第四章 类图建模（一）

目录

m 1.类

m 2.关系

m 3.类图

m 4. 领域模型

m 5. 对象图

2.1 类

       类是对一组具有相同属性、操作、关系和语义的对象的描述。

m 名称

    每个类必须有一个区别于其他类的名称。

m 属性

       已命名的类的特性，描述了该特性的实例可以取值的范围。

m 操作

       是一个服务的实现，是对一个对象所做的事情的抽象，并且由这个类的所有对象共享。

m 对属性和操作的组织

Ø 可以有选择的仅显示部分属性和操作

Ø 可以在属性和操作前加构造型

Ø 可以使用省略号

m 职责

      是类的合约或责任。在较高的抽象层次上，这些响应的属性和操作正是要完成类的职责的特征。

2.2 关系

  关系是事物之间的联系。   

m 1. 依赖（ dependency ）

       是一种使用关系，说明一个事物使用另一个事物的信息和服务，反之未必。

m 2. 泛化（ generalization ）

       是一般事物（超类、父类）和该事物的特殊的种类（子类）之间的关系。

       也称为“is – a – kind - of”关系。

m 3. 关联（ association ）

       是一种结构关系，它指明一个事物的对象与另一个事物对象间的联系。

Ø 名称

Ø 角色

Ø 重数

Ø 聚合

2.3 类图及应用

m 1. 概念

      类图（class diagram）是显示一组类、接口、协作以及它们之间关系的图。

       从图形上看，就是点和弧的集合。

      普通特性：有名字，有内容

       内容：类；接口；依赖、泛化、关联关系

m 2. 一般用法

Ø 对基本结构建模

Ø 对简单协作建模

Ø 对逻辑数据库模式建模

m 3. 建模技术

Ø （ 1 ）对基本结构建模

A. 对系统词汇建模

(a)识别用户或实现者用于描述问题或解决方案的那些事物。

(b)对于每个抽象，识别一个职责集。

(c)  提供为实现每个类的职责所需的属性和操作。

B 对系统中的职责分布建模

(1)识别一组为了完成某些行为而紧密地协同工作的类。

(2)对上述每一个类识别出一组职责。

(3)整体上观察，重新分配职责，使抽象合理。

(4)考虑协作方式，重新分配职责，使协作均衡。

C 对非软件事物建模

(a)对抽象为类的事物建模

(b)可以用构造型详述新的事物

(c)如果建模事物是包含软件的硬件，可建模为结点。

D 对简单类型建模

(1)对抽象为类型或枚举的事物建模，可用构造型表示。

(2)若需要详述该类型的值域，可使用约束。

Ø （ 2 ）对简单协作建模

  A 识别建模的机制。

  B 对每种机制，识别参与协作的类、接口和其它协作，并识别事物之间的关系

  C 用场景排演这些事物。

  D 把元素和内容聚集在一起。

Ø （ 3 ）对逻辑数据库模式建模

UML类图是E-R图的超集

2.4 领域模型

m . 概念

       领域模型（domain model）是对领域内的概念或现实世界中对象的可视化表示。也称为概念模型、领域对象模型、分析对象模型。

       应用UML表示法，领域模型被描述为一组没有定义操作的类图。

       可以展示：

u 领域对象或概念类

u 概念类之间的联系

u 概念类的属性

m 领域模型被称为“可视化字典”

      因为它对领域词汇或概念进行了可视化和关联，还显示了概念类的抽象。

m 领域模型不是软件业务对象图

m 领域模型不是数据模型

m 什么是概念类

conceptualclass

，是思想、事物或

对象。有表示词语

或图形的符号，有

表示定义的内涵和

表示适用示例的外延。

m 动机：     降低与 OO 建模之间的表示差异

m 准则：如何创建领域模型

以当前所要设计的需求为界

Ø 寻找概念类

Ø 将其绘制为 UML 类图中的类

Ø 添加关联和属性。

m 准则：如何找到概念类

Ø 1. 重用和修改现有模型。

Ø 2. 使用分类列表

• 物理的或者实际的对象

• 地点

• 组织

m 3. 确定名词短语

   为了找到问题域中的公共词汇，可以考虑从需求文档中以及开发团队成员的知识中来找词汇。注意力要放在下列方面:

Ø 业务对象

Ø 真实世界中的对象

Ø 事件

概念类识别实例—仓储管理

      在一个仓储管理的系统中，我们将关注库存中的物品以及它们的存储位置

      在该系统中一个事件就是将货品放到仓库中。对于每一次运货，系统必须记住搬运的时间，谁接收了货品，什么货品，每一种的数量有多少

m 领域模型建模指南

Ø 采用概念类目录列表和从需求中采用名词识别法将所有的备选概念类列出

Ø 在那些需要将关系信息保存的地方添加关联

Ø 依据信息需求添加必要的属性

属性还是概念类

m 如果我们不是将概念类 X 仅仅看作是实际生活中的数字或者文字， X 就可能是概念类，而不是属性

m 在我们的生活中经常用相近的概念来表示同一件事情

对非现实世界建模

m 许多事物是人工的 , 也就是说 , 它们是被造出来的

m 为了对它们建模，我们需要更多的抽象

m 例如

Ø 电信 : Message, Connection, Port,Dialog, Route, Protocol

Ø 中间件 : Service, Transaction

说明性（或者描述性）概念类

m 为什么 ?

Ø 真实的世界 ¹ 软件世界

m 例子

Ø 在一个商店中 , 每一个商品都有价格 , 描述和其他属性

Ø 如果我们为每一个商品创建一个包含所有信息的对象

Ø 不必要的冗余

Ø 删除商品对象意味着丢失所有信息

描述性概念类实例

2.5 对象图

m 实例（ instance ）：是抽象的具体表现，可以对其施加一组操作，而且它可能有一组状态，用以存储操作的结果。

m 在很大程度和对象（ object ）同义。

m 名称与类型

m 属性与状态

m 其它特征

m 对象图实例

m 对象建模要求

Ø 1. 明确联系到一个特定的抽象

Ø 2. 有一个从问题域或解域词汇中提取的唯一的名称。

Ø

m 对象建模策略  

Ø 1. 显示实例所属的抽象的名称，除非它在语境中是明显的

Ø 2. 根据在语境中理解对象的需要，显示实例的构造型和状态

Ø 3. 当属性及其值列表很长时，按种类分组

小结

m 类是对一组具有相同属性、操作、关系和语义的对象的描述。

m 类之间是有联系的，主要有依赖、关联、泛化三种关系。

m 类图可以对系统词汇建模、对简单协作建模、对逻辑数据库建模。

m 领域模型是对现实世界对象的可视化表示，降低了与ＯＯ建模之间的表示差异。

m 对象图对包含在类图中的事物的实例建模，显示了在某一时间点上一组对象以及他们之间的关系。