UML第一部分和设计模式原则总结

一、UML简述

UML是一种直观化、明确化 、构建和文档化软件系统产物的通用可视化建模语言，它是所有建模人员可以使用的通用建模语言，它能在对众多系统建模的同时，尽可能的简洁。UML概念和模型可以被划分为静态结构、动态行为、实现构造、模型组织、扩展机制。

 

二、UML一览

视图是表达系统单个方面的建模UML结构的简单子集，它在最高层次可以划分为三个领域 结构性分类、动态行为和模型管理。分类视图包括静态视图、用例视图和实现视图；行为视图包括状态机图 活动图和交互图；模型管理描述了用层次式的单元对模型自身的组织 包是模型的通用组织单元 特殊的包包括模型和子系统。

 

三、静态视图

静态视图是UML的基础，静态视图中的关键元素是分类和它们之间的关系，分类之间的关系是关联、概括，以及各种依赖，包括实现和使用。静态视图主要是由类及类间相互关系构成，这些相互关系包括：关联、泛化和各种依赖关系，如使用和实现关系。一个类是应用领域或应用解决方案中概念的描述。类图是以类为中心来组织的，类图中的其他元素或属于某个类或与类相关联。静态视图用类图来实现，正因为它以类为中心，所以称其为类图。

 

四、用例视图

用例视图是从外部用户的角度捕获系统 、子系统或类的行为，用例通过系统与一个或

多个活动者之间的一系列消息描述了与活动者的交互。活动者是与系统 子系统或类交互的外部人员 、进程或事务的理想化，每个活动者参与一个或多个用例；用例视图的作用：使用户容易理解 其中元素的用途；使码农更容易实现这种元素。

 

 

设计模式原则总结

聪明的人把房子盖在磐石上，无知的人，把房子盖在沙土上，对于开发者而言，设计模式就是那坚固的磐石-----java开发者社区。

一、单一职责原则：

就一个类而言，应该仅有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。

二、开放-封闭原则     

软件实体（类、模块、函数等）应该可以扩展，但是不可以修改，即对于扩展是开放的，对于更改是封闭的；开放-封闭原则是面向对象设计的核心所在，遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然后，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

三、里氏代换原则

定义：子类型必须能够替换掉它们的父类型。也就是说，一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它觉察不出父类对象和子类对象的区别，即在软件里面，把父类都替换成它的子类，程序的行为没有变化。只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新

的行为。

 

四、依赖倒置原则

 

1、高层模块不应该依赖低层模块，两个都应该依赖抽象。

 

 

 

2、抽象不应该依赖细节，细节应该依赖抽象。

 

程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之就是过程化的设计了。

 

五、迪米特法则

 

又叫最少知识原则。如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。该法则首先强调的前提是在类的结构设计上，每一个类都应该尽量降低成员的访问权限，即一个类包装好自己的private状态，不需要让别的类知道的字段或行为就不要公开。迪米特法则的根本思想，是强调了类之间的松耦合。类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。