Use Case编写建议

原创 2006年06月10日 02:03:00
前一段时间一直在忙于编写用例,这着实让我体味了一把编写好的用例的不易。
用例代表着系统中各个项目相关人员之间就系统的行为所达成的契约。在面向对象的需求分析中,得到系统的功能需求最方便的方式就是识别用例,而且这些用例扮演着很重要的角色(看看RUP吧)。因此我们将着重讨论在作为系统功能性需求的用例,而不涉及其它种类的用例。
也许你应该抽空阅读一下这篇文章《用例建模指南》。你将对用例的编写有一个全面的认识。而下面将给你更详细的建议:
 
1.  用例之间要保持独立。不要让用例之间存在依赖关系和前后顺序。
2.  一个完整的用例必须完整的描述执行结果。基本流和备选流一个都不能少。
3.  在用例中不要描述设计。用例应该着重于what而不是how。比如“系统将结果保存到xml中……”这就掺杂了设计的成分在里面了,也许这样会更好些——“系统保存结果……
4.  在用例中不要涉及GUI。
5.  使用序号和题目来标注用例中的基本流程。
6.  在基本流中不要引用备选流。基本流中引用了备选流,说明基本流的成功执行会受到备选流的影响,这肯定是不合理的。也许你的基本流囊括了太多的东西,也许是你将一个独立的用例塞到了备选流里面。
7.  备选流中要描述是从基本流中哪个步骤或者其它备选流中开始的。
8.  备选流中要描述触发的原因。
9.  不要编写CRUD用例。CRUD即对数据库的读写改查,不建议为每一个操作创建一个用例。而是作为一个用例来写。在基本流中会有类似与例子中的语句:
    系统展示功能给管理员,有新建合同、编辑合同、查询合同、删除合同,管理员选择编辑合同……
而在备选流中,相应的要创建剩余的其它流程:新建合同、查询合同、删除合同……
当然,有些时候将其拆分到单独得用例中是有意义的。比如权限问题的限制。而大多情况下那只会让用例数量剧增,并影响你的心情。
10. 用例中要体现出必要的重复过程。例如“管理员可以重复3-6步骤,直至满意为止”。忽略了这句话可能会影响页面流的设计。
11. 不要编写重复的用例。当两个用例中都有大段的过程重复,也许你应该考虑将其独立出来作为一个include用例(关于include、extend的区别请看RUP之用例间的关系》)。
12. “如果”的使用。先看下面的例子:
            X.X 关闭设计界面
       
如果设计人员未对设计内容进行修改,则系统直接关闭界面;否则保存设计人员修改后的数据并关闭设计界面。
这里面使用如果来判断执行条件。这很类似于程序设计的风格,但是可能难于跟踪、实现和测试。好了,让我们去掉如果的判断:
              X.X 关闭设计界面
             
设计人员未对设计内容进行修改,系统直接关闭界面。
              Y.Y 关闭设计界面并保存修改数据
              系统保存设计人员修改后的设计数据并关闭设计界面。
这就好理解多了,也容易跟踪了,但是你的用例中会多出很多繁琐的流程。
那到底用不用如果语句呢?这还要由你的团队来决策(就上面的例子而言,我更倾向于使用如果语句)。
13. 流程的顺序真的考虑全面了?你想过没有,用户为什么非要在第四步才开始访问数据库,而不是在一开始。如果这是可行的,那你就漏掉了一种场景。而这就可能影响到后续的设计。不要想当然的将它放在第四步,而是在用例中将可选的情况描述清楚。
14. 记得给你的用例分配权重。用例之间没有顺序,但是却存在着优先级。
 
 

Use Case编写建议

转自 http://blog.csdn.net/ai92/archive/2006/06/10/784995.aspx前一段时间一直在忙于编写用例,这着实让我体味了一把编写好的用例的不易。用例代表着系...
  • wanzhongyi
  • wanzhongyi
  • 2010年12月03日 15:52
  • 223

UseCase事件流描述规范

文/fasiondog 整理需求用例的编写规范,分享部分UseCase事件流描述规范。其中,准则5~10、12来自《编写有效用例》([美] Alistair Cockburn 著)一书,其它为自身实践...
  • KongDong
  • KongDong
  • 2014年12月19日 01:08
  • 4142

Use Case Diagram(用例图)——UML

用例图是软件从需求分析到最终实现的第一步,它展示了一个外部用户能够看到的系统功能模型图。帮助团队以一种可视化的方式理解系统的功能需求。   理论篇                   用例图...
  • liutengteng130
  • liutengteng130
  • 2012年11月28日 10:10
  • 7192

使用实例(usecase)和功能需求

    使用实例的描述并不向开发者提供他们所要开发的功能的细节。如果你在用户需求阶段停止了需求开发,你将会发现在软件的构造阶段,开发者必须询问许多问题来弥补他们的信息空白。为了减少这种不确定性,你需要...
  • qiang_gu
  • qiang_gu
  • 2004年11月22日 16:45
  • 1209

UsecaseDiagram中的include和extend比较

本文和大家重点讨论一下UML用例图中include与extend的区别,include是指用例中的包含关系,通常发生在多个用例中,有可以提取出来的公共部分,而extend则恰好相反。下面请看本文详细介...
  • liushui102
  • liushui102
  • 2010年12月20日 14:37
  • 1851

用例图(UseCase Diagram)—UML图(一)

一.       从上面的用例图模型,我们可以大致了解用例图所描述的是什么。下面进行详细介绍。         用例图,即用来描述什么角色通过某某系统能做什么事情...
  • yuexianchang
  • yuexianchang
  • 2016年11月25日 08:59
  • 3987

Use Case中的include, extend和generalization

  画用例图时用例之间的关系应该是一个比较难理解的概念,用例之间的关系分为include, extend和generalization三种。  先介绍一下比较容易理解的generalization,g...
  • sunshinestation
  • sunshinestation
  • 2009年07月15日 16:14
  • 3658

编写有效用例实例Writing effective Use Case Examples

Writing effective Use Case Examples编写有效用例实例A great way for writing effective use cases is to walk th...
  • lanmao100
  • lanmao100
  • 2009年04月21日 19:24
  • 3017

设计阶段如何画用例图(Use-Case Diagram)

一、概述 用例试图描概括了用例中角色和系统之间的关系,描述了系统功能需求,角色和系统的交互以及系统的反应。       会员具有浏览商品类别、根据关键字产讯商品和选择商品加入...
  • qq51931373
  • qq51931373
  • 2013年12月25日 15:39
  • 2057

非常有用的User case用例描述模板

Table 6.0 Use...
  • CompassButton
  • CompassButton
  • 2006年08月04日 17:04
  • 4206
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Use Case编写建议
举报原因:
原因补充:

(最多只允许输入30个字)