-
2021-01-30 12:48:21
本文和大家重点讨论一下如何用Visio画UML用例图,首先看一下UML用例图的概念,它主要用来图示化系统的主事件流程,它主要用来描述客户的需求,即用户希望系统具备的完成一定功能的动作,通俗地理解用例就是软件的功能模块。
UML用例图简介
首先看一下UML用例图的概念,它主要用来图示化系统的主事件流程,它主要用来描述客户的需求,即用户希望系统具备的完成一定功能的动作,通俗地理解用例就是软件的功能模块,所以是设计系统分析阶段的起点,设计人员根据客户的需求来创建和解释用例图,用来描述软件应具备哪些功能模块以及这些模块之间的调用关系,用例图包含了用例和参与者,用例之间用关联来连接以求把系统的整个结构和功能反映给非技术人员(通常是软件的用户),对应的是软件的结构和功能分解。
用例是从系统外部可见的行为,是系统为某一个或几个参与者(Actor)提供的一段完整的服务。从原则上来讲,用例之间都是独立、并列的,它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系,提高可维护性和一致性,用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。
用Visio画UML用例图步骤:
1.在“文件”菜单上,依次指向“新建”、“软件”,然后单击“UML模型图”。
2.在树视图中,右击要包含用例图的包或子系统,再指向“新建”,然后单击“用例图”。
此时会出现一个空白页,而且“UML用例”模具也会显示在最顶部。工作区将“用例”显示为水印。树视图将添加一个表示该图表的图标。
注释如果看不见树视图,请在“UML”菜单中指向“视图”,然后单击“模型资
更多相关内容 -
UML用例图总结
2021-01-31 04:40:53用例图主要用来描述 用户、需求、系统功能单元之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。【用途】:帮助开发团队以一种可视化的方式理解系统的功能需求。用例图所包含的元素如下:表示与您的... -
UML用例图例子
2019-04-27 00:06:07UML用例图例子 供学习参考,免责声明 -
UML用例图之泛化(generalization)、扩展(extend)和包含(include)关系
2021-02-27 00:24:42在画用例图的时候,理清用例之间的关系是重点。用例的关系有泛化(generalization)、扩展(extend)和包含(include)。其中include和extend最易混淆。下面我们结合实例彻底理清三者的关系。基本概念用例图... -
uml用例图
2019-03-23 01:36:42NULL 博文链接:https://lipeixiaoyu.iteye.com/blog/1067135 -
UML用例图
2022-04-15 02:20:33UML 用例图 Use Case Diagram 我们把用例图分解为四个不同的元素:系统Systems,参与者Actors,用例Use Cases和关系Relationships 1、系统 系统就是我们正在开发的任何东西。它可以是一个网站,一个软件组件,...UML 用例图 Use Case Diagram
我们把用例图分解为四个不同的元素:系统Systems,参与者Actors,用例Use Cases和关系Relationships
1、系统
系统就是我们正在开发的任何东西。它可以是一个网站,一个软件组件,业务流程,应用程序或任何其他的事情。
矩形表示一个系统,并把系统的名称放在顶部。
我们构建一个简单的银行应用程序用例图。我们称为银行应用程序系统。此矩形有助于定义此系统的范围。
这个矩形内的任何东西都在银行应用程序内。这个矩形之外的任何东西都没有发生在银行应用程序中。
2、下一个元素是参与者,如图所示。参与者Actor将成为某人或者某事,来使我们的系统实现目标。那可能是一个人,一个组织,
另一个系统或者外部设备等。
那么谁或将要使用我们的银行业务程序呢?
最明显的参与者是顾客,我们将有顾客下载并使用我们的银行应用程序。
另一个参与者是银行,银行将提供相关信息,与交易一样,我们的银行应用程序提供交易,账户余额等
以下是我们除了参与者Actor时要注意的:
首先,重要的是要注意这些参与者都是外部对象。它们总是要放在我们的系统外面
其次,参与者要被视为类型或者类别。对于我们的银行应用程序,参与者不会去成为特定的个人或者特定组织。我们不会将我们的
参与者Actor标记为王超和招商银行。我们希望保持绝对的东西。所有现在我们说两个顾客和银行将使用我们的应用程序。这提出了主要次要的参与者。主要参与者启动系统的使用,而次要参与者更被动。所以在我们的例子中,那个参与者是主要的,那个是次要的?顾客是主要的 客户开始使用我们的系统,他们打算拿出手机打开我们的银行应用程序,并做一些事情。银行是次要的,银行只会在顾客做了些什么之后,才会采取行动。
主要参与者应该在系统左边,次要参与者在系统的右边。
在这里我们只是视觉上强化了这一事实,客户参与银行应用程序,然后银行作出反应。
3、下一个元素是用例,这是我们真正开始描述我们的系统。
我们使用椭圆描绘一个用例,它代表一个完成的动作,或者系统内的某种任务。
用例将被放置在矩形内,因为它们是在系统中发生的行为。
那么我们的银行应用程序会做些什么呢?简单来说,如果我们的银行应用程序可以进行 客户登录,查询余额,转账,支付等,那么这些将就是我们要描述的用例。
可以看到,我们的每个用例的描述都使用动词开始,我们使用动词加强了动作的发生。我们还希望它们具有足够的描述性。最后我们尽可能的按照逻辑顺序使用用例。这是我们将登陆置于顶端的原因。这是客户使用我们应用程序的第一件事。
4、用例图中的最后一个元素是关系。根据定义,参与者Actor正在使用我们的系统实现目标。所以每个参与者都必须至少与我们系统中的一个用例互动。
在我们的系统中,客户将要登录进入我们的应用程序。所以我们再参与者Actor与用例之间画一条实线,来表示这种关系。这种关系称为关联,它只是表示基本的沟通或互动。客户将与其他用例进行互动,也是如此。他们将查询余额,转账,支付,所以我们将用实线连接参与者与这些用例。
次要参与者Actor也要至少连接一个用例,请注意,每个参与者都必须与至少一个用例互动。
那么银行将与那些用例互动?当客户想要查询余额时,在应用程序上,银行将提供账户余额。我们再银行和查询余额直接画一条实线。同时,当客户进行转账或者支付时,银行正在跟进这些交易。我们不需要在登录时刻连线,是因为该过程发送在应用程序中,银行实际行没有必要参与登录过程。
还有其他三种关系,除了association 组合,还有Include包含、Extend扩展和Generalization泛化。
我们另外构建这个图表用例,以解释这些类型关系。
当客户输入他们的登录信息时,我们程序将在完成登录过程之前,验证密码是否正确,如果密码不正确,程序将显示错误消息。
因此我们创建两个新的用例验证,验证密码,和显示登录错误。
当客户在进行转账或支付时,银行会先验证余额是否充足;另外客户在支付和付款时,可以选择支票支付或者储蓄支付。我们创建两个用例支票支付,储蓄支付。
返回验证密码用例再次讨论关系。验证密码如何与其他用例发生关系?我们的参与者都没有直接发起,它只会在每次尝试登录时,发生在程序内部。这是一个包含关系。
包含关系显示基本用例和包含用例之间的依赖关系。 每次在执行基本用例时,包含用例也被执行。为了执行完一个基本用例,需要执行一个包含用例。
当基本用例有一个包含关系时,我们画一条带有箭头的虚线,到包含用例。
因此,在我们的示例中,登录用例是基本用例,它和验证密码用例是包含关系。每次客户登录是,应用程序将自动验证密码。除非登录用例不完整,或者验证密码已完成。
下一种关系是Extend扩展关系,扩展关系存在于基本用例和扩展用例之间。当执行基本用例时,扩展用例有时会发生,但不是每次都会发生。扩展用例只会在确定的符合标准的时间才会发生。
想到它的另一种方式是,你有扩展基础行为的选项用例。当有延伸关系时,我们画一条带有箭头的虚线,指向基本用例。
在我们的示例中,登录是一个基本用例,和显示登录错误是一种扩展关系。我们不会每次都显示错误信息,只会在用户输入错误密码时才显示。
这里我们解释了包含和扩展直接差异关系,以防万一,我们再举一个简单的例子,来区分两者之间的差异。
如果你打喷嚏,你会闭上眼睛。这是一个包含关系,因为它每次都会发生。另外,如果你打喷嚏,你可能会说劳驾,这是一个扩展关系,因为它补充了打喷嚏,但并非完全属于打喷嚏过程中必不可少的。
请记住每次都包含,延伸恰好发生在有时,而不是每次,箭头指向相反方向。
需要注意的一点是,多重基础用例 可以指向相同的包含或者扩展用例。例如:支付和转账将指向验证余额,我们希望系统每次在进行转账和支付时,进行此检查。每次这些基本用例执行时,都会执行检查余额用例。
最后一种关系是泛化,也叫继承。
当我们使用银行APP进行付款时,可以选择支票支付,或者储蓄支付。这种情况下,付款是基本用例,与支票支付用例,储蓄支付用例是父子关系,每个孩子都有共同的父行为,但每个孩子都有它自己的一些行为,更多的是它自己的。为了表名这种概况,我们从孩子哪里画出箭头,指向父母。
另外我们也允许对参与者Actor进行泛化。这些每种孩子参与者,都具有某些特有的行为或者品质。
最后,我们看一个带扩展点的用例,用例的名称在横线上方,下面有扩展点。扩展点只是一个详细的版本延伸关系。
-
UML用例图:准则
2021-03-04 05:34:08若要创建UML用例图,请在“体系结构”菜单上,单击“新建关系图”。用例图有助于讨论和传达以下内容:用例图不显示用例的详细信息:它只概括用例、参与者和系统之间的某些关系。特别是,用例图不显示每个用例为实现... -
超市管理系统--UML用例图,类图,时序图(交互图)活动图,状态图含详细文档~
2018-12-25 18:21:573、学会使用Rational Rose绘制用例图。 三、实验仪器设备 计算机+Rational Rose+Office 四、实验方案设计 1、通过用例描述寻找类; 2、确定类之间的关系,并使用Rational Rose绘制类图; 五、实验内容及步骤 六、... -
UML用例图概要
2021-02-27 04:20:10用例图主要用来图示化系统的主事件流程,它主要用来描述客户的需求,即用户希望系统具备的完成一定功能的动作,通俗地理解用例就是软件的功能模块,所以是设计系统分析阶段的起点,设计人员根据客户的需求来创建和... -
UML用例图及类图用法
2018-05-12 11:28:00UML的用例以及类图的用法。主要描述在业务分析和开发分析过程中,如何正确的进行用例和类图分析。 -
UML 用例图
2018-04-23 11:36:12UML 用例图 参考 【UML】— 用例图 用例图 初学UML——用例图 需求中如何画用例图 为什么使用用例图 从业务事件、发起事件以及系统如何响应这些事件来建模系统功能的过程。 用例建模起源于面向对象建模...UML 用例图
参考
【UML】— 用例图
用例图
初学UML——用例图
需求中如何画用例图为什么使用用例图
- 从业务事件、发起事件以及系统如何响应这些事件来建模系统功能的过程。
- 用例建模起源于面向对象建模。
概念
- 图形化地描述了谁将使用该系统以及用户希望与系统交互的方式。
- 业务事件的文本描述以及用户如何与系统交互以完成任务。
参与者
- 参与者是与系统主体交互的外部实体的类元,描述了一个或一组与系统产生交互的外部用户或外部事物。
- 参与者位于系统边界之外,而不是系统的一部分。
- 可以是:人,组织,另一个信息系统,外部设备,甚至时间。
确定参与者
从以下角度确定参与者
- 为系统提供输入的人或事物
- 接收系统输出的人或事物
- 需要接入的第三方系统或设备
- 时间是否会触发某些事件
- 负责支持或维护系统中信息的人
参与者分类
- 主要业务参与者:主要从用例的执行中获得好处的关联人员。
- 主要系统参与者:直接同系统交互以触发业务或系统事件的关联人员。
- 外部服务参与者:响应来自用例的请求的关联人员。
- 外部接收参与者:从用例中接收某些价值或输出的非主要的关联人员。
参与者的泛化关系
- 当系统中的几个参与者既扮演自身的角色,同时也有更一般化的角色时,可以通过建立泛化关系来进行描述。
- 与类相似,父参与者可以是抽象的,即不能创建一个父参与者的直接实例,这就要求属于抽象父参与者的外部对象一定能够属于其子参与者之一。
用例
- 用例是类元提供的一个内聚的的功能单元,表明系统与一个或多个参与者之间信息交换的顺序,也表明了系统执行的动作。
- 简单来说,用例就是某一个参与者在系统中做某件事从开始到结束的一系列活动的集合,以及结束时应该返回的可观测、有意义的结果,其中也包含可能的各种分支情况。
- 用例与用例图被广泛使用于系统的需求建模阶段,并在系统的整个生命周期中被不断细化。
确定用例
用例的特征保证用例能够正确地捕捉功能性需求,同时也是判断用例是否准确的依据。
- 用例是动宾短语
- 用例是相对独立的
- 用例是由参与者启动的
- 用例要有可观测的执行结果
- 一个用例是一个单元
用例与参与者
- 一个用例可以隶属一个或多个参与者,一个参与者也可以参与一个或多个用例。
- 用例与参与者之间存在关联关系。
- 主参与者与次参与者:通常来说主参与者是用例的重要服务对象,而次参与者处于一种协作地位。
用例的粒度
- 在业务建模阶段,用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。例如取钱、报装电话、借书等表达完整业务的用例,而不要细节到验证密码、填写申请单、查找数目等业务中的一个步骤。
- 在用例分析阶段,即概念建模阶段,用例的粒度以每个用例能描述一个完整事件流为宜。可以理解为一个用例描述一项完整业务中的一个步骤。
- 在系统建模阶段,用例视角是针对计算机的,因此用例的粒度以一个用例能够描述操作者与计算机的一次完成交互为宜。例如,填写申请单、审核申请单、派发任务单等。可以理解为一个操作界面或一个页面流。
泛化关系
- 与参与者的泛化关系相似,用例的泛化关系将特化的用例与一般化的用例联系起来。子用例继承了父用例的属性、操作和行为序列,并且可以增加属于自己的附加属性和操作。
- 父用例同样可以定义为抽象用例。
依赖关系——包含
- 包含指的是一个用例(基用例)可以包含其他用例(包含用例)具有的行为,其中包含用例中定义的行为将被插入基用例定义的行为中。
- 包含的两个基本约束:
- 基用例可以看到包含用例,并需要依赖于包含用例的执行结果,但是它对包含用例的内部结构没有了解;
- 基用例一定会要求包含用例执行。
扩展
- 扩展指的是一个用例(扩展用例)对另一个用例(基用例)行为的增强。
- 在这一关系中,扩展用例包含了一个或多个片段,每个片段都可以插入到基用例中的一个单独的位置上,而基用例对于扩展的存在是毫不知情的。使用扩展用例我们就可以在不改变基用例的同时,根据需要自由地向用例中添加行为。
用例图示例
依赖关系对比
用例描述
- 一个完整的用例模型应该不仅仅包括用例图部分,还要有完整的用例描述部分。
- 一般的用例描述主要包括以下几部分内容:
- 用例名称:描述用例的意图或实现的目标,一般为动词或动宾短语。
- 用例编号:用例的唯一标识符,在其他位置可以使用该标识符来引用用例。
- 参与者:描述用例的参与者,包括主要参与者和其他参与者。
- 用例描述:对用例的一段简单的概括描述。
- 触发器:触发用例执行的一个事件。
- 前置条件:用例执行前系统状态的约束条件。
- 基本事件流(典型过程):用例的常规活动序列,包括参与者发起的动作与系统执行的响应活动。
- 扩展事件流(替代过程):记录如果典型过程出现异常或变化时的用例行为,即典型过程以外的其他活动步骤。
- 结论:描述用例何时结束。
- 后置条件:用例执行后系统状态的约束条件。
- 补充约束:用例实现时需要考虑的业务规则、实现约束等信息。
用例描述示例
-
UML图解:用例图(Usecasediagram)
2021-03-01 16:19:01UML因为讲求建模的精确性,所以比较专业,学起来比较抽象,这里专门以贪吃蛇游戏为例,讲解UML的13种图,如下图所示:UML图解1:用例图(Usecasediagram)用例图其实来自于电影领域的场景描述,是导演向演员讲述电影... -
UML用例图规范
2011-11-18 01:33:01UML用例图规范用例子的编写,对于正在学软件工程或者UML的同学,会很有帮助的。欢迎下载! -
UML用例图中关系详解
2018-08-22 02:37:15UML中用例图:包含、扩展、泛化三种关系详解。在设计的时候可以参考一下。 -
UML用例的关系_UML用例图关系_源码
2021-10-03 18:07:11论述UML用例图之间的关系,对用例图进行详细说明。 -
UML用例图的画法详细介绍【软件工程】
2022-01-01 17:17:42首先,用例图是用来描述系统功能的技术,表示一个系统中用例与参与者及其关系的图,主要用于需求分析阶段,同时它由参与者(actor)、用例(case)和容器(container) 三部分组成,并具有关联(Association)、泛化...
I.总述和预备知识
首先,用例图是用来描述系统功能的技术,表示一个系统中用例与参与者及其关系的图,主要用于需求分析阶段,同时它由参与者(actor)、用例(case)和容器(container) 三部分组成,并具有关联(Association)、泛化(Generalization)、包含(Include)和扩展(Extend) 四种关系。
【预备知识】:关于组成成分:参与者、用例和容器
✅参与者(actor): 表示与应用软件或系统进行交互的用户、组织或外部系统,画图时用一个小人表示:
✅用例(case): 表示外部可见的系统或软件的功能,对系统提供的服务进行描述,画图时用椭圆和文字表示:
✅容器(container): 代表着一个系统,画图时用一个矩形表示,矩形内一般是一个一个的用例:
下面从用例图的四种关系进行逐一介绍。
II.关联(Association)关系
关联(Association)关系是用例图最常见的一种关系,简单理解就是参与者(actor)与每个用例(case)之间存在的一种相互交流、通信的关系,发生的对象是参与者和用例。这种关系与类图的关联关系很相似,可以近似理解。
画法上,关联关系无论是双向的还是单向的,一律用单向的实线箭头从参与者指向用例:
III.泛化(Generalization)关系
泛化(Generalization)关系是我们通常理解的继承关系:子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系;子用例可以使用父用例的一段行为,也可以重载它。此时,父用例通常是抽象的,而子用例表现出很强的具体性。(这里的子用例和父用例同样适用于参与者)
在用例图中,泛化关系存在于用例(case)之间或参与者(actor)之间,但通常不会出现在二者混合之间。画法上,泛化关系表示为实线、空心三角箭头,从“子”指向“父”:
IV.包含(Include)关系
包含(Include)关系是用来表示把一个较复杂用例所表示的功能分解成较小的步骤的一种关系。从定义不难看出,这种关系只会存在于用例(case)之间,并且通常是对一个复杂的用例进行拆解操作。
画法上,包含关系表示为两个部分:首先是一条虚线箭头,从较复杂的用例指向拆解出的功能用例;第二部分是在虚线上标注《include》,表示这是包含关系(与下一个扩展关系进行区分):
V.扩展(Extend)关系
扩展(Extend)关系是用来表示用例功能的延伸的一种关系。这种关系同样是发生在用例(case)之间,相当于为基础用例提供一个附加功能用例。
画法上,扩展关系同样分两个部分:首先是一条虚线箭头,从延伸功能用例指向基础用例(直观感受与包含关系刚好相反);第二部分是在虚线上标注《extend》,表示这是扩展关系:
VI.总结
对四种关系的画法进行一个总结:
关系 UML画法 关联关系 一条从参与者指向用例的实线 泛化关系 一条从 “子”指向“父” 的空心三角实线 包含关系 一条从较复杂用例指向拆解出的功能用例的虚线,并标有 《include》 扩展关系 一条从延伸功能用例指向基础用例的虚线,并标有 《extend》 最后放一个登录注册系统的UML用例图:
-
UML 用例图符号含义
2021-08-30 22:27:19用例图 用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示一个外部用户能够观察到的系统功能模型图。用例图多用于静态建模阶段(主要是业务建模和需求建模),帮助开发团队以一种可视化的方式理解... -
UML实践----用例图、顺序图、状态图、类图、包图、协作图
2021-03-03 02:27:43UML中有九种建模的图标,即:用例图类图对象图顺序图协作图状态图活动图组件图配置图本课程中的某些部分包含了这些图的细节信息的页面链接。而且每个部分都有一个小问题,测试一下你对这个部分的理解。为什么UML很... -
UML用例图介绍
2020-01-18 11:20:491.什么是用例图 1.用例图用来描述系统的需求,从用户的角度来描述系统的功能,强调谁在使用系统,系统实现了哪些功能,总的来说,用例图就是描述用户的需求和系统的功能,从外部用户的角度来描述系统的功能。 2.用例... -
论文研究-基于UML用例图的软件产品线需求建模方法.pdf
2019-07-22 17:56:50而传统的UML用例图等方法不足以完整描述产品线需求,特别是其变化性。通过分析软件产品线开发过程和软件产品线需求建模的特殊性,采用扩展UML用例图标签的方法,实现对软件产品线需求的明确描述。以网络图书销售软件... -
java之UML用例图
2020-01-30 16:01:29java之UML用例图 -
Visio画图(一):UML用例图
2021-01-17 18:45:32Visio画图(一):UML用例图1.找到UML用例图A.有网状态第一步 在搜索框内输入用例图进行搜索.第二步,移动鼠标直到找到用例图B.无网状态第一步 点击特别推荐旁的类别选项第二步 点击其下方的软件和数据库第三步 移动鼠标... -
UML用例图、时序图、类图、活动图
2020-06-02 15:04:27用例图: 参与者:外部参与者(用户/其他系统) 用例:功能 2.1关系 包含关系:一个用例包含另一个用例(不可或缺) 拓展关系:一个用例存在是为了拓展另一个用例(锦上添花) 继承关系:一个用例继承自一个用例 依赖关系:一个... -
UML实践--UML用例图和类图解析.doc
2020-06-14 02:28:57UML实践--UML用例图和类图解析 UML统一建模语言相信大家应该有所了解你对UML实践是否熟悉这里就向大家介绍一下UML实践中的用例图和类图相信通过本文的介绍你对UML实践有一定的认识 本节向大家介绍一下UML实践方面的... -
UML用例图讲解及画法
2020-04-09 23:26:131.用例图 ●用例图(UseCaseDiagram)用于描述若干参与者(actor)以及这些参与者与系统提供的用例之间的交互关系 ●用例图从人-机交互的角度,分析和考察系统的行为,描述系统对用户提供的功能特性 ●用例图由参与者、... -
uml 用例图
2013-01-27 09:34:42uml用例图详解,详细描述了uml用例图的概念及应用