首先,让我们仔细研究一下用例的定义:
一个用例抽象了目标系统在现实中将执行的一组场景(每个场景由一系列动作组成);这些场景会产生一个对某个Actor有价值的、可观测的结果;
在这个定义中,我们强调了两件事情:一、用例是被从现实的场景中抽象出来的,而不是被随便发明出来的;二、每个用例(场景)应能提供完整的商业价值。在未来的博文里会介绍这两条会如何帮助我们避免对用例的误用。
用例的优势在于它天生是黑盒的,它用自然语言抽象了用户和目标系统的交互,避免了混入分析、设计和实现细节,以保证用例可以被不懂具体技术的业务及测试人员所真正理解。同时,需求分析员又可以方便地通过用例分析(use case analysis)(即用分析类来试图在理想方式下实现用例),将需求体系精华成分析模型。在这一过程中,需求分析员可以更进一步地完善基于用例的需求体系,而不必担心分析模型会污染需求,从而实现需求与分析的分离及有效互动。
最后,我们必须指出,基于用例的需求管理体系中不仅仅包含用例,它还应该包括涉众请求,特性列表,前景文档,补充规约,词汇表等等。
用例其实是Ivar在许多年前发明的老技术了,现在被很多人所采用,而被更多人误用,下面的文章让我们看看一些对用例的典型的误解和误用
用例是一个门槛很低的技术,任何人都可以随便画几个小人和几个椭圆,然后向全世界宣称我在用用例进行需求建模了,但是好像也没有真正解决我的问题。在这种情况下,用例技术很可能被误用了。在对用例不同类型的误用之中,最严重、最普遍的莫过于利用用例来进行功能分解了。刚在为了偷懒,想找张现成的错误使用用例的例子,结果找的了2001年Kurt写的在这方面的文章以及最近一位老兄在CSDN上给出的翻译(已经收藏在我的网摘里)。Kurt对这个问题的阐述已经相当清楚了,我也就不多写了,大家去看我的网摘或原文吧!
作为总结,可以记住这样两句话:
1、Login往往不是一个好的用例;
2、用例是不会互相调用的;
英文原文:
中文翻译:
http://blog.csdn.net/soaringbird/archive/2007/03/28/1544093.aspx
最近在与用户的沟通过程中,发现用户经常会认为用例是一种基于图形描述或UML的方法,从而质疑用例是否能够有足够的描述能力,或者用例是否易于被业务人员理解。其实,这是对用例的另一种典型的误解。
在用例模型中,的确会用到一些UML的图符(一个小人代表Actor,一个椭圆代表Use Case,等等),但这些图符是非常容易理解的。而且用例的主要信息是在需求规约当中,用例模型传递的信息可能只占所有相关需求信息的5%。
所以,我建议,大家可以粗略地认为用例与UML基本无关,它主要是一种基于文本的结构化地书写需求的方式。
用例的粒度问题一直是困扰着需求分析员的常见问题,对于这个问题,抱歉,没有银弹,我只能给出一些解决这个问题的基本原则:
1. 控制用例的总体数量:一般来说,一个相当复杂的系统的用例数量可能在30-50个之间,如果一个系统的用例数量大大超过了这一范围,那就该看看是不是陷入了功能分解的误区;
2. 高内聚、低耦合:用例是一种结构化写作需求的技术,用例是被从现实的场景中抽象出来的。如果这些场景有紧密的联系(高内聚),那用用例技术来组织它们则可以复用这些场景中的步骤描述,从而达到事倍功半的效果;
3. 写写看:很多时候在初步规划用例模型的阶段,有时很难判断一个用例的粒度是否合适,不要执迷于一次获得一个完美的用例模型和用例粒度。不妨先得出一个初稿,然后写写用例,看看是不是符合高内聚、低耦合的原则,实际上在写用例的过程中,用例模型往往是需要不断进行调整的;
4. 避免功能分解:功能分解是正确使用用例技术的最大敌人,很多用例粒度的讨论其实都是功能分解的思想在作怪。
目前大多数用户的开发都是对现有系统的升级和改造,在这样的情况下还能使用用例技术吗?很幸运答案是肯定的,你可以按照以下步骤进行:
1. 确定系统边界:通过标识Actor来定义系统边界;
2. 重构用例模型:简要地捕获和描述现有系统的用例模型;
3. 扩展用例模型补充用例规约:根据系统的升级和改造要求,增加新的用例或对已有用例进行扩展;在对现有用例进行扩展之前,则需要补充用例的基本事件流和涉及到的备选流,在以它们为基础来对描述需要的新行为;
这样,就可以在对现有系统的改造过程中,逐步地重构整个系统的用例模型和用例描述。