Offene Punkte in der MDA-Anwendung

Sie sind nicht angemeldet

Kompetenzzentrum

Wissensdatenbank

	Anwendungsfelder

	SE-Themen


	Glossar

	Forschungsprojekte

	Anbieterverzeichnis

	Datenbanksuche

	Highlights

Wissensbrowser starten

Einordnung im Wissensnetz

Thema

MDA

Themeneinstiege

	MDA Basistechnologien
	MDA Konzepte
	MDA Motivation Nutzen
	MDA offene Punkte
	MDA Themenüberblick
	MDA Wissenschaft

Zuordnung zu SE-Themen

Entwurf

	Strategien & Methoden

Verfahren

Offene Punkte in der MDA-Anwendung


	NEU: Externe Quellen zum Thema suchen Externe Quellen werden abgefragt...

Beschreibung

Die MDA ist ein noch relativ junger Standard. Es ist daher nicht verwunderlich, wenn es in der praktischen Anwendung noch viele Schwierigkeiten gibt. Zum einen ist die Umsetzung des Standards in entsprechenden Werkzeugen noch nicht überzeugend und zum anderen gibt es noch eine Reihe konzeptioneller Aspekte rund um die MDA-basierte Softwareentwicklung, die noch nicht ausreichend geklärt erscheinen.

Einige dieser Aspekte sind im folgendem aufgeführt und erläutert.

Stabilität des Datenmodells
Änderungen am Datenmodell können großen Aufwand nach sich ziehen, der bei der Änderung des Modells nicht sofort sichtbar ist.

Entfremdung des Entwicklers vom Code
Der generierte Code ist für den Entwickler nur noch schwer verständlich und damit schwer nachvollziehbar.

Unzulänglichkeiten in den Tools
Die Erwartungshaltungen der Entwickler sind derzeit nur schwer zu erfüllen.

Reverse-Engineering/
Reengineering/Wartung
MDA ist ursprünglich für Neuentwicklungen gedacht. Wie können aber bestehende Softwaresyteme in MDA übernommen werden, so dass die Weiterentwicklung mit Hilfe dieser Methodik erfolgen kann. Ein weiterer Aspekt ist die Erzeugung von Releases, Patches oder Updates, welches ein wichtiger Bestandteil der laufenden Wartung von Anwendungen ist. Wie geht MDA damit um? Jedes Mal das komplette System neu installieren?

Plattform-Begriff
Die OMG versteht im engeren Sinne unter diesem Begriff die Middleware und hier insbesondere CORBA. Plattformunabhängigkeit meint also eher Unabhängigkeit von Middleware. Im weiteren Sinne aber auch z. B. Programmiersprachen. Letztlich muss sich der MDA-Anwender im Vorfeld darüber klar werden, wie er den Begriff Plattform definiert.

ROI (Return-on-Investment)
Bisher gibt es nur sehr wenig Überlegungen dazu, ab wann sich der Einsatz von MDA lohnt. Für den Einsatz von MDA sind viele Vorbereitungen und Vorarbeiten notwendig. Hierzu gehören nicht nur Schulungen der Entwickler, sondern auch konzeptionelle Arbeiten (z. B. Anpassung des Softwareentwicklungsprozesses). Dies sind nicht unerhebliche Aufwände.

EAI (Enterprise Application Integration)
Modellierung auf hoher Ebene erscheint auf den ersten Blick sinnvoll. Neue Anwendungen laufen aber selten für sich isoliert, sondern müssen in eine vorhandene Anwendungslandschaft integriert werden. Wie aber werden sie in der MDA-basierten Entwicklung berücksichtigt?

Herstellerabhängigkeit
Da der MDA-Standard derzeit noch nicht vollständig und einheitlich von den Toolherstellern umgesetzt wird, bedeutet die Festlegung auf ein Werkzeug damit auch eine gewisse Abhängigkeit vom Hersteller. Solche Abhängigkeiten haben sich in der Vergangenheit jedoch oftmals als schlecht herausgestellt.

Zurück zum Themenüberblick Model Driven Architecture.