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 benefits
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
1
-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 Specific
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 specifica-
tions/code. Many automated approaches have been
proposed in the literature for the design of a well fac-
torized hierarchy out of a flat set of classes, for the
restructuring of an existing one in order to improve
its factorization level or for the composition of class
1
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
2
. 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
2
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
Copyright
c
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 ”flow” 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
3
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 final 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.
3
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
E
P
XX
X
X
X
XX
XX
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 defined by
X
= {p P |∀e X, (e, p) I}. Symmetrically,
any property set Y P has an image in E defined by
Y
= {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 first 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 find their names, role names, and the classes they
link. Attributes and operations can also be consid-
ered like first-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
owns
owner
owner
account
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 first 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
X
Formal context for associations
ownsCBH−CA
X
X
ownsM−MA
X
originRole=owner
name=owns
assoc
P
destRole=account
origType=CBH
origType=M
destType=CA
destType=MA
XX
XX
XX
properties
Relational
E
assoc
X
Formal context for classes
properties
classes
P
classes
X
X
originOf(ownsCBH−CA)
Relational
M Mortgager
CBH CheckBookHolder
X
X
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
E
XX
X
X
X
XX
X
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 definition of class Account. The process stops
there because no new generalization appears in next
steps. For a formal definition 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
X
X
X
X
X
X
XX
XX
Relational
E
assoc
P
assoc
properties
destType=Account
X
X
account
account
owner
owner
owns
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
4
(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
5
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
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
4
http://www.objecteering.com.
5
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}
{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 first case (upper part of Figure 9), the asso-
ciations have not been taken into account, hence the
merge of the two classes Subscribing client
6
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 modified diagram as
it does not declare any specific attribute or operation.
This is where the knowledge of the UML diagram de-
signer gets essential.
Though ICG has proved useful for the improve-
6
In the restructured hierarchy, classes corresponding to
owner
owns
X
X
destOf(NEWowns)
X
X
originOf(NEWowns)
properties
classes
P
classes
X
X
originOf(ownsCBH−CA)
Relational
M Mortgager
CBH CheckBookHolder
X
X
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
E
XX
X
X
X
XX
XX
New evolution of class context
Account
....
CheckBookHolder CheckAccount
Mortgager
MortgageAccount
....
....
owns
owner account
{subset}
{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 final 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
G
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 difficult 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 prefixed 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
1
*
11..*
*1
civil status : undefined
mail address : undefined
bank account number : undefined
method of payment : undefined
civil status : 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 benefits
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 defining 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 modified 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 modified di-
agram;
mapping classes of the modifieddiagram to the cor-
responding classes of the initial diagram;
finding in the initial diagram all the attributes or
operations of a class from the modified 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
1
1
*
*
1..*
Figure 9: Different results of ICG.
finding in the modified diagram all the attributes or
operations of a class from the initial diagram.
In the following sections we first briefly 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 modified 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 modified 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 definition of the
attribute or the operation in the modified 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-
ified diagram. Thus, the function displays a sub-
graph of the modified 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 figure 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 definition of the
operation getSupport that remains declared in the
modified 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 modified 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 elements
**
sets ensembles
**
Figure 11: A factorized association and the corresponding
initial associations.
5 CONCLUSION
We have presented here the first 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 efficiently 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-
fluenced in a purposeful manner. Finally, the prob-
lems we met with naming conflict resolution during
the UML model encoding step suggest that the use of
natural language techniques could be helpful for ter-
minology clarification purposes.
This work has shown that the use of advancedtech-
niques such as RCA may benefit 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., Arfi, 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 Specification. 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