Grundlagen der Modellierung - Gesamt
Peter Völkl (Jahrgang 1984) startete seine berufliche Laufbahn nach dem Abschluss seiner Ausbildung an der HTBLuVA für EDV und Organisation im Jahr 2005 als Softwareentwickler beim Österreichischen Roten Kreuz. 2008 übernahm er die Leitung einer Abteilung der Blutspendezentrale für Wien, Niederösterreich und Burgenland, die für die IT-Services des Blutbereichs verantwortlich war. Neben der Führung der Abteilung lagen seine Schwerpunkte in der Koordination und Überwachung von IT-Projekten und -Prozessen sowie in der Entwicklung, Testung und Validierung von IT-Systemen.
Parallel zu seiner beruflichen Tätigkeit begann er 2010 das Bachelorstudium Wirtschaftsinformatik an der FernFH, das er 2012 abschloss. Im Anschluss absolvierte er die Masterstudiengänge Wirtschaftsinformatik an der FernFH sowie Information Management and IT Security an der FH Technikum Wien, die er 2014 erfolgreich beendete.
Von November 2014 bis 2024 war Peter Völkl als wissenschaftlicher Mitarbeiter an der FernFH tätig. Ab Juli 2016 übernahm er die Studiengangsleitung des Masterstudiengangs Wirtschaftsinformatik und leitete seit 2023 zudem das Institut für Informationstechnologie und Wirtschaftsinformatik.
Seit Oktober 2024 ist er Kaufmännischer Leiter der Blutspendezentrale für Wien, Niederösterreich und Burgenland im Österreichischen Roten Kreuz.
Einleitung
Modellierung und Modellierungssprachen sind ein essentieller Bestandteil der meisten Themenfelder der Wirtschafsinformatik. Die Modellierung bildet dabei einen existierenden, erwarteten oder geplanten Sachverhalt in Form eines Modells ab. Dabei handelt es sich um eine Darstellung, welche der betroffenen Zielgruppe und Zielsetzung angepasst wurde. In den nachfolgenden Lektionen werden der Modellbegriff und die ordnungsgemäße Modellierung, sowie die Grundlagen einzelner, in der Wirtschafsinformatik besonders relevanter, Modellierungsformen erläutert.
Der Modellbegriff
Bei einem Modell handelt es sich um eine vereinfachte Darstellung der Realität oder ihres Soll-Zustandes. Durch diese Abstraktion ist eine genauere Betrachtung oder Planung bestimmter Einzelaspekte möglich. Es betrachtet nur so viele Details wie nötig sind, um das zugrunde liegende Problem vollständig zu beschreiben. Der Begriff „Modell“ leitet sich aus dem lateinischen Wort „modulus“ ab und bezeichnete einen Maßstab im Bereich der Architektur. Laut dem deutschen Duden Fremdwörterbuch (2010), bedeutet Modell: Objekt, Gebilde, das die inneren Beziehungen und Funktionen von etwas abbildet bzw. [schematisch] veranschaulicht [und vereinfacht, idealisiert].
Für Wirtschaftsinformatiker und Wirtschaftsinformatikerinnen gehören Modelle und Modellierungstechniken zum unumgänglichen Handwerkszeug, insbesondere die Modelle, die in Informationssystemen abgebildet werden und jene, die wir in der Softwareentwicklung verwenden.
Modelle gibt es nicht nur in der Wirtschaftsinformatik, sondern auch in allen anderen Themenfeldern der Wissenschaft, Forschung und Entwicklung. So werden beispielsweise in der Wirtschaftsinformatik Datenmodelle verwendet und anatomische Modelle in der Medizin.
Die gängigen Modelle in der Wirtschaftsinformatik sind:
- Datenmodelle,
- Prozess- und Ablaufmodelle,
- Geschäftsprozessmodelle und
- objektorientierte Modelle.
Auf diese vier speziellen Modelle und ihre gängigsten Ausprägungen wird in den Lektionen Datenmodellierung bis Objektorientierte Modelle im Detail eingegangen.
Auch die Erstellung eines Test- oder Entwicklungssystems in der Software- und Systementwicklung ist ein (Soll-)Modell des Echtsystems. Meist hat es jedoch einen sehr geringen Abstrahierungsgrad, da es dem Echtsystem so nahe wie möglich kommen soll.
Die richtige Wahl eines Modells ist essentiell für den Erfolg der gewünschten Betrachtung, da es durch eine zu starke oder falsche Abstraktion der Darstellung auch zu fehlerhaften Annahmen und Resultaten führen kann.
Jedes Modell lässt sich selbst wiederum in einem Metamodell beschreiben, welches die Modellierung selbst definiert. Ein Metamodell definiert somit die einzelnen Bausteine eines Modells und wie sie anzuwenden sind.
Die drei Hauptmerkmale des allgemeinen Modellbegriffs nach Herbert Stachowiak, dem Begründer der allgemeinen Modelltheorie, sind (Stachowiak, 1973, S. 131ff):
- Abbildungsmerkmal: Modelle sind Abbildungen oder Repräsentationen natürlicher oder künstlicher Objekte, die selbst wiederum Modelle sein können. Es handelt sich dabei auch um die Zuordnung von Original-Attributen zu Modell-Attributen.
- Verkürzungsmerkmal: Modelle bestehen, in der Regel, nicht aus allen, sondern nur aus den relevanten, Attributen des betrachteten Objektes. Um die korrekten Attribute für ein Modell auszuwählen ist sowohl das Wissen über alle möglichen Attribute des Originalobjektes als auch über die Attribute des Modells notwendig.
- Pragmatisches Merkmal: Modelle sind nicht alleine einem Zweck, sondern auch einem bestimmten Anwenderkreis und Zeitraum zugeordnet. Eine pragmatisch vollständige Bestimmung des Modellbegriffs hat nicht nur die Frage zu berücksichtigen, wovon etwas Modell ist, sondern auch, für wen, wann und wozu bezüglich seiner je spezifischen Funktionen es Modell ist.
Ein Beispiel für ein einfaches Modell und seine Attribute ist das eines Smartphones:
Je nach Abstrahierungsgrad ändern sich die mögliche Darstellung und die relevanten Attribute. Eine mögliche Aufstellung der Attribute und Abbildungen unterschiedlicher Abstrahierungsgrade ist in der Tabelle "Einfaches Modell eines Smartphones" dargestellt.
Tabelle – Einfaches Modell eines Smartphones
| Anwendungsfall: | Technischer Aufbau eines konkreten Smartphones | Abbildung eines konkreten Smartphones | Piktogramm für Smartphone |
|---|---|---|---|
| Attribute: |
|
|
|
| Abbildung: |
Modellbildung und Anforderungen an ein Modell
Bei der Modellbildung geht es um die ausreichende Abbildung eines realen Systems zur Beschreibung einer bestimmten Fragenstellung oder eines Zustandes. Dazu können entweder bestehende Modelle verwendet werden, oder ein eigenes, geeignetes, Metamodell geschaffen werden. Meist handelt es sich bei den gängigen Modellierungsaufgaben in der Wirtschaftsinformatik jedoch um Situationen, in denen bestehende Modellarten zur Anwendung kommen können und sollten. Die Verwendung eines weit verbreitenden, und im eigenen Fachbereich allgemein bekannten, Modells führt zu einem schnelleren Verständnis für alle beteiligten Personen.
Die Modellbildung lässt sich generell in vier Schritten beschreiben und durchführen (Oeser, 2012, S. 7):
- Schritt 1: Vereinfachung und Formulierung des Problems
- Schritt 2: Formalisierung und Quantifizierung des Problems
- Schritt 3: Verarbeitung des Datenmaterials und Erstellung des Modells
- Schritt 4: Interpretation und Rückschluss auf den ursprünglichen Sachverhalt
In Schritt 1 und 2 wird deutlich, dass die Anforderungen an ein Modell durch die Formulierung des zugrunde liegenden Problems definiert werden. Dieser Planungsschritt ist sehr wichtig, da die Modellauswahl für den weiteren Erfolg der Modellierung, und der damit verbundenen Behandlung der Problemstellung, essentiell ist.
Im 4. Schritt wird die Erfüllung der Zielsetzung des Modells nochmals überprüft und damit sichergestellt, dass es den Sachverhalt problemadäquat widerspiegelt.
Der Modellierer hat, durch seine Tätigkeit, eine hohe Verantwortung gegenüber der Zielsetzung des Modells. Durch eine zu hohe Abstrahierung kann es zu Fehlern in allen, anhand des Modells abgeleiteten, Folgerungen kommen. Diese Fehler wirken sich dann auf alle Bereiche aus, welche das Modell einsetzen. Wesentliche Fehler können in der Praxis auch sehr schlimme Folgen haben, wie das nachfolgende Beispiel beschreibt.
|
22.09.2006: Bei dem schweren Transrapid-Unglück im emsländischen Lathen sind 23 Menschen getötet worden. Das teilte die Polizei am Freitag abend mit. Zehn Menschen sollen die Katastrophe verletzt überlebt haben. Der Transrapid war am Vormittag auf einen Reinigungswagen geprallt. [1] Der Transrapid nutzt eine neue Antriebsform und ein spezielles Leitsystem mit einigen Sicherheitsmaßnahmen. Der Zug wird durch Magnete in der Schiene bewegt. Weiter umgreift das Fahrwerk des Zuges die Schiene und haltet ihn in Position, was wiederum ein entgleisen verhindert. Zusätzlich ist jeder Zug mit einem Ortungssystem ausgestattet, welches seine Daten kontinuierlich mit dem Leitsystem der Streckenanlage abgleicht. Ein Zusammenstoß zweier Züge ist daher, zumindest dem Modell nach, durch die zentrale Steuerung des Streckenantriebs und die Positionsbestimmung nicht möglich. Das System galt daher als enorm sicher. Leider gab es in diesem Modell eine Komponente, welche nicht beachtet wurde. Die Streckenfahrzeuge und Reinigungswagen sind mit herkömmlichen Dieselantrieben ausgestattet und verfügten über keine Ortungssysteme. Daher war es auch möglich, dass ein Reinigungsfahrzeug übersehen wurde und in dessen Folge 23 Menschen starben. |
Die Grundsätze ordnungsmäßiger Modellierung (GoM)
Bei den Grundsätzen ordnungsgemäßer Modellierung (GoM) handelt es sich um semantische Empfehlungen zur bedarfsgerechten Informationsmodellierung. Damit wurde eine bewusste Einschränkung der Modellierungsfreiheit, zugunsten der Zielgerichtetheit der Modellierung selbst, eingeführt. Dies soll wiederum die Modellqualität erhöhen. Die GoM wurden von Becker, Rosemann und Schütte, in Anlehnung an den Grundsätzen ordnungsgemäßer Buchführung (GoB), entwickelt. (Becker, Rosemann, & Schütte, 1995, S. 437)
Die GoM definieren einen Ordnungsrahmen, bestehend aus sechs Grundsätzen, welchen wiederum ein Metamodell zugrunde liegt, in dem die einzelnen GoM Objekte, Attribute und ihre Beziehungen untereinander definiert werden (Becker, Rosemann, & Schütte, 1995, S. 437ff):
- Grundsatz der Richtigkeit,
- Grundsatz der Relevanz,
- Grundsatz der Wirtschaftlichkeit,
- Grundsatz der Klarheit,
- Grundsatz der Vergleichbarkeit und dem
- Grundsatz des systematischen Aufbaus.
Zusammengefasst sollen sie die Qualität von Informationsmodellen sicherstellen.
Grundsatz der Richtigkeit
Ein Modell kann sowohl semantisch, als auch syntaktisch richtig sein. Die syntaktische Richtigkeit bezieht sich dabei auf die korrekte Einhaltung der Vorgaben des Metamodells. Bei der semantischen Richtigkeit handelt es sich um die korrekte Abbildung des Modellierungsobjektes. Dies bedeutet nicht nur, dass das Modellierungsobjekt, dem Zweck entsprechend, vollständig abgebildet sein muss, sondern auch, dass es in sich keine Wiedersprüche aufweisen darf. Die Richtigkeit beinhaltet auch die eindeutige und korrekte Benennung von modellierten Objekten. Hierbei sollen Synonyme [2] und Homonyme [3] vermeiden werden.
Grundsatz der Relevanz
Bei der Modellierung müssen die mit ihr bezweckten Ziele eingehalten werden. Die in dem Modell enthaltenen Elemente und Beziehungen sind relevant, wenn das Modellierungsziel bei ihrer Reduzierung nicht mehr erfüllt werden würde. Das Modell muss sich wieder in eine Beschreibung des beschriebenen Objektes zurückführen lassen, ohne für die Betrachtung relevante Aspekte zu verlieren.
Grundsatz der Wirtschaftlichkeit
Der Grundsatz der Wirtschaftlichkeit limitiert die Tiefe und den Umfang eines Modells hinlänglich der, durch die Modellierung selbst, entstehenden Kosten. Es handelt sich dabei um eine Abwägung zwischen dem, durch die Modellierung entstehenden, Nutzen durch eine bessere Abbildbarkeit des zugrunde liegenden Problems und der Verbesserung der Interaktion zwischen den Modellnutzern und den Kosten, die durch die Modellierung entstehen. Je umfangreicher und tiefergehend ein Modell gebildet wird, desto mehr Aufwand muss in seine Erstellung investiert werden.
Grundsatz der Klarheit
Die Anwendbarkeit des Grundsatzes der Klarheit ist, ähnlich der Relevanz, stark von den Anwendern des Modells abhängig. So ist es nötig, die Darstellung eines Modells der Zielgruppe anzupassen. Analog zur syntaktischen Richtigkeit ist auch eine klare Darstellung des Modells essentiell. Dabei geht es insbesondere um die verwendeten Symbole auf Ebene des Metamodells, als auch um die Anordnung der Symbole innerhalb des Modells selbst. Dieser Grundsatz kann beispielsweise bedeuten, dass ein sehr komplexes Modell in weitere Abstrahierungsebenen geteilt werden muss, um für den Anwender verständlich zu bleiben. Hierfür werden meist die Möglichkeiten von Substitutionen und Detailmodellen geschaffen.
Grundsatz der Vergleichbarkeit
Ähnlich dem Grundsatz der Richtigkeit wird beim Grundsatz der Vergleichbarkeit in eine syntaktische und eine semantische Vergleichbarkeit unterschiedenen. Die beiden Grundsätze der Richtigkeit und Vergleichbarkeit lehnen sich dabei auch aneinander an. Bei der syntaktischen Vergleichbarkeit handelt es sich um eine Vergleichbarkeit unterschiedlicher Modelle, mit derselben zugrunde liegenden Modellierungsanforderung. Dadurch soll auch eine Überführung von Modellen mit unterschiedlichen Metamodellen ermöglicht werden. Die semantische Vergleichbarkeit bezieht sich auf die inhaltliche Vergleichbarkeit. Damit soll der Vergleich unterschiedlicher Modelle zueinander ermöglicht werden.
Grundsatz des systematischen Aufbaus
Bei in unterschiedlichen Sichten aufgebauten Modellen müssen die Sichten untereinander konsistent sein. Das bedeutet, dass die Bezüge der unterschiedlichen Sichten zueinander vorhanden sein müssen. So muss beispielsweise ein Ablaufmodell, welches auf ein Datenmodell referenziert, auch sicherstellen, dass das entsprechende Datenmodell entsprechend modelliert ist und umgekehrt. Um hierbei alle relevanten Sichten zu integrieren, liegen solchen Modellen übergreifende Architekturkonzepte zu Grunde.
Erweiterung der GoM
Die eingeführten Grundsätze ordnungsgemäßer Modellierung wurden von ihrem Mitbegründer Reinhard Schütte in Form der „neuen Grundsätze ordnungsgemäßer Modellierung“ überarbeitet. Diese erweiterten Grundsätze weichen von den herkömmlichen in einigen Teilen ab. Das Ziel der Überarbeitung war, die theoretische Begründung und die praktische Prüfbarkeit der Grundsätze zu verbessern.
Diese „neuen Grundsätze ordnungsgemäßer Modellierung“ sind (Schütte, 1997):
- Grundsatz der Konstruktionsadäquanz,
- Grundsatz der Sprachadäquanz,
- Grundsatz des systematischen Aufbaus,
- Grundsatz der Klarheit und der
- Grundsatz der Vergleichbarkeit.
Die erweiterten Grundsätze selbst werden aus, als allgemeingültig erachteten, Zwecken abgeleitet, welche in Abbildung 1 dargestellt sind.
Dabei unterscheiden sie sich primär in zwei Grundsätzen, von den ursprünglichen GoM:
- Grundsatz der Konstruktionsadäquanz und der
- Grundsatz der Sprachadäquanz.
Diese beiden sollten den Grundsatz der Richtigkeit und den Grundsatz der Relevanz ersetzen. Inhaltlich wurden jedoch auch bei den anderen Grundsätzen einige Ergänzungen durchgeführt.
Der Grundsatz der Konstruktionsadäquanz ist dabei als wichtigster Grundsatz definiert. Hierbei wird der Nutzen des Modells, für seinen jeweiligen Modellierungszweck, in den Vordergrund gestellt und der Konsens der Modellersteller herangezogen, da sie bewerten können, ob der Abstrahierungsgrad des Modells die Realität für die Aufgabenstellung angemessen abbildet. Es muss somit zwischen den Anwendern eine Einigkeit über die, ausreichend durch das Modell abgebildete, Problemstellung und die Art der gewählten Darstellung bestehen. Auch muss ein Konsens bezüglich einheitlicher Namenskonventionen herrschen. Ein inhaltlich identes Attribut oder Objekt muss auch in allen Modellen dieselbe Bezeichnung haben.
Der Grundsatz der Sprachadäquanz beschreibt dabei die Spracheignung und Sprachrichtigkeit in Relation zum Modellsystem. Die Spracheignung bezieht sich auf die Auswahl der geeigneten Modellierungstechnik für den jeweiligen Modellierungszweck. Die Sprachrichtigkeit bezieht sich dagegen auf die korrekte Anwendung der, im Metamodell definierten, Sprachsyntax.
Diese neuen GoM werden jedoch, im Gegensatz zu ihrer ursprünglichen Version, kaum angewendet, obwohl sie sich durch eine hohe theoretische Begründung und praktische Prüfbarkeit auszeichnen.
Datenmodellierung
Bei der Datenmodellierung geht es um die zweckmäßige und effiziente Strukturierung von Daten in Informationssystemen. Die Modelle behandeln unterschiedliche Arten von Speicheranwendungen. Beispielsweise ist das ER-Modell im Bereich der Datenbanksysteme beheimatet, XML und JSON dahingegen im Bereich der Nahtstellen und Datenstrukturen innerhalb und zwischen einzelnen Systemen auf Dateiebene.
Entity-Relationship Modell (ER-Modell)
Das Entity-Relationship Modell (ER-Modell) wurde bereits im vorherigen Semester, im Studienheft „Datenbanksysteme“ (Schikuta, E.), genau erläutert. Nachfolgend werden nun die wesentlichen Punkte dieses Skriptums nochmals auszugsweise wiederholt.
Das Entity-Relationship-Modell (ER-Modell) ist eines der ältesten (Chen, 1976) und am weitesten verbreiteten Modelle zum Entwurf von Datenbankmodellen und wird auch gerne im Bereich der allgemeinen Software Entwicklung eingesetzt. Durch seine besonders einfachen Darstellungsmöglichkeiten ist es sehr gut für die Kommunikation mit den Endbenutzern geeignet.
Die Grundidee des Entity-Relationship-Modells (Objekt-Beziehungs-Modell) besteht darin, die Welt als Sammlung von Entitäten (Entity oder Objekttypen) und Beziehungen (Relationship) zwischen diesen Objekttypen zu sehen.
Modellierungsobjekte des ER-Modells
Entitäten
Ein Objekt wird Entität-Instanz genannt. Entität-Instanzen sind dabei einzelne Exemplare von Dingen oder Begriffen. Dies können beispielsweise sein:
- Personen: der Kunde, Lieferant, Mitarbeiter etc.
- Gegenstände: Handelsware, Rohstoff, Maschine etc.
- Abstrakte Begriffe: Konto, Buchung, Bestellung etc.
Entität-Instanzen mit gleichen Eigenschaften lassen sich zu Entitäten (Objekttypen) zusammenfassen, z.B. Kunden, Bestellungen etc. Die Eigenschaften einer Entität-Instanz werden durch Attribute beschrieben, z.B. Name, Baujahr, Preis, Bestellnummer.
Hinweis: Im ER – Modell bezeichnet der Begriff Entität immer eine Klasse (Typ) von Instanzen, nicht eine Instanz!
Zwischen zwei, aber auch mehr, Entitäten können Beziehungen bestehen, z.B. „Kunde bestellt Maschine“. Die Beziehung wird dabei durch die Rolle der an ihr beteiligten Entitäten beschrieben. Die Beziehungen können zwischen Entitäten gleichen Typs oder zwischen Entitäten verschiedenen Typs bestehen.
Die wichtigsten Symbole in der grafischen Notation des ER-Modells werden in der Abbildung "Grafische Notation im ER-Modell" dargestellt.
Attribute können auch Beziehungen zugeordnet werden (siehe Abbildung "Beispiel Beziehungsattribut"). Hier ist bei der Modellierung zu entscheiden, ob dieses Beziehungsattribut nicht einer der beiden Entitäten zugeordnet werden kann oder soll.
Eine minimale Menge von Attributen, deren Werte die zugeordnete Entität-Instanz eindeutig innerhalb aller Instanzen seines Objekttyps identifiziert, nennt man Schlüssel. Oft gibt es Attribute, die künstlich als Schlüssel eingebaut werden, z.B. Personalnummer, Vorlesungsnummer, …
Schlüsselattribute werden durch Unterstreichen (manchmal auch durch doppelt gezeichnete Ovale) gekennzeichnet (siehe Abbildung "Beispiel Schlüsselattribut").
Beziehungen
Beziehungen repräsentieren eigentlich Aggregate von zwei oder mehreren an der Beziehung teilnehmenden Entitäten. Die Anzahl der aggregierten Entitäten heißt Grad der Beziehung (unäre, binäre, n-äre Beziehung). Entitäten haben in einer Beziehung eine minimale und eine maximale Kardinalität bzw. Komplexität.
Die Beziehungen können vom Typ 1:1, 1:n, n:1, oder m:n sein. Entsprechende Beispiele für die einzelnen Kardinalitäten findet man in der Abbildung "Beispiele Kardinalitäten":
Diese Kardinalitäten können folgendermaßen interpretiert werden:
- 1:1 – ein Ehemann hat genau eine Ehefrau (normalerweise), und umgekehrt.
- 1:n – ein Kunde besitzt mehrere Konten, aber jedes Konto gehört genau einem Kunden.
- m:n – Ein Kunde kann mehrere Artikel kaufen und jeder Artikel kann von mehreren Kunden gekauft werden.
Bei der Angabe der Kardinalitäten ist es auch möglich Intervalle durch Angabe der minimalen und maximalen Kardinalität zu definieren. In der Abbildung "Beispiel Kardinalitäten mit Intervallen" ist sowohl eine n:m und eine n:1 Beziehung definiert, wobei das Maximum der Kardinalität die Beziehungsmultiplizität definiert.
Im obigen Beispiel sieht man, dass es ohne weiters möglich ist, auch mehr als eine Beziehung zwischen Entitäten zu definieren. Im spezifischen Fall sind dies zwei binäre Beziehungen.
In manchen Fällen ist es notwendig auch n-äre Beziehungen zu modellieren. In der Abbildung "Beispiel ternäre Beziehung" ist eine ternäre Beziehung dargestellt und die entsprechende Interpretation der Kardinalitäten angegeben.
Es ist aber empfohlen n-äre Beziehungen nur in wirklich begründeten Fällen zu modellieren.
Unter einer schwachen Entität versteht man eine Entität, die kein Schlüsselattribut besitzt (d.h. wo die Instanzen nicht eindeutig unterschieden werden können). Solche Instanzen können nur über eine Beziehung zu einer anderen Entität eindeutig identifiziert werden. Schwache Entitäten werden grafisch durch einen doppelten Rand gekennzeichnet.
In der nachfolgenden Abbildung "Beispiel Schwache Entität" ergibt sich die schwache Entität dadurch, dass ein Hörsaal durch seine Nummer, Größe und seinen Typ nicht eindeutig auf einem Universitätscampus identifiziert werden kann, auf dem es eine Vielzahl von Gebäuden mit jeweils mehreren Hörsälen gibt, die in jedem Gebäude von der Nummer 1 an gezählt werden. Das bedeutet es gibt in jedem Gebäude einen Hörsaal mit der Nummer 1. Erst mit der Angabe des Gebäudes (identifying owner) kann dadurch jeder Hörsaal eindeutig identifiziert werden.
Beispiel eines ER-Modells
Im abschließenden (vereinfachten) Beispiel dieser Lektion wollen wir, basierend auf einem gegebenen Ausschnitt der Realität einer „Bank“, eine Modellierung mit Hilfe des ER-Modells durchführen.
Ausgangsposition für unseren Ansatz bildet eine Anforderungsbeschreibung in natürlichsprachiger Form. Es wird angenommen, dass sich diese Beschreibung aus den Interviews mit den Benutzern bzw. Auftragsgebern ergeben hat. Eine in der Praxis simple, aber übliche Vorgangsweise, um Entitätskandidaten zu erhalten, ist alle Hauptworte im Text zu identifizieren und als ersten Ansatz für Entitäten zu verwenden. Dieses Verfahren wird in der CRC-Methode vertieft (siehe die Aufgaben zu dieser Lektion).
Anforderungsbeschreibung:
„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“
Eine mögliche Modellierung dieser Anforderungsbeschreibung als ER-Modell findet man in der Abbildung "Beispiel Bank: ER-Modell".
Extensible Markup Language (XML)
Die Extensible Markup Language (XML) ist ein Standard für den Aufbau von Dateidokumenten. Sie wurde vom World Wide Web Consortium (W3C) entwickelt. Es handelt sich dabei um eine sehr flexible Modellierungsform für Textformate welche wiederum von der Standard Generalized Markup Language (SGML, ISO8879) abgeleitet wurde. (World Wide Web Consortium (W3C), 2014)
XML ist eine Markup-Sprache, und es ist nur eine Markup-Sprache. […] Der XML-Hype ist so extrem geworden, dass viele Leute glauben, XML könne sogar Kaffee kochen der den Familienhund waschen. (Harold & Means, 2005, S. 5)
Die Designziele von XML selbst sind (World Wide Web Consortium (W3C), 2008):
- XML soll direkt und unkompliziert über das Internet nutzbar sein,
- XML soll eine große Anzahl unterschiedlicher Applikationen unterstützen,
- XML soll mit SGML kompatibel sein,
- eine Programmierung von Anwendungen, welche XML Dokumente verarbeiten können, soll einfach möglich sein,
- die Anzahl von optionalen Features soll in XML so gering wie möglich gehalten werden und optimal Null sein,
- XML Dokumente sollen menschenlesbar und leicht verständlich sein,
- die Modellierung von XML Dokumenten soll schnell erstellt werden können,
- das Design von XML Dokumenten soll formal und präzise sein,
- die Erstellung von XML Dokumenten soll einfach sein und
- die Kürze und Kompaktheit der XML Elemente ist von geringer Bedeutung.
Der Hauptvorteil bei XML liegt, im Gegensatz zu eigen entwickelten Dateistrukturmodellen, in der schnellen und einheitlichen Verarbeitbarkeit für den Entwickler. In nahezu jeder gängigen Programmiersprache existieren bereits fertige Parser, welche die Generierung und Verarbeitung der Datenstrukturen, ohne größeren Programmieraufwand, ermöglichen.
Aufbau eines XML Dokuments
Baumstruktur:
Die Struktur eines XML-Dokuments entspricht einer Baum-Struktur und wird oft als XML-Baum bezeichnet.
Jedes XML Dokument beinhaltet ein einziges XML Wurzel-Element, welches selbst jeweils wiederum beliebig viele weitere Elemente beinhalten kann. In unserem Beispiel ist das Wurzel-Element die Firma.
Alle Elemente dürfen wiederum beliebig viele weitere Elemente enthalten - sog. Kind-Elemente (child elements). In unserem Beispiel ist der Mitarbeiter ein Kind-Element von Firma und hat wiederum Vorname, Nachname, Kontakt Nr. E-Mail und Adresse als Kind-Elemente. Wie Sie erkennen können, hat auch die Adresse wiederum 4 weitere Kind-Elemente. Diese Verzweigungen lassen sich beliebig fortsetzen und sind in der tiefe der Verzweigungen nicht begrenzt.
Im Folgenden sehen Sie die Umsetzung des oben genannten XML-Baumes in ein XML-Dokument.
<?xml version="1.0"?>
<Firma>
<Mitarbeiter>
<Vorname> Peter </Vorname>
<Nachname> Huber </Nachname>
<KontaktNr> 123 </KontaktNr>
<E-Mail> phuber@ffh.ac.at </E-Mail>
<Adresse>
<Strasse> Ferdinand Porsche Ring 3 </Strasse>
<PLZ> 2700 </PLZ>
<Stadt> Wr. Neustadt </Stadt>
<Land> Austria </Land>
</Adresse>
</Mitarbeiter>
</Firma>
<span id="_Ref402870210" class="anchor"></span>
Zusätzlich kann das Dokument XML Deklarationen, auch bezeichnet als Processing Instructions (PI), und beliebig viele Kommentare enthalten. Die Zeichenkodierung der Dokumente darf alle Unicodezeichen enthalten, wobei jedes XML verarbeitende Programm zumindest die Kodierungen UTF-8 und UTF-16 akzeptieren muss. Alle Bezeichnungen eines Dokuments, seien es die von Elementen oder Attributen, sind Case Sensitive. Da es sich dabei um ein einfaches Textdokument handelt, kann es auch von allen Texteditoren und Internetbrowsern, ohne weitere Hilfsmittel und Plugins, angezeigt werden. (World Wide Web Consortium (W3C), 2008)
Vom Aufbau sehen sich XML und HTML (Hypertext Markup Language) Dokumente sehr ähnlich. Sie unterscheiden sich jedoch darin, dass die Art und teilweise die Anzahl der Elemente in HTML fest vorgegeben, in XML jedoch alle Elemente frei modellierbar, sind. Das Metamodell der zu verwendeten Elemente eines XML Dokuments kann somit vom Modellierer selbst festgelegt werden. HTML dient der Modellierung von Webseitendokumenten und hat fest vorgegebene Strukturen und Elemente um eine einheitliche grafische Verarbeitung durch die Internetbrowser zu ermöglichen. Das Design der Elemente selbst ist jedoch in beiden Fällen sehr restriktiv vorgegeben.
Die XML Deklaration gibt die eingesetzte XML Version, und optional das Encoding, an. Dadurch wird den verarbeitenden Programmen die Verarbeitung erleichtert. Gerade die Angabe des Encodings kann viele Verarbeitungsprobleme im Vorfeld abfangen, da der Parser damit die eingesetzten Zeichen kennt und sie korrekt interpretieren kann. Nachfolgend ist in Abbildung 10 ein minimales XML Dokument dargestellt, welches nur eine XML Deklaration und ein einzelnes XML Element, namens „mein_wurzel_element“, ohne weitere Attribute und ohne Wert, beinhaltet.
<?xml version="1.0" encoding="UTF-8"?> <mein_wurzel_element />
Minimales XML Dokument
Da einige Zeichen in der XML Syntax eine spezielle Bedeutung haben, müssen sie im Text nötigenfalls in einer anderen Form geschrieben werden, um sie innerhalb von XML Elementen nutzen zu können:
- < wird zu <
- > wird zu >
- " wird zu "
- ' wird zu '
- & wird zu &
XML-Elemente
Die einzelnen XML Elemente sind alle nach demselben Schema aufgebaut. Sie haben eine Elementbezeichnung und können beliebig viele Attribute enthalten. Weiter können sie selbst einen Inhalt haben, welcher wiederum aus Elementen bestehen kann.
Ein Element besteht aus einem oder zwei sogenannten Tags. Ein Tag wird durch spitze Klammern (<,>) an seinem Beginn und Ende ausgezeichnet. Ob ein Element aus einem oder zwei Tags besteht, hängt davon ab, ob es selbst einen eigenen Inhalt besitzt, oder nicht. Der Inhalt kann aus Text oder weiteren Elementen bestehen. Am Beginn jedes Tags steht der Name des Elements.
Hat ein Element keinen Inhaltsbereich, besteht es aus nur einen einzigen Tag. Dessen abschließenden spitzen Klammer wird ein Schrägstrich vorangestellt (<elementname />) um die Abwesenheit eines Inhaltbereiches zu signalisieren.
Sollte das Element dahingegen einen Inhaltsbereich haben, wird der erste Tag durch eine einfache spitze Klammer geschossen (<elementname>). Danach folgt dann der eigentliche Inhalt des Elements. Nach dem Inhalt, und damit am Ende des Elements, steht in diesem Fall ein zweiter Tag, welcher wiederum einen Schrägstrich nach der einleitenden spitzen Klammer hat (</elementname>).
Die Attribute eines Elements befinden sich immer innerhalb des ersten Tags. In einem Element darf ein gewählter Attributname nur einmal vorkommen. Somit ist es beispielsweise nicht möglich einem Element „person“ mehrmals das Attribut „name“ zu zuzuweisen. die Reihenfolge der einzelnen Attribute eines Elements ist dahingegen nicht relevant und kann beliebig gewählt werden. Ein möglicher Aufbau eines Elements „person“ mit den Attributen „vorname“, „nachname“ und „ausweisnummer“ ist in Abbildung 11 dargestellt.
<person vorname="Peter" nachname="Völkl" ausweisnummer="1234567"/>
Abbildung 11 – XML Element „person“
In Abbildung 12 sind weiter:
- ein Element „element_1“ ohne Inhalt und ohne Attribute,
- ein Element „element_2“ ohne Inhalt und mit Attributen,
- ein Element „element_3“ mit Inhalt und ohne Attributen,
- ein Element „element_4“ mit Inhalt und mit Attribut und
- ein Element „element_5“ mit Attributen und weiteren Elementen im Inhalt exemplarisch dargestellt.
<element_1 /> <element_2 attribut_1="Attributwert 1" attribut_2="Attributwert 2" attribut_3="Attributwert 3"/> <element_3>Dies ist ein Inhaltstext</element_3> <element_4 attribut_1="Wert 1">Noch ein Inhaltstext</element_4> <element_5 attribut_1="Attributwert 1"> <element_1 /> <element_2 attribut1="Test 1"<br> attribut_2="Test 2" attribut_3="Attributwert 3"/> <element_3>Dies ist ein anderer Inhaltstext</element_3> </element_5>
Abbildung 12 – XML Elemente mit unterschiedlichen Tags
Kommentare
Zusätzlich zu den Deklarationen und Elementen, kann ein XML Dokument auch Kommentare enthalten. Diese können sich an jeder Position im Dokument befinden an der auch ein Element stehen dürfte, also überall außer im Attributbereich eines Tags. Sie werden bei der Interpretation des Dokuments ignoriert. Kommentare dienen primär der Lesbarkeit durch Menschen. Mit ihnen können einzelne Teile des Dokuments mit Erklärungen versehen werden, die dem Anwender bei nicht automatisierter Betrachtung helfen können, den Inhalt zu verstehen.
Ein Kommentar ist hinlänglich seines Inhaltes kaum beschränkt. Es darf einzig keine zwei direkt zusammenhängenden Minuszeichen (--) enthalten. Sollte sich innerhalb eines Kommentars ein XML Element befinden, wird es nicht als Element, sondern als Kommentartext interpretiert. Damit können auch einzelne Teile eines Dokuments „auskommentiert“ werden, um sie bei der Interpretation zu ignorieren, ohne sie aus dem Dokument löschen zu müssen. Dies ist gerade bei der Entwicklung von Schnittstellen hilfreich, da die Musterdateien somit abgeändert werden können, ohne einzelne Inhalte zu löschen.
Kommentare werden durch die Zeichenfolge <!-- begonnen und danach durch --> wieder beendet. Alle Zeichen, welche sich zwischen diesen beiden Teilen befinden gelten damit als Kommentartext und nicht als XML Element.
XML-Schema (XSD)
Was ist ein Schema?
Ein Schema ist die formale Beschreibung der Organisation, Struktur und des Inhalts von Dokumenten.
Aufgrund des wachsenden Einsatzgebietes und der gestiegenen Anforderungen an XML, wurde ein Werkzeug benötigt, mit dem man sowohl für Maschinen als auch für Menschen das Vokabular von XML-Dokumenten lesbar beschreiben, dokumentieren und, vor allem, validieren kann.[4]
Damit wird gewährleistet, dass jede Anwendung, die ein wohlgeformtes XML verwendet, den hier definierten Formalismus verwendet, um syntaktische-, strukturelle- und Wert-Beschränkungen auszudrücken, die für ihre Dokumentinstanzen gelten.[5]
Ein XML-Schema dient also dazu, Regeln und Strukturen zu beschreiben. Allerdings gelten diese Beschreibungen nur für XML-Dokumente. Die Menge der XML-Dokumente, für die ein Schema gilt, wird Klasse genannt.[6]
Anwendungsgebiete
Die Anwendungsgebiete für ein XML-Schema lassen sich in folgende Kategorien zusammenfassen:
- Validierung - ist die meistverbreitete Anwendung eines XSDs. Sie kann in zwei Ebenen unterteilt werden.
- Strukturvalidierung - es wird die Einhaltung der Regel für das Vorkommen von Elementen und Attributen überprüft.
- Datenvalidierung - Der Inhalt der Elemente und Attribute wird auf die Art der Daten, welche in Elementen und Attributen verwendet werden dürfen, überprüft.
- Abfrageunterstützung - Durch die Unterstützung von XML-Schema-Datentypen wird eine genaue Analyse und Abfrage mittels XSLT, XPath und XQuery unterstützt.
- Datenbindung, Editierung - mit geeigneten Tools lassen sich Informationen direkt aus der Dokumentenstruktur in eine Datenbank einbinden.
- Dokumentation - XML-Schemata können dazu genutzt werden, um das verwendete XML-Vokabular zu dokumentieren.[7]
Vorteile von XSD
- Interoperabilität – Mit Hilfe von XSD können Organisationen konsistente Datenformate definieren, was die Interoperablilität zwischen verschiedenen Systemen und Plattformen verbessert.
- Neue Datentypen – Neue Datentypen können aus bestehenden abgeleitet werden.
- Wiederverwendbarkeit – XSD ermöglicht den Einsatz von benutzerdefinierten Datentypen und Elementen. Diese können in verschiedenen Teilen eines Schemas wiederverwendet werden.
- Default-Werte und Einschränkungen - XSD erlaubt die Festlegung von Standard- oder Vorgabewerten für Elemente und Attribute. Außerdem können Einschränkungen für Datentypen definiert werden, um sicherzustellen, dass die eingegebenen Daten bestimmten Kriterien entsprechen.
- Namensräume - XSD unterstützt die Verwendung von Namensräumen, was es ermöglicht, komplexe XML-Schemata zu entwickeln, die aus mehreren Modulen oder Quellen stammen können. Dies ist besonders wichtig in umfangreichen Projekten und bei der Integration verschiedener Datenquellen.
- Erweiterbarkeit - XSD bietet Mechanismen für die Definition von optionalen Elementen und Attributen sowie für die Erweiterung von bestehenden Schemata. Dies ermöglicht es, Schemata im Laufe der Zeit anzupassen und zu erweitern, ohne die bestehenden Datenstrukturen zu brechen.
- Tool-Unterstützung - Es gibt eine breite Palette von Tools und Bibliotheken, die die Arbeit mit XML-Schemas erleichtern. Diese Tools bieten Funktionen wie Validierung, automatische Generierung von XML-Daten basierend auf einem Schema und umgekehrt, sowie Schema-Transformationen.
- XSD ist selbst ein XML Dokument – Da XSD ebenfalls ein XML Dokument ist, kann es auch entsprechend validiert werden. D.h. es kann geprüft werden, ob das Schema den Regeln der Schemaspezifikation entspricht.
Bestandteile eines XSDs
- Header: wie bei XML Dokument plus dem Namespace
- Attributdefinition
- Elementdefinition
- Datentypdefinition
Header
In einem XML-Dokument ist der Header ein optionaler Abschnitt, der spezielle Informationen über das Dokument enthält. Der Header befindet sich am Anfang des XML-Dokuments und wird in spitzen Klammern (< und >) eingeschlossen. Der Header besteht aus einem oder mehreren benannten Teilen, die als "Attribut-Wert-Paare" bezeichnet werden. Ein typischer XML-Header sieht folgendermaßen aus:
<?xml version="1.0"?>
Namespace / Namensräume sind besonders nützlich, wenn in einem XML-Dokument, Daten aus verschiedenen Quellen kombiniert werden. Durch die Verwendung von Namensräumen kann sichergestellt werden, dass Elemente und Attribute eindeutig identifizierbar sind, selbst wenn sie denselben Namen haben. Das fördert die Interoperabilität und Flexibilität beim Austausch von Daten zwischen verschiedenen Systemen und Plattformen.
Der Namensraum für XML-Schema ist: http://www.w3.org/2001/XMLSchema
Jedes Element und Attribut, das zum Schema gehört wird mit einem Namensrau-Präfix (entweder „xs“ oder „xsd“) versehen.
Das <schema> Element
Das <schema> Element ist das Root Element von jedem XML-Schema und kann einige Attribute enthalten.
Eine Schema-Deklaration sieht oft so aus:
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
...
...
</xs:schema>
Typisierung von Daten
In einem XSD unterscheidet man zwei Typ-Arten:
- Einfacher Typ – das sind Elemente, die nur Zeichenketten – (Zeichen oder Zahlen) enthalten und keine Attribute besitzen dürfen.
- Komplexer Typ – das sind Elemente, die Unterelemente enthalten oder Attribute besitzen können.
Einfacher Typ
In einem XML-Schema (XSD) wird ein einfaches Element definiert, indem das <xs:element>-Element verwendet wird. Ein einfaches Element enthält nur Textinhalt.
Die grundlegende Struktur für die Definition eines einfachen Elements in einem XS:
<xs:element name="elementName" type="dataType" />
- name: Gibt den Namen des Elements an.
- type: Gibt den Datentyp des Elements an. Dieser kann ein vordefinierter einfacher Datentyp wie "string", "integer", "boolean", usw. sein, oder er kann ein benutzerdefinierter Datentyp sein, der im Schema definiert ist.
Beispiel XSD einfacher Typ:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="nachname" type="xs:string" />
</xs:schema>
In diesem Beispiel wird das Element „nachname“ vom Datentyp „string“ definiert.
Das XML-Dokument, das diesem Schema entspricht, könnte sein:
<nachname>Huber</nachname>
Default Variablen
Für einfache Elemente kann ein Standardwert ODER ein fester Wert angegeben werden.
Ein Standardwert wird dem Element automatisch zugewiesen, wenn kein anderer Wert angegeben wird.
Im folgenden Beispiel ist der Standardwert "rot":
<xs:element name=“Farbe" type="xs:string" default=“rot"/>
Fixe Variable
Bei einer fixen Variablen wird dem Element automatisch ein fester Wert zugewiesen, und es kann kein anderer Wert verwendet werden.
Im folgenden Beispiel ist der fixe Wert "rot":
<xs:element name=“Farbe" type="xs:string" fixed=“rot"/>
Komplexer Typ
Ein komplexes Element ist ein XML-Element, das andere Elemente und/oder Attribute enthält.
Es gibt vier Arten von komplexen Elementen:
- leere Elemente
- Elemente, die nur andere Elemente enthalten
- Elemente, die nur Text enthalten
- Elemente, die sowohl andere Elemente als auch Text enthalten
Achtung: Jedes dieser Elemente kann auch Attribute enthalten!
In einem XML-Schema (XSD) wird ein komplexes Element definiert, indem das <xs:element>-Element zusammen mit dem <xs:complexType>-Element verwendet wird. Ein komplexes Element kann sowohl Textinhalt als auch andere verschachtelte Elemente enthalten.
Die grundlegende Struktur für die Definition eines komplexen Elements in einem XS:
<xs:element name="elementName">
<xs:complexType>
<!-- Hier folgen Definitionen für verschachtelte Elemente, Attributen, usw. -->
</xs:complexType>
</xs:element>
Innerhalb des <xs:complexType>-Elements kann die Struktur des komplexen Elements definiert werden, einschließlich der verschachtelten Elemente, ihrer Datentypen und anderer Einschränkungen.
Beispiel XSD für komplexer Typ
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="person">
<xs:complexType>
<xs:sequence>
<xs:element name="nachname" type="xs:string" />
<xs:element name="alter" type="xs:integer" />
</xs:sequence>
</xs:complexType>
</xs:element>
/xs:schema>
In diesem Beispiel enthält das komplexe Element "person" zwei verschachtelte Elemente: "nachname" und "alter".
Das <xs:sequence>-Element stellt sicher, dass die Elemente in der angegebenen Reihenfolge erscheinen müssen.
In Folgendem sieht man beispielshaft, wie das dem Schema entsprechende XML aussehen könnte:
<person>
<nachname>John Doe</nachname>
<alter>30</alter>
</person>
Attribut
Der Aufbau einer Attributdefinition sieht wie folgt aus:
<xs:attribute name="xxx" type="yyy"/>
“xxx” = Name des Attributes
“yyy” = Datentyp des Attributes
Beispiel
XS: <xs:attribute name="lang" type="xs:string"/>
Ein entsprechendes XML-Dokument würde wie folgt aussehen:
XML: <nachname lang="EN">Smith</nachname>
Für Attribute kann ein Standardwert ODER ein fester Wert angegeben werden.
- Ein Standardwert wird dem Attribut automatisch zugewiesen, wenn kein anderer Wert angegeben wird.
- Einem fixen Attribut wird vorab ein fester Wert zugewiesen. Es kann kein anderer Wert angegeben werden
Im folgenden Beispiel ist der Standardwert „DE":
<xs:attribute name="lang" type="xs:string" default=„DE"/>
Im folgendem Beispiel ist der fixe Wert „EN“.
<xs:attribute name="lang" type="xs:string" fixed=„EN"/>
Attribute sind standardmäßig optional.
Um anzugeben, dass das Attribut erforderlich ist, verwenden Sie das Attribut "use":
<xs:attribute name="lang" type="xs:string" use="required"/>
Inhaltsbeschränkungen:
Wenn für ein XML-Element oder -Attribut ein Datentyp definiert ist, gelten Einschränkungen für den Inhalt des Elements oder Attributs.
Wenn ein XML-Element vom Typ "xs:date" ist und eine Zeichenkette wie "Hello World" enthält, wird das Element nicht validiert.
Mit XML-Schemas können Sie Ihren XML-Elementen und -Attributen auch Ihre eigenen Einschränkungen hinzufügen.
Um den Inhalt eines XML-Elements einzuschränken und eine Reihe von Zahlen oder Buchstaben zu definieren, die verwendet werden können, wird die Mustereinschränkung verwendet.
Im folgenden Beispiel wird ein Element namens "letter" mit einer Einschränkung definiert. Der einzige akzeptable Wert ist EINER der Buchstaben in Kleinbuchstaben von a bis z:
<xs:element name="letter">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[a-z]"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
Das folgende Beispiel definiert ein Element namens "Buchstabe" mit einer Einschränkung. Der akzeptable Wert ist null oder mehr Vorkommen von Kleinbuchstaben von a bis z:
<xs:element name=„Buchstabe">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="([a-z])*"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
Im folgenden Beispiel wird ein Element namens „periode" mit einer Einschränkung definiert. Der einzige akzeptable Wert sind FÜNF Ziffern in einer Folge, und jede Ziffer muss in einem Bereich von 0 bis 9 liegen:
<xs:element name=„periode">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:pattern value="[0-9][0-9][0-9][0-9][0-9]"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
Nach dem gleichen Muster funktioniert das auch mit weiteren Definitionen:
| <xs:pattern value="[A-Z][A-Z][A-Z]"/> | 3 Großbuchstaben |
| <xs:pattern value="[a-zA-Z][a-zA-Z][a-zA-Z]"/> | 3 Groß- oder Kleinbuchstaben |
| <xs:pattern value="[xyz]"/> | Entweder „x“ oder „y“ |
| <xs:pattern value="[0-9][0-9][0-9][0-9][0-9]"/> | 5 Ziffern aus dem Zahlenbereich 0-9 |
| <xs:pattern value="[1-5][ 1-5][ 1-5][ 1-5][ 1-5]"/> | 5 Ziffern aus dem Zahlenbereich 1-5 |
| <xs:pattern value="([a-z])*"/> | beliebig viele Kleinbuchstaben |
| <xs:pattern value="male|female|divers"/> | einer der Gender-Werte ist erlaubt |
| <xs:pattern value="[a-zA-Z0-9]{8}"/> | 8 Zeichen bestehend aus Groß- oder Kleinbuchstaben oder Ziffern oder gemischte Zeichenfolge |
Vorgehen beim Erstellen eines XSD
Um ein XSD für ein XML – Dokument zu erstellen, geht man wie folgt vor:
- XML-Dokument analysieren:
Zunächst sollten Sie das gegebene XML-Dokument gründlich analysieren, um die Struktur und Hierarchie der Elemente sowie die Art der enthaltenen Daten zu verstehen. - Elemente identifizieren:
Identifizieren Sie die verschiedenen Elemente im XML-Dokument, einschließlich ihrer Hierarchiebeziehungen. Im gegebenen Beispiel gibt es die Elemente example, name, firstname, lastname, age, address, street, zip-code, city und country. - Datentypen bestimmen:
Bestimmen Sie die Datentypen für jedes Element. Zum Beispiel könnten firstname, lastname, street, city und country vom Typ xsd:string sein, während age und zip-code vom Typ xsd:integer sein könnten. - Elemente und Typen im XSD definieren:
Definieren Sie die Elemente und ihre Datentypen im XSD. Beachten Sie dabei die Hierarchie der Elemente. Verwenden Sie xsd:element für jedes Element und weisen Sie ihm den entsprechenden Datentyp (xsd:string, xsd:integer, etc.) zu. - Attribute definieren:
Wenn das XML-Dokument Attribute enthält (wie plz im gegebenen Beispiel), definieren Sie diese mit xsd:attribute. - Wiederholbare Elemente festlegen:
Beachten Sie, welche Elemente im XML-Dokument mehrmals auftreten können (wie address und name im Beispiel). Verwenden Sie maxOccurs="unbounded" oder einen anderen geeigneten Wert, um diese Wiederholbarkeit im XSD festzulegen. - Validierungen hinzufügen (optional):
Wenn spezifische Muster oder Validierungen für die Daten erforderlich sind (z.B. für Namen, Postleitzahlen), können Sie xsd:restriction und xsd:pattern verwenden, um diese Einschränkungen im XSD festzulegen. - Beispiel-Instanzen testen:
Erstellen Sie einige Beispiel-XML-Instanzen, um sicherzustellen, dass sie dem erstellten XSD-Schema entsprechen. Dies hilft dabei, sicherzustellen, dass das Schema die gewünschte Struktur und Validierung aufweist.
Beispiel:
Für ein XML, das folgendem Strukturbaum folgt, soll ein XML Definition File erstellt werden.
Das XSD File soll folgende Merkmale enthalten:
- Die Reihenfolge der Elemente ist, entsprechend der Baumstruktur einzuhalten.
- Alle Namen (Vorname, Nachname, Straßennamen etc…) müssen mit einem Großbuchstaben beginnen.
- Das Element „example“ muss das Attribut “plz” enthalten welches als String zu definieren ist.
- Für die Elemente „name“ und „address“ sollen eigene Typen erstellt werden welche die jeweiligen Unter-Elemente definieren.
- Beim Alter muss sichergestellt sein, dass sowohl Kleinkinder als auch Senioren im Alter von 99+ erfasst werden können. (200+ Jahre dürfen nicht erfasst werden.)
Beispiel XSD:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!-- Identifizierte Elemente mit entsprechenden Datentypen und Restriktionen definieren -->
<xsd:element name="firstname">
<xsd:simpleType>
<xsd:restriction base ="xsd:string" >
<xsd:pattern value="[A-Z][a-z]*"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="lastname">
<xsd:simpleType>
<xsd:restriction base ="xsd:string" >
<xsd:pattern value="[A-Z][a-z]*"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="age">
<xsd:simpleType>
<xsd:restriction base ="xsd:integer" >
<xsd:pattern value="[0-1][0-9][0-9]"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="street">
<xsd:simpleType>
<xsd:restriction base ="xsd:string" >
<xsd:pattern value="[A-Z][a-z]*"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="city">
<xsd:simpleType>
<xsd:restriction base ="xsd:string" >
<xsd:pattern value="[A-Z][a-z]*"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="country">
<xsd:simpleType>
<xsd:restriction base ="xsd:string" >
<xsd:pattern value="[A-Z][a-z]*"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<!-- das Rootelement "example" ist vom Typ "MultAddress" -->
<xsd:element name="example" type="MultAddress" />
<!-- der Typ "MultAddress" besteht aus dem Typ "name" und dem Attribut "plz" -->
<xsd:complexType name="MultAddress">
<xsd:sequence>
<xsd:element ref="name" maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute name="plz" type="xsd:string" use="required" />
</xsd:complexType>
<!-- der Typ "name" wird definiert durch "firstname", "lastname", "age" und "address" -->
<xsd:element name="name" type="nametype" />
<xsd:complexType name="nametype">
<xsd:sequence>
<xsd:element ref="firstname" />
<xsd:element ref="lastname" />
<xsd:element ref="age" />
<xsd:sequence>
<xsd:element ref="address" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:sequence>
</xsd:complexType>
<!-- das Element "address" wird durch "addresstype" definiert -->
<xsd:element name="address" type="addresstype" />
<xsd:complexType name="addresstype">
<xsd:sequence>
<xsd:element ref="street" />
<xsd:element ref="city" />
<xsd:element ref="country" />
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
Beispiel XML:
So könnte das, dem oben beschriebenen XSD File, entsprechende XML File aussehen:
<?xml version="1.0" encoding="UTF-8"?>
<example plz="1030" >
<xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" \>
< xsi:noNamespaceSchemaLocation="path/to/external-schema.xsd">
<name>
<firstname>Hans</firstname>
<lastname>Müller</lastname>
<age>30</age>
<address>
<street>Hauptstraße 1</street>
<city>Wien</city>
<country>Österreich</country>
</address>
<address>
<street>Rochusgasse 12</street>
<city>Wien</city>
<country>Österreich</country>
</address>
</name>
<name>
<firstname>Heidi</firstname>
<lastname>Fischer</lastname>
<age>25</age>
<address>
<street>Rennweg 3</street>
<city>Wien</city>
<country>Österreich</country>
</address>
</name>
</example>
Zu beachten
Das XSD File kann sowohl in dem jeweiligen XML File am Beginn integriert werden, oder als externes XSD File zur Verfügung gestellt werden. Dazu muss zunächst der XML Schema Instance Namensraum im XML definiert und danach der Pfad, unter den das XSD File zu finden ist, angegeben werden.
Der allgemeine Aufbau für den Aufruf sieht wie folgt aus:
<rootElement xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="path/to/external-schema.xsd">
<!-- XML-Inhalt hier -->
</rootElement>
Beispiel eines XML Modells
Anforderungsbeschreibung:
„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“
Die Anforderungsbeschreibung gleicht dem Beispiels eines ER Modells. In diesem Fall soll jedoch kein Datenbankmodell, sondern ein Modell für ein Dateibasiertes XML Dokument für den Datenaustausch erstellt werden. Eine mögliche Modellierung dieser Anforderungsbeschreibung als DTD findet sich in der Abbildung "Beispiel „Bank“: XML-Modell, DTD Datei" und ein mögliches darauf basierendes XML Dokument in Abbildung "Beispiel „Bank“: XML-Modell, XML Datei". Dabei wurde aus Sicht der Filialen ausgegangen. Eine Betrachtung aus Sicht des Kontos, Kredites oder aus Sicht des Kunden wäre ebenfalls möglich. Dies hängt natürlich stark vom beabsichtigten Modellierungszweck ab. Als Wurzelelement dient das Element Filialliste, welches 0-n Filialen enthalten darf.
<!ELEMENT filialliste (filiale*)> <!ELEMENT filiale (kredit*, konto*)> <!ATTLIST filiale filialname ID> <!ATTLIST filiale stadt CDATA> <!ATTLIST filiale vermoegen CDATA> <!ELEMENT kredit (kunde)> <!ATTLIST kredit nummer ID> <!ATTLIST kredit betrag CDATA> <!ELEMENT konto (kunde)> <!ATTLIST konto nummer ID> <!ATTLIST konto kontostand CDATA> <!ELEMENT kunde EMPTY> <!ATTLIST kunde name ID> <!ATTLIST kunde strasse CDATA> <!ATTLIST kunde stadt CDATA>
Beispiel „Bank“: XML-Modell, DTD Datei
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE bank SYSTEM "bank.dtd"> <filialliste> <filiale filialname="Meine Bank" stadt="Wien" vermoegen="5 mrd eur"> <kredit nummer="100" betrag="200000 eur"> <kunde name="Max Muster" strasse="Musterplatz 1" stadt="Wien"> </kredit> <kredit nummer="101" betrag="10000 eur"> <kunde name="Maria Muster" strasse="Mustergasse 3" stadt="Wien"> </kredit> </filiale> <filiale filialname="Deine Bank" stadt="Wien" vermoegen="1 mrd eur"> <konto nummer="200" kontostand="3000 eur"> <kunde name="Hans Meier" strasse="Mustergasse 1" stadt="Graz"> </konto> </filiale> <filiale filialname="Seine Bank" stadt="Wien" vermoegen="2 mrd eur"> </filiale> </filialliste>
Beispiel „Bank“: XML-Modell, XML Datei
JavaScript Object Notation (JSON)
Die JavaScript Object Notation (JSON) wurde ursprünglich zur Speicherung und Übertragung von Datenstrukturen in JavaScript entwickelt. Es handelt sich dabei um ein reines Textformat, welches, ähnlich wie in XML, durch die Vorgabe einer klaren Struktur, eine einheitliche Abbildung von Daten ermöglicht. JSON ist in der RFC 4627 definiert und ist wiederum Teil des ECMAScript Programming Standards, welcher wiederum die wesentlichen Objekt Literale von JavaScrip definiert. (RFC Network Working Group, 2006)
Genau wie in XML, zeichnet sich JSON durch seine Menschenlesbarkeit und die Vielzahl verfügbarer Implementierungen in allen gängigen Programmiersprachen aus. JSON ist somit nicht auf JavaScript beschränkt, hat dort jedoch seinen eigentlichen Ursprung. Damit ist auch hier eine schnelle und einfache Implementierung von Nahtstellen zwischen unterschiedlichen Anwendungen möglich. Da die Syntax in JSON wesentlich kompakter geschrieben wird, als in XML, wird es häufig für die Datenübertragungen in Webservices, wie beispielsweise Services mit REST Schnittstellen (Fielding, 2000), eingesetzt.
Aufbau eines JSON Dokuments
Die Elemente und Attribute sind in JSON werden als Objekte und Key-Values bezeichnet. Jede Struktur ist über Objekte Abgebildet, welche selbst wiederum beliebig Objekte enthalten können. Ähnlich wie in XML muss in der obersten Hierarchiestufe ein einzelnes Objekt stehen. Die gemeinsame Verschachtelung von Objekten geschieht über Arrays Struktur.
Die möglichen Datentypen der einzelnen Objekte sind:
- String,
- Number,
- Boolean und
- null.
Sie müssen jedoch nicht eigens deklariert werden, sondern ergeben sich durch ihre Schreibweise innerhalb der Datei. Strings werden mit umschließenden Anführungszeichen geschrieben, Numbers in Zahlenschreibweise ohne Anführungszeichen und Booleans direkt als Werte true und false.
Objekte werden durch geschwungene Klammern ( { , } ) deklariert. Sie können beliebig viele Key-Values enthalten. Nach dem Namen einer Key-Value steht immer ein Doppelpunkt, gefolgt von ihrem enthaltenen Wert, welcher wiederum ein eigenes Objekt sein kann. Die einzelnen Key-Values werden durch Beistriche getrennt. Ein Wert kann auch ein Array aus Werten sein. Es wird durch eckige Klammern ( [ , ] ) deklariert und enthält beliebig viele, durch Beistriche getrennte, Werte.
Im Gegensatz zu XML gibt es in JSON Dateien keine Kommentare.
Der Text der JSON Dokumente soll laut Spezifikation (RFC Network Working Group, 2006) Unicode kodiert sein, wobei standardmäßig UTF-8 verwendet wird. Der verwendete Zeichensatz des Dokuments wird vom Parser über seine ersten beiden Zeichen erkannt. Es werden dazu die, in ihrer binären Form, enthaltenen Nullen betrachtet:
- 00 00 00 xx ergibt UTF-32BE [8] ,
- 00 xx 00 xx ergibt UTF-16BE,
- xx 00 00 00 ergibt UTF-32LE,
- xx 00 xx 00 ergibt UTF-16LE und
- xx xx xx xx ergibt UTF-8.
In der Abbildung "Beispiel JSON Objekt" ist ein JSON Objekt für eine Person definiert, welches Key-Values für einen Vornamen, einen Nachnamen und eine Ausweisnummer enthält. Weiter hat die Person ein Array mit Objekten, welche je einen Schlüssel der Person mit der jeweiligen Raumnummer abbilden.
{"vorname" : "Peter",
"nachname" : "Völkl",
"ausweisnummer" : 1234567,
"schluessel" : [{"raumnummer" : 22},{"raumnummer" : 33}]
}
Beispiel JSON Objekt
JSON Schema
Im Gegensatz zu XML gibt es bei JSON Daten keine standardisierte Möglichkeit eine eigene, formale, Definition zu erstellen, gegen welche die Struktur automatisiert geprüft werden kann. Eine entsprechende Standardisierung, das JSON Schema, befindet sich derzeit in Ausarbeitung und liegt bereits im Entwurfsstadium vor. Es kann jedoch aktuell nicht davon ausgegangen werden, dass diese unfertige Standardisierung mit jedem Parser eingesetzt werden kann. (Galiegue, 2013)
Beispiel eines JSON Modells
Anforderungsbeschreibung:
„Eine Bank gliedert sich in Filialen. Filialen werden an ihrem Namen unterschieden, sind in einer Stadt beheimatet und weisen ein Vermögen aus. Jede Filiale verwaltet ihre eigenen Konten und Kredite, die über Nummern identifiziert werden. Jedes Konto und jeder Kredit besitzt eine eindeutige Nummer und weist einen Kontostand (bei Konto) bzw. einen Betrag (bei Krediten) auf. Kunden wiederum besitzen Konten und haben auch Kredite laufen, wobei jedes Konto wie auch jeder Kredit genau einem oder mehreren Kunden zugeordnet wird. Kunden haben einen eindeutigen Namen und wohnen in einer Straße in einer Stadt.“
Die Anforderungsbeschreibung gleicht dem Beispiel eines ER-Modells und XML Modell. Die JSON Struktur könnte beispielsweise dem Austausch von Filialdaten über ein Webservice dienen. Eine mögliche Modellierung dieser Anforderungsbeschreibung findet sich nachfolgend in der Abbildung "Beispiel „Bank“: JSON-Modell, Teil 1/2". Dabei wurde ebenfalls wieder aus Sicht der Filialen ausgegangen. Eine Betrachtung aus Sicht des Kontos, Kredites oder aus Sicht des Kunden wäre ebenfalls möglich. Dies hängt natürlich stark vom beabsichtigten Modellierungszweck ab. Als Wurzelelement dient das Element Filialliste, welches 0-n Filialen enthalten darf. Die, in dem Beispiel enthaltenen, Einrückungen dienen der besseren Lesbarkeit und nicht erforderlich.
{"filialliste" : [ {"filialname“ : "Meine Bank",
"stadt" : "Wien",
"vermoegen" : "5 mrd eur",
"kredite" : [ {"nummer" : "100",
"betrag" : "20000 eur"},
"kunde" : {"name" : "Max Muster",
"strasse" : "Musterplatz 1",
"stadt" : "Wien"}
},
{"nummer" : "101",
"betrag" : "10000 eur"},
"kunde" : {"name" : "Maria Muster",
"strasse" : "Mustergasse 3",
"stadt" : "Wien"}
}
],
"konten" : []
},
{"filialname“ : "Deine Bank",
"stadt" : "Wien",
"vermoegen" : "1 mrd eur",
"kredite" : [],
"konten" : [ {"nummer" : "200",
"betrag" : "3000 eur"},
"kunde" : {"name" : "Hans Meier",
"strasse" : "Mustergasse 1",
"stadt" : "Graz"}
}
]
},
Beispiel „Bank“: JSON-Modell, Teil 1/2
{"filialname“ : "Seine Bank",
"stadt" : "Wien",
"vermoegen" : "2 mrd eur",
"kredite" : [],
"konten" : []
} ]
}
Beispiel „Bank“: JSON-Modell, Teil 2/2
Prozess-, Ablauf- und Geschäftsprozessmodellierung
Petri-Netze
Im Jahr 1939 wurden von Carl Adam Petri die Petri-Netze Entwickelt um seine Kenntnisse chemischer Prozesse anschaulich zu machen. Im Jahr 1941 begann er dann damit seine neue Modellierungsform zu erweitern, um ein strukturiertes Modell zur Formulierung und Lösung der spezifischen Problemstellungen von Computersystemen zur Verfügung zu stellen. Als Entwicklungsgrundlage der Petri-Netze dienten auch die Zustandsautomaten. (Reisig, 2010, S. IX)
Mit einem Petri-Netz werden diskrete Systeme abgebildet. Das bedeutet, dass das System und seine Abläufe und Zustände von einem bestimmten Zeitpunkt abhängig sind. Weiter ermöglichen sie die Modellierung und Abbildung verteilter Systeme.
Aufbau eines Petri-Netzes
Ein Petri-Netz besteht aus einem oder mehreren Abläufen, welche immer eine zeitliche Abhängigkeit und einen bestimmten Zustand haben. Der Zustand wird hierbei jedoch in Form von Token abgebildet, welche immer von einem Platz zum nächsten weitergereicht werden können. Die grundlegenden Elemente eines Petri-Netzes sind (Reisig, 2010, S. 22ff):
- Plätze, welche als Kreis oder Ellipse dargestellt werden,
- Transitionen, welche als Quadrate oder Rechtecke dargestellt werden,
- Kanten, die als Pfeile dargestellt werden, und
- Token, welche entweder als ausgefüllter Punkt, oder als bestimmtes Element, abgebildet werden.
Ein wesentliches Element sind die Token. Sie befinden sich an bestimmten Plätzen und werden an verarbeitende Stellen, die Transitionen, weitergeben. Diese erzeugen wiederum neue Token und legen diese wiederum an Plätzen ab. In manchen Modellteilen kann es daher so aussehen, als würden die Transitionen Token „weitergeben“, sofern derselbe Token-Typ, in gleicher Anzahl in die Transition eingeht und sie wieder verlässt. Tatsächlich handelt es sich jedoch immer um eigene eingehende und ausgehende Token.
In der Abbildung "einfaches Petri-Netz" ist ein einfaches Petri-Netz dargestellt, welches einen einfachen Token vom Platz A über die Transition b zum Platz C weiterreicht.
Nach einem Ablaufschritt wurde der Token dann „weitergereicht“ und befindet sich am Platz C. Konkret hat jedoch die Kante zwischen A und b zu einer Entnahme des Tokens aus A geführt. Die Transition b wurde nun dadurch ausgelöst und hat, angeleitet durch die Kante zwischen b und C einen neuen Token am Platz C abgelegt. Dies ist nachfolgend in der Abbildung "einfaches Petri-Netz zum Zeitpunkt t+1" wieder grafisch dargestellt.
Diese ersten beiden Beispiele nutzen die einfachste Form von Token, ohne spezielle Ausprägung. Dieser Form eines Petri-Netzes wird als elementares Netz bezeichnet.
Es ist auch möglich die Token selbst mit einem bestimmten Typ zu versehen. Damit können die verarbeitenden Transitionen von ganz bestimmten Token abhängig gemacht werden. Wenn es beispielsweise einen Token-Typ „Kaffeetasse“ und einen Token-Typ „Kaffeebohne“ gibt, kann eine Transition auch von der Existenz beider bestimmter Typen im vorhergehenden Platz abhängig gemacht werden, um dann wiederum einen Token vom Typ „volle Kaffeetasse“ im nachfolgenden Platz abzulegen. Wenn mehrere Token-Typen unterschieden werden, dann muss die zuständige Kante auch mit den weiterzugebenden Token beschriftet werden. Im nachfolgenden Beispiel, in der Abbildung "einfaches Petri-Netz einer Kaffeezubereitung", ist ein simpler Ablauf einer Kaffeezubereitung in Form eines sehr einfachen Petri-Netzes abgebildet. Grundvoraussetzung ist hierbei, dass sich genügend Kaffeebohnen und leere Tassen im Platz „Küchenschrank“ befinden. Erst wenn die Token der Kante vorhanden sind, wird die Transition „Kaffeezubereitung“ gestartet, welche wiederum eine „volle Kaffeetasse“ im Platz „Küchentisch“ ablegt. Die Token sind, der Einfachheit halber, in Form von Piktogrammen dargestellt.
In diesem Modell wird nun eine Bohne und eine Tasse aus dem Platz „Küchenschrank“ durch die Bedingung der Kante entnommen und an die Transition „Kaffeezubereitung“ übergeben. Diese wiederum generiert eine volle Kaffeetasse und legt sie in den Platz „Küchentisch“. Nach der Abarbeitung befindet sich damit im Platz „Küchenschrank“ eine Kaffeebohne und im Platz Küchentisch eine „volle Kaffeetasse“.
Eine Transition kann sowohl mehrere eingehende, als auch mehrere ausgehende Kanten haben. Um die Aktion der Transition auszulösen, müssen immer alle eingehenden Kanten erfüllt sein. Erst wenn alle nötigen Kanten erfüllt werden, werden auch die vorausgesetzten Token der vorangehenden Plätze entnommen. Wird nur ein Teil der eingehenden Kanten erfüllt, bleiben somit alle Token in den Plätzen liegen, bis sie dann gemeinsam entnommen werden können. In der Abbildung "einfaches Petri-Netz einer Kaffeezubereitung mit mehreren Startplätzen" wurde das Beispiel der Kaffeezubereitung nun um einen zweiten eingehenden Platz „Kaffeedose“ erweitert, welcher nun die Bohnen enthält.
Damit ein Nachfüllen der Tassen und Bohnen, sowie die Entnahme des fertigen Kaffees möglich sind, werden nun eigene eingehende Transition eingeführt, welche eine Interaktion des Systems mit äußeren Einflüssen erlauben. Diese Transitionen nennt man kalte Transitionen. Es wird generell zwischen heißen und kalten Transitionen unterschieden. Eine heiße Transition wird einem System immer automatisch aktiv, sobald ihre Vorbedingungen erfüllt sind. Eine kalte Transition ist zusätzlich noch von äußeren Bedingungen abhängig und wird somit nicht automatisch aktiv. Zur besseren Kennzeichnung werden kalte Transitionen mit dem Zeichen „ε“ [9] gekennzeichnet, was wiederum auf ihren externen Charakter hinweisen soll.
Nachfolgend, in der Abbildung "Petri-Netz „Kaffeezubereitung“ mit ein-/ausgehenden Transitionen", wurde das Modell der Kaffeezubereitung nun um das Nachfüllen der Kaffeebohnen und Kaffeetassen, sowie um die Entnahme des fertigen Kaffees vom Küchentisch erweitert.
In dem Beispiel würde immer so viel Kaffee gekocht wie, aufgrund der verfügbaren Kaffeetassen und Kaffeebohnen möglich ist. Die Entnahme der fertigen Kaffees aus dem Platz „Küchentisch“ ist möglich, tritt jedoch nicht sicher ein. Wird die Transition „Kaffee trinken“ nicht von außen abgerufen, so füllt sich der Küchentisch immer weiter an.
Eine weitere mögliche Anwendung von Transitionen und Kanten ist die Angabe einer zusätzlichen Bedingung. Diese kann den Inhalt eines übergebenen Token prüfen und verhält sich damit wie eine Variablenabfrage, wobei der Token die Variable darstellt. Damit lassen sich beispielsweise auch Zähler abbilden. Die Bedingung wird dazu in das Transition-Symbol geschrieben und muss zusätzlich zu den eingehenden Kanten erfüllt werden.
Um die Anwendung von Bedingungen in Transitionen zu erläutern wurde das Kaffeezubereitungsbeispiel nun um einen Hinweis zu Entkalkung der Kaffeemaschine erweitert, der nach 100 zubereiteten Kaffees auftreten, und dann nach der Bestätigung des Hinweises durch die Serviceperson wieder auf 0 gesetzt werden, soll.
Da die Geschwindigkeit der Ausführung der Transitionen nicht einheitlich ist, wird im aktuellen Beispiel die asynchrone Abarbeitung des Petri-Netzes deutlich. So kann die Transition „Kaffeezubereitung“ natürlich auch mehr Zeit in Anspruch nehmen, als die simple Transition „Zähler ausführen“. Durch das Auslösen der Transitionen mittels Token, wird eine Verteilung der Aufgaben erreicht, welche zwar parallel jedoch nicht unbedingt synchron abgearbeitet werden. Da es sich bei Transitionen immer um Aktionen handelt, welche asynchron laufen, darf eine Transition nie direkt eine Kante zu einer anderen Transition haben, da dadurch eine direkte Abhängigkeit entstehen würde. Auch darf im Gegenzug kein Platz eine direkte Kante zu einem anderen Platz haben, da ohne Transition nicht klar wäre, in welchem Platz sich ein Token dann befinden würde.
Berechnungen und Plätze mit Zahlenwerten
Zusätzlich zur einfachen Entnahme und Generierung von Token können Kanten auch Berechnungen mit der Token Anzahl des zugehörigen Platzes durchführen. Die Funktionsweise und Darstellung dieser Rechenmöglichkeiten sind nun nachfolgend, anhand eines einfachen Modells mit zwei Plätzen, einer Transition und den zugehörigen Kanten, genauer beschrieben.
Den Plätzen A und B in Abbildung 40 können durch ihre zugehörigen Kanten und die Transition b Token entnommen und hinzugefügt werden. Dies geschieht normalerweise in Richtung der Pfeile. Eine Kante mit einem Pfeil in Richtung des Platzes legt einen Token in dem Platz ab und eine Kante mit einem vom Platz wegzeigenden Pfeil entnimmt einen Token aus dem Platz.
Wenn ein Platz nur einen Standardtyp von Token enthält, kann er auch als Wert geschrieben werden. In der Abbildung "Plätze mit der Token Anzahl in Werte Schreibweise" noch einmal das vorherige Beispiel in der Schreibweise als Werte.
Es ist nicht relevant, ob ein Platz als Oval, oder als Kreis gezeichnet wird. Bei der Darstellung der Token Anzahl als Zahl ist ein runder Platz ausreichend und platzsparender. In der Abbildung "Runde Plätze mit der Token Anzahl in Werte Schreibweise" ist noch einmal dasselbe Modell mit runden Plätzen dargestellt.
Durch die Angabe einer Formel mit einer Variable, können Berechnungen mit dem
Wert (der Token Anzahl) des Platzes durchgeführt werden. Die Variable (z.B. x) steht dabei für den aktuellen Wert des zugehörigen Platzes. In der Abbildung "Berechnungen durch Formelangaben der Kanten" wird durch die Ausführung der Transition b die Token Anzahl von A um zwei Reduziert und die Token Anzahl von C um 5 erhöht. Die Kante zwischen A und c ist dabei die Vorbedingung zur Ausführung der Transition. Sind nicht genügend Token in A um die Berechnung durchzuführen, wird sie auch nicht ausgeführt. Nach der Ausführung des Beispiels hat der Platz A den Wert 0 und der Platz C den Wert 5.
Diese Berechnungen müssen jedoch nicht zwingend der Pfeilrichtung entsprechen. Die Pfeilrichtung bezieht sich bei einer Formel nur auf die Auslösung der Transition (Pfeil zur Transition löst sie aus. Pfeil weg von der Transition geschieht durch die Auslösung). Ein Beispiel einer Token Entnahme entgegen der Pfeilrichtung ist in Abbildung 44 dargestellt. Dabei werden bei Erfüllung der Kante zwischen A und b jeweils fünf Token von C abgezogen. Nach Ausführung des Beispiels hat somit A den Wert 0 und C den Wert 5.
Der Wert (=Token Anzahl) eines Platzes darf nicht negativ sein. Wäre der Wert des Platzes C hier nicht 10, sondern kleiner als 5, dann wäre das ein Fehler. Dieser kann jedoch, wie nachfolgend beschrieben, durch eine zusätzliche Bedingung in der Transition verhindert werden.
Soll der Wert eines Platzes an eine Bedingung übergeben werden, erfolgt dies durch eine eigene Kante die nur den Variablennamen (z.B. x) enthält. Diese Kante führt keine Änderung an dem Wert des Platzes durch, sondern übergibt nur den Wert an die Transition. Das Modell aus der Abbildung "Berechnungen durch Formelangaben der Kanten entgegen der Pfeilrichtung" wurde in der Abbildung "Bedingung einer Transition mit Übergabe des Wertes eines Platzes" um eine Bedingung erweitert, welche überprüft, ob der Wert des Platzes C größer oder gleich 5 ist, um einen möglichen Fehler bei der Ausführung der Transition zu verhindern. Der Wert des Platzes C wird dazu durch eine eigene Kante mit der Variable y an die Bedingung der Transition b übergeben.
Abbildung verteilter Systeme
Durch die Anwendung von kalten und warmen Transitionen können Systemgrenzen und Schnittstellen definiert werden. Im Fall eines verteilten Systems können damit nun asynchrone Abhängigkeiten zwischen einzelnen Systemen modelliert werden. Um ein Beispiel für eine solche Schnittstelle zu schaffen wird nachfolgend, in der Abbildung "Petri-Netz „Geschirrspülen“", ein einfaches Modell eines Geschirrspülers entwickelt, welches dann mit dem Petri-Netz der Kaffee Zubereitung kombiniert wird.
Nun wird das Petri-Netz des Geschirrspülens mit dem der Kaffeezubereitung kombiniert. Die Nahtstellen sind dabei die kalte Transition „Schmutzige Tasse einfüllen“ und „Kaffee trinken“, sowie „Tasse nachfüllen“ und „Saubere Tasse entnehmen“. Da eine Transition nicht direkt in eine andere Transition übergehen kann, sonst wären die Vorgänge synchron und damit nur eine einzige Transition, muss dazwischen jeweils ein eigener Platz definiert werden, an dem sich die Tassen befinden, solange die „abholende“ Transition noch nicht bereit ist. Die Kombination der beiden Systeme ist nun nachfolgend in der Abbildung "Kombiniertes Petri-Netz „Kaffeekochen und Geschirrspülen“" dargestellt.
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 der Abbildung "EPK: Ereignis und Funktion" dargestellt.
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 der Abbildung "EPK: Operatoren" angeführt.
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 der Abbildung "EPK: Synchronisation mehrerer paralleler Kontrollflüsse" dargestellt.
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 der Abbildung "EPK: Prozesswegweiser" dargestellt.
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 der Abbildung "eEPK: Organisationseinheit und Informationsobjekt" dargestellt.
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 der Abbildung "oEPK: Modell einer Objektklasse" dargestellt.
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 der Abbildung "eEPK Beispiel einer Kaffeeküche", 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.
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 der Abbildung "BPMN Flussobjekte" ersichtlich.
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 der Abbildung "BPMN Aktivitäten mit Ausprägung" aufgelistet und beschrieben.
| Aktivitätsausprägung | Symbol | Beschreibung |
|---|---|---|
| Service-Aktivität | wird durch ein automatiches System durchgeführt | |
| Sende-Aktivität | führt das Senden einer Nachricht durch (Erstellung und Versand) | |
| Empfangs-Aktivität | führt das Empfangen einer Nachricht durch (Empfang und Verarbeitung) | |
| Benutzer-Aktivität | wird durch einen oder mehrere Menschen durchgeführt | |
| Manuelle-Aktivität | wird durch einen oder mehrere Menschen manuell und ohne IT Unterstützung durchgeführt | |
| Geschäftsregel-Aktivität | führt eine BPMN Geschäftsregel aus (wird in dieser Lektion nicht weiter behandelt) | |
| Script-Aktivität | führt ein Script innerhalb der Prozessumgebung aus (wird in dieser Lektion nicht weiter behandelt) |
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 der Abbildung "BPMN Sub-Prozesses Aufruf" dargestellt.
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 der Abbildung "BPMN Event-Typen" dargestellt.
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)
| Symbol | Zulässig als Start-Event | Zulässig als Zwischen-Event | Zulässig als Ende-Event | |
|---|---|---|---|---|
| Nachricht | Ja | Ja | Ja | |
| Signal | Ja | Ja | Ja | |
| Timer | Ja | Ja | Nein | |
| Bedingung | Ja | Ja | Nein | |
| Verknüpfung | Nein | Ja | Nein | |
| Terminierung | Nein | Nein | Ja |
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 der Abbildung "BPMN: Exklusives Gateway" 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.
Bei einem inklusiven Oder-Gateway werden mögliche Pfade vorgegeben, von denen einer oder mehrere eingeschlagen werden können. In der Abbildung "BPMN: Inklusives Gateway" 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.
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 der Abbildung "Parallel Gateway" 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.
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 der Abbildung "BPMN: komplexes Gateway" 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.
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 der Abbildung "BPMN: Gruppierung" 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.
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 der Abbildung "BPMN: Pool mit Lanes" 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.
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 der Abbildung "BPMN: Mehrere Pools und Nachrichtenflüsse" 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.
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.
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.
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 dem Kapitel ER-Modell 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.
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 der Abbildung "Klasse mit instanziierten Objekten" 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 UML Klassendiagramm, genauer beschrieben wird.
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 der Abbildung "Klasse mit instanziierten Objekten" 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 der Abbildung "Klasse mit Vererbung". 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.
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 der Abbildung "Klasse mit Vererbung" 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 der Abbildung "Klassen mit Get- und Set-Methoden" ersichtlich.
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 der Abbildung "Klassen mit überlagerter Methode getKundenString()" ersichtlich.
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.
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 UML Klassendiagramm).
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.
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.
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.
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.
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:
- Use-Case-gesteuert,
- Iterativ,
- Architekturzentriert und
- Inkrementell.
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 [10] . In den nachfolgenden Abschnitten UML Klassendiagramm und UML Anwendungsfalldiagramm (Use Case Diagramm) werden das Objektdiagramm und das Anwendungsfalldiagramm genauer behandelt.
Strukturdiagramme
| Klassendiagramm
Stellt den „strukturellen“ Kern von UML dar, fasst gleichartige Objekte zusammen und definiert die Beziehungen untereinander |
|
|---|---|
|
Objektdiagramm Stellt einen prototypischen Ausschnitt aus dem System dar, besteht nur aus Objekten |
|
|
Paketdiagramm Erlaubt die Gruppierung von Systembestandteilen und verschiedenen Ebenen und dient zur Reduzierung der Komplexität in der Darstellung |
|
|
Komponentendiagramm Definiert Komponenten (modulare Systemteile) und deren Abhängigkeiten unter einem softwareorganisatorischen Aspekt |
|
|
Kompositionsstrukturdiagramm Erlaubt die (kontextabhängige) hierarchische Strukturierung von Systemteilen |
|
|
Verteilungsdiagramm Beschreibt die eingesetzte Hardwareinfrastruktur und deren Aufbau und das Laufzeitsystem |
Verhaltensdiagramme
| Anwendungsfalldiagramm
Spezifiziert die Funktionalität des zu entwickelnden Systems aus der Benutzersicht auf der Basis von Szenarien |
|
|---|---|
|
Aktivitätsdiagramm Stellt den Kontroll- und Datenfluss von Abläufen im System dar (Prozessmodellierung) |
|
|
Zustandsdiagramm Definiert das Verhalten eines Objekts über seine erlaubten Zustände und Zustandsübergänge (Lebenszyklus eines Objekts) |
|
|
Sequenzdiagramm Definiert die Interaktionen von Objekten bei einer spezifischen Aufgabe, der Fokus liegt hier bei der Beschreibung der zeitlichen Reihenfolge |
|
|
Kommunikationsdiagramm Eigentlich analog zum Sequenzdiagramm werden die Interaktionen zwischen Objekten beschrieben, der Schwerpunkt liegt hier aber auf den strukturellen Beziehungen |
|
|
Zeitdiagramm Spezielle Form des Interaktionsdiagramms für präzise zeitliche Spezifikationen, eignet sich für die Beschreibung von Echtzeitsystemen |
|
|
Interaktionsübersichtsdiagramm Beschreibt abstrakt den Kontrollfluss zwischen verschiedenen Interaktionsabläufen, erlaubt die Beschreibung der logischen Reihenfolge von Interaktionsdiagrammen |
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 "Klassendiagramm"). Mit Ausnahme des Namens der Klasse können alle weiteren Beschreibungselemente fehlen.
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 der Abbildung "Erweitertes Klassendiagramm" abgebildet.
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 "UML Klasse Angestellter" angegeben.
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 "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
* Reflexive Assoziation
|
|
|---|---|
|
|
|
|
|
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 die Abbildung "Objektdiagramm", die die Klasse und das entsprechende Objekt darstellt.
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.
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 "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 der Abbildung "UML Überdeckung":
Mehrfachvererbungen
UML unterstützt auch die Notation von Mehrfachvererbungen. Siehe hierzu das folgende Beispiel in der Abbildung "UML Mehrfachvererbung":
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 "UML Aggregration"):
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 "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 " UML Beispiel Fachhochschule" und Abbildung " UML Beispiel Bank") sind die Ausschnitte zweier Realitäten modelliert, eine Fachhochschule und eine Bank. Sie erkennen hier den Einsatz von Generalisation und Aggregation.
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.
Darstellung
Beginnen wir mit einem einfachen Beispiel für ein Anwendungsfalldiagramm, das die wichtigsten Elemente dieser Notationsform enthält (siehe Abbildung "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:
* Eine Reise für eine Gruppe buchen:
|
|
|---|---|
|
|
|
|
|
Wir können daher diesen Use cases in das folgende Anwendungsfalldiagramm eintragen (Abbildung "Use Case Reisebüro Buchungssystem"):
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 "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 "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 "Use Case Generalisierung"):
Wir können jetzt diese Beziehungen in unser ursprüngliches Anwendungsfalldiagramm eintragen und dadurch die Beschreibung erweitern (Abbildung "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.
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:
Finde die Aktoren des Systems
Finde für jeden Aktor heraus:
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.
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.
<span id="literaturverzeichnis"></span>
= Literaturverzeichnis =
Becker, J., Rosemann, M., & Schütte, R. (1995). Grundsätze ordnungsmäßiger Modellierung. Wirtschaftsinformatik, 37.
Chen, P. (1976). The Entity-Relationship Model – Toward a Unified View of Data. In Transactions ODS Bd. 1, pp 9–36.
Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures, CHAPTER 5, Representational State Transfer (REST). Abgerufen am 1. Juni 2014 von http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Freund, J., & Rücker, B. (2014). Praxishandbuch BPMN 2.0, 4., aktualisierte Auflage. München: Carl Hanser Verlag GmbH & Co. KG.
Galiegue, F. (30. Jänner 2013). JSON Schema: core definitions and terminology. Abgerufen am 6. November 2014 von http://json-schema.org/latest/json-schema-core.html
Harold, E. R., & Means, S. (2005). XML in a Nutshell. Deutsche Übersetzung von Katharina Udemadu, Kathrin Lichtenberg und Lars Schulten. 3. Auflage. Köln: O'Reilly Verlag.
Keller G., N. M.-W. (1992). Semantische Prozeßmodellierung auf der Grundlage „Ereignisgesteuerter Prozeßketten (EPK)“. Saarbrücken: Veröffentlichungen des Instituts für Wirtschaftsinformatik (IWi), Universität des Saarlandes, Heft 89.
Kohavi, Z., & Jha, N. K. (2010). Switching and Finite Automata Theory, Third Edition. New York: Cambridge University Press.
Martin, R. C. (2000). Design Principles and Design Patterns. Abgerufen am 11. Dezember 2014 von http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
Nassi, I., & Shneiderman, B. (1973). Flowchart techniques for structured programming. New York: State University of New York at Stony Brook, Department of Computer Science, SIGPLAN Notices 12.
Object Management Group (OMG). (2011). Business Process Modeling Notation (BPMN) Version 2.0. Abgerufen am 28. November 2014 von http://www.omg.org/spec/BPMN/2.0/PDF/
Object Management Group (OMG). (2011). UML 2.4.1. Abgerufen am 11. Dezember 2014 von http://www.omg.org/spec/UML/2.4.1/
Oeser, R. (2012). Aus Zahlen werden Fakten. Wien.
Oesterreich, B. (2006). Analyse und Design mit UML 2.1, 8. aktualisierte Auflage. München: Oldenbourg Verlag.
Reisig, W. (2010). Petrinetze - Modellierungstechnik, Analysemethoden, Fallstudien. Wiesbaden: Vieweg+Teubner Verlag; Springer Fachmedien Wiesbaden GmbH.
RFC Network Working Group. (2006). RFC 4627, The application/json Media Type for JavaScript Object Notation (JSON). Abgerufen am 3. November 2014
Scheer, A.-W. (2001). ARIS - Modellierungsmethoden, Metamodelle, Anwendungen, Vierte Auflage. Berlin Heidelberg: Springer-Verlag.
Scheer, A.-W., Nüttgens, M., & Zimmermann, V. (1997). Objektorientierte Ereignisgesteuerte Prozeßkette (oEPK) - Methode und Anwendung. Saarbrücken: Veröffentlichungen des Instituts für Wirtschaftsinformatik (IWi), Universität des Saarlandes, Heft 141.
Schütte, R. (1997). Die neuen Grundsätze ordnungsmäßiger Modellierung (Paper zum Forschungsforum `97, Leipzig 16.09-20.09.97). Münster.
Stachowiak, H. (1973). Allgemeine Modelltheorie. Wien: Springer Verlag.
Wang, J. (2014). Understanding of Finite State Machine [Kindle Edition]. Jason Wang.
World Wide Web Consortium (W3C). (26. November 2008). Extensible Markup Language (XML) 1.0 (Fifth Edition). Abgerufen am 4. November 2014 von http://www.w3.org/TR/2008/REC-xml-20081126/
World Wide Web Consortium (W3C). (3. Oktober 2014). Extensible Markup Language (XML). Abgerufen am 3. November 2014 von http://www.w3.org/XML/
- ↑ http://www.faz.net/aktuell/gesellschaft/magnetbahn-unfall-23-menschen-sterben-in-den-truemmern-des-transrapid-1357701.html, Aufruf der Seite am 03.11.2014
- ↑ Synonyme sind unterschiedliche Benennungen für den gleichen Begriff. (z.B. kann für den Begriff Auto auch Kraftfahrzeug, Wagen oder Automobil verwendet werden).
- ↑ Ein Homonym ist die gleiche Benennung für zwei oder mehrere Begriffe (z.B. Golf ist ein Sport, eine Meeresbucht und ein Fahrzeug).
- ↑ Vgl Thomas J.Sebestyen, 2010, S109 ff
- ↑ Vgl. www-w3-org./TR/xmlschema11-1 1.2 Zweck.
- ↑ Vgl Thomas J.Sebestyen, 2010, S109 ff
- ↑ Vgl Thomas J.Sebestyen, 2010, S109 ff
- ↑ Die Zusätze BE und LE steht für Big Endian und Little Endian und beziehen sich auf die Reihenfolge in der die einzelnen Bits des Zeichens gespeichert werden. Somit steht das erste Bit des Zeichens entweder links (LE) oder rechts (BE) in der binären Abbildung.
- ↑ Epsilon
- ↑ Die graphischen Darstellungen sind aus Wikipedia, http://de.wikipedia.org/