UML & dessen Sinnhaftigkeit
-
Moin moin,
im Zuge meiner Ausbildung kauen wir in der Schule momentan - und voraussichtlich auch noch für das nächste halbe Jahr - das Thema "UML" durch.
Da ich persönlich wenig bis gar nichts von der ganzen Modellierungssoftware halte und auch betrieblich noch nie dazu angehalten wurde, solche zu verwenden, an dieser Stelle ein paar Fragen:-
Wie wird das bei euch in der Planungsphase eines kleinen/größeren Projekts gehandhabt? Kommt hier UML (bzw. Derivate davon oder gänzlich andere Modellierungssoftware) zum Einsatz oder wird der Entwurf - so wie es bei mir im Betrieb meist passiert - im Kopf arrangiert? Und wie viel Zeit verschlingt solch ein Entwurf? Bzw. darf er maximal?
-
Gibt es wirklich einen Vorteil für die "Prämodellierung" einer Software durch Konstrukte wie UML? Ich sehe in der Schule - wobei dies natürlich nicht gerade als Vorzeigefall zu betrachten ist - dahingehend immer wieder das Problem, dass besonders die Umsetzung vom Modell in die konkrete Sprache seine Tücken hat, da sprachspezifische Hürden in UML - da zu abstrakt - nicht betrachtet werden können. Wieso dann nicht gänzlich ein konkretes Modell einsetzen, bei dem man die Schwachpunkte der Sprache von Anfang an in das Modell einfließen lassen kann, aber jenes auch gleich umsetzen kann?
Ich persönlich muss jedenfalls immer etwas schmunzeln, wenn der Lehrer getreu dem Motto "Modellierung über alles" das Bild vom Softwarentwickler zeichnet, der in Visio stundenlang irgendwelche Kästchen verbindet und sich freut, wenn er gleich den richtigen Pfeiltyp gefunden hat. Wie sieht das in der Realität aus?
-
-
Die Modellierung hat dann Vorteile, wenn du zum Beispiel dem Kunden nach dem ersten Vorgespräch schonmal was vorlegen willst, wie du dir das ganze vorstellst, ohne unnötig technisch zu werden.
Es hilft auch dabei, bei größeren Projekten den Überblick zu behalten und das, was in Besprechungen nur dahergeredet wurde, in einer verwertbaren Form aufzubewaren (gerade, wenn später Uneinigkeit darüber herrscht, was alles besprochen war, und was nicht)
Wie du das ganze im Endeffekt genau darstellst, bleibt dir bzw. dem Teamleiter überlassen. Die UML bietet dafür nur standardisierte Diagramme, die allgemein so auch gleich verstanden werden
-
In der Realität hast du erst die Use Cases. Im Grunde eine Beschreibung was dein Programm machen soll, bzw. kann. Danach hast du erst mal machst du dir bei GUI Programmen eine Skizze der GUI.
Dann kannst du mit dem Klassendiagramm anfangen. Gute Tools können auch gleich den Code erstellen (nennt sich Round-Trip, weil man aus dem Diagramm die Klassen erstellen kann und dann umgekehrt Änderungen im Code wieder in das Diagramm zurück modellieren kannst).
Wenn du eine Datenbank brauchst kannst du dir ein ORM Diagramm zeichnen und daraus z.B. MySQL Code erstellen lassen kannst. Aus dem ORM Diagram erstellt du dir das Klassen-Diagramm (Tabelle <> Klasse) für eine Persistenz-Bibliothek wie z.B. Hibernate.
Wenn du dann die Klassen und Methoden hast, erstellt du das Sequenz-Diagram oder Communication-Diagramm damit du weist wie die Objekte miteinander Nachrichten austauschen. Es stehen dir noch ein Dutzend andere Diagramme zur Verfügung, aber ich denke Use Case, Class Diagramm und Sequenz Diagramm sind die wichtigsten 3.
Wichtig ist es immer die Diagramm aktuell zu halten. Deswegen ist ein gutes UML-Tool unerlässlich, dass Code generieren und aus dem Code das Diagramm aktualisieren kann.
-
Matzer schrieb:
- Gibt es wirklich einen Vorteil für die "Prämodellierung" einer Software durch Konstrukte wie UML?
Ich sehe das in vielen Teilen auch mit Vorbehalt, aber es gibt gute Anwendungsmöglichkeiten von Sequenz- und Interaktionsdiagrammen beim Zusammenspiel von unterschiedlichen Gewerken.
Es stimmt schon, ein guter und erfahrener Entwickler braucht kein UML-Klassendiagramm, wenn er Code schreibt sieht er das auch direkt.
Aber schon eine einfache Software, die z.B. einen Bediener und eine Maschine (die ebenfalls eine Software besitzt) kann mit UML in der Spezifikation an Deutlichkeit gewinnen, noch dazu wenn man mit 3 Lieferanten zu tun hat. Dadurch wird erklärbar, was in welcher Reihenfolge zu tun ist.
Auch haben wir großen Erfolg damit bei der Erstellung der Arbeitsanweisungen - denn jede Fraktion erstellt entlang "ihres" Pfades ihr Applikationsverhalten. Jetzt denken die Entwickler wieder nur an Software, aber man muß z.B. für Bediener ja auch schriftliche Anweisungen (Pfeile, Schilder, etc) entwerfen. Hat man daher die UML-Abläufe, so kann man auch hier die notwendigen Anleitungen und Dokumente ableiten.
Ebenso kann man in der Diskussion mit dem Kunden deutlich machen, was eigentlich geschehen soll, hilfreich sind die Diagramme dann, wenn man es mit Nicht-Softwerkern zu tun hat. Z.B. haben wir im letzten Projekt auch Logistik-Abläufe - die nur zu 50% in der Software laufen und sonst auch so Sachen wie "Werker klebt Etikett auf Kiste" enthält - mit Sequenzdiagrammen dargestellt, oder Qualitätsprüfpläne. Das geht eher in Geschäftslogik rein, war aber sehr hilfreich: auch die Mechaniker haben das schnell verstanden und die Zusammenarbeit und Diskussion wurde dramatisch vereinfacht.
Aber ganz klar, für viele Programme ist sowas wirklich Overkill, man muß für eine TCP/IP-Kommunikation kein Sequenzdiagramm pinseln.
-
Marc++us schrieb:
Es stimmt schon, ein guter und erfahrener Entwickler braucht kein UML-Klassendiagramm, wenn er Code schreibt sieht er das auch direkt.
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.
-
UML braucht man meiner Meinung nach wenn man irgendwelche Schnittstellen definiert, die später einmal von anderen genutzt werden sollen. Oder wenn man irgendwelche komplizierten Protokolle für irgendetwas entwirft.
Ansonsten braucht man nur Use-Case-Diagramme um zu verstehen was der Kunde eigentlich will und Klassendiagramme um die Übersicht zu behalten.
Das wesentliche ist, das diese helfen können fremden Code zu verstehen, wenn sich derjenige die Mühe gemacht hat wirklich welche anzuwenden. Und für die theoretische Forschung. Vieleicht erfindet Jemand der UML Diagramme kennt ja noch irgend ein weiteres was man für irgendwas brauchen kann
Daher sollte man die kennen, damit man sie lesen kann wenn es erstellet gibt, welche erstellen kann wenns wirklich nötig ist und man sie nicht ausversehen nochmal in schlechterer Form neu erfindet
-
MisterX schrieb:
Ansonsten braucht man nur Use-Case-Diagramme um zu verstehen was der Kunde eigentlich will und Klassendiagramme um die Übersicht zu behalten.
Use Case Diagramme sind ziemlich unwichtig. Ein Use Case ist eine detaillierte Beschreibung (in Textform) der Funktion der Software und wie ein Akteur mit der Software interagieren kann.
-
Matzer schrieb:
-
Wie wird das bei euch in der Planungsphase eines kleinen/größeren Projekts gehandhabt? Kommt hier UML (bzw. Derivate davon oder gänzlich andere Modellierungssoftware) zum Einsatz oder wird der Entwurf - so wie es bei mir im Betrieb meist passiert - im Kopf arrangiert? Und wie viel Zeit verschlingt solch ein Entwurf? Bzw. darf er maximal?
-
Gibt es wirklich einen Vorteil für die "Prämodellierung" einer Software durch Konstrukte wie UML? Ich sehe in der Schule - wobei dies natürlich nicht gerade als Vorzeigefall zu betrachten ist - dahingehend immer wieder das Problem, dass besonders die Umsetzung vom Modell in die konkrete Sprache seine Tücken hat, da sprachspezifische Hürden in UML - da zu abstrakt - nicht betrachtet werden können. Wieso dann nicht gänzlich ein konkretes Modell einsetzen, bei dem man die Schwachpunkte der Sprache von Anfang an in das Modell einfließen lassen kann, aber jenes auch gleich umsetzen kann?
Ich glaub du (oder dein Lehrer) haben en kleines Verstaendnisproblem: du verwendest nicht UML um deine Software zu entwerfen, sondern nur um den Entwurf dann (in standardisierter Form) festzuhalten.
Demzufolge wird der Entwurf eigentlich immer "im Kopf arrangiert", nur wird danach noch gesagt "so, um nicht zu vergessen was wir da entworfen/besprochen haben, schreiben wir's noch schnell nieder". Und dann wirds halt in UML niedergeschrieben, weil das eine standardisierte Sprache ist (d.h. jeder sollte es verstehen) und weils dafuer auch nette Tools gibt (d.h. du kannst aus dieser Dokumentation z. T. automatisch Code generieren etc.).
Deshalb ists auch keine "Praemodelierung", sondern eher reine Dokmentation, die von einer konkreten Sprache unabhaengig ist. Der Vorteil: auch Leute, die jetzt z. B. keine C++ Gurus sind, koennen das grobe Design schnell ueberblicken (ohne sich lang durch den Code zu wursteln). Umsetzungsprobleme UML <-> Konkrete Implementierung haette ich noch nie so wirklich gesehen, kannst mal ein Beispiel machen?
-
-
DEvent schrieb:
Marc++us schrieb:
Es stimmt schon, ein guter und erfahrener Entwickler braucht kein UML-Klassendiagramm, wenn er Code schreibt sieht er das auch direkt.
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.
Darum sind die ganzen Dokus von OO-Programmen und Libraries auch alle voll von UML-Diagrammen. Also so wichtig kanns nicht sein...
-
DEvent schrieb:
Marc++us schrieb:
Es stimmt schon, ein guter und erfahrener Entwickler braucht kein UML-Klassendiagramm, wenn er Code schreibt sieht er das auch direkt.
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.
Ist doch kein Problem. Ich hab mich schon in Unmengen an Code von anderen Leuten eingelesen, ohne das es ein UML Diagramm gab.
-
Ich glaub du (oder dein Lehrer) haben en kleines Verstaendnisproblem: du verwendest nicht UML um deine Software zu entwerfen, sondern nur um den Entwurf dann (in standardisierter Form) festzuhalten.
Bei uns stand der Entwurf in UML zeitlich bislang immer vor der reinen Programmierung, die sich dann natürlich an den Diagrammen orientierte. Natürlich kann es hierbei auch nur um eine didaktische Vorgehensweise des Lehrers handeln, allerdings haben wir den umgekehrten Fall noch nie erprobt.
Andererseits verstehe ich dann aber die Fixierung auf UML, besonders in der Fachrichtung Anwendungsentwicklung, in den Berufsschulen nicht. Soweit ich weiß, wird UML mich auch noch das restliche Jahr begleiten und einen Schwerpunkt in der Abschlussprüfung bilden. Und sicherlich ist Dokumentation ein wichtiger Punkt, aber diese in den Mittelpunkt zu rücken finde ich falsch. Ich weiß am Ende der Ausbildung dann zwar, wie ich einen Algorithmus in einem schönen Diagramm darstellen kann, allerdings nicht wie ihn bildeDer Vorteil: auch Leute, die jetzt z. B. keine C++ Gurus sind, koennen das grobe Design schnell ueberblicken (ohne sich lang durch den Code zu wursteln)
Ich persönlich würde eine C++-artige Notation der von UML vorziehen ;). Im Ernst, einige Konstrukte im UML sind doch sehr an die Notationen in diversen Programmiersprachen angelehnt. Ich denke hierbei an solche Sachen wie die extends- und include-Beziehungen in den Anwendungsfalldiagrammen. Und obwohl diese sich noch auf einer noch abstrakteren Ebene im Prozessablauf als beispielsweise die Klassendiagramme befinden, kommen sie mir doch zu "kryptisch" vor, um auch für einen Laien sofort ersichtlich zu sein.
Klar ist die Einarbeitungszeit in eine "abstrakte Sprache" wie UML einfacher, aber mit wachsender Größe der Projekte nehmen sich doch eine anständige, z.B. mit Doxygen generierte Dokumentation und die Diagramme aus UML nicht mehr viel - jedenfalls was die Softwaremodellierung angeht.
-
Matzer schrieb:
Ich glaub du (oder dein Lehrer) haben en kleines Verstaendnisproblem: du verwendest nicht UML um deine Software zu entwerfen, sondern nur um den Entwurf dann (in standardisierter Form) festzuhalten.
Bei uns stand der Entwurf in UML zeitlich bislang immer vor der reinen Programmierung, die sich dann natürlich an den Diagrammen orientierte. Natürlich kann es hierbei auch nur um eine didaktische Vorgehensweise des Lehrers handeln, allerdings haben wir den umgekehrten Fall noch nie erprobt.
Andererseits verstehe ich dann aber die Fixierung auf UML, besonders in der Fachrichtung Anwendungsentwicklung, in den Berufsschulen nicht. Soweit ich weiß, wird UML mich auch noch das restliche Jahr begleiten und einen Schwerpunkt in der Abschlussprüfung bilden. Und sicherlich ist Dokumentation ein wichtiger Punkt, aber diese in den Mittelpunkt zu rücken finde ich falsch. Ich weiß am Ende der Ausbildung dann zwar, wie ich einen Algorithmus in einem schönen Diagramm darstellen kann, allerdings nicht wie ihn bildeIch meinte mit "Dokumentation" nicht nur die endgueltige Doku, wenn das Programm fertig ist, sondern jede Art, Programmdesign auf Papier festzuhalten, also z. B. auch als Spezifikation.
Als FIAE (ich nehm mal an das ist deine Ausbildung) bist du ja letztendlich der, der den Code schreibt/implementiert, obwohl in womoeglich wer anderer (z. B. ein SW-Architekt) designt hat. Und UML ist eine der Moeglichkeiten, dir das Design zu erklaeren/zu spezifizieren, was du implementieren sollst. Besonders in grossen Firmen, wo der SW-Architekt und der Implementierer womoeglich nichtmal auf dem gleichen Kontinent arbeiten, ists wichtig, dass das reibungslos funktioniert. Und deshalb ists wichtig, dass du UML-Diagramme verstehen und in Code umsetzen kannst (Oder dass du spaeter mal in gehobener Position faehig bist, dein Design in UML so auszudruecken, dass andere es verstehen/umsetzen koennen).
-
Blue-Tiger schrieb:
Und deshalb ists wichtig, dass du UML-Diagramme verstehen und in Code umsetzen kannst (Oder dass du spaeter mal in gehobener Position faehig bist, dein Design in UML so auszudruecken, dass andere es verstehen/umsetzen koennen).
das wären ja finstere Aussichten. Glaube aber nicht, dass es so selten ist, sein eigener SW-Architekt zu sein.
-
Matzer schrieb:
Ich persönlich würde eine C++-artige Notation der von UML vorziehen
das wäre ja ein ding. kannst dir ja mal sowas ausdenken. *fg*
-
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.
Wenn man ein monolithisches Programm in einer Sprache erstellt, macht die parallele Dokumentation oder Aufbereitung in UML tatsächlich keinen Sinn. Sobald man aber über Gewerke- oder Systemgrenzen hinweg geht, bekommt das schon an einigen Stellen Gewicht.
-
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?
