初次学习UML—用例图（Use Case Diagram）

用例图（Use Case Diagram）

1. 概念

---

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

2. 用例图的构成要素

---

用例图包含3方面内容：参与者（actor）、用例（use case）、关系。

• **参与者：**一般用“人形”表示。

• 用例：一般用椭圆表示，并标注用例名称。每个用例都必须有一个惟一的名字以区别于其它用例。

• 关系：

（1）关联（Association）：用例与其参与者之间的关联关系用带箭头的直线或不带箭头的直线表示。

（2）泛化（Generalization）：如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。

【泛化误区】:

（3）包含（Include）：包含关系把几个用例的公共步骤分离成一个单独的被包含用例。在UML中，扩展关系表示为虚线箭头加<<include>>字样，箭头指向被扩展的用例。

（4）扩展（Extend）：扩展关系是把新的行为插入到已有用例中的方法。一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系。

• 在UML中，扩展关系表示为虚线箭头加<<extend>>字样，箭头指向被扩展的用例。

• 被包含用例称作提供者用例（基本用例），包含用例称作客户用例，提供者用例提供功能给客户使用。

• 基础用例的扩展增加了原有的语义。

• 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。

• 基础用例即使没有扩展用例也是完整的。

• 只有特定的条件发生，扩展用例才被执行。

扩展关系为处理异常或构建灵活的系统框架提供了一种十分有效的方法。

【扩展误区】:

**说明：**除上面外，用例图中可以包含注释、约束以及包。

---

3. 用例粒度

---

• 用例的粒度：用例所包含的系统服务或功能单元的多少。

• 用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。

优缺点：

• 如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。

• 如果用例数目过多会造成用例模型过大和引入设计困难大大提高。

• 如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。

【误区1】:把步骤当用例。

【误区2】: 把系统活动当用例。

---

4. 用例规约

---

用例规约用来描述用例的，不是用例图。

• 用例图只是在总体上大致描述了系统所提供的各种服务，让用户对系统有一个总体的认识。但对于每一个用例还需要有详细的描述信息，以便让其他人对于整个系统有一个更加详细地了解，这些信息包含在用例规约之中。

• 用例模型指的也不仅仅是用例图，而是由用例图和用例的详细描述——用例规约所组成的。

• 用例图是骨架，而用例规约则是其内在的肉。

用例规约包含以下内容：

（1）简要说明：对用例作用和目的的简要描述。

（2）事件流：事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。
（3）用例场景：同一个用例在实际执行的时候会有很多不同的情况发生，称之为用例场景，也可以说用例场景就是用例的实例。
（4）特殊需求：特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。
（5）前置条件：执行用例之前系统必须所处的状态。例如，前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。
（6）后置条件：用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。

【用例规约示例】

---

5. 实例

---

5.1 企业进、存、销管理系统

“企业进、存、销管理系统” 功能性需求包括以下内容：
（1）采购员根据生产原料的使用情况判断采购用品，对需要订购产品信息统计订货的，并制作产品订单。最后根据订单进行采购活动。
（2）仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、处理报损产品信息和一些信息的设置。这些设置信息，包括：供应商信息、产品信息。仓库管理员每天对产品进行一次盘点，当发现库存产品有损坏时，及时处理报损信息。当产品生产后，将产品进行入库。当产品销售后时，产品进行出库处理。
（3）统计人员负责统计分析管理，包括：查询产品信息、查询销售信息、查询供应商信息、查询缺货信息、查询报表信息，并制作报表。统计分析员使用系统的统计分析功能，了解产品信息、销售信息、供应商信息、库存信息。
（4）在销售员为客户提供售货服务时，接受客户购买产品，根据系统的定价计算出产品的总价，客户付款，系统自动保存客户购买记录。
（5）系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、供货商信息管理以及系统维护等。每种管理者都通过自己的用户名称和密码登录到各自的管理系统中。

步骤一：需求分析。

（1）销售员：为客户客提供销售产品的服务。
（2）仓库管理员：负责库存产品的管理活动。
（3）采购员：负责企业生产原料的订购。
（4）会计：负责企业经营状况的统计。
（5）系统管理员：负责企业员工信息管理、供应商信息管理以及系统维护等。

步骤二：构建用例模型。

（1）销售员用例图。

销售员能够通过该系统进行销售商品活动。首先登录系统，验证身份成功后，获取商品信息，然后将销售信息更新，最后对客户进行商品销售。

（2）仓库管理用例图。

仓库管理员能够通过该系统进行如下活动：
（1）处理盘点，每天需要对库存产品信息进行盘点。
（2）产品入库。当产品生产后，将产品进行入库。
（3）产品出库。当产品销售发货后，进行出库处理。
（4）管理设置。仓库管理员负责供应商信息、产品基本信息的管理设置。

（3）采购员用例图。

采购员能够通过该系统进行订货管理活动。采购员首先根据经营情况统计所缺的生产资料，根据需要制定出订单。

（4）会计用例图。

会计负责产品的统计分析管理，它能够通过该系统进行如下活动：
（1）查询基本信息。会计能够查询产品的基本信息，根据产品的基本信息，制定出相应的方案。
（2）查询销售信息。会计根据销售情况汇总后交销售部制定合理的销售方案。
（3）查询供应商信息。会计能够查询供应商信息。
（4）查询缺货信息。会计能够查询缺货信息。
（5）查询报损信息。会计能够查询报损信息。

（5）系统管理员用例图。

系统管理员能够通过该系统进行如下活动：
（1）维护员工信息。系统管理员能够维护企业员工的信息，如添加员工、删除员工和修改员工信息等。（2）维护供应商信息。系统管理员能够维护供应商的信息，如添加供应商、删除供应商和修改供应商信息等。
（3）系统设置。系统管理员能够根据一些需要进行必要的系统设置。

---

5.2 学生信息管理系统

在每个新学年开始的时候都会有新生入学。这时系统的管理人员可以通过系统将这些新生的学籍、年龄、家庭住址、性别、学生证号、身份证号等基本信息存入数据库。在日常的管理中，系统管理员还可以对所有学生的基本信息进行查询、修改、删除等操作。校领导可以查询、修改全校学生的基本信息，教师可以在日常工作中查询、修改自己班里学生的基本信息。学校的领导可以通过本系统了解每个班的任课教师、辅导员、学生、专业等班级基本信息。系统管理员可以进行查询班级基本信息、添加新班级、修改班级信息、删除班级等操作。考试结束后，教师可以录入学生成绩，还可以对成绩进行修改和查询。学生可以查询成绩。学生可以网上选课，可以通过系统看到课程的信息。每个学生每个学期的选课不得大于6门，如果已经选了6门课则不能选择新的课程。只有将已选的课程删除后才能再选。系统管理员负责修改、增加、删除选修课程。每个用户登陆系统，都需要一个账号，这就需要系统管理员对用户账户进行管理。

步骤一：需求分析

（1）学生信息管理模块学生信息管理模块主要用来实现系统管理员、教师、校领导等对学生基本信息的管理。系统管理员登录后可以对学生的基本信息进行增加、删除、修改和查询等操作；教师的校领导登录后可以对学生信息进行查询和修改操作。
（2）班级信息管理模块班级信息管理模块主要用来实现系统管理员、校领导对班级基本信息的管理。系统管理员登录后可以对班级基本信息进行增加、删除、修改和查询等操作；校领导登录后可以对学生信息进行查询操作。
（3）成绩管理模块成绩管理模块主要用于实现教师对学生考试成绩的管理以及学生对考试成绩的查询。教师登录后可以对学生成绩进行录入、删除、修改和查询等操作；学生登录后可以对成绩进行查询操作。
（4）网上选课模块网上选课模块主要用于实现学生在网上了解并选择自己感兴趣的课程。
（5）账号管理模块账号管理模块主要实现系统管理员对用户账号的管理。系统管理员可以对账号进行增加、删除、修改和查询等操作。

步骤二：构建用例模型。

（1）班级信息管理用例图。

（2）成绩管理用例图。

（3）网上选课用例图。

（4）账号管理用例图。