Diese Präsentation wurde erfolgreich gemeldet.

Bern.jb

3

Teilen

Nächste SlideShare
DNM Portfolio
DNM Portfolio
Wird geladen in …3
×
1 von 77
1 von 77

Bern.jb

3

Teilen

Herunterladen, um offline zu lesen

  1. 1. Should we Resurrect Software Engineering? Jean Bézivin JBezivin@gmail.com CHOOSE Forum 2012, Bern 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 1
  2. 2. Requiem for Software Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 2
  3. 3. You escaped these titles Software Engineering is Dead; Long Live Software Engineering The basis of Software Engineering 2.0 From Software Engineering to Engineering Software Towards a Unified Theory of Engineering Is Generic Engineering Feasible? How to Bridge Problem Spaces and Solution Spaces? Some remarks about eEngineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 3
  4. 4. Agenda 1. Introduction 2. Software Engineering is Dead 3. Model Driven Engineering Missed the Boat 4. Problem and Solution Spaces 5. Domain Engineering 6. Support Engineering 7. Conclusion 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 4
  5. 5. Sorry for the bad news SOFTWARE ENGINEERING IS DEAD 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 5
  6. 6. … or at least critically ill The NATO Conferences of 1968 and  Last time we heard good news 1969 were motivated by the belief was in the 80’s with the that software development should be invention of the Smalltalk "based on the types of theoretical Browser foundations and practical disciplines  Every year since then, we have that are traditional in the established been eagerly waiting for better branches of engineering.“ health news at OOPSLA, ECOOP, ICSE, etc. Surprisingly the conferences did not discuss what these foundations and  But unfortunately we had only disciplines were, or how they could patterns, aspects, Java, and false be emulated. There has been little hopes that did not last very long discussion of this topic in the  Adding superficial deltas to the intervening forty years and more. J-language is boring Some important lessons have been  And now many people have neglected. given up, to concentrate only on the problem of organization of agile teams From Michael Jackson’s Web site 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 6
  7. 7. Hype after Hype  Are we condemned to jump from hype to hype like a fashion industry?(1)  What is the hidden meaning in the long term evolution of our discipline? Google Ngram Viewer (Raw Ngram buzzword observations) (1) Ivar Jacobson 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 7
  8. 8. Software Engineering as a Succession of Hypes  Many developers’ career paths follow a continuous zigzag from hype to hype, from objects to models, from models to services, ...  We need to focus more on long term continuity and progresses than on small ruptures and failures.  Progress in SE? What is the deep meaning, if any, behind this succession of hypes? 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 8
  9. 9. OOPSLA: An Object Odyssey [OOPSLA] became the forum for some of the most important software developments over the last couple of decades. OOPSLA was the incubator for CRC cards, CLOS, Design Patterns, Self, Agile Methodologies, Service- Oriented Architectures, Wikis, Unified Modeling Language (UML), Test Driven Design (TDD), Refactoring, Java, Dynamic Compilation, and Aspect-Oriented Programming, to name just some of them. Probably the Palo Alto Research Center produced more results in ten years between 1970 and 1980 that the OOPSLA community in 25 years between 1986 and 2012. Design Patterns: Kent Beck and Ward Cunningham 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 9
  10. 10. Not a competition  We are suffering from the « My solution is better than yours » syndrome.  Where is the big picture in this hype-after-hype sequence? Will some technology finally prevail?  Let us focus more on technology cooperation than on technology competition. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 10
  11. 11. 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 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 11
  12. 12. Model Driven Engineering MDE MISSED THE BOAT 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 12
  13. 13. Models Have Failed  “Models” have failed, at least temporarily.  Deployment of MDE seems today to have reached a standstill.  Immense hopes greeted the MDA™ initial proposal as a possible way to regenerate the entire software engineering practices  Recognition today that its impact is rather limited and its perspectives quite confined.  Observation that the process is not at the same level that in case of technology take-off like OT in the 80’s  Unfortunately this last silver bullet fired blank  What went wrong?  No sustainability  lack of model portability in time and space  No killer app  Decreasing confidence in UML  Many other factors 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 13
  14. 14. Separating the platform independent and dependent parts of a system (PIM/PSM) We don't want anymore to pay such a high price for simply moving our information system to a new middleware platform (COM, CORBA, Java, HTML, XML, DotNet, etc.) when our business system stays stable. We are prepared to pay a last price for building the abstract models of our business and services that will guarantee us against technological obsolescence. From there, any platform provider will also have to provide the mapping solutions from standard business models before we buy. November 2000 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 14
  15. 15. Write Once, Run Anywhere Model Once, Generate Anywhere From Platform Independent Multi-target Models to Platform Specific code generation Models PIM PIM to PSM etc. Service architecture, CORBA SMIL/Flash Cloud computing, … Java/EJB C#/DotNet Web/XML/SOAP + SVG, GML, Delphi, ASP, MySQL, PHP, etc. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 15 - 15 -
  16. 16. Sustainable Software?  Sustainability is the new hype, but is this hype sustainable?  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 (PIM) as the underlying infrastructure shifts over time”.  This was based on the “hidden condition” that the PIM was written in UML, a language supposed itself to be stable over long periods of time. PERMANENT LINK TO THIS COMIC: HTTP://XKCD.COM/1007/ IMAGE URL (FOR HOTLINKING/EMBEDDING): HTTP://IMGS.XKCD.COM/COMICS/SUSTAINABLE.PNG 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 16
  17. 17. Nice Gems … but is this core MDE? 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 17
  18. 18. Some MDA success stories but no killer app. yet http://www.omg.org/mda/products_success.htm 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 18
  19. 19. What is a Killer App? Tom Love experiment at Schlumberger (see also the Analyst At Xerox) 220 lines of Smalltalk vs. 10,000 lines of Fortran A killer app. should provide measurable and reproducible evidence that the new proposal offers an order of magnitude improvement over previous solutions. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 19
  20. 20. UML and MDE: friend or foe, devil or angel?  UML was the conclusion of the OOADTF and the beginning of MDA  Everything started with UML and this is probably the main problem of MDE  UML is a loosely defined language  UML is a language with one syntax and an infinity of semantics (Very popular BYOS)  UML is not a badly designed language  Because it was never designed at all  It is the result of industrial consensus, obtained through a precise process (committee invention)  Bad modularity principles (profiles)  UML as a visual syntax for C++  UML as a better « programming » language? 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 20
  21. 21. UML as the modeling language archetype?  UML considered as the archetype of modeling languages, often illustrates properties that are at the extreme opposite of the main MDE basic principles.  UML as the typical visual language.  Many still wrongly associate MDE with visual modeling.  MDE has later shown that textual modeling (like in Xtext) is often better than visual modeling.  UML as a general purpose language (GPL).  MDE has demonstrated the interest of precise and focused Domain Specific Languages (DSLs).  UML as an OO modeling language  MDE has demonstrated the benefits of multiparadigm modeling, considering not only objects, but rules, events, functions, tables, processes, etc.  UML has wrongly conveyed the idea that modeling was only OO modeling  UML is known for its complexity, by the size of its metamodel and its rapid evolution  MDE promotes the idea of simple languages that could be combined, with controlled execution 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 21
  22. 22. Confusing Executability and Precision  One important ambiguity has been to let the idea propagate that all MDE-models, (including UML), could be made executable.  MDE promotes the idea that some models may be executable but not all  A perverse corollary of this is that non executable models are not precise  Many models may be executable and however very precise  Precision is not always obtained through computer executability 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 22
  23. 23. XMI Failure  From SMIF to XMI, a good start.  XMI as the final interoperability solution, the first mistake  The proportion of native data expressed in XMI is completely marginal and will not increase.  Through its various versions, XMI added mess to mess.  XMI with UML is part of MDE legacy.  XMI will eventually disappear, creating an additional problem of maintenance for UML models. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 23
  24. 24. Lack of Theory Squares and Circles The «real» World The World of «Models» a system S a model M 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 24
  25. 25. Representation and Conformance The two orthogonal Metamodel dimensions of MDE wrt conformsTo System Model representationOf 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 25
  26. 26. Taking the representation relation seriously "What about the [relationship between model and real-world]? The answer, and one of the main points I hope you will take away from this discussion, is that, at this point in intellectual relationship". [Brian Cantwell Smith] history, we have no theory of this [...] Where are models coming from? 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 26
  27. 27. Action on a model is not action on the system (real world) repOf a system S a model M A situation or a phenomenon of the real or imagined world. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 27
  28. 28. But we Learned a Lot with MDE  Any model M represents a system S  A transformation is a model 1. Representation principle 6. HOT principle  A system S may be represented by  Abstract correspondences between 2. Multiple view principle 7. Weaving principle several models models are represented as models  Any model M conforms to the  Model elements may be considered 3. Conformance principle 8. Megamodel principle language of its metamodel MM as models  Any metamodel MM conforms to a  All models specialize a common 4. 3-level principle 9. Unification principle common metametamodel MMM abstract model  The most important operation  Any model has a given 5. Transformation principle 10. Technical Space Framework applicable to models is a representation defined by its transformation technical space 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 28
  29. 29. What is a modeling language?  The expression “modeling  Examples language” is recent  Flowcharts (~1950)  Examples: Requirements  Petri Nets (~1960-1970) Abstract Specifications  PSL/PSA (~1967) Formal Methods  State Diagrams (~1967) •  SADT (~1969) Semi-Formal Notations • Early aspects (?) • etc.  DFD (~1975) •  The expression “modeling  Entity-Association • language” is recent (Chen, ~1976) •  Tentative definition: A modeling language is a language  JSD (~1982) contributing to software  AD/Cycle (~1982) production, maintenance or operation that is not directly  UML (~1996) executable.  MDA (~2000) 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 29
  30. 30. What are the relations between Programming & Modeling Languages? 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 30
  31. 31. The two parallel tracks Programming Lisp Algol60 Smalltalk Fortran COBOL PL/1 Java Ruby Javascript Scala Dart Languages ADA C++ Python Assembler Prolog Pascal C# F# Go No global consolidated history of Modeling Languages ExecutableUML? Flowcharts Petri JSD Z B UML Modeling SREM SADT SBVR SART DFD VDM OMT SysML Languages Sara PSL/PSA 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 31
  32. 32. Evolving scope Not only for code generation [If MDE is the Solution, then what was the Problem?] MDD MDE MDE MDD MDD = Model Driven (Software) Development MDE = Model Driven Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 32
  33. 33. MDE is not only for code generation  Restricted focus  MDE concentrated too much Initially MDA was for just software engineering, on models of code and not and the scope was progressively extended enough on models of data  MDE concentrated too much on models of solutions and Model not enough on models of Driven problems Engineering  MDE concentrated too much on Information Systems models and not enough on appliesTo Business models  MDE concentrated too much on modeling in the small and not enough on modeling in the large Software Data System Business  etc. Engineering Engineering Engineering Engineering UML/SPEM CWM SysML BPMN 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 33
  34. 34. The engineer view of « how to solve it? » PROBLEM AND SOLUTION SPACES 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 34
  35. 35. Technical Spaces Technical Space: A representation system for models and a set of technical solutions to handle them. A framework usually based on some algebraic structures (relational tuples, trees, graphs, hypergraphs, etc.) aTechnicalSpace System: A group of interacting, MetaMetaModel interrelated, or interdependent elements forming a complex whole. aSystem aModel repOf Model: An abstract representation of a system created for a specific purpose. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 35
  36. 36. Structuring the solution space Problem How to Solve it? Problem Space Java XML Ontologies etc. MDA™ DBMS Solution Space Grammars XML Schema Metamodel Programs XML Documents Model All models are not MOF or ECORE Models. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 36
  37. 37. Three representations for the same program Java Java JavaML Grammar Metamodel schema Java Java JavaML Program Model Document Program TS MDA TS XML TS 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 37
  38. 38. Projections between EBNF, MDE and XML XML TS MDE TS EBNF TS M3 XSD.xsd MOF EBNF.g M2 JavaML.xsd Java Java.g M1 Test.xml Test.xmi Test.java 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 38
  39. 39. Ubiquitous Software: From Problems to Solutions Domain Problem Spaces Engineering Mappings Solution Spaces Support Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 39
  40. 40. Focus on Engineering Scientists study the world as it is; engineers Theodore von Kármán create the world that has never been. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 40
  41. 41. The two spaces Domain Engineering Problems lie here Support Engineering Tools to solve problems may be found here 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 41
  42. 42. 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  Legal engineering Domain Engineering (horizontal?)   Civil engineering  Building engineering  Electrical engineering  Mechanical engineering  Business engineering  Biological engineering  Automotive engineering  Health engineering   07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 42
  43. 43. Problem Spaces DOMAIN ENGINEERING 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 43
  44. 44. 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.  07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 44
  45. 45. Electrical Engineering Augmenting, Building Validation Putting in Changing the abstract models Verification Production world 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 45
  46. 46. Construction Engineering Augmenting, Building Validation Putting in Changing the abstract models Verification Production world 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 46
  47. 47. Old and new engineering fields 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 47
  48. 48. Many Communities, Many Journals 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 http://www.govengr.com/ … Concurrent engineering is Neural a work methodology based engineering (also on the parallelization of tasks known as Neuroengineering) is a (i.e. performing tasks discipline concurrently). It refers to an within biomedical approach used in product engineering that uses development in which engineering techniques functions of design to understand, repair, engineering, manufacturing replace, enhance, or engineering and other otherwise exploit the functions are integrated to properties of neural reduce the elapsed time systems Journal of Neural Engineering to help scientists, clinicians and engineers required to bring a new to understand, replace, repair and enhance the nervous system. product to the market. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 48
  49. 49. And many more 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 49
  50. 50. Synergies Between Engineering Fields Program Engineering Building Engineering Once in a great while, a great idea makes it across the boundary of one discipline to take root in another. The “The Origins of Pattern Theory, adoption of Christopher Alexander’s patterns by the the Future of the Theory, And The software community is one such event. Generation of a Living World” Christopher Alexander . Jim Coplien 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 50
  51. 51. Domain Engineering Domain Problem spaces Engineering Product Process Engineering Engineering Solution spaces (Support Engineering) 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 51
  52. 52. Many features common to all domain engineering fields  Based on support engineering  Product & Process focus  Including HR and team management  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 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 52
  53. 53. Solution Spaces SUPPORT ENGINEERING 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 53
  54. 54. Variety Complexity of the Support Engineering Landscape Language Program Ontology Model Engineering Engineering Engineering Engineering Web Service Transformation Rule Engineering Engineering Engineering Engineering Complex Event Data Process Product Engineering Engineering Engineering Engineering HR Team Software Other Engineering Engineering Engineering Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 54
  55. 55. Specialized engineering fields Language Engineering Software Language Engineering Grammar Model Ontology Engineering Engineering Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 55
  56. 56. Composite engineering fields 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 56
  57. 57. Model Engineering Same visual notation, different context, different meaning Model element (Thick red dotted lines for bicycle lanes) Metamodel element µ Metamodel c2 The legend Model is the metamodel 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 57
  58. 58. Process engineering encompasses a vast range Process Engineering  Process engineering of industries, such as chemical, petrochemical, mineral processing, advanced material, food, Software Process Engineering pharmaceutical, biotechnological, and software industries.  See also Concurrent SPEM Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 58
  59. 59. PSL (Process Specification Language) Process Specification Language NIST Process +name 1 0..* Activity +preceding -name -duration 0..* 0..* +following 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 59
  60. 60. Early SPEM (UPM) 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 60
  61. 61. Team and Product management Team Management Product Lifecyle Engineering Management (PLM) Software Team Product Line Management Engineering Engineering Software Product Agile Methods Line Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 61
  62. 62. Data Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 62
  63. 63. 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. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 63
  64. 64. What is a program? A Programming The World Language (domain) c2 The Application Requirements A Program class Application{ (use cases) public static void main (String[] args) { System.out.writeln("Hello, world") class BankCustomer{ } } } class Printer{ } The Machine class Application{ (platform) } 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 64
  65. 65. Making implicit relations explicit  Language engineering is related to the definition and handling of Language languages  Program engineering Engineering deals with the use of ? Program executable software Engineering languages to produce operational programs ? that will participate in human activities (includes deployment). 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 65
  66. 66. Models for producing programs Domain (World) Problem (Application) Program Today Knowledge in the head of programmer Platform (Machine) Models Other aspects Tomorrow From implicit to explicit Transformation based Code generation with models 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 66
  67. 67. But also models for understanding programs View1 Program View2 Today Models View3 Tomorrow Code understanding with models 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 67
  68. 68. 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 Model Engineering ? Program Programming Modeling is Engineering ? 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 68
  69. 69. Many Possible Useful Collaborations Between Support Eng. Service Data Process Product Engineering Engineering Engineering Engineering Model Model Engineering Engineering Program Language Transformation Data Engineering Engineering Engineering Engineering Model Model Engineering Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 69
  70. 70. Combining Support Engineering Model Engineering ? Service Engineering ? 1,400,000 results N defs of MDA M defs of SOA P ways to combine them 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 70
  71. 71. Understanding complex relations Business Engineering BPMN ? Software Engineering ? UML Model Language Data Service Engineering Engineering Engineering Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 71
  72. 72. Software Engineering is Engineering CONCLUSIONS 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 72
  73. 73. Let’s forget about “Computer Science” Program Language Engineering Engineering Computer Engineering ? Informatics Data Engineering Platform Software Engineering Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 73
  74. 74. Conclusions After nearly 50 years Software engineering is dead MDE missed the boat No other major silver bullet on the horizon Good time to invent a new future SE as a branch of generic eEngineering (eE) eE using most of the ideas of MDE eE taking inspiration of the brightest ideas in other domain or support engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 74
  75. 75. Software Engineering and Engineering Software Engineering eEngineering Electrical Software Engineering Civil Engineering Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 75
  76. 76. Unified Theories of Engineering  Yes we need to resurrect Software Engineering.  The expression “Software Engineering” was coined in 1968.  In 2018, for the 50th anniversary, 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.  Short term proposal: a generic platform for eEngineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 76
  77. 77. Thanks • Questions? • Comments? JBezivin@gmail.com 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 77
  1. 1. Should we Resurrect Software Engineering? Jean Bézivin JBezivin@gmail.com CHOOSE Forum 2012, Bern 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 1
  2. 2. Requiem for Software Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 2
  3. 3. You escaped these titles Software Engineering is Dead; Long Live Software Engineering The basis of Software Engineering 2.0 From Software Engineering to Engineering Software Towards a Unified Theory of Engineering Is Generic Engineering Feasible? How to Bridge Problem Spaces and Solution Spaces? Some remarks about eEngineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 3
  4. 4. Agenda 1. Introduction 2. Software Engineering is Dead 3. Model Driven Engineering Missed the Boat 4. Problem and Solution Spaces 5. Domain Engineering 6. Support Engineering 7. Conclusion 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 4
  5. 5. Sorry for the bad news SOFTWARE ENGINEERING IS DEAD 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 5
  6. 6. … or at least critically ill The NATO Conferences of 1968 and  Last time we heard good news 1969 were motivated by the belief was in the 80’s with the that software development should be invention of the Smalltalk "based on the types of theoretical Browser foundations and practical disciplines  Every year since then, we have that are traditional in the established been eagerly waiting for better branches of engineering.“ health news at OOPSLA, ECOOP, ICSE, etc. Surprisingly the conferences did not discuss what these foundations and  But unfortunately we had only disciplines were, or how they could patterns, aspects, Java, and false be emulated. There has been little hopes that did not last very long discussion of this topic in the  Adding superficial deltas to the intervening forty years and more. J-language is boring Some important lessons have been  And now many people have neglected. given up, to concentrate only on the problem of organization of agile teams From Michael Jackson’s Web site 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 6
  7. 7. Hype after Hype  Are we condemned to jump from hype to hype like a fashion industry?(1)  What is the hidden meaning in the long term evolution of our discipline? Google Ngram Viewer (Raw Ngram buzzword observations) (1) Ivar Jacobson 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 7
  8. 8. Software Engineering as a Succession of Hypes  Many developers’ career paths follow a continuous zigzag from hype to hype, from objects to models, from models to services, ...  We need to focus more on long term continuity and progresses than on small ruptures and failures.  Progress in SE? What is the deep meaning, if any, behind this succession of hypes? 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 8
  9. 9. OOPSLA: An Object Odyssey [OOPSLA] became the forum for some of the most important software developments over the last couple of decades. OOPSLA was the incubator for CRC cards, CLOS, Design Patterns, Self, Agile Methodologies, Service- Oriented Architectures, Wikis, Unified Modeling Language (UML), Test Driven Design (TDD), Refactoring, Java, Dynamic Compilation, and Aspect-Oriented Programming, to name just some of them. Probably the Palo Alto Research Center produced more results in ten years between 1970 and 1980 that the OOPSLA community in 25 years between 1986 and 2012. Design Patterns: Kent Beck and Ward Cunningham 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 9
  10. 10. Not a competition  We are suffering from the « My solution is better than yours » syndrome.  Where is the big picture in this hype-after-hype sequence? Will some technology finally prevail?  Let us focus more on technology cooperation than on technology competition. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 10
  11. 11. 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 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 11
  12. 12. Model Driven Engineering MDE MISSED THE BOAT 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 12
  13. 13. Models Have Failed  “Models” have failed, at least temporarily.  Deployment of MDE seems today to have reached a standstill.  Immense hopes greeted the MDA™ initial proposal as a possible way to regenerate the entire software engineering practices  Recognition today that its impact is rather limited and its perspectives quite confined.  Observation that the process is not at the same level that in case of technology take-off like OT in the 80’s  Unfortunately this last silver bullet fired blank  What went wrong?  No sustainability  lack of model portability in time and space  No killer app  Decreasing confidence in UML  Many other factors 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 13
  14. 14. Separating the platform independent and dependent parts of a system (PIM/PSM) We don't want anymore to pay such a high price for simply moving our information system to a new middleware platform (COM, CORBA, Java, HTML, XML, DotNet, etc.) when our business system stays stable. We are prepared to pay a last price for building the abstract models of our business and services that will guarantee us against technological obsolescence. From there, any platform provider will also have to provide the mapping solutions from standard business models before we buy. November 2000 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 14
  15. 15. Write Once, Run Anywhere Model Once, Generate Anywhere From Platform Independent Multi-target Models to Platform Specific code generation Models PIM PIM to PSM etc. Service architecture, CORBA SMIL/Flash Cloud computing, … Java/EJB C#/DotNet Web/XML/SOAP + SVG, GML, Delphi, ASP, MySQL, PHP, etc. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 15 - 15 -
  16. 16. Sustainable Software?  Sustainability is the new hype, but is this hype sustainable?  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 (PIM) as the underlying infrastructure shifts over time”.  This was based on the “hidden condition” that the PIM was written in UML, a language supposed itself to be stable over long periods of time. PERMANENT LINK TO THIS COMIC: HTTP://XKCD.COM/1007/ IMAGE URL (FOR HOTLINKING/EMBEDDING): HTTP://IMGS.XKCD.COM/COMICS/SUSTAINABLE.PNG 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 16
  17. 17. Nice Gems … but is this core MDE? 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 17
  18. 18. Some MDA success stories but no killer app. yet http://www.omg.org/mda/products_success.htm 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 18
  19. 19. What is a Killer App? Tom Love experiment at Schlumberger (see also the Analyst At Xerox) 220 lines of Smalltalk vs. 10,000 lines of Fortran A killer app. should provide measurable and reproducible evidence that the new proposal offers an order of magnitude improvement over previous solutions. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 19
  20. 20. UML and MDE: friend or foe, devil or angel?  UML was the conclusion of the OOADTF and the beginning of MDA  Everything started with UML and this is probably the main problem of MDE  UML is a loosely defined language  UML is a language with one syntax and an infinity of semantics (Very popular BYOS)  UML is not a badly designed language  Because it was never designed at all  It is the result of industrial consensus, obtained through a precise process (committee invention)  Bad modularity principles (profiles)  UML as a visual syntax for C++  UML as a better « programming » language? 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 20
  21. 21. UML as the modeling language archetype?  UML considered as the archetype of modeling languages, often illustrates properties that are at the extreme opposite of the main MDE basic principles.  UML as the typical visual language.  Many still wrongly associate MDE with visual modeling.  MDE has later shown that textual modeling (like in Xtext) is often better than visual modeling.  UML as a general purpose language (GPL).  MDE has demonstrated the interest of precise and focused Domain Specific Languages (DSLs).  UML as an OO modeling language  MDE has demonstrated the benefits of multiparadigm modeling, considering not only objects, but rules, events, functions, tables, processes, etc.  UML has wrongly conveyed the idea that modeling was only OO modeling  UML is known for its complexity, by the size of its metamodel and its rapid evolution  MDE promotes the idea of simple languages that could be combined, with controlled execution 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 21
  22. 22. Confusing Executability and Precision  One important ambiguity has been to let the idea propagate that all MDE-models, (including UML), could be made executable.  MDE promotes the idea that some models may be executable but not all  A perverse corollary of this is that non executable models are not precise  Many models may be executable and however very precise  Precision is not always obtained through computer executability 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 22
  23. 23. XMI Failure  From SMIF to XMI, a good start.  XMI as the final interoperability solution, the first mistake  The proportion of native data expressed in XMI is completely marginal and will not increase.  Through its various versions, XMI added mess to mess.  XMI with UML is part of MDE legacy.  XMI will eventually disappear, creating an additional problem of maintenance for UML models. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 23
  24. 24. Lack of Theory Squares and Circles The «real» World The World of «Models» a system S a model M 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 24
  25. 25. Representation and Conformance The two orthogonal Metamodel dimensions of MDE wrt conformsTo System Model representationOf 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 25
  26. 26. Taking the representation relation seriously "What about the [relationship between model and real-world]? The answer, and one of the main points I hope you will take away from this discussion, is that, at this point in intellectual relationship". [Brian Cantwell Smith] history, we have no theory of this [...] Where are models coming from? 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 26
  27. 27. Action on a model is not action on the system (real world) repOf a system S a model M A situation or a phenomenon of the real or imagined world. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 27
  28. 28. But we Learned a Lot with MDE  Any model M represents a system S  A transformation is a model 1. Representation principle 6. HOT principle  A system S may be represented by  Abstract correspondences between 2. Multiple view principle 7. Weaving principle several models models are represented as models  Any model M conforms to the  Model elements may be considered 3. Conformance principle 8. Megamodel principle language of its metamodel MM as models  Any metamodel MM conforms to a  All models specialize a common 4. 3-level principle 9. Unification principle common metametamodel MMM abstract model  The most important operation  Any model has a given 5. Transformation principle 10. Technical Space Framework applicable to models is a representation defined by its transformation technical space 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 28
  29. 29. What is a modeling language?  The expression “modeling  Examples language” is recent  Flowcharts (~1950)  Examples: Requirements  Petri Nets (~1960-1970) Abstract Specifications  PSL/PSA (~1967) Formal Methods  State Diagrams (~1967) •  SADT (~1969) Semi-Formal Notations • Early aspects (?) • etc.  DFD (~1975) •  The expression “modeling  Entity-Association • language” is recent (Chen, ~1976) •  Tentative definition: A modeling language is a language  JSD (~1982) contributing to software  AD/Cycle (~1982) production, maintenance or operation that is not directly  UML (~1996) executable.  MDA (~2000) 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 29
  30. 30. What are the relations between Programming & Modeling Languages? 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 30
  31. 31. The two parallel tracks Programming Lisp Algol60 Smalltalk Fortran COBOL PL/1 Java Ruby Javascript Scala Dart Languages ADA C++ Python Assembler Prolog Pascal C# F# Go No global consolidated history of Modeling Languages ExecutableUML? Flowcharts Petri JSD Z B UML Modeling SREM SADT SBVR SART DFD VDM OMT SysML Languages Sara PSL/PSA 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 31
  32. 32. Evolving scope Not only for code generation [If MDE is the Solution, then what was the Problem?] MDD MDE MDE MDD MDD = Model Driven (Software) Development MDE = Model Driven Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 32
  33. 33. MDE is not only for code generation  Restricted focus  MDE concentrated too much Initially MDA was for just software engineering, on models of code and not and the scope was progressively extended enough on models of data  MDE concentrated too much on models of solutions and Model not enough on models of Driven problems Engineering  MDE concentrated too much on Information Systems models and not enough on appliesTo Business models  MDE concentrated too much on modeling in the small and not enough on modeling in the large Software Data System Business  etc. Engineering Engineering Engineering Engineering UML/SPEM CWM SysML BPMN 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 33
  34. 34. The engineer view of « how to solve it? » PROBLEM AND SOLUTION SPACES 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 34
  35. 35. Technical Spaces Technical Space: A representation system for models and a set of technical solutions to handle them. A framework usually based on some algebraic structures (relational tuples, trees, graphs, hypergraphs, etc.) aTechnicalSpace System: A group of interacting, MetaMetaModel interrelated, or interdependent elements forming a complex whole. aSystem aModel repOf Model: An abstract representation of a system created for a specific purpose. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 35
  36. 36. Structuring the solution space Problem How to Solve it? Problem Space Java XML Ontologies etc. MDA™ DBMS Solution Space Grammars XML Schema Metamodel Programs XML Documents Model All models are not MOF or ECORE Models. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 36
  37. 37. Three representations for the same program Java Java JavaML Grammar Metamodel schema Java Java JavaML Program Model Document Program TS MDA TS XML TS 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 37
  38. 38. Projections between EBNF, MDE and XML XML TS MDE TS EBNF TS M3 XSD.xsd MOF EBNF.g M2 JavaML.xsd Java Java.g M1 Test.xml Test.xmi Test.java 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 38
  39. 39. Ubiquitous Software: From Problems to Solutions Domain Problem Spaces Engineering Mappings Solution Spaces Support Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 39
  40. 40. Focus on Engineering Scientists study the world as it is; engineers Theodore von Kármán create the world that has never been. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 40
  41. 41. The two spaces Domain Engineering Problems lie here Support Engineering Tools to solve problems may be found here 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 41
  42. 42. 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  Legal engineering Domain Engineering (horizontal?)   Civil engineering  Building engineering  Electrical engineering  Mechanical engineering  Business engineering  Biological engineering  Automotive engineering  Health engineering   07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 42
  43. 43. Problem Spaces DOMAIN ENGINEERING 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 43
  44. 44. 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.  07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 44
  45. 45. Electrical Engineering Augmenting, Building Validation Putting in Changing the abstract models Verification Production world 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 45
  46. 46. Construction Engineering Augmenting, Building Validation Putting in Changing the abstract models Verification Production world 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 46
  47. 47. Old and new engineering fields 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 47
  48. 48. Many Communities, Many Journals 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 http://www.govengr.com/ … Concurrent engineering is Neural a work methodology based engineering (also on the parallelization of tasks known as Neuroengineering) is a (i.e. performing tasks discipline concurrently). It refers to an within biomedical approach used in product engineering that uses development in which engineering techniques functions of design to understand, repair, engineering, manufacturing replace, enhance, or engineering and other otherwise exploit the functions are integrated to properties of neural reduce the elapsed time systems Journal of Neural Engineering to help scientists, clinicians and engineers required to bring a new to understand, replace, repair and enhance the nervous system. product to the market. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 48
  49. 49. And many more 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 49
  50. 50. Synergies Between Engineering Fields Program Engineering Building Engineering Once in a great while, a great idea makes it across the boundary of one discipline to take root in another. The “The Origins of Pattern Theory, adoption of Christopher Alexander’s patterns by the the Future of the Theory, And The software community is one such event. Generation of a Living World” Christopher Alexander . Jim Coplien 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 50
  51. 51. Domain Engineering Domain Problem spaces Engineering Product Process Engineering Engineering Solution spaces (Support Engineering) 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 51
  52. 52. Many features common to all domain engineering fields  Based on support engineering  Product & Process focus  Including HR and team management  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 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 52
  53. 53. Solution Spaces SUPPORT ENGINEERING 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 53
  54. 54. Variety Complexity of the Support Engineering Landscape Language Program Ontology Model Engineering Engineering Engineering Engineering Web Service Transformation Rule Engineering Engineering Engineering Engineering Complex Event Data Process Product Engineering Engineering Engineering Engineering HR Team Software Other Engineering Engineering Engineering Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 54
  55. 55. Specialized engineering fields Language Engineering Software Language Engineering Grammar Model Ontology Engineering Engineering Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 55
  56. 56. Composite engineering fields 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 56
  57. 57. Model Engineering Same visual notation, different context, different meaning Model element (Thick red dotted lines for bicycle lanes) Metamodel element µ Metamodel c2 The legend Model is the metamodel 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 57
  58. 58. Process engineering encompasses a vast range Process Engineering  Process engineering of industries, such as chemical, petrochemical, mineral processing, advanced material, food, Software Process Engineering pharmaceutical, biotechnological, and software industries.  See also Concurrent SPEM Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 58
  59. 59. PSL (Process Specification Language) Process Specification Language NIST Process +name 1 0..* Activity +preceding -name -duration 0..* 0..* +following 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 59
  60. 60. Early SPEM (UPM) 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 60
  61. 61. Team and Product management Team Management Product Lifecyle Engineering Management (PLM) Software Team Product Line Management Engineering Engineering Software Product Agile Methods Line Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 61
  62. 62. Data Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 62
  63. 63. 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. 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 63
  64. 64. What is a program? A Programming The World Language (domain) c2 The Application Requirements A Program class Application{ (use cases) public static void main (String[] args) { System.out.writeln("Hello, world") class BankCustomer{ } } } class Printer{ } The Machine class Application{ (platform) } 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 64
  65. 65. Making implicit relations explicit  Language engineering is related to the definition and handling of Language languages  Program engineering Engineering deals with the use of ? Program executable software Engineering languages to produce operational programs ? that will participate in human activities (includes deployment). 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 65
  66. 66. Models for producing programs Domain (World) Problem (Application) Program Today Knowledge in the head of programmer Platform (Machine) Models Other aspects Tomorrow From implicit to explicit Transformation based Code generation with models 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 66
  67. 67. But also models for understanding programs View1 Program View2 Today Models View3 Tomorrow Code understanding with models 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 67
  68. 68. 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 Model Engineering ? Program Programming Modeling is Engineering ? 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 68
  69. 69. Many Possible Useful Collaborations Between Support Eng. Service Data Process Product Engineering Engineering Engineering Engineering Model Model Engineering Engineering Program Language Transformation Data Engineering Engineering Engineering Engineering Model Model Engineering Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 69
  70. 70. Combining Support Engineering Model Engineering ? Service Engineering ? 1,400,000 results N defs of MDA M defs of SOA P ways to combine them 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 70
  71. 71. Understanding complex relations Business Engineering BPMN ? Software Engineering ? UML Model Language Data Service Engineering Engineering Engineering Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 71
  72. 72. Software Engineering is Engineering CONCLUSIONS 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 72
  73. 73. Let’s forget about “Computer Science” Program Language Engineering Engineering Computer Engineering ? Informatics Data Engineering Platform Software Engineering Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 73
  74. 74. Conclusions After nearly 50 years Software engineering is dead MDE missed the boat No other major silver bullet on the horizon Good time to invent a new future SE as a branch of generic eEngineering (eE) eE using most of the ideas of MDE eE taking inspiration of the brightest ideas in other domain or support engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 74
  75. 75. Software Engineering and Engineering Software Engineering eEngineering Electrical Software Engineering Civil Engineering Engineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 75
  76. 76. Unified Theories of Engineering  Yes we need to resurrect Software Engineering.  The expression “Software Engineering” was coined in 1968.  In 2018, for the 50th anniversary, 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.  Short term proposal: a generic platform for eEngineering 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 76
  77. 77. Thanks • Questions? • Comments? JBezivin@gmail.com 07/01/2013 CHOOSE Forum 2012, 14 December 2012, Bern 77

Weitere Verwandte Inhalte

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

×