• 统一建模语言UML释义


    UML全称Unified Modeling Language

    统一建模语言(UML)是用来对软件密集系统进行描述、构造、视化和文档编制的一种语言。

    首先,也是最重要的一点,统一建模语言融合了Booch、OMT和OOSE方法中的概念,它是可以被上述及其他方法的使用者广泛采用的一门简单、一致、通用的建模语言。

    其次,统一建模语言扩展了现有方法的应用范围。特别值得一提的是,UML的开发者们把并行分布式系统的建模作为UML的设计目标,也就是说,UML具有处理这类问题的能力。

    第三,统一建模语言是标准的建模语言,而不是一个标准的开发流程。虽然UML的应用必然以系统的开发流程为背景,但根据我们的经验,不同的组织,不同的应用领域需要不同的开发过程。举个例子来说,开发错综复杂的软件是非常有趣的工作,但开发这种软件与构造严格实时的航空电子系统是大不一样的,后者是性命攸关的大事。因此我们首先把精力集中在设计通用的元模型上(统一不同方法的语义),其次是建立通用的表示法(提供对这些语义的形象化的表达)。虽然UML的开发者们将继续倡导从用例驱动体系结构为中心最后反复改进、不断添加的软件开发过程,但实际上设计标准的开发流程并不是非常必要的。

    UML的基本组成

    UML的基本成分什么是呢?这个问题可以从两个方面来回答:UML

    的定义及如何应用UML构造系统框架。

    UML定义的基本内容

    为了有助于对统一建模语言本身(“内部”观点)的理解,我们把文档划分为UML简介(本文档)、UML语义UML表示法指导UML特定进程扩展这几部分。下面,我们将对这些文档的内容作简单的介绍。除了这些文档之外,其他有关UML的理解、范例以及习惯用法等内容的书籍也将陆续出版。

    UML语义

    该文档通过叙述性的语言和UML表示法对UML精确模型作了详细描述。UML开发者们用UML表示法及英文说明文字提出了一个严格的元模型。提出这个元模型是为了给UML要素的语法和语义作简单、一致的定义性说明。它把UML的语义与因人而异的最佳表达方法相分离,从而使开发者们能够对UML的语义达成一致意见。另外,这个元模型还使开发小组有可能通过(从某种意义上来说)统一UML的元素来大大简化UML。(例如,我们发现类型、模式和用例这三个概念之间存在着相似之处。)开发者们希望通过描述元模型的语义,从而选择那些能更精确的表达元模型的规范技术。

    元模型是描述模型的语言。现在指对象模型。元模型非常重要,因为它能对模型的语法和语义提供简单、通用、明确的描述。在模型里,元的“层次”有点儿任意。UML的开发者们有意识的选择语义丰富的元“层次”,因为这是工具交互和复杂系统设计所依赖的语义丰富的协议的必然要求。

     UML表示法指南

    UML表示法指南集中介绍了UML的表示法,并给出了一些范例。当开发者或开发工具应用UML建造系统模型时,图形符号和文本语法是最直接可见的部分(“外部”观点)。这些图形符号和文字所表达的是应用级的模型。应用级模型是UML元模型的实例。UML标准的图表类型见 4.1.2 节。

     UML进程扩展

    该文档主要介绍UML扩展机制中的进程特定的扩展(例如,构造型, 特征值和限制条件等),以及其相应的符号(如果有的话)。

    开发

    设计怎样的模型对问题的解决及系统的开发有重要的影响。抽象,即抓住相关细节、忽略无关信息,是学习和交流的基本方法。因为:

    复杂的系统可以从系统模型的不同角度来更好的理解。只从一个角度来考察系统是不够的。

    一个模型可以表示成不同的抽象层次。

    优秀的模型是同实际相联系的。


    UML从考察系统的不同角度出发,定义了下列图表:

    用例图

    类图

    行为图

    状态图

    活动图

    时序图

    协同图

    实现图

    构件图

    安装维护图


    这些图表从不同的侧面对进行分析或设计的系统进行描述。系统模型把这些不同的侧面综合成一致的整体,便于系统的分析和构造。尽管UML和其他开发工具还会设计出许多派生的视图,但上述这些图表和其他辅助性的文档是软件开发人员所见的最基本的结构。上述图表将在文档UML表示法指南中详细介绍。

    表示法和语义的发展史

    UML是在Booch、OMT、OOSE等面向对象的方法及许多其他来源的基础上发展起来的。UML包含了来自许多人员的各种不同的观点,也受到了非面向对象方法的影响。UML表示法混合了不同的图形表示方法,剔除了其中容易引起混淆、冗余的、或者很少使用的符号,同时增添了一些新的符号。UML中的概念来自于面向对象技术领域中众多人员的思想。UML开发者们并没有提出其中大部分的观点,而只是对优秀的面向对象和计算机科学的方法加以选择和综合。表示法和语义的实际发展历程是非常复杂的,这里介绍的只是一些简单的背景知识,而不是详细的发展史。

    UML用例图与OOSE方法类似。

    UML的类图综合了OMT、Booch等面向对象方法中的类图。各种图表可以通过进程特定的扩展(如构造型及相应的符号)来支持其他的建模方法。

    UML的状态图是对David Harel所提出的状态图的改进。UML活动图的基本语义与状态图大致相同,它类似于许多方法(包括面向对象技术以前的一些方法)中的工作流图。

    你可以在许多面向对象的方法中发现UML时序图的影子(如交互作用、消息流 事件流)等,甚至可以追溯到面向对象技术以前的方法。UML的协同图是通过对Booch方法的对象图、Fusion方法的对象交互作用图以及其他一些方法中的相关图表改造而来的。

    协同是比较基本的建模元素,它构成了模式的基础。

    UML的实现图(构件 安装维护图)是在Booch方法中的模块进程图(处理器关系图、处理器图)的基础上发展起来的,但UML的实现图以构件为中心而不是以模块为中心,相互之间的联系也更紧密。

    构造型是UML扩展机制中的一种,它扩展了UML元模型的语义。构造型还可以附带用户定义的符号,以满足特定开发流程的需要。

    上述的这些概念有着深远的渊源和影响,我们只能进行简单扼要的介绍。UML实际上是计算机科学和软件工程学长期发展的产物。

    UML未涉及的领域

    UML定义1.0版并没有提出开发工具和开发流程的标准,这是因为两者所考虑的问题有很大不同。标准化的建模语言是开发工具和流程的必要基础。

    工具

    对象管理小组的RFP(OADTF RFP-1)是推动UML开发的重要力量。RFP的初衷是增强开发工具彼此之间相互协作的能力,但实际上,开发工具及其可协作性在很大程度上依赖于一致的语义和表示法定义(如UML)。虽然UML定义的是语义元模型,而不是工具元模型,但这两者是非常接近的。在语义和表示法定义的基础上,很容易制订出一致的开发工具交互标准。

    在向OMG提交UML的同时,UML开发者们还提交了一个依从UML的工具接口定义。这个定义在大批量数据传送的编码和语法方面采用了CDIF/ EIA标准。

    UML文档中包括一些给工具开发者的有关具体实现的建议,但并没有对所有的问题作出回答。例如,文档中没有关于图表设计、色彩、用户索引、生动性等特点的内容。

    开发流程

    许多组织都把UML作为框架设计的通用语言,并在各种不同类型的开发流程中使用UML的图表。UML并不依赖于特定的开发流程方法,定义标准的开发流程并不是UML开发的计划,也不是OMG的要求。

    但UML的开发者确实认识到了开发流程的重要作用。是否存在一个严格定义、管理方便的工作流程是区别项目水平高低的关键。繁重的编程并不是持久的商业开发方法。开发流程可以1)指导制订开发小组的行动规划,2)确定开发的框架,3)从总体上指导个人和开发小组的工作,4)提供监督和衡量项目成果及开发工作的标准。

    项目的流程在本质上要满足不同组织、不同风格、不同应用领域的需要。在某些情况(例如错综繁绕的软件的开发)下有效的开发流程方法很可能在其他情况(如严格实时的系统开发)下效果并不是很好。应用领域、实现技术和开发小组的技能在很大程度上决定了工作流程的选择。

    Booch、OMT、OOSE以及许多其他方法都有自己严格定义的开发流程,UML可以支持其中大部分的开发流程方法。虽然人们已经认识到了开发流程的重要作用,但流程标准化的问题还没有引起足够的重视。目前,更有可能发生的情况是人们普遍认同一些优秀的方法,选择某种开发流程的框架,并在这个框架的基础上规划自己的工作流程。虽然UML没有强制使用特定的开发流程,但UML的开发者们更提倡从用例驱动到以体系结构为中心最后反复改进、不断添加的软件开发过程,因此在UML定义中谨慎的提出了这个方法。

    UML与Booch、OMT、OOSE以及其他建模方法的比较

    首先必须明确统一建模语言并没有从根本上脱离Booch、OMT或OOSE方法,而是对这些方法的有批判的继承。这就意味着,如果目前你是一名Booch、OMT 或OOSE方法的使用者,你接受的培训、你的工作经验和所偏好的开发工具都可以保留下来,因为统一建模语言是对这些方法的延续。对于其他方法的使用者来说,UML同样很容易接受。但这些方法的作者必须决定是否在他们的方法中采用UML的概念和表示法。

    与Booch、OMT、OOSE等??他方法相比,统一建模语言有表达力更强、更清晰和一致的优点。因此,转而采用UML并不是毫无意义的,它可以使工程在更广的范围内建模。其他大多数方法和建模语言的使用者也会因采用UML而受益,因为UML消除了各种方法在表示法和术语上的不必要的差异,而正是这些差异隐藏了不同方法之间重要的相似之处。

    相对于其他可视化建模语言,例如基于实体和关系的模型化方法、BPR流图、状态驱动的建模语言等,UML更富有表达力,机能更完善。

    从现有的方法到UML,在表示法上会有略微的变化,但这并不需要使用者花很长的时间从头学习,而且可以使关键性的语义更加明确。如果UML统一的目标得以实现,那么随着有关UML的开发工具,书籍和培训课程的逐渐推广,UML将成为开发项目首选的建模方法。目前,许多可视化的建模工具将现有的表示法,如Booch、OMT、OOSE等方法,作为模型的不同视图;随着这些工具对UML的支持,使用者将会很容易的把其他方法的模型转换成UML模型,而不会丢失任何信息。

    任何面向对象方法的使用者都可以通过短期的学习而获得与以前相同的表达能力。你可以很快就熟练掌握UML的基本使用。高级的UML技术,如构造型和属性的使用,还需要你更深入的学习。这些高级技术可以使模型更精确,更富有表达力。

    UML的新特点

    UML的开发是为了简化建模方法,它抛弃了Booch、OMT和OOSE方法中的糟粕,而代之以其他方法中的精华。只有在没有现有的解决方法时,UML的开发者们才考虑增加新的特点。UML的开发者们是在设计一门语言(尽管只是一门图式语言),因此必须在简单(所有元素一律用方框和文字表达)和烦琐(为每个元素设计单独的符号)之间取得平衡。UML的设计者对增加新的元素非常谨慎,因为他们不想使UML过于复杂。尽管如此,UML中还是增添了一些新的元素,因为这些元素在其他建模语言的实践中已经被证明是非常有用的。

    UML中增加了下列新概念:

    构造型

    责任

    扩展机制:构造型、特征值及限制条件

    线程和进程

    分布及并发(如建模ActiveX/DCOM 和CORBA)

    模式/协同

    活动图(用于商业进程再工程)

    类型、类和实例的明确区分

    求精(处理不同抽象层次)

    界面和构件


    这些概念中的大部分都已经在其他方法和理论中提出了,UML把它们统一成一个整体。除了这些较大的变化外,我们还对Booch、OMT和OOSE方法的语义和表示法作了一些局部改动。

  • 相关阅读:
    Flask上下文管理源码分析 ——(3)
    Flask 快速使用 进阶—— (2)
    HTML-语法
    安装kubenetes-遇到的问题总结
    CentOS7-部署kubernetes
    k8s-部署及介绍
    docker-macvlan网络
    Dom编程-左侧菜单栏设计模型实现
    JavaScript-checkbox标签-隐藏、显示、全选、取消和反选等操作
    docker-Overlay原生网络
  • 原文地址:https://www.cnblogs.com/chaowei119/p/255006.html
Copyright © 2020-2023  润新知