（计算机软件与理论专业论文）集成uml和com技术构建webbased应用系统.pdf

abs t rac t abs tract wi t h t h e f a s t d e v e l o p m e n t o f i n t e rn e t l l n t r a n e t , w e b - b a s e d a p p l i c a t i o n s a r e b e i n g u s e d m o r e w i d e l y , b e c o m i n g m o r e c o m p l e x , a n d m o r e d i ff i c u lt t o m a i n t a i n . i t h a s b e e n a n u r g e n t p r o b l e m t o m a n a g e t h e c o m p l e x i t y o f t h e s y s t e m t o a v o i d d i s o r d e r s t a t e . mo d e l i n g f o r w e b - b a s e d a p p l i c a t i o n s m i g h t s o l v e t h i s p r o b l e m. a n u m b e r o f m a t u r e t h e o r i e s a n d t e c h n o l o g i e s , s u c h a s w i n d o w d n a a r c h i t e c t u r e , c o m a n d r e l a t i o n a l d a t a b a s e , h a v e b e e n w i d e l y u s e d i n w e b d e v e l o p m e n t i n o r d e r t o b u i l d r o b u s t , e a s i l y - m a i n t a i n e d w e b - b a s e d a p p l i c a t i o n s . h o w e v e r , a t p r e s e n t , t h e g a p s e x i s t b e t w e e n t h e a n a l y s i s a n d d e s i g n o f t h e s e t e c h n o l o g i e s a n d t h a t o f t h e w h o l e s y s t e m ; f u r t h e r m o r e t h e y a r e n o t e x p r e s s e d i n t h e u n i q u e w a y s . s o i t m a k e s s e n s e t o f i n d a m e t h o d w h i c h c a n i n t e g r a t e s a l l t e c h n o l o g i e s i n t o t h e a n a l y s i s a n d d e s i g n o f t h e w h o l e s y s t e m , f i r s t l y , wi n d o w s d n a , u m l a n d i t s e x t e n s i o n m e c h a n i s m s ， a n d c o m t e c h n i q u e a r e i n t r o d u c e d . t h e n , a d e v e l o p m e n t m e th o d a b o u t w e b a p p l i c a t io n i s p r o p o s e d w h ic h i n t e g r a te s c o m o b j e c t d e s ig n a n d d a t a b a s e d e s i g n i n t o o v e r a l l s y s t e m d e s i g n . t h e m e t h o d i n c l u d e s f o l l o w i n g a s p e c t s : e x t e n d i n g u m l t o m o d e l w e b a p p l i c a t i o n , u s i n g o b j e c t / r e l a t i o n s h i p m a p p i n g r u l e t o d e s i g n r a t i o n a l d a t a b a s e , c o m c o m p o n e n t a u t o m a t i c c o d e g e n e r a t i o n a n d s o o n . p r a c t i c a l s o l u t i o n s t o s o m e k e y i s s u e s i n t h e m e t h o d a r e g i v e n . t h e m e t h o d c a n s o l v e t h e p r o b l e m s m e n t i o n e d a b o v e i n w e b a p p l i c a t i o n d e v e l o p m e n t . a c a s e i s o ff e r e d w h i c h t e s t s t h e f e a s i b i l i t y o f t h e p r o p o s e d m e t h o d f i n a l l y , a s u m m a r y i s d r a w n and s o m e d e f e c t s i n t h e m o d e l a r e a l s o d i s c u s s e d . k e y w o r d s : we b , c o m, wi n d o w s d n a , u ml , m o d e l i n g . 第一章引言 第一章引言 提到we b ，大家都会想到 w e b网站。但一般的网站并不能称之为w e b 应用，本文 中所谓的 “ w e b - b a s e d 应用”( 或简称为w e b 应用) ，指的是在整个we b系统 ( we b 服 务器、网络、协议、浏览器、组件、数据库)中， 用户的输入会影响到系统的业务状态 2 。 或者说， w e b 应用是一个显示逻辑相对简单， 而业务逻辑相对复杂， 并且用户的 输 入会影响到业务状态的一个 w e b系统。比如网上商店、网上银行或企业内部基于 w e b 的办公自 动化系统等都是典型的w e b 应用。 1 . 1 we b 应用相关技术及现状 1 . wi n d o w s d n a架构 一个成功的 we b - b as e d应用系统的构建必须有赖于一个健壮的分布式体系结构. 为此，微软建议采用被称为wi n d o w s d n a( 分布式网间应用程序架构)的体系结构来 编写分布式应用。 它是一个用来构造基于组件的三层应用程序的 框架结构， 可以 帮助开 发 人员 实 现 三 层的、 基 于 组 件 的 分 布 式 应 用的 所有 三 个 层次 3 , 1 7 。 当 前w i n d o w s d n a 体系结构作为we b 应用的基础框架已经得到了普遍应用。 ( 1 ) wi n d o w s d n a体系结构 按照w i n d o w s d n a思想， 应用系统结构可由图1 . 1 描述。 整个应用系统由 表示层 ( p r e s e n t a t io n ) 、 事务逻辑层 ( b u s i n e s s l o g i c ) 和数据服务层 ( d a t a ) 构成。 图1 . 1 w i n d o w s d n a 三层架构 表示层是应用程序和用户直接交互的层面。在i n t e rn e t 应用环境中，表示层的工作 由瘦型客户机来完成。 事务逻辑层负责处理表示层的 应用请求， 完成商务逻辑的 计算任务， 并将处理结果 返回给用户。 事务逻辑处理层是将原先置于客户端的事务逻辑分离出 来， 集中置于服务 器部分， 为所有用户共享。 事务逻辑层是整个应用的 核心部分。 事务逻辑层通过 c o m 第一章引言 组件进行事务处理， 并由i i s ( i n t e r n e t i n f o r m a t i o n s e r v e r ) 和 mt s ( mi c r o s o ft t r a n s a c t i o n s e r v e r )为各种应用组件提供完善的管理 ( 在win d o w s 2 0 0 0 中，c o m+ 已经将c o m和 m t s 集成起来) 。关于m t s 和c o m + 的详细介绍参见文献 4 , 1 5 数据服务层为应用提供数据来源。 和两层体系结构不同， 数据库不再和每个活动客 户保持一个连接， 而是若干个客户通过应用逻辑组件共享数据库的连接， 从而减少了连 接次数， 提高了数据服务器的性能和安全性。我们可以 根据需要选择 m i c r o s o ft s q l s e r v e r . o r a c l e或任何与o l e d b或o d b c兼容的数据源。 ( 2 ) wi n d o w s d n a结构的优点 将wi n d o w s d n a作为w e b - b a s e d 分布式应用的基础框架结构， 使得针对w e b 的商 务应用较以前开发大为改观:首先w i n d o w s d n a思想使软件系统的开发有了明确的分 工，一部分人员专著于事务逻辑层c o m组件的开发和测试，另一部分人员根据商务逻 辑的需要选择和使用c o m组件，使用组件提供的统一对外接口 而无须了解其功能实现 的内部细节，最终以 精练的 a s p脚本语言把组件集成到页面中，从而有效地降低了开 发难度， 加快了 开发进度; 其次w i n d o w d n a将事务逻辑处理单独分离出 来作为一个 层次来对待并用 n i t s统一管理，消除了各个 c o m 组件间潜伏的不协调性;第三， w i n d o w s d n a应用模式还显著地提高了系统的 运营效率和安全性: 若干个客户通过事 务逻辑层的组件共享与数据库的连接，降低了数据库的负担， 提高了系统的性能， 事务 逻辑层m t s 的安全管理机制使商务活动的安全性和系统结构有机地结合在一起。 总之，wi n d o w s d n a思想为企业开发复杂、 健壮、生命力强的w e b - b a s e d 商务应 用系统提供了一个十分有价值的模式，已 广泛应用于金融、电信、 交通等各种行业， 充 分显示了强大的生命力【 1 0 0 2 . c o m组件技术 基于组件的程序设计是继面向 对象之后的 又一个新的软件技术。 组件程序设计就 是将复杂的 应用程序设计成一些小的、 功能单一的组件模块， 这些组件模块可以 运行在 同一台机器或不同 机器上， 甚至不同的操作系统上。 每个组件程序可以 使用不同的编程 语言环境单独开发、 编译、 调试和测试， 最后把它们组合在一起就得到完整的应用程序。 当应用的需求发生变化时， 只对受影响的组件模块进行修改， 然后重新整合得到新的升 级软件， 而无需对整个系统进行编译修改。 组件程序设计大大增强了软件的复用性、 稳 定性和安全性， 使软件以即插即用的方式进行升级和维护，降低了成本， 提高了软件生 产的效率 9 。 现在业界占 主导地位的组件技术主要有三种。 其中微软公司的 c o m 是 wi n d o w s 系统下应用最为广泛的主流组件技术。 在c o m技术运用于w e b 应用开发之前，系统所有的事务逻辑处理只能由h t ml , j a v a s c r ip t 和c g i 等 技 术实 现， 选 择 余 地非 常 有限 。 后 来a s p 技 术的 面 世 使 动 态w e b 的开发方式大为改观， 但随之也出现了一些新的问题， 那就是页面的脚本语言结构十分 复杂， 逻辑不清晰， 可读性差。 这给编程和维护带来了很大的困难， 特别是当应用逻辑 需求变更时，修改这些臃肿、晦涩的解释性脚本源代码更是非常困难。而且仅用 a s p 技术也难以 应付复杂而细致的商务逻辑处理任务。 将c o m组件技术运用于w e b 应用开发之中， 可以解决上述问题。 将系统复杂细致 的业务逻辑用c o m组件来实现， 而在a s p 页面中只是创建并调用这些c o m组件， 事 第一章引言 务逻辑处理都是由c o m组件完成， a s p 脚本主要承担c o m组件的“ 粘合” 任务。 a s p 页面变得清晰、易读， 便于调试， 更不会出现开发活动因 研发人员的中途变动而使整个 工作搁浅的局面。 而 c o m组件则可根据需要利用v b , v c和c 什等多种语言工具实 现，其处理事务逻辑的能力十分强大。 显然， 将c o m组件运用于we b 应用的开发之中， 使系统简洁明了， 开发和维护都 变得更容易进行了。组件的独立性和语言无关性使得系统的开发时间大大缩短: 组件的 接口一旦确定，组件的开发和应用系统实现的其他工作可由各个专门小组同时进行; c o m组件的可重用性使得w e b 应用系统整体的管理和维护费用大大减少:当多个页面 需要进行相同的事务处理时，只需调用同一c o m组件而无须编写冗长而又复杂的a s p 脚本代码;当进行类似的系统开发， 需要进行相同的事务处理时， 也可方便地使用已有 的 c o m组件。c o m组件的即插即用性使得系统的升级和维护变得非常方便:当商务 逻辑变更时，不必改变整个页面源代码， 只需调整或替换相应的c o m组件，即可灵活 适应商务逻辑的改变;当有新的商务活动需要增加时，也只需添加新的组件并在 a s p 脚本中加以 调用即可。当前， c o m组件技术在一些企业级w e b 应用的开发中已经得到 了 运用并将会获得更为广泛的运用。 仅仅把c o m组件技术运用于w e b 系统开发中并不能产生一个成功的分布式应用。 高性能、可伸展、可靠的分布式应用程序需要一个复杂的基础结构，而 w i n d o w d n a 正是一个满足这样条件的体系结构。 将w i n d o w s d n a架构和c o m组件技术相结合， 将事务逻辑处理组件集中于w i n d o w d n a的中间层， 并由m t s 进行统一管理， 使c o m 组件技术在w e b 应用中显示出了更强大的生命力。 3 . 关系数据库系统 关系数据库系统是目 前最为成熟的 数据库技术。 作为w i n d o w s d n a架构的数据层， 必须要具有很好的安全性、 数据完整性、 并发控制和数据的 备份恢复等功能， 而关系数 据库系统完全满足了 这些要求， 并以 其广泛的 厂商支持得到了更多企业用户的 青睐。目 前，关系型数据库是构建基于w e b 的企业级应用的首选后台数据库系统。 1 . 2 存在的问题 1 .系统复杂性难以 控制 一方面，由 于基于 w e b的 分布式应用较传统的 分布式应用更容易为客户所接受: 更易于操作，对用户的计算机知识要求更少，对客户端计算机的要求更低，使得基于 w e b的分布式应用越来越广泛。另一方面，随着 w e b应用覆盖范围的不断扩大和业务 功能的不断增强，这种基于 w e b的分布式应用也变得越来越复杂，越来越难以 控制和 维 护 2 ,2 1 1 。目 前， 对 于w e b 应 用的主 要 研究 集中 于 开发工 具上， 而 对于开 发过程的 研 究则很少 2 。 所以， 对w e b 应用的开发过程进行研究， 建立一种可以 用于对w e b 应用 第 一 章引 言 的整个生命周期进行管理、有效控制系统复杂性的方法模型是非常必要的。 控制系 统复 杂 性的 最 好方法就是 对系统建 模 2 1 . u m l 是软 件界公 认的 功能强 大的 标准建模语言，利用它的扩展机制，可以为基于 w e b的分布式应用建模，以控制系统 的复杂性。 但是， w e b 应用中的软件元素与u ml中的面向 对象模型元素是不一致的。 所以， 如何将w e b 应用中的软件元素映射为u ml中的面向对象模型元素以 及如何扩展 u ml 为w e b 应用建模就成为了两个必须解决的问题。 2 . c o m组件的设计和数据库的设计与系统的整体设计脱节 当前，虽然c o m组件技术己广泛地运用于w e b 应用的开发之中， 但是对c o m组 件的 设计和开 发往往单 独进行 1 4 ，与 系统的 整体分析 和设 计脱节. 如果能 将c o m组 件的设计集成于对整个系统的分析和设计之中，可以使整个we b 系统的开发更加一致、 平滑，有条不紊，井然有序。 如前所述， w e b 应用的数据层多采用关系型数据库系统。 关系数据库逻辑结构的设 计一般采用由 概念设计阶段得到的e - r图向 关系模型转化而成 5 ， 这与面向 对象的设计 也是脱节的，并且表示方法完全不同.这种情况在 we b应用的开发中同样是普遍存在 的。 如果能将数据库的设计以一致的表示方法集成于使用面向对象方法对应用程序的整 体分析和设计之中， 则不仅减少了工作量， 而且整个开发过程更显得流畅、自 然、 一致。 所以， 如何扩展u m l ， 并寻找一种将数据库、 c o m组件和系统的整体分析设计整 合在一起的we b 应用建模和开发方法是非常有意义的。 1 . 3 本文工作 本文给出了 一种综合u m l 和c o m技术构建w i n d o w s d n a形态的分布式w e b 应 用的建模及开发方法，该方法利用u ml扩展机制为we b 应用建模，并将c o m组件的 设计和数据库的 设计一致地集成于整个系统的 分析和设计之中， 使得整个系统的 建模和 开发过程更一致、 平滑和自 然。 当然这其中有若干的问题需要解决， 本文对这些问题进 行了 较深入研究， 并给出了解决办法。 最后， 本文还用一个实例验证了 所提出的方法及 其关键问题解决方案的可行性。 以下是集成u ml 和c o m并使用关系数据库开发 需要解决的几个关键问题，也是本文重点解决的问题: d n a形态的w e b 应用 u m l 是面向 对象的 建模语言， 其中的 模型元素与w e b 应用中的软件元素大不相 同，那么怎么样用u ml为w e b分布式应用进行建模呢?这是第一个要解决的 问题。 对于后台数据库采用关系型数据库的w e b 应用系统，如何将面向 对象分析和设 计得到的对象模型中持久类及其之间的关系转化为关系数据库中的关系表存储 起来，是本文要解决的第二个问题。 第一章引言 如何将u m l 设计的最终结果向c o m组件实现平滑过渡， 是另一个需要解决的 问题。 1 . 4 结构安排 本论文的具体结构安排如下: 第二章对u m l 知识做了 简要介绍. 第三章对组件对象模型 ( c o m) 技术做了 概要 的介绍， 并给出了基于c o m技术的w e b 应用的体系结构。 第四章是本论文的重点章节， 在前三章所介绍技术的 基础上， 首先给出了 一个集成u m l和c o m构建w e b - b as e d 应 用的 方法模型和总体开发过程， 接下来分别对该过程中的 几个关键问 题给出了 详细的解 决方法。第五章通过一个 w e b应用实例的开发过程验证了开发流程和解决方案的可行 性。最后一章对本论文进行了总结，提出了模型中仍然存在的有待于解决的问题。 第二章 统一建模语言u m l 第二章统一建模语言u ml 软件工程领域在 1 9 9 5 年至 1 9 9 7 年取得了前所未有的进展，其成果超过过去 1 5 年 来的成就总和。其中最重要的、具有划时代重大意义的成果之一就是统一建模语言 ( u m l : u n i f i e d m o d e l i n g l a n g u a g e ) 的出 现。 它是面向 对象的分析与设计( o o a r u m b a u g h 的o m t - 2( 特别适用于以数据为中心的信息系统的分析和描 述中的应用): j a c o b s o n 的o o s e ，即u s e - c a s e 方法 ( 支持商业工程和需求分析)。 它 们都是完整的方法，但各有其特色。 u m l 开始于1 9 9 4 年1 0 月。先由r a t i o n a l s o f t w a r e 公司的g . b o o c h 和j . r u m b a u g h 将b o o c h 和o m t( 这两种方法被公认为是世界0 0 方法的先驱)统一起来，并于1 9 9 5 年 1 0 月推出了u m ( u n i f i e d m e t h o d )草案0 . 8 版; 1 9 9 5 年秋，j a c o b s o n 参加，把o o s e 也 合并进来，这才称为u m l . 经过b o o c h . r u m b a u g h 和j a c o h s o n 三人的努力， 了u m l 0 . 9 和u m l 0 . 9 1 版本，1 9 9 7 年 1 月公布了u m l 于1 9 9 6 年6 月和1 0 月分别推出 1 . 0 e 第二章统一建模语言u ml 1 9 9 6 年， 一些机构要将u m l 作为商业策略， 于是成立了完善和加强u m l 定义的 机构， 即u m l 成员协会，成员包括d e c , h p , i - l o g i x , i t e l l i c o r p , i b m , i c o n c o m p u t i n g , m c i s y s t e m h o u s e , m i c r o s o f t , o r a c l e , r a t i o n a l s o f t w a r e , t t 以及u n i s y s 等。它们 为u m l 开发提供了大量的有价值的技术，结果于1 9 9 7 年9 月推出了u m l 1 . 1 . 1 9 9 7 年 1 1 月1 7 日 其被o m g ( o b j e c t m a n a g e m e n t g r o u p ) 接纳为 标准。 u m l 是在多种0 0 方法基础上发展起来的。u m l 一经推出， 立即得到科技界、工业界 和用户的广泛欢迎和接受。 任何一项新技术、 新方法或新标准， 都需要经过不断地改进和完善。 因此在u m l 1 . 1 之后，又有u m l 1 . 2 , u m l 1 . 3 和u m l 1 . 4 版本，它们改进了u m l 1 . 1 版本中的一些遗 留问题及此后发现的诸多问 题。目 前u m l 2 . 0 版本正在起草，相信今后还将看到更新的 u m l 版本。 2 . 1 . 2 u ml的内容 作为一种建模语言，u m l 的定义包括u m l 语义和u m l 表示法两个部分 6 1 . ( 1 ) u m l 语义描述基于u m l 的 精确元模型定义。 元模型为u m l 的 所有元素在语法 和语义上提供了 简单、一致、 通用的定义性说明， 使开发者能在语义上取得一致。 此外 u m l 还支持对元模型的扩展定义。 ( 2 ) u m l 表示法定义u m l 符号的表示法， 为开发者或开发工具使用这些图 形符号 和文本语法为系统建模提供了 标准。 这些图 形符号和文字所表达的 是应用级的 模型， 在 语义上它是u m l 元模型的实例。 标准建模语言u m l 的重要内容可以由下列五类视图 ( 共9 种图形)来定义: 第一类是用例视图 ( u s e c a s e v i e w )，从用户角度描述系统功能。它是从系统的外 部用户角度出发， 对系统的抽象表示.用例视图中可以包含若干个用例 ( u s e c a s e )。 用例视图是其他视图的核心和基础. 用例视图主要为用户、设计人员、开发人员和测试 人员而设置。 第二类是逻辑视图( l o g i c a l v i e w ) ， 用例视图只考虑系统应该提供什么样的 功能， 对这些功能的内 部运作情况不予考虑， 为了 揭示系统内 部的设计和协作情况， 要使用逻 辑视图描述系统。 逻辑视图用来显示系统内部的功能是怎样设计的， 它利用系统的静态结构和动态行 为来刻画系统功能。 静态结构在类图和对象图中 描述， 动态建模用状态图、 序列图、 协 作图和活动图描述。 第三类是组件视图 ( c o m p o n e n t v i e w )，用来显示代码组件的组织方式。它描述了 实现模块和它们之间的依赖关系。组件视图由组件图组成。 组件是代码模块。组件视图 主要供开发者使用。 第四 类是并发视图 ( c o n c u r r e n c y v i e w )，用来显示系统的并发工作状况。并发 视图供系统开发者和集成者使用。它由动态图和执行图 ( 组件图，展开图)构成。 第五类是展开视图 ( d e p l o y m e n t v i e w )，展开视图用来显示系统的物理构架，即 第二章统一建模语言u m l 系统的物理展开。比如计算机和设备以及它们之间的联接方式。它由展开图表示。展开 图 还包括一个映射， 该映射显示物理架构中组件是怎样展开的。 展开视图 提供给开发者、 集成者和测试者。 由以 上介绍可知， u m l 中用一组视图来反映系统的各个方面，视图和视图之间会有 轻微的重叠。每个视图由一组图构成。这些图包括用例图、类图 ( 包含包)、对象图、 组件图、 展开图、状态图、活动图、序列图和协作图等九种图形， 其中前五种可以为系 统静态建模， 后四种用来为系统动态建模。 所以标准建模语言u m l 的主要内容也可以归 纳为静态建模机制和动态建模机制两大类。 2 . 1 .3 u ml的主要特点 标准建模语言u m l 的主要特点可以归结为三点: u m l 统一了b o o c h , o m t 和o o s e 等方法中的基本概念 u m l 还吸取了面向 对象技术领域中其他流派的长处， 的影响。 u m l 在演变过程中还提出了一些新的概念。 其中也包括非0 0 方法 2 . 1 .4 u ml的主要应用领域 u m l 的目 标是以 面向 对象的方式来描述任何类型的系统，具有很宽的 应用领域。 其中 最常用的是建立软件系统的 模型， 但它同 样可以 用于描述非软件领域的系统， 如机 械系统、 企业机构或业务过程，以 及处理复杂数据的信息系统、 具有实时要求的工业系 统或工业过程等。总之， u m l 是一个通用的标准建模语言，可以 对任何具有静态结构和 动态行为的系统进行建模 6 1 . 此外，u m l 适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段 f 6 , 7 。在需求分析阶段，可以 用用例来捕获用户需求。分析阶段主要关心问 题域中的 主要概念 ( 如抽象、 类和对象等) 和机制， 需要识别这些类以 及它们相互间的 关系， 并 用u m l 类图 来描述。为实现用例， 类之间需要协作， 这可以 用u m l 动态模型来描述。 编程 ( 构造) 是一个独立的阶段， 其任务是用面向 对象编程语言将来自 设计阶段的 类转换成实际的代码。 u m l 模型还可作为测试阶段的 依据. 系统通常需要经过单元测试、 集成测试、 系统 测试和验收测试。 不同的测试小组使用不同的u m l 图作为测试依据: 单元测试使用类图 和类规格说明; 集成测试使用组件图和协作图; 系统测试使用用例图来验证系统的行为; 验收测试由用户进行，以 验证系统测试的结果是否满足在分析阶段确定的需求。 总之， 标准建模语言u m l 适用于以 面向对象技术来描述任何类型的系统， 而且适用 于系统开发的不同阶段，从需求规格描述直至系统完成后的测试和维护。 第二章统一建模语言u m l 2 . 2 u m l 的静态建模机制 u m l 的 静态建模机制包括用例图 ( u s e c a s e d i a g r a m ) 、类图 ( c l a s s d i a g r a m ) 、 对象图 ( o b j e c t d i a g r a m) 、包( p a c k a g e ) 、组件图( c o m p o n e n t d i a g r a m ) 和展开图( d e p l o y m e n t d i a g r a m ) 6 . 2 . 2 . 1 用例图 1 . 用 例 模 型 ( u s e c a s e m o d e l) 用例模型描述的 是外部执行者( a c t o r ) 所理解的系统功能。 用例模型用于需求分析阶 段， 它的建立是系统开发者和用户反复讨论的结果， 表明了开发者和用户对需求规格达 成的共识。首先，它描述了待开发系统的功能需求;其次，它将系统看作黑盒，从外部 执行者的角度来理解系统; 第三， 它驱动了需求分析之后各阶段的开发工作， 不仅在开 发过程中保证了系统所有功能的实现， 而且被用于验证和检测所开发的系统，从而影响 到开发工作的各个阶段和u ml的各个模型。在u m l中，一个用例模型由若干个用例 图描述，用例图主要元素是用例和执行者。 2 . 用例 ( u s e c a s e ) 从本质上讲， 一个用例是用户与计算机之间的一次典型交互作用。 以 字处理软件为 例，.将某些正文置为黑体 和.创建一个索引” 便是两个典型的 用例。 在 u ml中，用例 被定义成系统执行的一系列动作， 动作执行的结果能被指定执行者察觉到。 在u m l 中， 用例表示为一个椭圆。 图2 . 1 显示了 一个金融贸易系统的用例图。 概 括地说，用例有以下特点: 用例捕获某些用户可见的需求，实现一个具体的用户目 标。 用例由 执行者激活，并提供确切的值给执行者。 用例可大可小，但它必须是对一个具体的用户目 标实现的完整描述。 吴 助 帐目记盆 东统 交 易 估价 理/-、员 计01人锹 进 行 交 易妞越 边 界 的 交 易 图2 . 1 用例图 第二章统一建模语言u m l 3 . 执行者( a c t o r ) 执行者是指用户在系统中所扮演的角色。其图形化的表示是一个小人。图2 . 1 中有 四个执行者:贸易经理、营销人员、售货员和记帐系统。 图2 . 1 中，不带箭头的线段将执行者与用例连接到一起，表示两者之间交换信息， 称之为通信联系。执行者可以 从用例中取值，也可以参与到用例中。 执行者也可以 是一个外界系统， 该外界系统可能需要从当前系统中获取信息， 与当 前系统有进行交互。 在图2 . 1 中，我们可以 看到，记帐系统是一个外界系统， 它需要更 新帐目。 4 . 使用和扩展( u s e a n d e x t e n d ) 图2 . 1 中除了 包含执行者与用例之间的 连接外， 还有另外两种类型的 连接， 用以 表 示用例之间的使用和扩展关系。 使用和扩展是两种不同形式的继承关系。 当一个用例与 另一个用例相似， 但所做的动作多一些， 就可以 用到扩展关系。 当有一 大块相似的动作 存在于几个用例， 又不想重复描述该动作时， 就可以 把相似的 动作抽象出 来组成单独的 一个用例， 其他用例和该用例构成使用关系。 虽然使用和扩展都意味着从几个用例中抽取那些公共的行为并放入一个单独用例 中，而这个用例被其他几个用例使用或扩展，但使用和扩展的目的是不同的。 2 . 2 . 2 类图、对象图和包 类 ( c las s ) 、 对 象 ( o b j e c t ) 和 它 们 之间 的 关 联 是 面向 对 象 技 术中 最 基 本的 元 素. 对 于 一 个想要描述的系统， 其类模型和对象模型揭示了系统的结构。 在u m l中，类和对象模 型分别由 类图 和对象图 表示。 类图 技术是0 0方法的 核心 6 。图2 .2 显示了一个金融保 险系统的类图。 约 臾 多!性 图2 . 2保险系统类图 第二章统一建模语言u m l i . 类图 类图 ( c l a s s d i a g r a m ) 描述类以 及类之间的 静态 关系。它不仅显 示了 信息的 结 构， 同 时还描述了 系统的 行为。 类图 是定义其它图的基础。 在类图的 基础上， 状态图、 协作图 等进一步描述了系统其他方面的特性。 2 . 类和对象 所 谓类 ( c l a s s ) 是 对一 类具 有相同 特征的 对象的 描 述。 而对 象是 类的 实 例 i n s t a n c e ) . 类描述一类对象的属性( a t t r ib u t e ) 和行为 ( b e h a v i o r ) 。 在 u m l中， 类的 可视化表示 为一个划分成三个格子的 长方形( 下面两个格子可省略) 。 图2 . 2 中， “ 客户” 就是一个典 型的类。最顶部的格子包含类的名字，中间的格子包含类的属性，第三格是类的操作 ( o p e r a t i o n ) . 属性和操作具有不同的可见性， 常用的 可见性有p u b l i c . p r iv a t e 和p r o t e c t e d 三种，在u ml中分d j 表示为” + ， 、” 一 ， 和，# ， 。 类图描述了类和类之间的静态关系。 定义了类之后， 就可以定义类之间的各种关系 关联关系 关 联 ( a s s o c i a t i o n ) 表 示 两 个 类之间 存 在 某 种 语 义 上的 联 系。 了3. 关联可以 有方向， 表示该关联单方向 被使用。 关联上加上箭头表示方向， 在 u m l 中 称 为 导 航 困a v i g a b i li ty ) 。 我 们 将 只 在 一 个 方向 上 存 在导 航 表 示的 关 联， 称 作 单向 关 联 ( u n i - d ir e c t io n a l a s s o c i a t io n) ， 在两个方向 上都有导航表示的 关联， 称作 双向 关联 ( b i - d i r e c t i o n a l a s s o c i a t i o n ) . 可以为关联命名， 用小黑三角表示名字的方向 ( 见图2 .2中 最上部的” 属于，/签定“ 关联) 。命名有助于理解模型。 关联两头的类以 某种角色参与关联。 例如图 2 .3中，” 公司” 以” 雇主“ 的角色，“ 人” 以 .雇员” 的角色参与” 工作合同.关联. ，雇主” 和” 雇员” 称为角色名。 如果在关联上没有标 出 角 色名， 则隐 含 地用 类的 名 称 作为 角 色名。 角 色 还 具 有多 重 性 ( m u lt ip l ic i ty ) ， 表 示 可 以 有多少个对象参与该关联， 如图2 .3 . 多重性 关联 名角色名 图2 . 3 关联的角色 一个关联可能要记录一些信息，可以引入一个关联类来记录 基础上引入了关联类。关联类通过一根虚线与关联连接。图2 . 5 一种方法，就是使雇用关系成为一个正式的类。 : 。图2 .4是在图2 .3的 是实现上述目 标的另外 第二章 统一建模语言u m l 一i黔 工 作合同 合同 期限年 工作 合司 合司 期限 : 年 图 2 . 4 关 联类图 2 . 5 另一 种 实 现 方法 聚 集和组 成 聚 集( a g g r e g a t i o n ) 是一 种特殊形式的 关 联。 聚集表示类 之间 的 关 系是 整体与部分的关系。聚集可以进一步划分成共享聚集( s h a r e d a g g r e g a t i o n ) 和组成 ( c o m p o s i t i o n ) 。 例如， 课题组包含许多成员， 但是每个成员又可以 是另一个课题组的 成 员，即部分可以 参加多个整体， 我们称之为共享聚集。 另一种情况是整体拥有各部分， 部分 与整体共 存， 如整 体不存 在了， 部分也 会随 之消失， 这 称为 组 成 ( c o m p o s it i o n ) . 例 如， 我们打开一个视窗口， 它就由 标题、外框和显示区所组成。 一旦消亡则各部分同时 消失。在u ml中，聚集表示为空心菱形，组成表示为实心菱形。 4 . 继承关系 继承( g e n e r a l i z a t i o n ) 定义了 一般元素和特殊元素之间的分类关系。 在u m l 中， 继承 表示为一头为空心三角形的连线。 如图2 .2 中， 将客户进一步分类成个体客户和团体客户， 使用的就是继承关系. 5 . 依赖关系 有两个元素x , y ， 如果修改元素x的定义可能会引起对另一个元素y的定义的 修 改， 则 称元 素y 依赖 ( d e p e n d e n c y ) 于 元素x 。 在 类中， 依 赖由 各 种原因 引 起， 如: 一 个 类向另一个类发消息; 一个类是另一个类的数据成员; 一个类是另一个类的 某个操作参数 等。 6 . 对象图、对象和链 u m l中对象图与类图 具有相同的 表示形式。对象图 可以 看作是类图的一个实例。 对象是类的实例; 对象之间的 链( l i n k ) 是类之间的 关联的实例。 7 . 包 一个最古老的软件方法问 题是: 怎样将大系统拆分成小系统。 解决这个问 题的一个 思路是将许多类集合成一个更高层次的单位， 形成一个高内聚、 低祸合的类的集合。 这 个思 路被 松散 地应 用到 许多 对象技术中。 u m l 中 这种分 组 机制叫 包 ( p a c k a g e ) . 不仅是类， u m l中的任何模型元素都可运用包的 机制。 如果没有任何启发性原则 来指导类的分组，分组方法就是任意的。在u ml中，最有用的和强调最多的启发性原 则就是依赖。 包图主要显示类的包以 及这些包之间的依赖关系。 有时还显示包和包之间 的继承关系和组成关系。 8 . 其他模型元素和表示机制 第二章统一建模语言u m l 类图中 用到的 模型元素和表示机制较为丰富， 由 于篇幅的限制， 这里不能一一介绍。 主 要还有以 下 模型符号 和概 念: 约束 ( c o n s t r a i n t ) 、 版型 ( s t e r e o t y p e ) 、 界 面 ( i n t e r f a c e ) 、 参 数 化 类 ( p a r a m e t e r i z e d c las s ) 也 称 模 板 类 ( t e m p la t e ) 、 限 定 关 联 ( q u a l i f ie d a s s o c i a ti o n ) 、 多 维关 联( n - a ry a s s o c i a t i o n ) 、 多 维 链( n - a ry l i n k ) , 派 生 ( d e r i v e d ) 、 类型 ( t y p e ) 和 注 释( n o t e ) 等， 详细内 容参见文献 7， 8 。 2 . 2 .3 组件图和展开图 组件图 ( c o m p o n e n t d ia g r a m ) 和展开图 ( d e p l o y m e n t d i a g r a m ) 显示系统实现时的一些 特性， 包括源代码的静态结构和运行时刻的实现结构。组件图显示代码本身的结构， 展 开图显示系统运行时刻的结构。 1 .组件图 组件图 显示软件构件之间的 依赖关系。 一般来说， 软件构件就是一个实际 文件， 可 以 是源代码文件、 二进制代码文件和可执行文件等。 组件图 可以 用来显示编译、 链接或 执行时构件之间的依赖关系。 2 .展开图 展开图描述系统硬件的物理拓扑结构以及在此结构上执行的软件， 如图2 . 6 所示是 一个保险系统的展开图。 展开图可以显示计算结点的拓扑结构和通信路径、结点上运行 的软件构件、软件构件包含的逻辑单元( 对象、 类) 等。 展开图常常用于帮助理解分布式 系统。 客户端p c 保险单坡 写界面 构件的界面 丫-一一仁介里一歌 熟-j沁口洲-图 cl干月q|-l-一王配-目 保险后台服务器 保险系统 配t用户 件中包含 的对象 展开图 第二章统一建模语言u ml 2 . 3 u m l 动态建模机制 2 .3 . 1 消息 在面向对象技术中， 对象间的交互是通过对象间消息的传递来完成的。在u m l 的四 个动态模型中均用到消息这个概念。 通常， 当一个对象调用另一个对象中的操作时， 即完 成了一次消息传递。 当操作执行后， 控制便返回到调用者。 对象通过相互间的通信( 消息 传递) 进行合作， 并在其生命周期中根据通信的结果不断改变自身的状态。 u m l 定义的消息类型有三种: 简单消息、同步消息和异步消息。 2 . 3 . 2 状态图 状态图( s t a t e d i a g r a m ) 用来描述一个特定对象的 所有可能 状态及其引 起状态转移 的事件。 用状态图 表示单个对象在其生命周期中的 行为。 一个状态图 包括一系列的 状态 以及状态之间的转移.如图2 . 7 是一个支票对象的状态图示例: 哗 塑 钎支 ” 图2 . 7 写己 ”) - 竺 兰 鹭. 状态图示例 1 .状态 所有对象都具有状态， 状态是对象执行了一系列活动的结果. 当某个事件发生后， 对 象的状态将发生变化。状态图