软件架构设计

 

事实上，经过从上面三个方面审视架构，我们已经建立了一个完整的而且比较良好的架
构。但我们还需要从第四个方面在更高的层次审视我们的架构，需要考虑的又一个问题就是
软件的复用。复用可以大大降低后期成本，提高整个软件系统的可升级性与可维护性。我们
可以考虑哪些结构可以使用已经存在的可复用结构和产品，某些结构可以利用 GoF 的设计模
式设计可复用的构件已备后期使用。还需要根据需求分析得出的易变点仔细设计产品结构，
确保后期的变化不至于对产品带来太大的影响。而复用的一个重要的手段，就是面向构件的
方法。
1，软件复用
软件复用是指重复使用“为了复用目的而设计的软件”的过程。在过去的开发实践中，
我们也可能会重复使用“并非为了复用目的而设计的软件”的过程，或者在一个应用系统的
不同版本间重复使用代码的过程，这两类行为都不属于严格意义上的软件复用。
通过软件复用，在应用系统开发中可以充分地利用已有的开发成果，消除了包括分析、
设计、编码、测试等在内的许多重复劳动，从而提高了软件开发的效率，同时，通过复用高
质量的已有开发成果，避免了重新开发可能引入的错误，从而提高了软件的质量。在基于复
用的软件开发中，为复用而开发的软件架构本身就可以作为一种大粒度的、抽象级别较高的
软件构件进行复用，而且软件架构还为构件的组装提供了基础和上下文，对于成功的复用具
有非常重要的意义。
软件架构研究如何快速、可靠地用可复用构件构造系统的方式，着眼于软件系统自身的
整体结构和构件间的互联。其中主要包括：软件架构原理和风格，软件架构的描述和规范，
特定领域软件架构，构件如何向软件构架的集成机制等。
2，面向构件的方法简述
构件也称为组件，面向构件的方法包含了许多关键理论，这些关键理论解决了当今许多
备受挑剔的软件问题，这些理论包括：
构件基础设施
软件模式
软件架构
基于构件的软件开发
构件可以理解为面向对象软件技术的一种变体，它有四点原则区别于其它思想，封装、
多态、后期绑定、安全。从这个角度来说，它和面向对象是类似的。不过它取消了对于继承
的强调。
在面向构件的思想里，认为继承是个紧耦合的、白盒的关系，它对大多数打包和复用来
说都是不合适的。构件通过直接调用其它对象或构件来实现功能的复用，而不是使用继承来
实现它，事实上，在我们后面的讨论中，也会提到面向对象的方法中还是要优先使用组合而
不是继承，但在构件方法中则完全摒弃了继承而是调用，在构件术语里，这些调用称作“代
理”（delegation）。
实现构件技术关键是需要一个规范，这个规范应该定义封装标准，或者说是构件设计的
公共结构。理想状态这个规范应该是在行业以至全球范围内的标准，这样构建就可以在系统、
企业乃至整个软件行业中被广泛复用。构件利用组装来创建系统，在组装的过程中，可以把
多个构件结合在一起创建一个比较大的实体，如果构件之间能够匹配用户的请求和服务的规
范，它们就能进行交互而不需要额外的代码。
3，面向构件的软件模式
面向构件技术的特色在于：迅速、灵活、简洁，面向构件技术之于软件业的意义正如由
生产流水线之于工业制造，是软件业发展的必然趋势。软件业发展到今天，已经不是那种个
人花费一段时间即可完成的小软件。软件越来越复杂，时间越来越短，软件代码也从几百行
到现在的上百万行。把这些代码分解成一些构件完成，可以减少软件系统中的变化因子。
1）面向构件方法模式
面向构件技术的思想基础在软件复用，技术基础是根据软件复用思想设计的众多构件。
面向构件将软件系统开发的重心移向如何把应用系统分解成稳定、灵活、可重用的构件和如
何利用已有构件库组装出随需而变的应用软件。
基于面向构件的架构可以描述为：系统=框架+构件+组建。框架是所有构件的支撑框架;
每个构件实现系统的每个具体功能;组建，可以视为构件的插入顺序，不同构件的组成顺序不
同，其实现的整体功能也就不同。
面向构件技术将把软件开发分成几种：框架开发设计、构件开发设计、组装，如果用现
代的工业生产做比喻，框架设计就是基本的生产机器的开发研究，构件开发就是零件的生产，
组装就是把零件组装成汽车、飞机等等各种产品。
2）面向构件开发的不足之处
（1）系统资源耗费
从软件性能角度看，用面向构件技术开发的软件并不是最佳的。除了有比较大的代码冗
余外，因为它的灵活性在很大程度上是以空间和时间等为代价实现的。
（2）面向构件开发的风险
从细节来看，构件将构件的实现细节完全封装，如果没有好的文档支持，有可能导致构
件的使用结果不是使用者预期的。比如，构件使用者对某构件的出错机制认识不够
3）开放式系统技术
专用软件是由单个供应商生产的不符合统一标准的产品。这些单个供应商通过版本更换
来控制软件的形式与功能。但是谁这系统越来越复杂，当一个系统建立起来以后，往往更倾
向于依赖于通用的商业软件，这种依赖往往成为内部软件复用的非常有效的形式。正是这种
状态，我们需要讨论一下开放式系统技术这个问题。
商业软件成为复用的有效形式，主要原因是规模经济的作用，通用的商业软件的质量，
往往超过终端用户自主开发能力。
商业软件也可以在某个领域内实现专有，也就是提供应用程序接口（API）为应用软件
提供服务。当软件不断升级的过程中，这些接口的复杂性可能超出用户的需要，这就需要有
复杂性的控制。
一个解决方案就是实现开放式系统技术，开放式系统技术与专有技术有根本的不同。在
开放式系统技术中，由供应商组织来开发独立于专有实现的规范，所有的供应商实现的接口
都严格的一致，并且规定了统一的术语，这样就可以是软件的生命周期得以延长，这种开放
式系统技术特别适合于面向对象的方法。
为了使商业技术能适应各种应用需求，对软件开发和安装就有一定的要求，这种要求称
之为配置（profiling），适当的配置软件的嵌入也称为开放是软件的一个特点。
从架构的角度来看，不少系统结构具有大量的一对一接口和复杂的相互连接关系，这种
模型被称之为“烟囱”模型，当系统规模增大以后，这种关系会以平方律的速度增加，复杂
性的增加会带来相当多的问题，尤其是升级和修改越来越难以进行，而系统的可扩展性恰恰
是开发成本的重要部分。
为此，我们可以建立一个称之为对象管理器的层，用于统一协调各个对象的沟通，从可
维护性角度这是一个比较好的结构，但是在某些特别强调效率的点可以避开它。系统的架构
的一个重要原则就是对软件接口定义一个已经规划的定义，为系统集成方案提供更高的统一
性，软件的子系统部分要由应用程序接口来定义。这样，就削弱了模块之间的依赖性，这样
的系统就比较容易扩展和维护，并且支持大规模的集成。
经过从四个方面审视我们的架构，经过分析、权衡、设计和部分编码，我们就可以得到
一个稳固的架构。这个架构经过经过评审，就可以作为后期开发的基础架构.

综上所述，我们就可以比较条理化的建立软件架构设计的流程了。典型软件架构设计的
流程如下图所示。
一、业务架构概念
在构建软件架构之前，架构师需要仔细研究如下几个问题：
系统是为什么目的而构建的？
系统投运后服务于哪些利益相关者的利益？
什么角色在什么时候操作或者维护系统？
业务系统实现方法是怎样的？
整个业务系统是如何依靠系统而运转的？
为了回答这些问题，需要仔细阅读需求分析文档中的业务模型建立、问题域及其解决构
思、产品模型的构思等等前期文档，站在系统架构的角度，全面清晰的建立业务模型，包括
组织结构关系、业务功能、业务流程、业务信息交互方法、业务地理分布、业务规则和约束
条件。这个阶段的主要活动如下：
建立产品范围、目的、最终用户、业务背景等重要的初始信息。
建立完整的业务和系统的术语字典，确保项目相关人员理解上保持一致。
建立宏观层面业务的总体概念，明确总体流程、业务功能的边界、交互与协作方式，
建立系统的概念模型。
汇总业务总的组织结构与协作职能关系。
分析业务的组成节点，以及节点间交互、协同与信息的依赖关系。
分析业务节点的事件、消息，以及由此引发的状态转换关系。
汇总业务运行的基本数据模型，以便于跟踪信息的流动与格式转换。分析业务数据
的关联关系。
理解问题域以及系统需要解决的问题。
分析业务运作层面的基本业务规则与约束条件。
这个阶段的活动非常重要，架构师只有具备了这些相互关联的业务概念以后，才可能从
这些概念中抽取恰当的架构因素。
二、产品架构概念
在理解业务的基础上，我们需要进一步思考产品架构的概念，这个阶段从活动的层面看
实际上与建立业务架构概念是一样的，但是思维的重心转移到如下几个方面：
新系统投入运行以后，最高层面的业务会怎样运作？
新系统是如何解决原来工作系统的问题的？
新系统的投运，会对原来的组织结构划分发生什么样的影响？
由于新系统取代了原来的一些业务职能，业务节点的分布会发生怎样的变化？变化
后的节点间的信息又是怎样交换与依赖的？
变化后的业务事件传递又会发生怎样的变化？
新的系统加入以后，哪些业务流程将会发生重大变化？哪些不会发生变化？
业务的状态转换关系将会如何随着新系统地加入而改变？
业务的数据模型将会如何随着业务流程的变化而变化的？
新系统地加入，将会如何影响新的业务规则和约束？
从这些角度出发，我们会重新构建未来新系统投运以后的业务规则，相应的新规则也需
要建立，这就实现了业务过程的重构。
三、建立稳定的架构基线
在对业务领域与问题域有深刻的理解以后，我们需要继续研究如下一些问题：
这个复杂系统应该分成多少和哪些子系统？
子系统是如何分布在不同的业务节点或者物理节点上的？
这些分散的子系统将提供哪些接口？这些接口如何进行交互？
各个子系统需要交互哪些数据？
每个单独的子系统，所需要实现的功能有哪些？
整个系统对各个子系统有哪些功能、性能和质量上的要求？
“基线”这个词有两个意义：
这个阶段将会对整体架构策略做出重大的设计上的决策。一旦作出了这些决策，后
续开发没有重大情况不允许变动。
这个阶段完成的工作，本身就是架构阶段的重要成果，需要广泛认同、集体遵守以
及具备强制的约束力。
尽管在后期的演变中，这样的基线实际上还会不断的精化和优化，但最初下功夫构建稳
定的架构基线是十分必要的。这个阶段的活动如下：
校验与确认前期所有的业务架构与产品架构的信息，必要的时候补充相应的信息。
修订和增补术语字典，确保所有的相关人员对术语有相同的认知。
把整个系统功能进行拆分，并且分解到不同的运行节点上，构建不同的系统集和子
系统，在全局范围内划分接口与交互规则。
汇总系统/子系统接口信息，便于检索与浏览。
规划整个系统的通信链路、通信路径、通信网络等传输媒介。
把产品架构概念中的业务职能与系统功能相对应，从而确保满足业务要求。
分析系统/子系统在运行起动态协作需要交互的信息。
构建和模拟整个系统在业务环境下的动态特性，规划全系统内部状态变化过程、触
发的事件及约束条件。
详细汇总各个子系统间信息传递的过程、内容以及其它辅助信息。
根据初始的数据模型构建数据物理模型。
汇总质量上对系统的要求，并把这些质量要求细化分解，量化到各个子系统中去。
构建整个系统与子系统的构建和演化计划，在迭代过程中构建整体项目规划和初始
的迭代规划。
按固定时段预测技术的演化，汇总整个系统的应用技术及其演化。
分辨与汇总整个系统在不同阶段必须遵循的标准。
把业务约束映射到各个子系统，必要时附加 IT 业务约束。
四、子系统架构的设计与实现
通过上述各主要过程，我们已经实现了一个重要的总体架构基线。所有的子系统设计都
是在这个庞大的架构基线约束下展开，至此，首席架构师逐渐淡出，让位于子系统架构设计
师。子系统架构设计师的任务是继续分解、细化、设计各个子系统。在这个阶段，将会考虑
更加细节的问题，为后来的构件设计与单元设计作准备，我们需要考虑的问题如下：
规划给该子系统的功能是否可行？
在整个子系统的范围内，又能分解成什么子功能集？
在整个子系统的范围内，又能把哪些子功能合并到某些构件中去？
这些构件与子功能集是如何通过接口与子系统衔接的？
事实上子系统架构设计本身就是一个完整的系统设计，所区别的是视野集中到子系统的
范围内，这个阶段的活动如下：
校验与确认前期与该子系统相关的业务架构与产品架构的信息，必要的时候补充相
应的信息。
增补与本子系统相关的术语字典，确保所有的相关人员对术语有相同的认知。
把整个子系统功能进行拆分，并且分解到不同的构件节点上，构建不同的子功能集，
在子系统范围内划分接口与交互规则。
汇总子系统/构件接口信息，便于检索与浏览。
规划整个子系统的通信链路、通信路径、通信网络等传输媒介。
把产品架构概念中的子业务职能与构件功能相对应，从而确保满足业务要求。
分析子系统/构件在运行起动态协作需要交互的信息。
构建和模拟整个子系统在业务环境下的动态特性，规划子系统内部状态变化过程、
触发的事件及约束条件。
详细汇总各个构件间信息传递的过程、内容以及其它辅助信息。
根据初始的数据模型构建子系统相关的更详细的数据物理模型。
根据质量上对子系统的要求，并把这些质量要求细化分解，量化到各个构件中去。
构建整子系统的构建和演化计划，在迭代过程中构建子系统项目规划和更详细地的
迭代规划。
按固定时段预测技术的演化，汇总子系统的应用技术及其演化。
分辨与汇总子系统在不同阶段必须遵循的标准。
把业务约束映射到各个构件，必要时附加 IT 业务约束。
五、构件与实现单元的设计
进入构件设计阶段也就是进入了详细设计阶段。这个阶段主要的工作就是接口与功能设
计。在迭代模型下，这个阶段很大程度上是在迭代过程中完成的，由某个设计人员带领全体
开发团队进行分析和设计。
在这个过程中，我们应该考虑在小粒度架构中如何使产品需求变更不至于对产品质量造
成影响，还需要考虑业务概念模型与产品功能块有相应的追溯和回溯关系。这些问题，我们
将会在后面用适当的篇幅进行讨论。
小结：
大型复杂项目的成功依赖于合理的项目组织，这种组织概念包括人力资源的组织和产品
架构的组织两个方面。敏捷项目管理为这两种合理的组织提供了思维基础，为项目的成功提
供了保证。一个典型的例子是 20 世纪 90 年代加拿大空中交通系统项目（首席架构师：Philippe
Kruchten）。150 个程序员被组织到 6 个月的长周期迭代中。但是，即使在 6 个月的迭代中，
10～20 人的子系统，仍然把任务分解成一连串 6 个为期一个月的小迭代。正是这个项目的
实践成功，Philippe Kruchten 才成为 RUP 的首倡者。
敏捷过程的提出直接影响到架构设计的核心思维，正是因为敏捷过程的提出，才有了架
构驱动、弹性架构和骨架系统这些理念。也直接影响到需求分析方法、项目规划和估计方法
等一系列领域的新思维。甚至推动了业务敏捷以及与之相适应的基于服务的架构的提出。这
些观念的提出又更加推动了软件工程学向更高的层次发展。
下面我们将讨论几个专题，但讨论的时候希望研究一种思考问题的方法，从而为大家解
决更广阔的问题提供一个思维的平台。这些专题并不是独立存在，而是融合在本章所讨论的
各个阶段之中。再一次强调，方法和技术是会变化的，但优秀的思维方式是永恒的！