Projekttitel: Bookme.at Projekthomepage:

Transkript

1 Software Engineering Labor-Übung, LVNr:050052/2 Übungsleiter: Martin Köhler Dokument: Anforderungsanalyse und Use Case Modell I v.2.0 Projekttitel: Bookme.at Projekthomepage: Gruppenmitglieder: MatNr: Nachname: Vorname: Cachro Artur artur.cachro@gmail.com Dinulovic Dominik dom.dinulovic@gmail.com Kovacs Gabriel insictul@gmail.com Datum:

2 1 Anforderungsanalyse 1.1 Funktionale Anforderungen Die Projektidee, eine Versteigerungsplattform, wurde vom Lehrveranstaltungsleiter vorgegeben. Das Design und die funktionalen Anforderungen wurden für das Projekt offenen gehalten und wir durften unsere kreative Seite zeigen. Die Idee für eine Bücherplattform wurde von einem der Teammitglieder vorgeschlagen, da er für eine andere Übungseinheit ein Buch gebraucht hat, es aber nur teure Exemplare zur Verfügung gab. Dadurch kamen wir auf die Idee, eine Plattform anzubieten, auf der Personen Bücher ersteigern können und dadurch zu möglichen Schnäppchen kommen können. Die Funktion mit dem Bewertungssystem haben wir als besonders wichtig eingestuft, da jede ähnliche Plattform diese Funktion den Benutzern zur Verfügung stellt, um seriöse Verkäufer aber auch Artikel in den Vordergrund zu stellen. Das Gleiche gilt für die Such- bzw. Filterfunktion. Diese Funktion würde den Betrieb der Homepage um einiges vereinfach, deshalb ist diese auch sehr wichtig. Um Missbrauch zu vermeiden, haben wir als Sicherheitsmaßnahme die Registrierung gewählt. Durch diese Funktion sollen Spaßbieter das Niveau der Homepage, ähnlich wie bei Ebay, nicht verschlechtern können, da jede Ersteigerung auf einen Namen zurückverfolgbar ist. Als einfachste Verwaltungsmöglichkeit haben wir Datenbanken gewählt, da diese bei fast allen wichtigen Homepages zum Einsatz kommen, da die einzelnen Werte schnell und einfach in verschiedenen Spalten gespeichert werden können. Außerdem hat ein Teil des Projektteams gute Erfahrungen mit Datenbanken in anderen Übungseinheiten sammeln können. Um eine Auktion zu beenden, wird eine Timer eingebaut der nach einer bestimmten Zeit die Auktion schließt und beendet Beschreibung der Funktionalität Mit unserem Projekt soll eine Homepage realisiert werden, die es ermöglicht Bücher zu verkaufen und zu kaufen. Um Bücher zu kaufen oder zu verkaufen muss sich der Käufer/Verkäufer zuerst einloggen. Die Bücher sind nach drei Untergruppen kategorisiert: Kochbücher,Fantasy und Science-Fiction. Die angebotenen Bücher werden samt Verkäufer in einer Datenbank festgehalten. Das Kaufen der Bücher soll nur registrieren Benutzern ermöglicht werden. Nicht registrierte Benutzer dürfen sich nur die angebotenen Bücher anschauen. Außerdem soll es möglich sein nach verschiedenen Eigenschaften, wie zum Beispiel Titel, Autor, ISBN oder Erscheinungsjahr, die Bücher zu filtern. Eine Auktion läuft nach einer bestimmten Zeit ab und der Höchstbietende bekommt dann den Artikel. Zum Schluss soll ein Bewertungssystem zur Verfügung gestellt werden, in dem die Bewertung zu den einzelnen Verkäufern eingetragen sind. 2

3 1.1.2 Bedienungsoberfläche Die Startseite: Seite zum registrieren und einloggen: 3

4 Persönliche Seite: So sieht die Seite bei einer Suchanfrage aus: 4

5 So sieht die Seite aus wenn man ein Gebot abgeben will: Das Bewertungsprofil: 5

6 1.2 Nichtfunktionale Anforderungen Um unseren Benutzern einen sicheren und übersichtlichen Zugriff zu gewähren, werden innerhalb des Projektes großen Wert auf die Benutzeroberfläche gelegt. Das heißt, die Homepage soll übersichtlich sein um Funktionalitäten leicht zu handhaben. Weiters soll sie Verständlich und Erlernbar sein. Dies soll durch Informationen über Funktionalitäten auf der Homepage für Benutzer sichtbar und zugreifbar sein. Außerdem soll ihm Rahmen der Leistung eine so kurz wie mögliche Antwortzeit z.b. von dem Datenbankserver gewährleistet werden. Natürlich hängt das auch von der Bandbreite des Internetproviders eines Benutzers ab worüber im Punkt Technische Anforderungen mehrere Informationen auffindbar sind. Unter welchem Betriebssystem die Homepage benutzt wird ist irrelevant. Die Homepage soll natürlich von verschiedenen Browsern geöffnet werden können. Weiters wird auf die Datenintegrität einen großen Wert gelegt. Alle ausgefüllten Daten sind geschützt und nur durch den jeweiligen Benutzer aufrufbar. Natürlich sind auch alle Daten eines Benutzers jederzeit Verfügbar. Für den Benutzer soll auf der Homepage eine bestimmte Konformität herrschen. Es muss innerhalb der Homepage nichts installiert werden oder in sonstiger Weise angepasst werden. Natürlich bieten wir den Benutzern ein Rund um Zugriff. Dies soll durch eine geringe Fehlertoleranz und durch fehlerfreie Ergebnisse verwirklicht werden. Das soll durch gut eingesetzte Ressourcen eingehalten werden. Im folgenden Punkt werden detaillierte Qualitätsanforderungen näher erläutert Qualitätsanforderungen Höchsten Wert legen wir bei unserem Projekt auf die Benutzerfreundlichkeit, da eine einfache aber auch schnelle Bedienung eine Homepage erfolgreicher und beliebter macht. Deshalb muss es möglich sein nach mehreren Kriterien zu suchen bzw. zu filtern, damit nicht jeder Eintrag einzeln abgesucht werden muss und die Wartezeiten nicht zu lange gehalten werden. Sollten Wartungsarbeiten anfallen, würden wir diese zu bestimmten Uhrzeiten (wahrscheinlich 03:00 05:00) erledigen um die Ausfallzeiten der Plattform zu einer Zeit zu halten, zu der vermutet wird, dass wenige Benutzer online sind. Sollten viele Beschwerden zu diesen Ausfällen kommen, müssten wir uns Gedanken über einen Backup Server machen, der zu dieser Zeit aktiv sein würde. Außerdem versuchen wir das Design möglichst einfach zu gestalten, damit der Benutzer die Übersicht nicht verliert und schnell zu seinen geforderten Ergebnissen kommt. Zu bestimmten Uhrzeiten (wahrscheinlich 18:00 22:00) erwarten wir besonders hohe Benutzerzahlen und müssen versuchen den eingehenden Traffic möglichst schnell und effektiv zu verarbeiten damit es zu keinem Ausfall der Homepage kommt. Sollte dennoch ein Ausfall auftreten wollten wir diesen mit einem Backup Server überbrücken. 6

7 1.2.2 Technische Anforderungen Entwicklungsumgebung(IDE) : Eclipse IDE for Java Developers: Juno Release Programmiersprache: Java JRE7 Server: Apache Tomcat 7 Datenbank: Mysql Web Browser: Firefox Documentation erstellen: JavaDOC Webseite erstellen: HTML 5 Projekt Hosting: Google Code Repository, almighty.cs.univie.ac.at. Architektur: JSP Model 2 Weitere Dokumentation: JavaApi7 : SWE Tutorien: Hsql: Servlets and JSP Pages Best Practices: Realisierungsanforderungen Um unsere Auktionsplattform zu Implementieren werden wir wie folgt vorgehen: Wir benutzen als Versionierungstool SVN auf Google Code und verknüpfen es mit Eclipse. Als Webspace benutzen wir almighty.cs.univie.ac.at und um unsere Webseite persistent zu halten benutzen wir als Server Apache Tomcat. Wir werden unsere Homepage in HTML schreiben. Wir werden die Seite Übersichtlich und Benutzerfreundlich gestalten. Als Datenbank für unsere Projekt werden wir Mysql benutzen. Die Architektur wird dem JSP Model 2 entsprechen: JSP für die verschiedenen Views, JavaBeans für die Business Logic und Java Servlets 3.0 für die Kommunikation. Meilensteine: 1. Projektbeschreibung: - die Projektbeschreibung, die Projektanforderungen, Aufstellen der Repository. 2. Anforderungsanalyse: - Erstellung des Use Case Diagramms, Beschreibung der Use Cases und der Funktionalität des Projektes. Nicht funktionale Anforderungen. 3.Design I: - Ermittlung der wichtigsten Use-Cases sowie analyse und Strukturierung der Use Cases. Dies beeinhaltet zu den jeweiligen Use Cases, ein Sequenzdiagramm, Klassendiagramm und Analysediagramm 4. Implementation - Implementierung der ausgearbeiteten Funktionalitäten. Umsetzung der Use Cases. 5. Design II: - Überarbeitung und Fertigstellung der wichtigsten Use Cases mit den Klassendesign sowie dem Klassendiagramm. 7

8 1.2.4 Diverses Als großen Risikopunkt sehen wir die Popularität der Seite und dass durch dieses Problem die Benutzer ausbleiben werden. Das könnte aber nicht der einzige Grund für das Ausbleiben der Benutzer sein. Durch die hohe Konkurrenzanzahl gibt es viele andere Anbieter die unserem Produkt im Weg stehen können. Es könnte aber auch das Gegenteil passieren und es gibt eine sehr hohe Benutzerzahl. Dann könnte es zu Serverüberlastungen und zu Homepageausfällen kommen. 8

9 2 Use Case Modell Innerhalb der folgenden Punkte wurden die Funktionalitäten für die Homepage in ein Use Case Diagramm modelliert. Als erstes folgt eine kurze Beschreibung über den Ablauf im Diagramm. Danach folgen das Diagramm und die jeweils detailliert aufgelisteten Use Cases. Im Use Case Diagramm ist ein Akteur vorhanden, wobei zu unterscheiden ist das ein Benutzer eingeloggt sein muss um Funktionalitäten als Verkäufer oder Käufer ausüben zu können. Ein nicht registrierter Benutzer kann sich lediglich Artikel anzeigen lassen. Zum Startbeginn des Projektes wurde überlegt, ob sich ein nicht registrierter Benutzer ebenfalls Bewertungen ansehen darf. Dies wurde jedoch umgeändert mit der Begründung, um nicht registrierte Benutzer dazu zu bringen sich zu registrieren, falls Sie das Bedürfnis haben mehrere Funktionalitäten ausüben zu können. Artikel kaufen oder erstellen können nur registrierte Benutzer. Natürlich kann sich ein Benutzer auch neu registrieren und somit als Käufer bzw. Verkäufer im System vorhanden sein. Als registrierter Benutzer hat man die Möglichkeit Artikel zu ersteigern bzw. zu kaufen. Weiters auch Artikel anzulegen, zu verkaufen oder auch zu verwalten. Außerdem ist es nur registrierten Benutzern möglich eine Bewertung zu erstellen sowie sich jeweilige Statistiken anzeigen zu lassen. Weitere detaillierte Informationen über die Use Cases und das Diagramm werden in den kommenden Punkten behandelt. 2.1 Use Case Diagramm 9

10 2.2 Use Case 1 Beschreibung Use Case: Ziel: Kategorie: Vorbedingung: Nachbedingung bei Erfolg: Nachbedingung bei Fehlschlag: Akteure: Auslösendes Ereignis: Artikel anlegen Einen Artikel mit allen Informationen anlegen Primär Der Benutzer muss registriert sein Der Artikel ist angelegt und kann verkauft werden Daten richtig ausfüllen beim Anlegen Benutzer Keines Beschreibung Basisablauf: 1. Eingabe der Daten des Benutzers 2. Daten des Benutzers werden geprüft 3. Wenn der Benutzer die Daten nicht richtig angegeben hat Folgt eine wiederholte Eingabe 4. Falls alles richtig angegeben wird kann der Artikel zum Verkauf frei gegeben werden 2.3 Use Case 2 Beschreibung Use Case: Ziel: Kategorie: Vorbedingung: Nachbedingung bei Erfolg: Nachbedingung bei Fehlschlag: Akteure: Auslösendes Ereignis: Gebot geben Für einen ausgewählten Artikel ein Gebot abgeben Primär Der Benutzer muss registriert sein Gebot und Datum werden überprüft Wiederholung der Gebotabgabe Benutzer muss registriert sein Gebotsüberprüfung Beschreibung Basisablauf: 1. Auswahl eines Artikels für den man Bieten will 2. Gebot angeben 3. Gebot wird überprüft. Falls das Gebot höher ist und das Datum nicht abgelaufen Ist wird das Gebot bestätigt 4. Falls eines der beiden Punkte in Ablauf 3 nicht erfüllt ist, muss das Szenario wiederholt werden. 10

11 2.4 Use Case 3 Beschreibung Use Case: Ziel: Kategorie: Vorbedingung: Nachbedingung bei Erfolg: Nachbedingung bei Fehlschlag: Akteure: Auslösendes Ereignis: Bewertung ansehen Bewertungen ansehen die man von anderen Benutzern erhalten hat Primär Benutzer muss registriert sein Ausgabe der Bewertungen Keine Bewertungen vorhanden Benutzer Keines Beschreibung Basisablauf: 1. Benutzer muss sich einloggen 2. Nachdem der Benutzer eingeloggt ist kann er sich seine Bewertungen anzeigen lassen 3. Wenn er kein Artikel verkauft hat, warden keine Bewertungen vorhanden sein 11