精华内容
下载资源
问答
  • 架构权衡分析法ATAM
    千次阅读
    2017-10-20 10:48:40

    Architecture Tradeoff Analysis Method

    使用ATAM方法对软件架构进行评估的目标,是理解架构关于软件的质量属性需求决策的结果。ATAM方法不但提示了架构如何满足特定的质量目标,而且还提供了这些质量目标是如何交互的,即它们之间是如何权衡的。

     

    最后欢迎大家访问我的个人网站:1024s

    ​​​​​​​

     

    更多相关内容
  • 架构权衡分析方法3.质量属性效用树4.可靠性   在软件考试中,可用性,稳定性,可靠性和连续性的概念难以分清,本概念来自互联网,供读者参考: 可用性:保持稳定态的时长。 稳定性:抵御故障的能力。 可靠性:故障...


      在软件考试中,可用性,稳定性,可靠性和连续性的概念难以分清,本概念来自互联网,供读者参考:

    • 可用性:保持稳定态的时长。
    • 稳定性:抵御故障的能力。
    • 可靠性:故障的频率。
    • 连续性:恢复能力。

    质量属性效用树主要关注性能、可用性、安全性和可修改性。

    1.软件质量属性

      《GB/T16260-1996(idt ISO/IEC9126:1991)信息技术软件产品评价质量特性及其使用指南》中描述的软件质量特性包括功能性、可靠性、易用性、效率、可维护性、可移植性等 6 个方面,每个方面都包含若干个子特性。

    功能性:适合性、准确性、互操作性、安全性;
    可靠性:成熟性、容错性、依从性、易恢复性;
    易用性:易理解性、易学性、易操作性;
    效率:时间特性、资源特性;
    可维护性:易分析性、易改变性、稳定性、易测试性;
    可移植性:适应性、易安装性、遵循性、易替换性;

    1.1运行期质量属性

    性能:性能是指软件系统及时提供相应服务的能力。包括速度、吞吐量和持续高速性三方面的要求。
    安全性:指软件系统同时兼顾向合法用户提供服务,以及阻止非授权使用的能力。
    易用性:指软件系统易于被使用的程度。
    可伸缩性:指当用户数和数据量增加时,软件系统维持高服务质量的能力。例如,通过增加服务器来提高能力。
    互操作性:指本软件系统与其他系统交换数据和相互调用服务的难易程度。
    可靠性:软件系统在一定的时间内无故障运行的能力。
    持续可用性:指系统长时间无故障运行的能力。与可靠性相关联,常将其纳入可靠性中。
    鲁棒性:是指软件系统在一些非正常情况(如用户进行了非法操作、相关的软硬件系统发生了故障等)下仍能够正常运行的能力。也称健壮性或容错性。

    1.2开发期质量属性

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

    1.3提高质量属性架构策略

    • 可用性:心跳,Ping/Echo,主动冗余、被动冗余、选举等架构策略。
    • 性能:增加计算资源、减少计算开销、引入并发机制、采用资源调度等架构策略。
    • 安全性:入侵检测、用户认证、用户授权、追踪审计等架构策略

    2.架构权衡分析方法

       ATAM(Architecture Tradeoff Analysis Method),主要包括场景和需求收集、架构视图和场景实现、属性模型构造和分析和属性模型折中四个阶段。

    3.质量属性效用树

      它是对质量属性进行分类、权衡、分析的架构分析工具,主要关注系统的性能、可用性、可修改性和安全性四个方面。

    4.可靠性

      系统可靠性是指系统在规定的时间内及规定的环境条件下,完成规定功能的能力,就是系统无故障运行的概率。4个主要子特性。

    • 成熟性:成熟性是指系统避免因错误的发生而导致失效的能力。
    • 容错性:容错性是指在系统发生故障或者违反指定接口的情况下,系统维持规定的性能级别的能力。
    • 易恢复性:易恢复性是指系统发生失效的情况下,重建规定的性能级别并恢复受直接影响的数据的能力。
    • 依从性:可靠性的依从性是指系统依附于与可靠性相关的标准、约定或规定的能力。

       提高可靠性的技术方法:冗余技术、软件容错技术、双机容错技术和集群技术。

      软件的可靠性设计主要包括恢复快和N版程序设计两种方法。
      主块–>验证测试–>正确结果–>异常处理

    展开全文
  • 基于软件架构分析方法(SAAM)和架构权衡分析方法(ATAM),提出了一种基于场景的软件架构分析方法,该方法通过基于场景的分析过程,建立相应的场景库和评价指标树,为软件架构分析提供了一种轻量级的分析方法。
  • 基于软件架构分析方法(SAAM)和架构权衡分析方法(ATAM),提出了一种基于场景的软件架构分析方法,该方法通过基于场景的分析过程,建立相应的场景库和评价指标树,为软件架构分析提供了一种轻量级的分析方法。
  • 本文从理解需求种类的复杂性谈起,通过具体案例的分析,展示了如何通过RUP的4+1视图方法,针对不同需求进行架构设计,从而确保重要的需求一一被满足。灵感一闪,就想出了把大象放进冰箱的办法,这自然好。但希望每个...
  • 软件系统设计-17-架构评估

    千次阅读 2022-04-15 09:00:25
    软件系统设计-17-架构评估

    1. Architecture Process

    1.1. Why to evaluate architecture?

    1. 大型项目经常延迟交付和超出预算 Large projects often delivered late and over-budget
      1. 由于设计失败而无法及时交付 Don’t function as promised due to design failures
      2. 商业组件不能按照预期运行 COTS components don’t work as expected
    2. 项目后期需要大量的返工 Considerable rework often required late in project
      1. 团队成员没有讨论这个问题 Team members not communicated the issues?
      2. 团队成员中缺少可以尽早发现问题的专家 Team members lacking expertise to detect problems early?
      3. 有代价 Costly
    3. 架构评估有助于缓解这些问题 Architecture evaluations help alleviate these problems
      1. 彻底评估商业组件的稳定性 Thoroughly assess COTS component suitability
      2. 在问题变的需要一定代价去修复前识别发现问题 Identify problems before they become costly to fix
      3. 通知管理层,以方便他们做出更好的决策 Inform management so they can make better decisions
    4. 在问题修复代价还比较低时尽早定位问题 Locate problems early when they are cheap to fix
      1. 设计缺陷 Design faults
      2. 没有考虑到的商业组件行为 Unexpected COTS components behavior
      3. 商业组件对整体系统架构不匹配 Mismatch of COTS components to overall architecture
    5. 传播架构/设计最佳实践 Disseminate architecture/design best practices
      1. 评估者是可以发现最佳时间的专家 Reviewers are experts, can capture best practices
      2. 评估者拥有不同项目的广阔视野 Reviewers have broad perspective across many projects
    6. 提供更好的技术和项目信息给管理层 Provide management with better technical and project information
    7. 确定培训可以对常见问题领域产生广泛影响的领域 Identify areas where training could provide broad impact on commonly recurring problem areas
    8. 改善与商业组件供应商的互动 Improve interactions with COTS component suppliers

    1.2. 什么时候需要评估架构呢?When to evaluate an architecture?

    1. 期望获得 Acquisition
      1. 选择不合适的商业组件时的最小风险 Minimize risks of choosing inappropriate COTS components
      2. 涉及收购方和供应商(有明显的警告)Involve acquirers and vendors (with obvious caveats:-})
    2. 演化/升级 Evolution/Upgrade
      1. 评估变化的影响 Assess impact of changes
    3. 设计 Design
      1. 新架构适合需求的早期“验证” Early ‘validation’ that the new architecture is suitable for requirements
    4. 构建 Build
      1. 实际架构是否按预期构建 Is actual architecture built as intended
      2. 它是否被很好的构建 Is it built 'well?
    5. 尽早地进行评估 Always evaluate early!!!

    1.3. Why evaluate architecture early?

    1. 架构评估需要尽早完成因为 Architecture evaluation should be done early because:
      1. 还有时间来修复 there is time for correction
      2. 修复错误的决定的成本相对比较小 correcting wrong decision is relatively inexpensive
      3. 它是最有效的质量保证和风险缓解技术之一 it is one of the most effective quality assurance and risk mitigation techniques
      4. 这被认为是一种良好的商业惯例 it is considered a good commercial practice
    2. 早期质量评估具有成本效益(AT&T:生产力提高 10%/1991 年项目) - 最近,通过及早发现和解决问题,在 100,000行(不含注释)的系统上节省了 100 万美元 Early quality evaluation is cost effective (AT&T: 10% productivity increase/project 1991) - Lately, $I million savings on systems of 100,000 non-commentary LOC by detecting and resolving problems early
    3. 存在相互竞争的要求; 必须根据业务目标及早做出决定 There are competing requirements; decisions must be made early according to business goals
    4. 架构设计决策的基本原理应该被捕获和推理 Rationale for architecture design decisions should be captured and reasoned about

    1.4. 如何评估软件架构 How to evaluate software architecture?

    1. 评估架构的系统方法需要一种有助于提出正确问题的方法 A systematic approach to evaluate architecture needs a method that helps ask right questions
      1. 来发现风险 to discover risks
      2. 来识别错误的架构决定 to identify wrong architectural choices
      3. 确保质量问题得到解决 to ensure quality issues have been addressed
    2. 这里有很多用来评估软件架构的方法 There are a number of methods to evaluate software architecture:
      1. Software Architecture Analysis Method (SAAM)
      2. Architecture Level Modifiability Analysis (ALMA)
      3. Performance Assessment of Software Architecture (PASA)
      4. Architecture Trade-off Analysis Method (ATAM)
    3. 所有这些方法都是基于场景的方法,因为质量属性是使用场景定义的 All these methods are scenario-based approaches as quality attributes are defined using scenarios
    4. 场景被映射到架构组件上,以评估架构能力,以满足所需的质量属性 Scenarios are mapped on architectural components to evaluate architectural capability to fulfill desired quality attributes

    1.5. 方法如何可以变得有用?How can a method be helpful!?

    1. 帮助涉众尽早问正确的问题来:It helps stakeholders ask right questions early to:
      1. 识别风险:可能对所需质量属性产生负面影响的架构决策Identify risks: Architectural decisions that may negatively affect desired quality attributes
      2. 发现敏感点:特定质量属性对其敏感的架构决策Find sensitivity points: Architecture decisions to which a particular quality attribute is sensitive to
      3. 发现权衡:影响多个质量属性的架构决策 Discover tradeoffs: Architecture decision that affect more than one quality attribute
    2. 发现趋势:架构决策与系统属性预测之间的相关性 Find trends: correlation between architectural decisions and predictions of system properties
    3. 可以通过进一步分析、设计或原型制作来减轻风险 Efforts can be directed to mitigate the found risks by further analysis, design or prototyping
    4. 所做的权衡和支持它们的理由可以适当地记录下来以备将来参考 Tradeoffs made and rationale underpinning them can appropriately be documented for future reference

    1.6. 评价分析方法 Analysis Methods for Evaluation

    1.7. 评估格式 Evaluate Forms

    1. 设计师在设计过程中评估 Evaluation by designers within the design process
      1. 生成-测试方法 generate-and-test approach
    2. 其他人在设计过程中评估 Evaluation by peers within the design process
      1. 审查者确定许多质量属性方案来推动审查。The reviewers determine a number of quality attribute scenarios to drive the review.
      2. 架构师介绍要评估的架构部分 The architect presents the portion of the architecture to be evaluated.
      3. 对于每个场景,设计人员都会遍历架构并解释如何满足场景。For each scenario, the designer walks through the architecture and explains how the scenario is satisfied.
      4. 潜在的问题被捕获。Potential problems are captured.
    3. 架构设计完成后由外部人员进行评估 Evaluation by outsiders once the architecture has been designed

    2. ATAM:架构权衡分析方法 ATAM:Architecture Tradeoff Analysis Method

    2.1. 阶段 Phase

    1. ATAM方法分为4个阶段完成

    2.1.1. 阶段0:准备好伙伴 Phase-0: Partnership 8 Preparation

    1. 参与者:评估团队领导和关键项目决策者 Participants: evaluation team leadership and key project decision makers
    2. 输入:架构设计文档 Inputs: the architecture documentation
    3. 输出:评估计划 Outputs: the evaluation plan
      1. **谁?**涉众的初步名单 Who? a preliminary list of stakeholders
      2. 逻辑:什么时候?什么地点和如何? Logistics: When? Where? and How?
      3. 什么时候评估报告被送给?When the evaluation report is to be delivered to whom?
      4. 评估报告中应该包含什么信息?What information to be included in the evaluation report?

    2.1.2. 阶段1:评估(1) Phase-1: Evaluation (1)

    1. 参与者:评估团队和项目决策者 Participants: evaluation team and project decision makers
    2. 步骤1-6 Step 1-6
    3. 输出 Outputs:
      1. 架构的简明介绍 a concise presentation of the architecture
      2. 业务目标(驱动因素)的阐述 articulation of the business goals (drivers)
      3. 作为场景实现的特定质量属性要求的优先列表 a prioritized list of specific quality attribute requlrements realized as scenarios
      4. 效用树 utility tree
      5. 风险和无风险 risks and nonrisks
      6. 敏感点和权衡点 sensitivity points and tradeoff points

    2.1.3. 阶段2:评估(2) Phase-2: Evaluation (2)

    1. 参与者:评估团队,项目决策者和架构涉众 Participants: evaluation team, project decision makers, and architecture stakeholders
    2. 步骤(1) 7-9 Step (1) 7~9
    3. 输出:Outputs:
      1. 涉众社区的优先场景列表 a list of prioritized scenarios from the stakeholder community
      2. 风险主题和业务驱动因素各自受到威胁 risk themes and business drivers threatened by each one

    2.1.4. 阶段3:后续 Phase-3: Follow-up

    1. 参与者:评估团队和主要涉众(评估客户) Participants: evaluation team and key stakeholders (evaluation clients)
    2. 输出:最终评估报告 Outputs: the final evaluation report
    3. 评估团队制作一份书面最终报告,分发给主要涉众以供审核。The evaluation team produces a written final report that is circulated to key stakeholders for revlew.
    4. 审查结束后,将报告提交给委托评估的人。After the review, the report is delivered to whom commissioned the evaluation.

    2.1.5. ATAM阶段总结 Summary of ATAM phases

    2.2. 第一阶段的步骤 Steps of Phase-1

    2.2.1. 第一步:介绍ATAM Step1 - Present the ATAM

    1. 评估负责人向集合的项目代表(“决策者”)简要介绍 ATAM,让他们了解评估的过程和输出 The evaluation leader presents the ATAM in brief to assembled project representatives (‘decision makers’) for their understanding of the process and outputs of the evaluation

    2.2.2. 第二步:介绍业务驱动因素 Step2 - Present the Business Drivers

    1. 项目经理或系统的客户从业务角度呈现系统概览,描述 Project manager or system’s customer presents a system overview from a business perspective, describing
      1. 它最重要的功能需求 its most important functional requirements
      2. 其技术、管理、经济或政治限制 its technical, managerial, economic, or political constraints
      3. 其商业目标和上下文 its business goals and context
      4. 其主要涉众 its major stakeholders
      5. 架构驱动因素(塑造架构的主要质量属性目标)the architectural drivers (major quality attribute goals that shape the architecture)

    2.2.3. 第三步:介绍架构 Step3 - Present the architecture

    1. 首席架构师在适当的细节级别上进行了描述架构的演示: The lead architect makes a presentation describing the architecture at an appropriate level of detail:
      1. 技术限制,例如规定使用的操作系统、硬件或中间件 technical constraints such as an OS, hardware, or middleware prescribed for use
      2. 系统必须与之交互的其他系统 other systems with which the system must interact
      3. 用于满足质量属性要求的架构方法 architectural approaches used to meet quality attribute requirements
    2. 架构演示(大约 20 张幻灯片;60 分钟)Architecture Presentation (Approximately 20 slides; 60 Minutes)
      1. 推动架构要求、与这些要求相关联的可测量数量,以及满足这些要求的任何现有标准/模型/方法(2-3 张幻灯片) Driving architectural requirements, the measurable quantities you associate with these requirements, and any existing standards/ models/ approaches for meeting these (2-3 slides)
        1. 重要的架构信息(4-8 张幻灯片):Important architectural information (4-8 slides):
          1. 语境图 - 系统在其存在的语境中。系统将与之交互的人类或其他系统。 Context diagram-the system within the context in which it will exist. Humans or other systems with which the system will interact.
          2. 模块或层视图 - 描述系统功能分解的模块(可以是子系统或层),以及填充这些的对象、过程、函数以及它们之间的关系(例如,过程调用、方法调用、 回调,遏制)。Module or layer view- the modules (which may be subsystems or layers) that describe the system s decomposition of functionality, along with the objects, procedures, functions that populate these, and the relations among them (e.g, procedure call, method invocation, callback, containment).
          3. 组件和连接器视图进程、线程以及连接它们的同步、数据流和事件。Component-and-connector view-processes, threads along with the synchronization, data flow, and events that connect them.
          4. 部署视图 - CPU、存储、外部设备/传感器以及连接它们的网络和通信设备。 还显示了在各种处理器上执行的进程。Deployment view- CPUs, storage, external devices/ sensors along with the networks and communication devices that connect them. Also shown are the processes that execute on the various processors.
        2. 采用的架构方法、模式或策略,包括它们解决的质量属性以及这些方法如何解决这些属性的描述(3-6 张幻灯片):Architectural approaches, patterns, or tactics employed, including what quality attributes they address and a description of how the approaches address those attributes (3-6 slides):
          1. 商业现货 (COTS) 产品的使用以及它们的选择/集成方式(1-2 张幻灯片)。Use of commercial off-the-shelf (COTS) products and how they are chosen/integrated (1-2 slides).
          2. 跟踪 1 到 3 个最重要的用例场景。 如果可能,包括每个场景消耗的运行时资源(1-3 张幻灯片)。Trace of 1 to 3 of the most important use case scenarios. If possible, include the runtime resources consumed for each scenario (1-3 slides).
          3. 跟踪 1 到 3 个最重要的变化场景。 如果可能,根据更改的模块或界面(1-3 张幻灯片)描述更改影响(更改的估计大小/难度) Trace of1 to 3 of the most important change scenarios. If possible, describe the change impact (estimated size/ difficulty of the change) in terms of the changed modules or interfaces (1-3 slides).
          4. 与满足驱动架构要求相关的架构问题/风险(2-3 张幻灯片)。Architectural issues/risks with respect to meeting the driving architectural requirements (2-3 slides).
          5. 词汇表(1张PPT)Glossary (1 slide).

    2.2.4. 第四步:确定架构方法 Step4 - Identify Architectural Approaches

    1. ATAM 专注于通过理解架构方法来分析架构。ATAM focuses on analyzing an architecture by understanding its architectural approaches.
    2. 在这一步,评估团队:By this step, the evaluation team
      1. 研究了架构文档 have studied the architecture documentation
      2. 听取了架构师的展示 have heard the architect’s presentation
      3. 向架构师询问了设计系统时使用的模式和策略 have asked the architect about patterns and tactics used in designing the system
    3. 评估团队对已确定的架构方法(风格、模式和策略)进行编目。The evaluation team catalogs the architectural approaches (styles, patterns and tactics) that have been identified.

    2.2.5. 第五步:生成质量属性效用树 Step5 - Generate Quality Attribute Utility Tree

    1. 这是指导其余分析的关键步骤。 This is a crucial step that guides the remainder of the analysis.
    2. 评估团队与项目决策者合作,确定、确定和优化系统最重要的质量属性目标。The evaluation team works with the project decision makers to identify, prioritize and refine the system’s most important quality attribute goals.
    3. 质量属性目标通过质量属性效用树详细阐述,该树通过精确定义相关质量属性需求使需求具体化。The quality attribute goals are articulated in detail via quality attribute utility tree that makes the requirements concrete by defining precisely the relevant quality attribute requirements.

    2.2.6. 第六步:分析架构方法 Step6 - Analyze Architectural Approaches

    1. 目标是让评估团队确信该方法的实例化适合满足特定于属性的要求。The goal is for the evaluation team to be convinced that the instantiation of the approach is appropriate for meeting the attribute-specific requirements.
    2. 评估团队通过要求架构师解释架构如何相互支持,一次检查排名最高的场景(来自实用程序树)。The evaluation team examines that the highest-ranked scenarios(from the utility tree) one at a time by asking the architect to explain how the architecture supports each other.
    3. 评估团队记录相关的架构决策,并通过讨论识别和分类其风险、非风险、敏感点和权衡。The evaluation team documents the relevant architectural decisions and identifies and catalogs their risks, nonrisks, sensitivity points, and tradeoffs through a discussion.
    4. 分析是为了引出足够的架构信息,以在已经做出的架构决策和需要满足的质量属性之间建立某种联系。The analysis is to elicit sufficient architectural information to establish some link between the architectural decisions that have been made and quality attributes that need to be satisfied.
    5. 在这一步结束时,评估团队应该清楚地了解整个架构的最重要方面、关键设计决策的基本原理以及风险、非风险、敏感点和权衡点的列表。At the end of this step, the evaluation team should have a clear picture of the most important aspects of the entire architecture, the rationale for key design decisions, and a list of risks, nonrisks, sensitivity points, and tradeoff points.

    2.2.7. ATAM 第 1 天的示例议程 Example Agenda for Day 1 for ATAM

    2.3. 阶段2的步骤 Steps of phase-2

    2.3.1. 第一步:展示ATAM和之前的结果 Step-1: Present the ATAM & Previous Results

    1. 重复步骤 1,以便利益相关者了解方法和他们将扮演的角色。 Step 1 is repeated so that the stakeholders understand the method and the roles they are to play.
    2. 评估负责人总结第 2 步到第 6 步的结果,并分享输出(效用树除外)。The evaluation leader recaps the results of steps 2 through 6, and shares the outputs (except the utility tree).

    2.3.2. 第七步:头脑风暴并确定场景的优先级 Step-7: Brainstorm & Prioritize Scenarios

    1. 此步骤的目的是把握更大的利益相关者社区的脉搏,以了解系统成功对他们意味着什么。The purpose of this step is to take the pulse of the larger stakeholder community to understand what system success means to them.
    2. 评估团队要求利益相关者集思广益,就其个人角色而言,在操作上有意义的场景。The evaluation team asks the stakeholders to brainstorm scenarios that are operationally meaningful with respect to their individual roles.
    3. 一旦收集了场景,就会要求利益相关者对他们认为代表行为或质量问题的场景进行优先级排序和合并。Once the scenarios have been collected, stakeholders are asked to prioritize and merge scenarios they feel represent the behavior or quality concern.
    4. 将优先场景列表与实用程序树中的场景进行比较。The list of prioritized scenarios is compared with those from the utility tree.
    5. 如果差异很大,则额外的情景可能被识别为风险。If the discrepancy is significant, the additional scenario may be identified as a risk.

    2.3.3. 第八步:分析架构方法 Step-8: Analyze Architectual Approaches

    1. 在此步骤中,评估团队执行与步骤 6 中相同的活动,使用排名最高的(例如前 5 到 10)但新生成的场景。In this step, the evaluation team performs the same activities as in Step 6, using the highest ranked (e.g. top 5 to 10), but newly generated scenarios.
    2. 架构师解释了相关的架构决策如何有助于实现每个决策。 The architect explains how relevant architectural decisions contribute to realizing each one.

    2.3.4. 第九步:展示结果 Step-9: Present Results

    1. 评估团队根据共同的潜在问题或系统性缺陷将风险分组为风险主题。The evaluation team groups the risks into risk themes, based on common underlying concern or systemic deficiency.
    2. 然后,确定的风险主题与步骤 2 中列出的特定业务驱动因素相关。The identified risk themes are then related to specific business drivers listed in Step 2.
    3. 从评估中收集的信息被总结并呈现给所有利益相关者:The collected information from evaluation is summarized and presented to all stakeholders:
      1. 记录的架构方法 The architectural approaches documented
      2. 集思广益的场景集及其优先级 The set of scenarios and their prioritization from brainstorming
      3. 实用树 The utility tree
      4. 发现的风险和记录的非风险 The risks discovered and nonrisks documented
      5. 发现的敏感因素和权衡因素 The sensitivity points and tradeoff points found
      6. 风险主题和受威胁的业务驱动因素 Risk themes and the business drivers threatened by each one

    2.4. Summary of ATAM Phases

    2.5. ATAM输出总结 Summary of ATAM Outputs

    1. 架构的简明展示 A concise presentation of the architecture
    2. 业务目标的阐述 Articulation of the business goals
    3. 表示为质量属性场景的优先质量属性要求 Prioritized quality attribute requirements expressed as quality attribute scenarios
    4. 引用树 A utility tree
    5. 一组风险和非风险 A set of risks and nonrisks
    6. 一组风险主题 A set of riskthemes
    7. 将架构决策映射到质量要求 Mapping of architectural decisions to quality requirements
    8. 一组确定的敏感度和权衡点 A set of identified sensitivity and tradeoff points
    9. 最终的评估报告 Final evaluation report

    2.6. Lightweight Architecture Evaluation

    展开全文
  • 本文使用这种方法之一:体系结构权衡分析方法(ATAM)来评估两种架构。 后者包括Hoover实现的事件架构(第4版)和我们实现的事件架构。 此评估的目标是确定哪个架构能更好地提供系统所需的服务。 本文详细分析了两...

    论文题目:Evaluation of two architectures Using the Architecture Tradeoff Analysis Method (ATAM)
    作者:Mildred N. Ambe Frederick Vizeacoumar {mildred, fred}@cs.ualberta.ca
    仅供参考,如有错误欢迎指正。

    摘要

    任何一种软件系统的软件架构都是它的体系结构。 架构决定了系统成功的程度。 因此,找到适当的方法验证任何软件架构以确保整个系统的成功非常重要。 本文使用这种方法之一:体系结构权衡分析方法(ATAM)来评估两种架构。 后者包括Hoover实现的事件架构(第4版)和我们实现的事件架构。 此评估的目标是确定哪个架构能更好地提供系统所需的服务。 本文详细分析了两种体系结构中ATAM的不同阶段。

    1.目的

    本文的主要目标是在两个为事件系统设计的架构上执行ATAM。 我们希望在评估后收集有价值的信息,以回答以下问题:
    •架构是否适合事件系统?
    •两种竞争架构中的哪一种最适合这项任务?
    在ATAM评估步骤完成后,我们将在第7节中提出这些问题的答案。

    2.引言

    系统的体系结构指的是系统的组件和这些组件之间的交互。它提供了对系统的有意义的描述。 “架构允许或排除几乎所有系统的质量属性”[1]。这种质量属性的例子包括可修改性,性能,可靠性等等。上面提到的定义让我们提到了关于软件架构评估的这个事实: “如果架构决策决定了系统的质量属性,那么就可以评估架构决策对这些属性的影响”[1]。现在有很多软件架构技术正在使用,但是这个项目只关注体系结构权衡分析方法(ATAM)。这个项目的目标是使用这种方法来评估两种体系结构:Hoover的最新版本的Event体系结构和我们对后者的实现。这两种体系结构有不同的Event框架实现,它提供’事件服务’。这些服务然后被系统中的事件驱动应用程序组件使用。
    进行架构评估的主要原因是使用ATAM正式确定在提供上述服务方面哪种架构更好。在对每个架构的ATAM阶段进行全面分析之后,我们将有足够的证据对上述事件系统的更好架构做出明智决策。
    本文的结构如下:第三部分介绍了执行软件架构评估的动机。相关的工作部分在第四部分。第五部分简要介绍了主要的ATAM阶段。报告的核心是第六部分,其中ATAM用于评估上述两种体系结构。在第七节中,我们简要讨论前一节的结果,最后的结论在第八节。

    3.动机

    任何系统的体系结构都直接影响系统的成功。因此,架构越好,系统成功实现其创建目标的可能性就越高。然后在开发过程中尽可能早地验证系统的体系结构,以确保其正确运行。
    理想情况下,体系结构评估不应该延迟到体系结构完全确定为止。在系统的早期创建阶段,应该评估架构以确定已经做出的架构决策是否合适,并找出未来决策的可能选项。在这个项目中,正在对两个完全开发的体系结构进行体系结构评估。这不是一个错误的方法,因为评估是一件有用的事情,特别是当给定系统存在竞争架构时。换句话说,在进行架构评估方面迟到比从来没有更好。

    4.相关工作

    目前有许多软件评估技术。 尽管软件评估方法可能由不同阶段构成,但它们有一个共同的目标,即确定体系结构对其预期系统的适用性。
    软件工程研究所开发了三种软件体系结构评估技术:本项目中使用的ATAM,软件体系结构分析方法(SAAM)和中间设计活动评估(ARID)。 尽管这些技术彼此之间有一些相似之处,但每种方法都有一种特有的架构评估方法。 为了节省时间和空间,我们不会停留在任何这些方法上。 我们将严格关注这个项目的ATAM。

    5.ATAM的简要描述

    本节提供了对ATAM各阶段的排除,不包括所有细节。 下面的第6部分提供了关于正在评估的体系结构的ATAM评估阶段的详细描述。
    ATAM根据质量属性要求评估架构决策。 系统中的质量属性对于该系统来说是期望的质量,例如良好的性能,可修改性,安全性等。为了更好地简要介绍ATAM步骤,请参考下图。
    这里写图片描述
    请注意,在下一节中,不同ATAM阶段内的步骤是从第一阶段开始递增的。

    6.使用ATAM评估这两种架构

    阶段1 - 演示(Presentation)

    这是使用ATAM评估软件体系结构的初始阶段。 如上图所示,此阶段有三个主要步骤。 在本文中,我们将重点介绍下面的第三个演示步骤。 这些步骤包括以下内容:

    第1步:介绍ATAM

    这一步涉及ATAM评估过程的描述。在此步骤中,评估负责人向所有相关参与者提供有关ATAM过程的一般信息。领导者解释了评估中使用的分析技术以及评估的预期结果。领导者解决小组成员的任何疑虑,期望或问题。

    第2步:介绍业务驱动因素

    在这一步中,提到了系统体系结构驱动程序的业务目标。这一步着重于系统的业务视角。它提供了有关系统功能,主要利益相关方,业务目标和系统其他限制的更多信息。
    在这一步中,我们将定义被评估系统的主要功能以及涉及的利益相关方。正如引言中所述,本项目中正在评估的体系结构表示应用程序将使用的Event框架。 Event框架的主要功能是处理和处理事件。该任务通过框架中不同现有组件的交互来完成。应用程序组件是利用框架的系统的另一部分。
    利益相关者是在被评估的架构中共享任何形式的利益的人。评估这两种架构时考虑的主要利益相关者包括:最终用户,架构师和应用程序开发人员。这三个利益相关者在两个系统中执行不同的重要任务最终用户通过在命令行界面向系统提供输入来使用“成品”。架构师是事件框架的创建者;而应用程序开发人员负责构建使用事件框架的事件驱动的应用程序。所有利益相关者在系统中都有不同的期望和兴趣。

    第3步:介绍要评估的体系结构

    在这一步中,架构团队描述了要评估的架构。它侧重于体系结构,评估的时间可用性以及所研究体系结构的质量要求。此步骤中的体系结构演示非常重要,因为它会影响分析的质量。本演讲中涉及的一些关键问题是:技术约束,与正在评估的系统交互的其他系统,以及为满足质量属性而实施的架构方法。系统的质量属性是代表系统所需质量的问题。这些属性的例子包括性能,可靠性等。“一个系统的质量属性在很大程度上被其架构所允许或排除”[2]。
    以下是两种体系结构的详细介绍:

    (1)胡佛(Hoover)的事件架构:

    图2显示了Hoover体系结构的简单类图,随后描述了系统及其组件:
    这里写图片描述
    胡佛的架构由组成事件框架的组件和利用框架服务的应用程序组成。 框架组件如下所述。
    如前所述,框架是一个事件框架。 它的命令是事件和这个事件,它们根据它们的类型进行处理。 因此,一个事件由两个主要部分组成:它的类型和事件需要处理的参数。 为了处理多个事件,系统中存在一个事件队列组件。
    事件队列(Event Queue)保存系统中的事件并以先来先服务(FIFO)模式分派它们。 事件队列在任何事件生成任何其他事件时(基于使用此框架的应用程序)特别有用,因为事件需要存储和检索以供将来处理。
    该框架的核心组件是事件管理器(Event manager)。 该组件绑定到事件队列和事件组件。 事件管理器维护事件注册表数据结构,并将事件类型注册到与应用程序相关的关联处理程序中。 可能有多个应用程序处理程序可用。 另外,当事件正在执行时,事件管理器将事件绑定到相应的处理程序。 这是可能的,因为事件管理器维护和事件类型注册表。
    该框架还有一个Handler组件,它是所有处理程序的基类。 基本处理程序组件包含两个主要处理程序:
    • STOP handler - 此处理程序负责系统终止。
    • IDLE handler- 此处理程序执行“空闲等待”,直到用户输入输入事件。 它将系统维持在空闲状态,直到有任何输入被提供给系统处理。
    应用程序在某些定义的“挂钩”处挂钩到上述框架。 如图2所示,灰色背景阴影区域代表了胡佛架构的框架。 主进程控制事件类型和应用程序的状态。 它也控制着事件管理器。 所有应用程序处理程序都会修改系统的状态(在图2中由应用程序处理程序组件旁边的 * 表示)。但是,只有一个事件管理器控制系统。

    (2)“银行”(Banking)事件架构:

    图3显示了一个简单的“银行”体系结构类图,其后是对系统及其组件的描述:
    这里写图片描述
    “银行”体系结构由组成事件框架的组件和利用框架服务的应用程序组成。 框架组件如下所述。
    这个框架与上面描述的Hoover的体系结构类似,但有一些区别。 在这种架构中,即使没有独特的事件组件,底层主题也是一个事件(隐式表示)。 在这种架构中,事件有两个主要部分:类型及其参数。
    事件队列(Event Queue)组件通过排队它们并以FIFO模式返回它们来处理事件的维护。 如果没有要返回的事件,则会生成“空闲”事件。
    有一个基本的Handler组件,它由三个标准的指定处理程序和应用程序处理程序扩展。 该组件包含以下三个标准指定处理程序:
    • START handler - 在启动时初始化系统
    • STOP handler - 终止系统。
    • IDLE handler - 此处理程序执行“空闲等待”,直到用户输入一个输入事件。 它验证输入事件是否有效。 如果有效,则事件排队,否则会产生另一个空闲事件。 该处理程序将系统保持在空闲状态,直到给系统处理任何输入。
    在这个架构中,主模块(Main )是框架的一部分。 该组件绑定到事件管理器和事件队列。 该模块的基本功能是从事件队列中取出一个事件并将其分派给事件管理器进行处理。 该组件中没有应用程序特定的信息。
    在此框架中,应用程序在事件管理器中进行访问。 后者处理绑定事件与事件处理程序的过程。 因此,应用程序被挂接到事件管理器。 应用程序处理程序也链接到此事件管理器,并且此模块中不保留事件注册表存储。 可以有多个可链接到系统的事件和多个链接到从基本处理程序组件派生的事件管理器的应用程序处理程序。 然而在这个框架中只有一个事件队列和一个事件管理器。

    阶段2 - 调查和分析

    这是使用ATAM技术评估架构的第二阶段。 在这个阶段,我们对评估期间要重点关注的一些重要问题进行彻底调查。 这个阶段被细分为三个步骤。

    第4步:确定架构方法

    这一步涉及确定能够理解系统关键需求的关键架构方法。 在这一步中,架构团队解释了架构的流程控制,并提供了关于如何以及是否达到关键目标的适当解释。 以下是与正在评估的两种体系结构有关的两种体系结构方法的讨论。

    (1)胡佛的架构:

    在此体系结构中,系统从闲置处理程序生成的命令提示符处接受输入。输入事件被传递给事件管理器,事件管理器将事件存储在事件队列中。主进程从事件队列中取出事件,并将其分派给事件管理器进行处理。事件管理器然后将事件绑定到其相应的事件处理程序。如果事件未被注册,则事件管理器丢弃该事件并将控制传递给主进程。下一个要处理的事件从事件队列中取出并再次发送给事件管理器。如果没有要处理的事件,则会生成空闲事件,执行空闲等待,直到从系统用户接收到输入为止。如果事件在事件管理器事件注册表中注册,则事件与正确的事件处理程序匹配。该处理程序然后执行该事件,可能导致系统状态的变化。
    从质量属性角度来看结构,可以提出几点。从图2中可以清楚的看出框架之外的应用。每个组件都可以单独出来并重新使用。因此,该架构具有高度的可修改性。另外,这些组件相互适当地进行交互并执行其预期的工作,实现功能的质量属性。架构也可以扩展,因为应用程序构建器可以看到明确的钩子。这涉及到变异性的问题。由于处理在命令行界面输入的无效输入,该系统中的可靠性也得到满足。

    (2)“银行”活动架构:

    在此体系结构中,系统由“开始”事件初始化,该事件在内部生成并处理。从空闲处理程序生成的命令提示符处接收输入。当输入事件输入时,IDLE_Handler检查它的有效性。传递给将事件存储在事件队列中的主模块的有效输入。处理事件时,首先从队列中提取事件并分派给事件管理器进行进一步处理。由于在初始阶段消除了有缺陷的输入,并且事件管理器知道应用程序处理程序,它会将相应的处理程序与事件匹配并执行事件。如果事件队列中没有可处理的事件,则事件队列发送空闲事件。
    关于这个架构中提到的质量属性,可以注意几点。这种体系结构中的一个明显缺陷是,事件管理器组件暴露给应用程序,因此不在框架中(图3中灰色区域之外)。因此可以说,这种架构中没有很好地表现出可修改性。这些组件以协调的方式进行交互,即使它们高度相互依赖。由于组件的相互依赖性,在此体系结构中可重用性不太可能。空闲事件的输入活动需要事件,对其进行解析并消除任何有缺陷的输入,从而实现可靠性问题。

    第5步:生成质量属性效用树。

    在评估的这个阶段,系统的最重要的质量属性目标被确定,确定优先次序和完善。这一步至关重要,因为它将所有利益相关方和评估人员的注意力集中在对体系成功至关重要的体系结构的不同方面。这是通过建立效用树来实现的。
    效用树提供了一种使系统目标更加具体和更具体的方法。它还提供了质量属性目标相对于彼此的重要性的比较。因此,效用树表达了系统的整体“良好”。最重要的是,树包含与系统有关的质量属性,以及对利益相关者重要的质量属性要求。这些要求被称为情景。情景是一个说明利益相关者和系统之间的相互作用的陈述。这些情景是质量目标,体系结构将被判断。
    此阶段完成后,结果将成为ATAM评估步骤其余部分使用的情景优先列表。它缩小了在架构中探索风险或架构方法的地点的选择范围。因此,这一步在评估过程中是非常宝贵的。
    在这个项目中,Event系统有两个相互竞争的体系结构,在这一步中,将会有一个实用程序树代表Event系统的质量目标。这些场景是代表三个利益相关者生成的:最终用户,架构师和应用程序开发人员。如上所述,质量属性需求(场景)在这一步中是非常重要的。经过仔细的思考实验,我们代表利益相关者提出了可能的情景。
    情景生成
    情景生成是创建效用树的前一个重要步骤。下面的表1显示了与每个利益相关者有关的情景以及它所代表的质量属性的启发。
    这里写图片描述
    质量属性效用树生成
    效用树包含“效用”作为根节点,质量属性构成效用树的辅助级别。 这些属性位于上面表1的第三列。 在每个质量属性下,都会包含特定的质量属性细化,以提供对方案更精确的描述。 后者形成了实用程序树中的叶节点。 效用树沿着两个维度排列优先顺序:每个场景对系统成功的重要性以及对此场景实现(从架构师的角度来看)所带来的难度程度的估计。 效用树中的优先级基于相对排名:高(H),中(M)和低(L)。 请参阅图4(下一页)了解实用程序树图。(文中并没有附图……)

    第6步:分析体系结构方法

    这是“调查和分析”阶段的最后一步。在这一步中,我们分析前一步生成的效用树的输出,并进行彻底的调查和分析,找出处理相应质量属性的架构方法。我们根据这些质量属性分析这两种架构,并为它们提供适当的解释。我们还确定每种架构方法的风险,非风险,敏感点和权衡点。
    从步骤5的效用树中,提取高优先级场景。例如,请考虑步骤5中效用程序树中的以下两个方案:
    (L,M)所有操作都以最快的速度处理(性能)
    (H,M)应该处理使用系统中的用户错误(可靠性)
    从场景旁边的(L,M)和(H,M)所示的这些场景的优先级确定,决定选择哪个质量属性。在这个例子中,选择第二种方案是因为它对系统的成功和建筑师的中等难度具有高度重要性。第一种情况不被考虑,因为它对系统的重要性不高。从效用树中获得的高优先级属性是:可变性,可靠性,集成性(Conceptual Integrity),功能性和可修改性。质量属性(如性能,可用性,安全性和可移植性)没有被赋予高优先级,因为它们对系统目标不那么重要(如树中所示)。
    这一步分为四个主要阶段:
    - 调查建筑方法
    - 创建分析问题
    - 分析问题的答案
    - 找出风险,非风险,敏感点,权衡点。

    6.1调查体系结构方法

    在识别出对系统目标很重要的质量属性后,我们分析两种架构并确定它们如何支持这些质量属性。 我们对体系结构进行了详细的调查,以了解这些质量属性要求是否得到满足。
    (a)可变性:
    可变性是定义可以如何扩展或修改架构以生成新体系结构的属性。
    (1)胡佛架构:
    在这个架构中,如图2所示,该框架非常灵活。 Event框架维护一个队列;独立于应用程序的处理程序和事件组件。由于该应用程序未嵌入许多组件,因此该系统具有高度可修改性。例如,如果架构团队希望包含主模块调用队列的新方案,则可以在稍后阶段完成。由于架构清楚地显示了所有组件的交互作用,因此可以重构任何组件,或者可以将任何新组件添加到架构中,而不会影响任何其他组件。因此,胡佛的架构高度支持可变性。
    (2)银行体系结构:
    如图3所示,架构的组件是高度相互依赖的,并且有许多组件包含特定于应用程序的信息。例如,如果主模块调用应用程序处理程序,则事件管理器会受到影响,因为后者包含特定于应用程序的信息。但是,架构的某些部分支持可变性。例如,如果事件队列更改为绑定到事件管理器,而不是当前体系结构中的主模块,则不会影响其他组件。因此,这种架构在一定程度上支持变化。
    另外,这种架构的一个主要缺陷是事件管理器被排除在框架之外,因为它包含与应用程序相关的信息。事件管理器应该是框架内的核心组件。如果这种架构在未来得到扩展,这个缺陷将会造成很大的困难。一般而言,某些组件的更改或新组件的包含很可能会影响其他相关组件。
    (b)可靠性:
    可靠性是决定系统响应故障的行为以及系统如何随时间运行的特性。
    (1)胡佛架构:
    在这个架构中,在输入阶段,任何输入都是在没有消除任何’有缺陷’的输入的情况下处理的。传播有缺陷的输入直到事件绑定时间的主要原因是它是一个特定于应用程序的细节。因此,框架保持不变,无论应用程序是否与之相关。然而,最终在事件管理器组件中以适当的方式处理了有缺陷的输入。因此,该体系结构支持可靠性。
    (2)银行体系结构:
    在此体系结构中,在空闲事件的输入活动中识别有缺陷的输入。因此,在事件存储在队列中之前,将检查类型和参数的有效性(请注意,这是一个特定于应用程序的细节)。尽管这是一个与应用程序相关的活动,但系统在任何有缺陷的输入和可靠性得到满足后都会恢复。但是,如果任何其他应用程序挂钩到框架,则此验证过程必须更改。
    (c)集成性(Conceptual Integrity):
    该属性定义了统一各级系统设计的基础主题。架构应该是一致的,在执行架构的所有进程时使用最少的数据和控制机制。
    (1)胡佛架构:
    在这个架构中,事件在整个系统中以类似的方式处理。无论事件类型如何,主模块都将事件传递给事件管理器,后者将事件绑定到执行该过程的处理程序。在系统中执行任何操作都涉及很少的控制机制,并且后者以有效的方式执行。因此概念完整性得以实现。
    (2)银行体系结构:
    在这个架构中,所有事件都以类似的方式处理,但所使用的控制机制的数量相当高。在这个体系结构中,事件从事件队列中提取并传递给事件管理器,事件管理器相对于某些特定于应用程序的细节处理事件。处理事件后,事件管理器通过调用应用程序处理程序将该事件传播到其处理程序,处理程序依次处理该事件。虽然类似的方法被用于架构中的所有事件,但是使用的控制机制的数量可以被最小化以实现这个目标。因此,在这个架构中,概念完整性的属性没有得到妥善处理。
    (d)功能性:
    此属性标识系统中组件之间的交互,以及系统是否执行预期的任务。
    (1)胡佛架构:
    如前所述,在这个架构中,组件之间展示了适当的相互作用。该体系结构还以有效的方式执行事件处理的预期任务。组件之间的交互是合理和适当的。事件队列保存事件,根据请求分派给事件管理器。另外,事件管理器与应用程序处理程序协调并将事件绑定到相应的处理程序。因此,在这种架构中,功能的属性显然是需要关注的。
    (2)银行体系结构:
    在这种架构中,组件之间存在适当的交互,系统通常适当地执行预期的任务。尽管在系统的许多组件中都嵌入了特定于应用程序的细节,但组件协调也是合理的。因此,在这种架构中适度地解决了功能问题。
    (e)可修改性:
    顾名思义,该属性验证系统是否能够以一种快速,经济高效的方式进行修改。它验证了体系结构如何处理对组件所做的更改,以及是否可以将任何不同的应用程序挂接到框架。
    (1)胡佛架构:
    在此体系结构中,可修改性的程度很高,因为所有框架组件都与应用程序分离。如果要包含任何新的特定于应用程序的组件,该体系结构有能力以经济有效的方式适应这种修改。事件管理器组件维护一个事件类型的注册表,它将每个事件注册到它的处理程序。此注册表的内容不固定,但依赖于使用事件框架的应用程序。这确保了架构中的高度可修改性。
    (2)银行体系结构:
    在这种架构中,应用程序嵌入在许多组件中。因此,重新使用不同应用程序的框架或添加任何新的应用程序特定组件都会涉及很多困难和修改。因此修改过程可能不是成本有效的。鉴于这些观点,这种架构没有表现出足够的可修改性。

    6.2创建分析问题

    本步骤的下一个阶段涉及收集上面讨论过的高优先级场景中产生的分析问题。在现实生活中,所有利益相关者都会收集分析问题。在这个项目中,我们只是简单地创建了优先场景中显著的示例问题。分析问题与上面讨论的每种架构方法相关联;并面向重要的质量属性。以下是分析问题列表和正在解决的属性:
    •架构的组件可以重复用于未来的项目吗? (变化性)
    •未来可以扩展框架以适应新的应用程序或新组件? (变化性)
    •系统会处理用户提供的任何输入并处理无效输入吗? (可靠性)
    •架构的行为是否一致? (概念完整)
    •是否可以将任何新的应用程序特定功能添加到架构中(可修改性)
    •系统能否以短时间和成本效益的方式进行修改?(修改性)
    •组件是否正确交互?(功能性)
    •体系结构是否正确执行其事件处理任务? (功能)

    6.3分析问题的答案

    这一步的第三阶段是根据两种评估架构对上述分析问题提供合理的解释或答案。以下是在每个架构中如何处理这些问题的讨论。
    (1)胡佛架构:
    •架构的组件可以重复用于未来的项目吗?
    如前所述,此体系结构中的每个组件都是相互独立的,并以适当的方式进行协调。例如,无论它链接到哪个组件,事件管理器都会在使用任何注册的事件类型调用时将事件绑定到相应的处理程序。
    •未来可以扩展框架以适应新的应用程序或新组件?
    是的,这个架构可以很容易地扩展以适应更多的组件和任何给定的应用程序。这是由于上一个问题中给出的原因。
    •系统是否处理用户提供的任何输入并处理无效输入?
    虽然有缺陷的输入在稍后阶段被识别,但系统会处理用户给出的所有输入并处理任何无效输入。
    •架构的行为是否一致?
    是的,胡佛的架构在处理所有事件时的行为是一致的。另外,它利用最少数量的控制机制来执行任何给定的任务。
    •是否可以将任何新的特定于应用程序的功能添加到架构中?
    由于应用程序完全独立于此框架组件
    体系结构中,可以将任何新功能添加到架构中,而不会影响其他组件。该应用程序被添加到框架中的’挂钩’,这在这个架构中明确定义。
    •系统是否可以在短时间内以具有成本效益的方式进行修改?
    是的,因为应用程序没有嵌入到许多组件中,并且在极小的地方与框架链接,所以可以在更短的时间内以经济高效的方式进行修改。
    •组件是否正确交互?
    正如上述架构方法的讨论中所解释的,此架构中的组件以协调的方式进行交互。
    •体系结构是否正确执行其事件处理任务?
    胡佛的体系结构提供了所需的结果,因为事件处理的主要任务是通过系统中各组件之间的适当交互来处理的。
    (2)银行体系结构:
    •架构的组件可以重复用于未来的项目吗?
    这些组件可以重用,但会涉及一些重大更改,因为应用程序嵌入了许多组件。但是,像事件队列这样的组件可以被重用。
    •未来可以扩展框架以适应新的应用程序或新组件?
    使用框架来改变应用程序并不是一件容易的事情,因为必须对框架的主要部分进行重大更改。事件管理器组件在此体系结构中是高度特定于应用程序的,并且如果要添加任何应用程序,则必须对其进行修改。出于同样的原因,添加任何新功能都需要付出很大的努力。
    •系统是否处理用户提供的任何输入并处理无效输入?
    是的,系统处理系统用户给出的所有输入并丢弃无效的输入事件。
    •架构的行为是否一致?
    在这种体系结构中,一致性没有充分显示,因为控制权被转移到一系列组件中以执行任何任务。
    •是否可以将任何新的特定于应用程序的功能添加到架构中?
    即使涉及许多组件,也可以向系统添加任何新功能。
    •系统是否可以在短时间内以具有成本效益的方式进行修改?
    鉴于该应用程序嵌入到系统中涉及的许多组件中,所以修改需要更多时间,并且可能不具有成本效益。
    •组件是否正确交互?
    这些组件以适当的方式进行交互(如上面在架构方法讨论中所述)。
    •体系结构是否正确执行其事件处理任务?
    我们的体系结构提供了所需的结果,因为事件处理的主要任务得到处理,即使系统中还存在其他缺陷。

    6.4找出风险,非风险,敏感点,权衡点。

    涉及此步骤的最后阶段是确定风险,无风险,敏感点和权衡点。
    风险是架构中的一个问题点,后者不支持给定的优先级质量属性。 非风险是体系结构的优势,后者实现特定的优先级质量属性。 敏感点是一个或多个组件的属性,对于实现给定的质量属性至关重要。 如果架构对多个属性敏感,那么该点称为权衡点。
    这里写图片描述
    敏感点:
    对于这两种体系结构,以下是敏感点:
    •更改体系结构的范围对应用程序嵌入到系统中的位置数量很敏感。
    •错误输入的处理对应用程序中事件类型的数量很敏感(因为在验证过程中,输入事件是针对已知事件进行验证的)。
    •系统一致性水平对用于处理流程的控制机制的数量很敏感。
    •从系统获取所需输出的过程对组件协调的方式以及彼此之间的交互方式非常敏感。
    •向应用程序添加新功能的能力对应用程序嵌入到系统中的位置数量很敏感。
    权衡点:
    从敏感点可以清楚地看出,应用程序嵌入系统的地方数量会影响变化性和可修改性质量属性。 因此,这形成了一个权衡点。
    基于这一观察,我们发现银行业务体系结构具有上述的权衡点,而胡佛的体系结构则没有。

    阶段3 - 测试

    第7步:头脑风暴和优先场景

    这是ATAM测试阶段的第一步。前者代表利益相关者的利益,用于理解质量属性要求。在效用树生成步骤中,主要结果是从建筑师的角度来理解质量属性。在这一步中,目标是让更大的利益相关者参与其中。该
    将头脑风暴情景的优先列表与在步骤5中从树中获得的优先方案进行比较。利益相关者需要头脑风暴三种场景:
    用例场景 - 在这种情况下,利益相关者就是最终用户。
    增长情景 - 代表了架构发展的方式
    探索性场景 - 代表架构中极端的增长形式。
    在这一步中执行的活动如下:
    首先,情景是在利益相关者的大风暴活动之后收集的。
    场景优先:与相同质量属性有关的所有场景都被合并,利益相关者投票选出他们认为最重要的场景。从[1]中可以看出,每个利益相关者都被分配了一定数量的选票,如下所示:

    票数=场景总数的30%

    投票结束后,投票结果会被记录下来,场景按总票数排序。采取截止线以上的情况,其余不予考虑。
    将优先头脑风暴情景列表与优先情景进行比较
    从步骤5中的效用树中获得。头脑风暴的场景被放置在
    在实用程序树中适当的分支。它可能是树中已经存在的场景的副本,或者它可能在新的叶子下,或者可能不适合任何分支。
    在这个阶段提及这一点很重要,因为我们正在进行两次ATAM
    一个项目中的体系结构,我们只能模拟利益相关者,他们的想法和他们的兴趣。这个阶段有一些步骤,在现实生活中有很多利益相关者,评估团队,建筑师和开发人员,这些步骤更加明智。在这个项目中,我们尽可能地尝试来表示这个过程的不同部分。
    我们首先介绍这一步中的头脑风暴情景列表,为我们正在评估的架构中的三个利益相关者。场景列表不需要与步骤5中生成的场景不同,但也可以通过头脑风暴过程生成新场景。下面的表3显示了编号方案的列表,方案的类型以及它所代表的质量属性。
    这里写图片描述
    在这一点上,头脑风暴的场景清单已经准备就绪。 下一步是让利益相关者为他们认为重要的情景进行投票。 分配给每个利益相关者的票数定义如下:
    票数= 30% (情景总数)= 0.3 16(到最近的整数)= 5

    因此,三个利益相关者每个都有5张投票可供选择。 接下来,我们模仿一个投票活动,每个利益相关者对与他们最感兴趣的情景进行投票。 在这个阶段,我们根据不同的利益相关者进行思考,并对各种情况进行投票。 示例投票活动的结果显示在下面的表4中(所有得到总共0张选票的情况均不包含在此表中):
    这里写图片描述
    这里写图片描述

    第8步:分析架构方法

    这是“测试”阶段的最后一步。在这一步中,我们分析上一步中高质量的质量属性。我们找到了处理这些质量属性的架构方法,并检查架构是否支持这些属性。这一步重复“调查和分析”阶段的第6步。唯一的区别在于,在步骤6中,高优先级质量属性来自效用树,而这一步需要高度投票的头脑风暴质量属性。一些来自步骤6的优先级质量属性可能在这里重新发生,而一些新的可能会出现。最后,分析优先方案的风险,非风险,敏感点和权衡点。
    从上一步的投票表中,高质量的质量属性是:功能性,可靠性,可修改性,安全性,性能和可变性。由于其中一些质量属性已经在步骤6中讨论过,所以我们只关注新出现的属于安全和性能质量属性的情况。在这一步中,仅根据这两种情况分析两种体系结构。
    这一步分为四个主要阶段:
    - 调查建筑方法
    - 创建分析问题
    - 分析问题的答案
    - 找出风险,非风险,敏感点,权衡点。

    8.1调查建筑方法

    (a)安全性:
    此属性验证系统是否有能力限制未经授权的访问,以及体系结构是否提供任何数据机密性。
    (1)胡佛架构:
    在这种架构中,一些组件以适当的方式使用数据封装。例如,只有事件管理器执行事件注册表活动,因此未经授权的组件不能执行此任务,或者操作事件注册表数据结构。由于框架完全独立于特定于应用程序的信息,因此组件的协调确保正确的数据封装,并且信息仅对需要它的组件可见。因此,解决了安全问题。
    (2)银行体系结构:
    在这种体系结构中,特定于应用程序的信息被嵌入到架构中的许多组件中,因此数据机密性处理不当。因此,框架的结构非常“开放”。但是,在某些情况下,保密性是可以达到的。例如,应用程序处理程序仅由事件管理器调用,并且不能由其他组件访问。这支持一些受限组件的安全性,但不支持整体体系结构。
    (b)性能:
    该属性使我们能够了解系统的响应性。性能因素通常表示为每单位时间的交易次数或执行一次交易所花费的时间。
    (1)胡佛架构:
    在此体系结构中,用户界面是命令驱动的,因此整个系统的性能不能以每单位时间的事务数量来衡量。但是,由于执行任何给定流程所涉及的组件都很少,我们可以推断执行一项事务所花费的时间很少。因此,该体系结构解决了性能问题。
    (2)银行体系结构:
    这种体系结构也是由命令驱动的,并且如果根据处理任何事件所涉及的组件数量来计算性能,则可以说该体系结构中的这个数字更高。因此,这种体系结构中的性能不足。

    8.2创建分析问题

    以下是利益相关方收集的分析问题清单,并基于高度投票的情景。
    •系统是否允许未经授权的访问? (安全)
    •架构是否描绘数据机密性? (安全)
    •架构是否以最快的速度处理任何任务? (性能)

    8.3分析问题的答案

    现在我们在这两种体系结构中找到这些分析问题的合理答案。
    (1)胡佛架构:
    •系统是否允许未经授权的访问?
    在组件层面,胡佛的架构中未经授权的访问受到限制。但是,在应用程序级别,如果需要,可以通过修改应用程序组件来限制访问。
    •架构是否描绘数据机密性?
    如前所述,特定于应用程序的信息并未嵌入组件的许多部分,因此数据得到了很好的保护。
    •架构是否以最快的速度处理任何任务?
    由于执行任何任务所涉及的组件数量极少,并且每个组件中的处理量在此架构中最小,因此后者以最快的速度执行操作。
    (2)银行体系结构:
    •系统是否允许未经授权的访问?
    在组件级别,某些组件受到限制,而体系结构中的大多数组件都可用于访问未经授权的组件。
    •架构是否描绘数据机密性?
    考虑到应用程序特定的信息在许多组件中可用,这些信息分散在架构中,因此不存在数据机密性。
    •架构是否以最快的速度处理任何任务?
    由于涉及事件处理的组件数量很多,因此此架构不能以最快的速度执行操作。

    8.4找出风险,无风险,敏感点,权衡点。

    风险与无风险:
    这里写图片描述
    敏感点:
    •数据保密级别对嵌入应用程序的地点数量很敏感。
    •执行任务的平均速度对处理任务所涉及的组件数量敏感。
    权衡点:
    考虑到上述敏感点和步骤6中列出的敏感点,我们得出以下权衡点。
    •应用程序嵌入的地点数量
    •处理任务所涉及的组件数量
    基于这些权衡点,我们可以推断Hoover的架构在框架中没有应用程序特定信息,并且执行任务所涉及的组件数量很少,而在银行架构中,这两个权衡点都不被处理正确。

    阶段4 - 报告ATAM

    这是ATAM评估的最后阶段,其中提供了评估期间收集的所有信息。 ATAM团队将他们的发现呈现给利益相关者群体。
    ATAM团队的主要发现通常包括:
    - 一种效用树
    - 一组生成的场景
    - 一组分析问题
    - 一套确定的风险和非风险
    - 确定的建筑方法
    鉴于通过这份报告我们已经介绍了这些发现,这个阶段是多余的。

    7.从ATAM评估观察

    在使用ATAM技术评估这两种架构之后,我们发现了许多有趣的结果。 ATAM评估的主要目标是为开发系统确定更好的体系结构。如表2和表6所示,其中包含两种架构的风险和非风险,我们发现Hoover的架构没有任何风险,而银行架构则有三种风险。
    同样,第8步(测试阶段)的结果显示,银行架构中存在两个权衡点,而胡佛架构中没有权衡点。
    因此,在这个时刻,考虑到从ATAM评估中获得的所有输出,我们有足够的证据从架构角度证明Hoover的架构最适合它所设计的基于事件的系统。另一方面,可以改进银行业务体系结构以更好地满足系统的需求,但讨论如何实现这一点超出了本项目的范围。

    8.结束语

    这个项目的目标是使用ATAM来评估2个已经开发的架构。 使用ATAM非常有趣,因为评估过程提出了每个体系结构中不一定很明显的关键部分。 尽管“测试”阶段与“调查和分析”阶段几乎完全相同,但确保过程彻底,并且利益相关者的观点受到高度重视。
    在现实生活中,由于上述原因,ATAM将成为一种很好的评估技术。 在这个项目中,我们必须考虑系统的三个利益相关者,并进行思考实验以实施一些ATAM步骤。
    一般来说,从事这个项目的工作对软件体系结构评估,质量属性要求以及所有利益相关者参与系统评估的重要性有一定的了解。

    参考文献:

    [1] Paul Clements, Rick Kazman and Mark Klein, “Evaluating Software Architectures: Methods and Case Studies”, SEI Series in Software Engineering.
    [2] “Software Architecture Evaluation: A Key to System Success”, http://interactive.sei.cmu.edu
    [3] Dr. James Hoover, “Hoover’s Architecture Version 4”.

    展开全文
  • 软件架构论文集

    2013-02-06 19:27:33
    在以软件为主的系统获取中使用架构权衡分析方法.pdf 架构权衡分析方法相关理论.pdf 用架构权衡分析方法评估一个参考架构:一个案例研究.pdf 管理软件架构的可变性.pdf 软件架构平衡分析方法.pdf 软件架构文档化:...
  • 架构方法

    千次阅读 2020-09-23 20:05:00
    架构方法论|0x00 架构思维相信很多人,谈起架构,第一印象,就是各种各样的架构图,有一个高高在上的人,坐在那里,阔谈自己的理念。诚然画图是架构师的一项日常工作,但通过一张图,来道出事物...
  • 题外话:本篇文章主要讲的是软件架构体系中的软件开发方法、质量属性以及软件架构评估等方面的内容。 一:基于架构的软件开发方法 1、开发过程 基于架构的软件开发主要分为架构需求、架构设计、架构文档化、...
  • 系统架构设计方法

    千次阅读 2016-11-07 20:29:02
    系统架构设计方法论 软件架构设计方法体系涵盖了预想架构(PA)概念架构(CA)细化架构(RA)三个阶段和一个贯穿环节。 一、预备架构 预备架构阶段主要是通过系统的理解需求和挖掘潜在需求以此建立需求大局观...
  • 系统架构综合知识

    千次阅读 2018-11-10 07:59:19
    在数据库设计的需求...需求分析阶段的任务是对现实世界要处理的对象(组织、部门和企业等)进行详细调查,在了解现行系统的概况,确定新系统功能的过程中收集支持系统目标的基础数据及处理方法。需求分析是在用户...
  • 具体什么原因,我们不做猜测,但是今天就来说说架构的问题,毕竟我也是看过很多总结,并且经历过很多公司的架构设计的。 当然,阿里的系统架构肯定是没有问题的,毕竟它是国内的顶级IT公司。 一. 什么是架...
  • ATAM SAAM架构评估理论知识

    千次阅读 2021-06-11 13:11:10
    架构权衡分析方法:一种非定量方法,它可揭示构架满足特定质量目标的情况,及构架对质量目标的权衡;软件结构权衡分析方法(ATAM)是一种评估软件结构的技术,它不仅用于软件系统的结构的特性评估,还能在有质量冲突...
  • 软件架构评估是在对架构分析、评估的基础上,对架构策略的选取进行决策。它也可以灵活地运用于对软件架构进行评审等工作中。 二、软件架构评估的方法 业界已开发出多种软件架构评估的方法,按基于的技术手段来看,...
  • 为了调整系统架构,设计语言必须支持多种分析方法以便进行跨领域的权衡架构设计语言还必须支持开发过程中的增量分析以及用于系统评估的多级逼真度。这种增量特性允许架构规范在整个生命周期内都有效。架构分析与...
  • 本文对软件体系架构的描述方法的研究基于 ISO/IEC/IEEE 42010. ISO/IEC/IEEE 42010 于 2011 年批准使用并发布,该标准是继 2006 年 ISO 快速采用 IEEE 标准后,ISO 和 IEEE 联合制定的修订 IEEE Std 1471:2000 的...
  • 架构制图--工具与方法

    千次阅读 2020-11-30 16:34:30
    作为软件行业的从业者,你可以完全不懂工程制图,但你不得不懂架构制图 —— 这是任何程序员职业生涯的的必修课。 前言 “架构制图”这词乍一听似乎有些晦涩,但如果提起“工程制图”,相信绝大部分工科背景的...
  • 【软考系统架构设计师】2013年下系统架构师综合知识历年真题
  • SAAM及 ATAM两种方法在具体的实际评估活动中,它们在场景的生成、风险承担者的商业动机的表述、软件体系结构的描述等方面存在着很大的不同,两种评估方法各有特长 ,其评估方法在具体的场景执行环节上具有不确定性 ,将...
  • 软考系统架构师笔记-最后知识点总结(三)

    千次阅读 多人点赞 2019-10-29 09:30:55
    ATAM中文名:体系结构权衡分析方法,他最后的目标是生成关键的质量属性效用树。 在软考中,体系结构=架构 体系结构权衡方法(ATAM)包含4个主要的领域活动:场景和需求收集、体系结构视图和场景实现、属性模型构造...
  • 软考系统架构师笔记-案例分析重点(一)

    千次阅读 多人点赞 2019-09-17 00:20:03
    系统架构权衡点:影响多个质量属性的特征,是多个质量属性的敏感点。 状态图:描述一个对象在其生成周期的动态行为,表现一个对象所经历的状态序列,引起状态转移的事件(event),以及因状态转移而伴随...
  • 架构设计(5)—架构愿景分析

    万次阅读 2018-07-04 16:36:09
    1、架构目标架构设计始终以服务业务为中心,以保证产品业务的稳定、安全、高效运行为目标。稳定:指产品向用户提供服务的可用性、准确性、完整性,访问速度及用户体验符合产品的设计与预期;安全:指产品运行在安全...
  • 2 内容见文档:”考点按章节整理\第 9 章 软件架构设计\软件架构设计.docx” 3 更新文档:”各年例题分类.xlsx” 考题分布 软件架构设计 目录 软件架构设计 1 1 软件架构概述 3 1.1 软件架构的定义 ...
  • 比如,架构风格这一知识点,选择里的考察方式可能是以下架构风格中,哪个属于数据流风格。而案例分析中,考察方式就是针对XX系统的应用场景,从XX方面和XX方面对管道-过滤器风格和虚拟机风格进行对比与分析,并说明...
  • 架构师PPT大纲

    千次阅读 2019-10-12 21:55:53
    架构师PPT大纲架构师PPT大纲计算机系统基础计算机组成CPU的功能运算器。控制器。计算机系统结构的分类指令系统校验码指令控制方式存储系统总线操作系统基础知识 架构师PPT大纲 我每天花八小时练琴,他们却用“天才...
  • 架构图深入解读

    千次阅读 2020-06-30 23:27:32
    架构图是什么?为什么要画架构图?...有哪些方法?本文从架构的定义说起,分享阿里文娱高级技术专家箫逸关于画架构图多年的经验总结,并对抽象这一概念进行了深入地讨论。较长,同学们可收藏后再看。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 27,596
精华内容 11,038
关键字:

架构权衡分析方法