Guerilla Projektmanagement

IT Projekte & Agilität & Zeuch

Warum UML 2.1 nicht funktioniert

Eigentlich liebe ich UML. Sie ist übersichtlich, leicht zu erlernen und für jemanden wie mich der sich noch an die lustigen „Booch-Wolken“ erinnern kann ein echter Segen.

Diese Woche habe ich aber mal wieder gelernt, dass meine Vorurteile der UML 2 gegenüber berechtigt sind.

UML ist eine Hilfe u.a. zur Kommunikation zwischen Technik und Fachbereich. Sie ist die Schnittstellensprache welche beiden Seiten einiermaßen problemlos verstehen. Der Fachbereich versteht keine Klassendiagramme, aber Use-cases, Aktivitätsdiagramme und Sequenzdiagramme eignen sich super zur Kommunikation.

Was aber UML aus meiner Sicht nicht sein sollte: Eine grafische Programmiersprache. Und genau das wird gerade versucht. Durch den MDA Ansatz steigert die Komplexität der Diagramme enorm. Das wäre an sich ja noch nicht schlimm. Ich stelle aber in letzter Zeit immer wieder fest, dass auch die Tekkies durch die UML2 Mächtigkeit überfordert sind. Das Ergebnis: Sie beherschen UML nur noch rudimentär und die entstandenen Diagramme sind fehlerhaft (was nicht schlimm ist), unvollständig und widersprüchlich (und das ist schlimm!). Ich bin mal gespannt, wie es weiter gehen wird.

3 thoughts on “Warum UML 2.1 nicht funktioniert

  • Alex sagt:

    Servus, also hier muss ich dir mal ganz eindeutig widersprechen. Dass Diagramme fehlerhaft, unvollständig und widersprüchlich sind ist doch nicht der Fehler von UML 2(.1). Ich hab auch keinen schwarzen Gürtel in UML aber ich habe es immer noch geschafft, für Alle verständliche Diagramme zu zeichnen und dafür gibt es einfach ein paar Grundregeln, z.B. die Zahl der Klassen so weit wie möglich einzuschränken. Beziehungen und Kardinalitäten wiederrum finde ich in einem Klassendiagramm essenziell, aber gefährlich, da an diesen Stellen am leichtesten die Unwissenheiten zu Tage treten und die Diagramme widersprüchlich, fehlerhaft und unvollständig machen – aber so mächtig war die UML schon immer.

    Die UML2 wurde ja eingeführt um damit genereller umgehen zu können. Als Beispiel nenne ich hier mal die Stereotypen, die es erlauben, mit der UML domänenspezifischer zu modellieren. Die Änderungen und Erweiterungen hängen sicher auch damit zusammen, MDA zu unterstützen und hier weiter zu standartisieren – aber nicht mit dem Ziel eine grafische Programmiersprache zu entwickeln, sondern die Lösung wiederkehrender Aufgabenstellungen zu automatisieren. Die Modelle der MDA sind übrigens nicht ausschließlich als UML zu finden sondern existieren auch in vielen anderen Ausprägungen.

    Also, das Problem mit der UML ist nicht die UML, sondern wie man damit umgeht ;-)

  • Sven Rimbach sagt:

    Stimmt. Ich habe mich nicht gut ausgedrückt.
    Eigentlich wollte ich schreiben: UML 2 ist so komplex, dass immer weniger Leute sie gut verstehen und immer mehr Leute schlechte Diagramme schreiben.

    Das soll nicht heißen, dass man nicht auch gute, verständliche Diagramme erstellen kann und es gibt sicherlich auch viele Leute, die das können

  • Generell muss ich Euch beiden rechtgeben. Sven hat aber bereits eingeräumt sich hier schlecht ausgedrückt zu haben.

    Aus meiner Projekterfahrung heraus stellt sich UML beim Kunden (mittlererweile) als zweischneidiges Schwert heraus. Persönlich habe ich in der eigenen Firma die Erfahrung gemacht, dass man damit sehr wohl beim Kunden sitzen und mit ihm analysieren kann. Viele Leute haben mir immer wieder gesagt, sie hielten dies für Blödsinn und das bringt nix.

    Wir hatten damit eigentlich immer Erfolg und ich verstand diese Kritiken nicht. Bis ich letztendlich auf den Trichter kam, dass wir UML im Rahmen con OOA, OOD und natürlich auch OOP Trainings jahrelang geschult hatten. Man bekommt dabei einen anderen Draht damit umzugehen und es anderen Leuten nahezu bringen. Gut der Kunde muss es nicht soweit kapieren es selber machen zu müssen wie ein Schulungsteilnehmer, aber die Art es einem Newbie zu erklären ist bereits eine andere.

    Schaue ich mir heute so manche meiner Kunden im Projektgeschäft an, verstehe ich die Kritiker voll und ganz. Und hier haben wir auch den gemeinsamen Nenner. Nur weil UML draufsteht muss noch nix gscheites dabei rauskommen. UML alleine kann per se mal nix dafür.

    Zum Thema MDA, möchte ich aber auch noch was loswerden. Wir haben im Rahmen eines OpenSource Produktes (plone.org) einen Generator entwickelt, welcher quasi Produktrümpfe aus UML generiert, mit allem was Klassenmodelle, Statediagramme etc. halt so können. Ganz nebenbei können auch alle wesentlichen Unittests generiert/vorbereitet werden.

    Vorteil: das Ding wird wirklich exzessiv in der ganzen Entwicklergemeinde genutzt. Alle langweiligen und wiederkehrenden Codierungen werden dem Entwickler abgenommen und Unittests zu erstellen ist ebenfalls keine Qual mehr weil es sich gut automatisieren lässt. Die erzeugte Software hat mehr Qualität, und die Entwicklungszyklen verkürzen sich.
    Dass dennoch viel zu tun bleibt, sollte jedem klar sein, MDA Ansätze erzeugen mit Sicherheit noch keine Out of the Box Software welche alle zufridenstellen kann.

    My 2 cents on this ;)

Schreibe einen Kommentar zu Alex Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert