系统架构设计师—系统架构设计篇—架构评估

洛北辰南

于 2025-03-09 00:20:26 发布

阅读量663

点赞数 25

CC 4.0 BY-SA版权

分类专栏：系统架构设计师文章标签：系统架构架构架构评估质量属性

本文链接：https://blog.csdn.net/qq_18941713/article/details/146125394

系统架构设计师专栏收录该内容

38 篇文章

订阅专栏

质量属性

分类

开发期质量属性

子属性	作用及要点
易理解性	指设计被开发人员理解的难易程度。
可扩展性	软件因适应新需求或需求变化而增加新功能的能力，也称灵活性。
可重用性	指重用软件系统或某一部分的难易程度。
可测试性	对软件测试以证明其满足需求规范的难易程度。
可维护性	当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
可移植性	将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

运行期质量属性

子属性	作用及要点
性能	软件系统及时提供相应服务的能力，如速度、吞吐量和容量等。
安全性	软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
可伸缩性	当用户数和数据量增加时，软件系统维持高服务质量的能力。
互操作性	软件系统与其他系统交互数据和相互调用服务的难易程度。
可靠性	软件系统在一定的时间内持续无故障运行的能力。
可用性	系统在一定时间内正常工作的时间所占比例。
鲁棒性	软件系统在非正常情况（用户进行非法操作、相关软硬件系统发生故障）下仍正常运行的能力，也称健壮性或容错性。

面向架构评估的质量属性

属性		作用及要点
性能		处理任务所需时间/单位时间内的处理量。
可靠性	容错性	出现错误后仍能保证系统正确运行，且自行修正错误。
可靠性	健壮性	错误不对系统产生影响，按既定程序忽略错误。
可用性		正常运行的时间比例，出现故障多久能启用备用系统。
安全性		系统向合法用户提供服务并阻止非法用户的能力。
可修改性	可维护性	错误发生后进行局部性修改，对其他构件负面影响最小。
可修改性	可扩展性	使用新构件、改进或删除原有构件或特性。
可修改性	结构重组	重新组织构件及构件关系、灵活配置构件。
可修改性	可移植性	多样的环境（硬件平台、语言、操作系统等）。
功能性		需求的满足程度。
可变性		总体架构可变。
互操作性		通过可视化或接口方式提供更好的交互协作体验。
易用性		在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。

质量场景

质量属性场景是一种面向特定的质量属性的需求。

质量场景的6个组成部分：

刺激源：谁造成的刺激。
刺激：一个响应系统的情况。
制品：系统被刺激的部分。
环境：刺激发生时，系统所处的状态。
响应：刺激所产生的结果。
响应度量指标：如何评估响应。

重点

性能

处理任务所需时间或单位时间内的处理量。

提升策略

资源需求
- 减少处理事件时对资源的占用、减少处理事件的数量、控制资源的使用。
资源管理
- 并发机制、增加资源。
资源仲裁
- 先来先服务、固定优先级、动态优先级、静态调度。

可用性

系统正常运行的时间比例，出现故障多久能启用备用系统。

提升策略

错误检测
- 心跳、Ping/Echo、异常。
错误恢复
- 表决、主动冗余、被动冗余、重新同步、内测、检查点/回滚。
错误避免
- 服务下线、事务、进程监控器。

安全性

系统向合法用户提供服务，并阻止非法用户的能力。

提升策略

抵抗攻击
- 用户身份验证、用户授权、维护数据机密性与完整性、限制暴露、限制访问。
检测攻击
- 入侵检测系统。
从攻击中恢复
- 恢复状态、识别攻击者。

可修改性

能够快速地以较高的性价比对系统进行变更的能力。

提升策略

局部化修改
- 高内聚低耦合、预测变更、使模块通用。
防止连锁反应
- 信息隐藏、维持现有接口、限制通信路径、使用中介。
推迟绑定时间
- 运行时注册、多态、配置文件。

质量特性

名称	特征
敏感点	为了实现某种特定的质量属性，一个或多个系统组件所具有的属性。
权衡点	影响多个质量属性的特征，是多个属性的敏感点。
风险点	某些做法有一些隐患可能导致一些问题。
非风险点	某些做法是可行的，可接受的。

架构评估方法

重点

SAAM-软件架构分析方法

主要输入
- 问题描述
- 需求说明
- 架构描述
分析过程
- 场景开发
- 架构描述
- 单个场景评估
- 场景交互
- 总体评估

分析过程

在这里插入图片描述

ATAM-架构权衡分析方法

针对性能、可用性、安全性、可修改性等质量属性进行评价和折中。

ATAM可以分为4个主要的活动阶段：

需求收集
架构视图描述
属性模型构造和分析
架构决策和折中

整个评估过程强调以属性作为架构评估的核心概念。

最初的ATAM
在这里插入图片描述

现在的ATAM
在这里插入图片描述

评估参与者

评估小组：组织内部或外部的、扮演特定角色
项目决策者：项目管理人员、重要客户代表、架构师
项目干系人：模块开发人员、测试人员、用户

评估活动步骤

描述ATAM方法：评估小组负责人向参加会议的项目干系人介绍ATAM评估方法。
描述业务动机：项目决策者从业务的角度介绍系统的概况。
1. 该描述应该包括系统最重要的功能、技术/管理/经济和政治方面的任何相关限制、与该项目相关的业务目标和上下文、主要项目的干系人，以及架构的驱动因素等。
描述架构：包括技术约束，将与本系统进行交互的其他系统，用以满足质量属性要求的架构方法等。
确定架构方法：通过理解架构方法来分析架构，在这一步，由架构设计师确定架构方法。
生成质量属性效用树：评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些质量目标设置优先级和细化。
分析架构方法：这一步的主要结果是一个架构方法或风格的列表，与之相关的一些问题，以及设计师对这些问题的回答。
1. 通常产生一个风险列表、敏感点和权衡点列表。
讨论场景和对场景的分级：项目干系人进行两项相关的活动，分别是集体讨论用例场景和改变场景。
1. 用例场景是场景的一种，在用例场景中，项目干系人是一个终端用户，使用系统执行的一些功能。
2. 一旦收集了若干个场景后，必须设置优先级。
3. 评估人员通过投票表决的方式来完成。
分析架构方法：在收集并分析了场景之后，设计师就可把最高级别的场景映射到所描述的架构中，并对相关的架构如何有助于该场景的实现做出解释。
1. 在这一步中，评估小组要重复第六步中的工作，把新得到的最高优先级场景与尚未得到的架构工作产品对应起来。
2. 在第七步中，如果未产生任何在以前的分析步骤中都没有发现的高优先级场景，则在第八步就是测试步骤。
描述评估结果：最后，要把ATAM分析中所得到的各种信息进行归纳，并反馈给项目干系人。
1. ATAM的评估结果包括一个简洁的架构描述、表达清楚的业务目标、用场景集合捕获的质量属性、所确定的敏感点和权衡点的集合、有风险决策和无风险决策、风险主题的集合。