第七章 类图

 

前言

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

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

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

 

术语和概念

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

类图通常包含如下的内容：

l         类

l         接口

l         协作

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

同其他的图一样，类图也可以包含注解和限制。

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

 注：组件图和分布图和类图类似，虽然他们不包含类而是分别包含组件和节点。

你通常通过下面三种方式使用类图：

1，为系统词汇建模型

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

2，模型化简单的协作

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

3，模型化一个逻辑数据库模式

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

 

通用建模技术

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

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

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

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

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

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

 

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

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

　

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

 

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

 

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

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

         详细定义它们的属性。

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

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

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

 

图7-2 模式建模

　

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

 

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

 

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

 

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

 

对类图的正向工程：

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

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

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

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

 

    反向工程：反向工程是从代码到模型的过程。

进行反向工程：

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

         使用工具（Rose C++ Analyzer）进行反向工程。

 

提示和技巧

一个结构化好的类图：

         焦点放在系统静态设计视图的一个方面

         只包含为了理解该方面而应该存在的元素

         提供足够的信息来理解该图

         不让读者产生错误的信息

当你画类图的时候：

         给它起一个名字，这个名字能表达类图的用途

用最少的交叉线来组织它的元素。