REPORT                                                    SoftwareentwicklungVon Plattformen und PlattitüdenLippenbekenntn...
wenig fachlichen Bezug. Die mittlere               ter anderem dazu, dass sich Kompo-                  zu gehen. Zentrale ...
REPORT                                                        Softwareentwicklungnach dem Durchspielen eines ersten       ...
kurzfristige und besser sichtbare Fort-      jeder, der sie verwendet, auf alles ge-            den Prozess der Plattformd...
Upcoming SlideShare
Loading in...5
×

Ix62011 lippenbekenntnis moelle

298

Published on

Softwareplattformen sollen nicht nur Entwicklungszeiten verkürzen und Fehler reduzieren, sondern auch die kreative Energie der Mitarbeiter in produktive Bahnen lenken, statt sie in immer wiederkehrenden Aufgaben zu erschöpfen.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
298
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Ix62011 lippenbekenntnis moelle

  1. 1. REPORT SoftwareentwicklungVon Plattformen und PlattitüdenLippenbekenntnisDaniel MölleSoftwareplattformensollen nicht nur Entwicklungszeitenverkürzen und Fehler reduzieren, sondern auch die kreative Hardware) vor den auf sie zurückgrei- fenden Komponenten.Energie der Mitarbeiter in produktive Bahnen lenken, statt Besonders deutlich äußert sich dassie in immer wiederkehrenden Aufgaben zu erschöpfen. Duo aus Dekomposition und Abstrak- tion in Schichtenarchitekturen: DieIm alltäglichen Projektgeschäft stehen allerdings diverse Schichten bilden eine vertikale Hierar-Faktoren dem Plattformgedanken entgegen. chie mit einem von unten nach oben zu- nehmenden Grad an Verallgemeine- rung, und die Komponenten einer jedenV iele Unternehmen stehen vor der Situation, dass sie im Laufe derJahre eine Familie vergleichbarer Ge- besser beleuchten zu können, bedarf es zunächst einiger grundlegender Überle- gungen zum Architekturbegriff. Schicht sind das Resultat einer hori- zontalen Trennung von Aufgaben auf gleicher Abstraktionsebene. Häufig fin-räte oder Applikationen erstellen, die det sich im Design der einzelnen Kom-zugehörigen Softwareprojekte jedochimmer wieder „bei null“ anfangen. Es Ein kurzes Vorwort ponenten eine ähnliche Struktur: Eine Komponente besteht dann intern wiederist nur zu verständlich, dass diese Be- zur Architektur aus einer Hierarchie kleinerer Baustei-obachtung bereits nach wenigen Wie- ne, etwa Java-Klassen oder C-Modulen,derholungen des kostspieligen Proze- Allgemein gesprochen besteht die mit klar definierten Zuständigkeiten.dere dazu führt, dass der Ruf nach einer Kernaufgabe der IT-Architektur in die- Zusätzlich ist es üblich, die öffentlicheSoftwareplattform laut wird. Ernst ge- sem Umfeld darin, eine Software für die Schnittstelle einer Komponente von ih-meinte Plattformen allerdings setzen ei- Lösung der gesetzten Aufgaben derart rer konkreten Implementierung zu tren-nen gewissen Mehraufwand an Vorar- zu strukturieren, dass das entstehende nen – ein weiterer Abstraktionsschrittbeit voraus, der in der Praxis häufig Gesamtsystem intellektuell und organi- mit vielen Vorteilen.gescheut wird – der Plattformgedanke satorisch beherrschbar bleibt. Zwei der Eine typische Dreischichtenarchitek-verkommt zum Lippenbekenntnis. wichtigsten Mittel zum Erreichen dieser tur für eine Enterprise-Applikation Die Besonderheiten von Plattform- Zielsetzung sind Dekomposition, also könnte beispielsweise wie folgt struk-projekten zeigen sich in erster Linie in die Zerlegung eines Systems in Kompo- turiert sein: Der unterste Layer kapseltAspekten der Architektur. Um den Un- nenten mit klar definierten Aufgaben, Details der Datenhaltung, etwa Daten-terschied zu klassischen Projekten oh- und Abstraktion, also das Verbergen in- banken und -verbindungen. Sie hat so-ne Plattformgedanken im Folgenden terner Details einer Komponente (oder mit eine technische Ausrichtung, aber100 iX 6/2011 © Copyright by Heise Zeitschriften Verlag
  2. 2. wenig fachlichen Bezug. Die mittlere ter anderem dazu, dass sich Kompo- zu gehen. Zentrale Aspekte der mitt-Schicht hingegen fasst die (per Defini- nenten des untersten Layer relativ lerweile veralteten ISO/IECˇ9126 sindtion fachliche) Geschäftslogik zusam- leicht austauschen lassen, selbst wenn Funktionalität, Zuverlässigkeit, Benutz-men. Hier wird das Vokabular der fach- dies leichte Anpassungen an ihren barkeit, Effizienz, Änderbarkeit undlichen Domäne reflektiert, etwa Kunden, Schnittstellen zur Folge hat: Die Ände- Übertragbarkeit. Dabei besteht ein fun-Produkte, Aufträge, Lagerbestände et rung ist in ihren Auswirkungen einiger- damentaler Unterschied zwischen dencetera. Die oberste Ebene konzentriert maßen begrenzt. Bei Embedded-Pro- ersten vier und den letzten beiden die-sich auf Aspekte der Präsentation, etwa jekten kommt diese Eigenschaft vor ser Ausprägungen.eine grafische Benutzeroberfläche zur allem dann zum Tragen, wenn man Funktionalität, Zuverlässigkeit, Be-Eingabe und Verwaltung jener fachli- Software von einer Hardware auf eine nutzbarkeit und Effizienz sind ver-chen Entitäten. andere portieren will. Im Idealfall ge- gleichsweise gut sichtbare Eigenschaf- nügt es, die Implementierung des Hard- ten einer Software. Solange ein Gerät ware Abstraction Layer auszutauschen, oder eine Applikation an den Anforde- In erster Linie zeigen sich die während man alle darüberliegenden rungen vorbeiläuft, den Dienst verwei-Besonderheiten von Plattformprojekten Komponenten beibehalten kann. Ein gert, unbedienbar oder schlichtweg zu weiterer gravierender Vorteil strenger langsam ist, wird die Abnahme ausge- in Aspekten der Architektur Schichtenarchitekturen besteht darin, setzt und die Entwicklungsarbeit ver- dass Komponenten aus den oberen längert (oder das Projekt abgebrochen). Schichten ersetzt werden können, ohne Zusätzlich gilt die Besonderheit, dass dass dadurch irgendwelche Anpassun- eine augenscheinlich funktionierende,Im Vergleich dazu könnte der Aufbau gen an Komponenten der darunterlie- zuverlässige, benutzbare und effizienteeiner typischen Dreischichtenarchitek- genden Ebenen notwendig würden. Da- Software beinahe keinerlei Rückschlüs-tur für die Firmware eines eingebette- rüber hinaus äußert sich die saubere se auf die Qualität oder gar Ästhetik ih-ten Systems so aussehen: Die unterste Trennung in einer drastisch verbesser- rer zugrunde liegenden Architektur ge-Schicht stellt ein Hardware Abstrac- ten Testbarkeit. stattet.tion Layer dar, besteht also aus Trei- Änderbarkeit und Übertragbarkeitbern für die eingesetzte Peripherie, de-ren Schnittstellen nach oben von den Qualität erfordert hingegen sind subtile architekturelle Eigenschaften. Sie zeigen sich an derDetails der eingesetzten Hardwareabstrahieren. Wie im vorherigen Bei- auch Weitsicht Oberfläche frühestens dann, wenn eine (weitgehend) fertige Software zum ers-spiel liegt der Fokus dieser untersten In der Tat ist die durch Dekomposition ten Mal einer größeren Änderung oderEbene demzufolge auf technischen De- und Abstraktion erreichbare Qualität ei- Portierung unterzogen wird – alsotails. Die mittlere Schicht hingegen be- nes Softwaresystems so offensichtlich meist erst Jahre nach Beginn des Pro-herbergt Komponenten, die sich auf erstrebenswert, dass es beinahe unmög- jekts. Das Erzielen von Qualität in die-abstrakte Aufgaben konzentrieren – lich ist, sich jemanden vorzustellen, der sem Sinne erfordert somit nicht nur we-beispielsweise auf die Erfassung von sie für sein Projekt nicht in Anspruch sentlich mehr Umsicht und Erfahrung,Messwerten, die Kommunikation mit nehmen möchte. Aber wenn sich diese sondern auch eine gewisse Weitsicht al-anderen Geräten oder die Speicherung Qualität so einfach herstellen ließe, wie ler Beteiligten.fachlicher Daten. In der obersten der es der erste Abschnitt dieses Artikelsdrei Schichten werden die eigentlichen oberflächlich suggeriert, dann stelltHigh-Level-Abläufe abgebildet, die der sich zwingend die folgende Frage: Bei Plattformprojekten bietetErfüllung der angedachten Aufgaben Wieso wird so häufig Software entwi- es sich an, die Unterschiede zwischendienen. ckelt, die sich eben gerade nicht als Eine verbreitete Strukturierungs- Plattform verwenden lässt, sondern den einzelnen Ausprägungen dermaßnahme bei solchen Architekturen nach einigen Jahren wieder von einer Software in DSLs zu beschreibenbesteht in der zusätzlichen Einschrän- vollständigen Neuentwicklung abgelöstkung, dass Komponenten einer Schicht werden muss?nur von Komponenten derselben oder Ein kurzer Blick auf die berühmtender darunterliegenden Schicht abhängig Ausprägungen von Softwarequalität Diese Diskrepanz zwischen kurzfristigsein dürfen. Diese Restriktion führt un- soll helfen, dieser Frage auf den Grund sichtbaren Erfolgen einerseits und ver- borgenen Qualitäten andererseits zeigt sich unter anderem in einem weitver- breiteten Phänomen, das sich po- x-TRACT larisierend – aber treffend – als „die ● Obwohl viele Firmen im Lauf der Jahre Softwareprojekte haben, die sich in weiten Reuse-Lüge“ bezeichnen lässt: Weil die Teilen stark ähneln, entwickeln sie häufig alle Komponenten von Grund auf neu. Wiederverwendbarkeit von Software zwar gemeinhin als Qualitätsmerkmal ● Eine naheliegende Lösung sind Softwareplattformen, die als Basis für die Wieder- anerkannt, jedoch mitnichten trivial zu verwendung vieler Komponenten dienen können. messen ist, wird sie wesentlich öfter ● Erfolgreich sind Plattform-Projekte aber nur dann, wenn alle Beteiligten dieses Ziel deklariert als tatsächlich erreicht. So konsequent verfolgen und es nicht zugunsten kurzfristig sichtbarer Erfolge aus den beginnen auch zahlreiche Architektur- Augen verlieren. Reviews mit einer positiven Antwort der Entwickler auf die Frage „Ist ihr Code modular?“, enden aber bereitsiX 6/2011 101 © Copyright by Heise Zeitschriften Verlag
  3. 3. REPORT Softwareentwicklungnach dem Durchspielen eines ersten kommen. Allerdings zeigen sich auf möglich, eine sinnvolle Schnittstelle fürPortierungsszenarios mit der gegentei- dem Weg zur Strukturierung oft drei eine Kommunikationskomponente zuligen Erkenntnis. Schwierigkeiten. definieren, wenn zwei alternative Ver- Erstens lässt sich die Struktur einer bindungskonzepte mit gänzlich kon-Struktur braucht Struktur – Software nur dann in sinnvollem Maße festlegen, wenn dies auch bei ihren trären Eigenschaften in der Diskussion sind. Um den Umgang mit derartigenund Erfahrung Randbedingungen erfolgt. Das ist kein Unsicherheiten geht es weiter unten. Plädoyer für einen Wasserfallprozess, Zweitens verlangen DekompositionDer Grund dafür, dass Änderbarkeit sondern im Gegenteil der zwingende und Abstraktion in komplizierteren Fäl-und Übertragbarkeit oft verfehlt wer- Grund für ein iteratives Vorgehen in len besondere Umsicht. Ein Paradebei-den, liegt nicht etwa in einer mangeln- Projekten, bei denen diese Randbedin- spiel hierfür sind grafische Benutzer-den Bereitschaft, das oben beleuchtete gungen nur über einen längeren Zeit- oberflächen: Bei der Darstellung oderDuo aus Dekomposition und Abstrak- raum und mit vielen Interessenvertretern Eingabe fachlicher Daten müssen Busi-tion einzusetzen. Ausschlaggebend ist geklärt werden können – mit anderen ness-Logik und Präsentationsschicht ei-vielmehr der Umstand, dass es keines- Worten, in allen Projekten. ner Enterprise-Applikation per Anforde-wegs leicht ist, eine saubere Strukturie- rung eng zusammenarbeiten, währendrung im Sinne dieser beiden Konzepte man andererseits eine lose Kopplungfestzulegen und durchzuhalten. Zwischen kurzfristig sichtbaren zwischen diesen beiden Softwareteilen Jede Strukturierung ist zunächst Erfolgen einerseits und verborgenen anstrebt. Die Lösung dieses Wider-durch Einschränkungen charakterisiert: spruchs ist zwar möglich – etwa durchA darf nichts von B wissen, C soll kei- Qualitäten andererseits besteht die Trennung zwischen Inhalt (Model-ne Annahmen über die Farbtiefe des eine Diskrepanz len) und Form (Ansichten) sowie denDisplays machen, D muss denselben gleichzeitigen Einsatz generischer stattSchnittstellenvertrag wie E einhalten hartverdrahteter Dialoge –, erfordertund so weiter. Theoretisch gesehen aber ein Maß an Ausdauer und Diszip-macht eine Architektur aus einer allge- Die Randbedingungen betreffen vor lin, das längst nicht jeder erbringt.meinen Random Access Machine (oder allem Anforderungen, aber auch tech-einer Turing-Maschine), bei der jederTeil der Software alles darf und kennt, nische Fragen, etwa bezüglich der Hardware. So lassen sich bei einem Vom Einzelfall zurein mehr oder weniger projektspezifi- Enterprise-Projekt keine sinnvollen Plattformsches, beschränktes und vor allem bes- Entscheidungen bezüglich konzeptio-ser beherrschbares Berechnungsmo- neller Datenbankschemata fällen, so- Drittens schlägt in diesem Zusammen-dell. Aus praktischer Sicht sind diese lange man nicht weiß, welche fachli- hang wieder eine oben erörterte Tat-Maßnahmen zwingend erforderlich, chen Entitäten man überhaupt erfassen sache zu Buche: In Phasen hohen Zeit-um die Abhängigkeiten und die Kom- muss. Bei einem Embedded-Projekt oder Erfolgsdrucks gerät die Strukturie-plexität im System in den Griff zu be- hingegen ist es beispielsweise kaum rung in Gefahr, wenn ihre Verletzung Zur Rolle von DSLs in Plattformprojekten Besonderer Beliebtheit erfreuen sich in den Vermeidung von handgeschriebenem „Boi- die Unterschiede ausdrücklich zu formulie- letzten Jahren Domain-Specific Languages lerplate Code“, also die Vermeidung vieler ren, statt sie implizit im Code zu verbergen – zu Recht. Gerade im Zusammenhang mit Codepassagen mit großer Ähnlichkeit. (etwa durch #ifdef-Konstrukte, die bei um- Plattformprojekten lässt sich festhalten, Hierzu müssen die Informationen, die die fangreichem Einsatz schwer wartbar sind). dass DSLs bei richtiger Anwendung enor- geringen Unterschiede zwischen diesen Auf fachlicher Ebene könnten die Ent- me Vorteile bieten. Passagen ausmachen, auf einem höheren wickler beispielsweise die Features pro Abstraktionsniveau formuliert und die ent- Ausprägung definieren – der Code und zu- Die Kunst beim Entwurf einer DSL für ein gehörige Metadaten würde aus diesen De- sprechenden Codefragmente daraus gene- Projekt besteht darin, genau die Aspekte in finitionen generiert. Auf technischer Ebe- riert werden. Ein händisches Ausprogram- der Sprache abzubilden, bei denen dieses ne wiederum könnten sie Details zu den mieren der repetitiven Passagen hingegen Vorgehen der händischen Formulierung in beteiligten Software- oder Hardwaremodu- wäre nicht nur eine Verschwendung kreati- regulärem Code (beispielsweise in C) oder len formulieren, mit deren Hilfe der Build- ver Entwicklerenergie, sondern auch eine in Metadateien zum Build-Prozess (etwa Prozess oder auch die Konfiguration von notorische Fehlerquelle. Makefiles) spürbar überlegen ist. Dabei Treibern gesteuert werden. sollte der Begriff „domain“ nicht darüber In fachlicher Hinsicht nutzt man DSLs un- hinwegtäuschen, dass dies nicht nur für ter anderem dazu, für den Kunden relevante Hier zeigt sich, dass DSLs in Plattformpro- fachliche, sondern auch für technische As- Konstellationen und Abläufe derart zu for- jekten zum Teil denselben Voraussetzungen pekte gilt. DSLs sind also nicht nur dafür mulieren (und in Code zu überführen), dass unterliegen wie die eigentliche Software: geeignet, fachliche Artefakte wie Business- man Domänenexperten auch ohne Kenntnis Der sinnvolle Einsatz domänenspezifischer Prozesse auf einem höheren Abstraktions- der Programmiersprache oder sonstiger Sprachen setzt voraus, dass den am Projekt niveau zu beschreiben; dasselbe können sie technischer Details einbeziehen kann. Beteiligten klar ist, inwiefern sich die di- für technische Artefakte leisten. versen Ausprägungen – anders gesagt: die Bei Plattformprojekten bietet es sich an, Instanzen – der Plattform voneinander un- Aus vielerlei Gründen kann die Beschrei- die Unterschiede zwischen den einzelnen terscheiden werden. Gefragt ist somit ein- bung technischer Entitäten in einer DSL Ausprägungen der Software in DSLs zu mal mehr ein genaues Verständnis der Va- sinnvoll sein. Ein Paradebeispiel ist die beschreiben. Dieses Vorgehen gestattet es, riabilität.102 iX 6/2011 © Copyright by Heise Zeitschriften Verlag
  4. 4. kurzfristige und besser sichtbare Fort- jeder, der sie verwendet, auf alles ge- den Prozess der Plattformdefinition zuschritte ermöglicht. Das Nichteinhalten fasst sein. Der Irrtum, dass eine derart führen. Gerade für Interessenvertreterder Architektur zeigt sich häufig erst überzogene Verallgemeinerung eine mit nichttechnischen Schwerpunktenwesentlich später – etwa, wie oben an- valide Form von Abstraktion darstellen ist meist kaum ersichtlich, welche Än-gedeutet, bei einem Review zur Wie- könnte, wird dadurch entlarvt, dass sie derungswünsche welche Auswirkun-derverwendbarkeit. undicht (also eine „leaking abstrac- gen nach sich ziehen und welche Fra- Die zentrale Herausforderung bei tion“) ist. Zwar werden technische De- gen zur Variabilität die Plattform amPlattformprojekten liegt in einer Po- tails aus rein statischer Sicht vielleicht stärksten betreffen. Die zur Schaffungtenzierung der aufgeführten Problem- noch verborgen, allerdings müssen sie der Voraussetzungen für eine Platt-quellen, allen voran der erstgenann- zur Laufzeit mühselig über die Schnitt- form wichtige Zusammenarbeit zwi-ten: Randbedingungen. Weil es schon stellengrenzen nach oben publiziert schen verschiedenen Abteilungen setztschwierig ist, eine Software angesichts werden. Die übergeordneten Kompo- eine interdisziplinäre Arbeitskultur vo-in Bewegung befindlicher Anforderun- nenten erben somit die Verantwortung, raus, die sich nicht immer leicht etab-gen und Technologieentscheidungen mit den eigentlich zu verbergenden lieren lässt.zu strukturieren, gilt dies erst recht für Details umzugehen – dies ist das Ge-eine Plattform, die den Anforderungen genteil von Abstraktion.und Eigenschaften verschiedener oder Ein zweiter, nur geringfügig ange- Die Vermengung von Datengar zukünftiger Produkte gerecht wer- nehmerer Weg bei der Konstruktion von zweier grundsätzlich verschiedenerden soll. Plattformarchitekturen verläuft über Er- fahrungswerte: An Stellen, an denen Abstraktionsniveaus schlägt sich Jede Strukturierung ist größere Unsicherheiten herrschen, ver- meistens in schlechtem Code nieder sucht man, zumindest die wahrschein- zunächst durch Einschränkungen lichsten Ausgänge zukünftiger Ent- scheidungen abzudecken. Auch dieses charakterisiert Vorgehen ist aber wenig mehr als eine Eine Variabilitätsanalyse ist insofern an- Form von Notwehr gegenüber der ver- spruchsvoll, als sie relativ früh im Pro- zögerten Klärung von Anforderungen jekt drei unbequeme Forderungen stellt: und anderen Randbedingungen. Erstens müssen sich alle Interessen-Eine übliche, aber problematische Ant- Die ideale Reaktion auf die hier vertreter die Zeit nehmen, in der jewei-wort auf diese Herausforderung be- diskutierte Herausforderung der unsi- ligen Rolle an der Analyse mitzuwirken.steht darin, die von Unsicherheiten be- cheren Randbedingungen ist ungleich Dies ist aufgrund parallel laufenden Ta-troffenen Schnittstellen derart zu anspruchsvoller. Sie besteht in einer gesgeschäfts oft schwierig zu erreichen.verallgemeinern, dass sie jede Even- von allen Interessenvertretern getrage- Zweitens muss das Management dazutualität gestatten. In der Praxis finden nen, ernsthaft durchgeführten Variabi- bereit sein, den mit der Analyse ver-sich beispielsweise Datenbankschema- litätsanalyse, die zwei hehren Zielen bundenen Aufwand hinzunehmen, auchta, die neben einigen konkreten Ele- dient. wenn die positiven Folgen erst lang-menten ein spezielles Feld für die Ein- fristig Sichtbarkeit erlangen. Diesebettung beliebig großer binärer Blobsoder XML-Strings mit weiteren Infor- Varianten stets Zukunftsorientierung ist vor allem in Kulturkreisen mit kurzfristigen Erfolgs-mationen vorsehen. Diese Vermengung im Blick behalten metriken schwer zu etablieren. Drittensvon Daten zweier grundsätzlich ver- ist die allgemeine Bereitschaft zur Ent-schiedener Abstraktionsniveaus schlägt In technischer Hinsicht hülfe eine sol- scheidungsfindung Voraussetzung da-sich meistens in schlechtem Code nie- che Analyse dabei, ein klares Bild da- für, dass die Arbeiten eine konkreteder. Der Code reflektiert diese Ver- von zu ermitteln, welche Einschränkun- Richtung einschlagen können. Diesermengung, weil er sowohl mit den kon- gen der Softwarearchitekt annehmen dritte Punkt setzt zudem voraus, dasskreten fachlichen Elementen als auch darf und welche möglichen Varianten nicht messbare oder unterspezifizierteden technischen Spezifika der generi- er berücksichtigen muss. Dies schafft Anforderungen entweder präzisiert oderschen Rohdaten umgehen können die Strukturen bezüglich Anforderun- aufgegeben werden.muss. Ein vergleichbarer Fall liegt bei gen und Technologien, die für die Folglich erfordern ernst gemeinteHardwaretreibern vor, deren Schnitt- Konzeption einer erfolgreichen Platt- Plattformprojekte von allen Beteiligtenstellen zu stark verallgemeinert wur- formarchitektur notwendig sind (die – quer durch alle Disziplinen – ein Be-den – etwa in der Form, dass eine den erforderliche technische Expertise vo- kenntnis zum Plattformgedanken. DabeiTreiber nutzende Komponente zur rausgesetzt). Natürlich kann die Ana- muss klar sein, dass der Weg zur Platt-Laufzeit zunächst Details der tatsäch- lyse einige Iterationen durchlaufen und form keine gewöhnliche technische An-lichen Hardware-Auslegung über spe- muss dies üblicherweise auch tun – forderung darstellt, sondern budgetiertzielle Funktionen erfragen und Code wichtig ist dabei nur, dass man mög- und von allen Interessenvertretern mitfür jede denkbare Antwort vorsehen lichst viele der zentralen Fragen und beschritten werden muss. (ka)muss, bevor sie den Treiber in sinn- Risiken früh angeht, um dem Prozessvoller Weise einsetzen kann. der Architekturdefinition einen konkre- DR. DANIEL MÖLLE Das Überverallgemeinern einer ten Weg zu ebnen.Schnittstelle ist deshalb so kritisch, In organisatorischer Hinsicht kommt ist bei der Zühlke Engineering GmbHweil es ihre strukturierende Wirkung der Analyse eine weitere wichtige als Softwarearchitekt mit den Schwer-zunichte macht. Wenn die Schnittstelle Funktion zu, nämlich die, die Projekt- punkten eingebettete Systemeeiner Komponente alles zulässt, muss beteiligten mit offenen Augen durch und .Net tätig. xiX 6/2011 103 © Copyright by Heise Zeitschriften Verlag

×