用例行为和类的关系在线视频

同学们

今天我们讲面向对象分析与设计这门课程的第十五部分——用例分析（三）

在前面我们介绍了用例分析

我们讲了如何来识别分析类

我们重点介绍了边界类 实体类和控制类这三种分析类

那么下面我们将介绍如何将用例的行为分配给这些分析类

然后如何来识别分析类的职责

描述分析类的属性和关联关系

最后给每个分析类定义它的分析机制

如何来描述分析类的职责

我们在用例实现里边已经描述了我们识别出来的分析类

以及它们对象之间的如何相互协作的

我们是通过通信图或者时序图

在通信图或者时序图里边

我们定义了一个分析类的对象以及另外一个分析类的对象之间

它们会有这种消息交互

也就是说在这个例子里边

客户端这个对象会向供应者这个对象发送消息

那么接收到消息的对象

它就必须具有对这个消息进行处理的相应的一个职责

也就是说

我们的供应者的这个类需要有处理接收到的消息的职责

这样的话 我们就可以从通讯图

根据通讯图 对每一个接收到的消息

我们去定义这个类它所应该具备的职责

这是我们在教学管理系统里边

我们已经识别出来的分析类以及我们所定义的它相应的职责

你比如说

注册控制器他就具有一个获取课程列表的职责

在类的职责定义以后

对于每个类 我们识别定义完它的职责定义以后

我们要保证这些类的职责的一致性

如何来确保它的一致性

我们需要做以下这些检查

首先 我们来检查这个类是不是具有冗余的

或者多个类具有冗余的

或者说类似或者相同的职责

换句话讲 我们在软件设计里边

每一个类它的职责应该是不一样的

不应该两个类具有相同的职责

或者说一个职责分配给两个类

这种情况是不允许的

第二个是每一个类都是高内聚的

也就是说每个类可以有多个职责

但这些职责应该是紧密相关的

如果一个类的职责

它里边的职责之间是分散的或者说不是内聚的

那么这时候我们应该考虑把这个类拆分

还有第三种情况

某个类只有一个职责

如果一个类只有一个职责

这个类就会非常的简单

我们需要检查和确认是否必需要设计这个类

我们能不能把它的职责移交给或者分配给其它的类

从而把这个类删掉

还有一种情况是这个类没有职责

在软件设计里边

如果我们识别了一个分析类但最终没有给它分配职责

那么换句话讲 这个类的设计是存在问题的

最后我们还要看一下

有一些行为可能是分布式的

如果是这个职责 它需要在不同的节点上完成

那么这个职责有没有必要或者说需不需要把它设计到两个类里边

而不是把它放到同一个类里边去

还有一种情况是一个类和多个类之间进行交互

在这种情况下 这个类本身承担的职责就非常的多

那么这种情况下我们也需要考虑

我们需不需要把这个类进行拆分

也就是说 我们最终设计的类

每个类由有合适的数量的职责

而且这些职责应该是高内聚的

根据经验来讲

一个类有5到7个职责是最为合适的

在分配每个类的职责之后

下一步 我们要给每个类定义它的属性和关联关系

什么是属性

我们说属性定义了这个类需要存储 管理和维护的信息或者说数据

在分析阶段 我们通常并不花很长的时间去定义或者描述这个类的属性

我们一般 也就是说在分析类里边

只要去描述一些这个类需要去管理和维护的一些基本信息

我们把它定义为属性就可以了

我们如何来找到这些属性

我们需要对每一个我们所识别的分析类

首先找到它的特征

我们可以把它的每一个特征值定义为这个类的属性

第二个 我们需要根据这些分析类管理和维护的信息

它这些所有管理和维护的信息也可以考虑把它定义成这个类的属性

第三个是我们在名词过滤法里边

我们把一些属性

当时我们为了去识别实体类

我们把它过滤掉了

那么这些没有被定义为类的名词就可以考虑把它定义为一个属性

当然这些属性首先代表一个比较重要的实体

而且这些属性是当前唯一这个类的对象所拥有的

还有这些属性管理的信息它本身不应该拥有行为

如果有行为 它就应该被定义为一个类

而不是把它定义为别的类的属性

什么是关联关系

前边我们介绍到

关联关系是两个类之间一个结构的稳定的持久的结构化的语义关系

比如说 关联关系是比较持久的

那么在建立关联关系以后

我们就可以从一个类的对象导航到另外一个类的对象

如何来找到关联关系

我们同样要从前边用例实现我们定义的时序图或者通信图之间来找

在通信图里边 我们描述了两个类的对象之间它们消息的交互

如果两个类的对象之间存在消息交互

那么我们可以识别和定义这两个类之间具有关联关系

因为只有关联关系

前面这个类的对象才能找到另一个类的对象

它才能够把消息发送给另外一个类的对象

当然 我们除了普通的关联关系以外还有一种特殊的关联关系

我们把它称之为聚集关系

聚集关系实际上是描述了一种整体和部分之间的关系

前边这个菱形箭头的前边是表示的是整体

后边这个表示的部分

所以说 我们可以说聚集关系是一种特殊的关联关系

在什么情况下 我们把两个类之间的关系定义为普通的关联关系

什么情况下 我们把两个类之间的关系定义为特殊聚集关系、

那么我们来看一下下边的这个例子

在这个例子里边

我们有两个类

一个是车 一个是门

在不同的场景下 这两个类之间的关系是不一样的

假如说我们是在一个汽车的4s销售店

我们在一个汽车的销售店

我们在卖车的时候

我们是把车和门一起卖给客户的

那么在这种情况下 这个门是车的一部分

所以 车和门之间的关系是一种聚集关系

反之 我们在一个汽车维修厂

我们这个门是一个配件

在这个维修厂 门可以换或者安装给任何一个汽车

所以个在这个维修厂里边

车和门不再是一个整体和部分的关系

只是一种普通的关联关系

在关联关系里边我们还要识别角色

一旦两个类建立关联关系以后

一个类的对象就会扮演另一个类的对象的一个角色

我们也知道在生活中 我们每个人都扮演着不同的角色

今天在这里 我扮演的角色是老师

回到家中 面对着我的孩子

我的角色是一个父亲

那么同样的 一个类的对象在它的关联关系里边

它也有它所对应的角色

你比如说 我们在这张图中

对于一门课程来讲

这个教师的对象所扮演的就是这门课的主讲老师

这样一个角色

同样是老师

他在另外一个关系

在系之间 他扮演的角色可能就是一个系主任

除了角色以外

下面我们还要回顾以一下多重性

所谓多重性

就描述了一个类的对象可以关联多少个另外一个类的对象

比如在我们的这个例子里边

我们说开设的课程

每一门开设的课程它必须关联一门课程

但是反过来说 一门课程可以被开设多次

比如说 我们的面向对象分析与设计这门课程

我们每学年开设一次

所以说面向对象分析与设计这门课

是2019年开设一次 2018年开设一次 2017年开设一次

它就被关联了多次

当然了一门课程可能还从没有开设过

那么它就关联零次

所以多重性就描述了一个类的对象关联了若干个或者多少个另外的对象

在下面 我们要介绍一个特殊的关联——多重关联

多重关联是描述两个对象之间具有一个及以上的关联关系

比如我们的这个例子

在这个例子里边

我们前边是课程计划 后边是开设的课程

我们可以看到有一些课程在我们的课程计划里边是必修课

而另外一些课程在我们的课程计划中扮演的角色是选修课

也就是说在课程计划里边

它所关联的多个开设的课程对象里边

这些开设的课程的对象在我们的课程计划里边扮演的角色是不一样的

在这种情况下 我们需要定义为多重关联

但是下面这个例子就是错误的

如果说它只是说

两个对象之间 它会有多个消息交互

虽然说它有多个消息交互

但是后面这个对象在前面这个对象里边扮演的角色是一样的

或者说是同一个角色

那么它还是普通的关联关系而不是多重关联关系

也就是说 换一句话讲

如果是多重关联关系

那么某一个对象在关联关系里边

它所扮演的角色是不同的

我们才可以定义它为多重关联关系

这是我们在教学管理系统里边我们所识别出的类

以及它们之间的关联关系以及它们的多重性等等

在识别完分析类 定义完分析类之间的关系以后

下一步 就是要给每个分析类定义确定它的分析机制

我们在前面已经介绍 什么是分析机制

就是把关于软件实现的一些复杂的问题

我们在软件分析阶段 我们不想考虑

或者说我们不想投入过多的精力

我们只需要这些复杂问题标识出来 定义出来

等到后边详细设计阶段 再给出这些问题的具体解决方法和解决方案

对于分析机制来讲 我们把类定义完以后

我们首先要把相关的分析机制列一个表

然后对每一个分析类

我们要确定和它相关联的或者说

它可能需要到的相应的分析机制

最后我们要定义每一种分析机制的特征值

这些特征值也是后面

我们对这种分析机制进行实现的需要考虑的主要的一些参数

或者说影响因素

这是我们在教学管理系统中给的一个例子

我们在前边识别的分析类有学生 课程计划 开设课程等等

至于后边列出了每一个类所对关的分析机制

比如说学生他有持久性和安全性两个分析机制

接着我们对每个分析机制

每个关联的分析机制给出了它的特征参数

比如说对持久性来讲

我们可能需要对每个产品大概最多有一万个的持久性对象

另外它的访问频率

每天需要创建500个

每小时需要读2000个等等

在用例分析

我们用例分析的过程不是一次完成的

而是迭代完成的

在用例分析过程中

第一次我们可能分析某个用例

第二次我们分析另外一个用例

甚至在迭代过程中

我们如果这个用例太复杂 我们只是分析了这个用例里边的若干个场景

这样的话 在当前这次用例分析完成以后

我们需要把我们所识别出来的分析类和我们之前的分析模型要进行合并

我们需要把我们所识别出来的分析类和我们之前的分析模型要进行合并

也就是说我们要把我们新定义的一些分析类补充进去

还有一些情况 可能是之前我们已经识别出来的一些分析类

我们在这个新的用例里边 我们又识别又定义了分析类

而且我们给它增加了新的属性或者新的操作或者新的职责

那么同样的 我们需要对它进行一个合并

最终构成一个合并后的统一的一个分析模型

在用例分析完成以后 我们还需要评估我们分析的结果

我们要看我们所分析设计的用例分析模型

我们的时序图 通信图是不是能够完成

或者说实现了我们用例里边所描述的系统行为

好了 同学们

今天我们的内容就主要介绍了如何来识别每个分析类的属性

定义分析类之间的关联关系

在什么情况下把它定义成关联

什么情况下把它定义成聚集

最后定义了分析类之间的导航性 多样性

以及讲描述整个用例分析过程是迭代的

所以最后要对用例分析的结果进行合并

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