Kategorien
Sind UML-Diagramme sinnvoll?
Viele von uns kommen von der Uni oder haben eine andere Ausbildung Richtung Informatik genossen. Wenn man genügend Theorie gepaukt hat, dann hat man auch die Kunst des UML-Diagramm -Zeichnens gelernt. Keine Frage, Diagramme sind sehr sinnvoll, sorry also für den provokativen Titel, trotzdem nutzt sie kaum ein Entwickler (außer Tom, schätze ich mal).
Bei Entwicklern wären es wohl Klassendiagramme, die sie in Massen zeichnen sollten. Trotzdem habe ich in meinen vielen Jahren der Webentwicklung kaum welche gesehen und wenn ich ehrlich bin auch kaum welche gezeichnet. Das hat sich die letzte Zeit geändert, seitdem ich eher an Prozessen arbeite, trotzdem kann ich mich an der Stelle nicht hinstellen und mit den Fingern auf die anderen zeigen. Schade eigentlich … nur ein Witz.
Aber woran liegt es, dass man keine Diagramme zeichnet und in PHP meistens einfach drauflos programmiert? Natürlich ist es aufwändiger im Vorfeld den Entwicklungsschritt des Entwurfs einzubauen, der Gewinn, den man dadurch haben kann sollte aber diesen Aufwand locker aufwiegen. Das gilt aber nur für komplexe Probleme. Vielleicht haben wir also zu einfache Aufgaben, so dass die Entwurfsphase lächerlich einfach wäre und man sie deswegen auch weglassen könnte. Fände ich aber schade wenn das so wäre und wahrscheinlich fänden die meisten Entwickler ihr Leben auch langweilig wenn das die Realität ist.
Vielleicht ist es ja auch der Projektdruck, dass jeder das Gefühl hat man müsste so schnell wie möglich fertig werden und sich damit keine Zeit nimmt. Jeder „Mehraufwand“ kann da schon als Hindernis gesehen werden. Wahrscheinlich ist es eine Kombination aus allen genannten Punkten. Vielleicht fallen euch aber auch noch Gründe ein, warum man so handeln wie man handelt.
Noch nachgeschoben: Seid ihr eigentlich daran interessiert mal ein wenig was zum Thema UML zu hören?
Ich hab das Thema lang in der Berufschule durchgekaut und ganz ehrlich? Ich programmier immernoxh drauf los. Solang man OOP programmiert funzt das eigentlich auch.
Ich habe das Thema UML bisher immer vermieden, aber in letzter Zeit versuche ich immer mehr meinen inneren Schweinehund zu besiegen, und komplexere Projekte mit UML Diagrammen vorher ordentlich zu planen.
Es fühlt sich gut an 😉
Also ich würde sehr gerne mehr zum Thema UML auf dieser Seite lesen.
Das wird wohl maßgeblich mit dem Umfang / der Komplexität des Projekts und der Anzahl der involvierten Entwickler zusammenhängen.
Ich finde UML-Diagramme ziemlich wichtig, sofern die Projekte ein gewisses Maß an Komplexität besitzen. Zum Beispiel bei einem Use-Case-Diagramm kann man so schön sein Ablauf planen und sich so programmiertechnisch daran halten. Auch macht man sich so vielleicht mehr Gedanken um das Projekt, als wenn man einfach drauf los programmiert, und findet vielleicht ein paar Probleme im Vorfeld, die man ohne Planung vielleicht nur schwer in sein Programm rein bekommt. Ich fände es nicht schlecht, wenn hier ab und zu ein paar interessante Kniffe und Tricks zur Darstellung von UML-Diagrammen kommen würden. Auch wären vielleicht ein paar Tools hierzu interessant. Der OpenSource Bereich soll hierzu ja nicht so toll sein.
Ein Standard wie UML ist erforderlich und sinnvoll, damit eine übergreifende Möglichkeit zur Kommunikation besteht. Je größer das Projekt ist, umso müßiger ist es, immer zuerst noch erklären zu müssen, was der Autor jetzt für grafische Elemente verwendet hat und was diese überhaupt aussagen. Zumal dann im Endeffekt doch wieder (interne) Richtlinien entstehen würde, von Projekt zu Projekt, von Firma zu Firma unterschiedlich.
Und auch nur mit einem Standard kann man überhaupt daran denken, Aufgaben wie Code->UML oder sogar UML->Code zu lösen.
UML ist vllt stark OOP ausgelegt, aber prinzipiell gibt es auch genügend Möglichkeiten, anderen Code bzw. Situationen damit zu visualisieren.
… Und mit der Tatsache, ob der Auftraggeber den „Mehraufwand“ bezahlen will. 😉
yEd von yWorks (http://www.yworks.com/) finde ich für schnelle Entwürfe sehr brauchbar. Ist zwar nicht opensource, aber kostenlos.
Mir waere wichtig zunaechst einmal festzuhalten, dass zwischen UML Diagramme zeichnen und „einfach drauflos“ programmieren noch eine ganze Menge anderer Wege liegen. So sinnvoll UML Diagramme sind, stellen sie imho keine Loesung fuer all unsere Probleme dar. Sie sind ein sauberer Weg keine Frage, aber es gibt auch andere.
Ausserdem bezweifel ich, dass die meisten von uns UML wirklich gelernt haben. Ich selber hab es ziemlich lange durchgekaut und danach kaum wieder angewendet. Mein Wissen um UML geht daher eher gegen null.
Ein moeglicher Grund, warum man in PHP Projekten wenig auf UML stoesst scheint mir aber auch die mangelnde Integration in die Tools. So gibt es keine wirklich praktikable und einfache (!) Code Generierung geschweige denn ein Reverse Engineering, oder ich war bisher einfach blind. Indiesem Fall erleuchtet mich bitte.
Ich halte UML fuer ein gutes Mittel, um das eigene Vorhaben im Vorfeld genauer zu planen und theoretisch durchzuspielen. Aber auch Rapid Prototyping ist ein guter Ansatz. Ich glaube, die moeglichen Probleme liegen woanders, naemlich in der mangelnden Modularisierung (Separation of Concerns) und vor der schuetzt einen auch ein UML Diagramm nicht.
Ich denke das liegt am Aufwand. Von Hand ein UML-Diagramm zu zeichnen und von Hand zu pflegen macht keinen Spaß. Vor allem wenn man es dann gar nicht benutzt. Obendrein nutzt auch das beste Diagramm wiederum nichts ohne ordentliche Kommentare. Auch das frisst noch Zeit.
Es muss also entweder automatisch generiert oder automatisch gepflegt werden und es muss in den Gesamtprozess integriert sein. Zusätzlich muss man wissen, was man damit eigentlich erreichen will:
Wenn man sowieso mit einem CASE-Tool arbeitet liegt die Antwort auf der Hand. Wenn man „nur“ einen Vortrag ausarbeitet auch.
Klassendiagramme lassen sich live generieren. Feine Sache für Einbindung in die API-Doku, oder um sich ein beeindruckendes Poster in der Größe 3×3 Meter an die Wand zu kleben um dem Chef zu zeigen, wie fleißig man gearbeitet hat.
Zur Dokumentation des Austauschs von Daten mit Fremdsystemen oder der Nutzung von Schnittstellen auch eine gute Sache.
Für die Analyse sowieso: Serena Prototype zum Beispiel kann die gezeichneten Aktivitätendiagramme direkt ausführen als live-Vorschau auf die fertige Webseite. Das findet sogar der Chef toll.
Ist doch was anderes, ob man einen Schmierzettel bzw. (mit Glück) ein hingeschludertes „Pflichtenheft“ bekommt, oder eine ordentliche Anforderungsdoku, welche man per Knopfdruck auf Konsistenz und Vollständigkeit prüfen und zum Abschluss live simulieren kann.
In der Modellierung macht man es eigentlich um Tabellenmodelle zu validieren. Was nützt ein komplexes Diagramm, wenn die Maschine dir nicht sagen kann, ob das syntaktisch korrekt ist?
Design Pattern lassen sich per Drag&Drop einbauen und Skeletons generieren. Wenn man stets damit arbeitet ist auch das eine feine Sache.
Objektrelationalles Mapping: die XML-Datei braucht man sowieso und bei UML kann man sie wenigstens grafisch darstellen.
Und eine Sache darf man nicht vergessen: wir arbeiten ständig mit UML ohne es zu merken. Denn UML legt keineswegs die Symbole endgültig fest, sondern nur einen „Default“ und wie sie sich verhalten. Es erlaubt das Verwenden von Stereotypen und durch einen Stereotyp darf im Diagramm auch ein abweichendes Icon verwendet werden.
Somit ist BPMN nichts anderes als UML-Aktivitätendiagramme mit ein paar neuen Stereotypen. Hat man UML einmal verstanden muss man i.d.R. gar nichts mehr neu lernen. Mit Ausnahme vielleicht, man steigt auf EPKs um.
Einen einmal modellierten Workflow wiederum kann man direkt auf einen Workflow Execution Server hochladen und als Programm ausführen lassen.
UML muss in den Entwicklungsprozess eingebunden sein. Ohne ordentliche Werkzeuge hat das keinen Zweck.
Klar sind UML-Diagramme sinnvoll um bestimmte Sachverhalte grafisch darzustellen. Wichtig ist dabei nur die Aktualität und es nicht mit der Komplexität zu übertreiben.
Der schon angesprochene Aufwand ist sicher in der Tat einer der Hauptgründe dafür, dass es nicht gemacht wird. Und einen wirklichen Mehrwert kann ich in Klassendiagrammen auch nicht erkennen. Zumindest nicht solange sie nicht wie eine Art phpDoc generiert werden oder aus dem Diagramm Klassen erzeugt werden können. Weil ein Diagramm ist nur sinnvoll solange es aktuell ist. Und die Diagramme aktuell zu halten ist sehr schwer bis unmöglich bei den sich schnell ändernden Anforderungen.
Ich persönlich sehe die Klassendiagramme oder andere UML-Diagramme eher als Dokumentation. Und die Frage ist dann für WEN man dokumentieren soll? Die Anwender haben (meist) ihre Klassen und deren Zusammenhänge im Kopf. Für einen Entwickler ist der Code die Dokumentation. Oder auch phpDoc. Da drauf geschaut und man findet auch recht schnell die Zusammenhänge heraus. Wie gesagt fände ich es optimal, wenn phpDoc oder ein anderen Programm aus bestehendem Code sowas schnell erzeugen könnte. Oder sowas gibt es schon und ich kenne es nicht 😉
Also ich sehe es so:
Pro:
– schneller Überblick für Projektfremde möglich
– sehr hohe Abstraktion möglich (je nach Art des Diagrammes)
Kontra:
– sehr hoher Pflegeaufwand um Diagramme aktuell zu halten
– schlechte Toolintegration vorhanden
Zum Thema UML würde ich schon gerne etwas hören. Ich habe zwar auch nicht gerade viele in der Entwicklung gesehen aber nutze sie jetzt seit ca. acht Monaten aktiv.
Das Problem bei der ganzen Sache ist definitiv die Einheit die man festlegen muss – gerade in Angeboten. Man muss dem Kunden praktisch verkaufen, dass die Planung von UML Diagrammen das Entwickeln enorm erleichtert und auch später Probleme verhindert, da es sonst kein einziger Kunde akzeptieren würde.
Natürlich kann man das Problem umgehen wenn man das ganze mit in der Planungsphase einberechnet.
Das andere Problem ist, dass es selten eine Einheit beim Designen der Modelle gibt.
Man sollte hier vielleicht eine Reihe ansetzen, die sich darum kümmert, wie man überhaupt an die Sache heran geht.
Hmm wie es in der PHP-Entwicklung aussieht weiß ich nicht, bei uns in der Firma (Java) wird viel mit UML gearbeitet.
Ich finde http://argouml.tigris.org/ eigentlich ganz nett, habe aber auch noch kein nicht-kostenloses Tool ausprobiert. Die Code-Generierung mit ArgoUML geht in einfachem Maße eigentlich auch ganz gut.
Es ist, denke ich, auch immer eine Frage von Zeit und Budget, ob man es in der Entwicklung einsetzen kann. Bei sehr kleinen, einfachen Aufgaben, ist jedoch die Frage, ob sich der Aufwand für das Ergebnis lohnt.
Wenn ich mir so eure Kommentare durchlese, dann wir klar, dass UML-Diagramme schon als wichtig erachtet werden. Nutzt denn jemand von euch Klassendiagramme?
Soviel ich in Erinnerung habe, hat Visual Paradigm in der neusten Version eine UML-Untzerstützung für PHP. Kann mich aber auch irren.
@Christian: Was sind denn die anderen Wege?
ich habe noch kein tool gefunden, welches reverse engineering für php unterstützt. sonst hätte ich uml schonmal verwendet.
Also, ich für meinen Teil verwende UML Diagramme immer sehr gerne. Allerdings habe ich für mich persönlich festgestellt, dass UML Diagramme immer nur unterstützen können und kein Gesamtbild abbilden sollten. Vielmehr verwende ich immer wieder gerne kleine UML Diagramme, um ein gewisses Teilproblem zu beschreiben. Dazu verwende ich UML Digramme auch noch gerne am Whiteboard, um Probleme mit anderen zu diskutieren.
Ich finde das wichtigste ist, dass man selbst für sich einen Weg findet, um das Problem / die Domain / das Konzept / das Projekt so zu beschreiben, dass man selbst damit zurecht kommt.
Also ich nutze UML-Diagramme zugegebenermaßen vorrangig zum Datenbankentwurf. Ich lasse mir dann meine SQL-Skripte erzeugen und gut. Das Thema finde ich aber trotzdem interessant!
Wie Patrick schon sagte, glaube ich auch, das UML viel häufiger im Java-Umfeld eingesetzt wird. Wenn ich mit PHP programmiere, dann verwende ich eher selten bis gar nicht. Das hat auch nen Grund; da ich weniger from scratch arbeite, sondern mit Hilfe von Frameworks, erscheint es mir doppelt gemoppelt, wenn ich die Klassen des FW mi abbilden muss, da ich sonst die Beziehungen ja kaum hin bekomme.
Zu den Tools; da gibt es einige gute OSS, zum Beispiel Dia (mit Dia2Code, parsediasql oder tedia2sql) oder ArgoUML. Allerdings sind diese im Funktionsumfang eingeschränkt oder laufen vorrangig unter Linux. Die kommerziellen, also Poseidon oder Visual Pradigm, sind sehr teuer und oftmals sehr überladen mit Funktionen. Ich weiß nicht, ob es sich rechtfertigt, mehrere Hunderte/Tausende von Euronen auszugeben, wenn man diese Tools nur 1-2 Mal im Jahr nutzt? Für jemanden, der sich zum ersten Mal richtig damit beschäftigen möchte, steht auch ein ziemlich hoher Einarbeitungsaufwand im Raum. Er/Sie muss dann auch 2 Tools beherrschen, seine IDE und sein UML-Werkzeug.
Kleiner Nachtrag: Reverse Engineering für PHP habe ich in den UML-Tools auch noch nicht gefunden. Eine brauchbare Code-Generierung bekommt aber zum Beispiel Dia mit dia2code hin, auch speziell auf PHP 5 gemünzt und brauchbaren phpDoc-Gerüsten.
Ich verwende UML Diagramme sehr oft. Besonders Klassendiagramme bieten aus meiner Sicht einen hervorragenden Überblick, um als Entwickler einen ersten Eindruck von der Applikation zu bekommen.
Als Tool für das Zeichnen verwende ich Dia (http://dia-installer.de), das sowohl für Windows, als auch Linux verfügbar ist. Es gibt auch ein Skript, das aus PHP ein entsprechendes Dia Diagramm erstellt. Allerdings ist für mich das Zeichnen des UML Diagramms ein Teil des Aufarbeitens und Aufräumens. Und so mach ich das ganz gerne manuell und prüfe so die Struktur noch einmal. ArgoUML fand ich sehr schlecht, besonders bezüglich der Usability. yEd ist vom Funktionsumfang und der Bedienbarkeit auch ganz gut.
Ein Beispiel für eines meiner UML Diagramme könnt ihr hier finden: http://rsslounge.googlecode.com/svn/trunk/docs/class-uml.jpg
Das Thema an sich finde ich allerdings nicht so interessant, dass ich mehr darüber lesen möchte.
Grüße
Tobi
Für mich hat UML, wenn ich es verwende, zwei Zwecke: Erstens kann man Lösungen ohne den syntaktischen Überhang der Programmiersprache konzipieren und zweitens dient es der Dokumentation für andere Entwickler. Jedoch ist es für mich bei beiden wesentlich, dass diese Diagramme klein gehalten werden, denn sonst wird der Vorteil der visuellen Darstellung unterminiert. In diesem Sinne kann ich mich nur Dennis anschließen.
Zu deiner Frage, Nils: Ich kann mir keine interessanten Artikel über UML vorstellen, aber ich lasse mich gerne eines Besseren belehren. 🙂
Ich nutze UML, wenn auch nicht in der Reinform. Mir wurde noch beigebracht, dass man UML nicht als „Maß aller Dinge“ betrachten sollte, wenn die eigentliche Aussage damit nicht gut darstellbar ist. Dann lieber davon abweichen, wenn das Diagramm dadurch schlüssiger, übersichtlicher, aussagekräftiger, .. wird.
Denke Hauptgrund, warum es so selten genutzt wird, ist, dass Programmierer immer noch Programmierer sind, also so ähnlich, wie (der Rest der) Dokumentation, oder Tests: Wenn ich die Wahl habe, am „richtigen Ding“ zu arbeiten, oder bloss laaahme Diagramme zu zeichnen, fällt die Wahl leicht :>
Nach meinem Studium habe ich bei einer Firma angefangen, die kein UML kannte. Frisch aus dem Studium ist man das aber so gewohnt, dass man zumidnest für sich selbst das ein oder andere UML-Diagramm zeichnet. Mit der Zeit hat sich das dann mehr oder weniger eingebürgert. Insbesondere bei den Dev-Meetings war UML verdammt praktisch und angenehm, da es einfach eine einheitliche Sprache bietet, die auch Neulinge recht einfach erlernen können und auch auf Anhieb verstehen können. Außerdem können auch Nicht-Entwickler so ein wesentlich besseres Verständnis für die Komplexität einiger vermeintlich simplen Anforderungen erkennen.
Was ich nicht vertreten kann, dass ist die Aussage einiger Kommentatoren, dass der Einsatz von UML erst ab einer gewissen Projektkomplexität sinnvoll sein soll. Ich für meinen Teil würde es begrüßen, die Anforderungen grundsätzlich in Form von kurzen Einführungstexten zu bekommen, die dann in UML spezifiziert sind und ich das quasi nur noch runterprogrammieren muss. Die Diagrame sagen einfach viel mehr aus und macht wesentlich konkretere Aussagen, als das Blah-Blah was da zu oft aus der Feder so mancher Projektmanager kommt. Dazu kommt, dass man in die UML-Diagramme wenig reininterpretieren kann und so der Raum für mögliche Missverständnisse sehr klein wird. Wer kennt nicht solche Aussagen: „Ja _so_ habe ich das aber nicht gemeint…“?
Leider haben die wenigsten von uns die Möglichkeit, die Entscheidung zu fällen, UML im Alltag konsequent einzusetzen. Denn es kostet definitiv Zeit, diese Diagramme anzufertigen. Die Entscheider sehen leider selten den Mehrwert, der dann am Ende herauskommt. Nämlich qualitativ hochwertigere Software, dokumentierte Software und eine gemeinsame Sprache, die Abteilungsübergreifend gesprochen werden kann. Ähnliches gilt für so viele weitere Dinge wie beispielsweise Unit-Testing. Das Schreiben der Tests benötigt zusätzliche Zeit. Aber dass man sich dadurch sehr viele Bugs erspart und somit Zeit, um die Bugs zu fixen, dass bleibt entweder oft außer Acht oder wird gekonnt ignoriert.
Dies sind jedenfalls meine Erfahrungen bisher.
Eine Sache bezüglich der Dokumentation muss ich aber noch erwähnen. Für mich gibt es nur ein gültiges Argument, was den Vorteil der Dokumentation nichtig machen kann: Änderungen werden gerne mal einfach so im Code vorgenommen, ohne diese dann in zugehörigen Dokumentationen zu übernehmen. Im Fall von UML wäre es sogar sinnvoller, erst die Änderungen in den Diagrammen zu machen und dann im Code. Wenn diese Änderungen in der Dokumentation aber nicht gemacht wurden, dann kann das sehr schnell zu bösen Problemen führen, wenn sich jemand auf die Dokumentation verlässt – und man sollte sich definitiv auf die Dokumentation verlassen können, sonst bringt das alles recht wenig.
Schön wäre es, wenn endlich mal ein Tool auf den Markt kommen würde, mit dem man auch in PHP Design Driven Development machen kann. Ich weiß, es gibt Tools wie Visual Paradigm, mit denen das Möglich ist. Aber die sind wieder so komplex, dass die Arbeit damit nicht wirklich Spaß macht und ineffizient wird. Jedenfalls habe ich bisher noch kein Tool gesehen, mit dem ich einfach die Diagramme zusammenklicken kann und mir dann der Code bzw. die Klassen- und Methoden-Skelette sauber und zuverlässig generiert werden. Und dann am besten noch in beide Richtung: ich mache Änderungen im Code und die werden korrekt in die Diagramme übernommen.
Ich bin Software-Entwickler für kaufmännische Software.
Ich Erstelle also Lösungen für Aufgaben die sich nach Menschen und Gegebenheiten ständig ändern / weiterentwickeln.
Aufgaben bei denen nicht von Anfang an klar ist was da noch kommen soll, oder wie der Workflow letztlich optimal ist.
Etwas was man nur mir RAD sinnvoll hin bekommt.
UML ist ein theoretischer abstrakter Lösungs- und Planungsansatz.
Theoretisch sinnvoll, praktisch für mich nur Ballast.
P.S: Bin auch kein Freund von XML
Nun ja, gerade dafür eignet sich ein (standardisierter und grafischer) Ansatz sogar immens, denn die Alternativen sind ja sonst:
* gar nichts
* nicht grafische, Text/Prosa (in welcher „Sprache“?)
* ein grafisches Tool, welches im Zweifel jedem erklärt werden muss
Zu dem Thema „Reverse Engineering“: Das ist ein Feature, welches sich die meisten Hersteller richtig gut bezahlen lassen. Export nach Java gibt es manchmal (gab es etwa mal in der Communityversion von Poseidon); aus Code Klasse machen auch (etwa ArgoUML). Bei PHP sieht (oder sah?) das um einiges schlimmer aus, und die Preise sind nicht von schlechten Eltern.
Für Adhoc-UMLs kann ich übrigens http://yuml.me/ empfehlen; wird vom Autor mittels Graphviz realisiert. Solche URLs kann man sogar in Foren nutzen, sehr praktisch!
PHP & UML: http://www.phpbar.de/w/UML_und_PHP
Ich habe für diverse Projekte schon einfache bis umfangreiche Klassendiagramme verfasst, und diese erleichtern, zumindest mir, die Arbeit ungemein.
Ich habe im Studium jedoch noch nie einen Kurs zu UML gehabt und habe mir mal aus dem Netz das Notwendigste zusammengeklaubt. Daher würde ich gerne mehr zum Thema lesen.
Ich benutze BOUML, weil es äusserst performant läuft und vor allem PHP forward engineering beherrscht. Das einzige Feature, das ich bei BOUML vermisse, ist roundtripping, wenn ich mal den Ablauf nicht beachte. Kann es also nur empfehlen.
http://bouml.free.fr/
Mich würds auch mal interessieren etwas mehr über UML zu hören…
Am Anfang von PTI habe ich mit dem PEAR Paket PHP_UML experimentiert, um aus PHP UML Diagramme und umgekehrt zu generieren. Das Thema fand ich persönlich sehr interessant, da genau das „drauf-los-programmieren“ oft zu Insel Klassen führten, die zwar für sich genommen irgendwie funktionierten, aber im Gesamtkonstrukt nicht gut zusammenarbeiteten. Hatte es aber erst mal wieder auf Eis gelegt, da die Bearbeitung von XMI Dateien mit den Eclipse Standard UML Tools nicht unbedingt komfortable war.
UML ist in der Tat sehr wichtig, aber ebenso aufwändig. Ich glaube, selbst wenn man den Aufwand noch in Kauf nehmen würde: UML-Diagramme zeichnen und sich mit dem theoretischen Kram auseinandersetzen ist absolut langweilig. Wenn man ein neues Projekt beginnt, will man nichts mehr als endlich drauf los schreiben ^^ „Die Arbeit zeigt den Weg“. Aber so manche Zeile konnte man sich sparen, wenn man sich vorher tiefgehende Gedanken gemacht hätte. Von daher wäre ich auch dafür, mehr über UML zu lesen 🙂
Irgendwie lesen sich die ganzen Kommentare so … umfassend ^^ Bei Diagrammen im Allgemeinen liegt immer die Darstellug/Übersichtlichkeit im Vordergrund. Es hat niemand gesagt, man müsse ein komplettes System komplett in UML abbilden. Vielmehr ist es doch wesentlich interessanter immer mal wieder einzelne Teile heraus zu nehmen und zu reflektieren. Und ein UML-Diagramm mit 5 Klassen ist mit der Hand in < 10min gekritzelt 😉
@Nils Andere Wege sind zum Beispiel das Prototyping, welches ich nicht mich „einfach loslegen“ gleichsetze. Aber auch jede andere Form der Ideenfindung.
Zu mehr laesst sich UML fuer PHP imho derzeit nicht benutzen, denn solange es sich nicht automatisiert in meine Entwicklungsumgebung einbinden laesst, stellt es einen Mehraufwand dar, die Diagramme aktuell zu halten.
Fuer die Ideenfindung selbst wiederum braucht es nicht unbedingt reines UML, da reichen einfache Diagramme wie mit yuml.me erstellt. Die nutze ich auch sehr gerne, um mir und anderen etwas vor Augen zu fuehren.
Danke, sehr interessante Kommentare. Zumal ich in der Schule jetzt auch gerade UML durchnehme, werde ich noch versuchen ein paar kritische Punkte von hier aufzunehmen und diese den Experten vorzulegen. Mal schauen, wie sie so reagieren.
Nicht direkt UML, aber auch. Und vor allem: Volle Integration gefällig?
Wer GeneSEZ als PHP Entwicklerin noch nicht kennt, sollte mal einen Blick werfen: http://www.genesez.de/ Modell Getriebene Entwicklung mit PHP Export in 10 Minuten (als Anspruch). Eclipse basiert.
Die Dokumentation des PHP Metaframeworks ist übrigens ne clevere Sache.
Hi, ich möchte gerne ein PHP Projekt Planen, habe mir auch ein UML 2.0 Buch gekauft, werde daraus aber nicht wirklich schlau.
Mit welchem Digramm fange ich an, wenn ich erfassen will was überhaupt in das Script gehört. Also die Logik.
Z.B. das Script ruft die Datenbank auf und verbinden, dann weiter blub bla.
Welches Digramm muss man dafür nehmen, damit ich den „Weg“ symbolisch erfassen kann.
Danke für die Hilfe.
2te Frage:
Mit welchem Digramm fange ich an, wenn ich erfassen will, wie die Methoden Funktionen ineinander agieren, welche Abhänigkeiten vorhanden sind, etc (OOP).
@Woy: Schau dir mal Sequenz- und Klassendiagramme an, vielleicht sind es die zwei, die du suchst.
Artikel und Kommentare wie diese zeigen doch eindeutig wie haarsträubend in der Branche gearbeitet wird. Allein die Frage „Sind UML-Diagramme sinnvoll?“ zeigt doch wie sehr wir uns hier noch wie die kleinen Kinder unbeholfen durch unseren Arbeitsalltag programmieren und völlig ohne standardisierte Prozesse und halbwegs professionelle Methoden auszukommen scheinen. Das einzige was beim Thema UML aus dem Studium hängen geblieben ist, scheinen Klassendiagramme . An welchen Projekten müssen Entwickler arbeiten die eine Antwort auf die Frage suchen wozu UML gut sein könnte. Wenn ich als neuer Entwickler an einem halbwegs komplexen System weiterarbeiten muss, wie verschaffe ich mir am besten einen Überblick? Ich muss doch erstmal verstehen was die use-cases sind für den jeweiligen Bereich und wie diese implementiert sind. Gibt es da etwas vernünftigeres/professionelleres als ein Sequenzdiagramm zu erstellen? Und wenn bei solchen Themen immer wieder die Rede ist von „aber mein Auftraggeber bezahlt das nicht“: Wenn wir von kleinen Agenturen als Auftraggeber absehen wird in dem Bereich Kohle verbraten wie in fast keinem anderen. Selbst bei Zend Framework Projekten wird irgendwann gefrickelt und geschustert und dabei die Ansätze des Frameworks untergraben bis am Ende wieder ein zusammengeschustertes Etwas herauskommt, das dann irgendwann für teuer Geld komplett neu entwickelt werden muss. „Für Entwickler ist der Code die Dokumentation“. Yeah! Da wir offenbar immer wieder Auftraggeber finden die uns einfach mal machen lassen und selbst keine Standards vorgeben liegt es wohl am einzelnen Entwickler hier etwas mehr Würde reinzubringen. Ist auch gut für die Selbstachtung, einfach mal versuchen etwas Sauberes abzuliefern, auch wenn man im schlechtesten Fall dann auch schneller ersetzt werden kann.