一文读懂 UML 用例图
1个回答
展开全部
当你脑子里有一个商业案例时,你该怎么向老板介绍呢?一大段文字,或是动手写个 Demo?老板很忙,老板也不见得懂你所说的“高大上”技术,有没有那种实现成本较低但又包含较多信息的表现方式呢?有,画张图呗!
今天起再开个专题,谈谈我们开发中常用到的一些图形建模手段。前言结束,我们从 UML 视图启航。
UML——Unified Modeling Language——统一建模语言,是业务建模阶段最常用和最重要的一种视图。由于它简单易懂,常常用于跨组织的文档或演示的说明中;这里所谓的跨组织指的不仅仅是开发部门间,而是指跨产品、设计、测试、运维等等部门的业务交流中。UML 设计中,第一张图一般都是用例图:是的,就是那个有“小人”的图。
用例图主要有三个部分组成:用例(Use Case)、参与者(Actor),以及它们互相间的关系(Relationship);形式上就是用椭圆、小人,以及箭头的连线组合。
我们先不细说椭圆或是箭头的具体含义。我觉得讲用例图最好还是从具体的 Use case 入手为好。我们试着设计一款简单的银行 APP,它包含注册、登陆、交易等等操作。我们一步步拆解挥着用例图的过程。
画用例图的第一步通常是拖出一个巨大的矩形块,并将其命名为我们的目标系统——Banking App。一个用例图一般只会有一个 System,之后我们会把所有该系统相关的是功能(“用例”)放置在系统内部,系统的相关方(“参与者”)放置在系统的左右两侧。
第二个绘制元素就是参与者,即系统相关方,可以是人、组织、外部设备,或是其他系统。在我们这个银行案例里,该 App 的相关方有两个:就是客户(Customer)和银行(Bank)。
通常来说,一个用例图中会有两三个参与者,我们会把主要参与者放在系统左侧,次要参与者(主要参与者的回应方)放在右侧;显然我们的 App 主要是面向客户的,所以把客户放在了左边。
第三步就是在系统内添加具体的用例,也就是该系统所提供的功能或是业务块。我们的银行 APP 比较简单,只提供如下业务:
第四步,我们再把参与者与用例串联起来,就是我们所说的关系(Relationships)。用例图中,关系还可以继续细分:
最后,所有 UML 视图事实上都可以加注释,专业术语叫延伸(Extension points)和批注(Note);这两种注释性质形同,都是起说明作用:
好了,UML 用例图大体就讲完了。我们再回顾一下用例图的使用场景,在产品设计阶段,我们可以使用用例图为用户、系统和功能服务建立起抽象关系,以便描述产品所呈现的外部动态特征。在一些大厂中,通常由产品经理或是设计师来首先绘制 UML 用例图,再交于开发团队实现。
我们举了一个银行 App 的例子,事实上有点大了;现实开发中,一个 Use Case 图通常只对应的一个简单的业务流而已。我们自己在写用例图时,也要注意在宏观层面将联系紧密的功能模块抽象为一个简单的 Case,然后逐步地为这些较大的功能模块画出细分 Case 的用例图。
今天起再开个专题,谈谈我们开发中常用到的一些图形建模手段。前言结束,我们从 UML 视图启航。
UML——Unified Modeling Language——统一建模语言,是业务建模阶段最常用和最重要的一种视图。由于它简单易懂,常常用于跨组织的文档或演示的说明中;这里所谓的跨组织指的不仅仅是开发部门间,而是指跨产品、设计、测试、运维等等部门的业务交流中。UML 设计中,第一张图一般都是用例图:是的,就是那个有“小人”的图。
用例图主要有三个部分组成:用例(Use Case)、参与者(Actor),以及它们互相间的关系(Relationship);形式上就是用椭圆、小人,以及箭头的连线组合。
我们先不细说椭圆或是箭头的具体含义。我觉得讲用例图最好还是从具体的 Use case 入手为好。我们试着设计一款简单的银行 APP,它包含注册、登陆、交易等等操作。我们一步步拆解挥着用例图的过程。
画用例图的第一步通常是拖出一个巨大的矩形块,并将其命名为我们的目标系统——Banking App。一个用例图一般只会有一个 System,之后我们会把所有该系统相关的是功能(“用例”)放置在系统内部,系统的相关方(“参与者”)放置在系统的左右两侧。
第二个绘制元素就是参与者,即系统相关方,可以是人、组织、外部设备,或是其他系统。在我们这个银行案例里,该 App 的相关方有两个:就是客户(Customer)和银行(Bank)。
通常来说,一个用例图中会有两三个参与者,我们会把主要参与者放在系统左侧,次要参与者(主要参与者的回应方)放在右侧;显然我们的 App 主要是面向客户的,所以把客户放在了左边。
第三步就是在系统内添加具体的用例,也就是该系统所提供的功能或是业务块。我们的银行 APP 比较简单,只提供如下业务:
第四步,我们再把参与者与用例串联起来,就是我们所说的关系(Relationships)。用例图中,关系还可以继续细分:
最后,所有 UML 视图事实上都可以加注释,专业术语叫延伸(Extension points)和批注(Note);这两种注释性质形同,都是起说明作用:
好了,UML 用例图大体就讲完了。我们再回顾一下用例图的使用场景,在产品设计阶段,我们可以使用用例图为用户、系统和功能服务建立起抽象关系,以便描述产品所呈现的外部动态特征。在一些大厂中,通常由产品经理或是设计师来首先绘制 UML 用例图,再交于开发团队实现。
我们举了一个银行 App 的例子,事实上有点大了;现实开发中,一个 Use Case 图通常只对应的一个简单的业务流而已。我们自己在写用例图时,也要注意在宏观层面将联系紧密的功能模块抽象为一个简单的 Case,然后逐步地为这些较大的功能模块画出细分 Case 的用例图。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
博思aippt
2024-07-22 广告
2024-07-22 广告
博思AIPPT是基于ai制作PPT的智能在线工具,类似gamma生成ppt,它提供了4种AI制作PPT的方式,包括AI生成大纲、AI直接生成PPT、文本生成PPT、AI提炼文档生成PPT,一站式集成多种AI生成PPT的方式,可满足办公用户的...
点击进入详情页
本回答由博思aippt提供
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询