Ix 10 2011_medizinisch_praktisch_gut_moelle

416 views
338 views

Published on

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.

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
416
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Ix 10 2011_medizinisch_praktisch_gut_moelle

  1. 1. WISSEN Softwareentwicklung Modellgetriebene Ansätze – auch in der Medizintechnik Medizinisch, praktisch, gut Daniel Mölle 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.M odellgetriebene Ansätze wie die von der OMGspezifizierte Model Driven Ar- aus. Erstgenannte Disziplin ist innovationsbetont, weil die steigende Komplexität der zu tierung eines Algorithmus, die jedoch auf Sprachmittel oder Techniken zurückgreift, die lung und Regulierung berührt vor allem Prozessfragen und ist eine unerschöpfliche Quellechitecture sollen Softwareent- bewältigenden Aufgaben kon- aus Sicherheitserwägungen von Missverständnissen.wickler dabei unterstützen, die tinuierlich neue Konzepte nicht verwendet werden sol- Zum Glück lassen sich diezunehmende Komplexität von erfordert. Die Medizintechnik len. Analog dazu gibt es De- drei genannten WidersprücheAnwendungen in den Griff zu hingegen muss aufgrund von signprinzipien wie Kapselung in vielen Fällen auflösen. Sobekommen. Plattformunabhän- Sicherheitsbelangen zwangs- und Entkopplung, die aus bringt die Softwaretechnikgige Modelle, aus denen sich weise eine konservative Hal- Sicht des Softwareentwick- auch Innovationen und Lö-Sourcecode möglichst automa- tung einnehmen. Tatsächlich lers hochgradig wünschens- sungsmuster hervor, die be-tisch generieren lässt, befreien neigt die Softwaretechnik dazu, wert sind, aber im Rahmen währten Ansprüchen an dieProgrammierer unter anderem zunehmend größere Frame- von Sicherheitsmaßnahmen Sicherheit entgegenkommen.von lästigen Routinearbeiten. works und flexiblere Konzepte wie Programmablaufüberwa- Inwiefern dies für modellge-Zudem kann die Einbeziehung hervorzubringen. Sie ermög- chung oder gegenseitiger Kon- triebene Ansätze gilt, sieheoffener Standards eine gewis- lichen in weniger sicherheits- trolle zwischen Softwaremo- weiter unten.se Investitionssicherheit garan- kritischen Umfeldern eine er- dulen zum Teil aufgebrochen In ähnlicher Weise gibt estieren. Diverse Tools unterstüt- höhte Produktivität, stehen werden müssen. beim Entwurf gemeinsamezen diese Ansätze, sind jedoch aber oft im Widerspruch zu Werte und Ziele. Oft sind esauf unterschiedliche Aufgabenspezialisiert und eignen sich Sicherheitsvorgaben wie Vali- dierbarkeit, Transparenz oder Entwicklung in der Softwareentwicklung beispielsweise die einfachenebenso wenig wie alle Metho- statischer Analysierbarkeit. versus Regulation Konzepte (auch wenn dieseden, die unter den Sammel- Zudem haben die meisten nicht unbedingt leicht zu er-begriff „model-driven“ (MD*) Aufgaben in der Software- Softwareentwicklung erfordert mitteln sind), die eine Aufgabefallen, für alle Anwendungs- technik kreativen Charakter, außerdem eine gewisse Dyna- am elegantesten lösen. Diesedomänen. da sie den Entwurf von Syste- mik, zumal sich die Anforde- Einfachheit ist natürlich auch So zeichnen sich etwa men und Detaillösungen bein- rungen und Randbedingungen im Sinne der Sicherheit.Software- und Medizintech- halten, während ein reguliertes in Bewegung befinden, wo- Bezüglich der Dynamiknik, die bei Entwicklungspro- Umfeld tendenziell eine Ein- hingegen die in der Medizin- von Softwareprojekten kamjekten im Medical-Bereich schränkung von Kreativität technik geltenden Normen man bereits vor langer Zeit zuzwangsweise aufeinandersto- bedingt. Ein typisches Beispiel und Abläufe klare Grenzen der Erkenntnis, dass unflexibleßen, auf den ersten Blick hierfür wäre die besonders ele- setzen. Dieser Teil des Span- Wasserfallprozesse – Analyse,durch konträre Eigenschaften gante und knappe Implemen- nungsfelds zwischen Entwick- gefolgt von Architektur und112 iX 10/2011 © Copyright by Heise Zeitschriften Verlag FA-211, 2011
  2. 2. Design, im Anschluss daran Measurementdie Implementierung, dann dieTests und schließlich die Aus-lieferung – ein unrealistisches Idle WaitingForResultConfirmationModell sind. Dies schon allein Initial ResultConfirmed/ ClearScreendeshalb, weil sich die für dieAnalyse relevanten Anforde- StartMeasurement [ShutterNotOpen]/rungen und Randbedingungen ErrorConfirmed/ DisplayPleaseShutMessage ClearScreendes Projekts in Bewegung be-finden und nicht etwa zumZeitpunkt null als Konstanten ReportMeasurementResult/feststehen. Außerdem existie- WaitingForShutterToOpen StartMeasurement [ShutterOpen] WaitingForErrorConfirmation DisplayResultMessageren zwangsweise Feedback-Schleifen zwischen den Dis-ziplinen: So bleibt ein Design,dessen Umsetzbarkeit sich ReportSensorError/ ReportMeasurementError/ [ShutterOpen] DisplaySensorErrorMessage DisplayMeasurementErrorMessagenoch nicht durch eine zumin-dest grundlegende Implemen-tierung als haltbar erwiesen [SensorsReady]hat, erst mal ein schwebendes Checking Sensors PerformingMeasurementKonzept. Ähnlich naiv ist es anzu-nehmen, dass eine Ausliefe-rung am Ende des Projekts UML State Machines spielen bei MDD-Werkzeugen eine zentrale Rolle. Mit ihrer Hilfe las-ausreicht. Ganz im Gegenteil sen sich die wesentlichen Zustände einer Softwarekomponente und die Übergänge zwi-ist eine kontinuierliche Vor- schen diesen Zuständen modellieren (Abb.ˇ1).stellung von Zwischenergeb-nissen dringend erforderlich,um Feedback – beispielsweise IECˇ62304 (im AnnexˇB) aus- nition von MD* zwangsweise maten (Finite State Machines).Änderungswünsche an den drücklich auf inkrementelle hochgradig generisch ausfal- Das impliziert, dass der Ent-Anforderungen, die sich bei und evolutionäre Prozesse len. Deshalb ist es sinnvoller, wickler nur einen Rahmen fürder Demonstration von Zwi- nach ISO/IECˇ12207 ein. den Überblick anhand einiger die Software generieren kann,schenständen ergeben – früh- konkreter Ausprägungen her- während er Implementierungs-zeitig aufnehmen zu können.Im Gegensatz zu einer weit Modellgetriebene auszuarbeiten. Model-Driven Software details von Hand ergänzen muss. Alternativ kann er denverbreiteten Auffassung wider- Ansätze Development (MDSD, teil- Low-Level-Code schon insprechen die modernen Pro- weise auch nur MDD ge- den Modellen verstecken; bei-zesse und Methoden, die die- Der Sammelbegriff „model- nannt) legt den Fokus auf das spielsweise existieren popu-se Tatsachen berücksichtigen, driven“ fasst zahlreiche Me- Modellieren von Software, läre Modellierungswerkzeugenicht den normativen Anfor- thoden quer durch alle Dis- beispielsweise in UML. Hier für State Machines, die es ge-derungen: Die Normen fordern ziplinen der Softwaretechnik besteht das Hauptziel darin, statten, hinter den Zustands-zwar zu Recht klar definierte zusammen: Modellbasierte Teile des Codes – oder gar die übergängen (Transitionen) be-Prozesse sowie deren Ein- Ansätze existieren in Analyse, komplette Software – aus den liebigen Code einzuhängenhaltung, verlangen aber zum Architektur und Design, Im- erarbeiteten Modellen zu gene- (Abbildungˇ1).Glück nicht, dass es sich dabei plementierung, Test, Deploy- rieren. Die dabei erfassten As- Ein Softwaresystem in for-– provokant formuliert – um ment, Debugging et cetera. pekte haben typischerweise ein malen Modellen zu beschrei-möglichst ungeeignete Pro- Aufgrund dieser enormen höheres Abstraktionsniveau – ben, aus denen sich konkre-zesse handeln muss. Vielmehr Spannweite muss jeder Ver- etwa Komponenten, Klassen tere erzeugen lassen, ist imgeht beispielsweise die ISO/ such einer allgemeinen Defi- oder endliche Zustandsauto- engeren Sinne das Ziel der Model-Driven Architecture (MDA). Die Ausgangsmodel- le definieren die Struktur und x-TRACT das Funktionsspektrum des ● Modellbasierte Softwaretechniken wie MDSD/MDD, MDA und MDE sind State-of-the-Art- Systems, vorzugsweise in Be- Methoden der Softwareentwicklung, die dynamischen Anforderungen durch ein hohes griffen der jeweiligen Do- Abstraktionsniveau gerecht werden sollen. mäne, abstrahieren aber von technischen Spezifika der re- ● In der Medizintechnik gibt es strikte Sicherheitsvorgaben bezüglich Validier- und Analysier- levanten Zielplattformen (wie barkeit, die der Flexibilität innovativer Methoden Grenzen setzen. Hardware, Betriebssystem ● Wer den von MDD-Werkzeugen generierten Code den erforderlichen Kontrollen unterwirft, oder Frameworks). Sie wer- kann dennoch von der modellgetriebenen Entwicklung profitieren – speziell auch in Bereichen, den daher PIMs genannt: Plat- die den Produktivcode nicht direkt betreffen, etwa dem modellgetriebenen Deployment. form-Independent Models. Die Übersetzung dieser PIMs in konkretere Modelle resultiertiX 10/2011 113 © Copyright by Heise Zeitschriften Verlag
  3. 3. WISSEN Softwareentwicklungin PSMs: Platform-Specific Wenn jemand ausführbare Ar- Fülle anderer Details verbor- direkt, verzögert und durchModels. Im Extremfall kann tefakte aus formalen Modellen, gen liegt. händische Übersetzung in diedas Ergebnis dieser Trans- die das gewünschte Verhalten –ˇDie explizite Beschreibung Software einfließen.formation ausführbarer Code der Software beschreiben, ge- erfolgt in formalen Modellen. Allgemein lässt sich fest-sein, obgleich dies eine etwas neriert hat, kann er aus diesen Dabei ist der Begriff „formal“ stellen, dass modellgetriebeneweiche Auffassung von MDA Modellen auch Testfälle ab- hier informationstechnisch, Ansätze keine wundersamedarstellt, die den Unterschied leiten, um Abweichungen vom nicht regulatorisch gemeint: Erfindung, sondern eher einezwischen MDA und MDD definierten Verhalten aufzu- Die Modelle müssen maschi- natürliche Fortsetzung klas-verwischt. decken. nenlesbar sein, sich also streng sischer Softwareparadigmen Ein sehr weit ausgelegter an textuelle oder grafische sind. Eine saubere ArchitekturBegriff ist Model-Driven En-gineering (MDE), der dadurch Abstrakt, formal Grammatiken halten. Natür- lich müssen sie auch für Men- beispielsweise trennt bereits verschiedene Abstraktions-definiert ist, dass bei der Kon- und ableitbar schen lesbar sein, weil diese niveaus voneinander (etwastruktion von Softwaresyste- damit arbeiten. Konkrete Hardware-Treiber, technischemen ausdrücklich auf Domä- Insgesamt lässt sich feststel- Beispiele sind domänenspe- Dienste, fachliche Logik undnenmodelle gesetzt wird. Dies len, dass ein Vorgehen die drei zifische Sprachen (DSLs, Benutzerschnittstelle). Die Im-steht im Gegensatz zur klassi- folgenden Eigenschaften er- Domain-Specific Languages) plementierung ist auf der je-schen Softwareentwicklung, füllen muss, um als „model- oder UML-Diagramme, die weiligen Ebene zwangsweisedie sich eher auf die Imple- driven“ eingestuft zu werden: mittels geeigneter Werkzeuge explizit und formal, weil siementierung konzentriert, so- –ˇDie Beschreibung bestimm- in andere Artefakte transfor- in einer Programmiersprachedass Domänenspezifika im ter projektrelevanter Entitäten miert werden können. erfolgt. Dann aber ist derCode verborgen bleiben. Inso- erfolgt explizit und auf mög- –ˇDie erarbeiteten Modelle Wunsch, die nächsthöherefern kann man zum Beispiel lichst hohem Abstraktions- werden direkt für die Ablei- Ebene – das grundlegende De-MDA als eine konkrete Dis- niveau. Dies können sowohl tung anderer Artefakte einge- sign – ebenfalls formal undziplin oder Ausprägung von fachliche als auch technische setzt. Somit kommt den Mo- explizit zu erfassen, nur zuMDE verstehen. Darüber hi- Entitäten sein, etwa zu rea- dellen ausdrücklich die Rolle leicht verständlich. Wieder-naus berücksichtigt MDE As- lisierende fachliche Abläufe einer Datenquelle mit zentra- holt man diesen gedanklichenpekte wie Prozesse und Ana- oder die Architektur einer ler Bedeutung zu. Die in den Schritt, gelangt man nach undlyse. Software. Wichtig ist die ex- Modellen definierten Aspekte nach (wenn auch mit steigen- plizite Darstellung auf pas- wirken unmittelbar (und repro- dem Aufwand) zur formalen sendem Niveau. Zwar bein- duzierbar) auf die Software, Modellierung der gesamtenNicht ohne Test haltet jede Software implizit was letztendlich den Begriff Architektur, der Domäne oder die Information, welche Ab- „modellgetrieben“ motiviert. gar der Anforderungen. Letz-Model-Driven Testing, häufig läufe sie realisiert oder wel- Ein Gegenbeispiel sind klassi- teres dürfte aber in den meis-auch als Model-Based Testing che Architektur ihr innewohnt, sche Anforderungs- oder De- ten Fällen unrealistisch seinbezeichnet, ergibt sich gewis- diese Information ist aber signdokumente, weil sie zwar und erinnert an die naivensermaßen als naheliegende keineswegs leicht zu extra- auch formale Modelle enthal- Träume vom automatisiertenBegleiterscheinung von MDD: hieren, weil sie unter einer ten mögen, diese aber nur in- Programmieren, die es bereits vor einem halben Jahrhundert gab. texturelle Modelle grafische Modelle texturelle Modelle Generator eingehŠngter Code eingehŠngter Code Konsistenz ist garantiert grafische Modelle Die zentrale Stärke modellge- Generator triebener Ansätze wie MDD handgeschriebener liegt darin, dass die explizite generierter Code Code und formale Modellierung von generierter Code Struktur und Verhalten we- sentlich verbindlicher ist als Compiler implizite Absichtserklärungen + Linker in isolierten Fließtextdoku- Compiler menten, zumal die relevanten + Linker Softwareartefakte direkt aus den Modellen generiert wer- den. Die automatische Trans- ausfŸhrbare Software ausfŸhrbare Software formation garantiert – die kor- rekte Funktion des Werkzeugs vorausgesetzt – die KonsistenzZwei verbreitete Ausprägungen von MDSD. In beiden Fällen beschreiben die Modelle zwischen den Modellen undlediglich einige zentrale Aspekte der Software. Links vervollständigt handgeschriebener den erzeugten Artefakten.Code den generierten Code-Rahmen, rechts wird der konkrete Code direkt in die Modelle Zusätzlich erweisen sich dieeingehängt und vom Generator in den erzeugten Code eingebracht (Abb.ˇ2). Modelle als wichtiges Kom-114 iX 10/2011 © Copyright by Heise Zeitschriften Verlag
  4. 4. munikationswerkzeug, das es Frage erlaubt sein, ob es wirk- zen erzeugen lassen. Auch Artefakte in formalen Model-erlaubt, auf einem geeigneten lich sinnvoll ist, neben dem die Entwicklung der relevan- len repräsentiert, für die diesAbstraktionsniveau über rele- grundlegenden Design Imple- ten Transformationswerkzeu- aus seiner Sicht einen beson-vante Abläufe oder Designent- mentierungsdetails – oder gar ge ist keine einfache Auf- ders großen Nutzen hat. Einscheidungen zu diskutieren. den gesamten Code – an die gabe. In vielen Projekten mit plastisches Beispiel ist dieDies erleichtert sowohl den In- Modelle zu heften (Tagging). einer überschaubaren Menge Formulierung von Zustands-formationsfluss innerhalb des Viele MDD-Werkzeuge for- an zugrunde liegenden Platt- maschinen in einer textuellenEntwicklungsteams als auch cieren diesen Ansatz, was die formen ist es praktisch unmög- oder grafischen DSL, wäh-die Präsentation nach außen. Hersteller zu der euphori- lich, den Aufwand für eine rend die Details der Imple-Diesem Aspekt verdanken die schen Aussage verleitet, man resolute Durchführung einer mentierung – etwa exit, entrydomänenspezifischen Spra- könne die gesamte Software vollständigen MDA zu recht- und transition actions – inchen, in denen die Modelle aus dem Modell erzeugen las- fertigen. klassischem Sourcecode aus-formuliert werden, einen Groß- sen. Dies ist aber nicht ganz Model-Based Testing wie- definiert werden. Hierbei ist esteil ihrer Popularität. wahr, weil der heimlich ange- derum führt zwar dazu, dass wichtig, generierte und hand- klebte Code ein viel niedrige- sich Testfälle leicht und in be- geschriebene Quellen sauberPragmatismus res Abstraktionsniveau hat als das sichtbare Modell (meist liebiger Zahl erzeugen lassen – garantiert aber nicht, dass voneinander zu trennen, damit man den Generator jederzeitstatt Fanatismus UML). Solcher Code kann na- dabei auch die interessanten wieder aufrufen kann, ohne türlich nicht ernsthaft als Be- Testfälle anfallen. Somit mag die manuell implementiertenAngesichts der deutlich sicht- standteil des Modells gelten; Model-Based Testing eine Teile zu überschreiben.baren Vorzüge werden mo- kurz: UML-Zustandsautoma- sinnvolle Ergänzung sein,dellgetriebene Ansätze gern inder Form von Heilsverspre- ten kennen kein C++. Letzt- endlich wird die Software kann aber auf keinen Fall die kreative Penetranz erzielen, Modellgetriebenechen beworben. Ein Indikator somit aus einer unsauberen die erfahrene Tester so wert- Medizintechnikhierfür ist die allseits bekann- Vermengung von Modellen voll macht. Ein Gefühl fürte Satzform: „X wird die ob- und Code-Stücken erzeugt kritische Randfälle, typisches Die folgenden Ausführungenjektorientierte Softwareent- (Abbildungˇ2). Benutzerverhalten oder klassi- sollen der Frage auf den Grundwicklung so revolutionieren, Die MDA hingegen leidet sche Implementierungsfehler gehen, inwiefern sich modell-wie es diese einst mit der in ihrer Reinform ein wenig (und wenn sie im Transforma- getriebene Ansätze mit denstrukturierten Programmierung unter der enormen Abstrak- tor liegen) lässt sich beim bes- Besonderheiten der Medizin-getan hat.“ Hier wird für X tionslast (diese entfällt, wenn ten Willen nicht generieren technik vereinbaren lassen.gerne tagesaktuell eine zu be- der Begriff MDA in dem Sinne (Abbildungˇ3). Relevant ist dabei insbesonde-werbende Technologie einge- weit gefasst wird, dass im We- Aufgrund dieser Kritik hat re, dass die in diesem Umfeldsetzt, und tatsächlich finden sentlichen MDD gemeint ist). sich neben einer reinen Lehre, zu entwickelnden Produkte insich solche Aussagen auch in Es ist im Allgemeinen ausge- die den vollumfänglichen Ein- den meisten Fällen sicherheits-Ausprägungen wie X=„MDE“. sprochen aufwendig, eine Do- satz modellgetriebener Ansät- kritisch sind und somit zahl- Allerdings stehen modellge- mäne und eine Meta-Archi- ze propagiert, eine pragma- reichen normativen Anforde-triebene Ansätze nicht außer- tektur so gut zu spezifizieren, tische Auffassung etabliert. rungen unterliegen.halb jeder Kritik. Hinsichtlich dass sich daraus automatisch Letztere liegt dann vor, wenn Der mögliche KonfliktMDD beispielsweise muss die plattformspezifische Instan- ein Projektteam nur solche zwischen MD* und Medizin- Was braucht es, damit jährlich Tausende von Menschen wieder klarer sehen? Eine Idee mehr. Und Zühlke.iX 10/2011 115 © Copyright by Heise Zeitschriften Verlag
  5. 5. WISSEN Softwareentwicklungtechnik liegt keineswegs in wenig überzogen, wenn nicht vollumfängliches MDD (im Systems außerhalb des Source-dem Bestreben, fachliche oder sogar esoterisch. Allerdings Sinne der reinen Lehre, siehe codes modelliert und somittechnische Artefakte explizit gehört MDA sowieso eher oben) als auch die Frame- nur bestimmte Teile generiertin formalen Modellen zu no- in die Welt der Enterprise- works für die Verwendung werden.tieren. Im Gegenteil – die aus- Projekte, während medizin- projektspezifischer DSLs (im Noch unproblematischerdrückliche Formulierung ist technische Produkte meistens Sinne des pragmatischen, re- sind modellgetriebene Ansät-transparenter. Auch die Idee, in den Embedded-Bereich duzierten Ansatzes) dazu nei- ze, die sich nicht auf den Pro-Teile der Software aus diesen fallen. Geeignetere Ansätze gen, groß und komplex zu duktivcode auswirken. DiesModellen zu erzeugen, ist im wie MDD leiden nicht unter sein. Das absolute Gros dieser gilt zum Beispiel für modell-Kern unproblematisch – im- dieser Überabstraktion, weil Werkzeuge ist nicht validiert, getriebenes Deployment, beimerhin erhöht das die Kon- sie nur Artefakte definieren, sondern bestenfalls in dem dem man Build- und Installati-sistenz zwischen Design und die sich ohnehin direkt in der Sinne validierbar, dass sie be- onsregeln aus Modellen ablei-Implementierung. Außerdem konkreten Software wieder- reits im Rahmen anderer Pro- tet – die erzeugten Artefaktehilft das Generieren von Code finden. jekte – aber nur für diese – ih- lassen sich leicht auf Korrekt-oft dabei, die Entwickler von re Praxistauglichkeit bewiesen heit kontrollieren. Ähnlichesunkreativen und fehlerträch- haben (gewissermaßen als trifft auf das modellbasiertetigen Aufgaben zu befreien – Tools evaluieren Präzedenzfall). In den meisten Testen zu, bei dem die gene-insbesondere, wenn sie As- Fällen dürfte der Versuch ei- rierten Testfälle einerseits ei-pekte der Infrastruktur (etwa Der Problemkern liegt somit ner ernsthaften Validierung nem Review unterzogen undKomponenten, Abhängigkei- in den umfangreichen Werk- enorm aufwendig ausfallen, andererseits durch manuell er-ten und Zustandsautomaten) zeugen. Viele Medizin-Pro- zumal Entwickler oft nur einen stellte Testfälle ergänzt wer-nicht immer wieder händisch jekte umfassen auch die Be- Bruchteil der von den Werk- den können.ausformulieren müssen. wertung, die Risikoanalyse zeugen angebotenen Funktio- Vielmehr liegen die kriti- oder gar die Validierung der nen nutzen.schen Punkte in der Tendenz im Rahmen der Entwicklung Allerdings gibt es – und Fazitzur Überabstraktion einerseits eingesetzten Tools. Dies be- das ist die gute Nachricht – ei-und der Abhängigkeit von um- trifft unter anderem Com- nen pragmatischen Ausweg: Es steht außer Frage, dassfangreichen Werkzeugen ande- piler/Linker, Build-Skripte, Statt das Werkzeug zu vali- modellgetriebene Ansätze einrerseits. Ersteres zeigt sich vor Revisionsverwaltung und Be- dieren, kann man einfach den mächtiges Instrument der mo-allem bei so weitgehenden triebssysteme (für das Target). generierten Code denselben dernen Softwaretechnik dar-Ansätzen wie MDA: Die Be- Da modellgetriebene Ansätze Kontrollen unterwerfen, de- stellen. Während einige wieschreibung eines Domänenmo- immer auch Werkzeuge für die nen sonst der handgeschriebe- die Model-Driven Architec-dells und einer Meta-Architek- Transformation oder Code-Ge- ne Code ausgesetzt ist. Dieser ture (MDA) aufgrund ihrestur auf extrem hohen Niveau, nerierung erfordern, dürfen sie Ansatz verträgt sich aus nahe- enormen Abstraktionsniveausum daraus plattformspezifi- bei der Bewertung nicht außer liegenden Gründen besonders eher in die Enterprise-Weltsche Architekturinstanzen zu Acht gelassen werden. gut mit der pragmatischen gehören, können andere wiegewinnen, ist aus Sicht der Auffällig ist, dass sowohl Auffassung von MDD, bei der Model-Driven DevelopmentMedizintechnik sicherlich ein die typischen Werkzeuge für nur bestimmte Aspekte des (MDD) oder Model-Based Testing ihre Vorteile auch in der Medizintechnik ausspie- INFO button pressed len. Den zahlreichen Vorteilen WelcomeScreen InfoScreen der expliziten und formalen Initial Modellierung produktrelevan- Traversed when ter Artefakte, technisch wie POWER button pressed INFO button pressed fachlich, stehen aber kom- OKAY button pressed plexe Werkzeuge gegenüber. OKAY button pressed Lassen sich diese nicht auf wirtschaftliche Weise vali- POWER button pressed dieren, können die generier- ShutdownScreen MainScreen ten Entitäten (beispielsweise Sourcecode) immer noch den- selben Kontrollen unterwor- fen werden, die nach ihrer OKAY button pressed OKAY button pressed manuellen Erstellung durch- zuführen wären. (ka) 3 seconds elapsed MeasurementScreen ResultScreen DR. DANIEL MÖLLE ist bei der Zühlke Enginee-Die Qualität der aus diesem Modell für die GUI-Abläufe eines Geräts generierten Testfälle ring GmbH als Software-ist durch die Aussagekraft des Modells beschränkt. Im Beispiel könnten zwar die darge- architekt mit den Schwer-stellten Screen-Typen, nicht aber die konkreten Bildschirminhalte als Testkriterien herange- punkten eingebettetezogen werden (Abb.ˇ3). Systeme und .Net tätig. x116 iX 10/2011 © Copyright by Heise Zeitschriften Verlag
  6. 6. Was braucht es, damit die Diagnostikdem Defekt einen Schritt voraus ist?Eine Idee mehr. Und Zühlke.Defekte beheben, bevor sie auftreten. Zühlke entwickelt eine maßgeschneiderte, mobileinsetzbare Diagnostik-Software für einen weltweit tätigen Baumaschinenhersteller.Techniker analysieren damit aus der Ferne den Zustand der Baumaschinen und lassenfunktionskritische Teile rechtzeitig ersetzen. Das Resultat: Deutlich mehr Betriebsstundenbei geringeren Service- und Unterhaltskosten. Consulting Development Integration www.zuehlke.com

×