SoftEng 版 (精华区)

发信人: alai (alai), 信区: SoftEng
标  题: 标准建模语言UML的静态建模机制(四)
发信站: 紫 丁 香 (Sat Apr  8 04:24:10 2000), 转信

(接上期)
(6) 类图的抽象层次和细化(Refinement)关系
    需要注意的是,虽然在软件开发的不同阶段都使用类图,但这些类图表示了不同层次的
抽象。在需求分析阶段,类图是研究领域的概念;在设计阶段,类图描述类与类之间的接口;
而在实现阶段,类图描述软件系统中类的实现。按照Steve Cook和John Dianiels的观点
,类图分为三个层次。需要说明的是,这个观点同样也适合于其他任何模型,只是在类图中显
得更为突出。

概念层　概念层(Conceptual)类图描述应用领域中的概念。实现它们的类可以从这些概念
        中得出,但两者并没有直接的映射关系。事实上,一个概念模型应独立于实现它的
        软件和程序设计语言。
说明层　说明层(Specification)类图描述软件的接口部分,而不是软件的实现部分。面向
        对象开发方法非常重视区别接口与实现之间的差异,但在实际应用中却常常忽略这
        一差异。这主要是因为OO语言中类的概念将接口与实现合在了一起。大多数方法
        由于受到语言的影响,也仿效了这一做法。现在这种情况正在发生变化。可以用一
        个类型(Type )描述一个接口,这个接口可能因为实现环境、运行特性或者用户的
        不同而具有多种实现。
实现层　只有在实现层(Implementation)才真正有类的概念,并且揭示软件的实现部分。这
        可能是大多数人最常用的类图,但在很多时候,说明层的类图更易于开发者之间的
        相互理解和交流。

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

下面介绍细化概念。

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

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

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

(9) 包
    一个最古老的软件方法问题是:怎样将大系统拆分成小系统。解决这个问题的一个思路
是将许多类集合成一个更高层次的单位,形成一个高内聚、低耦合的类的集合。这个思路被
松散地应用到许多对象技术中。UML中这种分组机制叫包(Package)
    不仅是类,任何模型元素都运用包的机制。如果没有任何启发性原则来指导类的分组,
分组方法就是任意的。在UML中,最有用的和强调最多的启发性原则就是依赖。包图主要显
示类的包以及这些包之间的依赖关系。有时还显示包和包之间的继承关系和组成关系。

包的内容　包的内容可以是类的列表,也可以是另一个包图,还可以是一个类图。
          当不需要显示包的内容时,包的名字放入主方框内,否则包的名字放入左上角的
          小方框中,而将内容放入主方框内。
包的依赖和继承　可以使用继承中通用和特例的概念来说明通用包和专用包之间的关系。
                例如,专用包必须符合通用包的界面,与类继承关系类似。通过"数据库界
                面"包,"系统内部"包既能够使用Oracle的界面也可使用Sybase的界面。
                通用包可标记为{abs tract},表示该包只是定义了一个界面,具体实现则
                由专用包来完成。
(10) 其他模型元素和表示机制
    类图中用到的模型元素和表示机制较为丰富,由于篇幅的限制,这里不能一一介绍。主
要还有以下模型符号和概念:类别模板(Stereotype)、界面(Interface)、参数化类(P 
arameterized Class)也称模板类(Template)、限定关联(Qualified Association)、多维
关联(N-ary Association)、多维链(N-ary Link)、派生(Derived)、类型(Type)和注释
(Note)等。

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





 

 

 

--
※ 来源:．紫 丁 香 bbs.hit.edu.cn．[FROM: 202.118.224.232]