当前位置：首页 > news >正文

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

news 2025/10/18 15:35:25

目的：适应需求变化（用户需求、业务环境、运行环境等），维持软件架构的有用性。
本质：软件整体结构的动态调整，贯穿架构全生命周期（需求获取、建模、实现、维护）。
核心价值：
- 保障系统质量属性：性能、可靠性、安全性、可维护性等依赖架构的持续优化。
- 降低演化成本：架构的可视化与形式化描述便于修改，减少波及效应。
- 控制复杂性：通过架构蓝图宏观管理系统的变化性与一致性。
关键原因：
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)。
约束演化特点：为何约束修改需拆分为“删除+新增”？
答：约束缺乏可视化描述，直接修改无法映射到自动机模型。