Software-Modellierung - was sich wirklich lohnt

"Wenn ich Fachartikel über modellgetriebene Software-Entwicklung lese, komme ich mir vor wie Asterix", sagt Daniel Tobler, Software-Architekt beim Technologie- und Beratungsunternehmen Zühlke. Software hat zu wenig Standards, Modellierungsexperten sprechen an Entwicklern vorbei. Keiner versteht den anderen. Viele Abkürzungen und haufenweise Theorie prägen die Debatte. Was fehle, sei eine knackige, praxistaugliche Modellierungssprache, bringt Tobler die Sache auf den Punkt. Trotzdem gibt es aus der Praxis ansehnliche Erfolge zu vermelden.

Fallbeispiel Phonak

Etwa bei der Phonak Communications AG, einem Unternehmen, das sich auf Hörgeräte und miniaturisierte Kommunikationslösungen spezialisiert hat. Dort wurde das Projekt inspiro, das die Entwicklung eines stark softwarebasierten Miniatur-Senders zum Ziel hatte, in zwölf Monaten erfolgreich durchgezogen. Als Modellierungsplattform kam IBMs Rhapsody zum Einsatz. Anfangs musste das Management die Nörgeleien seiner Programmierer über sich ergehen lassen: Bis wir Rhapsody kennen und das Software-Modell aufgesetzt haben, programmieren wir die Sache doch lieber gleich in C/C++, frotzelten die Entwickler.

40 bis 50 Prozent in Rhapsody modelliert

Der Erfolg hat jedoch letztlich alle überzeugt. "Das Projekt inspiro hat Software in guter Qualität abgeliefert", resümiert Dr. Rainer Platz, F&E-Direktor bei Phonak. Der Miniatursender inspiro wurde bis heute weltweit etwa 10.000 Mal verkauft. "Wir haben 40 bis 50 Prozent des Quellcodes von inspiro in Rhapsody modelliert", schätzt Platz. Jedoch hatte das Projektteam auch mit Problemen zu kämpfen. Die Hauptschwierigkeiten lagen in der Integration der verschiedenen Layer, also dem Zusammenspiel zwischen dem Betriebssystem, den in Rhapsody modellierten Komponenten und den von Phonak (ohne Rhapsody) entwickelten Treibern und proprietären Software-Blöcken. Allgemein wurde der Aufwand unterschätzt, resümiert Platz.

Echter Mehrwert

"Erst bei längerer Nutzung generieren Software-Modellierwerkzeuge echten Mehrtwert", urteilt Wolfgang Boos, Manager Software-Entwicklung bei Mettler-Toledo, einem Anbieter von Präzisionsinstrumenten. Auch Mettler-Toledo benutzt Rhapsody für die Modellierung eingebetteter Systeme. Den Hauptvorteil von Modellierwerkzeugen sieht Boos im höheren Abstraktionsniveau beim Software-Entwurf, was die Kommunikation mit Fachabteilungen wesentlich erleichtert. Ausserdem könne man sich schneller in die Software einarbeiten. Kürzere Entwicklungszeiten lassen sich aber nur zusammen mit auf Komponenten basierenden Ansätzen, also etwa domänenspezifischen Sprachen (DSL domain specific language) und "Software Product line"-Strategien, erzielen. Ein grosses Potenzial und eine hohe Dynamik macht Boos ausserdem beim Eclipse Modelling Framework (EMF) für Java-Entwickler aus.

Mehr Freiheit mit openArchitectureWare

Mit Rhapsody kann man zwar schnell produktiv gehen, jedoch sind der Einsatzbereich des Werkzeuges begrenzt und die Lizenzen teuer. So mancher CIO bekommt beim Blick auf die Rechnung erstmal einen Schreck. Rhapsody biete sich vor allem für Zustandsmodelle an, fasst Software-Architekt Daniel Tobler zusammen. Alternative Open-Source-Lösungen wie openArchitectureWare (oAW) decken demgegenüber zwar einen breiten Einsatzbereich ab, benötigen aber einen eigenen Codegenerator (oder sogar DSL), um lauffähigen Quellcode zu erzeugen. OAW unterstützt EMF und sei ideal, wenn grosse Freiheit bei der Modellierung wichtig sei. Zudem seien die Kosten für Generator und DSL exakt quantifizierbar, so Tobler.

Do-it-yourself-Technik Eigencodierung

Zur klassischen Do-it-yourself-Technik, also dem traditionellen Kodieren ohne Modellier-Werkzeuge, sollten Software-Entwickler nur dann greifen, wenn das auch tatsächlich Sinn macht. Denn das fehlende Abstraktionsniveau erschwert die Diskussion mit Fachabteilungen, Schnell sieht man den Wald vor lauter Bäumen nicht mehr. Ausserdem sei der Aufwand für doppelte und dreifache Implementationen nicht quantifizierbar, betont Tobler. Fazit der Late Afternoon Talks bei Zühlke: Software-Modellierung so oft wie möglich, Eigenkodierung nur dann, wenn nötig.