uml3.htm

质量高！好东西！值得一看！

height="188"></p>

<p align="left">聚集和组成　聚集(Aggregation)是一种特殊形式的关联。聚集表示类之间的关系是整体与部分的关系。一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘,这是聚集的一个例子。在需求分析中,&quot;包含&quot;、&quot;组成&quot;、&quot;分为……部分&quot;等经常设计成聚集关系。聚集可以进一步划分成共享聚集(Shared
Aggregation)和组成。例如,课题组包含许多成员,但是每个成员又可以是另一个课题组的成员,即部分可以参加多个整体,我们称之为共享聚集。另一种情况是整体拥有各部分,部分与整体共存,如整体不存在了,部分也会随之消失,这称为组成(Composition)。例如,我们打开一个视窗口,它就由标题、外框和显示区所组成。一旦消亡则各部分同时消失。在UML中,聚集表示为空心菱形,组成表示为实心菱形。需要注意的是,一些面向对象大师对聚集的定义并不一样。大家应注意其他面向对象方法与UML中所定义的聚集的差别。</p>

<p align="left"><br>
(4) 继承关系<br>
人们将具有共同特性的元素抽象成类别,并通过增加其内涵而进一步分类。例如,动物可分为飞鸟和走兽,人可分为男人和女人。在面向对象方法中将前者称为一般元素、基类元素或父元素,将后者称为特殊元素或子元素。继承(Generalization)定义了一般元素和特殊元素之间的分类关系。在UML中,继承表示为一头为空心三角形的连线。<br>
如图1中,将客户进一步分类成个体客户和团体客户,使用的就是继承关系。<br>
在UML定义中对继承有三个要求:<br>
*特殊元素应与一般元素完全一致,一般元素所具有的关联、属性和操作,特殊元素也都隐含性地具有;</p>

<p align="left">*特殊元素还应包含额外信息;<br>
*允许使用一般元素实例的地方,也应能使用特殊元素。</p>

<p align="left"><br>
(5) 依赖关系<br>
有两个元素X、Y,如果修改元素X的定义可能会引起对另一个元素Y的定义的修改,则称元素Y依赖(Dependency)于元素X。在类中,依赖由各种原因引起,如:一个类向另一个类发消息;一个类是另一个类的数据成员;一个类是另一个类的某个操作参数。如果一个类的界面改变,它发出的任何消息可能不再合法。</p>

<p align="left"><br>
(6) 类图的抽象层次和细化(Refinement)关系<br>
需要注意的是,虽然在软件开发的不同阶段都使用类图,但这些类图表示了不同层次的抽象。在需求分析阶段,类图是研究领域的概念;在设计阶段,类图描述类与类之间的接口;而在实现阶段,类图描述软件系统中类的实现。按照Steve
Cook和John Dianiels的观点,类图分为三个层次。需要说明的是,这个观点同样也适合于其他任何模型,只是在类图中显得更为突出。<br>
概念层　概念层(Conceptual)类图描述应用领域中的概念。实现它们的类可以从这些概念中得出,但两者并没有直接的映射关系。事实上,一个概念模型应独立于实现它的软件和程序设计语言。<br>
说明层　说明层(Specification)类图描述软件的接口部分,而不是软件的实现部分。面向对象开发方法非常重视区别接口与实现之间的差异,但在实际应用中却常常忽略这一差异。这主要是因为OO语言中类的概念将接口与实现合在了一起。大多数方法由于受到语言的影响,也仿效了这一做法。现在这种情况正在发生变化。可以用一个类型(Type
)描述一个接口,这个接口可能因为实现环境、运行特性或者用户的不同而具有多种实现。<br>
实现层　只有在实现层(Implementation)才真正有类的概念,并且揭示软件的实现部分。这可能是大多数人最常用的类图,但在很多时候,说明层的类图更易于开发者之间的相互理解和交流。</p>

<p align="left"><br>
理解以上层次对于画类图和读懂类图都是至关重要的。但是由于各层次之间没有一个清晰的界限,所以大多数建模者在画图时没能对其加以区分。画图时,要从一个清晰的层次观念出发;而读图时,则要弄清它是根据哪种层次观念来绘制的。要正确地理解类图,首先应正确地理解上述三种层次。虽然将类图分成三个层次的观点并不是UML的组成部分,但是它们对于建模或者评价模型非常有用。尽管迄今为止人们似乎更强调实现层类图,但这三个层次都可应用于UML,而且实际上另外两个层次的类图更有用。</p>

<p align="left"><br>
下面介绍细化概念。细化是UML中的术语,表示对事物更详细一层的描述。两个元素A、B描述同一件事物,它们的区别是抽象层次不同,若元素B是在元素A的基础上的更详细的描述,则称元素B细化了元素A,或称元素A细化成元素B。细化的图形表示为由元素B指向元素A的、一头为空心三角的虚线(千万不要把方向颠倒了!)。细化主要用于模型之间的合作,表示开发各阶段不同层次抽象模型的相关性,常用于跟踪模型的演变。</p>

<p align="left"><br>
(7) 约束<br>
在UML中,可以用约束(Constraint)表示规则。约束是放在括号&quot;{}&quot;中的一个表达式,表示一个永真的逻辑陈述。在程序设计语言中,约束可以由断言(Assertion)来实现。</p>

<p align="left"><br>
(8) 对象图、对象和链<br>
UML中对象图与类图具有相同的表示形式。对象图可以看作是类图的一个实例。对象是类的实例;对象之间的链(Link)是类之间的关联的实例。对象与类的图形表示相似,均为划分成两个格子的长方形(下面的格子可省略)。上面的格子是对象名,对象名下有下划线;下面的格子记录属性值。链的图形表示与关联相似。对象图常用于表示复杂的类图的一个实例。<br>
</p>

<p align="left">(9) 包<br>
一个最古老的软件方法问题是:怎样将大系统拆分成小系统。解决这个问题的一个思路是将许多类集合成一个更高层次的单位,形成一个高内聚、低耦合的类的集合。这个思路被松散地应用到许多对象技术中。UML中这种分组机制叫包(Package)(见图5)。</p>

<p align="center"><img src="../images/uml3-5.jpg" width="267"
height="279"></p>

<p align="left">不仅是类,任何模型元素都运用包的机制。如果没有任何启发性原则来指导类的分组,分组方法就是任意的。在UML中,最有用的和强调最多的启发性原则就是依赖。包图主要显示类的包以及这些包之间的依赖关系。有时还显示包和包之间的继承关系和组成关系。<br>
包的内容　在图5中,&quot;系统内部&quot;包由&quot;保险单&quot;包和&quot;客户&quot;包组成。这里称&quot;保险单&quot;包和&quot;客户&quot;包为&quot;系统内部&quot;包的内容。当不需要显示包的内容时,包的名字放入主方框内,否则包的名字放入左上角的小方框中,而将内容放入主方框内。包的内容可以是类的列表,也可以是另一个包图,还可以是一个类图。<br>
包的依赖和继承　图5中&quot;保险单填写界面&quot;包依赖于&quot;保险单&quot;包;整个&quot;系统内部&quot;包依赖于&quot;数据库界面&quot;包。可以使用继承中通用和特例的概念来说明通用包和专用包之间的关系。例如,专用包必须符合通用包的界面,与类继承关系类似。通过&quot;数据库界面&quot;包,&quot;系统内部&quot;包既能够使用Oracle的界面也可使用Sybase的界面。通用包可标记为{abs
tract},表示该包只是定义了一个界面,具体实现则由专用包来完成。</p>

<p align="left"><br>
(10) 其他模型元素和表示机制<br>
类图中用到的模型元素和表示机制较为丰富,由于篇幅的限制,这里不能一一介绍。主要还有以下模型符号和概念:类别模板(Stereotype)、界面(Interface)、参数化类(P
arameterized Class)也称模板类(Template)、限定关联(Qualified
Association)、多维关联(N-ary Association)、多维链(N-ary
Link)、派生(Derived)、类型(Type)和注释(Note)等。</p>

<p align="left"><br>
(11) 使用类图的几个建议<br>
类图几乎是所有OO方法的支柱。采用标准建模语言UML进行建模时,必须对UML类图引入的各种要素有清晰的理解。以下对使用类图进行建模提出几点建议:<br>
*不要试图使用所有的符号。从简单的开始,例如,类、关联、属性和继承等概念。在UML中,有些符号仅用于特殊的场合和方法中,只有当需要时才去使用。<br>
*根据项目开发的不同阶段,用正确的观点来画类图。如果处于分析阶段,应画概念层类图;当开始着手软件设计时,应画说明层类图;当考察某个特定的实现技术时,则应画实现层类图。<br>
*不要为每个事物都画一个模型,应该把精力放在关键的领域。最好只画几张较为关键的图,经常使用并不断更新修改。使用类图的最大危险是过早地陷入实现细节。为了避免这一危险,应该将重点放在概念层和说明层。如果已经遇到了一些麻烦,可以从以下几个方面来反思你的模型。<br>
*模型是否真实地反映了研究领域的实际。<br>
*模型和模型中的元素是否有清楚的目的和职责(在面向对象方法中,系统功能最终是分配到每个类的操作上实现的,这个机制叫职责分配)。<br>
*模型和模型元素的大小是否适中。过于复杂的模型和模型元素是很难生存的,应将其分解成几个相互合作的部分。</p>

<p align="left"><br>
(12) 术语比较<br>
下表列出了最常用的四种UML术语,并与其他方法学中相对应的术语进行比较,以帮助读者了解UML与其他建模语言的异同。(未完待续)</p>

<p align="center"><img src="../images/uml3-6.jpg" width="578"
height="210"><br>
</p>

<p align="center"><a href="../index.htm">Home</a></p>
</body>
</html>