high-level views in object-oriented software using formal concept analysis

High-Level Views in High-Level Views in Object-Oriented Software Object-Oriented Software

using Formal Concept Analysisusing Formal Concept Analysis

Gabriela B. ArévaloGabriela B. Arévalo

LIRMM - Séminaire D’OC - 9/02/06LIRMM - Séminaire D’OC - 9/02/06

Abstract Z

B C

D

P

CZ

D B

P

LIRMM 2/32Séminaire D'OC

Who I am …Who I am …

1999: Licenciatura en Informática Universidad Nacional de La Plata, Argentina

2000: Master in the EMOOSE Program Ecole des Mines de Nantes (France) and Vrije Universiteit Brussels (Belgium)

2005: Ph.D. in Computer Science Universitaet Bern (Switzerland)

2006: Postdoc in LIRMM Université de Montpellier (France)

From 1995 - … Research and Teaching Assistant in different research groups.


RoadmapRoadmap

Dependencies in Maintenance Dependencies in Maintenance of Object Oriented Systemsof Object Oriented Systems

Goals of the ApproachGoals of the Approach

Introduction to Formal Introduction to Formal Concept Analysis Concept Analysis

High-Level ViewsHigh-Level Views

Achievement of Goals and Achievement of Goals and ConclusionsConclusions

Abstract Z

B C

Abstract Z

D

B C

P

Abstract Z


Maintenance of Software SystemsMaintenance of Software Systems

Software System: Laws of Continuing Change and Increasing Complexity

Maintenance of software systems

50% to 75 % of the total cost

Reading and Analysis of Software:

½ time of maintenance phase

We need to detect Implicit Contracts between software components in a system

50% - 75 %

50%


The system is like a puzzleThe system is like a puzzle

No precise and updated documentation

Pieces have no order at all

Structure is not obvious

H A ?

Working System

Partial Information


Dependencies in Object Oriented SystemsDependencies in Object Oriented Systems

Dependency is the Dependency is the glueglue between the objects between the objects

Reuse

Data Encapsulation

Delegation

Dynamic Binding

Inheritance

Polymorphism Explicit Dependency:

Direct inheritance relationship between two classes

Implicit Dependency:

Method lookup in a chain of superclasses

Appear several times

Do not appear isolated

Can appear at different abstraction levels


High-Level Views based on Formal High-Level Views based on Formal Concept Analysis (FCA)Concept Analysis (FCA)

P

C

Z

D B

Formal Concept Analysis as a

base tool

High Level Views

Abstract Z

B C

D

P

Object Oriented Systems


Goals of High-Level Views (1/2)Goals of High-Level Views (1/2)

How can we detect implicit unanticipated How can we detect implicit unanticipated

dependencies ?dependencies ?

How can we discover defects introduced in the How can we discover defects introduced in the

systemssystems

How can we discover recurring situations How can we discover recurring situations

(patterns-like) of dependencies ?(patterns-like) of dependencies ?

Is the mental model with Is the mental model with high-level viewshigh-level views

meaningful enough to understand the system?meaningful enough to understand the system?

H A ?


Goals of High-Level Views (2/2)Goals of High-Level Views (2/2)

Is FCA an easy-to-use clustering technique ?Is FCA an easy-to-use clustering technique ?

Is FCA scalable ?Is FCA scalable ?

Is there any limit in the use of the technique ?Is there any limit in the use of the technique ?

Is the interpretation of the results an automatic Is the interpretation of the results an automatic

process ?process ?

H A ?


Formal Concept Analysis in a NutshellFormal Concept Analysis in a Nutshell

TraitsTraits PatternsPatterns FCAFCA MetricsMetrics RERE

OscarOscar xx xx

StephaneStephane xx xx

MarianneMarianne xx xx

GiulianoGiuliano xx xx xx

SanderSander xx xx

MicheleMichele xx xx

{Giuliano}, {Patterns, FCA, RE}Bottom

Top

{Oscar, Stephane},

{Traits, Patterns}

{Oscar, Stephane, Giuliano}, {Patterns}

ELE

ME

NT

SPROPERTIES

Lattice: Partial Order

Top

Bottom

More Elements

Less Properties

Less Elements

More Properties


Our MethodologyOur Methodology

<

Source Code

Magnitude Integer

Inheritance

Model Import

Source code model

Magnitude isAbstract

<self send = ….. >

FCA Mapping

Elements and Properties

ConAn Engine

Concept Lattice

Post-Filtering

Meaningful Concepts

= = =

Magnitude

<=

Analysis

High Level Views

Modelling

Interpretation


High Level ViewsHigh Level Views

Abstract Z

B C

Abstract Z

D

B C

P

XRay Views: Class Level

Hierarchy Schemas: Class Hierarchy Level

Collaboration Patterns: Application Level

Abstract Z



Abstract Z

Abstract Z

Abstract Z

B C

D

B C

P




Which methods access attributes ?

Which methods are used internally ?

Which methods are heavily used ?

How methods and attributes collaborate ?


Formal Concept Analysis on ClassesFormal Concept Analysis on Classes

Analysis of Accesses to State

usesuses aa bb cc dd ee

m1()m1() xx xx xx

m2()m2() xx xx xx

m3()m3() xx xx

m4()m4() xx

m5()m5() xx

m6()m6() xx xx

Properties: Access to instance variables

Ele

me

nts

: m

eth

od

sAbstract Z

Class A

a, b, c, d, e

m1() { .. a .. b .. d }m2() { .. a .. b .. e }

Bottom

Top

(m1,m2),

(a,b)

(m1,m3,m6), (d)

(m1), (a,b,d)


X-Ray Views on ClassesX-Ray Views on Classes X-Ray View is a set of collaborations to show patterns based on the state and behavior

Abstract Z

representBinaryOn:beforeremoveFirst

addLast:add:after:

notEmpty:includes:at:put:changeSizeTo:

firstIndex

lastIndex

addFirst:

Ordered Collection

Collaborating Attributes

add:Interface

Exclusive Accessors

Collaborating Methods


Validation: Case StudiesValidation: Case StudiesAbstract Z

OrderedOrdered

CollectionCollection

ScannerScanner UIBuilderUIBuilder

AttributesAttributes 22 1010 1818

MethodsMethods 5656 2424 122122

XRay Views

State Usage

External/Internal Calls

Behavioral Skeleton

XRay View: State Usage State of the class is not exposed to the clients Naming conventions in the methods Cohesive Collaboration 20 of 56 methods access systematically all the state


Wrap-up on XRay ViewsWrap-up on XRay Views

Use of FCAUse of FCA

Compact Representation of the dataCompact Representation of the data

Partial Information of the ConceptsPartial Information of the Concepts

Meaningless Concepts (concepts with Meaningless Concepts (concepts with

only one property)only one property)

Overlapping of InformationOverlapping of Information

Opportunistic Code ReadingOpportunistic Code Reading

Class FunctionalityClass Functionality

Class as a sole development unitClass as a sole development unit

XRay Views



Abstract Z

Abstract Z

B C



Abstract Z

D

B C

P


Which classes define and use their own state ?

Which classes uses state defined in superclasses ?

Which classes reuse or extend behavior of their superclasses ?


Hierarchy SchemasHierarchy Schemas

B C

m1 { ... }m2 { ... }... { self m1 }... { super m3 }

m1 { ... }m4 { ... }... { self m1 }... { self m4 }... { super m3 }

Am3 { .... }

m2 {<abstract>}

m4 {<abstract>}

B define m2 and C defines m4 (abstract in A)

B and C calls m3 defined in A via a super call

B and C have a similar structure


Formal Concept Analysis on Class Formal Concept Analysis on Class HierarchiesHierarchies

selfself supersuper ancestorancestor locallocal descendantdescendant

m1m1 xx xx

m2m2 xx xx xx

m3m3 xx xx xx

m4m4 xx xx xx

Type of calls – Definer Class

invo

cati

on

s

Elements: Invocations

Properties: type of calls and hierarchical relationships with definer class

B Cm1 { ... }m2 { ... }... { self m1 }... { super m3 }

m1 { ... }m4 { ... }... { self m1 }... { self m4 }... { super m3 }

Am3 { .... }

m2 {<abstract>}

m4 {<abstract>}


Discovering Bad Smell Schema: Discovering Bad Smell Schema: Cancelled BehaviorCancelled Behavior

Concrete local or inherited methods

Via-self call

Cancelled in subclasses.

Method cancellation: code reuse without regarding for subtyping.

Calling cancelled methods can provoke runtime errors

add: { .. self addLast: .. }

addLast: { <concrete> }

OrderedCollection

addLast: { <cancelled> }

Sorted Collection

addLast: { <concrete> }

FontDescriptionBundle


Validation: Case StudyValidation: Case Study

ClassicalClassicalReuse of superclass behavior (111 instances)Reuse of superclass behavior (111 instances)

Bad SmellBad SmellCancelled Local or Inherited Behavior (6 Cancelled Local or Inherited Behavior (6 instances)instances)

IrregularitiesIrregularitiesInherited and Local Invocations (15 instances)Inherited and Local Invocations (15 instances)

Class: Collection

Essential part of Smalltalk & Heavy use of subclassing

104 classes in 8 levels of inheritance

2162 defined methods

3117 invocations

1146 accesses to state


Wrap-up on Hierarchy SchemasWrap-up on Hierarchy Schemas

Use of FCAUse of FCAPerformance of the AlgorithmPerformance of the Algorithm

Partial Usage of LatticePartial Usage of Lattice

Mapping from Concepts to SchemasMapping from Concepts to Schemas

Filtered out non-invoked methodsFiltered out non-invoked methods

Hierarchy Schemas:

Analysis of State and Behavior

Identify irregularities and bad smell schemas

Main constraints of a class in a class hierarchy



Abstract Z

D

B C

P


Abstract ZXRay Views: Class Level

Abstract Z

B C


Are known design patterns implemented in a system ?

Can we discover new patterns ?

Do they occur several times ?


Collaboration PatternsCollaboration Patterns

P

Abstract A

Abstract X

B C

Y Z

T

D Collaboration Patterns: Common structural aspects between classes


(1,2)(1,2)SubSub (3,2)(3,2)SubSub (1,2)(1,2)AccAcc (3,2)(3,2)AccAcc (2)(2)AbsAbs

(C,A,P)(C,A,P) xx xx xx xx

(C,A,B)(C,A,B) xx xx xx xx

(Z,X,P)(Z,X,P) xx xx xx

(Z,X,Y)(Z,X,Y) xx xx xx xx

Ele

me

nts

:

Tu

ple

s o

f cl

asse

s

Properties: Relationships between classes

1 3

(1,2)Subclass

(3,2)Subclass

(2)Abstract

(3,2)Accesses

2

C P

A

Z Y

X

,=

A

C P

2

1 3

Formal Concept Analysis on Formal Concept Analysis on Object-Oriented ApplicationsObject-Oriented Applications


Selected Collaboration Selected Collaboration PatternsPatterns

A A

A A

Tuple: 3 Classes

4 Classes

A A

Tuple: 3 classes

4 Classes

Tuple: 3 Classes

4 Classes

Attribute Star

Composite Bridge

A

A

Attribute Chain

Tuple: 3 Classes

Tuple: 4 Classes


Validation: Case StudiesValidation: Case Studies

ADvance: ADvance: multidimensional OOAD-multidimensional OOAD-tool (tool (www.io.com/~iccwww.io.com/~icc))

CodeCrawler: language CodeCrawler: language independent software independent software visualization tool (visualization tool (www.iam.unibe.ch/~scgwww.iam.unibe.ch/~scg))

ADvanceADvance CodeCrawlerCodeCrawler

Number of Number of ClassesClasses

167167 8181

Number of Number of MethodsMethods

27192719 10771077

Lines of CodeLines of Code 1446614466 48684868

ADvanceADvance CodeCrawlerCodeCrawler

Computation Computation Time Time

(3 Classes)(3 Classes)ca. 1 hourca. 1 hour ca. 30 minca. 30 min

Concepts Concepts (before filter)(before filter) 120120 6565

Concepts Concepts (after filter)(after filter) 5757 3232


Evaluation of ResultsEvaluation of Results

ClassesClasses as Center of Systems as Center of Systems

CodeCrawler: CCTool is in none of patternsCodeCrawler: CCTool is in none of patterns

CCNodePlugin is in 47 patterns up to order = 4CCNodePlugin is in 47 patterns up to order = 4

Identify candidates of design patternsIdentify candidates of design patterns

Advance: 6 instances of Composite, 37 instances of Advance: 6 instances of Composite, 37 instances of BridgeBridge

CodeCrawler: 19 instances of BridgeCodeCrawler: 19 instances of Bridge

Coding Styles: frequency of some patternsCoding Styles: frequency of some patterns

CodeCrawler: heavy use of Attribute Star and FaçadeCodeCrawler: heavy use of Attribute Star and Façade

Advance: CompositeAdvance: Composite


Wrap-up on Collaboration PatternsWrap-up on Collaboration Patterns

Collaboration PatternsCollaboration PatternsDetect class dependenciesDetect class dependencies

Detect presence of classical design patternsDetect presence of classical design patterns

Mining PatternsMining Patterns

Understand class rolesUnderstand class roles

Identify Coding StylesIdentify Coding Styles

Use of FCAUse of FCAPerformance of AlgorithmPerformance of Algorithm

Meaningless conceptsMeaningless concepts

Multiple ContextsMultiple Contexts

Mapping Partial OrderMapping Partial Order


We achieved the goals ...We achieved the goals ... High-Level ViewsHigh-Level Views

Development of a general methodologyDevelopment of a general methodology

Detected Implicit Dependencies with FCADetected Implicit Dependencies with FCA

Discovered defects in the systemDiscovered defects in the system

Discovered patterns Discovered patterns

Metamodel InformationMetamodel Information

Use of FCA [ICFCA `05] Modelling software entities as FCA components

Performance of FCA algorithms

Interpretation of Concepts

Use of Complete Lattice

Use of Partial Order


A good application of FCA ….A good application of FCA ….

High-level ViewsHigh-level Views: XRay Views, Hierarchy : XRay Views, Hierarchy

Schemas, Collaboration PatternsSchemas, Collaboration Patterns

Development of a methodology Development of a methodology

Tool support of the Methodology: ConAnTool support of the Methodology: ConAn

Analysis of advantages and constraintsAnalysis of advantages and constraints

Interpretation without any mathematical Interpretation without any mathematical

knowlegeknowlege

high-level views in object-oriented software using formal concept analysis

Documents