开发方法 · 软件重用、ABSD 与形式化方法

正规定义：软件重用指的是利用已经存在的软件元素建立新的软件系统，软件元素既可以是软件产品、源程序，也可以是文档、设计思想甚至是领域知识。为什么值得专门研究？软件产品与其他产品不同，是抽象的，一旦产生就可以无限制地复制，重用意义重大、节约大量人力物力——效果是提高开发效率、降低开发成本、缩短开发周期、提高软件质量，这四个「提高降低缩短」是填空素材。

常见的重用形式有七种：第一，源代码重用，最简单也最常见，但受软件系统复杂性限制，很难大规模重用已有源代码；第二，架构重用，随着软件架构风格和设计模式的推广和应用，已对软件开发产生重大影响；第三，应用框架的重用，很多成熟软件公司建立了自己的开发框架，开源社区也不断推出应用新技术的框架，例如应用了 AOP 面向方面编程技术的 Spring。

第四，业务建模的重用，重用常见领域的建模方法可以降低因领域知识不足造成的需求风险；第五，文档及过程的重用；第六，软构件的重用；第七，软件服务的重用，随着 Web 服务的提出人们越来越关注服务重用，SOA 面向服务的架构提出了相应标准，但 SOA 还不够成熟。考「以下不属于软件重用形式的是」就拿这七个名单做文章。

构件又称为组件，是一个自包容、可复用的程序集：它是一组程序的集合，可能以源程序或二进制代码等方式体现；这个集合整体向外提供统一的访问接口，构件外部只能通过接口来访问构件，不能直接操作构件的内部。两个最重要的特性是自包容与可重用——自包容指构件本身是功能完整的独立体，内外功能界限清晰明确，可独立配置与使用；可重用既是构件的特点，也是构件出现的目的。

构件历史要背一句：早在 1968 年 NATO 软件工程会议，Mcllroy 的论文《大量生产的软件构件》就提出了「软件组装生产线」的思想——从此使用构件技术实现软件复用、搭积木式生产软件成为软件人员的梦想。构件的开发者和使用者往往不是相同的人或组织，必须定义构件标准消除障碍，目前应用比较广泛的有三个：CORBA、Java Bean/EJB、COM/DCOM，一个不能少。

ABSD 是另一种打法。基于架构的软件设计，英文 Architecture-Based Software Design，缩写 ABSD，是一种架构驱动方法。这种方法有 3 个基础：第一，功能的分解，在功能分解中，ABSD 方法使用已有的基于模块的内聚和耦合技术；第二，通过选择架构风格来实现质量和业务需求；第三，软件模板的使用。前两个好懂，软件模板是原文说「对于设计方法来说是一个新概念」的东西，要多花一句。

软件模板是一个特殊类型的软件元素，包括描述所有这种类型的元素在共享服务和底层构造的基础上如何进行交互，还包括属于这种类型的所有元素的功能——例如每个元素必须记录某些重大事件、必须为运行期间的外部诊断提供测试点等。在软件产品线系统中软件模板格外重要：新元素的引入是使产品线架构适应特定产品的通用技术。另外记住 ABSD 的方法学性质：ABSD 是递归的，且迭代的每一步都清晰定义，因此不管设计是否完成，架构总是清晰的，有助于降低架构设计的随意性。

输入六项：抽象功能需求、用例、抽象的质量和业务需求、质量因素、架构选项、约束。两个概念值得抠。用例：一个或多个最终用户与系统之间交互的具体表述——用例很容易创建，甚至成百上千个，但必须限制数量：架构设计阶段只有重要的用例才有用，必须分组、设优先级筛选最重要的。质量场景：正如用例使功能需求具体化，质量场景使质量需求具体化，是质量需求的特定扩充，同样只验证最重要的。

约束：一个前置的设计决策。某些决策可直接由业务目标导出——例如公司在某个中间件上投入了大量资金，产品选择上就不必考虑其他决策；特殊情况下约束由遗留系统决定，出于商业目的要求重用遗留系统构件，这种需求就变成了约束。架构选项：对每个质量和业务需求列举能满足它的所有可能架构——比如需求是支持不同的用户界面，可选把不同界面分解成不同构件；此时只需列举，不需要决策。

来了，这是本集第一主考。基于架构的软件开发模型，英文 Architecture-Based Software Design Model，缩写 ABSDM，把整个基于架构的软件过程划分为 6 个子过程：架构需求、设计、文档化、复审、实现、演化。真题问「其中第一个是」，选项架构需求、架构设计、架构文档化、架构复审——答架构需求。这个子过程内部还有结构：包括需求获取、标识构件、需求评审三块，必要时可以在三者之间进行迭代。

需求这块展开一下。架构需求一般来自三个方面：系统的质量目标、系统的业务目标和系统开发人员的业务目标。标识构件分三步：第一步生成类图，第二步对类进行分组——与其他类隔离的类形成一个组，由泛化关联的类组成一个附加组，由聚合或组合关联的类也形成一个附加组，第三步把类打包成构件。需求评审则组织一个由不同代表——分析人员、客户、设计人员、测试人员——组成的小组，对架构需求及相关构件仔细审查，内容包括所获取的需求是否真实反映了用户的要求、类的分组是否合理、构件合并是否合理等。

架构设计子过程五步：提出软件架构模型——建立架构的初期，选择一个合适的架构风格是首要的；把已标识的构件映射到软件架构中，将产生一个只包含那些能明确适合架构模型的构件的中间结构；分析构件之间的相互作用；产生软件架构，在中间架构基础上细化；设计评审——一旦设计了软件架构，必须邀请独立于系统开发的外部人员对架构进行评审。

后面四个子过程快速走。架构文档化：绝大多数架构都是抽象的、由概念上的构件组成——例如层的概念在任何程序设计语言中都不存在——因此必须文档化才能让系统分析师和程序员去实现；文档是系统演化的每一阶段中设计与开发人员的通信媒介；主要输出两个文档——架构需求规格说明，和测试架构需求的质量设计说明书。架构复审：在一个主版本的软件架构分析之后，要安排一次由外部人员——用户代表和领域专家——参加的复审，目的是标识潜在的风险，及早发现架构设计中的缺陷和错误；由外部人员复审是为了保证架构的设计能够公正地进行检验。

架构实现：以复审后的文档化架构说明书为基础，用实体显示出软件架构，每个构件必须满足架构中说明的对其他构件的责任；可从构件库查找符合接口约束的构件，必要时开发新构件，然后通过组装支持工具把构件实现体组装起来，最后测试——包括单个构件的功能性测试和组装后应用的整体功能性能测试。架构演化是使用系统演化步骤修改应用以满足新需求，共七步：需求变动归类，使变化的需求与已有构件对应；制订架构演化计划；修改、增加或删除构件；更新构件的相互作用——构件增删改后构件之间的控制流必须更新；构件组装与测试；技术评审——不符合用户需求则在第 2 到第 6 步之间迭代；产生演化后的架构，把所有修改集成到原架构中，完成一次演化。

直觉对了，它就是数学系的东西。形式化方法是指采用严格的数学方法，使用形式化规约语言来精确定义软件系统。对照组是：非形式化的开发方法是通过自然语言、图形或表格描述软件系统的行为和特性，然后基于这些描述进行设计和开发；而形式化开发则是基于数学的方式描述、开发和验证系统。真题问「形式化方法的核心特点」，四个选项：使用图形化工具描述系统、采用严格的数学方法定义软件系统、使用自然语言描述需求、强调快速原型开发——答第二条。注意第一条和第三条恰恰是非形式化方法的做法。

内部结构两部分：形式化方法包括形式化描述和基于形式化描述的形式化验证。形式化描述就是用形式化语言进行描绘，建立软件需求和特性，即解决软件「做什么」的问题；形式化验证指的是验证已有的程序是否满足形式化描述的定义。这对「描述管做什么、验证管对不对」的分工要分清。形式化描述主要可以分为两类：一类是通过建立计算模型来描述系统的行为特性，另一类通过定义系统必须满足的一些属性来描述系统。

它的价值原文写得很满：形式化描述又称之为形式化规约，相对于自然语言描述，它是精确的、可验证的，避免了模糊性与二义性，消除需求中相互矛盾的地方，避免需求定义人员和开发人员对需求的理解偏差；可以通过计算机技术进行自动处理，进行一致性的检查和证明，很多自然语言描述无法避免的缺陷在需求分析阶段就会被发现并解决，从而降低后期开发和维护的成本，并提升软件的质量和可靠性。在一些要求高可靠性的关键应用上，采用形式化开发方法可以保证软件系统的可靠性。

有，而且是交通命脉级的：巴黎地铁 14 号线和 Roissy 机场穿梭车的自动控制系统，这两个系统中的部分程序使用了形式化方法进行开发，并取得了很好的效果。表里的 ADA 代码行数表示运用形式化方法开发的软件系统规模，这些代码是形式化方法自动生成的，开发人员并不需要直接修改。最劲爆的是原文专家提示的那句：这两个案例都没有进行单元测试——而在非形式化开发中，这类关键应用系统的单元测试和集成测试都是非常重要的工作，通常要付出高昂的代价。形式化开发的优点可见一斑。考判断题：「形式化开发的关键系统仍必须做大量单元测试」——按教材口径，错。

全章必背，分模块过。生命周期：GB8566-88 划分 8 阶段，详细设计不是必需阶段。开发模型：瀑布面向文档、难适应变化、重载；V 模型需求对系统测试、总体设计对集成测试、详细设计对单元测试；演化是瀑布的若干次迭代；螺旋最突出特点是强调风险分析、每周期需求定义、风险分析、工程实现、评审四阶段、适用庞大复杂高风险；增量发布每版本完整可用、增量要均匀；原型法用完一般抛弃；构件组装自包容使扩展更容易是优点、缺点四条。

UP：二维模型横轴初始细化构建交付、纵轴九工作流；四里程碑目标对应初始、架构对应细化、能力对应构建加 Alpha 测试、发布对应交付；UP 不属于敏捷、未裁减的重载。敏捷：宣言 2001 年 2 月犹他州 17 人；XP 四大价值观沟通简单反馈勇气、尊重是隐藏的、十二实践完整运用；FDD 类的个体所有专人维护；Scrum 五价值观没有简单、Sprint 两到四周；水晶透明水晶 6 人以下；开放源码地理分布广；ASD 猜测合作学习。重用与架构：重用七形式、构件标准三个；ABSD 三基础；ABSDM 六子过程以架构需求为首；形式化方法两部分、巴黎地铁与 Roissy 案例。

连起来就对了，考试就爱在模型之间跳着问。下一章讲系统规划——立项之前怎么论证这个系统值不值得建，成本效益怎么算，那是决策层的功课，架构师也躲不掉。