软件体系结构复习

整门课上课考试完全按照老师的想法来（整体在说微软蓝屏事件，safety, architecture…），主观性强。考试概念刁钻，需要注意

1.认识体系结构

体系结构简称架构或构架。

Architecture和Structure有什么不同？

结构(structure)：从某个角度（视角）对组成整体的各部分的搭配和安排。构架（architecture）：建筑的结构的集合，形成设计整体。

architecture = structures

Safety和Security有什么不同？

security”它有一些目的性，我故意要给你找点麻烦。“safety”是谁也不愿意让它发生但是它发生了，谁都不愿意，你也不愿意，我也不愿意，监管者也不愿意。比如，汽车安全带叫“safety belt”，没人希望车祸发生。我们在机场进行不叫“safety check”，叫“security check”，为什么叫security check？因为他针对那些有特殊目的，有恶意要干坏事情的人。

为什么研究软件架构?
思想有多远，我们就能走多远
高度决定思路，思路决定出路

系统的建立是为了满足组织的需求（包括功能和质量），质量需求决定了系统必须达到的特征, 包括性能, 可靠性, 互操作性以及生命周期等。随着软件系统的日益复杂，涉众对软件的要求已不局限于功能上的满足，而是更加注重质量。
很少有人注意到组织（开发组织、客户等）在系统设计和系统成败上扮演的角色。
系统的质量特征受到软件架构的限制，或者说构架设计的选择受到要达到的质量特征的影响。

1.1 软件架构基础

软件架构—在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件、组件的外部可见属性及组件之间的相互关系。
组件的外部可见属性是指其它组件可对该组件所做的假设，如该组件提供的服务、具备的质量特征、错误处理、共享资源的使用。

为什么设计原则是架构的一部分？

不遵循架构设计的原则，架构也容易失败

架构定义可以从下面六个方面来理解：

• 架构应建立在一定的设计原则之上，否则很容易失败。
• 架构由多个结构组成，其中任何一个结构都不能与构架等同。
• 每个软件系统都有自己的架构。
• 软件架构决定了各个组件。
• 只要某个组件的行为可以从其它组件的角度观察到或区别开，这样的行为就是软件架构的内容。
• 软件架构是抽象的，它不考虑实现、算法和数据表示的细节，而集中研究“黑盒”组件的行为和交互，是设计第一步。

1.2 软件架构的多个结构

静态的角度：

1. 模块结构—体现了任务的划分，每个模块有其接口描述、代码和测试计划等，各模块通过父子关系联系起来，在开发和维护阶段用于分配任务和资源。
2. 分析类结构—子系统图、包图。
3. 类结构—对象之间的继承或实例关系。

动态的角度：

1. 进程结构—运行系统的动态特征，包括进程间的同步关系、缺少不能运行、存在不能运行、先后等关系，与模块结构、概念结构成垂直正交关系。
2. 数据流—模块之间可能发送数据的关系，最适合用于系统需求的追踪
3. 控制流—程序、模块或系统状态之间的“之后激活”的关系，适合于对系统功能行为和时序关系的验证。
4. 使用结构—描述过程或模块之间的联系，这种联系是“假设正确存在”的关系，用于设计可轻松扩展的系统。如果过程A的运行必须以过程B的正确运行为前提，则说过程A使用过程B。
5. 调用结构–（子）过程之间调用和被调用的关系，可用来跟踪系统的执行过程
6. 层次结构—是一种特殊的使用结构，层就是相关功能的一致集合，在严格的分层结构中，第n层仅能使用第n-1层提供的服务。

使用结构

层次结构

部署的角度：
物理结构—软件与硬件之间的映射关系，在分布式或并行系统中有重要意义。

各种结构间的相互关系

1. 各个结构都是从不同角度考察系统，但它们并不完全独立，它们之间的联系是多对多的。
2. 每个项目在开发时一般是注重一个结构，按照这一主要结构来考虑和运用其它结构。
3. 经验表明，系统规模越大，这些结构之间的差异越明显。
4. 使用结构与调用结构的区别：对于使用结构，A可以调用B，并且A使用B的结果，如在ATM机上取款，先要验证余额是否够；或者A使用B的结果，但A不直接调用B，银行结息需要读利率，但不会直接调用利率设置程序。
   对于调用结构，A调用B，但A不使用B的结果，例如虽然网页的某个部分无法显示，但不会影响网页其它内容的显示。

1.3 架构定义的其他观点

…

软件架构是软件系统的总体结构（是否正确？）否

1.4 软件架构的产生

设计仅是系统功能需求分析的产物？
功能需求-设计-系统开发？

否

1.4.1 架构受系统涉众的影响

涉众—也叫风险承担者，利益相关者，他们是对构建软件系统感兴趣的人或组织，包括合同中的客户、系统最终用户、开发人员、开发组织、系统维护人员等，他们所关注的问题各不相同，但都要求系统在他们所关注的方面提供保证或优化。

事物有主要矛盾和次要矛盾之分。
开发系统时，首先要确定其软件构架。借助于构架，设计师可以分析众多风险承担者所提出的各种要求的优先级，并将这些要求转化为系统的各个特性，再针对它们在系统结构上做折衷，从而得到和谐的架构。

开发组织所关心的问题不同于客户，它对软件构架的影响分为3类：
· 直接影响
如希望向产品线发展
·长远影响
如行业布局
·组织结构的影响
如软件外包
开发组织的开发团队的经验对设计师有影响，从而间接影响架构

1.4.2 架构受设计师的素质和经验的影响

​ 1 熟悉.NET的设计师在设计时会考虑.NET的框架和技术。
​ 2 熟悉J2EE的设计师在设计时会考虑J2EE的框架和技术。
​ 3 设计师具有数据库方向的背景，系统会被认为是数据库的应用。
​ 4 设计师具有网络安全的背景，系统的安全会被放在很突出的位置。

1.4.3 构架受技术环境的影响

​ 例如：现在AI很流行，设计师在设计时往往首先考虑系统能否结合AI运行。

1.4.4 设计师的沟通能力

设计师的沟通能力从下面三点体现：
1 多看别人的长处，这样才能屈身理解涉众要求。

2 姿态放低一点

3 设计师还要会讲故事

1.5 软件的架构不是静止的

1. 软件在开发过程中或交付使用后，都可能会发生修改，这些修改往往涉及到架构的变更。因此软件版本的演进也是软件架构的演进。
2. 软件架构影响设计师的经验。
3. 软件架构影响开发组织的内部结构和经营目标。
4. 软件架构可能会影响客户对下个系统的需求
5. 有些系统甚至会影响并实际改变软件工程的发展，以及开发人员学习和实践的技术环境，如互联网、嵌入式、手机等。

架构商业周期—架构是软件开发的必经之路和必要手段，它受到来自客户和开发组织的影响，也受到设计师的素质和经验以及技术环境的影响；反过来，构架也影响着被开发的系统，对客户、开发组织、构架和技术环境也都有影响，还影响着客户及其开发组织的未来目标。围绕着构架的这些影响和反馈循环构成构架商业周期。

1.6 软件架构的重要性

1. 风险承担者之间的交流平台
2. 早期设计决策的体现
3. 有助于实现构架级重用

1.7 小结

构架不只是功能需求的结果。

1.8 讨论

谈软件架构与建筑架构的联系与区别

软件架构（Software Architecture）是指软件系统的基本组成部分、它们之间的关系和原则，以及这些元素是如何协同工作以完成系统功能的决策。软件架构描述了软件系统的整体结构、行为和属性，为软件开发提供了一个高层次的视角。

建筑物架构（Building Architecture）是指建筑物的形态、结构、空间安排、材料和技术等因素的整体规划和设计。建筑物架构描述了建筑物的外观、内部布局、功能和风格，为建筑设计和建造提供了一个高层次的视角。

模块化： 软件架构和建筑物架构都采用模块化的方法，将复杂系统分解

2. 质量属性

2.1 需求分析与架构的关系

需求包括三要素：
• 功能
• 质量
• 限制条件

需求是架构设计的基础，但在需求阶段是无法弄清全部需求的，因此需求和架构设计之间的迭代是必要和有意义的。

2.2 功能和架构的关系

功能
功能是指系统所能完成的工作。
功能是构架设计的必要条件而非充分条件，因为不同架构具有相同的功能，它们的差别在于质量。

随着软件开发水平的提高，如何满足功能已不是软件开发的主要矛盾，也不是构架层次上主要考虑的问题，构架设计主要考虑如何满足质量上的要求，但软件构架会限制各模块的功能划分，功能对架构设计有间接的影响。

2.3 架构和质量属性的关系

质量属性—系统在其生命周期过程中所表现出的各种特征。

1. 架构和质量属性的关系：
   • 架构是获取许多质量属性的基础（上梁不正下梁歪）
   在架构设计过程中就应考虑到这些质量属性，并在架构层次上进行评估。
   • 质量属性既和架构有关，也和具体实现有关。
   例如，系统设计时一般都会考虑设置密码来提供安全性，可是如果实现时SQL语句没写好，则可能被注入攻击。
2. 质量属性之间的关系：
   • 一个质量属性的获取对其他质量属性可能产生正面或负面的影响。
   • 任何质量属性都不可能在不考虑其他属性情况下单独获取
3. 质量属性可以分为两类：
   • 运行时可见属性
   包括：可用性、性能、安全性、易用性
   • 维护时可见属性
   包括：可修改性、可扩展性、可移植性、可集成性
4. 质量属性的场景描述法
   传统关于质量属性的讨论中存在问题：
   • 定义不具可操作性
   • 可能会关注同一问题
   可用性、易用性和安全性都可能关心一个系统故障

质量属性场景就是通过对某个实体与系统的一次交互的简要描述说明一个有关质量属性的特定需求，它由六部分组成：
• 刺激源：可以是风险承担者、计算机系统等。
• 刺激：可以看作是一个事件。
• 环境：系统当前的状态。
• 制品：系统中对事件作出反应的部分，可以是整个系统或系统的某一部分。
• 反应：事件到达后系统的相关行为。
• 反应度量：对反应结果提供某种形式的衡量。

质量属性不是处于隔离状态，只有在一定的上下文环境中才能做出有意义的评判。生成质量属性场景的目的和意义：
• 帮助构架师生成有意义的质量属性需求。
• 使质量属性需求的描述规范化。
• 某一场景是一类场景的代表，系统将以完全相同的方式对这些场景做出反应。

质量场景创建的参与人员：
· 负责软件执行的人员—最终用户
· 负责管理系统的人员—系统管理员
· 负责更改系统运行时功能的人员—维护人员
· 负责系统规划的单位—客户
· 负责项目实施的单位—开发组织

2.4 质量属性及其场景描述

可用性(Availability)是指系统正常运行时间的比例，是通过两次故障之间的时间长度或在系统崩溃情况下能够恢复正常运行的速度来衡量的。

可靠性(Reliability)是指系统能够保持正常运行的能力，通常用平均无故障工作时间来衡量。可靠性和可用性都与构架密切相关。

日常生活中，洗衣机、电冰箱等是用无故障工作时间来衡量。但对故障修复时间要求很短的系统，则常用可用性来衡量，如银行、证券和航天飞行等系统。

平均正常工作时间的加长是设计不易出错的系统，即在构架层次上把相关部分分离而实现。
平均（脱机）修复时间的缩短主要通过设计容错性较好的构架来实现，也就是通过在构架中重复设置关键处理单元及其之间的通讯信道而实现，这是通过快速确定故障症结并快速替换故障组件来实现的。因此要设计易于更改的组件、易于确定故障症结的组件。
下面是银行曾经使用过的双机热备份的例子。

可用性针对的是过错(fault)而不是失败(failure) 。

可修改性
可修改性是进行快速修改并使修改代价尽可能低的能力，这种能力直接受到构架的限制。
可修改性主要是所做修改的局部性的函数。
构架决定了各个组件及其职责，因此也定义了各个组件需要修改时所处的状态，这些修改可以分为3类：
§ 涉及一个组件的修改
§ 涉及几个组件的修改
§ 涉及整个构架的修改

对系统的更改一般是由于拥有该系统的组织的商业目的发生了变化，这些变化包括:
§ 功能的扩展或改变
§ 删除不需要的功能
§ 适应新的操作环境
§ 结构的重新调整
可修改性有时也称做可维护性。

可重用性
可重用性是指要合理地设计系统，使系统的结构或其某些组件能够在以后的应用开发中重复使用。
构架的各个组件就是重用的单位，一个组件的可重用程度依赖于它与其它组件的耦合程度。
Java API的应用就是复用的一个典型例子，Java API就是可复用的类集合。
可重用性与构架密切相关，它还可以看作是可修改性或可集成性的特例。这相当于一个硬币的两面：建立的系统可修改导致了系统可重用。

类的复用

• 对于一个已经设计好的类，可以使用继承、聚合、依赖等技术实现复用。
• 具体说，将新创建类直接说明为已经设计好的类（父类）的子类，通过继承和修改父类的属性与行为完成新创建类的定义；
• 或者，在新创建类中引进已经设计好的类的对象作为新创建类的成员变量，然后在新创建类中通过成员变量复用已经设计好的类的属性和方法；
• 或者，在新创建类中引进已经设计好的类的对象，作为新创建类中的方法的参数或返回类型。

性能
性能是指系统的响应能力—即对外部刺激（事件）做出反应时所需要的时间或在某段时间内所处理的事件个数。
在硬件条件一定的情况下，性能通常是系统中各组件间进行通信或交互的次数与数据量的函数，如函数之间的调用，参数的传递等。因此，性能与构架密切相关。
我们可以通过观察服务请求的到达速率、处理时间、队列大小和延迟时间长短等指标了解系统性能。
我们可以根据预计的工作负载，通过构建系统的随机队列模型来模拟该系统的性能并进行分析。

安全性
安全性是衡量系统在向合法用户正常提供服务的情况下，阻止非授权使用和抗拒拒绝服务攻击的能力。
系统受到的威胁有多种，例如：
§ 拒绝服务
§ IP源地址欺骗
下面场景表现了病毒攻击上网计算机时系统的安全性。

易用性
易用性可分为如下几个方面：
§ 可学习性
§ 可记忆性
§ 错误避免
§ 错误处理
§ 满意度
易用性与构架是密不可分的。

可移植性
可移植性是系统能够在不同计算环境下运行的能力。这里所说的环境可能是硬件、软件或两者的组合。
如果对任何特定计算环境的所有假设都仅包含在一个或几个组件中，那么就说该系统是可移植的。
在构架中对与平台相关问题的封装常采用一个可移植层，它是一组软件服务的集合，使上层应用软件与其环境具有抽象接口，并且在移植时接口不变。
可移植层是信息隐藏原则运用的结果。
采用可移植层的缺陷是什么？ 可能不能发挥特定系统的最大效率！

可集成性（integrability）
可集成性是使独立开发的系统组件能够协同运行的能力，集成性依赖与：
§ 组件的外部复杂性
§ 组件之间的交互机制和协议
§ 组件功能划分的清晰程度
§ 组件接口的定义是否完整、合理
可集成性表明了一个系统内个组件之间相互协作的能力，而互操作性（interoperability）衡量的则是一个系统与另一个系统的协作能力。

2.5 限制条件

限制条件包括商业限制、技术限制、法律限制、社会限制等。限制条件会对系统架构产生直接影响，也会对系统功能和质量产生影响。从而间接影响架构。

2.6 架构本身的质量属性

• 一致性

构架应该以类似的方式做类似的事情。

迈向一致性的最重要一步是有一个系统构架师。

• 正确性和完整性

构架能够满足系统的各种需求及运行时的资源要求。

• 可构建性

保证能够由指定的开发小组完成。

3. 软件架构的样式（风格）与框架

3.1 软件架构样式的概念

构架样式（风格）—是对各组件类型和运行控制/数据传送模式的描述。可以把构架样式看作是对构架的一组制约条件，即对各组件类型及其交互模式的限制条件，而这些制约条件就确定了一组或一系列能满足它们的构架。
可以从四个方面理解构架样式：

• 一组在系统运行时执行一定功能的组件类型。

• 能够表明在系统运行时组件的相互关系的拓扑结构。

• 一组语义约束条件的集合。

• 一组连接件的集合，这些连接件为组件之间的通信提供中介。

构架样式是预先定义好的，稍加修改即可在给定环境下使用的“组块”，样式代表了一组已经做出并可重用的设计决策，而且这些决策构成了一个整体。
样式对系统功能的要求总是模糊的，出现的形式经常变化。

3.2 软件架构样式的种类

以数据为中心的构架样式为我们提供了一个解决可集成性问题的结构解决方案。这种方式的优点是客户端相对独立，缺点是数据中心的性能要高，响应速度要快，并且要有灾难备份等。

数据流样式
数据流构架的目标是实现可重用性和可更改性，它的特点是把系统看作是对相继输入数据的一系列变换。它可分成两个子样式：

• 批处理（成批顺序式）—等到一个步骤全部处理完后才能开始下一个步骤，每个处理步骤（组件）是独立的程序，在各个步骤之间，数据是作为一个整体传送的，如传统的磁带处理。
• 管道—过滤式
  管道负责数据传递，过滤器对数据进行渐进的转换。如UNIX系统中可以用此方法来过滤文件中一些不需要的字符。

• 虚拟机样式
虚拟机构架的目标是实现可移植性。虚拟机是模拟硬件功能或抽象软件环境的构架样式。
虚拟机构架常见的示例有解释程序、基于规则的系统、句法shell程序、命令语言处理器等。

​ • 调用–返回风格
​ 调用返回风格一直是大型软件系统的主流构架样式，它的目标是实现系统的可更改性和可扩展性。它有多种子样式：

• 主程序-子程序风格​
• 远过程调用风格​
• 面向对象风格​
• 分层风格

含有参数的子程序的一般调用过程如下。
按从右到左的顺序，计算实参各表达式的值；
按照位置，将实参的值一一传给形参；
执行被调用函数（子程序）；
当遇到return(表达式)语句时，计算表达式的值，并返回主调函数（主程序）。

​ • 独立组件样式
​ 独立组件构架由许多通过发送消息进行通讯的独立进程或对象组成，它的目标是通过解除各运算部分之间的耦合实现可更改性，如股票机、各类短信预定等。它有两类子样式：

• 事件系统样式​
• 通讯进程样式

​ • C/S样式及其演变
​ C/S（Client/Server，客户机/服务器）样式是基于资源不对等，且为实现共享而提出来的，是20世纪90年代成熟起来的技术，C/S结构将应用一分为二，服务器（后台）负责数据管理，客户机（前台）完成与用户的交互任务。
​ C/S 样式具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。但随着企业规模的日益扩大，软件的复杂程度不断提高，传统的二层C/S结构存在以下几个局限：
​ （1）二层C/S结构是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet；
​ （2）软、硬件的组合及集成能力有限；
​ （3）服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏；

​ （4）数据安全性不好。因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。
​ 正是因为二层C/S有这么多缺点，因此，三层C/S结构应运而生。三层C/S结构是将应用功能分成表示层、业务层和数据层三个部分，如图所示。

​ 表示层是应用的用户接口部分，它担负着用户与应用间的对话功能，用于检查用户从键盘等输入的数据，显示应用输出的数据。为使用户能直观地进行操作，一般要使用图形用户接口，操作简单、易学易用。在变更用户接口时，只需改变显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的形式和取值范围，不包括有关业务本身的处理逻辑。
​ 业务层相当于应用的本体，它是将具体的业务处理逻辑编入程序中。例如，在制作订购合同时要计算合同金额，按照定好的格式配置数据、打印订购合同，而处理所需的数据则要从表示层或数据层取得。表示层和业务层之间的数据交往要尽可能简洁。例如，用户检索数据时，要设法将有关检索要求的信息一次性地传送给业务层，而由业务层处理过的检索结果数据也一次性地传送给表示层。
​ 通常，在业务层中包含有确认用户对应用和数据库存取权限的功能以及记录系统处理日志的功能。

​ 数据层主要是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。一般从业务层传送到数据层的要求大都使用SQL语言。
​ 三层C/S的解决方案是：对这三层进行明确分割，并在逻辑上使其独立。原来的数据层作为数据库管理系统已经独立出来，所以，关键是要将表示层和业务层分离成各自独立的程序，并且还要使这两层间的接口简洁明了。
​ 与传统的二层结构相比，三层C/S结构具有以下优点： 　
​ （1）允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统的可维护性和可扩展性。
​ （2）允许更灵活有效地选用相应的软硬件平台，使之在处理能力和处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。

​ （3）三层C/S结构中，各层可以并行开发，可以选择各自最适合的开发语言，维护也会更容易些。
​ （4）允许充分利用业务层有效地隔离开表示层与数据层，未授权的用户难以绕过业务层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础；整个系统的管理层次也更加合理和可控制。

​ C2样式有两方面设计规则。组成规则规定了C2以组件和连接件为基础，每一个组件和连接件都设有一个“顶域”和“底域”；组件的“顶域”与连接件的“底域”相连接；组件的“底域”与连接件的“顶域”相连接；对连接到某一个连接件上的组件数量没有限制，但组件与组件之间不能直接相连。 　
​ C2的通信规则规定所有组件间的通信必须通过消息来实现。组件的“顶域”定义了组件可以对哪些通知作出响应，以及可以发出哪些请求；组件的“底域”设置了可以向下层发送哪些通知，以及可以响应下层的哪些请求。每个组件只能感知层次高于自己的组件提供的服务，而不能感知层次低于自己的组件服务 。
​ C2构架样式最重要的特征就是“底层无关性”，这在组件的可替代性和可重用性方面具有显著的作用，即使软件组件的语言方式不同，通过一个构架，它们之间也可以方便、快捷地进行交互，这是通过以连接件为中介的异步消息交换机制来实现的。C2样式对于伸缩性的影响是正面的 。

​ C2样式可以概括为：通过连接件绑定在一起的按照一组规则运作的并行组件网络。
​ C2样式具有以下特点：
​ （1）系统中的组件可实现应用需求，并能将任意复杂度的功能封装在一起；
​ （2）所有组件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的；
​ （3）组件相对独立，组件之间依赖性较少。系统中不存在某些组件将在同一地址空间内执行，或某些组件共享特定控制线程之类的相关性假设。

​ • 正交样式
​ 正交样式由层和线索的组件构成。层是由一组具有相同抽象级别的组件构成。线索是子系统的特例，它是由完成不同层次功能的组件组成（通过相互调用来关联），每一条线索完成整个系统中相对独立的一部分功能。每一条线索的实现与其他线索的实现无关或关联很少，在同一层中的组件之间是不存在相互调用的。
​ 如果线索是相互独立的，即不同线索中的组件之间没有相互调用，那么这个结构就是完全正交的。从以上定义，我们可以看出，正交软件体系结构是一种以垂直线索组件族为基础的层次化结构，其基本思想是把应用系统的结构按功能的正交相关性，垂直分割为若干个线索（子系统），线索又分为几个层次，每个线索由多个具有不同层次功能和不同抽象级别的组件构成。各线索的相同层次的组件具有相同的抽象级别。因此，我们可以归纳正交软件体系结构的主要特征如下：

​ （1）正交样式由完成不同功能的n（n > 1）个线索（子系统）组成；
​ （2）系统具有m（m > 1）个不同抽象级别的层；
​ （3）线索之间是相互独立的（正交的）；
​ （4）系统有一个公共驱动层（一般为最高层）和公共数据结构（一般为最低层）。
​ 对于大型的和复杂的软件系统，其子线索（一级子线索）还可以划分为更低一级的子线索（二级子线索），形成多级正交结构。正交软件体系结构的框架如图所示。

​ 上图是一个三级线索、五层结构的正交样式框架图，在该图中，ABDFK组成了一条线索，ACEJK也是一条线索。因为B、C处于同一层次中，所以不允许进行互相调用；H、J处于同一层次中，也不允许进行互相调用。一般来讲，第五层是一个物理数据库连接组件或设备组件，供整个系统公用。在软件进化过程中，系统需求会不断发生变化。在正交软件体系结构中，因线索的正交性，每一个需求变动仅影响某一条线索，而不会涉及到其他线索。这样，就把软件需求的变动局部化了，产生的影响也被限制在一定范围内，因此实现容易。
​ 正交样式具有以下优点：
​ （1）结构清晰，易于理解。正交软件体系结构的形式有利于理解。由于线索功能相互独立，不进行互相调用，结构简单、清晰，组件在结构图中的位置已经说明它所实现的是哪一级抽象，担负的是什么功能。

​ （2）易修改，可维护性强。由于线索之间是相互独立的，所以对一个线索的修改不会影响到其他线索。因此，当软件需求发生变化时，可以将新需求分解为独立的子需求，然后以线索和其中的组件为主要对象分别对各个子需求进行处理，这样软件修改就很容易实现。系统功能的增加或减少，只需相应的增删线索组件族，而不影响整个正交体系结构，因此能方便地实现结构调整。
​ （3）可移植性强，重用粒度大。因为正交结构可以为一个领域内的所有应用程序所共享，这些软件有着相同或类似的层次和线索，可以实现体系结构级的重用。

​ • 构架的异质性
​ 实际系统的构架是异质的，既是多种样式的综合，这种异质可以分为3类：
​ 1 局部异质
​ 2 层次异质
​ 3 并行异质

3.3 参考模型

参考模型—是一种考虑数据流的功能划分，是对已知问题的标准分解，分解所得的各个部分相互协作，构成问题的解决方案。
参考构架—是映射到软件组件及组件之间数据流上的参考模型。

参考构架—是映射到软件组件及组件之间数据流上的参考模型。

3.4 软件架构、框架和设计模式

框架的定义：
《设计模式》中对框架的定义是框架就是一组相互协作的类，对于特定的一类软件，框架构成了一种可重用的设计。
软件框架是提取特定领域软件的共性部分形成的体系结构，不同领域的软件项目有着不同的框架类型。框架的作用在于：由于提取了特定领域软件的共性部分，因此在此领域内新项目的开发过程中代码不需要从头编写，只需要在框架的基础上进行一些开发和调整便可满足要求；对于开发过程而言，这样做会提高软件的质量，降低成本，缩短开发时间，形成良性循环。

框架和平台的关系：
框架不是现成可用的应用系统。是一个半成品，需要后来的开发人员进行二次开发，实现应用系统的具体功能。框架不是“平台”，平台概念比较广泛，可以是一种操作系统，一种应用服务器，一种数据库软件，一种通讯中间件等，因此平台在应用层面主要指提供特定服务的系统软件，而框架更侧重设计和开发过程，框架可通过调用平台提供的服务而起的作用。
框架和类库的关系：
框架不是工具包或者类库，调用API并不就是在使用框架开发，仅仅使用API是开发者完成系统的主题部分，并不时地调用类库实现特定任务。而框架构成了通用的、具有一般性的系统主体部分，二次开发人员只是像做填空一样，根据具体业务，完成特定应用系统中与众不同的特殊部分。

框架和架构的关系：
框架不是构架。构架确定了系统整体结构、层次划分、不同部分之间的协作等设计考虑。框架比架构更具体，更偏重于技术。确定框架后，其所对应的架构也随之确定，但在一个系统架构中可以集成多种框架，例如J2EE的SSH、SSM。
框架和设计模式的关系：
设计模式和框架在软件设计中是两个不同的研究领域。设计模式研究的是一个设计问题的解决方法，一个模式可应用于不同的框架和被不同的语言所实现；而框架则是一个应用的体系结构，是一种或多种设计模式和代码的混合体虽然它们有所不同，但却共同致力于使人们的设计可以被重用，在思想上存在着统一性的特点，因而设计模式的思想可以在框架设计中进行应用。

1. 从应用领域上分，框架给出的是整个应用的体系结构；而设计模式则给出了单一设计问题的解决方案，并且这个方案可在不同的应用程序或者框架中进行应用。
2. 从内容上分，设计模式仅是一个单纯的设计，这个设计可被不同语言以不用方式来实现；而框架则是设计和代码的一个混合体，编程者可以用各种方式对框架进行扩展，进而形成完整的不同的应用。
3. 设计模式比框架更容易移植；框架一旦设计成形，虽然还没有构成完整的一个应用，但是以其为基础进行应用的开发显然要受制于框架的实现环境；而设计模式是与语言无关的，所以可以在更广泛的异构环境中进行应用。
   总之，框架是软件，而设计模式是软件的知识体，提升框架的设计水平。

4. 实现质量属性的战术

4.1 战术介绍

战术是对质量属性的控制产生影响的设计决策。
架构策略是架构中所采用的战术的集合。
战术的特点：

1. 根据一种战术可以求精其他战术，并可以组织成层次的形式。如冗余战术可进一步求精为数据冗余或计算冗余。
2. 模式可以把战术打包，如冗余战术通常还会使用同步战术。

4.2 可用性战术

4.2.1 错误检测

用于检测错误的3个战术是：
• 砰/回声
• 心跳
• 异常
砰/回声和心跳战术用来检测另一个进程的错误，异常是进程本身的错误处理。

4.2.2 错误恢复

用于错误恢复的战术有：
• 表决
• 主动冗余
• 被动冗余
• 备件
• shadow操作
Windows的安全模式
• 状态再同步
• 检查点/回滚

4.2.3 错误预防

用于错误预防的战术有：
• 进程监视器
• 从服务中删除
• 事务

4.3 可修改性的战术

4.3.1 局部性修改

局部化修改的目标是在设计期间为模块分配责任，以把预期的变更限制在一定的范围内，以降低修改成本，其战术有：
• 维持语义的一致性
• 预期期望的变更
• 泛化模块
• 限制可能的选择

4.3.2 防止连锁反应

修改所产生的连锁反应就是本修改没有直接影响到的模块也需要改变，这是由于模块间存在依赖关系，这种依赖关系有：
• 语法
• 语义
• 顺序
防止连锁反应的战术有：
• 信息隐藏
• 维持现有的接口
Δ 添加接口
Δ 添加适配器
Δ 提供一个占位程序A

4.3.3 推迟绑定时间

推迟绑定可以允许非开发人员进行修改，也可以延迟部署时间，其战术有：
• 运行时注册—支持即插即用
• 配置文件—启动时设置参数
• 多态—允许方法调用的后期绑定
• 组件更换 –允许载入时间绑定
• 遵守已定义的协议—允许独立进程的运行时绑定

4.4 实施性能的战术

影响响应时间的两个基本因素是：
• 资源消耗
• 阻塞时间
Δ 资源争用
Δ 资源的可用性
Δ 对其他计算的依赖性

4.4.1 控制对资源需求

1 减少处理一个事件所需要的资源：
• 提高计算效率
• 减少计算开销
2 减少需要同时处理事件的数量：
• 管理事件率
• 控制采样频率
3 控制资源的使用：
• 限制执行时间
• 限制队列的大小

4.4.2 资源管理

用于资源管理的战术有：
• 引入并发
• 维持数据或计算的多个副本
• 增加可用资源

4.4.3 资源仲裁

常见的调度策略有：
• 先进/先出
• 固定优先级
Δ 语义重要性
Δ 时限时间单调
Δ 速率单调
• 动态优先级调度
Δ 轮转
Δ 时限时间最早优先
• 静态调度

4.5 实施安全性的战术

4.5.1 检测攻击

配置网络监视器来检测和记录网络事件，网络入侵检测系统的工作方式是比较网络通信模式与数据库中的记录。通常，必须根据协议、TCP标记、有效符合大小、源或目的地地址以及端口号等，对数据包进行过滤。
• 误用情况的检测是把通信模式与已知攻击的历史模式进行比较。
• 异常情况的检测是把通信模式与其本身的历史基线（情况）进行比较。
入侵检测系统必须有检测攻击的传感器、存储事件供以后分析的数据库、用于离线报告和分析的工具、一个让分析员能够修改入侵检测操作的控制台。

4.5.2 抵抗攻击

用于抵抗攻击的战术是：
• 对用户进行身份验证
• 对用户进行授权
• 维护数据的机密性
• 维护完整性
• 限制暴露的信息
• 限制访问
• 在外部用户和提供服务的系统之间设置认证服务器。
• 把要保护的系统置于通讯防火墙之后
• 在某个可信内核的基础上构建系统，由该内核提供安全

4.5.3 从攻击中恢复

从攻击中恢复的战术分为：
• 恢复状态
• 识别攻击者

4.6 易用性的战术

4.6.1 运行时战术

易用性的表现：系统正在做什么，用户能做什么，系统帮用户做什么。
人机交互的过程可以用“用户主动”、“系统主动”和“混合主动”，其中“系统主动”需要根据一定的模型来实现。
• 维持任务的一个模型
例如英文句子常以大写字母开头，可以纠正该位置的小写字母。某个词组多次输入后Word能保存该词组。
• 维持用户的一个模型
例如维持用户模型使系统以用户满意的速度滚动显示。
• 维持系统的一个模型
拷贝或粘贴的时间预计。

4.6.2 设计时战术

在测试过程中，用户接口可能频繁修改，这就要求修改时保持语义的一致，该战术进一步求精为—将用户接口与应用的其余部分分离开来，从而局部化变更。支持该战术的软件构架有：
• 模型-视图-控制器
• 表示-抽象-控制
• Seeheim
• Arch/Slinky

4.7 案例：中行网上银行安全战术分析

4.8 软件架构样式与战术的关系

软件架构样式从战略层面解决质量问题，战术是从具体部署上给出解决质量问题的局部策略。

5. 设计构架

5.1 生命期中的构架

软件过程—对软件开发活动的组织、规范和管理
基于构架的开发步骤

1. 为软件系统构建一个商业案例
2. 弄清系统需求
3. 构建或选用构架
4. 正确表述此构架，并与有关各方进行交流
5. 对此构架进行分析和评价
6. 实现基于构架的系统并保证与构架相一致
7. 系统维护时，构架文档应同步维护

何时可以开始设计?
对需求有了初步了解就可以开始设计。
构架驱动因素的组成：
比较重要的功能、质量属性、限制条件构成的某个子集
如何确定构架驱动因素?
业务目标优先级较高的要求

5.2 良好架构的评判原则

设计构架过程的建议：

1. 构架的设计应该由一位设计师来完成
2. 设计师应全面掌握对系统的技术需求，以及对各项定性指标优先级的清单
3. 构架的文档完备，并采用所有人员认可的文档形式（至少有一个静态视图和动态视图）
4. 构架设计方案应让各风险承担者积极参与评估
5. 通过对构架分析，得出明确的定性与定量指标
6. 构架设计应有助于具体实现（有助于增量式实现）
7. 允许构架带来一定的资源争用，并给出可行的解决方案

关于构架的结构的建议：

1. 构架由定义良好的模块组成，各模块的功能划分应基于信息隐藏
2. 模块的划分应体现出相互独立的原则
3. 把计算机基础结构的特性封装在一定的模块中
4. 构架尽量不依赖于某个特定版本的商用产品或工具
5. 产生数据的功能和使用数据的功能应分属于不同的模块
6. 对并发系统，构架应充分考虑进程与模块结构的不对应
7. 进程编写要考虑到与特定处理器的关系，并容易改变关系
8. 构架应尽量采用一些已知的设计模式。

5.3 架构设计的质量驱动方法

你作为设计师对构架的设计和评价就如同一个足球教练对一场比赛的球队组织，你首先要了解自身和对手的情况，明确你这场比赛想打输、打赢或打平（质量目标），然后根据该目标设计比赛阵型，如攻击或防守阵型，再确定相关战术和人员组织（构架设计、战术选用），最后将你的设计和队员沟通，取得全体队员的共识（构架评价）

属性驱动的设计(Attribute Driven Design, ADD)把一组质量属性场景作为输入，利用对质量属性实现与构架设计之间的关系的了解，对构架进行设计。
ADD是一种定义软件构架的方法，该方法将模块分解过程建立在软件必须满足的质量属性之上。它是一个递归的分解过程，其中在每个阶段都选择构架模式和战术来满足一组质量属性场景，然后对功能进行分配，以实例化有该模式所提供的模块类型。
ADD的结果是粗粒度的， ADD的结果是构架的模块分解视图和其他视图的最初的几个层次，不是视图的所有细节都是通过ADD得到。
由ADD得到的构架和已经为实现做好准备的构架之间的区别是，需要做出更详细的设计决策。

ADD构架设计的步骤如下：

1. 需求输入。
2. 选择要分解的模块。
3. 根据下列步骤对模块进行求精：
   a. 从具体的质量场景和功能需求集合中选择构架驱动因素。
   b. 选择满足构架驱动因素的构架样式（风格）、参考模型，形成参考架构、框架和设计模式。
   c. 实例化模块并根据用例分配功能，使用多个视图进行表示。
   d. 定义子模块的接口。
   e. 验证用例和质量场景并对其进行求精，使它们成为子模块的限制。
4. 对需要进一步分解的每个模块重复上述步骤。

5.4 创建骨架系统

创建骨架系统的思想是提供一种基本能力，以一种对项目有力的顺序实现系统的功能。
在系统开发的最初阶段创建整个系统的骨架系统是非常重要的，主要原因包括：

1. 提高开发效率，鼓舞士气。
2. 能更早发现复杂的依赖关系。
3. 使开发人员更多关注在设想中最难以实现的部分。
4. 能够缩短系统集成时间，降低其成本，并使集成成本更明确。
   便于评审和测试。

创建骨架系统的步骤：

1. 实现处理构架组件交互的软件部分。
2. 选择组件逐步添加到系统中。
3. 逐步进行测试。

5.5 团队结构的形成

开发小组的结构反映了构架的模块结构。可以把模块看作一个小领域，再根据开发人员的专长进行安排。
开发小组要做到松耦合，高内聚，即小组内需要有非常便于沟通的机制，小组间的沟通尽可能少。
开发组织对构架也会有影响。

5.6 架构师的职责

架构师要和多个部门和多种人沟通，如要指导以架构为核心形成开发团队，协调团队之间的合作，解决他们之间的冲突；架构师要支持项目经理的工作，要知道开发团队的技术水平；为明确组织的业务目标，架构师需要和售前、售后部门交流，拜访客户。因此，架构师必须纵观软件过程的全局，并对不同角色相互合作的接口和时机有清晰的把握。架构师的职责包括：
1 了解所在组织的业务目标，使架构更好地支持业务目标
2 规划产品的开发与演进
3 规划和建设架构级的重用，如产品线等
4 领导并负责架构设计，定义系统的高层结构和接口
5 为项目管理提供支持，如技术可行性、任务划分、人员招聘

6 领导和协调项目组的主要技术活动，对主要技术产品负责实际参与架构原型的开发实现
7 讲解架构、指导详细设计和开发、协调冲突以实现既定的构架目标
8 规划和协助软件架构的评审
9 评估新技术并提出采用建议

6. 案例分析

6.1 项目背景

​ 随着互联网的大规模普及以及近年来中国政府大力推广“互联网+”理念，让许多传统公司的经营方式从线下迁移到线上，互联网科技技术的发展促使着商业模式的剧烈转型，其中包括传统的门店销售转型成网上交易，现如今，人们已经越来越依赖网上购物，它的出现给人们的生活带来了深远的影响。
​ 传统的门店销售，不仅需要店家前期通过市场调研寻找合适的店铺门店，而且需要支付门店开设，门店装修等费用，在前期投入中就给店家带来了巨大压力；同时还需要对商品的库存，进货，资金流水有明确的了解；顾客也需要几经辗转才能到指定的店铺购买到心怡的商品。给买卖双方带来极大的不便。而网上购物，店家不需要前期巨大投入，只需要简单的操作步骤和少许费用即可完成店铺开设，在商品的管理和订单流水上，一目了然。买家也可以不需要花费出行时间就可以挑选购买到需要的商品。

6.2 需求分析

​ 创建代表“目前”业务情况的业务模型，并将此业务模型转换成“将来”的系统模型，包括功能需求和非功能需求。非功能需求又包括质量属性和各种约定。
​ 通过对客户的当前业务的分析，我们得到当前业务的基本需求。

6.2.1 定义系统

根据业务的功能需求，该系统主要的涉众有卖家、买家、管理人员和游客，卖家会对店铺和商品信息进行相关维护，管理人员对卖家和买家信息进行相关的维护。由此得出系统角色，分析其对系统的具体要求，并找出系统的各个用例。

6.2.2 质量场景

1）性能场景：在系统处于高峰时期，保证登陆的每个顾客所作的选择和查询的响应时间能在5s以内，如果需要等待则给出有友好的提示。系统可以保证以最快速度同时响应500个用户的操作。

2）安全性场景：杜绝非法用户试图绕过应用服务器直接连接到数据库服务器的端口上，防止非法窃取注册用户个人息；屏蔽某IP短时间内的大量无意义的访问，以防被挤爆，使正常用户无法使用。保证系统数据的机密性和完整性。

3）易用性场景：在该系统中，用户希望在运行时能尽快取消某操作使错误的影响降到最低，取消在1秒内发生；要求具有基本电脑操作常识的人，可以根据良好的界面设计迅速学会使用方法，让熟手用户使用快捷键。

4. 可用性场景：在正常的工作时间内，系统必须具有极高的可用性，保证出故障几率最低。出现故障时系统有相应的处理机制。

6.2.3 约束（限制）条件

​ (1) 开发周期
​ (2) 技术人员水平
​ (3) 开发费用
​ (4) 用户操作能力

6.3 系统架构设计

6.3.1 样式选择、参考模型、参考架构

6.3.2 体系结构的设计

6.3.3 系统架构的分析与设计

业务逻辑层架构设计
业务逻辑层作为该系统的关键部分，对系统的灵活性实现起着决定性的 作用。在本系统的业务逻辑层架构层中，采取了MVC模式，下面简单介绍一 下MVC模式的好处：
(1) 实现了客户端表示层和业务逻辑层的完全分离
(2) 高效可靠的事务处理
(3) 具有良好的易用性，安全性

业务逻辑层架构分析：
该业务逻辑层的架构是前面MVC模式的一种变形，他继承了MVC模式的优点，同时，具体到我们的架构中，它又实现了表示层与业务层的完全分离。在业务逻辑层我们使用Spring框架作为容器，以便实现业务层与表示层和数据层的松耦合。该业务逻辑层架构具备良好的易用性、安全性和性能。

6.4 小结

本章通过案例分析描述了设计师是如何通过质量属性来驱动系统设计的过程，根据质量属性选择相应的战术以及场景来进行分析。

7. 构架评审的一般方法

7.1 成本与收益

成本

1. 人员时间成本

2. 构架评审部门的组织开销

3. 构架评审部门要求高级设计人员参与的代价

收益

1. 及早发现现有构架中存在的问题
2. 构架的改进
3. 财务收益
4. 强制为评审做准备
5. 捕获构架设计的基本思想
6. 验证需求的有效性

7.2 评审技巧

​ 所谓“定性分析”，是指凭分析者的直觉、经验，凭分析对象过去和现在的延续状况及最新的信息资料，对分析对象的性质、特点、发展变化规律作出判断的一种方法。
​ 所谓“定量分析”，是依据实际统计数据，建立数学模型，并用数学模型计算出分析对象的各项指标及其数值的一种方法。

构架评审技巧可以分为两大类，应用不同的技巧需要付出不同的代价，也能够得到不同的信息。
定性技巧—提问技巧
1.场景—描述风险承担者和系统之间的具体交互
2.评审清单—对同一领域的若干系统进行评估后提出的一组详细的问题
3.问卷—适用于所有构架的若干问题的清单
定量技巧
1.指标—对构架可观察到的参数的量化解释
2.模拟、原型与实验

评审技巧的选用
场景->评审清单->问卷调查
利用系统原型或模拟系统来解答与性能等相关的问题

7.3 评审实践

评审前提

1. 评审环境—预先规划
2. 项目代表—风险承担者，子系统或组件负责人
3. 评审小组
   • 评审小组的人员公证、客观、受尊重
   • 成员必须专门从事评审工作
   • 有对构架相关问题熟悉的人，其领导具有设计、评价经验
   • 至少有一位该系统所属领域的专家
   • 有专人负责文档、后勤，办公地点离评审对象近，有学徒
4. 组织的期望—用合同明确
   • 构架评审结束时应向谁报告什么内容
   • 评审的标准是什么
   • 向评审小组提供那些资源及人力
   • 对评审小组和项目组以后的工作有什么期望
   • 预计评审持续的最长时间
   设定期望的目的是让所有人都理解评审结果的本质是判断可行性，而不是提供任何保证。
5. 评审的准备—制定评审日程
   • 系统需求文档
   • 架构文档，包括架构描述及介绍构架决策思想的材料
   • 将系统的质量属性和功能要求按重要程度排序出前面3-5个

评审实施
• 按问题的重要性进行分类。
• 强调那些与构架相符或相悖的重要问题。
• 必须记载评审中所提的每个问题。
评审结果
对评审中的各个问题都要做出正式的阐述，同时也要对赖以确定这些问题的数据做出相应的说明。

7.4 小结

构架评审的主要指导原则如下：

1. 把由独立部门实施的正规的构架评审作为项目开发周期规划的一部分。
2. 选择评审的最佳时间，尽早预审一次。
3. 选择恰当的评审技巧。
4. 签署评审合同。
5. 限制所要评审的质量属性的个数。
6. 要保证评审小组中有构架方面的专家、领域专家、资料员及后勤员。
7. 一定要有系统设计师。
8. 收集各种场景数据，并在此基础上形成评审清单。

评审（分析）软件架构的原因

• 架构师风险承担者交流的平台、是早期设计决策的体现、是可传递的系统抽象（架构级重用）
• 系统的质量属性不可能在系统实现的最后阶段追加上去，必须在设计之初就考虑到

8. 架构权衡分析法(ATAM)

8.1 ATAM的参与人员

ATAM(Architecture Tradeoff Analysis Method)—构架权衡分析法（基于场景的定性评审方法）。
ATAM方法的特点是不仅可以揭示出构架满足特定质量目标的情况，而且可以使我们更清楚地认识到质量目标之间的联系。
ATAM的中心问题是对用于构架评估的有限时间进行管理。
ATAM要求以下3个小组的参与和合作：
• 评估小组
通常由3-5人组成，每个人要扮演多个角色，其中计时员的角色辅助管理时间。

​ • 构架的主要涉众（项目决策人）
​ 客户、项目管理人员、委托进行评审的人
​ • 构架的其他涉众

8.2 ATAM的输入和结果

软件构架评估的输入与输出
输入—用场景集合捕获的质量要求
输出—粗糙的评价，可能包括：
• 一个简洁的构架表述
• 表述清楚的业务目标
• 构架决策到质量需求的映射
• 所确定的敏感点和权衡点集合
敏感点：一个战术满足了一个质量场景
权衡点：一个战术满足了一个质量场景，但对另一质量场景产生了负面影响

​ • 有风险决策和无风险决策
​ 有风险决策：一个战术满足了一个质量场景，但该战术有风险
​ • 风险主题的集合
​ 风险主题：将有风险决策以通俗易懂的形式呈现出来

8.3 ATAM的阶段

ATAM中的活动被分为四个阶段：
• 评估小组和项目决策者共同确定评估细节。
• 评估小组收集信息和分析。
• 风险承担者参与评估。
• 评估小组自我检查和改进，提交书面报告。

8.3.1 评估阶段的步骤

ATAM的分析评估阶段由9步组成：
1. ATAM方法的表述
2. 商业动机的表述
任何相关的技术、管理、经济和政治限制
与该项目相关的商业目标和上下文
主要的涉众
构架的驱动因素
3. 构架的表述
祥略适当，在有限时间内传达构架的本质
技术约束条件
4. 对构架方法进行分类
说明构架中涉及的样式和战术对质量的影响
5. 生成质量属性效用树
效用树的作用是使质量属性需求具体化，从而迫使设计师和客户代表准确地定义出他们的质量需求。
“效用”是效用树的根结点，表示系统的总体适宜性。
中间结点是质量属性及其求精。
叶结点是与质量属性对应的场景。
6. 分析构架方法
7. 集体讨论并确定场景优先级
8. 再次分析构架方法
9. 结果的表述

8.3.2 有效利用有限的评估时间

1. 业务目标被作为收集效用树场景的动机
2. 划分分场景优先级
3. 自顶向下生成效用树场景，自底向上进行分析
4. 仅分析优先级高和较难实现的场景

8.4 小结

ATAM是评估软件构架的健壮方法。在该方法中，项目决策者和风险承担者要以场景方式阐述一个准确的质量属性需求列表，说明实现高优先级场景的构架决策。然后，把这些决策确定为有风险和无风险场景，以找到构架中存在的问题。
但ATAM不是需求评估，不是代码评估，不包括对实际系统的测试，不是一个量化的手段。

9. 架构文档的写作

9.1 编写架构文档的目的和原则

1 构架编档的目的与作用
让不同的风险承担者都能快速找到和理解他们所需要的信息。

2 构架文档写作的基本规则是：
就是从读者的角度出发。

9.2 选择相关结构

构架编档的基本顺序是：
将相关结构编成文档，然后向其中添加结构之间关系的文件。

1. 产生一个候选结构列表
   先为项目建立一个风险承担者和他们感兴趣的视图表，与项目的具体情况尽可能相符。
2. 组合结构
3. 划分优先级
   为了提供一个适当的结构集合，需要根据项目的具体情况确定先做什么，不需要在完成一个结构后再开始另一个结构，可采用宽度优先的方法。

9.3 结构编档

没有对结构进行编档的工业标准模板。
在实践中，文档通常包括下面七部分内容：
• 展示结构中的组件和组件之间关系的主要表示，常用图形方式。
• 组件目录至少祥述在主要表示中提到的组件和组件之间的相互关系，还包括组件的接口和行为。
• 系统与其环境相关的上下文图。
• 可变性指南，包括：
要在其中做出选择的选项
做出选择的时机

​ • 解释构架设计的背景，包括：
​ 基本原理
​ 分析结果
​ 设计中所反映的假定
​ • 结构中所选择的术语表。
​ • 其他信息。

9.3.1 对行为进行编档

结构仅提供了系统的组成信息，并不能据此对某些系统行为进行推断，而行为描述可以提供元素间的交互顺序、并发机会以及交互的时间依赖性的信息。
对行为的描述可以采用不同的建模技术和表示法，这取决于所要进行的分析的类型。
在UML中，顺序图和状态图用于行为描述。

9.3.2 对接口进行编档

接口就是两个独立的实体相遇并进行交互或通信的边界。
组件接口就是其他组件可对该组件所做的假设。
对接口进行编档的模板包括：
• 接口身份
• 所提供的资源
• 数据类型定义
• 异常定义
• 该接口提供的可变性
• 接口的质量属性特征
• 基本原理和设计问题
• 使用指南

9.4 跨结构的文档

结构文档看起来不应是孤立存在的，而要形成一个整体，这包括构架概述、构架的基本原理和如何安排与组织文档。
构架概述包括：
• 系统概述
• 结构之间的映射
• 组件列表
• 项目词汇
构架基本原理包括：
• 设计决策
• 预计可能的修改对构架的影响
• 在实现解决方案中对开发人员的限制
• 拒绝采用的决策方案

如何组织文档：
构架文档的每个套件都需要有介绍性内容，以向经验不多的涉众介绍其组织结构，并帮助他们获得最感兴趣的信息。文档组织包括两种方式：
• 结构目录
结构的名称和它说明的样式
结构中的组件类型、关系类型和属性的描述
结构目的的描述
结构文档的管理信息
• 结构模板

10. 评审案例分析

10.1 ATAM方法表述

(1) 概述
ATAM（Architecture Tradeoff Analysis Method）：
SEI提出的一种软件构架评估方法。ATAM评估方法的主要目的：
1) 提炼出软件质量属性需求的精确描述；
2) 提炼出构架设计决策的精确描述；
3) 评估这些构架设计决策，并判定其是否令人满意的实现了这些质量需求。
ATAM评估方法：
并非把每个可以量化的质量属性都进行详尽的分析，而是使众多的风险承担者（包括经理、开发人员、测试人员、用户、客户等等）都参与进来，由此而达到上述目标的。
ATAM是一种挖掘潜在风险，降低或者缓和现有风险的软件构架评估方法。因此，以下三点是评估中要特别注重的：风险、敏感点和权衡点。

(2) 构架涉众

·卖家
·买家
·管理人员
·游客
·开发人员
·测试人员

(3) 评估步骤
ATAM主要分以下几个步骤：

1. ATAM描述；
2. 商业动机表述；
3. 软件构架表述；
4. 确定构架方式；
5. 生成效用树；
6. 分析构架方式；
7. 确定场景及其优先级；
8. 进一步分析构架方式；
9. 得出结论。

10.2 商业动机的描述

项目经理从开发组织和客户角度，来表述在线购物系统的商业目标，综合如下：
从开发组织角度：开发一个模块性强、实时高效、界面良好、与外部其他系统兼容良好的系统，这使得开发组织能够把整个产品或某个模块卖给其他客户，同时由于良好的界面和业务处理效率而受市场欢迎。
从客户角度：系统容易操作，可维护性好、系统稳定、可以及时准确的处理用户的在线购物或查询要求。

根据上述目标，质量属性可以划分为两类：
高优先级质量属性：
1) 性能
2) 安全性
3) 易用性
4) 可用性
重要但优先级较低的属性：
1) 可维护性
2) 可修改性
3) 可测试性

10.3 架构表述

10.4 质量属性效用树

10.5 质量场景的构架分析

​ 在质量属性效用树中，我们对场景的优先级进行了划分，而同时由于分析时间宝贵，所以我们应该把宝贵的分析时间最先用于最重要且最难实现的场景上，即标注为**(H,H)**的场景。在质量属性效用树的表格中，仅在性能和可用性这2个质量属性下发现标注有(H,H)的场景，下面根据系统的体系结构和实现质量属性所采用的战术分别给出这些重要场景的构架方法分析表格。

10.6 对系统构架的再分析

10.7 评审结论

​ 总体而言，通过对质量属性场景的分析，我们发现了最先提出的构架方案的不足，由此得出改进后的构架方案。采用改进后的构架方案可以获得了良好的性能、易用性、安全性、可用性等等，达到了设计目的符合质量属性需求分析的要求！

补充

真题演练

一 填空题

1.架构受什么影响

答：客户和最终用户，开发组织，技术环境，设计师的经验

2.可用性的三个战术

错误检测（砰、回声/心跳、异常）、错误恢复（表决、主动冗余…）、错误预防（ 进程监视器）

3.性能的三个战术

控制对资源需求（提高计算效率）、资源管理（引入并发…）、资源仲裁（调度策略）

4.评审方法分为（定性）和定量

定性技巧—提问技巧
1.场景—描述风险承担者和系统之间的具体交互
2.评审清单—对同一领域的若干系统进行评估后提出的一组详细的问题
3.问卷—适用于所有构架的若干问题的清单
定量技巧
1.指标—对构架可观察到的参数的量化解释
2.模拟、原型与实验

5.架构样式写四种

以数据为中心的样式、数据流样式、虚拟机样式、独立组件样式、C/S、C2

6.架构自身的质量属性

概念完整性、正确性与完整性、可构建性

7.涉众

涉众就是对系统构建感兴趣的人或组织。如：客户、最终用户、开发人员、项目经理、维护人员、对系统进行市场营销活动的人。

8.安全性的战术

检测攻击

配置网络监视器来检测和记录网络事件
• 误用情况的检测是把通信模式与已知攻击的历史模式进行比较。
• 异常情况的检测是把通信模式与其本身的历史基线（情况）进行比较。

抵抗攻击
• 对用户进行身份验证
• 对用户进行授权
• 维护数据的机密性
• 维护完整性
• 限制暴露的信息
• 限制访问
• 在外部用户和提供服务的系统之间设置认证服务器。
• 把要保护的系统置于通讯防火墙之后
• 在某个可信内核的基础上构建系统，由该内核提供安全

从攻击中恢复
• 恢复状态
• 识别攻击者

二 简答题

1.什么是架构

在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件、组件的外部可见属性及组件之间的相互关系。

2.什么是架构样式

构架样式（风格）—是对各组件类型和运行控制/数据传送模式的描述。可以把构架样式看作是对构架的一组制约条件，即对各组件类型及其交互模式的限制条件，而这些制约条件就确定了一组或一系列能满足它们的构架。

3.什么是框架

框架就是一组相互协作的类，对于特定的一类软件，框架构成了一种可重用的设计。
软件框架是提取特定领域软件的共性部分形成的体系结构，不同领域的软件项目有着不同的框架类型。

4.请说明构架、框架和设计模式之间的联系和区别

• 定义：软件框架使提取特定领域软件的共性部分形成的体系结构，不同领域的软件项目有着不同的框架类型
• 作用：开发过程中代码不需要从头编写，提高软件的质量，降低成本，缩短开发时间，形成良性循环

1、框架和平台的关系：

• 平台在应用层面主要指提供特定服务的系统软件
• 框架更侧重设计和开发过程，框架可通过调用平台提供的服务而起作用

2、框架和类库的关系：

• 框架构成了通用的、具有一般性的系统主体部分
• 二次开发人员根据具体业务，完成特定应用系统中与众不同的特殊部分

3、框架和架构的关系：

• 构架确定了系统整体结构、层次划分、不同部分之间的协作等设计考虑
• 框架更偏重于技术，确定框架后，其所对应的架构也随之确定，但在一个系统架构中可以集成多种框架

4、框架和设计模式的关系：

• 设计模式研究的是一个设计问题的解决方法，一个模式可应用于不同的框架和被不同的语言所实现
• 框架则是一个应用的体系结构，是一种或多种设计模式和代码的混合体

共性：共同致力于使人们的设计可以被重用（设计模式的思想可以在框架设计中进行应用）

区别：

• 从应用领域上分，框架给出的使整个应用的体系结构，而设计模式则给出了单一设计问题的解决方案
• 从内容上分，设计模式仅是一个单纯的设计；而框架则是设计和代码的一个混合体
• 设计模式比框架更容易移植

5.请说明架构师的主要职责，架构师与项目经理的职责区别

架构师的职责如下：

• 了解所在组织的业务目标，使架构更好地支持业务目标
• 规划产品的开发与演进
• 规划和建设架构级的重用，如产品线等
• 领导并负责架构设计，定义系统的高层结构和接口
• 为项目管理提供支持，如技术可行性、任务划分、人员招聘
• 领导和协调项目组的主要技术活动，对主要技术产品负责实际参与架构原型的开发实现
• 讲解架构、指导详细设计和开发、协调冲突以实现既定的构架目标
• 规划和协助软件架构的评审
• 评估新技术并提出采用建议

项目经理的职责如下：

• 具有过程控制能力
• 具备文档能力
• 总结汇报
• 擅长分解任务
• 具有时间观念
• 具有计划能力
• 具有跨界思维
• 有亲和力
• 组织协调

区别

1. 关注点：
   • 架构师：侧重于系统的高层设计和技术方向，确保架构支持业务目标并具备可扩展性和可维护性。
   • 项目经理：专注于项目的管理和执行，确保项目按时、按预算完成。
2. 职责范围：
   • 架构师：负责架构设计、技术评估、指导详细设计，并参与架构原型的开发。
   • 项目经理：负责任务分解、进度控制、文档管理以及团队协调。
3. 决策层级：
   • 架构师：在技术决策和架构方向上具有更高的决策权，通常参与技术标准的制定。
   • 项目经理：在项目管理和资源分配上具有决策权，更侧重于团队和任务管理。
4. 技能要求：
   • 架构师：需要深厚的技术背景和架构设计能力，善于评估新技术并指导团队。
   • 项目经理：需具备良好的组织、协调能力和沟通技巧，强调过程控制和团队管理。

总体来说，架构师更多关注系统的技术设计，而项目经理则关注项目的整体管理与执行。

6.请说明架构评审的主要方法。

1、定性分析

是指凭分析者的直觉、经验，凭分析对象过去和现在的延续状况及最新的信息资料，对分析对象的性质、特点、发展变化规律作出判断的一种方法。

定性技巧——提问技巧：

• 场景——描述风险承担者和系统之间的具体交互
• 评审清单——对同一领域的若干系统进行评估后提出的一组详细的问题
• 问卷——适用于所有构架的若干问题的清单

2、定量分析

是依据实际统计数据，建立数学模型，并用数学模型计算出分析对象的各项指标及其数值的一种方法。

定量技巧：

• 指标——对构架可观察到的参数的量化解释
• 模拟、原型与实验

7.请说明以架构为中心的软件过程

软件过程—对软件开发活动的组织、规范和管理
基于构架的开发步骤

1. 为软件系统构建一个商业案例
2. 弄清系统需求
3. 构建或选用构架
4. 正确表述此构架，并与有关各方进行交流
5. 对此构架进行分析和评价
6. 实现基于构架的系统并保证与构架相一致
7. 系统维护时，构架文档应同步维护

8.什么是参考模型

是一种考虑数据流的功能划分，是对已知问题的标准分解，分解所得的各个部分相互协作，构成问题的解决方案。

三 判断题

略

四 问答题

1.架构和设计模式的区别和联系

区别：

1. 范围：架构关注于系统的整体结构，包括组件的划分、模块的交互和技术选型，是高层次的设计决策；设计模式则是针对特定问题的解决方案，通常是低层次的、可复用的代码片段或结构。
2. 抽象层级：架构涉及系统的非功能性需求，如性能、安全性和可扩展性，设计模式则专注于解决特定的设计问题，如对象创建、行为或结构。

联系：

1. 互补性：设计模式可以作为实现架构的工具，帮助在架构框架下解决特定的设计挑战。例如，一个系统架构可能会推荐使用某些设计模式来实现模块间的协作。
2. 影响性：设计模式的选择可以影响架构设计的灵活性和可维护性，而良好的架构可以使设计模式的应用更加有效和有意义。

总的来说，架构提供了一个系统的整体视图，而设计模式则为实现这个视图提供了具体的实践方法。

2.架构师和项目经理有哪些可以配合的地方

需求分析与目标对齐：

• 协作：架构师可以提供技术视角，帮助项目经理理解业务需求的技术实现，确保架构设计与项目目标一致。

规划与时间管理：

• 协作：项目经理可以根据架构师提供的技术路线图进行项目进度规划，确保各项技术实现能按时完成。

任务分解与资源分配：

• 协作：项目经理可以将架构师提出的架构设计转化为具体的开发任务，并合理分配资源，以保证团队的高效工作。

风险管理：

• 协作：架构师可以识别技术风险，项目经理则负责整体项目风险的管理与缓解策略的制定，确保项目的顺利推进。

技术评审与反馈：

• 协作：架构师可以参与项目经理组织的评审会议，提供技术意见，同时项目经理可以从中获取技术可行性和实施建议。

团队沟通与协调：

• 协作：项目经理可以促进团队之间的沟通，而架构师可以提供技术指导，确保各个团队成员在同一方向上努力。

变更管理：

• 协作：在项目需求变更时，架构师可以评估变更对架构的影响，而项目经理则负责管理变更过程和与利益相关者的沟通。

3.什么是质量属性？描述质量属性的方法？

质量属性—系统在其生命周期过程中所表现出的各种特征。

场景描述法

质量属性场景就是通过对某个实体与系统的一次交互的简要描述说明一个有关质量属性的特定需求，它由六部分组成：
• 刺激源：可以是风险承担者、计算机系统等。
• 刺激：可以看作是一个事件。
• 环境：系统当前的状态。
• 制品：系统中对事件作出反应的部分，可以是整个系统或系统的某一部分。
• 反应：事件到达后系统的相关行为。
• 反应度量：对反应结果提供某种形式的衡量。

4.在架构设计过程中，功能和质量属性的关系

在架构设计过程中，功能和质量属性之间的关系密切且复杂，主要体现在以下几个方面：

1. 相互依赖：
   • 功能需求定义了系统必须实现的特性和行为，而质量属性（如性能、安全性、可用性等）则描述了这些功能在何种条件下提供服务。质量属性往往是实现功能的前提或基础。
2. 权衡与折衷：
   • 在设计过程中，架构师常常面临功能和质量属性之间的权衡。例如，为了提高系统的性能，可能需要牺牲某些功能的复杂性，反之亦然。因此，架构师需要根据业务需求和用户期望进行合理的折衷。
3. 影响设计选择：
   • 功能需求的性质可以影响质量属性的设计。例如，如果一个系统需要高并发处理功能，架构师必须考虑如何设计以满足性能要求，同时确保数据一致性和安全性。
4. 验证与评估：
   • 功能和质量属性在测试阶段同样重要。功能测试确保系统按预期工作，而质量属性测试（如压力测试、安全性测试）则确保系统在不同条件下的可靠性和稳定性。
5. 架构演化：
   • 随着系统的演化，功能需求可能会发生变化，质量属性也需要相应调整。因此，架构设计需要具备一定的灵活性，以便在未来适应新的功能需求和质量要求。

5.架构师的沟通能力是很重要的为什么

开发组织的开发团队的经验对设计师有影响，从而间接影响架构。

跨团队协调：架构师需要与开发、测试、运维等多个团队协作，清晰的沟通能确保各方理解架构设计及其实现。

需求澄清：与业务方和项目经理沟通可以帮助架构师更准确地理解需求，从而设计出更符合业务目标的系统架构。

技术指导：架构师需要向团队成员传达技术决策和设计理念，良好的沟通能力能帮助他们有效理解和执行架构设计。

冲突解决：在项目中可能会出现技术争议或团队间的意见分歧，架构师需要通过沟通来协调解决，维护团队的合作氛围。

技术评审与反馈：在技术评审中，架构师需要清晰表达自己的观点，并能有效接纳和整合他人的意见，促进架构的不断优化。

影响力：良好的沟通能力可以增强架构师在组织中的影响力，帮助推动技术变革和架构决策的实施。

6.为什么需求和架构模式要相互迭代

软件的架构不是静止的

1. 软件在开发过程中或交付使用后，都可能会发生修改，这些修改往往涉及到架构的变更。因此软件版本的演进也是软件架构的演进。
2. 软件架构影响设计师的经验。
3. 软件架构影响开发组织的内部结构和经营目标。
4. 软件架构可能会影响客户对下个系统的需求
5. 有些系统甚至会影响并实际改变软件工程的发展，以及开发人员学习和实践的技术环境，如互联网、嵌入式、手机等。

五

从售票系统，选课系统等实验做的四个项目选一个回答以下问题

1.项目背景

购票系统旨在为用户提供便捷、高效的火车票购票服务，支持在线查询、预订、支付和退票等功能。随着用户需求的增加和在线购票的普及，系统需要处理高并发请求，并保证交易安全和用户数据隐私。

2.质量属性优先级和画两个质量场景图

高优先级：性能、安全性、可用性、易用性

低优先级：可维护性、可修改性、可移植性

3.ADD设计方法并进行第一步分解

识别主要功能：

• 用户登录/注册
• 查询余票
• 购票操作
• 支付处理
• 订单管理

确定关键质量属性：

• 针对每个功能，分析其对质量属性的影响，特别关注性能和安全性。

4.生成质量属性效用树

质量属性、属性求精、场景编号、场景

5.选一个属性进行战术评审

安全性

战术：采用HTTPS协议对数据传输进行加密，确保用户信息在网络传输中的安全性。

数据泄露风险：

• 敏感用户数据（如个人身份信息、支付信息）的存储和传输过程中的保护。

选择加密算法：

• 需评估所选加密算法的强度及其对系统性能的影响，确保不会引入安全隐患或导致性能瓶颈。

六

12306有哪些架构模式和战术有利于购票？你能给出什么改进建议

架构模式

1. 微服务架构：将不同功能（如用户管理、订单处理、支付等）拆分为独立的服务，提高了系统的灵活性和可维护性。
2. 事件驱动架构：通过事件通知机制，实时处理购票请求，提高系统响应速度。
3. 分布式架构：采用分布式系统来应对高并发请求，确保系统的可用性和稳定性。

战术

1. 缓存策略：使用缓存机制减少数据库访问，提高系统性能，尤其是在高峰期。
2. 负载均衡：通过负载均衡器分配用户请求，优化资源使用，防止单点故障。
3. 限流和熔断：在高并发情况下限制请求速率，保护后端系统免受冲击。

改进建议

1. 优化用户体验：引入智能推荐系统，根据用户历史行为和偏好推荐车票，提升购票体验。
2. 增强实时性：利用实时数据分析，预测购票高峰期并提前做出系统扩容，以应对突发流量。
3. 完善支付流程：提供更多支付方式和分期付款选项，减少用户在支付环节的流失。
4. 用户反馈机制：建立有效的用户反馈渠道，及时收集和处理用户在购票过程中的问题和建议。