系统架构师（九）软件架构设计（二）
架构设计
软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。需要注意的是，软件架构设计与系统需求是直交的，两者并无必然联系。
- 软件架构设计能够满足系统的性能、安全性、可维护性等品质；
- 软件架构设计能够帮助项目干系人（Stakeholder）更好地理解软件结构：
- 软件架构设计能够有效地管理系统的复杂性，并降低系统维护费用；
- 软件架构设计对系统开发具有指导性：
- 软件架构设计为系统复用奠定的基础；
- 软件架构设计能够支持冲突分析。
1．演变交付生命周期
在生命周期模型中，架构设计就是从初步的需求分析开始逐步进行循环迭代。即：一方面在了解系统需求前，不能开始设计架构；另一方面，刚开始进行设计架构时并不需要等到全部需求都收集到。
2．属性驱动设计法
ADD是一种定义软件架构的方法，该方法将分解过程建立在软件必须满足的质量属性之上。ADD 的输入为：功能需求（一般表示为用例）、限制条件和质量需求（一组特定于系统的质量场景）。
3．按架构组织开发团队
每个模块都构成自己的小领域（专门知识或专门技术），并与其他模块的接口清晰，不同的模块分到不同的开发小组中，减少沟通成本
4．开发骨架系统
以架构为指导，开发一个可运行的原型（骨架系统）；在其上进行增量开发，直到软件开发完成。
5．利用商用构件进行开发
例如使用 J2EE/EJB 进行开发面向对象的分布式系统。
软件架构文档化
记录软件架构的活动就是架构编档过程，也就是架构的文档化。它包含两个方面：一是过程，编档过程能促使架构设计师进一步思考，使得架构更加完善；二是结果，描述架构的文档将作为架构开发的成果，供项目关系人使用
1．架构文档的使用者
架构的主要用途是充当项目关系人之间进行交流的工具，文档则促进了这种交流
2．合理的编档规则
（1）从读者的角度编写文档。
（2）避免出现不必要的重复。
（3）避免歧义。
（4）使用标准结构。
（5）记录基本原理。
（6）使文档保持更新，但更新频率不要过高。
（7）针对目标的适宜性对文档进行评审。
3．视图编档
视图的概念为架构设计师提供了进行软件架构编档的基本原则。架构文档化就是将相关视图编成文档，并补充多个视图的关联关系。
- 视图概述：对系统进行概括性的描述，包含视图的主要元素和元素间的关系。主要表示可用多个形式：图形、表格、文本，通常用图形形式，使用 UML 语言来描述。
- 元素目录：对主要表示中所描述的元素及其关系进行详细描述，包括：元素及属性、关系及其属性、元素接口、元素行为。
- 上下文图：用图形展示系统如何与其环境相关。
- 可变性指南：描述架构的可变化点，如各系统要做出选择的选项、做出选择的时间。
- 架构背景：为架构的合理性提供足够的、令人信服的论据。包括：基本原理、分析结果及设计中所反映的假定。
- 术语表：对文档中每个术语进行简要说明。
- 其他信息：描述不属于架构方面的必要信息，如管理信息（创作者、配置控制数据及变更历史）。
4．跨视图文档：对文档进行一个整体的“打包”工作
5．使用 UML：在视图文档的组织结构中，UML 主要用于表示元素或元素组的行为。
6．软件架构重构：反向工程之一，用于文档丢失时
由以下活动以迭代方式进行：
（1）信息提取（View Extraction）。可以使用各种工具进行信息提取，如解析器、语法分析器等；
（2）数据库构造（Database Construction）：将提取的信息转化为标准的形式，并置于数据库中。
（3）视图融合（View Fusion）：将数据库中的信息组合在一起，生成该架构的一个内聚的视图。
（4）重构（Reconstruction）：构建数据抽象和各种表示以生成架构表示，主要由两个活动组成：可视化和交互、模式定义和识别。最后生成需要的架构文档（Documentation）。
架构描述语言：
- Aesop：支持体系结构风格的应用；
- MetaH：为设计者提供了关于实时电子控制软件系统的设计指导；
- C2：支持基于消息传递风格的用户界面系统的描述；
- Rapide：支持体系结构设计的模拟并提供了分析模拟结果的工具；
- SADL：提供了关于体系结构加细的形式化基础；
- Unicon：支持异构的构件和连接类型并提供了关于体系结构的高层编译器；
- Wright：支持体系结构构件之间交互的说明分析；
架构描述语言（ADL） 是一种为明确说明软件系统的概念架构和对这些概念架构建模提供功能的语言。ADL主要包括以下组成部分：组件、组件接口、连接件和架构配置。ADL对连接件的重视成为区分ADL和其他建模语言的重要特征之一。
软件架构评估
软件架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它也可以灵活地运用于对软件架构进行评审等工作中。
评估方法所关注的质量属性：
- 性能： 指系统的响应能力
代表参数：响应时间、吞吐量
设计策略：优先级队列、资源调度 - 可用性： 系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
代表参数：故障间隔时间
设计策略：冗余、心跳线、Ping/Echo、选举 - 安全性： 指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
设计策略：追踪审计、限制访问 - 可修改性： 指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。
主要策略：运行时注册、接口-实现分离、信息隐藏 - 可靠性：是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。主要考虑两个方面：容错、健壮性。
代表参数：MTTF、MTBF
设计策略：冗余、心跳线 - 功能性：是系统所能完成所期望的工作的能力，一项任务的完成需要系统中许多或大多数构件的相互协作。
- 可变性：是指体系结构经扩充或变更而成为新体系结构的能力。
- 互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。
记录-回放主要提高系统的可测试性
质量评估的概念
- 风险点：指架构设计中潜在的、存在问题，给架构决策所带来的隐患。
- 敏感点：是为了实现某种特定的质量属性，一个或多个构件所具有的特性。
- 权衡点：是影响多个质量属性的特性，是多个质量属性的敏感点。
- 非风险点：用户提出的XX要求，是可以接受的。
软件架构评估的方法
（1）基于调查问卷或检查表的方式：其缺点是在很大程度上依赖于评估人员的主观推断。
（2）基于场景的方式： 通过分析软件架构对场景（也就是对系统的使用或修改活动）的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
- 软件架构分析法（SAAM）：最初用于分析架构的可修改性，后扩展到其它质量属性。
- SAAM的过程包括五个步骤，即场景开发、体系结构描述、单个场景评估、场景交互和总体评估。
- SAAM的主要输入问题是问题描述、需求声明和体系结构描述。
- 架构权衡分析法（ATAM）：主要针对性能、实用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。主要关注系统的需求说明，强调以属性作为架构评估的核心概念，通常采用效用树对质量属性的描述进行刻画与排序。
- 第一阶段：场景和需求收集
- 第二阶段：描述架构视图和场景实现；
- 第三阶段：属性模型构造和分析；特定属性分析（优秀的单一理论）
- 第四阶段：折中；
- 成本效益分析法（CBAM）：CBAM 在 ATAM 结束时开始
（3）基于度量的方式：它是建立在软件架构度量的基础上的，能提供更为客观和量化的质量评估，但它对评估人员及其使用的技术有较高的要求。ATAM 中也使用了度量的思想（度量效用）。
- 首先需要建立质量属性和度量之间的映射原则，即确定怎样从度量结果推出系统具有什么样的质量属性；
- 然后从软件架构文档中获取度量信息；
- 最后根据映射原则分析推导出系统的质量属性。
构件及其复用
构件的定义：软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。
构件组装成系统的过程：定制、集成、扩展
构件的特性：
- 独立部署单元
- 作为第三方的组装单元
- 没有（外部的）可见状态。
- 一个构件可以包含多个类元素，一个类元素只能属于一个构件
面向构件的编程（COP）关注于如何支持建立面向构件的解决方案。基于一般OOP风格，面向构件的编程需要下列基本的支持：
- 多态性（可替代性）
- 模块封装性（高层次信息的隐藏）
- 后期的绑定和装载（部署独立性）
- 安全性（类型和模块安全性）。
CORBA（公共对象请求代理架构）
- 伺服对象（Servant）：CORBA对象的真正实现，负责完成客户端请求。
- 对象适配器（Object Adapter）：用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。
- 对象请求代理（Object Request Broker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。
基于构件的开发模型
基于构件的开发模型： 利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化形的，开发过程是迭代的。基于构件的开发模型由软件的需求分析定义、体系结构设计、构件库建立、应用软件构建以及测试和发布5个阶段组成。
在基于构件的开发中，构件包含并扩展了模块化程序设计中子程序、面向对象系统中对象或类和系统模型中包的思想，它是系统设计、实现和维护的基础。构件定义为通过接口访问服务的一个独立可交付的功能单元。
在基于构件的软件开发中，逻辑构件模型用功能包描述系统的抽象设计，用接口描述每个服务集合，以及功能之间如何交互以满足用户需求，它作为系统的设计蓝图以保证系统提供适当的功能。物理构件模型用技术设施产品、硬件分布和拓扑结构，以及用于绑定的网络和通信协议描述系统的物理设计，这种架构用于了解系统的性能、吞吐率等许多非功能性属性。
产品线及系统演化
软件产品线
指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。
围绕核心资产库进行管理、复用、集成新的系统。核心资产库包括软件架构及其可剪裁的元素，更广泛地，它还包括设计方案及其文档、用户手册、项目管理的历史记录（如预算和进度）、软件测试计划和测试用例。
可复用的资产：
- 需求
- 架构设计
- 元素
- 建模与分析
- 测试
- 项目规划
- 过程、 方法和工具
- 人员
- 样本系统
- 缺陷消除
基于产品线的架构
软件产品线架构是针对一系列产品而设计的通用架构，并在此基础上，进一步将系列产品共用的模块事先实现，供直接重用；将架构用框架的形式予以实现，供定制使用。这就是通常所说的“平台”。
（1）产品线架构必须考虑一系列明确许可的变化；
（2）产品线架构一定要文档化；
（3）产品线架构必须提供“产品创建者指南”（开发指南），描述架构的实例化过程。
产品线的开发模型
（1）“ 前瞻性 ” 产品线： 利用在应用领域的经验、对市场和技术发展趋势的了解及商业判断力等进行产品线设计，它反映了企业的战略决策。通常是 自上而下地采用产品线方法。
（2）“ 反应性 ” 模型： 企业根据以前的产品构建产品家族，并随着新产品的开发，扩展架构和设计方案，它的核心资产库是根据“已经证明”为共有、而非“预先计划”为共有的元素构建的。通常是 自下而上地采用产品线方法。
一旦确定了产品线，就进入其演变阶段，它是产品线不断向前的发展过程
特定领域软件架构(DSSA)
架构的本质在于其抽象性。它包括两个方面的抽象：业务抽象和技术抽象。其中业务抽象面向特定的应用领域。
特定领域软件架构（Domain Specific Software Architecture，DSSA）可以看做开发产品线的一个方法（或理论），它的目标就是支持在一个特定领域中有多个应用的生成。DSSA以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构。
基本活动：
- 领域分析：建立领域模型，领域模型描述领域中系统之间共同的需求，即领域需求；
- 领域设计：获得DSSA，DSSA描述领域模型中表示需求的解决方案；
- 领域实现：依据领域模型和DSSA开发和组织可重用信息，并对基础软件架构进行实现。
DSSA人员角色：
- 领域分析者：控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中；
- 领域设计者：根据领域模型和现有系统开发出DSSA，并对DSSA的准确性和一致性进行验证。
- 领域专家：提供关于领域中系统的需求规约和实现的知识。
从功能覆盖的范围角度理解 DSSA 中领域的含义有两种方法：
（1）垂直域。 定义了一个特定的系统族，导出在该领域中可作为系统的可行解决方案的一个通用软件架构。
（2）水平域。 定义了在多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统（族）的特定部分功能。
三层次模型：
- 领域开发环境：领域架构师
- 领域特定的应用开发环境：应用工程师
- 应用执行环境：操作员
基于架构的软件开发方法
基于架构的软件设计（ABSD）
ABSD方法是架构驱动，即强调由业务、质量和功能需求的组合驱动架构设计。很好的支持软件重用。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。
使用ABSD方法，设计活动可以从项目总体功能框架明确开始，这意味着需求获取和分析还没有完成就开始了软件设计。
有三个基础：
- 功能分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。
- 通过选择架构风格来实现质量和业务需求。
- 软件模板的使用。软件模板利用了一些软件系统的结构。
开发过程
ABSD模型把整个软件过程划分为：架构需求、设计、文档化、复审、实现、演化
- 架构复审活动的目标是标识潜在的风险，及早发现架构设计中的缺陷和错误；
- 架构演化活动针对用户的需求变化，修改应用架构，满足新的需求。
架构需求过程与架构设计过程
架构实现过程与架构演化过程
所谓实现就是要用实体来显示出一个软件架构，即要符合架构所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。
