UML--核心元素之用例

Use case

一个系统就是由各种各样的愿望组成的。

一个用例就是与参与者actor交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。

例如你想做一顿饭吃，你需要完成煮饭和炒菜两件事情，这两件事情就是两个用例。

一个完整的用例是有参与者、前置条件、场景、后置条件构成的。

米---前置条件

电饭煲---场景一

蒸笼---场景二

米饭---后置条件

这就是一个用例的构成。

 

用例本质体现了参与者的愿望，不能完整达到参与者愿望的不能称为用例。如果目的是取到钱，那么取钱是一个有效的用例，填写取款单却不是。

用例必须有参与者发起。

用例必然是动宾短语形式出现的。比如喝水是一个有效的用例。而“喝”却不是。

用例是一个需求单元。

 

用例的粒度。

比如ATM取钱的场景，取钱、读卡、验证账号、打印回执单都是可能的用例，显然，取钱包含了后续动作。取钱的粒度要大些。

让业务代表从他自己的本职工作出发来谈谈他的期望，

可以问：

1.您对系统有什么期望？

我们期望，系统可以对老师信息进行管理，包括基本信息，工资信息等等。

我们期望，系统可以对学生信息进行管理，包括基本信息，健康信息，听力信息等等。

我们期望，系统可以对教务信息进行管理，包括教学计划、学生学籍、课表编排、学生成绩、教学考评、毕业处理、教材管理等方面。

2.您打算在这个系统里做些什么事情？

管理老师信息。

管理学生信息。

管理教务信息。

管理学校信息等。

 

3.您做这件事的目的是什么？

更好的管理学校的信息。

 

4.您做完这件事希望有一个什么样的结果？

希望可以实现这些信息管理，给学校、老师和同学们带来方便。

 

简单地用纸和笔记录下业务代表的访谈结果，从结果中找出用例。

经常地，头一两次的访谈可能没有那么顺利。基于客户不熟悉这种访谈形式以及需求采集人员不熟悉客户业务的原因，开始时采集到的信息可能不足以得出用例。

这样，可以考虑重新进行访谈。

 

功能和用例的区别：

举个例子。从功能的角度出发，对电视的描述是能开关，能显示。可以调频道。可以调声音。

从用例的角度出发，对电视的描述是有个人要看电视节目。要完成这个用例，第一步需要先打开开关，调到自己喜欢的频道，如果声音不合适，可以调节一下。

读者可以细细品味一下这其中的区别。

 

 

业务用例

myself：一切围绕公司项目来学习，来进行认识，相应的技能的学习等等。做好自己的工作，才有资格加薪。

 

业务用例是用于描述客户现有业务的，它的参与者是业务主角。如果说用例是用来获取功能性需求的，那么可以说业务用例就是用来获取功能性业务的。业务用例不将计算机包括进来。

业务范围不等于系统范围，不是所有的业务都能够用计算机来实现的。不在计算机中实现的业务就可以不进入系统范围。

 

虚线的内容就是业务用例的实现。