Deriving OWL Ontologies from UML Models: an Enterprise Modelling Approach. Dr. Sergio Viademonte, Dr. Zhan Cui. British Telecom, GCTO Adastral Park, Ipswich IP5 3RE, UK sergio.viademontedarosa@bt.com zhan.cui@bt.com Abstract. The work described in this paper concentrates on providing semantic descriptions into enterprise models, in order to promote system interoperability, and in particular, enterprise information integration and retrieval. Therefore, the paper presents an empirical work, the conversion of enterprise models described through the Unified Modelling Language (UML), into Ontologies, encoded in the Web Ontology Language (OWL). The paper discusses the mappings and the mains aspects of the implementation from UML to OWL. Keywords: Enterprise modelling, enterprise interoperability, semantic for enterprise modelling, UML and ontology. 1 Introduction This paper describes an empirical work, the conversion of enterprise models described through the Unified Modelling Language (UML) [1], into Ontologies, encoded in the Web Ontology Language (OWL) [2]. The communications service providers (CSPs) constitute a highly competitive, changeable and networked industry. CSPs companies face the challenge of providing services meanwhile adapting to incorporate new technologies, exploring new business opportunities and dealing with aggressive new entrants in the market [3]. Therefore the industry is seeking to create flexible business processes, and providing integrated services to attend a higher demand for sophisticated and often customised services. From an information system s point of view, this leads to an enterprise modelling approach; designing information systems that represent business entities and process, and how they interoperate. Model driven architecture has been applied as the paradigm for system development for many industries. Model Driven Architecture (MDA) constitutes an approach for software engineering which emphasizes abstraction modelling of entities and processes [4], applying the UML as it modelling standard. Although UML s powerful modelling capabilities, it lacks features for richer semantic descriptions, for example to describe types of services a specific model provides, how to communicate with such model and kinds of data a model consumes. Incorporating semantic descriptions into models enrich the understandability of such models, providing more
Dr. Sergio Viademonte, Dr. Zhan Cui. information than the ones purely related to software engineering aspects. This brings several advantages such as promoting systems interoperability, data and process mediation, enterprise information integration and also facilitates dynamic discovery of services, in service oriented platforms [5]. Ontologies have been explored as a modelling approach that enhances the semantic capabilities of classical UML based models [6][7]. Regarding its powerful modelling capabilities, ontologies can describe business entities, types of services, data they consume and provide, promoting systems interoperability [8]. British Telecom (BT) has been engaged in the development of a comprehensive model of its core businesses, according to the MDA approach. The Common Capability Model (CCM) has been developed as part of this effort. The CCM is an enterprise model developed as part of the enterprise system architecture which provides the technical platform of business process and entities, containing around 13 systems platforms. This paper describes the conversion of the CCM from its UML representation into ontology, written in OWL. It gives an introduction to the CMM, describes the UML elements that needed to be represented in the ontology, and the mapping elements in the OWL. This section, Introduction, discusses the context in which the work described in this paper has been developed, it briefly contextualizes the challenges facing the CSPs industry and how these challenges impact enterprise information systems development. Section 2, introduces the BT s capability model. Following, Section 3 discusses some related work in mapping UML models onto Ontologies. Section 4 presents the conversion between the CCM into OWL, the defined crosswalks (mappings) and their implementation. Finally, Section 6 discusses some of the lessons learned during the development of this work, and Section 5 presents our conclusions, as well as future directions in the subjects covered in this project. 2 The Capability Model This section aims to give an introduction about the BT s Capability Model, in order to facilitate the clarity of this paper; readers interested in detailed discussion about CCM should refer to [9]. The CCM basically consists of sets of reusable blocks of business functionality the platforms which encapsulate related applications and data, exposed through a standard interface [9]. The capability model has been developed within the context of the service oriented architecture (SOA); platforms can expose service capabilities based on the CCM, which can be understood by consumer of those capabilities in the organization. Figure 2.1 shows an excerpt of the CCM (in UML) model, illustrating part of the Party class diagram and its respective attributes and associations.
Deriving OWL Ontologies from UML Models: an Enterprise Modelling Approach. Fig. 2.1. Part of Party class UML diagram. Party class represents the abstract concept of organisation or individual person that can play different roles during interactions with an enterprise. Therefore, Party class is sub classed into Person and Organisation classes, with respective attributes and methods (which express classes functionality). For instance, it can be observed in Figure 2.1 that Organisation has the attributes businessunitid, businessunitname, and industrytype. Also, class Person has attributes such gender, maritalstatus and nationality. Organisation class is associated to OrganisationName class, through a has association, in similar way, Person class is associated to PersonName class through a has association. The whole CCM model consists of around 350 classes, each with definition, key attributes and named associations. The core concepts are represented through packages, each one being based on a cluster of classes and the associations between them, representing business concepts, such as Portfolio, Resource, Activities, Finance, HR, Business Operations, Events and Market. The conversion of CCM into an Ontology based model aims to provide a semantic model, supporting domain modelling (enterprise model), architectural design, and interoperability aspects.
Dr. Sergio Viademonte, Dr. Zhan Cui. 3 Related Works OWL was the chosen ontology representation language for the CCM. OWL is a semantic markup language (XML based) for publishing and sharing ontologies on the World Wide Web [10], which provides a vocabulary to represent classes, classes hierarchies, associations between classes and properties, therefore suitable to represent UML models. The OWL has been developed based on XML [10], RDF and RDF Schema [11] technologies; however it provides a richer vocabulary than RDF for describing properties and classes [2]. There are various works related to transformations between UML and OWL [12][13], UML and DAML+OIL [14][15] and also between UML and OWL S [16][7]. There are also works in the subject of object oriented representation of ontologies, producing both Java classes and RDF schema [17]. And also works about mapping UML class diagrams into XML, as a means to define data interchange formats. Most of the works about converting UML models into ontologies concern in providing semantic capabilities for web services, e.g. semantic web services. Other works, such as the one presented by [18] relates to aspects of software engineering, facilitating software design from conceptual models. In contrast, the work presented in this paper relates to enterprise information integration and interoperability, therefore, emphasis has been taken in describing elements that could be mapped into database structures, such as class associations, attributes and respective data types. Next Section discusses the conversion of CCM UML representation into OWL ontology. 4 Converting Enterprise Models into OWL Ontology The work presented in this paper reports an empirical work related to incorporating semantic capabilities into enterprise models, which are designed through UML and the converted into OWL ontologies. Therefore, the purpose and contributions of this work lay in the definition of crosswalks [19][20] between UML and OWL vocabularies, and the development of a software component to automatically perform this conversion. The work presented in this paper does not aim an extensive mapping of all OWL language constructs, but the UML elements contained in the CMM models. 4.1 Defining the Crosswalks between UML and OWL One of the first activities in our work was to identify which UML elements needed to be converted, and then to identify the semantically corresponding OWL elements. Table 4.1 enumerates the identified UML elements and its correspondent OWL constructs. The defined crosswalks were grounded in the works of [15][18] which discusses the similarities between UML, ontology languages and Java, and also in the specific needs of the application it has been designed for, e.g., information integration.
Deriving OWL Ontologies from UML Models: an Enterprise Modelling Approach. Table 4.1 Crosswalks between UML and OWL The identified UML elements were: classes and subclasses (hierarchies of generalization and specialization), class s attributes, including attribute s names and datatypes (string, integer, or other classes), and class associations. Associations include the direction of the association, it means, the source and target classes, besides association s names. As illustrated in Table 4.1, an UML class is converted into the element owl:class, class s names are identified by the owl:class rdf:id attribute. Alternatively, class names are also encoded in the rdfs:label tag (this is to facilitate search) within the owl:class tagged expression. UML hierarchies of generalization and specialization are encoded within the rdfs:subclassof element, with names encoded through rdf:resource attribute. Figure 4.1 illustrates the OWL encoding of Organisation class, taken from the OWL Party ontology. <owl:class rdf:id="organisation"> <rdfs:label>organisation</rdfs:label> <rdfs:subclassof rdf:resource="#party"/> </owl:class> Fig. 4.1 OWL class Figure 4.1 illustrates Organisation class as a sub class of Party class, through the OWL element rdfs:subclassof rdf:resource which value is Party. An OWL class is shown in a similar fashion as an UML class, with the exception that ontologies typically do not specify class behaviour; therefore class s methods are not converted into OWL.
Dr. Sergio Viademonte, Dr. Zhan Cui. Class s attributes are encoded into OWL s owl:datatypeproperty element. Attribute s names are identified by the owl:datatypeproperty rdf:id attribute, names are also encoded in the rdfs:label tag within the owl:datatypeproperty tagged expression. Figure 4.2 shows the OWL encoding for the businessunitid attribute, in the Organisation class. <owl:datatypeproperty rdf:id="businessunitid"> <rdfs:label>businessunitid</rdfs:label> <rdfs:domain rdf:resource="#organisation"/> <rdfs:range rdf:resource="#xsd:int"/> </owl:datatypeproperty> Fig. 4.2 OWL class attributes Datatype property has two elements, rdfs:domain and rdfs:range. The rdsf:domain element, combined with its rdf:resource attribute, indicates the class the attribute is associated to. Figure 4.2 illustrates the businessunitid attribute related to Organisation class. Similarly, the rdfs:range element indicates the datatype property of the attribute, in Figure 4.2, businessunitid is a numeric integer. OWL uses XML Schema datatypes (http://www.w3.org/2001/xmlschema) to represent attribute datatypes. Besides XML Schema datatypes, different schemas can be used, but they need to be refereed in the original UML document. Additionally, rdfs:range rdf:resource can have a class name as its value, indicating that the respective attribute is composed by instances of that class. Associations are encoded into OWL s owl:objectproperty element, association names are identified by the value of the owl:objectproperty rdf:id attribute. Similarly to class and attribute names, association names are also encoded into rdfs:label tag within the owl:objectproperty tagged expression. Figure 4.3 illustrates the OWL encoding for has association, between Organisation and OrganisationName classes. <owl:objectproperty rdf:id="has"> <rdfs:label>has</rdfs:label> <rdfs:domain rdf:resource="#organisation"/> <rdfs:range rdf:resource="#organisationname"/> </owl:objectproperty> Fig. 4.3 OWL class association The source class of an association is identified by the element attribute pair rdfs:domain rdf:resource, and the target class by the element attribute pair rdfs:range rdf:resource. Figure 4.3 illustrates the has association, in which the source class is Organisation and target class is OrganisationName.
Deriving OWL Ontologies from UML Models: an Enterprise Modelling Approach. 4.2 Mapping aspects from XMI to OWL The capability model has been designed under Borland Together, a visual modelling tool for software architecture design (www.borland.com/us/products/together). Borland Together provides means of exporting UML diagrams into a standard XMLbased format, the XML Metadata Interchange Language (XMI) [21], which is a XML integration schema for interchanging XML data. Therefore, the implementation effort was concentrated in identifying and implementing the mappings between the XMI UML elements and the OWL elements, as listed in Table 4.1. These mappings are discussed next. Table 4.2 presents the crosswalks from the UML class element encoded in XMI to OWL. Table 4.2. Crosswalks for Class element. Class element is mapped from the UML:Class element into OWL:Class, with the name attribute mapped into the OWL Class rdf:id attribute and rdfs:label element, as shown in Table 4.2. The hierarchies of generalization/specialization, represented by the rdfs:subclassof element in OWL, correspond in XMI to the UML:Generalization element, and its sub elements UML:Generalization.parent, GeneralizableElement and its attribute xmi.idref. As illustrates in Table 4.2, the xmi.idref = 'S.X' attribute value corresponds to the code of the super class, therefore it is necessary to scan the XML document to find the class name of the element UML:Class, in which the attribute Class xmi.id matches the value S.X'. The owl:datatypeproperty and rdfs:label elements correspond to the value of the name attribute in the UML:Attribute element. Table 4.3 shows the crosswalks between the XMI UML:Attribute and owl:datatypeproperty. The OWL rdfs:domain rdf:resource element, inside a DatatypeProperty tagged expression, indicates the class to which the attribute belongs to. Therefore, it is necessary to locate the specific UML:Class, element and retrieve the value of its name attribute, in which the UML:Attribute described by the DatatypeProperty element is nested in. This is the class name to which this attribute belongs to. The OWL element rdfs:range rdf:resource indicates the datatype of an attribute, such as "XMLSchema#string" (or a class name if this attribute is a class instance). This information is encoded in the XMI UML:DataType element, xmi:id and name attributes (refer to Table 4.3), where the value of UML:DataType element xmi:id
Dr. Sergio Viademonte, Dr. Zhan Cui. attribute match the value of UML:Attribute element type attribute. The value of UML:DataType element, name attribute corresponds to the data type of the attribute. Table 4.3 illustrates this mapping. Table 4.3 Crosswalks for Datatype Property element The next elements to be discussed are class associations, which are encoded in OWL by the ObjectProperty element. Table 4.4 presents this crosswalk, the owl:objectproperty element corresponds to the XMI UML:Association element and associated sub elements. The owl:objectproperty rdf:id attribute and the rdfs:label element are encoded through the XMI UML:Association name attribute, where the name attribute holds the association name. Table 4.4 Crosswalks for Object Property element Classes involved in an association are encoded in XMI through the nested elements Association.connection, AssociationEnd, AssociationEnd.participant and Classifier, where the xmi.idref attribute from Classifier element holds the identifier of the class participant in the association. It is necessary to scan the XML document and locate
Deriving OWL Ontologies from UML Models: an Enterprise Modelling Approach. the UML:Class elements where its xmi.id attribute value matches the value of (Classifier) xmi.idref, then retrieve the value of the name attribute, from this UML:Class element. The source class of an association is represented by the first instance of the UML:Classifier element, nested inside the UML:Association tags in the XML document; target classe(s), are represented by the remaining instances of UML:Classifier, nested inside the Association.connection element. In OWL, class associations are encoded within the rdfs:domain and rdfs:range elements and their respective rdf:resource attribute, inside an owl:objectproperty tagged expression. XMI is a fairly complex XML schema; it is not in the scope of this paper a detailed discussion about XMI and its vocabulary. Also, it needs to be taken into account that each particular software tool could generate slightly different vocabularies of a XMI document. In case of the work presented in this paper, it addresses the XMI version 1.1 generated by Borland Together tool, the UML version is 1.3, as defined by the OMG [22]. 4.3 Implementation The conversion from UML encoded in XMI to OWL, as previously described, was implemented through the Extensible Stylesheet Language for Transformations (XSLT) [23]. XSLT provides a XML grammar for processing XML documents. Additionally, Java API for XML processing (JAXP) [24] has been applied to implement more complex data manipulation. As a simple example, Figure 4.4 illustrates part of the XSLT implemented to convert the UML/XMI into OWL. It illustrates the crosswalk implementation of Class element. Fig. 4.4 Part of XSLT converting Class element According to Figure 4.4, the XSLT scans the XMI document identifying all UML:Class elements (second line in Figure 4.4), for each of them it retrieves the value of name attribute through the xsl:value of select statement. The XSLT then generates the owl:class element, assigning the value of (UML:Class) name attribute into (owl:class) rdf:id attribute and rdfs:label element. Figure 4.5 illustrates part of the resulting ontology from an excerpt of the model showed in Figure 2.1.
Dr. Sergio Viademonte, Dr. Zhan Cui. Fig. 4.5 OWL describing Person class Figure 4.5 illustrates part of the OWL representation of Person class, its attributes gender and dataofbirth, and the has association between Person and PersonName classes, according to the mappings described in section 4.1 and 4.2, in this paper. 5 Some Lessons Learned The work discussed in this paper constitutes an empirical effort, aiming to explore the feasibility and benefits of incorporating semantic into business model, and its further applications. It has been developed as part of the data fusion platform of BT, which aims to facilitate enterprise information integration and retrieval, and system interoperability. As a first approach, we concentrated in defining and implementing the crosswalks between UML and OWL, resulting in a preliminary ontology which represents business entities modelled through UML. UML seems to be a natural starting point from where to build ontologies from business model, as it is one of the most used standards for modelling enterprise information systems. Specifically about the mappings definition between UML and OWL, some crosswalks present semantic inconsistencies. For example UML associations and OWL properties, UML associations are encoded through OWL ObjectProperty, which allows the existence of properties with null range and domain elements. This is not possible in UML, as each association needs to be linked through classes (even association between instances of the same class) [15]. Crosswalks can be defined and implemented in a software engineering point of view; however their semantic correspondence may not always be preserved. Some OWL property restriction s crosswalks showed to be complex to define, such as functional property (owl:functionalproperty) and inverse functional property
Deriving OWL Ontologies from UML Models: an Enterprise Modelling Approach. (owl:inversefunctionalproperty), as they do not have a direct correspondence in UML. Also, OWL defines cardinality constrains (owl:cardinality, owl:maxcardinality and owl:mincardinality), which constraint on the number of values a property can assume; and value constraints (owl:allvaluesfrom, owl:hasvalue, owl:sameas), which constraint the range of a particular class description. Naturally, OWL cardinality constrains seems to be most accurate way of defining UML cardinality constraints, although value constrains can also be applied in some cases, therefore the decision on how to encode these elements depends on specific applications, rather than a general rule. Others difficulties found during the development of this work relates to the conversion from UML/XMI into OWL, this showed to be a significant complex tasks, subject to specific UML modelling tools (in this case Borland Together). It was necessary to hard code specific features, subject to specific software platform, XML encoding versions and namespaces as well, therefore it is difficult to achieve a more general solution. It is also necessary to take into account the discrepancies among distinct APIs for ontology processing and ontology editors. For example, an OWL ontology generated through Protégé (http://protege.stanford.edu.) may have different language constructs than an ontology using Swoop editor (http://code.google.com/p/swoop/) and an ontology generated through Jena API (http://jena.sourceforge.net/index.html). Each of those environments may apply specific OWL constructs that need to be taken into account during the implementation phase. For instance, the owl:objectproperty rdf:id element attribute that is generated through our XSLT, when edited with Jena API, it is replaced by owl:objectproperty rdf:about. Replacing the attribute rdf:id by rdf:about does not affect the semantic meaning of the document, but may lead to errors when scanning and processing the XML document. 6 Conclusions This paper describes an empirical work, which is the conversion of an enterprise model, the CCM, modelled through the Unified Modelling Language (UML), into Ontologies, encoded in Web Ontology Language (OWL). The purposes of the work described in this paper is to provide semantic descriptions of business model to facilitate system interoperability, and in particular, enterprise information integration and retrieval The paper gives and introduction about the CCM, discusses the crosswalks from UML into OWL, and presents the mains aspects of the implementation from the UML representation in XMI to OWL. Our experience during the development of this work indicates that the automatic provision of semantic models, leads to problems related to metadata interoperability, even within same standards, such as OWL. As future directions of this work, the developed ontologies need to be enhanced with additional descriptions. For instance, OWL class restrictions and cardinality constrains were already identified and needs to be included. The immediate application of this work was information search and retrieval; therefore, the resulting ontologies were mapped to relational database model, facilitating data search and retrieval from corporate databases. Different purposes may
Dr. Sergio Viademonte, Dr. Zhan Cui. require different semantic information, this brings issues of investigation which semantic information would be interesting in an ontology describing business model like the CCM, besides the ones representing the UML vocabulary, and how to describe such information. OWL was the chosen ontology language in this work; an interesting topic for future investigation would be a comparative analysis using other ontology language, such as Web Services Modelling Ontology [25]. There are many metadata standards, but most of them are industry specific, therefore this raises the problem of developing more generic metadata standards for interoperability. More specific to BT purposes, issues for future research on which services could be built around a CCM semantic layer and how to move towards a federation of (smart) services deployed over BT s SOA. Bibliography 1. Booch, G., Rumbaugh, J. and Jacobson, I. (1999). The Unified Modeling Language User Guide. Reading, MA, Addison Wesley. ISBN 0 201 57168 4. 2. W3C, Word Wide Web Consortium (2004a). OWL Web Ontology Language Reference. W3C Recommendation, 10 February (2004). http://www.w3.org/tr/2004/rec owl ref 20040210/ (Last accessed February 2008). 3. Duke A, Richardson M, (2006). A Semantic Service Oriented Architecture for the Telecommunications Industry, Ed. Davies J, Studer R, Warren P, John Wiley & Sons, Ltd. England; 2006. p. 281 299. 4. Souza, D. (2001). Model Driven Architecture and Integration Opportunities and Challenges. Object Management Group, OMG. Online access: www.omg.org/mda/mda_files/mdafaqfinal1.pdf 5. Paul, A. (2006). Service Orientation, winning strategies and best practices. Cambridge, UK: Cambridge University Press. ISBN 13 978 0 521 84336 2. 6. Gasevic, D., Djuric, D. and Devedzic, V. (2006a). Model Driven Architecture and Ontology Development. Springer Verlag, Germany. 7. Grønmo, R., Jaeger, M.C., and Hoff, H. (2005). Transformations between UML and OWL S. Springer Verlag. Proceedings of the European Conference on Model Driven Architecture Foundations and Applications (ECMDA FA), Nuremberg, Germany. November 2005. 8. OMG, Object Management Group (2003). Model Driven Architecture MDA Guide V1.0.1. http://www.omg.org/mda/. 9. Levy, B. (2005). The common capability approach to new service development. BT Technology Journal, Volume 23, N. 1. Springer Netherlands. January 2005. 10. W3C, Word Wide Web Consortium (2004b). XML Extensible Markup Language 1.0 (Third Edition). Recommendation, 04 February, 2004. Available at: http://www.w3.org/tr/2004/rec xml 20040204/. Accessed April, 2006. 11. W3C, World Wide Web Consortium (2002). Resource Description Framework (RDF): Concepts and Abstract Syntax. Submission, 08 November, 2002. Available online at: http://www.w3.org/tr/2002/wd rdf concepts 20021108/. Accessed April, 2006. 12. Gasevic, D., Djuric, D. and Devedzic, V. (2006b). Mappings of MDA Based Languages and Ontologies. In Gasevic, D., Djuric, D. and Devedzic, V. Model Driven Architecture and Ontology Development. Chapter 10, pp: 211 226, Springer Verlag, Germany, 2006. 13. Dragan, D. (2004). MDA based Ontology Infrastructure. Computer Science Information Systems (ComSIS), 1(1):91 116, February 2004. 14. Falkovych, K. (2002). Ontology Extraction from UML Diagrams. Master s thesis, Vrije Universiteit Amsterdam.
Deriving OWL Ontologies from UML Models: an Enterprise Modelling Approach. 15. Falkovych, K., Sabou, M. and Stuckenschmidt, H. (2003). `UML for the Semantic Web: Transformation Based Approaches. Omelayenko, B., Michel, C. and Klein, A. (Eds.): Knowledge Transformation for the Semantic Web. Frontiers in Artificial Intelligence and Applications Vol. 95 IOS Press, pp: 92 106. 16. W3C, World Wide Web Consortium (2005). OWL S: Semantic Markup for Web Services. Submission, 22 November, 2005. Available online at: http://www.w3.org/submission/owl S/. Accessed April, 2006. 17. Cranefield, S. (2001). UML and the Semantic Web. Proceedings of the International Semantic Web Working Symposium (SWWS). 18. Kalyanpur, A., Pastor, D. J., Battle, S. and Padget, J. (2004). Automatic Mapping of OWL Ontologies into Java. In Proceedings of the Sixteenth International Conference on Software Engineering & Knowledge Engineering (SEKE'2004), Banff, Alberta, Canada, June 20 24, 2004, pp. 98 103. 19. Pierre M, LaPlant WP, (1998). Issues in Crosswalking Content Metadata Standards, in NISO Standards White Papers, National Information Standards Organization, 1998. 20. Moen, W.E. (2004). Metadata Interaction, Integration and Interoperability. NISO Workshop: Metadata Practices on the Cutting Edge. May 20. Washington DC, US. 21. OMG, Object Management Group (2008a). MOF 2.0 / XMI Mapping Specification, v2.1.1. January 2008. 22. OMG, Object Management Group (2008b). UML Resource Page. Available online at: http://www.uml.org/. Last visited 13, March, 2008. 23. W3C, Word Wide Web Consortium (1999). XSL Transformations (XSLT) Version 1.0. Recommendation, 16 November, 1999. Available at: http://www.w3.org/tr/xslt.html. Accessed April, 2006. 24. Sun Microsystems, (2006). Java API for XML Processing. Available online at: http://java.sun.com/xml/japx/index.jsp. (Last accessed March, 2008). 25. WSMO, Web Services Modeling Ontology (2005) [online]. Available online at: http://www.wsmo.org/tr/d2/v1.2/.