This presentation summarizes research on recovering binary class relationships from source code. It defines association, aggregation, and composition relationships based on their properties. Algorithms are presented to recover relationships by analyzing source code statically and dynamically. The approaches were validated on Java frameworks, achieving high precision and recall for composition relationships and moderate recall for aggregation relationships. Future work is proposed on detecting other UML elements and further experimental validation.

1. This presentation has been given at OOPSLA, the 27th of October 2004, in Vancouver, BC, Canada.
Recovering Binary Class Relationships:
Putting Icing on the UML Cake
Yann-Gaël Guéhéneuc
Hervé Albin-Amiot
Département d’informatique
École des Mines de Nantes
Software Engineering Laboratory
Department of Computing Science and Operations Research
University of Montreal © Yann-Gaël Guéhéneuc and Hervé Albin-Amiot

2. Statements
n Maintenance
– 50% of the total cost of a program
n Program understanding
– 50% of the maintainers’ time
n Anyhelp in understanding a program
would reduce its cost!
2/32

3. Context
n OO maintenance
– Source code
• Most accurate source of information
– Design models
• Useful to understand source code
(architecture of a program)
• Non-existent or obsolete
n Classdiagrams help in understanding
3/32 source code

4. Approach
n Automated recovery of class diagrams
from program source code
– Extract relevant information
– Operational semantics for relevant
constituents of class diagram
– Consistent mapping
• Concepts in programming languages
• Concepts in modeling languages
4/32

5. Problem
n Use of our approach on Java and UML
– UML class diagrams
• Only a notation! As emphasised during the
panel on “Model Driven Architecture”
– Mapping
• Semantic continuity for some concepts, such as
classes, fields, methods
• Discontinuity for binary class relationships
5/32

6. Problem (cont’d)
Java
Should be recovered as
Is recovered as
6/32

7. Problem (cont’d)
Java
Should be recovered as
Is recovered as
6/32

8. Proposal
n Studyof the reverse-engineering of
binary class relationships
– “Consensual” definitions
• At design-level
• At implementation-level
– Properties
– Formalisations
– Recovery algorithms
7/32

9. Proposal (cont’d)
n Studyof the reverse-engineering of
binary class relationships
– Mapping between programming and
modeling languages
– Sound foundations
• Understanding
• Round-tripping
• Design patterns identification
• … and much more!
8/32

10. Overview
n Motivations
n Formalisations
n Recovery
n Validations
n Conclusion
9/32

11. Definitions
n Up to now, no consensual definitions
n Study of more than 30 definitions
n “Consensual” definitions
Link Relationship
Is described by
Origin Means Target Origin Name Target
Instance Direct Instance Entity Association Entity
Instance Field Instance Class Aggregation Entity
Instance Field + Instance Class Composition Entity
Lifetime property
“Entity” denotes either a class or an interface
10/32

12. Definitions
n Association
– At design-level
• Conceptual link between two classes
• Multiple instances can be involved
– At implementation-level
• Message sends between instances of two
classes, an origin and a target
• Oriented, irreflexive, anti-symmetric at instance
and class level; asymmetric at instance level
11/32

13. Definitions
n Aggregation
– At design-level
• An aggregation relationship is an association
between two classes: The whole and the part
– At implementation level
• An aggregation relationship exists between
classes A and B when the definition of A, the
whole, contains instances of B, its part
12/32

14. Definitions
n Composition
– At design-level
• Aggregation where parts are destroyed when
their whole is destroyed
• Parts might be instantiated before the whole
and exchanged
– At implementation level
• Aggregation with constraint on the lifetimes and
on the ownership of the whole and of its part
13/32

15. Properties
n Four minimal properties
– Exclusivity, an instance of B (b) is in
relation with only one instance of A (a)
– Invocation site, for method invocations
from a to b
– Lifetime, time of destruction of b wrt. a
14/32
– Multiplicity, number of b’s for one a

16. Properties
n Four minimal properties
– Exclusivity, EX(A, B) ∈
– Invocation site, IS(A, B) ⊆ {field, parameter,
local variable, …}
– Lifetime, LT(A, B) ∈ {+, −}
– Multiplicity, MU(A, B) ⊂ N ∪ {+∞}
15/32

17. Formalisations
n Rewritingbinary class relationships as
conjunctions of their properties
n Association
AS(A, B) =
(EX(A, B) ∈ B) ∧ (EX(B, A) ∈ B) ∧
(IS(A, B) ⊆ {field…}) ∧ (IS(B, A) = ∅) ∧
(LT(A, B) ∈ {+, −}) ∧ (LT(B, A) ∈ {+, −}) ∧
(MU(A, B) = [0, +∞]) ∧ (MU(B, A) = [0, +∞])
16/32

18. Formalisations
n Aggregation
AG(A, B) =
(EX(A, B) ∈ B) ∧
(EX(B, A) ∈ B) ∧
(IS(A, B) ⊆ {field, array field, collection field}) ∧
(IS(B, A) = ∅) ∧
(LT(A, B) ∈ {+, −}) ∧
(LT(B, A) ∈ {+, −}) ∧
(MU(A, B) = [0, +∞]) ∧
17/32
(MU(B, A) = [1, +∞])

19. Formalisations
n Composition
CO(A, B) =
(EX(A, B) = true) ∧
(EX(B, A) = false) ∧
(IS(A, B) ⊆ {field, array field, collection field}) ∧
(IS(B, A) = ∅) ∧
(LT(A, B) = +) ∧
(LT(B, A) = −) ∧
(MU(A, B) = [1, +∞]) ∧
18/32
(MU(B, A) = [1, 1])

20. Formalisations
n Emergent characteristics
– Minimality of the set of properties
• See p. 307 of the proceedings
– Order among binary class relationships
• Association
• Aggregation
• Composition
– Static and dynamic parts
• IS(A, B), MU(A, B)
19/32
• EX(A, B), LT(A, B)

21. Overview
n Motivations
n Formalisations
n Recovery
n Validations
n Conclusion
20/32

22. Recovery
n Binary class relationships
– Not syntactical constructs in source code
– Expressed with four minimal properties
n Recovery
– Computation of the properties
– Inference of existing relationships
21/32

23. Recovery
n Algorithms
– Static analyses
• IS(A, B), MU(A, B)
– Dynamic analyses
• EX(A, B), LT(A, B)
22/32

24. Recovery
n Algorithms
– Order among the relationships
– Association
• IS(A, B) with respect to other classes
– Aggregation
• MU(A, B) with respect to associated classes
– Composition
• EX(A, B)
with respect to aggregated classes
• LT(A, B)
23/32

25. Overview
n Motivations
n Formalisations
n Recovery
n Validations
n Conclusion
24/32

26. Model +
Associations,
PDL / PADL
Implementations aggregations,
and composition
Caffeine
n Meta-model
Model +
– PDL / PADL Associations, PDL / PADL
aggregations
n Static analyses
– PatternsBox / Ptidej PatternsBox / Ptidej
n Dynamic analyses Model PDL / PADL
– Caffeine
Dedicated parser
Bytecodes
25/32 Java

27. Experimentations
n Case studies
– Java AWT v1.2.2
• 367 classes
– JHotDraw v5.1
• 171 classes
– JUnit v3.7
• 45 classes
26/32

28. Experimentations
n Association
– 4,925 for 583 classes but required for aggregation
n Aggregation
Frameworks Found Manual False Hits
Java AWT 17 20 1
JHotDraw 6 8 0
JUnit 1 4 0
Total 24 32 1
Recall: 0.75 Precision: 0.96
n Composition
27/32
– Precision and recall of 100% (JUnit only)

29. Experimentations
n Emergent characteristics
– Quantitative
• Possible metrics
– Qualitative
• Assessment
• Comparison
– Practicality
28/32

30. Overview
n Motivations
n Formalisations
n Recovery
n Validations
n Conclusion
29/32

31. Conclusion
n Any help in understanding a program
would reduce its cost
n Automated recovery of class diagrams
from program source code
n Mapping for binary class relationships
– “Consensual” definitions
– Formalisations
– Recovery algorithms
30/32

32. Related work
n Civello at OOPSLA 1993
– Classification of binary class relationships
– No operational semantics
n Henderson-Sellers and Barbier in L’Objet 1999
– Properties
– Design-level
n Jackson and Waingold at ISCE 1999
– Operational semantics
31/32
– Flavours of association, aggregation only

33. Future work
n Detection of other UML constituents
n Static analyses vs. dynamic analyses
n Experimental validations
– Maintainers
– Class diagrams with/without binary
class relationships
32/32