SDD System Design Document

Größe: px

Ab Seite anzeigen:

Download "SDD System Design Document"

Gerhardt Stieber
vor 8 Jahren
Abrufe

1 SDD Software Konstruktion WS01/02 Gruppe 4

2 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen detaillierten Überblick über die Systemumgebung, strukturelle Konzepte und verwendete Schnittstellen bieten. Seite 2 von 6 Autor: Gruppe 4

wird. Es soll einen detaillierten Überblick über die Systemumgebung,

3 2. Vorgeschlagene Software Architektur 2.1 Übersicht Dispatcher Algo 1 Proxy Algo 2 Checker Algo 3 Service -Schicht Implementierungsschicht Damit unser System einfach erweiterbar ist, führten wir zwei grundsätzlich verschiedene Schichten ein. Einerseits ist dies die Implementierungsschicht, die verschiedene Module enthalten kann, die sehr einfach ausgetauscht werden können, und somit eine gewisse Flexibilität in die Wahl des Peer-to-peer-Algorithmus bringen. Diese Module sind selbständig und dürfen nicht miteinander kommunizieren. Sie dürfen jedoch verschiedene Dienste aus der Service-Schicht in Anspruch nehmen. Die Service-Schicht besteht aus drei verschiedenen Komponenten: Dispatcher, Checker und Proxy, auf die in den folgenden Abschnitten näher eingegangen wird. Sie dürfen beliebig miteinander kommunizieren. 2.2 Subsysteme Aus Gründen der stetigen Veränderung und Erweiterung der Schnittstellen innerhalb des gesamten, gruppenübergreifenden Projekts, entschieden wir uns für die Einführung eines Proxies. Er stellt die Verbindung nach aussen dar und ist dementsprechend die einzige nach aussen sichtbare Komponente. Da die anfallenden Peer-to-peer-Zuteilungen sehr unterschiedlich in Punkto Grösse, Komplexität und Anforderungen sein können, muss der Dispatcher die richtige Implementierung aus der Implementierungsschicht wählen. Er kann auch eine komplexe Aufgabe aufteilen und an verschiedene Implementierungen delegieren. Damit der Dispatcher die Qualität der zurückgelieferten Lösungen überprüfen kann, steht ihm der Checker zur Verfügung. Dieser bietet für alle Komponenten die Möglichkeit auf einfache Weise die Anzahl Überschneidungen mit früheren Zuteilungen in einer Peer-to-peer-Zuteilung zu bestimmen. Die verschiedenen Implementierungsmodule haben alle die selbe Schnittstelle und sind voneinander unabhängig. Sie erledigen alle die selbe Aufgabe, jedoch mit unterschiedlichen Strategien in unterschiedlicher Zeit und Qualität. 2.3 Software Hardware-Abbildung 2.4 Speicherung von Daten 2.5 Zugangs- und Zugriffskontrolle Da die ganze Kommunikation von und nach aussen über den Proxy läuft, hat dieser die volle Kontrolle, was wann aufgerufen wird. Der Proxy ist auch die einzige gegen aussen sichtbare Komponente unseres Subsystems. 2.6 Kontrollfluss Der Kontrollfluss innerhalb unseres Systems ist wie folgt geregelt: Die Services der Komponenten in der Service-Schicht können von allen Komponenten genutzt (bzw. aufgerufen) werden. Die einzelnen Implementierungen dürfen jedoch nur vom Dispatcher aufgerufen werden und nicht miteinander kommunizieren. 2.7 Grenzfälle und Randbedingungen Mehrmaliges Anfordern von Reviewzuteilungen Seite 3 von 6 Autor: Gruppe 4

ein. Einerseits ist dies die Implementierungsschicht, die verschiedene Module enthalten kann, die sehr einfach ausgetauscht werden können, und somit eine gewisse Flexibilität in die Wahl des

4 Es darf nicht erwartet werden, dass die Funktion AssignReviewers(U_ID) deterministisch ist. Praktisch heisst das, dass mehrmaliges Anfordern von Reviewzuteilungen unter den gleichen Voraussetzungen verschiedene Lösungen hervorbringen kann. Zuteilungsqualität Wird nach einer bestimmten Anzahl von Zuteilungsprozessen keine vollständig korrekte Lösung gefunden, so wird die beste verfügbare verwendet. Eine nicht vollständig korrekte Lösung ist dabei eine, die welche nicht alle geforderten Kriterien erfüllt. Sie kann beispielsweise eine Reviewer-Reviewee Kombination enthalten, welche bereits zu einem früheren Zeitpunkt aufgetreten ist. Handhaben von abwesenden Studenten Die Abwesenheit von Studenten wird durch den Peer-Review-Algorithmus nicht berücksichtigt. Seite 4 von 6 Autor: Gruppe 4

Zuteilungsqualität Wird nach einer bestimmten Anzahl von Zuteilungsprozessen keine vollständig korrekte Lösung gefunden, so wird die beste verfügbare verwendet.

5 3. Beschreibung der von den Subsystemen zur Verfügung gestellten Services: Daten: RV: Eine Review Zuordnung ST_ID zu ST_ID (Student zu Reviewer) 3.1 Proxy Liefert extern: AssignReviewers(U_ID) Liefert intern: GetSubmission(U_ID): List of ST_ID GetActualStudents(): List of ST_ID GetReviewAssigns(U_ID): List of RV StoreReviewAssigns (U_ID, List of RV) Braucht: DB:GetSubmission(U_ID): ST_ID List NEU: DB:GetActualStudents(): List of ST_ID NEU: DB:GetReviewAssigns(U_ID): List of RV NEU: DB:StoreReviewAssigns(U_ID, List of RV) 3.2 Dispatcher Liefert: AssignReviewers(U_ID) 3.3 Checker Liefert: CheckAllAssigns(U_ID, List of RV) CheckSingleAssign(U_ID, ST_ID: Student, ST_ID: Reviewer) 3.4 Algo N Liefert: Assign(U_ID, List of ST_ID: Students, List of ST_ID: Reviewers): List of RV Seite 5 von 6 Autor: Gruppe 4

of RV) Braucht: DB:GetSubmission(U_ID): ST_ID List NEU: DB:GetActualStudents(): List of ST_ID NEU: DB:GetReviewAssigns(U_ID): List of RV NEU: DB:StoreReviewAssigns(U_ID, List of RV) 3.

6 4. Verzeichnis von Abkürzungen, Terminologie, etc. U_ID ST_ID RV User ID Studenten ID Zuordnung Reviewer-Reviewee Seite 6 von 6 Autor: Gruppe 4

Ähnliche Dokumente

Fragen und Antworten

Fragen und Antworten im Umgang mit dem elektronischen Abfallnachweisverfahren eanv in Bezug auf die ZKS-Abfall -Allgemeine Fragen- www.zks-abfall.de Stand: 19.05.2010 Einleitung Auf den folgenden Seiten