哪个网站可以接做美工的活儿,开发一款游戏需要多少资金,嘉兴做营销型网站,个人备案网站 做资讯系统架构评估是在对架构分析、评估的基础上#xff0c;对架构策略的选取进行决策。它利用数学或逻辑分析技术#xff0c;针对系统的一致性、正确性、质量属性、规划结果等不同方面#xff0c;提供描述性、预测性和指令性的分析结果。
重要概念
敏感点#xff1a;敏感点是… 系统架构评估是在对架构分析、评估的基础上对架构策略的选取进行决策。它利用数学或逻辑分析技术针对系统的一致性、正确性、质量属性、规划结果等不同方面提供描述性、预测性和指令性的分析结果。
重要概念
敏感点敏感点是一个或多个构件的特性。研究敏感点可使设计人员或分析人员明确在搞清楚如何实现质量目标时应注意什么。权衡点权衡点是影响多个质量属性的特性是多个质量属性的敏感点。例如改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性但可能要耗费更多的处理时间影响系统性能。如果某个机密消息的处理有严格的时间延迟要求则加密级别可能就会成为一个权衡点。风险点风险点是指那些可能导致项目质量属性目标无法实现的不确定事件或条件非风险点非风险点是指那些不会对项目质量属性目标实现构成威胁的事件或条件。它们通常是项目中的确定因素不具备风险的特点风险承担者/利益相关人系统的架构涉及很多人的利益这些人都对架构施加各种影响以保证自己的目标能够实现。场景进行架构评估时一般首先要精确地得出具体的质量目标并以之作为判定该架构优略的标准。为得出这些目标而采用的机制称之为场景。 场景是从风险承担者的角度对系统的交互的简单描述。在架构评估中一般采用刺激、环境和响应三方面对场景进行描述。 刺激用于描述利益相关者如何引发与系统的交互。环境用于描述刺激发生时的系统情况响应用于描述系统是如何对刺激做出反应的。
架构评估方法 系统架构评估的方法通常可以分为3类基于调查问卷或检查表的方式、基于场景的方式、基于度量的方式
基于调查问卷或检查表的方式该方法的关键是要设计好问卷或检查表充分利用系统相关人员的经验和知识获得对架构的评估。该方法的缺点是在很大程度上依赖于评估人员的主观推断。基于场景的方式基于场景的方式由卡耐基梅隆大学软件工程研究所首先提出并应用在架构权衡分析法ATAM和软件架构分析方法SAAM中。它是通过分析软件架构对场景的支持程度从而判断该架构对这一场景所代表的质量需求和满足程度。基于度量的方式它是建立在软件架构度量的基础上的涉及3个基本活动首先需要建立质量属性和度量之间的映射原则然后从软件架构文档中获取度量信息最后根据映射原则分析推导出系统的质量属性。
SAAM 软件体系结构分析方法
SAAM 的目标是对描述应用程序属性的文档验证基本的架构假设和原则。SAAM 使用的评估技术是场景技术。场景代表了描述架构属性的基础描述了各种系统必须支持的活动和可能存在的状态变化。可修改性是SAAM 分析的主要质量属性SAAM 的主要输入是问题描述、需求声明和架构描述。SAAM 分析评估架构的过程包括 5个步骤包括场景开发、架构描述、单个场景评估、场景交互和总体评估。 SAAM 是一种成熟的方法已被应用到众多系统中这些系统包括空中交互管制、嵌入式音频系统、WRCS 修正控制系统、KWIC 根据上下文查找关键词系统等
ATAM 系统权衡分析法
系统权衡分析方法ATAM是在SAAM 的基础上发展起来的主要针对性能、实用性、安全性和可修改性在系统开发之前对这些质量属性进行评价和折中。架构描述基于5种基本结构来进行这5种结构是从Kruchten 的 41 视图派生而来的。其中逻辑视图被分为功能结构和代码结构。这些结构加上它们之间适当的映射可以完整地描述一个架构。评估技术。可以把ATAM 方法视为一个框架该框架依赖于质量属性可以使用不同的分析技术。它集成了多种优秀的单一理论模型其中每种都能够高效、实用的处理属性。该方法使用了场景技术。从不同的架构角度有3种不同类型的场景 用例包括对系统典型的使用、引出信息增长场景用于涵盖那些对它的系统的修改探测场景用于涵盖那些可能会对系统造成过载的极端修改
ATAM 还使用特定的启发式分析方法在对一个质量属性构造了一个精确分析模型时要进行分析定性的启发式分析方法就是这种分析的粗粒度版本。ATAM 被分为 4个主要的活动领域分别是场景和需求收集、架构视图和场景实现、属性模型构造和分析、架构决策与折中。整个评估过程强调以属性作为架构评估的核心概念。现在的ATAM 的4个活动分为描述和介绍阶段、调查和分析阶段、测试阶段、报告阶段 ATAM 采用有效用树这一工具来对质量属性进行分类和优先级排序。效用树的结构包括树根-质量属性-属性分类-质量属性场景。得到初始效用树后需要修剪这棵树保留重要场景通常不超过50个再对场景按重要性给定优先级,再按场景实现的难易程度来确定优先级(H/M/L的形式)这样对所选定的每个场景就有一个优先级对重要度、难易度)如H、L表示该场景重要且易实现。
架构评估实践
阶段1-- 演示
演示阶段包括的步骤有介绍ATAM、介绍业务驱动因素需求、介绍要评估的体系结构
介绍 ATAM评估小组负责人向参加会议的项目干系人介绍ATAM 评估方法介绍业务驱动因素项目决策者从业务的角度介绍系统的概况。该描述应该包括系统最重要的功能、技术/管理/经济和政治方面的任何相关限制、与该项目相关的业务目标和上下文、主要的项目干系人以及架构的驱动因素等。介绍要评估的体系结构包括技术约束如操作系统、硬件和中间件等将与本系统进行交互的其它系统、用以满足质量属性要求的架构方法等。
阶段2-- 调查和分析
调查和分析步骤包括确定架构方法、生成质量属性效用树、分析体系结构方法
确定架构方法通过理解架构方法来分析架构在这一步由架构设计师确定架构方法。生成质量属性效用树评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标并对这些质量目标设置优先级和细化。分析体系结构方法这一步的主要结果是一个架构方法或风格的列表与之相关的一些问题以及设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表。
这一步分为四个主要阶段 找出风险、非风险、敏感点和权衡点分析问题的答案根据架构对上述分析问题提供合理的解释或答案创建分析问题收集上面讨论过的高优先级场景中产生的分析问题。在现实生活中所有利益相关者都会收集分析问题。分析问题与上面讨论的每种架构方法相关联并面向重要的质量属性调查架构方法在识别出对系统目标至关重要的质量属性后我们分析结构并确定它如何支持这些质量属性。我们对体系结构进行详细的调查以了解这些质量属性要求是否得到满足。
阶段3-- 测试 测试阶段包括头脑风暴和优先场景、分析架构方法
头脑风暴和优先场景项目干系人进行两项相关的活动分别是集体讨论用例场景和改变场景。用例场景是场景的一种在用例场景中项目干系人是一个终端用户使用系统执行的一些功能。一旦收集了若干个场景后必须设置优先级。评估人员通过投票表决的方式来完成。分析架构方法在收集并分析了场景之后设计师就可把最高级别的场景映射到所描述的架构中并对相关的架构如何有助于该场景的实现做出解释。在这一步中评估小组要重复第6步中的工作把新得到的最高优先级场景与尚未得到的架构工作产品对应起来。在第7步中如果未产生任何在以前的分析步骤中都没有发现的高优先级场景则在第8步就是测试步骤。
阶段4-- 报告 ATAM 最后要把ATAM 分析中所得到的各种信息进行归纳并反馈给项目干系人。ATAM 的评估结果包括一个简洁的架构描述、表达清楚的业务目标、用场景集合捕获的质量属性、所确定的敏感点和权衡点的集合、有风险决策和无风险决策、风险主题的集合。 ATAM 团队的主要发现通常包括
一种效用树一组生成的场景一组分析问题一套确定的风险和非风险确定的架构方法
CBAM 成本效益分析法 在大型复杂系统的构建过程中经济性通常是需要考虑的首要因素。因此需要从经济角度建立成本、收益、风险和进度等方面的软件的“经济”模型。成本效益分析法CBAM是在ATAM 上构建用来对架构设计决策的成本和收益进行建模是优化此类决策的一种手段。CBAM 的思想就是架构策略影响系统的质量属性反过来这些质量属性又会为系统的项目干系人带来一些收益CBAM 协助项目干系人根据其投资回报ROI选择架构策略。CBAM 在 ATAM 结束时开始它实际上使用了ATAM 评估的结果。
步骤
整理场景。整理ATAM 中获取的场景根据商业目标确定这些场景的优先级并选取优先级最高的1/3 的场景进行分析。对场景进行求精。为每个场景获取最坏情况、当前情况、期望情况和最好情况的质量属性相应级别。确定场景的优先级。项目关系人对场景进行投票其投票是基于每个场景“所期望的响应值根据投票结果和票的权值生成一个分值场景的权值。分配效用。对场景的响应级别最坏情况、当前情况、期望情况和最好情况确定效用表。架构策略涉及哪些质量属性及响应级别形成相关的”策略-场景-相应级别“的对应关系。使用内插法确定”期望的“质量属性相应级别的效用。即根据第4步的效用表以及第5步的对应关系确定架构策略及其对应场景的效用表。计算各架构策略的总收益。根据第3步的场景的权值及第6步的架构策略效用表计算出架构策略的总收益得分。根据受成本限制影响的ROI 选择架构策略。根据开发经验估算架构策略的成本结合第7步的收益计算出架构策略的ROI按ROI 排序从而确定选取策略的优先级。
SAEM 将软件架构看作一个最终产品以及设计过程中的一个中间产品从外部质量属性和内部质量属性两个角度来阐述它的评估模型旨在为软件架构的质量评估创建一个基础框架。 外部属性指用户定义的质量属性而内部属性指开发者决定的质量属性。该软件架构评估模型包含以下几个流程。
对待评估的质量属性进行规约建模参考ISO/IEC 9126-1 标准中的质量模型先从用户的角度描述架构的外部质量属性再基于外部质量属性规约从开发者的角度描述架构的内部质量属性。为外部和内部的质量属性创建度量准则先从评估目的评估角度评估环境出发来定义架构评估的目标再根据目标相关的属性来提出问题然后回答每个问题并提出相应的度量准则。评估质量属性包括数据集、度量和结果分析3个活动。该模型已在相关系统领域得到应用。
SAABNet 软件架构定性的评估技术依赖于专家知识包括某些特定类型问题的解决方案以及可能的诱导因素、统计知识、审美观等这些定性的知识比较含糊且难以文档化。SAABNet 是一种用来表达和使用定性知识以辅助架构的定性评估。
SACMM SACMM 方法是一种软件架构修改的度量方法首先基于图内核定义差异度量准则来计算两个软件架构之间的距离图内核的基本思想是将结构化的对象描述为它的字结构的集合通过子结构的配对比较来分析对象之间的相似性。
SASAM SASAM 方法通过对预期架构架构设计阶段的相关描述材料和实际架构源代码中执行的架构进行映射和比较来静态地评估软件架构并将静态评估与架构开发方法PuLSE-DSSA 结合识别出10种不同的目的和需求来指导静态的架构评估。 静态评估方法对预期架构模型和实际架构模型中的每个元素进行映射比较某个模型元素或关联是否在两个架构模型中都存在还是只存在于其中某个架构模型中从而得到评估结果其中映射需要手工完成比较评估可以在软件架构可视化和评估工具SAVE 中执行。10个评估目的包括
产品线可能性。分析几个不相干的系统是否适用于某个共有的架构即分析它们是否能成为预期产品线的一部分。产品对准性。评估系统的软件架构是否与产品线的软件架构一致。重用可能性。分析组件是否能重用组件充分性。评估组件的内在质量。对软件架构的理解一致性。评估架构文档和执行的一致性完备性。检测未被文档化的架构实体。软件系统或产品线的文档控制演化支持架构结构的分解
ALRRA ALRRA 是一种软件架构可靠性风险评估方法该方法使用动态复杂度准则和动态耦合度准则来定义组件和连接件的复杂性因素其中动态复杂度准则在某个场景的执行中分析组件的动态行为来度量组件的复杂性动态耦合度准则在某个场景的执行中分析连接件的消息传递协议来度量连接件的复杂性。该方法利用失效模式和影响分析FMEA来定义故障引起的后果的严重性因素并将复杂度和严重性因素组合起来定义组件和连接件的启发式风险因素然后基于组件依赖图定义风险分析模型和风险分析算法将组件和连接件的风险因素集成到架构层次的风险因素中。 使用 ALRRA 方法进行软件架构可靠性评估的步骤
使用架构描述语言ADL建模软件架构使用仿真进行复杂性分析使用FMEA 和失效严重性分析为组件和连接件启发式的定义可靠性风险因素构造架构的CDG 对每个结点 Ci 赋予组件的可靠性风险hrfi对Ci 和Cj 之间连接件赋连接件的可靠性风险hrfij。用图遍历算法执行架构的风险评估和分析架构的可靠性风险因素可以通过集成其组件和连接件的风险因素获取。
AHP 层次分析法AHP 是多种架构评估度量方法的基础理论。AHP 的特点是把复杂问题中的各种因素通过划分为相联系的有序层次使之条理化并在一般情况下通过两两对比根据一定客观现实的主观判断结构把专家意见和分析者的客观判断结果直接、有效地结合起来将一定层次上元素的某些重要性进行定量描述之后利用数学方法计算反应每一层次元素的相对重要性次序的权值并最后通过所有层次之间的总排序计算所有元素的相对权重及对权重进行排序。
层次分析法对AHP 问题域的分析、度量一般分为5步
通过对系统的深入认知确定该系统的总目标得出规划决策所涉及的范围、所要采取的措施方案和政策、实现目标的准则以及策略和各种约束条件等并广泛收集在分析过程中要用到的多种信息。建立一个多层次的递阶结构按目标的不同、实施功能的差异将系统分为几个等级层次。确定以上递阶结构中相邻层次元素间的相关程度通过构造比较判断矩阵即矩阵运算的数学方法确定对于上一层次的某个元素而言本层次中与其相关元素的重要性排序即相对权值。计算各层元素对系统目标的合成权重进行总排序确定递阶结构图中底层的各个元素的重要程度。根据分析计算结果考虑相应的决策。 软件架构评估包括对各种质量属性的评估以及其他一些非功能非质量因素的评估这些属性之间有时存在某些冲突。AHP 是一种重要的辅助决策方法通常被用来解决这些冲突。AHP 可以帮助对提供的设计方案进行整体排名。
COSMIC UML 基于面向对象系统源代码的可维护性度量准则.针对不同表达方式的软件架构采用统一的软件度量COSMIC 方法来进行度量和评估。例如针对UML 组件图描述的软件架构其可维护性度量包括以下3个步骤。
将面向对象的度量准则与COSMIC 方法相关联。对COSMIC 标记进行完善以适用于描述UML 组件图。提出UML 组件图的度量准则复杂度、耦合度和内聚度等 该方法主要是为了辅助分析软件架构的演化方案是否可行并在开源软件DCMMS 的软件架构UML 组件图上得以验证。
