软件体系结构期末复习

软件体系结构期末复习要点

第一章 绪论

1. 软件工程的基本要素

• 过程：支持软件开发各个环节的控制和管理。
• 方法：完成软件开发任务的技术手段。
• 工具：为软件开发提供自动的或半自动的软件支撑环境。

2. 软件工程的过程

3. 软件工程的方法

• 面向服务：在应用表现层次上将软件构件化，即应用业务过程由服务组成，而服务由构件组装而成。
• 面向构件：寻求比类的粒度更大的且易于复用的构件，期望实现软件的再工程。
• 面向对象：以类为基本程序单元，对象是类的实例化，对象之间以消息传递为基本手段。
• 面向过程：以算法作为基本构造单元，强调自顶向下的功能分解，将功能和数据进行一定程度的分离。

第二章 软件过程

1. 软件过程模型的分类

2. 根据不同软件应用场景，选择合适的软件过程模型

1. 瀑布模型

特点：

• 以预测性为原则。
• 以文档驱动开发过程。
• 以过程控制为核心。

根据瀑布模型的特点(连续无反馈)是对于每一个阶段来说，前一个阶段工作的正确无误是至关重要的。因此，瀑布模型不能很好地适应那些需求不易确定和多变的软件项目的开发。由于大项目在软件开发的前期阶段，人们很难详细地了解系统的许多细节，从而在项目进行过程中常会出现需求变化。因此，瀑布模型适用于小系统开发项目，而不适用于大、中型软件系统开发。

2. 原型化模型

原型化方法首先根据系统分析人员对用户要求的理解，模拟出一个系统原型，然后就这个模型与用户展开讨论。所以，原型化方法是一种适应于需求不确定性的软件系统开发方法，即指在获得一组软件基本需求说明后，快速分析构造出一个小型的软件系统，满足用户的基本要求，使得用户可在试用原型过程中得到感受和启发，并做出反应、评价；然后开发者根据用户的意见对原型加以改进，获得新的原型版本，再次交由用户试用、评价。通过重复这一过程，逐步减少分析过程的误解，进一步确定需求细节，适应需求的变更，从而可提高最终产品的质量。

3. 迭代式开发

不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

4. 可转换模型

适合对安全性、可靠性和保密性要求极高的系统。

5. 案例

1. 汽车制动防抱系统

2. 网络公开课程网站

3. 医疗设备管理系统

3. 校园一卡通系统

第三章 概念与模型

1. 软件体系结构核心模型

2. 构件、连接件与约束

1. 构件

构件是具有某种功能的可复用的软件结构单元，表示系统中主要的计算元素和数据存储。

2. 连接

连接是构件间建立和维护行为关联与信息传递的途径。

3. 连接件

连接件表示构件之间的交互并实现构件之间的连接。

4. 约束

约束是作用于这些要素或连接关系上的限制条件。

• 一般构件是软件功能设计和实现的承载体
• 连接件是负责完成构件之间信息交换和行为联系的专用构件

3. 风格、模式和框架

• 体系结构风格：

用于描述某一特定应用领域中系统组织的惯用模式，反映了领域中众多系统所共用的结构和语义特性。

• 设计模式：

描述了软件系统设计过程中常见问题的一些解决方案，通常是从大量的成功实践中总结出来的且被广泛公认的实践和知识。

• 软件框架：

软件框架是由开发人员定制的应用系统的骨架，是整个或部分系统的可重用设计，由一组抽象构件和构件实例间的交互方式组成。

1. 框架和体系结构的关系：
   • 体系结构的呈现形式是一个设计规约，而框架则是“半成品”的软件；
   • 体系结构的目的是指软件系统的开发，而框架的目的是设计复用。
2. 框架和设计模式的关系：
   • ​ 框架给出的是整个应用的体系结构；而设计模式则给出了单一设计问题的解决方案，且可以在不同的应用程序或者框架中进行应用。
   • 举例：一个网络游戏可以基于网易的 Pomelo 框架开发，这是一个基于 Node.js 的高性能、分布式游戏服务器框架；在实现某个动画功能时，可能会使用观察者模式实现自动化的通知更新。
   • 设计模式的目标时改善代码结构，提高程序的结构质量；框架强调的是设计的重用性和系统的可扩展性，以缩短开发周期，提高开发质量.

4. Kruchten 的 4 + 1 模型组成

4：逻辑视图、进程视图、物理视图、开发视图

1：场景视图

1. 逻辑视图

• 当采用面向对象的设计方法时，逻辑视图即是对象模型。
• 逻辑视图主要支持系统的功能需求，即系统提供给用户的服务。

2. 开发视图

• 描述软件在开发环境下的静态组织。
• 开发视图也称模块视图，主要侧重于软件模块的组织和管理。

3. 进程视图

• 描述系统的并发和同步方面的设计。
• 进程视图侧重于系统的运行特性，主要关注一些非功能性的需求。

4. 物理视图

• 描述软件到硬件之间的映射关系，反映系统在分布方面的设计。
• 物理视图主要考虑如何把软件映射到硬件上，它通常要考虑到系统性能、规模、可靠性等。解决系统拓扑结构、系统安装、通讯等问题。

5. 场景视图

• 场景可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。在开发体系结构时，它可以帮助设计者找到体系结构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。
• 场景可以用文本表示，也可以用图形表示。

5. Rational 的 4 + 1 模型组成

4：设计视图、实现视图、交互视图、部署视图

1：用例视图

1. 用例视图

1. 用例视图
   • 用例视图包含描述用户、分析师和测试工程师看到的系统行为的用例。
   • 根据视图可确定系统架构。
2. UML
   • 静态方面由用例图描述。
   • 动态方面由交互图、状态图和活动图描述。

2. 设计视图

1. 设计视图
   • 设计视图包含构建系统的类、接口和类之间的协作。
   • 主要支持系统的功能性需求，也即系统提供给用户的服务。
2. UML
   • 静态方面由类图、对象图描述。
   • 动态方面由交互图、状态图和活动图描述。

3. 交互视图

1. 交互视图
   • 交互视图描述了系统不同部分之间的控制流，包括可能的并发和同步机制。
   • 主要解决了系统的性能、可拓展性、吞吐量等问题。
2. UML
   • 静态方面和动态方面的描述所采用图都和设计视图相同。

4. 实现视图

1. 实现视图
   • 实现视图包含用于组装和发布物理系统的组件。
   • 主要解决系统发布的配置管理问题。
2. UML
   • 静态方面用物件图描述。
   • 动态方面用交互图、状态图和活动图描述。

5. 部署视图

1. 部署视图
   • 部署视图包含形成系统硬件拓扑结构的节点。
   • 主要解决构成物理系统的部件的分布、发布和安装 问题。
2. UML
   • 静态方面由部署图描述。
   • 动态方面用交互图、状态图和活动图描述。

第四章 UML

1. 类图、交互图和状态图的图形组成、绘制方法

2. 类的属性、操作格式与解析、消息格式与解析

1. 类的属性

2. 操作格式与解析

3. 消息格式与解析

3. 根据需求描述进行模型分析，并绘制类图、顺序图和状态图

类图：86

顺序图：179

状态图：226

第五章 体系结构风格

1. 管道过滤器风格概念与应用场景

2. 以数据为中心的风格概念与应用场景

3. 事件风格概念与应用场景

4. MVC 风格、组成与应用场景

第六章 体系结构设计

1. 软件设计过程的基本步骤

2. 权衡软件设计目标的策略

3. 提高 Web 架构性能的方法

4. 文件数据、关系型数据库、NoSQL 数据库和基于内存数据库的特点和应用场景

1. 常用数据库介绍

2. 案例分析