Modellierung „Echt Zeit“ für Use-Cases

Objektorientierte Methoden werden immer beliebter und die UML trägt als Quasistandard für die Modellierung ihren Teil dazu bei. Leider bieten die meisten UML-Bücher lediglich Beispiele für kommerzielle Software. In diesem Beitrag versuchen wir, Use-Cases in die Welt von eingebetteten Systemen und Systemen mit Echtzeitanforderungen zu übertragen.

Anbieter zum Thema

MicroConsult Academy GmbH

MES Electronic Connect GmbH & Co. KG

CADFEM Germany GmbH

SOPHIST GmbH

Was ist das besondere an Echtzeit- und Embedded-Systemen, im Folgenden kurz RTE-Systeme genannt? Warum können nicht einfach alle Erfahrungen und Vorgaben aus der kommerziellen Modellierung unreflektiert übernommen werden? Weil RTE-Systeme eben etwas mehr beinhalten als nur Software. Hinter einem RTE-System verbirgt sich neben dem Software- zumindest noch ein Hardwareanteil. Oftmals ist aber auch andere Technik wie z.B. mechanische, elektrische oder elektronische Komponenten an der Verarbeitung beteiligt.

Eine funktionale Zerlegung des Systems

Um RTE-Systeme erfolgreich zu spezifizieren ist ein ganzheitlicher Ansatz nötig, der sich nicht sofort auf die Einzelteile des Systems (z. B. Hardware oder Software) konzentriert, sondern das System als Gesamtheit von außen — aus der Nutzersicht – betrachtet. Dementsprechend eignen sich Use-Cases für die erste Beschreibung eines RTE-Systems hervorragend.

Die meisten Systeme sind relativ umfangreich und zu komplex, um sie „am Stück“ zu begreifen. Deshalb müssen wir unsere Systeme in mundgerechte, verdaubare Bissen zerteilen. Mit dem Use-Case-Ansatz wird die Zerteilung auf funktionaler Ebene verfolgt. Dabei betrachten wir das System von außen als eine Blackbox und überlegen uns, welches die Akteure außerhalb unseres Systems sind. Wenn wir die Akteure kennen, halten wir fest, was diese von unserem System erwarten. Dadurch erhalten wir die Use-Cases unseres System, was automatisch eine funktionale Zerlegung des Systems in leichter fassbare Einheiten bewirkt.

Bis jetzt haben wir zwei essenzielle Punkte bei der Use-Case-Betrachtung festgestellt.

• Akteure befinden sich außerhalb des Systems. Sie wollen etwas von dem System.
• Use-Cases sind innerhalb des Systems. Sie spezifizieren grob, was das System tut, wenn ein Akteur etwas will.

Wie bereits erwähnt beinhalten RTE-Systeme mehr als nur Software. Man muss sich daher bei RTE-Systemen explizit Gedanken darüber machen, was außerhalb und was innerhalb der Systemgrenzen liegt. Zur Betrachtung der Systemgrenzen verwendet man idealerweise ein Kontextdiagramm. Dieses stellt eindeutig und auf einen Blick dar, was sich innerhalb der Systemgrenzen und was sich außerhalb befindet und wie die Ein- und Ausgabeschnittstellen zwischen Innen und Außen aussehen. Ohne Kontextdiagramm lassen sich Beginn und Ende eines Use-Cases nur schwer präzisieren. Das Kontextdiagramm an sich ist nicht Bestandteil der UML, kann aber mit UML-Diagrammtypen (z.B. Klassendiagramm) simuliert werden. Wir möchten aber in diesem Artikel nicht näher darauf eingehen, sondern auf „UML 2 glasklar“ von Chris Rupp et.al. (Hanser Verlag) und „Agile Softwareentwicklung“ von Chris Rupp und Peter Hruscka (Hanser Verlag) verweisen .

Identifizierung von Akteuren

Da das Innenleben bei RTE-Systemen mehr als nur Software umfassen kann stellen Use-Cases die „Systemprozesse“ quer durch Hard- und Software dar. Architektur- und Desingentscheidungen werden bei der Use-Case-Betrachtung absichtlich außer acht gelassen. Diese ganzheitliche Systembetrachtung mittels Use-Cases ist bei RTE-Systemen erfolgsentscheidend.

Grundsätzlich gilt, dass alle Akteure außerhalb des Systems zu finden sind und von diesem etwas haben möchten. Betrachten wir auch die Suche nach Akteuren doch einmal für RTE-Systeme. Wer – und das muss man nun auch einschließen – oder was löst etwas in RTE-Systemen aus? Manchmal sind bei diesen Systemen Menschen die Auslöser, allerdings stellt der Akteur Mensch bei RTE-Systemen eher die Ausnahme dar. Es gibt mindestens drei weitere Kategorien von Auslösern, die von Bedeutung sind:

• Sensoren,
• Nachbarsysteme und
• die Zeit.

Die Sensoren zählen nur dann zu den Akteuren, wenn sie außerhalb des Systems zu finden sind. Sie erfassen Informationen (z.B. Temperatur, Lichteinfall) und ermitteln Ereignisse (z.B. die Überschreitung von Schwellwerten, Siedepunkten), die für das System von Bedeutung sind. Diese Daten initiieren im System die Ausführung von Use-Cases. Betrachtet man den Sensor jedoch als Teil des Hard-/Softwaresystems, so wird anstatt des Sensors die physikalische Größe, die der Sensor misst als Akteur angesehen.

Engebettete Systeme unterhalten häufig viele Schnittstellen zu anderen Systemen. Dementsprechend treten Nachbarsysteme oder die das System umgebenden Systeme ebenfalls häufig als Initiatoren wichtiger Use-Cases unseres RTE-Systems auf.

Da wir von Echtzeitsystemen sprechen, ist auch den Faktor Zeit ein Akteur. UseCases werden häufig zu definierten Zeitpunkten oder an definierten Terminen ausgelöst. Dabei ist weder ein Nachbarsystem noch ein Mensch explizit an der Auslösung beteiligt. Die Systemreaktion ist vorab eingeplant oder terminiert.

Wenn Sie sich also auf die Suche nach Akteuren für Ihre Systeme machen, dann suchen Sie bitte in allen vier Kategorien. Erfahrungsgemäß finden sich bei vielen RTE-Systemen eine Menge von Nachbarsystemen, Sensoren oder Zeitauslösern. Menschen als Akteure befinden sich eher in der Minderheit. Sind alle Akteure und die initiierten Use-Cases ermittelt, geht es vor allem darum, den essenziellen fachlichen Ablauf zu den gefundenen Use-Cases zu beschreiben.

(ID:272796)