Class Analysis with Concept Lattices

Class Analysis with Concept Lattices

Uri DekelDepartment of Computer Science

Technion, Haifa, Israel

2

Outline Introduction Formal Concept Analysis Stage I – Interface Analysis Stage II – Implementation Analysis Stage III – Code Inspection Version Comparison Overview of other FCA applications

3

Domain Understanding and analyzing individual Java

classes Interface (black-box) analysis

Reducing the learning curve Discovering interface problems

Implementation (white-box) analysis Understanding class structure and role of fields Discovering implementation problems

Code review and inspection Understanding the purpose of each method from its code. Ensuring style, quality, and correctness Discovering code reuse opportunities

Version Comparison

4

Problems Classes can be very large and complex

OOP practices promote use of many methods Meyer’s “shopping list approach” advocates

completing the interface with “syntactic-sugar” methods

“Rules of software evolution”: The entropy of software artifacts increases with time

Delocalisation Definition order not meaningful

Fact: A quarter of all public methods are found in classes with more than 100 methods !

5

Research Question Can Formal Concept Analysis (FCA) help

alleviate some of these problems? FCA is a mathematical classification technique

Helps discover meaningful data in binary relations Can be visualized with Concept Lattices

FCA has been applied to many CS and SW problems

Automatic modularization Automatic construction and refinement of class

hierarchies Reverse engineering complex systems Smart component repositories

6

Formal Concept Analysis Input: A context <O,A,R>

O is a set of objects A is a set of attributes R is a binary relation between O and A

Mapping: Galois Connection Common attributes of a set of objects:

Common objects of a set of attributes:

Output: Concepts s.t.

RaoOoAaOOCA ,:''

RaoAaOoAACO ,:''

',' AO

')'(')'(OACOAOCA

7

FCA Example Field-accesses context of a class

Objects are fields, attributes are methods, relation specifies which methods access each field

Pnt3D getX setX getY setY setXY getZ setZ setXYZ getColor setColor drawx √ √ √ √ √ √y √ √ √ √ √ √z √ √ √ √ √

color √ √ √ √

Objects

Attributes

Concept Objects AttributesC1 {} {Pnt3D, getx, setx, getY, setY, setXY, getZ, setZ, setXYZ, getColor, setColor, draw}C2 {color} {Pnt3D, getColor, setColor, draw}C3 {x} {Pnt3D, getX, setX, setXY, setXYZ, draw}C4 {y} {Pnt3D, getY, setY, setXY, setXYZ, draw}C5 {x,y} {Pnt3D, setXY, setXYZ, draw}C6 {z} {Pnt3D, getZ, seZ, setXYZ, draw}C7 {x,y,z} {Pnt3D, setXYZ, draw}C8 {x,y,color,z} {Pnt3D, draw}

Context:

Concepts:

8

Concept Lattices Partial order:

Defines domination between concepts Visualized as a concept lattice

21212211 ,, AAOOAOAO

xgetX() setX()setXY() Pnt3D()setXYZ() draw()

C3

getX() setX() getY() getY() setXY() Pnt3D()getColor() setColor() getZ() setZ() setXYZ() draw()

C1

x ysetXY() Pnt3D() setXYZ() draw()

C5

Pnt3D() setXYZ() draw()x y z C7

x y color zPnt3D() draw()

C8

colorgetColor()setColor()Pnt3D() Draw()

C2 ygetY() setY()setXY() Pnt3D()setXYZ() draw()

C4 zPnt3D() getZ()setZ() setXYZ()draw()

C6

9

Interpreting Class Lattices We use only sparse lattices

Economical but equivalent representation Each object introduced in lowest concept Each attribute introduced in highest concept

Interpretation: Each method uses all fields introduced

in the same concept or below Reveals:

Possible restructuring Asymmetry between coordinates

colorgetColor()setColor()

setXY()

setXYZ()

Pnt3D()draw()

zgetZ()setZ()

xgetX()setX()

ygetY()setY()

10

Field-Accesses Context Field usage is critical for understanding a class

All implementations of an operation use the same fields Representation changes are rare Methods that use the same combination are related

Can be calculated directly from the .class file Allows some reverse engineering without source code

Calculated using standard static analysis Currently restricted to accesses inside the class

11

Lattices vs. Tables The lattice and the accesses table contain

exactly the same information! Advantages of the table:

It is immediately clear what fields are accessed by each method.

Advantages of the lattice: Related methods appear together. Makes it easier to:

Discover what exactly each method does. Discover duplicate methods. Find inconsistencies. Determine level of abstraction.

12

Graph example Accesses tables (only a part is visible)

Visibility Method Nameprivate adjustGroupChildren_(Node,dbl,dbl,dbl,dbl,dbl):void vpublic children(int):Set vpublic copy(Graph):void v v v v vpublic dummysToEdgePaths():void v v v v vprivate fillBackEdges_():void vpublic firstAvailable():int vpublic firstNode():Node vpublic firstNodeIndex():int vpublic getEdge(int,int):edge vpublic getEdgePathPoints(int,int):Dpoint3 vpublic getEdges():Enumeration vpublic getIndexFromNode(Node):intpublic getNodeFromId(int):Node vpublic getNodeFromIndex(int):Node vpublic Graph() v v v v v

last

TopI

d_ i

nt

Fields

dire

cted

_ bo

olea

n

idHa

sh_

Hash

tabl

e

node

List

_ No

deLi

st

edge

s_ H

asht

able

13

Graph example (cont.)

getIndexFromNode(Node):int

(PRV) fillBackEdges_():voidgetEdges():EnumerationgetEdge(int,int): EdgegetEdgePathPoints(int,int):DPoint3removeEdgePaths():void(PRV) removeFalseEdges_():void isDirected():boolean

setDirected(boolean):voidinsertEdge(Edge):void

pack():void

insertNodeAt(int):void(PRV) validateIds_():voidinsertNode():intinsertNode(boolean):int

insertEdge(int,int):voidinsertEdge(int,int,DPoint3[]):voidinsertEdge(int,int,DPoint3[],String):voidremoveEdge(int,int):voidremoveEdge(Edge):voidsetGMLvalues(GMLobject):void

copy(Graph):voiddummysToEdgePaths():voidkillGroup(Node):voidGraph()Graph(boolean)Graph(GMLobject)removeGroups():voidremoveNode(int):voidremoveNode(Node):voidsetNodeGroup(Node, Node):void

getNodeFromId(int):Node

(PRV) adjustGroupChildren_(Node, dbl, dbl, dbl,..., dbl):voidchildren(int):SetfirstAvailable():intfirstNode():NodefirstNodeIndex():int(PRV) getGroupCoordinates_(Node,DPoint3,DDimension3):intgetNodeFromIndex(int):Nodegroup(Node, boolean):voidhighestIndex():int(PRV) markGroupChildren_(Node,boolean):voidnextNode(Node):NodenextNodeIndex(int):intnodeFromIndex(int):NodenumberOfNodes():intparents(int):Set

C2

C1

C5

C4

C3

C7 C8

C9C6

C10

(PRV) idHash_:HashTable

(PRV) nodeList:_NodeList

(PRV) edges:_HashTable

(PRV) directed_:boolean

(PRV) lastTopId_:int

14

Class Assignment Try to find as many problems as possible in

the Molecule class. Examples:

Duplicate methods. Different methods that do the same thing (not composites!).

Inconsistencies in types and names between methods. Asymmetries in the interface. Invariants that are violated. Methods which do not access the fields you expect them

to. Assume that:

All methods are documented. Some methods declare and throw exceptions.

15

Zoom-in Zoom-out approach

Problems: Concept lattices can be very large

Number of concepts is bound by Polynomial for most real-life contexts Linear for 99.5% of classes!

Elaborate member details are cumbersome Solution:

Provide (semi-) automatic zoom in/out tools

AO ,min2

Appropriate contextselection, then FCA

Full signaturesSource code

Auxiliary informationEmbedded call graph Horizontal decomposition

Cluster conceptsName conceptsHide signatures

Zoom In Zoom Out

16

Running Example The Molecule class from CDK

CDK: Chemistry Development Kit Open source library of chemistry related classes Developed at the Max Plank institute in Germany Used in chemistry visualization applications

Why the Molecule class? Has a large interface (nearly 75 public members) The represented entity is familiar to most people

Methodology was successfully applied to other classes as well

Our methodology revealed several new bugs and issues !

Stage I: Interface Analysis“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning…”

--Rich Cook“There are only two industries that refer to theircustomers as ‘users’…”

-- Edward Tufte

18

Interface Analysis Purpose:

Understand the functionality provided by the class Map expectations into interface members

The “concept assignment” or “feature mapping” problems Discover problems

e.g. missing or superfluous functionality, exposed implementation details, inconsistent naming

Methodology: Methods are partitioned into concepts

Heuristic for automatic feature categorization Zoom-out and reason about overall structure Zoom-in and examine specific functionalities

19

Preliminaries Mapping features to interface members

requires knowing what the features are Tasks:

Surmising abstraction, purpose and role Determining vocabulary Predicting mandatory- and non-mandatory

functionality Information sources:

Domain-specific knowledge Class environment

E.g. hierarchy, dependencies, etc. This step is not unique to concept analysis

20

Context Selection Only client-visible methods should be used

Public methods by default, protected if client is subclass, default if client is in the same package

All fields are kept to ensure a correct partitioning Will be removed after the lattice is constructed

Context parameters: (boldface indicates selection)Parameter Options Parameter Options Parameter Optionsstatic y | n | Φ field read y | n | Φ static y | n | Φpublic-access y | n field write y | n | Φ public-access y | nprotected-access y | n protected-access n | yprivate-access y | n private-access n | ydefault-access y | n default-access n | y

(bold indicates our selection, Φ represents”don’t care” )

21

Constructing the Lattice The lattice is too cluttered to grasp

immediately We start zooming-out Layers correspond to

levels of abstraction

contains(Bond):booleangetBond(Atom,Atom):BondgetBonds():Bond[]getBondCount(Atom):intgetBondOrderSum(Atom):intgetConnectedAtoms(Atom):Atom[]getConnectedAtomsVector(Atom):VectorgetConnectedBonds(Atom):Bond[]getDegree(Atom):intgetHighestCurrentBondOrder(Atom):doublegetMinimumBondOrder(Atom):doubleremoveBond(Bond):BondremoveBond(int):BondremoveBond(Atom,Atom):boolean

atoms():EnumerationshallowCopy():Object

addListener(ChemObjectListener):voidremoveListener(ChemObjectListener):void

getRemark(Object):ObjectsetRemark(Object,Object):void

add(AtomContainer):voidaddBonds(double):voidclone():ObjectgetIntersection(AtomContainer):AtomContainerremoveAllElements():void

Molecule()Molecule(AtomContainer)Molecule(int,int)Molecule(Molecule)

flags:boolean[]

pointers:Vector[]

contains(Atom):booleanget2DCenter():Point2Dget3DCenter():Point3DgetAtoms():Atom[]getAtomNumber(Atom):intgetLastAtom():AtomremoveAtom(Atom):voidremoveAtom(int):void

addAtom(Atom):void getDegree(int):int

getConnectionMatrix():double[][]remove(AtomContainer):voidremoveAtomAndConnectedBonds(Atom):voidtoString()::String

addBond(int,int,int):voidaddBond(int,int,int,int):void

addBonds(AtomContainer):voidaddBond(Bond):voidremoveAllBonds():void

setProperty(Object,Object):voidgetProperty(Object):Object

setPhysicalProperty(Object,Object):voidgetPhysicalProperty(Object):Object

addChemName(String):voidgetChemName(int):StringgetChemNames():VectorgetChemNamesCount():intsetChemNames(Vector):void

getBeilsteinRN():StringsetBeilsteinRN(String):void

getCasRN():StringsetCasRN(String):void

getAutonomName():StringsetAutonomName(String):void

getFirstAtom():AtomsetAtomAt(int,Atom):voidgetAtomAt(int):AtomsetAtoms(Atom[]):void

getAtomCount():intsetAtomCount(int):void

getBondAt(int):BondsetBondAt(int,Bond):voidsetBonds(Bond[]):void getBondCount():int

title:StringgetTitle():StringsetTitle(String):void

C2 C3 C4 C5 C6 C7C8

C9 C10C11

C12C13

C14C15

C1

C21

C23

C24 C25

C20

C17

C22

C16

C18 C19

C26

22

Simplifying concepts We summarize the responsibilities of each

concept in a quick skim over method signatures This process cannot be fully-automated at

present Still too cluttered !

Retrieving and removing bonds.Calculating bond order.

Calculating atom degree.Obtaining connected atoms.

Calculating degree of anatom specified by index

Add ing single bond object.Adding and removing multiple bonds.

Retrieving and removing atoms.Retrieving the serial number of an atom.

Calculating centerpoints.

Maintaining"remarks"

Maintaining"properties"

"Atom Count"property EmptyAccessing individual atoms.

Access bond by index.Set collection of bonds. Count bonds

"CasRN"property

"beilsteinRN"property

Complexmaintenance of

"chemical names""autonomName"

property"title" property (public

field and methods)

Shallow copy. Enumerating Atoms.

Add single atom

Adding single bond between atoms.s

Get "Connections Matrix".Remove atoms with connected bonds.

Conversion to string.

Maintaining"physical

properties"Maintaining"listeners"

Cloning, adding and merging bonds,adding atoms with connected bonds,

complete element removal.

Public "flags" field.Constructing molecules,

Public "pointers" field

C11

C2 C3C4

C5 C6 C7C8

C9 C10

C12

C13C14

C15

C1

C16

EmptyC26

C17

C18C19 C20

C21

C22

C23

C24

C25

23

Naming Concepts Name concepts based on summary

Use symbolic representations for common responsibilities

{physicalproperty}

Index-based atom degree

shallow copy | #atom

{listener}{remark} {property}{{chemical

name}}@autonom

name {{bond}} @bondCount _title | @title{{atom}}@atomCount

{{atom}} | centerpoints

add bond

bind atomsadd atom "connection matrix" | toString | unbind atoms

{{bond}} | bond order |atom degree | connected atoms

clone | merge | intersect | clear

_flags | CONS

_pointers

@beilsteinRN@casRNC2 C3

C4

C5 C6 C7

C8 C9

C10 C11C12

C13 C14 C15

C16 C26 C17

C19

C21

C23

C22

C20

C24

C18

C25

C1

Responsibility Legend_x an exposed field named x@x operate on a single x{x} operate on a single x in a collection{{x}} operate on multiple x's in a collection#x get an enumeration or iterator of x| additional responsibilityCONS constructor"x" x is an unfamiliar name.text free-text name

24

Horizontal Decomposition Remove top- and bottom- concepts

Connected components are orthogonal Problem with title (on the right) becomes obvious Abundance of trivial components implies record-like

behavior Cohesive component requires further analysis

{physicalproperty}


shallow copy | #atom

{listener}{remark} {property}{{chemical

name}}@autonom

name {{bond}} @bondCount _title | @title{{atom}}@atomCount

{{atom}} | centerpoints

add bond

bind atomsadd atom "connection matrix" | toString | unbind atoms


clone | merge | intersect | clear

_flags | CONS

_pointers

@beilsteinRN@casRNC2 C3

C4

C5 C6 C7

C8 C9

C10 C11C12

C13 C14 C15

C16 C26 C17

C19

C21

C23

C22

C20

C24

C18

C25

C1

25

Abstraction Lattice Heuristic for clustering concepts

Concepts dominated by the same top-layer concepts belong in the same cluster



atoms{{bond}} @bondCount

"connection matrix" | toString | unbind atoms

add bond

bind atoms

baseunknown

add atom

bonds

atom-bondentire-state

add bondadd atom

C18 C21 C22

C19 C20

C17

C12C13 C14

{{atom}} | centerpointsC16

@atomCountC10

{{atom}}C11

shallow copy | #atomC1

C26

clone | merge | intersect | clearC23

26

Match services against expectations

Functionality search order: Expected mandatory features Expected non-mandatory features Unexpected features

For each functionality: Mark relevant clusters Mark relevant concepts Examine each concept

Example: Bond management


getDegree(int):int



getBondAt(int):BondsetBondAt(int,Bond):voidsetBonds(Bond[]):void getBondCount():int

C13

C14

C20

C17

C22

C19

Bonds

Add Bonds

Stage II – Implementation Analysis

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.” C. A. R. Hoare

28

Implementation Analysis Purpose:

Understand implementation and structure. Discover problems

e.g. redundant fields, bad naming conventions, wrongly-implemented operations

Methodology: Code is not inspected at this stage!

All information derived from lattice Zoom-in:

Including private fields and methods Listing full signatures and introducing classes Embedded call-graph

29

Embedded Call Graph Superposition of call-graph on concept

lattice A semantics-based CG layout heuristic

Keeps related methods together while reducing crossings

Helps investigate relations between methods e.g. surmise level of abstraction or discover wrappers Used later for selecting an order for code inspection

Example: ECG of Pnt3DsetXYZ

getColor setColor getX setX getY setY

setXY

draw Pnt3D

getZ setZ

xcolor C3 y zC2 C4 C6

C1

C5

C8

C7

30

Investigate Fields Examine unused fields

Might indicate unimplemented stubs or dead structure

Discover the roles of fields Easy for trivial

components Harder for the

cohesive one Investigate

interdependency Naming quality




getDegree(int):int



addAtom(Atom):void

clone():ObjectaddBonds(double):voidremoveAllElements():voidadd(AtomContainer):voidgetIntersection(AtomContainer):AtomContainer

getBondCount():intbondCount:int

growArraySize:int


atoms:Atom[]

getBondAt(int):BondsetBondAt(int,Bond):voidsetBonds(Bond[]):void

bonds:Bond[]


atomCount:intC10

C11

C12 C13 C14

C16

C26

C17

C20

C22

C19

C21C18

C23

addListener(ChemObjectListener):voidremoveListener(ChemObjectListener):void

chemObjects:VectorC3

31

Investigate Special Methods

Methods that (should) use the entire state should be in the top concept Exceptions can indicate problems Zoom-in by adding declaring class details

Examine methodsthat do not use fields e.g. discover

undeclared statics contains(Bond):booleangetBondgetBondsgetBondCountgetBondOrderSumgetConnectedAtomsgetConnectedAtomsVectorgetConnectedBondsgetDegree(Atom):intgetHighestCurrentBondOrdergetMinimumBondOrderremoveBond(Bond):BondremoveBond(int):BondremoveBond(Atom,Atom):boolean

atomsshallowCopy

clone():Object

add(AtomContainer):voidaddBonds(double):voidgetIntersection(AtomContainer):AtomContainerremoveAllElements():void

Molecule()Molecule(AtomContainer)Molecule(int,int)Molecule(Molecule)

flags:boolean[]

contains(Atom):booleanget2DCenterget3DCentergetAtomsgetAtomNumbergetLastAtomremoveAtom(Atom):voidremoveAtom(int):void

addAtom getDegree(int):int

getConnectionMatrixremoveremoveAtomAndConnectedBondstoString


addBondsaddBond(Bond):voidremoveAllBonds

s

getAutonomNamesetAutonomName

C2 C3 C4 C5 C6 C7C8

C9 C10 C11C12

C13C14 C15

C1

C21

C23

C24 C25

C20

C17

C22

C16

C18 C19

C26

autonomNamegetRemarksetRemark

remarksaddListenerremoveListener

chemObjectssetPropertygetProperty

propertiessetPhysicalPropertygetPhysicalProperty

physicalPropertiesgetCasRNsetCasRN

casRN

addChemNamegetChemNamegetChemNamesgetChemNamesCountsetChemNames

chemNames

getBeilsteinRNsetBeilsteinRN

beilsteinRNgetAtomCountsetAtomCount

atomCountgetFirstAtomsetAtomAtgetAtomAtsetAtoms

atoms

growArraySizegetBondAtsetBondAtsetBonds

bondstitlegetTitlesetTitlegetBondCount

bondCount

pointers

ChemObjectMolecule

AtomContainer

cloning

constructors

shallowCopy

Molecule

AtomContainer

ChemObject

32

Investigate Other Methods Ensure symmetry where expected

e.g. C11 and C13, C10 and C14, C16 and C17 Ensure methods use expected access

patterns Add non-public

methods to lattice addBonds(AtomContainer):voidaddBond(Bond):voidremoveAllBonds():void



getDegree(int):int



addAtom(Atom):void

clone():ObjectaddBonds(double):voidremoveAllElements():voidadd(AtomContainer):voidgetIntersection(AtomContainer):AtomContainer

getBondCount():intbondCount:int

growArraySize:int


atoms:Atom[]

getBondAt(int):BondsetBondAt(int,Bond):voidsetBonds(Bond[]):void

bonds:Bond[]


atomCount:intC10

C11

C12 C13 C14

C16

C26

C17

C20

C22

C19

C21C18

C23

Stage III – Code Inspection

“Real programmers don't document. If it was hard to write, it should be hard to understand…”

--Anonymous

“Real programmers can write assembly code in any language…”

--Larry Wall

34

Code Inspection Purpose:

Understand functionality which is unclear after the previous stages.

Ensure quality of code and style Methodology:

Select an order for effective reading Maximizing reading throughput Maximizing discovered defects Minimizing repetitions

35

Code Inspection Problem Original source code order not effective

Co-definitions. No incremental order All class members are defined simultaneously

Perturbations to intended order Evolution and maintenance Language issues (e.g. inheritance) Style issues (e.g. public before private)

36

Reading Strategy Organize methods into groups of related

functionality and order these groups (global order)

Order the methods inside each group (local order)

Each concept is a group Same-concept methods are similar in purpose,

semantics and implementation Increased prospects of understanding differences

between methods and discovering redundancies and replications

Less infrastructure (e.g. external libraries) to memorize

37

Reading Strategy Global order (by importance)

Read each HD component separately Each represents an independent functionality

Read concepts in ascending order of layers Exploit similar level of abstraction

Read concepts of the same cluster together Local order (by importance)

Read methods in topological order Use restricted ECG

Read methods in same ECG component together Resolve equivalencies with “simplest-first”

rule

38

Inspection Tasks Inspection tasks customized for our reading

order Finding duplicate services inside a concept

e.g. getDegree and getBondCount Identifying code-sharing opportunities

e.g. overloads of addBond Verify that low-level methods

are not bypassed e.g. getBondCount, getBondAt

An addition to “standard”inspection tasks




getBondCount():intbondCount:intgetBondAt(int):Bond

setBondAt(int,Bond):voidsetBonds(Bond[]):void

bonds:Bond[]

Version Comparison

“Zero defects: The result of shutting down a production line…” --Kelvin Throop III, "The Management Dictionary"

40

Version Comparison Examine an outline of the differences before

the actual details Example:

Also useful for subclass/superclass comparisons

Concept #5

packing

"directed"

Bottom Concept.Single utility method.

"idHash" "nodeList" "edges"

Edge insertion and removal by node indices.Conversion to GML format moved to #18.

"lastTopId" field. Node insertions.

Concept #14Concept #12 Concept #13Concept #11

Concept #16

Concept #17 Concept #18

Concept #19

Concept #6

Concept #4

Concept #1

Concept #3 Concept #2

Concept #7

Concept #8Concept #9

"pathList" fieldmany methods.

"MaxViewedPaths"inspector & mutator

"pathDist"inspector & mutator

"lightPathRequest"inspector & mutator

Path creation. Conversion to GML format

New top concept. Contains the "copy" method.

mutator for "directed"edge object insertion

Concept #15

Empty concept

Path manipulation.

Old Top concept. Node removal. Group manipulation."copy" method moved to concept #19.

Concept #10

Differences between the original version of the “Graph” class of VGJ (Visualizing Graphs with Java) and the Technion adaptation of that class.Originals appear in bold font, Modifications appear in plain font

Other applications of FCA

42

Hierarchy Construction Godin and Mili (93) classified Smalltalk

classes: Objects: Names of concrete collection classes Attributes: Names of messages that these

classes accept.Collection Set Bag Sequenceable

CollectionDictionary Linked

ListArray

isEmpty x x x x x x xsize x x x x x x xincludes x x x x x x xadd x x x xremove x x xminus xadd WithOccurences

x

at x x x xat put x xatAllput xfirst x x xlast x x xaddFirst xaddLast xkeys xvalues x

43

Hierarchy Construction (cont.)

Output: Multiple inheritance class hierarchyCollection

{isEmpty, Size, includes}

{}{}

{}{at}

{}{add}

{}{remove}

{}{minus}

{}{}

{}{atPut}

{SequenceableCollection}{ first, last}

{LinkedList}{addFirst, addLast}

{Bag}{addWithOccurences}

{Set}{}

{Dictionary}{keys, values}

{Array}{atAllPut}

44


There are four types of concepts: Concrete concepts

Introduce both attributes and objects Intersect concepts

Introduce objects but no attributes Abstract concepts

Introduce attributes but no objects Connector (“empty”) concepts

Do not introduce objects or attributes Can be removed!

Collection{isEmpty, Size, includes}

{}{}

{}{at}

{}{add}

{}{remove}

{}{minus}

{}{}

{}{atPut}




{Set}{}


{Array}{atAllPut}


{}{add}

{}{remove}

{}{minus}

{}{atPut}




{Set}{}


{Array}{atAllPut}

45


Hierarchy after removing connectors and naming abstract concepts:


ExtensibleCollection{add}

RemovableCollection{remove}

SubtractableCollection{minus}

UpdateableCollection{atPut}

SequenceableCollection{ first, last}

LinkedList{addFirst, addLast}

Bag{addWithOccurences}

Set{}

Dictionary{keys, values}

Array{atAllPut}

46

Other Applications Modularizing legacy code

Objects: Global variables. Attributes: Functions. Lattice is horizontally decomposed, resulting in

modules. Managing component repositories:

Objects: Software components. Attributes: Text-based properties or features. Lattice includes all search paths.

The End

“Theory is when you know something, but it doesn't work. Practice is when something works, but you don't know why. Programming combines theory and practice: Nothing works and you don't know why…”

-- Anonymous

Documents

Class Analysis with Concept Lattices