„Echt Zeit“ für Use-Cases

Anbieter zum Thema

MicroConsult Academy GmbH

MES Electronic Connect GmbH & Co. KG

CADFEM Germany GmbH

SOPHIST GmbH

Wie viele Use-Cases hat mein System?

Wichtig ist es bei der Beschreibung der Use-Cases vor allem darauf zu achten, dass diese weitestgehend frei von technischen Entscheidungen bleibt. Da RTE-Systeme stark von Technik geprägt sind, ist es nicht immer leicht, einen Use-Case so zu beschreiben, aber dies ermöglicht es die Use-Cases möglichst langlebig zu gestalten und wiederverwendbar zu machen.

Ist Technik in der Beschreibung von Use-Cases verboten? Mitnichten. Sollten technische Entscheidungen unumstößlich feststehen, so ist es möglich, diese Informationen in der Use-Case-Beschreibung zu erwähnen. Dabei sollten die technikbelasteten Stellen der Beschreibung dennoch klar von den essenziellen, technikneutralen Beschreibungsbestandteilen getrennt werden.

Hierzu gibt es verschiedenste gestalterische Mittel, wie die farbliche Markierung, Kursivschreibung bis hin zur räumlichen Trennung der unterschiedlichen Anteil. Außerdem führt eine vollkommen technikfreie Beschreibung sehr schnell zu einer starken Abstraktion, die für den Leser sehr unverständlich ist. Wenn technische Entscheidungen bereits feststehen, können diese auch als pragmatischer Ansatz mit in das Projekt einfließen, anstatt künstlich neue technikneutrale Begriffe zu erfinden. Der Preis für dieses pragmatischen Vorgehen ist allerdings eine schlechtere Wiederverwendbarkeit bei einem potenziellen Wechsel der Technik, der Gewinn eventuell eine höhere Akzeptanz des Anwenders, da die Begriffe in seiner Sprachwelt verbleiben.

Wie viele Use-Cases sollten man in einer echten Anwendungen finden? Die einzig richtige Antwort lautet: so viele, wie es unabhängige, von Akteuren ausgelöste Prozesse gibt. Aber wie viele sind das?

Bei bestimmten Arten von RTE-Systemen findet man nur einen einzigen echten Systemprozess! Wird ein System modelliert, das sich hauptsächlich mit Regelung beschäftigt, dann ist der Regelungsprozess häufig der einzig interessante. Hier sollte nicht auf Biegen und Brechen versucht werden, diesen Use-Case in mehrere Einzelteile zu zerlegen. Dafür gibt es geeignetere Mittel (vgl. Abschnitt „Use-Case-Modell und andere UML-Modelle“ weiter unten).

Natürlich kann ein technisches System auch aus mehreren Use-Cases bestehen. In diesem Fall sollte man sich für die Darstellung im Diagramm auf die 7+-2 wichtigsten beschränken. Falls Sie versucht sind, Dutzende (oder sogar Hunderte) von scheinbaren Use-Cases hinzuschreiben, befinden Sie sich mit aller Wahrscheinlichkeit bereits zu tief im Detail. Um dies zu verhindern, ist es hilfreich sich vorzustellen, was bei jedem dieser Use-Cases das Ziel des Akteurs ist. Dabei lässt sich häufig feststellen, dass viele dieser Use-Cases das gleiche Ziel verfolgen. Demnach können diese zu einem abstrakteren zusammengefasst werden.

Use-Cases sind eine wirkliche Bereicherung der Analysemethoden. Zwei Hauptvorteile sind die von außen getriebene Zerlegung eines komplexen Systems in natürliche, (relativ) unabhängige Abläufe sowie die Verständlichkeit für viele Projektbeteiligte. Machen Sie diese Vorteile nicht zunichte, indem Sie versuchen, Use-Cases übermäßig zu strukturieren oder zu verfeinern.

Use-Cases und die Notation von Zeitanforderungen

Für die Verfeinerung bietet die UML andere Diagramme (z.B. Aktivitätsdiagramm oder Zustandsautomaten), die für diese Aufgabe weitaus geeigneter sind als Use-Case-Diagramme. Mit Aktivitätsdiagrammen kann das Verhalten in einem Use-Case Schritt für Schritt in feinere, detailliertere Aktivitäten zerlegt werden. Darüber hinaus wird mit Zustandsautomaten ein hervorragendes Ausdrucksmittel zur Verfügung gestellt, um komplexe Zustandsabhängigkeiten transparent zu machen. Sequenz- und Kollaborationsdiagramme sind beste Hilfsmittel, um beispielhaft komplexe Situationen in den Abläufen zu modellieren, diese mit Anwendern zu besprechen und so auch komplexe Sonderfälle lesbar abzuhandeln. Bei Echtzeitsystemen muss nicht nur darauf geachtet werden, dass das System auf die Wünsche der Systemumgebung reagiert, sondern auch, dass es dies im gegebenen zeitlichen Rahmen tut. Use-Case-Modelle sind ein hervorragendes Modell, wenn es um die Zuordnung von Zeitanforderungen zu UML-Modellen geht. Es gibt zwei Arten von Zeitanforderungen:

• Antwortzeiten und Frequenzen,
• Häufigkeit und Verteilung von Eingabesignalen.

Durch die strikte Blackbox-Betrachtung kann man den Use-Cases Antwortzeitverhalten zuordnen. Ein Akteur hat einen Wunsch an das System. Der Use-Case erledigt diesen Wunsch. Wenn der Akteur dafür einen Zeitrahmen vorgibt, sollte dieser genau diesem Use-Case zugeordnet werden. (z.B. durch einen eigenen Abschnitt in der Use-Case-Spezifikation). Auch die zweite Kategorie hat in der Use-Case-Modellierung ein mögliches Zuhause: Gibt es Zeitanforderungen an die Eingangsgrößen, lassen sich diese bei der Eingabespezifikation in der Use-Case-Beschreibung anhängen.

*Chris Rupp ist Geschäftsführerin der SOPHIST GROUP. Durch ihre Publikationen und Vorträge liefert sie immer wieder wichtige Impulse für die Bereiche Requirements Engineering und Objektorientierung. Kontakt: Chris.Rupp@sophist.de

*Carsten Pflug ist Trainer und Berater der SOPHIST GmbH und hat sich insbesondere auf die Objektorientierung mit der UML spezialisiert. Dabei vermittelt er in verschiedenen Projekten Knowhow in den Fachgebieten objektorientierte Analyse und Design. Kontakt: carsten.pflug@sophist.de

(ID:272796)