03 Ereignisdiskrete Prozessmodellierung mit der UML Flashcards

1
Q

Modell

A

Ein Modell ist ein System, das als Repräsentant eines komplizierten Originals aufgrund mit diesem gemeinsamer, für eine bestimmte Aufgabe wesentlicher Eigenschaften von einem dritten System benutzt, ausgewählt oder geschaffen wird, um letzterem die Erfassung oder Beherrschung des Originals zu ermöglichen oder zu erleichtern, beziehungsweise um es zu ersetzen.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Kerneigenschaften eines Modells

A

o Ziel: Umweltverständnis, Ideenentwicklung und -umsetzung
o Semantik: Bedeutung des Modells
o Notation: Erscheinungsbild des Modells

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Merkmale eines Modells

A
  • Abbildungsmerkmal
  • Verkürzungsmerkmal
  • Pragmatisches Merkmal
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Merkmale eines Modells: Abbildungsmerkmal

A

Bei Modellen handelt es sich um Abbildungen und Repräsentationen natürlicher und künstlicher Originale.

 Technischer, natürlicher Originale
 Symbole, Vorstellungen, Begriffe, physische Originale
 Räumliche, zeitliche Originale/Veränderungen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Merkmale eines Modells: Verkürzungsmerkmal

A

Modelle erfassen nicht alle Attribute des durch sie repräsentierten Originals, sondern die für den Ersteller eines Modells oder für die Benutzer des Modells relevant sind.
 Modell- und Originalattribute müssen bekannt sein
 Attribute des Originals werden im Modell reduziert
 Zu modellierende Attribute sind subjektiv und/oder zielgerichtet

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Merkmale eines Modells: Pragmatisches Merkmal

A

Modelle sind ihren Originalen nicht immer eindeutig zugeordnet und können sie auch ersetzen.
 Modell ersetzt das Original für eine bestimmte Person & einen bestimmten Zeitraum
 Modell ersetzt das Original unter Einschränkungen gedanklicher/tatsächlicher Operationen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Modellierung: Analyseprozess

A

o Mit der Erhebung der Anforderungen kommt ein Analyseprozess in Gang, der über die Dokumentation und Validierung der Anforderungen zu einer Spezifikation führt.
o Im Anschluss an Analyseprozess folgt die Festlegung der technischen Spezifikation und die Implementierung

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Modellierung: Vorgehen im Analyseprozess

A

Analytiker und Fachexperten finden Fakten -> Wissensträger steuern das Fachwissen bei, Analytiker das methodische Wissen

Fakten werden in Diagrammen und Dokumenten repräsentiert -> Normalerweise durch Analytiker

Wissensträger validiert Fakten

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Modellierung: Analyseprozess - Techniken für die Validierung von Fakten

A
  • Beobachtung im Feld
  • Mitarbeit bei den zu untersuchenden Prozessen
  • Übernahme der Rolle eines Außenstehenden
  • Verwendung von Fragebogen
  • Durchführung von Interviews
  • Brainstorming mit den Beteiligten
  • Diskussion mit Fachexperten
  • Durchsicht bestehender Formulare, Dokumentationen, Beschreibungen und Handbücher
  • Beschreibung der Aufbau- und Ablauforganisation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Resultat des Analyseprozesses

A

Spezifikation, die aus ihrem Modell und anderen Repräsentationen besteht

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Vorüberlegung zur Modellierung - Fragen zur Definition von Zweck und Zielgruppe

A

o Wer spezifiziert?
o Für wen wird spezifiziert?
o Was soll spezifiziert werden?
o Zu welchem Zweck soll das Modell benutzt werden?
o Wie tief ist das Business-Know-how?
o Welchen Detaillierungsgrad verlangt die Zielgruppe?
o Wie viel Zeit steht der Zielgruppe zur Verfügung, um die Modelle zu lesen und zu interpretieren?
o Welche Sprache kann in dem Modell verwendet werden?
o Welche Abstraktionsebene soll gewählt werden?

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Grafische Beschreibungssprachen - Untergruppen

A
  • Funktionsorientiert
  • Prozessorientiert
  • Objektorientiert
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Grafische Beschreibungssprachen zur Modellierung von Arbeitsprozessen - Funktionsorientiert

A
  • Structured Analysis and Design Technique (SADT)
  • IDEF-Diagramme (Integration DEFinition)
  • Datenflussdiagramm (Data Flow Diagram DFD)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Grafische Beschreibungssprachen zur Modellierung von Arbeitsprozessen - Prozessorientiert

A
  • Petri-Netze
  • K3 (Koordination, Kooperation, Kommunikation)
  • Erweiterte Ereignisgesteuerte Prozesskette (eEPK)
  • Business Process Modeling Notation (BPMN)
  • DIN 66001
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Grafische Beschreibungssprachen zur Modellierung von Arbeitsprozessen - Objektorientiert

A
  • Unified Modeling Language
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Funktionsorientierte Modellierungsansätze: Structured Analysis and Design Technique (SADT)

A

Methode für den Entwurf und die Analyse von Systemen unterschiedlicher Art.

 Funktionselemente, deren Input und Output genau angegeben wird, werden differenziert, sowie die Regelungs- und Steuerungsfunktion
 Notwendige Mechanismen zur Ausführung der Funktion werden spezifiziert

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Funktionsorientierte Modellierungsansätze: IDEF-Diagramme

A

Oberbegriff für eine auf SADT basierende Menge von Werkzeugen zur Modellierung von Prozessen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Funktionsorientierte Modellierungsansätze: Datenflussdiagramme

A

Können Funktionalitäten eines Realsystems durch Prozesse und Aktivitäten grafisch abbilden (Ausdrucks- und Anwendungsmöglichkeiten jedoch sehr beschränkt)
 Funktionsorientierte Sprachen eignen sich nur bedingt zur Modellierung von Arbeitsprozessen. -> Meist Spezialisiert und eignen sich hauptsächlich zur funktionalen Dekomposition von Systemkomponenten, Modellierung von Elementen und deren Beziehungen sowie dynamisches Prozessverhalten nur eingeschränkt oder gar nicht möglich

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Prozessorientierte Modellierungsansätze: Petri-Netze

A

Formale Methode zur mathematischen Modellierung von Systemen, in denen mehrere Prozesse simultan bzw. nebenläufig ablaufen können.
 Eignen sich aufgrund der formalen Beschreibung und geringen Anschaulichkeit eher zur theoretischen Analyse und Simulation von Arbeitsprozessen.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Prozessorientierte Modellierungsansätze: eEPK

A

Dienen der Darstellung von Geschäfts- und Arbeitsprozessen aus Sicht der Wirtschaftsinformatik
 Werden häufig zur Analyse von Abläufen auf Abteilungsebene sowie zur computergestützten Optimierung eingesetzt.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Prozessorientierte Modellierungsansätze: UML

A

Standardisierte Sprache zur Modellierung von Systemen.
 Für die Modellierung von Geschäftsprozessen können je nach Zweck unterschiedliche Diagrammtypen eingesetzt werden.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Prozessorientierte Modellierungsansätze: K3-Methode

A

Speziell für die Modellierung kooperativer, schwach strukturierter Arbeitsprozesse entwickelt, findet aber auch Verwendung in der Modellierung stark strukturierter Geschäftsprozesse
 Koordination, Kooperation, Kommunikation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Prozessorientierte Modellierungsansätze: BPMN

A

Grafische Spezifikationssprache mit Ursprung in der Wirtschaftsinformatik
 Stellt eine umfangreiche Notation zur Verfügung, mit denen Fach- und Software-Spezialisten Geschäfts- und Arbeitsprozesse modellieren können.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

UML - Definition

A

Die UML ist eine Sprache und Notation zur Spezifikation, Konstruktion, Visualisierung und Dokumentation von Modellen für Softwaresysteme.

o UML kann als Basis für verschiedene Methoden sein -> Stellt eine definierte Menge von Modellierungskonstrukten mit einheitlicher Notation und Semantik bereit

25
Q

UML - Ziel

A

Spezifikation, Konstruktion und Dokumentation von Software und Systemen

26
Q

UML - Grundidee

A

Der objektorientierten Programmierung (OOP) ein standardisiertes Entwickler- und Analysetool zur Seite stellen

  • Eignet sich für konkurrierende, verteilte, zeitkritische, sozial eingebettete Systeme und mehr
27
Q

UML - Bestandteile

A

o Im Zentrum steht das Objekt.  Es enthält Attributfelder, in welchen die Daten stehen
o Welche Attributfelder das Objekt besitzt hängt von seiner Klasse ab
o Klassen sind das Äquivalent von Entitätstypen
o Assoziationen  Beziehungen, Beziehungstypen und Kardinalität
o Sieht in der Realität vorkommende Gegenstände als Objekte an.  Objekte können sich wiederum aus anderen Objekten zusammensetzen

28
Q

UML - Objekte

A
  • Besitzen Eigenschaften (Attribute)
  • Zeigen Verhalten (Methoden)
  • Kommunizieren mit anderen Objekten (Nachrichten)
29
Q

UML - Akteure

A
  • Verwenden das System
  • Stellen Anforderungen (Requirements) an das System
30
Q

UML - Klassen

A

Fassen mehrere ähnliche Objekte (Instanzen) zusammen

31
Q

Unterschiedliche Sichten innerhalb der UML

A

o Benutzersicht
-> Anwendungsfalldiagramme

o Strukturelle Sicht
-> Klassendiagramme, Objektdiagramme

o Verhaltenssicht
-> Sequenz-, Interaktions-, Zustands-, Aktivitätsdiagramme

o Implementierungssicht
-> Komponentendiagramme, Modell-Management Diagramme

o Umgebungssicht
-> Einsatzdiagramme

o Anforderungen
-> Anwendungsfalldiagramme

o Statistische Sicht
-> Klassendiagramme, Objektdiagramme

o Dynamische Sicht
-> Sequenz-, Interaktions-, Zustands-, Aktivitätsdiagramme

32
Q

Besondere Stärke der UML

A

Bereitstellung von standardisierten Modellierungsnotationen und -prinzipien zur Modellierung unterschiedlicher Ansichten

33
Q

UML-Verhaltensdiagramme

A

Ein Verhaltensdiagramm modelliert die dynamischen Aspekte eines Systems

  • Soll Klarheit bspw. über interne Abläufe, Geschäftsprozesse oder das Zusammenwirken verschiedener Systeme schaffen.
34
Q

Verhalten

A

Menge von Prozessen, grundsätzliche strukturelle Merkmale eines Objektes über den Verlauf der Zeit

35
Q

Prozess

A

Ablauf von Aktivitäten zur Erreichung eines vorgegebenen Ziels
o Gerichteter Ablauf
o Verschachtelung möglich

36
Q

UML-Verhaltensdiagramme: Modelliert werden…

A

o Abläufe mit mehreren Objekten
o Interaktionen zwischen Objekten
o Objekte, die ihre Zustände durch Verhalten ändern können

37
Q

UML-Verhaltensdiagramme: Annahmen zur Spezifikation eines Verhaltens

A

o Verhalten geht immer von Instanzen (Objekten) aktiver Klassen aus
o Verhalten ist immer ereignisgesteuert

38
Q

UML-Verhaltensdiagramm: Aktion

A

Fundamentale Bausteine der Verhaltensbeschreibung

o Aktionen können mit anderen Verhaltensbeschreibungen (Aktivitäten, Interaktionen oder Zustandsautomaten) kombiniert werden

39
Q

UML-Verhaltensdiagramm: Verhaltensbeschreibungen

A

 Besitzen Parameter, mit denen vor der Verhaltensführung Werte übergeben werden können
* Parameter sind Platzhalter, über die nach der Verhaltensführung Werte zurückgeliefert werden

 Können auf andere Modellelemente innerhalb eines Kontexts zugreifen

40
Q

UML-Verhaltensdiagramm: Zustandsdiagramm

A

Ein Zustandsdiagramm zeigt eine Folge von Zuständen, die ein Objekt im Laufe seines Lebens einnehmen kann und aufgrund welcher Stimuli Zustandsänderungen stattfinden

o Beschreibt eine hypothetische Maschine (endlicher Automat), die sich zu jedem Zeitpunkt in einer Menge endlicher Zustände befindet und besteht aus:
 Einer endlichen, nicht-leeren Menge von Zuständen
 Einer endlichen, nicht-leeren Menge von Ereignissen
 Zustandsübergängen
 Einen Anfangszustand
 Und einer Menge von Endzuständen

41
Q

Zustandsdiagramm: Ereignis

A

Vorkommnis, das in einem gegebenen Kontext eine Bedeutung hat, sich räumlich und zeitlich lokalisieren lässt und gewöhnlich einen Zustandsübergang (Transition) auslöst

 Ereignisse lösen Übergänge von einem Zustand zum nächsten aus
 Ein Ereignis besteht aus einem Namen und einer Liste möglicher Argumente
 Ursachen für Ereignisse:
* Das Objekt erhält eine Nachricht
* Eine (für einen Übergang definierte) Bedingung wird erfüllt
* Zeitereignisse:
o After: relativer Zeitpunkt -> z.B. nach 30 min
o At: exakter Zeitpunkt -> z.B. wenn… (Vorlagedatum)

42
Q

Zustandsdiagramm entwickeln - Checkliste

A
  • Vollständigkeit prüfen -> Sind alle fachlich zulässigen Zustände des Objektes dokumentiert?
  • Implikationen identifizieren -> Sind die Implikationen der identifizierten Zustände durchdacht und berücksichtigt worden?
  • Folgezustände/Transitionen untersuchen  Sind die möglichen Folgezustände und Transitionen zu jedem einzelnen Zustand untersucht worden?
  • Operationen kennzeichnen -> Sind alle Operationen der betroffenen Klasse als zustandsabhängig bzw. -unabhängig gekennzeichnet worden (z.B. durch einen entsprechenden Eigenschaftswert)?
43
Q

UML - Interaktionsdiagramme

A

Interaktionsdiagramme zeigen, wie Nachrichten zwischen verschiedenen Interaktionspartnern in einem bestimmten Kontext ausgetauscht werden.

44
Q

Interaktion

A

Aufeinander bezogenes Handeln zweier oder mehrerer Akteure/Objekte
o Wechselbeziehung zwischen Akteuren/Objekten
o Ziel: Nachrichten- Datenaustausch
o Interaktionsinhalt: Signale, Operationsaufrufe
o Interaktionssteuerung: Bedingungen, Zeitliche Ereignisse
o Interaktionen werden als Signale und Nachrichten dargestellt
-> Signale werden versendet, ein Feedback wird nicht zwangsläufig erwartet (Asynchrone Kommunikation)

45
Q

Bestandteile von Interaktionsdiagrammen

A

Interaktionsdiagramme bestehen immer aus
 Kommunikationspartner/Objekte und deren Lebenslinien
 Interaktionen
 Nachrichten
 Mittel zur Flusskontrolle

46
Q

Arten von Interaktionsdiagrammen

A
  • Sequenzdiagramm
  • Kommunikationsdiagramm
  • Zeitdiagramm
  • Interkationsübersichtsdiagramm
47
Q

Interaktionsdiagramme: Sequenzdiagramm

A

Interaktionspartner/Objekte werden horizontal angeordnet, während die Zeit vertikal verläuft
 Nachrichtenaustausch zwischen den Interaktionspartnern wird über Pfeile ausgedrückt
 Stellt in der Regel einen Weg durch einen Entscheidungsbaum innerhalb eines Systemablaufes dar.

-> Zeitlich, logisch
-> Fokus: Zusammenarbeit der Interaktionspartner

48
Q

Interaktionsdiagramme: Kommunikationsdiagramm

A

Strukturell orientiert, keine Zeitachse
 Hauptziel: Aufzeigen der Beziehung zwischen den einzelnen Interaktionspartnern
 Zeigt ähnliche Sachverhalte wie Sequenzdiagramm, jedoch aus anderer Perspektive  Rollen und ihre Zusammenarbeit untereinander stehen im Vordergrund

49
Q

Interaktionsdiagramme: Zeitdiagramm

A

Ermöglichen den Ausdruck von Zustandsänderungen
 Zustände können detaillierter spezifiziert werden
 Ein Interaktionspartner befindet sich immer in einem bestimmten Zustand
 Zustände, die ein Interaktionspartner annehmen kann, können explizit eingezeichnet werden -> Übergänge von Zuständen lassen sich darstellen

-> Zeitlich präzise

50
Q

Interaktionsdiagramme: Interaktionsübersichtsdiagramm

A

Verknüpft unterschiedliche Interaktionsdiagramme miteinander
 Können für komplexe Systeme sehr groß werden

-> Interaktionsorientiert

51
Q

Einsatzbereiche von Interaktionsdiagrammen

A

o Modellierung von Interaktionen eines Systems mit seiner Umwelt

o Modellierung des Zusammenspiels der internen Struktur einer Klasse, Komponente oder Kollaboration

o Modellierung der Spezifikation von Schnittstellen zwischen Systemteilen (Zusammenspiel angebotene/benutzte Schnittstellen)

o Interaktionsdiagramme eignen sich nicht in das Innere der Systemgrenzen zu schauen -> Black Box

52
Q

UML-Verhaltensdiagramme: Sequenzdiagramm

A

Zeigt eine Reihe von Nachrichten, die eine ausgewählte Menge von Beteiligten (Rollen und Akteuren) in einer zeitlich begrenzten Situation austauscht, wobei der zeitliche Ablauf betont wird.

Darstellung von Interaktionen in 2 Dimensionen
o „horizontal“: Interaktionspartner in Form von Rollen (Anordnung kann beliebig erfolgen)
o „vertikal“: Zeitachse (oben nach unten)

53
Q

Einsatz von Sequenzdiagrammen

A

o Abbildung System <-> Umwelt Interaktion
o Darstellung der internen Klassenstruktur
o Spezifikation von Systemschnittstellen
o Logik von komplexen Verfahren darstellen
o Interaktion zwischen Objekten und Komponenten
o Funktionsweise eines Szenarios planen und verstehen

54
Q

Sequenzdiagramme - Wichtigste Notationselemente

A

o Lebenslinien/Zeitlinie: Stellen die Kommunikationspartner dar -> Stellt das Voranschreiten der Zeit des Objektes/der Rolle dar

o Nachrichten: Werden durch Pfeile repräsentiert

55
Q

Sequenzdiagramme: Notation

A

o Zeitlicher Verlauf der Nachrichten steht im Vordergrund -> Rollen/Objekte werden lediglich mit senkrechten Lebenslinien gezeigt

o Aktivitätsbalken symbolisiere den Steuerungsfokus -> Gibt an, welche Rolle gerade die Kontrolle über eine Aktivität besitzt/welche Rolle gerade aktiv ist

o Nachrichten werden als waagerechte Pfeile dargestellt (wird als Form eines Arguments auf den Pfeilen notiert)

56
Q

Sequenzdiagramme: Spezielle Nachrichten

A

Objekterzeugung: Ermöglicht einen Interaktionspartner erst im Laufe der Interaktion zu erzeugen
Verlorene Nachricht: Senden einer Nachricht an unbekannten oder nicht relevanten Interaktionspartner
Gefundene Nachricht: Empfang einer Nachricht von einem unbekannten oder nicht relevanten Interaktionspartner
Zeitkonsumierende Nachricht

57
Q

Interaktionsmodelle entwickeln

A
  1. Für jeden Anwendungsfall ein Sequenz- oder Kommunikationsdiagramm entwickeln, das den Standardablauf darstellt
  2. Stärken und Schwächen des gewählten Designs in diesen Situationen bedenken
  3. Für jeden Anwendungsfall 1-3 Diagramme, die die wichtigsten Ablaufvarianten bzw. Ausnahmen darstellen
  4. Gegenebenfalls fehlende Eigenschaften in den betroffenen Klassen identifizieren (z.B. notwendige neue Klassen, Assoziationen, Attribute und Operationen)
58
Q

Sequenzdiagramm erstellen: Checkliste

A
  1. Akteure und Systeme bestimmen -> Wer ist am Arbeitsprozess beteiligt?
  2. Initiator bestimmen -> Wer beginnt den Arbeitsprozess?
  3. Informationsaustausch zwischen Akteuren -> Welche Informationen werden ausgetauscht?
  4. Zeitlichen Ablauf der Interaktionen festlegen -> Wie ist die Reihenfolge der Interaktionen?
  5. Ergänzende Informationen eintragen -> Was ist noch wichtig?
  6. Modellverifikation -> Ist alles richtig?