《软件工程方法与实践》—— 3.4 面向对象模型

本节书摘来自华章出版社《软件工程方法与实践》一 书中的第3章,第3.4节,作者窦万峰,更多章节内容可以访问云栖社区“华章计算机”公众号查看。

3.4 面向对象模型

3.4.1 构件集成模型

构件集成模型利用模块化方法将整个系统模块化,并在一定构件模型的支持下重用构件库中的软件构件,通过组合手段提高应用软件系统过程的效率和质量。构建集成模型融合了螺旋模型的许多特征,本质上是演化型的,开发过程是迭代的。基于构件的开发模型由软件的需求分析和定义、体系结构设计、构件库建立、应用软件构建及测试和发布5个阶段组成。采用这种开发模型的软件过程如图3-4所示。


《软件工程方法与实践》—— 3.4 面向对象模型

基于构件的开发活动从标识候选构件开始,通过搜查已有构件库,确认所需要的构件是否已经存在。如果已经存在,则从构件库中提取出来重用,否则采用面向对象方法开发它。之后利用提取出来的构件通过语法和语义检查后将这些构件通过胶合代码组装到一起实现系统,这个过程是迭代的。基于构件的开发方法使得软件开发不再一切从头开发,开发的过程就是构件组装的过程,维护的过程就是构件升级、替换和扩充的过程。其优点是构件集成模型导致了软件的重用,提高了软件开发的效率。
由于采用自定义的组装结构标准,缺乏通用的组装结构标准,这样就引入了比较大的风险。可重用性和软件高效性不容易协调,这就需要比较有开发经验的开发人员,而一般的开发人员很难开发出令客户满意的软件。由于过分依赖于构件,所以构件库的质量影响着产品质量。
构件集成模型融合了螺旋模型的很多特征,支持软件开发的迭代方法。这种面向重用的过程模型,最明显的优势是减少了需要开发的软件数量,加快了软件交付,从而降低了开发成本,同时降低了开发风险。当然,它的成功主要是依赖与可以存取的可重用软件构件,以及能集成这些软件构件的框架。

3.4.2 统一过程模型

统一过程模型(Unified Process,UP)是风险驱动的、基于用例技术的、以架构为中心的、迭代的、可配置的软件开发流程。UP是一个面向对象且基于网络的程序开发方法论。根据Rational Rose和统一建模语言的开发者的说法,它可以为所有方面和层次的程序开发提供指导方针、模板以及用例支持。
统一过程模型是一个软件开发过程,是一个通用的过程框架,可以用于各类软件系统和应用领域。统一过程模型是在重复一系列组成系统生存周期的循环。每一次循环包括4个阶段:初始、细化、构造和移交,每个阶段又进一步细分为多次迭代的过程,如图3-5所示。每次循环迭代会产生一个新的版本,每个版本都是一个准备交付的产品。


《软件工程方法与实践》—— 3.4 面向对象模型

初始阶段。在初始阶段将一个好的想法发展为最终产品的一个构想,提出了该产品的业务实例。该阶段要完成:系统向它的每个重要用户提供的基本功能是什么?该系统的逻辑架构大概是什么样子?开发该产品的计划如何?开销多大?在该阶段主要建立关键用例的简化用例模型,用于刻画系统主要功能。架构是实验性的,通常包括主要子系统的大致轮廓。要确定最主要的风险及其优先次序,对细化阶段进行详细规划,并对项目进行粗略估算。
细化阶段。在细化阶段,详细说明该系统的绝大多数用例,并设计出系统的架构。架构可以表示为系统中所有模型的不同视图,合起来表示整个系统,即架构包括用例模型、分析模型、设计模型、实现模型和实施模型的视图。在细化阶段末期,要规划完成项目的活动,估算完成项目所需的资源。关键问题是用例、架构和计划是否足够稳定、可靠,风险是否得到控制,以便按照合同的规定完成整个开发任务。该阶段的结果是架构基线。
构造阶段。构造阶段将构造出最终产品—软件。在该阶段,架构基线逐步发展成为完善的系统,将消除所需要的大部分资源,架构可以进行微调,但系统架构是稳定、可靠的。要回答的问题是早期交付给客户的产品是否完全满足用户的需求。
移交阶段。移交阶段包括产品进入分析后期的整个阶段,用户使用分析法发现产品的缺陷和不足,开发人员改正问题及完善系统形成更通用的版本。该阶段包括诸如制作、用户培训、提供在线支持以及改正交付之后发现的缺陷活动。
统一过程模型在定义4个阶段及其迭代过程时,又给出了5个核心工作流:需求、分析、设计、实现和测试。每个工作流在各个阶段所处的地位和工作不同。图3-6给出了统一过程模型的核心工作流。

《软件工程方法与实践》—— 3.4 面向对象模型

需求。需求工作流的目的是致力于开发正确的系统。需求工作流要求足够详细地描述系统需求,使客户和开发人员在系统应该做什么、不应该做什么方面达到共识。
分析。分析工作流的目的是更精确地理解需求,也是为了得到一个易于维护且有助于确定系统结构的需求描述。与需求工作流相比,分析工作流可以使用开发人员的语言来描述和组织。需求捕获阶段的需求,探究系统内部,解决用例间的干扰以及类似的问题。分析得到的需求结构可用做构造整个系统的基本输入。分析工作流使用分析模型表达系统的本质。
设计。设计工作流的目的是深入理解与非功能性需求和约束相联系的编程语言、构件使用、操作系统、分布与并发技术、数据库技术、用户界面技术和事务管理技术等相关问题。设计工作流把实现工作划分成更易于管理的各个部分,捕获早期子系统之间的主要接口,建立对系统实行的无缝抽象。
实现。实现工作流探讨如何用源代码、脚本、二进制代码、可执行体等构件来实现系统。实现工作流的目的是规划每次迭代中所要求的系统集成,通过把可执行构件映射到实施模型中的结点的方式来分布系统,实现设计过程中发现的设计类和子系统,对构件进行单元测试。
测试。测试工作流通过测试每一个构造来验证实现的结构。测试工作流的目的是规划每一次迭代需要的测试工作,包括集成测试和系统测试。设计和实现测试,执行各种测试并系统地处理每个测试的结果。
统一过程模型也存在一些缺点:统一过程模型只是一个开发过程,并没有涵盖软件过程的全部内容,如它在软件运行和支持等方面的内容略有不足。此外,它不支持多项目的开发结构,这在一定程度上降低了在开发组织内大范围实现重用的可能性。统一过程模型是一个非常好的开端,但并不完美,在实际的应用中可以根据需要对其进行改进,并可以用其他软件过程的相关模型对统一过程模型进行补充和完善。