UML第二部分与创建型模式

UML第二部分

状态机视图

1.概述

状态机对类的对象的可能生命历史建模 状态机包含由迁移连接的状态 每个状态对对

象生命期中的一段时间建模 该时间内对象满足一定的条件 当事件发生时 它可能导致

迁移的激发 使对象改变至新状态 当迁移激发时 附属于迁移的动作可能被执行 状态

机显示为状态图。

2. 状态机

状态机是由状态和迁移组成的图 通常状态机附属于类 描述了类实例对接收事件的响

应 状态机还可以附加于操作 用例 协作 以描述它们的执行。状态机是某个类的对象所有可能生命历史的模型。状态机是对象的局部化视图 该视图将对象与周围世界分开 独立的检查它的行为

3. 事件

事件是具有时间和空间位置的显著发生的某件事 它发生在时间点上 不具有持续时间。

事件种类

4.状态

状态描述了对象生命期中的一段时间 它可以通过三个互补的方面来指定 某些性质上具有相似性的一系列对象值 对象等待某个或某些事件发生的一段时间 对象执行某些正在进行活动的一段时间 状态可以具有名称 尽管它常常是匿名的及用它的动作来描述。

5.迁移

迁移具有事件触发 迁移条件 动作和目标状态。

迁移和隐式动作的种类

6.复合状态

复合状态可以分解为连续的或并发的子状态。复合状态中可能有初始状态 至复合状态边界的迁移即隐式为至初始状态的迁移 对象从最外层的初始状态开始 类似的 复合状态可包含结束状态 至结束状态的迁移触发复合状态上的结束迁移（无触发迁移）。

活动视图

1.概述

活动视图是用于显示执行某个计算过程中的运算活动的状态机的一种变形 活动状态表

现了一项活动 工作流的步骤或操作的执行 活动图描述了顺序和并发活动分组 活动视

图表达为活动图。

2. 活动图

活动图是活动视图的标记形式。它包含了一些方便使用的速记符号 事实上 这些符号可以用于任何的状态图中，尽管混合的标记有时可能会很难看。

3. 活动和其它视图

活动图没有显示所有运算的细节 它们显示了活动的流 但是没有显示执行活动的对象

活动图是设计的一个起点 为了完成设计 每个活动必须被扩展成一个或多个的操作 每

个操作被指派给特定的对象来实现 上述的指派导致了实现活动图的协作设计。

交互视图

1.概述

交互视图描述了实现系统行为角色之间的消息交换序列 分类角色是对交互中充当特殊

角色的对象的描述 从而使该对象区别于相同类的对象 视图提供了系统中行为全局的描

述 它显示了多个对象间的控制流程 交互视图用侧重点不同的两种图来显示 顺序图

和协作图。

2. 协作

协作是对上下文中交互实现某种行为对象群体的描述 它描述了许多相互合作的的对象

集中起来实现某种目标 协作包括了由对象和连接多填充的空槽 协作槽被称为角色 因

为它描述了协作中对象和链的用途。

3. 交互

交互是在协作中由分类角色通过关联角色进行交换的一系列消息。当协作在运行期间存

在时，绑定于分类角色的对象通过绑定于关联角色的链来交换消息实例。交互对操作，用

例或其它行为实体的执行建模。

4. 顺序图

顺序图以二维图表来显示交互。纵向是时间轴；时间自上而下。横向显示了代表协作中

单个对象的分类角色。每个分类角色表现为垂直列--生命线。在对象存在的时间内，角

色显示为虚线，在对象的过程激活时间内；生命线显示为双线。

5.激活

激活是过程的执行，包括它等待嵌套过程的执行时间。在顺序图中，它用部分替换生命线的双道线表示。

6.协作图

协作图是一种类图，它包含类元角色和关联角色。类元角色和关联角色描述了对象的配置和当一个协作执行时可能出现的连接。协作图只对相互间具有交互作用的对象以及对象间的关系建模，忽略了其他对象和关联。

7.模板

模板是一个参数化的协作，并有表示何时使用该协作的标线。参数可以被不同的值替代产生不同的协作，它通常为类指定槽。

设计模式按目的分类可分为三类：

1. 创建型模式：负责对象创建（比如new对象）
2. 结构性模式：处理类与对象间的组合（比如继承关系）
3. 行为型模式：类与对象交互中的职责分配（指责隔离）

创建型模式分为：

　　　1.Singleton单件模式（创建型模式）：

　　　　基本动机是：由类的设计者来规范，来负责，使程序绕过常规的构造器，提供一种机制来保证一个类只有一个实例。

　　　　意图是：保证一个类仅有一个实例，并提供一个该实例的全局访问点。

　　　　代码的实现的话。。我网上查阅了一下JAVA语言的实现方法，其大致步骤都一样：

1. 1. 将该类的构造方法定义为私有方法，这样其他处的代码就无法通过调用该类的构造方法来实例化该类的对象，只有通过该类提供的静态方法来得到该类的唯一实例；
   2. 在该类内提供一个静态方法，当我们调用这个方法时，如果类持有的引用不为空就返回这个引用，如果类保持的引用为空就创建该类的实例并将实例的引用赋予该类保持的引用。

　　　　　这里参考JAVA中实现单例模式的八种方式https://www.cnblogs.com/zhaosq/p/10135362.html

　　　　在单例模式使用中要注意：

1. 1. 可以设置protected，以允许子类派生。
   2. 不要支持序列化，反序列化会导致出现新的对象，与单例模式原则相违背。
   3. 对对象的创建与销毁要注意一下，当对象被指明要生成时再生成，不要求时可不生成。对于垃圾回收，可以交给语言机制处理。
   4. 对于多线程的实现要稍作变化。

　　　　单例模式的多线程实现：

1. 1. 使用静态构造器，因为静态构造器只会被执行一次。
   2. 同时写静态构造方法和私有构造方法。但缺点是当构造方法有参数传入时，不适用。

　　　　单例模式的拓展：

1. 1. 将一个实例扩展到n个实例，例如对象池的实现。
   2. 将new构造器的调用转移到其他类中，例如多个类协同工作环境中，某个局部环境只需要拥有某个类的一个实例。
   3. 理解和扩展Singleton模式的核心是"如何控制用户使用new对一个类的实例构造器的任意调用"。

　　　　2.Abstract Factory 抽象工厂（创建型模式）：

　　　　　　面临的问题是：时下你来，不能应对“具体实例化类型”的变化

　　　　　　解决的办法是：封装变化点——哪里变化，封装哪里。（如果没有变化则不需要额外的封装。）

　　　　　　工厂模式的缘起：变化点在“对象创建”，因此就封装“对象创建”，要求面向接口编程——依赖接口，而非依赖实现。

　　　　　　基本动机是：为了解决“一系列相互依赖的对象的创建工作”，以及多系列对象的创建工作。绕过窗轨的对象创建方法（new），提供一种“封装机制”来避免客户程序和这种“多系列具体对象创建工作”的紧耦合。

　　　　　　意图是：提供一个接口，让该接口负责创建一系列“相关或者相互依赖的对象”，无需指定他们具体的类。

　　　　　　要点在于：

1. 1. 1. 如果没有应对“多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的静态工厂 完全可以。
      2. “系列对象”指的是这些对象之间有相互依赖、或作用的关系，例如游戏开发场景中的“道路”与“房屋”的依赖，“道路”与“地道”的依赖。
      3. Abstract Factory模式主要在于应对“新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。
      4. Abstract Factory模式经常和Factory Method模式共同组合 来应对“对象创建”的需求变化。

　　　　3.Builder模式（创建型模式）：

　　　　　　缘起：假设黄建一个房屋House设施，该房屋的构建有几个部分组成，且各个部分要富于变化。

　　　　　　动机：在软件系统中，有时候面临着”一个复杂对象“的创建工作，其通常由各个部分的子对象用一定算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将他们组合在一起的算法却相对稳定。如何应对这种变化？如何提供一种”封装机制“来隔离出”复杂对象的各个部分“的变化。

　　　　　　意图：将一个复杂对象的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。

　　　　　　要点在于：

1. 1. 1. Builder 模式主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。
      2. 变化点在哪里，封装哪里—— Builder模式主要在于应对“复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。
      3. Abstract Factory模式解决“系列对象”的需求变 化，Builder模式解决“对象部分”的需求变化。Builder模式通常和Composite模式组合使用。

　　　　4.Factory Method 工厂方法（创建型模式）：

　　　　　　在软件开发过程中，要先划分模块，主模块相对稳定，也是高层部分、抽象部分，其他细节部分依赖于高层。耦合关系直接决定着软件面对变化时的行为。要做到高内聚，低耦合。

　　　　　　动机：在软件系统中，经常面临着”某个对象“的创建工作；由于需求的变化，这个对象经常面临着剧烈的变化，但是它却拥有比较稳定的接口。如何应对这种变化；如何提供一种”封装机制“来隔离出”这个易变化对象“的变化，从而保持系统中”其他以来该对象的对象“不随着需求改变而改变？

　　　　　　意图：定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟到子类。

　　　　　　要点：

1. 1. 1. Factory Method模式主要用于隔离类对象的使用者和具体类型之间的几个耦合关系。面对一个经常变化的具体类型，紧耦合关系会导致软件的脆弱。
      2. Factory Method模式通过面向对象的手法，将索要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合关系。
      3. Factory Method模式解决"单个对象"的需求变化，Abstract Factory模式解决"系列对象"的需求变化，Builder模式解决"对象部分"的需求变化。

　　　　5.Prototype原型（创建型模式）：

　　　　　　动机：在软件系统中，经常面临着”某些结构复杂的对象“的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口。如何应对这种变化？如何向”客户程序（使用这些对象的程序）“隔离出”这些易变对象“，从而使得”以来这些易变对象的客户程序“不随着需求改变而改变？

　　　　　　意图：使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象。

　　　　　　Prototype模式的几个要点：

1. 1. 1. Prototype模式同样用于隔离类对象的使用者和具 体类型（易变类）之间的耦合关系，它同样要求 这些“易变类”拥有“稳定的接口”。
      2. Prototype模式对于“如何创建易变类的实体对象” 采用“原型克隆”的方法来做，它使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象——所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方不断地Clone。
      3. Prototype模式中的Clone方法可以利用.NET中的Object类的MemberwiseClone()方法或者序列化 来实现深拷贝。

UML第二部分与创建型模式

原文：https://www.cnblogs.com/niceteam1/p/14379778.html