Wenn man in die modellbasierte Entwicklung (MBSE) einsteigt, steht man vor der Herausforderung zu entscheiden, welche Art der Modellierung denn die richtige ist. Dabei gibt es eine ganze Reihe von Diagrammen, Modellelementen und Standards, die man möglicherweise einsetzen könnte. Aber welche braucht man denn nun wirklich?

Ich habe in den über 25 Jahren, in denen ich inzwischen Modelle und Modellierung einsetze, gelernt was wirklich wichtig ist. Dies möchte ich in diesem Artikel zunächst einmal im Überblick beschreiben und ich plane in zukünftigen Artikeln dann die einzelnen Modellarten im Detail zu erklären.

Standards der modellbasierten Entwicklung

In der Welt von MBSE hat man es oft mit standardisierten Modellierungssprachen und Modellierungselementen zu tun. Die Nutzung von Standards erleichtert das Verständnis von Modellen, da viele Anwender mit der Art der Darstellung durch Schulung und (Selbst-)Studium bereits vertraut sind. Viele der heute gängigen Standards werden durch die Object Management Group (OMG) und deren Mitglieder standardisiert und weiterentwickelt.

Die UML

Schaut man sich nach Möglichkeiten der System- und Softwaremodellierung um, stößt man unweigerlich auf die Unified Modeling Language (UML). Die UML ist eine Sammlung von standardisierten Modellelementen und Diagrammen, die dazu gedacht sind Dinge rund um die objektorientierte Softwareentwicklung zu modellieren, bzw. zu visualisieren. Sie ist ein Standard der OMG. Das diese Sprache „Unified“, also vereinheitlichte Modellierungssprache heißt kommt daher, dass zum Beginn der UML – Ender der 1990er Jahre – drei konkurrierende Methoden zur Beschreibung objektorientierter Software als Veröffentlichungen existierten. Mit der UML hat man sich auf eine gemeinsame Darstellung geeinigt und die konkurrierenden Methoden und Darstellungen durch eine vereinheitlichte Form abgelöst.

Struktur und Verhalten

Die UML in der aktuellen Version 2.x kennt 13 verschiedene Diagrammarten und dazu gehörende Modellelemente und Verbindungen (Konnektoren) zwischen diesen. Dabei wird zwischen zwei Arten von Modellierung unterschieden: Modellierung von Struktur, also statischen Aspekten von Software, und Modellierung von Verhalten, also dynamischen Aspekten von Software.

Diese Art von Unterscheidung zwischen Struktur und Verhalten zieht sich übrigens durch alle Modellierungssprachen – nicht nur die UML – und kann daher als ein grundlegendes Prinzip im Aufbau von Modellen bezeichnet werden.

Die SysML

Die Systems Modeling Language (SysML) ist eine Modellierungssprache zur Modellierung von mechatronischen Systemen. Zumindest die Version 1.x basieren auf der UML und übernehmen viele Dinge daraus, lassen aber auch einige Sachen weg und erweitern an einigen wenigen Stellen die Notation. SysML ist ebenfalls ein Standard der OMG.

SysML ist eine domänenspezifische Sprache, das heißt sie adressiert einen bestimmten Einsatzzweck – nämlich den des modellbasierten Systems Engineering. Beim Systems Engineering geht es darum ein System, bestehend aus Elektronik, Mechanik und Software ganzheitlich zu erfassen und zu modellieren. Diesen Anspruch hat die SysML. Im Gegensatz dazu wurde die UML entwickelt, um vor allem die Aspekte der objektorientierten Softwareentwicklung abzubilden und dies auch in etwas genereller Natur. Elektronik und Mechanik sind hier außen vorgelassen.

SysML deckt also vom Systemkontext her einen größeren Bereich als die UML ab, dafür konzentriert sie sich aber mehr auf die Systemaspekte und lässt es unter Umständen nicht zu Softwareaspekte so detailreich zu modellieren, wie es die UML kann.

In der Praxis kommt es daher durchaus vor, dass man in einem Modell sowohl Techniken der SysML als auch der UML kombiniert einsetzt. Da beide Sprachen dieselben Grundlagen haben, lässt sich dies mit heutigen Modellierungswerkzeugen auch ohne Medienbruch realisieren.

Auch SysML unterscheidet zwischen Struktur- und Verhaltensmodellierung und ist mit 9 Diagrammarten schlanker definiert als die UML mit 13.

BPMN

Business Process Model and Notation (BPMN) ist ebenfalls ein Standard der OMG und wird dazu verwendet Geschäftsprozesse zu modellieren und grafisch darzustellen.

Bei der Geschäftsprozessmodellierung kommen vor allem Modelle und Elemente zum Einsatz, die dynamische Aspekte zeigen. Dies sind Abläufe von Geschäftsprozessen: Welche Schritte sind notwendig, um ein bestimmtes Ziel zu erreichen, was sind die Eingaben, was sind die Ausgaben und wer macht es.

Im Grunde genommen sind die meisten Modelle von BPMN etwas spezialisiere Aktivitätsdiagramme wie man sie auch aus der UML und SysML kennt, mit denen man Geschäftsprozesse, also Aktivitäten, Rollen und Arbeitsprodukte grafisch in Zusammenhänge setzt. Wer UML und SysML (noch) nicht kennt hat vielleicht schon mal etwas von „Flow Charts“ gehört. Das ist genau die Grundlage der Aktivitätsmodellierung allgemein und noch älter als die UML.

FMC

Die Fundamental Modeling Concepts (FMC) sind ebenfalls eine Möglichkeit zur Modellierung von Systemen mit intensiven Softwareaspekten. FMC ist um einiges älter als UML und geht zurück auf die Arbeiten von Prof. Siegfried Wendt, der unter anderem den Lehrstuhl für „Alternative Softwaretechnik“ am Hasso-Plattner-Institut in Potsdam innehatte. Er und sein Team entwickelten bereits in den 1970er Jahren Möglichkeiten der grafischen Modellierung von System- und Softwareaspekten. Obwohl hier sehr gute Ansätze entwickelt wurden, hat sich FMC nicht breit durchgesetzt – was vermutlich auch am besseren Marketing der OMG und der Leute rund um die UML lag und liegt.

FMC steht in bestimmten Bereichen in Konkurrenz zur UML oder aus SysML. Aber auch hier gilt das schon oben bei SysML gesagte: Man kann auch verschiedene Modellierungssprachen kombiniert einsetzen. Außerdem gilt bei Modellierungssprachen das Gleiche wie bei natürlichen Sprachen: Man kann ein Modell, welches vom Inhalt her in FMC das gleiche ausdrückt wie ein konkurrierendes UML-Diagramm beides ineinander transferieren, bzw. übersetzen. Genauso wie man einen deutschen Text in einen inhaltlich gleichen englischen Text übersetzen kann, ohne den Inhalt zu verändern.

FMC ist kein Standard der OMG, sondern ist wie gesagt durch die wissenschaftlichen Arbeiten von Prof. Wendt und seinen Mitarbeitern veröffentlicht und im Buch „Fundamental Modeling Concepts – Effective Communication of IT Systems“ detailliert beschrieben.

Die Qual der Wahl

Wenn Sie bis hier gelesen und vielleicht mitgezählt haben, dann steht mit den oben beschriebenen Standards nun folgendes zur Verfügung:

• 13 UML-Diagrammarten
• 9 SysML-Diagrammarten
• 1-2 BPMN-Diagrammarten
• 3 FMC-Diagrammarten

Also zusammen fast 30 verschiedene Diagramme und Modellelemente aus denen man wählen könnte.

Braucht man die aber wirklich alle?

Und hier kommt meine Antwort aus über 25 Jahren Praxis: Nein! Denn viele Dinge überschneiden sich inhaltlich (semantisch). Die Art der Darstellung (Syntax) unterscheidet sich mehr oder weniger, die Art der Inhalte aber nicht!

In Abbildung 1 kann man die inhaltlichen Überschneidungen der verschiedenen Standards sehen. Es braucht etwas Erfahrung, um diese semantischen Gleichheiten zu erkennen – da sich die Modellierungselemente manchmal deutlich voneinander unterscheiden und trotzdem dasselbe bedeuten.

Am Ende des Tages kann man einen bestimmten Aspekt mit dieser oder jener Notation darstellen bzw. modellieren. Es gibt jedoch Erfahrungswerte, die zeigen, das eine Notation schneller verstanden wird als eine andere. Dies liegt vor allem daran, dass bestimmte grafische Darstellungen zum Beispiel dem Betrachter bereits aus der Erfahrung heraus vertraut sind und daher die Bedeutung eines Diagramms nicht erst erklärt werden muss. Welche das sind, muss man am besten durch empirische Beobachtung herausfinden, wenn man jemand ein unbekanntes Diagramm oder Modell zu ersten Mal zeigt.

In den letzten Jahrzehnten haben sich bestimmte Darstellungen durchgesetzt und viele Anwender eines Modells sind durch Beruf, Studium oder Weiterbildung mit dieser Art der Darstellung vertraut.

Daher sollte man, wenn man modelliert auf solche Modellelemente und Darstellungen bauen, um den Anlernaufwand für Anwender möglichst klein zu halten!

Grundlegende Modelle die man in der Praxis immer wieder braucht

Nach der eher theoretischen Einleitung oben möchte ich Ihnen nun beschreiben, welche Art von Modellen ich in meiner Berufspraxis immer wieder eingesetzt habe, einsetze oder einsetzen werde, um Aspekte meiner Arbeit zu spezifizieren, zu visualisieren oder zu dokumentieren.

Bei jeder Art der Modellierung muss immer hinterfragt werden „Was will ich mit dem Modell erreichen?“ und „Für wen bringt das Modell einen Nutzen?“. Ein Modell, welches erstellt wird, nur weil die Modellierungssprache die Möglichkeit bietet es zu erstellen oder das man erstellt, weil man irgendwo gelesen hat, dass man das müsste, das Modell aber von niemandem genutzt wird und man auch selbst als Ersteller keinen Mehrwert daraus zieht nützt keinem was und ist unnötige Arbeitszeitverschwendung.

Es muss also darum gehen, die „richtigen“ Modelle zu erstellen, die ein Projekt oder eine Organisation wirklich auch voranbringen und einen Nutzen haben. Oftmals helfen Modelle dabei Kommunikations- und Verständnisprobleme zu lösen. Die Generierung von zum Beispiel ausführbarem Quellcode für Software – was oftmals mit modellbasierter Entwicklung in Verbindung gebracht wird – spielt eigentlich in der Praxis eine viel geringere Rolle als die Modelle als Kommunikationsmittel einzusetzen. Durch vermiedene Missverständnisse können die Modelle aber dazu beitragen, dass Projekte flüssiger und mit weniger notwendigen Korrekturschleifen ablaufen und somit Zeit und Geld sparen.

Datenmodellierung

Daten sind das Fundament oder die Grundlage ein jeder Software. Es geht eigentlich immer darum irgendwelche Daten einzulesen, diese zu verändern oder zu verarbeiten und dann neue Daten daraus zu erzeugen und ggfs. wieder zu speichern.

Man spricht in der Softwareentwicklung daher auch von einem „Datenmodell“ welches man braucht, um die Daten einer bestimmten Softwareanwendung im Speicher zu halten, damit die Software die Daten verarbeiten kann.

Im Rahmen von Digitalisierung geht es auch darum, Dinge aus der realen Welt einem Rechnersystem zugänglich zu machen. Daten die man vorher zum Beispiel auf Papier schriftlich notiert hat (analoge Daten), sollen nun digital in rechnerverarbeitbarer Form als Dateien oder Datenbanken vorliegen, damit diese automatisiert weiterverarbeitet werden können.

Die Objektorientierung hat hier mit der objektorientierten Analyse (OOA) und dem objektorientierten Design (OOD) um die Jahrtausendwende einen großen Beitrag geleistet, wie man analoge Daten in digitale Datenmodelle überführen kann.

Solche Datenmodelle sind am Ende Klassen der Objektorientierung, die Daten mit Hilfe von Eigenschaften (UML-Attribute) und bestimmten Verbindungen zu anderen Klassen (z.B. Vererbung, Komposition oder Assoziation) modellieren.

Daraus ergibt sich die Nutzung der UML-Klassendiagramme als logischer Schritt und Entscheidung für die visuelle Darstellung von Datenmodellen.

Andere Notationen, wie sie zum Beispiel FMC vorschlägt, kommen aufgrund des geringen Bekanntheitsgrades dieser Darstellung und dem damit verbundenen Schulungsaufwand nicht in Betracht.

Abbildung 2 zeigt ein kleines Beispiel für ein Datenmodell einer Adressverwaltung. Zur Anwendung kommt das UML-Klassendiagramm.

Strukturmodellierung

Wenn man etwas entwickelt und dafür ein Modell erstellt oder aber für ein schon bestehendes System im Nachhinein noch eine visuelle Dokumentation in Form eines Modells erstellt, dann besteht ein System typischerweise aus mehreren Teilen.

Diese Teile – oder man spricht auch von Systemkomponenten – arbeiten zusammen, um am Ende eine bestimmte Aufgabe zu erfüllen als Gesamtsystem. Man braucht also ein Modell, dass die verschiedenen Komponenten des Systems und deren Zusammenspiel darstellt oder auch eine Darstellung, dass eine Komponente ein Teil einer anderen Komponente ist.

Ein solches Modell nennt man ein Strukturmodell des Systems oder auch ein Systemarchitekturmodell. Systemarchitekturmodellierung gehört in den Bereich der Strukturmodelle und der Darstellung der statischen Systemaspekte (Struktur vs. Verhalten).

Der Kern der Systemarchitekturmodellierung liegt dabei darauf 1. die Komponenten des Systems zu visualisieren, 2. die Schnittstellen der Komponenten darzustellen und 3. Verbindungen zwischen diesen Schnittstellen.

Die oben genannten Modellierungssprachen bzw. -standards bieten eine Reihe verschiedener Elemente und Diagramme an, die man nutzen könnte, um eine solche Systemarchitektur darzustellen. Dazu gehören:

• UML-Komponentendiagramme
• UML-Verteilungsdiagramme (deployment diagram)
• UML-Objektdiagramme
• UML-Kompositionsstrukturdiagramme
• SysML-Interne Blockdiagramme
• FMC-Blockdiagramme
• Evtl. auch UML-Klassen & SysML-Blockdefinitionsdiagramme

Allein von der Aufzählung kann einem fast schon schwindelig werden. Im Prinzip kann man die Architekturaspekte mit jedem Diagramm und seinen Elementen ausdrücken, man sollte sich aber für eines entscheiden!

Nachdem ich selbst lange Jahre die SysML und das SysML-Interne Blockdiagramm verwendet und propagiert habe, bin ich allerdings vor ein paar Jahren davon abgekommen und nutze heute die Notation der FMC-Blockdiagramme in einer von mir leicht modifizierten Form (FMC4SE). Dazu gibt es auch einen eigenen Blog-Beitrag: Systemmodellierung – einfach und intuitiv.

Der Grund von SysML an dieser Stelle weg zu gehen ist, dass ich beobachten konnte, wie selbst erfahrene Modellierer und Trainer, wenn Systeme diskutiert wurden, am Whiteboard in einer Besprechung keine UML- oder SysML-Symbole nutzen, sondern ganz einfache rechteckige Kästen zur Darstellung von Systemkomponenten.

Hier entspricht die FMC-Notation fast 1:1 dieser Art der Darstellung und bietet die intuitivste Art des Einstiegs in ein solches Modell. Ich habe dies auch empirisch immer wieder bestätigt bekommen in dem ich beobachten konnte, wie Modelle dieser Art ohne jede Erklärung von Personen, die sie vorher nicht kannten, intuitiv benutzt wurden.

Daher ist meine Empfehlung für die Modellierung von Systemarchitektur die FMC4SE-Notation einzusetzen!

In Abbildung 3 ist ein Beispiel einer solchen Systemarchitekturmodellierung zu sehen. Dargestellt ist ein moderner Laptop-Arbeitsplatz mit Peripheriegeräten. Als Notation kommt hier FMC4SE zum Einsatz. Man sieht die Komponenten, deren Schnittstellen und die Verbindung zwischen diesen Schnittstellen.

Wann immer oben von Systemarchitektur die Rede ist, dann ist dort auch immer Softwarearchitektur-Modellierung inbegriffen. Sofern die Systemgrenze nämlich nur eine Softwaresystemgrenze ist, dann besteht das Gesamtsystem eben dann nur rein aus Softwarekomponenten. Die Möglichkeiten der Modellierung lassen sich hier aber genauso anwenden wie bei Systemen mit zusätzlichen mechanischen oder elektronischen Komponenten (mechatronischen Systemen).

Anwendungsfallmodellierung

Wenn man ein System, ein Produkt oder eine Software neu konzipiert und dies mit mehreren Personen (Stakeholdern) gemeinsam tut oder zumindest diskutiert, ist einer der ersten Schritte ein gemeinsames Bild herzustellen über die Funktionalitäten, die das System bieten soll. Genau hierbei haben sich Anwendungsfälle (engl. Use Cases) und das Anwendungsfalldiagramm als sehr nützlich erwiesen.  

In solch einem Diagramm werden drei Dinge dargestellt:

1. Das System welches entwickelt werden wird als rechteckiger Kasten (ein so genanntes Boundary-Element) dargestellt
2. Die Anwendungsfälle als elliptische Elemente mit deren Namen innen drin. Der Name ist dabei so gewählt, dass eine aktive Funktionalität des Systems benannt wird und besteht aus einem Substantiv und einem Verb. Beispielsweise: „Person suchen“, „Person anlegen“ oder auch „Benutzer anmelden“
3. Menschliche und technische Akteure, die die Anwendungsfälle typischerweise durchführen (dürfen) werden dargestellt als Strichmännchen oder rechteckiges Systemelement und dann mit einer durchgezogenen Linie mit den ihnen zugeordneten Anwendungsfällen verbunden.

Abbildung 4 zeigt ein Beispiel eines einfachen Anwendungsfalldiagramms für eine Adressverwaltung. Wichtig zu erwähnen ist, dass ein solches Diagramm durchaus noch Raum für Interpretation bietet. Es zeigt zwar erstmal auf, welche größeren Funktionalitäten das System bieten soll, aber es wird trotzdem nicht daraus ersichtlich, wie diese Funktionalitäten konkret realisiert werden sollen. Jede Person, die ein solches Diagramm liest, hat irgendein Bild im Kopf, das sich durch persönliche Erfahrungen, Wissen und Denkweisen von dem Bild einer anderen Personen, die das Modell anschaut durchaus stark unterscheiden kann.

Man darf nicht zu viel in solch ein Diagramm reininterpretieren. Es bleibt, was es ist: Im Prinzip eine Auflistung der Anwendungsfälle mit deren Namen. Nicht mehr und nicht weniger.

Um unterschiedliche Interpretationen in den Köpfen der Nutzer auszuräumen und das Systemverständnis auf eine gemeinsame Basis zu stellen sind weitere textuelle oder modellbasierte Beschreibungen notwendig. Für einen ersten gemeinsamen Überblick im Entwicklungsteam reicht ein solches Diagramm aber aus und es ist auch sehr hilfreich solch ein Diagramm ausgedruckt an die Wand des Büros zu hängen, damit man die groben Ziele der Systementwicklung stets vor Augen hat.

Ich persönlich verwende keine Include– oder Extends-Beziehungen wie sie die Anwendungsfallmodellierung gemäß der UML-Spezifikation auch vorsieht, da sich in der Praxis gezeigt hat, dass man dadurch mehr Verwirrung stiftet als Klarheit schafft. Hier gilt das Einfachheitsprinzip KISS = Keep It Simple and Stupid oder anders ausgedrückt „Immer nur so komplex wie nötig und so einfach wie möglich“.

Verhaltensmodellierung

Für die Modellierung von Systemverhalten haben sich für mich drei Diagramm- bzw. Modellierungsarten als praxisrelevant erwiesen:

• Aktivitätsmodellierung
• Sequenzdiagramme
• Zustandsmodelle

Diese Verhaltensdiagramme kamen vorwiegend immer dann zum Einsatz, wenn es darum ging das genauere Verhalten eines Anwendungsfalls formaler zu beschreiben mit Hilfe eines weiteren grafischen Modells.

Anwendungsfälle werden oftmals auch textuell genauer spezifiziert. Sei es mit textuellen Beschreibungen eines strukturieren Szenarios oder auch durch textuelle Anforderungen.

Will man jedoch auch Modelle verwenden, um Anwendungsfälle genauer zu beschreiben, dann bietet sich zuallererst die Aktivitätsmodellierung an. Hier hat man wiederum die Wahl zwischen UML/SysML-Aktivitätsdiagrammen, die bis auf wenige Dinge identisch sind, oder dem Einsatz von BPMN-Diagrammen.

BPMN-Diagramme

Ich persönlich finde die BPMN-Diagramme inzwischen etwas ansprechender und nutze diese auch gerne, um Anwendungsfälle im Detail zu modellieren. Inhaltlich kann man aber beide Möglichkeiten verwenden.

Abbildung 5 zeigt ein Beispiel eines BPMN-Diagramms, das den Ablauf des Anwendungsfalls „Person suchen“ genauer spezifiziert. Hier ist insbesondere die Interaktion zwischen dem Benutzer und dem zu entwickelnden System gut zu sehen.

Papier-Prototypen helfen beim Entwurf der Benutzerschnittstelle

Natürlich gibt es auch mit dem obigen BPMN-Diagramm noch Interpretationsspielraum, wie zum Beispiel die Benutzeroberfläche der Suchfunktion genau aussehen soll. Hier können UI-Mockups und so genannte „Papier-Prototypen“ helfen dies genauer zu definieren und die Spezifikation zu ergänzen. Man kann so auch deutlich schneller Benutzeroberflächen skizzieren und entwerfen, als zum Beispiel Modelle von Benutzeroberflächen in einem Modellierungswerkzeug zu erstellen. Durch die Nutzung von „elektronischem Papier“ und einem Stift, mit dem man direkt auf das Display des Laptops zeichnen kann, können zudem auch schnell schon digital nutzbare Bilder entstehen (Abbildung 6).

Solche Zeichnungen und Skizzen sind auch Modelle, allerdings abseits des Sprachumfanges von SysML, UML und Co., die helfen ein gemeinsames Verständnis für das System zu schaffen und die Kommunikation im Team zu verbessern. Sie sind sehr hilfreich in der Entwurfsphase einer Anwendungssoftware – und vor allem kostet deren Erstellung fast keinen Aufwand und kaum Zeit.

Einsatz von Sequenzdiagrammen

Sequenzdiagramme stellen Abläufe und Interaktionen in einem zeitlichen Verlauf dar. Dieses Diagramm hat eine Besonderheit, denn es hat als einziges eine bestimmte Leserichtung. Eine Zeitachse geht von oben nach unten, und man muss das Diagramm dann entsprechend lesen – während man bei den anderen Diagrammarten die Anordnung der Elemente frei wählen kann.

Sequenzdiagramme haben sich für mich auch oft als hilfreich erwiesen, dort wo es darum geht bestimmte Funktionalitäten genauer zu spezifizieren – insbesondere, wo mehrere Systeme oder Systemkomponenten miteinander interagieren, kann man dies mit einem Sequenzdiagramm gut veranschaulichen.

Heute werden zum Beispiel viele Systeme in Microservice-Architektur realisiert, bei der viele kleine einzelne Softwaredienste miteinander interagieren. Gerade dort kann man mit Hilfe eines Sequenzdiagramms gut das Zusammenspiel darstellen.

Abbildung 7 zeigt ein kleines Beispiel eines Sequenzdiagramms, welches die Kommunikation zwischen einem Web Client – z.B. einem Browser – und einem Webserver abbildet.

Zustandsdiagramme

Die Zustandsdiagramme der UML und SysML basieren auf dem Ansatz der „State Charts“, der auf David Harel zurück geht. Man kann also damit hierarchische Zustandsautomaten modellieren.

In meiner Modellierungspraxis habe ich diese Diagramme tatsächlich sehr viel weniger gebraucht als zum Beispiel Aktivitätsdiagramme. Besonders in der Entwicklung hardwarenaher Software im Embedded-Bereich spielen diese eine größere Rolle, da man damit, mit etwas ins Modell gelegten Mehraufwand, auch direkt Softwarecode aus solch einem Modell generieren kann. Vielleicht beschreibe ich sowas irgendwann nochmal in einem separaten Beitrag.

Wo Zustandsautomaten aber auch ihre Berechtigung haben, ist in der Definition von Zuständen für Statuswerte im Rahmen einer Prozessdefinition. Beispielsweise möchte man definieren welche Zustände ein Arbeitsprodukt (z.B. ein Dokument) im Arbeitsablauf haben kann. Dazu kann man das Zustandsdiagramm verwenden, um dies zu spezifizieren oder zu dokumentieren.

Abbildung 8 zeigt das Zustandsdiagramm für den Arbeitsablauf (workflow) einer Arbeitsaufgabe (task) wie er zum Beispiel in einem Aufgabenverwaltungswerkzeug hinterlegt sein kann.

Schlussbemerkungen

In diesem Beitrag habe ich versucht, basierend auf meiner langjährigen Erfahrung im Einsatz von Modellen in der System- und Softwareentwicklung, eine Übersicht zu geben, welche Modellelemente und Diagramme wirklich hilfreich sind in der täglichen Praxis. Man sieht, dass die Modellierungssprachen und -standards hier mehr bereitstellen als das, was man als Software- und Systemingenieur wirklich braucht. Natürlich darf und kann man auch mehr verwenden als die dargestellten Dinge und es hängt sicher auch vom Bereich ab in dem man tätig ist, aber es zeigt sich immer wieder: Je einfacher und intuitiver man Modelle gestaltet, erhält man eine breitere Akzeptanz und Nutzung der Modelle und ihrer Daten durch die Nutzerinnen und Nutzer.

Manche der obigen Beispiele sind auf Deutsch gehalten, da der Artikel selbst in Deutsch formuliert ist. Normalerweise würde ich in einem Unternehmens- oder Projektumfeld die Modelle in englischer Sprache aufbauen. Leider geben es die Werkzeuge und Modellierungsstandards bis heute nicht her, dass man Inhalte mehrsprachig hinterlegen kann, was ich schon des Öfteren hätte brauchen können.

Ich plane, in weiteren Artikeln die hier einzeln vorgestellten Dinge mit weiteren Beispielen zu vertiefen und damit auch Hilfestellung für die praktische Erstellung und Nutzung solcher Modelle zu geben.