（计算机科学与技术专业论文）场景驱动的需求工程.pdf

独创性声明 本人声明所呈交的学位论文是我本人在导师指导下进行的研究工作及取得 的研究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含 其他人已经发表和撰写过的研究成果，也不包含为获得国防科学技术大学或其它 教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任 何贡献均已在论文中作了明确的说明并表示谢意。 学位论文题目：塑量堕边曲蛊塞王堡 一 学位论文作者签名：! ! l 蛰 日期：】年。月一f 日 学位论文版权使用授权书 本人完全了解国防科学技术大学有关保留、使用学位论文的规定。本人授权 国防科学技术大学可以保留并向国家有关部门或机构送交论文的复印件和电子 文档，允许论文被查阅和借阅；可以将学位论文的全部或部分内容编入有关数据 库进行检索可以采用影印、缩印或扫描等复制手段保存、汇编学位论文。 ( 保密学位论文在解密后适用本授权书。) 学位论文题目：垃量塑边煎孟垄三焦 学位论文作者签名 作者指导教师签名 虱垫 日期：加j 年，j 月，f 日 日期：2 。 年f ，月，、r 日 埠易一 国防科学技术大学研究生院学位论文 摘要 随着软件需求工程的发展，基于场景的需求获取逐步得到了人们的重视，因 此出现了基于场景的需求获取方法及工具。本文研究了一种基于场景的需求获取 方法，该方法用于获取反应式系统的行为需求，并根据上述思路，设计和实现了 一个需求获取和分析工具。用这个工具用户直接从系统的原型g u i 界面取“p l a y i n ”场景，并且可以“p l a yo u t ”这些场景，从而获取并确认需求。在相应工具的 支持下，通过p l a yi n 场景，自动生成用形式化规约描述语言l s c ( l i v es e q u e n c e c h a r t ) 描述的需求规约；通过p l a yo u t 过程，g u i 根据规约的u n i v e r s a l 部分做出反 应；同时通过监控规约的e x i s t e n t i a l 部分检查系统的执行情况。p l a y - i n 是一种高层 次的用户友好的规范系统行为的方法，而p l a yo u t 允许用户通过直接操作g u i 确认 需求。这种基于场景的需求获取方法提高了需求获取和确认能力，有利于开发人 员在系统开发的各个阶段之间进行平滑而严格的转换。 关键词：需求工程，场景，需求获取，需求确认 里堕型兰垫查奎兰翌至生堕兰垡堕苎 a b s t r a c t s c e n a r i o 。b a s e da p p r o a c h e sh a v ea t t r a c t e dc o n s i d e r a b l ea t t e n t i o ni 1 1r e q u i r e m e n t e n g i n e e r i n g t h i s t h e s i s p r e s e n t s a p o w e r f u lm e t h o d o l o g y f o r s p e c i f y i n g s c e n a r i o b a s e dr e q u i r e m e n t so fr e a c t i v es y s t e m s ，i nw h i c hb e h a v i o r sa r e p l a y e di n d i r e c t l yf r o mt h es y s t e m sg u io rs o m ea b s t r a c tv e r s i o nt h e r e o f , a n dc a nt h e nb e “p l a y e do u t ”at o o ls u p p o r t st h em e t h o dm e n t i o n e da b o v ei sa l s od e v e l o p e d a st h e r e q u i r e m e n t sa r eb e i n gp l a y e di n ，t h et o o la u t o m a t i c a l l yg e n e r a t e saf o r m a lv e r s i o ni n t h el a n g u a g eo fl i v es e q u e n c ec h a r t s ( l s c s ) a st h er e q u i r e m e n t sa r ep l a y e do u t ，t h e t o o lc a nm a k et h ea p p l i c a t i o nr e a c ta c c o r d i n gt ot h eu n i v e r s a lp a r t so f t h es p e c i f i c a t i o n ， a n dt h ee x i s t e n t i a lp a r t sc a nb em o m t o r e dt oc h e c kt h e i rs u c c e s s f u lc o m p l e t i o n p l a y i n i sau s e r - f r i e n d l ya d v a n c e dm e t h o do fs p e c i f y i n gb e h a v i o ra n d p l a y - o u ti san o v e lw a y o fw o r k i n gw i t l laf u l l yo p e r a t i o n a ls y s t e md i r e c t l yf r o mi t si n t e r o b j e c tr e q u i r e m e n t s t h ei d e a sa p p e a rt ob er e l e v a n tt om a n ys t a g e so fs y s t e md e v e l o p m e n t ，i n c l u d i n g r e q u i r e m e n t se n g i n e e r i n g ，s p e c i f c a f i o n ，t e s t i n g ，a n a l y s i sa n di m p l e m e n t a t i o n k e yw o r d s ：r e q u i r e m e n te n g i n e e r i n g , s c e n a r i o ，p l a y i n ，p l a y - o u t , l s c i i 垦堕型兰垫查查兰竺窒生些兰竺堡苎 第一章绪论 1 1 研究背景 需求工程( r e q u i r e m e n t se n g i n e e r i n g ，r e ) 是随着软件工程的发展而产生的。 在软件开发的初级时期，软件规模不大，软件开发所关注的是代码编写，需求分 析很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为软件生命 周期的第一阶段。随着软件系统规模的扩大和“软件危机”带来的软件工程的发 展，需求分析与定义在整个软件开发与维护过程中越来越重要，人们普遍认识到 研究需求可以避免系统开发时的盲目性。随着软件工程的研究和应用的逐渐深入， 人们同时认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开 发的整个生命周期。 需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求， 帮助分析人员理解领域相关问题并定义目标系统所有外部特征的一门学科；它通 过相应的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求 文档，并对用户不断变化的需求( 演化需求) 给予支持。需求工程可分为系统需 求工程( 如果是针对由软硬件共同组成的整个系统) 和软件需求工程( 如果仅是 专门针对纯软件部分) 。软件需求工程是一门分析并记录软件需求的学科，它把系 统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通 过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软 件的需求描述和一些性能参数。 软件需求阶段一般指从用户提出软件开发请求到形成软件功能规约的开发过 程，以产生功能规约为结束标志，是软件开发过程中的第一个技术性阶段。文献 中常常将需求阶段分成需求分析和功能规约两个子阶段。前者侧重予从用户获取 需求并进行分析、整理，产生需求定义。后者在此基础上，抽取其中有关功能的 需求，产生功能规约。需求定义是软件需求的完整叙述，是开发者和用户之间对 最终产品的功能和性能等方面达成的共识和契约，它对软件产品质量及其开发费 用都具有重要影响。 2 0 世纪7 0 年代以来，软件工程研究人员提出了一系列软件需求分析技术和 方法。大致可分为4 类：面向过程的分析方法，面向数据的分析方法，面向控制 的分析方法，面向对象的分析方法。o o s e 是j a c k s o n1 9 9 2 年提出的用例驱动的 面向对象的开发方法。用例图现已成为标准建模语言u m l 的一部分。用例( u s e e a s e ) 是指用户使用系统时所执行的一个与行为相关的事务序列，这个序列是在 与系统的对话中完成的。我们也常常提及与此类似的一个概念：场景( s c e n a r i o ) 。 但是在已有的研究成果中，场景和用例这两个术语的含义有时是一致的，有时则 把场景定义为用例的一个特定实现。所谓软件需求的场景，简单地说，就是软件 在某个或某类特定使用情形下的需求。一个有意义的场景应该具有如下内容： 1 使用者：场景具有一个或一类特定的软件使用者，该场景是从该使用者的 角度对软件需求的描述； 2 使用目的：场景具有一定的使用目的，它是围绕使用者为达到一定的使用 目的以及所需完成的任务对软件需求的描述； 国防科学技术大学研究生院学位论文 3 使用条件：场景是在特定的使用条件和特定参数下对软件需求的描述。 场景在需求分析与定义中的作用主要有两方面：一是需求获取的手段，二是 分析需求定义的手段。作为获取需求的手段，可以在形成完整的需求模型之前或 者构造需求模型的过程中首先设定一批场景，并对这些场景所需软件的功能、使 用方式以及限制进行描述，然后，以这些场景的描述为依据，综合出完整的需求 定义。作为分析需求定义的手段，在形成了完整的软件需求模型之后，可以选择 一批使用场景，根据场景对获得的需求进行测试和分析，分析需求定义中的错误 和不足之处。除此之外，需求场景还对软件开发后继阶段有所帮助，例如作为功 能测试数据选择和验收测试的依据。 通过对场景的分析可以使需求获取和分析工作系统化、有序化。与分析和描 述整个系统相比，在特定场景下对软件需求进行分析与描述更为简单容易。然而， 如何保证场景描述之间的一致性，如何从场景的描述获得整个系统的需求模型则 是基于场景的需求分析方法的关键，近年来受到人们的重视。 任何严格的建模方法都需要对建模结构定义严格的语义，特别是模型的行为 部分和它们的连接结构。严格的语义使执行模型和运行从此产生的代码成为可能。 目前的一些工具，如i l o g i x 公司的s t a t e m a t e 工具和r h a p s o d y 工具，以及r a t i o n a l 公司的r o s er e a l t i m e ，都能产生高质量代码，能够以较高的质量实现一些反应 式系统。 在支持面向对象建模的语言的发展方面，r a t i o n a l 公司在1 9 9 7 年推出了u m l 对象建模语言，软件工业界对此表示了极大的关注和参与热情，并且围绕它开展 了广泛的软件环境的研究和开发工作。作为面向对象系统分析和设计的建模语言。 u m l 己经成为事实上的工业标准。 1 2 课题的目标 本文研究了一个通用的需求获取方法，这种方法直接从一个用户友好的系统 界面获取需求，即场景的p l a y - i n ，通过一种描述消息序列的语言获得到完全的系 统模型，并且得到最终的可执行系统进行需求验证。重点是如何获取需求并根据 需求迭代式地确认需求以及通过语言、方法和工具，保证方法应用中各阶段之间 进行平滑而严格的转换和过渡。 本文的主要工作是： 1 研究了一种基于场景的需求获取方法：用户可以直接从被开发系统的g u i 界面p l a yi n 场景，从而获取需求，然后p l a yo u t 这些场景对需求进行确认。该方 法用一种比u m l 的序列图以及i t u 的m s c 表达能力更强的图形语言l s c ( l i v e s e q u e n c ec h a r t s ) 来描述场景，l s c 能区分出用户期望发生的场景和禁止发生的 场景。 2 设计并实现了相应的支持工具原型。其目标和该工具的主要作用是：通过 操作g u i 直接建立场景：自动生成需求规约；支持需求的回放。 1 3 论文的组织结构 在第2 章，综述了现有的基于场景的需求分析方法：第3 章描述了l i v e s e q u e n c e c h a r t s 语言。这种语言比u m l 的序列图以及r r u 的m s c 表达能力更为 强大，能区分出用户期望发生的场景和禁止发生的场景；在第4 章，研究了p l a y i n 里堕型兰垫查盔兰竺窒生堕兰垫丝苎 和p l a y - o u t 方法的基本原理和实现机制；第5 章中，描述了支持p l a y i n 和p l a y - o u t 方法的工具的设计与实现；在第6 章中，总结本文的研究成果，提出了进步的 研究工作和主要方向。 里堕型兰垫查盔兰堕窒竺堕兰堡笙苎 第二章基于场景的需求分析 2 1 场景 一个场景是指“一种可能发生在几个对象间有目的的交互行为”。它由一个 或者多个动作组成，每个动作表示一个对象和另一个对象之间的一次交互。在一 个场景中一系列动作的组合描述了一条唯一的路径。场景可以用初始状态和终止 状态作为其区别特征。一个场景的初始状态定义了触发这个场景的前提条件。而 终止状态则定义了这个场景结束时的状态。场景分为两种：普通场景和异常场景。 前者可以实现既定的目标，而后者则表示了特定的异常情况。 作为需求工程的发展成果，基于场景的需求获取逐步得到了人们的重视。基 于场景的需求获取过程要通过捕捉用例、场景、上下文的叙述性说明，用例以及 对象行为的实例说明，最终得到系统的完整需求。场景在需求过程中，可以在预 想情况下导出需求【7 】，帮助发现异常事件5 6 】f 2 0 1 ，获得面向对象概念模型f 5 7 】【5 】 1 “， 通过场景原型理解需求【1 5 】，说明设计结果 2 l 】1 2 2 1 ，创建设计上下文1 8 等等。 工业界的实践，如c r e w s 组织的工作，也证实当抽象的建模失败时，场景 就变得特别有用p 。 此外，因为场景描述了具体的行为，它们捕捉了实际的需求。然而，正因为 场景处理的是实例和示例，则注定它的描述是不完全的，只能提供有限的需求， 从而需要进行归纳得到完备的需求。 根据开发目的不同，场景的表示法经常包含不同的内容，表示在不同的抽象 层次上，同时可以用不同的符号表示。 考虑到开发的目的，场景可以是描述性的( d e s c r i p t i v e ) ，解释性的 ( e x p l a n a t o r y ) 或探索性的( e x p l o r a t o r y ) 。 在描述性的场景中1 7 j ，分析者和用户通过遍历这个场景，理解它的操作、角 色、触发过程的事件等等，这样来捕捉需求。因此，通过描述性场景的辅助，可 以了解一个过程是如何执行的，谁参与了这个过程以及这个过程激活以后是如何 动作的。 解释性场景【l 】要求识别发生的事件，事件发生原因及后果，什么是通常发生 的事件及处理方法。 探索性场景可以帮助了解要开发的系统的期望特征，比较给定系统各种可能 解决方案i l ，对它们进行检查和评估，最终找到正确解决方案。这些场景在需求 和期望的解决方案之间建立了直接的联系。 场景可以在三种不同的抽象层次上表示：实例、类型和混合型。 在已有的工作中，c a r o l l ，p o t t s 等使用特定实例场景，说明发生了什么，为 什么发生以及如何发生【2 1 】【7 】【2 2 1 。而类型场景【1 5 】1 1o 】不使用单个的实体，而使用实 体的类型，一个类型场景的一次执行表示一个实例场景。而混合场景是指那些部 分在实例层次，部分在类型层次的场景1 5 0 1 。 场景可以用不同的符号( 语言) 表示，可以是非形式化语言，半形式化语言 以及形式化语言。非形式化的场景使用自然语言，图象或者描述表达，适用于不 愿意或者不能处理形式化符号的用户群。半形式化的场景使用结构化的符号例如 表1 7 】和场景脚本【4 1 来捕捉实际的动作。形式化的场景用基于规范文法的建模语言1 1 或者状态图【l 来表示。 里堕型兰垫查查堂堑塑生堕差竺丝茎 使用例子、上下文叙述性说明、实体模型以及原型等方法描述需求，在需求 工程、人机交互以及信息系统开发中已经得到了相当的重视。大体而言这些方法 都可以称作基于场景的方法，当然，各有侧重不同。快速原型的系统开发也指出 了基于场景开发的有效性。最早一个的有效的基于场景的设计实例是i b m 为l o s a n g e l e so l y m p i c s 开发的语音信息系统u6 1 。从那以后，产生了多种场景的表达方 法，对场景的解释取决于它们的用法以及它们是如何产生的。 h c ic o m m u n i t y 提议场景用详细的文本进行描述【”j 。在软件工程领域“用例” 是面向对象的设计中对用法、职责和服务做非正式的叙述性的描述【l0 j 【l ”。而且， 在需求工程中，为检查一个需求规约和用户或者环境之间的关系，场景脚本可以 作为测试数据。 2 2 基于场景的需求分析 近来，场景的使用引起了需求工程界、软件工程界、人机交互界的高度关注。 在开发计算机系统过程中人们提出了大量基于场景的方法，强调了一种更加面向 应用的视点场景，描述系统与环境的交互行为。 在需求分析中使用场景进行分析的方法源于o b j e c t o r y 并且应用在o b j 中【4 j 。 j a c o b s o n 等提出第一个用例驱动的面向对象的分析过程模型【t o 。r e g n e l l 进一步发 展了这个模型【6 】，其中强调了从场景中综合需求模型的重要性。在文献 7 】中，提 出了i n q u i r y c y c l e 方法，在面向目标的需求分析中，使用场景脚本识别障碍和问 题。文献 1 9 1 中提出的s c r a m 方法结合了概念证明，场景和设计的基本原理。 它以一种预演的方法应用场景脚本，验证了脚本关键点的设计选项。最近，基于 i n q u i r yc y c l e 和s c r a m 2 训中提出了一种基于场景的需求工程方法，可以和面相 对象的开发相结合，这个方法包括四个阶段：a 、引出和分类用例，b 、分析普遍 的问题和需求，c 、产生场景，d 、用场景验证系统需求。 k y n g 的方法捧j 牛，认为原型和场景可以支持设计过程中的各个步骤。在设计过 程中用到的s u l n l n a r i e s ，w o r ks i t u a t i o nd e s c r i p t i o n s ，u s es c e n a r i o s ，m o c k u p s 和 p r o t o t y p e s ，e x p l o r a t i o n r e q u i r e m e n ts c e n a r i o s 以及e x p l a n a t i o ns c e n a r i o s 都可视为一 种场景。 p o t t 的方法pj 是需求工程中基于场景方法的代表，提出了一种相当完全的需 求分析模型支持建档和需求演化。 b e n n e r 等【l 剐通过强调场景的特点给出了一个场景定义，即某种非形式化的场 景符号的原模型。但没有阐述一个场景不同的形式的问题。他给出了一些例子， 使用多种的媒体( 文本、图象、原型) ，多种符号层次( 从非形式化的文本到形 式化规范的场景) 以及大量的叙述( 从静态到活跃、从没有交互性到高交互性) 来表示场景。 g o u g h 等对j a c o b e o n 【l0 】基于用例的0 0 s e 方法提出了一个扩展【2 3 】。该扩展主 要反映在两个方面： 1 场景的可视化表示，用于显示事件和动作间的时间序列和工作流。 2 问题领域的超文本可视化。场景可以用文本，图像和原型表示，可以通过 超文本连接，激励场景并与之交互。 h o l b r o o k 提出一种方法学，在场景的帮助下引出需求方法。这个方法学基于 一种概念体系结构，在场景和目标及问题集之间建立联系。它在一个s b r e ( 基于 场景的需求获取) 工具中实现，支持超文本结构，帮助决策者精化对需求的理解。 h o l b r o o k 的场景既可以用文本说明系统快照，也可以是动画的仿真( a n i m a t e d 国防科学技术大学研究生院学位论文 s t i m u l a t i o n ) 。h o l b r o o k 定义的场景为一种规约：它捕捉系统如何对环境作出 反应。 h s i a 等提出了一种传统的场景的产生和分析的形式化方法。这些场景用一个 形式化语言描述，并给出了相关术语。h s i a 的形式化场景不是可以执行的( 这就 限制了它们在需求获取和确认中的作用) ，但是应用了更多传统的验证技术检查 场景一致性。场景的内容的核心在系统交互上，着重于描述行为。h s i a 提出的过 程模型【15 】中，场景的作用贯穿于从需求获取到验收测试。但是它并没有说明如何 在需求工程中结合场景分析。 r e g n e l l 的方法 6 1 是j a c o b s o n ”】提出的用例驱动的方法的扩展。相对于 j a c o s b o n 的方法有几点不同： 这种方法提出了用例的两个层次：用例描述与用例规约。用例描述给出了一 个更为形式化的符号( 相对于j a c o s b o n 用例) 。用例规约用来精化用例描述。事 件、条件和问题领域对象是用例描述中的概念。用例规约中只使用事件，原子操 作和抽象接口对象，分别用结构文本和媒体描述用例描述和用例规约。类似 l a c o s b o n 的方法，r e g n e l l 的用例侧重于系统和环境之间的交互，而在用例规约中， 通过原子操作捕捉系统内部( s y s t e mi n t e r n a l ) 的交互。用例描述仅仅用来产生用 例规约。用例规约可以服务于建立设计模型。 在o m t 5 1 中，场景以文本形式出现，规定为一个事件序列。它们可以转化到 里堕型兰垫查奎兰竺耋生堕兰堡笙奎 一个事件图中，保持一种半形式化的表示；不支持a n i m a t i o n 和交互活动。在文献 2 5 中，区分了用例和场景。用例包括选项，迭代，参数等。而场景是一个特别 的事件，是用例的一个特殊的路径或者实例。此外，用例和场景中设计的实体描 述为类型而不是单个的对象和角色。r u m b a u g h 等定义场景只是为了描述从外部 世界到系统的交互( 在它的场景使用规则中第步是设定系统边界【”j ) 。r u m b a u g h 扩展了场景的用法，用它们来构造动态模型。在文献( 9 】中，o m t 场景已经用于 创建基本对象模型。它覆盖了功能需求的结构，功能和行为需求方面，但不支持 内部非功能性内容的描述。 b s c a l z o 的方法口】贝0 使用一种半形式化表示方法。它以预先定义好的模板用 符号描述场景，叫做用户行为图( 同于o m t 的事件踪迹) 。但没有a n i m a t i o n 类 交互动作。s c a l z o 等把场景定义为一种咨询( i n t e r v i e w ) 格式，通过询问决策者， 谁描述了它们的特别活动或者它们在组织中的位置，由一个分析者来填写。该方 法没有设置系统边界。因而可以在场景中描述系统的内部信息。在咨询格式的模 板中有许多属性可以捕捉场景的上下文。例如，工作和资源的提供者，资源，前 置条件和后置条件等，并不能从明确的属性中清晰地捕捉组织的环境。s c a l z o 描 述了如何从场景中创建结构化，功能化和行为化的模型。 s c a l z o 在任务场景中直接应用了b p r 原则，从中获得新的场景，可以视为场 景重用。场景都综合到一个场景特色表中。除用于重用场景重新设计以外，没有 提及其他的精化或者扩展。 s o m 6 等【3 】提出了一种方法分析场景。用一种结构语言描述场景，并自动综合 它们作为一种用t i m e da u t o m a t a 表示的规约的一部分。这是，场景只能通过它们 的文本表示来了解。他们研究的一个原型产生器，可以以一种动画和交互的方式 执行。这种方法限制了它自身建模系统的内部行为以及发生在与环境进行的交互。 s o m 6 借鉴了b e r m e r l l 8 的观点：场景可以用来表示发生在受限情况( 状态) 下的 偏序行为( 即可能的操作连续序列) 。因此，只考虑了结构和行为。没有提及内 部问题，唯一的非功能化约束是事件约束。 基于场景的需求工程取得了很多成果，但是仍然有以下的问题没有解决： 缺乏工具支持。其主要原因是难于设计一种合适的表示方法来描述场景。一 个合适的场景描述方法至少要满足两个条件，首先要足够简单，让软件工程 师和用户易于理解，其次，不仅要便于需求模型构造，也要便于对场景的形 式化和自动化的分析。尽管已经出现了许多关于用例和场景的表示形式，几 乎都不能同时满足上述两个要求。 缺乏重用的支持。场景驱动的需求工程主要应用于面向对象的分析。这类方 法都依赖于可重用的需求的模型库，利用检索工具根据不同的用例获取不同 的模型库。通过遍历用例中每一个可能的事件序列和应用启发式分析指出在 每一步可能发生的例外和错误来产生场景。一个场景可以定义为一个事件序 列，它是一个用例中的一条可能的路径。 2 3 基于p l a y - i n 和p l a y - o u t 的需求分析方法 面向对象的分析和设计过程中通常要识别两种类型的行为 2 6 】【2 7 】：对象间行 为，它描述了每个场景中对象的交互；以及对象内行为，它描述了单个对象在所 有可能的环境下的表现；对于对象内行为的建模，大多数面相对象的建模方法采 用了状态图，而对于需求方面，则广泛使用消息序列图描述( m s c ) 或者它在 国防科学技术大学研究生院学位论文 u m l 中的变种序列图1 3 4 1 刈进行描述。 多数面向对象的系统开发方法都首先要规范系统的用例【3 “，然后用序列图描 述每个用例的不同实例场景。然后用状态图描述一个类的行为，规定了类的每个 实例的行为，最后用特定的编程语言编写代码，实现这个对象。这些过程中，部 分可咀自动化，在文献 2 7 1 中讨论了这个问题，特别是可以实现从对象模型图和 状态图产生代码。实际上，文献 2 8 】和 3 0 】的主要语言，即对象模型图和状态图， 构成了u m l 的核心可执行部分。 用序列图规范需求和实例化用例产生了很多问题。序列图只有极弱的偏序语 义，比时序逻辑或其他形式化语言描述需求和约束的能力要弱得多，无法获取系 统完全的行为需求。为了解决这个问题，同时保留这种基于场景的可视化形式。 1 9 9 9 年，在文献 2 6 1 中提出了一种对m s c 的扩展语言，l i v es e q u e n c ec h a r t ，简 称l s c 。l s c 区分了系统中可能发生的场景( e x i s t e n t i a lc h a r t ) 和必须发生的场 景( u n i v e r s a lc h a r t ) 。同样，它们也规定了可能接收到的消息( c o l d ) 和必须接收到的 消g ( h o t ) 。一个条件也可以是c o l d ，意思是这个条件可以为真( 否则控制退出当前 框或子图) 。当条件为h o t 时，它就必须为真，否则系统中断。 l s c 的表达能力比m s c 更为强大，因此通过l s c 可以更加严格地表达建模 过程中两种行为的关系，并有可能在它们之间进行转换：一方面是用例和l s c 以 对象间的形式表示了系统的需求；另一方面，状态图以对象内的方式表示了它的 实现模型。可以证明二者是一致的，但是一般要从前者导出后者。文献【2 9 】提出 了一个算法，但是得到的状态图非常庞大； 用例是非形式化的而且是高度抽象的，为此需要一种高层次的规范基于场景 的行为的方法一p l a y i n 场景方法，来获得需求。p l a yi n 场景无需使用任何传统 语言，通过直接操作一个系统接口的模型( g u i ) ，使用一种用户友好的方式获 取期望的和不期望的场景。开发者可以和客户一起完成这个工作，从而加快建模 过程并且排除在开发过程中可能出现的错误。 例如，在开发者的计算机屏幕上有一个应用程序的界面，但没有定义任何行 为。开发者通过点击和拖拽，p l a yi n 场景事件并设置系统相应的反应，指出事件 的c o l d 和h o t 状况，实例事件或者普遍事件等等，建立起场景。这个交互过程包 括对系统结构的不断精化的过程。 随着p l a yi n 需求过程的继续，底层的支持工具将会自动和逐步地产生形式化 的l s c ( 不仅仅是m s c 或者s c ) 或者时序逻辑公式，它们准确捕捉了已经p l a y e d i n 的场景。无需使用抽象的面向特定领域的语言，而应用一种友好直观的面向用 户的自动过程，构造出严格和复杂的需求。 p l a y i n 场景之后，还要对需求进行确认：证实需求的确反映了用户的要求。 测试的方法之一是构造一个原型，通过执行模型测试l s c 需求规约。p l a y i n o u t 机制不仅可以规范需求，同样可以进行需求的测试和确认。在应用p l a y o u t 的时 候，可以随意地操作g u i ，好像使用最终的系统一样，观察系统的反应是否和期 望的一致。通过p l a y o u t ，我们可以直接地执行需求，而不需要建立或者综合出 一个系统模型。 下图表示了个完整的系统开发过程： 国防科学技术大学研究生院学位论文 0 0 d e l s c so rt e m p o r a lt o g i c ) ( x u m lo rs a t s d ) 图2 2 系统开发的过程思想【5 3 国防科学技术大学研究生院学位论文 第三章l s c 的概念和应用 3 1l s c 的背景 通信软件开发广泛应用了m s c ( m e s s a g es e q u e n c ec h a r t ) 描述场景，理解软 件的使用过程，获取对象间典型的交互。m s c 在系统开发早期特别有用，因此i t u 提出了m s c 标准并不断对其进行修改以适应实际需要。除此之外，文献 1 7 】， 2 9 】， 【1 0 】也提出了m s c 语法和语义的严格定义；同时，为了支持利用m s c 进行分析， 许多机构也开发了相关的m s c 分析工具p 6 j 【j ”“。 尽管m s c 得到了广泛的应用，但是m s c 本身存在一些不足。如：一个m s c 规约是否描述了系统所有的行为? 或者只是描述了一个系统的一些样本行为? 通 常，m s c 只是用来捕捉相应的用例的一些样本场景【lo 】l ”j ，随着系统模型的精化 和对用例的理解深入，已有的系统描述必须解决一个需求描述问题：可能性 ( e x i s t e m i a l ) 视点和必然性( u n i v e r s a l ) 视点之间的转换。前者说明当某个条件 为真，则此场景可能发生；而后者指出，如果刻划该用例的条件为真，系统则必 须执行图中描述的这个场景。因此，我们希望能够规范场景的活性( 1 i v e n e s s ) ， 即强制性的行为。 实际上，一个基本m s c 图( b m s c ) 本身也存在可能性和必然性之间的混淆： m s c 的消息序列没有说明描述的是时间偏序约束，还是消息间的因果联系。标准 【5 0 】中仅仅把m s c 的语义视为按时间顺序排列的事件的一种约束，而设计者则希 望根据设计的深入和细化，进一步对消息发收的必然性和可能性作出强求的规定。 i t u 标准中没有考虑对条件多样性的支持，从而无法区分可能性和必然性。因此 在需求和约束表达能力上比时序逻辑或者其他形式化语言要弱得多。 因此，需要扩展m s c 语言，使之具备清晰的语法和完全的语义，才能构造 描述和分析用例和场景的工具。 面向对象的规约必须解决如何在对象间规约和对象内规约之间建立联系。对 象间规约通常用于开发早期阶段的系统行为规约，根据时间顺序，线性地规范了 过程和对象实例之间的交互关系，描述用例和场景。m s c 很适合描述这种规约。 对象内规约是对象行为建模的最后阶段的结果，即每个对象实例完全的行为规约， 包括每个实例在所有可能条件下和“情节”中的完备的行为描述。目前多数面向 对象建模方法采用状态机语言( 如状态酬怫】1 2 0 】) 来描述对象内部行为。之所以用 一个状态机对象内模型作为设计阶段的输出，目的是软件实现的自动化：最终软 件是由每个过程或者对象的代码组成。这些代码必须支持用m s c 规范的场景。 从m s c 中综合出状态图是系统开发的可靠性和自动化方面的重大进步。目前已 经有不少这方面的算法1 4 0 1 1 4 1 4 2 1 1 4 4 。但是通过一种更为强大的语言可以更深入地研 究并更好地解决这个问题。 因此，d a n l l n 和h a r e l 等在1 9 9 9 年提出了一种新的称为l i v es e q u e n c e c h a r t s ( l s c s ) 2 6 1 的语言，l s c 是对m s c 的扩展，区分了系统中可能发生 ( e x i s t e n t i a l ) 和必须发生( u n i v e r s a l ) 的场景，同样也规范了可以接收到( c o l d ) 和必须接收至l j ( h o t ) 的消息。一个条件可以是c o l d 或者h o t ，前者意味着它可以为 真( 否则不执行当前的图) ，后者则说明它必须为真( 否则系统中断) 。此外， 实例的运行可以定义为h o t 从而迫使它继续向前执行，而当实例的运行为c o l d ， 则实例可以停留在它当前的运行位置上。所以l s c 可以表示禁止出现的行为 里堕型兰垫查盔兰竺壅圭堕兰垡丝苎 ( a n t i s c e n a r i o s ) 。 在本文后面的章节里，描述了一种用p l a y i n p l a y o u t 方法进行需求的获取和 确认。其中，p l a y - i n 机制可以让用户直接从一个g u i 或者一个对象模型图中 “p l a y i n ”场景，并通过相应的工具自动生成l s c 需求规约；而用户可以利用 p l a y o u t 机制，直接执行给定的l s c 需求规约，而不需要建立或者导出一个包括 状态图和代码的系统模型。而且，p l a yo u t 中的行为不一定就是p l a yi n 的行为。 用户不仅可以追踪场景，还可以根据自己的需要自由地执行需求。这样就可以在 整个开发周期中利用l s c 。如同其他的许多面向对象的方法，用户首先规范系统 的用例，然后用序列图实例化这些用例。用例描述了当用户或者外部环境给了系 统一个激励后系统产生的反应可以用u r t i v e t s a l 图表示，而e x i s t e n t i a l 图捕捉那些 系统在特定的条件下完成的暂时行为。转入设计阶段的时候，通过逐渐精化 u n i v e r s a l 图，获得系统的完全行为描述。 在工具的支持下，可以通过执行u n i v e r s a l 图，并监控e x i s t e n t i a l 图进行系统 测试。在后续阶段，每个类的行为用状态图描述，或者用某种语言实现代码。因 为l s c 是可执行的，因此把l s c 及其支持工具相结合可以作为一个通用的需求 执行装置( u n i v e r s a lr e q u i r e m e n t se x e c u t i o nm a c h i n e ) ，模拟实现系统的执行过程。 3 2 用l s c 描述系统的行为 本节首先定义l s c 语言模型，然后简单说明系统开发中如何用支持获取系统 l s c 行为需求规约的工具获取系统的行为规约，最后用列车控制系统的例子简单 解释了l s c 的组成及对系统行为的描述方法。 一个系统可定义为一系列对象和对象之间收发的消息。消息也可以来自外部 环境或者发送到外部环境。用吖表示消息的集合，占表示系统事件( 包括发送和 接收消息) ： s y s = 0 = 0 1 ，0 2 ，o n m = m 1 ，m 2 ， 厶) s = ( e t ，e 2 ，, e 2 k ) = m ( s e n d , r e c v 一个反应式系统的行为需求规范了外部的激励( 如用户动作、来自外界的事 件、时间事件等等) 和系统的反应。在执行需求的过程中，希望能描述最终用户 或者外部环境的激励和可以观察到的系统反应。我们在后面章节中描述的p l a y - o u t 机制采用了这种交互框架。用户通过操作g u i 应用中的对象，模拟最终用户和外 部环境的动作，系统的反应也显示在g u i 对象中。g u i 中各对象的行为可以用 对象的模型进行记录和表示，从而获取系统的完全行为。 相对于状态图或者代码，用对象交互语言如序列图或者m s c 给出的需求很 难执行。状态图描述了对象内部行为，给出了针对每个事件，对象相应的反应。 序列图或者l s c 是基于场景的，没有给出每个对象在某个激励下如何反应。这 是p l a y o u t 机制要解决的核心问题。 为了获取描述系统行为的l s c ，需要使用支持上述的p l a y i n p l a y o u t 过程的 支持工具。这个工具可以称之为p l a y e n g i n e ，它可以完成以下功能，进行需求的 获取和验证： 1 识别一个外部激励并且找出系统所有的需求( 如识别出某个开关的点击事 国防科学技术大学研究生院学位论文 件，并找到所有的需求，从而规范系统对于点击开关时产生的反应) 。 2 用相关的需求创建系统反应序列。包括识别系统做出反应时，相关的附加 需求，并应用之( 如，点击开关后，向控制器发送一个信号，然后发信号给显示 灯，打开显示灯) 。 3 根据需求识别禁止的场景，并且避免产生之f 如，保证如果需求禁止在灯 亮时某个信号的发送，则保证信号不被发送) 。 4 一旦出现了一个禁止的场景，指出这是一个违反( v i o l a t i o n ) 。 5 指示成功完成了一个e x i s t e n t i a l ( p r o v i s i o n a l ) 场景。 一个需求执行机制不断地扫描和监控所有的规则。因此，p l a ye n g i n e 只做那 些要求它做的事情，避免禁止执行的动作。这是保证系统行为服从需求的最低要 求，确保系统不产生错误行为，并发现需求中的矛盾。 l s c 作为一种规约描述语言，其相应的可执行语言必须以严格的方式创建被 建模系统的实例。举例来说，在结构化分析框架下，如s t a t e m a t e ，实例通常对应 活动，而在面向对象框架中，如u m l 或者r h a p s o d y ，它们是指对象实例。此外， 执行语言要把每个实例与其数据空间及其事件进行关联；事件包括发送或接收消 息、超时、对象实例的析构。下面用v a t 表示实例f 的变量，用e v e n t ( i ) 表示它 的事件。变量可以是局部变量，也可以是全局变量。要求v a t 倒包括实例i 所有已 知的变量。 以列车控制系统为例说明： 实例c a r 有以下变量： m o d e p a s s ，s t o p i s e m p t y t r u e ，f a l s e s t a t e i d l e ，d e p a r t u r e ，c r u s i n g ，a r r i v e d ) 对象c a r 可以发送事件s t a r t ，s t o p ，e n g a g e 和d i s e n g a g e 给c r u i s e r ，发送 d e p a r t r e q 和a r r i v r e q 给c a r h a n d l e r 。对象c a r 也可以从p r o x s e n s o r 处接收a l e r t l 0 0 和a l e r t s t o p 事件，从c a r h a n d l e r 处接收d e p a r t a c k 和a r r i v a c k 事件，从c r u i s e r 处接收s t a r t e d 消息。 表3 1 列出了一些事件，其中省略了实例的析构以及定时器的设置和终止。 表3 1 列车控制系统中的事件 消息m s g i d 从实例i 异步发送到 实例- ， 消息m s g i d 从实例i 同步发送到 实例j 实例i 收到来自实例_ 的消息 m s g i d 消息m s g i d 从实例f 异步发送到 外部环境 消息m s g f d 从实例i 同步发送到 外部环境 实例i 收到来自外部环境的消息 m s g i d 系统s 的一个快照s 显示了某个时刻所有可能的事件及所有的变量所赋的值。 里堕型堂堇查奎兰竺壅生堕兰垡笙苎 如果条件e 中涉及到了e v e n t 御( 系统的实例的事件集合) 中的事件或者v a r