UML建模

2022/3/17 java

# 说在前面

UML作为一种统一的软件建模语言具有广泛的建模能力。UML是在消化、吸收、提炼至今存在的所有软件建模语言的基础上提出的,集百家之所长,它是软件建模语言的集大成者。UML还突破了软件的限制,广泛吸收了其他领域的建模方法,并根据建模的一般原理,结合了软件的特点,因此具有坚实的理论基础和广泛性。UML不仅可以用于软件建模,还可以用于其他领域的建模工作

UML立足于对事物的实体、性质、关系、结构、状态和动态变化过程的全程描述和反映。UML可以从不同角度描述人们所观察到的软件视图,也可以描述在不同开发阶段中的软件的形态。UML可以建立需求模型、逻辑模型、设计模型和实现模型等。

大白话就是作为软件业务设计人员,使用UML建模可以使我们更快,更深的理解业务需求及业务深层逻辑交互。使得我们在日常的业务设计过程中,对业务的数据流的输入,处理,输出有更清晰的认识。设计人员产出的设计文档能够让开发人员快速理解需求,快速进入到开发当中,能够减少设计与开发环节的沟通成本!

建模工具:Visio Professional

# 用例图

# 简介

用例图用于描述用户和其他应用程序与指定系统的交互。

定义:有参与者(Actor)、用例(Use Case)以及他们之间的的关系构成的用于描述系统功能的动态视图称为用例图。

用例图是外部用户(参与者)所能观察到的系统功能的模型图,显示了系统中用例与角色的相互关,主要是用于对系统、子系统的功能行为进行建模。

用例图展示了用例之间以及同用例Actor之间是怎样相互联系的。对系统、子系统的行为进行了用例图展示了用例之间以及同用例Actor之间是怎样相互联系的。对系统、子系统的行为进行了可视化,是用户可以立即如何使用系统模块,且给开发者的实现提供一个引导。

用例图是通过Actor从系统的外部看系统功能的,因此并不描述系统的内部具体实现。

# 使用说明

  • 基本元素说明

    image-20220316114038170

    Customer:它指的是在系统以外,在使用系统或则与系统进行交互的时候所扮演的角色,比如我们可以从以下方面识别参与者:

    1. 谁向系统获取信息
    2. 谁向用户获取信息
    3. 谁操作系统

    Partner Management: 用例主要描述系统的交互,简单来说用例是参与者期望系统做的事。对于用例的名字一般是描述性的,并带有动作性的词,比如我们可以从以下方面识别用例:

    1. Custome希望系统执行什么任务
    2. Custome访问哪些信息(储存,修改,删除等)
  • 连接元素

    image-20220316133907807

    包含关系:基于用例的行为包含了另一个用例的行为。

    泛化关系:代表通用与特殊的关系,类的is-a关系。子用例可以增加新的行为、覆盖父用例的行为

    延长关系:扩展关系和泛化关系类似,不过扩展的用例有更多的规则限制,子用例可以增加新的行为,但是不能进行覆盖。

    概括(归纳)关系:表示继承 常用于参与者之间,拥有父类的所有用例行为 并可以增加新的用例

# 注意事项

  • 用例图需要涵盖该功能模块下的所有参与者
  • 用例图需要涵盖该功能模块下的所有参与者的用例
  • 不要遗漏,否则可能导致设计流程缺失或开发缺少需求认知的覆盖面

# 场景介绍

用户注册用例图

image-20220316143131588

收货地址用例图

image-20220316144249503

若供应商和采购商都存在收货地址,那么用1,2图标识都可以

# 适用范围

再描述整体或部分功能流程时,可添加该流程或该模块的用例图,一般再大模块标题处声明,可与流程图同级

# 序列图

# 简介

时序图用于显示进程如何相互操作以及以何种顺序操作,序列图是一个同步图,这意味着在 UML 模型中的交互下存在的任何元素都将在序列图中自动可见。

# 使用说明

  • 基本元素说明

    1. 角色(Actor)

    系统角色,可以是人或者其他系统和子系统或函数名,方法。以一个小人图标表示。

    image-20220316155550631

    • 对象(Object)

      对象位于时序图的顶部,以一个矩形表示。一般以业务接口或实现类或类名命名

      image-20220316155538416

    • 生命线(LifeLine)

      时序图中每个对象和底部中心都有一条垂直的虚线,这就是对象的生命线(对象的时间线)。以一条垂直的虚线表。

    • 控制焦点(Activation)

      控制焦点代表时序图中在对象时间线上某段时期执行的操作。以一个很窄的矩形表示。

      Visio命名为:激活

      image-20220316155504592

    • 消息(Message)

      表示对象之间发送的信息。消息分为三种类型。

      • 同步消息(Synchronous Message) 消息的发送者把控制传递给消息的接收者,然后停止活动,等待消息的接收者放弃或者返回控制。用来表示同步的意义。以一条实线和实心箭头表示

      • 异步消息(Asynchronous Message)

        消息发送者通过消息把信号传递给消息的接收者,然后继续自己的活动,不等待接受者返回消息或者控制。异步消息的接收者和发送者是并发工作的。以一条实线和大于号表示

      • 返回消息(Return Message) 返回消息表示从过程调用返回。以小于号和虚线表示

      image-20220316155630329

    • 组合片段

    image-20220316160045496

# 注意事项

  • 序列图表示系统内部具体的执行顺序和执行逻辑,需要考虑全面 禁止出现执行顺序混乱,图形描述有误的情况出现
  • 组合片段的功能平时用的不是很多,这边不做深入介绍了。

# 适用范围

再描述具体某个方法实现时,可用时序图声明内部逻辑处理,一般放在设计文档具体实现内

# 场景介绍

商品保存序列图

image-20220316152350188

订单下单时序图

image-20220316152350188

# 状态图

# 简介

状态图(UML 1.x规范中的称呼),是一种展示状态机的图,在UML 2.x中则称为状态机图。

所谓状态机,它是一种行为,用于描述一个对象在其生命周期中的各种状态及状态的转换。

# 使用说明

基本元素说明:

UML状态图主要由五种元素组成,分别是状态、转换、事件、动作和活动。

  • 状态:表示对象的生命周期中的一种条件/情况,有初态和终态之分

    image-20220316164333509

  • 转换:表示两种状态间的一种关系

    即:执行

    image-20220316164353703

  • 事件:表示在某一时间与空间下所发生的有意义的事情

    即为内部行为及状态

    image-20220316164405863

  • 动作:表示一个可执行的原子操作,是UML能够表达的最小计算单元

    基于一个状态到另一个状态的执行过程

    image-20220316164417496

# 注意事项

  • 注意行为过程和最终态要区分清楚,行为过程是指状态变化过程中的操作,最终态是指内部行为及状态的表示

# 场景介绍

盘点计划状态图

image-20220316162206564

# 适用范围

再描述整体或部分功能流程时,可添加该流程或该模块的用例图,一般再大模块标题处声明,可与流程图同级

# E-R图(非UML建模图形)

# 简介

E-R图也称实体-联系图(Entity Relationship Diagram),提供了表示实体类型、属性和联系的方法。

# 使用说明

基本元素说明

  • 实体

    通常表示数据库表

    image-20220316165920541

  • 属性

    表示数据库表字段

    image-20220316165930328

  • 联系

    实体与实体之间的联系,有1:1,1:N,N:N

    image-20220316165948505

# 注意事项

# 场景介绍

用户体系ER图

image-20220316170641351

# 活动图

# 简介

活动指:某件事情正在进行的状态,既可以是现实生活中某一项工作,也可以是软件系统中某个类对象的一个操作。

活动图是UML中描述系统动态行为的图之一,用于展现参与行为的类的活动或动作。

# 使用说明

基本元素说明

  • 开始结束

    在活动图当中,活动图的开始由一个实心球表示,结束由一个半实心球表示

    image-20220316180731221

  • 活动和活动流

    活动指执行特定动作,并在该动作完成之后向另一个状态转化,通常圆角方框表示。通常将表达的动作写在方框内。

    动作流连接活动,通常用实线箭头表示。

    image-20220316180921201

  • 分叉和汇合

    在UML中,可以使用分叉将路径分成两个或多个并发流,然后使用结合,同步这些并流。分叉和汇合通常都用同步条表示,同步条是一条粗的水平线。

    image-20220316181715467

# 注意事项

# 场景介绍

用户下单活动图

image-20220316181819384

# 适用范围

再描述整体或部分功能流程时,可添加该流程或该模块的用例图,一般再大模块标题处声明,可与流程图同级

# 讲到最后

设计人员学习UML建模的不同图形是对业务需求的一种视角上面的思考,能够通过不同的视角加深对需求细节的理解,提升工程能力。通过UML建模从不同角度去理解软件系统但学习UML的重点不要放在词法语法上,知道基本语法即可,重点去理解UML如何体现需求,总体设计,业务逻辑设计,验证和测试,具体实现等等不同角度的异同,协调和平衡软件系统里不同的考虑。

设计人员一定要注意换位思考,产出的设计文档,流程图,用例图,状态图等。作为开发角度来看是否可以清晰理解业务需求,以及业务交互。如果做不到这一点,那么设计将毫无意义。