design visual Verwenden Sie immer noch UML? Wie? Wozu?




visual paradigm (16)

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.

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?


Wir benutzen immer noch UML. Wie andere hier finde ich, dass sie sehr hilfreich in der Kommunikation sind. Es ist viel einfacher für Menschen zu kommunizieren, wenn sie visuelle Hilfsmittel haben (geben Sie die Popularität von PowerPoint ein). Dies gilt insbesondere in den Anfangsphasen eines Projekts, in dem Szenarien wie Firebird84 viel passieren. Die sorgfältige Seite von UML ist die Pflege der Diagramme, sobald die Entwickler am Projekt mit dem Codieren beginnen.

Wir generieren jedoch keinen Code von ihnen, und ich muss noch persönlich mit jemandem sprechen, der UML in diesem Ausmaß verwendet hat.


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.


Together / J ist ein guter Bezugspunkt, da es keine Anstrengung gibt, die UML zu erzeugen, sie ist nur neben Ihrem Java-Code vorhanden. Interessant zu sehen ob ich die UML benutzt habe als sie dort für "free" war.

Habe ich es nützlich gefunden, es dort zu haben? Um ehrlich zu sein, ich fand es nützlich als zusätzliche visuelle Beruhigung und Gegenprobe, dass das Design, das ich gemacht habe, Form annahm und als visuelles Katalogisierungswerkzeug. Ich habe nicht über bestimmte Logik oder Schemata nach den Diagrammen nachgedacht. Okay, vielleicht habe ich es manchmal getan.

War es das Geld wert? Ich fühlte mich in diesem Prozess wohl. Es sah für andere beeindruckend aus. Es rasierte sich ein paar Augenblicke und dachte über das Inventar der Dinge nach, die ich gemacht hatte. Es brachte mich dazu, mehr über Sauberkeit und Einfachheit im Allgemeinen nachzudenken, was mit jedem Objekt Platz auf dem Bildschirm einnimmt. Es hat mich gefragt, ob ich wirklich dieses Attribut brauche oder kann ich es besser machen? Es hat mir gelegentlich geholfen, "in UML zu denken".

Mit zusätzlicher Erfahrung, würde ich jetzt Together / J verwenden? Würde ich jetzt Zeit damit verbringen, UML von Grund auf neu zu erstellen?

Nun, wenn ich mir ansehe, was ich eigentlich für ein Projekt tue, dann besteht es darin, UI-Designs, Datenbankschemata und Kommunikationsprotokolle zu schreiben, Use Cases und Speicherbenutzung, Bandbreitennutzung und Sicherheit zu berücksichtigen. Tatsächlich ist fast alles möglich, außer Objektorientierung / UML. Und ich benutze nicht Together / J.

Warum ist das?

Das liegt daran, dass ich meine Erkenntnisse von UML verinnerlicht habe. Ich konzentriere mich jetzt darauf, Geschwindigkeits-, Raum- und Zeiteffizienzen in Designs zu erreichen. Meine Designs sind stark durch UML-Prinzipien eingeschränkt, so dass es sich gelohnt hat, all diese Dinge zu lernen, aber ich benutze keine echten Papier-UML-Diagramme oder denke nicht mehr an UML.

UML wird nur angenommen; ein gegebenes. Oder besser gesagt, sein Einfluss auf das Design ist.

Was ich jetzt auf dem Bildschirm habe, ist reiner Code und Daten. Ich habe auch ein Gefühl der Leistung. :-)


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 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 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 finde ULM nutzlos für mich, es schadet meiner Kreativität. Ich erzeuge UML nur als Dokumentation, wenn der Kunde es möchte. Aber ich benutze es nicht, um Klassen zu modellieren. Architektur ist ein sich entwickelnder Prozess, in dem ich immer wieder neu denke und überall neue Ideen bekomme, nicht nur im Büro. Ich reformiere mich ständig, um dem Optimum näher zu kommen, zunächst im Code. Ich hoffe du verstehst was ich meine.


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 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.


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.


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.


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.


Ich benutze UML in Diskussionen mit anderen Entwicklern. Ich denke oft an mich, dass es mir gelingt, Informationen über Bilder an andere Menschen weiterzuleiten, also zeichne ich ein Klassendiagramm oder ein Aktivitätsdiagramm auf einem Whiteboard, wenn ich mit dem Rest des Teams zusammenarbeite. Andere Mitglieder können es zeichnen und modifizieren, und sobald wir alle wissen, wovon wir reden, neigen wir dazu, einfach damit zu rollen. Wir haben uns nicht darum gekümmert, Code direkt daraus zu generieren (teilweise weil unsere Tools schrecklich waren), aber auf der anderen Seite haben wir uns möglicherweise eingeschränkt gefühlt, wenn wir es getan haben. Diese Designs haben seit dem Whiteboarding eine Menge verändert ....


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.





uml