软件体系结构与风格复习一

总结了软件体系结构风格的经典部分。

从软件架构风格的定义，到软件架构模型，到一些经典的软件架构风格。然后是敏捷开发中的软件架构，之后是软件架构风格的设计和实现，最后是软件架构风格的质量和评估。

这是整个课程的开展顺序，还是很有逻辑性的。其中重点部分是二十种软件架构风格及其优缺点以及最后的软件架构质量评估。如果百分制的话，这两单元可能占到60分,复习一的其它部分占20分。后面复习二的Unit11-18只占20分。

多提一嘴，质量效用树的构建一定会考，这也是软考高级系统架构设计师的必考题！

复习中穿插了一些题目，都是近几年软考真题。

Unit 1 概述

1.1软件架构的思想和特征

主要思想：软件架构是整个软件设计的蓝图，软件架构关注的不仅仅是总体架构，还有质量属性以及功能与结构直接的关系。软件架构主要关注的两个焦点是：软件总体架构的组织，软件结构与需求之间的一一映射。主要思想：关注与软件总体架构的组织。

特征：关注点分离、注意可重用性、利益相关者较多、注意使用架构设计风格

-------------------这一章没什么东西

Unit 2 软件架构的定义

2.1参考性定义框架

组件、连接件、配置、端口、角色

-------------------这一章也没什么东西

Unit 3 软件架构模型

3.1 软件架构建模的方法?

（1）基于非标准图形的建模方法

（2）基于UML的建模方法（优缺点）

优点:

支持多视图结构，可以全面的描述软件架构；

使用统一的模型，便于理解和交流；

有效利用图形开发工具，有效缩短开发周期，提高开发效率；

?统一的交叉引用图形信息，有利于维护开发元素的可处理性

（3）基于形式化的建模方法

（4）基于UML的形式化建模方法

（5）基于文本语言的建模方法

通过文本文件描述架构，这些文本文件通常需要符合某些特殊的句法格式

（6）基于MDA的建模方法（Model dependency Architure）

核心思想是抽象出与实现不相关、且完整描述业务功能的平台独立模型

3.2 “4+1”视图（4和1分别是什么？）

逻辑、过程、开发、物理（罗锅开物）+ 用例

例题：

AA

Unit4 软件架构经典风格

4.1 什么是软件架构风格？

软件架构风格是指某些特定领域开发所常用的惯用模式，这些风格为开发人员提供了术语交流空间，在一定程度上提高了开发效率，而且提高了软件架构的重用性。

4.2 软件架构风格的好处

1. 开发人员能够使用统一的风格术语进行开发，极大的提高了开发效率，降低了软件架构的理解难度；

2. 软件风格的使用，进一步提高了软件架构的复用性和代码的复用性。

4.3 经典软件架构风格21种（特点、优缺点、适用范围）

（这一块没什么好办法，诀窍就是多重复，每天早起一个小时背上一遍）

（微信小程序算异构风格）

（手机的消息通知算事件驱动风格）

（1）数据流风格

批处理风格、管道-过滤器风格

（2）调用返回风格

主程序-子程序风格、面向对象风格、层次化风格、C/S风格、两层C/S风格、三层C/S风格、B/S风格

（3）解释器风格

虚拟机风格、基于规则的风格

（4）以数据为中心的风格

仓库风格、黑板风格

（5）事件驱动风格

（6）其他风格

C2风格、平台插件风格、面向Agent风格、面向SOP风格、面向服务风格、微服务风格、正交风格、异构风格、MVC风格

基于层次架构之类的不会考大题（反复说的可能会考大题，标红的）

接下来通过一个表格来总结一下各个风格的特点、优缺点、应用场景，因为我发现只靠脑子太难记了。这是纵向来背，当然也可以横向来背，根据优缺点找风格

软件架构风格	风格特点	风格优点	风格缺点	风格适用场景
批处理风格
管道-处理器风格		高内聚、低耦合 模块间关联较弱，可拓展性较好 可重用性也较好	处理数据，性能降低； 安全性较低 交互性较差	传统编译器、 linux管道、 数据处理、 ? ? ?图像处理
主程序-子程序风格
面向对象风格
层次化风格		可拓展，上下分层 可重用（接口稳定）	（1）难以确定一个准确的分层结构； （2）层层相调用，系统性能下降； （3）底层服务一旦出现错误，可能会导致整个系统的无法运行	TCP/IP协议
C/S风格		（1）可以将一个较大的业务分布式的部署在多个服务器上，降低了服务端的成本，且便于处理分布式数据； （2）可以配置不同的硬件和软件，可拓展性较好	（1）对客户端的配置要求比较高； （2）客户端更新时，每台客户机都要进行更新，成本较高	原神PC端
两层C/S风格			客户端直接与数据库交互，安全性较低
三层C/S风格		将客户端与数据库隔离开，提高了系统的安全性	系统性能取决于多个方面，如果3层C/S架构中各层之间的通信效率较低，那么即使服务器性能很高，系统的总体性能依然会很低
B/S风格		（1）用户只需安装浏览器，操作简单，成本较低； （2）且部署维护是只需更新服务器和数据库，成本较低 （3）能进行跨平台通信	（1）系统动态交互性较差，数据提交只能通过HTML进行； （2）服务器负载较重，是整个系统性能的核心； （3）可拓展性较差，数据交互通过HTTP等协议进行，系统的安全性难以保证； （4）个性化较差，几乎所有的用户进行同样的操作	云原神，以及各种4399小游戏
虚拟机风格			多了一层调用关系，可能会导致系统性能下降
基于规则的风格
仓库风格		（1）可以对模块进行修改、增加、删除； （2）便于模块间的数据共享； （3）避免了重复知识源的添加	对数据进行操作时，需引入同步加锁机制以确保数据的完整性和正确性； 不能确保结果的准确
黑板风格		（1）实现了知识源的重用； （2）可以随时添加或删除知识源代理		自然语言处理
事件驱动风格		可拓展性 可维护性，只要组件和其订阅的事件名称未变，就可以使用新的组件替换原来的组件	让出了系统的控制权； 不能保证消息的正确性	（比如手机的消息提醒）
C2风格
平台-插件风格（优点有点类似微服务风格，但是平台插件的各模块之间有个交集（平台），但是微服务没有，这也进而导致了微服务的底层代码可能在各个服务里会有重用）		模块之间低耦合； 模块之间关联较弱，便于系统的修改和维护； 用户可以根据需求灵活的组装软件	某个平台的插件只能适用于这一个平台，可重用性较差
面向Agent风格
面向SOP风格
面向服务风格
微服务风格		（1）系统模块独立部署，独立开发，每一个服务只专注于自己的功能； （2）当系统达到瓶颈时，只需要将达到瓶颈的服务单独进行改进和性能提升即可，降低了维护成本；	（1）将原本的一个服务拆分为多个服务，在一定程度上提高了运维成本； （2）代码具有重用性，可能不同的服务之间需要通道同一块底层代码进行处理，可能具有一定的代码重用坏味道
正交风格		??
异构风格		可以实现代码的重用	不同风格之间的融合较为困难	（微信小程序）
MVC风格		当功能发生改变时，只需要修改系统中的某一部分即可	（1）MVC没有明确的定义，较难进行划分； （2）可能对相同的数据进行了多次调用，降低了系统性能； （3）如果一些较为简单的程序使用MVC风格，反而可能会增加代码的复杂性； （4）增加了系统结构和实现的复杂性。

质量属性	优点	缺点
性能	（1）微服务风格：当系统性能达到瓶颈时，只需将达到瓶颈的服务性能进行提升即可； （2）MVC风格：当功能发生变化时，改变其中的一部分模型就能满足要求	（1）管道-过滤器风格：过滤器可能需要对管道输入输出到数据进行处理，增加系统复杂性，降低了系统性能 （2）层次化风格：层层相调，影响性能 （3）三层C/S架构：性能取决于多个方面，如果各层之间通讯效率不高，那么即使服务器效率很高，系统的整体性能也不会很高 （4）B/S风格：应用服务器处理所有事物，性能瓶颈取决于应用服务器 （5）MVC风格：重复的数据进行多次调用，难免会影响系统性能
安全性	B/S架构	管道-过滤器风格：攻击者可通过数据的输入输出得到过滤器的规则，具有一定的安全隐患 C/S架构：客户端可直接访问数据库，安全性较差 黑板风格：对数据的操作需要引入同步加锁机制，以保证数据的正确性和完整性
交互性	B/S架构：能实现跨平台交互	管道-过滤器风格：没法进行人机交互 C/S架构：只能在局域网进行，难以扩展到Internet；交互内容和形式较为单一 B/S架构：无法进行动态交互，人机交互只能通过HTML文件进行
低耦合：	管道过滤器风格 平台插件风格
模块化	仓库风格：方便模块的增删改 平台插件风格; 微服务风格;
可拓展性	层次化风格：上下分层，便于拓展 C/S架构：软硬件配置具有极大灵活性，易于功能的拓展 黑板风格:便于添加新的代理源，也方便扩展黑板风格的数据结构	B/S架构：可拓展性较差
可重用性	层次化风格：接口稳定，便于重用 黑板风格：知识源可重用 事件驱动风格：只要是在系统事件中注册组件的过程，就可以将该过程集成到系统中	MVC风格：视图和控制器之间耦合较深，妨碍了系统的重用
可维护性	事件驱动风格：只要组件名和事件中注册的过程名不变，原有组件就可以被新组组件替代 微服务架构：每个服务都是独立部署的，每次更新都不会对整体业务造成影响
可修改性
成本	C/S架构：通过将大规模的业务逻辑分配到多个网络连接的低成本计算机上，降低了服务端的开发成本。且有利于分布式数据的处理； B/S架构：客户端只需安装浏览器，操作简单，成本较低；且只需维护应用服务器和数据库即可，降低了维护成本	C/S架构：对客户端的配置要求较高，同时客户端更新时每一台客户机都要对软件进行更新，维护成本较高 微服务架构：将一个应用拆分成多个服务进行运维部署，一定程度上加大了开发和维护的成本
个性化	平台插件	B/S架构
风格难以使用或者划分层次		层次化风格 MVC风格 正交风格

Unit 6 敏捷开发和软件架构

6.1 敏捷开发如何改变了软件架构风格

敏捷开发将软件前期开发的详细设计过程啊，分散到了整个敏捷开发过程中，以提高效率减少风险

6.2 两种常见的敏捷开发方式

（规划式设计、演进式设计）具体表现为初始阶段设计和具体迭代过程中的设计。一般敏捷开发方法都会在正式编码前有一个初步的设计，输出一个软件系统的原始架构，然后通过迭代过程进行完善。

Unit 7-8? 软件架构的设计和实现

7.1 良好的软件架构应具有的品质

（1）良好的模块化；（2）能够适应需求、技术栈的变化；（3）对系统的动态运行有良好的规划（4）数据结构的规划；（5）良好的部署规划

8.2 软件架构和软件需求是如何协同演化的？

软件架构和软件需求之间是相辅相成的。一方面需求影响着软件架构的设计，另一方面软件架构的设计能够帮助进一步明确软件需求

8.3 MDA的基本思想、过程、应用MDA的好处

基本思想：将软件架构设计与实现分离开

过程：

计算无关模型（CIM）：捕获需求。也称为业务模型，描述系统外部行为和运行环境。

平台无关模型（PIM）：创建PIM。无关任何实现技术的模型。

平台相关模型（PSM）：将PIM转化为PSM，最后将PSM转化为代码。为实现某种技术量身定做的模型

好处：将模型与实现相分离，能够很好的适应技术的易变性。由于实现往往依赖于特定的平台，当某种技术发生变化时，只需针对这种技术做出相应的实现，编写相应的运行平台即可。由此可以使模型更好的适应如今技术快速发展的时代? ? ?

?Answer：A

8.4 软件架构设计面临的主要威胁

（1）被忽略的重要非功能需求：全面认识需求

（2）频繁变化的需求：关键需求决定架构

（3）考虑不全面的架构设计：多视图探寻架构

（4）较高的创造性的架构比重：合理分配经验架构（80%）与创新架构（20%）比重

（5）架构的低可执行性：验证架构的可执行性

（6）不及时的架构验证：尽早验证架构

Unit 9-10 软件架构质量与测试

9.1 软件架构的质量属性、场景

开发期质量即内部质量，运行期质量即外部质量

内部属性：模块化、可测试性、可维护性、可拓展性

外部属性：性能、安全性、可用性、可靠性

场景：是指从风险承担者的角度对与系统交互进行的描述。一般采用环境、刺激、响应三方面来对场景进行描述

质量属性场景：

例题：

CC

例题：

AC

例题：

B? ?树根+质量属性+具体属性分类+场景

D

9.2 ATAM（体系结构权衡分析）方法

（1）敏感点、权衡点、质量效用树

敏感点：一个或多个构件的特征，可以使设计师搞清楚实现质量目标是需要注意什么

权衡点：影响多个质量属性的特征，是多个质量属性的敏感点。

（2）评估过程

（3）质量效用树的构建（要记得标注优先级）

（4）优缺点，相比SASM方法

SASM方法构造了针对某一质量属性构造了多个场景以来评定场景对质量属性的适应度，而ATAM是针对多个质量属性提出场景，来分析某个场景对不同质量属性的适用度，以达到在不同质量属性之间进行权衡的效果。