如何获得更多有关LDAP的RFC 以及更多信息
要了解常见问题、与 LDAP 相关的 RFC 以及更多信息，请访 问 Mark Wahl 的 LDAP
网站
<淘宝热门商品：
来源：程序员网
|
|
摘要：本论文简要的探讨了XML和数据库之间的关系，同时列出一些可以使用数据库处理XML文档的软件。虽然这里不打算详尽地介绍这些软件，但是笔者希望它能够描述使用数据库处理XML文档中的主要部分。
内容：
目录
1.0 简介
2.0 XML是数据库吗?
3.0 为什么使用数据库?
4.0 数据和文档的对比
4.1 以数据为中心的文件
4.2 以文档为中心的文件
4.3 数据、文档和数据库
5.0 存储和检索数据
5.1 转移数据
5.2 将文档结构映射为数据库结构
5.2.1 模板驱动的映射
5.2.2 模型驱动的映射
5.2.2.1 表格模型
5.2.2.2 特定数据对象模型
5.3 数据类型、空值、字符集和其他
5.3.1 数据类型
5.3.2 二进制数据
5.3.3 空值
5.3.4 字符集
5.3.5 处理指令
5.3.6 存储标记
5.4 从数据库的结构生成DTD及其互逆过程
1.0 简介
本论文简要的探讨了XML和数据库之间的关系，同时列出一些可以使用数据库处理XML文档的软件。虽然这里不打算详尽地介绍这些软件，但是笔者希望它能够描述使用数据库处理XML文档中的主要部分。这里有点偏向与关系数据库，因为我的经验如此。
2.0 XML是数据库吗?
在开始讨论XML和数据库之前，我们需要回答一个萦绕在很多心头的问题: "XML是数据库吗?"在严格意义上将，如果"XML"是指XML文档时，答案是"否"。尽管XML文档包含了数据，但是如果没有其他的软件来处理这些数据，它对于数据库的意义和其他文本文件没有什么区别。
如果在更为宽泛一些的意义上将，当"XML是指XML文档以及所有相关的XML的工具和技术时，答案则是"是"。 之所以肯定是由于XML提供了许多数据库中所需要的部分:存储(XML文档),结构(DTD,
XML schema语言),查询语言(XQL, XML-QL, QUILT等), 编程接口(SAX, DOM),等等。不过...XML还缺少很多在真实的数据库中所必备的内容: 有效的存储、索引、安全、交易、数据完备性、多用户访问、触发、多文档查询等。
因此如果在数据量一般、用户较少、性能要求不高的环境下可以把XML当作数据库来使用；而在大多产品的环境中，要求有许多的用户使用、需要严格的数据完整性并且对性能有很高的要求，XML就不能胜任了。而且，考虑到象dBase和Access等数据库既便宜又十分易用，因此甚至在第一种情况下XML都很少有理由充当数据库的角色。
3.0 为什么使用数据库?
当在考虑使用XML和数据库时，第一个要问自己的问题应该是：为什么我需要使用数据库？你需要将原有的数据导出？你需要保存你的Web主页？你是要在一个电子商务应用中使用数据库，而且其中XML当做传输的数据格式？这些问题的答案都将直接影响到你对数据库和中间件(如果有的话)的选择。
例如，假设你在电子商务应用程序中使用XML来进行数据传输。这是很好的方案，因为你的数据具有高度规范的结构，而XML中的那些实体和编码对你而言并不重要了。毕竟样你关心的仅仅是数据而不在于这些数据如何在文档中进行物理的存储。如果你的应用程序相对比较简单的话，关系数据库和数据传输中间件将可以满足你的需求；如果应用程序庞大而且复杂，那么你就需要一个完全支持XML的开发环境了。
从另一方面来说，假设你有一个从零散的XML文件创建的网站。你不仅需要管理这个网站，你还要提供方法让用户可以查询其中的内容。这时你的文件将非常的不规范，而实体的使用对你来说将变得很重要，因为这些文件的结构是网站的根本。在这个例子中，你就需要某类"原生
XML"数据库可以执行版本化、跟踪实体的使用并且支持如XQL这样的查询语言。
4.0 数据和文档的对比
笔者认为，在选择数据库时，最重要的判断因素可能是你是利用数据库来保存数据还是保存文档。如果你想保存数据，你需要的数据库主要是面向数据存储(例如关系型数据库或者面向对象型数据库)以及在数据库和XML文档之间相互转换。从另一个角度来将，如果你想存储文档，你需要一个专门设计用来存储文件的内容管理系统。
虽然你可以自己把文件保存在关系数据库或面向对象数据库中，可是你常会发现你的工作是在重复内容管理系统的功能。类似的，虽然一个内容管理系统通常是建立在面向对象数据库或关系数据库之上，但要是把一个内容管理系统当做数据库来使用就可能非常的令人困绕。
你需要存储数据还是文档，答案常常取决于你的XML文档。原因是XML文件分为两大类：以数据为中心和以文档为中心。.
4.1 以数据为中心的文件
以数据为中心的文件的特点是结构相当规范、数据颗粒度好(也就是说，数据中最小的独立单元是PCDATA元素或者是属性)、很少或者没有混合内容。其中同层次元素和PCDATA的出现顺序并不重要。典型的例子是，XML文档包含了销售定单、飞行安排、餐馆菜单等等。数据为中心的文档常被用于机器的使用，这时XML可能是多余的---它仅仅是数据传输的手段而已。
例如，下面的销售定单的文档就是以数据为中心的：
ABC Industries
123 Main St.
Chicago
IL
60609
981215
Turkey wrench:
Stainless steel, one-piece construction,
lifetime guarantee.
9.95
10
Stuffing separator:
Aluminum, one-year guarantee.
13.27
5
在XML的世界中，许多内容丰富的文档实际上都是数据为中心的。我们以显示图书信息的Amazon.com网站为例。虽然这个页面是相当巨大的文本，但是这个文本的结构是高度规范的，其中许多的部分对任何的书本描述页面都是相同的，并且特点页面中的各部分的大小都是有限的。也就是说，该页面可以通过一个简单的、数据为中心的XML文档来建立，其中包含了从数据库中检索得到的文本信息以及一个XSL样式表。通常，目前任何通过在模板中填充数据库数据而动态构造HTML页面的网站都可以被上面介绍的用以数据为中心的XML文档和一个或者多个的XSL样式表方式替代。
例如，我们来看下面的租房(Lease)文档:
ABC Industries agrees to lease the property at123 Main St., Chicago, IL from
XYZ for a term of not less thanProperties
at a cost of TimeUnit="Months">18
. Currency="USD" TimeUnit="Months">1000
可以从下面的XML文档和简单的样式表得到:
ABC Industries 123 Main St., Chicago, IL
XYZ Properties
18
1000
4.2 以文档为中心的文件
以文档为中心的文档的特点是:结构不规范、数据颗粒度更大(即，最小的独立数据单元是包含有混合内容的元素或者就是整个XML文档)以及含有大量的混合内容。其中相同层次的元素和PCDATA出现顺序是非常重要的。典型的例子是书、电子邮件、广告以及大多数XHTML文档。以文档为中心的文档是用于人的使用。
例如，下面的产品描述文档就是以文档为中心：
Turkey Wrench
Full Fabrication Labs, Inc.
Like a monkey wrench, but not as big.
The turkey wrench, which comes in both right- and left-handed versions (skyhook optional), is made of the finest
stainless steel. The Readi-grip rubberized handle quickly adapts
to your hands, even in the greasiest situations. Adjustment is
possible through a variety of custom dials.
You can:
- Order your own turkey wrench
- Read more about wrenches
- Download the catalog
The turkey wrench costs just $19.99 and, if you order now, comes with a hand-crafted shrimp hammer as a
bonus gift.
4.3 数据、文档和数据库
在现实情况中，以数据为中心的文件和文档为中心的文件之间的区别并不是很严格。例如，一个以数据为中心的文件(如一张发票)，也有可能包含粗颗粒度、不规则的数据(如发票的描述部分)。而一个以文档为中心文件(如用户手册)也可能包含有良好颗粒度、规则的结构化数据(通常是元数据),例如作者和修订日期。除此之外，让你的文档具有以数据为中心或者以文档为中心的特点有助于你判断是关心数据还是文档，这也将决定你需要采用什么样的系统。
要存储或检索数据，你可以使用一个数据库(通常是关系型、面向对象型或者是层次型)和中间件(字带或者是采用第三方)，你也可以使用XML服务器(即创建分布式应用的平台，例如利用XML进行数据传输的电子商务应用)。要保存文档，你将需要一个内容管理系统或者是一致性的DOM实现系统。有关各类系统的探讨在5.0
"存储和检索数据" 小节和6.0 "
href="#storingretrievingdocs">存储和检索文档 " 小节。你也能够在
href="http://www.rpbourret.com/xml/XMLDatabaseProds.htm">
XML数据库产品 中了解详细的相关产品列表。
5.0 存储和检索数据
在以数据为中心的文档中的数据内容可能来自数据库(此时你想把数据导出为XML格式)，也可能是XML文档(此时你想把数据存储在数据库中)。前者的例子是在关系型数据库中存储的大量现有数据(或称遗产数据);后者的例子是将数据作为XML发布在Web中，而且你想要在你的数据库中进行存储以进行更多的处理。如此，根据你的需求，你可能需要将XML文档转移到数据库的软件，也可能需要从数据库转移到XML文档的软件，或者两者都支持。
5.1 转移数据
将数据存储在数据库中时，经常需要丢弃大量与文档有关的信息，例如文档名称和DTD，同时还有其物理结构，例如实体的定义和使用、属性值和同层元素的顺序、二进制数据的存储方式(是Base64编码、是未析实体或他方式)、字符数据段和其他的编码信息。类似的，当从数据库中检索数据时，生成的XML文档结果除了非预定义实体lt(<"),gt(">"), amp("&"), apos("’"), quot(""")不包含任何CDATA或实体引用。而同层元素和属性的出现顺序也常常就是从数据库中返回的数据的次序。
尽管一开始有些让你吃惊，但是这常常是合理的。例如，假设你需要用XML作为数据格式把一张销售从一个数据库中转移到另一个数据库中。在这种情况下，在XML文档中并不关心销售单的编号是保存在销售单的日期的前面还是后面，也不用关心是否将顾客的名称保存在字符数据(CDATA)段还是作为一个外部实体，或者直接当成一个PCDATA。最重要的在于相关的数据是从第一个数据库转移到第二个数据库中。这样，这个数据传输软件就需要考虑数据的层次结构(该结构将销售单的有关进行进行了分组)，而其他则不必过多考虑。
忽略文档信息以及其物理结构的后果之一是
文档的"逆反回归"的不一致效应，即将一个文档的数据存储在数据库中，然后根据这些数据重新组织成新的文档。而即便是根据标准格式处理，得到的也常常是和前面不同的文档。这是否可以接受要取决于你的需求，而且也将影响到你对数据库和数据传输中间件的选择。
5.2
从文档结构到数据库结构的映射
为了在XML和数据库之间传输数据，需要在文档结构和数据库结构之间进行相互的映射。这样的映射通常分为两大类: 模板驱动和模式驱动。
5.2.1 模板驱动的映射
在以模板驱动的映射中,没有预先定义文档结构和数据库结构之间的映射关系
，而是使用将命令语句内嵌入模板的方法，让数据传输中间件来处理该模板。例如，考虑下面的模板(注意该模板并不适用任何实际的产品)，在<SelectStmt>元素中内嵌了SELECT语句：
<?xml version="1.0"?><FlightInfo>
<Intro>The following flights have available seats:</Intro>
<SelectStmt>SELECT Airline, FltNumber, Depart, Arrive FROM Flights</SelectStmt>
<Conclude>We hope one of these meets your needs</Conclude>
</FlightInfo>
当数据传输中间件处理到该文档时,每个SELECT语句都将被各自的执行结果所替换，得到下面的XML格式:
<?xml version="1.0"?><FlightInfo>
<Intro>The following flights have available seats:</Intro>
<Flights>
<Row>
<Airline>ACME</Airline>
<FltNumber>123</FltNumber>
<Depart>Dec 12, 1998 13:43</Depart>
<Arrive>Dec 13, 1998 01:21</Arrive>
</Row>
...
</Flights>
<Conclude>We hope one of these meets your needs</Conclude>
</FlightInfo>
这种以模板驱动的映射可以相当的灵活。例如,有些产品可以允许你在任何结果集合中替换你想要的内容(包括在SELECT中使用参数),而不是象上面的例子中简单地格式化结果。另外它还支持使用编程来进行构造，例如循环和条件判断结构。还有一些还支持SELECT语句的参数化，例如通过HTTP来传递参数。
目前，以模板驱动的映射只支持从一个关系型数据库转换成XML文档的情况。
5.2.2 模型驱动的映射
在以模型驱动的映射中,利用XML文档结构对应的数据模型显式或隐式地将映射成数据库的结构，而且反之亦然。它的缺点是灵活性不够，但是却简单易用，这是因为它是基于具体的数据模型来进行映射的，通常能够为用户实现很多地转换工作。由于将数据从数据库转换成XML的结果依照了单个模型,
因此通常在这种方式下通常结合XSL来提供模板驱动的系统中所具有的灵活性。
在XML文档中的数据视图通常有两种模型:表格模型和特定数据对象模型。有时候也可能会出现其他的模型。例如，通过采用ID和IDREF属性，一个XML文档可以用来一个指定的图形。不过，很多现有的中间件并不支持这些模型。
5.2.2.1 表格模型
许多中间件软件包都采用表格模型在XML和关系型数据库之间进行转换。它把XML的模型看成是一个单独的表格或者是一系列的表格。也就是说，XML的文档的结构和下面的例子相类似，其中在单个表格的情况下，<database>并不出现:
<database><table>
<row>
<column1>...</column1>
<column2>...</column2>
...
</row>
...
</table>
...
</database>
其中的术语"table"可理解为单个的结果集(当从数据库向XML中转换数据时)，或者是一个单独的表格或可更新的视图(当从XML向数据库转换数据时)。如果数据需要来自多个结果集(当数据来自数据库中时)或者与仅仅表达成一系列表格的集合(当转换数据到数据库时)相比，XML的文档包含有更深层次的嵌套元素，那么类似的转换几乎是不可能的。
5.2.2.2 特定数据对象模型
XML文档中第二种普遍的数据模型是特定数据对象的树型结构。在该模型中,元素类型通常对应对象，而XML中的内容模型、属性和PCDATA则对应对象的属性。这种模型直接映射成面向对象的数据库和层次型数据库，当然借助于传统的对象-关系映射技术和SQL
3对象视图也可以映射成关系数据库。要注意的是，这种模型并不是文档对象模型(DOM)。DOM是对文档本身进行建模，而不是对文档中的数据。如
href="#writeyourown">6.1.2小节所述,DOM用来在关系型数据库的基础上建立内容管理系统。
例如，上面的销售定单文档就可以看作是由五个类所组成的树型结构。如下面的视图所示，包括Orders, SalesOrder, Customer,
Line和Part类:
Orders|
SalesOrder
/ | Customer Line Line
| |
Part Part
当把一个XML文档建模为一棵特定数据对象树时，就没有必要要求元素一定要对应于对象。例如，如果一个元素只包含PCDATA，如销售定单文档中的CustName元素，它可以当作一个属性进行处理，因此属性只包含单一的、标量型数值。类似的，有时将混合元素或元素内容模型化成属性也是非常有用的。一个现成的例子就是在销售定单文档中对Description元素的处理：尽管它在XHTML的格式中有混合内容，但是将Description元素看作单个的属性会更有用些，因为它的组成部分本身并没有什么意义。
5.3 数据类型、空值、字符集合和其它
本节将探讨一些有关来自数据库的XML文档的存储问题。通常，你决定不了你选择的中间件是如何解决这些问题的，但是你最好应该意识到这些问题的存在，因为这有助于你正确选择你的中间件。
5.3.1 数据类型
XML不支持任何有实际意义的数据类型。除了未析实体，所有XML文档中的数据都被当成文本来对待，即便它能够用其他的数据类型(如日期或者整数)来表示。通常，数据转换中间件将把XML文档中的文本转换成其它数据库中的数据类型，反之亦然。然而，特定的数据类型所识别的文本格式是有限制的，例如受到提供的JDBC
Driver所支持的数据类型的限制。在这些众多的数据类型中，日期类型通常会导致麻烦。不同国际地区的数字格式的差异也可能产生问题。
5.3.2 二进制数据
通常有两种方法将二进制数据保存到XML文档中的：未析实体和Base64编码处理(一种MIME编码方法，可以将二进制数据映射成US-ASCII的子集)。
对于关系型数据库，这两种方法都可能存在问题，因为从数据库中保存和检索二进制数据的规则非常的严格，这样对会导致中间件出现问题。
另外，并没有一种标准的符号用来说明一个XML文档中的元素包含有Base64编码数据，从而使得中间件可能根本就不能够识别这种编码。最后，在存储数据到数据库时，可能会忽略与未析实体或Base64编码元素相关的符号。所以，如果对你而言二进制数据非常重要的话，请务必要确认你的中间件是否支持二进制数据。
5.3.3 空值
在数据库世界中，空值(null)数据意味着数据不存在值。但是这与一个值为0的数字或长度为0的字符串有很大的区别。例如，假设你的数据来自一个气象站，
如果气象站的温度计出了毛病读不出温度值，那么你的数据库中将存储一个null值而不是一个0。显然，值为0完全是另外一回事了
。
XML中空值概念的支持可以通过设置可选的元素类型或属性来实现。如果元素类型或属性值为null，XML只要在文档不包含该元素或者属性就可以了。但是对数据库而言，空的元素或包含0长度字符串的属性并不是空值null：它们的值为长度为0的字符串。
当在XML文档和数据库结构之间相互映射过程中，你必须特别注意那些可选的元素类型或属性是否对应于数据库中的空值项。如果不这么做的话，很可能出现插入错误(当将数据转换到数据库中时)或者无效文档错误(当将数据从数据库读出时)。
因为同样要用符号空值，XML中相对与数据库而言更为灵活。具体来讲，许多XML用户很可能包含空字符串的空元素或属性是空值。这个时候你必须考虑如何选择合适的中间件来解决这个问题。一些中间件可以让用户选择在XML文档中定义用什么来组成空值。
5.3.4 字符集
根据定义，除了一些控制字符，XML文档能够包含任何的Unicode字符。但是不幸的是，许多数据库都限制或则不支持Unicode，而且需要一些特殊的配置才能够处理非ASCII编码的字符数据。如果你的数据包含了非ASCII字符，那么务必要核实你的数据库和中间件是否能够处理这些字符。
5.3.5 处理指令
处理指令并不属于XML文档中的“数据”部分，因此目前许多中间件可能不能正常的处理。问题是，尤其是在将XML文档结构严格映射成数据库结构时，处理指令通常是很难处理的，因为它们可以虚拟地出现在文档的任何位置。因此，中间件就很难判断将它们保存到什么位置以及在什么时候检索读取出来。如果处理指令和文档的循环回复("round-tripping")对你而言是非常重要的话，就务必检查你的中间件是如解决这个问题的。
5.3.6 存储标记
在
href="#markup">4
href="#markup">.2.2
小节中提到，有时候将包含元素或者混合内容的元素不作进一步的解析而直接保存到数据库中是非常有用的。最常见的方法是简单的把这个标记本身直接保存到数据库中。不幸的是，当从数据库中检索数据时将产生问题：不可能判断数据库中的标记到底是真的标记还是代表了标记字符的实体，如由lt和gt转义的字符。
例如，下面的description元素:
<description><b>Confusing example:</b> <foo/>
</description>
在数据库中存储为:
<b>Confusing example:</b> <foo/>
这时数据库就不能判断<b>和<foo>是标记还是文本。有几种可能的解决方法，如以一定的方式来标志标记或者对非标记的标记字符使用实体。但是这时你要格外注意这样的方式是否和使用这些的数据的其它应用兼容。例如，如果你想查询数据库中的小于号("<")和
lt实体("<")时就要特别留心。
5.4 从数据库的结构生成DTD及其互逆过程
在XML文档和数据库之间转换数据时，一个普遍问题是：如何从数据库的结构(Schema)生成XML的DTD,如果从XML的DTD产生数据库的结构。简而言之，这是非常直接的操作，但是产生的结果通常离许多用户的期望值还有一些距离。
(还要注意这通常是一次性操作，而大多数应用，尤其是所有的垂直性应用都结合了已知的DTD和关系型Schema的集合。显而易见的特例是在关系数据库中存储随机XML文档或者将关系型数据发布为XML文档的工具;而在后面的情况中，DTD的作用并不明显。)
对于元素类型中每个有单一数值的属性和只包含有PCDATA内容的子元素类型在该ta
ble中新建立一列（字段）。如果子元素类型或则属性是可选的，让该字段允许为空。
对于每个有多值的属性或则多仅含有PCDATA内容的子元素类型，再建立一个分开的
table来保存他们的值，通过它们的父表的主关键字连接到父表。
对于每个子元素，这些子元素本身还有元素或则混合内容，使用父表中的关键字将
父元素表连接到子元素表中。
而下面则是一个从关系数据库的结构生成XML文档的过程（简化过的）：
对每个table，新建一个元素。
对表中的每列，建立一个属性或则只含PCDATA的子元素
对每个包含有在主键/外键关键字关系中主键值的列，新建一个子元素。
例如，下面的过程(经简化）说明了如何从一个DTD生成一个关系型结构:
- 对于每种包含元素或者混合内容的元素类型，新建一个表格和一个主键字段。
- 对于每个包含混合内容的元素类型，创建一个单独的表格，其中存放未析数据，通过父元素主键链接到父表格。
- 对于此元素类型的每个单值属性和只包含未析数据内容、只出现一次的子元素，在该表格中创建一个字段。如果元素类型或者属性是可选的，可以让设置该字段为空值。
- 对于每个多值属性和多次出现的子元素，创建一个单独的表格来存储数值，并且通过父元素主键链接到父表格。
- 对每个有元素或者混合内容的子元素，通过父元素主键将父元素表格和子元素表格相连接。
下面的过程(经简化)说明了如何从一个关系型的结构生成一个DTD:
- 对于每个表格，新建一个元素；
- 对于表格中的每个字段，新建一个属性或者是只包含未析数据的子元素；
- 对于每个表格字段中提供主键的主键/外键的关系都新建一个子元素。
不幸的是，这些过程还存在着一些缺陷。例如，DTD中没有方法预先准确地规定数据类型或者字段长度。
因为任何的预先定义(例如通过读取一个示例文档)在读取其它“类型”的文档或者其他文档中包含有超过字长内容的文档时就会产生错误。(长久之策是使用XML schema文档的数据类型。)简单来说，当从一关系型结构生成DTD时，是没有办法预先判断子元素“应该”出现的顺序或者字段(如数据库内部的行标识)是否该进行完全转换。
在以上两种情况中都可能产生命名的冲突。
尽管有这样那样的缺陷，但是这些方法仍然能够很好地奠定在关系型结构和DTD之间互相转换的起点。
<淘宝热门商品：
|
|
图1：角色和用例。分析中的第一步就是指出系统能被用来做什么，谁将去使用它。它们分别就是用例和角色。所有的用例必须始于角色，而且有些用例也结束于角色。角色是位于你所工作的系统外部的人或其他系统。一台打印机或一个数据库都可能是一个角色。本系统有两个角色：借阅者和图书管理员。通过与用户或客户的讨论，可以将每一个用例用文字进行说明。
2．2域分析（Domain Analysis）
系统分析也详细地列出了域（系统中的关键类）。为了导出一个域分析，可以阅读规范文档（specifications）和用例，查找哪一些概念应该被系统处理。或者组织一个集体讨论，在用户及领域专家共同的参与下指出系统中必须处理的关键概念，以及它们之间的关系。
图书馆系统中的域类如下：borrowerinformation（如此命名是为了与用例图中的角色borrower区分开来），title，book title, magazine title, item, reservation和loan。这些类以及它们之间的关系记录在类图文档中，如图2所示。域类定义为Business object版型，Business object版型是一个用户自定义的版型，指定该类的对象是关键域的一部分，并且应该在系统中持久存储。
其中有些类有UML状态图，用来显示这些类的对象可能具有的不同状态，以及触发他们的状态发生改变的事件。该例子中有状态图的类是item 和title类。
用例lend item（借阅者没有预定的情况）的顺序图显示在图3中。所有用例的顺序图都可从在线模型中查到。
图2：域类结构。域分析详细说明了系统中的关键类。对每一个对象而言，如果它调用了其他对象的方法，那么在他们之间就用一条直线连结起来，以显示他们之间的关系。每一个代表类的四边形被分成了三部分，最顶层包括类的名称，中间一层是类的属性，最底层是类的方法。类之间的直线是关联，用来指出一个对象调用另一个对象的方法。如果再仔细看，将会发现在Loan和Item之间的关联关系中靠近Loan的一端有“0..1”,这代表关联的重数。重数“0..1表示Item可以感知0个到1个loan。其他可能出现的重数还有：“0..*”表示0或多；“1”表示就是1；“0”表示就是0，“1..*”表示1或多。
当对顺序图建模时，必须提供窗体和对话框作为人机交互的界面。在本分析当中，只要知道借书、预定和还
书需要窗体就可以了。在此，详细的界面不必考虑。为了把系统中的窗体类和域类分开，所有的窗体类组织在一起放在GUI Package包中。域类组织在一起放在Business Package包中。
图3：Lend item场景的顺序图。场景是从头到尾实现一个用例的一次特定的过程。场景总是始于角色，而角色是属于系统外部的。场景描绘了从所有角色的观点出发，完成一次系统动作的完整过程。UML在用顺序图来图示场景。本用例图显示了在借阅者没有预定图书的情况下的Lend用例。横在图的顶部的是参与交互的对象。自上而下表示时间的流逝。首先，图书管理员尝试去查找标题。标有“Lending Window”的是用户界面，在分析阶段作为一个粗略的对象。横在顺序图中的每一个箭头都是一次方法的调用，箭头的首端是调用的对象，箭头的末端是被调用的对象。
3．设计（Design）
设计阶段对分析模型进行扩展并将模型进一步细化，并考虑技术细节和限制条件。设计的目的是指定一个可行的解决方案，以便能很容易地转变成为编程代码。
设计可以分成两个阶段：
体系结构设计阶段（Architecture Design）。这是一个从较高层次的进行的设计，用来定义包（子系统），描述包之间的依赖性及通信机制。很自然，目的是要设计一个清晰简单的体系结构，有很少的依赖性，而且尽可能避免双向依赖。详细设计阶段（Detailed Design）。在此阶段，所有的类都详尽地进行描述，给编写代码的程序员一个清晰的规范说明。UML中的动态模型用来说明类的对象如何在特定的情况下做出相应的表现。
3．1体系结构设计
一个良好的体系结构设计是一个可扩展的和可改变的系统的基础。包可能关注特定的功能领域或关注特定的技术领域。把应用程序逻辑（域类）和技术逻辑分开是至关重要的，这样不管哪一部分的改变都不会影响其他的部分。
本案例的包或叫子系统如下：
User-Interface Package包。该包中的类基于Java AWT包，java AWT是一个用来书写用户界面应用程序的Java的标准库。该包和Business-objects Package包协作。Business-objects Package包包含那些实际存储数据的类。UI包调用Business 对象的操作，对他们进行取出或插入数据操作。
Business-object Package。该包包括域类，这些域类（如borrowerinformation，title，item，loan等）来自于分析模型。设计阶段完整地定义了这些类的操作，并增加了一些其他细节来支持持续存储。Business-object包与Database Package进行协作。所有的Business-object类必须继承Database Package中的persistent类。
Database Package。Database Package向Business-object包中的类提供服务，以便他们能够持续地存储。在当前版本中，persistent类将把它的子类的对象存储到文件系统的文件中。
图4：图书馆应用程序体系结构设计总览。本类图显示了应用程序包以及它们之间的依赖性。Database包提供了persistence类。Utility包提供了Object ID类。Business-Object包包含了域类（详细情况参见图5）最后，UI包（在本例中它是基于标准Jaa AWT库）调用business对象中的操作来实现对他们的数据存取操作。，
3．2详细设计
细节设计描述了新的技术性的类，如User-Interface和Database 包中的类，并且丰富了分析阶段所形成的Business-Object类。类图、状态图和动态图用的还是分析阶段所形成的图，但对他们定义的更加详细，具有了更高的技术水平。在分析阶段对用例进行的文字性描述在此用来证明用例在设计阶段也能被处理。顺序图就是用来说明用例如何在系统中被实现的。
Database Package。应用程序必须有持续存储的对象。因此，必须增加数据层来提供这样的服务。为简单起见，我们将对象以文件的形式保存在磁盘上。存储的细节被应用程序隐藏起来，只需调用诸如store（）， update（），delete（）和find（）这样的公共操作即可。这些都是persistent类的一部分，所有需要持续对象的类必须继承它。
对类进行持续处理的一个重要因子就是ObjId类。它的对象用来引用系统中的任何持续对象（不管这个对象是在磁盘上还是已经被读进了应用程序之中）。ObjId是Object Identity的简写，它是一个广为应用的技术，用来有效地处理应用程序中的对象引用。通过使用object identifiers，一个对象ID能被传递到普通的persistent.getobject（）操作中，进而该对象将被从持续的存储体中取出或存储。通常情况下，这些都是通过每个持续类的一个getobject操作完成的。当然，持续类同时也作一些检查或格式转换的操作。一个对象标识符也能作为一个参数很容易地在两个操作之间传递（例如，一个查找特定对象的查询窗口可以将它的查询结果通过object id传递给另一个窗口 ）。
ObjId是一个系统中所有的包（User Interface , Business Object和Database）都能使用的通用类，所以在设计阶段它被放置在Utility包中，而不是放在Database包中。
当前对persistent类的实现还能改进。为此，定义persistent类的接口，方便持续存储的改变。一些备选的方案可能是：将对象存储在一个关系数据库中或存储在面向对象的数据库中，或使用Java 1.1所支持的持续对象来存储他们。
Business-Object Package。设计阶段的Business-Object包基于相应的分析阶段的放置域类的包。类和类之间的关系以及他们的行为继续保留，只是被描述的更为详细，包括他们的关系和行为如何被实现。
分析模型中的一些操作中被翻译成设计模型的操作，另一些改了名字。这是很正常的事，因为分析阶段得到的是每一个类的草图，而设计阶段是对系统的详细描述。因此，设计模型的操作必须有设计良好的特征值和返回值（由于空间限制，图5没有显示，但他们在在线模型中都有）。注意以下所列的设计和分析阶段的变化：
1. 系统的当前版本不要求检查书目是否按时归还，也不要求处理预定的次序。因此没有在loan 和reservation类中设置日期属性。
2. 除了最长借阅期外，对杂志和书标题的处理方式是一样的。因此分析阶段的子类magazine title和book title被认为在设计阶段是不必要的，而是在title类中增加type属性来指出该标题引用的是一本书还是一本杂志。在面向对象的设计中不存在设计不能简化分析的说法。
如果认为有必要的话，在将来的版本中这些简化都可以很容易地被取消。
分析阶段的状态图也在设计阶段细化了。状态图显示了如何表示状态及如何在系统中处理状态。设计阶段的title 类的状态图如图6所示。其他的对象可以通过调用如图所示的操作addreservation（）和removereservation（）来改变title对象的状态。
User-Interface Package。User-Interface Package位于其他包的“上面”。在系统中它为用户提供输出信息和服务。正如上面曾经提到的，该包是基于标准Java AWT（abstract windows toolkit）类的。
设计模型中的动态模型放置在GUI包中，因为所有和用户的交互都从用户界面开始。在此声明，顺序图用来显示动态模型。用例在设计模型中的实现通过顺序图被详细地显示出来，包括类中的实际操作。
顺序图由一系列的交互构成。在实现阶段（编码），考虑到具体情况，可能会有更多的交互。图7显示了add title用例的顺序图。实际的操作和特征值从在线模型代码中可以看到。
图5：商业对象设计（Business-Object design）。本图描述了在Business-Object包中的不同类的设计。设计包括定型模型，更完全地定制界面，给属性选择数据类型等等。
6：Title的状态图。Title具有预定和非预定状态，在设计中，通过称为“reservations”的矢量来实现。
7：Add Title的顺序图。本图中所涉及到的用户界面问题的详细情况已经超出了本文的讨论范围。
协作图可以作为顺序图的替代，如图8所示：
图8：Add Title的协作图。本图中涉及到的用户界面问题的详细情况已经超出了本文讨论的范围
3．3 用户界面 设计（User-lnterface Design）
设计阶段的一个特定的活动是创建用户界面。
图书馆系统的用户界面基于用例，分为以下几部分，每一部分都在主窗体菜单上给出一个单独的菜单项。
Functions：实现系统基本功能的窗体，通过它可以实现借阅、归还和对图书的预定。
Information：查看系统信息的窗体，收集了借阅者和图书的信息。
Maintenance：维护系统的窗体，添加、修改和删除标题、借阅者和书目。
图9显示了一个User-Interface Package中类图的例子。其中包含了典型的AWT事件句柄。按钮（button）、标签（label）和编辑（edit）等的属性没有显示。
典型地，每一个窗体都给出了系统的一个服务，并且映射一个最初的用例（尽管并非所有的用户界面都必须从用例中映射）。创建成功的用户界面已经超出了本文所讨论的范围。在此邀请读者来考虑用symantec visual cafe 环境开发的本应用程序的UI代码（已经放在网上）。
图9：功能类图模型。功能菜单中的用户界面类一般都有1对1的关联关系，表示需要建立关联的窗口类，或者需要访问关联的商业对象类。
4．实现（Implementation）
在构造或称实现阶段进行程序编写。该应用程序要求能运行在几个不同的处理器和不同的操作系统上，因此选择Java来实现系统。Java可以轻松地将逻辑类映射为代码组件，因为在类和Java代码文件之间有1对1的映射。
图10：组件图显示了依赖性。源代码组件实现了域类，他们之间的关联显示为双向依赖性
图10显示，设计模型的组件视图简单地将逻辑视图中的类映射为组件视图中的组件。每个逻辑视图包含了一个指向逻辑视图中类的连接，因此可以很容易地在不同的视图之间导航（即便象本例只是简单地使用了文件名）。由于依赖性可以从逻辑视图的类图中得到，因此组件图中没有显示组件之间的依赖性。
编写代码时，从下面的设计模型的图中取出规范说明：
1．类规范：每一个类的规范详细地显示了必要的属性和操作。
2．类图：类图由类构成，显示了类的结构以及类之间的关系。
3．状态图：类的状态图显示了类可能具有的状态以及需要处理的状态转移（以及触发转移的操作）。
4．动态图（顺序图、协作图和活动图）：涉及到类的对象，显示了类中的特定方法如何实现，或对象之间如何使用其它类的对象进行交互。
5．用例图和规范：当开发者需要了解更多的关于系统如何被使用的信息时（当开发者感到他或她已经迷失在一片细节中），他们显示了系统被使用的结果。
很自然，设计中的某些缺陷可以在编码阶段发现。可能需要一些新的操作或修改某些操作，这意味着开发者必须改变设计模型。这在所有的工程中都会发生。重要的是将设计模型和代码同步，以便使模型能够成为系统的最终文档。
这里给出了loan 类和部分titleframe类的Java代码。整个应用程序的Java代码可以从网上查到。当学习这些代码时，注意结合UML模型，考虑UML结构是如何被转变为代码的。注意以下几点：
1．Java包规范是与类所属的逻辑视图或组件视图中相应的包等值的代码。
2．私有属性对应于模型中指定的属性；并且，很自然Java 方法对应于模型中的操作。
3．ObjId类（对象标识符）被调用来实现关联。也就是说，关联通常和类一起保存（因为ObjId类是持续的）。
程序清单1的代码示例来自于loan类，loan类是一个Business-Object类，用来存放借阅信息。由于该类主要是信息的存放处，因此程序的实现是直接的，代码也简单。大多数的功能继承了Database 包中的Persistent类。该类的唯一属性是对象标识符，将item和borrowerinformation类关联起来。并且这些关联属性也在Write（）和Read（）操作中被保存。
试着在Add Title顺序图（图7）上下文中检验一下程序清单2中显示的Addbutton_Clicked（）操作。结合顺序图阅读代码，可以看出：它就是另一个对顺序图所表达的协作关系的更为详细的描述。
所有设计模型中的顺序图的编码都包含在源代码当中（操作名和类名显示在顺序图中）
5．测试和部署(Test and Deployment)
编码结束后，UML的使用还没有停止。例如，可以检验用例能否在已完成的应用程序中得到很好的支持。对于系统的部署来说，利用模型和本文可以做一份得心应手的文档。
6．总结
本学习案例的不同部分由一组人分别来设计完成。他们以做实际工程的方式努力完成该工作。尽管不同的阶段和活动似乎是独立的，而且以严格的顺序来管理，但在实际工作中仍然有很多反复。设计中的经验和教训反馈到分析模型，实现阶段所发现的新情况在设计模型中更改或更新。这就是建立面向对象系统的一般方法。
本文摘录自UML Toolkit，New York：Wiley & Sons，1998. Hans-Erik Erikkson是一个有名的C++和OO技术方面的作者。Magnus Penker是Astrakan培训副主席，Astrankan是一个瑞典专攻OO建模和设计的公司。
原文链接：http://www.umlchina.com/Indepth/DesignJava.htm
模型及源码：http://www.umlchina.com/zippdf/libraryjava.zip
附：主要术语中英文对照
actor：角色
use case：用例
domain：域
domain analysis：域分析
specification：规范文档
sequence diagram：顺序图
collaboration diagram：协作图
component diagram：组件图
state diagram：状态图
dependency：依赖性
attribute：属性
method：方法
operation：操作
association：关联
multiplicity：重数
class：类
object：对象
package：包
implementation：实现
deployment：部署
