Course Registration System (CREG) Dokument zur Softwarearchitektur Revisionsprotokoll
Dokument zur Softwarearchitektur Einführung![]() 1.1 VerwendungszweckDieses Dokument liefert einen umfassenden architekturbezogenen Überblick über das System. Hierfür werden verschiedene Architektursichten verwendet, um verschiedene Aspekte des Systems zu beleuchten. Das Dokument soll die signifikanten architektonischen Entscheidungen zum System erfassen und vermitteln. 1.2 GeltungsbereichDieses Dokument zur Softwarearchitektur gibt einen architektonischen Überblick über das Course Registration System (CREG). Das CREG-System wird vom Wylie College entwickelt, um eine Onlineregistrierung für Kurse zu unterstützen. Das vorliegende Dokument wurde direkt aus dem in Rose implementierten Analyse- und Designmodell für CREG generiert. Die meisten Abschnitte des Dokuments wurden mit SoDA aus dem Rose-Modell und der Vorlage für Softwarearchitekturdokumente extrahiert. 1.3 Definitionen, Akronyme und AbkürzungenSiehe Glossar [4] 1.4 Referenzen
![]()
![]()
![]() 4.1 Für die Architektur bedeutsame Anwendungsfälle Diagrammname: Architektonisch signifikante Anwendungsfälle
4.1.1 Registrierung abschließen Kurzbeschreibung: In diesem Anwendungsfall kann ein Registrator den Registrierungsprozess abschließen. Kursangebote, für die sich nicht genug Studenten angemeldet haben, werden storniert. Ein Kurs wird gehalten, wenn sich mindestens drei Teilnehmer gemeldet haben. Das Abrechnungssystem wird über alle Studenten in den nicht stornierten Kursen informiert, so dass den Studenten die Kursgebühren in Rechnung gestellt werden können. Der Hauptakteur dieses Anwendungsfalls ist der Registrator. Das Gebührenabrechnungssystem gehört zu den weiteren, an diesem Testfall beteiligten Akteuren. 4.1.2 Anmeldung Kurzbeschreibung: Dieser Anwendungsfall beschreibt, wie sich ein Benutzer beim Kursregistrierungssystem anmeldet. Die Akteure, mit denen dieser Anwendungsfall beginnt, sind Student, Dozent und Registrator. 4.1.3 Dozenteninformationen verwalten Kurzbeschreibung: In diesem Anwendungsfall kann der Registrator die Dozenteninformationen im Registrierungssystem verwalten. Dazu gehören das Hinzufügen, Modifizieren und Löschen von Dozenten im System. Der Akteur dieses Anwendungsfalls ist der Registrator. 4.1.4 Zu haltende Kurse auswählen Kurzbeschreibung: In diesem Anwendungsfall kann ein Dozent im Kurskatalog die Kursangebote (mit Datums- und Zeitangaben) auswählen, die in sein Fachgebiet fallen und die er im kommenden Semester halten möchte. Der Akteur, mit dem dieser Anwendungsfall beginnt, ist der Dozent. Das Kurskatalogsystem ist ebenfalls ein Akteur in diesem Anwendungsfall. 4.1.5 Registrierung für Kurse Kurzbeschreibung: In diesem Anwendungsfall kann sich ein Student für Kurse des aktuellen Semesters registrieren. Er kann die getroffene Auswahl auch modifizieren oder löschen, falls in der Bestätigungsphase zu Semesterbeginn Änderungen vorgenommen werden. Das Gebührenabrechnungssystem wird über alle Aktualisierungen der Registrierung benachrichtigt. Der Kurskatalog enthält eine Liste aller Kursangebote für das laufende Semester. Der Hauptakteur dieses Anwendungsfalls ist der Student. Das Kurskatalogsystem ist ebenfalls ein Akteur in diesem Anwendungsfall. 4.1.6 Zeugnis anzeigen Kurzbeschreibung: In diesem Anwendungsfall kann sich ein Student sein Zeugnis für das abgelaufene Semester ansehen. Der Akteur dieses Anwendungsfalls ist der Student. 4.1.7 Noten erfassen Kurzbeschreibung: In diesem Anwendungsfall kann ein Dozent Noten für die im letzten Semester abgeschlossenen Fächer erfassen. Der Akteur in diesem Anwendungsfall ist der Dozent. 4.1.8 Studenteninformationen verwalten
![]() Hier wird die logische Sicht der Architektur beschrieben. Die Beschreibung gibt die wichtigsten Klassen, ihre Organisation in Servicepaketen und Subsystemen sowie die Organisation dieser Subsysteme in Ebenen an. Außerdem werden die wichtigsten Anwendungsfallrealisierungen, z. B. die dynamischen Aspekte der Architektur, beschrieben. Sie können Klassendiagramme aufnehmen, um die Beziehungen zwischen den architektonisch signifikanten Klassen, Subsystemen, Paketen und Ebenen zu illustrieren. Die logische Sicht des Course Registration System umfasst drei Hauptpakete: Benutzerschnittstelle, Geschäftsservices und Geschäftsobjekte. Das Paket 'Benutzerschnittstelle' enthält Klassen für alle Formulare, die die Akteure für die Kommunikation mit dem System verwenden. Es gibt Schnittstellenklassen zur Unterstützung der Anmeldung, der Verwaltung von Terminplänen, der Verwaltung von Dozenteninformationen, der Auswahl von Kursen, der Erfassung von Noten, der Verwaltung von Studenteninformationen, des Abschlusses der Registrierung und der Anzeige von Zeugnissen. Das Paket 'Geschäftsservices' enthält Steuerungsklassen, die die Schnittstelle zum Finanzsystem bilden, die Studentenregistrierung steuern und die Studentenbewertung verwalten. Das Paket 'Geschäftsobjekte' enthält unter anderem Entitätenklassen für die Universitätsartefakte (d. h. Kursangebote, Terminplan) und Schnittstellenklassen für die Schnittstelle zum Kurskatalogsystem.
5.1.1 Anwendung Ebene Auf der Anwendungsebene befinden sich alle Schnittstellenklassen für die Darstellung der Anwendungsanzeigen, die der Benutzer sieht. Diese Ebene ist von der Ebene 'Prozessobjekte' abhängig, die die Grenze zwischen Client und Mittelschicht überbrückt. 5.1.2 Geschäftsservices Ebene Auf der Prozessebene 'Geschäftsservices' befinden sich alle Controllerklassen, die die Anwendungsfallmanager zur Steuerung des Anwendungsverhaltens repräsentieren. Diese Ebene bildet die Grenze zwischen Client und Mittelschicht. Die Ebene 'Geschäftsservices' ist von der Ebene 'Prozessobjekte' abhängig, die die Grenze zwischen Client und Mittelschicht überbrückt.
Ebene Die Middlewareebene unterstützt den Zugriff auf Relational DBMS und OODBMS.
![]() Hier wird die Prozesssicht der Architektur beschrieben. Die Beschreibung gibt die Aufgaben (Prozesse und Threads) für die Systemausführung sowie deren Interaktionen und Konfigurationen an. Außerdem wird die Zuordnung von Objekten und Klassen zu Aufgaben beschrieben. Das Prozessmodell illustriert die als ausführbare Prozesse organisierten Kursregistrierungsklassen. Es gibt Prozesse, die die Registrierung von Studenten, Dozentenfunktionen, den Abschluss der Registrierung sowie den Zugriff auf das externe Finanzsystem und Kurskatalogsystem unterstützen.
Diagrammtitel: Prozesse 6.1.1 CourseCatalogSystemAccess Dieser Prozess verwaltet den Zugriff auf das herkömmliche Kurskatalogsystem. Er kann von mehreren Benutzern, die sich für Kurse registrieren lassen, gemeinsam verwendet werden. Kürzlich abgerufene Kurse und Angebote können so in den Cache gestellt werden, um den Durchsatz zu verbessern. Mit den beiden gesonderten Threads des CourseCatalog-Prozesses, CourseCache und OfferingCache, werden asynchron Elemente aus dem herkömmlichen System abgerufen. Analysemechanismen: - Herkömmliche Schnittstelle Rückverfolgbarkeit der Anforderungen: - Designeinschränkungen: Das System soll in ein vorhandenes herkömmliches System (Kurskatalogdatenbank) integriert werden.
6.1.2 CourseCatalogSystem Der vollständige Katalog mit allen Kursen und Kursangeboten der Universität, einschließlich der Kurse der vorherigen Semester. Diese Klasse fungiert als Adapter (siehe Gammamuster). Sie soll sicherstellen, dass der Zugriff auf das Kurskatalogsystem (CourseCatalogSystem) über die Schnittstelle ICourseCatalog zum Subsystem möglich ist.
6.1.3 CourseRegistrationProcess Für jeden Studenten, der sich gerade für Kurse registrieren lässt, gibt es eine Instanz dieses Prozesses.
6.1.4 RegistrationController Dieser Controller unterstützt den Anwendungsfall und ermöglicht die Registrierung eines Studenten für Kurse des aktuellen Semesters. Der Student kann die getroffene Auswahl auch modifizieren oder löschen, falls in der Bestätigungsphase zu Semesterbeginn Änderungen vorgenommen werden. Analysemechanismen: - Verteilung
6.1.5 StudentApplication Dieser Prozess verwaltet die Studentenfunktionen, einschließlich der Benutzerschnittstellenverarbeitung und der Koordinierung mit den Geschäftsprozessen. Für jeden Studenten, der sich gerade für Kurse registrieren lässt, gibt es eine Instanz dieses Prozesses.
6.1.6 MainStudentForm Steuert die Schnittstelle der Studentenanwendung (StudentApplication) und die Gruppe der vom Studenten verwendeten Formulare.
6.1.7 BillingSystemAccess Dieser Prozess kommuniziert mit dem externen Finanzsystem (Gebührenabrechnung), um die Abrechnung der Studiengebühren einzuleiten.
6.1.8 CloseRegistrationProcess Der Prozess CloseRegistrationProcess wird am Ende des Registrierungszeitraums eingeleitet. Er kommuniziert mit dem Prozess, der den Zugriff auf das Finanzsystem steuert.
6.1.9 BillingSystem Das Finanzsystem unterstützt die Übergabe von Rechnungen für die Kurse des aktuellen Semesters, für die sich der Student eingeschrieben hat. Analysemechanismen: - Herkömmliche Schnittstelle
6.1.10 CloseRegistrationController Der CloseRegistrationController steuert den Zugriff auf das Finanzsystem. Analysemechanismen: - Verteilung
Diagrammname: Prozess- und Designelemente 6.2.1 CourseCache
6.2.3 Course Ein bestimmtes Angebot für einen Kurs mit Wochentag und Uhrzeit. Analysemechanismen: - Persistenz - Herkömmliche Schnittstelle
6.4 Prozesse bis zur Implementierung Diagrammtitel: Prozesse bis zur Implementierung
* Die Schnittstelle Remote dient der Identifizierung aller fernen Objekte. Sie muss direkt oder indirekt von allen fernen Objekten implementiert werden. Nur die für Remote-Schnittstellen angegebenen Methoden sind über Remote-Zugriff verfügbar. * Implementierungsklassen können beliebig viele Remote-Schnittstellen implementieren und andere ferne Implementierungsklassen erweitern. 6.4.2 Runnable * Die Schnittstelle Runnable sollte von allen Klassen implementiert werden, deren Instanzen von einem Thread ausgeführt werden sollen. Die Klasse muss eine Methode mit dem Namen run ohne Argumente definieren. * Diese Schnittstelle soll ein allgemeines Protokoll für Objekte bereitstellen, die Code austauschen möchten, wenn sie aktiv sind. Runnable wird beispielsweise von der Klasse Thread implementiert. * Das Wort 'aktiv' meint hier lediglich, dass ein Thread gestartet und noch nicht gestoppt wurde.
* Ein Thread ist ein Ausführungs-Thread in einem Programm. Die Java Virtual Machine lässt zu, dass eine Anwendung mehrere Threads gleichzeitig ausführt. * Jeder Thread hat eine Priorität. Threads mit höherer Priorität werden vor Threads mit niedrigerer Priorität ausgeführt. Jeder Thread kann außerdem als Dämon markiert werden. Wenn in einem Thread ausgeführter Code ein neues Thread-Objekt erzeugt, stimmt die Anfangspriorität des neuen Threads mit der des erzeugenden Threads überein. Der neue Thread ist nur dann ein Dämon, wenn der erzeugende Thread ein Dämon ist.
Eine Beschreibung der Deployment-Sicht der Architektur beschäftigt sich mit den verschiedenen physischen Knoten der am häufigsten verwendeten Plattformkonfigurationen. Eine solche Beschreibung erläutert auch die Zuordnung von Aufgaben (aus der Prozesssicht) zu den physischen Knoten. Dieser Abschnitt ist entsprechend der physischen Netzkonfiguration aufgebaut. Jede Konfiguration wird in einem Deployment-Diagramm und durch eine Zuordnung von Prozessen zu den einzelnen Prozessoren illustriert. Diagrammname: Deployment-Sicht Studenten schreiben sich an externen Desktop-PCs für Kurse ein. Diese PCs sind über Internet-Einwahl mit dem College-Server verbunden. Studenten schreiben sich an lokalen Desktop-PCs für Kurse ein. Diese PCs sind direkt über ein LAN mit dem College-Server verbunden und werden auch von Dozenten für das Auswählen von Kursen und das Erfassen von Noten genutzt. Der Registrator verwendet diese lokalen PCs für die Verwaltung von Studenten- und Dozenteninformationen. Der Registrierungsserver ist der Haupt-UNIX-Server des Kampus. Alle Fakultäten und Studenten können über das Kampus-LAN auf den Server zugreifen. Das Kurskatalogsystem ist ein herkömmliches System, das den gesamten Kurskatalog enthält. Der Zugriff auf das System ist über den College-Server und das LAN möglich. Das Gebührenabrechnungssystem (bzw. Finanzsystem) ist ein herkömmliches System, das jedes Semester die Gebührenabrechnungen für Studenten erstellt.
![]()
![]()
|
|