UseCase用例怎么画_UML用例UseCase的几个理解误区

UseCase用例是什么？看一下官方定义：用例定义了一组用例示例，其中每个示例都是系统所执行的一系列操作。看个UML的用例图：

其他的内容大家都可以网上去找资料，关于use case的内容，我这里只想说一下use case的几个理解上的误区：

 

误区1：用例就是功能点

这是一个很大的误区，也是技术人员容易犯的一个错误。功能点是站在软件开发的角度来说的，而用例是站在用户的角度来说的。获取用例是领域专家干的活，而最后的功能实现是技术专家干的活，不同的角色。所以获取用例的关键就是要站在用户角度看问题。

怎么获得用例？首先确定位于系统边界之外的主角是谁？他的期望和目的是什么？这个期望和回报要求在系统之内。所以，用例是帮助确定系统边界的一个好方法。用例也是获取需求的一个方法。

 

误区2：用例和步骤混淆

举例来说，用户输入密码，要有密码错误提示，并且三次错误自动锁定用户，最后登录成功。“输入密码”是一个步骤，不是用例。整个过程是一个用例：“用户登录”。中间步骤和场景可以有很多。比如输入密码是一个步骤；“要有密码错误提示”这是一个业务需求，不是用例；“并且三次错误自动锁定用户”这是一个业务需求，也不是用例。

用例的特征：有目的，有用户期望，有回报预期。当结果不可定义或不清晰时不能用Use Cases，意思是如果目标成功或目标失败不能有一个明确的定义，那就不是一个用例。举例来说，用户输入密码，这是不是一个用例？用户输入密码的目的是什么？是为了输入密码吗？不是的，是为了登录系统，所以，用户登录是一个用例。

 

误区3：用例的粒度不明

用例的粒度大小要看情况，因地制宜，因时制宜。

因地制宜：一般系统用例10-50个为宜。比较小型系统可以粒度更小一些。

因时制宜：在业务建模阶段，在概念建模阶段，在系统建模阶段都是不同的。在系统建模阶段，用例的粒度是以每个用例能够描述操作者与计算机的一次完整的交互为宜。根据项目的不同阶段，不断缩小边界可以获得更小的粒度用例。一个大的用例还可以include一个小的用例，比如网上下订单是一个用例，修改订单是一个子用例，因为除了用户，管理员可以修改订单，这个子用例有意义。

 

误区4：用例和场景混淆

一个用例的执行是要有前因和后果的（前提是什么，结果会怎么样）；比如，煮饭和炒菜是用例，他们各自都有步骤，各自有好几个场景。比如煮饭，我可以用电饭锅煮，也可以蒸饭，煮饭前要先淘米，等等，这些都是一个用例的不同场景，但用户的最终目的都是一样的。不要把用例和场景混淆。

 

误区5：软件工程是不是用例驱动？

软件工程是不是用例驱动？需求是重要的，用例是构造需求的好方法。但如果你同时要考虑开发的所有因素包括重用，架构，花费，时间，你就无法仅仅从一个方面来驱动你的项目。好的软件工程是被一系列重要因素所驱动的，而且因素也因不同的公司和项目有着不同的重要程度。这些因素包括: 技术上对于设计的考虑，用户需求，重用，可更改性，系统性能，标准化，日程的安排以及其他的商务驱动。每个项目都有着自己不同的考虑。对于每一种情况，可以精确的说项目被域模型和用例共同驱动。

 

误区6：用例直接推导出设计

不要从用例直接推论出设计。如果这样做，“用例开发”仅仅成为了功能分解的一个借口。用例止于系统接口的边界！用例应该描述参与者使用系统时所遵循的次序，但用例决不说明系统内部采用什么步骤来响应参与者的刺激。

用例是帮助确定系统边界的一个好方法。用例也是获取需求的一个方法。用例也是产生测试用例的好方法。但是，从系统边界、需求、到详细设计还有很长的路要走。比如说，类图，事实上类图和用例图没有对应关系。换句话来说，用例是需求分析时的产物，类（边界类外）的设计期的产物。