g3t3 [Main]
Projektarbeit II - Jetzt erst recht!
Ein Vorschlag für eine Renovierung der Projektarbeit (-:
Vorschlag Use Cases
Beschränkung auf die Use-Cases der Studierenden und Versuch, die komplett umzusetzen.
Nicht mehr enthalten: Betreiber, Supporter und die Verwaltung von erledigten LVs der Studierenden.
Annahme: Alle Daten die "vernünftigerweise" eh in einem Uni-Gesamtsystem gespeichert sind, holen wir auch von dort.
Registrieren
Meldet sich mit Matrikelnr und Passwort neu am System an. Der Benutzer-Datensatz wird von Univis importiert. Er wird zur Studienplan-Auswahl weitergeleitet.
Login
Meldet sich mit Matrikelnr und Passwort am System an. Er wird zur aktuellen Kalenderansicht weitergeleitet.
Studienplan-Auswahl inkl. Aktuelles-Semester-Auswahl
Der Benutzer kann aktuell gewählte Studienpläne (mit jeweils aktuellem Semester) anzeigen lassen. Es können neue Studienpläne gesucht und hinzugefügt werden. Das aktuelle Semester der gewählten Studienpläne kann verändert werden.
LV-Auswahl
Der Benutzer kann aktuell gewählte LVen anzeigen und abwählen. Es können zusätzliche LVen gesucht werden. Filter: "Nur gewählte Studienpläne [ja/nein]" und "Volltext".
Kalender-Ansicht
Anzeige aller LVen der aktuellen Kalenderwoche.
Daten-Import
Einlesen der XMLs von Studien, Studienplan, LVs, LV_Studienplan, Termine, Lehrende und Veranstaltungsort.
Übersicht
Meiner Meinung nach sind das die Grundfunktionen, auf die wir aufbauen sollten… Ich hoffe, dass ich nichts wichtiges vergessen habe…
Use Case -> XML
Registrierung ---write---> Account.xml <----- registrierung.php
Stammdaten ändern ---write---> Account.xml <----- daten_aendern.php
Login ---read----> Account.xml <----- login.php
Stundenplan erstellen ---read----> LVA.xml, Studienplan.xml <------ FEHLT
|---write---> schedule_export.xml (vielleicht umbenennen in stundenplan.xml) <------- FEHLT
Stundenplan anzeigen ---read----> schedule_export.xml <------- FEHLT
Terminänderung abfragen ---read----> Account.xml
Terminänderung erstellen ---write---> Account.xml <------ FEHLT
|---read----> schedule_export.xml <------ FEHLT
LV-Termine eingeben ---write---> LVA.xml <------ newLva.php
Studienplan eingeben ---write---> Studienplan.xml <------ newStudienplan.php
Stefan:
univis_students_import.xml, sms_notification_export.xml und schedule_export.xml wären nicht als permanenter Datenspeicher, sondern als Daten von/für bestimmte Aktionen gedacht gewesen. (sms_notification_export.xml wär z.B. die Datei, die unser System verschickt, wenn ein SMS-Gateway beauftragt wird, alle Stundenten per SMS über Terminänderungen zu informieren.)
Lehrender (vormals Person) und Veranstaltungsort hätte ich vorgeschlagen, damit wir etwas näher an eine "Normalform" kommen. (Z.B. steht in der LVA jetzt der komplette Datensatz vom Leiter. Den könnte man auch einfach referenzieren.)
Um alle notwendigen Daten in unser System zu bekommen, würde ich einfach annehmen, dass wir alle Stammdaten (inkl. Student, Studium, Studienplan, LVA, Termine, Lehrender, Ort) von einem "Uni-System" bekommen. (XML-Import statt Maske/Formular/Validierung etc bauen.) Damit könnten wir uns auf die "Kernkompetenz" Studenplan-Erstellung beschränken. Und - wenn zeitlich möglich - noch die Terminänderungs-Benachrichtigung einbauen.
Bzgl. Benennung der XMLs würde ich vorschlagen, dass wir alles möglichst durchgängig halten.
Thomas:
Ok, dann schlage ich vor, dass wir noch einen Use Case Daten Import für die LV-Termine und die Studienpläne machen, oder?
aber die XMLs würden so bleiben, oder?
Stefan:
Yep, das klingt gut! :-)
Vorschlag Architektur
Wir könnten einen Model-View-Controller-Ansatz schaffen!
- Controller: Ein zentrales PHP-File, das alle Anfragen entgegen nimmt und verteilt.
- View: Unsere XSLT-Definitionen, dazu noch ein Menue.xslt. Der Controller bestimmt, welche View. Die View selbst holt sich (parameter-gesteuert) ihre Daten vom Model
- Model: Die Funktionen (evtl Klassen?), mit denen alle Kommandos auf die XMLs ausgeführt werden. Von CRUD auf ein XML bis Verschachtelung von mehreren Aktionen.
Was meint ihr dazu:
- / … Haupt-PHPs (Controller und "Basis-Maske")
- /xml … Daten (Xml, Xsd)
- /xsl … "Maskendefinitionen
- /model … Gemeinsame Funktionen, Klassen, PHPs zum Bearbeiten der Daten
- /css … Stylesheet
Vorschlag Daten
Fragen:
Welche Daten "importieren" wir von einem hypothetischen Gesamt-Uni-System? (Import = studum_import.php, sonst Maske+Datenverwaltung.)
Welche Daten fassen wir auf je ein XML zusammen?
Vermutlich am einfachsten, wenn wir (DB-like) pro Entität ein XML-File verwenden. (⇒ Standardisierte phps zum Lesen/Schreiben der Daten, weil keine - oder wenig - Unter-Strukturen.) Student könnte man mit "Studiert" und "Besucht" zusammenlegen!?
Name Entität = Name XML (student.xml, studium.xml, studienplan.xml, etc)
Vorschlag PHP
Für die Datenverwaltung (also jede Entität)
Name XML = Name PHP (studium.php, studienplan.php, etc). Jeweils mit einem "Command" (CRUD) als Übergabeparameter. Die Datenfelder folgen einfach als GET-Paramter. Name Datenfeld = Name Parameter. Wenn Command = read, dann wird der Parameter als Filter verwendet, sonst als "Eingabe". Nachdem das bei allen Entitäten gleich ablaufen wird, könnten wir ein "generisches" php für die gesamte Datenverwaltung (bzw. nur mit Anpassungen an den jeweiligen Datenstamm) bauen.
Für die Anzeige
Folgende Views fallen mir ein: (Ein View = ein php)
- Registrierung
- Login (Startseite)
- Kalender-Ansicht(= Hauptseite)
- Studienplanauswahl
- LV-Auswahl
- Menü zum Einbinden auf jeder Seite
Letzte Änderung: 09.12.2009, 10:23 | 709 Worte