（计算机软件与理论专业论文）基于z对uml中use+case图的形式化.pdf

摘要 y “8 8 g 1 统一建模语言u m l 已经成为面向对象建模语言的标准，正在得到越来越广泛的 应用。形式化软件方法能产生严密、精确的规格说明，为软件开发提供严格的数学基 础为了使u m l 更加精确，同时发挥形式化方法的优势，增加形式化方法在软件开 发中的实际作用，我们提出了形式化方法与统一建模语言中u s ec a s e 图相结合的方 法。 本文使用z 语言给出u m l 中u s ec a s e 图的形式化描述，为u m l 提供形式化的 基础在本文中，我们采用分而治之的原则，分别对u s ec a s e 图中的三种组成成分角 色、u s ec a s e 和系统进行形式化，然后将这三种成分的形式化描述组合起来。就得到 我们所需要的u s ec a s e 图的形式化描述。 关键词：统一建模语言，u s ec a s e ，形式化方法，z 语言 a b s t r a c t u n i f l e dm o d e l l i n gl a n g u a g eh a sb e e nac r i t e r i o n o fo b j e c t - o r i e n t e d m o d e l l i n gl a n g u a g ea n db e e nu s e dm o r ea n dm o r ew i d e l y f o r m a ls o f t w a r e m e t h o dc a r tp r o d u c ep r e c i s es p e c i f i c a t i o n , a n dp r o v i d er i g o r o u sm a m e m a n c a l b a s i sf o rs o x r w s r ed e v e l o p m e n t i no r d e rt om a k e 眦m o r e p r e c i s e 。e x h i b i tt h e a d v a n t a g eo ff o r m a lm e t h o d ，a n de n h a n c et h ea c t u a le f f e c to f f o r m a lm e t h o di n s o f t w a l ed e v e l o p m e n t , w ep u tf o r w a r dan e wm e t h o dt h a tc o m b m et h ef o r m a l m e t h o dw i t hu s ec a s e d i a g r a mo f u m 屯 t h i sp a p e rd e s c r i b e sf o r m a l l yt h eu s ec a s ed i a g r a mw i t hz l a n g u a g e ， w h i c hp m “d ef o r m a lb a s i sf o ru m l r e s p e c t i v e l yw ef o r m a l i z et h et h r e e c o m p o n e n t so fu s ec a s ed i a g r a m ：a c t o r , u s ec a s ea n d s y s t e m f u r t h e r m o r e ， t h ef o r m a l d e s c r i p t i o n o fu s ec a s e d i a g r a m c a nb eo b t a i n e d b y t h e c o m b i n a t i o no ff o r m a l i z a t i o no f a c t o r , u s ec a s ea n ds y s t e m k e y w o r d s ：u i v i l ，u s ec a s e ，f o r m a lm e t h o d ，z l a n g u a g e 苎王! 墅坐些生坐! 里竺! 鬯墼垄茎些一 序言 统一建模语言u m l 是面向对象开发中一种通用的、图形化的模型语言，是 近代软件工程环境中对象分析和设计的重要工具。近年来，统一建模语言u m l 被广泛用于对软件系统不同阶段的模型化经验表明。如果模型的表示有坚实的 语义基础，那么可以对模型的含义有更清晰的理解；相反，如果缺乏足够的语义 支持，对模型本身的语义的理解将会增加很大的困难 z 语言是一种常用的形式化语言，具有“状态操作”风格，它以一阶谓词逻 辑和集合论为基础，利用集合、关系、函数、序列和包等数学概念，使用状态模 式和操作模式对目标系统的状态和行为进行说明，具有简明和精确的特点，z 语 言在工业界和学术界得到了广泛的应用，曾被称为“软件工程语言”。 本文将统一建模语言u m l 和z 语言结合起来，提出了基于z 语言对统一建 模语吉u m l 中u s ec a s e 图的形式化描述方法在本文中，我们分别对u s ec 够e 图中的三种组成成分角色、u s ec a s e 和系统进行形式化，然后将这三种成分的形 式化描述组合起来，就得到所需要的u s ec e 图的形式化描述。对于u s ec a s e 图中的角色，我们将其形式化为具有这种角色的类。对于各个u s ec a s e ，将它们 形式化为声明和断言两部分，断言是对u 靶c a s e 所用到的u s e c a s e 、状态变量和 输入输出变量的说明，断言包括前置条件和后置条件两部分。前置条件是执行 u s ec s s e 的功能前状态变量和输入应满足的条件，后置条件是执行u s ec a s e 的功 能后状态变量和输出所应满足的条件至于系统，同样将其形式化为两个组成部 分，第一部分是它所包含的u s ec e 的说明，第二部分是对各个u s ec a s e 的约 束，也就是对u s ec a s e 之间的关系进行描述在得到角色、u s ec a s e 和系统的形 式化描述后，我们就可以对u s ec a s e 图进行一个整体的描述，首先给出u s ec a s e 图所包含的角色、u s oc a s e 和系统，然后再说明角色和u s ec a s e 之间的关系。 本文的主要内容共分为五个部分。 第一章是统一建模语言u m l 和u s ec a s e 图的介绍阐述了统一建模语言 u m l 的出现、内容、主要特点和应用领域；说明了u s ec a s e 图的组成、表示法 以及它的功能和应用范围，最后还指出了它的不足之处。 第二章是形式化方法和z 语言的概述首先说明了形式化方法的重要意义、 分类以及发展展望，然后又简要介绍了我们在形式化工作中用到的形式规约语言 z 语言。 第三章提出了一种基于z 语言对统一建模语言u m l 中u s e c a s e 图的形式化 方法 苎王兰墅坐些主堕垒苎里堕丝壅些 第四章结合图书馆信息系统实例说明了u s e c a s e 图形式化描述方法的具体实 现 第五章是总结和展望，对我们在本文中所做的工作进行了总结和概括，并提 出了进一步的工作 2 苎王圣盟旦坠! 竺兰竺竺! _ 璺堕堕堑型兰一 第一章统一模型语言u m l 和u s e c a s e 图 面向对象的分析与设计( o o a d ) 方法的发展在8 0 年代末至9 0 年代中出现 了一个高潮，u m l 是这个高潮的产物它不仅统一了b o o c h 、r u m b a u g h j a c o b s o n 的表示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模 语言。 1 1 关于统一建模语言u m l 一统一建模语言u m l 的出现 公认的面向对象建模语言出现于7 0 年代中期从1 9 8 9 年到1 9 9 4 年，其数 量由不到十种增加到了五十多种在众多的建模语言中，语言的创造者努力推祟 自己的产品，并在实践中不断完善。但是，o o 方法的用户并不了解不同建模语 言的优缺点及相互之间的差异，因而很难根据应用特点选择合适的建模语言，于 是爆发了一场“方法大战”。9 0 年代中期，一批新方法出现了，其中最引人注目的 是b o o c h1 9 9 3 、o o s e 和o m t - 2 等 b o o c h 是面向对象方法最早的倡导者之一，他提出了面向对象软件工程的概 念1 9 9 1 年，他将以前面向a d a 的工作扩展到整个面向对象设计领域。b o o t h1 9 9 3 比较适合于系统的设计和构造 r u m b a u g h 等人提出了面向对象的建模技术( o m t ) 方法，采用了面向对象 的概念，并引入各种独立于语言的表示符。这种方法用对象模型、动态模型、功 能模型和用例模型，共同完成对整个系统的建模，所定义的概念和符号可用于软 件开发的分析、设计和实现的全过程。软件开发人员不必在开发过程的不同阶段 进行概念和符号的转换o m t - 2 特别适用于分析和描述以数据为中心的信息系 统 j a c o b s o n 于1 9 9 4 年提出了o o s e 方法，其最大特点是面向用例( u s e c a s e ) 。 并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武 器，而且用例贯穿于整个开发过程，包括对系统的测试和验证o o s e 比较适合 支持商业工程和需求分析。 此外，还有c o a d y o u r d o n 方法，即著名的o o a o o d ，它是最早的面向对象 的分析和设计方法之一该方法简单、易学，适合于面向对象技术的初学者使用， 苎王! 堕坐些型苎曼竺! 里塑丝苎些一 但由于该方法在处理能力方面的局限，目前已很少使用 概括起来，首先，面对众多的建模语言，用户由于没有能力区别不同语言之 间的差别，因此很难找到一种比较适合其应用特点的语言；其次，众多的建模语 言实际上各有千秋；第三，虽然不同的建模语言大多类同，但仍存在某些细微的 差别，极大地妨碍了用户之间的交流因此在客观上，极有必要在精心比较不同 的建模语言优缺点及总结面向对象技术应用实践的基础上，组织联合设计小组， 根据应用需求，取其精华，去其糟粕。求同存异，统一建模语言 1 9 9 4 年1 0 月，g r a d yb o o c h 和j i mr u m b a u g h 开始致力于这一工作他们首 先将b o o c h9 3 和o m t - 2 统一起来，并于1 9 9 5 年l o 月发布了第一个公开版本， 称之为统一方法u mo 8 ( u n i t i e dm e t h o d ) 。1 9 9 5 年秋，o o s e 的创始人i v a r j a c o b s o n 加盟到这一工作。经过b o o t h 、r u m b a u g h 和j a c o b s o n 三人的共同努力， 于1 9 9 6 年6 月和l o 月分别发布了两个新的版本，即u m l0 9 和u m lo 9 1 ，并 将u m 重新命名为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 ) 。 1 9 9 6 年，一些机构将u m l 作为其商业策略已日趋明显u m l 的开发者得到 了来自公众的正面反应，并倡议成立了u m l 成员协会，以完善、加强和促进u m l 的定义工作。当时的成员有d e c 、h p 、i l o g i x 、l 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 is 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 ls o f t w a r e 、t i 以及 u n i s y s 这机构对u m l l 0 ( 1 9 9 7 年1 月) 及u m l l 1 ( 1 9 9 7 年1 1 月1 7 日) 的定义和发布起了重要的促进作用 u m l 是一种定义良好、易于表达、功能强大且普遍适用的建模语言它溶入 了软件工程领域的新思想、新方法和新技术它的作用域不限于支持面向对象的 分析与设计，还支持从需求分析开始的软件开发的全过程。 面向对象技术和u m l 的发展过程如上所述，统一建模语言的出现是其重要 成果在美国，截止1 9 9 6 年1 0 月，u m l 获得了工业界、科技界和应用界的广泛 支持，已有7 0 0 多个公司表示支持采用u m l 作为建模语言。1 9 9 6 年底，u m l 已 稳占面向对象技术市场的8 5 。成为可视化建模语言事实上的工业标准。1 9 9 7 年1 1 月1 7 日，o m g 采纳u m l1 1 作为基于面向对象技术的统一建模语言u m l 代表了面向对象方法的软件开发技术的发展方向，具有巨大的市场前景，也具有 重大的经济价值和国防价值。 一统一建模语言u m l 的内容 首先，u m l 融合了b o o c h 、o m t 和o o s e 方法中的基本概念，而且这些基 本概念与其他面向对象技术中的基本概念大多相同，因而，u m l 必然成为这些方 法以及其他方法的使用者乐于采用的种简单一致的建模语言l 其次，u m l 不仅 仅是上述方法的简单汇合，而且是在这些方法的基础上广泛征求意见，集众家之 长，几经修改而完成的，u m l 扩展了现有方法的应用范围；第三，u m l 是标准 的建模语言，而不是标准的开发过程。尽管u m l 的应用必然以系统的开发过程 为背景，但由于不同的组织和不同的应用领域，需要采取不同的开发过程。 作为一种建模语言，u m l 的定义包括u m l 语义和u m l 表示法两个部分 ( 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 ec a s e 图) ，从用户角度描述系统功能，并指出各功能 的操作者 第二类是静态图( s t a t i cd i a g r a m ) ，包括类图、对象图和包图其中类图描述 系统中类的静态结构不仅定义系统中的类，表示类之间的联系如关联、依赖、 聚合等，也包括类的内部结构( 类的属性和操作) 类图描述的是一种静态关系。 在系统的整个生命周期都是有效的 对象图是类图的实例，几乎使用与类图完全相同的标识他们的不同点在于 对象图显示类的多个对象实例。而不是实际的类。一个对象图是类图的一个实例 由于对象存在生命周期，因此对象图只能在系统某一时问段存在 包图由包或类组成。表示包与包之间的关系。包图用于描述系统的分层结构。 第三类是行为图( b e h a v i o rd i a g r a m ) ，描述系统的动态模型和组成对象问的 交互关系其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移 条件通常，状态图是对类图的补充在实用上并不需要为所有的类画状态图， 仅为那些有多个状态，其行为受外界环境的影响并且发生改变的类画状态图 而活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于 识别并行活动 第四类是交互图( i n t e r a c t i v ed i a g r a m ) ，描述对象间的交互关系其中顺序 图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对 象之间的交互；合作图描述对象间的协作关系，合作图跟顺序图相似，显示对象 间的动态合作关系除显示信息交换外。合作图还显示对象以及它们之间的关系 如果强调时间和顺序，则使用顺序图；如果强调上下级关系。则选择合作图这 5 茎王兰型1 2 些! 旦! ! ! 壁鬯塑垄茎些 两种图合称为交互图 第五类是实现图( i m p l e m e n t a t i o nd i a g r a m ) 其中构件图描述代码部件的物 理结构及各部件之间的依赖关系。一个部件可能是一个资源代码部件、一个二进 制部件或一个可执行部件。它包含逻辑类或实现类的有关信息部件图有助于分 析和理解部件之间的相互影响程度。 配置图定义系统中软硬件的物理体系结构它可以显示实际的计算机和设备 ( 用节点表示) 以及它们之间的连接关系，也可显示连接的类型及部件之问的依 赖性。在节点内部，放置可执行部件和对象以显示节点跟可执行软件单元的对应 关系。 从应用的角度看，当采用面向对象技术设计系统时，首先是描述需求；其次 根据需求建立系统的静态模型，以构造系统的结构；第三步是描述系统的行为。 其中在第一步与第二步中所建立的模型都是静态的，包括用例圈、类图( 包含包 图) 、对象图、组件图和配置图等五个图形，它们是统一建模语言u m l 的静态建 模机制在第三步中所建立的模型或者可以执行，或者表示执行时的时序状态或 交互关系。它包括状态图、活动图、顺序图和合作图等四个图形，是统一建模语 言u m l 的动态建模机制。因此，统一建模语言u m l 的主要内容也可以归纳为静 态建模机制和动态建模机制两大类。 统一建模语言u m l 的主要特点 统一建模语言u m l 的主要特点可以归结为三点： ( 1 )u m l 统一了b o o c h 、o m t 和o o s e 等方法中的基本概念。 ( 2 ) u m l 还吸取了面向对象技术领域中其它流派的长处，其中也包括非 o o 方法的影响。u m l 符号表示考虑了各种方法的图形表示，删掉 了大量易引起混乱的、多余的和极少使用的符号，也添加了一些新符 号。因此，在u m l 中汇入了面向对象领域中很多人的思想。这些思 想并不是u m l 的开发者们发明的，而是开发者们依据最优秀的o o 方法和丰富的计算机科学实践经验综合提炼而成的 ( 3 ) u m l 在演变过程中还提出了一些新的概念在u m l 标准中新加了 模板( s t e r e o t y p e s ) 、职责( r e s p o n s i b i l i t i e s ) 、扩展机制饵x t e n s i b i l i t y m e c h a n i s m s ) 、线程( t h r e a d s ) 、过程( p r o c e s s e s ) 、分布式( d i s t r i b u t i o n ) 、 并发( c o n c u r r e n c y ) 、模式( p a t t e r n s ) 、合作( c o l l a b o r a t i o n s ) 、活动图 ( a c t i v i t yd i a g r a m ) 等新概念，并清晰地区分类型( t y p e ) 、类( c l a s s ) 和实例( i n s t a n c e ) 、细化( r e f i n e m e n t ) 、接口( i n t e r f a c e s ) 和组件 ( c o m p o n e n t s ) 等概念 6 苎王至型坐些望苎竺竺! 里塑丝苎丝一一 因此可以认为，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 建立分析和设计模型时，应尽量避免考虑把模型转换成某种 特定的编程语言。因为在早期阶段，模型仅仅是理解和分析系统结构的工具，过 早考虑编码问题十分不利于建立简单正确的模型 u m l 模型还可作为测试阶段的依据系统通常需要经过单元测试、集成测 试、系统测试和验收测试。不同的测试小组使用不同的u m l 图作为测试依据： 单元测试使用类图和类规格说明：集成测试使用部件图和合作图；系统测试使用 用例图来验证系统的行为：验收测试用以验证系统测试的结果是否满足在分析阶 段确定的需求。 总之，统一建模语言u m l 适用于以砸向对象技术来描述任何类型的系统， 而且适用于系统开发的不同阶段，从需求规格描述直至系统完成后的测试和维护。 1 2 u s e c a s e 图 u s e c a s e 图是统建模语言u m l 的五类图之一，在统一建模语言u m l 中占 7 差三圣型坐些竖壁竺里塑兰苎些一 有重要的地位。 m u s ec a s e 图的组成 u s ec a s e 图的基本组成部分是角色、u s ec a s e 和系统。角色是与系统进行交 互的外部实体，它可以是系统用户，也可以是其它系统或硬件设备，总之，凡是 需要与系统交互的任何东西都可以称作角色。u s ec a s e 用于描述系统的功能，也 就是从外部用户的角度观察，系统应支持哪些功能，帮助分析人员理解系统的行 为，它是对系统功能的宏观描述一个完整的系统中通常包含若干个u s e c a s e ， 每个u s ec a s e 具体说明应完成的功能，代表系统的所有基本功能( 集) 系统的 边界线以内的区域( 即u s e c a s e 的活动区域) 则抽象表示系统能够实现的所有基 本功能。在一个基本功能( 集) 已经实现的系统中，系统运转的大致过程是：外 部角色先初始化u s e c a s e ，然后u s e c a s e 执行其所代表的功能，执行完后u s e c a s e 便给角色返回一些值，这个值可以是角色需要的来自系统中的任何东西 角色 角色( a c t o r ) 是与系统交互的人或事。所谓“与系统交互”指的是角色向系 统发送消息，从系统中接收消息，或者在系统中交换消息只要使用u s ec a s e ， 与系统互相交流的任何人或事都是角色。比如，某人使用系统中提供的u s ec a s e ， 则该人就是角色；与系统进行通信( 通过u s ec a s e ) 的某种硬件设备也是角色 角色是一个群体概念。代表的是一类能使用某个功能的人或事，角色不是指 某个个体比如，在自动售货系统中，系统有售货、供货、提取销售散等功能， 启动售货功能的是人那么人就是角色，如果再把人具体化，则该人可以是张三 ( 张三买矿泉水) ，也可以是李四( 李四买可乐) ，但是张三和李四这些具体的个 体对象不能称作角色。事实上，一个具体的人( 比如张三) 在系统中可以具有多 种不同的角色比如，上述的自动售货系统中，张三既可以为售货机添加新物品 ( 执行供货) 也可以将售货机中的钱取走( 执行提取销售款) 。通常系统会对角色 的行为有所约束，使其不能随便执行某些功能比如，可以约束供货的人不能同 时又是提取销售款的人，以免有舞弊行为角色都有名字，它的名字反映了该角 色的身份和行为( 比如顾客) ，注意，不能将角色的名字表示成角色的某个实例( 比 如，张三) ，也不能表示成角色所需完成的功能( 比如，售货) 。 角色与系统进行通信的收、发消息机制与面向对象编程中的消息机制很像 角色是启动u s ec a s e 的前提条件，又称为刺激物角色先发送消息给u s ec a s e ， 初始化u s ec a s e 后，u s ec a s e 开始执行，在执行过程中，该u s ec a s e 也可能向 8 苎王墨翌竺些! 旦苎里竺! 里箜墨型望生一 一个或多个角色发送消息( 可以是其它角色，也可以是初始化该u s e c a s e l o a d ) 角色类包含有属性、行为和描述角色的文档性质统一建模语言u m l 中用 - - 4 4 、人形图形表示角色类，小人形的下方写角色名字，如图1 一l 所示。 u s ec s o 什么是u s e c a s e 吴 保脸销售员 图i - l 角色类的图示方法示倒 u s ec a s e 概念是由j a c o b s o n 最早提出并详细阐述的对象技术词典) 根据 j a c o b s o n 的观点给出了如下两个定义： ( u s e c a s e 是) 对一个系统或一个应用的一种单一的使用方式所进行的描述。 ( u s ec a s e 是) 关于单个角色在与系统的对话中所执行的处理的行为陈述序 列。 把以上两个定义的内容综合起来，以更符合中文习惯的方式给出，就是： u s ec a s e 是对一个角色使用系统的一项功能时所进行的交互过程的一个文字 描述序列。 上述定义包含了如下几层意思： ( i ) 一个u s ec a s e 只描述一个角色对一项单一的系统功能的使用情况不 能把一个大方面的功能( 它包含了许许多多的具体功能) 的使用情况笼统地用一 个u s ec a s e 来描述。这样规定主要目的是为了避免一个u s ec a s e 过于庞大或过 分复杂 ( 2 ) u s ec a s e 是一种平铺直叙的文字描述，不是程序，也不是图形、流程图 之类的东西。它可以像一个剧本一样从头到尾的阅读 ( 3 ) u s ec a s e 陈述了角色和系统在交互过程中双方所作的事，例如角色向系 统发一命令要求它做某件事；系统经初步判断，要求角色提供进一步的信息；角 色输入信息；系统进行处理，把结果报告角色这确实是一种“对话”，你一段台 词，我一段台词，互相交织，构成一个剧本。它就像我国东北的地方戏“二人转” 的剧本，由两个演员来对唱这两个“演员”一个是角色，一个是系统 在所有的u s ec a s e 中，由角色首先发起对话的可能性较大，但有些对话也可 能是由系统首先发起的例如，系统在发现某些异常情况时主动要求操作员的干 9 苎王兰型坐些竺竺曼竖鬯塑堑塞些 预，系统主动地向设备发出操作指令，本系统主动要求与外系统通信等等，就需 要一个由系统首先发起对话的u s ec a s e 来描述 ( 4 ) u s ec a s e 的使用方式只强调用u s ec a s e 描述角色和系统彼此为对方直 接地做了些什么事。不描述怎么做，也不描述间接地做了些什么。对角色只描述 它对系统的直接动作( 例如“输入某某数据”) ，不描述为了完成这个动作所进行 的一切准备工作( 例如为获得输入数据进行的调查、统计和计算) 同样的道理， 对系统应该只描述其外部可见的行为，即与角色的要求直接有关的高层系统功能， 不必详细地描述为完成这样的功能雨进行的大量内部工作实际上。定义u s ec a s e 的工作一般是在分析工作开始时进行的，此时分析员还没有完全了解系统应设立 哪些成分以及它们之间的行为依赖关系，他们只能从系统的最高层次( 即最接近 角色的层次) 来观察和描述系统功能。 ( 5 ) u s e c a s e 对角色和系统双方行为的描述应力求准确、清晰再不引起误 解的前提下允许用比较简练的语言来概括地说明每一方的行为，但这种概括的最 大限度是，不要把双方的行为混在一起不分彼此。就是说至少要把交互过程中 每一个“回合”的角色切换都表现出来 u s e c a s e 的特征： u s ec a s e 具有以下的特征： ( i )u s e c a s e 一般总由角色初始化 u s ec a s e 所代表的功能通常必须由角色激活，而后才能执行。一般情况下， 角色可能并没有意识到初始化了一个u s e c a s e 。换句话说，角色需要系统完成的 功能，其实都是通过u s ec a s e 具体完成的，角色一定会直接或间接地命令系统执 行u s e c a s e ( 2 )u s ec a s e 为角色提供值 u s e c a s e 必需为角色提供实在的值，虽然这个值并不总是重要的，但是能被 角色识别。 ( 3 )u s ec a s e 具有完全性 u s ec a s e 是一个完整的描述虽然编程实现时，一个u s ec a s e 可以被分解为 多个小u s ec a s e ，每个小u s ec a s e 之问相互调用执行，一个小u s ec a s e 可以先 执行完毕，但是该小u s ec a s e 执行结束并不能说这个u s ec a s e 执行结束。也就 是说，不管u s ec a s e 内部的小u s ec a s e 是如何通信工作的，只有最终产生了返 回给角色的结果值，才能说u s ec a s e 执行完毕。 u s ec a s e 和角色之间也有连接关系。u s e c a s e 和角色之间的关系属于关联， 又称作通信关联这种关联表明哪种角色能与该u s ec a s e 通信关联关系是双向 1 0 茎王圣翌! 里些旦苎里竺! 鬯堕垄墨些 的一对一关系，即角色可以与u s e c a s e 通信，u s ec a s e 也可以与角色通信a u s e c a s e 的表示 统一建模语言u m l 中的u s ec a s e 用椭圆形表示，u s ec a s e 的名字写在椭圆 的内部或下方。u s ec a s e 位于系统边界的内部。角色与u s e c a s e 之间的关联关系 用一条直线表示，如图1 - 2 所示。 u s e c a s e 之间的关系 图i - 2 u s e c a s e 示例 u s ec a s e 之间有扩展和使用两种关系扩展和使用是继承关系( 即通用化关 系) 的另一种体现形式 1 扩展关系 一个u s ec a s e 中加入一些新的动作后则构成了另一个u s ec a s e ，这两个u s e c a s e 之间的关系就是通用化关系，又称扩展关系。后者通过继承前者的一些行为 得来。前者通常称为通用化u s ec a s e 后者常称为扩展u s ec a s e 扩展u s ec a s e 可以根据需要有选择地继承通用化u s ec a s e 的部分行为扩展u s ec a s e 也一定 具有完全性。由于u s e c a s e 的具体功能通常采用普通的文字描述( 书写) ，因此， 从文字中划分哪些行为是从通用化u s ec a s e 中继承而来的，哪些行为是在u s e c a s e 中重新定义的( 作为u s ec a s e 本身的具体行为) ，哪些行为是添加到通用化 u s ec a s e 中( 扩展通用化u s ec a s e ) 的，都比较困难。 引入扩展u s ec a s e 的好处在于：便于处理通用化u s ec a s e 中不易描述的某些 具体情况：便于扩展系统，提高系统性能，减少不必要的重复工作。u s ec a s e 之 间的扩展关系可图示为带版类( e x t e n d s 的通用化关系，如图1 3 所示： 基占 茎王兰墅坐些主型! ! 竺竺! 里堕丝茎些一 圈i - 3 扩展关系示例 2 使用关系 一个u s ec a s e 使用另一个u s ec a s e 时，这两个u s ec a s e 之间就构成了使用 关系一般情况下，如果若干个u s ec a s e 的某些行为都是相同的，则可以把这些 相同的行为提取出来单独做成一个u s ec a s e 。这个u s ec a s e 称为抽象u s e c a s e 。 这样，当某个u s ec a s e 使用该抽象u s ec a s e 时，就好像这个u s ec a s e 包含了抽 象u s e c a s e 的所有行为u s e c a s e 之间的使用关系被图示为带版类( u s e s ) 的通 用化关系，如图i - 4 所示： 系统 圈i - 4 使用关系示例 系统是u s ec a s e 图的另一个组成部分，代表的是一部机器或一个商务活动等 等，而并不是真正实现的软件系统系统的边界用来说明构建的u s ec a s e 模型的 应用范围。比如，一台自助式售货机( 被看作系统) 应提供售货、供货、提取销 售款等功能，这些功能在自动售货机之内的区域起作用，自动售货机之外的情况 不考虑。准确定义系统的边界( 功能) 并不总是容易的事，因为严格地划分哪种 任务最好由系统自动实现，哪种任务由其它系统或人工实现是很困难的。另外， 系统最初的规模应有多大也应该考虑。一般的作法是。先识别出系统的基本功能 ( 集) ，然后以此为基础定义一个稳定的、精确定义的系统架构，以后再不断她扩 基于z 对u m l 中u s e c a s e 图的形式化 充系统功能，逐步完善。这样作的好处在于避免了一开始系统太大，需求分析不 易明确，从而导致浪费大量的开发时间 u s e c a s e 图中的系统用一个长方框表示，系统的名字写在方框上或方框里面， 方框内部还可以包含该系统中的用符号表示的u s ec a s e 比如图l - 5 中的自动售 货系统，表示该系统的方框内还包含了三个u s ec a s e ( 买饮料、供货和取货款) 在u s e c a s e 中，系统仿佛是实现各种u s e c a s e 的“黑匣子”，我们只关心该 系统实现了哪些功能，并不关心内部的具体实现细节( 比如系统是如何做的? u s e c a s e 是如何实现的? ) 。 u s ec a s e 图的表示 图示u s ec a s e 图时，既要画出三种模型元素，同时还要画出元素之间的各种 关系，如图1 - 5 所示 自动售货系统 一 一( 一蕊 一( ，葡蔽、 、一 圈i - 5 u s e c a s e 图示倒 该u s e c a s e 图中包括三个角色( 客户、供货人和收银员) 、三个u s e c a s e ( 买 饮料、供货和取贷款) 和一个自动售货系统，角色“客户”与u s e c e “买饮料”、 角色“供货人”和u s ec a s e “供货”以及角色“收银员”和u s e c a s e “取货款” 之间有关联关系。 u s e c a s e 图的作用及应用范围 u s e c a s e 图在建模过程中居于非常重要的位置，影响着系统中其它视图( 比 如交互图) 的构建和解决方案( 满足基本功能需求) 的实现概括起来，u s ec 船e 图的主要作用如下； 1 3 基于z 对u m l 中u s e c a s e 圈的形式化 确定系统应具备哪些功能，这些功能是否满足系统的需求( 开发者与用户 协商达成共识的东西) 为系统功能提供清晰一致的描述，以便为后续的开发工作打下良好的交流 基础，方便开发人员传递需求的功能。 为系统验证工作打下基础。通过验证最终实现的系统能够执行的功能是否 与最初需求的功能相一致，保证系统的实用性和正确性。 从需求的功能( u s ec a s e ) 出发，提供跟踪系统中具体实现的类的方法。 提供检查实现是否正确的能力。特别是为复杂系统建模时，常用u s ec a s e 图构造 系统的简化版本( 也就是精化系统的变化和扩展能力，使系统不要过于复杂) 。然 后，利用该u s ec a s e 图跟踪对系统的设计和实现有影响的u s ec a s e 。简化版本构 造正确之后，通过扩展完成复杂系统的建模 u s ec a s e 图主要应用在软件开发的初期。进行需求分析时使用通过分析描 述使开发者在头脑中明确需要开发的系统功能有哪些，为将来的开发工作奠定基 础另外它还可以用在软件测试阶段，用以验证被测试的实际系统与其u s ec a s e 图中说明的功能( 集) 是否一致 u s ec s s e 图的不足之处 u s ec a s e 图是一种可视化图形，它在宏观上给出u s ec a s e 模型的总体轮廓。 u s ec a s e 图所表示的可视化模型本身并不提供u s e c a s e 模型必需的所有信息也 就是说，从可视化的模型只能看出系统应具有哪些功能，每个功能的含义和具体 实现步骤必须使用普通的文字书写这样就有可能造成功能描述的模糊性和二义 性，为以后的开发工作和系统测试及验收带来困难，为了能得到一个精确严格的 功能说明，我们将形式化方法引入到u s ec a s e 图中。 1 3 小结 在本章中我们首先说明了统一建模语言u m l 的出现、内容、主要特点和应 用领域，对它在软件开发中的地位和作用有了一个较为深刻的认识；然后又具体 对统一建模语言u m l 中的u s e c a s e 图作了重点介绍，介绍了u s e c a s e 图的组成、 表示法以及它的功能和应用范围，最后还指出了它的不足之处通过本章的学习 我们可知u s e c a s e 图在软件开发中占有重要的地位，但是平铺直叙的文字描述会 给软件的开发带来很大的困难，所以我们提出了形式化方法和u s ec a s e 图相结合 的方法在下一章中我们将对形式化方法作一简单介绍。并选择一种软件规约语 1 4 苎王兰型坐些主坐! 鱼苎里塑垩苎些一 言用以实现u s ec a s e 图的形式化描述 苎王! 堕坐些竖垒兰璺些丝茎些 第二章形式化方法和z 语言 形式化方法能产生严密、精确的规格说明。为软件开发提供严格的数学基础 z 语言是一种常用的形式化语言，在工业界和学术界得到了广泛的应用。曾被称 为“软件工程语言” 2 1 关于形式化方法 形式化的重要意义 三十多年来，计算机软件发展迅速，重要性与日俱增，但其现状还不能令人 满意，主要问题是：软件整体功能不强，缺乏智能；质量欠佳；生产效率低为 了解决上述向题，需要采取改进传统技术与发展新技术的方法 非形式的自然语言主要用来书写系统开发者与用户之间的协议和系统的开 发文档。为了实现符合要求的软件系统，为了保证软件产品的可靠性，规格说明 应具有可理解性和精确性，这是程序实现的基本保证形式化的规格说明语言避 免了自然语言的歧义性和不精确性，奠定了保证程序的正确性的各种形式化方法 的基础 软件开发过程自动化的技术是提高软件生产率的根本途径之一实现软件开 发过程各阶段的自动化是软件工程的重要目标之一软件自动化的前提是形式化， 形式化软件规格说明不仅是对用户需求，也是对软件系统的严格定义，在软件开 发中有着相当重要的作用另一方面，为了提高软件生产率，便于从软件规格说 明自动或者半自动地导出正确的程序，对软件规格说明语言相应地提出了新的需 求，即要求它不仅要能适合描述大型软件，便于用户使用，以及利于软件产品的 可靠性，而且还要有利于机器的自动处理。 因此，将形式化的理论和方法用于需求分析与规格说明极为必要，也是实现 软件自动化生产的根本前提 一形式化方法和形式化规格说明语言的发展状况 形式化方法的研究和应用已有3 0 多年的历史了。最初的产生是由d i j k s t r a 和 h o a r e 在程序验证方面的工作和s c o t t ，s t r a t c h e y 以及其它学者在程序语义方面的 1 6 薹! 壁! 塑些! 兰竺! 兰望竺壁墓些一 工作基础上发展起来的。 由于软件规格说明的重要性，国际上对软件规格说明方法和软件规格说明语 言进行了广泛的研究。在软件开发过程中，用户需求的规格说明非常重要其使 用者包括用户、系统分析员、设计与编程人员、测试人员验收人员规格说明对 这些人来说是一个可靠的参照点；系统分析员接受用户的需求，产生目标软件系 统的规格说明；设计与编程人员根据规格说明，进行模块设计并产生最终程序代 码；测试人员和验收人员验证最终程序代码是否满足规格说明非形式化规格说 明具有易读、易理解的优点，但是它通常具有歧义性，这往往引起规格说明的使 用者们对同一规格说明产生不同的理解，最终导致用户对已完成的系统产生不满 传统的软件开发方法由于采用不严格的非形式技术来描述目标软件系统的规格说 明。它很难得到计算机的有效支持，显然，这对提高软件质量和生产率不利 为了克服这些缺陷，人们提出了一种新的软件开发范型，即通过严格的、规 范化的数学理论来描述“傲什么”，这就是形式化方法分析与规格说明方法而形 式语言指的是语法和语义均显示和精确定义的语言。形式化方法的基本含义是借 助数学的方法来研究计算机科学中的有关问题形式化方法是基于数学方法来描 述目标软件系统性质的一门技术，用严格的数学符号和数学法则对目标软件系统 的结构与行为进行有效的综合、分析和推理，它为系统的说明、开发和验证提供 了一个框架利于发现目标软件系统需求中的不致性、不完整性等方面。例如 一阶谓词演算便是一种形式化语言，用它书写的规格说明便是形式规格说明。一 阶谓词演算是一个形式逻辑系统，具有一整套证明技术，采