slide1
Download
Skip this Video
Download Presentation
Formal Concept Analysis used for object-oriented software modelling

Loading in 2 Seconds...

play fullscreen
1 / 22

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


  • 105 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
slide1

Formal Concept Analysis used forobject-oriented software modelling

Wolfgang HesseFB Mathematik und Informatik, Univ. Marburg

slide2

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

slide3

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
slide4

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)

slide5

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

slide6

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

slide7

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

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])
slide10

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

slide11

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)

slide12

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
slide14

Crossing perspectives via FCA

Functional perspective (Use cases)

general

special

...

particular

...

common

Data perspective ("Things")

slide15

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?
slide16

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
slide17

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

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

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

slide22

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