Protokoll der Arbeitsgruppensitzungen

– AG: Entwerfen und Dokumentieren von Frameworks: Methoden & Werkzeuge –

Protokoll: Georg Odenthal

Die Teilnehmer des vierten AK-Treffens in Siegen haben sich in zwei Arbeitsgruppen jeweils speziellen Themen aus den Bereichen Frameworks und Entwurfsmuster gewidmet. Hier die Ergebnisse aus den ca. 5 Stunden an Vorträgen und intensiver Diskussion der Arbeitsgruppe "Entwerfen und Dokumentieren von Frameworks: Methoden & Werkzeuge" als Zusammenfassung.

Zur Vorbereitung der Arbeitsgruppe waren alle interessierten Teilnehmer aufgerufen, ein Positionspapier zu formulieren, in dem bei wahlfreiem Umfang kurz auf die eigenen Interessen und die aktuelle Arbeit eingegangen werden sollte. Leider war die Resonanz nicht berauschend, der Erfolg derer, die sich Arbeit machten, beim Treffen dann aber deutlich.: Durch die Vorarbeit von Dr. Ute Gappa (Bosch, Frankfurt) und Wolfram Kleis (Uni Kaiserslautern) konnten die zwei Sessions durch interessante Berichte eingeleitet und motiviert werden. Bei der Abschlußbesprechung des AKs herrschte dann schließlich Konsens darüber, daß ein gewisses Maß an Vorbereitung für den effizienten Ablauf eines solchen Treffens nötig ist.

Dr. Ute Gappa von Bosch in Frankfurt berichtete also am Donnerstag Nachmittag ausführlich von den ganz praktischen Problemen, die bei der Einführung einer Framework-basierten Entwicklungsstrategie in die gewachsenen organisatorischen wie technischen Strukturen im Bereich der elektronischen Diesel-Einspritzsysteme entstehen. Zur Unterstützung einer gezielten Anforderungsermittlung an die Variantenbildung und die Ableitung einer geeigneten Software-Struktur hat Sie ein Formular entworfen, anhand dessen für einen bestimmten Themenkomplex die Hot und Frozen Spots identifiziert werden, eine Architektur zur Einbettbarkeit der Varianten entworfen und in ein sprachabhängiges Design umgesetzt wird. Dieses "Varianten Engineering" soll die Basis für den Entwurf eines Frameworks bilden, das möglichst vielen der zu erwartenden Kundenwünschen entspricht. Der dritte Schwerpunkt ihres Vortrags bezog sich auf die generativen Möglichkeiten zur Begegnung der Anforderungen an die Flexibilität der Software einerseits, insbesondere hinsichtlich Variantenbildung, und an die geforderte Laufzeiteffizienz andererseits. In dem Zusammenhang überlegt sie, welche Konzepte der Objektorientierung man durch eine gezielte Erweiterung der im Projekt zugrundegelegten objektbasierten Echtzeit-Implementierungssprache ERCOS/OLT realisieren sollte. Zur Diskussion stellte sie insbesondere die technologische Antwort auf die Problemstellungen des Anwendungsbereichs in Form der Objekttechnologie, d.h. wieviel Objektorientierung bzw. welche Konzepte man in der Umgebung zum jetzigen Zeitpunkt für eine Framework-Entwicklung einführen bzw. mit einem generativen Ansatz unterstützen sollte.

Aus Ihrem Vortrag entstand anschließend eine angeregte Diskussion – hier einige Stichworte aus den angeschnittenen Problemkreisen:

• Klaus Quibeldey-Cirkel merkte an, daß der Schwerpunkt der Analyse bei der Frameworkentwicklung auf den Invarianten einer Produktfamilie anstatt auf den Varianten liegen sollte. Die Invarianten liefern dann die Bausteine, aus denen man bei Black Box Frameworks die Anwendungen komponieren kann.
• Einige Teilnehmer waren ferner der Meinung, daß speziell in diesem Fall anstatt eines Frameworks in einer objektorientierten Universalsprache eine anwendungspezifische (idealerweise visuelle) Programmiersprache entwickelt werden sollte. (Visueller Editor für Regelkreise). In diesem Fall kommt ein Framework (wenn überhaupt) nur beim Bau des Interpreters/Compilers zum Einsatz. Die Benutzer können sich weiterhin in der Begriffswelt des Anwendungsbereichs bewegen und eine Schulung in objektorientierten Konzepten und Frameworktechnik entfällt.
• Nachbildung von OO-Konzepten in einer nicht-objektorientierten Entwicklungsumgebung?
• Martin Hefering von der DKV bot wichtige Einblicke in die Projektorganisation eines kommerziellen großen Frameworks: Das DKV-Framework ist ein Blackbox-Framework (die Systemarchitektur ist festgelegt), das auf Basis von Kochrezepten in In-house-Projekten auf die jeweils speziellen fachlichen Workflows angepaßt wird. Jedes Projekt, das das Framework einsetzt, wird von einem Mitarbeiter aus der Framework-Entwicklergruppe gecoacht. So sind optimale Unterstützung und kurze Wege gewährleistet. Das entstehende Feedback aus der Framework-Verwendung fließt so umgekehrt in die Weiterentwicklung des Frameworks ein.

Die Diskussion verlagerte sich dann zu Fragen der Dokumentation:

• Reicht die textuelle Dokumentation für die Verwendung von Frameworks oder ist eine Unterstützung durch Wizzards und Generatoren erforderlich. Hier hatte vor allem das im Plenarvortrag von Ansgar Bredenfeld vorgestellte APICES die Phantasie der Teilnehmer beflügelt, da dort die Vorteile einer entsprechenden Unterstützung des Framework-Anwenders besonders deutlich geworden war.
• Gegenfrage: Ist eine Werkzeugentwicklung für die Framework-Verwendung nicht zu aufwendig? Unterschiedliche Zielgruppen und die Bestimmung eines Frameworkprojekts sowie die Projektgröße sind hier wichtige Einflußfaktoren.
• Der Einsatz von Frameworks bedeutet einen Technologiesprung, der durch entsprechendes Projektmanagement und Veränderung der hausinternen Abläufe flankiert werden muß. Diese These konnte durch die Beispiele von Bosch und DKV beispielhaft illustriert werden.
• Was die Typen von Framework-Dokumentationen angeht, lassen sich drei identifizieren:

• die Dokumentation zur Verwendbarkeit – eine kurze und strukturierte Beschreibung der wesentlichen Eigenschaften und Beschränkungen des Frameworks. Die Frage: "paßt das Framework auf meine Anforderungen" soll hier möglichst schnell beantwortet werden.
• Die Dokumentation zur Anwendung – durch Kochbücher, Beispiele oder Laufzeitunterstützung (Wizzards, Generatoren) wird der Anwender in die Lage versetzt, ein Framework zu benutzen, ohne dessen Entwurf und die konkrete Realisierung zu kennen, geschweige denn verstehen zu müssen.
• Die Dokumentation zum Entwurfsverständnis – für alle, die die Architektur und die Implementierung eines Frameworks verstehen wollen oder müssen: schon bei der Vorstellung der Teilnehmer des AK-Treffens wurde dieses Problem (erneut) deutlich: die Einarbeitung neuer Mitarbeiter in ein bestehendes Framework-Projekt ist ohne eine geeignete Unterstützung durch Werkzeuge und/oder Dokumentation sehr aufwendig, da die erfahrenen Entwickler diese Arbeit dann "nebenher" erledigen müssen.

• Zum Thema Projektorganisation noch ein (bekanntes) Statement: Die Initiierung eines Frameworkprojekts "from the scratch" ist dem Vorgehen, bestehende Erfahrungen aus verschiedenen Projekten einer Domäne in ein Framwork-Projekt zu bündeln, unterlegen: Frameworks können nur auf Basis fundierten Anwendungswissens erfolgreich entworfen werden.

Wolfram Kleis von der Universität Kaiserslautern stellte den Freitagmorgen unter das Thema "Konzepte zur Beschreibung objektorientierter Frameworks". Mit seinen Worten gesprochen "ketzerisch und provokant" wollte er die Teilnehmer zum Widerspruch auffordern, als er zunächst die bestehenden Ansätze Revue passieren ließ. Ausgehend von seinem Standpunkt: "ich will nicht blind Bedienungsrezepte anwenden sondern ein für meine Tätigkeit angemessenes Systemverständnis haben", stellte er:

• das Kochbuch zur Framework-Anwendung,
• die Verwendung von Beispielen, um auf experimentellem Weg ein Systemverständnis zu erlangen,
• die Werkzeugunterstützung mit der Unterscheidung in die Automatisierung von Handarbeit (beispielsweise Codefragmente erzeugen) und Kopfarbeit (Black-Box-Framework mit Applikationsgeneratoren),
• und die Dokumentation auf Basis von (Entwurfs-)mustern

unter einem kritischen Licht dar.

Anschließend vermittelte er zunächst konzeptionell und dann anhand zweier Beispiele s eine Ideen, die er ergänzend zu den bestehenden Methoden, einsetzen möchte. Seine Arbeit basiert dabei im wesentlichen auf einer von Prof. Wendt in Kaiserslautern schon seit den siebziger Jahren entwickelten Begriffswelt und Darstellungstechnik. Ziel der Systembeschreibung ist dabei die Verbesserung des Wirkungsgrades der zwischenmenschlichen Kommunikation. Deshalb wird der Anschaulichkeit der Vorrang vor der formalen Präzision eingeräumt. Die Systembeschreibungen bestehen deshalb aus einer Mischung von formalen und nicht formalen Elementen. Für die maschinelle Verarbeitung (Analysatoren, Konsistenzprüfer, Codegeneratoren) sind sie bewußt nicht konzipiert und deshalb auch nicht geeignet. Die Beschreibungstechnik, die Systeme auf unterschiedlichen Betrachtungsebenen jeweils durch orthogonale Sichten (Aufbau, Ablauf, Typaussagen) graphisch darstellt, ist generell für die Modellierung programmierter Systeme geeignet. Sie ist für objektorientierte Systeme anwendbar, aber nicht darauf beschränkt.

Die Praxistauglichkeit des Ansatzes wurde in Projekten zur Nachdokumentation der R/3-Basis bei SAP in Walldorf in den letzten Jahren gezeigt. Für Einzelheiten zur Notation und erhellende Beispiel siehe die Folien zum Vortrag, die auf Nachfrage bei Wolfram Kleis zu erhalten sind. Aus Sicht des Vortragenden besteht bei aktuellen Ansätzen zur Framework-Dokumentation vor allem ein Defizit bei der Beschreibung des Systemverhaltens und bei der Darstellung exemplarischer Aufbaustrukturen. Die meisten bekannten Ansätze legen den Fokus hingegen auf Typaussagen (Klassenstrukturen). Genau hier soll der vorgestellte Ansatz Verbesserungen bringen. Zusammenfassend kann man sagen, daß Wolfram Kleis den Teilnehmern nach anfänglicher Skepsis anhand der Beispiele doch deutlich vermitteln konnte, daß seine Ideen eine deutliche Verbesserung für das Systemverständnis bedeuten.

Abschließend stellte Georg Odenthal die im letzten halben Jahr im Rahmen einer Diplomarbeit (Markus Blachnik) in Zusammenarbeit mit Prof. Dr. H. A. Schmid entstandene Nachdokumentation des OSEFA-Frameworks der FH-Konstanz vor. Neben der Nachdokumentation lag das Interesse der Arbeit vor allem in der Weiterentwicklung von HTML-basierten Dokumentationstechniken. Interessenten können sich die Ergebnisse im Web ansehen.

Beim nächsten Treffen des Arbeitskreises wird die Arbeitsgruppe mit einer konkreten Aufgabe fortfahren: der Anforderungsdefinition für Software-Dokumentation. Wir hoffen schon jetzt auf eine rege Beteiligung! Über Einzelheiten werden wir alle Mitglieder des AKs rechtzeitig informieren.