Modellieren mit Visual Studio 2012

Seit Visual Studio 2012 hat Microsoft mit der UML als Modellierungssprache seinen Frieden geschlossen. Davor wurden ausschließlich Konstrukte in einer (UML-ähnlichen) DSL unterstützt, da diese enger an die verwendete Technologie (hier: .NET) gebunden waren und deshalb einfacher für Codegenerierungszwecke verwendet werden konnten. Visual Studio 2012 Ultimate Edition stellt nun ein Modellierungsprojekttemplate zur Verfügung, das für die Erstellung von UML-Modellen geeignet ist. Über entsprechende Erweiterungen kann die Funktionalität von Visual Studio weiter angepasst werden.

UML-Modellierung

In UML-Modellierungsprojekten können die wichtigsten UML-Diagrammtypen verwendet werden (siehe Abbildung 1). Nicht unterstützt werden leider Zustandsdiagramme, die neben Klassen- und Aktivitätsdiagrammen wohl zu den am häufigsten genutzten UML-Diagrammtypen gehören. Allerdings bietet Visual Studio Layer-Diagramme an, die offiziell nicht Bestandteil der UML sind (dort wird diese Funktionalität über Komponentendiagramme abgedeckt). Der Funktionsumfang der Layer-Diagramme wurde von meinem Kollegen Alexander Jung hier eingehend betrachtet.

Diagramme unterstützen darüber hinaus alle gängigen UML-Konstrukte; Stereotypen können in sogenannten Profilen definiert und danach auf dafür vorgesehene UML-Konstrukte angewendet werden. Visual Studio sieht auch die Erstellung von PIMs (L2-/L3-Standardprofile) und PSMs (C#-Profil) vor. Sprachspezifische Konstrukte wie beispielsweise C#-Properties werden über entsprechende Stereotypen markiert und bei der Codegenerierung entsprechend berücksichtigt.

Abbildung 1: Diagrammtypen in VS 2012 UML-Modellierungsprojekten

Codegenerierung

Die Generierung von Quellcode wird in Visual Studio 2012 über ein entsprechendes T4-Template ermöglicht. Ein Template für die Erzeugung von C#-Quellcode wird standardmäßig mitgeliefert, kann aber benutzerdefiniert angepasst werden. Für jedes UML-Modell und jeden Elementtyp (Klasse, Enumeration, Interface, Struct) können separate Templates konfiguriert werden.

Abbildung 2: Konfiguration des pro UML-Konstrukt zu verwendenden T4-Templates

Reverse Engineering

Das Reverse-Engineering ist mit Visual Studio 2012 grundsätzlich möglich, wobei dies im Praxistest nur mit erheblichen Einschränkungen funktionierte. In der Theorie lassen sich über den sogenannten Architecture Explorer Elemente aus referenzierten Assemblies oder Projekten per Drag & Drop auf Diagramme ziehen. In der Folge werden die in der Assembly oder dem Projekt existierenden Artefakte importiert und im UML Model Explorer als Packages, Klassen oder Schnittstellen (Interfaces) dargestellt. Im Test funktionierte dies in wenigen Fällen reibungslos, beispielsweise gab Visual Studio unter anderem folgende Meldungen aus:

Error: Object reference not set to an instance of an object. Reverse engineer process was stopped.
Message: (6) type(s) fully reverse engineered.
Message: (13) type(s) partially reverse engineered. These types were not included in the original selection so their full definitions are not reverse engineered. Instead, this shallow operation has simply ensured these types exist in the UML model because they are needed in order to fully describe other elements.

Manche Typen, zum Beispiel solche, die sich in einer anderen Assembly befinden, werden nur teilweise eingelesen, obwohl die Ursprungs-Assembly diese explizit referenziert. Die manuelle Korrektur solcher Fehler gestaltete sich im Test mühsam, denn auch alle bestehenden Assoziationen müssen dann manuell nachgetragen werden. Darüber hinaus werden Template-Parameter (Parameter generischer Typen) unter dem Package “Unspecified Types" als separate Konstrukte importiert, was wenig sinnvoll erscheint (siehe Abbildung 3).

Abbildung 3: Template-Parameter werden als “Unspecified Types” eingelesen

Synchronisierung

Eine Synchronisierung zwischen Modell und Code im Rahmen des Roundtrip-Engineerings ist in Visual Studio 2012 nicht vorgesehen. In der MSDN-Doku heißt es hierzu:

The code and the diagram are not updated automatically. You can update the diagram to discuss change proposals without affecting your code. Subsequent changes in the code will not automatically affect the diagram unless you again drag the classes onto the diagram. [1]

Dies bedeutet, dass eine automatische Übernahme/Synchronisation von Codeänderungen im Modell nur durch erneutes, manuelles Reverse Engineering über Drag & Drop erfolgen kann. In Anbetracht der Schwierigkeiten, die mit dieser Funktion im Praxistest auftraten, ist dies eine unbefriedigende Aussage. Die Reflexion von Modelländerungen im Code ist ebenfalls problematisch. Bei der Konfiguration von Templates für die Quellcodegenerierung (siehe Abbildung 2 oben) kann lediglich angegeben werden, ob vorhandene Dateien im Zielverzeichnis überschrieben werden sollen oder nicht. Ein Abgleich mit vorhandenem Quellcode findet damit nicht statt.

MDA

Obwohl die Erstellung sowohl von PIMs als auch von PSMs mit Visual Studio 2012 grundsätzlich über die Auswahl von Modellprofilen möglich ist, kann ein PIM in der Entwicklungsumgebung nicht ohne weiteres in ein PSM umgewandelt werden. Entsprechende Transformationsfunktionen sind nicht vorgesehen. Dies ist im Kontext dieser Evaluation jedoch irrelevant, denn durch die Verwendung von Visual Studio hat man sich bereits explizit für die .NET-Plattform entschieden. Die Erstellung von PIMs ist deshalb höchstens für Dokumentationszwecke sinnvoll.

Anpassbarkeit

Durch die Verwendung von T4-Texttemplates lässt sich die Generierung von Textartefakten beliebig anpassen. Die entsprechenden Template-Dateien finden sich im Verzeichnis “C:Program Files (x86)Microsoft Visual Studio 11.0Common7IDEExtensionsMicrosoftArchitecture ToolsExtensibilityTemplatesText” und enthalten Markups der Form “<# … #>” mit Codefragmenten, die für die Abbildung von Logik und Prozeduraufrufen verwendet werden. Eine Anpassung des Reverse Engineerings von bereits existierendem Code ist nicht über Templates möglich.

Fazit

Visual Studio 2012 unterstützt grundsätzlich die Modellierung von Anwendungen mithilfe der UML. Allerdings schneidet die Entwicklungsumgebung bei der Evaluierung der DDD-/MDD-Kriterien schlecht ab. Schwächen zeigten sich insbesondere (1) beim Reverse Engineering existierender Codefragmente, das nicht immer fehlerfrei ablief und manuelle Eingriffe nötig machte und (2) der Synchronisation von Modell und Code. Existierende Einschränkungen bei der Unterstützung von MDA-Transformationen sind hier irrelevant, da die Verwendung von Visual Studio bereits die Festlegung auf die .NET-Plattform impliziert, daher wurden diese bei der abschließenden Bewertung nicht berücksichtigt.

Referenzen

[1] MSDN: How to: Create UML Class Diagrams from Code, Online Publikation, http://msdn.microsoft.com/en-us/library/vstudio/ff657806.aspx, Stand: 7. Februar 2013