Programmiermethodik SS2006 © 2005 Albert Zündorf, University of Kassel 1 3. Analyse Gliederung: 1. Einführung 2. Anforderungsdefinition 3. Analyse

Programmiermethodik SS2006 © 2005 Albert Zündorf, University of Kassel 1

3. Analyse

Gliederung:

1. Einführung

2. Anforderungsdefinition

3. Analyse <== UML Objektdiagramme / UML Kollaborationsdiagramme UML Activity Diagramme Story Boards Grundstruktur des Analysedokuments Objektspiel UML Sequenzdiagramme

4. Design

5. Zusammenfassung


Story Driven Modeling

Anforderungsdefinition: textuelle Szenarien

Analyse: objektorientierte Szenario-Beschreibungen (plus Klassendiagramme) Objektspiel zur Validierung der Objekt-Szenarien

Design: Methodische Ableitung von automatischen Tests Methodische Ableitung von Methoden-Implementierungen (plus Klassendiagramme) Zetteltests Automatische Code-Generierung Systematisches Testen

Noch nicht erfasst: Grafical User Interface Wartung


Grundstruktur des Projekthandbuchs

Titelseite

1. Auftraggeber

2. AuftragnehmerVersionsbezeichnung / -historie

3. Zielbestimmung1. Produkteinsatz (Relevante Geschäftsprozesse)2. Glossar

4. Analyse (Produktfunktionen) <==

5. Design (Produktdaten)

6. Validierung

7. Nichtfunktionale Anforderungen1. Produktleistungen2. Qualitätsanforderungen

8. Projektplan1. Aufwandsschätzung2. Zeitplan


Projekthandbuch Beispiel

"Titelseite"

Dokumentartbezeichnung

Projektname

Auftraggeber

Auftragnehmer

Versionsgeschichte:mit jeweils Versionsnummer Datum Autor Prüfer

Projekthandbuch Ludo Online1. Autraggeber:

Albert Zündorf , Universität Kassel34121 KasselTel.: 0333 77 888, Fax: 0333 77 889Email: [email protected]

2. Auftragnehmer: Kasseler Webanwendungen GMBH, Annelise Beispiel, Mat.Nr. 012345,E-mail: [email protected] Muster, Mat.Nr. 023455, E-mail: [email protected]

Version: Datum: Autor: Prüfdatum Prüfer

0.1 04.11.05 A. Beispiel

0.2 06.11.05 M. Muster

1.0 11.11.05 A. Beispiel 14.11.05 A. Zündorf



3. Zielbestimmung

so eine Art Einleitung

Hauptaufgabe

evtl. Prinzipskizze

Kann man meist von der Aufgabenstellung / von der Auftragsanfrage abschreiben

Fax.: .....E-Mail: …..

3. ZielbestimmungLudo ist ein zeitlos populäres Spiel. Als ersten Baustein eines werbefinanzierten Webportals für klassische Brettspiele soll daher in diesem Projekt eine online Version von Ludo erstellt werden.



3.1. Produkteinsatz(Geschäftsprozessmodell)

Darstellung von Arbeitsvorgängen in einer Firma.

Einzelne Schritte / Teilabläufe sollen durch das Projekt automatisiert werden

Kontext des Projekts

Workflowsprachen wie EPKs

….

3.1. ProdukteinsatzDas online Ludo soll eine Vielzahl von Besuchern auf unser Webportal locken. Dort soll man an Einzelspielen oder Turnieren teilnehmen können. Das Benutzerinterface soll dem normalen Brettspiel möglichst intuitiv nachempfunden sein. . . .

.....



3.2 Glossar

Definition wichtiger Begriffe

sehr schwieriger Schritt

später Klassendiagramm

=> siehe Ontologie

entfällt in unser Projektarbeit

…. 3. Zielbestimmung….. 3.1 Produkteinsatz…..3.2 GlossarSpielbrett:

Das Spielbrett zeigt die einzelnen Spielfelder, die Heimatfelder der Spieler und die Zielfelder an. Er gibt die Wege für die Spielsteine vor und er gibt die aktuellen Positionen aller Spielsteine wider.

Spieler:Es können bis zu vier Spieler teilnehmen. Jedem Spieler sind über seine Farbe seine Heimatfelder, seine Spielsteine und seine Zielfelder zugeordnet.

SpielStein:Jeder Spieler hat vier Spielsteine seiner Farbe. Die Spielsteine werden gemäß der gewürfelten Augenzahlen weiterbewegt.

….

.....



4. Analyse (Produktfunktionen)

Auflistung und Erklärung der Hauptfunktionen des zu erstellenden Programms

Package Diagramme zur hierarchischen Organisation

Use-Case Diagramme für "einfache„ Packages

strukturierte Erläuterung der Use-Cases

Gegebenenfalls GUI-Screen-Shots

....4. Analyse (Produktfunktionen)Die Produktfunktionen sind gemäß folgendem

Packagediagramm gegliedert:

.....



Usecase Diagramme

Usecase <==> Produktfunktion

Actor <==> "Benutzer"

System <==> "Programm"

....4.1 Package LudoDas Package Ludo fasst die zentralen

Funktionen des Spiels Ludo zusammen:

.....



Usecase Beschreibungen

einfache Texte(zu ungenau)

Formulare(erster Schritt)

UML Scenariodiagramme(zweiter Schritt)(meist erst in der Analyse)

…..4.1.1 Usecase move

(Autor: A. Muster)Scenario: simpleStart Situation:

Tom spielt Ludo gegen Albert. Tom hat eine 3 gewürfelt.

Initial:Tom wählt seinen ersten Spielstein s1 auf Feld f3.

Step 1: Der Spielstein sieht beim Würfel, dass drei Schritte zu machen sind.

Step 2:Der Spielstein macht einen Schritt. Zwei bleiben.

Step 3: Der Spielstein macht den zweiten Schritt.

Step 4:Der Spielstein macht den letzten Schritt

Result Situation: Der Spielstein steht jetzt auf Feld f6.

.....


Analyse:

Ausarbeitung der textuellen Usecase Szenarios durch Folge von Objektdiagrammen Story Boards

Ein Objektdiagramm pro Szenario-Schritt


Methodische Erstellung von Objektdiagrammen: Hauptwörter unterstreichen

=> Kandidaten für Objekte Verbformen => Nachrichten Eigenschaften => Attribute

(... Tom spielt blaue Steine …) Links:

Besitzanzeigende Fürworter(mein, ihr, ...)

Präpositionen:(auf, unter, neben, in, ...)

Nachrichtenwege ...

Problem der Homonyme und Synonyme => Ontologie

Das ist ein kreativer Vorgang

…..4.1.1 Usecase move

(Autor: A. Muster)Scenario: simpleStart Situation:

Tom spielt Ludo gegen Albert. Tom hat eine 3 gewürfelt.


Methodische Erstellung von Objektdiagrammen: Hauptwörter unterstreichen

=> Kandidaten für Objekte Verbformen => Nachrichten Eigenschaften => Attribute

(... Tom spielt blaue Steine …) Links:

Besitzanzeigende Fürworter(mein, ihr, ...)

Präpositionen:(auf, unter, neben, in, ...)

Nachrichtenwege ...

Problem der Homonyme und Synonyme => Ontologie

Das ist ein kreativer Vorgang

Scenario: simple…Initial:

Tom wählt seinen ersten Spielstein s1 auf Feld f3.

1: _ _ _ _ _ _ _ _


Modellierung von Beispielverhalten

Step 1: Der Spielstein sieht beim Würfel, dass drei Schritte zu machen sind.

tom

theDie

s1

v == 3

1: steps := 3

die

Collaborations-Nachrichten




tom

theDie

s1

f3 f4 :Field

v == 3

stones

atat at

next

die

«destroy» «create»

1: moveOneStep()

<<create>> und <<destroy>> Marker

:= Attributzuweisungen

bekannte Objekte ohne Klassennamenneue Objekte mit Klassenname(Änderung des Ausschnitts)


2: steps := 2



Step 3: Der Spielstein macht den zweiten Schritt.

tom

theDie

s1

f3

v == 3

stones

atat at

next

die


1: moveOneStep()





2: steps := 1

f5 :Fieldnext

f4



Step 4:Der Spielstein macht den letzten Schritt

tom

theDie

s1

v == 3

stones

atat at

die


1: moveOneStep()





2: steps := 0

f6 :Fieldnext

f5



Result Situation: Der Spielstein steht jetzt auf Feld f6.

tom

theDie

s1

v == 3

stones

at

die





f6next

f5


"Syntax" von Objektdiagrammen:

id1 :Class linkname

«Actor»id3 : Controller

attr1 : int == 10attr2 == value[state]

Klasse des Objekts

id2

:Class

Objektbezeichner

Objekt

Waisenobjekt

anonymes Objekst

Stereotyp / "Objektklass if ikation"(Stereotyp kann auch graphisch dargestellt werden)

id3 : Controller

attr1 : int == 10attr == value[state]

Attributwerte

Zustand

benannter Link

unbenannter Link

id1 :Classset1 :Class

Multiobjekt(Menge, Gruppe von Objekten)


Semantik von Objektdiagrammen

Objektdiagramme zeigen Ausschnitt der Objektwelt zu bestimmtem Zeitpunkt

Momentaufnahme / Schnappschuss zur Laufzeit eines System (Teil des dynamischen Modells)

Konsistenzbedingungen: Objektbezeichner müssen eindeutig sein


Erweiterungen für Story Driven Modeling

p1 :Player

color == "none"color := "blue"

f1 :Field

s1:Stone

f2 :Field

«create»atat

«destroy»

s3 :Stone«create»s2 :Stone

«destroy»

Attributzuweisungen p1.setCo lor ("blue") /* c.doorPos = "blue" */

Linkerzeugung s1.se tAt (f2)

ObjektErzeugung s3 = new Stone()

Linklöschung s1.setAt (null)

Objektlöschung s2 .removeYou()



5. Design (Produktdaten):

Beschreibung der wichtigsten Datenstrukturen

jetzt nicht mehr textuell

Klassendiagramm plus Erläuterung aller Klassen pro Klasse Erläuterung

jedes Attributs Erläuterung aller

Assoziationen. pro Klasse Erläuterung

jeder Methode

Siehe Vorlesung am Dienstag

…..5. Design (Produktdaten)


The FAMous Fujaba Abstract Machine (Teil 1)

in den Objekten werden Kommandos / Nachrichten von vergesslichen „Object Guys“ abgearbeitet

Object Guys schlafen normaler weise

beim Aufwachen wird die Umgebung wird vom „Nebel des Vergessens“ verschleiert

Object Guys sehen nicht was die anderen tun

Jeder Object Guy hat eigenen „Namensraums“

Object Guy hat „Handlungsanweisungen“ für jedes mögliche Komando

Immer ein Object Guy pro Nachricht


tom

theDie

s1

f3 f4 :Field

v == 3

stones

atat at

next

die


1: moveOneStep()

2: steps := 2


The FAMous Fujaba Abstract Machine (Teil 1)

Object Guy kann:

Kanten und Attribute lesen um Nebel zu vertreiben

lokale Namen für Nachbarn vergeben

temporäre Werte notieren

Berechnungen durchführen

Nachrichten verschicken (wartet (untätig) auf Antwort)

Antworten zurückschicken(und wieder einschlafen)

Attribute schreiben

Kanten löschen / erzeugen

Objekte löschen / erzeugen


tom

theDie

s1

f3 f4 :Field

v == 3

stones

atat at

next

die


1: moveOneStep()

2: steps := 2


Objektspiel:

Teilnehmer übernehmen die Rolle einzelner Objekte (Object Guys)

Links durch Arm auf Schulter

Augen verbinden

Moderator schickt initialen Aufruf an ein „Objekt“

aktives „Objekt“ führt Object Guy Schritte aus

Protokollant schreibt die Schritte an der Tafel mit

Beispiel:Tom hat 6 gewürfelt und stellt Spielstein s3 vom Heimat- auf das Startfeld.


Online Übung:

1. Bob hat einen Spielstein auf dem Feld und drei im Heimatfeld. Er ist dran und hat gerade eine 6 gewürfelt.

2. Bob hat soeben eine seiner Spielfiguren aus dem Heimatfeld auf das Startfeld heraus gesetzt und darf nun noch einmal würfeln.



Documents

Programmiermethodik SS2006 © 2005 Albert Zündorf, University of Kassel 1 3. Analyse Gliederung: 1. Einführung 2. Anforderungsdefinition 3. Analyse