架构设计 相关文档，希望互相学习，****************************
****************************共同进步
知识总览
共19章内容，主要包括：
1）1绪论、2计算机系统、3信息系统、4信息安全技术、5软件工程
2）6数据库设计、7系统架构设计基础知识
3）8系统质量属性与架构评估、9软件可靠性、
10软件架构演化与维护、11未来信息综合技术
4）12信息系统架构设计、13层次式架构设计、14云原生架构设计、
15面向服务架构设计、16嵌入式系统架构设计、17通信系统架构设计、
18安全架构设计、19大数据架构设计
每天进步一点点，加油！小伙伴们！💪
本文学习 第10章 软件架构演化与维护，以下为个人笔记，希望有所帮助，共同学习。
（来源教材，扩展少，偏理论，单项3-5分，案例、论文）
包括：
软件架构演化和定义的关系（演化的重要性、演化和定义的关系）
面向对象软件架构演化过程（对象演化、消息演化、复合片段演化、约束演化）
软件架构演化方式的分类（软件架构演化时期、软件架构静态演化 | 动态演化）
软件架构演化原则、
软件架构演化评估方法（演化过程已知的评估、演化过程未知的评估）、
大型网站系统架构演化实例、
软件架构维护（软件架构知识管理、修改管理、版本管理、可维护性度量实践）
第10章 软件架构演化与维护
为了使软件能适应环境变化和满足用户需求，在软件架构生命周期中，不断迭代的演化和维护至关重要。考试中很多案例分析题、甚至论文题会出自本章内容。
软件架构的演化和维护：对架构进行修改和完善的过程，目的就是为了使软件能够适应环境的变化而进行的纠错性修改和完善性修改等，是一个不断迭代的过程，直至满足用户需求。
◆本质上讲，软件架构的演化就是软件整体结构的演化，演化过程涵盖软件架构的全生命周期，包括软件架构需求的获取、软件架构建模、软件架构文档、软件架构实现、软件架构维护等阶段。
10.1 软件架构演化和定义的关系
10.1.1 演化的重要性
◆软件架构演化的重要性体现在：
1）架构是整个系统的骨架，是软件系统具备诸多好的特性的保障；
2）软件架构作为软件蓝图为人们宏观管控软件系统的整体复杂性和变化性提供了一条有效途径。
（1）保障软件系统具备诸多好的特性。（2）有效管控软件系统的整体复杂性和变化性，降低软件检修和修改成本。
（3）保证软件系统演化的一致性和正确性，增加便捷性。
◆软件架构的演化能降低软件演化的成本的原因：1〉对系统的软件架构进行的形式化、可视化表示提高了软件的可构造性，便于软件演化。
2〉软件架构设计方案涵盖的整体结构信息、配置信息、约束信息等有助于开发人员充分考虑未来可能出现的演化问题、演化情况和演化环境。
3〉架构设计时对系统组件之间的耦合描述有助于软件系统的动态调整。
10.1.2 演化和定义的关系
软件架构包括：++组件、连接件、约束++三大要素。
因此软件架构演化主要关注 这三者之间的 添加、修改和删除。
10.2 面向对象软件架构演化过程
在面向对象软件架构中，组件、连接件、约束分别对应：对象、消息 和控制流、约束。
10.2.1 对象演化
在顺序图中，组件的实体是对象，对架构设计的动态行为产生影响的演化包括：AO 、DO
（1）Add Object（AO） 是在系统需要添加新的对象来实现某种新的功能，或需将现有对象的某个功能独立以增加架构灵活性时发生。
AO表示在顺序图中添加一个新的对象。这种演化一般是在系统需要添加新的对象来实现某种新的功能，或需要将现有对象的某个功能独立以增加架构灵活性的时候发生
。
（2）Delete Object（DO） 是在系统需要移除某个现有的功能，或需合并某些对象及其功能来降低架构的复杂度的时候发生。
DO删除顺序图中现有的一个对象。这种演化一般在系统需要移除某个现有的功能，或需要合并某些对象及其功能来降低架构的复杂度的时候发生。
10.2.2 消息演化
将消息演化分为5种： AM、DM、SMO、 OM、CMM。
（1）Add Message（AM）：
增添一条新的消息，产生在对象之间需要增加新的交互行为的时候。
（2）Delete Message（DM）：
删除当前的一条消息，产生在需要移除某交互行为的时候。
（3）Swap Message Order（SMO）：
交换两条消息的时间顺序，发生在需要改变两个交互行为之间的时候。
（4）Overturn Message（OM）：
反转消息的发送对象与接收对象，发生在需要修改某个交互行为本身的时候。
（5）Change Message Module（CMM）：
改变消息的发送或接收对象，发生在需要修改某个交互行为本身的时候。
10.2.3 复合片段演化
复合片段演化：复合片段是对象交互关系的控制流描述，表示可能发生在不同场合的交互，与消息同属于连接件范畴。 复合片断的演化包括 ：AF、DF、FTC、FCC。
（1）Add Fragment（AF）：
在某几条消息上新增复合片段，发生在需要增添新的控制流时。
（2）Delete Fragment（DF）：
删除某个现有的复合片段，发生在需要移除当前某段控制流时。
（3）Fragment Type Change （FTC）：
改变复合片段的类型，发生在需要改变某段控制流时。
（4）Fragment Condition Change（FCC）：
改变复合片段内部执行的条件，发生在改变当前控制流的执行条件时。
10.2.4 约束演化
约束演化，直接对约束信息增删，包括 Add Constraint（AC）、Delete Constraint（DC）。
（1）AC：直接添加新的约束信息，需判断当前设计是否满足新添加的约束要求。
（2）DC：直接移除某条约束信息，发生在去除某些不必要条件的时候。
10.3 软件架构演化方式的分类
三种比较典型的软件架构演化方式的分类：
3种典型的分类方法；
（1）按照软件架构的实现方式和实施粒度分类：基于过程和函数的演化、面向对象的演化、基于组件的演化和基于架构的演化。
（2）按照研究方法将软件架构演化方式分为4类：第1类是对演化的支持，如代码模块化的准则、可维护性的指示（如内聚和祸合）、代码重构等；第2类是版本和工程的管理工具；第3类是架构变换的形式方法，包括系统结构和行为变换的模型，以及架构演化的重现风格等；第4类是架构演化的成本收益分析，决定如何增加系统的弹性。
（3）针对软件架构的演化过程是否处于系统运行时期，可将软件架构演化分为静态、动态演化。
10.3.1 软件架构演化时期
软件架构的演化时期包括：设计时演化、运行前演化、有限制运行时演化、运行时演化。
（1）设计时演化：发生在体系结构模型与之相关的代码编译之前。
（2）运行前演化：发生在执行之前、编译之后。
（3）有限制运行时演化：只发生在某些特定约束满足时。
（4）运行时演化：发生在运行时不能满足要求时
习题：下列软件架构演化时期，（ ）是在系统设计时规定了演化的具体条件，将系统置于"安 全"模式下，演化只发生在某些特定约束满足时，可以进行一些规定好的演化操作。
A．设计时演化 B．运行前演化 时
C．有限制运行时演化 D．运行时演化
解析：
设计时演化：发生在体系结构模型与之相关的代码编译之前；
运行前演化：发生在执行 第 之前、编译之后；
有限制运行时演化：只发生在某些特定约束满足时；
运行时演化：发生在运行不 能满足要求时。
答案：C
10.3.2 软件架构静态演化
◆软件架构静态演化主要是：在设计时演化以及运行前演化。与此相对应的维护方法有3类：更正性维护、适应性维护、完善性维护。
1.静态演化需求
静态演化需求：设计时演化需求、运行前演化需求。
2.静态演化的5个步骤
静态演化的一般过程：软件理解→需求变更分析→演化计划→系统重构→系统测试
●软件理解：查阅软件文档，分析软件架构，识别系统组成元素及其之间的相互关系，提取系统的抽象表示形式。
●需求变更分析：静态演化往往是由于用户需求变化、系统运行出错和运行环境发生改变等原因所引花起的，需要找出新的软件需求与原有的差异。
●演化计划：分析原系统，确定演化范围和成本，选择合适的演化计划。
●系统重构：根据演化计划对系统进行重构，使之适应当前的需求。
●系统测试：对演化后的系统进行测试，查找其中的错误和不足之处。
3.静态演化的原子演化操作
一次完整软件架构演化过程可以看作经过一系列原子演化操作组合而成。所谓原子演化操作是指基于UML模型表示的软件架构，在逻辑语义上粒度最小的架构修改操作。每经过一次原子演化操作，架构会形成一个演化中间版本。
1)与可维护性相关的架构演化操作
架构演化的可维护性度量基于组件图表示的软件架构，在较高层次上评估架构的某个原子修改操作对整个架构所产生的影响。这些原子修改操作包括增加/删除模块间的依赖、增加／删除模块间的接口、增加/删除模块、拆分/聚合模块等。
AMD（Add Module Dependence）、RMD（Remove ModuleDependence）、AMI（Add Module Interface）、RMI（Remove Module Inferface）、AM（Add Module）、 RM（Remove Module）、SM（Split Module）、AGM（Aggregate Modules）。
2)与可靠性相关的架构演化操作
架构演化的可靠性评估基于用例图、部署图、顺序图，分析在架构模块的交互过程中某个原子演化操作对交互场景的可靠程度的影响。这些原子修改操作包括增加／删除消息、增加／删除交互对象、增加/删除/修改消息片段、增加／删除用例执行、增加/删除角色等。
AMS（Add Message）、RMS（Remove Message）、AO（Add Object）、RO（Remove Object）、AF（Add Fragment）、RF（Remove Fragment）、CF（Change Fragment）、 AU（Add Use Case）、RU（Remove Use Case）、AA（Add Actor）、RA（Remove Actor）。
4.静态演化实例：正交软件架构
静态演化里常用正交软件架构（Orthogonal Software Architecture） 来做修改分析和管理，核心思路是功能分层 + 线索化 ，让每次变动只影响一条线索，改动范围更可控。
🧱 核心思想
分层与线索化：把复杂系统的功能拆成多个层次，每层再按业务线索纵向切分，形成正交结构。
同层不交互：同一层次里的组件不允许互相调用，所以每个变动只影响自己所在的那条线索，不会牵连同层的其他部分。
🔄 演化步骤
需求变动归类：先把新需求或变更归到对应的组件和线索上，判断哪些可以复用。
制定演化计划：明确要改什么、怎么改，评估影响范围。
修改、增加或删除组件：按计划执行组件的增删改。
更新组件间相互作用：调整连接关系，保证改动后架构依然一致。
产出演化后架构：把新架构作为系统更新的详细设计方案和实现基础。
💡 为什么用正交架构
改动隔离：一条线索的变动不会波及其他线索，分析影响和回归测试都更轻松。
复用友好：需求归类后能快速看出哪些组件可以重用，减少重复开发。
10.3.3软件架构动态演化
动态演化是在系统运行期间的演化，需要在不停止系统功能的情况下完成演化，较之静态演化更加困难。具体发生在有限制的运行时演化和运行时演化阶段。
1.动态演化的需求
架构的动态演化主要来自两类需求： 软件内部执行所导致的体系结构改变、软件系统外部的请求对软件进行 的重配置。具体如下：
①软件内部执行所导致的体系结构改变，如 许多服务器端软件会在客户请求到达时创建新的组件来响应用户需求；
②软件系统外部的请求对软件进行的重配置，如 操作系统在升级时无须重新启动，在运行过程中就完成对体系结构的修改。
2.动态演化的类型
1）软件动态性的等级：交互动态性、结构动态性、架构动态性。
◆软件的动态性分为3个级别：
①交互动态性，要求数据在固定的结构下动态交互；
②结构动态性，允许对结构进行修改，通常的形式是组件和连接件实例的添加和删除，这种动态性是研究和应用的主流；
③架构动态性，允许软件架构的基本构造的变动，即结构可以被重定义，如新的组件类型的定义。
2）动态演化的内容：属性改名、行为变化、拓扑结构改变、风格变化。
◆属性改名：目前所有的ADL都支持对非功能属性的分析和规约，而在运行过程中，用户可能会对这些指标进行重新定义（如服务响应时间）。
◆行为变化：在运行过程中，用户需求变化或系统自身服务质量的调节都将引发软件行为的变化。
◆拓扑结构改变：如增删组件，增删连接件，改变组件与连接件之间的关联关系等。
◆风格变化：一般软件演化后其架构风格应当保持不变，如果非要改变软件的架构风格，也只能将架构风格变为其衍生风格，如两层C/S到三层C/S
习题：根据所修改的内容不同，软件的动态演化不包括（ ）。
A．属性改名 B．行为变化
C．拓扑结构改变 D．格式变化
解析：动态演化的内容：属性改名、行为变化、拓扑结构改变、风格变化。
答案：D
3.动态软件架构
目前，实现软件架构动态演化的技术主要有两种：采用动态软件架构（DSA）和进行动态重配置（DR）。DSA是指在运行时刻会发生变化的系统框架结构，允许在运行过程中通过框架结构的动态演化实现对架构的修改；DR从组件和连接件的配置入手，允许在运行过程中增删组件，增删连接件，修改连接关系等操作。
1）基于 DSA 实现动态演化的基本原理：是运行时刻体系结构相关信息的改变可用来触发、驱动 系统自身的动态调整。
实现软件架构动态演化的基本原理是使DSA在可运行应用系统中以一类有状态、有行为、可操作的实体显式地表示出来，并且被整个运行环境共享，作为整个系统运行的依据。也就是说，运行时刻体系结构相关信息的改变可用来触发、驱动系统自身的动态调整。
系统必须提供SA动态演化的一些相关功能：保存当前软件架构信息的功能、设置监控机制监视系统有无需求变化、保证演化操作原子性。
2）DSA 描述语言：基于行为视角的 π-ADL、基于反射视角的 Pilar、基于协调视角的 LIME。
3）DSA 演化工具：使用反射机制、基于组件操作、基于 π 演算、利用外部的体系结构演化管 理器
4）DSA实施动态演化大体遵循以下4步：
①捕捉并分析需求变化：
②获取或生成体系结构演化策略：
③根据步骤2得到的演化策略，选择适当的演化策略并实施演化；
④演化后的评估与检测。
4.动态软件架构应用实例：PKUAS
动态软件架构应用实例---PKUAS：包括容器系统、公共服务、工具、微内核 4 种类型。
(1)容器系统
(2)公共服务
(3)工具
(4)微内核
5.动态重配置
基于软件动态重配置的软件架构动态演化
◆主要是指在软件部署之后对配置信息的修改，常常被用于系统动态升级时需要进行的配置信息修改。一般来说，动态重配置可能涉及的修改有：
①简单任务的相关实现修改；②工作流实例任务的添加和删除：
③组合任务流程中的个体修改：④任务输入来源的添加和删除：
⑤任务输入来源的优先级修改：⑥组合任务输出目标的添加和删除：
⑦组合任务输出目标的优先级修改等。
1)动态重配置模式 ：主从模式、中央控制模式、客户端/服务器模式、分布式控制模式。2)例子：可重用、可配置的产品线架构
- 动态配置难点：约束定义困难、性能约束难以静态衡量、难以管理所有方面、需同时保证 组件系统完整性和重配置策略的正确和安全性。
ok, 今天就到这里吧 🤗
相关系列文章，欢迎点赞、收藏，提供意见！****
计算机系统基础知识 1分：概述、计算机硬件、计算机软件
操作系统 3分：进程管理、存储管理、文件管理、设备管理
数据库技术 3分：数据库设计、关系代数、范式、事务并发、数据库安全、新技术
嵌入式技术 3分：嵌入式硬件、嵌入式操作系统、嵌入式软件开发
计算机网络 3分（超纲较多）：OSI七层模型、TCP/IP协议族、网络生命周期、IP地址
其他计算机系统基础知识 1分：计算机语言、多媒体、系统工程
系统性能 1分：性能指标、性能设计
信息系统基础知识 3分：信息系统生命周期、开发方法、五大典型系统
信息安全技术基础 5分：安全属性、信息安全技术、网络安全技术、安全协议
软件工程 12分：概述、需求工程、系统设计、运维、测试、基于构件；
面向对象技术 3分：面向对象基础、分析设计、UML关系、图
项目管理 1分：进度管理、配置管理、质量管理、风险管理
系统架构设计 20分：架构概念、生命周期、ABSD、DSSA、架构风格、
架构复用、质量属性、架构评估
软件可靠性 2分：可靠性建模、软件可靠性设计
软件架构的演化和维护1分：架构演化分类、评估、面向对象架构演化
未来信息综合技术 3分：信息物理系统、人工智能、边缘计算、机器人、数字李生、云计算
数学与经济管理 2分：最小生成树、最短路径、网络与最大流量、线性规划、决策论
知识产权和标准化 2分：知识产权属性、保护期限、产权人确定、侵权判定
专业英语 5分：完形填空，大学英语3级难度，自学
|--------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|
| 【架构专栏】架构考试介绍 | 【架构专栏】架构知识点 |
| 【架构专栏】第1章 绪论 | 【架构专栏】第11章 未来信息综合技术 |
| 【架构专栏】第2章 计算机基础知识 | 【架构专栏】第12章 信息系统架构设计理论与实践 |
| 【架构专栏】第3章 信息系统基础知识 | 【架构专栏】第13章 层次式架构设计理论与实践 |
| 【架构专栏】第4章 信息安全技术基础知识 | 【架构专栏】第14章 云原生架构设计理论与实践 |
| 【架构专栏】第5章 软件工程基础知识 | 【架构专栏】第15章 面向服务架构设计理论与实践 |
| 【架构专栏】第6章 数据库设计基础知识 | 【架构专栏】第16章 嵌入式系统架构设计理论与实践 |
| 【架构专栏】第7章 系统架构设计基础知识 | 【架构专栏】第17章 通信系统架构设计理论与实践 |
| 【架构专栏】第8章 系统质量属性与架构评估 | 【架构专栏】第18章 安全架构设计理论与实践 |
| 【架构专栏】第9章 软件可靠性基础知识 | 【架构专栏】第19章 大数据架构设计理论与实践 |
| 【架构专栏】第10章 软件架构的演化和维护 | |
[架构专栏 知识点]
希望有所帮助，互相学习、共同进步，欢迎点赞、收藏！