Architecture Explorer in VS Ultimate

Manchmal entdeckt man erst nach Jahren ein Feature in den mächtigen Tools seines täglichen Lebens. Das ging mir letztens bei VS 2010 Ultimate so, als ich das Menu „Architecture“ für mich entdeckte.

VS 2012 Solution (*.7z)

Worum gehts?

Viele VS-Programmierer haben eine Professional- oder Premium-Lizenz (die schon teuer genug sind) und werden daher leider nicht selbst nachvollziehen können, was ich hier zeigen möchte. Ich denke aber, dass das noch ein Grund mehr ist, den Dingen auf den Grund zu gehen. Es wird immer ein riesen Geheimnis aus den coolen Features der teuren VS-Versionen gemacht und viele können sich gar nicht entscheiden, weil sie letztlich die Katze im Sack kaufen müssten.

Ich möchte hier eines dieser Features zeigen und vielleicht für einen Aha-Effekt sorgen.

Thematisch gesehen geht es um Analyse von Projektmappen im Visual Studio. Es geht um Dokumentation und Visualisierung.

Webcast

Für die Eiligen hier mal wieder der Webcast. Diesmal zeigt der Cast sogar ein paar mehr Dinge, als der Artikel, weil die einfach nicht gut darstellbar waren.

Das Beispiel-Projekt

Abb. 1: Solution-Explorer des Projektes

Abb. 1 zeigt die Solution aus der Sicht eines ganz normalen VS-Entwicklers. So sehen wir uns eine Solution jedes Mal an. Es besteht, um es simpel zu halten, aus 3 Projekten, die so was ähnliches, wie 2 Layer bilden sollen. Das „Console“-Projekt ist als Startprojekt hinterlegt und bildet somit das UI.

Das Problem

Interessant ist nun, was wir nicht auf Anhieb sehen. Ohne in den Code zu springen, oder die Referenzen aufzumachen, kann man eigentlich nicht genau sagen, was sich hinter den einzelnen Layern verbirgt und wie sie interagieren. Nun ist das Beispiel bewusst einfach gehalten. Bereits bei üblichen Projektgrößen (10+ Projekte je Solution) wird es immer schwieriger, genau zu sagen, was da eigentlich mit wem kommuniziert.

Noch blöder ist die Dokumentation dieses üblicherweise komplexen Geflechts von Abhängigkeiten. Welches Projekt referenziert welches? Welche Klasse erbt wie von anderen Projekten. Welche Methoden ruft eine Eigenschaft eigentlich auf?

Die Lösung

Genau bei solchen Problemen helfen nun die Architektur-Tools der Ultimate-Editionen weiter. Letztlich bieten sie dazu 2 Hilfsmittel, die direkt miteinander interagieren:

  • Architektur-Explorer
  • Dependency Graphs

Der Architecture Explorer (AE)

Ist man stolzer Besitzer einer Visual Studio 2010 Ultimate, sieht man in der Menuleiste einen Punk „Architecture“. In dessen Menu unter „Windows“ und dann „Architecture Explorer“ findet man das Tool, das wir hier betrachten wollen:

Abb. 2: Architektur-Explorer

Der AE in Abb. 2 zeigt die Darstellung direkt nach dem ersten Aufruf. Was wir hier sehen, ist sozusagen die Auswahl, die es uns erlaubt, festzulegen, wie wir in das Tool einsteigen wollen. Hat man, wie ich, eine Solution geladen, kann man die in der Gruppe „Visual Studio“ gezeigten Varianten wählen. Bei „Class View“ steigen wir auf Namespace-Ebene ein, bei „Solution View“ auf Projekt-Ebene.

Die Navigation ist für Windows-User etwas gewöhnungsbedürftig. Mac-User werden sich witzigerweise allerdings sofort an den Finder erinnert fühlen. Die Logik ist einfach: Klickt man in einer Ebene einen Eintrag an, öffnen sich rechts daneben in einer neuen Ebene (Spalte) die Details dieses Eintrages. Nach einigem Klicken durch unsere Solution bekommt man so einen ganz netten Überblick und weiß immer, wo man sich eigentliche befindet:

Abb. 3: AE im Drilldown

Es gibt ein paar Regeln zu beachten:

  1. Der AE kann nur anzeigen, was zuvor erfolgreich gebuildet wurde.
  2. Der AE geht runter bis auf Member-Ebene

Es spricht übrigens nichts dagegen, eine beliebige .NET-Assembly mit dem Tool zu betrachten. Dazu wählt man als Startpunkt einfach die Gruppe „File System“ und selektiert eine exe oder dll. Im Beispiel in Abb. 4 habe ich einfach mal die System.Net.dll ausgewählt.

Abb. 4: AE mit System.Net.dll vom Framework

„Das kann doch der Objektkatalog auch!“, könnte jetzt der ein oder andere meinen. „Ja, aber nicht so schick!“ könnte man antworten. Interessant sind nämlich die Filter-Optionen. Zunächst einmal kann man in jeder Spalte am oberen Rand einen Suchbegriff eingeben. Der sucht case-insensitiv per Volltext im jeweiligen Bereich. Klickt man auf das Filter-Symbol links neben dem Suchfeld kann man außerdem kontextsensitiv sinnvolle Ja/Nein-Filter dazu schalten:

Abb. 5: Filter-Optionen i.V.m. Suchbegriff

Die Optionen variieren je nach Kontext des Bereiches, in dem man sich jeweils befindet. Das war aber noch nicht alles.

Rechts neben einer Ebene erscheinen manchmal schmale vertikale Buttons mit Titeln wie „Contains“ oder „Members“. Klickt man z.B.  den Button „Types“ neben einer Namespace-Ebene an, erscheint folgende Zusatz-Navigation:

Abb. 6: Zusatz-Optionen eingeblendet

Hier kann man wie in einem Menu einfach einen Eintrag anklicken und so sehr bequem filtern.

Alles in allem ist das alles schon ziemlich fein. So richtig nützlich wird das Ganze aber erst durch das Menu ganz links am Rand des AE. Vor allem die beiden oberen Optionen haben es in sich, denn sie sind das Einfallstor zu den mächtigen Dependency Graphs.

Dependency Graphs (DG)

Ein DG stellt vereinfacht gesagt Abhängigkeiten zwischen Objekten dar. Ein Objekt könnte so ziemlich alles sein, in unserem Fall sind es zufälligerweise Namespaces, Klassen, Methoden usw. Um eine Abhängigkeit zu haben, braucht man i.d.R. mehr als ein Objekt. Daher kann man im AE mehrere Objekte (alle Namespaces, 3 Klassen, alle Methoden usw.) auswählen:

Abb. 7: Namespaces auswählen und „Create New Graph“ kllicken

Das Ergebnis ist folgendes:

Abb. 8: Der erste DG

Was wir in Abb. 8 sehen, ist die optische Aufbereitung eines DGML-Dokumentes (direct graph modelling language). VS Ultimate bringt halt einen hübschen Darsteller für Abhängigkeiten mit. Zu diesem Tool gibt es – nicht weiter überraschend – auch gleich eine eigene Toolbar:

Abb. 9: DG-Toolbar

Sie zeichnet sich vor allem durch vielfältige Möglichkeiten aus, die Darstellung des DG zu verändern. Jeden DG kann man übrigens im DGML-Format speichern. Bei Arbeit im Team empfiehlt es sich, dieses Dokument als Source-File zu betrachten und gleich mit einzuchecken.

DGs haben aber nicht nur die Möglichkeit, recht statische Inhalte zu zeigen. Im folgenden Beispiel sehen wir uns mal an, wie der Aufrufpfad zur Methode Base.Save aussieht. Dazu habe ich Save im AE angeklickt und dann Create gewählt:

Abb. 11: DG zu Base.Save

Sehr gut. Hält man die Maus nun etwas länger über dem Pfeil zwischen der Klasse „Base“ und ihrer Methode „Save“ erscheint ein Control. Klickt man hier genau auf die Mitte, gelangt man zu einem Detail-Generierungs-Screen:

Abb. 12: Auswahl von Details
Abb. 13: Optionen für Details festlegen
Abb. 14: DG-Details

Abb. 14 zeigt das Ergebnis dieser Operation. Man erhält eine optische Darstellung vom Namespace bis zur selektierten Methode. Mit diesem Wissen bewaffnet, selektiere ich einfach mal alle Member aller Klassen in allen Namespaces und generiere einen neuen DG:

Abb. 15: DG aller Elemente

Jetzt weiß man auch, warum ich das Projekt so klein gehalten habe. Generiere ich nun aber Details:

Abb. 16: DG-Detais etwas komplexer

Resumé

Sowas musste man eigentlich immer selbst per Hand machen. Schade zwar, dass sich dieses Tool nur für die teure Edition eignet. Könnte aber andererseits ein schöner Anlass sein, den Chef zu überzeugen, dass er das Geld für die Ultimate locker macht :-). Wertung: Nützlich.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.