第七章类图

前言

类图是在面向对象的系统模型中使用得最普遍的图。类图包含了一组类、接口和协作以及他们之间的关系。

你使用类图来为系统的静态视图建模。通常这包括模型化系统的词汇&＃xff08;从系统的词汇表中发现类&＃xff09;&＃xff0c;模型化协作&＃xff0c;或则模型化模式。类图还是一些相关的图的基础&＃xff0c;包括组件图、分布图。

类图的重要性不仅仅体现在为系统建立可视化的、文档化的结构模型&＃xff0c;同样重要的是构建通过正向和反向工程建立执行系统。

术语和概念

类图&＃xff1a;类图是一组类、接口和协作以及他们之间的关系构成的。

类图通常包含如下的内容&＃xff1a;

l 类

l 接口

l 协作

l 依赖关系、继承关系、关联关系

同其他的图一样&＃xff0c;类图也可以包含注解和限制。

类图中也可以包含包和子系统&＃xff0c;这两者用来将元素分组。有时后你也可以将类的实例放到类图中。

注&＃xff1a;组件图和分布图和类图类似&＃xff0c;虽然他们不包含类而是分别包含组件和节点。

你通常通过下面三种方式使用类图&＃xff1a;

1&＃xff0c;为系统词汇建模型

为系统的词汇建模实际上是从词汇表中发现类&＃xff0c;发现它的责任。

2&＃xff0c;模型化简单的协作

协作是指一些类、接口和其他的元素一起工作提供一些合作的行为&＃xff0c;这些行为不是简单地将元素加能得到的。例如&＃xff1a;当你为一个分布式的系统中的事务处理过程建模型时&＃xff0c;你不可能只通过一个类来明白事务是怎样进行的&＃xff0c;事实上这个过程的执行涉及到一系列的类的协同工作。使用类图来可视化这些类和他们的关系。

3&＃xff0c;模型化一个逻辑数据库模式

想象模式是概念上设计数据库的蓝图。在很多领域&＃xff0c;你将想保存持久性数据到关系数据库活面向对象的数据库。你可以用类图为这些数据库模式建立模型。

通用建模技术

没有类是单独存在的&＃xff0c;他们通常和别的类协作&＃xff0c;创造比单独工作更大的语义。因此&＃xff0c;除了捕获系统的词汇以外&＃xff0c;还要将注意力集中到这些类是如何在一起工作的。使用类图来表达这种协作。

l 确定你建模的机制。机制代表了部分你建模的系统的一些功能和行为&＃xff0c;这些功能和行为是一组类、接口和其他事物相互作用的结果。

l 对于每个机制&＃xff0c;确定类、接口和其他的参与这个协作的协作。同时确定这些事物之间的关系。

l 用场景来预排这些事物&＃xff0c;沿着这条路你将发现模型中忽略的部分和定义错误的部分。

l 确定用这些事物的内容来填充它们。对于类&＃xff0c;开始于获得一个责任&＃xff08;类的职责&＃xff09;&＃xff0c;然后&＃xff0c;将它转化为具体的属性和方法。

图 7-1 模型化简单的协作

图7-1是一个自治机器人的类图。这张的图焦点聚集那些让机器人在路上行走的机制对应的类上。你可以发现一个虚类Motor和两个从它派生出来的类&＃xff1a;SteeringMotor和MainMotor。这两个类都从它的父亲Motor继承了五个方法。这两个类又是另一个类Driver的一部分。类PathAgent和Driver有一个1对1的关系&＃xff0c;和CollisionSensor有1对n的关系。

在这个系统中其实还有很多其他的类&＃xff0c;但这张图的重点是放在那些将机器人移动的类上的。在其他的图中你可能也会看到这些类。通过将焦点放在不通的功能上&＃xff0c;可以获得从不通的角度对整个系统的认识&＃xff0c;最终达到认识整个系统。

很多系统都是有持久性数据的&＃xff0c;也就是说要将这些数据保存到数据库中以便下一次使用。通常你会使用关系型数据库或面向对象的数据库&＃xff0c;或其它类型的数据库来保存数据。UML很适合为逻辑数据库模式建模。

UML的类图是E-R图&＃xff08;为逻辑数据库建模的通用工具&＃xff09;的超集&＃xff0c;尽管E-R图的重点是数据&＃xff0c;类图的扩展允许模型化行为。在物理数据库中这些逻辑操作一半转化为触发器或存储过程。

确定那些状态比其生命周期要长的类。

创建一张包含这些类的图&＃xff0c;标记它们为持久性的。

详细定义它们的属性。

对于使得物理数据库设计复杂的模式如&＃xff1a;循环关系、1对1关系、N元关系&＃xff0c;考虑创建中间抽象来使得逻辑结构复杂。

详细定义这些类的操作&＃xff0c;特别是那些访问数据和涉及数据完整性的方法。

如果可能的话使用工具来将你的逻辑设计转化为物理设计。

图7-2 模式建模

建模是重要的&＃xff0c;但要记住的是对于开发组来说软件才是主要的产品&＃xff0c;而不是图。当然&＃xff0c;画图的主要目的是为了更好地理解系统&＃xff0c;预测什么时候可以提供什么样的软件来满足用户的需要。基于这个理由&＃xff0c;让你画的图对开发有指导意义是很重要的。

某些时候&＃xff0c;使用UML。你的模型并不能直接映射成为代码。例如&＃xff0c;如果你在使用活动图为一个商业过程建模&＃xff0c;很多活动实际上涉及人而不是计算机。

很多时候&＃xff0c;你创建的图形可以被映射成为代码。UML并不是专门为面向对象的语言设计的&＃xff0c;它支持多种语言&＃xff0c;但使用面向对象的语言会更直观些&＃xff0c;特别是类图的映射&＃xff0c;它的内容可以直接映射成为面向对象语言的内容。如&＃xff1a;C&＃xff0b;&＃xff0b;&＃xff0c;SMALLTALK、ADA、ObjectPascal、Eiffel和Forte。UML还支持如Visual Basic这样的面向对象的语言。

正向工程&＃xff1a;是从图到代码的过程。通过对某中特定语言的映射可以从UML的图得到该语言的代码。正向工程会丢失信息&＃xff0c;这是因为UML比任何一种程序语言的语义都丰富。这也正是为什么你需要UML模型的原因。结构特性、协作、交互等可以通过UML直观地表达出来&＃xff0c;使用代码就不是那么明显了。

对类图的正向工程&＃xff1a;

选择将图形映射到哪一种程序语言。

根据你选择的语言的语义&＃xff0c;你可能要对使用某写UML的特性加以限制。例如&＃xff1a;UML允许你使用多重继承&＃xff0c;而SmallTalk只允许一重继承。

使用标记值来指定比的目的语言。你可以在类级进行也可以在协作或包的层次上进行。

使用工具来对你的模型进行正向工程。

反向工程&＃xff1a;反向工程是从代码到模型的过程。

进行反向工程&＃xff1a;

确定将你的程序语言的代码反向成模型的规则。

使用工具&＃xff08;Rose C&＃43;&＃43; Analyzer&＃xff09;进行反向工程。