Seven's Pad

Just another Product Blog site

Posts Tagged ‘UML

UML核心元素之用例

leave a comment »

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

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

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

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

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

用例的构成

用例的特征

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

用例是相对独立的

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

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

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

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

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

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

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

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

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

用例的粒度

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

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

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

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

用例的获得

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

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

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

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

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

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

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

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

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

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

Written by sevenpad

06/20/2010 at 3:11 下午

发表在 产品相关

Tagged with , ,

UML核心元素之参与者

leave a comment »

参与者(actor)在建模过程中是处于核心地位的。UML官方文档对参与者的定义为:actor是在系统之外与系统交互的某人或某物。系统之外的定义说明在参与者和系统之间有一个明确的边界,参与者只可能存在于边界之外,边界之内的所有人和事物都不是参与者。

按照定义,要弄明白谁是参与者首先要弄明白系统的边界。但有时系统边界是不明确的,如何确定系统之外和系统之内呢,可以通过回答正面两个问题来找出参与者从而确定边界:

  1. 谁对系统有着明确的目标和要求并且主动发出动作?
  2. 系统是为谁服务的?

实际上在官方文档中,参与者还有另外一种叫法:主角。系统之内的人“参与”业务,被称之为业务工人。

参与者可以非人

任何需求都必须至少有一个启动者,如果找不到启动者,那么可以肯定地说这不是一个功能性需求。

如何发现参与者

参与者的一个重要来源是涉众,从涉众中找出那些直接对系统发出动作,或直接从系统中接收反馈的涉众,若无一个好的涉众分析作参考,那么参与者的另一个可参考来源是客户的岗位设置。如果客户的岗位设置还不足以搞清楚参与者,那么需要做的是与客户代表访谈,并为他假定一个参与者,列出他在系统中要做的事情;再与另一些客户代表访谈,假定其他的参与者和其他客户在系统中要做的事情。通过分析这些假定的参与者在系统中要做的事情,找出共同性,并与客户敲定。

在查找参与者的过程中,可以询问以下问题以帮助确定参者:

  • 谁负责提供、使用或删除信息?
  • 谁将使用些功能?
  • 谁对某个特定功能感兴趣?
  • 在组织中的什么地方使用系统?
  • 谁负责支持和维护系统?
  • 系统有哪些外部资源?
  • 其他还有哪些系统将需要与该系统进行交互?

查找参与者时需要注意的是参与者一定是直接并且主动地向系统发出动作并获得反馈的,否则就不是参与者。

业务主角

业务主角(business actor)是参与者的一个版型,特别用于定义业务的参与者,在需求阶段使用。业务主角是与业务系统有着交互的人和事物,他们用来确定业务范围(注:在软件项目里,业务范围和系统范围是不同的。业务范围反映这个项目所涉及的所有客户业务,这些业务有没有计算机系统参与都客观存在。系统范围则是反映软件将要的那些对应于业务功能的系统功能从功能性需求来说系统范围是业务范围的一个子集。但是一些系统功能则会走出业务范围,例如担任日志。有没有操作日志并不影响目标的达成,客户也不一定会提出这个要求,但从系统角度出发,操作日志会使得系统更加健壮)。业务主角是参与者的一个版型,所以业务主角必须遵守参与者的所有定义。

业务主角的特殊性在于,它针对的是业务人员而计算机用户。在查找业务主角时必须抛开计算机,没有计算机系统这些业务人员也客观存在,在引入计算机系统之前他们的也一直跑得很顺畅。这是因为在初始需求阶段,我们需要获得的是客户的业务模型,根据业务模型才能建立计算机模型。如果在了解业务阶阶段就引入计算机的概念,将会混淆现有业务和将来有计算机参与时的业务。请记住,要建立一个符合客户需要的计算机系统,首要条件是完全彻底地搞清楚客户的业务,而不是预先假设已经有了一个计算机系统,再让客户来假想需要计算机帮他们做什么。

在初始需求阶段,请务必使用业务主角,时时牢记业务主角是客户实际业务里的参与者,而没有计算机系统,没有抽象的计算机角色。业务主角必须在实际业务里能找到对应的岗位或人员。如果你对获得的业务主角不是很自信,请回答以下问题:

  • 业务主角的名称是否是客户的业务术语?
  • 业务主角的职责是否在客户的岗位手册里有对应的定义?
  • 业务主角的业务用例是否都是客户的业务术语?
  • 客户是否对业务主角能顺利理解?

业务工人

业务工人(business worker)处于系统边界之内且确实参与了业务的执行过程。

作为配角,他们的工作就是完成主角的业务目标,只在主角的业务模型中出现,经常出现的地方是领域模型和用例场景。缺少了他们的业务场景就不完整,甚至不能 运行。只有主角没有配角的戏没法演。可通过下面三个问题帮助澄清:

  • 他是主动向系统发出动作的吗?
  • 他有完整的业务目标吗?
  • 系统是为他服务的吗?

这三个问题如果是否定的。那一定是业务工人。

参与者与涉众的关系

涉众(stakeholder),也称为干系人。涉众是与要建设的这个系统有利益相关的一切人和事,涉众的利益要求会影响系统的建设。只要和这个系统有利益关系的都是这个项目的涉众。涉众虽然与这个系统有利益相关,但并不是所有的涉众都是系统的参与者。

参与者是涉众代表。参与者对系统的要求直接影响系统的建设,他们的要求就是系统需求的来源。参与者通过对系统提出要求来获得他所代表的涉众的利益。

参与者与用户的关系

用户(user)是指系统的使用者,通俗一点说就是系统的操作员,用户是参与者的代表,或者说是参与者的实例或代理。并非所有的参与者都是用户,但是一个用户可以代理多个参与者。

参与者与角色的关系

角色(role)是参与者的职责。角色是一个抽象的概念,从众多参与者的职责中抽象出相同的那一部分,将其命名而形成一个角色。一个角色代表了系统中的一类职责。另外由于一个用户可以代理多个参与者,因此一个用户可以拥有多个职责,也就是可以被指定多个角色。

参与者的核心地位

从上面的描述中可得知,参与者是涉众的代表,它代表涉众对系统的复兴要求,并向系统提出建设要求;参与者通过代理给其他用户或将自身实例化成用户来使用系统;参与者的职责可以用角色来归纳,用户被指定扮演哪个角色因此来获得参与者的职责。

检查点

  • 是否您已找到所有的参与者?也就是说,是否您已经对系统环境中的所有角色都进行了说明和建模?这个得要到找到并说明了所有用例之后才能将其确定。
  • 每个参与者是否至少涉及到一个用例?删除未在用例说明中提及的所有参与者,或与用例无通信关系的甩有参与者。
  • 能否列出至少两名可以作为特定参与者的人员?如果不能,请检查参与者所建模的角色是否为另一个角色的一部分。如果是这样,应该将该参与者与另一参与者合并。是否有参与者担任与系统相关的相似角色?如果有,应该将他们合并到一个主角中,通信关联关系和用例说明参与者和系统是如何相互关联关系的。
  • 是否有两个参与者担任与用例相关的同一角色?如果有,您应该利用参与者泛化关系来为他们的共享行为建立模型。
    特定的参与者是否将以几种(完全不同的)方式使用系统?或者,他使用用例是否出于几个(完全不同的)目的?如果是这样,您也就应该有多个参与者。
  • 参与者是否有直观名称和描述性名称?用户和客户是否都能理解这些名称?参与者的名称要与其角色相符,否则应该对其进行更改。

Written by sevenpad

06/18/2010 at 10:38 下午

发表在 产品相关

Tagged with , ,

初识UML

leave a comment »

UML是什么?百度知道是如此解释的:UML是统一建模语言(UML是 Unified Modeling Language的缩写)是用来对软件密集系统进行可视化建模的一种语言。UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。作为一种模型语言,它使开发人员专注于建立产品的模型和结构,而不是选用什么程序语言和算法实现。当模型建立之后,模型可以被UML工具转化成指定的程序语言代码。形象地说即UML是把现实世界映射到对象世界的方法、从对象世界描述现实世界的方法、验证对象世界行为是否正确反映了现实世界的方法。

讲到面向对象的分析方法,在这里就不得不介绍面向过得的分析方法与面各对象的分析方法之间区别所在。面向过程的分析方法:在需求调研时最先弄清楚有多少业务流程,先画出业务流程图,然后顺藤摸瓜,找出业务流程中每个步骤的参与部门或岗位,弄清楚在这一步参与者所做的事情和填写表单的结果,并关心用户是如何把这份表单传给到下一个环节 ;面向对象的分析方法:在调研需求时最先弄清楚有多少部门,多少岗位,然后找到每个岗位的业务代表,问他们类似的问题:你平时都做什么?这件事是谁交办的?做完了你需要通知或传达给谁吗?做这件事情你都需要填写些什么表格吗?…

把现实世界映射到对象世界的第一步.UML采用用例这一关键元素捕获了现实世界的人要做的事,再通过用例场景、领域模型等视图将现实世界的人、事、物、规则这些构成现实世界的元素用UML这种语言描述出来。

UML有三大模型,即业务模型、概念模型和设计模型。

业务模型

现实世界之本质是由人、事、物和规则组成的.人是一切的中心,人要做事,做事就会使用一些物并产生另一些物,同时做事需要遵循一定的规则。人驱动系统,事体现过程,物记录结果,规则是控件。

建立模型的关键在于弄明白有什么人,什么人做什么事,什么事产生佬物,中间有什么规则,再把人、事、物之间的关系定义出来,一个模型就基本成型了。参与者即模型信息来源的提供者,也是第一驱动者。换句话说,要建立的模型的意义完全被参与者决定,所建立的模型也是完全为参与者服务的,参与者是整个建模过程的中心。用例作为一种元模型来表示驱动者的业务目标,也就是参与者想要做什么并且获得什么。这个业务目标(现实世界中的"事")是怎么做的,依据什么规则,则通过被称之为业务场景和用例场景的UML视图来描绘的,这些场景便是现实世界中的"规则"。

最后,UML通过被称之为业务对象模型的视图来说明在达成这些业务目标的过程中涉及到的事物,用逻辑概念来表示他们,并定义它们之间的关系。业务对象模型则代表了现实世界中的"物"。

概念模型

当业务模型用分析类来描述的时候,我们实际上已经采用了对象视角。用例所代表的现实的业务过程,被"边界" 、"控制" 、"实体"以及"包" 、"组件"等概念替代。从业务模型到概念模型这一过程,正是我们需要的一种从对象世界来描述现实世界的方法。

绘制分析模型最主要的元模型有:

  • 边界类 boundary
    边界决定了外面能对里面做什么"事"
  • 实体类 entity
    原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物,UML采用实体类来重新表达业务实体;
  • 控制类 control
    边界和实体都是静态的,本身不会动作.UML采用控制类来表述原始需求中的动态信息,即业务或用例场景中的步骤和活动。

从UML的观点看,边界类和实体类之间,边界类和边界类之间,实体类和实体类之间不能够直接相互访问,它们需要通过控制类来代理访问要求,把动作和物体分开。

设计模型

在设计模型中,概念模型中的边界类可以被转化为操作界面或者系统接口;控制类可以被转化为计算程序或控制程序,例如工作流 算法体等;实体类可以转化为数据库表 XML文档或者其他带有持久化特征的类。

Written by sevenpad

06/18/2010 at 4:02 下午

发表在 产品相关

Tagged with , ,