目录
软件体系结构概述
软件体系结构的定义
bridging the gap between requirements and
implementations (David Garlan & Dewane Perry)
SEI软件体系结构讨论群定义如下:一个程序/系统构件的结构，它们之间的相互关系， 以及在设计和交付的整个过程中的原则和指导方针。
一般来说，软件体系结构定义需要考虑到系统中的构件及其它们之间的相互作用
软件体系结构包括构件(Component)、连接件(Connector)和约束(Constrain)或配置(Configuration)三大要素。
构件是指一个计算单元或者数据存储单元，可以是处理过程或数据元素。
构件是用于实现计算和状态的单元，可以工作在：客户端、服务器端、数据库、层等。
构件可简单可复杂.
连接件
连接件是体系结构的一个元素，它可以用于建模：构件之间的相互作用以及控制这些相互作用的规则.
配置
指构件和连接器组成的一个连接图，它用于描述软件体系结构的构成：
软件需求
需求的基本概念
宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。
“用户”（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（the end user）和“间接用户”（或称为关系人）。掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。
需求工程——所有与需求直接相关的活动通称为需求工程
需求开发的目的是通过调查与分析，获取用户需求并定义产品需求
需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。
需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。
需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。
需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。
需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
《用户需求说明书》与《产品需求规格说明书》的主要区别与联系
前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。
后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。
两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《产品需求规格说明书》来开发当前产品。
需求分析
分析方法大体有两类：“问答分析法”和“建模分析法”。后者技术性比较强，写出来有学术味，故大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用（保你一学就会），很有实用价值。
“问答分析法”比较适合于用户需求调查阶段
“建模分析法”比较适合于产品需求定义阶段
需求建模就是指用图形符号来表示、刻画需求。
建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。
好的需求规格说明书
正确——正确地反映用户的真实意图，《产品需求规格说明书》最重要的属性
清楚——让人易读易懂
无二义性——每个需求只有唯一的含义
一致——“一致”（Consistent）是指《产品需求规格说明书》中各个需求之间不会发生矛盾
必要——《产品需求规格说明书》中的各项需求对用户而言应当都是必要的
完备——（Complete）是指《产品需求规格说明书》中没有遗漏一些必要的需求
可实现
——《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的（Attainable）
可验证
——《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的（Verifiable）
确定优先级
阐述“做什么”而不是“怎么做”——《产品需求规格说明书》的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么做”是系统设计和实现阶段的事情
需求管理
需求确认（评审和承诺）——开发方和客户方共同对《产品需求规格说明书》进行评审，双方对需求达成共识后作出承诺。需求确认包含两个重要工作：“需求评审”和“需求承诺”
需求跟踪——目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求
正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处
需求变更控制——提出需求变更目的是希望产品更加符合用户的需求。项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价
如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。
如果需求变更带来的坏处大于好处，那么拒绝变更。
软件体系结构风格
定义
1)
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。
2)
体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
3)
体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统
4)
An architectural style defines a family of
systems in terms of a pattern of structural organization. More specifically, an
architectural style defines a vocabulary of components and connector types, and
a set of constraints on how they can be combined.
经典的体系结构风格
l
数据流风格: 批处理序列; 管道/过滤器。
l
调用/返回风格：主程序/子程序；面向对象风格；层次结构。
l
独立构件风格：进程通讯；事件系统。
l
虚拟机风格：解释器；基于规则的系统。
l
仓库风格：数据库系统；超文本系统；黑板系统。
l
过程控制环路
l
C/S风格
l
B/S风格
管道和过滤器
每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。
过滤器风格的连接件就象是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入
不变量：
过滤器虽然可以增量式地处理数据，但是它们是独立的
管道和过滤器的正确输出不依赖其顺序
实例：——编译器，功能程序，并行程序
数据抽象和面向对象组织
数据的表示方法和它们的相应操作被封装在一个抽象数据类型或对象中
这种风格的构件是对象或者说是抽象数据类型的实例
对象通过函数和过程的调用来进行交互
基于事件的隐式调用
构件不直接调用一个过程，而是触发或广播一个或多个事件
系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程。
这种风格的构件是一个模块，这些模块可以是一些过程，又可以是一些事件的集合。
不变量：事件的触发者并不知道哪些构件会被这些事件影响
实例：数据库管理系统，用户界面
分层系统
组织成一个层次结构
每一层都为上一层提供了相应的服务，并且接受下一层提供的服务
在分层系统的一些层次中构件实现了虚拟机的功能
实例：分层的通信协议
仓库系统
构件：中心数据结构（仓库）和一些独立构件的集合
仓库和在系统中很重要的外部构件之间的相互作用
实例：需要使用一些复杂表征的信号处理系统
过程控制环路
源自于控制理论中的模型框架，将事务处理看成输入、加工、输出、反馈、再输入的一个持续的过程模型。
通过持续性的加工处理过程将输入数据转换成既定属性的“产品”，在工控系统、供电、水利甚至可以推广到商务软件体现的管理模型中。
C2风格
通过连接件绑定在一起的按照一组规则运作的并行构件网络。系统组织规则入下：
系统中的构件和连接件都有一个顶部和一个底部；
构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；
一个连接件可以和任意数目的其它构件和连接件连接；
当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
特点
系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起
所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的
构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设
C/S风格
基于资源不对等，且为实现共享而提出来的，是20世纪90年代成熟起来的技术，C/S体系结构定义了工作站如何与服务器相连，以实现数据和应用分布到多个处理机上。体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络。
服务器
数据库安全性的要求；
数据库访问并发性的控制；
数据库前端的客户应用程序的全局数据完整性规则；
数据库的备份和恢复。
客户应用程序
提供用户与数据库交互的界面；
向数据库服务器提交用户请求并接收来自数据库服务器的信息；
利用客户应用程序对存在于客户端的数据执行应用逻辑要求
处理流程
优点
1)
C/S体系结构具有强大的数据操作和事务处理能力，
模型思想简单，易于人们理解和接受。
2)
系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小。
3)
在C/S体系结构中，系统中的功能构件充分隔离，客户应用程序的开发集中于数据的显示和分析，而数据库服务器的开发则集中于数据的管理，不必在每一个新的应用程序中都要对一个DBMS进行编码。将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。
缺点
1)
开发成本较高
2)
客户端程序设计复杂
3)
信息内容和形式单一
4)
用户界面风格不一，使用繁杂，不利于推广使用
5)
软件移植困难
6)
软件维护和升级困难
7)
新技术不能轻易应用
三层CS
数据库服务器——应用服务器——用户
处理流程
物理结构
三层优点：
1)
允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，能提高系统和软件的可维护性和可扩展性。
2)
允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
3)
应用的各层可以并行开发，可以选择各自最适合的开发语言。
4)
利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，为严格的安全管理奠定了坚实的基础。
5)
需注意
6)
三层C/S结构各层间的通信效率不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能。
7)
设计时必须慎重考虑三层间的通信方法、通信频率及数据量，这和提高各层的独立性一样是三层C/S结构的关键问题。
B/S风格
浏览器/服务器(B/S)风格就是上述三层应用结构的一种实现方式，其具体结构为：浏览器/Web服务器/数据库服务器。
优点
1)
基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。
2)
B/S体系结构还提供了异种机、异种网、异种应用服务器的联机、联网、统一服务的最现实的开放性基础。
缺点
1)
B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
2)
B/S体系结构的系统扩展能力差，安全性难以控制。
3)
采用B/S体系结构的应用系统，在数据查询等响应速度上，要远远低于C/S体系结构。
4)
B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用。//ajax一定程度上缓解了问题
UML
概述
概念：是一种由图形符号表达的建模语言，也就意味着它有属于自己的标准表达规则。它不是一种类似Java、C++的编程语言，而是一种分析设计语言，也就是一种建模语言。
用户视图：以用户的观点表示系统的目标，它是所有视图的核心，该视图描述系统的需求。
结构视图：表示系统的静态行为，描述系统的静态元素如包、类与对象，以及它们之间的关系。
行为视图：表示系统的动态行为，描述系统的组成元素如对象在系统运行时的交互关系。
实现视图：表示系统中逻辑元素的分布，描述系统中物理文件以及它们之间的关系。
环境视图：表示系统中物理元素的分布，描述系统中硬件设备以及它们之间的关系。
用户视图：用例图
结构视图：类图、对象图、包图 (UML2.0)、组合结构图 (UML2.0)
行为视图：时序图、通信图（UML1.0 协作图）、定时图 (UML2.0)、状态图、活动图、交互概览图 (UML2.0)
实现视图：组件图
环境视图：部署图
UML需求建模
用例建模：Use
Case Modeling是使用用例的方法来描述系统的功能需求的过程，用例建模促进并鼓励了用户参与，这是确保项目成功的关键因素之一。主要包括用例图(Use Case Diagram) +用例描述文档 (Use Case Specification)
1)
识别执行者——执行者Actor定义：在系统之外，透过系统边界与系统进行有意义交互的任何事物。引入执行者的目的：帮助确定系统边界
2)
识别用例——用例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。[有意义的目标+价值结果由系统生成+业务语言+用户观点+注意用例的命名+用例的“粒度”]——【执行者】使用系统来【用例】
3)
绘制用例图
a)
执行者与用例之间的关联关系Association或通信关系(Communication)
b)
执行者之间的泛化/继承关系Generalization
c)
用例之间的关系
i.
多个用例中都有的公共行为,依赖关系上应用<
ii.
基用例之上添加新的行为,依赖关系上应用<
iii.
泛化关系:共性抽象成为父用例,子用例继承了父用例所有的结构、行为和关系
4)
书写用例文档——文本文档，而非图形，用例建模主要是编写文本的活动而非制图，用例不是面向对象的，编写用例时也不会进行OO分析；用例是经典OOA/D的关键需求输入。
内容包括：
用例编号、用例名、执行者、前置条件、后置条件、涉众利益、基本路径
、扩展路径、字段列表、业务规则、非功能需求、设计约束
前置[开始用例前所必需的系统及其环境的状态]、后置条件[用例成功结束后系统应该具备的状态],都是系统必须能检测到。
基本路径：单独分离，凸现用例的核心[客户最想看到、最关心的路径]价值。以执行者或系统作为主语的主动句，分支要放到扩展路径,而循环则直接描述.
扩展路径: 替换路径和异常路径.
补充约束: 字段列表、业务规则、非功能需求、设计约束，可以直接放在用例中，也可以单独集中到另外的文档，从用例文档指向
5)
检查用例模型
功能需求的完备性、模型是否易于理解
、是否存在不一致性、避免语义二义性
UML静态建模
概述：描述了数据如何封装到对象中，类和对象的职责如何划分以及它们之间关系如何。可以使用类图、对象图、包图和组成结构图。
类图
——描述系统的静态结构，类图包含类和它们之间的关系，它描述系统内所声明的类，但它没有描述系统运行时类的行为。
类名 +属性（可见性 名称:类型 = 缺省值） + 操作（可见性 名称(参数列表):返回类型）
类间的关系：
1)
关联关系：指一种对象和另一种对象有联系，有单向关联和双向关联。多重性关联关系又称为重数性关联关系，表示一个类的对象与另一个类的对象连接的个数。
2)
聚合关系：整体与部分的关系，类A是类B的一部分，但是类A可以独立存在。空心。
3)
组合关系：整体和部分的关系，类A控制类B的生命周期意味着类B的存在依赖于类A。实心。
4)
依赖关系：体现在某个类的方法使用另一个类作为参数。用带箭头的虚线表示，由依赖的一方指向被依赖的一方。参数引用+局部变量引用+静态方法调用
5)
泛化/继承关系
6)
实现关系: 接口和类之间的关系，带空心三角形的虚线
对象图
——真实世界中的某个客观实体，任何对象都是某个类的实例。对象图是类图在某一时刻的一个实例。描述一段时间里特定实例的静态结构，只能在系统某一时间段存在。
表示方法，链。
包图
——把元素组织到一起的通用机制，描述包与包之间的关系。
包之间的关系：
引入关系[依赖关系的一种，需要在依赖线上增加一个<
泛化关系：Idao
dao
嵌套关系:包中包含子包，层次结构。子包7±2原则。
组合结构图
——将每一个类放在一个整体中，从类的内部结构来审视一个类。
部件(Part)+
连接件(Connector)+ 端口(Port)
UML动态建模
——对应于系统的行为视图，它描述了软件系统模型的动态方面。状态图、活动图、时序图、通信图、定时图和交互概览图来表示。
状态图
——描述一个特定对象的所有可能状态及其引起状态转移的事件。具有重要交互行为的类，才会使用状态图来描述。
组成元素：
初始状态（Initial
State）1个
终止状态（Final
State）X个，
状态
转移（Transition）事件名 [条件] / 动作名
过渡事件（Event）对应对象的动作或活动（Action）
守护条件（Guard
Condition），
绘制方法。
活动图
——表示系统中各种活动的次序，着重描述操作以及用例实例或对象中的活动，活动图就是UML中的流程图。
组成元素：起始状态(Start State)、终止状态(End State)、转移(Transition)、决策(Decision)、守护条件、同步条(Synchronization Bar,分支folk和合并join)和泳道(Swimlate划分负责活动的对象)等
作用: 描述对象的操作流程, 某些局部的行为, 某些外部可见的行为, 系统的业务流程, 用例的路径等.
交互图
系统中对象之间通过消息的传递来进行交互, 使用交互图(Interactive
Diagram)对对象之间的交互进行建模. 时序图、通信图、定时图和交互概览图.
1)
时序图：强调消息的时间次序的交互图，时序图展示了一组角色和由扮演这些角色的实例发送和接收的消息。
——也称为顺序图或序列图，由执行者（actor）、对象（object）、消息（message）、生命线（lifeline）、激活（activation）等组成。时序图描述对象之间的动态交互关系，着重体现对象间消息传递的时间顺序。
如果需要考察单个用例内部多个对象的行为就应该使用时序图；(单个对象的行为就需要使用状态图；跨用例或者跨线程的行为就需要考虑使用活动图。)
2)
通信图：强调收发信息的对象的结构组织的交互图，通信图展示了一组角色、这些角色间的连接件以及由扮演这些角色的实例所收发的消息。
——UML1.0中，叫协作图。与时序图是同构图，清晰地显示了对象间关系，时间次序必须从顺序号来获得。时序图常用于用例场景描述，通信图更适合显示过程设计细节。当对象及其连接有利于理解交互时，选择通信图；当只需了解交互的次序时，选择时序图。
组成：执行者（actor）、对象（object）、连接(link，也称为链)和消息(message)。
3)
定时图：展现消息跨越不同对象或角色的实际时间，而不仅仅关心消息的相对顺序。
——带数字刻度的时间轴来精确地描述消息的顺序，允许可视化地表示每条生命线的状态变化
4)
交互概览图：活动图和时序图的混合物，可以对活动图中的一些关键的、复杂度不高的活动节点进行细化，用时序图来表示其对象间的控制流。
——交互图与活动图的混合物，使用活动图描述主线，使用时序图描述细节。
UML架构建模
——包括实现视图和部署视图，其中实现视图通过组件图来表示，部署视图（环境视图）通过部署图来表示。架构建模用于帮助开发人员设计系统的整体物理架构。组件图用于描述每个功能所在的组件位置以及它们之间的关系；部署图用于描述软件中各个组件驻留的硬件位置以及这些硬件之间的交互关系。
实现视图描述软件系统的组件结构，组件是代码的实际物理模块，系统的组件图用来显示代码模块间的关系。
部署视图又称为环境视图，它用于描述系统所使用的不同元素的物理布局，部署视图通过部署图来表示。在部署图中，系统所涉及的物理硬件称为节点。
组件图
——又称为构件图(Component Diagram) 。组件图中通常包括组件、接口，以及各种关系。组件就是一个实际文件，源代码组件、二进制组件、可执行组件，可以用来显示编译、链接或执行时组件之间的依赖关系，以及组件的接口和调用关系。之间的关系有泛化关系和依赖关系。
组成元素：组件、接口、部件、端口、连接件。
部署图
——部署图(Deployment
Diagram)，也称为实施图。描述系统硬件的物理拓扑结构及在此结构上执行的软件。部署图(显示了系统的硬件和安装在硬件上的软件，以及用于连接异构计算机之间的中间件。部署图通常被认为是一个网络图或者技术架构图。
组成元素：节点和连接，组件与接口。
软件质量属性
CMM 对质量的定义是：①
一个系统、组件或过程符合特定需求的程度；② 一个系统、组件或过程符合客户或用户的要求或期望的程度。
软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。
质量属性——质量属性需求来源于商业和产品目标，关键的质量属性必须刻画系统的细节特征。质量属性场景是用于描述质量属性和表达项目干系人观点的强有力的工具。
软件质量属性场景——描述软件的质量属性，是一种面向特定的质量属性的需求。
刺激源(Stimulus Source)：某个生成该刺激的实体。
刺激(Stimulus)：刺激达到系统时需要考虑的条件。
环境(Environment)：该刺激在某些条件下发生。
制品(Artifact)：被刺激的对象，可以是系统或系统的一部分。
响应(Response)：在刺激达到后采取的行动。
响应度量(Response Measure)：以某种方式对其进行度量，对需求进行测试。
外部质量——用户而言
1)
正确性——软件按照需求正确执行任务的能力
2)
健壮性——在异常情况下，软件能够正常运行的能力。
3)
可靠性——一定的环境下，在给定的时间内，系统不发生故障（可以正常运行）的概率。
4)
性能——软件的“时间–空间”效率，而不仅是指软件的运行速度。
5)
安全性——指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。
6)
易用性——用户使用软件的容易程度。
7)
兼容性——指不同产品（或者新老产品）相互交换信息的能力。又称为互操作性
内部质量——开发人员，帮助开发人员实现外部质量
1)
易理解性——开发人员理解软件产品的能力，工作成果要易读、易理解
2)
可测试性——测试软件组件或集成产品时查找缺陷的简易程度，又称为可验证性。
3)
可维护性——在软件中纠正一个缺陷或做一次更改的简易程度。
4)
可扩展性——反映软件适应“变化”的能力。
5)
可移植性——软件不经修改或稍加修改就可以运行于不同软硬件环境（CPU、OS和编译器）的能力，主要体现为代码的可移植性。
6)
可复用性——指一个软件的组成部分可以在同一个项目的不同地方甚至在不同的项目中重复使用的能力。
过程质量——与开发活动相关，产品通过过程来进行开发，可靠、稳健、高效、可扩展、可重用
过程改进指南——CMM：Capability
Maturity Model for Software (软件能力成熟度模型（CMU-SEI）)
衡量软件过程能力的事实上的标准，同时也是目前软件过程改进最好的参考标准。
软件体系结构评估
概述
基本概念
敏感点——一个或多个构件（或构件之间的关系）的特性，可使设计人员或分析员明确在搞清楚如何实现质量目标时应注意什么。
权衡点——影响多个质量属性的特性，是多个质量属性的敏感点。
风险承担者——系统的体系结构涉及到很多人的利益，这些人都对体系结构施加各种影响，以保证自己的目标能够实现。
场景——为得出具体的质量目标而采用的机制叫做，它是从风险承担者的角度对与系统的交互的简短描述。
1)
刺激——场景中解释或描述风险承担者怎样引发与系统的交互部分
2)
环境——刺激发生时的情况。
3)
响应——系统如何通过体系结构对刺激作出反应的
评估的主要方式
基于调查问卷或检查表的评估方式
——比较自由灵活，可评估多种质量属性，也可以在软件体系结构设计的多个阶段进行。
基于场景的评估方式
——对系统的使用或修改活动的支持程度，从而判断该体系结构对这一场景所代表的质量需求的满足程度。是特定于领域的。这一评估方式的实施者一方面需要有丰富的领域知识以对某一质量需求设计出合理的场景，另一方面，必须对待评估的软件体系结构有一定的了解以准确判断它是否支持场景描述的一系列活动。
基于度量的评估方式
——首先需要建立质量属性和度量之间的映射原则，然后从软件体系结构文档中获取度量信息；最后根据映射原则分析推导出系统的某些质量属性。客观和量化的质量评估。
比较
ATAM
概念——Architecture
Tradeoff Analysis Method (ATAM)，Its purpose is to help choose a suitable architecture for a software
system by discovering trade-offs and sensitivity points.
步骤
(1) 描述ATAM方法——评估小组负责人介绍ATAM评估方法
(2) 描述商业动机——项目经理要从商业角度介绍系统的概况。
(3) 描述体系结构——首席设计师或设计小组详略适当地介绍体系结构
(4) 确定体系结构方法——设计师确定体系结构方法，由分析小组捕获，但不进行分析。
(5) 生成质量属性效用树——评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标，效用树的输出结果是对具体质量属性需求（以场景形式出现）的优先级的确定。
(6) 分析体系结构方法——有了效用树的结果，评估小组可以对实现重要质量属性的体系结构方法进行考察，通常产生一个风险列表、敏感点和权衡点列表。
(7) 讨论和分级场景——风险承担者集体讨论用例场景（描述风险承担者期望使用系统的方式）和改变场景（描述风险承担者所期望的系统在将来变更的方式，可分为成长场景和考察场景）。成长场景描述的是体系结构在中短期的改变，考察场景描述的是系统成长的一个极端情形。成长场景能够使评估人员看清在预期因素影响系统时，体系结构所表现出来的优缺点，而考察场景则试图找出敏感点和权衡点。
(8) 分析体系结构方法（是第六步的重复）——把最高级别的场景映射到所描述的体系结构中，重复第6步中的工作，把新得到的最高优先级场景与尚未得到的体系结构工作产品对应起来，在第7步中，如果未产生任何在以前的分析步骤中都没有发现的高优先级场景，则在第8步就是测试步骤。
(9) 描述评估结果——把ATAM分析中所得到的各种信息进行归纳，并反馈给风险承担者。
CBAM
——CBAM扩展了ATAM，它考虑到了更多的经济因素，优点：可以得到比主观想象更正确的决策，并且考虑到利益的最大化，缺点：难以获得准确的成本估算
面向对象设计原则
概述
——软件的复用(Reuse)或重用拥有众多优点，如可以提高软件的开发效率，提高软件质量，节约开发成本，恰当的复用还可以改善系统的可维护性。面向对象设计复用的目标在于实现支持可维护性的复用，可维护性复用都是以面向对象设计原则为基础的。重构(Refactoring)是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
七大原则
1)
SRP
——一个类只负责一个功能领域中的相应职责，There should never be more than one reason for a class to change.
一个类（或者大到模块，小到方法）承担的职责(类的职责主要包括两个方面：数据职责和行为职责)越多，它被复用的可能性越小。
2)
OCP
——Software
entities should be open for extension, but closed for modification.
抽象化是开闭原则的关键，可以通过“对可变性封装原则”来描述，对可变性封装原则(Principle of Encapsulation of Variation, EVP)要求找到系统的可变因素并将其封装起来。
3)
LSP
——Functions
that use pointers or references to base classes must be able to use objects of
derived classes without knowing it. 所有引用基类（父类）的地方必须能透明地使用其子类的对象。
4)
DIP
——High
level modules should not depend upon low level modules, both should depend upon
abstractions. Abstractions should not depend upon details, details should
depend upon abstractions. 高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。另一种说法是：要针对接口编程，不要针对实现编程。Program to an interface, not an implementation.
实现开闭原则的关键是抽象化，并且从抽象化导出具体化实现，如果说开闭原则是面向对象设计的目标的话，那么依赖倒转原则就是面向对象设计的主要手段。常用实现方式之一是在代码中使用抽象类，而将具体类放在配置文件中。
“将抽象放进代码，将细节放进元数据” Put
Abstractions in Code, Details in Metadata。
依赖注入：Constructor
Injection+Setter Injection+ Interface Injection
5)
ISP
——Clients
should not be forced to depend upon interfaces that they do not use. 客户端不应该依赖那些它不需要的接口。
接口隔离原则拆分接口时，首先必须满足单一职责原则。
6)
CRP
——又称为组合/聚合复用原则(Composition/ Aggregate
Reuse Principle, CARP)，尽量使用对象组合，而不是继承来达到复用的目的，Favor composition of objects over inheritance as a reuse mechanism.
在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用其已有功能的目的。简言之：要尽量使用组合/聚合关系，少用继承。
7)
LoD
——又称为最少知识原则(Least Knowledge Principle, LKP)，Don’t talk to strangers.Talk only to your
immediate friends. 每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位（Each unit should have only limited knowledge about other units: only
units “closely” related to the current unit.）
一个软件实体应当尽可能少的与其他实体发生相互作用
朋友：
(1) 当前对象本身(this)；
(2) 以参数形式传入到当前对象方法中的对象；
(3) 当前对象的成员对象；
(4) 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友；
(5) 当前对象所创建的对象。
狭义法则——两个类之间不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，可以通过第三者转发这个调用。可以降低类之间的耦合，也会造成系统的不同模块之间的通信效率降低。
广义法则——对对象之间的信息流量、流向以及信息的影响的控制，主要是对信息隐藏的控制。
Lod主要用途在于控制信息的过载
8)
小结
a)
对于面向对象的软件系统设计来说，在支持可维护性的同时，需要提高系统的可复用性。
b)
软件的复用可以提高软件的开发效率，提高软件质量，节约开发成本，恰当的复用还可以改善系统的可维护性。
c)
单一职责原则要求在软件系统中，一个类只负责一个功能领域中的相应职责。
d)
开闭原则要求一个软件实体应当对扩展开放，对修改关闭，即在不修改源代码的基础上扩展一个系统的行为。
e)
里氏代换原则可以通俗表述为在软件中如果能够使用基类对象，那么一定能够使用其子类对象。
f)
依赖倒转原则要求抽象不应该依赖于细节，细节应该依赖于抽象；要针对接口编程，不要针对实现编程。
g)
接口隔离原则要求客户端不应该依赖那些它不需要的接口，即将一些大的接口细化成一些小的接口供客户端使用。
h)
合成复用原则要求复用时尽量使用对象组合，而不使用继承。
i)
迪米特法则要求一个软件实体应当尽可能少的与其他实体发生相互作用。
