[TOC] ## 要点 1. 三种评估方法是什么? 1. 基于问卷调查 2. 基于场景的评估方法 3. 基于度量的评估方法 2. 主要哪些质量属性? 3. 创建项目评估小组? 5. ATAM架构评估实践的步骤 1. 介绍ATAM(介绍ATAM,描述商业目标,描述架构) 2. 分析和调查(调查各个利益负责人的要求,并生成质量效用树,得出风险点和敏感点,和权衡点) 3. 测试(对场景的质量属性就测试,是否满足要求,确定优先级) 4. 报告ATAM(生成一个即时通讯的架构评估表,) 考点 ## 考点 1. 敏感点和平衡点, 风险承担着 2. 选择理由,比其他方法更适合 面向SOA 3. 四个阶段 ## 论即时通讯系统中的软件架构评估 ### ATAM评估方法的可写点概述 ATAM（Architecture Tradeoff Analysis Method，体系结构权衡分析方法）是一种基于场景的软件架构评估方法，主要用于评估系统架构在多个质量属性（如性能、可用性、可修改性、安全性）上的权衡，帮助识别风险并验证是否满足非功能性需求。在论文中描述ATAM时，可以从方法论、过程、实际应用和效果等方面展开。以下是可写的关键点，建议结合项目背景（如即时通讯软件的架构设计）进行具体化描述，以突出“我”作为架构设计师的角色和贡献。内容应条理清晰、开门见山，忠实于论点，避免偏题。 #### 1. **ATAM方法的定义和选择理由** - 定义：ATAM是一种基于场景的评估方法，通过构建场景来模拟系统在不同质量属性下的表现，评估架构的权衡点、风险点和敏感点。强调其关注多个质量属性的交互影响，而不是单一属性。 - 选择理由：相比基于问卷或度量的评估方式，ATAM更适合中等规模的项目（如本即时通讯软件），因为它主观性适中、易操作，且能涉及项目干系人（如用户、开发人员）。可以写：本项目采用ATAM是因为它能权衡性能（响应时间）、可用性（故障恢复）、可修改性（模块扩展）和安全性（数据加密），符合内网部署和定制化需求。 - 可扩展写：与其他方法对比（如SAAM或CBAM），ATAM更注重权衡分析，适用于SOA架构的项目。 #### 2. **评估小组的组建和角色分工** - 小组成员：包括评估负责人（可写“我”担任）、项目决策者、架构设计师（“我”兼任）、用户代表、开发人员、测试人员、部署人员等。 - 角色分工：强调协作性，例如“我”作为负责人组织会议，用户提供需求场景，开发人员分析技术实现。 - 可写点：小组规模适中（5-10人），确保多视角输入，避免主观偏差。结合项目：小组讨论了即时通讯的组织架构管理和单点登录等场景。 #### 3. **ATAM评估的四个阶段详细过程** ATAM的核心是四个阶段，这是描述的重点，可以分段展开，每阶段结合项目示例。 - **描述和介绍阶段**： - 介绍ATAM方法：解释其基于场景评估多质量属性，确认风险并验证需求。 - 客户阐述目的：写项目背景，如依托大数据从流量中挖掘漏洞（或适应项目：内网即时通讯的文字/文件发送、安全控制）。 - 架构设计师描述架构：详细说明系统架构（如SOA风格，模块拆分：登录服务、群组服务、文件服务等），并初步讲解子模块功能。 - 可写：由于部分成员不熟悉ATAM，“我”先进行方法培训，确保共识。 - **调查和分析阶段**： - 收集需求：不同干系人提出场景，如客户要求系统故障恢复<1分钟、漏洞识别率>90%；安全人员要求过滤无效流量；开发人员强调并行开发。 - 生成质量效应树：描述树结构（考试时可简要图示），树根为质量属性（如可用性最高），分支为具体场景和优先级。 - 识别关键点： - 风险点：如黑客IP未实时捕获导致漏洞丢失（适应项目：长连接中断导致消息丢失）。 - 敏感点：如加密级别、规则修改（项目中：敏感词检测规则）。 - 权衡点：如提高加密严格度提升安全性但降低性能（项目中：支持多种数据库 vs. 性能开销）。 - 可写：通过 brainstorm 会议总结，量化优先级（可用性最高、性能其次）。 - **测试阶段**： - 场景优先级确定：集体讨论后排序，如可用性>性能>可修改性>安全性。 - 技术措施验证：描述如何地址风险，例如采用双机热备（流量捕获模块）、集群部署（分析模块）、RAID5（数据存储）、非对称加密（用户数据）。 - 可写：测试模拟场景，确保措施有效，如心跳机制实现无缝切换，验证了系统的可靠性。 - **报告阶段**： - 形成报告：包括方法文档、场景优先级、质量效应树、风险/非风险决策、会议记录。 - 可写：报告以文档形式输出，用于后续优化，“我”负责汇总，确保完整性。 #### 4. **质量属性的具体阐述和应用** - 关注的主要质量属性：性能（响应时间）、可用性（故障恢复比例）、可修改性（变更成本）、安全性（授权访问）。 - 结合项目：例如，在即时通讯中，性能体现在消息队列处理；可用性通过看门狗服务监控；可修改性支持定制化（如国产数据库适配）；安全性包括日志审计和敏感词检测。 - 可写：这些属性通过ATAM场景量化，如“系统必须在1分钟内恢复故障”。 #### 5. **评估效果和验证** - 效果：识别出风险（如消息积压>12小时），并通过措施优化；提升了系统稳定性。 - 项目验证：系统稳定运行1年多，产生实际价值（如挖掘150+漏洞特征；适应项目：支持国产化部署，获得好评）。 - 不足与改进：如评估主观性强，可结合度量方法补充；或在未来项目中扩展到更多属性。 - 可写：实践证明ATAM保证了项目顺利完成，但需注意小组偏见。 #### 写作建议 - **字数控制**：正文部分描述ATAM过程占50-60%，结合项目示例，避免空谈理论。 - **以“我”为中心**：强调“我”的贡献，如“我”主导阶段推进、设计架构、分析风险。 - **图文并茂**：插入质量效应树简图（树状结构），或流程图增强可读性。 - **忠实论点**：紧扣“软件系统架构评估”，开门见山，避免偏向其他主题（如容错技术）。 - **条理清晰**：用小标题分段，首尾呼应（如开头引出ATAM，结尾总结效果）。 这些点基于标准ATAM流程，可直接参考提供的范文扩展。如果需要更具体的项目适配示例或工具调用（如代码验证），请提供更多细节。