Ist UML praktisch?[geschlossen]

https://stackoverflow.com/questions/18803

09-06-2019
|

Frage

Im College hatte ich zahlreiche Design- und UML orientierte Kurse, und ich erkenne, dass UML insbesondere für ein Softwareprojekt von Nutzen sein kann Anwendungsfall Mapping, aber ist es wirklich praktisch?Ich habe ein paar Koop-Arbeitsbegriffe gemacht 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, weil es einfach schneller ist, sich die Header-Datei einer Klasse anzusehen.Welche Diagramme sind konkret am nützlichsten?

Bearbeiten: Meine Erfahrung beschränkt sich auf kleine Projekte mit weniger als 10 Entwicklern.

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

Lösung

In einem ausreichend komplexen System gibt es einige Stellen, an denen UML als nützlich erachtet wird.

Die nützlichen Diagramme für ein System variieren je nach Anwendbarkeit.Am weitesten verbreitet sind jedoch Zustandsdiagramme, Aktivitätsdiagramme und Sequenzdiagramme.

Es gibt viele Unternehmen, die darauf schwören, und viele, die sie als reine Zeit- und Arbeitsverschwendung völlig ablehnen.

Es ist am besten, es nicht zu übertreiben und darüber nachzudenken, was für das Projekt, an dem Sie arbeiten, am besten ist, und das auszuwählen, was anwendbar und sinnvoll ist.

Andere Tipps

Die Verwendung von UML ist so, als würde man beim Gehen auf die Füße schauen.Es geht darum, etwas bewusst und explizit zu machen, was man normalerweise unbewusst tun kann.Anfänger müssen sorgfältig darüber nachdenken, was sie tun, aber ein professioneller Programmierer weiß bereits, was er tut.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 kommt jedoch nicht nur darauf an, was Sie tun.Was ist mit dem neuen Mitarbeiter, der in sechs Monaten eintrifft und sich mit dem Code vertraut machen muss?Was ist, wenn in fünf Jahren alle, die derzeit an dem Projekt arbeiten, nicht mehr da sind?

Es ist unglaublich hilfreich, für jeden, der sich später dem Projekt anschließt, eine grundlegende, aktuelle Dokumentation 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 Grundverhalten von unschätzbarem Wert ist.Sofern sich das Design des Systems nicht drastisch ändert, sollten sich diese Informationen auch dann nicht wesentlich ändern, wenn die Implementierung optimiert wird.

Ich habe festgestellt, dass der Schlüssel zur Dokumentation in der Moderation liegt.Niemand wird 50 Seiten vollwertiger UML-Diagramme mit Designdokumentation lesen, ohne nach ein paar Seiten einzuschlafen.Andererseits würden die meisten Menschen gerne 5–10 Seiten mit einfachen Klassendiagrammen mit einigen grundlegenden Beschreibungen zum Aufbau des Systems erhalten.

Der andere Fall, in dem ich festgestellt habe, dass UML nützlich ist, ist, wenn ein leitender Entwickler für den Entwurf einer Komponente verantwortlich ist, den Entwurf dann aber einem Junior-Entwickler zur Implementierung übergibt.

Die Verwendung von UML ist so, als würde man beim Gehen auf die Füße schauen.Es geht darum, etwas bewusst und explizit zu machen, was man normalerweise unbewusst tun kann.Anfänger müssen sorgfältig darüber nachdenken, was sie tun, aber ein professioneller Programmierer weiß bereits, was er tut.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, wenn man nachts ohne Taschenlampe im Wald steht und es anfängt zu regnen – dann muss man auf seine Füße achten, um nicht herunterzufallen.Es gibt Zeiten, in denen die von Ihnen übernommene Aufgabe komplizierter ist, als Ihre Intuition bewältigen kann, und Sie langsamer vorgehen und die Struktur Ihres Programms explizit darlegen müssen.Dann ist UML eines von vielen Tools, die Sie verwenden können.Andere beinhalten Pseudocode, High-Level-Architekturdiagramme und seltsame Metaphern.

Generische Arbeitsabläufe 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.

Da muss ich widersprechen, UML wird überall verwendet – überall dort, wo ein IT-Projekt entworfen wird, ist UML normalerweise vorhanden.

Nun, ob es verwendet wird Also ist eine andere Sache.

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 z. B. Persistenz, darzustellen.Wenn es darum geht, jedes einzelne Attribut oder jede einzelne Eigenschaft hinzuzufügen, sind sie normalerweise übertrieben, insbesondere da sie nach dem Schreiben des Codes oft schnell veralten.

Eines der größten Probleme bei UML ist der Arbeitsaufwand, der erforderlich ist, um es nach der Codegenerierung auf dem neuesten Stand zu halten, da es nur wenige Tools gibt, die UML aus Code umgestalten können, und nur wenige, die dies gut können.

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

Die Art und Weise, wie ich UML und das sehe Rationaler einheitlicher Prozess ist, dass es mehr ist REDEN darüber, was Sie tun werden, als tatsächlich TUN was du tun wirst.

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

Meiner Meinung nach nur wegwerfen.UML ist ein großartiges Werkzeug zum Kommunizieren von Ideen. Das einzige Problem besteht darin, es zu speichern und zu verwalten, da Sie im Wesentlichen zwei Kopien derselben Informationen erstellen, und hier scheitert es normalerweise.Nach der ersten Implementierungsrunde sollte der Großteil der UML aus dem Quellcode generiert werden, da sie sonst sehr schnell veraltet oder (mit manuellen Fehlern) viel Zeit in Anspruch nimmt, um sie auf dem neuesten Stand zu halten.

In den letzten beiden Semestern meiner Schulzeit war ich Co-Dozent eines Entwicklungsprojektkurses für Oberstufenschüler.Das Projekt sollte in einer Produktionsumgebung mit lokalen gemeinnützigen Organisationen als zahlenden Kunden eingesetzt werden.Wir mussten sicher sein, dass der Code das tut, was wir erwartet haben, und dass die Studenten alle Daten erfassen, die zur Erfüllung der Kundenanforderungen erforderlich sind.

Die Unterrichtszeit war begrenzt, ebenso wie meine Zeit außerhalb des Klassenzimmers.Daher mussten wir bei jedem Klassentreffen Codeüberprüfungen durchführen, aber bei 25 eingeschriebenen Schülern war die Zeit für die einzelnen Überprüfungen sehr kurz.Das wertvollste Werkzeug, das wir in diesen Überprüfungssitzungen fanden, waren ERDs, Klassendiagramme und Sequenzdiagramme.ERDs und Klassendiagramme wurden nur in Visual Studio erstellt, sodass der Zeitaufwand für deren Erstellung für die Schüler gering war.

Die Diagramme vermittelten sehr schnell viele Informationen.Durch einen schnellen Überblick über die Entwürfe der Studenten konnten wir Problembereiche in ihrem Code schnell 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 durchzugehen und nach Problemen zu suchen.

Ich komme etwas spät zu diesem Thema und versuche nur, ein paar kleinere Punkte klarzustellen.Die Frage, ob UML nützlich ist, ist viel zu weit gefasst.Die meisten Leute schienen die Frage aus der typischen/populären UML-Perspektive als Zeichen-/Kommunikationstool zu beantworten.Notiz:Martin Fowler und andere UML-Buchautoren sind der Meinung, dass UML am besten nur für die Kommunikation verwendet wird.Es gibt jedoch viele andere Verwendungsmöglichkeiten für UML.UML ist vor allem eine Modellierungssprache, die Notation und Diagramme auf die logischen Konzepte abbildet.Hier sind einige Verwendungsmöglichkeiten für UML:

Kommunikation
Standardisierte Design-/Lösungsdokumentation
DSL-Definition (Domänenspezifische Sprache).
Modelldefinition (UML-Profile)
Muster/Asset-Nutzung
Codegenerierung
Modell-zu-Modell-Transformationen

Angesichts der Verwendungsliste oben ist der Beitrag von Pascal nicht ausreichend, da er sich nur auf die Diagrammerstellung bezieht.Ein Projekt könnte von UML profitieren, wenn einer der oben genannten Punkte kritische Erfolgsfaktoren oder Problembereiche sind, die einer standardisierten Lösung bedürfen.

Die Diskussion sollte darüber hinausgehen, wie UML übertrieben oder auf kleine Projekte angewendet werden kann, um zu diskutieren, wann UML sinnvoll ist oder das Produkt/die Lösung tatsächlich verbessert, da dann UML verwendet werden sollte.Es gibt Situationen, in denen UML für einen einzelnen Entwickler ebenfalls sinnvoll sein könnte, beispielsweise bei der Musteranwendung oder der Codegenerierung.

UML funktioniert seit Jahren für mich.Als ich anfing, las ich Fowlers UML destilliert wo er sagt: „Machen Sie genug Modellierung/Architektur/etc.“Benutzen Sie einfach das, was Sie möchten brauchen!

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

Ich halte die UML für nützlich, obwohl ich denke, dass die 2.0-Spezifikation die einst klare Spezifikation etwas aufgebläht und umständlich gemacht hat.Ich bin mit der Ausgabe von Zeitdiagrammen usw. einverstanden, da sie eine Lücke füllen ...

Der effektive Umgang mit UML erfordert ein wenig Übung.Der wichtigste Punkt ist, klar zu kommunizieren, bei Bedarf Vorbild zu sein und als Team vorzuleben.Whiteboards sind das beste Werkzeug, das ich gefunden habe.Ich habe keine „digitale Whiteboard-Software“ gesehen, die es geschafft hat, den Nutzen eines echten Whiteboards zu erfassen.

Davon abgesehen gefallen mir die folgenden UML-Tools:

Violett – Wenn es einfacher wäre, wäre es ein Stück Papier
Altova UModel – Gutes Tool für Java- und C#-Modellierung
MagicDraw – Mein liebstes kommerzielles Tool zum Modellieren
Poseidon – Ordentliches Werkzeug mit gutem Preis-Leistungs-Verhältnis
StarUML – Bestes Open-Source-Modellierungstool

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 Designs, der Entwicklung und des Tests verwendet werden.

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

Ein Modell kann Ihnen helfen, die Welt zu visualisieren, in der Ihr System funktioniert, die Bedürfnisse 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 lernt man „gutes Softwaredesign/-architektur“? bei https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Obwohl diese Diskussion schon seit langem inaktiv ist, möchte ich noch ein paar meiner Meinung nach wichtige Punkte hinzufügen.

Fehlerhafter Code ist eine Sache.Bleibt man stromabwärts treiben, kann es zu Designfehlern kommen sehr aufgedunsen und in der Tat hässlich.UML ist jedoch selbstvalidierend.Damit meine ich, dass dadurch, dass Sie Ihre Modelle in mehreren, mathematisch geschlossenen und sich gegenseitig prüfenden Dimensionen untersuchen können, ein robustes Design entsteht.

UML hat noch einen weiteren wichtigen Aspekt:es „spricht“ direkt mit unserer stärksten Fähigkeit, der Visualisierung.Wäre beispielsweise ITIL V3 (im Kern einfach genug) in Form von UML-Diagrammen kommuniziert worden, hätte es auf ein paar Dutzend A3-Faltblättern veröffentlicht werden können.Stattdessen erschien es in mehreren Bänden wahrhaft biblischen Ausmaßes, was eine ganze Branche, atemberaubende Kosten und einen weitverbreiteten katatonischen Schock hervorbrachte.

Ich sehe, dass Sequenzdiagramme und Aktivitätsdiagramme ziemlich häufig 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 erstelle gerne Anwendungsfalldiagramme, aber ich habe nicht 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 man durch UML-modellbasiertes Design erhält.Es ist aufgebläht, fehlerhaft, langsam, hässlich, ...

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

Im Grunde spielt es keine Rolle, was Sie verwenden, Sie müssen lediglich zwei Dinge im Hinterkopf behalten:

Sie möchten eine Art Architekturplanung
Sie möchten sicher sein, dass tatsächlich alle im Team die gleiche Technologie für die Projektplanung nutzen

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

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

UML ist nützlich, ja, tatsächlich!Die Hauptverwendungen, die ich daraus gemacht habe, waren:

Brainstorming darüber, wie eine Software funktionieren sollte.Es macht es einfach, zu kommunizieren, was Sie denken.
Dokumentieren 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 dieser kleine Kurs gedacht war.
Dokumentieren Sie alle Architekturmuster, die Sie auf allen Ihren Systemen verwenden, aus den gleichen Gründen wie im obigen Punkt

Ich bin nur anderer Meinung Michael wenn er das sagt Die Verwendung von UML für einen einzelnen Entwickler und/oder ein einfaches Softwareprojekt erscheint übertrieben zu ihm.Ich habe es bei meinen kleinen persönlichen Projekten verwendet, und die Dokumentation mit UML hat mir viel Zeit gespart, als ich sieben Monate später darauf zurückkam und völlig vergessen hatte, wie ich all diese Klassen erstellt und zusammengestellt hatte.

Ich glaube, es gibt möglicherweise eine Möglichkeit, um UML-Fisch-, Drachen- und Meeresnutzungsfälle zu verwenden, wie von Fowler in seinem Buch "UML Destilled" beschrieben. Meine Idee war es, Cockburn -Anwendungsfälle als Hilfe für die Lesbarkeit der Code zu verwenden.

Also habe ich ein Experiment durchgeführt 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 der Klasse und der inneren Klasse oder indem Sie die Namespaces für Aufzählungen verwenden).Ich glaube, dass dies eine praktikable und einfache Technik sein könnte, habe aber noch Fragen und brauche andere, die sie ausprobieren.Es könnte für einfache Programme nützlich sein, die eine Art pseudo-domänenspezifische Sprache benötigen, die ohne Spracherweiterungen direkt in der Mitte des C#-Codes existieren kann.

Bitte schauen Sie sich den Beitrag an, wenn Sie interessiert sind.Gehen Hier.

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 der Metamodelle und Meta-Meta-Modelle.Eines der Verkaufsargumente von UML ist, dass es weniger mehrdeutig ist als natürliche Sprache.Wenn jedoch zwei oder mehr Ingenieure ein Diagramm unterschiedlich interpretieren, scheitert es am Ziel.

Außerdem habe ich versucht, in mehreren UML-Foren und an Mitglieder der OMG selbst spezifische Fragen zum Superstrukturdokument zu stellen, mit wenig oder keinem Ergebnis.Ich glaube nicht, dass die UML-Community noch nicht reif genug ist, um sich selbst zu unterstützen.

Ich spreche von einem Studenten und finde, dass UML nur sehr wenig Nutzen hat.Ich finde es ironisch, dass PROGAMER noch kein Programm entwickelt haben, das automatisch die Dinge generiert, von denen Sie gesagt haben, dass sie notwendig sind.Es wäre äußerst einfach, eine Funktion in Visual Studio zu entwerfen, die Teile der Daten abrufen, nach Definitionen und Produktantworten suchen könnte, sodass jeder, egal ob groß oder klein, es sich ansehen und das Programm verstehen könnte.Dies würde es auch auf dem neuesten Stand halten, da die Informationen direkt aus dem Code entnommen würden, um die Informationen zu erzeugen.

UML kommt zum Einsatz, sobald man eine Klasse mit ihren Feldern und Methoden darstellt, obwohl es sich lediglich um eine Art UML-Diagramm handelt.

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

UML ist nur eine Sprache, nicht wirklich eine Methode.

Was mich betrifft, finde ich das Fehlen eines UML-Schemas für Opensource-Projekte wirklich ärgerlich.Nehmen Sie etwas wie Wordpress, Sie haben nur ein Datenbankschema, sonst nichts.Sie müssen sich in der Codex-API umsehen, um einen Überblick zu gewinnen.

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.

UML scheint für große Projekte mit großen Teams geeignet zu sein.Allerdings habe ich in kleinen Teams gearbeitet, in denen die Kommunikation besser ist.

Die Verwendung von UML-ähnlichen Diagrammen ist jedoch gut, insbesondere in der Planungsphase.Da ich eher im Code denke, fällt es mir schwer, große Spezifikationen zu schreiben.Ich bevorzuge es, die Ein- und Ausgänge aufzuschreiben und den Entwicklern die Gestaltung des Teils in der Mitte zu überlassen.

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 man eine gestrichelte Linie oder einen kreisförmigen Endpunkt verwendet – ist nicht ganz so notwendig, aber dennoch gut.

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

Ich glaube, dass die Verwendung von UML subjektiv von der Situation abhängt, in der das Entwicklungsteam arbeitet.

UML ist in zweierlei Hinsicht nützlich:

Technische Seite:Viele Leute (Manager und einige Funktionsanalysten) denken, dass UML ein Luxusfeature ist, weil Der Code ist die Dokumentation:Sie beginnen mit dem Codieren, nachdem Sie Fehler behoben und behoben haben.Die Synchronisierung von UML-Diagrammen mit Code und Analysen zwingt Sie dazu, die Anforderungen des Kunden gut zu verstehen;
Managementseite:Die UML-Diagramme sind ein Spiegelbild der ungenauen Anforderungen des Kunden:Wenn Sie ohne UML programmieren, können Sie nach vielen Arbeitsstunden möglicherweise einen Fehler in „requires“ finden.Die UML-Diagramme ermöglichen es Ihnen, mögliche Kontroversen zu finden und vor der Codierung zu lösen =>hilft Ihrer Planung.

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

wenn Sie in einer LinkedIn-Gruppe sind SYSTEMINGENIEURE, sehen meine alte diskussion.

Letztlich existiert UML nur wegen RUP.Benötigen wir UML oder ähnliches, um Java/.Net zu verwenden?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 nein danke.

UML ist auf jeden Fall hilfreich, genauso wie Junit unerlässlich ist.Es hängt alles davon ab, wie Sie die Idee verkaufen.Ihr Programm funktioniert ohne UML genauso, wie es ohne Unit-Tests funktionieren würde.Allerdings sollten Sie UML so erstellen, dass es mit Ihrem Code verbunden ist, d. h. wenn Sie UML-Diagramme aktualisieren, aktualisiert es Ihren Code, oder wenn Sie Ihren Code aktualisieren, generiert es automatisch die UML.Tun Sie es nicht nur, um es zu tun.

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

UML ist nur eine der Methoden zur Kommunikation zwischen Menschen.Whiteboard ist besser.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow