关于UML概述

关系：

执行者间：泛化(extend)

执行者与用例：关联

用例间：包含、扩展、泛化

类间：泛化、实现、依赖、关联（组合、聚合）

构件间：依赖

 

知识点：

1 OCL：对象约束语言

2 构件：系统中一个物理实现片段

3 包间的依赖关系：《use》、《import》、《access》、《trace》

4 交互图：顺序图（时序图）、协作图（通信图）

5 活动状态：表示过程中命令的执行或工作流程中活动的进行。

动作状态：与活动状态相似，但它们是原子运动并且当它们处于活动状态时不允许发生转换。

6 活动图的边包括对象流（对象与活动间的关系）和控制流。

7活动：表示一个行为、状态。

8 类在运行时进行实例化，称为对象。

9状态机：展现状态与状态转换的图。用于对系统的动态行为建模。

10类：约束、重复度、角色名、可见性。

 

UML：

1、用例图：用例图主要应用于分析阶段，用来描述用户的需求。既描述用户要待开发的软件“做什么”。   主要元素：用例、执行者、关联关系。

2、类图：主要用来描述整个系统的静态组织结构，主要展现类之间的关系。（用于系统模式时，主要用于创建领域模型、分析模型、设计模型）

3、状态图：主要用来描述业务的流程处理，其中适合于描述某个对象其生命周期内的运行情况，也可以用来描述某个工作流。

4、活动图：主要用来描述业务流程，最适合用来描述某个业务（工作）流程，或操作、方法的操作流程。（一种特殊形式的状态机，可以包含并发线程的分叉控制）   主要元素：节点、边。（泳道区分负责活动的对象；节点主要是指活动，对象，和分支，分叉）

5、时序图（顺序图）：用于描述对象间动态的交互关系，着重表现对象间消息传递的时间顺序。

6、协作图：用于描述相互合作的对象间的交互关系和链接关系。

7、部署图：主要用来描述应用系统如何部署（安装）到物理设备（计算机、读卡器..）即用来描述系统中软件和硬件的物理架构。  主要建模元素：节点（一组运行资源，计算机设备、存储器..）

8、包图：主要用来对语义相近或相关的对象（事物）分组。

9、组件图（构件图）：主要用来反应代码间的物理结构。   主要建模元素：构件（可包括包、类）

 

 

具体：

1.用例图：

参与者：系统的外部用户和环境，代表了系统的使用者和环境。

用例：用来描述系统对参与者所提供的服务和功能。用例是一个叙述性文档，描述了参与者使用系统完成某个事件时的事情发生顺序。用例反映了系统的使用过程，体现了其描述过程中的需求情况。

关联关系：定义了参与者同用例及用例之间的连接关系，标识了系统为不同参与者提供的服务项目类型和用例的依赖和泛化等关系。

2.活动图

初始节点和活动终点

活动：一个行为、状态。

转换：表示活动间的控制或者数据变换

分叉与结合

分支与监护条件：监护条件是一个布尔表达式

泳道：描述多个对象间的交互。

3.类图

类：类代表了被建模的应用领域中的离散概念——物理实体（如飞机）、商业事物（如一份订单）、逻辑事物（如广播计划）、应用事物（如取消键）、计算机领域的事物（如哈希表）或行为事物（如一项任务）。具有属性和操作，采用矩形框表示。

类名

属性

操作

分类：

1、             用例图

2、             静态图：类图、对象图、包图

3、             行为图：活动图、状态图、交互图

4、             实现图：部署图、构件图

符号：

泛化（继承）：—▷

关联：—

简单消息：—>

同步消息：—▶

返回消息：<-----

异步消息：—>

分支：◇

初始节点：●

活动终点：

实现：----▷

依赖：--à

扩展：--à（向里，extends）

包含：--à（向外，include）

聚合：♢—

组合：♦—

 

代码重构：在保持功能不变的情况下，改善代码的质量，提高代码的复用性。

代码重构的原则：

重构与设计、重构与性能、重构与模式、重构与思想。

重构的使用情况：

添加新功能、修改错误、复审程序代码时

1.     提取方法：Extract Method 通过从现有的方法移动代码到新方法中增加代码的清晰度和重用程度。

2.     移动方法：Move Method 当一个方法引用一个类中的数据比引用它本身类的数据要多时

3.     采用查询替换临时变量：若一个临时变量仅仅在使用它的方法中可见，则用一个查询方法取代该变量会使得代码更加易读。

4.     提升方法：在子类中相同的方法容易出错并很难维护

 

 

一、工厂模式：将创建和使用对象分离。

（1）简单工厂：只是一个产品家族中的部分。

（2）工厂方法：针对一个产品家族。

（3）抽象工厂：针对多个（至少2个）产品家族。

核心：工厂方法

抽象工厂模式使用：经常要定义多个类，并通过NEW对其进行实例化。一旦对象多了，且在实例化的时候，要做的初始化工作就比较复杂啦。

二、单例模式：单例类只能有一个实例。（对于某些类来说，只有一个实例是非常重要的）

（1）饿汉式单例：就是在类被装载器装载的时候就实例化了一个对象。

（2）懒汉式单例：就是在getInstance()方法被第一次调用的时候实例化一个对象。

核心：就是构造方法私有化，getInstance()方法。

例如：系统中可以有很多种类型的打印机，但是只有一个打印假脱机、一个文件系统和一个窗口管理器。使用该模式，可以保证一个类只有一个实例，并提供一个访问它的全局访问点。

三、门面模式（外观模式）：为了子系统更易于被访问。 层次结构

门面和各子系统之间还是组合/聚合关系

四、适配器模式：主要针对复用（重用）第三方的软件功能。但是第三方软件的接口和现有系统的接口不一致。

（1）类适配器模式：适配器继承第三方的类。

（2）对象适配器模式：组合/聚合。就用第三方的类定义的变量作为适配器的成员变量。

五、观察者模式：当一个对象的数据发生改变以后，要通知所有的与之相关的对象。（通知状态变化）

（1）Observable（类）被观察者。最核心的两个方法，一个setChanged（）和notifyObservers（）。setChanged()用来说明被观察者的数据已经发生改变，可以通知观察者;notifyObservers()方法用来通知所有的观察者。同时，会调用每一个观察者的update（）方法。

（2）Observer（接口）：观察者都应当实现该接口，也就是要实现update（）方法，

核心：应当建立观察者和被观察者的关联关系。实际上就是要将观察者添加到被观察者的“观察者向量中”。

六、策略模式：应对变化。

（1）针对接口编程，而不要针对实现编程。(依赖倒置原则)

（2）优先使用聚合或组合复用其他类的功能。（聚合/组合复用原则）

（3）分离变化，进行封装。

七、命令模式：将紧耦合的关系进行解耦，转化为松耦合的关系。（将请求封装成一个对象）

（1）命令的下达者。

（2）命令的传递者。

（3）命令的执行者。

八、装饰模式：动态的增加类的职责。

（1）装饰者和被装饰者都应当继承同一个类。

（2）装饰者既能装饰被装饰者，又能装饰装饰者。（在装饰者当中必须用他们的父类来定义成员变量）

九、责任链模式：对请求进行分级处理。

十、对象池模式：缓存和共享。

destroyPool

createPool

 

门面模式是迪迷特法则的典型运用

MVC模型的基本工作原理是基于观察者模式

设计模式的思想根源是( 面向对象 )基本原则的宏观运用,本质上是没有任何模式的,发现模式的人永远是大师,而死守模式的人,最对只能是一个工匠.

 

模式的使用/效果：

1.单件模式：

当一个类只有一个实例而且客户可以从一个众所周知的访问点访问它时；当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。

对唯一实例提供受控访问、缩小名称空间、允许对操作和表示进行精化操作、运行可变数目的类实例数、提供了比类操作更多的灵活性。

2.工厂模式：

  一个系统需要独立于它的产品的创建、组件和表示；一系列相关产品对象的设计以便进行联合使用；提供一个产品库，只想显示它们的接口而不是实现。

分离了具体的类，可以控制系统创建对象的类。。。。

3.门面模式：

  为一个复杂子系统提供一个简单接口；客户程序与抽象类的实现部分之间存在很大的依赖性；构建一个层次结构的子系统。

对客户屏蔽子系统组件，实现子系统与用户间的松耦合。

4.适配器模式：

  希望复用一个或一系列已存在的类，其接口不符合当前的设计要求；希望创建一个可复用的类，该类必须能够与接口不可预定的类协同工作。

5.命令模式：

日志修改、取消操作、、、、

 

 

分类：

1 创建型

单例模式

工厂模式{简单工厂   工厂方法  抽象工厂}

对象池模式

2 构造型

外观模式

适配器{ 类   对象}模式

3 行为型

命令模式

观察者模式

策略模式

 

 

耦合：类之间的连接、联系。

 

1.单一职责原则（SRP）：消除耦合，减少因需求变化引起的代码僵化。

“就一个类而言，应该仅有一个引起它变化的原因。”也就是说，不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到不相干的职责。再通俗一点地说就是，不该你管的事情你不要管，管好自己的事情就可以了，多管闲事害了自己也害了别人。

将不同的职责分配给不同的类，使单个类的职责尽量单一，就隔离了变化，这样他们也不会互相影响了。

例如：一个人身兼数职，而这些事情相互之间又关联不大，甚至有冲突，那他就无法很好地解决这些职责，应该分到不同的人身上去做才对。

2.开放—封闭原则(OCP)：软件实体应当对扩展开放，对修改关闭。

“软件实体(类、模块、函数等)应该是可以扩展的，但是不可修改。”意思是“你可以随便增加新的类，但是不要修改原来的类”。其实这里还是一个隔离变化的问题。

例如：如下图，有一个客户端程序通过数据访问接口操作数据，对于这套系统来说，一开始计划使用的是SQL Server或Oracle数据库，但是后来考虑到成本，改用免费的MySQL；那么对于客户端程序来说，后来数据的扩展对它没有任何影响，它在不知不觉间就用上了免费好用的MySQL数据库，这全要感谢OCP原则。

例如：工资税，不同国家有不同的计算规则。

3.依赖倒置原则(DIP)

“抽象不应该依赖于细节。细节应该依赖于抽象。”关于这个原则，还有种说法是.“高层模块不应该依赖于低层模块，两者都应该依赖于抽象。”其实怎么说都是对的，关键就是要理解一点，只有抽象的东西才是最稳定的，也就是说，我们依赖的是它的稳定。如果将来“抽象”也不稳定了，那么谁稳定我跟谁，其实说白了不就是傍大款吗！哈哈！

例如：参考下图的设计，一个开关跟灯直接连接在一起了，也就是说开关依赖于灯的打开和关闭方法，那么如果我想用这个开关也可以打开其他东西呢，比如电视、音响。显然这个设计是无法满足这个要了，因为我们依赖了细节而不是抽象，这个开关已经等价于“灯的开关”。

4.接口隔离原则(ISP) ：使用多个专门的接口比使用单一的总接口好。

“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，就是不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。

例如：参考下图的设计，在这个设计里，取款、存款、转账都使用一个通用界面接口，也就是说，每一个类都被强迫依赖了另两个类的接口方法，那么每个类有可能因为另外两个类的方法(跟自己无关)而被影响。拿取款来说，它根本不关心“存款操作”和“转账操作”，可是它却要受到这两个方法的变化的影响，真是土鳖！！！

应该为每个类都单独设计专门的操作接口，使得它们只依赖于它们关心的方法，这样就不会互相影响。

5.里氏替换原则(LSP) ：即完全替换原则，子类有的方法，父类没有，子类不能替换父类。

“子类型必须能够替换掉它们的基类型。”也就是说继承中的“ISA”关系是必须保证的，否则还算什么继承啊！如果违反了LSP原则，常会导致在运行时(RTTI)的类型判断违反OCP原则。

例如：函数A的参数是基类型，调用时传递的对象是子类型，正常情况下，增加子类型都不会影响到函数A的，如果违反了LSP，则函数A必须小心的判断传进来的具体类型，否则就会出错，这就已经违反了OCP原则。

 

注意：一个系统或子系统要拥有良好的扩展性和实现运行期内绑定，有两个必要的条件：LSP、DIP。

LSP是保证OCP的重要原则。（1.面对的是接口编程，而不是面向实现；2.用组合而不主张用继承）

 

 

6.合成复用原则（CARP）：在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分。

7.最少知识原则（LOD）：一个软件实体要尽可能地只与和它最近的实体进行通信（“只和你最近的朋友进行交互”）。  （即迪米特原则）“不要和陌生人说话”

8.无循环依赖原则（ADP）