第四章 类图建模（一）

目录

m1.类

m2.关系

m3.类图

m4.领域模型

m5.对象图

2.1 类

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

m名称

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

m属性

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

m操作

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

m对属性和操作的组织

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

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

Ø可以使用省略号

m职责

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

2.2 关系

  关系是事物之间的联系。   

m1.依赖（dependency）

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

m2.泛化（generalization）

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

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

m3.关联（association）

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

Ø名称

Ø角色

Ø重数

Ø聚合

2.3 类图及应用

m1.概念

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

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

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

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

m2.一般用法

Ø对基本结构建模

Ø对简单协作建模

Ø对逻辑数据库模式建模

m3.建模技术

Ø（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. 使用分类列表

•物理的或者实际的对象

•地点

•组织

m3. 确定名词短语

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

Ø业务对象

Ø真实世界中的对象

Ø事件

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

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

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

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对象图对包含在类图中的事物的实例建模，显示了在某一时间点上一组对象以及他们之间的关系。