Das Buch beschreibt ausführlich ein Vorgehensmodell zur Spezifikation von Komponenten. Die Outputartefakte der beschriebenen Arbeitsschritte sind fast immer UML Diagramme. Im Stil ist es, auch für nicht-Techniker, gut lesbar geschrieben. Stellenweise wiederholt sich der Autor.
Die eigentliche Hauptaufgabe aller am Entwicklungsprozess Beteiligter, nämlich das effiziente Produzieren von sauber implementierter, getesteter Software (Code!), verliert man beim Lesen des Buches beinahe aus den Augen. Zum Beispiel ist das im Kontext der Komponentenentwicklung wichtige Thema Qualitätssicherung auf knapp formulierte, allgemein gehaltene Managementempfehlungen beschränkt.
Dass sich die Vorgehensweise mit dem Attribut agil schmückt, hat wohl eher marketingtechnischen Charakter. Darauf, wie man die Vielzahl produzierter UML Diagramme synchronisiert behalten kann, wenn man während des Modellierens neue Einsichten gewinnt oder wenn gar neue Anforderungen auftauchen, wird nicht eingegangen. Eher stellt man sich ein Designteam vor, welches UML Spezifikationen produziert, diese den Entwicklern übergibt und sich später wundert, weshalb etwas anderes implementiert wurde.
Hätte das Buch einen Titel wie Leitfaden zur Erstellung von UML Diagrammen zur Beschreibung von Komponenten würde dies seinem Inhalt gerecht. Man entschied sich aber aus offensichtlichen Gründen für einen verkaufsfördernden Titel, wo natürlich auch das das Wörtchen XML nicht fehlen darf selbst dann nicht, wenn es schlicht nichts mit dem Thema zu tun hat.
Das Buch richtet sich wohl an technische Projektleiter, die in Ihrem komplexen Aufgabenbereich den Überblick behalten müssen und die sich auch mal mit Auflistungen aktueller IT Schlagwörter zufrieden geben.
Softwareentwickler, die auch in der Implementierung Verantwortung übernehmen, werden enttäuscht sein.
