Exportieren (0) Drucken
Alle erweitern
Dieser Artikel wurde manuell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen. Weitere Informationen
Übersetzung
Original

Verwenden von Modellen im Entwicklungsprozess

In Visual Studio Ultimate können Sie ein Modell verwenden, um ein System, eine Anwendung oder eine Komponente zu verstehen und zu ändern. Mit einem Modell können Sie das Umfeld des Systems visuell darstellen, Anforderungen der Benutzer verdeutlichen, die Architektur des Systems definieren, den Code analysieren und sicherstellen, dass der Code die Anforderungen erfüllt.

Siehe Channel 9-Video: Verbessern Sie Architektur von Modellierung.

Modelle können auf verschiedene Weise von Nutzen sein:

  • Durch das Zeichen von Modellierungsdiagrammen können Sie die Konzepte für Anforderungen, Architektur und allgemeinen Entwurf verdeutlichen. Weitere Informationen finden Sie unter Modellieren von Benutzeranforderungen.

  • Durch das Arbeiten mit Modellen können Sie mangelnde Übereinstimmungen in den Anforderungen aufzeigen.

  • Mithilfe von Modellen können Sie wichtige Konzepte eindeutiger als mithilfe von natürlicher Sprache mitteilen. Weitere Informationen finden Sie unter Modellieren der Architektur eines Softwaresystems.

  • Manchmal können Sie mithilfe von Modellen Code oder andere Artefakte, z. B. Datenbankschemas oder Dokumente, generieren. Beispielsweise werden die Modellierungskomponenten von Visual Studio Ultimate aus einem Modell generiert. Weitere Informationen finden Sie unter Generieren und Konfigurieren der Anwendung aus Modellen.

Sie können Modelle in einer Vielzahl von Prozessen, von äußerst agilen bis zu sehr förmlichen Prozessen, verwenden.

Dd409423.collapse_all(de-de,VS.120).gifVerwenden Sie Modelle, um Mehrdeutigkeit zu reduzieren

Die Modellierungssprache ist weniger mehrdeutig als natürliche Sprache, und sie ist zum Darstellen der Konzepte vorgesehen, die normalerweise während der Softwareentwicklung erforderlich sind.

Wenn das Projekt von einem kleinen Team mit agilen Verfahren durchgeführt wird, können Sie mithilfe von Modellen User Stories verdeutlichen. In Gesprächen mit den Kunden über ihre Anforderungen lassen sich durch das Erstellen eines Modells viel schneller hilfreiche Fragen generieren, und zwar zu einem breiteren Bereich des Produkts, als durch das Schreiben von Spike- oder Prototypcode.

Wenn das Projekt umfangreich ist und Teams aus verschiedenen Ländern auf dem Globus umfasst, können Sie mithilfe von Modellen die Anforderungen und Architektur effizienter als mit Klartext vermitteln.

In beiden Fällen lassen sich durch das Erstellen eines Modells mangelnde Übereinstimmungen und Mehrdeutigkeiten fast immer erheblich reduzieren. Unterschiedliche Projektbeteiligte verfügen über unterschiedliche Vorstellungen von dem Geschäftsumfeld, in dem das System eingesetzt wird, und unterschiedliche Entwickler verfügen häufig über unterschiedliche Vorstellungen von der Funktionsweise des Systems. Mit einem Modell als Mittelpunkt eines Gesprächs werden diese Unterschiede in der Regel aufgezeigt. Weitere Informationen zum Reduzieren mangelnder Übereinstimmungen mithilfe eines Modells finden Sie unter Modellieren von Benutzeranforderungen.

Dd409423.collapse_all(de-de,VS.120).gifVerwenden Sie Modelle mit anderen Artefakten

Ein Modell allein ist noch keine Anforderungsspezifikation der Architektur. Es ist ein Werkzeug, um einige Aspekte klarer darzustellen, jedoch können nicht alle während des Softwareentwurfs erforderlichen Aspekte dargestellt werden. Die Modelle sollten daher zusammen mit anderen Kommunikationsmitteln, z. B. OneNote-Seiten oder -Absätzen, Microsoft Office-Dokumenten, Arbeitsaufgaben in Team Foundation oder Haftnotizen an der Wand des Projektraums, verwendet werden. Außer dem letzten Element können alle diese Objekttypen mit Elementteilen des Modells verknüpft werden.

Zusammen mit Modellen werden gewöhnlich folgende weitere Spezifikationsaspekte verwendet. Je nach Umfang und Art des Projekts verwenden Sie eventuell mehrere oder keinen dieser Aspekte:

  • User Stories. Eine User Story ist eine kurze Beschreibung eines Aspekts des Systemverhaltens, der mit Benutzern und anderen Projektbeteiligten erörtert und in einer der Iterationen des Projekts bereitgestellt wird. Eine typische User Story beginnt mit "Der Kunde ist in der Lage, zu …". Eine User Story kann eine Gruppe von Anwendungsfällen einführen oder Erweiterungen von Anwendungsfällen definieren, die zuvor entwickelt wurden. Das Definieren oder Erweitern der Anwendungsfälle trägt zur größeren Verständlichkeit der User Story bei.

  • Änderungsanforderungen. Ein Änderungsantrag in einem eher formalen Projekt ist einer User Story in einem agilen Projekt sehr ähnlich. Bei der agilen Vorgehensweise werden alle Anforderungen als Änderungen der Entwicklung in vorherigen Iterationen behandelt.

  • Anwendungsfallbeschreibung. Ein Anwendungsfall stellt eine der Methoden dar, mithilfe derer ein Benutzer mit dem System interagieren kann, um ein bestimmtes Ziel zu erreichen. Die vollständige Beschreibung enthält das Ziel, die Hauptsequenz und alternative Sequenzen von Ereignissen sowie außergewöhnliche Ergebnisse. Ein Anwendungsfalldiagramm bietet eine Zusammenfassung und einen Überblick über die Anwendungsfälle.

  • Szenarien. Ein Szenario ist eine ausführliche Beschreibung einer Sequenz von Ereignissen, die darstellt, wie sich durch die Interaktion von System, Benutzern und anderen Systemen sinnvolle Ergebnisse für die Projektbeteiligten ergeben. Dabei kann es sich um eine Bildschirmpräsentation der Benutzeroberfläche oder einen Prototyp der Benutzeroberfläche handeln. Ein Szenario kann einen Anwendungsfall oder eine Sequenz von Anwendungsfällen beschreiben.

  • Glossar. Das Glossar zu den Anforderungen des Projekts beschreibt die Wörter, mit denen die Kunden ihre Welt beschreiben. Diese Begriffe sollten auch im Benutzeroberflächenmodell und Anforderungsmodell verwendet werden. Ein Klassendiagramm kann dazu beitragen, die Beziehungen zwischen den meisten von diesen Begriffen zu verdeutlichen. Durch das Erstellen der Diagramme und des Glossars werden nicht nur Missverständnisse zwischen Benutzern und Entwicklern reduziert, sondern fast immer auch Missverständnisse zwischen unterschiedlichen Projektbeteiligten aufgeklärt.

  • Geschäftsregeln. Viele Geschäftsregeln können als unveränderliche Einschränkungen der Zuordnungen und Attribute im Anforderungsklassenmodell und als Einschränkungen in Sequenzdiagrammen dargestellt werden.

  • Allgemeiner Entwurf. Beschreibt die Hauptbestandteile und wie sie zusammenpassen. Komponenten-, Sequenz- und Schnittstellendiagramme sind wesentliche Teile eines allgemeinen Entwurfs.

  • Entwurfsmuster. Beschreiben die gemeinsamen Entwurfsregeln für die verschiedenen Teile des Systems.

  • Testspezifikationen. In Testskripts und den Entwürfen für Testcode können Aktivitäts- und Sequenzdiagramme zum Beschreiben der Sequenzen von Testschritten genutzt werden. Systemtests sollten im Anforderungsmodell dargestellt werden, damit sie leicht geändert werden können, wenn sich die Anforderungen ändern.

  • Projektplan. Der Projektplan oder -rückstand legt fest, wann die einzelnen Funktionen bereitgestellt werden. Sie können jede Funktion definieren, indem Sie angeben, welche Anwendungsfälle und Geschäftsregeln von ihr implementiert oder erweitert werden. Sie können entweder direkt im Plan auf die Anwendungsfälle und Geschäftsregeln verweisen, oder Sie können in einem eigenen Dokument einen Satz von Funktionen definieren und im Plan die Funktionstitel verwenden.

Dd409423.collapse_all(de-de,VS.120).gifVerwenden Sie Modelle bei der Iterationsplanung

Obwohl sich alle Projekte hinsichtlich Umfang und Organisation unterscheiden, wird ein typisches Projekt als eine Reihe von Iterationen mit einer Dauer von zwei bis sechs Wochen geplant. Es ist wichtig, eine ausreichende Anzahl von Iterationen zu planen, um Feedback von frühen Iterationen zu ermöglichen, mit dem der Umfang und die Pläne für spätere Iterationen angepasst werden können.

Möglicherweise tragen die folgenden Empfehlungen dazu bei, die Vorteile der Modellierung in einem iterativen Projekt auszuschöpfen.

Dd409423.collapse_all(de-de,VS.120).gifKonzentrieren Sie sich vor Beginn jeder Iteration auf das Wesentliche

Definieren Sie vor Beginn jeder Iteration mithilfe von Modellen, was am Ende der Iteration bereitgestellt werden muss.

  • Modellieren Sie in frühen Iterationen nicht ausführlich alle Details. Erstellen Sie in der ersten Iteration ein Klassendiagramm für die Hauptelemente im Benutzerglossar, zeichnen Sie ein Diagramm der Hauptanwendungsfälle, und zeichnen Sie ein Diagramm der Hauptkomponenten. Beschreiben Sie nicht die Details dieser Elemente, da sich die Details später im Projekt ändern. Verwenden Sie die in diesem Modell definierten Begriffe, um eine Liste von Funktionen oder wichtigen User Stories zu erstellen. Weisen Sie Iterationen Funktionen zu, um die Arbeitsauslastung während des gesamten Projekts ungefähr gleichmäßig zu verteilen. Diese Zuweisungen werden später im Projekt geändert.

  • Versuchen Sie, in einer frühen Iteration vereinfachte Versionen aller besonders wichtigen Anwendungsfälle zu implementieren. Erweitern Sie diese Anwendungsfälle in späteren Iterationen. Auf diese Weise verringern Sie das Risiko, einen Fehler in den Anforderungen oder der Architektur zu einem Zeitpunkt des Projekts zu erkennen, zu dem der Fehler nicht mehr behoben werden kann.

  • Veranstalten Sie gegen Ende jeder Iteration einen Anforderungsworkshop, um die Details der Anforderungen oder User Stories zu definieren, die in der nächsten Iteration entwickelt werden. Laden Sie Benutzer und Projektbeteiligte, die Entscheidungen zu Prioritäten treffen können, sowie Entwickler und Systemtester zur Teilnahme ein. Planen Sie zum Definieren der Anforderungen für eine Iteration von 2 Wochen eine Workshopdauer von 3 Stunden ein.

  • Der Workshop soll dazu führen, dass alle Projektbeteiligten Übereinstimmung über die bis zum Ende der nächsten Iteration zu erreichenden Ergebnisse erzielen. Verwenden Sie Modelle als eines der Instrumente zum Klarstellen der Anforderungen. Das Ergebnis des Workshops ist ein Iterationsrückstand. Dabei handelt es sich um eine Liste von Entwicklungsaufgaben in Team Foundation und von Testsammlungen in Microsoft Test-Manager.

  • Besprechen Sie im Anforderungsworkshop den Entwurf nur insoweit, als Sie die Entwicklungsaufgaben schätzungsweise bestimmen müssen. Begrenzen Sie ansonsten die Besprechung auf Systemverhalten, das Benutzer direkt wahrnehmen können. Halten Sie das Anforderungsmodell vom Architekturmodell getrennt.

  • Projektbeteiligte ohne technischen Hintergrund verstehen normalerweise UML-Diagramme ohne Probleme, wenn sie von Ihnen Erläuterungen erhalten.

Dd409423.collapse_all(de-de,VS.120).gifVerknüpfen Sie das Modell mit Arbeitsaufgaben

Bestimmen Sie nach dem Anforderungsworkshop die Details des Anforderungsmodells, und verknüpfen Sie das Modell mit Entwicklungsaufgaben. Sie können zu diesem Zweck Arbeitsaufgaben in Team Foundation mit Elementen im Modell verknüpfen. Informationen hierzu finden Sie unter Verknüpfen von Modellelementen und Arbeitsaufgaben.

Sie können jedes Element mit Arbeitsaufgaben verknüpfen, die zweckmäßigsten Elemente lauten jedoch wie folgt:

  • Anwendungsfälle. Sie können einen Anwendungsfall mit den Entwicklungsaufgaben verknüpfen, durch die er implementiert wird.

  • Anwendungsfallerweiterungen. Wenn in einer Iteration nur ein Aspekt eines Anwendungsfalls implementiert wird, können Sie ihn zusammen mit einer oder mehreren Erweiterungen als Basisanwendungsfall abtrennen. Die Erweiterungen sind Anwendungsfälle, die über die Beziehung «extend» mit dem Basisfall verknüpft sind. Weitere Informationen über Anwendungsfallerweiterungen finden Sie unter UML-Anwendungsfalldiagramme: Referenz.

  • Kommentare, die Geschäftsregeln oder Servicequalitätsanforderungen beschreiben. Weitere Informationen finden Sie unter Modellieren von Benutzeranforderungen.

Dd409423.collapse_all(de-de,VS.120).gifVerknüpfen Sie das Modell mit Tests

Verwenden Sie das Anforderungsmodell als Orientierungshilfe für den Entwurf der Akzeptanztests. Erstellen Sie diese Tests während der Entwicklungsarbeit.

Weitere Informationen zu diesem Verfahren finden Sie unter Entwickeln von Tests aus einem Modell.

Dd409423.collapse_all(de-de,VS.120).gifSchätzen Sie den restlichen Arbeitsaufwand

Mithilfe eines Anforderungsmodells lässt sich der Gesamtumfang des Projekts im Verhältnis zum Umfang der einzelnen Iterationen schätzen. Durch Bestimmen von Anzahl und Komplexität der Anwendungsfälle und Klassen können Sie die erforderliche Entwicklungsarbeit genauer schätzen. Wenn Sie die ersten Iterationen abgeschlossen haben, können Sie durch den Vergleich der erfüllten Anforderungen mit den noch zu erfüllenden Anforderungen den restlichen Aufwand und Umfang des Projekts näherungsweise bestimmen.

Überprüfen Sie gegen Ende jeder Iteration die Zuweisung von Anforderungen zu zukünftigen Iterationen. Es kann sinnvoll sein, den Zustand der Software am Ende jeder Iteration als Subsystem in einem Anwendungsfalldiagramm darzustellen. In den Besprechungen können Sie Anwendungsfälle und Anwendungsfallerweiterungen zwischen den Subsystemen verschieben.

Modelle abstrahieren die Software in unterschiedlichem Ausmaß. Der konkretesten Modelle stellen direkt den Programmcode dar, und die abstraktesten Modelle stellen Geschäftskonzepte dar, die nicht in jedem Fall im Code dargestellt werden.

Ein Modell kann über mehrere Arten von Diagrammen dargestellt werden. Informationen über Modelle und Diagramme finden Sie unter Entwickeln von Modellen für den Softwareentwurf.

Zum Beschreiben des Entwurfs auf unterschiedlichen Abstraktionsebenen eignen sich unterschiedliche Arten von Diagrammen. Viele der Diagrammtypen sind für mehrere Ebenen sinnvoll. In der folgenden Tabelle wird gezeigt, wie jeder Diagrammtyp verwendet werden kann.

Entwurfsebene

Diagrammtypen

Geschäftsprozess

Wenn Sie den Kontext kennen, in dem das System verwendet wird, erleichtert dies das Verständnis der Anforderungen der Benutzer an das System.

  • Aktivitätsdiagramme beschreiben den zum Erreichen von Geschäftszielen erforderlichen Arbeitsfluss zwischen Personen und Systemen.

  • Konzeptionelle Klassendiagramme beschreiben die innerhalb des Geschäftsprozesses verwendeten Geschäftskonzepte.

Benutzeranforderungen

Die Definition der Anforderungen der Benutzer an das System.

  • In Anwendungsfalldiagrammen werden die Interaktionen der Benutzer und anderer externer Systeme mit dem System, das Sie entwickeln, zusammengefasst. Sie können an jeden Anwendungsfall weitere Dokumente anfügen, um ihn ausführlich zu beschreiben.

  • UML-Klassendiagramme beschreiben die Typen von Informationen, über die die Benutzer und das System kommunizieren.

  • Geschäftsregeln und Servicequalitätsanforderungen können in eigenen Dokumenten beschrieben werden.

Allgemeiner Entwurf

Die Gesamtstruktur des Systems: die Hauptkomponenten und wie sie verknüpft sind.

  • Ebenendiagramme beschreiben, wie das System in von einander abhängige Teile gegliedert ist. Sie können Programmcode anhand von Ebenendiagrammen überprüfen, um sicherzustellen, dass er der Architektur entspricht.

  • Komponentendiagramme zeigen die Schnittstellen der Teile an und geben die Meldungen und die Dienste an, die bereitgestellt und von jeder Komponente verlangt werden.

  • Sequenzdiagramme zeigen, wie die Komponenten kommunizieren, um die einzelnen Anwendungsfälle zu implementieren.

  • UML-Klassendiagramme beschreiben die Schnittstellen der Komponenten und die Typen der Daten, die zwischen den Komponenten übergeben werden.

Entwurfsmuster

Konventionen und Methoden zum Lösen von Entwurfsproblemen, die in allen Teilen des Entwurfs verwendet werden.

  • UML-Klassendiagramme beschreiben die Strukturen eines Musters.

  • Sequenz- oder Aktivitätsdiagramme stellen die Interaktionen und Algorithmen dar.

Codeanalyse

Aus dem Code können mehrere Typen von Diagrammen generiert werden.

  • Sequenzdiagramme zeigen die Interaktion zwischen Objekten im Code.

  • Ebenendiagramme zeigen die Abhängigkeiten zwischen Klassen. Aktualisierter Code kann anhand eines Ebenendiagramms überprüft werden.

  • Klassendiagramme zeigen die Klassen im Code.

Community-Beiträge

HINZUFÜGEN
Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2015 Microsoft