Wie Sie es bereits auf unserem Blog lesen konnten, reiste unser Berater Alexander Rauh im Rahmen seiner Forschung in den Sonnenstaat Kalifornien und hat dort sein Meta-Modell für Anforderungen auf der SOSE 2017 (Service-Oriented System Engineering) vorgestellt. Nun möchten wir Ihnen dieses Meta-Modell etwas genauer erläutern und möchten Ihnen zeigen welche Informationen in Ihren Anforderungen stecken.
Das Meta-Modell, das wir Ihnen vorstellen möchten, zeigt Ihnen welche Informationen für eine vollständige Beschreibung von Funktionen eines Systems inklusive deren zugehörigen Qualitätsaspekte in Anforderungen abgebildet sein sollten. Durch möglichst vollständige Spezifikationen unterstützen Sie schließlich alle Disziplinen, die auf Ihren Anforderungen aufsetzen wie bspw. Architektur, Design, Implementierung sowie Qualitätssicherung durch Test und Validierung.
In diesem Teil der Blogserie, betrachten wir Funktionalitäten eines Systems aus Kompositions- und Dekompositionssicht. Dazu werfen wir zunächst einen Blick das Klassendiagramm in Abbildung 1.
Der Ausdruck „NamedElement“ in den Klassen „System under Consideration“, „Actor“, „Function“, und „Function Object“ bezeichnet, dass jedes dieser Elemente einen Namen als Attribut besitzt.
Das Kernstück dieses Meta-Modells bildet aber das „Service“ Element. Ein „Service“ beschreibt eine Funktionalität des betrachteden Systems unabhängig vom Abstraktionsgrad. Auf der einen Seite kann ein „Service“ zum Erreichen eines Ziels eines Akteurs (engl. Actor) beitragen und entspricht damit der Ebene der Use-Cases. Andererseits kann ein „Service“ aber auch die Realisierung eines anderen Services unterstützen wie beispielsweise ein einzelner Schritt während der Ausführung eines Use-Case. Akteure bezeichnen in diesem Fall sowohl Nachbarsysteme als auch Person, die eine bestimmte Rolle einnehmen und die die zur Verfügung gestellte Funktionalität nutzen.
Ein „Service“ wird von einer „Function“ und einem „Function Object“ definiert. Die „Function“ beschreibt den Prozess (dargestellt durch ein „gutes“ Vollverb [1]), der auf das „Function Object“, ein Objekt aus der Domäne des Systems, angewendet wird. Betrachtet man beispielsweise den Use-Case „Kontakt erstellen“ eines Smartphones, so wäre „Kontakt“ das Objekt der Domäne, auf das der Prozess „erstellen“ angewendet wird. Der Smartphone-Nutzer ist in diesem Fall der Akteur, der die Funktionalität nutzt. Wie in der obigen Abbildung ersichtlich können „Function Objects“ zudem als Eingaben oder als Ergebnis von Services dienen.
Um die Funktionalität des zu betrachtenden Systems zu verfeinern und zu strukturieren, gibt es zwei Spezialisierungen von „Services“. Einerseits gibt es „Simple Services“, welche nicht weiter zerlegt werden können. „Simple Services“ sind damit atomar und entsprechen der niedrigsten Ebene in einer Spezifikation. Andererseits existiert „Complex Services“, die in weitere Services zerlegt werden können. Ein Use-Case eines Systems entspricht dementsprechend einem solchen Complex Service. Speziell im Kontext von cyber-physischen Systemen ist eine Dekomposition von Funktionalitäten in kleinere Teile notwendig. Doch nehmen wir unser deutlich einfacheres Beispiel „Kontakt erstellen“ unseres Smartphones von weiter oben für eine solche Dekomposition her. Die Schritte „Name eingeben“, „Telefonnummer eingeben“ und „Kontakt speichern“ sind zwingend erforderlich, um einen Kontakt zu erfolgreich erstellen. Optional dagegen sind beispielsweise die Schritte „E-Mail Adresse eingeben“ und „Bild hinzufügen“. All diese Schritte entsprechen dem Service „Kontakt erstellen“ untergeordnete Services. Je nach der gewünschten Detaillierung kann auch jeder einzelne Teilschritt in weitere Services zerlegt werden.
Der letzte Aspekt, den wir Ihnen in diesem Artikel vorstellen, sind die nicht-funktionalen Anteile eines Systems. Im Meta-Modell wird zwischen der Qualität eines einzelnen Service („Quality of Service“) sowie der Qualität des Systems als Ganzes („Quality of System“) unterschieden. Beide Qualitätsklassen können in Wechselwirkung stehen und sich gegenseitig beeinflussen. Nehmen wir z.B. den Qualitätsaspekt der Verfügbarkeit: Ein Service soll 24 Stunden am Tag, 7 Tage in der Woche verfügbar sein so muss das realisierende System selbst auch über diesen Zeitraum verfügbar sein. Die Unterteilung von Qualitätsanforderungen finden Sie in Kapitel 12 in unserem Buch „Requirements-Engineering und –Management“.
Wir hoffen, dass wir Ihnen einen ersten Einblick in unser Meta-Modell für Anforderungen geben konnten und hoffen, dass Sie auch unseren nächsten Artikel dieser Serie verfolgen. Dann werden wir Ihnen die Verbindung zwischen den Funktionalitäten des Systems und dem Informationsmodell der Fachdomäne vorstellen – Sie können also gespannt sein!
Bis dahin wünschen wir Ihnen alles Gute!
Ihre SOPHISTen
[1] Mehr Informationen zu Prozesswörtern finden Sie unter den folgenden Link:
Prozesswörter eindeutig und vollständig spezifizieren (Teil 1): https://blog.sophist.de/2017/01/18/prozesswoerter-eindeutig-und-vollstaendig-spezifizieren-teil-1/
Prozesswörer eindeutig und vollständig spezifizieren (Teil 2): https://blog.sophist.de/2017/03/01/prozesswoerter-eindeutig-und-vollstaendig-spezifizieren-teil-2/
25.000 Kilometer über das Meer: https://blog.sophist.de/2017/05/17/25-000-kilometer-ueber-das-meer/