UML系列 （六）如何提取用例技术？

          这次做机房系统已经提取过一遍用例图了，但是选取用例不够准备，虽然这次没有什么影响，还是需要学会如何提取用例，这是做系统的第一步。

          提取用例的书和资料很多，讲的都很类似，主要是从角色和系统功能两个角度去考虑，对于我们没有开发经验的初学者来说， 可能面临的问题有两个：一是我们知道了系统功能后，应该怎么确定用例；二是提取用例多少的问题，即粒度问题。如果没有丰富的经验可能会把握不好用例的提取。

          想确定用例，我们必须知道用例的定义，即什么是用例：用例试图概括了用例中角色和系统之间的关系，描述了系统功能需求，角色和系统的交互以及系统的反映。如下面例子：

           用例的粒度问题，也即使不用为Include 和Extend所困扰，如果Include 、extent使用频繁则粒度细，反之，粒度粗。

       include 包含是主用例没有包含其他的辅助用例就不能独立执行，但是主用例可以在没有“扩展”其他辅助用例的情况也可以执行。比如说注册前需要检查验证码，但是不一定会“扩展”发送通知邮件这个用例。

       extent表示一个用例有可能扩展到另外一个用例的功能，用例中的扩展通常暗示一个选择性流程。

       有些公司甚至为了使用例简化，取消了Include 和extent ，这是极端的做饭，显然，不利于用例提取。

       合理把握粒度，需注意以下问题：

 

1. 做用例前，要先弄清楚研究对象是什么，并时刻提醒自己不要偏离主题。不然会发生“患者到医院挂号”，或者“患者到医院信息系统看病”之类的笑话。
2. 只要在形式上能写出符合需求标准的路径、步骤，都可以作为用例。注意，是“可以”，并不是“一定”。
4. 做用例分析时最常犯的错误是：把步骤当作用例。如“取款”用例中的“验证密码”与“扣除帐户金额”，它们是“取款”用例的步骤，而不是其子用例。
5. include的目的是为了复用有价值的步骤集合。形式往往是多个大用例include一个可复用的用例，即“多个老大include一个小弟”。 例如：
6. 用例是否用对了的一个判断标准是：其是否加强了和涉众的联系。如多级审批中，局长乐意跟科长共享一个审批功能吗？ ，又如下面图：
7. 
8. 层次问题的出现常常是因为把研究对象弄错了，或者将系统契约与非契约混在一起。如将医院的职责“强加”给了医院信息系统。
9. 讲究“复用”不是需求要考虑的事情，而是设计要考虑的。高焕堂老师说：需求是收益面，设计是成本面。

           只有正确提取用例，以下的工作才能顺利进行，通过看这篇博客，希望大家学会提取用例！