Seven's Pad

Just another Product Blog site

UML核心元素之用例

leave a comment »

用例(Use Case)在官方文档中是这样定义的:用例定义了一组用例实例,其中每个实例都是系统所执行的一系统操作,这些操作生成特定主角可以观测的值。

用例在UML建模中是最最重要的一个元素,之所以说它重要,是因为UML是面向对象的,除用例之外,所有其他元素都是"封装"的、"独立“的。

用例是一种把现实世界的需求捕获下来的方法。各种各样的人为着各自的目的做着各种各样的事情共同组成了一个系统。如果我们要描述一个系统的功能性需求,就要找到对这个系统有愿望的人,让他们来说明他们会在这个系统里做什么,想要什么结果。如果所有对系统有愿望的人要做的所有事情都找全了,那这个系统的功能性就被确定下来了。

所谓用例,就是一件事情,要完成为件事情,需要做做一系列的活动;而做一件事情可以有很多不同的办法和步骤,也可能会遇到各种各样的意外情况,因些这件事情是由很多不同情况的集合构成的,在UML中称之为用例场景。一个场景就是一个用例的实例。

要启动用例是有条件的,要做饭,首先得要有米。这是启动用例的前提,也称为前置条件;用例执行完了,会有一个结果,米变成了饭。这称为后置条件。一个完整的用例定义由参与者、前置条件、场景、后置条件构成。

用例的构成

用例的特征

用例有着一系统的特征。这些特征保证用例能够正确地捕捉功能性需求,同时这些特征也是判断用例是否准确的依据。

用例是相对独立的

意味着它不需要与其他用例交互而独自完成参与者的目的。也就是说用例从“功能”上是完备的。用例本质体现了系统参与者的愿望,不能完整达到参与者愿望的不能称为用例。

用例的执行结果对参与者来说是可观测的和有意义的

例如,有一个后台进程监控参与者在系统里的操作,并在参与者删除数据之前执行备份操作。虽说它是系统的一个必需组成部分,但它在需求阶段却不应该作为用例出现。因为这是一个后台进程,对参与者来说是不可观测的,它应该作为系统需求在补充规约中定义而不是一个用户需求。

这件事必须由一个参与者发起。不存在没有参与者的用例,用例不应该自动启动,也不说文主动启动另一个用例。

用例总是由一个参与者发起的,参与者的愿望是这个用例存在的原因。

用例必然是以动宾短语形式出现的

用例必须有一个动作和动作的受体。

一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元,甚至部署单元

一旦决定了用例,开发工作的其他活动都以这个用例为基础,围绕着它进行。即以用例作驱动。

用例的粒度

粒度是令人困惑的。到底是一个大的用例合适还是分解成多个小用例合适呢?这个问题并没有一个标准的规则,笔者可以给大家分享的经验是在项目过程中根据阶段不同,使用不同的粒度。在业务建模阶段,用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。

在用例分析阶段,即概念建模阶段,用例的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。需要注意的是,这个阶段需要采用一些面向对象的方法,归纳和抽象出业务用例中的关键概念模型并为之建模。

在系统建模阶段,用例视角是针对计算机的,因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。实际上,用例粒度的划分依据(尤其是业务用例)最标准的方法是以该用例是否完成了参与者的某个完整目的为依据的,请记住一点,用例分析是以参与者为中心的,因此用例的粒度以能完成参与者目的为依据。现实情况中,一个大型系统和一个很小的系统用例粒度选择会有较大差异。这种差异是为了适应不同的需求范围,一般来说,一个系统的业务用例定义在多于10个,少于50个之间,否则就应该考虑一下粒度选择是否合适了。

当然不论粒度如何选择,必须把握的原则是在同一个需求阶段,所有用例的粒度应该是同一个量级的。另外还需要澄清一个观点,粒度选择的问题本质上还是因为边界认定不同而产生的。如果对选择粒度感到困难,或者出现了同一个阶段粒度大小不一的情况,则应当首先确认是否选择了一个正确的边界并时时检查自己是否越过了这个边界。

用例的获得

我们知道用例的定义就是由参与者驱动的,并且给参与者提供可观测的有意义的结果的一系列活动的集合,用例的来源就是参与者对系统的期望。所以发现用例的前提条件是发现参与者;而确定参考者的同时就确定了系统边界。在开妈捕获用例之前,我们需要做好准备工作;即确定参与者和系统边界。

在准备发现用例之前,再强调并确认你已经能够清楚地理解了下面几个问题:

  • 参与者是位于系统边界之外的;
  • 参与者对系统有着明确的期望和明确的回报要求;
  • 参与者的期望和回报要求在系统边界之内;

接下来,可以开始对参与者或业务代表进行访谈。访谈时请不要试图让业务代表为你描述整个业务流程,也不要涉及表单填写一类的业务细节,甚至你可以不关心业务规则,更不要试图让业务代表理解将来的计算机系统会如何工作。你只需要让业务代表从他自己的本职工作出发来谈谈他的期望,并时时提醒和引导那些喜欢一讲什么事情就深入到细节的客户。可以通过以下问题引导业务代表,这些问题对用例的获取来说已经足够了。

  • 您对系统有什么期望:
  • 您打算在这个系统里做什么事情?
  • 您做这件事情的目的是什么?
  • 您做完这件事希望有一个什么样的结果?

简单地用纸和笔记录下业务代表的访谈结果,从结果中找出用例。你应当清楚,业务代表想做的和要做的事情不一定是他真实的目标,也许只是他做事情的一个步骤。总之,你应当确保:

  • 一个明确的有效的目标才是一个用例的来源;
  • 一个真实的目标应该完备地表达业务代表的期望;
  • 一个有效的目标应当在系统边界内,由参与者者发动并且有明确的后果。

基于客户不熟悉这种访谈形式以及需求采集人员不熟悉客户业务的原因,开始采集到的信息可能并不足以得出用例。或者获得了用例,在用这些用例来建立业务模型的时候总遇到困难和矛盾,发现有些业务总是说不清楚,那么应当考虑重新进行访谈。在重新开始访谈以前,你应当考虑调整以下策略:

  • 调整系统边界和主角;
  • 扩大或缩小系统边界;
  • 变更业务代表;
  • 然后,重新开始。

经过几次调整之后 ,系统边界内应该已经充满了业务代表的期望,将每一个有效的期望用用例绘制出来,并给一个合适的名字就完成了用例获取的工作。

Advertisements

Written by sevenpad

06/20/2010 在 3:11 下午

发表在 产品相关

Tagged with , ,

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s

%d 博主赞过: