Mapping UML Class Diagrams to Object-Oriented Logic Programs for Formal Model-Driven Development

Franklin Ramalho1,2, Jacques Robin2

1

Departamento de Sistemas e Computao Universidade Federal de Campina Grande Caixa Postal 10106 58109-970 Campina Grande, PB Brazil franklin@dsc.ufcg.edu.br 2 Centro de Informtica Universidade Federal de Pernambuco Caixa Postal 7851 50732-970 Recife, PE Brazil {fsr, jr}@cin.ufpe.br

Abstract: MODELOG aims at automatically mapping UML class, object, statechart, activity and collaboration diagrams adorned with Object-Constraint Language expressions to non-monotonic, dynamic, object-oriented logic programs in Concurrent Transaction Frame Logic (CTFL). Coupled with the Flora2 inference engine for CTFL, MODELOG will fill five gaps in the current UML-based infrastructure for the Common Warehouse Meta-model, ModelDriven Architecture and Semantic Web visions: (1) automated data transformation transactions specified using the Meta-Object Facility for data warehousing and mining, (2) automated UML model transformations for refinement and refactoring, (3) formal verification of UML models, (4) complete UML model compiling into running code and (5) deductive and abductive inference in intelligent agents leveraging UML semantic web ontologies. In this paper, we present the MODELOG mapping of UML class diagrams to structural CTFL clauses.

1 Introduction and Motivation

In recent years, UML has far outgrown its initial purpose as a standard visual notation for constructing intuitive, high-level blueprint models of object-oriented software. A series of extension, such as the Object-Constraint Language (OCL) [18] and the Meta-Object Facility (MOF) [14] standards, to the language and to its application scope have fed-off each other in synergy. The set of all UML language extensions were motivated by a set of application scope extensions that includes: (1) UML as an abstract visual syntax for data and meta-data modeling; (2) UML as an abstract visual syntax for computational language and middleware design; (3) UML as a low-level specification language allowing complete structural and behavioral code generation from detailed, precise models; (4) UML as a formal specification language for automated model checking and verification; and (5) UML as a knowledge representation language for intelligent agents.

These extensions are associated with ambitious OMG and W3C standardization efforts to bring about far-reaching innovative visions to the software industry: Extension 1 is associated with the Common Warehouse Metamodel (CWM) which aims at (1) providing transparent interoperability among Knowledge Discovery in Database (KDD) tools and (2) raise the level of automation in the KDD process; Extensions 1 to 4 are associated with the Model-Driven Architecture (MDA) initiative [11], which aims at (a) separating business modeling concerns from implementation platform concerns by distinguishing between Platform Independent Models (PIM) and Platform Specific Models (PSM), (b) separating industry specific business modeling from modeling computational services that recur across industries and (c) automating many steps of the software engineering process; Extension 5 is associated with the Semantic Web (SW) initiative [6], which aims at providing web-published domain ontologies as knowledge bases to be reused by intelligent, information gathering and e-business agents for autonomous reasoning, communication, negotiation and cooperation. While the UML extensions mentioned above constitute a sound starting point to make UML the pivotal element for the MDA and SW visions, many other building blocks are still missing from UML before it can truly play this role. Five crucial missing blocks are: Complete UML and OCL formal semantics in the complementary denotational, operational and axiomatic flavors; UML inference engines based on such formal semantics to support UML model checking and verification as well as intelligent agent reasoning with UML ontologies; UML model transformation engines to automate PIM to PIM refinement from design patterns as well as PIM to PSM for implementation and PSM to PIM translations for reverse engineering; Engines to automatically execute scheduled, composite data transformation transactions specified in UML using the CWM standard; UML model compilers for fully automated programming language code generation from UML models. Many different proposals have been put forward that tackle one or two of these issues. In this paper, we present a key part of the MODELOG (Model-Oriented Development with Executable Logical Object Generation) project that addresses simultaneously all five of these issues with a simple, single proposal. The proposal consists of defining an automatic mapping from precise UML class, object, activity, statechart, and collaboration diagrams, fully annotated with OCL constraints to the formal knowledge representation language Concurrent Transaction Frame Logic (CTFL) [9]. We are currently developing the MODELOG automatic translator of UML models to CTFL programs. In a previous publication [15], we presented the mapping of UML activity diagrams to CTFL behavioral code. In the present paper, we focus on the mapping of UML class diagrams to CTFL structural code. Future publications will present the mapping of OCL constraints and the remaining diagrams to CTFL.

2 Concurrent Transaction Frame Logic (CTFL)

CTFL is the integration of Frame Logic [10] and Concurrent Transaction Logic [4], two orthogonal extensions of First-Order Horn Logic (FOHL), the subset of classical first-order logic that underlies pure logic programming. 2.1. Frame Logic (FL) FL extends FOHL with two new classes of logical terms: class definition terms and object creation terms. A class definition term specifies the superclass of a class together with its proper attribute filler and method return type constraints, following the syntactic pattern: class::superclass[...attri typOpi typei, ..., methj(...,paramjk,...) typOpj typej...] There are four typing operators in FL that instantiate the typOpi in the above pattern: *=>, *=>>, => and =>>. The presence or absence of the * prefix distinguishes between inheritable and non-inheritable type constraints, whereas the > and >> suffixes indicates whether the attribute or method is single valued or set valued. An object definition term creates a new object instance of a class and assigns its proper attribute and method return values, follow the syntactic pattern: object:class[...attri assignOpi valuei, ,methj(...,paramjk,...) assignOpj valuej ...] There are four value assignment operators, that instantiate the assignOpi in the above pattern: *->, *->>, -> and ->>. They follow the same prefix and suffix conventions than the typing operators. 2.2. Concurrent Transaction Logic (CTL) Sequential Transaction Logic (STL) extends FOHL with two new transactional connectives: n-ary serial conjunction , and n-ary serial disjunction . Concurrent Transaction Logic (CTL) further extends STL with three additional ones: n-ary concurrent conjunction , n-ary concurrent disjunction and unary atomic transaction modality . These five connectives allow representing in a purely declarative and logical way ordering and synchronization constraints on the execution order of logical proof steps. They provide declarative proof-theoretic and model-theoretic semantics to logic programs and database updates and transactions, as well as to multi-agent and inter-process communication protocols. The difference between these new connectives and their classical counterpart lies not in their truth tables, but only in their execution order constraints: specified and and , concurrent for and , and unspecified for and . Thus, sequential for while |, , and are commutative, and are not. Given that FL extends FOHL by introducing new terms and STL and CTL extends it by introducing new connectives, these extensions are orthogonal and can be straightforwardly combined, respectively yielding STFL and CTFL.

3 Mapping UML Class Diagrams to CTFL Object-Oriented Facts

The UML class diagram is a very comprehensive structural knowledge representation language, even though only a small part of its many elements are used in most models. While the most frequently used elements have direct counterparts in CTFL, the more rarely used ones do not. The approach that we chose was to directly map the elements with a corresponding CTFL constructs at the domain level, and map those with no such corresponding construct at the meta-level using UML meta-model attributes in CTFL objects. 3.1 Class, Attribute and Operation Mapping A UML class signature is mapped directly to a CTFL class definition term as shown in Fig. 1. Attribute and methods with Boolean values in UML do not possess any return value (void return value) in CTFL. The hybrid logic and object-oriented paradigm of CTFL makes any attribute value or method return result dual. Each has both a logical truth-value, which is Boolean, and an object identifier.
Cl ass1
attribute1_c1 : Type1 attribute2_c1 [ 0..* ] : Type2 attribute3_c1 : Boolean method1_c1(par : Type_Par) : Type1

class1[attribute1_c1 *=> type1, attribute2_c1 *=>> type1, attribute3_c1 *=> void, method1_c1(type_par) *=> type1, uml *=> uml].

Fig. 1. Class mapping uml[class *=> umlClass, attr(string) *=> umlAttr, meth(string) *=> umlOper] .

Fig. 2. Meta-level uml class type signature The additional attribute uml groups the elements of the UML source class for which no corresponding CTFL constructs exist. The type of such attribute is constrained to the special, meta-level class uml, which type signature is shown in Fig. 2.

3.2 Constraint and Stereotype Mapping UML generalization relationships can be restricted by various adornments. For example, the root adornment specifies that the class stands at the top of the generalization hierarchy. Classes can also contain stereotypes that extend the vocabulary of UML model elements. We map adornments and stereotypes onto attributes of the meta-level CTFL class umlClass, as shown in Fig. 3. Note that the predefined constraints that may be applied to UML classes are mapped to Boolean attributes in CTFL.

umlClass[ abstract *=> void, root *=> void, leaf *=> void, stereotype *=>string] .

Fig. 3. Auxiliary CTFL class for mapping class constraints and stereotypes

3.3 Attribute Properties Mapping A UML attribute can have several other properties beyond its name and value type constraint: visibility, scope, multiplicity, changeability, initial value and default value. Among these properties, only the scope has a direct correspondence in CTFL: the -> type operator for classifier scope and => type operator for instance scope. We thus map the other properties to attributes of the meta-level CTFL class umlAttr, which definition is shown in Fig. 4. umlAttr[visibility *=> {public, protected, private, package}, multiplicity(integer, {integer ; *}) *=> void, order *=> void, initialValue *=> class, changeability *=> {changeable, addOnly, frozen}, stereotype *=> string] .

Fig. 4. Auxiliary CTFL class for mapping attributes information

This class has one attribute for each adornment that may appear in an attribute declaration within a umlClass definition. For example, in Fig. 4, attributes visibility and changeability are encoded by a CTFL enumeration that restricts their value to their respective range in the UML specification. The multiplicity of a umlClass attribute is mapped into a the Boolean method multiplicity, which parameters are the minimal and maximal attribute cardinalities. 3.4 Generalization Mapping A UML generalization relationship is mapped to the CTFL subclass :: operator. The default inheritability of UML attributes and methods is mapped to the type constraint operators prefixed by * that captures such semantics in CTFL. We map other properties of the generalization such as association-ends, discriminator, predefinition and stereotypes to attributes of the meta-level umlGeneralization class. An example of such mapping is given in Figs. 5 and 6.

Class1
attri bute _c1 : Type1 method_c1(par : Type_Par) : Type1

class1[attribute_c1*=> type1, method_c1(type_par) *=> type1] .

Subclass_1
attri bute _sc1 : Type 2 method_c1(par : Type_Par) : Type3

subclass_1::class1[ attribute_sc1*=> type2, method_c1(type_par)*=> type3] .

Fig. 5. Generalization mapping using CTFL :: operator

umlGeneralization[ end1 *=> class, end2 *=> class, discriminator *=> string, constraint *=>> {complete, incomplete, disjoint, overlapping}, stereotype *=>> string, elided *=> void] .

Fig. 6. Generalization mapping using meta-class in CTFL

4 Related Work
Previous research related to MODELOG split along three axis. The first one advocates using UML to represent SW ontologies, due to its visual clarity, conciseness, intuitiveness, comprehensive expressiveness, wide user base and the availability of many industrial strength case tools for UML model edition and maintenance [2] [5]. In part because other languages such as RDF Schema and DAML-OIL [6] have been approved as W3C standards for SW ontology representation, this line of work emphasized mapping UML diagrams to these languages. While we fully support UML as a knowledge-level SW language, our UML to CTFL mapping proposal differs from these other proposals due to the distinctive characteristics of CTFL as compared to W3C ontology languages. Foremost, there is no inference engine available to directly reason with such languages. Reasoning can only be carried through a second mapping to a third knowledge representation language for which such engine is available. To that effect, mapping to Prolog, Jess [7] various description logic languages [1] and CTFL itself have been proposed. Our approach is more direct. The second line of work related to MODELOG advocates the use of UML class diagrams and OCL constraints to declaratively specify, in UML itself, automated model transformation for model refinement, model refactoring, code generation and reverse engineering [8] [12]. In these proposals, the UML/OCL transformation specification is manually implemented into an executable transformation language, such as XSLT [3]. In contrast, we propose to use MODELOG to automatically generate executable transformations in CTFL from such UML/OCL transformation specification.

Interestingly, one previous study [8] identified CTFL as a more appropriate model transformation language than Java, XSLT and Mercury among others. However, it criticized Flora-1 as transformation engine as inefficient and unsafe with negation. The now available Flora-2 engine corrects both these problems. First, it compiles a single-thread CTFL program in two stages to the abstract machine of the tabled Prolog engine, XSB [16], with great efficiency gains as compared to Flora-1. Second, it implements the well-founded semantics for negation [17]. The third related work axis deals with mapping UML diagrams to formal languages for model checking purposes. A comparison of MODELOG and these approaches can be found in [15]. The main originality of our proposal is twofold. First, it simultaneously tackles various advanced UML applications such as semantic web ontologies and agents, UML formal semantics, UML model transformation, and code generation and verification from UML models. Second, it does so without putting forward any new language but only by reusing a theoretically consolidated and efficiently implemented one. In contrast, previous proposals tend be limited to one or two such applications while often proposed new languages.

5 Conclusion
In this paper, we have shown how to map a UML class diagram to an executable program in the CTFL formal object-oriented logic programming language. The mapping we presented is part of the MODELOG project that aims to define an automatic mapping from precise UML class, object, activity, statechart, and collaboration diagrams, fully annotated with OCL constraints to a CTFL program. MODELOG paired with the Flora-2 inference engine for the sequential subset of CTFL will allow automating the following tasks: Generate from the model a complete STFL implementation and execute it; Verify the logical consistency and completeness of the generated code, and thus indirectly of the source model, via the application of STFL verification rules; Perform queries on the model that involve complex deductive and abductive reasoning (again indirectly as STFL queries on the generated STFL code); Perform model refinement, model refactoring or data warehousing transformations on the model by mapping it to a STFL program, transforming the STFL program via the application of STFL transformation rules, and mapping back the transformed STFL program to the transformed model. The pair of MODELOG and Flora-2 will thus be able to fulfill the functionalities needed in three aspect of the MDA vision: the Query-View-Transform aspect, the Executable UML aspect and the UML-based formal software engineering aspect. It will also allow leveraging UML case tools to develop both SW ontologies and agents that autonomously reason with the knowledge encoded in these ontologies to provide intelligent web services.

References
1. Baader,, F., Calvanese, D., McGuiness, D., Nardi, D. and Patel-Schneider, P. (Eds.): The description logic handbook: theory, implementation and applications. Cambridge University Press. (2003) 2. Baclawski, K., Kokar, M., Kogut, P., Hart, L., Smith, J., Holmes, W., Letkowski, J., Aronson, M.: Extending UML to Support Ontology Engineering for the Semantic Web. In: Fourth International Conference on UML, Toronto (2001) 3. Birbeck, M. et al. Professional XML (2nd Ed.). Wrox. (2001) 4. Bonner, A.J. and Kifer, M.: Concurrency and communication in transaction logic. In Proceedings of the Joint International Conference and Symposium on Logic Programming, MIT Press, (1996), 142156. 5. Cranefield, S.: Networked Knowledge Representation and Exchange using UML and RDF, Journal of Digital Information 1(8), February, 2001 6. Davies, J., Fensel, D. and Van Harmelen, F. (Eds).: Towards the semantic web: ontologydriven knowledge management. John Wiley & Sons. (2003) 7. Friedman-Hill, E.: Jess in Action: Rule-Based Systems in Java. Manning Publications Company. (2003) 8. Gerber, A., Lawley, M.J., Raymond, K., Steel, J. and Wood. A.: Transformation: The Missing Link of MDA. In Proceedings of the 1st International Conference on Graph Transformation (ICGT 2002), 90-105 9. Kifer, M.: Deductive and object data language: a quest for integration. In Proceedings of the 4th Conference on Deductive and Object-Oriented Databases, (DOOD'95), Singapore, LNCS 1013, (1995) 10. Kifer, M. Lausen, G. and Wu, J. (1995).: Logical foundations of object-oriented and frame-based languages, Journal of the ACM, (1995), 741-843. 11. Kleppe, A., Warmer, J. and Bast W.: MDA Explained: The Model Driven Architecture: Practice and Promise Addison Wesley (2003) 12. Oldevik, J., Solberg, A. Elvesaether, B. and Berre, A.J.: Framework for model transformation and code generation. In proceedings of the Sixth International Enterprise Distributed Object Computing Conference (EDOC'02), September 17 - 20, Lausanne, Switzerland, (2002) 13. Object Management Group, Request for Proposal: MOF 2.0 Query / Views / Transformations RFP, ad/2002-04-10 (2002). 14. Poole, J., Chang, D. Tolbert, D. and Mellor, D.: Common Warehouse Meta-model: an introduction to the standard for data warehouse integration, Wiley & Sons,(2002) 15. Ramalho, F., Robin, J. and Schiel, U.: Concurrent Transaction Frame Logic Formal Semantics for UML Activity and Class Diagrams. Electronic Notes in Theoretical Computer Science Volume 95, 17 May 2004 Edited by A. Cavalcanti and P. Machado, Elsevier, 2004. 16. Sagonas, K., Swift, T. and Warren, D. S..: XSB as an efficient deductive database engine, Snodgrass, R. T. and M. Winslett, M., ACM SIGMOD Int. Conf. on Management of Data (SIGMOD'94), (1994) 442453 17. Van Gelder, A., Ross, K.A., and Schlipf, J.S.: The Well-Founded Semantics for General Logic Programs. Journal of the ACM 38(3), (1991), 620--650. 18. Warmer J. and Kleppe A.: Object Constraint Language, The: Getting Your Models Ready for MDA, Second Edition, Addison-Wesley, Reading/MA, 2003.