SEKE 2012 Proceedings - Knowledge Systems Institute

The tool’s ability to deal with SWRL rules based on an UML
profile based approach as discussed in literature [8] has been
successfully demonstrated in [4][p.7,8].
D. A Word about XML Metadata Interchange
Evaluation showed that the transformation proccess heavily
depends on the format of the provided XMI file. Although
most of the leading UML modeling tool vendors support XMI,
their formats are highly incompatible and implementations
often have a lack of quality. Often export and import of simple
diagrams within the same modeling tool is doomed to fail.
One of the reasons for this is that XMI attempts to solve
a technical problem far more difficult than exchanging UML
models; it attempts to provide a mechanism for facilitating the
exchange of any language defined by the OMG’s MetaObject
Facility (MOF). Furthermore, the UML 2.* Diagram Interchange
specification lacks sufficient detail to facilitate reliable
interchange of UML 2.* notations between modeling tools.
Since UML is a visual modeling language, this shortcoming
is a show-stopper for many modelers who don’t want to redraw
their diagrams 10 .
There are several reasons why transformation of VP XMI
2.1 format into valid OWL fails using existing UML2OWL
tools. First of all, VP takes use of different XML namespaces
to distinguish between different types of elements (i.e. classes,
associations, packages) which do not have been considered by
most of the transformation tools. Secondly, the XML structure
is nested and data for particular elements have to be grabbed
using cross references. This turned out to be fragile according
to XSLT scripts implementations and tools who try to tackle a
joint solution for all XMI dialects. Furthermore, the structure
of the resulting VP XMI file depends on the state of the
UML editor view during the export process (e.g. if a particular
package/part of the diagram is selected, the XML hierarchy
changes). Finally there are even incompatibilities between
different versions of VP (i.e. between VP UML 7.2 and VP
UML 8.2).
The conclusion is that an UML2OWL transformation process
always should be tailored to a specific vendor’s UML
solution. UML2OWL tool developers are required to specify
vendor, product name and version of the UML editor they
support as well as XMI versions and instructions, how to
export that XMI version from the respective UML editor.
Furthermore they must define, which UML elements their
tool supports (and which not) and provide adequate reference
models, including test cases (automated?) and documentation.
III. UMLTUOWL TRANSFORMATION TOOL
A. Overview
umlTUowl has been developed to overcome the problems
that arise during the transformation process of evaluated
UML2OWL tools. It is not only optimized to transform UML
class data models, as used by partners of CDL-Flex (Visual
Paradigm for UML V7.2, 8.2; XMI 2.1, Microsoft Visio 2010
10 http://www.uml-forum.com/FAQ.htm
Supported UML elements Not supported UML elements
- classes - multiplicity of attribute value
- abstract classes - attribute values except primitives
- interfaces - package elem. inside a diagram
- generalization - data constraints
- multiple packages (diagrams) - class operations
- attributes - association classes
- visibility of attributes (partly) - n-ary associations
- attrs. with primitive data types - overlapping/disjoint classes
- attrs. with XML data types - roles (VP, ArgoUML)
- associations - XOR annotation
- navigable associations - redefnition of derived attributes
- multiplicity of associations - subset annotation
- aggregations - ordering+uniqueness attr. annot.
- compositions - datatype meta annotation
- labelled endpoints (MS Visio) - enumerations
- comments / note elements - stereotypes
TABLE I: Comparison of supported and not supported UML
elements
XMI 1.0) into OWL 2 DL ontologies, but also attempts to be
a best practice lightweight framework for engineers and thus
is hosted as an open source project. 11 Both, executable and
source code are available.
umlTUowl eases the integration of new transformation
scripts, e.g. support for ArgoUML 0.32.2 XMI 2.1 (freeware)
has been already implemented. Its maxim is: don’t try to provide
an overall transformation solution for all vendors, because
parsing of XMI is too fragile. Be prepared for variations and
UML-model-vendor updates that affect the structure of the
resulting XMI code by providing traceability of supported
UML tools, as well as providing high testability, modifiability
and extensibility.
Traceability is reached by keeping record of version numbers,
export settings and supported UML elements for each
vendor-specific UML modeling tool. This approach has several
advantages. It provides end user documentation and guarantees
designated transformation results, which at all times are
OWL2 DL compatible and thus should be also compatible
with current versions of Protégé (¿=4.1). Furthermore, by
leveraging automated testing those artifacts also ensure that
whenever a vendor adapts a modeling tool, these changes
will be detected. umlTUowl comes with a bulk of unit tests
and three implemented reference model tools[4][pg.37ff.],
hence providing comprehensive templates to developers, who
want to implement transformations for additional models. By
utilizing a meta model, either a new input format (e.g. Entity
Relationship Diagram (ERD) instead of UML) may be added,
or the output converter (e.g. DAML instead of OWL) may be
replaced.
Supported UML elements are outlined in Table I. VP
uses the term package for diagram synonymously. umlTUowl
allows to define, if all packages should be merged into a
single ontology, or if an own ontology file should be created
for each package. The elements which are not supported by
umlTUowl typically are not commonly used or only wellunderstood
by UML experts. They have not been implemented
11 http://sourceforge.net/projects/uml2owl
732