《软件工程》 第3篇 设计 姜久雷 副教授 北方民族大学 计算机科学与技术系

第10章 体系结构的设计 引言（本章的开头部分） 10.1 系统构成 10.2 控制模型 10.1.1 容器模型 10.1 系统构成 10.1.1 容器模型 10.1.2 客户机/服务器模型 10.1.3 抽象机模型 10.2 控制模型 10.2.1 集中式控制 10.2.2 事件驱动系统

引言 大型系统总是被分解成一些子系统，这些子系统提供一些相关的服务。 初始设计过程的任务是要识别出这些子系统并建立起子系统控制和通信的框架，这个过程叫做体系结构设计，其输出是软件体系结构的一个描述。 体系结构的设计过程主要关心的是为系统建立一个基本架构。它包括要识别出系统的主要组件以及这些组件之间的通信。

软件体系结构设计的重要性 1.项目相关人员之间的沟通 体系结构是系统的一个高层表示，可以作为不同的项目相关人员之间讨论的焦点。 2.系统分析 在系统开发的早期阶段给出系统的体系结构，实际上就是对系统的分析过程。对体系结构的设计决定对系统能否满足关键性需求如系统的性能、可靠性和可维护性等具有极深的影响。 3.大规模复用 系统体系结构的内容是关于系统的组织和组件间的互操作，其形式是一个紧凑的易于管理的描述单元。体系结构能在具有相似需求的系统之间互用，由此来支持大规模的软件复用。产品线体系结构的开发就是希望有一个通用的产品体系结构供一系列相关系统使用。

如何描述软件体系结构 体系结构描述语言（ADL）的基本要素是组件和连接器，这类语言包含了形成规范化体系结构所应该使用的规则和指南。 体系结构模型 1.静态结构模型——描述独立单元子系统或组件的相互关系。 2.动态过程模型——描述系统在运行时的过程。 3.接口模型——定义每个子系统从它们的公共接口能得到的服务。 4.关系模型——给出子系统间的关系，如数据流关系。 体系结构的描述 体系结构描述语言（ADL）的基本要素是组件和连接器，这类语言包含了形成规范化体系结构所应该使用的规则和指南。 非形式化模型和标记语言将会大量用在体系结构的描述上。如UML。

软件体系结构的由来——优秀开发者的设计经验总结 起缘于软件系统的模块化分解 进而，研究模块间相互作用，组合成整体的属性，便形成了体系结构。 后人即可利用这些体系结构的模式（architecture pattern）作为自己软件系统结构设计的策略。

体系结构风格——公认的体系结构模式 重要的体系结构风格 一些成功的体系结构模型或风格，是体系结构设计的重要基础。 需要对这些模型有相当的了解，才能有效使用。 不但要了解模型本身，还要了解它们的应用及其各自的优缺点。 设计者需要发现最适当的模型，然后依照问题的需求来修改它。 系统本身是一个复合型体系结构。通过融合不同的体系结构模型来达到这样的目的。 重要的体系结构风格 结构化模型、控制模型和分解模型。

软件的非功能需求 非功能性需求 一个应用程序的结构和风格，依赖于系统的非功能性需求。 1.性能——为满足性能需求，体系结构的设计需要提高子系统的关键操作性能——如：为了减少子系统间的通信，采用较大粒度组件）。 2.保密性——为满足保密性需求，体系结构的设计需要采用分层结构，把重要资源放在内层，并且在每层中采用更加严格的安全有效性验证。 3.安全性——为满足安全性的需求，系统体系结构的设计就要将与安全相关的操作集中在一个或少数几个子系统中。 4.可用性——为满足可用性需求，系统体系结构设计就要采用冗余性组件，以便能在无需系统停止运行的情况下更新和替换组件。 5.可维护性——为满足可维护性需求，系统体系结构设计就要使用小粒度的自包含组件以便于更换。

10.1 系统构成 10.1 System structuring 系统构成的描述方式 方块图是许多有用的体系结构的模型之一。 在最抽象层次，使用“方块图”描述一个体系结构的设计，每个方块代表一个子系统。 方块内的方块，意味着子系统本身又被分解成其他子系统。 方块之间的有箭头线段，表示数据和控制的流向。

方块图的优缺点 优点：有效沟通。在项目规划阶段，能够有效实现项目相关人员之间的沟通 它不掺杂细节，还能识别出每个关键子系统（可独立开发），便于管理者指派人员规划系统的开发。 缺点：不描述系统组件之间关系的本质，也不显示系统的外部特性 。

图10-1是一个打包机器人的系统体系结构的结构化模型。

方块图建模的三个标准模型 为描述子系统原理（如何共享数据、如何分布以及如何彼此交互），需要开发一些更专门化的模型。三个标准模型： 容器模型 客户机/服务器模型 抽象机器模型。

10.1.1 容器模型 系统原理：为子系统间信息交换提供基本的方法。有两种： 10.1.1 容器模型 系统原理：为子系统间信息交换提供基本的方法。有两种： 1.集中存放，各自存取——全部共享数据放在一个中央数据库中，所有子系统都能从中存取数据。 基于一个共享数据库的系统模型称为容器模型。 2.分散保持，消息传送——每个子系统维持自己的一个数据库，与其他子系统间的数据交互通过消息传递来实现。

例:基于一个共享容器的CASE工具集的体系结构

共享容器模型的优缺点： 是共享大量数据时的一个高效方法——无需在子系统间进行数据转换。 但是，子系统一定要与容器数据模型一致。 生产数据的子系统始终保持既有的数据结构，不管其他子系统是否长久适用。 但是，数据结构的进化会变得困难 数据管理活动集中，便于管理。 但是，难以兼顾不同的要求（保密性、恢复和备份等）。 共享模型能通过容器模式管理，能直接集成新工具的数据模型进入容器模型。 然而，将容器分布到多台机器上比较困难——会引起数据冗余和不一致性的问题。

黑板模型（智能化共享容器模型） 当容器数据的结构组织得不是很好时该方法比较合适。 “黑板”模型源于人工智能系统，当有特别的数据可用时，就会主动通报子系统。

10.1.2 客户机/服务器模型 客户机/服务器体系结构的模型 客户机/服务器方法能实现基于容器的系统 一种分布式系统的模型 10.1.2 客户机/服务器模型 客户机/服务器体系结构的模型 一种分布式系统的模型 其特征是：数据及其加工过程是在多个处理器之间的分配的。 客户机/服务器方法能实现基于容器的系统 容器充当系统的服务器。子系统扮演客户机角色，访问容器。 服务器和客户机进行交换数据的处理。 当有大量数据要交换的时候，会产生性能问题。

客户机/服务器模型的主要组成部分 1.单机服务器（一组）。给其他子系统提供服务，如打印服务器，文件服务器，编译服务器等。 2.客户机（ 一组）。向服务器请求服务，通常都是独立的子系统。多个客户机程序在并发运行。 3.一个连接客户机和服务器的网络。原则上，这并不是必需的，因为客户机和服务器可以同时运行在同一台机器上。但在实际过程中，这个模型并不在这样的情形中使用。

客户机/服务器模型示例（图10-3）——一个提供电影和图片库的多用户超文本系统。 要求目录能够支持各种查询并能与超文本信息系统相链接。客户机程序只是对这些服务提供集成的用户界面。

客户机/服务器模型的优势 缺点 是一个分布式体系结构。 许多分布处理器构成的网络系统可提供更有效的使用。 系统结构灵活，添加服务器或更新服务器是很容易的而且是透明的。 缺点 每集成一台新服务器，如果想获得系统的所有利益，就要改变现存的客户机和服务器的内容。 没有共享数据模型，子系统以不同的方式组织它们的数据 需要为每个服务器建立专门的数据模型以便优化其性能。 对来自新服务器的数据进行集成时很难预料出现的问题。 每个服务器需要自己负责数据管理活动，如备份和数据恢复。

10.1.3 抽象机模型 平台的概念 平台的分类 平台即平台化的软件——是独立的软件系统，用来构建和支撑应用软件。 10.1.3 抽象机模型 平台的概念 平台即平台化的软件——是独立的软件系统，用来构建和支撑应用软件。 平台的分类 粗略地划分——两种类型的平台：技术支撑型平台软件和应用实现型平台软件。 细致地划分 （1）基于快速开发目的技术平台，（2）基于业务逻辑复用的业务平台，（3）基于系统自维护、自扩展的应用平台。 技术平台和业务平台都是软件开发人员使用的平台，而应用平台则是应用软件用户使用的平台。

何为抽象机？ 特点 抽象机是对平台的抽象。 体系结构的抽象机模型，也叫做分层模型，是用来建立子系统的接口模型。 结构上，系统组织成一系列的层次，每一层提供一组服务——每一层定义一个抽象机，每个抽象机是由其下层的抽象机的代码构成的。

版本管理系统的抽象机模型

最典型的分层结构是网络通信协议。 由一套描述计算机程序之间如何进行通信的规则和约定来组成——ISO/OSI 7层模型。 分层抽象描述通信的物理-链路-网络-传输-会话-表示-应用这样固有的层次关系。每上层提供一个处理通信某特定部分的抽象功能，以作为上层通信的基础。 逻辑数据流 真实数据流

网络应用软件（平台）的抽象机结构 分层原则 优点 缺点 责任划分 层抽象 可维护， 重用，可扩展，可测试 通信传输量增加多 组件非额外的工作量大，性能受影响

体系结构的抽象机模型

10.2 控制模型 10.2 Control models 控制模型的作用 结构化模型没有涉及到信息的控制，因此需要在体系结构之外增加控制模型，以保证体系结构的运行： ——子系统必须得到控制以使它们的服务能在正确的时间传送到正确的地方 ——子系统之间存在控制流。 控制模型的作用 先有结构模型，再给出子系统的控制模型，便于分析系统的控制原理。 控制模型能够使结构模型得到集中式控制或基于事件控制。

控制模型的建模方法 1.集中式控制：考虑让一个子系统专门负责控制其他子系统的启动和停止。 2.基于事件的控制：让每个子系统都能接收来自外部子系统的事件并对此做出响应，而不是将控制信息集中在一个子系统内。

控制模型举例：访问控制模型 该模型以敏感度来划分资源的安全级别。 假如一个用户，他的安全级别为“高密“（命题者），想要访问安全级别为”秘密”的文档（题库），他将能够成功读取该文件，但不能写入；而安全级别为“秘密”的用户（题库管理员）访问安全级别为“高密”的文档（试卷），则会读取失败，但他能够写入（提供新试题）。这样，文档的保秘性就得到了保障。 控制

10.2.1 集中式控制 集中式控制模型 集中式控制模型的分类 把一个子系统指定为系统控制器，负责管理其他系统的执行。 10.2.1 集中式控制 集中式控制模型 把一个子系统指定为系统控制器，负责管理其他系统的执行。 集中式控制模型的分类 1.调用-返回模型 2.管理者模型 分类依据：子系统是顺序执行的还是并发执行？

解释：自上而下的子过程模型，控制始于子程序层次的顶层，在子程序调用过程中，控制逐步传递到更低的层次中。子程序模型只适用于顺序执行的系统。 “主”就是控制 解释：自上而下的子过程模型，控制始于子程序层次的顶层，在子程序调用过程中，控制逐步传递到更低的层次中。子程序模型只适用于顺序执行的系统。

管理者模型示例：一个并发系统的集中式控制模型 （图l0-6）。也称为事件-轮询模型。 “控制”的字样是必需的 注意：——适用于并发系统。 ——控制器控制其他系统过程的启动、终止和协调。 ——控制器内的管理程序根据状态变量来决定调用哪个子系统。

控制的本质——被控对象受到外界的作用（修正、影响、操纵和调节等），按照外界的要求动作。 时间 物质（外力） 特定的信息（事件）

10.2.2 事件驱动系统 事件驱动的控制模型 事件和输入的区别 事件——表面上是一个二进制信号，实质上是一个数据结构。 10.2.2 事件驱动系统 事件驱动的控制模型 事件——表面上是一个二进制信号，实质上是一个数据结构。 系统通过来自外部的事件来驱动自身的动作。 事件和输入的区别 事件的到来不受处理它的那个过程控制。 输入，是事先设计好的，受处理过程的控制。 系统需要读取状态信息来处理事件。

不同的基于事件驱动的系统 电子表格 专家系统 面向对象的程序 改变一个单元的值会引起其他单元的值的修改； 人工智能中使用的基于规则的产生式系统,当一个条件变为真时，一个相应的动作被触发 面向对象的程序 对于主动对象，当对象的属性值发生了改变，一系列相关的动作就会被触发执行。

两种事件驱动系统的控制模型 1.广播模型——事件可以广播到所有子系统，任何能处理该事件的子系统都会响应。 广播模型在基于网络的分布式系统中很有效。 2.中断驱动模型——专用于实时系统，由中断处理器对来自外部的中断进行检测，然后在其他组件中处理这些中断。 中断驱动模型在对定时有极严格要求的实时系统中广泛采用。

图10-7所示广播模型的特点： 子系统预先注册感兴趣的事件，当这些事件发生的时候，控制被转移到能处理这些事件的子系统。 系统的控制策略不在事件和消息处理器内部——子系统决定需要哪些事件，而消息处理器只管将事件发送给它们。

广播模型方法的好处 缺点 易于进化，新的处理特别类型事件的子系统可以通过注册来集成这些事件。 任何子系统可以在不知道其他子系统名字或位置的情况下激活其他子系统。 子系统能在分布式机器上实现。 缺点 子系统不知道是否和什么时候事件将会被处理。 当一个子系统产生一个事件，它不知道哪个子系统对该事件感兴趣。 不适用于实时系统。

中断驱动模型——事件处理基本原理 每个中断类型与一个内存地址相连，该内存地址存放的是与中断类型相应的事件处理器的地址。中断处理器对事件的响应是启动或终止其他的进程。 这个模型应该只用在硬实时系统中 。

作业 什么是体系结构设计? 一个应用程序的结构和风格，依赖于系统的哪些非功能性需求? 共享容器模型的优缺点. 客户机/服务器模型的主要组成部分.