系统架构设计师备考第43天——软件架构演化和定义

目的：适应需求变化（用户需求、业务环境、运行环境等），维持软件架构的有用性。
本质：软件整体结构的动态调整，贯穿架构全生命周期（需求获取、建模、实现、维护）。
核心价值 ：
- 保障系统质量属性：性能、可靠性、安全性、可维护性等依赖架构的持续优化。
- 降低演化成本：架构的可视化与形式化描述便于修改，减少波及效应。
- 控制复杂性：通过架构蓝图宏观管理系统的变化性与一致性。
关键原因 ：
1. 形式化架构描述提升可构造性；
2. 架构设计预判未来演化场景；
3. 组件耦合设计支持动态调整。

架构定义多样性 ：存在近百种架构定义（如 5A={组件, 连接件, 约束}），演化需结合具体定义。
演化操作分类 ：
- 组件演化：增删改计算单元（如模块），波及交互消息变化。
- 连接件演化：调整组件间交互关系（消息增删改），常伴随组件演化。
- 约束演化：修改拓扑配置或参数（如知识库数据变更），影响架构合规性。
波及效应 ：变更分为直接影响元素 （主动修改部分）和间接影响元素（受牵连部分）。

操作类型 ：
- AddObject (AO)：新增对象（需新功能或功能独立化）。
- DeleteObject (DO)：删除对象（移除功能或合并对象降复杂度）。
关键规则 ：对象演化需伴随消息演化（否则无实际意义），否则不影响架构动态行为。

演化类型 ：

定位：控制流描述（如分支、循环），属连接件范畴。
演化类型 ：
- AddFragment (AF) ：新增控制流（如ref、par片段）。
- DeleteFragment (DF)：移除控制流（AF的逆向操作）。
- FragmentTypeChange (FTC) ：改变片段类型（如alt→opt）。
- FragmentConditionChange (FCC)：修改执行条件（影响转移触发事件）。
影响：可能改变消息执行流程，需验证是否引发意外错误。

操作类型 ：
- AddConstraint (AC)：新增约束（需验证当前设计是否满足）。
- DeleteConstraint (DC)：删除约束（通常设计天然满足）。
特点：约束以文本形式存储（如LTL公式），无可视化自动机描述。修改约束视为"删除+新增"。

架构演化重要性：结合质量属性（性能、可靠性）说明演化必要性。
- 考题示例 ：为什么说软件架构是"演化来的"而非"设计来的"？
  答：架构需持续适应环境变化，通过迭代修改维持有用性（生命周期特性）。
演化与定义的关系 ：以5A={组件,连接件,约束}为例分析演化操作。
- 考题示例 ：删除一个组件会导致哪些连锁变化？
  答：组件删除 → 关联连接件（消息）删除 → 依赖约束可能失效。
消息演化分类：区分5种消息操作（AM/DM/SMO/OM/CMM）的场景及影响。
- 考题示例 ：SwapMessageOrder是否必然导致架构错误？
  答：不一定，需检查是否违反时序约束（如"A必须在B前执行"）。
复合片段演化 ：识别AF/DF/FTC/FCC对应的UML操作。
- 考题示例 ：将顺序图中的alt片段改为par属于哪种演化？
  答：FragmentTypeChange (FTC)。
约束演化特点 ：为何约束修改需拆分为"删除+新增"？
答：约束缺乏可视化描述，直接修改无法映射到自动机模型。

学习建议：结合UML顺序图工具模拟对象、消息、片段演化操作，直观理解波及效应。重点关注演化操作与架构定义的关联性（如5A模型），此为案例分析题高频命题点。