本文主要是介绍ADD属性驱动架构设计（一），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
一、架构设计过程
1.1、架构设计过程
1.1.1、设计目的
1.1.2、质量属性（非功能需求）
1.1.3、核心功能（功能需求）
1.1.4、架构关注
1.1.5、约束条件
1.2、基于设计过程
二、什么是ADD?
三、为什么选择ADD?
四、作用
五、ADD实现步骤
5.1、架构设计目标
5.1.1、系统类型确定
5.1.2、系统阶段确定
5.2、建立迭代目标
5.2.1 为研发选择参考架构
5.3、架构正式设计
5.3.1、任务分解
5.3.2、选择符合任务分解中的子目标相关输入进行概念设计
5.3.3、实例化架构元素、分配职责和定义接口
5.3.4、形成设计结果
5.3.5、回顾设计要点
5.4、步骤总结
六、质量研讨QAW
6.1、QAW是什么？
6.2、为什么需要QAW?
6.2.1、确保软件系统符合预期的质量标准
6.2.2、提高团队沟通和合作
6.2.3、确定关键的质量属性和优先级
6.2.4、提高软件系统的可维护性和可扩展性
6.3、QAW步骤
6.3.1.明确会议目标和议程确定QAW的目标和议程
6.3. 2.确定参与者和角色确定QAW参与者和他们的角色
6.3.3.讨论质量属性
6.3.4.确定质量属性的优先级和权重
6.3.5.确定度量和监控方法
6.3.6.汇总和记录讨论结果
6.3.7.跟进和持续改进
6.4、实践: QAW结合决策树用来分析非功能性参数
七、非功能性参数（质量参数）
八、案例
8.1、形成use-case
8.2、根据第一步开始梳理质量参数
8.3、定质量参数优先级与约束
8.4、然后我们就得到下面这个表格，然后我们就开始按照ADD步骤去实践编辑
一、架构设计过程
1.1、架构设计过程
1.1.1、设计目的
- 1、对于售前建议，通常涉及快速设计初始解决方案以方便估算
- 2、对于全新系统的开发，通常是确保最小化功能先上线
- 3、对于不断发展的系统，则是新增量或版本
1.1.2、质量属性（非功能需求）
- 性能、可用性、安全性和可测试性等。系统完整性(比如异常输入处理)
1.1.3、核心功能（功能需求）
- 业务逻辑，比如User-case
1.1.4、架构关注
- 输入验证
- 异常管理和日志记录
- 通讯
- 部署和更新
- 数据迁移和备份
- 代码库的组织
1.1.5、约束条件
1、技术限制或组织能力
2、客户或者团队员
3、约束是我们可以利用的点 (化敌为友)
1.2、基于设计过程
通过参数建模输出各种建模与设计
二、什么是ADD?
属性驱动设计：非功能性需求架构设计，ADD是一种由非功能(质量) 属性关注点“驱动”的架构设计方法。
是里克·卡兹曼教授及其团队专门针对软件构架的非功能 (质量) 属性需求而设计的一套开发方法论。
三、为什么选择ADD?
- 1、构架设计有可重复和借鉴内容
- 2、构架设计需要知识面广、流程复杂并且对系统有致关重要。
- 3、ADD相对其它软件方法更具体，更是技术人员需要优先掌握。
四、作用
- 它提供了一套详细的架构设计步骤：
- 1、使设计能够以系统的、可重复的方式进行
- 2、导致可预测的结果。
五、ADD实现步骤
5.1、架构设计目标
5.1.1、系统类型确定
一般我们可能是做很多系统，我们要确定我们要做的是什么系统？比如：
1、内部系统:对安全性要求低，性能和成本之间更考虑成本。
2、专家系统
3、医疗系统
4、高并发电商系统
5.1.2、系统阶段确定
就是确定我们当前系统处于什么阶段？
1、售前阶段。技术探索和研究性质。
2、原有系统功能升级和迭代。
3、移植旧系统。
有了架构目标之后我们就有了架构设计图
5.2、建立迭代目标
5.2.1 为研发选择参考架构
架构参考的一些原则：
1、迭代过程中解决的大多数子问题都可以总结为:
-希望避免重新发明轮子
-对于我们可能不是专家的问题，最好 (更快) 使用经过验证的解决方案，使用现有解决方案解决，即设计概念
2、需要考虑
-参考架构部署模式
-构架风格/模式
5.3、架构正式设计
5.3.1、任务分解
分解选择原则：
1、技术难度和复杂度
2、技术风险(新技术的使用)~
3、业务的重要程度
4、组织的标准
任务分解会影响步骤2的选择，所以他是一个重复迭代的过程
5.3.2、选择符合任务分解中的子目标相关输入进行概念设计
因为是反复迭代的，所以我们需要：
1、明确设计理念
2、评估和解决矛盾
选择设计理念可能是设计过程中将面临的最困难的决定因为它要求我们在可用于实现迭代目标的设计概念中识别备选方案，并从这些备选方案中做出选择
如:中间件选型，需要了解各种中间件类型
5.3.3、实例化架构元素、分配职责和定义接口
此时就是具体化
Step1和Step2有何不同？
1一个是理念，而需要将理念具体化2。
比如选择了Redis作为缓存，就需要考虑Redis具体的如何部署，使用单线程还是分布式对于模块就需要考虑接口。
5.3.4、形成设计结果
并不是一个完整的设计文档，先制作出一个架构性的文档。
5.3.5、回顾设计要点
在这一点上做出的决定与整体设计过程的进步一起进行分析，以确定是否需要更多的迭代。
5.4、步骤总结
1、确定需求输入
2、明确迭代目标。
3、任务分解。
4、选择设计理念、定义接口。
5、形成设计图。
6、审查是否满足了冲刺目标。
六、质量研讨QAW
6.1、QAW是什么？
质量属性研讨会(QualityAttribute Workshop)是一个促进头脑风暴会议，涉及一组系统利益相关者，涵盖获取、指定、优先排序和就质量属性达成共识的研讨活动。
架构师可以使用效用树 (Utility Tree)根据技术难度和风险对质量属性要求进行优先级排序。（这个就是排优先级，哪个需要先做，哪些后做）
QAW是根据Mission Thread Workshop (SEI提供方法论) 的思想而设计。
6.2、为什么需要QAW?
决策功能的最重要二个影响因素：功能需求和非功能需求，而非功能性需求容易被忽略
6.2.1、确保软件系统符合预期的质量标准
通过QAW，团队成员和相关利益相关者可以讨论和确定软件系统的关键质量属性，以确保软件系统满足预期的质量标准。这有助于减少质量问题和错误，提高软件系统的可靠性和可用性。
6.2.2、提高团队沟通和合作
QAW提供了一个平台，让团队成员和利益相关者可以共同讨论系统的需求和目标，以及如何实现这些目标。这有助于提高团队沟通和合作，确保每个人都了解他们的角色和职责，以及整个团队的目标。
6.2.3、确定关键的质量属性和优先级
QAW可以帮助团队成员和利益相关者确定关键的质量属性和优先级，以便在软件开发过程中重点关注这些质量属性。这有助于确保团队在软件开发过程中集中精力解决最重要的问题，并确保软件系统满足用户需求和期望。
6.2.4、提高软件系统的可维护性和可扩展性
- 通过讨论和确定软件系统的关键质量属性，QAW可以帮助团队成员和利益相关者确保软件系统易于维护和扩展。这有助于减少未来的技术债务和开发成本，并确保软件系统可以随着用户需求的变化而灵活地适应。
6.3、QAW步骤
6.3.1.明确会议目标和议程确定QAW的目标和议程
例如确定关键质量属性、确定权重和优先级、讨论度量和监控方法等等。
6.3. 2.确定参与者和角色确定QAW参与者和他们的角色
例如质量经理、项目经理、软件架构师、开发人员、测试人员、业务代表等等。
6.3.3.讨论质量属性
根据软件系统的需求和预期，讨论关键质量属性，并尽可能详细地描述它们。例如，可用性、可靠性、安全性、性能、可扩展性等等。
6.3.4.确定质量属性的优先级和权重
根据软件系统的需求和预期，讨论并确定每个质量属性的优先级和权重。这有助于确定开发过程中的关键重点和目标。
6.3.5.确定度量和监控方法
讨论并确定如何度量和监控每个质量属性。例如，使用哪些指标和工具来监测系统的性能、可靠性和安全性等等。
6.3.6.汇总和记录讨论结果
对讨论结果进行汇总和记录，包括每个质量属性的定义、优先级、权重和度量方法等等。这有助于确保整个团队对软件系统的质量属性有一个共同的理解，并有助于指导软件开发和测试过程。
6.3.7.跟进和持续改进
根据QAW的讨论结果，对软件开发和测试过程进行跟进和持续改进，以确保软件系统满足其预期的质量标准。
6.4、实践: QAW结合决策树用来分析非功能性参数
1、质量属性研讨会(QAW)和tility Tree是两个不同但可以结合使用的工具，用于确保软件系统满足其预期的质量属性。
2、Utility Tree是一种分层结构，用于描述软件系统的质量属性和关系。它由多个节点组成，每个节点表示一个质量属性，每个节点下面可以有多个子节点，用于进一步描述该质量属性。每个节点还可以定义该质量属性的权重和度量方式。
3、在结合使用OAW和Utility Tree时，可以按照以下步骤进行:
- 使用tilityTree描述软件系统的质量属性和关系:团队成员和利益相关者可以使用UtilityTree描述软件系统的质量属性和关系。他们可以讨论每个节点的定义，确定它们的权重和度量方式，并确定它们之间的关系。
- 在0AW中讨论和确定质量属性:基于utilitvTree的定义，团队成员和利益相关者可以在0AW中讨论和确定软件系统的关键质量属性。他们可以根据UtilityTree的结构和定义，讨论每个节点的重要性和优先级，并确定如何在软件开发过程中度量和监控这些质量属性。
- 在UtilityTree中更新和维护质量属性:根据QAW的讨论结果，团队成员和利益相关者可以更新和维护UtilityTree中的质量属性和关系。他们可以根据OAW的结果，调整每个节点的权重和度量方式，以确保软件系统满足预期的质量标准。
- 总结
利用Utility进行讨论的具体化：比如高并发，我们要30s完成什么指标等等，给他具体指标，不能含糊其辞，如下：
研讨：一起确认主题，大家认可的指标，群策群力，最后会得一个表格 Utility tree。最终我们系统的质量属性就 确定了
最后我们根据tree行程一个文档
七、非功能性参数（质量参数）
八、案例
8.1、形成use-case
分解目标功能，确定用户目标效果
8.2、根据第一步开始梳理质量参数
此时就通过QAW是分析质量参数
注意：质量参数的获取是跟功能需求中绑定的
8.3、定质量参数优先级与约束
1、定约束条件：maste have
2、定义关系点:nice have
8.4、然后我们就得到下面这个表格，然后我们就开始按照ADD步骤去实践
这篇关于ADD属性驱动架构设计（一）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
