软件架构设计系列包括软件生命周期、软件开发模型、软件开发方法、基于架构的软件开发、软件架构设计等。本文为系列之四——基于架构的软件开发。
基于架构的软件开发基于架构的软件设计（Architecture-Based Software Design，ABSD）方法是由功能需求、质量属性和约束的组合驱动软件架构设计、软件架构驱动开发的方法。基于架构的软件设计是一种自顶向下，递归，逐步求精的软件开发方法。这种方法有 3 个基础：
（1）功能分解。
（2）通过选择合适的架构风格来满足质量属性和业务需求。
（3）使用软件模板。
所谓模板是将一个事物的结构规律予以固定化、标准化的成果，它体现的是结构、形式的标准化。软件模板也是类似的概念，软件模板是一个特殊类型的软件元素，包括描述所有这种类型的元素在共享服务和底层构造的基础上如何进行交互。软件模板实际上相当于一个软件元素予以固定化、标准化的基础框架。软件模板实现了软件框架的的重用，在软件产品线系统中，软件模板显得格外重要，因为新元素的引入是一个通用的技术，这种技术用来使产品线架构适应一个特定的产品。
基于架构的软件设计方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，这有助于降低架构设计的随意性。
基于架构的软件设计方法与生命周期基于架构的软件设计方法在软件生命周期中处于需求分析之后的位置。至少完成部分需求，获得部分关键的需求（包括功能需求、质量属性和业务需求、设计约束等），才能开始基于架构的软件设计。基于架构的软件设计方法的输出是三个视图的集合（抽象构件、软件模板、设计约束）。
ABSD方法与生命周期
基于架构的软件设计方法的输入由下列部分组成：
（1）功能需求（抽象功能需求，包括变化的需求和通用的需求；用例（实际功能需求））；
（2）质量需求（抽象的质量和业务需求；质量因素（实际质量和业务需求）；架构选项）
（3）约束。
下基于架构的软件设计方法的输入：
1．抽象功能需求：功能需求的抽象描述，包括这些需求的粗略变化的描述。
2．用例：用例是一个或多个最终用户与系统之间的交互的具体表述，最终用户既可以是操作人员，也可以是与系统进行交互操作的其他软件系统。在此阶段，只需关注关键的用例即可，架构的设计主要参考关键的、优先级高的用例。
3．抽象的质量和业务需求。
4．架构选项：满足质量和业务需求的多个架构选项。例如，如果要支持跨平台交互，则可能的架构选择就是消息中间件、基于服务的调用等。
5．质量场景：质量场景是质量需求的特定扩充。
6．约束：约束是一个前置的设计决策，设计过程本身包含决策。例如，某厂商要求使用国产操作系统和国产数据库等。很多情况下，约束由遗留系统决定，遗留系统通常封装为构件，与新系统进行集成。
基于架构的软件开发模型基于架构的软件开发模型（Architecture-Based Software Design Model，ABSDM）把整个基于架构的软件过程划分为架构需求、设计、文档化、复审、实现、演化等 6 个子过程。
基于架构的软件开发模型
一、架构需求
架构需求是指对目标架构在功能、行为、性能、设计约束等方面的期望。
架构需求过程
（1）需求获取：从系统的质量目标、系统的业务目标和系统开发人员的业务目标中获得。软件架构需求侧重于软件质量属性，主要是定义开发人员必须实现的功能，从而满足业务需求。
（2）标识构件
该过程为系统生成初始逻辑结构，包含大致的构件。这一过程的步骤：生成类图->对类进行分组->把类打包成构件。
（3）需求评审：组织一个由不同代表（如分析人员、客户、设计人员、测试人员）组成的小组，对架构需求及相关构件进行仔细的审查。审查的主要内容包括所获取的需求是否真实反映了用户的要求，类的分组是否合理，构件合并是否合理等。
“需求获取—标识构件—需求评审”是一个迭代的过程。
二、架构设计
架构需求用来激发和调整设计决策。架构设计和架构需求一样，也是一个迭代的过程。
架构设计过程
（1）提出软件架构模型：首要任务是选择合适的架构风格，在此基础上提出架构模型。
（2）把已标识的构件映射到软件架构中。
（3）分析构件之间的相互作用。
（4）产生软件架构。
（5）设计评审。
三、架构文档化
架构文档化是将抽象的架构编制为文档的过程。架构文档是系统设计与开发人员的媒介，是不同人员之间沟通的基础文档之一。
架构文档化过程的主要输出结果是架构需求规格说明和测试架构需求的质量设计说明书这两个文档。生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。
四、架构复审
架构设计、架构文档化和架构文档复审都是迭代的过程。
架构复审的目的是标识潜在的问题和风险，及早发现架构设计中的问题。主要包括架构能否满足需求、是否体现了质量需求、层次结构是否清晰、构件的划分是否合理等。
五、架构实现
所谓“实现”就是要用实体来展示出一个软件架构，即要符合架构所描述的结构性设计决策，拆分成不同的构件并实现，按规定方式互相交互。
架构实现过程
架构实现过程是在复审后的架构说明书的基础的基础上，每个构件必须满足软件架构中说明的对其他构件的责任。这些决定即实现的约束是在系统级或项目范围内做出的，每个构件上工作的实现者是看不见的。
在架构说明书中，已经定义了系统中构件与构件之间的关系。可以从构件库中查找符合约束的构件，如果没有则开发新的构件。
然后，按照设计提供的结构，通过相应的工具把这些构件组装起来，完成整个软件系统的连接与合成。
最后是测试，包括单个构件的功能性测试和被组装应用的整体功能和性能测试。
六、架构演化
软件的架构虽然是相对稳定的，但需求却是不断的变化的，软件架构也应随需求的变化进行更新，以满足新的软件需求。架构演化主要包括以下七个步骤：
（1）需求变动归类。首先对用户需求的变化进行归类，使变化的需求与已有构件对应。对找不到对应构件的变动，也要做好标记，在后续工作中，将创建新的构件，以对应这部分变化的需求。
（2）制订架构演化计划。在改变原有结构之前，开发组织必须制订一个周密的架构演化计划，作为后续演化工作的指南。
（3）修改、增加或删除构件。在演化计划的基础上，可根据在第一步得到的需求变动的归类情况，决定是否修改或删除存在的构件、增加新构件。最后还应对修改和增加的构件进行测试。
（4）更新构件的相互作用。随着构件的增加、删除和修改，构件之间的交互也要更新。
（5）构件组装与测试。把这些构件的实现体组装起来，完成整个软件系统的连接与合成，形成新的架构。再对组装后的系统进行整体的测试。
（6）技术评审。对以上步骤进行确认，进行技术评审。评审组装后的架构是否反映需求变动，符合用户需求。如果不符合，则需要在第 2 到第 6 步之间进行迭代。
（7）产生演化后的架构。将所作的所有修改集成到原来的架构中，完成一次架构的演化过程。
架构演化过程
评论：
基于架构的软件设计特点是：架构驱动、迭代、增量、演化。这个过程基本涵盖了软件架构设计过程中的所有过程、步骤和要点。后面将要讲到的更加具体的软件架构设计的内容，都会参考此方法。掌握了这种软件设计方法，就打开了软件架构设计的大门，是软件架构师必须掌握的软件设计方法。
,
