HWR-Chat: Pflichtenheft
Warning: preg_match(): Compilation failed: group name must start with a non-digit at offset 8 in /www/htdocs/w0102873/mediawiki/includes/MagicWord.php on line 739
Aus It2010-g1
Chge (Diskussion | Beiträge) (→Gekapseltes Nachrichtenmodell) |
Admin (Diskussion | Beiträge) (→Siehe auch) |
||
Zeile 16: | Zeile 16: | ||
==Glossar== | ==Glossar== | ||
− | |||
− | |||
*'''Abstraktion:''' Abstraktion bezeichnet meist den induktiven Denkprozess des Weglassens von Einzelheiten und des Überführens auf etwas Allgemeineres oder Einfacheres. | *'''Abstraktion:''' Abstraktion bezeichnet meist den induktiven Denkprozess des Weglassens von Einzelheiten und des Überführens auf etwas Allgemeineres oder Einfacheres. | ||
Zeile 51: | Zeile 49: | ||
*'''Konsistenz:''' In der Informatik sind Daten konsistent, wenn Widerspruchsfreiheit innerhalb einer Datenbank gewährleistet ist. | *'''Konsistenz:''' In der Informatik sind Daten konsistent, wenn Widerspruchsfreiheit innerhalb einer Datenbank gewährleistet ist. | ||
− | *'''Konsole:''' Die Konsole eines Betriebssystems dient zur | + | *'''Konsole:''' Die Konsole eines Betriebssystems dient zur direkten Befehlseingabe durch Text an das System. Übliche Konsolen sind die "CMD" von Windows und die "shell" für alle Unix-Systeme, wie OS, Linux, BSD u.s.w. |
*'''Logdatei:''' Als Logdatei wird ein automatisch geführtes Protokoll bestimmter Aktionen bezeichnet. Im Falle des Chat Programmes ist das Protokoll der ausgetauschten Nachrichten gemeint. | *'''Logdatei:''' Als Logdatei wird ein automatisch geführtes Protokoll bestimmter Aktionen bezeichnet. Im Falle des Chat Programmes ist das Protokoll der ausgetauschten Nachrichten gemeint. | ||
Zeile 59: | Zeile 57: | ||
*'''Objekt:''' Ein Objekt bezeichnet in der objektorientierten Programmierung (OOP) ein Exemplar eines bestimmten Datentyps oder einer Klasse. | *'''Objekt:''' Ein Objekt bezeichnet in der objektorientierten Programmierung (OOP) ein Exemplar eines bestimmten Datentyps oder einer Klasse. | ||
− | *'''Orgware:''' Als Orgware bezeichnet man die für die | + | *'''Orgware:''' Als Orgware bezeichnet man die für die Organisation und Pflege eines Systems benötigten Komponenten, wie z.B. Administratoren. |
*'''Parameter:''' Parameter sind Variablen, über die ein Computerprogramm oder Unterprogramm, für einen Aufruf gültig, auf bestimmte Werte "eingestellt" werden kann. | *'''Parameter:''' Parameter sind Variablen, über die ein Computerprogramm oder Unterprogramm, für einen Aufruf gültig, auf bestimmte Werte "eingestellt" werden kann. | ||
Zeile 67: | Zeile 65: | ||
*'''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. | *'''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. |
*'''Profilseite:''' Als Profilseite bezeichnet man eine Seite, auf der einem angemeldeten Nutzer persönliche Informationen zur Verfügung gestellt werden. | *'''Profilseite:''' Als Profilseite bezeichnet man eine Seite, auf der einem angemeldeten Nutzer persönliche Informationen zur Verfügung gestellt werden. | ||
Zeile 299: | Zeile 297: | ||
===Datenbank=== | ===Datenbank=== | ||
− | *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. | + | *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. | *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. | ||
*Für die Gruppeneinteilung muss eine Tabelle "Gruppe" erstellt werden, die den Namen und eine ID als Primär-Schlüssel enthält.<br>Es soll eine Relation "ist in Gruppe" existieren, bei der eine User-ID und eine Gruppen-ID gespeichert werden. Beide zusammen ergeben den Primärschlüssel. | *Für die Gruppeneinteilung muss eine Tabelle "Gruppe" erstellt werden, die den Namen und eine ID als Primär-Schlüssel enthält.<br>Es soll eine Relation "ist in Gruppe" existieren, bei der eine User-ID und eine Gruppen-ID gespeichert werden. Beide zusammen ergeben den Primärschlüssel. | ||
Zeile 310: | Zeile 308: | ||
===Gekapseltes Nachrichtenmodell=== | ===Gekapseltes Nachrichtenmodell=== | ||
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> | 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 | + | Das bedeutet, dass neben Textnachrichten auch Kontaktanfragen, Gruppenerstellungen, Gruppeneinladungen und Adressänderungen Nachrichten sind.<br> |
Eine Beschreibung des Sachverhaltes stellt folgendes Klassendiagramm dar: <br> | Eine Beschreibung des Sachverhaltes stellt folgendes Klassendiagramm dar: <br> | ||
[[Datei:110909-Message Model.png]] | [[Datei:110909-Message Model.png]] | ||
− | Die im Diagramm dargestellten | + | Jede Nachricht hat zwei Attribute vom Typ AAdress, diese können Benutzer oder Gruppen sein. Dabei dient ein Attribut zur Kennzeichnung des Senders, das andere für den Empfänger.<br> |
+ | Die im Diagramm dargestellten AMessage-Typen können bei Bedarf um weitere ergänzt werden. | ||
===Versenden einer Nachricht=== | ===Versenden einer Nachricht=== | ||
Zeile 333: | Zeile 332: | ||
*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 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> | + | *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. | ||
===Config-Manager=== | ===Config-Manager=== | ||
Zeile 468: | Zeile 468: | ||
===Server=== | ===Server=== | ||
Der Server wird an die HWR-Berlin geliefert und von dieser in ihrem Rechenzentrum betrieben. Der Server stellt mit Hilfe der angebundenen Datenbank Informationen für die Clients zur Verfügung und steuert die Kommunikation zwischen ihnen. | Der Server wird an die HWR-Berlin geliefert und von dieser in ihrem Rechenzentrum betrieben. Der Server stellt mit Hilfe der angebundenen Datenbank Informationen für die Clients zur Verfügung und steuert die Kommunikation zwischen ihnen. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |