Universität Stuttgart

Universität Stuttgart
Institut für Informatik
Abteilung Software Engineering 

Prof. Dr. Jochen Ludewig

Arbeitsschwerpunkte

In der Fakultät Informatik der Universität Stuttgart gibt es zwei Institute mit insgesamt 14 Lehrstühlen, die in Stuttgart als Abteilungen bezeichnet werden. Die Abteilung Software Engineering wurde 1988 neu eingerichtet.

Nähere Informationen zu allen hier angesprochenen Themen, Adressen usw. sind unseren WWW-Seiten zu entnehmen.

Das Wort Software Engineering hat keine klare Bedeutung; das provokativ eingeführte Etikett (F.L. Bauer 1968) wurde erst ab Mitte der 70'er Jahre aufgegriffen und dann jeweils nach Belieben interpretiert. Das in Stuttgart herrschende Verständnis von Software Engineering ist durch den Ingenieur-Hintergrund des Abteilungsleiters und durch das Umfeld, eine praxis-orientierte Informatik in einer technischen Hochschule, geprägt; es entspricht der Charakterisierung in IEEE Std. 610.12 (1990).

Wir glauben nicht, die unbefriedigenden Verhältnisse, die wir in der Welt der Software sehen, durch irgendwelche Patentrezepte, raffinierte Werkzeuge oder geniale Methoden revolutionieren zu können. Wir versuchen stattdessen, an uns selbst und in Zusammenarbeit mit Partnern außerhalb der Universität Schwachstellen im Bereich der Software-Bearbeitung zu identifizieren, Möglichkeiten der schrittweisen Verbesserung zu erkennen und umzusetzen.

Zwei sonst in der akademischen Welt wichtige Abgrenzungen haben für uns geringeres Gewicht, nämlich

• die Trennung zwischen Forschung und Lehre und
• die Trennung zwischen Technik und Management, allgemeiner zwischen der Technik und den Aspekten der Zusammenarbeit. 

Denn Software Engineering ist in jedem Falle eine Aktivität von Menschen, die ihre Wertmaßstäbe, ihre Verhaltensweisen, ihre Verfahren und Notationen ändern müssen, wenn sich etwas ändern soll. Darum gehört zu jedem Versuch, Forschungsergebnisse umzusetzen, Lehre (im weitesten Sinne). Zudem werden die Forschungsresultate nur sehr schleppend in die Praxis übernommen. Wir folgern daraus, daß entweder die Forschungsresultate untauglich sind oder daß der Transfer in die Praxis vernachlässigt wurde (vgl. (1)). Wenn wir mit Gruppen in der Industrie kooperieren, dann läuft immer ein wechselseitiger Austausch ab; wie sonst sollten wir erfahren, was benötigt wird und was in der Praxis funktioniert?

Die Aspekte der Kooperation (Management, Qualitätssicherung, Kommunikation und Teamarbeit) beziehen wir ein, weil darin nach unserer Beobachtung und nach den publizierten Erfahrungen anderer die meisten Probleme wurzeln, mit denen die Entwickler und die Benutzer von Software zu kämpfen haben. Die Erfahrung hat gezeigt, daß es kaum hilft, Ingenieure und Manager nur zu mischen; wir brauchen offensichtlich Leute, die beides können. Denn Software ist Kommunikation, nicht nur die zwischen Programmierer und Rechner, sondern vor allem die zwischen Kunde und Analytiker, zwischen Projektleiter und Entwickler, zwischen Verfasser des Handbuchs und Benutzer, zwischen dokumentierendem Codierer und Wartungsprogrammierer.

Die Abteilung Software Engineering sieht ihre Aufgabe darin, Beiträge zu leisten, die in der realen Welt anwendbar sind und auch angewendet werden. Dabei gilt der Grundsatz, daß wir externen Partnern nichts zumuten können, was wir selbst nicht bei unserer täglichen Arbeit anwenden. Insofern sind wir unsere eigenen, keineswegs immer erfolgreichen Versuchstiere.

In Zukunft wird sich die Abteilung auch mit Software-Wartung und Software-Sicherheit befassen.

Seit 1996 bietet die Fakultät neben dem Studiengang Informatik den Modellstudiengang Softwaretechnik an; darin ist vieles umgesetzt, was oben als abstrakte Überlegung formuliert ist (2): Der Studienplan ist so angelegt, daß nicht nur mit besonderem Nachdruck die technischen Konzepte des Software Engineerings gelehrt, sondern auch die Kenntnisse und Erfahrungen in der Kommunikation und Teamarbeit, in Management und Qualitätssicherung vermittelt werden. Drei sogenannte Studienprojekte, die in Gruppen von etwa acht Studierenden über zwölf Monate laufen und alle Phasen der Entwicklung einschließen, beanspruchen die Hälfte des Gesamtaufwands im Hauptstudium. Eines der Projekte hat speziell mit Alt-Software zu tun, eines findet im (bislang nur technischen) Anwendungsfach statt.
 

Projekte

SESAM

Das Projekt SESAM (Software-Engineering-Simulation durch animierte Modelle) läuft seit 1990. Sein Ziel ist die Entwicklung eines Simulationssystems, mit dem sich ein Software-Entwicklungsprojekt in einigen Stunden durchspielen läßt. Die Rolle des Projektleiters wird nicht simuliert, sie muß durch den ``Spieler'' wahrgenommen werden; aus seiner Sicht ist SESAM eine Art Abenteuer-Spiel. Damit bietet SESAM die Möglichkeit, die Leitung eines Softwareprojekts in einer definierten Umgebung zu üben, ohne erhebliche Kosten oder Risiken zu verursachen. Da der gesamte Spielverlauf aufgezeichnet wird, können die Handlungen und Unterlassungen des Spielers später analysiert und korrigiert werden.

Die Konzepte für SESAM wurden zunächst in drei Smalltalk-Prototypen untersucht; es entstand eine Architektur, in der der eigentliche Simulator klar getrennt ist vom Modell, das der Simulation zugrundeliegt. Der Spielzustand, also aus der Sicht des Spielers das (simulierte) Projekt, wird im Rechner als attributierter Graph dargestellt. Das Modell besteht entsprechend aus einem statischen Teil, der definiert, welche Entitäten, Attribute und Relationen zur Verfügung stehen, und einem dynamischen Teil, der bestimmt, wie sich der Zustand mit der Zeit ändert. Die Entscheidungen des Spielers führen in der Regel zu Änderungen des Zustands.

Beispielsweise kann der Spieler einen seiner (simulierten) Mitarbeiter beauftragen, eine Spezifikation zu schreiben. Dann entsteht zunächst eine Beziehung zwischen diesem Mitarbeiter und der Spezifikation (genauer zwischen den Objekten, die den Mitarbeiter und die Spezifikation in SESAM repräsentieren). Aufgrund dieser Beziehung wächst die Spezifikation (d.h. der Attributwert ``Umfang'') mit der Zeit an. Die Geschwindigkeit des Wachstums und die Zahl der Fehler, die der Mitarbeiter macht, sind u.a. von den Attributwerten des Mitarbeiters abhängig, z.B. von seiner Motivation und von seiner Erfahrung im Anwendungsgebiet.

Während das erste den Prototypen folgende komplette System (SESAM-1) ebenfalls auf der Basis von Smalltalk-80/Visual Works 2.0 implementiert wurde, läuft seit 1997 eine Neuimplementierung in Ada95. Wir streben damit an, zwei Probleme besser als bisher in den Griff zu bekommen, nämlich die Geschwindigkeit und die Wartbarkeit des Systems. Außerdem finden wir es interessant, quasi anti-zyklisch nach unserer Arbeit mit Smalltalk nun Erfahrungen mit einer sehr ausgereiften konventionellen, aber objektorientiert erweiterten Programmiersprache zu sammeln.

Die Grundidee von SESAM ist leicht verständlich. Beim Versuch, das System zu realisieren, stößt man aber auf viele Fragen, die sich nicht einfach aufgrund der Literatur oder durch kurzes Nachdenken beantworten lassen. Diese Fragen lassen sich am besten an den Schichten festmachen, die das System bilden (siehe Tabelle).

Die Bedien- oder Spielschnittstelle muß dem Spieler erlauben, alle Möglichkeiten zu nutzen, die im Modell vorgesehen ist. Technisch bietet sich dafür ein Menü an. Aber durch ein Menü wird der Spieler geführt; wenn er selbst herausfinden soll, welche Möglichkeiten er hat, muß SESAM seine Anweisungen in natürlicher Sprache akzeptieren. Im Rahmen einer Diplomarbeit (Spiegel 1995) wurde dazu eine Lösung nach dem Vorbild des Adventure-Games Dungeon entwickelt.

Die Analyseschnittstelle ist bislang nur rudimentär realisiert, sie erfordert vor allem eine anschauliche (und aufwendige) graphische Darstellung des Spielverlaufs, bietet aber kaum grundsätzliche Schwierigkeiten.

Ganz anders das Simulationsmodell: Die zusammenhängenden Fragen, wie Modelle in der Realität ablaufen, welche Modellierung dafür angemessen ist und in welcher Form solche Modelle formuliert werden können, sind die zentrale Herausforderung dieses Projekts.

Modell-Compiler und Simulationssystem sind Programme beträchtlicher Größe; ihre Spezifikation ist erschwert durch den Umstand, daß sich mit den Forschungen zum Modell auch die Anforderungen ändern; umgekehrt sind die Überlegungen zum Modell nicht von den Möglichkeiten des Simulators zu lösen.

SESAM bildet für die Abteilung Software Engineering ein integrierendes Gesamtprojekt; alle weiteren unten genannten Teilprojekte tragen mehr oder minder stark zum SESAM-Projekt bei. Die meisten Studien- und Diplomarbeiten, die in der Abteilung Software Engineering gelaufen sind, hatten einen thematischen Bezug zu SESAM. Über SESAM gibt es eine Reihe von Publikationen, einige sind unten angegeben ((3), (4), (5)).

Bislang wurde SESAM nur indirekt für seinen Zweck verwendet, zukünftige Projektleiter auszubilden: Die Entscheidungen der (spielenden) Studenten wurden von den Betreuern eingegeben, die Resultate wurden ihnen mitgeteilt. Diese Vorsichtsmaßnahme hatte mehrere Gründe: SESAM war alles andere als robust, das Modell war lückenhaft und zum Ende des Life Cycles hin unvollständig. Darum war die korrigierende Mitwirkung der Betreuer unverzichtbar. Trotzdem waren die Erfahrungen ermutigend: Die Spieler fanden die Reaktionen des Systems durchaus plausibel und konnten sie also als realistische Erfahrung akzeptieren.

Bis Mitte des Jahres 1998 wollen wir SESAM-2 demonstrieren können. Dann sind wir in der Lage, komplexere - und das heißt realistischere - Modelle zu erproben. Solche Modelle werden gegenwärtig entwickelt.

Die bisherigen Ergebnisse des Projekts betreffen vor allem die Gebiete Metriken und Prozeßmodelle. Wir haben gelernt, jede Metrik vor allem danach zu beurteilen, welchen Zusammenhang sie mit anderen Metriken oder mit unmittelbar relevanten, feststellbaren Eigenschaften der Software hat. Prozeßmodelle sind nur sinnvoll, wenn ihr Nutzen für eine der primären Zielgrößen unserer Arbeit (Kosten, Termine, Qualität) empirisch belegt ist.

Schließlich mußten wir erkennen, daß die teilweise dickleibige Literatur unseres Fachs so gut wie keine Aussagen enthält, die hart genug sind, um darauf ein Simulationsmodell zu gründen. Wie Software-Projekte wirklich verlaufen, bleibt offen. Die Validierung der Modelle wird damit zu einem wesentlichen und extrem schwierigen Bestandteil unserer Arbeit.

Projektmanagement

Patricia Mandl-Striegnitz arbeitet an der Analyse und Verbesserung des Software-Projekt-Managements in der Praxis. Bei einem industriellen Kooperationspartner werden die konkreten Bedingungen der Software-Entwicklung erhoben, Verbesserungsvorschläge entwickelt und umgesetzt. Dieses Projekt läuft im Rahmen des Software-Labors Stuttgart (siehe (6)). Die Ergebnisse sollen auch einer Verbesserung der SESAM-Modelle dienen.

Modellierung

Anke Drappas Thema ist die Analyse und Modellierung der Software-Entwicklungsprozesse. Es entsteht ein SESAM-Modell, das speziell auf den Aspekt der Software-Qualität ausgerichtet ist. Der Spieler erfährt also den Zusammenhang zwischen Entwicklungsprozeß und Software-Qualität.

Anforderungsspezifikation

Ralf Melchisedech untersucht auf dem Gebiet des Requirements Engineerings insbesondere die Möglichkeiten der nicht-formalen Spezifikation. Die formale Spezifikation war zwei Jahrzehnte lang Gegenstand intensiver Forschung; ihr Nutzen bleibt gering. In der Praxis wird weiterhin und aus guten Gründen vorwiegend informal spezifiziert, bislang ohne Unterstützung durch die Forschung. Die Arbeit soll Möglichkeiten und Grenzen der informalen Spezifikation ausloten.

Configuration Management

Stefan Krauß organisiert im SESAM-Projekt das Software-Configuration-Management und die Dokumentation. Dies ist auch sein Forschungsthema. Wir hoffen auf diese Weise neue Wege zu finden, um auch große Software-Systeme in kompakter Weise darstellen zu können, so daß die Chancen einer umfassenden Software-Wartung statt einer reinen Code-Anpassung verbessert werden.

Objektorientierte Entwicklung

Ralf Reißing befaßt sich mit objektorientierter Entwicklung und dabei vor allem mit der Frage, welchen Einfluß Entwurfsmuster auf die Software-Entwicklung und auf die entstehenden Architekturen haben werden.

Typ-Inferenz

Jinhua Li arbeitet an der Frage, wie sich aus Smalltalk-Programmen Typinformationen durch Typ-Inferenz automatisch ableiten lassen. Die Resultate sind für die Wartung des SESAM-1-Systems und aller anderen Smalltalk-Programme von großer Bedeutung.

Veröffentlichungen

1. J. Ludewig: Von der Software-Zivilisation zur Software-Kultur: Die Vision einer verläßlichen Software-Umgebung. H. Mayr (Hrsg.), Beherrschung von Informationssystemen. GI-…CG-Jahrestagung 1996, Klagenfurt, Verlag R. Oldenbourg, Wien, S.255-266.
2. J. Ludewig: Der Modellstudiengang Softwaretechnik. in Forbrig, Riedewald (Hrsg.): SEUH'97 (Software Engineering im Unterricht der Hochschulen). Berichte des German Chapter of the ACM, Band 48, Teubner, Stuttgart, 1997, S.9-23.
3. J. Ludewig (Hrsg.) (1994): SESAM - Software-Engineering-Simulation durch animierte Modelle. Bericht 5/1994 der Fakultät Informatik, Universität Stuttgart.
4. J. Ludewig, M. Deininger: Teaching software project management by simulation: The SESAM project. in Irish Quality Association (ed.): 5th European Conference on Software Quality, Dublin 1996, pp. 417 - 426.
5. R. Melchisedech, M. Deininger, A. Drappa, H. Hoff, S. Krauß, J. Li, J. Ludewig, P. Mandl-Striegnitz: SESAM - A Software Engineering Education Tool Based on Graph Grammars. Bulletin of the European Association for Theoretical Computer Science (EATCS) 58, 1996, S. 198-221.
6. H. Lichter, P. Mandl-Striegnitz: Software-Projektmanagement in der Industrie - Erfahrungen und Analysen. Bericht SL-2/96 des Software-Labors Stuttgart, 1996.
7. J. Li: Modellierung und Ausführung der Softwarewartung. In: F. Lehner (Hrsg.): Softwarewartung und Reengineering - Erfahrungen und Entwicklungen, Deutscher Universitätsverlag Wiesbaden/Gabler Vieweg Westdeutscher Verlag, 1996. S. 279-295.

Produkte und Werkzeuge

Das SESAM-System ist über WWW verfügbar. Es ist vollständig auf Englisch dokumentiert. Anfang 1998 handelt es sich um SESAM-1, dessen Installation Visual Works auf Solaris erfordert. SESAM-2 wird bereitgestellt, wenn es vollständig ist. Ebenfalls im WWW stehen Checklisten für die Software-Entwicklung, die im Rahmen einer Diplomarbeit (Würthele 1995), des Teilprojekts ''Projektmanagement'' und anderer Arbeiten zusammengetragen und verbessert wurden.

Kontaktadresse:

Prof. Dr. Jochen Ludewig
Universität Stuttgart
Institut für Informatik
Abteilung Software Engineering
Breitwiesenstr. 20-22, D-70565 Stuttgart
Tel.: (0711) 7816-354 
Fax: (0711) 7816-380
ludewig@informatik.uni-stuttgart.de