在计算复杂的数学题时,我们必然会打草稿计算
在绘画课中,我们可以素描出来看到的事物
那么在程序设计中呢?
如何描绘传达你脑海中的关于这个程序 ,设计的蓝图草稿?
OOP的程序设计中,最多的自然是类、接口层次接口的设计
简单的设计,可能在脑海中想象下就过了,比如A继承B
但是复杂的呢?
对于OOP程序设计中,类的层次、关系设计如何描绘?
用文字么? A继承B A实现C,A中有一个D的引用
显然,图形化的方式更加直观,简洁
那么到底如何表示OOP中的事物与关系?每个人有每个人的书写方式,如何进行交流?
你画了一个三角形说这是一个接口,我花了一个圆形,跟你讲这个是接口?这其中的问题不言而喻。
UML起源
1997年,OMG 组织(Object Management Group对象管理组织)发布了统一建模语言(Unified Modeling Language,UML)
UML 是一种为面向对象开发系统的产品进行说明、可视化、和编制文档的标准语言
UML 作为一种模型语言,它使开发人员专注于建立产品的模型和结构
UML 是不同于其他常见的编程语言,如Java等,它是一种绘画语言,用来做软件蓝图
UML 提出了一套 统一的,标准的建模符号
首先它提供了一套建模符号,用于类的层次结构设计
另外,统一的也就意味着只要按照标准构图,就可以无障碍的通过UML图进行沟通
计算机软件的世界里面,总是“分久必合”,UML的发展历史也不例外
UML 统一了Booch、OMT、OOSE和其他面向对象方法所涉及的基本概念和建模符号
UML的发展不是一蹴而就的,而是吸收了现有的精华,而发展出来的大一统的形式
UML逻辑原理
UML是面向对象程序设计的描绘语言
是面向对象程序设计的建模语言,是对面向对象程序设计世界的抽象
UML的基本逻辑是很简单的
将面向对象程序设计中的元素进行抽象,比如类还是接口,UML中称之为事物,就如同积木的基础形状
将元素之间的联系关系进行抽象,比如到底是继承还是组合(聚合),如同积木中的卡扣,可能有多种卡扣连接形式
而我们看到的UML图也就是如同一整块已经搭建好的积木
当然
UML肯定不会向积木那样简单,所以自然还会有很多的规则、限制、要求,这些一起构成了完整的UML
但是根本是事物和关系,这两者是UML的主体
事物就是面向对象程序设计中的元素
关系则是他们的相互联系形式
图则是按照不同事物的组织形式进而产生的分类
UML组成
上图是UML的大致基本组成部分,部分类型并未全部列举
事物是是实体抽象化的最终结果,是 UML 构建块最重要的组成部分
最基本的是类和接口
关系是事物之间的联系的抽象分类
有了事物和联系,就可以绘制出各种各样的UML图
按照他们的逻辑功能性质,又有了图的分类
UML是软件需求分析、设计的强大工具,并非简单介绍就可以认知的
本文重在简单了解基本知识以更好学习设计模式
UML常用关系
UML类的属性和方法
类包括类名、属性、方法
都在类图中
属性:可见性 名称 :类型 [ = 缺省值]
方法:可见性 名称(参数列表) [ : 返回类型]
中括号表示缺省的
可见性使用+ - #表示
+ public
- private
# protected
常用工具
UML的工具有很多,比如 StarUML 、astah
astah,前身是JUDE
下图为astah中的sample
以下图为例简单的了解下UML的图形标识符号
Tracer中与Engine、Steering、Monitor单项关联,也就是含有引用
与State双向关联
Engine与Steering由Motor组成 他们是可以独立存在的
Monitor由LightSensor组成 他们是可以独立存在的
Idle OnCourse OutOfCourse 是State的实现类
Monitor中,Threshold是boolean类型的私有属性
isBlack和isWhite是返回类型为void的 public方法
总结
本文简单介绍了UML的历史以及组成部分,目的不在于详细介绍UML,只在于能够读懂以及绘制类图
UML是可视化的程序设计描绘语言,通过图形和符号直观的表达含义
对于类图需要理解清楚类图相关的关联关系
另外,不同的软件对于各种图形的表示可能局部细节会有差别,实际使用时应该注意
UML是Unified Modeling Language ,并不是一种具体的工具,而是标准
UML建模工具就如同“实现类”一样,细节上有差异也很正常,很多软件也可以调整显式的式样,比如StarUML就可以