Ist UML praktisch? [geschlossen]

114

Im College hatte ich zahlreiche Design- und UML- orientierte Kurse und ich erkenne, dass UML zum Nutzen eines Softwareprojekts verwendet werden kann, insbesondere zum Use-Case- Mapping. Aber ist es wirklich praktisch? Ich habe einige Begriffe für Koop-Arbeiten verwendet, und es scheint, dass UML in der Branche nicht häufig verwendet wird. Lohnt es sich während eines Projekts, UML-Diagramme zu erstellen? Außerdem finde ich, dass Klassendiagramme im Allgemeinen nicht nützlich sind, da es nur schneller ist, die Header-Datei für eine Klasse zu betrachten. Welche Diagramme sind speziell am nützlichsten?

Bearbeiten: Meine Erfahrung beschränkt sich auf kleine Projekte unter 10 Entwicklern.

Bearbeiten: Viele gute Antworten, und obwohl nicht die ausführlichste, glaube ich, dass die ausgewählte die ausgewogenste ist.

Chris
quelle
4
Die Ergebnisse einer Umfrage aus dem Jahr 2013 zeigen, dass es nicht so häufig verwendet wird, wie es Professoren für Softwareentwicklung erwarten (!), Und einige Gründe dafür aufzeigen
Fuhrmanator

Antworten:

47

In einem ausreichend komplexen System gibt es einige Stellen, an denen einige UMLals nützlich angesehen werden.

Die nützlichen Diagramme für ein System variieren je nach Anwendbarkeit.
Die am häufigsten verwendeten sind jedoch:

  • Klassendiagramme
  • Zustandsdiagramme
  • Aktivitätsdiagramme
  • Sequenzdiagramme

Es gibt viele Unternehmen, die auf sie schwören, und viele, die sie als völlige Verschwendung von Zeit und Mühe ablehnen.

Es ist am besten, nicht über Bord zu gehen und zu überlegen, was für das Projekt, an dem Sie arbeiten, am besten ist, und das Material auszuwählen, das anwendbar und sinnvoll ist.

Pascal
quelle
83

Die Verwendung von UML ist wie das Betrachten Ihrer Füße beim Gehen. Es macht bewusst und explizit etwas, was Sie normalerweise unbewusst tun können. Anfänger müssen sorgfältig überlegen, was sie tun, aber ein professioneller Programmierer weiß bereits, was sie tun. Meistens ist das Schreiben des Codes selbst schneller und effektiver als das Schreiben über den Code, da ihre Programmierintuition auf die Aufgabe abgestimmt ist.

Es geht aber nicht nur darum, was Sie tun. Was ist mit dem neuen Mitarbeiter, der in sechs Monaten kommt und den Code auf den neuesten Stand bringen muss? Wie sieht es in fünf Jahren aus, wenn alle, die derzeit an dem Projekt arbeiten, verschwunden sind?

Es ist unglaublich hilfreich, für jeden, der sich später dem Projekt anschließt, einige grundlegende, aktuelle Dokumentationen zur Verfügung zu haben. Ich befürworte keine vollständigen UML-Diagramme mit Methodennamen und -parametern (viel zu schwierig zu pflegen), aber ich denke, dass ein grundlegendes Diagramm der Komponenten im System mit ihren Beziehungen und ihrem grundlegenden Verhalten von unschätzbarem Wert ist. Sofern sich das Design des Systems nicht drastisch ändert, sollten sich diese Informationen nicht wesentlich ändern, selbst wenn die Implementierung optimiert wird.

Ich habe festgestellt, dass der Schlüssel zur Dokumentation die Moderation ist. Niemand wird 50 Seiten ausgewachsener UML-Diagramme mit Konstruktionsdokumentation lesen, ohne ein paar Seiten einzuschlafen. Andererseits würden die meisten Leute gerne 5-10 Seiten einfacher Klassendiagramme mit einigen grundlegenden Beschreibungen erhalten, wie die System wird zusammengestellt.

Der andere Fall, in dem ich UML als nützlich empfunden habe, ist, wenn ein leitender Entwickler für das Entwerfen einer Komponente verantwortlich ist und das Design dann einem Junior-Entwickler zur Implementierung übergibt.

17 von 26
quelle
31
"Was ist mit dem neuen Mitarbeiter, der in sechs Monaten kommt und den Code auf den neuesten Stand bringen muss?" Ähm ... wie wäre es mit einem Blick auf den Code? Dies ist die einzige genaue und vollständige Methode, um den Code auf den neuesten Stand zu bringen. Auch der natürlichste Weg, wenn man bedenkt, dass wir Programmierer sind. Ich halte die Vorstellung, dass wir uns ein Diagramm ansehen müssen, um Code zu verstehen, für lächerlich und bedrückend, dass dieser Müll irgendwie weit verbreitet wurde.
BobTurbo
6
Ich stimme BobTurbo zu, ich hatte noch nie eine Verwendung für UML, insbesondere für die UML eines anderen. Ich gehe immer lieber direkt zum Code.
James Adam
7
Ich habe festgestellt, dass das Zeichnen eines UML-Klassendiagramms vor dem Beginn der Codierung mir Zeit gespart hat. Dadurch konnte ich Konstruktionsfehler und -fehler visualisieren und diese mit meinen Kollegen besprechen. Besser noch, wenn sie mit CASE-Tools gezeichnet werden, generieren sie den grundlegenden Strukturcode Ihrer App. Die Amortisation ist also dreifach.
Andrew S
1
@ James Adam, kein Diagramm soll das Betrachten des Codes ersetzen, aber in riesigen Codebasen (versuchen Sie es mit Millionen Codezeilen) kann eine bessere Übersicht über das System viel Zeit und Nerven sparen.
Serine
10
Ein Bild sagt immer noch mehr als tausend Worte, selbst wenn es sich um den Code @BobTurbo handelt. Ich sehe kein vernünftiges Argument dagegen - und das schließt Argumente ein, die mit "Nun, echte Programmierer ..." beginnen. Wenn ich mit meinem Team über Architektur sprechen will, werde ich kein Klebeband machen 10 Seiten Quellcode auf ein Whiteboard.
DavidS
34

Die Verwendung von UML ist wie das Betrachten Ihrer Füße beim Gehen. Es macht bewusst und explizit etwas, was Sie normalerweise unbewusst tun können. Anfänger müssen sorgfältig überlegen, was sie tun, aber ein professioneller Programmierer weiß bereits, was sie tun. Meistens ist das Schreiben des Codes selbst schneller und effektiver als das Schreiben über den Code, da ihre Programmierintuition auf die Aufgabe abgestimmt ist.

Die Ausnahme ist, warum Sie sich nachts ohne Fackel im Wald befinden und es anfängt zu regnen - dann müssen Sie auf Ihre Füße schauen, um nicht herunterzufallen. Es gibt Zeiten, in denen die von Ihnen übernommene Aufgabe komplizierter ist, als Ihre Intuition bewältigen kann, und Sie müssen die Struktur Ihres Programms verlangsamen und explizit angeben. Dann ist UML eines von vielen Tools, die Sie verwenden können. Andere umfassen Pseudocode, Architekturdiagramme auf hoher Ebene und seltsame Metaphern.

Marcus Downing
quelle
3
Das Seltsame an dieser Website ist, dass man im ersten Absatz nicht sagen kann, dass man jemanden zitiert und dann nicht damit einverstanden ist. Aber ja, stimmt: Pseudocode ist auch eine großartige Diagrammtechnik und wird sehr häufig verwendet. Seltsame Metaphern mit Hölzern, Fackeln usw. sind ebenfalls großartig.
Dan Rosenstark
stimme überhaupt nicht zu - wenn du komplexe Komponenten herstellst - uml ist ein Muss
yehonatan yehezkel
18

Generische Workflows und DFDs können für komplexe Prozesse sehr nützlich sein. Alle anderen Diagramme (INSBESONDERE UML) waren meiner Erfahrung nach ausnahmslos eine schmerzhafte Zeit- und Arbeitsverschwendung.

Stu
quelle
16

Ich muss nicht zustimmen, UML wird überall verwendet - überall dort, wo ein IT-Projekt entworfen wird, ist UML normalerweise dort.

Ob es nun gut genutzt wird, ist eine andere Frage.

Wie Stu sagte, finde ich sowohl Anwendungsfälle (zusammen mit den Anwendungsfallbeschreibungen) als auch Aktivitätsdiagramme aus Entwicklersicht am hilfreichsten.

Klassendiagramme können sehr nützlich sein, wenn Sie versuchen, Beziehungen sowie Objektattribute wie die Persistenz anzuzeigen. Wenn es darum geht, einzelne Attribute oder Eigenschaften hinzuzufügen, sind sie normalerweise übertrieben, zumal sie nach dem Schreiben von Code häufig schnell veraltet sind.

Eines der größten Probleme mit UML ist der Arbeitsaufwand, der erforderlich ist, um es nach dem Generieren von Code auf dem neuesten Stand zu halten, da es nur wenige Tools gibt, die UML aus Code neu konstruieren können, und nur wenige, die es noch gut machen.

Samjudson
quelle
14

Ich werde meine Antwort qualifizieren, indem ich erwähne, dass ich keine Erfahrung in großen (IBM-ähnlichen) Unternehmensentwicklungsumgebungen habe.

Die Art , wie ich UML und der Blick Rational Unified Process ist , dass es mehr TALKING über das, was Sie tun werden , als tatsächlich TUT , was Sie tun werden.

(Mit anderen Worten, es ist größtenteils Zeitverschwendung)

Seibar
quelle
9
Ich werde dich nicht ablehnen, weil ich denke, dass es eine gute Antwort ist, aber ich könnte nicht mehr widersprechen. Jedes Mal, wenn ich etwas grafisch darstelle, spare ich mir Stunden oder Monate Entwicklungszeit und entwickle mich fast immer alleine (in letzter Zeit).
Dan Rosenstark
2
Wenn Sie darüber sprechen und schreiben, was Sie tun möchten, können Sie und andere mögliche Probleme früher verstehen und erkennen.
Kamran Bigdely
12

Nur meiner Meinung nach wegwerfen. UML ist ein großartiges Werkzeug für die Kommunikation von Ideen. Das einzige Problem besteht darin, dass Sie es speichern und pflegen, da Sie im Wesentlichen zwei Kopien derselben Informationen erstellen und hier normalerweise die Luft sprengt. Nach der ersten Implementierungsrunde sollte der größte Teil der UML aus dem Quellcode generiert werden, da sie sonst sehr schnell veraltet ist oder viel Zeit (mit manuellen Fehlern) benötigt, um auf dem neuesten Stand zu bleiben.

Streit
quelle
Beeindruckend. Was ist mit einem Tool, das das Diagramm mit dem Code synchronisiert und umgekehrt, wie z. B. Together?
Dan Rosenstark
1
Die Tatsache, dass UML aus der Quelle generiert werden kann, bedeutet für mich, dass das Lesen der UML keinen Vorteil gegenüber dem Lesen der Quelle hat. Mit anderen Worten, es ist eine Verschwendung.
Marcus Downing
1
@MarcusDowning Nein, es hilft Neueinstellungen massiv. UML ist schneller zu betrachten als der Code.
Kamran Bigdely
10

In den letzten beiden Semestern in der Schule unterrichtete ich gemeinsam einen Kurs für ein Entwicklungsprojekt auf hoher Ebene. Das Projekt sollte in einer Produktionsumgebung mit lokalen gemeinnützigen Organisationen als zahlenden Kunden eingesetzt werden. Wir mussten sicher sein, dass der Code das tat, was wir erwartet hatten, und dass die Schüler alle Daten erfassten, die zur Erfüllung der Kundenanforderungen erforderlich waren.

Die Unterrichtszeit war begrenzt, ebenso wie meine Zeit außerhalb des Klassenzimmers. Aus diesem Grund mussten wir bei jedem Klassentreffen Codeüberprüfungen durchführen, aber mit 25 eingeschriebenen Schülern war die individuelle Überprüfungszeit sehr kurz. Das Werkzeug, das wir in diesen Überprüfungssitzungen als am wertvollsten empfanden, waren ERDs, Klassendiagramme und Sequenzdiagramme. ERDs und Klassendiagramme wurden nur in Visual Studio erstellt, daher war die für ihre Erstellung erforderliche Zeit für die Schüler trivial.

Die Diagramme übermittelten sehr schnell viele Informationen. Durch einen schnellen Überblick über die Entwürfe der Schüler konnten wir schnell Problembereiche in ihrem Code isolieren und vor Ort eine detailliertere Überprüfung durchführen.

Ohne die Verwendung von Diagrammen hätten wir uns die Zeit nehmen müssen, die Codedateien der Schüler einzeln nach Problemen zu durchsuchen.

Jason Sparks
quelle
+1 Eine gute Visualisierung der Daten hilft dabei, Probleme und Trends aufzudecken, die sonst durch nicht relevante Details verdeckt werden.
Vlad Gudim
8

Ich komme etwas spät zu diesem Thema und werde nur versuchen, ein paar kleinere Punkte zu klären. Fragen, ob UML viel zu weit gefasst ist. Die meisten Leute schienen die Frage aus der typischen / populären UML als Zeichen- / Kommunikationswerkzeugperspektive zu beantworten. Hinweis: Martin Fowler und andere UML-Buchautoren sind der Ansicht, dass UML am besten nur für die Kommunikation verwendet wird. Es gibt jedoch viele andere Verwendungszwecke für UML. UML ist vor allem eine Modellierungssprache, deren Notation und Diagramme den logischen Konzepten zugeordnet sind. Hier sind einige Verwendungszwecke für UML:

  • Kommunikation
  • Standardisierte Design- / Lösungsdokumentation
  • DSL-Definition (Domain Specific Language)
  • Modelldefinition (UML-Profile)
  • Verwendung von Mustern / Assets
  • Codegenerierung
  • Modell-zu-Modell-Transformationen

Angesichts der obigen Verwendungsliste reicht die Veröffentlichung durch Pascal nicht aus, da sie nur für die Erstellung von Diagrammen spricht. Ein Projekt könnte von UML profitieren, wenn einer der oben genannten Faktoren kritische Erfolgsfaktoren oder Problembereiche sind, die eine standardisierte Lösung benötigen.

Die Diskussion sollte dahingehend erweitert werden, wie UML übermäßig beendet oder auf kleine Projekte angewendet werden kann, um zu diskutieren, wann UML sinnvoll ist oder das Produkt / die Lösung tatsächlich verbessern wird, da dann UML verwendet werden sollte. Es gibt Situationen, in denen UML für einen Entwickler ebenfalls erkennbar ist, z. B. Musteranwendung oder Codegenerierung.

Ted Johnson
quelle
5

UML arbeitet seit Jahren für mich. Als ich anfing, las ich Fowlers UML Distilled, wo er sagt "mach genug Modellierung / Architektur / etc." Verwenden Sie einfach, was Sie brauchen !

Sean Kearon
quelle
4

Aus Sicht eines QS-Ingenieurs weisen UML-Diagramme auf mögliche Fehler in Logik und Denken hin. Erleichtert meine Arbeit :)

Nick Stinemates
quelle
3

Ich denke, die UML ist nützlich, obwohl ich denke, dass die 2.0-Spezifikation eine ehemals klare Spezifikation etwas aufgebläht und umständlich gemacht hat. Ich stimme der Ausgabe von Zeitdiagrammen usw. zu, da sie eine Lücke füllten ...

Das Erlernen des effektiven Gebrauchs der UML erfordert ein wenig Übung. Der wichtigste Punkt ist, klar zu kommunizieren, bei Bedarf zu modellieren und als Team zu modellieren. Whiteboards sind das beste Werkzeug, das ich gefunden habe. Ich habe keine "digitale Whiteboard-Software" gesehen, die es geschafft hat, den Nutzen eines tatsächlichen Whiteboards zu erfassen.

Davon abgesehen mag ich die folgenden UML-Tools:

  1. Violett - Wenn es einfacher wäre, wäre es ein Stück Papier

  2. Altova UModel - Gutes Tool für Java- und C # -Modellierung

  3. MagicDraw - Mein bevorzugtes kommerzielles Tool zum Modellieren

  4. Poseidon - Ordentliches Werkzeug mit gutem Preis-Leistungs-Verhältnis

  5. StarUML - Bestes Open Source-Modellierungswerkzeug
Daniel Honig
quelle
3

UML-Diagramme sind nützlich, um Anforderungen zu erfassen und zu kommunizieren und sicherzustellen, dass das System diese Anforderungen erfüllt. Sie können iterativ und in verschiedenen Phasen der Planung, des Entwurfs, der Entwicklung und des Testens verwendet werden.

Aus dem Thema: Verwenden von Modellen im Entwicklungsprozess unter http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

Mithilfe eines Modells können Sie die Welt visualisieren, in der Ihr System funktioniert, die Anforderungen der Benutzer klären, die Architektur Ihres Systems definieren, den Code analysieren und sicherstellen, dass Ihr Code den Anforderungen entspricht.

Vielleicht möchten Sie auch meine Antwort auf den folgenden Beitrag lesen:

Wie lerne ich „gutes Software-Design / Architektur“? unter /programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Esther Fan - MSFT
quelle
3

Obwohl diese Diskussion seit langem inaktiv ist, muss ich noch einige wichtige Punkte hinzufügen.

Buggy-Code ist eine Sache. Designfehler können sehr aufgebläht und hässlich werden. UML ist jedoch selbstvalidierend. Damit meine ich, dass Sie ein robustes Design erhalten, wenn Sie Ihre Modelle in mehreren, mathematisch geschlossenen und sich gegenseitig überprüfenden Dimensionen untersuchen können.

UML hat einen weiteren wichtigen Aspekt: ​​Es "spricht" direkt mit unserer stärksten Fähigkeit, der Visualisierung. Wäre beispielsweise ITIL V3 (im Grunde genommen einfach genug) in Form von UML-Diagrammen kommuniziert worden, hätte es auf einigen Dutzend A3-Faltblättern veröffentlicht werden können. Stattdessen erschien es in mehreren Bänden von wirklich biblischem Ausmaß, was eine ganze Branche hervorbrachte, atemberaubende Kosten und einen weit verbreiteten katatonischen Schock.

Schläger
quelle
2
Haben Sie den UML-Standard gelesen? Es hat KEINEN mathematischen Hintergrund und sogar interne Inkonsistenzen. Es ist auch sehr schwer zu verstehen: Beispielsweise werden abgerundete Rechtecke für zwei völlig unterschiedliche Dinge verwendet (Zustände in Zustandsmaschinen und Aktionen und Aktivitäten in Aktivitätsdiagrammen). Es ist furchtbar.
Vainolo
2

Ich sehe Sequenzdiagramme und Aktivitätsdiagramme, die ziemlich oft verwendet werden. Ich arbeite viel mit "Echtzeit" - und eingebetteten Systemen, die mit anderen Systemen interagieren, und Sequenzdiagramme sind sehr hilfreich bei der Visualisierung aller Interaktionen.

Ich mache gerne Anwendungsfalldiagramme, aber ich habe nicht zu viele Leute getroffen, die sie für wertvoll halten.

Ich habe mich oft gefragt, ob Rational Rose ein gutes Beispiel für die Art von Anwendungen ist, die Sie durch UML-Modell-basiertes Design erhalten. Es ist aufgebläht, fehlerhaft, langsam, hässlich, ...

Kristopher Johnson
quelle
2

Ich fand UML nicht sehr nützlich für sehr kleine Projekte, aber wirklich geeignet für größere.

Im Wesentlichen spielt es keine Rolle, was Sie verwenden, Sie müssen nur zwei Dinge beachten:

  • Sie möchten eine Art Architekturplanung
  • Sie möchten sicher sein, dass jeder im Team tatsächlich dieselbe Technologie für die Projektplanung verwendet

UML ist genau das: Ein Standard für die Planung Ihrer Projekte. Wenn Sie neue Mitarbeiter einstellen, ist es wahrscheinlicher, dass Sie einen vorhandenen Standard kennen - sei es UML, Flowchard, Nassi-Schneiderman oder was auch immer - als Ihre bestehenden internen Mitarbeiter.

Die Verwendung von UML für einen einzelnen Entwickler und / oder ein einfaches Softwareprojekt scheint mir übertrieben, aber wenn ich in einem größeren Team arbeite, würde ich definitiv einen Standard für die Planung von Software wollen.

Michael Stum
quelle
2

UML ist nützlich, ja in der Tat! Die Hauptverwendungen, die ich daraus gemacht habe, waren:

  • Brainstorming über die Funktionsweise einer Software. Es macht es einfach zu kommunizieren, was Sie denken.
  • Dokumentation der Architektur eines Systems, seiner Muster und der Hauptbeziehungen seiner Klassen. Es hilft, wenn jemand in Ihr Team eintritt, wenn Sie gehen und sicherstellen möchten, dass Ihr Nachfolger es versteht, und wenn Sie schließlich vergessen, wofür zum Teufel diese kleine Klasse gedacht war.
  • Dokumentieren Sie alle Architekturmuster, die Sie auf allen Ihren Systemen verwenden, aus den gleichen Gründen wie oben

Ich bin mit Michael nicht einverstanden, wenn er sagt, dass die Verwendung von UML für einen einzelnen Entwickler und / oder ein einfaches Softwareprojekt für ihn übertrieben erscheint . Ich habe es für meine kleinen persönlichen Projekte verwendet, und die Dokumentation mit UML hat mir viel Zeit gespart, als ich sieben Monate später zu ihnen zurückkam und völlig vergessen hatte, wie ich all diese Klassen aufgebaut und zusammengestellt hatte.

Mario Marinato -br-
quelle
2

Ich glaube, es gibt eine Möglichkeit, UML-Anwendungsfälle für Fische, Drachen und Meeresspiegel im Cockburn-Stil zu verwenden, wie sie von Fowler in seinem Buch "UML Distilled" beschrieben wurden. Meine Idee war es, Cockburn-Anwendungsfälle als Hilfsmittel für die Lesbarkeit von Code zu verwenden.

Also habe ich ein Experiment gemacht und es gibt hier einen Beitrag darüber mit dem Tag "UML" oder "FOWLER". Es war eine einfache Idee für c #. Finden Sie eine Möglichkeit, Cockburn-Anwendungsfälle in die Namespaces von Programmierkonstrukten einzubetten (z. B. die Namespaces für Klassen und innere Klassen oder indem Sie die Namespaces für Aufzählungen verwenden). Ich glaube, dies könnte eine praktikable und einfache Technik sein, habe aber noch Fragen und brauche andere, um sie zu überprüfen. Dies kann für einfache Programme hilfreich sein, die eine Art pseudodomänenspezifische Sprache benötigen, die ohne Spracherweiterungen mitten im c # -Code vorhanden sein kann.

Bitte überprüfen Sie den Beitrag, wenn Sie interessiert sind. Geh hierher .

Primzahlen getäuscht
quelle
2

Eines der Probleme, die ich mit UML habe, ist die Verständlichkeit der Spezifikation. Wenn ich versuche, die Semantik eines bestimmten Diagramms wirklich zu verstehen, verliere ich mich schnell im Labyrinth von Metamodellen und Metamodellen. Eines der Verkaufsargumente von UML ist, dass es weniger mehrdeutig ist als die natürliche Sprache. Wenn jedoch zwei oder mehr Ingenieure ein Diagramm unterschiedlich interpretieren, schlägt es am Ziel fehl.

Außerdem habe ich in mehreren UML-Foren und bei Mitgliedern der OMG selbst versucht, bestimmte Fragen zum Superstrukturdokument zu stellen, ohne oder mit nur geringen Ergebnissen. Ich denke nicht, dass die UML-Community ausgereift genug ist, um sich selbst zu unterstützen.

Trent
quelle
2

Ich komme von einem Studenten und finde, dass UML sehr wenig Sinn hat. Ich finde es ironisch, dass PROGAMER noch kein Programm entwickelt haben, das automatisch die Dinge generiert, die Sie für notwendig gehalten haben. Es wäre äußerst einfach, eine Funktion in Visual Studio zu entwerfen, mit der Teile der Daten abgerufen, nach Definitionen und Produktantworten gesucht werden können, damit jeder sie sich ansehen kann, ob groß oder klein, und das Programm verstehen kann. Dies würde es auch auf dem neuesten Stand halten, da es die Informationen direkt aus dem Code entnehmen würde, um die Informationen zu erzeugen.

Mike
quelle
Es ist nicht so leicht! Wenn Sie Reverse Engineering verwenden, um ein UML-Modell aus echtem Code zu extrahieren, werden in Ihrem UML-Modell in der Regel so viele Details angezeigt, dass es nutzlos ist. Zweifellos wird dies von Forschern verfolgt, aber es ist kein leicht zu lösendes Problem.
ComDubh
2

UML wird verwendet, sobald Sie eine Klasse mit ihren Feldern und Methoden darstellen, obwohl es sich nur um eine Art UML-Diagramm handelt.

Das Problem mit UML ist, dass das Gründerbuch zu vage ist.

UML ist nur eine Sprache, es ist nicht wirklich eine Methode.

Was mich wirklich nervt, ist das Fehlen eines UML-Schemas für Opensource-Projekte. Nehmen Sie so etwas wie Wordpress, Sie haben nur ein Datenbankschema, sonst nichts. Sie müssen durch die Codex-API wandern, um das Gesamtbild zu erhalten.

programmernovice
quelle
1

UML hat seinen Platz. Mit zunehmender Größe des Projekts wird es immer wichtiger. Wenn Sie ein Projekt mit langer Laufzeit haben, ist es am besten, alles in UML zu dokumentieren.

Vaibhav
quelle
Oder zumindest die wichtigsten Designprobleme.
Silvercode
1

UML scheint für große Projekte mit großen Teams von Menschen gut zu sein. Ich habe jedoch in kleinen Teams gearbeitet, in denen die Kommunikation besser ist.

Die Verwendung von UML-ähnlichen Diagrammen ist jedoch besonders in der Planungsphase gut. Ich neige dazu, in Code zu denken, daher fällt es mir schwer, große Spezifikationen zu schreiben. Ich ziehe es vor, die Ein- und Ausgänge aufzuschreiben und die Entwickler das Bit in der Mitte entwerfen zu lassen.

graham.reeds
quelle
1
Auch in etwas kleineren Projekten ist es meiner Meinung nach frustrierend, durch Kommunikation zu arbeiten. Wenn Sie ständig viele Dinge fragen und erzählen müssen, unterbricht dies die Arbeit und es werden keine Dokumente erstellt. Stattdessen sollten die wichtigsten Gestaltungsprinzipien dokumentiert und modelliert werden.
Silvercode
1

Ich glaube, UML ist nur deshalb nützlich, weil es die Leute dazu bringt, über die Beziehungen zwischen ihren Klassen nachzudenken. Es ist ein guter Ausgangspunkt, um über solche Beziehungen nachzudenken, aber es ist definitiv nicht für jeden eine Lösung.

Meiner Meinung nach ist die Verwendung von UML subjektiv für die Situation, in der das Entwicklungsteam arbeitet.

Adam Mika
quelle
0

Durch meine Erfahrung:

Die Fähigkeit, aussagekräftige Codediagramme zu erstellen und zu kommunizieren, ist eine notwendige Fähigkeit für jeden Softwareentwickler, der neuen Code entwickelt oder versucht, vorhandenen Code zu verstehen.

Die Besonderheiten von UML zu kennen - wann eine gestrichelte Linie oder ein Kreisendpunkt verwendet werden soll - ist nicht ganz so notwendig, aber dennoch gut zu haben.

David Koelle
quelle
0

UML ist auf zwei Arten nützlich:

  • Technische Seite: Viele Leute (Manager und einige funktionale Analysten) halten UML für eine Luxusfunktion, da der Code die Dokumentation ist: Sie beginnen mit dem Codieren, nachdem Sie debuggt und behoben haben . Die Synchronisierung von UML-Diagrammen mit Code und Analysen zwingt Sie dazu, die Anforderungen des Kunden gut zu verstehen.

  • Verwaltungsseite: Die UMl-Diagramme spiegeln die Anforderungen des Kunden wider, der ungenau ist: Wenn Sie ohne UML codieren, können Sie möglicherweise nach vielen Stunden Arbeit einen Fehler in den Anforderungen finden. Mit den UML-Diagrammen können Sie mögliche Kontroversen finden und vor der Codierung auflösen => Ihre Planung unterstützen.

Im Allgemeinen haben alle Projekte ohne UML-Diagramme eine oberflächliche Analyse oder eine kurze Größe.

Wenn Sie in der Linkedin-Gruppe SYSTEMS ENGINEERS sind , lesen Sie meine alte Diskussion .

alepuzio
quelle
-1

Am Ende existiert UML nur wegen RUP. Benötigen wir UML oder ähnliches, um Java / .Net verwenden zu können? Die praktische Antwort ist, dass sie über eine eigene Dokumentation (Javadoc usw.) verfügen, die ausreicht und es uns ermöglicht, unsere Arbeit zu erledigen!

UML kein Dank.

mP.
quelle
Bei RUP geht es um Prozessmanagement, bei UML um Sprache. UML ist nützlich, wenn Sie mit vielen Menschen zu tun haben und eine gemeinsame Sprache benötigen.
Programmernovice
1
Schon mal was von chinesischen Whispiers gehört - je mehr man von einer Form in eine andere übersetzt, desto mehr schleichen sich Unterschiede und Fehler ein. Wenn UML so gut ist, warum nehmen Microsoft, Sun und Google UML nicht in ihre Produktdetails auf? Es wird Ihnen schwer fallen, welche zu finden. Was ist mit dem Werkzeug passiert? Vorwärts- / Rückwärts-Zwei-Wege-Werkzeuge? Sie existieren nicht, weil diese Modeerscheinung aufgrund mangelnder Verdienste gestorben ist.
mP.
-1

UML ist definitiv hilfreich, genauso wie Junit wichtig ist. Es hängt alles davon ab, wie Sie die Idee verkaufen. Ihr Programm funktioniert ohne UML genauso wie ohne Unit-Tests. Allerdings sollten Sie do UML erstellen, da es mit Ihrem Code verbunden ist, dh wenn Sie UML-Diagramme aktualisieren, wird Ihr Code aktualisiert, oder wenn Sie Ihren Code aktualisieren, wird die UML automatisch generiert. Tun Sie das nicht nur, um es zu tun.

fastcodejava
quelle
-2

UML hat definitiv seinen Platz in der Branche. Stellen Sie sich vor, Sie erstellen Software für Boing-Flugzeuge oder ein anderes komplexes System. UML und RUP wären hier eine große Hilfe.

EdinD
quelle
-3

UML ist nur eine der Kommunikationsmethoden innerhalb von Menschen. Whiteboard ist besser.

Popopome
quelle