HWR-Chat: Pflichtenheft

*'''Kapselung:''' Als (Daten-)Kapselung bezeichnet man in der Programmierung das Verbergen von Daten oder Informationen vor dem Zugriff von außen. Der direkte Zugriff auf die interne Datenstruktur wird unterbunden und erfolgt stattdessen über definierte Schnittstellen.

*'''Orgware:''' Als Orgware bezeichnet man die für die Organisation und Pflege eines Systems benötigten Komponenten, wie z.B. Administratoren.

*'''Port:''' Ein Port ist der Teil einer Netzwerkadresse, der für die Zuteilung der für die Übertragung verwendeten Netzwerkprotokolle zuständig ist. Dargestellt wird ein Port mit einer Nummer von 0 bis 65535.

*'''Primärschlüssel:''' Als Primärschlüssel bezeichnet man in einer Datenbank die Spalten einer Tabelle, die für jede Zeile einen unterschiedlichen / eindeutigen Wert besitzen. Somit kann jede Zeile über eben diesen eindeutig benannt werden.

*'''Relation:''' Eine Relation ist die Beziehung zwischen zwei Objekten, und wird in Datenbanken als eigene Tabelle, oder in einem Teil der Tabelle eines der betroffenen Objekte beschrieben.

*'''Schnittstelle:''' Eine Schnittstelle (auch Interface) dient zur Kommunikation zwischen Modulen eines Systems oder zwischen dem Menschen und Modulen eines Systems. Schnittstellen müssen immer exakt definiert sein.

Der Chat ist nicht öffentlich zugänglich, sondern explizit für Studenten, Dozenten und andere Mitarbeiter der HWR-Berlin vorgesehen. Aus diesem Grund ist das Anlegen eines neuen Profils nur durch einen Administrator möglich.  

*Zunächst sollen alle User in einer Tabelle festgehalten werden.<br>Diese sollen neben einer eindeutigen ID alle im unten dargestellten ER-Diagramm aufgeführten Attribute enthalten. Die Benutzer-ID und der Nickname sind eindeutig. <br>Eine Besonderheit stellen die Profilbilder dar. Diese sollen auf dem Server abgelegt und nur die Pfade in der Datenbank gespeichert werden.

*Um eine Kontaktbeziehung darzustellen braucht man noch eine "kennt"- Tabelle. Diese soll lediglich zwei IDs der Benutzer enthalten. User kennt User. Dabei ist zu beachten, dass nur wenn die Benutzer IDs in beide Richtungen eingetragen sind, die Nutzer sich auch beide kennen. Wird nur eine einseitige Beziehung geführt handelt es sich um eine intiale Kontaktanfrage, wobei der Gegenüber (noch) nicht angenommen hat.

Dieses Zustandsdiagramm beschreibt den Vorgang des Login. Dabei sendet der Client eine Login-Anfrage an den Server, der diese entweder zurückweist oder anerkennt.<br>

Um die Daten bequem vom Client zum Server senden zu können, soll ein gekapseltes Modell verwendet werden. So können einfach AMessage Objekte versendet werden, um den Rest kann sich jede Funktion selber kümmern. Ist kein Empfänger angegeben, so ist die Nachricht für den Server. Ansonsten leitet der Server diese weiter und führt gegebenenfalls ergänzende Arbeiten aus.<br>

Das bedeutet, dass neben Textnachrichten auch Kontaktanfragen, Gruppenerstellungen, Gruppeneinladungen und Adressänderungen Nachrichten sind.<br>

*Die Anmeldung der User soll am Server erfolgen. Dabei lädt der Nutzer sein Profil sowie seine ihm bekannten Kontakte und Gruppen. Diese Daten müssen daher für den Server vorgehalten werden, damit dieser sie bei Bedarf speichern, bearbeiten oder auch löschen kann. Um auch bei einem möglichen Absturz oder beim Herunterfahren konsistente Daten zu gewährleisten, soll hierzu eine Datenbank genutzt werden.  

*Für die konkrete Implementierung bedeutet dies, dass es zwei unterschiedliche Datenmodelle gibt. Zum Einen die Datenbank selbst (und deren Schnittstelle um Daten auszulesen / zu speichern) und andererseits ein internes Datenmodell des Servers. Beim initialen Start wird die Datenbasis des Servers mit der Datenbank synchronisiert, was im konkreten Fall bedeutet, dass alle Nutzer und Gruppen geladen werden. Werden nun lesende Anfragen gestellt, wird nur die ServerDatenStruktur benutzt, die Datenbank bleibt unangetastet (Performance). Erst wenn Daten verändert werden, muss ein Abgleich der Datenbank mit dem Server erfolgen, damit die Daten konsistent bleiben.  

*Die Datenerhaltung auf dem Server erfolgt durch einen Liste von Benutzerobjekten, die wiederum Referenzen auf andere Gruppen/User Objekte besitzen. Diese Objektorientiertheit hat den Vorteil, das bei Änderung eines Users, die User die auf diesen User referenziert worden sind, unmittelbar die aktuellen Daten bereithält. Der Server muss bei Änderungen nur dafür Sorge tragen, dass alle Freunde, die diesen Nutzer kennen, diese Änderung auch mitbekommen.  

*Die einzigen Daten, die nicht mit der Datenbank synchronisert werden, sind die Statuseinträge, da diese lediglich live existieren.<br>

Wenn die Statusnachricht benutzerdefiniert implementiert wird, würde sie wiederum gespeichert werden.

Bestimmte Einstellungen müssen in Konfigurationsdateien gespeichert werden, damit bei Änderung das Programm nicht neu kompiliert werden muss. Das betrifft unter anderem die Adresse des Servers, die Adresse der Datenbank oder das ausgewählte Design des Clients. Wenn eine solche Datei noch nicht existiert, soll diese mit vorgegebenen Standardeinstellungen automatisch erstellt werden. Es soll ein System für beide Konfigurationsdateien (Server, Client) entwickelt und standardisiert werden. Die Konfigurationsdateien sollen "server.conf" und "client.conf" heißen und mit einem Texteditor veränderbar sein.

Direkt am Server solldie Eingabe verschiedener Kommandos möglich sein, um so beispielsweise einen neuen Benutzer zu registrieren.<br>

Der Server soll eine Konsole besitzen. Folgende Kommandos soll der Server verarbeiten können:

| listUsers || Listet alle User auf  

| listGroups || Listet alle Gruppen auf  

Bei Bedarf sollen ergänzend auch verschiedene Informationen auf der Server-Konsole angezeigt werden können.

*Für die Passwörter gelten besondere Sicherheitsanforderungen: Diese dürfen nur stark verschlüsselt gespeichert werden.