Als ich an der Universität war, wurde ich über die Vorteile von UML und seine Zukunft in der Codeentwicklung aufgeklärt.

Aufgrund meiner Branchenerfahrung habe ich jedoch festgestellt, dass wir zwar Diagramme verwenden - von ER-Diagrammen, Klassendiagrammen, Zustandsdiagrammen bis hin zu Arbeitsablaufdiagrammen -, diese jedoch ausschließlich zu Kommunikationszwecken.

Das heißt, ich habe nie automatisch Code aus Diagrammen generiert, und vom Standpunkt der Kommunikation aus versuche ich im Allgemeinen, meine Diagramme so einfach und verständlich wie möglich zu halten.

Aber wenn ich mir Visio und Enterprise Architect anschaue, scheinen sie viele verschiedene Arten von Diagrammen, Formen, Eigenschaftenobjekten zu haben, von denen ich die meisten nicht benutze.

Verwenden die Benutzer UML, um anspruchsvollere Aufgaben wie die Generierung von Code oder Datenbanken auszuführen?

Ja, UML CASE-Tools waren eines der angesagtesten Produkte der 90er Jahre ... und konnten dann nicht geliefert werden.

Der Hauptgrund dafür ist, dass UML-Diagramme (oder die meisten anderen Arten von Diagrammen) das Problem und / oder das Programm, das es löst, besser verstehen, sofern das Diagramm die Implementierungsdetails des eigentlichen Codes abstrahiert . Daher ist (für jeden nicht trivialen Code) ein Diagramm, das leicht zu verstehen ist, für die Codegenerierung inhärent nutzlos , da ihm die erforderlichen Details fehlen. Und umgekehrt hilft Ihnen ein Diagramm, das direkt für die Codegenerierung verwendet werden kann, nicht viel, das Programm besser zu verstehen als Code selbst. Wenn Sie jemals ein UML-Klassendiagramm gesehen haben, das aus Produktionscode entwickelt wurde, wissen Sie wahrscheinlich, was ich meine.

Die einzige mögliche Ausnahme, die ich kenne, sind Entity-Relationship-Diagramme, die keinen Code an sich enthalten, sondern nur (wie der Name schon sagt) Daten und deren Beziehungen. Ich habe jedoch noch nie von einem erfolgreichen Versuch gehört, UML-Diagramme für die echte Codegenerierung [Update] zu verwenden, dh mehr als nur Klassenskelette und trivialer Code wie Getter / Setter von Doc Brown unten [/ Update] , und ich denke, das ist kein Zufall.

Ich persönlich hasse UML nicht - ich denke, dass UML-Diagramme ein großartiges Kommunikationsmittel sein können -, um Ihre Absichten und Ideen während der Designdiskussionen zu zeigen oder die Architektur Ihrer App zu visualisieren. Aber es ist am besten, sie daran zu halten und nicht zu versuchen, sie für Dinge zu verwenden, in denen sie nicht gut sind.

Als ich (vor einiger Zeit) an der Uni war, wurde mir gesagt, dass UML die Zukunft ist. UML wird die Programmierung ersetzen und wir werden einfach Code aus Diagrammen usw. generieren.

Sie lagen falsch. Das wird ungefähr zu der Zeit passieren, wenn die Leute die Rede aufgeben und zur Höhlenmalerei zurückkehren.

Probleme der realen Welt und die Programme, die sie lösen, weisen eine wesentliche Komplexität auf, die nicht reduziert werden kann. Um ein Arbeitsprogramm zu erstellen, muss diese Komplexität erfasst und in einer ausführbaren Sprache ausgedrückt werden. Die Frage ist, ob eine grafische Programmiersprache effektiver sein könnte als eine textuelle Programmiersprache. Wir experimentieren seit ungefähr dreißig Jahren mit diagrammatischer Programmierung, und bisher sprechen die Beweise überwiegend für textuelle Programmierung. Mir ist keine wichtige Anwendung bekannt, die durch Codegenerierung aus Diagrammen erstellt wurde.

NEIN

Die Legende basierte auf der fehlgeschlagenen Annahme, dass das Schreiben:

class ClassName extends SomeThing
{

}

... es ist schwer und braucht Automatisierung .

Möglicherweise finden Sie immer noch gelegentliche Gläubige oder Scharen von Gläubigen.
Aber so geht es mit Religionen und Kulten.

War schon dort, fand es nicht allzu nützlich.

Im Allgemeinen tragen die Diagramme, die spezifisch genug sind, um Code daraus zu generieren, hauptsächlich Klassendiagramme, nicht viel zum Verständnis des Programms bei, und Sie können keinen Code aus den Übersichtsdiagrammen wie Anwendungsfällen oder Aktivitäten auf Übersichtsebene generieren entscheidend für die Dokumentation. Ein Diagramm, das zum Verständnis hilfreich ist und aus dem Code generiert werden kann, ist das Zustandsdiagramm, das sich als nützlich erweist, wenn Sie eine Zustandsmaschine wirklich benötigen. Aber im Allgemeinen sollten Sie versuchen, diese zu vermeiden, da sie von Natur aus fehleranfällig sind.

In einem Projekt mussten wir den Code im UML-Modellierer (Rhapsody) entwerfen und daraus generieren. Es hat irgendwie funktioniert und war wahrscheinlich etwas einfacher als das Eingeben der Überschriften (es war C ++) und der Prototypen von Hand. Die Fähigkeit, diese beiden automatisch konsistent zu halten, war etwas praktisch.

Die Methodenkörper mussten noch von Hand ausgefüllt werden, da die Diagramme das mit Ausnahme von State-Machine-Skeletten nicht wirklich abbilden können.

Auf der anderen Seite ist es ziemlich komplex, so dass Sie eine Menge zusätzlicher Dinge lernen müssen, und was noch wichtiger ist, es war mühsam, sich zu vereinen. Das Zusammenführen von Textdateien ist gut erforscht und funktioniert mit ihnen, aber noch niemand hat eine einfache Methode zum Zusammenführen von Änderungen an Diagrammen erfunden. Rhapsody speichert tatsächlich einen Teil der Informationen im generierten Code und parst sie zurück, sodass sie nicht völlig unbrauchbar waren, aber es war immer noch eine ernsthafte Komplikation.

Zwar ist es durchaus möglich, Code (und sogar ganze Systeme) direkt aus UML-Modellen zu generieren, aber ich bin noch nie darauf gestoßen, dass er auf diese Weise verwendet wird.

Nach meiner Erfahrung scheinen die meisten Unternehmen es als Kommunikationswerkzeug für Anforderungen oder als "MS Paint zum Zeichnen von Diagrammen" zu verwenden.

Eine wichtige Unterscheidung, die ich machen möchte, ist, dass Sie mit den meisten UML-Modellierungswerkzeugen ein einzelnes Modell Ihres Systems erstellen können. Visio hat beispielsweise ein ziemlich gutes Verständnis für die Funktionsweise von UML, und Sie können viele Dinge hinzufügen, die nicht direkt diagrammbezogen sind. Bei den tatsächlichen Diagrammen handelt es sich einfach um verschiedene Perspektiven auf Teile des Modells, mit denen Sie verschiedene Aspekte des Systems hervorheben können.

Alles (Modellierungsdiagramme) dient Kommunikationszwecken

Die Modellierung hat 4 wichtige Verwendungen im Softwareentwicklungsprozess:

1. Integriertes Designtool

2. Kommunikationswerkzeug

3. Eine Hilfe zur Software-Generierung

4. Ein Weg, um die Komplexität des Real-Word-Problems zu reduzieren (das habe ich aus der obigen Antwort von @kevin cline erfahren)

5. Der Modellierungsprozess bringt einige Designer dazu, über Details nachzudenken, die beim Codieren nicht berücksichtigt wurden (und umgekehrt). Die Modellierung zur Entwurfszeit ermöglicht es Ihnen, ein größeres Bild zu betrachten, als eine Methode oder eine Klasse in einer Sprache zu codieren.

Meiner Meinung nach ist das Modellieren von entscheidender Bedeutung, um Datenbanken zu erstellen (ER-Diagramme), Prozessabläufe zu verstehen (Aktivitätsdiagramme) und Interaktionen zwischen Benutzer und System zu verstehen (Anwendungsfalldiagramme).

Verwenden die Benutzer UML, um anspruchsvollere Aufgaben wie die Generierung von Code oder Datenbanken auszuführen?

Ja, in der Tat. ERDs (kein UML-Diagramm) und Klassendiagramme können verwendet werden (abhängig von den Funktionen Ihres Tools), um Folgendes zu generieren:

1 - Datendefinitionssprache (DDL)

2 - Gespeicherte Prozeduren für CRUD und Klassendiagramme in Ihrer bevorzugten Sprache (weniger nützlich, da ORM-Tools mehr dagegen tun)

Zu den wertvollsten Funktionen von Modellierungswerkzeugen gehören:

1 - Fähigkeit, die Integrität des Modells zu wahren. Wenn Sie eine Änderung vornehmen, wird diese im Modell weitergegeben

2 - Fähigkeit zur Beantwortung von Fragen, bei denen der Verwendungszweck angegeben wurde (wo wird das Konto in meinem Modell verwendet?)

3 - Möglichkeit, gleichzeitigen Benutzern das Arbeiten am Modell zu ermöglichen

4 - Suche in grafischen Darstellungen

5 - Drucksteuerung

6 - Ebenen (Organisieren Sie Ihre Diagrammelemente in Ebenen), sodass Sie sich auf eine Ebene gleichzeitig konzentrieren können

7 - Datenbankcodegenerierung für mehrere Datenbanksysteme

8 - Modellvalidierung (überprüft die Konsistenz, fehlende Schlüssel, Zyklen usw.)

Modellierungswerkzeuge, insbesondere die guten, können also viel mehr als nur malen.

Wir verwenden Software Architect, um übergeordnete Designs zu erstellen und einige der geheimnisvolleren Komponenteninteraktionen in unserem Material zu dokumentieren. Wir generieren manchmal das Grundgerüst der App aus den Diagrammen, aber wenn wir beide getrennt verwalten, versuchen wir nicht, den Code nach Fertigstellung wieder in ein Diagramm umzuwandeln. Früher habe ich ein Tool namens Rational XDE verwendet, das für kleine Programme recht gut funktioniert hat, aber es ging verloren, als Sie mit dem Hinzufügen von Swing-Ereignishandlern begonnen oder versucht haben, mit Struts zu arbeiten.

Ich denke, ein großer Teil des Grundes, warum Leute nicht in UML schreiben, ist, dass es viel mehr Arbeit kostet, alles in UML vollständig zu spezifizieren und dann den Code aus Ihrem Diagramm zu generieren. Ich weiß, dass das US-amerikanische Verteidigungsministerium mit der OMG zusammenarbeitet, um einige Tools zu entwickeln, mit denen "bewährter" Code aus Diagrammen generiert wird, die als korrekt eingestuft wurden. Mein Eindruck ist jedoch, dass Sie um eine Größenordnung mehr Metadaten als tatsächlichen Code erhalten. Das ist wahrscheinlich gut (schließlich ist es Dokumentation), aber das Generieren von Metadaten geht nicht schneller als das Schreiben von Code, sodass Sie proportional mehr Zeit aufwenden müssen.

UML selbst ist ein Notationssystem, so dass es für die Kommunikation und Dokumentation von Bedeutung ist. Es kommt selten vor, dass Code aus einem UML-Modell generiert wird, aber es gibt Leute, die das tun. Rhapsody-Benutzer tun dies häufiger als Rose. Der schwierige Teil ist, das Modell und den Code synchron zu halten. Für die meisten realen Projekte sind die Kosten einfach zu hoch.

In meinem neuesten Projekt benutze ich UML-Lab (https://www.uml-lab.com). Dies ist ein schönes Tool, mit dem das Modell auch rückentwickelt werden kann. Das Tool generiert Java-Code und sogar die JPA-Anmerkungen, die ziemlich genau sind.

Die Herausforderung besteht darin, in einem Team zu arbeiten. Das Modell ist statisch und befindet sich in einer einzelnen Ressource, was es ein wenig schwierig macht, es mit mehreren Entwickleränderungen synchron zu halten. Es gibt eine Testversion, die für 1 Monat verfügbar ist. Dies ist eine gute Zeit, um andere zu erkunden und mit ihnen zu vergleichen, wenn Sie Nachforschungen anstellen.

Dies ist das erste Mal, dass ich ein Produkt gesehen habe, das Objektmodellierung und Datenmodellierung in einer Aufnahme sowie Codegenerierung ausführt.

Ansonsten habe ich in meinen vergangenen Projekten immer veraltete Modelle gesehen, die ungenau oder zu detailliert waren.

In meinen früheren Projekten habe ich manchmal Diagramme durch Reverse Engineering generiert. Die meiste Zeit fand ich, dass die Diagramme überladen sind, und ich zog es vor, sie manuell zu zeichnen und das gesamte Rauschen zu filtern.

Ich denke, wir können UML verwenden, um Code zu generieren. Keine Geschäftslogik, da Geschäftslogik kein Standard ist und von Anwendung zu Anwendung unterschiedlich ist. Klassendiagramme können zusammen mit ER-Diagrammen zum Generieren von Schnittstellen, Klassen, Entitäten im Ruhezustand, grundlegenden Dao-Methoden usw. verwendet werden. Mit Hilfe von Objektdiagrammen können auch andere Codeelemente wie Fassadenimplementierung, Datentypkonverter (z. B. Entität zum Übertragen von Objekten) generiert werden .

Wie bereits in früheren Kommentaren erwähnt, können auch Datenbankschemata, DDL-Skripten usw. mithilfe von Modellen generiert werden.

Mit OAW und Modellierungswerkzeugen wie Enterprise Architect können wir stärkere Codegeneratoren schreiben, die sogar beim Generieren von Konfigurationsdateien, Factory-Code unter Verwendung von Stereotypen und getaggten Werten hilfreich sind.

Ich verstehe immer noch nicht, warum die Business Intelligence mit Tools wie Business Object alle Unternehmensinformationen analysieren und nutzen kann, während wir auf technologischer Ebene immer noch nur auf Code-Ebene oder auf abstrakter Ebene mit UML arbeiten !!

Das Problem ist nicht UML, sondern die Modelltransformation zwischen UML und MOF und die Codegenerierung aus einem Klassendiagramm oder XMI mithilfe von Vorlagen. UML soll eine abstrakte Sicht auf die reale Welt geben, daher sehen Sie nur, was wirklich wichtig ist. Allerdings, wie kann man genauen Code generieren, wenn das UML-Diagramm nur eine Ansicht der realen Welt ist? Es ist unmöglich und daher ist eine modellgetriebene Entwicklung, die Code aus einem Modell generieren würde, gescheitert.

Die Lösung besteht darin, die reale Welt und damit den gesamten Projektcode auf ein einziges UML-Modell abzubilden. Mit einem einzelnen Modell und der vollständigen Projektlogik können Sie dann jedes Mal Ansichten aus dem Modell und nicht aus dem Code generieren. Es gibt eine mutige Initiative von Omondo innerhalb der Java / Jee-Technologie. Das Konzept ist live synchronisiertes MOF und UML direkt mit dem Code und ORM. UML-Diagramme sind jetzt nur eine allgemeine Ansicht des Modells, das das gesamte Projekt abbildet. Sie können Hunderte von Ansichten erstellen, Hunderte von Notizen hinzufügen usw., um das Projekt besser zu verstehen. Der Code wird nur generiert, wenn das Element geändert oder erstellt wird. Wunderbare Technologie, bei der die Java-ID ohne die traditionelle Transformationsbrücke zwischen MOF und UML der UML-ID zugeordnet wird.

Fantastisch ist auch, dass ich meine Domain auf UML-Ebene modellieren und meine ORM-Annotationen direkt im Code abrufen kann. Mit Hibernate kann ich also eine Datenbank erstellen, löschen, erstellen, bereitstellen usw. ... in einer permanenten, kontinuierlichen Integration, in die UML ist Teil der gesamten Architektur und nicht die Architektur selbst des Projekts.

Ich war noch nie von UML als High-Level-Viewer enttäuscht, wenn es um die Live-Synchronisation mit dem Code ging, aber die traditionelle Verwendung von MDA mit modellgetriebenen Entwicklungsvorlagen zur Codegenerierung hat mich völlig am Boden zerstört. Die Codegenerierung aus einem Modell ist wie eine HTML-Seite, die aus einem Word-Dokument stammt. Wie kann ich es ändern, sobald es generiert wurde? Es ist einfach unmöglich zu aktualisieren und Sie verbringen mehr Zeit damit, den Code zu bereinigen, als von Grund auf neu zu schreiben!