系统架构设计（二）

 软件架构风格

软件架构风格概述

• 软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
• 架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。
• 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则
• 软件架构设计的一个核心目标问题是能否达到架构级的软件复用

数据流体系结构风格

数据流体系结构风格，面向数据流，按照一定的顺序从前向后执行程序，主要包括批处理风格和管道-过滤器风格。

批处理体系结构风格

构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式传递。构件是独立的应用程序，连接件是某种类型的媒介。

管道-过滤器体系结构风格

每个过滤器(处理步骤)都有一组输入和输出，过滤器从管道(数据传输)中读取输入的数据流，经过内部处理，产生输出数据流并写入管道中。前一个过滤器的输出作为后一个过滤器的输入，前后数据流关联。构件就是过滤器，连接件就是管道。早期编译器就是采用的这种架构，要一步一步处理的，均可考虑此架构风格。

二者区别在于批处理前后构件不一定有关联，并且是作为整体传递，即必须前一个执行完才能执行下一个。管道-过滤器是前一个输出作为后一个输入，前面执行到部分可以开始下一个的执行

调用／返回体系结构风格

调用/返回风格是指在系统中采用了调用与返回机制。其主要思想是将一个复杂的大系统分解为若干子系统，以便降低复杂度，并且增加可修改性。构件之间存在互相调用的关系，一般是显式的调用，主要包括主程序/子程序风格、面向对象风格、层次型风格、客户端/服务器风格以及浏览器服务器体系结构风格。

主程序/子程序风格

采用单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。过程调用作为交互机制，充当连接件的角色

面向对象体系结构风格

构件是对象，或者说是抽象数据类型的实例，连接件是对象间交互的方式。对象是通过函数和过程的调用来交互的。

层次型体系结构风格

构件组成一个层次结构，连接件通过决定层间如何交互的协议来定义。每一层为上层提供服务，并作为下层的客户，只对与自己相邻的层可见。修改某一层，最多影响其相邻的两层(通常只能影响上层)。

层次型结构优点:
(1)支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现。
(2)不同的层次处于不同的抽象级别，越靠近底层，抽象级别越高。
(3)每一层最多只影响两层，为软件复用提供了强大的支持。
层次型结构缺点:
(1)并不是每个系统都可以很容易地划分为分层的模式。
(2)很难找到一个合适的、正确的层次抽象方法

客户端/服务器体系结构风格

C/S(客户端/服务器)软件体系结构是基于资源不对等，且为实现共享而提出的。
两层C/S体系结构有3个主要组成部分:数据库服务器、客户应用程序和网络。服务器(后台)负责数据管理，客户机(前台)完成与用户的交互任务，称为“胖客户机，瘦服务器”
三层C/S结构增加了一个应用服务器。整个应用逻辑驻留在应用服务器上，只有表示层存在于客户机上，故称为“瘦客户机”应用功能分为表示层、功能层和数据层三层。表示层是应用的用户接口部分，通常使用图形用户界面;功能层是应用的主体，实现具体的业务处理逻辑;数据层是数据库管理系统。以上三层逻辑上独立。表示层在客户机上，功能层在应用服务器上，数据层在数据库服务器上。（需要下载客户端，如QQ微信)

浏览器/服务器体系结构风格

B/S架构是三层C/S架构的变种，将客户端变为用户客户端上的浏览器，将应用服务器变为网络上的WEB服务器，又称为零客户端架构。其三层结构为:浏览器、Web服务器和数据库服务器。虽然不用开发客户端，但有很多缺点:

• 对动态页面的支持能力较弱，没有集成有效的数据库处理功能;
• 安全性难以控制
• 在数据查询等响应速度上，要远远低于C/S架构
• 数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用

以数据为中心的体系结构风格

以数据为中心的体系结构以数据为中心，所有的操作都是围绕建立的数据中心进行的，主要包括仓库体系结构风格和黑板体系结构风格。

仓库体系结构风格

仓库(Repository)是存储和维护数据的中心场所。仓库架构风格由中央数据结构(说明当前数据状态)和一组独立构件(对中央数据进行操作)组成。连接件是仓库与独立构件之间的交互。

黑板体系结构风格

包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，修改黑板:黑板是一个全局数据库包含问题域解空间的全部状态，是知识源相互作用的唯一介;知识源响应是通过黑板状态的变化来控制的。黑板架构风格适用于解决复杂的非结构化的问题,能在求解过程中综合运用多种不同知识源，使得问题的表达、组织和求解变得比较容易，如信号处理、问题规划和编译器优化等。

虚拟机体系结构风格

虚拟机体系结构风格的基本思想是人为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言，这样来增加架构的灵活性。自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配，主要包括解释器风格(JVM)和规则系统风格。

解释器体系结构风格

通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，缺点是执行效率低。

规则系统体系结构风格

基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存，一般用在人工智能领域和决策支持系统DSS中。

独立构件体系结构风格

独立构件体系结构风格主要强调构件之间是互相独立的，不存在显式的调用关系(返回)，而是通过某个事件触发、异步的方式来执行，以降低耦合度，提升灵活性。主要包括进程通信和事件系统风格(隐式调用)。

进程通信体系结构风格

构件是独立的进程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程(方法)调用等。

事件系统体系结构风格

基于事件的隐式调用风格。构件不直接调用一个过程，而是触发调用。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。
主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便，缺点是构件放弃了对系统计算的控制

C２体系结构风格

C2体系结构风格可以概括为，通过连接件绑定在一起按照一组规则运作的并行构件网络。C2风格中的系统组
织规则如下:
(1)系统中的构件和连接件都有一个顶部和一个底部:
(2)构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的:
(3)一个连接件可以和任意数目的其他构件和连接件连接;
(4)当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

软件架构复用

软件架构复用的定义及分类

软件架构复用是系统化的软件开发过程:开发一组基本的软件构件模块，以覆盖不同的需求/体系结构之间的相似性，提高系统开发的效率、质量和性能。
软件架构复用的类型包括机会复用和系统复用。机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用。系统复用是指在开发之前，就要进行规划，以决定哪些需要复用。

软件架构复用的原因

减少开发工作、减少开发时间、降低开发成本、提高生产力、提高产品质量，更好的互操作性，使产品维护变得更加简单。

软件架构复用的对象及形式

可复用的资产包括:需求、架构设计、元素、建模与分析、测试、项目规划、过程方法和工具、人员、样本系统、缺陷消除。
一般形式的复用包括:函数的复用、库的复用、面向对象开发中的类、接口和包的复用。

软件架构复用的基本过程

(1)构造/获取可复用的软件资产(复用的前提)。首先需要构造恰当的、可复用的资产，并且这些资产必须是可靠的、可被广泛使用的、易于理解和修改的。
(2)管理可复用资产。该阶段最重要的是:构件库(ComponentLibrary)，其对可复用构件进行存储和管理，是支持软件复用的必要设施。构件库应提供的主要功能包括构件的存储、管理、检索以及库的浏览与维护等，以及支持使用者有效地、准确地发现所需的可复用构件。
(3)使用可复用资产。在最后阶段，通过获取需求，检索复用资产库，获取可复用资产，并定制这些可复用资产:修改、扩展、配置等，最后将它们组装与集成，形成最终系统。

特定领域软件体系结构

ＤＳＳＡ的定义

DSSA(Domain Specific Sofware Architecture，DSSA)就是在一个特定应用领域中为一组应用提供组织结构参考的标准软件体系结构，即用于某一类特定领域的标准软件构件的集合。
DSSA就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础，其目标就是支持在一个特定领域中多个应用的生成。
从功能覆盖的范围的角度有两种理解DSSA中领域的含义的方式。
(1)垂直域:定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构。即在一个特定领域中的通用软件架构。
(2)水平域:定义了在多个系统和多个系统族中功能区城的共有部分。在子系统级上涵盖多个系统族的特定部分功能。(如购物和教育都有收费系统，收费系统即是水平域)。

DSSA的基本活动

领域分析

这个阶段的主要目标是获得领域模型(领域需求)。识别信息源，即整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。

领域设计

这个阶段的主要目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求DSSA。

领域实现

这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。

参与DSSA的人员

参与DSSA的人员可以划分为4种角色:
(1)领域专家:包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。主要任务包括提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型DSSA等领域工程产品等。
(2)领域分析人员:由具有知识工程背景的有经验的系统分析员来担任。主要任务包括控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中。
(3)领域设计人员:由有经验的软件设计人员来担任。主要任务包括根据领域模型和现有系统开发出DSSA，并对DSSA的准确性和一致性进行验证。
(4)领域实现人员:由有经验的程序设计人员来担任。主要任务包括根据领域模型和DSSA，开
发可重用的构件。

DSSA的建立过程

DSSA的建立过程分为5个阶段:
(1)定义领域范围:领域中的应用要满足用户一系列的需求。
(2)定义领域特定的元素:建立领域的字典，归纳领域中的术语，识别出领域中相同和不相同的元素(3)定义领域特定的设计和实现需求的约束:识别领域中的约束，记录这些约束对领域的设计和实现会造成什么后果。
(4)定义领域模型和架构:产生一般的架构，并描述其构件说明。
(5)产生、搜集可复用的产品单元:为DSSA增加复用构件，使其可用于新的应用系统。DSSA的建立过程是并发的、递归的、反复的和螺旋型的。

DSSA的三层次系统模型:

• 领域开发环境:领域架构师决定核心架构，产出参考结构、参考需求、架构、领域模型、开发工具。
• 领域特定的应用开发环境:应用工程师根据具体环境来将核心架构实例化。
• ·应用执行环境:操作员实现实例化后的架构。