SEKE 2012 Proceedings - Knowledge Systems Institute

within the umlTUowl prototype because these elements have
not been used by CDL-Flex customers and engineers in the
past years and also may not be important for the populace
of UML modelers outside CDL-Flex projects. Other reasons
are that some elements are hard to implement because they
can’t be expressed naturally in OWL. For instance, how can
someone express a class operation such as
, without introducing additional semantics?
However, this case is not relevant for the CDL-Flex.
The tool should be seen as a recommendation as well. It
attempts to suggest, which informations should be provided
when publishing an UML transformation tool, based on the
experiences collected during the evaluation phase.
B. Software Architecture
umlTUowl naturally accepts UML diagrams in the specified
XMI format. As illustrated in figure 1, at first the XML/XMI
files are loaded into memory. Depending on the XMI inputformat
a particular converter is selected, which transforms the
UML model into a simplified meta model ( ).
The meta model basically consists of modules that represent
and facilitate all relevant UML model elements in a convenient
way. It has been defined analogue to Eclipse MOF, Netbeans
MDR or as discussed in [9]. The usage of a meta model
has numerous benefits. On the one hand, decoupling of XMI
parsing process (
) and OWL serialization
( ) eases the adoption of additional converters
(e.g. Poseidon XMI format or even ER-diagram conversion)
and enables automated testing approaches. On the other
hand, a meta model can facilitate access to specific meta
data elements, which implies that searching, manipulating
and referencing of entities is much more comfortable than
directly accessing XML. This advantage is also leveraged by
the
component, which ensures that all classes,
attributes and associations are labeled with a unique and OWL
2 DL compatible name, before they are finally serialized into
an OWL 2 DL ontology utilizing the OWL API by University
of Manchester (OWL API). Decoupling of input (parsing) and
output (serialization) process furthermore has the advantage
that not only the parser might be replaced, but also the OWL
serialization component.
Fig. 1: Workflow and software architecture of umlTUowl
1) Harmonizer: The harmonizer component ensures the
uniqueness of element names and prepares them for the
OWL export. According to the configured strategy all entity
names in the meta model are unified, so that each name only
occurs once. Furthermore, attribute and association names are
converted into common OWL styles.
Table II illustrates some of the most considerable harmonizing
techniques and how they are applied (the complete example
can be found in [4][p.22]).Two strategys have been implemented
to handle packages: Depending on the configuration
either all meta packages are merged into a single meta model
during the harmonizing phase, or all packages remain and are
serialized into separated ontologies, subsequently. If all classes
are merged into a single ontology, more harmonizing effort
is required, since it can happen that semantically inequivalent
classes with same class name exist in different packages. These
classes have to be prefixed with their package name.
Duplicate attributes and association names frequently occur
even within a package. They appear, when packages are
merged into a single ontology or when the same attribute (or
association) name is contained in different UML classes (e.g.
age might exist for a class named ”Student“, but also for a class
named ”Building“). Therefore, the
component
offers a set of naming strategys, which can be customized.
Thus, attribute names are always renamed (pre- or suffixing
class and/or package name), if they occur more than
once, although different strategys exist therefore. Associations
often exist without label. Even if they are named labels
are useless, except the association is navigable. Hence, all
associations are renamed, depending on the chosen strategy
( ). For instance, as illustrated in table
II, aggregations and compositions can be renamed using
supplementary patterns. If only a conventional association
is established between two classes, e.g. ”Building“ contains
”Rooms“, this results in two OWL object properties. The first
one is named ”buildingHasRoomAssociation“ and the second
(inverse) object property is named ”roomHasBuildingAssociation“;
if the association is bidirectional navigable, there is no
way, to find out, if ”Building“ is contained in ”Room“ or vice
versa.
2) Metamodeltoowl: The OWL API by the University of
Manchester has been utilized to serialize umlTUowl’s meta
model into valid OWL2 DL. Not all UML elements have a
matching counterpart. For instance, an abstract UML class
will be transformed into an
entity with probably
specific naming conventions. Depending on the chosen transformation
strategy either all UML packages are merged into
a single file, or each package is separated into a single OWL
ontology. This approach is inspired by previous works, such
as [2] and [9].
Attributes are transformed into data properties. XML builtin
data types (e.g. ) are supported as well as OWL
built-in data types. UML associations result in OWL ob-
12 X: harmonizing carried out using default settings; blank: adapted configuration
settings; S: blank + special case
733