it-swarm.com.de

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

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 dies eine Verschwendung meiner Zeit ist. Sollte ich einfach andere lustige Dinge wie das Schreiben von Code machen? Und wann ist es nicht in Ordnung, etwas zu bauen, ohne die gesamte konzeptionelle Phase zu durchlaufen? Geht es nur um Komplexität? Und wenn ja, wie kann man es messen?

22
Wissem

Ich war vor einiger Zeit ein großer Fan von UML. Ich bin sogar OMG-zertifiziert. Ich habe es ausgiebig in großen Unternehmensprojekten verwendet, 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 arbeite jetzt lieber mit User Stories, die sowohl von (nur) notwendigen Dokumentationen des Produktbesitzers (oder von Analysten) als auch von seinem Engagement für das Entwicklungsteam unterstützt werden, um bei Bedarf weitere Details zu liefern.

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 jetzt, dass der entscheidende Faktor das Entwicklungsteam ist, egal welche Tools es verwendet.

53
user2567

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

Kein Kampagnenplan überlebt den ersten Kontakt mit dem Feind

Es ist also keine große Zeitverschwendung, zu planen, wie die Probleme anfänglich angegriffen werden sollen. Aber wahrscheinlich eine 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 diesen Plan nicht an Historiker weitergeben, um ihn als Bericht nach der Aktion zu verwenden.

Genauer gesagt können Sie diese Diagramme verwenden, um Ihre Absichten in Ihrem Team zu kommunizieren und über Ihren Angriffsplan vor und während des Projekts nachzudenken. Es besteht jedoch die Möglichkeit, dass das, was Sie sich einfallen lassen, beim Codieren angepasst 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.

9
Doug T.

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

Das Schreiben von UML nur zum Schreiben von UML wird zu unnötiger Bürokratie und macht das Projekt und den Code weniger anpassungsfähig an Änderungen ohne jeglichen Nutzen.

Beispielsweise liefert ein UML-Klassendiagramm, das alle Klassen in einem Paket 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 so dokumentiert und organisiert wird, dass leichter zu erkennen ist, welche Methoden/Attribute/Dinge wichtiger sind.

Wenn Sie jedoch Konzepte mit einer höheren Abstraktionsebene haben, als sie im Code ausgedrückt werden können, kann es eine gute Idee sein, diese in einem Diagramm zu dokumentieren.

Zum Beispiel kann ein Diagramm, das die übergeordneten abstrakten Module auf einem komplexen System mit ihren Abhängigkeiten und möglicherweise einer kleinen Beschreibung ihrer Verantwortlichkeiten und dem Paket/Namespace zeigt, dem sie im Quellcode zugeordnet sind, für ein neues Teammitglied sehr nützlich sein Dies muss in das Projekt eingeführt werden oder kann auch verwendet werden, um herauszufinden, wo eine neue Klasse/Funktionalität ausgelöst werden soll.

Ein anderes Beispiel eines nützlichen Diagramms könnte ein Sequenzdiagramm sein, das die allgemeinen Schritte zeigt, die in einem Kommunikationsprotokoll auszuführen sind. Vielleicht hat jeder Schritt kleine Macken und Komplexitäten, aber es reicht wahrscheinlich aus, 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 ausführen sollten, wenn Sie im Code selbst nichts ausdrücken können. Wenn Sie UML-Diagramme verwenden, um den Quellcode selbst zu erklären, machen Sie den Soruce-Code stattdessen selbstdokumentierender.

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, haben Sie keine Angst, 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 Selbst), wenn Sie sie schreiben :)

9
epidemian

UML ist wertvoll, wenn die 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 nützlich findet.

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

8
pythoneer

Ich habe einmal an einem Gig gearbeitet, bei dem ich ein Team von Vertragsentwicklern in Übersee leiten musste.

Einige der Dinge, die sie produzierten, waren ziemlich schrecklich (ein häufiges Symptom für Remote-Vertragscodierer - 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 brauchte nicht so lange, um ein Programm in UML zu schreiben, viel schneller als in Java, und es war etwas, woran die Auftragnehmer folgen und daran gemessen werden 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

6
Victor Grazi

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

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

3
emory

Ich finde es in der ersten Entwurfsphase nützlich, Ideen auf Papier oder auf das Whiteboard zu bringen. Ich habe hauptsächlich UML-Klassendiagramme verwendet, ohne die Standards strikt einzuhalten. Es ist nützlich, Ihr UML-Originaldesign 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 nur durch Lesen von Code erreichen können, und hat sogar dazu beigetragen, potenzielle Fehler zu erkennen.

Es gibt einen guten Punkt hier von ragu.pattabi zwischen zwei Arten von UML zu unterscheiden ...

Ich denke, das agile Aroma von UML (z. B. schnelle Whiteboard-Skizze) ist erfolgreicher als das Wasserfall-Aroma von UML (z. B. ausgefeiltes Diagramm mit allen wichtigen Details für Dokumentation, Codegenerierung usw., um die dokumentenbewussten Manager glücklich zu machen).

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

2
dodgy_coder

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

Ich meine, wenn UML ein Betrachter des Codes ist, ist es für Dokumentationszwecke wirklich hilfreich, aber sicherlich nicht für die Codegenerierung. Das Projekt sollte codezentriert und sicherlich nicht modellgetrieben sein. UML sollte in der Implementierungsphase unter Verwendung eines Live-Codes und einer Modellsynchronisation verwendet werden. Ich meine nicht nur auf Anforderungsebene, was zu viel Investition für eine geringe Rendite in Produktivität und Qualität erfordert.

1
UML_Guru

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

Einige Programmierer halten Dokumentation für Zeitverschwendung. Aber das ist nicht wahr. Wenn Sie die Dokumentation auf elegante und klare Weise als Anzeige Ihrer Entwurfs- und Systemregeln betrachten, werden Sie sie möglicherweise mehr zu schätzen wissen. Außerdem muss man sich in die Position der Menschen versetzen, die das System warten müssen. 500 Codedateien zu werfen und gebeten zu werden, die Probleme damit zu beheben, ist zwar schlecht, aber nicht ungewöhnlich.

Ich schlage vor, Sie weisen Ihrem Projekt Zeit zu und erstellen die Diagramme in Zyklen. Die erste würde die allgemeinen Aspekte Ihres Projekts abdecken, und die nachfolgenden Ebenen könnten sich mehr mit den Details befassen.

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

1
NoChance

Ich benutze UML (oder etwas ähnliches wie UML :)), wenn ich mit Freunden über etwas spreche, das 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 von Code zu UML bringen. Und wenn ich UML benutze, zeichne ich auf Whiteboard oder Papier. Niemals in einem Tool wie Enterprise Architect.

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

1
Piotr Perak

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

Wenn Ihr Workflow auf UML basiert, um Ihre Architektur zu dokumentieren oder zu planen, wäre es dumm, sie zu löschen. Wenn UML die bestmögliche Möglichkeit ist, die Projektstruktur anderen Teammitgliedern (im weiteren Sinne) mitzuteilen, verwenden Sie sie auf jeden Fall. Aber wenn das Projekt ohne UML gut funktioniert, ist es Unsinn, UML-Diagramme nur deswegen zu erstellen.

1
tdammers

Ich habe einige Gedanken dazu. Sprache kann benutzt und missbraucht werden, zwingen und ablenken, auslösen und lullen. UML ist nur eine andere Sprache, die für eine bestimmte Reihe von Problemen geeignet ist. Wie bei jeder anderen 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 macht Ihre schlechten Designs nicht auf magische Weise verständlich. Wie bei jeder anderen Sprache ist es leicht, sich in Details zu verlieren oder zu viel der Fantasie zu überlassen.

UML bekam einen schlechten Ruf wegen der zahlreichen schrecklichen IDEs, die Round-Trip-Prototyping, klickintensive Grafikmanipulation und die Schwierigkeit, irgendetwas zu ändern, ermöglichten. UML 2.0 mag komplex genug sein, um bestimmte Wissenschaftler zufrieden zu stellen, aber sein Metamodell scheint nicht viele praktische Anwendungen anzulocken.

Trotzdem benutze ich von Zeit zu Zeit UML. Bewertung eines Entwurfs auf hoher Ebene (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.

1
Dibbeke

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

In dieser Art von Szenario sind die UML-Diagramme (oder die von Ihnen verwendete Modellierungssprache) auf lange Sicht selten nützlich, da sie im Laufe der Zeit und im Verlauf des Projekts tendenziell an Relevanz verlieren. Diese ersten Zeichnungen sind in wenigen Jahren meistens nutzlos und falsch, und es ist meistens schädlich, sie in der Nähe zu haben.

Die Verwendung von Modellierungswerkzeugen (nicht unbedingt UML) ist jedoch keine völlig nutzlose Praxis, wenn die Modelle eine tatsächliche Live- und relevante Eingabe für den tatsächlich ausgeführten Code liefern. Wenn die Modellbeschreibung ein nützliches Artefakt des Codes ist, sollte sie als Code behandelt werden:

Entweder indem Sie es als direkte Quelle für Metadaten verwenden, um dynamische Entscheidungen basierend auf den modellierten Konzepten zu treffen, oder indem Sie mithilfe der Codegenerierung statische Code-Artefakte generieren, die im eigentlichen Arbeitscode verwendet werden.

0
Roland Tepp

Normalerweise iteriere ich zwischen Code- und UML-Diagrammen. Ich finde, dass die Diagramme helfen, das Gesamtbild 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, neigt die Codierung dazu, trivial zu werden.

Umgekehrt, wenn ich den Code in Bildern zeichne, werden Abhängigkeitsprobleme aufgedeckt und Möglichkeiten zur Designverbesserung werden offensichtlich, 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 codieren und ein Albtraum, den man aufrechterhalten muss.

Ich habe festgestellt, dass eine Iteration erforderlich ist, da beim Zeichnen der Bilder immer wichtige Aspekte übersehen werden, während nur das Codieren zu problematischen Designs führt.

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 hängt es von den Personen, der Komplexität des Projekts und der Bedeutung der ordnungsgemäßen Funktionsweise des Systems ab.

0
Dunk

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

0
carlo

Ich liebe Diagramme, aber wenn ich gebeten würde, eines zu erstellen (insbesondere 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 jetzt mit jemandem zu kommunizieren, wird es nur verrotten. Und wenn die Person, mit der Sie kommunizieren, mit einer Textbeschreibung, einem Telefonanruf oder einem informellen Digramm auf einem Whiteboard besser zurechtkommt, schlagen Sie dies stattdessen vor.

0
Steve Bennett

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

0
James

UML ist nur dann von Wert, wenn die Benutzer des Systems den Code nicht selbst schreiben können. Das heißt, UML ist eine 'Sprache', die die Architekturkonzepte an eine andere Person weitergibt. Wenn Sie nun die Person sind, die den Code entwirft und implementiert, warum sollten Sie sich dann zeigen müssen, 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.

Wenn Sie jedoch ein Systemarchitekt wären, der Ihrem ausgelagerten Entwicklerteam mitteilen möchte, was Sie wollten, müssten Sie es ihnen irgendwie mitteilen, und hier kommt UML ins Spiel. Ich denke jedoch, dass es viele alternative Leistungsmethoden gibt Diese Aufgabe bedeutet heutzutage, und ehrlich gesagt, dass die Komplexität des UML-Diagramms bedeutet, dass jeder verstehen muss, wie man es liest, was etwas selbstzerstörerisch ist, wenn er es nicht tut.

0
gbjbaanb

Ich war nie ein Fan von UML, aber ich habe ein gutes Sequenzdiagramm zur Beschreibung der Interaktionen zwischen Systemen oder Aufgaben geschätzt.

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:

  • entscheidungen auf hoher Ebene (Architektur) sollten manuell dokumentiert werden
  • fakten auf niedriger Ebene (Entitätsbeziehungen) sollten automatisch extrahiert werden
0
Matthieu M.

Ich weiß nicht, ob es um den Nutzen von UML oder um den Verdienst beim Entwerfen der Architektur von Programmen geht.

Über UML. Normalerweise benötigen Sie nur: Anwendungsfälle, Klassendiagramme und Sequenzdiagramme. Einfach und leicht, obwohl Sie es 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, entwickeln Sie ihn einfach zurück. Wenn Sie es nicht geplant haben, wetten Sie, dass es ein schlechtes Design sein wird.

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

  3. Wenn Sie in einem Team arbeiten, ist Design erforderlich, um Lösungen zu diskutieren, Ideen zu übermitteln und sehr praktisch, aber notwendig, um Arbeit zu verteilen.

0
cibercitizen1