【软件架构】UML作为数据建模符号:第一部分

UML as a Data Modeling Notation, Part 1

UML as a Data Modeling Notation, Part 2

UML as a Data Modeling Notation, Part 3

UML as a Data Modeling Notation, Part 4

 

这一系列文章有两个受众：数据建模者，他们确信UML与他们无关；以及UML专家，他们没有意识到数据建模实际上与对象建模不同（而且差异很重要）。提交人的目标是最终使这两个群体和平共处。

该系列分为三部分。在这里，第一部分设置了阶段，描述了符号之间的基本差异以及如何协调它们。第二部分将发表在下一期的《数据管理通讯》中，它将更详细地介绍子类型和约束，以及UML中不应用于数据模型的内容，以及必须添加的“刻板印象”。而且，由于准备数据模型的全部目的是将其呈现给管理层进行验证，因此第三部分讨论了准备和呈现数据模型的美学——无论使用何种符号。

简介1：用于数据建模器

前提：UML中的类模型与实体/关系模型不是一回事。

数据建模师（至少）有两种风格。你们中的一些人（数据库组）将数据建模视为数据库设计的前奏，事实上，在数据模型中包含了许多关系设计概念（如“外键”）。使用ERrwin作为建模工具特别有利于这种思维方式。第二组（业务概念组）将数据建模视为捕获业务语言的一种方式，而不考虑有朝一日可能捕获数据的数据库管理系统。这个群体倾向于更抽象地看待世界，更关心准确地描述业务，而不是关心数据库性能等问题。

这两个小组都认为UML至少是令人讨厌的，如果不对他们的世界观构成威胁的话。首先，面向对象的数据方法与关系数据库方法有很大不同。最重要的是，面向对象广泛使用子类型（继承），而这不能在纯关系数据库中直接表示。

其次，数据库管理员将数据库视为公司资源，并负责控制对数据及其定义的访问，而面向对象的开发人员则负责将数据作为程序设计的基础。正如面向对象的设计者所使用的那样，UML中的类是指一段描述其属性和行为的程序代码，该类中的对象根据需要存在和消失。

UML“类模型”也不同于业务概念实体/关系模型，因为面向对象的社区在指定类的组成方面不受约束。几乎任何东西都可以是要收集到类中的对象。另一方面，在实体/关系世界中，在面向业务的数据模型中，实体类只能对它希望保存信息的业务具有重要意义。

当然，数据建模师自己有时在决定什么构成对象时有点随心所欲，所以也许他们也可以从本文中学习。

问题是UML就在这里。无论它有什么缺陷，它都被广泛认为是一种标准。我们可以宣称（正如您的作者所宣称的）它与数据建模有着根本的不同，与数据库设计无关——但客户和招聘经理一直在问您是否知道如何使用UML。

多年来，您的一位作者一直是UML对类模型方法最强烈的反对者之一，主要是基于美学的原因[Hay，1999]。然而，碰巧的是，今年，David Hay已经“走向黑暗面”，并一直在为UML的创建者对象管理小组（OMG）做一个项目。该项目旨在生成一组元模型来描述实体/关系建模本身，以及关系数据库设计、XML Schema设计等。在这个项目中，有必要生成本质上是“概念性”的实体/关系模型，但由于它是OMG，所以有必要使用UML类表示法。

好吧，这是真的。这是可以做到的。可以肯定的是，操纵UML的工具使用起来要复杂得多，因为UML（甚至是类模型）包含的内容远远超过了实体/关系模型所需的内容，但只要有耐心，就可以取消并使用适当的符号子集。这是一个关闭工具中各种选项的问题。可以肯定的是，一开始似乎有一些逻辑障碍阻碍了这一点。但事实证明，有一个“秘密握手”（同样是工具中必须关闭的选项）解决了这个问题。

本文向您展示了如何做到这一点。它将采用熟悉的概念，并向您展示如何使用UML表示法来表示它们。这个符号不漂亮（我们敢说吗？）。但它是可用的。

然而，请注意，尽管存在UML建模的问题，但即使在数据建模社区中，人们对什么构成“好”的数据模型也有非常不同的想法。因此，请注意，这篇文章确实反映了作者的偏见。我们已经做了二十多年的数据建模，从一开始我们就学会了将其作为一种语义而非技术学科来处理。

这篇文章将反映那段历史。

因此，尽管本文将向UML建模人员展示如何扩展他们的视野，以一种新的方式使用他们的表示法，但也许它也将为数据建模人员提供对他们生成的模型的新见解。

简介2：用于UML建模器

前提：实体/关系模型与UML中的类模型不是一回事。

统一建模语言（UML）最初是支持面向对象设计的符号集。它是从各种现有方法中派生出来的，因此，它不是一个单一的符号，而是一系列用于建模各种元素（如类、行为、事件和其他）的符号。

到20世纪90年代初UML出现时，使用模型来支持发现业务的系统需求已经得到了高度发展。数据流图和实体/关系数据模型都已有近20年的历史。在这种情况下进行建模（无论是数据流、事件还是数据结构），都清楚地区分了业务性质建模和支持该业务的系统建模。

描述业务性质和结构的一个特别强大的工具是实体/关系图。这种对企业具有重要意义的事物或对象以及它们之间的关系的绘制可以用来让业务人员清楚地看到分析师误解了什么。在建模过程中发现这样的误解比在随后花费巨大代价构建的系统中发现它们要便宜得多。

因为程序经常描述现实世界中的事物，所以支持设计的UML类模型看起来很像支持需求分析的实体/关系模型。例如，Meiler-Page-Jones在他的一组对象类中包括了那些引用真实世界事物的类。他写到了类的“域”——比如“业务域”和“应用程序域”[Page Jones 2000]。由此，面向对象的世界得出结论，它创造了“面向对象的分析”。

嗯，没有。需求分析（正如它在过去30年左右发展起来的那样）不能是“面向对象的”，就像它可以是“面向关系的”或“面向COBOL的”一样。需求分析从根本上讲是关于业务的，而不是关于技术的。

根据UML的“三个朋友”，“对象是一个”离散实体，具有定义明确的边界和标识，封装状态和行为；类的实例“[Rumbaugh，et al.1999，p.360]“类”反过来是“共享相同属性、操作、方法、关系和行为的一组对象的描述符”[Rumbauh，et al.1999，p.185]请注意，在这两个定义中，对感兴趣的对象或类的类型都没有限制。任何东西都是物体。

实体/关系建模世界使用类的方式与UML中的类似，但它的定义要窄得多。首先，“实体”（在实体/关系世界中）与“对象”（在面向对象世界中）不同，它与操作、方法或行为无关。它们属于“过程建模”的世界。实体/关系模型只关心数据的结构。其次，实体/关系模型中的实体类不仅仅是任何“具有明确边界和身份的离散实体”。它仅限于理查德·巴克（Richard Barker）所说的那些“有意义的东西，无论是真实的还是想象的，需要了解或掌握的信息。”[Barker 1989年]

Barker的方向是只针对那些对业务感兴趣的实体，而UML包含任何可以想到的对象和类。事实上，根据James Martin和James Odell的观点，“对象类型”（“类”）只是“一个概念”[Martin&Odell 1995，pp，34143]。

任何概念。

除了业务感兴趣的那些元素和工件之外，这还包括计算机元素和工件。

这是否意味着UML类图表示法不能用于生成概念实体/关系图？当然不是。巴克实体当然是由三个朋友定义的对象的子集。

但重要的是要认识到三件事：

• 只有与手头的业务相关的实体类1才会被处理。
• 只有UML中使用的符号的子集可以用来表示业务的语义。
• 符号的含义与面向对象世界中使用的符号的含义有着根本的不同，即使是微妙的不同。

由于这些含义略有不同，使用这些子集的图与使用信息工程符号、Barker-Ellis符号或任何其他符号的对应图具有完全相同的语义。

顺便说一句，增加了一节关于数据模型中所需的美学特征的内容，并简单介绍了如何向业务观察者展示模型。之所以包括这一点，是因为无论使用何种表示法，概念实体/关系模型都旨在成为与业务沟通的手段。与两个阵营中的一些人所认为的相反，美学是重要的。

这些文章（对两位读者来说）最简单的部分是理解这种方法所需的符号。更困难的是在每种情况下都需要改变态度才能取得成功。

在继续之前，应牢记三点意见。

• 数据建模师有好有坏
• UML建模师有好有坏。
• 两个“社区”都不是同质的。

本系列文章的目的是为所有建模人员提供如何使用UML类图表示法生成优秀概念实体/关系模型的指导。

NOTATION

 

各种形式的实体/关系表示法和UML都可以描述实体类和关系。图1显示了Richard Barker和Harry Ellis开发的符号中的模型片段。它声称，订单的实例将由“订单号”和“订单日期”的值来描述，而行项目则由“行号”、“数量”、“价格”和“交货日期”的数值来描述。此外，还可以为LINE ITEM的每个实例计算值“（扩展值）”。

此外，该模型片段断言：

• 每个订单可能由一个或多个行项目组成，以及

• 每个行项目必须是一个订单的一部分。2
   

  

图1：Barker-Ellis符号中的关系

图2显示了完全相同的信息，但采用了UML形式。

在Barker-Ellis表示法中，可能是第一个断言的一部分由连接到第一个实体类（ORDER）的虚线表示。在UML模型中，这由第二个实体类（LINE ITEM）旁边的“0..”表示法表示。在Barker-Ellis表示法中，必须是第二个断言的一部分由第一个实体类line ITEM旁边的实线表示）。在UML模型中，它由第二个实体类（ORDER）旁边的“1..”表示。

在UML版本中，第一个断言的多个部分不是在Barker-Ellis表示法中由第二个实体类旁边的“鱼尾纹”（<--）符号表示的，而是由第二实体类旁的“..*”表示的。在Barker-Ellis表示法中，第二个断言的确切一部分不是由直线（没有鱼尾纹）表示的，而是由第二个实体类旁边的字符“..1”表示的。

图2:UML中的关系

这两种形式在语义上是等价的。

请注意，形式“1..1”通常缩写为“1”。

因为在Barker-Ellis表示法中，表示法的可选性部分（“可能是”或“必须是”）紧挨着第一个实体类，所以按照惯例，关系名称也紧挨着一个实体类。在UML中，可选性由第二个实体类旁边的符号表示。因此，在UML的情况下，关系名称位于第二个实体类的旁边。为了保护那些必须同时使用这两种符号的人的理智，在所有情况下，关系句都是按顺时针方向阅读的：从左到右，从右到左。

在Barker-Ellis模型中，强制属性用星号（*）或八叉（#）3指定，可选属性用圆圈（0）指定。在UML中，用于关系的相同符号也用于属性。示例中的强制属性注释为“[1]”，表示“1..1”，这意味着至少需要一个值，但不允许超过一个。可选属性注释为“[0..1]”，这意味着不需要一个值，但也不允许超过一个值。在实体/关系建模世界中，第二个“..1”是不必要的，因为禁止多值属性的原始关系理论规则是有效的。在UML世界中，这样的事情是允许的，所以“..1”将始终存在。

请注意，严格地说，任何表达式都可以用来描述关系的每一端所扮演的角色，但在有纪律的数据建模中，有严格的规则，如下节所述。
语言

实体/关系图主要是对组织的英语断言的图形描述。因此，图表上出现的唯一语言必须使用与业务相关的术语。也就是说，只有商业术语（和传统英语）可以用作实体类的名称和角色的名称。

请注意，排版约定（实体类名均为大写，关系为斜体）是不必要的。事实上，在所有正常情况下都可以显示句子。然而，区分本教程中的成分是有帮助的，这样它们在句子中的作用就清楚了。
实体类

实体类是“对企业具有重要意义的事物或对象的名称，无论是真实的还是想象的，需要了解或掌握有关信息。”[Barker 1989，第5-1页]。这可能是一个具体的东西，比如人或地理位置，也可能是一种抽象，比如行项目或项目角色。

UML概念“类”的一个子集可以用于此，前提是它被理解为仅指实体/关系模型类——这对企业来说是重要的，并且只有遵循此处描述的命名约定。

具体来说，实体类的名称是单数形式，并引用该类的实例。因此，订单，行项目，如上所述。虽然不允许使用“项目历史记录”的名称，但一个名为Project的实体类可能会随着时间的推移包含实例，因此它实际上可能是一个项目“历史记录”。但它并不是这样命名的。不允许使用数据库表名，也不允许使用缩写或缩略词4作为计算机工件的类（“窗口”、“光标”等）。
属性

在UML中，实体/关系模型中的属性是实体类的一个特征，“用于限定、识别、分类、量化或表达实体的状态”[Barker 1989，p.5-6]。在上面的例子中，ORDER的属性是“订单号”和“订单日期”。LINE ITEM的属性为“行号”、“数量”、“价格”和“/扩展值”。“扩展值”前面的“/”是计算字段的UML符号。（大多数实体/关系符号都没有这样的符号，尽管作者的约定用括号括起了名称。）/Extended值的每个值都源自“数量乘以价格”表达式。该算法未显示在实体/关系图中，但必须在后台进行记录。在UML中，它可以显示在图形上的注释中。

UML能够显示关于一个属性的大量内容：它的数据类型，它的“可见性”5，无论它是否为“只读”，等等。在实体/关系版本中，唯一要显示的是属性名称，无论它是否可选，它的可选“<<ID>>”构造型（下面将详细介绍），以及将其指定为派生属性的可选“/”。数据类型必须在幕后进行记录，但由于它会增加混乱，通常不会显示在用于演示的图表上。如果图表仅用于文档，则可以将其包含在图表中。“可见性”是属性在特定上下文中使用的特征，不属于结构图。

与实体类名一样，属性名称必须是所涉及特征的常用英文名称。通常，没有必要在属性名称中包含实体类名，但在某些公司，标准规定实体类名应插入通用属性之前，例如“人名”和“个人ID”。
关系和角色

两个实体类之间的关系由关于它们的两个断言组成。每个断言都是一个实体类相对于另一个的角色。这可以使用UML行来描述“关联”。从某种意义上说，UML关联等效于实体/关系关系，但
实体/关系模型在表示什么方面比面向对象的关联更受约束。具体来说，如下所述，每个关系都是关于业务性质的一对断言。这并不是简单地认识到两件事在某种程度上是相互关联的。

请注意，虽然在初步的实体/关系模型中，多对多关系是常见的，但当模型被解析为“概念”模型时，它们都已被解析为一对多关系。这一点很重要，因为两个实体类的交集通常包含重要的业务信息。简单地说，每个A都与很多B有关，每个B都与很多A有关，这并不能告诉你每次A与B有关。

在信息工程和实体/关系建模的Barker-Ellis表示法中，基数（在UML中称为“多重性”）由“鱼尾纹”（>-）符号的存在或不存在来表示。可选性（也称为“模态”）（在信息工程中）由圆（O）或垂直线（|）表示，或（在Barker-Ellis表示法中）由所涉及的关系线的一半是实线还是虚线表示。

在UML中，基数由字符表示：“..1”（意味着第一个实体类的实例可以与第二个类的不多于一个实例相关联）或“..*”（意味著第一个实体可以与第三个类的无限数量的实例相关联。）。关系的可选性可以是“0..”（意味着该关系是可选的）或“1..”（表示它是必需的）。

顺便说一句，与实体/关系建模不同，UML支持各种最大基数值。表达式可以是“1,4，>7”，这意味着该值必须恰好为1或4，或者大于7。

与传统的UML用法不同，每个关系都由两个普通的英语句子组成，尽管这个句子确实有严格的结构。在UML中，每个关系端都被称为一个“角色”。因此，图2中所示的关系以图形的形式显示了基数和可选性。明确地

• 每个
• <实体类1>
• 必须是…如果第二个实体类旁边有“1..”
• 或
• 可能是…如果第二个实体类旁边有“0..”
• <角色名称>
• 一个或多个…如果第二个实体类旁边有“..*”
• 或
• 正好一个…如果第二个实体类旁边有“..1”。

请注意，ORDER可能由一个或多个项目组成，通常表示为ORDER由零个、一个或更多项目组成，但在作者看来，后者更笨拙。对非技术性的听众说这句话听起来很技术。

还要注意，每个角色名称都是介词短语的形式，而不是动词。介词是表示一种关系的词性。（还记得“Grover words”吗？）动词代表动作，是面向过程的主题，而不是结构模型。

最常见的配置是“1..1”，表示“…必须…恰好是一个…”，而“0..*”表示“…可能是…一个或多个…”。如上所述，因为它非常常见，“1..1“通常缩写为“1”。这意味着，当读取这样的角色时，读取器必须将“1”解析为它的两个组件。

因此，在上图2中，从右到左的角色阅读产生了以下句子：

每个订单可能由一个或多个行项目组成。
从左到右依次为：

每个行项目必须是一个订单的一部分。（请注意，“1..1”本可以缩写为“1”。）
请注意，如果建模成功，这些关系语句对观众来说几乎是不言自明的。这些都是非常正常的、非技术性的句子。它们不仅听起来很正常，而且是强有力的句子，所以如果断言事实上是错误的，观众就不能简单地听之任之。”E不得不不同意他们的观点。

然而，也要注意，想出这样不言自明的角色名称是非常困难的。这样做意味着你必须真正了解这种关系的本质，并且你必须善于掌握英语（或你所用的任何语言）。不幸的是，许多建模师没有这样做的意愿或能力。最终的产品会受到影响。6

顺便说一句，这是一种与面向对象社区中采用的命名角色的方法截然不同的方法。在那里，角色通常是一个名词，描述第二个实体的内容。在许多情况下，这确实是关系回归的名词形式（“customer”而不是“customer-In”），但在许多情况中，它只是复制实体的名称。

图3显示了在面向对象规则下开发的模型。在这种情况下，主题区域起到了作为实体的包含主题区域的作用。实体反过来又扮演着作为主题区域的被包含实体的角色。这适用于实体/关系方法，即断言每个实体可能包含在一个或多个主题区域中，并且每个主题区域可能是一个或更多实体的容器。

图3：面向对象的角色7

一个约束

一些实体/关系符号能够描述关系的“排他性或”安排。例如，图4显示了断言：

每个行项目必须用于一种产品类型，或者用于一种服务。
跨越关系线的“弧”表示这一点。

图4：Barker-Ellis符号中的独占或

并不是所有的实体/关系符号都能显示这一点，但实际上UML可以。在UML中，它被称为“XOR约束”，如图5.8所示

图5:UML中的Exclusive或

本系列的第2部分将探讨子类型和唯一标识符的表示，以及一些UML特性，这些特性对于实体/关系模型来说是不必要的。

UML as a Data Modeling Notation, Part 2

UML as a Data Modeling Notation, Part 3

UML as a Data Modeling Notation, Part 4

脚注：

 

1. By “business at hand” is meant the subject being modeled, which might be a business or a microbiology lab or a Space Shuttle. The key is that we are interested in describing the “problem space”, not the “solution space.” For convenience in this article, the term will be “business” even though the subject matter could be other than commercial.
2. The UML readers will point out that “part of/composed of” is represented in UML by the additional symbol of a black (or open) diamond. In E/R models, however, the additional symbol is unnecessary because the roles are fully described by the English phrases. (More on this next month.)
3. More on the “octothorpe” when we discuss identifiers in Part 2 of this series.
4. If the acronym is widely accepted in the organization, and if everyone agrees as to what it means, and if to spell it out would be too long and clumsy, then it may be permissible to use it in an entity class name. Maybe.
5. Note to E/R modelers: “Visibility” refers to whether or not an attribute in a module of an object-oriented program can be referred to by other modules. Clearly this is not of interest in a requirements analysis model.
6. As an indication of how important it can be to use the right relationship name, the editors of the Hitchhiker’s Guide to the Universe were once “sued by the families of those who had died as a result of taking the entry on the planet Tral literally (it said ‘Ravenous Bugblatter Beasts often make a very good meal for visiting tourists’ instead of ‘Ravenous Bugblatter Beasts often make a very good meal of visiting tourists’).” —Douglas Adams, The Restaurant at the End of the Universe (New York: Pocket Books, 1980). P. 38.
7. Our thanks to Jim Logan of Model Driven Solutions for this model.
8. Note that the role name “for” as a property of LINE ITEM is duplicated.  This is not a logical problem, since “for a SERVICE” is not the same as “for a PRODUCT TYPE”. It can be a problem for UML, though, since the roles are “properties” of the entity class, but the other entity classes are not. In
   entity/relationship modeling, however, this is not an issue.  See the discussion of “Dealing with quirky UML concepts” next month.

References:

Barker, R. 1989. CASE*Method: Entity Relationship Modeling. (Wokingham, England: Addison Wesley).

Box, George E. P.; Norman R. Draper (1987). Empirical Model-Building and Response Surfaces, p. 424, Wiley. Available at: http://en.wikiquote.org/wiki/Special:BookSources/0471810339

Hay, D. 1999 “UML Misses the Boat,” East Coast Oracle Users’ Group: ECO 99 (Conference Proceedings / HTML File). Apr 1, 1999. Available at http://essentialstrategies.com/publications/objects/umleco.htm

Hay, D. 2003. Requirements Analysis: From Business Rules to Architecture (Upper Saddle River, NJ: Prentice Hall PTR).

Miller, G. A. 1956. “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information”, The Psychological Review, Vol. 63, No 2 (March, 1956). Available at http://www.musanim.com/miller1956/.

Martin, J., and James Odell. 1995. Object-Oriented Methods. (Englewood Cliffs, NJ: Prentice Hall).

Page-Jones, M. 2000. Fundamentals of Object-Oriented Design in UML. New York: Dorset House). Pp. 233-240.

Rumbaugh, J., Ivar Jacobson, Grady Booch. 1999. The Unified Modeling Language Reference Manual