×
Behaviour Driven Design| qtec-group

Behaviour Driven Design bei Medizingeräten

25. Mai 2022

Funktionale Architekturen sind eine Art von Architekturbeschreibung, die das Verhalten eines Systems beschreibt. Anders als die typische, technische Architektur, beschäftigt sich die funktionale Architektur nicht mit technischen Detailfragen, sondern versucht, die verhaltensspezifischen Inhalte der Anforderungen strukturiert aufzuarbeiten und darzustellen.

Starte mit Funktionalität, nicht technischen Details!

Die Entwicklung von Software hat einen typischen Ablauf. Zunächst werden Anforderungen gesammelt und strukturiert aufgeschrieben, basierend auf diesen eine Struktur für die Software überlegt (Software Architektur) und basierend auf dieser wiederum eine Implementierung vorgenommen. Die Software Architektur wird dabei üblicherweise mittels Diagrammen der Unified Modeling Language (UML) dargestellt, die bereits sehr konkrete Informationen über die Komponenten der Software, deren Schnittstellen untereinander und nach außen sowie eine Menge von technischen Interna jeder Komponente enthält. Der Weg von den Anforderungen zur Architektur wird allerdings üblicherweise nicht dokumentiert. Welche Anforderung und Funktionalität sich genau in welchem Aspekt der Architektur wieder findet, kann meistens nur von erfahrenen Entwicklern beurteilt werden.

In einem so regulierten und sicherheitskritischen Feld wie der Entwicklung von Medizingeräten ist aber ein solcher Zusammenhang zwischen Funktionen / Anforderungen und der Architektur - nicht nur für die Software, sondern auch für das System bzw. das Produkt - eine wichtige Komponente, um Entscheidungen nachvollziehen zu können, Erweiterungen leichter auf einer abstrakteren Ebene planen zu können und die Gründe für die gegebene Architektur zu dokumentieren. In diesem Rahmen empfehlen wir die Erstellung einer funktionalen Architektur, bevor man zu der eigentlichen, technischen Architektur der Software kommt.

Behaviour Driven Development für bessere Nachvollziehbarkeit von Tests

Behaviour Driven Development stellt einen Ansatz zur Entwicklung von Software und Systemen über einen Zwischenschritt einer Verhaltensspezifikation dar. Beim Erstellen von Tests bietet dies den Vorteil, dass zunächst diese Verhaltensspezifikation geschrieben und die Tests dann von dieser abgeleitet werden, anstatt, dass ein Testentwickler direkt den Test schreibt. Dies erlaubt eine bessere Nachvollziehbarkeit und Verständlichkeit der Tests und wie diese entstanden sind, da die abstrakten Gedanken des Testentwicklers in der Verhaltensspezifikation mit dokumentiert werden. Ansonsten fehlt dieser Zwischenschritt vollständig.

Dasselbe Problem der fehlenden Nachvollziehbarkeit und Dokumentation durch eine Zwischenrepräsentation existiert auch beim Erstellen von Architekturen. Dieses Problem soll durch den Einsatz von Behaviour Driven Design, und damit funktionalen Architekturen, behoben werden.

Funktionale Architekturen durch Behaviour Driven Design

Im Gegensatz zu herkömmlichen, technischen Architekturen bilden funktionale Architekturen keinerlei technische Aspekte ab. Sie sind allein dafür da, funktionale Komponenten zu identifizieren, deren Verknüpfung miteinander zu beschreiben und gegebenenfalls Funktionalität einzelner Komponenten durch, zum Beispiel, mathematische Beschreibungen abstrakt darzustellen.

„Der abstrakte Blick auf einzelne Komponenten oder deren Verknüpfung bildet die Schnittstelle zwischen User-/Stakeholder-Needs und der technischen Architektur.“

 

Dr. Torben Scheffel, qtec Experte

Durch diesen abstrakten Blick bilden sie genau die Schnittstelle zwischen User-/Stakeholder Needs und einer technischen Architektur und gliedern sich direkt in diesen roten Faden ein. Siehe folgendes Bild für den Zusammenhang zwischen funktionaler Architektur, technischer Architektur und physikalischer (realer) Architektur.

Im Folgenden wird noch einmal ein Blick auf ein konkretes Beispiel aus einer funktionalen und einer technischen Architektur geworfen:

Diese beiden Diagramme beschreiben eine funktionale Architektur. Auf der linken Seite ist eine abstrakte Übersicht der einzelnen Funktionsblöcke zu sehen, die die verschiedenen Funktionalitäten der Gaseinheiten in einem Gerät für z.B. Beatmung oder Anästhesie abbilden. Auf der rechten Seite findet sich eine konkrete Übersicht der Verbindungen der einzelnen Elemente auf einer funktionalen Ebene. Es werden keinerlei technische Details beschrieben, sondern die Zusammenhänge der einzelnen Elemente sowie deren Verhalten zueinander. Für jedes Element werden die Ein- und Ausgaben beschrieben. So lässt sich zum einen festhalten, welches funktionale Element was verarbeitet und erzeugt und zum anderen Wege durch die funktionalen Elemente nachvollziehen. Zum Beispiel kann man sehen, dass sowohl GasA als auch GasB durch jeweils eine Gas dosing Einheit gehen und schließlich in die Gas mixing Einheit fließen.

Schließlich sehen wir eine mögliche technische Architektur, die aus der vorher gezeigten, funktionalen Architektur erstellt worden sein könnte. Im Vergleich zur funktionalen Architektur von vorher sind in der technischen Architektur deutlich mehr technische Details zu sehen, wie Druckmessungen und Drosseleinrichtungen, die für eine technische Umsetzung nötig sind, für die reine, funktionale Sicht auf das Gerät aber keine Rolle spielen.

Funktionale Architektur als  ergänzender Zwischenschritt

Wie zu sehen ist, bildet die funktionale Architektur einen ergänzenden Zwischenschritt zwischen den User/Stakeholder Needs und der technischen Architektur. Sie strukturiert die durch die Anforderungen gegebenen Aspekte, die sich auf die Erstellung der eigentlichen, technischen Architektur auswirken könnten und stellt deren Zusammenhänge und das Verhalten abstrakt dar. Von dieser funktionalen Sicht aus lässt sich deutlich einfacher und strukturierter dann die technische Sicht ableiten, als wenn man dies direkt von den funktionalen Anforderungen aus tun würde.

Welche Vorteile bietet eine funktionale Architektur und Behaviour Driven Design?

Die Vorteile dieser zusätzlichen Ebene bei der Erstellung einer Architektur sind vielfältig. Konkret ergeben sich unter anderem folgende, positive Effekte:

  • Die zusätzliche, funktionale Architektur enthält direkt die Möglichkeit, die erstellte Architektur insgesamt zu simulieren, da man nicht nur eine technische Sicht durch die entsprechende Architektur hat, sondern auch eine Sicht des erlaubten Verhaltens.
  • Die funktionale Architektur kann zur Dokumentation im Design History File (DHF) herangezogen werden, da sie zusätzlich zur technischen Architektur einen weiteren Aspekt des Designprozesses dokumentiert.
  • Die funktionale Architektur gibt eine zusätzliche Übersicht über Möglichkeiten der Erweiterbarkeit des Systems. Oft sind diese Möglichkeiten nur schwer aus den Anforderungen selbst herauszulesen. Die funktionale Architektur eignet sich durch ihre strukturierte Darstellung hervorragend dafür.
  • Letztendlich repräsentiert die funktionale Architektur auch einen wichtigen, domänenübergreifenden Wissensspeicher. Hiermit erhält man per Abstraktion („was“ anstatt „wie“) ein besseres Verständnis von komplexer Software, Produkten oder Systemen - und eine erklärende Rückverfolgbarkeit aus Sicht der nachgelagerten technischen Umsetzung und getroffenen Design-Entscheidungen.
 

Wünschen Sie sich eine konsistente Entwicklung Ihrer Software?

Haben Sie eine Lücke in Ihrer Designhistorie? Fehlt Ihnen eine abstrakte, aber strukturierte Beschreibung des Verhaltens für eine konsistente Entwicklung und Planung Ihrer Software? Unsere Expertinnen und Experten entwicklen Lösungen für Sie. Rufen Sie uns an!

Kontakt +49 451 808 503 60

Zusammenfassung

In diesem Artikel wurden funktionale Architekturen vorgestellt, eine Art von Architekturbeschreibung, die das Verhalten eines Systems beschreibt. Anders als die typische, technische Architektur, beschäftigt sich die funktionale Architektur nicht mit technischen Detailfragen, sondern versucht, die verhaltensspezifischen Inhalte der Anforderungen strukturiert aufzuarbeiten und darzustellen. Dies bietet ergänzend zur technischen Sicht eine Möglichkeit, einen weiteren Aspekt der Anforderungen abzubilden und, unter anderem, als Dokumentation des Designs zu verwenden.

Passende Seminare in der qtec Academy

20.11.- 21.11.­2024

Fachbeitrag von qtec-group

qtec-group ist Teil unseres vielköpfigen Teams aus Expertinnen und Experten.
Hier finden Sie alle Beiträge:

Alle Beiträge von qtec-group

Unser Newsletter „qonzentrat“

kompakt, professionell und präzise

Profitieren Sie von unserem Fachwissen.

Jetzt anmelden