软件架构评审报告：系统评估与改进

一、软件架构评估

软件架构评估是在对架构分析、评估的基础上，对架构策略的选取进行决策。它也可以灵活地运用于对软件架构进行评审等工作中。

二、软件架构评估的方法

业界已开发出多种软件架构评估的方法，按基于的技术手段来看，可以分为三类：基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。以属性作为架构评估的核心概念。

1. 基于调查问卷或检查表的方式：该方式的关键是要设计好问卷或检查表，它充分利用系统相关人员的经验和知识，获得对架构的评估。其缺点是在很大程度上依赖于评估人员的主观推断。
2. 基于场景的方式：基于场景的方式由 SEI 首先提出并应用在架构权衡分析法（Architecture Tradeoff Analysis Method，ATAM）和软件架构分析方法（Software Architecture Analysis Method，SAAM）中。它是通过分析软件架构对场景（也就是对系统的使用或修改活动）的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
3. 基于度量的方式：它是建立在软件架构度量的基础上的，涉及三个基本活动，首先需要建立质量属性和度量之间的映射原则，即确定怎样从度量结果推出系统具有什么样的质量属性；然后从软件架构文档中获取度量信息；最后根据映射原则分析推导出系统的质量属性。它能提供更为客观和量化的质量评估，但它对评估人员及其使用的技术有较高
   的要求。ATAM 中也使用了度量的思想（度量效用）。

三、软件架构评估的质量属性

1. 性能是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。（优先级队列、资源调度）
2. 可用性是系统能够正常运行的时间比例。(通过用两次故障之间的时间长度或出现故障时系统能够恢复的速度来表示)（冗余、心跳线（ping/echo））
3. 可靠性是指软件系统在应用或错误面前，在意外或错误使用的情况下维持软件系统功能特性的基本能力。（冗余、心跳线）
4. 健壮性是指在处理或环境中，系统能够承受压力或变更的能力。
5. 安全性是指系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。（追踪审计）
6. 可修改性是指能够快速地以较高的性能价格比对系统进行变更的能力。（包含四个方面：可维护性（maintainability）、可扩展性（extendibility），结构重组（reassemble）、可移植性（portability））
7. 可变性是指体系结构经扩充或变更成为新体系结构的能力。
8. 易用性是衡量用户使用一个软件产品完成指定任务的难易程度。
9. 可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。（信息隐蔽）
10. 功能性是系统所能完成所期望工作的能力。
11. 互操作性是指系统与外界或系统与系统之间的相互作用能力。

四、关键步骤

敏感点是实现一个特定质量属性的关键特征，该特征为一个或多个软件构件所共有。系统权衡点会影响一个或多个属性，并对于多个属性来说都是敏感点。

1. 风险点: 架构设计中潜在的、存在问题的架构决策所带来的隐患。（业务逻辑不明确的地方）
2. 非风险点：非隐患
3. 敏感点: 为了实现某种特定的质量属性，一个或多个构件所具有的特征；（修改影响结果）
4. 权衡点: 影响多个质量属性的特征，是多个质量属性的敏感点（如对两个质量属性特征产生相反的影响，一个好一个坏）（安全与性能）

通常采用效用树对质量属性的描述进行刻画与排序。在评估过程中，权衡点是一个会影响多个质量属性的架构设计决策。

五、软件架构评估-基于场景的评估 SAAM

最初用于分析架构可修改性，后扩展到其他质量属性。

场景：问题描述/需求说明/架构描述。

分析过程：场景开发/架构描述/单个场景评估/场景交互/总体评估。

先评估单个, 再评估多个相互作用。

六、架构权衡分析法ATAM

在SAAM的基础上发展起来的，主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和这种。ATAM 方法不但能够揭示架构如何满足特定的质量需求（例如，性能和可修改性），而且还提供了分析这些质量需求之间交互作用的方法。使用 ATAM 方法评价一个软件架构的目的是理解架构设计满足系统质量需求的结果。该框架主要关注系统的需求说明。

场景包括：场景和需求收集、架构视图和场景实现、属性模型构造和分析、属性模型折中。整个评估过程强调以属性作为架构评估的核心概念。

评估过程：

七、产品线及系统演化

软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。
包含的技术: 软件架构/领域工程/DSSA

1. 特定领域软件架构(DSSA)
2. 过程模型

1. 双生命周期模型：

1. SEI模型

1. 三生命周期模型

1. 组织结构

1. 建立方式

八、架构复用

软件构件是软件系统中具有一定意义的、相对独立的可重用单元。与对象相比，构件可以基于对象实现，也可以不作为对象实现。构件需要在容器中管理并获取容器提供的服务；客户程序可以在运行状态下利用接口动态确定构件所支持的功能并调用。

面向构件的编程需要下列基本的支持：多态性（可替代性）、模块封装性（高层次信息的隐藏）、后期的绑定和装载（部署独立性）、安全性（类型和模块安全性）。

构件组装成软件系统的过程可以分为3个层次: 定制/集成/拓展

1. 商用构件标准规范 CORBA

三个层次：

1. 对象请求代理(ORB): 最底层, 规定了分布对象的定义（接口）和语言映射，实现对象间的通信和互操作，是分布对象系统中的“软总线”.
2. 公共对象服务: 提供诸如并发服务、名字服务、事务（交易）服务、安全服务等各种各样的服务.
3. 公共设施: 最上层, 定义了构件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则.

四种构件

1. 实体（Entity） 构件需要长期持久化并主要用于事务性行为，由容器管理其持久化。
2. 加工（Process） 构件同样需要容器管理其持久化，但没有客户端可访问的主键。
3. 会话（Session） 构件不需要容器管理其持久化，其状态信息必须由构件自己管理。负责完成服务端和客户端的交互。
4. 服务（Service） 构件是无状态的。

构件模型

1. 伺服对象（Servant）：CORBA对象的真正实现，负责完成客户端请求。
2. 对象适配器（Object Adapter）：用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。
3. 对象请求代理（Object Request Broker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。

2. EJB/J2EE
支持的5种构件模型：Applet、Servlet、JSP、EJB、Application Client。
其中,EJB中的BEAN分三种:

1. session bean会话bean: 负责维护一个短暂的会话；
2. entity bean 实体bean:负责维护一行稳固持久的数据；
3. message-driven bean 消息驱动bean:异步接受消息。

无状态的bean没有成员变量，用单例模式 ；有状态的bean有成员变量，非线程安全，适合用prototype原型模式。

3. 微软的 COM/DCOM/COM+

4. 软件重用

软件重用分垂直式重用与水平式重用，垂直式重用是指局限于某一垂直领域的重用，如只在电力系统中用到的构件；而水平式重用是指通用领域的重用，如标准函数库，任何软件都能用，所以是水平式重用。

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删