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

Get Model-Driven Software Development: Technology, Engineering, Management now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.