Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

14.05.2004 - 

Trends in der Softwareentwicklung/Die Branche träumt von der flexiblen Softwarefabrik

Programmieren ist nicht mehr angesagt

Glaubt man den Visionären der Softwareentwicklung, dann gibt es bald nur noch zwei Varianten einer Vorgehensweise. Softwarehäuser wie Anwenderunternehmen gestalten ein Softwaresystem auf Basis von Geschäftsanforderungen. Umgesetzt wird es dann entweder von den Codierknechten eines Dienstleisters oder aber durch fabrikähnliche Mechanismen. Von Hermann Gfaller*

Der Traum von der Softwarefabrik ist alles andere als neu. Anno 1968 wurde auf einer Nato-Tagung in Garmisch-Partenkirchen die Forderung nach Software-Engineering, sprich nach ingenieurmäßig geplanten und konstruierten Anwendungen, erhoben. Immer wieder glaubte man, dem Ziel nahe zu sein, zuletzt in den 80er Jahren durch Softwaregeneratoren der 4. Generation und durch so genanntes Computer Aided Software Engineering (Case). Nun ist es wieder so weit.

Zwei Standardisierungsschübe haben der Branche den Mut zu einer Neuauflage von Case gegeben, das heute vor allem unter dem Begriff Model Driven Architecture (MDA) heiß diskutiert wird. Zum einen haben sich Ende der 90er Jahre die drei Entwicklungspäpste Grady Booch, James Rumbaugh und Ivar Jacobson auf eine visuelle Nomenklatur zur Darstellung und Gestaltung von Softwareprojekten geeinigt, die als Unified Modelling Language (UML) Furore machte. Sie bildet heute eine gemeinsame Sprache, auf der sich Entwickler über ihre Aufgaben auf einer abstrakten, im Prinzip plattformunabhängigen Ebene verständigen können. Um UML herum sind Werkzeuge und Verfahren entstanden, mit deren Hilfe nun aus den abstrakten Regeln - wie einst mit Case-Tools - plattformspezifischer Code weitgehend automatisch zu generieren sein soll.

Der Internet-Boom der 90er Jahre sorgte für eine zweite Standardisierungswelle, die einen solchen Ansatz heute als möglicherweise umsetzbar erscheinen lässt. Weil sich selbst die größten Konzerne nicht in der Lage sahen, das Internet für sich zu vereinnahmen, wurden viele Techniken zur Eroberung des weltweiten Netzes allen Marktteilnehmern und Nutzern zur Verfügung gestellt. So etablierten sich offene Standards wie das Web, das Darstellungverfahren HTML, die Java-Plattform mit dem Konzept des "Write once, run everywhere", das offene Standardformat für Datenübermittlung XML, Microsofts Internet-Variante des Funktionsaufrufs Soap und daraus die Web-Services als Standard für lose gekoppelte Anwendungen, und viele mehr. Gremien wie W3C, Object Management Group (OMG), Organization for the Advancement of Structured Information Standards (Oasis), die Web Services Interoperability Organization (WS-I) und andere produzieren ständig neue offene Standards. Einige Hersteller geben ihre Entwicklungen für die allgemeine Nutzung frei, so etwa mit Einschränkungen Sun Java, Microsofts Soap oder IBM die Java-Entwicklungsumgebung Eclipse.

All diese Komponenten sollen sich zu einer lückenlosen Kette fügen, die es ermöglicht, Softwareprojekte von der Geschäftsanforderung über die plattformunabhängige Modellierung bis zur Codierung in Java oder C# zu automatisieren. Dabei ist zu berücksichtigen, dass moderne Anwendungen über unzählige Schnittstellen in eine komplexe IT-Umgebung eingebunden sein müssen. Hier die Integration zu vereinfachen gehört zu den zentralen Aufgaben von Web-Services und dem Projekt einer darauf aufbauenden Service Oriented Architecture (SOA).

So gewaltig die Vorhaben sind, so groß ist der Optimismus. Bei der IBM-Tochter Rational gehen die UML-Pioniere davon aus, dass sich inzwischen in der Regel 90 Prozent des Codes über die Model Driven Architecture der OMG generieren lassen. Neben den erwähnten Standards spielen dabei auf Designebene Musterlösungen wie Patterns eine ähnlich wichtige Rolle wie die Klassenbibliotheken auf der technischen Seite. Routineaufgaben werden einmal gelöst und dann immer wieder bei Bedarf eingebunden. Laut Chris Haddad, Senior Consultant der Burton Group, gibt es inzwischen nicht mehr viele Technologielücken zwischen Modell und Umsetzung. Zwar sind weder MDA noch SOA plattformspezifisch konzipiert, de facto aber stehen für eine weitgehend lückenlose Umsetzung der Konzepte fast nur Internet-Techniken und Standards zur Verfügung. Ältere IT-Komponenten wie Mainframe-Systeme und Backend-Datenbanken werden üblicherweise über Web-Services, Browser-Frontends oder Konnektoren für Web-Application-Server eingebunden.

Kostenzwänge zeigen Wirkung

Weit mehr als zu Case-Zeiten stecken hinter MDA und SOA nicht Technologievisionen, sondern betriebswirtschaftliche Forderungen. Dem Modebegriff IT- oder Code-Governance folgend, verlangen die Geschäftsleitungen, dass wie in den anderen Unternehmensbereichen wirtschaftlich bewertbare Prozesse eingeführt werden. Die Kosten für die in Jahrzehnten gewachsenen, heterogenen IT-Landschaften sollen sinken, gleichzeitig aber Geschäftsideen möglichst über Nacht DV-technisch unterstützt werden. Bei der Softwareentwicklung zählt daher nicht mehr nur, dass zum Schluss ein lauffähiges Programm herauskommt. Wichtig ist inzwischen, dass mit Hilfe geordneter Prozesse Qualität und Zeitplan ebenso gesichert werden wie die spätere Wartbarkeit des Codes und die Möglichkeit, die Anwendung in eine sich ständig verändernde IT-Umgebung einzupassen.

Für die IT-Abteilungen bedeutet das, zum einen die Integration ihrer Systeme voranzutreiben und sie andererseits so offen zu halten, dass sie sich rasch ändern und ergänzen lassen. Als Integrations-Schnittstelle erster Ordnung haben sich in den vergangenen Jahren Web-Services herauskristallisiert. Aus den Erfahrungen damit ist die Idee entstanden, die gesamte Softwareinfrastruktur lose über eine Service-orientierte Architektur zu koppeln, sprich die Schnittstellen der Programme so zu exponieren, dass sie nahezu beliebig erweiterbar sind. Im Grunde wird hier die Idee der Componentware aus den 80er Jahren wieder belebt. Damals hatte die Branche davon geträumt, Softwarekomponenten zu beliebigen Anwendungen zu kombinieren.

Die Konzepte hinter SOA sind allerdings weiter gesteckt. Sie zielen darauf ab, alle Anwendungen und Anwendungskomponenten im Unternehmen und eventuell darüber hinaus zu einem so genannten Virtual Enterprise Network (VEN) zu integrieren. Auf diese Weise soll ein lose über Service-Schnittstellen verknüpfter Anwendungsverbund entstehen, der sich rasch an veränderte Anforderungen anpassen lässt. Grundsätzlich ist die SOA ein plattformunabhängiges Konzept für den Entwurf von Systemumgebungen, de facto jedoch bieten derzeit fast nur die Web-Service-Standards die Möglichkeit, ein VEN aufzubauen. Dadurch erhält das Konzept zwei Stoßrichtungen. Zum einen zielt es in Kombination mit Web-Application-Server auf die Ablösung der bisherigen Werkzeuge und Produkte für Enterprise Application Integration (EAI), zum anderen konkurrieren Web-Services mit dem klassischen Client-Server-Konzept.

EAI-Anbieter denken um

Tatsächlich sind die EAI-Anbieter inzwischen dabei, sich auf Web-Service-Technik einzustellen. Ob Web-Services Client-Server-Architekturen ersetzen können, ist jedoch keineswegs ausgemacht. So ist es zwar meist möglich, im Unternehmen verteilte Dienste auf einem Portal zusammenzuführen, andererseits scheint es durchaus sinnvoll zu sein, etwa alle Funktionen einer Textverarbeitung oder einer Kundendienstsoftware in einem Paket zusammenzufassen. Wer will schon die Rechtschreibprüfung nach jedem Brief - womöglich kostenpflichtig - als Dienst über das Web beziehen.

Der Forderung der Geschäftsführung nach kontrollierten und kostengünstigen Prozessen sollen Entwickler durch Verwendung unternehmensweit geltender Regeln in allen Phasen der Softwareentwicklung nachkommen. Auf Designebene gehört hier UML zu den wichtigsten Hilfsmitteln. Da jedoch laut Burton Group die Zahl der IT-Verantwortlichen zunimmt, die wenig von Technik verstehen, bietet sich als Mittel zur Kosten- und Qualitätskontrolle auch an, Entwicklungsaufgaben an Dienstleister zu vergeben. Wer auch immer für die Entwicklung verantwortlich zeichnet, wird zudem aus Kostengründen stupide Programmieraufgaben in Offshore-Länder verlagern. Die teuren Entwickler in den USA oder Europa werden sich laut Haddad auf Design und Modelling konzentrieren.

Diese sich abzeichnende Arbeitsteilung in Softwarearchitekten und Programmierknechte ist alles andere als unproblematisch. So befürchtet Haddad, dass es den Architekten über kurz oder lang an den nötigen Programmierkenntnissen fehlen wird. Zwar ist Modellierung vom Konzept her plattformunabhängig, dennoch eignen sich dafür nur erfahrene Programmierer, die klare Vorstellungen davon entwickeln können, welche Auswirkungen ihre abstrakten Entwürfe auf den C#- oder Java-Code haben werden. Auch müssen einige technische Entscheidungen sehr früh im Modellierungsprozess gefällt werden. Dazu gehört beispielsweise, ob es sich um eine Mainframe-, eine Client-Server- oder eine Web-Anwendung handeln soll.

Ein eher psychologisches Problem besteht darin, dass gerade gute Programmierer dazu neigen, die Geduld mit dem langwierigen Modellierungsprozess zu verlieren. Je besser ihnen die UML dabei geholfen hat, die Aufgabe zu erfassen, desto eher drängt es sie, mit dem Programmieren zu beginnen. Schwierig ist für Programmierfachleute auch, dass sie einen im Sourcecode gefundenen Fehler nicht sofort, sondern erst nach aufwändiger Abstraktion im Modell beheben dürfen. Laut Holger Dörnemann, IBM-Technical Sales Manager bei Rational Software, ist das jedoch ein Anfängerfehler, der sich gibt, sobald der Entwickler erkennt, wie leicht sich eine sauber modellierte Software auf Modellebene verändern und neu generieren lässt.

Zweifel am lückenlosen Roundtrip

Genau an diesem auch als Roundtrip bezeichneten Verfahren setzt jedoch die Kritik vieler Programmierer an. Da es sich bei UML um eine Abstraktion der Möglichkeiten von Programmiersprachen handelt, um eine Art Metasprache, liegt es in der Natur der Sache, dass bei der Rückführung eines Codes in das Modell Uneindeutigkeiten entstehen. Es ist so, als würde ein Hocker plötzlich als Sitzgelegenheit bezeichnet. Solche Uneindeutigkeiten lassen sich durch so genannte Patterns verringern. Es handelt sich dabei um Musterlösungen, die zum einen brauchbare UML-Diagramme liefern, zum anderen die Vorschriften für ihre Umsetzung in eine spezifische Programmiersprache enthalten.

Eine andere Möglichkeit besteht darin, UML semantisch anzureichern, bis sie die Mächtigkeit der gewünschten Programmiersprache erreicht. Damit jedoch verlieren sich die Vorteile der Abstraktion, für die man das Modelling eigentlich entwickelt hat. Unternehmensberater Dieter Jenz vertritt allerdings die Ansicht, dass Modelle gerade für geschäftliche Anwendungen nicht reichhaltig genug sein können. Er empfiehlt daher, UML um so genannte Ontologien zu erweitern, sprich um eine auf bestimmte Wissensbereiche zugeschnittene Terminologie, so etwa für die Geschäftsprozess-Modellierung. Eine Alternative zur Modellierung generell stellt die Ercaton-Methode der Münchner Living Pages Research GmbH dar, die auf XML beruht und sich für J2EE-Projekte eignet. Sie soll einfacher zu handhaben sein als Modellierung und eine höhere Wiederverwendungsquote bieten als Objektorientierung. (ue)

*Hermann Gfaller ist freier Fachjournalist in München.

Hier lesen Sie ...

- welche Richtung das Computer Aided Software Engineering (Case) genommen hat;

- welche Rolle dabei die Model Driven Architecture (MDA) und die Unified Modelling Language (UML) spielen;

- dass alle Entwicklungskonzepte im Idealfall plattformunabhängig in einer Service-orientierten Architektur (SOA) und einem Virtual Enterprise Network münden.

Java versus .NET

Böse Zungen behaupten, dass .NET nicht viel mehr als ein mit proprietären Funktionen ausgestatteter Clone der Java-Plattform ist. Tatsächlich sind sich die Analysten der Burton Group und die IBM-Rational-Mitarbeiter einig, dass zumindest die Programmiersprachen Java und C# zu rund 80 Prozent identisch sind. Wenn sich die beiden Lager dennoch seit Jahren bekriegen, so liegt das nicht zuletzt an ganz unterschiedlichen Grundkonzepten. Java-Programme sollen unabhängig von Hardware oder Betriebsystem überall in einer Browser-Umgebung lauffähig sein. .NET dagegen ist für die Windows-Umgebung konzipiert, unterstützt dafür aber eine ganze Reihe von Programmiersprachen. Außerdem wurde das Microsoft-Produkt von Anfang an mit Just-in-Time-Compiler auf Geschwindigkeit getrimmt, während Sun mit dem Sandbox-Konzept auf Sicherheit im Web gesetzt hat.

In den vergangenen Jahren hat Microsoft mit seiner Entwicklungsumgebung Visual Studio immer mehr Boden gegenüber Java gutgemacht. Auftrieb hat Java derweil von IBM erhalten, die ihr Eclipse-Projekt der Open-Source-Gemeinde vermachte. Dabei handelt es sich nicht nur um eine Entwicklungsplattform, sondern vor allem um eine hochproduktive Architektur zur Herstellung von Werkzeugen. Selbst Suns Java-Guru James Gosling "liebt" Eclipse, obwohl seiner Company die Konkurrenz für die eigenen Beans nicht schmeckt.

Doch nun wird sich alles ändern: Sun und Microsoft haben nicht nur vor Gericht Frieden geschlossen, sondern darüber hinaus gelobt, dafür zu sorgen, dass Java und .NET weit besser als bisher zusammenarbeiten. Noch weiß man nichts Genaues in Sachen Interoperabilität. Doch Programmierer hoffen, vielleicht schon bald Microsofts Visual Studio als Frontend zum Erstellen von Java-Anwendungen nutzen zu können. Auf alle Fälle wird es durch die Zusammenarbeit leichter werden, die Lücken zu schließen, die bislang das Umsetzen generativer Ansätze wie der Model Driven Architecture behindern.