Verwenden von Modellen in Ihrem Entwicklungsprozess

In Visual Studio können Sie ein Modell verwenden, um ein System, eine Anwendung oder eine Komponente zu verstehen und zu ändern. Ein Modell kann Ihnen helfen, die Welt zu visualisieren, in der Ihr System funktioniert, die Anforderungen der Benutzer zu klären, die Architektur Ihres Systems zu definieren, den Code zu analysieren und sicherzustellen, dass Ihr Code die Anforderungen erfüllt.

Informationen dazu, welche Versionen von Visual Studio jeden Modelltyp unterstützen, finden Sie unter Versionsunterstützung für Architektur- und Modellierungstools.

Modelle können Ihnen auf verschiedene Arten helfen:

Zeichnungsmodellierungsdiagramme helfen Ihnen dabei, die Konzepte zu klären, die in Anforderungen, Architektur und allgemeinem Design involviert sind. Weitere Informationen finden Sie unter Modellbenutzeranforderungen.
Die Arbeit mit Modellen kann Ihnen helfen, Inkonsistenzen in den Anforderungen aufzudecken.
Die Kommunikation mit Modellen hilft Ihnen, wichtige Konzepte weniger mehrdeutig zu kommunizieren als mit natürlicher Sprache. Weitere Informationen finden Sie unter Modellieren der Architektur Ihrer App.
Sie können manchmal Modelle verwenden, um Code oder andere Artefakte wie Datenbankschemas oder Dokumente zu generieren. Beispielsweise werden die Modellierungskomponenten von Visual Studio aus einem Modell generiert. Weitere Informationen finden Sie unter Generieren und Konfigurieren Ihrer App anhand von Modellen.

Sie können Modelle in einer Vielzahl von Prozessen verwenden, von extrem agiler bis hoher Zeremonie.

Verwenden von Modellen zur Reduzierung der Mehrdeutigkeit

Die Modellierungssprache ist weniger mehrdeutig als natürliche Sprache, und sie wurde entwickelt, um die in der Regel erforderlichen Ideen während der Softwareentwicklung auszudrücken.

Wenn Ihr Projekt über ein kleines Team verfügt, das agile Methoden verfolgt, können Sie Modelle verwenden, um Benutzergeschichten zu verdeutlichen. Im Gespräch mit dem Kunden über ihre Bedürfnisse kann das Erstellen eines Modells nützliche Fragen viel schneller generieren und über einen breiteren Bereich des Produkts hinweg, als Spitzen- oder Prototypcode zu schreiben.

Wenn Ihr Projekt groß ist und Teams in verschiedenen Teilen der Welt umfasst, können Sie Modelle verwenden, um die Anforderungen und die Architektur wesentlich effektiver zu kommunizieren, als es mit normalem Text möglich ist.

In beiden Fällen führt die Erstellung eines Modells fast immer zu einer erheblichen Verringerung der Inkonsistenzen und Mehrdeutigkeiten. Unterschiedliche Projektbeteiligte haben häufig unterschiedliche Kenntnisse der Geschäftswelt, in der das System funktioniert, und unterschiedliche Entwickler haben häufig unterschiedliche Kenntnisse darüber, wie das System funktioniert. Die Verwendung eines Modells als Schwerpunkt einer Diskussion macht diese Unterschiede in der Regel verfügbar. Weitere Informationen zur Verwendung eines Modells zur Reduzierung von Inkonsistenzen finden Sie unter Modellbenutzeranforderungen.

Verwenden von Modellen mit anderen Artefakten

Ein Modell ist nicht allein eine Anforderungsspezifikation oder eine Architektur. Es ist ein Werkzeug, um einige Aspekte dieser Dinge deutlicher auszudrücken, aber nicht alle Konzepte, die während des Softwaredesigns erforderlich sind, können ausgedrückt werden. Die Modelle sollten daher zusammen mit anderen Kommunikationsmitteln verwendet werden, z. B. OneNote-Seiten oder Absätze, Microsoft Office-Dokumente, Arbeitsaufgaben in Team Foundation oder Kurznotizen auf der Projektraumwand. Abgesehen vom letzten Element können alle diese Objekttypen mit Elementen des Modells verknüpft werden.

Weitere Aspekte der Spezifikation, die in Kombination mit Modellen verwendet werden, sind die folgenden: Je nach Skalierung und Stil Ihres Projekts können Sie mehrere dieser Aspekte verwenden oder überhaupt keines verwenden:

Benutzergeschichten. Eine Benutzergeschichte ist eine kurze Beschreibung, die mit Benutzern und anderen Projektbeteiligten diskutiert wird, eines Aspekts des Systemverhaltens, das in einer der Iterationen des Projekts bereitgestellt wird. Eine typische Benutzergeschichte beginnt mit "Der Kunde wird in der Lage sein,..." Eine Benutzergeschichte kann eine Gruppe von Anwendungsfällen einführen oder Erweiterungen von Anwendungsfällen definieren, die zuvor entwickelt wurden. Wenn Sie die Anwendungsfälle definieren oder erweitern, können Sie die Benutzergeschichte klarer gestalten.
Änderungsanforderungen. Eine Änderungsanforderung in einem formelleren Projekt ist einem Benutzerabschnitt in einem agilen Projekt sehr ähnlich. Der agile Ansatz behandelt alle Anforderungen als Änderungen an dem, was in früheren Iterationen entwickelt wurde.
Anwendungsfallbeschreibung. Ein Anwendungsfall stellt eine Möglichkeit dar, in der ein Benutzer mit dem System interagiert, um ein bestimmtes Ziel zu erreichen. Eine vollständige Beschreibung umfasst das Ziel, die Haupt- und alternative Abfolgen von Ereignissen und außergewöhnliche Ergebnisse. Ein Anwendungsfalldiagramm hilft beim Zusammenfassen und Bereitstellen einer Übersicht über die Anwendungsfälle.
Drehbücher. Ein Szenario ist eine ziemlich detaillierte Beschreibung einer Abfolge von Ereignissen, die zeigen, wie das System, die Benutzer und andere Systeme zusammenarbeiten, um den Projektbeteiligten Einen Mehrwert zu bieten. Es kann sich um eine Bildschirmpräsentation der Benutzeroberfläche oder einen Prototyp der Benutzeroberfläche handeln. Sie kann einen Anwendungsfall oder eine Abfolge von Anwendungsfällen beschreiben.
Glossar. Das Projektanforderungen-Glossar beschreibt die Wörter, mit denen Kunden ihre Welt diskutieren. Die Benutzeroberflächen- und Anforderungsmodelle sollten auch diese Begriffe verwenden. Ein Klassendiagramm kann dazu beitragen, die Beziehungen zwischen den meisten dieser Begriffe zu klären. Das Erstellen von Diagrammen und Glossaren reduziert nicht nur Missverständnisse zwischen Benutzern und Entwicklern, sondern macht fast immer Missverständnisse zwischen verschiedenen Geschäftsbeteiligten offen.
Geschäftsregeln. Viele Geschäftsregeln können als invariante Einschränkungen für die Zuordnungen und Attribute im Anforderungsklassenmodell und als Einschränkungen für Sequenzdiagramme ausgedrückt werden.
Entwurf auf hoher Ebene Beschreibt die hauptteile und wie sie zusammenpassen. Komponenten-, Sequenz- und Schnittstellendiagramme sind ein wichtiger Bestandteil eines allgemeinen Entwurfs.
Entwurfsmuster. Beschreiben Sie die Regeln des Entwurfs, die in den verschiedenen Teilen des Systems gemeinsam verwendet werden.
Testspezifikationen. Testskripts und die Designs für Testcode können Aktivitäts- und Sequenzdiagramme verwenden, um Sequenzen von Testschritten zu beschreiben. Systemtests sollten im Hinblick auf das Anforderungsmodell ausgedrückt werden, damit sie leicht geändert werden können, wenn sich die Anforderungen ändern.
Projektplan. Der Projektplan oder der Backlog definiert, wann jedes Feature bereitgestellt wird. Sie können jedes Feature definieren, indem Sie angeben, welche Anwendungsfälle und Geschäftsregeln es implementiert oder erweitert. Sie können entweder direkt im Plan auf Anwendungsfälle und Geschäftsregeln verweisen, oder Sie können eine Reihe von Features in einem separaten Dokument definieren und die Featuretitel im Plan verwenden.

Verwenden von Modellen in der Iterationsplanung

Obwohl alle Projekte in ihrem Maßstab und ihrer Organisation unterschiedlich sind, wird ein typisches Projekt als eine Reihe von Iterationen zwischen zwei und sechs Wochen geplant. Es ist wichtig, genügend Iterationen zu planen, damit Feedback aus frühen Iterationen verwendet werden kann, um den Umfang und die Pläne für spätere Iterationen anzupassen.

Möglicherweise finden Sie die folgenden Vorschläge hilfreich, um die Vorteile der Modellierung in einem iterativen Projekt zu realisieren.

Fokus schärfen, wenn sich jede Iteration nähert

Verwenden Sie bei den einzelnen Iterationsansätzen Modelle, um zu definieren, was am Ende der Iteration bereitgestellt werden soll.

Modelliert nicht alles im Detail in den frühen Iterationen. Erstellen Sie in der ersten Iteration ein Klassendiagramm für die Hauptelemente im Benutzer glossar, zeichnen Sie ein Diagramm der wichtigsten Anwendungsfälle, und zeichnen Sie ein Diagramm der Hauptkomponenten. Beschreiben Sie diese nicht detailliert, da sich das Detail später im Projekt ändert. Verwenden Sie die in diesem Modell definierten Begriffe, um eine Liste von Features oder Hauptnutzerstories zu erstellen. Weisen Sie die Features den Iterationen zu, damit die geschätzte Arbeitslast ungefähr über das gesamte Projekt ausgeglichen wird. Diese Zuweisungen werden später im Projekt geändert.
Versuchen Sie, vereinfachte Versionen aller wichtigsten Anwendungsfälle in einer frühen Iteration zu implementieren. Erweitern Sie diese Anwendungsfälle in späteren Iterationen. Dieser Ansatz trägt dazu bei, das Risiko zu verringern, einen Fehler in den Anforderungen oder die Architektur zu spät im Projekt zu erkennen, um etwas dagegen zu tun.
Halten Sie am Ende jeder Iteration einen Anforderungs-Workshop ab, um die Anforderungen oder Benutzergeschichten, die in der nächsten Iteration entwickelt werden, detailliert zu definieren. Laden Sie Benutzer und Geschäftsbeteiligte ein, die Prioritäten festlegen können, sowie Entwickler und Systemtester. Erlauben Sie drei Stunden, Anforderungen für eine 2-Wochen-Iteration zu definieren.
Ziel des Workshops ist es, sich darauf zu einigen, was am Ende der nächsten Iteration erreicht werden soll. Verwenden Sie Modelle als eines der Tools, um die Anforderungen zu verdeutlichen. Die Ausgabe des Workshops ist ein Iterationsbacklog, das heißt eine Liste der Entwicklungsaufgaben in Team Foundation und Testsuiten in Microsoft Test Manager.
Besprechen Sie in der Anforderungswerkstatt die Gestaltung nur, soweit Sie Schätzungen für die Entwicklungsaufgaben bestimmen müssen. Andernfalls halten Sie die Diskussion auf das Systemverhalten, das Benutzer direkt erleben können. Trennen Sie das Anforderungsmodell vom Architekturmodell.
Nicht technische Projektbeteiligte haben in der Regel keine Probleme mit dem Verständnis von UML-Diagrammen, mit einigen Anleitungen von Ihnen.

Verknüpfen des Modells mit Arbeitsaufgaben

Nach dem Anforderungsworkshop erarbeiten Sie die Details des Anforderungsmodells und verknüpfen das Modell mit Entwicklungsaufgaben. Dazu können Sie Arbeitsaufgaben in Team Foundation mit Elementen im Modell verknüpfen.

Sie können jedes Element mit Arbeitsaufgaben verknüpfen, aber die nützlichsten Elemente sind wie folgt:

Kommentare, die Geschäftsregeln oder Dienstqualitätsanforderungen beschreiben. Weitere Informationen finden Sie unter Modellbenutzeranforderungen.

Verknüpfen des Modells mit Tests

Verwenden Sie das Anforderungsmodell, um die Gestaltung der Akzeptanztests zu leiten. Erstellen Sie diese Tests gleichzeitig mit der Entwicklungsarbeit.

Weitere Informationen zu dieser Technik finden Sie unter Entwickeln von Tests aus einem Modell.

Schätzen der verbleibenden Arbeit

Ein Anforderungsmodell kann dabei helfen, die Gesamtgröße des Projekts im Verhältnis zur Größe der einzelnen Iterationen zu schätzen. Die Bewertung der Anzahl und Komplexität der Anwendungsfälle und Klassen kann Ihnen helfen, die erforderliche Entwicklungsarbeit zu schätzen. Wenn Sie die ersten Iterationen abgeschlossen haben, kann ein Vergleich der abgedeckten Anforderungen und der noch abzudeckenden Anforderungen eine ungefähre Messung der Kosten und des Umfangs des restlichen Projekts liefern.

Überprüfen Sie am Ende jeder Iteration die Zuordnung der Anforderungen zu zukünftigen Iterationen. Es kann nützlich sein, den Status Ihrer Software am Ende jeder Iteration als Subsystem in einem Anwendungsfalldiagramm darzustellen. In Ihren Diskussionen können Sie Anwendungsfälle und Anwendungsfallerweiterungen von einem dieser Subsysteme in ein anderes verschieben.

Abstraktionsebenen

Modelle haben eine Reihe von Abstraktionen in Bezug auf die Software. Die konkretesten Modelle stellen direkt Programmcode dar, und die abstraktesten Modelle stellen Geschäftskonzepte dar, die möglicherweise im Code dargestellt werden oder nicht.

Ein Modell kann über mehrere Arten von Diagrammen angezeigt werden. Informationen zu Modellen und Diagrammen finden Sie unter Erstellen von Modellen für Ihre App.

Verschiedene Arten von Diagrammen sind nützlich, um den Entwurf auf verschiedenen Abstraktionsebenen zu beschreiben. Viele der Diagrammtypen sind auf mehr als einer Ebene nützlich. In dieser Tabelle wird gezeigt, wie jeder Diagrammtyp verwendet werden kann.

Entwurfsebene	Diagrammtypen
Geschäftsprozess Wenn Sie den Kontext verstehen, in dem Ihr System verwendet wird, können Sie verstehen, was die Benutzer daraus benötigen.	- Konzeptionelle Klassendiagramme beschreiben die Geschäftskonzepte, die innerhalb des Geschäftsprozesses verwendet werden.
Benutzeranforderungen Definition, was die Benutzer von Ihrem System benötigen.	- Geschäftsregeln und Dienstqualitätsanforderungen können in separaten Dokumenten beschrieben werden.
Design auf hoher Ebene Die Gesamtstruktur des Systems: die Hauptkomponenten und ihre Zusammenführung.	- Abhängigkeitsdiagramme beschreiben, wie das System in zusammenhängende Teile strukturiert ist. Sie können Programmcode anhand von Abhängigkeitsdiagrammen überprüfen, um sicherzustellen, dass er der Architektur entspricht.
Codeanalyse Diagramme können aus dem Code generiert werden.	- Abhängigkeitsdiagramme zeigen die Abhängigkeiten zwischen Klassen an. Aktualisierter Code kann anhand eines Abhängigkeitsdiagramms überprüft werden. - Klassendiagramme zeigen die Klassen im Code an.

Externe Ressourcen

Kategorie	Verknüpfungen
Videos	MSDN "How Do I"-Videos: Wie man UML-Modelle und -Diagramme erstellt und verwendet (Visual Studio Ultimate) MSDN How Do I Series: UML Tools and Extensibility (Visual Studio Ultimate)
Foren	- Visual Studio-Visualisierungs- und Modellierungstools - Visual Studio Visualization & Modeling SDK (DSL-Tools)
Blogs	Microsoft DevOps
Technische Artikel und Zeitschriften	MSDN Architecture Center

Hinweis

Die Textvorlagentransformationskomponente wird automatisch als Teil der Visual Studio-Erweiterungsentwicklungsworkloads installiert. Sie können es auch auf der Registerkarte "Einzelne Komponenten " von Visual Studio Installer unter der Kategorie SDKs, Bibliotheken und Frameworks installieren. Installieren Sie die Modellierungs-SDK-Komponente auf der Registerkarte "Einzelne Komponenten ".

Feedback

War diese Seite hilfreich?

Last updated on 2025-10-31