Model-Driven Software Development: Technology, Engineering, Management
by Thomas Stahl, Markus Völter, Jorn Bettin, Arno Haase, Simon Helsen, Krzysztof Czarnecki, Bettina von Stockfleth
Chapter 5
Classification
We established a uniform terminology for MDSD in Chapter 4, so we can now take on the classification of related topics.
5.1 MDSD vs. CASE, 4GL and Wizards
One remarkable characteristic of Model-Driven Software Development is that the development environments used are by no means static, but that in fact any target architectures, modeling and target languages, interfaces, and runtime components can be supported.
In contrast, a classic CASE or 4GL tool will typically predetermine at least one component of a domain architecture – and in most cases, all of them:
- DSL (modeling language)
- Transformations
- Platform and target architecture
Such tools focus on a domain that is not specific: they try to adhere to the dogma of ‘one size fits all’ – one premeditated combination fits all applications. This assumption is completely unrealistic in practice and causes significant problems. Typically, 80% of an application can be created fairly quickly in this manner, whereas the remaining 20% will eventually require 80% of the total effort. This is because the tools’ inflexibilities enforce workarounds to combat them. Individual architectural requirements and interfaces cannot be applied here, let alone domain knowledge.
MDSD means an explicit abandonment of all ‘one size fits all’ approaches. Its emphasis is clearly on development methodology, not on development environment.
As a rule, all the aspects one wishes to generate will be implemented manually and verified at ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access