Im vorherigen Teil unserer Blogserie zu unserem Meta-Modell für Anforderungen haben wir die Funktionalitäten eines Systems aus Kompositions- und Dekompositionssicht betrachtet. In diesem Artikel möchten wir Ihnen zeigen, wie die Funktionalitäten des Systems und das Informationsmodell der Fachdomäne in Verbindung stehen.
Dazu betrachten wir das Diagramm in Abbildung 1.
Abbildung 1 – Verbindung von Systemfunktionen und dem Informationsmodell der Fachdomäne
Das Diagramm zeigt die Verbindung zwischen den in unserem vorherigen Teil dieser Blogserie vorgestellten Services und dem Informationsmodell der betrachteten Systemdomäne. Ein „Function Object“, also Teil der Service-Definition oder die Eingabe bzw. das Ergebnis eines „Service“, ist entweder ein Objekt aus der Domäne des Systems („Domain Object“) oder ist eine Eigenschaft eines dieser Objekte („Domain Object Attribut“). Einem solchen Domänen-Objekt können beliebig viele Eigenschaften zugeordnet werden. Betrachten wir wieder unser Smartphone als Beispiel. Ein „Kontakt“ aus dem Adressbuch des Smartphone ist ein solches „Domain Object“ und besitzt die Eigenschaften: „Vorname“, „Nachname“, „Telefonnummer“ und „E-Mail Adresse“.
Außerdem können „Domain Objects“ Beziehungen zu anderen „Domain Objects“ haben. Dafür verbindet das „Relation“ Element eine Beziehungsquelle und ein Beziehungsziel miteinander. Jedem dieser Beziehungsenden ist genau ein „Domain Object“ zugewiesen. Die „Relation“ selbst besitzt einen Typ (wie bspw. Generalisierung, Spezialisierung, Komposition usw.) und, je nach Typ der Relation, einen Namen. Zudem kann die Beziehung eine Richtung wie z. B. „Quelle-zu-Ziel“ oder „ungerichtet“ haben. Besonders bei Generalisierungen und Spezialisierung ist die Richtung entscheidend.
Als eingefleischter Modellierer oder aus unseren CPRE Foundation Level-Schulungen kennen Sie wahrscheinlich Multiplizitäten und Rollennamen aus UML-Klassendiagrammen. Unser vorgestelltes Meta-Modell für Anforderungen bietet die Möglichkeit, diese zusätzliche Semantik für Relationen in den Attributen „Cardinality“ und „Role Name“ an den Beziehungsenden mit zu erfassen.
Betrachten wir wieder unser Smartphone anhand des folgenden Auszuges aus dem Informationsmodell.
Abbildung 2 – Beziehungen zwischen Kontakt und Nachricht eines Smartphones
Der in Abbildung 2 definierte Rollenname „Empfänger“ erweitert die Semantik der Assoziation zwischen Nachricht und Kontakt. In unserem Beispiel bedeutet das, dass einer Nachricht mindestens ein Kontakt als Empfänger (1..*) der Nachricht zugeordnet sein muss. Allerdings muss ein Kontakt nicht zwingend als Empfänger (0..*) einer Nachricht fungieren.
Jedes „Domain Object Attribute“ sollte einen definierten Typ besitzen. Dabei wird zwischen „Primitive Type“, „Enumeration“ und „Data Type“ unterschieden. „Primitive Types“ kennen Sie vielleicht aus verschiedenen Programmiersprachen. Dazu zählen zum Beispiel „Integer“, „Decimal“ oder „Character“. „Enumerations“ entsprechen Aufzählungstypen, die aus Literalen bestehen. So kann man beispielsweise den Aufzählunstyp „Wochentag“ mit den Literalen „Montag“, „Dienstag“, …, „Sonntag“ definieren. „Data Types“ beschreiben zusammengesetzte Datentypen, die aus „Data Type Attributes“ bestehen. Ein Beispiel für einen solchen Datentyp ist ein „Datum“, das sich aus den „Data Type Attributes“ „Tag“, „Monat“ und „Jahr“ zusammensetzt. Ein „Data Type“ hat im Gegensatz zu „Domain Objects“ keine Beziehungen zu anderen „Domain Objects“.
Damit sind wir auch schon am Ende dieses Artikels angekommen. Wir haben Ihnen gezeigt, wie das Informationsmodell Ihres Systems und dessen Funktionalitäten in Verbindung stehen. Damit sind Sie gewappnet für die nächsten Diskussionen über die Begrifflichkeiten und Funktionen für Ihr System.
Im letzten Teil dieser Blogserie möchten wir Ihnen noch die dynamischen Aspekte von Systemfunktionen anhand unseres Meta-Modells vorstellen. Dazu gehören die Einflüsse der Services auf die Zustände von Objekten der Domäne sowie das Zusammenspiel der Services untereinander.
Stay Tuned!