Wir begrüßen ein neues Mitglied im Team!
Knuddelmaus hat sich bereiterklärt, die Hintergrundmusik für Japan War zu erstellen.
Derzeit ist sie in der Analysephase und jeder ist recht herzlich eingeladen, im Forum Anregung und Kritik beizusteuern!
Hier geht es direkt zum entsprechenden Forenbeitrag
Sonntag, 8. November 2009
Dienstag, 29. September 2009
Textanalyse
Die Textanalyse ist ein Instrument, um Klassenkandidaten und Methodenkandidaten zu finden.
Wir setzen sie ein, um Kandidaten zu sammeln, damit wir das erste vorläufige Design entwickeln können.
Bei der Textanalyse notieren wir jedes Substantiv und jedes Verb der entsprechenden detaillierten Anwendungsfallbeschreibung.
Dabei streichen wir Substantive und Verben, die lediglich dazu im Text stehen, um den Textfluss zu ermöglichen. Beispiel: System, ist
Danach werden Synonyme gesucht. Ein Synonym ist ein Wort, das die gleiche Bedeutung eines anderen Wortes hat.
Im aktuellen Fall waren das:
Im aktuellen Fall gibt es ein Homonym: Teilnehmer.
Damit ist einerseits ein Teilnehmer im Mehrspielerraum gemeint und andererseits ein Teilnehmer am startenden Spiel.
Wir sehen es so vor, dass mehr Teilnehmer im Mehrspielerraum sein können, als tatsächlich beim Spiel mitspielen werden, damit bei einem hohen Andrang die Möglichkeit besteht, alle gewünschen Spielteilnehmer Zutritt zu verschaffen.
Wir setzen sie ein, um Kandidaten zu sammeln, damit wir das erste vorläufige Design entwickeln können.
Bei der Textanalyse notieren wir jedes Substantiv und jedes Verb der entsprechenden detaillierten Anwendungsfallbeschreibung.
Dabei streichen wir Substantive und Verben, die lediglich dazu im Text stehen, um den Textfluss zu ermöglichen. Beispiel: System, ist
Danach werden Synonyme gesucht. Ein Synonym ist ein Wort, das die gleiche Bedeutung eines anderen Wortes hat.
Im aktuellen Fall waren das:
- Mehrspielerraum, Raum
- Spieler, Teilnehmer
- Farbmarkierung, Farbauswahl
- Wunschfarbe, Farbe
- Host, Hostspieler
Im aktuellen Fall gibt es ein Homonym: Teilnehmer.
Damit ist einerseits ein Teilnehmer im Mehrspielerraum gemeint und andererseits ein Teilnehmer am startenden Spiel.
Wir sehen es so vor, dass mehr Teilnehmer im Mehrspielerraum sein können, als tatsächlich beim Spiel mitspielen werden, damit bei einem hohen Andrang die Möglichkeit besteht, alle gewünschen Spielteilnehmer Zutritt zu verschaffen.
Montag, 28. September 2009
Anwendungsfall detailliert beschreiben
Nachdem wir im letzten Schritt die Reihenfolge der Abarbeitung der ersten Anwendungsfälle bestimmt haben, formulieren wir den Anwendungsfall detailliert aus.
Dabei schreiben wir so genannte Hauptpfade nieder und ergänzen sie durch Nebenpfade.
Der Hauptpfad ist der Programmablauf, der in den meisten Fällen eintreten wird.
Nebenpfade treten seltener auf.
Während wir Anwendungsfälle schreiben, werfen wir immer wieder einen Blick auf die Feature-Liste, um nichts bei der Beschreibung zu vergessen.
Dabei schreiben wir so genannte Hauptpfade nieder und ergänzen sie durch Nebenpfade.
Der Hauptpfad ist der Programmablauf, der in den meisten Fällen eintreten wird.
Nebenpfade treten seltener auf.
Während wir Anwendungsfälle schreiben, werfen wir immer wieder einen Blick auf die Feature-Liste, um nichts bei der Beschreibung zu vergessen.
Dienstag, 22. September 2009
Iteration beginnen
Beginnen wir die Iteration.
Iteration bedeutet, dass Stück für Stück, Anwendungsfall für Anwendungsfall abgearbeitet wird und das mit den folgenden Schritten:
Heute betrachten wir den Punkt "Einen Anwendungsfall bestimmen":
Es werden drei Fragen gegen alle Anwendungsfaelle gerichtet:
Ist das Wesen des Systems?
Weiß ich, was das bedeuten soll?
Weiß ich, wie man das technisch umsetzt?
Anhand der Fragen haben wir jene Anwendungsfälle identifiziert, denen wir volle Aufmerksamkeit widmen sollten.
Denn wenn wir bei diesen Anwendungsfaellen einen Fehler im Desing machen, kann sich das nachhaltig negativ auf das Gesamtsystem auswirken.
Nun gibt es aber mehrere Anwendungsfälle, mit denen wir anfangen sollten, weil sie wichtig für die Zukunft des Projekts sind.
Wir müssen jedoch einen einzigen bestimmen, bei dem wir anfangen.
Wir haben uns daher entschieden, einen Pfad durch das Anwendungsfalldiagramm beginnend vom Akteur zu ziehen, der die maximale Anzahl von Anwendungsfällen beinhaltet, die wichtig sind.
Die Anwendungsfälle werden dann der Reihe nach abgearbeitet.
Ziel dieser Vorgehensweise ist es, dass man von Anfang an einen Einstiegspunkt im System hat, um es präsentieren zu können.
Iteration bedeutet, dass Stück für Stück, Anwendungsfall für Anwendungsfall abgearbeitet wird und das mit den folgenden Schritten:
- Einen Anwendungsfall bestimmen
- Textanalyse
- Vorläufiges Design
- Implementierung
Heute betrachten wir den Punkt "Einen Anwendungsfall bestimmen":
Es werden drei Fragen gegen alle Anwendungsfaelle gerichtet:
Ist das Wesen des Systems?
Weiß ich, was das bedeuten soll?
Weiß ich, wie man das technisch umsetzt?
Anhand der Fragen haben wir jene Anwendungsfälle identifiziert, denen wir volle Aufmerksamkeit widmen sollten.
Denn wenn wir bei diesen Anwendungsfaellen einen Fehler im Desing machen, kann sich das nachhaltig negativ auf das Gesamtsystem auswirken.
Nun gibt es aber mehrere Anwendungsfälle, mit denen wir anfangen sollten, weil sie wichtig für die Zukunft des Projekts sind.
Wir müssen jedoch einen einzigen bestimmen, bei dem wir anfangen.
Wir haben uns daher entschieden, einen Pfad durch das Anwendungsfalldiagramm beginnend vom Akteur zu ziehen, der die maximale Anzahl von Anwendungsfällen beinhaltet, die wichtig sind.
Die Anwendungsfälle werden dann der Reihe nach abgearbeitet.
Ziel dieser Vorgehensweise ist es, dass man von Anfang an einen Einstiegspunkt im System hat, um es präsentieren zu können.
Als Abschluss der aktuelle Stand unseres Anwendungsfalldiagramms:
Freitag, 11. September 2009
Module
Der nächste Schritt besteht darin, die vorhandenen Anwendungsfälle zu studieren und in Module einzuordnen.
Diese Module werden sich später in Namespaces wiederfinden.
Um den positiven Effekt der Module zu erkennen, machen wir einen Zeitsprung in die Zukunft:
Diese Module werden sich später in Namespaces wiederfinden.
Um den positiven Effekt der Module zu erkennen, machen wir einen Zeitsprung in die Zukunft:
- Ohne Module könnte man später ein objektorientiertes Design entwickeln, bei der es eine Klasse Spielfeld gibt.
Dieses Spielfeld bekäme eine Methode, um sich selbst auf der Festplatte zu Speichern und zu Laden.
Führte man dann eine Analyse auf Single Responsibility Principle durch, würde man das Design verwerfen.
Man hätte festgestellt, dass die eigentliche Aufgabe der Klasse Spielfeld darin besteht, die Daten rund ums Spielfeld zu halten. Diese auf der Festplatte zu Speichern und zu Laden ist eine zweite Aufgabe. - Mit der vorher stattgefundenen Einteilung in Module, gäbe es ein Modul Speicherbank und beim ersten Design wird der Klasse Spielfeld erst gar nicht das Laden und Speichern zugeordnet, da sie sich in einem anderen Modul befindet.
- controller (Model-View-Controller Entwurfsmuster)
- game (Zugüberwachung, Regelüberwachung)
- player (menschlich, Computerspieler, entfernte Spieler (Multiplayer))
- randomizer (Würfel, Landverteilung)
- model (Model-View-Controller Entwurfsmuster)
- gameground (Spielfeld)
- storage (Kokus, Einheiten im Vorrat)
- units (Einheiten, Armeen, Sondereinheiten)
- network (Senden und Empfangen von Netzwerkdaten)
- storage (Speichern und Laden auf Festplatte)
- test (für Testprogrammcode)
- view (Model-View-Controller Entwurfsmuster)
Donnerstag, 10. September 2009
Anwendungsfalldiagramm
Anwendungsfalldiagramme (Use Case Diagram) beschreiben, was das System ist.
Sie sind einen Grad detaillierter, als die Feature-Liste es ist.
Die Vorarbeit mit der Feature-Liste hat dazu beigetragen, Anwendungsfälle zu identifizieren, an die man zunächst nicht gedacht hätte.
Die Anwendungsfalldiagramme bieten einen sehr guten, visuellen Überblick über das zu entwickelnde Programm.
Die Ordnung im Chaos nimmt langsam Struktur an.
Sie sind einen Grad detaillierter, als die Feature-Liste es ist.
Die Vorarbeit mit der Feature-Liste hat dazu beigetragen, Anwendungsfälle zu identifizieren, an die man zunächst nicht gedacht hätte.
Die Anwendungsfalldiagramme bieten einen sehr guten, visuellen Überblick über das zu entwickelnde Programm.
Die Ordnung im Chaos nimmt langsam Struktur an.
Mittwoch, 9. September 2009
Feature-Liste
Der erste Schritt ist das Erstellen der Feature-Liste.
Als Feature verstehen wir ganz allgemein die Kernfunktionalitäten des Programms.
Die Feature-Liste hilft, Ordnung ins Chaos zu bringen.
Das Chaos ist bei Projektstart immer groß, da noch so viel zu erledigen ist und man nicht weiß, wo man anfangen soll.
Die Feature Liste und die in den folgenden Tagen eingesetzten Techniken helfen, genau dies heraus zu finden: Wo sollte man am sinnvollsten anfangen?
Unsere Feature-Liste sieht wie folgt aus:
- Spielregeln des Brettspiels werden eingehalten
- Spielanleitung ist ansehbar
- Figuren des Brettspiels (Kampfkraft, Kosten, Nah-/Fernkämpfer, temporäre Einheit, Ronin-Limit, Daimyo (als letzte Einheit entfernbar))
- Spielfelder sind landkartentypisch, nicht quadratisch
- Computerspieler mit verschiedenen Strategien
- Mehrspielermodus über Internet
- Einzelspielermodus
- Spielfeld ist lad- und auswählbar
- Computerspieler sind lad- und auswählbar
- Chat während Mehrspielermodus
- Mehrsprachigkeit
Abonnieren
Posts (Atom)
