Modellgetriebene Softwareentwicklung Das Ableiten bzw. Synthetisieren von Softwaresystemen (oder bestimmten Aspekten eines Softwaresystems) hat in den vergangenen Jahren durch die MDA stetig an Bedeutung gewonnen. Fachexperten sind sich einig: In der Modellierung liegt die Zukunft der Softwareentwicklung. Aber wie fern ist diese Zukunft noch? Schließlich liegt die Zukunft der Personenbeförderung seit langem in alternativen Energien. Faktisch hat sich auf diesem Gebiet nicht viel getan. Ähnlich ist es mit der MDA oder prinzipiell der MDSD, der Modellgetriebenen Softwareentwicklung, welche gewissermaßen die Grundlagen für die MDA bildet. Ein 4er-Team kompetenter IT-Experten haben sich der schwammigen Materie der MDSD angenommen und versucht die Konturen dieser zukunftsträchtigen und Erfolg versprechenden Methodik zu schärfen. Das Buch deckt einen ziemlich breit gefächerten Umfang ab. Es wird nahezu jedes mit Modellgetriebener Entwicklung verwandte – und macnhes nicht verwandte – Thema miteinbezogen und besprochen. Über eine Einführung und Motivation zum Hauptgebiet „Domänenarchitekturen“, in welchem alle für eine spezifische Domäne relevanten Techniken, wie DSLs, Model-2-Model-Transformationen, taugliche Zielarchitekturen oder Codegeneratoren, umfassend aber oberflächlich behandelt werden. Darauf aufbauend werden Best Practices für MDSD-Prozesse aufgeführt, das Thema „Testing“ darf natürlich nicht fehlen, eben so wenig wie die Versionierung von Artefakten, denn wer arbeitet an komplexen Softwaresystemen schon alleine? Den Abschluss bilden Überlegungen zum Management von MDSD-Projekten. Das Buchprojekt ist durchaus ehrgeizig, soviel möchte ich den Autoren zugestehen. Das Thema ist schwer einzugrenzen und bei der Fülle von möglichen Auslegungen und Methodiken, wie ein MSDS-Projekt aufgebaut und durchgeführt werden kann, bleibt immer einige Verfahren bzw. Schlagworte „unangeschrieben“. Mir gefällt, dass die Autoren eine Vielzahl dieser Schlagworte aufgefasst haben. Das im Titel aufgeführte Wort „Techniken“ gilt also als übererfüllt. Damit ist es aus meiner Sicht jedoch vorbei mit der Herrlichkeit. Fortan verlieren sich die Autoren in der Masse, führen Passagen und Themen auf, ohne diese zu konkretisieren oder mit einem praktisches Projekt zu verschmelzen. Was hilft es, wenn sie folgerichtig schreiben, dass Frameworks für ein Softwaresystem über eine eigene DSL sich hervorragend in einer Architektur einbinden lassen, es aber keinerlei hinweise darauf gibt, wie man dies nun konkret durchsetzt? Gleiches gilt für Middlewaresysteme. Zu Service-Orientierung von solchen System wird beispielsweise gesagt, dass Service prinzipiell sich sehr gut durch MSDS umsetzen lassen. Das war es zu diesem Thema. Der Rezipient fragte sich mehrmals, was die Autoren eigentlich zu erreichen gedenken? Eine Aufzählung derzeit hoch im Kurs stehender „buzz-words“ oder eine zielgerichtete Einführung und Konkretisierung der MDSD, mit derer es möglich ist ein eigenes MDSD-Projekt auf- und umzusetzen? Denn dies ist die Intension der Zielsetzung der Autoren (laut Vorwort). Meiner Meinung nach erreichen sie dieses Ziel nicht. Löblich sei angemerkt, dass die Autoren das Thema „Testen“ nicht auf die Ersatzbank verdrängen – wie in den meisten Büchern –, sondern diesem Bereich ein ganzes Kapitel widmen. Subjektiv betrachtet treffen die Autoren aber auch hier vollkommene Falschaussagen: So messen sie der Bedeutung automatisch abgeleiteter Testfälle keinen Stellenwert zu. Ich denke jedoch, dass insbesondere die automatisierte Testfallgenerierung aus den vorhandenen Systemmodellen (State Machine, Sequence Diagrams) das Ziel in der MDA oder MDSD sein sollte. Darüber hinaus fehlt mir ein Hinweis auf das extra zu diesem Zweck konzipierte „UML2 testing Profile“ (U2P), mit dem auf Basis der Systemmodelle die Testkomponenten und Testverhalten bereits über Stereotypen für die anschließende Testsequenzgenerierung angereichert werden können. Abschließend möchte ich betonen, dass die Autoren keineswegs schlecht schreiben, nein, die Texte sind besitzen einen gehobenen Anspruch. Dennoch fehlt der Bezug zur Anwendung total. Es hilft einem geneigten Rezipienten reichlich wenig, wenn der ihm vorliegende Text gespickt mit hochtragenden und fachspezifischen Worten ist, es aber keine praktische Verwendung für diese Aussagen gibt? Betrachtet man das Buch jedoch als theoretische, wissenschaftliche Einführung über MDSD, so liefert es doch allerhand interessante Fakten.

Das Ableiten bzw. Synthetisieren von Softwaresystemen (oder bestimmten Aspekten eines Softwaresystems) hat in den vergangenen Jahren durch die MDA stetig an Bedeutung gewonnen. Fachexperten sind sich einig: In der Modellierung liegt die Zukunft der Softwareentwicklung. Aber wie fern ist diese Zukunft noch? Schließlich liegt die Zukunft der Personenbeförderung seit langem in alternativen Energien. Faktisch hat sich auf diesem Gebiet nicht viel getan. Ähnlich ist es mit der MDA oder prinzipiell der MDSD, der Modellgetriebenen Softwareentwicklung, welche gewissermaßen die Grundlagen für die MDA bildet. Ein 4er-Team kompetenter IT-Experten haben sich der schwammigen Materie der MDSD angenommen und versucht die Konturen dieser zukunftsträchtigen und Erfolg versprechenden Methodik zu schärfen.

Das Buch deckt einen ziemlich breit gefächerten Umfang ab. Es wird nahezu jedes mit Modellgetriebener Entwicklung verwandte – und macnhes nicht verwandte – Thema miteinbezogen und besprochen. Über eine Einführung und Motivation zum Hauptgebiet „Domänenarchitekturen“, in welchem alle für eine spezifische Domäne relevanten Techniken, wie DSLs, Model-2-Model-Transformationen, taugliche Zielarchitekturen oder Codegeneratoren, umfassend aber oberflächlich behandelt werden. Darauf aufbauend werden Best Practices für MDSD-Prozesse aufgeführt, das Thema „Testing“ darf natürlich nicht fehlen, eben so wenig wie die Versionierung von Artefakten, denn wer arbeitet an komplexen Softwaresystemen schon alleine? Den Abschluss bilden Überlegungen zum Management von MDSD-Projekten.

Das Buchprojekt ist durchaus ehrgeizig, soviel möchte ich den Autoren zugestehen. Das Thema ist schwer einzugrenzen und bei der Fülle von möglichen Auslegungen und Methodiken, wie ein MSDS-Projekt aufgebaut und durchgeführt werden kann, bleibt immer einige Verfahren bzw. Schlagworte „unangeschrieben“. Mir gefällt, dass die Autoren eine Vielzahl dieser Schlagworte aufgefasst haben. Das im Titel aufgeführte Wort „Techniken“ gilt also als übererfüllt.

Damit ist es aus meiner Sicht jedoch vorbei mit der Herrlichkeit. Fortan verlieren sich die Autoren in der Masse, führen Passagen und Themen auf, ohne diese zu konkretisieren oder mit einem praktisches Projekt zu verschmelzen. Was hilft es, wenn sie folgerichtig schreiben, dass Frameworks für ein Softwaresystem über eine eigene DSL sich hervorragend in einer Architektur einbinden lassen, es aber keinerlei hinweise darauf gibt, wie man dies nun konkret durchsetzt? Gleiches gilt für Middlewaresysteme. Zu Service-Orientierung von solchen System wird beispielsweise gesagt, dass Service prinzipiell sich sehr gut durch MSDS umsetzen lassen. Das war es zu diesem Thema. Der Rezipient fragte sich mehrmals, was die Autoren eigentlich zu erreichen gedenken? Eine Aufzählung derzeit hoch im Kurs stehender „buzz-words“ oder eine zielgerichtete Einführung und Konkretisierung der MDSD, mit derer es möglich ist ein eigenes MDSD-Projekt auf- und umzusetzen? Denn dies ist die Intension der Zielsetzung der Autoren (laut Vorwort). Meiner Meinung nach erreichen sie dieses Ziel nicht.

Löblich sei angemerkt, dass die Autoren das Thema „Testen“ nicht auf die Ersatzbank verdrängen – wie in den meisten Büchern –, sondern diesem Bereich ein ganzes Kapitel widmen. Subjektiv betrachtet treffen die Autoren aber auch hier vollkommene Falschaussagen: So messen sie der Bedeutung automatisch abgeleiteter Testfälle keinen Stellenwert zu. Ich denke jedoch, dass insbesondere die automatisierte Testfallgenerierung aus den vorhandenen Systemmodellen (State Machine, Sequence Diagrams) das Ziel in der MDA oder MDSD sein sollte. Darüber hinaus fehlt mir ein Hinweis auf das extra zu diesem Zweck konzipierte „UML2 testing Profile“ (U2P), mit dem auf Basis der Systemmodelle die Testkomponenten und Testverhalten bereits über Stereotypen für die anschließende Testsequenzgenerierung angereichert werden können.

Abschließend möchte ich betonen, dass die Autoren keineswegs schlecht schreiben, nein, die Texte sind besitzen einen gehobenen Anspruch. Dennoch fehlt der Bezug zur Anwendung total. Es hilft einem geneigten Rezipienten reichlich wenig, wenn der ihm vorliegende Text gespickt mit hochtragenden und fachspezifischen Worten ist, es aber keine praktische Verwendung für diese Aussagen gibt? Betrachtet man das Buch jedoch als theoretische, wissenschaftliche Einführung über MDSD, so liefert es doch allerhand interessante Fakten.

geschrieben am 13.05.2008 | 601 Wörter | 3847 Zeichen