Evaluation of UML to OWL Approaches and Implementation of a Transformation Tool for Visual Paradigm and MS Visio
Andreas Grünwald · 2014
class {abstract} Student X Abstract Student abstract-prefix=Abstract abstract-postfix= interface class Student X Interface Student interface-prefix=Interface interface-postfix= attribute Class Student has attribute age (integer). X hasAge data-property-prefix=has boolean attribute Class Student has attribute male: Boolean. X isMale data-property-prefix-boolean=is attribute Two classes, namely Student and Building exist within the same package. Both contain attribute name. X Building: hasName Student: hasPackage1 StudentName merge-packages=true data-property-prefix=has merge-attribute-strategy=duplicates merge-attribute-prefix=package-class attribute Two classes, namely Student and Building exist within the same package. Both contain attribute name. Building: hasName Student: hasStudentName merge-packages=true data-property-prefix=has merge-attribute-strategy=duplicates merge-attribute-prefix={class} attribute Two classes, namely Student and Building exist within the same package. Both contain attribute name. Student: hasStudentName Building: hasBuildingName merge-packages=true data-property-prefix=has merge-attribute-strategy=all merge-attribute-prefix={class} attribute Person is an abstract superclass of Student. Both have the attribute name (Student overrides Person’s name. S Abstract Person: hasName Person: hasStudentName Reason: Abstract classes and interfaces are treated first. merge-packages=false data-property-prefix=has default-attribute-strategy=duplicates default-attribute-prefix={class} default-attribute-postfix= association Unidirectional association named based on between Tree and Trunk. X hasTreeTrunkRelation hasTrunkTreeRelation (inverse). Comment ”Relation originally named ’based on’“ will be added. relation-strategy-relation=Relation relation-strategie1=has{from}{to}{dependingRelation} UML to OWL Transformation 23 UML element Example D Harmonizing result Relevant settings composition Each Tire belongs to exactly 1 Car at one time. X hasCarTireComposition isTireOfCar (inverse part of) relation-strategie1=has{from}{to}{dependingRelation} relation-strategie-composition-part1=is{from}Of{to} relation-strategiecomposition=Composition aggregation University has Researchers. hasUniversityResearcher IsResearcherOfUniversity (inverse) relation-strategie1=has{from}{to}{dependingRelation} relation-strategie-aggregation-part1=is{from}Of{to} relation-strategie-aggregation= association Three associations: A Tank contains Temperature Sensors, Level Sensors and Heaters (all class names). All associations are labeled with contains. S All associations are still labeled with contains. In OWL, one object property named contains with domain Tank and range Temperature Sensor or Level Sensor or Heater will be created. allow-multiple-labeled-names=true relation-strategie-1={name} relation-strategie2=has{from}{to}{dependingRelation} Table 4: Examples of harmonizing techniques, depending on settings Table 4 illustrates the most common harmonizing techniques and how they are applied. Column ”D“ contains ”X“, if harmonizing has been carried out using default settings settings, ”S“ if it is a special case and hence required configuration changes, and is empty, if configuration parameters must be changed, to achieve the illustrated result, but is not a special case yet. Two strategies have been implemented to handle packages: Depending on configuration settings in settings.properties, either all meta packages are merged into a single meta model within the harmonizing phase, or all packages remain and are serialized into separated ontologies, subsequently. If all classes are merged into a single ontology, then more harmonizing effort is required, because it can happen, that semantically nonequivalent 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. Thus, attribute names are always renamed (preor suffixing class and/or package name), if they occur more than once, although different strategies exist therefore. Association labels are useless, except the association is navigable. Hence, all associations are renamed, depending on the chosen strategy (settings.properties). For instance, as illustrated in table 4, aggregations and compositions can be renamed using supplementary patterns. Another point concerning attribute transformation is, that it is necessary to traverse attributes of abstract classes and interfaces first and afterward continue with attributes of concrete classes. The reason is, that abstract classes are more general, so they should be altered as less as possible. If an attribute (e.g. age) exists for an abstract class and three concrete classes (even they are no subclasses of the abstract class), it is desirable that the abstract class keeps its original attribute name, while the concrete class’s attributes may be converted into, lets say studentAge, buildingAge, animalAge, without any further problems.