CASE - Computer Aided Software Engineering

Wir gehen hier nur kurz auf das Ausbildungsproblem ein. Bei Einführung von CASE bei einem Software-Produzenten müssen häufig zunächst einmal die zukünftigen Benutzer der Werkzeuge in den unterstützten Methoden ausgebildet und u.U. die interne betriebliche Organisation der Software Entwicklung verändert werden. Beide Bereiche betrachten wir hier nur als Voraussetzungen für CASE. Es sei aber nicht verschwiegen, daß sie oft das entscheidende Problem bei der Einführung von CASE sind. Neben den eigentlichen Werkzeugen benötigt ein CASE-Anwender daher häufig Beratung bei der Methodenauswahl, Schulungen, Studienmaterialien etc.

Die Auswahl von CASE-Werkzeugen oder -Umgebungen erfordert, genau wie bei anderen Software-Systemen, zunächst eine gründliche Anforderungsanalyse, gefolgt von einem Systementwurf. Eine CASE-Umgebung wird normalerweise, ähnlich wie andere Standardsoftware, überwiegend aus im Markt erhältlichen Komponenten bestehen, die an die speziellen Benutzeranforderungen adaptiert bzw. durch eigene Software ergänzt werden. Hieraus resultieren einige Anforderungen an technische Merkmale von CASE-Werkzeugen.

Unterstützung bei der Software-Entwicklung durch Werkzeuge war schon immer notwendig. Beispiele konventioneller Werkzeuge sind Text-Editoren, Assembler, Übersetzer, Testhilfen, Modul-Bibliotheken oder andere Werkzeuge mit begrenztem Funktionsumfang. Hinzugekommen sind seit einigen Jahren vor allem Werkzeuge für die frühen Phasen der Software-Entwicklung, z.B. Editoren für Datenflußdiagramme, Entity-Relationship-Diagramme, Petri-Netze und ähnliches. Als CASE-Werkzeug bezeichnen wir hier alle Software-Produkte, die zumindest einzelne bei der Entwicklung von Software benötigte Funktionen anbieten.

Das Arbeiten mit mehreren isolierten Einzelwerkzeugen hat sich allerdings vielfach als zu ineffektiv erwiesen. Dies war ein Hauptmotiv dafür, das "integrierte" Systeme mit einem breiten, "vollständigen" (s.u.) Funktionsumfang zu entwickeln. Letztere bezeichnet man als Software-Entwicklungsumgebungen (SEU) oder CASE-Umgebungen.

Bei der Entwicklung eines Softwaresystems werden verschiedene Typen von (meist papierlosen) Dokumenten mit entsprechenden Methoden und Verfahren produziert. Eine Methode ist dabei gegeben durch (1) einen Systembeschreibungstyp, z.B. Petri-Netze, SADT-Diagramme, Quellprogramme usw., (2) eine Menge von detaillierten Verfahren bzw. Arbeitsschritten ("Tätigkeiten") und mehr oder minder präzise Regeln, wie die Tätigkeiten auszuführen sind, um die gewünschte Systembeschreibung zu produzieren. Eine Systembeschreibung eines bestimmten Typs beschreibt das Software-System aus einem bestimmten Blickwinkel bzw. auf einem bestimmten Abstraktionsniveau. Um sie mit Werkzeugen verarbeiten zu können, muß sie in der Syntax einer konkreten textuellen oder graphischen Sprache gespeichert werden.

Neben den Tätigkeiten, die unmittelbar zur (Weiter-)-Entwicklung der Software und der dazugehörigen Dokumentation beitragen, treten auch Tätigkeiten zur Projektadministration, Qualitätssicherung, Berichtswesen innerhalb des Unternehmens etc. auf.

In einem Vorgehensmodell (software life cycle) wird mehr oder weniger exakt festgelegt, welche Dokumente zu produzieren, welche Methoden und Verfahren dabei anzuwenden und welche Tätigkeiten in welcher Abfolge durchzuführen sind. Beispiele sind das Wasserfallmodell und das Spiral-Modell. Das Vorgehensmodell hängt vom Typ der Größenordnung und der geforderten Qualität der zu entwickelnden Software sowie anderen Faktoren ab. Die Vorgehensmodelle für verschiedene Klassen von Software können so unterschiedlich sein, daß bestimmte Tätigkeiten bei manchen Vorgehensmodellen auftreten und bei anderen nicht. Beispielsweise wird bei der Methode Jackson Structured Programming (JSP) aus der Beschreibung der Ein-/Ausgabe-Datenstrukturen und ihren Beziehungen zueinander direkt die Feinstruktur des Kontrollflusses abgeleitet. Das Programm ist nicht in Moduln gegliedert. Somit tritt die Tätigkeit "Modulstruktur entwerfen" nicht auf.

Die Methoden in einem Vorgehensmodell sollten integriert sein in dem Sinne, daß die sukzessive zu erstellenden Dokumente semantisch konsistent sind und durch inkrementelle Erweiterung oder durch Transformation auseinander entstehen. Ferner sollten sie keine Teile enthalten, die nicht zum Endergebnis beitragen.

• Vollständigkeit: Eine SEU soll Funktionen enthalten, die alle bei der Entwicklung von Software anfallenden Tätigkeiten unterstützen. Wie schon erwähnt, hängen die anfallenden Tätigkeiten vom Typ der zu entwickelnden Software und vom Vorgehensmodell ab. Gleiches gilt für den Begriff Vollständigkeit. Es ist hier nützlich, zwei Klassen von Tätigkeiten zu unterscheiden:
  1. Tätigkeiten, die bei fast allen Vorgehensmodellen auftreten: Projektverwaltung, Entwicklungsprozeßsteuerung, Dokumentation, Textverarbeitung, Berichterstattung, Wiederverwendung von Komponenten (Bibliotheken), elektronische Post und andere Bürotätigkeiten.
  2. Vorgehensmodell-spezifische Tätigkeiten, z.B. editieren, prüfen, transformieren, übersetzen etc. von konkreten Systembeschreibungen bzw. Dokumenten.

  Alle allgemein auftretenden Tätigkeiten sollen von einer SEU unterstützt werden, ferner alle Entwicklungsmodell-spezifischen Tätigkeiten, die der konkrete Benutzer der SEU ausübt.

• Integration: Eine besonders wichtige Anforderung an eine SEU ist, daß sie in mehrfacher Hinsicht integriert ist (wobei sie nur soweit integriert sein kann, wie die unterstützten Methoden integriert sind).
  • Verteilung, unterliegendes Betriebssystem: Wenn eine SEU aus einzelnen Werkzeugen zusammengesetzt ist, die ggf. sogar auf verschiedenen Rechnern (PCs, Mainframes, Workstations) laufen, dann müssen als elementarste Form der Integration diese Werkzeuge von einem Arbeitsplatz aus benutzbar gemacht werden.
  • Daten: Die verschiedenen Arten von Systembeschreibungen in einem Vorgehensmodell weisen fast immer Redundanzen (oder Konsistenzbedingungen untereinander) auf. Zum Beispiel kann der Datentyp eines Datenflusses in einem Datenflußdiagramm auch als Typ eines Parameters einer Prozedur in einer Modulbeschreibung und als Datentyp in dem zugehörigen Quellprogramm auftreten. Redundante oder ableitbare Daten sollten nicht erneut vom Software-Entwickler eingegeben werden müssen. Wen Redundanzen nicht vermeidbar sind, muß die Beseitigung von Inkonsistenzen unterstützt werden.
  • Benutzungsschnittstelle: Um den Lernaufwand zu begrenzen und die Benutzungsfreundlichkeit zu erhöhen, sollen die Sprachen, in denen der Entwickler mit verschiedenen Werkzeugen bzw. Funktionsgruppen der SEU kommuniziert, möglichst einheitlich sein. Dies gilt für alle Abstraktionsebenen der Kommunikation; einzelne Zeichen (lexikalische Ebene), Syntax und Semantik von Kommandos, ganze Dialoge. Die lexikalischen und syntaktischen Aspekte der Kommunikation können durch ein Fenstersystem konstruktiv vereinheitlicht werden.
  • (Werkzeug-)Steuerung/Automation: bei den meisten Vorgehensmodellen treten häufig wiederholte Sequenzen von Arbeitsschritten auf (z.B. Editieren - Prüfen - Übersetzen - Binden von Programmen). Entsprechend können durch die Gruppierung von Funktionen innerhalb einer SEU wiederholte Sequenzen von Benutzerkommandos erforderlich sein. Soweit möglich und sinnvoll, sollten Aufruf und Steuerung einzelner Werkzeuge bzw. Funktionen der SEU automatisch erfolgen.
  • Überwachung des Software-Entwicklungprozesses: Die Einhaltung der im Vorgehensmodell enthaltenen Regeln sollte kontrolliert werden. Diese Regeln sind immer dann anwendbar, wenn ein Entwickler seinen nächsten Arbeitsschritt auswählt. Die Kontrolle kann z.B. darin bestehen, Abweichungen vom Vorgehensmodell durch Warnungen anzuzeigen, mögliche nächste Arbeitsschritte vorzuschlagen oder die Menge der zulässigen nächsten Arbeitsschritte einzuschränken.
• Benutzerfreundlichkeit: Die Bedienung der SEU sollte leicht erlernbar, bequem, konsistent (s. auch Integration der Benutzungsschnittstelle) und an individuelle Benutzerbedürfnisse anpaßbar sein. Die Benutzungsschnittstelle der SEU sollte Software-ergonomische Standards (DIN 66234, Teil 8: Grundsätze der Dialoggestaltung) einhalten und ein Hilfesystem enthalten.
• Teamarbeit: Große Software-Systeme werden arbeitsteilig in Teams entwickelt. Die parallele Arbeit der Entwickler und die Kooperation innerhalb des Teams muß unterstützt werden.
• Adaptierbarkeit: Die SEU muß an die Arbeitsumgebung und an die organisatorisch/technischen Verhältnisse beim Software-Entwickler (z.B. Layout von Ausdrucken, interne Prozeduren und Standards etc.) adaptierbar sein.
• Offenheit: Die Architektur sollte interne Schnittstellen haben, die die Integration mit anderen Werkzeugen (z.B. bei Software-Entwickler bereits vorhanden oder für die Adaptierung zusätzlich benötigten Werkzeugen) erleichtern. Diese Schnittstellen sollten offen sein.

Im folgenden werden einige typische Formen von Umgebungen vorgestellt. Die angegebenen Merkmale beziehen sich sowohl auf den Benutzer sichtbaren Funktionsumfang als auch auf die Architektur der Umgebung. Literaturangaben zu den als Beispiel angeführten Umgebungen finden sich in. Beschreibungen weiterer Umgebungen finden sich in.

"Werkzeugkästen" bestehen aus mehreren durch das Betriebssystem verbundenen Einzelwerkzeugen. Die Daten sind in Dateien gespeichert; Werkzeuge tauschen Daten über Dateien aus. Der Benutzer muß die Werkzeuge durch Betriebssystemkommandos aufrufen; allerdings kann durch geeignete Kommandoprozeduren dieser Aufwand stark reduziert und insgesamt der Eindruck einer integrierten Umgebung erweckt werden. Bekanntestes Beispiel ist UNIX mit den zugehörigen Werkzeugen.

Programmierumgebungen unterstützen die "späten" Phasen der Software-Entwicklung ("lower CASE"), also Entwurf, Programmierung und Test von Programmen, meist nur in einer konkreten Programmiersprache. Dann nennt man sie auch sprachorientierte Umgebungen. Beispiele sind Interlisp, Smalltalk und Rational für die Sprachen Lisp, Smalltalk bzw. Ada.

Syntax-orientierte Umgebungen beinhalten Sytnax-orientiere Editoren, (inkrementelle) Compiler und andere Werkzeuge, die die Syntax einer oder mehrerer Sprachen, meist Programmiersprachen, kennen und ausnutzen. Die Werkzeuge bzw. die Umgebung werden aus der Grammatik der Sprachen generiert, der Werkzeug-Generator steht oft den Benutzern der Umgebung zur Verfügung, so daß diese eine modifizierte Umgebung generieren können. Beispiele sind der Cornell Program Synthesizer, Gandalf und Mentor.

"Upper-CASE"-Umgebungen enthalten nur Werkzeuge, die die frühen Entwicklungsphasen unterstützen. Typische unterstützte Methoden sind Structured Analysis, SADT, Datenmodellierung mit Entity-Relationship-Diagrammen und JSP: Derartige Umgebungen werden vor allem bei der Entwicklung von administrativer Software auf Basis von Datenbanksystem benutzt; dieser spezielle Anwendungsbereich der Software-Technologie hat vermutlich die meisten Anwender und das umfangreichste Angebot an Werkzeugen, "Upper-CASE"-Umgebungen bzw. Werkzeuge müssen mit einem Data Dictionary System, einem Datenbanksystem und ggf. einer 4.-Generationssprache integriert sein; letztere werden in diesem Kontext meist nicht als CASE-Werkzeuge bezeichnet.

Software-Fabriken sind SEU, die die "industrielle" Software-Entwicklung ermöglichen sollen. Hierzu werden besondere Funktionen in den Bereichen Wiederverwendung und Prozeßkontrolle angeboten. Beispiele sind Arcadia und EUREKA-Software-Factory.

Ein weiterer Aspekt von CASE ist die Standardisierung: In den letzten Jahren wurden mehrere Vorhaben zur Definition von "CASE-Standards" gestartet. Die Standards sind z.T. nicht auf SEU beschränkt, sondern umfassen allgemeine Software-Entwicklungsumgebungen. Die involvierten Gruppen hielten am Rande der internationalen Workshops CASE 88 und CASE 89 (Imperial College, London) jeweils ein "CASE Standards Coordination Meeting" ab. 1989 waren bereits rund 20 Gruppierungen vertreten. Die wichtigsten Themenbereiche der Standards sind

• Methoden,
• Datenaustauschformate,
• Data Dictionaries,
• Benutzungsschittstellen und
• verteilte Systeme.

Aus diesen Gruppierungen stammen außerdem mehrere Referenzmodelle für SEU; erwähnenswert ist.

1. Balzert, H.: CASE-Systeme und Werkzeuge (Angewandte Informatik ), Mannheim: BI 1990
2. Boehm, B.: A spiral model of software development and enhancement. IEEE Comput. 21 (5), 61-72 (1988)
3. Dewal, S., Kelter, U.: Role-based requirements definition for software factories using reusable requirements packages, in: Bennet, K.H. (ed.): Proc. Software Engineering Environments 1989, p. 351-370, University of Durham, Chichester: Horwood 1989
4. Penedo, L., Riddle, W.E.: Software engineering environment architectures, IEEE Trans. Softw. Eng. 14, 689-696 (1988)
5. A reference model for frameworks of computer aided software engineering environments. Technical Report TR/55, European Computer Manufacturers Association, 111 Rue du Rhône, CH-1204 Genf (1991)

Prof. Dr. Udo Kelter
FernUniversität Hagen
Fachbereich Mathematik und Informatik
Praktische Informatik V
Postfach 940, 5800 Hagen 1

© 1991 Informatik Spektrum, Springer-Verlag Berlin Heidelberg