软件构架实践(第2版)学习笔记

一、软件、架构模式、参考模型、参考架构

1、对于软件架构定义有很多种，通用的定义是：某个软件或计算机系统的软件架构是该系统的一个或多个结构，他们由软件元素，这些元素的外部可见属性以及这些元素之间的关系组成。

这里所说的某个元素的“外部可见属性”是指其他元素对该元素所做的假设，如它所提供的服务、性能特征、错误处理、共享资源的使用，等等。

其他的定义包括：架构是一种高层设计。架构是系统的总体结构。架构是一个软件或系统的组件、组件之间的相互关系以及管理其设计和演变的原理和方针的结构。架构是组件和连接器。

2、架构模式是对元素和关系类型以及一组对其使用方式的限制的描述。

3、参考模型是一种考虑数据流的功能划分。

4、参考架构是映射到软件元素（它们相互协作，共同实现在参考模型中定义的功能）及元素之间数据流上的参考模型。

5、软件架构、架构模式、参考模型、参考架构之间的关系：

6、软件架构的重要性

   (1)、架构是涉众进行交流的手段。

   (2)、架构是早期设计决策的体现。

   (3)、架构是可传递、可重用的模型。

7、架构定义中指出系统由多种结构构成的，下面列出一些常见的结构。

软件结构	关系	适用环境
分解	是一个子模块；与之共享秘密	资源分配、项目结构化和规划；信息隐藏、封装；配置控制
使用	要求正确出现	设计子集；设计扩展
分层	要求正确的出现、使用服务、提供抽象	增量式开发；在“虚拟机”可移植性之上实现系统
类	是一个实例；共享访问方法	在面向对象的设计系统中，从一个公共的模版中产生快速的、相近的实现
客户机-服务器	与之通信；依赖于	分布式操作；关注点分离；性能分析；负载平衡
进程	与之并发运行、可能会与之并发运行；排除；优先于等	调度分析；性能分析
并发	在相同的逻辑线程上运行	确定存在资源争用，线程可以交叉、连接、被创建或被杀死的位置
共享数据	产生数据；使用数据	性能；数据完整性；可修改性
部署	分配给；移植到	性能、可用性、安全性分析
实现	存储在	配置控制、集成、活动
工作分配	分配到	项目管理、最佳利用专业技术、管理通用性

二、质量属性

系统从设计、实现到部署的整个过程中考虑质量属性的实现。质量属性包括下列三类：

（1）、系统的质量属性。（可用性、可修改性、性能、安全性、可测试性和易用性）

（2）、受架构影响的商业属性。（上市时间、成本和收益、所希望的系统生命期的长短、目标市场、推出计划、与老系统的集成）

（3）、与架构本身相关的一些质量属性。（概念完整性、正确性与完整性、可构建性）

六个质量属性的战术列表：

 

 

 

 

 

 

 

战术与架构模式的关系

Active Objcet设计模式将方法执行从方法调用中分离出来，以增强并发，并简化对驻留在其自身控制线程中的对象的同步访问。

该模式由6个元素组成：代理，它提供了允许客户对主动对象调用公共访问方法的接口；方法请求，它定义了用于执行主动对象的方法的一个接口；激活接口，它维持了挂起方法请求的一个缓冲器；调度程序，它决定接下来执行什么方法请求；附属，他定义可建模为主动对象的行为和状态；将来，它允许客户获得方法调用的结果。

该模式的动机就是增强并发性——这是一个性能目标。因此其主要目的就是实现“引入并发“性能战术。然而，还要注意该模式包含的其他战术。

●     信息隐藏（可修改性）。每个元素都选择了它将实现的责任，并将其实现隐藏在接口后面。

●     仲裁者（可修改性）。该代理充当着把变化缓冲到方法调用中的仲裁者。

●     绑定时间（可修改性）。主动对象模式假定对该对象的请求在运行时到达该对象。然而，并没有确定客户机与代理的绑定时间。

●     调度策略（性能）。调度程序实现一些调度策略。

对设计师来说，分析过程包括理解嵌入在实现中的所有战术；设计过程包括在关于哪些战术最和将实现系统期望的目标方面，做出一个明智的选择。

 

架构模式和样式

软件中架构模式与建筑物中的架构样式类似，它由几个将他们组合起来以维持架构完整性的关键特性和规则组成。架构模式由以下几个因素确定：

●     一组元素类型（如数据存储库或计算数学函数的组件）

●     指出其相互关系的元素的拓扑布局。

●     一组语义限制（如管道——过滤器样式中的过滤器是纯数据转化器——他们以增量形式将其输入流转换为输出流，但并不控制上游流或下游元素）。

●     一组交互机制（如子例程调用、事件——调阅者、黑板）、他们确定元素将如何通过允许的拓扑进行协调。

架构模式和战术之间是什么关系呢？正如已经说明的那样，我们把战术看作是设计的基本“构建块”，并根据该战术创建架构模式和策略。

三、设计架构

几乎在我们遇到的所有成功的面向对象系统中都具有但失败的系统中缺少的两个特性是：存在一个强大的构架构想，应用管理良好的迭代式增量开发周期。

功能、质量和商业需求的某个集合“塑造”了构架。我们把这些塑造需求称为“构架驱动因素”

。

构架设计必须按需求分析进行，但不需要在需求分析完成后在开始构架设计。实际上，在确定了关键的构架驱动因素后，就可以开始构架设计了。当设计了构架的足够多的部分后，就可以开始开发骨架系统了。该骨架系统在上面进行迭代开发（以及其在任何一个点交付的能力）的框架。组织结构对构架产生影响。

属性驱动的设计(ADD)是一个用于设计构架以满足质量需求和功能需求的方法。ADD把一组质量属性场景作为输入，并使用对质量属性实现和构架之间的关系的了解，对构架进行设计。

ADD步骤：

（1）       选择要分解的模块。

（2）       根据这些步骤对模块进行求精。

（3）       对需要进一步分解的每个模块重复上述步骤。

 

四、构架编档

构架编档是创建构架的最有价值的一步。即使构架非常完美，但如果没有人理解它，或主要的涉众误解了它，它也没有什么用处。如果您创建了一个非常强大的构架，那么，就必须用足够的细节明确地描述它，并以一种其他人可以快速找到所需要信息的方式对其进行组织。否则，构架不会有什么用处，您所付出努力就白费了。捕获构架信息的描述方式采用UML表示法。

 

五、软件构架重构

构架重构是一种解释、交互和迭代的过程，涉及许多活动；它不是自动进行的。它需要反向工程专家和设计师具备相关技能并投入精力，这在很大程度上是因为没有在源代码中清楚地表示构架构件。

软件构架重构由以下活动组成，这些活动以迭代的方式进行：

（1）       信息提取。

（2）       构造。

（3）       视图融合。

（4）       重构。

 

 

六、分析构架

构架评估的一些基本问题——原因、时间、成本、收益、技巧、计划内、计划外、前置条件以及结构。

每个基于构架的开发方法中都应该进行构架评估。

在生命周期中尽可能早的评估软件质量几乎总是经济高效的。

评估成本就是需要参与评估的人员所付出的时间。

成功评估应该具有如下属性：

（1）、表述清楚的构架目标和需求。

（2）、可控制的范围。

（3）、经济高效。

（4）、关键人员的可用性。

（5）、称职的评估小组。

（6）、可管理的期望。

 

ATAM一种进行构架评估的综合方法，ATAM是评估软件构架的一个健壮的方法。在该方法中，项目决策者和涉众要清晰地阐述一个准确的质量属性需求列表（以场景的方式），并说明与实现每个高优先场景相关的构架决策。然后，把这些决策确定为有风险决策或无风险决策，以找到构架中任何存在问题的地方。

ATAM不是需求评估。

ATAM不是代码评估。

ATAM不包括实际的系统测试。

ATAM不是一个准确的手段，但它识别了构架中可能存在风险的区域。这些风险包含在敏感点和权衡中。

ATAM活动的4个阶段：

在第0阶段（合作关系和准备）确定细节：人员名单，时间，地点；评估小组获取资料并进行初步了解分析。

第1阶段，评估阶段，决策者参与，小组开始信息收集与分析；耗时约1周。1～2周中断期，评估小组进一步以非正式方式了解构架。

第2阶段，评估阶段，涉众参与，分析继续；约2天。

第3阶段，后续阶段，生成最终报告，进行评估活动总结；1周。

评估阶段的步骤：

第1步：ATAM方法的表述。评估负责人向决策者表述ATAM方法，使大家理解其过程，了解角色布局。

第2步：商业动机的表述。决策者介绍系统商业动机、重要功能、各种限制（任何相关的技术、管理、经济和政治限制）、商业目标和上下文、主要的涉众、驱动因素等。

第3步：构架的表述。首席设计师或架构小组介绍构架，技术限制、所用模式等。

第4步：对构架方法进行分类。评估小组利用所有已知信息对构架方法进行分类。

第5步：生成质量属性效用树。生成质量属性效用树，捕获详细的需求信息，为每个场景分配一个级别，如（高，中），前者为重要度，后者为实现难易度，重点放在（高，高）的场景；此处场景具备刺激、环境、响应三要素就可以了。

第6步：分析构架方法。评估小组分析所有重要场景，设计师解释如何支持该场景，检查所用构架方法，分析风险点、权衡点、敏感点。

经过一段中断期，第2阶段开始，此时涉众开始参与；首先仍然需要一个对ATAM方法的介绍，并使涉众了解已有的成果。

第7步：集体讨论并确定场景的优先级。集体讨论并分析场景的优先级，以了解更广泛的涉众的想法；该过程可能产生新的场景；使用“有限票数法”投票确定每个场景的优先级——此处不考虑实现难度。

第8步：分析构架方法。分析新的高优先级的场景，构架师解释构架是怎么满足各场景的。

第9步：结果表述。总结评估结果，评估负责人展示该结果。

 

CBAM构架设计决策制定的定量方法

为了经济地制定决策，我们开发了一个对软件系统进行经济建模的方法，主要是对其构架进行分析。该方法即成本收益分析方法(CBAM)，它在ATAM上构建，用来对构架设计决策的成本和收益进行建模，是优化此类决策的一种手段。CBAM提供了对技术和经济问题以及构架决策的评估。

CBAM的思想就是构架策略（构架战术的集合）影响系统的质量属性，反过来这些质量属性又会为系统的涉众带来一些收益，我们把该收益称为“效用”。每个构架策略都为涉众提供了某一特定级别的效用。此外，每个构架策略都有成本，并需要花时间去部署。从此，CBAM可以协助涉众根据其投资回报（ROI）选择构架策略，投资回报是收益和成本的比。

CBAM是一种迭代式获取过程，它与决策分析框架结合在一起。它采用场景来表示各种质量属性。涉众通过获取效用—响应曲线来理解系统的效用如何随着质量属性的变化而变化，从而对决策进行分析。在达成一致的基础上，该方法允许涉众进行讨论，以在涉众之间进行澄清。设计决策的可跟踪性允许设计过程随着时间的推移而不断得到更新和改进。

1、  场景的变体

CBAM使用场景来表示和表达具体的质量属性。把场景结构分成3个部分：刺激（与系统交互）、环境（系统此时的状态）、响应（所导致的可度量的质量属性）。

2、  效用—响应曲线

最好情况的质量属性级别，最好指继续提高质量属性也不能带来效用的提升，此时效用值取100（如1秒）；

最坏情况的质量属性级别，最坏指如果质量属性低于该值，系统将毫无价值（如10秒）；

本场景（曲线表现的是某个场景）当前的响应与效用级别（当前是5秒，用户愿意付钱50）；期望的效用级别（如果能达到3秒，用户愿意支付80）确定每个属性的权重，构架师选择策略，考虑策略对每个属性的影响，计算获得的总收益与成本；

3、  场景的优先级

4、  构架策略

CBAM实现步骤：

步骤1、整理场景：根据商业目标确定优先级，选择优先级别最高的前1/3的场景。

步骤2、对场景进行求精：确定每个场景的最好、最坏、当前、期望情况的质量响应级别——此步仅处理响应级别，期望值有可能等于最好值。

步骤3、确定场景优先级：去掉优先级低的一半场景。

步骤4、为每个场景的当前级别和期望级别分配效用。

步骤5、为场景开发构架策略，并确定质量属性响应级别。

步骤6、使用内插法确定所期望的构架策略效用值。

步骤7、计算从某个构架策略中获取的总收益。

步骤8、根据受成本限制影响的ROI选择构架策略。

步骤9、运用直觉来确认所得到的结果。

 

七、软件产品线

基于构架的开发模式，即软件产品线，由于越来越多的组织发现采用产品线可以在成本、进度、质量方面实现数量级的改进，因此该方法日益受到青睐。

创建一个成功的产品线取决于软件工程、技术管理和组织管理的协调策略。

软件线实现需要考虑3件事情：

确定变化点

支持变化点

对产品线构架的适宜性进行评估

 

八、开发案例分析

本书中案例都是些难度大、实时性要求高、安全性要求高的系统开发案例。

空中交通管制：高可用性设计案例分析                  详见P113

飞行模拟：构架可集成案例分析                            详见P153

Nightingale系统：应用ATAM的案例分析        详见P243

NASA ECS项目：引用CBAM的案例分析              详见P267

万维网：可互操作性案例分析                                详见P277

CelsiusTech公司：产品线开发案例分析                 详见P315

J2EE/EJB：工业标准计算基础结构案例分析           详见P343

Luther构架：使用J2EE的移动应用案例分析         详见P365