USING

UML CLASS DIAGRAM AS A KNOWLEDGE

ENGINEERING TOOL

Thomas Raimbault, David Genest and St

ephane Loiseau

Leria laboratory − University of Angers, 2 boulevard Lavoisier, 49045 Angers Cedex 1, France

Keywords:

Knowledge Engineering, Model-Based Reasoning, UML, Conceptual Graphs, Visual Quering and Checking.

Abstract:

UML class diagram is the de facto standard, including in Knowledge Engineering, for modeling structural

knowledge of systems. Attaching importance to visual representation and based on a previous work, where

we have given a logical deﬁned extension of UML class diagram to represent queries and constraints into the

UML visual environment, we present here how using the model of conceptuals graphs to answer queries and

to check constraints in concrete terms.

1 INTRODUCTION

In Knowledge Engineering (KE) several tools are

used, especially knowledge representation methods,

for knowledge modeling and processing; e.g. (Akker-

man et al., 2000). We consider both visual modeling

for human readability and capable processing by a

machine as fundamental in KE area. For these two

reasons, we advocate on the one hand the use of the

Uniﬁed Modeling Language (UML) as visual mod-

eler, on the other hand the use of the model of con-

ceptual graphs (CG) as engine reasoner.

Based on our previous work (Raimbault et al.,

2009), where we have given both an extension of

UML class diagram to represent queries and con-

straints into the UML visual environment and a ﬁrst-

order logical (FOL) semantics for extended UML

class diagram (EUCD), we present here how using the

CG model to answer queries and to check constraints.

Due to the great deal in common between KE and

Software Engineering (SE) and the hight visual level

of UML class diagram as easy human readable mean-

ing, the integration of UML in KE becomes obvious;

e.g. (Rhem, 2006). UML − the so-called language

from SE − provides a way to software design by us-

ing diagrams of various kinds (Booch et al., 1998). In

this article, we focus our attention on class diagram

that is the main UML diagram and is used to model

structure of a system.

During the knowledge acquisition phase, the de-

signer needs to query and to check several parts of al-

ready represented knowledge to complete this phase.

However, UML is merely a language, then knowl-

edge is only represented as a drawing (no reasoning

way is available at the origin). The Object Constraint

Language (OMG, a) (OCL), which is an integral part

of UML 2, gives a solution to express constraints or

queries in addition to UML diagrammatic notations.

Nevertheless, as a textual language, OCL leaves the

visual interest of UML out. That is the main reason

why we use CG model to answer queries and to check

constraints rather than OCL tools (like USE (Gogolla

et al., 2007)).

In this paper, our contibution is to show how to

translate EUCD from (Raimbault et al., 2009) into the

CG model of (Chein and Mugnier, 1992; Chein et al.,

1998; Chein and Mugnier, 2004; Baget et al., 1999;

Baget and Mugnier, 2002). It is a knowledge rep-

resentation and calculation model with FOL seman-

tics that is implemented, for instance, in the Cogi-

tant platform (Genest, 2008). This translation is in-

teresting for tree reasons. First, the logical semantics

− called logical form − of EUCD (including query

and constraint) from (Raimbault et al., 2009) can eas-

ily mapped into the CG model using nested graphs

(Chein et al., 1998). Second, in the situation where

some element of a given class diagram can not be

represented in the visual environment of EUCD, the

CG model that provide a graphical environment (as

graph theory meaning) seems more preferable than

OCL that is a textual language. This second reason

also concerns the use of the CG model instead of

“classical” theorem prover because the visual repres-

ntation of CGs is more intuitive to use than logical

formulas. Third, Cogitant includes operators that can

e used to validate our work: queries and constraints

Raimbault T., Genest D. and Loiseau S. (2009).

USING UML CLASS DIAGRAM AS A KNOWLEDGE ENGINEERING TOOL.

In Proceedings of the 11th International Conference on Enterprise Information Systems - Artiﬁcial Intelligence and Decision Support Systems, pages

61-66

DOI: 10.5220/0001862400610066

 SciTePress

Figure 1: Example of a UML class diagram.

can be computed by this platform on EUCD.

This paper is organized as follows. Section 2 give

a short introduction to UML class diagram. Section 3

recalls recall the logical form of EUCD and the def-

inition of queries and constraints as kind of EUCD

from our previous works. Section 4 indicates how to

integrate EUCD into the model of conceptual graphs.

2 UML CLASS DIAGRAM

Class diagram shows statical structure of a system

with graphical notations. It describes the system’s

elements (especially classes), their features and their

relationships to other system’s elements. In a class

diagram, classes are modeled and are linked by two

types of relations: generalization and association.

Using the example in Figure 1, we brieﬂy present

the main notations of a UML class diagram. A class

(e.g. Customer) is drawn as a solid-outline rectangle.

It contains the name of the class in the top compart-

ment, the attributes (e.g. name) in the middle compart-

ment, and the operations (e.g. bill) in the bottom com-

partment. This operation has one parameter, which is

an instance of the class Flight, and returns a data as

a real (primitive type). The generalization relation is

represented by an arrowed line drawn from the spe-

cialized class to the general class. Then, the class

FrequentFlyer has for generalization the Customer class,

and the Customer class has for subclasse the classe Fre-

quentFlyer. An association between the classes Flight

and Customer is deﬁned

by the association class travel

and by the properties present at the ends of the associ-

ation, like the multiplicity 1..N or the role person. The

association class, which is a kind of class, is shown

as a class symbol (the top compartment is only rep-

resented here) linked by a dashed line to a line that

represent the association.

We have always chosen to represent an association as

its most complete form, i.e. by using an association class

(each association can be expended to an association class).

Note that we consider a UML class diagram as a

ﬁnite set of UML notations. We call a UML notation

a pair (concept, element), where concept is one of the

symbols that constitute the UML class diagram lan-

guage, and element is an instance of this concept. For

example, in Figure 1 Flight is an element of the con-

cept ‘class’. We divide concepts in three sets: the set

of entities, the set of relations and the set of proper-

ties. An entity is used to refer to general concepts such

as: class, attribute, operation, etc. A relation is either

a generalization or an association between classes. A

property provides more precisely a meaning, like vis-

ibility or multiplicity.

3 PREVIOUS WORKS

The presented work in this paper is based on our pre-

vious works (Raimbault et al., ) and (Raimbault et al.,

2009). In (Raimbault et al., ) is proposed a ﬁrst way

for querying and checking UML class diagram by us-

ing the model of conceptual graphs. (Raimbault et al.,

2009) gives a simpliﬁcation and an explicit formaliza-

tion in FOL of the implicit logical semantics using in

(Raimbault et al., ) to transforme class diagrams into

conceptual graphs.

We now recall the main contributions from (Raim-

bault et al., 2009): logical form of a class diagram,

an extension of class diagram with variables and bi-

coloration, and query and constraints.

3.1 Logical Form of UML Class

Diagram

In our previous work (Raimbault et al., 2009), we as-

sociate a FOL semantics, called Logical Form (LF),

of a given UML class diagram. The predicat set that

are used expresses the UML meta-model (OMG, c).

In a class diagram, an element may be described

by some others: these other elements are enclosed

into it. For instance, a class is described by its at-

tributes and its operations, which are nested into the

class representation. We call the entity that encloses

the others the context of them. In light of those ob-

servation and rather than other approaches to trans-

forme UML class diagram into FOL formula − e.g.

(Beckert et al., 2002) −, in our approach a predicate

that represents an entity (respectiveley a relation or a

property) is a binary predicate (respectiveley a ternary

predicate): the ﬁrst one argument is used to represent

the context of an element.

Logical Form. The Logical Form Φ

of a UML

class diagram D is a FOL formula of conjunction of

USING UML CLASS DIAGRAM AS A KNOWLEDGE ENGINEERING TOOL

Figure 2: Entity set of UML class diagram meta-model.

predicates. A predicate in Φ

represents a concept

of the UML class diagram language (i.e. UML class

diagram meta-level). A constant in Φ

refers to an el-

ement of D (i.e. an instance of a concept). According

to different kind of UML notations that can be used in

D, Φ

is obtained as follows:

• an instance e of an entity E is repesented by the

binary predicate E(c

, id

) where c

is the context

of e and id

is the identiﬁer of e (see Φ

as exam-

ple). The entity predicate set is partially ordered

in Figure 2.

• a generalization link between the more gen-

eral class C

and the more speciﬁc class C

repesented by the ternary predicate generaliza-

tion(c

, id

) where c

is the context of the

generalization link, id

and id

are respectively

the identiﬁers of C

and C

(see Φ

as example).

• a association link among classes C

, . . . , C

is - in

UML - a group of several association ends. The

associtaion link, strictly speaking, is represented

as an association class, i.e. an instance of the

entity assoClass (see ﬁrst item); The i

associa-

tion end is repesented by the ternary predicate as-

soEnd(c

, id

) where c

is the context of the

association link, id

is the identiﬁer of class C

and id

is the identiﬁer of role that is associated

to C

according to this association link; The group

is composed by the use of the ternary predicate

association(c

, id

) where id

is the identiﬁer

of the association link (i.e. the association class);

(see Φ

as example).

• a value v for the property P that is applied to an

entity or a relation a is repesented by the ternary

predicate P(c

, id

, v) where c

is the context of a

and id

is the identiﬁer of a (see Φ as example).

The property predicate set is partially ordered in

Figure 3.

Example: Φ

is the LF of the part of class diagram in

Figure 1 amount to the class Customer, Φ

is the LF of

the generalization link between FrequentFlyer and Cus-

tomer, Φ

is the LF of the association travel. Finally, Φ

is the LF of class diagram in Figure 1, based on par-

tial LFs Φ

to Φ

that are competed w.r.t. appropriate

properties.

Figure 3: Property set of UML class diagram meta-model.

= package(>, pkg) ∧ class(pkg, customer) ∧ at-

tribute(customer, name) ∧ operation(customer, bill) ∧

parameter(bill, f).

= generalization(pkg, customer, frequentﬂyer).

= assoClass(pkg, travel) ∧ role(pkg, assigﬂight) ∧

role(pkg, person) ∧ assoEnd(pkg, ﬂight, assigﬂight)

∧ assoEnd(pkg, customer, person) ∧ association(pkg,

travel, assigﬂight) ∧ association(pkg, travel, person).

Φ = Φ

∧ named(pkg, customer, ”Customer”) ∧

propVal(pkg, ”Customer”) ∧ ofType(bill, f, ﬂight) ∧

. . . ∧ Φ

∧ Φ

∧ multiplicity(pkg, person, 1-N) ∧ . . . .

First, note that the more general context is repre-

sented by the constant >. Second, note that each ele-

ment is identiﬁed by a constant: for visibility reasons,

in our example an identiﬁer is the element’s name pre-

ﬁxed by its full context (but identiﬁers may be num-

bers as id

, id

, etc.). Third, note that named is a prop-

erty that makes the link between an identiﬁer of an

entity and its real name in a class diagram. Fourth,

note that predicate propVal is used to deﬁne a prop-

erty’s value as an entity itself.

3.2 Querying and Checking EUCD

In (Raimbault et al., 2009), we have proposed an ex-

tension of UML class diagram, called extended UML

class diagram (EUCD), using variables and/or bi-

coloration. Then, we have deﬁnd two family of ex-

tended UML class diagrams: queries and constraints.

Queries are used to ﬁnd some elements, and con-

straints to check some other. We recall in this section

how to query and check UML class diagram.

Variable and Mapping. Any element in a EUCD

can be a variable. It seems that the element exists

whereas it is not identiﬁed (a temporary identiﬁer is

used: the variable’s name). The new visual notation

associated of a variable x is denoted in EUCD D by

the symbol $x. In Φ

, the existential quantiﬁed vari-

able x is used.

A mapping from a EUCD D

to a EUCD D

is a min-

imal subset D

of D

such as knowledge modeled by

can be infered by knowledge modeled by D

ICEIS 2009 - International Conference on Enterprise Information Systems

Figure 4: A UML query and a mapping.

Querying UML Class Diagram. A query is a

EUCD (see left part of Figure 4 for instance). The

result(s) of a query Q to interrogate a EUCD D is the

set of mappings from Q to D.

Example: The query in Figure 4 expresses the

fact that “In a given package, does a class

named Customer has a subclass that has an at-

tribute of type int?”. The LF of this query

is: Φ

= ∃x,y,z package(>,x) ∧ class(x,id

)

∧ named(x,id

,”Person”) ∧ propVal(x,”Person”) ∧

class(x,y) ∧ generalization(x,id

,y) ∧ attribute(y,z)

∧ visibility(y,z,”private”) ∧ propVal(>,”private”) ∧

ofType(y,z,int) ∧ primType(>,int).

The answer of this query to interrogate class diagram

on Figure 1 is presented on the right side in Figure 4.

One can see that the intended class is Frequentﬂyer:

into package Pkg and with the attribute bonusPoints.

Checking UML Class Diagram. Two kind of con-

straints are deﬁned: negative and positive constraints.

A negative constraint C

−

expresses a speciﬁcation

like “no A exists” in a class diagram D: no mapping

from C

−

to D must be found. A negative constraint

is represented by a EUCD. A positive constraint

expresses a speciﬁcation like “if premise A,

then obligation B”. In other words, if a mapping

from the premise of C

to a class diagram D (which

has to be check by C

) exists, then this mapping

must be extend from whole C

to D. A positive

constraint is represented by a EUCD where premise

is white background colored and obligation is black

background colored.

Example: Figure 5 shows a negative constraints C

−

and a positive constraints C

. C

−

expresses the fol-

lowing prohibition: “a class X can be a subclass of

a class Y, which is a subclass of X”. In other words,

this constraint checks that “there is no simple inheri-

tance cycle”. C

expresses the following obligation:

“if a class X has an abstract operation z, for each sub-

class Y of X that is non-abstract, z must necessarily be

overwritten as a non-abstract operation”.

Figure 5: UML negative and positive constraints.

According to constraints C

−

and C

, the class dia-

gram in Figure 1 is valid.

4 INTREGRATION INTO

CONCEPTUAL GRAPHS

In this article, we use the CG model from (Chein

and Mugnier, 1992) with nested graphs (Chein and

Mugnier, 1997; Chein et al., 1998), coreference links

(Chein and Mugnier, 2004) and constraints (Baget

et al., 1999; Baget and Mugnier, 2002). This CG

model presents many interests. It is a formal and vi-

sual knowledge representation model. It provides a

reasoning operator, called projection, which is sound

and complete with respect to deduction in FOL (see

(Sowa, 1984; Chein and Mugnier, 1992) for simple

graphs, (Chein et al., 1998) for nested graphs. We use

the CG model instead of “classical” theorem prover

because in case of necessity to represent some knowl-

edge that can not be represented in UML, the visual

aspect of the CG model is more intuitive to use than

logical formulas.

4.1 A Short Introduction to CGs

In the CG model, a support speciﬁes the vocabu-

lary representing ontological knowledge. It describes

available concept and relation types ordered by a spe-

cialization relation. Facts are represented by con-

ceptual graphs, which nodes represent individual in-

stances of concepts and relations between them. The

fundamental reasoning operation is a graph morphism

called projection. It induces a subsumption relation

between graphs.

Support. We consider here a support

S = (T

, T

, I). T

is a partially ordered set of

concept types whose greatest element is >. T

is a

partially ordered set of relation types. For the paper,

we only use binary relations whose greatest element

is >

(but in general relations may be of any arity

greater or equal to one). Each relation type has a

USING UML CLASS DIAGRAM AS A KNOWLEDGE ENGINEERING TOOL

Figure 6: T(UML query) and projection from it to T(class diagram Fig.1).

signature, which gives the greatest possible concept

type for each argument. I is a countably inﬁnite set

of individual markers.

Nested Conceptual Graphs. A nested conceptual

graph (NCG), related to a support S, is a bipartite la-

belled multigraph G = (C, R, E, l). C is the set of con-

cept nodes, R the set of relation nodes, and E the set

of edges.. Each label is given by the mapping l. The

label of a relation node is a relation type from T

. The

label of a concept node is composed of a concept type

from T

, a marker from I ∪ {∗} (if ∗, the node repre-

sents a generic individual, else a speciﬁc individual)

and a description, which may be either sets of NCG

or empty (refered by ∗∗ in (Chein and Mugnier, 1997;

Chein et al., 1998)). For a graph G, which is in a de-

scription of a concept node c of another graph, one

saids that G is nested into c. Labels on concept nodes

must respect the signature deﬁned for their relation

neighbors. Every edge is labeled by 1 or 2 (in the

case of binary relations), for indicating which is the

ﬁrst and the second argument of each relation node.

4.2 EUCD into the CG Model

We ﬁrst show how to translate an extended UML class

diagram (EUCD) into a CG: the ordered sets of UML

concepts are deﬁned in a support of CGs; the transla-

tion of a given UML class diagram in a nested CG is

presented (see (Raimbault et al., ) for details). Sec-

ond, we describe how to translate queries and con-

straints into the CG model. Once we have it, we use

the projection operator for making reasoning (query-

ing and checking).

4.2.1 LF and Nested Conceptual Graphs

Proposition 1 (EUCD into CG). A EUCD can be

translated into a nested CG.

UML concepts are translated into a support S. A

EUCD is translated into a nested CG based on S. We

deﬁne S = (T

, T

, I) as follows:

• The set of concept types T

is the set of entity

predicates (Figure 2). Then the partial order be-

tween concept types is the partial order between

entities, i.e. entity is the greatest concept type.

• The set of relation types T

is composed of the

set of property predicates (Figure 3) in accordance

with partial order between them, plus the pred-

icates generalization, assoEnd and association.

Property, generalization, assoEnd and associa-

tion have a greater common relation type >

• The set of individual markers I is the set of iden-

tiﬁers of elements.

Let D be a EUCD, we build a nested CG T(D) based

on S such as by construction the FOL formula of T(D)

(Chein and Mugnier, 1997; Chein et al., 1998; Chein

and Mugnier, 2004) is equivalent to Φ

. T(D) is the

nested CG NCG(D, >), which is recursively deﬁned

by NCG(D, c) as follows:

• For each P(c, t

) ∈ Φ

, a new concept node C

created. C

is labelled by (type, marker, descrip-

tion); type is P; marker is either t

if t

is a con-

stant or ∗ if t

is a variable; description is either

NCG(D, t

) if NCG(D, t

) is not empty or ∗∗.

• For each P(c, t

, t

) ∈ Φ

, a new relation node is

created between C

and C

. This relation node is

labelled by P.

After this translation, coreference links are created

between concept nodes C

for each variable x of Φ

4.2.2 Queries and Constraints

Proposition 2 (UML Query and Projection). Let D

be a UML class diagram and Q a EUCD. There is

a mapping from Q to D iff there is a projection from

T(Q) to T(D).

Example: Figure 6 presents in the CG model the ex-

ample on Figure 4: on the left side is the translated

CG T(UML query), on the right side a part of the

translated CG T(class diagram Fig. 1). The projection

from T(UML query) to T(class diagram Fig. 1) is the

ICEIS 2009 - International Conference on Enterprise Information Systems

application from the labelled nodes of T (UML query)

into labelled nodes of T(class diagram Fig. 1) that

may decrease node labels (Chein and Mugnier, 1997;

Chein et al., 1998; Chein and Mugnier, 2004). A con-

cept node is represented by a rectangle [typeConcept:

individualMarker] or [typeConcept: ∗] that may have

a nested CG into it; a relation node is represented by

an oval (relationConcept).

Proposition 3 (UML Constraint and CG Con-

straint). A UML positive constraint (resp. negative

constraint) is translated into a CG positive constraint

(resp. CG negative constraint)

by T that is extended

such as the coloration is preserved (resp. each node

is one colored.).

Let D be a UML class diagram and C a UML con-

straint. D veriﬁes C iff T(D) veriﬁes (Baget et al.,

1999; Baget and Mugnier, 2002) T(C).

A prototype was developed to make an interface

between a EUCD and a CG by using Cogitant (Gen-

est, 2008). It translates UML class diagram, UML

query and UML constraint into CGs. Cogitant opera-

tors (based on projection) compute results of queries

and veriﬁe constraints on CGs. This interface makes

the visual link between CGs and UML class diagram

to display results computed by Cogitant (Raimbault

et al., ) on UML class diagram.

5 FUTURE WORK

We have proposed a way to translate UML queries

and UML constraints − both as EUCD − into the CG

model, and so use projection to query and check class

diagram. By using inverse translation, results can be

displayed in the visual representation of UML.

Due to the importance of visual representation of

knowledge, see for instance (OMG, b; Lukichev and

Wagner, 2006), we will now focus our attention on

how to represent rules into the UML visual environ-

ment by using bi-coloration (white background for

head and black background for conclusion) and how

to infere them by using the CG model.

REFERENCES

Akkerman, H., Anjewierden, A., Hoog, R. D., Shad-

bolt, N., de Welde, W. V., and Wielenga, B. (2000).

Knowledge engineering and management: the Com-

monKads methodology. Cambridge, MIT Press.

We recall that a CG constraint is a colored CG (Baget

et al., 1999; Baget and Mugnier, 2002).

Baget, J., Genest, D., and Mugnier, M. (1999). Knowl-

edge Acquisition with a Pure Graph-Based Knowl-

edge Representation Model. In Proc. of KAW’99, vol-

ume 2, pages 7.1.1–7.1.20.

Baget, J. and Mugnier, M. (2002). Extensions of Sim-

ple Conceptual Graphs: the Complexity of Rules and

Constraints. JAIR, 16(12):425–465.

Beckert, B., Keller, U., and Schmitt, P. H. (2002). Translat-

ing the Object Constraint Language into First-order

Predicate Logic. In Proc.of VERIFY, Workshop at

FLoC’02.

Booch, G., Jacobson, C., and Rumbaugh, J. (1998). The

Uniﬁed Modeling Language - a reference manual. Ad-

dison Wesley.

Chein, M. and Mugnier, M. (1992). Conceptual Graphs:

Fundamental Notions. Revue d’intelligence artiﬁ-

cielle, 6(4):365–406.

Chein, M. and Mugnier, M. (1997). Positive nested con-

ceptual graphs. In Proc. of ICCS’97, volume 1257 of

LNAI, pages 95–109. Springer.

Chein, M. and Mugnier, M. (2004). Concept types and

coreference in simple conceptual graphs. In Proc. of

ICCS’04, volume 3127 of LNAI. Springer.

Chein, M., Mugnier, M., and Simonet, G. (1998). Nested

Graphs: A Graph-based Knowledge Representation

Model with FOL Semantics. In Proc. of KR’98, pages

524–534. Morgan Kaufmann Publishers.

Genest, D. (2008). Cogitant Reference Manual, version

5.1.92. http://cogitant.sourceforge.net.

Gogolla, M., Bttner, F., and Richters, M. (2007). USE: A

UML-Based Speciﬁcation Environment for Validating

UML and OCL. Science of Computer Programming,

69:27–34.

Lukichev, S. and Wagner, G. (2006). Visual Rules Model-

ing. In Proc. of ICPSI’06. Springer.

OMG. Object Constraint Language, Version 2.0.

http://www.omg.org/spec/OCL/2.0/.

OMG. Production rule representation. Technical report.

br/2003-09-03.

OMG. Speciﬁcation for the UML 2 modeling language.

http://www.omg.org/spec/UML/2.1.2/.

Raimbault, T., Genest, D., and Loiseau, S. A New Method

to Interrogate and Check UML Class Diagrams. In

Proc. of ICCS’05. Springer.

Raimbault, T., Genest, D., and Loiseau, S. (2009). A useful

logical semantics of UML for querying and checking

UML class diagram. In Proc. of ICAART’09, pages

179–184. Insticc Press.

Rhem, A. J. (2006). UML for Developing Knowledge Man-

agement Systems. New York, Auerbach Publications.

Sowa, J. (1984). Conceptual Structures: Information Pro-

cessing in Mind and Machine. Addison Wesley.

USING UML CLASS DIAGRAM AS A KNOWLEDGE ENGINEERING TOOL