UML-14图总汇
UML图的分类
14种uml图的说明
行为类的图
序列图(也叫做/顺序图/时序图)
时序图和通讯图被称为交互图,他们的区别在于时序图强调时间顺序,通讯图强调的是对象之间的组织结构。
包含的元素
- 角色(actor),一般就是参与者,也可以是定时器之类的触发器
- 对象(object),这个可以是系统服务,也可以是简单的服务类,也可以是整个系统,设备,组织机构等
- 生命线(LifeLine),
- 消息(Message)(直线+ 大于箭头)
- 同步消息(直线+三角箭头)
- 异步消息(直线加半角箭头)
- 放回消息(虚线+小于箭头)
- 子反消息(实现+三角箭头)
- 控制焦点(Activation),表示对象处于活跃状态
- 组合片段(组合片段有13中),用于表示逻辑控制
- opt,类似简单if
- alt,类似if else
- loop,循环
- par 并行
- seq 弱串行
- strict 强串行
- break 中断
- ref 引用
- critical 关键 region 标志在组合片段中先于其他交互片断发生的交互;
- consider 考虑
- ignore 忽略
- assert 断言
- neg 否定
绘制方式
- 认清交互边界,和主次,只画关注的重点逻辑
- 识别角色和对象,角色放在最左边,对像按照重要程度或者交互先后顺序依次放在右边。
- 确认对象和对象之间的消息有哪些
- 对象和角色一般是名词,消息是动词
- 按照消息先后顺序给消息编号
- 控制焦点的两段因该是消息封顶,不要超出消息
下图检查IP变化的程序的时序图
通讯图(协作图)(UML2.0叫做改名为通信图,1.0叫做协作图)
通讯图用于描述系统对象之间的消息传递和通信,和时序图是异构关系。时序图侧重时间顺序,通讯图侧重对交互过程和对象之间关系。
包含元素:
- 对象
用矩形表示 - 链
用箭头表示 - 消息
用带有编号的文字描述
下图检查IP变化的程序的通讯图
活动图
用于描述活动流程,活动图是一种流程图,但是活动图加入了面向对象的一些思想,并且能够描述并发流程,活动图传递的是控制流
包含元素
-
开始,结束节点
开始实心圆,结束圆圈内有实心圆 -
活动状态(actions)
圆矩(动词) -
控制流(control flow)
箭头线表示 -
分支和合并(decision and merge)
菱形表示分支,多选一,类似if else -
分叉和汇合(fork-join)
粗横线表示分叉,表示并行 -
泳道(partition)
泳道有横向和纵向两种,表示活动在那个对象上执行 -
对象和对象流
活动图对面向对象的优化,需要配合泳道一起使用,用于填补活动图与面向对象思想之间的梳理。
用矩形表示(对象),虚线箭头连接,很少用(感觉是在活动图的每个泳道上强行加上对象和对象流) -
扩展区域 ?
检查IP变化的程序的活动图
商品购买活动图
状态图
状态图反映的是状态变化和事件之间的关系
包含元素
- 状态(开始状态,结束状态,和中间状态),开始状态用实心圆表示,结束用圆环套实心圆表示,中间状态用圆角矩形表示
- 状态名
- 状态变量
- 状态活动
- entry:进入这个状态的时候触发
- exit:退出这个状态的时候触发
- do:这个状态的过程中会执行的活动
- 状态转移
用箭头表示连接两个不同的状态,表示状态发生转移 - 事件和动作
用于转移连线上的标注,表示状态因为什么事件而发生状态变化,表达式为:触发事件[参数条件]/动作
如下图是检测IP变化的状态图,此状态图只有两种中间状态,没有结束状态
用例图
描述系统能做什么,通过用户行为例举描述系统的功能需求。
系统非功能需求(性能需求)可以通过场景和质量属性来描述。
包含元素:
- 参与者
- 用例
- 联系
- 参与者和用例之间用实线箭头连接
- 用例和用例之间三种关系
- 包含(使用用例A一定会使用用例B)
使用虚线+箭头,中间使用《include》 表示,箭头指向被包含用例 - 扩展(使用用例A,特定情况会使用用例B)
使用虚线+箭头,中间 使用 《extend》 表示,箭头由拓展用例指向基本用例 - 泛化(用例A有两种实现方式,B和C)
用实线+空心三角表示,子类指向父类
- 包含(使用用例A一定会使用用例B)
下面是检查IP变化的用例图
定时图(时间图)(UML2.0)
用于描述状态随着时间而变化的场景
包含元素:
- 时间线
x轴表示时间线 - 生命线
- 状态生命线
- 值生命线
- 状态
- 状态生命线在y轴方向用不同的高度表示不同的状态
- 值生命线用在平行线中间标注状态,平行线相加表示状态变化
- 消息
两个时间线之间传递信息的载体,用箭头表示 - 事件
引起状态变化的事件,正常都是时间改变状态,特殊情况的事件才需要生命线的开始位置标注 - 时间约束?
- 期限约束?
洗衣机定时图(状态生命线)
画图工具不支持定时图元素,用别的图形代替的
洗衣机定时图(值生命线)
画图工具不支持定时图元素,用别的图形代替的
交互概览图(UML2.0)
本质就是可以用交互图代替活动节点的活动图,每个单独的活动都可以被描绘为包含嵌套交互图的框架
,是交互图和活动图的结合使用。
包含元素
- 活动图的所有元素
- 交互元素
直接在矩形框里面绘制内嵌的交互图,并且在交互框上协商交互图的类型,然后直接在交互框里面绘制内嵌的交互图 - 交互发生
表示引用别的交互图,在交互框的标题上写上ref,在交互框里面写上引用的交互图的名字
绘制方法又两种
- 先用活动图描述主线活动,然后用顺序图(一般用顺序图,也可以是别的交互图)补充完善具体的活动节点。(一般用这种)
- 以顺序图为主,用活动图细化顺序图中某些重要的对象的活动描述。
交互概览图的细节可以使用时序图以外应该还可以用别的交互图来描述,比如通讯图,定时图,甚至是交互概览图。
购买指定商品的交互概览图
查询商品流程直接画在交互概览图中的,登录流程引用的另外的登录通信图
结构类的图
类图
描述的类和类之间的静态关系,是逻辑层面的模型
包含元素
- 类
类里面有类名,属性,和方法,可以更具需要不写属性和方法的类型,也可以属性和方法都不写,方法和属性前面的+-号表示访问权限+
公有-
私有#
受保护的~
是包权限
- 关系
- 依赖:没有直接关系
虚线+箭头 - 关联:有直接关系,但是没有整体和部分关系,是平级关系而不是整体和部分关系,多对多一般是关联关系
实线+双向箭头 - 组合:一般是一对多,整体和部分的关系,整体和部分不可分离,生命周期相同
实线+实心菱(部分指向整体) - 聚合:一般是一对多,整体和部分的关系,整体和部分可以分离,生命周期不同
实线+空心菱 - 泛化:泛化是子类
实线+空心三角箭头(子指向父) - 实现:实现是接口
虚线+空心三角箭头
- 依赖:没有直接关系
类图之间关系还有多重度的标注,也就是1对1,一对多,和多对多,出了泛化和实现都可以用几对几来指明多重度
判断类之间关系步骤
-
应该先考虑他们是否有父子关系(实现和泛化)
接口和实现类之间是实现关系,父类和子类之间是泛化(继承)关系举例子:正常设计支付程序,支付和微信支付就是实现关系 举例子2:如果之前没有为支付设计接口,只有现金支付的实现,后来并且没有提取高层接口,只是实现的微信支付继承了现金支付,这就是泛化
-
然后判断他们是否整体和部分中间的关系(组合和聚合)
整体和部分生命周期一样就是组合,生命周期可以不一样就是聚合举例子1:人和心脏,一般来说他们生命周期是一样的不可分隔,是组合 举例子2:电脑和内存条,内存可以拔下来插到别的电脑上,是聚合 备注:组合和聚合按照主观常识判断即可,不用吹毛求疵,毕竟心脏也是可换的,内存取了运行的电脑也回死机。
-
然后判断他们是有有直接关系(关联和依赖)
有直接关系就是关联,没有直接关系但有间接依赖关系就是依赖(有依赖关系的前提是相互有影响,没有影响他们之间不存在关系)举例子1:冰箱和冰箱里面放的东西,他们是关联关系(不存在整体和部分,冰箱里面可以不放东西也是一个完整的冰箱) 举例子2:冰箱和入户开关是依赖关系,他们没有直接的连续,冰箱和供电插座有关联关系,插座和开关有有关联关系,但是冰箱和开关没有直接关系,但是关了开关,冰箱就停了,存在依赖。
获取IP变化的程序的类图
对象图
对象图描述某一时刻系统的对象的静态状态,或者是类图某一时刻的实例
包含元素
-
对象
-
对象名
格式为 对象名:类名 ,对象名称下面加下划线用于区分对象图和类图,对象名字可以省略
-
属性
没有方法,并且每个属性都有当前的值
-
-
链
直线表示,没有箭头,没有多重性
电脑组成的对象图
对象图相对简单,注意画对象图的时候,对象名的命名方式,没有方法,属性有具体的值,对象之间关联用没有箭头的实线连接,并且没有多重度
复合结构图(也叫组合结构图,uml2.0)
用于表示整体和部分的关系
包含的元素
-
组件(用矩形表示,右上角有和插头标记)
- 部件
部件内部的矩形表示 - 接口
- 需求接口
在边框上用横向棒棒糖表示 - 提供
接口在边框上用横向撑衣杆表示 - 端口
在边上用小矩形加文字描述表示
- 需求接口
- 部件
-
类元(一种特殊的组件),类元是类,接口等部件的的高层抽象
-
协作
用虚线椭圆表示一项功能由一系列角色承担 -
元素关系
-
委托
定义外部接口和端口是由那个内部部件提供的,用实线箭头表示 -
绑定,表现,发生
连接协作和类元
-
包图(uml2.0)
当对一个比较复杂的软件系统进行建模时,会有大量的类、接口、组件、节点和图需要处理;如果放在同一个地方的话,信息量非常的大,显得很乱,不方便查询,所以就对这些信息进行分组,将语义或者功能相同的放在同一个包中,这样就便于理解和处理整个模型。而包图就是描述包与包之间的关系。 每一个包就是一个独立的命名空间,两个不同的包之中可以有相同的元素名,只是所处的包不同,其全名不同。
包含的元素
- 包
- 包名
- 包内元素
- 类
- 接口
- 构件
- 节点
- 协作
- 用例
- 图
- 子包
- 关系
- 依赖(包元素之间有了依赖,包也就有了依赖)
- 引入(Import )
导入整个包,包里面所有元素都可以使用 - 访问(access)
访问里面包里面的一些元素
- 引入(Import )
- 泛化
一个包的元素是可以用另外一个包替换,可以在父包上面标注
- 依赖(包元素之间有了依赖,包也就有了依赖)
包元素的可见性
+
公有的-
私有的#
保护的,子类可用
包的重用原则
- 重用等价原则
对于同类可重用的模型元素尽量放到一个包中,不要把可重用模型元素和不可重用的模型元素混到一个包中。 - 共同重用原则
把同一个应用要重用的多个模型元素放到同一个包中,以减少包间的依赖,提高包的独立性。 - 共同封闭原则
把可能同时修改,同时维护的模型元素放到一个包中,以便于今后维护和升级。 - 非循环依赖原则
包之间不要循环依赖
常见三层架构的包图
包图不关心内部元素的时候可以直接在内部写上包名
部署图
描述的是硬件拓扑以及在此结构上执行的软件,说白了就是软件是怎么部署到硬件设备上的,是物理层面的模型
包含的元素
-
节点
表示服务器主机,用立体长矩形表示,命名方式可以直接写节点类型,也可以是 实例名:节点类型
-
物件(构件,组件)
表示需要部署的软件服务,用矩形框加合适的图标表示,里面写上部署的软件服务的名字 -
部署
把物件画在节点里面,物件之间如果有依赖关系,可以用虚线箭头连接,物件和节点外的构建也可以用虚线箭头表示依赖关系,但是这样画出来会有点乱 -
通信路径
用于描述节点和节点之间的通信方式,用实线连接,上面写上通信协议通信关系可以补充多重度,和类图的多重度类似
电商业务部署图
组件图(也叫构件图,uml2.0重新定义)
用于描述构件之间的依赖关系,描述实现层面的模型
包含元素
- 构件
- 构件名字
- 构件接口(依赖可以直接指向被依赖构件,也可以指向被依赖构件接口)
- 构件之间依赖关系
用虚线箭头表示依赖关系
下图是描述的一个电商的构建图
剖面图(有叫做轮廓图,uml2.0)
作为uml的扩展
包含元素
- 原型
用于扩展可用的 UML 元素。它们允许您创建、编辑或派生一个新的元素或构建块,然后可以直接在图表中使用。 - 标记值
将其视为现有模型添加新属性。一个新的标记值将分别产生一个新的关键字。 - 约束
不知道怎么画
不属于uml的体系的图说明
流程图
https://www.cnblogs.com/cxygg/p/18282296
数据流图
能耍的时候就一定要耍,不能耍的时候一定要学。
--天道酬勤,贵在坚持posted on 2024-06-10 23:00 zhangyukun 阅读(39) 评论(0) 编辑 收藏 举报