PlantUML——用例图

PlantUML用例图

1、用例图基本概念

用例图源于Jacobosn的OOSE方法，它通过用例（Use Case）来捕获系统的需求，再结合参与者（Actor）进行系统功能需求的分析和设计。

1.1、用例图的定义

由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。

其中用例和参与者之间的对应关系又叫作 通信关联（Communication Association） ，它表示参与者使用了系统中的哪些用例。用例图是从软件需求分析到最终实现的第一步，它显示了系统的用户和用户希望提供的功能，这有利于用户和软件开发人员之间的沟通。

要在用例图上显示某个用例，可以绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。

要在用例图上绘制一个参与者（表示一个系统用户），可绘制一个人形符号。参与者和用例之间的关系使用带箭头或者不带箭头的线段来描述，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者；如果不想强调对话中的主动与被动关系，可以使用不带箭头的线段。如图所示为银行自动取款机（ATM）的用例图。

进行用例建模时，所需要的用例图数量是根据系统的复杂度来衡量的。在一个简单的系统中往往只需要有一个用例图就可以描述清楚所有的关系。但是对于复杂的系统，一张用例图显然是不够的，这时候就需要用多个用例图来共同描述复杂的系统。然而，一个系统的用例图也不应该过多。

对于较复杂的大中型系统，用例模型中的参与者和用例会大大增加，这样的系统往往会需要几张甚至几十张用例图。为了有效地管理由于规模上升而造成的复杂度，对于复杂的系统还会使用包（Package）---UML中最常用的管理模型复杂度的机制。

在用例建模中，有时为了更加清楚地描述用例或者参与者，会用到注释。如图所示，可以对参与者进行注释。

要注意的是，不管是包（Package）还是注释，都不是用例图的基本组成元素，不过在用例建模过程中可能会用到这两种附加元素。

1.2、用例图的作用

用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员以可视化的方式了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、不同领域的专家能够大量减少了交流上的障碍，便于对问题达成共识。

与传统的SRS方法相比，用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。另外，用例方法是完全从外部来定义系统的功能，它把需求和设计完全地分离开来。人们不用关心系统内部是如何完成各种功能的，系统对于大家来说就是一个黑箱子。用例图可视化地描述了系统外部的用户（抽象为参与者）和用户使用系统时系统为这些用户提供的一系列服务（抽象为用例），并清晰地描述了参与者和参与者之间的泛化关系，用例和用例之间的包含关系、泛化关系、扩展关系，以及用例和参与者之间的关联关系。所以从用例图中，人们可以得到被定义系统的一个总体印象。

在面向对象的分析和设计方法中，用例图可以用于描述系统的功能性需求。每一个用例都描述了一个完整的系统服务，作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。

2、用例图的组成

用例图的4个组成元素：参与者（角色）、用例、系统边界和关联。只有了解了这4个元素的概念，它们之间的用法和相互关系，才能得心应手地画好用例图。

2.1、参与者

2.1.1、参与者的概念

参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图标下面，如图所示。

很多初学者都把参与者理解为人，这是错误的。参与者代表的是一个集合，通常一个参与者可以代表一个人、一个计算机子系统、一个硬件设备或者时间等。人是其中最常见也是最容易理解的参与者，对于上一节中提到的银行自动取款机（ATM）来说，它的参与者就是银行用户。

一个系统也可以作为参与者，大家去商场购物，经常会采用刷卡付款的方式，这时候就需要商场的管理程序和外部的应用程序建立联系，来验证信用卡以便完成信用卡的付款操作。其中，外部信用卡程序就是一个参与者，是一个系统。

而在有的系统中，一个进程也可以作为参与者，例如时间。如果家里开通上网包月的话，当包月时间快结束的时候，系统就会提示相关服务人员，再由这些人员通知包月到期的用户。由于时间不在人的控制范围内，因此也是一个参与者。

要注意的是，参与者虽然可以代表人或事物，但参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。例如小王是银行的工作人员，他参与银行管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为银行用户来取钱，在这里小王扮演了两个角色，是两个不同的参与者。因此，不能将参与者的名字表示成参与者的某个实例，例如小王作为银行用户来取钱，但是参与者的名字还是银行用户而不能是小王。

一个用例的参与者可以划分为发起参与者和参加参与者。发起参与者发起了用例的执行过程，一个用例只有一个发起参与者，可以有若干个参加参与者。在用例中标明发起参与者是一个明智的做法。

参与者还可以划分为主要参与者和次要参与者。主要参与者指的是执行系统主要功能的参与者，次要参与者指的是使用系统次要功能的参与者。标明主要参与者有利于找出系统的核心功能，往往也是用户最关心的功能。

2.1.2、参与者之间的关系

由于参与者实质上也是类，因此它拥有与类相同的关系描述，即参与者与参与者之间主要是 泛化关系（或称为"继承"关系） 。泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述成超类（或父类）。

泛化关系表示的是参与者之间的一般或特殊关系，在UML图中，使用带空心三角箭头的实线表示泛化关系，如图所示，箭头指向超类参与者。

在需求分析中很容易碰到用户权限问题，就拿一个公司来说，普通职员有权限进行一些常规操作，而销售经理和人事经理在常规操作之外还有权限进行销售管理和人事管理。用例图如图所示。

在这个例子中，我们会发现销售经理和人事经理都是一种特殊的用户，他们拥有普通用户所拥有的全部权限，此外他们还有自己独有的权限。这里可进一步把普通用户和销售经理、人事经理之间的关系抽象成泛化（Generalization）关系。

如图所示，职员是父类，销售经理和人事经理是子类。通过泛化关系，可以有效地减少用例图中通信关联的个数，简化用例模型，便于大家理解。

2.2、系统边界

所谓系统边界是指系统与系统之间的界限。通常所说的系统可以认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。系统同时又是相对的，一个系统本身又可以是另一个更大系统的组成部分，因此，系统与系统之间需要使用系统边界来进行区分。我们把系统边界以外的与系统相关联的部分称为系统环境。

在项目开发过程中，边界是一个非常重要的概念。系统与环境之间存在边界，子系统与其他子系统之间存在边界，子系统与整体系统之间存在边界。总之，没有完整的边界就不会有完整的分类，也就不会有完整的系统，边界的重要性一点也不亚于系统本身。

用例图中的系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统的外部。虽然有系统边界的存在，但是使用Rose画图并不会画出系统的边界，如果采用Visio软件画图，系统边界在用例图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面，如图所示。

系统边界决定了参与者，如果系统的边界不一样，它的参与者就会发生很大的变化。例如，对于一个银行自动取款系统来说，它的参与者就是银行客户，但是如果将系统的边界扩大至整个银行系统，那么系统参与者还将包括银行职员。由此可见，在系统开发过程中，系统的边界占据了举足轻重的地位，只有搞清楚了系统的边界，才能更好地确定系统的参与者和用例。

2.3、用例

2.3.1、用例的概念

用例（Use case）是参与者（角色）可以感受到的系统服务或功能单元。它定义了系统如何被参与者使用，描述了参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段交互作用。用例最大的优点就是站在用户的角度上（从系统的外部）来描述系统的功能。它把系统当作一个黑箱子，并不关心系统内部是如何完成它所提供的功能，只表达整个系统对外部用户可见的行为。

UML中通常以一个椭圆图符来表示用例，用例名称书写在椭圆下方，如图所示。

每个用例在其所属的包里都有唯一的名字，该名字是一个字符串，包括简单名和路径名。用例的路径名就是在用例名前面加上用例所属的包的名字，如图所示为带路径名的用例。用例名可以包括任意数目的字母、数字和除冒号以外的大多数标点符号。用例的名字可以换行，但应易于理解，往往是一个能准确描述功能的动词短语或者动名词词组。

用例和参与者之间的关系属于关联关系（Association），又称作通信关联（CommunicationAssociation） 。关联关系是双向的一对一的关系，这种关系表明了哪个参与者与用例通信。

需要注意用例的一些特征。首先，用例必须由某一个参与者触发激活后才能执行，即每个用例至少应该涉及一个参与者。如果存在没有参与者的用例，就可以考虑将这个用例并入其他用例之中。

其次用例也是一个类，而不是某个具体的实例。用例所描述的是它代表的功能的各个方面，包含了用例执行期间可能发生的各种情况。例如，从ATM系统中取款这个用例，张三持银行卡去取钱，系统收到消息后将钱送出的过程就是一个实例。而李四持银行卡取钱，系统收到消息后因为钱已经取完而将银行卡退给李四也是一个实例。

注意，用例是一个完整的描述。一个用例在编程实现的时候往往会被分解成多个小用例（函数），这些小用例的执行会有先后之分，其中任何一个小用例的完成都不能代表整个用例的完成。只有当所有的小用例都完成，并最终产生了返回给参与者的结果，才能代表整个用例的完成。

2.3.2、用例的粒度

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

对同一个系统的描述，不同的人可能会产生不同的用例模型。如果用例数量过多，就会造成用例模型过大和引入设计的困难大大提高。如果用例数量过少，就会造成用例的粒度太大，又不便于进一步的充分分析。

如图所示为学生管理系统中的学生信息维护用例，管理员需要添加、修改、删除学生信息等操作。

还可以根据具体的操作把它抽象成3个用例，如图所示，它展示的系统需求和单个用例是完全一样的。

当大致确定用例数量后，就可以轻松确定用例粒度的大小。对于比较简单的系统，因为系统的复杂度一般比较低，所以可以适当加大用例模型一级的复杂度，也就是可以将较复杂的用例分解成多个用例。对于比较复杂的系统，因为系统的复杂度已经很高，这就要求我们加强控制用例模型一级的复杂度，也就是将复杂度适当地移往用例内部，让一个用例包含较多的功能。

用例的粒度对于用例模型来说是很重要的，它不但决定了用例模型级的复杂度，而且也决定了每一个用例内部的复杂度。在确定用例粒度的时候，应该根据每个系统的具体情况，具体问题具体分析，在尽可能保证在整个用例模型容易理解的前提下决定用例粒度的大小和用例的数量。

2.4、用例之间的关系

为了减少模型维护的工作量，保证用例模型的可维护性和一致性，可以在用例之间抽象出包含（Include）、扩展（Extend）和泛化（Generalization）这几种关系。这几种关系都是从现有的用例中抽取出公共信息，再通过不同的方法来重用这部分的公共信息。

2.4.1、包含

包含关系是指用例可以简单地包含其他用例具有的行为，并把它所包含的其他用例的行为作为自身行为的一部分。在UML中，包含关系是通过带箭头的虚线段加<<include>>字样来表示，箭头由基础用例（Base）指向被包含用例（Inclusion），如图所示。包含关系代表着基础用例会用到被包含用例，就是将被包含用例的事件流插入到基础用例的事件流中。

需要注意的是，包含（Include）关系是UML 1.3中的表述，在UML 1.1中，同等语义的关系被表述为使用（Uses），如图所示。

在处理包含关系时，具体的做法就是把几个用例的公共部分单独地抽象出来成为一个新的用例。主要有两种情况需要用到包含关系：

多个用例用到同一段的行为，可以把这段公共的行为单独抽象成为一个用例，然后让其他用例来包含这一用例。某一个用例的功能过多、事件流过于复杂时，就可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的。

下面来看一个具体的例子，有一个资源网站，维护人员要对网站的资源进行维护，包括添加资源、修改资源和删除资源。其中，在添加资源和修改资源后，都要对新添加的资源和修改的资源进行预览，以检查添加和修改操作完成是否正确。用例图如图所示。

这个例子就是把添加资源和修改资源都会用到的一段行为抽象出来，成为一个新的用例---预览资源。而原有的添加资源和修改资源这两个用例都会包含这个新抽象出来的资源。如果以后需要对资源预览进行修改，则不会影响到添加资源和修改资源这两个用例。并且由于是一个用例，就不会发生同一段行为在不同用例中描述不一致的情况。通过这个例子可以看出包含关系的两个优点：

提高了用例模型的可维护性，当需要对公共需求进行修改时，只需要修改一个用例而不必修改所有与之有关的用例。
不但可以避免在多个用例中重复地描述同一段行为，还可以避免在多个用例中对同一段行为的描述不一致。

2.4.2、扩展

在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫作扩展用例（Extension），原有的用例叫作基础用例（Base），从扩展用例到基础用例的关系就是扩展关系。一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起使用。在UML中，扩展关系是通过带箭头的虚线段加<<extend>>字样来表示，箭头指向基础用例，如图所示。

在扩展关系中，基础用例提供了一个或者多个插入点，扩展用例为这些插入点提供了需要插入的行为。而在包含关系中，插入点只能有一个。

基础用例的执行并不一定会涉及扩展用例，扩展用例只有在满足一定条件下才会被执行。而在包含关系中，当基础用例执行后，被包含用例是一定会被执行的。即使没有扩展用例，扩展关系中的基础用例本身就是完整的。而对于包含关系而言，基础用例在没有被包含用例的情况下就是不完整的存在。

让我们来看一个具体的例子，如图所示为图书馆管理系统用例图的部分内容。在本用例中，基础用例是"还书"，扩展用例是"缴纳罚金"。在一切顺利的情况下，只需要执行"还书"用例即可。但是，如果借书超期或者书有破损，借书用户就要缴纳一定的罚金。这时就不能执行用例的常规动作，如果去修改"还书"用例，势必增加系统的复杂性。这时就可以在基础用例"还书"中增加插入点，这样当出现超期或破损的情况时，就执行扩展用例"缴纳罚金"。

扩展关系往往被用来处理异常或者构建灵活的系统框架。使用扩展关系可以降低系统的复杂度，有利于系统的扩展，提高系统的性能。扩展关系还可以用于处理基础用例中那些不易描述的问题，使系统显得更加清晰和易于理解。

2.4.3、泛化

用例的泛化指的是一个父用例可以被特化成多个子用例（从一般到特殊），而父用例和子用例之间的关系就是泛化关系。在用例的泛化关系中，子用例继承了父用例所有的结构、行为和关系，子用例是父用例的一种特殊形式。此外，子用例还可以添加、覆盖、改变继承的行为。在UML中，用例的泛化关系通过一个三角箭头从子用例指向父用例来表示，如图所示。

当我们发现系统中有两个或者多个用例在结构、行为和目的方面存在共性时，就可以使用泛化关系。这时，可以用一个新的（通常也是抽象的）用例来描述这些公共部分，这个新的用例就是父用例。

如图所示，用例图为飞机订票系统预定机票有两种方式，一种是通过电话预定，一种是通过网上预定。在这里，电话订票和网上订票都是订票的一种特殊方式，因此"订票"为父用例，"电话订票"和"网上订票"为子用例。

虽然用例泛化关系和包含关系都可以用来复用多个用例中的公共行为，但是它们还是有很大区别的。在用例的泛化关系中，所有的子用例都有相似的目的和结构，注意它们是整体上的相似。而用例的包含关系中，基础用例在目的上可以完全不同，但是它们都有一段相似的行为，它们的相似是部分相似而不是整体相似。用例的泛化关系类似于面向对象中的继承，它把多个子用例中的共性抽象成一个父用例，子用例在继承父用例的基础上可以进行修改。但是，子用例和子用例之间又是相互独立的，任何一个子用例的执行不受其他子用例的影响。而用例的包含关系是把多个基础用例中的共性抽象为一个被包含用例，可以说被包含用例就是基础用例中的一部分，基础用例的执行必然引起被包含用例的执行。

3、PlantUML语法

3.1、用例

用例用圆括号括起来（两个圆括号看起来就像椭圆）。
也可以用关键字 usecase 来定义用例。
还可以用关键字 as 定义一个别名，这个别名可以在以后定义关系的时候使用。

js 复制代码

@startuml
(First usercase)
(Another usercase) as (UC2)
usecase UC3
usecase (Last\nusecase) as UC4
@enduml

3.2、参与者

定义一个演员的名字被括在冒号之间。
也可以使用 actor 关键字来定义一个参与者。
可以使用 as 关键字来指定，并且可以在以后代替行为体的名称，例如在定义关系时使用。

js 复制代码

@startuml
:First Actor:
:Another\nactor: as Man2
actor Woman3
actor :Last actor: as Person1
@enduml

3.3、参与者样式

可以将角色的样式从默认的火柴人改成：

用户头像样式：skinparam actorStyle awesome
透明人样式：skinparam actorStyle hollow

用户头像样式：

js 复制代码

@startuml
skinparam actorStyle awesome
actor User
actor "Main Admin" as Admin

usecase "Use the application" as UC_Use
usecase "Admin the application" as UC_Admin

User --> UC_Use
Admin --> UC_Admin
@enduml

透明人样式：

js 复制代码

@startuml
skinparam actorStyle Hollow
actor User
actor "Main Admin" as Admin

usecase "Use the application" as UC_Use
usecase "Admin the application" as UC_Admin

User --> UC_Use
Admin --> UC_Admin
@enduml

3.4、用例描述

如果想定义跨越多行的用例描述，可以用双引号将其裹起来。
还可以使用这些分隔符：
- --（横线）
- ..（虚线）
- ==（双横线）
- __（下划线）
  并且还可以在分隔符中间放置标题。

js 复制代码

@startuml
usecase UC1 as "You can use
several lines to define your usecase.
You can also use separators.
--
Several separators are possible.
==
And you can add titles:
..Conclusion..
This allows large description."
@enduml

3.5、使用包

可以一使用包来对角色或用例进行分组。

js 复制代码

@startuml
left to right direction
actor Guest as g
package Professional {
    actor Chef as c
    actor "Food Critic" as fc
}
package Restaurant {
    usecase "Eat Food" as UC1
    usecase "Pay for Food" as UC2
    usecase "Drink" as UC3
    usecase "Review" as UC4
}
fc --> UC4
g --> UC1
g --> UC2
g --> UC3
@enduml

可以使用 rectangle 来改变包的外观。

js 复制代码

@startuml
left to right direction
actor "Food Critic" as fc
rectangle Restaurant {
    usecase "Eat Food" as UC1
    usecase "Pay for Food" as UC2
    usecase "Drink" as UC3
}
fc --> UC1
fc --> UC2
fc --> UC3
@enduml

3.6、基础示例

用箭头--> 连接角色和用例。
横杠-越多，箭头越长。通过在箭头定义的后面加一个冒号及文字的方式来添加标签。

在这个例子中，User 并没有定义，而是直接拿来当做一个角色使用。

js 复制代码

@startuml
User -> (Start)
User --> (Use the application) : A small label

:Main Admin: ---> (Use the application) : This is\nyet another\nlabel
@enduml

3.7、继承（泛化）

如果一个角色或者用例继承于另一个，那么可以用 <|--符号表示。

js 复制代码

@startuml
:Main Admin: as Admin
(Use the application) as (Use)

User <|-- Admin
(Start) <|-- (Use)
@enduml

3.8、使用注释

可以用 note left of , note right of , note top of , note bottom of 等关键字给一个对象添加注释。
还可以通过 note 关键字来定义，然后用.. 连接其他对象。

js 复制代码

@startuml
:Main Admin: as Admin
(Use the application) as (Use)

User -> (Start)
User --> (Use)
Admin ---> (Use)

note right of Admin : 注释示例

note right of (Use)
    定义在右侧的
    注释 
end note

note "这个注释与多个用例相连" as N2

(Start) .. N2
N2 .. (Use)
@enduml

3.9、构造类型

用 << 和 >> 来定义角色或者用例的构造类型。

js 复制代码

@startuml
User << Human >>
:Main Database: as MySql << Application >>

(Start) << One Shot >>
(Use the application) as (Use) << Main >>

User -> (Start)
User --> (Use)
MySql --> (Use)
@enduml

3.10、改变箭头方向

默认情况下，类之间的链接有两个破折号-- ，并且是垂直方向的。可以通过像这样放一个破折号（或点）

来使用水平链接。

js 复制代码

@startuml
:user: --> (Use case 1)
:user: -> (Use case 2)
@enduml

可以通过反转链接来改变方向。

js 复制代码

@startuml
(Use case 1) <.. :user:
(Use case 2) <- :user:
@enduml

也可以通过在箭头内添加 left,right,up 或 down 关键字来改变箭头方向。

js 复制代码

@startuml
:user: -left-> (dummyLeft)
:user: -right-> (dummyRight)
:user: -up-> (dummyUp)
:user: -down-> (dummyDown)
@enduml

可以通过只使用方向的第一个字符来缩短箭头（例如，-d- ，而不是 -down- ）或两个第一个字符(-do-)。

3.11、分割图示

用 newpage 关键字将图示分解为多个页面。

js 复制代码

@startuml
:actor1: --> (Usecase1)
newpage
:actor2: --> (Usecase2)
@enduml

3.12、从左向右方向

默认从上往下构建图示。

js 复制代码

@startuml
'default
top to bottom direction
user1 --> (Usecase 1)
user2 --> (Usecase 2)
@enduml

可以用 left to right direction 命令改变图示方向。

js 复制代码

@startuml
left to right direction
user1 --> (Usecase 1)
user2 --> (Usecase 2)
@enduml

3.13、显示参数

用 skinparam 改变字体和颜色。

可以在如下场景中使用：

在图示的定义中
在引入的文件中
在命令行或者 ANT 任务提供的配置文件中

也可以给构造的角色和用例指定特殊颜色和字体。

js 复制代码

@startuml
skinparam handwritten true
skinparam usecase {
    BackgroundColor DarkSeaGreen
    BorderColor DarkSlateGray
    BackgroundColor<< Main >> YellowGreen
    BorderColor<< Main >> YellowGreen
    ArrowColor Olive
    ActorBorderColor black
    ActorFontName Courier
    ActorBackgroundColor<< Human >> Gold
}
User << Human >>
:Main Database: as MySql << Application >>

(Start) << One Shot >>
(Use the application) as (Use) << Main >>

User -> (Start)
User --> (Use)
MySql --> (Use)
@enduml

3.14、完整样例

js 复制代码

@startuml
left to right direction
skinparam packageStyle rectangle
actor customer
actor clerk
rectangle checkout {
    customer -- (checkout)
    (checkout) .> (payment) : include
    (help) .> (checkout) : extends
    (checkout) -- clerk
}
@enduml

3.15、业务用例

可以添加/ 来制作业务用例。

3.15.1、业务用例

js 复制代码

@startuml
(First usecase)/
(Another usecase)/ as (UC2)
usecase/ UC3
usecase/ (Last\nusecase) as UC4
@enduml

3.15.2、商业参与者

js 复制代码

@startuml
:First Actor:/
:Another\nactor:/ as Man2
actor/ Woman3
actor/ :Last actor: as Person1
@enduml

3.16、改变箭头的颜色和样式（内联样式）

可以使用以下的内联式符号改变单个箭头的颜色或样式。

#color;line.[bold|dashed|dotted];text:color

js 复制代码

@startuml
actor foo
foo --> (bar) : normal
foo --> (bar1) #line:red;line.bold;text:red : red bold
foo --> (bar2) #green;line.dashed;text:green : green dashed
foo --> (bar3) #blue;line.dotted;text:blue : blue dotted
@enduml

3.17、改变元素的颜色和样式（内联样式）

可以用以下符号改变单个元素的颜色或样式。

#[color|back:color];line:color;line.[bold|dashed|dotted];text:color

js 复制代码

@startuml
actor a
actor b #pink;line:red;line.bold;text:red
usecase c #palegreen;line:green;line.dashed;text:green
usecase d #aliceblue;line:blue;line.dotted;text:blue
@enduml

3.18、显示 JSON 数据

js 复制代码

@startuml
allowmixing
actor 用户
usecase 用例
json JSON {
	"水果":"苹果",
	"尺寸":"大",
	"颜色": ["红", "绿"]
}
@enduml

3.19、示例

js 复制代码

@startuml
left to right direction

actor 仓库管理员 as UC

UC --> (登录)
(登录) ..> (身份验证) : <<extend>>
UC --> (产品入库)
UC --> (产品出库)
UC --> (产品报销)
UC --> (产品盘点)
UC --> (设置管理)

(设置管理) ..> (修改供应信息) : <<include>>
(设置管理) ..> (修改产品信息) : <<include>>
@enduml