UML & dessen Sinnhaftigkeit

[zwutz]

byto schrieb:

Wozu brauche ich da ein Klassendiagramm?

wenn du mal keine IDE zur Verfügung hast. Besprechungen, Dokumentationen oder wenn man in der Mittagspause in der Kantine nochmal über die Struktur nachdenken will

[byto]

Warum reisst Du mein Post aus dem Zusammenhang?
Ich habe nie geschrieben, dass Klassendiagramme gänzlich sinnlos sind. Ich habe lediglich klargestellt, dass Klassendiagramme für Codenavigation unnötig sind!

[zwutz]

byto schrieb:

Warum reisst Du mein Post aus dem Zusammenhang?
Ich habe nie geschrieben, dass Klassendiagramme gänzlich sinnlos sind. Ich habe lediglich klargestellt, dass Klassendiagramme für Codenavigation unnötig sind!

weil man eben nicht immer vor der IDE hockt, wenn man mal sehen will, welche Beziehungen die Klassen untereinander haben

Das wäre das gleiche, als würdest du die Druckfunktion von IDEs in Frage stellen, weil du ja den Code sowieso in der IDE sehen kannst

[byto]

Wenn ich nicht vor der IDE hocke, dann will ich auch nicht im Code navigieren.

Klassendiagramme sehe ich auch nur, wenn ich ein entsprechendes Tool öffne oder sie mir vorher ausgedruckt habe. Ich weiss ja nicht, wie Du Software entwickelst aber ich aktualisiere nicht nach jeder Codeänderung irgendwelche Klassendiagramme und drucke sie mir aus, damit ich sie auf dem Klo oder in der Kantine angucken kann.

[DEvent]

byto schrieb:

DEvent schrieb:

In Java SDK wäre das z.B. die Klassen AbstractCollection , AbstractList , AbstractQueue , AbstractSet , ArrayDeque , die List-Interfaces und dessen Implementierung wie Vector , ArrayList , usw. Dies in einem Klassendiagramm zu sehen würde vieles übersichtlicher machen. Oder ein weiteres Klassendiagramm wäre alle Klassen die von Throwable erben und im Paket java.utils sind. Ein weiteres Klassendiagramm wäre alle Klassen die von InputStream erben und im Paket java.io sind. Usw. usf.

Sehe nicht, wozu ich dafür Klassendiagramme brauche. Wenn ich z.B. wissen will, welche List-Implementierungen es gibt, dann markiere ich in Eclipse List, drücke F4 oder STRG + T und sehe alle Subtypen von List. Und wenn ich wissen will, wo z.B. überall im Projekt Typ XYZ benutzt wird, dann markiere ich XYZ und drücke STRG + SHIFT + G.

Vernünftige IDEs wie Eclipse oder Intellij IDEA haben unglaublich viele und gute Navigationsmöglichkeiten für OO-Code. Wozu brauche ich da ein Klassendiagramm?

* Um zu sehen ob du ein gutes Design hast. Um mich zu Zitieren:

Außerdem sehe ich dann die Referenzen, und wenn das Klassendiagramm schön* ist, dann ist der Code auch im gutem OOP Stil. Schön im Sinne von kein Spagetti, alle Assoziationen zeigen einen Fluss in eine Richtung, usw.

* Um sich einen schnellen Überblick zu verschaffen

* usw.

[ulmel]

Marc++us schrieb:

Tretet mal einen Schritt zurück von der Programmierung und denkt auch daran, daß sich auch noch andere Gewerke mit der Software befassen, aber nicht in C++ denken.

Z.B. die Erstellung der Dokumentation oder von Schulungsunterlagen profitiert durchaus ganz erheblich von Sequenzdiagrammen, weil dies den Ablauf der Schulungen vorgibt, etc.

ja, aber da tuts jedes diagramm und es muss nicht uml sein

[Zeus]

ulmel schrieb:

Marc++us schrieb:

Tretet mal einen Schritt zurück von der Programmierung und denkt auch daran, daß sich auch noch andere Gewerke mit der Software befassen, aber nicht in C++ denken.

Z.B. die Erstellung der Dokumentation oder von Schulungsunterlagen profitiert durchaus ganz erheblich von Sequenzdiagrammen, weil dies den Ablauf der Schulungen vorgibt, etc.

ja, aber da tuts jedes diagramm und es muss nicht uml sein

Um immer wieder zu ertagen, was uns die Notation sagt? XD

[otze]

Zeus schrieb:

Um immer wieder zu ertagen, was uns die Notation sagt? XD

Ich bin nicht 100% sicher in den unterschiedlichen UML Diagrammen, aber meiner Erfahrung nach gibt es kein Diagramm, dass wirklich super passt. Klassendiagramme bringen dir zum Beispiel nur an sehr wenigen Stellen wirklich etwas - nämlich wenn du die direkten Abhängigkeiten zwischen Klassen im Code rausfinden willst. Für einen groben Überblick, der in Dokumentationen häufig gebraucht wird, ist das aber gar nichts.

Das Problem hatten wir zum Beispiel letztens in unserem Studienprojekt. Wir wollten auf einer Seite grob den Datenfluss zwischen den einzelnen Modulen beschreiben. Also: Die Sensoren liefern die Eingaben die dann von A und B verarbeitet werden. Das Ergebnis von A landet in C und das Ergebnis von B in D. C schickt nun Datenblöcke an D welches die Ergebnisse zurück an C schickt. Das Ergebnis von C wird ausgegeben.

Naja, es kam halt einer mit nem Datenblatt über die verschiedenen UML-Diagramme an und wir saßen dann mit dem kompletten Team und den Betreuern drüber, konnten aber nichts passendes finden. Am Ende wurde es dann ein generisches Box/Pfeil-Diagramm mit Beschriftungen an den Pfeilen. Und da sist halt das Problem. Bis auf Klassen/Sequenzdiagramme sind die anderen Diagramme so speziell, dass man einfach keinen Groben Überblick über sowas wie Datenfluss oder Verarbeitungsreihenfolge geben kann.

[DEvent]

otze schrieb:

[...] ein generisches Box/Pfeil-Diagramm mit Beschriftungen an den Pfeilen.[...]

Ein Communication Diagram?

[otze]

DEvent schrieb:

otze schrieb:

[...] ein generisches Box/Pfeil-Diagramm mit Beschriftungen an den Pfeilen.[...]

Ein Communication Diagram?

Nein, die sind zu konkret. Dort bedeutet 1Pfeil=1 Methodenaufruf. Bei uns bedeuteten die Pfeile nur "Daten wandern von A nach B auf irgendeine Art und Weise".

Der Fokus lag bei uns darauf, dass dieses Diagramm spezifizieren sollte, welches Modul von welchem Modul welche Daten zur Verfügung gestellt bekommt und welche es darauf basierend berechnen musste.
Auf Basis dieses Diagramms haben wir dann die Interfaces ausgetüftelt und die Klassendiagramme erstellt.
Eine Idee dahinter war auch, dass die Nächsten, die an dem Problem arbeiten, sich das Diagramm anschauen können und daran überlegen, wo sie nun ihre Änderungen einfügen müssen, und welche Module davon betroffen sind (Zum Beispiel wenn neue Daten aus den Eingaben extrahiert werden sollen die dann später irgendwo in die Ergebnisse mit einfließen)

[byto]

DEvent schrieb:

byto schrieb:

Vernünftige IDEs wie Eclipse oder Intellij IDEA haben unglaublich viele und gute Navigationsmöglichkeiten für OO-Code. Wozu brauche ich da ein Klassendiagramm?

* Um zu sehen ob du ein gutes Design hast. Um mich zu Zitieren:

Außerdem sehe ich dann die Referenzen, und wenn das Klassendiagramm schön* ist, dann ist der Code auch im gutem OOP Stil. Schön im Sinne von kein Spagetti, alle Assoziationen zeigen einen Fluss in eine Richtung, usw.

Dafür brauche ich keine Klassendiagramme, weil ich Dependency Injection mache. Das heisst, die konkreten Abhängigkeiten zwischen den Klassen werden nicht im Code sondern an zentraler Stelle aufgelöst. Auf diese Weise behält man einen sehr guten Überblick über alle Assoziationen und kann somit den Spagetti-Grad gering halten. Die IDE visualisiert mir die Dependency Injection bei Bedarf auch grafisch.

Darüber hinaus kann man auch prima mittels Continous Integration die Code-Qualität hochhalten. Ich meine damit folgendes: Du kannst automatisiert vor jedem Commit ins VCS bestimmte Metriken über Deinen Code laufen lassen, z.B. Checkstyle, Prüfung ob Unittests vorhanden usw. Überschreiten die Metriken einen Grenzwert, schlägt der Commit fehl.

[DEvent]

otze schrieb:

DEvent schrieb:

otze schrieb:

[...] ein generisches Box/Pfeil-Diagramm mit Beschriftungen an den Pfeilen.[...]

Ein Communication Diagram?

Nein, die sind zu konkret. Dort bedeutet 1Pfeil=1 Methodenaufruf. Bei uns bedeuteten die Pfeile nur "Daten wandern von A nach B auf irgendeine Art und Weise".

Eine Methode ist nichts weiter als "Daten wandern von A nach B auf irgendeine Art und Weise". Wenn du Daten mit Information und Information mit Nachricht ersetzt, kommst du genau auf die OOP-Definition.

otze schrieb:

Der Fokus lag bei uns darauf, dass dieses Diagramm spezifizieren sollte, welches Modul von welchem Modul welche Daten zur Verfügung gestellt bekommt und welche es darauf basierend berechnen musste.
Auf Basis dieses Diagramms haben wir dann die Interfaces ausgetüftelt und die Klassendiagramme erstellt.
Eine Idee dahinter war auch, dass die Nächsten, die an dem Problem arbeiten, sich das Diagramm anschauen können und daran überlegen, wo sie nun ihre Änderungen einfügen müssen, und welche Module davon betroffen sind (Zum Beispiel wenn neue Daten aus den Eingaben extrahiert werden sollen die dann später irgendwo in die Ergebnisse mit einfließen)

Dann habt ihr wohl UML und OOP nicht ganz verstanden. Klassen und Objekte sollten ganz normale Objekte aus dem realen Leben darstellen. Auch Module kannst du als Klassen/Objekte darstellen und UML ist auch ganz abstrakt zu verstehen und nicht nur eingeschränkt auf eine Programmiersprache.