（计算机应用技术专业论文）基于uml的软件系统建模研究.pdf

亘童窑适盔堂塑土受塞堡堂丝监塞 塑- l 墓一 摘要 厂 f 欺件系统的分析和设计是软件生命周期中最关键的环节，一个成功的软 件系统必然建立在良好的分析和设计基础之上。九十年代以来，面向对象已 经成为软件工程领域的主流技术。统一建模语言( u n i f i e dm o d e l i n gl a n g u a g e ， u m l ) 是种绘制软件蓝图的标准语言，适于对软件开发过程中所有重要的 分析、设计和实现决策进行详细描述。此外，u m l 作为一种可视化建模语言， 使用它的开发人员能够用图形清晰地描述系统体系结构及其所有细节，有利 于用户与开发人员之间的交流。现在，在美国等国家已有大量的软件开发组 织开始用u m l 进行系统建模，摹午u m l 的软件过程及其支持工具成为国内 外软件工程领域研究的热点。i ， u m l 仅是一种建模语言，而不是一种方法，没有规定在什么时候怎样使 用它们。本文区分了u m l 的三种建模机制，然后在此基础上探讨了如何应 用u m l 提供的元模型完成软件系统的分析和设计，最终产生一组描述系统 体系结构视图的模型。利用支持u m l 的c a s e 工具，开发人员可以方便的 建立各种u m l 模型。本文结合r a t i o n a l 工具提出了利用u m l 来改善软件过 程以及进行团队开发管理的方法。最后，本文在上述理论研究的基础上完成 了一个分布式物资管理系统的分析和设计，建立了该系统的业务模型、用况 模型、分析模型和设计模型。 采用u m l 进行系统建模已经成为面向对象分析和设计的一种趋势。但 是由于u m l 本身的复杂性以及我国软件产业发展的局限性，u m l 尚未在我 国软件企业得到充分的重视。本文从理论和实践方面对u m l 在软件系统建 模方面的应用进行了研究，所提出的观点对软件人员掌握面向对象建模技术 具有一定的参考价值。 e。 v 关键词统一建模语言：面向对象分析和设诽计算机辅助软件工程工具 面侗璺缈 一一 直室窑鎏盔堂塑主塑塞堡堂丝迨塞 簦! ! 要 。_ _ _ _ _ - _ _ 。_ - _ _ l _ _ _ _ _ - 。_ 。一一 a b s tr a c t s y s t e ma n a l y s i s a n dd e s i g ni st h em o s ti m p o r t a n tp a r to ft h es o f t w a r el i f e c y c l e as u c c e s s f u ls o f t w a r es y s t e m i sa l w a y sb a s e do ng o o da n a l y s i sa n dd e s i g n s i n c et h e19 9 0 s ，o b j e c t - o r i e n t e dt e c h n o l o g yh a sb e c o m e t h et e n d e n c yo fs o t t w a r e e n g i n e e r i n g t h e u n i f i e dm o d e l i n gl a n g u a g e ( u m l ) i st h ei n d u s t r y 。s t a n d a r d l a n g u a g et om a k eab l u e p r i n to fs o f t w a r e ，w h i c hi s s u i t a b l ef o rs p e c i f y i n ga l l d e c i s i o n so fa n a l y s i s ，d e s i g na n di m p l e m e n ti ns o f t w a r ed e v e l o p m e n tp r o c e s s b e s i d e s u m li st h ev i s u a l i z e dm o d e l i n gl a n g u a g e ，、i t l lw h i c hd e v e l o p e rc a n e x a c t l yd e s c r i b et h ea r c h i t e c t u r ea n dd e t a i l s o fs o f t w a r es y s t e mi nt h ef o r mo f d i a g r a m ，w h i c h w i l l p r o m o t e t h ec o m m u n i c a t i o nb e t w e e nc u s t o m e r sa n d d e v e l o p e r s t o d a yi nm a n yc o u n t r i e s ag r e a tn u m b e ro fs o f t w a r eo r g a n i z a t i o n s c h o o s eu m lt om o d e lv a r i o u ss y s t e m t h es o f t w a r ep r o c e s sa n dc o r r e l a t i n gt o o l b a s e do ni j m lh a v eb e c o m ef o c u si n t h ed o m a i no fi n t e m a t i o n a ls o f t w a r e e n g i n e e r i n g t h eu m li so n l yam o d e l i n gl a n g u a g e ，b u tn o tak i n do fm e t h o d ，w h i c h d o e s n ts h o ww h e na n dh o wt o u s ei t t h i s p a p e rd e s c r i b e s t h r e ed i f f e r e n t m o d e l i n gm e c h a n i s m sa n dd e p i c t sh o w t oa n a l y z ea n dd e s i g ns o r w a r es y s t e m w i t ht h eu m lm e t a m o d e l a sar e s u l t ，as e to f m o d e li sc o n s t r u c t e d a i lk i n d so f m o d e lc a nb ec o n v e n i e n t l yb u i l tw i t ht h et o o l ss u p p o r t i n gu m l w i t l lt o o l so f r a t i o n a l ，m e t h o d so fa p p l y i n gu m l t oi m p r o v es o f t w a r ep r o c e s sa n dm a n a g e g r o u p d e v e l o p m e n ta r ep r o v i d e di nt h i sp a p e r a tl a s t ，t h i sp a p e ri l l u s t r a t e st h e a n a l y s i sa n dd e s i g no f ad i s t r i b u t e dm a t e r i a lm a n a g e m e n ts y s t e m ，a n db u i l d si t s b u s i n e s sm o d e l ，u s ec a s em o d a l ，a n a l y s i sm o d e la n dd e s i g nm o d e l m o d e l i n gw i t hu m l h a sb e c o m eat r e n di no b j e c t - o r i e n t e d a n a l y s i sa n d d e s i g n b u tb e c a u s eo f t h ec o m p l e x i t yo ft h eu m la n dt h el i m i to fo u rc o u n t r y s o f t w a r ei n d u s t r y , m o s ts o f t w a r ee n t e r p r i s e sg i v ei td e f i c i e n ta t t e n t i o n 1 1 l i sp a p e r e m p h a s i z e st h er e s e a r c ha n di m p l e m e n t a t i o no f s o t b # a r es y s t e mm o d e l i n gb a s e d o n u m l ，w h i c hm a y b eh e i pd e v e l o p e r s m a s t e r o b j e c t - o r i e n t e dm o d e l i n g t e c h n o l o g y k e yw o r d s ：u m l ，o b j e c t - o r i e n t e da n a l y s i sa n dd e s i g n , c a s et o o l 第1 章绪论 1 1 软件工程技术的发展 随着计算机硬件性能的不断提高和价格的不断下降，计算机的应用领域 逐步扩大，人们对计算机应用领域的期望也不断增加。这使得计算机软件的 规模和复杂程度与日俱增，项目开发的风险也相应增大。从2 0 世纪6 0 年代 “软件危机”出现以来，人们一直在寻求更先进的软件技术来解决软件领域 出现的新问题。1 9 6 8 年提出的软件工程的概念是为了倡导以工程学的方法组 织软件的生产和管理。其提出者认为软件系统的开发是一项工程。必须经过 分析、设计、实现、测试、维护等一系列的软件生命周期阶段。 软件工程的发展大致经历了两个时期 8 l 。2 0 世纪6 0 年代末到8 0 年代初 是软件工程发展的第一个时期，在这个阶段，围绕软件项目开展了有关软件 生存期模型、支持工具与开发方法的研究，提出了软件开发的瀑布模型、结 构化设计方法和结构化程序设计语言( 如p a s c a l 和c 语言等) 。2 0 世纪8 0 年代以后进入软件工程发展的第二个时期，围绕软件工程过程开展了有关软 件生产技术，特别是软件复用技术和软件生产管理的研究和实践，提出了具 有广泛应用前景的面向对象方法和相关的语言，并大力开展了计算机辅助软 件工程( c a s e ) 的研究和发展。近几年来，软件工程的研究已经从过程管理 转向产品开发，更加注重新的程序开发模式和大规模开发环境的研究。目前， 高智能、高自动化的c a s e 成为软件工程技术研究的热点i ，l 。 1 2 面向对象方法 面向对象方法是一种运用对象、类、继承、封装、消息传送和多态性等 概念来构造系统的软件开发方法f 9 l 。它强调以对象的观点来分析现实世界中 的问题。在面向对象系统中，世界被看成是独立的对象的集合，对象之间通 过消息相互通信。对象将属性和行为封装在一起，对一个对象的访问完全通 过其外部接口来进行，内部的实现细节和数据结构对外是不可见。 面向对象方法首先在编程领域兴起，之后很快拓展到软件生存期的分析 亘壹窑适盔兰塑塑窒圭堂丝迨塞 蔓! 夏 和设计阶段。2 0 世纪8 0 年代初，由美国x e r o x 研究中心推出的s m a i i t a l k g o 语言首次全面的实现了面向对象的程序设计方法，之后又有一大批面向对象 的编程语言问世。此时，面向对象方法开始向系统设计阶段延伸，出现了一 批o o d 方法。但这些o o d 方法并不是以面向对象的分析( o o a ) 为基础的， 而是基于结构化分析。到八十年代末，面向对象方法的研究重点开始转向软 件生存期的分析阶段，并将o o a 和o o d 紧密地结合在一起，出现了一大批 面向对象的分析和设计方法( o o a & d ) 。截止1 9 9 4 年，公开发表并具有一 定影响的o o a & d 方法已达5 0 多种口】。经过实践的不断检验，其中一些优秀 的方法在软件开发中广为使用，其中最著名的有b o o c h 方法、j a c o b s o n 的 o o s e ( 面向对象的软件工程) 方法、c o a d y o u r d o n 方法以及r u m b a u g h 等 人的o m t 方法等。这些方法都提出了面向对象领域的新概念、新思想，同 时又各有优缺点。 2 0 世纪9 0 年代以来，面向对象的分析、测试、度量和管理等研究都得到 长足发展。可以说面向对象技术的研究和应用已经普及到计算机应用的各个 领域，包括面向对象的程序设计、面向对象的分析设计工具、面向对象的数 据库管理系统、面向对象的集成开发环境等等。目前面向对象技术的前沿课 题包括设计模式、分布式对象系统和基于网络的对象应用等l s l 。 1 3 软件系统建模 建模是一项经过检验并广为接受的工程技术f 2 j ，已应用于社会生活以及科 学研究中的众多领域，例如建筑业、机械制造业、经济学等等。之所以要对 待解决的问题建模，是因为人对复杂问题的理解能力有限，通过建模对现实 世界进行一定程度的抽象，可以简化所研究阿题的难度。特别是当我们对一 个大而复杂的系统建模时，可以采用“各个击破”的手段，将要解决的问题 分解为一系列小问题，即在建模过程中一次只注重研究它的一个方面，这样 解决了所有的小问题也就解决了整个问题。 软件开发的最终目的是得到满足用户要求、具备特定功能的软件。在当 今软件项目的复杂性和规模日益膨胀的情况下，要生产合格的软件就必须有 一套关于体系结构、过程和工具的规范。如果没有对体系结构、过程和工具 规范做任何考虑就毫无计划地着手实施软件开发，必然导致软件项目的失败。 另一方面，今天的社会是一个市场竞争异常激烈的社会，信息和科技手段曰 匿童窑适盎茎塑主丛窒生堂垡迨塞_ = 宴三兽二 新月异。作为向用户提供服务的软件系统，如果不能迅速推陈出新也必将惨 遭淘汰。所以一个成功的软件不仅要满足高效率、高质量和低成本的要求， 还要能对变幻莫测的外部环境快速、准确地做出反应，这就要求在软件开发 过程中打好能适应变化的体系结构基础。为此，我们必须借助建模活动来达 到上述目的。建模的目的就是把所要设计的结构和系统的行为沟通起来，并 对系统的体系结构进行可视化和控制口1 。对软件系统建模有助于理解正在构 造的系统，并在简化系统和软件复用方面提供很好的支持。最常用的软件建 模方法有两种：一是从算法的角度建模；二是从面向对象的角度建模。传统 的软件开发是从算法的角度建模，而现代软件开发大多从面向对象的角度建 模。 面向对象的建模语言出现于2 0 世纪7 0 年代中期，经过9 0 年代初的“方 法之争”，b o o e h 方法，c o a d y o u r d o n 方法，r u m b a u g h 等人的o m t 和j a c o b s o n 的o o s e 方法在面向对象软件开发界得到了广泛的认可。具体而言，b o o c h 方法在项目的设计和构造阶段的表达能力比较强，o o s e 对以用况作为一种 途径来驱动需求捕获、分析和高层设计提供了极好的支持，而o m t 适合于 分析和描述数据密集型信息系统。o l 这些面向对象方法的主导思想基本一致。 但表达形式存在较大的差异，给用户的选择带来一定的困惑。为了使面向对 象方法向一致的方向发展，g m d yb o o t h 、j a m e sr u m b a u 曲和i v a rj a c o b s o n 三位面向对象领域的著名专家联合创立了统一建模语言( u n i f i e dm o d e l i n g l a n g u a g e ，u m l ) 。u m l 一经出现便得到工业界和学术界的广泛支持，迅速 成为可视化建模语言事实上的工业标准。1 9 9 7 年1 1 月，o m g 采纳u m l l 1 作为基于面向对象技术的标准建模语言，现在u m l 的最新版本为2 0 。 在o m g 发布的白皮书中，u m l 的定义为：u m l 是一种用于对软件密集 型系统的制品进行可视化、详述、构造和文档化的可视化建模语言，主要适 用于软件开发的分析和设计阶段。其主要特点是表达能力丰富。u m l 既是 b o o e h 、o o s e 和o m t 三种方法的结合，又吸收了其它大量方法学家的思想。 可以说，u m l 对系统模型的表达能力超出了以往任何一种o o a & d 方法， 它的复杂性也比以往任何一种o o a & d 方法有过之而无不及。u m l 的出现， 最重要的意义在于它代表了一种积极的方向多种方法相互借鉴、相互融 合、趋于一致、走向标准化。而建模语言的标准化必将为软件开发商及其用 户带来诸多便利口”。 亘童銮适杰堂塑圭受塞生堂丝迨塞蔓! 夏一 1 4 本文的研究工作 u m l 是一种建模语言，而不是一种方法。在原理上，任何方法都是由建 模语言和建模过程两部分构成的。u m l 统一了面向对象建模的概念、术语及 其图形符号，用户可以根据所开发软件的类型、环境和条件，选用不同的软 件过程。基于u m l 的软件开发过程及其支持工具是本文研究工作的出发点。 首先，本文论述了在u m l 的三种建模机制中如何应用u m l 提供的元模型完 成软件系统的分析和设计。其次，本文结合r a t i o n a l 工具提出了在软件开发 组织中利用u m l 来改善软件过程以及进行团队开发管理的方法。最后，本 文在上述研究工作的基础上完成了一个分布式物资管理系统的分析和设计。 论文的主要内容分为以下几个部分： 第一章：绪论。概述论文的背景知识以及u m l 建模技术在国内外的研究 状况。 第二章：u m l 概述。首先简述了u m l 的概念模型，分析了u m l 扩展 机制和公共机制的特性。然后区分了u m l 的三种建模机制，论述了如何应 用u m l 提供的元模型完成软件系统的分析和设计。 第三章：基于u m l 的软件开发过程。比较了传统软件过程和r a t i o n a l 统一过程的区别，说明了如何将u m l 应用于迭代增最式的软件开发过程中， 达到改善软件过程的目的。 第四章：c a s e 工具支持。说明了以r a t i o n a lr o s e 为代表的c a s e 工具 对u m l 的支持，并提出了在软件组织中进行团队开发管理的方法。 第五章：分布式物资管理系统的分析。利用u m l 完成了一个分布式物资 管理系统的分析，建立了该系统的业务模型、用况模型和分析模型。 第六章：分布式物资管理系统的设计。年用u m l 完成了一个分布式物资 管理系统的设计，建立了该系统的设计模型、实现模型和实旌模型。 最后在结论部分，对本文所完成的工作进行了总结，并指出了需要完善 和改进的方面。 第2 章u m l 概述 2 1u m l 的体系结构 理解复杂系统的体系结构时，需要从不同的角度来考察系统。为此，在 u m l 中定义了“视图”的概念。视图是对系统模型在某方面的投影，注重于系 统的某个方面。如图2 1 所示，u m l 定义了5 个互补和连锁的视图：用况视 图、设计视图、进程视图、实现视图和实施视图。每种视图都可能有结构方 面和行为方面。这些视图结合起来从整体上描绘了软件的体系结构。其中， 用况视图用于揭示系统需求；设计视图用于捕获问题空间和解空间里的词汇； 进程视图对系统的进程和线程的分布建模；实现视图描述系统的物理实现； 实施视图着重于系统工程方面的组织。由图2 1 可知，u m l 的“4 + 1 ”视图 模型中用况视图居于中心位置，这体现了r a t i o n a l 统一过程用况驱动的特征。 图2 1u m l 体系结构【2 3 】 模型通常以图的形式给出，以便直观地反映建模内容。u m l 定义了九种 图：用况图、类图、对象图、顺序图、协作图、状态图、活动图、构件图和 实施图。其中，顺序圈和协作图统称为交互图，状态圈和活动图统称为状态 机图。这些图反映了在软件系统的建模中最常见的模型元素组合，但建模人 员并不限于这九种图，他们可根据需要创建适合特定项目的图。u m l 中的5 种视图正是由多个图混合和装配而成的，视图的静态方面和动态方面分别用 不同的图来描述。表2 1 给出了每种图在各视图中的作用。 亘壶窑追盔兰塑主受塞生兰垡坠塞蔓! 夏 表2 - 1u m l 中视图与图的关系 用况视图设计视图进程视图实现视图实施视图 静态方面用况图类图对象图构件图实施图 动态方面顺序图协作图状态图活动图 如表2 一l 所示，用于描述视图静态方面的五种图即u m l 的静态图，用于 描述视图动态方面的四种图则是u m l 的动态图。这里，尽管进程视图与设 计视图采用相同种类的图来描述，但进程视图包含的是强调进程和线程的类 图、对象图、交互图和状态机图。 2 2u m l 的概念模型 作为一种建模语言，u m l 的概念模型是由特定的词汇表和一组规则构成 的。与其他建模语言相比，u m l 中的词汇表和规则注重于对系统进行概念和 物理上的描述。在g b o o t h 、j r u m b a u g h 和i j a c o b s o n 三位专家的著作中 提到，u m l 建模包括三个主要要素：u m l 的基本构造块、支配这些构造块 组合在起的规则和一些运用于整个u m l 的公共机制1 2 j 。这三部分构成了 u m l 的概念模型。 2 2 1 u m l 的基本构造块 u m l 中的基本构造块包括事物、关系和图。事物是对模型中最具有代表 性的成分的抽象，关系将事物结合在一起，图聚集了相关的事物。图2 2 显 示了u m l 的简单结构图。u m l 中的九种图可以归纳为两类：一类是结构图， 用于描述系统的结构方面，包括类图、对象图、构件图和实施图；另一类是 行为图，用于描述系统的行为方面，包括用况图、顺序图、协作图、状态图 和活动图。五种行为图中包含两组语义上等价的图：一组是顺序图与协作图， 它们统称为交互图；另组是活动图与状态图，它们统称为状态机图。所谓 语义上等价，是指：者是对相同的事物建模，但观察角度不同。这意味着可 能将一种图转化为与之语义相同的另一种图而不丢失信息【3 】。支持u m l 的 图2 2u m l 的简单结构图 c a s e 工具提供两种图之间的自动转化功能。在对系统的动态行为建模时， 可以先创建说明消息次序的顺序图，然后将顺序图转化为协作图，以便开发 参与协作的对象类之间的关系。类似地，可以先用状态图说明由事件驱动的 系统响应，然后把它转化为注重于控制流的活动图 2 2 2u m l 规则和公共机制 2 2 2 1u m l 的通用规则 二全缝塑垦堑盟垡型廛这堇塑= 枣盟塑型壅丝堡夔型丕鲞：燮壅塑：基 亘童窑鋈盔堂塑主堑塞圭堂焦迨塞 筮! 夏 实地反映客观世界。u m l 中提供了如下规则：语义规则、一致性规则和简约 规则。语义规则指定了描述模型元素的方式，规定从命名、范围、可见性、 完整性和执行5 个方面来描述模型元素。一致性规则是指同一元素在系统模 型的不同图中应保持语义一致。简约规则是指在绘制模型图时可以隐藏某些 元素以简化图型，突出重点。例如，在绘制类图时并不需要显示类的所有属 性和操作，可以根据抽象层次的需要有选择的进行显示。同样，在状态图中 仅需显示类名或对象名以及关键的属性或操作。 在软件开发期内，随着系统细节的展开和变动不可避免地耍出现一些 不太规范的模型。u m l 的规则鼓励开发人员专注于最重要的分析、设计和实 现问题，这些问题将促使模型随着时间的推移而具有良好的结构。1 2 1 2 2 2 2u m l 的公共机制 u m l 中有四种贯穿整个语言且一致应用的公共机制，它们分别是：规格 说明、修饰、通用划分和扩展机制。 】规格说明u m l 的定义包括u m l 语义和u m l 表示法两部分。这可 以从两个方面来理解：一方面，对u m l 元模型中每个元素的定义都从规格 说明和表示图符两方面来说明。另一方面，用u m l 进行建模时，每一个模 型元素的图符背后都必须有一个规格说明，它提供了该模型元素的结构和行 为的全面描述。实际上，u m l 的规格说明包含了系统模型的所有部分，各部 分之间相互联系并保持一致；而每个图只是对规格说明的简单视觉投影，展 现了系统的一个特定方面。从系统开发的角度来讲，u m l 的图形表示用来对 系统进行可视化，u m l 的规格说明用来描述系统的细节。假定把二者分开， 就可能进行增量式的建模。这可以通过以下方式完成：先在图中绘制模型元 素，再对这个模型元素的规格说明增加语义，或者直接创建模型元素的规格 说明，然后通过正向工程生成可执行系统；也可以对个已经存在的系统进 行逆向工程，然后再创建这些规格说明的模型图。 2 修饰u m l 表示法中的每一个模型元素都有一个基本符号，可以将各 种修饰细节添加到这个符号上为相应的模型元素附加定的语义。例如类的 图形表示展示了类的最重要的方面，即它的名称、属性和操作。我们可以将 它是否是抽象类，或它的属性和操作的可见性等细节表示为图形或文字修饰， 放到类的基本矩形符号上。 3 通用划分在面向对象建模中，至少有两种划分法：一是类，对象的划 耍蜜窑鋈盔堂塑圭堑塞尘堂焦迨塞 蔓! 蔓 分，类是个抽象，对象是这个抽象的具体形式：二是按n 实现的划分，接 口声明一个契约，实现则负责该契约的具体实施。u m l 也不例外，在u m l 中既可以对类和对象建模，也可以对接口和实现建模。具体而言，u m l 中的 每个构造块几乎都存在像类对象这样的二分法。例如，用况和用况实例，构 件和构件实例、节点和节点实例等。同样，u m l 中的每个构造块几乎都存在 象接口实现这样的二分法。例如用况和实现它的协作以及操作和实现它的方 法。 4 扩展机制作为一种通用建模语言，u m l 允许用户以受控的方式扩展 其词汇和语义规则。u m l 的扩展机制包括三部分：构造型( s t e r e o t y p e ) 、标 记值( t a g g e d v al u e ) 和约束( c o n s t r a i n t ) 。 ( 1 ) 构造型有时也称之为铅版。构造型用于扩展u m l 的词汇，建模人 员利用它可以创造新的构造块。构造型化元素往往是在u m l 基本模型元素 的基础上加上一些限制，在建模时将它作为基本构造块对待。对于构造型化 元素，没有额外的图符表示，只是在基本模型元素的名字上加上带有尖括号 “”的关键字，例如图2 3 中的类“p e n t r a c k e r ”图符中的“( ( c o n t r 0 1 ) ) ”。 基于可视化的目的，构造型化元素也可以直接用图标表示，例如图2 3 中的 类“p e n t r a c k e r ”的图符。简而言之，构造型是非常重要的扩展机制，它的存 在既避免了u m l 语言过于复杂化，同时也使u m l 语言能够适应多种系统的 需求。 ( 2 ) 标记值有时也称之为标签。标记值用于扩展u m l 构造块的语义， 建模人员利用它可以创建详述模型元素的新信息。对标记值最典型的应用是 在软件的配置管理中跟踪产品的版本和作者。版本和作者并非u m l 的基本 概念，可以将这两个特性作为标记值加入任何构造块中，为u m l 构造块增 加了新的信息。例如图2 3 中的类“e v e n t q u e u e ”图符中的“ v e r s i o n = 2 2 a u t h o r = a n n ”。 ( 3 ) 约束约束用于限定u m l 构造块的语义，允许增加新的规则或修改 现有的规则。约束条件在u m l 图中表示为带有大括号“ ) ”的条件表达式， 直接连接到被约束对象上。为对象添加约束即可以用自然语言来描述，也可 以用对象约束语言( o b j e c t c o n s t r a i n tl a n g u a g e ，o c l ) 来描述。o c l 是一种 形式化语言，用表达式表示约束。现在o c l 已为o m o 接受，成为u m l 的 一部分。 总之，任何用户都可以根据项目的的特点用这3 种机制对u m l 进行扩展， 生成符合自己需要的系统模型。同时，扩展机制也使得u m l 适合于新的软 亘直窑鋈盔堂亟圭瑟壅生堂丝鎏塞 篁! ! 夏 o p e n n l c k e r 匝至蚤习劐姥岖画茧画习 e v e n t q n e u e v e r s i o n = 2 2 a u t h o r = a n n ) a d d o 。 r e m o v e ( ) a ) 构造型化元素b ) 标记值和约束 图2 3u m l 的扩展机制 件技术。此外，以受控的方式进行扩展可保证用户不至于偏离u m l 的真正 目的信息交流。埘 2 3u m l 的建模机制 从应用的角度看，当采用面向对象技术设计系统时，首先应建立系统的 逻辑模型，然后建立相应的物理模型。 建立系统逻辑模型的过程大致分为三步：第步描述需求，第二步根据 需求建立系统的静态结构，第三步是描述系统的行为。其中在第一步与第二 步中所建立的模型都是静态的，可用三种图来描述，既用况图、类图、对象 图，属于标准建模语言u m l 的结构建模机制。而第三步中所建立的模型或 者可以执行，或者表示执行时的时序状态或交互关系，可用四种图来描述， 既状态图、活动图、顺序图和协作图，屑于标准建模语言u m l 的行为建模 机制。 建立系统物理模型的过程大致分为两步：第步是描述代码部件的物理 结构及各部件之间的依赖关系，第二步是描述系统中软硬件的物理拓扑结构， 以及代码构件在各物理节点上的部署。这两个步骤与建立系统物理构架相关， 分别用构件图和实施图来描述，属于标准建模语言u m l 的物理体系结构建 模机制。因此，可以将u m l 的建模机制归纳为静态结构建模机制、动态行 为建模机制和物理体系结构建模三大类a 下面讨论这三类建模机制的具体内 容。 匿壹塞里盔堂缝圭塑壅竺堂丝垒塞 蔓! ! 要 2 3 1 对系统的静态结构建模 静态结构建模的着眼点在于对系统中的抽象实体及其职责建模，并描述 各实体间的结构关系。此外，静态结构建模还涉及到对系统的公共机制建模。 静态结构建模的高级应用则包括利用接口对系统的接缝建模和利用包图对系 统的体系结构建模等。u m l 中用于结构建模的图包括类图、对象图和包图， 涉及的主要概念包括类、接1 3 、对象、关联、泛化、依赖关系等。 2 3 1 1 对系统的词汇和职责建模 在面向对象系统的设计中通常用类对问题域中的抽象建模。可以采用 c r c 卡片和基于用况的分析技术帮助找到这些抽象，并对每个抽象识别一个 职责集，然后在精化模型时提供为实现类的职责所的属性和操作。 类很少单独存在，通常情况下一组类协同工作共同完成某个行为。通过 绘制类图可以反映一组紧密协作的类、接口之间的关系。当我们对大量的类 建模时，应确保职责在所有的类之间得到很好的均衡，这意味着不能让一个 类过大或过小，这也就是粒度控制的部分工作。在识别出一组协同工作的类 并为每个类识别出一组职责后，必须从整体上观察这组类，将职责过多的类 进行分解，而将职责过于琐碎的类进行合并，重新分配职责以使整个系统的 职责分布达到合理的均衡。利用类图可以直接观察到一个类与其他类关联的 紧密程度，有助于类职责的调整。 随着模型的不断增大，很多类将趋于簇集到一些在概念上和语义上相关 的组中，可以用包对这些类簇建模，通过绘制包图显示这些类的组织结构。 2 3 1 2 对抽象间的关系建模 在面向对象的建模中。最重要的三种关系是依赖、泛化和关联。依赖是 一种使用关系，例如，若一个类使用另一个类作为它的操作参数时，二者之 间就是依赖关系。另外，c + + 中类的友元关系可用带有构造型f r i e n d 的依 赖建模。从严格意义上讲，前面提到的实现关系也是一种依赖关系。泛化关 系用于指明父类与子类之间的继承关系。在建模过程中可能通过两种方式产 生泛化：一种是寻找一组类中共同的职责、属性和操作，将这些共同的职责、 耍查窑适盔堂塑圭塑塞生兰焦整壅：i ! ：譬害 属性和操作提升到更般的类中；另一种是由已有类定义新类，将新类作为 子类，继承已有类的属性和操作。此外，泛化关系也适用于包。关联是一种 结构关系，它描述了类的对象问相互作用的结构路径- 有三种应用于关联的 修饰；名称、角色和多重性。聚合是一种典型的关联关系r 它指明一种“整 体部分”关系。 依赖和泛化表示了两个类之间的单向关系，一个类依赖另一个类，被依 赖的类无须知道另一个类的任何信息。同样泛化关系中的予类继承父类的结 构特征和行为特征，而父类无须了解子类的特有信息。 与依赖和泛化关系不同，关联关系是对对等的两个或多个类建模。处于 关联两端的两个类在某些方面互相依赖，从关联的两边都可以导航。类在关 联中扮演的角色也就是它对关联另端的类所呈现的职责。关联的多重性是 一个取值范围或具体数值，它说明在关联另端的类的每个对象要求在本端 的类必须有多少个对象。 以上三种关系是定义在类级的关系。在对象级建模时，要用到另外两 种关系：链和转换。链是关联的实例：转化是状态机中不同状态之间的连接。 2 ，3 1 3 对系统中的接缝建模 类是构成软件系统结构模型的基本构造块，一组类通过相互协作实现用 况。所谓系统接缝，是指那些紧密协作、倾向于高耦合的类或构件集自然形 成个边界，对外提供一定的服务并且趋于一起变化。在u m l 中，用接口 对系统中的接缝建模。其含义是：从一个类或构件集的实例到其他类或构件 集实例的操作和信号是跨越边界的。通常情况下，将那些在逻辑上相关的操 作和信号的集合打包为接口。这种做法有两个好处：一方面，通过选择正确 的接口，开发人员能够选取标准的构件、库和框架来实现这些接口，不必从 头创建这些构件，缩短了开发周期；另一方面，在系统维护时用新的实现代 替旧的实现时，只要接口保持不变就不会影响用户。 接口包括对一组公共可见的操作的规格说明，它不包括属性和实现操作 的方法。实际上，接口与没有属性、方法只有抽象操作的抽象类等价。接口 的操作列表还可以包括类准各处理的信号。接口很少单独存在。而是依附于 实现接口的类或构件，用于说明类或构件的一个服务的操作集。接口定义了 类或构件提供的服务，它定义的服务由类或构件实现。因此，接口跨过了系 统的逻辑和物理的界限。一个或多个类可以提供接口的逻辑实现，而一个或 一 亘壶窑垄杰堂塑圭塑塞生堂垡迨塞 复! i 蒌 多个构件可以提供符合同一接口的物理包h a 抉个角厦讲，如果芡买现j 一 个或多个接口，它必须声明所有接口的操作。接口与实现它的类或构件之间 构成实现关系。此外，接口还可以参与泛化、关联和依赖关系。 在建模过程中，应对系统中每个类或构件的协作，识别它所依赖的接 口和它提供给其他协作的接口。用依赖关系对接口的引入建模，用实现关系 对接口的示出建模。 2 3 1 4 对机制和框架建模 软件系统的设计不仅应对当前处理的问题有针对性，还要对将来的问题 和需求也有足够的通用性。一个软件系统能否适应业务的发展和需求的变化， 是决定其生命力的关键因素。为此，在软件复用领域，提出了模式的概念。 模式为特定语境中的共同问题提供了通用解决方案。所有结构良好的面向对 象软件体系结构都包含了许多模式。 使用u m l 建模，开发人员可以用模式来详细说明形成系统体系结构的机 制和框架。机制是应用于一组类的群体的设计模式，框架则是对一个领域中 的应用系统提供可扩充模板的体系结构模式。开发人员在设计过程中，既可 以复用已有的专家设计模式，也可以沿袭自己在前期工作中发掘的模式，将 设计工作建立在以往工作的基础上。在文献【5 1 中提到的3 类2 3 种设计模式 对大部分面向对象系统设计中遇到的问题提供了种灵活的解决方案。 总之，设计模式使开发人员更加简单地复用以往成功的设计和体系结构， 能够避免重复设计或尽可能少做重复设计，有助于设计出更加灵活的、模块 化的、可复用和易理解的软件【5 】。当前，设计模式正成为软件复用技术领域 的研究热点。同时，分析模式方面的研究也受到人们的格外关注。此外，在 应用面向对象技术设计系统时，新手面对众多选择无从下手，总是求助于以 前的非面向对象技术，通过学习设计模式并应用它来解决面临的问题无疑是 一个好的开始点。 2 3 2 对系统的动态行为建模 动态行为建模的着眼点在于对系统的需求建模，并描述了系统的控制流 和工作流。行为建模的高级应用则包括对进程间通信、多控制流以及移动对 叁蕉堡笠：旦m 垦虫旦王堑垫蕉送盟国垡堑旦鎏图：! 亟度圈：垃堡圈：适塾垦 2 3 2 1 对系统的语境和需求建模 对系统的语境建模是对系统的需求建模的很好的开始点1 2 ”。所谓系统的 语境是指系统存在的环境，所有存在于系统外部并与系统进行交互的事物构 成系统的语境。在u m l 中，用用况图对系统的语境建模，它将与系统交互 的实体定义为系统的参与者。参与者既可能是实际的用户，也可能是其他的 软件系统或硬件设备。用况从用户角度描述系统将要实现的行为，而不涉及 实现用况的任何细节，为最终用户、领域专家与各级开发人员提供了一致的 交流场所。参与者通过关联与用况连接，表示二者之间的通信。 对系统的需求建模时，首先要通过识别系统周围的参与者建立系统的语 境。然后对每个参与者，考虑它期望系统提供的行为，提取其中的公共行为 分别命名为用况。在此基础上可以利用泛化、包含和延伸关系产生新的用况， 最后在多个用况图中组织这些用况、参与者以及它们之间的关系。另外，每 一个用况都包括一个主事件流和若干异常事件流。一个用况实质上描述了一 组行为序列，每个序列被称作一个脚本，代表一个可能的事件流。如果说用 况是一个类元，一个脚本就是一个用况的实例。必要时可以把交互或状态机 附加在用况上，对该用况特定的控制流建模。 2 3 2 2 对系统中的控制流建模 控制流即包括系统中简单的、顺序的线程，也包括分支、循环、递归 和并发等复杂的控制流。对一个系统、操作、类或者用况脚本的动态行为进 行可视化建模可以使用交互图。其中，顺序图适用于对简单的迭代和分支建 模，而协作图适用于对复杂的迭代和分支以及多并发控制流建模。对控制流 建模，首先要设景交互的语境，可能是系统、子系统、操作、类、用况或者 协作的脚本；其次通过识别对象在交互中扮演的角色，设置交互的场景。如 果使用顺序图，要将对象顺序排放在图的上方，并为每个对象设置生命线， 然后从引发交互的消息开始，在生命线之间从上至下依次画出该行为序列中 的消息，不必对消息进行编号。如果使用协作图，要将对象作为顶点放在图 中，较重要的对象放在图的中央，画出关联对象之间存在的链，将消息附到 相应的链上，并按消息发生的次序进行编号。最后可为消息附上时间和空间 亘虚窑湮盔堂塑塑窒塞兰垡熊塞 蔓! j 夏， 约束以及前置条件和后置条件来迸一步形式化地说明该控制流- 现实世界中的系统往往是并发系统，存在多个控制流，也就是说在同 一时间有多个事件发生。在u m l 中，将每一个独立的控制流程建模为主动 对象，代表个能够启动控制活动的进程或线程。这也就是在系统的进程视 图中必须考虑的系统的并发和同步机制，包括对多控制流建模和对进程间通 信建模。进程通信有两种方式：消息传送和远程过程调用。一般而言，用异 步通信对消息建模，用同步通信对远程过程调用建模。另外，在并发系统中 开发人员面对的一个典型闯题是互斥。多个控制流可能在同一时间通过同一 对象，这时存在两种可能的情况：在该对象的同操作中有多个控制流；或 者在该对象的不同操作中有不同的控制流。在多个控制流存在的情况下，任 何个流都可能与另一个流产生资源竞争或其他方面的冲突，对该问题处理 不当是导致并发系统失败的最常见的原因。解决该问题的关键是把目标对象 作为一个l 临界区。在u m l 中定义了三种方法来保证对象的语义和完整性， 具体建模时可以为类中的操作定义三种同步特性：顺序、监护和并发。顺序 是指操作的调用者必须在对象外部进行协调保证在每时刻对象中仅有一个 控制流。监护是指利用监护条件将对操作的所有调用进行顺序化，从而保证 同时刻只有一个操作能被调用。并发是指当多个控制流出现时，将操作当 作原予处理来保证对象的语义和完整性。 2 3 2 3 对工作流建模 工作流通常是业务过程。在对业务过程的工作流建模时，首先选择工作 流中的有高层职责的业务对象，为每个重要的业务对象建立一个泳道，一般 来讲现实中映射到每个泳道的业务组织是独立的和并发的。其次通过识别该 工作流初始状态的前置条件和停止状态的后置条件明确该工作流的边界。然 后从初始状态开始依次标识出重要的动作状态和活动状态以及它们之间的转 换，对于那些复杂的动作或重复出现的动作集合可归并到一个活动状态，并 对每个这样的活动状态提供可展开的子活动图。对业务过程的工作流建模时， 通常会遇到并发控制流，可用同步棒来说明这些并行控制流的分叉和汇合。 一个分叉可以有一个进入转换和多个离去转化，每个转换表示一个独立的控 制流，位于并发控制流中的活动可能通过发送信号进行通信。与之相反，一 个汇合表示多个进入转换和一个离去转换，在汇合处并发流取得同步。在一 个状态机中的汇合和交叉应是平衡的。此外，可以用活动图说明软件开发过 亘直至鋈盔堂堡主受壅皇堂丝迨塞 蔓! ! 夏 程，例如用于配置管理的过程；还可以将活动图附加到一个操作，描述其中 的算法，相当于一个流程图。 对系统的行为建模是软件系统分析和设计中最重要的环节。通过行为建 模可以清晰的理解系统的需求以及验证和修