2 Use Case Realization Design

Software Engineering Übung, LVNr:
Übungsleiter: Sabri Pllana
Designmodell v.1.0
Projekttitel: GlassyWindowShopping
Projekthomepage: http://code.google.com/a/eclipselabs.org/p/glossywindowshopping
Gruppenmitglieder:
MatNr:
0908049
1047034
0906803
0553288
Nachname:
Stallinger
Spataro
Domentean
Kretsu
Vorname:
Magdalena
Nico
Daniel
Marinel
e-mail:
[email protected]
[email protected]
[email protected]
[email protected]
Erstellen sie ein Designmodell gemäß Unified Process das zumindest folgende
Aspekte umfasst:

Klassendesign

Use-Case-Realization-Design

Architekturbeschreibungen
1
1 Klassendesign
1.1 Klassen
GlossyWindowShopping.java
Dies ist das zentrale Servlet das alle Anfragen annimmt und an die richtigen
JSP’s weiterleitet.
Artikel.java
In dieser Klasse wird folgendes gespeichert:
private String Name;
private int Aid;
private float Preis;
private String deadline;
private int Verkaeufer;
private String Kategorie;
public Gebote[] gebote;
private int Voting;
public boolean abgelaufen = false;
Den Wert der Variablen können mit der dazugehörigen getter-Methode
abgerufen werden.
Zusätzlich gibt es noch die Methoden:
public void doBit(Integer uid, Float bit) Um ein Gebot zu machen
private void initme(int aid) Die wird im Konstruktor aufgerufen wenn
eine aid mitliefert wird. Sie ist zuständig für das Suchen und Laden des
Artikels, mit all seinen Variablen.
Artikelliste.java
Hier gibt es nur 1 Methode und zwar:
public
Artikel[] suche (String search, int kat)
Diese Methode liefert einen Array von Artikel zurück. Diese kann
entweder gefiltert werden durch ein Suchwort oder eine Kategorie oder
keines, dann werden alle Artikel zurückgegeben.
Gebote.java
In der Gebote Klasse werden folgende Werte gespeichert:
private
private
private
private
private
int Gid;
float Preis;
int Uhrzeit;
Person Kaeufer;
int Art;
Zugreifen kann man über die Getter/Setter-Methoden.
Kategorie.java
In dieser Klasse befinden sich folgende Variablen:
private int kid;
private String Name;
Zugriff über die Getter/Setter-Methoden
MySQLConnection.java
Regelt den Zugriff auf die Datenbank.
Person.java
In der Person.java werden folgende Variablen gespeichert.
private String Name;
private String Passwort;
private int Pid;
2
private String Typ;
private double VotingVerkaeufer;
private double VotingKaeufer;
Der Zugriff wird wieder mittels Getter/Setter-Methoden gehandhabt.
Zusätzlich gibt es folgende Methoden:
public
public
public
public
Artikel[]
Artikel[]
Artikel[]
Artikel[]
verkaufteArtikel ()
angeboteneArtikel ()
beboteneArtikel ()
gekaufteArtikel ()
Diese Methoden geben wie die Funktion schon erklärt, die Artikel zurück, die
verkauft, angeboten, usw, worden sind.
1.2 Designentscheidung
Aufgabe war es, die Funktionalität von der Ausgabe zu trennen. Eine Realisierung in
Form von JSP-Seiten, welche mit Java-Objekten im Hintergrund arbeiten, erschien
uns sinnvoll, da hier die HTML-Ausgabe fast vollständig von der Funktionalität
getrennt werden konnte. Um die Struktur so einfach wie möglich zu halten
entschieden wir uns dafür, nur EIN Servlet einzusetzen, welches die Requests je
nach Bedarf umleitet, bzw. selbst kleinere funktionale Aufgaben übernimmt.
So nimmt die Klasse GlossyWindowShopping.java jeden Request entgegen und
entscheidet, ob es sich etwa um ein Datenupdate oder einen Login handelt (wird
direkt in der Klasse verarbeitet) oder ob der Request an eine der JSP-Seiten
weitergeleitet werden soll, weil nur Ausgabefunktionen genutzt werden. Die
Klassen Artikel.java, Kategorie,java, Person.java, Gebote.java liefern und halten die
in den JSPs verwendeten Objekte. Die Datenspeicherung übernimmt eine MySQLDatenbank, welche über die Klasse MySQLConnection.java angesprochen wird.
2 Use Case Realization Design
Analyse ist die Phase zwischen Use Case Modellierung (wo Funktionalität des
Systems festgelegt wird) und Design (Code). Als Hauptaufgaben dieses Punkt sind
Verfeinerung und Ergänzung von Anforderungen sowie Identifizierung von
Analyseklassen und Erstellung eines Analysemodells. Wir können sagen dass es
eine Brücke die das was System können muss, zudem wie das System konkret
gemacht wurde überführt.
Artikel suchen
Use Case
Der folgende Use Case stellt eine Verfeinerung/Spezifizierung des Use Case „Artikel
suchen“ dar. Diese Beispiel zeigt klar wer darf ein Artikel im System suchen und wie
sind die Artikel verteilt und wie können die aufgerufen werden.
3
Analysis Diagramm
Sequenzdiagramm
Im folgenden Sequenzdiagramm ist „Artikel suchen“ exemplarisch dargestellt.
4
5
Artikel Kaufen
Use Case
Analysis Diagramm
6
Artikel Verwalten
Use Case
In der Artikelverwaltung können alle relevanten Benutzeraktionen durchgeführt
werden. Hierzu zählen Artikeldaten ändern, ein Artikel lösen oder Artikel anlegen.
Analysis Diagramm
7
Sequenzdiagramm
Im folgenden Sequenzdiagramm ist der der Artikel Verwaltung exemplarisch dargestellt.
8
Artikel anlegen
Analysis Diagramm
Artikel Bewerten
Die Artikelbewertung wird vom Benutzer durchgeführt. Hierzu muss der Benutzer
registriert und angemeldet sein, um Bewertung durchzuführen. Zusätzlich zu der
Bewertung der Artikel hat der Benutzer die Möglichkeit die Bewertungen anderer
Benutzer zu sehen.
Analysis Diagramm
9
3 Übersichtsklassendiagramm
10
4 Architekturbeschreibung
Unser Komponentendiagramm zeigt zwei Seiten: Server und Client.
Serverseitig finden wir das Datastorage, was in unserer Realisierung eine MySQLDatenbank des ZID (Klasse MySQLConnection.java) ist. Mit dieser werden Daten
über die Komponenten Userverwaltung (Klasse Person.java, JSP PersonDetail.jsp
PersonNeu.jsp PersonChange.jsp PersonenDurchsuchen.jsp), Artikelverwaltung
(Klassen Artikel.java, Kategorie.java, Artikelliste.java, JSP ArtikelDetail.jsp
ArtikelDurchsuchen.jsp ArtikelNeu.jsp) und Gebotsverwaltung (Klasse Gebote.java)
ausgetauscht.
Ausgegeben werden die Daten über das Webinterface. Geplant war eine
Realisierung auf Port 80, aber die Servlet-Engine auf Almighty zwang uns einen
anderen Port zu benutzen.
Clientseitig nutzen wir das Session-Management des Browsers um die Verbindung
zum Webinterface zu halten.
Deployment-Modell:
In diesem Modell sind die Verteilung der von uns verwendeten Komponenten
sichtbar werden. Clients greifen mittels PC, Laptops oder andere Gerät und
beliebigen Webbrowsern auf diesen Server zu wobei verschiedene Artefakte erstellt
werden, die sowohl Userdaten als auch die vorhandenen Objekte beinhalten. Wie
11
uns die Abbildung zeigt, das physische Gerät Webserver benötigt als
Softwarekomponente Tomcat und Server benötigt Datastorage idealerweise in der
aktuellsten Version.
12