"Zwar könnten wir eine Reihe von Dingen besser machen, aber auf jeden Fall hat es sich gelohnt, mit dem Framework zu entwickeln", resümiert Andreas Rösel. Der Diplomingenieur und Leiter des Projekts "Objektorientierte Frameworks" vom Heidelberger Forschungszentrum der Asea Brown Boveri AG (ABB) entwickelt Applikationen und Konzepte mit dem SGF. "Es macht aber auch mehr Spaß", setzt er sichtlich zufrieden mit sich hinzu. Kollegen aus den verschiedenen Projekten könnten sich nun über ihre Entwicklungen austauschen, da sie über eine gemeinsame Basis an Komponenten verfügten. Das sei in Projekten, in denen auf herkömmliche Art entwickelt werde, so nicht möglich. Für die Ingenieure, die mit den Framework-Anwendungen arbeiten, "sind die Objekte lebendig".
Das SGF besteht aus 1240 Klassen. Den Kern bilden 140 handelsübliche plus 110 Framework-Klassen. Bei einer, wie Rösel und sein Kollege Michael Wilcke, der das Basis-Framework entwickelt hat, "konservativen Schätzung" kann eine neue Lösung, die das Framework benutzt, rund 60 Prozent der darunterliegenden Schichten verwenden (siehe Abbildung unten). Die Anwendungsentwicklung setzt von vornherein auf einem höheren Level auf, so daß nur noch der Teil zu realisieren ist, der individuell gestaltet werden muß.
Deshalb benötigten die mit dem Framework entwickelten zehn Anwendungen - sieben Applikationen und drei Prototypen - weniger als die Hälfte der Klassen, die für voneinander unabhängige Einzelentwicklungen nötig gewesen wären, schätzungsweise 2740. Unterm Strich errechnet sich damit bisher eine Kostenersparnis von mindestens 9,5 Mannjahren.
Am Anfang der Framework-Entwicklung stand allerdings nicht das hehre Ziel der Wiederverwendung, sondern konkrete Aufträge aus zwei unterschiedlichen Geschäftsbereichen der ABB, die nahezu gleichzeitig beim Forschungszentrum eingingen. Beide Kunden meldeten Bedarf im Bereich "Graphical Engineering" an, das als Front-end auf bestehenden Ingenieurlösungen aufsetzen sollte.
Unter Graphical Engineering (siehe Abbildung Folgeseite) ist ein parametrisiertes Konstruktionsverfahren zu verstehen. Die Symbole verwenden ABB-Ingenieure zum Entwurf und zur Kontrolle von Dampf- oder Stromkreisläufen sowie beispielsweise für die Modellierung von Industrieanlagen oder -maschinen: Turbinen, Transformatoren, Kontakte und Umspannanlagen.
Nachdem die Überlappungen bei der Anforderungsanalyse sichtbar geworden waren, wollte man den gemeinsamen Teil nur einmal realisieren. Objektorientiertes Know-how war im Forschungszentrum bereits vorhanden. Anstelle jedoch lediglich eine Bibliothek mit Basisklassen anzulegen, um die Aufgabe zu lösen, entschied sich das Forschungszentrum für ein Framework. "Dabei definiere ich die übergreifende Architektur und lasse Platzhalter für Verfeinerungen", erklärt Wilcke. "Das Framework bietet den Applikationsentwicklern einen systematischen Bausatz an, in den sich die anderen Teile einer Applikation gewissermaßen einhängen lassen." Allen Anwendungen gemeinsam sind beispielsweise Methoden und Eigenschaften wie Verbindungen herstellen, Objekte hierarchisch anordnen, Konsistenzen prüfen, Daten über Dialoge eingeben, Copy and paste sowie die Parallelität von Wirklichkeit und Computerdarstellung.
Der Vorteil einer objektorientierten Implemetierung der Feature-basierten Methode liegt für Rösel auf der Hand. "Netzleittechniker etwa erhalten ein Abbild von zigtausend Schaltern."
Die Objekte, mit denen sie auf dem Bildschirm umgehen, enthalten entsprechende Verhaltens- und Kommunikationsregeln. Ähnliches auch im Bereich Dampfkraftwerke: Hier darf eine Turbine Dampf akzeptieren, nicht aber Wasser, und ein Hitzeaustauscher läßt jeweils zwei Wasser- und zwei Dampfverbindungen zu. Bei der Planung ist somit unmittelbar eine Plausibilitätsprüfung möglich, ohne eine aufwendige Regeldatenbank pflegen zu müssen.
Andererseits können Änderungen auf dem Bildschirm Folgen in der Realität haben und umgekehrt. Steigt etwa die Temperatur einer Turbine über Gebühr, blinkt es in der grafischen Darstellung. "Das ist der große Aha-Effekt bei den Ingenieuren. Was früher im Kopf der Leute, auf dem Bildschirm und daneben auf dem Papier in der technischen Zeichnung enthalten war, haben wir in Software gegossen", so Rösel.
Die Geschäftsbereiche allerdings, die kein fertiges Produkt von der Forschungsabteilung bekommen, sondern mit ihr zusammen auf der Basis des Frameworks entwickeln müssen, sind zunächst gezwungen, in die Objekttechnologie einzusteigen. Bis Entwickler, die den Technologiesprung wagen, produktiv arbeiten können, vergehen in der Regel sechs bis acht Monate. Sie müssen sich die objektorientierten Paradigmen zu Gemüte führen, C++ lernen, das Framework einsetzen sowie mit einer Reihe anderer neuer Tools umgehen können. "Doch die Zeitersparnis, die die Wiederverwendung ab dem dritten Projekt ermöglicht, ist einfach überwältigend", begeistert sich Rösel. "Bestenfalls wäre es bei traditioneller Entwicklung, bei der ich in jedem Projekt wieder von vorne anfangen und alles komplett neu entwickeln muß, möglich gewesen, ganze Anwendungsteile zu kopieren. Doch das Portieren von einer Plattform auf die andere wäre mir auch dann nicht erspart geblieben."
Die ABB-IT-Forscher verwenden C++, wie Rösel jedoch einschränkt, nur die objektorientierten Elemente. Der Grund für die Sprachwahl lag hauptsächlich in der Akzeptanz seitens der anderen ABB-Geschäftsbereiche, die häufig in C programmieren. Dennoch entstand der erste Framework-Prototyp 1993 in Smalltalk.
Für die Dokumentation und die Verwaltung der Framework-Klassen benutzt das ABB-Team das Konfigurationswerkzeug "PVCS" von Intersolv sowie das CASE-Werkzeug "Together C++". Dennoch, so Wilcke, wird die Information über die Veränderungen im Framework nur durch gemeinsame Projekte übermittelt. Ein "Kochbuch", das Rezepte enthält, auf welche Weise die Änderungen vorzunehmen sind, gibt es noch nicht. "Dafür hätte die Dokumentation des Frameworks früher einsetzen müssen", so die Entwickler aus heutiger Sicht.
Ungeklärt ist bei ABB derzeit die Frage, wer den Softwarerahmen auf Dauer pflegen soll. Noch sind die Entwickler aus dem Forschungszentrum damit betraut. Sie entscheiden von Fall zu Fall darüber, ob dem Framework etwas hinzugefügt werden soll, das aus der Projektarbeit zurückfließt. Dabei besteht ein grundsätzlicher Konflikt. Damit das Framework möglichst universell sein kann, darf es nicht zu viele Komponenten enthalten. Die Anwendungsentwickler möchten jedoch soviel wie möglich vorgefertigt erhalten. "Wir gehen da ganz pragmatisch vor", äußert sich Rösel. "Der Wunsch, ein neues Feature hinzuzufügen, kann schon ganz anders aussehen, wenn eine Nacht darüber geschlafen wurde. Häufig stellt man fest, daß auch das Vorhandene dieselbe Aufgabe lösen kann..
IT-Forschung bei ABB
Die Asea Brown Boveri AG (ABB), Mannheim, ein internationaler Konzern, ist für ihre Aktivitäten in den Bereichen Elektro-, Verkehrs- und Umwelttechnik bekannt. Die Unternehmensgruppe verfügt über rund 34 000 Mitarbeiter und erzielte im vergangenen Jahr einen Umsatz von rund zehn Milliarden Mark. Rund acht Prozent des Umsatzes fließen jährlich in die Forschung und Entwicklung.
Das ABB-Forschungszentrum, Heidelberg, arbeitet in dem weltweiten Forschungsverbund in der Material- und Oberflächentechnologie, der computergestützten Modellierung und Simulation, der industriellen Elektronik und Sensorik sowie in der Elektroernergietechnik. Rund ein Viertel der 200 Beschäftigten hat den Auftrag, Neuerungen in der Informationstechnologie für den Konzern nutzbar zu machen.