The story of moose an agile reengineering environment
Download
1 / 36

The Story of Moose - PowerPoint PPT Presentation


  • 201 Views
  • Updated On :

The Story of Moose — an Agile Reengineering Environment. Oscar Nierstrasz www.iam.unibe.ch/~scg/. Is Dilbert really, really smart , or just really, really dumb ? . Premise of this presentation …. Like death and taxes, Software Evolution is inevitable

Related searches for The Story of Moose

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'The Story of Moose' - medwin


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
The story of moose an agile reengineering environment l.jpg

The Story of Moose— an Agile Reengineering Environment

Oscar Nierstrasz

www.iam.unibe.ch/~scg/


Slide2 l.jpg

Is Dilbert really, really smart, or just really, really dumb?


Premise of this presentation l.jpg

The Story of Moose — ESEC/FSE 2005

Premise of this presentation …

  • Like death and taxes, Software Evolution is inevitable

  • Unfortunately, Software Evolution is still poorly understood and supported

    • We need techniques and tools to facilitate graceful software evolution


Roadmap l.jpg

The Story of Moose — ESEC/FSE 2005

Roadmap

  • The Challenge of Software Evolution

  • The Reengineering Lifecycle

  • Reengineering with Moose

  • The Future of Software Evolution


Roadmap5 l.jpg

The Story of Moose — ESEC/FSE 2005

Roadmap

  • The Challenge of Software Evolution

    • The Myth of “Software Maintenance”

    • The Dilemma of Legacy Software

    • Coping with the Cost of Change

  • The Reengineering Lifecycle

  • Reengineering with Moose

  • The Future of Software Evolution


The myth of software maintenance l.jpg

The Story of Moose — ESEC/FSE 2005

The Myth of “Software Maintenance”

  • 60% of “maintenance” is new functionality

  • 50-75% of development effort is “maintenance”, i.e., continuous development

  • Modern methods lead to longer-lived systems, hence more maintenance

18% Adaptive

(new platforms or OS)

4% Other

There is no “software maintenance”, just continuous software evolution.

18% Corrective

(fixing reported errors)

60% Perfective

(new functionality)


Lehman s laws l.jpg

The Story of Moose — ESEC/FSE 2005

Lehman’s Laws

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.

    — Lehman and Belady, 1985


The dilemma of legacy software l.jpg

The Story of Moose — ESEC/FSE 2005

The Dilemma of Legacy Software

A legacy system is a piece of software that:

  • you have inherited, and

  • is valuable to you.

    Symptoms

  • Loss of knowledge

  • Architecture & design drift

  • Hard to make changes

You can’t afford to throw it out, but it is too expensive to change


Trends l.jpg

The Story of Moose — ESEC/FSE 2005

Trends

Hardware innovations increasingly foster new and unexpected software applications

The rate of change (new features) for new application domains is increasing

How can we deal with the spiraling need to cope with change?


The cost of change l.jpg

x 200

cost

time

cost

The Story of Moose — ESEC/FSE 2005

The cost of change

We need to reduce the cost of change over time …

— cf., XP Explained

time


Roadmap11 l.jpg

The Story of Moose — ESEC/FSE 2005

Roadmap

  • The Challenge of Software Evolution

  • The Reengineering Lifecycle

    • FAMOOS Case Studies

    • Reverse and Reengineering Patterns

    • Tool support

  • Reengineering with Moose

  • The Future of Software Evolution


Famoos case studies l.jpg

The Story of Moose — ESEC/FSE 2005

FAMOOS Case Studies

Different reengineering goals … but common themes and problems !


The reengineering life cycle l.jpg

The Story of Moose — ESEC/FSE 2005

The Reengineering Life-Cycle

Requirements

Designs

Need appropriate tools and methods

Code


A map of reengineering patterns l.jpg

Tests: Your Life Insurance

Migration Strategies

Detailed Model Capture

Detecting Duplicated Code

Initial Understanding

Redistribute Responsibilities

First Contact

Transform Conditionals to Polymorphism

Setting Direction

The Story of Moose — ESEC/FSE 2005

A Map of Reengineering Patterns

Visualize Code as Dotplots

Study the Exceptional Entities


Pattern study the exceptional entities l.jpg

The Story of Moose — ESEC/FSE 2005

Pattern: Study the Exceptional Entities

Problem

  • How can you quickly gain insight into complex software?

    Solution

  • Measure software entities and study the anomalous ones

    Steps

  • Use simple metrics

  • Visualize metrics to get an overview

  • Browse the code to get insight into the anomalies


System complexity view l.jpg

The Story of Moose — ESEC/FSE 2005

System Complexity View

System Complexity View

Nodes = Classes

Edges = Inheritance Relationships

Width = Number of Attributes

Height = Number of Methods

Color = Number of Lines of Code


Pattern visualize code as dotplots l.jpg

The Story of Moose — ESEC/FSE 2005

Pattern: Visualize Code as Dotplots

Problem

  • How can you effectively identify significant duplication in a complex software system?

    Solution

  • Visualize the code as a dotplot, where dots represent duplication.

    Steps

  • Normalize the source files

  • Compare files line-by-line

  • Visualize and interpret the dotplots


Clone detection by string matching l.jpg

The Story of Moose — ESEC/FSE 2005

Clone detection by string-matching

Solid diagonals indicate significant duplication between or within source files.


Challenges l.jpg

The Story of Moose — ESEC/FSE 2005

Challenges

Difficulties and challenges…

  • Importing models and scaling to large data sets

  • Exchanging information between tools and combining techniques

  • Querying and navigating within models

The FAMOOS tools were highly successful, but largely ad hoc


Roadmap20 l.jpg

The Story of Moose — ESEC/FSE 2005

Roadmap

  • The Challenge of Software Evolution

  • The Reengineering Lifecycle

  • Reengineering with Moose

    • The evolution of Moose

    • Leveraging tools

    • Exploiting historical data

  • The Future of Software Evolution


The components of moose l.jpg

ConAn

Van

Hapax

...

CodeCrawler

Smalltalk

Java

External

Parser

CDIF

COBOL

Navigation

C++

Metrics

Querying

XMI

Grouping

The Story of Moose — ESEC/FSE 2005

The Components of Moose

Extensible meta model

Model repository

Smalltalk (VW)


The evolution of moose l.jpg

ConAn

Van

Hapax

...

Namespace

Package

Smalltalk

Attribute

Class

Inheritance

Java

COBOL

Access

Method

Invocation

FAMIX

C++

The Story of Moose — ESEC/FSE 2005

The Evolution of Moose

1. At first, CodeCrawler directly reflected on Smalltalk classes

3. Each tool needs its own information, so we need multiple meta-models

2. Modeling multiple languages requires a neutral meta-model


Everything is an entity l.jpg

The Story of Moose — ESEC/FSE 2005

“Everything is an Entity”

Offers uniform approach to:

  • Selection

  • Navigation

  • Introspection

  • Presentation

Individual classes or groups of classes are entities


Polymetric views l.jpg

Width Metric

Height

Metric

Position

Metrics

Color

Metric

The Story of Moose — ESEC/FSE 2005

Polymetric Views

Polymetric views are useful for exploring whole systems, individual classes, or the evolution of entities


Class blueprint example l.jpg

The Story of Moose — ESEC/FSE 2005

Class Blueprint — Example

  • Root Class:

    • Template

    • Inconsistent accessor definition

    • Unused accessors

    • Direct attribute access

    • Template Method (DP)

  • Subclasses:

    • Siamese twins

    • Pure overriders


The evolution matrix principles l.jpg

First Version

Version 2 .. Version (n - 1)

Last Version

Removed Classes

Added Classes

Growth Phase

Stagnation Phase

Time (Versions)

The Story of Moose — ESEC/FSE 2005

The Evolution Matrix — Principles


The evolution matrix example l.jpg

The Story of Moose — ESEC/FSE 2005

The Evolution Matrix — Example


History as a first class entity encapsulates the evolution l.jpg

History

A

B

C

D

The Story of Moose — ESEC/FSE 2005

History as a first class entity encapsulates the evolution

Vers.1

Vers.2

Vers.3

Vers.4

Vers.5


Cc system complexity view l.jpg

The Story of Moose — ESEC/FSE 2005

CC System Complexity View



Other activities around moose l.jpg

The Story of Moose — ESEC/FSE 2005

Other activities around Moose

  • Refactoring engine

  • Static and dynamic architecture recovery

  • Trace-based feature recovery

  • Concept mining


Lessons learned l.jpg

The Story of Moose — ESEC/FSE 2005

Lessons learned

  • Make your meta-model explicit

    • Enables rapid development of new tools

    • Enables tool integration

  • Leverage tools that combine techniques

    • Enables tool “reuse”

    • Accelerates development and research

  • Use a dynamic programming environment

    • No run-time/compile-time dichotomy

    • Object inspector as default GUI & QL


The future of moose l.jpg

The Story of Moose — ESEC/FSE 2005

The Future of Moose

  • Correlating evolution with developers

  • Recovering domain concepts from source code

  • Modeling other kinds of artifacts


Roadmap34 l.jpg

The Story of Moose — ESEC/FSE 2005

Roadmap

  • The Challenge of Software Evolution

  • The Reengineering Lifecycle

  • Reengineering with Moose

  • The Future of Software Evolution

    • Concluding remarks


Trends35 l.jpg

The Story of Moose — ESEC/FSE 2005

Trends

  • Software is evolving ever more rapidly

    • Faster, smaller hardware

      • leads to new application domains

    • Globalization

      • leads to new opportunities and requirements

    • The internet and mobile computing

      • raise the bar for interoperability

  • We cannot afford to continue to develop software in the same old way!


Conclusion l.jpg

The Story of Moose — ESEC/FSE 2005

Conclusion

We need to place software evolution at the centre of our software processes and tools.

  • Methods

    • Empirical research into “best practices” to support change

      • Tie forward, reverse and re-engineering

  • Tools

    • Model, analyse and transform evolving systems

      • Co-evolution of requirements, design and code

  • Programming Languages

    • Software as living systems

      • Context-aware programs

Questions?

Comments?


ad