好久没有写写新东西了，最近闲下来了，看了一本名叫《URL与软件建模》这边书，感觉里面讲的不错，现在将我学习到的东西和大家做一个简单的分享。

横竖都是写，建模和不建模有什么区别呢？如果你是一个资深的软件开发人员，也许你对建模的好处深有体会，下来我们就来先讲讲建模的好处：

模型是现实系统的简化。建模是对现实系统进行适当的过滤，用适当的表现规则描绘出简洁的模型。通过模型，人们可以了解到所研究事物的本质，而且在形式上便于人们对之进行分析和处理。UML（统一建模语言）是一种通用的建模语言，它获得了工业界和学术界的广泛支持，目前已经成为建模语言的标准。

1.1那么什么是模型呢？

模型是现实系统的简化，它是抓住现实系统的主要方面而忽略次要方面的一种抽象。因此，模型即反映了现实系统，又不等同于该现实系统。模型是理解、分析、开发或改造现实系统的常用手段。模型和现实系统之间的关系如下：

由于人们对复杂性的东西认识有限，因此系统设计者在系统设计之初往往无法完全理解整个系统。此时人们就需要将系统建模。现实生活中也是如此，再建造一个大楼的时候往往要先画设计图纸。建模可以使设计者能够从全局把握系统及内部的联系，而不至于陷入每个模块的细节之中。模型可使具有复杂关系的信息简单易懂，使人们容易洞察复杂堆砌而成的原始数据背后的规律，并能够有效的人们将系统需求映射到软件结构上。具体而言，模型的作用如下：

（1）模型可以促进项目有关人员对系统的理解和交流。模型对于问题的理、项目有关人员（客户、领域专家、分析人员和设计人员等）之间的交流、文档的准备以及程序和数据库的设计等都非常有益。模型可使得人们直接研究一个大型的复杂软件系统。建模促使人们对需求的理解，从而可得到更清楚的设计，进而得到更容易维护的系统。

（2）模型有助于挑选出代价较小的解决方案。再研究一个大型系统的软件模型时，人们可以提出多个实际方案并对它们进行比较，然后挑选一个最好的解决方案。

（3）模型可以缩短开发周期。模型实际上是通过过滤掉一些不必要的细节而刻画复杂问题或者结构的必要特效的抽象，它使得问题更容易理解。有了模型之后，软件系统的开发就会变的较快，同时也降低了系统的开发成本。

为了建立复杂的系统，开发人员必须先抽象出不同的视图，并用精确的表示法来建立模型，最后在模型转换为实现中逐渐添加细节。如右图所示，表示法、过程和工具是成功建模的3要素，三者缺一不可。如果建模人员了解表示法的含义，但不知道如何使用这些表示法（过程），那么最终有可能会失败；如果建模人员知道建模的过程，但不知道各个表示法的含义，那么最终也可能会失败；如果建模人员不能借助工具记录下建模过程所得的各制品，那么最后还是有可能会失败。

1.2面向对象的软件开发

在面向对象的程序设计方法出来之前，传统的设计方法大都是面向过程的（少数是面向数据结构的）。面向过程的程序设计结构清晰，它是历史上为缓解软件危机做出了贡献。面向过程的程序设计方法是以功能分析为基础的，它强调自顶向下的功能分解，并或多或少的对功能进行分离。换言之，在采用这种方法开发系统时，不管是在模型设计中还是在现实系统实现中，数据和操作都是分开的。对用这种设计方法设计出的系统而言，模块独立性较差，模块之间的耦合度较高，对一个模块的修改可能会造成很多其它模块功能上的改变。因此，系统的理解和维护都存在一定的难度。具体而言，面向过程的程序设计方法存在如下问题：

（1）操作和数据分离的软件设计结构和人类（所认识）的现实环境很不一样，和人的思维方式不相一致。因此，人们对现实世界的认识与程序之间设计之间存在一道理解上的鸿沟。

（2）系统是围绕着如何实现一定行为来进行的，当系统行为易变，需要常常修改时，修改工作颇为困难。因为这类系统的结构是基于上层模块必须掌控和控制下层模块工作的前提的，因此在底层模块变动时，常常会迫不得已改一些上层模块，而这种一系列的上层模块的修改不是当时变动底层模块的目的。同样，在需要修改上层模块时，新的上层模块也需要了解它的所有下层，编写这样的上层模块当然颇为困难。所以，这种结构无法适应迅猛变化的技术发展。

（3）在系统中模块之间的控制作用有重要的影响时(亦即在实际的控制发生的根源来自分散的各个模块之中时)，由于在“良好的模块结构”中的模块间的控制作用只能通过上下之间的关系调用关系来执行，这样会造成信息路径过长，效率低，易受干扰甚至出现错误。如果允许模块间为进行控制而直接进行通信，那么结果是系统总体结构混乱，从而难于维护。所以，这种结构是无法适应以控制关系为重要特性的系统要求的。

（4）用这种方法开发出来的系统往往难于维护，主要原因是所有的函数都必须知道数据结构。许多不同的数据类型的数据结构之间只有细微的差别。在这种情况下，函数中常常充满了条件判断，它们与函数的功能毫无关系，只是因为数据结构的不同而不得不使用他们，结果使得程序变的非常难读。

（5）自顶向下功能分解的分析方法大大的限制和降低了软件的易用性，导致对同样对象的大量重复性操作，从而降低了开发人员的生成率。

面向对象设计方法是对面向过程设计方法强有力的补充。面向对象的设计的方法是一种新型、实用的程序设计方法，它强调数据的抽象、易扩展性和代码复用等软件工程原则，特别有利于大型、复杂软件系统的生成，因而被称为20世纪90年代的“结构化程序设计方法”。该方法的主要特征在于支持数据抽象、封装、继承等概念。借助数据抽象和封装，可以抽象的定义对象的外部行为而隐藏其实现细节，从而达到规约和实现的分离，有利于程序的理解、修改和维护。对系统原型速成和有效实现大有帮助；支持继承则可以在原有的代码上构建新的软件模块，从而有利于软件的复用。在采用面向对象的程序设计方法开发系统时，系统实际上是由许多对象构成的集合。图1-3形象的描绘了结构化程序的和面向对象程序之间的主要差别。

面向对象程序设计语言可以直接、充分的支持面向对象程序设计方法，从而称为软件开发的有力工具。在面向对象程序语言设计当中，对象由属性和方法封装而成。对象的行为通过操作展示，外界不可以直接访问其内部属性，操作的实现对用户透明。消息的传递是对象间唯一的交互方式，对象的创建和对象中操作的调用通过消息传递来完成。类是对具有相同内部状态和外部行为对象结构的描述，它定义了表示对象状态的实例变量集和表示对象变量的方法集。类是待创建对象的模板，而对象则是类的实例。子类可以继承父类的的实例变量和方法，同时还可以定义新的变量和方法。对象的分装性降低了对象间的耦合度，从而使得程序的理解和修改变的容易。类之间的继承机制使得易于在现有代码基础上为系统增加新的功能。总之，可以把面向对象模型看作是一个由如下主要元素构成的概念框架：

• 抽象
• 封装性
• 模块化
• 层次性
• 并发性
• 类型化
• 持久化
• 易复用性
• 易扩展性
• 动态绑定

面向对象的软件开发方法涉及从面向对象分析（OOA）-->面向对象设计(OOD)-->面向对象程序设计和编码(OOP)-->面向对象测试(OOT)等一系列特定阶段。面向对象设计方法期望获得一种独立于语言的设计和描述，以求达到从客观世界中的事物原型到软件系统间的的尽可能的平滑过渡。

面向对象的方法把功能和数据看作是高度统一的，其优点主要有：

（1）它能较好的处理软件规模和复杂性不断增加所带来的问题。

（2）它更适合于控制关系复杂的系统。

（3）面向对象系统通过对象间的协作来完成任务，因而更容易管理。

（4）它使用各种直接模仿应用域中实体的抽象和对象，从而使得规约和设计更加完整。

（5）它围绕对象和类进行局部化，从而提高规约、设计和代码的易扩展性、易维护性和易复用性。

（6）简化了开发者的工作，提高的软件和文档的质量。

当开发人员正确的使用了面向对象开发方法时，就能够有效的降低软件开发的成本，提高系统的易复用性、易扩展性、易维护性和易理解性。

1.3 面向对象的软件建模

面向对象建模语言起始于20实际70年代中期。从1989年到1994年，其数量从不到10种迅速增加到50多种。各种建模语言的设计者都努力推崇自己的语言产品，并在实践中不断完善。然而，OO（面向对象）方法的用户并不了解不同建模语言的优缺点以及相互之间的差异，因而很难根据应用 的特点选择合适的建模语言。于是，爆发了一场“方法大战”。

Booch是面向对象方法最早的倡导者之一，它提出了面向对象软件工程的概念。1991年，它将以前所进行的面向Ada的工作扩展到整个面向对象设计领域。1993年，Booch对其之前的方法做了一些改进，使之适合系统的设计和构造。Booch在其OOAda中提出了面向对象的4个模型：逻辑视图，物理视图以及其相应的静态和动态语义。对逻辑结构的静态视图，OOAda提供提供对象图和类图；对逻辑结构的动态视图，OOAda提供的状态变迁图和交互图；对于物理结构的静态视图，OOAda提供了模块图和进程图。

Jacobson于1994年提出了面向对象的软件工程（OOSE）方法，该方法的最大特点就是面向用案（User Case）。OOSE是由用案模型、域对象模型、分析模型、设计模型、实现模型和测试模型组成的。其中用案模型贯穿于整个开发过程，它驱动所有其它模型的开发。

Rumbaugh等人提出了OMT方法。在OMT方法中，系统是通过对象模型、动态模型和功能模型来描述的。其中，对象模型用来描述系统中各对象的静态结构以及它们之间的关系；功能模型描述系统实现什么功能（即捕获系统所执行的计算），它通过数据流图来描述如何由系统的输入值得到输出值。功能模型只能够指出可能的功能计算路径，而不能确定哪一条路线会实际发生。动态模型则描述系统在何时实现其它功能（控制流），每个类的动态部分都是由状态图来描绘的。

Coad和Yourdon提出了OOA/OOD方法。一个OOA模型由主题层、类及对象层、结构层、属性层和服务层组成。其中，主题层描绘系统的划分。类和对象层描述系统中的类和对象，结构层捕获类和对象之间的继承关系及整体-部分的关系，属性层描述对象的属性属性和类及对象之间的关联关系，服务层描述对象所提供的服务（即方法）和对象的消息链接。OOD模型由人机交互（界面）构件，问题域构件，任务管理构件和数据管理构件组成。

Fusion自认为是“第二代”开发方法。它是在OMT方法、Objectory方法、形式话方法、CRC方法和Booch方法的基础上开发的。面向复用/再工程以及基于复用/再工程的需求开发是Fusion的一大特点。Fusion方法中用于描述系统设计和分析的图形虽然不多，但较全面。Fusion方法将开发过程划分为分析、设计和实现3个阶段，每个阶段由若干步骤组成，每一步骤的输出都是下一步骤的输入。

OL是Shlaer/Mellor重新修订其先前开发的面向对象系统分析方法（OOSA）后所得到的一种建模方法。OL方法中的OOA使用了信息建模，状态建模和进程建模技术。OOD中使用类图、类结构图、依赖图和继承图对系统进行描述。

Martin与Odell提出的OOAD方法的理论基础是逻辑和集合论。尽管面向对象的分析通常被划分成结构（静态）和行为(动态)两部分，但Martin与Odell的OOAD却试图将它们集成在一起。它们认为面向对象分析的基础应该是系统的行为，系统的结构通过对系统行为的分析而得到的。

1.4 统一的建模语言（UML）

UML是一种定义良好的、易于表达的、功能较强的且普遍适用的建模语言。它吸收了软件工程领域的新思想，新方法和新技术。UML的应用领域相当广泛，它不仅可以用于建立软件系统的模型，同样也可以描绘非软件领域内的系统模型以及处理复杂数据的信息相同、具有实时要求的工业系统或工业过程等。

作为一种通用的建模语言，UML适用于系统开发过程中从需求规约描述到系统完成后测试的不同阶段。目前，UML已经成为建模语言上的工业标准。

1.4.1 发展历程

在UML问世之前，已经有不少人试图将各种建模方法中的不同概念进行统一。其中Coleman和他的同事们曾努力统一OMT、Booch、CRC方法中的概念。但由于这些方法的原作者没有参与到这项工作，其最后的结果是得到了一种新的建模方法，如图1-4所示。UML语言开发始于1994年8月，当时Rational软件公司的Booch和Rumbaugh着手进行统一的Booch方法和OMT方法，以便以后得到一种统一的建模语言。1995年10月，他们发布了统一方法（UM）的初级版本。同年秋天，Jacobson加盟联合开发小组，并力图把OOSE方法也统一进来。

做为Booch、OMT（对象建模技术）和OOSE方法的创始人，Booch、Rumbaugh和Jacobson决定开发UML有3个原因：首先，这些方法有很多相似之处，消除它们给使用者造成的混淆是非常有意义的；其次，语义和表示法的统一可稳定面向对象技术的市场，使得开发工程能采用一种成熟的建模语言；再次，统一工作可吸收先前各种建模方法中的优秀成果，以便解决以前没有解决好的问题。

Booch、Rumbaugh和jacobson在着手统一工作时，制定了如下4个目标：

（1）使用面向对象的概念来构造系统的模型。

（2）建立设计框架和代码直接的明确关系。

（3）解决复杂的、以任务为中心的系统内在的规模问题。

（4）开发人与机器的通用的建模语言。

开发应用于面向对象的分析和设计的表示法并不像设计一种程序设计语言那么简单。首先，设计者要考虑表示法是不是应该能够表达系统的开发需求，是不是要把表示法设计成形象化的语言。其次，设计者需要在表达能力和简洁程度之间做出权衡，即过于简单的表示法会限制应用的范围，而过于复杂的表示法又会吓到刚入门的使用者。如果设计者是在统一已有的一些方法，那么还要照顾到过去的基础，即改变过多会使原来的使用者感觉到混乱，不作改进，又难以吸引更多的使用者。UML的定义力图在这几个方面权衡利弊。

经过Booch、Rumbaugh和Jacobson的不懈努力，UML0.9和0.91版终于在1996年的6月和10月出版。1996年间，UML开发者们向各界虚心求教并收到来自社会各界的反馈。他们据此做了相应的改进，但显然还有许多工作需要完成。同年，OMG（对象管理组）发布了向外界征集关于面向对象建模标准方法的消息。UML的3位创始人开始与来自其它公司的软件工程方法专家和开发人员一道制定了一套OMG感兴趣的方法，并设计了一种被软件开发工具提供者、软件开发方法学家和开发人员这些最终用户接受的建模语言。于此同时，其它一些相关人员也在做这项富有竞争性的工作。1997年9月1日产生了UML1.1，并提交到OMG进行讨论。

OMG于1997年11月正式接纳了UML1.1，然后成立任务组不断的修订，并产生了UML1.2、1.3和1.4版本，其中UML1.3是较为重要的修订版本。目前，该组织正在对UML进行重大修订，其目标是推出UML2.0，做为向ISO提交的标准方案。许多软件开发工具供应商声称他们的产品支持或计划支持UML，软件工程方法学家们也宣布他们将使用UML的表示法进行以后的研究工作。UML的出现深受计算机界的欢迎，因为它是由官方出面集中了许多专家的经验而形成的，减少了各种软件开发工具之间无谓的分歧。建模语言的标准化既能促进软件开发人员广泛使用面向对象的建模技术，同时也能带来UML支持工具的培训市场的繁荣，因为不论是用户还是供应商都不用再考虑到底应该采用哪一种开发方法。

总之，UML作为一种建模语言，它具有一下几个特点：

（1）UML统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点，从而有效的消除了各种建模语言之间不必要的差异。它实际上是一种通用的建模语言，可以为许多面向对象建模方法的用户广泛使用。

（2）UML建模能力比其它面向对象建模方法更强。它不仅适合于一般系统的开发，而且对并行、分布式系统的建模尤为适宜。

（3）UML是一种建模语言，而不是一个开发过程。

1.4.2 基本组成

UML是在Booch、OMT、OOSE等面向对象的方法极其它许多方法与资料的基础上发展起来的。UML不仅包含了许多人员的不同观点，而且也受到了非面向对象的影响。UML表示法集中了不同的图形表示方法，剔除了其中容易引起的混淆、冗余或者很少使用的符号，同时添加了一些新的符号。其中的概念来自于面向对象技术领域中众多专家的思想。其中的大部分观点并不是其开发者自己提出来的，他们的工作在很大程度上只是将优秀的面向对象建模方法加以选择和综合。

UML从考虑系统的不同角度出发，定义了用案图、类图、对象图、状态图、活动图、序列图、协作图、构件图、部署图等9种图。这些图从不同的侧面对系统进行描述。系统模型将这些不同的侧面综合成一致的整体，便于系统的分析和构造。尽管UML和其它开发工具还会设计出许多派生的视图，但上诉这些图和其它辅助性的文档是软件开发人员所见的最基本的构造。其中：

• UML用案图与OOSE中的用案图类似。
• UML的类图综合了OMT、Booch等面向对象方法中的类图。
• UML状态图是对David Harel所提出状态图的改进。
• UML活动图的基本语义和状态图大致相同，它类似于许多方法（包括面向对象技术之前的一些方法）中的工作流图，
• UML的协作图是通过对Booch方法的对象图、Fusion方法的对象交互图以及其它一些方法中的相关图表改造而成的。
• UML的构建图和部署图是在Booch方法中的模块和进程图（处理关系图、处理器图）的基础上发展起来的。

UML简化了建模方法，它扬弃了Booch、OMT或OOSE等方法中的糟粕，而代之以其它方法中的精华。UML一般不引入新的概念和符号，只有在没有现有的解决方法可以借鉴时，UML的开发者们才考虑加入新的概念。UML的开发者们是在设计一种语言（尽管只是一种图形化语言），因此必须在简明（所有元素一律用方框和文字表示）和繁琐（为每个元素设计单独的符号）之间权衡。尽管如此，UML中还是增添了衍型和扩展机制等一些新的元素，因为这些元素在其它建模语言的实践中已经证明是非常有用的。

1.4.3 建模能力的比较

UML并没有从根本上脱离Booch、OMT、OOSE等方法，而是对这些方法有批判的继承。这就意味着，如果目前的读者是一位Booch、OMT或OOSE的使用者，那么你所接受的培训、工作经验和所偏好的开发工具都可以继承与保留下来，因为UML是对这些方法的延续。对于其它方法的使用者来说，UML同样也很容易被接受。与Booch、OMT、OOSE等其它方法相比，UML具有表达能力更强、更清晰和一致的优点。因为UML消除了各种方法在表示法和术语上不必要的差异，而正是这些差异隐蔽了不同方法之间的相似之处。

Booch等著的UML USER Guide一书从结构建模、行为建模和体系结构建模3个方面给用户提供的具体的指南。为了突出UML与其它建模方法在建模能力上的差异，下面用3个表从结构建模，行为建模，体系结构建模3个方面对它们进行详细的比较。表格中使用的各种符号含义如下：

√----该概念存在于所指定的方法中。如果概念名字不一样，就在括号中注明。

×----所指定的方法中不存在该概念。

~----有一些相似之处。

?----不清楚所指定的方法中是否存在该概念。

表1-1为结构建模表，其中设计到的概念有类、属性、操作、关系、依赖、泛化、关联、角色、多重性、聚合、注释、约束和类图。图1-2为行为建模表，其中涉及的概念有消息、链接、顺序、创建、修改和撤销、序列图、协作图、用案图和活动图等等。表1-3为体系结构建模表，其中主要涉及的概念主要有构建和部署图。

从表1-1可以看出，各种建模方法都支持类，类图和关系等概念，其差别只在于表示符号不一样，这样可以用UML提供的标准符号来解决。从表1-2可以看出，各建模方法对动态建模的支持程度不经相同，但它们之间的差别是无关紧要的，因为UML提供的动态建模设施非常的丰富，足矣解决此问题。从1-3表中可以看出，各建模方法中并没有UML中的许多体系结构概念，其原因是这个概念比较新，因此，UML考虑了先前许多建模方法中都没有考虑的问题。

总结：

本节主要介绍了面向对象软件建模的方法。UML是一种良好定义的、易于表达的且功能颇强的建模语言，它吸收了软件工程领域内的新思想、新方法和新技术。UML的出现结束了“方法之战”，消除了面向对象技术早期时代中所面临的符号、术语以及语义上的混乱，UML已经被对象管理组织（OMG）采纳为面向对象建模标准。

UML很适合用于以体系结构中心的、用案驱动的、迭代式和渐增式的软件开发过程，目前已经在各个领域内得到广泛应用。