Grobgranulares Konzeptschema und Anfragemöglichkeiten
6.11 Volksfürsorge - Makro-Graphklasse
Wie leicht zu erkennen ist, bildet die sprachspezifische Graphklasse zu MFS nach der Integra-tion eine isolierte Teilgraphklasse. Es bestehen natürlich Beziehungen zwischen Messages und COBOL– bzw. PL/I–Programmen insofern Nachrichten aus Programmen heraus aufgerufen wer-den. Diese lassen sich allerdings durch eine statische Analyse der Quelltexte nicht ermitteln, da der Name der Message im Programm nicht explizit genannt sein muß7.
6.11 Volksfürsorge - Makro-Graphklasse
Die „Makro-Graphklasse“ bildet die Grundlage für den ersten GUPRO-Prototyp eines Programmverstehenswerkzeugs. Sie soll einen anwendungs- und programmiersprachen-übergreifenden Überblick über den gesamten Softwarebestand der Volksfürsorge ermöglichen.
Ziel ist es, den gesamten Bestand in einem einzigen Exemplar dieser Graphklasse zu repräsen-tieren8. Dieses entsteht inkrementell durch das Parsen einzelner Einheiten.
6.11.1 Parseeinheiten
Ein Parser, der einen Graphen der im folgenden beschriebenen Klasse erzeugt, erhält als Ein-gabe den bereits existierenden (ggf. initialen) Makrograph sowie eine Parseeinheit in einer der berücksichtigten Sprachen und liefert als Ausgabe den entsprechend erweiterten Makrograph.
Die Reihenfolge der geparsten Einheiten darf dabei keinen Einfluß auf den entstehenden Makro-graph haben. Der Makro-Graphklassen–Parser umfaßt also letztlich eine Familie von Parsern, die jede der in den Kapiteln 6.3 bis 6.9 genannten Parseeinheiten akzeptiert.
6.11.2 Graphklasse
Die Makro-Graphklasse (Abbildung 6.9) enthält im Gegensatz zur einfachen Integration der sprachspezifischen Graphklassen, wie sie im vorherigen Kapitel vorgestellt wurde, deutlich we-niger Elemente. Sie ermöglicht die Beantwortung für eine solche Makroebene typischer Fragen unter Vermeidung überflüssig komplizierter Strukturen (vgl. Abschnitt 6.12).
Vier Gesichtspunkte unter denen Anfragen, die auf Abhängigkeiten zwischen den einzelnen Ob-jekten des Software- bzw. Datenbestandes zielen, gestellt werden können, stehen hier im Vorder-grund:
Beziehungen zwischen Programmen und Datenbeständen
Für DB2-Datenbanken können diese direkt ermittelt werden (Kanten der Typen accesses-Db2Column, cspAccessesDb2Column bzw. representsDb2Column). Andere Zugriffe wer-den durch wer-den Knotentyp DataAccess bzw. seine Spezialisierungen repräsentiert. Dies ist nötig, da sich diese Beziehungen zwischen Programm und Datenbestand nicht unmittelbar
Es wird z. Zt. noch geprüft, inwiefern sich solche Beziehungen aufgrund von Programmier- oder Namenskon-ventionen doch ermitteln lassen.
wegen des isolierten Knotentyps Format vgl. Kapitel 6.10 und die Fußnote zu Abschnitt 6.11.3.
106AnwendungslandschaftderVolksfürsorge
6.11 Volksfürsorge - Makro-Graphklasse 107 aus dem Programmtext ergeben, sondern mittelbar durch eine JCL-Procedure bzw. einen entsprechendem PSB hergestellt werden.
Aufrufbeziehungen zwischen einzelnen Programmen
Diese werden durch die Kanten des Typs calls zwischen Programmen, bzw. isCalledBy zwischen JCL-Procedure und Program repräsentiert.
Wiederverwendung von CSP-Objekten in unterschiedlichen Applikationen
Gleichnamige CSP-Objekte verschiedener Applikationen werden im Makrograph durch genau einen Knoten repräsentiert.
Zuordnung von Quelltextdateien zu Programmen (COBOL und PL/I) Dies geschieht über die Kanten der Typen isSourceFor und isStoredIn Knotentyp Program
Die Spezialisierung des Knotentyps Program ist nicht total. Dies hat seinen Grund darin, daß es im Softwarebestand der Volksfürsorge auch Programme gibt, die zwar von anderen Programmen aufgerufen aber hier nicht geparst werden. Das sind zum einen Programme externer Entwickler (z. B. die zu den vorhandenen Systemen mitgelieferten „Sort“–Programme der IBM) und zum anderen Programme, die in Sprachen geschrieben wurden, die hier nicht betrachtet werden. So sind bei der Volksfürsorge z. B. noch eine ganze Reihe Assembler–Programme aktiv (vgl. Ta-belle 6.1). Die hier zu parsenden Programme sind dementsprechend unter der Spezialisierung ParsedProgramm subsummiert.
Dem Knotentyp ParsedProgram sind zwei Gruppen von Attributen zugeordnet. Während die links notierte (author, dateOfCreation, . . . ) Attribute umfaßt, die in den Programmverstehens-kontext fallen, repräsentieren die rechts notierten Attribute (dateOfFirstRelease, noOfReleases, ccMcCabe, . . . ) Informationen bzw. Kennzahlen („Metriken“) zur Programmbewertung Letztere werden imGUPRO-Kontext nicht ermittelt, sondern lediglich durch das Parsen eines geeigneten Textes dem Graph ergänzend hinzugefügt.
Zusammenfassung von Kantentypen
Um Anfragen effizient formulieren zu können, werden in der Makro-Graphklasse einheitliche Kantentypen zur Repräsentation von gleichartigen Beziehungen eingeführt. In Abschnitt 6.11.4 wird erläutert, wie Kanten dieser Typen im einzelnen instanziiert werden.
Die Zugehörigkeit von einzelnen Programmbausteinen (Module) zu Programmen wird so ein-heitlich über den Kantentyp isModuleOf modelliert. Dabei ist natürlich klar, daß mit einem Pl1Program nur Pl1Procedures verbunden sein können (analog für CSP und COBOL). Bei den Kardinalitätsanforderungen für diesen Kantentyp ist noch zu beachten, daß eine PL/I–Prozedur, ebenso wie ein CSP–Prozeß (Statementgroup) in mehreren Programmen Verwendung finden kann. COBOL–Prozeduren hingegen müssen genau einem Programm zugeordnet werden. An-dererseits können durch das Parsen eines PL/I–Files Pl1Procedure–Knoten entstehen, die (noch) keinem Pl1Program zugeordnet werden können. Die folgenden Prädikate beschreiben diese In-tegritätsbedingungen formal:
108 Anwendungslandschaft der Volksfürsorge
Eine Kante des Typs calls steht immer für einen Programmaufruf aus einem anderen Programm heraus. Der Kantentyp performs modelliert hingegen Aufrufbeziehungen von Prozeduren (Funk-tionen, Prozessen) innerhalb eines Programms. Daraus folgt, daß Anfangs- und Endknoten jeder dieser Kanten den gleichen Typ haben bzw. in einer Subtypbeziehung9 stehen. Außerdem sind so verbundene Module–Knoten immer einem gemeinsamen Program zugeordnet:
CAQ
Über den Kantentyp accesses ist eine einheitliche Beziehung zwischen Program und DataAc-cess realisiert. Die dadurch repräsentierte Information ist für CspApplication redundant, denn sie könnte auch über einen Pfad cspAccesses–CspRecord–isRecordIn, gewonnen werden. Diese Redundanz wird aber zugunsten einfacherer Anfragen (s. Kapitel 6.12) in Kauf genommen.
6.11.3 Inkrementelles Parsen mit „Klebeecken“
Jede Parseeinheit liefert einen bestimmten, für ihre Sprache spezifischen Anteil am Makrograph.
Die Makro-Graphklasse wurde unter dem Gesichtspunkt entworfen, interessierende Fragestel-lungen so einfach wie möglich beantworten zu können. Jedoch reichen die darin enthaltenen sprachspezifischen Elemente nicht in jedem Fall, um ein nahtloses „Einkleben“ einzelner Teil-graphen zu ermöglichen. So wird es nötig, weitere Elemente einzuführen, die in solchen Fällen Hilfsfunktionen übernehmen. Ein recht anschaulicher Vergleich hierzu sind Bastelbögen, bei de-nen die einzelde-nen Teile miteinander verklebt werden müssen. Hier sind Klebestellen vorgesehen, die zwar nichts zum Erscheinungsbild des fertigen Gegenstands beitragen aber zum Zusammen-fügen der einzelnen Teile unerläßlich sind.
In Abbildung 6.10 ist die Makro-Graphklasse um eben jene Klebeecken ergänzt dargestellt und schon die Anordnung macht deutlich, daß diese in erster Linie dazu benötigt werden, die Zu-sammenhänge zwischen Programmen, aufrufender JCL-Prozedur, dem entsprechenden PSB und die daraus resultierenden Zugriffsmöglichkeiten auf Datenbestände ermitteln zu können10. Hin-zu kommt noch der Kantentyp isDeclaredIn von FileAccess nach Pl1Procedure. Diese Kanten
falls ein CspProcess eine CspStmtGrp aufruft oder umgekehrt.
Wie bereits in Kapitel 6.10 erwähnt, gibt es u.U. die Möglichkeit, die Beziehung zwischen Format und Program bzw. Module über Konventionen zu ermitteln. Sollte dies der Fall sein, so wird dies nur über Knoten eines Typs Message funktionieren, durch den dann eine zusätzliche „Klebeecke“ entstehen würde.