基于架构的软件开发模型把整个
基于架构的软件过程划分为架构需求、设计、文档化、复审、实现、演化等 6 个子过程，
如图 6-9 所示。
1．架构需求
需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。架构需求
受技术环境和架构设计师的经验影响。需求过程主要是获取用户需求，标识系统中所要用到
的构件。架构需求过程如图 6-10 所示。如果以前有类似的系统架构的需求，我们可以从需
求库中取出，加以利用和修改，以节省需求获取的时间，减少重复劳动，提高开发效率。
（1）需求获取
架构需求一般来自三个方面，分别是系统的质量目标、系统的业务目标和系统开发人员
的业务目标。软件架构需求获取过程主要是定义开发人员必须实现的软件功能，使得用户能
完成他们的任务，从而满足业务上的功能需求。与此同时，还要获得软件质量属性，满足一
些非功能需求。
（2）标识构件
在图 6-10 中虚框部分属于标识构件过程，该过程为系统生成初始逻辑结构，包含大致
的构件。这一过程又可分为三步来实现。
第一步：生成类图。生成类图的 CASE 工具有很多，例如 Rational Rose 就能自动生成
类图。
第二步：对类进行分组。在生成的类图基础上，使用一些标准对类进行分组可以大大简
化类图结构，使之更清晰。一般地，与其他类隔离的类形成一个组，由泛化关联的类组成一
个附加组，由聚合或组合关联的类也形成一个附加组。
第三步：把类打包成构件。把在第二步得到的类簇打包成构件，这些构件可以分组合并
成更大的构件。
（3）需求评审
组织一个由不同代表（如分析人员、客户、设计人员、测试人员）组成的小组，对架构
需求及相关构件进行仔细的审查。审查的主要内容包括所获取的需求是否真实反映了用户的
要求，类的分组是否合理，构件合并是否合理等。
必要时，可以在“需求获取—标识构件—需求评审”之间进行迭代。
2．架构设计
架构需求用来激发和调整设计决策，不同的视图被用来表达与质量目标有关的信息。架
构设计是一个迭代过程，如果要开发的系统能够从已有的系统中导出大部分，则可以使用已
有系统的设计过程。软件架构设计过程如图 6-11 所示。
（1）提出软件架构模型
在建立架构的初期，选择一个合适的架构风格是首要的。在这个风格基础上，开发人员
通过架构模型，可以获得关于架构属性的理解。此时，虽然这个模型是理想化的（其中的某
些部分可能错误地表示了应用的特征），但是，该模型为将来的实现和演化过程建立了目标。
（2）把已标识的构件映射到软件架构中
把在架构需求阶段已标识的构件映射到架构中，将产生一个中间结构，这个中间结构只
包含那些能明确适合架构模型的构件。
（3）分析构件之间的相互作用
为了把所有已标识的构件集成到架构中，必须认真分析这些构件的相互作用和关系。
（4）产生软件架构
一旦决定了关键的构件之间的关系和相互作用，就可以在第 2 阶段得到的中间架构的
基础上进行细化。
（5）设计评审
一旦设计了软件架构，我们必须邀请独立于系统开发的外部人员对架构进行评审。
3．架构文档化
绝大多数的架构都是抽象的，由一些概念上的构件组成。例如，层的概念在任何程序设
计语言中都不存在。因此，要让系统分析师和程序员去实现架构，还必须得把架构进行文档
化。文档是在系统演化的每一个阶段，系统设计与开发人员的通信媒介，是为验证架构设计
和提炼或修改这些设计（必要时）所执行预先分析的基础。
架构文档化过程的主要输出结果是架构需求规格说明和测试架构需求的质量设计说明
书这两个文档。生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协
约。
软件架构的文档要求与软件开发项目中的其他文档是类似的。文档的完整性和质量是软
件架构成功的关键因素。文档要从使用者的角度进行编写，必须分发给所有与系统有关的开
发人员，且必须保证开发者手上的文档是最新的。
4．架构复审
从图 5-8 中我们可以看出，架构设计、文档化和复审是一个迭代过程。从这个方面来
说，在一个主版本的软件架构分析之后，要安排一次由外部人员（用户代表和领域专家）参
加的复审。
复审的目的是标识潜在的风险，以及早发现架构设计中的缺陷和错误，包括架构能否满
足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达
是否明确、构件的设计是否满足功能与性能的要求，等等。
由外部人员进行复审的目的是保证架构的设计能够公正地进行检验，使组织的管理者能
够决定正式实现架构。
5．架构实现
所谓“实现”就是要用实体来显示出一个软件架构，即要符合架构所描述的结构性设计
决策，分割成规定的构件，按规定方式互相交互。架构的实现过程如图 6-12 所示。
图 6-12 中的虚框部分是架构的实现过程。整个实现过程是以复审后的文档化的架构说
明书为基础的，每个构件必须满足软件架构中说明的对其他构件的责任。这些决定即实现的
约束是在系统级或项目范围内做出的，每个构件上工作的实现者是看不见的。
在架构说明书中，已经定义了系统中构件与构件之间的关系。因为在架构层次上，构件
接口约束对外唯一地代表了构件，所以可以从构件库中查找符合接口约束的构件，必要时开
发新的满足要求的构件。
然后，按照设计提供的结构，通过组装支持工具把这些构件的实现体组装起来，完成整
个软件系统的连接与合成。
最后一步是测试，包括单个构件的功能性测试和被组装应用的整体功能和性能测试。
6．架构演化
在构件开发过程中，最终用户的需求可能还有变动。在软件开发完毕，正常运行后，由
一个单位移植到另一个单位，需求也会发生变化。在这两种情况下，就必须相应地修改软件
架构，以适应新的软件需求。架构演化过程如图 6-13 所示。架构演化是使用系统演化步骤
去修改应用，以满足新的需求。主要包括以下七个步骤：
（1）需求变动归类首先必须对用户需求的变化进行归类，使变化的需求与已有构件对
应。对找不到对应构件的变动，也要做好标记，在后续工作中，将创建新的构件，以对应这
部分变化的需求。
（2）制订架构演化计划在改变原有结构之前，开发组织必须制订一个周密的架构演化
计划，作为后续演化开发工作的指南。
（3）修改、增加或删除构件在演化计划的基础上，开发人员可根据在第一步得到的需
求变动的归类情况，决定是否修改或删除存在的构件、增加新构件。最后，对修改和增加的
构件进行功能性测试。
（4）更新构件的相互作用随着构件的增加、删除和修改，构件之间的控制流必须得到
更新。
（5）构件组装与测试通过组装支持工具把这些构件的实现体组装起来，完成整个软件
系统的连接与合成，形成新的架构。然后对组装后的系统的整体功能和性能进行测试。
（6）技术评审对以上步骤进行确认，进行技术评审。评审组装后的架构是否反映需求
变动，符合用户需求。如果不符合，则需要在第 2 到第 6 步之间进行迭代。
（7）产生演化后的架构在原来系统上所作的所有修改必须集成到原来的架构中，完成
一次演化过程。