Transformation of the UML model into derivative artefacts
Introduction
Publications Office of the European Union set off to build an eProcurement ontology well motivated in [costetchi2020a, p.5-9]. The ultimate objective of the project is to put forth a commonly agreed ontology that will conceptualise, formally encode and make available in an open, structured and machine-readable format data about public procurement, covering end-to-end procurement, i.e. from notification, through tendering to awarding, ordering, invoicing and payment .
The process and the methodology adopted involve modelling the conceptual model in Unified Modelling Language (UML) [uml2.5] and then, by abiding a set of conventions and recommendations, transform that model into a formal ontology expressed in Web Ontology Language (OWL) .
This document provides a working definition of the transformation rules from the UML conceptual model into the formal ontology and validation data shapes. These rules are organised in accordance with the eProcurement ontology architecture [costetchi2020a, p.21-27].
State of the art
Much has been written about correspondences and between and transformation from UML to OWL and vice versa [sadowska2019]. The most significant literature on this topic was published between 2006 and 2019 comprising three book chapters, nine journal papers and multiple conference papers.
The work presented in [khan2015] transforms into OWL some selected elements of UML models containing multiple UML class, object and state-chart diagrams in order to analyse consistency of the models. A similar approach is presented in [khan2013], which is focused on detecting inconsistency in models containing UML class and state-chart diagrams.
The papers [hajjamy2016], [zedlitz2012], [zedlitz2014] investigate the differences and similarities between UML and OWL in order to present transformations of selected (and identified as useful) elements of UML class diagram. In [zedlitz2014conceptual], the need for UML–OWL transformation is additionally motivated by not repeating the modelling independently in both languages.
The paper [kiko2008] compares OWL abstract syntax elements to the equivalent UML features and appropriate OCL statements. The analysis is conducted in the direction from OWL to UML. For every OWL construct its UML interpretation is proposed.
The works presented in [xu2012], [xu2009], [na2006] are focused on extracting ontological knowledge from UML class diagrams and describe some UML–OWL mappings with the aim to reuse the existing UML models and stream the building of OWL domain ontologies.
In [sadowska2019] is presented a comprehensive review of the related work. We use it as a guideline for ensuring the necessary coverage of the transformation rules specified in this report. It is important to note here that all the UML elements are treated here, but only the ones employed in the eProcurement conceptual model.
How to read this document
The reminder of this document comprises four sections covering major UML aspects. Section Transformation of UML classes and attributes treats classes and attributes. Following section deals with the main connector types employed in the eProcurement model, namely: associations, dependencies and generalisations. Section #sec:tran-rules3 explains how the datatypes and enumerations should be transformed and, finally, Section #sec:tran-rules4 provides a few transformation rules that are applicable to all UML elements and are concerned with comments, labels and notes.
Each section provides a table with overview of the transformation rule set comprised within. The table provides three columns, one for every layer of the ontology architecture comprising rules: (a) , (b) , and (c) .
Transformation rules are specified in a normative language and are aided by prototypical UML diagram fragments (usually preceding the rule) along with representation of the corresponding OWL fragment depicted in Graffoo visual notation [graffoo]. The diagrams are provided side to side in order to increase comprehension, with UML fragment on the left constituting the source of the transformation and the OWL fragment on the right representing the final result of the transformation.
Each transformation rule is accompanied by the formal OWL representation, in Turtle [turtle] and RDF/XML syntaxes [rdf-xml-syntax-spec] [rdf1.1-xml-syntax], corresponding to the depicted UML fragment from the preceding figure. RDF/XML is a syntax to express RDF graphs as an XML document. Turtle is a textual syntax for RDF that is compact and resembles a natural text form with abbreviations for common usage patterns and datatypes.
UML visual notation
This section provides the main UML elements employed in this document. A detailed description can be consulted in the standard specifications [uml2.5] and in the UML user guide [uml-userguide].
Figure 1 depicts simple, abstract and regular classes with and without attribute specifications. Note that no class methods are ever employed as this document as the transformations aim at data structures only.
Figure 2 depicts a primitive datatype and an enumeration. No complex datatypes are depicted as they are treated in the same manner as classes are.
Figure 3 depicts association, generalisation and dependency connectors as the only ones necessary to model the eProcurement conceptual model.
Graffoo visual notation
This section provides the main Graffoo elements employed in this document. A detailed description can be consulted in the OWL standard specifications [owl2] and in the Graffoo user guide [graffoo].
A yellow rectangle with solid black border is used to declare classes. Solid black and labelled arrows are used to declare class axioms. A green rhomboid with solid black border is used to declare datatypes. Solid black and labelled arrows are used to declare class axioms.
A pink circle with solid black border is used to declare individuals. Solid black and labelled arrows are used to declare axioms and assertions among individuals.
A green solid line is used to declare data properties, where the empty circle at the beginning identifies the property domain while the empty arrow at the end indicates the property range. A blue solid line is used to declare object properties, where the solid circle at the beginning identifies the property domain while the solid arrow at the end indicates the property range.
The following sections present the transformation rules necessary for converting the UML eProcurement conceptual model into a formal OWL ontology.