design - tool - visual paradigm




Verwenden Sie immer noch UML? Wie? Wozu? (13)

Vor ein paar Jahren war jeder in unserem Geschäft verrückt nach UML . Jetzt scheint sich jeder abgekühlt zu haben.

Ich bin gespannt, ob UML in Softwareprojekten noch weit verbreitet ist.

Wenn ja, ist diese Nutzung auf Whiteboarding beschränkt? Verwenden Sie es zur Dokumentation? Verwenden Sie Tools, um daraus Code zu generieren?

Verbunden:

Ist UML praktisch?


Hängt von der Zielgruppe und dem Zweck dessen ab, was Sie zeichnen (vorausgesetzt, Sie verwenden UML als visuelle Modellierungssprache und nicht als weniger gebräuchliche abstraktere Form).

Wenn Sie die Steuerungsreihenfolge oder die Klassenhierarchie mit anderen Ingenieuren kommunizieren, sind die UML-Diagramme ideal.

Wenn Sie Makro-Anwendungsarchitekturen an Kunden oder Senior-Tech-Manager kommunizieren, würden Sie wahrscheinlich Powerpoint finden, egal wie stark Sie Ihre Nase halten müssen, effektiver

Eine gute Übersicht über die Schwächen von UML für einige häufig benötigte Diagramme von Architekturansichten finden Sie unter Dokumentieren von Softwarearchitekturen .

Noch ein Tipp - verwenden Sie ein PlantUml wie das ausgezeichnete PlantUml - es gibt ein sehr einfaches DSL zu lernen, und dann können Sie sich auf die Bedeutung konzentrieren, statt Visio in gerade Linien zu ziehen oder ein enormes überdimensioniertes CASE-Tool zu verwenden. Überprüfen Sie die PlantUml-Modelle auf die Quellcodeverwaltung und richten Sie einen CI-Job ein, um SVG oder PNGs automatisch zu erstellen und zu veröffentlichen.


Ich benutze UML für erste Entwürfe und als Hilfe für Diskussionen mit anderen Entwicklern. Aber abgesehen von der anfänglichen Planung ist die Zeit, die damit verbracht wurde, UML auf dem neuesten Stand zu halten, nicht die Mühe wert.


Ich benutze UML, um mir zu helfen, Probleme zu visualisieren und zu durchdenken. Zu diesem Zweck sind Sequenzdiagramme, Aktivitätsdiagramme und Objektdiagramme sehr nützlich.

Komponentendiagramme sind gut, wenn Sie versuchen, die Softwareschichten zu kommunizieren.

Bereitstellungsdiagramme sind sehr nützlich zum Ermitteln von Paketierung und Bereitstellung sowie von Kommunikationspfaden zwischen Knoten.

Klassendiagramme finde ich am wenigsten nützlich, da die meisten IDEs Ihnen die As-Built-Klassenhierarchie recht leicht geben können.


Ich benutze es für das Anwendungsfalldiagramm. sonst nicht viel.


Ich bevorzuge die agile Übernahme von UML (z. B. Whiteboard-Skizzen) über die Wasserfall- Anpassung von UML (z. B. exzessive Dokumente von in Visio gezeichneten aufwendigen Diagrammen).

UML ist immer noch nützlich, um ein Design für jemand anderen zu erklären. ZB ist das zusammengesetzte Entwurfsmuster leicht mit einfachen Klassendiagrammen zu erklären (das heißt, nachdem Sie mit diesen interessanten Analogien fertig sind).

Ein paar handgeschriebene Klassen- und Sequenzdiagramme sind praktisch, um einen schnellen Start zu ermöglichen, wenn Sie mit einem neuen oder alten Projekt konfrontiert werden, bei dem überall Klassen verstreut sind und die Dokumentation nicht gut genug ist.

Mein Team verwendet auch erfolgreich Klassendiagramme zum Generieren von Datenbankschemas. Vielleicht gibt es bessere Wege, aber das ist eine andere Frage.


Ich denke, dass traditionelle UML tot ist. Ich meine statische UML, die einige Monate der Anforderungsmodellierung und Codegenerierung von einem Modell aus verbringt. Wir können nicht länger als eine Woche warten, bevor wir anfangen zu programmieren, weil wir unser Projekt schneller und schneller liefern müssen. Wenn Sie ein Modell modellieren und einen Code generieren, ist der generierte Code normalerweise so schlecht, dass Sie ihn reparieren müssen. Ich habe vor einigen Jahren mehr Zeit damit verbracht, schmutzigen UML-generierten Code zu reparieren, als einen sauberen neuen Code zu schreiben.

Ich denke, dass MDD (zB modellgetriebene Entwicklung) tot ist, aber nicht UML grafische Notation. Ich benutze es immer noch jeden Tag und es funktioniert wirklich gut. Wenn ich neue Anforderungen bekomme, modelliere ich sie sofort in ein Klassendiagramm. Zuerst reverse ich mein bestehendes Projekt, dann erstelle ich neue Elemente und führe es mit existierendem Code zusammen. Es ist nicht mehr als 2 Stunden, um das Gerüst meiner Anforderung in mein bestehendes Projekt zu erstellen. Ich möchte mein Skelett mit einem Klassendiagramm erstellen, weil es ein höheres Abstraktions- und Code-Level bietet. Wirklich cool. Ich benutze Omondo EclipseUML und ich bin für dieses Tool gemacht, Entschuldigung für die anderen Anbieter, aber dieses Tool hat mein Leben verändert. Ich füge mein Projekt zweimal täglich mit Offshore-Teams zusammen und erstelle neue Diagramme. Dies ist nicht automatisch, da ich den Code vor der Annahme des Commits lieber überprüfe. Ich überprüfe die Zusammenstellung und auch den Objektansatz und nur UML kann mir einen Überblick darüber geben, was gemacht wurde, wie und wo der Klebstoff hinzugefügt wurde, um neue Anforderungen zu unterstützen. Ich bin glücklich, weil ich nicht mehr dreckige MDD-Codegenerierung verwende, sondern mich auf UML-Notation und Qualitätscode konzentrieren kann.


Ich habe entschieden, dass ich die Cockburn-Stil-Anwendungsfälle mag, die von Fowler in seinem Buch mit dem Titel "UML Distilled" beschrieben wurden. Ich mag sie genug, dass ich eine experimentelle Methode entwickelt habe, um sie direkt in C # -Namespaces einzubetten.

Auf diese Weise könnte ich Geschäftslogik oder UI-Logik in Bezug auf den englischsprachigen Inhalt der Use Cases kostenlos codieren, ohne eine domänenspezifische Sprache schreiben zu müssen. Der unmittelbarste Vorteil war, dass ich die Lesbarkeit des Codes verbesserte (Albiet auf eine sehr neue und esoterische Art). Es ist immer noch ein experimenteller Ansatz. Ich glaube jedoch, dass es nützlich sein könnte.

Here ist der Link zu einer Frage, die ich gepostet habe, während ich versucht habe, andere Wege zu finden, was ich getan habe.


Ich habe generierte UML gesehen, mit der neue Mitarbeiter ein sehr kompliziertes und komplexes System in den Griff bekommen. Da die UML automatisch aus dem Code generiert wurde, war sie immer auf dem neuesten Stand und einige Leute fanden es hilfreich.


Ich verwende UML auch für die ersten Entwürfe. Nach Durchführung der reqs-Phase und der Use Cases (sowohl in UML- als auch in Textform) ist das Basissystem als Komponentendiagramm ausgelegt, um einzelne Komponenten, die Schnittstellen sowie Subsysteme zu identifizieren.


Siehe SO: Ist UML praktisch? für einige weitere Antworten zu dem Thema. Es scheint, dass UML immer noch nützlich für die Kommunikation von Konzepten und Systemen ist. Die Leute scheinen es eher als Beschreibung als als Definition zu verwenden. Wenn Sie UML von der Implementierung selbst trennen, werden Sie Schwierigkeiten haben, die beiden synchron zu halten.



Wenn Sie Agile verwenden, sollten Sie UML verwenden.

Modellierung ist wichtig. Es macht natürlich mehr Spaß, Code zu schreiben, aber Sie verschwenden viel Zeit und haben keine Ahnung, ob Sie die Kundenanforderungen erfüllen. Sie modellieren, um das zu lösende Problem zu verstehen und die Entwicklungszeit zu verkürzen und Ihren Kunden ein nützliches Produkt zu liefern.

Sparen Sie Gold für die überteuerten Monster Kabel.


Wir verwenden UML-Klassendiagramme nur für einige Scratches, meist zu Beginn von Projekten, aber auch, wenn wir anderen Entwicklern unseren eigenen Code erklären. Aber das ist nur nervtötend, nicht um unsere Software zu dokumentieren.

Meiner Meinung nach wird viel über UML gesprochen (von Leuten, Zeitschriften), aber nicht ganz so viele Leute benutzen es wirklich.





uml