关于java:想学设计模式想搞架构设计先学学UML系统建模吧您

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！

本文由传智教育博学谷 – 狂野架构师教研团队公布
转载请注明出处！