Inhaltsverzeichnis
3.1. Entwurf der Schnittstelle

3.2. Integration der vorhandenen Daten und Algorithmen

Algorithmen

Die Algorithmen aus [1] wurden für Borland Pascal unter MS-DOS entwickelt. Bei der Übernahme in dieses Projekt sind nur geringfügige Änderungen erforderlich:

• Unter MS-DOS musste zwischen 16- und 32-bittigen ganzzahligen Variablen unterschieden werden. Durch den Umstieg auf ein 32-Bit-Betriebssystem ist diese Unterscheidung hinfällig; ganzzahlige Variablen sind standardmäßig 32 Bit breit.
• Typencodes überschreiten den Wertebereich 32-bittiger Ganzzahlen. In [1] wurde für diese Werte deshalb ein Spezialtyp des numerischen Koprozessors benutzt, der zwar mit 64 Bit einen ausreichenden Wertebereich bot, aber vergleichsweise langsam war. Die neue Umgebung Delphi bietet dagegen einen schnellen, 64-bittigen ganzzahligen Datentyp. Bei der Umstellung auf diesen Datentyp entsteht allerdings das Problem, dass ein Rechnen mit Zwischenergebnissen, die den Wertebereich von 64 Bit übersteigen, damit nicht mehr ohne Weiteres möglich ist. Diese Situation tritt in den Algorithmen beim Berechnen von Binomialkoeffizienten auf und lässt sich auch nicht effektiv umgehen. Hier muss eine eigene Prozedur implementiert werden, die einen Wert mit einem zweiten multipliziert und anschließend durch einen dritten dividiert, wobei zwischenzeitliche Überläufe zu beachten sind.
• Die globale Gelenkliste (a,b), die bei verschiedenen Prozeduren aus [1] zur Definition der zu behandelnden Struktur genutzt wurde, ist für das hier gewünschte abstrakte Interface nicht geeignet. Statt dessen werden Strukturen in Form ihrer Gliedmatrix als Parameter übergeben, und die Werte für (a,b) werden funktionsintern daraus gewonnen.

Der Algorithmus zum Ableiten von MTen aus Ketten muss zusätzlich um neue Funktionalität ergänzt werden; nämlich für den Fall, dass die Analyse der Basiskette gefordert ist:

• Die Analyse selbst, nach dem Algorithmus aus Abschnitt 2.4. Die potentiellen AGn der Kette werden in der Basiskette (Feld AssurTestGlieder) abgelegt.
• Die Bestimmung der Eigentlichkeit aller abgeleiteten MTen, die sich aus den bei der Kettenanalyse gewonnenen Daten unmittelbar ablesen lässt.

Die konkrete Implementierung dieser Ergänzungen ist im Quelltext der Bibliothek (Seiten C 9 bis C 13) zu sehen.

Daten

Die Typenkatalog-Dateien werden von [1] übernommen, allerdings ist auch hier eine Änderung angebracht. Die besondere Struktur dieser Kataloge war aufgrund der Beschränkungen des Betriebssystems entstanden, denn unter MS-DOS konnte eine 2 Megabyte große Datei nicht ohne Weiteres komplett in den Hauptspeicher geladen werden. Unter Win32 ist das problemlos möglich; bei einer heute üblichen Speicherausstattung können sogar alle vorhandenen Kataloge gleichzeitig im Hauptspeicher liegen, ohne übermäßig Ressourcen zu verschwenden. Explizites Verschieben von Daten zwischen Datenträger und Hauptspeicher ist überdies auch gar nicht mehr so relevant, da moderne Betriebssysteme diese Zuordnung nach eigenem Ermessen treffen (Festplattencache, Virtueller Speicher).

Eine besondere Strukturierung der Kataloge ist deshalb nicht mehr notwendig. Im Gegenteil: sie behindert eine direkte Indizierung der Codes und verkompliziert außerdem die schnelle binäre Suche nach ihnen. Die Strukturierung der Kataloge wird deshalb entfernt, d.h. nach dem unveränderten Dateikopf folgen nur noch die aufsteigend sortierten Typencodes.

Zum Zugriff auf die Kataloge wird das Feld Kat verwendet, in das die Typencodes aus einer Datei geladen werden. Die Suche nach einer Katalognummer besteht dann einfach darin, auf den betreffenden Index zuzugreifen. Die Suche nach einem Code kann binär erfolgen, da die Codes sortiert vorliegen:

lo:=0; hi:=KatLaenge-1; repeat Nummer:=(lo+hi) div 2; if Kat[Nummer]<Code then lo:=Nummer+1 else hi:=Nummer-1 until (Kat[Nummer]=Code) or (lo>hi);

Ist nach dem Durchlauf Kat[Nummer]<>Code, dann ist der gesuchte Typencode nicht im Katalog enthalten.

Die Bibliothek muss nach dem Design der Schnittstelle selbständig alle Kataloge verwalten können. Die Variable Kat wird deshalb noch um zwei Dimensionen erweitert: die Anzahl der nicht vertauschbaren Glieder (0 für Ketten, 1 für AGn) sowie die Anzahl der Glieder. Da die Kataloge unterschiedlich groß sind und außerdem kaum alle gleichzeitig benötigt werden, sollte der Speicherplatz für einen einzelnen Katalog bei Bedarf in der benötigten Größe dynamisch zugewiesen und später wieder frei gegeben werden:

type List=array[0..maxKatLaenge-1] of int64; var Kat: array[0..1,4..14] of ^List; {Typencodes aus Katalogen, erster Index: 0=Ketten 1=Assur-Grupen, zweiter Index: Anzahl der Glieder} KatLaenge: array[0..1,4..14] of integer; {zugehörige Anzahl der Typen}

3.3. Zerlegen in Assur-Gruppen