软件体系结构-软件体系结构风格
软件体系结构-软件体系结构风格
定义
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式
- 定义一个系统家族，即一个体系结构定义一个词汇表和一组约束
- 词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的
- 反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统
- 定义了用于描述系统的术语表和一组指导构建系统的规则
经典的体系结构风格
数据流风格
批处理序列
批处理序列强调数据是整体处理，数据作为一个整体一个步骤处理完了再进行下一个步骤的处理。
管道-过滤器
每个功能模块都有一组输入输出，功能模块从输入集合读入数据流，并在输出集合产生输出数据流，即功能模块对输入数据进行增量计算得到输出数据流
- 管道-过滤器模式下，功能模块被称为过滤器
- 功能模块间的连接看作输入、输出数据流之间的通路，称为管道
Linux中的grep命令
优点：
- 每个构件的行为不受其他构件的影响，整个系统易于理解
- 支持功能模块的复用
- 较强的可维护性可扩展性
- 支持特殊解析
- 支持并发执行
缺点：
- 导致系统处理过程的成批操作
- 多过滤器并发执行时数据流之间的同步问题
- 对数据传输进行特定处理会带来系统复杂性上升
- 并行处理的效率往往是假象
调用/返回风格
主程序/子程序
构建分为主程序和子程序，子程序可以构成模块，主程序的正确性决定于调用子程序的正确性
面向对象风格
- 数据的表示方法和它们相应的操作被封装在一个抽象数据类型或对象中
- 构件是对象，或者说是抽象数据类型的实例
- 对象通过函数和过程的调用来交互
层次结构
是按层次组织软件的一种软件体系结构
- 每一层软件都建立在低一层的软件层上
- 每一层都为上一层提供服务，并且接受下一层提供的服务
- 在分层系统的一些层次中构件实现了虚拟机的功能
例子：OSI网络7层模型
独立构件风格
进程通讯
强调构件是独立的过程，连接件是消息传递。
事件系统
- 构件不直接调用一个过程，而是触发或广播一个或多个事件
- 系统中其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用这个事件中注册的所有过程
- 构件是一个模块
- 事件的触发者不知道哪些构件会被这些事件影响
例子：观察者模式
虚拟机风格
解释器
解释器风格通常包含完成解释工作的引擎。
解释器风格通常被用于建立一种虚拟机，以弥合程序的语义与作为计算引擎的硬件的间隙。
例子：Java虚拟机，Unity Mono虚拟机
基于规则的系统
基于规则的系统包含规则集，规则解释器，一般用于人工智能领域。
仓库风格
数据库系统
超文本系统
黑板系统
由两个构件组成：
- 中央数据结构，表示当前状态
- 独立构件的集合，对中央数据结构进行操作
在黑板模式中，如果可用的组件超过一个，仲裁者（Moderator）组件决定程序执行的顺序。
应用在需要对数据做出复杂解释的信号处理中，这类系统包括语音和模式识别领域。
优点：
- 便于多客户共享大量数据，不用关心数据是何时出现的、谁提供的、怎样提供的。
- 既便于添加新的作为知识源代理的应用程序，也便于扩展共享的黑板数据结构。
- 可重用的知识源。
- 支持容错和健壮性。
缺点：
- 对于共享数据结构要达成一致，也造成对黑板数据结构的修改较为困难。
- 需要一定的同步锁机制。
- 测试困难
- 不保证有好的求解方案
- 低效
- 开发成本高
过程控制环路
将事务处理看成输入、加工、输出、反馈、再输入的一个持续的过程模型
持续性的加工处理
例子：定速巡航：将当前速度与设定速度比较
模型-视图-控制器风格
MVC风格
为那些需要为同样的数据提供多个视图的应用程序而设计的，很好地实现了数据层与表示层的分离。
C/S风格
基于资源不对等，且为实现共享而提出来的
三个部分组成：
-
数据库服务器
数据库安全性的要求；数据库访问并发性的控制；数据库前端的客户应用程序的全局数据完整性规则；数据库的备份和恢复
-
客户应用程序
提供用户与数据库交互的界面；向数据库服务器提交用户请求并接收来自数据库服务器的信息；利用客户应用程序对存在于客户端的数据执行应用逻辑要求
-
网络
优点：
- C/S体系结构具有强大的数据操作和事务处理能力， 模型思想简单，易于人们理解和接受
- 系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小
- 在C/S体系结构中，系统中的功能构件充分隔离，客户应用程序的开发集中于数据的显示和分析，而数据库服务器的开发则集中于数据的管理，不必在每一个新的应用程序中都要对一个DBMS进行编码。将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用
缺点：
- 开发成本较高
- 客户端程序设计复杂
- 信息内容和形式单一
- 用户界面风格不一
- 软件移植困难
- 软件维护和升级困难
- 新技术不能轻易应用
三层C/S风格：
在三层C/S体系结构中，增加了一个应用服务器，可以将整个应用逻辑驻留在应用服务器上，而只有表示层存在于客户机上。这种结构，被称为“瘦客户机”。
- 表示层
- 功能层
- 数据层
一般情况，是只将表示层配置在客户机中
优点：
- 允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，能提高系统和软件的可维护性和可扩展性。
- 允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
- 应用的各层可以并行开发，可以选择各自最适合的开发语言。
注意：
- 三层C/S结构各层间的通信效率不高
- 设计时必须慎重考虑三层间的通信方法、通信频率及数据量，这和提高各层的独立性一样是三层C/S结构的关键问题
B/S风格
- 用户界面完全通过浏览器实现，部分事务逻辑在前端实现，但是，主要事务逻辑在服务器端实现。
- 利用浏览器技术，结合浏览器的多种脚本语言并通过浏览器，就实现了原来需要复杂的专用软件才能实现的强大功能，是一种全新的软件体系结构。
上述三层应用结构的实现方式：浏览器、Web服务器、数据库服务器
优点：
- **系统安装、修改和维护全在服务器端解决。**用户在使用系统时，只需一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。
- B/S体系结构还提供了异种机、异种网、异种应用服务器的联机、联网、统一服务的最现实的开放性基础。
缺点：
- B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
- B/S体系结构的系统扩展能力差，安全性难以控制。
- 在数据查询等响应速度上，要远远低于C/S体系结构。
B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强（但现在有Ajax技术）
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 星辰微光的博客！
相关推荐
2024-01-15
软件体系结构-代理模式
软件体系结构-代理模式 定义 给某一个对象提供一个代理或占位符，并由代理对象来控制对原对象的访问。 UML类图 三个部分：Subject(抽象主题角色)、Proxy(代理主题角色)、RealSubject(真实主题角色) 代码 抽象主题角色： 123public abstract class Subject{ public abstract void request();} 代理主题角色： 12345678910111213141516public class Proxy extends Subject{ private RealSubject realSubject = new RealSubject(); public void preRequest(){ 前置业务代码 } public void postRequest(){ 后置业务代码 } public void request(){ ...
2024-01-15
软件体系结构-单例模式
软件体系结构-单例模式 定义 确保一个类只有一个实例，并提供一个全局访问点来访问这个唯一实例。 某个类只能有一个实例（private static） 必须自行创建这个实例（私有构造方法） 必须向整个系统提供这个实例（public getInstance） UML 单例模式的几种写法 饿汉式单例 12//在类被加载时就创建private static Singleton instance = new Singleton(); 懒汉式单例 123456789//在被引用时才加载private static Singleton instance = null;public static LazySingleton getInstance() { if (instance == null) { instance = new LazySingleton(); } return instance;} 懒汉式与双重检查锁定 12345678910111213141516171819public class...
2024-01-15
软件体系结构-命令模式
软件体系结构-命令模式 定义 将一个请求封装为一个对象，从而让你可以用不同的请求对客户进行参数化，对请求排队或者记录请求日志，以及支持可撤销的操作。 UML类图 四个部分： 抽象命令类Command 具体命令类ConcreteCommand 调用者Invoker 接收者Receiver 代码 抽象命令类 123public abstract class Command{ public abstract void execute();} 具体命令类 1234567public class ConcreteCommand extends Command{ private Receiver receiver; public void execute(){ receiver.action(); } } 调用者 123456789101112131415public class Invoker{ private Command command; public...
2024-01-15
软件体系结构-外观模式
软件体系结构-外观模式 定义 为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。 迪米特法则（最少知识原则）的体现 UML类图 两个部分：外观角色、子系统角色 外观模式+单例模式： 代码 子系统角色 12345public class SubSystemA{ public void mA(){ 业务代码 }} 外观角色 12345678910public class Façade{ private SubSystemA obj1 = new SubSystemA(); private SubSystemB obj2 = new SubSystemB(); private SubSystemC obj3 = new SubSystemC(); public void method(){ obj1.mA(); obj2.mB(); obj3.mC(); ...
2024-01-15
软件体系结构-工厂方法模式
软件体系结构-工厂方法模式 定义 简单工厂不符合开闭原则：添加新的产品类需要修改工厂类的代码 工厂方法模式： 不再提供一个工厂类来统一负责所有产品的创建，而是将具体产品的创建过程交给专门的工厂子类去完成 如果出现新的产品类型，只需要为这种新类型的产品定义一个具体的工厂类就可以创建该新产品的实例 目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类 开闭原则 √ UML类图 代码 抽象产品 123public abstract class ImageReader { public abstract void readImage();} 具体产品 123456public class GifReader extends ImageReader { @Override public void readImage(){ System.out.println("Read a gif"); ...
2024-01-15
软件体系结构-原型模式
软件体系结构-原型模式 定义 使用原型实例指定待创建对象的类型，并且通过复制这个原型来创建新的对象。 深克隆与浅克隆 浅克隆：当原型对象被复制时，只复制它本身和其中包含的值类型的成员变量，而引用类型的成员变量并没有复制（还是指向同一块地址） 深克隆：除了对象本身被复制外，对象所包含的所有成员变量也将被复制（引用变量有了一个新的地址） UML类图 在Java中通过继承Cloneable接口或Serializable实现浅克隆与深克隆 代码 浅克隆： 123456789101112131415161718public class ShallowCustomer implements Cloneable{ public ShallowAddress customerAddress = new ShallowAddress(); public ShallowAddress getCustomerAddress(){ return customerAddress; } @Override public...
