共计 8221 个字符，预计需要花费 21 分钟才能阅读完成。
UML 零碎建模
1 概述
1.1 课程概述
- 会集 UML 及其相干的一些话题
- 回顾 UML 相干的符号与概念
- 以电商订单相干业务为例，借助 UML 实现零碎建模
- 将 UML 变成晋升建模效率，表白架构思维的工具
1.2 什么是 UML
Unified Modeling Language 对立建模语言，又称规范建模语言。是用来对软件密集零碎进行可视化建模的一种语言。语言，也就是一个表达思想的符号约定。
1.3 UML 的倒退与版本
- 建模语言呈现在二十世纪 70 年代，80 年代末开始迅速倒退，建模语言达到了 50 多种，百家争鸣
- 起初，Rumbaugh 于 1994 年退出 Booch 所在的 Rational 公司，他们一起钻研一种对立的办法
- 一年后，Unified Method 0.8 诞生
- 通过他们三年的共同努力，UML0.9 和 UML0.91 于 1996 年相继面世。
- 尔后 UML 创始人 Booch 等人，邀请计算机界的知名人士与企业 IBM，HP，Microsoft，Oracle 等对 UML 进行评论，听取意见。
- 1997 年 1 月，Rational 公司向 OMG（对象治理组织）提交了 UML1.0
- 1997 年 11 月，OMG 发表承受 UML，认定为规范的建模语言
- 1998 年公布了 UML 1.2
- 1999 年公布了 UML 1.3
- 2003 年 3 月公布了 UML 1.5
- 2004 年推出 UML2.0
1.4 UML 能够做什么
从命名上剖析：对立、建模、语言
对立：没有规矩不成方圆，它指定了一种规范，一种束缚，使得大家的表白变得统一。它被 OMG（Object Management Group）所认可。
OMG 是一个国际化的、凋谢成员的、非盈利性的计算机行业规范协会，该协会成立于 1989 年，他是软件行业中一个规范的认可。包含客户、领域专家、分析师、设计师、程序员、测试工程师及培训人员等。UML 成为他们工作中对立的沟通工具，用于充沛了解和表白本人所关注的内容。
建模：简单业务零碎建模，即建设软件系统模型。UML 的创始人之一 Booch，曾用建一座摩天大楼来比喻 UML 的必要性。简略零碎下，可有可无，零碎简单或大到肯定水平，建模和文档成为零碎周期里十分重要的一环。
语言：面向对象思维的表白。相互之间的沟通工具。一种依照特定规定和模式组成的符号零碎。
1.5 学习 UML 的意义
- 团队或架构设计相互交换，必然须要一种沟通语言
- 是一门技能，不肯定用到，然而作为架构师应该晓得
- 有其余的表白方法，然而用习惯后，UML 真的很不便易用
1.6 对于 UML 的争议
观点一：UML 是鸡肋，离程序员真正须要的设计工具还差得很远。只有为数不多的程序员应用这个工具交换想法，而没有用在具体工作中。
观点二：UML 设计相当的谨严与全面，在面向对象的零碎架构上，能够便捷的表白你想要表白的所有想法，柔美切无可替代。
个人观点：一项技能和工具，学会并不难，须要的时候能拿来用就好，艺不压身。
1.7 切忌形式化
- 不要把 UML 适度神化
- 一个表白想法的工具而已
- 当用则用，不要刻意去套
2 实践篇
2.1 关系
关系是事实世界中事物与事物之间互相关系的符号表白，形象到面向对象理念上，大抵分为 6 种。
2.1.1 泛化（Generalization）
定义：
- Java 里的 extends，可用于接口与接口之间，或父子类之间
- 单向，箭头指向父类，如 Tiger 指向 Animal
代码：
// 类
public class Animal {
}
public class Cat extends Animal {
}
// 接口
public interface Action {
}
public interface Jump extends Action {}2.1.2 实现（Realization）
定义：
- Java 里的 implements，箭头指向接口
- 单向，如 Tiger 扩大了 Sleep 接口，那么箭头指向 Sleep
代码：
public interface Jump {
}
public class Tiger implements Jump {}2.1.3 依赖（Dependency）
定义：
- 某个类或对象实例，依赖于另一个而存在，在其要害办法中用到了对方
- 如果一方属性产生变动，另一方可能会收到影响
- 个别为单向，例如动物依赖于食物，eat(Food food)
- 类比在表构造上，更像是外键
代码：办法参数，局部变量
2.1.4 关联（Association）
定义：
- 是一种领有的关系，单方不肯定属于同一类事物，箭头指向被拥有者
- 能够单向，也能够双向，例如 Tiger 与 Zookeeper
- 类比在表构造上，更像是存在两头表关系
代码：成员变量
2.1.5 聚合（Aggregation）
定义：
- 单向，空心菱形起始的箭头，箭头指向被拥有者
- 一种很弱的领有关系，A 能够领有 B，然而不是离了 B 就无奈生存
- 群体与个体的关系，如小组蕴含组员
代码：成员变量，多为汇合
2.1.6 组合（Composition）
定义：
- 单向，实心菱形为起始，箭头指向子模块
- 一种整体与局部的关系，A 是由 B 组成的，来到 B 则不残缺。
- 单向，如人和四肢的关系
代码：成员变量，多为汇合
2.1.7 实例
一张图涵盖所有的关系：
2.1.8 总结
- 继承和实现简直不会搞混，一个高低父子关系，一个是类与接口
- 组合与聚合要留神，聚合为汇集，群体与个体。组合为组成，整体与局部
- 关联和依赖要留神，关联个别为同级别有相关性，这种相关性是长期存在的。依赖为需要关系，一方须要依赖另一方，可能会因另一方的扭转而扭转。
- 关系的强弱程序：继承 = 实现 > 组合 > 聚合 > 关联 > 依赖
2.2 图
2.2.1 概述
UML 中的图形十分多，按类型分为结构图和行为图，其中，最罕用，最典型的为 9 种，上面离开来介绍。
- 用例图：从用户角度形容零碎性能。
- 类图：形容零碎中类的动态构造。
- 对象图：零碎中的多个对象在某一时刻的状态。
- 状态图：是形容状态到状态控制流，用于表白零碎状态的变动
- 流动图：形容了业务实现用例的工作流程，强调的是动作之间的连接
- 序列图：对象之间的动静单干关系，强调对象发送音讯的程序
- 合作图：形容对象之间的帮助关系，强调对象之间的单干关系
- 组件图：形容零碎各个组件及其相干关系的动态视图
- 部署图：定义零碎中软硬件的物理体系结构
2.2.2 类图
1）阐明
- 面向对象零碎建模中最罕用和最重要的图，是定义其它图的根底
- 次要是用来显示零碎中的类、接口以及它们之间的动态构造和关系的一种动态模型
- 形容细化相干的属性和操作，是一个对业务模型面向对象化的过程，也是对系统的束缚
- 能够间接构建可执行代码，但真正应用的场景绝对较少
2）可用元素
- 类：
- 接口：
- 关系：能够应用上述中的 6 大关系。
3）实例
2.2.3 对象图
1）阐明
- 对象图和类图一样反映零碎的动态过程，但它表白的是一个理论场景。
- 对象图显示某时刻对象和对象之间的关系。可看成一个类图的快照。
- 对象图是类图的实例，所以简直应用与类图完全相同的标识。
2）可用元素
- 对象：
3）关系
对象图因为是运行在某个工夫节点的对象镜像，所以关系比拟繁多，形容的是类与类的实例之间。不波及接口
- 关联：对象之间存在关联关系，如用户和订单
- 依赖：对象实例之间的依赖关系，如商品对象依赖店铺
4）图例
2.2.4 组件图
1）阐明
- UML1.1 中，组件图是用来形容一个零碎的物理构件。包含文件，可执行文件，库等
- UML2 中，关注组件间的关联（应用什么接口，通过什么端口通信），强调通过接口来形容组件行为
- 对于后端来说，组件图比拟实用于 SOA 架构、微服务架构，形容整个零碎的构造以及子系统间的通信形式
- 对于前端来说，组件图适宜在应用相似 react、vue 这样组件化的前端技术框架时，表白对组件的设计，比方一个页面会有个骨架组件，骨架组件蕴含了导航组件，列表组件等等
2）可用元素
- 组件：形容的是零碎的其中一个组成部分，一个残缺的可独立服务的模块或单元，比方订单服务，k8s 里的一个 pod
- 部件：组件内可能细化为多个子模块
- 端口：组件对外提供服务就必须裸露对应的端口。如 http rest 服务默认的 80
- 接口：部件 / 组件之间的一种约定，分提供者和需求者同时展现了某个部件提供出的性能
3）关系
- 泛化：用于接口与接口之间存在的父子关系，组件之间也可能存在，但绝对用的较少
- 实现：接口和其实现者（提供服务的组件）之间
- 关联：Require link / Connector，接口与调用者（须要接口的组件）之间
4）图例
2.2.5 部署图
1）阐明
- 一种展现运行时进行解决的节点和在节点上存在的组件配置的图。
- 论述了在理论利用中软件和它的运行环境的关系，并且形容了软件部署在硬件上的具体形式。
2）可用元素
-
节点：
新近单实例 MVC 架构下，节点能够认为是某台物理服务器，微服务及容器化下，物理服务器大多纳入编排治理，docker 实例由零碎在物理节点见自在调度，组件无奈锁定在某个固定物理节点上，这种环境下的 node 能够了解为一个容器，或 k8s 中的 pod。
-
组件实例
相当于组件里的实例化，类比于类和对象
3）关系
- 依赖：产生于组件之间，如用户组件依赖于订单组件
- 关联：node association，产生于节点之间，例如应用服务器须要关联 mysql 数据库
4）图例
2.2.6 用例图
1）阐明
- 用例图是用来形容零碎性能的技术，示意一个零碎中用例与参与者及其关系的图
- 次要用于需要分析阶段，和产品文档比拟贴近
- 用例图相当于从用户的视角来形容和建模整个零碎，剖析零碎的性能与行为。
2）可用元素
- 参与者：应用零碎的人，有多少种角色就有多少参与者。
- 用例：参与者可用做的事件
3）关系
- 泛化：参与者之间可用泛化，例如用户与一般会员；用例也可用泛化，如用户治理与批改明码
- 关联：产生于参与者和用例之间，示意该角色可用有哪些用例（行为）
- 依赖：产生与用例之间，例如登录依赖于注册
4）图例
2.2.7 交互图
交互图分为序列图和合作图，两者既能够互相转换而不失落信息，又存在肯定差别。上面离开讲再类比
序列图
1）阐明
- 序列图次要用于依照交互产生的一系列程序，显示对象之间的音讯或行为传递。
- 序列图能够形象表白整个流程，和流程图有相似之处，然而流程图偏业务逻辑，序列图则是零碎面向对象化建模后，对应到对象上的交互过程。趋向于开发者角度。
2）可用元素
- 对象：提供性能和交互的类的实例
- 参与者：同用例种的参加人，多为一段流程的发动点
- 工夫线：对象在整个交互流程中的生命周期
- 音讯：对象间须要发送和返回的音讯，能够本人发给本人
- 内部参考：序列图能够引入内部的一段作为参考，或参加序列中与以后图的元素交互
- 片段：将某一段序列纳入片段治理，该片段像原子一样，产生某些整体的行为，例如循环
3）关系
- 不会用到 6 大关系，相互之间应用 message 交互。代表的是信息流动。
4）图例
合作图（1.4）/ 通信图（2.0）
1）阐明
- 合作图与时序图相似，二者都是用对象间的交互来形容用例的。
- 两者关注角度稍有不同，时序图强调交互的工夫秩序，合作图强调交互的空间结构。
2）可用元素
- 参与者：零碎参加的角色
- 对象：同时序图，零碎中实例化的对象
- 关联：对象间的关联关系
- 音讯：依附于关联而存在，承载了对象间要传递的信息
3）关系
- 不会用到 6 大关系，相互之间应用 message 交互。代表的是信息流动。
4）图例
两种交互图能够互相转化，类比如下：
2.2.8 状态机
状态机分为状态图和流动图，
状态图
1）阐明
- 形容一个实体基于事件反馈的动静行为，它有两方面的价值，一是反映对象可能有哪些状态，二是这些状态之间是如何流转的，须要什么样的条件下进入什么样的状态。
2）可用元素
- 状态：某一个工夫点，对象所在的状态
- 转移：连贯状态之间，因为状态时能够相互变动转移的
- 分支 / 会合点：状态变动中可能产生分叉或交会，如确认收货后，单方互评产生分叉
- 开始 / 完结：状态的起始与终结
- 同步点：须要多个分支状态都具备时应用。多用于并行合作解决的状态流转，如互评都实现后，订单才算终结
3）关系
- 只有转移关系，示意状态之间的变动
4）图例
流动图
1）阐明
- 流动图用于企业的业务流程建模，是对外部流动与流动之间流转动作的表白
- 流动图类比流程图：流动图存在分支与交会，能够表白并行存在的流动，流程图多为是与否分支判断
- 流动图类比状态图：关注不同，状态图强调行为的后果（下一个状态是什么），流动图在乎行为的动作（下一步干什么）。两者能够了解为交叉配合，一动一静，流动可能会触发下一步不同的状态。
2）可用元素
- 流动：表白零碎中，或对象内的某一个能够产生的动作
- 对象：流动的产生者，或交互者
- 流转：流动的跳转，即下一步指向谁
- 断定：相似与流程图里的裁决，依据条件产生不同的流转
- 同步：并行流转下的会集，不同于流程图的中央
- 起始 / 完结：流动的发动与终结
- 泳道：对 UML 流动图中的流动进行分组，同一类流动在一个泳道上，清晰明了
3）关系
- 只有流转，也就是流动的跳转，示意下一个流动是啥
4）图例
3 实战篇
3.1 常用工具
3.1.1 Rational Rose
老牌，赫赫有名，史上最有名的 UML 产品，以至于大多数状况下，很多人将他等同于 UML 工具，须要留神的是，自从 Rational 被 IBM 收买之后，Rational Rose 曾经成为历史，作为 UML1.4 规范的产物，当初曾经不降级，然而够用。其替代品是 IBM 的其余产品，如 IBM RSA。
3.1.2 RSA
IBM® Rational® Software Architect，IBM 的旗舰产品，是一个高级而又全面的利用程序设计、建模和开发工具，用于实现端到端的软件交付。通过和 IBM 其余产品的协调，支持软件开发的全生命周期开发。然而也有它的毛病，轻便，繁冗（大公司产品的通病？？？）
3.1.3 Enterprise Architect
Sparx Systems 公司的旗舰产品。它笼罩了零碎开发的整个周期，除了开发类模型之外，还包含事务过程剖析，应用案例需要，动静模型，组件和布局，系统管理，非性能需要，用户界面设计，测试和保护等。总之你须要的根本都能够满足，价格还便宜。性价比之选。
3.1.4 StarUML
开放源码的 UML 开发工具，是由韩国公司主导开发进去的产品。用 Delphi 写的，是个大神。须要付费，网站提供购买注册码，玲珑简略而易用，与 rose 相比更是显著。
3.1.5 VISIO
VISIO 能够了解为一种通用的画图工具，它具备常见的各种图形，从 VISIO2000 版本才开始涉足软件剖析设计到代码生成的全副性能，单纯从画图角度，有着无可比拟的劣势，UML 图标仅仅是其中很少的一部分。长处是跟微软的 office 产品的可能很好兼容。能够把图形间接复制或者内嵌到 WORD 的文档中。然而到代码的生成更多是反对微软自家的产品如 VB，C#，ms sql 等（微软的一贯作风），如果仅是画 UML 图和大量的 word 文档表白，它能够满足你。
3.1.6 PowerDesigner
Sybase 的企业建模和设计解决方案。采纳模型驱动办法，将业务与 IT 联合起来，可帮忙部署无效的企业体系架构，并为研发生命周期治理提供弱小的剖析与设计技术。将多种规范数据建模技术集成一体，并与 IDE 集成，典型的如 Eclipse 插件模式。PD 更多给人的印象是数据库建模技术，然而它能够实现 UML 的所有建模操作并映射到数据库和代码层面。并提供 60 多种关系数据库的连贯反对。
3.1.7 总结
- 以上工具各有利弊，依据本人理论状况和喜好抉择即可
- 根本都涵盖软件建模的残缺周期，UML 只是他们的一部分性能
- 任何一种都能够满足你学习和工作中 UML 建模的应用需要
3.2 订单建模实战
3.2.1 B2C 交易用例图
用例图从订单零碎应用人角色登程，反馈订单体系外面有哪些人，能够做哪些事件
1）业务需要：
- 买家：浏览商品，下单、领取、签收
- 卖家：开店，确认订单，发货，商品保护
- 单方：退货，换货，评估，珍藏
3.2.2 订单模块类图
订单类图从业务模型登程，用面向对象思维，订单业务中的模型形象为一个个对象
1）元素：
- 人物类：Seller，Buyer，User
- 商品类：Shop，Product
- 交易环节类：Cart，Order，Invoice，AliPay，WeichatPay，ICBCPay…
- 交易环节接口：Pay
- 促销相干类：DiscountPromotion，ReductionPromotion…
- 促销接口：Promotion
2）关系：
- 关联：Order→Seller，Buyer，Pay；Shop→Seller
- 依赖：Order→Cart→Promotion，Invoice；
- 组合：Shop→Product
- 聚合：Cart→Product
- 泛化：Buyer，Seller→User
- 实现：DiscountPromotion，ReductionPromotion→Promotion；AliPay，WeichatPay，ICBCPay→Pay
3.2.3 订单下单时的对象图
对象图表白的是下订单的时刻，零碎存在的对象及对象之间的关联关系。对象具备了理论的属性值
1）元素：
- 与类图统一，然而接口将不复存在，而变为理论实现类
- Cart 生命周期终结，Invoice 还没诞生，Product，Promotion 附丽在了订单上
- 对象上的属性具备了理论值，不再是泛化的类属性的概念
2）关系：
- 对象之间变为实例关联（Instance link），泛化和实现不再被应用。
- 弱类型能够应用依赖，比方 Order 与打折的 Promotion
3.2.4 B2C 下单领取序列图
序列图反馈下单到领取实现这段时间里，各个对象怎么合作和交互，相互之间须要传递什么音讯。
1）元素
- 人物：Buyer
- 对象：Product，Cart，Order，Promotion，Pay，AliPay（内部）
2）工夫序列
- 顺向：Buyer→筛选→Product→增加→Cart→促销结算→Promotion→下单→Order→领取→Pay→跳转→AliPay
- 回路：Buyer←告诉←Order←开单←Pay←回调←AliPay
- 环路：Cart ←→增删商品
3.2.5 下单领取合作图
合作图同序列图相似，能够由序列图转化而来。然而合作图反映的是交互关系，像是铺开的时序图
1）元素，同时序图
- 人物：Buyer
- 对象：Product，Cart，Order，Promotion，Pay，AliPay（内部）
2）交互，同序列图
- 关联
- 音讯
3.2.6 B2B 先款后货状态图
以 B2B 先款后货业务模式下，订单对象的流转状态为例，实现业务状态展现
1）元素
- 起始
- 订单的各个状态值
- 交会
- 同步
- 终结
2）流转
- 开始→合同已生成→已付款→交收单已生成→已发货→验货验票→待评估→分支→买方已评，卖方已评→同步→终结
3.2.7 B2B 先款后货流动图
在先款后货的交易中，单方都要做哪些流动或者说操作，通过流动图建模体现
1）元素
- 泳道：Buyer，Seller，Manager
- 流动（Buyer）：生成合同，领取货款，验货验票，买方评估
- 流动（Seller）：生成交收单，发货，卖方评估
- 流动（Manager）：仲裁
- 断定：是否有异议
2）流程
- 开始→生成合同→领取货款→生成交收单→发货→验票验货→判断（是否异议？）→否→分支→买方，卖方评估→同步→终结
- 判断异议→是→仲裁→终结
3.2.8 订单服务组件图
界定形成订单服务的各个对象以及他们之间的可用接口，相当于定义了一组约定。
1）元素
- Order：create（Cart），open（Pay）
- Cart：addProduct（Buyer），removeProduct（Buyer），settle（Buyer）
- Promotion：discount（Cart）
- Pay：pay（Buyer）
3.2.9 订单核心部署图
将订单核心如何部署到服务器？部署图的职责就是实现这部分的内容。在 docker 容器化编排和云环境下，部署图变得不那么的确切。node 能够类比了解为 docker 容器或者是 k8s 等编排工具中的 pod，而组件也不再固定在某个 node 中，而是由调度器动静调度，扩散部署。
1）元素
- node：App1，App2，App3，假如有三台；mysql 数据库，假如 1 主 2 从
- component：Order，Cart，Pay，Promotion
2）关系
- 组件离散散布于 3 台 App
- App 关联 mysql
- mysql 主从为依赖
3.3 总结
- 所有皆工具，适宜你的就是最好的
- 灵便变通，不要拘泥规矩，规矩是死的人是活的
- 表达思想才是目标，一切都是为了能说分明你的想法，这也是语言的实质
- 不要为了画图而画图，UML 不是必须的，然而有了它你的架构工作会变得更顺畅
心愿 UML 能成为你架构工作的利器，晋升效率，解决问题。Thanks！
本文由传智教育博学谷 – 狂野架构师教研团队公布
转载请注明出处！
