UML(Unified Modeling Language)作为面向对象分析设计的建模语言，综合了以往以来的多种记述方法。通过运用UML进行分析设计，可以很流畅地继续发展。

1. UML诞生的历史
2. UML的特征
3. 应用设计与建模
4. 应用设计法的历史
5. 设计的步骤
6. 结构法与面向对象
7. 为什么要采用面向对象设计方法

面向对象的设计方法论从1980年后期到1994年出现了众多提倡者，宛如百家争鸣的状态。仅仅作为代表的就有以下几种方法论。

• 出版了《面向对象系统分析》一书的Schlehr先生和Mellor先生的方法
• 因Ada设计而闻名的Booch先生的方法
• General Electric公司的Rumbaugh开发出来的OMT(Object Modeling Technique)
• 擅长运用用例进行要求分析的Jacobson先生提出的OOSE(Object-Oriented Software Engineering)
• Hewlett-Packard公司吸取各个方法的优点，开发出称为Fusion的第二代方法论
• Coad先生和Yourdon先生的OOA(Analysis)/OOD(Design)方法

但是1994年在Rational Software公司，Booch先生和Rumbaugh先生开始了统一方法论的研究。Rumbaugh先生用自身的方法论OMT已经获得了No.1的地位了，但是又开始了和Booch一起走向统一的道路。1995年Jacobson先生也和他们联合，1996年7月UML0.9版本终于发布了。而且在1997年1月UML伙伴组织完成了UML1.0。UML伙伴组织有DEC、HP、I-Logix、Intellicorp、IBM、Icon Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI、Unisys等公司。这个时期关于UML设定了以下四个目标。

• 运用面向对象的概念将系统（不仅限于软件）模型化。
• 明确确立与上流工程或可运行的成果物之间的联系。
• 在复杂且关键任务的系统中不能逃避，能够应对系统规模的问题。
• 开发出人类和计算机两者皆能使用的建模语言。

(参考文献 《UML摘要》日本Rational Software有限公司)

UML包含了从要求分析到系统分析、设计、测试这些系统开发阶段。使用的图表（diagram）主要是从Rumbaugh先生的OMT、Booch法、Jacobson先生的OOSE等这些方法中延伸出来的。对象包括信息系统、组合式即时系统、分散系统、业务系统等。在UML中定义了下列图表。

• 用例图
• 类图
• 包
• 协作图
• 状态图
• 接口
• 顺序图

何为应用设计呢?简言之就是程序处理以及研究处理数据的结构。

在应用中存在处理逻辑和数据处理这两个方面。迄今为止的应用设计中，正如以数据为中心的设计（DOA）一样，数据结构比处理更加受重视。处理任务脱离数据，成为一个单独的程序，当需要改变的时候，由于重写处理程序很方便，它们往往会成为一次性的程序。

在这里我们看一下行程管理程序的例子。这个程序很简单，输入自己的行程之后，只要一搜索就能显示出来。行程显示为“2000年1月1日上班解决Y2K故障”。另外还有行程的增加、删除等功能。可以如图2所示将“处理”和“数据”分开整理。这样在应用设计中就能研究“处理”和“数据”了。

这里我们简单回顾下应用设计法的历史。1980年代系统工程师必须掌握的是被称为SA/SD(Structured Analysis / Structured Design)的结构化方法。这个方法中使用了表示DFD(Data Flow Diagram)的图和表示ER图(Entity Relationship Diagram)的数据结构的图。DFD是DeMarco先生等研究出来的。James Martin先生从经营的角度出发构筑了信息系统，进一步扩展了IE(Information Engineering)。

现在，DFD已不止是单纯的一套程序，它经常被用来整理运营所需的业务流程，用在处于系统设计上游的一些工程里面。此外ER图也被广泛使用在关系数据库的设计中。与这种传统方法相比，最近出现的将处理和数据同时应对的面向对象的方法渐渐成为了主流。在程序语言中，渐渐从COBOL变成Java或Web系语言。但是，在面向对象设计时只要数据库的主流是关系数据库，就必须首先理解ER图。

系统设计可以分为“要求式样”、“系统分析”、“系统设计”这三个阶段。“要求式样”决定在何种系统中使用。“系统分析”决定系统内部的功能。有时也被称为理论设计。在这里，不考虑应用使用的系统只是简单的理论上的设计。与之相对应，“系统设计”就是考虑组装的设计。所谓组装就是指根据Web应用系统或者使用Java语言。系统设计也被称为物理设计，如果是Oracle的话就是决定增加这样一个表等事情。

这里我们来看一下设计阶段和设计图（Diagram）的关系。如果在所有阶段使用的技术都是面向对象的话，直接采用这里的主题-UML就可以了，但是实际上未必全是这样。比如，在数据管理中采用Oracle等关系数据库时，在这个设计中使用ER图比较适合。作为程序语言运用Java时，就不采用结构化方法而采用面向对象的设计方法。因此，工程师必须具备能根据情况灵活运用的能力。正确理解UML等面向对象的方法与DFD、ER图的关系。

在介绍面向对象设计方法之前，首先来看一下结构化方法。DFD如图3所示表示的是处理和数据的流程。在这里，“搜索行程”是处理，该程序的输入是“日期”，输出则是“行程”。在DFD中，程序（处理）用椭圆表示，数据的流程用箭头表示，数据的保存位置用上下线表示。使用DFD就能使处理层次化。更加详细的处理如图4所示，用下面的图（1的下面有1.1、1.2・・・这样用数字来表示层次关系）表示。。

图4是把“搜索行程”处理用DFD来表示。首先输入想要搜索的日期。然后应用下面的“读取行程”程序从“行程”中读取数据。接下来，将该数据与“日历”结合在一起表示出来。

接下来看一下ER图。图5的ER图表示的是行程管理中的数据结构。在这里，为了能够被多个使用者使用，创建了“使用者”这个实体。实体就是指数据的存储位置。相当于RDB的表。然后保存的内容就称之为属性。这个例子中，“行程”“使用者”“日历”属于数据，其中日历的属性是“日期”“休息日”“活动”。

在这类ER图中，系统被非常简单清晰地表示出来了。那为什么不能再继续使用了呢。其最大的理由就是组装环境容易给Java、C++、CORBA或EJB等分散对象带来巨大的变化。只要程序语言或者开发环境发生变化，仅凭旧的设计技术则无法处理。结构化方法普及的时候也是结构化编程的繁荣时期。这个设想的内容是，尽力避免“意大利面条式”的代码，尽可能少用goto语句，用结构化的代码来编程。然后这种想法一直应用到设计层面上。因为这里也出现了结构化这种巨大变化。开发环境一旦改变，设计方法也自然而然必须改变。只要打算用Java或者Web技术来进行系统构筑，就需要面向对象的设计。只要用面向对象来建模，就能把设计阶段到程序开发阶段紧密地联系在一起。例如，DFD不能在程序设计中使用，但是却能使用面向对象的类图。只要使用CASE工具类图也能生成编码。

此外，结构化方法不能灵活应对系统的变更要求。数据结构可以用ER图进行一元化管理，但是由于处理方法是被编入程序中的，因此处理逻辑就变得很分散。在面向对象中，因为数据和处理是一体化的，即使改变数据结构，对应的处理也能立即发生改变。此外，顾客/服务器系统的结构导入了应用浏览器之后变成三个层次时，用结构化方法分开设计数据和处理，然后就不能将组装数据和处理的浏览器准确分开。

这样说明的话会让人感觉面向对象设计似乎非常难，但是其实并不是那样的。使用面向对象设计来建模，比使用构造化方法更加容易。例如，收发货系统中，在数据建模时突然会有“订货”这个实体。这个对于在建模方面很有经验的人来说马上就能想到，但是没有经验的人则比较困难。相比之下，在面向对象设计中，研究了具体的事例-脚本之后，有顺序地选出必要元素。这样对初学者来说应该比较容易掌握。