Zusammenfassung. Zum systematischen Entwurf undzur Realisierung von Graphstrukturen und ihrer Zu-griffsoperationen wurde die SpezifikationssprachePROGRES entwickelt. Sie unterstutzt das Modellierenkomplex strukturierter Sachverhalte, wie sie beim Bauinteraktiver Systeme auftreten. Sie erlaubt die gemischtregelorientierte bzw. imperative Formulierung entspre-chender Zugriffsoperationen mit Hilfe PROgram-mierter GRaph-Ersetzungs-Systeme, besitzt ein stati-sches Typsystem, eine vollstandige formale Definitionihrer statischen und dynamischen Semantik und ist so-wohl interpretativ als auch kompilativ ausfuhrbar.

Hier soll die Eignung der Sprache PROGRES undihrer Entwicklungsumgebung zur operationalen Spezi-fikation entsprechender Systeme und zur Generierungvon Prototypen gezeigt werden. Dabei legen wir ein be-sonderes Gewicht auf die Unterstutzung durch die engeIntegration ihrer Werkzeuge, die das verschrankte Edi-tieren, Analysieren und Ausfuhren gestatten. Bei dengenerierten Prototypen stehen leichte Erweiterbarkeit,Persistenz der Daten, Recovery und Mehrbenutzerfa-higkeit im Vordergrund.

Schlusselworter: Graphersetzungssysteme, Prototyping,Spezifikationssprachen

Abstract. The specification language PROGRES hasbeen developed for the systematic design and realiza-tion of graph structures and operations on them. It isstatically typed, its static and dynamic semantics is for-mally defined. It offers both, rule based and imperativelanguage constructs and supports modeling of complexstructures in interactive systems and by the means ofPROgrammed Graph REwriting Systems.

We want to show the suitability of the PROGRESlanguage and environment for the operational specifica-tion and generation of prototypes for this kind of sys-

tems. We focus on the tightly integrated tools, which al-low editing, analyzing, and executing specifications inan intertwined way. Features of the generated proto-types are extendibility, data persistence, recovery, andmulti user support.

Key words: Graph rewriting systems, prototyping, speci-fication languages

CR Subject Classification: D.1.6, D.1.7, D.2.1, D.2.6,D.3.1, D.3.3, D.3.4

1 Einleitung

Eine Hauptaufgabe der Softwaretechnik ist die Erfor-schung von Sprachen und Methoden zum Bau komple-xer interaktiver Systeme. Solche Systeme werden in An-wendungsgebieten wie rechnergestutzter Entwurf vonKonstruktionsplanen (CAD), Buroautomatisierung(Workflow Management) oder Projektmanagementund nicht zuletzt in der Softwaretechnik selbst benotigt.Ein gemeinsames Charakteristikum solcher Systeme ist,daß sie die Beschreibung, Bearbeitung und Darstellungkomplex strukturierter und vielfach verzahnter Sachver-halte unterstutzen mussen.

Zum systematischen Entwurf und zur Realisierungpassender Datenstrukturen und Zugriffsoperationenbenotigt man Sprachen, Methoden und Werkzeuge, die• die Modellierung der Datenstrukturen im Sinne des

konzeptionellen Datenbankschemaentwurfs unter-stutzen,

• die Beschreibung der darauf auszufuhrenden Infe-renz- und Transformationsprozesse auf moglichst ho-hem Niveau gestatten,

• die Validierung der erstellten Beschreibungen durchstatische Analysen oder durch Prototyping erlaubenund schließlich

• ihre Umsetzung in ein korrekt und effizient arbeiten-des Endprodukt erleichtern.

Informatik Forsch. Entw. (1996) 11: 191–202

Spezifikation und Prototyping graphbasierter Systeme*

Andy Schurr1, Andreas J.Winter1, Albert Zundorf 2

1 Lehrstuhl fur Informatik III, RWTH Aachen, Ahornstr.55, D-52074 Aachen (e-mail: {andyvwinter}@i3.informatik.rwth-aachen.de)2 Fachbereich 17, AG Softwaretechnik, Universitat Paderborn, D-33095 Paderborn (e-mail: zuendorf@uni-paderborn.de)

Eingegangen am 1. April 1996/Angenommen am 6.September 1996

Springer-Verlag 1996

* Dieser Artikel ist eine uberarbeitete Fassung des gleichnamigenBeitrags zur GI-Fachtagung Softwaretechnik 95 [20].

Bislang hauptsachlich verwendete Ansatze in der Soft-waretechnik – wie die „klassischen“ strukturierten Ana-lyse- und Designmethoden von DeMarco [6], Yourdon[22], etc. oder die ihnen nachfolgenden objektorientier-ten Methoden OMT [18], Fusion [3], etc. – leiden darun-ter, daß die Semantik der verwendeten Sprachmittelund insbesondere deren Zusammenspiel nicht prazisegenug definiert ist.

Formale Spezifikationssprachen hingegen – wie CIP-L [4], Larch [11] oder Z [7] – besitzen eine wohldefinier-te Semantik und unterstutzen teilweise die Verifikationgewunschter Eigenschaften bzw. die semantikerhalten-de Transformation abstrakter Spezifikationen in kon-krete Implementationen. Aber die ihnen zugrundelie-gende Ideenwelt algebraischer Spezifikationen oder (ty-pisierter) pradikaten-logischer Kalkule ist nicht sonder-lich fur die Modellierung komplexer Datenstrukturenmit vielfachen Querbeziehungen untereinander unddie Definition darauf durchzufuhrender Transformatio-nen geeignet.

Ahnliche Einwande gelten fur sehr hohe Program-mier- oder Prototypingsprachen wie Smalltalk [10],OPS-5 [16] oder Prolog [5]. Sie besitzen zwar entwedereine formal definierte oder de facto durch ihre Imple-mentierung festgelegte Semantik. Dafur fehlt ihnenmeist ein statisches Typkonzept, so daß sie die Validie-rung erstellter Programme vor ihrer Ausfuhrung uber-haupt nicht unterstutzen. Eine Ausnahme bilden hierpolymorphe funktionale Sprachen wie ML [13] mit sei-nen Typinferenzmechanismen oder etwa SETL [8] mitseinen optionalen Typangaben. Sie konzentrieren sichallerdings auf die Modellierung von Listen, Mengenund Baumen. Damit lassen sich aber die komplex ver-netzten, strukturellen Zusammenhange zwischen Ob-jekten der oben angesprochenen Systeme nur schwermodellieren.

Um diese Lucke zu schließen, wurde die graphischeSpezifikationssprache PROGRES entwickelt, die• das Modellieren komplex strukturierter Sachverhalte

mit dem Datenmodell der gerichteten, attributierten,knoten- und kantenmarkierten Graphen unterstutzt,

• die regelorientierte und imperative Formulierungentsprechender Zugriffsoperationen mit HilfePROgrammierter GRaph-Ersetzungs-Systeme er-laubt,

• ein polymorphes und im wesentlichen statisches Typ-system mit Deklarationspflicht und uber 300 daraufberuhenden Konsistenzregeln anbietet,

• eine vollstandige formale Definition ihrer statischenund dynamischen Semantik besitzt,

• sowohl interpretativ als auch kompilativ ausfuhrbarist

• und schließlich durch eine Entwicklungsumgebungunterstutzt wird, die es erlaubt, Spezifikationen ge-mischt textuell und graphisch zu formulieren.

Damit kann man PROGRES als eine modellorientierteausfuhrbare Spezifikationssprache ansehen, die aller-dings – abgesehen von den Konsistenzregeln ihres Typ-systems – die Erstellung von Korrektheitsbeweisennicht unterstutzt. Sie verdient deshalb vielleicht besser

das Pradikat einer Programmiersprache auf sehr hohemNiveau (Very High Level Language), die mehrere Pro-grammierparadigmen unterstutzt. Im folgenden werdenwir den Einsatz der Sprache und ihrer Werkzeuge an ei-nem Beispiel vorstellen. Dabei soll diskutiert werden,warum sich PROGRES gerade fur das Prototyping vonSystemen oder Systemkomponenten eignet, die internkomplexe Datenstrukturen manipulieren, die uber einegraphische Benutzeroberflache sichtbar gemacht wer-den sollen.

Fur die formale Definition der Sprache PROGRESsei der Leser auf [19] und fur die Beschreibung ihrerEntwicklungsumgebung auf [24] verwiesen. Schließlichist es auch nicht Ziel dieses Aufsatzes, Vor- und Nach-teile formaler Spezifikationsmethoden und des Proto-typing bei der Softwareentwicklung bzw. deren Einord-nung in Softwarelebenszyklusmodelle zu diskutieren.Hierfur verweisen wir auf [2], [8], [12] oder [14].

2 Spezifikation eines merkmalsorientiertenKlassifikationssystems

In diesem Kapitel wird anhand eines einfachen merk-malsorientierten Softwareklassifikationssystems dieSpezifikation der Datenstrukturen eines zu realisieren-den Anwendungssystems vorgestellt. Das Beispielselbst hat lediglich „Spielcharakter“ und wird hier nichtbis ins Detail ausgearbeitet. Es eignet sich jedoch sehrgut dazu, die verschiedenen Elemente der SprachePROGRES und ihre Verwendung anschaulich zu erlau-tern. Schließlich wird in einem weiteren Abschnitt dieWerkzeugunterstutzung fur die Erstellung einer Spezifi-kation durch die PROGRES-Entwicklungsumgebungdargestellt.

2.1 Das Anwendungsbeispiel

Als Beispiel zur Erlauterung der Sprache PROGRESverwenden wir hier ein merkmalsorientiertes Klassifika-tionssystem (engl.: Feature-Oriented Classification Sy-stem = FOCS), das in [1] vorgestellt wurde. Ein derarti-ges System dient dazu, die Eigenschaften von Software-komponenten durch eine Menge von charakteristischenMerkmalen zu beschreiben. Das Ziel dieser Klassifika-tion ist die Wiederverwendung von Softwarebausteinen.Um Wiederverwendung zu ermoglichen, ist es notwen-dig, den potentiellen Benutzern Kenntnis uber bereitsvorhandene Komponenten und deren Eigenschaften zugeben. Dies bedeutet, daß wiederverwendbare Kompo-nenten zunachst identifiziert und bezuglich verschiede-ner Merkmale klassifiziert werden mussen. Diese Klas-sifikation muß geeignet gespeichert werden, damit an-schließend Anfragen gestellt werden konnen, die zu be-stimmten geforderten Eigenschaften bereits erfaßte undgeeignete Softwarekomponenten liefern.

Der Vorteil des hier dargestellten Ansatzes ist, daßdie Merkmale bezuglich denen die Bausteine eingeord-net werden sollen, nicht von vorneherein feststehen,sondern standig erweitert werden konnen. Die Merk-

192

malshierarchie stutzt sich auf zwei verschiedenen Artenvon Verfeinerung ab. Im einen Fall werden die Merk-male spezialisiert, um Eigenschaften von Softwarekom-ponenten genauer beschreiben zu konnen (is-Verfeine-rung). Dahinter verbirgt sich die Idee, daß nur einesder spezielleren Merkmale die Komponente charakteri-siert (Selektion). Der andere Fall der Verfeinerung(view-Verfeinerung) beschreibt eine Aufspaltung einesMerkmals in mehrere verschiedene Facetten. Eine Fa-cette ist ein besonderer Gesichtspunkt eines Merkmals,d.h. die Eigenschaft einer Komponente bezuglich einesMerkmals ergibt sich aus den Eigenschaften bezuglichaller Facetten des Merkmals (Aggregation). Das bedeu-tet insbesondere, daß eine Komponente immer zu allenFacetten eines view-verfeinerten Merkmals eingeordnetwerden muß.

Bei der Modellierung eines derartigen Systems ist esnotig, sich mit Hilfe geeigneter Beispielsituationen dar-uber Klarheit zu verschaffen, welche Information daszu modellierende System verfugbar machen soll. Dazubetrachtet man typische Operationen auf der internenDatenstruktur bzw. Anfragen verschiedener Benutzer-gruppen an das System. Das Beispiel in Abbildung 1zeigt einen Ausschnitt eines konkreten Klassifikations-graphen fur Benutzeroberflachenwerkzeuge. DerFOCS-Graph spaltet sich in einen Klassifikationssche-ma- und einen Datenanteil. Im Schemateil bezeichnensub -Kanten die is-Verfeinerung von Merkmalsklassen(Class- Knoten) und has -Kanten die view-Verfeine-rung von View -Knoten zu Facetten. Beispielsweise glie-dert sich der View- Knoten UITools in die FacettenKind , Licence und Domain. Dies bedeutet, daß beider Einordnung eines Softwarebausteins in diesenView Aussagen uber diese drei Gesichtspunkte getrof-fen werden mussen. Bei der Einordnung von Tcl/Tkin die Klasse der Anwendungsdomane (Domain ) wirdin diesem Beispiel das Wissen uber die Komponente da-durch prazisiert, daß sie in genau eine der speziellen Un-terkategorien (hier: UIBuilder ) eingetragen wird. Mitref- Kanten wird die Einordnung einer Komponentebezuglich der Merkmalsklassen dargestellt. Neben denOperationen zur Erweiterung des Klassifikationssche-

mas und der Erfassung neuer Softwarekomponentenwird ein Benutzer bei der Suche nach Komponenten zu-satzlich zu ihren eigenen Charakteristika auch wissenwollen, ob sie andere Komponenten verwenden. DieseBenutzungsabhangigkeiten zwischen Softwarekompo-nenten werden durch uses -Kanten ausgedruckt.

Die Modellierung unseres Klassifikationssystems be-ginnt mit dem Entwurf der statischen Daten- oderGraphstrukturen des Systems im folgenden Abschnitt.Danach wird vorgestellt, wie man Operationen auf die-sen Daten mit Graphersetzungsregeln spezifiziert.

2.2 Datenmodellierung mit Graphen

PROGRES ist eine streng typisierte Sprache, in der diestatischen Eigenschaften aller Elemente des zu model-lierenden Systems in einem Graphschema definiert wer-den. In einem solchen Graphschema wird fur alle ver-wendeten Knotenarten festgelegt, welche Attribute siebesitzen und uber welche Kantenarten sie zueinanderin Beziehung stehen. Gemeinsame Eigenschaften ver-schiedener Knotenarten werden in einer objektorien-tierten Knotenklassenhierarchie (mit Mehrfachverer-bung) zusammengefaßt und organisiert.

Nachdem in Abbildung 1 das Klassifikationssystemauf Instanzebene vorgestellt wurde, soll jetzt ein allge-meines Graphschema fur seine internen Datenstruktu-ren erstellt werden. Wir betrachten die KnotenklasseCODE. Innerhalb ihrer Deklaration werden die Attri-bute der zugehorigen Knoten definiert. Zunachst wirduber die is a -Beziehung festgelegt, daß Knoten dieserKlasse alle Eigenschaften der Klasse COMPONENTerbenwie zum Beispiel Name der Komponente und des Au-tors. Damit soll ausgedruckt werden, daß es sich beiProgrammcode um eine spezielle Softwarekomponentehandelt.

node class CODE is a COMPONENTderived isDocumented =

self is with < -describes-;end ;edge type describes :

DOCU [0 : n]- > CODE [1 : 1];

Zusatzlich wird das abgeleitete Attribut isDocumentedneu definiert. Es soll Aufschluß daruber geben, ob zumProgrammcode Dokumentation verfugbar ist odernicht. Der Wert eines abgeleiteten Attributs ergibt sichdurch seine zugehorige Berechnungsvorschrift aus derStruktur des umgebenden Graphen. Hier wird der Wertdes Attributes entsprechend der Existenz einlaufenderKanten des Typs describes berechnet. Kanten diesesTyps laufen von DOCU-Knoten zu den Knoten des TypsCODE. Vereinfachend wird hier angenommen, daß eineDokumentation genau ein Codestuck beschreibt, aberfur Programmcode mehrere (oder gar keine) Dokumen-tationen existieren konnen. Dies wird durch die Kardi-nalitatsangaben in der Deklaration der describes -Kante ausgedruckt. Die Angabe [1 : 1 ] legt fest, daßbei der Traversierung der Kante in dieser Richtung im-

193

Abb.1. Beispielgraph des Klassifikationssystems

mer genau ein Zielknoten gefunden wird, wahrend dieKardinalitat [0 : n ] bedeutet, daß die Traversierungder Kante in der anderen Richtung entweder keinenoder beliebig viele Ergebnisknoten zuruckliefert.

Man beachte, daß Kantentypen getrennt von denKnotenklassen deklariert werden. Dies druckt zum ei-nen aus, daß Kanten Struktureigenschaften und Konsi-stenzbeziehungen des gesamten Graphen beschreibenund daher nicht als Teil der Knotenklassen deklariertwerden sollten. Zum anderen sind Kanten in unseremGraphmodell bidirektional zwischen Graphelemententraversierbar, so daß eine feste Zuordnung zur Quell-(oder Ziel-)klasse willkurlich erscheint. Ein Vorteil dereigenstandigen Deklaration von Kanten ist, daß bei der(nachtraglichen) Einfuhrung weiterer Strukturbezie-hungen die zugehorigen Quell- und Zielklassendefini-tionen nicht modifiziert werden mussen.

Innerhalb von Attributberechnungsvorschriften kon-nen mit Hilfe sogenannter Pfadausdrucke auch kom-plexe Navigationen durch die Graphstruktur bzw. abge-leitete (zweistellige) Relationen spezifiziert werden.Fur die Formulierung solcher Navigationsvorschriftenstehen u.a. Konkatenation, Fallunterscheidung und Ite-ration zur Verfugung. Mehrfach verwendete Navigati-onsvorschriften konnen in benannten Pfaden verkapseltwerden. Pfade finden spater auch noch bei der Beschrei-bung graphverandernder Operationen Verwendung.

Die Speicherung der Graphen und des Graphschemaserfolgt in der Datenbank GRAS [15]. Sie sorgt fur Sche-matreue der abgelegten Graphen. Dies umfaßt sowohldie Sicherung der Grapheigenschaft, d.h. es kann zu kei-nem Zeitpunkt „hangende Kanten“ geben, weil ein Ziel-knoten geloscht wurde, als auch die Uberprufung, wel-che Attribute oder Kanten fur bestimmte Knoten zulas-sig sind. Daruber hinaus ist GRAS fur die inkrementelleAuswertung der Attributberechnungsvorschriften undPfade bei Graphmodifikationen zustandig.

Fur die Erstellung eines Graphschemas bietet diePROGRES-Umgebung sowohl eine textuelle als aucheine graphische Sicht an. In Abbildung 2 sieht man einen

Screen-Dump der PROGRES-Umgebung mit beidenSichten, die einen großeren Ausschnitt des Schemas zei-gen, zu dem unser Anwendungsbeispiel in Abbildung 1eine Instanz bildet. Das Schema kann sowohl im (linken)Textfenster als auch in der (rechten) graphischen Dar-stellung editiert werden. Dabei wird die jeweils andereAnsicht automatisch konsistent gehalten. Die graphi-sche Schema-Sicht unterstutzt eine Entity-Relation-ship-Diagramm-ahnliche Darstellung. Aus Grundender Ubersichtlichkeit fehlen in ihm die Kardinalitatsan-gaben fur Kanten und die Berechnungsvorschriften furAttribute. Diese mussen im Text-Fenster eingegebenwerden. Wird ein Schema zu komplex, so kann es zurubersichtlicheren Darstellung und Gliederung in logi-sche Abschnitte, sogenannte Sections, unterteilt werden.Diese werden in der graphischen Reprasentation jeweilsdurch eine eigene Teilgraphik dargestellt.

2.3 Spezifizieren mit Graphersetzungsregeln

Nachdem das Graphschema unseres Beispielsystemsmit Hilfe der graphischen und textuellen Darstellungeingegeben und seine Konsistenz gepruft wurde, kon-nen im nachsten Schritt die graphverandernden Opera-tionen spezifiziert werden.

Die wichtigsten Basisoperationen der Sprache PRO-GRES zur Modellierung graphverandernder Operatio-nen sind die sogenannten Produktionen oder Grapher-setzungsregeln. Mit ihnen manipuliert man den Arbeits-graphen, d.h. die aktuell bearbeitete Instanz des zuge-horigen Graphschemas. Eine Ersetzungsregel bestehtaus einer linken Seite, die den zu ersetzenden Teilgra-phen beschreibt, und einer rechten Seite, die die dafureinzusetzende Graphstruktur festlegt.

Ein einfaches Beispiel fur eine PROGRES-Produk-tion ist die Regel AddDocu in Abbildung 3, mit derGraphen des in Abschnitt 2.2 erstellten Schemas bear-beitet werden konnen. Die linke Regelseite (in der Ab-bildung oben) besteht aus einem Knoten ‘1 , der Pro-

194

Abb.2. Graphschema mit textueller und graphischer Reprasentation

grammcode reprasentiert. Der als doppelt gestrichelterKasten dargestellte Knoten ‘2 steht fur eine (mogli-cherweise leere) Menge von Knoten, die Klassen desKlassifikationsschemas reprasentieren. Bei der Anwen-dung der Regel wird im aktuellen Arbeitsgraphen einMatch der linken Regelseite gesucht. Dies kann, wiespater noch gezeigt wird, eine komplexe Suche erfor-dern. In unserem Beispiel wird jedoch der Code- Kno-ten uber den Parameter CodeJd ubergeben, der somiteinen Anker zur Teilgraphensuche im Arbeitsgraphenliefert. Von diesem gegebenen Knoten aus werdennun alle Knoten des Klasse CLASSgesucht, die mit ei-ner ref -Kante auf den Codeknoten verweisen. Diemit der linken Regelseite gefundenen Knoten werdenin diesem Beispiel bei der Anwendung der Regel iden-tisch ersetzt, d.h. sie bleiben bei der Ausfuhrung derTeilgraphersetzung im Graphen erhalten. Dies wirddurch die Knoten mit der Inschrift der Form i’ = ‘iauf der rechten Regelseite ausgedruckt. Zusatzlichwird ein neuer Knoten 3’ erzeugt, der die Dokumenta-tion fur den Programmcode darstellt und deshalb uberdie describes -Kante mit dem Knoten 1’ verbundenwird. Von den zuvor gefundenen Merkmalsklassen in2’ werden nun auch Referenzen (ref -Kanten) aufdie neue Dokumentation eingetragen. Abschließendwerden im transfer -Teil der Regel die Attributwertedes neuen Knotens gesetzt. Nach Anwendung der Re-gel wird der eben erzeugte Knoten mit Hilfe des out -Parameters DocuJd an die Aufrufstelle der Produktionzuruckgeliefert.

Neben den Ersetzungsregeln, mit denen der Graphverandert wird, bietet PROGRES Tests an. Mit ihrer Hil-fe kann man den aktuellen Arbeitsgraphen auf die Exi-stenz von bestimmten Graphmustern prufen und ent-sprechend reagieren. So konnen Graphmuster gesuchtwerden, die inkonsistenten Zustanden des spezifizierten

Systems entsprechen. Beispielsweise baut sich das Klas-sifikationsschema des Anwendungsbeispiels in Ab-schnitt 2.1 aus view- und is-Verfeinerungen auf, wobeieine klassifizierte Softwarekomponente bezuglich allerFacetten einer view-Verfeinerung klassifiziert werdenmuß. Dementsprechend liegt dann ein inkonsistenterZustand des Klassifikationssystems vor, wenn diese For-derung fur eine Softwarekomponente nicht erfullt ist. Se-mantische Eigenschaften des konkreten, spezifiziertenSystems dieser Art lassen sich nicht nur allein mit Hilfedes Graphmodells bzw. Graphschemas erfassen, sondernsie mussen explizit z. B. im Zusammenhang mit durchge-fuhrten Graphveranderungen uberpruft werden.

Abbildung 4 zeigt einen Test mit einem komplexenSuchmuster passend zur eben geschilderten Fehlersitua-tion. Der Test stellt zusatzliche Sprachmittel vor, die ins-besondere in Verbindung mit der graphischen Darstel-lung von Tests und Produktionen sehr anschaulich sind.Dies sind hier negative Kontextbedingungen, deren Be-deutung im folgenden beschrieben wird, und die bereitserwahnten Pfade.

Das Ziel des Tests ist es, Komponentenknoten imKlassifikationsgraphen zu finden, die hinsichtlich einerview-Verfeinerung nicht vollstandig spezifiziert sind.Die Teilgraphensuche, die beim Aufruf des Tests durch-gefuhrt wird, sucht also Knoten der Klasse CODE(‘1 )mit der Eigenschaft, daß man von ihnen ausgehend ei-nen CLASS-Knoten (‘2 ) uber eine Kante des Typs referreichen kann. Nun wird uber den Pfad superViewein Knoten von der Klasse VIEW gesucht, von dem dieeben gefundene Klasse eine Verfeinerung in der Merk-malshierarchie darstellt. Diese Verfeinerungsbeziehungkann sich uber mehrere Hierarchieebenen des Klassifi-kationsschemas erstrecken. Dies kann man nicht mitherkommlichen Kanten beschreiben, aber mit einementsprechend deklarierten Pfad (hier: superView )kann man genau den gewunschten transitiven Abschlußuber ruckwarts traversierte sub - und has -Kanten bil-den. Nun wird unter Benutzung des facets -Pfadeseine Facette ‘4 des View -Knotens ‘5 gesucht, zu dem

195

Abb.3. Produktion AddDocu

Abb.4. Test mit komplexem Suchmuster

der ursprungliche CODE-Knoten ‘1 nicht in Klassifizie-rungsbeziehung steht. Dies ist dann der Fall, wenn vonder Facette ‘4 selbst keine ref -Kante auf ‘1 verweist(durchgestrichene ref -Kante von ‘4 nach ‘1 ), sieselbst auch nicht Oberklasse der bereits besuchten Klas-se ‘2 ist (durchgestrichener subClass -Pfad) und auchsonst keine Unterklasse existiert, die selbst den CODE-Knoten ‘1 referenziert (durchgestrichener CLASS-Knoten ‘3 mit ref -Kante auf ‘1 ).

Wenn ein derartiges Graphmuster gefunden wird, istder entsprechende CODE-Knoten ‘1 bezuglich des Fa-cettenknotens ‘4 nicht ausreichend klassifiziert undwird uber den Ruckgabeparameter Codeld zuruckge-liefert. Im Beispielgraphen von Abbildung 1 tritt einederartige Fehlersituation nicht auf. Falls aber z. B. dieKante ref vom Knoten Public Dom . zum KnotenTkLayout nicht im Graphen existieren wurde, wareder Knoten TkLayout hinsichtlich der Facette Li-cence nicht klassifiziert.

An dieser Stelle wird nicht weiter auf die konkreteRealisierung der Pfade eingegangen, stattdessen solldie Anschaulichkeit und Ausdruckskraft der graphi-schen Formulierung des Tests und besonders der negati-ven Kontextbedingungen, d.h. Kanten und Knoten, diebei der Suche von Graphmustern im Arbeitsgraph nichtgefunden werden durfen (in Abbildung 4 durchgestri-chen dargestellt), betont werden.

Fur die Verknupfung „einfacher“ Ersetzungsregelnzu komplexen Graphtransformationen besitzt die Spra-che PROGRES eine Reihe spezieller Kontrollstruktu-ren, die die Programmierung mit Graphersetzungsregelnermoglichen. Dabei unterstutzen und berucksichtigendie Kontrollstrukturen die speziellen Eigenschaften derBasisoperationen. So ist es moglich, anhand des Ergeb-nisses eines Tests, der Anwendbarkeit einer einzelnenGraphersetzungsregel oder einer Folge von Regeln imKontrollfluß zu verzweigen. Der atomare Charakter ei-ner Ersetzungsregel bleibt dabei erhalten. Das heißt,eine komplexe Graphtransformation ist entweder alsGanzes ausfuhrbar oder sie scheitert als Ganzes, wobeieventuell bereits durchgefuhrte Graphmodifikationenzuruckgesetzt werden, um inkonsistente Zwischenzu-stande im Graphen zu vermeiden. Existieren fur eineRegel mehrere Anwendungsstellen im Arbeitsgraphen,so wird mit Tiefensuche und Backtracking solange eineAnwendungsstelle nach der anderen ausgewahlt, bisdie nachfolgenden Ersetzungen entweder ausfuhrbarsind oder keine Alternative zum Erfolg fuhrt.

Insgesamt erlauben die Kontrollstrukturen der Spra-che PROGRES die Verknupfung der nichtdeterministi-schen, deklarativen Graphersetzungsregeln zu komple-xen Transformationsablaufen. Dabei wurde großerWert auf einen fließenden Ubergang vom regelorien-tierten zum imperativen Paradigma gelegt. Dies wird in[19] und [24] ausfuhrlich beschrieben.

2.4 Die PROGRES-Entwicklungsumgebung

Bei der Spezifikation und Modellierung eines Anwen-dungssystems bietet die PROGRES-Entwicklungsum-

gebung weitreichende Werkzeugunterstutzung an, diein [24] vorgestellt wird. Der syntaxgesteuerte Editor derPROGRES-Umgebung erlaubt die komfortable Ein-gabe und Bearbeitung einer Spezifikation in gemischttextueller und graphischer Notation auf sehr hohem se-mantischen Abstraktionsniveau. Insbesondere in dengraphischen Anteilen der Sprache (und im graphischenSchemaeditor) bietet die sprachbezogene Arbeitsweisedes Editors ganz erhebliche Vorteile zum Beispiel ge-genuber der Verwendung eines allgemeinen Graphik-programms.

Der inkrementelle Analysator der PROGRES-Um-gebung fuhrt direkt wahrend der Eingabe (meist) ohnemerkliche Verzogerungen weitreichende Konsistenz-analysen durch. Aufgrund der strengen Typisierung derSprache PROGRES und der vielfaltigen Ausdrucksmit-tel des Schemateils kann so im operationalen Teil derSpezifikation schon in einer sehr fruhen Phase ein gros-ser Teil eventueller Spezifikationsfehler entdeckt undvom Spezifikator behoben werden. Fur einige Fehlerbietet die PROGRES-Umgebung sogar eine automati-sche Korrekturmoglichkeit an.

Zur direkten, interaktiven Uberprufung des opera-tionalen Verhaltens der spezifizierten Graphtransfor-mationen bietet die PROGRES-Umgebung einen Inter-preter an. Bei Bedarf wird von einem inkrementellenCompiler fur die auszufuhrenden Operationen der Spe-zifikation entsprechender Zwischencode fur eine ab-strakte Graphmaschine erzeugt. Dieser Zwischencodekann dann vom Interpreter ausgefuhrt werden. Gleich-zeitig dient der Zwischencode als Ausgangspunkt furdie Erzeugung von Modula-2- und C-Code (siehe Kapi-tel 3). Wahrend der interpretativen Ausfuhrung konnender Zustand des aktuellen Arbeitsgraphen und die Ef-fekte der ausgefuhrten Operationen von einem Graph-Browser dargestellt und vom Spezifikator uberpruftwerden. Das Zusammenspiel der einzelnen Komponen-ten ist in Abbildung 5 dargestellt.

Editor, Analysator, Compiler, Interpreter undGraph-Browser der Umgebung arbeiten verschrankt.Stellt der Spezifikator nach der Ausfuhrung einer kom-plexen Operation einen unerwarteten Effekt fest, sokann er mit Hilfe der Undo-Redo-Moglichkeiten derUmgebung die Ausfuhrung (schrittweise) bis vor diefehlerhafte Operation zurucksetzen. Mit Hilfe von ge-eigneten Einzelschrittausfuhrungs- und Ausfuhrungs-verfolgungskommandos sowie eventuell mehrfacherVorwarts-/Ruckwartsausfuhrungen kann die Fehlerstel-le genau eingekreist werden. Dann kann wahrend derInterpretersitzung direkt in der Umgebung die fehler-hafte Stelle editiert und der Fehler behoben werden.Dabei wird die geanderte Operation vom inkrementel-len Analysator der Umgebung auf Konsistenz gepruft.Anschließend kann die Operation vom inkrementellenCompiler ubersetzt und der erzeugte Zwischencodevom Interpreter erneut ausgefuhrt werden. Das heißt,die unterbrochene Interpretersitzung kann einfach fort-gesetzt und die verbesserte Operation direkt getestetwerden. Auf diese Weise konnen sehr kurze „Turn-around“-Zeiten bei der Fehlerbehebung erreicht wer-den.

196

Der gleiche Mechanismus kann aber auch zum Te-sten unterschiedlicher Realisierungsvarianten einerOperation verwendet werden. Zunachst fuhrt man dieSpezifikation bis zu der in Frage kommenden Operationaus. Durch Eingabe und Ausfuhrung unterschiedlicherVarianten uberpruft man die jeweiligen Effekte undkehrt anschließend zur Ausgangsituation zuruck, umweitere Varianten zu evaluieren. Man beachte dabei,daß das Undo der Umgebung auch beliebig lange Se-quenzen von Editoroperationen rucksetzen kann.

Verschrankung von Editieren und Ausfuhren in einerInterpretersitzung bezieht sich allerdings nicht auf An-derungen des Graphschemas, da inkrementelle Schema-anderungen fur den Arbeitsgraph noch nicht unterstutztwerden. In diesen Fallen muß die Sitzung verlassen undneu gestartet werden.

Sowohl Spezifikationen als auch Interpretersitzun-gen konnen in einem bestimmten Zustand abgespei-chert, kopiert und spater wieder geoffnet werden. FurSpezifikationen wird zudem eine Versionsverwaltungmit intelligentem Drei-Wege-Merge-Verfahren angebo-ten, vergleiche [21].

Wie dieser kurze Abriß der verschiedenen Werk-zeuge der PROGRES-Entwicklungsumgebung zeigt,bietet die Umgebung sehr weitreichende Unterstutzungfur die Spezifikation und Validierung des erstellten Mo-dells. Insbesondere die inkrementelle und verschrankteArbeitsweise der einzelnen Werkzeuge garantiert diefur das Prototyping wichtigen kurzen „Turnaround“-Zeiten. Zusammen mit den graphischen Ausdrucks-moglichkeiten und dem hohen semantischen Abstrak-tionsniveau der Sprache erlaubt das PROGRES-Systemsomit die schnelle Erstellung einer uberpruften, aus-fuhrbaren Spezifikation der internen Datenstrukturendes modellierten Anwendungssystems.

3 Prototyping des Klassifikationssystems

Dieser Abschnitt beschreibt die Generierung eigenstan-diger Prototypen auf der Basis ihrer Spezifikation. DerGenerator ist in der Lage, den vom PROGRES-Compi-ler erzeugten Zwischencode zu lesen und daraus eineImplementierung in den Sprachen Modula-2 oder C zu-sammen mit einer Tcl/Tk-Benutzeroberflache zu gene-rieren.

3.1 Ziel des Prototyping

Die Spezifikation eines Systems mit PROGRES kannverschiedene Ziele verfolgen.

Erstens lassen sich abstrakte Datentypen eines um-fangreicheren Systems spezifizieren. Der aus ihnen ge-nerierte Code kann dann als ein Baustein eines großerenGesamtsystems verwendet werden. Dies wurde im Rah-men des IPSEN-Projekts zur Generierung syntaxge-steuerter Editoren mit inkrementeller Typanalysedurchgefuhrt [9].

Zweitens kann man auch die Datenstrukturen eigen-standiger graphbasierter Anwendungen spezifizieren,fur die Prototypen generiert werden. Sie erlauben demkunftigen Benutzer – losgelost von der Entwicklungs-umgebung und den damit verbundenen Effizienzeinbu-ßen – mit einer auf ihn zugeschnittenen Benutzerober-flache zu arbeiten, und dadurch die Funktionalitat unddas interaktive Verhalten des Prototypen testen zu kon-nen. Die zugrundeliegende Graphenstruktur des Sy-stems und deren formale Spezifikation wird dabei durcheine geeignete graphische (oder besser: visuelle) inter-aktive Oberflache vor dem Benutzer verborgen.

Schließlich kann man fur sehr spezielle Anwen-dungsbereiche auch „echte“ Werkzeuge fur Endbenut-zer generieren. So lassen sich Prototypen fur kleine Da-tenbankanwendungen, wissensbasierte Systeme oderEditoren, Analysatoren und Ausfuhrungswerkzeugefur Diagrammsprachen wie die Prozeßmodellierungs-sprache GRIDS erzeugen [23].

Wir wollen an dieser Stelle nicht uber den Sinn vonPrototypen an sich diskutieren – siehe hierfur [2], [8],[12] oder [14] – sondern interessieren uns viel mehr furden automatischen Ubergang von einer Spezifikationuber den Prototyp zur fertigen Anwendung. Dies kannauf zwei Arten geschehen. Im throw-away Ansatz wirdder erstellte Prototyp weggeworfen, nachdem er seine(Un-)Tauglichkeit bewiesen hat, der evolutionare An-satz sieht hingegen seine stetige Weiterentwicklung biszur endgultigen Anwendung vor. In beiden Fallen wirdder generierte Prototyp solange verandert, bis seine Be-nutzeroberflache und seine Funktionalitat den Wun-schen und Erwartungen der Entwickler und Benutzerentspricht.

In unserem Ansatz dient der Prototyp in erster Liniedazu, das Graphmodell der Anwendung, also die inter-nen Datenstrukturen und die Operationen darauf, mitHilfe einer einfachen Benutzeroberflache interaktiv zutesten. Falls der Test Schwachen des Modells offenbart,kann die ursprungliche Spezifikation verbessert oder er-weitert und der Prototyp neu generiert werden. NachAbschluß des Tests wird der Prototyp verworfen, be-stimmte Teile des Codes konnen nun ggf. noch alsGrundlage spezieller Bausteine eines großeren Systemsverwendet werden.

Aus der Modellierung eines Anwendungssystems –wie zum Beispiel des Klassifikationssystems – lassensich sinnvollerweise verschiedene Werkzeug-Prototy-pen fur verschiedene Aufgaben und Benutzer des Sy-stems generieren, die jeweils eine passende Sicht aufden gemeinsamen Datenbestand und geeignete Ope-

197

Abb.5. Ausfuhrungs- und Generierungsprozesse

rationen darauf anbieten. So kann man sich einErfassungswerkzeug vorstellen, das den Benutzer beider Erfassung neuer Komponenten, deren Einordnungin die Merkmalshierarchie und bei der Festlegung vonBeziehungen untereinander unterstutzt. Es sollte bei-spielsweise auf die in Zusammenhang mit Abbildung 4in Abschnitt 2.3 diskutierte fehlerhafte Situation beider Einordnung bezuglich einer view-Verfeinerung auf-merksam machen. Daneben ist ein Schemaaufbauwerk-zeug notig, mit dessen Hilfe die verfeinernde Hierarchievon Merkmalen aufgebaut und erweitert werden kann.Schließlich braucht man ein Recherchewerkzeug furden eigentlichen Endbenutzer des Systems zum Wieder-auffinden von Softwarekomponenten mit bestimmtengeforderten Eigenschaften, das auf die Abhangigkeitvon anderen Softwarepaketen, Lizenzbestimmungenund Dokumentation hinweist.

Wir gehen bei der Generierung eines Prototypen voneiner Rahmenarchitektur fur interaktive Systeme ausund legen großen Wert auf eine klare Trennung verschie-dener Schichten mit wohldefinierten Schnittstellen. Soist es moglich, einzelne Komponenten auszutauschenoder zu verfeinern, ohne dabei die Gesamtstruktur zubeeinflussen. Der Aufbau des Systems ist in Abbildung 6dargestellt, wobei allein die schattierten Bausteine ausder gegebenen Spezifikation generiert werden.

Aufsetzend auf unserer Graphdatenbank GRAS,vergleiche [15], wird im Laufzeitsystem der inharenteNichtdeterminismus der Sprache PROGRES behan-delt. Hinzu kommen auf dieser Ebene die Basisbau-steine des verwendeten Benutzeroberflachen-ToolkitsTcl/Tk, zusammen mit der direkten Anbindung an dieDatenbank (Graph-Browser). Die Benutzeroberflachedes Prototyps ist weitgehend spezifikationsunabhangig,nur ein kleiner Teil wird aus der konkreten Spezifika-tion erzeugt. Trotzdem der Prototyp nur eine interak-tive Testumgebung fur die Spezifikation darstellt, legenwir großen Wert auf Erweiterbarkeit und Anpaßbarkeitseiner Oberflache und Funktionalitat. Auf die einzelnenKomponenten der Rahmenarchitektur wird im folgen-den noch naher eingegangen.

3.2 Generierung der Grundfunktionalitat

Fur beliebige Teile einer PROGRES-Spezifikationkann semantisch aquivalenter Modula-2- oder C-Codeerzeugt werden. Zu diesem Zweck hat jeder Befehl derabstrakten Graphmaschine eine Methode, die eine Fol-ge von Befehlen der entsprechenden Zielsprache er-zeugt. Diese Befehle sind im wesentlichen Schnittstel-lenoperationen der Datenbank. Dabei stellt sich dasProblem, die Reihenfolge der Anfragen so zu wahlen,daß die Abarbeitung durch die Datenbank effizient ge-schehen kann. Mogliche Vorgehensweisen dazu werdenin [24] vorgestellt.

Um eine eventuelle manuelle Nachbearbeitung oderdas Debuggen des generierten Systems zu erleichtern,wird im generierten Code viel Wert auf sinnvolle Na-mengebung gelegt und jede PROGRES-Operation aufeine entsprechende Prozedur abgebildet. Zusatzlichwird die Originalspezifikation (in textueller Darstel-lung) als Kommentar in den generierten Code uber-nommen. Bei Bedarf ist es deshalb moglich, einzelneProzeduren, zum Beispiel aus Effizienzgrunden, manu-ell nachzubearbeiten oder vollstandig durch eine andereImplementierung zu ersetzen. Denkbar ist auch die Pro-grammierung von Benutzerein-/ausgaben oder Be-triebssystemzugriffe, die in PROGRES selbst nicht(oder nur umstandlich) formuliert werden konnen.

Der Generator der PROGRES-Umgebung generiertden Applikations-Code, d.h. den Code fur die Grund-funktionalitat des spezifizierten Systems. Dies kann alsvollstandige Implementierung aller seiner Operationenoder nur fur bestimmte Bereiche einer Spezifikation ge-schehen. Dies ermoglicht die Realisierung mehrererSichten auf ein System, indem verschiedene Operatio-nen fur verschiedene Anwendergruppen zur Verfugunggestellt werden, die alle auf demselben Datenbestandarbeiten. Der Datenbestand wird zentral in der Daten-bank verwaltet. Entsprechend der in Abbildung 6 vor-gestellten Standardarchitektur stutzt sich der Applika-tions-Code jedoch nicht direkt auf der Datenbank absondern auf der PROGRES-Laufzeitumgebung. Sie er-laubt dem Benutzer Backtracking, d.h. zur Laufzeitwird der Kontrollfluß zuruckgesetzt, alte Variablenwer-te werden wiederhergestellt und Graphveranderungenruckgangig gemacht. Um Backtracking zu ermoglichen,werden wahrend der Ausfuhrung Sicherungspunkte inder Datenbank gesetzt und zur Rucksetzung genutzt.

3.3 Graphische Benutzerschnittstelle

Der Code-Generator der PROGRES-Umgebung wur-de zum Prototyping um die Moglichkeit zur Generie-rung einer einfachen graphischen Benutzeroberflacheerweitert. Sie besteht aus verschiedenen Komponenten,die aber nur zum Teil von der Spezifikation abhangigsind. Die angebotene Grundfunktionalitat gliedert sichin das Hauptfenster, das den aktuellen Arbeitsgraphendarstellt und das Menu anbietet, das Protokollfenster,das uber die ausgefuhrten Aktionen Auskunft gibt unddie Dialogboxen, die dem Benutzer die Eingabe von Pa-

198

Abb.6. Aufbau der generierten Prototypen

rametern fur die aufrufbaren Operationen ermoglichen.Das Variablenfenster zeigt die aktuelle Belegung der be-nutzerdefinierbaren Prototyp-Variablen an. Die Varia-blen dienen dem komfortablen Umgang mit den ange-botenen Operationen, indem man ihre Ruckgabewertezwischenspeichern und in das Dialogfenster andererOperationen weitergeben kann. Das Menu und das Va-riablenfenster sind parametrisierte Bausteine, die wah-rend der Generierung des Prototypen an die konkreteSpezifikation angepaßt werden.

Abbildung 7 zeigt ausschnittsweise zwei verschie-dene generierte Prototypen fur das Klassifikationssy-stem – wie es in Abbildung 1 vorgestellt wurde – wah-rend der Ausfuhrung. Die beiden Prototypen unter-scheiden sich durch verschiedene Sichten desselben Da-tenbestandes in den Anzeigefenstern der Graphen. DasFenster oben links bildet den Arbeitsplatz Komponen-tenerfassung, der auch die entsprechenden Operationenin den Menus Reference und Analyse anbietet. Sosollen neue Codekomponenten und Dokumentationenbezuglich der vorhandenen Merkmalshierarchie erfaßtwerden. Im oben rechts gezeigten Dialog wird geradeeine neue Softwarekomponente eingetragen, die den(in der Graphanzeige markierten) MerkmalsklassenToolkit und Layout zugeordnet wird. Zusatzlich be-kommt der Erfasser Unterstutzung im Hinblick auf ver-saumte Einordnungen wie in der Erlauterung des Testsin Abbildung 4 beschrieben.

In Abbildung 7 unten rechts sieht man die Sichtweisedes Endbenutzers, der Anfragen an das System stellt.

Das Menu Query im Fenster des Recherchewerkzeugsbietet Operationen, um Komponenten zu finden, diemoglichst viele seiner geforderten Eigenschaften erful-len. Hier wird nach den Komponenten gesucht, die zurMerkmalsklasse Layout gehoren und tk/tcl alsSchlusselwort haben. Die aktuelle Belegung der benut-zerdefinierbaren Variablen nach Ausfuhrung der An-frage ist im Global/Variables -Fenster zu sehen.Das Feld ComponentJds enthalt als Resultat die Kno-tennummern der zur gestellten Anfrage passendenKomponenten. Im Gegensatz zum Erfasser spielen furdiesen Benutzer die erfaßten Komponenten des Sy-stems zunachst keine Rolle, erst wenn er eine Anfragestellt, will er die entsprechenden Komponente gezeigtbekommen. Dies kann durch eine flexible Sichtenge-staltung auf Typ- und Instanzebene gesteuert werden.

Zur Realisierung der graphischen Benutzeroberfla-che verwenden wir – hauptsachlich wegen der freienVerfugbarkeit, weiten Verbreitung und der leichten Er-weiterbarkeit und Adaptierbarkeit – die Sprache Tclund das dazugehorige Benutzeroberflachen-Toolkit Tk[17]. Mit ihrer Hilfe sind die allgemeinen Bausteine derBenutzeroberflache implementiert.

Zusatzlich erzeugt ein Teilgenerator spezifikations-abhangige Tcl/Tk-Fragmente, die in das System einge-bunden werden. So werden fur alle Operationen, die derBenutzer des Prototyps direkt aufrufen konnen soll, ent-sprechende Menu-Eintrage erzeugt. Welche Operatio-nen zur Benutzeroberflache beitragen, wird bei der Ge-nerierung durch Aus- oder Einblenden logischer Ab-

199

Abb.7. Sichten verschiedener Prototypen des Klassifikationssystems

schnitte der Spezifikation vorgegeben. Fur alle Opera-tionen der Benutzeroberflache, die Ein- oder Ausgabe-parameter besitzen, werden zusatzlich Dialogmaskengeneriert, mit denen Aktualparameterwerte fur den Auf-ruf der Operationen eingegeben werden konnen. DieseParameter konnen uber die benutzerdefinierbaren Va-riablen miteinander gekoppelt werden. So konnen dieAktualparameter einer Operation, die Ergebniswerteanderer Operationen weiterverwenden, automatischuber ein passend benanntes Variablenfeld versorgt wer-den. Im Global/Variables- Fenster des Prototypskann der aktuelle Wert der Variablen auch direkt editiertwerden. Die Werte dieser Variablen werden dann beimAufruf einer Operation in die Maskenfelder fur die ent-sprechend benannten Parameter ubernommen.

Die Darstellung des Arbeitsgraphen im Prototypenist abhangig von den Attributwerten seiner Knoten.Die inkrementelle Neuberechnung der abgeleiteten At-tribute ermoglicht eine sich standig anpassende Prasen-tation des Graphen. Beispielsweise kann die Knotenin-schrift direkt an ein (abgeleitetes) Attribut gekoppeltwerden. Wie in Abbildung 7 zu sehen ist, kann man den-selben Mechanismus auch dazu nutzen, bestimmte Kno-ten durch passende Icons darzustellen, deren Name ei-nem vom Benutzer angegebenen Knotenattribut zu ent-nehmen ist. Zukunftig wird auch das bislang vollauto-matische Layout des Graphen durch ein halb manuellesund halb automatisches Layout ersetzt werden, das aufden Werten entsprechender Attribute der dargestelltenKnoten basiert.

Das von PROGRES unterstutzte Prototyping gehtuber die Generierung einzelner, isoliert arbeitender Pro-totypen hinaus. Aus einer Spezifikation konnen – wie ge-sehen – unterschiedliche Werkzeuge erstellt werden, diemit geeigneten Operationen auf demselben Datenbe-stand arbeiten konnen. Die entsprechende Sichtenbil-dung wird durch folgende Maßnahmen unterstutzt:• Wie bereits zuvor erwahnt, kann man bereits bei der

Generierung die Operationen auswahlen, fur dieCode erzeugt werden soll.

• Zusatzlich konnen sowohl auf Typ- als auch aufInstanzebene bestimmte Graphstrukturen von derAnzeige in einem Werkzeug ausgeschlossen werden.

• Schließlich kann man naturlich auch die angeboteneArbeitsgraphanzeige aufgrund der wohldefiniertenSchnittstelle durch eine vollig anders geartete Benut-zeroberflache ersetzen.

Das somit angebotene View-Konzept beruht also aufdem Verbergen von Strukturen und Operationen. Zu-sammen mit der Moglichkeit zur deklarativen Defini-tion abgeleiteter Grapheigenschaften und ihrer inkre-mentellen Konsistenzhaltung entspricht die angeboteneFunktionalitat durchaus dem Stand der Technik.

3.4 Datenhaltung

Die eigenstandigen Prototypen stutzen sich, wie diePROGRES-Entwicklungsumgebung selbst, auf dergraphorientierten Nichtstandard-Datenbank GRAS

[15] ab. Diese basiert auf einer Client/Server-Architekturund erlaubt verschiedene Formen des Mehrbenutzerbe-triebs.

Zunachst bietet GRAS die ublichen Datenbankei-genschaften an:• persistente Datenspeicherung,• sperrbaren parallelen Zugriff,• geschachtelte kurze Transaktionen und• Recovery-Moglichkeiten nach Systemabsturzen.

Die Fahigkeiten von GRAS gehen noch daruber hinaus.Events sorgen dafur, daß alle laufenden Anwendungenvon Anderungen im Graphzustand benachrichtigt wer-den und somit in allen Anwendungen immer der aktu-elle Graph bearbeitet wird. So konnen im Beispielgleichzeitig neue Merkmale eingefuhrt werden, wah-rend mehrere Benutzer mit dem Komponentenrecher-chewerkzeug arbeiten. Zudem ist GRAS fur die inkre-mentelle Auswertung abgeleiteter Attribute zustandigund bietet zur Unterstutzung der nichtdeterministi-schen Operationen in PROGRES Checkpoints an. MitHilfe der Undo/Redo-Funktionalitat kann man so zwi-schen den Checkpoints hin- und herspringen und damitbeliebig lange Sequenzen graphverandernder Operatio-nen zurucksetzen. Das Zusammenwirken von (langen)Transaktionen, Events und Undo/Redo ist Gegenstandunserer momentanen Forschungsaktivitaten.

Weiterhin beschaftigt uns die Idee, die Prototypenauch losgelost von der Datenbank – also als Hauptspei-chervarianten – einsetzen zu konnen. Einerseits werdendie Anwendungen dadurch wesentlich schlanker undschneller, andererseits opfert man einige Eigenschaften,die man durch die Verwendung einer geeigneten Daten-bank „geschenkt“ bekommt.

4 Vergleich und Ausblick

In den vorangegangenen Abschnitten haben wir dieSprache PROGRES und ihre Entwicklungsumgebungvorgestellt. Dabei haben wir unser Augenmerk auf dieEigenschaften der Sprache und ihrer Werkzeuge gerich-tet, die sie fur die operationale Spezifikation grapharti-ger Datenstrukturen und das Prototyping darauf aufbau-ender interaktiver Testwerkzeuge pradestinieren. Dasverwendete Beispiel eines Softwareklassifikationssy-stems war besonders gut geeignet,• die Modellierung von Graphstrukturen und die Defi-

nition abgeleiteter Attribute• sowie die regelorientierte Programmierung komple-

xer Graphtransformationsprozesse

mit PROGRES darzustellen. Etwas vernachlassigt wur-den dabei allerdings die Bestandteile der Sprache, diedie deklarative Festlegung abgeleiteter Relationen er-lauben, sowie der Kontrollstrukturanteil, der das ge-mischt regelorientierte/imperative Programmieren un-terstutzt. Eine ausfuhrliche Beschreibung dieserSprachanteile findet der Leser in [24].

Bereits in der Einleitung haben wir das Verhaltnisvon PROGRES zu formalen Spezifikationssprachen

200

und zu Prototypingsprachen kurz diskutiert. Den zwei-ten Teil dieser Diskussion wollen wir hier noch einmalaufgreifen und PROGRES solchen Prototypingspra-chen gegenuber stellen, die demselben Anwendungsbe-reich zuzuordnen sind: Beschreibung sequentieller Ab-laufe auf komplex strukturierten Sachverhalten. Dabeiwerden wir uns wieder auf einige „klassische“ Vertreterbeschranken und insbesondere (noch) nicht weitver-breitete multiparadigmatische Sprachen oder graphi-sche Datenbanksprachen nicht berucksichtigen (siehehierzu [19]).

Tabelle 1 gibt einen Uberblick uber einige hier beson-ders interessante Spracheigenschaften und soll dem Le-ser einen abschließenden Eindruck von den Vor- undNachteilen der Sprache PROGRES verschaffen. Beson-dere Beachtung verdienen dabei die folgenden Punkte:• Mustersuche: Im Vergleich zur regelorientierten Spra-

che OPS-5 ist PROGRES nicht in der Lage, gleichzei-tig nach Anwendungsstellen mehrerer Regeln zu su-chen, es verwendet aber eine Vielzahl von Heuristi-ken bei der Teilgraphensuche fur ein gegebenesGraphmuster.

• Abgeleitete Fakten: PROGRES ist die einzige aufge-fuhrte Sprache, die die inkrementelle Berechnung ab-geleiteter Attribute und Relationen unterstutzt.

• Backtracking: PROGRES kann im Zuge des Back-tracking nicht nur Variablenbindungen auflosen, son-dern alte Variablenwerte und vor allem alte Graphzu-stande wieder restaurieren.

Diese Eigenschaften der PROGRES-Implementationberuhen im wesentlichen auf entsprechenden Eigen-schaften des zugrundeliegenden DatenbanksystemsGRAS. Ihm verdanken generierte Prototypen auchihre (eingeschrankte) Mehrbenutzerfahigkeit, die Persi-stenz ihrer Datenstrukturen und ihre Recovery-Fahig-keit nach Systemabsturzen.

Aktuelle Forschungsschwerpunkte auf der Seite derPrototyp-Generierung betreffen die Verbesserung derinteraktiven Moglichkeiten zur Umgestaltung der gene-rierten Oberflache, zum Beispiel textuelle bzw. tabella-rische Darstellung des Graphen oder die Ausnutzung

bestimmter Knotenattribute zur Prasentation. Außer-dem ist eine Kombinaton des generierten Prototypenmit Toolkits zur Erstellung von interaktiven Benutzer-oberflachen wunschenswert, da wir mit unserem Gene-rierungsmechanismus den Schwerpunkt eher auf dieDarstellung und Manipulation der komplex strukturier-ten Fensterinhalte legen.

Auf der Seite der Spezifikation ist die Einfuhrungeines Modulkonzepts in PROGRES wesentlich, umdie Spezifikationen selbst handlicher zu machen undgerade auch zum Prototyping fur verschiedene Benut-zer spezielle Schnittstellen zu einer Spezifikation anzu-bieten. Weiterhin wollen wir mit dem Austausch desbislang verwendeten Graphmodells durch ein hierar-chisches Graphmodell komplexe Knotenattribute miteigenem Innenleben ermoglichen. Außerdem soll dieMoglichkeit zur Formulierung von Integritatsbedingun-gen dazu beitragen, daß die Einhaltung konsistenterZustande des modellierten Systems automatisch ge-wahrleistet ist und nicht mehr – wie in Abschnitt 2.3beschrieben – umstandlich durch den Spezifikatorselbst gepruft werden muß. Schließlich bedarf dasWechselspiel zwischen Backtracking einzelner Anwen-dungen, dem von GRAS unterstutzten Mehrbenutzer-betrieb und der Synchronisation der dargestelltenGraphzustande in verschiedenen Anwendungen durchTrigger & Event-Mechanismen weiterer Untersuchun-gen.

Die PROGRES-Umgebung ist hauptsachlich in Mo-dula-2 geschrieben, umfaßt zur Zeit ca. 500 000 ZeilenCode und steht als „Free Software“ fur Sun Workstati-ons zur allgemeinen Verfugung. Weitere Informationenzur aktuellen Version findet man im „world wide web“unter:http://www-i3.informatik.rwth-aachen.de/research/progres/index.html

Literatur

1. Borstler, J.: Programmieren-im-Großen: Sprachen Werkzeuge,Wiederverwendung, Dissertation, RWTH Aachen (1993)

201

Tabelle 1. Ausgewahlte Eigenschaften klassischer VHL-Sprachen

PROGRES [19] SETL [8] Prolog [5] OPS-5 [16] ML [13] Smalltalk [10]

Datenmodell AttributierteGraphen

Mengen n-stellige Rela-tionen

Attributlisten Terme u. Funk-tionen

AttributierteObjekte

Programmier-Paradigma

regelorientiertund imperativ

imperativ logikorientiert regelorientiert funktional objektorientiert

Typkonzept polymorph undobligate Dekl.

Laufzeittestsu. opt. Dekl.

kein Typkonzept kein Typkonzept polymorphu. Typinferenz

Laufzeittests

Zustandsraum Graph Variablen Faktenbasis Faktenbasis – Objekthalde

Mustersuche Heuristikenfur eine Regel

– – RETE-Netz furRegelmenge

– –

AbgeleiteteFakten

inkr. berechn. Attr.und Relationen

– Batch-Inferenzvon Relationen

– – –

Backtracking implizitkontrolliert

explizitkontrolliert

implizit und¬ Faktenbasis

– – –

Konkr. Syntax Grafik/Text Text Text Text Text Text

2. Budde, R.; Kuhlenkamp, K.; Mathiassen, L.; Zullighoven, H.:Approaches to Prototyping. Berlin Heidelberg New York:Springer 1984

3. Coleman, D.; Arnold, P.; Bodoff, S.; Dollin, C.; Gilchrist, H.;Hayes, F.; Jeremes, P.: Object-oriented development: the fusionmethod. London: Prentice Hall 1993

4. CIP Language Group: The Munich Project CIP, vol. 1, LNCS183. Berlin Heidelberg New York: Springer 1985

5. Clocksin, W. F.; Mellish, C.S.: Programming in Prolog, 3rd re-vised and extended edn. Berlin Heidelberg New York: Springer1987

6. DeMarco, T.: Structured analysis and system specification. NewYork, NY: Yourdon Press 1979

7. Diller, A.: An introduction to formal methods. New York, NY:Wiley 1992

8. Doberkat, E.-E.; Fox, D.: Software prototyping mit SETL.Stuttgart: Teubner 1989

9. Engels, G.; Lewerentz, C.; Nagl, M.; Schafer, W.; Schurr, A.:Building integrated software development environments.Part 1: Tool specification. ACM Transactions on Software En-gineering and Methodology, vol. 1(2), pp.135–167. New York,NY: ACM Press 1992

10. Goldberg, A.: Smalltalk-80: The language and its implementa-tion. Reading, MA: Addison-Wesley 1983

11. Guttag, J.V.; Horning, J. J.: Larch: Languages and tools for for-mal specification. Berlin Heidelberg New York: Springer 1993

12. Hallmann, M.: Prototyping komplexer Softwaresysteme. Stutt-gart: Teubner 1990

13. Harper, R.; Milner, R.; Tofte, M.: The Definition of StandardML. Cambridge, MA: MIT Press 1990

14. Hasselbring, W.: Formale Spezifikation und Prototyping imSprachentwurf – Eine Fallstudie. Informatik Forsch. Entw. 9,132–140 (1994)

15. Kiesel, N.; Schurr, A.; Westfechtel, B.: GRAS, A Graph-Ori-ented (Software) Engineering Database System. InformationSystems, vol. 20 (1), pp.21–52. Oxford: Pergamon Press 1995

16. Krickhahn, R.; Radig, B.: Die WissensreprasentationsspracheOPS-5. Braunschweig: Vieweg 1987

17. Ousterhout, J.: Tcl and the Tk Toolkit. Reading, MA: Addison-Wesley 1994

18. Rumbaugh, J.; Blaha, M.; Premerlani, W.; Eddy, F.; Lorensen,W.: Object-oriented modeling and design. Englewood Cliffs,NJ: Prentice Hall 1991

19. Schurr, A.: Operationales Spezifizieren mit programmiertenGraphersetzungssystemen. Dissertation, RWTH Aachen.Wiesbaden: Deutscher Universitats-Verlag 1991

20. Schurr, A.; Winter, A.; Zundorf, A.: Spezifikation und Proto-typing graphbasierter Systeme. GI-Fachtagung Softwaretech-nik, Braunschweig (1995)

21. Westfechtel, B.: Revisionskontrolle in einer integrierten Soft-wareentwicklungsumgebung. Dissertation, RWTH Aachen,IFB 280. Berlin Heidelberg New York: Springer 1991

22. Yourdon, E.: Modern structured analysis. New York, NY: Your-don Press 1989

23. Zamperoni, A.: GRIDS – Graph-based, Integrated Develop-ment of Software: Integrating different perspectives of soft-ware engineering. Proc. of the 18th International Conferenceon Software Engineering, Berlin, pp.48–59 (1996)

24. Zundorf, A.: Eine Entwicklungsumgebung fur PROgram-mierte GRaphErsetzungsSysteme, Dissertation, RWTH Aa-chen. Wiesbaden: Deutscher Universitats-Verlag 1996

202

Andy Schurr, Studium der Informa-tik mit Nebenfach Mathematik ander TU Munchen (1980–1986). Seit1986 wissenschaftlicher Mitarbei-ter/Assistent am Lehrstuhl fur In-formatik III (Softwaretechnik) derRWTH Aachen, Promotion 1991.Forschungsaufenthalte an der Rijks-universiteit Leiden, Queen’s Uni-versity Kingston.

Forschungsschwerpunkte: Soft-wareentwicklungsumgebungen,Graphgrammatiken, Nicht-Stan-dard-Datenbanken, visuelle Pro-grammiersprachen, OO-Modellie-rung.

Andreas J. Winter, Studium der In-formatik mit Nebenfach Mathema-tik an der Universitat Passau(1987–1993). Seit 1994 als wissen-schaftlicher Mitarbeiter am Lehr-stuhl fur Informatik III (Software-technik) der RWTH Aachen.

Forschungsschwerpunkt: Ein-satz und Weiterentwicklung vonGraphersetzungssystemen.

Albert Zundorf, Studium der Infor-matik mit Nebenfach Physik an derRWTH Aachen (1984–1990). Ab1990 wissenschaftlicher Mitarbeiteram Lehrstuhl fur Informatik III(Softwaretechnik) der RWTH Aa-chen, Promotion 1995. Seit 1995wissenschaftlicher Assistent in derAG-Softwaretechnik an der Uni-versitat-GH-Paderborn.

Forschungsschwerpunkt: Reen-gineering.