代码改变世界

第六周学习记录

2017-12-02 17:25  melay  阅读(146)  评论(0编辑  收藏  举报

这周主要画了用例图和写用例描述。一开始对用例图的绘制只是表面上的理解,真正动手画的时候,出现了不少问题,一方面对用例的概念比较模糊,另一方面是如何确定用例间的关系存在一定的难度,很多用例间的关系比较模糊,或者没遇到过,所以遇到了不少问题。下面主要罗列了如何确定参与者、确定用例的一些方法,以及用例描述说明。

用例图描述

用例图不显示用例的详细信息:它只概括用例、参与者和系统之间的某些关系。特别是,用例图不显示每个用例为实现目标所执行步骤的顺序。

用例图有四个部分:

  • 用例(Use Case):表明系统能做什么事情
  • 参与者(Actor):是对系统使用者的抽象
  • 系统边界:清晰表达出系统的范围
  • 关系 :角色的继承、关联、泛化、包含(Include)、扩展(Extend)、比较少用到的用例继承

关系介绍

关联(Association):是指角色与用例之间的关系,有三种:无箭头,指向用例的箭头,指向执行者的箭头。一般来说,箭头的尾部用来表示启动交互的一方,头部用来表示被启动的一方。不过箭头的解释容易把人弄晕,建议全部画成没有箭头就行了。
  
包含(Include):包含关系用来把一个较复杂的用例所表示的功能分解成较小的步骤。包含用例是必须的,如果缺少包含用例,基用例就是不完整的。
  
扩展(Extend):在某用例的基础上,还能做什么事情,带有”《extend》”标志的虚线的箭头方向,箭头方向表明了谁扩展谁。

泛化关系是两个用例或两个参与者之间的关系。泛化关系其实可以通俗理解为面向对象关系中的继承。将拥有一种类似的结构和行为的多个用例中的共性抽象为父用例,子用例继承父用例中的所有。

识别参与者

发现参与者,可以根据以下问题来寻找系统的参与者:
谁或什么在使用系统;
交互中,他们扮演什么角色;
谁安装系统;
谁启动和关闭系统;
谁维护系统;
与该系统交互的是什么系统;
谁从系统获取信息,谁提供信息给系统;

参与者相关的注意问题:

参与者对于系统而言是外部的,它们在系统控制之外。
参与者直接同系统交互,可以帮助定义系统边界。
参与者表示人和事物与系统发生交互时所扮演的角色,而不是特定的人或事物。
一个人和事物与系统发生交互时,可以扮演多个角色。例:某个研究生担任某教授的助教,从职业的角度看,他扮演了两个角色----学生和助教。
每个参与者需要有一个具有业务语义的名字。
每个参与者必须有简短的描述,从业务角度描述参与者是什么。
参与者可以具有分栏,表示参与者属性和它可接受的事件。
参与者可以使用用泛化关系来描述多个参与者之间的公共行为。

识别用例的方法:从分析系统的参与者开始,考虑每个参与者是怎样使用系统的。

以下几个问题可以帮助识别用例:
<1>特定参与者希望系统提供什么功能;
<2>系统是否存储和检索信息,若是,这个行为由哪个参与者触发;
<3>当系统改变状态时,通知参与者吗;
<4>存在影响系统的外部事件吗;
<5>是哪个参与者通知系统这些事。

用例描述

参见以下博客:
一个完整的用例描述

需要注意的是:

  • 前置条件描述了执行用例之前系统必须满足的条件。这些条件必须在执行用例之前得到满足,如果条件不满足,则用例不会执行。
  • 后置条件将在用例成功完成以后得到满足,它提供了系统的部分描述。后置条件可以在用例结束后监察系统,如系统状态或持久数据用例完成后所剩下的。用例的后置条件应该是不存在的,即执行可选择的流动;它不应该只适用于主流。如果某件事可能失败,你会在事后说:“行动完成了,或者如果某件事失败了,行动就没有完成”,而不是“行动完成了”。