Braucht ihr Datenmodellierung?

[Antoras]

Hallo,

ich würde mal gerne Wissen wie oft ihr (UML-)Diagramme benötigt um darzustellen wie eure Software in der ersten finalen Version so ungefähr auszusehen hat.
Ich würde das deshalb gerne wissen, weil ich mir selbst leider nicht vorstellen kann was für einen produktiven Nutzen die Dinger haben.

Ich mein, Klassendiagramme und Diagramme mit denen ich einen Überblick über ein (Software-)Projekt bekomme sind ja noch zu gebrauchen, genauso Diagramme mit denen ich darstelle wie lange ich für ein Teil des Projektes benötige. Aber alles andere halte ich für komplett sinnlos. Frei nach dem Motto: Es ist nicht wichtig wie etwas funktioniert, sondern nur was es kann. Wozu also so Zeugs wie Sequenzdiagramme, Struktogramme usw.

 

[Tobias]

Also wenn ich mir hier so anschaue, was in den sogenannten Fachdesigns - also den Spezifiktionen des Fachbereichs, welche Funktionalität gewünscht wird - drinsteht, dann sind das meistens Sequenzdiagramme und ab und zu auch Struktogramme. Eben das, was sinnvoll ist, um einen Ablauf zu beschreiben.

Die Diagramme haben also durchaus ihre Berechtigung, man muss nur an der richtiogen Stelle danach suchen .

 

[Landei]

Ich benutze UML nur, wenn man mich dazu zwingt. Bei privaten Projekten mache ich mir eine ganz grobe Skizze für die Oberfläche und etwas, das ganz entfernt an ein Klassendiagram erinnert, aber wirklich nur das wichtigste enthält. Sonst benutze ich nichts.

 

[Tobias]

Naja, das wird hier auch nur dann gemacht, wenn es der Kommunikation dienlich und förderlich ist - und ganz gewiss auch nicht immer 1000% nach Standardnotation... Macht ja auch Sinn so.

 

[ARadauer]

auch nicht immer 1000% nach Standardnotation

ach zwei schwindlige kastln mit einem strich dazwischen aufs witheboard... fertig mehr uml braucht der entwickler nicht...

 

[Antoras]

@Tobias
Und wann ist es sinnvoll zu wissen wie der Programmablauf ist? Für mich hört sich das eher so an, dass das irgendwelche Theoriefuzzis sind, die nicht vernünftig programmieren können, aber alles perfekt ausmodellieren müssen. Und die Leute, die das Programm dann programmieren müssen ärgern sich weil es sich nicht so umsetzen lässt wie geplant. Oder macht ihr die Diagramme nach der Programmierung um zu zeigen wie weit man schon gekommen ist?

 

[Landei]

Wenn man sich zuviel Gedanken über den Programmablauf machen muss, hat man etwas falsch gemacht. Üblicherweise ist das ein Zeichen von "zu cleverem" Code. Ein Grundidee von OO ist ja gerade, dass sich die Objekte wild durcheinander-"unterhalten" können, ohne das etwas schiefgeht. Und wenn die Reihenfolge doch einmal wichtig ist, gibt es so hübsche Sachen wie Queues, Transaktionen, Fork-Join, unveränderliche Datentypen, Aktoren...

 

[Tobias]

Nö, da geht es um so Späße wie die Berechnung von fachlichen Bedingungen - z. B. Kennzahlen oder Besteuerungsvorschriften. Oft handelt es sich auch um ein State-Diagramm, mit dem gezeigt wird, von welcher Stelle der Anwendung welche anderen Stellen erreichbar sind. Sprich da malt mir einer einen etwas komplizierten fachlichen Zusammenhang ordentlich hin, damit ich eine Idee davon bekomme, was der von mir will. Wie ich das hinterher programmiere, ist dann wieder meine Sache ...

 

[Nader]

nach fast 20 Jahren OO-Programmierung habe nie UML (alles was dazu gehört) gebraucht! es gibt sowas wie Marketung Gag, die UML würde ich als Programmierung-Gag bezeichnen.

PS. ein Programm, Anwendung, Software kann man auch mit viel einfacheren Mittel dokumentieren. Und ein gut geschriebenes OO-Programm dokumentiert meistens sich selbst. Für die komplexe Anwendungsfälle mit viel Komponenten reicht auch ein Zeichnung Anwendung (Visio, PP, PB etc.) aus, um die Abhängigkeiten darzustellen.

 

[ThreadPool]

nach fast 20 Jahren OO-Programmierung habe nie UML (alles was dazu gehört) gebraucht! [...] Für die komplexe Anwendungsfälle mit viel Komponenten reicht auch ein Zeichnung Anwendung (Visio, PP, PB etc.) aus, um die Abhängigkeiten darzustellen.

Dir ist hoffentlich in den 20 Jahren aufgefallen das UML eine vereinheitlichte "Modellierungssprache" ist d.h. die Diagramme haben eine bestimmte standardisierte Syntax und drücken etwas bestimmtes aus.

Wenn du jetzt fleißig mit Visio Kästchen und Striche zeichnest tust du nichts anderes wozu man nicht auch UML verwenden würde. Nur sind deine Kästchen nicht standardisiert und man müsste falls du z.B. alle Klassen rot zeichnest nachfragen weshalb die rot sind. Unter Verwendung von UML erübrigt sich das, da wie ich es oben schon erwähnte, die "Sprache" standardisiert ist.

UML bietet eine Möglichkeit bestimmte Sachverhalte in standardisierter Syntax und Semantik zu formulieren und wie abstrakt oder wie low-level (z.B. Pseudocode) diese Sachverhalte formuliert werden liegt im Ermessen der Projektbeteiligten oder muss den Anforderungen des Kunden genügen.

 

[Nader]

Wenn du jetzt fleißig mit Visio Kästchen und Striche zeichnest tust du nichts anderes wozu man nicht auch UML verwenden würde. Nur sind deine Kästchen nicht standardisiert und man müsste falls du z.B. alle Klassen rot zeichnest nachfragen weshalb die rot sind. Unter Verwendung von UML erübrigt sich das, da wie ich es oben schon erwähnte, die "Sprache" standardisiert ist.

NEIN! die Kästchen im Visio müssen nicht UML Standard entsprechen! einer macht so andere macht anderes, hauptsache, es ist verständlich.

Um Abhängigkeiten zwischen Modulen zu zeigen, muss man also kein UML-Zeug kennen, außerdem die Diagramme sind eher für die Leute, die sich kaum für UML interressieren (Fachbereich) !

 

[UMLUser]

NEIN! die Kästchen im Visio müssen nicht UML Standard entsprechen! einer macht so andere macht anderes, hauptsache, es ist verständlich.

Genau das ist der perfekte Grund UML einzusetzen. Warum sollte man sich dazu nötigen, evtl. doch mal einem Aussenstehenden zu erklären, was das grüne Oval mit gelber Schrift sein soll, wenn sich solche Fragen mit UML gar nicht erst ergeben.

 

[homer65]

Ich habe keine Ahnung von UML. Aber nach allem was ich bisher darüber weiß, will ich mich damit auch nicht beschäftigen.

 

[Tobias]

Das wäre ziemlich dämlich. Natürlich muss man den UML-Standard nicht vollständig beherrschen, aber die grundlegenden Diagramme sollte man kennen, lesen und schreiben können. Genau wie Design Patterns ist UML nämlich vor allem eines: Eine gemeinsame Sprache zum Austausch von Ideen. Und das ist wichtig.
Das in dieser Sprache jeder seine eigenen Dialekte spricht, macht nichts, aber die zugrundeliegende Syntax und Semantik sollte verständlich bleiben.

 

[Antoras]

Um Informationen auszutauschen und bei Verständigungsproblemen näher zu beschreiben ist UML ja schon gut geeignet, aber ich hab trotzdem den Eindruck, dass das wichtiger genommen wird als es ist. Zusammenhänge zu beschreiben geht ja auch in die Richtung einen Überblick über das Programm zu bekommen, aber was es für einen Sinn haben soll jemandem zu zeigen welche Objekte nacheinander in einem Programm aufgerufen werden erschließt sich mir nicht.

@Tobias
Wenn dir jemand ein Diagramm zeigt um dir was zu erklären, dann ist das ja vollkommen ok, nur eben bei Sequnzdiagrammen wird imho nichts mehr be-, sondern vorgeschrieben. Und das braucht niemand machen wollen, der nicht vernünftig programmieren kann.
Auch bei Klassendiagrammen geht es meiner Meinung nach zu weit die Sichtbarkeit zu beschreiben. Außer dem Programmierer sollte es ja wohl niemanden interessieren, welches Objekt worauf zugreifen kann und worauf nicht.

 

[Schumi]

Wenn Du das Modell anschließend direkt zur Codegenerierung nutzt, ist es schon sinnvoll das detailiert und korrekt (inkl. zB sichtbarkeiten) zu machen, dann musst Du Dich da nämlich im Code nicht mehr mit rumschlagen.

 

[Firestorm87]

Eine gute UML-Modellierung kann durchaus Sinn machen.
Zum einen kann man damit bereits im vorwege den Umfang und die genaue Aufgabe einer jeden Klasse herausarbeiten, ohne später eventuell unnötig viel Refactoring betreiben zu müssen und zum anderen lassen sich Heutzutage die UML-Diagramme nutzen um die "rohen" Klassen und Methoden zu erstellen, so dass man dort im Nachhinein wieder ein wenig Zeit gewinnen kann....

Aber es ist und bleibt überwiegend eine Dokumentation über die Klassenabhängigkeiten im Programm....

/EDIT: Kurz am Telefon und Schwups war jmd schneller

 

[@x.l]

...aber was es für einen Sinn haben soll jemandem zu zeigen welche Objekte nacheinander in einem Programm aufgerufen werden erschließt sich mir nicht.

Weil es Zeit spart! Hast du mal versucht dich in ein bestehendes, nicht triviales Projekt einzuarbeiten? Das kann der absolute Horror sein.
Aber auch wenn man eigenen Code nach einem halben oder ganzen Jahr wieder anschaut - so fragt man sich doch manchmal: Was hab ich mir dabei nur gedacht? Und wäre froh wenn man ein aussagekräftiges Diagramm hätte.

 

[SegFault]

Also meine persönliche Meinung:
Je nachdem was man machen will, für kleine Projekte nicht unbedingt nötig aber nicht schlecht. Gerade bei der Erarbeitung dieser Diagramme merkt man schnell was man noch beachten muss. Für größere Teamprojekte ist so ein UML Diagramm sehr wichtig da es die eindeutigen Schnittstellen definiert. Ich würds mal nicht in die Ecke "Brauch ich eh nicht" schieben. Das hab ich anfangs nämlich auch gedacht bis ich eines besseren Belehrt wurde.

 

[Anyone]

Wichtig ist vor Allem, dass in der Architektur keine logischen Fehler / unsinnigen Implementierungen vorkommen. Stichpunktartige Erörterung:

Pro UML:
- Grafische und mehr oder weniger übersichtliche Darstellung - abhängig von der Komplexität
- Universalität - jeder dem UML vertraut ist kann sich schneller in die Gedankengänge einarbeiten
- Klare Strukturen, Ideen werden konzeptionalisiert
- Denkfehler können bereits mehr oder weniger bei der Modellierungsphase beseitigt werden

Contra UML:
- Zeitaufwand - manche Menschen verbringen wirklich mehrere Wochen an der Modellierung
- Over-engineering - man versucht alles zu perfektionen und bewirkt dadurch genau das Gegenteil

Fazit:

- Einzelarbeit: UML ist hilfreich, jedoch kein Muss
- Partner-, Gruppen-, Teamarbeit: UML ist ein Muss um den Projektablauf besser koordinieren zu können.

 

[Antoras]

Wenn Du das Modell anschließend direkt zur Codegenerierung nutzt, ist es schon sinnvoll das detailiert und korrekt (inkl. zB sichtbarkeiten) zu machen, dann musst Du Dich da nämlich im Code nicht mehr mit rumschlagen.

Ok, das wäre ein Argument, wobei ich nicht glaube, dass das zeitlich einen großen Unterschied macht. Bei der Generierung von Standardcode (wie z.B. Beans) ist das hilfreich, aber bei komplexeren Klassen muss ich sowieso überlegen wie ich den Code aufbaue, da kann ich mir den Umweg über UML auch sparen.
Kommt natürlich auch darauf an was für Software man produziert. Dieser Punkt ist wohl wichtiger wenn man bei kleine Projekten mitarbeitet, die nur ein paar Wochen dauern. Bei Projekten über mehrere Jahre hinweg dürfte der Zeitgewinn wohl nicht mehr erwähnenswert sein.

Weil es Zeit spart! Hast du mal versucht dich in ein bestehendes, nicht triviales Projekt einzuarbeiten? Das kann der absolute Horror sein.

Das wäre jetzt ein guter Grund Ablaufdiagramme zu benutzen. Ich musste mich bisher aber noch nie in ein komplett fremdes Projekt einarbeiten, weshalb ich das noch nicht schätzen gelernt habe. Bei Java hat man im Gegensatz zu diversen anderen Programmiersprachen ja auch noch den Vorteil, dass der Code durch die strengen Richtlinien was Objektinstanziirung und -zugriff betrifft klarer strukturiert ist (vorausgesetzt man hat vernünftig programmiert).

Ich würds mal nicht in die Ecke "Brauch ich eh nicht" schieben.

Unnötig sind sie nicht, das stimmt. Ich hab von ihnen bisher nur einen schlechten Eindruck bekommen, weil von mir immer Leute so Diagramme erwarten haben, bei denen ich den Eindruck hatte, dass sie von nichts ne Ahnung haben.

Aber ich konnte hier ja gut rauslesen, dass zu Dokuzwecken diverse Diagramme mehr oder weniger gut zu gebrauchen sind.