UML用例图、类图

Posted 2023-05-11

参考技术A

首先需要先了解一下对象之间的关系，以及它们对应的符号

通常对象之间的关系可以分为以下几类：

1、泛化/继承（Generalization）：实线+三角形空心
相当于类继承，父参与者可以是抽象的，即不能创建一个父参与者的直接实例，这就要求属于抽象父参与者的外部对象一定能够属于其子参与者之一。

2、关联关系（association） ：实线箭头
关联关系：指的是类与类之间的联接，它使一个类知道另一个类的属性和方法（实例变量体现）。A类依赖于B对象,并且把B作为A的一个成员变量, 则A和B存在关联关系.
关联可以是双向的，也可以是单向的。两个类之前是一个层次的，不存在部分跟整体之间的关系。
单向：只能从A通过属性导航到B，B不能导航到A。
双向：A可以通过属性导航到B，B也可以通过属性导航到（双向即为嵌套）

3、聚合关系（aggregtion）棱形空心+实线
聚合(aggregation)关系是关联关系的一种,是强关联关系,是整合和部分的关系,是has-a的关系.
聚合关系也是通过成员对象来实现,其中成员对象是整体对象的一部分,但是成员对象可以脱离整体对象单独存在.(可替换)

4、依赖(Dependency) 虚线+箭头
依赖关系：指的是类与类之间的联接。依赖关系表示一个类依赖于另一个类的定义。
动物依赖氧气和水。调用新陈代谢方法需要氧气类与水类的实例作为参数

5、实现关系（realization）虚线三角形空心
实现关系：指的是一个class类实现 interface接口（可以实现多个接口）的功能；实现是类与接口之间最常见的关系；
在Java中此关系通过关键字implements明确标识。

6，组合关系（composition）
组合是一种强的‘拥有’关系，是一种contains-a的关系，体现了严格的部分和整体关系，部分和整体的生命周期一样。
示例：
鸟和翅膀就是组合关系，因为它们是部分和整体的关系，并且翅膀和鸟的生命周期是相同的。

一张完整的类图：

参考： UML用例图 ， UML类图 ， UML中的类图及常见类图关系

UML建模（一）---UserCase用例图

参考技术A

用例图源于Jacobson的OOSE方法，用例图是需求分析的产物，描述了==系统的参与者与系统进行交互的功能，是参与者所能观察和使用到的系统功能的模型图==。它的主要目的就是帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本流程的“角色”关系以及系统各个功能之间的关系。它通过用例（Use Case）来捕获系统的需求，再结合参与者（Actor）进行系统功能需求的分析和设计。

用例图有四部分组成： 用例（Use Case）、参与者（Actor）、系统边界、关联

在一个系统开发前，我们必定首先要确定系统的用户，系统的用户就是系统的参与者。除此以外，我们还会想打，我们开发的系统与其他的系统有什么关联？因此，系统的参与者可分为两类，一类是人，包括系统的使用者、维护者等，另外一类是其他系统。

用例（Use Case）是==参与者（Actor）可以感受到的系统服务或功能单元。==

任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例，所以识别用例的最好方法就是==从分析系统参与者开始，在这个过程中往往会发现新的参与者。==

用例是有粒度的，用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。

所谓系统边界是指系统与系统之间的界限。把系统边界以外的同系统相关联的其他部分称之为系统环境。

为了减少模型维护的工作量、保证用例模型的可维护性和一致性，可以在用例之间抽象出 包含（Include）、扩展（Extend）和泛化（Generalization） 这几种关系

1、 包含关系 是指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。
包含关系用来把一个较复杂用例所表示功能分解成较小的步骤。包含用例是必须的，如果缺少包含用例，基用例就不完整；包含用例必须被执行。
箭头指向：指向分解出来的功能用例。

用例图虽然作为UML中的一部分，给团队成员提供一种形象的系统表述，但是，用例图也由它本身的缺陷，用例图一般在需求分析阶段就给出了，有的时候对于系统的需求，并不能很好的表述，对于没有UML背景的人来说，更是一种痛苦与折磨，但是，话又说回来，作为软件开发人员，没有UML背景是说不过去的；有的时候，我们需要借助用例图对客户讲解系统，而让客户去理解用例图则是很困难的。
虽然，在用例图中的关系种类不是很多，也不是很复杂，但是UML的表示确实很让人费解的，别的还好，特别是扩展（Extend）和包含（Include），表示方式都一样的，仅靠上面的说明来进行区分，在一个复杂的系统中，是很容易看错的，从而理解出错，同时，扩展（Extend）中的箭头指向一直是让我很费解的，为什么需要让箭头指向基用例呢？
鉴于用例图有的时候并不能清楚地表达功能需求，开发中大家通常用用例描述表来补充某些不易表达的用例，请大家参考下图：