8/13/2019 Mode Log

1/8

Mapping UML Class Diagrams

to Object-Oriented Logic Programs

for Formal Model-Driven Development

Franklin Ramalho1,2, Jacques Robin2

1Departamento de Sistemas e Computao Universidade Federal de Campina Grande

Caixa Postal 10106 58109-970 Campina Grande, PB Brazilfranklin@dsc.ufcg.edu.br

2Centro 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 pro-

grams in Concurrent Transaction Frame Logic (CTFL). Coupled with the Flora-

2 inference engine for CTFL, MODELOG will fill five gaps in the current

UML-based infrastructure for the Common Warehouse Meta-model, Model-

Driven Architecture and Semantic Web visions: (1) automated data transforma-

tion 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 intel-ligent agents leveraging UML semantic web ontologies. In this paper, we pre-

sent 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 com-

plete structural and behavioral code generation from detailed, precise models;

(4) UML as a formal specification language for automated model checking and verifi-

cation; and (5) UML as a knowledge representation language for intelligent agents.

8/13/2019 Mode Log

2/8

These extensions are associated with ambitious OMG and W3C standardization ef-

forts 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 theModel-Driven Architecture (MDA)initiative [11], which aims at (a) separating business modeling concerns from

implementation platform concerns by distinguishing betweenPlatform Inde-

pendent 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 en-

gineering 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 miss-

ing blocks are:

Complete UML and OCL formal semantics in the complementary denota-tional, operational and axiomatic flavors;

UML inference engines based on such formal semantics to support UMLmodel 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 transformationtransactions specified in UML using the CWM standard;

UML model compilers for fully automated programming language code gen-eration from UML models.

Many different proposals have been put forward that tackle one or two of these is-

sues. In this paper, we present a key part of the MODELOG (Model-Oriented Devel-

opment with Executable Logical Object Generation)project that addresses simultane-

ouslyall 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.

8/13/2019 Mode Log

3/8

8/13/2019 Mode Log

4/8

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 (voidreturn value) in CTFL. The hybrid logic andobject-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.

Fig. 1.Class mapping

Fig. 2.Meta-level umlclass 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 con-

strained 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 exam-

ple, the rootadornment 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.

uml[class *=> umlClass,

attr(string) *=> umlAttr,

meth(string) *=> umlOper] .

class1[attribute1_c1 *=> type1,

attribute2_c1 *=>> type1,

attribute3_c1 *=> void,

method1_c1(type_par) *=> type1,

uml *=> uml].

Class1

attribute1_c1 : Type1

attribute2_c1 [ 0..* ] : Type2

attribute3_c1 : Boolean

method1_c1(par : Type_Par) : Type1

8/13/2019 Mode Log

5/8

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.

Fig. 4.Auxiliary CTFL class for mapping attributes information

This class has one attribute for each adornment that may appear in an attribute decla-

ration within a umlClassdefinition. For example, in Fig. 4, attributes visibil-

ityand changeabilityare encoded by a CTFL enumeration that restricts their

value to their respective range in the UML specification. The multiplicity of a

umlClassattribute 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. Thedefault inheritability of UML attributes and methods is mapped to the type constraint

operators prefixed by * that captures such semantics in CTFL. We map other proper-

ties of the generalization such as association-ends, discriminator, predefinition and

stereotypesto attributes of the meta-level umlGeneralization class. An example

of such mapping is given in Figs. 5 and 6.

umlClass[ abstract *=> void,

root *=> void,

leaf *=> void,

stereotype *=>string] .

umlAttr[visibility *=> {public, protected, private,

package},

multiplicity(integer, {integer ; *}) *=> void,

order *=> void,

initialValue *=> class,

changeability *=> {changeable, addOnly, frozen},

stereotype *=> string] .

8/13/2019 Mode Log

6/8

Fig. 5.Generalization mapping using CTFL :: operator

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

4 Related Work

Previous research related to MODELOG split along three axis. The first one advo-cates 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 empha-

sized 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] andCTFL 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 speci-

fication is manually implemented into an executable transformation language, such as

XSLT [3]. In contrast, we propose to use MODELOG to automatically generate ex-

ecutable transformations in CTFL from such UML/OCL transformation specification.

umlGeneralization[ end1 *=> class, end2 *=> class,

discriminator *=> string,

constraint *=>> {complete, incomplete, disjoint,

overlapping},

stereotype *=>> string, elided *=> void]

.

Class1

attribute_c1 : Type1

method_c1(par : Type_Par) : Type1

Subclass_1

attribute_s c1 : Type2

method_c1(par : Type_Par) : Type3

class1[attribute_c1*=> type1,

method_c1(type_par) *=> type1] .

subclass_1::class1[

attribute_sc1*=> type2,

method_c1(type_par)*=> type3]

.

8/13/2019 Mode Log

7/8

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 im-

plements 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 verifi-cation from UML models. Second, it does sowithoutputting forward any new lan-

guage 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 pro-

gram 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 map-

ping 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 abductivereasoning (again indirectly as STFL queries on the generated STFL code);

Perform model refinement, model refactoring or data warehousing transfor-mations on the model by mapping it to a STFL program, transforming the

STFL program via the application of STFL transformation rules, and map-

ping 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.

8/13/2019 Mode Log

8/8

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 Pro-

ceedings 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, 20016. Davies, J., Fensel, D. and Van Harmelen, F. (Eds).: Towards the semantic web: ontology-

driven knowledge management. John Wiley & Sons. (2003)

7. Friedman-Hill, E.: Jess in Action: Rule-Based Systems in Java. Manning Publications Com-

pany. (2003)

8. Gerber, A., Lawley, M.J., Raymond, K., Steel, J. and Wood. A.: Transformation: The Miss-

ing Link of MDA. In Proceedings of the 1stInternational Conference on Graph Transforma-

tion (ICGT 2002), 90-105

9. Kifer, M.: Deductive and object data language: a quest for integration. In Proceedings of the

4thConference 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 transforma-

tion 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 / Transforma-

tions 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 Seman-

tics for UML Activity and Class Diagrams. Electronic Notes in Theoretical Computer Sci-

ence 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) 44245317. 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.