用例图。
组成:系统边界。参与者。用例。关系。
参与者:Actor不是人,而是指参与用例时担当的角色。
如果一个角色的操作是由另一个角色代理完成的,请建立该角色到另外角色之间的依赖。
怎样识别参与者呢?
系统、子系统或类与外部的参与者(actor)交互的动作序列的说明,包括各种序列及出错序列。
用例分析可以认为是对系统功能的分解。
怎样确定用例的粒度呢?
用例的粒度(用例的大小)可大可小,一般一个系统易控制在20个左右。用例是系统级的抽象的描述,不是细化的(是做什么,非怎样做)。对复杂系统可以划分为若干个子系统处理。
怎样获取用例呢?
参与者希望系统执行什么任务?
参与者在系统中访问哪些信息(创建、存储、修改、删除等)?
需要将外界的哪些信息提供给系统?
需要将系统的那个事件告诉参与者?
如何维护系统?
UML中的四种关系。
关联(association)
包含(include)
扩展(extend)
泛化(generalization)
关联关系
描述参与者和用例之间的关系。
用单向箭头,表示谁启动用例。
每个用例都有角色启动,除了包含和扩展用例。
包含。
是指两个用例之间的关系。其中一个用例(基本用例,base use case)的行为包含了另一个用例(包含用例,inclusion use case)的行为。
如果两个以上用例有大量一致的功能,则可以将这个功能分解到另一个用例中,其他用力拉可以和这个用例建立包含关系。
上面的例子就是说查询、提款和转账三个用例都有一个一致的功能,所以将这个功能提取出来为一个用例。且这三个用例和提取出的这个用例之间是包含的关系。
执行基本用例的时候也可以执行被包含的用例,被包含的用例也可以单独执行。
如果一个用例的功能太多时,可以用包含关系建模成两个或多个小用例
扩展。
也是指两个用例之间的关系。一个用例可以被定义为基础用例的增量的扩展,称作为扩展关系。扩展关系是把新的行为插入到已有的用例中方法。基础用例即使没有扩展用例的执行不会涉及扩展用例,只有在特定的条件发生,扩展用例才被执行。
泛化(继承)。
一个用例和其几种情形的用例间构成泛化关系。往往父用例表示为抽象用例。
任何父用例出现的地方子用例也可出现。
1 对用例的描述。
2 用例描述的组成
用例名称,简要说明/描述,优先级,参与者,前置条件,基本事件流,其他事件流,扩展点,后置条件。
事件流:就是用例执行时,由一序列活动组成的控制流。
基本事件流:对用例中常规、预期路径的描述。
扩展事件流:主要是对一些异常情况、选择分支进行描述。
前置条件:在用例启动时参与者(actor)与系统应置于什么状态。
后置条件:用例结束时系统应置于什么状态。
以上述的”新增书籍信息”为例,说明如何细化用例描述。
扩展事件流。
如下例所示建立用例模型。
有一个业务需求如下,要求我们为其构件一个用例图。
1)系统可以供教师使用来为学生记录成绩。
2)系统根据需要创建报告卡。
从细分的用例中发现新的用例,并根据优先级重新排列。
机房收费系统的用例图。
1、首先是分析系统中的角色(Actor)。
谁向系统提供信息?—–学生
谁从系统获取信息?—-学生、管理员、操作员、一般用户
谁操作这个系统呢?–一般用户、操作员、管理员。
谁维护这个系统呢?—管理员。
系统要使用的外部资源?—数据库。
系统是否和已经存在的系统交互?—好像没有。
从中找出这个系统的Actor—(学生、一般用户、管理员、数据库)
外界提供给本系统的信息是—学生信息、系统时间信息、系统用户信息。
需要将系统的哪个事件告诉参与者?
……无……
如何维护系统?
管理员负责对系统的维护—–基本数据的设定。
用例图如下所示:
学生和一般用户的用例图。
学生和操作员的用例图。
学生和管理员用例图所示:
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/196467.html原文链接:https://javaforall.cn