• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
E engineering
 

E engineering

on

  • 477 views

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

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.

Statistics

Views

Total Views
477
Views on SlideShare
474
Embed Views
3

Actions

Likes
1
Downloads
7
Comments
0

1 Embed 3

http://www.linkedin.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    E engineering E engineering Presentation Transcript

    • Warning: Some slides at subliminal speed An introduction to “eEngineering” or Software Engineering at a Crossroads From Software Engineering to Engineering Software « Software Engineering at a Crossroads » Jean Bézivin Work in progress
    • Some bad news and some good news INTRODUCTION « 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. 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
    • 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 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
    • 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
    • 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
    • Looking at the past to guess the future 5 years 5 years 50 years 50 years « Software Engineering at a Crossroads » Jean Bézivin
    • 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
    • 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
    • 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
    • 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
    • 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: 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
    • Everybody’s a programmer Visicalc (1979) Excel (much later) www.bricklin.com « Software Engineering at a Crossroads » Jean Bézivin
    • 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%)
    • 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
    • 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 Crossroads » Jean Bézivin
    • 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
    • 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
    • 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
    • “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.
    • 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)
    • 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
    • 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.
    • 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.
    • 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;
    • 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
    • Software Modeling Languages            Flowcharts (~1950) Petri Nets (~1960-1970) PSL/PSA (~1967) State Diagrams (~1967) SADT (~1969) Mascot (~1970) DFD (~1975) Entity-Association (~1976) JSD (~1982) AD/Cycle (~1982) UML (~1996) UML 1.3 - autumn99 november 1997 UML-RTF created Submission of UML 1.0 to OMG for adoption (january 1997) UML 1.0 (june 96 - oct. 96) UML 0.9 & 0.91 UML partners expertise OOPSLA’95 Unified Method O.8 Booch 93 Other methods OMT-2 Booch 91 OMT-1 « Software Engineering at a Crossroads » Jean Bézivin OMG/OOADTF (~1990) OOSE
    • Beyond technical spaces DOMAIN AND SOLUTION SPACES « 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ármán « Software Engineering at a Crossroads » Jean Bézivin
    • 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
    • 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
    • Problem Spaces DOMAIN ENGINEERING « Software Engineering at a Crossroads » Jean Bézivin
    • Domain Engineering Domain Engineering Problem spaces Solution spaces Product Engineering (Support Engineering) « Software Engineering at a Crossroads » Jean Bézivin Process Engineering
    • Domain Engineering  Similar processes across all engineering fields 1. Build abstract models   2. Verify/Validate Abstract Models  3. Using some validation technique Put into production   4. Using some given ontologies For example mechanics, electronics, etc. Create Products from Models Automatic, Semi-automatic or Manual Put into operation    Deployment Augment or change the real world Adding a new bridge, a new phone device, a new building, a new operational program, etc. « Software Engineering at a Crossroads » Jean Bézivin
    • Electrical Engineering Building abstract models Validation Verification « Software Engineering at a Crossroads » Jean Bézivin Putting in Production Augmenting, Changing the world
    • Construction Engineering Building abstract models Validation Verification « Software Engineering at a Crossroads » Jean Bézivin Putting in Production Augmenting, Changing the world
    • Complexity of the Domain Engineering Landscape Civil Engineering Electrical Engineering Automotive Engineering Architecture Engineering Medical Engineering Chemical Engineering Biological Engineering Telephone Engineering Military Engineering Financial Engineering Business Engineering Enterprise Engineering Ecology Engineering Agricultural Engineering Communication Engineering Other Engineering Fields « Software Engineering at a Crossroads » Jean Bézivin
    • 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.
    • 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 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
    • Transfer of expertise between engineering fields 1st published 1977 Architectural engineering « Software Engineering at a Crossroads » Jean Bézivin Software engineering
    • Many features common to all domain engineering fields  Based on support engineering  Product & Process focus  Including HR and team management (engineers in the loop)  Chain  Building Abstract Models  Verification/Validation  Putting in Production  Putting in operation  Need for a strong model repository  Scaling up to millions of parts  Cooperative concurrent access  Point of view mechanisms  Strong zooming mechanisms « Software Engineering at a Crossroads » Jean Bézivin
    • Beyond Technical Spaces SUPPORT ENGINEERING « Software Engineering at a Crossroads » Jean Bézivin
    • Specialized engineering fields Language Engineering Software Language Engineering Grammar Engineering Model Engineering Ontology Engineering « Software Engineering at a Crossroads » Jean Bézivin
    • 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
    • Composite Engineering Fields Program Engineering Model Engineering Software Engineering Language Engineering Method Engineering Etc. « Software Engineering at a Crossroads » Jean Bézivin
    • 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
    • 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
    • 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 Many iterations and branches Structured Programming OO Programming Functional Programming Etc. « Software Engineering at a Crossroads » Jean Bézivin
    • 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
    • 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
    • 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
    • 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
    • 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 important to be confiscated by software people « Software Engineering at a Crossroads » Jean Bézivin
    • 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
    • Software Engineering and Engineering Software Engineering eEngineering (Generic, includes ME) Electrical Engineering Software Engineering « Software Engineering at a Crossroads » Jean Bézivin Enterprise Engineering
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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