类图职责分配.ppt

类图职责分配.ppt

《类图职责分配.ppt》由会员分享，可在线阅读，更多相关《类图职责分配.ppt（31页珍藏版）》请在冰豆网上搜索。

-1-实例实例-旅游申请系统中的分析类旅游申请系统中的分析类-2-定义分析类定义分析类定义分析类定义分析类u最终目标是从系统的角度明确说明每最终目标是从系统的角度明确说明每一个分析类的职责和属性以及类之间的一个分析类的职责和属性以及类之间的关系，从而构造系统的分析类视图关系，从而构造系统的分析类视图u并根据这些视图来描述和理解目标系并根据这些视图来描述和理解目标系统，从而为后续的设计提供基本的素材统，从而为后续的设计提供基本的素材-3-定义分析类的过程定义分析类的过程从单个分析类入手，完成如下工作：

从单个分析类入手，完成如下工作：

u1.定义职责定义职责u2.定义属性定义属性u3.定义关系定义关系3.1关联关系关联关系3.2聚合关系聚合关系3.3泛化关系泛化关系u4.统一分析类统一分析类-4-1.定义分析类的职责定义分析类的职责职责是要求某个对象所要执行的事务职责是要求某个对象所要执行的事务契约，在设计中将演化为类的操作契约，在设计中将演化为类的操作（一个或多个一个或多个）获取类的职责获取类的职责u从交互图中的消息得到从交互图中的消息得到u从非功能需求中得到从非功能需求中得到分析阶段表示类的职责分析阶段表示类的职责u“分析分析”操作，约定分析操作前加操作，约定分析操作前加“/”u文本描述文本描述-5-实例：

利用分析操作表示职责实例：

利用分析操作表示职责-6-2.定义分析类的属性定义分析类的属性属性属性（Attribute）用来存储对象的数据信息，是用来存储对象的数据信息，是没有职责的原子事物没有职责的原子事物u属性名是一个名词，清楚地表达了属性保留的信息属性名是一个名词，清楚地表达了属性保留的信息u可以利用文字详细说明属性中将要存储的相关信息可以利用文字详细说明属性中将要存储的相关信息u属性类型应来自业务领域，与编程语言无关属性类型应来自业务领域，与编程语言无关从以下几个方面来定义属性：

从以下几个方面来定义属性：

u识别分析类的过程中，也可同时发现类的属性，包识别分析类的过程中，也可同时发现类的属性，包括：

接在所有格后面的名词或形容词（即某某的属括：

接在所有格后面的名词或形容词（即某某的属性）、不能成为类的名词以及字段列表中所描述的性）、不能成为类的名词以及字段列表中所描述的数据需求数据需求u作为一般业务常识，是否有从类职责范围考虑所应作为一般业务常识，是否有从类职责范围考虑所应包括的属性包括的属性u该业务领域的专家意见以及过去的类似系统该业务领域的专家意见以及过去的类似系统-7-实例：

为分析类添加属性实例：

为分析类添加属性-8-3.定义分析类的关系定义分析类的关系对象不能孤立地存在，它们之间需要对象不能孤立地存在，它们之间需要频繁地通过消息进行交互从而执行有频繁地通过消息进行交互从而执行有用的工作，并达到用例的目标用的工作，并达到用例的目标为此，相应的类之间也应该存在特定为此，相应的类之间也应该存在特定的关系来支持这种交互过程的关系来支持这种交互过程u3.1关联关系：

协作关系关联关系：

协作关系u3.2聚合关系：

整体聚合关系：

整体-部分部分u3.3泛化关系：

抽象泛化关系：

抽象-具体具体-9-3.1关联关系关联关系关联是类之间的一种结构化关系，是类之关联是类之间的一种结构化关系，是类之间的语义联系间的语义联系u表明类的对象之间存在着链接表明类的对象之间存在着链接u对象是类的实例，而链接是关联的实例对象是类的实例，而链接是关联的实例识别关联的基本思路识别关联的基本思路u从交互模型中发现对象之间的链接，从而在从交互模型中发现对象之间的链接，从而在相应的类上建立关联关系：

如相应的类上建立关联关系：

如VOPC图中关图中关联关系联关系u从业务领域出发，分析领域中所存在的实体从业务领域出发，分析领域中所存在的实体类之间的语义联系，为那些存在语义联系的类之间的语义联系，为那些存在语义联系的类之间建立关联关系：

如实体类之间的各种类之间建立关联关系：

如实体类之间的各种语义联系语义联系-10-实例：

实体类之间的关联关系实例：

实体类之间的关联关系-11-细化关联关系细化关联关系关联具有：

名称、端点和角色名、多重性关联具有：

名称、端点和角色名、多重性u名称：

动词短语名称：

动词短语u端点和角色名端点和角色名u多重性表达式：

多重性表达式：

*，1.*，1-40，5，3,5,8，自反关联自反关联自反关联是指一个类自身之间存在关自反关联是指一个类自身之间存在关联，它表明同一个类的不同对象之间联，它表明同一个类的不同对象之间存在链接存在链接-12-13-关联类关联类关联类关联类（AssociationClass）u是一种被附加到关联上的类，用来描是一种被附加到关联上的类，用来描述该关联自身所拥有的属性和行为述该关联自身所拥有的属性和行为u当某些属于关联自身的特征信息无法当某些属于关联自身的特征信息无法被附加到关联两端的类时，就需要为该被附加到关联两端的类时，就需要为该关联定义关联类关联定义关联类-14-3.2聚合关系聚合关系聚合聚合（Aggregation）关系是一种特关系是一种特殊的关联关系殊的关联关系u除了拥有关联关系所有的基本特征之除了拥有关联关系所有的基本特征之外外u两个关联的类还分别代表两个关联的类还分别代表“整体整体”和和“部分部分”，意味着整体包含部分，意味着整体包含部分可以在已有的关联关系基础上，通过可以在已有的关联关系基础上，通过分析两个关联的类之间是否存在如何分析两个关联的类之间是否存在如何语义来识别聚合关系语义来识别聚合关系uA（整体）由（整体）由B（部分）构成（部分）构成uB（部分）是（部分）是A（整体）的一部分（整体）的一部分-15-3.3泛化关系泛化关系泛化是指类间的结构关系、亲子关系泛化是指类间的结构关系、亲子关系u子类继承父类所具有的属性、操作和关联子类继承父类所具有的属性、操作和关联分析阶段的泛化关系主要来自与业务对象分析阶段的泛化关系主要来自与业务对象模型，针对实体类，结合业务领域的需求，模型，针对实体类，结合业务领域的需求，从两个方面来提取泛化关系：

从两个方面来提取泛化关系：

u是否有类似的结构和行为的类，从而可以抽是否有类似的结构和行为的类，从而可以抽取出通用的结构和行为构成父类取出通用的结构和行为构成父类u单个实体类是否存在一些不同类别的结构和单个实体类是否存在一些不同类别的结构和行为，从而可以将这些不同类别的结构抽取行为，从而可以将这些不同类别的结构抽取出来构成不同的子类出来构成不同的子类-16-实例：

实体类间的聚合和泛化实例：

实体类间的聚合和泛化-17-4.统一分析类统一分析类类类体现了系统的静态结构，通过分析体现了系统的静态结构，通过分析类图体现软件静态结构类图体现软件静态结构统一分析类的目的是确保每个分析类统一分析类的目的是确保每个分析类表示一个单一的明确定义的概念，而表示一个单一的明确定义的概念，而不会职责重叠不会职责重叠在分析工作完成之前，需要过滤分析在分析工作完成之前，需要过滤分析类以确保创建最小数量的新概念类以确保创建最小数量的新概念-18-示例：

统一分析类示例：

统一分析类-19-分析阶段的重点在于找出体现系统核心业分析阶段的重点在于找出体现系统核心业务所需数据的实体类，而界面和业务逻辑务所需数据的实体类，而界面和业务逻辑细节分别由边界类和控制类隐藏细节分别由边界类和控制类隐藏在很多在很多UML模型中，分析阶段的工作就模型中，分析阶段的工作就是找到这些实体类是找到这些实体类这些实体类组成系统概念模型这些实体类组成系统概念模型（分析类图分析类图）通过各个用例的通过各个用例的VOPC图，删除那些没有图，删除那些没有引用的实体类，即可得到由实体类组成的引用的实体类，即可得到由实体类组成的分析类图，这些是分析的关键分析类图，这些是分析的关键-20-VOPC图图对于每个对于每个“用例实现用例实现”都存在若干张交互都存在若干张交互图进行描述，而这些交互图中会使用到各图进行描述，而这些交互图中会使用到各种分析类的对象种分析类的对象对于每一个对于每一个“用例实现用例实现”，需要绘制与之，需要绘制与之相关的类图，即相关的类图，即VOPC图图u参与类类图参与类类图（VOPC,ViewOfParticipatingClassesClassDiagram）u类图中的元素来自于交互图中的对象类图中的元素来自于交互图中的对象u类图中的关系来自于交互图中的消息类图中的关系来自于交互图中的消息（和业务和业务对象模型对象模型），分析阶段主要使用关联关系，也，分析阶段主要使用关联关系，也可根据业务模型引入泛化、聚合等关系可根据业务模型引入泛化、聚合等关系实例：

绘制实例：

绘制VOPC类图类图-21-实例：

旅游申请实例：

旅游申请系统实体类类图系统实体类类图-22-23-24-25-GRASP模式模式描述对象设计和职责分配的基本原则描述对象设计和职责分配的基本原则GeneralResponsibilityAssignmentSoftwarePatterns信息专家模式信息专家模式创建者模式创建者模式高内聚模式高内聚模式低耦合模式低耦合模式控制器模式控制器模式-26-27-2.创建者模式创建者模式如果符合下面的一个或多个条件，则如果符合下面的一个或多个条件，则可将创建类可将创建类A实例的职责分配给类实例的职责分配给类B：

类：

类B聚合类聚合类A的对象。

的对象。

：

类：

类B包含类包含类A的对象。

的对象。

：

类：

类B密切使用类密切使用类A的对象的对象-28-3.低耦合模式低耦合模式分配一个职责，使得保持低耦合度，分配一个职责，使得保持低耦合度，支持低的依赖性，减小变更带来的影支持低的依赖性，减小变更带来的影响，低耦合是一个时刻铭记于心的原响，低耦合是一个时刻铭记于心的原则，是一个时常考虑的设计目标。

则，是一个时常考虑的设计目标。

从类从类A到类到类B的耦合的常见形式：

的耦合的常见形式：

lA具有引用具有引用B的实例或的实例或B本身的属性本身的属性lA调用调用B对象中的服务对象中的服务lA的方法具有的方法具有B类型的参数或类型的参数或B类型的局部变量，或返回的对象是类型的局部变量，或返回的对象是B的实例的实例lA是是B的直接或间接的子类。

的直接或间接的子类。

lB是一个接口，是一个接口，A实现了这个接口。

实现了这个接口。

-29-4.高内聚模式高内聚模式分配一个职责，使得保持高内聚。

分配一个职责，使得保持高内聚。

如果一个元素具有很多紧密相关的职如果一个元素具有很多紧密相关的职责，而且只完成有限的功能，则这个责，而且只完成有限的功能，则这个元素具有高内聚性。

一个低内聚性的元素具有高内聚性。

一个低内聚性的类会执行许多互不相关的事物，或者类会执行许多互不相关的事物，或者完成太多的功能。

完成太多的功能。

-30-5.控制器模式控制器模式把接收或者处理系统事件消息的职责把接收或者处理系统事件消息的职责分配给一个类分配给一个类表示这个系统或子系统（外观控制器）表示这个系统或子系统（外观控制器）表示一个发生系统事件的用例场景（用例或会话控制器）表示一个发生系统事件的用例场景（用例或会话控制器）当系统不具有太多的系统事件时，选择外观控制器当系统不具有太多的系统事件时，选择外观控制器当外观控制器由于过多的职责而变得当外观控制器由于过多的职责而变得“臃肿臃肿”时，采用时，采用用例控制器。

用例控制器。

-31-