第1章 UML概况 -- 请多提意见

[jeffyan77]

第1章 UML概况
知道吗？超过七成的软件项目是以某种形式的失败而告终的 。
作为一个程序员、架构师、项目经理或者业务分析员，无论你处在什么业务行业中，你都是在软件行业中。软件系统是业务系统的一部分，不论这个业务系统是大如跨国公司，还是小如录像带店。如果你建造的软件不能准确满足用户需求的话，会造成用户生产能力的损失，代价不可谓不昂贵。
但是你知道吗，即便你建造的软件能够满足用户需求的话，你所付出的分析、设计、开发、维护的费用也有可能过于昂贵，甚至有可能比必需费用高出两三倍。
出现这样的问题，往往不是因为设计人员不够聪明，而是因为他们没有掌握软件设计的锐利武器：UML和基于UML的软件分析和设计。
以史为鉴可以知天下。本章就以图1.1为主线，面向对象思想和UML的发展历史，这样可以更为透彻地看清楚眼前的问题。

图1.1、UML历史发展断代图。
第1节 UML的历史
面向对象的春秋时期
面向对象语言的研究开始于二十世纪六十年代，以一种叫做Simula的语言为代表。
人们通常使用模拟系统在计算机中模拟真实世界中的行为，譬如交通路口在车辆不断到达、信号灯不断变化的情况下的状况、化学反应中化学物质在温度和压力不断变化的情况下的状态，以及生产车间的装配线在人员调配、流水线速度变化情况下的状况等等。
一般而言，化学反应中温度和压力是可以连续变化的，因此化学反应中的事件是连续的。而在在交通路口的模拟中，车辆的到达，信号灯的变化都是有一定时间间隔的，这个系统的状态变化是离散的，而不是连续的。Simula 1就是这样一种用来描述离散事件（Discrete event）系统的语言。
在1967年，奥斯陆大学（University of Oslo）和挪威计算中心（Norwegian Computing Centre）的Kristen Nygaard和Ole-Johan Dahl在Simula 1的基础之上开发成功一种全功能（General Purpose）语言，称为Simula 67。这就是人类历史上第一个具备面向对象功能的编程语言，它具备了类和继承的概念。1967年就是面向对象语言的出生年。这种语言至今仍在研究和使用中。
在七十年代，犹他大学（University of Utah）的Alan Kay，以及后来的Xerox公司PARC研究中心的Adele Goldberg和Daniel Ingalls等人一同开发了Smalltalk语言，这是第一个完整的面向对象的编程语言。
Smalltalk语言在八十年代得到了完善，形成了Smalltalk 80版本，这一版本导致了Smalltalk语言的广泛流传和应用。
Smalltalk语言的成功导致了一大批面向对象语言的出现，包括Objective C, C++, Eiffel和CLOS(Common Lisp Object System)，以及Object Pascal及Delphi等。在1996年正式发表的Java语言把面向对象的编程思想推向了普通程序员。最近，Microsoft发表了Visual Basic.NET和C#等.NET语言。C#结合了Java和C++的长处，将成为Windows编程的主体语言。
在Simula和C#之间存在着许许多多的面向对象语言，是Java语言和互联网的普及使得面向对象语言茁壮成长起来，形成一部面向对象的春秋。
分析方法的战国时代
在Smalltalk出现后不久，关于面向对象的分析和设计的著作开始出现。其中有很多是与特定的编程语言密切相关的，譬如Smalltalk, Object C和C++等，但是也有一些著作是相当一般化，更具有普遍意义的。这些著作包括Shlaer和Mellor在1988年的著作，Coad和Yourdon在1990年和1991年的著作，Booch在1991年的著作，Rumbaugh等人在1991年的著作，以及Jacobson等人在1992年的著作，等等。
不同的作者采用了不同的符号表示类和对象，以及它们之间的关联。在有些时候，同样或者相似的符号在不同作者的著作里表示不同的概念，譬如三角形加上连线在Rumbaugh图标中表示继承，而在Coad和Yourdon图标中则表示聚合（aggregate），造成相当程度的混淆。
在九十年代初期一共出现了五十种不同的建模语言，这些不同的面向对象的图标和相关的方法论形成了一个群雄争霸的战国时代，这个时期常常叫做方法论的战争（Method Wars）时期。
这个时期中，逐渐出现以Rumbaugh，Booch和Jacobson为代表的三家学派，理论最为完善，实力最为雄厚，形成三足鼎立的形势。
UML一统六合
大乱导致大治。九十年代中期，混乱的情况出现逆转。方法论战争中的主要三方Rumbaugh，Booch和Jacobson逐渐吸取彼此的长处，弥补自己的不足，他们的理论越来越相似。终于，统一的条件成熟了。
1994年，Rumbaugh和Booch开始在Rational Software Corporation一同工作，将他们两个学派的理论统一起来。在1995年他们发表了Unified Method的0.8版。在1995年Jacobson加入到Rational公司中，这样三位作者终于坐到一起来了。
这时他们做了一个重要的决定，就把各种方法论中的语言部分与方法论部分加以区分，语言部分就称作统一建模语言（Unified Modeling Language或UML），方法论部分称为统一软件开发过程（Unfiied Software Development Process）后来改称为Rational Unified Process（RUP）。UML不再和方法论、软件过程理论直接挂钩，它可以用来描述RUP，也可以用来描述其它不同的过程理论，成为一个超然的纯语言构造。

图1.2、UML是从多种建模理论中脱颖而出的。
OMG（Object Management Group）是一个建立工业标准的组织，它在1996年建议发展出一套标准的对象建模语言，Rational Software Corporation公司与IBM，HP，Oracle以及Microsoft等主要的软件公司组成UML Partner组织，共同承担了为OMG制定UML标准的工作。
1997年十一月，UML的1.1版出炉了，OMG并从此接过了制定以后各个版本的责任。OMG指定MCI Systemhouse公司的Cris Kobryn负责UML标准的所有修改工作。1998年六月发布UML 1.2版，1999年六月发布1.3版，2001年发布1.4版，2002年发布1.4.1版，2003年3月发布1.5版。其中1.1版本和1.3版本是UML 1.0的最为重要的修订版。
UML 2.0已成定局
在经过了长达三年的需求采集和讨论之后，OMG终于将要发表UML 2.0版本的最终规范了。负责规范制定的任务小组计划在2004年3月投票决定是否采纳现有提案。尽管还有其他提案，但是采纳其他提案的可能性很小。UML 2.0已成定局。
本书就是建立在这个提案的基础之上的，虽然正式的UML 2.0标准还有待表决结果，但是预计不会有戏剧性的变化。这就是本书成书的背景。
关于UML 2.0与UML 1.x的区别，本书后面还会集中讲述。
第2节 UML是什么
不同的工程设计人员之间、设计人员与生产人员之间进行沟通必须有一种精确的标准工程设计语言。机械设计蓝图就是机械工程设计的标准语言。在一个生产作坊里面，人们沟通可以使用手语，打着半哑谜。在一个现代化的工程里面，人们要相互沟通和协调合作，就必须使用标准的工业化设计语言。

图1.3、使用工业标准设计语言，还是打哑谜？
如同电子工程师有电路设计图，机械工程师有机械设计图，建筑工程师有建筑设计图一样，软件工程师有UML图标语言，UML是当今软件设计的标准语言。
在国内，UML的使用正在逐渐得到重视，但是仍然没有成为设计人员交流的语言。在很多开发项目里，人们在系统设计过程中使用的仍然是“手语”和“半哑谜”一样的沟通方式，UML仅仅被当做点缀。

[Chuanyan]

初学UML的Java程序员=初学Java的程序员?
侧重实用? I am expecting the following units.

[jeffyan77]

我假定读者了解Java的语法，懂得如何编程，就这些。

[BirdGu]

对初学者简化一些提法是可以的,不过一些概念的关系还是应该辨析清楚的。本来就已经有很多人搞不清OO与UML的关系,把UML等同于面向对象思想,你在书里再这样说……唉。这样的“简化”误导地厉害啊。一家之言，仅供参考。

[Chuanyan]

Agreed with BirdGu(鲲鹏)!

[jeffyan77]

对一个软件系统而言，UML语言具有以下的重要功能[BOOCH99]：可视化（Visualizing）功能、说明（Specifying）功能、建造（Constructing）功能和建文档（Documenting）功能。
可视化功能
可视化可以促进对问题的理解和解决，并且方便熟悉UML的设计师彼此交流和沟通。
可以较容易地发现设计草图中可能的逻辑错误，保证最后完成的软件确实能按照要求运行，避免和减少意外发生。
说明功能
对一个系统的说明应当通过一种通用的、精确的、没有歧义的通信机制进行，显然UML的特性使得UML很适合于这种说明工作。
系统的整体设计可以指导软件的开发过程。由于重要的决定均可以在开始写代码之前就做出，因此可以减少低质量的代码，进一步降低开发成本。
建造功能
UML有它自己的语法规则，这使得人们可以使用建模工具软件对一个系统设计模型加以解释，并将设计模型映射到一种计算机语言（如Java）上。这也就是说，使用一种建模工具可以大大加快建模和系统设计的过程。
通过UML可以看到总体的图像，这样一来，可以均衡调配系统所消耗的计算机的资源，使系统更有效率。因为系统的设计首先完成，所以很容易就能发现可以复用的代码。代码能够高效率地实现复用，可以降低开发成本。
建文档功能
使用UML进行设计可以同时产生系统设计文档。
由于使用UML设计的软件系统在写出代码之前就有了专业化的设计和文档资料，所以程序员事先精确地知道他们的计划是什么。当需要修改一个已有的系统时，如果能找到那个系统的UML文档资料，则会节省学习时间，使修改工作事半功倍。这样可以降低维修成本。
如果在项目进行过程当中，有新的程序员参加项目的话，这些程序员可以借助UML图形文档资料很快熟悉开发中的系统。
2.3 UML包括什么
从自身结构上讲，UML包括四大部分，分别是
 底层结构（Infrastructure）标准，精确描述UML内部概念结构
 上层结构（Superstructure）标准，用户层面的特性
 图标交换（Diagram Interchange）标准
 对象约束语言（Object Constraint Language）标准
作为UML的普通使用者，读者最为熟悉和关心的是UML的上层结构标准。从UML的组织上看，UML可以分成以下几种组成成分：
 视图（Views）：UML提供五种视图，它们是从不同角度上考察同一个系统。每一种视图都需要同时使用数种UML图表达。
 UML图（UML Diagram）：UML 1.x提供了九种，而UML 2.0提供了十三种UML图。本章后面会讲到这些UML图都是什么，以及2.0版本作了哪些增删。每一种UML图都是由很多图形元素（Graphic Elements）组成。
 模型元素（Model Elements）：描述一个面向对象系统的模型，必须一些基本的元素，包括类、对象、关系（譬如关联、依赖、一般化等），这些就是模型元素。每一种模型元素都以一个图形表示，并且可以出现在不同种类的UML图中。
 一般性机制（General Mechanisms）：为一个模型元素提供额外的注释（comments），信息、和语义（Semantics），也可以用于将UML扩展到特定的领域、语言、方法过程中去。
 模型驱动的架构（Model Driven Architecture或MDA）特性：OMG把UML视为一个更大的计划的一部分，这个更大的计划就是要使UML模型更为紧密地与开发工具相结合，并具有可执行性。
下面就分门别类讨论这些成分。


视图（Views）
对于真实世界中的软件系统而言，使用单一的UML图是不可能完整表述出系统的功能、性能和组织结构的，要描述系统的各个方面，必须要使用多种UML图联合描述。
那么一个系统需要描述的方面有多少哪？一般认为有五个方面需要描述，UML图对每一个方面的描述就称作一个视图，每一个视图都需要多个UML图联合描述（参见图1.4）。这五种视图是：

图1.4、UML的五种视图。
 用例视图（Use-Case View）：描述外部使用者所认知的系统功能。
 逻辑视图（Logical View）：描述功能是如何在系统内部设计的，包括系统的静态结构和动态行为。
 实现视图（Implementation View）：显示源代码以及可执行代码是如何组织的。
 过程视图（Process View）：描述过程性能的基本要素，包括可缩放性（Scalability）、吞吐量（Throughtput）、基本的时间性能等。
 部署图（Deployment View）：描述软件部件是如何放置到硬件部件上面的。
UML 1.1中的图（Diagram）
每一个UML图使用图形元素描述系统的某一个特定部分，而每一个UML图都是某一个或者几个UML图的一部分。UML 1.x只有下面的九种UML图。
四种结构型图：
 类图（Class Diagram)
 对象图（Object Diagram）
 构件图（Component Diagram)
 部署图（Deployment Diagram）
五种行为型图：
 用例图（Use Case Diagram)
 序列图（Sequence Diagram）
 合作图（Collaboration Diagram）
 状态图（Statechart Diagram）
 活动图（Activity Diagram）
或见图1.5所示。

图1.5、UML1.x中的图种类
描述一个系统的五种视图中，用例视图由UML用例图实现，实现视图由部件图实现，逻辑视图由类图和对象图实现，部署视图由部件图和部署图实现，过程试图由序列图、合作图、状态图和活动图实现，参见图1.6。

图1.6、UML1.x中的五种系统视图是如何实现的
值得指出的是，长期以来还有一种包图（Package Diagram）常常使用，但是它并不是九种UML图之一。包图在UML 2.0标准中正式成为标准UML图之一。
UML 2.0中的图（Diagram）
UML 2.0图UML 1.x相比有了较大的增删，UML 2.0有下面的十三种UML图。
六种结构型图：
 类图（Class Diagram)，描述类的静态结构。
 对象图（Object Diagram），一种特殊的类图，给出在系统执行期间对象的快照
 构件图（Component Diagram)，描述可部署的软件构件之间的静态结构
 复合结构图（Composite Structure Diagram）（新增），描述类在运行期的分解
 部署图（Deployment Diagram），描述系统硬件和软件的物理架构
 包图（Package Diagram）（新增），描述编译时期的系统层级结构
七种行为型图：
 用例图（Use Case Diagram)，描述系统外部的使用者与系统提供的用例之间的联系，可以用来对一个系统的最基本的行为进行建模
 序列图（Sequence Diagram），一种交互图，描述不同对象之间信息传递的时序
 通讯图（Communication Diagram）原名合作图（Collaboration Diagram），一种交互图，描述发出信息、接收信息的一系列对象的组织结构
 交互概览图（Interaction Overview Diagram）（新增）
 时机图（Timing Diagram）（新增），描述对象之间的相互作用，强调时机
 状态机图（State Machine Diagram）原名状态图（State Diagram），描述一系列对象的内部状态及状态的变化和转移。注意一个类不能有两个不同的状态图
 活动图（Activity Diagram），描述不同过程之间的动态接触。活动图是使用案例图所描述的行为的具体化
根据这些图的用意，可以将它们大体上划分为结构型图和行为型图两种。结构型图描述了系统的静态结构，在显示一个系统已有的类及它们之间的静态关系时最为有用。行为型图描述一个系统的动态性质，在显示系统的元素如何协作产生满足要求的系统行为方面最为有用。参见图1.7。

图1.7、UML 2.0中的图种类
描述一个系统的五种视图中，用例视图由UML用例图实现，实现视图由部件图实现，逻辑视图由类图、复合结构图、对象图和包图实现，部署视图由部件图和部署图实现，过程试图由序列图、通讯图、状态图、活动图、交互概览图和时机图实现，参见图1.8。

[jeffyan77]

图1.8、五种系统视图在UML 2.0中的实现
只要有意义，所有类型的UML图都是可以混合在一起使用的。比如，一个对象图可以与一个类图同时出现在一个结构图中，一个构件图中可以有类图出现等（一些UML建模工具软件不一定允许这样做）。
只要设计师认为有必要，就可以省略掉UML图中的某些信息。譬如类之间的依赖关系常常广泛存在于大量的类之间，画出所有的依赖关系会造成大量的线条扰乱读者的视线，因此设计师常常仅画出重要的依赖关系，而省略不重要的那些。此外关联关系的多重性（Multiplicity）也常常被省略掉。
当读者在看到某些UML图中的属性被省略掉的时候，不能假定这些属性不存在，而只能假定这些属性不重要，而将精力集中到图中被强调的部分。
UML建模工具
在笔者开始学习UML的时候，并没有很多读者这么幸运，因为那个时候没有什么UML工具可言，所有的图都是用手在纸上或黑板上画。
现在不同了，市场上有很多工具，甚至免费的工具可以帮助用户画UML图。其中有些是纯粹的绘图工具，另外的一些则是有代码生成功能的OO设计工具。一个好的OO设计工具甚至可以双向工作，既可以从代码生成UML图，也可以从UML图生成代码；根据时序图自动给出合作交互图，或者根据合作交互图自动给出序列交互视图等。这样的工具包括如下内容：
工具名称 公司网站
Rational Rose 2002 www.rational.com

Together Control Center 6.1 www.togethersoft.com

Microsoft Visio 2002 www.microsoft.com

Telelogic Tau (Generation 2) www.telelogic.com

Visual UML www.visualobjectmodelers.com

Model Bridge www.metaintegration.net

MicroGold WithClass www.microgold.com

QuickUML www.excelsoftware.com

ArgoUML (Free) argouml.tigris.org
VP UML www.visual-paradigm.com

UML建模工具又常常叫做CASE（Computer Assisted Software Engineering）工具。对于初学者来说，各种形形色色的建模工具可以提示基础概念，帮助建模工作，但是读者应当牢牢记住，UML语言是与建模工具没有关系的抽象标准，而每一种建模工具都不可避免地与UML标准本身有一定差距。
譬如常见的几种建模工具包括Rational Rose 2002，Together Control Center 6.1，Microsoft Visio2002等等，这几种工具分别符合UML标准的1.3，1.3和1.2版本，而且都增加了自己的一些扩展功能。
虽然Microsoft Visio不能符合UML 1.3及以上版本的要求，但是Microsoft Visio所具有的灵活性是这种工具成为最为一种极为普及的建模工具（参见图1.9）。

图1.9、Microsoft Visio在运行时的情形
Rational公司已经被IBM公司所并购，因此Rational Rose已经成为IBM公司的产品。Rose支持逻辑建模和物理建模，可以顺向工程（Forward Engineering）由模型生成代码，也可以逆向工程（Reverse Engineering）从代码生成模型。作为UML建模工具的行业老大，Rational Rose已经经历了漫长的岁月，面对新兴起的建模与开发环境合二而一的发展趋势，显得力不从心。

图1.10、Rational Rose在运行时的情形
在以上列出的这些工具里面，Together较为特殊。它把Java IDE和OO设计建模工具合二为一，用户可以同时看到UML图和Java源代码，修改UML图会使得源代码得到即时修改。反过来，修改Java源代码也会使UML图同时得到相应的修改，如图1.11所示。

图1.11、Together Control Center 6.0在运行时的情形
在一些参考文献里，读者可以看到类似于UML但不一定是UML的图标，比如在[GOF95]里使用的是较早的Booch图标，而在[GRAND98]里使用的却是UML图标，本书通篇使用UML图标。
本书的UML图标大部分是使用Together和Microsoft Visio生成的，对Together感兴趣的读者可以从www.togethersoft.com 网站得到免费的试用版本。
ArgoUML是一个免费的Java应用程序，它支持UML 1.3标准（参见图1.12）。

图1.12、ArgoUML .0在运行时的情形
本书作者使用了Microsoft Visio，Together ControlCenter 6.1以及Telelogic Tau会绘制本书中的插图。
在使用Microsoft Visio绘图时，作者使用了Pavel Hruby博士提供的UML 2.0模具（参见图1.13），作者特此感谢。对此模具感兴趣的读者可以从Pavel Hruby博士的网站www.phruby.com免费下载。

图1.13、Pavel Hruby博士提供的UML 2.0模具中的一部分。
解压缩后，读者会得到三个文件。在打开一个新Visio文件之后，需要导入新模具，参见图1.14。对其他模具感兴趣的读者可以参考http://www.mvps.org/visio/3rdparty.htm。


图1.14、如何导入新模具。 图1.15、OMG的UML认证标志
UML认证
OMG的UML认证由OMG和UML技术学院（UML Technology Institute或UTI）联合举办，OMG/UTI证书可以为IT社区提供一个衡量个人对UML 2.0标准的掌握程度的标准。该证书分成三个等级：

 OMG-Certified UML Professional Fundamental OM0-100 （OMG认证UML基础证书）
 OMG-Certified UML Professional Intermediate OM0-200 （OMG认证UML中等程度证书）
 OMG-Certified UML Professional Advanced OM0-300（OMG认证UML高级证书）
要得到以上任何一份证书必须通过一个90分钟闭卷考试，通过考试者即可得到OMG颁发的相关证书。

[BirdGu]

阎博士太抬举UML了吧。“出现这样的问题，往往不是因为设计人员不够聪明，而是因为他们没有掌握软件设计的锐利武器：UML和基于UML的软件分析和设计。”把UML说得好象是软件业的救世主一样。就算把这句话中的UML换成“面向对象”，都会有大把的人起来反对，更不用说是UML了。为什么会有那么多的项目失败？其原因大部分都会归结到使用了不恰当的或错误的“方法与过程”，或是对“方法与过程”的不正确、不恰当使用，（项目失败的政治原因这里就不谈了）。UML 是什么？是方法还是过程？它只是一种建模语言，一套符号体系。它能解决方法和过程方面的问题吗？不能。
从后面的文字看，明显有把面向对象和UML混为一谈的趋向。博士说要在本章里描述"面向对象思想和UML的发展历史，"，可显然对面向对象思想的发展历史描述太不到位了。如果真要描述面向对象的思想的发展历史，那么对于面向对象的主要概念“封装、继承、多态”的出现与发展历史，早期OOPL和目前普遍使用的OOPL中这些概念的实现方式以及差异是应该有所描述的。而且这也只是停留在OOPL的层次。总之真要写面向对象思想的发展历史，那要写的东西太多了。建议还是只是局限在“OO建模语言和UML的发展历史”这个范围会比较容易一些。

请问这本书的名字是什么？主要内容是什么？

[jeffyan77]

呵呵，我能理解你的疑问，考虑这个书的定位和主要内容：

《UML图解》
初学UML的Java程序员，一本侧重实用的UML 教材。

书中确实要谈到很多OO方面和UP方面的内容，但是都是围绕UML而谈。本书的题目就是UML。

我也同意书中有些提法过于简单化了一点，但这本书确实就是为初学者的，有一些说法只能减而化之。

[jeffyan77]

呵呵。你们知道Bruce Eckle的那本书为什么那么多罗圈话吗？都是大家提意见提的，原来的一句话最后都变成了两页纸。

不过你们说的也有道理，毕竟我也不想让人家说我误导初学者。这样吧，我加上一段话，专门讲解项目失败的原因分析，然后导入UML，但同时警告读者UML不是银弹。这样可以面面俱到。呵呵

[zhuma]

补充一点：
“人们通常使用模拟系统在计算机中模拟真实世界中的行为，譬如交通路口在车辆不断到达、信号灯不断变化的情况下的状况、化学反应中化学物质在温度和压力不断变化的情况下的状态，以及生产车间的装配线在人员调配、流水线速度变化情况下的状况等等。一般而言，化学反应中温度和压力是可以连续变化的，因此化学反应中的事件是连续的。而在在交通路口的模拟中，车辆的到达，信号灯的变化都是有一定时间间隔的，这个系统的状态变化是离散的，而不是连续的。Simula 1就是这样一种用来描述离散事件（Discrete event）系统的语言。”

看了以上的话，似乎“描述离散事件”的Simula不能描述化学反应了，因为“化学反应中的事件是连续的。”而前面又提到“人们通常使用模拟系统在计算机中模拟真实世界中的行为，譬如...化学反应...”。

这里是不是有点自相矛盾了？


另外觉得整体文字语句上有些凌乱，可能是前辈的初稿吧：）

新手意见
谬误百出
不当之出
jeffyan前辈见谅

[Chuanyan]

To jeffyan77(jeffyan77) ：
“这样吧，我加上一段话，专门讲解项目失败的原因分析，然后导入UML，但同时警告读者UML不是银弹。这样可以面面俱到。呵呵”
我读的书少，可能作为博士的你对文字的严密性很看重，而且，如果作为一些发表学术的文章的话，的确应该这样，因为这些文章是让专家看的。
但是据你所说，你写书的对象是“我假定读者了解Java的语法，懂得如何编程，就这些。”所以我更关心的是你假设的对象看完你的书后是否真的可以提升自己的能力？我觉得你花那么多心思去“面面俱到”是不必要的。或者你的书出版之后会被其他一些专家不断批评，但是你的书只要真的能让UML初学者Level up的话，这就足够了。
不知道你是出于学术发表的目的，还是出于为UML初学者服务的目的去写这些书的？

[jeffyan77]

嗯，需要改改。

[jeffyan77]

改为：

一般而言，化学反应中温度和压力是可以连续变化的，因此化学反应中的事件是连续的。而在在交通路口的模拟中，车辆的到达，信号灯的变化都是有一定时间间隔的，这个系统的状态变化是离散的，而不是连续的。在六十年代，人们需要一套系统更好地描述离散事件（Discrete event），Simula 1就应运而生了。

[jeffyan77]

呵呵,我的书时为初学者写的,属于入门教材之类.

不过我仍然认为各位提出的一件都是非常好的. 虽然我并不追求100%的严密，但是起码应当有70%的严密吧。

我已经把下面的这段话从草稿中删除了：

---------------------------------------
知道吗？超过七成的软件项目是以某种形式的失败而告终的 。
作为一个程序员、架构师、项目经理或者业务分析员，无论你处在什么业务行业中，你都是在软件行业中。软件系统是业务系统的一部分，不论这个业务系统是大如跨国公司，还是小如录像带店。如果你建造的软件不能准确满足用户需求的话，会造成用户生产能力的损失，代价不可谓不昂贵。
但是你知道吗，即便你建造的软件能够满足用户需求的话，你所付出的分析、设计、开发、维护的费用也有可能过于昂贵，甚至有可能比必需费用高出两三倍。
出现这样的问题，往往不是因为设计人员不够聪明，而是因为他们没有掌握软件设计的锐利武器：UML和基于UML的软件分析和设计。

[newdongkui]

首先表示支持!

原来以为博士不写这样的初学者看的东西,只有老教授们干这事,因为太难了.很容易落个误人子弟的评语.uml,更是怕怕.

博士都是锐利和前沿的,不会在这种出力不讨好的事情上周折.所表述的是观点,而不是系统.

不过阎博士说的就算不错啦.只是初看之下觉得网太大了,小心补不过洞洞来哦.

[iamwls]

支持，期待。。。

[zhaolihhy]

mark