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
- confirm requirements 确认要求
- choose an element to decompose 选择要分解的元素
- identify ASRs 识别ASR
- choose a design satisfying ASRs 选择满足ASR的设计（选择架构模式）
- instantiate elements & allocate responsibilities 实例化元素并分配职责
- define interface 定义接口
- verify & refine requirements 验证和完善需求
- 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周