200602271429302.html

软件工程的红包书

<P><FONT face=Verdana>不同属性具有不同可见性。常用的可见性有Public、Private和Protected三种,在U ML中分别表示为"+"、"-"和"#"。</FONT></P>
<P><FONT face=Verdana>类型表示该属性的种类。它可以是基本数据类型,例如整数、实数、布尔型等,也可 以是用户自定义的类型。一般它由所涉及的<a href="200602281700255.html" tppabs="http://www.itisedu.com/phrase/200602281700255.html" target="_new">程序设计语言</a>确定。</FONT></P>
<P><FONT face=Verdana>约束特性则是用户对该属性性质一个约束的说明。例如"{只读}"说明该属性是只读 属性。 类的操作(Operation)　该项可省略。操作用于修改、检索类的属性或执行某些动作 。</FONT></P>
<P><FONT face=Verdana>操作通常也被称为功能,但是它们被约束在类的内部,只能作用到该类的对象上。操作 名、返回类型和参数表组成操作界面。</FONT></P>
<P><FONT face=Verdana>UML规定操作的语法为: 可见性 操作名 (参数表) : 返回类型 {约束特性} 在图1中,"客户"类中有"取客户地址"操作,其中" +"表示该操作是公有操作,调用时 需要参数"客户名",参数类型为字符串,返回类型也为字符串。 类图描述了类和类之间的静态关系。定义了类之后,就可以定义类之间的各种关系了 。</FONT></P>
<P><FONT face=Verdana>(3) 关联关系 关联(Association)表示两个类之间存在某种语义上的联系。例如,一个人为一家公 司工作,一家公司有许多办公室。我们就认为人和公司、公司和办公室之间存在某种语义 上的联系。在分析设计的类图模型中,则在对应人类和公司类、公司类和办公室类之间建 立关联关系。</FONT></P>
<P><FONT face=Verdana>在图1中最上部存在一个"属于"/"签定"关联:每个"保险单"属于一个"客户",而"客户 "可以签定多个"保险单"。除了这个关联外,图1中还有另外两个关联,分别表示每个"保险 单"包含若干个"保险单上的项目",而每个"保险单上的项目"涉及单一的"保险类别"。 关联的方向　关联可以有方向,表示该关联单方向被使用。关联上加上箭头表示方向 ,在UML中称为导航(Navigability)。我们将只在一个方向上存在导航表示的关联,称作单 向关联 ( Uni-directional Association ),在两个方向上都有导航表示的关联,称作双 向关联 ( Bi-directional Association )。</FONT></P>
<P><FONT face=Verdana>图1中,"保险单"到"保险单上的项目"是单向 关联。UML规定,不带箭头的关联可以意味着未知、未确定或者该关联是双向关联三种选 择,因此,在图中应明确使用其中的一种选择。 关联的命名　既然关联可以是双向的,最复杂的命名方法是每个方向上给出一个名字 ,这样的关联有两个名字,可以用小黑三角表示名字的方向(见图1中最上部的"属于"/"签 定"关联)。为关联命名有几种方法,其原则是该命名是否有助于理解该模型。 角色　关联两头的类以某种角色参与关联。</FONT></P>
<P><FONT face=Verdana>例如图2中,"公司"以"雇主"的角色,"人 "以"雇员"的角色参与的"工作合同"关联。"雇主"和"雇员"称为角色名。如果在关联上没 有标出角色名,则隐含地用类的名称作为角色名。角色还具有多重性(Multiplicity),表 示可以有多少个对象参与该关联。在图2中,雇主(公司)可以雇佣(签工作合同)多个雇员 ,表示为"*"; 雇员只能与一家雇主签定工作合同,表示为"1"。</FONT></P>
<P><FONT face=Verdana>多重性表示参与对象的数 目的上下界限制。"*"代表0～∞,即一个客户可以没有保险单,也可以有任意多的保险单 。</FONT></P>
<P align=center><FONT face=Verdana><IMG src="2006327182849962.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/2006327182849962.jpg" border=0><IMG src="2006327182911531.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/2006327182911531.jpg" border=0><IMG src="2006327182918624.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/2006327182918624.jpg" border=0></FONT></P>
<P>&nbsp;</P>
<P><FONT face=Verdana>"1"是1..1的简写,即任何一个保险单仅来自于一个客户,可以用一个单个数字表示,也 可以用范围或者是数字和范围不连续的组合表示。&nbsp;&nbsp;&nbsp;&nbsp; 关联类　一个关联可能要记录一些信息,可以引入一个关联类来记录。</FONT></P>
<P><FONT face=Verdana>图3是在图2的 基础上引入了关联类。</FONT></P>
<P><FONT face=Verdana>关联类通过一根虚线与关联连接。</FONT></P>
<P><FONT face=Verdana>图4是实现上述目标的另外一种 方法,就是使雇用关系成为一个正式的类。&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT></P>
<P><FONT face=Verdana>聚集和组成　聚集(Aggregation)是一种特殊形式的关联。聚集表示类之间的关系是 整体与部分的关系。一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘,这是 聚集的一个例子。在需求分析中,"包含"、"组成"、"分为……部分"等经常设计成聚集关 系。聚集可以进一步划分成共享聚集(Shared Aggregation)和组成。</FONT></P>
<P><FONT face=Verdana>例如,课题组包含许 多成员,但是每个成员又可以是另一个课题组的成员,即部分可以参加多个整体,我们称之 为共享聚集。</FONT></P>
<P><FONT face=Verdana>另一种情况是整体拥有各部分,部分与整体共存,如整体不存在了,部分也会 随之消失,这称为组成(Composition)。例如,我们打开一个视窗口,它就由标题、外框和 显示区所组成。一旦消亡则各部分同时消失。在UML中,聚集表示为空心菱形,组成表示为 实心菱形。</FONT></P>
<P><FONT face=Verdana>需要注意的是,一些面向对象大师对聚集的定义并不一样。大家应注意其他面向对象 方法与UML中所定义的聚集的差别。</FONT></P>
<P><FONT face=Verdana>(4) 继承关系 人们将具有共同特性的元素抽象成类别,并通过增加其内涵而进一步分类。</FONT></P>
<P><FONT face=Verdana>例如,动 物可分为飞鸟和走兽,人可分为男人和女人。在面向对象方法中将前者称为一般元素、基 类元素或父元素,将后者称为特殊元素或子元素。继承(Generalization)定义了一般元素 和特殊元素之间的分类关系。在UML中,继承表示为一头为空心三角形的连线。如图1中, 将客户进一步分类成个体客户和团体客户,使用的就是继承关系。 在UML定义中对继承有三个要求:</FONT></P>
<P><FONT face=Verdana>*特殊元素应与一般元素完全一致,一般元素所具有的关联、属性和操作,特殊元素也 都隐含性地具有; *特殊元素还应包含额外信息;</FONT></P>
<P><FONT face=Verdana>*允许使用一般元素实例的地方,也应能使用特殊元素。</FONT></P>
<P><FONT face=Verdana>(5) 依赖关系 有两个元素X、Y,如果修改元素X的定义可能会引起对另一个元素Y的定义的修改,则 称元素Y依赖(Dependency)于元素X。在类中,依赖由各种原因引起,如:一个类向另一个类 发消息;一个类是另一个类的数据成员;一个类是另一个类的某个操作参数。如果一个类 的界面改变,它发出的任何消息可能不再合法。</FONT></P>
<P><FONT face=Verdana>(6) 类图的抽象层次和细化(Refinement)关系 需要注意的是,虽然在软件开发的不同阶段都使用类图,但这些类图表示了不同层次 的抽象。在需求分析阶段,类图是研究领域的概念;在设计阶段,类图描述类与类之间的接 口;而在实现阶段,类图描述软件系统中类的实现。按照Steve Cook和John Dianiels的观 点,类图分为三个层次。需要说明的是,这个观点同样也适合于其他任何模型,只是在类图 中显得更为突出。</FONT></P>
<P><FONT face=Verdana>概念层　概念层(Conceptual)类图描述应用领域中的概念。实现它们的类可以从这 些概念中得出,但两者并没有直接的映射关系。</FONT></P>
<P><FONT face=Verdana>事实上,一个<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200604181844195.html  \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon.  \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200604181844195.html'" tppabs="http://www.itisedu.com/phrase/200604181844195.html" target="_new">概念模型</a>应独立于实现它的 软件和<a href="200602281641255.html" tppabs="http://www.itisedu.com/phrase/200602281641255.html" target="_new">程序设计</a>语言。 说明层　说明层(Specification)类图描述软件的接口部分,而不是软件的实现部分 。</FONT></P>
<P><FONT face=Verdana>面向对象开发方法非常重视区别接口与实现之间的差异,但在实际应用中却常常忽略这 一差异。这主要是因为OO语言中类的概念将接口与实现合在了一起。大多数方法由于受 到语言的影响,也仿效了这一做法。现在这种情况正在发生变化。可以用一个类型(Type )描述一个接口,这个接口可能因为实现环境、运行特性或者用户的不同而具有多种实现 。</FONT></P>
<P><FONT face=Verdana>实现层　只有在实现层(Implementation)才真正有类的概念,并且揭示软件的实现部 分。这可能是大多数人最常用的类图,但在很多时候,说明层的类图更易于开发者之间的 相互理解和交流。 理解以上层次对于画类图和读懂类图都是至关重要的。但是由于各层次之间没有一 个清晰的界限,所以大多数建模者在画图时没能对其加以区分。画图时,要从一个清晰的 层次观念出发;而读图时,则要弄清它是根据哪种层次观念来绘制的。要正确地理解类图 ,首先应正确地理解上述三种层次。虽然将类图分成三个层次的观点并不是UML的组成部 分,但是它们对于建模或者评价模型非常有用。</FONT></P>