TOWARDS PRACTICAL TOOLS FOR

MINING ABSTRACTIONS IN UML MODELS

M. Dao

France T´el´ecom R&D/MAPS/AMS

38-40 rue du g´en´eral Leclerc – 92794 Issy Moulineaux Cedex 9, France

M. Huchard

LIRMM, CNRS et Universit´e Montpellier II, UM 5506

161 rue Ada – 34392 Montpellier cedex 5, France

M. Rouane Hac`ene, C. Roume, P. Valtchev

DIRO, Universit´e de Montr´eal

C.P. 6128, Succ. “Centre-Ville” – Montr´eal, Qu´ebec, Canada, H3C 3J7

Keywords: Formal concept analysis, UML class diagram, Galois lattice.

Abstract: We present an experiment in applying an extension of Formal Concept Analysis to UML class model restruc-

turing. The Relational Concept Analysis (RCA) mines potentially useful abstractions from UML classes, at-

tributes, operations and associations and therefore outscores competing restructuring techniques which usually

focus exclusively on classes. Nevertheless, the complexity and the size of the RCA output require interactive

tools to assist the human designers in comprehending the corresponding class model. We discuss the beneﬁts

of using RCA-based techniques in the light of an initial set of tools that were devised to ease the navigation

and the visual analysis of the results of the restructuring process.

1 INTRODUCTION

Current trends in object-oriented software construc-

tion, namely MDA

-based approaches (Object Man-

agement Group, 2003; Mellor et al., 2004), pro-

mote designing high-level models concerned with do-

main and application concepts (”Platform Indepen-

dent Models”) which are belatedly mapped to the

target implementation platform (”Platform Speciﬁc

Models”). This emphasizes the importance of the

model construction activity and, hence, the design of

tools to support it.

One of the highly desirable properties of a class

model is the right use of relevant abstractions, al-

lowing readability and maximal factorization of the

underlying hierarchical structure, i.e., the optimal

use of inheritance to avoid duplication of speciﬁca-

tions/code. Many automated approaches have been

proposed in the literature for the design of a well fac-

torized hierarchy out of a ﬂat set of classes, for the

restructuring of an existing one in order to improve

its factorization level or for the composition of class

Model-Driven Architecture.

hierarchies (Moore, 1996; Casais, 1995; Snelting and

Tip, 2002).

Our work is based on Formal Concept Analysis

(FCA) which is a mathematical approach towards

clustering and categorization (Ganter and Wille,

1999). FCA discovers useful abstractions from (indi-

viduals × properties) data expressed as binary tables,

the formal contexts. The abstractions, called (formal)

concepts, are hierarchically organized into a lattice,

the concept lattice of the context

. FCA has been

successfully applied to the refactoring of class hier-

archies, with classes and class members substituted

to individuals and properties, respectively (Godin

and Mili, 1993). Nevertheless, taking full advan-

tage of the expressive power of UML (Rational Soft-

ware Corporation, 1999; Object Management Group,

2004) requires relational information — e.g., associa-

tions that relate two or more classes, attributes whose

type is a class, operations whose parameter and re-

turn types are classes — to be successfully processed.

However, this sort of knowledge about entities is far

An excellent introduction to lattice theory is provided

in (Davey and Priestley, 2002).

276

Dao M., Huchard M., Rouane Hacène M., Roume C. and Valtchev P. (2006).

TOWARDS PRACTICAL TOOLS FOR MINING ABSTRACTIONS IN UML MODELS.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 276-283

DOI: 10.5220/0002447502760283

 SciTePress

beyond the scope of the classical FCA framework.

Taking into account all the structural knowledge en-

coded into a class model was the motivation behind

the relational extension of FCA (RCA) as described

in (Valtchev et al., 2003b; Dao et al., 2004). RCA re-

lies on a data model comparable to E-R as it is made

of a set of individual types, each introduced by its

own context, and a set of inter-context relations. The

underlying algorithmic method, called ICG, struc-

tures the individuals of each type into a concept lat-

tice where the concepts are described both by the

shared properties of their member individuals and by

the links to concepts from related contexts. The key

advantage of RCA is that it allows the abstraction

knowledge to ”ﬂow” among related contexts: the dis-

covery of a new concept on one context triggers the

formation of new concepts on every related context.

In the software engineering translation of RCA, the

individualsare instances of relevant UML meta model

(meta)classes. For the sake of simplicity, the theoreti-

cal description is restricted in this paper to classes and

associations: the set of classes and of associations are

assigned a type each while a collection of relations

express the various aspects of the incidence between

a class and an association. The whole framework, ap-

plied in the experience, also considers abstractions of

properties and operations.

In this paper we describe an industrial experience of

applying RCA to software engineering tasks. The ex-

perience was carried out within the MACAO project

and consisted of the restructuring of a set of class di-

agrams of different UML models. The key challenge

here was not that much the processing of the relevant

knowledge and the extraction of abstractions as the

sorting of the newly created elements in the ﬁnal dia-

gram to select only relevant and useful ones. To assist

the user in inspecting these elements, we provided a

set of tools that postprocess the results of RCA on a

UML diagram and that allow the designer to browse

those results more easily.

Section 2 is a brief introduction to both the classi-

cal FCA and its relational version, RCA. Section 3

presents the way ICG was applied in our experiment

whereas section 4 discusses the issues related to the

analysis of the obtained results.

A joint project of France T´el´ecom, SOFTEAM and

LIRMM, supported by the french department of research

and industry (RNTL).

2 ICG: A NEW METHOD FOR

MINING ABSTRACTIONS IN

RELATIONAL DATA

The method ICG is rooted on FCA techniques. Clas-

sical FCA aims at mining concepts in a set of entities

described by properties. It has been successfully used

in several software engineering applications for class

hierarchy analysis (Snelting and Tip, 2000; Ar´evalo

and Mens, 2002) or construction (Godin and Mili,

1993; Dicky et al., 1996; Godin et al., 1998; Huchard

et al., 2000).

However, as detailed below, classical FCA is un-

able to process interrelated entity descriptions like

those extracted from a UML class diagram. This was

the key motivation behind the design of RCA and its

main algorithmic method, ICG.

2.1 Classical Formal Concept

Analysis

Entities and their description

cr credit()

ci calculateInterest()

d debit()

i interestRate

b balance

nb number

MA MortgageAccount

CA CheckAccount

Formal context

calculateInterest()

credit()

interestRate

balance

number

MortgageAccount

debit()

credit()

balance

number

CheckAccount

Figure 1: A formal context describing classes.

In classical FCA, a set of concepts provided with

a specialization order (the concept or Galois lattice)

emphasizes commonalities in descriptions (by prop-

erty sets) of entities. Concepts emerge from a formal

context K =(E,P, I ) where E is the entity set, P the

property set and I associates an entity with its proper-

ties: (e, p) ∈ I when entity e owns property p. Figure

1 provides an example of context, where entities are

classes and properties are their attributes and opera-

TOWARDS PRACTICAL TOOLS FOR MINING ABSTRACTIONS IN UML MODELS

277

tions (in the table representing I, abbreviations are

proposed to be used below).

Any entity set X ⊆ E has an image in P deﬁned by



= {p ∈ P |∀e ∈ X, (e, p) ∈ I}. Symmetrically,

any property set Y ⊆ P has an image in E deﬁned by



= {e ∈ E |∀p ∈ Y, (e, p) ∈ I} . In the example,

let Y = {nb, b},wehaveY



= {CA, M A}, while

for X = {CA, M A}, X



= {nb,b,cr}.

A concept is a pair (X, Y ) where X ⊆ E,

Y ⊆ P , X



= Y and Y



= X. In Figure 1,

{{CA, M A}, {nb,b,cr}} is a concept. X (resp. Y )

is usually called the extent (resp. intent) of the con-

cept.

The specialization order between concepts corre-

sponds to extent inclusion (or intent containment). In

Figure 2, the concept {{CA}, {nb,b,cr,d}} special-

izes the concept {{CA,MA}, {nb,b,cr}}. Figure 2

shows the whole concept lattice (top) and an inter-

pretation of concepts as UML classes (bottom). In

this UML interpretation, a new Account class ap-

pears, which corresponds to the top concept of the

lattice. This can be considered as a learned abstrac-

tion. Class hierarchies constructed using this tech-

nique have several strong properties including max-

imal property factorization and conformity between

inheritance links and property set inclusion.

debit

calculateInterest

interestRate

MortgageAccountCheckAccount

credit()

balance

number

Account

{}

{nb,b,i,cr,d,ci}

{CA}

{nb,b,cr,d}

{MA}

{nb,b,i,cr,ci}

extent

intent

{CA,MA}

{nb,b,cr}

UML interpretation

Concept lattice

Figure 2: Top: The concept lattice for account concepts.

Bottom: The corresponding interpretation in UML class

model.

2.2 Relational Concept Analysis

Although powerful, classical FCA fails taking into

account realistic UML diagrams that contain inter-

related entities. Consider for example the very sim-

ple extension of our ﬁrst example shown in Figure

3. Classes Check Account and MortgageAccount

are involved in associations, called owns with similar

role names. Description of classes now also depends

on other entities, namely associations, as classes are

involved in association ends. Similarly, considering

associations as entities, among their properties, we

can ﬁnd their names, role names, and the classes they

link. Attributes and operations can also be consid-

ered like ﬁrst-class entities, described by properties

including their name, type, parameter type list, etc.

The types being classes, this description here also de-

pends on entities of another sort.

CheckBookHolder CheckAccount

Mortgager

MortgageAccount

....

owns

owner

account

Figure 3: Extending the account example.

In RCA, this sort of data is introduced as a Re-

lational Context Family (RCF), a family of contexts

(one for each sort of entity) provided with inter-

context relations linking entities of two sorts. In

the case of UML diagrams, a basic RCF includes a

context for classes and another one for associations,

where a set of relational properties model the inci-

dence between classes and associations. For instance,

a relation will link a class to an association if objects

at the end of the association are instances of the class.

ICG is a method for extracting formal concepts out

of a RCF. It performs iterative lattice construction on

all contexts of the RCF doubled by an enrichment of

entity descriptions. Thus, at each step, the contexts

are extended to incorporate the conceptual knowl-

edge learned at the previous step. Figure 4 shows a

RCF for the extended account example which is com-

posed of a class context (top) and an association con-

text (bottom). Relational properties like originO f or

origT ype have been included in the binary tables (in

italics).

At the ﬁrst construction step, class context is pro-

cessed, producing the new Account class seen be-

fore (Figure 2 bottom) but no concept (then no class

at interpretation step) for generalizing M and CBH

which have nothing common. Before processing the

association context, the fact that a new class has

been constructed is integrated. Figure 5 shows how

the association context is extended by a new column

destT ype = Account in order to precise that, as

instances at the end of owns associations links are

(respectively) from classes CA and MA, they are

also, thanks to class specialization, instances of the

new class Account. Constructing the concept lattice

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

278

Formal context for associations

ownsCBH−CA

ownsM−MA

originRole=owner

name=owns

assoc

destRole=account

origType=CBH

origType=M

destType=CA

destType=MA

properties

Relational

assoc

Formal context for classes

properties

classes

originOf(ownsCBH−CA)

Relational

M Mortgager

CBH CheckBookHolder

destOf(ownsM−MA)

destOf(ownsCBH−CA)

originOf(ownsM−MA)

cr credit()

ci calculateInterest()

d debit()

i interestRate

b balance

nb number

MA MortgageAccount

CA CheckAccount

Figure 4: A partial relational context family for the ex-

tended account example.

will produce a concept interpreted as a new associ-

ation, refered later as NEWowns that generalizes

ownsCBH − CA and ownsM − MA (Figure 6).

Returning to the class context, this new association

NEWowns will be ”shared” by classes M , CBH,

MA and CA in two ways. Firstly, instances of M

and CBH can be origins of ownsCBH − CA or

ownsM − MA links then they can also be origins of

links of an association that represents their disjunc-

tion. This appears in Figure 7 (top) where M and

CBH own the property originOf (NEWowns).

This results in a new class, we call it Client,

which generalizes M and CBH. Secondly, classes

MA and CA now share the newly added property

destOf(NEWowns), which then will be integrated

in the deﬁnition of class Account. The process stops

there because no new generalization appears in next

steps. For a formal deﬁnition of RCA and ICG the

reader is referred to (Huchard et al., 2002; Valtchev

et al., 2003b; Dao et al., 2004).

3 APPLYING ICG ALGORITHM

TO REAL WORLD MODELS

The ICG procedurehas been implemented in the Java-

based GALICIA platform (Valtchev et al., 2003a).

Enhancement of the association context

ownsCBH−CA

ownsM−MA

name=owns

originRole=owner

destRole=account

origType=CBH

origType=M

destType=CA

destType=MA

Relational

assoc

properties

destType=Account

account

owner

owns

....

MortgageAccount

Mortgager

CheckAccountCheckBookHolder

....

Account

Evolution of classes

Figure 5: Integrating Account class in the association con-

text.

The implementation has been connected to the UML

CASE tool Objecteering

(part of the MACAO

project) thus enabling the application of ICG to UML

class diagrams designed within Objecteering. Thus,

for a given diagram, derived relational contexts are

exported

in a format which is readable by GALICIA.

ICG within the platform is run and its results are im-

ported back in Objecteering in order to create a new

class diagram which is then studied and compared to

the original one.

We present here some results of the application

of ICG to several medium-sized projects of France

T´el´ecom. The projects pertained to different applica-

tion domains: information systems, intranet software

and user data model for telecommunication services.

Moreover, among the corresponding UML class dia-

grams there were both analysis-level and design-level

models.

Once constructed, the resulting class diagrams

were shown to the designers of the initial models who

gave an appreciation as to the pertinence of the pro-

posed restructuringwith respect to underlyingdomain

semantics. Class hierarchies of those projects consist

of several dozens of classes while the number of new

UML elements created by ICG (attributes, operations,

classes, inheritance links) may vary from a few to sev-

eral hundreds in some cases. Many new factorization

http://www.objecteering.com.

A limited parametrization of the constitution of the re-

lational contexts is possible within Objecteering.

TOWARDS PRACTICAL TOOLS FOR MINING ABSTRACTIONS IN UML MODELS

279

account

owner

owns

{subset}

....

accountowner

owns

....

MortgageAccount

Mortgager

CheckAccountCheckBookHolder

....

Account

Evolution of associations

{name=owns,originRole=owner,destRole=account,

destType=Account}

{ownsCBH−CA,ownsM−MA}

{name=owns,originRole=owner,destRole=account,

originType=CBH,destType=CA,destType=Account}

{ownsCBH−CA}

{name=owns,originRole=owner,destRole=account,

originType=M,destType=MA,destType=Account}

{ownsM−MA}

Concept lattice of associations (without bottom)

account

owner

owns

Figure 6: A new owns association appears.

classes or associations proposed by ICG were found

absolutely useful by the class diagram designers.

The diagram of Figure 8 shows the initial state of a

small part of a class hierarchy. The gray background

of the three right-hand-side classes indicates that they

are in a different package. The ICG algorithm was

applied once exclusively on the package containing

the four target classes and once on both packages.

In the ﬁrst case (upper part of Figure 9), the asso-

ciations have not been taken into account, hence the

merge of the two classes Subscribing client

and Owning client that declare only the attribute

civil status. Class Paying client inher-

its from this class and declares the additional at-

tributes that it declared in the initial diagram. In

the second case (lower part of Figure 9), a new

class Fact217 has been created by the algorithm

to factorize the attribute civil status of classes

Paying client, Subscribing client and

Owning client. It is noteworthy that the associ-

ations ending on those three classes (has >, sends

>, owns >) ensure that classes Subscribing

client and Owning client remain present in

the new class hierarchy. Indeed, civil status

should be declared in the initial class Client but

the ICG algorithm has no way to detect such a fact:

Client does not appear in the modiﬁed diagram as

it does not declare any speciﬁc attribute or operation.

This is where the knowledge of the UML diagram de-

signer gets essential.

Though ICG has proved useful for the improve-

In the restructured hierarchy, classes corresponding to

owner

owns

destOf(NEWowns)

originOf(NEWowns)

properties

classes

originOf(ownsCBH−CA)

Relational

M Mortgager

CBH CheckBookHolder

destOf(ownsM−MA)

destOf(ownsCBH−CA)

originOf(ownsM−MA)

cr credit()

ci calculateInterest()

d debit()

i interestRate

b balance

nb number

MA MortgageAccount

CA CheckAccount

New evolution of class context

Account

....

CheckBookHolder CheckAccount

Mortgager

MortgageAccount

....

owns

owner account

{subset}

Client

New evolution of classes

account

owner

owns

account

Figure 7: A new Client class appears.

ment of the project class diagrams, it also brought

to the spot some problems or shortcomings, most

of which admitted straightforward solutions. First,

the present parameter settings of the ICG algo-

rithm may result in the creation of numerous classes

whose only function is to factorize some very gen-

eral information. For instance, in the whole ICG

framework, including attribute generalization, a class

could be created to factorize the existence of an at-

tribute of type integer (it declares only newAttrib:

integer;). The same goes for all types of attributes

used in the class diagram, for operations and for as-

sociations. For the time being, we have chosen to re-

move those “information-less” classes in the CASE

tool, once the ﬁnal UML hierarchy has been created.

It should also be possible to directly modify the ICG

algorithm but this would also impact other uses of the

ALICIA environment.

FCA and, as a result, RCA approaches rely essen-

tially on the name of the entities and properties on

which they operate. This may lead to the situation

where two attributes (or any model element, for that

matter) of the same name are factorized by the ICG

algorithm into a single one, although they correspond

to two different pieces of data. Therefore, ICG may

provide some support in detecting naming problems.

Last, the amount of new information (new classes,

new inheritance links, moving of properties, etc.)

generated by the algorithm may be difﬁcult to analyze

by the designer of the class diagram. The next section

describes a set of tools that have been developed in

initial classes have the same name preﬁxed by an @.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

280

Paying client

civil status : undefined

mail address : undefined

bank account number : undefined

method of payment : undefined

Subscribing client

civil status : undefined

Owning client

civil status : undefined

::Entities::Telecom service::Invoice account

::Entities::Order::Order form

::Entities::Telecom service::Telecom Service

Client

11..*

civil status : undefined

mail address : undefined

bank account number : undefined

method of payment : undefined

civil status : undefined

sends >

has >

owns >

Figure 8: Initial class diagram.

order to assist the class diagram designer during the

analysis of the ICG results.

4 HELPING A DESIGNER TO

ANALYZE RESULTS OF THE

ICG ALGORITHM

The previous section has shown the potential beneﬁts

of using the ICG algorithm on existing UML class di-

agrams in order to suggest improvementsin the struc-

ture of the class hierarchy. Nevertheless, the experi-

ments described have been carried out by a software

engineering practitioner and not by the model design-

ers themselves. Depending on the initial class dia-

gram, the resulting diagram may be substantially dif-

ferent from the initial one: many factorization classes

(classes deﬁning properties that are inherited by other

classes) may be created, an initial class may be split

into several new classes, etc. Thus, it is not always

straightforward for a class designer using the tool to

retrieve the information present in the initial class di-

agram.

The main goal of this part of our work was there-

fore to develop a set of interactive tools that would

help a designer to browse and to analyze both the ini-

tial and the modiﬁed class diagram. The ultimate goal

is a tool that can be used by UML model designers on

their own. We have so far implemented the following

functions:

• mapping elements of the initial diagram (class, at-

tribute, operation, association) on the modiﬁed di-

agram;

• mapping classes of the modiﬁeddiagram to the cor-

responding classes of the initial diagram;

• ﬁnding in the initial diagram all the attributes or

operations of a class from the modiﬁed diagram;

@Subscribing client_@Owning client

civil status : undefined

@Paying client

method of payment : undefined

bank account number : undefined

mail address : undefined

civil status : undefined

method of payment : undefined

bank account number : undefined

mail address : undefined

@Paying client

mail address : undefined

method of payment : undefined

bank account number : undefined

@Subscribing client

@Holding client

@Telecom service

@Order form

@Invoice account

Fact217

civil status : undefined

mail address : undefined

owns >

sends >

has >

civil status : undefined

method of payment : undefined

bank account number : undefined

1..*

Figure 9: Different results of ICG.

• ﬁnding in the modiﬁed diagram all the attributes or

operations of a class from the initial diagram.

In the following sections we ﬁrst brieﬂy describe

the implementation and the interface of some of the

above functions and then expand on the use of two of

them.

4.1 Implementation and Interface of

Some Functions

Given a class of the initial diagram, its matching class

from the modiﬁed diagram is the class that has ex-

actly the same properties. At the end of the ICG al-

gorithm the mapping between initial classes and the

matching class is known. In order to easily retrieve

the matching class, the initial class contains a tagged

value which is initialized with the name of the match-

ing class. Thus, the underlying mapping function sim-

ply consists in the output, in a new window, of the

matching class.

The declaration of an attribute or an operation that

was in a given class of the initial diagram may have

been moved to another class in the modiﬁed diagram:

this is what ICG is expected to do. A function has

been implemented in the CASE tool which gathers

all the classes that contribute to the deﬁnition of the

attribute or the operation in the modiﬁed diagram.

TOWARDS PRACTICAL TOOLS FOR MINING ABSTRACTIONS IN UML MODELS

281

4.2 Analyzing the Factorization of

Attributes and Operations

We have implemented a function that allows to show

how all the attributes and operations of a class of

the initial diagram have been dispatched in the mod-

iﬁed diagram. Thus, the function displays a sub-

graph of the modiﬁed class diagram containing the

classes where the properties of the initial class are

declared. Figure 10 shows an example of such a re-

sult. The left-hand-side of the ﬁgure shows the ini-

tial class RLink with all its attributes and opera-

tions. The right-hand-side shows the result retrieved

by the CASE tool function. For instance, the class

Fact375 has been created to factorize the attribute

comment and the access operations getComment

and setComment. The class allows the informa-

tion embedded in comment to be shared with other

classes having these properties. Likewise the class

Fact378 factorizes the operation getNetwork

and the class Fact380 factorizes both the operation

getTopology and a more general deﬁnition of the

operation getSupport that remains declared in the

modiﬁed class RLink.

RLink

getSupport()

get Ed ges ()

toCopy : string

getDestination()

toDelete : string

initPF()

comment : string

createEdges()

getExtremities()

toDisplay()

get Origin ()

getComment()

setComment()

getTopology()

removeEdges()

getNetwork()

@RLink

initPF()

toCopy : string

getSupport()

getDestination()

toDelete : string

removeEdges()

createEdges()

getO rigin( )

getEdges ()

toDisplay()

getExt remit ies ()

initPF()

Fact369

toCopy : string

Fact380

getSupport()

getTopology()

getSupport()

toCopy : string

getTopology()

Fact375

comment : string

setComment()

getComment()

Fact370

toDelete : string

Fact374

initPF()

Fact365

initPF()initPF()

initPF()

toDelete : string

comment : string

setComment()

getComment()

Fact382

initPF()

Fact378

getN et work()toCopy : string

getSupport()

getDestination()

toDelete : string

initPF()

removeEdges()

createEdges()

getO rigin( )

getEdges ()

getN et work()

toDisplay()

getExt remit ies ()

Figure 10: Example of display of all properties of an initial

class.

4.3 Analyzing the Factorization of

Associations

As for the classes and the properties (attributes and

operations), a function allows an association of the

initial diagram to be highlighted in the modiﬁed di-

agram. Figure 11 (upper part) shows an example of

the use of this function: the association between the

initial classes RMacroLink and RUniLink repre-

sents the fact that a RMacroLink contains several

RUniLink and, conversely, that a RUniLink may

belong to several RMacroLink. The association has

been factorized to another one, connecting the new

classes Fact393 and Fact394.

The existence of the factorization classes points out

that some other classes must share the factorized as-

sociation between them. Another function allows to

shows from a factorized association all the initial as-

sociations that it has factorized. This is depicted in

Figure 11 (lower part) where three initial associa-

tions (inclusive the one between RMacroLink and

RUniLink) are shown. This allows the designer to

analyze and to question the factorization.

Fact393 Fact394

@RMacroLink @RUniLink

elementssets

RUniLinkRMacroLink

RUniN odeRMacroNode

RTNode RTZone

sets elements

sets ensembles

Figure 11: A factorized association and the corresponding

initial associations.

5 CONCLUSION

We have presented here the ﬁrst results of the appli-

cation of an extension of FCA to “real world” UML

class diagrams. This extension allows us to take into

account richer set of elements from the UML meta-

model (e.g., associations, properties, operations and

classes as types of model elements) thus improving

the proposed factorization of the inspected class dia-

grams. Class diagram designers have found a large

number of relevant factorization propositions among

those suggested by the ICG algorithm. Even factor-

izations that were not immediately recognized as use-

ful highlighted some modeling problems that the de-

signers were not aware of. In order to help designers

cope with the potential complexity of the class dia-

grams produced by the algorithm, we developed a few

interactive tools for browsingclass sets efﬁciently and

visually analyze them.

Future research sould focus on both ICG method

and tool support for the exploration and analysis of

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

282

the results. First, it would be interesting to provide

a more precise and thorough tuning of the ICG algo-

rithm. In particular, the possiblity of ignoring part of

the model elements (for instance, some attributes) in

the abstraction process should be granted to the ICG

user. This would allow the designer to enforce multi-

ple declarations. As shownin the paper, the ICG algo-

rithm may produce numerous so-called “information-

less” model elements. It is desirable for the designer

to be able to tune the generation of such elements.

Moreover, a run-time interaction with the designer

would allow the evolution of the algorithm to be in-

ﬂuenced in a purposeful manner. Finally, the prob-

lems we met with naming conﬂict resolution during

the UML model encoding step suggest that the use of

natural language techniques could be helpful for ter-

minology clariﬁcation purposes.

This work has shown that the use of advancedtech-

niques such as RCA may beneﬁt to UML class dia-

gram designers. However, it requires high-level in-

teractive tools to assist them in the analysis and the

interpretation of the RCA results.

REFERENCES

Ar´evalo, G. and Mens, T. (2002). Analysing Object-

Oriented Application Frameworks Using Concept

Analysis. In Bruel, J.-M. and Bellahs`ene, Z., editors,

Advances in Object-Oriented Information Systems -

OOIS 2002 Workshops, number 2426 in LNCS, pages

53–63. Springer.

Casais, E. (1995). Managing Class Evolution in Object-

Oriented Systems. In O.Nierstrasz and D.Tsichritzis,

editors, Object-Oriented Software Composition, pages

201–244. Prentice Hall.

Dao, M., Huchard, M., Rouane Hac`ene, M., Roume, C., and

Valtchev, P. (2004). Improving Generalization Level

in UML Models: Iterative Cross Generalizat ion in

Practice. In Pfeiffer, H. and Wolff, K. E., editors, Pro-

ceedings of the 12th Intl. Conference on Conceptual

Structures (ICCS’04), volume 3127 of Lecture Notes

in Computer Science, pages 346–360. Springer Ver-

lag.

Davey, B. A. and Priestley, H. A. (2002). Introduction to

Lattices and Order. Cambridge University Press, 2nd

edition.

Dicky, H., Dony, C., Huchard, M., and Libourel, T. (1996).

On Automatic Class Insertion with Overloading. In

Special issue of Sigplan Notice - Proceedings of ACM

OOPSLA’96, pages 251–267.

Ganter, B. and Wille, R. (1999). Formal Concept Analysis,

Mathematical Foundations. Springer, Berlin.

Godin, R. and Mili, H. (1993). Building and Maintaining

Analysis-Level Class Hierarchies Using Galois Lat-

tices. In Proceedings of OOPSLA’93, Washington

(DC), USA, pages 394–410.

Godin, R., Mili, H., Mineau, G., Missaoui, R., Arﬁ, A., and

Chau, T. (1998). Design of Class Hierarchies Based

on Concept (Galois) Lattices. Theory and Practice of

Object Systems, 4(2).

Huchard, M., Dicky, H., and Leblanc, H. (2000). Galois

Lattice as a Framework to Specify Algorithms Build-

ing Class Hierarchies. Theoretical Informatics and

Applications, 34:521–548.

Huchard, M., Roume, C., and Valtchev, P. (2002). When

Concepts Point at other Concepts: the Case of UML

Diagram Reconstruction. In Proceedings of the 2nd

Workshop on Advances in Formal Concept Analysis

for Knowledge Discovery in Databases (FCAKDD),

pages 32–43.

Mellor, S. J., Scott, K., Uhl, A., and Weise, D. (2004). MDA

Distilled – Principles of Model-Driven Architecture.

Addison Wesley Professional.

Moore, I. (1996). Automatic Inheritance Hierarchy Re-

structuring and Method Refactoring. In Proceedings

of OOPSLA’96, San Jose (CA), USA, pages 235–250.

Object Management Group (2003). MDA-Guide, V1.0.1,

omg/03-06-01.

Object Management Group (2004). UML 2.0 Superstruc-

ture Speciﬁcation. ptc/04-10-02.

Rational Software Corporation (1999). UML v 1.3, Seman-

tics, version 1.3 edition.

Snelting, G. and Tip, F. (2000). Understanding Class Hier-

archies Using Concept Analysis. ACM Transactions

on Programming Languages and Systems, 22(3):540–

582.

Snelting, G. and Tip, F. (2002). Semantics-Based Compo-

sition of Class Hierarchies. In Magnusson, B., editor,

ECOOP 2002 - 16th European Conference on Object-

Oriented Programming,, volume 2374 of LNCS, pages

562–584. Springer.

Valtchev, P., Grosser, D., Roume, C., and Rouane Hac`ene,

M. (2003a). G

ALICIA: an Open Platform for Lat-

tices. In B. Ganter, A. d. M., editor, Using Concep-

tual Structures: Contributions to 11th Intl. Confer-

ence on Conceptual Structures (ICCS’03), pages 241–

254, Aachen (DE). Shaker Verlag.

Valtchev, P., Rouane Hac`ene, M., Huchard, M., and Roume,

C. (2003b). Extracting Formal Concepts out of Re-

lational Data. In SanJuan, E., Berry, A., Sigayret,

A., and Napoli, A., editors, Proceedings of the 4th

Intl. Conference Journ´ees de l’Informatique Messine

(JIM’03): Knowledge Discovery and Discrete Math-

ematics, Metz (FR), 3-6 September, pages 37–49. IN-

RIA.

TOWARDS PRACTICAL TOOLS FOR MINING ABSTRACTIONS IN UML MODELS

283