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

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

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

这是整个课程的开展顺序，还是很有逻辑性的。其中重点部分是二十种软件架构风格及其优缺点以及最后的软件架构质量评估。如果百分制的话，这两单元可能占到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分别是什么？）

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

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风格正交风格