.NET-Architektur mit „GoFish“ – Vision, Diagnose und Analyse

by Gregor Biswanger 5. August 2011 06:44

gofish-1

In meiner Familie ist derzeit ein hohes Interesse am Erlenen von C# aufgetaucht. Noch interessanter sind die Übungsaufgaben der heutigen Lehrliteratur. Die Ziele sind jeweils kleine Spiele zu programmieren, die das Lernen durch einen hohen Spaßfaktor versüßt. Dabei fand ich folgendes Spiel sehr amüsant: „GoFish“.

Bei Lehrbüchern wird oft nur vorgegeben, wie es zum Lösungsweg kommen soll. Dabei stehen oft unfertige Klassen und Funktionen als Starthilfe bereit. Ich nahm mir das Beispiel „GoFish“ und entwarf daraus ein komplett neues Vorzeigeprojekt. Das Vorzeigeprojekt sollte vom Umfang her nicht gleich explodieren und gerade für den Einstieg in die Architektur, Vorgehensweisen und Technologien bieten.

Das Thema Softwarearchitektur ist sehr Umfangreich, so dass diese Architektur-Serie nur recht Oberflächlich auf die meinerseits vorgegangene Vorgehensweise zu diesem Beispiel eingehen wird. Dabei werden wir gemeinsam die sechs Phasen der Entwicklung durchgehen:

image

 

Die Serie selbst wird folgende Technologien und Vorgehensweisen aufzeigen:

Visual Studio 2010 Ultimate - Architecture Tools (Use Cases, Activity Diagram, UML, Layer Diagram, Component Diagram), Skeching, Prototyping, Domain-Driven Design (DDD), Model-Driven Architecture (MDA), Test-Driven Development, Workflow-Foundation 4 (WF4), Aspektorientierte Programmierung (AOP), Reactive Extensions (Rx), Model-View-ViewModel (MVVM), WPF, Silverlight, ASP.NET MVC 3 und vieles mehr.

Ich wünsche Euch viel Spaß und bin für jede Diskussion offen!

 

Die Vision

image

Von der Idee zur Vision. So beginnt es mit jedem Softwareprojekt. In der Regel hat der Kunde eine Vision, nämlich eine Softwarelösung für sein Anliegen zu erhalten. Bei diesem Beispiel kommt die Vision eher von einem Lehrbuch. Somit also auch die Spezifikation. Dieses gibt vor ein Kartenspiel namens „GoFish“ zu programmieren. Dabei gibt es folgende Spielregeln (funktionale Anforderungen):

 

  • Das Spiel beginnt mit einem Satz aus 52 Karten. Jeder Spieler erhält fünf Karten. Die Spieler fragen einander abwechselnd nach einem Wert (Zum Beispiel: „Hat einer ein Ass?“. Hat ein anderer Spieler Karten mit diesem Wert, muss er sie abtreten. Hat kein anderer Spieler eine Karte mit diesem Wert, muss der Spieler „Fischen gehen“, indem er eine Karte aus dem Stapel nimmt.
  • Das Ziel des Spieles ist es, Quartette zu sammeln. Ein Quartett ist ein vollständiger Satz aller vier Karten mit dem gleichen Wert. Der Spieler, der am Ende des Spieles die meisten Quartette hat, ist der Gewinner. Sobald ein Spieler ein Quartett zusammen hat, legt er es offen auf den Tisch, damit jeder sehen kann, wer welche Quartette hat.
  • Bei dieser Computerversion von GoFish Gibt es zwei Computerspieler und einen normalen Spieler. Jede Runde beginnt damit, dass der Spieler unter seinen angezeigten Handkarten eine aussucht. Das macht er, indem er eine der Karten auswählt und anzeigt, dass er danach fragen wird. Dann fragen die beiden Computerspieler nach ihren Karten. Das Ergebnis der einzelnen Runden wird angezeigt. Das wird wiederholt, bis es einen Sieger gibt.
  • Das Spiel kümmert sich automatisch um den Austausch der Karten und das Ablegen der Quartette. Gibt es einen Sieger, ist das Spiel vorüber. Dann zeigt das Spiel den Namen des Siegers an (oder der Sieger, falls es unentschieden ausgeht). Es kann nichts mehr gemacht werden – der Spieler muss das Programm neu starten, um ein neues Spiel zu beginnen.

 

Somit sind schon die wichtigsten Informationen vorhanden. Bei einem realen Projekt, sieht es oft ganz anders aus. Es sind vonseiten des Kunden nur Ideen vorhanden, worauf noch lange nicht alle Anforderungen bewusst/bekannt sind. Dann kommt noch ein weiteres Problem. Die Kommunikation. Der Kunde ist Business-Experte in seinem Arbeitsbereich und der Entwickler ist Business-Experte beim Programmieren von Software. Dabei möchte der Kunde nicht erst erlenen wie man Software schreibt und wir Entwickler wollen nicht das Fach vom Kunden studieren.

 

Eine „Common-Language“ aufbauen

Für dieses Problem gibt es nur eine Lösung. Man muss eine „Common Language“ aufbauen. Wenn man sich die Grafik in Abbildung 1 etwas genauer ansieht. Stellt man fest, dass es einen Treffpunkt beider Welten gibt. Genau bei diesem Treffpunkt können wir miteinander eine gemeinsame Sprache sprechen, mittels Software auf dem Bildschirm.

 

Abbildung 1 – Die Common Language

 

Mein Tipp! Das Video-Tutorial "Wie Projekte richtig starten?" 

 

Die Diagnose

image

Wir kommen ab hier zur Diagnose-Phase. Anforderungsanalyse und -spezifikation (engl. Requirement analysis and specification)

  • Die Diagnostic Phase beginnt bereits während des Verkaufsvorgangs und endet mit der Angebotsannahme für das Implementierungsprojekt.
  • Ziel der Diagnostic Phase ist es, ausreichend Informationen zusammenzutragen, um den Projektumfang auf höchster Ebene zu definieren und ein aussagekräftiges Angebot für die nächste Phase zu erstellen.
  • Die wichtigsten Zielvorgaben in dieser Phase sind das Implementierungsangebot und der Projektplan.

 

Sketches

Zum Aufbau der “Common Language” eignet sich geradezu ideal, das Sketching. Mittels Sketching kann blitzschnell vorgezeigt werden, welches Bild man aus den Anforderungen gewonnen hat. Dabei kann der Kunde sehr schnell ein Ergebnis sehen und das Bild in die richtige Richtung lenken. Dabei behilft das Sketching weiterhin bei der Anforderungsanalyse. Vergessene Anforderungen werden jetzt ersichtlicher. Zusätzliche Ideen bauen sich schneller auf.

Vorteile durch Sketching:

  • Common Language wird aufgebaut
  • Schnelles Ergebnis
  • Schnell und leicht änderbar
  • Behilft bei der Anforderungsanalyse

 

Als Sketching Tool empfehle ich Balsamiq Mockups. Hier können sehr schnell Sketches zu Anwendungen zusammengestellt werden. Sehr wichtig ist, dass die Sketches wie gezeichnet aussehen. Somit wird garantiert, dass wirklich nur über die Anforderungen und nicht über das Design gesprochen wird. Ich bin bei Projekten oft selbst darauf reingefallen, indem ich über die Farben gesprochen hatte, obwohl es nur Sketches für die Anforderungsanalyse waren.

 

SNAGHTMLaf7a52d

Abbildung 2 – Balsamiq Mockups – Tool zum Erstellen von Sketches

 

Für GoFish fertigte ich erst Sketches in Balsamiq Mockups an. Obwohl diese eigentlich bereits durch das Buch vorgegeben wurden. Dennoch machte ich dies für diesen Blog-Post.

 

image

Abbildung 3 – Der Sketch zu “GoFish”

 

Zusätzlich sollte für ein Softwareprojekt, ein Portal wie SharePoint angelegt werden. Hierbei lässt sich die „Common Language“ durch ein Glossar für Fremdwörter einfach erweitern. Auch das Verwenden von Brainstorming mittels Mind-Maps, lässt noch einiges an Ideen auftauchen.

Mein Tipp! Die SharePoint Lösung Project4Sure – Hier werden alle Phasen durch SharePoint begleitet und können hervorragend gemanagt werden. http://www.project4sure.com

Die Brainstorming-App für Windows Phone 7. Windows Phone 7 App – Brainstorming

Das Video-Tutorial “Sketches mit Balsamiq Mockup

 

Die Analyse

image

Wir kommen ab hier zur Analyse-Phase. Systemdesign und -spezifikation (engl. System design and specification)

  • Ziel der Analysis Phase ist es, alle in der Diagnostic Phase erkannten Anforderungen genau zu spezifizieren und die erforderlichen Geschäftsprozesse zu modellieren. Die Beschreibung der Anforderungen und Prozesse erfolgt produktneutral.
  • Die wichtigsten Zielvorgaben in dieser Phase sind die Erstellung der Functional Requirement Dokumente FRDs und der Dokumentation der Geschäftsanforderungen in den Business Process Dokumenten bzw. in einem externen Prozessmodellierungstool.

 

Modellieren

Use Case

Ich beginne mit dem Entwerfen von Anwendungsfällen (Use Cases - UML). Um eine Systemanalyse zu führen. Hierbei lässt sich sehr schnell Diagnostizieren, welche Abhängigkeiten von anderen Systemen gegeben sind. Auch ein Ziel ist es, möglichst einfach zu zeigen, was man mit dem zu bauenden Softwaresystem machen will. Welche Fälle es in der Anwendung also gibt.

Dazu habe ich in Visual Studio 2010 Ultimate die Architecture-Features verwendet und ein Use Case Diagramm erzeugt.

 

image

Abbildung 4 – Das Use Case Diagramm für „GoFish“

Das Domänen-Modell

Anschließend modellierte ich nach Domain-Driven Design (kurz DDD) von Eric Evans, ein Domänen-Modell (DomainModel). Hier geht es auch darum eine allgemeine Sprache aufzubauen. Die allgemeine Sprache baut sich aufgrund des Softwaredesigns auf, die sich nach dem Umfeld (Domäne) der Anforderungen ergibt. Dabei soll zum Beispiel mittels einfachen UML ein Schema entworfen werden, das anschließend den Code dazu generieren kann. Bei DDD wird zu Beginn auch kein Datenbankschema entworfen, sondern der Fokus bleibt bei einem Klassenmodell. Somit lassen sich komplexe Vorgänge einfacher implementieren. Weil hierbei die Abhängigkeit zum Datenbankschema genommen wird.

Als Tool verwendete ich die Visual Studio 2010 Ultimate-Version mit den Architecture-Features. Worin ich das Standard UML verwendete.

image

Abbildung 5 – Das DomainModel von „GoFish“

Dabei beschreibt das DomainModel folgendes:

  • Wir haben einen Spieltisch mit keiner oder mehreren Karten (Kartenstapel). Der Spieltisch hat auch noch mehrere Spieler.
  • Wir haben einen Spieler mit keinen oder mehreren Spielkarten. Der Spieler kann zudem ein Quartett haben oder mehrere.
  • Die Spielkarte kann auf dem Spieltisch oder dem Spieler öfter vorhanden sein, oder auch nicht.

 

Der Spieltisch (GamblingTable), Die Spielkarte (Card) und der Spieler (Player) sind jeweils Entitäten (Entities bzw. Reference Objects). Denn diese Gegenstände bleiben ein und dasselbe, auch wenn sich die Eigenschaften dazu ändern sollten. Entitäten werden oft mit Hilfe von eindeutigen Identifikatoren modelliert.

Bei „GoFish“ hatte ich die ID für den Spieltisch ausgelassen. Denn dieser Tisch soll nur einmalig existieren.

Die Farbe (ColorType) und der Wert (ValueType) der Spielkarte, bezeichnet man als Wertobjekte (Value Objects).

 

Mein Tipp! Das Buch von Eric Evans Domain-Driven Design: Tackling Complexity in the Heart of Software

Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture to Manage Complexity and Enable Change

 

Die Aktivitätsdiagramme (Activity Diagram)

Der nächste Schritt, war das definieren der einzelnen Prozesse. Dafür eigenen sich Aktivitätsdiagrammegeradezu ideal. Das Aktivitätsdiagramm ist ein Verhaltensdiagramm. Worin einzelne Aktionen grafisch miteinander verbunden werden. Auch dieses UML-Diagram ist in den Architecture Tools von Visual Studio 2010 Ultimate enthalten. Damit legte ich auch erst den Spielstart als einzelnen Prozess fest.

GameSetUpActivityDiagram

Abbildung 6 – Der Spielstart als Aktivitätsdiagramm

 

Die Architektur von Spielen ist auf so genannte Game Loops gelegt. Hierbei soll bei jeder Iteration das Spiel durch Zustände geregelt werden. Eher baut sich diese Strategie auf das zusätzliche Rendern (Zeichnen) bei einem Intervall auf, das bei 3D Spielen zum Einsatz kommt. jedoch konnte ich für GoFish auch eine Iteration wiederfinden. Somit entwarf ich den Prozess, beginnend mit der Aktion „Auswahl einer Spielkarte“ als Aktivitätsdiagramm, das nun als die Game Loop fungieren soll.

 

GameCoreActivityDiagram

Abbildung 7 – Die Game Loop von GoFish als Aktivitätsdiagramm

 

Prototyping mit SketchFlow

image

Wenn die Prozesse definiert wurden, können die Sketches interaktiv miteinander als SketchFlow verknüpft werden. So das diese als Prototype fungieren können. Der Vorteil liegt darin, dass nun die Vision vom Kunden „spürbar“ wird. Ab diesen Zeitpunkt kann man sich verstärkt mit den Thema Usability auseinandersetzen. Mittels SketchFlow verwendete ich bereits bei Kundenprojekten ein Eye-Tracking-System, um korrekt ermitteln zu können, dass die angewandte User Experience die richtige Zielgruppe von Anwendern trifft.

Als Tool eignet sich Microsoft Expression Blend 4 Ultimate mit SketchFlow. Expression Blend ist vorwiegend für Designer konzeptioniert worden, die damit für WPF und Silverlight, die Oberflächen gestalten können. SketchFlow ist eine Erweiterung die nur im Ultimate-Paket enthalten ist. Damit lassen sich WPF und Silverlight-Prototypen erstellen, die mittels SketchFlow-Player beim Kunden interaktiv verwendet werden können. Das Besondere am SketchFlow-Player ist die integrierte Feedback-Funktion. Worin der Kunde auf der Oberfläche selbst zeichnen und Feedback geben kann. Eine SharePoint Erweiterung bietet zusätzlich eine klassische Dokumentenverwaltung der Feedbacks an.

Vorteile durch einen SketchFlow:

  • Zusammenhänge werden verständlicher
  • Die Common Language wird erweitert
  • Benutzbarkeit (Usability) kann getestet werden
  • Behilft weiterhin bei der Anforderungsanalyse

 

Bei Expression Blend SketchFlow können die Sketches von Balsamiq Mockup weiterhin verwendet werden, indem man diese als Bilder importiert. Um Steuerelemente interaktiv einzubinden, muss das Sketch-Bild auf die letzte Hintergrund-Ebene. Somit können die Steuerelemente einfach über das Bild gelegt werden.

ExpressionBlendSketchFlow

Abbildung 9 – GoFish als SketchFlow-Prototype mit Expression Blend 4

 

Normal hätte ich auch den SketchFlow-Prototypen nicht unbedingt machen müssen. Denn im Buch wurde bereits eine Sketch-Vorlage gegeben und es gibt auch keinen Kunden dazu.

SketchFlowPlayer

Abbildung 10 – GoFish als SketchFlow-Prototype im SketchFlow-Player mit Feedback

Mein Tipp: Das Video-Tutorial zu “Prototypen mit SketchFlow

 

Zusammenfassung und Vorschau auf den nächsten Teil

Wir haben nun gemeinsam an den Phasen der Vision, Diagnose und der Analyse geschnuppert. Dabei wurde auf das Thema Kommunikation eingegangen und das diese durch Metaphorik vereinheitlicht wird. Es beginnt mit Sketching, Modellierung und endet mit Prototyping. Bei richtigen Kunden-Projekten kommen natürlich noch zusätzliche Dokumentationsverfahren zum Einsatz. Die vom Umfang zu groß wären, um diese hier ausführlich behandeln zu können. Auch unterscheidet sich die Vorgehensweise durch den Entwicklungsprozess. Zum Beispiel Agile-Prozesse wie SCRUM oder XP. Dieser Artikel soll eben nur zum allgemeinen Einstieg behelfen und meine Vorgehensweise bei der Lösung der Aufgabe „GoFish“.

Beim nächsten Teil werden wir die Phase Design und Development genauestens ansehen. Es beginnt mit der Abstraktion der Anforderungen, bis hin zur Entwicklung mit Test-Driven Development (TDD).

Viel Spaß und bis zu der nächsten Folge, wenn Ihr mögt!



Wenn ihnen der Artikel gefallen hat oder er für sie hilfreich war, bitten "kicken" sie ihn.
kick it on dotnet-kicks.de

Kommentare

Powered by BlogEngine.NET 1.4.5.0
Theme by Extensive SEO

Über den Autor

Gregor Biswanger

Microsoft MVP für Client App Dev
XING

Gregor Biswanger (Microsoft MVP für Client App Dev) ist freier Consultant, Trainer, Autor und Speaker.


Seine Schwerpunkte liegen im Bereich der .NET-Architektur, agilen Prozessen und XAML. Er veröffentlichte vor kurzem seine DVD´s mit Video-Trainings zum Thema „Meine erste Windows 8 App“, „Windows Store Apps mit XAML und C#“ und „WPF 4.5 und Silverlight 5“ bei Addison-Wesley von video2brain.


Biswanger ist auch im Auftrag von Intel GmbH als Technologieberater für die Intel Developer Zone aktiv und ist Leader bei der Ingolstädter .NET Developers Group (INdotNET). 

 

Video über mich:
http://www.youtube.com/watch?v=mx_6SiiLxjk


Basta! 2011 Speaker

CLIPer

MCTS
Windows SharePoint Services 3.0 – Application Development (MCTS)