Es kommt immer darauf an, was man von der
UML nutzt. Ich finde UseCases sind eine sehr gute Möglichkeit das System ausreichend abstrakt darzustellen, dass der Kunde und der Entwickler sich auskennen und sich einig sind welche Aufgaben das System übernimmt. Mit der Beschreibung dazu kann der Kunde selber reflektieren ob das Ding genau das tut was er will, oder er findet selbst Optimierungen. Der Aufwand hält sich dabei echt in Grenzen und wenn man UseCases Konsequenz erstellt, kann man als Entwickler auch die Klassen und den Aufbau daraus gewinnen. Bislang konnte ich bei der Anforderungsanalyse die besten Ergebnisse mit UseCases erzielen. Das schlimmste ist ja die Anforderung des Kunden nicht oder falsch verstanden zu haben und einfach darauf los zu entwickeln. (aber wer macht denn das schon? *gg*) Dann hat man zum Schluss eine vielleicht ganz tolle Anwendung, aber sie hilft dem Kunden nichts, weil sie anders arbeitet als er erwartet oder schlimmstenfalls gar nicht das tut was er möchte.
Ich verwende eigentlich nur die abstrakteren Diagramme um einen Überblick auf das System zu ermöglichen. Klassendiagramme oder Interaktionsdiagramme (Sequenz bzw. Aktivitätsdiagramm) nur ganz, ganz selten. Die sind natürlich sehr detailliert und ändern sich rasch. Da ist dann immer die Frage inwieweit sich der Aufwand dafürsteht.
Aber es stimmt leider, dass Delphi für MVVM komplett ungeeignet ist. Die Bindings sind im Vergleich zu C# in VS komplett unterlegen. Es gibt auch nichts vergleichbares zum ICommand Interface. Daher ist eine saubere Aufteilung meines Erachtens nach nur bedingt möglich - bei größeren Projekten aber unumgänglich. Das Schlimmste ist der Doppelklick auf einen Button und dann die Logik dahinter reinschreiben. Eine Aufteilung der Anwendung in Layer wird immer wichtiger, vor allem auch, wenn man für iOS, OSX oder den kommenden Android (Linux?) Plattformen programmieren möchte. Den "Compiler everywhere" Ansatz ohne Änderungen halte ich nicht für sinnvoll (Stichwort UI Guidelines der
OS Hersteller).
SOA kann man aber schon gut genug umsetzen finde ich. Obwohl C# auch hier mehr Möglichkeiten bietet.
Eine Dokumentation ist halt immer ein leidiges Thema. Die, die sich mit dem System auskennen brauchen es nicht und verstehen nicht warum sie die Doku machen sollten. Dabei kommt ein neues Teammitglied ohne Doku kaum nach und spätestens nach einigen Monaten/Jahren, wenn niemand weiterentwickelt hat, wären sie selbst froh wenn sie eine Doku zu hätten. Und noch schlimmer ist eine Doku die nicht am letzten Stand ist... dann lieber gar keine Doku.