Als Software Architekt steht man zu Projektbeginn vor vielen
Entscheidungen.
Eine Entscheidung ist unter anderem ob man Modelgetrieben,
inkl. Casetool-Unterstützung, vorgehen will oder eben nicht.
Im folgenden einige Punkte wieso ich mich bisher gegen
den MDA / MDSD Ansatz (Model Driven Architecture, Model Driven Software
Development) entschieden habe:
- MDA ist cool wenn es ein großes
unternehmensweites Datenmodell gibt.
Unternehmensweite Datenmodelle sind aufgrund der Service Orientierung etwas aus der Mode gekommen (der erste google Treffer zu „Unternehmensweite Datenmodelle“ ist ein Artikel aus der Computerwoche von 1989 (http://www.computerwoche.de/heftarchiv/1989/37/1151959/).
In größeren Unternehmen existieren viele spezialisierte Applikationen die nur über definierte Schnittstellen kommunizieren müssen (beispielsweise über BUS- oder Workflowsysteme). Eine SOA passt hier oft besser als eine große Anwendung, die mit einem unternehmensweiten Datenmodell umgehen kann.
Kleine modulare Applikationen à Sind die einzelnen Applikationen klein bzw. auch deren Datenmodell, stellt sich die Frage ob der Einsatz eines Case-Tools mit Klassengeneratoren eher die Produktionsgeschwindikgeit ausbremst. - Beim Einsatz eines OR-Mappers bspw. basierend auf JPA wie
Hibernate oder EclipseLink ist schon seit langen kein aufwändiges XML mehr
notwendig. Mit Hilfe von Annotations lassen sich die Datenbank-Entitäten
definieren.
Bei der Verwendung eines MDA-Ansatzes können XML Beschreibungen zu den Java-Entitäts-Klassen automatisch generiert werden. Hier ist ein MDA Ansatz durchaus sinnvoll.
Bei der Verwendung von Annotations wie bspw. in der JEE (@Entity) lässt sich sehr schlank ein Datenmodell definieren. Der Einsatz von Case-Tools mit Klassengeneratoren verringern hier eher die Produktionsgeschwindigkeit.
- Werden UML Diagramme primär zur Dokumentation benötigt, lassen diese sich bequem aus den bestehen Klassen generieren. Diese können bei der JEE direkt ins JavaDoc integriert werden (UMLGraph).
- MDA / MDSD wird im Moment in meiner Wahrnehmung aktuell
weniger gepusht als JEE6.
Verhältnis der JPA Vorträgen zu Modelling- Vorträgen auf aktuellen Java Konferenzen. Ggf. ist dies ein Grund wieso MDA Know How weniger verfügbar ist als JPA Know How.
Als technisch Verantwortlicher für eine Software ist dies ein nicht unwesentlicher Punkt (gibt es Rotationsmöglichkeiten für Entwickler, welches Know How wird zur Softwarewartung benötigt).
Aus diesen Gründen habe ich mich meist gegen MDSD
entschieden… ich geh allerdings davon aus, dass es noch weit mehr Gründe gibt
;-)
