A Novel Approach to Architectural Recovery in Evolving Object-

Oriented Systems

PhD thesis

Koen De HondtDecember 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

Pla

nnin

g

Man

uscr

ipt

Man

agem

ent

Vid

eo M

edia

Man

agem

ent

Pro

duct

&C

ontr

act

Man

agem

ent

TV1

FW

TV2

RD1TV3

Spec 1 Spec 2 Bug 1 Bug 2

SoftwareSystem

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

Items Classifications

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

PlannerCommandexecute

…<method body>…

…<more methods>…

InterfacesAcquaintance relationshipsSpecialisation clauses

Command Execution

controller:PlannerController

executeCommand:

command:PlannerCommand

execute

{executeCommand: invokes}execute

theCommand

PlannerController

executeCommand: theCommand

theCommand execute

…<more methods>…

16

Incremental Recoveryof a CollaborationContract

Recovery isincrementaland 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 A Class B

A B

Participant A Participant Bmp x

a b

Participant A Participant Bmp x

Participant A Participant Bmp x

a b

m [x]

x [p]

1

2

3

4

17

Results of Recovery

• Classification Browser acts as collaboration contract browser

• Translation to UML

Results of recovery are tangible in the SDESoftware engineer is motivated (pay off)

18

Application:Reuse Contract Recovery

Command execution

Context refinement Participant extension Participant refinement

Execution of resize command

Provid

er

clau

se(c

om

bin

ed)

Reu

ser

cla

use

executeCommand:execute

controller: PlannerController command: PlannerCommand

{ executeCommand: invokes} execute

theCommand

command: ResizeCommand

(PlannerCommand)

self

+ resizeTo: + newSize

command: ResizeCommand

(PlannerCommand)

+ {execute invokes} resizeTo: + {execute invokes} newSize

command: ResizeCommand

(PlannerCommand)

self

Command execution

executeCommand:execute

controller: PlannerController command: PlannerCommand

{ executeCommand: invokes} execute

theCommand

Command execution

executeCommand:

execute resizeTo: newSize

controller: PlannerController command: ResizeCommand

(PlannerCommand){ executeCommand: invokes} execute

theCommand

self

{execute invokes} resizeTo: {execute invokes} newSize

Initial collaboration contract

Derived collaboration contract

19

Reuse Contract Recovery

1 Set up initial collaboration contract2 Set up derived collaboration contract3 Determine the adaptation4 Decompose adaptation in basic reuser clauses and

associated contract types5 Reuse contract =

initial collaboration contract

+ basic reuser clauses and associated contract types

+ user supplied name

derived CC- initial CC= adaptation

Aut

omat

ic

Recovery is lightweight

20

Strategy: Automatic ClassificationThrough 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!

“<< 1.00 || wouter || 3-6-1998 || 9:34:36 am || extra buttons || NRK || Planning || SPEC: || 12345 >>”

Software engineer is motivated (little overhead)

21

Method Tag Processing

EnvyLibrary

ClassificationRepository

Method TagProcessor

File Spreadsheetapplication

changed methods cla

ssifi

catio

ns

method andtag information

22

Results of Method Tag Processing

In the Classification Browser In the spreadsheet application

23

Application:Recovery of Architectural Components

Multiple views on the softwareSoftware engineer is motivated (pay off)

24

Application:Management of Changes

Coping with an obscure software systemSoftware 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 HondtDecember 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 inVisual 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

sup

port

ed b

yvi

sual

com

pone

nt m

odel

s

34

Aggregation + Specialisation• Basis for frameworks and

design patterns• Example: item list editor

Item editor

List of itemsCreating 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 modelsshould focus on richer abstraction mechanisms

36