Course Registration System (CREG)

Dokument zur Softwarearchitektur
Version 1.0

Revisionsprotokoll

Datum

Version

Beschreibung

Autor

21. März 1999 1.0 Dokument zur Softwarearchitektur, generiert aus einer Rational-SoDA-Vorlage und dem Rational-Rose-Modell S. Johnson
 
 
 
 
 
 
 
 
 
 
 
 

 

 

InhaltsverzeichnisZum Seitenanfang

1.   Einführung

2.   Darstellung der Architektur

3.   Ziele und Einschränkungen der Architektur

4.   Anwendungsfallsicht

5.   Logische Sicht

6.   Prozesssicht

7.   Deployment-Sicht

8.   Größenordnung und Leistung

9.   Qualität

Dokument zur Softwarearchitektur

EinführungZum Seitenanfang

1.1 Verwendungszweck

    Dieses 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 Geltungsbereich

    Dieses 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ürzungen

    Siehe Glossar [4]

1.4 Referenzen

    Verfügbare Referenzen:

      1. Spezifikation der Abrechnungsschnittstelle für Kursgebühren WC93332, 1985, Wylie College Press
      2. Spezifikation der Kurskatalogdatenbank WC93422, 1985, Wylie College Press
      3. Course Registration System, Visionsdokument (WyIT387) Version 1.0, 1998, Wylie College IT
      4. Course Registration System, Glossar (WyIT406) Version 2.0, 1999, Wylie College IT
      5. Course Registration System, Spezifikation für den Anwendungsfall 'Registrierung abschließen' (WyIT403) Version 2.0, 1999, Wylie College IT
      6. Course Registration System, Spezifikation für den Anwendungsfall 'Anmeldung' (WyIT401) Version 2.0, 1999, Wylie College IT
      7. Course Registration System, Spezifikation für den Anwendungsfall 'Dozenteninformationen verwalten' (WyIT407) Version 2.0, 1999, Wylie College IT
      8. Course Registration System, Spezifikation für den Anwendungsfall 'Registrierung für Kurse' (WyIT402) Version 2.0, 1999, Wylie College IT
      9. Course Registration System, Spezifikation für den Anwendungsfall 'Zu haltende Kurse auswählen' (WyIT405) Version 2.0, 1999, Wylie College IT
      10. Course Registration System, Spezifikation für den Anwendungsfall 'Studenteninformationen verwalten' (WyIT408) Version 2.0, 1999, Wylie College IT
      11. Course Registration System, Spezifikation für den Anwendungsfall 'Noten erfassen' (WyIT409) Version 2.0, 1999, Wylie College IT
      12. Course Registration System, Spezifikation für den Anwendungsfall 'Zeugnis anzeigen' (WyIT410) Version 2.0, 1999, Wylie College IT
      13. Course Registration System, Softwareentwicklungsplan (WyIT418) Version 1.0, 1999, Wylie College IT
      14. Course Registration System, Iterationsplan, Ausarbeitungsiteration A1 (WyIT420) Version 1.0, 1999, Wylie College IT
      15. Course Registration System, Ergänzende Spezifikation (WyIT400) Version 1.0, 1999, Wylie College IT
2.  Darstellung der ArchitekturZum Seitenanfang
    In diesem Dokument wird die Architektur in Form von Sichten dargestellt (Anwendungsfallsicht, logische Sicht, Prozesssicht und Deployment-Sicht). Eine gesonderte Implementierungssicht wird in diesem Dokument nicht beschrieben. Die genannten Sichten gehören zu einem zugrundeliegenden UML-Modell (Unified Modeling Language), das mit Rational Rose entwickelt wurde.
3.  Ziele und Einschränkungen der ArchitekturZum Seitenanfang

Die folgenden wichtigen Anforderungen und Systemeinschränkungen haben einen erheblichen Einfluss auf die Architektur:

    1. Zum Abrufen sämtlicher Kursinformationen für das aktuelle Semester muss auf das vorhandene traditionelle Kurskatalogsystem am Wylie College zugegriffen werden. Das CREG-System muss die Datenformate und das DBMS des herkömmlichen Kurskatalogsystems [2] unterstützen.
    2. Für die Abrechnung der Kursgebühren wird eine Schnittstelle zum vorhandenen traditionellen Finanzsystem benötigt. Sie ist in der Spezifikation der Schnittstelle für Gebührenabrechnung [1] definiert.
    3. Alle Funktionen für Studenten, Dozenten und den Registrator müssen sowohl auf den lokalen Kampus-PCs als auch über Internet-Einwahlverbindungen auf fernen PCs verfügbar sein.
    4. Das Course Registration System muss einen vollständigen Schutz der Daten vor unbefugtem Zugriff gewährleisten. Bei einem Remote-Zugriff müssen sich Benutzer daher identifizieren und ein Kennwort eingeben.
    5. Das Course Registration System wird als Client-/Serversystem implementiert. Die Clientkomponente befindet sich auf PCs und die Serverkomponente muss auf dem UNIX-Server des Wylie College ausgeführt werden [3].
    6. Alle Leistungs- und Ladeanforderungen, die im Visionsdokument [3] und in der ergänzenden Spezifikation [15] aufgeführt sind, müssen beim Entwickeln der Architektur berücksichtigt werden.

4.  AnwendungsfallsichtZum Seitenanfang

Hier wird die Anwendungsfallsicht der Softwarearchitektur beschrieben. Die Anwendungsfallsicht ist eine wichtige Arbeitsvorgabe für die Auswahl der Szenarien und/oder Anwendungsfälle, die den Schwerpunkt einer Iteration bilden und wichtige zentrale Funktionen repräsentieren. Die Anwendungsfallsicht beschreibt außerdem die Szenarien und/oder Anwendungsfälle, die die Architektur im Wesentlichen abdecken (viele Architekturelemente ausführen) oder die einen bestimmten heiklen Punkt der Architektur veranschaulichen bzw. hervorheben.

CREG-Anwendungsfälle:

- Anmeldung

- Registrierung für Kurse

- Studenteninformationen verwalten

- Dozenteninformationen verwalten

- Zu haltende Kurse auswählen

- Noten erfassen

- Zeugnis anzeigen

- Registrierung abschließen

Diese Anwendungsfälle werden von den Akteuren Student, Dozent oder Registrator eingeleitet. Außerdem kommt es zur Interaktion mit den externen Akteuren Kurskatalog und Gebührenabrechnungssystem.

4.1  Für die Architektur bedeutsame Anwendungsfälle

Titel im folgenden Inhalt angegeben

      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

    Kurzbeschreibung: In diesem Anwendungsfall kann der Registrator die Studenteninformationen im Registrierungssystem verwalten. Dazu gehören das Hinzufügen, Modifizieren und Löschen von Studenten im System. Der Akteur dieses Anwendungsfalls ist der Registrator.

5.  Logische SichtZum Seitenanfang

    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  Architekturübersicht - Paket- und Subsystemebenen

Titel wie obige Überschrift

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.

5.1.3 Middleware

        Ebene

        Die Middlewareebene unterstützt den Zugriff auf Relational DBMS und OODBMS.

5.1.4 Basiswiederverwendung

    Das Paket 'Basiswiederverwendung' enthält Klassen zur Unterstützung von Listenfunktionen und Mustern.

     

6.  ProzesssichtZum Seitenanfang

    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.

6.1 Prozesse

Titel im folgenden Inhalt angegeben

 

      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

       

6.2 Prozess- und Designelemente

Titel im folgenden Inhalt angegeben

 

      Diagrammname: Prozess- und Designelemente

6.2.1 CourseCache

Mit dem Thread CourseCache werden asynchron Elemente aus dem herkömmlichen Kurskatalogsystem abgerufen.

6.2.2 OfferingCache

Mit dem Thread OfferingCashe werden asynchron Elemente aus dem herkömmlichen Kurskatalogsystem abgerufen.

         

6.2.3 Course

Eine von der Universität angebotene Lehrveranstaltung.

Analysemechanismen:

- Persistenz

- Herkömmliche Schnittstelle

 

6.2.4 CourseOffering

      Ein bestimmtes Angebot für einen Kurs mit Wochentag und Uhrzeit.

      Analysemechanismen:

      - Persistenz

      - Herkömmliche Schnittstelle

       

6.3 Abhängigkeiten zwischen Prozessmodell und Designmodell

Titel im folgenden Inhalt angegeben

Diagrammname: Abhängigkeiten zwischen Prozessmodell und Designmodell

 

6.4 Prozesse bis zur Implementierung

Titel im folgenden Inhalt angegeben

Diagrammtitel: Prozesse bis zur Implementierung

6.4.1 Remote

        * 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.

6.4.3 Thread

        * 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.

         

7.  Deployment-SichtZum Seitenanfang

    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.

    Im obigen Inhalt beschriebene Abbildung

    Diagrammname: Deployment-Sicht

7.1 Externer Desktop-PC

      Studenten schreiben sich an externen Desktop-PCs für Kurse ein. Diese PCs sind über Internet-Einwahl mit dem College-Server verbunden.

7.2 Desktop-PC

      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.

7.3 Registrierungsserver

      Der Registrierungsserver ist der Haupt-UNIX-Server des Kampus. Alle Fakultäten und Studenten können über das Kampus-LAN auf den Server zugreifen.

7.4 Kurskatalogsystem

      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.

7.5 Gebührenabrechnungssystem

    Das Gebührenabrechnungssystem (bzw. Finanzsystem) ist ein herkömmliches System, das jedes Semester die Gebührenabrechnungen für Studenten erstellt.

     

8.  Größenordnung und LeistungZum Seitenanfang

    Die gewählte Softwarearchitektur unterstützt die wichtigsten Anforderungen an die Größenordnung und die Ablaufsteuerung, wie sie in der ergänzenden Spezifikation [15] aufgeführt sind:

      1. Das System muss jederzeit bis zu 2000 gleichzeitige Benutzer der zentralen Datenbank und bis zu 500 gleichzeitige Benutzer des lokalen Servers unterstützen.
      2. Die Latenzzeit des Systems beim Zugriff auf die herkömmliche Katalogdatenbank darf nicht mehr als 10 Sekunden betragen.
      3. Das System muss 80 % aller Transaktionen innerhalb von zwei Minuten abschließen können.
      4. Die Clientkomponente soll weniger als 20 MB Plattenspeicherplatz und 32 MB Arbeitsspeicher belegen.

    Die ausgewählte Architektur (Implementierung einer Client-/Serverarchitektur) unterstützt die Anforderungen an Größenordnung und Ablaufsteuerung. Die Clientkomponente wird auf lokalen Kampus-PCs oder fernen PCs mit Einwahlverbindung implementiert. Die Komponenten wurden so konzipiert, dass die Clientkomponente auf den PCs minimale Anforderungen an den Plattenspeicherplatz und den Hauptspeicher stellt.

9.  QualitätSeitenanfang

    Die Softwarearchitektur unterstützt die in der ergänzenden Spezifikation [15] genannten Qualitätsanforderungen:

      1. Die Desktop-Benutzerschnittstelle muss mit Windows 95/98 kompatibel sein.
      2. Die Benutzerschnittstelle des CREG-Systems soll einen hohen Bedienungskomfort haben. Sie ist für computererfahrene Benutzergruppen bestimmt, die keine zusätzliche Schulung für das System benötigen.
      3. Zu jedem Feature des CREG-Systems muss es eine integrierte Onlinehilfe für den Benutzer geben. Die Onlinehilfe soll eine schrittweise Anleitung für die Verwendung des Systems enthalten. In der Onlinehilfe müssen Begriffe und Akronyme definiert sein.
      4. Das CREG-System soll rund um die Uhr verfügbar sein. Die Ausfallzeiten dürfen bei maximal 4 % liegen.
      5. Die mittlere Zeit zwischen auftretenden Fehlern soll bei mehr als 300 Stunden liegen.
      6. Upgrades zum Client des Course Registration System müssen über das Internet vom UNIX-Server auf den PC heruntergeladen werden können. Mit dem Downloadfeature haben Studenten guten Zugang zu Systemupgrades.



        

 
Copyright  (c) IBM Corp. 1987, 2004. Alle Rechte vorbehalten. 

Webbeispiel CREG-Projekt (Course Registration)
Version 2001.03