22年东南大学软工软体复习整理资料
文章目录
- 软件架构体系猜题
-
- 选择题（10）
- 简答题（8）
-
-
- 1. 软件建模方法UML、文本、MDA对比
- 2. 敏捷开发中如何改变了软件架构的设计方式？
- 3. 成功的软件架构应该具有的品质
- 4. 将软件架构的概念和原则引入软件需求阶段有什么好处？不引入可能会引起什么问题？
- 5. 软件架构和软件需求是如何协同演化的？
- 6. 将软件架构映射到详细设计经常遇到什么问题？如何解决？
- 7. 为什么要进行软件架构度量
- 8. 架构度量和架构演化的关系
- 9.软件架构为什么会发生演化
- 10. 什么是软件重构？为什么要进行软件重构
- 12.基于度量评估的架构重构过程
- 13.架构腐蚀的含义？架构恢复的含义及意义？架构恢复与架构腐蚀的关系
- 14.软件架构脆弱性的成因
-
- 综合分析题（4）
-
- 4+1 View
- ATAM
-
- ATAM步骤
软件架构体系猜题
软件架构风格请参考我的另一篇文章
知识点梳理
由于软件复杂、易变化，其行为难以遇见，软件开发过程中需求和设计之间缺乏有效的转换，因此导致软件开发过程困难和不可控。随着软件系统规模越来越大、越来越复杂，整个系统的结构和规格说明显得越来越重要。
因此在需求和设计过程中引入软件架构，软件架构在高级层次上对软件进行描述，便于软件开发过程中的各个视角统一，能够及早发现开发中的问题并支持各种解决方案的评估和预测，其意义贯彻软件生命周期的每个阶段。
软件架构的思想：将注意力集中在系统总体结构的组织上
软件架构的特征：注重可重用性、利益相关者较多（平衡需求）、关注点分离（分而治之、模块化）、质量驱动、概念完整性（设计决策是一个持续的过程）、循环风格（架构风格）
软件架构的定义：组件（软件模块）、连接件（组件交互）、配置（组件和连接件的拓扑约束）、端口（组件作为封装对象与外部交互的接口如：过程调用、通信协议）、角色（连接件的参与者角色如：RPC的caller和callee、广播发布者和接受者）
-
组成派：组件与交互的集合
-
决策派：重要设计决策的集合
对比：架构风格的基本属性：设计元素的词汇表（组件、连接件的类型以及数据元素）、配置规则（拓扑约束）、语义解释与分析
软件架构在开发过程中的应用：
需求阶段：有助于保证需求规约和系统之间的可追踪性和一致性
设计阶段：SA的描述（4+1 or UML）、SA的设计与分析（目的：在系统被实际构造之前预测其质量属性）以及对SA设计经验的总结与复用（软件架构风格：对给定场景中经常出现的问题提供的一般性的可重用方案，它反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效的组织成一个完整的系统。）
实现阶段：将设计阶段的算法以及数据模型用设计语言进行表示
测试阶段：软件架构测试
维护阶段：在SA中针对维护性的目标进行分析时，需要对一些有关维护性（例如可扩展性、可替换性）进行规定。
如何描述软件架构——软件架构建模：对架构设计的决策的具象化和文档化（可视化）
软件架构风格的优势和好处：
-
可以极大地促进设计的重用性和代码的重用性，并且使得系统的组织结构易被理解。
-
使用标准的架构风格可较好地支持系统内部的互操作性以及针对特定风格的分析
敏捷开发：敏捷开发在实践中表现为一种迭代、增量和持续集成的开发方法。
敏捷开发和软件架构的关系：
- 都是一个权衡的过程、目的都是为了提高软件开发效率、提高软件质量、降低软件成本
- 敏捷开发也要重视软件架构
- 敏捷开发改变了软件架构的设计方式
两类常见敏捷软件架构设计方法：
规划式设计和演进式设计，具体体现为初始阶段设计和迭代过程中的设计。各种敏捷开发方法在实际应用中基本上都会在正式编码前有一个初步的设计得到一个原始架构。初始阶段输出了一个软件系统的原始架构，然后通过迭代过程进行完善。迭代将致力于重用、修改、增强目前的架构，以使架构越来越强壮。
软件产品质量：
◦ 性能：如何提高组件间的通信性能
◦ 可用性：如何保证专用组件的可用性专用组件,例如安全内核或认证服务器
◦ 可靠性：如何通过使用冗余组件实现容错，提高可靠性
◦ 安全性：如何保障组件的安全交互
◦ 易用性：如何保障组件和架构的易用性问题
◦ 可更改性：组件和架构的可更改性如何得到保障
◦ 可移植性：组件是否可移植，架构是否可移植
◦ 可重用性：组件间是否是松散耦合
◦ 可集成性：组件/连接件接口是否统一，是否兼容
◦ 可测试性：组件和连接件的测试难度如何，测试环境的配置是否比较困难等
软件架构的质量指标：
内部质量指标（直接、包括架构文档的可读性、数据的一致性兼容性、软件的可维护等）：
- 可维护性：软件系统或组件在纠正错误，提升性能或其他属性，以及适应变化的环境的修改容易程度
- 可重用性:指要合理地设计系统使得系统结构或其某些组件能够在未来的应用开发中可以重复使用的能力。
- 可移植性:系统能够在不同计算环境（或平台）下运行的能力
- 可集成性：是使其他独立开发的系统组件能够与待开发系统协同运行的能力。
- 可测试性：指通过测试（通常是基于运行的测试）使软件表露出缺陷的容易程度。
外部质量指标（间接、在软件系统运维过程中，软件系统体现出来的与软件架构有关的质量属性）：
- 性能 ：指系统的响应能力,即要经过多少时间才能对某个刺激(事件)做出响应,或者在某个时间段内所能处理的事件的个数。
- 可用性：指系统正常运行的时间比例。通过两次故障之间的时间长度或系统崩溃的情况下系统能够恢复正常运行的速度来衡量。
- 可靠性：可靠性指的是系统能够保持正常运行的能力。（容错、健壮）
- 安全性：衡量系统在向合法用户正常提供服务的情况下，阻止企图非授权使用，或者抗拒拒绝服务攻击（denial of service attack），并阻止信息泄露和丢失的能力。
- 易用性：用户
软件架构评估的必要性/讨论软件架构质量的意义：
◦ 最终软件产品质量问题是当前软件开发发展过程的重要核心关注点之一
◦ 问题发现的越早，解决问题的代价越小
◦ 软件架构自身存在着很高的质量需求
软件架构评估技术：基于问卷调查或检查表的评估技术（早）、基于场景的评估技术（中）、基于度量的评估技术（后）
技术债是指开发人员为了加速软件开发（或修改），或是由于自身经验的缺乏，有意或无意地在应该采用最佳方案时进行了妥协，使用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。分为：代码债、设计债、测试债、文档债
设计债识别方法：ASA问题识别、代码坏味道识别、设计模式污垢识别、模块化冲突
技术债的处理：发现技术债、管理技术债、偿还技术债
代码坏味道：如果程序中的某一段代码是不稳定或者有一些潜在问题的，那么该段代码往往会包含一些明显的不太好的痕迹。我们称这些痕迹为“代码坏味或者代码异味”。 （应用级、类级、方法级）
架构坏味道：在系统粒度下出现的层次要高于代码坏味道，是一种通常使用的、可以对系统生命周期特性产生消极影响的架构设计。
选择题（10）
-
软件重构的类别：架构重构、结构调整、代码重构
-
架构腐蚀的预防控制方法：腐蚀最小化；腐蚀预防；腐蚀修补
-
代码坏味道：如果程序中的某一段代码是不稳定或者有一些潜在问题的，那么该段代码往往会包含一些明显的不太好的痕迹。我们称这些痕迹为“代码坏味或者代码异味”。 （应用级、类级、方法级）
-
软件架构的质量指标
-
软件架构的定义：组件（软件模块）、连接件（组件交互）、配置（组件和连接件的拓扑约束）、端口（组件作为封装对象与外部交互的接口如：过程调用、通信协议）、角色（连接件的参与者角色如：RPC的caller和callee、广播发布者和接受者
-
软件架构评估技术：基于问卷调查或检查表的评估技术（早）、基于场景的评估技术（中）、基于度量的评估技术（后）
简答题（8）
1. 软件建模方法UML、文本、MDA对比
| 软件架构建模方法 | 描述 | 优点 | 缺点 |
|---|---|---|---|
| 基于UML的建模方法（现在） | UML定义了一组丰富的模型元素以建模组件、接口、关系和约束。 | 通用的模型表示方法便于理解和交流、多视图从不同角度刻画软件架构、有大量辅助建模的工具提高开发效率 | 只针对特定的面向对象的架构 、对系统行为的语义的精确性不足、多视图建模产生信息冗余和不一致、非形式化不能保证开发的可靠性 |
| 基于文本语言的建模方法（以前） | 通过文本文件描绘架构，需要符合某些特殊的句法格式（XML建模） | 单个文档中描述整体架构，并且存在众多文本编辑器方便用户与文本交互、可以通过程序对语法检查 | 限制于显示连续满屏的文本很难以另外的方式组织文本、表示类图形结构不易理解 |
| 基于MDA的建模方法（未来） | 以代码为中心到以模型为中心，使模型不仅作为设计文档和规格说明使用，更能成为一种能够自动转换为最终可运行系统的重要软件（PIM、PSM） | 将模型与实现分离后，能够很好的适应技术的易变性。由于实现往往高度依赖特定的技术和特定的平台，当技术发生迁移的时候，只需对技术做相应的实现 | 目前技术不成熟、软件开发的创造性减弱了 |
MDA的基本思想：将软件系统分成模型和实现两部分：模型是对系统的描述，实现是利用特定技术在特定平台或环境中对模型的解释。模型仅仅负责对系统的描述，与实现技术无关。这是模型的实现技术无关性。
MDA的步骤：
- CIM捕获需求
- 创建PIM
- 将PIM转化为PSM，加入平台特定的规则和代码
- 将PSM转为代码
2. 敏捷开发中如何改变了软件架构的设计方式？
敏捷开发重视软件的架构设计但是轻架构的详细设计。敏捷开发将传统的架构设计分成：种子架构设计和详细架构设计。分离后种子架构的内容包括：软件的架构层次、重要模块、重要类的说明等。
敏捷开发把传统软件开发前期的详细架构设计，分散到了整个敏捷开发软件过程中，以达到提高效率、减少风险的目的。
3. 成功的软件架构应该具有的品质
- 良好的模块化
- 适应功能需求的变化，适应技术的变化
- 对系统的动态运行有良好的规划
- 对数据的良好规划
- 明确、灵活的部署规划
4. 将软件架构的概念和原则引入软件需求阶段有什么好处？不引入可能会引起什么问题？
需求分析主要考虑问题域和系统责任，其目的是得到一个正确、一致并且无二义的需求规约，作为后续开发、验证及系统演化的基础。
若把架构概念引入需求分析阶段，有助于保证需求规约、系统设计之间的可追踪性和一致性，有效保持软件质量。将软件架构概念和原则引入需求分析，也可以让我们获得更有结构性和可重用的需求规约。
用传统的方法产生需求规约，不考虑软件架构概念和原则，则在软件架构设计阶段建立需求规约与架构的映射将相对困难。
5. 软件架构和软件需求是如何协同演化的？
双峰模型强调软件需求和软件架构的平等性，在发展需求和架构规约的同时，继续从解决方案的结构和规约中分离问题的结构和规约。
6. 将软件架构映射到详细设计经常遇到什么问题？如何解决？
| 问题 | 解决方法 |
|---|---|
| 缺失架构视图，片面强调功能需求 | 对缺失的架构视图进行设计补充 |
| 架构设计方案过于笼统不够深入，停留在概念性架构层面，没有明确的技术蓝图 | 将设计决策细化到技术相关的层面 |
| 名不副实的分层架构，缺失层次之间的交互接口和交互机制，只进行职责划分 | 明确层次之间的交互接口和交互机制 |
| 某些方面过度设计 | 虽然需要考虑系统的扩展性和可维护性，但是切记过度设计 |
7. 为什么要进行软件架构度量
软件架构作为软件开发过程中早期阶段的设计模型，如果通过软件架构度量能够预测待开发的软件产品质量，并能够即时地发现早期设计缺陷，这对于减少开发风险和提高最终软件产品质量是非常重要的。
8. 架构度量和架构演化的关系
可以举例从基于度量的软件架构重构来谈
9.软件架构为什么会发生演化
软件架构在构建之后不可避免的要进行修改，进入演化和维护阶段；
架构的演化和维护既存在于软件开发期间，也存在于软件维护期间；
在软件运行期间所进行的架构演化为架构动态演化，较之架构静态演化更加的困难而重要；
软件架构有静态演化（系统停止运行期间的修改和更新，即一般意义上的修复和升级）需求：
- 设计时演化需求：在架构开发和实现过程中对原有架构进行调整，保证软件实现与架构的一致性以及软件开发过程的顺利进行；
- 运行前演化需求：软件发布之后由于运行环境的变化，需要对软件进行修改升级，在此期间软件的架构同样要进行演化。
软件架构有动态演化（系统运行期间的演化）需求：
- 软件内部执行所导致的体系结构改变。 例如，许多服务器端软件会在客户请求到达时创建新的组件来响应用户需求；
- 是软件系统外部的请求对软件进行的重配置。例如，操作系统在升级时无须重新启动，在运行过程中就完成对体系结构的修改。
10. 什么是软件重构？为什么要进行软件重构
软件重构是进行软件优化和提高软件质量的重要手段之一。
在不改变软件的功能和外部可见性的情况下，为了改善软件的结构，提高软件的可读性、 可扩展性、可重用性、可维护性等质量属性的情况下而对其进行的改造。
简而言之，软件重构就是改进已经写好的软件设计、提高软件的某些质量属性。
12.基于度量评估的架构重构过程
产生重构需求
架构持续演进原则达成性度量结果作为识别重构需求的入口，当度量过程结束后，识别度量结果中未达成的架构持续演进原则子指标，通过对子指标度量公式的分析判断是否可以通过重构操作达成子指标。
重构建议
在明确重构需求以及明确架构缺陷之后，我们应针对不同重构需求下的不同架构缺陷选择恰当的方法对系统进行重构，重构方法应明确重构对象以及重构操作 对象以及重构操作。
| 度量原则 | 重构原因 | 重构建议 |
|---|---|---|
| 模块独立演进原则 | 组件之间依赖关系复杂 | 降低文件之间耦合 |
| 主体维持原则 | 组件和组件之间的依赖关系变动太大 | 定位组件具体变化反馈用户 |
| 平滑演进原则 | 组件规模平均变化率过大 | 定位规模具体变化反馈用户 |
13.架构腐蚀的含义？架构恢复的含义及意义？架构恢复与架构腐蚀的关系
软件架构腐蚀（software architecture erosion）是指预期软件架构或概念软件架构与实际软件架构之间的偏离。它意味着最终的实现并没有完全满足预定的计划或违背了系统的约束和规则。这种偏离更多的是源自日常的软件修改，而非人为的恶意。
软件架构恢复的主要目的是从工程项目中获取所需的架构信息，恢复出架构的组成元素，即组件元素、连接件元素、架构模式以及架构的配置信息等。
通过对恢复出来的软件体系结构进行分析，开发人员可以快速对其进行必要的评估，在软件设计、编码和测试等多个阶段进行相应的改进。
架构腐蚀会导致软件演化过程中出现工程质量的恶化。 若通过人工阅读代码的方式理解架构，费时费力，并非良策。 在此情况下，通过逆向工程恢复软件架构就很有意义。
14.软件架构脆弱性的成因
软件脆弱性是导致破坏系统安全策略的系统安全规范、系统设计、实现和内部控制等方面的弱点。
软件的脆弱性的原因：软件脆弱性就是软件开发过程（如需求分析、软件设计、程序编码等） 中的错误，也可能是系统配置过程中的错误。
软件架构脆弱性属于软件设计脆弱性或软件结构脆弱性的一种。
综合分析题（4）
4+1 View
ATAM
ATAM步骤
- 陈述ATAM方法
- 陈述产品动机
- 陈述架构系统
- 确定架构体系结构
- 生成质量属性效用树
- 分析架构体系结构
- 集体讨论并确定场景优先级
- 分析架构体系结构
- 总结报告