搜索
写经验 领红包

用例图uml(uml用例图是什么意思)

导语:UML-用例图的介绍

UML:Unified Modeling Language 统一建模语言,又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。

你可能没怎么接触UML这个概念,但是你如果从事软件行业的工作,一定有接触过,比如时序图、构件图、类图、状态图这些都是属于UML的。

我由于工作中需要,最近在学习使用UML中的用例图,这里主要就是将我整理的分享出来。

用例图定义

用例图(Use Case Diagrame)是UML的一种,主要用来描述角色以及角色与用例之间的连接关系。能够充分展示一个外部用户能够观察的系统功能模型图,以一种可视化的直观方式理解系统的功能需求,以便使用户更容易理解这些元素的用途,也便于开发人员最终实现这些元素。

绘制用例图目的

用例图是跳出当前系统,站在用户的角度去看系统,思考系统功能,这样我们能更加理解业务,表达清楚需求。

从用户的视角,我们不会使用专业术语去进行业务的沟通,可以做到真正以用户为中心去获取需求,转化为产品服务。

这里比较烦的一点就是画这个图的往往是软件从业人员,而为了画用例图又要求你尽量忘记软件相关的专业知识。

用例图可以帮助我们更全面地考虑系统内事物之间的互相影响,关注整体的运行规律,而不是只考虑个别事物的情况。

用例图的组成元素

参与者:与应用程序或者系统进行交互的用户、组织或者外部系统,用一个火柴人表示。

参与者

用例:用例就是外部可见的系统功能,对系统提供的服务进行描述。通常用椭圆表示。

画用例的注意事项:

用例的颗粒度确定,没有标准,只能根据实际情况分析。一个大型系统,可能会有上百个用例,一个小产品,也许只有几个用例。一个用例是一个完整的使用场景,不是零散的动作步骤。比如,输入密码只是一个动作,登录才是完整的场景。一个用例有一个明确、独立的目标,如果一个用例包括多个目标,则可再逐层细化出子用例。

系统边界:将系统内外分开,参与者在外面,用例在里面。边界内的用例,就是系统要实现的事情。通常用矩形框表示。

关系:关系分成关联关系、归纳(泛化)关系、包含关系、扩展关系,用来表示参与者与用例、用例与用例之间的关系。

关联关系:参与者与用例之间通信,任何一方都可以发送和接收消息,将参与者与用例相连,指向消息接收方。一般有三种形式:无箭头、有指向用例的箭头、有指向执行者的箭头。箭头的方向代表了数据流向或者谁启动谁。

关联关系

归纳(泛化)关系:就是通常理解的继承关系,子用例和父用例相似,但是表现为更特别的行为。子用例继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的,在实际应用中很少使用泛化关系,箭头指向父用例。

泛化关系

包含关系:包含是用来把一个复杂的用例表示为一个功能分解的较小步骤,包含关系典型的应用就是复用,也就是定义中说的情景,但是有时候当某个用例的事件流太过于复杂时,我们也可以把一段事件流抽象成一个被包含的用例;相反用例太细的时候,也可以抽象出一个基用例,来包含这些细粒度的用例。

扩展关系:表示用例与用例之间的关系,是在特定条件下,由扩展用例指向被扩展用例。用虚线箭头+<<extend>>字样,箭头指向被扩展的用例。拓展用例是在特定条件出现时,才会被执行的用例。

包含关系和扩展关系的联系:都是从现有的用例中抽取出公共的那部分信息,作为一个单独的用例,然后通过不同的方法来重用这个公共的用例,以减少模型维护的工作量。

包含关系和扩展关系的区别:1. 扩展关系中基本用例执行时,扩展用例不一定执行,即扩展用例只有在基本用例满足某种条件的时候才会执行。2. 包含关系中基本用例执行时,包含用例一定会执行。

注意

不是每个需求都要画用例图,要视情况而定,简单的需求完全可以不用画。画图是为了表达、传递信息,当我们画用例图时,不管画得多么酷炫,本质都是在分析业务场景、系统功能性需求,并描述出来。

总结

用例图在需求阶段是一个很好用的工具,但是要画好用例图其实不是一件容易的事情。尤其是对于我这种非专业需求人员,那是相当令人头秃的事情。

本文内容由小葵整理编辑!