Ad-hoc Chatsystem für mobile Netze. G r u p p e 3. P f l i c h t e n h e f t

Ähnliche Dokumente
Aufgabe 3 Erstellt am: Softwaretechnik Praktikum SS06 Verantwortliche: Irina Justus

Benutzerhandbuch. AdBee : Adhoc-Chatsystem für mobile Netze. Version 1.0. Ein Projekt im Rahmen eines Software-Entwicklungs-Praktikums.

Softwareentwicklungspraktikum

PFLICHTENHEFT Softwaretechnik-Praktikum SS 2003 Gruppe: Geo01

SeVEN. Entwicklung eines sicheren Videoübertragungssystems. Softwareentwicklungspraktikum Sommersemester Pichtenheft

Pflichtenheft. 3. Produktübersicht

Pflichtenheft Patientenbett-Verwaltung

Pflichtenheft. Elektronische Studentenakte. von Vladislava Nadova und Marcus Stuber. 1. Zielbestimmung Musskriterien...2

Ad-Hoc Chatsystem für mobile Netze Barracuda

Ein Beispiel-Pflichtenheft

Pflichtenheft Inhaltsverzeichnis. 1 Zielbestimmung Musskriterien Wunschkriterien Abgrenzungskriterien...

Ad-hoc Chatsystem für mobile Netze. Softwareentwickungspraktikum Sommersemester 2007

Pflichtenheft. Software für Ansteuerung eines Moving-Heads mittels PCI-Card DMX512b

SWP09-1 Softwaretechnikpraktikum 2009 Aufgabenblatt 5 Projektleiter: Stefan Thomas Pflichtenheft Verantwortlicher: Jochen Tiepmar

Pflichtenheft. Inhaltsverzeichnis. Gruppe: swp Zielbestimmung Musskriterien Wunschkriterien Abgrenzungskriterien...

Ad-Hoc Chatsystem für mobile Netze Barracuda

Pflichtenheft Projekt Rollercoaster. Projektgruppe: Gruppenname Phasenverantwortlich: Müller-Langowski 15. April 2002

Ad-hoc Chatsystem für mobile Netze

Quelle:

Gruppe: swp12-9 (Projektleiter: Benjamin Glatz) Datum: Pflichtenheft. Web Annotation mit Fragment Ids. Gruppe: swp12-9

Pflichtenheft CluedoViewer

Softwarepraktikum - Gruppe 3. Pflichtenheft. Leipzig, 02. April 2007

Pflichtenheft. Didier Cherix. Christopher Hermann. Frank Stumpf SWP CHRISTOPHER HERMANN, DIDIER CHERIX, FRANK STUMPF

Softwareentwicklungspraktikum Sommersemester Pflichtenheft

Ad-Hoc Chatsystem für mobile Netze Barracuda

Phasenmodell. Problem stellung. Neue Anforderungen. Benutzerwünsche. Anforderungs analyse und - definition Systemmodell. Betrieb.

Ad hoc Chatsystem für mobile Netze. Softwareentwickungspraktikum Sommersemester Feinentwurf

Ad-hoc Chatsystem für mobile Netze

Pflichtenheft zum erweiterten UML-Tool

Grundlagen des Datenschutzes und der IT-Sicherheit (9) Vorlesung im Sommersemester 2005 von Bernhard C. Witt

A d - h o c C h a t s y s t e m f ü r m o b i l e N e t z e. G r u p p e 3 ( A d b e e ) T e s t d o k u m e n t a t i o n

Autoren: Ronny Fauth, Michael Freyer Dokumentation: Christian Schulze. 1 Zielbestimmung 2. 2 Produkteinsatz 2. 4 Produktfunktionen 3.

Zustandsdiagrammeditor Pflichtenheft, Version 3.0

Ad-hoc Chatsystem für mobile Netze Barracuda

Pflichtenheft: Wettervorhersagen via Webservice

Softwaretechnik-Praktikum SS 2007 Aufgabenblatt 3. Gruppe: HK-07-4 Gruppenleiter: Stanley Hillner Lastenheft. (Editor für Eclipse GMF)

Pflichtenheft. Hierarchisches Petrinetz - Komposition

Pflichtenheft. FHG1-Team. 5. Mai 2003

Kita Tauschbörse. - Pflichtenheft / Projektvertrag - Version: 1.1. F. Teichmann. F.Teichmann, R. Rößling. vorgelegt X fertig gestellt

Lastenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006)

Pflichtenheft. 1 Zielbestimmungen Musskriterien Wunschkriterien Abgrenzungskriterien... 2

Pflichtenheft zum Projekt JavaBeans

Ad-hoc Chatsystem für mobile Netze Barracuda

Pflichtenheft - Professorenkatalog

A d - h o c C h a t s y s t e m f ü r m o b i l e N e t z e. G r u p p e 3 ( A d B e e ) F e i n e n t w u r f

Pflichtenheft Projektarbeit 2008 / 2009

SOFTWARE ENGINEERING (SWE) - VORLAGEN

Pflichtenheft zum UML-Tool des Programmierpraktikums

Lastenheft Webinformationssystem V1.0

Pflichtenheft. Software Engineering I WS 2011/2012. Dr.-Ing. Ina Schaefer 1. Software Systems Engineering TU Braunschweig

Analyse und Entwurf objektorientierter Systeme

Gruppe 3 (AdBee) Grobentwurf

Pichtenheft. Kontakte zu bearbeiten und zu organisieren. Ressourcen für andere Nutzer bereit zu stellen

MathLib. Version IN 1 Tobias Laake Jörg Winkler Jan Hoffmeyer

Pflichtenheft. Thema: Datenbankbasiertes Installations- und Management System für Windows 2000 / XP.

Ad- h o c C h a t s y s t e m f ü r m o b i l e N e t z e. G r u p p e 3 ( A d B e e ) G r o b e n t w u r f

K o o p e r a t i v e S t e u e r u n g v o n M o d e l l v e r s u c h s f a h r z e u g e n

Kundenstamm öffnen. Artikelstamm öffnen 50,86 50,86 50,86 50,86 52,00 50, , ,86 52,00 52,00

CAE Grundlagen. Prof. Metzler 1

Pflichtenheft. Praktikumsgruppe 11

Softwareentwicklungspraktikum Sommersemester Pflichtenheft zum System E C A R. Auftraggeber

Softwarequalität und -test

Lastenheft Gruppe HK-03 erstellt am: Lastenheft

Dokumente eines IT-Projektes:

Modellgetriebene Entwicklung von Webanwendungen: eine erste Analyse

Pflichtenheft. Softwareprojekt Simulation / Idea Engineering

Pflichtenheft. Inhaltsverzeichnis

Softwareentwicklung in der Wissenschaft. Planet Simulator. Enno Köster. Enno Köster / 24

Pflichtenheft Programmanwendung "Syntax Tool"

4. Übung zu Software Engineering

Gruppe: swp12-9 (Projektleiter: Benjamin Glatz) Datum: Lastenheft. Web Annotation mit Fragment Ids. Gruppe: swp12-9

Softwareentwicklungspraktikum Sommersemester Pflichtenheft

Daten verschlüsselt senden

1. Übung Softwaretechnik - Planungsphase -

SEMESTERPROJEKT IM FACH SOFTWARETECHNIK VON ALEXANDER BAU ARTHUR BAUER MARKUS LANGPETER 05IN

Requirements Engineering I. Nicht-funktionale Anforderungen

Pflichtenheft Projekt Yellowstone

Qualität, Fehler un Testvorgehen

Software-Engineering Grundlagen des Software-Engineering

Pflichtenheft für die Herstellung von Software für das Unternehmen "Sohn & Sohn"

Lastenheft. Datum: Version: 1.4. Auftraggeber: BBS1 Mainz Judensand 1, Mainz Ansprechpartner: Hr. Müller, Hr. Löser, Hr.

kooperative Steuerung von Modellversuchsfahrzeugen

EIBPORT 3 VPN SSL Nutzung mit OpenVPN-Client

Pflichtenheft. Produkt: Multifunktionale Schubkarre

Pflichtenheft. KiPMan. Kursverwaltung mit integriertem Prüfungsmanagment

Beehive Management. Lastenheft für ein Diplomprojekt im Schuljahr 2015/16 Autor QS Datum Status Kommentar

Elexis - ABX Micros Connector

Version: Das Versionsfeld gibt an ob es sich um IPv4 oder um IPv6 handelt.

Pflichtenheft für das Produkt: Running Man

Pflichtenheft. Handyverträge V1.7

Benutzerhandbuch für WebMail. Februar 2016

ARCHITEKTUR KATA als Trainingsform für agile Teams

Softwarequalitätsmanagement. 24. April 2013

Inhaltsverzeichnis. Konfiguration und Zusatzmodule für eine Linux basierende VoIP-Telefonanlage Frau Annette Reinhart Fröstl

Fatih Emin Sahin. Projektbetreuerin: Prof. Dipl.-Inform. Astrid Beck

Seminar Softwareentwicklung in der Wissenschaft

Terminland TLSync. Installationsanleitung. Terminland TLSync. Installationsanleitung. Dokumentation: 3.02 Terminland: ab Datum:

Pflichtenheft 1 / 1. Gruppe: Geo05 Verantwortlicher: Martin Wannagat, Aron Schneider

SMARTentry Notification

AIK Dresden, Hans Jörg Günther. Pflichtenheft. Conway Game of Life. Pflichtenheft. Inhaltsverzeichnis. 1. Aufgabenstellung und - analyse

Transkript:

Ad-hoc Chatsystem für mobile Netze G r u p p e 3 Softwareentwicklungspraktikum Sommersemester 2007 P f l i c h t e n h e f t Auftraggeber Technische Universität Braunschweig Institut für Betriebssysteme und Rechnerverbund Prof. Dr.-Ing. Lars Wolf Mühlenpfordtstraße 23, 1. OG 38106 Braunschweig Deutschland Betreuer: Sven Lahde, Oliver Wellnitz Hiwi: Wolf-Bastian Pöttner Auftragnehmer: Gruppe 3 Name Ekrem Özmen Celal Özyalcin Thorben Schulze Danny Melching E - Mail e.oezmen@gmail.com c.oezyalcin@tu-bs.de thorben.schulze@tu-bs.de danny.melching@tu-bs.de Phasenverantwortlicher: Thorben Schulze Braunschweig, 16.04.2007 1

Versionsübersicht Version Datum Autor Status Kommentar 1.0 16.04.07 Ekrem, Celal, Danny, Thorben Erste Version des Pflichtenhefts 2

I n h a l t s v e r z e i c h n i s 1 ZIELBESTIMMUNG... 4 1.1 MUSSKRITERIEN... 4 1.2 WUNSCHKRITERIEN... 5 1.3 ABGRENZUNGSKRITERIEN... 5 2 PRODUKTEINSATZ... 6 2.1 ANWENDUNGSBEREICHE... 6 2.2 ZIELGRUPPEN... 6 2.3 BETRIEBSBEDINGUNGEN... 6 3 PRODUKTÜBERSICHT... 7 4 PRODUKTFUNKTIONEN... 8 5 PRODUKTDATEN... 10 6 PRODUKTLEISTUNGEN... 11 7 QUALITÄTSANFORDERUNGEN... 12 8 BENUTZEROBERFLÄCHE... 14 9 NICHTFUNKTIONALE ANFORDERUNGEN... 15 10 TECHNISCHE PRODUKTUMGEBUNG... 16 10.1 SOFTWARE... 16 10.2 HARDWARE... 16 10.3 ORGWARE... 16 10.4 PRODUKTSCHNITTSTELLEN... 16 11 GLOSSAR... 17 3

1 Zielbestimmung Es wird ein Chatsystem für mobile und drahtlose Netze erstellt, welches keiner Infrastruktur, wie z.b. einem zentralen Server, bedarf. Die Nachrichten zwischen einem Absender und einem oder mehreren Empfängern basiert auf einem Peer-to-Peer Netz. In diesem wird die Nachricht direkt oder über andere Knoten Hop-by-Hop vom Absender zu den richtigen Empfängern geleitet. Ist ein Empfänger nicht erreichbar oder ist er kurzeitig außerhalb des Netzbereiches, so wird die Nachricht gespeichert und später an den Empfänger übertragen. 1.1 Musskriterien Die grundlegende Fähigkeit des Chatsystem ist, dass die Benutzer Textnachrichten sowie Binärdaten miteinander austauschen können, sobald eine Verbindung zwischen zwei Teilnehmern besteht. Um dies zu ermöglichen sind folgende Kriterien notwendig: Der Austausch von Nachrichten erfolgt in Kommunikationskanälen. In jedem Kommunikationskanal befinden sich Benutzer, wobei jede gesendete Nachricht an alle Benutzer im jeweiligen Kanal geht. Ebenfalls besitzt jeder dieser Kommunikationskanäle einen Namen und eine eindeutige Identifizierung. Desweiteren sind die Kanäle öffentlich oder geschlossen, wobei jeder den Öffentlichen beitreten kann. In den Geschlossenen hingehen muss man von einem Benutzer, der sich schon in diesem Kanal befindet, eingeladen werden. Folglich muss es den Benutzern des Chatsystems möglich sein, einen Kommunikationskanal zu erstellen, in diese beitreten, sie wieder verlassen und jemand anderen in einen geschlossenen Kanal einladen zu können. Außerdem befindet sich jeder Benutzer zum Start des Programms in einem anonymen Kanal. Dieser besitzt den eindeutigen Namen Anonymous, welcher von den anderen Kanälen nicht verwendet werden darf. Die Übertragung in dem anonymen und den geschlossenen Kanälen erfolgt verschlüsselt. Letztendlich sind die Kanäle in ihrer Anzahl nicht begrenzt und die Benutzer können sich eine Liste aller existierenden Kanäle anzeigen lassen. Die Benutzer des Chatsystems besitzen ebenfalls einen Namen und müssen eindeutig identifiziert werden können. Jeder Benutzer kann sich in mehren Kommunikationskanälen befinden. Die Nachrichten, die übertragen werden, besitzen auch eine eindeutige Identifizierung. Ebenfalls müssen sie, außer in dem anonymen Kanal, einem Sender durch Authentifizierung eindeutig zugeordnet werden können. Sobald eine Nachricht verschickt wird, findet sie automatisch ihren Weg durch das Netz. Sie wird Hop-by-Hop zu den Empfängern übertragen, welche diese quittieren. Die Quittungen werden dann dem Sender innerhalb des Programms angezeigt. Falls eine Nachricht den Empfänger nicht erreicht, wird sie 4

gespeichert und später erneut gesendet, wobei dem Empfänger verspätete Nachrichten angezeigt werden sollen. Da diese Nachrichten verzögert gesendet werden und die Übertragung verbindunglos mittels UDP-Datagrammen stattfindet, muss die richtige Reihenfolge am Empfänger gewährleistet werden. Die genaue Protokollspezifikation was beim senden von Nachrichten beachtet werden muss, befindet sich detailiert im Peer-to-Peer Chat Protokoll 07 zu Internet-Drafts von Strauss. Allgemein muss das Chatprogramm interoperabel mit den Chatprogrammen der anderen Projektgruppen sein. Außerdem soll aufgrund der Mobilität der Teilnehmer eine ständige Aktualisierung der Netzstruktur erfolgen. Deswegen sollen nicht nur einzelne Benutzer mit in eine Netzstruktur aufgenommen werden können, sondern auch eine Verschmelzung von zwei oder mehr Netzstrukturen möglich sein. Dabei werden öffentliche Kanäle mit gleichen Namen zu einem Gemeinsamen zusammengeschlossen und geschlossene Kanäle müssen weiterhin getrennt behandelt werden. Zum Testen der Software gibt es eine Peerverwaltung die ein- bzw. ausgeschaltet werden kann. Im eingeschalteten Modus wird die Netzstruktur verwendet, die in der Peerverwaltungsliste angegeben ist, wohingegen im ausgeschalteten Modus die erreichbaren Rechner im drahtlosen Netz verwendet werden. Schließlich muss das Chatprogramm auf den Betriebssystemen Mac OS und Linux lauffähig sein und die graphische Oberfläche bedienerfreundlich gestaltet sein. 1.2 Wunschkriterien Um eine bessere Übersicht zu erhalten und Teilnehmer einfacher in einen geschlossenen Kanal einzuladen, kann sich jeder Benutzer eine Liste aller gerade im Netz vorhandenen Benutzer anzeigen lassen. Außerdem sollten neue Funktionen, die die Handhabung erleichtern oder erweitern, sich möglichst einfach einbinden lassen. Eine Portierung auf andere Betriebssysteme sollte auch ohne größere Änderungen erfolgen können. Ebenfalls wäre es wünschenswert, wenn die Benutzeroberfläche vom jeweiligen Benutzer in sinnvollem maß veränderbar ist. 1.3 Abgrenzungskriterien Das Programm wird nicht mit schon vorhandenen Chatsystemen Interoperabel sein, sondern nur mit den Programmen der anderen Gruppen des Projektes. Es wird auch keine Übertragung von größeren Dateien möglich sein, die Größe der übertragbaren Dateien ist begrenzt. 5

2 Produkteinsatz 2.1 Anwendungsbereiche Das Chatprogramm kann in Bereichen eingesetzt werden, in denen man möglichst schnell ständige Kommunikation benötigt. Häufig kommt dies in der Öffentlichkeit oder in Gebäuden vor, wo keine Möglichkeit besteht, eine Infrastruktur aufzubauen. Dies kann zum Beispiel bei Katastrophenszenarien sein, bei Arbeiten in der Öffentlichkeit oder an nicht bevölkerten Orten wie z.b. Nordpol oder Mond. Vor allem ist der Einsatz sinnvoll, wenn Informationen übertragen werden, die der Empfänger öfter abrufen möchte, was z.b. bei Übertragung von Sprache nicht so einfach möglich ist. 2.2 Zielgruppen Das Programm ist für jeden geeignet, der die Kommunikation von Ad-hoc Chatsystemen nutzen möchte. 2.3 Betriebsbedingungen Das Programm wird mobil und drahtlos Einsatzfähig sein. Außerdem wird keine Infrastruktur benötigt und man kann es zu jeder Zeit benutzen. 6

3 Produktübersicht Das folgende Diagramm zeigt vereinfacht Anwendungen, die in dem Produkt möglich sein werden. Abbildung1: Use-Case Diagramm 7

4 Produktfunktionen /F10/ Geschäftsprozess: Übertragen von Nachrichten Anforderung aus dem Lastenheft: Mit dem Programm sollen Benutzer in der Lage sein miteinander Daten auszutauschen. Hierbei können sowohl Textnachrichten wie auch Binärdaten ausgetauscht werden Ziel: Ein Sender verschickt eine Nachricht, sie wird durch das Netz übertragen und kommt letztendlich am richtigen Empfänger an. Kategorie: primär Vorbedingung: Ein Teilnehmer muss einen Kanal eröffnet haben und sowohl Sender als auch Empfänger müssen dem Kanal beigetreten sein. Nachbedingung Erfolg: Der Empfänger hat die Nachricht korrekt empfangen. Nachbedingung Fehlschlag: Die Nachricht konnte nicht übermittelt werden oder wurde nicht korrekt übertragen. Akteure: Teilnehmer Auslösendes Ereignis: Ein Teilnehmer möchte eine Nachricht an einen anderen Teilnehmer verschicken. Beschreibung: 1 Die Nachricht verschlüsselt, im geschlossenen Kanal, und unverschlüsselt, im offenen Kanal, verschicken. 2 Nachrichten werden außer im anonymen Kanal authentifiziert. 3 Die Nachricht kann aus Text oder Binärdaten bestehen. 4 Nachrichten werden an die richtigen Empfänger geschickt. 5 Bestätigungen für alle gesendeten Nachrichten. Erweiterung: 4a Nachrichten werden auf den schnellsten Weg durch das Netz geschickt 4b Nachrichten kommen in der richtigen Reihenfolge an Alternativen: 2a Wenn eine negative Bestätigung erhalten worden ist, wird die Nachricht gespeichert und später erneut gesendet. 2b Verspätete Nachrichten werden dem Benutzer angezeigt 8

/F20/ Peerverwaltungsliste zum aufstellen eines virtuellen Netzes mit folgenden Daten: Port, IPv4 /F30/ Teilnehmerliste für die im Netz vorhandenen Benutzer mit folgenden Daten: Benutzer ID, Name /F40/ Kanalliste für die erstellten Kanäle mit folgenden Daten: Kanal ID, Name, Kanaltyp 9

5 Produktdaten In Bezug auf die Musskriterien benötigt das Programm keine langfristig zu speichernden Daten. Für die Verwirklichung des Wunsches die Benutzeroberfläche sinnvoll veränderbar zu machen, benötigt man folgende zu speichernde Daten: /D10/ Benutzereinstellungen: - Fenstereinstellungen - Farbeinstellungen 10

6 Produktleistungen /L10/ Die Funktion /F10/ darf als verschlüsselte Nachrichten nicht einfach entschlüsselt werden können. /L20/ Die Funktion /F10/ darf nicht verfälscht werden können. /L30/ Bei der Funktion /F10/ darf man im Anonymen Kanal nicht auf den Sender zurückschließen können. 11

7 Qualitätsanforderungen Produktqualität sehr gut gut normal nicht relevant Funktionalität Angemessenheit Richtigkeit Interoperabilität Ordnungsmäßigkeit Sicherheit Zuverlässigkeit Reife Fehlertoleranz Wiederherstellbarkeit Benutzbarkeit Verständlichkeit Erlernbarkeit Bedienbarkeit Effizienz Zeitverhalten Verbrauchsverhalten Änderbarkeit 12

Analysierbarkeit Modifizierbarkeit Stabilität Prüfbarkeit Übertragbarkeit Anpassbarkeit Installierbarkeit Konformität Austauschbarkeit 13

8 Benutzeroberfläche Bei dem Produkt wird es keine Unterscheidung von Rollen geben, da es nur den Benutzer gibt. /B10/ Standardmäßig sind das Windows-Gestaltungs-Regelwerk sowie die Norm ISO 9241-10: 1996 (Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten, Teil 10: Grundsätze der Dialoggestaltung) in allen Benutzeroberflächen zu beachten. /B20/ Funktionen werden als Kommandos und als grafische Elemente zur Verfügung stehen. /B30/ Jeder Kommunikationskanal wird sein eigenes Fenster haben, zwischen denen man wechseln kann. 14

9 Nichtfunktionale Anforderungen /NF10/ Das Produkt soll plattformunabhängig sein /NF20/ Das Produkt muss anwenderfreundlich sein /NF30/ Das Produkt muss mit geringem Aufwand weiterentwickelbar und wartbar sein 15

10 Technische Produktumgebung 10.1 Software Betriebssysteme: Linux oder Mac OS 10.2 Hardware Mindestens zwei PC s mit der Möglichkeit zur drahtlosen Kommunikation 10.3 Orgware Um eine Nachrichtenübermittlung zu jeder Zeit zu gewährleisten, darf ein vom WLAN Adapter vorgegebener Maximalabstand von mindestens zwei Teilnehmern nicht überschritten werden. 10.4 Produktschnittstellen Lediglich das Protokoll zum Austausch von Nachrichten dient als Schnittstelle zu den Programmen der anderen Projektgruppen, um die Interoperabilität zu gewährleisten. Ansonsten läuft das Produkt eigenständig und benötigt somit keine Schnittstellen zu anderen Produkten. 16

11 Glossar Benutzer: Ein Benutzer ist ein menschlicher Teilnehmer, der das Chatprogramm benutzt. ID: Eine ID ist eine eindeutige Identifikation. Hop-by-Hop: Hop-by-Hop ist die Art und Weise, Übertragungen im Netz von Knoten zu Knoten zu leiten. Kanal: Ein Kanal ist eine Art virtueller Raum, in denen Teilnehmer des Raums miteinander kommunizieren können. Interoperabilität: Interoperabilität bedeutet, dass die fertigen Programme der Projektgruppen miteinander kommunizieren können. Nachricht: Nachrichten sind Daten in textueller und/oder binärer Form. Peer/Knoten: Peers/Knoten sind Endpunkte im vorhandenen Netz die mit anderen Endpunkten verbunden sind. Übertragung: Eine Übertragung ist eine Datenübertragung, die in beide Richtungen stattfinden kann. Verbindung: Eine Verbindung sind zwei miteinander verbundene Knoten/Peers. verbindungslose Übertragung: Eine verbindungslose Übertragung ist eine Übertragung, die ohne aufgebaute feste Verbindung besteht. D.h. Daten können auf unterschiedlichen Wegen durch das Netz zum Ziel gelangen. 17