绘制用例图_如何绘制 uml 活动图
大家好,又见面了,我是你们的朋友全栈君。
用例图。
组成:系统边界。参与者。用例。关系。
参与者:Actor不是人,而是指参与用例时担当的角色。
如果一个角色的操作是由另一个角色代理完成的,请建立该角色到另外角色之间的依赖。
怎样识别参与者呢?
- 是谁向系统提供的信息呢.
- 谁向系统获取信息。
- 谁操作系统。
- 系统使用哪些外部资源
- 系统是否和已经存在的系统交互
系统、子系统或类与外部的参与者(actor)交互的动作序列的说明,包括各种序列及出错序列。
用例分析可以认为是对系统功能的分解。
怎样确定用例的粒度呢?
用例的粒度(用例的大小)可大可小,一般一个系统易控制在20个左右。用例是系统级的抽象的描述,不是细化的(是做什么,非怎样做)。对复杂系统可以划分为若干个子系统处理。
怎样获取用例呢?
参与者希望系统执行什么任务?
参与者在系统中访问哪些信息(创建、存储、修改、删除等)?
需要将外界的哪些信息提供给系统?
需要将系统的那个事件告诉参与者?
如何维护系统?
UML中的四种关系。
关联(association)
包含(include)
扩展(extend)
泛化(generalization)
关联关系
描述参与者和用例之间的关系。
用单向箭头,表示谁启动用例。
每个用例都有角色启动,除了包含和扩展用例。
包含。
是指两个用例之间的关系。其中一个用例(基本用例,base use case)的行为包含了另一个用例(包含用例,inclusion use case)的行为。
如果两个以上用例有大量一致的功能,则可以将这个功能分解到另一个用例中,其他用力拉可以和这个用例建立包含关系。
上面的例子就是说查询、提款和转账三个用例都有一个一致的功能,所以将这个功能提取出来为一个用例。且这三个用例和提取出的这个用例之间是包含的关系。
执行基本用例的时候也可以执行被包含的用例,被包含的用例也可以单独执行。
如果一个用例的功能太多时,可以用包含关系建模成两个或多个小用例
扩展。
也是指两个用例之间的关系。一个用例可以被定义为基础用例的增量的扩展,称作为扩展关系。扩展关系是把新的行为插入到已有的用例中方法。基础用例即使没有扩展用例的执行不会涉及扩展用例,只有在特定的条件发生,扩展用例才被执行。
泛化(继承)。
一个用例和其几种情形的用例间构成泛化关系。往往父用例表示为抽象用例。
任何父用例出现的地方子用例也可出现。
1 对用例的描述。
- 用例图:只能描述系统的大概功能,是一种视图。
- 用例描述:更详细地描述用例的功能。
2 用例描述的组成
用例名称,简要说明/描述,优先级,参与者,前置条件,基本事件流,其他事件流,扩展点,后置条件。
事件流:就是用例执行时,由一序列活动组成的控制流。
基本事件流:对用例中常规、预期路径的描述。
扩展事件流:主要是对一些异常情况、选择分支进行描述。
前置条件:在用例启动时参与者(actor)与系统应置于什么状态。
后置条件:用例结束时系统应置于什么状态。
以上述的”新增书籍信息”为例,说明如何细化用例描述。
- 用例的概要描述 用例名称:新增书籍(UCO1) 简要说明:录入新购书籍信息,并自动存储建档。 事件流:基本事件流和扩展事件流。 非功能需求 前置条件:用户进入图书管理系统。 后置条件:完成新书信息的存储建档。 扩展点:无 优先级:高(满意度 5 ,不满意度5 )
- 详细描述 基本事件流
- 图书管理员向系统发出”新增书籍信息”请求。
- 系统要求图书管理员选择要增加的书籍是计算机类还是飞信计算接类
- 图书管理员做出选择后,显示相应界面,让图书管理员输入信息,并自动根据书号规则生成书号。
- 图书管理员输入书籍的相关信息,包括:书名、作者、出版社、ISBN号、开本。页数、定价。是否有CD-ROM。
- 系统确认输入的信息中书名没有重名。
- 系统将所输入的信息存档建档。
扩展事件流。
- A 如果输入的书名有重名现象,则显示出重名的书籍,并要求图书管理员选择修改书名或取消输入。
- A(1)图书管理员选择取消输入,则结束用例,不做存储建档工作。
- A(2)图书管理员选择修改书名后,转到A。
如下例所示建立用例模型。
有一个业务需求如下,要求我们为其构件一个用例图。
1)系统可以供教师使用来为学生记录成绩。
2)系统根据需要创建报告卡。
- 系统允许用户浏览记录的成绩。 首先这里面要问到的是:11)中教师可以记录学生信息,这就是说教师可以录入、修改和删除学生信息了。22)中系统要创建报告卡,是谁来创建报告卡呢?这里就应该有权限的问题了,系统需要管理人员来来执行这项工作,另一个方面做系统的维护工作。报告卡创建后干什么?管理人员检查其准确性之后,由教师来分发报告卡。33) 系统允许用户浏览成绩,是谁可以浏览成绩呢?是学生和老师。
- 从中得到这个系统的参与者是:教师,学生,管理员。 主要用例:录入成绩。更新成绩。生成报告卡。报告卡准确性。分发报告卡。浏览成绩。 要区分用例的优先级。 首先是 :记录成绩,浏览成绩,更新成绩,生成报告,检查报告卡的准确性,分发报告卡。 细化每一个用例。 对”记录成绩”进行细化,下面是对该用例的主事件流。
- 首先是教师要确定录入哪些学的成绩。
- 系统中要确保学生在数据库中。
- 教师说明记录哪像作业的成绩。
- 系统开始数据库的一些事物。
- 系统为学生把作业加入到数据库中。
- 教师输入学生作业的成绩。
- 系统核对输入的成绩是否符合正确的范围和格式。
- 系统记录作业的成绩。
- 系统结束事物的处理。
- 系统提示教师成绩已经记录好。
从细分的用例中发现新的用例,并根据优先级重新排列。
机房收费系统的用例图。
1、首先是分析系统中的角色(Actor)。
谁向系统提供信息?—–学生
谁从系统获取信息?—-学生、管理员、操作员、一般用户
谁操作这个系统呢?–一般用户、操作员、管理员。
谁维护这个系统呢?—管理员。
系统要使用的外部资源?—数据库。
系统是否和已经存在的系统交互?—好像没有。
从中找出这个系统的Actor—(学生、一般用户、管理员、数据库)
- 基本Use case。 找出的参与者希望系统执行什么任务? 学生—去注册卡号,后充值,上机,下机,付钱,查看信息(查看自己的个人信息,上机信息,卡内的余额信息),不想用了就注销卡号。(学生的需求是要通过系统用户对系统的操作来完成的。所以学生和系统用户这两个角色之间是关联关系。) 一般用户—主要是用这个系统来管理学生上下机。可以登录到系统中去,后学生刷卡上机,显示上机的学生的记录,显示登录时间,查看学生上机状态,学生下机,显示下机时间和消费金额,可以修改自己的密码,查询余额。 操作员—主要是用这个系统为学生进行注册充值以及查询一些信息。登录到系统中去,可修改密码,根据学生的要求使用系统来,注册,充值,退卡,注册后充值可以查看收取金额,学生基本信息维护,学生上机统计信息,最后退卡时,查看金额退还信息来退还相应的钱数。最后可以查看老师和自己的工作记录。 管理员—登录到系统中去,可以修改密码以确保安全性。利用这个系统可以对学生的上下机情况查看。可以对一般用户和操作员的工作记录查看。 参与者在系统中访问哪些信息(创建、存储、修改、删除等)? 参与者在系统中需要访问 需要将外界哪些信息供给系统?
外界提供给本系统的信息是—学生信息、系统时间信息、系统用户信息。
需要将系统的哪个事件告诉参与者?
……无……
如何维护系统?
管理员负责对系统的维护—–基本数据的设定。
用例图如下所示:
学生和一般用户的用例图。
学生和操作员的用例图。
学生和管理员用例图所示:
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
推荐阅读
-
绘制用例图_如何绘制 uml 活动图
-
使用 PlantUML 绘制活动图和泳道图
-
python 如何绘制全球风场图(以 2020 年月平均数据为例)
-
如何使用网页绘制黑莓 9900 键盘效果图
-
ipadpro 绘制流程图_要玩 iPad Pro?先下载这些应用程序如何?
-
[软件工程期末复习】知识点+大题详解(E-R图、数据流图、N-S框图、状态图、活动图、用例图 ....)(下图)
-
如何绘制标准化 UML 用例图
-
用 R 语言绘制雷达图
-
纯干货分享 | 研发效能提升——敏捷需求篇-而敏捷需求是提升效能的方式中不可或缺的模块之一。 云智慧的敏捷教练——Iris Xu近期在公司做了一场分享,主题为「敏捷需求挖掘和组织方法,交付更高业务价值的产品」。Iris具有丰富的团队敏捷转型实施经验,完成了企业多个团队从传统模式到敏捷转型的落地和实施,积淀了很多的经验。 这次分享主要包含以下2个部分: 第一部分是用户影响地图 第二部分是事件驱动的业务分析Event driven business analysis(以下简称EDBA) 用户影响地图,是一种从业务目标到产品需求映射的需求挖掘和组织的方法。 在软件开发过程中可能会遇到一些问题,比如大家使用不同的业务语言、技术语言,造成角色间的沟通阻碍,还会导致一些问题,比如需求误解、需求传递错误等;这会直接导致产品的功能需求和要实现的业务目标不是映射关系。 但在交付期间,研发人员必须要将这些需求实现交付,他们实则并不清楚这些功能需求产生的原因是什么、要解决客户的哪些痛点。研发人员往往只是拿到了解决方案,需要把它实现,但没有和业务侧一起去思考解决方案是否正确,能否真正的帮助客户解决问题。而用户影响地图通常是能够连接业务目标和产品功能的一种手段。 我们在每次迭代里加入的假设,也就是功能需求。首先把它先实现,再逐步去验证我们每一个小目标是否已经实现,再看下一个目标要是什么。那影响地图就是在这个过程中帮我们不断地去梳理目标和功能之间的关系。 我们在软件开发中可能存在的一些问题 针对这些问题,我们如何避免?先简单介绍做敏捷转型的常规思路: 先做团队级的敏捷,首先把产品、开发、测试人员,还有一些更后端的人员比如交互运维的同学放在一起,组成一个特训团队做交付。这个团队要包含交付过程中所涉及的所有角色。 接着业务敏捷要打通整个业务环节和研发侧的一个交付。上图中可以看到在敏捷中需求是分层管理的,第一层是业务需求,在这个层级是以用户目标和业务目标作为输入进行规划,同时需要去考虑客户的诉求。业务人员通过获取到的业务需求,进一步的和团队一起将其分解为产品需求。所以业务需求其实是我们真正去发布和运营的单元,它可以被独立发布到我们的生产环境上。我们的产品需求其实就是产品的具体功能,它是我们集成和测试的对象,也就是我们最终去部署到系统上的一个基本单元。产品需求再到了我们的开发团队,映射到迭代计划会上要把它分解为相应的技术任务,包括我们平时所说的比如一些前端的开发、后端的开发、测试都是相应的技术任务。所以业务敏捷要达到的目标是需要去持续顺畅高质量的交付业务价值。 将这几个点串起来,形成金字塔结构。最上层我们会把业务目标放在整个金字塔的塔尖。这个业务目标是通过用户的目标以及北极星指标确立的。确认业务目标后再去梳理相应的业务流程,最后生产。另外产品需求包含了操作流程和业务规则,具需求交付时间、工程时间以及我们的一些质量标准的要求。 谈到用户影响的地图,在敏捷江湖上其实有一个传说,大家都有一个说法叫做敏捷需求的“任督二脉”。用户影响地图其实就是任脉,在黑客马拉松上用过的用户故事地图其实叫督脉。所以说用户影响地图是在用户故事地图之前,先帮我们去梳理出我们要做哪些东西。当我们真正识别出我们要实现的业务活动之后,用户故事地图才去梳理我们整个的业务工作流,以及每个工作流节点下所要包含的具体功能和用户故事。所以说用户影响地图需要解决的问题,我们包括以下这些: 首先是范围蔓延,我们在整张地图上,功能和对应的业务目标是要去有一个映射的。这就避免了一些在我们比如有很多干系人参与的会议上,那大家都有不同想法些立场,会提出很多需求(正确以及错误的需求)。这个时候我们会依据目标去看这些需求是否真的是会影响我们的目标。 这里提到的错误需求,比如是利益相关的人提出的、客户认为产品应该有的、某个产品经理需求分析师认为可以有的....但是这些功能在用户影响地图中匹配不到对应目标的话,就需要降低优先级或弃掉。另外,通常我们去制定解决方案的时候,会考虑较完美的实现,导致解决方案括很多的功能。这个时候关键目标至关重要,会帮助我们梳理筛选、确定优先级。 看一下用户影响到地图概貌 总共分为一个三层的结构: 第一层why,你的业务目标哪个是最重要的,为什么?涉及到的角色有哪些? 第二层how ,怎样产生影响?影响用户角色什么样的行为? (不需要去列出所有的影响,基于业务目标) 第三层what,最关键的是在梳理需求时不需一次把所有细节想全,这通常团队中经常遇到的问题。 我们用这个例子来看一下 这是一个客服中心的影响地图,业务目标是 3个月内不增加客服人数的前提下能支持1.5倍的用户数。此业务目标设定是符合 smart 原则的,specific非常的具体,miserable 是可以衡量的,action reoriented是面向活动的, real list 也是很实际的。 量化的目标会指引我们接下来的行动,梳理一个业务目标,尽量去量化,比如 :我们通过打造一条什么样的流水线,能够提高整个部署的效率,时间是原来的 1/2 。这样才是一个能量化的有意义的目标。 回到这幅图, how 层级识别出来的内容,客服角色:想要对它施加的影响,把客户引导到论坛上,帮助客户更容易的跟踪问题,更快速的去定位问题。初级用户:方论坛上找到问题。高级用户:在论坛上回答问题。通过我们这些用户角色,进行活动,完成在不增加客户客服人数的前提下支持更多的用户数量。 最后一个层级,才是我们日常接触比较多的真正的功能的特性和需求,比如引导到客户到论坛上,其实这个产品就需要有一个常见问题的论坛的链接。这个层次需要我们团队进一步地在交付,在每个迭代之前做进一步的梳理,细化成相应的用户故事。 这个是云智慧团队中,自己做的影响地图的范例,可以看下整个的层级结构。序号表示优先级。 那我们用户影响地图可以总结为:
-
R 中的绘图 - 散点小提琴图 - 原始链接:用 R 绘制散点小提琴图