实时UML——开发嵌入式系统高效对象(第二版)
基本信息
- 原书名: Real-Time UML Developing Efficient Objects for Embedded Systems ,Second Edition
- 原出版社: Addison-Wesley
- 作者: [美]Bruce Powel Douglass [作译者介绍]
- 译者: 尹浩琼 欧阳宇
- 丛书名: 软件工程丛书
- 出版社:中国电力出版社
- ISBN:7508318129
- 上架时间:2003-12-9
- 出版日期:2003 年12月
- 开本:16开
- 页码:252
- 版次:2-1
- 所属分类:
计算机 > 软件工程及软件方法学 > UML
内容简介回到顶部↑
嵌入和实时系统变得日益复杂,因此需要一种预先计划周详的、成熟的设计方法,如此方可成功地实现。基于对象的统一建模语言(uml)可以描述对于实时系统极为关键的结构和行为方面,并且已成为有效设计的优秀媒介。
就像畅销的上一版一样,第二版概述了实时系统的本质,并且介绍了侧重于设计和开发的uml。本书详细讲解了需求分析、对象结构和对象行为的定义、体系结构设计、机械设计、以及包含数据结构、操作和异常的更详细的设计。书中图文并茂,详细阐述了uml的设计技术,并且通过详细、直实的例子向读者展示了这些技术的应用。
本书以uml标准为基础,涵盖了动作主义元模型的状态图,并且深入描述和演示了如何有效地应用用例,以及捕获对象模型和状态行为。本书还介绍了作者多年研究的心血——嵌入式系统的快速面向对象过程(ropes),这是一个已得到证实的产品开发过程,以及一个新的uml扩展过程的补充。
[b]bruce powel douglass[/b] 是实时系统开发工具的主流厂商i-logix的技术总宣传师,对于uml最初规范的制订功不可没,并且还是对象管理组(omg)的实时分析和设计工作组的主席之一。他还为很多公司和机构,包括nasa,提供建大规模、实时、安全临界系统方面的咨询。他还写了其他四本实时和嵌入式系统方面的书。
就像畅销的上一版一样,第二版概述了实时系统的本质,并且介绍了侧重于设计和开发的uml。本书详细讲解了需求分析、对象结构和对象行为的定义、体系结构设计、机械设计、以及包含数据结构、操作和异常的更详细的设计。书中图文并茂,详细阐述了uml的设计技术,并且通过详细、直实的例子向读者展示了这些技术的应用。
本书以uml标准为基础,涵盖了动作主义元模型的状态图,并且深入描述和演示了如何有效地应用用例,以及捕获对象模型和状态行为。本书还介绍了作者多年研究的心血——嵌入式系统的快速面向对象过程(ropes),这是一个已得到证实的产品开发过程,以及一个新的uml扩展过程的补充。
[b]bruce powel douglass[/b] 是实时系统开发工具的主流厂商i-logix的技术总宣传师,对于uml最初规范的制订功不可没,并且还是对象管理组(omg)的实时分析和设计工作组的主席之一。他还为很多公司和机构,包括nasa,提供建大规模、实时、安全临界系统方面的咨询。他还写了其他四本实时和嵌入式系统方面的书。
作译者回到顶部↑
本书提供作译者介绍
Bruce由俄勒冈荒地的狼群抚养成人。3岁时开始自学读书,不到12岁就开始学习微积分。14岁辍学游历美国,几年后进入俄勒冈大学学习数学专业,并最终获得俄勒冈大学的运动生理学科学硕士学位、USD医学院的神经生理学博士学位。他在医学院期间创立了一个名为自相关因子分析的数学分支,为研究多细胞生物神经系统中的信息处理提供了一个强有力的数学工具。
Bruce作为软件开发人员,在实时系统领域工作了近20年,是实时嵌入式系统领域内著名的讲演者和作者。他是嵌入式系统(Embedded System.. << 查看详细
Bruce作为软件开发人员,在实时系统领域工作了近20年,是实时嵌入式系统领域内著名的讲演者和作者。他是嵌入式系统(Embedded System.. << 查看详细
目录回到顶部↑
前言
译者序
第二版序
关于作者
第1章 实时系统和对象简介
1.1 实时系统的特殊之处
1.2 关于时间
1.3 基于模型的开发
1.4 对象的优点
1.5 uml中的面向对象技术
1.6 uml的图和表示法
1.7 展望
1.8 参考文献
第2章 实时系统的需求分析
2.1 用例
2.2 补充用例的详细信息
译者序
第二版序
关于作者
第1章 实时系统和对象简介
1.1 实时系统的特殊之处
1.2 关于时间
1.3 基于模型的开发
1.4 对象的优点
1.5 uml中的面向对象技术
1.6 uml的图和表示法
1.7 展望
1.8 参考文献
第2章 实时系统的需求分析
2.1 用例
2.2 补充用例的详细信息
译者序回到顶部↑
三位面向对象方法学的创始人Rumbaugh、Booch和Jacobson共同合作,创立了UML(统一建模语言)。自从1997年UML被OMG采用为标准以来,历经多次修订。从UML 1.0一直发展到1.4,但就在译者翻译本书时,OMG已经通过了UML2.0提案。
统一建模语言将为软件开发商及其用户带来诸多便利。美国等计算机技术发达国家已有大量的软件开发组织开始用UML进行系统建模,学习和使用UML已经成为一种潮流。我国软件界对UML也相当关注,许多研究人员和技术人员已在几年前就开始了对UML的学习和研究。但由于UML的复杂性,仅通过UML的标准文献和国内目前的关
于UML的资料来掌握使用它不是一件轻松的事。为此,我们专门翻译了UML的代表作之一,也就是本书,以帮助那些急切地想了解UML的读者。
本书按照大多数开发项目都遵循的分析-设计-)实现等步骤来组织。第1章介绍了什么是实时系统和对象,以及UML在实时系统中的应用。讨论了UML中的面向对象技术,以及类和对象间的关联。类之间存在着五种关系:关联、聚合、组成、泛化和依赖关系。本章同时还简单地提到了UML的表示法。为后面章节的学习打下了基础。
第2、3、4章可算作一个部分,即分析。其中第2章讲述了实时系统的需求分析,第3章讲述了实时系统的对象结构分析,第4章讲述了实时系统的对象行为分析。
5、6、7章又是一部分,主要讲的是设计。根据所作决策的作用域,可以将设计分为三个部分:体系结构设计、机械设计以及详细设计。5、6、7章分别讲述了这三个阶段的设计。
到这里为止,实时系统中UML的知识已经全部介绍完了。但为了方便开发者在开发大型复杂系统时参考,附录A还提供了一个详细的表示法列表,虽然这些表示法在正文中都出现过。附录B讲了UML的前景。由于本书英文版在1999年就出版了,所以其中作的很多预测与展望,都不幸成为了历史。有兴趣的读者,参考相关资料,看看作者预测的是否准确。
本书由尹浩琼、欧阳宇主译,参与翻译工作的人员还有石朝江、李明、周刚、谢俊、谢小花。由于译者水平有限,书中错误与疏漏在所难免,欢迎读者批评指正。
2003年7月
统一建模语言将为软件开发商及其用户带来诸多便利。美国等计算机技术发达国家已有大量的软件开发组织开始用UML进行系统建模,学习和使用UML已经成为一种潮流。我国软件界对UML也相当关注,许多研究人员和技术人员已在几年前就开始了对UML的学习和研究。但由于UML的复杂性,仅通过UML的标准文献和国内目前的关
于UML的资料来掌握使用它不是一件轻松的事。为此,我们专门翻译了UML的代表作之一,也就是本书,以帮助那些急切地想了解UML的读者。
本书按照大多数开发项目都遵循的分析-设计-)实现等步骤来组织。第1章介绍了什么是实时系统和对象,以及UML在实时系统中的应用。讨论了UML中的面向对象技术,以及类和对象间的关联。类之间存在着五种关系:关联、聚合、组成、泛化和依赖关系。本章同时还简单地提到了UML的表示法。为后面章节的学习打下了基础。
第2、3、4章可算作一个部分,即分析。其中第2章讲述了实时系统的需求分析,第3章讲述了实时系统的对象结构分析,第4章讲述了实时系统的对象行为分析。
5、6、7章又是一部分,主要讲的是设计。根据所作决策的作用域,可以将设计分为三个部分:体系结构设计、机械设计以及详细设计。5、6、7章分别讲述了这三个阶段的设计。
到这里为止,实时系统中UML的知识已经全部介绍完了。但为了方便开发者在开发大型复杂系统时参考,附录A还提供了一个详细的表示法列表,虽然这些表示法在正文中都出现过。附录B讲了UML的前景。由于本书英文版在1999年就出版了,所以其中作的很多预测与展望,都不幸成为了历史。有兴趣的读者,参考相关资料,看看作者预测的是否准确。
本书由尹浩琼、欧阳宇主译,参与翻译工作的人员还有石朝江、李明、周刚、谢俊、谢小花。由于译者水平有限,书中错误与疏漏在所难免,欢迎读者批评指正。
2003年7月
前言回到顶部↑
嵌入式计算机系统,以及反应式和实时系统的时代已经到来。读完本书,你就会发现嵌入式系统无处不在;除了传统的桌面和膝上计算机,还有更多的计算机隐藏在无数的机器或设备里面。
哪里有计算机和计算机处理系统,哪里就有驱动它们的软件。软件不是从树上长出来的,而是人们不断地编写、理解、分析、使用、维护和更新的结果。是人的编程唤起了在抽象层次上建模复杂系统的需要,这比“一般”的编程语言要高一个档次。这也产生了对能引导软件工程师和编程人员处理建模过程的方法学的需要。
大家一致认为好的图解是设计高级建模方法所需奋斗的目标之一。虽然其他的东西同样重要,但是图片通常比文本或符号更容易理解。然而我们也并不是仅对图片或图表感兴趣,因为构建复杂的软件不只是人的活动。我们对图解语言感兴趣,而这些语言需要对验证和分析的计算机化支持。正如高级编程语言不但需要编辑器和版本控制工具,而且还(并且是支配性地)需要编译器和调试工具那样,建模语言不但需要漂亮的图形、文档生成工具和项目管理辅助,还需要执行模型,合成代码以及真假校验所需的手段。
这意味着我们需要视觉形式主义(visual formalism),这种形式主义是由语法和语义完善起来的,其中语法决定什么被允许,语义决定被允许的东西意味着什么。这种形式主义应该尽可能地可见(很明显,有些东西不会自动地让人看到),其中重心放在图解实体之间的拓扑关系上,然而作为次佳选项,也可以是几何和度量,也可能是图标。
在历史的长河中,曾经有两种主要的高级建模方法:结构化分析(structured analysis,SA)和面向对象(object orientation,00)。这两种方法在提出概念到开始发展有十年的差距。SA,在20世纪70年代末由DeDarco、Yourdon等人提出,将经典的过程编程概念提升到建模层次,并且完成图形化。于是就产生了通过功能分解和信息流实现,由(层次结构)数据流图描述的建模系统结构。至于系统行为,在上世纪80年代早期和中期曾出现过几个方法学团体(比如Ward/Melior、Hatley/Pirbhai和I-Logix的STATEMATE小组),他们提出了很多详细的建议,利用基于状态图或比状态图更丰富的语言捕获行为的手段丰富了基本的SA模型。我们应该添加的精心定义过的行为建模,对于嵌入式、反应式和实时系统尤其关键。
OO建模(通常叫做OO分析和设计,或者OOAD)起源于20世纪80年代末,并且它的历史在某种程度上与SA有些类似。系统结构的基本思想是将概念从面向对象编程提升到建模层次上,并且也是图形化完成的。因此,Booch方法、OMT和ROOM方法,以及很多其他方法中的对象结构模型开始处理类和实例、关系和角色、操作和事件、聚合和继承。可见性是通过将该模型建立在修饰过和浓缩过的实体一关系图的基础上获得的。至于系统行为,大多数00建模方法采用了状态图语言(一种决策,即签过名的人不能再声称自己对此不清楚)。状态图与每个类都有关联,它的任务是描述出实例对象的行为。结构和行为之间微妙和复杂的连接(即,对象模型和状态图之间的连接)被00方法学家们认真对待,从极度的不重视到足够重视。当然,测试要搞清楚结构和行为的语言以及它们的连接是否被充分地定义,以便支持高级模型的“解释”和“编译”——也即是说,完整模型的执行和代码合成,最终(并且很有希望)还有对需求的完全正式的校验。这只有在两种情况下才能实现,即在ObiectTime工具(基于Selic、Gullekson和Ward的ROOM方法)以及Rhapsody工具(来自i-Logix,基于Gery以及可执行对象建模上签名人的工作)中。
在系统建模方面,SA和00范例之间的共同点越来越少。在过去的四到五年里,很多00方法学家携起手来共同努力。他们交换意见,讨论问题,将各种00建模方法的优点结合在一起,最终合作制订出了一个通用的统一建模语言,或者简称UML。这场怀念Algol60和Ada的运动是在对象管理组的资助和Grady Booch(Booch方法的创始人)、Jim Rumbaugh(OMT方法的开发者之一)及IvarJacobson(用例之父)的领导下进行的。UML0.8在1996年发布,它有很多东西需要补充,并且很模糊,与人们期望的良构相差很远。一年之后,在很多公司的方法学家和语言设计者的帮助下,UML小组终于推出了更严谨和更坚固的1.0版本。此后还出现了很多版本的UML。1997年,UML被对象管理组(Object Management Group,OMG)采用为标准。如果再下些功夫,除了只是官方确认的标准之外,它还很有希望成为面向对象编程中的建模机制。这绝不是小事,因为越来越多的软件工程师意识到软件最好是用00风格开发。
对于系统结构的捕获,UML确实采用了基于实体—关系方法的类和对象的图解语言。对于早期行为分析,它推荐了用例,并使用了顺序图(通常称为消息顺序图,或者MSC)。对于行为的完整可构造规范,它采用了状态图,这在前面的可执行对象建模工作中已经修改过了。
Bruce Douglass做了一项很有意义的事情,他将自己的工程经验提供给那些必须构建复杂软件(尤其是实时、嵌入式和反应式软件)的人。况且,他是通过将UML用作底层的载体来完成这一点的。如果给定最近的UML标准化以及它们的快速扩展用法,那些总是担心这种系统不能快速和平稳开发的人会从中受益非浅。
另外,本书思路清晰,文笔流畅,读者看了之后会信心大增。之所以有这种感觉,主要是因为作者不像专业的方法学家那样高高在上使人敬而远之,而是紧密结合自己在工程中的实践经验,娓娓道宋,使人倍感亲切。这种区别可称为“系统行为的宏大二元性”。我们还没有能理解这种二元性的好算法。状态图看上去很适合对象内的规范,而顺序图则很好地指定了用例,但是它们的功能太弱,不能充当完全对象间规范这一角色(例
如,它们不能指定“反场景”——可以禁止的场景)。最近有人提议扩展顺序图,以便它们可以捕获更多的场景,但是评审团还没有参与进来。同样,我们也没有好的算法来理解建模的两个模式之间的二元性。我们不知道如何从一个视图派生出另一个视图,不知道如何有效地测试这两个视图中提供的描述是否互相一致。
随着UML的流行,关于这方面的各种书籍、文章、报告、研讨会和工具一定会泛滥起来。所以读者一定要仔细甄别,从中找出真正有价值的东西。我深信Bruce的书就属于这一类。
至于UML本身,我们必须记住一点:UML目前还有点过于庞大。我们只了解了其中的一部分;其他部分的定义还没有被详细制订出来,因此我们还不太清楚它们和UML可构造性核心(类图和状态图)的关系。例如,用例以及与其关联的顺序图和协作图对于试图按照场景找出系统所需行为的用户和需求工程师毫无价值。在用例领域中,我们为所有相关对象只描述了一个场景(或者紧密相关的场景的一个簇)——我们可以称之为对象间行为。与此形成鲜明对比的是,状态图描述了一个对象的所有行为——我们称之为对象内行为。
其他严重的挑战仍然存在,并且我们只解决了皮毛而已。这样的例子包括利用UML提供的高级手段建模的面向对象的软件的真正的、正式的校验,自动的、赏心悦目的、结构增强的UML图布局,处理包含离散、连续部件在内的混合系统的令人满意的方法等等。
作为处理复杂软件的一个通用方法,面向对象的方法必不可少。也许UML也是如此,不过我的个人感觉是随着成为建模软件标准的新鲜感的慢慢消退,UML将变得越来越小和严密。或者,变得太臃肿,而不能真正使用。我认为它会逐渐收缩,只留下三到四种真正有用的图,其余的逐渐被人遗忘,并最终完全消失。
00是分析系统以及编程的强大且明智的方法,并将在很长一段时间内成为那些有自尊心的软件工程师必需的知识结构的一部分。本书将帮助他们做到这一点。另一方面,00并不能解决所有的问题,UML也不能,仍然有很多工作需要完成。事实上,我们可以毫不夸张地说,我们未知的和做不到的远比我们已知的和能够做到的多。即使这样,我们现在所知道的仍然比我们几年前所希望知道的要多得多,所以我们应该时刻抱着感激和谦虚的心态。
以色列魏茨曼科学学院
数学和计算机科学系主任
David Harel教授于Rehovot
1999年7月
哪里有计算机和计算机处理系统,哪里就有驱动它们的软件。软件不是从树上长出来的,而是人们不断地编写、理解、分析、使用、维护和更新的结果。是人的编程唤起了在抽象层次上建模复杂系统的需要,这比“一般”的编程语言要高一个档次。这也产生了对能引导软件工程师和编程人员处理建模过程的方法学的需要。
大家一致认为好的图解是设计高级建模方法所需奋斗的目标之一。虽然其他的东西同样重要,但是图片通常比文本或符号更容易理解。然而我们也并不是仅对图片或图表感兴趣,因为构建复杂的软件不只是人的活动。我们对图解语言感兴趣,而这些语言需要对验证和分析的计算机化支持。正如高级编程语言不但需要编辑器和版本控制工具,而且还(并且是支配性地)需要编译器和调试工具那样,建模语言不但需要漂亮的图形、文档生成工具和项目管理辅助,还需要执行模型,合成代码以及真假校验所需的手段。
这意味着我们需要视觉形式主义(visual formalism),这种形式主义是由语法和语义完善起来的,其中语法决定什么被允许,语义决定被允许的东西意味着什么。这种形式主义应该尽可能地可见(很明显,有些东西不会自动地让人看到),其中重心放在图解实体之间的拓扑关系上,然而作为次佳选项,也可以是几何和度量,也可能是图标。
在历史的长河中,曾经有两种主要的高级建模方法:结构化分析(structured analysis,SA)和面向对象(object orientation,00)。这两种方法在提出概念到开始发展有十年的差距。SA,在20世纪70年代末由DeDarco、Yourdon等人提出,将经典的过程编程概念提升到建模层次,并且完成图形化。于是就产生了通过功能分解和信息流实现,由(层次结构)数据流图描述的建模系统结构。至于系统行为,在上世纪80年代早期和中期曾出现过几个方法学团体(比如Ward/Melior、Hatley/Pirbhai和I-Logix的STATEMATE小组),他们提出了很多详细的建议,利用基于状态图或比状态图更丰富的语言捕获行为的手段丰富了基本的SA模型。我们应该添加的精心定义过的行为建模,对于嵌入式、反应式和实时系统尤其关键。
OO建模(通常叫做OO分析和设计,或者OOAD)起源于20世纪80年代末,并且它的历史在某种程度上与SA有些类似。系统结构的基本思想是将概念从面向对象编程提升到建模层次上,并且也是图形化完成的。因此,Booch方法、OMT和ROOM方法,以及很多其他方法中的对象结构模型开始处理类和实例、关系和角色、操作和事件、聚合和继承。可见性是通过将该模型建立在修饰过和浓缩过的实体一关系图的基础上获得的。至于系统行为,大多数00建模方法采用了状态图语言(一种决策,即签过名的人不能再声称自己对此不清楚)。状态图与每个类都有关联,它的任务是描述出实例对象的行为。结构和行为之间微妙和复杂的连接(即,对象模型和状态图之间的连接)被00方法学家们认真对待,从极度的不重视到足够重视。当然,测试要搞清楚结构和行为的语言以及它们的连接是否被充分地定义,以便支持高级模型的“解释”和“编译”——也即是说,完整模型的执行和代码合成,最终(并且很有希望)还有对需求的完全正式的校验。这只有在两种情况下才能实现,即在ObiectTime工具(基于Selic、Gullekson和Ward的ROOM方法)以及Rhapsody工具(来自i-Logix,基于Gery以及可执行对象建模上签名人的工作)中。
在系统建模方面,SA和00范例之间的共同点越来越少。在过去的四到五年里,很多00方法学家携起手来共同努力。他们交换意见,讨论问题,将各种00建模方法的优点结合在一起,最终合作制订出了一个通用的统一建模语言,或者简称UML。这场怀念Algol60和Ada的运动是在对象管理组的资助和Grady Booch(Booch方法的创始人)、Jim Rumbaugh(OMT方法的开发者之一)及IvarJacobson(用例之父)的领导下进行的。UML0.8在1996年发布,它有很多东西需要补充,并且很模糊,与人们期望的良构相差很远。一年之后,在很多公司的方法学家和语言设计者的帮助下,UML小组终于推出了更严谨和更坚固的1.0版本。此后还出现了很多版本的UML。1997年,UML被对象管理组(Object Management Group,OMG)采用为标准。如果再下些功夫,除了只是官方确认的标准之外,它还很有希望成为面向对象编程中的建模机制。这绝不是小事,因为越来越多的软件工程师意识到软件最好是用00风格开发。
对于系统结构的捕获,UML确实采用了基于实体—关系方法的类和对象的图解语言。对于早期行为分析,它推荐了用例,并使用了顺序图(通常称为消息顺序图,或者MSC)。对于行为的完整可构造规范,它采用了状态图,这在前面的可执行对象建模工作中已经修改过了。
Bruce Douglass做了一项很有意义的事情,他将自己的工程经验提供给那些必须构建复杂软件(尤其是实时、嵌入式和反应式软件)的人。况且,他是通过将UML用作底层的载体来完成这一点的。如果给定最近的UML标准化以及它们的快速扩展用法,那些总是担心这种系统不能快速和平稳开发的人会从中受益非浅。
另外,本书思路清晰,文笔流畅,读者看了之后会信心大增。之所以有这种感觉,主要是因为作者不像专业的方法学家那样高高在上使人敬而远之,而是紧密结合自己在工程中的实践经验,娓娓道宋,使人倍感亲切。这种区别可称为“系统行为的宏大二元性”。我们还没有能理解这种二元性的好算法。状态图看上去很适合对象内的规范,而顺序图则很好地指定了用例,但是它们的功能太弱,不能充当完全对象间规范这一角色(例
如,它们不能指定“反场景”——可以禁止的场景)。最近有人提议扩展顺序图,以便它们可以捕获更多的场景,但是评审团还没有参与进来。同样,我们也没有好的算法来理解建模的两个模式之间的二元性。我们不知道如何从一个视图派生出另一个视图,不知道如何有效地测试这两个视图中提供的描述是否互相一致。
随着UML的流行,关于这方面的各种书籍、文章、报告、研讨会和工具一定会泛滥起来。所以读者一定要仔细甄别,从中找出真正有价值的东西。我深信Bruce的书就属于这一类。
至于UML本身,我们必须记住一点:UML目前还有点过于庞大。我们只了解了其中的一部分;其他部分的定义还没有被详细制订出来,因此我们还不太清楚它们和UML可构造性核心(类图和状态图)的关系。例如,用例以及与其关联的顺序图和协作图对于试图按照场景找出系统所需行为的用户和需求工程师毫无价值。在用例领域中,我们为所有相关对象只描述了一个场景(或者紧密相关的场景的一个簇)——我们可以称之为对象间行为。与此形成鲜明对比的是,状态图描述了一个对象的所有行为——我们称之为对象内行为。
其他严重的挑战仍然存在,并且我们只解决了皮毛而已。这样的例子包括利用UML提供的高级手段建模的面向对象的软件的真正的、正式的校验,自动的、赏心悦目的、结构增强的UML图布局,处理包含离散、连续部件在内的混合系统的令人满意的方法等等。
作为处理复杂软件的一个通用方法,面向对象的方法必不可少。也许UML也是如此,不过我的个人感觉是随着成为建模软件标准的新鲜感的慢慢消退,UML将变得越来越小和严密。或者,变得太臃肿,而不能真正使用。我认为它会逐渐收缩,只留下三到四种真正有用的图,其余的逐渐被人遗忘,并最终完全消失。
00是分析系统以及编程的强大且明智的方法,并将在很长一段时间内成为那些有自尊心的软件工程师必需的知识结构的一部分。本书将帮助他们做到这一点。另一方面,00并不能解决所有的问题,UML也不能,仍然有很多工作需要完成。事实上,我们可以毫不夸张地说,我们未知的和做不到的远比我们已知的和能够做到的多。即使这样,我们现在所知道的仍然比我们几年前所希望知道的要多得多,所以我们应该时刻抱着感激和谦虚的心态。
以色列魏茨曼科学学院
数学和计算机科学系主任
David Harel教授于Rehovot
1999年7月
序言回到顶部↑
我对《Real-Time UML:Developing Efficient Object for Embedded Systems》第一版的成功深感欣慰。我认为第一版之所以受欢迎得益于实时和嵌入式系统开发中对象技术(一般来说)和UML(具体来说)的时效性和适当性。在刚出第一版时,UML就有成为面向对象系统开发主力军的迹象。然而,即便是它最坚定的支持者也为它在开发者中受欢迎的速度和程度感到惊讶。一位曾支持另外一种建模方法的方法学家对我说,“我忽视了UML,所以很快就遇上了大麻烦。”不管从达尔文主义的角度来看,还是从它的技术优势来说,UML都取得了巨大的成功,并成为对象领域内占统治地位的技术。
随着嵌入式系统变得越来越复杂,过去的那套老办法彻底不管用了。当前系统的复杂程度驱使开发人员从不同的视角来构建模型,以便理解并规划系统的各个层面。这些视角包括物理或者部署视角,以及逻辑或本质视角。二者都必须支持结构和行为两方面。这就说明了UML是什么,以及它为什么如此成功。
读者
本书面向在职的专业软件开发人员,以及计算机科学专业的大三和大四学生。本书也可用作大学本科以及研究生教材,但是本书偏向于实际开发,而不是理论性的介绍。在本书中几乎找不到什么方程式,但是在适当的地方都标出了引用,以方便读者找到它们更详细的理论和数学解释。阅读本书至少需要掌握一门编程语言,并且大概知道面向对象和实时系统的基本概念。
目标
本书和第一版的目标一样,仍然希望成为介绍UML以其表示法和语义在实时和嵌入式系统开发中的应用方面的一本好读物。除本书之外,市面上还有一本关于UML和实时系统的书:《Doing Hard Time:Developing Real-Time Systems with UML,Objects,Frameworks,and Patterns》(Addison-Wesley,1999),这也是我写的。《Doing Hard Time》对实时系统的讲述更加深入,重点放在对象可调度性的分析、行为模式在状态图模型构建中的作用以及如何有效利用实时框架上。它更加深入地探讨了实时系统,并且正好也使用了UML来表达这些概念。与此形成鲜明对比的是,(Real-Time UML))主要讲的是UML,其次才是如何利用UML捕获实时系统的需求、结构和行为。
除了第一版的最初目标,第二版又增加了另外两个:1)使本书与UML标准的最新变化保持一致;2)在第一版反馈的基础上增强本书的有效性。
自从UML被OMG采纳为标准以来,出现过两次修订。第一个修订版1.2几乎全是编辑性的,没有显著的改动。而1.3则在各方面都进行了大的改动。例如,用依赖关系的《includes》构造型替换用例泛化的《uses》构造型,从而改进了不少东西。
同样,UML1.1中动作的概念严重依赖于用来捕获其细节的“未解释文本”。UML1.3细化了该元模型,从而包含了更多种类的动作,同时使行为建模更加完整。动作语义元模型以及它如何与对象的消息发送相关,将在第2和4章讨论。
1.3版中对状态图模型做了很多修改。本书的第一版在状态图上下了很大功夫,而这一版在利用状态图进行行为建模上花了更多的心血。其中大部分精力都放在了状态图新增的特性上——同步伪状态、桩状态等。因此,关于对象行为建模第4章做了很大的改动。
我在各个领域(从高级医疗成像到下一代智能、自动宇宙飞船)中进行咨询工作的最新体验,以及第一版读者的反馈,都在第二版中得到了反映。例如,无数次的咨询经历告诉我很多开发者在理解并利用用例来捕获实时和嵌入式系统需求方面有很大的困难。为了解决这一问题,我开发了一个叫做Effective Use Cases的一日课程,曾在NASA(美国宇航局)以及别的地方讲过。那些已被证明在该领域内行之有效的准则在本书第2章得到了体现。同样,本书还提供了适用于捕获对象模型或者状态行为的技术和策略。
本书的另一个变化是产品开发中使用UML的有效过程的细化。我称此过程为嵌入式系统的快速面向对象过程(Rapid Object-Oriented Process for Embedded System,ROPES)。自从第一版面世以来,我被问得最多的问题就是关于在开发实时和嵌入式系统的项目组中如何成功地部署UML。为此,第1章专门解释了这一过程,并标识了在迭代生命周期的不同阶段产生的工作活动和工件。事实上,本书组织的基础正是ROPES过程,贯穿第
2到7章。
UML的目标是提供一个标准,但实际上却不尽人意,因为市场上的各个供应商都试图使自己的产品与众不同。时代的发展很自然地要求供应商们提供UML目前不能提供的、新的、潜在的、有价值的模型构造,因而有几个供应商开始声称他们的几项新特性将成为一些尚未宣布的实时UML的一部分。有意思的是,其中的有些供应商甚至连OMG都没有参与过,而其他的供应商则提供了互不兼容的“增强”。通过在开发人员社区内传播这种心理恐怖战术——FUD恐惧、不确定和怀疑,最先被IBM采用的一种行销伎俩),这些供应商极大地伤害了他们的顾客。开发人员应该知道采用这种单一来源的概念时,机遇以及风险是并存的。这些特性也许能够使系统的建模变得容易些(尽管在很多情况下,这些所谓的增强做不到这一点),但是也把开发人员死死地限定在一家公司的工具上。另一个风险是,当这些模型不再适合UML标准时不能在各个工具之间进行模型交换。这极大地减少了开发人员使用UML的好处。为了消除某些这样的FUD,我专门增加了附录B,以告诉人们更改标准意味着什么,为什么单个厂家不能声称拥有UML标准(它实际上属于OMG),以及在未来的几年中UML可能会发生哪些变化。
最后,我建议感兴趣的读者访问I-Logix公司的官方网站,www.ilogix.com。那里可以找到很多相关主题的文章,可能是我写的,也可能是别人写的。另外,还可以找到UML规范、工具说明,以及相关站点的链接。
Bruce Powel Douglass博士
1999年春
随着嵌入式系统变得越来越复杂,过去的那套老办法彻底不管用了。当前系统的复杂程度驱使开发人员从不同的视角来构建模型,以便理解并规划系统的各个层面。这些视角包括物理或者部署视角,以及逻辑或本质视角。二者都必须支持结构和行为两方面。这就说明了UML是什么,以及它为什么如此成功。
读者
本书面向在职的专业软件开发人员,以及计算机科学专业的大三和大四学生。本书也可用作大学本科以及研究生教材,但是本书偏向于实际开发,而不是理论性的介绍。在本书中几乎找不到什么方程式,但是在适当的地方都标出了引用,以方便读者找到它们更详细的理论和数学解释。阅读本书至少需要掌握一门编程语言,并且大概知道面向对象和实时系统的基本概念。
目标
本书和第一版的目标一样,仍然希望成为介绍UML以其表示法和语义在实时和嵌入式系统开发中的应用方面的一本好读物。除本书之外,市面上还有一本关于UML和实时系统的书:《Doing Hard Time:Developing Real-Time Systems with UML,Objects,Frameworks,and Patterns》(Addison-Wesley,1999),这也是我写的。《Doing Hard Time》对实时系统的讲述更加深入,重点放在对象可调度性的分析、行为模式在状态图模型构建中的作用以及如何有效利用实时框架上。它更加深入地探讨了实时系统,并且正好也使用了UML来表达这些概念。与此形成鲜明对比的是,(Real-Time UML))主要讲的是UML,其次才是如何利用UML捕获实时系统的需求、结构和行为。
除了第一版的最初目标,第二版又增加了另外两个:1)使本书与UML标准的最新变化保持一致;2)在第一版反馈的基础上增强本书的有效性。
自从UML被OMG采纳为标准以来,出现过两次修订。第一个修订版1.2几乎全是编辑性的,没有显著的改动。而1.3则在各方面都进行了大的改动。例如,用依赖关系的《includes》构造型替换用例泛化的《uses》构造型,从而改进了不少东西。
同样,UML1.1中动作的概念严重依赖于用来捕获其细节的“未解释文本”。UML1.3细化了该元模型,从而包含了更多种类的动作,同时使行为建模更加完整。动作语义元模型以及它如何与对象的消息发送相关,将在第2和4章讨论。
1.3版中对状态图模型做了很多修改。本书的第一版在状态图上下了很大功夫,而这一版在利用状态图进行行为建模上花了更多的心血。其中大部分精力都放在了状态图新增的特性上——同步伪状态、桩状态等。因此,关于对象行为建模第4章做了很大的改动。
我在各个领域(从高级医疗成像到下一代智能、自动宇宙飞船)中进行咨询工作的最新体验,以及第一版读者的反馈,都在第二版中得到了反映。例如,无数次的咨询经历告诉我很多开发者在理解并利用用例来捕获实时和嵌入式系统需求方面有很大的困难。为了解决这一问题,我开发了一个叫做Effective Use Cases的一日课程,曾在NASA(美国宇航局)以及别的地方讲过。那些已被证明在该领域内行之有效的准则在本书第2章得到了体现。同样,本书还提供了适用于捕获对象模型或者状态行为的技术和策略。
本书的另一个变化是产品开发中使用UML的有效过程的细化。我称此过程为嵌入式系统的快速面向对象过程(Rapid Object-Oriented Process for Embedded System,ROPES)。自从第一版面世以来,我被问得最多的问题就是关于在开发实时和嵌入式系统的项目组中如何成功地部署UML。为此,第1章专门解释了这一过程,并标识了在迭代生命周期的不同阶段产生的工作活动和工件。事实上,本书组织的基础正是ROPES过程,贯穿第
2到7章。
UML的目标是提供一个标准,但实际上却不尽人意,因为市场上的各个供应商都试图使自己的产品与众不同。时代的发展很自然地要求供应商们提供UML目前不能提供的、新的、潜在的、有价值的模型构造,因而有几个供应商开始声称他们的几项新特性将成为一些尚未宣布的实时UML的一部分。有意思的是,其中的有些供应商甚至连OMG都没有参与过,而其他的供应商则提供了互不兼容的“增强”。通过在开发人员社区内传播这种心理恐怖战术——FUD恐惧、不确定和怀疑,最先被IBM采用的一种行销伎俩),这些供应商极大地伤害了他们的顾客。开发人员应该知道采用这种单一来源的概念时,机遇以及风险是并存的。这些特性也许能够使系统的建模变得容易些(尽管在很多情况下,这些所谓的增强做不到这一点),但是也把开发人员死死地限定在一家公司的工具上。另一个风险是,当这些模型不再适合UML标准时不能在各个工具之间进行模型交换。这极大地减少了开发人员使用UML的好处。为了消除某些这样的FUD,我专门增加了附录B,以告诉人们更改标准意味着什么,为什么单个厂家不能声称拥有UML标准(它实际上属于OMG),以及在未来的几年中UML可能会发生哪些变化。
最后,我建议感兴趣的读者访问I-Logix公司的官方网站,www.ilogix.com。那里可以找到很多相关主题的文章,可能是我写的,也可能是别人写的。另外,还可以找到UML规范、工具说明,以及相关站点的链接。
Bruce Powel Douglass博士
1999年春


点击看大图




加载中...
