软件开发技术之个人见解

  

软件开发技术的发展历程

按照软件生命周期学的观点，软件的生命周期包括可行性研究、需求分析、概要设计、详细设计、编码与测试、维护、退出使用七个阶段

1.可行性研究：研究待开发系统是否有行得通的解决办法，以及成木与效益上的可行性

2.需求分析：详细分析用户需求，决定系统必须做什么，或者说系统必须具备哪些功能，即明确“问题域”

3.概要设计和详细设计：如何实现这些功能以及找出具体的实现办法，即为问题域找出“解域”

4.编码与测试：就是选用适当地程序设计语言(可以是一种，也可以是多种)，将解域翻译成计算机能处理的编码语言，通过测试保证编码的正确性

5.维护：交付使用后，要定时进行维护

 

2.1 明确“问题域”

首先明确问题域，只有明确了问题域，才能开发出符合用户需求的系统，而且，也只有明确了问题域，才能使后续的开发不致因问题域发生错误而修改。在软件开发的不同阶段，进行修改需要付出的代价很不相同。对于同样的修改越在开发的早期阶段进行，涉及面越小，改动代价越低 ; 越在后而阶段进行，涉及面越大，改动的代价越大，而且代价是呈数量级增加的

 

2.2 理解“问题域”的关键（Key）：建立模型

建立模型：用一组抽象的图形符号和组织这些符号的规则，把所要解决的问题，以及对应的解决办法描述出来

 

2.3 建模方法的应运而生（四种建模方法的产生）

 

2.3.1 : 结构化方法

以数据流图为主线，采用自顶向下，逐层细化，逐步求精的分解方法，直到每一个处理不能再分解为止

缺点 ：

结构化模型的可维护性、复用性也比较差、数据与处理数据的过程分离，割裂了两者的内在联系，所获得的模型难于理解和交流是一种不稳定的模型

第一，传统方法开发的系统结构稳定性差

第二，系统功能难以修改和扩充

第三，软件的可复用性较差

资料显示：传统方法提高软件开发效率的速度远远赶不上社会对软件产品需求的增加速度

 

2.3.2 面向对象方法

产生于 20 世纪 80 年代，之后得到了极大发展，以对象类作为建模元素，，类的封装、继承和多态性使得面向对象技术相对于传统软件开发方法更容易构造出结构稳定、利于复用、易于维护的系统，直接反应了客观世界事物及其间的联系，非常符合人们的思维习惯，因而得以广泛使用，面向对象的建模方法有 Booch 方法、 OMT 方法、 OOSE 方法等

缺点 ：

第一，面向对象方法中，对象和类是最大的建模元素，这些对象类往往粒度较少，在大型系统中，往往会存在数以百计甚至几千的对象类，这么多的对象类难于用于建模和管理。

第二，对于分布系统缺乏足够的表达能力，无以从对象模型中区分出一个对象是本地对象还是远程对象，而这一点又是很重要的，因为对象实现时必须据此作出封装形式和合作方法的选择，当然不同的面向对象建模方法之间在建模处理上也存在一些差异。

第三，面向对象技术不存在一个标准的框架，由不同编程语言实现的软件对象无法在同一地址空间里交互合作，更不用说进行跨进程、跨网络空间的交互合作了。面向对象技术还只能是一种基础，由它设计实现的系统仍然是一种封闭的系统。

 

2.3.3 构件法

20 世纪 9 0 年代，软件技术的一个重大发展就是产生了构件技术，开发构件和应用构件进行系统构造的技术称为构件技术，以构件为建摸元素。构件是将一个或多个对象封装在一起而形成的一个功能内聚，对外通过接口交互的可执行模块。因此构件粒度比对象类要大，建模时可以大大减少建模元素个数，，构件可以存在于网络的任何位置 , 客户对构件的调用完全透明，调用者不必关心其存放位置。以构件构造的系统结构灵活，维护升级容易。

四个特点：

第一，具有封装性，构件封装了设计和实现，仅通过接口与外界交互合作。

第二，功能相对独立，一个好的构件其功能必须内聚且接口简单。

第三，具有复用性，构件的可复用程序越高，构件的价值越大。

第四，可执行，构件是一个可执行的二进制软件模块。构件尽管具有以上特点，然而它并没有规定构件的实现手段。事实上只要遵循约定的构件技术规范，构件可以通过任何编程语言来实现，无论是用面向对象编程语言，还是结构化编程语言。

缺点：

构件本身的设计仍然离不开面向对象技术或结构化技术 。

 

2.3.4 休系结构法【体系结构和软件构件接口标准】

 

2.3.4 .1 软件体系结构【软件构件 ＝＞经过一定结构 、规则和约束条件组装 ＝＞软件体系结构 】《当然了，那一系列的规则和约束条件就包含着构件间的接口规范》

构件技术的产生使得软件开发分成了两个独立的开发过程：

第一个过程是构件开发过程。

第二个过程是应用构件进行系统组装的过程。

所谓应用系统组装，就是指结合应用系统的需要，挑选所需要的软件构件，并按照一定结构、规则和约束条件，将各个构件连接起来，形成应用系统。这种组装系统所用的构件，组装结构，规则和约束就是一种软件体系结构 (Software Architecture).

196 8 年， Dijkstra 首次提出了软件体系结构的概念 (121 ，但是，直到现在还没有一个 标准一致的定义。

软件休系结构定义的四种模型观点：
一、 结构模型观点

二、 框架模型观点

三、 动态模型观点

四、 过程模型观点

软件体系结构风格：

管道 / 过滤器、批处理、客户 / 服务器 、主程序 / 子程序、层次结构、面向对象、构件风格、分布式处理、隐式调用、解释器、规则系统、黑板系统。

不同的软件体系结构风格往往又互相渗透，有的甚至是一般和特殊的关系。当今应用系统开发中层次结构与客户 / 服务期结合的风格较热门，例如：三层客户 / 服务器体系结构

 

2.3.4 .2 体系结构中的构件接口标准

构件的封装特性和基于接口标准的实现和访问方法使得人们可以利用构件灵活、快捷地构造系统 ＝＞ 为了使构件达到跨平台、跨空间、跨语言的互操作要求，就不能任意地构造软件构件

＝＞ 研究构件软件的体系结构和构件间的接口方式 ＝＞软件构件系统体系结构和软件构件接口标准等概念便应运而生＝＞这样构件在科学的软件体系结构与构件的主流接口规范的指导下就能进行合理的组装，发挥构件的复用以及构件的真正互操作作用＝＞软件项目达到前所未有的完善『无能面对多大的工程项目』

以构件 ( 广义的 ) 及构件间的连接和约束 等来表现一个系统的模型，它是对系统的一种高层次把握，适合于系统的早期建模，有利于不同人员 ( 包括管理者和开发者 ) 间的相互交流，有利于产品复用。但是在进行具休构件元素 ( 函数、类、狭义构件等 ) 设计时

从多种接口规范中走出来的主流规范有有 CORBA, COM/DCOM 和 JAVA 接口规范

CORBA ： CORBA 标准由 OMG 推出和管理，是出现最早，也被认为是做得最好的一个标准 CORBA 用 IDL 及 ORB 实现从客户到 ORB 及 ORB 到执行对象间的两个半桥，它强调类的继承比较规范，适合于封装现存系统。

缺点－ > 是标准庞大复杂，技术更新缓慢。

COM/DCOM ： Microsoft 推出了 COM/DCOM 标准，该标准依赖于精巧的底层二进制标准方案，强调多个接口的类型而不强调继承，因此在互操作及功能扩展方面更为灵活。

弱点－ > 是跨平台性能差，目前只局限于 Windows 平台。

JAVA ： JAVA 标准由 Sun 公司制定和推出的，演变很快，在其最早推出的时候，只提供了远程方法调用 (RMI) ， 类似于传统的 RPC ，只支持初级的分布式对象互操作。很快 Sun 公司推出了 Java Bean ，其目前版本为 EJB(Enterprise Java Bean),

它提供了远程访问、安全、事务、持久和生命期管理等多种分布对象计算的服务。

JAVA 是纯语言的，因此跨平台性能非常好。

缺点－ > 效率低。

因此，在标准选择上，很难说哪一种标准更好，只能根据具体的应用环境和目标来确定。

规范的重要性：

原因一：产品作为一个独立体存在时，考不考虑规范是无关紧要的，甚至在单个产品范围内不使用规范可以作更大的优化

原因二：当产品作为系统的一部分而存在时，规范问题就变得重要了，因为这将意味着产品生命期长短的问题。当系统改变时，不符合接口规范的部件将因无法连接而无法使用，有面临淘汰的危险

缺点 ：

仍需要结构化方法、面向对象方法或构件设计方法。

 

2.4建模实现的手段建模工具【UML标准建模语言的应运而生】

 

2.4.1 结构化方法中用到的数据流图、 ER 图、 IPO 图等就是一种建模语言。由于结构化方法的缺点，结构化建模语言己很少有人去进一步研究

 

2.4.2 面向对象方法自上世纪 70 年代以来一直是研究的热点。到 80 年代中期，面向对象建模方法就达十几种之多，到 1994 年，建模语言的数量增加到五十多种，一度爆发了“方法大战”

 

2.4.3 90 年代中期，出现了一批新方法，这其中比较引人注目的有 Booch 1993, OMT, ， Jacobso 1994 OOSE 【 Use Case 用例图】、 Coad/Yourdon 【 OOA/OOD 】方法。『这些方法中都应该我自己的一套建模的工具即建模语言』

 

2.4.4 1997年11月17日，UML 被 OMG 批准为基于面向对象的标准建模语言。  面向对象技术专家 Grady Booch, Ivar Jacobson 和 Jimes Rumnbaug 发起，在 Booch 方法、 OOSE 方法和 OMT 方法的基础上 ＝＞UML

 

2.4.5 UML 的不足＝＞待扩展【版本升级中】

它缺乏构件对象这一元素的定义和图形表示，所以无法判定一个对象是普通对象还是构件对象。

UML 并不能囊括所有的项目工程的建模需求的需要，有可能UML中缺少建模的元素：某些新的巨大工程项目需要的图或者其它元素，因此扩展UML是必要的。接下来我要做的事情就是善于发现最新UML标准中添加了那些新元素，UML中又有那些新的最准产生。