什么是uml

Posted 2023-04-17

1. 标准建模语言UML的出现

公认的面向对象建模语言出现于70年代中期。从1989年到1994年,其数量从不到十种增加到了五十多种。在众多的建模语言中,语言的创造者努力推崇自己的产品,并在实践中不断完善。但是,OO方法的用户并不了解不同建模语言的优缺点及相互之间的差异,因而很难根据应用特点选择合适的建模语言,于是爆发了一场"方法大战"。90年代中,一批新方法出现了,其中最引人注目的是Booch 1993、OOSE和OMT-2等。

Booch是面向对象方法最早的倡导者之一,他提出了面向对象软件工程的概念。1991年,他将以前面向Ada的工作扩展到整个面向对象设计领域。Booch 1993比较适合于系统的设计和构造。Rumbaugh等人提出了面向对象的建模技术(OMT)方法,采用了面向对象的概念,并引入各种独立于语言的表示符。这种方法用对象模型、动态模型、功能模型和用例模型,共同完成对整个系统的建模,所定义的概念和符号可用于软件开发的分析、设计和实现的全过程,软件开发人员不必在开发过程的不同阶段进行概念和符号的转换。OMT-2特别适用于分析和描述以数据为中心的信息系统。Jacobson于1994年提出了OOSE方法,其最大特点是面向用例(Use-Case),并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器,但用例贯穿于整个开发过程,包括对系统的测试和验证。OOSE比较适合支持商业工程和需求分析。此外,还有Coad/Yourdon方法,即著名的OOA/OOD,它是最早的面向对象的分析和设计方法之一。该方法简单、易学,适合于面向对象技术的初学者使用,但由于该方法在处理能力方面的局限,目前已很少使用。

概括起来,首先,面对众多的建模语言,用户由于没有能力区别不同语言之间的差别,因此很难找到一种比较适合其应用特点的语言;其次,众多的建模语言实际上各有千秋;第三,虽然不同的建模语言大多类同,但仍存在某些细微的差别,极大地妨碍了用户之间的交流。因此在客观上,极有必要在精心比较不同的建模语言优缺点及总结面向对象技术应用实践的基础上,组织联合设计小组,根据应用需求,取其精华,去其糟粕,求同存异,统一建模语言。

1994年10月,Grady Booch和Jim Rumbaugh开始致力于这一工作。他们首先将Booch9 3和OMT-2 统一起来,并于1995年10月发布了第一个公开版本,称之为统一方法UM 0.8(Unitied Method)。1995年秋,OOSE 的创始人Ivar Jacobson加盟到这一工作。经过Booch、Rumbaugh和Jacobson三人的共同努力,于1996年6月和10月分别发布了两个新的版本,即UML 0.9和UML 0.91,并将UM重新命名为UML(Unified Modeling Language)。1996年,一些机构将UML作为其商业策略已日趋明显。UML的开发者得到了来自公众的正面反应,并倡议成立了UML成员协会,以完善、加强和促进UML的定义工作。当时的成员有DEC、HP、I-Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Micr osoft、Oracle、Rational Software、TI以及Unisys。这一机构对UML 1.0(1997年1月)及UML 1.1(1997年11月17日)的定义和发布起了重要的促进作用。

UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。

面向对象技术和UML的发展过程可用上图来表示,标准建模语言的出现是其重要成果。在美国,截止1996年10月,UML获得了工业界、科技界和应用界的广泛支持,已有700多个公司表示支持采用UML作为建模语言。1996年底,UML已稳占面向对象技术市场的85%,成为可视化建模语言事实上的工业标准。1997年11月17日,OMG采纳UML 1.1作为基于面向对象技术的标准建模语言。UML代表了面向对象方法的软件开发技术的发展方向,具有巨大的市场前景,也具有重大的经济价值和国防价值。

2. 标准建模语言UML的内容

首先,UML融合了Booch、OMT和OOSE方法中的基本概念,而且这些基本概念与其他面向对象技术中的基本概念大多相同,因而,UML必然成为这些方法以及其他方法的使用者乐于采用的一种简单一致的建模语言;其次,UML不仅仅是上述方法的简单汇合,而是在这些方法的基础上广泛征求意见,集众家之长,几经修改而完成的,UML扩展了现有方法的应用范围;第三,UML是标准的建模语言,而不是标准的开发过程。尽管UML的应用必然以系统的开发过程为背景,但由于不同的组织和不同的应用领域,需要采取不同的开发过程。
作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分。

(1) UML语义 描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。

(2) UML表示法 定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。

标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义:

·第一类是用例图
从用户角度描述系统功能,并指出各功能的操作者。

·第二类是静态图(Static diagram)
包括类图、对象图和包图。其中类图描述系统中类的静态结构。不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。

·第三类是行为图(Behavior diagram)
描述系统的动态模型和组成对象间的交互关系。其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充。在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。

·第四类是交互图(Interactive diagram)
描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。除显示信息交换外,合作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。这两种图合称为交互图。

·第五类是实现图( Implementation diagram )。其中
构件图描述代码部件的物理结构及各部件之间的依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。部件图有助于分析和理解部件之间的相互影响程度。
配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。

从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。

3. 标准建模语言UML的主要特点

标准建模语言UML的主要特点可以归结为三点:

(1) UML统一了Booch、OMT和OOSE等方法中的基本概念。

(2) UML还吸取了面向对象技术领域中其他流派的长处,其中也包括非OO方法的影响。UML符号表示考虑了各种方法的图形表示,删掉了大量易引起混乱的、多余的和极少使用的符号,也添加了一些新符号。因此,在UML中汇入了面向对象领域中很多人的思想。这些思想并不是UML的开发者们发明的,而是开发者们依据最优秀的OO方法和丰富的计算机科学实践经验综合提炼而成的。

(3) UML在演变过程中还提出了一些新的概念。在UML标准中新加了模板(Stereotypes)、职责(Responsibilities)、扩展机制(Extensibility mechanisms)、线程(Threads)、过程(Processes)、分布式(Distribution)、并发(Concurrency)、模式(Patterns) 、合作(Collaborations)、活动图(Activity diagram)等新概念,并清晰地区分类型(Type)、类(Class)和实例(Instance)、细化(Refinement)、接口(Interfaces)和组件(Components)等概念。

因此可以认为,UML是一种先进实用的标准建模语言,但其中某些概念尚待实践来验证,UML也必然存在一个进化过程

4. 标准建模语言UML的应用领域

UML的目标是以面向对象图的方式来描述任何类型的系统,具有很宽的应用领域。其中最常用的是建立软件系统的模型,但它同样可以用于描述非软件领域的系统,如机械系统、企业机构或业务过程,以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。总之,UML是一个通用的标准建模语言,可以对任何具有静态结构和动态行为的系统进行建模。此外,UML适用于系统开发过程中从需求规格描述到系统完成后测

试的不同阶段。在需求分析阶段,可以用用例来捕获用户需求。通过用例建模,描述对系统感兴趣的外部角色及其对系统(用例)的功能要求。分析阶段主要关心问题域中的主要概念(如抽象、类和对象等)和机制,需要识别这些类以及它们相互间的关系,并用UML类图来描述。为实现用例,类之间需要协作,这可以用UML动态模型来描述。在分析阶段,只对问题域的对象(现实世界的概念)建模,而不考虑定义软件系统中技术细节的类(如处理用户接口、数据库、通讯和并行性等问题的类)。这些技术细节将在设计阶段引入,因此设计阶段为构造阶段提供更详细的规格说明。

编程(构造)是一个独立的阶段,其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。在用UML建立分析和设计模型时,应尽量避免考虑把模型转换成某种特定的编程语言。因为在早期阶段,模型仅仅是理解和分析系统结构的工具,过早考虑编码问题十分不利于建立简单正确的模型。

UML模型还可作为测试阶段的依据。系统通常需要经过单元测试、集成测试、系统测试和验收测试。不同的测试小组使用不同的UML图作为测试依据:单元测试使用类图和类规格说明;集成测试使用部件图和合作图;系统测试使用用例图来验证系统的行为;验收测试由用户进行,以验证系统测试的结果是否满足在分析阶段确定的需求。

总之,标准建模语言UML适用于以面向对象技术来描述任何类型的系统,而且适用于系统开发的不同阶段,从需求规格描述直至系统完成后的测试和维护 参考技术A 1 UML的建筑块

组成UML有三种基本的建筑块：
1、事物（Things）
2、关系（Relationships）
3、图（Diagrams）
事物是UML中重要的组成部分。关系把事物紧密联系在一起。图是很多有相互相关的事物的组。

1.1 UML的事物
UML中有始终类型的事物：

1、结构事物（Structural things）
2、动作事物（Behavioral things）
3、分组事物（Grouping things）
4、注释事物（Annotational things）
这些事物是UML模型中最基本的面向对象的建筑块。它们在模型中属于最静态的部分，代表概念上等或物理上的元素。

1.1.1结构事物。
总共有七种结构化事物。首先是类（class），类是描述具有相同属性、方法、关系和语义的对象的集合。一个类实现一个或多个接口。在UML 中类被画为一个矩型，通常包括它的名字、属性和方法。

Window
Origin Size
Open()
Close()
Move()
Display()

图1-1 类

第二种是接口（interface），接口是指类或组件提供特定服务的一组操作的集合。因此，一个接口描述了类或组件的对外的可见的动作。一个接口可以实现类或组件的全部动作，也可以只实现一部分。接口在UML 中被画成一个圆和它的名字。

图1-2 接口

第三种是协作（collaboration），协作定义了交互的操作，是一些角色和其它元素一起工作，提供一些合作的动作，这些动作比元素的总和要大。因此，协作具有结构化、动作化、维的特性。一个给定的类可能是几个协作的组成部分。这些协作代表构成系统的模式的实现。协作在UML 中用一个虚线画的椭圆和它的名字来表示。

图1-3 协作

第四种是use case，use case是描述一系列的动作，这些动作是系统对一个特定角色执行，产生值得注意的结果的值。在模型中use case通常用来组织动作事物。Use case是通过协作来实现的。在UML 中，use case画为一个实线椭圆，通常还有它的名字。

图1-4 use case
第五种是活动类（active class），活动类是这种类，它的对象有一个或多个进程或线程。活动类和类很相象，只是它的对象代表的元素的行为和其他的元素是同时存在的。在UML 中活动类的画法和类相同，只是边框用粗线条。

EventManager
Suspend()
Flush()

图1-5 活动类

第六种是组件（component），组件是物理上或可替换的系统部分，它实现了一个接口集合。在一个系统中，你可能会遇到不同种类的组件，例如COM+ 或JAVA BEANS。组件在UML中用如下的图表示：

图1-6 组件 第七种是结点（node），结点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。一个组件集合一般来说位于一个结点，但有可能从一个结点转到另一个结点。结点通常用如下的图形表示：
图1-7结点

类、接口、协作、use case、活动类、组件和结点这七个元素是在UML 模型中使用的最基本的结构化事物。系统中还有这七种基本元素的变化体，如角色、信号（某种类），进程和线程（某种活动类），应用程序、文档、文件、库、表（组件的一种）。

1.1.2 动作事物

动态事物是UML 模型中的动态部分。它们是模型的动词，代表时间和空间上的动作。总共有两种主要的动作事物。
第一种是ineraction，interaction是由一组对象之间在特定上下文中，为达到特定的目的而进行的一系列消息交换而组成的动作。 interaction中组成动作的对象的每个操作都要详细列出，包括消息、动作次序（消息产生的动作），连接（对象之间的连接）。在UML 中消息画成带箭头的直线，通常加上操作的名字。

图1-8 消息
第二种是状态机（state machine），状态机由一系列对象的状态组成。在UML 中状态表示为下图：

图案1-9 状态

interaction和状态机是UML 模型中最基本的两个动态事物元素，它们通常和其他的结构元素、主要的类、对象连接在一起。

1.1.3 分组事物

分组事物是UML 模型中组织的部分，可以把它们看成是个盒子，模型可以在其中被分解。总共只有一种分组事物，称为包（package）。
包是一种将有组织的元素分组的机制。结构事物、动作事物甚至其他的分组事物都有可能放在一个包中。与组件（存在于运行时）不同的是包纯粹是一种概念上的东西，只存在于开发阶段。在UML 中用如下图表示包：

图 1-10 包

1.1.4 注释事物

注释事物是UML模型的解释部分。UML中用如下图表示：

图 1-11 注释

1.1.5 UML中的关系
UML中有四种关系：
1. 依赖（Dependencies）
（图1-12 依赖）

2. 关联（Association）
（图 1-13 关联）

3. 一般化（generalization）
（图1-14 一般化）
4. 实现(realuzation)
（图 1-15 实现）

1.1.6 UML中的图
1、类图（class diagram）
2、对象图（class diagram）
3、Use case diagram
4、Sequence diagram
5、Collaboration diagram
6、Statechart diagram
7、Activity diagram
8、Compomnent diagram
9、Deployment diagram
关于这些图的详细介绍将在今后的章节中讲解。

联系本文作者：[e-mail]
如果本文某些术语翻译得不正确，敬请大家指教。关于UML的东西我也是最近才接触，本文如有错误还请原谅。

参考资料：http://www.sssdf.com/showindex.jsp?categoryid=6&k=&s=id

什么是UML类图

百度了下，看评论不错我就收藏了，学习，真心不懂！！！

首先是复习一下UML中九种图的理解：http://xhf123456789plain.blog.163.com/blog/static/172880482201192222144421/

画用例图：http://xhf123456789plain.blog.163.com/blog/static/172880482201192221826110/

下面是类图的实例（好像大话设计中有）：

UML中类图实例

接口：空心圆+直线（唐老鸭类实现了‘讲人话’）；
依赖：虚线+箭头（动物和空气的关系）；
关联：实线+箭头（企鹅需要知道气候才迁移）；
聚合：空心四边形+实线+箭头（雁群和大雁的关系）；
合成/组合：实心四边形+实线+箭头（鸟和翅膀的关系）；
泛化/继承：空心三角形+实线（动物和鸟的继承关系）；
实现：空心三角形+虚线（实现大雁飞翔的接口）；

UML类图  

 

解释UML类图：

1.      首先看“动物”矩形框，它代表一个类。该类图分为三层，第一层显示类的名称，如果是抽象类就要用斜体显示。第二层是类的特性，通常就是字段和属性。第三层是类的操作，通常是方法和行为。

   注意前面的符号，‘+’表示public, ‘—’ 表示private, ‘#’表示protected.   

  

2.      “飞翔”矩形框表示一个接口图，它与类图的区别主要是顶端有《interface》显示，第一行是接口名称，第二行是接口方法。接口还有另一种表示方法，俗称棒棒糖表示法，就是唐老鸭类实现了“讲人话”的接口。

               

interfaceIFly                             interfaceIlanguage                              
{                                             {
   voidFly();                                   void Speak();
}                                            }

 

3.      动物，鸟，鸭，唐老鸭他们之间都是继承的关系，继承关系用空心三角形+实现来表示。   

                 

 

4.“大雁”实现了“飞翔”接口。实现接口用空心三角形+虚线来表示。（注：下面的图中应为空心三角形）

 

classBird:Animal                      class WideGoose:IFly
{                                       {
   //继承动物类                                 //实现飞翔接口
}                                       }

 

5.      企鹅与气候有很大的关系，企鹅需要“知道”气候的变化，需要“了解”气候规律。当一个类“知道”另一个类时，可以用关联(association)关系。关联关系用实线箭头来表示。  

       

class Penguin :Bird
{
   private Climateclimate;//在企鹅Penguin中，引用到气候Climate对象
}

 

6.      “大雁”和“雁群”这两个类。大雁是群居动物，每只大雁都属于一个雁群，一个雁群可以有多只大雁。所以它们之间就满足聚合(Aggregation)关系。聚合表示一种弱的“拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分。聚合关系用空心的菱形+ 实线箭头表示。

    

 

classWideGooseAggregate
{
   private WideGoose[]arrayWideGoose;
   //在雁群WideGooseAggregate类中，有大雁数组对象arrayWideGoose
}

 

7.      “鸟”和“翅膀”这两个类。鸟和翅膀似整体和部分的关系，并且翅膀和鸟的生命周期是相同的，在这里鸟和其翅膀就是合成关系。合成(composition)是一种强的“拥有”关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。合成关系用实心的的菱形+实线箭头来表示。另外，合成关系的连线两端还有一个数字“1”和数字“2”，，这被称为基数。表明这一端的类可以有几个实例，很显然，一个鸟应该有两支翅膀。如果一个类可能有无数个实例，则就用“n”来表示。关联关系，聚合关系也可以有基数的。

class Bird 
{
  private Wing wing;
  public Bird()
   {
      wing=new Wing();
    //在鸟Bird类中，初始化时，实例化翅膀Wing,它们之间同时生成
   }
}

 

8.      “动物”、“氧气”与“水”之间。动物有几大特征，比如有新陈代谢，能繁殖。而动物要有生命，需要氧气，水以及食物等。也就是说动物依赖于氧气和水。它们之间是依赖关系(Dependency),用虚线箭头来表示。

 

abstract class Animal
{
   public bolism(Oxygenoxygen,Water water)
    {
    } 
}

 

来源： http://blog.csdn.net/xhf55555/article/details/6896316/

来自为知笔记(Wiz)