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

会集 UML 及其相干的一些话题
回顾 UML 相干的符号与概念
以电商订单相干业务为例，借助 UML 实现零碎建模
将 UML 变成晋升建模效率，表白架构思维的工具

Unified Modeling Language 对立建模语言，又称规范建模语言。是用来对软件密集零碎进行可视化建模的一种语言。语言，也就是一个表达思想的符号约定。

建模语言呈现在二十世纪 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

从命名上剖析：对立、建模、语言

对立：没有规矩不成方圆，它指定了一种规范，一种束缚，使得大家的表白变得统一。它被 OMG（Object Management Group）所认可。

    OMG 是一个国际化的、凋谢成员的、非盈利性的计算机行业规范协会，该协会成立于 1989 年，他是软件行业中一个规范的认可。包含客户、领域专家、分析师、设计师、程序员、测试工程师及培训人员等。UML 成为他们工作中对立的沟通工具，用于充沛了解和表白本人所关注的内容。

建模：简单业务零碎建模，即建设软件系统模型。UML 的创始人之一 Booch，曾用建一座摩天大楼来比喻 UML 的必要性。简略零碎下，可有可无，零碎简单或大到肯定水平，建模和文档成为零碎周期里十分重要的一环。

语言：面向对象思维的表白。相互之间的沟通工具。一种依照特定规定和模式组成的符号零碎。

团队或架构设计相互交换，必然须要一种沟通语言
是一门技能，不肯定用到，然而作为架构师应该晓得
有其余的表白方法，然而用习惯后，UML 真的很不便易用

观点一：UML 是鸡肋，离程序员真正须要的设计工具还差得很远。只有为数不多的程序员应用这个工具交换想法，而没有用在具体工作中。

观点二：UML 设计相当的谨严与全面，在面向对象的零碎架构上，能够便捷的表白你想要表白的所有想法，柔美切无可替代。

个人观点：一项技能和工具，学会并不难，须要的时候能拿来用就好，艺不压身。

不要把 UML 适度神化
一个表白想法的工具而已
当用则用，不要刻意去套

关系是事实世界中事物与事物之间互相关系的符号表白，形象到面向对象理念上，大抵分为 6 种。

定义：

Java 里的 extends，可用于接口与接口之间，或父子类之间
单向，箭头指向父类，如 Tiger 指向 Animal

代码：

// 类
public class Animal {
}
public class Cat extends Animal {
}

// 接口
public interface Action {
}
public interface Jump extends Action {}

定义：

Java 里的 implements，箭头指向接口
单向，如 Tiger 扩大了 Sleep 接口，那么箭头指向 Sleep

代码：

public interface Jump {
}
public class Tiger implements Jump {}

定义：

某个类或对象实例，依赖于另一个而存在，在其要害办法中用到了对方
如果一方属性产生变动，另一方可能会收到影响
个别为单向，例如动物依赖于食物，eat(Food food)
类比在表构造上，更像是外键

代码：办法参数，局部变量

定义：

是一种领有的关系，单方不肯定属于同一类事物，箭头指向被拥有者
能够单向，也能够双向，例如 Tiger 与 Zookeeper
类比在表构造上，更像是存在两头表关系

代码：成员变量

定义：

单向，空心菱形起始的箭头，箭头指向被拥有者
一种很弱的领有关系，A 能够领有 B，然而不是离了 B 就无奈生存
群体与个体的关系，如小组蕴含组员

代码：成员变量，多为汇合

定义：

单向，实心菱形为起始，箭头指向子模块
一种整体与局部的关系，A 是由 B 组成的，来到 B 则不残缺。
单向，如人和四肢的关系

代码：成员变量，多为汇合

一张图涵盖所有的关系：

继承和实现简直不会搞混，一个高低父子关系，一个是类与接口
组合与聚合要留神，聚合为汇集，群体与个体。组合为组成，整体与局部
关联和依赖要留神，关联个别为同级别有相关性，这种相关性是长期存在的。依赖为需要关系，一方须要依赖另一方，可能会因另一方的扭转而扭转。
关系的强弱程序：继承 = 实现 > 组合 > 聚合 > 关联 > 依赖

UML 中的图形十分多，按类型分为结构图和行为图，其中，最罕用，最典型的为 9 种，上面离开来介绍。

用例图：从用户角度形容零碎性能。
类图：形容零碎中类的动态构造。
对象图：零碎中的多个对象在某一时刻的状态。
状态图：是形容状态到状态控制流，用于表白零碎状态的变动
流动图：形容了业务实现用例的工作流程，强调的是动作之间的连接
序列图：对象之间的动静单干关系，强调对象发送音讯的程序
合作图：形容对象之间的帮助关系，强调对象之间的单干关系
组件图：形容零碎各个组件及其相干关系的动态视图
部署图：定义零碎中软硬件的物理体系结构

1）阐明

面向对象零碎建模中最罕用和最重要的图，是定义其它图的根底
次要是用来显示零碎中的类、接口以及它们之间的动态构造和关系的一种动态模型
形容细化相干的属性和操作，是一个对业务模型面向对象化的过程，也是对系统的束缚
能够间接构建可执行代码，但真正应用的场景绝对较少

2）可用元素

类：

接口：

关系：能够应用上述中的 6 大关系。

3）实例

1）阐明

对象图和类图一样反映零碎的动态过程，但它表白的是一个理论场景。
对象图显示某时刻对象和对象之间的关系。可看成一个类图的快照。
对象图是类图的实例，所以简直应用与类图完全相同的标识。

2）可用元素

对象：

3）关系

对象图因为是运行在某个工夫节点的对象镜像，所以关系比拟繁多，形容的是类与类的实例之间。不波及接口

关联：对象之间存在关联关系，如用户和订单
依赖：对象实例之间的依赖关系，如商品对象依赖店铺

4）图例

1）阐明

UML1.1 中，组件图是用来形容一个零碎的物理构件。包含文件，可执行文件，库等
UML2 中，关注组件间的关联（应用什么接口，通过什么端口通信），强调通过接口来形容组件行为
对于后端来说，组件图比拟实用于 SOA 架构、微服务架构，形容整个零碎的构造以及子系统间的通信形式
对于前端来说，组件图适宜在应用相似 react、vue 这样组件化的前端技术框架时，表白对组件的设计，比方一个页面会有个骨架组件，骨架组件蕴含了导航组件，列表组件等等

2）可用元素

组件：形容的是零碎的其中一个组成部分，一个残缺的可独立服务的模块或单元，比方订单服务，k8s 里的一个 pod
部件：组件内可能细化为多个子模块
端口：组件对外提供服务就必须裸露对应的端口。如 http rest 服务默认的 80
接口：部件 / 组件之间的一种约定，分提供者和需求者同时展现了某个部件提供出的性能

3）关系

泛化：用于接口与接口之间存在的父子关系，组件之间也可能存在，但绝对用的较少
实现：接口和其实现者（提供服务的组件）之间
关联：Require link / Connector，接口与调用者（须要接口的组件）之间

4）图例

1）阐明

一种展现运行时进行解决的节点和在节点上存在的组件配置的图。
论述了在理论利用中软件和它的运行环境的关系，并且形容了软件部署在硬件上的具体形式。

2）可用元素

节点：

新近单实例 MVC 架构下，节点能够认为是某台物理服务器，微服务及容器化下，物理服务器大多纳入编排治理，docker 实例由零碎在物理节点见自在调度，组件无奈锁定在某个固定物理节点上，这种环境下的 node 能够了解为一个容器，或 k8s 中的 pod。

组件实例

相当于组件里的实例化，类比于类和对象

3）关系

依赖：产生于组件之间，如用户组件依赖于订单组件
关联：node association，产生于节点之间，例如应用服务器须要关联 mysql 数据库

4）图例

1）阐明

用例图是用来形容零碎性能的技术，示意一个零碎中用例与参与者及其关系的图
次要用于需要分析阶段，和产品文档比拟贴近
用例图相当于从用户的视角来形容和建模整个零碎，剖析零碎的性能与行为。

2）可用元素

参与者：应用零碎的人，有多少种角色就有多少参与者。

用例：参与者可用做的事件

3）关系

泛化：参与者之间可用泛化，例如用户与一般会员；用例也可用泛化，如用户治理与批改明码
关联：产生于参与者和用例之间，示意该角色可用有哪些用例（行为）
依赖：产生与用例之间，例如登录依赖于注册

4）图例

交互图分为序列图和合作图，两者既能够互相转换而不失落信息，又存在肯定差别。上面离开讲再类比

序列图

1）阐明

序列图次要用于依照交互产生的一系列程序，显示对象之间的音讯或行为传递。
序列图能够形象表白整个流程，和流程图有相似之处，然而流程图偏业务逻辑，序列图则是零碎面向对象化建模后，对应到对象上的交互过程。趋向于开发者角度。

2）可用元素

对象：提供性能和交互的类的实例
参与者：同用例种的参加人，多为一段流程的发动点
工夫线：对象在整个交互流程中的生命周期
音讯：对象间须要发送和返回的音讯，能够本人发给本人
内部参考：序列图能够引入内部的一段作为参考，或参加序列中与以后图的元素交互
片段：将某一段序列纳入片段治理，该片段像原子一样，产生某些整体的行为，例如循环

3）关系

不会用到 6 大关系，相互之间应用 message 交互。代表的是信息流动。

4）图例

合作图（1.4）/ 通信图（2.0）

1）阐明

合作图与时序图相似，二者都是用对象间的交互来形容用例的。
两者关注角度稍有不同，时序图强调交互的工夫秩序，合作图强调交互的空间结构。

2）可用元素

参与者：零碎参加的角色
对象：同时序图，零碎中实例化的对象
关联：对象间的关联关系
音讯：依附于关联而存在，承载了对象间要传递的信息

3）关系

不会用到 6 大关系，相互之间应用 message 交互。代表的是信息流动。

4）图例

两种交互图能够互相转化，类比如下：

状态机分为状态图和流动图，

状态图

1）阐明

形容一个实体基于事件反馈的动静行为，它有两方面的价值，一是反映对象可能有哪些状态，二是这些状态之间是如何流转的，须要什么样的条件下进入什么样的状态。

2）可用元素

状态：某一个工夫点，对象所在的状态
转移：连贯状态之间，因为状态时能够相互变动转移的
分支 / 会合点：状态变动中可能产生分叉或交会，如确认收货后，单方互评产生分叉
开始 / 完结：状态的起始与终结
同步点：须要多个分支状态都具备时应用。多用于并行合作解决的状态流转，如互评都实现后，订单才算终结

3）关系

只有转移关系，示意状态之间的变动

4）图例

流动图

1）阐明

流动图用于企业的业务流程建模，是对外部流动与流动之间流转动作的表白
流动图类比流程图：流动图存在分支与交会，能够表白并行存在的流动，流程图多为是与否分支判断
流动图类比状态图：关注不同，状态图强调行为的后果（下一个状态是什么），流动图在乎行为的动作（下一步干什么）。两者能够了解为交叉配合，一动一静，流动可能会触发下一步不同的状态。

2）可用元素

流动：表白零碎中，或对象内的某一个能够产生的动作
对象：流动的产生者，或交互者
流转：流动的跳转，即下一步指向谁
断定：相似与流程图里的裁决，依据条件产生不同的流转
同步：并行流转下的会集，不同于流程图的中央
起始 / 完结：流动的发动与终结
泳道：对 UML 流动图中的流动进行分组，同一类流动在一个泳道上，清晰明了

3）关系

只有流转，也就是流动的跳转，示意下一个流动是啥

4）图例

老牌，赫赫有名，史上最有名的 UML 产品，以至于大多数状况下，很多人将他等同于 UML 工具，须要留神的是，自从 Rational 被 IBM 收买之后，Rational Rose 曾经成为历史，作为 UML1.4 规范的产物，当初曾经不降级，然而够用。其替代品是 IBM 的其余产品，如 IBM RSA。

IBM® Rational® Software Architect，IBM 的旗舰产品，是一个高级而又全面的利用程序设计、建模和开发工具，用于实现端到端的软件交付。通过和 IBM 其余产品的协调，支持软件开发的全生命周期开发。然而也有它的毛病，轻便，繁冗（大公司产品的通病？？？）

Sparx Systems 公司的旗舰产品。它笼罩了零碎开发的整个周期，除了开发类模型之外，还包含事务过程剖析，应用案例需要，动静模型，组件和布局，系统管理，非性能需要，用户界面设计，测试和保护等。总之你须要的根本都能够满足，价格还便宜。性价比之选。

开放源码的 UML 开发工具，是由韩国公司主导开发进去的产品。用 Delphi 写的，是个大神。须要付费，网站提供购买注册码，玲珑简略而易用，与 rose 相比更是显著。

VISIO 能够了解为一种通用的画图工具，它具备常见的各种图形，从 VISIO2000 版本才开始涉足软件剖析设计到代码生成的全副性能，单纯从画图角度，有着无可比拟的劣势，UML 图标仅仅是其中很少的一部分。长处是跟微软的 office 产品的可能很好兼容。能够把图形间接复制或者内嵌到 WORD 的文档中。然而到代码的生成更多是反对微软自家的产品如 VB，C#，ms sql 等（微软的一贯作风），如果仅是画 UML 图和大量的 word 文档表白，它能够满足你。

Sybase 的企业建模和设计解决方案。采纳模型驱动办法，将业务与 IT 联合起来，可帮忙部署无效的企业体系架构，并为研发生命周期治理提供弱小的剖析与设计技术。将多种规范数据建模技术集成一体，并与 IDE 集成，典型的如 Eclipse 插件模式。PD 更多给人的印象是数据库建模技术，然而它能够实现 UML 的所有建模操作并映射到数据库和代码层面。并提供 60 多种关系数据库的连贯反对。

以上工具各有利弊，依据本人理论状况和喜好抉择即可
根本都涵盖软件建模的残缺周期，UML 只是他们的一部分性能
任何一种都能够满足你学习和工作中 UML 建模的应用需要

用例图从订单零碎应用人角色登程，反馈订单体系外面有哪些人，能够做哪些事件

1）业务需要：

买家：浏览商品，下单、领取、签收
卖家：开店，确认订单，发货，商品保护
单方：退货，换货，评估，珍藏

订单类图从业务模型登程，用面向对象思维，订单业务中的模型形象为一个个对象

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

对象图表白的是下订单的时刻，零碎存在的对象及对象之间的关联关系。对象具备了理论的属性值

1）元素：

与类图统一，然而接口将不复存在，而变为理论实现类
Cart 生命周期终结，Invoice 还没诞生，Product，Promotion 附丽在了订单上
对象上的属性具备了理论值，不再是泛化的类属性的概念

2）关系：

对象之间变为实例关联（Instance link），泛化和实现不再被应用。
弱类型能够应用依赖，比方 Order 与打折的 Promotion

序列图反馈下单到领取实现这段时间里，各个对象怎么合作和交互，相互之间须要传递什么音讯。

1）元素

人物：Buyer
对象：Product，Cart，Order，Promotion，Pay，AliPay（内部）

2）工夫序列

顺向：Buyer→筛选→Product→增加→Cart→促销结算→Promotion→下单→Order→领取→Pay→跳转→AliPay
回路：Buyer←告诉←Order←开单←Pay←回调←AliPay
环路：Cart ←→增删商品

合作图同序列图相似，能够由序列图转化而来。然而合作图反映的是交互关系，像是铺开的时序图

1）元素，同时序图

人物：Buyer
对象：Product，Cart，Order，Promotion，Pay，AliPay（内部）

2）交互，同序列图

关联
音讯

以 B2B 先款后货业务模式下，订单对象的流转状态为例，实现业务状态展现

1）元素

起始
订单的各个状态值
交会
同步
终结

2）流转

开始→合同已生成→已付款→交收单已生成→已发货→验货验票→待评估→分支→买方已评，卖方已评→同步→终结

在先款后货的交易中，单方都要做哪些流动或者说操作，通过流动图建模体现

1）元素

泳道：Buyer，Seller，Manager
流动（Buyer）：生成合同，领取货款，验货验票，买方评估
流动（Seller）：生成交收单，发货，卖方评估
流动（Manager）：仲裁
断定：是否有异议

2）流程

开始→生成合同→领取货款→生成交收单→发货→验票验货→判断（是否异议？）→否→分支→买方，卖方评估→同步→终结
判断异议→是→仲裁→终结

界定形成订单服务的各个对象以及他们之间的可用接口，相当于定义了一组约定。

1）元素

Order：create（Cart），open（Pay）
Cart：addProduct（Buyer），removeProduct（Buyer），settle（Buyer）
Promotion：discount（Cart）
Pay：pay（Buyer）

将订单核心如何部署到服务器？部署图的职责就是实现这部分的内容。在 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 主从为依赖

所有皆工具，适宜你的就是最好的
灵便变通，不要拘泥规矩，规矩是死的人是活的
表达思想才是目标，一切都是为了能说分明你的想法，这也是语言的实质
不要为了画图而画图，UML 不是必须的，然而有了它你的架构工作会变得更顺畅

心愿 UML 能成为你架构工作的利器，晋升效率，解决问题。Thanks！

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

UML 零碎建模

1 概述

1.1 课程概述

1.2 什么是 UML

1.3 UML 的倒退与版本

1.4 UML 能够做什么

1.5 学习 UML 的意义

1.6 对于 UML 的争议

1.7 切忌形式化

2 实践篇

2.1 关系

2.1.1 泛化（Generalization）

2.1.2 实现（Realization）

2.1.3 依赖（Dependency）

2.1.4 关联（Association）

2.1.5 聚合（Aggregation）

2.1.6 组合（Composition）

2.1.7 实例

2.1.8 总结

2.2 图

2.2.1 概述

2.2.2 类图

2.2.3 对象图

2.2.4 组件图

2.2.5 部署图

2.2.6 用例图

2.2.7 交互图

2.2.8 状态机

3 实战篇

3.1 常用工具

3.1.1 Rational Rose

3.1.2 RSA

3.1.3 Enterprise Architect

3.1.4 StarUML

3.1.5 VISIO

3.1.6 PowerDesigner

3.1.7 总结

3.2 订单建模实战

3.2.1 B2C 交易用例图

3.2.2 订单模块类图

3.2.3 订单下单时的对象图

3.2.4 B2C 下单领取序列图

3.2.5 下单领取合作图

3.2.6 B2B 先款后货状态图

3.2.7 B2B 先款后货流动图

3.2.8 订单服务组件图

3.2.9 订单核心部署图

3.3 总结