Geschafft!

Hinweis

Fehler

Session expiration Your session is going to expireClick here to extend

Budget:

Kleines Projekt <800

Geposted am

08.01.13 20:36

Kunde

Yas***

Die Angebotsphase ist beendet

Schreiben Sie ein ähnliches Projekt aus und erhalten Sie Angebote von Freelancern. Unverbindlich. Kostenlos. Schnell.

Jetzt ähnliches Projekt einstellen

Beschreibung:

Jede Gruppe hat die Aufgabe, ein verteiltes System eines Gruppenkalenders zu realisieren. Der Gruppenkalender soll Teams bei der Koordination ihrer Termine unterstützen. Hierbei müssen dem System die Begriffe Kalender, Person, Kalendereintrag, Termin, Alarm, Wiederholung sowie Kategorie be-kannt sein. Personen, Kalender, Kalendereinträge wie Termine und deren eventuellen Wiederholungen sollen in dem Zielsystem jederzeit angelegt, editiert und ge-löscht werden können. Für jedes Element kann eine Reihe von Attributen festgelegt werden. Dies sind mindestens für Kalender: Bezeichnung, der Besit-zer, die Zugriffsberechtigten und die Einträge; für Person: Nachname, Vorname, Raum, Telefon, Email-Adresse; für Kalendereintrag: Start, Ende (beides mit Tag und Uhrzeit), Titel, Ort, Beschrei-bung, Erinnerung, Kategorie, erstellt von; für Ter-min: Teilnehmer, Folgetermin; für Alarm: der Ter-min, für den dieser Alarm ausgelöst werden soll; für Wiederholung: Vorgängertermin; für Kategorie: Name. Ein Termin ist ein spezieller Kalenderein-trag. Alarme und Wiederholungen sind spezielle Termine. Zur Organisation von Terminen müssen diese in dem System in geeigneter Weise repräsentiert wer-den und für Berechtigte abrufbar sein. Daher muss auch ein entsprechender Login realisiert werden. Wie zu Beginn dieses Abschnitts erwähnt, soll es sich bei dem Zielsystem um ein verteiltes System handeln, auf das von mehreren Benutzern simultan zugriffen werden kann. Im Zuge dessen soll eine dreischichtige Architektur1 realisiert werden (vgl. Abbildung 1). Die unterste Schicht wird die Daten-bankschicht sein. Diese Schicht sorgt für die so ge-nannte Persistenz2 der mit dem System gehandhab-ten Daten. Hier soll mit Hilfe von mySQL eine rela-tionale Datenbank entworfen und implementiert werden, die sämtliche Daten des Systems aufneh-men kann. Die oberste Schicht wird die Präsentationsschicht sein. Sie wird durch zwei getrennte Clients mit gra-phischer Benutzungsschnittstelle (engl.: Graphical User Interface, GUI) realisiert. Der erste Client dient der Pflege des gesamten Datenbestands. Der zweite Client ist ein einfacher „Report-Generator“, mit dessen Hilfe die durch den ersten Client ge-pflegten Daten sehr einfach zur Anzeige gebracht werden können. Die Clients werden nachfolgend als Editor (Client 1) und als Report-Generator (Cli-ent 2) bezeichnet. Es ist darauf zu achten, dass die Clients eine klare Aufteilung von Funktionsbereichen besitzen. Orien-tieren Sie sich hierzu an bekannten Programmen wie z.B. dem MS-Explorer. Zur Navigation in einer größeren Datenmenge (→ Editor) bietet sich z.B. die Verwendung einer baum- oder listenartigen Darstellung an. Zum Editieren von Objekten sollte für jede Klasse (z.B. Kalender, Termin, Alarm, Wiederholung) eine spezifische Maske existieren, mit deren Hilfe die Attribute der jeweiligen Objekte modifiziert werden können. Die Maske wird in Abhängigkeit des selek-tierten Objekttyps zur Anzeige gebracht. Die Zu-ordnung von Elementen untereinander ist durch ge-eignete Auswahllisten zu realisieren. Das Herstellen von Beziehungen über die bloße Eingabe von Iden-tifikatoren, wie sie z.B. in Form von Primärschlüs-seln relationaler Datenbanken bekannt sind, ist hier nicht ausreichend. Die Reports können in textueller oder in Listenform ausgegeben werden. Es ist nicht erforderlich, mit Hilfe der einzelnen Einträge eines Reports eine weitere Navigation in der Datenbasis zu ermögli-chen. Ein Report ist also eine einmalige, statische Ausgabe. Als Reports soll die Ausgabe von Kalenderblättern (Tages-, Wochen- und Monatsansicht) bzgl. eines oder mehrerer Kalender sowie bzgl. Personen reali-siert werden. Die mittlere Schicht nimmt die Applikationslogik (auch Anwendungslogik oder Business-Logik ge-nannt) auf. Sie enthält die Algorithmen, Regeln und Strukturen, die notwendig sind, um die Elemente (Termine, Wiederholungen, etc.) und Funktionen (Eintragen, Löschen, Teilnehmer verwalten etc.) ei-ner Anwendung beschreiben zu können. Damit erfolgt eine Trennung von den anderen Funktionen des Systems, die sich z.B. mit der äußeren Darstel-lung oder der internen Abspeicherung der Daten be-fassen. Für eine Applikationslogik lassen sich somit mehrere Präsentationslogiken und mehrere Spei-cherlogiken definieren. Die mittlere Schicht stellt den sog. Applikationsser-ver dar. Er soll der Präsentationsschicht mindestens folgende Dienste anbieten: 1) Anlegen, Editieren und Löschen von Personen, Kategorien, Kalendern sowie deren Einträgen. 2) Verknüpfen von Kalendereinträgen mit Perso-nen, Kalendern und Kategorien bzw. Modifi-zieren und Aufheben von solchen Verknüpfun-gen. 3) Abfrage von Kalenderblättern (z.B.: „Welche Termine bestehen in der nächsten Woche?“) 4) Abfrage von Kalenderblättern bzgl. selektier-barer Kalender sowie bzgl. Personen (z.B.: „Welche privaten Termine muss Frau Müller in KW 32 wahrnehmen?“) 1) + 2) werden von dem Editor, 3) + 4) durch den Report-Generator genutzt. Weitere Funktionen der Applikationslogik können bei Bedarf hinzugefügt werden. Es ist in dem gesamten System auf die Einhaltung der referentiellen Integrität zu achten. Die oben genannte Funktionalität erfordert, dass sich die Applikationslogik in ständigem Kontakt mit der Datenbank befindet, um die nötigen Daten aus der Datenbank auslesen bzw. neue Daten in der Datenbank ablegen zu können. Die Datenbank-schicht wird demzufolge mit dem Datenbank-Server sowie seiner Anbindung an den Applikati-onsserver (Mapper-Klassen) realisiert, der den Zu-griff auf die abgespeicherten Daten als Dienst zur Verfügung stellt. Als Datenbank-Server ist der Rechner mars.iuk.hdm-stuttgart.de zu verwenden. Die Zugangsdaten haben Sie im Rah-men vorausgegangener Vorlesungen erhalten. Der Applikationsserver muss bei der Präsentation auf einem separaten Rechner laufen. Die Clients sind auf einem weiteren Rechner vorzuführen. Die Teilnehmer haben dafür Sorge zu tragen, dass die Präsentation vorab in dem ihnen genannten Raum lauffähig ist. Hierzu bietet sich ein Test an. Der Raum wird den Teilnehmern rechtzeitig vorher bekannt gegeben. Termine für Tests sind rechtzeitig zu vereinbaren. Die Aufteilung in drei Schichten bietet einige wich-tige Vorteile gegenüber z.B. zweischichtigen An-sätzen. Zum einen wird durch die Konzentration sämtlicher Applikationslogik auf die mittlere Schicht eine Entkopplung der Präsentationsschicht von der Datenbank erreicht. Zum anderen können die Präsentations-Clients verändert werden3, ohne die Applikationslogik modifizieren zu müssen. Darüber hinaus ist es so möglich, auf derselben Applikationslogik unterschiedliche Clients aufsetzen zu können (z.B. Editor und Report-Generator). Dies könnten einerseits Clients bzgl. unterschiedli-cher Medien (Web-basiert oder dedizierte Applika-tionen) oder bzgl. unterschiedlicher Benutzerrollen (z.B. für einfaches Reporting oder die Pflege von Elementen) sein. Aus diesem Grund ist unbedingt darauf zu achten, dass die Clients keinerlei Appli-kationslogik enthalten. Diese ist ausschließlich im Applikationsserver zu finden! Im Folgenden sollen noch einige weitere, schicht-spezifische Anforderungen erläutert werden. Die Präsentationsschicht soll mit Hilfe von „norma-len“ Java-Applikationen – also nicht mit Applets – realisiert werden. Insbesondere soll das Modul zur Gestaltung graphischer Benutzungsschnittstellen namens Swing zur Anwendung kommen. Hierbei dürfen keine sog. GUI-Builder verwendet werden! Ein Teil der Datenbankschicht soll relationale Strukturen (Datenbanktabellen, Tupel, usw.) in Ob-jekte und vice versa transformieren. Die Applikationsschicht soll Algorithmen realisie-ren, mit deren Hilfe überhaupt erst Kalendereinträ-ge in dem System beschrieben werden können. Zudem soll die Applikationsschicht mit der Präsen-tationsschicht mittels der Remote Methode Invoca-tion (RMI) kommunizieren. Die Kommunikation mit dem Datenbankmanagementsystem erfolgt mit-tels der Java Database Connectivity (JDBC). Die Datenbankschicht soll, wie bereits oben er-wähnt, mit Hilfe des Datenbank-Management-Systems mySQL realisiert werden. Hierzu sind ge-eignete Entity-Relationship-Modelle zu erstellen und in einer Datenbank abzubilden.