representation of uml class diagrams in owl 2 on the ... · representation of uml class diagrams in...

e-Informatica Software Engineering Journal Volume 13 Issue 1 2019 pages 63ndash103 DOI 105277e-Inf190103

Representation of UML Class Diagrams in OWL 2on the Background of Domain Ontologies

Małgorzata Sadowskalowast Zbigniew Huzarlowast

lowastFaculty of Computer Science and Management Wrocław University of Science and Technologymsadowskapwredupl zbigniewhuzarpwredupl

AbstractBackground UML class diagrams can be automatically validated if they are compliant witha domain knowledge specified in a selected OWL 2 domain ontology The method requirestranslation of the diagrams into their OWL 2 representationAim The aim of this paper is to present transformation and verification rules of UML classdiagrams to their OWL 2 representationMethod The analysis of the results of the systematic literature review on the topic of transfor-mation rules between elements of UML class diagrams and OWL 2 constructs The purpose of theanalysis is to present the extent to which state-of-the-art transformation rules cover the semanticsexpressed in class diagrams On the basis of the analysis new transformation rules expressing thesemantics not yet covered but expected from the point of view of domain modelling pragmaticshave been definedResults The first result is the revision and extension of the transformation rules identified inthe literature The second original result is a proposition of verification rules necessary to check ifa UML class diagram is compliant with the OWL 2 domain ontologyConclusion The proposed transformations can be used for automatic validation of complianceof UML class diagrams with respect to OWL 2 domain ontologies

Keywords UML OWL 2 transformation rules verification rules

1 Introduction

In [1] we presented an idea of a method for se-mantic validation of Unified Modeling Language(UML) class diagrams [2] with the use of OWL 2Web Ontology Language (OWL 2) [3] domainontologies While UML has been known for manyyears OWL is a much younger formalism and itsmain purpose is to represent knowledge in theSemantic Internet The choice of OWL is justifiedby the fact that knowledge and in particular on-tologies collected on the Internet will be increas-ingly used in business modelling as the first stageof software development The proposed approach[1] requires a transformation of an UML classdiagram constructed by a modeller into its seman-tically equivalent OWL 2 representation Despite

the fact that there are many publications whichdefine some UML to OWL 2 transformations tothe best of the authorsrsquo knowledge no study hasinvestigated a complete mapping covering all di-agram elements emphasized by pragmatic needsThis paper seeks to contribute in this field witha special focus on providing a full transformationof elements of an UML class diagram which arecommonly used in business and conceptual mod-elling All the transformations described in thispaper and the method of validation explainedin [1] have been implemented in a tool whoseprototype was presented in [4] On the basis ofthe proposed UMLndashOWL transformations thetool has been further extended Currently thetool offers validation of the modified diagramand can automatically suggest how the diagram

Submitted 6 June 2018 Revised 7 October 2018 Accepted 7 November 2018 Available online 14 December 2018

64 Małgorzata Sadowska Zbigniew Huzar

should be corrected on the basis of the ontologyA necessary requirement before the UML classdiagram can be validated with the use of OWLdomain ontology is that the diagram and theontology must follow one agreed domain vocab-ulary Moreover the domain ontology must beconsistent because it is the knowledge base forthe area

Our research is limited to the static elementsof UML class diagrams ndash the behavioural aspectrepresented by class operations is omitted Thisis due to the fact that the semantics of UML op-erations cannot be effectively expressed with theuse of OWL 2 constructs which do not representbehaviour In order to identify which transforma-tion rules of UML class diagrams into OWL con-structs have already been proposed we have per-formed a systematic review of literature The ex-tracted rules have been analysed compared andextended The resulting findings of how to con-duct the transformation of UML class diagram toits OWL 2 representation are described furtherin this paper In the rest of this paper OWLalways means OWL 2 if not stated otherwise

Besides the transformation rules the methodof semantic validation of UML class diagrams re-quires the so called verification rules This aspectis an original element of this research Transform-ing the UML elements to OWL may introducesome new properties that may be in conflict withthe ontology The verification rules are specifiedin the form of either OWL verification axioms orverification queries

It is then checked that the verification axiomsare not present in the domain ontology becauseif they are included the diagram is contradictoryto the domain knowledge In other words wecan say that the verification axioms detect if thesemantics of the diagram transformation is com-pliant with the axioms included in the domainontology Considering the inverse transformation(from the ontology to the diagram) the presenceof the verification axioms in the domain ontol-ogy means that the reengineering transformationwould remain in conflict with the semantics ofthe UML class diagram In [1] we presented someexamples of the consequences of a reengineering

transformation of OWL to UML which does nottake into account the verification rules

Verification queries are used for extractinginformation from a domain ontology the kind ofinformation that could not be provided throughinspecting the class diagram itself The domainontology can have more information regardingthe elements of a UML class diagram whichis not explicitly expressed on the diagram Forexample the ontology can contain informationabout individuals To give a more detailed per-spective the verification queries are used for (a)checking if the classes denoted as abstract in theUML class diagram do not have any individualsassigned in the OWL domain ontology (b) verify-ing if the multiplicity (of both the attributes andthe association ends) is not violated on the sideof the OWL domain ontology and (c) checkingif the user-defined list of literals of the specifiedenumerations on the UML class diagram is com-pliant with those defined in the OWL domainontology Technically all verification queries aredefined with the use of SPARQL1 language

The verification of UML class diagrams withthe use of the proposed method is possible thanksto the initial normalization of the domain ontol-ogy and the normalization of the transformationaxioms The concept of OWL ontology normal-ization is our proposition [5] Any input OWL 2DL ontology after normalization is presented ina new but semantically equivalent form becausethe normalization rules only change the structurebut do not affect the semantics of axioms or ex-pressions in the OWL 2 ontology The normalizedOWL 2 DL ontologies have a unified structure ofaxioms so that they can be algorithmically com-pared without the need to conduct additionalcomplex calculations The extensive details ofconducting the transformation of OWL 2 ontolo-gies to their normalized form are described in [5]In the rest of the paper OWL domain ontology isunderstood as OWL domain ontology after nor-malization (it should be done only once) Beforecomparison of axioms all transformation axiomsare also normalized (tool automatically savestransformation axioms also in the normalizedform so that no additional delay is needed in

1SPARQL Query Language httpswwww3orgTRsparql11-overview

Representation of UML Class Diagrams in OWL 2 on the Background of Domain Ontologies 65

the verification algorithm) For the purpose ofbeing compliant with the literature and for thepotential use of transformation axioms for otherpurposes all transformation axioms presentedin this paper are not normalized On the otherhand due to the fact that verification axioms areour proposition preliminary designed to supportverification of UML class diagrams some rulesfor verification axioms are already defined in thenormalized form in order to reduce the numberof unnecessary redundant verifications the restrules for verification axioms are not yet normal-ized for the purpose of clarity for readers butthe tool also automatically saves the verificationaxioms directly as normalized

In practical use of UML to OWL transforma-tion the initial phase involving modellerrsquos atten-tion is required The modeller has to assure thatall class attributes and association end names inone UML class are uniquely named Otherwisethe transformation rules may generate repeatingOWL axioms which may lead to inconsistenciesor may be semantically incorrect

The remainder of this article is organizedas follows Section 2 summarizes related worksSection 3 outlines which elements of UML classdiagrams are commonly used in business andconceptual modelling Section 4 describes theprocess and the results of the conducted sys-tematic literature review which was focused onidentifying the state-of-the-art transformationrules for translating UML class diagrams intotheir OWL representation Section 5 presentsthe revised and extended transformation rulesand proposes the verification rules Section 6summarises some important differences betweenOWL 2 and UML languages and their impact ontransformation Section 7 illustrates applicationof transformation and verification rules to exam-ple UML class diagrams Section 8 is dedicatedto the tool that implements the transformationsFinally Section 9 concludes the paper

2 Class diagrams in businessand conceptual modelling

The UML specification [2] does not strictly spec-ify which elements of UML class diagrams should

or should not be included in the specific diagramsand this decision is always left to modellers How-ever not all model elements are equally useful inthe practice of business and conceptual modellingwith UML class diagrams

In [6] it is suggested that a full variety ofUML constructs is not needed until the imple-mentation phase and it is practiced that a subsetof diagram elements useful for conceptual mod-elling in the business context is selected Thefollowing static elements of UML class diagramsare suggested in literature as the most importantin business and conceptual modelling [7 8]ndash named classesndash attributes of classes with types (either primi-

tive or structured datatypes)ndash associations between the classes (including

aggregation) with the specified multiplicityof the association ends

ndash generalization relationshipsModelling a complex business requires using

several views each of which focuses on a partic-ular aspect of business Following [7] there arefour commonly used Business Views BusinessVision View Business Process View BusinessStructure View and Business Behaviour ViewThe UML class diagrams are identified as useful[7] in Business Vision View and Business Struc-ture View

The UML class diagrams in a Business Vi-sion View [7] are used to create conceptual mod-els which establish a common vocabulary anddemonstrate relationships among different con-cepts used in business The important elements ofUML class diagrams in the conceptual modellingare named classes and associations between theclasses as they define concepts The classes canhave attributes as well as a textual explanationwhich together constitute a catalogue of termsThe textual descriptions may not be necessar-ily visible on the UML diagram but should beretrievable with the help of modelling tools Inthe conceptual modelling with UML attributesand operations of classes are not so much im-portant [7] (can be defined only if needed) butrelationships among the classes should be alreadycorrectly captured in models

The UML class diagrams in a Business Struc-ture View [7] are focused on presenting a struc-


ture of resources products services and infor-mation regarding the business including the or-ganization of the company The class diagramsin this view often include classes containing at-tributes with types and operations as well asgeneralizations and associations with the speci-fied multiplicity

In [8] modelling business processes with UMLclass activity and state machine diagrams is sug-gested UML class diagrams with a number ofpredefined classes are used to describe process en-tity representatives (activities agents resourcesand artefacts) The examples in [8] present a busi-ness process at the level of the UML class dia-gram as consisting of classes with attributes classgeneralizations associations between the classes(including aggregation) with a specified multiplic-ity of the association ends The class attributesare typed with either primitive or structureddatatypes

We have not found further recommendationsfor using additional static UML class diagramelements in the context of business or conceptualmodelling in other reviewed literature positionsIf the selected UML class diagram is compliantwith the domain it is reasonable to examinethe diagram further For example the questionoutside the scope of this research is about the roleof OCL2 in business and conceptual modellingwith UML class diagrams Some other worksinvestigate this aspect eg in [9] an approach totranslate OCL invariants into OWL 2 DL axiomscan be found

3 Review process

Kitchenham and Charters in [10] provide guide-lines for performing systematic literature review(SLR) in software engineering Following [10]a systematic literature review is a means of eval-uating and interpreting all available researchrelevant to a particular research question andaims at presenting a fair evaluation of a re-search topic by using a rigorous methodologyThis section describes the carried out reviewaimed at identifying studies describing mappings

of UML class diagrams to their OWL represen-tations

31 Research question

The research question isRQ ldquoWhat transformation rules between ele-ments of UML class diagrams and OWL con-structs have already been proposedrdquo

32 Data sources and search queries

In order to make the process repeatable the de-tails of our search strategy are documented belowThe search was conducted in the following onlinedatabases IEEE Xplore Digital Library SpringerLink ACM Digital Library and Science DirectThese electronic databases were chosen becausethey are commonly used for searching literaturein the field of Software Engineering Additionalsearches with the same queries were conductedthrough ResearchGate and Google scholar in or-der to discover more relevant publications Thesepublication channels were searched to find pa-pers published in all the available years untilMay 2018 The earliest primary study actuallyincluded was published in 2006

For conducting the search the following key-words were selected ldquotransformationrdquo ldquotrans-formingrdquo ldquomappingrdquo ldquotranslationrdquo ldquoOWLrdquoldquoUMLrdquo and ldquoclass diagramrdquo The keywords arealternate words and synonyms for the terms usedin the research question which aimed to mini-mize the effect of differences in terminologies Pilotsearches showed that the above keywords were toogeneral and the results were too broad Thereforein order to obtain more relevant results the searchqueries were based on the Boolean AND to jointermsndash ldquotransformationrdquo AND ldquoOWLrdquo AND ldquoUMLrdquondash ldquotransformingrdquo AND ldquoOWLrdquo AND ldquoUMLrdquondash ldquomappingrdquo AND ldquoOWLrdquo AND ldquoUMLrdquondash ldquotranslationrdquo AND ldquoOWLrdquo AND ldquoUMLrdquondash ldquotransformationrdquo AND ldquoOWLrdquo AND ldquoclass

diagramrdquondash ldquotransformingrdquo AND ldquoOWLrdquo AND ldquoclass di-

agramrdquo2Object Constraint Language (OCL) httpwwwomgorgspecOCL


ndash ldquomappingrdquo AND ldquoOWLrdquo AND ldquoclass dia-gramrdquo

ndash ldquotranslationrdquo AND ldquoOWLrdquo AND ldquoclass dia-gramrdquo

33 Inclusion and exclusion criteria

The main inclusion criterion was that a paper pro-vides some transformation rules between UMLclass diagrams and OWL constructs Addition-ally the study had to be written in English andbe fully accessible through the selected onlinelibraries Additionally there was a criterion forexcluding a paper from the review results if thestudy described transformation rules betweenother types of UML diagrams to OWL represen-tation or described transformation rules to otherontological languages

34 Study quality assessment

The final acceptance of the literature was doneby applying the quality criteria The criteria wereassigned a binary ldquoyesrdquoldquonordquo answer In orderfor a work to be selected it needed to provideldquoyesrdquo answer to both questions from the checklist1 Are the transformation rules explicitly de-

fined For example a paper could be excludedif it only reported on a possibility of specify-ing transformation rules for the selected UMLelements but such transformations were notprovided

2 Do the proposed transformation rules pre-serve the semantics of the UML elementsFor example a paper (or some selected trans-formation rules within the paper) could beexcluded if the proposed rules in the trans-formation to OWL 2 did not preserve thesemantics of the UML elements

35 Study selection

During the search the candidate papers for fulltext reading were identified by evaluating theirtitles and abstracts The literature was includedor excluded based on the selection criteria Thegoal was to obtain the literature that answeredthe research question The candidate papers af-

ter eliminating duplicates were fully read Afterpositive assessment of the quality of the litera-ture items they were added to the results of thesystematic literature review

Next if the paper was included its referencelist was additionally scanned in order to iden-tify potential further relevant papers (backwardsearch) Later the paper selection has addition-ally been extended by forward search related toworks citing the included papers In both back-ward search and forward search the papers forfull text reading were identified based on readingtitle and abstract

36 Threats to validity

We have identified threats to the validity of theconducted SLR grouped in accordance with thecategories presented in [11] Wherever applica-ble we included the applied mitigating factorscorresponding to the identified threats

Construct Validity The specified searchqueries may not be able to completely cover alladequate search terms related to the researchtopic As a mitigating factor we used alternatewords and synonyms for the terms used in theresearch question

Internal Validity The identified treats tointernal validity relate to search strategy andfurther steps of conducting the SLR such asselection strategy and quality assessment1 A threat to validity was caused by lack of

assurance that all papers relevant to answer-ing the research question were actually foundA mitigating factor to this threat was con-ducting a search with several search queriesand analyzing the references of the primarystudies with the aim of identifying furtherrelevant studies

2 Another threat was posed by the selectedresearch databases The threat was reducedby conducting the search with the use of sixdifferent electronic databases

3 A threat was caused by the fact that oneresearcher conducted SLR A mitigating fac-tor to the search process and the study se-lection process was that the whole searchprocess was twice reconducted in April 2018


and May 2018 The additional procedures didnot change the identified studiesExternal Validity External validity concen-

trates on the generalization of findings derivedfrom the primary studies The carried search wasaimed at identifying transformation rules of ele-ments of UML class diagram to their OWL 2 rep-resentation Some transformation rules could beformulated analogically in some other ontologicallanguages eg DAML+OIL etc Similarly sometransformation rules could be formulated analog-ically in some modelling languages or notationsdifferent then UML class diagrams eg in En-tity Relationship Diagram (ERD) EXPRESS-Ggraphical notation for information models etcA generalization of findings is out of scope of thisresearch

Conclusion Validity The search process wastwice reconducted and the obtained results havenot changed However non-determinism of somedatabase search engines is a threat to the re-liability of this and any other systematic re-view because the literature collected throughnon-deterministic search engines might not berepeatable by other researchers with exactly thesame results In particular it applies to the re-sults obtained with the use of Google scholar andResearchGate

4 Related work

41 Search results

In total the systematic literature review identi-fied 18 studies 14 literature positions were foundduring the search [12ndash26] Additional 30 studieswere excluded based on the quality assessmentexclusion criterion

Additional 3 studies were obtained throughthe analysis of the references of the identifiedstudies (the backward search) [27ndash29]

The forward search has not resulted in anypaper included The majority of papers had al-ready been examined during the main search andhad already been either previously included orexcluded In the forward search three papers de-scribing transformation rules have been excludedbecause they were not related to UML Most

other papers have been excluded because theyhave not described transformation rules Twopapers have been excluded because the transfor-mation rules were only mentioned but not de-fined A relatively large number (approximately20) of articles has been excluded based on thelanguage criterion ndash they had not been written inEnglish (the examples of the observed repetitivelanguages Russian French Turkish Chineseand Spanish)

The results of the search with respect to datasources are as follows (data source ndash numberof selected studies) ResearchGate ndash 6 SpringerLink ndash 3 IEEE Xplore Digital Library ndash 2Google Scholar ndash 2 ACM Digital Library ndash 1Science Direct ndash 1 In order to eliminate dupli-cates that were found in more than one electronicdatabase the place where a paper was first foundwas recordedTable 1 Search results versus years of publication

Year of publication Resulting papers

2006 [23]2008 [14162127]2009 [13]2010 [26]2012 [1217202225]2013 [192428]2014 [29]2015 [18]2016 [15]

To summarize the identified studies include3 book chapters 8 papers published in journals5 papers published in the proceedings of confer-ences 1 paper published in the proceedings ofa workshop and 1 technical report The identifiedprimary studies were published in the years be-tween 2006ndash2016 (see Table 1) What can be ob-served is that the topic has been gaining greaterattention since 2008 It should not be a surprisebecause OWL became a formal W3C recommen-dation in 2004

42 Summary of identified literature

Most of the identified studies described just a fewcommonly used diagram elements (ie UML classbinary association and generalization between


the classes or associations) while some other di-agram elements obtained less attention in theliterature (ie multiplicity of attributes n-aryassociation or generalization sets) For some classdiagram elements the literature offers incom-plete transformations Some of the transforma-tion rules defined in the selected papers are ex-cluded from the findings based on the quality cri-teria defined in Section 34 The state-of-the-arttransformation rules were revised and extendedSection 5 contains detailed references to the lit-erature related to relevant transformations Thefollowing is a short description of the includedstudies

The work presented in [18] transforms intoOWL some selected elements of UML modelscontaining multiple UML class object and state-chart diagrams in order to analyze consistencyof the models A similar approach is presented in[19] which is focused on detecting inconsistencyin models containing UML class and statechartdiagrams

The papers [151729] investigate the differ-ences and similarities between UML and OWLin order to present transformations of selected(and identified as useful) elements of UML classdiagram In [29] the need for UMLndashOWL trans-formation is additionally motivated by not re-peating the modelling independently in both lan-guages

In [14] a possible translation of few selectedelements of several UML diagrams to OWL ispresented The paper takes into account a setof UML diagrams use case package class ob-ject timing sequence interaction overview andcomponent The behavioural elements in UMLdiagrams in [14] are proposed to be translatedto OWL with annotations

The work of [26] focuses on representingUML and MOF-like metamodels with the use ofOWL 2 language The approach includes propo-sition of transforming Classes and Properties

The paper [27] compares OWL abstract syn-tax elements to the equivalent UML featuresand appropriate OCL statements The analysisis conducted in the direction from OWL to UMLFor every OWL construct its UML interpretationis proposed

The article [20] describes transformation rulesfor UML data types and class stereotypes se-lected from UML profile defined in ISO 19103A full transformation for three stereotypes isproposed The article describes also some addi-tional OWLndashUML mappings The focus of [28] isnarrowed to transformation of data types only

Some works are focused on UMLndashOWL trans-formations against the single application domainThe paper [21] depicts the applicability of OWLand UML in the modelling of disaster manage-ment processes In [16] transportation data mod-els are outlined and the translation of UMLmodel into its OWL representation is conductedfor the purpose of reasoning

The works presented in [121323] are focusedon extracting ontological knowledge from UMLclass diagrams and describe some UMLndashOWLmappings with the aim to reuse the existingUML models and stream the building of OWLdomain ontologies The paper [12] from 2012extends and enhances the conference paper [13]from 2009 Both papers were analysed during theprocess of collecting the data in case of detectionof any significant differences in the descriptionof transformation rules

In [22] UML classes are translated into OWLFinally [24 25] present a few transformations ofclass diagram elements to OWL

5 UML class diagram and its OWL 2representation

This section presents transformation rules(TR) which seek to transform the elements ofUML class diagrams to their equivalent repre-sentations expressed in OWL 2 Some of thetransformation rules come from the literatureidentified in the review (eg TR1 in Table 2)Another group of rules have their archetypesin the state-of-the-art transformation rules butwe have refined them in order to clarify theircontexts of use (eg TRA TRC in Section 62)or extend their application to a broader scope(eg TR1 in Table 5) The remaining transfor-mation rules are our new propositions (eg TR5in Table 7)


In contrast to the approaches available inthe literature together with the transformationrules we define the verification rules (VR) forall elements of a UML class diagram whereverapplicable The need for specifying verificationrules results from the fact that we would like tocheck the compliance of the OWL representationof UML class diagram with the OWL domainontology The role of verification rules is to de-tect if the semantics of a diagram is not in con-flict with the knowledge included in the domainontology

All the transformation and verification rulesare presented in Tables 2ndash21 We took into con-sideration all the static elements of UML classdiagrams which are important from the point ofview of pragmatics (see Section 2) To summarizethe results most of the UML elements which arerecommended [7 8] in business or conceptualmodelling with UML class diagrams are fullytransformable to OWL 2 constructsndash Class (Table 2)ndash attributes of the Class (Table 4)ndash multiplicity of the attributes (Table 5)ndash binary Association ndash both between two differ-

ent Classes (Table 6) as well as from a Classto itself (Table 7)

ndash multiplicity of the Association ends (Table 9)ndash Generalization between Classes (Table 12)ndash Integer Boolean and UnlimitedNatural prim-

itive types (Table 18)ndash structured DataType (Table 19)ndash Enumeration (Table 20)ndash Comments to the Class (Table 21)

We additionally fully translated into OWL 2the following UML elements which have not beenidentified among recommended for business orconceptual modelling but can be used in furtherstages of software developmentndash Generalization between Associations (Ta-

ble 13)ndash GeneralizationSet with constraints (Tables

14ndash17)ndash AssociationClass (Table 10 and Table 11)

The UML and OWL languages have differentexpressing power We consider also the partialtransformation which is possible for

ndash String and Real primitive types becausethey have only similar but not equivalentto OWL 2 types (Table 18)

ndash aggregation and composition can be trans-formed only as simple associations (Tables6ndash7)

ndash n-ary Association ndash OWL 2 offers only binaryrelations a pattern to mitigate the problem oftransforming n-ary Association is presented(Table 8)

ndash AbstractClass ndash OWL 2 does not offer anyaxiom for specifying that a class must notcontain any individuals Although it is im-possible to confirm that the UML abstractclass is correctly defined with respect to theOWL 2 domain ontology it can be detectedif it is not (Table 3)The tables below present for each UML ele-

ment its short description a graphical symboltransformation rules verification rules expla-nations or comments limitations of the trans-formations (if any) and the works related forthe transformation rules (if any) Additionallysome tables include references to Section 7 whereexamples of UMLndashOWL transformations are pre-sented

The convention for transformation and veri-fication rules presentation is semi-formal simi-lar to the convention used in other publicationpresenting transformation rules eg [17 20] Itseems to be more readable than a strict formalpresentation However a formal presentation isimplicitly defined in the programming tool whichtransforms any UML class diagram into a set ofOWL axioms

All OWL 2 constructs are written with theuse of a functional-style syntax [30] Additionallythe following convention is usedndash C ndash indicates an OWL classndash CE (possibly with an index) ndash indicates

a class expressionndash OPE (possibly with an index) ndash indicates an

object property expressionndash DPE (possibly with an index) ndash indicates

a data property expressionndash α = β ndash means textual identity of α and β

OWL 2 constructs


ndash α 6= β ndash means textual difference of α and βOWL 2 constructs

ndash The elements of UML meta-model UMLmodel and OWL entities or literals namedin the UML model are written with the useof italic font

ndash The OWL 2 constructs (axioms expressionsand datatypes) and SPARQL queries are writ-ten in boldAll presented SPARQL queries use the fol-

lowing prefixes

PREFIX rdf lthttpwwww3org19990222-rdf-syntax-nsgtPREFIX owl lthttpwwww3org200207owlgtPREFIX xsd lthttpwwww3org2001XMLSchemagtPREFIX rdfs lthttpwwww3org200001rdf-schemagtPREFIX lthttpselected ontologygt

51 Transformation of UML classes with attributes

Table 2 Classes and the defined rules

UML element Class

Description of UMLelement

In UML a Class [2] is purposed to specify a classification of objects

Symbol of UMLelementTransformation rules TR1 Specify declaration axiom for UML Class as OWL Class

Declaration( Class( ClassName ) )Verification rules VR1 Check if ClassName class has the HasKey axiom defined in the domain

ontology HasKey( ClassName( OPE1 OPEm) ( DPE1 DPEn) )Comments to the rules 1 Regarding VR1 The OWL HasKey axiom assures [3031] that if two named

instances of a class expression contain the same values of all object and dataproperty expressions then these two instances are the same This axiom is incontradiction with the semantics of UML class because UML specification allowsfor creating different objects with exactly the same properties

Related works In [12ndash2325ndash27] UML class is transformed to OWL with the use of TR1 axiomExample Section 7 example 1 2 and 3

Table 3 Abstract classes and the defined rules

UML element Abstract Class


In UML an abstract Class [2] cannot have any instances and only its subclassescan be instantiated

Symbol of UMLelementTransformation rules Not possible The UML abstract classes cannot be translated into OWL

because OWL does not offer any axiom for specifying that a class must notcontain any individuals

Verification rules VR1 Check if the domain ontology contains any individual specified for theAbstractClassSELECT (COUNT (DISTINCT ind) as count)WHERE ind rdftype AbstractClass


If the AbstractClass does not contain any individual specified in the domainontology the SPARQL query returns zero0^^lthttpwwww3org2001XMLSchemaintegergt

Comments to the rule OWL follows the Open World Assumption [30] therefore even if the ontologydoes not contain any instances for a specific class it is unknown whether theclass has any instances We cannot confirm that the UML abstract class iscorrectly defined with respect to the OWL domain ontology but we can detect ifit is not (VR1 checks if the class specified as abstract in the UML class diagramis indeed abstract in the domain ontology)

Related works In [172029] UML abstract class is stated as not transformable into OWL In[1720] it is proposed that DisjointUnion is used as an axiom which coverssome semantics of UML abstract class However UML specification does notrequire an abstract class to be a union of disjoint classes and theDisjointUnion axiom does not prohibit creating members of the abstractsuperclass therefore it is insufficient

Table 4 Attributes and the defined rules

UML element Attributes


The UML attributes [2] are Properties that are owned by a Classifier eg Class

Symbol of UMLelement

Transformation rules TR1 Specify declaration axiom(s) for attribute(s) as OWL data or objectproperties respectivelyDeclaration( ObjectProperty( name ) )Declaration( DataProperty( index ) )Declaration( DataProperty( year ) )Declaration( ObjectProperty( faculty ) )TR2 Specify data (or object) property domains for attribute(s)ObjectPropertyDomain( name Student )DataPropertyDomain( index Student )DataPropertyDomain( year Student )ObjectPropertyDomain( faculty Student )TR3 Specify data (or object) property ranges for attribute(s) (fortransformation of UML PrimitiveTypes refer to Table 18 for transformation ofUML structureDataTypes to Table 19)ObjectPropertyRange( name FullName )DataPropertyRange( index xsdstring )DataPropertyRange( year xsdinteger )ObjectPropertyRange( faculty Faculty )

Verification rules VR1 Check if the domain ontology contains ObjectPropertyDomain (orDataPropertyDomain) axiom specified for OPE (or DPE) where CE isspecified for a different than given UML Class (here Student)ObjectPropertyDomain( name CE ) where CE 6= StudentDataPropertyDomain( index CE ) where CE 6= StudentDataPropertyDomain( year CE ) where CE 6= StudentObjectPropertyDomain( faculty CE ) where CE 6= StudentVR2 Check if the domain ontology contains ObjectPropertyRange (orDataPropertyRange) axiom specified for OPE (or DPE) where CE is


specified for a different than given UML structureDataType (or DR is specifiedfor a different than given UML PrimitiveType)ObjectPropertyRange( faculty CE ) where CE 6= FacultyDataPropertyRange( index DR ) where DR 6= xsdstringDataPropertyRange( year DR ) where DR 6= xsdintegerObjectPropertyRange( name CE ) where CE 6= FullName

Comments to the rules 1 Both UML attributes and associations are represented by one meta-modelelement ndash Property OWL also allows one to define properties A transformationof UML attribute to OWL data property or OWL object property bases on itstype If the type of the attribute is PrimitiveType it should be transformed intoOWL DataProperty However if the type of the attribute is a structuredDataTypeit should be transformed into an OWL ObjectProperty2 VR1 checks whether or not the object properties (or respectively dataproperties) indicate that the UML attributes are specified for given UML Class3 VR2 checks whether or not the object properties (or respectively dataproperties) indicate that the UML attributes of the specified UML Class havespecified given types either PrimitiveTypes or structured DataTypes

Related works TR1ndashTR3 are proposed in [15ndash1720] In [12ndash14181921ndash24] all UMLattributes are translated into data properties only

Example Section 7 example 2 and 3

Table 5 Multiplicity of attributes and the defined rules

UML element Multiplicity of attributes


In [2] multiplicity bounds ofMultiplicityElement are specified in the form ofltlower-boundgt ldquordquo ltupper-boundgt The lower-bound is of a non-negativeInteger type and the upper-bound is of an UnlimitedNatural type The strictlycompliant specification of UML in version 25 defines only a single value rangefor MultiplicityElement However in practical examples it is sometimes usefulnot limit oneself to a single interval Therefore the below UML to OWLmapping covers a wider case ndash a possibility of specifying more value ranges fora multiplicity element Nevertheless if the reader would like to strictly follow thecurrent UML specification the particular single lowerupper bound interval istherein also comprisedIn comparison to UML the OWL specification [30] defines three classexpressions ObjectMinCardinality ObjectMaxCardinality andObjectExactCardinality for specifying the individuals that are connected byan object property to at least at most or exactly to a given number(non-negative integer) of instances of the specified class expression AnalogicallyDataMinCardinality DataMaxCardinality and DataExactCardinalityclass expressions are used for data properties


Transformation rules TR1 If UML attribute is specified with the use of OWL ObjectProperty itsmultiplicity should be specified analogously to TR1 from Table 9 (multiplicityof association ends) If UML attribute is specified with the use of OWLDataProperty its multiplicity should be specified with the use of axiomSubClassOf( ClassName multiplicityExpression )We define multiplicityExpression as one of class expressions A B C or DA a DataExactCardinality class expression if UML MultiplicityElement haslower-bound equal to its upper-bound eg ldquo11rdquo which is semanticallyequivalent to ldquo1rdquo


B a DataMinCardinality class expression if UML MultiplicityElement haslower-bound of Integer type and upper-bound of unlimited upper-boundeg ldquo2rdquoC an ObjectIntersectionOf class expression consisting ofDataMinCardinality and DataMaxCardinality class expressions if UMLMultiplicityElement has lower-bound of Integer type and upper-bound of Integertype eg ldquo46rdquoD an ObjectUnionOf class expression consisting of a combination ofObjectIntersectionOf class expressions (if needed) orDataExactCardinality class expressions (if needed) or oneDataMinCardinality class expression (if the last range has unlimitedupper-bound) if UML MultiplicityElement has more value ranges specified egldquo2 46 89 15rdquoThe following is the result of application of TR1 to the above diagramSubClassOf( ScrumTeam

ObjectExactCardinality( 1 scrumMaster Employee ) )SubClassOf( ScrumTeam ObjectIntersectionOf(

ObjectMinCardinality( 3 developer Employee )ObjectMaxCardinality( 9 developer Employee ) ) )

Verification rules VR1 Regardless of whether or not the UML attribute is specified with the useof OWL DataProperty or ObjectProperty the verification rule is definedwith the use of the SPARQL query (only applicable for multiplicities withmaximal upper-bound not equal ldquordquo)SELECT vioInd ( count ( range ) as n )WHERE vioInd leaf range GROUP BY vioIndHAVING ( n gt maxUpperBoundValue )

where maxUpperBoundValue is a maximal upper-bound value of the multiplicityrange If the query returns a number greater than 0 it means that UMLmultiplicity is in contradiction with the domain ontology (vioInd listsindividuals that cause the violation)The following is the result of definition of VR1 to the above diagrammaxUpperBoundValue for scrumMaster 1SPARQL query for scrumMaster SELECT vioInd (count (range) as n)WHERE vioInd scrumMaster range GROUP BY vioIndHAVING ( n gt 1)maxUpperBoundValue for developer 9SPARQL query for developer SELECT vioInd (count ( range ) as n )WHERE vioInd developer range GROUP BY vioIndHAVING ( n gt 9 )VR2 Check if the domain ontology contains SubClassOf axiom whichspecifies CE with different multiplicity of attributes than it is derived from theUML class diagramSubClassOf( ScrumTeam CE )

Comments to the rules 1It should be noted that upper-bound of UML MultiplicityElement can bespecified as unlimited ldquordquo In OWL cardinality expressions serve to restrict thenumber of individuals that are connected by an object property expression toa given number of instances of a specified class expression [30] Therefore UMLunlimited upper-bound does not add any information to OWL ontology henceit is not transformed2 Regarding TR1 the rule relies on the SubClassOf( CE1 CE2 ) axiomwhich restricts CE1 to necessarily inherit all the characteristics of CE2 but notthe other way around The difference of using EquivalentClasses( CE1 CE2 )


axiom is that the relationship is implied to go in both directions (and thereasoner would infer in both directions)3 Regarding VR1 As motivated in [17] reasoners that base on Open WorldAssumption can detect a violation of an upper limit of the cardinalityrestrictions only This is caused by the fact that in Open World Assumption it isassumed that there might be other individuals beyond those that are alreadypresented in the ontology The verification rules for the cardinality expressionsare defined with the use of SPARQL queries which are aimed to verify whetheror not the domain ontology does have any individuals that are contradictory toTR1 axiom Therefore the VR1 verifies the existence of individuals that areconnected to the selected object property a number of times that is greater thanthe specified UML multiplicity4 The rule VR2 verifies if the ontology contains axioms which describemultiplicity of Attributes different than the multiplicity specified in the UMLclass diagram

Related works The related works present only partial solutions for multiplicity of attributesIn [29] a solution for a single value interval is proposed In [17] multiplicityassociated with class attributes is transformed to a single expression of exactmaximum or minimum cardinality In [24] multiplicity is transformed only intomaximum or minimum cardinality

Example Section 7 example 2

52 Transformation of UML associations

Table 6 Binary Associations between two different Classes and the defined rules

UML element Binary Association (between two different Classes)


Following [2] a binary Association specifies a semantic relationship between twomemberEnds represented by Properties Please note that in accordance withspecification [2] the association end names are not obligatory In the method ofvalidation and the prototype tool we followed the same convention which isadopted for all metamodel diagrams throughout the specification ([2 page 61])If an association end is unlabeled the default name for that end is the name ofthe class to which the end is attached modified such that the first letter isa lowercase letter Due to the fact that our method of transformation requiresadditionally unique names either the modeller has to rename the names or thetool in such cases automatically adds subsequent numbers to the namesFor transformation of UML multiplicity of the association ends refer to Table 9

Symbol of UMLelementTransformation rules TR1 Specify declaration axiom(s) for object properties

Declaration( ObjectProperty( team ) )Declaration( ObjectProperty( goalie ) )TR2 Specify object property domains for association ends (note if theassociation contains an AssociationClass the domains should be transformed inaccordance with TR1 from Table 10)ObjectPropertyDomain( team Player )ObjectPropertyDomain( goalie Team )TR3 Specify object property ranges for association endsObjectPropertyRange( team Team )ObjectPropertyRange( goalie Player )


TR4 Specify InverseObjectProperties axiom for the associationInverseObjectProperties( team goalie )

Verification rules VR1 Check if AsymmetricObjectProperty axiom is specified for any ofUML association endsAsymmetricObjectProperty( goalie )AsymmetricObjectProperty( team )VR2 Check if the domain ontology contains ObjectPropertyDomainspecified for the same OPE but different CE than it is derived from the UMLclass diagramObjectPropertyDomain( team CE ) where CE 6= PlayerObjectPropertyDomain( goalie CE ) where CE 6= TeamVR3 Check if the domain ontology contains ObjectPropertyRange axiomspecified for the given OPE but different CE than it is derived from the UMLclass diagramObjectPropertyRange( team CE ) where CE 6= TeamObjectPropertyRange( goalie CE ) where CE 6= Player

Comments to the rules 1 TR4 is specified to state that both resulting object properties are part of oneUML Association2 Regarding VR1 A binary Association between two different Classes may notbe asymmetric Please refer to Table 7 for explanation of asymmetric binaryAssociation from a Class to itself3 Regarding VR2 If the domain ontology contains ObjectPropertyDomainspecified for the same OPE but different CE than it is derived from the UMLclass diagram the Association is defined in the ontology but between differentClasses4 Regarding VR3 If the domain ontology contains ObjectPropertyRangeaxiom specified for the given OPE but different CE than it is derived from theUML class diagram the Association is defined in the ontology but betweendifferent Classes

Limitations of themapping

1 UML Association has two important aspects The first is related to itsexistence and it can be transformed to OWL It should be noted that UMLintroduces an additional notation related to communication between objectsThe second one concerns navigability of the association ends which isuntranslatable because OWL does not offer any equivalent concept2 Both UML aggregation and composition can be only transformed to OWL asregular Associations This approach loses the specific semantics related to thecomposition or aggregation which is untranslatable to OWL

Related works In [14ndash222527] TR1ndashTR3 rules for the transformation of UML binaryassociation to object property domain and range are proposed In [152026]TR4 rule is additionally proposedIn [1720] a unidirectional association is transformed into one object propertyand a bi-directional association into two object properties (one for eachdirection) This interpretation does not seem to be sufficient because if anassociation end is not navigable in UML 25 access from the other end may bepossible but it might not be efficient ([2 page 198])


Table 7 Binary Association from the Class to itself and the defined rules

UML element Binary Association from a Class to itselfDescription of UMLelement

A binary Association [2] contains two memberEnds represented by PropertiesFor transformation of multiplicity of the association ends refer to Table 9



Transformation rules TR1ndashTR4 The same as TR1ndashTR4 from Table 6 TR5 SpecifyAsymmetricObjectProperty axiom for each UML association endAsymmetricObjectProperty( isPartOf )AsymmetricObjectProperty( isDividedInto )

Verification rules VR1 is the same as VR2 from Table 6VR2 is the same as VR3 from 6

Comments to the rules 1 In TR2 domain and range of binary association is the same UML class VR4checks if the domain ontology does not specify a different domain or range forthe Association2 In TR5 object property OPE is defined as asymmetric In OWL if anindividual x is connected by OPE to an individually then y cannot be connectedby OPE to x


The same as presented in Table 6

Related works For TR1ndashTR4 related works are analogous as in Table 6 while TR5 is ournew proposition In [15] the UML binary association from the Class to itself isconverted to OWL with the use of two ReflexiveObjectProperty axioms Wedo not share this approach because a specific association may be reflexive but inthe general case it is not true The ReflexiveObjectProperty axiom statesthat each individual is connected by OPE to itself In consequence it wouldmean that every object of the class should be connected to itself The UMLbinary Association has a different meaning where the association ends havedifferent roles


Table 8 N -ary associations and the defined rules

UML element N -ary AssociationDescription of UMLelement

UML n-ary Association [2] specifies the relationship between three or morememberEnds represented by Properties For transformation of UML multiplicityof the association ends refer to Table 9


Transformation rules Not possible to directly represent UML n-ary associations in OWL 2 Thefollowing is a partial transformation based on the pattern presented in [32] Thepattern requires creating a new class and N new properties to represent the n-aryassociation The figure below shows the corresponding classes and properties


TR1 Specify declaration axiom for the new class which represent the n-aryassociation (declaration axioms for other classes are added following Table 2)Declaration( Class( Schedule ) )TR2 Specify declaration axiom(s) for object propertiesDeclaration( ObjectProperty( student ) )Declaration( ObjectProperty( course ) )Declaration( ObjectProperty( lecturer ) )TR3 Specify object property domains for association endsObjectPropertyDomain( student Student )ObjectPropertyDomain( course Course )ObjectPropertyDomain( lecturer Lecturer )TR4 Specify object property ranges for association endsObjectPropertyRange( student Schedule )ObjectPropertyRange( course Schedule )ObjectPropertyRange( lecturer Schedule )TR5 Specify SubClassOf( CE1ObjectSomeValuesFrom( OPE CE2 ) )axioms where CE1 is a newly added class OPE are properties representing theUML Association and CE2 are corresponding UML ClassesSubClassOf( Schedule ObjectSomeValuesFrom( student Student ) )SubClassOf( Schedule ObjectSomeValuesFrom( course Course ) )SubClassOf( Schedule ObjectSomeValuesFrom( lecturer Lecturer ) )

Verification rules NoneLimitations of themapping

Properties in OWL 2 are only binary relations Three solutions to represent ann-ary relation in OWL are presented in W3C Working Group Note [32] in a formof ontology patterns Among the proposed solutions for n-ary association weselected one the most appropriate to UML and we supplemented it by addingunlimited ldquordquo multiplicity at every association end of the UML n-ary association

Related works The transformation rules (TR1 TR2 TR5) of a n-ary association base on thepattern proposed in [32] TR3 TR4 complement the rules analogically as it isin binary associations In [15] a partial transformation for n-ary association isproposed but one rule should be modified because an object property expressionis used in the place of a class expression

Table 9 Multiplicity of association ends and the defined rules

UML element Multiplicity of Association endsDescription of UMLelement

Description of multiplicity is presented in Table 5 (multiplicity of attributes) Ifno multiplicity of association end is defined the UML specification impliesa multiplicity of 1

Symbol of UMLelementTransformation rules TR1 For each association end with the multiplicity different than ldquordquo specify

axiomSubClassOf( ClassName multiplicityExpression )

We define multiplicityExpression as one of class expressions A B C or DA an ObjectExactCardinality if UML MultiplicityElement has lower-boundequal to its upper-bound eg ldquo11rdquo which is semantically equivalent to ldquo1rdquoB an ObjectMinCardinality class expression if UML MultiplicityElementhas lower-bound of Integer type and upper-bound of unlimited upper-boundeg ldquo2rdquoC an ObjectIntersectionOf consisting of ObjectMinCardinality andObjectMaxCardinality class expressions if UML MultiplicityElement haslower-bound of Integer type and upper-bound of Integer type eg ldquo46rdquo


D an ObjectUnionOf consisting of a combination of ObjectIntersectionOfclass expressions (if needed) OR ObjectExactCardinality class expressions(if needed) OR one ObjectMinCardinality class expression (if the last rangehas an unlimited upper-bound) if UML MultiplicityElement has more valueranges specified eg ldquo2 46 89 15rdquoThe following is a result of application of TR1 to the above diagramSubClassOf( Leaf ObjectExactCardinality( 1 flower Flower ) )SubClassOf( Flower ObjectUnionOf(

ObjectExactCardinality( 2 leaf Leaf )ObjectIntersectionOf( ObjectMinCardinality( 4 leaf Leaf )ObjectMaxCardinality( 6 leaf Leaf ) ) ) )

TR2 Specify FunctionalObjectProperty axiom if a multiplicity of theassociation end equals 1FunctionalObjectProperty( flower )

Verification rules VR1 The rule is defined with the use of the SPARQL query (only applicablefor multiplicities with maximal upper-bound not equal ldquordquo)SELECT vioInd ( count ( range ) as n )WHERE vioInd leaf range GROUP BY vioIndHAVING ( n gt maxUpperBoundValue )

where maxUpperBoundValue is a maximal upper-bound value of the multiplicityrange If the query returns a number greater than 0 it means that UMLmultiplicity is in contradiction with the domain ontology (vioInd listsindividuals that cause the violation)The following is a result of application of VR1 to the above diagrammaxUpperBoundValue for flower 1SPARQL query for flower SELECT vioInd (count (range) as n)WHERE vioInd flower range GROUP BY vioIndHAVING ( n gt 1 )maxUpperBoundValue for leaf 6SPARQL query for leaf SELECT vioInd (count (range) as n)WHERE vioInd leaf range GROUP BY vioIndHAVING ( n gt 6 )VR2 Check if the domain ontology contains SubClassOf axiom whichspecifies CE with different multiplicity of association ends than is derived fromthe UML class diagramSubClassOf( Leaf CE )SubClassOf( Flower CE )

Comments to the rules 1 The TR1 TR2 and VR1 rules are explained in Table 52 Regarding TR2 The FunctionalObjectProperty axiom states that eachindividual can have a maximum of one outgoing connection of the specifiedobject property expression3 The rule VR2 verifies whether or not the ontology contains axioms whichdescribe multiplicity of association ends different than multiplicity specified inthe UML class diagram4 We have considered one additional validation rule for checking if the domainontology contains FunctionalObjectProperty axiom specified for theassociation end which multiplicity is different from 1FunctionalObjectProperty( leaf )

However after analyzing of this rule it would never be triggered This is causedby the fact that the violation of cardinality is checked by TR1 rule Andspecifying FunctionalObjectProperty axiom in the ontology along with thetransformation axiom describing cardinality different than 1 makes the ontologyinconsistent


Related works The related works present partial solutions for multiplicity of association endsIn [14181926] the multiplicity of an association end is mapped toSubClassOf axiom containing a single ObjectMinCardinality orObjectMaxCardinality class expression In [17] ObjectExactCardinalityexpression is also considered and TR2 rule is additionally proposed In[121315212224] multiplicity is only suggested to be transformed into OWLcardinality restrictions

Example Section 7 example 1 2 and 3

Table 10 Association class (the association is between two different classes) and the defined rules

UML element AssociationClass (the Association is between two different Classes)Description of UMLelement

AssociationClass [2] is both an Association and a Class and preserves thesemantics of both Table 11 presents AssociationClass in the case whenassociation is from a UML Class to itself


Transformation rules The binary association between Person and Company UML classes should betransformed to OWL in accordance with the transformations TR1 TR3ndashTR4from Table 6 The object property ranges should be specified in accordance withTR2 from Table 6 The transformation of object property domains betweenPerson and Company UML classes should be transformed with TR1 rule belowTransformation of multiplicity of the association ends are specified in Table 9The attributes of the UML association class Job should be specified inaccordance with the transformation rules presented in Table 4 If multiplicity ofattributes is specified it should be transformed in accordance with the guidelinesfrom Table 5 TR1 Specify object property domains for Association endsObjectPropertyDomain( person ObjectUnionOf( Company Job ) )ObjectPropertyDomain( company ObjectUnionOf( Person Job) )TR2 Specify declaration axiom for UML association class as OWL ClassDeclaration( Class( Job ) )TR3 Specify declaration axiom for object property of UML AssociationClassDeclaration( ObjectProperty( job ) )TR4 Specify object property domain for UML AssociationClassObjectPropertyDomain( job ObjectUnionOf( Person Company ) )TR5 Specify object property range for UML association classObjectPropertyRange( job Job )

Verification rules VR1 Check if Job class has the HasKey axiom defined in the domainontologyHasKey( Job ( OPE1 OPEm) ( DPE1 DPEn) )VR2 Check if the domain ontology contains ObjectPropertyDomain axiomspecified for a given OPE (from Association ends and AssociationClass) butdifferent CE than is derived from the UML class diagramObjectPropertyDomain( personCE )

where CE 6=ObjectUnionOf( Company Job )ObjectPropertyDomain( company CE )

where CE 6=ObjectUnionOf( Person Job )ObjectPropertyDomain( job CE )

where CE 6=ObjectUnionOf( Person Company )


VR3 Check if the domain ontology contains ObjectPropertyRange axiomspecified for the same object property of UML association class but different CEthan it is derived from the UML class diagramObjectPropertyRange( job CE ) where CE 6= Job

Comments to the rules 1 The proposed transformation of UML association class covers both thesemantics of the UML class (TR1ndashTR2 plus the transformation of attributespossibly with multiplicity) as well as UML Association (TR3ndashTR5 plus thetransformation of multiplicity of Association ends)2 Regarding TR1 and TR3 The domain of the specified property is restrictedto those individuals that belong to the union of two classes3 Explanation of VR1 is analogous to VR1 from Table 24 VR2 checks if the UML Association and AssociationClass is specifiedcorrectly with respect to the domain ontology VR3 checks if the domainontology does not specify a different range for the AssociationClass

Related works TR1 TR3ndashTR5 transformation rules of the UML association class to OWLare original propositions and the proposed transformations to OWL cover fullsemantics of the UML AssociationClassThe literature [141525] present only partial solutions for transforming UMLassociation classes In [14] it is only suggested that UML AssociationClass betransformed with the use of the named class (here Job) and two functionalproperties that demonstrate associations (here JobndashPerson and JobndashCompany)In [1525] some rules are with an unclear notation more preciselyAssociationClass is transformed to OWL with the use of TR2 rule and a set ofmappings which base on a specific naming convention


Table 11 Association class (the Association is from a UML Class to itself) and the defined rules

UML element AssociationClass (the Association is from a UML Class to itself)Description of UMLelement

AssociationClass [2] is both an Association and a Class and preserves thesemantics of both Table 10 presents AssociationClass in the case whenassociation is between two different classes


Transformation rules All comments presented in Table 10 in TR section are applicable also forAssociationClass where association is from a UML Class to itself AdditionallyTR5 from Table 7 has to be specifiedTransformation rules TR1 TR2 TR3 and TR5 are the same as TR1 TR2TR3 and TR5 from Table 10 Except for TR4 which has formTR4 Specify object property domain for UML AssociationClassObjectPropertyDomain( employment Job )

Verification rules VR1 and VR3 The same as VR1 and VR3 from Table 10VR2 Check if the domain ontology contains ObjectPropertyDomain axiomspecified for a given OPE (from Association ends and AssociationClass)but different CE than is derived from the UML class diagramObjectPropertyDomain( boss CE )

where CE 6=ObjectUnionOf( Job Employment )ObjectPropertyDomain( worker CE )

where CE 6=ObjectUnionOf( Job Employment )ObjectPropertyDomain( employment CE ) where CE 6= Job


Comments to the rules The same as presented in Table 10Related works The same as presented in Table 10

53 Transformation of UML generalization relationship

Table 12 Generalization between classes and the defined rules

UML element Generalization between ClassesDescription of UMLelement

Generalization [2] defines specialization relationship between Classifiers In caseof UML classes it relates a more specific Class to a more general Class

Symbol of UMLelementTransformation rules TR1 Specify SubClassOf( CE1 CE2 ) axiom for the generalization between

UML classes where CE1 represents a more specific and CE2 a more generalUML ClassSubClassOf( Manager Employee )

Verification rules VR1 Check if the domain ontology contains SubClassOf( CE2 CE1 ) axiomspecified for classes which take part in the generalization relationship whereCE1 represents a more specific and CE2 a more general UML ClassSubClassOf( Employee Manager )

Related works In [1517ndash1921ndash2325ndash2729] TR1 is specified In [1213] generalizations areonly suggested to be transformed to OWL with the use of SubClassOf axiom


Table 13 Generalization between associations and the defined rules

UML element Generalization between AssociationsDescription of UMLelement

Generalization [2] defines specialization relationship between Classifiers In caseof the UML associations it relates a more specific Association to more generalAssociation


Transformation rules TR1 Specify two SubObjectPropertyOf( OPE1 OPE2 ) axioms for thegeneralization between UML Association where OPE1 represents a more specificand OPE2 a more general association end connected to the same UML ClassSubObjectPropertyOf( manages works )SubObjectPropertyOf( boss employee )

Verification rules VR1 Check if the domain ontology contains SubObjectPropertyOf( OPE2OPE1 ) axiom specified for associations which take part in the generalizationrelationship where OPE1 represents a more specific and OPE2 a more generalUML association end connected to the same UML ClassSubObjectPropertyOf( works manages )SubObjectPropertyOf( employee boss )

Related works In [151718262729] TR1 rule is proposed additionally with twoInverseObjectProperties axioms (one for each association) This table doesnot add a transformation rule for InverseObjectPropertie axioms becausethe axioms were already added while transforming binary associations (seeTables 6 7



Table 14 GeneralizationSet with incomplete disjoint constraints and the defined rules

UML element GeneralizationSet with incomplete disjoint constraintsDescription of UMLelement

UML GeneralizationSet [2] groups generalizations incomplete and disjointconstraints indicate that the set is not complete and its specific Classes have nocommon instances


Transformation rules TR1 Specify DisjointClasses axiom for every pair of more specific Classes inthe GeneralizationDisjointClasses( Dog Cat )

Verification rules VR1 Check if the domain ontology contains any of SubClassOf( CE1 CE2 )or SubClassOf( CE2 CE1 ) axioms specified for any pair of more specificClasses in the GeneralizationSubClassOf( Dog Cat )SubClassOf( Cat Dog )

Comments to the rules 1 TR and VR for Generalization between UML Classes are specified inTable 122 Regarding TR1 the DisjointClasses( CE1 CE2 ) axiom states that noindividual can be at the same time an instance of both CE1 and CE2 for CE1 6=CE2

Related works In [151729] TR1 rule is proposed

Table 15 GeneralizationSet with complete disjoint constraints and the defined rules

UML element GeneralizationSet with complete disjoint constraintsDescription of UMLelement

UML GeneralizationSet [2] is used to group generalizations complete anddisjoint constraints indicate that the generalization set is complete and itsspecific Classes have no common instances


Transformation rules TR1 Specify DisjointUnion axiom for UML Classes within theGeneralizationSetDisjointUnion( Person Man Woman )

Verification rules VR1 Check if the domain ontology contains SubClassOf( CE1 CE2 ) orSubClassOf( CE2 CE1 ) axioms specified for any pair of more specific Classesin the GeneralizationSubClassOf( Man Woman )SubClassOf( Woman Man )VR2 Check if the domain ontology contains DisjointUnion( C CE1 CEN )axiom specified for the given more general UML Class (here Person) and atleast one more specific UML Class different than those specified on the UMLclass diagram


DisjointUnion( Person CE1 CEN )Comments to the rules 1TR and VR for Generalization between UML Classes are specified in

Table 122 VR2 checks if the GeneralizationSet with complete disjoint constraints isdefined correctly with respect to domain ontology

Related works In [151729] TR1 is proposedExample Section 7 example 2

Table 16 GeneralizationSet with incomplete overlapping constraints and the defined rules

UML element GeneralizationSet with incomplete overlapping constraintsDescription of UMLelement

UML GeneralizationSet [2] is used to group generalizations incomplete andoverlapping constraints indicate that the generalization set is not complete andits specific Classes do share common instances If no constraints ofGeneralizationSet are specified incomplete overlapping are assigned as defaultvalues ([2 p 119])


Transformation rules NoneVerification rules VR1 Check if the domain ontology contains DisjointClasses( CE1 CE2 )

axiom specified for any pair of more specific Classes in the GeneralizationDisjointClasses( ActionMovie HorrorMovie )

Comments to the rules 1 TR and VR for Generalization between UML Classes are specified inTable 122 OWL follows Open World Assumption and by default incomplete knowledgeis assumed hence the UML incomplete and overlapping constraints ofGeneralizationSet do not add any new knowledge to the ontology so no TR arespecified3 UML overlapping constraint states that specific UML Classes in theGeneralization do share common instances Therefore the DisjointClassesaxiom is a verification rule VR1 for the constraint (the axiom assures that noindividual can be at the same time an instance of both classes)

Related works None

Table 17 GeneralizationSet with complete overlapping constraints and the defined rules

UML element GeneralizationSet with complete overlapping constraintsDescription of UMLelement

UML GeneralizationSet [2] is used to group generalizations complete andoverlapping constraints indicate that the generalization set is complete and itsspecific Classes do share common instances



Transformation rules TR1 Specify EquivalentClasses axiom for UML Classes within theGeneralizationSetEquivalentClasses( User ObjectUnionOf( Root RegularUser ) )

Verification rules VR1 Check if the domain ontology contains DisjointClasses( CE1 CE2 )axiom specified for any pair of more specific Classes in the GeneralizationDisjointClasses( Root RegularUser )VR2 Check if the domain ontology contains EquivalentClasses axiomspecified for the given more general UML Class (here User) andObjectUnionOf containing at least one UML Class different than specified onthe UML class diagram for the more specific classesEquivalentClasses( User ObjectUnionOf( CE1CEN ) ) whereObjectUnionOf( CE1CEN ) 6=ObjectUnionOf( Root RegularUser )

Comments to the rules 1 TR and VR for Generalization between UML Classes are specified inTable 122 Explanation for VR1 is presented in Table 163 VR2 checks if the GeneralizationSet with complete overlapping constraintis compliant with the domain ontology

Related works In [15] TR1 rule is defined with additional DisjointClasses( Dog Cat )axiom However the DisjointClasses axiom should not be specified for theUML Classes which may share common instances

54 Transformation of UML data types

Table 18 Primitive types and the defined rules

UML element PrimitiveTypeDescription of UMLelement

The UML PrimitiveType [2] defines a predefined DataType without anysubstructure The UML specification [2] predefines five primitive types StringInteger Boolean UnlimitedNatural and Real

Symbol of UMLelementTransformation rules It is impossible to define unambiguously the transformation of UML String and

UML Real type therefore the decision on the final transformation is left to themodeller The proposed transformations for the two types base on theirsimilarity in UML 25 and OWL 2 languagesThe transformation between UML predefined primitive types and OWL 2datatypesTR1 UML String has only a similar OWL 2 type xsdstringString types in the sense of UML and OWL are countable sets It is possible todefine an infinite number of equivalence functions which is left to the userwherein the UML is imprecise as to what the accepted characters areTR2 UML Integer has an equivalent OWL 2 type xsdintegerTR3 UML Boolean has an equivalent OWL 2 type xsdbooleanTR4 UML Real has two similar OWL 2 types xsdfloat and xsddoubleBoth UML and OWL 2 languages describe types that are subsets of the set of


real numbers The subsets are countable If one accepts a 32 or 64-bit precisionof UML Real type they will obtain an appropriate compatibility with OWL 2xsdfloat or xsddouble typesTR5 UML UnlimitedNatural can be explicitly defined in OWL 2 asDatatypeDefinition( UnlimitedNatural

DataUnionOf( xsdnonNegativeIntegerDataOneOf( lowastandandxsdstring ) ) )

Verification rules NoneComments to the rules The UML specification [2] on page 717 defines the semantics of five predefined

PrimitiveTypes The specification of OWL 2 [30] also offers predefined datatypes(many more than UML)TR1 An instance of UML String [2] defines a sequence of characters Charactersets may include non-Roman alphabets On the other hand OWL 2 supportsxsdstring defined in XML Schema [33] The value space of xsdstring [33] isa set of finite-length sequences of zero or more characters that match the Charproduction from XML where Char is any Unicode character excluding thesurrogate blocks FFFE and FFFF The cardinality of xsdstring is defined ascountably infinite Due to the fact that the ranges of characters differ UMLString and OWL 2 xsdstring are only similar datatypesTR2 An instance of UML Integer [2] is a value in the infinite set of integers( minus2minus1 0 1 2 ) OWL 2 supports xsdinteger defined in XML Schema[33] The value space of xsdinteger is an infinite set minus2minus1 0 1 2 The cardinality is defined as countably infinite The UML Integer and OWL 2xsdinteger types can be seen as equivalentTR3 An instance of UML Boolean [2] is one of the predefined values true andfalse OWL 2 supports xsdboolean defined in XML Schema [33] whichrepresents the values of two-valued logic true false The lexical space ofxsdboolean is a set of four literals rsquotruersquo rsquofalsersquo rsquo1rsquo and rsquo0rsquo but the lexicalmapping for xsdboolean returns true for rsquotruersquo or rsquo1rsquo and false for rsquofalsersquo or rsquo0rsquoTherefore the UML Boolean and xsdboolean types can be seen as equivalentTR4 An instance of UML Real [2] is a value in the infinite set of real numbersTypically [2] an implementation will internally represent Real numbers usinga floating point standard such as ISOIECIEEE 605592011 whose content isidentical [2] to the predecessor IEEE 754 standard On the other hand OWL 2supports xsdfloat and xsddouble which are defined in XML Schema [33]The xsdfloat [33] is patterned after the IEEE single-precision 32-bit floatingpoint datatype IEEE 754-2008 and the xsddouble [33] after the IEEEdouble-precision 64-bit floating point datatype IEEE 754-2008 The value spacecontains the non-zero numbers mtimes 2e where m is an integer whose absolutevalue is less than 253 for xsddouble (or less than 224 for xsdfloat) and e isan integer between minus1074 and 971 for xsddouble (or between minus149 and 104for xsdfloat) inclusive Due to the fact that the value spaces differ UML Realand OWL 2 xsddouble (or xsdfloat) are only similar datatypesTR5 An instance of UML UnlimitedNatural [2] is a value in the infinite set ofnatural numbers (0 1 2 ) plus unlimited The value of unlimited is shownusing an asterisk (lsquorsquo) UnlimitedNatural values are typically used [2] to denotethe upper-bound of a range such as a multiplicity unlimited is used wheneverthe range is specified as having no upper-bound The UML UnlimitedNatural canbe defined in OWL and added to the ontology as a new datatype (TR5)

Related works The related works are not precise with respect to the transformation of primitivetypes In [1727ndash29] some mappings of UML and OWL types are onlymentioned



Table 19 Structured data types and the defined rules

UML element Structured DataTypeDescription of UMLelement

The UML structured DataType [2] has attributes and is used to define complexdata types


Transformation rules TR1 Specify declaration axiom for UML data type as OWL classDeclaration( Class( FullName ) )TR2 Specify declaration axiom(s) for attributes ndash as OWL data or objectproperties respectively (see Table 4 for more information regarding attributes)Declaration( DataProperty( firstName ) )Declaration( DataProperty( secondName ) )TR3 Specify data (or object) property domains for attributesDataPropertyDomain( firstName FullName )DataPropertyDomain( secondName FullName )TR4 Specify data (or object) property ranges for attributes (OWL 2 datatypesfor UML primitive types are defined in Table 18)DataPropertyRange( firstName xsdstring )DataPropertyRange( secondName xsdstring )TR5 Specify HasKey axiom for the UML data type expressed in OWL withthe use of a class uniquely identified by the data andor object propertiesHasKey( FullName ( ) ( firstName secondName) )

Verification rules VR1 Check if the domain ontology contains DataPropertyDomain axiomspecified for DPE where CE is different than given UML structured DataTypeDataPropertyDomain( firstName CE ) where CE 6= FullNameDataPropertyDomain( secondName CE )

where CE 6= FullNameVR2 Check if the domain ontology contains DataPropertyRange axiomspecified for DPE where CE is different than given UML PrimitiveTypeDataPropertyRange( firstName DR ) where DR 6=xsdstringDataPropertyRange( secondName DR )

where DR 6=xsdstringComments to the rules 1 UML DataType [2] is a kind of Classifier whose instances are identified only

by their values All instances of a UML DataType with the same value areconsidered to be equal [2] A similar meaning can be assured in OWL with theuse of HasKey axiom The HasKey axiom [30] assures that each instance ofthe class expression is uniquely identified by the object andor data propertyexpressions2 VR1 checks whether the data properties indicate that the UML attributesare correct for the specified UML structured DataType3 VR2 checks whether the data properties indicate that the UML attributes ofthe specified UML structured DataType have correctly specified PrimitiveTypes


Due to the fact that we define the UML structure DataType as an OWL Classand not as an OWL Datatype (see Section 63 for further explanation) thepresented transformation results in some consequences A limitation is posed bythe fact that the instances of the UML DataType are identified only by theirvalue [2] while the TR1 rule opens a possibilityof explicitly defining the named instances for the Entity in OWL

Related works In [2829] TR1ndashTR5 rules and in [15] TR2ndashTR5 rules are proposed for thetransformation of UML structured DataType In [17] it is only noted that UMLDataTypes can be defined in OWL with the use of DatatypeDefinition axiom


but no example is provided The related works specify exclusively the dataproperties as attributes of the structured data types in TR2 We extend thestate-of-the-art TR2 transformation rule by the possibility of defining alsoobject properties wherever needed (see Table 4)


Table 20 Enumeration and the defined rules

UML element EnumerationDescription of UMLelement

UML Enumerations [2] are kinds of DataTypes whose values correspond to oneof user-defined literals


Transformation rules TR1 Specify declaration axiom for UML Enumeration as OWL DatatypeDeclaration( Datatype( VisibilityKind ) )TR2 Specify DatatypeDefinition axiom including the named Datatype(here VisibilityKind) with a data range in a form of a predefined enumeration ofliterals (DataOneOf)DatatypeDefinition( VisibilityKind

DataOneOf( public private protected package ) )Verification rule VR1 Check if the list of user-defined literals in the Enumeration on the class

diagram is correct and complete with respect to the OWL datatype definition forVisibilityKind included in the domain ontologyThe SPARQL querySELECT literal VisibilityKind owlequivalentClass dt

dt a rdfsDatatype owloneOfrdfrestlowastrdffirst literal

returns a list of literals of the enumeration from the domain ontology The list ofliterals should be compared with the list of user-defined literals on the classdiagram if the UML Enumeration includes a correct and complete list of literals


Enumerations [2] in UML are specializations of a Classifier and therefore canparticipate in generalization relationships OWL has no construct allowing forgeneralization of datatypes See Section 63 for further explanation

Related works In [17202829] UML Enumeration is transformed to OWL with the use ofTR1ndashTR2 rules

55 Transformation of UML comments

Table 21 Comment and the defined rules

UML element Comment to the ClassDescription of UMLelement

In accordance with [2] every kind of UML Element may own Comments whichadd no semantics but may represent information useful to the reader In OWL itis possible to define the annotation axiom for OWL Class DatatypeObjectProperty DataProperty AnnotationProperty andNamedIndividual The textual explanation added to UML Class is identifiedas useful for conceptual modelling [7] therefore the Comments that areconnected to UML Classes are taken into consideration in the transformation


Symbol of UMLelementTransformation rules TR1 Specify annotation axiom for UML Comment

AnnotationAssertion( rdfscommentClass Class description andandxsdstring )

Verification rule Not applicableComments to the rule As UML Comments add no semantics they are not used in any method of

semantic validation [1] In OWL the AnnotationAssertion [30] axiom doesnot add any semantics either and it only improves readability

Related works The transformation of UML Comments in the context of mapping to OWL hasnot been found in literature

6 Influence of UMLndashOWL differenceson transformations

Obviously OWL 2 and UML 25 languages differfrom each other

In general notice that OWL ontologies arebased on the Open World Assumption whileUML class diagrams are based on Closed WorldAssumption We can compare a UML class dia-gram to a given OWL ontology assuming thatthis ontology is in a given state Examining thatthe UML class diagram conforms to the OWL on-tology we transform the diagram into equivalentOWL representation and check if this representa-tion forms a subset of the ontology So the notionof semantic equivalence relates only to the UMLclass diagram and its OWL representation

The further part of the section focuses exclu-sively on two selected differences which influencethe form of transformations

61 Instances

OWL 2 defines several kinds of axioms declara-tions axioms about classes axioms about objectsand data properties datatype definitions keysassertions (used to state that individuals areinstances of eg class expressions) and axiomsabout annotations What can be observed is thatthe information about classes and their instances(in OWL called individuals) coexists within a sin-gle ontology

On the other hand in UML two differentkinds of diagrams are used in order to present theclasses and objects UML defines object diagramswhich represent instances of class diagrams at

a certain moment in time The object diagramsfocus on presenting attributes of objects andrelationships between objects

Despite the fact that information about theobjects is not present in UML class diagramsverification rules in the form of SPARQL queriestake advantage of the knowledge about individu-als in the domain ontology The rules are useful invalidation of class diagrams against the selecteddomain ontologies as they can check for exam-ple if an abstract class is indeed abstract (doesnot have any direct instances in ontology) or ifmultiplicity restrictions are specified correctly

62 Disjointness in OWL 2 and UML

In OWL 2 an individual can be an instance ofseveral classes [34] It is also possible to statethat no individual can be an instance of selectedclasses which is called class disjointness Theinformation that some specific classes are dis-joint is part of domain knowledge which servesa purpose of reasoning

OWL specification emphasises [34] In prac-tice disjointness statements are often forgottenor neglected The arguable reason for this couldbe that intuitively classes are considered dis-joint unless there is other evidence By omittingdisjointness statements many potentially usefulconsequences can get lost

What can be observed in typical ex-isting OWL ontologies axioms of disjoint-ness (DisjointClasses DisjointObjectProp-erties and DisjointDataProperties) arestated for classes object properties or data prop-erties only for the most evident situations If


disjointness is not specified the semantics ofOWL states that the ontology does not containenough information that disjointness takes placeFor example it is possible that the informationis actually true but it has not been included inthe ontology

On the other hand in a UML class diagramevery pair of UML classes (which are not withinone generalization set with an overlapping con-straint) is disjoint where disjointness is under-stood in the way that the classes have no commoninstances This aspect of UML semantics could bemapped to OWL with the use of an extensive setof additional transformations The transforma-tions would not be intuitive from the perspectiveof OWL and should add a lot of unnecessaryinformation which might never be useful due tothe fact that eg one should consider every pairof classes on the diagram and add additionalaxioms for it

For the purpose of completeness of our revi-sion below we present transformation rules alsofor disjointnessndash Transformation rule for disjointness of UML

classes ( TRA ) Specify DisjointClassesaxiom for every pair of UML Classes CE1CE2 where CE1 6= CE2 and the pair is notin the generalization relation or within onegeneralization set with an overlapping con-straint Comment The TRA rule for classeswithin a generalization relationship was orig-inally proposed in [17 18 20] We have re-fined the rule in order to cover only thepairs of classes which are not only in a directgeneralization relation but also not withinone GeneralizationSet with an overlappingconstraint This is caused by the fact thatthe GeneralizationSet with the overlappingconstraint (see Tables 16ndash17) defines spe-cific Classes which do share common in-stances Please note that UML Generaliza-tionSet with disjoint constraint adds Dis-jointClasses axioms ndash either directly or in-directly through DisjointUnion axiom (seeTables 14ndash15)

ndash Transformation rule for disjointness of UMLattributes (TRB) Specify DisjointObject-

Properties axiom for every pair OPE1OPE2 where OPE1 6= OPE2 of object prop-erties within the same UML Class (domainof both OPE1 and OPE2 is the same OWLClass) and specify DisjointDataProper-ties axiom for every pair DPE1 DPE2 whereDPE1 6= DPE2 of object properties withinthe same UML Class (domain of both DPE1and DPE2 is the same OWL Class)Comment The TRB rule is original proposi-tion

ndash Transformation rule for disjointness of UMLassociations ( TRC ) Specify DisjointOb-jectProperties axiom for every pair of asso-ciation ends OPE1 and OPE2 where OPE1 6=OPE2 and OPE1 is not generalized by OPE2and OPE2 is not generalized by OPE1 anddomain and range of OPE1 and OPE2 arethe same classesComment In [17 20] it is suggested thatDisjointObjectProperties and Disjoint-DataProperties axioms for all propertiesthat are not in a generalization relationshipshould be specified In a general case thissuggestion is not clear but we have modifiedthe rule to be applicable for UML associationswhich are not in generalization relationshipEven though the TRA TRB and TRC rulesare reasonable from the point of view of cov-ering semantics of a class diagram to OWLthey have not been implemented in a toolfor validation of UML class diagram [4] dueto their questionable usefulness from the per-spective of pragmatics This is caused by thefact that including these rules would leadto a large increase in the number of axiomsin the ontology which would increase thecomputational complexity

63 Concepts of class and datatypein UML and OWL

OWL 2 allows specifying declaration axioms fordatatypesDeclaration( Datatype( DatatypeName ) )

However the current specification of OWL 2[30] does not offer any constructs neither to spec-


ify the internal structure of the datatypes northe possibility to define generalization relation-ships between the datatypes Both are availablein UML 25

Please note that the OWL HasKey Data-PropertyDomain and ObjectProperty-Domain axioms can only be defined for the classexpressions (not for the data ranges) Thereforethe TR2ndashTR5 rules in Table 19 can only bespecified if the UML structured DataType isdeclared as an OWL Class This transformationhas its consequences which are presented inTable 19

If future extensions of the OWL language al-low one to precisely define the internal structureof datatypes by analogy as it is possible in UMLthe proposed transformation of UML structuredDataType presented in Table 19 should then bemodified Additionally if future extensions of theOWL language allow one to define generalizationrelationships between datatypes the currentlyvalid limitation of the transformation of UMLEnumeration presented in Table 20 will no longerbe applicable

7 Examples of UMLndashOWLtransformations

This section presents some examples of transfor-mations of UML class diagrams to their equiv-

alent OWL representations The UML class di-agram examples are relatively small but covera number of different UML elements For clarityof reading the examples include references totables from Section 5

The order of transformations is arbitrary (theresulting set of axioms will always be the samedespite the order) but we suggest to conduct thetransformations starting from Table 2 to Table 21In this way all the classes with attributes willbe mapped to OWL first then the associationsand generalization relationships and finally datatypes and comments

Each example includes two tables contain-ing transformational and verificational part ofUML class diagram (eg in Example 1 thereare two tables 22 and 23) Each verificationalpart should be considered in the context of theselected domain ontology The Table 23 whichpresents verificational part of the diagram fromExample 1 has been supplemented with addi-tional comments of how each verificational ax-iom or verificational query should be interpretedThe comments and the ontological backgroundpresented in Table 23 is also applicable to otherexamples

Example 1

Figure 1 Example 1 of UML class diagram (see Tables 22 23)


Table 22 Transformational part of UML class diagram from Example 1

Set of transformation axioms Transformation rules

Transformation of UML Classes

Declaration( Class( A ) ) Table 2 TR1Declaration( Class( B ) )Declaration( Class( C ) )Declaration( Class( D ) )

Transformation of UML binary Associations between two different Classes

Declaration( ObjectProperty( b ) ) Table 6 TR1Declaration( ObjectProperty( c ) )Declaration( ObjectProperty( cR1 ) )Declaration( ObjectProperty( dR1 ) )Declaration( ObjectProperty( cR2 ) )Declaration( ObjectProperty( dR2 ) )ObjectPropertyDomain( b C )ObjectPropertyDomain( c B )ObjectPropertyDomain( cR1 D )ObjectPropertyDomain( dR1 C )ObjectPropertyDomain( cR2 D )ObjectPropertyDomain( dR2 C )

Table 6 TR2

ObjectPropertyRange( b B )ObjectPropertyRange( c C )ObjectPropertyRange( cR1 C )ObjectPropertyRange( dR1 D )ObjectPropertyRange( cR2 C )ObjectPropertyRange( dR2 D )

Table 6 TR3

InverseObjectProperties( b c )InverseObjectProperties( cR1 dR1 )InverseObjectProperties( cR2 dR2 )

Table 6 TR4

Transformation of UML multiplicity of Association ends

SubClassOf( C ObjectExactCardinality( 5 b B ) ) Table 9 TR1SubClassOf( B ObjectUnionOf( ObjectExactCardinality( 7 c C )ObjectIntersectionOf( ObjectMinCardinality( 10 c C )ObjectMaxCardinality( 12 c C ) ) ) )SubClassOf( C ObjectExactCardinality( 1 dR1 D ) )SubClassOf( D ObjectExactCardinality( 1 cR1 C ) )SubClassOf( C ObjectExactCardinality( 1 dR2 D ) )SubClassOf( D ObjectExactCardinality( 1 cR2 C ) )FunctionalObjectProperty( dR1 )FunctionalObjectProperty( cR1 )FunctionalObjectProperty( dR2 )FunctionalObjectProperty( cR2 )

Table 9 TR2

Transformation of UML Generalization between Classes

SubClassOf( B A ) Table 12 TR1

Transformation of UML Generalization between Associations

SubObjectPropertyOf( cR2 cR1 )SubObjectPropertyOf( dR2 dR1 )

Table 13 TR1


Table 23 Verificational part of UML class diagram from Example 1

Verificational part of UML class diagram Verification rules


If the domain ontology contains any HasKey axiom with any internal structure(OPE1 DPE1 ) defined for A B C or D UML Class the element should beUML structured DataType not UML Class

Table 2 VR1

HasKey( A ( OPE1 OPEmA) ( DPE1 DPEnA) )HasKey( B ( OPE1 OPEmB) ( DPE1 DPEnB) )HasKey( C ( OPE1 OPEmC) ( DPE1 DPEnC) )HasKey( D ( OPE1 OPEmD) ( DPE1 DPEnD) )


If the domain ontology contains any of below defined AsymmetricObjectPropertyaxioms the defined UML Association is incorrectAsymmetricObjectProperty( b )AsymmetricObjectProperty( c )AsymmetricObjectProperty( cR1 )AsymmetricObjectProperty( dR1 )AsymmetricObjectProperty( cR2 )AsymmetricObjectProperty( dR2 )

Table 6 VR1

If the domain ontology contains any of the below-defined ObjectPropertyDomainaxioms where class expression is different than the given UML Class the Associationis defined in the ontology but between different Classes than it is specified on thediagram

Table 6 VR2

ObjectPropertyDomain( b CE ) where CE 6= CObjectPropertyDomain( c CE ) where CE 6= BObjectPropertyDomain( cR1 CE ) where CE 6= DObjectPropertyDomain( dR1 CE ) where CE 6= CObjectPropertyDomain( cR2 CE ) where CE 6= DObjectPropertyDomain( dR2 CE ) where CE 6= C

If the domain ontology contains any of below-defined ObjectPropertyRange axiomswhere the class expression is different than the given UML Class the Association isdefined in the ontology but between different Classes

Table 6 VR3

ObjectPropertyRange( b CE ) where CE 6= BObjectPropertyRange( c CE ) where CE 6= CObjectPropertyRange( cR1 CE ) where CE 6= CObjectPropertyRange( dR1 CE ) where CE 6= DObjectPropertyRange( cR2 CE ) where CE 6= CObjectPropertyRange( dR2 CE ) where CE 6= D


If the verification query returns a number greater than 0 it means that UML multiplicityis in contradiction with the domain ontology (vioInd lists individuals that cause theviolation)

Table 9 VR1

SELECT vioInd (count ( range ) as n )WHERE vioInd b range GROUP BY vioIndHAVING ( n gt 5 )SELECT vioInd (count ( range ) as n )WHERE vioInd c range GROUP BY vioIndHAVING ( n gt 12 )SELECT vioInd (count ( range ) as n )WHERE vioInd dR1 range GROUP BY vioIndHAVING ( n gt 1 )


SELECT vioInd (count ( range ) as n )WHERE vioInd cR1 range GROUP BY vioIndHAVING ( n gt 1 )SELECT vioInd (count ( range ) as n )WHERE vioInd dR2 range GROUP BY vioIndHAVING ( n gt 1 )SELECT vioInd (count ( range ) as n )WHERE vioInd cR2 range GROUP BY vioIndHAVING ( n gt 1 )

If the domain ontology contains FunctionalObjectProperty axiom specified for theassociation end which multiplicity is different from 1 the multiplicity is incorrectFunctionalObjectProperty( b )FunctionalObjectProperty( c )

Table 9 VR2

If the domain ontology contains SubClassOf axiom which specifies class expressionwith different multiplicity of the association ends than is derived from the UML classdiagram the multiplicity is incorrectSubClassOf( C CE ) where CE 6=ObjectExactCardinality( 5 b B )SubClassOf( B CE ) whereCE 6=ObjectUnionOf( ObjectExactCardinality( 7 c C )

ObjectIntersectionOf( ObjectMinCardinality( 10 c C )ObjectMaxCardinality( 12 c C ) ) )

SubClassOf( C CE ) where CE 6=ObjectExactCardinality( 1 dR1 D )SubClassOf( D CE ) where CE 6=ObjectExactCardinality( 1 cR1 C )SubClassOf( C CE ) where CE 6=ObjectExactCardinality( 1 dR2 D )SubClassOf( D CE ) where CE 6=ObjectExactCardinality( 1 cR2 C )

Table 9 VR3


If the domain ontology contains the defined SubClassOf axiom specified for Classeswhich take part in the generalization relationship the generalization relationship shouldbe inverted on the diagramSubClassOf( A B )

Table 12 VR1


If the domain ontology contains the defined SubObjectPropertyOf axioms specifiedfor Association which take part in the generalization relationship the generalizationrelationship should be inverted on the diagram

Table 13 VR1


Example 2

Figure 2 Example 2 of UML class diagram (see Tables 24ndash25)






Transformation of UML attributes

Declaration( DataProperty( a1 ) ) Table 4 TR1Declaration( ObjectProperty( a2 ) )DataPropertyDomain( a1 A ) Table 4 TR2ObjectPropertyDomain( a2 A )DataPropertyRange( a1 xsdinteger ) Table 4 TR3ObjectPropertyRange( a2 T ) Table 18 TR2Transformation of UML multiplicity of attributes

SubClassOf( A ObjectExactCardinality( 2 a2 T ) ) Table 5 TR1

Transformation of UML binary Association from the Class to itself

Declaration( ObjectProperty( aR1 ) )Declaration( ObjectProperty( aR2 ) ) Table 7 TR1ObjectPropertyDomain( aR1 A )ObjectPropertyDomain( aR2 A ) Table 7 TR2ObjectPropertyRange( aR1 A )ObjectPropertyRange( aR2 A ) Table 7 TR3InverseObjectProperties( aR1 aR2 ) Table 7 TR4AsymmetricObjectProperty( aR1 )AsymmetricObjectProperty( aR2 )

Table 7 TR5


SubClassOf( A ObjectExactCardinality( 1 aR1 A ) ) Table 9 TR1SubClassOf( A ObjectExactCardinality( 1 aR2 A ) )FunctionalObjectProperty( aR1 ) Table 9 TR2FunctionalObjectProperty( aR2 )Transformation of UML Generalization between Classes

SubClassOf( B A ) Table 12 TR1SubClassOf( C A )SubClassOf( D A )Transformation of UML GeneralizationSet with complete disjoint constraintsDisjointUnion( A B C D ) Table 15 TR1Transformation of UML structured DataType

Declaration( Class( T ) ) Table 19 TR1Declaration( DataProperty( t1 ) ) Table 19 TR2Declaration( DataProperty( t2 ) )DataPropertyDomain( t1 T ) Table 19 TR3DataPropertyDomain( t2 T )DataPropertyRange( t1 xsdstring ) Table 19 TR4DataPropertyRange( t2 xsdboolean ) Table 18 TR1

Table 18 TR3HasKey( T ( ) ( t1 t2 ) ) Table 19 TR5






Table 2 VR1


DataPropertyDomain( a1 CE ) where CE 6=AObjectPropertyDomain( a2 CE ) where CE 6=A

Table 4 VR1

DataPropertyRange( a1 DR ) whereDR 6=xsdinteger ObjectPropertyRange( a2 CE ) whereCE 6= T

Table 4 VR2Table 18 TR2

Transformation of UML multiplicity of attributes

SELECT vioInd (count ( range ) as n)WHERE vioInd a2 range GROUP BY vioIndHAVING ( n gt 2 )

Table 5 VR1

SubClassOf( A CE ) whereCE 6=ObjectExactCardinality( 2 a2 T )

Table 5 VR2


ObjectPropertyDomain( aR1 CE ) where CE 6= AObjectPropertyDomain( aR2 CE ) where CE 6= A

Table 7 VR1

ObjectPropertyRange( aR1 CE ) where CE 6= AObjectPropertyRange( aR2 CE ) where CE 6= A

Table 7 VR2


SELECT vioInd (count ( range ) as n) Table 9 VR1WHERE vioInd aR1 range GROUP BY vioIndHAVING ( n gt 1 )SELECT vioInd (count ( range ) as n)WHERE vioInd aR2 range GROUP BY vioIndHAVING ( n gt 1 )SubClassOf( A CE ) where CE 6=ObjectExactCardinality( 1 aR1 A )SubClassOf( A CE ) where CE 6=ObjectExactCardinality( 1 aR2 A )

Table 9 VR3


SubClassOf( A B )SubClassOf( A C )SubClassOf( A D )

Table 12 VR1

Transformation of UML GeneralizationSet with complete disjoint constraints

SubClassOf( B C )SubClassOf( C B )SubClassOf( C D )SubClassOf( D C )SubClassOf( B D )SubClassOf( D B )

Table 15 VR1


Transformation of UML structured DataType

Check if the T class is specified in the domain ontology as a subclass(SubClassOf axiom) of any class expression which does not have HasKeyaxiom defined

Table 19 VR1

Example 3





Declaration( Class( A ) )Declaration( Class( B ) )

Table 2 TR1


Declaration( ObjectProperty( d ) ) Table 4 TR1ObjectPropertyDomain( d C ) Table 4 TR2ObjectPropertyRange( d D ) Table 4 TR3


Declaration( ObjectProperty( a ) )Declaration( ObjectProperty( b ) )

Table 6 TR1

ObjectPropertyDomain( a ObjectUnionOf( B C ) )ObjectPropertyDomain( b ObjectUnionOf( A C ) )

Table 6 TR2Table 10 TR1

ObjectPropertyRange( a A )ObjectPropertyRange( b B )

Table 6 TR3

InverseObjectProperties( a b ) Table 6 TR4


SubClassOf( A ObjectMinCardinality( 2 b B ) ) Table 9 TR1

Transformation of UML AssociationClass

Declaration( Class( C ) ) Table 10 TR2Declaration( ObjectProperty( c ) ) Table 10 TR3ObjectPropertyDomain( c ObjectUnionOf( A B ) ) Table 10 TR4ObjectPropertyRange( c C ) Table 10 TR5





HasKey( A ( OPE1 OPEm) ( DPE1 DPEn) )HasKey( B ( OPE1 OPEm) ( DPE1 DPEn) )

Table 2 VR1


ObjectPropertyDomain( d CE ) where CE 6= C Table 4 VR1ObjectPropertyRange( d CE ) where CE 6= D Table 4 VR2


AsymmetricObjectProperty( a )AsymmetricObjectProperty( b )

Table 6 VR1


FunctionalObjectProperty( a )FunctionalObjectProperty( b )

Table 9 VR2

SubClassOf( A CE ) where CE 6=ObjectMinCardinality( 2 b B )SubClassOf( B CE ) where CE = any explicitly specified multiplicity

Table 9 VR3


HasKey( C ( OPE1 OPEm) ( DPE1 DPEn) ) Table 10 VR1ObjectPropertyDomain( a CE ) where CE 6=ObjectUnionOf( B C )ObjectPropertyDomain( b CE ) where CE 6=ObjectUnionOf( A C )ObjectPropertyDomain( c CE ) where CE 6=ObjectUnionOf( A B )

Table 10 VR2

ObjectPropertyRange( c CE ) where CE 6= C Table 10 VR3

8 Tool support for validationand automatic correction ofUML class diagrams

The transformation and verification rules pre-sented in Section 5 have been implemented ina tool All the defined rules are proved to be fullyimplementable As a result the tool allows oneto transform any UML class diagram built of dif-ferent kinds of UML elements (listed in Section 5and selected based on their importance from theperspective of pragmatics) to OWL 2 represen-tation In comparison to other available toolswhich allow transforming UML class diagramsto an OWL 2 representation the range of thetransformed constructions is wider as it benefitsfrom the results of the conducted systematicliterature review and its analysis revision andextension

Due to the fact that the tool is still un-der development the following webpage hasbeen created in which the tool with the in-

stallation instructions will be later accessi-ble httpssourceforgenetprojectsuml-class-diagrams-validation

After the development and experiment phasesare finished the tool will be made available on-line

The tool has been tested with a number oftest cases aimed to determine whether the toolfully and correctly implemented the transforma-tion and verification rules as well as the vali-dation method At least one test case has beenprepared for every normalization transformationand verification rule Additionally a number oftest cases have been prepared to cover popularassemblies of UML elements eg an associationfrom a class to itself an association between twoclasses two associations between two classes twoassociations between three classes etc Each rulehas been independently checked if it returns theexpected result In total the number of test caseswas as follows1 80 test cases for ontology normalization rules


2 40 test cases for transformation rules3 25 test cases for verification rulesThe tool passed all test cases

The implementation of the transformationand verification rules as well as the method ofvalidation explained in [1] resulted in a function-ality of the tool allowing for validation if a UMLclass diagram is compliant with the selected do-main ontology Furthermore on the basis of theresult of validation the tool automatically gen-erates ontology-based suggestions for diagramcorrections In [4] a few initial suggestions fordiagram corrections have been presented Theinitial list of suggestions has been revised andextended and currently the tool automaticallygenerates suggestions of two kinds1 What has to be corrected in the UML class

diagram in order for the diagram not to be

contradictory with the selected domain ontol-ogy (approximately 30 types of suggestions ndashone for violation of every verification rulesplus one general suggestion listing incorrectUML elements if a transformation rule hascaused the inconsistency in the domain ontol-ogy) This list of suggestions is reported bythe tool for the modeller and strongly advisedhis or her attention (Example 4 and 5)

2 Based on the domain ontology of what mightbe additionally included in the class diagram(9 types of suggestions) Whether or not toconsider this list of proposed suggestions isfor the modeller to decide Depending on thespecific requirements the suggestions may beincorporated in the diagram (Example 6)

Example 4

Table 28 Example of what has to be corrected in the diagram based on the ontologyabstract class verification

Suggestion the class is not abstract

Axiom(s) in the OWLdomain ontology

Declaration( Class( Town ) )ClassAssertion( Town Madrid )

Element on theUML class diagramResult of validation


Example 5

Table 29 Example of what has to be corrected in the diagram based on the ontologyenumeration verification

Suggestion the enumeration is incorrectly defined


DatatypeDefinition( AccommodationRatingDataOneOf( OneStarRating TwoStarRating ThreeStarRating

FourStarRating FiveStarRating ) )

Element on theUML class diagram

Result of validation

Example 6

Table 30 Example of what may be incorporated in the diagram based on the ontologyattribute verification

Suggestion Insert missing attribute missing type of attribute or missing multiplicity of attribute


Declaration( Class( Contact ) )ObjectPropertyDomain( person Contact )ObjectPropertyRange( person FullName )Declaration( Class( FullName ) )DataPropertyDomain( firstName FullName )DataPropertyRange( firstName xsdstring )DataPropertyDomain( secondName FullName )DataPropertyRange( secondName xsdstring )HasKey( FullName ( ) (firstName secondName ) )Declaration( DataProperty( hasEMail ) )DataPropertyDomain( hasEMail Contact )DataPropertyRange( hasEMail xsdstring )


Declaration( DataProperty( hasStreet ) )DataPropertyDomain( hasStreet Contact )DataPropertyRange( hasStreet xsdstring )Declaration( DataProperty( hasCity ) )DataPropertyDomain( hasCity Contact )DataPropertyRange( hasCity xsdstring )Declaration( DataProperty( lastUpdate ) )DataPropertyDomain( lastUpdate Contact )DataPropertyRange( lastUpdate xsddateTime )SubClassOf( Contact DataExactCardinality( 1 lastUpdate ) )


Legendwhite rows ndash suggestions of UML elements which might be included in the class diagramgrey rows ndash UML elements already included in the class diagram

9 Conclusions

The paper presents rules for transforming UMLclass diagrams to their OWL 2 representationsAll the static elements of UML class diagramscommonly used in business or conceptual mod-elling have been considered The vast majority ofthe elements can be fully transformed to OWL 2constructs The presented transformation rulesresult from an in-depth analysis and extensionof the state-of-the-art transformation rules iden-tified through a systematic literature review Intotal 41 transformation rules have been described(not counting our complementation to the rules ofdisjointness presented in Section 6) 25 transforma-tion rules have been directly extracted from the lit-erature 8 rules originate in the literature but havebeen extended by us in order to reflect the seman-tics of UML elements in OWL more precisely and8 transformation rules are our new propositions

In addition to the transformation rules wehave defined all the presented verification rules(26 in total) The verification rules are aimedat checking the compliance of the OWL repre-sentation of UML class diagram with the givenOWL domain ontology The described transfor-mation and verification rules are crucial in themethod of semantic validation of UML class dia-grams [1] The approach validates automaticallyif a selected class diagram is compliant with theselected OWL 2 domain ontology

The developed method and the tool area pragmatic attempt of bringing together thedifferences in the philosophy of UML and OWL 2languages In order to make the process auto-matic the tool has been supplemented with allthe transformation and verification rules andhas been tested with a wide range of test casesThe inclusions to the tool are the result of prag-matic thinking For example the implementa-


tion allowed observing that it is worth extend-ing the tool so that it automatically generatesontology-based suggestions for diagram correc-tions

The tool already offers a range of new possi-bilities for practical application of domain ontolo-gies However as a consequence the proposedapproach creates a need for greater involvementof domain ontologies in modeling

The research background of our considera-tions can be supported by other publications eg[35ndash37] The potential of reusing domain ontolo-gies for the purpose of validation is promising andmay help the modelers through automation Thechoice of OWL is justified by the growing numberof the already created ontologies in this languageFor future work the development of the tool isplanned to be finished soon The next step ofwork is preparation of experiment aimed at val-idation of the tool and the method in practiceThe experiment is aimed to state the practicalityof our proposal

References

[1] M Sadowska and Z Huzar ldquoSemantic validationof UML class diagrams with the use of domainontologies expressed in OWL 2rdquo in SoftwareEngineering Challenges and Solutions SpringerInternational Publishing 2016 pp 47ndash59

[2] Unified Modeling Language Version 25 OMG2015 [Online] httpwwwomgorgspecUML25

[3] OWL 2 Web Ontology Language DocumentOverview (Second Edition) W3C 2012 [Online]httpswwww3orgTRowl2-overview

[4] M Sadowska ldquoA prototype tool for semanticvalidation of UML class diagrams with the useof domain ontologies expressed in OWL 2rdquo inTowards a Synergistic Combination of Researchand Practice in Software Engineering SpringerInternational Publishing 2017 pp 49ndash62

[5] M Sadowska and Z Huzar ldquoThe method of nor-malizing OWL 2 DL ontologiesrdquo Global Journalof Computer Science and Technology Vol 18No 2 2018 pp 1ndash13

[6] A Korthaus ldquoUsing UML for business objectbased systems modelingrdquo in The Unified Mod-eling Language Physica-Verlag HD 1998 pp220ndash237

[7] HE Eriksson and M Penker Business Model-ing With UML Business Patterns at Work NewYork USA John Wiley amp Sons inc 2000

[8] ED Nitto L Lavazza M Schiavoni E Tra-canella and M Trombetta ldquoDeriving executableprocess descriptions from UMLrdquo in Proceedingsof the 24th International Conference on SoftwareEngineering ser ICSE rsquo02 New York NY USAACM 2002 pp 155ndash165

[9] C Fu D Yang X Zhang and H Hu ldquoAn ap-proach to translating OCL invariants into OWL2 DL axioms for checking inconsistencyrdquo Auto-mated Software Engineering Vol 24 No 2 2017pp 295ndash339

[10] B Kitchenham and S Charters ldquoGuidelines forperforming systematic literature reviews in soft-ware engineeringrdquo Keele University amp Univer-sity of Durham EBSE Technical Report EBSE2007-01 2007

[11] X Zhou Y Jin H Zhang S Li and X HuangldquoA map of threats to validity of systematic liter-ature reviews in software engineeringrdquo in 23rdAsia-Pacific Software Engineering Conference(APSEC) IEEE 2016 pp 153ndash160

[12] Z Xu Y Ni W He L Lin and Q YanldquoAutomatic extraction of OWL ontologies fromUML class diagrams a semantics-preserving ap-proachrdquo World Wide Web Vol 15 No 5 2012pp 517ndash545

[13] Z Xu Y Ni L Lin and H Gu ldquoA seman-tics-preserving approach for extracting OWL on-tologies from UML class diagramsrdquo in DatabaseTheory and Application ser Communicationsin Computer and Information Science BerlinHeidelberg Springer 2009 pp 122ndash136

[14] M Mehrolhassani and A Elccedili ldquoDeveloping on-tology based applications of semantic web usingUML to OWL conversionrdquo in The Open Knowl-ege Society A Computer Science and Informa-tion Systems Manifesto ser Communicationsin Computer and Information Science BerlinHeidelberg Springer 2008 pp 566ndash577

[15] O El Hajjamy K Alaoui L Alaoui and M Ba-haj ldquoMapping UML to OWL2 ontologyrdquo Jour-nal of Theoretical and Applied Information Tech-nology Vol 90 No 1 2016 pp 126ndash143

[16] C Zhang ZR Peng T Zhao and W LildquoTransformation of transportation data modelsfrom Unified Modeling Language to Web Ontol-ogy Languagerdquo Transportation Research RecordJournal of the Transportation Research BoardVol 2064 No 1 2008 pp 81ndash89

[17] J Zedlitz J Joumlrke and N Luttenberger ldquoFromUML to OWL 2rdquo in Knowledge Technology ser


Communications in Computer and InformationScience Berlin Heidelberg Springer 2012 pp154ndash163

[18] AH Khan and I Porres ldquoConsistency of UMLclass object and statechart diagrams using on-tology reasonersrdquo Journal of Visual Languagesamp Computing Vol 26 2015 pp 42ndash65

[19] AH Khan I Rauf and I Porres ldquoConsistencyof UML class and statechart diagrams with stateinvariantsrdquo in Proceedings of the 1st Interna-tional Conference on Model-Driven Engineeringand Software Development S Hammoudi LFPires J Filipe and RC das Neves Eds Vol 1SciTePress Digital Library 2013 p 1ndash11

[20] J Zedlitz and N Luttenberger ldquoTransformingbetween UML conceptual models and OWL 2ontologiesrdquo in Terra Cognita 2012 WorkshopVol 6 2012 p 15

[21] W Xu A Dilo S Zlatanova and P van Oost-erom ldquoModelling emergency response processesComparative study on OWL and UMLrdquo inProceedings of the Joint ISCRAM-CHINA andGI4DM Conference Harbin China 2008 pp493ndash504

[22] N Gherabi and M Bahaj ldquoA new methodfor mapping UML class into OWL ontologyrdquoInternational Journal of Computer ApplicationsSpecial Issue on Software Engineering Databasesand Expert Systems Vol SEDEXS No 1 2012pp 5ndash9 [Online] httpsresearchijcaonlineorgsedexnumber1sedex1002pdf

[23] HS Na OH Choi and JE Lim ldquoA method forbuilding domain ontologies based on the transfor-mation of UML modelsrdquo in Fourth InternationalConference on Software Engineering ResearchManagement and Applications (SERArsquo06) DKBaik D Primeaux N Ishii and R Lee EdsIEEE 2006 pp 332ndash338

[24] M Bahaj and J Bakkas ldquoAutomatic conversionmethod of class diagrams to ontologies maintain-ing their semantic featuresrdquo International Jour-nal of Soft Computing and Engineering Vol 2No 6 2013 pp 65ndash69

[25] A Belghiat and M Bourahla ldquoTransforma-tion of UML models towards OWL ontologiesrdquoin 2012 6th International Conference on Sci-ences of Electronics Technologies of Informa-tion and Telecommunications (SETIT) 2012 pp840ndash846

[26] S Houmlglund AH Khan Y Liu and I PorresldquoRepresenting and validating metamodels usingOWL 2 and SWRLrdquo in Proceedings of the 9th

Joint Conference on Knowledge-Based SoftwareEngineering 2010

[27] K Kiko and C Atkinson ldquoA detailed com-parison of UML and OWLrdquo University ofMannheim Fakultaumlt fuumlr Mathematik und In-formatik Lehrstuhl fuumlr Softwaretechnik TechRep TR-2008-004 2008

[28] J Zedlitz and N Luttenberger ldquoData types inUML and OWL-2rdquo in The Seventh InternationalConference on Advances in Semantic Processing2013 pp 32ndash35

[29] J Zedlitz and N Luttenberger ldquoConceptualmodelling in UML and OWL-2rdquo InternationalJournal on Advances in Software Vol 7 No 1amp 2 2014 pp 182ndash196

[30] OWL 2 Web Ontology Language Struc-tural Specification and Functional-Style Syn-tax (Second Edition) W3C 2012 [Online]httpswwww3orgTRowl2-syntax

[31] OWL 2 Web Ontology Language New Featuresand Rationale (Second Edition) W3C 2012[Online] httpswwww3orgTRowl2-new-features

[32] N Noy and A Rector Defining N-ary Relationson the Semantic Web W3C 2006 [Online] httpswwww3orgTRswbp-n-aryRelations

[33] W3C XML Schema Definition Language (XSD)11 Part 2 Datatypes W3C 2012 [Online]httpswwww3orgTRxmlschema11-2

[34] OWL 2 Web Ontology Language Primer(Second Edition) W3C 2012 [Online]httpswwww3orgTRowl2-primer

[35] I Dubielewicz B Hnatkowska Z Huzar andL Tuzinkiewicz ldquoDomain modeling in thecontext of ontologyrdquo Foundations of Computingand Decision Sciences Vol 40 No 1 2015pp 3ndash15 [Online] httpscontentsciendocomviewjournalsfcds401article-p3xml

[36] B Hnatkowska Z Huzar L Tuzinkiewicz andI Dubielewicz ldquoA new ontology-based approachfor construction of domain modelrdquo in Intelli-gent Information and Database Systems NTNguyen S Tojo LM Nguyen and B TrawińskiEds Cham Springer International Publishing2017 pp 75ndash85

[37] I Dubielewicz B Hnatkowska Z Huzar andL Tuzinkiewicz ldquoDomain modeling based onrequirements specification and ontologyrdquo inSoftware Engineering Challenges and SolutionsL Madeyski M Śmiałek B Hnatkowska andZ Huzar Eds Cham Springer InternationalPublishing 2017 pp 31ndash45

Introduction

Class diagrams in business and conceptual modelling

Review process

Research question

Data sources and search queries

Inclusion and exclusion criteria

Study quality assessment

Study selection

Threats to validity

Related work

Search results

Summary of identified literature

UML class diagram and its OWL 2 representation

Transformation of UML classes with attributes

Transformation of UML associations

Transformation of UML generalization relationship

Transformation of UML data types

Transformation of UML comments

Influence of UMLndashOWL differences on transformations

Instances

Disjointness in OWL 2 and UML

Concepts of class and datatype in UML and OWL

Examples of UMLndashOWL transformations

Example 1

Example 2

Example 3

Tool support for validation and automatic correction of UML class diagrams

Example 4

Example 5

Example 6

Conclusions

References


should be corrected on the basis of the ontologyA necessary requirement before the UML classdiagram can be validated with the use of OWLdomain ontology is that the diagram and theontology must follow one agreed domain vocab-ulary Moreover the domain ontology must beconsistent because it is the knowledge base forthe area

Our research is limited to the static elementsof UML class diagrams ndash the behavioural aspectrepresented by class operations is omitted Thisis due to the fact that the semantics of UML op-erations cannot be effectively expressed with theuse of OWL 2 constructs which do not representbehaviour In order to identify which transforma-tion rules of UML class diagrams into OWL con-structs have already been proposed we have per-formed a systematic review of literature The ex-tracted rules have been analysed compared andextended The resulting findings of how to con-duct the transformation of UML class diagram toits OWL 2 representation are described furtherin this paper In the rest of this paper OWLalways means OWL 2 if not stated otherwise

Besides the transformation rules the methodof semantic validation of UML class diagrams re-quires the so called verification rules This aspectis an original element of this research Transform-ing the UML elements to OWL may introducesome new properties that may be in conflict withthe ontology The verification rules are specifiedin the form of either OWL verification axioms orverification queries

It is then checked that the verification axiomsare not present in the domain ontology becauseif they are included the diagram is contradictoryto the domain knowledge In other words wecan say that the verification axioms detect if thesemantics of the diagram transformation is com-pliant with the axioms included in the domainontology Considering the inverse transformation(from the ontology to the diagram) the presenceof the verification axioms in the domain ontol-ogy means that the reengineering transformationwould remain in conflict with the semantics ofthe UML class diagram In [1] we presented someexamples of the consequences of a reengineering

transformation of OWL to UML which does nottake into account the verification rules

Verification queries are used for extractinginformation from a domain ontology the kind ofinformation that could not be provided throughinspecting the class diagram itself The domainontology can have more information regardingthe elements of a UML class diagram whichis not explicitly expressed on the diagram Forexample the ontology can contain informationabout individuals To give a more detailed per-spective the verification queries are used for (a)checking if the classes denoted as abstract in theUML class diagram do not have any individualsassigned in the OWL domain ontology (b) verify-ing if the multiplicity (of both the attributes andthe association ends) is not violated on the sideof the OWL domain ontology and (c) checkingif the user-defined list of literals of the specifiedenumerations on the UML class diagram is com-pliant with those defined in the OWL domainontology Technically all verification queries aredefined with the use of SPARQL1 language

The verification of UML class diagrams withthe use of the proposed method is possible thanksto the initial normalization of the domain ontol-ogy and the normalization of the transformationaxioms The concept of OWL ontology normal-ization is our proposition [5] Any input OWL 2DL ontology after normalization is presented ina new but semantically equivalent form becausethe normalization rules only change the structurebut do not affect the semantics of axioms or ex-pressions in the OWL 2 ontology The normalizedOWL 2 DL ontologies have a unified structure ofaxioms so that they can be algorithmically com-pared without the need to conduct additionalcomplex calculations The extensive details ofconducting the transformation of OWL 2 ontolo-gies to their normalized form are described in [5]In the rest of the paper OWL domain ontology isunderstood as OWL domain ontology after nor-malization (it should be done only once) Beforecomparison of axioms all transformation axiomsare also normalized (tool automatically savestransformation axioms also in the normalizedform so that no additional delay is needed in

1SPARQL Query Language httpswwww3orgTRsparql11-overview



















3 Review process



















35 Study selection















4 Related work

41 Search results







2006 [23]2008 [14162127]2009 [13]2010 [26]2012 [1217202225]2013 [192428]2014 [29]2015 [18]2016 [15]





































OWL 2 constructs





lowing prefixes




UML element Class









































































































































































Related works None

































































61 Instances





























Example 1









Table 6 TR2


Table 6 TR3


Table 6 TR4



Table 9 TR2





Table 13 TR1






Table 2 VR1




Table 6 VR1


Table 6 VR2



Table 6 VR3




Table 9 VR1





Table 9 VR2




Table 9 VR3



Table 12 VR1



Table 13 VR1


Example 2












Table 7 TR5











Table 2 VR1



Table 4 VR1





Table 5 VR1


Table 5 VR2



Table 7 VR1


Table 7 VR2



Table 9 VR3



Table 12 VR1



Table 15 VR1




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References



















3 Review process



















35 Study selection















4 Related work

41 Search results







2006 [23]2008 [14162127]2009 [13]2010 [26]2012 [1217202225]2013 [192428]2014 [29]2015 [18]2016 [15]





































OWL 2 constructs





lowing prefixes




UML element Class









































































































































































Related works None

































































61 Instances





























Example 1









Table 6 TR2


Table 6 TR3


Table 6 TR4



Table 9 TR2





Table 13 TR1






Table 2 VR1




Table 6 VR1


Table 6 VR2



Table 6 VR3




Table 9 VR1





Table 9 VR2




Table 9 VR3



Table 12 VR1



Table 13 VR1


Example 2












Table 7 TR5











Table 2 VR1



Table 4 VR1





Table 5 VR1


Table 5 VR2



Table 7 VR1


Table 7 VR2



Table 9 VR3



Table 12 VR1



Table 15 VR1




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References










35 Study selection















4 Related work

41 Search results







2006 [23]2008 [14162127]2009 [13]2010 [26]2012 [1217202225]2013 [192428]2014 [29]2015 [18]2016 [15]





































OWL 2 constructs





lowing prefixes




UML element Class









































































































































































Related works None

































































61 Instances





























Example 1









Table 6 TR2


Table 6 TR3


Table 6 TR4



Table 9 TR2





Table 13 TR1






Table 2 VR1




Table 6 VR1


Table 6 VR2



Table 6 VR3




Table 9 VR1





Table 9 VR2




Table 9 VR3



Table 12 VR1



Table 13 VR1


Example 2












Table 7 TR5











Table 2 VR1



Table 4 VR1





Table 5 VR1


Table 5 VR2



Table 7 VR1


Table 7 VR2



Table 9 VR3



Table 12 VR1



Table 15 VR1




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References





4 Related work

41 Search results







2006 [23]2008 [14162127]2009 [13]2010 [26]2012 [1217202225]2013 [192428]2014 [29]2015 [18]2016 [15]





































OWL 2 constructs





lowing prefixes




UML element Class









































































































































































Related works None

































































61 Instances





























Example 1









Table 6 TR2


Table 6 TR3


Table 6 TR4



Table 9 TR2





Table 13 TR1






Table 2 VR1




Table 6 VR1


Table 6 VR2



Table 6 VR3




Table 9 VR1





Table 9 VR2




Table 9 VR3



Table 12 VR1



Table 13 VR1


Example 2












Table 7 TR5











Table 2 VR1



Table 4 VR1





Table 5 VR1


Table 5 VR2



Table 7 VR1


Table 7 VR2



Table 9 VR3



Table 12 VR1



Table 15 VR1




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References


































OWL 2 constructs





lowing prefixes




UML element Class









































































































































































Related works None

































































61 Instances





























Example 1









Table 6 TR2


Table 6 TR3


Table 6 TR4



Table 9 TR2





Table 13 TR1






Table 2 VR1




Table 6 VR1


Table 6 VR2



Table 6 VR3




Table 9 VR1





Table 9 VR2




Table 9 VR3



Table 12 VR1



Table 13 VR1


Example 2












Table 7 TR5











Table 2 VR1



Table 4 VR1





Table 5 VR1


Table 5 VR2



Table 7 VR1


Table 7 VR2



Table 9 VR3



Table 12 VR1



Table 15 VR1




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References





lowing prefixes




UML element Class









































































































































































Related works None

































































61 Instances





























Example 1









Table 6 TR2


Table 6 TR3


Table 6 TR4



Table 9 TR2





Table 13 TR1






Table 2 VR1




Table 6 VR1


Table 6 VR2



Table 6 VR3




Table 9 VR1





Table 9 VR2




Table 9 VR3



Table 12 VR1



Table 13 VR1


Example 2












Table 7 TR5











Table 2 VR1



Table 4 VR1





Table 5 VR1


Table 5 VR2



Table 7 VR1


Table 7 VR2



Table 9 VR3



Table 12 VR1



Table 15 VR1




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References



























































































































































Related works None

































































61 Instances





























Example 1









Table 6 TR2


Table 6 TR3


Table 6 TR4



Table 9 TR2





Table 13 TR1






Table 2 VR1




Table 6 VR1


Table 6 VR2



Table 6 VR3




Table 9 VR1





Table 9 VR2




Table 9 VR3



Table 12 VR1



Table 13 VR1


Example 2












Table 7 TR5











Table 2 VR1



Table 4 VR1





Table 5 VR1


Table 5 VR2



Table 7 VR1


Table 7 VR2



Table 9 VR3



Table 12 VR1



Table 15 VR1




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References






























































61 Instances





























Example 1









Table 6 TR2


Table 6 TR3


Table 6 TR4



Table 9 TR2





Table 13 TR1






Table 2 VR1




Table 6 VR1


Table 6 VR2



Table 6 VR3




Table 9 VR1





Table 9 VR2




Table 9 VR3



Table 12 VR1



Table 13 VR1


Example 2












Table 7 TR5











Table 2 VR1



Table 4 VR1





Table 5 VR1


Table 5 VR2



Table 7 VR1


Table 7 VR2



Table 9 VR3



Table 12 VR1



Table 15 VR1




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References





















Example 1









Table 6 TR2


Table 6 TR3


Table 6 TR4



Table 9 TR2





Table 13 TR1






Table 2 VR1




Table 6 VR1


Table 6 VR2



Table 6 VR3




Table 9 VR1





Table 9 VR2




Table 9 VR3



Table 12 VR1



Table 13 VR1


Example 2












Table 7 TR5











Table 2 VR1



Table 4 VR1





Table 5 VR1


Table 5 VR2



Table 7 VR1


Table 7 VR2



Table 9 VR3



Table 12 VR1



Table 15 VR1




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References








Table 6 TR2


Table 6 TR3


Table 6 TR4



Table 9 TR2





Table 13 TR1






Table 2 VR1




Table 6 VR1


Table 6 VR2



Table 6 VR3




Table 9 VR1





Table 9 VR2




Table 9 VR3



Table 12 VR1



Table 13 VR1


Example 2












Table 7 TR5











Table 2 VR1



Table 4 VR1





Table 5 VR1


Table 5 VR2



Table 7 VR1


Table 7 VR2



Table 9 VR3



Table 12 VR1



Table 15 VR1




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References






Table 2 VR1




Table 6 VR1


Table 6 VR2



Table 6 VR3




Table 9 VR1





Table 9 VR2




Table 9 VR3



Table 12 VR1



Table 13 VR1


Example 2












Table 7 TR5











Table 2 VR1



Table 4 VR1





Table 5 VR1


Table 5 VR2



Table 7 VR1


Table 7 VR2



Table 9 VR3



Table 12 VR1



Table 15 VR1




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References




Table 9 VR2




Table 9 VR3



Table 12 VR1



Table 13 VR1


Example 2












Table 7 TR5











Table 2 VR1



Table 4 VR1





Table 5 VR1


Table 5 VR2



Table 7 VR1


Table 7 VR2



Table 9 VR3



Table 12 VR1



Table 15 VR1




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References











Table 7 TR5











Table 2 VR1



Table 4 VR1





Table 5 VR1


Table 5 VR2



Table 7 VR1


Table 7 VR2



Table 9 VR3



Table 12 VR1



Table 15 VR1




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References






Table 2 VR1



Table 4 VR1





Table 5 VR1


Table 5 VR2



Table 7 VR1


Table 7 VR2



Table 9 VR3



Table 12 VR1



Table 15 VR1




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References




Table 19 VR1

Example 3






Table 2 TR1





Table 6 TR1




Table 6 TR3











Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References






Table 2 VR1





Table 6 VR1



Table 9 VR2


Table 9 VR3



Table 10 VR2














Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References







Example 4







Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References


Example 5








Example 6









9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References





9 Conclusions








References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References





References









































Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References
























Introduction


Review process

Research question




Study selection

Threats to validity

Related work

Search results









Instances




Example 1

Example 2

Example 3


Example 4

Example 5

Example 6

Conclusions

References

representation of uml class diagrams in owl 2 on the ... · representation of uml class diagrams in...

Documents