bern.jb

07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 1

Should we Resurrect Software Engineering?

Jean Bézivin [email protected]

CHOOSE Forum 2012, Bern

mailto:[email protected]


Requiem for Software Engineering


You escaped these titles

Software Engineering is Dead; Long Live Software Engineering

The basis of Software Engineering 2.0 From Software Engineering to Engineering

Software Towards a Unified Theory of Engineering Is Generic Engineering Feasible? How to Bridge Problem Spaces and Solution

Spaces? Some remarks about eEngineering


Agenda

1. Introduction 2. Software Engineering is Dead 3. Model Driven Engineering Missed the Boat 4. Problem and Solution Spaces 5. Domain Engineering 6. Support Engineering 7. Conclusion


SOFTWARE ENGINEERING IS DEAD

Sorry for the bad news


… or at least critically ill

Last time we heard good news was in the 80’s with the invention of the Smalltalk Browser

Every year since then, we have been eagerly waiting for better health news at OOPSLA, ECOOP, ICSE, etc.

But unfortunately we had only patterns, aspects, Java, and false hopes that did not last very long

Adding superficial deltas to the J-language is boring

And now many people have given up, to concentrate only on the problem of organization of agile teams

The NATO Conferences of 1968 and 1969 were motivated by the belief that software development should be "based on the types of theoretical foundations and practical disciplines that are traditional in the established branches of engineering.“ Surprisingly the conferences did not discuss what these foundations and disciplines were, or how they could be emulated. There has been little discussion of this topic in the intervening forty years and more. Some important lessons have been neglected.

From Michael Jackson’s Web site


Hype after Hype

Are we condemned to jump from hype to hype like a fashion industry?(1)

What is the hidden meaning in the long term evolution of our discipline?

(Raw Ngram buzzword observations)

Google Ngram Viewer

(1) Ivar Jacobson


Software Engineering as a Succession of Hypes

Many developers’ career paths follow a continuous zigzag from hype to hype, from objects to models, from models to services, ...

We need to focus more on long term continuity and progresses than on small ruptures and failures.

Progress in SE? What is the deep meaning, if any, behind this succession of hypes?


OOPSLA: An Object Odyssey

Design Patterns: Kent Beck and Ward Cunningham

[OOPSLA] became the forum for some of the most important software developments over the last couple of decades. OOPSLA was the incubator for CRC cards, CLOS, Design Patterns, Self, Agile Methodologies, Service-Oriented Architectures, Wikis, Unified Modeling Language (UML), Test Driven Design (TDD), Refactoring, Java, Dynamic Compilation, and Aspect-Oriented Programming, to name just some of them.

Probably the Palo Alto Research Center produced more results in ten years between 1970 and 1980 that the OOPSLA community in 25 years between 1986 and 2012.


Not a competition

We are suffering from the « My solution is better than yours » syndrome. Where is the big picture in this hype-after-hype sequence? Will some

technology finally prevail? Let us focus more on technology cooperation than on technology

competition.


What has changed in the past 50 years ?

Expressions like “CAD” or “Computer Assisted” or “Computer Aided” have lost all their discriminant meaning in engineering

Most engineering fields are now using computers and software

Time to adapt our vision


MDE MISSED THE BOAT Model Driven Engineering


Models Have Failed

“Models” have failed, at least temporarily. Deployment of MDE seems today to have reached a standstill. Immense hopes greeted the MDA™ initial proposal as a possible

way to regenerate the entire software engineering practices Recognition today that its impact is rather limited and its perspectives

quite confined. Observation that the process is not at the same level that in case of

technology take-off like OT in the 80’s Unfortunately this last silver bullet fired blank What went wrong?

No sustainability lack of model portability in time and space

No killer app Decreasing confidence in UML Many other factors


Separating the platform independent and dependent parts of a system (PIM/PSM)

We don't want anymore to pay such a high price for simply moving our information system to a new middleware platform (COM, CORBA, Java, HTML, XML, DotNet, etc.) when our business system stays stable. We are prepared to pay a last price for building the abstract models of our business and services that will guarantee us against technological obsolescence. From there, any platform provider will also have to provide the mapping solutions from standard business models before we buy.

November 2000

07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 15 - 15 -

Write Once, Run Anywhere Model Once, Generate Anywhere

CORBA

Java/EJB C#/DotNet

Web/XML/SOAP

PIM

etc.

From Platform Independent Models to Platform Specific Models PIM to PSM

Multi-target code generation

+ SVG, GML, Delphi, ASP, MySQL, PHP, etc.

Service architecture, Cloud computing, …

SMIL/Flash


Sustainable Software?

Sustainability is the new hype, but is this hype sustainable?

The first promise/commitment of MDA™ was on sustainability: “Developers gain the ultimate in

flexibility, the ability to regenerate code from a stable, platform independent model (PIM) as the underlying infrastructure shifts over time”.

This was based on the “hidden condition” that the PIM was written in UML, a language supposed itself to be stable over long periods of time.

PERMANENT LINK TO THIS COMIC: HTTP://XKCD.COM/1007/ IMAGE URL (FOR HOTLINKING/EMBEDDING):

HTTP://IMGS.XKCD.COM/COMICS/SUSTAINABLE.PNG


Nice Gems … but is this core MDE?


Some MDA success stories but no killer app. yet

http://www.omg.org/mda/products_success.htm

http://www.omg.org/mda/products_success.htm


What is a Killer App?

Tom Love experiment at Schlumberger (see also the Analyst At Xerox) 220 lines of Smalltalk vs. 10,000 lines of Fortran

A killer app. should provide measurable and reproducible evidence that the new proposal offers an order of magnitude improvement over previous solutions.


UML and MDE: friend or foe, devil or angel?

UML was the conclusion of the OOADTF and the beginning of MDA Everything started with UML and this is

probably the main problem of MDE

UML is a loosely defined language UML is a language with one syntax and an

infinity of semantics (Very popular BYOS)

UML is not a badly designed language Because it was never designed at all It is the result of industrial consensus,

obtained through a precise process (committee invention)

Bad modularity principles (profiles) UML as a visual syntax for C++

UML as a better « programming » language?


UML as the modeling language archetype?

UML considered as the archetype of modeling languages, often illustrates properties that are at the extreme opposite of the main MDE basic principles.

UML as the typical visual language. Many still wrongly associate MDE with visual modeling. MDE has later shown that textual modeling (like in Xtext) is often better than visual

modeling. UML as a general purpose language (GPL).

MDE has demonstrated the interest of precise and focused Domain Specific Languages (DSLs).

UML as an OO modeling language MDE has demonstrated the benefits of multiparadigm modeling, considering not

only objects, but rules, events, functions, tables, processes, etc. UML has wrongly conveyed the idea that modeling was only OO modeling

UML is known for its complexity, by the size of its metamodel and its rapid evolution MDE promotes the idea of simple languages that could be combined, with controlled

execution


Confusing Executability and Precision

One important ambiguity has been to let the idea propagate that all MDE-models, (including UML), could be made executable.

MDE promotes the idea that some models may be executable but not all A perverse corollary of this is that non executable models are not

precise Many models may be executable and however very precise

Precision is not always obtained through computer executability


XMI Failure

From SMIF to XMI, a good start. XMI as the final interoperability solution, the first mistake The proportion of native data expressed in XMI is

completely marginal and will not increase. Through its various versions, XMI added mess to mess. XMI with UML is part of MDE legacy. XMI will eventually disappear, creating an additional

problem of maintenance for UML models.


Lack of Theory

a model M a system S

The «real» World The World of «Models»

Squares and Circles


Representation and Conformance

Model System representationOf

Metamodel

conformsTo

The two orthogonal dimensions of MDE

wrt


Taking the representation relation seriously

"What about the [relationship between model and real-world]? The answer, and one of the main points I hope you will take away from this discussion, is that, at this point in intellectual history, we have no theory of this [...] relationship". [Brian Cantwell Smith]

Where are models coming from?


Action on a model is not action on the system (real world)

a model M a system S repOf

A situation or a phenomenon of the real or imagined world.


But we Learned a Lot with MDE

1. Representation principle Any model M represents a system S

2. Multiple view principle A system S may be represented by

several models 3. Conformance principle

Any model M conforms to the language of its metamodel MM

4. 3-level principle Any metamodel MM conforms to a

common metametamodel MMM 5. Transformation principle

The most important operation applicable to models is a transformation

6. HOT principle A transformation is a model

7. Weaving principle Abstract correspondences between

models are represented as models 8. Megamodel principle

Model elements may be considered as models

9. Unification principle All models specialize a common

abstract model 10. Technical Space Framework

Any model has a given representation defined by its technical space


What is a modeling language?

The expression “modeling language” is recent

Examples: • Requirements • Abstract Specifications • Formal Methods • Semi-Formal Notations • Early aspects (?) • etc.

The expression “modeling language” is recent

Tentative definition: A modeling language is a language contributing to software production, maintenance or operation that is not directly executable.

Examples Flowcharts (~1950) Petri Nets (~1960-1970) PSL/PSA (~1967) State Diagrams (~1967) SADT (~1969) DFD (~1975) Entity-Association

(Chen, ~1976) JSD (~1982) AD/Cycle (~1982) UML (~1996) MDA (~2000)


What are the relations between Programming & Modeling Languages?


The two parallel tracks

Programming Languages

Assembler Fortran COBOL

Algol60 PL/1 ADA Java

C#

Smalltalk

C++ Ruby Scala

Python F# Go

Dart

Modeling Languages Sara

SREM SADT Petri JSD

DFD B

OMT

Z

VDM UML

SART

ExecutableUML?

Flowcharts

Lisp

Prolog

SysML

Pascal

PSL/PSA

SBVR

Javascript

No global consolidated history of Modeling Languages


Evolving scope Not only for code generation

[If MDE is the Solution, then what was the Problem?]

MDE

MDD

MDE

MDD

MDD = Model Driven (Software) Development MDE = Model Driven Engineering

http://pro.corbis.com/search/searchFrame.asp

http://upload.wikimedia.org/wikipedia/commons/a/ac/Iceberg.jpg


MDE is not only for code generation

Restricted focus MDE concentrated too much

on models of code and not enough on models of data

MDE concentrated too much on models of solutions and not enough on models of problems

MDE concentrated too much on Information Systems models and not enough on Business models

MDE concentrated too much on modeling in the small and not enough on modeling in the large

etc.

Software Engineering

System Engineering

Data Engineering

Business Engineering

appliesTo

Model Driven

Engineering

Initially MDA was for just software engineering, and the scope was progressively extended

UML/SPEM CWM SysML BPMN


PROBLEM AND SOLUTION SPACES The engineer view of « how to solve it? »


Technical Spaces

aTechnicalSpace

aSystem aModel repOf

System: A group of interacting, interrelated, or interdependent elements forming a complex whole.

Model: An abstract representation of a system created for a specific purpose.

Technical Space: A representation system for models and a set of technical solutions to handle them. A framework usually based on some algebraic structures (relational tuples, trees, graphs, hypergraphs, etc.)

MetaMetaModel


Structuring the solution space

Problem How to Solve it?

Java XML MDA™ Ontologies etc.

Problem Space

Solution Space

Grammars

Programs

DBMS

XML Schema

XML Documents

Metamodel

Model

All models are not MOF or ECORE Models.


Three representations for the same program

JavaML schema

JavaML Document

Java Metamodel

Java Model

Java Grammar

Java Program

Program TS MDA TS XML TS


Projections between EBNF, MDE and XML

MDE TS EBNF TS

MOF

Java

Test.xmi

EBNF.g

Java.g

Test.java

XSD.xsd

JavaML.xsd

Test.xml

M3

M2

M1

XML TS


Ubiquitous Software: From Problems to Solutions

Solution Spaces

Problem Spaces

Mappings

Domain Engineering

Support Engineering


Focus on Engineering

Scientists study the world as it is; engineers create the world that has never been.

Theodore von Kármán


The two spaces

Domain Engineering

Support Engineering

Problems lie here

Tools to solve problems may be found here


Problems and Solutions

Support Engineering (vertical?) Process engineering Product (line) engineering Software language engineering Model engineering Service engineering Data engineering Program engineering Event engineering Constraint engineering System engineering Requirement engineering Ontology engineering Legal engineering

Domain Engineering (horizontal?) Civil engineering Building engineering Electrical engineering Mechanical engineering Business engineering Biological engineering Automotive engineering Health engineering


DOMAIN ENGINEERING Problem Spaces


Domain Engineering

Similar processes across all engineering fields 1. Build abstract models

Using some given ontologies For example mechanics, electronics, etc.

2. Verify/Validate Abstract Models

Using some validation technique

3. Put into production Create Products from Models Automatic, Semi-automatic or Manual

4. Put into operation

Deployment Augment or change the real world Adding a new bridge, a new phone device, a

new building, a new operational program, etc.


Electrical Engineering

Building abstract models

Validation Verification

Putting in Production

Augmenting, Changing the

world


Construction Engineering

Building abstract models

Validation Verification

Putting in Production

Augmenting, Changing the

world


Old and new engineering fields


Many Communities, Many Journals

http://www.govengr.com/

Journal of Neural Engineering to help scientists, clinicians and engineers to understand, replace, repair and enhance the nervous system.

Neural engineering (also known as Neuroengineering) is a discipline within biomedical engineering that uses engineering techniques to understand, repair, replace, enhance, or otherwise exploit the properties of neural systems

Healthcare Engineering Biomedical engineering Computer-aided medical engineering Medical/disease modeling Rehabilitation engineering Healthcare energy systems engineering Healthcare support service engineering Emergency response engineering Engineering issues in public health and epidemiology Aging Engineering and aging (elderly patient service) Healthcare engineering education …

Concurrent engineering is a work methodology based on the parallelization of tasks (i.e. performing tasks concurrently). It refers to an approach used in product development in which functions of design engineering, manufacturing engineering and other functions are integrated to reduce the elapsed time required to bring a new product to the market.


And many more


Synergies Between Engineering Fields

Program Engineering Building Engineering

“The Origins of Pattern Theory, the Future of the Theory, And The

Generation of a Living World” Christopher Alexander

Once in a great while, a great idea makes it across the boundary of one discipline to take root in another. The adoption of Christopher Alexander’s patterns by the software community is one such event. .

Jim Coplien


Domain Engineering

Domain Engineering

Product Engineering

Process Engineering

Problem spaces

Solution spaces (Support Engineering)


Many features common to all domain engineering fields

Based on support engineering Product & Process focus Including HR and team management

Chain Building Abstract Models Verification/Validation Putting in Production Putting in operation

Need for a strong model repository Scaling up to millions of parts Cooperative concurrent access Point of view mechanisms Strong zooming mechanisms


SUPPORT ENGINEERING Solution Spaces


Variety Complexity of the Support Engineering Landscape

Language Engineering

Program Engineering

Ontology Engineering

Model Engineering

Web Engineering

Service Engineering

Transformation Engineering

Rule Engineering

Complex Event Engineering

Data Engineering

Process Engineering

Product Engineering

HR Engineering

Team Engineering


Other Engineering


Specialized engineering fields


Software Language

Engineering

Model Engineering

Ontology Engineering

Grammar Engineering


Composite engineering fields


Model Engineering

The legend

Same visual notation, different context, different meaning (Thick red dotted lines for bicycle lanes)

is the metamodel

µ

Model

c2

Metamodel

Model element

Metamodel element


Process engineering

Process engineering encompasses a vast range of industries, such as chemical, petrochemical, mineral processing, advanced material, food, pharmaceutical, biotechnological, and software industries.

See also Concurrent Engineering

Process Engineering

Software Process Engineering

SPEM


PSL (Process Specification Language) Process Specification Language NIST

+nameProcess

-name-duration

Activity

1

0..*

+following0..*

+preceding

0..*


Early SPEM (UPM)


Team and Product management

Team Management Engineering

Software Team Management Engineering

Agile Methods

Product Lifecyle Management (PLM)

Product Line Engineering

Software Product Line Engineering


Data Engineering


Program Engineering

Short name: “Programming” Long tradition of excellence Noble and visible part of SE Very difficult Many iterations and branches Structured Programming OO Programming Functional Programming Etc.


What is a program?

The World (domain)

The Machine (platform)

A Program The Application Requirements

(use cases)

class BankCustomer{ } class Printer{ } class Application{ }

A Programming

Language

c2

class Application{ public static void main (String[] args) { System.out.writeln("Hello, world") } }


Making implicit relations explicit

Language engineering is related to the definition and handling of languages

Program engineering deals with the use of executable software languages to produce operational programs that will participate in human activities (includes deployment).


Program Engineering

?

?


Models for producing programs

Domain (World)

Problem (Application)

Platform (Machine)

Program

Models

Code generation with models

Today Knowledge in the head of programmer

Tomorrow From implicit to explicit Transformation based Other aspects


But also models for understanding programs

View1

View2

View3

Program

Models

Code understanding with models

Today

Tomorrow


Sound terminologies are always useful

Good definitions allow avoiding sterile, futile, and non productive discussions

«Mal nommer les choses, c'est ajouter au malheur du monde» Albert Camus [To misname things is to add misery to the world]

Programming is Modeling

Modeling is Programming

Model Engineering

Program Engineering

?

?


Many Possible Useful Collaborations Between Support Eng.

Transformation Engineering

Model Engineering

Data Engineering

Program Engineering

Model Engineering


Service Engineering

Model Engineering

Data Engineering

Process Engineering

Model Engineering

Product Engineering


Combining Support Engineering

1,400,000 results N defs of MDA M defs of SOA P ways to combine them

Model Engineering

Service Engineering

?

?


Understanding complex relations

Business Engineering


?

?

Model Engineering


BPMN

UML

Data Engineering

Service Engineering


CONCLUSIONS Software Engineering is Engineering


Let’s forget about “Computer Science”

Computer Engineering

Program Engineering


Data Engineering

? Language

Engineering

Informatics

Platform Engineering


Conclusions

After nearly 50 years Software engineering is dead MDE missed the boat No other major silver bullet on the horizon

Good time to invent a new future SE as a branch of generic eEngineering (eE) eE using most of the ideas of MDE eE taking inspiration of the brightest ideas in

other domain or support engineering


Software Engineering and Engineering Software

Engineering

eEngineering

Software Engineering Civil Engineering Electrical Engineering


Unified Theories of Engineering

Yes we need to resurrect Software Engineering. The expression “Software Engineering” was coined in 1968. In 2018, for the 50th anniversary, a new “NATO-like” event to

refund SE2.0 on solid grounds, taking into account what has been learnt in half-a-century?

We need to invent SE2.0, in a radical departure from what has been done in the past 50 years. The problem is not to invent a marginally better

programming or modeling language. SE2.0 could/should be just be a specialization of

eEngineering, a generic view of modern engineering practices.

Short term proposal: a generic platform for eEngineering


Thanks

• Questions? • Comments?

[email protected]

bern.jb

Technology