|教 案 样 稿|
《2.1 用例图》
 本节目标
本节主要学习以下内容：
参与者
用例
用例与事件流
用例之间的关系
用例图
通过教学使学生理解用例图的概念和内容，能够使用用例图对一个简单系统进行描述，并独立完成本节提出的任务。
 本节重点
参与者
用例
事件流
用例之间的关系
用例图
 本节难点
用例图的绘制
 授课课时
2课时
 教法建议
首先可以讲述在软件开发中，需求分析的重要性，从而引出在UML建模中怎么进行需求分析描述的概念。
在讲述基本概念时，应理论结合实践，以实际事例导出理论的方式讲述。
目标概述 [5分钟]
本章主要讲述UML建模中如何使用用例图和活动图对系统进行需求分析。
并对本课程的具体案例进行引入。
本节主要讲述用例图的相关概念和应用，并提出了本节应该完成具体任务。
回顾 [5分钟]
讲述需求分析的重要性以及回顾在第一章讲述的有关用例图的知识。[讲述+提问]
课程知识点讲解
引入：
如何使用UML对需求建模呢？ [给出问题]
我们可以使用用例(use case)作为着手进行需求建模的良好起点。用例按照系统的使用方式组织系统。以用例为起点进行需求建模，可以使我们的关注焦点集中于客户身上，而这一点在系统开发过程中常常被遗忘。
用例图是显示一组用例、参与者以及它们之间关系的图。
用例图包括以下三方面的内容。
1．参与者。
2．用例。
3．依赖、泛化和关联关系。
[简单描述对提出的问题的解决]
主题：
参与者(actor ，有些书翻译成“角色”)是一种特殊的类，是系统外部的一个实体，这个实体可以是任何的人或物，它以某种方式参与了用例的执行过程。
参与者对系统而言总是外部的。
在图形上，参与者用一个人形的图案表示。
在获取用例前首先要确定系统的参与者，可以根据下面的一些问题来寻找系统的参与者：
①谁使用系统？
②谁安装系统、维护系统？
③谁启动系统、关闭系统？
④谁从系统中获取信息，谁提供信息给系统？
⑤在系统交互中，谁扮演了什么角色？
⑥系统会与哪些其他系统相关联？
[简单介绍参与者的概念和UML中描述方式，如何查找参与者（任务实例部分实现）]
引入：
用例是对一组序列动作的描述，系统执行这些动作将对用例的参与者产生可以观察的结果。 [直述内容]
主题：
在图形上，用例用实线的椭圆表示。
参与者和用例分别描述了“谁来做？”和“做什么？”这两个问题。
识别用例的最好办法就是从分析系统的参与者开始，考虑每个参与者是怎样使用系统。
用例建模的过程就是迭代和逐步求精的过程：从确定用例的名称开始，然后添加用例细节信息，最后完成完整的用例规格说明。
[简述用例的概念和用例建模的过程]
可以根据下面的一些问题来识别用例：
①参与者希望系统提供什么功能；
②系统是否存储和检索信息；
③当系统改变状态时，是否通知参与者；
④是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件。
[简述识别用例的方法，任务实例部分实现]
如何判断一个用例是否是一个优秀的用例呢？可以通过下面的测试方法来检验。
①用例是否描述了应该做什么，而不是如何做？用例应该描述系统做什么，但不应该描述系统是如何被实现的。
②用例的描述是否采取了参与者的视点？在确定用例的关键特征时，应该依据参与者的视点。也就是说，应该从参与者如何使用系统的角度出发定义用例，而不是从系统自身的角度。
③用例是否对参与者有价值？用例不是动作步骤的任意集合，它必须为参与者提供可辨识的价值。
④用例描述的时间流是否是一个完整场景？每一个用例必须描述出在一个给定场景下参与者将如何使用系统的完整事件流。这有助于避免产生单步用例、部分用例或者功能分解用例。
⑤是否所有的参与者、用例都有相应的关联用例或关联参与者？
[简述如何判断是否为优秀用例，任务实例部分实现]
引入：
具体如何来描述一个用例呢？ [给出问题]
主题：
针对每一个用例我们可以用事件流来描述这一对话的细节内容。[实例说明]
基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。
备选流负责描述用例执行过程中异常的或偶尔发生的一些情况。
[简述事件流的基本概念，并以实例辅以说明]
引入：
用例描述的是系统外部可见的行为。
主题：
从原则上来讲，用例之间都是并列的，它们之间并不存在着包含从属关系。
但是从保证用例模型的可维护性和一致性角度来看，我们可以在用例之间抽象出包含(include)、扩展(extend)和泛化(generalization)这几种关系。
1．泛化关系(generalization)
当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系，还可以添加自己的行为或覆盖已继承的行为。
[简述泛化关系，举例说明]
2．包含关系(include)
包含是指基础用例(base use case)会用到被包含用例(inclusion)，具体地讲，就是将被包含用例的事件流插入到基础用例的事件流中。被包含用例是可重用的用例──多个用例的公共用例。
包含关系是关联关系的一种。
[简述包含关系，举例说明]
3．扩展关系(extend)
扩展关系也是关联关系的一种。假设基础用例中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。如果基础用例是一个很复杂的用例，选用扩展关系将某些业务抽象成为单独的用例可以降低基础用例的复杂性。
[简述扩展关系，举例说明]
引入：
用例图的主要作用是描述参与者和用例之间的关系，简单的系统中只需要有一个用例图就可以把所有的关系都描述清楚。复杂的系统中可以有多个用例图。 [直述内容]
主题：
如果想要强调某一个参与者和多个用例的关系，就可以以该参与者为中心，用一个用例图表述出该参与者和多个用例之间的关系。在这个用例图中，我们强调的是该参与者会使用系统所提供的哪些服务。
如果想要强调某一个用例和多个参与者之间的关系，就可以以该用例为中心，用一个用例图表述出该用例和多个参与者之间的关系。在这个用例图中，我们强调的是该用例会涉及到哪些参与者，或者说该用例所表示的系统服务有哪些使用者。
[简述用例图的作用，并以实例介绍如何描述用例图]
任务：
HNS是一所以培养软件开发人才为目标的高等院校，现在由于在校人数的增加，为提高办事效率，图书馆委托HNS的信息系统开发部来开发一套图书馆管理系统来管理图书馆的日常业务。关于该项目的业务描述见本章的项目引入。现需要完成如下任务：
（1）．分析该系统的需求，确定系统中的参与者和主要用例，并画出用例视图。
分析：
1．通过分析该系统的业务描述，我们总结了出现在系统中的主要活动，如下：
①读者需要借书籍，需要还书籍。
②读者可以预约书籍，也可以撤消预约。
③管理员根据读者要求提供服务。
④管理员可以添加、修改、删除读者。
⑤管理员可以添加、修改、删除书籍。
2．确定系统参与者。
经过对系统中主要活动的分析，我们可以看到，严格意义上的参与者只有两个：管理员和读者。系统的实际操作者是管理员，读者没有操作系统的权限，只能向管理员提出服务请求。
3．确定系统用例。
一个完整的需求分析，要求找出所有的用例。但在这里，我们只分析最主要的部分。在这个系统中，可以总结出如下的用例：
①读者信息管理模块
②书籍信息管理模块
- 删除书籍
- 删除书目
- 新增书籍
- 新增书目
- 修改书籍信息
③图书馆业务功能模块
④信息查询模块
实现：
具体见P44-47。
[通过任务实现讲述如何给一个系统绘制用例图]
小结 [5分钟]
本节学习了以下主要内容：
1．用例的概念
2．用例之间的关系
3．事件流的基本概念
4．UML中如何绘制用例图
考核点
 考核点1：用例的概念
考核点2：用例之间的关系
考核点3：事件流的基本概念
考核点4：UML中如何绘制用例图
作业答案
 1：什么是参与者？如何确定系统的参与者？
答：参与者(actor ，有些书翻译成“角色”)是一种特殊的类，是系统外部的一个实体，这个实体可以是任何的人或物，它以某种方式参与了用例的执行过程。
在获取用例前首先要确定系统的参与者，可以根据下面的一些问题来寻找系统的参与者：①谁使用系统？②谁安装系统、维护系统？③谁启动系统、关闭系统？④谁从系统中获取信息，谁提供信息给系统？⑤在系统交互中，谁扮演了什么角色？⑥系统会与哪些其他系统相关联？
2：什么是用例？如何确定系统的用例？
答：用例是对一组序列动作的描述，系统执行这些动作将对用例的参与者产生可以观察的结果。
可以根据下面的一些问题来识别用例：
①参与者希望系统提供什么功能；
②系统是否存储和检索信息；
③当系统改变状态时，是否通知参与者；
④是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件。
3：用例之间有哪些关系？对每一种关系，请举出一个实际的例子，并画出用例图。
答：用例之间有包含(include)、扩展(extend)和泛化(generalization)这三种关系。
具体实例和具体用例图见课本。
扩展练习
 找出学生管理系统中的基本角色和用例。
学生问题汇总
（注：汇总学生在学习过程中容易出现的问题）
教学后记
本节重点介绍UML语言的用例图，要求学生能够掌握UML用例，角色的概念。在分析用例和角色时引入了较多的例子，学生能较好的分析出描述中的用例和角色。
本节的难点是用例之间的关系。学生对扩展用例，基本用例的概念区别上存在混淆的现象。利用借书实例讲解后能够掌握。
学生能独立完成本节的任务解决。
|教案下载|
|课件下载|
|
