软件体系结构总结

第一章：1、软件体系结构的定义

国内普遍看法：

体系结构=构件+连接件+约束

2、软件体系结构涉及哪几种结构：

1、模块结构（Module）

系统如何被构造为一组代码或数据单元的决策

2、构件和连接件结构（Component-And-Connector，C&C）

系统如何被设计为一组具有运行时行为（构件）和交互（连接件）的元素

3、分配结构（Allocation）

展示如何将来自于模块结构或C&C结构的单元映射到非软件结构（硬件、开发组和文件系统）

3、视图视点模型

视点（View point）

ISO/IEC 42010:2007 (IEEE-Std-1471-2000)中规定：视点是一个有关单个视图的规格说明。

视图是基于某一视点对整个系统的一种表达。一个视图可由一个或多个架构模型组成

架构模型

架构意义上的图及其文字描述（如软件架构结构图）

视图模型

一个视图是关于整个系统某一方面的表达，一个视图模型则是指一组用来构建

4、软件体系结构核心原模型

1、构件是具有某种功能的可复用的软件结构单元，表示了系统中主要的计算元素和数据存储。

2.连接件(Connector)：表示构件之间的交互并实现构件

之间的连接

特性：1)方向性2)角色3)激发性4)响应特征

第二章

1、软件功能需求、质量属性需求、约束分别对软件架构产生的影响

功能性需求：系统必须实现的功能，以及系统在运行时接收外部激励时所做出的行为或响应。

质量属性需求：这些需求对功能或整个产品的质量描述。

约束：一种零度自由的设计决策，如使用特定的编程语言。

质量原意是指好的程度，与目标吻合的程度，在软件工程领域，目标自然就是需求。

对任何系统而言，能按照功能需求正确执行应是对其最基本的要求。

正确性是指软件按照需求正确执行任务的能力，这无疑是第一重要的软件质量属性。质量属性的优劣程度反映了设计是否成功以及软件系统的整体质量。

系统或软件架构的相关视图的集合，这样一组从不同视角表达系统的视图组合在一起构成对系统比较完整的表达

2、质量属性

3、系统非功能性需求？包括哪些质量属性

非功能性需求：用户对软件质量属性、运行环境、资源约束、外部接口等方面的要求或期望，包括：

(1) 性能需求：用户在软件响应速度、结果精度、运行时资源消耗量等方面的要求。

(2) 可靠性需求：用户在软件失效的频率、严重程度、易恢复性，以及故障可预测性等方面的要求。

(3) 易用性需求：用户在界面的易用性、美观性，以及对面向用户的文档和培训资料等方面的要求。

(4) 安全性需求：用户在身份认证、授权控制、私密性等方面的要求

(5) 外部接口：用户对待开发软件系统与其他软件系统或硬件设备之间的接口的要求。

(6) 可保障性（supportable）需求：用户在软件可配置性、可扩展性、可维护性、可移植性等方面的要求。

4. 可靠性可用性区别

可靠性通常低于可用性，因为可靠性要求系统在[0,t]的整个时间段内需正常（注意是“连续”!）运行；

可用性大于或等于可靠性，对于可用性，要求就没有那么高，系统可以发生故障，然后在时间段[0,t]内修复。修复以后，只要系统能够正常运行，它仍然计入系统的可用性。

计算：

第三章

1、软件架构风格(是一个面向一类给定环境的架构设计决策的集合，这些通用的设计决策形

成了一种特定的模式，为一族系统提供粗粒度的抽象框架。

每一个软件系统都有其占主导地位的软件架构风格。

“从软件中来，到软件中去”

架构风格通过为常见的问题提供解决方案，增强了对问题的分解能力、提升了设计重用的

水平。

)

1）独立构建风格：（这种风格的主要特点是：事件的触发者并不知道哪些构件会被这些事件影响，相互保持独立。

这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用；

各个构件之间彼此无直接的连接关系，各自独立存在，通过对事件的发布和注册实现关联。

）

进程通信体系结构风格：构件是独立的进程，连接件是消息传递。消息传递通常用来实现进程之间的同步和对共享资源的互斥操作

典型例子：客户-服务器架构，其中服务器通常用来为一个或多个客户端提供数据服务，客户端则用来向服务器发出请求，针对这些请求服务器通过同步或异步方式进行请求响应。

基于事件的隐式调用风格

：构件不直接调用一个过程，而是触发或广播一个或多个

事件。

?系统中的其它构件中的过程在一个或多个事件中注册。

?当一个事件被触发/发布，系统自动调用在这个事件中注

册的所有过程。

?这样，一个事件的触发就导致了另一模块中的过程的调

用。

?这种系统，称为基于事件的系统(Event-based system)，

采用隐式调用(Implicit invocation)的方式。

2）层次风格优点：

通过把逻辑层分布到多个物理层中，可以提高可伸缩性、容错性（fault tolerance）和性能。

可重用性。每一层提供的功能都是独立的和定义良好的。不同层之间有明确的接口，在解决一个新的问题时，使开发人员更容易地重用一个已有的层。

可测试性。由于有了明确定义的接口，以及可以在层接口的不同实现之间实现按需切换，可测试性明显增强了。

标准化。清晰定义并且广泛接受的抽象层次能够促进实现标准化的任务和接口开发，同样接口的不同实现能够互换使用。

缺点：

1)并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；

2)效率的降低：

由分层风格构成的系统，运行效率往往低于整体结构。

在上层中的服务如果有很多依赖于最底层，则相关的数据必须通过一些中间层的若干次转化，才能传到；

3)很难找到合适的、正确的层次抽象方法：

层数太少，分层不能完全发挥这种风格的可复用性、可修改性和可移植性上的潜力。

层数过多，则引入不必要的复杂性和层间隔离冗余以及层间传输开销。

3) 虚拟机风格：

不管何种类别的虚拟机，本质上都是在高层次抽象的

用户与低层次抽象的OS/硬件之间建立一道屏障。

但是，如何把上层应用的请求映射到下层OS/硬件系

统的执行？

?解释器(Interpreter)

?基于规则的系统(Rule-based System)

解释器：是一个用来执行其他程序的程序.

基本构件：

?解释器引擎

?存储区

连接器：

?对存储区的数据访问

基于规则的系统：核心思想：

将业务逻辑中可能频繁发生变化的代码从源代码中分离出来；

基本过程：

使用规则定义语言（IF…THEN…的形式，通常基于XML或自然语言，但绝不是程序设计语言），将这些变化部分定义为“规则”；

4)客户机/服务器：一个应用系统被分为两个逻辑上分离的部分，每一部分充当不同的角色、完成不同的功能，多台计算机共同完成统一的任务。

1）客户机(前端，front-end)：接受用户的输入，并把输入进行适当组织，转换成服务器接受的形式，通过网络传递给服务器，同时，负责接收服务器的回送消息，并表back-end) 2）服务器：提供各种服务，通常在高档计算机（服务器）上运行。服务器软件根据客户机的请求提供相应的服务，如数据库服务、邮件服务、Web服务等。

3）连接件：建立在网络协议上，驻留在服务器和客户机两端，提供透明的网络连接和服务。

5）基于B/S体系结构的软件

优点

?系统维护成本低：

?客户端无任何业务逻辑

?良好的灵活性和可扩展性

?较好的安全性

?良好的容错能力和负载平衡能力。

缺点

?客户端浏览器一般情况下以同步的请求/响应模式交换数据，每请求一次服务器就要刷新一次页面；

?受HTTP协议“基于文本的数据交换”的限制，在数据查询等响应速度上，要远远低于C/S 体系结构；

?提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用；

?受限于HTML的表达能力，难以支持复杂GUI (如报表等)。

6）SOA风格

定义:面向服务的体系结构（Service-Oriented Architecture，SOA）是一个构件模型，它将应用程序的不同功能单元通过定义良好的接口和契约联系起来

接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

服务（service）是封装成用于业务流程的可复用构件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变

用于实现特定服务的流程并不重要，只要它响应命令并为请求提供高质量的服务就可以了

服务特征:

可在网际间请求调用

具有良好的兼容性

粗粒度的操作

松散耦合的关联

基于接口的设计

具有透明的搜索和查询

SOA好处:利用现有的资产

更快的响应和上市速度

减少成本和增加复用

更易于集成和管理复杂性

说到做到

2．Web Services定义

部署在Web上的对象

从外部使用者的角度来看, Web Services是部署在Web上的对象,具备以下特征:

完好的封装性（数据和处理）

松散耦合

使用协约的规范性

标准化

高度可集成能力

3、Web Service与 SOA区别

Web Service是技术规范，而SOA是设计原则。从本质上来说，SOA是一种架构模式，而Web Service是利用一组标准实现的服务。Web Service 是实现SOA的方式之一。

4.为什么Web Services是最佳解决方案?

HTTP+XML, 最通用的访问方式

基于规范协议的访问接口, 可支持所有平台和应用

仅使用Web Service作为访问界面, 使得所有接入模块的编写变得容易

开发代价显著降低：程序员无需与多种平台进行交互，只需与Web Service进行交互；其调用接口使用XML及其相关技术，在代码实现上的代价也显著降低

部署和集成的费用大大降低，流程的更改也无需更改大量的代码，甚至无需更改代码

只有使用Web Services架构, 今后的大规模的面向公众的系统对接才成为可能

第四章

1、常用SA描述方法

线框描述法:

优点：

灵活

能够直观反应系统架构，同时也易于理解

缺点：

二义性：图形的本质所决定的模糊性，不同人有不同的理解；

矛盾性：模型中可能存在相互冲突的陈述；

不完备：无法描述所有的细节；

异构性：各个建模规范不同，模型也不同，难以支持模型在各个建模工具之交换；

无法自动化：只能由人理解，靠软件工具来理解比较困难，因此无法实现自动化的验证与推理。

形式化描述法:

优点：

表达架构的一个正式方式

可做到人机可读

在一个比以前更高的水平上描述系统

允许在完整性、一致性、歧义性和性能等方面分析和评估架构

支持自动生成软件系统

ADL的缺点：

使用类计算机高级语言的形式描述，表达不够直观，难以理解

对于ADLs应该表达什么，没有一个普遍共识，特别是关于架构的行为

目前使用表达解析相对比较困难，没有很好的商业工具提供支持

UML描述

2、4+1视图

第五章

2、属性驱动的设计方法(Attribute-Driven Design, ADD)是定义软件架构的一种方法，可根据软件质量属性需求实施架构设计过程

ADD通过一个分解系统或者系统元素的循环过程，使用架构模式和策略来满足系统质量属性需求，以完成分解操作和模式

3、质量属性设计策略

4、模块设计评价标准:

可分解性

可组合型

可理解性

可持续性（连续性）

可保护性

模块化五大规则:直接映射、少的接口、小的接口、显示接口、信息隐藏模块化设计的基本原则

1.类设计原则:单一责任原则

开放-封闭原则

里氏替换原则

依赖倒置原则

接口隔离原则

2.(包聚合设计原则)

?(REP) The Reuse/Release Equivalency Principle

复用/发布等价原则

?(CCP) The Common Closure Principle

共同封闭原则

?(CRP) The Common Reuse Principle

共同复用原则

3. PRINCIPLES OF PACKAGE COUPLING

(包耦合设计原则)

:?(ADP) The Acyclic Dependencies Principle

无圈依赖原则

?(SDP) The Stable Dependencies Principle

稳定依赖原则

?(SAP) The Stable Abstraction Principle

稳定抽象原则

第八章

2、三大产品线的三大基本活动

1.核心资产开发：目标是建立产品的生产能力，描述了核心资产开发活动及其输入输出主要输入：产品约束生产约束生产策略现有资产清单

主要输出：产品线范围核心资产生产计划

2、产品开发

主要输入：产品特定需求核心资产开发输出：产品线范围核心资产生产计划

主要输出：特定产品对核心资产的反馈增加新的核心资产和产品约束

3、核心资产管理