Wie wichtig sind UML-Diagramme für ein erfolgreiches Projekt? [geschlossen]

22

Ich bin mitten in einem Projekt und wurde gebeten, UML-Diagramme (Anwendungsfälle, Klassendiagramme usw.) zu schreiben. Das Projekt ist nicht sehr komplex.

Ich habe mich gefragt, ob das Zeitverschwendung ist. Sollte ich einfach andere lustige Dinge tun, wie das Schreiben von Code? Und wann ist es nicht in Ordnung, etwas zu bauen, ohne die gesamte Konzeptionsphase zu durchlaufen? Geht es nur um Komplexität? Und wenn ja, wie kann man es messen?

Wissem
quelle
Sie könnten an diesem Beitrag interessiert sein: programmers.stackexchange.com/questions/58084/…
c_maker
15
Sorry, aber ich finde UML "technischer Mist", Zeitverschwendung und .. Ok, ich werde hier aufhören. Ich fühle mich jetzt besser.
Chiron
2
"Wenn Sie mehr Zeit für das Entwerfen benötigen, als der Kunde bereit ist, dafür zu zahlen, haben Sie das Entwerfen überzogen." verwendet werden und es würde sich lohnen :)
PhD
1
"Should I just be doing other fun stuff like writing code?"Du meinst: "other stuff that contributes to the bottom line of the project like writing code"sicher?
StuperUser
Natürlich tust du das und nenn dich nicht Shirley.
StuperUser

Antworten:

53

Ich war vor einiger Zeit ein großer Fan von UML. Ich bin sogar OMG zertifiziert. Ich habe es ausgiebig in großen Unternehmensprojekten eingesetzt, an denen ich beteiligt war.

Heute habe ich UML fast vollständig gestoppt. Manchmal verwende ich das Sequenzdiagramm, das ich sehr nützlich finde, um Interaktionen zwischen Systemen zu beschreiben, aber keine anderen Diagramme.

Ich bevorzuge es jetzt, mit User Stories zu arbeiten, die sowohl (nur) von den Produktbesitzern (oder Analysten) als auch von seinem Engagement für das Entwicklungsteam erstellte (n) Dokumentation enthalten, um bei Bedarf weitere Details bereitzustellen.

UML ist ein Tool, das Sie verwenden können, aber es ist sicherlich kein kritischer Faktor für den Erfolg Ihrer Projekte. Nach vielen Jahren denke ich, dass der entscheidende Faktor das Entwicklungsteam ist, egal welche Tools es verwendet.

user2567
quelle
Sie sagten, Sie sind OML-zertifiziert. Was ist OML? Ein Tippfehler?
BЈовић
Ja, es war OMG for Object Management Group, der Organismus hinter UML => uml.org
12
+1 für den letzten Absatz. Wenn es um die Darstellung von Softwaresystemen geht, ist UML großartig, da es standardisiert ist und von anderen Software-Entwicklern ohne Erklärung gut verstanden werden sollte. Es handelt sich jedoch nur um ein Tool, und Sie benötigen dieses Tool möglicherweise nicht, je nachdem, wer die Software erstellt.
Thomas Owens
14
Der erste Absatz ist viel lustiger, wenn Sie nur OMG mit seiner üblichen Bedeutung lesen .
JSB ձոգչ
@ Pierre303 Ich stimme zu, dass es neben UML noch andere Optionen gibt. Es geht aber auch um die Verwendung von Spezifikations- / Dokumentationswerkzeugen im Gegensatz zur reinen Codierung. Bedeutet "egal welche Tools verwendet werden", "solange das Team Tools für diese Aufgaben verwendet"? Verwenden Sie User Stories auch für "[nicht] sehr komplexe" Projekte oder verschwenden Sie in solchen Fällen Zeit?
scarfridge
9

Planung ist kritisch, warnt aber der berühmte Stratege Carl von Clausewitz

Kein Kampagnenplan überlebt den ersten Kontakt mit dem Feind

Es ist also keine große Zeitverschwendung für die Planung, wie die Probleme anfangs angegriffen werden sollen. Aber wahrscheinlich Zeitverschwendung für die Dokumentation Ihres Codes für zukünftige Programmierer. Um eine militärische Metapher zu verwenden, benötigen Sie einen Schlachtplan, aber Sie würden den Historikern diesen Plan nicht als Nachbearbeitungsbericht geben.

Konkreter können Sie diese Diagramme verwenden, um Ihre Absichten im Team zu kommunizieren und über Ihren Angriffsplan vor und während des Projekts nachzudenken. Aber die Chancen stehen gut, dass das, was Sie sich einfallen lassen, beim Codieren optimiert werden muss, um mehr über das Problem zu erfahren. Fast immer muss Ihr ursprünglicher Plan / Entwurf geändert werden, da Sie nicht alles im Voraus wissen können.

Doug T.
quelle
3
But likely a waste of time for documenting your code for future programmers.Wenn ein Projekt UML als Dokumentationsform verwenden möchte, wird es normalerweise mit Reverse Engineering-Tools erstellt. Es gibt verschiedene Tools, mit denen Klassen- und Sequenzdiagramme (und manchmal auch einige andere) aus dem Quellcode generiert werden können. Die Ausgabe dieser Tools wird als Dokumentation erfasst.
Thomas Owens
9

Ich denke, UML-Diagramme können nur nützlich sein, wenn sie etwas auf einer höheren Abstraktionsebene ausdrücken als Ihr Code .

Das Schreiben von UML nur zum Zwecke des Schreibens von UML wird zu einer unnötigen Bürokratie und macht das Projekt und den Code weniger anpassungsfähig für Änderungen, ohne dass dies irgendeinen Nutzen bringt.

Zum Beispiel liefert ein UML-Klassendiagramm, das alle Klassen eines Pakets mit all ihren Attributen und Methoden zeigt - etwas, das leicht automatisch generiert werden kann - überhaupt keinen Wert: Es befindet sich auf derselben Abstraktionsebene wie Ihr Code . Außerdem wird der Code mit Sicherheit eine bessere Quelle für diese Informationen sein, da er immer auf dem neuesten Stand ist und wahrscheinlich auf eine Weise dokumentiert und organisiert wird, die es einfacher macht zu wissen, welche Methoden / Attribute / Dinge wichtiger sind.

Auf der anderen Seite kann es eine gute Idee sein, die Konzepte in einem Diagramm zu dokumentieren, wenn die Abstraktionsebene über der im Code ausgedrückten Ebene liegt.

Beispielsweise kann ein Diagramm, das die übergeordneten abstrakten Module eines komplexen Systems mit ihren Abhängigkeiten und möglicherweise einer kurzen Beschreibung ihrer Zuständigkeiten und dem Paket / Namespace zeigt, dem sie im Quellcode zugeordnet sind, für ein neues Teammitglied von großem Nutzen sein Das muss in das Projekt eingeführt werden oder kann auch verwendet werden, um herauszufinden, wo eine neue Klasse / Funktionalität geworfen werden soll.

Ein anderes Beispiel eines nützlichen Diagramms könnte ein Sequenzdiagramm sein, das die in einem Kommunikationsprotokoll auszuführenden Schritte auf hoher Ebene zeigt. Vielleicht hat jeder dieser Schritte kleine Macken und Komplexitäten, aber es ist wahrscheinlich genug, um sie im Code selbst zu beschreiben. Das übergeordnete Diagramm kann einem Programmierer helfen, das "Gesamtbild" der Dinge leicht zu verstehen, ohne sich um die Komplexität jeder Interaktion kümmern zu müssen.

Wie auch immer, das sind nur einige Beispiele; Es gibt viele Fälle, in denen ein einfaches Diagramm sehr hilfreich sein kann. Denken Sie daran, dass Sie sie nur dann ausführen sollten, wenn Sie im Code selbst nichts ausdrücken können. Wenn Sie feststellen, dass Sie UML-Diagramme verwenden, um den Quellcode selbst zu erklären, sollten Sie den Quellcode stattdessen selbstdokumentierender gestalten.

Schließlich können einige der allgemeinen Regeln, die für Code gelten, auch für Diagramme gelten: Vermeiden Sie es, sich zu wiederholen, halten Sie es einfach, fürchten Sie sich nicht davor, Dinge zu ändern (nur weil etwas in einem UML-Diagramm dokumentiert ist, heißt das nicht, dass es nicht möglich ist geändert werden) und denken Sie immer daran, wer diese Diagramme in Zukunft lesen / pflegen wird (wahrscheinlich Ihr zukünftiges Ich), wenn Sie sie schreiben :)

Epidemie
quelle
8

UML ist von Wert, wenn Teammitglieder es gemeinsam verstehen und es als nützliche Methode zur Zusammenfassung und Kommunikation von Entwurfsentscheidungen betrachten. Sie müssen nicht alles wissen, nur die Teilmenge, die das Team für nützlich hält.

Außerdem müssen Sie keine perfekten, polierten Diagramme zeichnen. Ein grob skizziertes Sequenzdiagramm auf einem Whiteboard oder ein Klassendiagramm, in dem Klassen als Haftnotizen auf diesem Whiteboard gespeichert sind, kann je nach Kontext ausreichend sein.

Pythoneer
quelle
3
+1: In der Tat: sehen Sie UML als eine Skizze .
Richard
6

Ich habe einmal an einem Gig gearbeitet, bei dem ich ein Team von Vertragsentwicklern im Ausland leiten musste.

Einige der Dinge, die sie produzierten, waren ziemlich schrecklich (ein häufiges Symptom von Remote-Vertrags-Codierern - sie interessieren sich nicht wirklich für Ihren Code, sie wollen nur schnell fertig werden).

Um das Projekt zu verwalten, habe ich UML-Diagramme erstellt und an den Code übergeben. Es war sehr erfolgreich - ich habe nicht so lange gebraucht, um ein Programm in UML zu schreiben, viel schneller als in Java, und es war etwas, an dem sich die Auftragnehmer messen konnten.

Eine Einschränkung - sie wollten manchmal kreativ werden und von meinen Modellen abweichen, aber in diesen Fällen waren sie tatsächlich korrekt und insgesamt verbesserte die UML die Qualität des Endprodukts

Victor Grazi
quelle
+1 - Einer der wichtigsten Vorteile der Modellierung besteht darin, dass Sie verschiedene Ideen viel schneller erstellen, ändern, verstehen und erforschen können, als dies mit Code möglich ist.
Dunk
3

Wenn Sie jemand gebeten hat, UML-Diagramme zu erstellen, und jemand Ihr Gehalt zahlt, ist dies keine Zeitverschwendung. Es kann eine Verschwendung von Zeit sein oder auch nicht.

Wenn diese Person plant, Ihr Projekt durch Lesen Ihrer UML-Diagramme zu verstehen, ist dies wahrscheinlich keine Zeitverschwendung.

Emory
quelle
2

Ich finde es schon in der Entwurfsphase nützlich, Ideen auf Papier oder auf dem Whiteboard zu bekommen. Ich habe hauptsächlich UML-Klassendiagramme verwendet, ohne die Standards strikt einzuhalten. Es ist nützlich, das ursprüngliche UML-Design zu überprüfen, wenn Sie sich auf halbem Weg befinden und auch am Ende des Projekts. Es hat mir geholfen, eine Codebasis auf einer höheren Abstraktionsebene zu betrachten, die Sie jemals durch einfaches Lesen von Code erreichen können, und es hat mir sogar geholfen, potenzielle Fehler zu erkennen.

Es ist ein guter Punkt gemacht hier durch ragu.pattabi Unterscheidung zwischen zwei Arten von UML ...

Ich denke, dass der agile Stil von UML (z. B. eine schnelle Whiteboard-Skizze) erfolgreicher ist als der Wasserfall-Stil von UML (z. B. ein ausgeklügeltes Diagramm mit allen wichtigen Details für Dokumentation, Codegenerierung usw., um die dokumentenbewussten Manager glücklich zu machen).

Als UML als ein Muss angesehen wurde (vor 10 Jahren oder länger), war ich wahrscheinlich dagegen, weil die Meinung seiner vielen Fans zu dieser Zeit groß war. Aber jetzt, da es in Ungnade gefallen ist, sehe ich es als das, was es ist - ein nützliches Werkzeug, das sich auszahlt, aber nicht die Silberkugel der Softwareentwicklung ist.

dodgy_coder
quelle
1
+1 - Das einzige Mal, dass ich UML als Zeitverschwendung betrachtete, war der Versuch, den "Standard" einzuhalten und schlimmer noch, tatsächlich Code daraus zu generieren. Die richtige Verwendung besteht darin, es als Kommunikationsmechanismus zu verwenden und verschiedene Ideen zu untersuchen, auch wenn es bedeutet, es an Ihre Bedürfnisse anzupassen. Es ist weitaus effizienter als die Erstcodierung, es sei denn, die Anwendung ist trivial.
Dunk
1

Ich benutze UML (oder etwas Ähnliches wie UML :)), wenn ich mit Freunden über etwas spreche, was wir tun werden. Ideen diskutieren. Kein UML-Projekt vorzubereiten, das automatisch Code für mich generiert. Ich kann mir nicht vorstellen, meine Klassen in UML zu erstellen, dann Code zu generieren und ihn später nicht zu optimieren. Das passiert nie. Sie müssen also Änderungen vom Code in die UML übernehmen. Und wenn ich UML benutze, male ich auf Whiteboard oder Papier. Niemals in Tools wie Enterprise Architect.

Der einzige Grund, meinen gesamten Code in UML zu dokumentieren, wäre ein Vertrag, den der Kunde verlangt. Zum Beispiel, wenn er die Option haben möchte, den Software-Shop zu wechseln, nachdem ein Teil der Software abgeschlossen wurde.

Piotr Perak
quelle
1

Die Dokumentation der Projektarbeit ist ein grundlegendes Ergebnis eines professionellen Projekts. Wieviel ist genug? Nun, es hängt natürlich von vielen Faktoren ab. Nach meiner Meinung sind Anwendungsfälle, Klassendiagramme, Prozessflussdiagramme usw. jedoch keine Zeitverschwendung. Sie haben Wert in verschiedenen Projektphasen. Das einzige Problem bei der Dokumentation sind normalerweise die Ressourcen.

Einige Programmierer halten Dokumentation für Zeitverschwendung. Aber das ist nicht wahr. Wenn Sie die Dokumentation auf elegante und übersichtliche Weise als Anzeige Ihrer Design- und Systemregeln ansehen, werden Sie sie möglicherweise besser zu schätzen wissen. Außerdem muss man sich in die Position der Menschen versetzen, die das System warten müssen. 500 Code-Dateien zu werfen und gebeten zu werden, die Probleme mit ihnen zu beheben, ist etwas schlecht, aber nicht ungewöhnlich.

Ich schlage vor, dass Sie Ihrem Projekt Zeit zuweisen und die Diagramme in Zyklen erstellen. Die erste behandelt die Hauptaspekte Ihres Projekts, und die folgenden Ebenen befassen sich möglicherweise eingehender mit den Details.

Insbesondere Anwendungsfälle lassen sich nicht einfach aus dem Code ableiten (im Gegensatz zu vielen anderen Aspekten eines Systems). Stellen Sie sicher, dass Sie das tun.

Emmad Kareem
quelle
-1: Wenn Sie die Dokumentation auf elegante und klare Weise als Anzeige Ihrer Design- und Systemregeln ansehen: Nein, das tue ich nie. weil es immer veraltet ist. // Ich bin mir nicht sicher, wo Sie leben, aber auf dem Planeten Erde entwickelt sich die Software viel zu schnell, um eine Dokumentation in professioneller Qualität zu rechtfertigen.
Jim G.
@JimG. Das kann wahr oder unwahr sein, je nachdem, wie detailliert die Dokumentation ist. Wenn Sie Ihre Dokumentation auf einem hohen Niveau halten (Komponenten, wichtige Details der Hauptklassen), wird die Dokumentation nicht schnell veralten. Wenn Sie jedes Mitglied jeder Klasse manuell dokumentieren, ist Ihre Arbeit schnell unbrauchbar.
Danny Varod
1
@JimG., Ich bin sicher, Sie sind nicht allein in dieser Denkweise. Die Tatsache, dass sich die Software ändert, macht die Analyse-, Design- und Implementierungsdokumente nicht völlig überflüssig. Dieses Wissen entsteht während des Systemlebenszyklus. Wenn Sie Systeme an Organisationen übergeben müssten, die IT-Audits durchführen, müssten Sie die Dokumentation anzeigen und nicht nur den Code und die Binärdateien.
NoChance
@Emmad Kareem: In Bezug auf Organisationen, die IT-Audits durchführen - Der größte Teil dieser Dokumentation ist oberflächlich und nur für das Audit bestimmt. Die meisten Software-Entwickler werden dem nicht vertrauen.
Jim G.
@JimG., Was Sie in Ihrem letzten Kommentar beschrieben haben, ist eine Situation, die ich gerne verschwinden sehen würde. Ich würde es begrüßen, wenn die Softwareentwicklung zu einem berechenbareren Geschäft wird, das das Leben der Entwickler verbessert und das Risiko verringert, dass Unternehmen schlucken, weil sie die Gefahren nicht kennen, denen sie sich stellen müssen. Wie auch immer, ich denke, es ist ein langes, aber interessantes Thema (für mich).
NoChance
1

UML ist ein Werkzeug, nichts weiter, und ob es nützlich oder sogar entscheidend ist, hängt einzig und allein von Ihrem Entwicklungs- und Design-Workflow ab. Es gibt viele Wege nach Rom, und einige beinhalten UML, andere nicht.

Wenn Ihr Workflow sich auf UML stützt, um Ihre Architektur zu dokumentieren oder zu planen, wäre es dumm, sie fallen zu lassen. Wenn UML die beste Möglichkeit ist, die Projektstruktur anderen Teammitgliedern (im weiteren Sinne) mitzuteilen, sollten Sie sie auf jeden Fall verwenden. Aber wenn das Projekt ohne UML gut funktioniert, ist es Unsinn, nur UML-Diagramme zu erstellen.

tdammers
quelle
1

Ich habe einige Gedanken dazu. Sprache kann gebraucht und missbraucht werden, zwingen und ablenken, auslösen und lullen. UML ist nur eine weitere Sprache, die für eine bestimmte Reihe von Problemen geeignet ist. Wie jede andere Sprache wird es Zeit und Mühe kosten, zu lernen, wie man sie fließend spricht und richtig versteht.

Die Entscheidung, was kommuniziert werden soll, ist unglaublich wichtiger als die Sprache, in der kommuniziert wird. UML wird Ihre schlechten Designs nicht auf magische Weise verständlich machen. Wie in jeder anderen Sprache kann man sich leicht in Details verlieren oder zu viel der Fantasie überlassen.

UML hat einen schlechten Ruf wegen der zahlreichen schrecklichen IDEs, die Round-Trip-Prototyping, klickintensive Graphmanipulationen und die Schwierigkeit, irgendetwas zu ändern, ermöglichen. UML 2.0 mag komplex genug sein, um bestimmte Akademiker zufriedenzustellen, aber sein Metamodell scheint nicht viele praktische Anwendungen anzuziehen.

Trotzdem benutze ich von Zeit zu Zeit UML. Bewertung eines High-Level-Designs (ein gutes Design hat Komplexität am Rand und Einfachheit in der Mitte). Einem Kollegen eine Idee mitteilen und Feedback erhalten. Versteckte Beziehungen finden, normalisieren usw. Aber es ist immer ein Spiegelbild von etwas, das bereits in meinem Kopf ist. Im Allgemeinen zeichne ich UML mit Stift und Papier, vorzugsweise von jedem Computer entfernt. Wenn ein Design kristallisiert, mache ich bei Bedarf eine visuelle Darstellung in einem Zeichenprogramm.

Dibbeke
quelle
1

UML ist absolut fantastisch, um mithilfe eines Klassendiagramms eine grafische Ansicht Ihrer Architektur zu erhalten. Die Interaktion mithilfe eines Sequenzdiagramms ist für mich magisch. Das Problem ist daher für mich nicht UML sondern MDD.

Ich meine, wenn UML ein Betrachter des Codes ist, dann ist es für Dokumentationszwecke sehr hilfreich, aber sicherlich nicht für die Codegenerierung. Das Projekt sollte sich auf den Code konzentrieren und nicht auf das Modell. UML sollte in der Implementierungsphase unter Verwendung von Live-Code und Modellsynchronisation verwendet werden. Ich meine nicht nur auf Anforderungsebene, die zu viel Investition für eine geringe Rendite in Produktivität und Qualität erfordert.

UML_Guru
quelle
0

Ich finde sie hoch überbewertet. Ich betrachte sie als die einzigen Bilder, die nicht tausend Worte malen.

James
quelle
Geben Sie Farbe und einen Pinsel in die Hände eines ungelernten Mannes und alles, was dabei herauskommt, ist ein Durcheinander, das beseitigt werden muss. Legen Sie jedoch Farbe und Pinsel in die Hände eines Künstlers und Kunst ist geboren. Gleiches gilt für UML-Diagramme.
Dunk
0

UML ist nur dann von Nutzen, wenn die Entwickler des Systems den Code nicht selbst schreiben können. Das heißt, UML ist eine „Sprache“, die die Architekturkonzepte an andere weitergibt. Wenn Sie nun die Person sind, die den Code entwirft und implementiert, warum sollten Sie sich dann zeigen, was Sie tun werden ?! Steigen Sie ein und gehen Sie stattdessen direkt zur Codierung. Sie müssen noch dokumentieren, was Sie später getan haben, aber die Gesamteffizienz ist schneller.

Aber wenn Sie als Systemarchitekt Ihrem ausgelagerten Entwicklerteam mitteilen möchten, was Sie wollten, müssen Sie es ihnen irgendwie mitteilen, und hier kommt UML ins Spiel. Ich denke jedoch, dass es viele alternative Möglichkeiten gibt, eine Leistung zu erbringen Diese Aufgabe ist heutzutage, und offen gesagt, aufgrund der Komplexität des UML-Diagramms muss jeder verstehen, wie es zu lesen ist.

gbjbaanb
quelle
LMAO, schwarz / weiß? Ihre "vorgeschlagene" Entwicklungsmethode ist der Grund, warum ich aufgefordert werde, so oft katastrophale Projekte zu bereinigen und zu reparieren. Der Code ist nicht das Design. Es gibt nur wenige Leute, die selbst mäßig komplexe Systeme erstellen können (ich muss diese Aussage wohl für sich behalten). Und es gibt weitaus weniger, die es schaffen, direkt in Code zu springen. Möglicherweise haben Sie auch ein "kaputtes" System schneller, aber Sie werden kein "funktionierendes" System schneller haben, wenn Sie direkt in den Code springen. Aber ich denke, es hängt alles von der Art der Projekte ab, die Sie haben. Wenn die Hälfte der Arbeit in Ordnung ist, ist Ihr Ansatz in Ordnung.
Dunk
0

Ich war nie ein Fan von UML, aber ich habe ein gutes Sequenzdiagramm zur Beschreibung der Interaktionen zwischen Systemen oder Aufgaben zu schätzen gelernt.

Das Klassendiagramm ist jedoch veraltet, bevor es geboren wird. Für ein grobes Design ist keine UML erforderlich, und eine gründliche Dokumentation wird besser automatisch (live) aus der Codebasis extrahiert. Javadoc und Doxygen haben die Notwendigkeit manueller Klassendiagramme vollständig überflüssig gemacht.

Die Sache mit der Dokumentation ist, dass es zwei Ebenen gibt:

  • Übergeordnete (architektonische) Entscheidungen sollten manuell dokumentiert werden
  • Fakten auf niedriger Ebene (Entitätsbeziehungen) sollten automatisch extrahiert werden
Matthieu M.
quelle
Fast alle CASE Tools können Ihre Klassendiagramme zurückentwickeln. Trotzdem denke ich, dass Klassendiagramme zu den nutzlosesten Diagrammen gehören, mit Ausnahme von Vererbungs- und Abhängigkeitsproblemen (in diesem Fall sind nur die Klassennamen ausreichend). Der Knaller in der UML sind die Sequenzdiagramme. Leider erledigen keine Tools eine sinnvolle Aufgabe für das Reverse Engineering von Sequenzdiagrammen. Dieser Mangel an Fähigkeiten ist der Hauptgrund dafür, dass es sehr schwierig ist, UML zu verwenden, um Ihr Design so wie es ist zu dokumentieren. Stattdessen stellt UML lediglich eine Roadmap vor der Implementierung bereit.
Dunk
0

Normalerweise iteriere ich zwischen Code- und UML-Diagrammen. Ich finde, dass die Diagramme helfen, das große Ganze und einen soliden Weg nach vorne zu zeigen, und sie können ziemlich schnell geändert werden, wenn Probleme entdeckt werden. Auch wenn ich die Diagramme habe, wird die Codierung gewöhnlich trivial.

Umgekehrt, wenn ich den Code in Bildern zeichne, werden Abhängigkeitsprobleme aufgedeckt und Möglichkeiten zur Designverbesserung offenkundig, was wahrscheinlich nicht bemerkt worden wäre, wenn wir nur den Code hätten, mit dem wir arbeiten könnten. Insbesondere, wenn es ein Schmerz ist, zu zeichnen, dann wird es auch ein Schmerz sein, zu kodieren und einen Albtraum aufrechtzuerhalten.

Ich habe festgestellt, dass eine Iteration erforderlich ist, da beim Zeichnen der Bilder immer wichtige Aspekte fehlen, während beim Codieren problematische Designs entstehen.

Wie ein anderes Plakat sagte, läuft alles auf die Menschen hinaus. Wenn sie UML-Diagramme beherrschen, ist UML von unschätzbarem Wert. Wenn dies nicht der Fall ist, haben die Diagramme keinen Wert.

Die Antwort auf Ihre Frage lautet also wirklich "es kommt darauf an". In diesem Fall kommt es auf die Leute an, auf die Komplexität des Projekts und darauf, wie wichtig es ist, dass das System richtig funktioniert.

Dunk
quelle
0

Aus meiner Erfahrung ist die UML wichtig für die Kommunikation zwischen Entwicklern über die Codemuster und für die Architektur der Anwendung im Allgemeinen.

carlo
quelle
0

Ich liebe Diagramme, aber wenn ich gebeten würde, eines zu erstellen (besonders UML!), Würde ich zwei Fragen stellen:

  1. Für wen ist das?
  2. Brauchen sie es jetzt?

Diagramme sind sofort veraltet. Wenn Sie es also nicht verwenden, um mit jemandem zu kommunizieren, wird es nur verrotten. Und wenn die Person, mit der Sie kommunizieren, besser mit einer Textbeschreibung, einem Telefonanruf oder einem informellen Digramm auf einer Pinnwand zurechtkommt, schlagen Sie dies vor.

Steve Bennett
quelle
0

Einer der Hauptgründe für mich bei UML-Diagrammen, wie ich sie bisher gesehen habe, ist, dass sie meist nur als "hübsche Bilder" an der Wand oder als gefaltete Seite in einer Bindung dienen und selten als Grundlinie dienen für einen Produktionscode.

In dieser Art von Szenario sind die UML-Diagramme (oder welche Variante der verwendeten Modellierungssprache auch immer) auf lange Sicht selten nützlich, da sie im Laufe der Zeit und der Entwicklung des Projekts an Relevanz verlieren. Diese anfänglichen Zeichnungen sind in wenigen Jahren meistens unbrauchbar und falsch, und es ist meistens schädlich, sie zu haben.

Das heißt, die Verwendung von Modellierungswerkzeugen (nicht unbedingt UML) ist keine völlig nutzlose Praxis, wenn die Modelle den tatsächlichen aktiven und relevanten Input für den tatsächlichen laufenden Code liefern. Wenn die Modellbeschreibung ein nützliches Artefakt des Codes ist, sollte sie als Code behandelt werden:

Entweder durch Verwendung als direkte Quelle für Metadaten zum Treffen dynamischer Entscheidungen basierend auf den modellierten Konzepten oder durch Verwendung der Codegenerierung zum Generieren statischer Code-Artefakte, die im tatsächlichen Arbeitscode verwendet werden.

Roland Tepp
quelle
0

Ich weiß nicht, ob die Frage nach dem Nutzen von UML oder nach dem Nutzen des Entwurfs der Programmarchitektur gerichtet ist.

Über UML. Normalerweise benötigen Sie nur: Anwendungsfälle, Klassendiagramme und Sequenzdiagramme. Einfach und unkompliziert, obwohl Sie dies sicherlich mit Ihren eigenen Diagrammtypen tun könnten. In dieser Hinsicht ist UML ein Standard, den jeder verstehen wird.

Über das Entwerfen von Programmen.

  1. Jedes Programm hat ein Design, auch wenn Sie es nicht planen. Wenn der Code geschrieben ist, müssen Sie ihn einfach rückentwickeln. Wenn Sie es nicht geplant haben, wird es ein schlechtes Design sein.

  2. Design spart Zeit, indem bekannte Muster für wiederkehrende Probleme verwendet werden.

  3. Wenn Sie in einem Team arbeiten, ist Design notwendig, um Lösungen zu diskutieren, Ideen zu vermitteln und um Arbeit zu verteilen.

cibercitizen1
quelle