UML系统建模专题---1、UML概述和理论-编程知识

概述

什么是uml

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

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

uml可以做什么

从命名上分析：统一、建模、语言

统一：没有规矩不成方圆，它指定了一种标准，一种约束，使得大家的表达变得一致。它被OMG（Object Management Group）所认可。

OMG是一个国际化的、开放成员的、非盈利性的计算机行业标准协会，该协会成立于1989年，他是软件行业中一个标准的认可。包括客户、领域专家、分析师、设计师、程序员、测试工程师及培训人员等。uml成为他们工作中统一的沟通工具，用于充分理解和表达自己所关注的内容

建模：复杂业务系统建模，即建立软件系统模型。uml的创始人之一Booch，曾用建一座摩天大楼来比喻uml的必要性。简单系统下，可有可无，系统复杂或大到一定程度，建模和文档成为系统周期里非常重要的一环。

语言：面向对象思想的表达。互相之间的沟通工具。一种按照特定规则和模式组成的符号系统。

关于uml的争议

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

观点二：uml设计相当的严谨与全面，在面向对象的系统架构上，可以便捷的表达你想要表达的一切想法，优美切无可替代。

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

切忌形式化

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

理论

关系

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

泛化（Generalization）

定义：

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

代码：

//类
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）

定义：

是一种拥有的关系，双方不一定属于同一类事物，箭头指向被拥有者
可以单向，也可以双向，例如Tiger与Zookeeper
类比在表结构上，更像是存在中间表关系

代码：成员变量

聚合（Aggregation）

定义：

单向，空心菱形起始的箭头，箭头指向被拥有者
一种很弱的拥有关系，A可以拥有B，但是不是离了B就无法生存
群体与个体的关系，如小组包含组员

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

组合（Composition）

定义：

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

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

实例

一张图涵盖所有的关系：

在这里插入图片描述

总结

继承和实现几乎不会搞混，一个上下父子关系，一个是类与接口
组合与聚合要注意，聚合为聚集，群体与个体。组合为组成，整体与部分
关联和依赖要注意，关联一般为同级别有相关性，这种相关性是长期存在的。依赖为需求关系，一
方需要依赖另一方，可能会因另一方的改变而改变。
关系的强弱顺序：继承=实现>组合>聚合>关联>依赖

图

概述

在这里插入图片描述
uml中的图形非常多，按类型分为结构图和行为图，其中，最常用，最典型的为9种，下面分开来介绍。

用例图：从用户角度描述系统功能。
类图：描述系统中类的静态结构。
对象图：系统中的多个对象在某一时刻的状态。
状态图：是描述状态到状态控制流，用于表达系统状态的变化
活动图：描述了业务实现用例的工作流程，强调的是动作之间的衔接
序列图：对象之间的动态合作关系，强调对象发送消息的顺序
协作图：描述对象之间的协助关系，强调对象之间的合作关系
组件图：描述系统各个组件及其相关关系的静态视图
部署图：定义系统中软硬件的物理体系结构

类图

说明

面向对象系统建模中最常用和最重要的图，是定义其它图的基础
主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型
描述细化相关的属性和操作，是一个对业务模型面向对象化的过程，也是对系统的约束
可以直接构建可执行代码，但真正使用的场景相对较少

可用元素

类：
接口：
关系：可以使用上述中的6大关系。

实例

对象图

说明

对象图和类图一样反映系统的静态过程，但它表达的是一个实际场景。
对象图显示某时刻对象和对象之间的关系。可看成一个类图的快照。
对象图是类图的实例，所以几乎使用与类图完全相同的标识

可用元素
对象：
关系
对象图因为是运行在某个时间节点的对象镜像，所以关系比较单一，描述的是类与类的实例之间。不涉及接口

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

图例

组件图

说明

UML1.1中，组件图是用来描述一个系统的物理构件。包括文件，可执行文件，库等
UML2 中，关注组件间的关联（使用什么接口，通过什么端口通讯），强调通过接口来描述组件行为
对于后端来说，组件图比较适用于 SOA 架构、微服务架构，描述整个系统的结构以及子系统间的通讯方式
对于前端来说，组件图适合在使用类似 react、vue 这样组件化的前端技术框架时，表达对组件的设计，比如一个页面会有个骨架组件，骨架组件包含了导航组件，列表组件等等