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.
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
E engineering
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. Some bad news and some good news
INTRODUCTION
« Software Engineering at a Crossroads » Jean Bézivin
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. Sorry for the bad news
SOFTWARE ENGINEERING
IS NOT IN GOOD HEALTH
« Software Engineering at a Crossroads » Jean Bézivin
5. Requiem for Software Engineering 1.0
« Software Engineering at a Crossroads » Jean Bézivin
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. 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. 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. Looking at the past to guess the future
5 years
5 years
50 years
50 years
« Software Engineering at a Crossroads » Jean Bézivin
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. 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. 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
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
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. 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. Old and New engineering fields
« Software Engineering at a Crossroads » Jean Bézivin
20. Model Driven Engineering
The last silver bullet fired blank
HOW MDE MISSED THE BOAT
« Software Engineering at a Crossroads » Jean Bézivin
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. 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. 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. “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. 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. 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. 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. 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. 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. 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. 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
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. 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. 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
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
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. 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. And many more
« Software Engineering at a Crossroads » Jean Bézivin
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. Transfer of expertise
between engineering fields
1st published 1977
Architectural engineering
« Software Engineering at a Crossroads » Jean Bézivin
Software engineering
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
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
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. 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
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. 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. 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. 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
59. Software Engineering is Engineering
CONCLUSIONS
« Software Engineering at a Crossroads » Jean Bézivin
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. 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. 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. 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. 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. 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. 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. 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. 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