Formal Concept Analysis used for object-oriented software modelling

1. Formal Concept Analysis used forobject-oriented software modelling Wolfgang HesseFB Mathematik und Informatik, Univ. Marburg

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

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

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

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

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

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

8. From use cases to classes & objects

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

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

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

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

13. Resulting line diagram

14. Crossing perspectives via FCA Functional perspective (Use cases) general special ... particular ... common Data perspective ("Things")

15. 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?

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

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

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

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

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