子系统设计概述在线视频

同学们 今天我们讲面向对象分析与设计这门课的第21讲

子系统设计

在子系统设计这一节里面 我们首先介绍子系统设计的目的

以及在RUP的软件声明周期过程中什么时候执行它

接着我们讲子系统的行为规约是如何由它的内部所包含的设计类实现的

第三部分 我们介绍如何来描述子系统的内部结构以及如何来确定子系统和他的外部其他元素之间的依赖关系

在RUP的软件生命周期过程中子系统的设计是由在组件设计阶段由设计师来完成的

在子系统设计的时候 同样遵循整个项目的项目规约

它的主要输入是识别元素设计里我们所识别和定义的子系统以及它的接口

它的输出则是子系统内部所包含的设计类以及由这些子设计类之间的关系所组成的设计模型

我们知道在系统中引入子系统的主要目的是为了使整个系统的设计具有这样一些特性

第一个是松耦合 在子系统中我们把它内部是完全封装的 对外只暴露接口

子系统和外部的其他子系统之间是通过接口连接在一起的

这样两个子系统之间通过接口就可以实现它们之间的松耦合

也就是说只要一个子系统的请求接口和另外一个子系统的提供接口相匹配 这两个子系统就可以连接在一起进行工作

同样的 实现了相同接口的两个子系统之间只要它们实现的接口相同

它们就可以相互替换 从而能够使得整个系统具有插拔性和可移植性以及兼容性

在接口不变的情况下 我把子系统内部进行修改 只要接口不变这种变更内部的变化就不会扩散影响到外部的其他元素

也因此每个子系统都可以独立的演化

当然前提条件是子系统所实现的接口不变

所以在子系统设计中我们强烈要求在设计的时候 对子系统内部元素 内部设计细节封装起来 不能暴露

对外子系统只能暴露接口 两个子系统之间依赖或交互只能通过接口进行 而不推荐或者说不允许子系统之间直接进行依赖

子系统设计主要分为这些步骤

首先把子系统行为分配给它的内部元素

然后要建模和描述它的内部元素 要建模和描述它对外部元素的依赖关系

最后检查子系统设计

我们首先介绍如何把子系统的行为分配给它的内部元素

子系统的职责定义在子系统所实现的接口操作里面

我们前面讲每个子系统都需要实现接口 至少实现一个也可能是多个

在每个接口里定义了至少一个或多个操作 这些子系统所实现的接口和接口操作就构成了子系统对外应该提供的服务 也就是子系统的职责

而子系统定义在接口操作里面的职责 可以由子系统内部某个类来完成

我们把它称之为内部类行为

也可以由子系统内部的多个类的对象相互协作完成 我们把它称之为子系统行为

这里我们举个例子

比如说把一个班级看成一个子系统

我们在接口里面定义了一个职责 打扫教室卫生

如果这个职责是由这个班级里面某个同学 比如班长一个人来完成 那么这个职责就可以称为内部类行为

如果打扫教室卫生这个行为是由班级里很多同学相互配合一起完成的 那么这个职责行为就是子系统行为

在把子系统行为分配给内部元素的时候主要有这么几项工作 首先要找出实现这个子系统职责所需要的设计元素 当然 就是设计类

这些设计类有可能是复用已有的

也就是说在前面识别设计元素里 我们所识别出的设计类

或者说有些其他的子系统设计的时候所定义的设计类

都可以用来做新的子系统设计时的复用

那么除了复用以外可能还不够 我们可能还需要定义一些新的设计类

实现子系统相关的设计类定义完成以后 第二步我们就需要把子系统的职责分配给所识别和定义的这些设计类

第三步 我们要对子系统内部的设计类映射他们所关联的分析机制

并且给出每种分析机制具体如何实现的

接着我们需要进行文档化 就是说把设计类以及这些设计类对象之间通过交互图的方式来描述子系统的职责是如何来实现的

一般情况下对子系统所实现的接口里面的每一个操作我们需要给出一个交互图 如果这个操作很复杂也可能会给出多个交互图

除了交互图以外 我们还要用类图的方式来建模 子系统内部的所有的设计类之间的关系 给出子系统的设计模型

在子系统设计完成以后我们还要检查

有可能在子系统设计完成以后我们对子系统或子系统接口进行修改

在讲子系统职责分配之前 我们先介绍一个概念 这个概念称之为门

门是一个连接点 它用于在时序图里面描述其边界接收或者发出的消息

例如在这个图里面 我们可以看到在时序图的边界 这两个位置是门

它分别表示了从这个门接收外部发布给子系统的消息 这边是子系统发出的消息

每个门都有它的名称 门的名称和门所接收发送的消息名是一样的

在识别设计元素的时候 我们把整个系统行为用交互图的方式描述

这里我们把子系统看成一个黑盒子 是定义了子系统从外部元素之间所接收到的消息以及子系统对外所发送的消息

而把子系统的内部结构包起来作为一个黑匣子来显示

那么到了子系统设计阶段 我们就需要给出这个子系统内部如何实现

比如说子系统内部他还包括哪些设计类以及它们之间的关系

通常情况下 在子系统内部设计的时候 会设计一个子系统管理者这样一个内部类

用来控制协调其他的设计元素 共同来实现子系统的职责 也就是通过子系统接口所接收到的消息

这样的话我们所描述的时序图 从门接收到的外部的消息

当然这个消息是需要定义在子系统所实现的接口操作里

那么这个消息到达以后首先到达管理者

然后由管理者向其他的内部的设计元素 发送相应的消息来控制协调其他的设计元素 共同协作来完成子系统的职责

也就是通过这样的时序图 我们把子系统的职责分配给内部的各个设计元素

这个时序图就是从白盒角度具体描述了子系统内部的设计元素之间的通信交互过程

也就是通过这样一个通信交互过程 实现了子系统从门所接收到的外部消息的处理 实现了子系统在接口里所定义的操作和职责

在识别完设计元素后 我们同样需要把子系统内部的这些设计元素 即设计类 建立和它所对应的分析机制之间的映射关系

给每一个设计类可能相关的映射到的分析机制

我们还需要给出这些分析机制的具体的实现方法

比如说以课程为例 它的分析机制是持久化 那么持久化我们可能选用的是关系型数据库

那么关系型数据库的具体实现可能就采用JDBC 一个数据库访问的包来实现它

把设计元素识别出来以后 职责分配完以后

我们需要用文档来描述和建模子系统的内部设计 对于子系统的内部设计就是采用前面讲的第一个通过交互图、时序图

来描述子系统的接口操作是如何有内部元素交互实现的

第二个是通过类图来描述子系统内部的这些设计类直接的相互关系

接着我们需要把子系统的 和外部元素之间描述和建模依赖关系

这里就举两个例子 第一个例子我们所识别的子系统是课程目录子系统

课程目录子系统首先要依赖于外部系统接口 这样一个包

因为这样一个包定义了这个子系统所需要实现的接口

另外在课程目录子系统里面 需要对对象进行持久化 所以需要用到持久化相关的包 也就是java.sql

所以它和java.sql之间建立了依赖关系

在课程目录子系统里面会用到课程、学生这样一些类的对象

而课程和学生这些类定义在大学这个包里 所以它同样和大学这个包之间具有依赖关系

第二个例子 是计费系统

同样计费系统和计费系统所包含计费系统的外部系统接口这个包之间有依赖关系

另外在计费系统里 也会用到学生 学生这个类定义在大学这个包里

所以它和大学这个包也要有依赖关系

同学们

今天我们就介绍了一下子系统的设计我们讲了一下如何通过门来描述子系统对外所接收的消息

实际上这些消息也是定义在子系统所实现的接口操作里面

然后介绍了一下如何通过描述子系统内部的这些设计类

他们通过交互图的方式相互协作 共同实现子系统所对应的职责 对从门接收到的消息进行处理

最后通过类图来描述子系统相关的这些设计类之间的关系

然后我们要定义子系统和他外部的其他的这些包和元素之间的依赖关系

同学们 我们今天的可就讲到这里 谢谢大家