Anwendungsspezifische Informationssysteme Grundlagen der Prozessmodellierung 12.11.2003Peter Palaga & Matthias Pätzold1 Seminar: Integration- & Service-Engineering

12.11.2003Peter Palaga & Matthias Pätzold 1

Anwendungsspezifische Informationssysteme

Grundlagen der Prozessmodellierung

Seminar: Integration- & Service-Engineering- Grundlagen der Prozessmodellierung -

Peter Palaga & Matthias PätzoldWintersemester 2002/2003




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

o Entity-Relationship-Modello Zustandsautomaten

• BWL Blueprinting GAP

Neuere Entwicklungen als Vereinigung beider „Strömungen“• ARIS• Microsoft Visio (Vortrag um 15:00)

Matthias Pätzold

Peter Palaga




Motivation – Intuitive Modelldefinition

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

Was versteht man unter einem Modell?




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.




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

1. Software-Engineering und dem2. 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:




Übersicht Softwareentwicklungsprozess

Legende:

In der VorlesungSoftwaretechnikbehandelten Themen

= Übergabe von Teilprodukten

= Informationsaustausch

= Unterstützung

= Einfluß

Einführung und Überblick

V Unternehmensmodellierung

1 Grundlagen 2 ObjektorientierteUnternehmensmodellierung

I SW-Entwicklung

6 Die Wartungs- & Pflegephase

5 Die Abnahme- undEinführungsphase

4 Die Implementierungsphase

3 Die Entwurfsphase

2 Die Definitionsphase

1 Die Planungsphase

III SW-Qualitäts-management

6 Produktqualität– Systeme

5 Produktqualität– Komponenten

4 Prozeßqualität

3 ManuellePrüfmethoden

2 Qualitäts-sicherung

1 Grundlagen

II SW-Management

6 K ontrolle

5 Leitung

4 Personal

3 Organisation

2 Planung

1 Grundlagen

IV Querschnitte und Ausblicke4 Sanierung1 Prinzipien

& Methoden3 Wieder-

verwendung2 CASE




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

Ergebnis der Forschung im späteren Vortrag

Ergebnis der Forschung im späteren Vortrag

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!




Sichten und Modelle

System

Masken-generator SA

Assoziationsmatrix

RT-Erweiterung von SA

Funktionen

Funktions-baum

Geschäfts-prozesse

DFD

Dynamik

Petri-Netz Zustandsautomat Kontrollstrukturen Sequenzdiagramm

Grafik-Editor Kontroll-

strukturen Regeln

Daten Multidimensionale

Datenmodellierung ER DD

OOA

Legende:ER = Entity Relationship RT = Realtime Analysis

= Benutzungs- DD = Data Dictionary OOA = Object Oriented Analysis oberfläche DFD = Datenflussdiagramm SA = Structured Analysis




Sichten und Modelle

Funktions-baum

DataDictionary1979

Klassen-diagramm1980/1990

Strukto-gramm1973

PAP(Programm-ablaufplan)1966

Pseudo-code

ET(Entschei-dungsta-belle)1957

Regeln Petri-Netz1962

FunktionaleHierarchie

Informa-tions-fluss

Daten-Strukturen

Entitäts-typen &Beziehungen

Klassen-Strukturen

Kontroll-Strukturen

Regel-basierteSicht

EndlicherAutomat

Neben-läufigeStrukturen

Funktionale Sicht Datenorientierte Sicht Objekt-orientierteSicht

Algorith-mischeSicht

Zustandsorientierte Sicht

Sequenz-diagramm1987

Szenario-basierteSicht

Konzepte und Sichten

wenn–dann-Strukturen

Inter-aktions-Strukturen

Daten-flussdia-gramm1966

ER(Entity Re-lationship)1976

Zustands-automat1954

Geschäfts-prozess(1987)

Arbeits-ablauf

Aktivitäts-diagramm1997

Kollabora-tionsdia-gramm

häu

fig

verw

en

det

selte

n v

erw

en

det




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)

Kunde bucht Veranstaltung wird durch-geführt von Doz ent

Nummer

Dauer

vom

bis

Umsatz

gehört zu

Seminartyp

Kurztitel

Name

Adresse

Kontak t

Biografie

Titel

Name

Adresse

Kontakt

M M MM

M

1

Zielsetzung




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 alsZustandsdiagramm, Zustands-tabelle oder Zustandsmatrixdargestellt werden.

Ziel beim Aufstellen eines Zustands-automaten ist es, mit möglichstwenig Zuständen auszukommen.

vorbestellt

zur Abholungbereit

Buch defekt/ entfernen()

neues Buch liegt vor/ erfassen()

Ausleihwunsch/ vorbestellen()

Leser gibt Buch zurück/ zurueckgeben()

Ausleihwunsch/ ausleihen()

präsent

ausgeliehenBuch verloren/ entfernen()

after (Abholfrist vorbei)

Leserholt Buch ab/ ausleihen()

Leser gibt Buch zurück/ zurueckgeben()




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




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




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




ARIS 1

• Nicht nur ein Stück Software• Vielmehr ein Konzept/Framework zur Beschreibung von

Geschäftsprozessen eines Unternehmens mit allen ihrer wesentlichen Merkmale

ARISArchitektur integrierter Informationssysteme




ARIS 2

Ein Unternehmensprozess wird vollstädig durch

Vorgänge/FunktionenEreignisseOrganisationseinheitenRessourcenLeistungen& ihre Daten

Beschrieben

Vollständige Beschreibung aller Zusammenhänge eines Prozesses würde das Modell sehr Komplizieren & zu Redundanzen führen.

-> Sichten-> Ebenen




Sichten in ARIS 1

• Die Beziehungen der Komponenten innerhalb einer Sicht sehr hoch

• Zwischen den Sichten jedoch nur eine relativ lose Kopplung




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




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.




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.




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.




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.




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,...)




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

Documents

Anwendungsspezifische Informationssysteme Grundlagen der Prozessmodellierung 12.11.2003Peter Palaga & Matthias Pätzold1 Seminar: Integration- & Service-Engineering