What is Wrong with Models?

1. What is Wrong with Models? Omar Badreddin www.OmarBadreddin.com Post Doctoral Fellow, University of Ottawaoobahy@gmail.com

2. The Future of Modeling

3. Modeling Today

4. Desktop Modeling tools • 100% of the modeling tools are primarily IDE based • Only a few support web based environment

5. Support for collaboration • Versioning and merging of models still problematic • Much easier to collaborate on code • Model based collaboration in SE remain minimal [Collaboration in Software Engineering: A Roadmap]

6. Adoption • Open source developers rarely use modeling tools • lack of pressure to have rigor or follow deadlines • In one study, only 0.3% of OSS projects incorporate models • In another study, After a year • 70% of modeling tools are no longer used • Only 5% are widely used (despite positive impact reported) • Those who actually use models, only 6% always generate code

7. Complex tools • 75% find modeling tools are unnecessarily complex • In a study, 80% of software engineers find modeling tools are bad or awful in generating code. • Only 24% find modeling tools to be lacking in features they need.

8. Research Practice mismatch • Modeling is not New, SE is. • Modeling in Architecture and Civil Engineering • Modeling is a good practice • Enhanced productivity, quality, cost reduction • Wide empirical evidence • Yet, • Majority of practitioners do not use it • Modeling only as documentation • Open source community do not use models at all

9. Problems with the tooling • Modeling tools tend to be • Awkward to use • Expensive • Low quality of generated code • Incomplete implementation of a language • Weak in analysis • Difficult to integrate with existing environments

10. Evidence against modeling • Growing evidence against modeling • Open Source projects are successful without it • Majority of professionals have chosen not to use them • Modeling works in other domains only • There are some exceptions (automotive, aviation) • And, • Current approaches work well enough • Modeling tools are expensive, hard to learn • Versioning and merging of models is still problematic • Code generation and reverse engineering still do not work good enough • Some argue, “there is no future for MDA.”

11. Problems with cutting edge modeling tools • The same model generates different code using a different modeling tool • MDA becomes tool oriented • Imagine the same for Java!! • Abstraction level mismatch • Managing change • Usability and Cost • Culture, Education

12. MDA is loosing steam • Implementation is not difficult • The challenge is to identify business problem and build the solution (model) • Building a robust solution is more important that building a solution quickly • 90% of total cost of ownership is spent on maintenance • Agile: software is developed through cycles of evolution. • MDD is a technology enabler, and does not have business value itself • Systems developed using MDD have business value

13. Programming languages success • Always executable • Incorporating abstractions • Textual format • Backward compatible • Usually written in themselves • Core in education of software engineers

14. Increasing abstraction levels Java, C++ Pascal Levels of Abstraction Assembly Alf, UAL

15. Code more abstract than models • System Orientation New BankingSystem(DB2, medium, webAccess); enable_webAccess(IE, Chrome); • Drill down to models (i.e business logic) • Behavioural models (i.e state machines) • Business Rules • SE is an applied discipline by nature • Paradigm shift originates from industry

16. Modeling is not the goal in itself • Efficient development of software • Enhanced comprehensibility • Business Value • Agility • Reuse • ..

17. Properties of the future modeling tool • Flexible, simple, and powerful • Agile • In the Cloud • Real time collaboration support • Seamless Versioning and Merging • Popular adoption • Free? • Portable (phone, tablet, phablet, ..)

18. Properties of the future Modeling tool • Model debugging, tracing. • More interactive (Context assist, warnings, model-assist) • Unified and Universal • Interoperability • Portability • Cohesion • Business Oriented/Driven Modeling • 3D modeling • Less emphasis on tooling

19. Properties of MDA teams • Iterations result in executable models • From Flexible to precise models • Quick generation of system prototypes from Models • Blur lines between model / code / documentations • Little, no set up for model based contributions • Model reuse, Model libraries • Drill down to code • Future OO developers are today’s COBOL programmers

20. Context and Culture • Teach modeling in first year CS programs • A model is assumed to be executable or incomplete • Problem with the code? Fix the compiler. • Get your hands dirty with the low level models • Source code -> Source Model • Password -> Passmodel • Line number -> Region number • Codex -> Modex

23. Problem 2: Lack of a Truly Universal Language Code Goal Modeling • Monitor • Compliance • Legislations / Initiatives • Operations • Regulations • Requirements • Design Governance Requirement Compliance models System Development Use Cases SysML BPMN UML

24. Change Management • Regulations changes impact, requirements, design, operations, and compliance. • Forward Engineering • Reverse Engineering • Design system from compliance requirements • System design • Model tracing

27. In SE, we still can not agree on what a model is • Is a model • An incomplete view of the system • A diagram (Not code) • The system itself • Any representation, including code. • You should be able to • Analyse key aspects (Performance, correctness, etc) • Generate code • Executable, eventually executable, should never execute