programmiermethodik ss2006 © 2005 albert zündorf, university of kassel 1 use case driven software...

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

Use Case Driven Software Development

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/Methoden)

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.

theDie

s1

v == 3

stones

atat

next

diealbert

nextf4

nextf3 f4 f4

tom


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: _ _ _ _ _ _ _ _tom


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



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

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


Storyboard / Scenario wird JUnit Test

Feste Zuordnung Usecase – realisierende Methode

Aus Szenarien automatische Tests ableiten



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


Methodenimplementierung

Skizzierung der wichtigsten Methoden

mit textueller Erläuterung

…..5.1 Klasse Spieler5.1.1 Methode Spielerwechsel



6. Validierung:

Organisation der QS

Anzahl Tests

Coverage?

Protokoll der Testläufe

Z.B. JUnit Screen Dump

…

…..6. Valdierung

…6.n Testergebnisse



7. Nichtfunktionale Anforderungen:

nicht vernachlässigbar

leicht mehrere Größenordnungen bei den Kosten

…

…..7. Nichtfunktionale Anforderungen

…7.1 ProduktleistungenDas System kann gleichzeitig bis 20

Millionen Spiele online bearbeiten. Die Antwortzeit beträgt unter 0,1 Sekunden.

7.2 QualitätsanforderungenDas System ist 365 Tage im Jahr 24

Stunden am Tag verfügbar. Maximale Downtime ist 5 Minuten pro Jahr.



8. Projektplan:

Arbeitsschritte Verantwortlicher Eingangsprodukte Ausgangsprodukte geplanter Start geplantes Ende Aufwand

Planverfolgung tatsächlicher Start, Ende,

Aufwand tatsächlicher

Verantwortlicher

…..8. Projektplan Aus der Analyse ergibt sich folgender

Projektplan:


1. Nichtfunktionale Anforderungen

1. Produktleistungen

2. Qualitätsanforderungen

2. Projektplan

1. Aufwandsschätzung

2. Zeitplan

…..7. Nichtfunktionale Anforderungen

…7.1 Produktleistungen

programmiermethodik ss2006 © 2005 albert zündorf, university of kassel 1 use case driven software...

Documents