学习完UML的九种图之后，我们就可以开始学习如何利用UML来开发一个管理信息系统了。一般从用例图开始，由动入静，一步步搭建起系统模型。从确定系统基本需求（用例图）入手，完成用例图之后，再分析各个用例具体实现的动态模型——顺序图、状态图等。然后通过这些动态模型来确定系统的静态模型——类、对象图等，最后得到整个系统的组件图、部署图。

（一）确定用例以及用例之间的关系

用例模型主要由以下模型元素构成：

1.执行者（Actor）

执行者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。

2.用例（Use Case）

用例用于表示系统所提供的服务，它定义了系统是如何被执行者所使用的，它描述执行者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。

3.通信关联（Communication Association）

通信关联用于表示执行者和用例之间的对应关系，它表示执行者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些执行者所使用的。

这三种模型元素在UML中的表述如图9—33所示。

图9—33　UML的用例模型

以银行自动提款机（ATM）为例，它的主要功能可以由图9—34来表示。ATM的主要使用者是银行客户，客户主要使用自动提款机来进行银行账户的查询、提款和转账交易。

图9—34　银行ATM用例图

用例之间除了一般的通信关联（Communication Association）关系之外，还包含（include）、扩展（extend）和泛化（generalization）这三种关系。

（1）包含：包含关系是通过在关联关系上应用《include》构造型来表示的，如图9—35所示。

图9—35　用例的包含关系

（2）扩展：是指将扩展用例（Extension）的事件流在一定的条件下按照相应的扩展点插入到基础用例（Base）中，如图9—36所示。

图9—36　用例的扩展关系(www.daowen.com)

（3）泛化：当多个用例共同拥有一种类似的结构和行为时，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例，如图9—37所示。

图9—37　用例的泛化关系

（二）确定执行者和用例的细节描述

参照图9—34中描述的银行ATM用例图，以其中的执行者“银行客户”和用例“提款”为例来说明执行者和用例的细节描述。

1.执行者（如图9—38所示）

图9—38　执行者细节描述示例

2.用例（如图9—39所示）

图9—39　用例细节描述示例

（三）根据用例详述，给出系统动态模型

参照图9—39里描述的“提款”用例详述，可以将“提款”过程用顺序图描述出来，如图9—40所示。注意：提款过程除了“银行客户”和“后台服务器”两个执行者之外，还有ATM机参与。

动态模型除了顺序图之外，还有协作图、状态图和活动图，本章前面均已做过介绍。动态模型中的图主要为系统分析之用，在具体管理信息系统时，可以灵活选择，搭配使用。

（四）根据系统动态模型，给出系统静态模型

图9—40　“提款”用例的顺序图

参照图9—40里描述的系统动态模型，可以确定银行ATM系统的“提款”功能中需要用到的两个类（ATM类和后台服务器类），以及它们之间的关系。图9—41为“提款”用例的类图。

图9—41　“提款”用例的类图

静态模型除了类图之外，还有对象图、组件图、部署图，本章前面也都做过讲解。静态模型中的图相当于系统设计图纸和施工蓝图，对简单管理信息系统来说，用类图就可以清晰表达了。