Revisions- und Konsistenzkontrolle in einer integrierten Softwareentwicklungsumgebung

328 Pages·1991·8.826 MB·German

by  Bernhard Westfechtel (auth.)

Informatik-Fachberichte 280
Herausgeber: W. Brauer
im Auftrag der Gesellschaft fOr Informatik (GI)
Bernhard Westfechtel
Revisions- und
Konsistenzkontrolle in einer
integrierten
Software~
entwickl un gsu mgebu ng
Q.~ Springer-Verlag
~ Berlin Heidelberg New York London Paris
- ~ Tokyo Hong Kong Barcelona Budapest
Autor
Bernhard Westfechtel
Lehrstuhl fOr Informatik III, RWTH Aachen
Ahornstr. 55, W-5100 Aachen
o
82 (Oiss. TH Aachen)
CR Subject Classification (1991): 0.2.6,0.2.7,0.2.9, F.3.1
ISBN-13: 978-3-540-54432-6 e-ISBN-13: 978-3-642-76870-5
DOl: 10.1007/978-3-642-76870-5
Dleses Werk ist urheberrechtllch geschOtzt. Die dadurch begriindeten Rechte. insbesondere
die der Obersetzung, des Nachdrucks, des Vortregs, der Entnahme von Abblldungen und Ta
bellen, der Funksendung, der Mikroverfilmung oder der Vervlelflltigung auf anderen Wegen und
der Speicherung in Datenvererbellungsenlagen, blelben, bei auch nur auszugsweiser Verwer
tung, vorbehalten. Elne Vervielflltlgung dleses Werkes oder von Tellen dieses Werkes ist auch
1m Elnzellall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes
der Bundesrepublik Deutschland vom 9. September 1965 In der jewells geltenden Fassung
zullssig. Sie ist grundsltzlich vergOlungspfllchlig. Zuwlderhandlungen unterllegen den Straf
bestlmmungen des Urheberrechtsgesetzes.
e Springer-Verlag Berlin Heidelberg 1991
Satz: Reproduktionslartlge Vorlage yom Autor
33/3140-543210-Gedruckt auf slurefreiem Papier
Danksagung
Bei diesem Buch handelt es sich urn die uberarbeitete Fassung meiner Dissertation, die im
Rahmen des IPSEN-Projekts uber strukturbezogene, integrierte Softwareentwicklungsum
gebungen entstanden ist und unter dem Titel "Revisionskontrolle in einer integrierten Soft
wareentwicklungsumgebung" an der Rheinisch-Westfalischen Technischen Hochschule Aa
chen angenommen wurde.
Der Dank des Autors gilt vor allen anderen dem Initiator und Leiter des IPSEN-Projekts,
Prof. Dr. Nagl, der die Arbeit betreut und jederzeit mit groBem Interesse verfolgt hat. Seine
groBe Diskussionsbereitschaft und seine vielen konstruktiven Anregungen haben maBgeb
Iich zum Gelingen dieser Arbeit beigetragen.
Ferner danke ich dem Zweitgutachter, Prof. Dr. Kreowski, der die Muhe nicht gescheut hat,
fur diese doch recht umfangreiche Arbeit ein kompetentes Gutachten zu erstellen.
Mein Dank gilt weiterhin allen - jetzigen und auch ehemaligen - Kollegen, die mir in vielen
Diskussionen wertvolle Anregungen gegeben haben. Besonders hervorzuheben ist hier Andy
Schurr, der uber lange Jahre hinweg als standiger Diskussionspartner zur VerfUgung stand
und bei vielen Gesprachen zwischen Tur und Angel wertvolle und konstruktive Kritik ubte.
Insbesondere durch die Entwicklung der Spezifikationssprache PROGRESS, die von mir
extensiv benutzt wurde, hat er dazu beigetragen, daB die Arbeit eine handfeste Gestalt
annehmen konnte. Weiterhin danke ich auch Claus Lewerentz, dessen Dissertation den
Ausgangspunkt fur meine Uberlegungen bildete und der in der Anfangsphase der Arbeit als
kompetenter Gesprachspartner eine uberaus wertvolle Hilfe war. Ferner danke ich Martin
Lefering und Albert Zundorf, die Teile der Arbeit Korrektur gelesen haben.
Dariiber hinaus bin ich auch den Diplomanden und Programmiererinnen, die sich bei der
Implementierung von Werkzeugen auBerordentlich engagiert haben, zu groBem Dank ver
pflichtet. Hier sind zu nennen: Michael Broekmans, Ursula Cordts, Marita Lischewski. Gerd
Metzen, Peter Heimann und Cornelia Weigmann.
SchlieBlich danke ich meinen Eltern und meiner Schwester fUr die moralische Unterstutzung,
die sie mir in den letzten Jahren - und natiirlich auch vorher - gegeben haben. Meiner
Freundin Monika danke ich fur das Verstandnis, das sie insbesondere in der Endphase der
Arbeit aufgebracht hat.
Aachen, im Juni 1991
Zusammenfassung
Dieses Buch ist im Rahmen des IPSEN-Projekts entstanden, das sich mit integrierten,
strukturbezogenen Softwareentwicklungsumgebungen befaBt. Es beschaftigt sich zum einen
mit der Revisionskontrolle, d.h. der Kontrolle der zeitlichen Entwicklung von Softwaredoku
menten (Anforderungsdefinitionen, Architekturen, Modulimplementationen etc.). 1m Ver
lauf ihrer Lebensgeschichte durchlaufen Dokumente beziiglich ihres Inhalts nacheinander
verschiedene Zustande, weil Fehler beseitigt werden, Optimierungen vorgenommen werden
etc. Solche Zustande werden als Revisionen bezeichnet. Die Revisionskontrolle ist insbeson
dere bei der Wartung komplexer Softwaresysteme von herausragender Bedeutung.
Zum anderen befaBt sich dieses Buch mit der Konsistenzkontrolle. Die Dokumente eines
Softwaresystems sind nicht voneinander unabhangig, sondern zwischen ihnen bestehen enge
inhaltliche Beziehungen. Beispielsweise werden in der Architektur eines Softwaresystems
Modulschnittstellen festgelegt, die bei der Ausprogrammierung der Modulimplementatio
nen zu beach ten sind, und die technische Dokumentation eines Softwaresystems muB Anfor
derungsdefinition, Architektur und Modulimplementationen korrekt beschreiben. Urn diese
externe Konsistenz abhangiger mit bestimmenden Dokumenten zu gewahrleisten, muB der
Softwareentwickler durch geeignete Werkzeuge unterstiitzt werden. Dabei ist insbesondere
zu beriicksichtigen, daB die Dokumente jeweils in verschiedenen Revisionen existieren und
somit verwaltet werden muB, welche Revisionen sich konsistent kombinieren lassen.
In diesem Buch wird ein formaler Ansatz zur Revisions-und Konsistenzkontrolle dargestellt,
der sich durch folgende Eigenschaften auszeichnet:
• Einheitliches formales Datenmodell. Die Revisions-und Konsistenzkontrolle beruht auf
einem einheitlichen formalen Datenmodell, namlich gerichteten, markierten und attribu
tierten Graphen. Zur formalen Spezifikation von Werkzeugen werden programmierte
Graphersetzungssysteme verwendet.
• Strukturbezogenheit. Die Werkzeuge zur Revisions- und Konsistenzkontrolle selbst
arbeiten strukturbezogen, und sie sind mit anderen, ebenfalls strukturbezogenen Werk
zeugen integriert.
• Dokumenttypunabhangigkeit. Die Werkzeuge zur Revisions- und Konsistenzkontrolle
werden so weit wie moglich von den Typen der Dokumente unabhangig gehalten, deren
Verwaltung unterstiitzt wird. Dadurch wird erreicht, daB die Werkzeuge sich allgemein
einsetzen lassen.
• Arbeitsbereichsiibergreifende Integration von Aktivitaten. Die Integration von Aktivita
ten, die verschiedenen, voneinander abhangigen Arbeitsbereichen (Programmieren im
GroBen, Programmieren im Kleinen etc.) zuzuordnen sind, beschrankt sich nicht auf
Konsistenzanalysen, sondern es werden Vorgaben erzeugt und abbangige Revisionen
angepaBt, nachdem bestimmende Revisionen geandert worden sind.
Inhaltsverzeichnis
1 Motivation und Zielsetzung .................................. 1
1.1 Unterstiitzung der Softwareerstellung durch Werkzeuge . . . . . . . . . . . . . . . . 1
1.2 Konfigurationsverwaltung: Bedeutung und Unterstiitzung .............. 5
1.3 Werkzeuge zur Revisions- und Konsistenzkontrolle in IPSEN . . . . . . . . . . . 9
1.4 Kapiteliibersicht ................................................ 16
2 Ein Ansatz zur Revisions- und Konsistenzkontrolle in IPSEN . . . .. 18
2.1 Modellierung der Revisions- und Konsistenzkontrolle
auf der grobkornigen Ebene ...................................... 18
2.2 Modellierung der Revisionskontrolle auf der feinkornigen Ebene . . . . . . .. 26
2.3 Modellierung der Konsistenzkontrolle auf der feinkornigen Ebene ...... 34
2.4 Realisierung der Revisions- und Konsistenzkontrolle . . . . . . . . . . . . . . . . .. 42
2.5 Zusammenfassung .............................................. 48
3 Andere Ansatze zur Konfigurationsverwaltung .................. 50
3.1 Grundbegriffe .................................................. 50
3.2 Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 63
3.3 Zusammenfassung .............................................. 86
4 Modellierung der Revisions- und Konsistenzkontrolle
auf der grobkornigen Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 88
4.1 Modellierung der statischen Struktur ............................... 89
4.1.1 Bestandteile von Revisionsgraphen ............................ 89
4.1.2 Konsistenzbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 93
4.1.3 Szenariospezifische Aspekte .................................. 105
4.1.4 Erweiterungen ............................................. 106
4.2 Modellierung von Veranderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 111
4.2.1 Szenariounabhangige Basisoperationen . . . . . . . . . . . . . . . . . . . . . . . .. 113
4.2.2 Szenariounabhangige komplexe Operationen .. . . . . . . . . . . . . . . . . .. 127
4.2.3 Szenariospezifische komplexe Operationen ...................... 144
4.3 Literaturvergleich ............................................... 146
4.4 Zusammenfassung und Ausblick ................................... 157
5 Verfeinerung des grobkornigen Modells der
Revisions- und Konsistenzkontrolle ........................... 159
5.1 Verfeinerung der Struktur von Revisionsgraphen ...................... 159
5.2 Verfeinerung grobkorniger Operationen auf Revisionsgraphen .......... 166
5.2.1 Szenariounabhangige Basisoperationen ......................... 166
5.2.2 Szenariounabhangige komplexe Operationen . . . . . . . . . . . . . . . . . . .. 172
5.3 Literaturvergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 177
5.4 Zusammenfassung und Ausblick ................................... 180
x
6 Modellierung der Konsistenzkontrolle auf der feinkornigen Ebene . 181
6.1 Normierte EBNF's und abstrakte Syntaxgraphen ..................... 181
6.2 EBNF-Korrespondenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 187
6.3 Ein inkrementeller Transformator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 194
6.3.1 Ein Beispiel ............................................... 195
6.3.2 Prinzipien der inkrementellen Transformation ................... 200
6.3.3 Formale Spezifikation ....................................... 204
6.4 Literaturvergleich ............................................... 214
6.5 Zusammenfassung und Ausblick ................................... 219
7 Modellierung der Revisionskontrolle auf der feinkornigen Ebene .. 221
7.1 Kontextfreies Verschmelzen ....................................... 221
7.1.1 Pramissen und Prinzipien .................................... 221
7.1.2 Formale Spezifikation ....................................... 227
7.1.3 Probleme ................................................. 241
7.2 Kontextsensitives Verschmelzen ................................... 245
7.2.1 Pramissen und Prinzipien .................................... 245
7.2.2 Formale Spezifikation ....................................... 250
7.2.3 Probleme ................................................. 254
7.3 Dokumentiibergreifende Aspekte des Verschmelzens .................. 254
7.4 Literaturvergleich ............................................... 260
7.5 Zusammenfassung und Ausblick ................................... 264
8 Realisierung der Revisions- und Konsistenzkontrolle ............ 266
8.1 Der Graphenspeicher GRAS ...................................... 266
8.2 Realisierung eindeutiger Knotenbezeichner und
graphiibergreifender Kanten ...................................... 270
8.2.1 Realisierung eindeutiger Knotenbezeichner ..................... 270
8.2.2 Realisierung graphiibergreifender Kanten ....................... 272
8.2.3 Literaturvergleich ........................................... 282
8.3 Realisierung von Basisoperationen zur Anderungsverwaltung ........... 284
8.3.1 Funktionalitat der Basisoperationen ........................... 284
8.3.2 Realisierung der Basisoperationen ............................. 289
8.3.3 Literaturvergleich ........................................... 299
8.4 Stand der Implementierung ....................................... 303
8.5 Zusammenfassung und Ausblick ................................... 308
Literaturverzeichnis ........................................... 309
Stichwortverzeichnis ........................................... 319
1 Motivation und Zielsetzung
Dieses Buch beschaftigt sich mit der Frage, wie sich die Kontrolle der zeitlichen Entwicklung
von Softwaresystemen durch Werkzeuge unterstiitzen laBt. Der hier beschriebene Ansatz ist
im Rahmen des IPSEN-Projekts entwickelt worden, das sich mit integrierten Softwareent
wicklungsumgebungen befaBt. In diesem Kapitel beschreiben wir zunachst, mit welchen
Problemen wir uns in diesem Buch auseinandersetzen und welche Ziele wir verfolgen.
Zunachst gehen wir in Abschnitt 1.1 darauf ein, wie sich die Erstellung von Softwaresystemen
durch Werkzeuge unterstiitzen JaBt, und skizzieren die charakteristischen Merkmale des
IPSEN-Projekts. Abschnitt 1.2 enthalt eine kurze Einfiihrung in die Softwarekonfigurations
verwaltung, eine Disziplin, die sich mit der Kontrolle der Entwicklung und insbesondere der
Wartung komplexer Softwaresysteme befaBt, die in mehreren Versionen existieren. In Ab
schnitt 1.3 werden dann die Revisionskontrolle, die sich mit der zeitlichen Entwicklung von
einzelnen Softwaredokumenten beschaftigt, und die Konsistenzkontrolle, die sich mit der
Korrektheit von Softwaredokumenten und der zwischen ihnen bestehenden Beziehungen
auseinandersetzt, als Teilbereiche der Softwarekonfigurationsverwaltung eingefiihrt. Ferner
wird der hier verfolgte Ansatz zur Revisions-und Konsistenzkontrolle in einer integrierten
Softwareentwicklungsumgebung motiviert. SchlieBlich enthalt Abschnitt 1.4 eine Ubersicht
iiber die weiteren Kapitel des Buchs.
1.1 Unterstiitzung der Softwareerstellung durch Werkzeuge
Softwaresysteme werden immer komplexer. Es gibt heute Systeme, die mehr als eine Million
Zeilen Programmtext umfassen. Urn diese Komplexitat zu bewaltigen, braucht man geeig
nete Methoden und Werkzeuge. Ende der 60er Jahre entstand eine Disziplin der Informatik,
die als Softwaretechnik (englisch: Software Engineering) bezeichnet wird und sich mit der
ingenieurmaBigen Erstellung von Softwaresystemen beschaftigt.
Urn den ProzeB der Softwareerstellung zu strukturieren, sind Modelle entwickelt worden, die
die Softwareerstellung in nacheinander ablaufende Phasen unterteilen. Ein Beispiel fiir ein
solches Modell findet sich in IKKST 79/, wo die Phasen Problemanalyse, Entwurf, Implemen
tierung, Funktions- und Leistungsiiberpriifung, Installation und Abnahme sowie Wartung
identifiziert werden. Aile der Wartung vorangehenden Phasen werden unter dem Begriff
Entwicklung zusammengefaBt.
Phasenmodelle sind in verschiedener Hinsicht idealisiert:
• Die verschiedenen Phasen der Softwareentwicklung sind stark miteinander verschrankt.
Insbesondere gibt es Riickgriffe bei Fehlern, Vorgriffe bei Schatzungen etc.
2
• Die Wartung eines Softwaresystems umfaBt in der Regel aile Aktivitaten, die im Rahmen
der Entwieklung anfallen.
• Entwieklung und Wartung werden von phasenubergreifenden Aktivitaten (z.B. Doku
mentieren) begleitet.
Aus diesen Grunden sind Modelle der Softwareerstellung entwiekelt worden, die nieht die
zeitliehe Abfolge, sondem die logisehe ZusammengehOrigkeit von Aktivitaten in den Vor
dergrund stell en. In soIchen Modellen werden Aktivitaten nieht in Phasen, sondem in
Arbeitsbereichen zusammengefaBt. Ein Beispiel dafUr findet sieh in INa 901. Dort werden die
Arbeitsbereiehe Requirements Engineering (Festlegung der Anforderungen), Programmie
ren im GroBen (aile Aktivitaten oberhalb der Realisierung einzelner Module), Programmie
ren im Kleinen (Aktivitaten zur Realisierung einzelner Module), Projektmanagement, Doku
mentation und Qualitatssieherung eingefUhrt.
1m Zuge der Entwieklung und Wartung von Softwaresystemen werden Dokumente erstellt,
die jeweils das Ergebnis einer Aktivitat in einem bestimmten Arbeitsbereieh festhalten. Als
Beispiele lassen sieh etwa Anforderungsdefinitionen, Arehitekturen und Modulimplementa
tionen anfuhren, die jeweils Ergebnisse von Aktivitaten in den Arbeitsbereiehen Require
ments Engineering, Programmieren im GroBen bzw. Programmieren im Kleinen darstellen.
1m Faile, daB die Aktivitaten noeh nieht abgesehlossen sind, enthalten diese Dokumente
Teile, die noeh ausgestaltet werden mussen. Wir nennen soIche Dokumente unvollstandig.
Ein sehwieriges Problem bei der Softwareerstellung besteht darin, die Konsistenz von Doku
men ten zu gewahrleisten. Zum einen muB jedes Dokument fUr sieh betraehtet konsistent sein
(interne Konsistenz); z.B. darf eine Modulimplementation keine syntaktisehen Fehler enthal
ten. Zum anderen muB aber aueh die externe Konsistenz gewahrleistet sein: Dokumente sind
nieht voneinander unabhangig, sondem es gibt zwischen ihnen Beziehungen, die sieh aus dem
zugrundeliegenden Modell der Softwareerstellung ableiten lassen. So hangt z.B. die Arehi
tektur eines Softwaresystems von der Anforderungsdefinition ab, und die Modulimplementa
tionen bangen ihrerseits von der Arehitektur abo Exteme Konsistenz heiBt, daB ein Doku
ment den Forderungen genugt, die sieh aus den Dokumenten ergeben, von denen es abhangt.
So muB z.B. eine Modulimplementation mit der entspreehenden Sehnittstellenspezifikation
in der Arehitektur konsistent sein. Diese gegenseitigen Abhangigkeiten gibt es aueh bei
unvollstandigen Dokumenten.
Bei der Erstellung komplexer Softwaresysteme mussen Softwareentwiekler dureh geeignete
Werkzeuge unterstutzt werden. Eine Ansammlung derartiger miteinander (mehr oder weni
ger stark) kooperierender Werkzeuge wird als Softwareentwicklungsumgebung bezeiehnet
IDEFH 87/. 1m Gegensatz zu einer Programmentwieklungsumgebung, die lediglieh die
Implementierung von Softwaresystemen unterstutzt, impliziert der Begriff "Softwareent
wieklungsumgebung", daB aile Aktivitaten der Softwareerstellung unterstutzt werden. Natur-
3
lich hangt die Unterstiitzung von dem Lebenszyklusmodell (Phasenmodell, Arbeitsbereichs
modell o.a.) ab, das von seiten der Ersteller der Softwareentwicklungsumgebung an genom
men wurde.
Es gibt mittlerweile eine Fiille von Projekten, die sich mit Softwareentwicklungsumgebungen
beschaftigen. A1s Einstieg in die literatur seien dem interessierten Leser etwa der Uber
sichtsaufsatz IDEFH 871 und die Thgungsbande !He xx, CDW 861 empfohlen. In IDEFH 871
werden u.a. folgende Arten von Softwareentwicklungsumgebungen unterschieden:
• Sprachspezifische Umgebungen, die eine bestimmte Programmiersprache unterstiitzen
(z.B. Interlisp ffM 811 fur lisp, RationallMo 881 fur Ada, die Cedar-Umgebung rre 841
etc.). In diesen Umgebungen wird nicht zwischen verschiedenen Arbeitsbereichen unter
schieden; aile Aktivitaten bewegen sich auf programmiersprachlichem Niveau.
• Werkzeugkiisten, die aus einer Menge von Werkzeugen bestehen, die oft unabhangig
voneinander entstanden sind und daher nur lose miteinander integriert sind (z.B. die auf
Unix basierende Programmer's Workbench IKR 841 und die von Apollo entwickelte
Umgebung DSEE ICL 84/). Die Werkzeuge operieren in der Regel auf Textdateien.
• Strukturbezogene Umgebungen, in deren Zentrum syntaxgestiitzte Editoren fur verschie
dene Sprachen stehen (z.B. Gandalf IHN 86/, Mentor IDHKL 84/, Cornell Program
Synthesizer IRT 88/, PSG IBS 861 etc.). Die Werkzeuge einer strukturbezogenen Umge
bung sind a priori aufeinander abgestimmt, d.h. sie haben eine einheitliche Benutzer
schnittstelle und basieren auf einem einheitlichen internen Datenmodell. Dokumente
werden intern nicht als Textdateien, sondern in einer Form abgespeichert, die ihre
logische Struktur widerspiegeIt.
Das vorliegende Buch ist im Rahmen des IPSEN-Projekts (Integrated Project Support
ENvironment, INa 89, Na 90a, ES 89/) entstanden, das darauf abzieIt, Konzepte fur die
Erstellung von Softwareentwicklungsumgebungen zu erarbeiten und die Tragf<ihigkeit dieser
Konzepte durch die Implementierung entsprechender Prototypen zu demonstrieren. GemaB
der oben beschriebenen K1assifikation handeIt es sich dabei um strukturbezogene Umgebun
gen. Anstelle eines Phasenmodells der Softwareerstellung wird das oben angesprochene
Arbeitsbereichsmodell zugrunde gelegt. Ein Prototyp, der das Programmieren im GroBen,
das Programmieren im K1einen und die Dokumentation eines Softwaresystems sowie einige
Aspekte des Projektmanagements unterstiitzt, wurde im Jahre 1988 fertiggestellt (der IP
SEN-Prototyp '88, IEJS 88, Le 88b/).
Ein wichtiges Ziel von IPSEN besteht darin, die Integration von Aktivitiiten zu unterstiitzen,
die im Zuge der Erstellung eines Softwaresystems anfallen ILNW 88/. Dies betrifft sowohl die
Aktivitaten innerhalb eines Arbeitsbereichs als auch die Zusammenhange zwischen Aktivita
ten in verschiedenen Arbeitsbereichen. Beide Aspekte werden durch den oben erwahnten
IPSEN-Prototyp demonstriert. Innerhalb des Arbeitsbereichs Programmieren im K1einen
wird das syntaxgestiitzte Edieren, Analysieren und Ausfuhren von Programmen unterstiitzt.