语义图片模块

时序逻辑程序设计与软件工程下册(软件工程方法与工具)唐稚松等著2002内容简介本书旨在介绍一种面向软件工程的时序逻辑语言(XYZ桙E)及以该语言为基础的支撑软件开发全过程的软件工程系统(XYZ系统),目标是希望能为一般工业界用户服务,以提高软件开发的自动化水平及所开发软件的可靠性与可维护性.
全书共分上、下两册.
上册介绍时序逻辑语言XYZ桙E,内容包括XYZ系统研制的技术和哲学背景,XYZ桙E的逻辑基础,XYZ桙E的基本特征和基本成分,XYZ桙E的控制结构,XYZ桙E中所表示的各种机制,XYZ桙E的实现,基于XYZ桙E的实时程序设计与混成系统表示,以及在XYZ桙E框架内的程序规范与Hoare逻辑验证等.
下册介绍软件工程方法与工具,内容包括面向模块程序设计的可视化图形工具,基于形式规范的逐步求精过程、速成原型与模型检验方法,可视化体系结构描述语言与工具及其在软件开发过程中的应用,最后还介绍了语言转换工具及其在软件再造工程和某些专用领域的应用,实时及混成系统的验证等.
本书适于软件工程研究人员及教学人员阅读,也可供实际软件工作者参考.
图书在版编目(CIP)数据时序逻辑程序设计与软件工程(下册):软件工程方法与工具桙唐稚松等著.
—北京:科学出版社,2002ISBN7桘03桘009928桘1Ⅰ畅时…Ⅱ畅唐…Ⅲ畅①逻辑程序程序设计②软件工程Ⅳ畅TP311中国版本图书馆CIP数据核字(2001)第084808号科学出版社发行各地新华书店经销倡2002年5月第一版开本:787*10921桙162002年5月第一次印刷印张:16印数:1—3000字数:364000定价:28畅00元(如有印装质量问题,我社负责调换枙环伟枛)出版北京东黄城根北街16号邮政编码:100717http://www.
sciencep.
com印刷序XYZ系统是一种以时序逻辑语言XYZ桙E为基础的软件工程工具系统,该系统的研制计划自20世纪80年代初开始实施,在国家多种科研经费的支持下,共历3个五年计划的不断工作与改进,终于在1995年夏在中国科学院软件研究所实现.
从1996年起,我们一方面开展在实时过程控制、动画片等领域的一些应用研究,一方面又从理论与技术结合方面对这一系统进行改进并提出一种新的方法与工具,且将其应用于实际.
为便于今后开展有关XYZ系统的推广与应用,也为了我国在计算机科学与软件工程等领域培养高层次的研究及开发应用人才的需要,我们编写了本书.
它可以说是我本人以及我所领导的研究小组近20年来的研究工作的总结.
在本书中,我们力求明确地说明在软件工程及形式化方法等方面有哪些是应该解决的方向性的、根本性的理论与技术问题,以及我们在XYZ系统中是如何解决这些问题的,我们所走的道路与解决问题的方法与当前国外主流方向的分歧所在及各自的得失如何,以期得到读者的理解,从而做出合适的判断.
我之所以认为这样做是必要的,不仅是为了使我们的工作能得到读者的认可与支持,更重要的是希望能提醒我国青年同行:虽然在软件领域中,不论理论或技术方面,我国总地讲还比较落后,还应该向先进工业国的同行学习,但请注意,千万不要盲目追赶新潮,要以分析批判的态度对待他们的工作,这些工作不但可能有待改进,而且在某种条件下,甚至在重大的方向性问题上还长期走在值得怀疑的道路上.
在这种情况出现时,不但可能旁观者清,而且因为我们所处的文化背景不同,思维方式有异,可能我们比他们更易发现问题并认清道路.
古人所谓智者千虑必有一失,其信然乎!
日本是以学习西方科学技术而闻名的,软件技术更是力追美国.
可是近年来,日本也有人对此提出疑问.
例如,以向日本产业界介绍外界高新科技最新情况著称的经济新闻社与日经产业消费研究所合办的枟日經高科技情報枠(日經ハイテリ情報)在1993年第200期发表了一期名为"东方的智慧"专号,由该所研究员岛井弘之等写了一篇总论,其中有一段话说明办此专号的目的:"现代科学技术是否已陷入某种滞塞状态期待甚高的高温超导和常温核裂变研究虽仍在继续下去,而其现有技术已迈进成熟阶段,但是它缺乏发展革新的苗头.
这种停滞的原因也许包括西方理性主义(rationalism)对待事物的看法和行动原理,至少可以说是根本原因之一.
当今是重新考虑现代科学基础的思想方法的好时机.
目前世界上存在着许多与西方不同的文化思想区域,自然其中会隐藏着打开该局面的思想.
比如,自古代文明发达以来,中国人发明了印刷术、指南针、火药等丰富而实用的技术,其智慧最能够作为参考对象.
"由此可见,日本人已开始注意到这个问题,我们岂可妄自菲薄我认为,这不失为值得探索的达到知识创新目标的道路之一.
当然这件事不能流于空谈,捕风捉影,只有在具体科学技术研究中做出由于具有我国文化特征的思想指导而确见实效的工作才有真正的意义.
因此,我希望,我的上述看法不要被误解为鼓励人们丢掉踏实的研究作风而去做没有科学根据的比附与胡思乱想.
回顾近20年来XYZ系统的研制过程,深感在科研工作中走与世界主流方向不一致·i·的道路是多么艰难.
XYZ系统提出之初,虽得到美欧软件工程方面几位著名专家[如ISSI(国际软件系统公司)的叶祖尧①、CMU的N.
Habermann及Trondheim的A.
Solvberg等教授]的赞赏与支持[唐16,XYZ],但由于这些工作在思想倾向上与西方理论研究的主流方向相背离,自然不易很快得到西方理论界的理解与赞许,因此他们虽然对于XYZ系统因其独特思路而乐意邀请我去介绍,但对其意义与价值却长期不作评述,实际上即表示怀疑.
直至1988年才有两位英国著名理论家H.
R.
Barringer和D.
Gabbay在一篇总结性文章中指出:"将时序逻辑应用于软件工程的主要步骤即找到可执行时序逻辑"[BG],并承认1983年我发表的介绍XYZ桙E的论文[T1]是这方面最早的"先驱".
但这一评价也不过是"一叶知秋"而已.
真正表示国际理论界对XYZ系统态度的变化是在20世纪90年代才发生的.
1994年,时序逻辑的创立者、1996年图灵奖得主、以色列著名理论家A.
Pnueli教授第一次访问我国.
他在仔细参观了XYZ系统的演示后对我说:"说实话,我过去一直认为你的野心太大,不可能成功,而这次看了XYZ系统的演示后,我发现你已经成功了.
"在他与他的长期合作者斯坦福大学的Z.
Manna教授的提议下,于1995年在北京召开了"逻辑与软件工程"国际研讨会.
在他们向会议提交的论文前面有一段对XYZ桙E的评语:"唐稚松教授……将时序逻辑的概念处理得超乎任何人的想象,并将之应用在许多方面,在他之前,没有人认为这是可能的.
"[MP8]接着,在他作为这次国际研讨会论文集的主编所写的序言中,更清楚地说明了他对以时序逻辑为基础的XYZ系统的认识的变化过程.
他说:"我仍然记得,当我首次听唐教授谈到以时序逻辑作为软件开发全过程……的统一基础时所感到的惊讶.
随着时间的流逝,这一梦幻般的系统,由软件研究所一个致力于此的小组所实现并加以扩充,这系统……随之逐步成形.
我的这种惊讶也渐渐转变成为钦慕.
"接着,他说明以时序逻辑这种协调的形式语义理论作为软件开发全过程基础的重要意义.
最后,他说:"我盼望由唐教授所构想并发展的XYZ系统作为先驱所倡导的这一途径今后能引起软件工程系统的研究人员以及构造人员的巨大兴趣.
"[PL]事实上,Pnueli教授所说明的他对XYZ系统看法的变化,正是近年来国际形式化理论界在形势迫使下已开始出现改变其原来思路的动向的一种反映.
比如国际代数语义权威SRI(斯坦福研究所)的Mesequer教授将状态转换机制引入代数语义就是这方面又一有意义的迹象.
(他曾来函索取XYZ的资料,并说瑞士苏黎士ETH的Engeler教授向他推荐我们的工作.
1998年2月在Dagstuhl召开的会议上,我们初次相遇,又提起Engeler教授向他推荐我们的工作;此外在这次会上,我还第一次遇到另一位代数语义的权威学者Wirsing教授,他也提到Ehrich教授向他推荐我们的工作.
)我认为,XYZ系统之所以过去长时间难以为西方理论家所理解,从根本上说是由于我们采用了一些我国传统哲学思想方法与西方流行的逻辑分析方法相结合的思路.
这样的思路强调理论与技术紧密结合而不偏向一个极端,与西方片面重视形式化数学理论的理性主义思想差距甚大,但与国外(包括美、日、欧)一些对理论与技术不怀偏见,而较重视能实际提高软件生产率的软件工程专家(如叶祖尧、Solvberg及日本软件工程学会主·ii·①叶祖尧对XYZ的评语:"我心中绝对相信唐的XYZ语言将是一次重大突破的基础.
……他的工作非常有创造性,而且有使软件生产率取得重大提高的实际应用前景.
"Solvberg的评语:"XYZ语言为我们提供了一种关于信息系统……软件功能描述的令人着迷的思维方式.
……我看到,如果我们将唐教授的XYZ系统组织到我们的方法论基础中去,将有巨大的潜力推进软件设计与构造的……学科技术水平.
"席岸田孝一等)的思路较为接近.
这就说明,为什么在开始阶段XYZ系统从理论界与软件工程界这两方面所得到的反应是如此的不同!
特别应该一提的是日本友人岸田孝一先生,他不但对西方软件技术十分了解,而且对中国传统文化有很深的素养,因此他对XYZ系统的哲学背景的兴趣也显得特别浓厚.
他不但多次邀请我到日本作为软件学术会议的特邀主题报告人讲XYZ系统的哲学背景,而且亲自在枟朝日新闻枠上写专文介绍XYZ系统(1995年12月4日).
文中说:"唐教授的成就之一就是花了近15年的时间成功地开发了称为XYZ的软件系统.
尽管系统所采用的最基础的数学理论来源于西方,但构造此系统的基本思想却来自孔子的中庸哲学和佛教的禅宗认识论哲学.
这也许可以说是东方文明对于新的21世纪计算机技术发展的一大贡献吧.
"[岸田]这一情况当然不易为西方多数理论家所理解,而瑞士苏黎世ETH的Engeler教授及德国Braunschweig的Ehrich教授等少数理论家算是例外.
在XYZ系统设计中,我之所以强调哲学思想指导,并不是出于为哲学而哲学的学院式兴趣,而是由于20世纪80年代初对国际软件理论与技术的发展潮流及其思想背景感到怀疑与忧虑所致.
事实上,国际计算机科学家中有类似怀疑和忧虑的人并非少见,如斯坦福大学的D.
Knuth教授就是较著名的一位①.
下面让我们回顾一下计算机科学技术的发展历史.
众所周知,在20世纪70年代中期以前,计算机科学领域的理论与技术是紧密相联的,如形式文法(包括属性文法)及语法分析方法的研究与编译技术是相互依存的.
可是自从语义形式化问题提出以来,由于这问题难度很大,希望从传统数学理论中找新的工具与方法的要求很普遍,许多有才能的青年数学家逐渐进入这一研究领域.
他们在软件技术方面的根基不很深厚,但受理性主义传统影响很大,数学的职业倾向性远远大于软件的职业倾向性.
从20世纪80年代以来,在这类人员集中的机构、地区与会议上,其价值标准(如脱离实用意义,单纯从理论的逻辑严密性及深度与难度对工作进行评价等)以及学术气氛也就逐渐发生了变化,从而不能不影响学科发展方向,使计算机科学理论研究日益脱离软件的现实实用性考虑而成为一种较深的数学探索.
这种情况自然难被关心市场效益的工业界所接受.
特别是以实用主义传统著称的美国工业界,他们虽然也很关心提高软件生产率,关心软件的可靠性与可维护性这类关键问题,但他们对日益远离工程技术实用性的形式化语义理论及规范语言的研究逐渐失去信心与兴趣,终于导致几乎完全抛弃了理论研究,而单纯从技术上找出路.
他们企盼软件像硬件一样,用从技术上提高自动化水平或可重用性的途径找到提高生产率的方法.
这种思路大大推动了软件工具及与之相联系的操作系统的发展,其后果是整个20世纪80年代,对于软件研究与发展来说,就是一个理论与技术相互分离脱节、各走极端的年代.
这种情况在一段时间内使双方都得到一定程度的满足,理论家获得了很高的荣誉,而工业界也获得了不小的利润.
可是,提高软件生产率及可靠性与可维护性等根本性问题不但没有解决,而且似乎希望日益渺茫.
这种情况是否合理这些根本性问题是否已失去意义事实并非如此.
不但美欧各国关键技术委员会·iii·①1995年他在访问Duke大学时,与我过去一位名叫金伟的学生(现在该校作博士生)谈到过我,他说:"唐教授是我遇到的惟一一位关心计算机科学在10年、20年后如何发展这个问题的中国计算机科学家.
因此,我建议斯坦福大学计算机科学系邀请他来访问.
"事实上,XYZ系统的设计思想正是这次访问时开始形成的[T13].
每年一次向国家最高当局提出的报告中都将这个问题放在首位,而且甚至像微软这样一贯强调软件技术且已取得大量利润的公司也已感到,由于缺少精确语义基础,大型软件的可靠性与可维护性问题已制约他们进一步的发展,因此不久前该公司已在剑桥大学等处投入巨资开展这方面的研究.
事实上,语义的精确性与技术的自动化二者是相互依存、不可分割的,而且只有紧密结合才能达到提高软件生产率的目标.
因此,如果不从根本上找出理论与技术脱节的病根来辨明道路,单靠投入资金岂能解决这个问题.
那么,产生这个问题的根本原因何在呢40多年来,有关计算机科学的研究实际上是围绕以某种模型为基础的三个彼此相关的层次进行的,即计算机体系、适应该体系的可执行程序语言及表示程序抽象语义的规范语言.
众所周知,40多年来流行的计算机体系都是建立在冯·诺伊曼(vonNeumann)模型上的,流行的程序语言即为适应这种机器体系的常见命令式语言(如Pascal,Ada,C,C++等).
这种模型主要的特征即为自动机状态转换机制.
通俗地说,表现为变量在运行过程中可通过赋值命令(语句)改变其值,且其控制流可分解成"循环"、"分支"及"继续"等基本结构,其中尤以"循环"最具特殊的意义.
由于这些特征使这种语言能高效地在冯·诺伊曼型计算机上运行.
至于适应这样模型的规范语言,人们较为广泛接受的是Hoare逻辑中的由前置断言(preassertion)与后续断言(postassertion)所表示的逻辑语义.
以上三个层次对冯·诺伊曼模型的表示方式相互间是紧密关联,协调一致的.
它有其优点与缺点,优点是其常见命令式语言执行效率高,为广大计算机用户所习用(特别是用循环表示重复计算),在Hoare逻辑的作用下,命令式语言的程序与由前置和后续断言表示的规范协调地联系在一起,而且对于数学水平不高的初学者来说,按照自动机状态转换方式设计一个规模不太大的程序或模块较为直观而易于掌握;其缺点是这种基于自动机状态转换的机制不够抽象,包含细节太多(赋值本身即是一种细节),不能像数学中常用的函数那样便于嵌套与连接,平常数学中许多理论与技巧(如证明技巧)不易在其中直接应用等等;而更重要的是,在这种命令式语言与规范语言的关系中,后来发现一些语义方面的难题长期找不到解决的办法.
比如,常见命令式语言中递归过程(及进程)这类模块的后续条件如何表示其递归性并如何验证其正确性更困难而又更重要的一个问题是,对于由通信进程组成的并行语句,如何表示其语义如何验证其正确性事实上,在冯·诺伊曼模型的框架内,惟一可行的办法是将并行语句的语义归结为该语句所包含的串型进程语义的合取,但这一命题成立的条件是语义可组合性.
而事实表明,在通信的情况下这一条件可能是不成立的.
因此,困难在于如何保证并行语句语义可组合性条件成立.
容易看出,上述优点是工程界所重视的实用性方面的优点,上述缺点是理论界所强调的数学精美性方面的弱点,而上述困难问题则的确是冯·诺伊曼模型所面临的实质性问题.
不解决这些问题必将严重影响程序的可靠性与安全性,使冯·诺伊曼模型不论从理论上还是从工程上说都将难以采用.
(C.
A.
R.
Hoare在文献[Ho2]中讨论CSP的数学模型时明确指出,他在文献[Ho2]中放弃了文献[Ho1]中的语义模型,而采用了与CCS相同的进程代数所要求的函数式模型,其中三条原因中的前两条就与这里所述的两项困难问题直接相关.
)由于上述情况,从20世纪70年代末起,计算机科学领域出现寻找其他非冯·诺伊曼模型的高潮.
其中最有影响的即函数式模型的研究,包括函数式机器体系、函数式程序语言,以及以递归性与函数映射为特征的基于可计算函数(包括λ演算)及代数·iv·的语义理论与规范语言等三个层次的研究.
这些研究与上述基于冯·诺伊曼模型的三个层次研究可以说是相互对立的,一方的优点正是另一方的缺点,两方实际上是难以协调的.
由于函数式模型具有与传统数学理论一致的许多特征,从20世纪80年代以来有较强数学兴趣的计算机科学家参与这方面语义理论及规范语言研究的人越来越多,在理论研究方面形成热潮,特别是西欧受理性主义传统影响较深的学术机构更是如此.
因此可以说,从20世纪80年代到现在计算机科学理论界(特别是以英、法、德、荷、意等国为代表的西欧)是以函数式模型为基础的理论研究占绝对统治地位的年代.
但另一方面,这种理论研究所依附的基于函数式模型的计算机体系则很不成功,这类计算机造价昂贵、效率低,而且功能很有局限性,这是与现在流行而且在可预见时间内难以取代的硬件基础紧密相关的.
由于RISC技术及工作站流行,这类函数式机器已退出市场,这方面所长期探索的研究似乎已销声匿迹.
处于这类理论及机器体系之间的函数式语言研究虽多数已消失,但仍有少数(如从爱丁堡发源的SML)因在某些领域(如作为表示形式理论的验证系统的工具)有其应用价值而在学术界保持着生命力.
这一情况与下述情况颇为相似:长期以来尽管冯·诺伊曼计算机及与之相应的命令式语言占绝对统治地位,但函数式语言Lisp在人工智能领域仍保持其生命力.
类似地,估计今后像SML等少数函数式语言在某些专用领域可能会长存不衰.
可是,只要冯·诺伊曼计算机维持其在机器结构方面的统治地位,则函数式语言会因与机器体系不一致而影响其效率与功能,故不可能在可执行语言领域占统治地位,广大用户和工业界仍将会以使用基于冯·诺伊曼模型的命令式语言为主,这一点是无可怀疑的①.
现在的问题是关于形式语义理论及规范语言研究怎么样我认为,只要机器体系及可执行语言是以冯·诺伊曼模型为主流,若理论研究却反其道而行,坚持以函数式模型为基础进行,则必然出现的结果是要么理论与技术脱节成为一种近期与技术无关的纯基础数学研究,要么这样的理论终被抛弃.
从长远来看,两者必居其一,也就是说,"皮之不存,毛将焉附"从20世纪80年代初以来,XYZ系统的研究即是基于这样的信念开始的.
我们走的是一条以冯·诺伊曼计算机为基础,面向常见程序设计的理论与技术紧密相联系的研究道路.
作为少数派,孤单地走这条道路是艰辛的,为此所必须解决的问题也是十分困难的.
但我认为只要思想方法正确,坚持不懈,终能找到解决困难问题的途径,因此对这条坎坷道路的前途一直满怀信心.
事实上,几乎与我们同时,得克萨斯州(Texas)大学奥斯汀分校的Chandy与Misra教授很可能是在Di唱jkstra教授的影响下,也走上了与我们类似的面向冯·诺伊曼模型建立形式语义理论与可执行语言相结合的道路,这就是他们关于UNITY语言的研究.
这是一种可执行命令式语言,为了使此语言在并行情况下具有语义可组合性,他们建立了一整套复杂的理论,并对这种语言进行很多的限制,最后终于解决了以冯·诺伊曼模型为基础保证在并发情况下该语言的语义可组合性的难题.
从这方面说,该系统是成功的.
Dijkstra与Hoare对此语言系统作了极高的评价并予以推荐.
该系统问世之初曾经引起了理论界与技术界的注意,但很可能是由于这一语言受限制太多,与常见命令式语言风格差距很大,且表示力所·v·①一些著名计算机科学家致力于提高爱丁堡SML语言在冯·诺伊曼计算机上的执行效率,希望将它改造成一通用程序语言以取代常见命令式语言.
对于这一目标是否能完全达到,我的观点是消极的.
因为这目标等于要求建立在一种模型上的语言有可能在另一种与之对立的模型的计算机上有效执行,且其效率与建立在后一模型上的可执行语言的执行效率不相上下.
这实在是件不可思议的事.
受影响很深,以及它所依据的理论是专为此语言所建立的,相当复杂,一般用户很难深入掌握;此外,它的目标似乎是取代流行的常见命令式语言,而不是为常见命令式语言服务,为它们提供一坚实的语义基础,因此,难以引起广大习惯于使用常见命令式语言用户的兴趣.
总之,由于各种原因,这一语言系统问世10年,至今已少有人谈及,也未见到重要的应用效果.
无论如何,它即使不被完全抛弃,也不大可能取代流行的命令式语言并为这些命令式语言提供一合适的理论基础,补充其在这些方面的不足,以达到使冯·诺伊曼模型基础上的机器体系、可执行语言及语义理论与规范语言三个层次紧密地联系起来的目标.
看来,这一使命不可避免地只有落在XYZ系统身上.
为此,XYZ系统中提供一时序逻辑语言XYZ桙E,它既包含表示规范的子语言XYZ桙AE,也包含可在冯·诺伊曼计算机上有效执行的子语言XYZ桙EE,两方均具有与常见命令式语言相同的控制结构与数据结构,其风格与表示力与常见命令式语言无异,后者可作为常见命令式语言之上的中间语言,而前者可在语义描述及规范语言方面作常见语言的补充;它的理论基础,即Manna唱Pnueli线性时间时序逻辑,并不要求用户专门进行复杂的理论训练即可掌握,所以就XYZ系统而言,不存在妨碍UNITY推广应用所发生的那些理论与技术上的困难.
更重要的是,前面所述的那些冯·诺伊曼模型面临的难题,如并行语句的语义可组合性问题及递归过程规范的表示与验证等问题,都已简单而自然地在XYZ系统中得到解决(见本书第七章).
因此,现在我们可较大胆地说,XYZ系统已较圆满地为冯·诺伊曼模型提供了一个适应冯·诺伊曼计算机体系且理论与技术紧密联系的逻辑语言及软件工程系统.
据我所知,当前世界上似乎尚未见到其他同类系统做到了这一点.
事实上,正如Pnueli指出的,这一方向正是XYZ系统作为"先驱"所倡导的.
由于基于技术实现软件生产自动化的工具研究(特别是依靠人工智能实现这一目标的努力)效果并不显著,自20世纪80年代中以来,以美国工业界为基地大力发展起以提高可重用性为目标的提高软件生产率的模块程序设计的研究,这也就是面向对象程序设计的潮流.
先是以C++为代表的,近年则是以Java为代表的程序语言系统已在美国工业界引起广泛的注意.
可以说,这一以软件技术为基础的提高软件生产率的道路是颇有成效的.
但在我们看来,它仍存在以下两方面的问题:第一,这一方向对语义精确性问题未予足够的重视,因此可靠性方面仍无足够的保障.
比如由于面向对象程序设计的特征之一是可重用性,忽略了形式规范的情况下要保证重用时的语义一致性则只有依靠测试(testing),可是对于具有继承性的模块而言,测试将变得更为复杂与困难.
第二,分布式面向对象模块中并发通信将起核心的作用.
因此,由并发通信所引起的语义正确性问题是无法回避的,这个问题不可能单纯从技术上依靠模块重用来解决.
下面我们对XYZ系统的具体特征概括地介绍如下:1)我们的目标是语义精确性与技术实用性的统一,精确性与实用性缺一不可.
在这方面我们的要求是严格的,不容让步的,因为只有这样才能确保达到提高软件可靠性、可维护性的目标.
可是,语义精确并不等于理论精美,虽然在理论精美性与技术实用性这两个方面,我们都很重视,但如果双方发生不易调和的矛盾,则在不损伤语义精确性的条件下,我们宁可在理论精美性方面作适当让步,以保证技术的实用性标准.
因为在我们看来,计算机科学毕竟是一门技术科学,它与纯粹数学不同,忽视技术实用性必将失去技术科学的应用价值,最终导致理论与技术脱节.
既然冯·诺伊曼型计算机是当前及今后·vi·可预见的时间内惟一被采用的计算机体系,计算机科学理论与可执行语言理所当然应适应这种机器体系及其依据的模型,这才是保证理论与技术协调的合理道路.
但是如果为了做到这一点而出现关于语义理论及相关技术方面的困难,则是必须解决的问题,不能回避,否则其可靠性无法保证.
XYZ系统的研制过程即是以此为目标,面对这些问题逐步加以解决的历程.
事实证明,只要采取正确的思路,往往可以找到出人意料的解决问题的方法.
在这一方面,我们是有较多体会的.
我坚信,将我国传统哲学思想与西方逻辑分析方法相结合,常能为我们提供一些巧妙的思路.
我希望在本书中能够结合理论或技术问题对此有所说明.
2)时序逻辑语言XYZ桙E的一个重要特征即强调动态语义与静态语义并重,将两者结合而不只偏向一方.
适应冯·诺伊曼机器体系的可执行语言的特征即表示自动机的状态转换机制,其方式是命令式的,其语义是动态的;而适于这种模型的规范语言,即Hoare逻辑中的Pre与Post断言(用时序逻辑表示即Pre→Post),其语义则是静态的.
我认为,将规范所表示的静态语义与可执行语言所表示的动态语义紧密联系起来是使这方面的研究更能在实际软件工程系统中发挥实用价值的关键(这也就是前面所引Barringer与Gabbay对可执行时序逻辑在软件工程中的作用的评价).
为此,在时序逻辑语言XYZ桙E中,应找到一种控制框架将规范的静态语义与可执行的动态语义统一地表示出来,这就构成XYZ桙E的一个重要特色,即表示动态语义与静态语义(即XYZ桙EE与XYZ桙AE中)的两种命令(语句)可混合在同一程序中出现,用这种混合出现的程序,即能表示出由完全抽象的规范到完全可有效执行的程序之间平滑过渡的过程.
在XYZ系统中,就是以这样的方式表示逐步求精方法.
这种逐步平滑过渡恰好起着理论(表示静态语义的断言)与技术(表示动态语义的可有效执行的程序)相联系的桥梁作用.
动态语义与静态语义的联系,不但反映在抽象规范与可执行程序的关系上,而且也反映在程序的模块结构上.
如具有流程图结构的过程与进程显然是表示动态语义的,而作为面向对象程序设计的具有封装性(encapsulation)与继承性(inheritance)的对象模块,显然是面向问题领域的,故其语义是静态的.
为了将这两方面联系起来,如上所述,在XYZ系统中提供了一种面向基于通信的计算过程的模块,称为并行语句进程(PSP),用它即可将大型程序中静态语义与动态语义连结成为一个整体.
最后,还有一个与语义有关的问题,即如前面所述,XYZ桙E可分成不同层次的子语言.
其最基础的一层是表示可有效执行程序的XYZ桙EE,而且这些程序所表示的风格与常见程序语言是相同的.
人们不禁要问,既然已经存在许多流行的程序语言,如C,C++,ConcurrentC,Java等,提出XYZ桙EE这样的时序逻辑语言还有何必要一方面,由于它作为具有统一结构的时序逻辑语言的最底层,可与表示不同抽象层次规范相联系,来表示逐步求精过程,从而提高所书写程序的可维护性与可靠性;另一方面,XYZ桙EE语言可以看成是一种中间语言,它的程序可在保持其执行效率的前提下自动转换成Unix上的C程序、Java程序,或适应微软操作系统的程序.
这样,即可使用XYZ桙EE书写的程序具有适应不同软件平台的可移植性.
这种特征是极具实用价值的.
3)关于XYZ系统中工具所实现的方法论,有如下几方面的内容:①归纳"2)"中所述,XYZ系统所支撑的程序设计可以说是由纵向与横向二维正交而成.
纵向方法论即前面谈到的由抽象(静态语义)到具体(动态语义)的逐步求精方法,·vii·其中包括不同抽象层次的规范描述、语义一致性检验、验证及速成原型等各种方法及相应的支撑工具,这种设计与语义由静态向动态过渡相关;至于横向方法与工具,则是为了支撑模块程序设计.
对此,XYZ系统中将针对各种不同类型模块提供相应的可视化图形设计工具.
但是这两种程序设计方法及相关的工具,只是从形式化语义理论及模块程序技术两方面各强调其中的一方面,并未能将二者有机地结合起来.
为了达到本书所强调的将这两个方面在时序逻辑语言XYZ桙E的基础上协调地结合起来的目标,XYZ系统又提出了第三种软件工程方法与工具.
近年来,CMU的学者们(D.
Garlan,M.
Shaw等)特别强调软件体系结构的选择在软件开发过程中的重要意义,我们针对XYZ系统的特征提出一种可视化软件体系结构描述语言XYZ桙ADL(ArchitectureDescriptionLanguage),并以它作为应用XYZ系统设计软件时的用户语言.
它以组件(component)作为一软件系统的基本构件(事实上它是模块概念的推广),每一组件包含两个方面:一是其外部界面(interface),即以其规范来表示;另一是其内部结构,即其体系(architecture),它以XYZ桙ADL的图形来表示.
由前者向后者转换,即构成软件开发过程的一步过渡(transition).
因一组件的体系结构中又包含下层的组件,它们亦由上述两方面构成并进行过渡,这样的逐层过渡即构成开发该软件系统的逐步求精过程.
对于XYZ桙ADL而言,每当描述一组件的体系结构后,即将自动生成一描述该体系结构语义的XYZ桙E程序.
将此XYZ桙E程序与该组件的规范相互结合即可应用XYZ系统中提供的验证或模型检验工具检验这一步过渡的语义一致性,这样即将前两种方法的主要特征结合起来了.
在XYZ系统中将提供关于软件开发的上述三类软件工程方法与工具.
在开发一软件时,每一种方法与工具均可独立使用,也可将该软件划分成语义独立的模块,分别各用上述一种方法与工具进行开发,然后(最好是以通信的方式)再将它们联成一个整体.
在本书下册第八、九、十这三章将分别对这三种软件工程方法与工具及相应的逐步求精过程作较详细的介绍,并将以具体例子作为示范说明.
②在大型程序设计中往往出现这种情况,即有时需要在某些部分嵌入用其他程序写的久经使用的程序,在软件再造工程及某些专用领域应用系统中有时也有与此类似的需要.
为了提供用户处理这类问题的手段,XYZ系统中提供一种将用其他语言书写的程序转换成XYZ程序的简便的形式化方法.
我们已用此工具将SDL,ESTELLE,VHDL等这些专用领域国际标准语言转换到XYZ桙E,看来效果相当不错.
关于这部分的讨论即构成本书下册第十一章的内容.
XYZ系统的特征决定了本书的特征.
本书既不应是一本主要讨论时序逻辑理论的专著,也不应是一本主要介绍各种软件工程工具技术的教程,它旨在较全面而准确地介绍XYZ系统.
在介绍时序逻辑语言XYZ桙E时,首先是面向程序工作者,将XYZ桙E作为一程序语言,而不是作为一逻辑系统来介绍,但另一方面又随处指明它仍保持其为时序逻辑理论系统的特征;在介绍各工具时,首先将其作为软件工程工具来介绍,但另一方面又随时说明它与时序逻辑语言XYZ桙E的内在联系.
我深知,这样一本介绍兼具理论与技术双重特征的系统的书,本身存在着内在的矛盾,它所具有的"中道"性质的陈述方式很可能同时引起来自理论界与工程界双方的不满.
我记得在钱学森先生所著枟工程控制论枠英文版的序言中也曾谈到,该书的陈述方式很可能"按数学著作的标准看不够严谨慎重",而"从介绍工程系统的著作的标准看又包含数学理论太多".
我在书写本书时,实在·viii·也感到类似的困境,深觉无法避免.
我们认为对于这种深层的矛盾,采用"中庸之道"的方法来对待是较为合适的,这也许正是"技术科学"的内在特征所在,望能得到读者的谅解.
由于XYZ系统规模十分庞大,研制时间长达近15年,且参加人员流动性很大,这就决定了它的研制人员的结构具有如下特征:一方面研制这一系统只可能是集体的工作,另一方面为了使这一系统不致成为松散无章的堆砌物,它又应是一个在一人的思想指导之下按照非常紧凑统一的设计思想与理论完成的系统.
事实上,XYZ系统正是如此.
近20年来,参加人员50余人,平均每人参加时间约为2~3年,他们绝大多数参加了各子系统或工具有关设计的讨论与实现,惟我一人一直从头到尾主持并实际参与此项工作.
其语言设计、工具所支撑的方法及解决关键技术难题的方案研究等,除了少数部分外,主要皆由我负责.
当然,这过程中不少人也参加了讨论并提出过很好的建议,为了节省篇幅,很难在此列举各参加人员的参与情况.
不过在本书后面参考文献中,可查出对XYZ系统作出过贡献的人员的姓名.
本书撰写情况也与上述情况相似,也是由我负主要责任,从总体思想到XYZ桙E语言及各种软件工程方法的设计与介绍都由我完成,而对各工具系统具体实现的技术内容以及其应用实例的介绍,则一般由负责实现或修改该工具的人员且目前仍在我组工作或学习的人执笔,最后在文字上由我加以统一.
在书写有关部分、调试例题、对全书进行录入、编辑排版以及其他各项工作中,赵琛、沈武威起了较大的作用,谢育涛、高永祥、闫安、沈伟、唐小平、张小格、骆华俊、郭亮、朱雪阳等都负责完成了与他们有关的部分.
中国科技大学的孙淑玲教授与她所领导的科研集体以及李广元副教授分别编写了本书下册第十一章(即语言转换)、第七章与第十二章有关的内容和附录Ⅱ.
本书第七章介绍的Hoare逻辑验证工具XYZ桙VERI是张文辉博士的工作,何锫也在这系统中进行过长期的研究,北京航空航天大学的张玉平副教授曾参加过附录Ⅱ初稿的撰写工作.
此外,石民勇博士、王春江博士、张广泉博士先后阅读了各章,并检查了各方面可能出现的疏漏.
在这方面,张广泉、王春江两位博士贡献较大.
我所研究员柳军飞曾在完成本系统"八五"计划的项目研究中起了很重要的领导组织作用.
本系统及本书得以完成,的确是这个集体所有成员共同努力的结果.
值得令人引以为慰的是,近20年来,XYZ小组一直是一个团结的、有向心力的集体,其成员不但在组内工作与学习时是如此,甚至他们离开多年后(现在大多数都在国外),仍对这个集体的工作予以关心,经常为XYZ系统的完成提供各种帮助.
在本书完成之际,我应指出,如果XYZ系统将来被证明是一项有价值的工作,这成绩首先应归功于这个集体.
还有一点应当指出,本书下册中许多关于XYZ系统应用的介绍都是基于我组人员与其他单位人员合作应用XYZ系统所得到的成果.
在此我们对这些兄弟单位及有关人员表示谢意.
最后,借此机会感谢为XYZ系统的研制以及本书的出版提供各种支持、关心以及帮助的单位与友人.
近20年来,国家自然科学基金委、国家科委"863"计划、电子工业部一直提供经费支持.
中国科学院及我先后所在单位,如计算技术研究所与软件研究所的负责人,一直对我们的工作给予信任、支持与关心;如果没有中国科学院,特别是软件研究所基础部这样的科研环境,我相信,XYZ系统是不可能完成的.
此外,多年来国内外许多朋友也一直为我提供各种精神与物质的帮助.
在此,我还应特别提到几位国外的朋友对我的工作的支持和帮助,他们是J.
McCarthy,D.
Knuth,Z.
Manna,A.
Pnueli,R.
T.
Yeh(叶祖·ix·尧),N.
Habermann,D.
Bjorner,E.
Engeler,H.
D.
Ehrich,A.
Solvberg,K.
Kishida(岸田孝一)等.
过去我多次应邀去他们所在的大学或研究机构的访问对XYZ系统的形成很有影响[T13].
本书得到中国科学院科学出版基金、国家自然科学出版基金和华夏英才基金的资助.
最后,还应该特别提到的是30余年来与我冷暖相依的伴侣童恩健及我的两个儿子其深与其放对我的工作与生活的支持与关心.
对所有这些朋友与亲人,我谨在此表示由衷的谢意.
唐稚松1998年10月(2001年11月修改)·x·下册补充说明近四五年来,美国开发的可视化面向对象建模语言(UML)被确定为国际标准,受到广泛注意.
它集中了软件工程领域具有美国风格的新技术,如面向对象建模技术、需求工程技术与可视化程序设计技术等.
其基本思路是:首先用具体实例表示需求,然后通过对象的嵌套对所表示的程序进行抽象,最后得到高度抽象的模型.
因为需求不是形式化表示的,无法用验证方法讨论模型与需求的一致性,只能通过执行表示其动态语义的程序对模型进行测试.
而以上各个环节在UML中都是用可视化图形表示的,其语义虽不十分严格,但具有直观性,便于理解.
此外,由于需求往往需要修改与补充,系统也随之变化,对此UML也作了安排,从这个意义上,由于UML与需求紧密相连,它也就必然与软件进化过程密切相关了.
容易看出,UML与XYZ系统恰好形成鲜明的对照,既可以说是相互对立的,也可以说是相互补充的.
事实上,各在不同的领域占优势.
UML是针对数据结构的,故便于表示数据量大的信息系统;XYZ则是针对控制结构的,故便于表示结构复杂的实时控制过程.
但二者并不相互排斥,在一定条件下可以结合.
下册一开始,在第八章介绍可视化工具时,我们假定了UML已被广泛理解①,未加太多的解释即引用其中的一些概念,特此提请注意.
此外,读者在阅读本书上册(科学出版社,1999出版)的过程中,如有疑问请查阅网页http:桙桙www.
ios.
ac.
cn桙news桙xz.
htm.
唐稚松2001年11月·xi·①参阅:刘超、张莉编著.
可视化面向对象建模技术———标准建模语言UML教程.
北京:北京航空航天大学出版社,2000.
目录上册时序逻辑语言第一章绪论11畅1程序技术研究30年11畅2哲学方法211畅3XYZ系统简介40第二章时序逻辑语言XYZ桙E的基础部分422畅1基本概念422畅2状态转换与单元472畅3三种不同形式的控制结构552畅4Horn子句语言XYZ桙PEO622畅5指针64第三章时序逻辑语言XYZ桙E的基层模块673畅1程序框架673畅2过程与函数703畅3包块78第四章时序逻辑语言XYZ桙E的并发成分834畅1进程与并行语句834畅2通信864畅3共享存储的并发进程934畅4面向对象的程序设计954畅5一种面向并发通信的计算过程的模块1014畅6分布式程序设计106第五章实时程序设计与混成系统表示1095畅1从XYZ桙BE到XYZ桙RBE1095畅2从XYZ桙SE到XYZ桙RSE1165畅3实时程序自动生成工具1205畅4蒸汽锅炉实时控制问题1265畅5混成系统在XYZ系统中的表示方法139第六章模型与实现1486畅1模型1486畅2实现153第七章程序规范与Hoare逻辑验证1637畅1程序规范与程序性质1637畅2Hoare逻辑1667畅3活性验证问题173·xiii·7畅4一些与常用成分有关的验证问题1757畅5并发通信问题无死锁的条件194附录ⅠXYZ桙E的语法公式表200附录ⅡXYZ桙E的理论基础216参考文献232下册软件工程方法与工具第八章XYZ桙E可视化集成环境2418畅1软件进化与软件开发过程2418畅2面向开发过程的XYZ桙CASE2478畅3一个开发实例262第九章规范导引的逐步求精过程与模型检验方法2679畅1逐步求精过程2679畅2基于XYZ桙E重构SZRTOS实时操作系统内核2719畅3速成原型方法3349畅4模型检验方法336第十章软件体系结构与XYZ系统34410畅1软件体系结构34410畅2软件体系结构的生命周期模型和建模35010畅3软件体系结构建模语言XYZ桙SAE35410畅4典型体系结构风格的XYZ桙E描述35910畅5可视化体系结构设计工具XYZ桙ADL36310畅6基于组件的由静态语义向动态语义逐步过渡的程序设计方法36710畅7协议描述与验证举例:RPC唱Memory(远程调用桘存储器)问题386第十一章语言转换及其在软件再造工程与专用领域软件开发等方面的应用424……11畅1语言的自动转换42411畅2静态语义处理42711畅3动态语义处理43511畅4国际标准专用语言到XYZ桙E的转换43911畅5XYZ桙E到Java的转换444第十二章连续时序逻辑与实时及混成系统的验证45112畅1连续语义线性时序逻辑LTLC45112畅2实时系统45612畅3混成系统464参考文献474名词索引482后记486·xiv·第八章XYZ桙E可视化集成环境①②本章第一节介绍目前存在的三种软件开发方法及相应的开发工具,并阐述由此引发的三种不同类型的软件开发过程.
本书第八、九、十章分别介绍这三种不同的软件开发途径.
本章将着重介绍面向正确性要求高的应用领域(如实时控制系统、某些反应系统(re唱activesystem)的核心部分等)软件开发全过程的软件过程辅助工具XYZ桙CASE.
其中第一节介绍了软件开发的全过程和XYZ桙CASE的作用;第二节主要介绍XYZ桙CASE的组成及各组成部分的设计思想;并使用了与标准建模语言UML一致的图符;第三节介绍一个实例.
XYZ桙E既可与UML的一个子集相连也可以抛开UML独立使用,对于用XYZ系统研发实时控制系统的用户可以跳过8畅2畅2节直接阅读8畅2畅3节.
8畅1软件进化与软件开发过程为了提高软件生产率,加强其可靠性、可维护性及可重用性,20世纪60年代以来,计算机科学与技术专家们对软件开发方法及其支撑工具进行了广泛而深入的讨论,形成了一研究领域———软件工程.
本书下册旨在讨论以上册所介绍的时序逻辑语言XYZ桙E为共同基础的软件工程方法与支撑工具.
易见,就XYZ系统而言,上册所介绍的时序逻辑语言XYZ桙E与下册将讨论的软件工程方法与工具是紧密联系的,两者密不可分而形成一个整体.
时序逻辑语言XYZ桙E是根据软件工程的方法与工具的需要和特性而设计的,它形成了后者的语义基础;反过来,前者的功能也只有依赖后者才能完整地体现,从而可应用于实际进行软件开发.
当然,这两部分的具体内容可能随着今后的研究与应用的发展而有所变化,但这两方面的总体上的依存关系却是不会改变的.
在讨论各种软件工程方法及相应的软件开发过程和工具之前,有一个基本事实应该提请注意:这一研究领域所讨论的对象(也就是软件系统)是一个包含巨大数量的基本元素及运算的非常复杂的系统.
专家们早期即已认识到,这一事实决定了这一领域的研究必然具有如下的特征:①为了使这一领域的研究成果具有科学性及技术上的可操作性,所讨论的基本元素(成分)及可施加其上的运算必须是概念明确的而不是含义混乱的;②由这些对象组成的系统必须具有合理的分层(嵌套)结构;③分析开发这样的系统必然需要形成一个循环进行的理性化过程,而不能依靠一时灵感.
对于满足以上特征的方法与工具的具体内容,本书后面将要分别讨论.
当前,我们面临的一个问题是这些讨论应从何处开始.
事实上,任何一软件系统的开发过程都不可能是无中生有而突然孤立地存在的.
从提出要求起经过开发过程到所需软件系统的完成,它都必然面对一个包围其外而对它的开发过程起影响作用的外在世界.
这个世界不但包·142·①②本书上册第一次印刷时为231页,第二次印刷时为240页.
下册的页码是按第二次印刷版的页码连编的.
本章由朱雪阳负责整理完成.
括它所赖以生存的物质环境,即在其上运行的计算机硬件、软件及其他资源,而且还包括用户提出其计划的目的和其他主观意图,还有市场的影响以及其他种种限制.
这个外在世界既包括该软件系统从开发起始即必须明确说明的方面(否则这项研制计划无法进行),也包含许许多多难以预先明确说明与界定的规定与条件.
这个外在世界一般统称为用户对这一软件系统的需求.
它既可以说是这个软件系统开发过程的起点,也可以说是它的归宿,或者可以说是整个开发过程的外在环境(为了讨论方便,我们在此暂不将需求与环境细分开来).
它独立于这个软件开发过程,但又对其直接产生影响,有些方面应反映在这个软件系统之中,有些方面则是处在这个软件系统之外,是该系统内所不能表示清楚的(比如市场竞争的效益等).
在软件开发过程之前,系统分析员与用户必不可少的一项工作就是对这种需求进行分析与讨论,也就是需求分析.
这一工作做得如何将直接影响后面对这个软件系统的开发过程及其成品的质量.
由于它对软件系统的开发意义重大,过去十多年来许多人对这部分工作进行了专门的工程性研究,统称为需求工程(requirementengineering).
此部分研究的目标、对象和方法与我们在本书下册所要讨论的软件开发过程所依据的方法与工具的研究有联系但又不能混为一谈.
所以,我们将需求工程的研究置于软件工程方法与工具的研究之前,而将二者区分开来.
此外,用户对于一软件系统的需求虽必须在该软件系统开发之前"在适当程度上"明确确定,但这并不是说,它在确定后永远不能改变.
事实上,一软件系统不论在完成时如何完善,即使当时看来原来的需求都已满足,但在交付使用一段时间后,该软件原来提出的需求往往还可能需要修改.
这种情况的出现可能是由于原来认识不够周全或者交付使用时未彻底查清本已存在的缺陷,还可能是由于后来此系统赖以运行的外在环境发生了变化从而引起了需求的改变.
总之,需求本身存在不断变化与更改的情形.
为适应需求的不断变化,软件系统也需要不断变化.
对一软件系统为适应需求变化而不断修改的过程通常称之为软件进化(softwareevolution).
此时,这系统的研制过程又要回到原来需求分析的起点,再重新开始新一轮的对该系统需求的分析、讨论与修改.
因此,这一软件进化过程形成一包围在本书所讨论的软件开发过程之外的循环圈.
对于这样一个软件进化过程,过去20年来也进行了卓有成效的关于软件计划管理的工具系统的研制.
近10年来,软件市场上已有不少功能很强的关于软件模块配置管理与版本控制系统、软件检测及系统综合支撑工具、软件计划管理工具等,我们统称之为软件进化管理工具系统,它对有关研制该软件系统的进化过程中各种信息进行管理,以备查询.
在XYZ系统中也曾开发过这类工具系统,后来感到虽然这类工具系统对于软件计划完成起十分重要的作用,但它毕竟是关于软件进化的,与我们在本书中所要着重讨论的软件开发过程本身不宜混在一起.
我们在本书所要讨论的软件开发过程是假定对该系统的需求在该时刻至少暂时已有一明确的决定,并以此明确的需求为基础可将其功能的语义作出确定的形式化的描述,然后将它转化成一可有效执行的算法程序的过程.
现在软件市场上已有很多先进的、功能很强的关于软件进化过程中信息管理的系统出售.
一台计算机装配有这类系统之后,一般均可与XYZ系统结合运行.
正如不宜将计算机上的操作系统、数据库系统的内容都包括在本书的范围内讨论一样,我们将这一部分有关支撑软件进化及计划管理工具的讨论以及其他许多复杂的有关需求工程方面问题的研究,都排除在本书关于软件开发方法与工具的讨论之外,不作详细讨论.
本书讨论的软件工程方法及工具与上述内容的关系如图8畅1所示.
·242·图8畅1软件开发全过程示意图易见,我们在这本书所着重讨论的软件工程方法与工具,只是需求工程与软件进化过程所构成循环圈中的一个内核部分.
这个内核虽与包围它的外围部分有原则的区别,但并非没有千丝万缕的联系.
比如,在需求暂已确定后,将之转化为由形式化语言表示的规范时,有时还需要对该需求进行分析.
这样的分析包括在我们在本书讨论的软件开发过程之内,是我们所关心的问题.
这与一般需求工程所讨论的那些对数据与结构的具有原始工程性的分析是有区别的.
因此,虽然我们在本书范围内将不详细讨论需求工程与软件进化方面的内容,但仍不免要不时地有所涉及,以便于使软件工程方法与工具的讨论具有较清晰的来龙去脉.
事实上,不论从技术上讲关于软件模块(或由此推广而成的组件的结构)的概念,还是从形式化理论上讲关于规范的概念,都还不存在国际统一的标准.
因此,世界范围内撰写的任何一本关于软件工程的著作,都是适应其作者所采用的模块概念与规范概念,而去规定其需求分析方法、程序转换方法及软件开发支撑工具的特征的.
我们在本书范围内竭力减少这种歧异,但仍觉得难以完全避免,在介绍模块的分析工具时,实际上就必须与某一具体的工程系统连接起来.
但是,总的讲,本书下册所讨论的内容大体上仍然是独立于需求工程与软件进化方面的具体规定的,但可与市场上常见的具有通用性的这类系统配合使用.
比如著名的面向对象建模语言UML,它是面向信息系统开发的全过程的,从需求开始,经历软件开发的各阶段,并随着软件进化,需求的不断改变,而重复应用它进行描述.
它是可视化的,但不是形式化的,可是如果将它与XYZ桙E结合,即可以对用UML描述的系统也进行形式化问题的讨论.
即在软件进化到一定阶段,需求相对确定(一般可维持数年的稳定)后,转入用XYZ桙E表示内层的逐步过渡(求精)过程,本章所介绍的XYZ桙CASE工具就是在这方面作的尝试.
当然,除了这一应用XYZ桙E系统支撑环境进行软件开发的途径外,也还有另一种直接应用XYZ系统中其他工具进行软件开发的途径,那是面向第九、十两章所介绍的逐步求精或逐步过渡过程的:从管理工具XYZ桙SPEC(见第九章9畅1节)出发再结合其他工具进行开发.
这个问题我们在此暂不讨论,待第九、十两章介绍以后读者自然也就清楚了.
我们在本书的第八、九、十章将分别介绍三类不同的软件开发方法与工具.
事实上,在过去30年中,为了实现提高软件生产率的目标,在软件工程领域中进行的各种讨论,归纳起来也不过形成了这三类不同的方法与工具.
大致说来,第八、九两章讨论的问题分别代表了早期出现的相互对立的研究方向,即分别从软件技术方面强调模块设计自动化与从形式化方法方面强调规范引导的逐步求精过程.
而第十章则讨论以近10年提出的基于组件的软件体系结构研究为基础,将以上两个对立的方面统一起来成为一完整的理论与技术紧密结合的软件开发方法.
这是本书在软件工程方面所要着重强调的内容.
第八章中将介绍基于模块的程序设计方法和支撑该方法的可视化图形工具.
这是以美国工业界为代表的一派,他们强调的是软件技术,认为提高软件生产率的主要途径应为·342·软件模块的设计自动化与可重用性(reusability).
早在20世纪60年代初,具有流程图结构的过程(procedure)以及后来在并发环境下具有的类似结构的进程(process)即是早期重要的模块结构.
不过,这类模块虽然必不可少,但由于其内部结构复杂,在大型软件中作为模块在进行分解与组合时不够方便,故以它们作为大型程序设计的模块结构不太合适.
近年来,具有封装性(encapsulation)与继承性(inheritance)的数据模块概念受到广泛的注意,特别是美国工业界对此投入了大量的研究经费,形成了关于对象(object)技术的方向.
在本书上册中介绍的时序逻辑语言XYZ桙E中也包含了这类模块概念,不过我们对之稍作扩充成为代理机构,使之能将远程通信及对象的智能或其他特征方便而合理地得到表示(我们在本书中限于篇幅只是提供了可能表示这方面内容的机制).
此外,我们认为还应该提出另一类模块概念即并行语句进程(PSP)作为补充.
它也是一种适于大型程序设计的基本模块概念.
不过要使该种结构的确可以作为模块来引用,它还必须满足语义可组合性(分解性)的条件(见第七章).
以上各类模块要能作为软件开发的基本构件组成所要求的各种软件系统,它们必须要能按一定的条件互相嵌套.
在XYZ桙E中有关模块嵌套的规则是:①一PSP系统中可嵌套包括PSP在内的其他各种模块,但它必须满足语义可分解性条件.
②一OO模块中可出现程序流图模块,但不能出现PSP模块;至于是否可嵌套OO模块,不同面向对象系统可作不同的规定,在XYZ桙E中则不允许.
③过程中不允许出现PSP模块及OO模块(但可调用OO模块中的操作,作为过程或通信进程),但可出现过程模块;在XYZ桙E进程中不允许嵌套进程.
④过程中只许嵌套过程,不允许嵌套其他模块.
按照这样的模块嵌套规则,在设计一程序时,按嵌套的层次顺序由外向内依次设计出相应的模块即可.
分析与设计模块的过程是由顶向下的,但将模块组织成为系统并予以实现,则应该是由底向上的.
至于支撑工具,面向实时控制系统开发的XYZ桙CASE集成了从分析描述到最终实现的几个辅助工具.
这套工具中包含了可用部分UML语言(类的描述、活动图)进行建模的可视化设计工具XYZ桙Designer、对建模得到的基本模块进行设计的图形化工具XYZ桙CFC、将XYZ桙BE转换成XYZ桙SE的转换工具XYZ桙BESE、对XYZ桙SE程序进行验证的XYZ桙VERI、将XYZ桙E程序编译成可执行程序的XYZ桙E编译器.
在利用XYZ桙CASE进行实际系统的开发时,可用可视化设计工具XYZ桙Designer描述需求分析得到的模型,对模型中的基本模块用XYZ桙CFC进行细节的设计后生成XYZ桙BE程序,通过XYZ桙E编译器生成可执行代码.
如有必要,可利用XYZ桙BESE将部分用XYZ桙BE描述的核心程序转换成XYZ桙SE程序,进入程序验证工具XYZ桙VERI中对其算法予以验证.
显然,这样的方法与工具都以软件技术为依据,其正确性只能依靠测试予以保证.
一般来说,这一方法往往与形式语义联系较少,故在模块嵌套时,对于其复杂的语义界面是否一致的问题无法讨论.
事实上,这种片面强调模块化技术而忽视形式语义的作法是有其不足之处的.
单纯依靠软件技术去讨论模块可重用性问题是不够全面的,其系统可能出现隐患.
因此,虽然关于软件开发方法与工具这方向的研究在以美国工业界为代表的软件界开展得十分热烈,可是西欧学术界则有不少人对这方向有些存疑.
这主要体现在以下几点:①像对象系统那样的模块在构造时往往要求对其领域特性作相当大量的分析,如果在此分析后所得到的系统重用的次数不多,则构造这样的系统很可能得不偿失.
这个问题在构造这样的系统时是应认真考虑的,因为构造一领域的对象系统之前应对该·442·领域作详尽的分析,其工作量是非常巨大的.
②对于有些系统(如实时控制系统),用对象系统表示既未必方便又未必经济.
可见,基于UML的软件开发固然适用于很多类型软件,但在另一些情况下,独立于UML而直接应用XYZ系统的工具进行软件开发也是有意义,甚至是很有必要的.
所以本书在第九、十章还介绍了另外的开发过程和方法.
与上面这一关于软件开发的方法与工具的方向针锋相对,另一具有代表性的研究方向认为提高程序可靠性与可维护性是达到提高软件生产率目标的主要途径.
他们以西欧学术界为代表,长期以来致力于使软件语义得到精确描述,强调软件规范的精确性与系统的可靠性,也就是开展关于语义形式化方法的理论研究,以此为基础,再进一步研究如何表示程序"做什么"的规范语言以及如何验证程序正确性的问题.
随着这些方面研究的逐步深入,近年来又与软件工程结合开展以形式语义理论及规范语言为基础的软件开发方法与支撑工具的研究.
过去,由于形式语义问题难度很大,西欧计算机理论界专家探索过从各种抽象数学理论借用来的形式化方法.
往往由于其数学理论要求太深而且与软件技术的表示形式差别太大而难以为广大的软件工程师所接受,致使这些理论与软件技术结合太少,应用于解决实际工程问题有些困难.
近年来,这方面的情况正在改变,本书上册中的时序逻辑语言XYZ桙E的提出即旨在解决这个问题.
由于适应于冯·诺伊曼计算机的常用程序语言都是以自动机状态转换机制为基础的,其语义是动态的,而规范语言自从指称语义提出以来多数以静态语义为基础,二者截然分离,很难交接,也难以将动态语义与静态语义在统一的程序描述之中表示.
XYZ桙E则不同,它不但具有与常见程序语言相同的程序风格,而且可以相同的形式框架既表示程序的静态语义又表示程序的动态语义,故二者可混合在同一XYZ桙E程序中出现.
这样就为直接用统一的形式语言表示程序的逐步求精开发过程以及验证相邻二步之间程序的语义一致性提供了方便.
用这样的方法处理程序开发过程,可使一复杂的软件系统分解成许多步来处理,每一步所加工的程序段都变成易于理解和验证的,这就是这一方法的优越性之所在.
对这种基于形式语义的完整的程序开发过程及其相应的方法与工具的介绍,即构成本书第九章的内容.
此外,由于程序验证比较烦琐,事实上不能说每一程序都需要用如此繁重的方法来检验其正确性.
为此,20世纪80年代初,E畅M畅Clarke与E畅A畅Emerson提出了另一种检验程序正确性的方法,称为模型检验(modelchecking),近年来它已经引起理论界与工业界的广泛重视.
这方面的基本思想是找出一种形式系统(语言),它一方面是可判定的,另一方面可表示如下形式的公式:M→Φ(8畅1)其中,M表示所要验证的程序的模型(即能表示程序功能的框架),Φ表示所欲验证的性质或规范.
因该系统是可判定的,故存在一可执行的程序来判断式(8畅1)是否为真,也就是用该程序的执行来判断是否可从M推出Φ,以代替验证.
由于命题线性时序逻辑恰好是这样一个形式系统,它所表示的任一合式公式是否可满足是可判定的.
前些年,Manna和Pnueli及其学生找到了一种高效的判定算法,并已实现成为可有效执行的程序,利用此系统可以得到XYZ系统的模型检验法.
因此,我们可用此系统(稍加扩充)以取代麻烦的Hoare验证系统来论证一XYZ桙E程序是否具有某性质.
总之,这第二种基于形式规范的软件开发方法近年日趋成熟,逐渐可解决具有实际意义的工程问题,其优点是有较强的理·542·论基础,语义精确性可得到保证,有助于语义可靠性与程序可维护性的提高,其明显的缺点是,它与软件技术界长期强调的程序模块化技术之间的关系甚少,在加强程序可重用性方面未起直接的作用.
第十章所介绍的软件开发方法与工具可以说是将其前两章所讨论的两种对立的研究方向综合而成的.
这一研究方向的特征就是将组成软件的基本构件的体系结构(architec唱ture)与作为组件外部界面形式规范所表示的功能这对矛盾的两方面联系起来.
事实上,人们在设计一软件系统时,往往首先即要分析该系统是由怎样一些基本体系结构嵌套组合而成.
这些基本体系结构包括并行语句(由通信命令联系或是通过共享变量联系)、Cli唱ent唱Server结构、流程图结构、面向对象结构、Pipe唱Filter结构、Event唱based结构等等.
20世纪90年代初开始,CMU的一些学者如D畅Garlan、M畅Shaw继D畅E畅Perry与A畅L畅Wolf等之后,总结了这一关于程序结构的新的大方向,它事实上是过去软件工程界所讨论的程序模块概念的进一步发展,由此开始提出并讨论以这些体系结构作为构成软件系统的基本元素的软件开发方法.
每一体系结构必然是由一些下一层的组件(component)以某种连接方式连接而成.
每一组件可从内外两个方面来看它:对外而言它为一个界面,即表示其功能特征的规范;对内而言它具有其内部的结构,也就是其体系结构.
这一体系结构又是由若干组件经某一连接方式连接起来,这些子组件又各有其表示其功能的对外界面,以及相应地表示其内部结构的体系结构,如此等等,直到最后的组件中界面与体系结构已不可再分为止.
首先,从需求得出它的规范,然后再将它过渡到其相应的体系结构.
软件设计的过程就是由这种组件的界面向其相应的体系结构的过渡所组成的序列,这序列也就构成一逐步求精过程.
显然,这里存在的一个问题即如何保证这一过程是正确的,也就是问:如何保证每一步由其界面规范向其相应的体系结构过渡仍能保证其语义一致性这是这一研究方向中的主要问题之一.
这一方向的研究具体作法有很多.
我们在第十章中介绍一种具有XYZ系统特点的方法,首先,XYZ系统中包含一可视图形语言XYZ桙ADL,可用来描述设计组件体系的各种体系结构,用户在应用XYZ系统设计一软件时,首先即用XYZ桙ADL设计组件所需的体系结构,由于它是以可视化图形表示的,所以很直观,易于理解;更重要的是,在每一步将所需的体系结构设计好之后,系统即可根据这一体系结构所提供的信息,自动生成表示其语义的时序逻辑语言XYZ桙E程序,程序结构与其相应的语义事实上是一一对应的.
所以,也可以由XYZ桙E表示的语义自动生成相应的体系结构图形.
由于上述体系结构既将提供与联系图所表示的动态语义,又将提供由它们包含的各组件的界面的规范所表示的静态语义,故表示该组件体系结构的语义程序必须能将动态语义与静态语义组织在统一的程序框架之中.
据我们所知,目前除XYZ系统外,尚未见其他系统能自动生成这样的形式化语义程序.
这语义程序的重要意义即在于用它即可方便地证明这一步过渡过程中其体系结构与规范的语义一致性.
XYZ系统提供的Manna唱Pnueli实现的模型检验系统或本书第七章介绍的Hoare证明系统即可用来自动地验证XYZ桙E所表示的该组件的体系结构的形式语义程序与这组件的界面所表示的规范两方面语义的一致性.
本书第八、九、十章即包含以上三个方面的内容.
事实上,这三章正好说明了过去30年来关于软件工程方法与工具以及相应的软件开发过程中三个不同时期所强调的三个不同的途径.
从我们的观点看来,第八、九两章的内容都只是为介绍第十章的内容作不同方·642·面的初步准备.
显然,我们这里所介绍的内容是以时序逻辑语言XYZ桙E为统一基础来陈述的.
由于XYZ桙E具有作为形式化语言能够统一地表示程序的动态语义与静态语义的特征,故适合担任这一角色.
本书用三章的篇幅介绍软件工程这三个方面的主要内容,可使读者比较清楚地了解这一领域的历史发展情况,从而加深对第十章内容的认识.
至此,本书所希望达到的将时序逻辑程序设计与软件工程相结合以表示软件开发全过程的主要目标,可以说已基本完成.
下面将简要说明第十一章、第十二章的内容及其作用.
在第十一章,我们将补充另一方面的内容,正如我们一开始即已指明的,本书的所有讨论都是以时序逻辑语言XYZ桙E为统一基础的,也就是说,它们讨论的对象必须是以XYZ桙E表示的程序.
这里自然就产生一个问题:在许多专用领域,已有国际上普遍接受的国际标准语言,它较好地反映了该领域的许多重要特征,已为用户广泛接受,而且已有了用该语言编写的标准子程序库.
对于这样的用户,XYZ系统是否还起作用呢类似地,在国际软件市场上,目前广泛存在软件再造工程(softwarereengineering)问题亟待解决.
其中许多系统有待更新,但其中许多用其他语言编写的子系统已成功地应用多年,用户不希望再重新编制这些子系统.
对于这样的软件系统的再造工程问题,XYZ系统如何起作用为了解决以上这些问题,在XYZ系统中提供了一种很简便的形式化方法,它能将一具有高级语言结构的源语言程序自动地转化成XYZ桙E,它只要用一简单的元语言写出将源语言的动态语义转换到XYZ桙E的转换文本即可.
但它要求在应用这类转换之前,必须在对源语言静态语义检查时(即检查参量类型一致、同名、作用域一致性等),将上下文相关信息予以替换.
这一点,在源语言的编译程序中,名字表部分都是必须进行处理的,所以并不存在不可克服的困难,在第十一章中我们将讨论这个问题,它在应用XYZ系统开发专用领域软件以及软件再造工程中有其特殊的作用.
为了说明第十二章的内容与作用,在此应提醒读者注意,XYZ系统的基本服务对象是冯·诺伊曼型计算机上的程序设计.
因此,它所表示的程序空间基本上是离散型的,基于自动机状态转换机制的,这对于一般的用户是便于接受的.
我们前面也曾讨论过混成系统的表示问题,事实上仍然是局限在离散空间进行讨论,并没有着力去解决连续空间问题.
此外,关于含共享变量的进程如何验证等方面的问题也没有讨论.
第十二章即专门讨论这些方面的问题.
这一章是由李广元博士的学位论文整理而成,它形成了统一的理论系统,可以说是XYZ系统向连续空间的拓展.
它事实上已超出了冯·诺伊曼模型的范围,也超出了XYZ系统的范围.
8畅2面向开发过程的XYZ桙CASE正如上节所述,我们所着重讨论的软件工程方法与工具,只是需求工程与软件进化过程所构成循环圈中的一个内核部分,所以我们建立的XYZ桙E集成化支持环境———XYZ桙CASE就是基于这样一个假设:外围的需求工程或软件进化已进行到一定阶段,系统需求相对确定.
在这个基础上,我们利用可视化系统设计工具来描述已确定的需求模型,并将之转换成XYZ桙E语言,进入XYZ系统的研究范畴.
需要指出的是,我们已经实现了多个XYZ桙E的可视化工具,可以支持软件开发的各个阶段,考虑到UML语言的广泛流行,我们在XYZ系统的可视化语言上作了大的调整,·742·在可视化系统设计工具中采用标准建模语言UML的一个子集作为XYZ桙CASE的模型描述语言的一种参考.
这样既可以与国际标准接轨,又可对UML的形式化研究作一些探索.
8畅2畅1XYZ桙CASE构架XYZ桙CASE中包含了可用部分UML语言(类图符、活动图)进行建模的可视化设计工具XYZ桙Designer、对建模得到的基本模块进行设计的图形化工具XYZ桙CFC、将XYZ桙BE转换成XYZ桙SE的转换工具XYZ桙BESE、对XYZ桙SE程序进行验证的工具XYZ桙VERI、将XYZ桙E程序编译成可执行程序的XYZ桙E编译器.
它们之间的关系如图8畅2所示.
图8畅2XYZ桙CASE构架图在利用XYZ桙CASE进行实际系统的开发时,可用可视化设计工具XYZ桙Designer描述分析得到的模型,对模型可再通过XYZ桙Designer中的活动图或用XYZ桙CFC进行细节的设计后生成XYZ桙BE程序,通过XYZ桙E编译器生成可执行代码.
如有必要,可利用XYZ桙BESE将部分用XYZ桙BE描述的核心程序转换成XYZ桙SE程序,进入程序验证工具XYZ桙VERI中对其算法予以验证.
关于XYZ桙VERI,已在第七章作了介绍;关于XYZ桙E编译器,将在第十一章介绍.
以·842·下介绍XYZ桙Designer、XYZ桙CFC、XYZ桙BESE的设计思想.
8畅2畅2可视化设计工具XYZ桙Designer1畅标准建模语言UML简介UML是OMG(ObjectManagementGroup)于1997年11月批准的标准建模语言.
为了能支持从不同角度来考察系统,UML定义了10种模型,可以分为5类:第一类是用例图,它从用户角度描述系统的功能,并指出各功能的操作者.
第二类是静态图,包括类图、对象图和包图.
其中类图用于定义系统中的类,包括描述类之间的联系以及类的内部结构,即类的属性和操作.
对象图所使用的表示符号与类图几乎完全相同.
一个对象图是类图的一个实例.
包图由包或类组成,主要表示包与包、包与类之间的关系.
包图用于描述系统的分层结构.
第三类是行为图,描述系统的动态组成对象间的交互关系.
一种是状态图,它描述一类对象的所有可能的状态以及事件发生时状态的转移条件.
另一种称作活动图,它描述为满足用例要求所要进行的活动以及活动间的约束关系.
使用活动图可以很方便地表示并行活动.
第四类是交互图,描述对象之间的交互关系.
一种称之为顺序图,用以显示对象之间的动态合作关系.
它强调对象之间消息发送的顺序,同时也显示对象之间的交互过程.
另一种是合作图,它着重描述对象间的协作关系.
二者很相似,如果强调时间和顺序,应当使用顺序图;如果强调通信关系,则可以选择合作图.
第五类是实现图,包括构件图和配置图.
构件图描述代码部件的物理结构以及各部件之间的依赖关系.
配置图定义系统中软硬件的物理体系结构①.
UML的目标是以面向对象图的方式来描述任何类型的系统,具有很宽的应用领域,适用于软件开发的多个阶段.
而我们目前的XYZ桙CASE把目标指向如实时控制系统这类应用领域,它们的对象成分相对简单而正确性要求高,工具的入口从通常意义上的需求分析结束开始.
所以在可视化设计工具XYZ桙Designer中,只需要UML的一个子集作为我们的建模语言.
2畅XYZ桙Designer的主要功能我们取了UML中的类图符、活动图作为XYZ桙Designer的建模语言.
对一个系统建模,可用几个类图符来说明系统中的对象情况(因为XYZ桙CASE所面向的问题领域中对象类的关系相对简单,无需使用类图),用一组活动图来说明系统中各个层次的活动流程,达到对整个系统进行描述的目的.
3畅XYZ桙Designer的设计思想XYZ桙Designer的实现从本质上说,不属于XYZ系统的研究范围,所以在此只想简单说·942·①参阅:刘超、张莉编著.
可视化面向对象建模技术———标准建模语言UML教程.
北京:北京航空航天大学出版社,2000.
明一下总体的设计思路.
XYZ桙Designer从UML中选取的图符有:类图符、活动图的部分相关图符,它们的含义与其在UML中定义相同.
表8畅1列出在XYZ桙Designer中使用到的图符及其含义.
表8畅1XYZ桙Designer图符可视化图符名称描述类ClassNotation定义共享数据结构、共享操作.
可以只有数据结构没有操作,也可以只有操作没有数据结构,或者二者都有起点StartPointNotation用于表示活动图中所有活动的起点.
每一幅活动图有且仅有一个起点.
入口标号固定为START,有一个与控制流的连接点终点EndPointNotation用于表示活动图中所有活动的终点.
每一幅活动图有一个或多个终点.
入口标号固定为STOP活动ActivityNotation表示活动图中所有描述过程或算法的某一步.
分两类,原子活动Action,不可再细分(语句);可再细分成多个活动的组合的复合活动Activity,一般可用另一张活动图加以描述.
有一个入口标号DefLabel,有一个与控制流的连接点判断BranchNotation特殊活动的一种,用于表示活动流程的判断、决策.
有两个或两个以上的控制流从它引出,表示决策后的不同活动.
有一个入口标号DefLabel,有多个(两个或两个以上)与控制流的连接点控制流ControlFlowNotation用于连接各种活动(Activity、Branch、StartPoint、EndPoint).
表示各活动的转移.
箭头指向所连接活动的DefLabel利用XYZ桙Designer辅助对应用系统的开发过程中,将项目(Project)作为一个整体来管理,由一组类图符和一组活动图(一个主图和几个分图)组成.
以公式形式表示如下:Project∶∶=ProjectHead∪ActivityDiagramSet∪ClassNotationSetProjectHead∶∶=ProjectName∪GlobalDeclPartProjectName∶∶=NameGlobalDeclPart是关于全局的声明部分.
ClassNotationSet∶∶={ClassNotation}ClassNotation∶∶=类中的操作(Operation)也是对活动的描述,就是复合活动.
ActivityDiagramSet∶∶=MainActivityDiagram{∪PartActivityDiagram}MainActivityDiagram∶∶=ActivityDiagramPartActivityDiagram∶∶=ActivityDiagramActivityDiagram∶∶=ActivityHead∪Diagram·052·ActivityHead∶∶=ActivityName{∪ParameterDeclPart}1∪PartDeclPartActivityName∶∶=NamePartDeclPart是关于本活动内部的声明部分,ParameterDeclPart是关于本活动有关参数的声明部分.
上述各公式中:{A}ji表示"i到j个A";i缺省表示i=0,j缺省表示任意多个;∪A表示"和A";Project总体框架与XYZ桙BE的对应关系如表8畅2所示.
表8畅2Project总体框架与XYZ桙BE的对应关系名称XYZ桙BE描述ClassNotation%PACK[ClassName:…]MainActivityDiagram%OBPRGActivityName==[GlobalDeclPart;…]PartActivityDiagram%PROCActivityName(ParameterDeclPart)==[PartDeclPart;…]活动图Diagram的四个基本图元(StartElement,EndElement,ActivityElement,BranchEle唱ment)如表8畅3所示,它的组合规则与UML下的意义相同,它由一个StartElement起,有一个或多个EndElement,中间包含一至多个ActivityElement或BranchElement,例如求阶乘1!
,2!
,…,k!
之和的活动图如图8畅3所示.
用XYZ桙Designer中活动图的基本图元来设计XYZ桙BE程序,做到图形到程序的转换,要求图与程序的同态,即XYZ桙Designer中活动图的每个基本图元都能找到XYZ桙BE语言的语法对应.
活动图的基本图元的定义及对应的XYZ桙BE语句如表8畅3所示.
表8畅3活动图的基本图元与XYZ桙BE的对应关系图元名称说明XYZ桙BE语句StartElementDefLabel=START一个ForwardLabelLB=START痴S|OLB=ForwardLabel;ActivityElement一个DefLabel一个ForwardLabelActivity是一个语句或一个过程,它的内容由应用系统开发人员填写LB=DefLabel痴Activity∧S|OLB=ForwardLabel;BranchElement一个DefLabelN个ForwardLabelBranch是一个判断语句,包含N个条件Conditioni(i=1~N,N≥2)它的内容由应用系统开发人员填写LB=DefLabel∧Condition1痴S|OLB=ForwardLabel1;……LB=DefLabel∧ConditionN痴S|OLB=ForwardLabelN;EndPointElementDefLabel=STOPForwardLabel=STOPLB=STOP痴S|OLB=STOP;对于活动图中的复合活动Activity的细节设计有三个途径:一是再用活动图设计,直到图中的每个活动都是原子活动Action(语句);二是调用XYZ桙CFC利用XYZ图进行设·152·图8畅3求阶乘和的活动图计;三是直接用XYZ桙BE描述.
类中的操作(Operation)也是对活动的描述,就是复合活动.
XYZ桙Designer中暂时没有UML中原有的并行表示机制,对于包含并行的活动,可转入XYZ桙CFC(可表示并行)进行设计.
8畅2畅3XYZ桙CFCXYZ桙CFC是一种类似于CFC(ControlFlowChart)的图形语言,它是状态图同Petri网的结合.
它既能表示抽象的规范(Specification),又能表示具体的可实现的过程,而且它还能表示并发.
1畅XYZ桙CFC的主要功能XYZ桙CFC具有如下的主要功能:1)支持单个XYZ桙BE程序的分层设计.
为了实现XYZ桙BE语言的可视化设计,我们精心设计了XYZ桙BE语言的图形表示,即XYZ图.
同时,提供了直观的图形系统XYZ桙CFC,它具有对XYZ图的编辑和图形分解的功能.
由于引入了逐级分解的概念,所以它可以支持逐步求精地分层设计XYZ桙BE程序的方法.
2)支持XYZ图和XYZ桙BE程序自动转换.
XYZ桙CFC同时为用户提供了图形(即XYZ图)和文本两种方式,用户可以任意用其中之一去编写抽象的规范或者是具体的可执行的算法.
图形和文本之间可以自动地互相转换.
这样就为用户提供了灵活多变的设计手段,可以根据不同的阶段选择不同的方式.
3)支持单个XYZ桙BE程序的动态执行和调试.
XYZ桙CFC的动态执行就是要使用户能动态地解释执行一个图形方式的可执行算法.
用户要能随时对变量和要调用的过程进行说明,用户要能随时查看变量的当前值以及改变变量的当前值.
在过程调用的时候,用户所能见到的变量要能根据所在过程的不同随时变更(即仅能见到局部于本过程的变量以及全局变量的值的情况,并能对其进行修改).
4)系统的其他辅助功能.
根据软件工程的原则,本系统在安全性、错误检查等方面设置了较为完善的辅助功能.
当用户的操作将会使图形或文本窗口中的信息丢失,或使某文件的内容清除时,系统都将弹出对话窗口进行提示,让用户确认或取消该操作,或把将会丢失的内容存入文件再进行操作.
只要用户是从系统中正常退出,就不必担心信息的意外丢失.
例如,当用户用鼠标选中系统退出窗口时,系统将向用户询问是否确认要退出,若此时被编辑的图形尚未存入文件,系统会显示相应的信息并向用户提供三种选择:存盘退出,不存盘退出,或取消退出指令.
若在存盘过程中出现错误而未成功时,系统将自动取消退出操作,等待用户进一步的处理.
由这个例子可以看出,本系统在保证信息安全性的·252·同时也坚持了界面友善的原则.
图8畅4XYZ图的基本图元用户绘制XYZ图的过程中,系统将对图形进行严格检查,若某个图元的绘制不合规定,系统马上给出错误信息并取消该图元.
系统检查的错误包括语法方面的,如边的两端不在结点处、某种边的始端或末端所在结点的类型与语法规定不符等,这些检查保证了所画图形的正确性,进而保证了由图形到文本翻译的顺利进行;也包括画面方面的检查,如两个结点距离太近、两端连接于同一结点的边太拥挤等,以保证画面的清晰美观.
在由文本到图形翻译的过程中又设置了较为完善的错误检查和恢复体系.
文本到图形的翻译其实可以看成是一种编译,即由XYZ桙BE语言到XYZ图的编译,也要进行词法分析、语法分析和代码生成(此处代码即为图形).
XYZ桙CFC除了在词法和语法分析过程中设置了严格的错误检查外,还设置了错误恢复功能,具体手段如下:一是用添加符号的方法,在一些容易遗漏词法符号的地方,自动添加所需的符号,如条件元之间的分号、半边括号等.
二是跳过符号的方法,即在遇到错误时放弃此语法单元并向前搜索,直到可以进行正常分析,在存在很多错误的情况下能够继续分析.
这些辅助性功能的设置,保障了用户对本系统的顺利使用.
2畅XYZ桙CFC的设计思想(1)XYZ图的图元设计为了用XYZ图来设计XYZ桙BE程序,做到图形与程序之间的转换,则要求图与程序同构,即图形中的每一种图元都与XYZ桙BE语言的语法对应.
反之,XYZ桙BE语言的每种语法都能用图形表示出来.
XYZ桙BE语言的形式类似于状态转换,因此,XYZ图的结构与Petri网类似,节点由两类图元组成.
边的两端联结着节点.
为了方便画图时的布线,每种边都有直线边和曲线边两种形式,对应的语法完全相同,由用户自由选用.
为方便起见,下面介绍图元时只画出了直线边.
XYZ图的基本图元如下:1)标号节点.
对应于程序中某个过程中的某个控制标号所代表的状态,用图形图案表示.
如图8畅4(a)所示,图形的上半部可填入数字表示进程代号,下半部填入控制标号的取值.
反之,每个进程中的每个标号都需要一个对应的节点.
出入节点的边数是可以任意的.
2)基本条件元边.
对应于程序中某一基本条件元,用细实线表示,如图8畅4(b)所示.
condition和action分别对应于条件P和动作·352·Q,二者皆可为空(以下各种边的condition和action含义与此相同),它的两端联结着两个标号结点,可以不同,也可以是同一个.
3)行为描述边.
与基本条件元边类似,但动作部分用虚线画出,表示这只是抽象的行为描述,如图8畅4(c)所示.
4)等待条件节点.
为直观起见,对应程序中每一个等待条件产生一个此种节点,与下面的两种边一起构成等待语句的图形描述,如图8畅4(d)所示.
它本身并不对应于程序中的某个具体状态.
它用长方框来表示,下半部填写的是跳出等待状态的条件谓词S,上半部填的是此条件所依赖的进程代号,此代号需要由用户填写,也仅供用户参考,如果由系统自动分析将十分复杂.
直观上看,这种节点就像一个条件判断框.
如果是单个进程等待的情况,这种节点只有一条入边和一条出边,如果扩充为多个进程等待同一个同步条件的情况,则这些进程可以共享同一个等待条件节点,它将会有多条入边和多条出边,但两者数目必须相等.
这时此节点就显示了这些进程的同步切点(但同步条件并不一定只依赖于,甚至不依赖于这些进程).
5)等待语句入边.
对应每个等待语句,由这种边连接入口的标号节点和等待条件节点.
如图8畅4(e)所示,它的动作部分用双箭头表示,形象地描述了当指定条件不满足时动作重复和控制权滞留的情况.
6)等待语句出边.
对应每个等待语句,由这种边连接等待条件结点和出口的标号结点.
它表示跳出满足时控制状态的转移,因此没有自己的条件和动作,如图8畅4(f)所示.
7)并行结构条件边及隐含结点.
如图8畅4(g)所示,由于并行结构的状态转移个数不定,所以将并行结构的条件用粗实线边表示,一端连接某标号结点,另一端设一隐含结点,用来连接各并行分支的状态转移.
此处条件边和隐含结点总是联系在一起的,隐含结点不对应于某个具体状态.
条件边只表示条件部分,没有动作.
8)并行结构转移边.
表示某个并行分支对应的状态转移,即对应进程的触发.
如图8畅4(h)所示,它用粗实线表示,从并行结构隐含结点连接到目的过程的开始结点.
它没有条件,也没有动作.
9)选择结构条件边及隐含结点.
如图8畅4(i)所示,与并行结构类似,但隐含结点处的长条用粗虚线画出.
10)选择结构哨兵分支边.
如图8畅4(j)所示,对应选择结构的某个哨兵分支,从选择结构隐含结点连接到目的的状态的标号结点.
根据选择结构的语法,它既有条件又有动作,为与基本条件元边相区别,此边用粗实线画出.
(2)XYZ桙E程序与XYZ图的对应利用上面设计出的图元,就可以将五种形式的条件元与一定的图形对应起来:基本条件元LB=y∧P痴S|OQ∧S|OLB=z其对应的XYZ图如图8畅5(a)所示.
行为描述LB=y∧P痴(Q∧LB=z)其对应的XYZ图如图8畅5(b)所示.
等待语句LB=y∧P痴S|O(Q∧LB=y)S|SU(S∧LB=z)其对应的XYZ图如图8畅5(c)所示.
·452·图8畅5条件元与XYZ图的对应并行结构LB=y∧P痴S|O(p1∧p2∧…∧pk)WHERE‖[p1,p2,…,pk]其对应的XYZ图如图8畅5(d)所示.
选择结构LB=y∧P痴!
!
[S1|>S|OQ1∧S|OLBj1=z1,…,Sk|>S|OQk∧S|OLBjk=zk]·552·