|
|
| Zeile 288: |
Zeile 288: |
|
| |
|
| <span id="_Toc408237715" class="anchor"></span>Abbildung 66 – BPMN Beispiel Kaffeeküche | | <span id="_Toc408237715" class="anchor"></span>Abbildung 66 – BPMN Beispiel Kaffeeküche |
|
| |
| <span id="objektorientierte-modelle"></span>
| |
| = Objektorientierte Modelle =
| |
|
| |
| Die Grundlagen der objektorientierten Programmierung waren bereits Inhalt der Lehrveranstaltung „Einführung in die Programmierung mit C++“ und werden hier daher nicht mehr im Detail beschrieben. Nachfolgend werden die Grundlagen der objektorientierten Modellierung und die konkrete Anwendung durch die Unified Modeling Language (UML) genauer erläutert. Weiter werden die unterschiedlichen UML Modelle angeführt, welche ebenfalls zur Modellierung von Daten-, Prozess-, Ablauf- und Geschäftsmodellen eingesetzt werden können.
| |
|
| |
| <span id="grundlagen-der-objektorientierten-modellierung"></span>
| |
| == Grundlagen der objektorientierten Modellierung ==
| |
|
| |
| Bei der objektorientierten Modellierung werden Daten und Funktionen in Objekten abgebildet. Dabei werden alle Modellelemente einem oder mehreren Objekten zugeordnet.
| |
|
| |
| Bei der objektorientierten Modellierung werden die realen Objekte abstrahiert und dabei weiterhin als Objekte betrachtet. So wird beispielsweise ein ''Kunde'' als Objekt mit den Attributen ''Name'', ''E-Mail'' und ''Kundennummer'' abgebildet. Die grundlegenden Gliederungen der Objekte sind daher auch mit denen der ER-Datenmodelle aus Lektion 2.1 vergleichbar.
| |
|
| |
| Zusätzlich zu Daten, werden einem Objekt auch Funktionen und Methoden zugeordnet. Durch sie kann es mit der Außenwelt interagieren. So kann Beispielsweise bei einem Objekt ''Auto'' eine Funktion ''„bremse aktivieren''“ existieren, die sich um das Einleiten einer Bremsung kümmert.
| |
|
| |
| <span id="klassen-objekte-und-vererbung"></span>
| |
| === Klassen, Objekte und Vererbung ===
| |
|
| |
| Die Definition des Aufbaues und der Struktur eines Objektes wird als '''Klasse''' bezeichnet. Ein '''Objekt''' ist eine konkrete Repräsentation einer Klasse, welche selbst eine eigene Identität innerhalb des Programmes zur Laufzeit hat. Das Ausführen von Objekt-Methoden und die Änderung von Objekt-Variablen hat damit eine Auswirkung auf das konkrete Objekt, nicht aber auf die Klasse und nicht auf die übrigen Objekte der Klasse. Bei einem Objekt als Repräsentation einer Klasse spricht man von einer '''Instanz''' und bei ihren Variablen von '''Instanz-Variablen''', da ihr Inhalt nur für diese eine Instanz der Klasse gültig ist.
| |
|
| |
| Eine Klasse gibt es daher immer nur einmal, da es sich dabei um die Definition möglicher Objekte handelt. Zu einer Klasse kann es beliebig viele Objekte geben.
| |
|
| |
| Ein Beispiel für eine Klasse mit dazugehörigen Objekten ist in Abbildung 67 dargestellt. Es handelt sich dabei um die Klasse ''Kunde'', welche den Aufbau der Kundenobjekte definiert. Davon existieren zwei Instanzen, welche nun konkrete Kunden-Objekte repräsentieren.
| |
|
| |
| Jedes der beiden ''Kunden''-Objekte hat eigene Daten. Eine Änderung der Daten eines Kunden hat weder Auswirkung auf die anderen ''Kunden''-Objekte, noch auf die Klasse.
| |
|
| |
| Die verwendete Darstellform der Abbildungen ist das UML Klassendiagramm, welches später, in Abschnitt 5.4, genauer beschrieben wird.
| |
|
| |
| <span id="_Ref406415468" class="anchor"></span>Abbildung 67 – Klasse mit instanziierten Objekten
| |
|
| |
| Bei der '''Vererbung''' handelt es sich um einen der wesentlichsten Teile der Objektorientierung. Es handelt sich dabei um die Möglichkeit einzelne Klassen, und damit ihre Objekte, zu gliedern und zu konkretisieren oder in die andre Richtung weiter zu abstrahieren. Soll beispielsweise die Klasse ''Kunde'' aus Abbildung 67 weiter konkretisiert werden um zwischen normalen ''Kunden'' und ''Geschäftskunden'' zu unterscheiden, könnte diese neue Klasse mittels Vererbung von der Klasse Kunde '''abgeleitet''' werden. Sie erbt damit alle Variablen und Methoden der Klasse ''Kunde'' und ergänzt diese um weitere, für den Zweck der neuen Klasse konkretere, Variablen. Da die Klasseneigenschaften immer von einer Klasse zur nächsten weitervererbt werden, spricht man in diesem Zusammenhang oft von einer '''Mutterklasse''' und '''Tochterklasse'''. Ein entsprechendes Beispiel findet sich in Abbildung 68. Dabei wurde die neue Klasse ''Geschäftskunde'' um eine ''Umsatzsteuer-Identifikationsnummer'' und einen ''Firmennamen'' erweitert. Sie erbt dabei alle Eigenschaften ihrer Mutterklasse und kann diese wiederum selbst verwenden.
| |
|
| |
| <span id="_Ref406416460" class="anchor"></span>Abbildung 68 – Klasse mit Vererbung
| |
|
| |
| Eine Klasse kann zusätzlich zu Variablen auch '''Methoden''' enthalten. Es handelt sich dabei um Methoden, welche innerhalb der jeweiligen Instanz der Klasse ausgeführt werden. Sie können daher auf die jeweiligen Daten der Objekte zugreifen und diese verarbeiten und verändern. Im Rahmen der objektorientierten Modellierung ist es üblich, die Variablen eines Objektes nicht direkt abzurufen und zu befüllen, sondern dies über eigene Methoden zu bewerkstelligen. Dabei handelt es sich meist im eine Get- und eine Set-Methode. Sie werden daher auch als '''Getter und Setter''' bezeichnet. Für das Beispiel in Abbildung 68 werden daher Get- und Set-Methoden für die Variablen ''Name'', ''E-Mail'', ''KundenNr'' für die Klasse ''Kunde'' und für ''UstId'' und ''Firmenname'' der ihrer Tochterklasse ''Geschäftskunde'' angelegt. Das neue Modell ist in Abbildung 69 ersichtlich.
| |
|
| |
| <span id="_Ref406419448" class="anchor"></span>Abbildung 69 – Klassen mit Get- und Set-Methoden
| |
|
| |
| Eine weitere Möglichkeit bei der Vererbung von Klassen und ihrer Methoden ist die '''Überlagerung oder Polymorphie'''. Dabei können bereits in der Mutterklasse definierte Methoden erneut definiert und damit überlagert werden. Dies kann erforderlich sein, wenn der Methodenzweck sich durch die abgeleitete Klasse und ihrer konkreteren Daten verändern muss, um weiterhin ein korrektes Ergebnis zu liefern. Zur Veranschaulichung dieses Prinzips wird das Kundenbeispiel um eine Methode ''getKundenString'' erweitert. Der Zweck der Methode soll die Rückgabe einer Zeichenkette sein, welche immer alle relevanten Kundendaten enthalten soll, um sie beispielsweise später in einer Liste anzudrucken. Je nachdem, ob es sich um einen ''Kunden'' oder einen ''Geschäftskunden'' handelt, sollen die Werte ''Name'' und ''Kundennummer'', und gegebenenfalls auch der ''Firmenname'' enthalten sein. Dazu wird die neue Methode nun sowohl in der Mutterklasse ''Kunde'', als auch in der Tochterklasse ''Geschäftskunde'' definiert und dadurch für jede Instanz der Klasse ''Geschäftskunde'' in der Mutterklasse überlagert. Die Definition der überlagerten Methode ''getKundenString'' ist in Abbildung 70 ersichtlich.
| |
|
| |
| <span id="_Ref406421446" class="anchor"></span>Abbildung 70 – Klassen mit überlagerter Methode ''getKundenString()''
| |
|
| |
| Eine Ausnahme unter den Variablen und Methoden einer Klasse sind '''statische Variablen und statische Methoden'''. Diese sind direkt der Klasse zugeordnet und können keinen Einfluss auf Instanz-Variablen der Objektinstanzen nehmen. '''Statische Methoden''' können daher nicht nur über ein instanziiertes Objekt der Klasse, sondern auch ohne Objekt direkt über die Klasse aufgerufen werden. Diese Art der Methoden wird häufig in Klassen verwendet, von denen keine Objekte abgeleitet werden sollen, sondern die nur als Gruppierung von Methoden dienen. Ein Beispiel dafür sind mathematische Methodensammlungen. Klassen aus welchen selbst keine Objekte instanziiert werden dürfen werden selbst als statisch definiert. Statische Klassen können daher auch keine Instanz-Variablen beinhalten, sondern nur statische Variablen. '''Statische Variablen''' können sowohl durch statische, als auch durch nicht statische Methoden verändert werden. Sie werden jedoch auf der Ebene der Klasse geführt und nicht auf der der Objekte. Der Inhalt statischer Variablen gilt daher immer übergreifend für alle Objekte und wird auch nur übergreifend geändert. Es sind daher gemeinsame Variablen der Objekte der Klasse.
| |
|
| |
| <span id="kapselung"></span>
| |
| === Kapselung ===
| |
|
| |
| Damit die Variablen und Methoden einer Klasse nicht wahllos durch Zugriffe von außerhalb der Klasse aufgerufen und verändert werden können, gibt es die Möglichkeit, diese über die Kapselung zu schützen.
| |
|
| |
| Grundsätzlich sollte der Zugriff auf die Elemente des Objektes so eingeschränkt wie möglich sein. Das bedeutet, dass die Variablen eines Objektes möglichst nur über die entsprechenden Getter und Setter Methoden ausgelesen und verändert werden sollten. Auch sollten Methoden, welche nur für objektinterne Operationen verwendet werden sollen, nicht außerhalb des Projektes aufgerufen werden können.
| |
|
| |
| Um diese Kapselung sicherzustellen gibt es vier verschiedene Zugriffsmodifikatoren (Access-Modifier), mit denen der Kapselungs-Level definiert wird:
| |
|
| |
| * Public,
| |
| * Package,
| |
| * Protected und
| |
| * Private.
| |
| Um eine Variable oder Methode mit einem Kapselungs-Level zu versehen wird dieser meist direkt bei ihrer Definition angegeben. In UML geschieht dies vor dem Variablen- oder Methoden-Namen (siehe 5.4).
| |
|
| |
| Der offenste Level ist der Level '''Public'''. Er ermöglicht einen direkten Zugriff von außerhalb des Objektes oder der Klasse. Ein Beispiel für Methoden, welche diesem Level unterliegen sind die Getter- und Setter-Methoden.
| |
|
| |
| Der Level mit der größten Einschränkung ist '''Private'''. Auf alle Methoden und Variablen, welche mit diesem Level versehen sind, dürfen nur innerhalb des eigenen Objektes zugegriffen werden. Dieser Zugriffschutz gilt auch gegenüber abgeleitete Klassen und deren Objekten. Wurde somit in einer Mutterklasse eine private Variable x definiert, können neue oder überlagerte Methoden des Tochterelements nicht direkt auf sie zugreifen. Der Zugriff ist nur über Methoden möglich, welche auch auf Ebene des Mutterobjektes definiert wurden. Ein Zugriff wäre damit nur über eine Methode der Mutterklasse möglich, die selbst nicht als private definiert wurde.
| |
|
| |
| Der Level '''Protected''' ist ein Kompromiss zwischen den Level Public und Private für den Zugriff innerhalb der Vererbungshierarchie. Alle Variablen und Methoden dieses Levels sind nicht von außerhalb des Objektes oder der Klasse zugreifbar. Innerhalb der Vererbung darf jedoch voll auf sie zugegriffen werden. Somit kann eine Variable x mit dem Level protected einer Mutterklasse durch ihre Tochterklasse voll ausgelesen und beschrieben werden, nicht jedoch von außerhalb der Klassen und Objekte.
| |
|
| |
| Der Level '''Package''' entspricht dem Prinzip des Levels Protected. Die Zugriffserlaubnis wird jedoch über die Vererbungshierarchie hinaus auf alle Klassen und Objekte desselben Packages ausgeweitet. Ein Zugriff von außerhalb des Packages ist hier ebenfalls nicht gestattet. Er ist meist der Standardlevel, welcher zur Anwendung kommt, wenn kein spezieller Level angegeben wurde, wobei der sich Standardwert je nach Programmiersprache auch unterscheiden kann. Bei einem Package handelt es sich um eine logische Gruppierung von Klassen.
| |
|
| |
| <span id="abstrakte-klassen"></span>
| |
| === Abstrakte Klassen ===
| |
|
| |
| Abstrakte Klassen sind Vorlagen für die Vererbung und dienen auch als generalisierte Übergruppen ihrer Tochter-Klassen. Aus Ihnen können keine Objekte generiert werden. Wird aus einer abstrakten Mutter-Klasse eine Tochter-Klasse abgeleitet, kann diese abstrakt aber auch nicht abstrakt sein. Ist die abgeleitete Klasse nicht mehr abstrakt, können aus ihr Objekte generiert werden.
| |
|
| |
| Damit eine Klasse abstrakt wird, muss sie selbst als abstrakt gekennzeichnet werden. Weiter gibt es die Möglichkeit, '''abstrakte Methoden''' zu definieren. Abstrakte Methoden sind nur eine Definition des Methodenkopfes, der aus Name und den übergebenen und zurückgelieferten Datentypen besteht. Sie müssen in den abgeleiteten Klassen überlagert und entsprechend ausprogrammiert werden. Die Tochter-Klasse ist dann solange selbst eine abstrakte Klasse, bis alle abstrakten Methoden der Mutter-Klassen überlagert und implementiert sind.
| |
|
| |
| Abstrakte Klassen können jedoch auch eine Basisimplementierung bestimmter Methoden zur Verfügung stellen, welche dann von allen abgeleiteten Klassen eingesetzt werden können.
| |
|
| |
| Ein Beispiel einer abstrakten Klasse wäre ein Klasse ''Fahrzeug'' mit den abstrakten Klassen-Methoden „''bewegen''“ und ''„stehen bleiben''“. Objekte der Klasse ''Fahrzeug'' machen noch keinen Sinn, da noch nicht klar ist wie das jeweilige Fahrzeug die Ausführung der beiden Methoden bewerkstelligen kann. Von ihr können nun die Klassen ''Auto'' und ''Fahrrad'' abgeleitet werden, welche die beiden Methoden jeweils überlagern und entsprechend der Anforderungen an das jeweilige Fahrzeug fertig implementieren.
| |
|
| |
| <span id="prinzipien-objektorientierten-designs-solid-object-oriented-design"></span>
| |
| === Prinzipien objektorientierten Designs (SOLID object-oriented design) ===
| |
|
| |
| Im Jahr 1994 entwickelte Robert C. Martin die Prinzipien objektorientierten Designs und veröffentlichte dazu eine Vielzahl von Artikel. Eine Zusammenfassung der Prinzipien kann im Detail in (Martin, 2000) nachgelesen werden. Dabei gibt es jeweils eigene Gruppen von Prinzipien für das Klassen- und Package-Design.
| |
|
| |
| Die wichtigsten fünf Prinzipien des Objektorientierten Designs sind:
| |
|
| |
| * '''Das Single Responsibility Prinzip''':
| |
| Eine Klasse soll nur für einen Anwendungsbereich verantwortlich sein, damit spätere Änderungen nicht mehrere Anwendungsbereiche betreffen und damit zu Fehlern führen können.
| |
|
| |
| * '''Das Open Closed Prinzip:'''
| |
| Eine Klasse soll offen sein erweitert zu werden, jedoch soweit geschlossen sein, um keine Modifikationen an ihr selbst zuzulassen.
| |
|
| |
| * '''Das Liskov Substitution Prinzip:'''
| |
| Eine Instanz einer abgeleiteten Klasse muss sich so verhalten wie eine Instanz der Mutterklasse. Ihre Funktionen dürfen nicht grundlegend anders sein.
| |
|
| |
| * '''Das Interface Segregation Prinzip:'''
| |
| Die Funktionalitäten müssen soweit entkoppelt sein, dass eine Verwendung von Klassen möglich ist, die nur den benötigten Zweck erfüllen. Der Client darf nicht gezwungen werden, Klassen einzusetzen von denen er nur einen Teil wirklich benötigt. Dadurch werden Ressourcen gespart und der Aufwand von späteren Softwareanpassungen wird geringer.
| |
|
| |
| * '''Das Dependency Inversion Prinzip'''
| |
| Abstraktionen dürfen nur in eine Richtung erfolgen. Eine Abstraktion auf einer höheren Ebene darf nicht von Attributen einer niedrigeren Ebene abhängen. Das bedeutet, dass eine Mutterklasse keine Elemente von Tochterklassen benötigen darf, eine Tochterklasse hingegen jedoch Teile der Mutterklasse.
| |
|
| |
| Da aus den Anfangsbuchstaben der Prinzipien das Akronym SOLID gebildet werden kann, wird ein an ihnen orientiertes Objekt-Design oft als '''SOLID object-oriented design''' bezeichnet.
| |
|
| |
| <span id="die-unified-modeling-language-uml"></span>
| |
| == Die Unified Modeling Language (UML) ==
| |
|
| |
| Durch die Verbreitung der objektorientierten Konzepte bei der Analyse und dem Design von Informationssystemen und auch durch die Notwendigkeit dynamische Aspekte formalisiert in einem Gesamtmodell zu beschreiben, wurden die Bemühungen intensiviert, eine möglichst umfassende und konsistente Modellierungssprache zu entwickeln. Dies führte schließlich nach einem heftigen „Methodenkrieg“ zur Definition der objektorientierten Modellierungssprache '''UML''', der '''Unified Modeling Language''', die auch als Standard (Object Management Group (OMG), 2011) von der OMG akzeptiert wurde.
| |
|
| |
| Ziel war es, eine Sprache zu entwickeln, die komplexe Systeme in ihrer Gesamtheit erfassen kann. Da hierzu ein einziges Modell nicht ausreicht, erschien es notwendig, verschiedene Sichten auf die zu modellierende Realität zu definieren, die durch unterschiedliche, relativ unabhängige Modellen innerhalb eines konsistenten Gesamtkonzepts dargestellt werden. Dieser Ansatz führte zur Entwicklung von UML, einer graphischen Sprache für die objektorientierte Modellierung von industriellen Softwaresystemen und anderer komplexer Systeme. Sie erlaubt hierbei die Visualisierung, Spezifikation, Konstruktion und Dokumentation der verschiedenen Elemente der zu modellierenden Systeme. UML vereinigt dabei die Notationen von Booch, Rumbaugh und Jacobson, indem sie fast alle Modelle der drei Methoden enthält und weitere Notationsformen hinzufügt.
| |
|
| |
| '''Ziele von UML:'''
| |
|
| |
| * Sie stellt dem Benutzer eine verwendbare, ausdrucksstarke visuelle Modellierungssprache zur Entwicklung und dem Austausch inhaltsvoller Modelle zur Verfügung.
| |
| * Sie erlaubt Erweiterungs- und Spezialisierungsmechanismen zur Erweiterung der Kernkonzepte.
| |
| * Sie ist unabhängig von spezifischen Programmiersprachen und Entwicklungsprozessen.
| |
| * Sie ist durch eine rigorose (semi-formale) Modellierungssprache (UML-Meta-Modell) definiert.
| |
| * Sie ermutigt die Entwicklung des OO Tool Markts.
| |
| * Sie unterstützt abstrahierte Entwicklungskonzepte, wie Kollaboration, Frameworks, Patterns und Komponenten.
| |
| '''Beschränkungen von UML:'''
| |
|
| |
| * Sie ist keine visuelle Programmiersprache, d.h. sie bietet keine Unterstützung für eine volle Programmiersprache, wie zum Beispiel Ausdrücke, Kontrollkonstrukte, …
| |
| * UML definiert keine Schnittstelle zu spezifischen Softwarewerkzeugen.
| |
| * UML definiert keinen Entwicklungsprozess, d.h.
| |
| <blockquote>Sie schreibt keinen Ansatz vor, wie man Klassen, oder Verhalten findet, sie enthält keine Design Richtlinien oder Empfehlungen.
| |
|
| |
| UML unterstützt jedoch Prozesse, die folgende Eigenschaften aufweisen:</blockquote>
| |
| * Use-Case-gesteuert,
| |
| * Iterativ,
| |
| * Architekturzentriert und
| |
| * Inkrementell.
| |
|
| |
| <span id="uml-diagrammtypen"></span>
| |
| == UML Diagrammtypen ==
| |
|
| |
| Die zentrale Eigenschaft der Notation ist die Unterstützung von verschiedenen Sichten auf das zu modellierende System. Hierzu stellt UML eine Reihe von unterschiedlichen Diagrammtypen, sogenannten Spracheinheiten (language units), zur Verfügung. Diese Diagrammtypen erlauben es dem Benutzer einen ausgewählten Aspekt eines Systems mit einem bestimmten Formalismus zu modellieren.
| |
|
| |
| UML 2.0 stellt hierzu insgesamt 13 Diagrammtypen zur Verfügung, die grundsätzlich in zwei Gruppen eingeteilt werden können, in sechs '''Strukturdiagramme''', die die statischen Aspekte darstellen, und sieben '''Verhaltensdiagramme''' für die dynamischen Aspekte, wobei drei allgemeines Verhalten und vier Interaktionen beschreiben. Im Folgenden werden diese 13 Diagramme kurz erläutert <ref>Die graphischen Darstellungen sind aus Wikipedia, http://de.wikipedia.org/</ref> . In den nachfolgenden Abschnitten 5.4 und 5.5 werden das Objektdiagramm und das Anwendungsfalldiagramm genauer behandelt.
| |
|
| |
| <span id="strukturdiagramme"></span>
| |
| === Strukturdiagramme ===
| |
|
| |
| {| style="border-collapse: collapse;" border="1"
| |
| ! width="44%" | '''Klassendiagramm'''
| |
|
| |
| Stellt den „strukturellen“ Kern von UML dar, fasst gleichartige Objekte zusammen und definiert die Beziehungen untereinander
| |
| ! width="55%" | [[File:media/image27.png|202x118px]]
| |
| |-
| |
| |
| |
| '''Objektdiagramm'''
| |
|
| |
| Stellt einen prototypischen Ausschnitt aus dem System dar, besteht nur aus Objekten
| |
| | [[File:media/image28.png|299x87px]]
| |
| |-
| |
| |
| |
| '''Paketdiagramm'''
| |
|
| |
| Erlaubt die Gruppierung von Systembestandteilen und verschiedenen Ebenen und dient zur Reduzierung der Komplexität in der Darstellung
| |
| | [[File:media/image29.png|284x129px]]
| |
| |-
| |
| |
| |
| '''Komponentendiagramm'''
| |
|
| |
| Definiert Komponenten (modulare Systemteile) und deren Abhängigkeiten unter einem softwareorganisatorischen Aspekt
| |
| | [[File:media/image30.png|170x108px]]
| |
| |-
| |
| |
| |
| '''Kompositionsstrukturdiagramm'''
| |
|
| |
| Erlaubt die (kontextabhängige) hierarchische Strukturierung von Systemteilen
| |
| | [[File:media/image31.png|176x109px]]
| |
| |-
| |
| |
| |
| '''Verteilungsdiagramm'''
| |
|
| |
| Beschreibt die eingesetzte Hardwareinfrastruktur und deren Aufbau und das Laufzeitsystem
| |
| | [[File:media/image32.png|132x97px]]
| |
| |}
| |
|
| |
| <span id="verhaltensdiagramme"></span>
| |
| === Verhaltensdiagramme ===
| |
|
| |
| {| style="border-collapse: collapse;" border="1"
| |
| ! width="46%" | '''Anwendungsfalldiagramm'''
| |
|
| |
| Spezifiziert die Funktionalität des zu entwickelnden Systems aus der Benutzersicht auf der Basis von Szenarien
| |
| ! width="53%" | [[File:media/image33.png|232x144px]]
| |
| |-
| |
| |
| |
| '''Aktivitätsdiagramm'''
| |
|
| |
| Stellt den Kontroll- und Datenfluss von Abläufen im System dar (Prozessmodellierung)
| |
| | [[File:media/image34.png|225x116px]]
| |
| |-
| |
| |
| |
| '''Zustandsdiagramm'''
| |
|
| |
| Definiert das Verhalten eines Objekts über seine erlaubten Zustände und Zustandsübergänge (Lebenszyklus eines Objekts)
| |
| | [[File:media/image35.png|120x115px]]
| |
| |-
| |
| |
| |
| '''Sequenzdiagramm'''
| |
|
| |
| Definiert die Interaktionen von Objekten bei einer spezifischen Aufgabe, der Fokus liegt hier bei der Beschreibung der zeitlichen Reihenfolge
| |
| | [[File:media/image36.png|154x128px]]
| |
| |-
| |
| |
| |
| '''Kommunikationsdiagramm'''
| |
|
| |
| Eigentlich analog zum Sequenzdiagramm werden die Interaktionen zwischen Objekten beschrieben, der Schwerpunkt liegt hier aber auf den strukturellen Beziehungen
| |
| | [[File:media/image37.png|202x129px]]
| |
| |-
| |
| |
| |
| '''Zeitdiagramm'''
| |
|
| |
| Spezielle Form des Interaktionsdiagramms für präzise zeitliche Spezifikationen, eignet sich für die Beschreibung von Echtzeitsystemen
| |
| | [[File:media/image38.png|227x99px]]
| |
| |-
| |
| |
| |
| '''Interaktionsübersichtsdiagramm'''
| |
|
| |
| Beschreibt abstrakt den Kontrollfluss zwischen verschiedenen Interaktionsabläufen, erlaubt die Beschreibung der logischen Reihenfolge von Interaktionsdiagrammen
| |
| | [[File:media/image39.png|146x179px]]
| |
| |}
| |
|
| |
| <span id="uml-klassendiagramm"></span>
| |
| == UML Klassendiagramm ==
| |
|
| |
| Ein '''Klassendiagramm''' beschreibt den strukturellen Aspekt des zu modellierenden Systems. Es unterstützt die objektorientierte Betrachtungsweise indem es Modellierungselemente für Klassen, ihre Eigenschaften (Attribute), ihr Verhalten (Operationen, Methoden) und ihre Beziehungen zur Verfügung stellt. Neben reinen Assoziationen wird auch die Beschreibung von Generalisations- und Aggregationsbeziehungen unterstützt.
| |
|
| |
| Eine Klasse wird in UML durch ein Rechteck dargestellt, das in horizontale Abschnitte gegliedert wird, die den Namen der Klasse, die Attribute, Operationen und optionalen weiteren, nicht normierte, „Compartments“ für textuelle Beschreibungen, wie Verantwortlichkeiten, Ausnahmen, etc. enthalten (siehe Abbildung 71). Mit Ausnahme des Namens der Klasse können alle weiteren Beschreibungselemente fehlen.
| |
|
| |
| [[File:media/image40.png|463x176px]]
| |
|
| |
| <span id="_Ref208639486" class="anchor"></span>Abbildung 71 – Klassendiagramm
| |
|
| |
| Bei der Definition von Klassen sind eine Reihe weiterer Angaben möglich. Beim Klassennamen können auch noch ein Stereotyp, in doppelten spitzen Klammern << … >>, und Eigenschaften, in geschwungenen Klammern, { … } angegeben werden.
| |
|
| |
| Stereotype sind ein Mechanismus, Sprachkonzepte von UML zu erweitern, wobei UML einige standardisierte Stereotype zur Verfügung stellt, wie zum Beispiel << entity >>, das die Klasse als persistente Problembereichsklasse identifiziert.
| |
|
| |
| Über Eigenschaften können Klassen gekennzeichnet werden. Eine häufig benutzte Eigenschaft ist die Verwendung der Eigenschaft { abstract } zur Kennzeichnung einer abstrakten Klasse. Es kann auch zum Beispiel das Speicherverhalten einer Klasse mit { persistence = persistent } definiert werden, das angibt, dass Objekte dieser Klasse dauerhaft (z. B. in einer Datenbank) abgelegt werden.
| |
|
| |
| Es kann auch eine Multiplizität für Klassen rechts oben beim Namen angegeben werden. Diese besagt, wie viele Objekte dieser Klasse existieren dürfen. Falls nichts angegeben ist, ist die Zahl unbegrenzt.
| |
|
| |
| Bei den Attributen können Anfangswerte (z. B. Bonität: Integer = 0) und Sichtbarkeiten bzw. Zugriffsberechtigungen angegeben werden:
| |
|
| |
| * - für private,
| |
| * + für public,
| |
| * # für protected und
| |
| * ~ für package.
| |
| Für die Operationen müssen Parameterlisten angegeben werden. Es reicht die Angabe eines Namens, weitere Spezifikationen, wie Typ, Angabe, Eingabe-/Ausgabeparameter und Standardwert sind optional. Funktionen werden durch die Angabe eines Ergebnistyps vereinbart; bei Prozeduren fehlt dieser. Die Sichtbarkeiten können bei Operationen analog zu den Attributen definiert werden.
| |
|
| |
| Attribute und Operatoren können ebenfalls mit Eigenschaften versehen werden, wie beispielsweise { static } zur Kennzeichnung als statisches Element auf Klassenebene.
| |
|
| |
| Es können weiter auch bei den Operationen Stereotype angegeben werden, die helfen, die Operationen zu gruppieren. Ein entsprechend erweitertes Beispiel ist in Abbildung 72 abgebildet.
| |
|
| |
| [[File:media/image41.png|241x189px]]
| |
|
| |
| <span id="_Ref208640534" class="anchor"></span>Abbildung 72 – Erweitertes Klassendiagramm
| |
|
| |
| Klassen erlauben auch abgeleitete Attribute zu spezifizieren. Das bedeutet, dass solche Attribute aus anderen Informationen berechnet werden. Diese Attribute werden durch einen vor den Namen gestellten Schrägstrich gekennzeichnet. Es kann auch die Berechnungsvorschrift in geschwungenen Klammern angegeben werden. Feldartige Attribute werden über eine Intervallschreibweise vereinbart.
| |
|
| |
| Ein Beispiel, das diese Möglichkeiten veranschaulicht, ist in der Abbildung 73 angegeben.
| |
|
| |
| [[File:media/image42.png|284x190px]]
| |
|
| |
| <span id="_Ref208653515" class="anchor"></span>Abbildung 73 – UML Klasse Angestellter
| |
|
| |
| <span id="assoziationen"></span>
| |
| === Assoziationen ===
| |
|
| |
| Eine '''Assoziation''' zeigt eine Beziehung zwischen zwei Klassen an und kann einen Namen haben. Mit anderen Worten ausgedrückt zeigt eine Assoziation an, dass eine Klasse von der Existenz einer anderen Klasse „wissen“ muss. Zum Beispiel kann ein Objekt einer Klasse durch Änderungen von Objekten einer anderen Klasse beeinflusst werden. Praktische Gründe für Assoziationen können sein:
| |
|
| |
| * schickt Message an ein Objekt der Klasse
| |
| * erzeugt ein Objekt der Klasse
| |
| * verwendet die andere Klasse als Typ für ein Methodenargument
| |
| * verwendet die andere Klasse als Typ eines Attributes
| |
| * ...
| |
| Betrachten wir hierzu folgendes Beispiel (Abbildung 74):
| |
|
| |
| [[File:media/image43.png|428x111px]]
| |
|
| |
| <span id="_Ref208643418" class="anchor"></span>Abbildung 74 – Assoziation
| |
|
| |
| Das (optionale) gefüllte Dreieck () gibt die Leserichtung der Assoziation an und hilft die Beziehung einfacher zu interpretieren. Auch hier können, wie bei der ER-Notation, Multiplizität (multiplicity) angegeben werden, die spezifizieren, wie viele Objekte an der Beziehung teilnehmen. Die Multiplizität liefert die Anzahl von Objekten einer Klasse in Bezug auf ein Objekt der anderen Klasse. In unserem obigen Beispiel bedeutet dies, dass jede Bestellung genau einen Kunden hat, jeder Kunde aber 0 bis beliebig viele (0..*) Bestellungen durchführen kann.
| |
|
| |
| UML unterstützt auch weitere Formen der Assoziationen, wie
| |
|
| |
| {| style="border-collapse: collapse;" border="1"
| |
| ! width="42%" | * Reflexive Assoziation
| |
| <blockquote>Diese Assoziationsform besteht zwischen Objekten derselben Klasse. Es müssen aber Rollennamen angegeben werden (Abbildung 75).</blockquote>
| |
| ! width="57%" | [[File:media/image44.png|236x117px]]
| |
|
| |
| <span id="_Ref208644013" class="anchor"></span>Abbildung 75 – Reflexive Assoziation
| |
| |-
| |
| |
| |
| * Assoziationsklassen
| |
| <blockquote>Eine Assoziationsklasse erlaubt die detaillierte Beschreibung von Assoziationseigenschaften (Abbildung 76). Die Darstellung verwendet das Klassensymbol, das durch eine gestrichelte Linie mit der Assoziationskante verbunden ist.</blockquote>
| |
| |
| |
| [[File:media/image45.png|254x93px]]
| |
|
| |
| <span id="_Ref208644037" class="anchor"></span>Abbildung 76 – Assoziationsklasse
| |
| |-
| |
| |
| |
| * N-äre Assoziation
| |
| <blockquote>Dies ist eine Assoziation zwischen 3 oder mehr Klassen (Abbildung 77). Jede Instanz einer n-ären Assoziation ist ein n-Tupel von Instanzen der beteiligten Assoziationen (können auch Assoziationsklassen sein).</blockquote>
| |
| |
| |
| [[File:media/image46.png|229x84px]]
| |
|
| |
| <span id="_Ref208644091" class="anchor"></span>Abbildung 77 – N-äre Assoziation
| |
| |-
| |
| |
| |
| * XOR-Assoziation
| |
| <blockquote>Eine Klasse kann potentiell Assoziationen zu mehreren anderen Klassen aufweisen, auf Instanzebene tritt aber immer nur eine dieser Assoziationen auf. Im Diagramm werden die betroffenen Assoziationskanten mit einer gestrichelten Linie verbunden (Abbildung 78).</blockquote>
| |
| |
| |
| [[File:media/image47.png|215x106px]]
| |
|
| |
| <span id="_Ref208655053" class="anchor"></span>Abbildung 78 – XOR-Assoziation
| |
| |}
| |
|
| |
| <span id="objektdiagramm"></span>
| |
| === Objektdiagramm ===
| |
|
| |
| Ein '''Objektdiagramm''' zeigt eine mögliche Systemkonfiguration durch ein Menge von Objekten und ihre Verbindungen. Es stellt quasi einen Snapshot einer prototypischen Systemsituation dar. Ein Objektdiagramm muss dem Klassendiagramm entsprechen und zeigt eine mögliche Interpretation (von vielen). UML verwendet eine einheitliche Darstellung, um Instanzen von dem dazugehörigen Typ zu unterscheiden, indem die Instanz dasselbe graphische Symbol wie der Typ verwendet, jedoch der Name unterstrichen wird. Siehe hierzu Abbildung 79, die die Klasse und das entsprechende Objekt darstellt.
| |
|
| |
| [[File:media/image48.png|549x97px]]
| |
|
| |
| <span id="_Ref208645846" class="anchor"></span>Abbildung 79 – Objektdiagramm
| |
|
| |
| Gerichtete Pfeile zeigen die Richtung der Implementierung an, die andere Richtung geht nicht. Man kann den Attributen von Objekten Werte zuweisen. Grundsätzlich sollten Objekte Instanzen existierender Klassen (durch „:“ gekennzeichnet) und Verbindungen Instanzen existierender Assoziationen sein, wobei etwaige Randbedingungen eingehalten werden.
| |
|
| |
| <span id="generalisierung-und-spezialisierung"></span>
| |
| === Generalisierung und Spezialisierung ===
| |
|
| |
| Die '''Generalisierung''' stellt eine hierarchische Beziehung zwischen einer allgemeineren Klasse (Oberklasse) und einer spezialisierten Klasse (Unterklasse) dar. Wir bezeichnen diese Generalisierung als eine IS-A Beziehung. Die Unterklasse erbt die Eigenschaften der Oberklasse, kann aber weitere spezifische Eigenschaften hinzufügen. In UML kennzeichnet man diese Generalisierungshierarchie durch einen nicht ausgefüllten Pfeil. Siehe hierzu folgendes Beispiel (Abbildung 80):
| |
|
| |
| [[File:media/image49.png|358x245px]]
| |
|
| |
| <span id="_Ref208644548" class="anchor"></span>Abbildung 80 – UML Generalisierung
| |
|
| |
| Analog zu den ER-Diagrammen lassen sich auch hier die Überdeckungen spezifizieren. Man kann im Diagramm neben dem Generalisierungsdreieck die Überdeckung in geschwungenen Klammern entsprechend angeben:
| |
|
| |
| * überlappend / exklusiv entspricht overlapping / disjoint (UML) und
| |
| * Total / Partiell entspricht complete / incomplete (UML).
| |
| Siehe hierzu das erläuternde Beispiel in Abbildung 81:
| |
|
| |
| [[File:media/image50.png|255x112px]]
| |
|
| |
| <span id="_Ref208658038" class="anchor"></span>Abbildung 81 – UML Überdeckung
| |
|
| |
| <span id="mehrfachvererbungen"></span>
| |
| === Mehrfachvererbungen ===
| |
|
| |
| UML unterstützt auch die Notation von '''Mehrfachvererbungen'''. Siehe hierzu das folgende Beispiel in Abbildung 82:
| |
|
| |
| [[File:media/image51.png|298x187px]]
| |
|
| |
| <span id="_Ref208658427" class="anchor"></span>Abbildung 82 – UML Mehrfachvererbung
| |
|
| |
| <span id="aggregation"></span>
| |
| === Aggregation ===
| |
|
| |
| Die '''Aggregation''' ist eine spezielle Form der Assoziation, die anzeigt, dass ein Objekt einer Klasse Teil eines Objektes einer anderen Klasse ist. Wir bezeichnen dieses Beziehung daher als „part-of“ / “has-a“ Beziehung („teil-von“ / „hat-ein“). Auch Aggregationen können (und sollten) einen Namen haben. Es kann auch hier die Multiplizität angegeben werden. Wir verwenden hierzu in UML die nicht ausgefüllte Raute. Siehe hierzu das folgende Beispiel (Abbildung 83):
| |
|
| |
| [[File:media/image52.png|329x39px]]
| |
|
| |
| <span id="_Ref208645054" class="anchor"></span>Abbildung 83 – UML Aggregation
| |
|
| |
| <span id="komposition"></span>
| |
| === Komposition ===
| |
|
| |
| Eine strengere Form der Aggregation ist die '''Komposition''', bei der der Teil nur Kompositionsteil '''eines''' Ganzen sein darf. Das Kompositum ist auch für das Erzeugen und Zerstören des Teils verantwortlich. In UML wird dazu die ausgefüllte Raute verwendet. Siehe das folgende Beispiel (Abbildung 84):
| |
|
| |
| [[File:media/image53.png|328x40px]]
| |
|
| |
| <span id="_Ref208645146" class="anchor"></span>Abbildung 84 – UML Komposition
| |
|
| |
| Das Kompositum („Ganze“) darf in der Kompositionsassoziation nur einmal oder keinmal auftreten, daher darf die Multiplizität auf Seiten des Kompositums nur 1 oder 0..1 sein.
| |
|
| |
| In den nachfolgenden, etwas umfangreicheren, Beispielen (Abbildung 85 und Abbildung 86) sind die Ausschnitte zweier Realitäten modelliert, eine Fachhochschule und eine Bank. Sie erkennen hier den Einsatz von Generalisation und Aggregation.
| |
|
| |
| [[File:media/image54.png|528x247px]]
| |
|
| |
| <span id="_Ref208651154" class="anchor"></span>Abbildung 85 – UML Beispiel Fachhochschule
| |
|
| |
| [[File:media/image55.png|526x272px]]
| |
|
| |
| <span id="_Ref208656969" class="anchor"></span>Abbildung 86 – UML Beispiel Bank
| |
|
| |
| <span id="uml-anwendungsfalldiagramm-use-case-diagramm"></span>
| |
| == UML Anwendungsfalldiagramm (Use Case Diagramm) ==
| |
|
| |
| '''Anwendungsfalldiagramme''' oder auch '''Use Case Diagramme''' dokumentieren das Verhalten des Systems vom Blickpunkt des Benutzers aus. Sie helfen bei drei wichtigen Aspekten der Entwicklung:
| |
|
| |
| * Finden der Anforderungen an das System (Systemspezifikation)
| |
| * Planung der Zyklen der Entwicklung (bezogen auf den Benutzer)
| |
| * Erstellen sinnvoller und aussagestarker Systemtests
| |
| Use Case Diagramme wurden ursprünglich von Jacobson (in den frühen 90er) in seinem OOSE Modell eingeführt und haben sich aus den „Scenarios“ entwickelt. Use-Cases sind unabhängig von einer objektorientierten Betrachtungsweise. Dies kann eine Stärke, aber auch eine Schwäche sein.
| |
|
| |
| <span id="darstellung"></span>
| |
| === Darstellung ===
| |
|
| |
| Beginnen wir mit einem einfachen Beispiel für ein Anwendungsfalldiagramm, das die wichtigsten Elemente dieser Notationsform enthält (siehe Abbildung 87):
| |
|
| |
| [[File:media/image56.png|292x229px]]
| |
|
| |
| <span id="_Ref208663298" class="anchor"></span>Abbildung 87 – Anwendungsfalldiagramm Beispiel (nach Jacobson)
| |
|
| |
| Ein '''Use Case''' repräsentiert eine mögliche Interaktion mit dem System. Ein System wird durch ein Rechteck dargestellt, das die Anwendungsfälle enthält. Ein spezifischer Anwendungsfall wird durch eine Ellipse dargestellt, bei der der Name des Falls in oder unter der Ellipse angegeben wird. Das zweite wichtige Element ist der sogenannte '''Aktor''', der als Strichfigur dargestellt und benannt wird. Ein Aktor kann ein menschlicher Benutzer oder eine Benutzergruppe des Systems in einer spezifischen Rolle, aber auch ein Programm oder ein externes System sein, das in einer spezifischen Rolle mit dem System interagiert. Die Verbindung zwischen Anwendungsfall und Aktor ist durch eine einfache Linie dargestellt. Derselbe menschliche Benutzer oder dasselbe externe System kann mit dem System in mehr als einer Rolle interagieren. Sie werden dann durch mehrere Aktoren realisiert.
| |
|
| |
| Use-Cases enthalten (normalerweise) eine textuelle Beschreibung über die Folge der zwischen dem Aktor und dem System ausgetauschten Botschaften (Messages) und die Aktionen des Systems, um die Funktionalität zu realisieren. Diese Beschreibung kann auch logische Fallunterscheidungen für Ausnahmefälle enthalten, wie zum Beispiel: „falls Kontostand zu niedrig, stop und Fehlermeldung“. Ein Use-Case kann auch mit anderen UML Diagrammen verbunden werden, um seine Realisierung zu zeigen.
| |
|
| |
| Wir wollen das Anwendungsfalldiagramm anhand eines weiteren Beispiels erläutern. Es soll ein Softwaresystem zur Unterstützung der Buchungen in einem Reisebüro entwickelt werden. Wir betrachten hierzu einen speziellen Aktor, nämlich den Reisebüroagenten. Die Funktionen dieses Aktors (Reisebüroagenten) sind die folgenden:
| |
|
| |
| {| style="border-collapse: collapse;" border="1"
| |
| ! width="67%" | * Eine Reise für eine Gruppe buchen:
| |
| <blockquote>Der Reisebüroagent bucht eine Gruppenreise, die aus mehreren Einzelreisen besteht. Die Bezahlung erfolgt erst nach der Buchung (z. B. über Kreditkarte). Jede gebuchte Einzelreise wird vom vorhandenen Reisekontingent des Reisebüros abgezogen.</blockquote>
| |
| ! width="32%" | [[File:media/image57.png|166x75px]]
| |
| |-
| |
| |
| |
| * Die Reise für die gesamte Gruppe stornieren:
| |
| <blockquote>Der Agent storniert die gesamte Gruppenreise. Jede einzelne Einzelreise muss storniert werden und auf das Kontingent des Reisebüros zurückgebucht werden.</blockquote>
| |
| | [[File:media/image58.png|166x75px]]
| |
| |-
| |
| |
| |
| * Die Reise eines einzelnen Reisenden (Einzelreise) in der Gruppe stornieren:
| |
| <blockquote>Der Agent storniert eine Einzelreise aus der Gruppenreise, die auf das Kontingent des Reisebüros zurückgebucht wird.</blockquote>
| |
| | [[File:media/image59.png|166x75px]]
| |
| |-
| |
| |
| |
| * Ein Luxus-Gruppenreise buchen:
| |
| <blockquote>Eine Gruppenreise kann durch einen Upgrade zu einer Luxus-Gruppenreise erweitert werden (5-Stern Hotel, All-Inklusiv).</blockquote>
| |
| | [[File:media/image60.png|166x75px]]
| |
| |}
| |
| Wir können daher diesen Use cases in das folgende Anwendungsfalldiagramm eintragen (Abbildung 88):
| |
|
| |
| [[File:media/image61.png|439x304px]]
| |
|
| |
| <span id="_Ref208717891" class="anchor"></span>Abbildung 88 – Use Case Reisebüro Buchungssystem
| |
|
| |
| <span id="beziehungen-zwischen-use-cases"></span>
| |
| === Beziehungen zwischen Use Cases ===
| |
|
| |
| Use Cases können nicht nur Beziehungen zu Aktoren, sondern auch untereinander haben. Es werden drei unterschiedliche Beziehungsarten unterschieden: die include-, die extend- und die Generalisierungsbeziehung.
| |
|
| |
| Die '''include-Beziehung''' besteht zwischen Use-Cases, die ein ähnliches Verhalten zeigen. Sie wird verwendet, um Aktionsfolgen nur einmal zu beschreiben, die aber in mehreren Use-Cases vorkommen.
| |
|
| |
| In unserem Reisebüro Beispiel liegt eine include-Beziehung zwischen dem Use Case „Storniere Gruppenreise“ und „Storniere Einzelreise“ vor, da im Fall der Stornierung einer gesamten Gruppenreise alle in ihr enthaltenen Einzelreisen storniert werden müssen. Das Gruppenreisestornieren verwendet („include“) das Verhalten des Einzelreisestornieren. Graphisch lässt sich das folgendermaßen darstellen (Abbildung 89):
| |
|
| |
| [[File:media/image62.png|302x123px]]
| |
|
| |
| <span id="_Ref208718198" class="anchor"></span>Abbildung 89 – <<include>>-Beziehung
| |
|
| |
| Die include-Beziehung wird durch einen gestrichelten Pfeil dargestellt, der mit dem Schlüsselwort <<include>> beschriftet ist.
| |
|
| |
| Die '''extend-Beziehung''' wird verwendet, um Spezialfälle zu beschreiben, d.h. Aktionsfolgen in einem durch eine extend-Beziehung verknüpften Use-Case sind optional. Man spricht auch davon, dass der Use-Case A ein zusätzliches Verhalten zum Use Case B zeigt (Hauptfall B - Nebenfall A).
| |
|
| |
| In unserem Beispiel des Reisebüros könnte zum Beispiel bei der Buchung einer Gruppenreise eine Erweiterung zu einer Luxus-Gruppenreise durchgeführt werden. Das bedeutet, dass der Use Case der normalen Gruppenbuchung durch den Luxus-Upgrade erweitert (extend) wird. Dies lässt sich graphisch durch die <<extend>>-Beziehung darstellen (Abbildung 90):
| |
|
| |
| [[File:media/image63.png|289x120px]]
| |
|
| |
| <span id="_Ref208718688" class="anchor"></span>Abbildung 90 – <<extend>> - Beziehung
| |
|
| |
| Die extend-Beziehung wird durch einen gestrichelten Pfeil dargestellt, der mit dem Schlüsselwort <<extend>> beschriftet ist.
| |
|
| |
| Die '''Generalisierungsbeziehung''' ist ähnlich der Vererbung im objektorientierten Ansatz und kann auf Aktivitäten (Funktionen) und Teilnehmer (Aktors) angewendet werden. Sie sollte vor allem eingesetzt werden, um Beziehungen zwischen abstrakten und konkreten Use Cases darzustellen.
| |
|
| |
| In unserem Beispiel könnten wir daher unsere Gruppenstornierung und Einzelstornierung als Spezialisierung eines abstrakten Stornierungsfalls sehen (Abbildung 91):
| |
|
| |
| [[File:media/image64.png|237x151px]]
| |
|
| |
| <span id="_Ref208719744" class="anchor"></span>Abbildung 91 – Use Case Generalisierung
| |
|
| |
| Wir können jetzt diese Beziehungen in unser ursprüngliches Anwendungsfalldiagramm eintragen und dadurch die Beschreibung erweitern (Abbildung 92):
| |
|
| |
| [[File:media/image65.png|439x292px]]
| |
|
| |
| <span id="_Ref208720530" class="anchor"></span>Abbildung 92 – Erweiterter Use Case Reisebüro Buchungssystem
| |
|
| |
| Im Folgenden wollen wir noch einige Faustregeln aufstellen, wann welcher Beziehungstyp eingesetzt werden soll:
| |
|
| |
| * Die include-Beziehung verwendet man dann, wenn der benutzte Use Case unbedingt notwendig ist, die Funktionalität des benutzenden Use Case sicherzustellen.
| |
| * Die extend-Beziehung erläutert, dass der zu erweiternde Use Case vom erweiterten Use Case übernommen werden kann, aber nicht muss.
| |
| * Die Generalisierungsbeziehung sollte man zwischen konkreten und abstrakten Use Case einsetzen.
| |
|
| |
| <span id="einsatz-von-use-cases"></span>
| |
| === Einsatz von Use Cases ===
| |
|
| |
| Use Cases sind sehr gut dazu geeignet oder können zumindest helfen, die Anforderungen (Spezifikationen) an das System zu identifizieren. Die Vorgangsweise ist hierbei relativ simpel:
| |
|
| |
| <ol style="list-style-type: decimal;">
| |
| <li><blockquote><p>Finde die Aktoren des Systems</p></blockquote></li>
| |
| <li><blockquote><p>Finde für jeden Aktor heraus:</p></blockquote></li>
| |
| </ol>
| |
| <blockquote>Was benötigt der Aktor vom System.
| |
|
| |
| Welche sonstige Interaktion hat der Aktor mit dem System.
| |
|
| |
| Welche Use-Cases besitzen welche Priorität für den Aktor.</blockquote>
| |
| Es ist dabei aber zu beachten, dass es ein Systemverhalten geben kann, das nicht direkt aus einem Use-Case für einen Aktor erkannt (abgeleitet) werden kann.
| |
|
| |
| Die Kritik an der Verwendung von Use Cases sieht folgende Gefahren. Use-Cases können zu einer funktionalen Betrachtungsweise führen und man vernachlässigt den objektorientierten Ansatz. Der Entwickler kann weiter den Blick auf die System- und Objektarchitektur verlieren und er könnte daher Design mit Anforderungen verwechseln. Die letzte Gefahr liegt darin, dass Anforderungen übersehen werden, die mit keinem offensichtlichen Aktor verbunden sind. Man sollte daher immer beachten, dass Use Cases zu einer disziplinierten objektorientierten Modellierung führen können, sie aber NICHT die Modellierung selbst sind.
| |
|
| |
| Use Cases besitzen aber auch eine „politische“ Komponente während eines Projektablaufs. Sie können helfen, Motivation, Verständnis für das Projekt zu erzeugen und die Bedeutung des Projekts zu verdeutlichen. Die Anforderungen, die sich aus Use-Cases ableiten lassen, zeigen nämlich WAS für WEN WICHTIG ist! Diese Information muss schnell, an alle Personen, die davon betroffen sind, und in jedem Zyklus des Entwicklungsprozesses geliefert werden. Das Ergebnis ist dann (hoffentlich), dass man Unterstützung für ein Projekt erhält und vielleicht auch dass ein Projekt nicht abgebrochen wird.
| |
Geschäftsprozessmodellierung
Ergänzend zu den bereits betrachteten Modellen der Prozess- und Ablaufmodellierung gibt es noch einige spezielle Geschäftsprozessmodelle. In dieser Lektion werden nun die Grundlagen von zwei der diesbezüglich wichtigsten Modelle erläutert. Diese Modelle dienen der organisatorischen Betrachtung von Geschäftsprozessen und werden auch von Nicht-Technikern eingesetzt. Sie dienen oft auch als gemeinsame Basis bei der Spezifikation der Anforderungen von IT-Systemen und ihrer Unterstützung der Geschäftsprozesse.
Ereignisgesteuerte Prozessketten (EPK)
Die Ereignisgesteuerten Prozessketten (EPK) wurden 1992 durch Keller, Nüttgens und Scheer entwickelt. Sie wurden von den Petri-Netzen abgeleitet und dienen der prozessorientierten Modellierung von Geschäftsprozessen. Sie sind Teil des Rahmenkonzeptes der Architektur integrierter Informationssysteme (ARIS) und dort im Bereich der Steuerungssicht angesiedelt. Zusätzlich zu den Prozessabläufen ermöglichen Sie in ihrer aktuellen Version auch direkte Verbindungen zur Daten- und Funktionssicht. Das ARIS-Konzept selbst wurde entwickelt, um die Vielzahl unterschiedlicher Methoden der Anwendungsentwicklung und Unternehmensentwicklung zu strukturieren. (Keller G., 1992, S. 3f)
Die "Ereignisgesteuerte Prozeßkette" stellt den zeitlich-logischen Ablauf von Funktionen und eine Verknüpfung der Elemente des Daten- und des Funktionsmodells dar. Sie ist somit eine zentrale Komponente innerhalb der Informationsmodellierung. (Keller G., 1992, S. 15)
Aufbau einer EPK
Eine EPK besteht aus Elementen, Pfaden und Operatoren. Der Prozess wird durch die möglichen Pfade beschrieben, welche zu Elementen hin und von ihnen weg führen. Mittels Operatoren können diese Pfade geteilt, parallelisiert und auch wieder zusammengeführt werden.
Die möglichen Elemente einer einfachen EPK sind:
- Ereignisse und
- Funktionen.
Ein Ereignis stellt dabei einen eingetretenen Zustand dar und ist damit eine passive Komponente des Systems. Funktionen werden von Ereignissen ausgelöst und damit gestartet. Sie können wiederum Ereignisse auslösen und so weiter. Eine Funktion stellt dabei eine bestimmte Tätigkeit dar, welche für den Prozess ausgeführt wird. Das bedeutet auch, dass auf ein Ereignis niemals ein Ereignis und auf eine Funktion keine Funktion folgen kann. (Keller G., 1992, S. 10f)
Die Pfade des Kontrollflusses werden als gestrichelte Linie dargestellt. Der Kontrollfluss entspricht dabei dem Prozessablauf. Pfade des Datenflusses werden durch durchgehende Linien repräsentiert. Dabei handelt es sich um die Verbindung von Informationsobjekten und Organisationseinheiten zu den Funktionen, welche später im Abschnitt 4.1.2 genauer beschrieben werden. Die grafische Darstellung von einem Ereignis, welches eine Funktion auslöst ist in Abbildung 48 dargestellt.
Abbildung 48 – EPK: Ereignis und Funktion
Der Prozessablauf wird über einen Token-Ansatz abgearbeitet. Das bedeutet, dass immer ganz bestimmte Teilpfade des Kontrollflusses aktiv sind, wobei es möglich ist, eine parallele Ausführung mehrerer Pfade durchzuführen, indem der aktuelle Token auf mehrere Teilpfade aufgeteilt wird. Ein Zusammenführen oder Synchronisieren mehrerer Pfade zu einem einzigen Pfad ist ebenfalls möglich. Diese Teilung und Zusammenführung erfolgt über logische Operatoren. Folgende Operatoren sind dabei möglich:
- exklusiver Oder-Operator (XOR),
- inklusiver Oder-Operator (OR) und
- Und-Operator (AND).
Die Darstellung der logischen Operatoren erfolgt mittels Kreissymbol mit dem jeweiligen Typ darin. Die Darstellungsformen der Operatoren-Typen sind in Abbildung 49 angeführt.
Abbildung 49 – EPK: Operatoren
Beim exklusiven Oder-Operator wird genau einer der Pfade ausgewählt und der Prozessfluss dort weitergeführt. Bei einem inklusiven Oder-Operator wird der Prozesspfad an einem oder mehreren möglichen Pfaden fortgesetzt. In beiden Fällen ist der eingeschlagene Weg von dem Eintreten des nachfolgenden Ereignisses abhängig. Ein Oder-Operator darf daher nur von einer Funktion weg zu mehreren Ereignissen führen aber nicht von einem Ereignis zu mehreren Funktionen. Anderenfalls wäre nicht eindeutig unter welchen Umständen (Ereignis) welcher Pfad gewählt werden soll.
Der Und-Operator kann sowohl nach einem Ereignis, als auch nach einer Funktion eingesetzt werden. Er teilt immer den aktuellen Pfad in mehrere parallel ausgeführte Pfade. Es ist somit damit auch möglich durch ein einzelnes Ereignis mehrere Funktionen auszulösen.
Werden die Operatoren für die Zusammenführung mehrerer Kontrollflüsse verwendet, gilt die oben beschriebene Logik ebenfalls. So werden beim inklusiven Oder-Operator mehrere Pfade zu einem zusammengeführt und beim exklusiven Oder-Operator einer aus mehreren Pfaden fortgesetzt. Beim Und-Operator wird abgewartet, bis alle eingehenden Kontrollflüsse vorhanden sind und dann mit dem ausgehenden Kontrollfluss fortgesetzt. Er kann daher für die Synchronisierung mehrerer Abläufe verwendet werden. Sollen mehrere Prozessflüsse an einer Stelle synchronisiert werden, jedoch getrennt weiterlaufen, kann dies mit zwei aufeinander folgenden Und-Operatoren geschehen. Diese Vorgehensweise ist im Beispiel in Abbildung 50 dargestellt.
Abbildung 50 – EPK: Synchronisation mehrerer paralleler Kontrollflüsse
Um in einer EPK die Ausführung eines Sub-Prozesses anzustoßen werden Prozesswegweiser eingesetzt. Diese ermöglichen die Auslagerung von komplexeren oder mehrfach genutzten Prozessteilen in eigene Prozesse. Der Prozesswegweiser repräsentiert dabei immer die komplette Ausführung des Sub-Prozesses. Das bedeutet, dass nach seinem Aufruf auf die Abarbeitung des aufgerufenen Prozesses gewartet, und der Prozessfluss danach hinter dem Prozesswegweiser wieder fortgesetzt wird. Das Symbol eines Prozesswegweisers ist das einer Funktion mit einem dahinter befindlichen Ereignis. Er wird als Funktionsaufruf behandelt und daher immer von einem Ereignis aufgerufen. Weiter folgt ihm auch immer ein Ereignis nach. Der Aufruf eines Prozesswegweisers ist in Abbildung 51 dargestellt.
Abbildung 51 – EPK: Prozesswegweiser
Erweiterte Ereignisgesteuerte Prozessketten (eEPK)
Die erweiterten Ereignisgesteuerten Prozessketten (eEPK) sind eine direkte Ergänzung der EPK um weitere Elemente. Dadurch ist es möglich das Prozessumfeld und Zuständigkeiten genauer zu beschreiben.
Die wesentlichen Zusatzelemente sind:
- Organisationseinheiten und
- Informationsobjekte.
Die Zusatzelemente werden mittels Informationspfaden, welche als Pfeile mit durchgehenden Linien gezeichnet werden, mit den zugehörigen Funktionen verbunden. Sie sind damit genau diesen Funktionen zugeordnet.
Die Organisationseinheiten repräsentieren die Prozessteilnehmer, welche die zugehörige Funktion durchführen. Prozessteilnehmer können bestimmte Organisationseinheiten oder Funktionen eines Unternehmens sein. Sie werden als Oval mit einem innenliegenden vertikalen Strich an der linken Seite gezeichnet und beinhalten den Namen des Prozessteilnehmers.
Informationsobjekte dienen der Darstellung von Daten, welche von der zugehörigen Funktion genutzt oder erstellt werden. Als Daten gelten hier jedoch alle Arten von Informationen, auch wenn sie nicht in elektronischer Form vorliegen. Die Darstellung eines Informationsobjektes geschieht in Form eines Rechtecks mit spitzen Ecken (im Gegensatz zu den abgerundeten Ecken der Funktion).
Eine Funktion mit zugehörigen Daten und einer Organisationseinheit ist in Abbildung 52 dargestellt.
Abbildung 52 – eEPK: Organisationseinheit und Informationsobjekt
Objektorientierte Ereignisgesteuerte Prozessketten (oEPK)
Bei den objektorientieren Ereignisgesteuerten Prozessketten handelt es sich um eine andere Form der Herangehensweise an die Modellierung. Im Gegenzug zur herkömmlichen, rein prozessbezogenen Betrachtung, überwiegt hierbei der Objektbezug. Das bedeutet insbesondere eine Definition von Objekten und ihrer Interaktionen. Die Geschäftsprozesse werden hierbei über die Abbildung der Objekte und ihrer Interaktion mittels ereignisgesteuerter Nachrichten realisiert. Die in dieser Form modellierten Objekte können daher auch als Geschäftsobjekte bezeichnet werden. (Scheer, Nüttgens, & Zimmermann, Objektorientierte Ereignisgesteuerte Prozeßkette (oEPK) - Methode und Anwendung, 1997, S. 16ff)
Zuerst werden die einzelnen Objektklassen modelliert, welche selbst Variablen und Methoden enthalten können. Für den Nachrichtenaustausch werden den Objekten weiter Ereignisse zugewiesen, welche dann im Prozessfluss verwendet werden können.
Zur Definition einer Objektklasse wird ein, vom EPK Prozessfluss getrenntes, Modell erstellt, welches die Objektklasse und ihre zugehörigen Funktionen und Instanzvariablen beinhaltet. Weiter werden alle möglichen Ereignisse angeführt, die von der Objektklasse ausgelöst werden können. Das Symbol der Instanzvariablen ist ein Rechteck, welches links und rechts mit einem Halbkreis abgeschlossen wird. Sie repräsentieren die Daten des Objektes. Die Funktionen des Geschäftsobjektes können auch als Methoden bezeichnet werden. Eine mögliche Modellierung einer oEPK Objektklasse ist in Abbildung 53 dargestellt.
Abbildung 53 – oEPK: Modell einer Objektklasse
Die Einbindung der Objektklasse in eine EPK geschieht direkt über das Objektklassen-Symbol. Es wird dabei wie eine Funktion eingesetzt, wird von Ereignissen aufgerufen und kann wiederum selbst Ereignisse auslösen. Die einzelnen Funktionen, Instanzvariablen und Ereignisse des Objektes werden hier nur angeführt, wenn sie an der jeweiligen Position der EPK gerade verwendet werden. Alle übrigen Komponenten werden ausgeblendet. Es werden daher auch nur die Folgeereignisse angeführt, welche an dieser Position ausgelöst werden können.
Beispiel einer eEPK
Im Beispiel, in Abbildung 54, soll der Prozess einer Kaffeezubereitung in einer Büroküche modelliert werden. Die Teilnehmer des Prozesses sind alle Mitarbeiter der Abteilung und ein Service-Verantwortlicher. Sobald ein Mitarbeiter einen Kaffee möchte, prüft er zuerst ob die Kaffeemaschine korrekt funktioniert. Ist dies der Fall, sucht er sich einen Kaffee (Espresso, Ristretto oder Lungo) aus und bereitet diesen zu. Nach der Zubereitung trinkt er den Kaffee und hat seinen Kaffeebedarf damit gestillt. Sollte die Kaffeemaschine nicht funktionieren, informiert er den für das Service verantwortlichen Kollegen. Dieser setzt die Kaffeemaschine wieder in Stand und informiert anschließend wieder die Mitarbeiter der Abteilung.
Abbildung 54 – eEPK Beispiel einer Kaffeeküche
Business Process Model and Notation (BPMN)
Die Business Process Model and Notation (BPMN) wurde ursprünglich von Stephen A. White entwickelt und 2004 von der Business Process Management Initiative (BPMI) veröffentlicht. Seit Februar 2011 gibt es die BPMN nun in ihrer aktuellen Version 2.0, welche offiziell von der Object Management Group (OMG) verabschiedet und publiziert wurde. BPMN dient der Modellierung von Prozessen und kann daher andere Strukturen, wie eine übergeordnete Prozesslandschaft und Ablauforganisationen, nicht abbilden. (Freund & Rücker, 2014, S. 8f, 22)
Alle Elemente und der Aufbau von BPMN 2.0 sind in der zugehörigen, 538 Seiten langen, Spezifikation (Object Management Group (OMG), 2011) genau definiert. Nachfolgend werden nun die davon wichtigsten Grundaspekte erläutert.
Aufbau der BPMN
Die BPMN kann in fünf Hauptelementtypen gegliedert werden (Freund & Rücker, 2014, S. 23):
- Flussobjekte,
- verbindende Objekte,
- Artefakte,
- Teilnehmer und
- Daten.
Die Flussobjekte beschreiben alle Entscheidungen, Aktivitäten und Ereignisse. Sie werden selbst wiederum über die verbindenden Objekte vernetzt und mit Hilfe der Artefakte beschrieben. Ergänzend können dann noch die Teilnehmer und relevanten Daten des Prozesses in das Modell eingefügt werden.
Generell wird, ähnlich wie bei den EPK, ein Token-Ansatz verwendet. Der Prozessfluss findet also entlang des definierten Pfades statt, welcher von einem Token durchlaufen wird. Dieser kann wiederum in mehrere parallele Token geteilt und umgekehrt wiederum zu einem einzelnen zusammengeführt werden.
Die möglichen Flussobjekte sind
- die Aktivität,
- das Event und
- das Gateway.
Die grafische Darstellung der Flussobjekte ist in Abbildung 55 ersichtlich.
Abbildung 55 – BPMN Flussobjekte
Die Aktivität beschreibt dabei eine konkrete Tätigkeit, die bei ihrem Aufruf durchgeführt wird. Diese kann in komplexeren Modellen wiederum selbst aus Unteraktivitäten bestehen. Auf diese Form der weiteren Untergliederung wird hier jedoch nicht weiter eingegangen. Eine Aktivität hat immer eine Bezeichnung und kann zusätzlich eine bestimmte Ausprägung haben. Diese wird in der linken oberen Ecke in Form eines Symbols angezeigt. Aktivitäten werden oft auch als Aufgaben bezeichnet, wenn sie selbst nicht mehr in Teilaufgaben teilbar sind. Ein Beispiel hierfür wäre die Zubereitung eines Kaffees mit einer Kaffeemaschine. Das „Zubereiten eines Espressos“ wäre eine Aktivität, da sie auch weiter in „Tasse unterstellen“ und „Espressotaste drücken“ geteilt werden könnte. Der Druck auf die Espressotaste hingegen wäre eine Aufgabe, da sie nicht weiter teilbar ist.
Eine Aktivität ohne spezielle Ausprägung wird als abstrakt bezeichnet. Die unterschiedlichen Ausprägungen und ihre Symbole sind in Abbildung 56 aufgelistet und beschrieben.
| Aktivitätsausprägung
|
Symbol
|
Beschreibung
|
| Service-Aktivität
|
Datei:Media/image15.png
|
wird durch ein automatiches System durchgeführt
|
| Sende-Aktivität
|
Datei:Media/image15.png
|
führt das Senden einer Nachricht durch (Erstellung und Versand)
|
| Empfangs-Aktivität
|
Datei:Media/image15.png
|
führt das Empfangen einer Nachricht durch (Empfang und Verarbeitung)
|
| Benutzer-Aktivität
|
Datei:Media/image16.png
|
wird durch einen oder mehrere Menschen durchgeführt
|
| Manuelle-Aktivität
|
Datei:Media/image16.png
|
wird durch einen oder mehrere Menschen manuell und ohne IT Unterstützung durchgeführt
|
| Geschäftsregel-Aktivität
|
Datei:Media/image16.png
|
führt eine BPMN Geschäftsregel aus (wird in dieser Lektion nicht weiter behandelt)
|
| Script-Aktivität
|
Datei:Media/image16.png
|
führt ein Script innerhalb der Prozessumgebung aus (wird in dieser Lektion nicht weiter behandelt)
|
Abbildung 56 – BPMN Aktivitäten mit Ausprägung (Object Management Group (OMG), 2011, S. 385, 430)
Weiter ist es möglich, über eine Aktivität einen Sub-Prozess aufzurufen. Damit kann das Modell vereinfacht und mehrfach ausgeführte Prozessabläufe zusammengefasst werden. Ein Sub-Prozess wird durch ein kleines Quadrat mit einem Pluszeichen in der Mitte des unteren Bereiches der Aktivität dargestellt. Der Inhalt des Sub-Prozesses wird in Form eines eigenen Pools modelliert, welcher in diesem Abschnitt weiter unten genauer beschrieben wird. Ein Beispiel für einen Sub-Prozess Aufruf ist in Abbildung 57 dargestellt.
Abbildung 57 – BPMN Sub-Prozesses Aufruf (Object Management Group (OMG), 2011, S. 418)
Ein Event ist ein bestimmtes Ereignis, welches eintreten und ausgelöst werden kann. Es kann dabei sowohl von außerhalb ausgelöst werden, als auch durch den modellierten Prozess selbst. Dabei wird zwischen Start-, Zwischen- und End-Events unterschieden. Ein Start-Event ist ein Ereignis, welches außerhalb des modellierten Prozesses ausgelöst wird und damit einen Einfluss auf einen Teil des Prozesses von außen hat. Start-Events werden daher auch zum Start des Prozesses eingesetzt. End-Events beenden einzelne Abläufe des Prozesses. Ist kein Teil des Prozesses mehr aktiv, da jeder Pfad in einem End-Event geendet hat, ist damit der gesamte Prozess beendet. Eine Ausnahme ist hierbei das End-Event vom Typ Terminierung, welches bei seinem Aufruf den gesamten Prozess beendet. Weiter gibt es noch Events, welche innerhalb des Prozesses ausgelöst werden und wiederum einen anderen Teil des eigenen Prozesses beeinflussen. Diese Events werden als Zwischen-Events bezeichnet.
Je nachdem um welchen Event Typ es sich handelt wird die Umrandung des Kreises anders dargestellt. Die unterschiedlichen Event-Typen sind in Abbildung 58 dargestellt.
Abbildung 58 – BPMN Event-Typen
Der Start eines Prozessflusses wird immer durch ein oder mehrere Start-Events begonnen und durch ein oder mehrere End-Events beendet.
Zusätzlich kann der Typ eines Events durch einen zugehörigen Auslöser oder ein Resultat beschrieben werden. Die wichtigsten Auslöser oder Resultate sind:
- Nachricht,
- Signal,
- Timer,
- Bedingung,
- Verknüpfung und
- Terminierung.
Bei einer Nachricht handelt es sich um eine Benachrichtigung von außen an den Prozess oder umgekehrt, sowie möglicher Benachrichtigungen zwischen Aktivitäten. Signale sind, im Gegensatz zu Nachrichten, Benachrichtigungen welche ohne bestimmte Empfänger an alle gerichtet sind, die sie auffangen können. Timer erlauben, zwischen den Aktivitäten ein bestimmtes Zeitintervall oder einen Zeitpunkt abzuwarten und Start-Events in einem bestimmten Intervall oder Zeitpunkt zu starten. Bei Bedingungen handelt es sich um Events, welche unter einer bestimmten Bedingung ausgeführt werden oder auf eine bestimmte Bedingung warten. Bei den Verknüpfungen handelt es sich um einen Sonderfall von Events, welche eine grafische Möglichkeit darstellen den Prozessfluss innerhalb des Diagramms zu unterbrechen und an einer anderen Stelle fortzusetzen. Dabei ist es wichtig, die Verknüpfung an beiden Stellen im Diagramm gleich zu benennen. Die Terminierung beendet den gesamten Ablauf unmittelbar nach ihrem Eintreten, egal ob noch parallele Aktivitäten offen sind, oder nicht.
In Tabelle 7 findet sich eine Tabelle der wichtigsten Symbole der Auslöser und Resultate und in welchen Event-Typen ihre Verwendung zulässig ist.
Tabelle 7 – BPMN Event Auslöser und Resultate (Object Management Group (OMG), 2011, S. 261)
Gateways dienen dem Ablauffluss zwischen den Aktivitäten untereinander und zwischen Aktivitäten und Events. Sie ermöglichen den Ablauf zu teilen und wieder zusammenzuführen. Der Ablauf findet dabei immer nach dem Token-Ansatz statt. Das bedeutet, dass es immer einen bestimmten Teil des Pfades gibt, der gerade aktiv ist. Durch die Teilung des Prozess-Flusses mittels Gateways können mehrere parallele Abarbeitungen erfolgen und auch bestimmte Pfade unter bestimmten Bedingungen ausgewählt werden.
Die wichtigsten Gateway-Typen sind:
- Exklusives Oder (Entweder-Oder Verbindung),
- Inklusives Oder (Und-Oder Verbindung),
- Parallel (Und Verbindung) und
- Komplex (Kombination mehrerer Verbindungsarten).
Mit einem exklusiven Oder-Gateway werden mögliche Pfade vorgegeben, von denen genau einer eingeschlagen werden kann. In Abbildung 59 ist die mögliche Verwendung von Gateways mit exklusivem Oder dargestellt. Hier löst des Event Start die Aktivität 1 aus und wird nachher durch das exklusive Oder geteilt. Je nachdem ob Bedingung 1 oder Bedingung 2 erfüllt ist, wird der Ablauf bei Aktivität 2 oder Aktivität 3 fortgesetzt. Damit beide Aktivitäten am Event Ende abschließen können, werden die Pfade nach den beiden möglichen Aktivitäten wieder über ein exklusives Oder zusammengeführt. Grundsätzlich werden Pfade immer mit demselben Gateway-Typ zusammengeführt, mit dem sie auch geteilt wurden.
Datei:Media/image23.pngDatei:Media/image23.png
Abbildung 59 – BPMN: Exklusives Gateway
Bei einem inklusiven Oder-Gateway werden mögliche Pfade vorgegeben, von denen einer oder mehrere eingeschlagen werden können. In Abbildung 60 ist die mögliche Verwendung von Gateways mit inklusivem Oder dargestellt. Hier löst des Event Start ebenfalls die Aktivität 1 aus und wird nachher durch das inklusive Oder geteilt. Je nachdem ob Bedingung 1 oder Bedingung 2, oder beide Bedingungen, erfüllt sind, wird der Ablauf bei Aktivität 2, Aktivität 3 oder bei beiden Aktivitäten parallel fortgesetzt. Damit beide Aktivitäten am Event Ende abschließen können, werden die Pfade nach den beiden möglichen Aktivitäten wieder über ein inklusives Oder zusammengeführt. Das zusammenführende inklusive Oder wartet, je nach der Anzahl der eingeschlagenen Pfade des verteilenden inklusiven Oder auf nur eine oder beide eingehenden Aktivitäten.
Abbildung 60 – BPMN: Inklusives Gateway
Damit es bei der Aufteilung der Pfade nicht zum Stillstand des Gesamtablaufes kommen kann wird empfohlen, bei Oder-Bedingungen, einen zusätzlichen Standardfluss ohne Bedingung zu modellieren welcher ausgeführt wird, wenn keine der übrigen Bedingungen zutrifft (ähnlich dem Default-Zweig eines Select-Case Statements). (Freund & Rücker, 2014, S. 39f)
Bei einem Parallel-Gateway werden mögliche Pfade vorgegeben, welche alle gleichzeitig, ohne zusätzliche Bedingungen, eingeschlagen werden. In Abbildung 61 ist die mögliche Verwendung von Parallel Gateways dargestellt. Hier löst des Event Start wieder die Aktivität 1 aus und wird nachher durch das Parallel Gateway geteilt. Der Ablauf wird daher parallel bei Aktivität 2 und Aktivität 3 fortgesetzt. Damit der Prozess-Fluss, nach der Ausführung beider Aktivitäten, am Event Ende abschließen kann, werden die Pfade wieder über ein Parallel Gateway zusammengeführt. Das bedeutet, dass das Gateway abwartet, bis beide seiner Eingangspfade, nach dem Abschluss aller parallel ausgeführten Aktivitäten, aktiv sind und erst dann die Ausführung mit der Auslösung des Events Ende fortsetzt.
Abbildung 61 – BPMN: Parallel Gateway
Ein komplexes Gateway kann zur Kombination mehrerer verketteter Gateway-Arten in einem einzelnen Gateway genutzt werden. Die Aktivierung der einzelnen Pfade ist dabei von einer rein verbalen Bedingung abhängig, welche beliebig komplex sein kann (z.B.: zwei Aktivitäten aus fünf möglichen müssen ausgeführt werden). Genauso verhält es sich auch beim Zusammenführen paralleler Pfade. In Abbildung 62 ist die mögliche Verwendung von komplexen Gateways dargestellt. Hier löst des Event Start wieder die Aktivität 1 aus und wird nachher durch das Gateway geteilt, wobei zwei aus fünf möglichen Aktivitäten ausgeführt werden müssen. Nach dem Abschluss der beiden Aktivitäten wird dann die Ausführung wieder mit der Auslösung des Events Ende fortsetzt. Die verbale Beschriftung der Gateways erfolgt dabei direkt mittels Freitext-Anmerkungen.
Abbildung 62 – BPMN: komplexes Gateway
Wie im vorherigen Beispiel der komplexen Gateways bereits eingesetzt, gibt es die Möglichkeit bestimmte Freitext-Anmerkungen zu einzelnen Elementen zu machen, indem eine eckige Klammer mit einer gestrichelten Linie mit dem jeweiligen Element verbunden wird. Hinter die Klammer wird dann die Freitext-Anmerkung geschrieben. Diese Anmerkungen gehören zur Gruppe der Artefakte.
Ein weiteres Artefakt ist die Gruppierung. Dabei können mehrere Teile des Diagramms durch ein gepunktet-gestricheltes Rechteck eingefasst werden, um ihre logische Zusammengehörigkeit zu verdeutlichen. Dies hat jedoch keinerlei Auswirkung auf die Funktionalitäten des Prozesses. In das System zusätzlich eingebrachte eigene Symbole gelten auch als Artefakte und haben ebenfalls keine Auswirkung auf den Ablauf. Ein Beispiel für eine Gruppierung ist in Abbildung 63 dargestellt. Hier sind die Elemente Aktivität 2 und Aktivität 3 zu einer Gruppe mit der Bezeichnung Gruppe 1 zusammengefasst. Auf den Ablauf des Modells hat dies jedoch keinerlei Auswirkung.
Abbildung 63 – BPMN: Gruppierung
Die Teilnehmer eines Prozesses werden über Pools mit darin optional enthaltenen Lanes dargestellt. Dabei ist zu beachten, dass es sich bei einem Teilnehmer nicht immer um eine Person, sondern auch um eine Personengruppe, Rolle, Organisationseinheit oder auch um ein bestimmtes System handeln kann. Innerhalb eines Pools werden all die Prozessteile dargestellt, die von seinen Teilnehmern ausgeführt werden. Innerhalb eines Pools können weitere Unterteilnehmer definiert werden, welche den definierten Teilnehmerkreis weiter unterteilen. Diese Unterteilungen werden als Lanes bezeichnet und können wiederum weiter ineinander verschachtelt werden. Wichtig ist dabei, dass diese Unterteilnehmer innerhalb des übergeordneten Teilnehmerkreises an demselben Prozess beteiligt sind. Eine Aktivität wird dabei immer in der Lane des Teilnehmers eingezeichnet, der sie durchführt. Soll eine Aktivität von mehreren Teilnehmern durchgeführt werden, muss sie in jeder Lane separat eingezeichnet werden. Eine Aktivität darf nicht über mehrere Lanes hinweg gezeichnet werden. Der Grund dieser Regel liegt in der Eindeutigkeit der Aktivitätsdurchführung und Zuständigkeit. Wird beispielsweise eine Aktivität entweder von Teilnehmer 1 oder Teilnehmer 2 ausgeführt, wird sie vorab über ein exklusives Oder-Gateway in zwei idente Aufgaben in beiden Lanes aufgeteilt und anschließend wieder zusammengeführt. Damit ist sichergestellt, dass für ihre Ausführung genau einer der beiden Teilnehmer erforderlich ist. In Abbildung 64 ist ein einfaches Prozessdiagramm dargestellt, welches das Zusammenspiel mehrerer Lanes in einem Pool zeigt. Hier führt nach dem Start des Prozesses Teilnehmer 1 die Aktivität 1 aus. Danach werden Aktivität 2 von Teilnehmer 2 und Aktivität 3 von Teilnehmer 3 gestartet. Sobald beide Aktivitäten abgeschlossen sind, wird noch Aktivität 4 von Teilnehmer 1 ausgeführt und der Prozessfluss danach abgeschlossen. Es wurde in diesem Beispiel weiter davon ausgegangen, dass Aktivität 2 und Aktivität 3 thematisch zusammengehören und daher eine Gruppierung eingezeichnet. Dies hat jedoch keinen Einfluss auf den Ablauf und dient einzig der Übersichtlichkeit.
Abbildung 64 – BPMN: Pool mit Lanes
Gibt es in einem Prozessdiagramm mehrere Pools, stellen diese getrennte Teilnehmerkreise mit getrennten Prozessabläufen dar. Es handelt sich dabei um kollaborative Prozesse. Hierbei ist zu beachten, dass die Prozesse nicht direkt über Gateways oder Aktivitäten miteinander verknüpft werden dürfen, da sie in getrennten Systemen stattfinden. Zur Interaktion mehrerer Pools werden Nachrichtenflüsse verwendet. Diese werden als gerichtete gestrichelte Linie dargestellt. Dabei muss beachtet werden, dass ein Gateway keine direkten Aufrufe von Aktivitäten in einem anderen Pool durchführen darf und auch nicht mit Gateways des anderen Pools verknüpft werden kann. Befindet sich ein Nachrichtenfluss direkt zwischen zwei Aktivitäten, handelt es sich um eine Abstimmung der Aktivitäten mittels Nachrichten. Zwischen einer Aktivität und einem Ereignis wird ein Ereignis ausgelöst oder empfangen. Zusätzlich ist es möglich, nicht mit einem Prozessteil eines Pools, sondern mit seinen Teilnehmern zu interagieren. Dazu wird ein Nachrichtenfluss direkt zur Außenkante des gewünschten Poos gezeichnet. Damit ist es auch möglich, Nachrichten an und von Teilnehmern darzustellen, deren Prozess inhaltlich nicht modelliert wird.
Die unterschiedlichen Formen von Nachrichtenflüssen sind in Abbildung 65 dargestellt. Hier gibt es zwei verschiedene Prozessabläufe zweier unterschiedlicher Teilnehmerkreise und damit unterschiedlicher Pools. Der Teilnehmerkreis 1 teilt sich selbst wiederum in zwei unterschiedliche Teilnehmer, welche mittels Lanes in den Pool integriert sind. Der erste Nachrichtenfluss findet zwischen Aktivität 1 und dem Startevent im Pool von Teilnehmerkreis 2 statt. Dabei wird durch die Ausführung von Aktivität 1 eine Nachricht ausgelöst, welche gleichzeitig auch der Start-Event von Teilnehmerkreis 2 ist. Der nächste Nachrichtenfluss geschieht zwischen Aktivität B und Aktivität 3. Hier benötigt Aktivität 3 Informationen aus Aktivität B. Der letzte Nachrichtenfluss geschieht durch Ausführung von Aktivität 4. Diese benachrichtigt jedoch kein Element in Teilnehmerkreis 2, sondern den Teilnehmerkreis 2 selbst.
Datei:Media/image25.png
Abbildung 65 – BPMN: Mehrere Pools und Nachrichtenflüsse
Web Service Business Process Execution Language (WS-BPEL)
Bei der Web Service Business Process Execution Language (WS-BPEL) handelt es sich um eine Möglichkeit, die in der BPMN modellierten Prozesse in einem technischen Prozessmodell abzubilden. Dazu wird eine XML Struktur verwendet, welche viele der BPMN Elemente und ihre Interaktionen beinhaltet. Das Hauptaugenmerk liegt hierbei in der Zusammenführung von Webservices zu einem integrierten Prozess. WS-BPEL war ursprünglich der direkte Vorgänger von BPMN und ist durch seine spezielle Ausrichtung, hin zu XML Webschnittstellen, sehr in seinen Anwendungsmöglichkeiten beschränkt. (Freund & Rücker, 2014, S. 231f)
In der BPMN 2.0 Spezifikation sind die Überführungen von der BPMN zur WS-BPEL im Detail beschrieben. (Object Management Group (OMG), 2011, S. 445ff)
Beispiel eines BPMN
In diesem Beispiel soll der Prozess einer Kaffeezubereitung in einer Büroküche modelliert werden. Die Teilnehmer des Prozesses sind alle Mitarbeiter der Abteilung. Diese untergliedern sich in die Mitarbeiter, die Kaffee trinken wollen, und den Mitarbeiter, der ebenfalls für die Wartung der Kaffeemaschinezuständig ist.
Sobald ein Mitarbeiter einen Kaffee möchte, prüft er zuerst ob die Kaffeemaschine korrekt funktioniert. Ist dies der Fall, sucht er sich einen Kaffee (Espresso, Ristretto oder Lungo) aus und bereitet diesen zu. Nach der Zubereitung trinkt er den Kaffee und hat seinen Kaffeebedarf damit gestillt. Sollte die Kaffeemaschine nicht funktionieren informiert er den Service-Verantwortlichen der Abteilung. Dieser überprüft wiederum die Kaffeemaschine hinsichtlich ihrer möglichen Probleme. Ist sie verkalkt, entkalkt er sie, fehlen Bohnen, füllt er Bohnen nach und wenn sie defekt ist, beauftragt er den Hersteller-Service mit einer Reparatur. Alle Probleme können auch gleichzeitig vorhanden sein, daher ist es auch möglich, dass er mehrere der Servicetätigkeiten parallel vornimmt. Im Falle eines Gerätedefektes wird der Service-Verantwortliche wieder vom Hersteller-Service informiert, sobald die Kaffeemaschine repariert ist. Sind alle Servicearbeiten beendet, und die Maschine damit wieder einsatzbereit, informiert der Service-Verantwortliche Kollege die Mitarbeiter der Abteilung. Stellt er hingegen fest, dass überhaupt kein Problem besteht, informiert er direkt die Mitarbeiter der Abteilung, ohne Servicetätigkeiten durchzuführen.
Datei:Media/image23.pngDatei:Media/image23.pngDatei:Media/image23.pngDatei:Media/image25.pngDatei:Media/image25.pngDatei:Media/image25.png
Abbildung 66 – BPMN Beispiel Kaffeeküche
