软件体系结构问题整理

一、概念性问题

1、架构的5个来源

需求、涉众、开发组织、架构师、技术环境

2、需求的3类，每一类的定义

功能性需求，质量需求、约束

功能需求：系统需要做什么，系统应当如何为涉众提供价值。

质量需求：系统应当满足的整个系统的理想特性。

约束：是预定义的设计决策。通过接受设计决策、与其他受影响的设计决策进行协调来满足约束。

3、架构的定义

SEI：是整个程序或计算系统的结构(Structure)，包含了程序的元素(Software Elements)和那些外部能看见的元素属性(Properties)和元素之间的关系(Relationship)

IEEE：一个系统的基本组织，包含了了它的所有组件(Components)、组件之间的关系、环境以及指导该系统的设计(Design)和演化(Evolution)的原则(Principle)

4、列举4种tactics

心跳机制：监控系统/服务的可用性，如果不再能收到服务的心跳，则认为服务已经失效/出了故障，可用来提高可用性、可靠性

提高内聚、降低耦合、重构、清晰定义接口：可以提高系统的可修改性，互操作性

提高资源效率，增加资源，控制资源需求、引入并发：系统接收到外部请求后可迅速响应。提高系统性能

时间戳：可用于发现错误序列，尤其是分布式信息传递系统中

事务机制，回滚：便于故障恢复

主动冗余：采用冗余的服务器的机制来保证系统出现故障时不发生可用性缺失。

5、软件架构中的4个活动及各自的输入输出（就是那张颜色丰富的图

确定ASR：发现一些候选ASR

输入：涉众 输出：带优先级的质量属性场景

架构设计：定位ASR，选择、生成和分析设计决策来达成这些质量属性

输入：带优先级的质量属性场景、需求、约束、patterns和tactics 输出：候选views

文档化：设计出来架构后还要让它可被涉众理解和使用

输入：候选view、涉众 输出：选中的views和其结合文本的表示

架构评估：关乎系统成败，有必要花时间确保架构设计可提供需要的东西

输入：涉众、带优先级的质量属性场景 输出：选中的views和其结合文本的表示

二、比较对比问题

1、架构VS设计

1）架构是设计的一部分：架构一定是软件设计，但并非所有的设计都是架构；

2）架构提供了设计的抽象视图，架构是一种high level的设计，是一系列设计决策。

2、架构VS结构

架构包括software elements和它们的外在特性、它们之间的关系。

结构定义了组件接口，但架构还说明组件间的交流和依赖

架构是一种high level的结构，架构定义了结构，结构特性由架构设计决定。

3、软件需求VS质量属性VS架构关键需求（ASR

软件需求 ：包括功能需求、非功能需求；非功能需求or架构需求则是QA的替代术语。

质量属性：在功能需求之上，系统应当满足的整个系统的理想特性

ASR：对于架构会产生重大影响的，会对架构设计决策产生关键影响的那部分质量属性。一个质量属性越困难、越重要，越倾向于成为ASR。

4、patterns VS tactics

1）tactics更加简单，使用单一结构或机制来达成单一架构目标

2）patterns是多种相关设计决策进行组合的结果

3）tactics是构建patterns的组成模块

4）大部分patterns由多种不同的tactics组成

5）二者共同构成软件架构的主要工具

5、styles vs patterns vs views

style：定义元素、元素间关系类型和元素用法约束，关注架构方法，不关注具体上下文和问题；=architecture approach

pattern：体现软件系统基本的结构组织模式。关注具体上下文中的问题和具体上下文中如何解决；=（problem+context）->architecture approach

view：表示系统中特定类型的元素及元素间关系；不同视图支持不同的目标和用户，强调不同系统元素和关系；不同视图在不能程度上表示不同的质量属性。

6、产品线VS单一产品

产品线SPL：一系列可满足特定市场部门或任务的特定需求的软件系统 共享 一组通用的、被管理的特性集，它们是以规定的方式，从一套共同的core assets中开发出来的。

SPL通常是多个同步的变体，而单一产品使用版本和发布来控制。

SPL不仅仅是一个可重构的架构，它可以使用系统的变化。

三、步骤问题

1、ADD

step1：确定有足够的需求(输入）

• 涉众根据业务目标为需求划分优先级
• 将质量属性表示为场景

Step2：选择一个系统的元素来分解

• 如果是第一次迭代，则选择整个系统进行本次分解，将所有需求都被分配给系统
• 如果系统已经根据需求被分解，则选择其中一个元素

Step3：为选择的元素定义ASRs

• H, M, L 的二维数组：(对利益相关者的重要性，对架构实现的影响)即(Importance，Difficulty)
• 第一个表示：这条需求对涉众的重要程度
• 第二个表示：这条需求对架构的影响有多大

Step4：选择一个符合架构必要需求的设计理念

• 确认设计关注点
  
  • 如何满足ASRs
• 为次要关注点列出不同的模式和策略
  
  • 需要为选择的模式选定度量值，估计度量值的取值
• 选择合适的模式和策略
  
  • 根据他们对ASRs的优缺点进行选择
• 决定架构必要需求和模式策略之间的关系(确定模式/战术与ASRs之间的关系)
• 得到架构视图
• 评估并解决不一致问题

Step5：列出架构元素并分配职责(实例化架构元素并分配职责)

• 将父元素的职责在子元素中进行分配,分析和文档化设计决定

Step6：定义元素接口

• 接口描述了元素需要什么和提供什么的假设

Step7：确认需求，为元素构造约束

Step8：重复以上步骤直到所有架构必要需求都被满足

2、ATAM

3、PK的4+1views

逻辑视图：描述架构中至关重要的架构元素和他们之间的关系 Logical

过程视图(进程视图)：描述元素之间的交流依赖 process

物理视图：主要的进程和组件是怎么映射到硬件 Physical

开发视图：捕捉软件组件的内部组织 Development

架构用例：+1，架构需求，与多个视图相关 Architecture use cases

4、文档化——如何选择view：

1）建立涉众/视图表格

2）合并视图（确定视图边缘，将边缘视图与其他视图结合）

3）对视图优先级排序

5、如何确定ASR：

四、Patterns/Style 这部分git上总结的很好

1、patterns分类

module关注组件内部结构

component-connector关注系统级 不同系统间的相互关系

allocation关注系统与外部环境

pattern是什么：一系列适用于多次出现的问题的架构设计决策，可根据问题出现的上下文进行参数化设置。

2、以MVC为例说明Component-connector模式

MVC模式把功能分解为3个组件：model view和controller

model：表示应用的核心数据和状态

view：是用户接口组件，用于向用户展示信息

controller：协调model和view，管理model和view间的交互，把用户行为转化为model或view的变化

而notifies relation把model view controller的实例连接起来。

3、分层模式的上下文、优缺点Layerd

分层模式：定义了层与层之间的单向允许使用关系，通常使用代表了层的方框的叠加来表示层的依赖关系。层：提供一组内聚服务的模块组。换句话说：层内是内聚服务，层间演个单向调用

优点：

把复杂的问题分解为多个组件；

提高可扩展性和可复用性；

缺点：

层的增加会带来系统的成本和复杂度的增加；

给性能带来负面影响

设计不好的层会妨碍到抽象；

过多的层间关系不利于可移植性和可修改性

4、代理模式的上下文、优缺点Broker

代理模式：broker是运行时组件，协调client和server之间的交流。

优点：

高可扩展性，高可用性；

server可以被动态修改

缺点：

延迟，通信瓶颈：增加了一层，会延迟client和server间通信，可能会成为通信瓶颈。

broker会增加系统复杂度

broker可能出现单点失效；

broker可能成为被攻击的目标

broker难于被测试

5、MVC模式

把系统功能分为3个组件：MVC，Controller是中介；

通知关系 连接三部分的实例，并通知相关元素的状态变化。

缺点：

用户接口简单的情况下，带来的复杂度是不值得的

不一定能很好地使用一些用户接口工具

6、piper and filter模式

数据从系统外部输入到输出的过程中，经过一系列由管道连接的过滤器的变化处理

过滤器：一种转化数据的组件，过滤器间可以并行处理

管道：将数据从过滤器的输出端口传递给另一个过滤器的输入端口的连接件，不会修改数据

缺点：

不适合交互式系统

有大量独立的过滤器会增大大量的计算开销

不适合长时间的计算任务

7、CS模式

客户端发起与服务器的交互，根据需要 调用服务 等待返回请求结果

客户端：调用服务器服务的组件，直到它所需要的服务的端口

服务器：给客户端提供服务的组件，有提供服务的端口。

请求/响应连接件：使用请求响应协议实现的连接件，客户端使用它来调用服务器的服务。

缺点：

服务器会成为性能瓶颈

服务器淡定失效

在哪里放置功能的决定是复杂的，切系统构建后很难改变

8、peer to peer模式

计算由多个节点合作完成，各个节点之间要通过网络相互提供服务和相互调用

点：网络节点上独立的组件

请求响应连接件：用于连接网络上的点，查找其他点，调用服务

缺点：

安全性，数据一致性，数据/服务的可用性，备援和恢复都变的复杂，

小的点对点系统可能无法实现质量目标，如性能和可用性

9、Service-oriented模式

计算由一组相互合作的组件提供，他们在网络上提供服务，包括服务提供者，服务消费者，SOAP连接件、REST连接件

缺点：

构建复杂

中间件带来性能开销

服务成为性能瓶颈，无法提供性能保证

10、publish-subscriber模式

组件发布和订阅时间，发布事件后，基础连接件将时间分发到所有注册的订阅者。

缺点：

增加通信延迟，对伸缩性降低，消息传递时间的预测降低

缺乏对消息顺序的控制，消息是不受保护的

11、shared-data模式

数据存取器通过共享的数据商店通信。数据商店负责实现数据持久化。

缺点：

数据商店性能瓶颈；单点失效；

数据的生产者和消费者可能耦合紧密

12、Map-reduce模式

提供了一个分析大规模分布式数据集合的框架，在一组处理器上并行处理。Map提取和转化；reduce转载结果

优点：并行，因而低延迟，高可用

缺点：

数据集小时，开销不合理

数据不能分为小的子集时，并行就没有优势

需要多reduce的操作是复杂的

13、multi-tier based模式

计算结构由多个逻辑划分的组件团体组成。每一个团体就是一个层(tier)。

缺点：前期成本高，复杂度高

Layer是实际存在的清晰的，有层次关系的组织

Tier 不是在物理上实际存在的，是一种逻辑上的，概念上的组合，没有明确的层次关系

五、Designing：

1、ADD

2、4+1 views

六、Documentation：views and beyond

1、structure views的3种类型：

Module view：一系列提供内聚职责的实现单元的集合。从属依赖衍生。

C&C style：展示有了运行时表现的元素 组件：程序、client、server、数据存储等，组件通过端口和连接器交互，连接器是组件间交互的通道。关联。

Allocation：软件单元和环境元素间的映射。目标是比较环境提供的特性与软件元素需要的特性是否相符，来判断分配是否成功。分配。

2、视图的4种分类和目标：

质量视图：用于表示质量属性是怎样的。

Module视图：在代码级别表达系统的功能，用于提供对工作任务定义的支持、提供预算信息和系统应管理的结构信息。

C&C视图：用于展示系统如何运行，通过确定运行时元素的结构和行为指导开发，帮助推导运行时系统质量属性。

Allocation视图：通过对比环境提供的特性与软件元素需要的属性，判断allocation成功与否。

3、列举3种结构视图各自包含哪些style：

Module：分解、使用、泛化、分层、切面、数据模块（分尸犯曾切树）

C&C：管道过滤器、C/S、P2P、SOA、发布者-订阅者、共享数据、多层（PCPSSSM）

Allocation：部署、安装、实现、工作分配、其他分配（不按时工作）

4、documentation package的两部分，各自的目标：

architecture view：

架构视图是一系列特定类型的系统元素和这些元素间关系的表示。

能帮助把系统实体分解为感兴趣和可管理的表示。

documentation beyond views：

超越视图的文档包括架构文档信息和架构信息。

展示了文档路线图，视图如何被文档化的方式，系统概述，视图间映射，基本理论和目录。

5、为什么需要使用多种不同视图来记录架构？

视图用来表示系统中特定类型的元素及元素间关系；

不同视图支持不同的目标和用户，强调不同系统元素和关系；

不同视图在不能程度上揭示不同的质量属性。

七、Evaluation：ATAM

考察方式：

ATAM每步中参与的涉众和涉众在其中的角色；

ATAM每步的输出

ATAM每步做什么

1、评估（why when how）：降成本、降风险、质量保障

why：

大型项目经常推迟交付或超支，或由于设计缺陷不能正常工作；

项目进行过程中有时需要评估并重新设计；

评估的好处：尽早发现问题，降低解决问题的成本；

可以传播架构设计的最佳实践，可以提供优秀项目技术管理。

when：

越早越好：升级更新时；设计时；构造时

尽早评估的原因：有时间修正；修正错误成本不高；有效的质量保障和降低风险；很好的商业活动。

How：

发现风险点；识别错误的架构选择；保证解决了质量属性；基于质量属性场景；场景与架构组件映射，评估架构是否满足质量属性；风险risks；敏感点sensitivity points；权衡点tradeoffs

2、ATAM涉众：

包括三类：设计者；伙伴；外界人士 designers peers outsiders

具体主要有：项目设计决策者，评估小组（评估小组组长），架构涉众，项目经理，系统客户，

每步参与者：

Phase0: 评估计划（评估小组组长，关键的项目设计决策者 （组长和关键策

Phase1: 评估1（评估小组，项目设计决策者（组策

Phase2: 评估2（评估小组，项目设计决策者和架构涉众（组策众

Phase3: 后续（评估小组，主要涉众（诅咒

3、ATAM步骤：Architecture tradeoff analysis method（4个phase：

Phase0: 参与者准备阶段

Phase1: 评估1 包括6步：

1）介绍ATAM方法（评估小组组长

2）介绍商业动机（项目经理或系统客户

3）介绍架构（首席结构师

4）识别使用的架构方法（评估小组

5）生成质量属性效用树（评估小组和项目设计决策者

6）分析架构方法，确保方法时正确的，获取风险点、非风险点、敏感点、权衡点列表（评估小组

Phase2: 评估2 包括9步（6+3）

1）介绍ATAM方法和之前的结果，重复以确保涉众也知道方法并回顾分享之前2-6步的结果

7）头脑风暴，场景划分优先级，与质量属性效用树进行比对（评估小组问涉众

8）分析架构方法，使用新产生的优先级靠前的场景，架构师解释与之相关的架构决定

9）展示结果：（评估小组

Phase3: 后续工作

1）参与者：评估小组和主要涉众（诅咒

4、ATAM每步输出

Phase0: 评估计划（谁、什么时间、提供什么样子的评估报告

Phase1: 评估1（架构简要展示、业务目标、质量属性和相关场景、效用树、风险和非风险点，敏感点，权衡点

Phase2: 评估2（优先级场景列表、风险主题和商业动机、每个涉众关心的业务目标

Phase3: 后续工作（最终的评估报告

八：质量属性和scenarios

availablility：可用性；

interoperability：互操作性。多个系统通过接口交换信息，包括交换和正确推断信息

modifiability：可修改性。一个更改所消耗的时间和金钱。

performance：性能。系统响应时间和系统满足时间需求的能力（=处理时间+等待时间

security：安全性。系统在向合法用户提供服务的同时，阻止非授权使用的能力。

Testablility：可测试性。通过测试揭示软件缺陷的容易程度。

Usability：易用性。用户完成特定任务的容易程度和系统提供的用户支持的种类

X-ability：可变性、可移植性、可伸缩性、可部署性、可复用性

Mobility：移动性，解决平台之间的移动和支持

safety：安全性，和security相比，不是有意为之，关注自身安全，防止偶然可能造成破坏的对象

Variability：可变性，特殊的可修改性

Portability：易于做改变，用于另一种平台

Development Distributability：支持分布式软件开发

Scalability：可伸缩性，对软件系统计算处理能力的设计指标

Deployability：可部署性