Benoit 开始撰写有关 UML 和 XML 模式开发
系列新文章
这是其中第篇讨论了使用 UML 对 XML 建模动机
他还介绍了 XML Metadata Interchange(XML 元数据交换XMI)并简要描述了从 UML 模型自动派生 XML 模式策略请您在本文讨论论坛上和作者及其他读者交流您想法(您也可以单击本文顶部或底部讨论来访问论坛)随着 XML 成为主流
人们越来越关心 XML 应用
设计更具体地说许多组织希望把 XML 应用设计和他们其他应用设计结合起来采用种通用思路方法——或者至少组通用工具——是值得考虑方向就 XML 而言
设计活动主要围绕着数据建模事实上
XML 是种标记语言仅仅涉及到信息组织——这点和其他语言是区别比如 Java 同时处理数据建模(类继承)和数据操作(思路方法)使用 XML 专栏新
系列文章将探讨使用 UML 建模工具设计 XML 应用如 IBM Rational Rose 和 XSLT这是其中第篇在这篇介绍性文章我将讨论数据建模基本原理并介绍在后面 3篇文章中将用到技术数据建模
简明牛津词典(牛津大学出版社
2001)有关名词“model”至少有 7 种以上定义对于本专栏系列文章而言下面定义最合适:“系统及其他简化(通常是数学化)描述以便帮助计算和预测”这个定义中有 3个关键词:简化、描述和帮助按照这个定义
模型是有关系统描述这论断很重要模型不是系统本身而是系统形式化表示具体到 XML 而言系统由按照特定词汇表编码文档组成这
定义第 2方面说模型是种简化表示它不像所建模系统那么复杂或者丰富许多系统都设计用于解决复杂问题因此天生就是复杂比如看看 DocBook 这类复杂词汇表:它设计用于出版技术数据和文档(其中 Linux 文档就是用 DocNook 出版)技术书籍和文档很复杂 DOcBook 也很复杂(请参阅参考资料)此外
人们能够同时处理信息量是有限多数人在解决个复杂问题时都喜欢(或者需要)把它分解成更小、更容易管理问题建立模型就是为了满足这种需要模型通过只公开系统某些特定方面来简化复杂系统定义中最后
个关键词是帮助模型不是凭空建立而是服务于非常具体目标它只是更有效地实现特定目标种工具目标从来不是建立模型而是处理个系统目标
操作特性和前面所述简化密切相关简化意味着要选择系统中需要包括那些成分和应该抛开那些成分选择受模型目标所控制比如试图帮助计算和预测简化和建模
无论如何强调模型是实际系统
简化都不过分同样除非将其分解成更小、更简单成分要解决个复杂系统是不可能在实战中个模型常常是不够复杂系统可以用从简单到复杂多个模型表示建模
过程可以从传奇般餐巾纸(块白板或者裁好沓纸是很好替代品)上系统草图开始第个模型通常很粗略忽略了系统多数方面只有设计者认为重要少数方面可能这些方面特别复杂或者是系统关键特征这个粗略
模型将被细化成更加精细、更加复杂个或多个模型每次迭代都从实际系统中引入更多成分直到所有相关方面都引入到模型中最终您将达到数据模型实现阶段并定义系统可以管理所有方面对于 XML 而言实现将
个 XML 模式其他选择包括 DTD、 RELAX NG 或者 WSDL(请参阅参考资料)尽管这些实现的间存在技术上差异但在本系列文章中我将把它们看作是 XML 模式变体 业内对模型和 XML 模式的间
关系有两种区别观点些作者在设计模型和 XML 模式的间划了条清晰界线设计模型通常是 UML 模型或实体-关系模型被认为是抽象而 XML 模式则被认为包含大量实现细节这种区别有助于清晰地划分建模活动和实现活动建模通常由业务分析人员完成而实现则是技术人员职责这种工作划分模仿了典型应用开发中分析人员和开发人员的间分工虽然我认为这种划分对编程而言是合理
但不能保证也适用于 XML 建模——这使我倾向于对这种关系第 2种观点XML 模式是文档模型您将在下篇文章中看到它和良好 UML 模型在复杂程度上并没有显著区别毫无疑问XML 模式包含大量技术信息但是描述同样多技术信息 UML 模型也并不少见因此我倾向于把 XML 模式看作是从高层模型到底层模型模型连续统体中部分如果安装了辅助建模工具——我将在本系列
其他文章中介绍——把模式仅仅看作是另种模型尤其合适简化和图形
建模中使用
最有效简化方式是图形和长串复杂指令相比人们发现大脑更容易处理图形多数建模思路方法都建立在可视化语言基础上如 UML、实体-关系图或者流程图具体到 XML 模式
用什么组成最佳可视化语言存在两种区别观点种思路方法是采用 XML 专用语言另种则是用更般建模语言XML Spy 或 TurboXML(请参阅参考资料)这类产品使用自定义图形树表示处理 XML 模式种可视化呈现可能类似于图 1:图 1. 可视化 XML 结构
![](\"/A-A-B/Image/2005/09/05/uml-xmi-1-1.g<img)
\" width=\"320\" alt=\"\"/>为此也可以采用标准
建模语言如 UML图 2 是类似于图 1 UML 模型:图 2. 建模 XML
UML![](\"/A-A-B/Image/2005/09/05/uml-xmi-1-2.g<img)
\" width=\"130\" alt=\"\"/>每种思路方法各有自己
优缺点XML 专用符号完全和 XML 结构匹配很容易标志 XML 顺序、XML 选择、元素和属性等等也可以用简单、自然方式规定所有技术信息直到最近许多 XML 应用设计者还推荐使用这种思路方法它简单而有效付出
代价是建模以及工具常常不能和其他开发工作很好地结合虽然这种思路方法仍然适用于小型 XML 项目但是没有很好伸缩性这种思路方法也很难用于结合了 XML、Java、Web 服务和 SQL 大型项目团队(Team)中其他人可能使用是 UML有两个原因使得 UML 最适合于中型和大型
项目:
UML 应用于 Java、C
、Python、PHP、SQL、Web 服务以及差不多任何其他部属技术它统性减少了培训需要(种语言适用于每个人)而且更容易在团队(Team)中共享设计UML 图可以根据需要显示更多
或较少信息因此可以使用同个工具准备多种复杂层次模型UML 主要
不利的处在于在处理建模底层方面时不很友好比如在树中对组元素排序很容易但在 UML 中就需要很多窍门技巧UML 和 XML
我计划在以后几篇文章中详细讨论这个话题
现在只要指出在 XML 模式和 UML 模型的间可以建立多种映射就足够了UML 支持多种图包括用例图、包图、顺序图和活动图这里最适合
是类图类图表示面向对象数据模型图 3 是表示 person
非常简单 UML 模型它包括两个类个代表 person 基本数据(“person”)另个代表 person “address(地址)”矩形是表示类符号被分成 3个部分:类名、属性以及思路方法我们要建模是数据而不是行为可以忽略思路方法部分图 3. person
UML 模型![](\"/A-A-B/Image/2005/09/05/uml-xmi-1-3.g<img)
\" alt=\"\"/>类的间
关系用联系表示在模型中联系用条直线表示直线可以使用连接符修饰以进行区分比如图 3 中实心菱形表示这里是组合关系——换句话说address 类例子只能存在于 person 类上下文中注意
把 UML 结构映射到 XML 可以有多种区别选择其中 UML 属性就是个很好例子在 UML 中属性是附加到类中字段在 Java 语言中只有种合理映射方式:属性变成个类变量相反在 XML 中属性可以映射成子元素或者真正 XML 属性我将在以后文章中继续讨论这个话题模式派生
可以尝试区别
思路方法绘制 UML 模型:可以将其画在纸上或白板上
可以使用 SmartDraw 或 Omnigraffle(请参阅参考资料)这样
向量绘图工具 可以使用建模工具
如 IBM Rational Rose(请参阅参考资料) 除了最简单
模型的外您可能更愿意使用建模工具初看起来建模工具只不过是美化绘图工具但实际上提供了更多功能建模工具能够理解模型因而可以为设计人员提供大量帮助比如在向图中增加类时它可以自动地画出这些关系自动派生
如前所述
我认为 XML 模式只不过是种详细模型特殊呈现因此从 UML 模型自动派生 XML 模式是很重要看着 UML 模型
将其编码成 XML 模式非常耗时而且容易出错您可能忽略些元素或属性也很容易把关系搞错所幸是只要在 UML 结构和 XML 模式语句间建立对映射这个过程很容易自动化您可以找到用于从模型自动派生模式
许多工具其中包括:Eclipse 建模框架(EMF)
原来称为 IBM XMI Toolkit(请参阅参考资料)EMF 包括个代码生成器从 UML 模型派生 XML 模式 IBM Rational Rose
它所含脚本语言 RoseScript 可以处理 UML 模型因而能将其保存为 XML 模式 Velocity
来自 Apache Jakarta 个项目是用于从 UML 模型生成代码模板引擎 hyperModel 是专门用于从 UML 生成
[1][2]下
页 
最新评论