积跬步,聚小流------关于UML类图

UML的存在

类图是使用频率比較高的UML图,它用于描写叙述系统中所含的类以及它们之间的相互关系,帮助人们简化对系统的理解,也是系统分析和设计阶段的重要产物,也是系统编码和測试的重要类型根据。

UML的表示方法

它的表示方法也比較简单,分成三层,第一层是类名。第二层是属性,第三层是方法。

而 属性和方法中用到的“+”表示public,“-”表示private,“#”表示protected。以及属性的写法:权限修饰符、属性名(方法名),然后是数据类型(或返回值)。这些都是基本的语法,都比較明显也比較简单。

当然还有接口和抽象类的表示方法:

用来描写叙述接口;

用来描写叙述抽象方法。

UML描写叙述类图之间的关系

类图之间的关系有四种:泛化关系、实现关系、依赖关系、关联关系,而关联关系又分为普通关联关系、聚合关系和合成关系。而其实这些关系我们easy理解,可很多其它时候我们要注意怎样转化成java代码:

泛化关系

泛化关系实质上就是我们的继承,类继承与还有一个类,这个代码应该好些,我们仅仅须要记一下UML表示方法就好了

(图片是从网上任意转载的)

这里须要注意的是集成的方向,空心箭头加实现表示继承,箭头指向谁表示继承于谁。

至于 java中关系代码则为public class Tiger extends Animal(){};

实现 关系

这就是来相对于接口的,描写叙述实现接口,这个我们也来简单记下:

(图片是从网上任意转载)

作为对照,与继承类似的是都是空心箭头,而与继承不同的则是虚线表示实现;

而java代码在这里的写法则为public class PenBrush implents IBrush(){};

依赖关系

把依赖关系放在第三个。是由于它是类与类之间最浅的关系。它能够是单向的,也能够是双向的,可是我们通常都用单向的。避免双向的。

(图片是从网上任意转载)

依赖关系解释起来比起继承和实现来稍微有些麻烦。由于继承和实现我们经经常使用到。并且比較单一。有着明白的上下级,而依赖关系则不然,就像图中的人都依赖于计算机来作某些事情。就像在《大话设计模式》中动物依赖空气和水,空气和水是不同于动物的单独事物,就像计算机是不同于人类的独立的事物一样,它是独立存在的,而人类在计算或者其他行动中须要用到计算机,就像动物的呼吸须要空气,喝水须要水一样,它的行为中可能会用到还有一个独立的存在。而假设不进行这个行为可能就不须要动用这个存在,就像一个死去的动物,已经不要水和空气,但是它仍然是一个动物,这个类是不会变的。

解释起来可能相比較有些麻烦,可是表示方法还是非常easy的,一个虚线加上实心箭头就够了;

至于代码实现方法。则就须要详细情况进行详细对待了。

整体上说,通常能够表现为:

①:被指向的类。在指向它的类中,做为一个方法的參数,这是最经常使用的一种方式。

public class Person{
	public void count(Computer computer){

	}
}

②:还能够将被指向的类。在指向它的类中。作为一个方法中的局部变量;

public class Person{
	public void count(){
		Computer computer=new Computer();
	}
}

③:再有一种方式就是被指向的类中含有静态方法。而指向它的类调用它的静态方法;

public class Computer(){
       public static void test(){

       }
}
public class Person{
	Computer.test();
}

关联关系:

最后就是我们的关联关系了,说它分为三种状态:普通关联关系、聚合关系和合成关系,他们最大的共同之处就是都是关联关系,而代码表现出来的方式就是被指向类会作为指向类的成员变量出现,而我们再来看看它们有什么不同?

普通关联关系

(图片是从网上任意转载)

这是最普通的关联关系。代码也非常easy写:

public class Customer{
  private Address address。
}

而对应的还有自关联和双向关联,而这些也都是将对应的类做成成员变量就可以。自关联将自己,双向关联互相做成。

聚合关系

关联关系就像是一个老人讲故事,要想知道这个事情,要从多少多少年说起了,那个年代那个背景可能会让你理解的更深刻。而聚合关系则不不过这样,不不过那个时代造成了这样,而是主人公可能就在一个组织里,那个组织的人的共性,他是组织里的人。组织都是由他这类人组成的。

(图片是从网上任意转载)

它的描写叙述形式比起简单的关联来多了一个菱形。而菱形所在的类指向对方。

它的代码编写,比起普通关联要麻烦了非常多:

public class Car{
   private Engine engine;
   public Car(Engine engine){

  }
  public void setEngine(Engine engine){

  }
}

它不仅将被指向对象作为了成员变量。还将成员对象作为构造方法以及set方法或其它业务方法的參数。

合成关系

合成关系,还有人把它叫做组合关系。它之所以不同于聚合关系,是由于关联的对象在本质上是在一起的。就像四肢对于生物。就像数字对于计算。

(图片是从网上任意转载)

鉴于它的同根同源性,菱形变成了实心。而对应的程序也做出了变化:

public class Head{
   private Mouth mouth;
   public Head(){
       mouth=new Mouth();
   }
}

它是在总体的构造方法中直接实例化成员。

时间: 2024-10-05 23:50:48

积跬步,聚小流------关于UML类图的相关文章

积跬步,聚小流-------关于UML时序图

uml时序图的存在 在上一篇中记录了uml类图,用类图来描述代码中所需要的类以及相互之间的关系,也就立体的将整个程序框架展现在了我们面前,像一幅画,有山有水有人. 一张照片只能定格当时的美好,等物是人非,再看时却往往不是欣喜,而是惆怅和失落,那些念念不忘的,终究还是跟着时间走了,哪怕依依不舍,也只能在回忆里沉醉. 如果说类图就是一张张照片,那回忆就是一幅幅时序图,走过,也可能错过,笑过,也可能哭过,可不论怎样,是我们让这个世界一点点改变,一点点动起来. 如果说类图是一张张曾经规划的图纸,那时序图

不积跬步无以至千里----高度自适应的textarea

在某个项目里面,有这样的一个小需求. textarea的高度自适应,当高度高于300px之后,textarea高度不再增高,出滚动条.当高度小于某个高度例如80px的时候,高度不再变小. 其实这个需求在很多地方都有出现过,例如微博的评论框,还有各种评论框. 谈不上什么有难度的技术,写下来当一个小插件积累. <!doctype html> <html> <head> <meta charset="utf-8"> <title>高

技术成长-不积跬步无以至千里

走在开发的道路上,你会发现越走路越长,越走路上的坑越多.本人是想在成长的道路上多踩一些坑的,踩的坑越多,遇到问题解决速度越快.坑多了,可能自己都记不住了,就需要记一记,有些时候你遇到的坑采用的解决办法并不是最优解,所有需要拿出来跟小伙伴一起分享分享你的经验. 记录到比如印象笔记或者有道云笔记里,或者自己的一个文件夹里,不过,个人经验,记在文件夹后很少有人再去看,还是记在印象笔记或者有道云笔记里,可以帮助自己随时翻看.现在的流程是重要的时候记录在有道云笔记上,做个索引,然后印象笔记记录的是我再找对

UML设计:类图说明及一步一步制作UML类图

什么是类图 UML类图是用来描述一个系统的静态结构.它既可以用于一般概念建模也可以用于细节建模.类包含了数据和行为,是面向对象的重要组成部分,它是具有相同属性.操作.关系的对象集合的总称. UML类图也可以用于数据建模.它可以用来描述应用程序内部或和其他用户之间的对象和信息结构.在UML中问题域终要被逐步转化,通过类来建模,通过编程语言构建这些类.类加上他们之间的关系就构成了类图,类图中还可以包含接口.包等元素,也可以包括对象.链等实例. 类图中的符号 class 类通过一个矩形表示,被两条直线

《Nodejs开发加密货币》之二十六:轻松从Js文件生成UML类图

前言 上一篇<函数式编程入门经典>,罗嗦了很长,很多小伙伴看得云里雾里.这里提供一个实例,让大家切身感受函数式编程的奥妙和趣味.当然,仅仅为了举例而写代码就没有什么意义了,本书提供的例子都是承担了某项任务的具体项目或工具,这个例子自然也不能例外. 本书用到了大量的Uml类图,经常有小伙伴问我用什么工具画的.说实话,前几篇是我个人一点点手工整理的,但后来就感觉在浪费生命,作为程序员,怎么可能容忍这样的事情反复发生.所以,就有了 js2uml(见参考)这个小工具.只不过,当初目的单一,仅仅使用正则

机房收费系统——UML类图

在对一个软件系统进行设计和建模的时候,通常是从构造系统的基本词汇开始,包括构造这些词汇的基本属性和行为.系统分析师如果要对所设计的系统清晰认识,还有考虑这些基本词汇之间的关系.而如果把这些行为可视化为图,就是通常所说的类图. 类图(Class Diagram)是描述类.接口.协作以及它们之间关系的图,用来显示系统中的各个类的静态结构. 类图包括3方面内容: 1.类(Class): 2.接口: 3.关系: 类 类是对一组具有相同属性.操作.关系和语义的对象的描述. 主要包括:类的名称(ClassN

【软件设计】UML类图怎么看

前言 无论使用哪种语言,都离不开面向过程与面向对象两个流派,而类图是面向对象程序设计中至关重要的一种软件表达形式,如何看懂类图,并设计好的软件架构,是我们作为软件工程师必不可少的技能之一. 今天小黑把类图学习的一些笔记和心得分享出来,供大家参考. 什么是类 了解类图之前,我们需要简单了解一下类的概念 类(Class)封装了数据和行为,是面向对象的重要组成部分,它是具有相同属性.操作.关系的对象集合的总称. 在面向过程设计中,数据和算法组织成为程序.而面向对象中,数据+算法的理论基础并没有改变,虽

设计模式之UML类图的常见关系

设计模式之UML类图的常见关系 本文来自转载 烧点饭博客 本篇会讲解在UML类图中,常见几种关系: 泛化(Generalization),依赖(Dependency),关联(Association),聚合(Aggregation),组合(Composition). 1.泛化关系 泛化关系是继承或实现的关系,是is a关系,具体表现为类与类的继承,接口与接口的继承,类对接口的实现关系. 2.依赖关系 依赖关系表示为一个类使用另一个类,这种使用关系是具有偶然性的.临时性的.非常弱的,一个类的变化会影

从 Java 代码逆向工程生成 UML 类图和序列图

from:http://blog.itpub.net/14780914/viewspace-588975/ 本文面向于那些软件架构师,设计师和开发人员,他们想使用 IBM? Rational? Software Architect 从 Java? 源代码来逆向工程生成 UML 类和序列图. 逆向工程经常被用来从已有的源代码中以一种抽象模型 UML 格式来获得丢失的设计文档,其可以用来研究一个系统的静态结构和动态行为,并用于扩展新的特性到产品. 作者详细说明了使用 IBM Rational Sof