用例图用于系统分析的第一步，描述系统：做什么？ 用例图是用来描述用户需求的图，它从用户的角度描述系统功能 并指明各功能的操作者，当前用例概念和用例驱动设计已经成为面对对象设计与分析方法中不可缺少的一部分。

用例图（Use Case Diagram）的元素：参与者、用例、关系

参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象，用小人符号表示，下面标注参与者的名称

用例(Use Case)–用例就是外部可见的系统功能，对系统提供的服务进行描述，一般用动名词形容。用椭圆表示，上面标注用例名称

用例图总共有四种关系，如下所示：

是最基本的关系，表示参与者和用例之间的交互。表示参与者与用例之间的通信和交互。关联关系在用例图中表示为一条直线，从参与者指向用例

一个父用例被特化成多个子用例，就是继承关系。用空心箭头表示，箭头指向父用例。泛化关系在用例图中表示为带空心箭头的实线，从子用例指向父用例。

包含关系（include）是把几个用例的公共行为分离成一个单独的用例，使这几个用例与该单独的用例之间建立关系。单独抽取出来的用例叫被包含用例，而抽取出公共用例的那几个用例叫做基本用例，用带《include》的虚线表示，箭头指向被包含用例。

tips： 包含关系中，在执行基本用例的时候一定会执行包含用例！ 包含用例带有复用的意思，表示的是“必需”而不是“可选”，如果没用被包含用例，基本用例就不完整，被包含用例不能脱离基本用例来单独存在。 包含关系一般是多对一的关系，由多个基本用例指向一个被包含用例，例子如下： 如下是网上的一个用例图的例子，但我感觉不太合适，这样描述，被包含用例可以脱离基本用例来单独存在，而且也没有体现复用，所以我认为是错的，我在有的UML教程教材书中看到作者用《extend》去描述，个人建议用《extend》去描述，或者用多张用例图去描述，系统层次上只用一个“维护XX”去概括，然后在用另一张用例图去展开增删改查的用例。

扩展关系（extend）是将基本用例中的一段相对独立且可选的动作，用扩展用例加以封装，再让它从基本用例上的扩展点进行扩展，使基本用例行为更加简练、目标更加集中。用带《extend》的虚线表示，箭头指向基本用例。 tips： 扩展关系中，在执行基本用例的时候不一定会执行包含用例！ 扩展关系是为基本用例添加新的行为，扩展表示“可选”而不是“必需”，意味着即使没有扩展用例，基本用例是完整的，但同样，扩展用例不能脱离基本用例来单独存在。 一个基本用例可以有多个扩展用例。 包含关系和扩展关系辨析：

找到系统的使用者，可以对参与者进行角色划分，注意参与者之间是否有继承泛化关系

tips： 用例是具有一定复杂性的系统功能，而不是具体的步骤，用简洁的“动名词”描述系统的功能，注意动词在前只有一个，名词在后，且无人称代词 eg： 相关新闻推荐 ：推荐相关新闻 上传下载图片 ：上传图片、下载图片 商家导入菜品 ：导入菜品

tips： 参与者和用例之间采用关联关系 泛化关系表示“XX是一种XX”的关系 包含关系表示“XX都有A ”的关系 扩展关系表示“XX是一种特殊情况的XX”关系

tips： 用例图可以一张，也可以绘制多张，可以从参与者的角色分类进行绘制，也可以按系统的层次进行（例如一张用例图从系统层次展现，其余用例图对在系统图中的基本用例进行展开）

用例图是骨架，而用例规约则是其内在； 不同开发团队在进行系统分析的时候可能对用例规约的要求略有差异，但大体的格式如下： 系统用例规约编写步骤： 实例如下： tips： 1、用例名称要与用例图的用例名称保持一致； 2、事件流是两个对象之间交互的触发和响应，学生在系统上xx，系统xx学生，eg：“系统查询书籍 ”只涉及系统，所以就是不太规范的描述，应该为“系统（给用户）展示查询到的书籍” 3、用例规约不是用户手册，要写上系统的行为，而不是“完全写用户的行为，直接完成，没有系统处理”； 4、事件流一定要带上主语，学生xx，系统xx； 5、事件流中不能出现与该用例名一样的步骤 6、步骤中要写操作或动作，eg：“系统添加成功 ”，并不是一个动作，应该为“系统显示添加成功”； 7、其他事件流是基本事件流的分支，每一分支的结束要写完整，表达清楚，分支的最后是“结束用例”还是“继续某一事件（事件2）” 8、其他事件流的扩展，需要我们思考，该用例执行失败的情况或者执行异常的特殊情况。