第七章 类图
前言类图是在面向对象的系统模型中使用得最普遍的图。类图包含了一组类、接口和协作以及他们之间的关系。 你使用类图来为系统的静态视图建模。通常这包括模型化系统的词汇（从系统的词汇表中发现类），模型化协作，或则模型化模式。类图还是一些相关的图的基础，包括组件图、分布图。 类图的重要性不仅仅体现在为系统建立可视化的、文档化的结构模型，同样重要的是构建通过正向和反向工程建立执行系统。 术语和概念类图：类图是一组类、接口和协作以及他们之间的关系构成的。 类图通常包含如下的内容： 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）进行反向工程。 提示和技巧一个结构化好的类图： 焦点放在系统静态设计视图的一个方面 只包含为了理解该方面而应该存在的元素 提供足够的信息来理解该图 不让读者产生错误的信息 当你画类图的时候： 给它起一个名字，这个名字能表达类图的用途 用最少的交叉线来组织它的元素。 |
