Wird Code häufig aus UML generiert? [geschlossen]

39

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?

RoboShop
quelle
6
@SK - Wir alle wissen, dass IHR Code großartig und so kristallklar geschrieben ist, dass selbst ein Fünfjähriger das gesamte Projekt erfassen kann, indem er nur einige Ihrer Methoden liest. Für den Rest von uns, der nicht über die übernatürliche Fähigkeit verfügt, kristallklaren Code zu schreiben, sind Diagramme von großem Vorteil, wenn es darum geht, die Funktionsweise des Systems kurz und bündig zu beschreiben, und UML-Diagramme sind eine Standardmethode zum Zeichnen dieser Diagramme. Ich behaupte nicht, dass sie der beste Weg sind, nur ein Standard, der größtenteils funktioniert.
Dunk
2
@Dunk, wahrscheinlich haben Sie diesen Moment verpasst, als der Rest von uns eine Rede anstelle eines Höhlengemäldes erfand . Diagramme sind fast immer nichts anderes als eine Möglichkeit, das zu verdecken, was sie darstellen sollen. Ein einfacher Text ist immer besser. Und je größer Ihr System, desto komplexer sein Verhalten, desto größer ist diese Lücke zwischen einem Kommunikationsstil der Höhlenmalerei und einem modernen Englisch. Ich habe noch nie ein Diagramm gesehen, das ich verstehen konnte, ohne es vorher manuell in einen Text zu übersetzen.
SK-logic
9
@ SK-logic - ich dachte ein Bild hat tausend Worte gemalt?
Michael Arnell
5
@ SK-logic: Es gibt also einige Dinge, die besser durch Text kommuniziert werden können. Und ob Sie es glauben oder nicht, andere werden besser über Diagramme kommuniziert, und dazu gehört auch das Systemdesign und nicht nur das OO-Design. Und es kann sogar für verschiedene Personen unterschiedlich sein und nein, Ihre Präferenz für Textinformationen ist kein von Gott gegebenes Zeichen der Überlegenheit.
Michael Borgwardt
3
@Sk - Ihre Meinung hat zwar einige gültige Punkte, da ein Diagramm fast nie ausreicht und Text hinzugefügt werden muss. Ich werde einfach weiterhin die Ihrer Meinung nach nutzlosen Diagramme verwenden, während ich weiterhin ziemlich große Systeme mit nahezu unmöglichen Terminen in großen Teams erfolgreich aufbaue, da ich noch keinen besseren Weg gefunden habe, mit anderen Entwicklern zu kommunizieren. Ich weiß, dass Sie viel Zeit haben, sich zu setzen und jeden Entwickler individuell zu leiten, aber ich bin zu beschäftigt damit, die Arbeit zu erledigen.
Dunk

Antworten:

64

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.

Péter Török
quelle
5
Genau. Aber dann stellt sich die Frage, warum UML mit all seinen sinnlosen strengen Regeln und seinen folglich aufgeblähten Werkzeugen zur Erstellung von UML überhaupt erst? Einfache Polygone und Ellipsen, die durch Linien und Pfeile verbunden sind, können genauso gut, wenn nicht sogar besser, Absichten vermitteln wie UML.
Dexter
1
+1 für den 90er-Jahre-Hype: Das Hardware-Design bewegte sich gleichzeitig sogar in die entgegengesetzte Richtung, weg von der schematischen Erfassung und hin zu HDLs.
jk.
2
Von 1996 bis 2002 arbeitete ich für eine Firma, in der wir erfolgreich UML-Diagramme als "bessere" ER-Modelle verwendeten. Wir hatten unsere eigenen Codegeneratoren, um C ++ - Code für unser ORM-Framework, SQL / DDL und die Dokumentation aus einem einzigen Modell zu generieren.
Doc Brown
2
Eine großartige Anwendung von UML-Diagrammen ist auch das Gerüst. Generieren Sie Klassen, mit Gettern / Setzern, vielleicht Ihrem Verzeichnisbaum usw.
Clement Herreman
5
@Dexter: Die Sache ist, dass "Einfache Polygone und Ellipsen, die durch Linien und Pfeile verbunden sind" viel für die Interpretation offen lassen. Es mag sein, dass UML zu sehr versucht, ein spezielles Symbol für alles zu haben, aber es ist sicherlich sinnvoll, eine standardisierte Notation zu haben, mit der Sie visuell zwischen Klassen und Hardwaresystemen sowie zwischen einer Vererbungsbeziehung und einem Kommunikationskanal unterscheiden können.
Michael Borgwardt
36

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.

Kevin Cline
quelle
2
+1, vielen Dank, dass Sie das Problem mit der Komplexität realer Wortprobleme angesprochen haben. Großartiger Punkt.
NoChance
Was ist mit G, der in LabVIEW verwendeten grafischen Programmiersprache?
Angelo.Hannes
1
@ Angelo.Hannes: Lösen von Problemen in der realen Welt in labview invariablen Ansätzen, die so aussehen: img.thedailywtf.com/images/201104/labview.jpg
Whatsisname
@whatsisname Dieses Diagramm ist sehr überladen. Aber ich habe in LabVIEW sehr gut strukturierte und sehr "lesbare" Diagramme gesehen, die Probleme der realen Welt lösen.
Angelo.Hannes
@ Angelo.Hannes: Ich habe LabVIEW-ähnliche Systeme verwendet. Sie eignen sich gut zum Erstellen kleiner Anwendungen in einer begrenzten Domäne.
Kevin Cline
9

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.

ZJR
quelle
4
Ich hatte wirklich das Bedürfnis nach einer Antwort mit einem großen NEIN irgendwo.
ZJR
6

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.

Jan Hudec
quelle
@mouviciel: Ich glaube nicht, dass es ein Tool gibt, das solche Probleme nicht hätte. Rhapsody versucht tatsächlich, die schlimmsten Probleme zu mindern, indem der generierte Code, der Text ist, als Autorität für Mitglieder verwendet wird.
Jan Hudec
3

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.

Daniel B
quelle
1

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.

Keine Chance
quelle
3
Ich möchte auf zwei Dinge hinweisen: 1. Sie mögen geordnete Listen.
Talnicolas
@talnicolas, du bist richtig! Ich tue :)
NoChance
0

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.

TMN
quelle
0

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.

Pinxue
quelle
-1

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.

Koya
quelle
-4

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.

Siddhesh Patil
quelle
-5

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!

UML_GURU
quelle
1
Das ist keine Antwort, nur eine Beschwerde. Ich stimme ein wenig zu, warum Codierer immer noch jeden einzelnen Zeilencode schreiben, während es EINFACH ist, kleine Code-Konstruktoren mit Drag & Drop zu erstellen. Sie haben vollkommen Recht, dass Bussiness die Technologie besser implementiert hat als die Benutzer, die sie verwenden. Sie können mit Ihrer App in Sekunden eine ganze vorkonfigurierte Maschine erstellen, aber Sie können keine Software mit wenigen (Tausenden) Klicks oder Tastenanschlägen erstellen. Extra. Ich habe festgestellt, dass Día und Pythonnect eine gute Arbeit leisten können, wenn sie Code direkt aus Ihrer UML ausführen, aber noch nicht getestet haben.
erm3nda