Ask HN: What Happened to Model Driven Development
Why am I getting taught this in final year of university.
Is this paradigm still used in non-legacy areas?
Regards,
Is this paradigm still used in non-legacy areas?
Regards,
The thing is: You have to do it right to reap the rewards. Especially in larger companies it's unfortunately not uncommon to encounter all-encompassing models with hundreds (or even thousands) of entities / classes. That kind of model not only doesn't help with developing software faster and more cost-efficiently but even has an adverse effect. In order to benefit from model-driven development you have to think in terms of the various business functions (sales, HR etc.), the boundaries between those functions and models which are specific to their respective subdomain.
Just making a project in class i found it to Beverly tedious jumping between diagrams.
Much rather prefer code.
However, rapid application development isn't the main benefit of these approaches. Their main point is getting a better understanding of the business domain you're operating in.
I do like DDD, the idea that you have a project that is completely focused on solving the business issues. Then the infrastructure/technology concerns simply plugin into that model.
Gives you flexibility on changing technologies more easily, and well designed domain model can give you a serious business advantage.
Going off the MSDN article (https://msdn.microsoft.com/en-us/library/aa964145.aspx), MDD, it starts to sound vaguely like how most early-stage startups build software wrt agile. There are definitely tools to generate basic CRUD models from a data model diagram eg UML. There are also tools to generate class diagrams from code. However, they lost me somewhere in the middle of that article where everything quickly detached from reality into abstractions. Beyond those points and using TDD, personally I had a hard time seeing what this approach is exactly and what the value added is.
The Wikipedia article for model-driven software development (https://en.m.wikipedia.org/wiki/Model-driven_software_develo...) makes it sounds like you generate code then never modify it directly, only regenerating from the abstraction. That sounds cool in theory but completely unrealistic in practice.
There is a fair amount of model based design in defence and aerospace, where the systems in question can be years away from being ready and finding bugs when the systems are ready is hugely expensive. This starts to get into Systems Engineering territory (the INCOSE kind not the MCSE kind).
When one gets into Systems of Systems territory, just looking at code isn't an option, and understanding the interactions between systems at a system level can be worth the up front cost of creating the models.
Having models drive code generation (say Simulink generating FPGA code) can also allow for simulation and testing to be done on the model and then the exact same tests be done on target with very little rework.
Usually those places have a a 'full-stack' of model based systems engineers using SysML, who hand off models to the dev guys using model based development (MBD). Testing with a V-model, etc.
Defence more than automotive, but some orgs have very long project cycles (i.e. >25 years) so models provide a great benefit over simple source/docs.