- Grundlagen der Prozessmodellierung -

Präsentation zum Thema: "- Grundlagen der Prozessmodellierung -"—  Präsentation transkript:

1 - Grundlagen der Prozessmodellierung -
Seminar: Integration- & Service-Engineering - Grundlagen der Prozessmodellierung - Peter Palaga & Matthias Pätzold Wintersemester 2002/2003 Peter Palaga & Matthias Pätzold

2 Intuitive Modelldefinition Warum ist die Modellierung so wichtig?
Agenda Motivation Intuitive Modelldefinition Warum ist die Modellierung so wichtig? Abstammungen verschiedener Modelle Softwareentwicklung Übersicht Softwareentwicklungsprozess Entstandene Fragen in Bezug auf das IE/SE Sichten und Modelle Entity-Relationship-Modell Zustandsautomaten BWL Blueprinting GAP Neuere Entwicklungen als Vereinigung beider „Strömungen“ ARIS Microsoft Visio (Vortrag um 15:00) Matthias Pätzold Peter Palaga Inhaltsverzeichnis, geteilt nach Referent Peter Palaga & Matthias Pätzold

3 Motivation – Intuitive Modelldefinition
Was versteht man unter einem Modell? Intuitiv gesprochen: Erfassen eines Teilbereichs der Welt/„Realität“ Abstraktion von „weniger wichtigen“ Aspekten Repräsentation in einer Art Schema/Diagramm/Beschreibung vor allem werden graphische Modelle zum besseren Verständnis benutzt auch sind mathematisch fundierte Modelle interessant aufgrund ihrer Aussagekraft zu „semantischer Korrektheit“ und anderen Eigenschaften des erstellten Modells Peter Palaga & Matthias Pätzold

4 Motivation – Warum ist Modellierung wichtig?
Früher: HW- & SW-Technik war teuer & unflexibel  die Optimierungsmöglichkeiten wurden dementsprechend gesucht Jetzt: Hardware ist billiger & SW-Technik viel flexibler (WebServices...)  Steigende SW-Komplexität, Modelle zur Wahrung des Überblicks und korrekten Planung, Definition usw. erforderlich  Die Optimierungsmöglichkeiten liegen nun bei der organisatorischen Gestaltung der Unternehmensabläufe Was brauchen wir also für Modelle? Modelle für Daten, Kommunikation (UML, ER...) im Bereich der Softwareentwicklung Modelle zur Optimierung von Arbeitsabläufen/Geschäftsprozessen, Ressourcenplanung usw. Peter Palaga & Matthias Pätzold

5 Abstammungen verschiedener Modelle
Es haben sich mit der Zeit verschiedene, nebeneinander existierende Modelle für unterschiedliche Anwendungen entwickelt. Im wesentlichen stammen diese aber aus dem Software-Engineering und dem betriebswirtschaftlichen Bereich. Aus Sicht eines Informatikers könnte man meinen: „Die Phasen im Softwareentwicklungsprozess einschließ- lich der zugehörigen Modelle können mit geringen Modifi- kationen auf die Prozesse im Bereich des Integration- und Service-Engineerings übertragen werden.“ Ob dies wirklich der Fall ist, soll mit unserer Projektarbeit geklärt werden. These: These angeregt/mitformuliert durch Thomas Riechert Peter Palaga & Matthias Pätzold

6 Übersicht Softwareentwicklungsprozess
ü h r u g d Ü b e l c k V U t m s o 1 G a 2 O j I S W - w 6 D & P p 5 A 4 3 Q ä q – y K z ß M L v 2 CASE Legende: In der Vorlesung Softwaretechnik behandelten Themen = Ü b e r g a v o n T i l p d u k t I f m s c h U ü z E ß Übersicht über die Phasen der Softwareentwicklung Peter Palaga & Matthias Pätzold

7 Entstandene Fragen in Bezug auf IE/SE
Brauche ich eine solche Einteilung in Phasen beim IE/SE? Welche Phase ist wie stark im IE/SE ausgeprägt? In welcher Phase werden welche Modelle verwendet, um welche Aspekte zu modellieren und warum gerade diese? Welche Rolle spielen die folgenden Begriffe? EAI (Enterprise Application Integration) ERP (Enterprise Resource Planning)  Ja, denn eine strukturierte Vorgehensweise spart Zeit, Kosten und vermindert Fehlerhäufigkeit  Einige Phasen sind nicht so stark ausgeprägt wie im Software-Engineering, aber z.B. die Planungs- und Entwurfsphase ist extrem wichtig für spätere Phasen!  Ergebnis der Forschung im späteren Vortrag  Ergebnis der Forschung im späteren Vortrag Peter Palaga & Matthias Pätzold

8 Sichten und Modelle Daten Multidimensionale Datenmodellierung ER DD
Assoziationsmatrix Masken- generator SA Funktionen Funktions- baum Geschäfts- prozesse DFD System OOA Grafik-Editor Kontroll- strukturen Regeln Dynamik Petri-Netz Zustandsautomat Kontrollstrukturen Sequenzdiagramm RT-Erweiterung von SA Es gibt bei der Softwareentwicklung, genauso wie in anderen Bereichen verschiedene Sichten innerhalb eines Projektes Zunächst kann man eine Unterteilung in Datensicht, Funktionale Sicht, Dynamische Sicht und Benutzersicht bei einem Softwareprodukt sehen. Beim IE/SE kann dies ähnlich betrachtet werden, da die Funktionen, Daten usw. beispielsweise zweier IT‘s oder einer neuen Dienstleistung ebenfalls analysiert und modelliert werden müssen. Legende: ER = Entity Relationship RT = Realtime Analysis = Benutzungs- DD = Data Dictionary OOA = Object Oriented Analysis oberfläche DFD = Datenflussdiagramm SA = Structured Analysis Peter Palaga & Matthias Pätzold

9 Sichten und Modelle F u n k t i o s - b a m D c r y 1 9 7 K l e d g 8 / S 3 P A ( f p ) 6 E T h 5 R N z 2 H I en ä & B O j Z q w – 4 G v häufig verwendet selten verwendet Hier hat man noch mal einen besseren Überblick über die Modelle der einzelnen Schichten. Diese Auflistung erhebt aber keinen Anspruch auf Vollständigkeit, z.B. das Semantic Object Model?! (SOM) fehlt, da es relativ neu ist. Ich würde gerne Vorschläge über fehlende Modelle aufnehmen und diese dann ergänzen. Als Beispiel habe ich mir das ER-Modell und die Zustandsautomaten für eine kurze Erläuterung herausgenommen Peter Palaga & Matthias Pätzold

10 Entity-Relationship-Modell
Entity-Relationship-Modell (ER-Modell) 1976 von P. Chen zur Datenmodellierung entwickelt Ziel Beschreibung der permanent gespeicherten Daten und ihre Beziehungen untereinander. Die Analyse der Information erfolgt aus fachlogischer Sicht. Ergebnis Konzeptionelles Modell, das gegen Veränderungen der Funktionalität weitgehend stabil ist. Semantische Datenmodellierung Erweiterung um Aggregation und Vererbung Beispiel: Fallstudie »Seminarorganisation« (Chen-Notation) K u n d e b c h t V r a s l g w i - f ü v o D z N m U ö S y p A k B T M 1 Z Chen-Notation M: Multiple C: Choice Das ER-Modell sollte im allgemeinen bekannt sein. Was ich nur verdeutlichen möchte ist, dass das Modell auf einem relativ hohen Abstraktionsniveau gut geeignet ist, um die beim IE/SE zu vereinenden/neu zu kreierenden Daten gut modellieren lassen, ohne zu konkret auf die spätere Umsetzung z.B. in einer Datenbank einzugehen. Dafür ist dann z.B. das relationale Schema geeignet. Peter Palaga & Matthias Pätzold

11 Zustandsautomaten Viele Systeme und Geräte zeigen ein Verhalten, das von der bis dahin durchlaufenen Historie abhängt. Das aktuelle Verhalten wird durch den internen Zustand bestimmt, der durch vorausgegangene Eingaben oder Ereignisse erreicht worden ist. Zur Modellierung solcher Systeme eignen sich Zustandsautomaten (finite state machine), auch endliche Automaten (finite automation, sequential machine) genannt. Gegenüber einem allgemeinen Automaten besitzen endlich Automaten nur eine endliche Zahl von Zuständen. Bei deterministischen endlichen Automaten gibt es zu einer Eingabe von einem Zustand aus höchstens einen Zustandsübergang (transition) in einen anderen Zustand, während bei nichtdeterministischen endlichen Automaten mehrere Übergänge für dieselbe Eingabe möglich sind. Zustandsautomaten können als Zustandsdiagramm, Zustands- tabelle oder Zustandsmatrix dargestellt werden. Ziel beim Aufstellen eines Zustands- automaten ist es, mit möglichst wenig Zuständen auszukommen. vorbestellt zur Abholung bereit Buch defekt / entfernen() neues Buch liegt vor / erfassen() Ausleihwunsch / vorbestellen() Leser gibt Buch zurück / zurueckgeben() / ausleihen() präsent ausgeliehen Buch verloren after (Abholfrist vorbei) Leser holt Buch ab Der Zustandautomat eignet sich im Gegensatz zum ER-Modell nicht zu Datenmodellierung, sondern zur Darstellung einfacher (und gegebenenfalls auch komplexer) Vorgänge. Dieser ist zum Beispiel für die Beschreibung einer Ablauforganisation in einem Unternehmen (vor allem mit sich wiederholenden/zyklischen Tätigkeiten) durchaus denkbar. Peter Palaga & Matthias Pätzold

12 Warum ist die Modellierung so wichtig?
Fahrplan Motivation Modelldefinition Warum ist die Modellierung so wichtig? Abstammungen verschiedener Modelle Softwareentwicklung Entstandene Fragen Übersicht Softwareentwicklungsprozess Sichten und Modelle Entity-Relationship-Modell Zustandsautomaten  BWL-Modelle Blueprinting GAP Integration der Zwei Entwicklungslinien (BWL & SW-Engineering) ARIS Peter Palaga & Matthias Pätzold

13 Überzeugungen aufgrund der gelesenen Literatur:
BWL-Modelle Überzeugungen aufgrund der gelesenen Literatur: Modellierung im Bereich BWL existiert nicht lange (+-5 Jahren) Es gibt keine mit der UML vergleichbar standardisierte/bekannte/verbreitete Modellierungssprachen Blueprinting (wird ausgearbeitet) GAP (wird ausgearbeitet) Modelle oft entweder ganz intuitiv, oder ad hoc & wenig formalisiert Die BWL-Leute leihen sich die Ausdrucksmittel aus der SW-Engineering (ER-Modell, UML) aus Peter Palaga & Matthias Pätzold

14 Warum ist die Modellierung so wichtig?
Fahrplan Motivation Modelldefinition Warum ist die Modellierung so wichtig? Abstammungen verschiedener Modelle Softwareentwicklung Entstandene Fragen Übersicht Softwareentwicklungsprozess Sichten und Modelle Entity-Relationship-Modell Zustandsautomaten BWL-Modelle Blueprinting GAP  Integration der Zwei Entwicklungslinien (BWL & SW-Engineering) ARIS Peter Palaga & Matthias Pätzold

15 Architektur integrierter Informationssysteme
ARIS 1 ARIS Architektur integrierter Informationssysteme Nicht nur ein Stück Software Vielmehr ein Konzept/Framework zur Beschreibung von Geschäftsprozessen eines Unternehmens mit allen ihrer wesentlichen Merkmale Peter Palaga & Matthias Pätzold

16 ARIS 2 Ein Unternehmensprozess wird vollstädig durch
Vorgänge/Funktionen Ereignisse Organisationseinheiten Ressourcen Leistungen & ihre Daten Beschrieben Vollständige Beschreibung aller Zusammenhänge eines Prozesses würde das Modell sehr Komplizieren & zu Redundanzen führen. -> Sichten -> Ebenen Peter Palaga & Matthias Pätzold

17 Sichten in ARIS 1 Die Beziehungen der Komponenten innerhalb einer Sicht sehr hoch Zwischen den Sichten jedoch nur eine relativ lose Kopplung Peter Palaga & Matthias Pätzold

18 Die Zusammenhänge der Prozesselemente durch die Zerlegung verloren
Sichten in ARIS 2 Die Zerlegung ermöglicht es, die die Sichten weitgehend unabhängig voneinander und mit den spezialisierten Mitteln zu Beschreiben. Die Zusammenhänge der Prozesselemente durch die Zerlegung verloren -> die neue Steuerungssicht wird aufgenommen Die Ressourcensicht in ARIS wird durch ein Life-Cycle-Konzept der Beschreibungsebenen aufgelöst; Die Ressourcen werden auf den Beschreibungsebenen DV-Konzept und Implementierung der anderen Sichten behandelt Peter Palaga & Matthias Pätzold

19 Ebenen in ARIS Life-Cycle-Modelle beschreiben normalerweise den Lebenslauf eines Informationssystems. x Das Life-Cycle-Modell von ARIS definiert unterschiedliche Beschreibungsebenen, die sich in ihrer Nähe zur Informationstechnik unterscheiden. Peter Palaga & Matthias Pätzold

20 Ebenen in ARIS; BW Problemstellung
Ausgangspunkt: betriebswirtschaftliche Problemstellung. Die Beschreibung umfasst hier grobe Tatbestände, die sehr nahe an den fachlichen Zielsetzungen und der fachlichen Sprachwelt orientiert sind. Dabei werden auch die Möglichkeiten der Informationstechnik zur Unterstützung betriebswirtschaftlicher Prozesse und Entscheidungen mit einbezogen. Zur Darstellung werden nur halbformale Beschreibungsmethoden eingesetzt. Peter Palaga & Matthias Pätzold

21 wird auch als semantische Modellierung bezeichnet
Ebenen in ARIS Fachkonzept Stellt das zu unterstützende betriebswirtschaftliche Anwendungskonzept in einer mehr formalisierten Beschreibungssprache dar wird auch als semantische Modellierung bezeichnet DV-Konzept Anpassung der Fachbeschreibung an generelle Beschreibungskonstrukte der Informationstechnik Implementierung wird das DV-Konzept auf konkrete hardware- und softwaretechnische Komponenten übertragen. Hiermit wird die Verbindung zur Informationstechnik hergestellt. Peter Palaga & Matthias Pätzold

22 Sichten & Ebenen in ARIS
Mit der Sichtenbildung und den Beschreibungs-ebenen einschließlich betriebswirtschaftlichen Ausgangslösung ist das ARIS-Konzept entwickelt. Jede der Beschreibungs-sichten wird in den Fachkonzept, DV-Konzept und Implementierung beschrieben. Peter Palaga & Matthias Pätzold

23 Zusammenfassung ARIS stellt eine Integrierte Architektur dar; Bringt die Ansätze aus der BWL & Software-Engineering auf eine gemeinsame Plattform. Im Vergleich mit UML besitzt umfangreiche Möglichkeiten die aus der BWL-Sicht wichtige Teile der Geschäftsprozessen zu modellieren (Steuerung, Organisation, Resourcen,...) Peter Palaga & Matthias Pätzold

24 Quellen Becker, Kugeler, Rosemann: Prozessmanagement. 2. Auflage, Springer-Verlag, Berlin 2000 Hoeth, Ulrike; Schwarz, Wolfgang: Qualtiätstechniken für die DienstleistungHAnser, Berlin 2001 Hennig, Björn: Prozessorientiertes Qualitätsmanagement von Dienstleistungen; Deutscher Universitäts-Verlag, Wiesbaden 2001 Methodenhandbuch von ARIS 6.1 Der Zustandautomat eignet sich im Gegensatz zum ER-Modell nicht zu Datenmodellierung, sondern zur Darstellung einfacher (und gegebenenfalls auch komplexer) Vorgänge. Dieser ist zum Beispiel für die Beschreibung einer Ablauforganisation in einem Unternehmen (vor allem mit sich wiederholenden/zyklischen Tätigkeiten) durchaus denkbar. Peter Palaga & Matthias Pätzold