NJU SE 软件系统设计期末复习——架构设计部分

软件架构

基础知识

什么是软件架构

某个软件或计算系统的软件架构是该系统的一个或多个结构，它们由软件元素、这些元素的外部可见属性以及这些元素之间的关系组成。

（架构是设计的一部分，是设计的最早期的阶段最重要的决定）

架构师是做什么的

架构师的工作不是创造性的一种设计，更多的是在和不同的stakeholder去交流沟通各方面的需求、限制、约束的，最终达成妥协的结果。在技术方面，他对于实现的技术要有所了解；在工程管理方面，也要有一定的经验。

架构的来源

• NFRs，即非功能化需求。功能化需求描述的是系统要实现的功能，非功能化需求就是除此以外的部分。非功能化需求是架构的主要来源。非功能化需求进一步划分，可以分为质量需求和约束。质量需求就是指完成功能化需求所定义的工作的质量，如做得有多好、让客户多满意等；约束是做架构设计之前已有的，没有任何妥协的余地，不能修改，只能平衡其他方面来满足约束条件
• ASRs，即架构攸关的需求。ASRs是从各种需求中识别出来的需求，如安全性、可用性等
• 架构还可以通过不同的因素考虑，不同的利益相关者或涉众对自身的利益有不同的考虑。比如，最终用户可能更关注外部的质量属性，如系统的易用性、安全性等；而开发人员可能更关心系统的内部即不可观测到的质量属性，比如系统的可修改性、可测试性等。一个架构要满足不同的stakeholder的利益、不同组织的商业目标、具体制约架构设计的技术环境等等因素。

架构视图

概念

• 视图是架构元素的内聚集的表示，由系统涉众编写和阅读。它由一个元素集的表示和元素之间的关系组成。

• 结构是元素本身的集合，它们存在于软件或硬件中。

例如，模块结构是系统的模块和其组织的集合。模块视图时该结构的表示，由某些系统涉众编档和使用。

视图4+1

• 逻辑视图（Logical view）
  • 描述系统的静态结构、组成关系
• 过程视图（Process view）
  • 描述系统运行起来的时候，各部分之间的关系、行为
• 物理视图（Physical view）
  • 描述软件系统，将虚拟的软件用物理的方式描述展现
• 开发视图（Development view）
  • 开发人员使用，与逻辑视图关联。描述了开发人员的分工、过程
  • 还会考虑跟项目管理有关的内容，比如交付日期、成本等

这四类视图从不同的角度看系统，同时都在描述一个使用案例场景场景（Use case scenarios）

每一个场景都会涉及到这四类视图

架构活动与过程

架构相关活动

• 架构设计
• 架构实现
• 架构维护
• 架构演化

架构过程

课程主要关心架构设计阶段的相关活动

主要由以下四个活动串联起来：

• 识别ASR
• 架构设计
• 文档化
• 架构评估

识别ASR

要知道为谁、为什么去设计，找到设计依据，并不是所有需求都要在架构阶段完成设计，只是一少部分需求，那么就要把这些需求从很多需求中挑选出来，形成ASR。

架构设计

识别出ASR后，把它作为输入，进行架构设计，采用ADD方法。输入除了ASR之外，还有跟这些ASR相关Pattern和tactics成了候选考虑。

文档化

完成设计后，生成一系列视图。

架构评估

生成的文档作为输入Evaluation，进行评估。除了架构文档之外，还有Stakeholders参与，因为他们是最初的需求来源。此外，这其中还会存在迭代，即如果没有通过评估，还会再回到架构设计，进行进一步的设计和改进。

以上就是课堂所关注的架构设计

质量属性

• 功能化需求 Software Requirements

• 质量属性 Quality Attributes

• 架构攸关需求 Architecturally Significant Requirements

往往交替互换使用上述三个名词，把它们看作近似等价

质量属性建模

使用刺激—响应方式，对每一个质量属性由以下6个元素组成描述：

• 源 Source
• 刺激 Stimulus
• 制品 Artefact
• 环境 Environment
• 响应 Response
• 响应度量 Measure

一般场景（General scenarios)

可用性

场景的组成部分	可能的值
源	系统内部、系统外部
刺激	错误；疏忽、崩溃、时间、响应
制品	系统的处理器、通信信道、持久存储器、进程
环境	正常操作、降级模式（也就是更少的特性，这是一种后退（fall back）的解决方案）
响应	系统应该检测到事件，并进行如下一个或多个活动： 1. 将其记录下来 2. 通知适当的各方，包括用户和其他系统 3. 根据已定义的规则禁止导致错误或故障的事件源 4. 在一段预先指定的时间间隔内不可用，其中，时间间隔取决于系统的关键程度 5. 继续在正常或降级模式下运行
响应度量	1. 系统必须可用的时间间隔 2. 可用时间 3. 系统可以在降级模式下运行的时间 4. 修复时间

可修改性

场景的组成部分	可能的值
源	最终用户、开发人员、系统管理员
刺激	希望增加/删除/修改/改变功能、质量属性、容量
制品	系统用户界面、平台、环境或与目标系统交互的系统
环境	在运行时、编译时、构建时、设计时
响应	查找架构中需要修改的位置，进行修改且不会影响其他功能，对所做的修改进行测试，部署所做的修改
响应度量	根据所影响的元素数量度量的成本、努力、资金；该修改对其他功能或质量属性所造成影响的程度

性能

场景的组成部分	可能的值
源	大量的独立源中的一个，可能来自系统内部
刺激	定期事件到达；随机事件到达；偶然事件到达
制品	系统
环境	正常模式；超载模式
响应	处理刺激；改变服务级别
响应度量	等待事件、期限、吞吐量、抖动、缺失率、数据丢失

安全性

场景的组成部分	可能的值
源	正确识别、非正确识别或身份未知的个人或系统它来自内部/外部； 经过了授权/未经授权
刺激	试图显示数据、改变/删除数据、访问系统服务、降低系统服务的可用性
制品	系统服务、系统中的数据
环境	在线或离线、联网或断网、连接有防火墙或直接连接到了网络上
响应	对用户进行身份验证 隐藏用户的身份 阻止对数据和/或服务的访问 允许对数据和/或服务的访问 授予或收回对访问数据和/或服务的许可 根据身份记录访问/修改或试图访问/修改数据/服务 通知用户或另外一个系统，并限制服务的可用性
响应度量	用成功的概率表示避开安全防范措施所需要的时间/努力/资源 检测到攻击的可能性 确定攻击或访问/修改数据和/或服务的个人的可能性 在拒绝服务攻击的情况下仍然可以获得的服务的百分比 恢复数据/服务 被破坏的数据/服务和/或拒绝的合法访问的范围

可测试性

场景的组成部分	可能的值
源	单元开发人员 增量集成人员 系统验证人员 客户验收测试人员 系统用户
刺激	已完成的分析、架构、设计、类和子系统集成 所交付的系统
制品	设计、代码段、完整的应用
环境	设计时、开发时、编译时、部署时
响应	提供对状态值的访问 提供所计算的值} 准备测试环境
响应度量	已执行的可执行语句的百分比 如果存在缺陷出现故障的概率 执行测试的时间 测试中最长依赖链的长度 准备测试环境的时间

易用性

略

具体场景（Concrete scenarios）

设计的时候主要使用具体场景

质量属性对应的战术（Tactics）

可用性战术

• 错误检测
  • 命令/响应（ping/echo）
  • 心跳（heartbeat）
  • 异常
• 错误恢复
  • 表决
  • 主动冗余（热重启）
  • 被动冗余（暖重启/双冗余/三冗余）
  • 备件
  • shadow操作
  • 状态再同步
  • 检查点/回滚
• 错误预防
  • 从服务中删除
  • 事务
  • 进程监视器

可修改性战术

• 局部化修改
  • 维持语义的一致性
  • 预期期望的变更
  • 泛化该模块
  • 限制可能的选择
• 防止连锁反应
  • 信息隐藏
  • 维持现有的接口
  • 限制通信路径
  • 仲裁者的使用
• 推迟绑定事件
  • 运行时注册
  • 配置文件
  • 多态
  • 组件更换
  • 遵守已定义的协议

性能战术

• 资源需求
  • 提高计算效率
  • 减少计算开销
  • 管理事件率
  • 控制采样频率
  • 限制执行时间
  • 限制队列大小
• 资源管理
  • 引入并发
  • 维持数据或计算的多个副本
  • 增加可用资源
• 资源仲裁

安全性战术

• 抵抗攻击
  • 对用户进行身份验证
  • 对用户进行授权
  • 维护数据的机密性
  • 维护完整性
  • 限制暴露的信息
  • 限制访问
• 检测攻击
• 从攻击中恢复

可测试性战术

• 输入/输出
  • 记录/回放
  • 将接口与实现分离
  • 特化访问路线/接口
• 内部监视
  • 内置监视器

易用性战术

• 运行时战术
  • 维持任务的一个模型
  • 维持用户的一个模型
  • 维持系统的一个模型
• 设计时战术
  • 将用户接口与应用的其余部分分离开来

战术与架构模式的关系

任何模式都会实现几个战术，它们通常与不同的质量属性有关；并且该模式的任何实现都对战术做出了选择

Architecturally Significant Requirements

怎样去找到ASR

• 需求
  • 可能会发现一些质量属性，但不一定足以支撑设计，可能缺乏度量方法；需要对其进行评估，选取一些重要的需求
• 与Stakeholders交流（Interviews)
• 商业目标（系统是用来干什么）
  • 不同的需求可能都很重要，但它们可能会竞争资源，最终判断依据就是它
• 质量属性效用树
  • 识别需求的过程中，识别出哪些是重要需求，可以被纳入到ASR中的时候，把它加入质量属性效用树

架构模式

一个架构模式是用来解决在某一个具体的上下文环境（context）中所出现的问题，对于这个问题的一个解决方案构成了架构模式。（Solution：元素之间的关系满足什么样的约束）

Module Patterns 模块

模块看的是在设计时系统的分解，分成不同的模块。一旦完成设计模块，就变成了架构的component

• Layered pattern

Component-Connector Patterns 组件-连接器

从动态的、运行时的角度去观察系统

• Broker pattern
• Model-view-controller pattern
• Pipe-and-filter pattern
  • pipe—connection、filter—component
• Client-server pattern
• Peer-to-peer pattern
• Service-oriented pattern SOA
• Publish-subscribe pattern
• Share-data pattern

Allocation Patterns 分配

软件映射到什么硬件的元素上

• Map-reduce pattern
  • 通过引入并行提高效率
• Multi-tier pattern
  • 把不同的元素作为一个组合放到某个平台上

设计架构

General Design Strategy

• Abstraction
• Decomposition
• Divide & conquer
• Generation and test
• Iteration
• Reuse

Attribute-Driven Design

ADD是一种定义软件架构的方法，该方法将分解过程建立在软件必须满足的质量属性之上。它是一个递归分解的过程，其中在每个阶段都选择战术和架构模式来满足一组质量属性场景，然后对功能进行分配，以实例化由该模式所提供的模块类型

• Choose a part to design 选择要设计的部分
• Marshal all ASRs for that part 把那部分的所有ASR整理好
• Create and test a design for that part 创建并测试该部件的设计
• Inputs to and outputs of ADD ADD的输入和输出

8-step process

1. confirm requirements 确认要求
2. choose an element to decompose 选择要分解的元素
3. identify ASRs 识别ASR
4. choose a design satisfying ASRs 选择满足ASR的设计（选择架构模式）
5. instantiate elements & allocate responsibilities 实例化元素并分配职责
6. define interface 定义接口
7. verify & refine requirements 验证和完善需求
8. repeat step 2-7 until all ASRs satisfied 重复步骤2-7，直到所有ASR满意

文档化架构

Views and Beyond 视图并超越视图

大部分架构的决定通过视图反映出来

我们通不过不同的视角会生成不一样的视图

视图

结构视图

• 模块视图
• C&C视图
• 分配视图

质量视图

放在架构文档里的是最重要的视图，能反映出架构信息

如何识别视图的重要性

• 建立Stakeholder/view table
  • 反映了视图对不同stakeholder的重要性、详细程度，找到大部分人关心的视图
• 组合视图
  • 组合上一步得到的视图，让某一视图展现更多的信息
• 优先次序和阶段
  • 对于筛选/合并后的视图进行排序，最重要的视图可能作为后面详细设计的依据

beyond

在视图部分，生成的都是单独的；缺少的是跨越不同视图的部分，即系统间的视图关系

架构评估

ATAM: Architecture Tradeoff Analysis Method 体系结构权衡分析方法

ATAM一种进行构架评估的综合方法，ATAM是评估软件构架的一个健壮的方法。在该方法中，项目决策者和涉众要清晰地阐述一个准确的质量属性需求列表（以场景的方式），并说明与实现每个高优先场景相关的构架决策。然后，把这些决策确定为有风险决策或无风险决策，以找到构架中任何存在问题的地方。

ATAM不是需求评估。

ATAM不是代码评估。

ATAM不包括实际的系统测试。

ATAM不是一个准确的手段，但它识别了构架中可能存在风险的区域。这些风险包含在敏感点和权衡中。

选择ATAM的原因

• 通用的架构评估方法（很多其他方法只关心某一个质量属性）

四个阶段

• 第0阶段（合作关系和准备）确定细节
• 第1阶段，评估阶段，决策者参与，小组开始信息收集与分析；耗时约1周。1～2周中断期，评估小组进一步以非正式方式了解构架
  • ATAM方法的表述。评估负责人向决策者表述ATAM方法，使大家理解其过程，了解角色布局
  • 商业动机的表述。决策者介绍系统商业动机、重要功能、各种限制（任何相关的技术、管理、经济和政治限制）、商业目标和上下文、主要的涉众、驱动因素等。
  • 构架的表述。首席设计师或架构小组介绍构架，技术限制、所用模式等
  • 对构架方法进行分类。评估小组利用所有已知信息对构架方法进行分类
  • 生成质量属性效用树。生成质量属性效用树，捕获详细的需求信息，为每个场景分配一个级别，如（高，中），前者为重要度，后者为实现难易度，重点放在（高，高）的场景；此处场景具备刺激、环境、响应三要素就可以了
  • 分析构架方法。评估小组分析所有重要场景，设计师解释如何支持该场景，检查所用构架方法，分析风险点、权衡点、敏感点
• 第2阶段，评估阶段，涉众参与，分析继续；约2天
  • 集体讨论并确定场景的优先级。集体讨论并分析场景的优先级，以了解更广泛的涉众的想法；该过程可能产生新的场景；使用“有限票数法”投票确定每个场景的优先级——此处不考虑实现难度
  • 分析构架方法。分析新的高优先级的场景，构架师解释构架是怎么满足各场景的
  • 结果表述。总结评估结果，评估负责人展示该结果
• 第3阶段，后续阶段，生成最终报告，进行评估活动总结；1周