全网最全最简洁UML图教程
网上有太多复杂而不全的UML图教程,故笔者整合网上资料并结合自己的理解撰写此帖以作考试用。笔者水平有限,若有不准确之处烦请指正
UML Structural (Static) Diagrams
Class Diagram
意义:显示了系统中的类的信息以及它们是如何相关联的(而不是如何交互)
解释:每一个块代表一个类,一个块有三部分,最上面是类名,中间是类属性,下面是类方法。
类之间可以用箭头相连,类图关系如下图。
类之间的关系可以是1对n,1对1或者n对n。
Object Diagram
意义:对象图用于表示在特定时间点上系统中的对象实例及其之间的关系。
解释:对象直接无箭头,用线条相连即可(也不需要写数量关系),对象图需要写上实例的名称和属性的值,其他和类图没区别。
Composite Structure Diagram
意义:描述类、组件或系统内部的组成结构,以及它们之间的关系。关注类的实例(对象)在系统中如何协作完成某个功能。它描述的是系统或组件在某一时刻的静态结构,不会像动态图那样展示行为的时间序列。
** 解释**:有两个基本的符号:collaboration(就是图中的椭圆)和structured class(就是图中的长方形)每个structure class可能会有一个标记来指示它在这次协作中的作用。图中左边就是seller,右边就是buyer。简单来说,这个图就是用来描述类如何协作的,但是它是
描述的协作的方式,结构而不是动态的。
Component Diagram
意义:描述系统中所有的组件,它们的关系、交互以及接口。它是一个组合或者模块结构的大纲。
解释:圆形的棒棒糖是提供的功能,弧形的机器人手臂是使用棒棒糖提供的功能的意思。这里可能有朋友搞不明白这和Class Diagram有啥区别了:
Component Diagram 强调的是模块化设计和部署架构,关注高层组件及其依赖关系。
Class Diagram 强调的是类的设计和逻辑结构,关注类的属性、方法以及类与类的关系。
也就是说,多个类可以是一个组件(当然一个类也可以是一个组件)。
Package Diagram
意义:包图 中的每个“包”就像是一个代码文件夹,里面可以放很多类、接口等代码。包图描述的是这些文件夹之间如何组织和依赖,而不关心里面具体有什么类或方法。这个主要用在开发视图里面。
注意:包是一种分组机制,所以包内可以包含UML中任何元素,如类、用例、接口、组件、节点等,也可以包含其它包、用例图、协作图、时序图等。
解释:包中的元素可见性主要包含三种:
- 公有的(public)
通过在元素前添加“+”符号来表示,则该元素对所有引入该包的元素可见。 - 私有的(private)
通过在元素前添加“-”符号来表示,则该元素只能被同一个包内的元素可见。 - 保护的(protected)
通过在元素前添加“#”符号来表示,则该元素对继承该包的包中元素可见。
包之间可以有两种关系:
-
引入和访问依赖
在此图中[1],订单Ordering引入了产品Products包和价格Pricing包。Ordering是客户包,Products和Pricing是提供者。
-
泛化
特殊包必须遵循一般包的接口。对于一般性包可以标明 {abstract},定义为一个接口,该接口有多个特殊包实现。
特殊包从一般包继承其所含的公共类,并且可以重载和添加自己的类。特殊包可以替代一般包,用在一般包使用的任何地方[2]。
Deployment Diagram
意义: 描述系统如何在硬件环境中部署,以及软硬件之间的关系。它展示了系统中各个组件(如应用程序、数据库等)如何在物理设备上部署,以及它们如何通过网络连接进行交互。
解释:里面的正方体或者圆柱体就是节点,节点是系统中的一个物理设备或虚拟设备,例如服务器、计算机、路由器、手机等。节点下方的名字表示设备的名称,比如 Web Server和Database Server。连接两个节点的线条表示这些节点之间存在某种交互关系。线条上的文字表示交互的方式,通常是使用的协议(例如 HTTP、TCP/IP)或API(例如 REST API、SOAP)。这些关系通常没有方向性,因为交互是双向的,除非明确表示数据的流向。
Behavioral (Dynamic) Diagrams
Use Case Diagram
意义:用例图主要用来描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统,以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素,如系统、参与者和用例,并且显示这些元素之间的各种关系,如泛化、关联和依赖。它展示了一个外部用户能够观察到的系统功能模型图。帮助展示功能性需求。
解释:方块就是系统,小人就是使用者,椭圆就是功能,线条连接的意思就是这个使用者能够使用这个功能,如果无特殊关系(都是association关系)的话,那么箭头有没有都对,但如果特殊关系(非association关系)还是要加上箭头的。
用例图有四种关系[3]:
-
Association
就是上图无文字描述的线条,实线,箭头可有可无。 -
Include
虚线,必须有箭头。
被多个基用例调用以提高重用性。且每次基用例执行,都会包含被包含用例。
例如:在有入库处理和出库处理时,必执行更新库存记录。
-
Extend
虚线,必须有箭头。
在基用例的某个条件下触发。基用例(比如还书)不是每次都需要扩展用例(罚款),只在一定条件下(超期未还等)才需要罚款。
例如:读者还书时不一定会进行罚款,只有满足特定条件(如逾期太久)才会罚款。
-
Generalization
实线,必须有箭头。
子用例是父用例的具体的、不同的执行方式。
例如:识别用户可以用验证口令实现,也可以用扫描指纹实现。
注意:include是从事件指向副事件的,extend是从副事件指向事件的
Activity Diagram
意义[4]:描述活动的顺序,展现从一个活动到另一个活动的控制流,活动图在本质上是一种流程图;活动图着重表现从一个活动到另一个活动的控制流。
解释:如下图,实心圆点是起点,实心圆点外面再加一个空心圆是终点,圆角矩形是活动,箭头就是活动流程,菱形是if条件划分。横杠是从一个流程变道多个流程或者多个流程合并到同一个流程。
注意菱形的两个if也是可以合并的,如下图。
State Machine Diagram
意义:状态机图描述系统或对象在其生命周期中状态的变化,以及触发状态转换的事件和条件。
解释:起点和终点同活动图。每个节点是一个状态(圆角矩形),分三层,最上层是状态名,中间是一些状态变量,第三层是状态活动。两个状态可以用箭头连接,箭头指向切换的状态,箭头上面写状态切换的条件。
注意:有的时候对于一些活动状态是不会改变的,比如下面的wait for login。
Sequence Diagram
意义:描述对象之间发送消息的时间顺序,显示多个对象之间的动态协作。
解释[5]:我们在画时序图时会涉及7种元素:角色(Actor)、对象(Object)、生命线(LifeLine)、控制焦点(Activation)、消息(Message)、自关联消息、组合片段。其中前6种是比较常用和重要的元素,剩余的一种组合片段元素不是很常用,但是比较复杂。我们先介绍前6种元素,在单独介绍组合片段元素。
- 角色(Actor)
系统角色,可以是人或者其他系统,子系统。以一个小人图标表示。 - 对象(Object)
对象位于时序图的顶部,以一个矩形表示。对象的命名方式一般有三种:
1. 对象名和类名。例如:华为手机:手机、loginServiceObject:LoginService。
2. 只显示类名,不显示对象,即为一个匿名类。例如::手机、:LoginSservice。
3. 只显示对象名,不显示类名。例如:华为手机:、loginServiceObject:。 - 生命线(LifeLine)
时序图中每个对象和底部中心都有一条垂直的虚线,这就是对象的生命线(对象的时间线)。以一条垂直的虚线表。下图其实是有点问题的,生命线应该在该对象上面第一个控制焦点的头部开始到下面最后一个控制焦点以后结束,擦除多余的生命线是绘画时序图的最后一步,而下图没有擦掉多余的生命线。 - 控制焦点(Activation)
控制焦点代表时序图中在对象时间线上某段时期执行的操作。以一个很窄的矩形表示。 - 消息(Message)
表现代表对象之间发送的信息。消息分为四种类型。
1. 同步消息(Synchronous Message)
消息的发送者把控制传递给消息的接收者,然后停止活动,等待消息的接收者放弃或者返回控制。用来表示同步的意义。以一条实线+实心箭头表示。
2. 异步消息(Asynchronous Message)
消息发送者通过消息把信号传递给消息的接收者,然后继续自己的活动,不等待接受者返回消息或者控制。异步消息的接收者和发送者是并发工作的。以一条实线+大于号表示。
3. 返回消息(Return Message)
返回消息表示从过程调用返回。以小于号+虚线表示。
4. 自关联消息
表示方法的自身调用或者一个对象内的一个方法调用另外一个方法。以一个半闭合的长方形+下方实心剪头表示。
- 组合片段
1. 抉择(Alt)
抉择在任何场合下只发生一个序列。 可以在每个片段中设置一个临界来指示该片段可以运行的条件。else 的临界指示其他任何临界都不为 True 时应运行的片段。如果所有临界都为 False 并且没有 else,则不执行任何片段。Alt片段组合可以理解为if…else if…else条件语句。我们还拿微信支付的时序图举例,如果7.3向商家汇款的成功或失败流程需要在时序图中体现出来,可以这么使用Alt片段组合。
2. 选项(Opt)
包含一个可能发生或不发生的序列。Opt相当于if…语句。
3. 循环(Loop)
片段重复一定次数,可以在临界中指示片段重复的条件。Loop相当于for语句。
5. 并行(Par)
并行处理,片段中的事件可以并行交错。Par相当于多线程。
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA
版权协议,转载请附上原文出处链接和本声明。原文链接:https://blog.youkuaiyun.com/fly_zxy/article/details/80911942
Communication (Collaboration) Diagram
意义:描述了系统中对象件的信息传递,与时序图是等价的,唯一不一样的点是它关注对象的角色。
解释:最左边的小人是actor,方框是对象,箭头就是传递消息的链路,箭头上方就是消息以及序列顺序号。每个通信链路都与一个序列顺序号加上传递的消息相关联。
Interaction Overview Diagram
意义:本质就是可以用时序图(或者Communication Diagram, Activity Diagram)代替活动节点的活动图,每个单独的活动都可以被描绘为包含嵌套时序图(或者Communication Diagram, Activity Diagram)的框架,这样可以提供系统和事务的概览。
解释:其实没什么好解释的,活动图和时序图这些前面都有讲过,就是选择需要细化的一些活动图的节点,把他们变成时序图(或者Communication Diagram, Activity Diagram),这就是交互概览图,如下图。
Timing Diagram
意义:揭示系统状态随着时间的变化,合并了坐标轴和状态图的状态,一般用于时间关键型系统,如实时操作系统等等。
解释:纵轴就是状态,横轴就是时间,没啥好说的。
4+1 View Modules 对应的图汇总
由于网上许多资料不一样,这里通统一参考书本Software Architecture And Design Illuminated By Kai Qian, Xiang Fu, Lixin Tao, Chong-wei Xu, Jones And Bartlett Publishers.
View Type | Diagrams |
---|---|
Scenario View | 1. Use Case Diagram |
Logical (Conceptual) View | 1. Class Diagram 2. Object Diagram 3. Interaction Overview Diagram 4. Sequence Diagram 5. Communication Diagram 6. State Diagram 7. Activity Diagram PS: A block diagram(Not UML) can also be used to provide an overview of the whole system. A sequence diagram shows how objects in the system interact. A communication diagram shows system objects and the message passing between them in time order. |
Development (Module) View | 1. Package Diagram 2. Component Diagram |
Process View | 1. Activity Diagram 2. Interaction Overview Diagram |
Physical View | 1. Deployment Diagram |
一些其他的图
由于还有一些其他的图比较重要,虽然不是UML图,但仍然在这里稍作讲解
Data Flow Diagram
这里国内和国外有一个差异,国外的Level 0 数据流图就是国内的顶层数据流图,国外的Level 1数据流图才是国内的Level 0数据流图,以此类推,简单来说就是国内多了一个顶层数据流图而国外是直接从Level 0开始的,下面为了方便讲解统一使用国外的标准。
意义:描述系统中数据流动和处理过程。
解释:基本元素如下图
数据流图是分层的[6]。
- 0层是最抽象的顶层的数据流,突出表明了数据的源点和终点,如下图。一个系统只有一个0层数据流图。在这个高层次的数据流图上是否列出了所有给定的数据源点 / 终点是一目了然的,因此它是很有价值的沟通工具。
- 0层数据流图太大概,太抽象了,1层数据流图把基本系统模型细化,描绘系统的主要功能。由于 “产生报表” 和 “处理事务” 是该系统必须完成的两个主要功能,它们将代替图顶层数据流图中的“订货系统”。此外,细化后的数据流图中还增加了两个数据存储:处理事务需要“库存清单”数据;产生报表和处理事务在不同时间,因此需要存储“定货信息”,同样的,一个系统也只有一个1层数据流图。
- 2层到n层数据流图
接下来应该对功能级数据流图中描绘的系统主要功能进一步细化。考虑通过系统的逻辑数据流,当发生一个事务时必须首先接收它;随后按照事务的内容修改库存清单;最后如果更新后的库存量少于库存量临界值时,则应该再次定货,也就是需要处理定货信息。因此,把“处理事务”这个功能分解为下述3个步骤:“接收事务”、“更新库存清单”和“处理订货”,下图就是事务1第2层的数据流图,后面可能还可以细化到第n层,以此类推。
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
原文链接:https://blog.youkuaiyun.com/I_r_o_n_M_a_n/article/details/121309525
Entity Relationship Diagram
意义:设计数据库实体关系画的图。
解释:ER图可太多种了,这里说一下我知道的两种吧
下面这个图方形就是实体,菱形就是关系,橙实线就是连接的线,实线上面的数字就是数量关系,圆形就是属性,黑实线是关系隶属于某个实体的意思。
下面每一个圆角矩形(或者矩形)是一个实体,实体里面有名称和属性。数量关系在箭头里。
箭头代表的数量关系如下:
注意:在实际数据库设计时,如果遇到多对多,转换为两张表的多对一关系。
比如: 假设我们有两个实体: 学生 (Student) 表:包含 StudentID 和其他学生信息。 课程 (Course) 表:包含
CourseID 和其他课程信息。 多对多关系: 学生可以选修多门课程,一门课程可以被多个学生选修。 中间表设计: 引入一个 选课表
(Enrollment): StudentID:引用学生表的主键。 CourseID:引用课程表的主键。 可以额外加字段,例如
EnrollmentDate。
Box-and-Line Diagram
意义:用于描述软件系统中的各个组件及其相互之间的连接和交互。这种图表通过矩形框(Boxes)表示系统中的各个组件,并通过线条(Lines)表示这些组件之间的连接和数据流。
解释:方框就是组件,线条就是连接,连箭头都不需要画,特别简单,主要就是描述大致系统的构成以及各个组件基本关系。
框线图
Block Diagram
这个真的。。。没有任何定义,全网都是查不到的,坑死人了,书里面提到了但是也没有明确的定义。就是方框与箭头的组合(箭头类型还可以自己定义),用来提供系统的概览,示例如下图:
结束啦,爱你们,祝期末顺利!
参考文章
注:所有参考文章均在文中作有标注
[1] https://blog.youkuaiyun.com/lfdfhl/article/details/134581558
[2] https://blog.youkuaiyun.com/fanxiaobin577328725/article/details/51700528
[3] https://blog.youkuaiyun.com/naozibuok/article/details/144067932
[4] https://blog.youkuaiyun.com/qq_41784749/article/details/112242348
[5] https://blog.youkuaiyun.com/fly_zxy/article/details/80911942
[6] https://blog.youkuaiyun.com/I_r_o_n_M_a_n/article/details/121309525