2.4 Die Modellierung

Gegen Ende der Analyse-Phase begannen wir mit der Erstellung eines Analyse-Modells. Hier galt es nun, aus den zuvor gesammelten Informationen ein Modell zu entwickeln, das die vorgefundene Realität möglichst gut abbildet und zugleich flexibel genug ist, um später im Design zahlreiche Anpassungen und Erweiterungen zu überstehen. Erstes Sammeln von Ideen erfolgte dabei mit Hilfe sogenannter CRC-Karten. Diese einfachen Karteikarten repräsentieren Klassen, die einen Namen (Class), eine Verantwortung der Klasse (Responsibility) und eine Vernetzung (Collaboration) mit anderen Klassen des Systems aufweisen. Diese kann man nun in beliebiger Zahl auf einem Tisch (mit möglichst großer Fläche) anordnen und auf diese Weise Situationen durchspielen, anhand derer man die derzeitige Vollständigkeit und Konsistenz des Modells überprüfen kann. CRC-Karten sind ein sehr gutes Hilfsmittel im Anfangsstadium der Modellbildung, aber bei steigender Komplexität verliert man sehr schnell die Übersicht über das Kartenmeer. Es wird dann Zeit, daß man das Modell in eine "strenge" Notation faßt, die nicht nur die Übersichtlichkeit erhöht, sondern die es auch ermöglicht, daß weitaus mehr Details in das Modell eingefügt werden können.

In unserem Fall wurde die Notation nach Grady Booch benutzt, die in seinem Buch "Object-Oriented Analysis and Design" ([Booch, 1994]) beschrieben wird (siehe auch Anhang K). Das Buch verfügt über eine sehr gute Einführung in die Thematik, stellt die Methodik vor und macht die Anwendung anhand von zahlreichen Beispielen klar. Ermöglicht wird der Einsatz der Notation jedoch erst durch den Einsatz eines CASE-Tools, welches in unserem Fall das Programm "Rational Rose/C++" der Firma Rational Software Corp. war. Nach unserer Erfahrung ist der Einsatz dieses Tools jedoch nur beschränkt möglich/sinnvoll. Bleibt zu hoffen, daß es in Zukunft leistungsfähige Tools geben wird.

Die Abbildung 2.4.1 zeigt die Hauptkomponenten des erstellten Systems. "Zentrale Komponente" ist die Klasse CStundenplanGenerator, welche die Verantwortlichkeit der realen Stundenplaner auferlegt bekommen hat. Um Stundenpläne zu generieren, bedient sie sich der Dienstleistungen der sie umgebenden Klassen. Alle relevanten Daten werden von dedizierten Verwalterklassen gehalten, die auf Anfrage die Daten an den Stundenplangenerator weiterreichen. Es erfolgte dazu eine Aufteilung der Datenmenge in Personen-, Raum- und Fächerdaten. Des weiteren muß eine zusätzliche Klasse in das System gebracht werden, die in der Realität kein Äquivalent besitzt, die Klasse CRestriktionVerwalter. Hier sollen die Informationen gespeichert werden, die später im Lösungsalgorithmus eine Repräsentation als Constraints finden. Diese Restriktionen, die in gewisser Weise die gesammelten Erfahrungen der Stundenplaner bzgl. der Stundenplanerstellung darstellen, werden im System nun zentral gespeichert und können über die Verwalterklasse angesprochen werden.

Ein generierter Stundenplan muß schließlich gespeichert werden, damit er evtl. weiter bearbeitet werden kann. Diese Aufgabe übernimmt CStundenplanVerwalter. Beide, CStundenplanVerwalter und auch CStundenplanGenerator, bedienen sich der Funktionen, die CKalender zur Verfügung stellt. Hier können Informationen vom aktuellen Datum bis zur Anzahl der Feiertage in einem Semester erfragt werden. Dies wird benötigt, um z. B. zwischen verschiedenen Stundenplänen unterscheiden zu können. Weiterhin wird für manche Veranstaltungen gefordert, daß unbedingt genügend freie Veranstaltungstermine zur Verfügung stehen.

Abbildung 2.4.1: CStundenplanGenerator und Dienstleister

Es soll noch erwähnt werden, daß im System zur Laufzeit jeweils nur ein Objekt jeder der o. g. Klassen existiert.

Schauen wir uns nun einmal die Struktur an (Abbildung 2.4.2), die sich hinter der Klasse CFaecherkatalog verbirgt. Diese Klasse wurde in das System eingefügt, um alle notwendigen Informationen über die angebotenen Veranstaltungen zur Verfügung zu stellen. Die einzuplanenden Veranstaltungen sind an der Universität grundsätzlich einem Fach zugeordnet (z. B. ein Fach XYZ besteht aus den Veranstaltungen Vorlesung und zugehörige Übung). Also richten wir eine Klasse CStudienfach und eine Klasse CVeranstaltung ein, deren Objekte die benötigten Informationen über das Fach (z. B. Bezeichnung, Kurzzeichen usw. ) und über die zugehörigen Veranstaltungen (z. B. Veranstaltungsart, Dauer usw. ) bereitstellen. Der Fächerkatalog beinhaltet nun zur Laufzeit alle angebotenen Fächer und die Objekte der Klasse CStudienfach enthalten ihre jeweils zugehörigen Veranstaltungsobjekte.

In Abbildung 2.4.3 sind die Verwalter CRaumVerwalter und CPersonenverzeichnis dargestellt. Die Räume, die bei der Planung zu berücksichtigen sind, werden im System durch Objekte der Klasse CRaum repräsentiert. Diese speichern relevante Daten wie Raumgröße, Raumort und Ausstattung. Der Raumverwalter enthält zur Laufzeit alle diese Räume und ermöglicht Funktionen zum Zugriff bzw. zur Änderung der Daten. Bereitgestellt wird z. B. auch die Suche nach Räumen mit bestimmter Raumausstattung. Auf diese Art und Weise arbeitet auch das Personenverzeichnis. Es enthält Objekte der Klasse CPerson, welche Daten über die Dozenten der angebotenen Veranstaltungen enthalten. Personendaten sind u. a. Name, Adresse und Telefonnummer. Der Verwalter ermöglicht hier die üblichen Suchfunktionen auf den Personendaten.

Abbildung 2.4.2: Organisation der Fächerverwaltung

Was in den bisherigen Darstellungen noch ausgelassen wurde, sind die Assoziationen zwischen verschiedenen Klassen, die benötigt werden, um Redundanz in den Daten zu vermeiden. So muß z. B. eine Person des Systems mit ihren angebotenen Veranstaltungen assoziiert sein, da sonst alle Veranstaltungsinformationen wiederholt im Personenobjekt enthalten sein müßten. Diese Redundanz ist hier auf keinen Fall wünschenswert.

Abbildung 2.4.3: Die Raum- und Personalverwaltung

In der Abbildung 2.4.4 sehen wir die Stundenplanverwaltung. Die vom Stundenplangenerator erzeugten Pläne sollen vom Stundenplanverwalter archiviert werden. Später können diese Pläne dann wieder bei ihm angefordert werden, wobei zur Unterscheidung der Pläne Daten wie z. B. Datum der Erstellung, Autor und Semester gespeichert werden. Ein Stundenplan gliedert sich in die Pläne Dozentenplan, Raumbelegungsplan und Semesterbelegungsplan auf. Genau diese Pläne werden durch die gleichnamigen Klassen in unserem System benutzt.

Abbildung 2.4.4: Aufbau der Stundenplanverwaltung

Der Restriktionsverwalter (siehe Abbildung 2.4.5) stellt ein sehr wichtiges Instrument im System dar. Er wird benutzt, um das Erfahrungswissen der Stundenplaner, d. h. alle Restriktionen, die für die Erstellung eines Stundenplanes wichtig sind, auf Anfrage dem Lösungsalgorithmus zur Verfügung zu stellen. Hierzu muß erwähnt werden, daß Restriktionen Bestandteile der Software sind und als solche die realen Bedingungen, die an einen "guten" Stundenplan gestellt werden, modellieren. Der Lösungsalgorithmus kann dann eine Methode, die jedes übergebene Restriktionsobjekt besitzt, aufrufen und so die Restriktion in ein konkretes Constraint der Klassenbibliothek ILOG Solver übersetzen und den Lösungsalgorithmus starten. Hier nutzen wir die Möglichkeit, abstrakte Klassen einzusetzen. Die Klasse CRestriktion stellt nur einen Rumpf (Interfaceklasse) für konkrete Restriktionen dar, die nach Belieben im System eingefügt werden können. Man kann auf Änderungen in den Anforderungen an den Stundenplan mit einer weiteren Restriktionsklasse reagieren, welche die neuen Informationen beinhaltet und sich nach außen wie jede andere Restriktionsklasse verhält. In der Abbildung wurden beispielhafte Restriktionsklassen eingefügt.

Die Restriktionen sind nun in Restriktionsebenen organisiert. Die Objekte der Klasse
CRestriktionEbene entsprechen einer Prioritätsebene der im nachfolgenden Abschnitt behandelten Liste von Bedingungen. Eine solche Ebene enthält alle Restriktionen, welche dieselbe Priorität haben.

Diese Restriktionsebenen werden schließlich dem Restriktonsverwalter unterstellt. Der Verwalter kann z. B. über eine Methode, die alle Restriktionsebenen besitzen, alle Restriktionen dieser einen Ebene zur Überführung in Constraints veranlassen. Bei der Vorstellung des Designs wird noch genauer darauf eingegangen.

Abbildung 2.4.5: Aufbau der Restriktionsverwaltung

WWW-Designer: Hans Peter Kunz. Letzte Änderung: 12-03-1998.