Warning: Some slides at subliminal speed

An introduction to “eEngineering”
or
Software Engineering at a Crossroads
From S...
Some bad news and some good news

INTRODUCTION

« Software Engineering at a Crossroads » Jean Bézivin
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....
Sorry for the bad news

SOFTWARE ENGINEERING
IS NOT IN GOOD HEALTH
« Software Engineering at a Crossroads » Jean Bézivin
Requiem for Software Engineering 1.0

« Software Engineering at a Crossroads » Jean Bézivin
Not dead, but at least critically ill
The NATO Conferences of 1968 and 1969 were
motivated by the belief that software
dev...
Hype after Hype
 Are we condemned to jump from hype to hype like a
fashion industry? (1)
 What is the hidden meaning (if...
ThoughtWorks, Technology Radar, May 2013
Languages & Frameworks
Adopt
Clojure
CSS frameworks
Jasmine paired with Node.js
S...
Looking at the past to guess the future

5 years

5 years

50 years

50 years

« Software Engineering at a Crossroads » Je...
Paradigm/Artifact changes {step = 15y.}
1965
Procedural
Technology

1980

Procedures,
Pascal,
C,
...

Procedural
refinemen...
Software engineering: Approaching half-time?
?

Agile
Development
Object
Oriented
Programming

Structured
Programming

196...
Predictions
”Predictions are very hard, especially about the future”
 The second part of the life of SE (2015-2065) will ...
What has changed in the past 50 years ?

 Expressions like “CAD” or “Computer Assisted” or
“Computer Aided” have lost all...
Software professionals vs. End User Developers

« Software Engineering at a Crossroads » Jean Bézivin
Software Professionals and End Users
?
End User
Programmers

Software
Professionals

(1%)

(99%)

100%
Total inversion:
Pe...
Everybody’s a programmer

Visicalc (1979)

Excel (much later)
www.bricklin.com

« Software Engineering at a Crossroads » J...
U.S. Bureau of Labor Statistics (2002)
Description

Number

Ann. Salary

Software Eng., Applications
Software Eng., System...
Software vs. Traditional Engineering
?
Software
Engineers
(35%)

Traditional
Engineers
(65%)

Will have to imagine new way...
Old and New engineering fields

« Software Engineering at a Crossroads » Jean Bézivin
Model Driven Engineering

The last silver bullet fired blank

HOW MDE MISSED THE BOAT

« Software Engineering at a Crossro...
Sustainable Modeling?
 The first promise/commitment of
MDA™ was on sustainability:
 “Developers gain the ultimate in fle...
Steve Cook (OOPSLA 2004 panel)
suggested that MDA proponents fall into the following three
camps:
1. The UML PIM camp: MDA...
but there are much more than 3 camps in MDE
 Some Facets (Niches)

















UML blueprint
UML as a...
“Lost in the MetaJungle” Syndrome














UML
fUML
xUML
ALF
SysML
SoaML
MOF
SyML
ADM
KDM
ASTM
SPEM
BPMN...
But we learnt many things from MDE
1. Representation principle
 Any model M represents a system S
2. Multiple view princi...
Not all models are software models,
but most of them are

Creative Commons http://en.wikipedia.org/wiki/File:Renault_clay_...
MDE is not only for code generation
Initially MDA was for just software engineering,
But the scope was progressively exten...
Model
Engineering

Model
Driven
Engineering

MDbizE

MDSE

MDsysE

(BPMN)

(UML)

(SysML)

MDrevE

MDD

MDCG

Definition F...
ME and DSLs

Model
Engineering

(Domain
Specific)
Language
Engineering

2005

« Software Engineering at a Crossroads » Jea...
The long history of modeling languages
Lisp
Algol60
Fortran COBOL
PL/1
Prolog
Assembler

Smalltalk
ADA
Pascal

C++

Ruby

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

Flowcharts (~1950)
Petri Nets (~1960-1970)
PSL/PSA (~1967)
State Diagra...
Beyond technical spaces

DOMAIN AND SOLUTION SPACES

« Software Engineering at a Crossroads » Jean Bézivin
Focus on Engineering
Scientists study the world as it is; engineers
create the world that has never been.
Theodore von Kár...
The two engineering spaces

Problems lie here

Tools to solve problems
may be found here

Domain
Engineering

Support
Engi...
Problems and Solutions
 Support Engineering (vertical?)













Process engineering
Product (line) engin...
Problem Spaces

DOMAIN ENGINEERING

« Software Engineering at a Crossroads » Jean Bézivin
Domain Engineering
Domain
Engineering

Problem spaces

Solution spaces

Product
Engineering

(Support Engineering)

« Soft...
Domain Engineering
 Similar processes across all engineering
fields
1.

Build abstract models



2.

Verify/Validate Ab...
Electrical Engineering
Building abstract
models

Validation
Verification

« Software Engineering at a Crossroads » Jean Bé...
Construction Engineering
Building abstract
models

Validation
Verification

« Software Engineering at a Crossroads » Jean ...
Complexity of the
Domain Engineering Landscape
Civil
Engineering

Electrical
Engineering

Automotive
Engineering

Architec...
Many Communities, Many Journals

http://www.govengr.com/
Neural engineering (also
known as
Neuroengineering) is a
discipli...
And many more

« Software Engineering at a Crossroads » Jean Bézivin
Synergies Between Engineering Fields
Program Engineering

“The Origins of Pattern Theory, the
Future of the Theory, And Th...
Transfer of expertise
between engineering fields

1st published 1977

Architectural engineering
« Software Engineering at ...
Many features common
to all domain engineering fields
 Based on support engineering
 Product & Process focus
 Including...
Beyond Technical Spaces

SUPPORT ENGINEERING

« Software Engineering at a Crossroads » Jean Bézivin
Specialized engineering fields

Language
Engineering

Software
Language
Engineering

Grammar
Engineering

Model
Engineerin...
Complexity of the
Support Engineering Landscape
Language
Engineering

Program
Engineering

Ontology
Engineering

Model
Eng...
Composite Engineering Fields
Program
Engineering

Model
Engineering
Software
Engineering

Language
Engineering

Method
Eng...
Process engineering
 Process engineering
encompasses a vast range
of industries, such as
chemical, petrochemical,
mineral...
Team and Product management
Team Management
Engineering

Product Lifecyle
Management (PLM)

Software Team
Management
Engin...
Data Engineering

« Software Engineering at a Crossroads » Jean Bézivin
Program Engineering
Short name: “programming”
Long tradition of excellence
Noble and visible part of SE
Very difficult...
Making implicit relations explicit

Language
Engineering

?

?

Program
Engineering

 Language engineering is
related to ...
Many Possible Useful Collaborations
Between Support Eng.
Service
Engineering

Data
Engineering

Process
Engineering

Model...
Sound terminologies are always useful

Programming is
Modeling

 Good definitions allow avoiding
sterile, futile, and non...
Understanding complex relations
BPMN

Business
Engineering

?

?

Model
Engineering

Language
Engineering

« Software Engi...
Software Engineering is Engineering

CONCLUSIONS

« Software Engineering at a Crossroads » Jean Bézivin
A possible scenario for MDE
Visibility

Second tentative

Technology trigger
2010

2020

2030

2040

Time

MDE is too impo...
MDE is dead, Long life MDE
Enterprise
Software
Engineering Engineering

Software
Engineering

Business
Engineering

Data
E...
Software Engineering and Engineering Software

Engineering

eEngineering
(Generic, includes ME)

Electrical Engineering

S...
DogFooding: Software Tools are Software Too
Support Engineering

Software Engineering

Domain Engineering

uses

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

Computer
Engineering

Language
Engine...
Proposal for a Call to Arms
Unified Global Theory of Engineering
 Yes we need to resurrect Software Engineering.
 The ex...
Conclusions
After nearly 50 years
Software engineering (SE) needs to be revisited in
its goals
MDE did not meet all exp...
Thanks
• Questions?
• Comments?
JBezivin@gmail.com
JBezivin@twitter
« Qu'on ne me dise pas que je n'ai rien dit de nouveau...
Abstract
Less than fifty years ago, the discipline of software
engineering was proposed to face the multiple challenges of...
Upcoming SlideShare
Loading in …5
×

E engineering

1,831 views

Published on

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.

Published in: Technology

E engineering

  1. 1. 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
  2. 2. Some bad news and some good news INTRODUCTION « Software Engineering at a Crossroads » Jean Bézivin
  3. 3. 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 « Software Engineering at a Crossroads » Jean Bézivin Introduction Software Engineering 1.0 How Model Driven Engineering Missed the Boat 2. 3. 4. Problem and Solution Spaces Domain Engineering Support Engineering Conclusion
  4. 4. Sorry for the bad news SOFTWARE ENGINEERING IS NOT IN GOOD HEALTH « Software Engineering at a Crossroads » Jean Bézivin
  5. 5. Requiem for Software Engineering 1.0 « Software Engineering at a Crossroads » Jean Bézivin
  6. 6. 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 « Software Engineering at a Crossroads » Jean Bézivin
  7. 7. 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) « Software Engineering at a Crossroads » Jean Bézivin (1) Ivar Jacobson
  8. 8. 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 « Software Engineering at a Crossroads » Jean Bézivin Backbone.js Component-based frameworks Handwritten CSS Logic in stored procedures
  9. 9. Looking at the past to guess the future 5 years 5 years 50 years 50 years « Software Engineering at a Crossroads » Jean Bézivin
  10. 10. 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 « Software Engineering at a Crossroads » Jean Bézivin Model Driven Engineering Models, Metamodels, UML, MOF, … Model transformation
  11. 11. 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/ « Software Engineering at a Crossroads » Jean Bézivin
  12. 12. 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. « Software Engineering at a Crossroads » Jean Bézivin
  13. 13. 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 Engineering at a Crossroads » Jean Bézivin
  14. 14. Software professionals vs. End User Developers « Software Engineering at a Crossroads » Jean Bézivin
  15. 15. 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 « Software Engineering at a Crossroads » Jean Bézivin
  16. 16. Everybody’s a programmer Visicalc (1979) Excel (much later) www.bricklin.com « Software Engineering at a Crossroads » Jean Bézivin
  17. 17. 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 « Software Engineering at a Crossroads » Jean Bézivin 611.900 (35%) 1.157.020 (65%)
  18. 18. Software vs. Traditional Engineering ? Software Engineers (35%) Traditional Engineers (65%) Will have to imagine new ways for working together in the next decades « Software Engineering at a Crossroads » Jean Bézivin
  19. 19. Old and New engineering fields « Software Engineering at a Crossroads » Jean Bézivin
  20. 20. Model Driven Engineering The last silver bullet fired blank HOW MDE MISSED THE BOAT « Software Engineering at a Crossroads » Jean Bézivin
  21. 21. 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 « Software Engineering at a Crossroads » Jean Bézivin
  22. 22. 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. « Software Engineering at a Crossroads » Jean Bézivin http://blogs.msdn.com/stevecook
  23. 23. 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 « Software Engineering at a Crossroads » Jean Bézivin
  24. 24. “Lost in the MetaJungle” Syndrome              UML fUML xUML ALF SysML SoaML MOF SyML ADM KDM ASTM SPEM BPMN           « Software Engineering at a Crossroads » Jean Bézivin 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.
  25. 25. 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. « Software Engineering at a Crossroads » Jean Bézivin 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)
  26. 26. Not all models are software models, but most of them are Creative Commons http://en.wikipedia.org/wiki/File:Renault_clay_model_-_front.JPG « Software Engineering at a Crossroads » Jean Bézivin
  27. 27. 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 at a Crossroads » Jean Bézivin                 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.
  28. 28. 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         « Software Engineering at a Crossroads » Jean Bézivin 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.
  29. 29. ME and DSLs Model Engineering (Domain Specific) Language Engineering 2005 « Software Engineering at a Crossroads » Jean Bézivin 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;
  30. 30. 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 « Software Engineering at a Crossroads » Jean Bézivin OMT SBVR SysML (DS) Modeling Languages
  31. 31. 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
  32. 32. Beyond technical spaces DOMAIN AND SOLUTION SPACES « Software Engineering at a Crossroads » Jean Bézivin
  33. 33. Focus on Engineering Scientists study the world as it is; engineers create the world that has never been. Theodore von Kármán « Software Engineering at a Crossroads » Jean Bézivin
  34. 34. The two engineering spaces Problems lie here Tools to solve problems may be found here Domain Engineering Support Engineering « Software Engineering at a Crossroads » Jean Bézivin
  35. 35. 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?)          « Software Engineering at a Crossroads » Jean Bézivin Civil engineering Building engineering Electrical engineering Mechanical engineering Business engineering Biological engineering Automotive engineering Health engineering Enterprise Engineering
  36. 36. Problem Spaces DOMAIN ENGINEERING « Software Engineering at a Crossroads » Jean Bézivin
  37. 37. Domain Engineering Domain Engineering Problem spaces Solution spaces Product Engineering (Support Engineering) « Software Engineering at a Crossroads » Jean Bézivin Process Engineering
  38. 38. 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. « Software Engineering at a Crossroads » Jean Bézivin
  39. 39. Electrical Engineering Building abstract models Validation Verification « Software Engineering at a Crossroads » Jean Bézivin Putting in Production Augmenting, Changing the world
  40. 40. Construction Engineering Building abstract models Validation Verification « Software Engineering at a Crossroads » Jean Bézivin Putting in Production Augmenting, Changing the world
  41. 41. 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 « Software Engineering at a Crossroads » Jean Bézivin
  42. 42. 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. « Software Engineering at a Crossroads » Jean Bézivin 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.
  43. 43. And many more « Software Engineering at a Crossroads » Jean Bézivin
  44. 44. 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 « Software Engineering at a Crossroads » Jean Bézivin
  45. 45. Transfer of expertise between engineering fields 1st published 1977 Architectural engineering « Software Engineering at a Crossroads » Jean Bézivin Software engineering
  46. 46. 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 « Software Engineering at a Crossroads » Jean Bézivin
  47. 47. Beyond Technical Spaces SUPPORT ENGINEERING « Software Engineering at a Crossroads » Jean Bézivin
  48. 48. Specialized engineering fields Language Engineering Software Language Engineering Grammar Engineering Model Engineering Ontology Engineering « Software Engineering at a Crossroads » Jean Bézivin
  49. 49. 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 « Software Engineering at a Crossroads » Jean Bézivin
  50. 50. Composite Engineering Fields Program Engineering Model Engineering Software Engineering Language Engineering Method Engineering Etc. « Software Engineering at a Crossroads » Jean Bézivin
  51. 51. 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 « Software Engineering at a Crossroads » Jean Bézivin Process Engineering Software Process Engineering SPEM
  52. 52. Team and Product management Team Management Engineering Product Lifecyle Management (PLM) Software Team Management Engineering Product Line Engineering Agile Methods Software Product Line Engineering « Software Engineering at a Crossroads » Jean Bézivin
  53. 53. Data Engineering « Software Engineering at a Crossroads » Jean Bézivin
  54. 54. 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. « Software Engineering at a Crossroads » Jean Bézivin
  55. 55. 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). « Software Engineering at a Crossroads » Jean Bézivin
  56. 56. 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 « Software Engineering at a Crossroads » Jean Bézivin Transformation Engineering Data Engineering Model Engineering
  57. 57. 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 ? « Software Engineering at a Crossroads » Jean Bézivin Program Engineering
  58. 58. Understanding complex relations BPMN Business Engineering ? ? Model Engineering Language Engineering « Software Engineering at a Crossroads » Jean Bézivin Software Engineering Data Engineering UML Service Engineering
  59. 59. Software Engineering is Engineering CONCLUSIONS « Software Engineering at a Crossroads » Jean Bézivin
  60. 60. 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 « Software Engineering at a Crossroads » Jean Bézivin
  61. 61. 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 « Software Engineering at a Crossroads » Jean Bézivin Financial Engineering Other Engineering Fields
  62. 62. Software Engineering and Engineering Software Engineering eEngineering (Generic, includes ME) Electrical Engineering Software Engineering « Software Engineering at a Crossroads » Jean Bézivin Enterprise Engineering
  63. 63. DogFooding: Software Tools are Software Too Support Engineering Software Engineering Domain Engineering uses Software Engineering Engineering Field Domain Engineering Support Engineering « Software Engineering at a Crossroads » Jean Bézivin uses Software Engineering
  64. 64. Semantic map very useful for RTI (Research/Teaching/Innovation) Program Engineering Computer Engineering Language Engineering Model Engineering Platform Engineering « Software Engineering at a Crossroads » Jean Bézivin Data Engineering Software Engineering
  65. 65. 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 « Software Engineering at a Crossroads » Jean Bézivin
  66. 66. 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 « Software Engineering at a Crossroads » Jean Bézivin
  67. 67. 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] « Software Engineering at a Crossroads » Jean Bézivin
  68. 68. 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. « Software Engineering at a Crossroads » Jean Bézivin

×