FCA SE 10 Formal Concept Analysis used for

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

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 Order missing products <<include>> Determine inv. stock <<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 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

FCA SE 210 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. CAi. SE'98/IFIP 8. 1 3 rd Int. Workshop on Evaluation of Modeling Methods in System Analysis and Design (EMMSAD'98), Pisa 1998 [D H 00] S. 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. 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 dobson: [Jac 93] I. Printing, Addison Wesley 1993 [Lin 95] Lindig: C. Komponentensuche Begriffen, mit Proceedings Software technik Braunschweig, '95, S. 67 75, Oktober 1995 Lindig: [Lin 98] C. Braunschweig, Januar 1998

FCA SE 220 References (cont'd) gacy e Snelting: Assessing Structure of Modular [L S G. Lindig, 97] C. 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 mathemati cal [Sne ACM analysis, configurations concept Reengineering Snelting: on 96] based of. G. Transactions on Software Engineering and Methodology, 5(2), pp. 146 189, April 1996 [S T 00] G. 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] Vogt: Supporting F. Communication Software in. Engineering: Approach An Based Formal on 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)