类图职责分配总结.ppt

-*- 定义分析类的过程 从单个分析类入手，完成如下工作： 1. 定义职责 2. 定义属性 3. 定义关系 3.1 关联关系 3.2 聚合关系 3.3 泛化关系 4. 统一分析类 -*- 1. 定义分析类的职责 职责是要求某个对象所要执行的事务契约，在设计中将演化为类的操作(一个或多个 ) 获取类的职责 从交互图中的消息得到 从非功能需求中得到 分析阶段表示类的职责 “分析”操作，约定分析操作前加“//” 文本描述 -*- 实例：利用分析操作表示职责 -*- 2. 定义分析类的属性 属性(Attribute)用来存储对象的数据信息，是没有职责的原子事物 属性名是一个名词，清楚地表达了属性保留的信息 可以利用文字详细说明属性中将要存储的相关信息 属性类型应来自业务领域，与编程语言无关 从以下几个方面来定义属性： 识别分析类的过程中，也可同时发现类的属性，包括：接在所有格后面的名词或形容词（即某某的属性）、不能成为类的名词以及字段列表中所描述的数据需求 作为一般业务常识，是否有从类职责范围考虑所应包括的属性 该业务领域的专家意见以及过去的类似系统 -*- 实例：为分析类添加属性 -*- 3. 定义分析类的关系 对象不能孤立地存在，它们之间需要频繁地通过消息进行交互从而执行有用的工作，并达到用例的目标 为此，相应的类之间也应该存在特定的关系来支持这种交互过程 3.1 关联关系：协作关系 3.2 聚合关系：整体-部分 3.3 泛化关系：抽象-具体 -*- 3.1 关联关系 关联是类之间的一种结构化关系，是类之间的语义联系 表明类的对象之间存在着链接 对象是类的实例，而链接是关联的实例 识别关联的基本思路 从交互模型中发现对象之间的链接，从而在相应的类上建立关联关系：如VOPC图中关联关系 从业务领域出发，分析领域中所存在的实体类之间的语义联系，为那些存在语义联系的类之间建立关联关系：如实体类之间的各种语义联系 -*- 实例：实体类之间的关联关系 -*- 细化关联关系 关联具有：名称、端点和角色名、多重性 名称：动词短语 端点和角色名 多重性表达式：*，1..*，1-40，5，3,5,8，… 自反关联 自反关联是指一个类自身之间存在关联，它表明同一个类的不同对象之间存在链接 -*- -*- 关联类 关联类(Association Class) 是一种被附加到关联上的类，用来描述该关联自身所拥有的属性和行为 当某些属于关联自身的特征信息无法被附加到关联两端的类时，就需要为该关联定义关联类 -*- 3.2 聚合关系 聚合(Aggregation)关系是一种特殊的关联关系 除了拥有关联关系所有的基本特征之外 两个关联的类还分别代表“整体”和“部分”，意味着整体包含部分 可以在已有的关联关系基础上，通过分析两个关联的类之间是否存在如何语义来识别聚合关系 A（整体）由B（部分）构成 B（部分）是A（整体）的一部分 -*- 3.3 泛化关系 泛化是指类间的结构关系、亲子关系 子类继承父类所具有的属性、操作和关联 分析阶段的泛化关系主要来自与业务对象模型，针对实体类，结合业务领域的需求，从两个方面来提取泛化关系： 是否有类似的结构和行为的类，从而可以抽取出通用的结构和行为构成父类 单个实体类是否存在一些不同类别的结构和行为，从而可以将这些不同类别的结构抽取出来构成不同的子类 -*- 实例：实体类间的聚合和泛化 -*- 4.统一分析类 类体现了系统的静态结构，通过分析类图体现软件静态结构 统一分析类的目的是确保每个分析类表示一个单一的明确定义的概念，而不会职责重叠 在分析工作完成之前，需要过滤分析类以确保创建最小数量的新概念 -*- 示例：统一分析类 -*- 分析阶段的重点在于找出体现系统核心业务所需数据的实体类，而界面和业务逻辑细节分别由边界类和控制类隐藏 在很多UML模型中，分析阶段的工作就是找到这些实体类 这些实体类组成系统概念模型(分析类图) 通过各个用例的VOPC图，删除那些没有引用的实体类，即可得到由实体类组成的分析类图，这些是分析的关键 -*- VOPC图 对于每个“用例实现”都存在若干张交互图进行描述，而这些交互图中会使用到各种分析类的对象 对于每一个“用例实现”，需要绘制与之相关的类图，即VOPC图 参与类类图(VOPC, View Of Participating Classes Class Diagram) 类图中的元素来自于交互图中的对象 类图中的关系来自于交互图中的消息(和业务对象模型)，分析阶段主要使用关联关系，也可根据业务模型引入泛化、聚合等关系 实例：绘制VOPC类图 -*- 实例：旅游申请系统实体类类图 -*- -*- -*- -*- GRASP模式 描述对象设计和职责分配的基本原则 General Res