UML是什么

面向对象的分析与设计(OOA＆D)方法的发展在80年代末至90年代中出现了一个高潮，UML是这个高潮的产物。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。

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开始致力于这一工作。他们首先将Booch 93和OMT-2 统一起来，并于1995年10月发布了第一个公开版本，称之为统一方法UM 08（Unitied Method）。1995年秋，OOSE 的创始人Ivar Jacobson加盟到这一工作。经过Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分别发布了两个新的版本，即UML 09和UML 091，并将UM重新命名为UML（Unified Modeling Language）。

1996年，一些机构将UML作为其商业策略已日趋明显。UML的开发者得到了来自公众的正面反应，并倡议成立了UML成员协会，以完善、加强和促进UML的定义工作。当时的成员有DEC、HP、I－Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI以及Unisys。这一机构对UML 10（1997年1月）及UML 11（1997年11月17日）的定义和发布起了重要的促进作用。

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

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

无双 回复于：2003-08-03 13:12:17

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的主要内容也可以归纳为静态建模机制和动态建

模机制两大类。

无双 回复于：2003-08-03 13:12:38

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适用于以面向对象技术来描述任何类型的系统，而且适用于系统开发的不同阶段，从需求规格描述直至系统完成后的测试和维护。

随便说几点,不一定全面,仅供参考

1ER图,即实体关系图,专用于数据库建模即对欲构建的数据库画出模型图是古老的有生命力的描述方法

2DFD,数据流图,用于描述数据在系统中的流动方向及变化,便开发人员把握数据的来龙去脉

3UML,统一建模语言,有十多张侧重不同的图形,面向整个软件开发过程

总之,相同点都是图形(表现力较文字更直观)

最近在进行UML学习过程中，突然忘记了大学时关于数据库理论中概念模型、逻辑模型、物理模型之间的区别。随机复习上网并复习，并在此记录一下，数据库建模是对现实世界进行分析、抽象、并从中找出内在联系，进而确定数据库的结构。

1、概念模型：就是从现实世界到信息世界的第一层抽象，确定领域实体属性关系等，使用E-R图表示，E-R图主要是由实体、属性和联系三个要素构成的。

2、逻辑模型：是将概念模型转化为具体的数据模型的过程，即按照概念结构设计阶段建立的基本E-R图，按选定的管理系统软件支持的数据模型（层次、网状、关系、面向对象），转换成相应的逻辑模型。这种转换要符合关系数据模型的原则。目前最流行就是关系模型（也就是对应的关系数据库）

E-R图向关系模型的转换是要解决如何将实体和实体间的联系转换为关系，并确定这些关系的属性和码。这种转换一般按下面的原则进行：

（1）一个实体转换为一个关系，实体的属性就是关系的属性，实体的码就是关系的码。

（2）一个联系也转换为一个关系，联系的属性及联系所连接的实体的码都转换为关系的属性，但是关系的码会根据联系的类型变化，如果是：

1：1联系，两端实体的码都成为关系的候选码。

1：n联系，n端实体的码成为关系的码。

m：n联系，两端实体码的组合成为关系的码。

3、物理模型就是根据逻辑模型对应到具体的数据模型的机器实现。物理模型是对真实数据库的描述。如关系数据库中的一些对象为表、视图、字段、数据类型、长度、主键、外键、索引、约束、是否可为空、默认值。

数据库关系模型(数据库逻辑模型)是将数据概念模型转换为所使用的数据库管理系统(DBMS)支持的数据库逻辑结构,即将E-R图表示成关系数据库模式。数据库逻辑设计的结果不是唯一的,需利用规范化理论对数据库结构进行优化。

在关系模型中,数据库的逻辑结构是一张二维表。在数据库中,满足下列条件的二维表称为关系模型:

1)每列中的分量是类型相同的数据;

2)列的顺序可以是任意的;

3)行的顺序可以是任意的;

4)表中的分量是不可再分割的最小数据项,即表中不允许有子表;

5)表中的任意两行不能完全相同。

由此可见,有序的航空物探测量剖面数据不满足数据库关系模型条件第3条“行的顺序可以是任意的”,因此,不能简单地直接利用关系数据库(如Oracle,SQL Server,Sybase等)来管理剖面数据,需将数据在数据库中的存储方式改为大字段存储,确保不因数据库数据的增加和删除等 *** 作改变剖面数据有序特性。

一、大字段存储

(一)大字段存储技术

大字段LOB(Large Object)技术是Oracle专门用于存放处理大对象类型数据(如多媒体材料、影像资料、文档资料等)的数据管理技术。LOB包括内部的和外部的两种类型。内部LOB又分CLOB(字符型)、BLOB(二进制型)等3种数据类型,其数据存储在数据库中,并且支持事务 *** 作;外部LOB只有BFILE类型,其数据存储在 *** 作系统中,并且不支持事务 *** 作。LOB存放数据的长度最大可以达到4G字节,并且空值列(没有存放数据)不占空间(图2-6)。

图2-6 大字段存储示意图

由于外部LOB存放在 *** 作系统文件中,其安全性比内部LOB差一些。此外,大字段的存储支持事务 *** 作(批量提交和回滚等),而外部LOB不支持事务 *** 作。所以,航空物探测量剖面数据采用BLOB来存储。对于BLOB类型,如果数据量小于4000字节,数据库通常采用行内存储,而数据量大于4000字节采用行外存储。分析航空物探测量剖面数据,每个场值数据占4个字节(单精度),目前航磁数据采样率为10次/s,4000字节只能存储100s数据;一般情况下航空物探测量每条测线飞行时间至少在10min以上,每条测线数据量远远大于4000字节。所以,航空物探测量剖面数据采用行外存储方式,即大字段列指定“Disable Storage In Row”的存储参数。

由于大字段类型长度可变,最大可到4G。假设测线飞行时间为T,场值采样率为n次/s,测线场值数据量为4Tn,所以有4Tn≤4G。单条测线飞行时间T不会超过10h(36000s,航空物探测量1架次至少飞行1个往返2条测线),则场值的采样率n≤4G/4T=4×1024×1024×1024/4×36000次/s=29826次/s。采用大字段来存储测量数据,不仅能够减少数据表的记录数,提高查询效率,而且使得采样率的扩展不受限制。

(二)大字段存储技术应用

由于航空物探数据的数据量较大,现有的航磁测量数据按基准点方式(点存储)存储可达几亿个数据记录。若按磁场数据采样点存储方式(简称“场值存储方式”),则记录条数=(磁场数据采样率/坐标采样率)点存储方式的记录数,达几十亿条数据记录,且随着数据采样率的扩展、测点的加密,航空物探测量数据量随着时间的推移呈现快速增长之势。显然,如果采用常规的表结构来存储,势必造成数据的存储、管理、检索、浏览和提取都非常困难。另一方面,从航空物探专业应用需求来说,很少对单个测点的场值数据进行运算、分析等 *** 作,一般至少是对一条测线或以上测线,多数时候是需要对整个测区的场值数据进行化极、上延、正反演拟合等。

因此,在航空物探数据库表结构设计时,改变过去将基准点或场值点数据记录作为数据库最小管理对象的理念,采用了大字段存储技术,将测线作为数据库最小管理对象,将测线上的测量数据,如坐标数据和磁场、重力场数据分别存储在相应大字段中。在航空物探数据库建设中,大量采用数据库的大字段存储技术(详见《航空物探信息系统数据库结构设计》)。

(三)大字段存储效率

以航磁测量数据为例分析大字段存储技术优势。如果以场值存储方式存储测线数据,则每条记录包含架次号、测线号、基准号、地理坐标、投影坐标、磁场数据等,由于坐标数据采样率2次/s,磁场数据采样率10次/s,每5个磁场数据中,只有第1个磁场数据有坐标数据,其他4个坐标数据是内插出来,因此在测线记录中会产生大量冗余的数据坐标数据。采用点存储方式存储的测线数据记录数等于线上基准点数,若采用大字段存储方式,一条测线数据只存储为1条数据记录(图2-7),一般一条测线的测点数近万个,甚至更多,可见采用大字段存储大大减少测线数据存储记录数,提高数据的存取效率。

以某测区的两条航迹线为例,分别采用3种方式测试数据库的数据存储效率。磁场数据的采样率10次/s,坐标数据采样率2次/s,两条测线上共有基准点8801个。以场值方式存储先内插坐标信息,使得每个场值数据都拥有自己的坐标,然后存入数据库,共有数据记录44005条,写入数据库时间为5722s,读取时间为103s。第二种方式是以采样点的方式进行存储,共有8801条记录,写入数据库时间为947s,读取需要091s。第三种方式是以大字段的形式存储,只有2条记录,写入数据库103s,读取时间为044s(表2-2)。大字段数据存储记录数最少,存取效率最高。用整个测区数据测试效果更加明显。

表2-2 三种数据存储方法的存取效率比较

图2-7 大字段存储方式示意图

二、联合主键

主外键是关系型数据库建立表间关系的核心。在航空物探空间数据库建设过程中,要素类与要素类之间、要素类与对象类之间,以及对象类与对象类之间的关系的描述有3种形式,即拓扑关系——描述要素类与要素类之间结点、邻接和联通关系;叠加关系——描述要素类与要素类之间的相交、包含与分类关系;隶属关系——描述对象类与对象类之间的派生关系。前两种关系是采用空间数据模型建立的关系,而隶属关系是通过主键建立的对象类与对象类之间的关系。在建立一对一、一对多的表间关系时,需要在整个数据库表中确定具有唯一性的一个字段作为主键(主关键字)。

按照传统的航空物探数据的档案管理模式,每个项目分配一个自然数作为档案号,项目的所有资料均与此档案号相联系。勘查项目和科研项目的档案号是独立编号的,且均从001开始。加之人工管理的原因,存在1个项目2个档案号和2个项目1个档案号的情况,因此现行的档案号与项目之间的对应关系不具备唯一性,不能作为项目的唯一标识,即不能作为数据库表的主键。项目编号也不能作为数据库表的主键,项目编号也只是近十年的事,以前的项目没有项目编号。

综合考虑上述因素和项目具有分级、分类的特点,提出了构造项目唯一标识码(简称“项目标识”)的方法,并以此码作为数据库表的主键。

项目标识(主键):AGS+项目类别(2位)+项目起始年份(4位)+档案号(6位)

标识含义:AGS——航空物探的缩位代码;

项目类别——2位代码,01代表勘查项目、02代表科研项目;

起始年份—4位代码,项目开始年号;

档案号—6位代码,为了与传统的项目管理方式相衔接,后面3~4位是

项目档案管理模式下的档案号,不足部分补零。

以上15位编码是一级项目的项目标识,二级及其以下级别的项目标识是在上一级项目标识基础上扩展2位数字代码,中间用“”号隔开,数字为该级项目的序号。项目标识定义为30位编码,适用于六级以内的项目。例如:AGS022004000576080402,表示该项目为2004年开展的档案号为576的航空物探科研项目(一级项目)的第8课题(二级项目)第4子课题(三级项目)的第2专题。由此可见,该项目标识不仅仅是一个建立表间关系的关键字,同时还表达了不同级别项目间的隶属关系。在系统软件开发时,利用此关系生成了项目的分级树形目录,用户对项目的层次关系一目了然,便于项目查询。

数据库的主键一经确定,相应地需要确定联合主键的组成及其表达方式。所谓联合主键就是数据资料的唯一标识,在一个数据库表中选择2个或者2个以上的字段作为主键。由于航空物探数据绝大部分与项目标识有关,加之数据的种类较多,分类复杂,单凭主键确定数据库表中记录的唯一性,势必需要构建极其复杂的主键,这种方法既不利于主键的数据 *** 作,又会造成大量的数据冗余,合理地使用联合主键技术可以很好地解决资料唯一问题。以项目提交资料为例,提交的资料分为文字类资料、图件类资料和媒体类资料,我们对资料进行分类和编号,例如100代表文字资料(110——World文档,120——PDF文档),200代表图件资料(210——基础地理资料、220——基础地质资料,230——航迹线图,240——剖面图,250——等值线图等),300代表媒体资料(310——PPT文档,320——照片等),第1位(百位)表示该资料的类型,第2~3位表示该类资料的序号。

在数据库管理和项目资料查询时,采用项目标识与资料分类编号作为联合主键(图2-8),可以高效地实现复杂数据的查询。在整个数据库系统中多处(项目查询、数据提取等模块)使用联合主键技术。

图2-8 联合主键实例

三、信息标准化

为了实现数据共享,在航空物探数据库建模过程中,参考和引用了近百个国家信息化标准,编制了4个中心信息化标准和1个图件信息化工作指南。

(一)引用的国家信息化标准

1)地质矿产术语分类代码:地球物理勘查,地球化学勘查,大地构造学,工程地质学,结晶学及矿物学,矿床学,水文地质学,岩石学,地质学等。

2)国家基础信息数据分类与代码,国土基础信息数据分类与代码,地球物理勘查技术符号,地面重力测量规范,地面磁勘查技术规程,地面高精度磁测技术规程,大比例尺重力勘查规范,地理信息技术基本术语,地理点位置的纬度、经度和高程的标准表示法,地名分类与类别代码编制规则。

3)地球空间数据交换格式;数学数字地理底图数据交换格式;数字化地质图图层及属性文件格式。

(二)本系统建立的信息化标准

编写了“航空物探空间数据要素类和对象类划分标准”,“航空物探项目管理和资料管理分类代码标准”,“航空物探勘查分类代码标准”,“航空物探信息系统元数据标准”,“航空物探图件信息化工作指南”,以便与其他应用系统进行信息交换,实现数据库资料共享。

航空物探空间数据要素类和对象类划分标准:根据物探方法、数据处理过程以及推断解释方法和过程,把与GIS有关的数据划分为不同类型的要素类-对象类数据,按专业、比例尺、数据内容对要素类和对象类进行统一命名,使空间数据库中的每个要素类和对象类的命名具有唯一性,防止重名出现。规定要素类-对象类数据库表结构及数据项数值类型。

航空物探项目管理和资料管理分类代码标准:规定了航空物探项目管理和资料管理的相关内容,包括航空物探勘查项目和科研项目的项目立项、设计、实施、成果、评审、资料汇交等项目管理的全过程中的内容,以及项目成果资料和收集资料的归档、发送、销毁、借阅等资料管理与服务过程中的内容和数据项代码。

航空物探勘查分类代码标准:在“地质矿产术语分类代码地球物理勘查”(国家标准GB/T964928—1998)增加了航磁、航重专业方面所涉及的数据采集、物性参数、方法手段、仪器设备、资料数据解释及成图图件等内容和数据项代码。

航空物探信息系统元数据标准:规定了航空物探空间数据管理与服务的元数据(数据的标识、内容、质量、状况及其他有关特征)的内容。

四、航迹线数据模型

(一)航迹线模型的结构

航空物探测量是依据测量比例尺在测区内布置测网(测线和切割线)。当飞机沿着设计的测线飞行测量时,航空物探数据收录系统按照一定的采样率采集采样点的地理位置、高度和各种地球物理场信息。采用属性数据分置的方法,将测线地理位置信息从航空物探测量数据中分离出来,形成航迹线要素类表,在此表中只存储与航迹线要素类有关的数据,如项目标识、测区编号、测线号、测线类型(用于区分测线、切割线、不同高度线、重复线等)、坐标、高度值等;将航迹线的对象类数据(磁场、重力场基础数据)分别以大字段形式存储在各自的二维表中,它们共享航迹线,解决了多源有序不同采样率的航空物探测量数据的数据存储问题,在满足要素类空间查询的同时,统一数据的存储方式(图2-9)。航迹线要素类隶属于测区要素类,它们之间为空间拓扑(包含)关系。测区从属于勘查项目,每个勘查项目至少有一个测区,它们之间为1对多关系。有关项目信息存放在项目概况信息对象类表中,各种表之间通过项目标识进行联接。

图2-9 航迹线数据模型结构

(二)航迹线的UML模型

统一建模语言UML(Unified Modeling Language)是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。UML是面向对象技术领域内占主导地位的标准建模语言,成为可视化建模语言的工业标准。在UML基础上,ESRI定义了空间数据库建模的ArcGIS包、类库和扩展原则。

图2-10 与航迹线有关的数据库表逻辑模型结构图

在确定航迹线数据模型后,以它为基础,使用UML完成与航迹的有关的项目概况信息、测区信息、原始数据等数据库表逻辑模型设计(图2-10)。

由UML模型生成Geodatabase模式时,模型中的每个类都对应生成一个要素类或对象类。类的属性映射为要素类或对象类的字段。基类属性中包含的字段,在继承类中不需重复创建。例如,每个类都包括项目标识等字段,可以创建一个包含公共属性的基类,其他类从该类继承公共的属性,而无需重复建基类中包含的属性。因为基类没有对应的要素类或对象类,所以将基类设置为抽象类型。要素类之间的关系采用依赖关系表示。

五、数据库逻辑模型

关系数据库的逻辑结构由一组关系模式组成,因而从概念结构到关系数据库逻辑结构的转换就是将概念设计中所得到的概念结构(ER图)转换成等价的UML关系模式(图2-11)。在UML模型图中,要素数据集用Geodatabase工作空间下的静态包表示。要素集包不能互相嵌套,为了容易组织,在生成物理模型后,在要素数据集包中自定义嵌套。要素数据集与空间参考有关,但是空间参考不能在UML中表达。要素类和二维表都是以类的形式创建的,区别是要素类继承Feature Class的属性,而二维表继承Object属性。为了表达每种元素的额外属性,比如设置字符型属性字段的字符串长度,设置要素类的几何类型(点、线或面)需要使用Geodatabase预定义的元素标记值。

图2-11 逻辑设计关系转换

基于航空物探数据的内在逻辑关系进行分析,使用统一建模语言(UML)构建数据实体对象间的关系类,定义了航空物探数据库的逻辑模型(图2-12)。

随便说几点,不一定全面,仅供参考

1ER图,即实体关系图,专用于数据库建模即对欲构建的数据库画出模型图是古老的有生命力的描述方法

2DFD,数据流图,用于描述数据在系统中的流动方向及变化,便开发人员把握数据的来龙去脉

3UML,统一建模语言,有十多张侧重不同的图形,面向整个软件开发过程

总之,相同点都是图形(表现力较文字更直观)

数据类型，，就是变量所能保存的数据的类型

每个变量都具有数值和数据类型，比如，str1='dadssf' ,str1是变量名，dadssf是数值，而dadssf很明显不是数字，所以这个应该是字符串类型

换言说，在UML中设计 str1 是 字符串类型的话，那么str1的数值在存储在数据库中的时候就不能以数字的方式存在。

若 设定 变量 lon1的 值为 3 ，lon1的数据类型为长整型 —— lon1=3，那么此数值可以被用来计算等等

若 设定 变量 lon2的 值为 5 ，lon2的数据类型为字符串 —— lon2=5，那么此数值不可以被用来计算，只能当做文字来使用

——数据类型 限制或表明了变量所能存储的数据的样式、范围甚至用途。

当在UML中设计的时候，每个属性的或变量的类型，是根据需要设计的。

以上就是关于UML是什么全部的内容，包括:UML是什么、uml ER图的联系与区别、使用uml进行数据建模时，用什么来建模数据表中的主键等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！