Das Argument der Sprachunabhängigkeit zieht nur seeehr bedingt. Ich kann mir kaum vorstellen, dass jemand ein UML-Diagramm malt, ohne zumindest implizit schon stark eingerenzt zu haben, um welche Sprache es geht. Nicht zuletzt weil die Frage von „Best Practices“ im Sinne des Klassendesigns auch stark von der Sprache abhängt. D.h. ich denke, dass die Struktur und einige Details der Frage, was in dem UML-Diagramm auftacht, z.B. davon abhängt, ob man irgendwas in C++ mit templates macht, oder in Java mit Generics - natürlich sind das eher Details, bezogen auf „den Stil“, ~„wie man z.B. Vererbung einsetzt“, aber nicht komplett irrelevant.
Ich wüsste nicht warum du in UML länger brauchen solltest bei deinem 60 Sekunden-Beispiel. Du tippst ja genau das Gleiche.
Welches Tool? Frei für kommerzielle Nutzung? Wie viel Lernaufwand? Was kostet eine Lizenz? In welchem Dateiformat wird das gespeichert? …
Hab’ hier ein bißchen aufgeräumt. Weiteres „Bäh-bäh-selba-dohf“ werde ich entsprechend unkommentiert löschen. Ggf. werde ich den Teil, bei dem es (dann, hoffentlich, nur noch) um die Frage nach dem „Sinn und Nutzen von UML bei der Softwareentwicklung“ ( ← Titel) geht, abtrennen.
Ich glaube nicht, dass UML-Klassendiagramme wesentlich zum RoI beitragen. Denn meines Erachtens ist der Detaillierungsgrad von Klassendiagrammen viel zu hoch und auf Klassenebene ändert sich eine Software viel zu schnell. Ich finde UML-(artige-)Klassendiagramme schon ganz gut zur Visualisierung, aber eher so wie im Threadtitel genannt. Nämlich um aus dem Code ein Diagramm zu erzeugen und dann auf die für die Diskussion relevanten Teile einzukürzen. In der Regel nutze ich die Diagramme dann auch in gekürzter Form und lasse dann bspw. nur die Klassen und Beziehungen darstellen, unwesentliche Felder etc. bleiben außen vor.
Kennt hier jemand das C4 Model? Da geht es darum wie man Softwaresysteme visuell designen kann. Das kann man sich so vorstellen, dass man nach und nach immer weiter rein zoomt.
Das erste C ist der System Context. Hier betrachtet man mit was für anderen Systemen mein System zusammen spielt und wie welche User damit interagieren.
Das zweite C sind dann Container. Dabei geht es darum aus welchen Bestandteilen besteht mein System, in einer Microservice-Welt sind dass die einzelnen Services. Aber es können auch Datenbanken, externe Webservices, Message-Queues, etc. sein.
Das dritte C sind die Componenten. Hier zoomt man in einen einzelnen Container rein und beschreibt dann davon die einzelnen Bestandteile auf einen relativ groben Level.
Das letzte C ist dann Code. Hier geht es um die Art von Diagrammen über die wir hier diskutieren. Interessant finde ich dabei was C4 darüber sagt:
This is an optional level of detail and is often available on-demand from tooling such as IDEs. Ideally this diagram would be automatically generated using tooling (e.g. an IDE or UML modelling tool), and you should consider showing only those attributes and methods that allow you to tell the story that you want to tell. This level of detail is not recommended for anything but the most important or complex components.
Für mich bedeutet das, dass man den Code kennen soll, den man zeigen will. Bei diesen Diagrammen geht es nicht um upfront Design, sondern das soll zeigen was im Code da ist. Die anderen Cs sind für das Designen von Systemen interessanter.
Hab ich schon mal in echt gesehen (ja, man schreibt „in echt“ als Redewendung für „wirklich“ laut Duden klein…). Das wird gerne von Bwlern verwendet, die eine grobe Sicht auf das System haben wollen (wir haben 5000 Mitarbeiter (von denen niemand etwas von Informatik versteht), wenn sie hier arbeiten möchten, müssen sie jede Komponente verstanden haben (oder so ähnlich)).
Ich finde es auch passender, als irre große UML-Klassendiagramme mit irre langen Klassen zu haben. In echt wird man detaillierte Klassendiagramme auch nur noch selten antreffen.