【愚公系列】软考高级-架构设计师 101-系统架构评估
🏆 作者简介,愚公搬代码
🏆《头衔》:华为云特约编辑,华为云云享专家,华为开发者专家,华为产品云测专家,CSDN博客专家,CSDN商业化专家,阿里云专家博主,阿里云签约作者,腾讯云优秀博主,腾讯云内容共创官,掘金优秀博主,亚马逊技领云博主,51CTO博客专家等。
🏆《近期荣誉》:2022年度博客之星TOP2,2023年度博客之星TOP2,2022年华为云十佳博主,2023年华为云十佳博主等。
🏆《博客内容》:.NET、Java、Python、Go、Node、前端、IOS、Android、鸿蒙、Linux、物联网、网络安全、大数据、人工智能、U3D游戏、小程序等相关领域知识。
🏆🎉欢迎 👍点赞✍评论⭐收藏
🚀前言
系统架构评估(System Architecture Evaluation)是一种系统化的方法,用于分析和评估软件系统的架构设计,确保其满足预期的质量属性和需求。
🚀一、系统架构评估
🔎1.概念
敏感点和权衡点:
-
敏感点:是指为了实现某一种特定的质量属性,一个或多个构件所具有的特性。
-
权衡点:是影响多个质量属性的特性,是多个质量属性的敏感点。
风险承担者(或利益相关人):
- 定义:系统的架构涉及很多人的利益,这些人都对架构施加各种影响,以保证自己的目标能够实现。
软件架构评估:
-
时间节点:软件架构评估在架构设计之后,系统设计之前,因此与设计、实现、测试都没有关系。
-
评估目的:评估的目的是为了评估所采用的架构是否能解决软件系统需求,但不仅限于确定是否满足需求,有时候还需要针对质量属性进行评估架构是否能满足。
🔎2.三种常用的评估方式
🦋2.1 基于调查问卷(检查表)的方式
这种方式类似于需求获取中的问卷调查,但侧重于架构方面的问卷。评估人员需要对领域和架构有一定的了解,才能理解并回答与架构相关的问题。此方式通常用于获取主观反馈和意见,以改进架构。
举例:
对于一个大型电子商务平台的架构评估,评估团队可以向开发团队发送架构调查问卷,询问他们对性能、可维护性和安全性等方面的看法。例如:“您认为当前系统的性能是否满足需求?”或“您认为系统的安全措施是否足够?”
🦋2.2 基于度量的方式
此方式通过制定一些定量指标来度量架构,如代码行数、内存使用、响应时间等,以评估系统的各个方面。评估人员需要对架构的技术细节和度量标准有一定了解。
举例:
对于一个大型数据库管理系统的架构评估,评估团队可以度量数据库查询的平均响应时间、事务处理的吞吐量、数据库表的大小等指标。这些度量可以用于评估系统的性能和可伸缩性。
🦋2.3 基于场景的方式
这是主要的评估方法,涉及定义一系列场景或情境,以测试系统在各种条件下的表现。每个场景描述了一种特定的使用情况,包括输入、预期输出和性能指标。评估人员会模拟这些场景,并评估系统是否满足质量属性需求。场景是从风险承担者的角度对与系统交互的简单描述。
实施过程:
- 确定应用领域的功能和软件架构的结构之间的映射。
- 设计用于体现待评估质量属性的场景(即4+1视图中的场景)。
- 分析软件架构对场景的支持程度。要求评估人员既对领域熟悉,也对架构熟悉。
场景设计的三个方面:
- 刺激(事件):触发架构响应的事件。
- 环境(事件发生的环境):事件发生的背景条件。
- 响应(架构响应刺激的过程):系统如何应对刺激。
举例:
对于一个网络视频流媒体服务的架构评估,评估团队可以定义场景,如“同时1000名用户观看高清视频”或“在网络拥塞时仍能提供无缝的视频流”。然后,他们会模拟这些场景,测试系统的性能、可用性和容错性。
🔎3.基于场景的架构分析方法 (SAAM)
SAAM(Scenario-Based Architecture Analysis Method)是一种用于分析软件系统非功能质量属性的架构分析方法,是最早形成文档并得到广泛应用的软件架构分析方法之一。
🦋3.1 特定目标
SAAM 的目标是对描述应用程序属性的文档进行分析,验证基本的架构假设和原则。
🦋3.2 评估技术
SAAM 使用的评估技术是场景技术,通过定义一系列场景来具体化质量属性。
🦋3.3 质量属性
SAAM 的基本特点是将任何形式的质量属性具体化为场景。尽管可修改性是 SAAM 分析的主要质量属性,但它也可以评估其他质量属性。
🦋3.4 风险承担者
SAAM 协调不同参与者之间感兴趣的共同方面,作为后续决策的基础,达成对架构的共识。
🦋3.5 架构描述
SAAM 用于架构的最后版本,但早于详细设计。架构的描述形式应当被所有参与者理解。架构描述包含功能、结构和分配三个主要方面。
🦋3.6 方法活动
SAAM 的主要输入包括问题描述、需求声明和架构描述。评估过程包括以下五个步骤:
- 场景开发:定义一系列用于评估的场景。
- 架构描述:描述系统的架构,包括功能、结构和分配。
- 单个场景评估:评估每个场景对架构的影响。
- 场景交互:分析多个场景之间的交互和冲突。
- 总体评估:对整个架构进行综合评估,形成最终报告。
🦋3.7 SAAM 分析活动相关输入及评估过程
SAAM 评估活动的相关输入及评估过程如图所示:
例如,对于一个网络视频流媒体服务的架构评估,评估团队可以定义场景,如“同时 1000 名用户观看高清视频”或“在网络拥塞时仍能提供无缝的视频流”。然后,他们会模拟这些场景,测试系统的性能、可用性和容错性。通过 SAAM 方法,可以具体化这些质量属性,确保系统架构能够满足预期需求。
🔎4.ATAM(架构权衡分析法)
ATAM(Architecture Tradeoff Analysis Method)是一种系统架构评估方法,主要在系统开发之前,针对性能、可用性、安全性和可修改性等质量属性进行评价和折中,使架构师明确如何权衡多个质量目标。参与者包括评估小组、项目决策者和其他项目相关人。
🦋4.1 ATAM主要活动领域
ATAM评估过程分为四个主要的活动领域:
-
场景和需求收集
- 收集并定义系统的使用场景和需求,确保所有相关利益方的需求都被考虑。
-
体系结构视图和场景实现
- 通过不同的架构视图展示系统的设计,并演示如何在这些视图中实现收集的场景。
-
属性模型构造和分析
- 为每个质量属性构造模型,并进行分析以评估系统在这些属性上的表现。
-
架构评审与折中
- 对架构进行评审,识别并讨论各质量属性之间的折中关系,以确定最优的架构设计方案。
🦋4.2 质量属性的核心概念
在ATAM评估过程中,质量属性(如性能、安全性、可修改性和可用性)是评估的核心概念。为了对质量属性进行分类和优先级排序,ATAM方法采用效用树(Utility Tree)这一工具。
🦋4.3 效用树的结构
效用树的结构包括:
- 树根:质量属性
- 属性分类:对质量属性进行详细分类
- 质量属性场景:具体的应用场景(叶子节点)
🦋4.4 质量属性的优先级排序
ATAM主要关注的四类质量属性为性能、安全性、可修改性和可用性,因为这些是利益相关者最为关心的。得到初始的效用树后,需要对这棵树进行修剪,保留重要场景(通常不超过50个),再对这些场景按重要性和实现难度进行优先级排序。
🦋4.5 优先级对的确定
- 重要性:用 H(高)、M(中)、L(低)的形式表示
- 难易度:用 H(高)、M(中)、L(低)的形式表示
例如,优先级对 (H, L) 表示该场景重要且易实现。
通过这种方式,每个选定的场景都会有一个优先级对,帮助架构师在系统设计时进行合理的权衡和选择。
在需求分析与架构设计阶段,公司提出了以下需求和质量属性:
-
管理员功能需求
- (a) 管理员能够在页面上灵活设置折扣力度规则和促销活动逻辑,设置后即可生效。
-
安全性需求
- (b) 系统应该具备完整的安全防护措施,支持对恶意攻击行为进行检测与报警。
-
性能需求
- © 在正常负载情况下,系统应在0.3秒内对用户的界面操作请求进行响应。
- (e) 在正常负载情况下,用户支付商品费用后在3秒内确认订单支付信息。
- (f) 系统主站点电力中断后,应在5秒内将请求重定向到备用站点。
- (h) 系统宕机后,需要在10秒内感知错误,并自动启动热备份系统。
-
数据完整性需求
- (d) 用户名是系统唯一标识,要求以字母开头,由数字和字母组合而成,长度不少于6个字符。
-
扩展性需求
- (g) 系统支持横向存储扩展,要求在2人天内完成所有的扩展与测试工作。
-
可维护性需求
- (i) 系统需要内置接口函数,支持开发团队进行功能调试与系统诊断。
- (j) 系统需要为所有的用户操作行为进行详细记录,便于后期查阅与审计。
-
可配置性需求
- (k) 支持对系统的外观进行调整和配置,调整工作需要在4人天内完成。
🦋4.6 需求分类与优先级
需求 | 类型 | 描述 | 重要性 | 难易度 |
---|---|---|---|---|
(a) | 功能需求 | 管理员能够灵活设置折扣和促销活动 | 高 | 中 |
(b) | 安全性需求 | 系统具备安全防护措施,检测并报警 | 高 | 高 |
© | 性能需求 | 系统在0.3秒内响应界面操作请求 | 高 | 高 |
(d) | 数据完整性需求 | 用户名唯一标识,字母开头,长度不少于6字符 | 中 | 低 |
(e) | 性能需求 | 支付后3秒内确认订单支付信息 | 高 | 中 |
(f) | 性能需求 | 电力中断后5秒内重定向到备用站点 | 高 | 高 |
(g) | 扩展性需求 | 支持横向存储扩展,2人天内完成扩展与测试 | 中 | 中 |
(h) | 性能需求 | 宕机后10秒内感知错误并启动热备份系统 | 高 | 高 |
(i) | 可维护性需求 | 内置接口函数,支持功能调试与系统诊断 | 中 | 中 |
(j) | 可维护性需求 | 记录用户操作行为,便于查阅与审计 | 中 | 中 |
(k) | 可配置性需求 | 支持系统外观调整,4人天内完成 | 低 | 中 |
🦋4.7 质量属性
- 性能:
- ©, (e), (f), (h)
- 安全性:
- (b)
- 可修改性:
- (a), (k)
- 可用性:
- (j)
- 扩展性:
- (g)
- 可维护性:
- (i)
- 数据完整性:
- (d)
🔎5.ATAM的阶段解释
🦋5.1 描述和介绍阶段
目标:
- 收集相关架构材料。
- 定义评估目标和评估的软件架构。
- 明确要优化的质量属性。
- 介绍ATAM方法的步骤和原则。
活动:
- 评估团队与项目干系人一起定义评估的目标,确定评估的软件架构。
- 收集架构文档和相关信息。
- 介绍ATAM方法的步骤,以确保所有参与者了解评估的过程。
示例:
- 对于电子商务网站的架构评估,评估团队会与项目干系人合作,确定评估的目标是提高性能和安全性。他们收集有关网站架构的文档,如架构图和设计文档。
🦋5.2 调查和分析阶段
目标:
- 确定架构方法。
- 分析架构并评估这些方法对质量属性的影响。
- 识别潜在的问题和权衡决策。
活动:
- 定义架构方法,分析不同的架构设计。
- 生成质量属性效应树,表示不同决策对质量属性的影响。
- 识别潜在的问题和决策权衡。
产出:
- 质量属性效应树(Quality Attribute Utility Tree),用于表示不同架构决策对质量属性的影响及其之间的权衡关系。
示例:
- 对于电子商务网站的架构评估,评估团队会定义不同的架构决策,如引入缓存或增加服务器资源。他们生成质量属性效应树,以分析这些决策对性能和安全性的影响。
🦋5.3 测试阶段
目标:
- 验证架构是否满足质量属性需求。
活动:
- 创建测试用例模拟质量属性场景,包括性能测试、安全性测试等。
- 运行这些测试用例,测量系统的性能和行为,并记录测试结果。
- 讨论各种质量属性场景,分级它们的重要性。
- 分析不同的架构方法,以确定哪种方法最有可能满足关键场景的需求。
- 项目干系人对不同的架构方法和场景分级进行投票,以帮助确定最佳架构方案。
示例:
- 评估团队讨论电子商务网站的性能、可伸缩性和安全性场景,分级它们的重要性,并分析引入缓存或增加服务器资源等不同架构方法的影响。项目干系人进行投票,以选择最合适的架构方法。
🦋5.4 报告阶段
目标:
- 总结评估的结果。
- 提供改进建议。
- 为决策者提供决策依据。
活动:
- 生成ATAM评估报告,包括评估发现、性能数据、改进建议及权衡决策。
- 报告应清晰传达关键信息,帮助决策者做出明智的架构决策。
示例:
- 电子商务网站的评估报告可能包括性能测试结果、安全性评估、建议的架构改进及与质量属性场景相关的权衡决策。报告将提供给项目管理团队,以指导后续的架构决策和改进。
🔎6.成本效益分析法 (CBAM)
成本效益分析法(CBAM)用于对架构建立的成本进行设计和建模,让决策者根据投资收益率来选择合适的架构。CBAM可以看作是对ATAM(架构贸易分析法)的补充,在ATAM确定质量合理的基础上,再对效益进行分析。
🦋6.1 CBAM的步骤
-
整理场景
- 描述:确定所有相关场景,并对其优先级进行排序。选择优先级最高的三分之一场景进行详细分析。
- 目标:确保关键场景得到优先考虑和分析。
-
对场景进行细化
- 描述:对每个选定场景进行详细分析,确定场景的最佳和最坏情况。
- 目标:全面了解每个场景的潜在影响和结果。
-
确定场景的优先级
- 描述:项目干系人对场景进行投票,根据投票结果确定场景的优先级。
- 目标:反映干系人对不同场景的重视程度和优先级。
-
分配效用
- 描述:对场景的响应级别进行效用分配,建立策略、场景和响应级别的表格。
- 目标:量化不同响应级别的效用,以便进行进一步分析。
-
形成“策略-场景-响应级别的对应关系”
- 描述:将架构策略与场景和响应级别对应起来。
- 目标:明确各策略在不同场景和响应级别下的表现。
-
确定期望的质量属性响应级别的效用
- 描述:根据效用表确定每个具体场景的效用值。
- 目标:量化各质量属性响应级别的效用。
-
计算各架构策略的总收益
- 描述:综合考虑每个架构策略的效用,计算其总收益。
- 目标:评估不同策略的整体效益。
-
根据受成本限制影响的投资报酬率选择架构策略
- 描述:估算成本,用上一步计算的收益减去成本,得出净收益,选择收益最高的架构策略。
- 目标:在成本限制下,选择投资报酬率最高的架构策略。
🦋6.2 示例应用
示例:电子商务网站的架构评估
-
整理场景
- 确定场景如:用户高峰期的系统响应、数据安全保护、系统扩展性等。
- 确定这些场景的优先级,并选择优先级最高的场景进行详细分析。
-
对场景进行细化
- 对用户高峰期的系统响应进行分析,确定最佳情况和最坏情况的系统性能。
-
确定场景的优先级
- 项目干系人对所有场景进行投票,确定哪些场景最为关键。
-
分配效用
- 对用户高峰期响应级别进行效用分配,建立响应级别效用表。
-
形成“策略-场景-响应级别的对应关系”
- 将缓存策略与用户高峰期场景和响应级别对应起来。
-
确定期望的质量属性响应级别的效用
- 确定每个具体场景(如高峰期系统响应)的效用值。
-
计算各架构策略的总收益
- 计算不同架构策略(如增加缓存服务器)的总收益。
-
根据受成本限制影响的投资报酬率选择架构策略
- 估算增加缓存服务器的成本,计算净收益,并选择收益最高的策略。
🔎7.其他评估方法
🦋7.1 SAEM方法
SAEM(Software Architecture Evaluation Model)方法将软件架构视为一个最终产品和设计过程中的一个中间产品,从外部质量属性和内部质量属性两个角度阐述评估模型,旨在为软件架构的质量评估创建基础框架。外部属性指用户定义的质量属性,而内部属性指开发者决定的质量属性。
评估流程:
- 对待评估的质量属性进行规约建模。
- 创建度量准则:
- 确定评估目的(如软件架构比较、最终产品的质量预测)。
- 确定评估角度(如开发者、用户、维护者)。
- 确定评估环境(架构作为最终产品或设计中间产品)。
- 根据目标相关的属性提出问题,然后回答每个问题并提出相应的度量准则。
- 评估质量属性:
- 数据收集。
- 度量。
- 结果分析。
🦋7.2 SAABNet方法
SAABNet方法用于表达和使用定性知识辅助架构的定性评估,来源于人工智能允许不确定、不完整知识的推理。使用BBN(Bayesian Belief Network)表示和使用开发过程中的知识,包含定性和定量描述。
变量分类:
- 架构质量属性变量(如可维护性、灵活性)。
- 质量属性的度量准则变量(如容错性、响应性)。
- 架构特征变量(如继承深度、编程语言)。
评估流程:
- 高层抽象的质量属性变量分解为低层抽象的度量准则变量。
- 度量准则变量分解为更低层抽象的架构特征变量。
🦋7.3 SACMM方法
SACMM(Software Architecture Change Management Model)是一种软件架构修改的度量方法。
🦋7.4 SASAM方法
SASAM(Software Architecture Static Analysis Method)通过对预期架构(架构设计阶段的相关描述材料)和实际架构(源代码中执行的架构)进行映射和比较来静态地评估软件架构。
🦋7.5 ALRRA方法
ALRRA(Architecture Level Reliability Risk Assessment)是一种软件架构可靠性风险评估方法,使用动态复杂度准则和动态耦合度准则来定义组件和连接件的复杂性因素。
评估流程:
- 动态复杂度准则:在某个场景的执行中分析组件的动态行为来度量组件的复杂性。
- 动态耦合度准则:在某个场景的执行中分析连接件的消息传递协议来度量连接件的复杂性。
- 使用失效模式和影响分析(FMEA)技术。
🦋7.6 AHP方法
AHP(Analytic Hierarchy Process)是一种对定性问题进行定量分析的多准则决策方法。
特点:
- 将复杂问题中的各种因素通过划分为相联系的有序层次,使之条理化。
- 通过两两对比,根据一定客观现实的主观判断,将专家意见和分析者的客观判断结果结合起来。
- 通过数学方法计算每一层次元素的相对重要性次序的权值,最后计算所有元素的相对权重及排序。
🦋7.7 COSMIC+UML方法
基于度量模型来评估软件架构可维护性的方法。采用统一的COSMIC(Common Software Measurement International Consortium)度量方法来进行度量和评估,主要用于辅助分析软件架构的演化方案是否可行,并在开源软件DCMMS的软件架构UML组件图上进行验证。
🚀二、练习
🔎1.题目一
🔎2.题目二
🔎3.题目三
🚀感谢:给读者的一封信
亲爱的读者,
我在这篇文章中投入了大量的心血和时间,希望为您提供有价值的内容。这篇文章包含了深入的研究和个人经验,我相信这些信息对您非常有帮助。
如果您觉得这篇文章对您有所帮助,我诚恳地请求您考虑赞赏1元钱的支持。这个金额不会对您的财务状况造成负担,但它会对我继续创作高质量的内容产生积极的影响。
我之所以写这篇文章,是因为我热爱分享有用的知识和见解。您的支持将帮助我继续这个使命,也鼓励我花更多的时间和精力创作更多有价值的内容。
如果您愿意支持我的创作,请扫描下面二维码,您的支持将不胜感激。同时,如果您有任何反馈或建议,也欢迎与我分享。
再次感谢您的阅读和支持!
最诚挚的问候, “愚公搬代码”
- 点赞
- 收藏
- 关注作者
评论(0)