利用UML类 建立系统结构模型

统一建模语言(UML)是用于系统建模的一种半形式化标准，该语言兼具严格性和灵活性特点，可以对系统的不同层面进行描述。本文以一个电源子系统为例，介绍了UML类的定义和对象之间的关系，以及通过类图对系统进行建模的方法。

统一建模语言(UML)是一种用于系统建模的半形式化标准。其十分严格的特点能满足可执行性要求，同时又具有灵活性，能实现对系统各个层面的描述。在最基本的情况下，UML能描述一个系统的结构模型及系统内部的协作行为，以及系统对象和系统组件的具体行为规范。

类与类图

类是指某组对象的低层结构和行为规范。类定义了对象的属性(数据元)和方法(成员函数)，类还可以通过状态图或活动图来说明其实例如何响应各类事件。

形象地说，如果一个类是“切饼机”，那么其对象便是“饼”。一个对象是某个类的实例，例如3.14159是浮点数类型的实例。一个特定类的所有对象具有相同的数据结构和行为，尽管它们的属性值可能互不相同。

当我们希望描述一个系统的某些结构特性时，通常会从它的通用特征开始，如系统各个组成部分在设计时的各种特性以及它们之间的相互关系，而不是运行时某一具体时刻的系统结构。因此，我们通常会把系统结构抽象成为多个相互关联的类，并且知道在运行中各时刻这些类的实例未必一定存在。如果我们希望获得系统在某一瞬间的状态，便需要采用对象。

图1所示为一个以电池和太阳能电池板构成的供电系统，该图是一个典型类图，图中小方框表示不同的类。“电源子系统”类代表一个子系统，该子系统是一个大的结构对象，它包含了提供子系统功能的小对象。PowerClient类和Knob类以“标准形式”显示，而Light类除了名字外，还显示了它的某些属性和方法，其属性为分类色彩和亮度，相应的枚举类型为COLOR_TYPE和整数(int)。在Light类的底部列出了获得可能返回值和参数的方法。DisplayThread是一个特殊的类，该类的实例在其自己的线程内运行。DisplayThread类包含了一个Light类的实例，它也在DisplayThread对象的线程中运行。

通常，一个系统的结构模型由一组类图构成，一些类图表示子系统的结构，其中主要单元是大的对象，例如子系统和部件，另一些类图集中描述任务结构，并以活动对象为主(但也可描述系统旗语和事件队列)。其余的类图描述类之间的协作结构，即对象是如何协同工作来实现系统级行为或模型构成，并主要描述各个模型包及其相互关系。上面这些类图都是描述同一系统结构的不同方面。

对象关系

对象只是系统的组成部分，它们必须与其它对象进行协作来实现系统功能，因此需要在对象之间建立链接(通常采用C或C++的指针)，以便调用服务或相互发送事件(event)。这在类图中表现为类之间的关联，在图1中示出了三个不同的关联，不带箭头的线表示常规关联。这些类之间的关联表示在运行过程中它们可能是实例对象之间的活动链接，并可在对象间调用服务。标有单向箭头的地方表示信息流只有一个方向。

线上的空心菱形(例如SolarPanel和PositionSensor类之间的菱形)表明一个聚集，它代表了一种整体与局部的关联形式。聚集的增强形式称为组合体，采用实心菱形(如电源子系统和SolarPanel之间)或将一个类嵌套在另一个类中(如电源子系统和电池之间)来表示。组合体是整体与局部的关联，但同时也表明整体类负责各部分对象的创建和解除。

对于各种关联还可以表示其多重性，即运行时可充当某一角色的类的实例数。例如，你会发现只有一个Knob对象与每个PowerClient对象关联。另一方面，每个电源子系统实例可与0个或多个(用*表示) SolarPanel实例关联。对于嵌套的符号，在部件类的左上角示出了部件的多重性。例如，电源子系统拥有两个电池对象。

除了关联之外，UML还定义了其它的类间关系。最常见的一个是“判定”，即“is-a”关系，例如PowerClient(广义的)和Light(具体的)间的关系(即Light是一种PowerClient)。从语义上来讲，“判定”确保Light类同样具有所有PowerClient类的属性、操作及关联。Light类可重新定义PowerClient类中定义的操作，同时也可定义新的属性和操作。例如，Light类与Knob类有关联，因为它的父类PowerClient中定义了这一关联。

此外，图中还定义了“正确性规则”约束，这是系统的类和关联中没有定义的系统语义。在本文例举的类图中，我们需要规定在同一时刻，只能是电池或太阳能电池板之一供电，而不能两者同时供电。约束是用来描述系统的非功能性特征(通常称为QoS,服务质量)，例如方法的最差及平均性能、功能等。

作者: Bruce Powel Douglass

Email: bpd@ilogix.com

I-Logix公司