MDA, MDE, MDSD, CASE,… Oder doch lieber klassisch?

Möchte man bei der Entwicklung etwas neues probieren, so stößt man häufig auf die Idee der Modellgetriebenen Entwicklung. Doch bereits nach kurzer Recherche erweckt es den Anschein, dass es eine schier unendliche Anzahl von Ideen und Systemen gibt. Doch wie so häufig verbirgt sich hinter einer Vielzahl von Bezeichnungen ein und dasselbe System. Ich möchte hier einmal einen kurzen Überblick bieten, wie das Chaos der Modellgetriebenen Architektur halbwegs greifbarer wird und zukünftige Recherchen möglicherweise erleichtert.
Als allgemeinen Gedanken kann man die sogenannte “Model Driven Architecture” (kurz: MDA) sehen. Diese beschreibt den Ansatz, bereits bei der Konzeptionierung und der anschließenden Modellierung eine klare Trennung von Funktionalität und Technik klarzustellen. Dabei unterteilt man eine solche Architektur in drei große Einzelbereiche:

  • Computation Independent Model (CIM)
  • Platform Independent Model (PIM)
  • Platform Specific Model (PSM)

In der ersten Instanz, der CIM, werden jegliche Modelle erfasst, die das Projekt / die Software umgangssprachlich beschreiben. Hier werden dem Team keine Grenzen gesetzt, welche Informationen sie in welchem Detailierungsgrad aufführt(durchaus auch in Fließtextform). Steht das ganze, kann nun zu der Plattform-unabhängigen Modellierung übergegangen werden. Dieser Schritt beinhaltet das Entwickeln von beispielsweise UML-Modellen, um Prozesse und Anwendung des Systems grafisch und abstrahiert darzustellen(Use-Case, Zustandsdiagramm, Prozessdiagramm, etc.).
Die ersten zwei Schritte benötigen keinerlei technischen Entwicklerkentnisse. Im letzten Schritt kommen wir schließlich zu der eigentlichen Modellgetriebenen Entwicklung. Der Grundgedanke hier ist, aus Plattformspezifischen Modellen Code zu generieren. Dabei stoßt man hier auf eine Vielzahl von Bezeichnungen für ein und das selbe Prinzip: MDSD (Model Driven Software Development), MDE (Model Driven Engineering), MDSE (Model Driven Software Engineering) oder einfach nur MDD (Model Driven Development). Durch die grafische Modellierung von beispielsweise Klassen und deren Attributen und Relationen zueinander erreicht man eine hohe Anschaulichkeit und die Möglichkeit, Standardcode bzw. die Programmstruktur zu generieren. Lediglich Funktionen und Methoden müssen noch hinzugefügt werden.
Diese Art der Entwicklung ist natürlich kein Wunderwerkzeug und entfaltet sein volles Potenzial erst bei wirklich großen Projekten, die über einen längeren Zeitraum gehen. Alleingestellt passiert es auch häufig, dass die Entwicklung mit Modellen nur zu Beginn genutzt wird oder aber der Aufwand der Modellierung als zu groß empfunden wird und somit schlechte Erfahrungen damit gemacht wurden. Deshalb empfiehlt sich der MDA-Ansatz, da für eine gewisse Dokumentation gesorgt wird und auch Abseits der Entwicklung Leute mitreden können, während es den Entwicklern selbst frei überlassen bleibt, in wie weit sie sprachenspezifisch Modelle erstellen und wie viel sie lieber klassisch entwickeln, denn die Basis ist trotzdem vorhanden.

Drei Möglichkeiten zur Einführung von Open Source

Open Source Software kostet zwar keine Lizenzgebühren, aber ist natürlich trotzdem nicht kostenlos. Zumindest die Einführung bzw. Implementierung und der spätere Betrieb sind mit Kosten verbunden. Je nach dem, wie Sie als Anwender die Implementierung vornehmen, sind das vielleicht nur interne Kosten, die man auf den ersten Blick gar nicht sehen kann. Trotzdem fallen sie natürlich an, beispielsweise wenn Sie sich in dieser Zeit Ihren anderen Aufgaben nicht mehr uneingeschränkt widmen können.
Wenn man alle Möglichkeiten zusammenfasst, kommt man auf die folgenden drei Möglichkeiten Open Source in einem Unternehmen einzuführen:
1. Das Superhelden Model
In diesem Fall machen Sie als Held alles selbst. Sie besorgen sich die Software aus dem Internet und arbeiten sich intensiv in das Thema ein. Danach installiert und konfigurieren Sie alles selbst. Das kostet so gut wie gar kein Geld, aber natürlich sehr viel Zeit, die ja dann indirekt auch wieder Geld kostet. Außerdem kann es möglicherweise lange dauern, bis die Lösung einsatzbereit ist. Support gibt es in Form von Mailinglisten oder Newsgroups, aber natürlich nur auf freiwilliger Basis. Es gibt keinen Anbieter auf den man sich im Notfall verlassen kann.
2. Das IKEA Model
Sie kaufen eine fertige Schachtel und schrauben dann im Büro nur noch alles passend zusammen. Das geht recht schnell und kostet damit wesentlich weniger Zeit als im erste Fall. Leider ist die Software durch die Herstellervorgaben natürlich auch nicht mehr ganz so flexibel, wie im ersten Fall. Dafür bekommen Sie Support durch den Hersteller des Pakets und können sich im Notfall auf den zugesicherten Support verlassen. Insgesamt braucht dieses Model etwas weniger Zeit, kostet dafür aber auch etwas mehr und die Lösung ist nicht mehr so flexibel.
3. Das Consultant Model
Sie kaufen das komplette Know How von einem professionellen Anbieter ein und lassen sich eine eigene und individuelle Lösung herstellen. Das kostet im Vergleich zu den anderen Möglichkeiten nur sehr wenig Zeit, ist aber natürlich nicht ganz billig. Dafür ist die Lösung ganz genau auf Ihre Anforderungen ausgerichtet. Mit dem Dienstleister haben Sie jemanden, der Sie jederzeit, auch beim späteren Betrieb unterstützen kann.
Die verschiedenen Modelle stehen natürlich auch für unterschiedliche Kundentypen: Das Superheldenmodel funktioniert sicher nur im privaten Bereich oder in kleinen Firmen. Das IKEA Model setzt mal normalerweise in sehr standardisierten Fragestellungen ein, denn bei einem Fileserver braucht man nicht unbedingt externe Beratung, etwas Support macht aber schon Sinn. Und das Consultant Model eignet sich besonders für große Firmen, die eine sehr spezielle Umgebung haben oder eine individuelle Lösung benötigen. In diesem Fall ist es sicher auch günstiger und vor allem schneller externes Know How einzukaufen. Man muß ja nicht alle Fehler selbst machen. Und durch unsere Vorgehen in Workshops versuchen wir trotzdem aus allen Projektbeteiligten Superhelden zu machen, denn eine komplexe Lösung muss ja auch betrieben werden.

Julian Hein
Julian Hein
Executive Chairman

Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.