fachgebiet software engineering Übersicht © 22.01.2014 albert zündorf, kassel university...

Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University

Projektmanagement


Design-/Architekturbeispiel:

CalenderView

Client ServerCommunication

RESTAPI

ReservationSystem

Persistency

ReservationForm

UserManagement

UserAdministration

BusinessRules


BÖSE

Dogma der 70er und 80er

Ein Baustein eine Verantwortliche

Gut definierte Schnittstellen

Bausteine parallel implementieren

Bausteine einzeln testen

(Schrittweise) Integration der Bausteine

Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel UniversityBÖSE

Design-/Architekturbeispiel: Horizontale WPs

CalenderView


RESTAPI

ReservationSystem

Persistency

ReservationForm

UserManagement

UserAdministration

BusinessRules


Iterative / Agile /XP Vorgehensweise

Eine Funktionalität eine Verantwortliche

keine zusätzlichen Testtreiber

Schnittstellendefinition bei der Entwicklung

Schnittstellenverantwortung beim Schnittstellennutzer

Funktionalitäten durchschneiden Bausteine (vertikal)

parallele Entwicklung an vielen Bausteinen Versionsverwaltung mit optimistischen Sperrkonzepten


Design-/Architekturbeispiel: Vertikale WPs

CalenderView


RESTAPI

ReservationSystem

Persistency

ReservationForm

UserManagement

UserAdministration

BusinessRules


Iterativ und testgetrieben

für nächste Anforderung anf {

bis Funktionalität ist gut abgedeckt {

entwerfe Beispielablauf ba {

GUI Pappmodell des Aufruf

GUI Pappmodell des Ergebnis

textuelle Beschreibung der Schritte

}

für wichtige Schritte im Beispielablauf

{

Beispielobjektdiagramm

}

Klassendiagramm anpassen

Architektur anpassen

Tests implementieren

Funktionalität implementieren

Coverage prüfen

}

}

Anforderungsdefinition

Analyse

Design

Implementierung

Qualitäts Sicherung

Projekt Management


Projektmeilensteine (alt)

12.11.08: Anforderungsanalyse Dokument

26.11.08: Analyse + Design Dokument

16.12.08: An-/Abmeldefrist OKA (noch 3 Tage)

17.12.08: Technische Dokumentation

14.01.09: 1. Messe

21.01.09: Anforderungsanalyse Integrationsaufgabe

28.01.09: Analyse + Design Integrationsaufgabe

04.02.09: Technische Dokumentation Integrationsaufgabe

11.02.09: 2. Messe


Projektmeilensteine (neu)

12.11.08: Anforderungsanalyse Dokument

26.11.08: Projekthandbuch Sprint 2

16.12.08: An-/Abmeldefrist OKA (noch 3 Tage)

17.12.08: Projekthandbuch Sprint 3

14.01.09: 1. Messe

21.01.09: Projekthandbuch Integrationsaufgabe Sprint 1



11.02.09: 2. Messe


Projekthandbuch

Deckblatt

Name

Autoren

Versionsbezeichner

Projekthandbuch

BeamMan

Gruppe: QuickSoft

Albert Zündorf, [email protected]örn Dreyer, [email protected]

Version: 1.0.20081028.233012


Inhalt

Kapitel nach Phasen

Inhaltsverzeichnis

1. Einleitung2. Anforderungen & Analyse3. Design & Architektur4. Implementierung & Test5. Zeitplan und Aufwände


Einleitung

Kurzer Überblick

(z.B. Aufgenabstellung)

1. Einleitung

Das Projekt BeamMan stellt eine Web basierte Anwendung zur Organisation der Beamer Ausleihe am Fachbereich 16 zur Verfügung. Fachgebiete die einen Beamer ausleihen wollen, können Beamer, die vom Studienservice und einigen anderen Fachgebieten zur Verfügung gestellt werden, für bestimmte Zeiträume reservieren. Die Ausleiher können ihr eigenes Gerät priorisiert reservieren bzw. Freigabezeiträume definieren.

Das System wird auch benutzt, um die Übergabe des Geräts bei Ausleihe und Wiedergabe so wie den einwandfreien Zustand des Geräts zu protokollieren.


Anforderungen

Use Case Diagramme

System

Anforderungen

Benutzer

2. Anforderungen & Analyse

Das Projekt ist in folgende Use Cases gegliedert:

Besitzer

bereit stellen

Sperrzeiten

Reservieren

Ausleihe

Leihender


GUI Pappmodelle

Für jeden Use Case:

Beispielszenarios mit:

GUI Pappmodell

textuelle Ablaufbeschreibung

2. 1 Reservieren

Herr Maier logt sich mit seinem Webbrowser in das BeamMan Reservierungssystem ein und erhält folgende Übersicht:

BeamMan FB 16 Uni Kassel

Mon8:00 10:00 12:00 14:00 16:00

RA Beamer X X

StudServ X X


GUI Pappmodelle



GUI Pappmodell


Herr Maier klickt auf StudServ, Montag 16:00 Uhr. Das System prüft die Verfügbarkeit und trägt die Reservierung für Herrn Maier ein.


Mon8:00 10:00 12:00 14:00 16:00

RA Beamer X X

StudServ X X Maier


GUI Pappmodelle



GUI Pappmodell



Mon8:00 10:00 12:00 14:00 16:00

RA Beamer X X Maier

StudServ X X


textuelle Abläufe

Für aktuellen Use Case:


GUI Pappmodell


mit Betreuer besprechen

bis jetzt Kundentauglich

…Ablauf: 1. Durch den Klick auf StudServ, Montag 16:00

Uhr wird ein entsprechender Reservierungs-wunsch im Webbrowser zusammengestellt.

2. Der Reservierungswunsch wird an den BeamMan Server übermittelt.

3. Der BeamMan Server greift auf die Datenbank zu und holt sich den Eintrag für den StudServ Beamer und den gewünschten Timeslot.

4. Da der Timeslot noch frei ist, wird die Reservierung für Herrn Maier eingetragen.

5. Die Änderung wird in der Datenbank gespeichert.

6. Die Bestätigung der Reservierung wird an den Webbrowser zurückgemeldet.

7. Der Webbrowser holt sich die neuen Wochendaten und zeigt sie an.


Objektdiagramme

Analyse:

Hier Datenmodellentwurf

Für zentrale Schritte:

Objektdiagramm

Ziel:

Datenorganisation muss klar werden

…

3. Der BeamMan Server greift auf die Datenbank

zu und holt sich den Eintrag für den StudServ Beamer und den gewünschten Timeslot.

beamMan

RABeamer: Beamer

StudServ: Beamer

r1: Reservierung

von: Mo 10:00bis: Mo 12:00

r2: Reservierung

von: Mo 12:00bis: Mo 14:00


Design

Klassendiagramm ableiten

…3. Design und Architektur

Folgendes Klassendiagramm fasst unseren Datenentwurf zusammen:

BeamMan

Reservierung

von: longbis: long

Beamer

name: String


Architektur

Architektur hier Standard

…Folgendes Deploymentdiagramm stellt unsere

Client Server Architektur dar.

dekanatsserver

ReservierungsDatenbank

BeamManService

PC1

WebBrowser


JUnit Tests mit GWT

siehe Anleitung Vorlesungsseite

Szenario dient als Vorlage für die Tests

zuerst kleine Teilfunktionalitäten einzeln testen (und implementieren)

dann Gesamtszenario testen (und implementieren)

Test legt Beispieldaten an

Test führt Beispieloperation des Benutzers durch

Test prüft Reaktion des Systems im Vergleich mit Szenario


Coverage Prüfung

Manuell Szenarios durchgehen funktioniert dieser Schritt? Alternative Situation denkbar?

Prüfung der Implementierung mit z.B. ECL Emma Test durchlaufen alle Code Teile? Gut. Wenn nein, Implementierung behandelt Sonderfälle? Sonderfälle in Szenarios und Tests gießen


Aufwände

Zeitplan später

Stundenzettel:

arbeit an Use Case xSzenario y

PappmodellLeute, Stunden

TextszenarienLeute, Stunden

ObjektdiagrammeLeute, Stunden

…

Inhaltsverzeichnis

1. Einleitung2. Anforderungen & Analyse3. Design & Architektur4. Implementierung & Test5. Zeitplan und Aufwände


Story Card

fachgebiet software engineering Übersicht © 22.01.2014 albert zündorf, kassel university...

Documents