Detailed Design für Software in Medizinprodukten
Per Modell von der Architektur zum Detaillierten Design
Ist ein Bild besser als 1000 Worte?
Dies muss nicht immer der Fall sein; es kommt - wie immer - auf die Bildqualität und vor allem auf die Blickrichtung des Betrachters an. Auch in der bekannteren Abwandlung der obigen These „Ein Bild sagt mehr als 1000 Worte“ kann es durchaus sein, dass das eine Bild zu viel erzählen möchte – oder sich schlimmstenfalls der falschen Sprache bedient!
Es soll im Kontext der Software-Entwicklung für Medizinprodukte in diesem Blogartikel darum gehen, inwieweit eine grafische Darstellung des Systems und dessen Spezifikation einer rein textuellen Beschreibung vorzuziehen wäre. Oder kompakter ausgedrückt: modellgetriebene Architektur & Design vs. textbasierter Spezifikation.
Das Modell – ein unbekanntes Fluch-Objekt?
Vor einigen Jahren kam im Rahmen eines gerade laufenden SW-Entwicklungsprojekts (Medizinprodukt) ein Kunde (in der Rolle des Entwicklungsleiters) auf mich zu und gab seiner leichten Besorgnis Ausdruck, er erkenne „doch gar nicht, wonach die SW-Entwickler das Produkt implementieren“, und bat mich dann freundlich, „das komplette Architekturmodell der SW bitte einmal auf DIN A2 auszudrucken – oder noch besser – gleich nach Visio zwecks Weiterverarbeitung zu exportieren“.
Ich entgegnete ihm, dass wir uns das wertvolle Papier sparen könnten – und die hübsche Darstellung in Visio auch keinen nachhaltigen Nutzen (außer als Snapshot für Präsentationen) bringen würde. Stattdessen haben wir uns für den Rest des Nachmittags zusammengesetzt, um das Thema der modellbasierten SW-Entwicklung und deren Merkmale am konkreten Projekt durchzugehen. Am Ende des Tages war der Kunde in keiner Weise mehr besorgt; es gab eine intensive und ertragreiche Diskussion über Modelle, Sichten, Viewpoints und Perspektiven – und den generellen Mehrwert einer Modellunterstützung für die in IEC 62304 eingeforderte detaillierte Design-Spezifikation (Gefährdungsklasse C).
Am Anfang steht die Software-Architektur.
Spätestens wenn die Software-Requirements aus den Systemanforderungen abgeleitet sind, sollte die Software System Architektur (SSA) erstellt werden. Der Abschnitt 5.3 der Norm IEC 62304 (Software life cycle processes) fordert dieses Lieferprodukt ab der Klasse B verbindlich ein. Im Kern soll die SSA die heruntergebrochene Struktur (Structure, Containment) aller beteiligten Software-Bestandteile (Software Items) abbilden, inklusive eventuell eingebundener Fremdsoftware (SOUP). Im zweiten Schritt werden die Schnittstellen (Interfaces) zwischen den ermittelten Bestandteilen erfasst und beschrieben.
Es ist naheliegend, die beiden eben genannten Gesichtspunkte der SW-Architektur grafisch zu spezifizieren. Eine weit verbreitete und anerkannte Notation ist die Unified Modeling Language (UML), die im Kern ein gutes Dutzend Diagrammtypen anbietet, mit der sich (nicht nur) Software vollständig spezifizieren lässt – hier zwei Beispiele:
Strukturmodellierung (beispielhaft)
Komponentendiagramm
Stellt logisch oder inhaltlich zusammengefasste SW-Elemente als Komponente dar und zeigt Schnittstellen zwischen den Komponenten.
Paketdiagramm
Stellt logisch oder inhaltlich zusammengefasste Bestandteile als Paket dar und zeigt Assoziationen zwischen den Paketen.
Diese Art der Darstellung würde die minimalen Anforderungen aus Abschnitt 5.3 der IEC 62304 erfüllen. Die Norm trifft im Übrigen keine besonderen Festlegungen zu der Granularität von Software Item und Software Unit – nur dass die Unit aus der Blickrichtung der Architektur nicht mehr weiter unterteilbar ist.
Bei mit C klassifizierten SW-Bestandteilen ist es zusätzlich erforderlich, Abgrenzung und Aufteilung der Bestandteile untereinander und deren sicherheitsrelevante Funktionen im Hinblick auf das Risikomanagement zu bewerten.
Erweiterte Anforderungen beim Detailed Design
Im Abschnitt 5.4 der IEC 62304 wird die fortgesetzte Zerlegung aller Items in Units gefordert (ab Klasse B). Für Klasse C muss dann für jede Unit die detaillierte Designbeschreibung angelegt werden, und zwar hauptsächlich für die Schnittstellen zwischen diesen, ebenso die Schnittstellen zu externen Komponenten wie Hardware und Umgebung.
Hier reicht eine rein statische Strukturbeschreibung (Structural Modeling) nicht aus; für die Modellierung von z.B. Bedienmanövern oder Kommunikationsprotokollen sollen zusätzlich zeitliche Aspekte, dynamische Funktionen und Verhaltensweisen (Behavioral Modeling) berücksichtigt werden.
Der modellbasierte Ansatz aus der Architektur bietet allerdings einen ausgezeichneten Startpunkt für das Detailed Design; und wieder bietet die UML die passenden Instrumente - sprich: Notationen und Diagramme - zur Verfeinerung der Architektur.
Dabei ist unbedingt zu beachten, dass die durch Zerlegung ermittelte Unit als kleinstes, unteilbares Element – im Sinne der SW-Architektur – immer als Blackbox betrachtet werden muss. Die Ausgestaltung der Unit ist ja schließlich genau die Aufgabe der Implementierung. Daher werden die unten angeführten Diagramme hier vorrangig zur Modellierung der Schnittstellen und Assoziationen zwischen den Units genutzt, Beispiele:
Strukturmodellierung (beispielhaft)
Kompositionsstrukturdiagramm
Komponiert logisch oder inhaltlich assoziierte SW-Parts als Bestandteile eines übergeordneten Ganzen. Parts sind immer Teil von etwas und können alleinstehend nicht existieren.
Klassendiagramm
Beschreibt Gestalt und Beziehungen von Klassen und deren bereitgestellten Schnittstellen.
Verhaltensmodellierung, Interaktionen (beispielhaft):
Zustandsdiagramm
Stellt das Laufzeitverhalten als eine Menge von Zuständen und dessen Übergängen dar.
Sequenzdiagramm
Visualisiert die Kommunikation zwischen Objekten entlang der Zeitachse für ein bestimmtes Szenario.
Aktivitätsdiagramm
Spezifiziert Daten- und Kontrollflüsse anhand von vernetzten Aktivitäten und Verzweigungen. Es entspricht am ehesten dem klassischen Programmablaufplan (PAP) oder Flussdiagramm und wird zur Detaillierung von Anwendungsfällen verwendet.
Wie detailliert darf es denn sein?
Die Feinarchitektur sollte sich in jedem Fall aus Details zur Implementierung heraushalten. Demnach kann man sich SW-Architektur und SW-Design als hierarchisches Konstrukt (top-down) vorstellen:
- Grobarchitektur: Ebenen 1 .. n
- Feinarchitektur(detailliertes Design): Ebenen n+1 .. m , m>n
- Implementierung: Ebene m+1
Methoden und Werkzeuge
Wie einleitend schon beschrieben wurde, ist die Verwendung von reinen „Zeichenprogrammen“ wie MS Visio oder CorelDraw zur SW-Modellierung nicht zu empfehlen. Diese Tools visualisieren lediglich; es gibt hier keine Meta-Ebene, welche das Modell, dessen Elemente und deren Assoziationen ganzheitlich beinhaltet.
Es gibt seit geraumer Zeit eine große Anzahl von Software-Modellierungswerkzeugen auf dem Markt und im OpenSource-Umfeld – hier nur ein kleiner Auszug:
Kommerziell:
- MagicDraw
- Enterprise Architect
- Rational Rhapsody
OpenSource:
- Papyrus unter EMF (Eclipse-basiert)
- modelio
Von vielen kommerziellen Tools existieren kostenlose Evaluierungsversionen (zeitlich begrenzt); hiermit kann man sich einen guten, vergleichenden Überblick verschaffen.
Interessant ist die Tatsache, dass einige Tools die Simulation des Modells sowie die Erzeugung von Quellcode aus dem Modell heraus unterstützen. Letzteres Feature hilft gerade bei dem Übergang vom Design zur Implementierung. Auch der umgekehrte Weg wird zum Teil angeboten – also das Generieren eines Modell aus einer Bestandssoftware durch automatisierte Analyse (Reverse engineering).
Pragmatisch ausgedrückt soll die Detaillierung demnach:
- so maximal sein, um dem SW-Entwickler (ohne weitere Rückfragen an den SW-Architekten) die Implementierung „seiner“ Unit zu ermöglichen, aber auch
- so minimal sein, um den Lösungsraum der Implementierung nicht unnötig einzuengen.
Die Art der Detaillierung lässt sich in zwei Komponenten zerlegen:
- Granularität: Wie hoch (Ebenenzahl m, n) wähle ich den Grad der Verfeinerung?
- Genauigkeit: Wie genau beschreibe ich Schnittstellen und Eigenschaften?
Resümee
Die Erstellung der Detailed Design Specification für Medizingeräte-Software wird seitens der Norm IEC 62304 [1], aber auch von der FDA [2] eingefordert - zumindest für SW-Komponenten, die ein hohes Gefährdungspotenzial für Patient oder Anwender im bestimmungsgemäßen Gebrauch, aber auch im Fehlerfall aufweisen.
In jedem Falle muss eine Software System Architecture (SSA) vorliegen, welche sinnvollerweise als Modell (z.B. unter Nutzung der UML) erstellt wird.
Hieraus kann durch eine weitere Verfeinerung des Architekturmodells das Detailed Design erreicht werden – immer unter Erhaltung der Konsistenz des Modells. Dabei sollte man wahlweise die Granularität oder die Genauigkeit erhöhen. Die UML kann auch zu diesem Zweck genutzt werden, so dass sich ein fast nahtloser Workflow unter Nutzung einheitlicher Werkzeuge darstellen lässt.
Nicht zuletzt ist ein sauber aufgesetztes und gepflegtes Architekturmodell inklusive vollständiger Spezifikation des Detailed Design eine hervorragende Wissensbasis, um z.B. neue Kollegen in das Team einzuarbeiten oder die Weiterentwicklung des Produkts zu visualisieren und zu planen – selbstverständlich immer in Abstimmung mit dem Anforderungsmanagement.
Unsere Empfehlung:
Machen Sie sich rechtzeitig Gedanken um Methodik und Werkzeuge zur Software- Systemarchitektur. Prüfen Sie, ob Ihre Entwicklungsabteilung dem modellbasierten Ansatz folgt (oder folgen würde). Holen Sie sich gegebenenfalls Unterstützung von Externen in Ihr Unternehmen, falls Ihnen die Einstiegsschwelle zu hoch erscheint. Zögern Sie auch nicht, Alt- oder Bestands-Software retrospektiv im Sinne von Architektur oder Design zu modellieren – oder als Dienstleistung modellieren zu lassen.
Das kommt öfter vor, als man annehmen möchte.
Fragen Sie uns!
Unser Newsletter „qonzentrat“
kompakt, professionell und präzise
Profitieren Sie von unserem Fachwissen.
Jetzt anmelden
