软件架构是具有一定形式的结构化元素,即构件的集合,包括处理构件,连接构件和数据构件。处理构件负责对数据进行加工,数据构件是被加工的信息,连接构件把架构的不同部分组合连接起来。
特点:
1、软件架构风格是描述某一特定领域中系统组织方式的惯用模式;
2、软件架构为软件系统提供了一个结构、行为和属性的高级抽象;
3、软件架构是项目干系人进行交流的手段;
4、软件架构是早期决策的体现;
5、软件架构是可传递和可复用的模型;
6、架构制约这系统的质量属性,通过研究软件架构可能预测软件的质量。
软件架构建模也就是如何表示软件架构,可以分为五种:结构模型、框架模型、动态模型、过程模型和功能模型。
这里我们重点总结下“4+1”视图模型。“4+1”视图模型从5个不同的视角(逻辑、进程、物理、开发、场景)来描述软件架构。
逻辑视图:主要支持系统的功能需求,即系统提供给最终用户的服务。
开发视图:也称为模块视图,主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织,这样,对于一个软件系统,就可以由不同的人进行开发。
物理视图:主要考虑如何把软件映射到硬件上,它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。
进程视图:侧重于系统的运行特性,主要关注一些非功能性的需求,例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力,以及逻辑视图中的主要抽象的进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象,每个级别分别关注不同的方面。
场景:可以看作是那些重要系统活动的抽象,它使四个视图有机地联系起来,从某种意义上说,场景是最重要的需求抽象。在开发架构时,它可以帮助设计者找到架构的构件和它们之间的作用关系。
PS:以下内容过长,以理解为主,实际工作中知道这么回事就行了。
以下内容参考:《系统架构设计师教程》
数据流风格包括批处理序列和管道/过滤器架构风格。
(1)批处理序列架构风格。组件为一系列固定顺序的计算单元,组件间只通过数据传递交互。每个处理步骤是一个独立的程序,每一步必须在前一步结束后才能开始,数据必须是完整的,以整体的方式传递。
(2)管道/过滤器架构风格。每个构件都有一组输入和输出,构件读输入的数据流,经过内部处理,然后产生输出数据流,经过处理,产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成,包括通过计算和增加信息丰富数据,通过浓缩和删除精炼数据,通过改变记录方式转化数据,递增地转化数据等。在输入被完全消费之前,输出便产生了。这里构件被称为过滤器,连接件就是数据流传输的管道,将一个过滤器的输出传到另一过滤器的输入。
调用/返回风格包括主程序/子程序架构风格、数据抽象和面向对象架构风格以及层次结构架构风格
(1)主程序/子程序架构风格。单线程控制,把问题划分为若干处理步骤,构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制,即充当连接件。调用关系具有层次性,其语义逻辑表现为子程序的正确性取决于它调用的子程序的正确性。
(2)数据抽象和面向对象架构风格。这种风格的构件是对象。对象是抽象数据类型的实例。在抽象数据类型中,数据的表示和它们的相应操作被封装起来。对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式,对象是通过函数和过程的调用来交互的。对象具有封装性,一个对象的改变不会影响其他对象。对象拥有状态和操作,也有责任维护状态。这种结构风格中包含有封装、交互、多态、集成、重用等特征。
(3)层次结构架构风格。层次系统组织成一个层次结构。构件在一些层实现了虚拟机。连接件通过决定层间如何交互的协议来定义,拓扑约束包括对相邻层间交互的约束。这个风格的特点是每层为上一层提供服务,使用下一层的服务,只能见到与自己邻接的层。大的问题分解为若干个渐进的小问题,逐步解决,隐藏了很多复杂度。修改一层,最多影响两层,而通常只能影响上层。上层必须知道下层的身份,不能调整层次之间的顺序。它是一种常见的架构设计方法,能够有效简化设计,使设计的系统结构清晰,便于提高复用能力和产品维护能力。一般来说,企业应用系统的架构可以分为 表现层、中间层和持久层三个层次。
表现层。表现层主要负责接收用户的请求,对用户的输入、输出进行检查与控 制,处理客户端的一些动作,包括控制页面跳转等,并向用户呈现最终的结果信息。表现层主要采用MVC结构来实现。控制器负责接收用户的请求,并决定应该调用哪个模型来处理;然后,模型根据用户请求调用中间层进行相应的业务逻辑处理,并返回数据;最后,控制器调用相应的视图来格式化模型返回的数据,并通过视图呈现给用户。
中间层。中间层主要包括业务逻辑层组件、业务逻辑层工作流、业务逻辑层实体和业务逻辑层框架四个方面。业务逻辑层组件分为接口和实现类两个部分,接口用于定义业务逻辑组件,定义业务逻辑组件必须实现的方法。通常按模块来设计业务逻辑组件,每个模块设计为一个业务逻辑组件,并且每个业务逻辑组件以多个DAO组件作为基础,从而实现对外提供系统的业务逻辑服务。业务逻辑层工作流能够实现在多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行,从而实现某个预期的业务目标,或者促进此目标的实现。业务逻辑层实体提供对业务数据及相关功能的状态编程访问,业务逻辑层实体数据可以使用具有复杂架构的数据来构建,这种数据通常来自数据库中的多个相关表,业务逻辑层实体数据可以作为业务过程的部分I/O参数传递,业务逻辑层的实体是可序列化的,以保持它们的当前状态。业务逻辑层是实现系统功能的核心组件,采用容器的形式,便于系统功能的开发、代码重用和管理。
持久层。持久层主要负责数据的持久化存储,主要负责将业务数据存储在文件、 数据库等持久化存储介质中。持久层的主要功能是为业务逻辑提供透明的数据访问、持久化、加载等能力。
独立构件风格包括进程通信架构风格和事件驱动的架构风格
(1)进程通信架构风格。构件是独立的过程,连接件是消息传递。这种风格的特点是构件通常是命名过程,消息传递的方式可以是点对点、异步和同步方式、以及远过程调用等
(2)事件驱动的架构风格。构件不直接调用一个过程,而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册,当一个事件被触发,系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程的调用。这种风格中的构件是非命名的过程,它们之间交互的连接件往往是以过程之间的隐式调用(Implicit Invocation)来实现的。基于事件的隐式调用风格的主要优点是为软件重用提供了强大的支持,为构件的维护和演化带来了方便,其缺点是构件放弃了对系统计算的控制。
虚拟机风格包括解释器架构风格和基于规则的系统
(1)解释器架构风格。一个解释器通常包括完成解释工作的解释引擎,一个包含将被解释的代码的存储区,一个记录解释引擎当前工作状态的数据结构,以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机,可以仿真硬件的执行过程和一些关键应用。其缺点是执行效率较低。
(2)基于规则的系统。基于规则的系统包括规则集、规则解释器、规则/数据选择器以及工作内
存。
仓库风格包括数据库架构风格和黑板架构风格
(1)数据库架构风格。数据库架构是库风格最常见的形式。构件主要有两大类,一个是中央共享数据源,保存当前系统的数据状态,另一个是多个独立处理元素,处理元素对数据元素进行操作。
(2)黑板架构风格。黑板架构包括知识源、黑板、控制三部分。知识源包括若干独立计算的不同单元,提供解决问题的知识,知识源响应黑板上的变化,也只修改黑板。黑板是一个全局数据库,包含解域的全部状态,是知识源互相作用的唯一媒介。知识源响应是通过黑板状态的变化来控制。黑板通常应用在对于解决问题没有确定性算法的系统中,例如信号处理、问题规划、编译器优化等软件系统的设计中。