Entwurf

Software-Design

Version 0.1 Stand DD.MM.YYYY Status in Bearbeitung Autor Autor: Datei > Eigenschaften

Vorwort

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung

2 Überblick 2.1 Zweck der Software-Systemkomponente IDataSave: Sendet Userdaten an die Persistencekomponente. || Darüber hinaus werden spezielle Klassen und Methode für die Mapfunktionalität implementiert. || IProfileProvider:Liest Profildaten von anderen Usern vom Server IFahrtProvider: Liest Fahrten vom Server, um dies darzustellen IGetFahrt: Liefert neue Fahrten an den Server IGetProfile: Liefert UserProfile an den Server || IDataSave: Speichert übergebene Userdaten. || IFahrtProvide: Sendet Fahrtinformationen an den Webserver. IGetProfile: Übernimmt User-Profilinformationen die vom Webserver gesendet werden. IProfileProvide: Sendet User-Profilinformationen an den Webserver. ||
 * ===Komponente=== || ===Beschreibung=== || ===Interface=== ||
 * GUI || Die GUI-Komponente stellt Klassen und Methoden für die Darstellung. || IDatenProvide: Lädt Userdaten aus der Persistencekomponente.
 * Map || Die Map-Komponente nutzt Klassen und Methoden der GUI Komponente.
 * Persistence || Die Persistencekomponente bietet Klassen und Methoden für CRUD Operationen. || IDataProvide: Bietet Userdaten
 * Webservice || Die Webservicekomponente bietet Klassen und Methoden zum verarbeiten von Webserviceaufrufen. || IGetFahrt: Übernimmt Fahrtinformationen die vom Webserver gesendet werden.

2.2 Software-Kategorien 2.2.1 GUI

2.2.3 Aktivität - Login 2.2.4 Aktivität - Teilnehmer Bewerten 2.3 Externe Schnittstellen 2.4 Leistungsmerkmale 2.5 Erfüllte Anforderungen 2.6 Variabilität 2.7 Umzusetzende Systemanwendungsfälle

Die Systemanwendungsfälle sind in zwei Pakete eingeteilt. Diese werden in den folgenden Unterkapiteln erläutert. In den Systemanwendungsfällen treten die zwei Akteure Fahrer und Mitfahrer auf, die sich systemtechnisch nicht unterscheiden: Jeder Anwender des Systems kann je nach Anwendungsfall sowohl als Fahrer oder Mitfahrer agieren. Zum besseren Verständnis wird trotzdem zwischen diesen Akteuren unterschieden, um die Rollen der Akteure differenzieren zu können.

Die folgende Use-Case-Diagramme zeigen eine Übersicht der Anwendungsfälle, die durch das IT-System abzudecken sind. Eine detailierte Beschreibung der einzelnen Anwendungsfälle erfolgt in den Unterkapiteln unter Verwendung der Use-Case-Schablone nach Alistair Cockburn.

2.7.1 Paket "Fahrt planen und durchführen"

Fahrer ist am System angemeldet. || 2. Der Fahrer gibt den Endpunkt der Fahrt ein. 3. Das System macht einen Vorschlag für den Fahrpreis. Der Fahrer gibt den Fahrpreis an. 4. Der Fahrer gibt einen Starttermin der Fahrt an (Datum und Uhrzeit). 5. Der Fahrer gibt die Anzahl der freien Plätze an. 6. Der Fahrer veröffentlicht die Fahrt. 7. Das IT-System bietet die Möglichkeit eine Rückfahrt einzugeben. || 4. Der Fahrer gibt als Starttermin "Sofort" ein. || Fahrer hat ein Userprofil Fahrer ist am System angemeldet. || 2. Fahrer aktualisiert die Anzahl der freien Plätze. 3. Fahrer startet seine Fahrt. ||
 * 2.7.1.1 Route planen
 * Name und Identifier || 2.7.1.1 Route planen ||
 * Beschreibung || Ein Fahrer plant eine Fahrt und bietet Mitfahrern die Möglichkeit sich für diese Fahrt anzumelden. ||
 * Beteiligte Akteure || Fahrer ||
 * Status || zum Review ||
 * Verwendete Anwendungsfälle || - ||
 * Auslöser || - ||
 * Vorbedingungen || Fahrer hat ein Userprofil
 * Invarianten ||  ||
 * Ergebnis || Fahrt ist angelegt und für Mitfahrer sichtbar. ||
 * Standardablauf || 1. Der Fahrer gibt den Startpunkt der Fahrt ein.
 * Alternative Ablaufschritte || 1. Der Fahrer gibt seine aktuelle GPS-Position als Startpunkt ein.
 * Hinweise || - ||
 * Änderungsgeschichte || 28.03.2011, OW Ersterstellung ||
 * 2.7.1.2 Fahrt antreten
 * Name und Identifier || 2.7.1.2 Fahrt antreten ||
 * Beschreibung || Ein ||
 * Beteiligte Akteure || Fahrer, Mitfahrer ||
 * Status || zum Review ||
 * Verwendete Anwendungsfälle ||  ||
 * Auslöser || Route wurde geplant. Starttermin ist eingetreten. ||
 * Vorbedingungen || Route ist geplant.
 * Invarianten ||  ||
 * Ergebnis || Fahrt ist aktiv und wird getrackt (siehe Route tracken). ||
 * Standardablauf || 1. Mitfahrer treffen Fahrer am vereinbarten Startpunkt zur vereinbarten Startzeit.
 * Alternative Ablaufschritte || Schritt 1 ist optional. Der UC kann auch mit Schritt 2 beginnen. ||
 * Hinweise || Ist mglw. keinen eigenen UC wert. Integration in den UC Route tracken ist zu überlegen. ||
 * Änderungsgeschichte || 28.03.2011, OW Ersterstellung. ||


 * 2.7.1.3 Mitfahrwunsch angeben

Standardablauf: Es existiert bereits eine passende Fahrt, die der Mitfahrer auswählen kann.
 * Name und Identifier || 2.7.1.3 Mitfahrwunsch angeben ||
 * Beschreibung || Ein Mitfahrer sucht eine Mitfahrt. Dabei können die folgenden Fälle unterschieden werden.

Alternative Ablaufschritte: Es gibt keine passende Fahrt. Der Mitfahrer veröffentlicht seinen Mitfahrwunsch, mit dem Ziel, dass sich ein Fahrer dazu findet.

In diesem Use Case können auch Mitfahrwünsche für bereits aktiven Fahrten (D.h. die Fahrt ist bereits angetreten) angegeben werden. Die Anzeige bzw. Auswahl von aktiven Fahrten ist abhängig von den einzugebenen Suchkriterien (Abfahrtort, Abfahrttermin) einer Fahrt. || Mitfahrer ist am System angemeldet. || 2. Das IT-System liefert den Suchkriterien entsprechende Fahrten zur Auswahl zurück. 3. Der Mitfahrer wählt eine Fahrt aus. 4. Der Mitfahrer äußert seinen Mitfahrwunsch (per Anruf über das Mobiltelefon, SMS, Email) gegenüber dem Fahrer. || 3. Der Mitfahrer veröffentlicht seinen Mitfahrwunsch mit den in den Suchkriterien angegebenen Attributen (Startpunkt, Endpunkt, Termin). 4. Der Mitfahrer gibt einen Fahrpreis an. 4. Der Mitfahrer veröffentlicht seinen Mitfahrwunsch. Der Mitfahrwunsch ist für Fahrer sichtbar. ||
 * Beteiligte Akteure || Mitfahrer. ||
 * Status || zum Review ||
 * Verwendete Anwendungsfälle || - ||
 * Auslöser || - ||
 * Vorbedingungen || Mitfahrer hat ein Userprofil.
 * Invarianten ||  ||
 * Ergebnis || Der Mitfahrer hat seinen Mitfahrwunsch veröffentlicht. Der Fahrer kann den Mitfahrwunsch akzeptieren. ||
 * Standardablauf || 1. Der Mitfahrer sucht nach einer Fahrt. Suchkriterien sind Startpunkt, Endpunkt und Uhrzeit. Die freien Plätze einer Fahrt werden dabei berücksichtigt.
 * Alternative Ablaufschritte || 2. Das IT-System liefert kein passendes Ergebnis. Der Mitfahrer kann seine Suchkriterien anpassen.
 * Hinweise || 1. Als Startpunkt können Startpunkt kann "Hier" angegeben werden. Dies ist die aktuelle GPS-Position. Als Startzeitpunkt kann "Jetzt" angegeben werden. Dies ist die aktuelle Uhrzeit. ||
 * Änderungsgeschichte || 28.03.2011, OW Ersterstellung. ||


 * 2.7.1.4 Mitfahrwunsch annehmen


 * Name und Identifier || 2.7.1.4 Mitfahrwunsch annehmen ||
 * Beschreibung || Ein Fahrer hat seine Route geplant. Ein oder mehrere Mitfahrer haben einen Mitfahrwunsch gegenüber angegeben. Der Fahrer bestätigt den Mitfahrwunsch.

Dabei ist es unerheblich, ob die Fahrt noch geplant oder bereits aktiv ist. || Fahrer hat ein Userprofil. Fahrer ist am System angemeldet. || 2. Der Fahrer kontaktiert den Mitfahrer (per Anruf über das Mobiltelefon, SMS, Email). 3. Der Fahrer bestätigt den Mitfahrwunsch. Die Anzahl freier Plätze wird aktualisiert. 4. Der Mitfahrer erhält eine Bestätigung der Mitfahrt per Email/ SMS. ||
 * Beteiligte Akteure || Fahrer, Mitfahrer ||
 * Status || zum Review ||
 * Verwendete Anwendungsfälle || - ||
 * Auslöser || Mitfahrwunsch wurde angegeben. ||
 * Vorbedingungen || Mitfahrwunsch liegt vor
 * Invarianten || - ||
 * Ergebnis || Mitfahrwunsch ist angenommen. Mitfahrer wird über die Annahme des Mitfahrwunschs informiert. ||
 * Standardablauf || 1. Dem Fahrer werden Mitfahrwünsche angezeigt.
 * Alternative Ablaufschritte || 3. Der Fahrer lehnt den Mitfahrwunsch ab. Es erfolgt keine weitere Aktion bezüglich des abgelehnten Mitfahrwunsches. Der Fahrer wählt einen weiteren Mitfahrwunsch aus und kann wiederum über den Mitfahrwunsch entscheiden. ||
 * Hinweise || Die Anzeige der Mitfahrwünsche kann Mitfahrwünsche enthalten, die entlang der aktiven Fahrt liegen oder die auf der vor Fahrtantritt geplanten Route liegen. ||
 * Änderungsgeschichte || 28.03.2011, OW Ersterstellung. ||


 * 2.7.1.5 Route tracken

Mitfahrer ist am System angemeldet. Fahrt ist angetreten. || 2. Das IT-System erfasst die neue Position und aktualisiert die Route. ||
 * Name und Identifier || 2.7.1.5 Route tracken ||
 * Beschreibung || Während einer aktiven Fahrt aktualisiert das IT-System periodisch die Position des Fahrers. ||
 * Beteiligte Akteure || Fahrer ||
 * Status || zum Review ||
 * Verwendete Anwendungsfälle ||  ||
 * Auslöser || Fahrt ist angetreten. ||
 * Vorbedingungen || Mitfahrer hat ein Userprofil.
 * Invarianten ||  ||
 * Ergebnis || Position des Fahrers hat den aktuellen Stand. Mitfahrer können einen Mitfahrwunsch angeben, dabei wird die aktualisierte Position und Uhrzeit berücksichtigt. ||
 * Standardablauf || 1. Der Fahrer ändert seine Position.
 * Alternative Ablaufschritte || - ||
 * Hinweise ||  ||
 * Änderungsgeschichte || 28.03.2011, OW Ersterstellung. ||

2.7.2 Paket Useradministration




 * 2.7.2.1 Userprofil anlegen

2. Der Anwender gibt die Pflichtfelder Vorname, Nachname, Emailadresse, Passwort, Mobiltelefonnummer ein. 3. Die optionalen Felder Telefon, PLZ, Ort, Strasse, Hausnummer, Führerschein seit, Geburtstag, Fahrzeug, Raucher, nehme Umwege in Kauf werden nicht eingetragen. 4. Der Anwender klickt auf den Button "Registrieren". || Nutzung der Facebook-Kontos? ||
 * Name und Identifier || 2.7.2.1 Userprofil anlegen ||
 * Beschreibung || Das IT-System kann nur von registrierten Anwendern benutzt werden. Die Registrierung muss einmalig vorgenommen werden. Um die Schwelle für die Anmeldung möglichst gering zu halten, werden zunächst nur die essentiellen Daten abgefragt. Das Userprofil kann zu einem späteren Zeitpunkt ergänzt werden. ||
 * Beteiligte Akteure || Fahrer (unregistriert) ||
 * Status || zum Review ||
 * Verwendete Anwendungsfälle || - ||
 * Auslöser || Anwender hat sich die App heruntergeladen und installiert. ||
 * Vorbedingungen || App ist installiert und gestartet. ||
 * Invarianten || - ||
 * Ergebnis || Das Userprofil ist angelegt. Der Anwender kann sich mit seinen Zugangsdaten am System anmelden. . ||
 * Standardablauf || 1. Anwender klickt auf dem Startbildschirm der App den Button "Registrieren".
 * Alternative Ablaufschritte ||  ||
 * Hinweise || Username ist gleich der Emailadresse.
 * Änderungsgeschichte || 30.03.2011, OW Ersterstellung. ||
 * 2.7.2.2 Userprofil verwalten

2. Fahrer ändert Angaben in seines Profils. 3. Fahrer klickt auf den Button "Speichern" ||
 * Name und Identifier || 2.7.2.2 Userprofil verwalten ||
 * Beschreibung || Der Anwender vervollständigt sein bestehendes Userprofil oder passt es an. ||
 * Beteiligte Akteure || Fahrer ||
 * Status || zum Review ||
 * Verwendete Anwendungsfälle || - ||
 * Auslöser || - ||
 * Vorbedingungen || Fahrer ist registriert und angemeldet. ||
 * Invarianten || - ||
 * Ergebnis || Fahrer hat seine Angaben aktualisiert. ||
 * Standardablauf || 1. Fahrer wechselt auf die Seite "Mein Profil"
 * Alternative Ablaufschritte || - ||
 * Hinweise || - ||
 * Änderungsgeschichte || 30.03.2011, OW Ersterstellung. ||


 * 2.7.2.3. Am System anmelden

2. Fahrer klickt auf den Button "Anmelden". 3. Zugangsdaten werden überprüft und bestätigt. 4. Fahrer ist angemeldet. ||
 * Name und Identifier || 2.7.2.3 Am System anmelden ||
 * Beschreibung || Der Fahrer meldet sich am mit seinen Zugangsdaten am System an. ||
 * Beteiligte Akteure || Fahrer (nicht angemeldet) ||
 * Status || zum Review ||
 * Verwendete Anwendungsfälle || - ||
 * Auslöser || - ||
 * Vorbedingungen || Anwendung ist gestartet, Fahrer ist registriert. ||
 * Invarianten || - ||
 * Ergebnis || Der Fahrer ist am System angemeldet und kann das System im vollen Umfang nutzen. ||
 * Standardablauf || 1. Fahrer gibt auf der Startseite seine Zugangsdaten ein (Emailadresse und Passwort).
 * Alternative Ablaufschritte || Kombination von Emailadresse/ Passwort ist nicht korrekt. Anmeldung ist nicht erfolgreich ||
 * Hinweise || - ||
 * Änderungsgeschichte || 30.03.2011, OW Ersterstellung. ||

2.7.2.4. Fahrer bewerten

Die Bewertung dient späteren Mitfahrern der als Entscheidungskriterium. || 2. Angetretene Fahrten haben einen "Bewerten"-Button. Der Mitfahrer klickt auf den "Bewerten"-Button 3. Der Mitfahrer gibt seine Bewertung ab. 4. Der Mitfahrergibt einen optionalen Freitext ein. 5. Der Mitfahrer klickt auf den Button bewerten. ||
 * Name und Identifier || 2.7.2.4 Fahrer bewerten ||
 * Beschreibung || Ein Mitfahrer kann die Fahrt eines Fahrers während oder nach einer Fahrt bewerten. Als Bewertungsskala stehen 1-5 Sterne zur Verfügung. Außerdem kann ein Freitext verfasst werden.
 * Beteiligte Akteure || Fahrer/ Mitfahrer ||
 * Status || zum Review ||
 * Verwendete Anwendungsfälle || - ||
 * Auslöser || Fahrt ist beendet ||
 * Vorbedingungen || Mitfahrer ist angemeldet, Fahrt ist aktiv oder beendet ||
 * Invarianten || - ||
 * Ergebnis || Eine Fahrt ist durch einen Mitfahrer bewertet. ||
 * Standardablauf || 1. Auf der Seite "Meine Fahrten" werden geplante und bereits durchgeführte Fahrten aufgelistet.
 * Alternative Ablaufschritte || 4. Der Mitfahrer gibt keinen Freitext ein. ||
 * Hinweise || Mitfahrer können Fahrer bewerten. Fahrer können nicht Mitfahrer bewerten. ||
 * Änderungsgeschichte || 28.03.2011, OW Ersterstellung. ||
 * 2.7.2.5 Passwort zurücksetzen


 * Name und Identifier || 2.7.2.5 Passwort zurücksetzen ||
 * Beschreibung ||  ||
 * Beteiligte Akteure ||  ||
 * Status ||  ||
 * Verwendete Anwendungsfälle || - ||
 * Auslöser ||  ||
 * Vorbedingungen ||  ||
 * Invarianten ||  ||
 * Ergebnis ||  ||
 * Standardablauf ||  ||
 * Alternative Ablaufschritte ||  ||
 * Hinweise ||  ||
 * Änderungsgeschichte || 06.04.2011, OW Ersterstellung. ||

2.8 Sonstiges 2.9 Backend-System 2.9.1 Klassenmodell der Entitäten

2.9.2 Klassenmodell der Data-Access-Objects

2.9.3 Klassenmodell der Services

2.9.4 Klassenmodell der Webservices 3 Randbedingungen 3.1 Einzusetzende Konzepte und Komponenten 3.2 Einzuhaltende Konventionen 3.3 Sonstige Randbedingungen

4 Komponentenmodell 4.1 Interne Struktur 4.2 Beschreibung der lokalen Software-Komponenten / Units 4.3 Schnittstellenbeschreibungen 4.4 Offene Punkte

5 Verhaltensmodell

6 Datenmodell

7 Implementierungsmodell

8 Entwurfsentscheidungen 8.1 Entwurfsentscheidung XY

9 Software-Komponente [n] 9.1 Überblick 9.1.1 Zweck/Verantwortung: 9.1.2 Software-Kategorie 9.1.3 Verweis auf externe Schnittstellen 9.1.4 Leistungsmerkmale: 9.1.5 Erfüllte Anforderungen 9.1.6 Variabilität: 9.1.7 Sonstiges 9.2 Komponentenmodell 9.2.1 Interne Struktur 9.2.2 Beschreibung der lokalen Sub-Komponenten / Units 9.2.3 Schnittstellenbeschreibungen 9.3 Verhaltensmodell 9.4 Datenmodell

A Anhang

Abkürzungsverzeichnis

Quellenverzeichnis