敏捷宣言

• Individuals and interactions over processes and tools 人机交互重于过程和工具
• Working software over comprehensive documentation 可以工作的软件重于求全责备的文档
• Customer collaboration over contract negotiation 客户协作重于合同谈判
• Responding to change over following a plan 随时应对变化重于循规蹈矩

具有架构重要性的需求(Architecturally Significant Requirement ,ASR)

• 并非所有需求都是平等的。
• 具有架构重要性的需求（ASR）是对架构产生深远影响的需求。
• 我们如何找到这些需求呢？

捕捉架构重要性需求的方法

• 从需求文档中获取
• 通过与利益相关者进行面谈
• 通过理解业务目标
• 在效用树中(In Utility Tree)

具有架构重要性的需求和需求文档

设计策略(Design Strategy)

• 分解(Decomposition)
• 面向架构重要性需求的设计(Designing to Architecturally Significant Requirements)
• 生成和测试(Generate and Test)

分解(Decomposition)

• 架构决定了质量属性
• 重要的质量属性是整个系统的特征。
• 设计从整个系统开始
  • 整个系统被分解为各个部分
  • 每个部分可能继承全部或部分质量属性需求

架构与实现

• 保持代码和架构一致的技术：
  • 在代码中嵌入设计(Embedding the Design in the Code)
  • 框架
  • 代码模板

在代码中嵌入设计(Embedding the Design in the Code)

• 架构作为实现的蓝图。这意味着：
  • 实现者知道他们正在实现的架构结构。例如，层次结构、发布-订阅、MVC、代理等。
  • 他们可以将架构结构作为注释记录在代码中。这样，任何接手代码的人都会了解一些约束条件。
  • 然后，工具可以自动关联代码和架构。

三种评估形式

• 设计过程中由设计师进行的评估。
• 设计过程中由同行进行的评估。
• 架构设计完成后由外部人员进行的分析。

设计师的评估(Evaluation by the Designer)

• 每当设计师做出关键设计决策时，应对选择的备选方案进行评估。
• “生成和测试”方法中的“测试”部分。
• 需要进行多少分析？有三个因素包括：
  • 决策的重要性。
  • 潜在备选方案的数量。更多的备选方案需要更多的时间进行评估。
  • 足够好与完美相对。不要在决策上花费超过其价值的时间。

敏捷宣言

• Individuals and interactions over processes and tools 人机交互重于过程和工具
• Working software over comprehensive documentation 可以工作的软件重于求全责备的文档
• Customer collaboration over contract negotiation 客户协作重于合同谈判
• Responding to change over following a plan 随时应对变化重于循规蹈矩

具有架构重要性的需求(Architecturally Significant Requirement ,ASR)

• 并非所有需求都是平等的。
• 具有架构重要性的需求（ASR）是对架构产生深远影响的需求。
• 我们如何找到这些需求呢？

捕捉架构重要性需求的方法

• 从需求文档中获取
• 通过与利益相关者进行面谈
• 通过理解业务目标
• 在效用树中(In Utility Tree)

具有架构重要性的需求和需求文档

设计策略(Design Strategy)

• 分解(Decomposition)
• 面向架构重要性需求的设计(Designing to Architecturally Significant Requirements)
• 生成和测试(Generate and Test)

分解(Decomposition)

• 架构决定了质量属性
• 重要的质量属性是整个系统的特征。
• 设计从整个系统开始
  • 整个系统被分解为各个部分
  • 每个部分可能继承全部或部分质量属性需求

架构与实现

• 保持代码和架构一致的技术：
  • 在代码中嵌入设计(Embedding the Design in the Code)
  • 框架
  • 代码模板

在代码中嵌入设计(Embedding the Design in the Code)

• 架构作为实现的蓝图。这意味着：
  • 实现者知道他们正在实现的架构结构。例如，层次结构、发布-订阅、MVC、代理等。
  • 他们可以将架构结构作为注释记录在代码中。这样，任何接手代码的人都会了解一些约束条件。
  • 然后，工具可以自动关联代码和架构。

三种评估形式

• 设计过程中由设计师进行的评估。
• 设计过程中由同行进行的评估。
• 架构设计完成后由外部人员进行的分析。

设计师的评估(Evaluation by the Designer)

• 每当设计师做出关键设计决策时，应对选择的备选方案进行评估。
• “生成和测试”方法中的“测试”部分。
• 需要进行多少分析？有三个因素包括：
  • 决策的重要性。
  • 潜在备选方案的数量。更多的备选方案需要更多的时间进行评估。
  • 足够好与完美相对。不要在决策上花费超过其价值的时间。