the story of moose an agile reengineering environment
Download
Skip this Video
Download Presentation
The Story of Moose — an Agile Reengineering Environment

Loading in 2 Seconds...

play fullscreen
1 / 36

The Story of Moose - PowerPoint PPT Presentation


  • 202 Views
  • Uploaded 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

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

The Story of Moose— an Agile Reengineering Environment

Oscar Nierstrasz

www.iam.unibe.ch/~scg/

premise of this presentation
The Story of Moose — ESEC/FSE 2005Premise 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
The Story of Moose — ESEC/FSE 2005Roadmap
  • The Challenge of Software Evolution
  • The Reengineering Lifecycle
  • Reengineering with Moose
  • The Future of Software Evolution
roadmap5
The Story of Moose — ESEC/FSE 2005Roadmap
  • 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
The Story of Moose — ESEC/FSE 2005The 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
The Story of Moose — ESEC/FSE 2005Lehman’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
The Story of Moose — ESEC/FSE 2005The 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
The Story of Moose — ESEC/FSE 2005Trends

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

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
The Story of Moose — ESEC/FSE 2005Roadmap
  • 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
The Story of Moose — ESEC/FSE 2005FAMOOS Case Studies

Different reengineering goals … but common themes and problems !

the reengineering life cycle
The Story of Moose — ESEC/FSE 2005The Reengineering Life-Cycle

Requirements

Designs

Need appropriate tools and methods

Code

a map of reengineering patterns

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
The Story of Moose — ESEC/FSE 2005Pattern: 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
The Story of Moose — ESEC/FSE 2005System 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
The Story of Moose — ESEC/FSE 2005Pattern: 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
The Story of Moose — ESEC/FSE 2005Clone detection by string-matching

Solid diagonals indicate significant duplication between or within source files.

challenges
The Story of Moose — ESEC/FSE 2005Challenges

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
The Story of Moose — ESEC/FSE 2005Roadmap
  • 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

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

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

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
The Story of Moose — ESEC/FSE 2005Class 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

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
history as a first class entity encapsulates the evolution

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

other activities around moose
The Story of Moose — ESEC/FSE 2005Other activities around Moose
  • Refactoring engine
  • Static and dynamic architecture recovery
  • Trace-based feature recovery
  • Concept mining
lessons learned
The Story of Moose — ESEC/FSE 2005Lessons 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
The Story of Moose — ESEC/FSE 2005The Future of Moose
  • Correlating evolution with developers
  • Recovering domain concepts from source code
  • Modeling other kinds of artifacts
roadmap34
The Story of Moose — ESEC/FSE 2005Roadmap
  • The Challenge of Software Evolution
  • The Reengineering Lifecycle
  • Reengineering with Moose
  • The Future of Software Evolution
    • Concluding remarks
trends35
The Story of Moose — ESEC/FSE 2005Trends
  • 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
The Story of Moose — ESEC/FSE 2005Conclusion

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