◆用户能够依据系统须求团结创造版型,而做一件事情能够有无数不一样的办法和步骤

何以是用例

用例在UML建立模型中是最重视的二个因素。幸好用例使得其他那3个“孤立”的UML成分能够联手组成一篇有意义的文字。因此没有精确的用例定义一切都无从谈起。

不过用例却又是最麻烦精通的,除了本身的好多属性难于上学以外,在实践进度中什么运用更为令人摸不着方向。

所谓用例,便是一件事情,要做到那件工作,加入者须求做一文山会海的移位。而做一件业务能够有广大不等的章程和手续,也说不定会遇到各样各种的竟然情状,因而这件工作是由许多不一样处境的聚众构成的,在UML中称之为用例场景。3个光景就是一个用例的实例。

诸如想做一顿饭吃,需求形成煮饭和炒菜两件业务,那两件工作便是五个用例。而起火这件业务是能够有两样的做法,可以用电饭锅,也足以用蒸笼做,那正是三种差别的气象,也便是四个实例。而同一是用电锅做,借使是糯米,大概要先淘米,再下锅;倘诺是精米,就足以节约淘米步骤直接下锅。那就是用例在差异口径下的不等处理场景。

要运营用例是有规则的,要做饭,首先得要有米。那是运维用例的前提,也称为前置条件;用例执行完了,会有1个结实,米变成了饭。那称为前置条件。

总结,一个整机的用例定义由参预者、前置条件、场景、前置条件构成。

三个种类的功用性是由局地对系统有愿望的参加者要做的局地作业结合的,事情完了后就完成了出席者的多个希望,当全体参预者的装有希望都能够透过用例来完毕,那么这一个体系就被明显下来了。捕捉功效性须求,正是用例的效益。

3.1 版型

         
◆版型是UML中的多个概念,也叫作类型、构造型。版型是对UML中基础成分赋予贰个破例的意义,使得那一个因素得以描述特定的场子。

         
◆例如类有接口、边界类、实体类、控制类等版型。

         
◆用户可以依照系统供给自身创制版型,例如工作组、文档等。

用例的特征

用例有着一密密麻麻的特色。那几个特色有限支撑用例能够科学地捕捉功效性须要,同时那个特征也是判定用例是还是不是确切的依照。

  • 用例是周旋独立的。不须求与任何用例交互而独自完毕参与者的指标。也就是说用例从“作用”上实属完备的。用例本质显示了系统参预者的心愿,不能够全体达到参预者愿望的不可能称之为用例。例如取钱是1个灵光的用例,填写取款单却不是。
  • 用例的实施结果对参加者来说是可观看的和有意义的。比如,有三个后台进度监察和控制参与者在系统中的操作,不应当作为用例出现;登陆系统是二个实惠的用例,但输入密码却不是。
  • 那件事必须由八个到场者发起。不存在尚未参与者的用例,用例不应有自行运转,也不应当积极运营另1个用例。用例总是由多少个参预者发起的,到场者的意思是以此用例存在的原由。
  • 用例必然是以动宾短语格局出现的。
  • 3个用例就是多个供给单元、分析单元、设计单元、开发单元、测试单元甚至陈设单元。

3.2 插足者(亦能够成为顶梁柱)

用例的粒度

在作业建立模型阶段,用例的粒度以各样用例能够证实一件完整的事情为宜。即多少个用例能够描述一项完整的业务流程。那将力促明显供给范围。

在用例分析阶段,即概念建立模型阶段,用例的粒度以种种用例能描述三个完整的风浪流为宜。可见道为1个用例描述一项完整业务中的一个步骤。这么些等级采纳部分面向对象的方法,归结和浮泛出事情用例中的关键概念模型并为之建立模型。

在系统建立模型阶段,用例视角是指向总括机的,由此用例的粒度以2个用例可以描述操作者与计算机的1次完整交互为宜。

相似的话,2个系统的思想政治工作用例定义在多于11个,少于四十四个里头,不然就应当考虑一下粒度采纳是还是不是合适了。

任凭粒度咋样挑选,必须把握的准绳是在同多少个急需阶段,全部用例的粒度应该是同2个量级的。此外,粒度选取的题材本质上还是因为边界确认分化而发出的。借使对选择粒度感到困难,或然出现了同1个等级粒度大小不一的意况,应该首先肯定是或不是选取了二个科学的界限,并随时检查本人是不是通过了这些界限。

3.2.1定义:

         ◆定义:系统外部与系统举办交互的人或物

         ◆如何界定系统里面和表面:

           
 a.明确什么人对系统有由此可见的靶子和须求并主动向系统倡导了动作?

             b.系统首借使为哪个人服务

         ◆怎么样分明加入者:

         
a.直接且主动向系统倡导动作并得到反馈的人或物

            eg:
对于1个机票预约系统

               
 >甲某通过机票预约系统购票,甲某是参与者

               
 >贾某打呼叫中央人工座席,令人工座席通过机票预定系统为其订票,则人工坐席是参与者

               
 >贾某通过呼叫中央语音系统访问机票预约系统买票,呼叫中央语音系统是参加者

               
 >将呼叫中央作为机票预定系统的子系统,贾某通过呼叫大旨人工座席/语音系统订票,则贾某是参预者,人工坐席变成了业务工人。

用例的拿走

在预备发现用例此前,确认已经能够清楚理解上面包车型大巴多少个难点:

  • 主角(参与者)是位于系统边界之外的
  • 主角对系统有着鲜明的愿意和显然的回报须要
  • 骨干的只求和回报供给在系统边界之内

接下去,可以开首对支柱举办访谈,只需求让工作代表从她协调的本职工作出发来谈谈他的梦想。能够通过以下问题教导:

  • 你对系统有怎么样期望?
  • 你打算在这一个体系里做什么事情?
  • 您做那件事的指标是什么样?
  • 你做完那件事希望有八个怎么着的结果?

简短地用纸和笔记录下业务代表的访谈结果,从结果中找出用例。

  • 有道是知道,主演想做和要做的事体不肯定是她真正的靶子,大概只是他做政工的一个手续。比如客户大概会说自家第壹做……,然后做……,最终做……,内需从冗长的言语中为客户总括出她的真实目的来;
  • 其它,主演对系统的期待也不自然是二个有效的轩然大波,恐怕的确只是3个愿望,比如客户会说希望界面能非常满意一些,您需求报告客户她的盼望将是一件能够做的业务,而不仅仅是一个莫明其妙意愿。
  • 今非昔比主演对相同指标或然会有分裂的抒发,恐怕正是同一件业务,应当去伪求真,求同存异,而不是简单地就分为多少个用例。
  • 今非昔比主演的对象恐怕会互相重叠,显示出一种交集的情况。有道是小心求证,是不是这几个主演所谈的都只是某些完整指标的一部分?一经那样,应当统百分之十一个用例,并假定那八个支柱在这一个用例中只是担任作业工人的剧中人物而不是当真的骨干。依然这个骨干所谈的是有陆续的一些,但的确是多个例外的靶子。借使如此,应当就是三个用例。至于交集部分,须要在概念模型中去领取公共的业务单元。

总的说来,应道确认保证:

  • 2个明显的实惠的靶子才是三个用例的发源。
  • 一个诚实的指标应该万事俱备地表明主角的指望。
  • 多个有效的靶子应该在系统边界内,由主演发动,并装有鲜明的结果。

当发现有个别工作总是说不清楚,那么应该考虑重新开始展览访谈。在重复起始访谈在此之前,你应有考虑调整以下政策:

  • 调动系统边界和中坚。
  • 壮大或裁减系统边界。
  • 改变主演。
  • 然后,重新发轫。

因而几回调动现在,系统边界内应当已经浸透了主演的梦想,将每二个灵光的愿意用用例绘制出来,并给一个恰如其分的名字就成功了用例获取的办事。

3.2.3 业务骨干

     ◆定义: 业务骨干是插足者的三个版型,是与作业种类开始展览交互的人或物,用来规定业务范围。

      ◆业务范围与系统范围分别:

       
 a.业务范围是本项目涉及的享有客户工作

       
 b.系统范围是指软件将要达成的这几个对应于客户工作的效益,一般是业务范围的子集。

   
  ◆怎样规定工作骨干采用是还是不是科学:

           
a.业务主演的名号和业务用例是还是不是是客户的工作术语

           
b.业务骨干的义务是不是在客户的岗位任务手册中有明显概念

           
c.客户是不是能很不难的敞亮该事务骨干

     
◆开发人士做需要分析职员时易范的谬误:

       
 a.和客户关系进行作业建立模型时,从电脑类别的角度来考虑难题,客户恐怕会因为信任技术职员在微型总计机方面包车型大巴高雅而再工作要求远非描述的

       
 很明亮的前提下承认开发人员对须求的定义与叙述,导致在付出甘休时客户觉得开发的体系不是他俩想要的。

       
 b.和客户联系进行工作建立模型时,主观的在心里中假诺了作业在处理器里的落到实处情势且没能确切的接头客户的实际工作,导致支出出来后客户认

       
 为系统不符合他们的业务流程。

用例和效果的误区

虽说效果和用例很类似,可是从实质上的话作用和用例是截然分裂的。在讲述2个东西的时候,能够从以下多个视角出发:

  • 那是事物是哪些?
  • 那么些事物能做如何?
  • 人们能够用这几个东西做什么样?

率先种描述是一种结构性观点,即事物的客观存在。不过那么些看法不可见证实事物的遵从,也等于功用性方面包车型大巴音信。

第两种描述是一种效用性观点,表明事物可利用的价值。但是那个观点不可见注解事物在某种情况下的的确价值,也便是它贫乏上下文环境,没有人来利用,事物的富有可使用市场股票总值可能是架空的。

其二种面试是一种使用者观点,表达事物对于使用者的意义,以及使用者能够怎么利用它,获得什么的好处。那种意见不能表达事物的真相结构,它只是从外表揭穿了东西相对与使用者来说是怎么,能做如何,能够赢得怎么着。

软件恰恰就是一种还不设有的东西。独白一骢准备付出的软件,不可能从组织观点去描述它,也不能从作用观点去讲述它,最佳的点子便是从使用者的见识去描述它。

使用者观点告诉要求收集人士,他盼望以此连串是哪些,他将何以使用那几个系统,希望获得如何结果。那么软件只需求依照使用者的要求提供贰个贯彻,就不会离开使用者的预料。至于功效性观点和布局性官观点,则能够通过使用者观点推导出来。

使用者观点实际上就是用例的视角。二个用例是叁个参与者怎么样运用系统,得到怎么着结果的贰个晤面,通过分析用例,得出结构性的和成效性的始末,最后完毕用例,也正是完成了使用者的看法。

因此地点的分析能够得出那样有个别总计:

先是,成效是退出使用者的希望而留存。作用用来叙述某某东西能做哪些,它与使用者的意愿非亲非故,描述的是东西本来的品质。习惯于以效益来对待系统的团组织,喜欢从系统的角度出发,表达系统能做什么,而时常系统能做哪些并不是使用者关系的。用例是描述使用者愿望的,描述的是使用者对系统的采取须要,用用例来对待系统协会,则是从使用者角度出发,表达使用者将在系统里做哪些。

第壹,功效是孤立的,给多少个输入,通过测算就有三个永恒的出口。效能描述是贰个个点,倘使要达标三个特定的指标,必须求在附加添加二个顺序的进程把点串起来,才能成就三个系统性的办事。而用例描述的是二个系统性的劳作,这一个系统性的劳作充裕显明地去达到三个一定的靶子。习惯使用功效分解来对待系统的集体,习惯从开发者角度出发,提供多量的功用点。而用用例来对待系统的团伙,习惯从客户角度出发,为客户量身定制他们的渴求。

其三,倘使非要从效率的角度表达用例,那么用例能够解释为一多级成就一个特定指标的“功效”的组合,针对不一样的行使场景,那几个“功用”展示差异的组成格局。并且,不是先有了那一个“效率”才来组合成某个场景,而是先有了景况,才说明出“作用”。在UML种没有意义这几个词,实际上从气象分解出来的是目的,那么些指标通过音信交互而成就场景。

3.2.4 业务工人

   
  ◆定义:处于系统内部的出席者,称为业务工人。

     
◆区分业务工人和加入者:

       
 a.是还是不是主动向系统倡导动作

       
 b.有没有令人惊讶标作业目的或必要

         c.系统是为他服务呢

   
  ◆例子:

       
 对于呼叫核心作为购买机票系统的子系统的系统,用户通过呼叫中央的人造座席来从机票购买系统开始展览买票,那时,用户是参与者,
人工坐席就是事情工人。

目的和手续的误区

3个用例是参预者对指标类别的1个意思,二个完好无损的风浪。为了完毕那几个事件须求经过很多手续,可是这几个手续不可见全部地显示参预者的对象,不能作为用例。

假若邮局是多个对象连串,作为寄信人那样三个参加者,对邮局有着寄信的希望。把发信作为用例是很当然的作业。要是寄信那件事,包括买信封、买邮票、付钱、投递步骤,以实现这么些全部育赛事件的步调作为用例,就会产出如此的揶揄:寄信人到邮政和电信管理局付钱。

可是步骤也能够当做用例的。在概念模型阶段,由于须要已经抓获,在对须要开始展览剖析时,实际上已经进去了用例的里边。进入用例的内部意味着边界已经改成,导致加入者也在改变。经常,参加者已经济体改成了原来的业务工人,自然参加者的全体指标也就改变了。

寄信和收钱,两个用例大小不等,边界分裂,参与者也分化,它们明显不该同时现身在三个视图里。可是现真实情情形是无数人将不一致尺寸的用例建模在同2个视图里,出现了另八个误区:用例粒度的误区。

3.2.5 参预者与涉众的涉嫌:

      ◆涉众的定义:全体和待开发的系统利益息息相关的人或事,涉众的急需或许会影响系统的建设。

      ◆参与者是涉众的代表,参预者对系统的要就正是系统供给的来源于。

用例粒度的误区

发生用例粒度错误的原由首先是分不清目的和步子。用步骤划分用例会导致不规范的急需获得,以及用例的粒度过于细小。

另3个不时被误用的误区是在同二个需要阶段中的用例粒度大小不一。本质是建立模型者心目中尚无二个知道的境界,没有时时检查现阶段出于哪个抽象层次而造成的。

3.2.6 用户与参预者的关系

   
 ◆用户是系统的操作员,是参与者的象征,但毫无全数的参与者都是用户,1个用户能够代劳多少个到场者。

     ◆例子:

       
自动化办公系统建设,省长是插手者,向系统建议什么样审查批准的渴求;但背后是文书秘书来顶替司长和系统进行直接互动,所以参谋长不是系统的最后用户。

作业用例

工作功用能例(business use
case)是用例版型中的一种,专门用来须求阶段的作业建立模型。业务建立模型是针对性客户工作的模型,通过业务模型能够获取业务范围,帮忙供给职员精晓客户工作,并在业务范围上和客户完毕共同的认识。业务范围不对等供给,软件须要着实的源于是系统范围,也正是系统模型。业务模型是系统模型的最要害输入。

3.2.7 参加者与剧中人物的关系

     ◆定义:角色是加入者的职分,是重多加入者职务中架空出来的如出一辙的一片段职责,使用角色可以为系统带来很好的油滑。

     ◆用户和剧中人物的涉嫌:用户
 1vs多 加入者 ==> 用户
1vs多剧中人物

工功效例完成

政工用例达成是用例版型中的一种,专门用于供给阶段的业务建立模型。三个作业用例的两个业务用例达成都以为着达到同多个目标,然而各类事情用例完成为直达那一个目标而选择的主意各不一致。举例表明:“交纳电话费”能够有“营业厅交费”、“银行缴费”、“预存话费”多个分歧工作功能用例完毕情势。业务用例完毕是促成目的追溯到需要的二个主要环节。

3.2.8 参加者的中坚身份

     ◆大旨地点表今后:系统是以参预者的角度展开设计的,参预者的渴求控制了系统的效能性。

概念用例

在UML中并未定义用例的预约版型,可是概念模型用来获取工作模型中的关键概念,分析出事情模型中的宗旨工作结构以获取一个便于通晓的政工框架,还一定重庆大学。实际上业务架构正是在那么些等级产生的。业务框架结构是工作分析中很关键的三个收获,它对软件架构有着间接的熏陶。

作为概念模型中的主旨成分,概念用例用来得到工作用例中的大旨工作逻辑,那几个大旨工作逻辑揭破了政工格局,成为作业架构的关键带领。同时,概念用例如故从业务用例到系统用例过渡时拾壹分关键的教导。例如:预存话费业务达成,能够从贯彻进程中获得部分为主业务
开立账户、存入现金、转账、支付划账等。

3.2.9 检查点:

 
   ◆怎么着保障发现的参加者都以不易的:

 
    a.找到并表明了装有用例 ==>
来确认是否找到全部的参预者

 
   
b.去除不涉及用例或和用例无通讯关联关系的参加者

 
   
c.有限支撑系统中足足有多个能够当做特定参预者的人手,并联合剧中人物有子集关系的参与者

 
   
d.是不是有参加者担任与系统相关的貌似剧中人物?有则将她们联合成3个加入者。通讯关联关系和用例表达参与者和系统是何许相关关系关系的。

 
   
e.是不是有多少个参预者担任与用例相关的一模一样角色?有则应用加入者泛化关系来未他们的共享行为确立模型

 
   
f.特定的插足者是或不是以三种截然差别的艺术选取系统?他运用的用例是还是不是是因为多少个完全差异的指标?是的话将其化成四个参预者。

 
   
g.到场者是不是有直观的名号和描述性名称?用户和客户是还是不是都能分晓这么些名称?

系统用例

系统用例没有定义版型。系统用例是用例定义系统范围、获取成效性供给的。系统用例是我们获取的末尾要求,实际上是划定开发范围,鲜明系统必要。

3.3.用例

用例达成

恍如事情用例达成,3个用例完结代表了用例的一种完成情势。

 

3.3.1 用例的基本概念:

>定义:用例定义了一组用例实例,每种用例实例对应系统的一多重操作,那一个操作生成了一定主演的惊人测值。

>组成:参预者、前置条件、场景、前置条件。

 
eg:

 
贾某做米饭。对于起火那个用例,其置于条件是有米,前置条件是做出来的饭,用电锅做依然用蒸笼做是四个现象,用电饭煲做时用精米不淘米一直蒸和用粗米淘米后再蒸那是用例对于分歧尺度的拍卖场景。

3.3.2 用例的本性:

 
>用例是并行独立的:
即单个用例即可到位到场者的某部意愿,而浑然不需求依靠任何用例。

 
>用例的施行结果对参加者是可观望和有含义的:比如用户访问系统除去某条记下,系统在剔除前对记录实行了备份。那里的备份数据就不是用户的用例,因为
      用户十分小概对其进展观测。

 
>用例必须由参预者发起,用例不应当自动运行,也不应当主动调用另二个用例。例如用户取钱里取钱是三个用例,ATM机主动吐钱时吐钱不是1个用例因为从没参 

   
与者开始展览发起。

 
>用例必然是以动宾短语结构出现的,入取钱,做报表

 
>一个用例就是二个需要单元、设计单元、开发单元、测试单元,甚至可能是多少个布局单元

3.3.3 用例粒度:

 
>标准的粒度
:用例粒度应能的叙说出席者的某部完整的指标。

 
>在工作建立模型时,用例的粒度以能证实一件具体的业务为宜,如取钱。

 
>在概念建立模型时,用例的粒度以能描述1个总体的风浪流为宜,如填写取款单

 
>在系统建模时,用例的看法是针对性总计机的,用例粒度以能够描述清楚用户和体系的2回完整交互为宜。在RUM(统一建模)中,项目安排要依据系统模型来
      编写,所以另3个可供参考的粒度是三个用例的付出时间决定在七日左右为宜

  #注意:

 
在同二个需求解读,全体的用例的粒度要保持一致。

3.3.4 用例的获取

●从客户那里获得用例前要问的难题:

 
您对系统的希望是怎么?

 
你打算在这几个系统里做哪些事?

 
你对那件事的指标是哪些?

 
您做完那件事要二个怎么结果?

●明确用例时要做的事务: 

 
 多个支柱的对象显示交集,且那些目的是有个别完整目标的一部分,则将这个用例和并成1个,并假定那那多少个主演都只是统一后的事务用例的事情工人。

 
 五个主演谈论的指标有交集,但着实是多个目的,则应该作为多少个用例来对待

3.3.5
用例和机能的误区:

●描述事物的八个视角:

 
这一个事物是何许?

 
那么些事物能够做什么样?

 
那么些东西被人们用来做什么?

●效率:
重在描述那几个事物能够做如何。

  功用是退出使用者意愿而留存的

  功用是单独的

●用例:重在描述这么些东西被人们用来做怎么着。

 
从效果角度来讲述用例,用例能够看成是为落到实处有个别指标而结成在一块的一多元功用的集结。

3.3.6指标和手续的误区:


目的是插手者对系统的完整期望,是1个整机的风波;而完全这一个事件要通过广大手续,单独的步调不可能完全的反应插手者的对象,故不能够看做用例。


eg:

 
 参加者去邮局发信,寄信这一个指标能够分成买信封、买邮票、给钱等几个步骤,对于寄信的参预者人的话,单独的给钱不是他对系统的对象,让他来邮局

给完钱就走他页肯定不干,所以给钱是手续,不是指标,在脚下的事情建立模型中它不可能作为用例。

3.3.7用力力度的误区:

●在同一供给阶段,务必保管用例粒度一致,紧守系统边界。

3.3.8 业务用例

●业务用例是用例的一种版型,在事情建立模型中使用,主要用以获取效率性业务

3.3.9 业务用例达成

●业务用例实现是业务用例的实例,用于描述同一业务用例的不相同完结方式

3.3.10 定义用例

●概念用例用于概念建立模型,用于获取工功能例中的核心业务逻辑。

3.3.11 系统用例

●系统用例用于系统建模,也正是日常说的用例,用于获取成效性需要,是从系统的意见来对待难题。

3.3.12 用例达成

●即系统用例实现,1个用例完成代表了二个用例的一种达成情势,是接二连三用例模型和连串贯彻之间的大桥,对数码库表设计、类设计有教导意义