随着网站的发展，我们团队负责的网上论坛系统已经不堪重负，我们头决定重写该系统。由于这套系统以前没有写usecase文档，所以安排我根据目前网上的功能写出这套系统的usecase。
以下是我在写usecase的时候自己的一些感想，我觉得写出来一个是留个记录，其二也算是一个总结笔记吧（做笔记是我的习惯 ）。
一、UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。
Use Cases本身是用户或其它系统与正在设计的系统的一个交互。这里我觉得要重点领会“功能”和“交互”这两个词。
二、如何写好use case？
（1）写Use Case的时候，要把自己想象是一个用户进入这个系统，与系统交互，Use Case尽量少地提及UI，除非这个UI与功能有关。
（2）把握住系统的actor, 有哪些actor，系统提供哪些功能。
actor 是独立于系统之外的；
actor 是使用系统提供的功能。
（3）Use Case本身是高聚合的，Use Case之间应该是低耦合，也就是说描述一个Use Case的时候要集中描述这个Use Case的功能，不要把其他Use Case做的事情牵扯进来。
重要的是保持每个用例粒度小，功能单一，不要把与该用例功能无关的东西也牵扯到该用例中。
（4）注重Use Case本身的描述，对Use Case之间的关系不必太关注。
不要把重点放在用例之间的关系上（到底是包含还是扩展,泛化），这些无论对你的用例还是对于系统的了解，都无多大价值。
（5）如何描述Use Case的一个步骤？
要把握好“度”：
比如下面的话，有三种描述。
a.用户输入信息
b.用户输入用户名和密码
c.用户在编辑框输入用户名和密码
很显然b是最恰当的。
（6）Use Case要明确开始和结束
三、CRUD操作的问题
CRUD操作是放在一个Use Case中作为分支路径，还是作为一个独立的usecase，我的看法是取决于这个CRUD逻辑上是否是比较复杂，如果逻辑上比较简单，放在一个usecase中会比较好，显得紧凑。
四、扩展事件流用在对一些异常情况、选择分支进行描述。
当有条件判断的时候，表述上采用系统检验到...，不要使用“如果”等字词。
同时选择一个条件分支作为Use Case的主路径，其他的条件分支放在扩展事件流中。
|
本类阅读TOP10