下载掌阅APP，畅读海量书库
立即打开
2.8 软件开发方法
Jackson方法有时也称为面向数据结构的软件设计方法。这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其他细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。该方法也可与其他方法结合，用于模块的详细设计。
1974年，J. D. Warnier提出的软件开发方法与Jackson方法类似。
差别有三点：一是它们使用的图形工具不同，分别使用Warnier图和Jackson图；二是使用的伪码不同；三是在构造程序框架时，Warnier方法仅考虑输入数据结构，而Jackson方法不仅考虑输入数据结构，而且还考虑输出数据结构。
面向对象的软件开发方法OMT（Object Modelling Technique）是一种自底向上和自顶向下相结合的方法，而且它以对象建模为基础，从而不仅考虑了输入、输出数据结构，实际上也包含了所有对象的数据结构。OO技术在需求分析、可维护性和可靠性这三个软件开发的关键环节和质量指标上有了实质性的突破，彻底地解决了在这些方面存在的严重问题，从而宣告了软件危机末日的来临。建立对象模型既包括自底向上的抽象过程，也包括自顶向下的分解过程。
OMT的第一步是从问题的陈述入手，构造系统模型。从真实系统导出类的体系，即对象模型包括类的属性，与子类、父类的继承关系，以及类之间的关联。类是具有相似属性和行为的一组具体实例（客观对象）的抽象，父类是若干子类的归纳。因此这是一种自底向上的归纳过程。在自底向上的归纳过程中，为使子类能更合理地继承父类的属性和行为，可能需要自顶向下修改，从而使整个类体系更加合理。由于这种类体系的构造是从具体到抽象，再从抽象到具体，符合人类的思维规律，因此能更快、更方便地完成任务。这与自顶向下的Yourdon方法形成鲜明的对照。在Yourdon方法中构造系统模型是最困难的一步，因为自顶向下的“顶”是一个空中楼阁，缺乏坚实的基础，而且功能分解有相当大的任意性，因此需要开发人员有丰富的软件开发经验。而在OMT中这一工作可由一般开发人员较快地完成。在对象模型建立后，很容易在这一基础上再导出动态模型和功能模型。这三个模型一起构成要求解的系统模型。
在建立对象模型的过程中，也包括自顶向下的分解。例如对于计算机系统，首先识别出主机对象、显示器对象、键盘对象和打印机对象等。接着对这些对象再进一步分解，例如主机对象由处理器对象、内存对象、硬盘对象和主板对象组成。系统的进一步分解因有具体的对象为依据，所以分解过程比较明确，而且也相对容易。因此面向对象建模也具有自顶向下开发方法的优点，既能有效地控制系统的复杂性，又能同时避免结构化开发方法中功能分解的困难和不确定性。
每个对象类由数据结构（属性）和操作（行为）组成，有关的所有数据结构（包括输入、输出数据结构）都成了软件开发的依据。因此Jackson方法和PAM中输入、输出数据结构与整个系统之间的鸿沟在OMT中不再存在。OMT不仅具有Jackson方法和PAM的优点，而且可以应用于大型系统。更重要的是，在Jackson方法和PAM方法中，当它们出发点的输入、输出数据结构（即系统的边界）发生变化时，整个软件必须推倒重来。但在OMT中系统边界的改变只是增加或减少一些对象而已，整个系统改动极小。
（1）需求分析彻底
需求分析不彻底是软件失败的主要原因之一。即使在目前，这一危险依然存在。传统的软件开发方法在开发过程中不允许由于用户的需求发生变化，而导致出现种种问题。正是这一原因，人们提出了原型化方法，推出探索原型、实验原型和进化原型，积极鼓励用户改进需求。在每次改进需求后又形成新的进化原型供用户试用，直到用户基本满意，大大提高了软件的成功率。但是它要求软件开发人员能迅速生成这些原型，这就要求有自动生成代码的工具的支持。
OMT彻底解决了这一问题。因为需求分析过程已与系统模型的形成过程一致，开发人员与用户的讨论是从用户熟悉的具体实例（实体）开始的。开发人员必须搞清现实系统才能导出系统模型，这就使用户与开发人员之间有了共同的语言，避免了传统需求分析中可能产生的种种问题。
（2）可维护性大大改善
在OMT之前的软件开发方法都是基于功能分解的。尽管软件工程学在可维护方面做出了极大的努力，使软件的可维护性有较大的改进，但从本质上讲，基于功能分解的软件是不易维护的。因为功能一旦有变化就会使开发的软件系统产生较大的变化，甚至推倒重来。更严重的是，在这种软件系统中，修改是困难的。因为由于种种原因，即使是微小的修改也可能引入新的错误。所以传统开发方法很可能会引起软件成本增长失控、软件质量得不到保证等一系列严重问题。正是OMT才使软件的可维护性有了质的改善。
OMT的基础是目标系统的对象模型，而不是功能的分解。功能是对象的使用，它依赖于应用的细节，并在开发过程中不断变化。由于对象是客观存在的，因此当需求变化时对象的性质要比对象的使用更为稳定，从而使建立在对象结构上的软件系统也更为稳定。
更重要的是OMT彻底解决了软件的可维护性。在OO语言中，子类不仅可以继承父类的属性和行为，而且也可以重载父类的某个行为（虚函数）。利用这一特点，我们可以方便地进行功能修改：引入某类的一个子类，对要修改的一些行为（即虚函数或虚方法）进行重载，也就是对它们重新定义。由于不再在原来的程序模块中引入修改，所以彻底解决了软件的可修改性，从而也彻底解决了软件的可维护性。OO技术还提高了软件的可靠性和健壮性。
可视化开发是 20 世纪 90年代软件界最大的两个热点之一。随着图形用户界面的兴起，用户界面在软件系统中所占的比例也越来越大，有的甚至高达 60%～70%。产生这一问题的原因是图形界面元素的生成很不方便。为此Windows提供了应用程序设计接口API（Application Programming Interface），它包含了 600 多个函数，极大地方便了图形用户界面的开发。但是在这批函数中，大量的函数参数和使用数量更多的有关常量，使基于Windows API的开发变得相当困难。为此Borland C++推出了Object Windows编程。它将API的各部分用对象类进行封装，提供了大量预定义的类，并为这些定义了许多成员函数。利用子类对父类的继承性，以及实例对类的函数的引用，应用程序的开发可以省去大量类的定义、大量成员函数的定义或只需做少量修改以定义子类。
Object Windows还提供了许多标准的默认处理，大大减少了应用程序开发的工作量。但要掌握它们，对非专业人员来说仍是一个沉重的负担。为此人们利用Windows API或Borland C++的Object Windows开发了一批可视开发工具。
可视化开发就是在可视开发工具提供的图形用户界面上，通过操作界面元素，诸如菜单、按钮、对话框、文本编辑框、单选按钮、复选框、列表框和滚动条等，由可视开发工具自动生成应用软件。
这类应用软件的工作方式是事件驱动。对每一事件，由系统产生相应的消息，再传递给相应的消息响应函数。这些消息响应函数是由可视开发工具在生成软件时自动装入的。
构件技术是指通过组装一系列可复用的软件构件来构造软件系统的软件技术。通过运用构件技术，开发人员可以有效地进行软件复用，减少重复开发，缩短软件的开发时间，降低软件的开发成本。所谓软件构件化，就是要让软件开发像机械制造工业一样，可以用各种标准和非标准的零件来进行组装，或者像建筑一样，用各种建筑材料搭建成各式各样的建筑。软件的构件化和集成技术的目标是：软件可以由不同厂商提供的，用不同语言开发的，在不同硬件平台上实现的软件构件，方便地、动态地集成。这些构件要求能互操作，它们可以放在本地的计算机上，也可以分布式地放置在网上异构环境下的不同节点上。所谓结构化方法，其目标就是为了保证软件开发的质量，提高软件的灵活性的软件生产效率，通过工程化方法，其目标就是为了保证软件开发的质量，提高软件的灵活性和软件生产效率，通过工程化方法，建立系统及软件开发过程，使开发的软件具有好的结构，即所谓可拼装、可裁剪的模块化结构。由于有了面向对象技术的发展，多年来追求软件构件化的梦想，才有可能成为现实。
J2EE是Java 2 平台企业版（Java 2 Platform，Enterprise Edition）。J2EE是一套全然不同于传统应用开发的技术架构，包含许多组件，主要可简化且规范应用系统的开发与部署，进而提高可移植性、安全与再用价值。
Java语言由于巧妙地采用虚拟机的机制，使得编译后产生的泛代码程序可以在各种平台上执行，从而做到了程序执行与平台无关。加之用Java编的Applet可以方便地用浏览器下载运行，Java语言普及和发展得很快。Java采用了构件技术，发展了Java构件（即Java Beans）和企业级Java构件（即EJB）。为了用构件技术组成实际的应用系统，后来又推出了J2EE（Java2 环境平台企业版）和Java程序设计模型。
按照此模型组成的应用系统至少分为三层。第一层是客户层，可以采用一般的浏览器或特制的客户软件。从服务器下载的Applet可以带有Java Beans一起在客户端执行。为了避免由于不同厂商提供的浏览器中虚拟机的差异，还专门提供了虚拟机软件插件，做到程序的语义一致。为了保证安全，客户分防火墙内外，外客户只能从服务器进入，而内客户允许使用RMI、IIOP等直接访问EJB。
第二层是中间层，即业务逻辑层。其中有两个包容器，一个是Web包容器，另一个是EJB包容器。Servlets Java服务器页面（JSP）技术使人机界面的开发变得非常容易，而Servlets则方便为Applet等客户程序提供服务。简单的业务逻辑由开发人员编写业务Beans，而复杂的业务逻辑则由EJB完成。
第三层是企业的信息系统。第二层的构件通过JDBC（访问关系数据库）、JNDI（Java子目录接口）、JMS（Java消息服务）、JavaMail（发送和接收信件）、JavaIDL（与CORBA构件接口）访问第三层企业的信息系统。为了保护过去的投入，第三层可以与传统的应用软件、电子政务、ERP等建立联系。
.NET包含了建立和运行基于XML的软件需要的全部部件。
Microsoft.NET解决了下面这些当今软件开发中的一些核心问题：
（1）互操作性（interoperability）、集成性（integration）和应用程序的可扩展性（extensibility）太难实现而且代价很高。Microsoft.NET依靠XML（一个由World Wide Web Consortium（W3C）管理的开放标准）消除了数据共享和软件集成的障碍。
（2）无数具有相当竞争力的私有软件技术使得软件的集成变得非常复杂。而Microsoft.NET建立在一个开放的标准上，它包含了所有编程语言。
（3）当终端用户使用软件时，他们总觉得不够简便，有时甚至感到很沮丧，因为他们无法在程序之间方便地共享数据或是无法对能访问的数据进行操作。XML使数据交换变得容易了，并且.NET软件可以使得用户只要一得到数据就能对它们进行操作。
（4）终端用户在使用Web的时候，无法对自己的个人信息和数据进行控制，这导致了个人隐私和安全泄露问题。而Microsoft.NET提供了一套服务，使用户可以管理他们的个人信息，并且控制对这些信息的访问。
（5）COM公司和Web站点开发者们很难为用户们提供足够的有价值的数据，至少有一部分原因是由于他们的应用程序和服务无法很好地和其他程序和服务合作，只是一个不和外界连接的信息孤岛。而Microsoft.NET的设计宗旨就是为了使来自于多个站点和公司的数据或服务能够整合起来。
XML Web服务是建立在XML数据交换基础上的软件模型，它帮助应用程序、服务和设备一起工作。用XML进行共享的数据，彼此之间独立，但同时又能够松耦合地连接到一个执行某特定任务的合作组。
XML Web服务使开发者能够对他们所要的程序的来源进行选择，可以自己创建或购买程序的功能块；同样也可以选择是让自己的方案使用其他的XML Web服务，还是让其他的程序使用自己的服务。这意味着一个公司不必为了给客户一个完整的解决方案而不得不提供方案的每一个组成部分。
XML Web服务除了服务相互之间独立以外，对访问它们的设备而言也是独立的。与独立应用程序不同的是，XML Web服务并没有束缚于某一特定的编程语言、商业应用程序或者是某一在线服务。这给了终端用户足够的自由，使其可以使用任何访问设备，从台式计算机到移动电话都可以。
UML是一种可视化的建模语言，结合了Booch、Objectory和OMT方法，同时吸收了其他大量方法学的思想，提供了一种表示的标准。1997 年OMG采纳UML作为软件建模语言的标准，可以应用于不同的软件开发过程。
下面介绍UML涉及的一些基本概念。
UML用模型来描述系统的静态结构和动态行为。为了捕捉要构建的软件系统的所有决策信息，需要从团队中不同参与者的角度出发，为系统的体系结构建模，形成不同的系统视图。要描述一个软件系统，下面的五种视图尤为重要。
（1）用例视图（Use case view）
用例视图定义系统的外部行为，是最终用户、分析人员和测试人员所关注的。用例视图定义了系统的需求，是描述系统设计和构建其他视图的基础，即用例驱动。用例视图也称为用户模型视图。
（2）逻辑视图（Logic view）
逻辑视图描述逻辑结构，该逻辑结构支持用例视图描述的功能，它描述了问题空间中的概念以及实现系统功能的机制，如类、包、子系统等，因而是编程人员最关心的。逻辑视图又称做结构模型视图或静态视图。
（3）实现视图（Implementation view）
实现视图描述用于组建系统的物理组件，如可执行文件、代码库和数据库等系统程序员所看到的软件产物，是和配置管理以及系统集成相关的信息。实现视图又称为组件视图（Componentview）。
（4）过程视图（Process view）
过程视图描述将系统分解为过程和任务，以及这些并发元素之间的通信与同步。过程视图对于系统集成人员特别重要，因为他们需要考虑系统的性能和吞吐量等。过程视图也称为并发视图、动态视图或者协作视图等。
（5）部署视图（Deployment view）
描述系统的物理网络布局，是系统工程和网络工程师所感兴趣的。又称做物理视图。
每个视图都由一个或者多个图组成，一个图是系统体系结构在某个侧面的表示，所有的图在一起组成系统的完整视图。UML提供了九种不同的图，分为静态图和动态图两大类。静态图包括用例图、类图、对象图、组件图和配置图，动态图包括序列图、状态图、协作图和活动图。
（1）用例图（Use case diagram）
用例图描述系统的功能，由系统、用例和角（Actor）三种元素组成。图中显示若干角色以及这些角色和系统提供的用例之间的连接关系。用例是系统对外提供的功能的描述，是角色和系统在一次交互过程中执行的相关事务的序列。角色是与系统、子系统或类交互的外部人员、进程或事物。
用例之间存在扩展、使用和组合三种关系。角色之间可以用通用化关系将某些角色的共同行为抽象为通用行为。在UML中，用例图是用例视图的重要组成部分。
（2）类图（Class diagram）
类图用来表示系统中的类以及类与类之间的关系，描述系统的静态结构，用于逻辑视图中。类是对象的抽象描述。所谓对象就是可以控制和操作的实体，类是具有共同的结构、行为、关系、语义的一组对象的抽象。类的行为和结构特征分别通过操作和属性表示。
类与类之间有多种关系，如关联、依赖、通用化、聚合等。关系提供了对象之间的通信方式。关联关系用于描述类与类之间的连接，通常是双向的。通用化又称继承，是通用元素和具体元素之间的一种分类关系，具体元素完全拥有通用元素的信息，并且还可以附加其他信息。聚合关系具有较强的耦合性，描述整体与部分的关系。依赖关系描述两个模型无素之间语义上的连接关系，其中一个元素是独立的，另一个元素依赖于独立的模型元素，独立元素的变化将影响到依赖元素。
（3）对象图（Object diagram）
对象图是类图的示例，类图表示类和类与类之的关系，对象图则表示在某一时刻这些类的具体实例以及这些实例之间的具体连接关系，可以帮助人们理解比较复杂的类图。对象图也可以用于显示类图中的对象在某一点的连接关系。对象图常用于用例视图和逻辑视图中。
（4）状态图（State diagram）
状态图主要用来描述对象、子系统、系统的生命周期。通过状态图可以了解一个对象可能具有的所有状态、导致对象状态改变的事件，以及状态转移引发的动作。状态是对象操作的前一次活动的结果，通常由对象的属性值来决定。事件指的是发生的且引起某些动作执行的事情。状态的变化称做转移，与转移相连的动作指明状态转移时应该做的事情。状态图是对类描述的事物的补充说明，用在逻辑视图中描述类的行为。
（5）序列图（Sequence diagram）
面向对象系统中对象之间的交互表现为消息的发送和接收。序列图反映若干个对象之间的动态协作关系，即随着时间的流逝，消息是如何在对象之间发送和接收的。序列图表现为二维的形式，其中的纵坐标轴显示时间，横坐标轴显示对象。序列图中重点反映对象之间发送消息的先后次序，常用在逻辑视图中。
（6）协作图（Collaboration diagram）
协作图主要描述协作对象之间的交互和链接。协作图和序列图同样反映对象间的动态协作，也可以表达消息序列，但重点描述交换消息的对象之间的关系，强调的是空间关系而非时间顺序。
（7）活动图（Activity diagram）
活动图显示动作及其结果，着重描述操作实现中所完成的工作以及用例实例或对象中的活动。活动图中反映了一个连续的活动流，常用于描述一个操作执行过程中所完成的工作。活动图也有其他的用途，如显示如何执行一组相关的动作，以及这些动作如何影响它们周围的对象，说明一次商务活动中的工人、工作流、组织和对象是如何工作的等。
（8）组件图（Component diagram）
组件图用来反映代码的物理结构。组件可以是源代码、二进制文件或可执行文件，包含逻辑类的实现信息。实现视图由组件图构成。
（9）配置图（Deployment diagram）
配置图用来显示系统中软件和硬件的物理架构。图中通常显示实际的计算机和设备及它们之间的关系。配置图用来构成配置视图，描述系统的实际物理结构。
可以在图中使用的概念统称为模型元素。模型元素用语义、元素的正式定义或确定的语句的准确含义来定义。模型元素在图中用相应的符号表示，即视图元素。一个模型元素可以用在多个不同的图中，但总是具有相同的含义和符号表示，并且出现的方式应符合一定的规则。
除了类、对象、消息等概念外，模型元素之间的连接关系如关联、依赖、通用化也是模型元素。另外，模型元素也包括消息、动作和版型等。
通用机制用于为图附加一些无法用基本的模型元素表示的信息，如注释（note）、修饰（adornment）和规格说明（specification）等。
在图的模型元素上添加修饰为模型元素附加一定的语义，这样，建模人员就可以方便地区别类型与实例。
无论建模语言怎样扩展，它都不可能适用于描述任何事物。UML提供的注释能力能够在模型中加一些模型元素无法表示的额外信息，对某个元素做出解释或说明。
模型元素具有的一些性质是以数值方式体现的。一个性质用一个名称和一个值表示，又称做加标签值（Tagged value）。UML中预定义了许多性质，一般作为模型元素实例的附加规格说明。这种规范说明方式是非正式的，不直接显示在图中。
为了使建模人员根据需要对基本建模语言进行一定的扩展，UML提供了版型、加标签值和约束等扩展机制。
版型机制是指在已有的模型元素基础上建立一种新的模型元素。版型比现有元素多一些特别的语义，其使用场所和产生版型的原始元素相同。版型的存在避免了UML语言过于复杂化，同时也使UML能够适应各种需求。
加标签值也称为性质。除了UML语言中预定义的性质外，用户还可以为元素定义一些附加信息，即定义性质。
约束是对元素的限制。通过约束限定元素的用法或元素的语义。
通过扩展机制可以扩展UML以适用于某种具体的方法、过程或组织。
用UML语言建造系统模型时，并不是只建立一个模型。在系统开发的每个阶段都要建造不同的模型，建造这些模型的目的也不同。需求分析阶段建造的模型用来捕获系统的需求，描绘与真实世界相应的基本类和协作关系。设计阶段的模型是分析模型的扩充，为实现阶段做指导性的、技术上的解决方案。实现阶段的模型是真正的源代码，编译后就变成了程序。最后的配置模型则是在物理架构上解释系统是如何展开的。
UML尽可能地结合了世界范围内面向对象项目的成功经验，因而它的价值在于它体现了世界上面向对象方法实践的最好经验，并以建模的形式将它们打包，以适应开发大型复杂系统的要求。但需要说明的是，UML作为一种建模语言，目的是为不同领域的人们提供统一的交流标准，其本身并不能保证系统的质量。使用UML建模，必须依照某种方法或过程进行。
在众多的软件设计和实现的经验中，最突出的有两条，一是注重系统体系结构的开发，二是注重过程的迭代和递增性。尽管UML本身没有定义任何过程，但UML对任何使用它的方法或过程提出的要求是：支持用例驱动，以体系结构为中心以及递增和迭代地开发。