参考《UML面向对象系统分析与设计教程》
第四章 用例图
一 在获取用例前要先确定系统的活动者，系统分析人员可以根据以下一些问题来寻找系统的活动者。
系统的主要客户是谁
谁从该系统获取信息
谁向系统提供信息
谁来安装、操作该系统
谁来关闭该系统
在预定的时刻，是否有时间自动发生
谁使用或删除系统中的信息
系统从何处获得信息
一般的确定活动者应首先确定系统的范围和边界，并从应用的角度考虑系统的作用，确定将有哪些外部事物与系统进行交互。
二 用例（Use Case）是对一个活动者（参与者）使用系统的一项功能是所进行的交互过程的一个文字描述序列。
用例（Use Case）是对系统的用户需求（主要是功能需求）的描述，Use Case表达了系统的功能和所提供的服务
Use Case描述活动者与系统交互中的对话，这种对话表达了活动者与系统的交互的一系列步骤。
Use Case只描述活动者和系统在交互过程中做些什么，并不描述怎么做。
一个活动者可以运行多个Use Case，而一个Use Case可以有多个活动者运行它。但是，也有的Use Case很难有与它明确关联的活动者。
三 用例之间联系
泛化联系
当系统中具有一个或多个用例是较一般用例的特化时，就使用用例泛化。
使用联系
使用联系是指一个用例使用另一个用例的功能行为。使用联系是一种泛化联系，如下例子中，用例“删除教师”和用例“查找教师”之间、用例“更新教师”和“查找教师”之间存在着使用联系，在更新和删除教师信息之前，必须要首先找出要处理的教师。
包含联系
包含联系是一种依赖联系，指一个基本用例的行为包括了另一个用例的行为。
扩展联系
扩展联系是把新行为插入到已有用例的方法。基础用例必须申明若干“扩展点”，而扩展用例只能在这些扩展点上增加新的行为。如下用例图，基础用例是“还书”。如果借阅人所借图书超期，按规定应缴纳一定数额的罚金，这时就不能执行用例提供的常规动作。如果更改“还书”用例，必然会增加系统的复杂性。因此可以在还书用例中增加扩展点，特定条件是超期，如果满足特定条件，将执行扩展用例“缴纳罚金”，这样显然能使系统更容易被理解。
四 用例建模
前面已经说过，用例图（Use Case图）是一种描述Use Case 的可视化工具，它用简单的图形元素表示出系统的活动者、Use Case及他们之间的关系，准确地表达了活动者与系统的交互情况和系统所能提供的服务。建立用例图一般可以按照以下步骤进行。
确定系统的边界和范围，明确系统外部的活动者和外部系统。
确定每个活动者所期望的系统行为。
把这些系统行为作为系统的用例（Use Case）。
把公共的系统行为分解为新的用例，供其他用例引用。把变更的行为分解为扩展用例。
编制每一个用例的剧本。
绘制用例图。
区分主业务流和异常情况的事件流。可以把表达异常情况的事件流的用例画成一个单独的子用例图。
精化用例图。解决用例图的重复与冲突问题，简化用例中的对话序列。高层次的用例可以分解为若干下属子系统中的用例。
五 用例建模中应注意的问题（截取一些）
用例应简单明了，具有较强的可读性。在建模时一个使用例尽可能简短但要切中要点，用动词短语命名用例。
应该用文本和其他UML图来描述用例是如何启动和停止的。
应从活动者的角度并以主动语态编写用例。一方面，应该尽可能以主动语态而不是被动语态来编写用例；另一方面，用例是用来描述用户如何和系统进行交互的，故应尽可能从活动者的角度来编写用例。
用例只记载行为需求，用例既不是类的规约，也不是数据部规约。
应始终如一地组织用例图。一般的做法是垂直地绘制继承和扩展联系，水平地绘制包含联系。
应让用例带动用户文档。
应让用例带动演示。
用例应对系统的作用域、系统所提供的功能以及为支撑这些功能所必须依赖的元素进行定义。
六 小结
用例图是从用户的角度而不是开发者的角度来描述对软件产品的需求，分析产品所需的功能和动态行为的。
活动者是系统外部的一个实体（可以是任何的事物或人），它以某种方式参与了用例的执行过程。
用例是对一个活动者使用系统的一项功能时所进行的交互过程的一个文字描述序列。用例之间可以存在一定的联系，这些联系包括泛化联系，使用联系，包含联系，扩展联系等。
转载于:https://blog.51cto.com/10750710/1738286
216
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
