UML第12章 控制驱动部分的设计

《UML第12章 控制驱动部分的设计》由会员分享，可在线阅读，更多相关《UML第12章 控制驱动部分的设计（62页珍藏版）》请在金锄头文库上搜索。

1、第12章 控制驱动部分的设计 12.1 什么是控制驱动部分 12.2 相关技术问题 12.3 如何设计控制驱动部分 控制驱动部分是OOD模型的一个外围组成部分。 该部分由系统中全部主动类构成。这些主动类 描述了整个系统中所有主动对象，每个主动对 象是系统中一个控制流动驱动者。 12.1 什么是控制驱动部分 控制流（control flow）是一个在处理机上顺 序执行的动作序列。在目前的实现技术中，一 个控制流就是一个进程或者一个线程，在UML的 文献中称之为控制流。 在OOD中，把系统中所有的主动对象表示清楚， 就抓住了系统中每个控制流的源头，就可以把 并发执行的所有的控制流梳理出清晰的脉络，

2、 所有的主动对象都用主动类描述，所有的主动 类构成OOD模型的控制驱动部分。 12.2 相关技术问题 本节将从系统总体方案、软件体系结构、分布 式系统的体系结构风格以及系统的并发性这几 方面探讨控制驱动部分的设计中的技术问题 。12.2.1 系统总体方案 要开发一个较大的计算机应用系统，首先要制 定一个系统总体方案。系统总体方案的内容包 括：（1）项目的背景、目标与意义。（2）系统的应用范围。（3）对需求的简要描述，采用的主要技术。（4）使用的硬件设备、网络设施和商品软件。 （5）选择的软件体结构风格。（6）规划中的网络拓扑结构。（7）子系统划分。（8）系统分布方案。（9）经费预算、工期估计、

3、风险分析。（10）售后服务措施，对用户的培训计划。 对于OOD模型中控制驱动部分的设计而言，总体 方案中所决定的下述问题是它的基本实现条件 ：（1）计算机硬件。（2）操作系统。 （3）软件体系结构。（4）网络方案。（5）编程语言。（6）其他商品软件。12.2.2 软件体系结构 软件体系结构是对系统的组成与组织结构较为 宏观的描述，它按照功能部件和部件之间的联 系与约束来定义系统，着重于软件系统自身的 整体结构和部件间的交互。 部件和连接器被公认为体系结构的两大类构成 部分。部件是软件系统的组成单元，在系统框 架中起结构块的作用，是软件功能设计和实现 的承载体。连接器是建立部件和部件之间连接 的

4、部件。 以下是几种典型的软件体系结构风格：（1）管道与过滤器风格（2）客户-服务器风格 （3）面向对象风格（4）隐式调用风格（5）仓库风格（6）进程控制风格（7）解释器模型（8）黑板风格（9）层次风格（10）数据抽象风格12.2.3 分布式系统的体系结构风格 主机+仿真终端体系结构。以一台计算机为主机 ，其他计算机只作为它的远程仿真终端。从应 用系统的角度看，其软件体系结构和集中式的 系统没有本质性差别，因为其功能和数据都集 中在主机上，其他计算机只相当于一些终端设 备而已。 文件共享体系结构。在这种体系结构中，系统 功能分布到网络的各个节点上，数据存放在一 个被称作文件服务器的主机上。在某些

5、系统中 也可以把数据分布到各个节点上。 客户-服务器体系结构。这种体系结构把分布在 不同节点上的系统组成部分之间的关系处理为 请求服务和提供服务的关系，提供服务的计算 机称作服务器，请求服务的计算机称作客户机 。客户-服务器体系结构衍出生了一些特点各异 的变种： （1）两层客户-服务器体系结构这是早期最典型的客户-服务器体系结构。其 特点是明显地区分客户机和服务器，把提供给 多个节点共享的公共服务集中在一台服务器上 ，客户机则只配备与本地业务处理有关的功能 和数据。客户机和服务器构成两个界限分明的 层次，这就是两层客户-服务器结构。（2）对等式客户-服务器体系结构这种体系结构观点把客户机和服务

6、器看成是相 对的。根据实际需要，系统中的每一台计算机 既可以作为客户机，又可以作为服务器，即每 一台计算机既可以请求其他节点提供服务，又 可以向其他节点提供服务。实际上，这是一种 更具一般性的客户-服务器体系结构形式，其他 形式都可以看作这种形式的受限的特例。（3）三层客户-服务器体系结构这种体系结构是在两层客户-服务器体系结构 基础上改进和发展的结果。其中包括数据服务 器、应用服务器和客户机三个层次。数据服务 器存储和管理被整个系统共享的数据，提供对 这些数据进行查询、更新、一致性维护等操作 的服务。 （4）瘦客户-服务器体系结构这种体系结构的思想是把分布到客户机上的功 能尽可能减少。其目的

7、是使客户机上软件的安 装、维护和升级变得很容易。在一个分布区域 较广的大型系统中，末端的客户机数量最多， 分布范围也最广，往往延伸到维护力量薄弱的 边远地区。 （5）浏览器-服务器体系结构瘦客户-服务器的思想发展到极端，应用系统分 布到客户机上的软件成分就只剩下了一个浏览 器。用户在浏览器上进行人机交互操作，浏览 器把用户命令转换为对服务器的请求，并把得 到的处理结果向用户显示。 12.2.4 系统的并发性 在本小节关于并发系统的讨论中将使用“任务 ”、“进程”、“线程”、“控制流”、“主 动对象”等一系列含义相近的术语。按以下的 约定来使用这些术语：（1）在OOA和OOD中用主动对象的一个主

8、动服务 来描述一个任务，用主动类来描述一类主动对 象。（2）在从用户需求的角度或者在较高的抽象层 次上讨论和认识系统的并发性时，使用任务的 概念，以明确系统中客观上要求有哪些任务并 发执行。（3）从逻辑上看问题，忽略实现细节，可以说 OOD模型中的一个主动对象的主动服务描述了一 个控制流。 （4）在实现阶段，主动对象、主动类的概念仍 然存在，但是已被实现为程序代码中的对象和 类，它们的每个主动服务将被具体地实现为进 程或者线程。（5）把“任务”和“控制流”作为讨论问题、 解释概念或陈述设计策略时使用的词汇，而把 “主动对象”、“主动类”、“进程”作为模 型或程序中的元素或技术术语。 顺序程序和

9、并发程序： （1）顺序程序中只有一件事在进行处理，即使 程序中包括多项工作，也不会在一个时间段同 时做两项（或以上）工作。程序中可以有分支 、循环、子程序调用等各种复杂情况，但是一 切都按确定的逻辑进行。 （2）如果说系统要在同一段时间内执行多个任 务，而这些任务之间又没有确定的时间关系， 这种系统就是并发系统。描述并发系统的程序 叫做并发程序。并发程序要执行的多个任务在 时间上没有确定的逻辑关系，但是又相互影响 。 进程和线程：（1）进程是W.Dijkstra、C. A .R .Hoare和 P.B.Hansen等人在20世纪60年代中期以后的一 系列文章中提出并逐渐完善的，它的全称是顺 序

10、进程。采用进程的基本思想是：把一个并发 程序分解成若干能够顺序执行的程序单位。每 一个这样的程序单位的一次执行就叫做一个顺 序进程。 （2）线程在进程之后出现，它可以看作是并发 程序设计技术的进一步发展，然而更重要的原 因是由于并行计算技术的需要。进程既是处理 机资源的分配单位又是其他资源的分配单位； 而线程只是处理机资源的分配单位。一个进程 可以包含一个或者多个线程。 （3）从应用的角度看，进程的概念适合于解决 系统固有的并发性问题。（4）从编程技术来看，线程概念的出现还有更 重要的逻辑上的理由，那就是：一个进程的数 据空间被该进程内的多个线程共享，使这些线 程可以方便地交换信息。 当前应用

11、系统的并发性。有些程序员虽然已经 成功地开发出许多并发的应用系统，但是他们 并没有觉察到自己曾经面对并发程序设计的挑 战性问题。他们觉得，自己编写的程序和一个 顺序程序没有什么两样。原因在于当前的开发 环境和运行环境无形中已经帮助，甚至代替这 些程序员解决了系统的并发问题。 12.3 如何设计控制驱动部分 设计OOD模型中控制驱动部分的关键，是识别系 统中所有并发执行的任务，然后用主动对象来 表示这些任务。 12.3.1 选择软件体系结构风格 分布式系统的设计中，除了采用面向对象风格 以外，还需要在其他几种体系结构中做出选择 。主要的选择是客户-服务器体系结构的几个变 种，选择这些体系结构风格

12、所考虑的因素包括 ：（1）被开发系统的特点。（2）网络协议。（3）可用的软件产品。（4）成本及其他，包括购置相应硬件及软件的 成本、新开发软件的成本、系统的安装与维护 成本。 12.3.2 确定系统分布方案 随着软件体系结构风格的选择，系统中的每个 节点采用何种计算机以及它们之间如何连接也 都将逐一明确。被开发的软件将分布到这些节 点上。面对一个分散的计算环境，要考虑如何 把对象分布到通过网络相连的各台计算机上。 本小节围绕这一目标，讨论对象的分布、类的 分布以及如何在模型中表示这种分布方案。 对象的分布。这里首先针对一般情况讨论对象 分布策略：1）由数据决定对象分布，这又包括以下几点： （1

13、）当应用系统中一个类的对象实例需要在文 件或关系数据库中存储时，则定义与这个类的 数据结构一致的文件或数据库表。（2）该类的每个对象实例用文件的一个 记录或者用数据库的一个元组保存。当一 个类有大量的对象实例时，通常只把当前 正在被处理的对象读到内存，所以一般只 需要为该类定义少量的内存空间的对象。（3）需要设计一个名为“对象存取器”的对象 类，其功能是负责把内存中的对象实例保存到 文件或数据库表中以及把文件或数据库表中的 对象数据恢复成内存中的一个对象。2）由功能决定对象分布3）追踪消息 4）Use Case 类的分布。关于类的分布，具体做法如下：（1）如果整个系统只需要在一个节点上创建某

14、个类的对象实例，那么这个类就分布在这个节 点上。（2）如果系统需要在多个节点上创建同一个类 的对象实例，那么这个类主要分布在每个需要 它的节点上。可以把其中一个节点上的这个类 作为正本，而把其他节点上出现的这个类表示 为副本。作为副本的类可以采用如图12-1所示 的表示法。图12-1 类图的划分。为了表明对象和类在各个节点上 的分布情况，需要在类图上采取相应的组织措 施，把描述整个系统的集中式的类图分散到各 个节点上，以分别描述分布在各个节点上的对 象；最后要把每个节点上的类组织成一个主题 。具体策略有以下两种： （1）把每个节点的主题看成是在整个系统的类 图上划分出来的一个局部。 （2）把每

15、个节点上的主题看成一个独立的子系 统，用一个定义完整的类图表示。 在类描述模板中的表示。下面给出类描述模板 的描述格式：对象实例：处理机：，;内存对象：n元数组;外存对象：;12.3.3 识别控制流 以节点为单位识别控制流。以每个节点为单位 考虑在每个节点上运行的程序还需要如何并发 ，需要设计哪些控制流以及各个节点之间如何 相互通信。以节点为单位识别控制流是本小节 讨论的前提。 从用户需求出发认识控制流。现在需要考虑的 是，每一个节点上的功能，还有哪些任务必须 在同一台计算机上并发地执行。 从Use Case认识控制流。在以下情况下应考虑 针对一个Use Case设计相应的控制线程：（1）用户

16、希望一个Use Case所描述的功能在必 要时能够与系统的其他功能同时进行处理。（2）一个Use Case所描述的功能是对系统中随 机发生的异常事件（例如某一种中断信号）进 行异常处理的。（3）对一个Use Case所描述的功能，用户可以 在未经系统提示的情况下随时要求执行，这样 的Use Case一般应由一个专门的控制流去处理 。 为改善性能而增设的控制流。除了满足系统固 有的并发要求之外，为了改善性能，可能需要 增设执行以下几类任务的控制流： （1）低优先级任务（2）高优先级任务（3）紧急任务 参照OOA模型中的主动对象。主动对象的一个主 动服务，是在创建之后不必接收其他对象的消 息就可以主动执行的服务，从系统运行的角度 看，这意味着主动对象的一个主动服务是一个 控制流的源头，在OOD中，通过考察OOA模型中 的主动对象可帮助确定这些控制流。 实现并行计算的控制流。如果被开发的系统包 含并行计算