Table Of ContentInformatik -Fachberichte
Herausgegeben von WBrauer
im Auftrag der Gesellschaft fur Informatik (GI)
43
Werkzeuge
der Programmiertechnik
GI- Arbeitstagung
Karlsruhe, 16. - 17. März 1981
Proceedings
Herausgegeben von G. Goos
Springer-Verlag
Berlin Heidelberg NewYork 1981
Herausgeber
Gerhard Goos
Institut für Informatik 11
der Universität
Postfach 6380
7500 Karlsruhe
AMS SUbject Classifications (1979):
CR Subject Classifications (1980): 4.0,4.6
ISBN-13: 978-3-540-10725-5 e-ISBN-13: 978-3-642-68064-9
001: 10.1007/978-3-642-68064-9
This work is subject to copyright. All rights are reserved, whether the whole or part
of the material is concerned, specifically those of translation, reprinting, re-use of
illustrations, broadcasting, reproduction by photocopying machine or similar means, and
storage in data banks. Further, storage or utilization of the described programms on date
processing installations is forbidden without the written perm iss ion of the author.
Under § 54 of the German Copyright Law where copies are made for other than private
use, a fee ist payable to "Verwertungsgesellschaft Wort", Munich.
© by Springer-Verlag Berlin Heidelberg 1981
VorvTort
In diesem Band sind die Vortre.ge zusammengestellt, die auf der Tagung
"werkzeuge der Programmiertechnik" am 16./17. März 1981 in Karlsruhe
gehalten wurden. Die Tagung kam zustande auf Anregung des FA 3/4
der GI "Rechnerorganisation und Betriebssysteme" und wurde vom FA 2
der GI "ProgramI!'iersprachen" unterst\.i.tzt, der jetzt für die Betreuung
des Themas Software Engineering zuständig ist. Das sgezielle Thema
"Werkzeuge der PrograIl1IT'.iertechnik" wurde ge~\lähl t, u.'U eine Gelegenheit
zu schaffen, den heutigen Stand der Diskussion im Bereich des Software
Engineering zu erfassen, der vielfach aus dem Stadium der Methodendis
kussion in das Stadium der handfesten Unterstützungsprogramme für die
Software-Entwicklung getreten ist.
Das Programmkomitee, bestehend aus den Herren
Dr. A. Endres, IBH
Prof. Dr. G. Goos, U Karlsruhe
Prof. Dr. J. Griese, U DortJ:\und
Dr. G. Heldmann, Softlab
Dipl.-Ing. D. Heysing, Bayer AG
Prof. Dr. J. Nehmer, U Kaiserslautern
Prof. Dr. G. Seegmüller, TU München
Dr. H. Strunz, mbp
Dr. J. lVi tt, Siemens
Dipl.-Phys. P. vHisten, Siemens
hatte die erfreuliche, \\lenn auch r.\i.ihsame Aufgabe, aus insgesamt 33
eingereichten Vortragsmeldungen die hier abgedruckten 14 Beiträge
auszuwählen. Um die Aktualität der "Arbeits"-Tagung zu gewährleisten,
mußte dies sowie die Fertigstellung der endgültigen Manuskripte in
verhältnismäßig kurzer Zeit erfolgen.
Die Veranstalter danken den Vortragenden, den Gutachtern und allen,
die zum Gelingen der Tagung beigetragen haben. Schließlich gilt unser
Dank dem Springer Verlag., der die Herstellung dieses Tagungsbandes in
außergewöhnlich kurzer Zeit ermöglichte.
Karlsruhe, im Februar 1981 G. Goos
I n haI t
Software-Produktionsumgebungen: Entwicklungsstand und Trends
H. L. Hausen, M. Müllerburg
Developing algebraic specifications of threaded data structure 28
implementations
A. Laut
Ein Weg zur Spezifikation und Durchführung von Transformationen 41
an Progr~en in höheren Prograromiersprachen
G. Fischer
PASILA - ein computerunterstütztes Werkzeug zur Definition 57
und Implementation von Anforderungssprachen
J. Christ, H. Balzert
Spezifikation für ein Spezifikationswerkzeug 75
P. Schnupp
ESPRESO-W, ein Werkzeug für die Spezifikation von 101
Prozeßrechner-Software
K. Eckert, J. Ludewig
Methoden und Werkzeuge zur SOftvmre-Entwicklung: 113
Einordnung und eberblick
W. Hesse
DIPROTOR - ein Software'illerkzeug zur Erstellung von 154
Diagrammen und Prograw~rahmen für die
datenstrukturorientierte des PrograI!U!'.entwurfs
~1ethode
K. Truöl
RELSPEZ - eine relationale Problemspezifikation: 169
Konzept und Erfahrungsbericht
Th. Spitta, A. Schnieder
Die separate Compilation in ChilI 181
A. Büchler
ASeparate Compilation System for Ada 197
M. Dausmann, G. Persch, S. Drossopoulou, G. Winterstein
Software-Entwicklung für Mikroprozessoren bei der 214
Nixdorf Computer AG
K. Angermann, M. SedeZZo
Erfahrungen aus Entwicklung und Einsatz eines 228
Programmgeneratorsystems mit komfortabler Benutzer
schnittstelle zum 'bildhaften Spezifizieren'
R. M. Gerkens
Systeme R/SAP - Real Time Systeme 244
H. PZattner
Autorenverzeichnis 261
SOFTWARE-PRODUKTIONS-UMGEBUNGEN:
ENTwrCKLUNGSSTAND UND TRENDS
H.L. Hausen und M. Müllerburg
Institut für Software-Technologie
Gesellschaft für Mathematik und Datenverarbeitung mbH
Schloß Birlinghoven
0-5205 St. Augustin 1
Zusammenfassung
Es wird ein Überblick über Software-Produktions-Umgebungen gegeben.
Grundlage hierfür sind ca. 20 solcher Systeme, die aus etwa 75 Hilfs
mitteln für die SOftware-Entwicklung ausgewählt wurden. Die Untersu
chung der Systeme orientiert sich am Fragenkatakog, der für das Sym
posion on Software Engineering Environments [Hünk81] erstellt wurde.
Diskussionsthemen sind: Motivation und Ziel, Anwendungsbereiche, Werk
zeuge und Funktionen, Konzepte, Entwicklung und Nutzung von Software
Produktions-Umgebungen. Dabei wird der heutige "Stand der Kunst" darge
legt, und Mängel werden aufgezeigt: Z.B. fehlen adäquate Modelle für
die Entwicklung und Anwendung von Software, und mögliche Auswirkungen
der Anwendung von SOftware-Systemen werden bei der Entwicklung nicht
genügend berücksichtigt.
Schlagwörter
Software-Produkt ions-Umgebung, Programmier-Umgebung, Software
Produktion, SOftware-Management, Produktkontrolle, Produktionskontrol-
le, Automatisierung der Software-Produktion .
Inhaltsverzeichnis
1 Einleitung
2 Motivation und Zweck der Software-Produktions-Umgebungen
3 Ziele bei der Entwicklung von Software-Produktions-Umgebungen
4 Anwendungsbereich von Software-Produktions-Umgebungen
5 Werkzeuge und Funktionen von Software-Produktions-Umgebungen
6 GrundLegende Konzepte in Software-Produktions-Umgebungen
7 Entwicklung von Software-Produktions-Umgebungen
8 Einfluß der Nutzungsphase auf SOftware-Produktions-Umgebungen
9 Automatisierung durch Software-Produktions-Umgebungen
10 AusbLick
Anhang
A Charakterisierung ausgewählter Software-Produktions-Umgebungen
B Literaturverzeichnis
2
1 EINLEITUNG
Die hier vorgestellten Ergebnisse beruhen auf einer Untersuchung von
etwa 20 Ansätzen zu SOftware-Produktions-Umgebungen, abgekürzt SPUen
[Haus81c]. Diese Ergebnisse wurden beeinflußt vom "Symposium on
Software Engineering Environments (S2E2)", das von der GMD im Juni 1980
in Lahnstein veranstaltet wurde [Hünk31]. Die ausgewählten Systeme (so
wie die Auswahlkriterien) werden im Anhang A kurz beschrieben. Außerdem
enthält dieser Anhung die im Text verwendeten Abkürzungen für SPUen und
für jede SPU Literaturhinweise.
1.1 Bedeutung des Begriffs Software-Produkt ions-Umgebung
Der Begriff Software-Produkt ions-Umgebung bezeichnet ein instrumentier
tes und organisiertes SOftware-Entwicklungs-Laboratorium, in dem viele
Personen arbeiten, um gemeinsam in einem vollständig organisierten Ar
beitsprozeß Software zu entwerfen, zu zu prüfen, zu än
konstruieren~
dern und zu warten. Eine SPU bietet software-gestützte Modelle, Metho
den, Verfthren, Beschreibungsmittel und Werkzeuge für diese Arbeit.
SPUen unterstützen die Software-Entwicklung und -Anwendung dadurch, daß
sie diese Mittel bereitstellen und dadurch daß sie die Handhabung die
ser Mittel festlegen.
1.2 Geschichte der Software-Produktions-Umgebungen
Als Antwort auf die Software-Krise wurde Ende der 60er Jahre die Diszi
plin Software-Technologie (Software engineering) eingeführt. Damals
wurde Software-Produktion verstanden aLs das Entwerfen und Dokumentie
ren von Programmen. Beides solLte verbessert werden durch methodisches
Vorgehen bei Strukturierung und Dokumentation von Programmen. Inzwi
schen ist der Aufgabenbereich der Software-Produktion gewachsen: Anfor
derungsanalyse, Spezifikation von Problem und Software sowie Verifika
tion und VaLidation von Software werden heute ebenfalls als Entwick
lungsaufgaben angesehen. Außerdem wird dem Management der Software
Produktion und der Organisation von Entwicklergruppen ein besonderes
Gewicht beigemessen. Erkennbar ist heute bereits die Notwendigkeit, die
Auswirkungen der Anwendung eines Systems schon während seiner Entwick
lung zu beachten. Der Einsatz eines Computer-Systems beeinflußt nicht
nur die Arbeitsbedingungen des einzelnen Benutzers an seinem Arbeits
platz, er kann unter Umständen die gesamte Organisation verändern, in
der es verwendet wird. Batroffen sind aber nicht nur diejenigen, die
mit einem Computer-System arbeiten müssen, sondern auch diejenigen, für
die z.B. Dienstleistungen mit Computerhilfe erbracht werden. Eine mög
liche Auswirkung ist die, daß eine Rechnung nicht mehr lesbar ist.
In Übereinstimmung mit diesem wachsenden Aufgabenbereich werden
neue und komplexere Instrumente entwickeLt, die nicht nur den einzelnen
Software-Entwickler unterstützen, sondern auch die Planung und Organi
sation großer Software-Projekte. Angesichts dieser Geschichte ist ver
ständlich, daß die früheren Programmierwerkzeuge zu Programmier
Umgebungen erweitert wurden (einschließlich Sprachprozessoren und
speziell zugeschnittenen Editoren), denen heute Software-Produkt ions
Umgebungen folgen.
SPUen sind nicht etwa Spielzeuge für "verrückte Software-
Fetischisten": Ansätze zu SPUen sind bereits erfolgreich eingesetzt
worden, und man braucht sie heute in vielen Bereichen, um Entwicklung
und Nutzung von Software rational zu gestalten. Der Bedarf in diesen
Bereichen ist verschieden:
3
• Im industriellen Bereich werden Instrumente gebraucht, die die Lösung
spezieller Produktionsprobleme erleichtern.
• Im Forschungsbreich verwendet man SPUen als Vehikel zum Experimentie
ren, d.h. zum Ausprobieren und UberprGfen wissenschaftlicher Ideen.
• Im öffentlichen Bereich möchte man Normen für Softwareprodukte durch
setzen und benötigt dafür Systeme, die die Softwareproduktion und die
Software entsprechend kontroLLieren.
1.3 Was soLLen Software-Produktions-umgebungen leisten?
SPUen soLLen ModeLLe, Methoden, Beschreibungsmittel und Werkzeuge für
die verschiedenen Aufgaben der SOftware-EntwickLung und -Nutzung anbie
ten; sie soLLen somit Fachabteilung, DV-Abteilung und Management unter
stützen. Die Aufgaben der Software-Produktion sind:
• Software-Management,
d.h. PLanung, organisation und Kontrolle von Projekten;
• Software-Produktion und -KontrolLe,
d.h. Anforderungsanalyse, Systementwurf und -Konstruktion sowie War
tung; hierzu gehört auch die Produktkontrolle oder Qualitätssicherung
und -KontroLLe;
• Software-Anwendung und Anwendungsvorbereitung,
d.h. auch Antizipation mögLicher Auswirkungen und Partizipation der
Benutzer und Betroffenen.
In den foLgenden KapiteLn werden e1n1ge Aspekte ausführLich disku
tiert, die für die Beurteilung des Entwicklungsstandes von SPUen wich
tig sind.
2 MOTIVATION UND ZWECK DER SOFTWARE-PRODUKTIONS-UMGEBUNGEN
Allgemeine Ziele bei der Erstellung und Anwendung von SPUen sind:
• RationaLisierung,
nämLich Kostenreduzierung und Produktivitätssteigerung,
• Standardisierung und Normung,
sowie nicht zuletzt
• Verbesserung der Qualität von Software.
2.1 Unterscheidung der Motivationen
Die Motivationen, SPUen zu entwickeln oder zu verwenden, unterscheiden
sich entsprechend der speziellen Umwelt des Herstellers oder Benutzers:
• in der Industrie: Handhabung großer
Produktionsprojekt~,
• im Forschungsbereich: Bereitstellung eines Forschungsvehikels für
die Untersuchung und Demonstration neuer
Forschungsergebnisse und
• im öffentlichen Bereich: Standardisierung und Normung von Produkten
und Produktionsverfahren, um bestimmte
zu sichern.
QuaLitätsmerkw~Le
In der Industrie müssen konkrete praktische Probleme bei der Pro
duktion bewältigt werden. Bemerkenswert ist, daß verschiedene SPU
Entwickler unterschiedliche Probleme der Software-Produktion als beson
ders kritisch empfinden. Die in der Industrie entstandenen SPUen sind
stark beeinflußt durch die Umgebung der DV-Abteilung sowie durch die
Branche, für die das jeweilige Werk arbeitet. In diesem Kontext der
SPU-Entwicklung ist Forschung zu Themen der Software-Produktion in er
ster Linie darauf ausgerichtet, zur Lösung der eigenen aktuellen
Schwierigkeiten beizutragen. Forschung wird hier auch durch die prakti
schen Probleme angeregt, die mit der Anwendung bestehender Software
verbunden sind.
4
Beispiele für industrielle SPUen sind CADES und AIDES:
• CADES wurde konstruiert, weil man die Entwicklung eines Betriebssy
stems für ein neues Computersystem rationalisieren wollte. In der er
sten Entwic~lungsphase übernahmen die Entwickler von CADES den TOPD
Ansatz aus Newcastle [Snow80] und fügten Funktionen für das techni
sche Personal sowie Instrumente für das Management hinzu.
• AIDES wurde entwickelt, weil man die Handhabung umfangreicher Dia
gramme unterstützen wollte. Dieses Problem war beim AIDES-Hersteller
aufgetreten, als die Entwurfs-Methode "Structured Design" (s.a. Com
posite Design; Myers, Yourdon, Constantine und Stevens) eingeführt
wurde. Für AIDES wurden Werkzeuge für den Umgang mit großen Struktur
Diagrammen entwickelt. Instrumente kamen hinzu, mit denen Aussagen
über die Qualität eines Software-Entwurfs möglich sein sollen. Die
Entwicklung dieser Instrumente beruht auf Forschung auf dem Gebiet
der Qualitätsmessung.
Die Ansätze im Forschungs- und Entwicklungsbereich sind durch ande
re Zielsetzungen geprägt. In fast allen akademischen SPU-Entwicklungen
ist die wesentliche Motivation die, ein Mittel zu schaffen, mit dem Me
thoden, Modelle, Verfahren, Techniken oder Werkzeuge für Software
Produktions-Aufgaben laborartig entwickelt und erprobt werden können.
Es wurden verschiedene Ansätze entwickelt, die jeweils auf einem spezi
ellen Konzept (für einen bestimmten Aspekt der Software-Produktion) ba
sieren (z.B. Sprache, Modellierungsprinzip). Typische Beispiele sind
DREAl-l, COSY und DELTA/BETA. Eine ausführliche Erörterung einzelner
Aspekte dieser SPUen ist in den folgenden Kapiteln zu finden.
2.2 Ursprung der Ideen für Software-Produkt ions-Systeme
SPUen können auch durch die Ideen unterschieden werden, auf denen sie
wesentlich beruhen. Solche Ideen (oder Ausgangspunkte) sind z.B. eine
Methode der SOftware-Entwicklung, ein Sprachkonzept, eine "Sichtweise"
oder ein Management-Verfahren. Dafür einige Beispiele:
• AIDES ist ein Beispiel für eine SPU, die auf einer speziellen Methode
beruht, nämlich auf "Structured Design".
• Sprachkonzepte sind Ausgangspunkt für das CDL2-Lab, casy und POS:
Das CDL2-Lab beruht auf der Compiler Description Language CDL2 •
~
• Die grundlegende Idee von eOSY ist, nicht-sequentielle Systeme mit
Path-expressions zu beschreiben.
• Basis von POS ist die Sprache EL1, die durch die Forschung auf dem
Gebiet der künstlichen Intelligenz (insbesondere automatische Pro-
grammsynthese) beeinflußt wurde.
• Ein besonderer Ansatz ist DELTA/BETA. In dieser SPU-Entwicklung wird
die Rolle der Personen betont, die durch den Einsatz von Computer
System.en betroffenen sind. Grundlage für diesen Ansatz ist ein beson
derer Systembegriff. Nach Nygaard [Nyga81] ist ein Computer- (oder
Software-) System nur ein Teilsystem in einem umfassenden sozio
technischen System, das nicht zuletzt auch Menschen umfaßt.
• SofhJare-~lanagement ist das zentrale Thema in SDEr1/SDSS. Diese SPU
unterstützt Software-Management, das mit einem Projekt
lenkungsausschuß arbeitet. Der Produktionsprozeß wlrd durch einen
detaillierten Life-cycle festgelegt. Für die techni~chen Komponenten
wird Vorhandenes genutzt; so soll z.B. PSL/PSA (von ISDOS [Teich77])
übernommen werden.
5
3 ZIELE BEI DER ENTWICKLUNG VON SOFTWARE-PRODUKTIONS-UMGEBUNGEN
Die Ziele bei der Entwicklung von SPUen können grob unterteilt werden
in
• wissenschaftliche (oder Forschungs-) Ziele,
• technische (oder Produktions-) Ziele und
• wirtschaftliche (oder marktstrategische) Ziele.
Wissenschaftliche Ziele beherrschen die SPU-Entwicklung im Forschungs
bereich. Technische Ziele gibt es sowohl in der Industrie als auch im
Forschungsbereich. Wirtschaftliche ZieLe bestimmen die Entwicklung von
SPUen in der Industrie. StaatLich unterstützte SPU-Entwicklungen können
ebenfalls nach diesen Zielkategorien klassifiziert werden, da deren
Ziele nicht von von oben erwähnten Zielen abweichen.
3.1 Entwicklungen mit wissenschaftlichen Zielen
Im Bereich der Universitäten und Forschungsinstitute beherrschen wis
senschaftliche Ziele die SPU-Entwicklungen. Hier werden Methoden zur
systemkonstruktion ebenso entworfen und entwickelt wie System
beschreibungssprachen und Werkzeuge zur Synthese und Analyse dieser
Beschreibungen. ALs charakteristische Beispiele können COSY, DREAM,
GYPSY und das CDL2-Lab angeführt werden:
• COSY verwendet Path-expressions für die Definition nebenläufiger Pro
zesse. Es wurde eine Sprache geschaffen, die die Entwicklung nicht
sequentieller Systeme unterstützt. Dazu wurde eine neue Technik der
Sprachdefinition entwickelt, nämlich die Spezifikation mittels Petri
Netzen [BrauSO].
• In DREAM führte die Modellierung paralleler Systeme durch die Be
schreibung von Message-transfers zur Entwurfssprache DON (DREAM
Design Notation). Die Sprache erlaubt die Spezifikation eines Systems
mit Event-expressions. Mit DON soll man das systemverhalten in der
Entwurfsphase definieren können, ohne gleichzeitig die Implementie
rung festzulegen.
• GYPSY ermöglicht die Verifikation verteilter Softwaresysteme. Die Me
thode des Beweisens der Korrektheit von Programmen mittels induktiver
Zusicherungen hat GYPSY in zweifacher Weise beeinflußt.
Verifikationstechnik und Sprach konzepte sind auf diese Methode ausge
richtet. Daneben wird die Verifikation mittels Zustandsmaschinen
ebenso unterstützt wie algebraische Verifikation. In den Augen der
GYPSY-Entwickler ist keine dieser Methoden den anderen überlegen.
OffensichtLich möchte das GYPSY-Team mit der Verifikation kLeiner Sy
steme experimentieren, indem kritische Funktionen einzelner
Verifikationsansätze erprobt und die Ergebnisse zur Rechtfertigung
der Benutzung des ausgewählten Verifikationsansatzes herangezogen
werden.
• Mit dem CDL2-Lab sollte eine bequeme Umgebung für die Systementwick
lung mit der Sprache CDL2 geschaffen werden. Basis ist hier der neue
ste Stand der Compiler-Compiler-Entwicklung. Die Anpassung der Tech
niken des Compilerbaus (z.B. Bootstrapping und Cross-Compiling) an
die Erfordernisse der Systementwicklung scheint erfolgreich zu sein:
Dieses System ist mehr aLs ein akademisches Spielzeug, erste in
dustrielLe Anwendungen finden statt.
3.2 Entwicklungen mit technischen Zielen
Als technische ZieLe werden z.B. genannt: Verbesserung der QuaLität von
Software und Verbesserung des Produktionsprozesses sowie Berücksichti
gung der Anwendungsauswirkungen von SPUen auf die betroffene Organisa
tion und die beteiligten Personen.
Für das Ziel besserer Softwarequalität werden als Teilziele ge
nannt: Verbesserung der Zuverlässigkeit sowie der Änderungs- und
