Arbeitsgebiete
Motivation
1968 fand in Garmisch eine Konferenz des NATO Science Committee statt, die gemeinhin als Geburtsstunde der Disziplin "Software Engineering" gilt - dieser Begriff wurde damals als Provokation auf die Tagesordnung gesetzt, da er nach damaligem Verständnis einen Widerspruch in sich darstellte.
Wenn man den Konferenzband zur Hand nimmt, wird man verwundert feststellen, worüber die Teilnehmer damals erregt debattierten. Einer der wesentlichen Punkte war der, ob man weiterhin in Assembler programmieren sollte, oder ob nicht besser sogenannte high-level Sprachen wie Pascal zu verwenden seien. Das Hauptargument gegen Pascal et al. war die mangelnde Effizienz der Programmausführung. Von der Effizienz der Programmerstellung sprach man dagegen kaum. Wie diese Kontroverse ausgegangen ist, wissen wir heute.
Heute stehen wir an einem ganz ähnlichen Wendepunkt in der Geschichte der Informatik: wir stehen unmittelbar vor der Ablösung der konventionellen Programmiersprachen durch diagrammatische Entwurfssprachen. Pascal und seine Nachfolger (z.B. C++, Eiffel, Ada, Java) werden abgelöst werden durch eine neue Klasse von Sprachen wie ROOM, SDL, und UML. Diese neue Generation von "Programmiersprachen" verspricht einen Quantensprung in Produktivität, Wartbarkeit und Qualität komplexer Softwaresysteme. Und anders als beim Übergang von imperativ-prozeduralen zu imperativ-objektorientierten Sprachen ist diese Hoffnung wirklich realistisch, wie die Erfahrungen mit eingebetteten Systemen und im Telekommunikationsbereich zeigen (siehe z.B. SDL/ObjectGeode, ROOM/ObjecTime Developer Toolset, StateCharts/Rhapsody, Petrinetze/Artifex).
Natürlich wird es auch in fernerer Zukunft noch gewisse Nischen geben, wo man um Programmiersprachen wie Java nicht herumkommt. Genau so, wie es heute noch Anwendungsbereiche für Assemblersprachen gibt. Die Masse von Anwendungssoftware aber wird künftig auf einer höheren semantischen Ebene hergestellt werden.
Dieser Entwicklungssprung wird Auswirkungen auf fast alle Bereiche der Software-Herstellung haben. Im folgenden seien nur einige Aspekte genannt, die mich besonders interessieren. Einige davon sind in meiner Dissertation bereits weitgehend abgedeckt, andere sind noch weniger erforscht.
Aspekte
Software Architektur
Mit abstrakteren Programmiersprachen rücken natürlich auch abstraktere Strukturen in den Blick: die Architektur von Softwaresystemen. Zwar ist Architektur als Schlagwort in jedermans Munde, aber was es bedeutet, welche Auswirkungen es mit sich bringt, und wie man damit konkret umgeht ist noch weitgehend unerforscht, oder nur in akademischen Zirkeln bekannt. Allgemein anerkannte Konzepte und Notationen, oder leistungsfähige, allgemein verfügbare und leicht bedienbare Werkzeuge für Software Architektur gibt es nicht. Daher konnte bislang das Konzept von Software Architektur bislang nur als Schlagwort wirksam sein.
Wiederverwendung, Komponenten
Ein Aspekt, der mit Architektur in enger Verbindung steht, ist der alte Traum von der Wiederverwendung von Softwarebausteinen. Bei dieser Vorstellung steht die Elektrotechnik Pate, wo es seit jeher Komponenten gibt, die in Katalogen aufgelistet sind, und die "von der Stange" gekauft und eingesetzt werden können. Soll so etwas für Software auch möglich sein, so muß zum einen sichergestellt werden, daß eine Softwarekomponente in allen denkbaren Kontexten eingesetzt werden kann und immer gewisse Eigenschaften garantiert. Zum anderen muß diese Komponente abstrakt beschrieben werden, damit der Aufwand der Wiederverwendung ihren Nutzen übersteigen kann.
Wartung
Ein anderer Aspekt ist der der Wartung, also der Fehlerkorrektur und funktionellen Evolution von Softwaresystemen. Hier handelt es sich eigentlich um die duale Problematik zur Wiederverwendung: große Teile eines Systems bleibe bestehen (werden wieder verwendet), und an kleinen Teilen werden Änderungen durchgeführt. Während bei der Wiederverwendung eine kleine Komponente gegen Einflüße eines Kontextes abgeschirmt werden muß, geht es bei der Wartung darum, ein System von den Einflüßen einer geänderten Komponente abzuschotten. Auch hier ist es erforderlich, daß das System abstrakt beschrieben sein muß, um wirklich erhöhte Produktivität und Qualität zu erzielen.
Software Prozeß
Offensichtlich hat die Hervorhebung der Architektur einen tiefgreifenden Einfluß auf den Prozeß der Softwareherstellung. Während aber z.B. UML und Catalysis vollmundig als "Architekturzentriert" und "komponentenbasiert" beworben werden, ist davon in der Realität wenig zu spüren. Es gibt mittlerweile eine erhebliche Menge von Erfahrungen mit Prozessen für Wiederverwendung, Beschaffung und Architekturentwurf/-evaluierung, aber bislang existieren diese Teile weitgehend in Isolation.
Automatisiertes Software Engineering (ASE)
So, wie für den Erfolg von Pascal die Verfügbarkeit eines brauchbaren Compilers wichtig war, so wird es auch für den Übergang von Programmiersprachen zu Entwurfssprachen von entscheidender Bedeutung sein, welches Maß an Werkzeugunterstützung es gibt. Die heute vorhandenen Funktionalitäten sind dafür nicht ausreichend: zu Editoren und Simulatoren müssen sich leistungsvolle Code-Erzeuger und vor allem Konsistenzüberprüfer (Design Debugger) gesellen. Eine Reihe von randständigen, aber gleichwohl wichtigen Aspekten sind der Austausch von Modellen zwischen verschiedenen Werkzeugen, die Animation von Simulationen, und die Unterstützung von Messungen von Entwürfen.
Unified Modeling Language (UML)
Die UML ist "die lingua franca der Software Engineering community" - heute schon. Alle anderen Konkurrenten sind verdrängt oder in UML integriert worden. Auf absehbare Zeit wird es keine unabhängige Alternative zu UML geben. Es wird vermutlich vielerlei Dialekte und Variationen geben, aber alle werden sich beziehen müssen auf UML. Zwar gibt es auch heute noch eine Reihe on schwerwiegenden Problemen mit/in der UML, aber im Vergleich zu allen ihren Vorgängern bietet sie ein ein sehr umfassendes und recht gut integriertes konzeptuelles System mit breiter industrieller und akademischer Unterstützung. Damit ist UML der natürliche Ausgangspunkt dafür, die Vision von Computer Aided Software Engineering wieder aufleben zu lassen - und diesmal zum Erfolg zu führen.
Vision
Aus diesen Beobachtungen ergibt sich die Vision von integrierten Umgebungen zur Herstellung von Software auf Basis von Entwürfen (Computer Aided Software Engineering - CASE) in neuer Weise.
Ausgehend von einem Entwurf der Architektur mit einem Verbund von UML-Diagrammen wird die Machbarkeit des Entwurfes überprüft. Dies schließt neben einfachen Konsistenzprüfungen auch komplexe semantische Eigenschaften ein, z.B. Verhaltenseigenschften wie Verklemmungsfreiheit oder Fairness. Auch Lastprognosen zur Evaluierung von Benutzungsprofilen sind anhand socher Entwürfe möglich. Ein Prototyp der Anwendung wird vollautomatisch erzeugt. Die manuelle Nacharbeit beschränkt sich auf einige ausgewählte Punkte, und die dort eingeführten Änderungen werden entweder automatisch in die Entwürfe übernommen (wenn sie sich darauf beziehen), oder aber in spezielle Komponenten gekapselt, um insgesamt, als eine Art Mitochondrium verwendet zu werden.
Diese Vision wurde erstmals entwickelt im Zusammenhang mit den strukturierten Entwurfssprachen der siebziger Jahre. Damals wurden aber einige entscheidende Punkte übersehen, bzw. eine Reihe von Voraussetzungen waren schlichtweg nicht erfüllt. So wurde die Natur von Software als eine Art lebender, sich entwickelnder Organismus weithin verkannt. Der Prozeß der Herstellung war schlecht verstanden, ausdrucksstarke Notationen und Konzepte fehlten. Auf der technischen Seite fehlten graphische Benutzeroberflächen, semantische Datenbanken, Middleware für transparente Verteilung von Prozessen und vieles andere, an das wir uns heute gewöhnt haben.
Schließlich, und das ist wohl der Hauptpunkt, war der "Markt" für Modellierungssprachen und Methoden zersplittert, sodaß sich für kein einzelnes Segment die Herstellung leistungsfähiger Werkzeuge wirklich lohnte, weswegen sich der Einsatz für Anwender nicht lohnte, weswegen jedes Segment für sich klein blieb und so weiter.
Dies alles ist jetzt vorbei: wir haben in den letzten 20 Jahren eine Menge gelernt, es gibt mit UML nur noch eine einzige relevante Modellierungssprache, diese stellt eine Vielzahl sehr mächtiger Notationen in einem integrierten konzeptuellen Rahmen bereit, und die technischen Voraussetzungen sind heute gegeben. Folgerichtig beobachten wir ein explosionsartiges Wachstum des Marktes für neuartige UML-Werkzeuge. Mit anderen Worten: unsere Vision von CASE wird Realität, jeden Tag ein Stückchen mehr.
Ein paar Verweise zum weiterlesen (auf Englisch).
Harald Störle