[UML] [Klassendiagramm] Unbekannte Typen, sowie abstrakte Methoden

[Tersus]

Hallo,

ich arbeite mich derzeit in ArgoUML und Modelio ein, um dann das "bessere" UML Tool für meinen Geschmack zu finden.
Dabei stoße ich auf einige Fragen.

1)
Was mache ich, wenn ich eine Klasse erstelle möchte, deren Methoden API-spezifische Typen, wie "View" oder "CharSequence", als Parameter übergeben bekommen? Die UML Tools kennen diese Typen doch gar nicht.

2)
Wenn eine meiner Klassen ein Interface implementiert, dann muss sie bekanntlich die methodenrumpflosen Methoden dieses Interfaces definieren.
Ist es hier wichtig, dass ich in meinem UML Klassendiagramm diese Methoden dann doppelt hineinschreibe. Also sowohl im Interface, als auch in der Klasse, die das Interface implementiert?
Oder reicht es, die Methode im Interface stehen zu haben, weil ja bekannt sein müsste, dass meine Klasse diese definieren muss, soweit sie das Interface implementiert.


Vielen Dank für eure Unterstützung!

 

[NullPointer]

Ketzerische Frage: Willst du UML benutzen, oder wird es von dir gefordert?

 

[Tersus]

Den Hintergrund der Frage verstehe ich auch nach längerem Grübeln nicht.

Meinst du, dass jemand, der wirklich daran interessiert ist (so wie ich), die gestellten Fragen wissen müsste?

Ich will es wirklich benutzen, weil ich Modellierung für sehr sinnvoll halte und auch denke, daran meinen Spaß zu haben.


Grüße

 

[NullPointer]

Ok, dann ist ja gut

Der Hintergrund war, dass ich aus meiner eigenen Erfahrung als Entwickler Modellierung für überholt halte. Ich habe auch seit Jahren kein UML mehr angefasst, deswegen kann ich dir bei deinen Fragen leider nicht helfen.

 

[Tersus]

Meinst du wirklich überholt, oder überbewertet? Wenn du ersteres meinst. Von was würde UML überholt?

 

[NullPointer]

Ich betrachte (UML-)Modellierung als Anzeichen einer Big Design Up Front-Herangehensweise. Diese Methode ist mMn überholt durch agile Entwicklungspraktiken und die damit einhergehende Idee des Emergent Design. Kurz gesagt, statt die Struktur des Codes ausführlich zu planen, bevor überhaupt mit der Implementierung angefangen wird, entsteht dabei die Struktur im laufenden Prozess (und kann sich auch immer wieder ändern).

Der Vorteil dabei liegt vor allem darin, dass es wesentlich flexibler ist. Meiner Erfahrung nach ist es einfacher, beim Coden selbst festzustellen, welches Design für mich am besten geeignet ist, als im voraus. Außerdem ändert sich das Design immer mal wieder - sei es wegen geänderter oder neuer Anforderungen oder weil ich einfach feststelle, dass es noch etwas besser ginge. In gewisser Weise erinnert mich das UML-Modelling an das Bauen von Häusern: Der Architekt macht die Pläne, danach wird gebaut, und dann kann sich auch nichts mehr ändern. Software ist aber nicht so - da sind Änderungen an bestehendem Code an der Tagesordnung, und sobald das passiert, ist das Modell veraltet. Deswegen halte ich es für gescheiter, allenfalls generelle Vorüberlegungen zu treffen, wie das Design aussehen soll, aber kein detailliertes Modell.

Ein Beispiel für eine "moderne" Methodik, die sehr stark auf Emergent Design setzt, ist Test Driven Development. Man kann es aber ebensogut nicht-testgetrieben machen (so wie ich in aller Regel).

 

[thecain]

Nur weil man ein UML Diagramm erstellt hat das noch lange nichts mit Big Design Up Front zu tun. Es ist ja jederzeit möglich das UML anzupassen oder zu erweitern.

Wenn man jedoch mit Personen von Fachbereichen oder in einem grösseren Team über ein Endprodukt auf einer Ebene reden will, kommt man nicht umher dies irgendwie zu illustrieren. Ein UML kann hier eine Hilfe sein.

Bei einem UML jedoch alle Methoden Klassen usw in Stein meisseln zu wollen finde ich auch unsinnig.

 

[NullPointer]

Stimmt schon - ich hätte vielleicht betonen sollen, dass ich im speziellen Diagramme wie dieses meine. So etwas kann man vielleicht zur Dokumentation von existierendem Code benutzen (da gibt es ja zum Glück Tools, die das automatisch aus dem Code generieren - per Hand wäre kein Spaß), aber die Entwicklung neuen Codes würde ich so nicht durchplanen.

 

[Tersus]

@thecain

Sehe ich auch so. Ich finde UML ist super, um die Beziehungen der Klassen und Interfaces zu veranschaulichen. Ich setze es ja auch nur unterstützend zur Beschreibung ein.


@NullPointer

Das Klassendiagramm ist ja gruslig. Verfehlt so sicher seinen Zweck.