Lessons in Software Evolution Learned by Listening to Smalltalk

Post on 20-May-2015

1.626 views 3 download

Tags:

description

Invited talk at SOFSEM 2010. Full paper (PDF) is available for download. http://bit.ly/8awi30

Transcript of Lessons in Software Evolution Learned by Listening to Smalltalk

Lessons in Software EvolutionLearned by Listening to Smalltalk

Oscar Nierstraszscg.unibe.ch

Research Team

Adrian LienhardAdrian Kuhn

Fabrizio PerinLukas RenggliJorge Ressia

David RoethlisbergerNiko Schwarz

Toon VerwaestErwann Wernli

The trouble with changeSmalltalk in a NutshellTaming Software ChangeEpilogue — Bringing Models Closer to Code

The trouble with changeSmalltalk in a NutshellTaming Software ChangeEpilogue — Bringing Models Closer to Code

Roadmap

The trouble with changeSmalltalk in a NutshellTaming Software ChangeEpilogue — Bringing Models Closer to Code

The trouble with changeSmalltalk in a NutshellTaming Software ChangeEpilogue — Bringing Models Closer to Code

Roadmap

The trouble with changeThe trouble with change

How we enable change

Package what is stable

Define an interface for configuration

A brief history of software packaging

The Trouble with Software Change

Understanding the system

Understanding the system

Bridging the gapBridging the gap

Specifying changeSpecifying change

Managing changeManaging change

Understanding change

Understanding change

The trouble with changeSmalltalk in a NutshellTaming Software ChangeEpilogue — Bringing Models Closer to Code

The trouble with changeSmalltalk in a NutshellTaming Software ChangeEpilogue — Bringing Models Closer to Code

Roadmap

Smalltalk in a NutshellSmalltalk in a Nutshell

To thine own self be true

Less is MoreLess is More The object model “is as simple as possible, but no simpler”

The object model “is as simple as possible, but no simpler”

Reify EverythingReify Everything

You can change a Running SystemYou can change a Running System

“Everything is an object” is applied consistently

“Everything is an object” is applied consistently

Smalltalk models itself, so changing the model changes the system

Smalltalk models itself, so changing the model changes the system

The origins of Smalltalk

Alan Kay’s Dynabook project (1968)

Alan Kay’s Dynabook project (1968)

Alto — Xerox PARC (1973)

Alto — Xerox PARC (1973)

Smalltalk architecture

ImageImage

ChangesChanges

Virtual machineVirtual machine

SourcesSources

Everything happens by sending messages

2 raisedTo: 1 + 3 factorial2 raisedTo: 1 + 3 factorial 128128

First unary, then binary, then keyword:First unary, then binary, then keyword:

factorial+raisedTo:

<= aPoint "Answer whether the receiver is neitherbelow nor to the right of aPoint."

^ x <= aPoint x and: [y <= aPoint y]

<= aPoint "Answer whether the receiver is neitherbelow nor to the right of aPoint."

^ x <= aPoint x and: [y <= aPoint y]

A typical method

(2@3) <= (5@6)(2@3) <= (5@6) truetrue

Keyword messageKeyword message

Instance variableInstance variable

BlockBlock

Binary messageBinary message

Unary messageUnary message

Method nameMethod name ArgumentArgument CommentComment

ReturnReturn

Everything is an object

Everything is an object

You can change a running system

AKA: “The Debugger is your Friend” AKA: “The Debugger is your Friend”

Pharo — an multi-platform, open-source Smalltalk

Pharo by Example. Andrew Black, et al. Square Bracket Associates, 2009.

Pharo by Example. Andrew Black, et al. Square Bracket Associates, 2009.

The trouble with changeSmalltalk in a NutshellTaming Software ChangeEpilogue — Bringing Models Closer to Code

The trouble with changeSmalltalk in a NutshellTaming Software ChangeEpilogue — Bringing Models Closer to Code

Roadmap

Taming Software ChangeTaming Software Change

Moose: a platform for reverse engineering

Smalltalk

NavigationMetrics

QueryingGrouping

Smalltalk

Java

C++

COBOL

CDIF

XMI

ExternalParser

CodeCrawler

ConAn Van ...Hapax

Extensible meta model

Model repository

Explicit metamodels enable change

The Story of Moose: an Agile Reengineering Environment. Oscar Nierstrasz, Stéphane Ducasse, and Tudor Gîrba. ESEC/FSE 2005

The Story of Moose: an Agile Reengineering Environment. Oscar Nierstrasz, Stéphane Ducasse, and Tudor Gîrba. ESEC/FSE 2005

Moose visualizations

Programming visualizations with CodeCrawler

Scripting visualizations with Mondrian

Mondrian: An Agile Visualization Framework. Michael Meyer, Tudor Gîrba, and Mircea Lungu. SoftVis 2006

Mondrian: An Agile Visualization Framework. Michael Meyer, Tudor Gîrba, and Mircea Lungu. SoftVis 2006

Moose — a platform for collaborative research

Feature inheritance ≠ specialization

First-class traits enable fine-grained reuse

Class = superclass + state + traits + glue

Traits provide and require methods

Traits provide and require methods

The composing class retains control

The composing class retains control

Traits: A Mechanism for fine-grained Reuse. Stéphane Ducasse, Oscar Nierstrasz, Nathanael Schärli, Roel Wuyts and Andrew Black. ACM TOPLAS, March 2006

Traits: A Mechanism for fine-grained Reuse. Stéphane Ducasse, Oscar Nierstrasz, Nathanael Schärli, Roel Wuyts and Andrew Black. ACM TOPLAS, March 2006

Traits and Classes share common behaviour

First-class aliases enable object flow analysis

Practical Object-Oriented Back-in-Time Debugging. Adrian Lienhard, Tudor Gîrba, and Oscar Nierstrasz. ECOOP 2008.

Practical Object-Oriented Back-in-Time Debugging. Adrian Lienhard, Tudor Gîrba, and Oscar Nierstrasz. ECOOP 2008.

A back-in-time VM with object flow analysis

GC remembers only what is needed

How to manage change in a running system?

Encapsulating and Exploiting Change with Changeboxes. Marcus Denker, et al. ICDL 2007.

Encapsulating and Exploiting Change with Changeboxes. Marcus Denker, et al. ICDL 2007.

First-class changes enable scoped evolution

The trouble with changeSmalltalk in a NutshellTaming Software ChangeEpilogue — Bringing Models Closer to Code

The trouble with changeSmalltalk in a NutshellTaming Software ChangeEpilogue — Bringing Models Closer to Code

Roadmap

Epilogue — Bringing Models Closer to CodeEpilogue — Bringing Models Closer to Code

Systems that support change need to be model-centric and context-aware

Model-centric systems are self-describing and can be adapted

dynamically

Model-centric systems are self-describing and can be adapted

dynamically

Context-aware systems control the scope of change to static or

dynamic contexts

Context-aware systems control the scope of change to static or

dynamic contexts