Object-Oriented Reengineering Oscar Nierstrasz Software Composition Group University of Bern.

Object-Oriented Reengineering

Oscar NierstraszSoftware Composition Group

University of Bern

Slide 2 of 25 Software Composition Group University of Berne (Switzerland)

2002 © Serge Demeyer,Stéphane Ducasse, Oscar Nierstrasz.

Roadmap

1. Legacy OO systems• What are they?• Why do they exist?• Why should we care?

2. The Reengineering lifecycle



What is a Legacy System?

legacyA sum of money, or a specified article, given to

another by will; anything handed down by an ancestor or predecessor.— OED

A legacy system is a piece of software that:• you have inherited, and• is valuable to you.



Lehman’s Laws

A classic study by Lehman and Belady (1985) identified several “laws” of system change.

Continuing change• A program that is used in a real-world environment must

change, or become progressively less useful in that environment.

Increasing complexity• As a program evolves, it becomes more complex, and

extra resources are needed to preserve and simplify its structure.



OO Legacy

Object-oriented legacy systems:• = successful OO systems whose architecture

and design no longer respond to changing requirements

Compared to traditional legacy systems:• The symptoms and the source of the problems

are the same• The technical details and solutions may differ



Problems with Legacy Systems

Typical problems are:• original developers no longer available• outdated development methods used• extensive patches and modifications have been

made• missing or outdated documentation

so, further evolution and development may be prohibitively expensive



Architectural Drift

With time, all legacy systems tend to drift from their original design.

Insufficient documentation• most legacy systems suffer from inexistent or inconsistent

documentationDuplicated functionality• “cut, paste and edit” is quick and easy, but leads to maintenance

nightmaresLack of modularity• strong coupling between modules hampers evolutionImproper layering• missing or improper layering hampers portability and

adaptability



Design Drift

Legacy systems suffer from both high-level architectural and low-level design drift.

Misuse of inheritance• aggregation, code reuse ...Missing inheritance• duplicated code ...Misplaced operations• high coupling, low cohesion ...Violation of encapsulation• public instance variables, friends, global variables ...



Roadmap

1. Legacy OO systems2. The Reengineering lifecycle• Patterns, tools and techniques



The Reengineering Lifecycle

Requirements

Designs

Code

(0) requirementanalysis

(1) modelcapture

(2) problemdetection (3) problem

resolution

(4) program transformation



Reverse and Reengineering Patterns

Reverse engineering patterns encode expertise and trade-offs in extracting design from source code, running systems and people.– Even if design documents exist, they are typically out

of sync with reality.

Reengineering patterns encode expertise and trade-offs in transforming legacy code to resolve problems that have emerged.– These problems are typically not apparent in original

design but are due to architectural drift as requirements evolve



Setting Direction

Agree on Maxims

Appoint aNavigator

Speak to theRound Table

Most Valuable First

Fix Problems,Not Symptoms

If It Ain't BrokeDon't Fix It

Keep it Simple

Set direction

Maintaindirection

Coordinatedirection

Where to start

What not to doWhat to do

How to do it

Principles & Guidelines forSoftware project

managementespecially relevant for reengineering projects



First Contact

System experts

Chat with theMaintainers

Interviewduring Demo

Talk withdevelopers

Talk withend users

Software System

Read All the Codein One Hour

Do a MockInstallation

Read it Compile it

Skim theDocumentation

Talk about it

Verify whatyou hear

feasibility assessment(one week time)

Read about it



Initial Understanding

Top down

Speculate about Design

Recover design

Analyze the Persistent

Data

Study the Exceptional

Entities

Read it Compile it

understand higher-level model

Bottom up



CodeCrawler: Visualizing Metrics

Use simple metrics and layout algorithms.

(x,y) width

height colour

Visualize up to 5 metrics per node



Detailed Model Capture

Tie Code and Questions

Refactor to UnderstandKeep track of

your understanding

Expose design

Expose the design& make sure it remains

exposed

Step through the Execution

Look for the Contracts

Learn from the Past

• Use Your Tools• Look for Key Methods

• Look for Constructor Calls• Look for Template/Hook

Methods• Look for Super Calls

Expose collaborations

Expose contracts

Expose evolution

Write Teststo Understand



Tests: Your Life Insurance

Write Tests to Enable Evolution

Grow Your TestBase Incrementally

Managing testsUse a TestingFramework

Test the Interface,Not the Implementation

Record BusinessRules as Tests

Designingtests

Write Teststo Understand

• Test Fuzzy features• Test Old Bugs• Retest Persistent Problems

Regression Testafter Every Change

Migration Strategies



Migration

Migrate SystemsIncrementally

ConserveFamiliarity

HowUse Profiler

before Optimizing

Build ConfidenceInvolve the UsersHow Why

Why

Prototype theTarget Solution

Always Have aRunning Version

Regression Testafter Every Change

Present theRight Interface

Distinguish Publicfrom Published Interfaces

DeprecateObsolete Interfaces

Make a Bridgeto the New Town

How

Tests, yourLife-Insurance

Where to



Detecting Duplicated Code

Compare Code Mechanically

Visualize Code as Dotplots

Redistribute Responsibilitie

sTransform

Conditionals to Polymorphism

Detect

Understand



Duploc: Detecting Duplicated Code

Compare, visualize and navigate multiple source files



Dotplot Visualization

Exact Copies Copies with Inserts/Deletes Repetitive

a b c d e f a b c d e f a b c d e fa b x y e f b c d e a b x y dc ea x b c x d e x f xg ha

Variations Code Elements(Helfman, 1995)

Sample Dot Configurations:



Redistribute Responsibilities

Eliminate Navigation Code

Data containers

Monster client ofdata containers

Split Up God Class

Move Behaviour Close to Data

Chains of datacontainers



Transform Conditionals to Polymorphism

TransformSelf Type Checks

Test providertype

Test self type Test externalattribute

TransformClient Type Checks

Transform Conditionalsinto Registration

Testnull values Introduce

Null Object

Factor Out Strategy

Factor Out State

Test object state



Conclusion

• Yes, there are object-oriented legacy systems too!– … actually, that's a sign of health

• Reverse engineering and reengineering are essential activities in the lifecycle of any successful software system.– … consequently, do not consider it second class work

• There is a large set of lightweight tools and techniques to help you with reengineering.– … check our book, but remember the list is growing

• Nevertheless, people must do the job!– … so pick them carefully and reward them appropriately!



The end

For more information, please visit:www.iam.unibe.ch/~scg/

Buy the book!

http://www.iam.unibe.ch/~scg/





Roadmap

1. Legacy OO systems2. The Reengineering lifecycle3. Odds and ends



FAMOOS Case Studies

Goal: Reengineering object-oriented legacy systems towards component frameworks.

Emphasis: Lightweight tools and techniques applied to industrial case studies.

Domain LOC Reengineering Goal

pipeline planning 55,000 extract design

user interface 60,000 increase flexibility

embedded switching 180,000 improve modularity

mail sorting 350,000 portability and scalability

network management 2,000,000 unbundle application

space mission 2,500,000 identify components



Moose

A language-independent reengineering platform based on FAMIX

• repository– querying– metrics computation– navigational operators

• built-in language parsers (Smalltalk, ...)• CDIF and XMI file exchange

– external parsers and tools



FAMIX

A simple, UML-like meta-model designed for reengineering operations and information exchange– language-independent meta-model

• models source code, not designs• explicit language mappings for C++, Java, Ada• (Smalltalk in the works ...)

– models method invocations and variables accesses for dependency analysis

• reverse engineering• refactoring

– interchange for reengineering tools• CDIF and XMI



FAMIX Core Model

The full model also includes Functions, Formal Parameters ...Additional information is stored for every entity (the name of

a Class, the visibility of a Method, ...)



Duploc: Visualizing Software Evolution



Interactive Visualization

Anomalous software entities are usually the “interesting” ones.

Object-Oriented Reengineering Oscar Nierstrasz Software Composition Group University of Bern.

Documents

adaptability slide

expensive slide

serge demeyer

legacy oo systems

stphane ducasse

design drift legacy

traditional legacy systems

reengineering lifecycle