e engineering

« Software Engineering at a Crossroads » Jean Bézivin

An introduction to “eEngineering”or

Software Engineering at a Crossroads

From Software Engineeringto Engineering Software

Work in progress

Warning: Some slides at subliminal speed


INTRODUCTIONSome bad news and some good news


Presenter/Presentation

1. In search of the ultimate silver bullet

1. Introduction2. Software Engineering 1.03. How Model Driven

Engineering Missed the Boat

2. From SE 1.0 to SE 2.01. Problem and Solution

Spaces2. Domain Engineering3. Support Engineering4. Conclusion

1967

1980

1987

1998

2008 There is NO silver bullet

Santa Claus does not exist


SOFTWARE ENGINEERINGIS NOT IN GOOD HEALTH

Sorry for the bad news


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?

(raw Ngrambuzzword observations)

Google Ngram Viewer

(1) Ivar Jacobson


ThoughtWorks, Technology Radar, May 2013

Languages & FrameworksAdopt

ClojureCSS frameworksJasmine paired with Node.jsScalaSinatra

TrialCoffeeScriptDropwizardHTML5 for offline applicationsJavaScript as a platformJavaScript MV* frameworksPlay Framework 2Require.js & NPMScratch, Alice, and Kodu

AssessClojureScriptGremlinLuaNancyOWINRubyMotionTwitter Bootstrap

HoldBackbone.jsComponent-based frameworksHandwritten CSSLogic in stored procedures

http://www.thoughtworks.com/radar




Looking at the past to guess the future

5 years 5 years

50 years 50 years


Paradigm/Artifact changes {step = 15y.}

ProceduralTechnology

ComponentTechnology

ObjectTechnology

Objects,Classes,

Smalltalk, C++,...

Procedures,Pascal,

C,...

Components,Packages,

Frameworks,Patterns,EJB, J2EE

1980 1995 2010

Proceduralrefinement

Model Driven Engineering

Models,Metamodels,UML, MOF,

…

Objectcomposition

Modeltransformation

1965


Software engineering: Approaching half-time?

1965 2015 2065

StructuredProgramming

ObjectOriented

Programming

AgileDevelopment

?

1967

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

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

Software Professionals

(1%)

End User Programmers

(99%)

?

1965 2015

100%

0%

Total inversion:Percentage of non software professionalusing computers and software applicationsat work, home, etc.


Everybody’s a programmer

www.bricklin.com

Visicalc (1979) Excel (much later)


U.S. Bureau of Labor Statistics (2002)

Description Number Ann. Salary Software Eng., Applications 356,760 $73,800 Software Eng., System Software 255,040 $75,840 Aerospace Engineers 74,210 $74,110 Agricultural Engineers 2,500 $55,730 Biomedical Engineers 7,130 $64,420 Chemical Engineers 32,110 $75,010 Civil Engineers 207,480 $63,010 Computer Hardware Engineers 67,180 $76,150 Electrical Engineers 146,180 $70,480 Electronics Eng., Exc. Computer 126,020 $71,600 Environmental Engineers 45,720 $63,440 Health and Safety, Exc. Mining 34,160 $59,830 Industrial Engineers 151,760 $63,590 Marine Eng., Naval Architects 4,810 $68,280 Materials Engineers 22,780 $64,310 Mechanical Engineers 203,620 $65,170 Mining and Geological Eng. 5,050 $64,770 Nuclear Engineers 15,180 $82,300 Petroleum Engineers 11,130 $85,540

611.900 (35%)

1.157.020 (65%)


Software vs. Traditional Engineering

Software Engineers

(35%)

TraditionalEngineers

(65%)

?

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


Old and New engineering fields


HOW MDE MISSED THE BOATThe last silver bullet fired blank

Model Driven Engineering


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! (paper-driven)

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 models3. 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 MMM5. Transformation principle

The most important operation applicable to models is a transformation

6. HOT principle A transformation is a model (an

executable model)7. Weaving principle

Abstract correspondences between models may be represented as models (non-executable)

8. Megamodel principle Model elements may be considered

as models9. Unification principle

All models specialize a common abstract model

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

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

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


MDE is not only for code generation

SoftwareEngineering

SystemEngineering

DataEngineering

BusinessEngineering

appliesTo

ModelDriven

Engineering

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

UML/SPEM CWM SysML BPMN

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.

Broadening application spectrum


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.

Model Engineering

ModelDriven

Engineering

MDSE(UML)

MDsysE(SysML)

MDbizE(BPMN)

MDDMDrevE

MDCG

uses


ME and DSLs

2005 2010 2015 2020 2025

Number of professional programmers

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

Num

ber o

f app

licati

ons

Model Engineering

(DomainSpecific)Language

Engineering


The long history of modeling languages

ProgrammingLanguages

Assembler

Fortran COBOLAlgol60

PL/1 ADA JavaC#

Smalltalk

C++Ruby Scala

PythonF# Go

Dart

(DS)Modeling

LanguagesSara

SREM SADTPetri JSD

DFDB

OMT

Z

VDM

UMLSART

Flowcharts

Lisp

Prolog

SysML

Pascal

PSL/PSA

SBVR

Javascript

No global consolidated history of 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)

Other methods Booch 91 OOSEOMT-1

Booch 93 OMT-2

OOPSLA’95 Unified Method O.8

UML 0.9 & 0.91UML

partners expertise

UML 1.0

Submission of UML 1.0 to OMG for adoption (january 1997)

(june 96 - oct. 96)

november 1997UML-RTF created

UML 1.3 - autumn99

OMG/OOADTF (~1990)


DOMAIN AND SOLUTION SPACESBeyond technical 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

DomainEngineering

SupportEngineering

Problems lie here

Tools to solve problemsmay 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

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


DOMAIN ENGINEERINGProblem Spaces


Domain Engineering

Domain Engineering

Product Engineering

Process Engineering

Problem spaces

Solution spaces(Support Engineering)


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

ValidationVerification

Putting in Production

Augmenting,Changing the

world


Construction Engineering

Building abstract models

ValidationVerification

Putting in Production

Augmenting,Changing the

world


Complexity of theDomain 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/

Journal of Neural Engineering to help scientists, clinicians and engineersto 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 EngineeringBiomedical engineeringComputer-aided medical engineering Medical/disease modeling Rehabilitation engineering Healthcare energy systems engineering Healthcare support service engineering Emergency response engineeringEngineering 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.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 expertisebetween engineering fields

Architectural engineering Software engineering

1st published 1977


Many features commonto 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


SUPPORT ENGINEERINGBeyond Technical Spaces


Specialized engineering fields

Language Engineering

Software Language

Engineering

Model Engineering

Ontology Engineering

Grammar Engineering


Complexity of theSupport Engineering Landscape


Program Engineering

Ontology Engineering

Model Engineering

Web Engineering

Service Engineering

Transformation Engineering

Rule Engineering

Complex Event Engineering

Data Engineering

Process Engineering

Product Engineering

HR EngineeringTeam

EngineeringSoftware

EngineeringOther

Engineering


Composite Engineering Fields

Software Engineering

Program Engineering

Model Engineering


Method Engineering

Etc.


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


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 excellenceNoble and visible part of SEVery difficultMany iterations and branches

Structured ProgrammingOO ProgrammingFunctional ProgrammingEtc.


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

?

?


Many Possible Useful CollaborationsBetween Support Eng.

Transformation Engineering

Model Engineering

Data Engineering

Program Engineering

Model Engineering


Service Engineering

Model Engineering

Data Engineering

Process Engineering

Model Engineering

Product Engineering


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

?

?


Understanding complex relations

Business Engineering


?

?

Model Engineering


BPMN

UML

Data Engineering

Service Engineering


CONCLUSIONSSoftware Engineering is Engineering


A possible scenario for MDE

Visibility

Time

Technology trigger

Second tentative

MDE is too important to be confiscated by software people

2010 2020 2030 2040

WE ARE HERE


MDE is dead, Long life MDE

SoftwareEngineering

ModelDriven

Engineering

SoftwareEngineering

BusinessEngineering

EnterpriseEngineering

ModelEngineering

DataEngineering

FinancialEngineering

OtherEngineering

Fields

WebEngineering

BiologyEngineering


Software Engineering and Engineering Software

Engineering

eEngineering(Generic, includes ME)

Software Engineering Enterprise EngineeringElectrical Engineering


DogFooding: Software Tools are Software Too

Support Engineering

Software Engineering Software Engineering

Domain Engineering

uses


usesEngineering Field

Domain Engineering

Support Engineering


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

Computer Engineering

Program Engineering


Data Engineering


Platform Engineering

Model Engineering


Proposal for a Call to ArmsUnified 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 yearsSoftware engineering (SE) needs to be revisited in

its goalsMDE did not meet all expectations but has

nevertheless a great potentialNo other major silver bullet on the horizon

Good time to invent a new futureSE as a branch of Engineering Software (ES)ES using most of the ideas of ME


Thanks

• Questions?• Comments?

[email protected]@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]

mailto:[email protected]


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