V iele Unternehmen stehen vor derSituation, dass sie im Laufe der

Jahre eine Familie vergleichbarer Ge-räte oder Applikationen erstellen, diezugehörigen Softwareprojekte jedochimmer wieder „bei null“ anfangen. Esist nur zu verständlich, dass diese Be-obachtung bereits nach wenigen Wie-derholungen des kostspieligen Proze -dere dazu führt, dass der Ruf nach einerSoftwareplattform laut wird. Ernst ge-meinte Plattformen allerdings setzen ei-nen gewissen Mehraufwand an Vorar-beit voraus, der in der Praxis häufiggescheut wird – der Plattformgedankeverkommt zum Lippenbekenntnis.

Die Besonderheiten von Plattform-projekten zeigen sich in erster Linie inAspekten der Architektur. Um den Un-terschied zu klassischen Projekten oh-ne Plattformgedanken im Folgenden

besser beleuchten zu können, bedarf eszunächst einiger grundlegender Überle-gungen zum Architekturbegriff.

Ein kurzes Vorwort zur ArchitekturAllgemein gesprochen besteht dieKernaufgabe der IT-Architektur in die-sem Umfeld darin, eine Software für dieLösung der gesetzten Aufgaben derartzu strukturieren, dass das entstehendeGesamtsystem intellektuell und organi-satorisch beherrschbar bleibt. Zwei derwichtigsten Mittel zum Erreichen dieserZielsetzung sind Dekomposition, alsodie Zerlegung eines Systems in Kompo-nenten mit klar definierten Aufgaben,und Abstraktion, also das Verbergen in-terner Details einer Komponente (oder

Hardware) vor den auf sie zurückgrei-fenden Komponenten.

Besonders deutlich äußert sich dasDuo aus Dekomposition und Abs trak -tion in Schichtenarchitekturen: DieSchichten bilden eine vertikale Hierar-chie mit einem von unten nach oben zu-nehmenden Grad an Verallgemeine-rung, und die Komponenten einer jedenSchicht sind das Resultat einer hori -zontalen Trennung von Aufgaben aufgleicher Abstraktionsebene. Häufig fin-det sich im Design der einzelnen Kom -ponenten eine ähnliche Struktur: EineKomponente besteht dann intern wiederaus einer Hierarchie kleinerer Baustei-ne, etwa Java-Klassen oder C-Modulen,mit klar definierten Zuständigkeiten.Zusätzlich ist es üblich, die öffentlicheSchnittstelle einer Komponente von ih-rer konkreten Implementierung zu tren-nen – ein weiterer Abstraktionsschrittmit vielen Vorteilen.

Eine typische Dreischichtenarchitek-tur für eine Enterprise-Applikationkönnte beispielsweise wie folgt struk-turiert sein: Der unterste Layer kapseltDetails der Datenhaltung, etwa Daten-banken und -verbindungen. Sie hat so-mit eine technische Ausrichtung, aber

100 iX 6/2011

REPORT Softwareentwicklung

Von Plattformen und Plattitüden

LippenbekenntnisDaniel Mölle

Softwareplattformen sollen nicht nur Entwicklungszeiten verkürzen und Fehler reduzieren, sondern auch die kreativeEnergie der Mitarbeiter in produktive Bahnen lenken, statt sie in immer wiederkehrenden Aufgaben zu erschöpfen. Im alltäglichen Projektgeschäft stehen allerdings diverse Faktoren dem Plattformgedanken entgegen.

ix.0611.100-103 16.05.2011 10:07 Uhr Seite 100

© Copyright by Heise Zeitschriften Verlag

wenig fachlichen Bezug. Die mittlereSchicht hingegen fasst die (per Defini-tion fachliche) Geschäftslogik zusam-men. Hier wird das Vokabular der fach-lichen Domäne reflektiert, etwa Kunden,Produkte, Aufträge, Lagerbestände etcetera. Die oberste Ebene konzentriertsich auf Aspekte der Präsentation, etwaeine grafische Benutzeroberfläche zurEingabe und Verwaltung jener fachli-chen Entitäten.

In erster Linie zeigen sich die Besonderheiten von Plattformprojekten

in Aspekten der Architektur

Im Vergleich dazu könnte der Aufbaueiner typischen Dreischichtenarchitek-tur für die Firmware eines eingebette-ten Systems so aussehen: Die untersteSchicht stellt ein Hardware Abstrac -tion Layer dar, besteht also aus Trei-bern für die eingesetzte Peripherie, de-ren Schnittstellen nach oben von denDetails der eingesetzten Hardware abs trahieren. Wie im vorherigen Bei-spiel liegt der Fokus dieser unterstenEbene demzufolge auf technischen De-tails. Die mittlere Schicht hingegen be-herbergt Komponenten, die sich aufabstrakte Aufgaben konzentrieren –beispielsweise auf die Erfassung vonMesswerten, die Kommunikation mitanderen Geräten oder die Speicherungfachlicher Daten. In der obersten derdrei Schichten werden die eigentlichenHigh-Level-Abläufe abgebildet, die derErfüllung der angedachten Aufgabendienen.

Eine verbreitete Strukturierungs-maßnahme bei solchen Architekturenbesteht in der zusätzlichen Einschrän-kung, dass Komponenten einer Schichtnur von Komponenten derselben oderder darunterliegenden Schicht abhängigsein dürfen. Diese Restriktion führt un-

ter anderem dazu, dass sich Kompo-nenten des untersten Layer relativleicht austauschen lassen, selbst wenndies leichte Anpassungen an ihrenSchnittstellen zur Folge hat: Die Ände-rung ist in ihren Auswirkungen einiger-maßen begrenzt. Bei Embedded-Pro-jekten kommt diese Eigenschaft vorallem dann zum Tragen, wenn manSoftware von einer Hardware auf eineandere portieren will. Im Idealfall ge-nügt es, die Implementierung des Hard-ware Abstraction Layer auszutauschen,während man alle darüberliegendenKomponenten beibehalten kann. Einweiterer gravierender Vorteil strengerSchichtenarchitekturen besteht darin,dass Komponenten aus den oberenSchichten ersetzt werden können, ohnedass dadurch irgendwelche Anpassun-gen an Komponenten der darunterlie-genden Ebenen notwendig würden. Da-rüber hinaus äußert sich die saubereTrennung in einer drastisch verbesser-ten Testbarkeit.

Qualität erfordert auch WeitsichtIn der Tat ist die durch Dekompositionund Abstraktion erreichbare Qualität ei-nes Softwaresystems so offensichtlicherstrebenswert, dass es beinahe unmög-lich ist, sich jemanden vorzustellen, dersie für sein Projekt nicht in Anspruchnehmen möchte. Aber wenn sich dieseQualität so einfach herstellen ließe, wiees der erste Abschnitt dieses Artikelsoberflächlich suggeriert, dann stelltsich zwingend die folgende Frage:Wieso wird so häufig Software entwi-ckelt, die sich eben gerade nicht alsPlattform verwenden lässt, sondernnach einigen Jahren wieder von einervollständigen Neuentwicklung abgelöstwerden muss?

Ein kurzer Blick auf die berühmtenAusprägungen von Softwarequalitätsoll helfen, dieser Frage auf den Grund

zu gehen. Zentrale Aspekte der mitt-lerweile veralteten ISO/IECˇ9126 sindFunktionalität, Zuverlässigkeit, Benutz-barkeit, Effizienz, Änderbarkeit undÜbertragbarkeit. Dabei besteht ein fun-damentaler Unterschied zwischen denersten vier und den letzten beiden die-ser Ausprägungen.

Funktionalität, Zuverlässigkeit, Be-nutzbarkeit und Effizienz sind ver-gleichsweise gut sichtbare Eigenschaf-ten einer Software. Solange ein Gerätoder eine Applikation an den Anforde-rungen vorbeiläuft, den Dienst verwei-gert, unbedienbar oder schlichtweg zulangsam ist, wird die Abnahme ausge-setzt und die Entwicklungsarbeit ver-längert (oder das Projekt abgebrochen).Zusätzlich gilt die Besonderheit, dasseine augenscheinlich funktionierende,zuverlässige, benutzbare und effizienteSoftware beinahe keinerlei Rückschlüs-se auf die Qualität oder gar Ästhetik ih-rer zugrunde liegenden Architektur ge-stattet.

Änderbarkeit und Übertragbarkeithingegen sind subtile architekturelleEigenschaften. Sie zeigen sich an derOberfläche frühestens dann, wenn eine(weitgehend) fertige Software zum ers-ten Mal einer größeren Änderung oderPortierung unterzogen wird – alsomeist erst Jahre nach Beginn des Pro-jekts. Das Erzielen von Qualität in die-sem Sinne erfordert somit nicht nur we-sentlich mehr Umsicht und Erfahrung,sondern auch eine gewisse Weitsicht al-ler Beteiligten.

Bei Plattformprojekten bietet es sich an, die Unterschiede zwischen

den einzelnen Ausprägungen der Software in DSLs zu beschreiben

Diese Diskrepanz zwischen kurzfristigsichtbaren Erfolgen einerseits und ver-borgenen Qualitäten andererseits zeigtsich unter anderem in einem weitver-breiteten Phänomen, das sich po -larisierend – aber treffend – als „dieReuse-Lüge“ bezeichnen lässt: Weil dieWiederverwendbarkeit von Softwarezwar gemeinhin als Qualitätsmerkmalanerkannt, jedoch mitnichten trivial zumessen ist, wird sie wesentlich öfterdeklariert als tatsächlich erreicht. Sobeginnen auch zahlreiche Architektur-Reviews mit einer positiven Antwortder Entwickler auf die Frage „Ist ihrCode modular?“, enden aber bereits

iX 6/2011 101

x-TRACT● Obwohl viele Firmen im Lauf der Jahre Softwareprojekte haben, die sich in weiten

Teilen stark ähneln, entwickeln sie häufig alle Komponenten von Grund auf neu.

● Eine naheliegende Lösung sind Softwareplattformen, die als Basis für die Wieder -verwendung vieler Komponenten dienen können.

● Erfolgreich sind Plattform-Projekte aber nur dann, wenn alle Beteiligten dieses Zielkonsequent verfolgen und es nicht zugunsten kurzfristig sichtbarer Erfolge aus denAugen verlieren.

ix.0611.100-103 16.05.2011 10:07 Uhr Seite 101

© Copyright by Heise Zeitschriften Verlag

nach dem Durchspielen eines erstenPortierungsszenarios mit der gegentei-ligen Erkenntnis.

Struktur braucht Struktur –und ErfahrungDer Grund dafür, dass Änderbarkeitund Übertragbarkeit oft verfehlt wer-den, liegt nicht etwa in einer mangeln-den Bereitschaft, das oben beleuchteteDuo aus Dekomposition und Abstrak -tion einzusetzen. Ausschlaggebend istvielmehr der Umstand, dass es keines-wegs leicht ist, eine saubere Strukturie-rung im Sinne dieser beiden Konzeptefestzulegen und durchzuhalten.

Jede Strukturierung ist zunächstdurch Einschränkungen charakterisiert:A darf nichts von B wissen, C soll kei-ne Annahmen über die Farbtiefe desDisplays machen, D muss denselbenSchnittstellenvertrag wie E einhaltenund so weiter. Theoretisch gesehenmacht eine Architektur aus einer allge-meinen Random Access Machine (odereiner Turing-Maschine), bei der jederTeil der Software alles darf und kennt,ein mehr oder weniger projektspezifi-sches, beschränktes und vor allem bes-ser beherrschbares Berechnungsmo-dell. Aus praktischer Sicht sind dieseMaßnahmen zwingend erforderlich,um die Abhängigkeiten und die Kom-plexität im System in den Griff zu be-

kommen. Allerdings zeigen sich aufdem Weg zur Strukturierung oft dreiSchwierigkeiten.

Erstens lässt sich die Struktur einerSoftware nur dann in sinnvollem Maßefestlegen, wenn dies auch bei ihrenRandbedingungen erfolgt. Das ist keinPlädoyer für einen Wasserfallprozess,sondern im Gegenteil der zwingendeGrund für ein iteratives Vorgehen inProjekten, bei denen diese Randbedin-gungen nur über einen längeren Zeit-raum und mit vielen Interessenvertreterngeklärt werden können – mit anderenWorten, in allen Projekten.

Zwischen kurzfristig sichtbaren Erfolgen einerseits und verborgenen

Qualitäten andererseits besteht eine Diskrepanz

Die Randbedingungen betreffen vorallem Anforderungen, aber auch tech-nische Fragen, etwa bezüglich derHardware. So lassen sich bei einemEnterprise-Projekt keine sinnvollenEntscheidungen bezüglich konzeptio-neller Datenbankschemata fällen, so-lange man nicht weiß, welche fachli-chen Entitäten man überhaupt erfassenmuss. Bei einem Embedded-Projekthingegen ist es beispielsweise kaum

möglich, eine sinnvolle Schnittstelle füreine Kommunikationskomponente zudefinieren, wenn zwei alternative Ver-bindungskonzepte mit gänzlich kon -trären Eigenschaften in der Diskussionsind. Um den Umgang mit derartigenUnsicherheiten geht es weiter unten.

Zweitens verlangen Dekompositionund Abstraktion in komplizierteren Fäl-len besondere Umsicht. Ein Paradebei-spiel hierfür sind grafische Benutzer-oberflächen: Bei der Darstellung oderEingabe fachlicher Daten müssen Busi-ness-Logik und Präsentationsschicht ei-ner Enterprise-Applikation per Anforde-rung eng zusammenarbeiten, währendman andererseits eine lose Kopplungzwischen diesen beiden Softwareteilenanstrebt. Die Lösung dieses Wider-spruchs ist zwar möglich – etwa durchdie Trennung zwischen Inhalt (Model-len) und Form (Ansichten) sowie dengleichzeitigen Einsatz generischer statthartverdrahteter Dialoge –, erfordertaber ein Maß an Ausdauer und Diszip-lin, das längst nicht jeder erbringt.

Vom Einzelfall zur PlattformDrittens schlägt in diesem Zusammen-hang wieder eine oben erörterte Tat -sache zu Buche: In Phasen hohen Zeit-oder Erfolgsdrucks gerät die Strukturie-rung in Gefahr, wenn ihre Verletzung

102 iX 6/2011

REPORT Softwareentwicklung

Zur Rolle von DSLs in PlattformprojektenBesonderer Beliebtheit erfreuen sich in denletzten Jahren Domain-Specific Languages– zu Recht. Gerade im Zusammenhang mitPlattformprojekten lässt sich festhalten,dass DSLs bei richtiger Anwendung enor-me Vorteile bieten.

Die Kunst beim Entwurf einer DSL für einProjekt besteht darin, genau die Aspekte inder Sprache abzubilden, bei denen diesesVorgehen der händischen Formulierung inregulärem Code (beispielsweise in C) oderin Metadateien zum Build-Prozess (etwaMakefiles) spürbar überlegen ist. Dabeisollte der Begriff „domain“ nicht darüberhinwegtäuschen, dass dies nicht nur fürfachliche, sondern auch für technische As-pekte gilt. DSLs sind also nicht nur dafürgeeignet, fachliche Artefakte wie Business-Prozesse auf einem höheren Abstraktions-niveau zu beschreiben; dasselbe können siefür technische Artefakte leisten.

Aus vielerlei Gründen kann die Beschrei-bung technischer Entitäten in einer DSLsinnvoll sein. Ein Paradebeispiel ist die

Vermeidung von handgeschriebenem „Boi-lerplate Code“, also die Vermeidung vielerCodepassagen mit großer Ähnlichkeit.Hierzu müssen die Informationen, die diegeringen Unterschiede zwischen diesenPassagen ausmachen, auf einem höherenAbstraktionsniveau formuliert und die ent-sprechenden Codefragmente daraus gene-riert werden. Ein händisches Ausprogram-mieren der repetitiven Passagen hingegenwäre nicht nur eine Verschwendung kreati-ver Entwicklerenergie, sondern auch einenotorische Fehlerquelle.

In fachlicher Hinsicht nutzt man DSLs un-ter anderem dazu, für den Kunden relevanteKonstellationen und Abläufe derart zu for-mulieren (und in Code zu überführen), dassman Domänenexperten auch ohne Kenntnisder Programmiersprache oder sonstigertechnischer Details einbeziehen kann.

Bei Plattformprojekten bietet es sich an,die Unterschiede zwischen den einzelnenAusprägungen der Software in DSLs zubeschreiben. Dieses Vorgehen gestattet es,

die Unterschiede ausdrücklich zu formulie-ren, statt sie implizit im Code zu verbergen(etwa durch #ifdef-Konstrukte, die bei um-fangreichem Einsatz schwer wartbar sind).Auf fachlicher Ebene könnten die Ent-wickler beispielsweise die Features proAusprägung definieren – der Code und zu-gehörige Metadaten würde aus diesen De-finitionen generiert. Auf technischer Ebe-ne wiederum könnten sie Details zu denbeteiligten Software- oder Hardwaremodu-len formulieren, mit deren Hilfe der Build-Prozess oder auch die Konfiguration vonTreibern gesteuert werden.

Hier zeigt sich, dass DSLs in Plattformpro-jekten zum Teil denselben Voraussetzungenunterliegen wie die eigentliche Software:Der sinnvolle Einsatz domänenspezifischerSprachen setzt voraus, dass den am ProjektBeteiligten klar ist, inwiefern sich die di-versen Ausprägungen – anders gesagt: dieInstanzen – der Plattform voneinander un-terscheiden werden. Gefragt ist somit ein-mal mehr ein genaues Verständnis der Va-riabilität.

ix.0611.100-103 16.05.2011 10:07 Uhr Seite 102

© Copyright by Heise Zeitschriften Verlag

kurzfristige und besser sichtbare Fort-schritte ermöglicht. Das Nichteinhaltender Architektur zeigt sich häufig erstwesentlich später – etwa, wie oben an-gedeutet, bei einem Review zur Wie-derverwendbarkeit.

Die zentrale Herausforderung beiPlattformprojekten liegt in einer Po-tenzierung der aufgeführten Problem-quellen, allen voran der erstgenann-ten: Randbedingungen. Weil es schonschwierig ist, eine Software angesichtsin Bewegung befindlicher Anforderun-gen und Technologieentscheidungenzu strukturieren, gilt dies erst recht füreine Plattform, die den Anforderungenund Eigenschaften verschiedener odergar zukünftiger Produkte gerecht wer-den soll.

Jede Strukturierung ist zunächst durch Einschränkungen

charakterisiert

Eine übliche, aber problematische Ant-wort auf diese Herausforderung be-steht darin, die von Unsicherheiten be-troffenen Schnittstellen derart zuverallgemeinern, dass sie jede Even-tualität gestatten. In der Praxis findensich beispielsweise Datenbankschema-ta, die neben einigen konkreten Ele-menten ein spezielles Feld für die Ein-bettung beliebig großer binärer Blobsoder XML-Strings mit weiteren Infor-mationen vorsehen. Diese Vermengungvon Daten zweier grundsätzlich ver-schiedener Abstraktionsniveaus schlägtsich meistens in schlechtem Code nie-der. Der Code reflektiert diese Ver-mengung, weil er sowohl mit den kon-kreten fachlichen Elementen als auchden technischen Spezifika der generi-schen Rohdaten umgehen könnenmuss. Ein vergleichbarer Fall liegt beiHardwaretreibern vor, deren Schnitt-stellen zu stark verallgemeinert wur-den – etwa in der Form, dass eine denTreiber nutzende Komponente zurLaufzeit zunächst Details der tatsäch-lichen Hardware-Auslegung über spe-zielle Funktionen erfragen und Codefür jede denkbare Antwort vorsehenmuss, bevor sie den Treiber in sinn -voller Weise einsetzen kann.

Das Überverallgemeinern einerSchnittstelle ist deshalb so kritisch,weil es ihre strukturierende Wirkungzunichte macht. Wenn die Schnittstelleeiner Komponente alles zulässt, muss

jeder, der sie verwendet, auf alles ge-fasst sein. Der Irrtum, dass eine derartüberzogene Verallgemeinerung einevalide Form von Abstraktion darstellenkönnte, wird dadurch entlarvt, dass sieundicht (also eine „leaking abstrac -tion“) ist. Zwar werden technische De-tails aus rein statischer Sicht vielleichtnoch verborgen, allerdings müssen siezur Laufzeit mühselig über die Schnitt-stellengrenzen nach oben publiziertwerden. Die übergeordneten Kompo-nenten erben somit die Verantwortung,mit den eigentlich zu verbergendenDetails umzugehen – dies ist das Ge-genteil von Abstraktion.

Ein zweiter, nur geringfügig ange-nehmerer Weg bei der Konstruktion vonPlattformarchitekturen verläuft über Er-fahrungswerte: An Stellen, an denengrößere Unsicherheiten herrschen, ver-sucht man, zumindest die wahrschein-lichsten Ausgänge zukünftiger Ent-scheidungen abzudecken. Auch diesesVorgehen ist aber wenig mehr als eineForm von Notwehr gegenüber der ver-zögerten Klärung von Anforderungenund anderen Randbedingungen.

Die ideale Reaktion auf die hierdiskutierte Herausforderung der unsi-cheren Randbedingungen ist ungleichanspruchsvoller. Sie besteht in einervon allen Interessenvertretern getrage-nen, ernsthaft durchgeführten Variabi-litätsanalyse, die zwei hehren Zielendient.

Varianten stets im Blick behaltenIn technischer Hinsicht hülfe eine sol-che Analyse dabei, ein klares Bild da-von zu ermitteln, welche Einschränkun-gen der Softwarearchitekt annehmendarf und welche möglichen Variantener berücksichtigen muss. Dies schafftdie Strukturen bezüglich Anforderun-gen und Technologien, die für dieKonzeption einer erfolgreichen Platt-formarchitektur notwendig sind (dieerforderliche technische Expertise vo-rausgesetzt). Natürlich kann die Ana-lyse einige Iterationen durchlaufen undmuss dies üblicherweise auch tun –wichtig ist dabei nur, dass man mög-lichst viele der zentralen Fragen undRisiken früh angeht, um dem Prozessder Architekturdefinition einen konkre-ten Weg zu ebnen.

In organisatorischer Hinsicht kommtder Analyse eine weitere wichtigeFunktion zu, nämlich die, die Projekt-beteiligten mit offenen Augen durch

den Prozess der Plattformdefinition zuführen. Gerade für Interessenvertretermit nichttechnischen Schwerpunktenist meist kaum ersichtlich, welche Än-derungswünsche welche Auswirkun-gen nach sich ziehen und welche Fra-gen zur Variabilität die Plattform amstärksten betreffen. Die zur Schaffungder Voraussetzungen für eine Platt-form wichtige Zusammenarbeit zwi-schen verschiedenen Abteilungen setzteine interdisziplinäre Arbeitskultur vo-raus, die sich nicht immer leicht etab-lieren lässt.

Die Vermengung von Daten zweier grundsätzlich verschiedener

Abstraktionsniveaus schlägt sich meistens in schlechtem Code nieder

Eine Variabilitätsanalyse ist insofern an-spruchsvoll, als sie relativ früh im Pro-jekt drei unbequeme Forderungen stellt:Erstens müssen sich alle Interessen-vertreter die Zeit nehmen, in der jewei-ligen Rolle an der Analyse mitzuwirken.Dies ist aufgrund parallel laufenden Ta-gesgeschäfts oft schwierig zu erreichen.Zweitens muss das Management dazubereit sein, den mit der Analyse ver -bundenen Aufwand hinzunehmen, auchwenn die positiven Folgen erst lang-fristig Sichtbarkeit erlangen. DieseZukunftsorientierung ist vor allem inKulturkreisen mit kurzfristigen Erfolgs-metriken schwer zu etablieren. Drittensist die allgemeine Bereitschaft zur Ent-scheidungsfindung Voraussetzung da-für, dass die Arbeiten eine konkreteRichtung einschlagen können. Dieserdritte Punkt setzt zudem voraus, dassnicht messbare oder unterspezifizierteAnforderungen entweder präzisiert oderaufgegeben werden.

Folglich erfordern ernst gemeintePlattformprojekte von allen Beteiligten– quer durch alle Disziplinen – ein Be-kenntnis zum Plattformgedanken. Dabeimuss klar sein, dass der Weg zur Platt-form keine gewöhnliche technische An-forderung darstellt, sondern budgetiertund von allen Interessenvertretern mitbeschritten werden muss. (ka)

DR. DANIEL MÖLLE ist bei der Zühlke Engineering GmbHals Softwarearchitekt mit den Schwer-punkten eingebettete Systeme und .Net tätig. x

iX 6/2011 103

ix.0611.100-103 16.05.2011 10:07 Uhr Seite 103

© Copyright by Heise Zeitschriften Verlag