识别设计元素概述在线视频

同学们 今天我们介绍面向对象设计与分析这门课程的第十六讲——识别设计类

在识别设计类里边

我们需要从分析模型里边找到对应的设计元素

我们主要的设计元素有设计类 子系统和子系统的接口

识别设计元素由架构师在体系架构精化这个阶段进行完成

在体系架构精化的时候

我们首先要从之前我们在用例分析里边

我们从中识别出来的分析类中对应找到

我们设计阶段所需要的具体的各种元素

也就是我们刚才讲到的设计类 子系统和接口

所以识别设计元素这样一种活动

它的主要输入

第一个有分析模型 有附加规格说明书 软件体系架构

最终 我们把这些分析模型通过识别设计元素以后转换为一个对应的设计模型

设计识别设计元素的主要步骤

首先要识别类和子系统

接着我们要识别和定义子系统的接口

然后我们把类和子系统之间的关系组织到一起形成新的设计模型

最后检查我们设计的正确性

首先我们介绍第一部分 识别类和子系统

我们在前边我们讲在用例分析的时候

我们定义了分析模型 里边就是分析类

我们说分析类有边界类 实体类和控制类

那么这些边界类 实体类和控制类在识别设计元素这一环节

我们把它对应转化为设计元素 也就是我们的设计类、子系统

当然了 我们也把一些设计类打包或者组织到一起

这就是我们的包

那么在这些分析类和设计元素的映射关系是什么

我们从这张图上可以看到

它不是一个简单的一对一关系

它可能是复杂的多对多的关系

也就是说 有一些分析类 它可能转化为一个包也可能是多个设计类

甚至可能转化为一个子系统

当然 也有一些分析类 可能在设计阶段

我们发现它可能不需要

可以把它的职责分配给或者说合并给同一个子系统里边或者同一个设计类里边

那么如何来识别分析类

第一种情况 如果这个分析类比较简单

比如说它只是描述了单个的逻辑概念

在这里 我们可以把这个分析类直接识别或对应为一个设计类

比如说我们多数实体类

每个实体类它描述了一个单一的概念

那么在设计阶段 这些实体类就可以同样的识别成一个设计类

对于一些复杂的分析类

它的识别就比较困难

比如说我们有一些控制类

它的控制逻辑很复杂

我们在分析阶段定义它为一个控制类

但是到了设计阶段 我们可能把它的控制逻辑拆分了

那么在设计阶段 我们可能定义多个设计类

另外 一些边界类 比如说用户接口的边界类

在分析阶段我们只定义了一个分析类

但到了设计阶段 我们要设计用户接口的细节

也就是UI的细节

所以这时候一个分析类转化为多个设计类

我们把这些设计类打包

也就是说吧这个分析类转化为一个包

那么还有一些 比如说设备边界类 系统边界类

因为它涉及到与外边的软件系统或者硬件的一些协议

我们需要把它识别成一个子系统

甚至可能是上边的一些情况的一些组合

我们刚才讲 我们在识别设计元素时

有可能把识别到的设计元素组成一个包

那么什么是包 我们回顾一下

在UML里边或者在面向对象里边

包是一种分组机制

也就是说可以通过包可以把一些对象或者面向对象元素进行组织和管理

比如说或者说常用的我们可以把一些相关的类放在同一个包里边去

用包作为容器来管理它们

当然包本身还可以进行嵌套

那么我们如何把一些相关的类进行分组对它进行打包

我们主要考虑这样一些因素

第一个我们为什么要进行分组

我们在管理配置里边

我们是以包为单位进行软件的配置管理的

第二个我们也可以以包作为一个单位分配开发组

我们知道一些复杂软件项目可能同时有多个软件开发团队或者开发项目组

同时进行开发

所以我们以包为单位给这些开发组来分配任务

第三个我们这个软件系统

我们一个软件系统可能有多个不同角色的用户

比如说我们的教学管理系统里边

我们的老师是管理系统的用户学生是教务管理人员也是

那么把针对不同角色或者不同用户之间的

实现这些不同角色不同功能的这些类

我们就可以可以把它门放在不同的包里去

另外在软件设计过程中

我们尽量的想复用我们已有的一些组件

已有的一些中间件或者开源的、或者第三方、或者原有系统

那么我们希望把我们已有的这些组件在设计阶段封装成一个包

另外我们的系统可能需要使用的或者请求的其它一些服务

也可以把它以包的形式进行组织和管理 进行表示

在这个例子里边 我们来看一下

在这个例子里边我们可以看到左边的分包形式和右边的不一样

在左边的里边 我们下边的里边的每一个包

我们是把同一个用例里边的实体类和控制类放在一个包里边

然后我们把所有的边界类放在最上边

在这边呢 我们可以看到

我们把每个用例的实体类、边界类和控制类放在一个包里边

我们可以看在在左边是三个包 到这边就变成两个包

这两种分包的方式 哪种好呢

这不是绝对的 这需要看它的场景

在第一种情况下 如果说我们系统的整个界面或者说它的边界

有可能会变化

那么在这种情况下 我们把所有的边界类放在一个包里边是一种好的设计

这样的话 对边界或界面设计的变更

它只会影响到上边的 也就是存放我们边界类的包

另外两个包里的程序或者说另外两个里的类是不会受到影响的

反之 如果我们的用户界面不会变化或者说很小的变化

那我们按照用例把它分在两个包里边

它的好处是我们可以针对

我们在发布这个系统功能的时候

我们需要发布哪个用例的功能

我们就把这个包里边的类发布出去就可以了

在分组的时候 我们打包的原则

我们基本的原则就是把功能相关的类打在同一个包里边去

那么问题来了

我们如何来判断两个类或者多个类之间是功能相关的

我们有下边一些基本的方法

第一个 如果我们对一个类它的结构或者它的行为做了变更

如果它会影响到另外一个类

那么说明在这两个类之间有着比较紧密的功能耦合关系

它们就应该打包在一起

第二个呢 如果我们把一个类删除了

它会影响到另外一个类

换句话讲 另外一个类离不开这个被删除的类

那么这两个类也应该被打包在同一个包里边去

第三种情况 如果两个类之间有非常多的或者大量的消息交互

比如说 这两个类之间有紧密的功能协作

这两个类的关系紧耦合也应该放在同一个包里边去

还有一些情况 如果说一个边界类就是把实体类的数据提交或者展示给用户

那么这种情况下

我们也可以把这个边界类和它所需要操作使用的数据类打包在一起

最后如果两个类和同一个角色相关

那么这两个类也可以考虑把它打包在一起

还有一些情况下

如果两个类彼此之间有比较紧密的关系

那么这两个类应该打包

还有的情况下 一个类可能需要去创建另外一个类的对象或者实例

那么这两个类也应该考虑把它打包在同一个包

还有一些情况 我们可以明确确定两个类不应该放在一起 不应该打包在一起

第一种情况 如果这两个类所实现的功能和参与的用例是和不同的角色相关的

那么这两个类就不应该把它放在同一个包里去

还有一些情况下 有些类它是实现整个系统的基本功能或者强制功能的

而另外一些类是实现可选功能的

那么这两种类也不应该把它放在同一个包里边去

我们知道有一些系统它有一些基本功能和高级功能

可以用户在安装时自己去选

那么实现基本功能的我们叫它强制类

实现可选功能的我们就说可选类

这两种类就不应该打包在一起

应该放在不同的包里边 方便部署

那么在打包完以后 我们还要建立包与包之间的依赖关系

我们讲依赖关系是一种存在关系

也就是说A包依赖B包

只要A包里任意一个类依赖B包的一个类

那么我们说A包是一定依赖B包的

但是我们要强调的是包的封装性并不是很好

包把它里边所有具有的需要公共操作的类都暴露出去了

包之间就只有一种关系 就是依赖关系

两个包之间不应该是交叉耦合的

换句话来讲 两个包之间不应该存在循环依赖

比如说 这个图我们看到的A、B两个包具有相互依赖关系

另外的话 在层次化的软件分析过程中

包之间的依赖关系只能是上层依赖下层

不允许下层依赖上层

在一些严格的层次化的软件分析里边

包之间的关系只能是逐层依赖

也就是说只能依赖它相邻的下一层 不能跨层依赖

这是我们课程系统里边 我们所识别出来的类以及类之间的关系

我们把这些类打包在一起 叫注册包

这是另外一个 这是我们教学系统里边我们识别的公共的一些实体类

像学生 全职学生 半工半读学生

我们把这些类打包成一个包 我们叫基本包

这是我们记分系统 它里边它把它的记分系统和它的接口

这两个也可以把它打包在一起

在我们识别完这些类以及对类分包以后

当然也包括我们识别出来的子系统

我们要检查我们所识别的每个类

它的名字是不是反映了它角色

然后这些类的内部应该是高内聚的

类与类之间应该是松耦合的

而且我们所识别出来的这些类应该是用例实现里边所需要的等等

只有这些检查都正确了

我们所识别的这些类才是正确的

好了 同学们 今天我们就介绍了一下识别设计元素

我们说主要的识别设计元素是类 子系统和接口

然后我们在识别完这些类以后 我们需要建立包来对这个类进行分组

我们介绍了一下包进行分组的一些基本原则

好 我们今天的课就介绍到这里 谢谢大家