VSTS im Einsatz: Team gewinnt

(…) Das besonders Wissenswerte
daran wiederum ist, dass Testläufe auch
automatisiert ausgeführt werden können.
Vorstellbar unmittelbar nach dem „Nightly
Build“, mit dem dann früh bei Arbeitsbeginn
Software-Entwicklern die identifizierten
Schwachstellen aufgezeigt werden
oder ihnen angezeigt wird, dass sie sich ab
sofort im „Programmierfehler-Gefängnis“
befinden.

Beim Monitoring/Reporting fließen
also die Ergebnisse aus Änderungs-, Konfigurations-,
Test-, Build-Management ein
und werden beispielsweise in einem Sternschema
verknüpft. Hier findet sich nur eine
der Automatisierungen der „recht langweiligen“
Prozesse wie Daten sammeln
und auswerten, deren Ergebnis aber zum
Beispiel für Wirtschaftsanalytiker bei der
Messung von Wertbeiträgen enorm wichtig
sind. Reports können dabei aufgrund
der Datenbestände des Data Warehouses
des Team Foundation Servers über Report
Designer oder Excel abgefragt werden.
Die Integration von Daten aufgrund eigener
Werkzeuge oder welcher von Drittherstellen
ist über Integrationsadapter auch
möglich.

We do the best – our partners do the rest.

Die Überschrift dieses Absatzes könnte bei
Microsoft durchaus bei dem einen oder
anderen Produkt Pate gestanden haben
und in Zukunft auch weiter stehen. Ein
Beispiel wiederum für ein solches Produkt
könnte Visio sein, bei dem Microsoft die
Unterstützung für UML auf den Stand von
UML 1.3 eingefroren hat; aber auch Visual
Studio, das von je her keine native Unterstützung
für UML bietet (mehr dazu unter
[7] und in Abbildung 2). Stattdessen gibt
es bei Visual Studio 2005 erstmals einen
Klassendesigner und bei der Team-System-
Variante zusätzlich mit den Distributed
System Design Tools
einen Application-,
Logical-Datacenter-, System- und Deployment-
Designer. Mit diesem Satz von Designern
legt Microsoft den Fokus auf die
werkzeugunterstützte Entwicklung von
verteilten, aber insbesondere auch serviceorientierten
Anwendungen: Architekten
können mittels des Application-Designers
Anwendungen definieren, die im System-
Designer als Instanz ein Software-System
bilden und von Software-Entwicklern letztendlich
entwickelt und von Architekten beziehungsweise
Rechenzentrumsmitarbeitern
mittels des Logical Datacenter Designers
bestimmten Typen von Systemen zugeordnet
und auf diese verteilt werden. Anschließend
liefern Generatoren XML-basierte
System-Definition-Model-Dateien
(SDM), die die Grundlage für die Installation
und Konfiguration dieser Anwendungen
sind.

Ein wesentliches Merkmal dieses Satzes
von Designern ist, dass mit visuellen
domänenspezifischen Sprachen
bei der
Beschreibung von Software-Systemen gearbeitet
wird [8]. Der Grund für die Entscheidung,
domänenspezifische Techniken
anstatt des etablierten Modellierungsstandards
UML zu verwenden, liegt sicherlich
unter anderem daran, dass UML
mit der Version 2.0 einen relativ hohen
Komplexitätsgrad erreicht hat. UML erfährt
dazu in der Praxis häufig durch individuelle
Anpassungen, beispielweise
über Stereotypes oder Tagged Values, eine
Fokussierung und durchaus auch eine
Komplexitätsreduzierung. Sie ist aber
gegenüber einer domänenspezifischen
Sprache in der Abbildung von allen Anforderungen
an ein Software-System im
Nachteil. Das ist auch verständlich, denn
UML wurde für die riesige Domäne der
objektorientierten Software-Entwicklung
entworfen. Nicht nur, aber auch, weil wir
visuell geprägte Wesen sind, hilft eine (visuelle)
domänenspezifische Sprache demgegenüber, komplexes Wissen auf wenige
Elemente zu reduzieren, wenn sie für eine
kleine und stark fokussierte Domäne spezifiziert
ist. Damit wird vermieden, wie im
Rahmen einer „Unique Modeling Language“,
soviel in eine Modellierungssprache
zu packen, bis der Aufwand für eine Anpassung,
für den Lernprozess und der Verwendung
höher ist, als der Aufwand für die
eigentliche Implementierung eines Software-
Systems. Auch wenn UML für die
Software-Entwicklung vielleicht teilweise
geeignet erscheint und sich in der Praxis
auch neidlos etabliert hat, sieht es bei der
Beschreibung der Software-Verteilung als
auch dem Betrieb von Software, eventuell
sogar mit dynamischen Anteilen, ganz anders
aus. Das sind Domänen, für die UML
nicht spezifiziert ist.

Ein Beispiel für Erweiterbarkeit
Doch halt, keine einseitige Kritik. Diese
Argumentationskette lässt sich nämlich
auch gegen die von Microsoft mit den
Distributed System Design Tools zur Verfügung
gestellten Designern anführen:
Die durchaus Microsoft-getriebenen domänenspezifische
Modelle zur Entwicklung
von verteilten Anwendungen heißen
nicht, dass hier auch wie bei UML nicht
nur die Obermenge der wie auch immer
ermittelten Bedürfnisse aller Anwender
von VSTS abgedeckt wird. Nun kommt
aber der Clou: Durch die DSL-Werkzeuge
[9] wird das Problem gelöst, dass Modellierungssprachen
von einem Hersteller
einer Modellierungs-Software kommen
müssen, sondern können stattdessen auch
selbst definiert werden. Die Definition
einer domänenspezifischen Sprache ist,
selbstverständlich in Abhängigkeit von
der Domäne, häufig keine leichte Sache
und benötigt zumeist auch mehrere Iterationen.
Dennoch ist aber schon rein logisch
der Aufwand für die Entwicklung
der domänenspezifischen Sprache geringer,
als auch noch die dafür notwendige
Modellierungs-Software zu entwickeln.
Anwender einer Domäne können sich bei
der Definition beziehungsweise Entwicklung
einer domänenspezifischen Sprache
ganz darauf konzentrieren und müssen
nicht die dafür technische Infrastruktur
kennen beziehungsweise entwickeln.
Werden die Bedürfnisse, beispielsweise für
monolithische Anwendungen mit vielen
Terminals, durch VSTS nicht abgedeckt,
können eigene Designer für eben solche
Anwendungstypen entwickelt werden. Erstaunlich
erscheint, dass mit dieser Erweiterbarkeit
von Visual Studio 2005 durch
die DSL-Tools, auch der UML-2.0-Standard
in Visual Studio 2005 Einzug halten
und individuell angepasst werden könnte.
Letztendlich überlässt Microsoft die Unterstützung
von UML in Visual Studio und
auch bei den Schnittstellen zu Visio bei
UML 2.0 Drittherstellern.

Zusammenfassend gilt also, dass der
Klassendesigner pro Sprache in Visual
Studio 2005, also beispielsweise für C#,
sehr geeignet zum Design von Klassen erscheint
– weil er eben genau zu den Leistungsmerkmalen
der Sprache C# passt
und beispielweise Sequenzdiagramme
nicht unterstützt, die aber auch beim Entwurf
einer Klasse
fehl am Platz sind. Visual
Studio ist aber so offen, dass auch jederzeit
Werkzeuge zur Unterstützung anderer
Modellierungssprachen wie die UML zum
Einsatz kommen können, die vielleicht
aufgrund langjähriger Erfahrung der Mitarbeiter
damit, der Domäne oder beteiligten
Partnern für besser geeignet erscheinen.
Zwei Beispiele dafür sind Together
von Borland [10] und Enterprise Architect
von Sparx Systems [11].

Mit einer solchen Erweiterbarkeit
beziehungsweise Fähigkeit zur Integration
braucht es keine allzu große Diskussion
geben: Ist eine „Fremdsprache“ wie
UML besser? Ist die Verwendung von domänenspezifischen
Sprachen und damit
der Vermeidung von „Fremdsprachen“
besser? Sind gar die mit der kommenden
Version 2 der DSL-Tools und dort durch
das Designer Integration Framework miteinander
verbindbaren domänenspezifischen
Sprachen eine Möglichkeit, Interessensbeteiligte
quasi über ein Wörterbuch
miteinander sprechen zu lassen?
Sind Werkzeuge von Drittherstellern für
Testläufe besser? Die Antworten darauf
liegen letztendlich nicht beim einzelnen
Software-Entwickler, sondern zumeist
in der Kompetenz der „mächtigen und
furchteinflößenden“ Instanzen der Rolle
des Architekten, die damit ihre Freiheitsgrade
erhöht bekommen, im Gegenzug für
die Absenkung der Freiheitsgrade anderer.
Das wiederum dient unter anderem einer
höheren Prozesskontrolle im Team, egal
ob die Prozesse eher agil, iterativ oder formal
angehaucht sind und damit der verbesserten
Planbarkeit, Steuerbarkeit und
nicht zuletzt auch der Produktivität von
Software-Entwicklungen. Damit dient die
Erweiterbarkeit von Visual Studio Team
System gerade den Aspekten Kommunikation,
Zusammenarbeit & Koordination,
Qualitätssicherung
und Projekttransparenz
– der Team-Orientierung.

An dieser Stelle ist auch ein anderes,
salomonisches, Schlusswort möglich:
Die Antworten auf diese Fragen hängen
vom Ökosystem zur Software-Entwicklung
in einem Unternehmen ab. Hat sich
bei einem UML bewährt oder gibt es die
Rolle des Architekten dort gar nicht, dessen
Instanz diese Entscheidung über die
UML versus einer DSL abnehmen könnte,
dann steht dem mit Visual Studio Team
System nichts mehr im Weg, es kann UML
und DSL integriert verwendet werden und
VSTS dient so ganz dem Ziel: „I even like
saying the word . team“ [12] – der Team-
Orientierung.

Torsten Weber ist gelernter Bankkaufmann,
verfügt über eine langjährige Berufserfahrung in
der Software-Entwicklung und ist zudem noch
Leiter der .NET User Group Leipzig. In beratender
Funktion stellt er immer wieder fest, das Begriffe
rund um VSTS relativ unbekannt und in Entwicklungsprojekten
trotz solcher mächtiger Werkzeuge
ob in kleinen oder großen Unternehmen so manches
noch immer auf Zuruf, anstatt in formalen
Prozessen abläuft. Sie erreichen ihn unter torsten
.weber@dotnet-leipzig.de.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.