Exemplarische Vorgehensweise: Aktualisieren eines Systems mithilfe von Visualisierungs- und Modellierungstools

  • Artikel

Um sicherzustellen, dass ein Softwaresystem die Anforderungen der Benutzer erfüllt, verwenden Sie die Architektur- und Modellierungstools in Visual Studio Ultimate, mit denen Sie das System aktualisieren können. Diese Tools umfassen UML-Diagramme (Unified Modeling Language), Ebenendiagramme, codebasierte Abhängigkeitsdiagramme, Sequenzdiagramme sowie Klassendiagramme ein. Mit diesen Tools können Sie beispielsweise die folgenden Aufgaben ausführen:

  • Ermitteln der Anforderungen und Geschäftsprozesse von Benutzern

  • Visualisieren und Untersuchen von vorhandenem Code

  • Beschreiben der Änderungen an einem vorhandenen System

  • Sicherstellen, dass das System die Anforderungen erfüllt

  • Sicherstellen, dass der Code konsistent mit dem Entwurf ist

In dieser exemplarischen Vorgehensweise sollen mit einem Beispielszenario die folgenden Ziele erreicht werden:

  • Bereitstellen einer allgemeinen Übersicht der Tools und ihrer Vorteile für ein Softwareprojekt

  • Verdeutlichen, wie zwei Teams diese Tools in einem Beispielszenario verwenden können, unabhängig von ihren Entwicklungsansätzen

Weitere Informationen zu diesen Tools und den Szenarien, die sie unterstützen, finden Sie unter:

In diesem Thema

Abschnitt

Beschreibung

Übersicht über das Szenario

Beschreibt das Beispielszenario und seine Teilnehmer.

Rollen von Architektur- und Modellierungsdiagrammen in der Softwareentwicklung

Beschreibt die Rollen, die diese Tools während des Lebenszyklus der Softwareentwicklung spielen können.

Verstehen und Kommunizieren von Informationen zum System

Stellt eine allgemeine Übersicht dazu bereit, wie die Teilnehmer die Tools in diesem Szenario verwenden.

Aktualisieren des Systems mithilfe von Visualisierung und Modellierung

Stellt nähere Details zu den einzelnen Tools bereit und erläutert, wie sie in diesem Szenario verwendet werden können.

Übersicht über das Szenario

Dieses Szenario beschreibt Episoden in den Lebenszyklen der Softwareentwicklung von zwei fiktiven Unternehmen: Dinner Now und Lucerne Publishing. Dinner Now bietet einen webbasierten Essenslieferdienst in Seattle an. Kunden können Essen bestellen auf der Dinner Now-Website bezahlen. Die Bestellungen werden dann an das entsprechende örtliche Restaurant für die Lieferung gesendet. Lucerne Publishing, ein Unternehmen in New York, unterhält mehrere Geschäfte sowohl im Internet als auch außerhalb des Internets. Beispielsweise wird eine Website betrieben, auf der Kunden Restaurantkritiken veröffentlichen können.

Lucerne hat vor kurzem Dinner Now übernommen und möchte die folgenden Änderungen vornehmen:

  • Integrieren der Websites durch Hinzufügen von Restaurantkritikfunktionen zu Dinner Now

  • Ersetzen des Zahlungssystems von Dinner Now durch das System von Lucerne

  • Ausweiten der Dienstleistung von Dinner Now auf das ganze Land

Dinner Now verwendet SCRUM- und eXtreme-Programmierung. Sie verfügen über eine sehr hohe Testabdeckung und nur wenig nicht unterstützten Code. Risiken werden minimiert, indem kleine, funktionierende Versionen eines Systems erstellt und dann schrittweise Funktionen hinzugefügt werden. Der Code wird über kurze und regelmäßige Iterationen entwickelt. Dadurch werden Änderungen auf sichere Weise eingeführt, der Code wird häufig umgestaltet, und ein "Big Design Up Front" wird vermieden.

Lucerne unterhält eine überaus umfangreichere und komplexe Auflistung von Systemen, die teilweise über 40 Jahre alt sind. Aufgrund von Komplexität und Umfang des älteren Codes werden Änderungen nur mit größter Vorsicht vorgenommen. Lucerne verfolgt einen rigoroseren Entwicklungsprozess und zieht es vor, detaillierte Lösungen zu entwerfen und den Entwurf und sowie während der Entwicklung auftretende Änderungen zu dokumentieren.

Beide Teams verwenden Modellierungsdiagramme in Visual Studio Ultimate, die sie dabei unterstützen, Systeme zu entwickeln, die die Anforderungen der Benutzer erfüllen. Sie verwenden Visual Studio Team Foundation Server zusammen mit anderen Tools zum Planen, Organisieren und Verwalten ihrer Arbeit.

Weitere Informationen über Visual Studio Team Foundation Server finden Sie hier:

  • Planen und Nachverfolgen der Arbeit

  • Testen, Überprüfen und Einchecken von aktualisiertem Code

Rollen von Architektur- und Modellierungsdiagrammen in der Softwareentwicklung

In der folgenden Tabelle werden Rollen beschrieben, die diese Tools während verschiedener Phasen des Lebenszyklus der Softwareentwicklung spielen können:

Modellieren von Benutzeranforderungen

Modellierung von Geschäftsprozessen

Systemarchitektur und -entwurf

Visualisieren und Untersuchen von Code

Überprüfung

Anwendungsfalldiagramm (UML)

√

√

√

Aktivitätsdiagramm (UML)

√

√

√

√

Klassendiagramm (UML)

√

√

√

√

Komponentendiagramm (UML)

√

√

√

√

Sequenzdiagramm (UML)

√

√

√

√

DSL-Diagramm (domänenspezifische Sprache)

√

√

√

Ebenendiagramm, Ebenenvalidierung

√

√

√

Klassen-Designer (codebasiert)

√

Sequenzdiagramm (codebasiert)

√

√

Abhängigkeitsdiagramm (codebasiert)

√

√

Architektur-Explorer

√

Um UML-Diagramme und Ebenendiagramme zu zeichnen, müssen Sie ein Modellierungsprojekt als Teil einer vorhandenen oder einer neuen Lösung erstellen. Diese Diagramme müssen im Modellierungsprojekt erstellt werden. Elemente in UML-Diagrammen sind Teil eines allgemeinen Modells, und die UML-Diagramme sind Ansichten dieses Modells. Elemente in Ebenendiagrammen befinden sich im Modellierungsprojekt, sie werden jedoch nicht im allgemeinen Modell gespeichert. Codebasierte Abhängigkeitsdiagramme, Sequenzdiagramme und Klassendiagramme sind normalerweise außerhalb des Modellierungsprojekts vorhanden.

Weitere Informationen finden Sie in folgenden Themen:

Um alternative Ansichten der Architektur anzuzeigen, können Sie bestimmte Elemente aus demselben Modell in verschiedenen Diagrammen wiederverwenden. Beispielsweise können Sie eine Komponente in ein anderes Komponentendiagramm oder in ein Sequenzdiagramm ziehen, damit es als Akteur fungieren kann. Weitere Informationen finden Sie unter Gewusst wie: Bearbeiten eines UML-Modells und Bearbeiten von Diagrammen.

Beide Teams verwenden außerdem Ebenenvalidierung, um sicherzustellen, dass Code in der Entwicklung mit dem Entwurf konsistent bleibt.

Weitere Informationen finden Sie in folgenden Themen:

Verstehen und Kommunizieren von Informationen zum System

Es gibt keine vorgeschriebene Reihenfolge zum Verwenden der Visual Studio Ultimate-Modellierungsdiagramme. Daher können Sie sie ganz ihren Anforderungen oder dem Ansatz entsprechend verwenden. Normalerweise rufen Teams ihre Modelle im Verlauf des Projekts wiederholt und häufig auf. Jedes Diagramm bietet bestimmte Vorteile, um verschiedene Aspekte des Systems in der Entwicklung zu verstehen, zu beschreiben und zu kommunizieren.

Dinner Now und Lucerne kommunizieren untereinander sowie mit Projektbeteiligten anhand von Diagrammen als einheitliche Sprache. Beispielsweise verwendet Dinner Now Diagramme, um folgende Aufgaben auszuführen:

  • Visualisieren von vorhandenem Code

  • Kommunizieren mit Lucerne über neue oder aktualisierte User Storys

  • Identifizieren von Änderungen, die für die Unterstützung neuer oder aktualisierter User Storys erforderlich sind

Lucerne verwendet Diagramme, um folgende Aufgaben auszuführen:

  • Aneignung von Kenntnissen über den Geschäftsprozess von Dinner Now

  • Verstehen des Systementwurfs

  • Kommunizieren mit Dinner Now über neue oder aktualisierte Benutzeranforderungen

  • Dokumentieren von Aktualisierungen am System

Die Diagramme werden in Team Foundation Server integriert, sodass die Teams ihre Arbeit leichter planen, verwalten und verfolgen können. Beispielsweise verwenden sie Modelle, um Testfälle und Entwicklungsaufgaben zu identifizieren und um ihre Arbeit einzuschätzen. Lucerne verknüpft Visual Studio Team Foundation Server-Arbeitsaufgaben mit Modellelementen, um den Fortschritt zu überwachen sowie sicherzustellen, dass das System die Anforderungen der Benutzer erfüllt. Beispielsweise werden Anwendungsfälle mit Testfallarbeitsaufgaben verknüpft, um sehen zu können, dass Anwendungsfälle erfüllt werden, wenn alle Tests erfolgreich verlaufen.

Bevor Teams ihre Änderungen einchecken, überprüfen sie den Code anhand der Tests und des Entwurfs durch das Ausführen von Builds, die Ebenenvalidierung und automatisierte Tests beinhalten. Dadurch wird sichergestellt, dass der aktualisierte Code dem Entwurf nicht widerspricht und Funktionen, die bereits funktionieren, nicht beeinträchtigt werden.

Weitere Informationen finden Sie in den folgenden Abschnitten:

  • Grundlegendes zur Rolle des Systems im Geschäftsprozess

  • Beschreiben neuer oder aktualisierter Benutzeranforderungen

  • Erstellen von Tests aus Modellen

  • Identifizieren von Änderungen am vorhandenen System

  • Sicherstellen der Konsistenz von Code und Entwurf

  • Allgemeine Tipps zum Erstellen und Verwenden von Modellen

  • Planen und Nachverfolgen der Arbeit

  • Testen, Überprüfen und Einchecken von aktualisiertem Code

Grundlegendes zur Rolle des Systems im Geschäftsprozess

Lucerne möchte mehr über den Geschäftsprozess von Dinner Now erfahren. Die folgenden Diagramme werden erstellt, um den Kenntnisstand mit Dinner Now leichter abzuklären:

Diagramm

Beschreibt

Anwendungsfalldiagramm (UML)

Weitere Informationen finden Sie in folgenden Themen:

  • Die vom Dinner Now-System unterstützten Aktivitäten

  • Die Personen und externen Systeme, von denen die Aktivitäten ausgeführt werden

  • Die Hauptkomponenten des Systems, die die jeweilige Aktivität unterstützen

  • Die Teile des Geschäftsprozesses, die sich außerhalb des Projektumfangs des aktuellen Systems befinden, z. B. Essenslieferung

Aktivitätsdiagramm (UML)

Weitere Informationen finden Sie in folgenden Themen:

Der Ablauf von Schritten, wenn ein Kunde eine Bestellung aufgibt

Klassendiagramm (UML)

Weitere Informationen finden Sie in folgenden Themen:

Die bei Besprechungen verwendeten Geschäftsentitäten und Begriffe sowie die Beziehungen zwischen ihnen Beispielsweise sind "Bestellung" und "Menüelement" Teil des Vokabulars in diesem Szenario.

Lucerne erstellt z. B. das folgende Anwendungsfalldiagramm, um zu verstehen, welche Aufgaben auf der Dinner Now-Website ausgeführt werden und von wem sie ausgeführt werden:

UML-Anwendungsfalldiagramm

UML-Anwendungsfalldiagramm

Das folgende Aktivitätsdiagramm beschreibt den Ablauf von Schritten, wenn ein Kunde auf der Dinner Now-Website eine Bestellung aufgibt. In dieser Version identifizieren Kommentarelemente die Rollen, und mit Linien werden Verantwortlichkeitsbereiche erstellt, die die Schritte nach Rolle organisieren:

UML-Aktivitätsdiagramm

UML Activity Diagram

Das folgende Klassendiagramm beschreibt die Entitäten, die am Bestellvorgang beteiligt sind:

UML-Klassendiagramm

UML-Klassendiagramm

Beschreiben neuer oder aktualisierter Benutzeranforderungen

Lucerne will dem Dinner Now-System Funktionen hinzufügen, damit Kunden Restaurantkritiken lesen und veröffentlichen können. Die folgenden Diagramme werden aktualisiert, um diese neue Anforderung mit Dinner Now zu besprechen:

Diagramm

Beschreibt

Anwendungsfalldiagramm (UML)

Weitere Informationen finden Sie in folgenden Themen:

Ein neuer Anwendungsfall für "Restaurantkritik verfassen"

Aktivitätsdiagramm (UML)

Weitere Informationen finden Sie in folgenden Themen:

Die Schritte, die auftreten, wenn ein Kunde eine Restaurantkritik schreiben möchte

Klassendiagramm (UML)

Weitere Informationen finden Sie in folgenden Themen:

Die Daten, die zum Speichern einer Kritik erforderlich sind

Beispielsweise enthält das folgende Anwendungsfalldiagramm den neuen Anwendungsfall "Kritik verfassen", um die neue Anforderung darzustellen. Zur leichteren Erkennung wird es im Diagramm orangefarben hervorgehoben:

UML-Anwendungsfalldiagramm

UML-Anwendungsfalldiagramm

Das folgende Aktivitätsdiagramm enthält neue Elemente in orange, um den Ablauf von Schritten im neuen Anwendungsfall zu beschreiben:

UML-Aktivitätsdiagramm

UML-Aktivitätsdiagramm

Das folgende Klassendiagramm enthält die neue Klasse Review (Kritik) sowie zugehörige Beziehungen zu anderen Klassen, sodass die Teams die Einzelheiten erläutern können. Beachten Sie, dass ein Kunde und ein Restaurant über mehrere Kritiken verfügen können:

UML-Klassendiagramm

UML-Klassendiagramm

Erstellen von Tests aus Modellen

Beide Teams stimmen darin überein, dass sie einen vollständigen Satz von Tests für das System und seine Komponenten benötigen, bevor sie Änderungen vornehmen können. Lucerne verfügt über ein spezialisiertes Team, das Tests auf System- und Komponentenebene durchführt. Die von Dinner Now erstellten Tests werden wiederverwendet und mithilfe von UML-Diagrammen strukturiert:

  • Jeder Anwendungsfall wird durch einen oder mehrere Tests dargestellt. Die Elemente im Anwendungsfalldiagramm sind mit Testfallarbeitsaufgaben in Visual Studio Team Foundation Server verknüpft.

  • Jeder Ablauf in einem Aktivitätsdiagramm oder einem Sequenzdiagramm auf Systemebene wird mindestens mit einem Test verknüpft. Das Testteam stellt systematisch sicher, dass jeder mögliche Pfad durch das Aktivitätsdiagramm getestet wird.

  • Die zum Beschreiben der Tests verwendeten Begriffe basieren auf den Begriffen, die durch Anwendungsfall-, Klassen- und Aktivitätsdiagramme definiert werden.

Mit der Änderung von Anforderungen und der entsprechenden Aktualisierung der Diagramme werden auch die Tests aktualisiert. Eine Anforderung wird nur als erfüllt betrachtet, wenn die Tests bestanden werden. Wenn es möglich oder praktikabel ist, werden die Tests auf Grundlage von UML-Diagrammen definiert, bevor mit der Implementierung begonnen wird.

Weitere Informationen finden Sie in folgenden Themen:

Identifizieren von Änderungen am vorhandenen System

Dinner Now muss die Kosten für die Erfüllung der neuen Anforderung schätzen. Diese hängen teilweise davon ab, wie sehr sich diese Änderung auf andere Teile des Systems auswirkt. Zur Verdeutlichung erstellt einer der Dinner Now-Entwickler die folgenden Diagramme und aus vorhandenem Code:

Diagramm

Zeigt Folgendes an

Abhängigkeitsdiagramm

Weitere Informationen finden Sie in folgenden Themen:

Die Abhängigkeiten und andere Beziehungen in vorhandenem Code

Dinner Now könnte z. B. damit beginnen, Assemblyabhängigkeitsdiagramme zu überprüfen, um eine Übersicht der Assemblys und ihrer Abhängigkeiten zu erhalten. Sie können in den Diagrammen einen Drilldown durchführen, um die Namespaces und Klassen in diesen Assemblys zu untersuchen.

Dinner Now kann auch Diagramme generieren, um bestimmte Bereiche und andere Arten von Beziehungen im Code zu untersuchen. Sie verwenden Architektur-Explorer, um relevante Bereiche und Beziehungen zu finden und auszuwählen.

Codebasiertes Sequenzdiagramm

Weitere Informationen finden Sie unter Gewusst wie: Untersuchen von Code mit Sequenzdiagrammen.

Die Sequenz der Interaktionen zwischen Instanzen

Sequenzdiagramme werden aus Methodendefinitionen generiert und sind hilfreich, um zu verstehen, wie Methodenverhalten vom Code implementiert wird.

Codebasiertes Klassendiagramm

Weitere Informationen finden Sie unter Gewusst wie: Hinzufügen von Klassendiagrammen zu Projekten (Klassen-Designer).

Vorhandene Klassen in Code

Beispielsweise generiert die Entwicklerin aus dem Code ein Abhängigkeitsdiagramm für Namespaces. Sie passt den Umfang an, um sich auf die Bereiche zu konzentrieren, die von dem neuen Szenario betroffen sind. Diese Bereiche werden ausgewählt und im Diagramm hervorgehoben:

Abhängigkeitsdiagramm für Namespaces

Abhängigkeitsdiagramm für Namespaces

Die Entwicklerin erweitert die ausgewählten Namespaces, um die zugehörigen Klassen, Methoden und Beziehungen anzuzeigen:

Erweitertes Abhängigkeitsdiagramm für Namespaces

Erweitertes Abhängigkeitsdiagramm für Namespaces mit sichtbaren gruppenübergreifenden Links

Die Entwicklerin untersucht den Code, um nach den betroffenen Klassen und Methoden zu suchen. Sie generiert Sequenzdiagramme und Klassendiagramme aus Code, um die Änderungen zu beschreiben und zu erläutern. Weitere Informationen finden Sie unter Visualisieren von vorhandenem Code.

Tipp

Generieren Sie Abhängigkeitsdiagramme und Sequenzdiagramme nach jeder Änderung erneut aus dem Code, um die Auswirkungen der vorgenommenen Änderungen zu sehen.

Um Änderungen an anderen Teilen des Systems zu beschreiben, wie z. B. Komponenten oder Interaktionen, kann das Team diese Elemente bei Bedarf auf Whiteboards zeichnen. Sie können auch die folgenden Diagramme in Visual Studio zeichnen, sodass die Details von beiden Teams erfasst, verwaltet und verstanden werden können:

Diagramme

Beschreibt

Aktivitätsdiagramm (UML)

Weitere Informationen finden Sie in folgenden Themen:

Der Ablauf von Schritten, wenn das System erkennt, dass ein Kunde erneut eine Bestellung bei einem Restaurant aufgibt, und der Kunden aufgefordert wird, eine Kritik zu schreiben

Klassendiagramm (UML)

Weitere Informationen finden Sie in folgenden Themen:

Logische Klassen und ihre Beziehungen Beispielsweise wird eine neue Klasse hinzugefügt, um eine Kritik und die Beziehungen mit anderen Entitäten zu beschreiben, wie z. B. Restaurant, Menü und Kunde.

Um Kritiken einem Kunden zuzuordnen, muss das System Kundendetails speichern. Ein UML-Klassendiagramm kann helfen, diese Details zu klären.

Codebasiertes Klassendiagramm

Weitere Informationen finden Sie unter Gewusst wie: Hinzufügen von Klassendiagrammen zu Projekten (Klassen-Designer).

Vorhandene Klassen in Code

Komponentendiagramm (UML)

Weitere Informationen finden Sie in folgenden Themen:

Die Teile des Systems auf höherer Ebene, wie z. B. die Dinner Now-Website und ihre Schnittstellen Diese Schnittstellen definieren, wie Komponenten untereinander durch die Methoden oder Dienste interagieren, die sie bereitstellen und nutzen.

Sequenzdiagramm (UML)

Weitere Informationen finden Sie in folgenden Themen:

Die Sequenz der Interaktionen zwischen Instanzen

Das folgende Komponentendiagramm zeigt z. B. die neue Komponente an, die Teil der Dinner Now-Websitekomponente ist. Die Komponente ReviewProcessing behandelt die Funktionalität zum Erstellen von Kritiken und wird orangefarben angezeigt:

UML-Komponentendiagramm

UML-Komponentendiagramm

Das folgende Sequenzdiagramm zeigt die Reihenfolge von Interaktionen an, die auftreten, wenn von der Dinner Now-Website überprüft wird, ob der Kunde schon einmal eine Bestellung bei einem Restaurant aufgegeben hat. Wenn dies zutrifft, wird der Kunde aufgefordert, eine Kritik zu erstellen, die an das Restaurant gesendet und auf der Website veröffentlicht wird:

UML-Sequenzdiagramm

UML-Sequenzdiagramm

Sicherstellen der Konsistenz von Code und Entwurf

Dinner Now muss sicherstellen, dass der aktualisierte Code konsistent mit dem Entwurf bleibt. Es werden Ebenendiagramme erstellt, die die Funktionsebenen im System beschreiben, die erlaubten Abhängigkeiten zwischen ihnen angeben und diesen Ebenen Lösungsartefakte zuordnen.

Diagramm

Beschreibt

Ebenendiagramm

Weitere Informationen finden Sie in folgenden Themen:

Die logische Architektur des Codes

Mit einem Ebenendiagramm werden die Artefakte in einer Visual Studio-Projektmappe organisiert und abstrakten Gruppen, genannt Ebenen, zugeordnet. Diese Ebenen identifizieren die Rollen, Aufgaben oder Funktionen, die diese Artefakte im System spielen.

Ebenendiagramme sind hilfreich, um den beabsichtigten Entwurf des Systems zu beschreiben und in der Entwicklung befindlichen Code anhand des Entwurfs zu validieren.

Um Ebenen zu erstellen, ziehen Sie Elemente aus dem Projektmappen-Explorer, Abhängigkeitsdiagrammen oder Architektur-Explorer. Verwenden Sie die Toolbox, oder klicken Sie mit der rechten Maustaste auf die Diagrammoberfläche, um neue Ebenen zu zeichnen.

Um vorhandene Abhängigkeiten anzuzeigen, klicken Sie mit der rechten Maustaste auf die Ebenendiagrammoberfläche, und klicken Sie dann auf Abhängigkeiten generieren. Um beabsichtigte Abhängigkeiten anzugeben, zeichnen Sie neue Abhängigkeiten.

Das folgende Ebenendiagramm beschreibt z. B. Abhängigkeiten zwischen Ebenen sowie die Anzahl der Artefakte, die jeder Ebene zugeordnet sind:

Ebenendiagramm für integriertes Zahlungssystem

Ebenendiagramm

Um sicherzustellen, dass während der Codeentwicklung keine Konflikte mit dem Entwurf auftreten, verwenden die Teams Ebenenvalidierung in Builds, die unter Team Foundation Build ausgeführt werden. Außerdem erstellen sie eine benutzerdefinierte MSBuild-Aufgabe, um Ebenenvalidierung bei den Eincheckvorgängen zu erfordern. Mithilfe von Buildberichten werden Validierungsfehler erfasst.

Weitere Informationen finden Sie in folgenden Themen:

Allgemeine Tipps zum Erstellen und Verwenden von Modellen

  • Die meisten Diagramme bestehen aus Knoten, die durch Linien verbunden sind. Für jeden Diagrammtyp stellt die Toolbox verschiedene Arten von Knoten und Linien bereit.

    Zum Öffnen der Toolbox klicken Sie im Menü Ansicht auf Toolbox.

  • Um einen Knoten zu erstellen, ziehen Sie ihn von der Toolbox in das Diagramm. Bestimmte Arten von Knoten müssen auf vorhandene Knoten gezogen werden. In einem Komponentendiagramm muss einer vorhandenen Komponente z. B. ein neuer Port hinzugefügt werden.

  • Um eine Linie oder Verbindung zu erstellen, klicken Sie in der Toolbox auf das entsprechende Tool, klicken Sie auf den Quellknoten und dann auf den Zielknoten. Einige Linien können nur zwischen bestimmten Arten von Knoten erstellt werden. Wenn Sie den Mauszeiger über mögliche Quellen oder Ziele bewegen, wird angezeigt, ob Sie eine Verbindung erstellen können.

  • Wenn Sie Elemente in UML-Diagrammen erstellen, werden diese auch einem allgemeinen Modell hinzugefügt. Die UML-Diagramme in einem Modellierungsprojekt sind Ansichten dieses Modells. Elemente in einem Ebenendiagramm sind Teil des Modellierungsprojekts, obwohl sie nicht im allgemeinen Modell gespeichert werden.

    Wenn Sie das Modell mit dem Modell-Explorer anzeigen möchten, klicken Sie auf Ansicht, zeigen auf Weitere Fenster, und klicken dann auf Modell-Explorer.

  • In einigen Fällen können Sie bestimmte Elemente aus dem Modell-Explorer in ein UML-Diagramm ziehen. Einige Elemente innerhalb des gleichen Modells können in verschiedenen Diagrammen verwendet werden, um alternative Ansichten der Architektur anzuzeigen. Sie können z. B. eine Komponente in ein anderes Komponentendiagramm oder ein Sequenzdiagramm ziehen, um sie als Akteur zu verwenden.

  • Visual Studio 2010 Ultimate unterstützt UML 2.1.2. In dieser exemplarischen Vorgehensweise werden nur die Hauptfunktionen der UML-Diagramme in dieser Version beschrieben. Es gibt jedoch viele Bücher, die UML und dessen Verwendung im Detail behandeln.

Weitere Informationen finden Sie unter Entwickeln von Modellen für den Softwareentwurf.

Planen und Nachverfolgen der Arbeit

Die Visual Studio Ultimate-Modellierungsdiagramme sind in Arbeitsaufgabenverfolgung in Team Foundation integriert, sodass die Arbeit leichter geplant, verwaltet und verfolgt werden kann. Beide Teams verwenden Modelle, um Testfälle und Entwicklungsaufgaben zu identifizieren und um ihre Arbeit einzuschätzen. Lucerne erstellt und verknüpft Visual Studio Team Foundation Server-Arbeitsaufgaben mit Modellelementen, wie z. B. Anwendungsfälle oder Komponenten. Auf diese Weise kann der Status überwacht werden, und die Arbeit kann bis zu den Benutzeranforderungen zurückverfolgt werden. Somit wird sichergestellt, dass die Änderungen stets den Anforderungen entsprechen.

Im Verlauf ihrer Arbeit aktualisieren die Teams die Arbeitsaufgaben, um die Zeit zu berücksichtigen, die sie mit ihren Aufgaben verbracht haben. Außerdem wird eine Überwachung und Berichterstellung des Status der Arbeit mithilfe der folgenden Visual Studio Team Foundation Server-Funktionen durchgeführt:

  • Tägliche Burndownberichte, die angeben, ob die geplante Arbeit in der erwarteten Zeit angeschlossen wird. Es werden andere ähnliche Berichte in Visual Studio Team Foundation Server erstellt, um den Status von Fehlern zu verfolgen.

  • Ein Iterationsarbeitsblatt, das Microsoft Excel verwendet, mit dem das Team die Arbeitsbelastung überwachen und zwischen den Mitgliedern ausgleichen kann. Dieses Arbeitsblatt ist mit Visual Studio Team Foundation Server verknüpft und bietet bei den regelmäßigen Statusbesprechungen eine Diskussionsbasis.

  • Ein Entwicklungsdashboard, das Office Project verwendet, um das Team mit wichtigen Projektinformationen auf dem neuesten Stand zu halten.

Weitere Informationen finden Sie in folgenden Themen:

Testen, Überprüfen und Einchecken von Code

Beim Ausführen der einzelnen Aufgaben wird der Code von den Teams in Team Foundation-Versionskontrolle eingecheckt. Wird dies vergessen, werden von Visual Studio Team Foundation Server entsprechende Erinnerungen angezeigt. Bevor Visual Studio Team Foundation Server das Einchecken akzeptiert, führen die Teams Komponententests und Ebenenvalidierung aus, um den Code anhand der Testfälle und des Entwurfs zu überprüfen. Mit Team Foundation werden regelmäßig Builds, automatisierte Komponententests und eine Ebenenvalidierung ausgeführt. Dadurch wird sichergestellt, dass der Code die folgenden Kriterien erfüllt:

  • Er funktioniert.

  • Bereits funktionierender Code wird dadurch nicht beeinträchtigt.

  • Er steht nicht in Konflikt mit dem Entwurf.

Dinner Now verfügt über eine große Auflistung automatisierter Tests, die Lucerne wiederverwenden kann, da fast alle weiterhin gültig sind. Lucerne kann außerdem auf diesen Tests aufbauen und neue hinzufügen, um neue Funktionen abzudecken. Darüber hinaus verwenden beide Visual Studio Ultimate, um manuelle Tests auszuführen.

Um sicherzustellen, dass der Code dem Entwurf entspricht, konfigurieren die Teams ihre Builds zum Einbinden der Ebenenvalidierung in Team Foundation Build. Wenn Konflikte auftreten, wird ein Bericht mit den Details generiert.

Weitere Informationen finden Sie in folgenden Themen:

Aktualisieren des Systems mithilfe von Visualisierung und Modellierung

Lucerne und Dinner Now müssen ihre Zahlungssysteme integrieren. Die folgenden Abschnitte zeigen die Modellierungsdiagramme in Visual Studio Ultimate, die beim Ausführen dieser Aufgabe helfen:

  • Verstehen der Benutzeranforderungen: Anwendungsfalldiagramme

  • Verstehen des Geschäftsprozesses: Aktivitätsdiagramme

  • Beschreiben der Systemstruktur: Komponentendiagramme

  • Beschreiben der Interaktionen: Sequenzdiagramme

  • Visualisieren von vorhandenem Code: Abhängigkeitsdiagramme

  • Definieren eines Glossars der Typen: Klassendiagramme

  • Beschreiben der logischen Architektur: Ebenendiagramme

Weitere Informationen finden Sie in folgenden Themen:

Verstehen der Benutzeranforderungen: Anwendungsfalldiagramme

Anwendungsfalldiagramme fassen zusammen, welche Aktivitäten ein System unterstützt und von wem diese ausgeführt werden. Lucerne verwendet ein Anwendungsfalldiagramm, um die folgenden Informationen über das Dinner Now-System zu erhalten:

  • Kunden geben Bestellungen auf.

  • Restaurants empfangen Bestellungen.

  • Das externe Zahlungsverarbeitungsgateway, das vom Dinner Now-Zahlungssystem zum Überprüfen von Zahlungen verwendet wird, liegt außerhalb des Projektumfangs der Website.

Das Diagramm zeigt auch, wie einige der Hauptanwendungsfälle in kleinere Anwendungsfälle unterteilt sind. Lucerne möchte sein eigenes Zahlungssystem verwenden. Der Anwendungsfall Process Payment (Zahlung verarbeiten) wird in einer anderen Farbe hervorgehoben, um auf erforderliche Änderungen hinzuweisen:

Hervorheben von "Process Payment" (Zahlung verarbeiten) im Anwendungsfalldiagramm

Hervorheben von "Process Payment" (Zahlung verarbeiten) im Anwendungsfalldiagramm

Wenn die Entwicklungszeit knapp wäre, könnte das Team erwägen, dass Kunden die Restaurants direkt bezahlen. Um dies zu verdeutlichen, würden sie den Anwendungsfall Process Payment (Zahlung verarbeiten) durch einen Anwendungsfall außerhalb der Dinner Now-Systemgrenze ersetzen. Anschließend würde der Kunde direkt mit dem Restaurant verknüpft, um anzugeben, dass Dinner Now nur die Bestellungen verarbeitet:

Neudefinition des Projektumfangs zum Bezahlen der Restaurants im Anwendungsfalldiagramm

Neudefinition des Projektumfangs zum Bezahlen der Restaurants im Anwendungsfalldiagramm

Weitere Informationen finden Sie in folgenden Themen:

Zeichnen eines Anwendungsfalldiagramms

Ein Anwendungsfalldiagramm umfasst die folgenden Hauptfunktionen:

  • Akteure stellen Rollen dar, die Personen, Organisationen, Maschinen oder Softwaresysteme spielen. Bespielsweise sind Kunde, Restaurant und das Dinner Now-Zahlungssystem Akteure.

  • Anwendungsfälle stellen Interaktionen zwischen Akteuren und dem System in der Entwicklung dar. Sie können eine beliebige Skala der Interaktion von einem einzelnen Mausklick oder einer Meldung bis hin zu einer mehrtägigen Transaktion darstellen.

  • Zuordnungen verknüpfen Akteure mit Anwendungsfällen.

  • Ein größerer Anwendungsfall kann kleinere einschließen, z. B. ist Select Restaurant (Restaurant auswählen) in Create Order (Bestellung aufgeben) enthalten. Sie können einen Anwendungsfall erweitern. Einem erweiterten Anwendungsfall werden Ziele und Schritte hinzugefügt, um anzugeben, dass der Anwendungsfall nur unter bestimmten Bedingungen auftritt. Anwendungsfälle können auch voneinander erben.

  • Ein Subsystem stellt das Softwaresystem dar, das sich in der Entwicklung befindet, oder eine seiner Komponenten. Dabei handelt es sich um ein großes Feld, das Anwendungsfälle enthält. Ein Anwendungsfalldiagramm klärt ab, was sich innerhalb oder außerhalb der Subsystemgrenze befindet. Um anzugeben, dass der Benutzer bestimmte Ziele auf andere Weise erreichen muss, zeichnen Sie diese Anwendungsfälle außerhalb der Subsystemgrenze.

  • Artefakte verknüpfen Elemente im Diagramm mit anderen Diagrammen oder Dokumenten.

Weitere Informationen finden Sie in folgenden Themen:

Zusammenfassung: Vorteile von Anwendungsfalldiagrammen

Mit Anwendungsfalldiagrammen können Sie Folgendes visualisieren:

  • Die Aktivitäten, die ein System unterstützt bzw. nicht unterstützt

  • Die Personen und externen Systeme, von denen diese Aktivitäten ausgeführt werden

  • Die Hauptkomponenten des Systems, die die einzelnen Aktivitäten unterstützen und die Sie als im übergeordneten System geschachtelte Subsysteme darstellen können

  • Wie ein Anwendungsfall in kleinere Anwendungsfälle oder Variationen unterteilt sein kann

Beziehung zu anderen Diagrammen

Diagramm

Beschreibt

Aktivitätsdiagramm

Der Ablauf von Schritten in einem Anwendungsfall und die Personen, die diese Schritte in diesem Anwendungsfall ausführen.

Die Namen von Anwendungsfällen spiegeln häufig die Schritte in einem Aktivitätsdiagramm wider. Aktivitätsdiagramme unterstützen Elemente wie z. B. Entscheidungen, Zusammenführungen, Eingaben und Ausgaben, gleichzeitige Abläufe usw.

Weitere Informationen finden Sie in folgenden Themen:

Sequenzdiagramm

Die Reihenfolge der Interaktionen zwischen den Teilnehmern in einem Anwendungsfall.

Weitere Informationen finden Sie in folgenden Themen:

Klassendiagramm (UML)

Die am Anwendungsfall beteiligten Entitäten oder Typen.

Weitere Informationen finden Sie in folgenden Themen:

Verstehen des Geschäftsprozesses: Aktivitätsdiagramme

Aktivitätsdiagramme beschreiben den Ablauf von Schritten in einem Geschäftsprozess und bieten eine einfache Möglichkeit, den Workflow zu kommunizieren. Ein Entwicklungsprojekt kann mehrere Aktivitätsdiagramme umfassen. Normalerweise umfasst eine Aktivität alle Aktionen, die sich aus einer externen Aktion ergeben, wie z. B. das Bestellen einer Mahlzeit, das Aktualisieren eines Menüs oder das Hinzufügen eines neuen Restaurants zum Geschäft. Eine Aktivität kann auch die Details einer komplexen Aktion beschreiben.

Lucerne aktualisiert das folgende Aktivitätsdiagramm, um zu zeigen, dass Lucerne die Zahlung verarbeitet und das Restaurant bezahlt. Das Dinner Now-Zahlungssystem wird durch das Lucerne-Zahlungssystem ersetzt, wie hervorgehoben wird:

Lucerne-Zahlungssystem in Aktivitätsdiagramm

Ersetzen des Dinner Now-Zahlungssystems im Aktivitätsdiagramm

Mit dem aktualisierten Diagramm können Lucerne und Dinner Now darstellen, an welcher Stelle das Zahlungssystem von Lucerne in den Geschäftsprozess passt. In dieser Version werden Kommentare zum Identifizieren der Rollen verwendet, die die Schritte ausführen. Mithilfe von Linien werden Verantwortlichkeitsbereiche erstellt, mit denen die Schritte nach Rolle organisiert werden.

Die Teams könnten auch einen alternativen Textabschnitt in Erwägung ziehen, bei dem der Kunde das Restaurant bezahlt, nachdem die Bestellung geliefert wurde. Dies würde zu anderen Anforderungen an das Softwaresystem führen.

Zuvor hat Dinner Now diese Diagramme auf ein Whiteboard oder in PowerPoint gezeichnet. Außerdem werden diese Diagramme mit Visual Studio Ultimate gezeichnet, sodass beide Teams die Details erfassen, verstehen und verwalten können.

Weitere Informationen finden Sie in folgenden Themen:

Zeichnen eines Aktivitätsdiagramms

Ein Aktivitätsdiagramm umfasst die folgenden Hauptfunktionen:

  • Einen Startknoten, der die erste Aktion der Aktivität angibt.

    Das Diagramm sollte immer einen dieser Knoten enthalten.

  • Aktionen, die Schritte beschreiben, bei denen der Benutzer oder die Software eine Aufgabe ausführt.

  • Kontrollflüsse, die den Ablauf zwischen Aktionen anzeigen.

  • Entscheidungsknoten, die bedingte Verzweigungen im Ablauf darstellen.

  • Gabelungsknoten, die einzelne Abläufe in gleichzeitige Abläufe teilen.

  • Aktivitätsendknoten, die Enden der Aktivität anzeigen.

    Obwohl diese Knoten optional sind, ist deren Aufnahme in das Diagramm nützlich, um zu verdeutlichen, wo die Aktivität endet.

Weitere Informationen finden Sie in folgenden Themen:

Zusammenfassung: Vorteile von Aktivitätsdiagrammen

Mit Aktivitätsdiagrammen können Sie den Steuerungsablauf und die Informationen zwischen den Aktionen eines Geschäfts, Systems oder Programms visuell darstellen und beschreiben. Dabei handelt es sich um eine einfache und hilfreiche Möglichkeit, anderen Personen den Workflow zu erläutern.

Beziehung zu anderen Diagrammen

Diagramm

Beschreibung

Anwendungsfalldiagramm

Fassen Sie die Aktivitäten zusammen, die jeder Akteur ausführt.

Weitere Informationen finden Sie in folgenden Themen:

Komponentendiagramm

Visualisieren Sie das System als Auflistung von wiederverwendbaren Komponenten, die durch einen genau definierten Satz von Schnittstellen Verhaltensweisen bereitstellen oder nutzen.

Weitere Informationen finden Sie in folgenden Themen:

Beschreiben der Systemstruktur: Komponentendiagramme

Komponentendiagramme beschreiben ein System als Auflistung trennbarer Komponenten, die durch einen genau definierten Satz von Schnittstellen Verhaltensweisen bereitstellen oder nutzen. Die Komponenten können einen beliebigen Umfang aufweisen und auf beliebige Art miteinander verbunden sein.

Damit Lucerne und Dinner Now die Komponenten und Schnittstellen des Systems leichter visualisieren und besprechen können, werden die folgenden Komponentendiagramme erstellt:

Externe Komponenten im Zahlungssystem

Komponenten des Zahlungssystems von Dinner Now

Dieses Diagramm zeigt verschiedene Komponententypen und ihre Abhängigkeiten. Sowohl die Dinner Now-Website als auch das Zahlungssystem von Lucerne erfordern z. B. das externe Zahlungsverarbeitungsgateway zum Überprüfen von Zahlungen. Die Pfeile zwischen Komponenten stellen die Abhängigkeiten dar, mit denen angegeben wird, welche Komponenten die Funktionen anderer Komponenten erfordern.

Um das Zahlungssystem von Lucerne zu verwenden, muss die Dinner Now-Website für die Verwendung der Schnittstellen PaymentApproval und PayableInsertion des Zahlungssystems von Lucerne aktualisiert werden.

Das folgende Diagramm zeigt eine spezielle Konfiguration der Komponenten für die Dinner Now-Website. Diese Konfiguration gibt an, dass jede Instanz der Website aus vier Teilen besteht:

  • CustomerProcessing

  • OrderProcessing

  • ReviewProcessing

  • PaymentProcessing

Diese Teile sind Instanzen der angegebenen Komponententypen und sind wie folgt verbunden:

Komponenten innerhalb der Dinner Now-Website

Komponenten innerhalb der Dinner Now-Website

Die Dinner Now-Website delegiert sein Verhalten an diese Teile, die die Funktionen der Website behandeln. Die Pfeile zwischen der übergeordneten Komponente und ihren Mitgliedskomponenten weisen auf Delegierungen hin, mit denen angegeben wird, welche Teile die Nachricht behandeln, die das übergeordnete Element über die Schnittstellen empfängt oder sendet.

In dieser Konfiguration werden die Kundenzahlungen von der PaymentProcessing-Komponente verarbeitet. Daher muss sie für die Integration mit dem Zahlungssystem von Lucerne aktualisiert werden. In anderen Szenarien können mehrere Instanzen eines Komponententyps in derselben übergeordneten Komponente vorhanden sein.

Weitere Informationen finden Sie in folgenden Themen:

Zeichnen eines Komponentendiagramms

Ein Komponentendiagramm umfasst die folgenden Hauptfunktionen:

  • Komponenten, die trennbare Stücke der Systemfunktionalität darstellen.

  • Bereitgestellte Schnittstellenports, die Gruppen von Nachrichten oder Aufrufen darstellen, die von Komponenten implementiert und von anderen Komponenten oder externen Systemen verwendet werden.

  • Erforderliche Schnittstellenports, die Gruppen von Nachrichten oder Aufrufen darstellen, die von Komponenten an andere Komponenten oder externe Systeme gesendet werden. Diese Art von Port beschreibt die Vorgänge, die eine Komponente von anderen Komponenten oder externen Systemen mindestens erwartet.

  • Teile sind Elemente von Komponenten und üblicherweise Instanzen anderer Komponenten. Ein Teil ist ein Stück des internen Entwurfs der übergeordneten Komponente.

  • Abhängigkeiten, die angeben, dass Komponenten die Funktionalität anderer Komponenten erfordern.

  • Delegierungen, die angeben, dass Teile einer Komponente Nachrichten behandeln, die von der übergeordneten Komponente gesendet oder empfangen werden.

Weitere Informationen finden Sie in folgenden Themen:

Zusammenfassung: Vorteile von Komponentendiagrammen

Mit Komponentendiagramme können Sie Folgendes visualisieren:

  • Das System als Auflistung trennbarer Teile, unabhängig von ihrer Implementierungssprache oder ihres Formats.

  • Komponenten mit genau definierten Schnittstellen, um den Entwurf leichter verstehen und aktualisieren zu können, wenn sich die Anforderungen ändern.

Beziehung zu anderen Diagrammen

Diagramm

Beschreibung

Abhängigkeitsdiagramm

Visualisieren Sie die Organisation und Beziehungen in vorhandenem Code.

Um Kandidaten für Komponenten zu identifizieren, erstellen Sie ein Abhängigkeitsdiagramm und gruppieren Elemente nach ihrer Funktion im System.

Weitere Informationen finden Sie in folgenden Themen:

Sequenzdiagramm

Visualisieren Sie die Sequenz der Interaktionen zwischen Komponenten oder den Teilen innerhalb einer Komponente.

Um aus einer Komponente eine Lebenslinie in einem Sequenzdiagramm zu erstellen, klicken Sie mit der rechten Maustaste auf die Komponente, und klicken Sie dann auf Lebenslinie erstellen.

Weitere Informationen finden Sie in folgenden Themen:

Klassendiagramm (UML)

Definieren Sie die Schnittstellen an den bereitgestellten oder angeforderten Ports sowie die Klassen, die die Funktionalität der Komponenten implementieren.

Weitere Informationen finden Sie in folgenden Themen:

Ebenendiagramm

Beschreiben Sie die logische Architektur des Systems in Bezug auf die Komponenten. Stellen Sie durch Ebenenvalidierung sicher, dass der Code konsistent mit dem Entwurf bleibt.

Weitere Informationen finden Sie in folgenden Themen:

Aktivitätsdiagramm

Visualisieren Sie die interne Verarbeitung, die Komponenten als Reaktion auf eingehende Nachrichten durchführen.

Weitere Informationen finden Sie in folgenden Themen:

Visualisieren von vorhandenem Code: Abhängigkeitsdiagramme

Abhängigkeitsdiagramme zeigen die aktuelle Organisation und die Beziehungen im Code. Elemente werden im Diagramm durch Knoten dargestellt, und Beziehungen werden durch Links dargestellt. Mit Abhängigkeitsdiagrammen können Sie die folgenden Arten von Aufgaben ausführen:

  • Untersuchen von unbekanntem Code

  • Verstehen, wo und wie sich eine vorgeschlagene Änderung auf vorhandenen Code auswirken könnte

  • Auffinden von Bereichen mit Komplexität, natürlichen Ebenen oder Mustern sowie anderen Bereichen, die von Verbesserungen profitieren könnten

Dinner Now muss z. B. die Kosten für die Aktualisierung der PaymentProcessing-Komponente schätzen. Diese hängen teilweise davon ab, wie sehr sich diese Änderung auf andere Teile des Systems auswirkt. Zur Verdeutlichung erstellt einer der Dinner Now-Entwickler Abhängigkeitsdiagramme aus dem Code und richtet den Fokus des Projektumfangs auf die Bereiche aus, die durch die Änderung betroffen sein könnten.

Das folgende Diagramm zeigt die Abhängigkeiten zwischen der PaymentProcessing-Klasse und anderen Teilen des Dinner Now-Systems, die markiert dargestellt werden:

Abhängigkeitsdiagramm für das Zahlungssystem von Dinner Now

Abhängigkeitsdiagramm für das Zahlungssystem von Dinner Now

Der Entwickler untersucht das Diagramm, indem er die PaymentProcessing-Klasse erweitert und die zugehörigen Member auswählt, um die potenziell betroffenen Bereiche anzuzeigen:

Methoden in der PaymentProcessing-Klasse und ihre Abhängigkeiten

Methoden in der PaymentProcessing-Klasse und ihre Abhängigkeiten

Für das Zahlungssystem von Lucerne wird das folgende Diagramm generiert, um die zugehörigen Klassen, Methoden und Abhängigkeiten zu untersuchen. Das Team erkennt, dass das Lucerne-System auch Arbeit erfordern könnte, damit es mit anderen Teilen von Dinner Now interagieren kann:

Abhängigkeitsdiagramm für das Zahlungssystem von Lucerne

Abhängigkeitsdiagramm für das Zahlungssystem von Lucerne

Beide Teams arbeiten zusammen, um die Änderungen zu ermitteln, die zum Integrieren der beiden Systeme erforderlich sind. Es wird entschieden, einen Teil des Codes umzugestalten, damit er einfacher zu aktualisieren ist. Die PaymentApprover-Klasse wird in den DinnerNow.Business-Namespace verschoben und erfordert einige neue Methoden. Die Dinner Now-Klassen, die Transaktionen behandeln, erhalten einen eigenen Namespace. Die Teams erstellen und verwenden Arbeitsaufgaben, um ihre Arbeit zu planen, zu organisieren und nachzuverfolgen. Wo sinnvoll, werden Arbeitsaufgaben mit Modellelementen verknüpft.

Nach der Neuorganisation des Codes generieren die Teams ein neues Abhängigkeitsdiagramm, um die aktualisierte Struktur und die Beziehungen anzuzeigen:

Abhängigkeitsdiagramm mit neu organisiertem Code

Abhängigkeitsdiagramm mit neu organisiertem Code

Dieses Diagramm zeigt, dass sich die PaymentApprover-Klasse nun im DinnerNow.Business-Namespace befindet und über ein paar neue Methoden verfügt. Die Dinner Now-Transaktionsklassen verfügen jetzt über einen eigenen PaymentSystem-Namespace, mit dem der Code später leichter behandelt werden kann.

Erstellen eines Abhängigkeitsdiagramms

  • Folgen Sie den folgenden Schritten zum Generieren eines Abhängigkeitsdiagramms, um eine schnelle Übersicht über Quellcode zu erhalten:

    Zeigen Sie im Menü Architektur auf Abhängigkeitsdiagramm generieren, und klicken Sie dann auf Nach Assembly, Nach Namespace oder Nach Klasse. Um eine Kombination dieser Elemente auszuwählen, klicken Sie auf Benutzerdefiniert.

    Erstellen Sie für eine schnelle Übersicht über kompilierten Code ein leeres Abhängigkeitsdiagramm, und ziehen Sie dann Assemblydateien oder ausführbare Dateien in die Diagrammoberfläche.

    Weitere Informationen finden Sie unter Gewusst wie: Generieren von Abhängigkeitsdiagrammen für .NET-Code.

  • Um bestimmte Code- oder Lösungselemente zu untersuchen, wählen Sie mit dem Architektur-Explorer die Elemente und Beziehungen aus, die Sie visualisieren möchten. Sie können dann entweder ein neues Diagramm generieren oder einem vorhandenen Diagramm ausgewählte Elemente hinzufügen.

    Weitere Informationen finden Sie unter Gewusst wie: Suchen von Code im Architektur-Explorer.

  • Um das Diagramm besser zu untersuchen, können Sie das Layout den auszuführenden Aufgaben entsprechend neu anordnen.

    Wählen Sie beispielsweise ein Strukturlayout aus, um die Ebenen im Code zu visualisieren. Weitere Informationen finden Sie unter Gewusst wie: Durchsuchen von und Navigieren in Diagrammdokumenten.

  • Um sich auf bestimmte Bereiche des Diagramms zu konzentrieren, können Sie seinen Umfang ändern, indem Sie Elemente herausfiltern oder deren Darstellung anpassen. Weitere Informationen finden Sie unter Gewusst wie: Bearbeiten und Anpassen von Diagrammdokumenten.

Zusammenfassung: Vorteile von Abhängigkeitsdiagrammen

Mit Abhängigkeitsdiagrammen können Sie Folgendes durchführen:

  • Verdeutlichen der Organisation und Beziehungen in vorhandenem Code

  • Identifizieren der Bereiche, die von einer vorgeschlagenen Änderung betroffen sein könnten

  • Auffinden von Bereichen mit Komplexität, Mustern oder Ebenen sowie andere Bereichen, die Sie optimieren könnten, um den Code leichter verwalten, ändern und wiederverwenden zu können

Beziehung zu anderen Diagrammen

Diagramm

Beschreibt

Ebenendiagramm

Die logische Architektur des Systems Stellen Sie durch Ebenenvalidierung sicher, dass der Code konsistent mit dem Entwurf bleibt.

Erstellen Sie ein Abhängigkeitsdiagramm, und gruppieren Sie verwandte Elemente, um vorhandene oder beabsichtigte Ebenen besser identifizieren zu können. Ziehen Sie Elemente aus dem Diagramm oder Architektur-Explorer, um ein Ebenendiagramm zu erstellen.

Weitere Informationen finden Sie in folgenden Themen:

Komponentendiagramm

Komponenten, ihre Schnittstellen und ihre Beziehungen

Um Komponenten zu identifizieren, erstellen Sie ein Abhängigkeitsdiagramm und gruppieren Elemente nach ihrer Funktion im System.

Weitere Informationen finden Sie in folgenden Themen:

Klassendiagramm (UML)

Klassen, ihre Attribute und Vorgänge und ihre Beziehungen

Um diese Elemente leichter zu identifizieren, können Sie ein Diagrammdokument mit den entsprechenden Elementen erstellen.

Weitere Informationen finden Sie in folgenden Themen:

Klassendiagramm (codebasiert)

Vorhandene Klassen in Code

Verwenden Sie den Klassen-Designer, um eine vorhandene Klasse in Code zu visualisieren und zu ändern.

Weitere Informationen finden Sie unter Gewusst wie: Hinzufügen von Klassendiagrammen zu Projekten (Klassen-Designer).

Beschreiben der Interaktionen: Sequenzdiagramme

Sequenzdiagramme beschreiben eine Reihe von Interaktionen zwischen Teilen eines Systems. Die Teile können beliebig skaliert sein. Sie können z. B. von einzelnen Objekten in einem Programm bis hin zu großen Subsystemen oder externen Akteuren reichen. Skala und Typ der Interaktionen können beliebig sein. Sie können z. B. von einzelnen Nachrichten bis hin zu erweiterten Transaktionen reichen, und es kann sich um Funktionsaufrufe oder Webdienstmeldungen handeln.

Um die Schritte im Anwendungsfall Process Payment (Zahlung verarbeiten) besser besprechen und erläutern zu können, erstellen Lucerne und Dinner Now das folgende Sequenzdiagramm aus dem Komponentendiagramm. Die Lebenslinien spiegeln die Dinner Now-Websitekomponente und seine Teile wider. Die Meldungen, die zwischen Lebenslinien auftreten, folgen den Verbindungen in den Komponentendiagrammen:

Sequenzdiagramm für den Anwendungsfall "Process Payment" (Zahlung verarbeiten)

Sequenzdiagramm für den Anwendungsfall "Process Payment" (Zahlung verarbeiten)

Das Sequenzdiagramm zeigt, dass die Dinner Now-Website ProcessOrder in einer Instanz von OrderProcessing aufruft, wenn der Kunde eine Bestellung aufgibt. Anschließend wird ProcessPayment in PaymentProcessing von OrderProcessing aufgerufen. Dies wird fortgeführt, bis die Zahlung vom externen Zahlungsverarbeitungsgateway überprüft wird. Erst dann wird die Kontrolle an die Dinner Now-Website zurückgegeben.

Lucerne muss die Kosten für die Integration ihres Zahlungssystem in das Dinner Now-System schätzen. Zur Verdeutlichung generiert einer der Entwickler Sequenzdiagramme aus dem Code, um die vorhandenen Interaktionen zu visualisieren.

Weitere Informationen finden Sie in folgenden Themen:

Zeichnen eines Sequenzdiagramms

Ein Sequenzdiagramm umfasst die folgenden Hauptfunktionen:

  • Vertikale Lebenslinien stellen Akteure oder Instanzen von Softwareobjekten dar.

    Klicken Sie auf die Lebenslinie, um ein Akteursymbol hinzuzufügen, mit dem angegeben wird, dass sich ein Teilnehmer außerhalb des Systems in der Entwicklung befindet. Legen Sie im Fenster Eigenschaftenfenster die Option Akteur auf Wahr fest. Wenn das Fenster Eigenschaften nicht angezeigt wird, drücken Sie F4.

  • Horizontale Meldungen stellen Methodenaufrufe, Webdienstmeldungen oder eine andere Kommunikationsarten dar. Vorkommnisausführungen sind vertikal schraffierte Rechtecke, die auf Lebenslinien angezeigt werden und die Zeiträume darstellen, in denen Objektprozessaufrufe empfangen werden.

  • Bei einer synchronen Meldung wartet das Absenderobjekt auf das <<Zurückgeben>> der Kontrolle wie bei einem regulären Funktionsaufruf. Bei einer asynchronen Meldung kann der Absender unmittelbar fortfahren.

  • Verwenden Sie Meldungen vom Typ <<Erstellen>>, um auf die Erstellung von Objekten durch andere Objekte hinzuweisen. Dies sollte die erste an das Objekt gesendete Meldung sein.

Weitere Informationen finden Sie in folgenden Themen:

Zusammenfassung: Vorteile von Sequenzdiagrammen

Mit Sequenzdiagrammen können Sie Folgendes visualisieren:

  • Der Kontrollfluss, der während der Ausführung eines Anwendungsfalls zwischen Akteuren oder Objekten übertragen wird.

  • Die Implementierung eines Methodenaufrufs oder einer Meldung

Beziehung zu anderen Diagrammen

Diagramm

Beschreibung

Klassendiagramm (UML)

Definieren Sie die Klassen, die Lebenslinien darstellen, sowie die Parameter und Rückgabewerte, die in zwischen Lebenslinien gesendeten Meldungen verwendet werden.

Um eine Klasse aus einer Lebenslinie zu erstellen, klicken Sie mit der rechten Maustaste auf die Lebenslinie, und klicken Sie dann auf Klasse erstellen oder Schnittstelle erstellen. Um eine Lebenslinie aus einem Typ in einem Klassendiagramm zu erstellen, klicken Sie mit der rechten Maustaste auf den Typ, und klicken Sie dann auf Lebenslinie erstellen erstellen.

Weitere Informationen finden Sie in folgenden Themen:

Komponentendiagramm

Beschreiben Sie die Komponenten, die Lebenslinien darstellen, sowie die Schnittstellen, die das von Meldungen dargestellte Verhalten bereitstellen und nutzen.

Um eine Lebenslinie aus einem Komponentendiagramm zu erstellen, klicken Sie mit der rechten Maustaste auf die Komponente, und klicken Sie dann auf Lebenslinie erstellen.

Weitere Informationen finden Sie in folgenden Themen:

Anwendungsfalldiagramm

Fassen Sie die Interaktionen zwischen Benutzern und Komponenten in einem Sequenzdiagramm als Anwendungsfall zusammen, der das Ziel eines Benutzers darstellt.

Weitere Informationen finden Sie in folgenden Themen:

Definieren eines Glossars der Typen: Klassendiagramme

Klassendiagramme definieren die am System beteiligten Entitäten, Begriffe oder Konzepte sowie ihre Beziehungen untereinander. Beispielsweise können Sie diese Diagramme während der Entwicklung verwenden, um die Attribute und Vorgänge für jede Klasse unabhängig von Implementierungssprache oder Format zu beschreiben.

Um die am Anwendungsfall Process Payment (Zahlung verarbeiten) beteiligten Entitäten zu erläutern und zu besprechen, zeichnet Lucerne das folgende Klassendiagramm:

Process Payment-Entitäten in einem Klassendiagramm

Process Payment-Entitäten in einem Klassendiagramm

Dieses Diagramm zeigt, dass ein Kunde über viele Bestellungen und verschiedene Methoden zum Bezahlen der Bestellungen verfügen kann. BankAccount und CreditCard erben beide von Payment.

Während der Entwicklung verwendet Lucerne das folgende Klassendiagramm, um die Details der einzelnen Klassen zu beschreiben und zu besprechen:

Process Payment-Entitätsdetails in einem Klassendiagramm

Process Payment-Details im Klassendiagramm

Weitere Informationen finden Sie in folgenden Themen:

Zeichnen eines Klassendiagramms

Ein Klassendiagramm umfasst die folgenden Hauptfunktionen:

  • Typen wie z. B. Klassen, Schnittstellen und Enumerationen:

    • Eine Klasse ist die Definition von Objekten, die gemeinsame strukturelle Merkmale oder Verhaltensmerkmale aufweisen.

    • Eine Schnittstelle definiert einen Teil des extern sichtbaren Verhaltens eines Objekts.

    • Eine Enumeration ist eine Klassifizierung, die eine Liste von literalen Werten enthält.

  • Attribute sind Werte eines bestimmten Typs, der die einzelnen Instanzen einer Klassifizierung beschreiben. Eine Klassifizierung ist ein allgemeiner Name für Typen, Komponenten, Anwendungsfälle und sogar Akteure.

  • Vorgänge sind Methoden oder Funktionen, die Instanzen einer Klassifizierung ausführen können.

  • Eine Zuordnung gibt eine Art von Beziehung zwischen zwei Klassifizierungen an.

    • Eine Aggregation ist eine Zuordnung, die einen gemeinsamen Besitz zwischen Klassifizierungen angibt.

    • Eine Komposition ist eine Zuordnung, die eine ganzteilige Beziehung zwischen Klassifizierungen angibt.

    Um Aggregationen oder Kompositionen anzuzeigen, legen Sie die Eigenschaft Aggregation für eine Zuordnung fest. Mit Freigegeben werden Aggregationen und mit Verbund werden Kompositionen angezeigt.

  • Eine Abhängigkeit gibt an, dass durch Änderungen an der Definition einer Klassifizierung möglicherweise auch die Definition einer anderen Klassifizierung geändert wird.

  • Eine Generalisierung gibt an, dass eine bestimmte Klassifizierung einen Teil ihrer Definition von einer allgemeinen Klassifizierung erbt. Eine Realisierung gibt an, dass eine Klasse die Vorgänge und Attribute implementiert, die von einer Schnittstelle bereitgestellt werden.

    Verwenden Sie das Tool Vererbung, um diese Beziehungen zu erstellen. Alternativ kann eine Realisierung als Lollipop dargestellt werden.

  • Pakete sind Gruppen von Klassifizierern, Zuordnungen, Lebenslinien, Komponenten und anderen Paketen. Importbeziehungen geben an, dass ein Paket alle Definitionen eines anderen Pakets enthält.

Als Ausgangspunkt für die Untersuchung und Besprechung bestehender Klassen können Sie mit dem Klassen-Designer Klassendiagramme aus Code erstellen.

Weitere Informationen finden Sie in folgenden Themen:

Zusammenfassung: Vorteile von Klassendiagrammen

Mit Klassendiagrammen können Sie Folgendes definieren:

  • Ein allgemeines Glossar von Begriffen, die zum Erläutern der Benutzeranforderungen und der am System beteiligten Entitäten verwendet werden. Weitere Informationen finden Sie unter Modellieren von Benutzeranforderungen.

  • Typen, die von Teilen des Systems verwendet werden, wie z. B. Komponenten, unabhängig von ihrer Implementierung. Weitere Informationen finden Sie unter Modellieren der Architektur eines Softwaresystems.

  • Beziehungen, wie z. B. Abhängigkeiten zwischen Typen. Sie können z. B. anzeigen, dass ein Typ mehreren Instanzen eines anderen Typs zugeordnet sein kann.

Beziehung zu anderen Diagrammen

Diagramm

Beschreibung

Anwendungsfalldiagramm

Definieren Sie die Typen, mit denen die Ziele und Schritte in Anwendungsfällen beschreiben werden.

Weitere Informationen finden Sie in folgenden Themen:

Aktivitätsdiagramm

Definieren Sie die Typen von Daten, die Objektknoten, Eingabepins, Ausgabepins und Aktivitätsparameterknoten durchlaufen.

Weitere Informationen finden Sie in folgenden Themen:

Komponentendiagramm

Beschreiben Sie Komponenten, ihre Schnittstellen und ihre Beziehungen. Eine Klasse kann auch eine vollständige Komponente beschreiben.

Weitere Informationen finden Sie in folgenden Themen:

Ebenendiagramm

Definieren Sie die logische Architektur des Systems in Bezug auf Klassen.

Stellen Sie durch Ebenenvalidierung sicher, dass der Code konsistent mit dem Entwurf bleibt.

Weitere Informationen finden Sie in folgenden Themen:

Sequenzdiagramm

Definieren Sie die Typen von Lebenslinien sowie die Vorgänge, Parameter und Rückgabewerte für alle Meldungen, die die Lebenslinie empfangen kann.

Um eine Lebenslinie aus einem Typ in einem Klassendiagramm zu erstellen, klicken Sie mit der rechten Maustaste auf den Typ, und klicken Sie dann auf Lebenslinie erstellen erstellen.

Weitere Informationen finden Sie in folgenden Themen:

Abhängigkeitsdiagramm

Visualisieren Sie die Organisation und Beziehungen in vorhandenem Code.

Um Klassen, ihre Beziehungen und ihre Methoden zu identifizieren, erstellen Sie ein Diagrammdokument, in dem diese Elemente angezeigt werden.

Weitere Informationen finden Sie in folgenden Themen:

Beschreiben der logischen Architektur: Ebenendiagramme

Ebenendiagramme beschreiben die logische Architektur eines Systems, indem die Artefakte in der Projektmappe in abstrakten Gruppen bzw. Ebenen organisiert werden. Artefakte können viele Dinge sein, z. B. Namespaces, Projekte, Klassen, Methoden usw. Ebenen stellen die Rollen oder Aufgaben dar, die die Artefakte im System ausführen. Sie können auch eine Ebenenvalidierung in die Build- und Eincheckvorgänge einschließen, um sicherzustellen, dass der Code konsistent mit dem Entwurf bleibt.

Um den Code mit dem Entwurf konsistent zu halten, überprüfen Dinner Now und Lucerne ihren Code während der Entwicklung mit dem folgenden Ebenendiagramm:

Ebenendiagramm für integriertes Zahlungssystem

Ebenendiagramm für Dinner Now nach der Integration mit Lucerne

Die Ebenen in diesem Diagramm sind mit den entsprechenden Lösungsartefakten von Dinner Now und Lucerne verknüpft. Die Business-Ebene ist z. B. mit dem DinnerNow.Business-Namespace und seinen Membern verknüpft, die nun die PaymentApprover-Klasse einschließen. Die Resource Access-Ebene ist mit dem DinnerNow.Data-Namespace verknüpft. Die Pfeile, bzw. Abhängigkeiten, geben an, dass die Funktionen in der Resource Access-Ebene nur von der Business-Ebene verwendet werden können. Beim Aktualisieren des Codes durch die Teams wird regelmäßig eine Ebenenvalidierung ausgeführt, um Konflikte bei ihrer Entstehung sofort erkennen und beheben zu können.

Die Teams arbeiten zusammen, um die beiden Systeme schrittweise zu integrieren und zu testen. Zuerst wird sichergestellt, dass PaymentApprover und der Rest von Dinner Now erfolgreich miteinander funktionieren, bevor PaymentProcessing behandelt wird.

Das folgende Abhängigkeitsdiagramm zeigt die neuen Aufrufe zwischen Dinner Now und PaymentApprover:

Aktualisiertes Abhängigkeitsdiagramm mit integriertem System

Abhängigkeitsdiagramm mit aktualisierten Methodenaufrufen

Nachdem bestätigt wurde, dass das System wie erwartet funktioniert, wird der PaymentProcessing-Code von Dinner Now auskommentiert. Die Ebenenvalidierungsberichte sind einwandfrei, und das resultierende Abhängigkeitsdiagramm zeigt, dass keine PaymentProcessing-Abhängigkeiten mehr vorhanden sind:

Abhängigkeitsdiagramm ohne PaymentProcessing

Abhängigkeitsdiagramm ohne PaymentProcessing

Weitere Informationen finden Sie in folgenden Themen:

Zeichnen eines Ebenendiagramms

Ein Ebenendiagramm umfasst die folgenden Hauptfunktionen:

  • Ebenen beschreiben logische Gruppen von Artefakten.

  • Ein Link ist eine Zuordnung zwischen einer Ebene und einem Artefakt.

    Um Ebenen aus Artefakten zu erstellen, ziehen Sie Elemente aus dem Projektmappen-Explorer, Abhängigkeitsdiagrammen oder Architektur-Explorer. Um neue Ebenen zu zeichnen und sie dann mit Artefakten zu verknüpfen, verwenden Sie die Toolbox, oder klicken Sie mit der rechten Maustaste auf die Diagrammoberfläche, um die Ebenen zu erstellen, und ziehen Sie dann Elemente in diese Ebenen.

    Die Zahl auf einer Ebene zeigt die Anzahl von Artefakten an, die mit der Ebene verknüpft sind. Diese Artefakte können Namespaces, Projekte, Klassen, Methoden usw. sein. Beachten Sie folgendes, wenn Sie die Anzahl der Artefakte in einer Ebene interpretieren:

    • Wenn eine Ebene mit einem Artefakt verknüpft ist, das andere Artefakte enthält, die Ebene jedoch nicht direkt mit den anderen Artefakten verknüpft ist, umfasst die Zahl nur das verknüpfte Artefakt. Die anderen Artefakte werden jedoch während der Ebenenvalidierung für die Analyse berücksichtigt.

      Ist z. B. eine Ebene mit einem einzelnen Namespace verknüpft, ist die Anzahl der verknüpften Artefakte 1, auch wenn der Namespace Klassen enthält. Wenn die Ebene auch mit den einzelnen Klassen im Namespace verknüpft ist, umfasst die Zahl die verknüpften Klassen.

    • Wenn eine Ebene andere Ebenen enthält, die mit Artefakten verknüpft sind, ist die Containerebene ebenfalls mit diesen Artefakten verknüpft, obwohl in der Zahl auf der Containerebene diese Artefakte nicht berücksichtigt sind.

    Klicken Sie mit der rechten Maustaste auf die Ebene, um die mit der Ebene verknüpften Artefakte anzuzeigen, und klicken Sie dann auf Links anzeigen, um den Ebenen-Explorer zu öffnen.

  • Eine Abhängigkeit gibt an, dass eine Ebene die Funktionen in einer anderen Ebene verwenden darf, jedoch nicht umgekehrt. Eine bidirektionale Abhängigkeit gibt an, dass eine Ebene die Funktionen in einer anderen Ebene verwenden darf und umgekehrt.

    Um vorhandene Abhängigkeiten in einem Ebenendiagramm anzuzeigen, klicken Sie mit der rechten Maustaste auf die Diagrammoberfläche, und klicken Sie dann auf Abhängigkeiten generieren. Um beabsichtigte Abhängigkeiten zu beschreiben, zeichnen Sie neue.

Weitere Informationen finden Sie in folgenden Themen:

Zusammenfassung: Vorteile von Ebenendiagrammen

Mit Ebenendiagrammen können Sie Folgendes ausführen:

  • Beschreiben der logischen Architektur eines Systems entsprechend den Funktionen der zugehörigen Artefakte

  • Sicherstellen, dass dieser Code in der Entwicklung dem vorgegebenen Entwurf entspricht

Beziehung zu anderen Diagrammen

Diagramm

Beschreibung

Abhängigkeitsdiagramm

Visualisieren Sie die Organisation und Beziehungen in vorhandenem Code.

Um Ebenen zu erstellen, generieren Sie ein Abhängigkeitsdiagramm, und gruppieren Sie dann die Elemente im Diagramm als potenzielle Ebenen. Ziehen Sie die Gruppen aus dem Diagramm in das Ebenendiagramm.

Weitere Informationen finden Sie in folgenden Themen:

Komponentendiagramm

Beschreiben Sie Komponenten, ihre Schnittstellen und ihre Beziehungen.

Um Ebenen zu visualisieren, erstellen Sie ein Komponentendiagramm, das die Funktionalität verschiedener Komponenten im System beschreibt.

Weitere Informationen finden Sie unter:

Externe Ressourcen

Kategorie

Links

Videos

Link zu Video

Link zu Video

Link zu Video

Foren

Blogs

Technische Artikel und Journale

The Architecture Journal – Ausgabe 23: Architekturmodellierung und -prozesse

Andere Sites

MSDN Architecture Center

Siehe auch

Konzepte

Visualisieren von vorhandenem Code

Entwickeln von Modellen für den Softwareentwurf

Verwenden von Modellen im Entwicklungsprozess

Überprüfen des Systems während der Entwicklung

Weitere Ressourcen

Verwenden von Modellen in der Agile-Entwicklung

Erweitern von UML-Modellen und Diagrammen