用例:连接OWL与UML
标题: 连接 OWL 与 UML (牧羊人: 一问)
所有人
Jeff Young
背景与当前实践进展
用例发生在一个特定领域,因而理解它需要提供一些基础信息,本节是用来描述该领域。有可能的话,请将该领域的解释放在这里,介绍请尽可能简短。如果这种情景通过展示如何运用技术可以取代目前的实践是最好的说明,那么这部分可以用来描述目前的做法。通常,用例重要的原因,关键也在于如果用例没有实现将发生什么问题,或者问题的方法很难实现。
首要原理
关联数据的首要原理:
用URIs给事物命名:
如果认为命名是很容易的事情,那就太直接太天真了。如果名字不是由领域专家来专门管理,很容易变得没条理和/或者结合得意外紧密而使重用成为不可能或混乱。为了防止这种情况,名字应当在一个适应性强的概念模型里合理安排,这个概念模型基于用例,并以合理的元模型语言来管理。 Web本体语言(OWL)和统一建模语言(UML)是两种这样的语言,它们可在任何一个方向上进行的内容磋商,以管理和描述共同的领域模型。 OWL的表示法对机器消费最有效,而UML更适合表现人类消费。 UML的社区已经发展了本体定义元模型(ODM)来帮助填补两者之间的差距,但一直缺乏例子。这个用例是为了进一步缩小这个差距。
目标
两个简短的开头声明:(1)不涉及关联数据的方案可以实现什么;(2)我们如何使用关联数据技术实现这个目标。
说明如何用UML类图探索、重用和设计OWL。如果你避开了两种语言之间的警告和提示,所有关联数据资源都可以用UML类图表示,反之亦然。
目标观众
案例的主要观众。例如学者,广大市民,服务提供商,档案管理员,计算机程序...
用例情景
用例情景描述参与者与系统交互的故事。本节应把重点放在用户在这种情景下的需要上。不涉及技术和/或者关联数据的使用。
一个领域专家和建模专家讨论一个新的web用例。领域专家从建模专家那里围绕似乎必不可少的的术语/概念,带来了一个“电梯式演讲”。在建模者提出问题,并倾听其他概念和术语,以充实、澄清、重命名、规范化和抽象这个逻辑/概念模型概念以符合领域专家的理解之后,他与领域专家,用UML类图整理并分类这些术语。
建模专家探测每个术语的隐含意义以及便于利用的好词库。结果获得一组被分类并根据有关UML元模型:类、属性、关联、操作、实例等命名的事物的必不可少的名字。
在这个过程中,领域专家提及的信息,一些已经存在与关系数据库,而另一些存在于XML数据库中。该领域建模者跟踪这些架构并将它们添加到UML模型中。因为这些名称是较早的物理数据设计的用例模型的一部分,尽管如此,这个模型的部分,还是应该通过相同的概念建模单独维护处理,并映射到物理/概念模型。
使用此用例的关联数据的应用
本节描述关联数据技术如何用来支持上述用例。试图将焦点集中在抽象层的关联数据上,而不涉及具体应用和/或者词汇。提示:没有具体的图书馆领域
两个Web描述文档中有领域模型描述的例子:
UML (ODM): http://www.eclipse.org/m2m/atl/usecases/ODMImplementation/img/MuseumUML.png
RDF/XML (OWL DL): http://www.w3.org/2005/Incubator/lld/wiki/images/c/cc/MuseumUML.xml
已有的工作
本体定义元模型 OMG Ontology Definition Metamodel (ODM)
http://www.omg.org/spec/ODM/1.0/
博物馆的例子
http://www.eclipse.org/m2m/atl/usecases/ODMImplementation/
相关用例和意外的用途
本节描述使用关联数据的特别案例。也允许放些其他用例有希望的解决方案。本节也用于记录同一个系统在在这个用例情景中意外用途的表现。
图书馆关联数据的维度/主题
维度/主题用来组织用例。相同情况下,它们可能会帮助你识别当前没有被发现的新增内容,如果缺少适当的主题和/或者维度,请在此描述并用一个“*”号标识出来。
尚无条目
参考
"http://www.w3.org/2005/Incubator/lld/wiki/Use_Case_Bridging_OWL_and_UML"