E engineering

Warning: Some slides at subliminal speed

An introduction to “eEngineering”
or
Software Engineering at a Crossroads
From Software Engineering
to Engineering Software

« Software Engineering at a Crossroads » Jean Bézivin

Work in progress

Some bad news and some good news

INTRODUCTION


Presenter/Presentation
1.

1967

In search of the ultimate
silver bullet
1.
2.
3.

1980

2.
1987

From SE 1.0 to SE 2.0
1.

1998

Santa Claus does not exist

There is NO silver bullet
2008

Introduction
Software Engineering 1.0
How Model Driven
Engineering Missed the
Boat

2.
3.
4.

Problem and Solution
Spaces
Domain Engineering
Support Engineering
Conclusion

Sorry for the bad news

SOFTWARE ENGINEERING
IS NOT IN GOOD HEALTH

Requiem for Software Engineering 1.0


Not dead, but at least critically ill
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

Software engineering is gravely hampered
today by immature practices:
 The prevalence of fad's more typical
of fashion industry than of an
engineering discipline
 The lack of a sound, widely accepted
theoretical basis
 The huge number of methods and
method variants, with differences
little understood and artificially
magnified
 The lack of credible experimental
evaluation and validation
 The split between industry practice
and academic research


Hype after Hype
 Are we condemned to jump from hype to hype like a
fashion industry? (1)
 What is the hidden meaning (if any) in the evolution
of our discipline?

Google Ngram
Viewer
(raw Ngram
buzzword observations)


(1) Ivar

Jacobson

ThoughtWorks, Technology Radar, May 2013
Languages & Frameworks
Adopt
Clojure
CSS frameworks
Jasmine paired with Node.js
Scala
Sinatra
Trial
CoffeeScript
Dropwizard
HTML5 for offline applications
JavaScript as a platform
JavaScript MV* frameworks
Play Framework 2
Require.js & NPM
Scratch, Alice, and Kodu
Assess
ClojureScript
Gremlin
Lua
Nancy
OWIN
RubyMotion
Twitter Bootstrap
Hold

http://www.thoughtworks.com/radar


Backbone.js
Component-based frameworks
Handwritten CSS
Logic in stored procedures

Looking at the past to guess the future

5 years

5 years

50 years

50 years


Paradigm/Artifact changes {step = 15y.}
1965
Procedural
Technology

1980

Procedures,
Pascal,
C,
...

Procedural
refinement

2010

1995
Object
Technology

Component
Technology

Objects,
Classes,
Smalltalk, C++,
...

Components,
Packages,
Frameworks,
Patterns,
EJB, J2EE

Object
composition


Model Driven
Engineering

Models,
Metamodels,
UML, MOF,

…
Model
transformation

Software engineering: Approaching half-time?
?

Agile
Development
Object
Oriented
Programming

Structured
Programming

1965

1967

2015

2065

http://bertrandmeyer.com/2013/04/04/the-origin-of-software-engineering/


Predictions
”Predictions are very hard, especially about the future”
 The second part of the life of SE (2015-2065) will be more in rupture than
in continuity
 Change of focus: from Software Engineering to Engineering Software?
 Wikipedia: “Software engineering (SE) is the application of a
systematic, disciplined, quantifiable approach to the
design, development, operation, and maintenance of software, and the study
of these approaches; that is, the application of engineering to software”

 More relevant is the increasing need for the application of
(advanced form of) software to engineering





This evolution already started
We have seen only the beginning of it
Not simply computers as in (CAD), but software
Not any kind of software, but probably “eEngineering” with a lot of software
models.


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

Software professionals vs. End User Developers


Software Professionals and End Users
?
End User
Programmers

Software
Professionals

(1%)

(99%)

100%
Total inversion:
Percentage of non software professional
using computers and software applications
at work, home, etc.

0%
1965

2015


Everybody’s a programmer

Visicalc (1979)

Excel (much later)
www.bricklin.com


U.S. Bureau of Labor Statistics (2002)
Description

Number

Ann. Salary

Software Eng., Applications
Software Eng., System Software

356,760
255,040

$73,800
$75,840

Aerospace Engineers
Agricultural Engineers
Biomedical Engineers
Chemical Engineers
Civil Engineers
Computer Hardware Engineers
Electrical Engineers
Electronics Eng., Exc. Computer
Environmental Engineers
Health and Safety, Exc. Mining
Industrial Engineers
Marine Eng., Naval Architects
Materials Engineers
Mechanical Engineers
Mining and Geological Eng.
Nuclear Engineers
Petroleum Engineers

74,210
2,500
7,130
32,110
207,480
67,180
146,180
126,020
45,720
34,160
151,760
4,810
22,780
203,620
5,050
15,180
11,130

$74,110
$55,730
$64,420
$75,010
$63,010
$76,150
$70,480
$71,600
$63,440
$59,830
$63,590
$68,280
$64,310
$65,170
$64,770
$82,300
$85,540


611.900 (35%)

1.157.020 (65%)

Software vs. Traditional Engineering
?
Software
Engineers
(35%)

Traditional
Engineers
(65%)

Will have to imagine new ways for working together in the next decades


Old and New engineering fields


Model Driven Engineering

The last silver bullet fired blank

HOW MDE MISSED THE BOAT


Sustainable Modeling?
 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 as
the underlying infrastructure shifts over
time”.
 “ROI flows from the reuse of application
and domain models across the software
lifespan--especially during long-term
support and maintenance, the most
expensive phase of an application's life”.

 The MDA™ did not deliver on
sustainability.
 Reasons are multiple:





Complexity of UML
Evolution of UML (versions)
Broken UML profiles
UML tools not based on the UML
metamodel (no dogfooding)
 Bad interoperability of UML tools
 Versions of XMI

 As a result, Java code is probably
more sustainable than most UML
models
 In direct violation of PIM/PSM separation
objective


Steve Cook (OOPSLA 2004 panel)
suggested that MDA proponents fall into the following three
camps:
1. The UML PIM camp: MDA involves the use of UML to build Platform
Independent Models (PIMs) which are transformed into Platform
Specific Models (PSMs) from which code is generated.
2. The MOF camp: MDA does not involve the use of UML, but instead
the crucial technology is MOF, and the definition of modelling
languages and language transformations using MOF.
3. The Executable UML camp: MDA involves building a UML compiler,
making it a first class programming language.


http://blogs.msdn.com/stevecook

but there are much more than 3 camps in MDE
 Some Facets (Niches)

















UML blueprint
UML as a GPL
UML as a DSL framework
PIM/PSM sustainability vision
UML as a universal knowledge
representation language
Executable UML (PL)
Visual Programming
DDD
Code generation from UML
Code Generation from other models
Full extensible external DSLs (MOF)
Model to Text Transformation
Model to Model Transformations
Reverse engineering
Interoperability
… and many more

 The problem does not stem from the high
number of visions on MDE, but from the
fact that several of them are completely
contradictory
 “UML Engineering” is different from
“Model Engineering”
 Main reason why industry (big companies)
lost confidence
 Asking a company what they believe
about using MDE has no meaning/value
 Some niches are quite successful (e.g.
code generation, documentation)
 One very successful area is academic
“research” paper publishing! (paperdriven)
 Also metamodel procrastination is still
doing quite well


“Lost in the MetaJungle” Syndrome














UML
fUML
xUML
ALF
SysML
SoaML
MOF
SyML
ADM
KDM
ASTM
SPEM
BPMN














QVT
OCL
XMI
MOFM2T
OSM (Organization Structure
Metamodel)
VDML (Value Delivery Modeling
Language)
UTP (UML Testing Profile)
BMM (Business Motivation Model)
SBVR (Semantics of Business
Vocabulary and Business Rules)
etc.

But we learnt many things from 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.

7.

8.

9.

10.


HOT principle
 A transformation is a model (an
executable model)
Weaving principle
 Abstract correspondences between
models may be represented as
models (non-executable)
Megamodel principle
 Model elements may be considered
as models
Unification principle
 All models specialize a common
abstract model
Technical Space Framework
 Any model has a given
representation defined by its
technical space (no MOF/ECORE
lock-in)

Not all models are software models,
but most of them are

Creative Commons http://en.wikipedia.org/wiki/File:Renault_clay_model_-_front.JPG


MDE is not only for code generation
Initially MDA was for just software engineering,
But the scope was progressively extended

Model
Driven
Engineering

appliesTo

Software
Engineering

UML/SPEM

Data
Engineering

System
Engineering

CWM

SysML

Business
Engineering

BPMN

Broadening application spectrum



















Software engineering
Data engineering
System engineering
Business engineering
Enterprise engineering
Telecommunication engineering
Building engineering
Electrical engineering
Mechanical engineering
Automotive engineering
Aeronautical engineering
Biological engineering
Health engineering
Financial engineering
Political engineering (!)
etc.

Model
Engineering

Model
Driven
Engineering

MDbizE

MDSE

MDsysE

(BPMN)

(UML)

(SysML)

MDrevE

MDD

MDCG

Definition Framework
 (Software) Model Engineering (ME)
promotes the systematic use of models,
metamodels and model transformations to
achieve industrial goals (based on ako
algebra of models).
 Model Driven Engineering (MDE) is the
application of ME principles and tools to any
given engineering field.
 Model Driven Software Engineering (MDSE)
 Model Driven (Software) Development
(MDD)
 Model Driven Code Generation(MDCG)
 Model Driven Reverse Engineering (MDrevE)
 But also










Model Driven Business Engineering (MDbizE)
Model Driven System Engineering (MDsysE)
Model Driven Data Engineering
Model Driven Web Engineering
Model Driven Requirement Engineering
Model Driven Civil Engineering
Model Driven Biological Engineering
etc.

ME and DSLs

Model
Engineering

(Domain
Specific)
Language
Engineering

2005


2010

2015

2020

2025

Est. USA 2012:
90 Millions computer users;
50 Millions Spreadsheet & DB users;
12 Millions self described programmers;
3 Millions professional programmers;

The long history of modeling languages
Lisp
Algol60
Fortran COBOL
PL/1
Prolog
Assembler

Smalltalk
ADA
Pascal

C++

Ruby

Java

C#

Javascript
Python

F#

Scala

Dart

Programming
Languages

Go

No global consolidated history of Modeling Languages

Flowcharts
Sara

Petri
SREM

PSL/PSA

SADT
SART

JSD

Z
DFD

UML

B
VDM


OMT

SBVR
SysML

(DS)
Modeling
Languages

Software Modeling Languages












Flowcharts (~1950)
Petri Nets (~1960-1970)
PSL/PSA (~1967)
State Diagrams (~1967)
SADT (~1969)
Mascot (~1970)
DFD (~1975)
Entity-Association (~1976)
JSD (~1982)
AD/Cycle (~1982)
UML (~1996)

UML 1.3 - autumn99

november 1997

UML-RTF created

Submission of UML 1.0 to OMG
for adoption (january 1997)
UML 1.0
(june 96 - oct. 96) UML 0.9 & 0.91

UML
partners expertise

OOPSLA’95 Unified Method O.8
Booch 93

Other methods

OMT-2

Booch 91

OMT-1

« Software Engineering at a Crossroads » Jean Bézivin OMG/OOADTF (~1990)

OOSE

Beyond technical spaces

DOMAIN AND SOLUTION SPACES


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

Problems lie here

Tools to solve problems
may be found here

Domain
Engineering

Support
Engineering


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

 Domain Engineering (horizontal?)











Civil engineering
Building engineering
Electrical engineering
Mechanical engineering
Business engineering
Biological engineering
Automotive engineering
Health engineering
Enterprise Engineering

Problem Spaces

DOMAIN ENGINEERING


Domain Engineering
Domain
Engineering

Problem spaces

Solution spaces

Product
Engineering

(Support Engineering)


Process
Engineering

Domain Engineering
 Similar processes across all engineering
fields
1.

Build abstract models



2.

Verify/Validate Abstract Models


3.

Using some validation technique

Put into production



4.

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

Create Products from Models
Automatic, Semi-automatic or Manual

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

Complexity of the
Domain Engineering Landscape
Civil
Engineering

Electrical
Engineering

Automotive
Engineering

Architecture
Engineering

Medical
Engineering

Chemical
Engineering

Biological
Engineering

Telephone
Engineering

Military
Engineering

Financial
Engineering

Business
Engineering

Enterprise
Engineering

Ecology
Engineering

Agricultural
Engineering

Communication
Engineering

Other
Engineering
Fields


Many Communities, Many Journals

http://www.govengr.com/
Neural engineering (also
known as
Neuroengineering) is a
discipline
within biomedical
engineering that uses
engineering techniques
to
understand, repair, replac
e, enhance, or otherwise
exploit the properties of
neural systems
Journal of Neural Engineering to help scientists, clinicians and engineers
to understand, replace, repair and enhance the nervous system.


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

“The Origins of Pattern Theory, the
Future of the Theory, And The
Generation of a Living World”
Christopher Alexander

Building Engineering

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


Transfer of expertise
between engineering fields

1st published 1977

Architectural engineering

Software engineering

Many features common
to all domain engineering fields
 Based on support engineering
 Product & Process focus
 Including HR and team management (engineers in the loop)

 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

Beyond Technical Spaces

SUPPORT ENGINEERING


Specialized engineering fields

Language
Engineering

Software
Language
Engineering

Grammar
Engineering

Model
Engineering

Ontology
Engineering


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

Software
Engineering

Other
Engineering


Composite Engineering Fields
Program
Engineering

Model
Engineering
Software
Engineering

Language
Engineering

Method
Engineering
Etc.


Process engineering
 Process engineering
encompasses a vast range
of industries, such as
chemical, petrochemical,
mineral
processing, advanced
material, food, pharmaceu
tical, biotechnological, and
software industries.
 See also Concurrent
Engineering


Process Engineering

Software Process
Engineering

SPEM

Team and Product management
Team Management
Engineering

Product Lifecyle
Management (PLM)

Software Team
Management
Engineering

Product Line
Engineering

Agile Methods

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.

Making implicit relations explicit

Language
Engineering

?

?

Program
Engineering

 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).


Many Possible Useful Collaborations
Between Support Eng.
Service
Engineering

Data
Engineering

Process
Engineering

Model
Engineering

Program
Engineering

Product
Engineering

Model
Engineering

Language
Engineering

Model
Engineering


Transformation
Engineering

Data
Engineering

Model
Engineering

Sound terminologies are always useful

Programming is
Modeling

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

Model
Engineering

?

Modeling is
Programming

?


Program
Engineering

Understanding complex relations
BPMN

Business
Engineering

?

?

Model
Engineering

Language
Engineering


Software
Engineering

Data
Engineering

UML

Service
Engineering

Software Engineering is Engineering

CONCLUSIONS


A possible scenario for MDE
Visibility

Second tentative

Technology trigger
2010

2020

2030

2040

Time

MDE is too important to be confiscated by software people

MDE is dead, Long life MDE
Enterprise
Software
Engineering Engineering

Software
Engineering

Business
Engineering

Data
Engineering
Model
Engineering

Model
Driven
Engineering

Web
Engineering

Biology
Engineering


Financial
Engineering
Other
Engineering
Fields

Software Engineering and Engineering Software

Engineering

eEngineering
(Generic, includes ME)

Electrical Engineering

Software Engineering


Enterprise Engineering

DogFooding: Software Tools are Software Too
Support Engineering


Domain Engineering

uses


Engineering Field

Domain
Engineering

Support
Engineering


uses


Semantic map very useful for RTI
(Research/Teaching/Innovation)
Program
Engineering

Computer
Engineering

Language
Engineering

Model
Engineering

Platform
Engineering


Data Engineering

Software
Engineering

Proposal for a Call to Arms
Unified Global Theory of Engineering
 Yes we need to resurrect Software Engineering.
 The expression “Software Engineering” was coined in 1965.
 In 2015, for the 50th anniversary, Let us hope 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.
 As a support engineering, ME will be quite important in defining
the core of eEngineering


Conclusions
After nearly 50 years
Software engineering (SE) needs to be revisited in
its goals
MDE did not meet all expectations but has
nevertheless a great potential
No other major silver bullet on the horizon

Good time to invent a new future
SE as a branch of Engineering Software (ES)
ES using most of the ideas of ME

Thanks
• Questions?
• Comments?
JBezivin@gmail.com
JBezivin@twitter
« Qu'on ne me dise pas que je n'ai rien dit de nouveau :
la disposition des matières est nouvelle …»
(Pascal, Pensées, 1669)
[Do not tell me that I did not say anything new:
arrangement of the material is new]

Abstract
Less than fifty years ago, the discipline of software
engineering was proposed to face the multiple challenges of
building and maintaining increasingly complex systems.
Moving from the individual creation of small programs to the
collective production of complex and evolutionary software
systems was rightly identified as a serious problem. But
attempts to solve it in a general way have been rather
deceiving. The recent tentative of considering most artifacts
as models and most operations in the lifecycle as model
transformations has not permitted to radically change the way
we build, operate and maintain software even if it has allowed
a much better understanding of the basic issues. Albeit we did
not achieve the ultimate goal of having models everywhere in
the software development cycle, the demonstration of the
tremendous potential of software modeling has now been
firmly established.
The subject of engineering has also changed a lot in the last
half-century. We realize that computers are now omnipresent
and software ubiquitous. We may revisit a lot of beliefs that
have been with us in the last decades and start thinking out of
the box. We may look for some "unifying theory of
engineering" and view software engineering as a
specialization of this conceptual framework, with some
expected benefits. In other words, we may revisit "software
engineering" as a special branch of "engineering software"
and show how software model engineering may be broadly
used through all the different branches.

To make things concrete, we can consider two broad
categories of engineering fields called "support engineering"
and "domain engineering". The first category defines a set of
technical spaces like service engineering, system engineering,
model engineering, constraint engineering, data engineering,
process engineering, language engineering, formal methods
engineering, and many more. At the opposite of this solution
space, we find the problem space with a lot of conventional
or emerging domain engineering fields like business, financial,
electrical, mechanical, civil, health, telecommunication,
avionics, biological and many more. There are many
commonalities of domain engineering that would gain to be
exposed: starting with the construction of abstract models
conforming to some ontology, a second step usually defines
some model validation or verification followed by a
manufacturing or production step and finally a deployment
step intended to augment or transform the real world. The
presentation will propose an initial cartography of support
and domain engineering, illustrating its possible impact on the
organization of research and advanced education. It will also
emphasize the important place taken by software model
engineering in this possible organization.


E engineering

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à E engineering

Similaire à E engineering (20)

Dernier

Dernier (20)

E engineering