架构演化的三要素与波及效应

软件架构一般经历初始设计、实际使用、修改完善、退化弃用的过程，其中”修改完善”就是架构的演化和维护过程——书中明确”软件架构是演化来的，而不是设计来的”这一判断，因为演化过程涵盖架构需求获取、建模、文档、实现、维护的全生命周期，而不只是某一个孤立阶段的动作。若按SA={components, connectors, constraints}这一经典定义理解架构，架构演化就主要体现在组件、连接件、约束三要素各自的添加、修改、删除上。组件是架构的基本结构单元，几乎所有消除缺陷、增加功能、适应新环境的演化都会涉及组件的变化，模块的增加会导致新增交互消息、删除模块会导致删除已有交互消息、改变模块会导致改变已有交互消息——这条因果链揭示了组件演化很少是孤立的。连接件是组件间的交互关系，大多数组件演化都会牵连连接件演化，除了随模块改变而改变外，还可能因系统内部结构调整、导致人与系统交互流程本身发生变化。约束是组件和连接件之间的拓扑关系和配置，为它们提供额外的数据支撑（架构约束数据或参数），约束的演化体现为知识库中仿真数据的增删改。无论哪种元素发生演化，都可能产生”波及效应”——变更会分出两类元素：受变更直接影响的元素，以及受到变更波及、间接受影响的元素，这两类变更元素连同不受影响的元素，共同组成演化后的软件架构。理解波及效应的价值在于：评估一次架构改动的真实成本，从来不能只看被直接修改的那一个组件，还要追踪它牵连的下游元素。