Paul Hackenberger
Version vom:

Protokoll vom 22.12.2000

Projektdokumentation | Projektmanagement | Protokoll vom 22.12.2000


Zurück Hauptseite

  1. Organisatorisches
  2. Präsentation des GUI-Prototypen
  3. Operationen und Klassendiagramm
  4. Weitere Planung
  5. Anwesenheit

Organisatorisches

Kommendes Seminar
Sitzungsleiter: Steven König
Protollant: Manuel Scholz

Präsentation des GUI-Prototypen

Liviu stellte den GUI-Prototypen vor:
  • 3-Schichten Architektur (Datenbank (EJB), Applikation, Web-Appl. (Servlet))
  • Datenbankzugriff und Erzeugung der Tabellen über EJBs

Schwächen des Entwurfs:
  • Keine klare Schichtentrennung zwischen Appl. und Web-Applikationsschicht, da bereits in der Web-Applikationsschicht HTML Code zum Hinweis auf das entsprechende Servlet vorhanden ist.
    Besser wäre es, wenn nur JAVA Objekte als Datencontainer in die Web-Applikationsschicht übergeben werden, zur klareren Trennung von Daten und Darstellung der Daten. Erst in der Web-Appl.schicht macht es Sinn diese Daten in ein Format, wie z.b. XML, umzuwandeln, da ansonsten die Daten erst wieder von JAVA interpretiert werden müssten.
  • Die Benutzung von AccessBeans, die die Benutzung der EJBs erleichtern macht das Programm abhängig von VA; sie sind jedoch nicht unbendingt notwendig.
  • Performanceproblem tritt bereits bei dem Zugriff eines einzelnen Benutzers und dem stark reduzierten Datenbestand auf
  • Auftretende mögliche Transaktionskonflikte wurden nicht berücksichtigt.
    Z.b. Ticketkontigent einfügen betrifft mehrere Objekte, so dass es während dieser Zeit zu Unstimmigkeiten mit den Beziehungen in dem Klassendiagramm kommen kann.

Operationen und Klassendiagramm

Probleme:
  • Operationen beziehen sich streng auf das Klassendiagramm
  • Session wurde nicht vorgesehen.
    Es gibt entweder die Alternative das Kaufobject dafür zu benutzen und beim Anmelden eins mit dem Kaufzeitpunkt null zu erzeugen, oder man muss ein neues Objekt Session zum Klassendiagramm hinzufügen.
    Auch besteht das Problem der nicht expliziten Abmeldung eines Benutzers; man muss also einen Timeout vorsehen.
  • Kaufbestätigung: Man stelle sich vor man bekommt für 5000 Tickets für jedes verkaufte Ticket eine Bestätigungsemail.
    Es wird also notwendig sein mehrere Kaufbestätigungen in einer email zu bestätigen; man könnte z.B. ein Attribut in das Objekt Kauf einfügen.
  • Es gibt eine Kaufhistorie aber keine Veranstaltungshistorie; muss aktiv/passiv Attribut muss hinzugefügt werden mit einem Endzeitpunkt zum Löschen aus dem System.
  • Kauf rückgängig machen schwierig (Absicherung, Provision).
    Soll dies modelliert werden, oder dem Sysadmin überlassen werden?

Weitere Planung

Die Spezifikation soll zum nächsten Termin abgeschlossen werden!
  • Liviu und Alexander untersuchen das Performanceproblem des GUI-Prototypen
  • Die Spezifikationsgruppe verteilt Aufgaben zur Systemspezifikation an alle anderen

Anwesenheit

Studenten: Liviu, Manuel, Alexander, Tina, Alphonse, Steven, Jan, Michael, Sascha, Paul
Student. Mitarbeiter: Thorsten, Gerald
Studenten: Liviu, Manuel, Alexander, Martina, Alphonse, Steven, Jan, Michael, Sascha, Paul
Wiss. Mitarbeiter: Gerald
Professoren: Schweppe, Löhr

Zurück Top Hauptseite