it-swarm.dev

Wird Code üblicherweise aus UML generiert?

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

Aufgrund meiner Branchenerfahrung habe ich jedoch festgestellt, dass wir zwar Diagramme verwenden - von ER-Diagrammen über Klassendiagramme und Zustandsdiagramme bis hin zu Arbeitsablaufdiagrammen -, die jedoch ausschließlich Kommunikationszwecken dienen.

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 leicht verständlich wie möglich zu halten.

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

Verwenden Menschen UML, um anspruchsvollere Dinge wie Code oder Datenbankgenerierung zu erledigen?

39
RoboShop

Ja, UML CASE-Tools waren eines der heißesten Elemente der 90er Jahre ... und konnten dann nicht geliefert werden.

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

Die einzige mögliche Ausnahme, die mir bekannt ist, sind Entity-Relationship-Diagramme, die keinen Code an sich umfassen, sondern nur (wie der Name schon sagt) Daten und ihre Beziehungen. Ich habe jedoch noch nie von einem erfolgreichen Versuch gehört, UML-Diagramme für die Generierung von echtem Code zu verwenden [Update] - dh mehr als Klassenskelette und trivialer Code wie Getter/Setter - außer in Spezialwerkzeugen/Bereiche wie ORM, wie von Doc Brown unten bestätigt [/ Update], und ich denke, dies ist kein Zufall.

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

64
Péter Török

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

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

Probleme in 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 diagrammatische Programmiersprache effektiver sein könnte als eine textuelle Programmiersprache. Wir experimentieren seit ungefähr dreißig Jahren mit der Diagrammprogrammierung, und bis jetzt sprechen die Beweise überwiegend für die Textprogrammierung. Mir ist keine wichtige Anwendung bekannt, die durch Codegenerierung aus Diagrammen erstellt wurde.

36
kevin cline

NEIN

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

class ClassName extends SomeThing
{

}

... es ist schwer und muss automatisiert werden.

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

9
ZJR

Ich war dort und fand es nicht allzu nützlich.

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

Bei einem Projekt mussten wir den Code in UML Modeller (Rhapsody) entwerfen und von dort aus generieren. Es hat irgendwie funktioniert und war wahrscheinlich etwas einfacher als das manuelle Eingeben der Header (es war C++) und der Prototypen. Die Möglichkeit, diese beiden automatisch konsistent zu halten, war etwas praktisch.

Die Methodenkörper mussten noch von Hand ausgefüllt werden, da die Diagramme dies mit Ausnahme von Zustandsmaschinenskeletten nicht wirklich darstellen können.

Auf der anderen Seite ist es ziemlich komplex, so dass man eine Menge zusätzlicher Dinge lernen muss und vor allem war es schmerzhaft, sich zusammenzuschließen. Das Zusammenführen ist für Textdateien gut recherchiert und funktioniert mit ihnen, aber noch hat niemand eine einfache Möglichkeit erfunden, Änderungen an Diagrammen zusammenzuführen. Rhapsody behält tatsächlich einen Teil der Informationen im generierten Code bei und analysiert sie zurück, sodass sie nicht völlig unbrauchbar waren, aber dennoch eine schwerwiegende Komplikation darstellten.

6
Jan Hudec

Es ist sicherlich möglich, Code (und sogar ganze Systeme) direkt aus UML-Modellen zu generieren, aber ich habe noch nie festgestellt, dass er auf diese Weise verwendet wird.

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

Eine wichtige Unterscheidung, die ich treffen 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 mit Diagrammen zusammenhängen. Bei den tatsächlichen Diagrammen handelt es sich lediglich um unterschiedliche Perspektiven auf Teile des Modells, sodass Sie verschiedene Aspekte des Systems hervorheben können.

3
Daniel B

alles (Modellierungsdiagramme) dient Kommunikationszwecken

Die Modellierung hat 4 wichtige Verwendungszwecke im Softwareentwicklungsprozess:

  1. Integriertes Design-Tool

  2. Kommunikationswerkzeug

  3. Eine Hilfe zur Softwaregenerierung

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

  5. Der Modellierungsprozess bringt einige Designer dazu, über Details nachzudenken, die beim Codieren nicht berücksichtigt werden (und umgekehrt). Durch Modellieren zur Entwurfszeit können Sie ein größeres Bild betrachten als durch Codieren einer Methode oder einer Klasse in einer Sprache.

Die Modellierung ist meiner Meinung nach wichtig, um Datenbanken (ER-Diagramme) zu erstellen, Prozessabläufe (Aktivitätsdiagramme) zu verstehen und Benutzer-System-Interaktionen (Anwendungsfalldiagramme) zu verstehen.

Verwenden Menschen UML, um anspruchsvollere Dinge wie Code oder Datenbankgenerierung zu erledigen?

Ja in der Tat. ERDs (kein UML-Diagramm) und Klassendiagramme können (abhängig von den Funktionen Ihres Tools) verwendet werden, 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 aufrechtzuerhalten. Wenn Sie eine Änderung vornehmen, wird diese im Modell weitergegeben

2 - Fähigkeit, wo verwendete Fragen zu beantworten (wo wird das in meinem Modell verwendete "Konto" verwendet?)

3 - Möglichkeit, gleichzeitigen Benutzern die Arbeit 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 (prüft Konsistenz, fehlende Schlüssel, Zyklen usw.)

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

1
NoChance

Wir verwenden Software Architect, um Entwürfe auf hoher Ebene zu erstellen und einige der arkaneren Komponenteninteraktionen in unseren Materialien zu dokumentieren. Manchmal generieren wir das Skelett der App aus den Diagrammen, aber sobald dies erledigt ist, pflegen wir beide separat und versuchen nicht, den Code nach Abschluss wieder in ein Diagramm umzuwandeln. Früher habe ich ein Tool namens Rational XDE verwendet, das für kleine Programme ziemlich gut funktioniert hat, aber es ging verloren, wenn Sie anfingen, Swing-Ereignishandler hinzuzufügen oder mit Struts zu arbeiten.

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

0
TMN

UML selbst ist ein Notationssystem, so dass es Anlass zur Kommunikation und Dokumentation gibt. Es ist selten, Code aus dem UML-Modell zu generieren, aber ja, es gibt Leute, die das tun. Rhapsody-Benutzer tun dies häufiger als Rose. Der schwierige Teil besteht darin, das Modell und den Code synchron zu halten. Für die meisten realen Projekte sind die Kosten einfach zu hoch.

0
pinxue