FCA-SE 10
Formal Concept Analysis
used for
object-oriented software modelling
Wolfgang Hesse
FB Mathematik und Informatik, Univ. Marburg
FCA-SE 20
Contents
1 The role of concepts in software development
2 OO modelling: Aspects, methods and open
questions
3 Bridging the gap between use case analysis and
class & object modelling
4 FCA used for "crossing perspectives"
5 Other SE applications of FCA
6 Resume
References
FCA-SE 30
1 The role of concepts in software development
• Software development methods support the complex task of
.. gathering and analysing requirements
.. designing and structuring the software system
.. implementing (i.e. programming and integrating) the system
.. operating and improving the system
• Modelling is the central task for finding the adequate system structure
to fulfill the requirements
• Object-oriented modelling builds on concepts formed during
analysis of the application domain and to be maintained during system
design & implementation
FCA-SE 40
The SW development cycle
(acc. to the EOS* model)
Analysis
Use & Operations
Design
Implementation
Use
environment
Development
environment
* (for Evolutionary,
Object-oriented
Software development)
planning,
analytic
activities
synthetic,
verifying
activities
FCA-SE 50
Concepts everywhere …
Business
concepts
Domain
concepts
Process
concepts
Use & user
concepts
Maintenance
concepts
Analysis
Use & Operations
System
concepts
Design
Implementation
Design &
architectural
concepts
Programming
concepts
Test &
integration
concepts
FCA-SE 60
Citations on concepts …
James Rumbaugh:
"The objects in the model should be applicationdomain concepts ... ."
James Martin und James Odell:
"Object types are important, because they create
conceptual building blocks for designing systems.
[...] An object type is a concept."
Grady Booch:
"Key abstractions are the classes and objects
that form the vocabulary of the problem domain."
 Use Formal Concept Analysis (FCA) to form and evaluate the
concepts needed for software development
FCA-SE 70
2 Object-oriented modelling: Aspects and methods
Aspects of OO modelling
structural
behavioural
ontological
OO methods:
• support building an OO model and bringing together various aspects.
Recent, popular methods
• start with use cases ( behavioural aspect),
• recommend to detect objects & classes ( structural aspect),
• according to the intentions of system users and owners ( ontological
aspect).
FCA-SE 80
From use cases
to classes &
objects
FCA-SE 90
From use cases to classes & objects (2)
Open questions:
• Are use cases (formulated in user language) appropriate for finding a
good class & object structure? Are there promising alternatives?
• Where do the candidates for classes & objects come from? Are they
already "contained" or "hidden" in the use cases?
• Is the object list (I. Jacobson) an appropriate "medium"?
• What are the criteria to choose between class candidates? How can
we compare alternative class models?
• Is all this so easy as some authors suggest?
 ".. objects are there just for the picking." (B. Meyer in [Mey 88])
FCA-SE 100
Example of a use
case diagram
Wine trade business
Receive
order
Process
order
Clerk
<<include>>
Determine
inv. stock
Order missing
products
<<include>>
Create deliv.
instructions
<<include>>
Process inc.
delivery
Define max. & min.
stock quantity
Process delivery
results
FCA-SE 110
Formal Concept Analysis (FCA)
A theory for formally describing concepts and their relationships
Formal Context (G, M, I ):
G
(formal) objects ("things")
M
(formal) attributes
I G M
Incidence relation
AI := { m  M | g I m for all g  A }
the set of attributes common to all objects in A
BI := { g  G | g I m for all m  B }
the set of objects that have all attributes from B
Formal Concept
(A, B) with A  G, B  M and
AI = B und BI = A .
A the extent of a concept
B the intent of a concept
Sub- / super concept relation
(A, B) ≤ (C, D)
iff A  C ( D  B )
FCA-SE 120
3 Bridging the gap:
The BASE approach
Use cases
• describe functionality
• handle "things" of the domain
"Things"
• are marked by the domain experts,
• may occur as classes, objects,
attributes, roles, etc. .. in the
forthcoming class model.
Our FCA view:
• "Things"  formal objects
Use cases  formal features
FCA-SE 130
Resulting line diagram
FCA-SE 140
Crossing perspectives via FCA
Functional perspective
(Use cases)
general
...
...
Data perspective
("Things")
special
particular
common
FCA-SE 150
Crossing perspectives via FCA (2)
-
Most general use cases stand top-most.
-
Special use cases stand lower in the diagram.
 Upper part shows use case hierarchy (functional perspective)
-
Most common "things" (class candidates?) stand bottom-most.
-
Particular "things" (class attributes?) stand higher in the diagram
 Lower part shows "things" hierarchy (data perspective)
Typical questions resulting from FCA analysis:
-
Why is thing X so high in the diagram? Shouldn't it lie in the scope of
use case Y?
-
Why is (sub-) use case X so low in the diagram? Shouldn't its scope
comprise thing Y?
-
Is node X is good class candidate? Are its sub-nodes good
candidates for (OO-) attribute, its super-nodes for (OO-) operations?
FCA-SE 160
Alternative approaches
Other possible associations with FCA categories
• classes
 formal objects
attributes & operations  formal features
( e.g. Godin et al. 1998, Snelting & Tip 2000)
 But: In our case we analyse a forthcoming (not an existing) class
structure! It is just our goal to find classes, attributes and operations !
• use cases
"Things"
 formal objects
 formal features
 is a reasonable alternative,
- equivalent from a mathematical point of view,
- even more "natural" from the use case point of view,
- ... but less "natural" from an overall SE point of view:
 functional perspective should be on top of data perspective
FCA-SE 170
Further analyses
Implication analysis:.
-
All use cases covering thing X cover thing Y as well.
 Is this an indicator of a possible use case refinement?
Block relation analysis:
-
Try to fill up the incidence table in such a way that blocks (rectangles
with a total incidence relation) are formed.
 Each block can be considered as a candidate for a system
component (I.e. as a collection of coherent concepts)
FCA-SE 180
FCA-SE 190
Conclusions
 FCA supports building class & object models from use case descriptions by
exposing class candidates, their attributes and operations.
 Choice between class candidates is done interactively - no automated
decisions.
 FCA analysis illuminates both functional and data perspectives of classes &
objects.
 Implication analysis supports refinement of functional decomposition.
 Block relation analysis supports modularisation and component structure.
 FCA is a good basis for the discourse between system owners, users and
developers.
 BASE tool generates concept lattices, suggestions for functional refinement,
modularisation and plausibility checks.
 Additional effort for applying FCA analysis and the BASE tool is marginal.
FCA-SE 200
Goals and aims
Formal
objects
Formal
attributes
Formal
concepts
Meaning of References
order relation
Analysis of class Classes
structure
Attributes and Abstract
operations
classes
Generalisation
Godin et al.
[GMM+ 98]
Analysis of class Program
structure
variables
Attributes and Classes
operations
Generalisation
Snelting&
Tip [S-T 00]
Modularisation
of legacy
systems
Program
procedures
Program
variables
Modules (of
maximal
cohesion)
Nesting of
modules
Lindig&
Snelting
[L-S 97]
Configuration
analysis
Code
segments
Controlling
expressions
Configurations
Specialisation of configurations
Lindig&
Snelting [Sne
96], [Lin 98]
Searching class Software
libraries
modules
Keywords
States during
searching
SpecialisaLindig [Lin
tion of
95]
search results
Project control
"Things"
relevant for
projects
Project
activities
States of
project
progress
Grade of
project
progress
Finding class
candidates
"Things"
relevant for
use cases
Use cases
Class
candidates
SpecialisaDüwel&
tion of
Hesse [Düw
functionality 00], [D-H 98]
Vogt [Vog 97]
FCA-SE 210
References
[Düw 00] S. Düwel: BASE- ein begriffsbasiertes Analyseverfahren für die Software-Entwicklung, Dissertation, Universität Marburg 2000, http://www.ub.uni-marburg.de/digibib/ediss/welcome.html
[D-H 98] S. Düwel, W. Hesse: Identifying Candidate Objects During System Analysis, Proc.
CAiSE'98/IFIP 8.1 3rd Int. Workshop on Evaluation of Modeling Methods in System Analysis
and Design (EMMSAD'98), Pisa 1998
[D-H 00] S. Düwel, W. Hesse: Bridging the gap between Use Case Analysis and Class Structure Design
by Formal Concept Analysis. In: J. Ebert, U. Frank (Hrsg.): Modelle und
Modellierungssprachen in Informatik und Wirtschaftsinformatik. Proc. "Modellierung 2000", pp.
27-40, Fölbach-Verlag, Koblenz 2000
[D-H 03] S. Düwel, W. Hesse: BASE – ein begriffsbasiertes Analyseverfahren für die SoftwareEntwicklung. in: K. Lengnink et. al (Hrsg.) Mathematik für Menschen, Festschrift f. R. Wille,
TU Darmstadt 2003
[G-W 98] B. Ganter, R. Wille: Formal Concept Analysis, Mathematical Foundation, Springer 1998
[GMM+ 98] R. Godin et al.: Design of class hierarchies based on concept (Galois) lattices. Theory and
Apllication of Object Systems (TOPAS) 4(2), pp. 117-134, 1998
[Jac 93] I. Jacobson: Object-Oriented Software Engineering - A Use Case Driven Approach; Revised
Printing, Addison- Wesley 1993
[Lin 95]
C. Lindig: Komponentensuche mit Begriffen, Proceedings Softwaretechnik '95, Braunschweig,
S. 67-75, Oktober 1995
[Lin 98]
C. Lindig: Analyse von Softwarevarianten, Informatik-Bericht 98-04, Technische Universität
Braunschweig, Januar 1998
FCA-SE 220
References (cont'd)
[L-S 97] C. Lindig, G. Snelting: Assessing Modular Structure of Legacy Code Based on Mathematical
Concept Analysis, Proceedings of the International Conference on Software Engineering
(ICSE 97), Boston, USA, pp. 349-359; 1997
[L-S 00] C. Lindig, G. Snelting: Formale Begriffsanalyse im Software Engineering. In: [S-W 00]
[M-O 92] J. Martin, J. Odell: Object-Oriented Analysis and Design. Prentice Hall 1992
[Mey 88] B. Meyer: Object oriented software construction. Prentice Hall 1988
[Sne 96] G. Snelting: Reengineering of configurations based on mathematical concept analysis, ACM
Transactions on Software Engineering and Methodology, 5(2), pp.146--189, April 1996
[S-T 00] G. Snelting, F. Tip: Understanding Class Hierarchies Using Concept Analysis, ACM
Transactions on Programming Languages and Systems, pp. 540-582, May 2000
[S-W 00] G. Stumme, R. Wille (Hrsg.):
Anwendungen. Springer 2000
Begriffliche
Wissensverarbeitung:
Methoden
und
[Vog 97] F. Vogt: Supporting Communication in Software Engineering: An Approach Based on Formal
Concept Analysis, Preprint Nr. 1926, Technische Universität Darmstadt, Fachbereich
Mathematik, 1997
[Wil 00] R. Wille: Begriffliche Wissensverarbeitung: Theorie und Praxis. Informatik-Spektrum 23.6, pp.
357-369 (2000)