Produktivitätssteigerung in der Softwareentwicklung wird eine der grossen Wellen der nächsten Jahre. Die Innovationen werden dabei im Bereich der generativen Programmierung, der modellgetriebenen Entwicklung und der integrierten Entwicklungswerkzeuge stattfinden. In klassischen Bereichen wie Architekturen, Programmiersprachen und Plattformen sind hingegen keine grossen Veränderungen zu erwarten. Zeit, sich praxisorientiert mit diesem Megatrend auseinanderzusetzen. Was ist heute schon praktisch machbar? In welche Richtung werden wir uns bewegen?
Die Individualentwicklung von Softwarelösungen ist in vielen Bereichen unumgänglich. Die Lösungen entstehen teilweise grundlegend neu, teilweise werden sie basierend auf bestehenden Weltmodellen mittels Customizing umgesetzt. Letzteres findet vor allem im ERP- und CRM-Bereich statt. Viele dieser heute realisierten Lösungen leiden unter den Problemen der Kosten und der Starrheit. Der Initialaufwand scheint wirtschaftlich gross, und die Anpassungen der Lösung an neue wirtschaftliche Gegebenheiten sind teuer und nehmen viel Zeit in Anspruch.
Dies lässt einige Unternehmen ein Off-Shoring von Entwicklungsprojekten zumindest prüfen. Beim Off-Shoring handelt es sich jedoch um eine ausgesprochen langfristige Strategie mit zahlreichen inhärenten Risiken, die zudem nicht universell anwendbar ist.
Volkswirtschaftlich betrachtet führt kein Weg an einer Steigerung der Entwicklungsproduktivität der heimischen IT-Industrie vorbei. Die Rezepte aus der industriellen Fertigung sind dabei jedoch auf die Softwareentwicklung nur sehr bedingt anwendbar. Denn die Individualentwicklung von Softwarelösungen ist kein industrieller Fertigungsprozess, sondern ein Designprozess. Diese Ausgangslage bedingt neue Denkansätze.
Komponenten der Software-Entwicklung
Der Kern dieser Ansätze besteht darin, die Softwareentwicklung auf eine höhere Ebene zu bringen. Wenn wir die Softwareentwicklung als Brücke zwischen Business und Technologie betrachten, so muss sie im Durchschnitt näher zum Business und weiter weg von der Technologie rücken. Auf diese Weise arbeitet der Entwickler auf einer höheren Stufe, seine Produktivität steigt und die resultierenden Lösungen sind schneller änderbar.
Der Weg zu diesem Ziel führt über drei Bereiche:
• Softwarearchitektur
• Generative Programmierung und modellgetriebene Entwicklung
• Integrierte Entwicklungswerkzeuge.
An den Softwarearchitekturen der J2EE- und .NET-Plattform ändert sich dabei nichts. Die bekannten Architekturmuster, im Falle von Java beispielsweise JSP- und EJB-Komponenten, bleiben unverändert. Eine typische individuell entwickelte Softwarelösung besteht nach wie vor aus den logischen Schichten Basistechnologie, Business Domain Solution und Customizing.
Was dagegen ändert, ist der Weg, wie wir zu den Lösungen gelangen. Der neue Weg führt über generative Programmierung, modellgetriebene Entwicklung und integrierte Entwicklungswerkzeuge. Auch diese Ansätze sind a priori nicht fundamental neu. Generative Programmierung wird beispielsweise seit über zehn Jahren in Bereichen wie RPC oder SQL Precompilation eingesetzt. Und jede IDE enthält letztlich integrierte Entwicklungswerkzeuge auf fundamentaler Stufe. Was effektiv neu ist, ist jedoch die Tiefe des Einsatzgebietes der Ansätze.
Zum ersten wird der Einsatz von generativer Programmierung und integrierten Entwicklungswerkzeugen im Bereich der Basistechnologie massiv intensiviert (horizontale Spezialisierung). Zum zweiten werden diese Ansätze in die Bereiche der Business Domain Solution und des Customizing hineingetragen, was das eigentliche Novum ist (vertikale Spezialisierung). Während bisherige Generatoren und Entwicklungswerkzeuge nur allgemeine, fundamentale Technologien abgedeckt haben, werden von denselben Technologien nun also vermehrt Spezialgebiete erfasst. Und genau dies ermöglicht dem Entwickler, näher am Business zu arbeiten und damit seine Produktivität zu steigern.
Dazu Beispiele aus der Praxis :
• Eine Java-Basiskomponente von Ergon, eingesetzt in Banken- und Telecomapplikationen, kapselt den Zugriff auf die Datenbank. Die Bibliothek umfasst neben Laufzeitkomponenten auch Werkzeuge für die Entwicklung und den Betrieb. Diese Werkzeuge unterstützen die Erstellung und Migration des physikalischen Datenbankschemas basierend auf einem logischen Data Dictionary sowie die Erstellung von Transfer-Objekten (typsicheren Wrapper-Klassen für Datensätze). Die Werkzeuge standen in der Vergangenheit nur auf der Kommandozeile zur Verfügung. Im laufenden Jahr wurden diese Werkzeuge nun portiert und als Plug-ins in die Eclipse-IDE umgesetzt. Die Pflege des Datenbankschemas ist nun auf einfache Weise aus der Entwicklungsumgebung heraus möglich. Ebenso erfolgt die Generierung von Transfer-Objekten automatisch beim Speichern der Tabellendefinition im Data Dictionary in der IDE. Diese Neuerungen steigern nicht nur die Produktivität in der Entwicklung, sondern erhöhen auch die Akzeptanz beim Kunden, der sich vermehrt selber helfen können will. Dies ist ein Beispiel einer horizontalen Spezialisierung, da die entsprechenden Komponenten und Werkzeuge basistechnologischen Charakter haben und nicht spezifisch für eine bestimmte Business Domain oder Lösung vorgesehen sind.
• Im Trading-Monitor, den Ergon für eine Schweizer Grossbank entwickelt hat, werden viele Informationen aus dem unterliegenden Wertschriftenhandelssystem visualisiert. Ergon war in diesem Bereich mit der Herausforderung konfrontiert, den Monitor bei einem neuen Release des Wertschriftenhandels schnellstmöglich anzupassen. Hierzu wurde ein lösungsspezifisches Framework aus Code-Generatoren und Entwicklungswerkzeugen umgesetzt. Das Framework enthält Deskriptoren im XML-Format, welche für alle Releases des Handelssystems die jeweilige Abbildung in den Trading-Monitor beschreiben. Serviceklassen, User Interfaces und zahlreiche weitere Elemente des Trading-Monitors werden vollautomatisch aus diesen Deskriptoren für den jeweiligen Release des Handelssystems generiert. Das System kann damit an viele Änderungen ohne Programmieraufwand angepasst werden. Dies ist ein Beispiel einer vertikalen Spezialisierung, d.h. einer Spezialisierung, die in die spezifische Lösung hineingeht.
Höhere Produktivität durch Spezialisierung
Unter generativer Programmierung wird ganz allgemein die Verwendung sogenannter Generatoren zur automatischen Erzeugung von Source Code verstanden. Eng mit der generativen Programmierung verknüpft ist die modellgetriebene Softwareentwicklung. Diese fokussiert die Softwareentwicklung durch Modellierung des Systems. Die Lösung wird anschliessend ganz oder teilweise aus den Modellen generiert (Transformation).
Die modellgetriebene Softwareentwicklung kann dabei als logischer Ausbau der Transformationskette zwischen Entwickler und Maschine betrachtet werden. Zu Beginn der Softwareentwicklung wurden Programme noch direkt in Maschinensprache geschrieben. Später haben Compiler die Generierung des Maschinencodes übernommen, so dass der Entwickler mit einer Hochsprache arbeiten konnte. Mit der modellgetriebenen Entwicklung erhält der Entwickler nun eine noch höher liegende «Modellsprache» zur Verfügung gestellt. Der Generator erstellt daraus den Source Code, und der Compiler übersetzt den Source Code in Maschinensprache beziehungsweise Zwischencode (Java Byte Code, MSIL).
Diese einleuchtende Kontinuitätsanalogie hat jedoch ihre Grenzen. Ein ganz wesentlicher Unterschied zwischen einer Hochsprache und einer Modellsprache ist, dass die Hochsprache bedeutend universeller einsetzbar ist. Es ist möglich, eine ganze Lösung durchgängig in der Hochsprache zu schreiben. Die durchgängige Modellierung einer Lösung in einer Modellsprache ist hingegen in der Regel nicht möglich. Der Abstraktionsgrad einer derart universellen Modellsprache, wenn es sie denn gäbe, wäre nach unserer Auffassung viel zu hoch. Wir gehen deshalb davon aus, dass Applikationen heute und zukünftig aus verschiedenen spezialisierten Modellsprachen generiert werden und wesentliche Anteile einer Lösung von Hand auscodiert bleiben. Dies hat zur Folge, dass wir mit der Herausforderung des «Mixed Language Programming» konfrontiert sind. In einer Lösung werden verschiedene Modellsprachen sowie eine Hochsprache kombiniert eingesetzt.
Vor diesem Hintergrund stellen sich derzeit spannende Fragen wie diese: Welche Einsatzgebiete eignen sich für modellgetriebene Entwicklung und welche nicht? Was sind konkrete Ansätze zur Kombination der verschiedenen Sprachen? Im folgenden stellen wir unsere Erfahrungen in einer Checkliste zusammen:
•
Modellgetriebene Entwicklung funktioniert dort gut, wo Modelle bereits etabliert sind. Typische Bereiche sind folglich Datenmodelle, Datenaustauschformate (insbesondere XML), Tabellen und Masken, Workflow-Prozesse, State Machines und Real-Time-Systeme. Alle diese Bereiche haben traditionell einen starken Fokus auf Modellierung.
•
Keine Anpassung des generierten Codes. Es darf nicht notwendig sein, den generierten Code anzupassen. In diesem Fall würde die Fähigkeit zur Regenerierung dieses Codes bei einer Änderung des Modells verlorengehen. Ein typischer Lösungsansatz in der objektorientierten Entwicklung besteht darin, eine Klasse vollständig zu generieren, jedoch nicht direkt zu verwenden. Statt dessen wird die generierte Klasse in einer von Hand codierten Klasse beerbt oder aggregiert. Dies erlaubt die effektive Kombination von generiertem Code mit von Hand geschriebenem.
•
Abstraktion in vernünftigem Rahmen halten. Durch modellgetriebene Softwareentwicklung nimmt die Distanz zwischen Entwickler und Maschine zu. Dies ist gewollt und sinnvoll. Es ist jedoch auch wichtig, diesen Bogen nicht zu überspannen. Der zunehmende Abstraktionsgrad der Tätigkeit muss mit einer stärkeren Spezialisierung der eingesetzten Werkzeuge kompensiert werden. Das Ziel besteht deshalb für die Massenanwendung nicht darin, möglichst universelle Werkzeuge einzusetzen, sondern spezialisierte Werkzeuge, die mit vertretbarem Aufwand erlernt und verstanden werden können. Wenn Flexibilität und Abstraktion zu gross werden, steigen die Risiken überproportional.
Entwicklung rückt näher zum Business
Durch die generativen und modellgetriebenen Ansätze steigt die Komplexität der Entwicklungs- und Build-Umgebungen deutlich an. Damit die Produktivitätsgewinne nicht durch die gesteigerte Komplexität der Entwicklungstätigkeit «aufgefressen» werden, ist es essentiell, die entsprechenden Werkzeuge dem Entwickler in hochintegrierter Form anzubieten.
Hierzu hat in der Java-Welt die Eclipse-Plattform eine wesentliche Grundlage geschaffen. Die Plattform präsentiert sich als IDE für alles und nichts. Sie ist eine IDE für nichts, da sie von Haus aus über keine fest eingebauten spezialisierten Funktionen verfügt. Und sie ist ein IDE für alles, da beliebige neue Funktionalitäten und Erweiterungen bestehender Funktionalitäten über Plug-ins bereitgestellt und dicht in die Plattform integriert werden können.
Der Fokus liegt bei den integrierten Entwicklungswerkzeugen ganz klar auf der Dichte der gegenseitigen Integration. Deren Bedeutung steigt, weil die Komplexität der Entwicklungstätigkeit zunimmt und durch die dicht integrierten Werkzeuge abgefedert werden muss.
Ein weiterer Aspekt der integrierten Entwicklungswerkzeuge betrifft die Grenze zwischen Softwareentwickler und Kunden. Kunden wollen sich vermehrt selber helfen können. Dicht integrierte, unter Umständen lösungsspezifische Werkzeuge schaffen hierfür eine wesentliche Voraussetzung und steigern die Akzeptanz eines Lösungsansatzes beim Kunden klar. Wir gehen davon aus, dass dieser Trend mittelfristig zu einer weiteren Aufweichung und Verschiebung der Grenze zwischen Softwareentwickler und Kunde führen wird. Der Kunde kann auf die Leistungen seines Lieferanten feingranularer und damit kostenoptimierter zugreifen.
Durch die Verschiebung der Entwicklungstätigkeit näher zum Business und weiter weg von der Technologie entsteht zwischen der Technologie und der neu angesiedelten Entwicklungstätigkeit eine Lücke, die geschlossen werden muss. Diese Lücke entspricht den Generatoren und integrierten Entwicklungswerkzeugen, welche den neuen Ansatz überhaupt Realität werden lassen.
Wie diese Lücke letztlich geschlossen wird, ist heute noch nicht klar. Derzeit wird mit vielen Ansätzen experimentiert (MDA, Softwarefabriken etc.). Die Ansätze lassen sich grob wie folgt klassifizieren:
• Produktansatz: Dieser Ansatz sieht eine Standardisierung der Modell- und Metamodellsprachen vor, so dass universelle Werkzeuge von Produktanbietern angeboten werden können. Die lösungsspezifischen Werkzeuge, Transformationen und Modelle werden mittels dieser Produkte modelliert.
• Framework-Ansatz: Dieser Ansatz sieht die Bereitstellung von Frameworks zur Entwicklung von Werkzeugen für die generative und modellgetriebene Softwareentwicklung vor. Die Werkzeuge werden basierend auf diesen Frameworks programmiert.
Welcher konkrete Ansatz oder (wahrscheinlicher) welche Kombination von Ansätzen sich letztlich durchsetzen wird, ist heute noch nicht absehbar. Während in der strategischen Frage der Plattformen derzeit wenig Bewegung herrscht, stellen sich für die Unternehmen damit neue strategische Fragen auf der Stufe der Entwicklungsmethodiken für Plattformen. Letztlich handelt es sich auch hier um eine Make-or-Buy-Frage, allerdings nicht betreffend der Lösungen, sondern betreffend der Werkzeuge, mit welchen Lösungen realisiert werden.
Auf jeden Fall zu rechnen ist mit einer gewissen vertikalen Desintegration in der IT- Industrie. Wir gehen davon aus, dass es eine verstärkte Segmentierung zwischen Entwicklern von Softwareentwicklungswerkzeugen und Anwendern von Softwareentwicklungswerkzeugen geben wird. Eine ähnliche Segmentierung war in den letzten zehn Jahren bereits im Bereich der Softwarekomponenten zu beobachten.
André Naef (andre.naef@ergon.ch) ist Dipl. Informatik-Ing. ETH und Senior Consultant bei der Ergon Informatik AG. Er konzentriert sich auf die Architektur und Realisierung von daten- und prozessorientierten Lösungen im J2EE-Umfeld.
