A Novel Approach to Architectural Recovery in Evolving Object- Oriented Systems PhD thesis Koen De Hondt December 11, 1998

2 Overview Problem, thesis, objectives Case study Software classification model Software classification strategies and applications –Classification with advanced navigation tools –Automatic classification through method tagging Conclusion, contributions, and future work

3 Observations Models are crucial for evolution Evolving software is hard Reverse engineering is often the only way to get a mental model of the software Reverse engineering is a recurrent development activity Models obtained through reverse engineering are not recorded

4 Thesis The software development environment should provide support for recording models that result from reverse engineering efforts, so that models become online software documentation that can be exploited in subsequent software development activities.

5 Objectives What? –Recovery of large architectural building blocks: modules, layers, framework customisations –Recovery of collaboration contracts –Recovery of reuse contracts How? –Incremental software classification

6 Case Study Large software system for broadcast management –More than 2000 classes –Object-oriented framework –Customizations for several customers –Continuous evolution; evolutionary software development –Smalltalk, Envy/Developer Role of the case study –Industry-as-laboratory approach –Requirements provider –Platform for experiments, evaluation and (early) feedback

7 Requirements for the Recovery Process Take multiple views on the software into account The recovery process should be incremental Motivate the software engineer (little overhead, effort must pay off) Keep the model simple Keep the recovery process lightweight Integrate the model and the recovery process in the SDE Integrate existing software entities in the model Make the results of recovery tangible in the SDE (memory prosthesis) Cope with an obscure software system

8 User Interface Layer Domain Model Layer Persistency Layer Multiple Views on Software Planning Manuscript Management Video Media Management Product & Contract Management TV1 FW TV2 RD1TV3 Spec 1Spec 2Bug 1Bug 2 Software System

9 Software Classification Software classification model –Metamodel to describe abstractions/models of the software Software classification technique –Way to carry out classification –Based on software classification strategies

10 Software Classification Model A classification is an entity in which items can be classified Items can reside in multiple classifications Classifications have a structure and a classification policy Classifications and items are stored in the classification repository Simple model

11 Software Classification Model Items in the SDE –Classes –Methods Participants (views on classes) Classifications as items Simple classifications Virtual classifications Classifications in the SDE –Smalltalk categories –Envy applications Collaboration contracts Reuse contracts ItemsClassifications Existing software entities are integrated in the model

12 Classification Browser Model is integrated in the SDE Classification Repository Smalltalk Repository Smalltalk System

13 Software Classification Strategies Manual classification Virtual classification Classification with advanced navigation tools Automatic classification through method tagging

14 Strategy: Classification with Advanced Navigation Tools In general –Set up classifications of items based on relationships between the items –Advanced navigation tools needed to find and to browse the relationships Classification Browser supports browsing of the interaction structure –In-place browsing of senders and implementers –Browsing of source code level acquaintances –History of browsing activities

15 Application: Collaboration Contract Recovery What must be recovered? PlannerCommand execute … Interfaces Acquaintance relationships Specialisation clauses Command Execution controller: PlannerController executeCommand: command: PlannerCommand execute {executeCommand: invokes} execute theCommand PlannerController executeCommand: theCommand theCommand execute … …

16 Incremental Recovery of a Collaboration Contract Recovery is incremental and lightweight Browsing restricted to a classification Browsing senders and implementers Browsing acquaintances Classification of classes as participants, methods, acquaintances, acquaintance classes Conversion of classification to collaboration contract Class AClass B AB Participant AParticipant B mpmp x a b Participant AParticipant B mpmp x Participant AParticipant B mpmp x a b m [x] x [p]

17 Results of Recovery Classification Browser acts as collaboration contract browser Translation to UML Results of recovery are tangible in the SDE Software engineer is motivated (pay off)

18 Application: Reuse Contract Recovery Initial collaboration contract Derived collaboration contract

19 Reuse Contract Recovery 1Set up initial collaboration contract 2Set up derived collaboration contract 3Determine the adaptation 4Decompose adaptation in basic reuser clauses and associated contract types 5Reuse contract = initial collaboration contract + basic reuser clauses and associated contract types + user supplied name derived CC -initial CC =adaptation Automatic Recovery is lightweight

20 Strategy: Automatic Classification Through Method Tagging Automatic incremental classification scheme based on information provided during forward engineering Method tagging Tagging info provided once per development task Requires changes to the SDE and the development process! “ >” Software engineer is motivated (little overhead)

21 Method Tag Processing Envy Library Classification Repository Method Tag Processor File Spreadsheet application changed methods classifications method and tag information

22 Results of Method Tag Processing In the Classification BrowserIn the spreadsheet application

23 Application: Recovery of Architectural Components Multiple views on the software Software engineer is motivated (pay off)

24 Application: Management of Changes Coping with an obscure software system Software engineer is motivated (pay off)

25 Conclusion Software classification is a viable approach to recovery Architectural recovery based on software classification –Record what is in the software engineers’ heads –Make it explicit as entities to be explored in the SDE Method tagging –Insight into the changes made; statistics about evolution –Requires changes to the SDE and the development process Software classification is an asset to software engineers (little overhead, effort pays off)

26 Contributions Presentation of a generic model and strategies for incremental recovery of the architecture of evolving object-oriented systems Classification Browser and method tagging tool Architectural recovery and software evolution –Expressing multiple views on software –Recovery of collaboration contracts, reuse contracts, and architectural components –Management of changes Important step towards a SDE based on reuse contracts

27 Future Work Larger components as collaboration contract participants Generic collaboration contracts Expressing architectural constraints Keeping classifications in sync Other software classification strategies –Exploitation of virtual classifications –Automatic classification and automatic recovery Classifications in other development tools Classifications in non-Smalltalk SDE SDE that actively supports reuse and evolution

A Novel Approach to Architectural Recovery in Evolving Object- Oriented Systems PhD thesis Koen De Hondt December 11, 1998

29 Apposition/Bijstelling The application domain of visual component systems is limited because component models support but a fraction of the abstraction mechanisms provided in other areas of software engineering. Research on visual component models should focus on richer abstraction mechanisms.

30 Visual Application Building

31 Visual Application Building Good –Rapid application development –Productive for particular application domains –Visual linking of components –Glue language Bad –Promotion of copy-and-paste reuse –Only for small or simply structured applications –Only for prototyping –Fails as complexity and scale increase

32 Abstraction Mechanisms in Visual Component Systems Worst case: no abstraction supported –Compositions are applications –Compositions cannot be reused Best case: weak form of aggregation –Compositions can be encapsulated into new components –New properties tools must be provided programmatically

33 Abstraction Mechanisms in Software Engineering Aggregation (  decomposition) –Emerging properties –Hereditary properties –Concealed properties Specialisation (  generalisation) –Inherited properties –Modified properties –Additional properties Source: Conceptual Modeling and Programming Languages (Kristensen and Østerbye) Not supported by visual component models

34 Aggregation + Specialisation Basis for frameworks and design patterns Example: item list editor Item editor List of items Creating abstract components with placeholders is not supported

35 Conclusion Making abstractions is shifted to the glue language But abstractions can only be expressed if they are supported by the component model Research on visual component models should focus on richer abstraction mechanisms

36