（计算机软件与理论专业论文）基于场景的行为模型合成技术研究.pdf

摘要需求工程是软件1 ：程初期的重要工作，其目的是得到对需求的准确清晰一一致的描述以及相应的求解限制。随着需求工程的发展，基于场景的需求获取逐步得到了软件工程界的重视，出现了基于场景的需求获取方法及工具。本文主要钭对需求工程巾场景合成的有关问题进行了探讨，在国内外专家学者对需求获取、用户场景及其合成研究的基础上进行进一步研究分析，确定本文的t i ) f 究重点是：在需求工程中如何利用用户提交的场景进行行为模型合成；对已有的场景处理方案进行分析，引入了改进后的支持状态标签( s t a t el a b e l ) 的消息序列图( m s c ) ；研究行为模型合成算法，将m s c 规约转化为有限状态过程( v s p ) 的形式描述；根据算法设计，初步实现行为模型合成工具。本文研究意义在于：需求工程的发展，使人们认识到，只有最终用户直接参与到软件开发过程并发挥主导作用，才能真正解决问题空间与求解空间的一致性问题，消除计算机领域和应用领域之间的鸿沟，满足并自动适应系统需求的不断变更。改善需求工程的开发质量和效率，需要探索一条有效的解决途径，缩小理论与应用之问的距离，使丌发出来的系统和模型切实满足应用领域的需要。基于场景的行为模型合成，强调用户的参与，有助_ j 二系统丌发人员和用户相互达成一致，并能对用户提供的场景及场景之问的联系进行有效的分析和检测，从而提高需求工程的质量和效率。【关键词】：需求工程，场景，消息序列图，标号迁移系统a b s t r a c tr e q u i r e m e n te n g i n e e r i n g ，w h o s eg o a li st oo b t a i np r e c i s ed e s c r i p t i o no f r e q u i r e m e n ta n dt h el i m i to f t h er e s u l t ，i so f g r e a ti m p o r t a n t a n c ei nt h ei n i t i a ls t a g eo fs o f t w a r ee n g i n e e r i n g a sr e q u i r e m e n te n g i n e e r i n gi sd e v e l o p i n g ，r e q u i r e m e n te l i c i t a t i o nb a s e do i ls c e n a r i o si sg r a d u a l l yt a k e ns e r i o u s l y a n dt h em e t h o d sa n dt o o l sf o rr e q u i r e m e n te l i c i t a t i o nc o m ei n t ob e i n g t h i sd i s s e r t a t i o n ，w h i c hi sb a s e do nt h es t u d yo fr e q u i r e m e n t se l i c i t a t i o n ，s c e n a r i o ，s c e n a r i os y n t h e s i sa tp r e s e n t ，f o c u s e so nh o wt os y s t h e s i z eb e h a v i o r a lm o d e l sf r o ms c e n a r i o st h a ts t a k e h o l d e r sp r o v i d et h i sp a p e rf i r s t l ya n a l y z e st h ep r e s e n ts c h e m eo fs c e n a r i o s ，a n dt h e ni m p o r t si m p o r v e dm s cw h i c hs u p p o r t ss t a t ec o n d i t i o n s w et r a n s l a t em s cd e s c r i p t i o ni n t of i n i t es t a t ep r o c e s s ，a n dt h e ns y n t h e s i sa nl t sm o d e lf r o ma l lf s pd e s c r i p t i o nb yl a b e l e dt r a n s i t i o ns y s t e m t h ev a l u eo ft h ed i s s e r t a t i o ：w i t ht h ed e v e l o p m e n to ft h er e q u i r e m e n t se n g i n e e r i n g ，d e v e l o p e r sr e a l i z et h a to n l ye n du s e r st a k ep a r ti nt h ep r o c e s so fd e v e l o p m e n ta n dp l a yt h el e a d i n gr o l e ，c a l lp r o b l e m sb es o l v e de f f e c t i v e l y , t h ew i d eg a pb e t w e e nc o m p u t e ra n da p p l i c a t i o nb es m o o t h e da w a y w es h o u l df i n da ne f f e c t i v ew a yt oi m p r o v et h eq u a l i t yo ft h er e q u i r e m e n t se n g i n e e r i n ga n ds h o r t e nt h ed i s t a n c eo ft h e o r i e sa n da p p l i c a t i o n s y n t h e s i so fb e h a v i o r a lm o d e l sf r o ms c e n a r i o s ，w h i c hp l a c e se m p h a s i so nu s e rp a r t i c i p a t i o n ，h e l p sb u i l dac o m m o ng r o u n db e t w e e ns t a k e h o l d e r sa n dd e v e l o p e r s a n di t i sa b l et od e t e c ta n da n a l y z et h es c e n a r i o sa n dt h er e l a t i o nb e t w e e ns c e n a r i o s ，s oa st oi m p r o v et h eq u a l i t ya n de f f i c i e n c yo f r e q u i r e m e n te n g i n e e r i n g 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 s ，m e s s a g es e q u e n c ec h a r t s ，l a b e l e dt r a n s i t i o ns y s t e m学位论文独创性声明本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得的研究成果。论文中除了特别加以标注和致谢的地方外，不包含其他人或其他机构已经发表或撰写过的研究成果。其他同志对本研究的启发和所做的贡献均已在论文中作了明确的声明并表示了谢意。研究生签名：歪家锋学位论文使用授权声明日飙2 - 4 五伊本人完全了解浙江师范大学有关保留、使用学位论文的规定，即：学校有权保留送交论文的复印件和电子文档，允许论文被查阅和借阅，可以采用影印、缩印或扫描等手段保存、汇编学位论文。同意浙江师范大学可以用不同方式在不同媒体上发表、传播论文的全部或部分内容。保密的学位论文在解密后遵守此协议。研究生签轹缝豸二绎副币蔷1 硼浙江师范大学学位论文诚信承诺书我承诺自觉遵守浙江师范大学研究生学术道德规范管理条例。我的学位论文中凡引用他人已经发表或未发表的成果、数据、观点等，均已明确注明并详细列出有关文献的名称、作者、年份、刊物名称和出版文献的出版机构、出版地和版次等内容。论文中未注明的内容为本人的研究成果。如有违反，本人接受处罚并承担一切责任。承诺人( 研究生) ：指导教师：第一章绪论( 一) 研究背景第一章绪论随着信息时代的发展，软件需求愈来愈复杂，规模愈来愈大，而且随着企业的发展，工作过程重组，频繁的需求变更已愈来愈成为必然。软件危机持续多年，至今仍无法得以很好地解决。究其原因，固然和软件本身具有的特点有关，但长期以来，缺乏软件开发和维护的正确方法以及忽视软件开发过程的质量控制是为最关键的原因。其中软件开发和维护方法的不正确性主要体现在：忽视软件开发前期的需求分析；开发过程缺乏统一的、规范化的方法论的指导；文档资料不齐全或不准确：忽视用户与开发人员之间的交流：忽视测试的重要性：不重视维护或由于上述原因造成维护工作的困难l 。需求分析不仅是软件生命周期的第一个阶段，而且贯穿于整个软件生命周期，其重要性越来越突出。随着软件工程的迸一步细化，需求工程逐渐从软件工程中分离出来，并成为软件工程界研究的热点之一。进入2 0 世纪9 0 年代，一种新的被称为“用户主导，面向领域的需求分析方法”被提了出来，即如何从各种各样的应用专业领域中特别是直接从最终用户处捕获需求，并完整、准确地予以描述与分析。需求工程的发展，使人们认识到，只有最终用户的直接参与并发挥主导作用，才能真正解决问题空间与求解空间的一致性问题，消除计算机领域和应用领域之间的鸿沟，并自动适应系统需求的不断变化。需求工程研究现状中一个明显的不足是理论研究与实践的脱节，理论解决方案通常是在对实际问题简化的基础上得到的。要获得需求突破，改善需求工程的开发质量和效率，需要探索一条有效的解决途径，缩小理论与应用之间的距离，使开发出来的系统和模型切实满足应用领域的需要【2 】。( - - ) 国内外相关课题的研究状况需求工程一般指应用已证实有效的原理、方法，通过合适的工具和标识，系浙江师范人学硕士学位论文统地描述出待开发系统及其行为和相关约束【1 1 。需求工程通常是一些过程的集合：需求获取、需求分析、需求表示、需求验证以及需求管理等。需求工程的方法学发展很快，对需求工程方法学不同侧面的研究和一些经典论述为需求工程的发展奠定了基础。其中典型的有：l a n o 提出的操作概念规格 3 1 ，于需求产生前由开发人员写成，它既满足精确的规格说明要求，同时易读、易理解，便于用户了解是否冥正体现了其要求。s u t e l i f f e 、m a i d e n 等人提出从领域知识的角度定义在需求工程环境中通用的领域语义模型和组合模型 4 1 。a l f o r d 提出任务分割的概念f 懿，大大降低了需求分析的问题复杂度。c h o u 6 1 和e c k e r t 7 1 讨论了面向对象的需求工程方法学的概念和模型。d r a k e 8 1 提出用于确定系统需求边界的限定过程。g o t e l l 9 1 对需求跟踪性问题进行了研究。还有其他许多人对需求工程方法学的其他方面进行了研究和论述。1 2 1 需求工程代表性研究方法( 1 ) c o r e 1 0 】c o n t r o l l e dr e q u i r e m e n te x p r e s s i o ns y s t e m sd e s i g n e r s 公司制定了一整套标准和过程，c o r e 方法是对这套标准和过程很好的体现。它建立在一些图表符号的基础上。这些图表符号借鉴了一些经典的规格及设计表示法的思想，能够较少二义性、严格的表达系统需求。用这些符号，c o r e 从不同的观察点来分析目标系统，并对此一一建模，最后形成一个组合模型。这一特点使得c o r e 适于系统动态特征的描述，而且能较好地满足s r s 完整性的要求。( 2 ) s a d t “l - - s t r c t u r e da n a l y s i sa n dd e s i g nt e c h n i q u e2 0 世纪7 0 年代由s o f t e c h 公司的d o u g l ar o s s 开发，用于分析、表示件的需求及设计。s a d t 是需求定义开发方法中第一个基于图形的方法，每个s a d t 模型由一系列图表组成，每个图表都有一个辅助文本。作为典型的结构化分析方法s a d 强调数据转换及功能分解的图形描述，表现在对从系统接收信息或传输信息给系统的外部实体的描述上。s a d t 还从需求定义过程中不同参与者的观察角度出发使用相互关联的多个模型来表示系统，它适用于许多建模投术。( 3 ) s r e m l l 2 l s o f t w a r er q u i r e m e n te n g i n e e r i n gm e t h o d o l o g ys r e m 是t r y 于1 9 7 3 1 9 7 8 年开发的方法，最初用于具有严格性能需求的大2第一章绪论型嵌入式系统。s r b m 描述一系列需求定义步骤，使用一定语言( r s l ) 和工具( r e v s )来产生需求及需求规格，并进行语言翻译、一致性和完整性的自动检测、生成文档。s r e m 最突出的一点是使用了一个通用的需求库。需求库信息的集中大大方便了用户对系统需求信息的增加、删除和修改。s r b m 后来还增加了对分布式并行系统的支持，即现在的d c d s ( d i s t r i b u t e dc o m p u t e rd e s i g ns y s t e m ) 系统。( 4 ) j a d 方法l ”l j o i n ta p p l i c a t i o nd e v e l o p m e n t这一方法由i b m 于1 9 7 7 年开发出来，在8 0 年代初首先投入使用。这一技术的核心在于一高度结构化的工作研讨会，研讨组由行政人员、项目管理者、用户、系统专家、技术人员、j h o 辅助人员及文档记录人员组成。用户得到系统人员的帮助及经验丰富、客观的项目的辅助者的指导。这个辅助者与项目管理者和用户会谈一起定义项目的范围和目标。j a o 方法能够加速持不同观点的用户之闻的协商，加深对软件需求的理解，并生成供用户参考的模型或原型。1 a d 成功之处在于它对群体需求获取的协调，同类方法还有n c o s e l l4 】和c r c ”】。( 5 ) a m o r e t ”】一t h ea d v a n c e dm u l t i m e d i ao r g a n i z e rf o rr e q u i r e m e n t se 1 ic i t a t i o n这一方法是卡内基梅隆大学软件工程研究所开发的，提出用多媒体的方法进行需求捕获和建模。a m o r e 采用层次或网状结构，如分层的数据流图、控制流图，对象层次图、任务分解图等形式来组织大量的需求。并提供浏览和导引工具来促进需求的捕获。需求分析人员把a m o r e 作为最接近其需求产生自然形式的需求存储平台，以获得最大限度的可跟踪性及促进对用户最初的需求意图的理解。而且填补了需求产生的最初形式和被一些需求规格方法和c a s e 工具所采用的形式化表示法之间的距离。( 6 ) 场景( s c e n a r i o ) 方法t i l t s l又称场景实例的分析方法，场景实例分析是从用户所设想和期望的特定目标系统来理解、分析和描述系统。场景是由一些智能体( a g e n t ，包括外部用户、外界激励和外部的一些功能实体) 来初始化的。它包括事件和改变系统状态或触发新事件的特定激励，一个事件通常很短，作为系统内部或外部的输入或响应。场景方法包括场景的获取、表示、验证、原型化等过程。当需求分析人员和用户均对最终的场景满意时，场景分析过程完成。浙江师范人学硕十学位论文上述几种方法中c o r e 、s a d t 和a m o r e 注重于需求的建模及表示；j a d 方法是群体讨论方法的湄表；s e m 严格的需求分析步骤能实现一定程度上的自动化支持；j a d 方法和d c d s 思想的结合，对分布式多用户需求协同的研究提供了很好的思路。c o r e 和s a d t 强调用图形界面进行交流，比传统的字母和符号易于接受，能促进需求的快速引出和定义。但是，原始的需求信息在到这种形式化或半形式化的文字或图形符号的形式的转换过程中，其完整性和可跟踪性等可能会受到损失。而a i “o r e 使用最适合需求最初产生形式的媒体( 如图像、声音) 捕获需求，较好地弥补了这一不足；场景实例法则强调从用户的角度用事件及状态变化来描述需求，是很有应用前景的需求工程开发方法，近来引起了需求工程界、软件工程界和人机交互界的高度关注。1 2 2 基于场景的需求工程场景是系统组件之间的临时交互，这里系统指预期软件和其周围环境【1 9 1 。场景是需求工程中需求获取、需求文档化和需求验证的有效的非形式化工具【2 们。较之自然语言，场景可以更为精确地刻画系统的行为；相对于形式化的描述方法，场景概念则更为直观1 2 1 1 。场景支持关注软件环境交互的动态特性的非形式化、叙述性和具体化的描述。实践证明，场景符合人类从具体到抽象的认知过程，也符合人类认知科学的规律，参与需求工程过程的开发人员和用户能容易地使用场景1 2 2 。1 2 2 1 场景研究现状在需求分析中使用场景进行分析的方法源于o b j e c t o r y 并且应用于o b j 中1 2 3 1 。j a c o b s o n 等提出第一个用例驱动的面向对象的分析过程模垂 j 2 4 1 。r e g n e l l 进一步发展了这个模型1 2 5 1 ，其中强调了从场景中综合需求模型的重要性。在文献“叫中，提出了i n q u i r y c y c l e 方法，在面向目标的需求分析中，使用场景脚本识别障碍和问题。文献1 2 7 】中提出的s c r a m 方法结合了概念证明，场景和设计的基本原理。它以一种预演的方法应用场景脚本，验证了脚本关键点的设计选项。最近，i n q u i r yc y c l e 和s c r a m l 2 8 1 中提出了一种基于场景的需求工程方法，可以和面向对象的开发相结合，这个方法包括四个阶段：a 引出和分类用例，b 、分析普遍的问题和需求，c 、产生场景，d 、用场景验证系统需求。4第一章绪论k y n g 的方法【2 9 1 中认为原型和场景可以支持设计过程中的各个步骤。在设计过程中用到的s u m m a r i e s , w o r ds i t u a t i o nd e s c r i p t l 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 r 的方法1 3 0 1 是需求工程中基于场景方法的代表，提出了一种相当完全的需求分析模型支持建档和需求演化。b e n n e r 等【3 1 1 通过强调场景的特点给出了一个场景定义，即某种非形式化的场景符号的原模型。但没有阐述一个场景不同的形式的问题。他给出了一些例子，使用多种的媒体( 文本、图象、原型) ，多种符号层次( 从非形式化的文本到形式化规范的场景) 以及大量的叙述( 从静态到活跃、从没有交互性到高交互性)来表示场景。g o u g h 等对j o c a b c o n l 3 2 】基于用例的o o s e 方法提出了一个扩展。该扩展主要反映在两个方面：1 场景的可视化表示，用于显示事件和动作间的时间序列和工作流。2 问题领域的超文本可视化。场景可以用文本，图象和原型表示，可以通过超文本连接，激励场景并与之交互。h o l b r o o k 提出一种方法学，在场景的帮助下引出需求方法。这个方法学基于一种概念体系结构，在场景和目标及问题集之自j 建立联系。它在一个s b r e ( 基于场景的需求获取) 工具中实现，支持超文本结构，帮助决策者精化对需求的理解。h o l b r o o k 的场景既可以用文本说明系统快照，也可以是动画仿真。h o l b r o o k定义的场景为一种规约：它捕捉系统如何对环境作出反应。h s i a 等提出了一种传统的场景的产生和分析的形式化方法。这些场景用一个形式化语言描述，并给出了相关术语。h s i a 的形式化场景是不可执行的( 这就限制了它们在需求获取和确认中的作用) ，但是应用了更多传统的验证技术检查场景一致性。场景内容的核心在系统交互上，着重于描述行为。h s i a 提出的过程模型d 3 1 中，场景的作用贯穿于从需求到验收测试。但是它并没有说明如何在需求工程中结合场景分析。r e g n e l l 的方法是j a c o b s o n 提出的用例驱动的方法的扩展。相对于j a c o s b o n的方法有几点不同：浙江师范大学硕士学位论文这种方法提出了用例的两个层次：用例描述与用例规约。用例描述给出了个更为形式化的符号( 相对于j a c o s b o n 用例) 。用例规约用来精化用例描述。事件、条件和问题领域对象是用例描述中概念。用例规约中只使用时问，原子操作和抽象接口对象，分别用结构文本和媒体描述用例描述和用例规约。类似j a c o s b o n 的方法，r e g n e l l 的用例侧重于系统和环境之间的交互，而在用例规约中，通过原子操作捕捉系统内部的交互。用例描述仅仅用来产生用例规约。用例规约可以服务于建立设计模型。( 三) 问题的提出需求获取的过程中，场景的使用可以有效促进用户和开发人员之间达成一致。但是，单一场景传达的信息相对较少，若要提供有意义的系统描述，则需将多个场景进行组合。怎样解释多场景? 多场景之间是如何关联的? 潜在的语义是什么? 当合成行为模型来自多场景时又会需要什么假设? 解决这些问题通常有两种方法：1 ) 开发人员设法推断场景之| 日j 的联系；2 ) 由用户明确地陈述这些联系。第1 ) 种方法要求开发人员具备较为丰富的领域知识，对于第2 ) 种方法则涉及到采用何种工具来描述用户所述的联系的问题。对第2 ) 种方法，国际电信协会( i t u ) 提出了类图符号彤】，类图符号可以描述系统是如何从一个场景演化到另一个场景的。类图符号的基础是场景合成：新场景是按照其他的由顺序、分支、循环操作符组成的场景来定义的。这种方式可以描述复杂的系统行为。k r u g e r 等人则提出以状态条件来代替高级消息序列图( h i g hl e v e lm e s s a g es e q u e n c ec h a r t s ) t 3 5 】。状态条件通过不同的场景来识别共同的状态。若两个不同的场景具有相同的状态条件，则表明这两个场景在其所描述的交互作用中具有共同点。这也潜在地允许系统在处于共同状态时可以选择不同的场景。场景合成法和状态条件法对比如下：场景合成法( 比如高级消息序列图) 促进了场景的再利用，场景合成法认为高级场景起相互联系的，并且不要求用户用某种抽象状态机详述这些场景。其不6第一章绪论足是会导致大量短小的场景，而为了描述系统的全部行为，必须用复杂的方法对这些短小场景片段进行合成。这一点削弱了场景合成法可以描述系统行为的重要部分的优势。状态识别法非常方便，不必对场景进行拆分即可描述复杂的行为。可以在一个场景中对主要的系统运行情况进彳亍描述，然后用状态信息加以修饰，这样做可以把该场景和其他场景联系起来。另外，状态识别法能够用来描述各种不同的系统信息。状态识别法不足之处在于：明确的状态识别需要用户在构造场景时提供更多的一致性，也迫使用户用状态丽非用动作序列来表述系统。本文将状态标签引入消息序列图，研究了带状态标签的消息序列图。在已有的场景合成方法中添加状态标签，不仅可以利用已有场景合成方法，而且可以丰富场景的描述，有助于更清晰的描述用户的需求。在此基础上研究了行为模型合成算法，可以将带状态标签的m s c 转化为有限序列进程，进而生成形式化描述标号迁移系统，使得开发人员对目标系统有更深入的认识。( 四) 研究内容和组织结构1 4 1 研究内容根据以上分析，笔者确定将以下问题作为主要研究内容：场景的常用描述语言是消息序列图，我们首先研究了场景描述语言带有状态标签的m s c 。接着我们介绍了基于m s c 规约的标号迁移系统，标号迁移系统本质上是一个有限状态自动机，但是在标号迁移系统中，所有状态都是可接受的。然后我们研究了将m s c 规约转化为标号迁移系统的行为模型合成算法，本文将以有限状态过程( f s p ) 3 6 1 的形式来说明如何将m s c 规约转化为l t s 行为模型。最后我们根据算法初步设计实现了行为模型合成工具。1 4 2 组织结构本文分为5 章：第1 章介绍了需求工程的研究现状，给出了场景的定义，并简要分析了基于场景的需求工程的研究方法。7浙江师范大学硕士学位论文第2 章介绍了m s c 和状态标签，给出了m s c 的定义，并研究了带有状态标签的m s c ，接着介绍了标号迁移系统。第3 章详细说明了m s c 规约转化为有限状态进程的行为模型合成算法。第4 章根据第3 章的算法，给出了行为模型合成工具的体系结构及设计要点。第5 章对论文进行总结并对下一步要进行的工作进行展望。( 五) 研究意义软件工程界早就认识到需求分析的重要性，并逐渐将需求分析独立出来进行研究一一需求工程。需求工程是软件工程较新的研究课题，国内外的专家、学者对需求工程的各个环节：需求获取、需求建模、形成需求规格、需求验证、需求管理都进行了大量研究，并取得了丰富的研究成果。但对需求工程的研究远远没有对软件工程的其他部分的研究那么深入。基于场景的需求工程已取得了很多成果，但是以下问题仍然没有很好地解决 3 7 】：1 ) 缺乏工具支持。其主要原因是难于设计一种合适的表示方法来描述场景。一个合适的场景描述方法至少要满足两个条件，首先要足够简单，让软件工程师和用户易于理解，其次，不仅要便于需求模型构造，也要便于对场景的形式化和自动化的分析。尽管已经出现了许多关于用例和场景的表示形式，几乎都不能同时满足上述两个要求。2 ) 缺乏重用的支持。场景驱动的需求工程主要应用于面向对象的分析。这类方法都依赖于可重用的需求的模型库，利用检索根据根据不同的用例获取不同的模型库。通过遍历用例中每一个可能的事件序列和应用启发式分析指出在每一步可能发生的例外和错误来产生场景。一个场景可以定义为一个事件序列，它是一个用例中的一条可能路径。本文从需求工程中在用户和开发人员起到桥梁作用的场景着手进行剖析，分析了已有的场景处理方案并进行了综合、改进，有一定的创新。论文的创新点：本文研究了一种基于场景的需求获取方法，结合了状态标签与场景合成二者的优点来处理多场景的合成，提高了场景的重用性，并可用状态信息来丰富场景的描述；研究了行为模型的合成算法，算法以有限状态进程的方g第一章绪论法将m s c 规约转化为l 1 s 系统；根据行为模型合成算法设计了一个工具，并结合实例对工具进行了验证。9浙江师范大学硕士学位论文( 一) 消息序列图第二章带状态标签的消息序列图由于人们对场景的理解和解释不同，场景的表示方法多达六十多种【3 8 1 ，【3 9 1 。消息序列图和u m l 序列图是场景文档化最常用的图形化标记语言。消息序列图是描述和规范系统实体间交互行为的图形文本语言，最初是作为s d l( s p e c i f i c a t i o na n dd e s c r i p t i o nl a n g u a g e ) 语言的补充。但是，随着消息序列图的发展，其应用领域越来越广，使用者越来越多，新的概念和内容不断加入到消息序列图中，描述能力也随之增强【4 0 l 。消息序列图的核心语言是基本消息序列图( b m s d ，b a s i cm s c ) ，b m s c 只关注通信和本地动作，高级消息序列图( h m s c ，h i g h - l e v e lm s c ) 提供了描述组m s c 的图形化方法。2 1 1 基本消息序列图b m s c 用于描述一组组件之间的交互作用：1 ) 一个b m s c 由多个实例组成，图2 1 给出的b m s c 示例中，a 、b 、c 表示实例；x ，y 表示消息。2 ) 实例是一个抽象的实体，用垂直轴表示。本文中实例表示场景的系统组成部分，即系统组件、用户和环境。3 ) 消息是实例之间或者实例与环境之间信息交互的基本单位，用水平箭头表示。消息的方向标明了交互的发送者和接收者。消息标签说明正在发生的交互类型。消息箭头的始点表示发送事件，终点表示接收事件，消息的方向说明了事件的发生顺序。任一消息的发送事件发生在该消息的接收事件之前，如图2 1 ，实例a 上对应于消息x 的发送事件在实例b 对应于消息x 的接收事件之前发生。4 ) 事件是可观察的基本单位，两个实例之闯的一条交互消息可以看成两个事件一发送事件和接收事件，同一消息的发送事件和接收事件是异步事件。事件还包括本地动作，定时器等。5 ) m s c 是时间相关的，同一实例轴上的事件按照从上到下的时问顺序依次发生。如图2 1 中实例b 上的对应于消息x 的接收事件发生在对应于消息y 的发1 0第二章带状态标签的消息序列图送事件之前。定义2 1 实t ，l j 4 0 j图2 - 1 基本消息序列图的元素t h ee l e m e n t so f b m s c实例是一个四元组( e ，l ， ，l b l ) ，其中e 表示事件，e = i nuo u tuc o n d 是一组m s c 事件，分别是消息输入，消息输出和状态条件。l 是有限状态标签集。本文假定i n i t 标签表示组件的初始化状态。 ( e x e ) 表示事件的顺序。最小化事件用e 表示，若e e ，表示为s u e ( c ) ，l b l ：e 专l 是函数，描述了每个事件的标签。用l b l ( a ) 表示集合 l b l ( e ) iea ，。定义2 2 基本消息序列图【4 8 1b m s c 是一个结构体：b = ( i ，t g t ) ，其中i 是b m s c 实例的有p 艮集( e j ，l j ， j ，l b lj ) ( o ( j n ) ；t 垂：u 二扬j 专u 乙c 址j 是一个双射函数，将发送和接收事件映射如下：如果i e i n j ，则t g t 0 ) 仨o u t j 。如果t g t ( i ) = 0 ，i 仨i n j 且。仨o u t i c ，则l b b ( i ) 。l b lk ( o ) 。浙江师范大学硕士学位论文如果迁移闭集( u 二i ) ut g tut g t 1 包含 ( a ，b ) ，( b ，a ) ) ，则t g t ( a ) = b ，t g t ( b ) = a ，或a = b 。注意上面定义的迁移闭集条件可以确保b m s c 是时间相关的。换句话说，消息箭头不能互相交叉。我们用t g t 和t 旷1 ，因为消息是同步的， 2 8 是h m s c 函数，它决定了b m s c 可能的连续关系；n a m e 是双射函数n a m e j ：l j - - ) c 决定某个实例属于哪个组件；i t um s c 标准包含更多的特性【3 4 1 ，简单起见本文排除了其中的一些特性。( 二) 状态标签处理多场景的另一个方法就是通过使用一组场景对通用组件和系统状态进行识别【3 5 l 。这里假设场景规约描述了一个模拟系统合成行为的状态机。因此，在b m s c 中，实例被看成是在状态机里模拟一系列状态，并且事件引起了状态的变化，称作状态迁移。因此，在场景规约里，连续事件的每一个间隔称为场景状态( 见图2 4 右部) ，也可用以表示组件状态。第二章带状态标签的消息序列图图2 - 4 场景，组件和系统状态s e c n a r i o s ，c o m p o n e n t sa n das y s t e mw i t hs t a t e s场景状态和组件状态是多对一的，即几个场景状态可能具有相同的组件状态。因此，不同的b m s c 中的具有相同组件状态的场景状态说明了场景之间的联系。有两个基本的机制用以识别组件状态：其一是给场景状态加标签【35 1 。典型的就是在场景状态上加上描述组件状态的标签( 见图2 - 4 ) ；若一个场景中的两个状态用同样的标签标识，则认为二者具有相同的组件状态。其二是不在场景中使用状态标签，而代之以提供识别组件状态的标准。这些标准通常基于特定领域的知识和系统专有的附加信息。例如，s c e d 【4 1 1 在应用一些假设时将状态图加以合成【4 2 】以决定两个场景状态是否表示相同的状态图状态。另一个例子是w h i t t l e 和s c h u m a n 的论文【4 3 】，他们用对象控制语言( o b j e c tc o n t r o ll a n g u a g e ) 来描述场景消息的前置和后置条件ao c l 规约是采用m s c为每一个场景状态产生一个状态变量值。有相等值的场景状态被看作代表相同的组件状态。组件状态识别的变动就是系统状态识别的变动m 】。场景中覆盖所有实例的标签不是用来识别某个特定实例的组件状态，而是用来表示特定的系统状态( 见图2 - 2 ) ，这种类型的标签实质上表示所有组件处于一个特定的时刻。给组件状态和系统状态添加标签的好处在于可用它们和附加信息来丰富场浙江师范大学硕士学位论文景的描述。这些信息可能来自具有不同系统视角和特定领域的知识。与场景合成相比，状态识别允许复杂的组件行为，这种复杂行为包括任何长度的b m s c 描述的可选择行为。例如，图2 - 4 中，我们有两个标识为“准备进行操作”的系统状态标签的b m s c 。这表明如果系统处于例2 的b m s c 状态，此时已经产生消息x 和y ，接下来，系统可能不产生消息z ，而是产生消息b 和c 且继续运行。因此，这个系统状态描述了分支行为，如图2 5 所示。图2 - 5b m s c 和对应的h m s cb m s c sa n dt h ec o r r e s p o n d i n gh m s c为了用场景合成来描述相同的分支行为，需要确切地知道何时是“准备进行操作”状态，然后引进一些合成机制来建立所有可能的分支行为( 见图2 5 ) 。尽管特定的行为相同，还是必须把场景分割成更小的部分，某些部分仅仅有一个消息，这些更小的部分对自身来说可能毫无意义。i t u 提供了一个类似状态标签的符号，其m s c 标准p 叼包括局部条件和全局条件，这些条件能解释组件状态和系统状态。然而，r r u 没有为这些合成元素分配任何语义。在u m l 4 5 1 里，序列图允许介绍状态信息；但是它没有清楚的说明状态信息如何影响不同场景之间的合成。为了理解序列图之间的联系，通常必须要借助于u m l 状态图来描述。( 三) 带状态标签的消息序列图带状态标签的m s c 保持m s c 的原有语义，并在实例上添加了表示状态的椭圆标签。椭圆标签表示个特定的组件状态。有的方法( 如口町) 把状态标签看作条件。将m s c 事件( 发送消息，接收消息或状态标签) 置于一个实例的下部表1 6第二章带状态标签的消息序列图示该事件稍后发生。图2 - 6 是w e b 登录系统添加了状态标签的m s c ：“等待”标签表示”用户”实例在向”浏览器”实例发出消息”输入用户名密码”后处于”等待”状态；“密码验证”标签表示“浏览器”实例在向“逻辑层”实例发出消息”验证用户”后处于”密码验证”状态；“等待数据库验证”标签表示”逻辑层”实例在向“数据库”实例发出消息“提交数据库验证”后处于“等待数据库验证”状态；“验证”标签表示“数据库”实例收到了消息“提交数据库验证”后处于”验证”状态。ab1 7浙江师范人学硕士学位论文( 四) 本章小结c图2 - 6 带状态标签的m s cm s c sw i t hi t a i cl a b e l s本章结合w e b 系统登录的实例，首先介绍了消息序列图和状态标签；然后将状态标签引入消息序列图，介绍了带状态标签的消息序列图。1 8第三章行为模型合成算法第三章行为模型合成算法带状态标签的m s c 为系统分析人员从用户处获取的需求描述，开发人员还需将其转化为更为形式化的描述标号迁移系统( l t s ) 。( 一) 标号迁移系统3 1 1 有限状态进程3 1 1 1f s pf s p ( f i n i t es t a t ep r o c e s s e s ) 【4 6 】是个简单的且有准确l t s 语义的过程代数，可用于简洁地描述l t s 。f s p 可以描述一个并发程序，并验证其行为与规约的一致性。在f s p 中主要有以下一些操作符：( 1 ) j l 哽序：专，表示动作间的顺序。如x - ) p 表示先执行动作x ，再执行进程p描述的动作序列。、( 2 ) 选择：l ，表示不同执行动作的选择。如x 专iy - ) q 表示或者先执行动作x ，再按照p 的描述执行；或者先执行动作y ，再按照q 的描述执行。( 3 ) 条件控制：w h e n ，表示在给定条件下执行某一动作。如w h e nbx - - ) py - - ) q表示：若条件b 成立，则除了y - ) q 以外可以选择执行动作x 再执行进程p 的动作序列；若b 不成立，则只能执行动作y ，然后再执行进程q 的动作序列。这里，b 是一个状态谓词。( 4 ) 并发组合：i i ，表示多个简单进程间的组合。如p i i q 表示在条件允许的情况下并发执行进程p 和q 中的动作序列。其中p 和q 又称为子进程。3 1 1 2f s p 中的并发控制当并发执行多个进程的动作序列时，这些属于不同进程的动作间的协作关系需要某种同步设施来描述和控制。在f s p 中有如下一些并发控制机制【4 6 】：共享动作( s h a r e da c t i o n s )1 9浙江师范大学硕士学位论文指各并发予进程中共有的动作，这些动作必须在同一时刻由各相关子进程同时完成。互斥( m u t u a le x c l u s i o n )一种锁机制，它的实现基于上述的共享动作，一般定义一个特殊进程：l o c k = f a c q u i r e - - r e l e a s e - l o c k ) 。系统中有一类资源在某一时刻不允许多个进程同时访问，只能由单个进程访问。这类资源在访问时需执行锁机制以确保互斥访问。3 1 2 标号迁移系统一个系统可以用一组并发状态机进行行为建模，每个实例用一组状态和状态之间的迁移来刻画。本文中的状态机是一类特别的自动机，称为标号迁移系统。定义3 1 有限自动机1 4 7 1有限自动机是一个5 元组( s ，。6 ，q o ，f ) ，其中s 是有限状态集，是字母表，6 是将s x 映射到2 s 的函数，q o 是初始状态，f 是可接受状态集，是s的子集。若对任意q e s 和任意e ，6 ( q ，e ) 至多有一个成员t 则自动机是确定的。在标号迁移系统中，所有状态都是可接受的，即s 集与f 集相同。定义3 2 标号迁移系统 4 7 】标号迁移系统是一个四元组( s ，l ，其中：s 是状态集；l - - q u ( 1 ) 是标签集，其中d ( p ) 表示字母表p ，t 表示内部动作。内部动作对外部环境不可见；a c ( s x l x s ) 。我们用s 旦一s 表示( s ，a ，s ) ，用s 竺一s 表示存在l i 和s “w ：l i l n ，s h = s 且s 与s l 与s n ；q e s 是初始状态。第三章行为模型合成算法设有两个l t s ：p 和q ，p h q 表示二者的联合行为，联合行为是两个l t s 异步执行的结果，但在所有共享消息标签上是同步。这表明只要转换标签没有被另一个l t s 的字母表共享，两个l t s 就能够相互独立地进行状态迁移，当然共享标签必须同时执行。标签的可见性表明l t s 在t 上不同步，因为t 代表内部动作。一个m s c 规约提供了两类信息：发送消息与接收消息的序列信息和状态信息。这两类信息在消息序列上是由实例提供的。例如对于图2 - 6 ( a ) 的逻辑层，自上而下，逻辑层在收到”验证用户”的消息后，发送“要求数据库验证”消息，接着在接收到“数据库”发出的“非法用户”消息后，向浏览器发送“非法用户”消息。若将实例的每一个事件都看作即时发生的，则将该实例就是一个标号迁移系统，如图3 - 1 所示：l t s 中的状态2 对应于w e b 登录系统的“数据库”实例的“验证”状态标签。图3 - 1w e b 登录系统的l t s 集合示例t h el t s so f t h ew e bl o g i ns y s t e m为了简化语义的表达，本文假定实例是标准化的。标准化实例既不包含两个连贯状态，也不包含两个连贯的消息事件。对于所有的事件e ，e ，如果e = s u e ( e ) ，则e c o n d 且e i nu o u t 或者e e i n u o u t 且e e c o n d 。另外，标准化实例有第一个和最后一个事件的状态，如果e 是在e 中的最小或最大事件，那么e e c o n d 。标准化实例有一个特殊种类的事件，t 事件表示组件状态的内部变化。标准化实例是通过使用t 事件将连续状态分开，并用带的状态标签( 空消息标2 l浙江师范大学硕士学位论文签) 将连续的消息事件分丌实现的。3 1 3 组件l t s 和系统l t s定义3 3 组件的l t s 实例【4 8 】设i 是标准化实例，i