UML & dessen Sinnhaftigkeit
-
DEvent schrieb:
Das stimmt zwar, aber was ist einen Monat später? Kennt er dann immer noch alle Klassen auswending und welche Objekte wie kommunizieren? Die UML Diagramme haben auch eine wichtige Funktion als Dokumentation.
Also ich finde, dass Klassendiagramme eher ungeeignet sind, um die Struktur einer Anwendung zu verstehen. Im Grunde sind Klassendiagramme mit (sagen wir mal) mehr als 10 Klassen schon unübersichtlich, erst recht wenn alle Member aufgeführt sind. Eine Anwendung besteht aber nicht aus 10 Klassen, sondern je nach Größe aus hunderten oder tausenden. Da finde ich mich mit einer guten IDE im Code schneller zurecht, als dass ich die ganzen Tapeten an Klassendiagrammen studiert habe.
Es stimmt schon, dass Diagramme als erste Orientierungshilfe des Codes hilfreich sein können. Aber dafür muss das Diagramm abstrakt gehalten sein und wirklich nur das nötigste aufführen. Und vor allem muss es aktuell sein. Meistens scheitert es daran. Denn wer aktualisiert schon ständig alle Diagramme, wenn er was am Code verändert?
-
byto schrieb:
Also ich finde, dass Klassendiagramme eher ungeeignet sind, um die Struktur einer Anwendung zu verstehen. Im Grunde sind Klassendiagramme mit (sagen wir mal) mehr als 10 Klassen schon unübersichtlich, erst recht wenn alle Member aufgeführt sind. Eine Anwendung besteht aber nicht aus 10 Klassen, sondern je nach Größe aus hunderten oder tausenden. Da finde ich mich mit einer guten IDE im Code schneller zurecht, als dass ich die ganzen Tapeten an Klassendiagrammen studiert habe.
Gibt es wirklich Leute, welche Diagramme mit mehr als 10 Klassen machen und damit Wände tapezieren?
Ich verstehe UML als eine Ergänzung zur Systemspezifikation. In der Systemspezifikation beschreibst du, wie dein Code zu funktionieren hat und mit Klassendiagrammen kannst du das ganze ein wenig veranschaulichen, aber halt jeweils nur für einen kleinen Teil.Wirklich praktisch finde ich Sequenzdiagramme. Mit denen kann man sehr schön aufzeigen, wie eine bestimmte Aktion bei einem Protokoll oder ähnliches zu erfolgen hat. Zum Beispiel ein Verbindungsaufbau zu einem Server und die ersten Daten, welche ausgetauscht werden.
Grüssli
-
Stimme Dir vollkommen zu. Mein Kommentar ging in die Richtung, Klassendiagramme als Navigationshilfe für den Code zu benutzen. Das halte ich nämlich für sinnlos. Für die Spezifikation von Anforderungen in einem Pflichtenheft machen die Diagramme noch Sinn. Aber wenn die Anwendung erstmal entwickelt wird, dann sind Klassendiagramme in meinen Augen nicht mehr hilfreich. Denn wenn sie automatisch aus dem Code generiert werden, sind sie bei vielen Klassen + Membern viel zu unübersichtlich. Und wenn sie nicht automatisch generiert werden, sind sie eh ständig inkonsistent. Oder kennt ihr jemanden, der nach jeder Codeänderung Klassendiagramme aktualisiert?
Edit: Wobei es durchaus IDE Plugins gibt, die es sogar hinkriegen, abgespeckte Klassendiagramme für einen kleinen Kontext übersichtlich darzustellen. Siehe z.B. Code Navigator für Intellij IDEA: http://plugins.intellij.net/plugin/?id=3202
-
byto schrieb:
Stimme Dir vollkommen zu. Mein Kommentar ging in die Richtung, Klassendiagramme als Navigationshilfe für den Code zu benutzen. Das halte ich nämlich für sinnlos. Für die Spezifikation von Anforderungen in einem Pflichtenheft machen die Diagramme noch Sinn. Aber wenn die Anwendung erstmal entwickelt wird, dann sind Klassendiagramme in meinen Augen nicht mehr hilfreich. Denn wenn sie automatisch aus dem Code generiert werden, sind sie bei vielen Klassen + Membern viel zu unübersichtlich. Und wenn sie nicht automatisch generiert werden, sind sie eh ständig inkonsistent. Oder kennt ihr jemanden, der nach jeder Codeänderung Klassendiagramme aktualisiert?
Edit: Wobei es durchaus IDE Plugins gibt, die es sogar hinkriegen, abgespeckte Klassendiagramme für einen kleinen Kontext übersichtlich darzustellen. Siehe z.B. Code Navigator für Intellij IDEA: http://plugins.intellij.net/plugin/?id=3202
Ich aktualisiere meine Klassendiagramme. Ist ja auch nur ein klick. 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.
In jedem CASE Tool kann man z.B. die privaten Member verbergen, auto Layout machen lassen, Zoomen, Sub-Diagramme haben, usw.
Ich denke niemand klebt sich die Tapete mit Klassendiagrammen zu. Man macht ein Klassendiagramm für ein Module oder für zusammenhängende Klassen. In Java SDK wäre das z.B. die Klassen
AbstractCollection,AbstractList,AbstractQueue,AbstractSet,ArrayDeque, die List-Interfaces und dessen Implementierung wieVector,ArrayList, usw. Dies in einem Klassendiagramm zu sehen würde vieles übersichtlicher machen. Oder ein weiteres Klassendiagramm wäre alle Klassen die vonThrowableerben und im Paketjava.utilssind. Ein weiteres Klassendiagramm wäre alle Klassen die vonInputStreamerben und im Paketjava.iosind. Usw. usf.
-
DEvent schrieb:
In Java SDK wäre das z.B. die Klassen
AbstractCollection,AbstractList,AbstractQueue,AbstractSet,ArrayDeque, die List-Interfaces und dessen Implementierung wieVector,ArrayList, usw. Dies in einem Klassendiagramm zu sehen würde vieles übersichtlicher machen. Oder ein weiteres Klassendiagramm wäre alle Klassen die vonThrowableerben und im Paketjava.utilssind. Ein weiteres Klassendiagramm wäre alle Klassen die vonInputStreamerben und im Paketjava.iosind. 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?
-
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
-
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!
-
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
-
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.
-
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 wieVector,ArrayList, usw. Dies in einem Klassendiagramm zu sehen würde vieles übersichtlicher machen. Oder ein weiteres Klassendiagramm wäre alle Klassen die vonThrowableerben und im Paketjava.utilssind. Ein weiteres Klassendiagramm wäre alle Klassen die vonInputStreamerben und im Paketjava.iosind. 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.
-
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
-
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
-
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.
-
otze schrieb:
[...] ein generisches Box/Pfeil-Diagramm mit Beschriftungen an den Pfeilen.[...]
-
DEvent schrieb:
otze schrieb:
[...] ein generisches Box/Pfeil-Diagramm mit Beschriftungen an den Pfeilen.[...]
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)
-
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.
-
otze schrieb:
DEvent schrieb:
otze schrieb:
[...] ein generisches Box/Pfeil-Diagramm mit Beschriftungen an den Pfeilen.[...]
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.
