Ix 10 2011_medizinisch_praktisch_gut_moelle

6
M odellgetriebene Ansätze wie die von der OMG spezifizierte Model Driven Ar- chitecture sollen Softwareent- wickler dabei unterstützen, die zunehmende Komplexität von Anwendungen in den Griff zu bekommen. Plattformunabhän- gige Modelle, aus denen sich Sourcecode möglichst automa- tisch generieren lässt, befreien Programmierer unter anderem von lästigen Routinearbeiten. Zudem kann die Einbeziehung offener Standards eine gewis- se Investitionssicherheit garan- tieren. Diverse Tools unterstüt- zen diese Ansätze, sind jedoch auf unterschiedliche Aufgaben spezialisiert und eignen sich ebenso wenig wie alle Metho- den, die unter den Sammel- begriff „model-driven“ (MD*) fallen, für alle Anwendungs- domänen. So zeichnen sich etwa Software- und Medizintech- nik, die bei Entwicklungspro- jekten im Medical-Bereich zwangsweise aufeinandersto- ßen, auf den ersten Blick durch konträre Eigenschaften aus. Erstgenannte Disziplin ist innovationsbetont, weil die steigende Komplexität der zu bewältigenden Aufgaben kon- tinuierlich neue Konzepte erfordert. Die Medizintechnik hingegen muss aufgrund von Sicherheitsbelangen zwangs- weise eine konservative Hal- tung einnehmen. Tatsächlich neigt die Softwaretechnik dazu, zunehmend größere Frame- works und flexiblere Konzepte hervorzubringen. Sie ermög- lichen in weniger sicherheits- kritischen Umfeldern eine er- höhte Produktivität, stehen aber oft im Widerspruch zu Sicherheitsvorgaben wie Vali- dierbarkeit, Transparenz oder statischer Analysierbarkeit. Zudem haben die meisten Aufgaben in der Software- technik kreativen Charakter, da sie den Entwurf von Syste- men und Detaillösungen bein- halten, während ein reguliertes Umfeld tendenziell eine Ein- schränkung von Kreativität bedingt. Ein typisches Beispiel hierfür wäre die besonders ele- gante und knappe Implemen- tierung eines Algorithmus, die jedoch auf Sprachmittel oder Techniken zurückgreift, die aus Sicherheitserwägungen nicht verwendet werden sol- len. Analog dazu gibt es De- signprinzipien wie Kapselung und Entkopplung, die aus Sicht des Softwareentwick- lers hochgradig wünschens- wert sind, aber im Rahmen von Sicherheitsmaßnahmen wie Programmablaufüberwa- chung oder gegenseitiger Kon- trolle zwischen Softwaremo- dulen zum Teil aufgebrochen werden müssen. Entwicklung versus Regulation Softwareentwicklung erfordert außerdem eine gewisse Dyna- mik, zumal sich die Anforde- rungen und Randbedingungen in Bewegung befinden, wo- hingegen die in der Medizin- technik geltenden Normen und Abläufe klare Grenzen setzen. Dieser Teil des Span- nungsfelds zwischen Entwick- lung und Regulierung berührt vor allem Prozessfragen und ist eine unerschöpfliche Quelle von Missverständnissen. Zum Glück lassen sich die drei genannten Widersprüche in vielen Fällen auflösen. So bringt die Softwaretechnik auch Innovationen und Lö- sungsmuster hervor, die be- währten Ansprüchen an die Sicherheit entgegenkommen. Inwiefern dies für modellge- triebene Ansätze gilt, siehe weiter unten. In ähnlicher Weise gibt es beim Entwurf gemeinsame Werte und Ziele. Oft sind es in der Softwareentwicklung beispielsweise die einfachen Konzepte (auch wenn diese nicht unbedingt leicht zu er- mitteln sind), die eine Aufgabe am elegantesten lösen. Diese Einfachheit ist natürlich auch im Sinne der Sicherheit. Bezüglich der Dynamik von Softwareprojekten kam man bereits vor langer Zeit zu der Erkenntnis, dass unflexible Wasserfallprozesse – Analyse, gefolgt von Architektur und 112 iX 10/2011 WISSEN Softwareentwicklung Obwohl ein aktueller Trend, sind modellge- triebene Ansätze nicht uneingeschränkt für jedes Projekt das Richtige. Es gilt nicht nur, zwischen den verschiedenen Methoden zu unterscheiden, sondern vor allem zu prüfen, welche von ihnen in welchem Um- fang den Besonderheiten der jeweiligen Domäne gerecht werden können, beispielsweise der Medizintechnik. Modellgetriebene Ansätze – auch in der Medizintechnik Medizinisch, praktisch, gut Daniel Mölle © Copyright by Heise Zeitschriften Verlag

description

Obwohl ein aktueller Trend, sind modellge - triebene Ansätze nicht uneingeschränkt für jedes Projekt das Richtige. Es gilt nicht nur, zwischen den verschiedenen Methoden zu unter scheiden, sondern vor allem zu prüfen, welche von ihnen in welchem Umfang den Besonderheiten der jeweiligen Domäne gerecht werden können, beispielsweise der Medizintechnik.

Transcript of Ix 10 2011_medizinisch_praktisch_gut_moelle

Page 1: Ix 10 2011_medizinisch_praktisch_gut_moelle

Modellgetriebene Ansätzewie die von der OMG

spezifizierte Model Driven Ar-chitecture sollen Softwareent-wickler dabei unterstützen, diezunehmende Komplexität vonAnwendungen in den Griff zubekommen. Plattformunabhän-gige Modelle, aus denen sichSourcecode möglichst automa-tisch generieren lässt, befreienProgrammierer unter anderemvon lästigen Routinearbeiten.Zudem kann die Einbeziehungoffener Standards eine gewis-se Investitionssicherheit garan-tieren. Diverse Tools unterstüt-zen diese Ansätze, sind jedochauf unterschiedliche Aufgabenspezialisiert und eignen sichebenso wenig wie alle Metho-den, die unter den Sammel -begriff „model-driven“ (MD*)fallen, für alle Anwendungs-domänen.

So zeichnen sich etwaSoftware- und Medizintech-nik, die bei Entwicklungspro-jekten im Medical-Bereichzwangsweise aufeinandersto-ßen, auf den ersten Blickdurch konträre Eigenschaften

aus. Erstgenannte Disziplin istinnovationsbetont, weil diesteigende Komplexität der zubewältigenden Aufgaben kon-tinuierlich neue Konzepte erfordert. Die Medizintechnikhingegen muss aufgrund vonSicherheitsbelangen zwangs-weise eine konserva tive Hal-tung einnehmen. Tatsächlichneigt die Softwaretechnik dazu,zunehmend größere Frame-works und flexiblere Konzeptehervorzubringen. Sie ermög -lichen in weniger sicherheits-kritischen Umfeldern eine er-höhte Produktivität, stehenaber oft im Widerspruch zuSicherheitsvorgaben wie Vali-dierbarkeit, Transparenz oderstatischer Analysierbarkeit.

Zudem haben die meistenAufgaben in der Software-technik kreativen Charakter,da sie den Entwurf von Syste-men und Detaillösungen bein-halten, während ein reguliertesUmfeld tendenziell eine Ein-schränkung von Kreati vitätbedingt. Ein typisches Beispielhierfür wäre die besonders ele-gante und knappe Implemen-

tierung eines Algorithmus, diejedoch auf Sprachmittel oderTechniken zurückgreift, dieaus Sicherheitserwägungennicht verwendet werden sol-len. Analog dazu gibt es De-signprinzipien wie Kapselungund Entkopplung, die ausSicht des Softwareentwick-lers hochgradig wünschens-wert sind, aber im Rahmenvon Sicherheitsmaßnahmenwie Programmablaufüber wa -chung oder gegenseitiger Kon-trolle zwischen Softwaremo-dulen zum Teil aufgebrochenwerden müssen.

Entwicklung versus RegulationSoftwareentwicklung erfordertaußerdem eine gewisse Dyna-mik, zumal sich die Anforde-rungen und Randbedingungenin Bewegung befinden, wo-hingegen die in der Medizin-technik geltenden Normenund Abläufe klare Grenzensetzen. Dieser Teil des Span-nungsfelds zwischen Entwick-

lung und Regulierung berührtvor allem Prozessfragen undist eine unerschöpfliche Quellevon Missverständnissen.

Zum Glück lassen sich diedrei genannten Widersprüchein vielen Fällen auflösen. Sobringt die Softwaretechnikauch Innovationen und Lö-sungsmuster hervor, die be-währten Ansprüchen an dieSicherheit entgegenkommen.Inwiefern dies für modellge-triebene Ansätze gilt, sieheweiter unten.

In ähnlicher Weise gibt esbeim Entwurf gemeinsameWerte und Ziele. Oft sind esin der Softwareentwicklungbeispielsweise die einfachenKonzepte (auch wenn diesenicht unbedingt leicht zu er-mitteln sind), die eine Aufgabeam elegantesten lösen. DieseEinfachheit ist natürlich auchim Sinne der Sicherheit.

Bezüglich der Dynamikvon Softwareprojekten kamman bereits vor langer Zeit zuder Erkenntnis, dass unflexibleWasserfallprozesse – Analyse,gefolgt von Architektur und

112 iX 10/2011

WISSEN Softwareentwicklung

Obwohl ein aktueller Trend, sind modellge -triebene Ansätze nicht uneingeschränkt für jedes

Projekt das Richtige. Es gilt nicht nur, zwischen denverschiedenen Methoden zu unter scheiden, sondern

vor allem zu prüfen, welche von ihnen in welchem Um-fang den Besonderheiten der jeweiligen Domäne gerecht

werden können, beispielsweise der Medizintechnik.

Modellgetriebene Ansätze – auch in der Medizintechnik

Medizinisch, praktisch, gut

Daniel Mölle

ix.1011.112-116 06.09.2011 10:46 Uhr Seite 112

© Copyright by Heise Zeitschriften Verlag

ptr
Typewritten Text
ptr
Typewritten Text
FA-211, 2011
Page 2: Ix 10 2011_medizinisch_praktisch_gut_moelle

Design, im Anschluss darandie Implementierung, dann dieTests und schließlich die Aus-lieferung – ein unrealistischesModell sind. Dies schon alleindeshalb, weil sich die für dieAnalyse relevanten Anforde-rungen und Randbedingungendes Projekts in Bewegung be-finden und nicht etwa zumZeitpunkt null als Konstantenfeststehen. Außerdem existie-ren zwangsweise Feedback-Schleifen zwischen den Dis-ziplinen: So bleibt ein Design,dessen Umsetzbarkeit sichnoch nicht durch eine zumin-dest grundlegende Implemen-tierung als haltbar erwiesenhat, erst mal ein schwebendesKonzept.

Ähnlich naiv ist es anzu-nehmen, dass eine Ausliefe-rung am Ende des Projektsausreicht. Ganz im Gegenteilist eine kontinuierliche Vor-stellung von Zwischenergeb-nissen dringend erforderlich,um Feedback – beispielsweiseÄnderungswünsche an denAnforderungen, die sich beider Demonstration von Zwi-schenständen ergeben – früh-zeitig aufnehmen zu können.Im Gegensatz zu einer weitverbreiteten Auffassung wider-sprechen die modernen Pro-zesse und Methoden, die die-se Tatsachen berücksichtigen,nicht den normativen Anfor-derungen: Die Normen fordernzwar zu Recht klar definierteProzesse sowie deren Ein -haltung, verlangen aber zumGlück nicht, dass es sich dabei– provokant formuliert – ummöglichst ungeeignete Pro -zesse handeln muss. Vielmehrgeht beispielsweise die ISO/

IECˇ62304 (im AnnexˇB) aus-drücklich auf inkrementelleund evolutionäre Prozessenach ISO/IECˇ12207 ein.

ModellgetriebeneAnsätzeDer Sammelbegriff „model-driven“ fasst zahlreiche Me-thoden quer durch alle Dis -ziplinen der Softwaretechnikzusammen: ModellbasierteAnsätze existieren in Analyse,Architektur und Design, Im-plementierung, Test, Deploy-ment, Debugging et cetera.Aufgrund dieser enormenSpannweite muss jeder Ver-such einer allgemeinen Defi-

nition von MD* zwangsweisehochgradig generisch ausfal-len. Deshalb ist es sinnvoller,den Überblick anhand einigerkonkreter Ausprägungen her -auszuarbeiten.

Model-Driven SoftwareDevelopment (MDSD, teil-weise auch nur MDD ge-nannt) legt den Fokus auf dasModellieren von Software,beispielsweise in UML. Hierbesteht das Hauptziel darin,Teile des Codes – oder gar diekomplette Software – aus denerarbeiteten Modellen zu gene-rieren. Die dabei erfassten As-pekte haben typischerweise einhöheres Abstraktionsniveau –etwa Komponenten, Klassenoder endliche Zustandsauto-

maten (Finite State Machines).Das impliziert, dass der Ent-wickler nur einen Rahmen fürdie Software generieren kann,während er Implementierungs -details von Hand ergänzenmuss. Alternativ kann er denLow-Level-Code schon inden Modellen verstecken; bei-spielsweise existieren popu -läre Modellierungswerkzeugefür State Machines, die es ge-statten, hinter den Zustands-übergängen (Transitionen) be-liebigen Code einzuhängen(Abbildungˇ1).

Ein Softwaresystem in for-malen Modellen zu beschrei-ben, aus denen sich konkre -tere erzeugen lassen, ist imengeren Sinne das Ziel derModel-Driven Architecture(MDA). Die Ausgangsmodel-le definieren die Struktur unddas Funktionsspektrum desSystems, vorzugsweise in Be-griffen der jeweiligen Do -mäne, abstrahieren aber vontechnischen Spezifika der re-levanten Zielplattformen (wieHardware, Betriebssystemoder Frameworks). Sie wer-den daher PIMs genannt: Plat-form-Independent Models. DieÜbersetzung dieser PIMs inkonkretere Modelle resultiert

iX 10/2011 113

x-TRACT● Modellbasierte Softwaretechniken wie MDSD/MDD, MDA und MDE sind State-of-the-Art-

Methoden der Softwareentwicklung, die dynamischen Anforderungen durch ein hohes Abstrak tionsniveau gerecht werden sollen.

● In der Medizintechnik gibt es strikte Sicherheitsvorgaben bezüglich Validier- und Analysier -barkeit, die der Flexibilität innovativer Methoden Grenzen setzen.

● Wer den von MDD-Werkzeugen generierten Code den erforderlichen Kontrollen unterwirft, kann dennoch von der modellgetriebenen Entwicklung profitieren – speziell auch in Bereichen,die den Produktivcode nicht direkt betreffen, etwa dem modellgetriebenen Deployment.

���������

��������� �������� �� ��

��� ������ ������������ �������������������������������

���� �������

���� ���������������������

���� ��������������������� �������������

������ ������� �������� ���������

�����

! ��� �������� �� ��

��� ������ ������������ ����

������� ���� ��� ���� ! ����������� ! �������

��� ������ �������������������������������

��� ������ ����! ������������� ����! �������

UML State Machines spielen bei MDD-Werkzeugen eine zentrale Rolle. Mit ihrer Hilfe las-sen sich die wesentlichen Zustände einer Softwarekomponente und die Übergänge zwi-schen diesen Zuständen modellieren (Abb.ˇ1).

ix.1011.112-116 06.09.2011 10:46 Uhr Seite 113

© Copyright by Heise Zeitschriften Verlag

Page 3: Ix 10 2011_medizinisch_praktisch_gut_moelle

in PSMs: Platform-SpecificModels. Im Extremfall kanndas Ergebnis dieser Trans -formation ausführbarer Codesein, obgleich dies eine etwasweiche Auffassung von MDAdarstellt, die den Unterschiedzwischen MDA und MDDverwischt.

Ein sehr weit ausgelegterBegriff ist Model-Driven En-gineering (MDE), der dadurchdefiniert ist, dass bei der Kon-struktion von Softwaresyste-men ausdrücklich auf Domä-nenmodelle gesetzt wird. Diessteht im Gegensatz zur klassi-schen Softwareentwicklung,die sich eher auf die Imple-mentierung konzentriert, so-dass Domänenspezifika imCode verborgen bleiben. Inso-fern kann man zum BeispielMDA als eine konkrete Dis-ziplin oder Ausprägung vonMDE verstehen. Darüber hi-naus berücksichtigt MDE As-pekte wie Prozesse und Ana-lyse.

Nicht ohne TestModel-Driven Testing, häufigauch als Model-Based Testingbezeichnet, ergibt sich gewis-sermaßen als naheliegendeBegleiterscheinung von MDD:

Wenn jemand ausführbare Ar-tefakte aus formalen Modellen,die das gewünschte Verhaltender Software beschreiben, ge-neriert hat, kann er aus diesenModellen auch Testfälle ab -leiten, um Abweichungen vomdefinierten Verhalten aufzu -decken.

Abstrakt, formalund ableitbarInsgesamt lässt sich feststel-len, dass ein Vorgehen die dreifolgenden Eigenschaften er-füllen muss, um als „model-driven“ eingestuft zu werden:–ˇDie Beschreibung bestimm-ter projektrelevanter Entitätenerfolgt explizit und auf mög-lichst hohem Abstraktions -niveau. Dies können sowohlfachliche als auch technischeEntitäten sein, etwa zu rea -lisierende fachliche Abläufeoder die Architektur einerSoftware. Wichtig ist die ex-plizite Darstellung auf pas-sendem Niveau. Zwar bein-haltet jede Software implizitdie Information, welche Ab-läufe sie realisiert oder wel-che Architektur ihr innewohnt,diese Information ist aberkeineswegs leicht zu extra-hieren, weil sie unter einer

Fülle anderer Details verbor-gen liegt.–ˇDie explizite Beschreibungerfolgt in formalen Modellen.Dabei ist der Begriff „formal“hier informationstechnisch,nicht regulatorisch gemeint:Die Modelle müssen maschi-nenlesbar sein, sich also strengan textuelle oder grafischeGrammatiken halten. Natür-lich müssen sie auch für Men-schen lesbar sein, weil diesedamit arbeiten. KonkreteBeispiele sind domänenspe-zifische Sprachen (DSLs,Domain-Specific Languages)oder UML-Diagramme, diemittels geeigneter Werkzeugein andere Artefakte transfor-miert werden können.–ˇDie erarbeiteten Modellewerden direkt für die Ablei-tung anderer Artefakte einge-setzt. Somit kommt den Mo-dellen ausdrücklich die Rolleeiner Datenquelle mit zentra-ler Bedeutung zu. Die in denModellen definierten Aspektewirken unmittelbar (und repro-duzierbar) auf die Software,was letztendlich den Begriff„modellgetrieben“ motiviert.Ein Gegenbeispiel sind klassi-sche Anforderungs- oder De-signdokumente, weil sie zwarauch formale Modelle enthal-ten mögen, diese aber nur in-

direkt, verzögert und durchhändische Übersetzung in dieSoftware einfließen.

Allgemein lässt sich fest-stellen, dass modellgetriebeneAnsätze keine wundersameErfindung, sondern eher einenatürliche Fortsetzung klas -sischer Softwareparadigmensind. Eine saubere Architekturbeispielsweise trennt bereitsverschiedene Abstraktions -niveaus voneinander (etwaHardware-Treiber, technischeDienste, fachliche Logik undBenutzerschnittstelle). Die Im-plementierung ist auf der je-weiligen Ebene zwangsweiseexplizit und formal, weil siein einer Programmierspracheerfolgt. Dann aber ist derWunsch, die nächsthöhereEbene – das grundlegende De-sign – ebenfalls formal undexplizit zu erfassen, nur zuleicht verständlich. Wieder-holt man diesen gedanklichenSchritt, gelangt man nach undnach (wenn auch mit steigen-dem Aufwand) zur formalenModellierung der gesamtenArchitektur, der Domäne odergar der Anforderungen. Letz-teres dürfte aber in den meis-ten Fällen unrealistisch seinund erinnert an die naivenTräume vom automatisiertenProgrammieren, die es bereitsvor einem halben Jahrhundertgab.

Konsistenz ist garantiertDie zentrale Stärke modellge-triebener Ansätze wie MDDliegt darin, dass die expliziteund formale Modellierung vonStruktur und Verhalten we-sentlich verbindlicher ist alsimplizite Absichtserklärungenin isolierten Fließtextdoku-menten, zumal die relevantenSoftwareartefakte direkt ausden Modellen generiert wer-den. Die automatische Trans-formation garantiert – die kor-rekte Funktion des Werkzeugsvorausgesetzt – die Konsistenzzwischen den Modellen undden erzeugten Artefakten.

Zusätzlich erweisen sich dieModelle als wichtiges Kom-

114 iX 10/2011

WISSEN Softwareentwicklung

� ��������������

�������� ��"�� ���

#�� ��

��� �� �� ����

������ $�%�&� ������

$�%�&�

����'� "� �����(� �

��)�� ����������������*��� ������)�� �����������

�����*��� ����� ��������������

����'� "� �����(� �

#�� ��

��� �� �� ����

Zwei verbreitete Ausprägungen von MDSD. In beiden Fällen beschreiben die Modelle lediglich einige zentrale Aspekte der Software. Links vervollständigt handgeschriebenerCode den generierten Code-Rahmen, rechts wird der konkrete Code direkt in die Modelleeingehängt und vom Generator in den erzeugten Code eingebracht (Abb.ˇ2).

ix.1011.112-116 06.09.2011 10:46 Uhr Seite 114

© Copyright by Heise Zeitschriften Verlag

Page 4: Ix 10 2011_medizinisch_praktisch_gut_moelle

munikationswerkzeug, das eserlaubt, auf einem geeignetenAbstraktionsniveau über rele-vante Abläufe oder Designent-scheidungen zu diskutieren.Dies erleichtert sowohl den In-formationsfluss innerhalb desEntwicklungsteams als auchdie Präsentation nach außen.Diesem Aspekt verdanken diedomänenspezifischen Spra-chen, in denen die Modelleformuliert werden, einen Groß-teil ihrer Popularität.

Pragmatismus statt FanatismusAngesichts der deutlich sicht-baren Vorzüge werden mo-dellgetriebene Ansätze gern inder Form von Heilsverspre-chen beworben. Ein Indikatorhierfür ist die allseits bekann-te Satzform: „X wird die ob-jektorientierte Softwareent-wicklung so revolutionieren,wie es diese einst mit derstrukturierten Programmierunggetan hat.“ Hier wird für Xgerne tagesaktuell eine zu be-werbende Technologie einge-setzt, und tatsächlich findensich solche Aussagen auch inAusprägungen wie X=„MDE“.

Allerdings stehen modellge-triebene Ansätze nicht außer-halb jeder Kritik. HinsichtlichMDD beispielsweise muss die

Frage erlaubt sein, ob es wirk-lich sinnvoll ist, neben demgrundlegenden Design Im ple-mentierungsdetails – oder garden gesamten Code – an dieModelle zu heften (Tagging).Viele MDD-Werkzeuge for-cieren diesen Ansatz, was dieHersteller zu der euphori-schen Aussage verleitet, mankönne die gesamte Softwareaus dem Modell erzeugen las-sen. Dies ist aber nicht ganzwahr, weil der heimlich ange-klebte Code ein viel niedrige-res Abstraktionsniveau hat alsdas sichtbare Modell (meistUML). Solcher Code kann na-türlich nicht ernsthaft als Be-standteil des Modells gelten;kurz: UML-Zustandsautoma-ten kennen kein C++. Letzt-endlich wird die Software somit aus einer unsauberenVermengung von Modellenund Code-Stücken erzeugt(Abbildungˇ2).

Die MDA hingegen leidetin ihrer Reinform ein wenigunter der enormen Abstrak -tionslast (diese entfällt, wennder Begriff MDA in dem Sinneweit gefasst wird, dass im We-sentlichen MDD gemeint ist).Es ist im Allgemeinen ausge-sprochen aufwendig, eine Do-mäne und eine Meta-Ar chi -tektur so gut zu spezifizieren,dass sich daraus automatischplattformspezifische Instan-

zen erzeugen lassen. Auchdie Entwicklung der relevan-ten Transformationswerk zeu -ge ist keine einfache Auf -gabe. In vielen Projekten miteiner überschaubaren Mengean zugrunde liegenden Platt-formen ist es praktisch unmög-lich, den Aufwand für eineresolute Durchführung einervollständigen MDA zu recht-fertigen.

Model-Based Testing wie-derum führt zwar dazu, dasssich Testfälle leicht und in be-liebiger Zahl erzeugen lassen– garantiert aber nicht, dassdabei auch die interessantenTestfälle anfallen. Somit magModel-Based Testing einesinnvolle Ergänzung sein,kann aber auf keinen Fall diekreative Penetranz erzielen,die erfahrene Tester so wert-voll macht. Ein Gefühl fürkritische Randfälle, typischesBenutzerverhalten oder klassi-sche Implementierungsfehler(und wenn sie im Transforma-tor liegen) lässt sich beim bes-ten Willen nicht generieren(Abbildungˇ3).

Aufgrund dieser Kritik hatsich neben einer reinen Lehre,die den vollumfänglichen Ein-satz modellgetriebener Ansät-ze propagiert, eine pragma -tische Auffassung etabliert.Letztere liegt dann vor, wennein Projektteam nur solche

Artefakte in formalen Model-len repräsentiert, für die diesaus seiner Sicht einen beson-ders großen Nutzen hat. Einplastisches Beispiel ist dieFormulierung von Zustands-maschinen in einer textuellenoder grafischen DSL, wäh-rend die Details der Imple-mentierung – etwa exit, entryund transition actions – inklassischem Sourcecode aus-definiert werden. Hierbei ist eswichtig, generierte und hand-geschriebene Quellen saubervoneinander zu trennen, damitman den Generator jederzeitwieder aufrufen kann, ohnedie manuell implementiertenTeile zu überschreiben.

ModellgetriebeneMedizintechnikDie folgenden Ausführungensollen der Frage auf den Grundgehen, inwiefern sich modell-getriebene Ansätze mit denBesonderheiten der Medizin-technik vereinbaren lassen.Relevant ist dabei insbesonde-re, dass die in diesem Umfeldzu entwickelnden Produkte inden meisten Fällen sicherheits-kritisch sind und somit zahl-reichen normativen Anforde-rungen unterliegen.

Der mögliche Konfliktzwischen MD* und Medizin-

iX 10/2011 115

ix.1011.112-116 06.09.2011 10:46 Uhr Seite 115

© Copyright by Heise Zeitschriften Verlag

Was braucht es, damit jährlich Tausende von Menschen wieder klarer sehen?

Eine Idee mehr. Und Zühlke.

Page 5: Ix 10 2011_medizinisch_praktisch_gut_moelle

technik liegt keineswegs indem Bestreben, fachliche odertechnische Artefakte explizitin formalen Modellen zu no-tieren. Im Gegenteil – die aus-drückliche Formulierung isttransparenter. Auch die Idee,Teile der Software aus diesenModellen zu erzeugen, ist imKern unproblematisch – im-merhin erhöht das die Kon-sistenz zwischen Design undImplementierung. Außerdemhilft das Generieren von Codeoft dabei, die Entwickler vonunkreativen und fehlerträch -tigen Aufgaben zu befreien –insbesondere, wenn sie As-pekte der Infrastruktur (etwaKomponenten, Abhängigkei-ten und Zustandsautomaten)nicht immer wieder händischausformulieren müssen.

Vielmehr liegen die kriti-schen Punkte in der Tendenzzur Überabstraktion einerseitsund der Abhängigkeit von um-fangreichen Werkzeugen an de-rerseits. Ersteres zeigt sich vorallem bei so weitgehenden Ansätzen wie MDA: Die Be-schreibung eines Domänenmo-dells und einer Meta-Architek-tur auf extrem hohen Niveau,um daraus plattformspezifi-sche Architekturinstanzen zugewinnen, ist aus Sicht derMedizintechnik sicherlich ein

wenig überzogen, wenn nichtsogar esoterisch. Allerdingsgehört MDA sowieso eher in die Welt der Enter prise-Projekte, während medizin-technische Produkte meistensin den Embedded-Bereichfallen. Geeignetere Ansätzewie MDD leiden nicht unterdieser Überabstraktion, weilsie nur Artefakte definieren,die sich ohnehin direkt in derkonkreten Software wieder-finden.

Tools evaluierenDer Problemkern liegt somitin den umfang reichen Werk-zeugen. Viele Medizin-Pro-jekte umfassen auch die Be-wertung, die Risikoanalyseoder gar die Validierung derim Rahmen der Entwicklungeingesetzten Tools. Dies be-trifft unter anderem Com -piler/Lin ker, Build-Skripte,Revi sions verwaltung und Be-triebs sys teme (für das Target).Da modellgetriebene Ansätzeimmer auch Werkzeuge für dieTransformation oder Code-Ge-nerierung erfordern, dürfen siebei der Bewertung nicht außerAcht gelassen werden.

Auffällig ist, dass sowohldie typischen Werkzeuge für

vollumfängliches MDD (imSinne der reinen Lehre, sieheoben) als auch die Frame-works für die Verwendungprojektspezifischer DSLs (imSinne des pragmatischen, re-duzierten Ansatzes) dazu nei-gen, groß und komplex zusein. Das absolute Gros dieserWerkzeuge ist nicht validiert,sondern bestenfalls in demSinne validierbar, dass sie be-reits im Rahmen anderer Pro-jekte – aber nur für diese – ih-re Praxistauglichkeit bewiesenhaben (gewissermaßen alsPräzedenzfall). In den meistenFällen dürfte der Versuch ei-ner ernsthaften Validierungenorm aufwendig ausfallen,zumal Entwickler oft nur einenBruchteil der von den Werk-zeugen angebotenen Funktio-nen nutzen.

Allerdings gibt es – unddas ist die gute Nachricht – ei-nen pragmatischen Ausweg:Statt das Werkzeug zu vali-dieren, kann man einfach dengenerierten Code denselbenKontrollen unterwerfen, de-nen sonst der handgeschriebe-ne Code ausgesetzt ist. DieserAnsatz verträgt sich aus nahe-liegenden Gründen besondersgut mit der pragmatischenAuffassung von MDD, bei dernur bestimmte Aspekte des

Systems außerhalb des Source-codes modelliert und somitnur bestimmte Teile generiertwerden.

Noch unproblematischersind modellgetriebene Ansät-ze, die sich nicht auf den Pro-duktivcode auswirken. Diesgilt zum Beispiel für modell-getriebenes Deployment, beidem man Build- und Installati-onsregeln aus Modellen ablei-tet – die erzeugten Artefaktelassen sich leicht auf Korrekt-heit kontrollieren. Ähnlichestrifft auf das modellbasierteTesten zu, bei dem die gene-rierten Testfälle einerseits ei-nem Review unterzogen undandererseits durch manuell er-stellte Testfälle ergänzt wer-den können.

FazitEs steht außer Frage, dassmodellgetriebene Ansätze einmächtiges Instrument der mo-dernen Softwaretechnik dar-stellen. Während einige wiedie Model-Driven Architec -ture (MDA) aufgrund ihresenormen Abstraktionsniveauseher in die Enterprise-Weltgehören, können andere wieModel-Driven Development(MDD) oder Model-BasedTesting ihre Vorteile auch inder Medizintechnik ausspie-len. Den zahlreichen Vorteilender expliziten und formalenModellierung produktrele van -ter Artefakte, technisch wiefachlich, stehen aber kom - plexe Werkzeuge gegenüber.Lassen sich diese nicht aufwirtschaftliche Weise vali -dieren, können die generier-ten Enti täten (beispielsweiseSource code) immer noch den-selben Kontrollen unterwor-fen werden, die nach ihrermanuellen Erstellung durch-zuführen wären. (ka)

DR. DANIEL MÖLLE ist bei der Zühlke Enginee-ring GmbH als Software -architekt mit den Schwer-punkten eingebetteteSysteme und .Net tätig. x

116 iX 10/2011

WISSEN Softwareentwicklung

�+��"����� �����

,��������������

��������������������

��������

�������������� ����������

�����

����� �����

�-./�"����� �����

�-./�"����� �����

�+��"����� �����

�-./�"����� �����

�-./�"����� �����

��0!��"����� �����

1 �2� ����(����0!��"����� �����

Die Qualität der aus diesem Modell für die GUI-Abläufe eines Geräts generierten Testfälleist durch die Aussagekraft des Modells beschränkt. Im Beispiel könnten zwar die darge-stellten Screen-Typen, nicht aber die konkreten Bildschirminhalte als Testkriterien herange-zogen werden (Abb.ˇ3).

ix.1011.112-116 06.09.2011 10:46 Uhr Seite 116

© Copyright by Heise Zeitschriften Verlag

Page 6: Ix 10 2011_medizinisch_praktisch_gut_moelle

ConsultingDevelopmentIntegration

www.zuehlke.com

Was braucht es, damit die Diagnostik dem Defekt einen Schritt voraus ist?

Eine Idee mehr. Und Zühlke.Defekte beheben, bevor sie auftreten. Zühlke entwickelt eine maßgeschneiderte, mobil einsetzbare Diagnostik-Software für einen weltweit tätigen Baumaschinenhersteller. Techniker analysieren damit aus der Ferne den Zustand der Baumaschinen und lassen funktionskritische Teile rechtzeitig ersetzen. Das Resultat: Deutlich mehr Betriebsstunden bei geringeren Service- und Unterhaltskosten.