Pflichtenheft Projekt Rollercoaster. Projektgruppe: Gruppenname Phasenverantwortlich: Müller-Langowski 15. April 2002

Transkript

1 Pflichtenheft Projekt Rollercoaster Projektgruppe: Gruppenname Phasenverantwortlich: Müller-Langowski 15. April

2 Inhaltsverzeichnis 1 Auftragnehmer 1 2 Auftraggeber 1 3 Zielbestimmung Mußkriterien Wunschkriterien Produkteinsatz Anwendungsbereiche Zielgruppen Produktumgebung Software Hardware Produktschnittstellen Produktfunktionen UML Beschreibung Use Case /sim010/ Use Case /sim020/ Use Case /sim030/ Produktdaten 5 8 Produkt-Leistungen 5 9 Benutzungsschnittstelle 5 10 Entwicklungsumgebung 5 11 Qualitätsbestimmungen 5 Abbildungsverzeichnis 1 Text im Abbildungsverzeichnis Use Case /to simple0815/ Use Case /sim010/ Tabellenverzeichnis i

3 1 Auftragnehmer Auftragnehmer ist die Projektgruppe Gruppenname. Ansprechpartner: Phasenveranwortlicher: Hans-Siegfied von Müller-Langowski {kann muss aber nicht angegeben Roberta Blanka Gilbert Schweizer Horst Uwe Schmidt 2 Auftraggeber Auftraggeber ist das Institut für Wissenschaftliches Rechnen der Technischen Universität Braunschweig. Anschrift: Technische Universität Braunschweig Institut für Wissenschaftliches Rechnen Prof. Hermann G. Matthies, PhD Hans-Sommer-Straße Braunschweig Ansprechpartner: Dipl.-Inform. Oliver Kayser-Herold O.Kayser-Herold@tu-bs.de Tel.: Dipl.-Math. Andreas Keese A.Keese@tu-bs.de Tel.: Dipl.-Inform. Markus Krosche M.Krosche@tu-bs.de Tel.:

4 3 Zielbestimmung ScientifiComputing Abbildung 1: Dieser Text steht unter der Abbildung Hier ein Beispiel wie man eine Graphik einbindet. Dabei kann man festlegen, welcher Text im Abbildungsverzeichnis und welcher unter dem Bild erscheint. Die Grösse des Bildes wird über einen Skalierungsfaktor festgelegt. Latex positioniert die Graphik im Dokument. Man hat nur bedingt Einfluss auf die Position des Bildes. 3.1 Mußkriterien 3.2 Wunschkriterien 4 Produkteinsatz 4.1 Anwendungsbereiche 4.2 Zielgruppen 5 Produktumgebung 2

5 5.1 Software 5.2 Hardware 5.3 Produktschnittstellen 6 Produktfunktionen /F10/ Eingabe von Parametern für den Meßvorgang. /F20/ Auslesen der Totzeit und des Betriebsmodus (1D/2D) aus Konfigurationsdatei. /F30/ Berechnung der Gesamtdauer eines Zyklus. /F40/ Ansteuern des Detektors mittels Trigger-Signalen. /F50/ Abspeicherung der Produktdaten im Header der Ergebnisdatei. /F60/ Einlesen von 1-dimensionalen Meßdaten. /F70/ Konvertierung von 1-dimensionalen Meßdaten. /F80/ Abspeichern von 1-dimensionalen Meßdaten in die Ergebnisdatei 6.1 UML Beschreibung Verfasser: Roberta Blanka Hier kommen die Use Case Diagramme hin. Mit Use Cases lassen sich tiefergehende Prozesse veranschaulichen, in denen der Benutzer eine Programmkomponente ist, die mit einer anderen interagiert. Mit Benutzer ist demnach nicht nur der Mensch gemeint, der einen Knopf eines GUI drückt und damit irgendeine Aktion auslöst (s. Abb. 2), sondern auch interagierende Softwarekomponenten (s. Abb. 3). Simulation starten Benutzer Abbildung 2: Use Case /to simple0815/ Use Case Diagramme sollen bezeichnet werden, damit man sich im laufenden Text auf sie beziehen kann. Sie müssen sowohl graphisch dargestellt als auch textlich beschieben werden. Das folgende Beispiel das ganze veranschaulichen: 3

6 6.1.1 Use Case /sim010/ Die textliche Beschreibung eines Use Case sollte so aussehen (siehe Balzert): Spielstand auf Client visualisieren Server <<extends>> <<extends>> Spielstand visualisieren Client Client abmelden Abbildung 3: Use Case /sim010/ Use Case /sim010/: Spielstand zum Client zur Visualisierung schicken Akteure: Client, Server Auslösendes Ereignis: Nach jedem Taktzyklus des virtuellen Prozessors schickt der Server den Spielstand zum Client. Vorbedingungen: Der Client ist beim Server angemeldet Das Turnier läuft. Nachbedingungen: Der Client zeigt den momentanen Spielstand an Der Server ist über die erfolgte Visualisierung informiert. Fehlersituationen: Ablauf: Der Client antwortet nicht innerhalb der Toleranzzeit 1. Der Server schickt dem Client den aktuellen Spielstand. 2. Der Client visualisiert diesen (<<include>> /CLIENT120/). 3. Der Client informiert den Server über die erfolgte Visualisierung. Alternativer Ablauf: Wenn ein Fehler in der Kommunikation auftritt, so meldet der Server den Client ab (<<include>> /SERVER210/), d.h. entfernt ihn aus der Liste der visualisierenden Clients 4

7 Beziehungen zu anderen Use-Cases: <<include>> /CLIENT210/ (Darstellung des Spielstands im Client). <<include>> /SERVER210/) (Client abmelden) Use Case /sim020/ Use Case /sim030/ 7 Produktdaten, Roberta Blanka 8 Produkt-Leistungen, Roberta Blanka 9 Benutzungsschnittstelle 10 Entwicklungsumgebung 11 Qualitätsbestimmungen 5