SystemEntwicklungsProjekt - Sancrist
von
Marcus Tönnis
Dokument III - Stand: 14.03.2000
|
Anforderungsprofil 1.1.1
(Requirements Analysis Document)
Inhalt
Vorbemerkung
Vorab sei angemerkt, daß in weiteren der Ausdruck 'Skript' als Synonym für alle Arten von gedruckten Materialien (Skripten, Protokolle, MuLös, ...) steht.
Des weiteren werde ich im folgenden meist die männliche Form im Falle eines Bezuges auf eine Person verwenden, weise aber ausdrücklich darauf hin, daß der Ausdruck dann in geschlechtsneutraler Art und Weise zu lesen ist.
Ziel des gesamten Projektes ist die Erstellung einer Datenbank zur Verwaltung des Skriptenbestandes der Fachschaft Math/ Phys/ Info der Technischen Universität München. Es soll aber auch Multifunktionalität gegenüber anderen Fachschaften gewahrt bleiben, damit das Programm Sancrist ggf. auch anderen Fachschaften (der TUM) zur Verfügung gestellt werden kann.
Das Programm soll alle Bedürfnisse der Skriptenverwaltung erfüllen. Es soll auch in Zukunft um neue Belange erweiterbar sein, weshalb es unter anderem in Java implementiert werden wird, was durch seine modulare Struktur sehr leicht Erweiterungen erlaubt.
Um den Benutzern mit dem fertigen System möglichst große Funktionalität zu bieten, wird während der gesamten Entwicklungszeit konsequenter Kontakt zu den Skriptenreferenten der Fachschaft gehalten. Diese können jederzeit den aktuellen Entwicklungsstand über die Internet-Homepage des Projektes abrufen.
Ziel dieses Dokumentes ist es, einen großen Teil der Analysephase der Aufgabenstellung zu dokumentieren. Das Ergebnis der Analyse wird eine formale Beschreibung des zu entwickelnden Systems mittels Aktoren und Anwendungsfallbeispielen sein. Bei Akteuren handelt es sich um Benutzer, andere Systemteile oder ähnliches. Anwendungsfallbeispiele (Use Case Models) sind Diagramme aller möglichen Anwendungen eindes Akteurs in einem bestimmten Bereich.
Weiterhin werden sich in diesem Dokument noch andere Diagramme finden, die durch Anpassung der Anwendungsfallbeispiele eine ungefähres Klassenmodell des zuküftigen Systems wiedergeben.
Zum Einstieg ins Thema wird kurz das derzeitige System beleuchtet, um manche Probleme aufzuzeigen. Im Anschluß werden die Funktionalen und besonders die Nichtfunktionalen Anforderungen beschrieben.
In diesem Abschnitt wird die derzeitige Situation der Skriptenverwaltung analysiert um Aspekte zu finden, die das neue, computerisierte, Verfahren erfüllen muß.
Das derzeitige Verfahren der Skriptenverwaltung arbeitet hauptsächlich auf Papier. Etwa ein mal pro Semester werden die Skripten gezählt, bisher im Keller gelagerte Skripten, die dem Moder zum Opfer gefallen sind, werden vernichtet und die aktuellen Zahlen werden in einer Liste aktualisiert.
Die Lagerung der Skripten ist in zwei Bereiche aufgeteilt: Ein Teil der Skripten, die, die höchstwahrscheinlich in nächster Zeit verkauft werden, liegt direkt erreichbar im Skriptenverkaufsraum. Der Rest lag bis vor einiger Zeit im Keller des Hauses Arcisstr. 19, der sehr schlecht belüftet war und befindet sich nun in einem eigenen Raum im Gebäude Gabelsberger Str. 39 im Erdgeschoß, in dem sie wenigstens nicht so leicht dem biologischen Verfall anheim fallen können.
Problematisch an dieser Situation ist, daß meistens erst auffällt, daß ein Skript nur noch im Lager vorliegt, wenn es nicht mehr im Verkaufraum vorhanden ist oder komplett ausverkauft ist, wenn im Lager auch nichts mehr verfügbar ist.
Trotz all dieser Hemmnisse werden auch Skripten verkauft. Der Verkäufer muß die Preise aller Skripten die ein Kunde wünscht mit dem Taschenrechner aufsummieren. Dies kann zeitweise bei viel Andrang zu Verwirrungen führen, falls auf einmal doch noch ein Skript zwischen die anderen rutscht.
Im weiteren muß nach jeder Verkaufstunde der Kassenstand gezählt werden, um die Einnahmen zu überprüfen. Zum Aufsummieren steht in der Fachschaft 'nur' ein Tischrechner zur Verfügung, da bei einem normalen Taschenrechner die Gefahr des Verschwindens zu groß ist.
Situationen, in denen Skripten ausverkauft sind, sollen verhindert werden, indem die Datenbank die Anzahl und die Verkaufsquote verwaltet und die Benutzer informiert, falls ein häufig gewünschtes Skript bald ausverkauft zu sein scheint.
Alle verkauften Skripten müssen somit mitprotokolliert werden. Eine Erleichterung für den Verkäufer wird sein, daß der Gesamtpreis eines Einkaufes auch von Sancrist errechnet wird.
Die Datenbank soll aus einigen packages bestehen, die miteinander kooperieren und mittles der package 'Sancrist' zum gleichnamigen Programm zusammengefasst sind. Auf die einzelnen Subsysteme wird in den folgenden Kapiteln genauer eingegangen.
Die packages des Sancrist-Projektes:
Nach derzeitiger Planung werden sich innerhalb des Verzeichnisses sancrist diese Klassen befinden. Eben genanntes Verzeichnis, die package sancrist wird weitere Pakete beinhalten, die das eigentliche System von Sancrist bilden. Hauptsächlich sind dies die Datenbank, die grafische Oberfläche und ein lernender Teil.
Innerhalb dieser Verzeichnisse werden die Klassen implementiert, die es den Skriptenverkäufern ermöglichen, mittels einer Maske für jeden Kunden einen Einkaufszettel mit Preis und gekauften Skripten zu erstellen. Die Skripten werden mittels einer laufenden Nummer gespeichert, die in gewissem Sinne dopplet kodiert ist. Einerseites kann man aus der Nummer direkt ablesen, zu welchem Fachbereich das Skript gehört und welcher Art (Skript, MuLös) es ist. Andererseits geben die letzten drei Ziffern die Nummer des Skriptes an, die nur zu diesem Skript gehört. Somit ist jedes Skript direkt nur mit dieser Nummer ansprechbar und auch anhand der Nummer teilweise einzuordnen, ohne die Datenbank zu konsultieren.
Im weiteren sollen die einzelnen Klassen Sancrists es den Administratoren des Systems ermöglichen neue Benutzer aufzunehmen und diese in bestimmte Gruppen einzuteilen. Diese Gruppen sollen verschiedene Rechte haben, z.B. sollen Verkäufer keine neuen Skripten aufnehmen können.
Die Benutzerrechte gehen meist in den Bereich der Datenbestandsverwaltung. Es gibt nicht nur Verkauf, sondern auch direkte Entfernungen aus der Datenbank, z.B. wenn, wie schon oft erwähnt, Skripten verschwunden, bzw. vermodert sind.
Schließlich und endlich soll, wenn sich ein Verkäufer abmeldet, eine Maske erscheinen, die ihm die Abrechung des Kassenstandes erleichtert. Außerdem soll systemintern die verkaufte Summe gespeichert werden.
Grundidee der Grafischen Oberfläche soll sein, daß sie leicht und gerade für den Skriptenverkäufer schnell bedienbar sein soll. Darum wird in der Problemanalyse das Hauptaugenmerk auf den 'Verkaufsbereich' gelegt. Die anderen, zur Bedienung nötigen Fenster werden auch im weiteren angesprochen.
Die grafische Oberfläche soll Verkäufern eine klar übersichtliche Oberfläche bieten, die alle für den Verkauf wichtigen Aspekte beinhaltet. Die Administratoren sollen in einem eigenen Fenster Verwaltungsarbeiten durchführen können und die Skripter und Drucker sollen einfach den Datenbestand verwalten können. Skripter sollen zusätzlich ein Fenster mit diversen Statistiken erhalten.
Nötig im Verkaufsfenster sind:
- Eine Liste der bisher eingegebenen Skripten pro Kunde.
- Ein kleines Textfenster zur Eingabe der Skriptnummer.
- Möglichkeit der Eingabe des Preises direkt. Bei alten MuLös, die nach Kilopreis verkauft werden.
- Eine Suchmöglichkeit für Skripten in der Datenbank.
- Ein Fenster der 'Verkaufshits' der letzten Zeit (Top Ten).
- Ein Fenster, in dem die Gesamtsumme der verkauften Skripten ausgegeben wird.
Administratoren benötigen:
- Ein Fenster um Benutzer zu verwalten
- Darin eine Option, den Benutzertyp einzustellen
Datenbestandsverwaltung:
- Ein Fenster soll den gesamten Bestand aller Skripten ausgeben, aber auch selektiert anzeigen können
- Es wird eine Maske zur Änderung eines Datensatzes benötigt.
Felder darin sind:
- Laufende Nummer
- Fachbereich des Skriptes
- Art des Skriptes
- Name des Skriptes
- Erscheinungsdatum des Skriptes
- aktueller Bestand
- wichtige Bestandsänderungen
- Eine ähnliche Maske ist für die Neuaufnahme eines Skriptes wichtig
Eine Löschfunktion ist nicht vorgesehen, evtl. eine Ablagefunktion, um alte Skripten in eine Archivdatenbank abzulegen.
Statistiken:
Dieses Fenster soll einige Unterpunkte haben.
- Gesamtbestand der Skripten
- Zahl der Verkauften Skripten pro Verkaufstunde, Semester, Verkäufer, ...
- Skripten, die in nächster Zeit wahrscheinlich dringend nachgedruckt werden müssen
- ...
Die Datenbank soll von Studenten benutzt werden, die nicht unbedingt im Bereich der Informatik tätig sind. Meist handelt es sich und Studenten der Bereiche Mathematik, Physik und Informatik, aber, falls die Datenbank auch in anderen Fachschaften eingesetzt werden soll, ist es wichtig, daß sie einfach zu bedienen ist und keine intensiven Computerkenntnisse erforderlich sein müssen, um sie zu bedienen.
Der Benutzer muß immer wissen, welche Rechte er hat und welche nicht.
Es wird zwei Arten der Dukumentation geben:
- Die Doku für den Benutzer
Hier soll der User mittels einer eigenen Web-Seite und eines Handbuches die Möglichkeit haben, Probleme und anderes nachzuschlagen.
- JavaDoc: Dies ist die Java-eigene Code-Dokumentation, die es Programmierern erleichtert, das System zu modifizieren. Zusätzlich soll noch ein mit TogetherJ 2.1 in UML entwickeltes Systemdiagramm das Verständnis erleichtern.
Da das System in Java implementiert wird, sollte der Computer, auf dem es läuft, über genug CPU-Leistung verfügen, um einen zügigen Aufbau der grafischen Oberfläche zu garantieren.
Damit alle Fensterteile auf dem Bildschirm sichtbar sind, sollte mindestens eine Auflösung von 800x600 Pixel verfügbar sein. Besser wäre 1024x768 oder mehr Bildpunkte.
Ein Farbbildschirm wird nicht notwendig sein, verschönert die Sache aber ungemein.
Die Leistung der Bediener-Oberfläche hängt hauptsächlich von der Hardware, dem verwendeten Betriebssystem und der Java Virtual Machine ab. Sind alle Kriterien erfüllt, dürften keine Probleme auftreten.
Die Benutzeroberfläche wird voraussichtlich die größten Anforderungen an die Hardware (inkl. der Java VM) stellen und sollte deshalb möglichst effektiv implementiert sein, da objektorientierte Vererbung sehr auf Kosten der Geschwindigkeit geht. Leider hat eine Klasse, die von Frame (java.awt) abgeleitet ist schon fünf Vorfahren.
Da das System komplett auf einem Rechner arbeitet sind keinerlei Netzwerkfähigkeiten notwendig.
Zwar ist dieser Rechner an das Internet angeschlossen, aber das Sancrist-System wird immer lokal gestartet und ggf. mittels export des Displays von einem anderen Rechner aus betrieben. Sollten hier Probleme auftreten, sollte die Ursache nicht bei Sancrist zu suchen sein.
Die Klassen des GUI-Subsystems kommunizieren mit allen anderen Subsystemen.
Zuverlässigkeit wird durch Verhinderung und Abfangen von Fehlern gewährleistet.
Klar ist, daß Zugriffe auf Betriebsmittel der Hardware immer unter der Prämisse das Ausfalls durchgeführt werden müssen, egal, ob bestimmte Betriebsmittel nicht verfügbar sind und somit bestimmte Aktionen nicht ausgeführt werden können, oder daß das System durch einen versuchten Zugriff auf eine Hardwarekomponente abstürzt.
Um ein qualitativ gutes Programm zu erstellen ist es wichtig, Qualität in der Fehlerverträglichkeit zu sichern.
Ein weiterer Vorteil, der auch qualitativ zu sehen ist, ist die Implementierung in Java, die es erlaubt das System jederzeit auf jede andere Plattform zu transferieren, fuer die eine Java Virtual Machine verfuegbar ist.
Um den Sourcecode gut lesbar zu halten, und damit es für einen javakundigen nicht allzu schwer wird, sich in die Objektstruktur einzuarbeiten, werden mittels JavaDoc und TogetherJ-Diagrammen die durchgeführten Softwarearbeiten beschrieben.
Alle angedachten Ausbauten des Systems beziehen sich nicht auf die grafische Oberfläche.
Das System Sancrist wird auf einem PC (o.ä.) im Skriptenverkaufsraum der Fachschaft Mathematik/ Physik/ Informatik arbeiten. Dort müssen keine besonderen Augenmerke auf die physische Umgebung gerichtet werden.
Einzig und allein muß beachtet werden, daß der Bildschirm gut sichtbar ist, was aber von sich aus selbstverständlich sein sollte.
Das GUI-Subsystem verwaltet keinerlei Daten. Somit muß im Prinzip nicht auf Sicherheit geachtet werden, nur darauf, daß intern benutzte Methoden nicht öffentlich zugänglich sind..
Es dürfen keine Fenster vom System geöffnet werden, die der User nicht sehen darf (vgl. Benutzergruppen).
Sind für den Betrieb weitere Hilfsmittel notwendig?
Die Installation wird einerseits von dem Programmierer vorgenommen, andererseits soll es auch Installationsskripten geben, die diese Arbeit in zukunft übernehmen.
Da die GUI verwaltet keine Daten, müssen auch keine Backups angefertigt werden.
Falls 'Wartungsarbeiten' anstehen sollten, steht der Programmierer weiterhin mit Rat und Tat zur Seite. Andernfalls wird es Dokumente geben, um sich einzuarbeiten (vgl. 3.1.3.7. Qualitätsfragen).
Eine wichtige, selbst auferlegte Beschränkung ist, daß das ganze System, also auch die GUI, nur mittels Java entwickelt wird. Alle benutzen Klassen der Gui werden Standard-Java-Klassen benutzen und keine von Drittherstellern.
Ob Java.Swing implementiert wird, wird sich im Laufe der Entwicklung zeigen. Geplant ist es nicht.
Mittels der objektorientierten Struktur von Java wird es einfach sein, die nötige Funktionalität der grafischen Oberfläche nachzubilden.
In diesem Abschnitt werden einige geplante Teile des Subsystems mittels Diagrammen (UML, erstellt mittels TogetherJ) gezeigt, die die ungefähre Struktur der GUI darstellen.
Diese entwickeln sich im Laufe der Analysephase aus den Szenarien.
Szenario 1: Verkauf
Der Skriptenverkäufer bedient ein Fenster, in dem er die Auswahl hat, die laufende Nummer eines Skriptes, einen Preis, ein Skript aus der Liste der TopTen einzugeben, oder ein Skript in der Datenbank zu suchen. Die Summe aller Skripten wird über einen ´Kassenzettel´ ausgegeben.
Eingaben der Laufenden Nummer oder Datenbankanfragen werden an die Datenbank weitergeleitet.
Die Information der aktuell bestverkauften Skripten wird vom Datenanalyse-Subsystem ermittelt.
Szenario 2: Administration und Benutzerrechte
Der oder die Sancrist-Administratoren haben die Möglichkeit über eine Eingabemaske neue Benutzer und neue Benutzergruppen anzulegen.
Alle eingegebenen Informationen werden an die Datenbank übermittelt.
Szenario 3: Datenbestandverwaltung
Über eine Eingabemaske können neue Fachbereiche angelegt werden. Darin können Typen (MuLös, Protokolle, ...) eingerichtet werden, die wiederum die Skripten enthalten.
Alle Eingaben verwaltet die Datenbank.
Szenario 4: Ende einer Sitzung
Zur leichteren Errechnung des Kassenstandes steht dem Skriptenverkäufer eine Eingabemaske für jede Schein- und Münzsorte zur Verfügung, wobei der lernende Teil des Systems dafür verantwortlich ist, den Endstand in einer Log-Datei zu sichern.
Szenario 5: Statistiken
Ein Fenster, das im Zuge der Basisentwicklung des Systems nur teilweise gefüllt wird, wird das Statistiken-Fenster sein. Hier werden Referenten die Möglichkeit haben, sich Veränderungen des Datenbestandes über einen längeren Zeitraum zu begutachten. Bzw. werden sie über Funktionen dieses Fensters informiert, falls dringend benötigte Skripten zur Neige gehen.
Szenario 1 - Verkauf:
Szenario 2 - Administration und Benutzerrechte:
Szenario 3 - Datenbestandverwaltung:
Szenario 4 - Ende einer Sitzung:
Szenario 5 - Statistiken:
Mittlere package: sancrist.gui.
In diesem Paket befinden sich alle Klassen-Dateien, die nach bisheriger Analyse notwendig für diesen Teil des Subsystems sind.
Das folgende Sequenz-Diagramm schildert das Sancrist System beim Start.
Alle hierfür notwendigen Maßnahmen übernimmt die Klasse Startup in dem Paket sancrist. Von hier aus wird in Auftrag gegeben, alle nötigen Daten zu laden, das UserLogin-Fenster anzuzeigen und, wenn alle Daten geladen sind und der User überprüft ist, das Haupt-Fenster auf den Bildschirm zu legen.
Zum laden der Daten (primär der Skriptendatenbank) erhält die Klasse Storage den Auftrag, die Daten aus der ASCII-Datei zu lesen und übergibt sie dann dem Separator, der die eingelesenen Zeilen in das Datenbankformat transferiert.
Sobald alles geladen ist, erhält der SystemStartup ein OK, wartet ggf. noch auf die Benutzerüberprüfung und reinigt dann den Bildschirm für das Hauptfenster.
Sequenz-Diagramm: System Startup
Die Datenbankfunktionen des Systems sind der grundlegende Kern des Ganzen. Auf ihm baut alles andere auf.
Prinzipiell könnte Software eines Drittanbieters eingebunden werden (beispielsweise mySQL), aber die nötigen Routinen sind nicht sehr tiefgreifend und sollen darum auch direkt in Java implementiert werden. Das vereinfacht eventuelle weitere Ausbauten von Sancrist und bietet auch einfach die Möglichkeit, alle Daten als ASCII (oder Uni-Code) abzuspeichern, so daß auch die Daten mittels eines Editors gesichtet und verändert werden können. Ggf. Wird es auch ein Web-Interface geben, das Studierenden erlaubt, Informationen über bestimmte Skripten einzuholen.
Alle Daten der Skripten, alle Statistiken, die Benutzer und für das System wichtige Daten werden in (bzw. über) die Datenbank gesichert.
Grundlegende Funktion des Datenbank-Subsystems ist die dauerhafte Speicherung aller Datensätze. Wie schon in 3.1.2. (Funktionale Anforderungen der GUI) im Sinne der Löschfunktion bemerkt, soll ggf. eine Archivdatenbank eingeführt werden.
Alle Datensätze sollen zwischen Archiv- und Regulärer DB verschiebbar sein. Somit muss jedes Skript einen eindeutigen Key haben.
Grundlegende Funktionen der Datenbank sind die Rückgabe aller Datensätze zu einem bestimmten Suchbegriff. Darin eingeschlossen sind Suchen über die laufende Nummer eines Skriptes, Titelteile uvam.
Datensatzänderungen sollen nur bestimmten Nutzergruppen möglich sein. Neuzugänge von Skripten dürfen nur Skriptenreferenten und Drucker eingeben. Ebenso Abgänge, die allerdings mit Kommentar versehen sein müssen.
Die komplette Datenbank muß über die grafische Benutzeroberfläche erreichbar sein. Ein direkter Zugriff auf Datenbankroutinen ist nicht gewünscht.
Wichtig ist eine klar verständliche Benutzerschnittstelle.
siehe 3.1.3.2. Dokumentaion (der GUI).
Die Datenbank, der eigentliche Kern des ganzen Systems benötigt ein gewisses Maß an Rechenleistung und Zugriff auf die benutzte Festplatte.
Die Anforderung an die Rechenleistung dürfte nicht allzu groß sein, da die Zahl der verwalteten Skripten definitiv im dreistelligen Zahlenbereich bleibt.
Selbiges gilt auch für den Plattenplatz. Bei angenommen insgesamt 500 Datensätzen (ein Skript) a ein Kilobyte plus der statistischen Daten mit geschätzt 50 Kilobyte, liegt der benötigte Plattenplatz bei (worst case) 550 KB.
Aufgrund des relativ geringen Datenaufkommens werden bei heutigen Rechnern keine größeren Wartezeiten bei Datenbankanfragen zu erwarten sein. Auch, falls Sancrist auf einem älteren PC (angenommen 486er mit 66MHz) läuft, dürften keine Probleme auftreten.
Für jedes in der Datenbank gespeichertes Skript gibt es eine Eingabemaske, die nur bestimmte Werte zulässt. Zum Beispiel Integer-Werte für Anzahl und Strings für die Typenbeschreibung. Somit sollten weitestgehend alle Eingabefehler verhindert werden. Wird ein falscher Wert eingegeben, muß dieses Subsystem die Möglichkeit bieten, alle eingegebenen Werte zu korrigieren. All dies geschieht in Abhängigkeit von der Gruppe der der Benutzer zugeteilt ist.
Defizite in der Geschwindigkeit können auftreten, wenn eine große Zahl von Skripten in der Datenbank verwaltet werden soll. Bis zu einer gegebenen Zahl von ca. 1000 Skripten soll die Anwendung allerdings ohne grössere Laufzeitverluste arbeiten.
Die Klassen der Datenbank kommunizieren mit allen anderen Subsystemen.
Falls das gesamte System abstürzt, darf keinerlei Datenverlust entstehen. Einzig und allein die letzten Änderungen dürfen verloren gehen. Dafür sollte das Datum der letzten Änderung vermerkt werden, so daß Datenverluste einfacher nachvollzogen werden können. Es wird ein Logbuch aller Datenveränderungen eingebunden.
Durch die Implementierung in Java sollte es möglich sein, das gesamte System auf jede andere Plattform zu portieren.
Mögliche Erweiterungen der Datenbank sind derzeit nur hypothetisch. Alle im Augenblick denkbaren und wichtigen Funktionen zur Verwaltung von Skripten werden implementiert. Ggf. können in Zukunft noch Erweiterungen zur Verwaltung des Fachschaftsarchives eingebunden werden. Anderereits kann eine Anbindung an den Fachschaftsinformationsserver 'WepDing' erfolgen, um Zahlen vorhandener Skripten Studierenden direkt zugänglich zu machen.
Der Skriptenverkaufsraum, in dem der Rechner plaziert sein wird, auf dem Sancrist agiert, ist wissentlich nicht in irgendeiner Art von Magnetfeld, o.ä bedeckt. Regulär erhältliche Hardware sollte den Anforderungen jederzeit gewachsen sein.
Alle Daten des Softwarepaketes Sancrist werden von der Datenbank verwaltet. Um die Konsistenz zwischen Sancrist und einer eventuellen Web-Einbindung via o.g. WepDing zu garantieren, werden alle Datensätze in ASCII (ggf. Uni-Code) abgespeichert. Sicherheitsaspekte wie unerlaubte Zugriffe werden über die Schreib- und Leseberechtigungen der zugrundeliegenden LINUX-Umgebung übernommen. Darum wird für die Sancrist-Benutzer auch eine eigene Benutzergruppe eingerichtet, bzw. es werden die existierenden Gruppen 'skripten' (Skriptenreferenten der Fachschaft) und 'druck' (Druckreferenten der Fachschaftsdruckerei) eingebunden.
Klarerweise muß wie o.g. genug Speicherplatz zur Verfügung stehen. Ansonsten sollten keine weiteren Resourcen für den normalen Betrieb nötig sein.
Ein Strichcodeleser soll zu einem späteren Zeitpunkt angeschafft werden.
Es ist im weiteren zu beachten, daß Plattenfehler auf der Harddisk die Konsistenz der Daten stören können. Darum sollte bei jedem eigenen Datensatz nochmals die eindeutige Schlüssel gespeichert werden, auch wenn sich dieser fortlaufend aus der vorhergehenden Nummer entwickelt.
Durch die laufende Nummer, die jedem einzelnen Skript zugeteilt wird, ist es nur möglich, bis zu eintausend verschiedene Skripten in der Datenbank zu verwalten. Erweiterungen sind möglich und nicht allzuschwer zu realisieren.
Außerdem vergleiche 3.1.4. Beschränkungen der GUI.
In diesem Abschnitt werden einige geplante Teile des Subsystems mittels Diagrammen (UML 1.2, erstellt mittels TogetherJ 2.1) gezeigt, die die ungefähre Struktur der Datenbank darstellen.
Szenario 1: Verkauf
Die Datenbank erhält von der grafischen Oberfläche eine laufende Nummer, sucht das zugehörige Skript und gibt es zurück.
Andererseits besteht die Möglichkeit, die Datenbank mit Suchbegriffen zu füttern, bzw in ihr zu suchen.
Szenario 2: Administration und Benutzerrechte
Mittels der GUI neu angelegte Benutzer und -gruppen müssen verwaltet und gespeichert werden.
Szenario 3: Datenbestandverwaltung
Alle Skripten werden in einem (Objekt-) Baum verwaltet (gewisse Ähnlichkeiten mit einem ab-Baum sind gewollt). Der Baum enthält Fachbereiche, Typen und darin Skripten.
Szenario 4: Ende einer Sitzung
Der Kassenendstand soll gespeichert werden.
Szenario 5: Statistiken
Informationen über den Bestand sollen auch in Form von Mustern (BehaviourPatterns) gespeichert werden.
Szenario 1 - Verkauf:
Szenario 2 - Administration und Benutzerrechte:
Szenario 3 - Datenbestandverwaltung:
Szenario 4 - Ende einer Sitzung:
Szenario 5 - Statistiken:
Vergleiche 3.1.5.3. Objektmodelle der GUI.
Linke package: sancrist.db.
Das hier abgebildete Sequenz-Diagramm zeigt eine einfache Datenbankanfrage, bei der der Schlüssel eines Skriptes übergeben wird.
Der Schlüssel wird analysiert, woraufhin, Fachbereich und Skript-Typ bekannt sind (die ersten beiden Ziffern des Schlüssels). Die Anfrage wird an den entsprechenden Teil der Datenbank weitergeleitet, das Skript geholt (Kopie), der Schlüssel als Ganzes verglichen und zurückgegeben.
Sequenz-Diagramm: Datenbankanfrage
Ergänzend zu dem Grundsystem der Datenbank arbeitet ein intelligentes Subsystem, das Aussagen über die Datenbestandsveränderungen treffen soll.
Der lernende Teil von Sancrist sollte unabhängig vom restlichen System laufen und die Datenbankanfragen überwachen. Am vorteilhaftesten wird eine Implementierung als eigenständiger Thread sein.
Eine wichtige Funktion wird sein, im Verkaufsfenster einen Bereich mit den derzeitigen Top Ten der verkauften Skripten zu füllen.
Zweiter Aspekt des Lernenden Teils wird sein, den Skriptenreferenten einige Statistiken zur Verfügung zu stellen:
- Geringe Restbestände müssen angegeben werden.
- Verkaufte Skripten pro Semester
Der lernende Teil des Sancrist Systems wird nur in einer Richtung mit dem Benutzer kommunizieren. Es wird Fenster oder Fensterteile geben, aus denen der Anwender aktuelle Informationen ablesen kann.
In der Anwenderdokumentation werden die Teile der Fenster ausführlich erklärt.
Mittels der javainternen Dokumentation werden die verwendeten Methoden dargelegt.
Die verwendeten Algorithmen werden keinen übermäßen Rechenaufwand benötigen. Es müssen, nach der augenblicklichen Planung, keine rechenintensiven Verhaltensmuster oder ähnliches generiert werden. Es handelt sich ausschließlich um Berechnungen, die aktuell vorliegende Zahlen benutzen.
vgl. 3.2.3.4. Leistungscharakteristika der Datenbank
Falls das System (oder der Computer) abstürzt, ist dieses Subsystem dafür verantwortlich, alle während der Sitzung durchgeführten Eingaben auszulesen und somit die Datenbank zu aktualisieren, Benutzeränderungen durchzuführen usw.
Die Klassen des Learning Subsystems kommunizieren mit allen anderen Subsystemen.
Das Learning-System wird einfache Algorithmen enthalten, die es dem Benutzer erlauben, Informationen über den gesamten Bestand an Skripten zu erlangen.
Bereitgestellte Informationen sind nur informativer Natur und sollen das ganze Erscheinungsbild der Datenbank abrunden.
Zu einem späteren Zeitpunkt, unter anderem, wenn das System eine längere Prüfung im realen Betrieb absolviert hat, soll eine Funktion eingebunden werden, die automatisch Skripten bei dem Druckreferat ordert, die in nächster Zeit drohen, auszulaufen.
vgl. 3.1.3.9. Physische Umgebung der GUI
Alle Daten, die der Lernende Teil errechnet, werden mittels der Datenbank gespeichert (-> vgl. 3.2.3.10. Sicherheitsfragen der Datenbank).
Andererseits muß darauf geachtet werden, daß nur Skriptenreferenten und Sancrist-Systemadministratoren die statistischen Informationen erhalten.
Das lernende Subsystem benötigt dauerhafte Speicherung vieler einzelner Daten. Hier muß eine geeignete Datenstruktur erstellt werden.
Vom Subsystem erstellte Verhaltensmuster müssen nach längerer Laufzeit auf Effizienz überprüft werden. Unter Umständen müssen einige Algorithmen dann ausgetauscht werden. Dies wird sich im Laufe der ersten grösseren Probeläufe zeigen.
Da die Objektorientierung, mittels der Java realisiert ist, in grossem Masse auf Kosten der Arbeitsgeschwindigkeit des Systems arbeitet, sollten Erstellung von Mustern und andere Berechnungen im Hintergrund durchgeführt werden und nur dann, wenn es die Systemlast zulässt.
Szenario 1: Verkauf
Für die Verkaufsmaske muß eine Liste der aktuell bestverkauften Skripten zur Verfügung gestellt werden. Nur anfangs muß häufiger berechnet werden, später seltener.
Szenario 4: Ende einer Sitzung
Die Berechnung des Kassenstandes könnte über Funktionen der Summe des ´Einkaufszettels´ aus dem Verkaufsfenster realisiert werden.
Szenario 5: Statistiken
Der Bereich der Statistiken liegt bisher noch offen. Nötig sind Informationen über zur Neige gehende Skripten und hervorstechende Verkaufszahlen.
Szenario 1 - Verkauf:
Szenario 4 - Ende einer Sitzung:
Szenario 5 - Statistiken:
Vergleiche 3.1.5.3. Objektmodelle der GUI.
Rechte package: sancrist.learn (später: sancrist.dm).
Das folgende Sequenz-Diagramm schildert den groben Rahmen der zur Erzeugung der Top Ten nötigen Methodenaufrufe.
Bei der Erzeugung des Verkaufsfensters wird die Klasse TopTen aufgefordert, die aktuelle Top Ten zu lieferen. Dafür werden die aktuellen Logs benötigt. In den Logs werden alle einzelnen Verkäufe gespeichert. Nachdem diese Liste übermittelt wurde, werden die entsprechenden Zahlen ermittelt. Das Ergebnis wird als Liste an das Verkaufsfenster gereicht und über die Datenbank gespeichert, damit beim nächsten Start nicht mehr alle Zahlen durchlaufen werden müssen.
Sequenz-Diagramm: Das TopTen-Teilfenster im Verkaufsfenster
Marcus Tönnis
14.03.2000