UML - Buzzword für Manager?
-
Also schrieb:
Gibts von den ganzen großen Frameworks (Java, MFC, .NET...) auch ein UML Diagramm? Ne richtige Doku sagt doch viel mehr aus als so ein UML Diagramm. Bei diesen Diagrammen sieht man doch nur wie was zusammen hängt, aber nicht was dinge machen, dazu muss man doch die Doku oder den Code selbst lesen.
Also da hast du UML zum Einen falsch verstanden und zum Zweiten siehst du es nicht richtig.
UML soll Dokumentationen nicht ersetzen sondern ergänzen. UML dient dazu, die Zusammenhänge zwischen Komponenten, Klassen, etc. zu verdeutlichen.
Ansonsten noch was: Wenn deine Funktionsnamen nicht annähernd den Sinn der Funktion wiedergeben, solltest du drüber nachdenken, ob nicht Maler nen sinnvollerer Beruf für dich wäre als Programmierer..
-
Solange man alleine an einem Projekt arbeitet, ist das ja auch noch nicht so dramatisch. Aber sobald sich ein Projekt auf mehrere Entwicklerteams aufteilt, spätestens dann ist der Nutzen imo nicht von der Hand zu weisen. Klar, wenn man alleine arbeitet, dann reicht auch der Blick in den Code, falls man mal vergessen hat, wie ein gewisses Subsystem aussieht oder wie irgendwas funktioniert. Da man den Code ja irgendwann selbst geschrieben hat, steigt man da auch recht schnell wieder durch. Aber sobald es um Programmteile geht, die Dritte entwickeln, dann hörts doch oft schon auf und man ist froh um jedes Diagramm. Zumindest geht es mir so.
-
dito @byto
-
DocJunioR schrieb:
UML soll Dokumentationen nicht ersetzen sondern ergänzen. UML dient dazu, die Zusammenhänge zwischen Komponenten, Klassen, etc. zu verdeutlichen.
Ansonsten noch was: Wenn deine Funktionsnamen nicht annähernd den Sinn der Funktion wiedergeben, solltest du drüber nachdenken, ob nicht Maler nen sinnvollerer Beruf für dich wäre als Programmierer..
Genau das ist es doch. Das UML Diagramm funktioniert, weil die Namen der Klassen aussagen, was die Klasse macht. Die einzige Zusatzinformation ist der Zusammenhang der Klassen, was aber ohne Beschreibung auch fast nix bring.
Und ich kann auch den Code bzw. die Klassen der anderen (Java, MFC) verstehen ohne so ein Diagramm.
Aber wieso bekommt man von größeren Frameworks eigentlich kein UML Diagramm zusehen? Haben die etwa keines?
-
Also schrieb:
Genau das ist es doch. Das UML Diagramm funktioniert, weil die Namen der Klassen aussagen, was die Klasse macht. Die einzige Zusatzinformation ist der Zusammenhang der Klassen, was aber ohne Beschreibung auch fast nix bring.
Nicht wirklich. Du beziehst Dich offenbar auf Klassendiagramme und die zeigen Dir nur die Struktur der Klassen und nicht, was diese Klassen machen. UML Diagramme zeigen Dir nix anderes als was der Code Dir auch sagt. Aber es ist halt eine andere Sichtweise. Du siehst z.B. grafisch, zwischen welchen Klassen es Assoziationen gibt, wie die Kardinalitäten sind etc pp. Das siehst Du auch, wenn Du in den Code guckst klar. Aber im Diagramm ist es u.U. übersichtlicher.
Und ich kann auch den Code bzw. die Klassen der anderen (Java, MFC) verstehen ohne so ein Diagramm.
Aber wieso bekommt man von größeren Frameworks eigentlich kein UML Diagramm zusehen? Haben die etwa keines?
Es geht ja weniger darum, dass Du als Endnutzer eines Frameworks dieses verstehst. Vielmehr geht es darum denjenigen die Arbeit zu erleichtern, die dieses Framework entwickeln.
-
byto schrieb:
Und ich kann auch den Code bzw. die Klassen der anderen (Java, MFC) verstehen ohne so ein Diagramm.
Aber wieso bekommt man von größeren Frameworks eigentlich kein UML Diagramm zusehen? Haben die etwa keines?
Es geht ja weniger darum, dass Du als Endnutzer eines Frameworks dieses verstehst. Vielmehr geht es darum denjenigen die Arbeit zu erleichtern, die dieses Framework entwickeln.
Das sehe ich anders. Das kann auch für Nutzer des Frameworks interessant sein.
Trotzdem gibt es natürlich nirgendwo ein Klassendiagramm der gesamten Java-Standardbibliothek als zentralen Bestandteil der Dokumentation. Die besteht aus mehreren tausend Klassen und entsprechend dürfte es auch mit einem Klassendiagramm schwer sein, sich darin zurechtzufinden. ...zumal sich die meisten Nutzer dieses Diagramm nicht ausdrucken könnten. Du kannst Dir überlegen, wie groß das wäre, vermutlich könnte man damit ne Hauswand füllen.
Was es aber gibt - und was auch sinnvoll ist - sind Klassendiagramme von bestimmten - kleinen - Bereichen der Java-Standardbibliothek. Soetwas findet man in vielen Büchern. Wenn man sich in der Java-Standardbibliothek zurechtfinden möchte, wird man das eh nicht auf einen Schlag erledigen können. Stattdessn wird man sich immer wieder kleiner Bereiche dieses Frameworks vornehmen, die es dann zu verstehen gilt.
-
Ein Diagramm der gesamten Java-Bibliothek halt ich auch nicht grade für sinnvoll. Die UML-Klassendiagramme (welche übrigens nur einer von 9 verschiedenen Typen sind) sollen Beziehungen zwischen Klassen darstellen..
Da erklär mir mal einer die Beziehung zwischen Socket und JFrame.Wie dem auch sei. Es wird sich immer an Klassendiagrammen aufgehalten. Was ist mit Use-Case-Diagrammen? Komponentendiagrammen oder Sequenzdiagrammen? Da fängt der Spaß ja eigentlich an..
-
Da wollt ihr ein UML Diagramm immer, um den Überblick über ein großes Projekt zu haben, aber wenn das Projekt zu groß ist, dann taugt UML dafür nicht mehr, hmm...
Komponentendiagramm ist OK, obwohl es nicht UML sein muss, eigentlich reichen ein paar Kästchen und Verbindungslinien. Ob da jetzt Pfeile, Knuppel oder sonstwas dran sind, ist doch egal, da der Text doch mehr aussagt.
Usecasediagramm wäre oft ganz schön, aber meistens wissen die Kunden doch noch nicht so genau was sie wollen bzw. wie das dann ablaufen soll.
Sequenzdiagramme haben ein bisschen was von Struktogrammen, entweder sie sind so detailiert, dass man sich gleich den Code anschauen hätte können, oder sie sagen das aus, was man sich sowieso denken hätte können. Manchmal sind sie gut.
-
Also schrieb:
Da wollt ihr ein UML Diagramm immer, um den Überblick über ein großes Projekt zu haben, aber wenn das Projekt zu groß ist, dann taugt UML dafür nicht mehr, hmm...
Nein, im Gegenteil. Gerade bei großen Projekten ist der Einsatz von Diagrammen zur Visualisierung sinnvoll. Aber es macht halt wenig Sinn, z.B. ein Klassendiagramm des gesamten Projekts anzulegen, weil dieses sehr unübersichtlich wäre. Stattdessen macht man halt Teildiagramme der einzelnen Subsysteme oder Komponenten oder whatever. Ob man das nun mit UML oder einer anderen Modellierungssprache macht, ist im Grunde egal. Hauptsache alle Entwickler im Umkreis "sprechen die gleiche Sprache", damit es nicht zu Mißverständnissen kommt. UML ist dabei halt am weitesten verbreitet...
Komponentendiagramm ist OK, obwohl es nicht UML sein muss, eigentlich reichen ein paar Kästchen und Verbindungslinien. Ob da jetzt Pfeile, Knuppel oder sonstwas dran sind, ist doch egal, da der Text doch mehr aussagt.
Das trifft vielleicht zu, wenn man der einzige ist, der diese Diagramme dann verwendet. Sobald jemand anders diese Diagramme zu Gesicht bekommt, sollte die Sprache schon wohl definiert sein, um Mißverständnisse zu umgehen.
Usecasediagramm wäre oft ganz schön, aber meistens wissen die Kunden doch noch nicht so genau was sie wollen bzw. wie das dann ablaufen soll.
Es müssen ja nicht die Kunden sein, die Dir ihre Anforderungen in Form von Use Cases näher bringen. Im Gegenteil: DU kannst mit Hilfe von Use Cases die doch häufig Schwammig formulierten Anforderungen formalisieren und Dich somit auf einen klaren Anforderungskatalog mit dem Kunden einig werden. Deswegen sind die Uses Cases ja so schön simpel gehalten, dass sie quasi jeder verstehen kann.
Sequenzdiagramme haben ein bisschen was von Struktogrammen, entweder sie sind so detailiert, dass man sich gleich den Code anschauen hätte können, oder sie sagen das aus, was man sich sowieso denken hätte können. Manchmal sind sie gut.
Dazu habe ich ja oben schon was geschrieben. Wenn man den Code selbst geschrieben hat, dann braucht man sicherlich kein Sequenzdiagramm, um das Verständis aufrecht zu erhalten. Da kann man bei Bedarf einen Blick in den Code werfen und ist wieder auf der Höhe. Aber spätestens wenn mehrere Entwicklerteams zusammenarbeiten, dann werden diese Diagramme interessant. Sagen wir, die Subsysteme A, B und C sollen nun miteinander kommunizieren. Jedes Subsystem ist von einem anderen Team entwickelt worden. Dann kann man die Beispielabläufe wunderbar in Sequenzdiagrammen formulieren, ohne dass sich jedes Team erst durch den Code der anderen wühlen muss. Im Gegenteil: Die Implementierung der anderen braucht und soll sie gar nicht interessieren. Was interessiert, sind die Schnittstellen sowie Art und Ablauf der Kommunikation.
-
byto schrieb:
Sequenzdiagramme haben ein bisschen was von Struktogrammen, entweder sie sind so detailiert, dass man sich gleich den Code anschauen hätte können, oder sie sagen das aus, was man sich sowieso denken hätte können. Manchmal sind sie gut.
Dazu habe ich ja oben schon was geschrieben. Wenn man den Code selbst geschrieben hat, dann braucht man sicherlich kein Sequenzdiagramm, um das Verständis aufrecht zu erhalten. Da kann man bei Bedarf einen Blick in den Code werfen und ist wieder auf der Höhe. Aber spätestens wenn mehrere Entwicklerteams zusammenarbeiten, dann werden diese Diagramme interessant. Sagen wir, die Subsysteme A, B und C sollen nun miteinander kommunizieren. Jedes Subsystem ist von einem anderen Team entwickelt worden. Dann kann man die Beispielabläufe wunderbar in Sequenzdiagrammen formulieren, ohne dass sich jedes Team erst durch den Code der anderen wühlen muss. Im Gegenteil: Die Implementierung der anderen braucht und soll sie gar nicht interessieren. Was interessiert, sind die Schnittstellen sowie Art und Ablauf der Kommunikation.
Dazu gibts dann eine Schnittstellenbeschreibung, da brauch ich kein Sequenzdiagramm.
byto schrieb:
Usecasediagramm wäre oft ganz schön, aber meistens wissen die Kunden doch noch nicht so genau was sie wollen bzw. wie das dann ablaufen soll.
Es müssen ja nicht die Kunden sein, die Dir ihre Anforderungen in Form von Use Cases näher bringen. Im Gegenteil: DU kannst mit Hilfe von Use Cases die doch häufig Schwammig formulierten Anforderungen formalisieren und Dich somit auf einen klaren Anforderungskatalog mit dem Kunden einig werden. Deswegen sind die Uses Cases ja so schön simpel gehalten, dass sie quasi jeder verstehen kann.
Machst du das so oder hast du gelernt, dass man es so machen soll?
-
Ich merk schon, die Diskussion ist sinnlos. Viel Spaß weiterhin beim Programmieren.
Cheers, byto
-
-
kartoffelsack ausgeloggt schrieb:
Zum ganze modell-driven-design zeug, würd mich interessieren, ob das wirklich irgendwo erfolgreich und in großem Stil eingesetzt wird. Meine Meinung zum Nutzen ist zwiespältig, insbesondere kenn ich aber auch niemanden konkret (oder in nem Forum, außer irgendwelche Leute die in irgendwelchen Magazinen irgendwelche Artikel schreiben) der sagt, dass das in Seiner Firma gemacht wird und der ne echte Meinung dazu haben kann.
Habe ich gerade per Email bekommen:
http://software-families.org/programm.htmlWenn es euch noch interessiert...
Die 150,- € Teilnehmergebühr kann sich auch ein Student leisten und wenn nicht - vielleicht ist der Eisenecker verhandlungsbereit ...
Aufgrund der knappen Zeitfenster wird es wohl nur eine Einführungsveranstaltung werden. Aber man lernt die Leute kennen, die wirkliche Korifeen auf diesen (Teil-)Gebiet sind und kann die Grenzen zwischen Theorie und Praxis kennenlernen und unterscheiden.