HowToCode: Braucht man UML?
Ich bin gerade auf den sehr schicken Dienst yUML.me gestoßen bei dem man sehr nette UML Diagramme über eine URL generieren kann. Den Dienst finde ich prinzipiell nett, aber eigentlich wüsste ich nicht wann ich richtiges UML in der Praxis eingesetzt habe. Braucht man UML?
yUML
yUML.me ist ein cooler Dienst um Klassen, Aktivitäts & Use Case UML Diagramme zu erzeugen. Es gibt für Unternehmen sogar eine Version die man im Firmenumfeld installieren kann. Eigentlich ziemlich cool gemacht und die Diagramme sehen auch nett aus 
Braucht man UML?
In meiner (noch recht kurzen) Zeit als Softwareentwickler hatte ich noch nie den Drang hochkomplexe UML Diagramme zu erzeugen. Meistens schmier ich Klassen oder Use Case Diagramm ähnliche Konstrukte ans Whiteboard oder male diese mit Powerpoint.
Powerpoint-Architekt
Obwohl Powerpoint nicht gerade die erste Wahl für die Architektur von Software scheint, seh ich doch wesentlich mehr “Powerpoint-Blöcke” wie die Architektur einer Software gemacht ist als “richtige” UML Diagramme.
Beobachtung
Ich selbst habe kein Studium, sondern nur eine Berufsausbildung gemacht. Bereits während der Ausbildung fand ich UML zwar nett, aber schrecklich oversized. Allein der “Syntax” hat mich bei den Diagrammen zum Teil gestört (Wie war die Pfeilrichtung? Ist das jetzt “extend” oder “include”?). Meistens haben es simple, aber effektive Skizzen auch getan. Einige Studenten schwärmen hingegen von UML und das dies die Übersichtlichkeit erhöht, aber ist es denn so oder ist das nur graue Theorie?
UML vs. TDD?
In einem Buch hatte ich mal den Vergleich von UML und Bauplänen gelesen. Dort wurde das Argument vorgebracht, dass man für einen Hausbau natürlich einen kompletten Bauplan braucht, weil es wesentlich komplexer ist und länger dauert ein Haus zu bauen als ein “Rohbau” der Softwarearchitektur. In wenigen Stunden kann man schonmal grob herausfinden ob die Richtung stimmt. TDD spielt besonders seine stärken aus, wenn ich eine API mir überlege möchte (Test Driven Design). Ein UML Plan zu machen dauert wahrscheinlich ebensolange wie dies mal in einer TDD Session auszuprobieren.
UML veraltet schnell
Ich stell mal die provokante Behauptung auf, dass ein UML Diagramm schnell veraltet, wenn es einmal nach mühevoller Arbeit erstellt wurde. Ohne einen strengen Prozess der sicher geht, dass die UML Diagramme mit der Realität übereinstimmen kann man sich die Arbeit auch sparen, oder?
Eine gute Architektur sollte auf einer Serviette platz finden
Ralf Westphal hat mal einen netten Blogpost darüber geschrieben. Eine gute Architektur sollte auch auf einer Serviette verständlich platz finden. Seh ich auch so
Fazit
Ich will nicht behaupten UML sei nutzlos, aber ich habe in meinen Projekten noch nie den Drang verspürt erstmal alles als UML Diagramm zu malen. Wenn man es grafisch (wie z.B. in VS2010) nett aufbereitet, dann bringt das natürlich nutzen. Ohne Tooling find ich UML schrecklich kompliziert gemacht. Wahrscheinlich ist es mit den passenden Tools nett, aber bis es soweit ist werde ich weiterhin einfache “Powerpoint-Architekturen” ans Whiteboard malen anstatt wilde UML Zeichnungen
yUML ist damit zwar eine coole Idee, macht es aber nicht einfacher die Dinger zu zeichnen.
Wie ist eure Meinung? Nutzt ihr UML? Warum? Wie haltet ihr diese aktuell? Bin ich vielleicht von allen guten Geistern verlassen und sehe den Nutzen nicht?
About the author
Written by Robert Mühsig
Robert Mühsig (@robert0muehsig) ist Webentwickler und beschäftigt sich mit Web-Frameworks (vor allem dem ASP.NET MVC Framework) und scheut sich auch nicht vor Javascript. Ansonsten bloggt er über all jene Probleme, die ihm über den Weg laufen. Seit 2008 ist er Microsoft MVP für ASP.NET und er arbeitet bei der T-Systems Multimedia Solutions GmbH in Dresden. Treffen kann man ihn online via Twitter (@robert0muehsig) oder dieser Seite oder bei der .NET User Group Dresden.
Jan Welker
19. March 2010
Hallo Robert,
ich meine, wenn eine große und wichtige Software über viele Jahre eingesetzt werden soll, sollte sie so ausführlich wie möglich geplant und dokumentiert werden. Kannst du die eine Steuerung für eine Dampfturbine, oder die Beschreibung eines Datenübertragungsprotokolls auf einer Serviette vorstellen? Zu solch einer Doku gehört auch UML.
Im schnelllebigen Webgeschäft macht UML und eine ausführliche Doku meiner Meinung nach nicht viel Sinn.
Mein Fazit: Bei agiler Entwicklung ist UML sehr schwierig umsetzbar und macht wenig Sinn.
Bei nicht agiler Entwicklung mit Pflichtenheft usw. gehört es dazu.
Grüße,
Jan
Torsten Hufsky
20. March 2010
Hallo Robert,
sehe das so ähnlich wie Jan.
In klassischen Projekten bringt UML eigentlich mehr Nutzen als Frust. Teilweise kann UML besser lesbar sein als zum Beispiel Consultant Deutsch. Nein das ist sogar der eigentliche Nutzen von UML, da es ja eine standardisierte Sprache ist, an die jede Zielgruppe kennt.
Ich bin jedoch der festen Meinung, dass eine ausführliche Doku immer Sinn macht, egal ob Webprojekt oder Softwareentwicklung. (kann evtl. Kundenspezifisch sein).
VG,
Torsten
Ilker Cetinkaya
22. March 2010
Ein besonders interessanter Artikel, mit einer provokanten Überschrift und zwei für mich hervorstechenden Themen.
Ich möchte zunächst von mir selbst berichten, um Deine Fragen zu beantworten: Ja, ich nutze UML, besonders in Design-Phasen. Ich nutze UML, um die Kundenanforderungen bzw. -Domäne besser zu verstehen. Ich nutze UML, um Patterns innerhalb von Systemen zu erkennen. Doch ganz besonders oft nutze UML, um anderen (und mir selbst) Ideen oder Designs verständlich zu zeigen oder zu erklären.
Ich nutze UML nicht als Referenz, sondern als “Malsprache” – zumindest versuche ich es. Ich komme auch ab und zu z.B. bei Aktivitätsdiagrammen nicht ganz zurecht. “Soll ich jetz abgerundete Ecken verwenden oder nicht?” denke ich mir schon ab und an, wenn ich wieder Kästchen male. Aber für mich ist “Konformität” nicht entscheidend. Es ist schön, wenn man es bei einem Tool so schön als Toolbox drin hat. Aber beim Malen auf ‘nen Flipchart ist es nicht so besonders wichtig, ob jetz’ die Zeichnung UML2-compliant ist oder nicht.
Besonders hilfreiche Diagramme finde ich Use Case, Activity, Class, Sequence, Component & Deployment.
Ich möchte Jan & Torsten unterstützen mit der Aussage, das in manchen Situationen UML nicht nur als “Malsprache”, sondern auch als Referenz bzw. Dokumentation notwendig & hilfreich sein kann. Ich habe eine professionelle UML-Referenz über ein Jahr lang lesen dürfen und fand es hilfreich.
Nun zu den Punkten, bei denen ich etwas mehr nachdenken musste/wollte.
1. UML vs TDD: Das sehe ich nicht so. TDD ist ein anderes Mittel und Werkzeug, um Implementierung zu designen. Es eignet sich vor allem auf mikroorganisatorischer Ebene – dort, wo nicht mehr viel Abstraktion zu erwarten ist.
Komplexere Systeme, ganze Anwendungen oder sogar mehrere Anwendungen im Verbund per TDD zu designen ist nicht zielführend. UML kann dort schon helfen. UML ist zwar auch dort kein “Allheilmittel” – aber es hilft.
TDD setze ich natürlich wesentlich öfter ein. Einfach weil ich halt viel mehr programmiere als mir zuviel theoretische Gedanken zu machen. UML ist mehr für das abstraktere, das größere.
2. Die Servietten-Architektur: Nein. Niemals. Eine gute Architektur hat meiner Meinung nach nichts mit der Größe eines Diagrammes zu tun. Ein Diagramm – vor allem ein UML Diagramm – kann und will nur eine bestimmte Perspektive der Architektur abbilden. Meistens sogar auf einer besonderen Abstraktionsstufe und oft auch nur partiell. Das ist auch gut so. Aber dass man 4 Kästchen auf eine Serviette packt und sie dann als “Layered Architecture” verpackt – nee, des isses wohl nicht.
näthi
15. April 2010
In erster Linie sollte man nicht UML für sich designen sondern für die anderen Entwickler die an dem Projekt arbeiten!
Wirklich gebraucht habe ich UML auch noch nicht, es fallen nur mache Sachen einfach leichter damit.
von yUML.me halte ich nicht viel, da es einfach zu umständlich zu bedienen ist. Wenn ich was designe dann mit https://creately.com/ , da is alles drine…
Christian Götz
17. April 2010
Tja, das mit der UML ist so eine Sache.
Als ich erstmals davon hörte war ich vollauf begeistert und bestellte mir sogar ein Buch über jene Thematik.
Allerdings wurde die Euphorie schnell getrübt, weil der Praxisbetrieb ein großartiges Top-Down-Design nicht zulässt.
Ich muss eben nicht nur eine Software entwickeln, welche ich für den Rest meiner Zeit in dem Betrieb pflege und erweitere.
Oft sind es eher kleine Tools, die “mal eben schnell” benötigt werden.
Oder der Kunde wünscht gravierende Änderungen an einer Software, wo der Zeitraum eher schmal bzw. knapp angesetzt ist.
Bei solchen Anforderungen ist an UML gar nicht zu denken. Da ist oftmals eher das “Quick-and-Dirty” Prinzip anzutreffen. Die Codebasis sieht dann zwar furchtbar aus, aber die Software macht erstmal das, was gefordert ist.
Ja, und was mich an UML eben auch stört, sind diese teils komplizierten Notationen.
Letztlich sehe ich es aber auch so, dass UML in der heutigen Zeit eher fehl am Platze ist. Gerade, weil die Praxis flexible Softwaredesigns provoziert.
Eine Software kann man daher nicht mit einem statischen Gebäude vergleichen, wo man nur sehr selten mal etwas verändert.
(Darüber mache ich mir auch so meine Gedanken, wie man Flexibilität mit Konsistenz und Stabilität verbinden kann. (siehe meinen Blog.))
mfg
Christian
lallala
23. April 2010
was kann die UML was die ERM nicht kann? Welche Konzepte spielen in der UML eine zentrale Rolle?
wenn da zb. steht … “mein neues auto das in der garage steht”… ist Auto dann ein objekt? für was brauche ich eig. die Datentypen wie zb. Integer? Kann ich werte eig nur als Initialisierung in den Klassen eingeben, oder mahct man das in den Objakten?…was genau ist eine Botschaft? wenn ich einen Wert durch die Initialisierung in der Klasse angebe ,ist das dann automatisch ein klassenatribut? weil der wert für alle Objekte gilt?…………………..tut mir leid das ich sooo viele Fragen auf einmal stell aber ich schreib in 2 tagen ne Arbeit und würd mich freuen wenn mir jemand weiterhelfen könnte. dankeschön..
lallala
23. April 2010
gibt es eig. auch private methoden und öffentliche Attribute? wisst ihr beispiele
Christian Götz
26. April 2010
Hallo lallala!
Zitat: “was kann die UML was die ERM nicht kann?”
Die UML umfasst ja viel mehr Teilaspekte bzw. Diagrammarten. Das ERM wird ja hauptsächlich für das Datenbankdesign verwendet, weil man hier die Beziehungen der verschiedenen Entitäten zueinander besser modellieren kann.
Die UML umfasst jedoch insgesamt 13(!) verschiedene Diagrammarten: Klassendiagramm, Objektdiagramm, Kompositionsstrukturdiagramm, Komponentendiagramm, Verteilungsdiagramm, Paketdiagramm, Anwendungsfalldiagramm, Aktivitätsdiagramm, Zustandsdiagramm, Sequenzdiagramm, Kommunikationsdiagramm, Timing-Diagramm, Interaktionsübersichtsdiagramm.
Die Diagramme hatte ich jetzt aus meinem UML-Buch abgeschrieben. (Die kann doch kein Mensch auswendig aufzählen. ^_^)
Zitat: “Welche Konzepte spielen in der UML eine zentrale Rolle?”
Ich würde sagen, definitiv das Klassendiagramm und das Sequenzdiagramm. Vielleicht auch noch das Zustandsdiagramm. Das sind so die Diagramme, denen man in der Praxis am Häufigsten begegnet.
Zitat: “wenn da zb. steht … “mein neues auto das in der garage steht”… ist Auto dann ein objekt?”
Natürlich! Du musst vor allem von der Vorstellung loskommen, dass in der objektorientierten Programmierung die Objekte nur Dinge sind, die man anfassen kann. Ein Objekt ist per se ein abtraktes Gebilde. Das kann im Prinzip alles sein. Es kapselt lediglich Dinge, die irgendwie logisch zusammengehören. (Zumindest sollte das so sein.)
Zitat: “für was brauche ich eig. die Datentypen wie zb. Integer?”
Um Werte zu speichern.
Zitat: “Kann ich werte eig nur als Initialisierung in den Klassen eingeben, oder mahct man das in den Objakten?”
Wichtig ist erstmal, dass du weißt, das Klassen nur die Baupläne deiner Objekte sind. Du kannst die Werte natürlich auch vorher in der Klasse festlegen. Dann wird jedes erzeugte Objekt automatisch diese Werte haben. Du kannst aber auch erst zur Laufzeit deinen Objekten Werte bei der Erzeugung zuweisen. Dies kannst du z.B. über den Konstruktor machen.
Zitat: “…was genau ist eine Botschaft?”
Du meinst sicher Objektbotschaften?! Wenn du z.B. von einem Objekt aus bei einem anderen Objekt eine Methode aufrufst.
Zitat: “wenn ich einen Wert durch die Initialisierung in der Klasse angebe ,ist das dann automatisch ein klassenatribut?”
Nur, wenn du es als “statisch” bzw. “static” deklarierst.
Zitat: “weil der wert für alle Objekte gilt?”
Nein. Nur, wenn du es als “static” deklarierst, ist der Wert in allen davon erzeugten Objekten gleich. Wenn er nicht “static” ist, kann sich der Wert individuell in jedem Objekt ändern, ohne ein anderes zu beeinflussen.
Zitat: “gibt es eig. auch private methoden und öffentliche Attribute? wisst ihr beispiele”
Selbstverständlich. Private Methoden kommen bei Klassen oftmals dann vor, wenn es sich z.B. um Hilfsfunktionen handelt und sie nicht nach außen hin sichtbar sein sollen.
Öffentliche Attribute ermöglichen es z.B., auf Datentypen von außen direkt zuzugreifen.
Falls du tiefgehendere Antworten suchst, kannst du natürlich weiterhin Fragen stellen. Dort findest du aber auch sehr ausführliche Informationen: http://openbook.galileocomputing.de/oop/
mfg
Christian