软件系统设计-架构期末

Charlie
  2024-06-06 10:06 2024-06-06 10:06 创建   2024-07-05 12:55:04 2024-07-05 12:55:04 更新    

1. 架构概念

  1. 架构定义
    • 架构定义：软件系统的系统，系统包含元素，元素之间的关系，软件的属性和动态行为
    • 工业界定义：设计阶段最重要设计决定的集合
  2. 软件架构师做什么
  3. 架构来源
    1. 主要：NFR非功能需求
    2. ASR
    3. 质量需求
    4. 利益相关者
    5. 技术环境
  4. 视图 4+1
    1. 逻辑视图：架构的静态关系
    2. 过程视图：运行过程种的变化行为
    3. 物理视图：和物理世界元素的对应关系
    4. 开发视图：开发活动
    5. 用例场景user case scenairos
  5. 架构活动和演化
  6. 软件架构知识域

2. 架构过程

四个阶段，图

2.1. 架构活动

架构实践、确认、维护、演化

image.png
image.png

2.2. 架构设计的活动

● 识别ASRs，指导架构设计的依据
● 考虑已有的框架、风格、模式、tactic
● 形成文档
● 架构的分析和评估 stakeholder参与，是否满足ASR要求

![[软件系统设计-架构期末#9.12. 简要描述在软件架构过程中涉及的⼀般活动，输入输出]]

image.png
image.png

3. 质量属性

  1. 软件需求
    1. 功能需求：系统行为
    2. 质量需求:系统完成工作好坏程度
    3. 约束：需求阶段预设的设计决定，不能妥协
  2. 质量属性
    1. 外部：用户把系统作为黑盒，可以从外部感受的
    2. 内部：可以知道系统内部怎么实现，开发人员，系统是否容易实现和维护
    3. 用刺激相应情景描述
    4. tatics树和设计决定
    5. checklist在七个方面评估质量属性
  3. ASR：
    1. 如何从用户获取ASR？从需求文档（不能提供足够信息，尤其是质量需求），座谈会，商业目标，效用树（Utililty Tree）

4. 架构模式

可以被复用的解决方案

涉及的架构元素
相互之间的关系
需要施加的设计决定

  • 分类
    1. Module 描述静态关系
    2. CNC 组件连接器
    3. 系统动态关系
    4. 系统和外部（物理世界，人，组织….）

Tactic是最小粒度的基本设计决定
Pattern包含需要解决的问题，问题发生的场景，一系列设计决定

image.png

5. 设计架构

  • 通用设计策略

    1. 抽象abstraction
    2. 分解decomposition：分解成一个个问题
    3. 分治divide & conquer
    4. 生成和测试generation and test：先根据ASR、质量属性选择一个初始的设计决定组合，然后看是不是能满足ASR要求
    5. 迭代iteration: 迭代，修正
    6. 重用reuse

  • 设计需要覆盖7个方面

    1. Responsibilities职责：如何分配，不等于功能
      • 还有质量要求，如Monitor是为了可用性而不是实现功能
    2. Coordination：系统元素如何协调通信
    3. Data：数据存储，存储协议，不同介质上的分配
    4. Resource：计算资源，网络，缓存，时间
    5. Elements mapping：元素对应关系，从架构元素到软件元素
    6. Binding time：元素之间的关系什么时候被确定下来
      • 绑定事件越往后，越灵活，但是系统的不确定性增加，测试负担增加
    7. Technology: 实现技术和技术栈的选择

  • ADD

    1. 输入：ASR
    2. 输出：在step 4生成的视图
    3. 8-step process:
      1. confirm requirements
      2. choose an element to decompose,
      3. identify ASRs,
      4. choose a design satisfying ASRs,
      5. instantiate elements & allocate responsibilities,
      6. define interface,
      7. verify & refine requirements,
      8. repeat step 2-7 until all ASRs satisfied
    4. Step4:
      • 4.1 identify concerns,
      • 4.2 list alternatives,
      • 4.3 select patterns/tactics,
      • 4.4 determine relations,
      • 4.5 capture views,
      • 4.6 resolve inconsistencies

6. 架构文档化

  • Views视图
    1. style(viewpoints), pattern and views
    2. Structural views: module views, component and connector views, allocation views
    3. Quality views
  • 文档化视图：
    1. 确定stakeholder，保留提供了大部分stakehodler都关心的信息的视图
    2. 合并视图
    3. 优先级排序，把不重要的视图筛选掉
  • 视图补充信息

7. 评估架构

  • ATAM方法的利益相关者（stackholder）
  • ATAM方法:Architecture Tradeoff Analysis Method
    • 阶段0：团队准备和建立
    • 阶段1：评估1
      1. 介绍ATAM
      2. 介绍商业驱动
      3. 介绍架构
      4. 识别架构方法：通过研究架构文档、听取架构师的展示、向架构师询问设计系统时使用的模式和策略
      5. 生成效用树：确定、排序和优化系统最重要的质量属性目标，并最终用质量属性效用树来详细阐述
      6. 分析架构方法
    • 阶段2：评估2
      1. 介绍ATAM和之前取得的结果（除了效用树）
      2. 头脑风暴，排列场景的优先级
      3. 分析架构方法
      4. 呈现结果
    • 阶段3：后续
      • 评估团队制作一份书面报告，发给主要涉众
  • 不同阶段参加的stackholder不同
    1. phase1 评估团队，决策者
    2. phase2 评估团队，决策者，其他涉众
    3. phase3 评估团队，主要涉众
  • 输入：架构文档
  • 输出：风险（非风险，风险主题），敏感点，权衡点

phase1
phase2 不能向stackholder透露效用树

软考系统架构设计师(十一)：软件架构评估 和 软件质量属性-腾讯云开发者社区-腾讯云

8. 微服务架构

更多考虑他们之间的关系

这里有张图，注意图例

9. 往年题

参考：
软件系统设计复习往年题 | wbl-z’s Blog
2021-软件系统设计-Exam0-往年考试 - SpriCoder的博客

9.1. 如何进行质量属性方案建模？请使用”刺激-相应”图的格式进行建模

  • 如何建模：
    1. 刺激源
    2. 刺激
    3. 工件
    4. 环境
    5. 响应
    6. 响应度量
  • 不同质量属性的刺激响应6要素：
    • image.png

9.2. 描述软件需求、质量属性和架构攸关的需求 (ASR) 之间的区别和关系

  • 联系：
    1. 软件需求包括质量属性和架构重要需求；
    2. 质量属性需求越困难、越重要，就越可能对架构产⽣重⼤影响，因此可能是 ASR；
    3. ASR 的实现可能会影响质量属性
  • 区别：
    1. 软件需求是总体的概念，质量属性是其中⼀部分内容，是整个系统的期望特性，是在功能需求之上的，强调系统需要达到的质量，ASR 是在架构上重要的需求，强调这个需求对于架构有重⼤影响；
    2. 质量属性侧重于描述需求要求的系统质量，ASR 侧重于描述需求可能影响系统架构

9.3. 什么是ASR？

Architecture Significant Requirement，架构攸关需求，是⼀种在架构上有深刻影响的需求。
质量属性需求越困难、越重要，就越有可能对架构产⽣重⼤影响，因此成为 ASR。

9.4. ASR四个来源和方法

  1. 从需求文档获取：MoScoW方法和用户故事
  2. 涉众采访：质量属性工作坊（QAW）
  3. 业务目标：通过理解业务目标获取ASR
  4. 从质量属性效用树获取：通过方案量化描述需求后，逐渐对质量属性进行分解细化，直到包含量化指标为止。

9.5. 设计软件时应用的通用设计策略/一般设计策略有哪些？为这些策略提供一个带有软件架构的简明工作示例

  1. 抽象abstraction
    • 使用抽象让设计师关注本身结构而不关心实现，比如将系统抽象为组件和连接件或抽象为模块。
  2. 分解decomposition：
    • 针对某一个系统关注点分解后处理，比如将整个系统分解或将某个模块分解，使满⾜给定的约束和安排，实现系统的质量和业务⽬标
  3. 分治divide & conquer
    • 对各个模块分别处理
  4. 生成和测试generation and test
    • 将一个特定的设计看作是一个假设；根据测试路径生成测试用例。
  5. 迭代iteration: 迭代，修正
    • 使用迭代的方法，ADD方法多次迭代直到满足所有ASR
  6. 重用reuse
    • 提取设计中可以重用的元素

9.6. ADD方法的过程

  1. 确定需求的信息充足
  2. 选择一个系统元素进行分解
  3. 识别候选的ASR
  4. 选择满足ASR的设计
    1. 识别设计关注点
    2. 从从属关注点列出可选的pattern、tactic
    3. 从列表中选择pattern、tactic
    4. 合成初步架构试图
    5. 评估和解决不一致
  5. 实例化元素并分配职责
  6. 定义实例化元素的接口
  7. 验证和细化需求，并使其成为实例化元素的约束
  8. 重复直到满足所有ASR

9.7. 为什么应该使用不同视图来记录软件架构？给出四个示例视图的名称和目的

  • 原因：
    1. 不同视图支持不同的目标和用户，突出不同的系统元素和关系
    2. 不同视图将不同质量属性暴露出不同的程度
  • 视图名称和目的：
    1. 模块视图 Module View：如何构建为一组实现单元？
    2. 组件和连接器视图 C & C View：如何构建为一组具有运行时行为和交互的元素的？
    3. 分配视图 Allocation View：与环境中的非软件结构有何关系？
    4. 质量视图 Quality Views，安全视图、性能视图、可靠性视图、沟通视图、异常（错误处理）视图
    5. 组合视图：将上述视图进行组合

9.8. 将以下每个问题（左侧）与解决该问题的架构风格/视图（右侧）对应起来。列出每个样式类别的四个视图

  • 连线题
    1. 它是如何构建为一组实现单元的？How it is structed as a set of implementation of units(Module Styles)
    2. 它是如何构建为一组具有运行时行为和交互的元素的？How it is structed as a set of elements that have runtime behavior and interactions?(Component-Connector Styles)
    3. 它与环境中的非软件结构有何关系？How it relates to non-software structures in its environment?(Allocation Styles)
  • Module Styles：分解视图、使用视图、泛化视图、分层视图、领域视图、数据模型视图
  • Component-Connector Styles：管道-过滤器视图、客户端-服务器视图、点对点视图、面向服务视图、发布-订阅视图
  • Allocation Styles：部署视图、安装视图、工作分配视图、其他分配视图。

9.9. 描述4+1视图并绘制

4+1 architectural view model - Wikipedia

  1. 逻辑视图：描述了对架构而言重要的元素和他们之间的关系（功能需求）
    • UML的类图、状态图描述
  2. 过程视图：描述了元素之间的并发和交互。
    • UML的顺序图、通信图、活动图描述
  3. 物理视图：描述了主要过程和组件是如何被映射到硬件上的。
    • UML部署图
  4. 开发视图：描述体系结构的需求，软件开发环境的静态结构
    • UML包图、组件图
  5. 用例场景（Use Case）：捕获架构需求，与一个或多个特定视图相关。
    • 刺激响应图

image.png

9.10. 什么区分了软件产品线架构和单个软件产品架构？

  1. 产品线的目的：实现高可重用性、高修改性。
  2. 产品线之所以有效是因为通过重用可以充分利用产品的共性，从而产生深长的经济性。
  3. 在产品线架构中有一组明确允许发生的变化，然而对于常规架构来说，只要满足了单个系统的行为和质量目标，几乎任何实例都是可以的。因此，识别允许的变化是架构责任的一部分，同时还需要提供内建的机制来实现它们。

9.11. 软件架构涉及哪些风险、敏感点和权衡点？为每个点给出一个例子

  1. ⻛险：可能对所需质量属性产⽣负⾯影响的架构决定；
    • 增加备份数据库导致性能下降；
    • ⽤户的简单密码是安全性的⻛险
  2. 敏感点：对于特定质量属性敏感的架构决定；
    • 可靠性对于增加备份数据库敏感；
    • ⽤户的简单认证降低安全性
  3. 权衡点：影响多个质量属性的架构决定；
    • 增加备份数据库让可靠性提升，让性能下降

9.12. 简要描述在软件架构过程中涉及的⼀般活动，输入输出

  1. 创造系统的商业案例
  2. 理解需求
  3. 创造和选择架构
  4. 与涉众沟通架构
  5. 分析或评估架构
    1. 总的方法
    2. 质量特定方法
  6. 实现架构
  7. 确保架构符合要求
  1. 识别ASRs
    1. 输入：无
    2. 输出：优化的质量属性场景
  2. 架构设计
    1. 输入：优化的质量属性场景、需求和约束、模式和决策
    2. 输出：一组候选视图的草图（模式决定）
  3. 架构文档化
    1. 输入：一组模式决定的草图（由模式决定）
    2. 输出：View & Beyond
  4. 架构评估
    1. 输入：View & Beyond、优化的质量属性场景
    2. 输出：View & Beyond

9.13. 典型的软件架构⽂档包中应该包括什么？简要描述各个组件及其⽤途

  1. 文档路线图：描述文档中有哪些信息，在哪里可以被找到
  2. 描述视图的文档结构
    1. 主要展示：显示视图的元素及其关系，通常图形化
    2. 元素⽬录：详细描述元素及其属性、关系及其属性、元素接⼝和⾏为
    3. 上下⽂图：展示系统和其部分如何与环境关联
    4. 可变性指南：描述该视图如何应对未来架构的任何变化点
    5. 缘由：为什么这个视图反映了设计，提供⼀个令⼈信服的论据以说明它是 健全的
  3. 系统概览：概要地描述系统
  4. 在视图间映射：描述每种视图的相似和映射
  5. 原因：描述最终选择试图的原因
  6. 目录：索引、词汇表、缩略词表

9.14. ATAM每个阶段的输出

  • 阶段0：
    1. 涉众的初步名单
    2. 逻辑：何时？何地？如何？
    3. 评估报告交给谁？
    4. 报告包含什么？
  • 阶段1：
    1. 架构描述
    2. 商业驱动
    3. 作为场景实现的特定质量属性需求的优先级列表
    4. 效用树
    5. 风险和非风险点
    6. 敏感点和权衡点
  • 阶段2：
    1. 涉众社区的场景优先级列表
    2. 风险主题
    3. 受到威胁的业务驱动因素
  • 阶段4：
    • 最终评估报告

9.15. 微服务和SOA的区别、相同点？

  1. 区别
    1. SOA使用企业级总线通信，微服务使用清凉级通信机制
    2. SOA每个服务职责较重，微服务每个服务职责单一
    3. SOA强调中央管理，微服务去中心化
    4. 微服务的耦合比SOA小
  2. 相同
    1. 都采用分布式组件的形式
    2. 各个组件可以相互服务而无需知道细节
    3. 服务自身高内聚，服务间低耦合
    4. 微服务是SOA的一种
  • 标题: 软件系统设计-架构期末
  • 作者: Charlie
  • 创建于 : 2024-06-06 10:06:00
  • 更新于 : 2024-07-05 12:55:04
  • 链接: https://chillcharlie357.github.io/posts/3ff9b627/
  • 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。
评论
此页目录
软件系统设计-架构期末
  1. 1. 架构概念
  2. 2. 架构过程
    1. 2.1. 架构活动
    2. 2.2. 架构设计的活动
  3. 3. 质量属性
  4. 4. 架构模式
  5. 5. 设计架构
  6. 6. 架构文档化
  7. 7. 评估架构
  8. 8. 微服务架构
  9. 9. 往年题
    1. 9.1. 如何进行质量属性方案建模？请使用”刺激-相应”图的格式进行建模
    2. 9.2. 描述软件需求、质量属性和架构攸关的需求 (ASR) 之间的区别和关系
    3. 9.3. 什么是ASR？
    4. 9.4. ASR四个来源和方法
    5. 9.5. 设计软件时应用的通用设计策略/一般设计策略有哪些？为这些策略提供一个带有软件架构的简明工作示例
    6. 9.6. ADD方法的过程
    7. 9.7. 为什么应该使用不同视图来记录软件架构？给出四个示例视图的名称和目的
    8. 9.8. 将以下每个问题（左侧）与解决该问题的架构风格/视图（右侧）对应起来。列出每个样式类别的四个视图
    9. 9.9. 描述4+1视图并绘制
    10. 9.10. 什么区分了软件产品线架构和单个软件产品架构？
    11. 9.11. 软件架构涉及哪些风险、敏感点和权衡点？为每个点给出一个例子
    12. 9.12. 简要描述在软件架构过程中涉及的⼀般活动，输入输出
    13. 9.13. 典型的软件架构⽂档包中应该包括什么？简要描述各个组件及其⽤途
    14. 9.14. ATAM每个阶段的输出
    15. 9.15. 微服务和SOA的区别、相同点？