1. What is Wrong with Models?
Omar Badreddin
Post Doctoral Fellow, University of Ottawa

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. Open source developers rarely use modeling tools
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. Implementation is not difficult
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
Low level Languages
Procedural Languages
Object Orientation
Model Orientation
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. Teach modeling in first year CS programs
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
Legislations / Initiatives
Goal
Modeling
Regulations
Compliance
Governance
Requirement
Compliance models
Monitor
Requirements
System Development
Use Cases
Operations
Design
Code
SysML
BPMN
UML

24. Change Management Forward Engineering Reverse Engineering
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