目录
UML系统建模
一、概述
1.是什么
Unifified Modeling Language
统一建模语言，又称
标准建模语言
。
是用来对软件密集系统进行可视化建模的一种语言。语言，也就是一个表达思想的符号约定。
2.为什么
统一的建模语言，能够是团队协作力更好
3.好处
- 团队或架构设计互相交流，必然需要一种沟通语言
- 是一门技能，不一定用到，但是作为架构师应该知道
- 有其他的表达办法，但是用习惯后，uml真的很方便易用
4.坏处
- uml是鸡肋，离程序员真正需要的设计工具还差得很远。只有为数不多的程序员使用这个工具交流想法， 而没有用在具体工作中。
- 简单的软件系统，使用uml，会耗费较多的时间
5.小结
- 不要把uml过度神化
- 一个表达想法的工具而已
- 当用则用，不要刻意去套
二、线（关系）
-
泛化（Generalization）
定义：
- java里的extends，可用于接口与接口之间，或父子类之间
- 单向，箭头指向父类，如Tiger指向Animal
代码：
//类
public class Animal {
}
public class Cat extends Animal {
}
//接口
public interface Action {
}
public interface Jump extends Action {
}
-
实现（Realization）
定义：
- java里的implements，箭头指向接口（指向父类）
- 单向，如Tiger扩展了Sleep接口，那么箭头指向Sleep（单向）
代码：
public interface Jump { }
public class Tiger implements Jump { }-
依赖（Dependency）
定义：
- 某个类或对象实例，依赖于另一个而存在，在其关键方法中用到了对方（关键依赖）
- 如果一方属性发生变动，另一方可能会收到影响（变动影响）
- 一般为单向，例如动物依赖于食物，eat(Food food)（单向）
- 类比在表结构上，更像是外键
代码：方法参数，局部变量
-
关联（Association）
定义：
- 是一种拥有的关系，双方不一定属于同一类事物，箭头指向被拥有者（拥有单个(成员变量)，不能为List，指向被拥）
- 可以单向，也可以双向，例如Tiger与Zookeeper（单双向）
- 类比在表结构上，更像是存在中间表关系（依赖中间人）
代码：成员变量
-
聚合（Aggregation）
OR 
定义：
- 单向，空心菱形起始的箭头，箭头指向被拥有者（指向单体）
- 一种很弱的拥有关系，A可以拥有B，但是不是离了B就无法生存（弱拥有）
- 群体与个体的关系，如小组包含组员（群体与单体）
代码：成员变量，多为集合
-
组合（Composition）
OR 
定义：
- 单向，实心菱形为起始，箭头指向子模块 (指向单体)
- 一种整体与部分的关系，A是由B组成的，离开B则不完整。（整体与部分）
- 单向，如人和四肢的关系（单向）
代码：成员变量，多为集合
小结：
- 继承和实现几乎不会搞混，一个上下父子关系，一个是类与接口
- 组合与聚合要注意，聚合为聚集，群体与个体。组合为组成，整体与部分
- 关联和依赖要注意，关联一般为同级别有相关性，这种相关性是长期存在的。依赖为需求关系，一方需要依赖另一方，可能会因另一方的改变而改变。
- 关系的强弱顺序：继承=实现>组合>聚合>关联>依赖 （两个之间实心联系最强）
三、图
- 用例图：从用户角度描述系统功能。
- 类图：描述系统中类的静态结构。
- 对象图：系统中的多个对象在某一时刻的状态。
- 状态图：是描述状态到状态控制流，用于表达系统状态的变化
- 活动图：描述了业务实现用例的工作流程，强调的是动作之间的衔接
- 序列图：对象之间的动态合作关系，强调对象发送消息的顺序
- 协作图：描述对象之间的协助关系，强调对象之间的合作关系
- 组件图：描述系统各个组件及其相关关系的静态视图
- 部署图：定义系统中软硬件的物理体系结构
-
类图 ★
1）说明
- 面向对象系统建模中最常用和最重要的图，是定义其它图的基础
- 主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型
- 描述细化相关的属性和操作，是一个对业务模型面向对象化的过程，也是对系统的约束
- 可以直接构建可执行代码，但真正使用的场景相对较少
2）可用元素
- 类：
tips: -是private、#protected、*package、+public ; 第二层是属性，第一层为方法，返回值为int
- 接口：
- 关系：可以使用上述中的6大关系
3 ) 案例实例
订单类图从业务模型出发，用面向对象思想，订单业务中的模型抽象为一个个对象
①元素：
- 人物类：Seller，Buyer，User
- 商品类：Shop，Product
- 交易环节类：Cart，Order，Invoice，AliPay，WeichatPay，ICBCPay...
- 交易环节接口：Pay
- 促销相关类：DiscountPromotion，ReductionPromotion...
- 促销接口：Promotion
②关系：
- 关联：Order→Seller，Buyer，Pay；Shop→Seller
- 依赖：Order→Cart→Promotion，Invoice；
- 组合：Shop→Product
- 聚合：Cart→Product
- 泛化：Buyer，Seller→User
- 实现：DiscountPromotion，ReductionPromotion→Promotion；AliPay，WeichatPay，ICBCPay→Pay
-
对象图 ★
1）说明
- 对象图和类图一样反映系统的静态过程，但它表达的是一个实际场景。对象图显示某时刻对象和对象之间的关系。可看成一个类图的快照。
- 对象图是类图的实例，所以几乎使用与类图完全相同的标识。
2 )可用元素
对象：
关系：
- 对象图因为是运行在某个时间节点的对象镜像，所以关系比较单一，描述的是类与类的实例之间。不涉及接口
- 关联：对象之间存在关联关系，如用户和订单
- 依赖：对象实例之间的依赖关系，如商品对象依赖店铺
3 ）图例
4 ) 案例实例
对象图表达的是下订单的时刻，系统存在的对象及对象之间的关联关系。对象具备了实际的属性值
①元素：
- 与类图一致，但是接口将不复存在，而变为实际实现类
- Cart生命周期终结，Invoice还没诞生，Product，Promotion依附在了订单上
- 对象上的属性具备了实际值，不再是泛化的类属性的概念
②关系：
- 对象之间变为实例关联（Instance link），泛化和实现不再被使用。
- 弱类型可以使用依赖，比如Order与打折的Promotion
-
组件图 ☆
1 )说明
- UML1.1中，组件图是用来描述一个系统的物理构件。包括文件，可执行文件，库等
- UML2 中，关注组件间的关联（使用什么接口，通过什么端口通讯），强调通过接口来描述组件行为
- 对于后端来说，组件图比较适用于 SOA 架构、微服务架构，描述整个系统的结构以及子系统间的通讯方式
- 对于前端来说，组件图适合在使用类似 react、vue 这样组件化的前端技术框架时，表达对组件的设计，比如 一个页面会有个骨架组件，骨架组件包含了导航组件，列表组件等等
2）可用元素
- 组件：描述的是系统的其中一个组成部分，一个完整的可独立服务的模块或单元，比如订单服务，k8s里的一个pod
- 部件：组件内可能细化为多个子模块
- 端口：组件对外提供服务就必须暴露对应的端口。如http rest服务默认的80
- 接口：部件/组件之间的一种约定，分提供者和需求者同时展示了某个部件提供出的功能
关系 :
- 泛化：用于接口与接口之间存在的父子关系，组件之间也可能存在，但相对用的较少
- 实现：接口和其实现者（提供服务的组件）之间
- 关联：Require link / Connector ，接口与调用者（需要接口的组件）之间
3 ）图例
-
部署图 ☆
1 )说明
- 一种展示运行时进行处理的节点和在节点上存在的组件配置的图。
- 阐述了在实际应用中软件和它的运行环境的关系，并且描述了软件部署在硬件上的具体方式。
2）可用元素
节点
早先单实例
MVC
架构下，节点可以认为是某台物理服务器，微服务及容器化下，物理服务器大多纳入编排管
理，
docker
实例由系统在物理节点见自由调度，组件无法锁定在某个固定物理节点上，这种环境下的
node
可
以理解为一个容器，或
k8s
中的
pod
。
组件实例
相当于组件里的实例化，类比于类和对象
关系
- 依赖：发生于组件之间，如用户组件依赖于订单组件
- 关联：node association，发生于节点之间，例如应用服务器需要关联mysql数据库
3 ）图例
-
用例图 ★
1 )说明
- 用例图是用来描述系统功能的技术，表示一个系统中用例与参与者及其关系的图
- 主要用于需求分析阶段，和产品文档比较贴近
- 用例图相当于从用户的视角来描述和建模整个系统，分析系统的功能与行为。
2）可用元素
参与者：使用系统的人，有多少种角色就有多少参与者。
用例：参与者可用做的事情
关系
- 泛化：参与者之间可用泛化，例如用户与普通会员；用例也可用泛化，如用户管理与修改密码
- 关联：发生于参与者和用例之间，表示该角色可用有哪些用例（行为）
- 依赖：发生与用例之间，例如登录依赖于注册
3 ）图例
4 ) 案例实例
B2C
交易用例图
用例图从订单系统使用人角色出发，反馈订单体系里面有哪些人，可以做哪些事情
1
）业务需求：
- 买家：浏览商品，下单、支付、签收
- 卖家：开店，确认订单，发货，商品维护
- 双方：退货，换货，评价，收藏
-
交互图 ★
交互图分为序列图和协作图，两者既可以相互转换而不丢失信息，又存在一定差异。下面分开讲再类比
1、时序图
1 )说明
- 序列图主要用于按照交互发生的一系列顺序，显示对象之间的消息或行为传递。
- 序列图可以形象表达整个流程，和流程图有相似之处，但是流程图偏业务逻辑，序列图则是系统面向对象化建模后，对应到对象上的交互过程。趋向于开发者角度。
2）可用元素
- 对象：提供功能和交互的类的实例
- 参与者：同用例种的参与人，多为一段流程的发起点
- 时间线：对象在整个交互流程中的生命周期
- 消息：对象间需要发送和返回的消息，可以自己发给自己
- 外部参考：序列图可以引入外部的一段作为参考，或参与序列中与当前图的元素交互
- 片段：将某一段序列纳入片段管理，该片段像原子一样，发生某些整体的行为，例如循环
- 关系：不会用到6大关系，相互之间使用message交互。代表的是信息流动。
3 ）图例
4 ) 案例实例
序列图反应下单到支付完成这段时间里，各个对象怎么协作和交互，互相之间需要传递什么消息。
①元素
- 人物：Buyer
- 对象：Product，Cart，Order，Promotion，Pay，AliPay（外部）
②时间序列
- 顺向：Buyer→筛选→Product→添加→Cart→促销结算→Promotion→下单→Order→支付→Pay→跳转
- →AliPay
- 回路：Buyer←通知←Order←开单←Pay←回调←AliPay环路：Cart ←→增删商品
2、协作图
1 )说明
- 协作图与时序图类似，二者都是用对象间的交互来描述用例的。
- 两者关注角度稍有不同，时序图强调交互的时间次序，协作图强调交互的空间结构。
2）可用元素
- 参与者：系统参与的角色
- 对象：同时序图，系统中实例化的对象
- 关联：对象间的关联关系
- 消息：依附于关联而存在，承载了对象间要传递的信息
- 关系：不会用到6大关系，相互之间使用message交互。代表的是信息流动。
3 ）图例
两种交互图可以相互转化，类比如下：
4 ) 案例实例
序列图反应下单到支付完成这段时间里，各个对象怎么协作和交互，互相之间需要传递什么消息。
①元素
- 人物：Buyer
- 对象：Product，Cart，Order，Promotion，Pay，AliPay（外部）
②时间序列
- 顺向：Buyer→筛选→Product→添加→Cart→促销结算→Promotion→下单→Order→支付→Pay→跳转
- →AliPay
- 回路：Buyer←通知←Order←开单←Pay←回调←AliPay环路：Cart ←→增删商品
-
状态机 ☆
状态机分为状态图和活动图
1、状态图
1 )说明
- 描述一个实体基于事件反应的动态行为，它有两方面的价值，一是反映对象可能有哪些状态，二是这些状态之间是如何流转的，需要什么样的条件下进入什么样的状态
2）可用元素
- 状态：某一个时间点，对象所在的状态
- 转移：连接状态之间，因为状态时可以互相变化转移的
- 分支/会合点：状态变化中可能产生分叉或交会，如确认收货后，双方互评产生分叉
- 开始/结束：状态的起始与终结
- 同步点：需要多个分支状态都具备时使用。多用于并行协作处理的状态流转，如互评都完成后，订单才算终结
- 关系：只有转移关系，表示状态之间的变化
3 ）图例
2、活动图
1 )说明
- 活动图用于企业的业务流程建模，是对内部活动与活动之间流转动作的表达
- 活动图类比流程图：活动图存在分支与交会，可以表达并行存在的活动，流程图多为是与否分支判断
- 活动图类比状态图：关注不同，状态图强调行为的结果（下一个状态是什么），活动图在乎行为的动作（下一步干什么）。两者可以理解为穿插配合，一动一静，活动可能会触发下一步不同的状态
2）可用元素
- 活动：表达系统中，或对象内的某一个可以发生的动作
- 对象：活动的发生者，或交互者
- 流转：活动的跳转，即下一步指向谁判定：类似与流程图里的判决，根据条件产生不同的流转
- 同步：并行流转下的汇集，不同于流程图的地方
- 起始/结束：活动的发起与终结
- 泳道：对UML活动图中的活动进行分组，同一类活动在一个泳道上，清晰明了
- 关系：只有流转，也就是活动的跳转，表示下一个活动是啥
3 ）图例
tips:工具选择有：Rational Rose 、RSA、 Enterprise Architect、StarUML、PowerDesigner
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
