1 / 27

What is Wrong with Models?

What is Wrong with Models?. Omar Badreddin www.OmarBadreddin.com Post Doctoral Fellow, University of Ottawa oobahy@gmail.com. The Future of Modeling. Modeling Today. Desktop Modeling tools. 100% of the modeling tools are primarily IDE based Only a few support web based environment.

amara
Télécharger la présentation

What is Wrong with Models?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

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

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

More Related