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

软件架构

基础知识

什么是软件架构

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

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

架构师是做什么的

架构师的工作不是创造性的一种设计，更多的是在和不同的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)

可用性

可修改性

性能

安全性

可测试性

易用性

略

具体场景（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周