Formal Concept Analysis
Download
1 / 22

Formal Concept Analysis used for object-oriented software modelling - PowerPoint PPT Presentation


  • 104 Views
  • Uploaded on

Formal Concept Analysis used for object-oriented software modelling. Wolfgang Hesse FB Mathematik und Informatik, Univ. Marburg. Contents 1 The role of concepts in software development 2 OO modelling: Aspects , methods and open questions

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Formal Concept Analysis used for object-oriented software modelling' - ajay


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Formal Concept Analysis used forobject-oriented software modelling

Wolfgang HesseFB Mathematik und Informatik, Univ. Marburg


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


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


Use & Operations

Use environment

Development environment

The SW development cycle (acc. to the EOS* model)

Analysis

Design

Implementation

planning,analyticactivities

synthetic, verifyingactivities

* (for Evolutionary, Object-oriented

Software development)


Use & Operations

Concepts everywhere …

Business concepts

Use & user concepts

Maintenance concepts

Analysis

Domain concepts

System concepts

Process concepts

Design

Implementation

Design & architectural concepts

Test & integration concepts

Programmingconcepts


Citations on concepts …

James Rumbaugh: "The objects in the model should be application-domain 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


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).



From use cases to classes & objects (2)

  • Open questions:

  • Are use cases (formulated in user language)appropriatefor 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])


Example of a use case diagram

Wine trade business

Receive order

Process order

<<include>>

Determine inv. stock

Clerk

Order missing products

<<include>>

<<include>>

Create deliv. instructions

Process inc. delivery

Define max. & min. stock quantity

Process delivery

results


Formal Concept Analysis (FCA)

A theory for formally describing concepts and their relationships

Formal Context (G, M, I ):G (formal) objects ("things")M(formal) attributesI G MIncidence relation

AI := { m  M | g I m for all g  A}the set of attributes common to all objects inA

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 conceptB the intent of a concept

Sub- / super concept relation(A, B) ≤ (C, D)

iffA C (DB)


3 Bridging the gap: The BASE approach

  • Use cases

  • describefunctionality

  • 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 objectsUse cases  formal features



Crossing perspectives via FCA

Functional perspective (Use cases)

general

special

...

particular

...

common

Data perspective ("Things")


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?


Alternative approaches

  • Other possible associations with FCA categories

  • classes formal objectsattributes & 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 formal objects"Things"  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


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)


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.


References

[Düw 00] S. Düwel: BASE- ein begriffsbasiertes Analyseverfahren für die Software-Entwicklung, Disser-tation, 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 Software-Entwicklung. 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 Software­technik '95, Braunschweig, S. 67-75, Oktober 1995

[Lin 98] C. Lindig: Analyse von Softwarevarianten, Informatik-Bericht 98‑04, Technische Universität Braunschweig, Januar 1998


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), Bo­ston, 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 mathemati­cal 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.): Begriffliche Wissensverarbeitung: Methoden und Anwendungen. Springer 2000

[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)


ad