面向对象设计

面向对象的设计包括概要设计和详细设计

 

精化类图：

  【依赖关系】：是一种使用的关系，即一个类的实现需要另一个类的协助。

  【代码表现】：局部变量、方法的参数或者对静态方法的调用

  【箭头及指向】：带箭头的虚线，指向被使用者

 

 

 

 

【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。

  【代码体现】：成员变量

 

 

 

 

2. 关联（Association)

  【聚合关系】：是整体与部分的关系，且部分可以离开整体而单独存在。

   聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。

  【代码体现】：成员变量

  【箭头及指向】：带空心菱形的实心线，菱形指向整体

  

 

2. 关联（Association)

   【组合关系】：是整体与部分的关系，但部分不能离开整体而单独存在。

    组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。

  【代码体现】：成员变量

  【箭头及指向】：带实心菱形的实线，菱形指向整体

 

 

3. 泛化（Generalization）

 【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。

 【箭头指向】：带三角箭头的实线，箭头指向父类

 

 

 

4. 实现（Realization）

   【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现.

   【箭头指向】：带三角箭头的虚线，箭头指向接口;

 

 

 

 

 

 

设计模式

—  通用职责分配软件模式（General Responsibility Assignment Software Patterns, GRASP）

—  创建者、信息专家、控制器、高内聚、低耦合、多态、纯虚构、间接性和防止变异

—  GoF(Gang of Four)模式

—  23种设计模式，其中基本的有适配器、工厂、单实例类、策略、组合、外观和观察者等模式

—  开闭原则：对修改关闭，对扩展开放。依赖接口编程而不依赖实现编程。

—  继承/组合复用原则：两种重要的重用手段：Inheritance & composition，能用composition就不用Inheritance。

—  高内聚低耦合原则（单一职责原则）：对象之间存在强耦合通常意味着弱内聚，而强内聚的对象通常意味着与其他对象之间存在弱耦合。面向对象设计追求强内聚、弱耦合。

 

 

GRASP-创建者模式

 

—  问题：一个对象由谁（哪个对象）创建？

—  指导原则：将创建一个对象A的职责分配给对象B的条件是B“包含”或组成聚集了A，B记录A，B紧密地使用A或者B具有A初始化数据并且在创建A时会将这些数据传递给A。简而言之，就是一个对象要由拥有或者使用其信息的、与其有密切关系的另一个已存在的对象创建。

—  例：在POS机系统中的Sale对象是由那个对象类创建？

—  对于对象Sale由谁创建，分析一下领域模型就会发现，可以认为Register是记录Sale的类。因此Register对象是创建Sale对象的合理选择。

 

 

 

GRASP-信息专家模式

 

—  信息专家（通常称为专家）模式是最基本的职责分配原则之一。

—  指导原则是：给对象分配职责时，应该把职责分配给具有完成该职责所需要信息的那个类。

—  例：在POS机系统中，销售的总额该如果确定？决定总额的一些元素应该是属于哪些对象的信息？

—  按照信息专家的建议，这里应当寻找具有确定总额所需信息的那个对象类。分析领域模型和设计模型得到，要计算总额应该知道销售的所有SalesLineItem实例及其小计之和。Sale实例包含了上述信息。

—  为了确定商品的小计，这里需要SalesLineItem.quantity和ProductDescription.price。SalesLineItem知道其数量和与其关联的ProductDescription。

 

 

GRASP-控制器模式

—  根据MVS（Model View Separation）原则，UI对象不应当包含应用逻辑或业务逻辑。应该把UI层的操作或者请求委派给一个协调者，由协调者把任务转发给领域层的领域对象。

—  控制器就是这样一个协调者。

—  例如在POS机系统中，enterItem和endSale这样的系统事件，应使用谁作为控制器？

—  指导原则是：控制器是UI层之上的第一个对象，它负责接收和处理系统操作消息。

—   

—  控制器的选择原则是：

—  代表全部“系统”、“根对象”、运行软件的设备或主要的子系统（如外观控制器）；

—  代表发生系统操作的用例场景。在用例场景中发生的系统事件通常命名为<UseCaseName>Handler、<UseCaseName>Coordinator或<UseCaseName>Session。

—  对于用同一用例场景的所有系统事件使用相同的控制器类。

 

 

GRASP-低耦合模式

—  低耦合模式是一个评价模式。

—  低耦合原则适用于软件开发的很多方面，它是构建软件最重要的目标之一。

—  指导原则是：分配职责以使耦合保持在较低的水平。

例如，在POS机系统中， Register记录了Payment,所以创建者模式建议将Register作为创建Payment的候选者。Register实例会把addPayment消息发送给Sale，并把新的Payment作为参数传递给它。这种职责分配使Register类和Payment类之间产生了耦合，即Register类要知道Payment类

 

 

 

GRASP-高内聚模式

 

—  高内聚模式是一个评价模式。

—  内聚是软件设计中的一种基本品质，内聚可以非正式地用于度量软件元素操作在功能上的相关程度，也可以用于度量软件元素完成的工作量。

—  指导原则是：分配职责可保持较高的内聚性。

 

 

 

 

构件图

—  构件图描述构件及其相互依赖关系，构件是逻辑体系结构---类、对象和它们间的关系和协作中定义的概念和功能在物理体系结构中的实现。

—  构件：相对逻辑设计上的类和对象，构件是和物理系统相关的一个概念，不同的语言对构件的定义有所不同，UML中的构件含义包括代码文件，也指数据库、动态链接库、web页面等。

 

—  构件图的主要元素包括构件、接口和依赖关系。

—  构件 ：是定义了良好接口的物理实现单元，是系统中可替换的物理部件。

—  构件可以是源代码构件、二进制构件或一个可执行的构件。在UML中，构件用一个左侧带有突出两个小矩形的矩形来表示。

 

 

—  构件

—  对于一个构件而言，它有两类接口：提供（provided）接口和所需（required）的接口。标识接口的构件表示方法有3种。

 

 

—  依赖

—  构件间的关系以依赖的形式表达。把提供服务的构件称为提供者，把使用服务的构件称为客户。

—  在UML中，构件图中依赖关系的表示方法与类图中依赖关系相同，都是一个由客户指向提供者的虚线箭头。

 

 

 

 

—  接口

—  接口用于描述构件所提供的服务的一组操作集合，指定了构件的外部可见操作。可以通过接口访问一个构件。

—  接口和构件之间的关系分为两种：

—  实现关系（Realization）

—  依赖关系（Dependency）

—  在UML图中，接口和构件之间用实线连接表示实现关系；而接口和构件之间用虚线箭头连接则表示依赖关系。

 

构件与接口之间的关系:  实现关系和依赖关系

 

 

 

 

 

     

 

 

 

                导出接口                                导入接口

 

 

 

部署图

 

—  节点

—  节点代表一个运行时计算机系统中的硬件资源。节点通常拥有一些内存，并具有处理能力。例如一台计算机、一个工作站等其它计算设备都属于节点。

—  在UML中，节点用一个立方体来表示

 

 

—  按照节点是否有计算能力，把节点分为两种类型：处理器和设备，分别用构造型《Processor》和构造型《Device》表示处理器和设备。

 

                 

 

 

          

Ø  处理器节点（Processor）

    处理器是能够执行软件、具有计算能力的节点。

Ø  设备节点（Device）

  设备是没有计算能力的节点，通常情况下都是通过其接口为  

  外部提供某种服务，例如打印机、IC读写器，如果我们的系

  统不考虑它们内部的芯片，就可以把它们看作设备。

 

—  节点间的连接

—  节点之间的连接表示节点之间物理连接以及其上用的通信协议。用直线表示。

 

 

 

—  构件分配到节点

—  当某些构件驻留在某个节点时，可以在该节点的内部描述这些构件。