Modellierung von IuK-Systemen

Transcription

JUSTUS-LIEBIG-UNIVERSITÄT GIESSEN
ALLG. BWL UND WIRTSCHAFTSINFORMATIK
UNIV.-PROF. DR. AXEL C. SCHWICKERT
Scriptum zur Vorlesung im Hauptstudium
Modellierung von
IuK-Systemen
Wintersemester 06/07
Univ.-Prof. Dr. Axel C. Schwickert
JLU Gießen – Vorlesung „Modellierung von IuK-Systemen“ – Hauptstudium – WS 06/07
Gliederung
1.
Struktur und Ziele der Vorlesung .................................................................................. 1
1 Gegenstand, Charakter und Ziele der Wirtschaftsinformatik ........................................ 3
2 Zur Bedeutung von Modellen und Modellierungsansätzen........................................... 5
3 Anvisierte Lernziele der Vorlesung ............................................................................... 7
2.
Grundlagen der Modellierung betrieblicher IKS........................................................... 8
1 Prozeß- und Systemgestaltung .................................................................................... 9
2 Systemtheoretische Grundlagen ................................................................................ 23
3 Graphen und Petri-Netze............................................................................................ 30
4 Prinzipien für die Entwicklung von betrieblichen IKS.................................................. 59
5 Objekte und Sichtweisen der Modellierung von betrieblichen IKS ............................. 62
3.
Funktionsorientierte Modellierung .............................................................................. 71
1 Funktions- und Verrichtungsorientierung.................................................................... 72
2 Funktionsorientierte Modelle....................................................................................... 74
3 Wandel zur Prozeßorientierung .................................................................................. 89
4.
Datenflußorientierte Modellierung ............................................................................... 94
1 Datenflußorientierte Modellierungsansätze ................................................................ 95
2 SADT – Structured Analysis and Design Technique .................................................. 96
3 SA – Structured Analysis (Tom DeMarco)................................................................ 105
5.
Datenorientierte Modellierung ................................................................................... 112
1 Datenorientierte Modellierungsansätze .................................................................... 113
2 Daten, Datenmanagement und Datenmodellierung ................................................. 114
3 Vorgehen bei der Datenmodellierung ....................................................................... 130
4 ERM – Entity Relationship Modeling ........................................................................ 136
6.
Objektorientierte Modellierung .................................................................................. 178
1 Zum Paradigma der Objektorientierung.................................................................... 179
2 Grundelemente der Objektorientierung .................................................................... 188
3 Die Unified Modeling Language (UML): Entstehung, Charakteristika, Elemente ..... 207
4 Aufbau einer Methode mit der Unified Modeling Language (UML)........................... 215
7.
Prozeßmodellierung mit ARIS .................................................................................... 243
1 Geschäftsprozeßorientierung und Workflow Management
2 Grundlagen der Prozeßmodellierung
3 ARIS Easy Learning: Beispiel “Organisation von Workshops”
4 ARIS Easy Learning: Sichten und Ebenen in ARIS
JLU Gießen – Vorlesung „Modellierung von IuK-Systemen“ – Hauptstudium – WS 06/07
Literatur
Falls ausgewählte Quellen in den einzelnen Abschnitten der Begleitunterlagen angegeben
sind, ergänzen und vertiefen diese Quellen die jeweiligen Stoffe. Die Lektüre dieser Quellen
wird empfohlen, ist aber fakultativ.
Die einschlägigen Kapitel der folgenden Quelle gelten als Pflichtlektüre für die Hörer der
Vorlesung:
Balzert, Helmut: Lehrbuch der Software-Technik – Band 1: Software-Entwicklung.
2. Aufl., Heidelberg, Berlin : Spektrum Akademischer Verlag 2000.
(ISBN 3827404800)
Gadatsch, Andreas: Management von Geschäftsprozessen.
2. Aufl., Braunschweig/Wiesbaden: Viehweg 2002. (ISBN 3528157593)
Modellierung von IuK-Systemen – WS 06/07 – Prof. Dr. Axel C. Schwickert
Vorlesung zur Wirtschaftsinformatik
Modellierung von
IuK-Systemen
Justus-Liebig-Universität Gießen
Prof. Dr. Axel C. Schwickert
Modellierung von IuK-Systemen – WS 06/07 – Prof. Dr. Schwickert
1
Modellierung von IuK-Systemen: Organisatorisches
X Vorlesung: Tiefenfachvorlesung Wirtschaftsinformatik, Hauptstudium
X Umfang:
2 SWS Vorlesung, Prof. Schwickert
X Prüfung:
90 Min. Klausur = 3 Creditpoints
Klausurstoff = Vorlesung
X Scriptum: Download im World-Wide-Web unter:
http://wi.uni-giessen.de/ dort im
„Download Center“ unter „Lehrveranstaltungen“ und „WS 06/07“ oder SPIC
X Dozent:
Univ.-Prof. Dr. Axel C. Schwickert
Professur für BWL und WI
Justus-Liebig-Universität Gießen
eMail: [email protected]
2
X VL-Termin:
Vorlesung
Donnerstags,
10.15 Uhr
bis 11.45 Uhr
X VL-Ort:
Vorlesung im
Hörsaal 1
(HS 1)
1. Donnerstag, 19. Oktober 2006
2. Donnerstag, 26. Oktober 2006
3. Donnerstag, 02. November 2006
8. Donnerstag, 07. Dezember 2006
Donnerstag, 28. Dezember 2006
Donnerstag, 04. Januar 2007
11. Donnerstag, 11. Januar 2007
14. Donnerstag, 01. Februar 2007
15. Donnerstag, 08. Februar 2007
Æ WBT 1+2
Æ WBT 3
Æ WBT 4
Æ WBT 5
statt Vorles.
statt Vorles.
statt Vorles.
statt Vorles.
Æ WBT 6
Æ WBT 7
statt Vorles.
statt Vorles.
3
X Klausur:
Spätestens 2 Wochen nach Ende der Vorlesungszeit
X Kontakt:
eMail: Axel. [email protected]
Oder Sprechzeit nach den Vorlesungen
Oder Sprechzeit nach Vereinbarung
X Infos:
http://wi.uni-giessen.de oder SPIC
Über die Web Site erhalten Sie aktuelle
Informationen und per Download alle
Skripten zu allen Lehrveranstaltungen.
Papieraushänge und gedruckte Skripten
nur in (angekündigten) Ausnahmefällen !
4
http://wi.uni-giessen.de
http://wi.uni-giessen.de
5
Abonnieren
Abonnieren!!
6
Infos
Infoszu
zuVorlesungen
Vorlesungen
und
undÜbungen
Übungen
7
Click
Click!!
•• Downloads
Downloads
•• Bookmarks
Bookmarks
•• Forum
Forum
•• Evaluation
Evaluation
8
Dipl.-Kfm.
Dipl.-Kfm.
Bernhard
Bernhard Ostheimer
Ostheimer
Dipl.-Kfm.
Dipl.-Kfm.
Michael
Michael Falk
Falk
Dipl.-Kfm.
Dipl.-Kfm.
Markus
Markus Brühl
Brühl
Dipl.-Vw.
Dipl.-Vw.
Sven
Sven Odermatt
Odermatt
Öffnungszeiten des Sekretariats (Licher Str. 70): Di. - Fr., je 9.00 bis 12.00 Uhr
9
Literatur zur Vorlesung
X Balzert, Helmut: Lehrbuch der Software-Technik – Band 1: Software-Entwicklung. 2. Aufl., Heidelberg, Berlin:
Spektrum Akademischer Verlag 2000.
X Gadatsch, Andreas: Management
von Geschäftsprozessen. 2. Aufl.,
Braunschweig/Wiesbaden:
Viehweg 2002.
10
Empfohlene Zeitschriften
X Das Wirtschaftsstudium – WISU
Allgemein sehr förderlich für Studierende
der Wirtschaftswissenschaften
X c´t: Technik!
X Wirtschaftsinformatik
Pflicht für Studierende
der Wirtschaftsinformatik
X IT-Zeitungen
Wöchentlich!
11
Vorlesung zum Wahlfach Wirtschaftsinformatik
Prof. Dr. Axel C. Schwickert
Hauptstudium Wirtschaftsinformatik
1
Gliederung
1 Struktur und Ziele der Vorlesung
2 Grundlagen der Modellierung von IKS
3 Funktionsorientierte Modellierung
4 Datenflußorientierte Modellierung
5 Datenorientierte Modellierung
6 Objektorientierte Modellierung
7 Prozeßmodellierung mit ARIS
Wahlfach Wirtschaftsinformatik - Wintersemester 06/07
2
1.1 Gegenstand, Charakter, Ziele der Wirtschaftsinformatik
Gegenstand der WI: IuK-Systeme in Wirtschaft und Verwaltung
l IKS sind sozio-technische Systeme
l Befriedigung der Informationsnachfrage zur Erfüllung von Aufgaben
in Wirtschaft und Verwaltung
l Koordination arbeitsteilig wirkender Aufgabenträger
Handhabung der Komplexität von IuK-Systemen
l Komponenten von IKS isolieren, untersuchen, integrieren
l Komponenten von IKS: Funktionen, Daten, Objekte, Schnittstellen
l Arten von IKS unterscheiden durch Fokussierung auf Unternehmen,
Arbeitsgruppen, Einzelpersonen, Branchen, betriebliche Funktionen,
unternehmensübergreifende Funktionen.
3
1.1 Gegenstand, Charakter, Ziele der Wirtschaftsinformatik
Wissenschaftstheoretischer Charakter der Wirtschaftsinformatik
l Realwissenschaft: Untersuchungsgegenstand sind Phänomene der Wirklichkeit
l Formalwissenschaft: Beschreibung, Erklärung, Prognose und Gestaltung
der IKS bedürfen der Entwicklung und Anwendung formaler
Beschreibungsverfahren und Theorien
l Ingenieurwissenschaft: Die Gestaltung von IKS verlangt nach einer
Konstruktionssystematik
Ziele und methodischer Ansatz der Wirtschaftsinformatik
l Erkenntnisziel der WI: Gewinnung von Theorien, Methoden und Werkzeugen
zur Beschreibung und Erklärung von IKS, zur Prognose des Systemverhaltens
und zur Gestaltung “besserer” Systeme
l Praxiskontakte zur Gewinnung und Validierung von Erkenntnissen über IKS
sind unverzichtbar (empirisch, induktiv, realistisch).
4
1.2 Zur Bedeutung von Modellen und Modellierungsansätzen
Komplexe Landschaft von IKS im Unternehmen
l Vielzahl von IKS für verschiedene Funktionalbereiche (z. B. Beschaffung,
Produktion, Absatz, Rechnungswesen) oder Verwendungszwecke (Planung,
Steuerung, Kontrolle, Leistungserbringung) im Unternehmen
l Integration der IKS in der Regel erforderlich
Verschiedene Sichten (Perspektiven) auf IKS
l
l
l
l
Entwickler: Modelle, Methoden, Werkzeuge, Programmierung
Organisatoren: Aufgaben, Abläufe, Aufgabenträger, Anforderungen
Management: Planung, Steuerung, Kontrolle von IKS-Entwicklung und -Nutzung
Benutzer: Aufgabenerfüllung, Anforderungen, Oberflächen, Verhalten, Bedienung
- System-Umwelt und ihre Beziehungsstruktur erkennen
Modelle: - Systeme, ihre Bestandteile und ihr Funktionieren verstehen
- Komplexität beherrschbar machen
5
1.2 Zur Bedeutung von Modellen und Modellierungsansätzen
Ergebnissicht: Was ist zu modellieren?
l Modell: Eine idealisierte, vereinfachte in gewisser Hinsicht ähnliche Darstellung
eines Gegenstands, Systems oder sonstigen Weltausschnitts mit dem Ziel,
daran bestimmte Eigenschaften des Vorbilds besser analysieren zu können
(Balzert, S. 100)
l Wie das Modell eines IKS erstellt wird und wie es aussieht, hängt vom
Entwicklungsparadigma, dem Verwendungszweck des Modells und häufig auch
vom Anwendungsbereich des zu modellierenden IKS ab.
Ergebnissicht: Anforderungen an das Modellieren
l Nutzen: Zweckgerichtet umfassende und genaue Abbildung des
Vorbilds erforderlich
l Verständlichkeit: Die Modelldarstellung muß der zweckgerichteten Verwendung
des Modells (z. B. System-Analyse, -Optimierung, -Modifikation) förderlich sein.
l Standardisierung: Die Festlegung auf ein Set von Modellierungskonventionen
fördert Vergleichbarkeit, Erlernbarkeit, Verständlichkeit.
6
1.3 Anvisierte Lernziele
Lernziele: Sie sollten wissen, .....
l ..... welche Ansätze und Prinzipien für die Modellierung von
betrieblichen IKS zur Verfügung stehen,
l ..... wie IKS funktionsorientiert modelliert werden,
l ..... wie IKS datenflußorientiert mit SA, SADT modelliert werden,
l ..... wie IKS datenorientiert per ERM modelliert werden,
l ..... wie IKS prozeßorientiert mit ARIS und EPKs modelliert werden,
l ..... wie IKS objektorientiert mit der UML modelliert werden.
7
Gliederung
8
2.1 Prozeß- und Systemgestaltung
Zwei Sichten der Planung von (Organisations-) Systemen
l Ergebnissicht: Das “Was” der Planung - die Systemgestaltung
l Prozeßsicht: Die Vorgehensweise der Planung - die Prozeßgestaltung
Prozeßsicht der IKS-Planung, -Entwicklung
l Vorgehensmodelle: Wie z. B. sequentielle Phasenmodelle, evolutionäre
Spiralmodelle, Prototyping-Modelle (RAD) etc.
l Methodische Durchgängigkeit: Die einzelnen Prozeßschritte werden durch
aufeinander abgestimmte Analyse- und Darstellungstechniken unterstützt (z. B.
durch ein Bündel von UML-Konzepten).
Ergebnissicht der IKS-Planung, -Entwicklung
l Modellierungsansätze: Wie z. B. funktions-, datenfluß-, daten-, prozeß- oder
objektorientierte Modellierung
l Prinzipien: Grundlagen der Systemtheorie, Abstraktion, hierarchische
Strukturierung, schrittweise Verfeinerung, Modularisierung
9
2.1 Prozeß- und Systemgestaltung
Prozeßsicht: Gliederung von Software-Entwicklungsprojekten
l Für die sachliche und zeitliche Gliederung von SWE-Projekten gibt es eine Fülle
von Vorschlägen, deren gemeinsamer Nenner ein allgemeines gestuftes
Vorgehen ist.
l Siehe dazu nachfolgend das “Allgemeine Vorgehensmodell” und seine
“Wasserfallstruktur”.
Prozeßsicht: Vorgehensmodelle zur Entwicklung von IKS
l
l
l
l
l
10
Es lassen sich folgende Grundformen unterscheiden:
Sequentielle Vorgehensmodelle
Parallel-sequentielle Vorgehensmodelle
Evolutionäre Vorgehensmodelle
Agile Vorgehensmodelle
2.1 Prozeß- und Systemgestaltung: Allgemeines Vorgehensmodell
Projektplanung
Projektrealisierung
Systemnutzung
Systemübergabe
Systemeinführung
Systembau
Detailprojekt
Hauptprojekt
Vorprojekt
Projektanstoß
Projektmanagement
Projektkontrolle
11
2.1 Prozeß- und Systemgestaltung: Allg. VG-Modell - Wasserfallstruktur
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
12
Vorprojekt
Hauptprojekt
Detailprojekt
Systembau,
Systemeinführung und -übergabe
Systemnutzung
Vorprojekt
Analyse
Istanalyse
- Erhebung des Istzustands
- Bewertung des Istzustands
Entwurf
Systementwurf
Programmspezifikation
Programmentwurf
Realisierung
Programmierung
Test
Einführung
Systemfreigabe
Systemeinführung
· eingeführtes System
Projektbegründung
· Schulung
· Unterhaltsorganisation aufstellen
· einführungsbereites System
Vorphase
Systemeinführung
Systembau
· System bauen
(Lösungen benutzungsreif machen)
· System testen, abnehmen
· Kosten und Wirtschaftlichkeit überprüfen
· Detailpläne
(Stahlknecht 2002)
· realisierungsreife Lösungen ausarbeiten
· detaillierte Wirtschaftlichkeitsrechnung
erstellen
· Unterhaltsorganisation planen
· Schulungs- und Einführungskonzept
erstellen
· Gesamtkonzept,
Masterplan
Phasen der
Systementwicklung
(allgemein)
Detailprojekt
· Zielsetzung überarbeiten
· Gesamtkonzept (evtl. mit Varianten)
erarbeiten
· Wirtschaftlichkeit überprüfen
· Planung aktualisieren
Hauptprojekt
· Problemstellung überprüfen
· Untersuchungsbereich abgrenzen
· Situationsanalyse / Standortbestimmung
vornehmen
· Gestaltungsmöglichkeiten abklären
· Ziele erarbeiten
· Lösungsprinzipien erarbeiten
· erste Wirtschaftlichkeitsund Nutzenüberlegungen anstellen
· Projektplanung erstellen
(weitere Vorgehen planen)
· Lösungsprinzipien
· Vorgehenskonzept
· Problem, Idee
· Projektwürdigkeit
· Projektauftrag
· Projektauftrag formulieren
· Projektorganisationsform wählen
· Projektpriorität bestimmen
Projektanstoß
Ergebnisse
14
Phasen und Aktivitäten
2.1 Prozeß- und Systemgestaltung: Allg. VG-Modell - Phasen
Phasenbezeichnung Phaseninhalt
Sollkonzept
- Fachentwurf
- IV-Grobentwurf
- Wirtschaftlichkeitsvergleiche
13
2.1 Prozeß- und Systemgestalt.: Allg. VG-Mod. - Phasen, Aktivitäten, Ergebnisse
2.1 Prozeß- und Systemgestalt.: Allg. VG-Mod. - Phasen, Aktivitäten, Ergebnisse
Projektbegründung
Vorphase
Istanalyse
Phase Analyse
Sollkonzept
Eigenentwicklung
Vorghehensmodell der
Systementwicklung
(allgemein)
Fremdbezug
Systementwurf
Phase Entwurf
Phase Realisierung
Programmentwurf
Auswahl und
Anschaffung von
Standardsoftware
Programmierung
und Test
Anpassung der
Standardsoftware
(Stahlknecht 2002)
Systemeinführung
Phase Einführung
15
2.1 Prozeß- und Systemgestaltung: Sequentielles VG-Modell “Wasserfallmodell”
Situationsstudie
Entwicklungsebenen
Situationsstudie
Validierung
Fachkonzeption
Systemkonzeption
Systementwicklung
Systeminstallation
Meilenstein
1
Fachkonzeption
Validierung
Meilenstein
2
Systemkonzeption
Validierung
Meilenstein
3
Systementwicklung
Validierung
Meilenstein
4
Systeminstallation
Validierung
Meilenstein
5
Zeit
16
2.1 Prozeß- und Systemgestaltung: Sequentielle Vorgehensmodelle
Sequentielle Vorgehensmodelle: Merkmale
l
l
l
l
l
Auch “Phasenkonzepte” genannt
Folgen dem Prinzip der “schrittweisen Verfeinerung”
Phasenergebnisse (”Meilensteine”) pro Phase zu definieren
Folgephase beginnt, wenn vorhergehende Phase vollständig abgeschlossen ist
Wasserfallmodell sieht (die in der SW-Entwicklung allfälligen) Rücksprünge vor
Sequentielle Vorgehensmodelle: Eignung
l
l
l
l
Anforderungen an zu entwickelndes IKS liegen präzise vor
Wenig komplexe IKS
IKS mit relativ stabilem Projektumfeld
IKS, die relativ wenig Arbeitsteilung erforden
17
SWE-Aktivität
Legende:
Prüfaktivität (QS)
SWE 6
Implementierung
SWE 5
Feinentwurf
SWE 4
Grobentwurf
KomponentenIntegration
Datenkatalog
SW-Entwurf
SW-Anforderungen
SW-Architektur
Schnittstellenentwurf
SWKE-Integrationsplan
SWE 7
SWIntegration
SWKEIntegration
SWE 3
SWAnforderungsanalyse
SWE 2
DVAnforderungsanalyse
und -Entwurf
DV-Anforderungen
DV-Architektur
DV-Integrationsplan
SWE 8
DVIntegration
SWE 1
SystemAnforderungsanalyse
und -Entwurf
18
Systemanforderungen
Systemarchitektur
Systemintegrationsplan
SWE 9
SystemIntegration
2.1 Prozeß- und Systemgestaltung: Parallel-sequent. VG-Modell “V-Modell”
2.1 Prozeß- und Systemgestaltung: Parallel-sequentielle Vorgehensmodelle
Parallel-sequentielle Vorgehensmodelle: Merkmale
l
l
l
l
Überlappte, zeitlich versetzte Arbeitsschritte phasenintern und phasenübergreifend
Keine Fixierung mehr auf umfassende, monolithische Phasenresultate
Statt dessen kleinere Leistungseinheiten (”Arbeitspakete”) zu definieren
V-Modell: Bündel aus Submodellen (PM, QM, Konfig.-Man., SW-Erstellung)
Parallel-sequentielle Vorgehensmodelle: Eignung
l
l
l
l
l
Für komplexere Projekte (V-Modell gültig im öffentlichen Sektor)
Realitätsnäher als rein sequentielle Vorgehensmodelle
Kleinere, einzeln abprüfbare Teilkomponenten
Änderungen im Projektumfeld können flexibler berücksichtigt werden
Nachteil: Vergleichsweise hoher Koordinationsaufwand
19
2.1 Prozeß- und Systemgestaltung: Evolutionäres VG-Modell - Grundstruktur
Zeit
R
E5
V
Systeminstallation
P
h
a
s
e
n
R
E3
V
Systemkonzeption
R
E2
V
Fachkonzeption
Situationsstudie
20
R
E4
V
Systemrealisierung
R
E1
V
Legende:
E = Entwickeln
R = Realisieren
V = Validieren
2.1 Prozeß- und Systemgestaltung: Evolutionäres VG-Modell “Sprialmodell”
Kumulierte
Kosten
schrittweises
Vorgehen
Ziele,
Alternativen,
Randbedingungen
festlegen
Alternativen und
Risiken bewerten,
Prototypen entwickeln
Risikoanalyse
Risikoanalyse
Risikoanalyse
Risikoanalyse
Prototyp
2
Prototyp 1
Vorgehenskonzept
Anforderungen
Prototyp
3
Prototyp
4
Entwurf
Realisierung
Validierung
der Anforderungen
Entwicklungsplan
Integration
Validierung des
und Testplan Entwurfs
Installation
Modul- Codierung
test
Integration und
Akzeptanz- Test
test
21
2.1 Prozeß- und Systemgestaltung: Evolutionäre Vorgehensmodelle
Evolutionäre Vorgehensmodelle: Merkmale
l Weitgehender Verzicht auf Sequentialisierung und vordefinierte
Zwischenergebnisse
l Zwischenresultate werden durch “systematisches Probieren” in zyklisch gestufter
Abfolge von Entwerfen, Realisieren und Validieren erzeugt.
l Grundlage “Prototyping”: explorativ, experimentell, evolutionär
l Spiralmodell (Böhm): inkrementell-iteratives Vorgehen
Evolutionäre Vorgehensmodelle: Eignung
l
l
l
l
22
Innovative, komplexe IKS
Im voraus schwierig zu strukturierende IKS
Rapid Application Development
Nachteil: Meilenstein-Zäsuren verschwimmen
2.1 Prozeß- und Systemgestaltung: Agile Vorgehensmodelle
22a
22b
Agile Vorgehensmodelle: Merkmale
l
l
l
l
l
Völliger Verzicht auf Sequentialisierung und vordefinierte Zwischenergebnisse
Geringe Regelungs- und Dokumentationsdichte
Grundlage “Prototyping”: explorativ, experimentell, evolutionär
Hohe Eigenverantwortung, gestaltbare Abläufe und Produkte
Beispiel: Extreme Programming
Agile Vorgehensmodelle: Eignung
l
l
l
l
l
Innovative IKS mit hoher Unsicherheit
Umwelt, System, Anforderungen offen
Kleine IuK-Systeme
Kleine Teams
Nachteil: Funktioniert nur mit “Helden”
22c
22d
2.2 Systemtheoretische Grundlagen
Gegenstand der allgemeinen Systemtheorie
l Anordnung von Elementen zu einem System und die Analyse der Beziehungen
zwischen den Elementen
l Begründer: Ludwig von Bertalanffy, 1951
Zum Begriff “System”
l Ein System wird durch eine abgegrenzte und geordnete Menge von Elementen
gebildet, die untereinander in Beziehung stehen.
l Das System bildet als Ganzes eine Einheit und läßt sich deutlich von seiner
Umwelt abgrenzen.
l System-Emergenz: Das Ganze ist mehr als die Summe seiner Teile.
Hauptaspekte der Analyse und Gestaltung von Systemen
l Wirkungsaspekte, Strukturaspekte
l Abstraktion, Dekomposition
23
Systemabgrenzung und Wirkungsanalyse
Umweltbeziehungen
Umweltelement
Systemgrenze
Umweltelement
System
als
Blackbox
Umweltelement
24
Strukturanalyse
Umweltelement
Umweltbeziehungen
Systemgrenze
System
Umweltelement
Umweltelement
25
Gesamtsystem
Abstraktion
und
schrittweise
Verfeinerung
Schnittstelle
Subsystem
l Hauptsachverhalte
l Vom Allgemeinen
Subsystem
.....
zum Speziellen
l Top-down,
Problemnahe
Ebene
Schnittstelle
Transformationsebene(n)
hierarchisch
Teilaufgabe
Teilaufgabe
Maschinennahe Ebene
26
Logische Komponente: suche, lies, schreibe ...
Ebene 1
Blockkonzept,
Modularisierung
Input
Output
Gesamtsystem
l Vollständige
Schachtelung
Ebene 2
Su
bs
ys
.3
Su
bs
ys
.2
Bausteine, Moduln
Su
bs
ys
.1
l Logische Komp. =
ul
od
Geordnete
Sammlung
von Moduln
M
M
od
ul
n
n
Ebene 3
27
Blockkonzept,
Modularisierung
Umsystem
l Mehrfach verwendbare Moduln mit
definierten Schnittstellen
Umsystem
Modul-Abgrenzung
Input
l Keine Nebeneffekte
1
2
bei Modul-Änderung/
-Austausch
Output
Modul
Black Box
1
2
Kontext und Schnittstellen
Input
Output
1
2
28
Modul
UnterModul
1
2
Interne Struktur und funktionale Einheit
A
Blockkonzept,
Modularisierung
Kein Spaghetti Junction Design !
Sequenz
Strukturblockarten
- - - - - - - - - - - - -
Ei
ng
Par 4
-
- - - - - - - - - - - - us
gan
A
l Standardisierte
Par 1
-
l Beschränkung der
an
g
B
Ablaufabbildungen
A
B
l Beherrschbare
Par 2
Dynamik
Selektion
A
Iteration
-
Par 5
- - - - - - - - - - - - -
Par 3
-
-
- - - - - - - - - - - - -
Par 6
- - - - - - - - - - - - -
-
- - - - - - - - - - - - -
29
2.3 Graphen und Petri-Netze
Graphentheorie
l Formale Theorie, die Vorgänge und Abfolgen untersucht
l Konzentriert sich auf Beziehungen zwischen Knoten und Kanten
Zum Begriff “Graph”
l Unter einem Graph versteht man eine Menge von Knoten, .....
l ..... die untereinander mit Kanten verbunden sind (siehe Begriff “System” !).
l Gerichtete Graphen zeigen auch die Art der Verbindung (Richtung der
Einflußnahme) zwischen den Knoten an.
Graph
30
Gerichteter Graph
g
Anwendungsbereiche der Graphentheorie
l Operations Research: Quantitative Methoden zur Planung und
Entscheidungsvorbereitung
l Ingenieur- und wirtschaftswissenschaftliche Bereiche
Eulersches Brückenproblem
l Euler 1736 in Königsberg: Gibt es einen Spazierweg über das Brückensystem
der Pregel, bei dem jede Brücke genau einmal passiert wird?
Ufer
Ufer
Insel
Ufer
31
TravellingSalesmanProblem
Kunde 4
Kunde 2
l Ein Vertriebsbeauftragter will eine
bestimmte Menge
von Kunden auf einer
Rundreise mit
minimaler Länge
abklappern.
Kunde 3
Kunde 5
Kunde 1
Kunde 6
Depot = Startort = Zielort
32
Zeit-/Wegminimierung
Touren-Problem
l Innerhalb eines best. Zeitraums ist eine best. Menge von Kunden mit einer best.
Menge Lieferwagen mit best. Produktmengen möglichst effizient zu beliefern.
Kunde 4
Kunde 3
Kunde 2
Tour 2
Tour 1
Kunde 5
Tour 3
Kunde 1
Kunde 6
33
Zeit-/Wegund Kostenminimierung
$
Depot = Startort = Zielort
Transport-Problem
l Von einer best. Menge an Depots aus ist eine best. Menge von Kunden (mit
einer best. Menge Lieferwagen) mit best. Produktmengen möglichst effizient zu
beliefern (keine Transport zwischen Kunden oder zwischen Depots).
Depot 1
34
Kunde 3
Depot 2
Kostenminimierung
Kunde 4
$$
SNI
Kunde 2
SNI
SNI
Kunde 1
Depot 3
Netzplantechnik (NPT)
l Große, komplexe Projekte planen, analysieren, steuern, kontrollieren, optimieren
l Ablaufstrukturplan mit zeitbeanspruchenden und zeitpunktbezogenen Elementen
muß vorher erstellt worden sein
l Zeitdauern und Vorgänger-/Nachfolgerbeziehungen sind bekannt.
S
T
A
R
T
A
2
4
5 5
30 30
F
6
45 45
C
H
S1
1
3
7
0 0
30 30
47 47
Z
I
E
L
5
30 37
35
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
Petri-Netze
l Begründer: C. A. Petri, 1962, Ges. für Mathematik und Datenverarbeitung (GMD)
l Petri-Netze sind gerichtete Graphen.
l Petri-Netze sind keine Instrumente, um Fische zu fangen. (Stahlknecht)
36
Petri-Netze: Anwendungsbereiche
l Anwendungsneutral: Mit Petri-Netzen lassen sich Systeme und Abläufe
modellieren, die auf diskreten Aktionen und Abhängigkeitsbeziehungen zwischen
diesen Aktionen basieren.
l Erlauben die Simulation der Modell-Dynamik mittels Verhaltensregeln.
l Bspw. Modellierung, Analyse umd Simulation im Bereich der
Automatisierungstechnik
l Wirtschaftswissenschaften: Modellierung von betrieblichen Abläufen als
hochaktuelles Anwendungsgebiet - Geschäftsprozeß-Modellierung
l U. a.: Geschäftsprozesse, Workflow-Management-Systeme, Customizing von
Standard-Anwendungssoftware
Petri-Netze: Elemente
l Statische Knoten-Elemente: Zustände (passiv) und Ereignisse (aktiv)
l Kanten: Kausal-logische Zusammenhänge zwischen Zuständen und Ereignissen
l Dynamische Elemente: Marken (für Zustände)
37
Passive Elemente: Zustände (Kreise)
l
l
l
l
Zustand (auch: Stelle, Platz, Bedingung)
Momentane Lage, Situation eines Systems bzw. Stand eines Prozesses
Bspw: Lagerbestand, in Bearbeitung, offene Rechnung, warm, bereit
Zustände werden als Kreise dargestellt.
Kausal-logische Zusammenhänge: Kanten (Pfeile)
l Gerichtete Kanten = Pfeile
Aktive Elemente: Ereignisse (Rechtecke)
l
l
l
l
38
Ereignis (auch: Transition, Zustandsübergang, Aktion)
Bewirken den Übergang von einem Zustand in einen anderen Zustand
Bspw.: Lagerbewegung, bearbeitet, Bezahlung, Erhitzung, fertigstellen
Ereignisse werden als Rechtecke dargestellt.
Ereignisse und Zustände
l Ein Ereignis beschreibt die Erzeugung, Veränderung, den Transport von z. B.
Daten oder Rohstoffen bei der Realisierung von Prozessen.
l Ein Ereignis setzt genau definierte und erfüllte Zustände voraus und/oder führt zu
einer genau definierten Menge von Zuständen.
l Die Beendigung eines Zustands erfolgt durch mind. ein Ereignis.
l Der Beginn eines neuen Zustands wird von mind. einem Ereignis angestoßen.
l Eingangszustand:
l Ausgangszustand:
l Zustände und Ereignisse wechseln sich immer ab: bipartider Graph
Richtig:
39
Falsch:
Ereignisse und Zustände
l Wege beginnen und enden
nicht mit einer Kante.
l Es gibt keine alleinstehenden
Knoten.
l Es gibt keine parallel
verlaufenden Kanten.
l Es gibt keine bidirektionalen
Kanten.
40
Falsch
Richtig
Eingangszustand
Zustand 1
41
Erteiltes
Angebot
Ausgangszustand
Zustandsübergang
Zustand 2
kann eintreten, wenn
Zustand 1 realisiert ist
wird durch den Eintritt des Zustandsübergangsrealisiert
Auftrag
Auftragsbearbeitung
Dynamische Elemente: Marken (in Zuständen)
l Durch das Setzen von Marken (Markierungen) in Zuständen wird die Dynamik
eines Systems oder Prozesses abgebildet.
l Jeder Zustand der realisiert ist, wird markiert.
l Markiert wird durch einen Punkt.
l Marken können exogen (empirische Beobachtung des Modellbenutzers) oder
endogen (aufgrund der modellbedingten Kausal-Logik) verursacht sein.
l Eine Zustandsübergang (Ereignis) kann “schalten” (durchgeführt werden), wenn
der Zustandsübergang aktiviert ist.
l Ein Zustandsübergang ist aktiviert, wenn alle Eingangszustände markiert und
alle Ausgangszustände markenfrei sind.
l Es besteht kein Schaltautomatismus. Schaltvorgänge verbrauchen keine Zeit.
l Erfolgt ein Zustandsübergang, werden von allen seinen Eingangszuständen die
Marken weggenommen und alle seine Ausgangszustände mit Marken belegt.
l Diese Vereinbarung zum Setzen von Marken (Schalten des Zustandsübergangs) heißt “Schaltregel” (Transitions-, Simulationsregel, Firing Rule).
42
Markierungssituationen in Petri-Netzen
l Wenn pro Zustand maximal 1 Marke zulässig ist, spricht man von einem
Bedingungs-/Ereignis-Netz (B/E-Netz).
l Lokalitätsprinzip: Zustände und Ereignisse werden immer nur durch ihre direkte,
lokale Umgebung beeinflußt (Kapselung, Modularisierung).
Unproblematische Situation: Aktivierung (Schaltbarkeit, Concession)
l Markierte Eingangszustände stehen unmarkierten Ausgangszuständen
gegenüber. Ereignis kann geschaltet werden.
43
Konflikt-Situation: Begegnung (Contact)
l Mindestens 1 Ausgangszustand (hier A) ist bereits markiert. Das Ereignis kann
mithin nicht schalten.
l Kann eintreten, wenn A zugleich Ausgangszustand eines anderen Ereignisses ist
oder wenn nicht vorhergesehene exogene Störungen auftreten.
A
44
?
Konflikt-Situation: Verzweigung (Branch Conflict)
l
l
l
l
l
l
Die Anordnung der Elemente ermöglicht verschiedene Zustandsübergänge.
Die Schaltregel gibt keinen Aufschluß darüber, welches Ereignis schalten soll.
Lösung 1: Modellbenutzer bestimmt das schaltende Ereignis exogen.
Oder Lösung 2: Entscheidungsregel zur abwechselnden Schaltung
Dabei: Zunächst schaltet Ereignis 1 und die Marke wandert von a nach b.
Bei erneuter Markierung von A schaltet dann Ereignis 2.
1
1
B
B
a
A
b
A
C
2
C
2
45
Konflikt-Situation: Wettbewerb (Meet Conflict)
l ”Markenüberangebot”: Die Ereignisse 1 und 2 können nicht gleichzeitig schalten,
da dann Ausgangszustand C vereinbarungswidrig mit zwei Marken belegt würde.
l
l
l
l
Dabei: Zunächst schaltet Ereignis 2 und die Marke wandert von a nach b.
Bei erneuter Markierung von A und B schaltet dann Ereignis 1.
1
1
A
A
a
C
B
2
46
b
C
B
2
Konflikt-Situation: Symmetrische Konfusion
l
l
l
l
Verflochtene Konfliktsituation: Verzweigung und Wettbewerb
Bspw.: Herstellung der Produkte C, D, E mit den Ressourcen A und B
1
a
C
A
1
A
C
2
b1
D
D
3
3
B
2
E
B
b2
E
c
47
Konflikt-Situation: Asymmetrische Konfusion
l Konflikt (zwischen 2 und 3) tritt erst ein, wenn ein Ereignis (hier 1) schaltet und
die Marke dann von A nach B wandert.
l Wenn dann 2 schaltet, wird die C-Marke eliminiert und 3 kann nicht geschaltet
werden.
l Wenn statt dessen 3 schaltet, sind nicht alle Eingangszustände für 2 aktiviert.
l Lösung 1: Exogener Eingriff
A
1
B
2
D
b. w.
C
3
48
E
Konflikt-Situation: Asymmetrische Konfusion
l Oder Lösung 2: Entscheidungsregel zur abwechselnden Schaltung
A
1
B
2
b
a
C
D
3
E
49
Verschiedene markenorientierte Petri-Netz-Typen
50
Markenkapazität
der Zustände = 1
Markenkapazität
der Zustände > 1
Nicht
unterscheidbare
Marken
Bedingungs-/
Ereignis-Netze
(B/E)
Stellen-/
Transitions-Netze
(S/T)
Unterscheidbare
Marken
Prädikats-/
Transitions-Netze
(Pr/T)
Prädikats-/
Transitions-Netze
(Pr/T)
Kurzbeschreibung: B/E-Netze
l
l
l
l
Zustand = Bedingung / Zustandsübergang = Ereignis
Jeder Zustand kann maximal 1 Marke haben: Knoten-Kapazität = 1
Marken sind nicht unterscheidbar.
Mit jeder Ereignis-Schaltung kann max. 1 Marke gesetzt werden:
Kanten-Kapazität = 1
l Marke vorhanden / nicht vorhanden: Bedingung wahr / falsch
l Voraussetzungen für Ereignis-Schaltung: Alle Eingangsbedingungen sind wahr
(markiert), alle Ausgangsbedingungen sind falsch (nicht markiert).
l Ereignisschaltung: Allen Eingangsbedingungen wird eine Marke entnommen,
allen Ausgangsbedingungen wird eine Marke zugefügt
Eingegangene
Bestellung
Mitarbeiter
verfügbar
Ausgelieferte
Ware
Bearbeitung
der Bestellung
Geschriebene
Rechnung
51
Kurzbeschreibung: S/T-Netze
l Zustand = Stelle / Zustandsübergang = Transition
l Jede Stelle kann mehr als 1 Marke haben: Stellen-Kapazität > 1
l Marken sind nicht unterscheidbar.
l Mit jeder Transitions-Schaltung können mehrere Marken transportiert werden:
Kanten-Kapazität > 1 (”Kanten-Gewichtung” gibt max. Markenmenge vor)
l Voraussetzungen für Transitions-Schaltung: Anzahl Marken in jeder
Eingangsstelle >= Kapazität der abgehenden Kante und freie Kapazität jeder
Ausgangsstelle >= Gewichtung der dort eingehenden Kante.
l Transitions-Schaltung: Allen Eingangsstellen wird diejenige Anzahl an Marken
entnommen, die der Gewichtung der abgehenden Kante entspricht.
l Transitions-Schaltung: Allen Ausgangsstellen wird diejenige Anzahl an Marken
zugewiesen, die der Gewichtung der eingehenden Kante entspricht.
52
Kurzbeschreibung: S/T-Netze (Beispiel)
K=10
K=50
Eingegangene
Bestellung
Mitarbeiter
verfügbar
K=10
1
1
2
1
Bearbeitung
der Bestellung
Ausgelieferte
Ware
Geschriebene
Rechnung
K=10
53
Kurzbeschreibung: Pr/T-Netze
l
l
l
l
l
l
l
l
l
l
54
Zustand = Prädikat / Zustandsübergang = Transition
Prädikate repräsentieren Relationen.
Marken nehmen Werte an und sind damit unterscheidbar.
Marken = Tupel oder Listen von Tupeln (aus Relationen)
Jedes Prädikat kann über mehr als 1 Marke (Relation) verfügen
Prädikats-Kapazität >= 1
Transitionen sind Operationen, die auf ein- bzw. ausgehende Relationen
(Marken) auszuführen sind.
Der Modelleur bestimmt, welche Prädikate welche Marken (Relationen)
aufnehmen können.
Voraussetzungen für Transitions-Schaltung: Jedes Eingangsprädikat hat
diejenigen Tupel, die die Kanten der Ausgangsprädikate fordern und jedes
Ausgangsprädikat enthält nicht die Tupel, die die eingehende Kante fordert.
Transitions-Schaltung: Den Eingangsprädikaten werden die durch die Kantenbeschriftungen festgelegten Tupel entnommen und die Ausgangsprädikate werden durch die Tupel ergänzt, die die jeweilige Kantenbeschriftungen fordert.
Die Marken (Relationen) aus den Eingangsprädikaten werden in die Marken der
Ausgangsprädikate umgesetzt.
Kurzbeschreibung: Pr/T-Netze (Beispiel)
Firma
Bestellnummer
Eing-Datum
Personalnummer
Bestellnummer
Muster GmbH
241299
19.12.2000
36 58 778
241299
K=10
K=50
Eingegangene
Bestellung
Mitarbeiter
verfügbar
K=10
Bearbeitung der
Bestellung
K=10
Ausgelieferte
Ware
Geschriebene
Rechnung
Mitarbeiter
Personalnummer
Personalnummer
Bestellnummer
Erstellungs-Datum
Hr. Friedrich
36 58 778
36 58 778
241299
22.12.2000
55
Vorteile Petri-Netze
l Klare Abbildung von Sequenzen, Nebenläufigkeiten und Verklemmungen in
l
l
l
l
l
l
Prozeßstrukturen
Semantik der Petri-Netze läßt sich einfach identifizieren
Verschiedene Abstraktionsebenen möglich (Vergröberung, Verfeinerung)
Sowohl Statik als auch Dynamik von Prozessen modellierbar, analysierbar
Relativ leichte Erlernbarkeit (besonders B/E-Netze)
Mathematische Verifizierbarkeit der Netze
Die Petri-Netz-Grundlagen (basieren auf den den Grundlagen der System- und
Graphentheorie) finden sich in der geschilderten oder in abgewandelter Form in
den Modellierungsansätzen für IKS wieder.
Nachteile Petri-Netze
l Fehlen allgemeiner Systematiken zum Vorgehen bei der Erstellung
von Petri-Netzen
l Modellierung subjektiv / keine Petri-Netz-orientierten Methoden
l Erhöhter Lernaufwand höherer Netz-Typen (Pr/T-Netze)
56
Anwendungsfelder Petri-Netze
Situationsstudie
Entwicklungsebenen
Situationsstudie
Validierung
Fachkonzeption
Systemkonzeption
Systementwicklung
Systeminstallation
Meilenstein
1
Fachkonzeption
Validierung
Meilenstein
2
Systemkonzeption
Validierung
Meilenstein
3
Systementwicklung
Validierung
Meilenstein
4
Systeminstallation
Validierung
Meilenstein
5
Zeit
57
Ausgewählte Quellen-Hinweise zu Petri-Netzen
l Balzert, Helmut: Lehrbuch der Software-Technik - Software-Entwicklung. 2. Aufl.,
Heidelberg, Berlin: Spektrum Akademischer Verlag 2000. Kapitel 2.17,
S. 346-374.
l Desel, Jörg; Oberweis, Andreas: Petri-Netz in der Angewandten Informatik. In:
Wirtschaftsinformatik, 4/1994, S. 359-366.
l Desel, Jörg; Erwin, Thomas: Simulation von Geschäftsprozessen mit PetriNetzen. In: WISU, 3/1999, S. 337-344.
l Rosenstengel, Bernd; Winand, Udo: Petri-Netze - Eine anwendungsorientierte
Einführung. 4. Aufl., Braunschweig: Viehweg 1991.
58
2.4 Prinzipien für die Entwicklung von betrieblichen IKS
Prinzip der hierarchischen Dekomposition
l Nach den systemtheoretischen Grundlagen der Abstraktion und schrittweisen
Verfeinerung (siehe Kap. 2.2)
Prinzip der Strukturierung und Modularisierung
l Nach den systemtheoretischen Grundlagen der Blockbildung und
Modularisierung (siehe Kap. 2.2)
Prinzip der konstruktiven Voraussicht
l Schon ab den ersten Schritten der Systementwicklung ist auf Qualitätssicherung,
Änderbarkeit, Wartbarkeit zu achten.
l Erstellungsprozeß durch praktikables Vorgehensmodell und methodische
Standardisierung strukturieren
l Integration aller Dokumentationsaktivitäten (in allen Phasen)
Prinzip der perspektivischen Betrachtung
l Abhängig vom Betrachter werden verschiedene Aspekte eines Systems
herausgehoben. Die Integration der Sichtweisen ist erforderlich.
59
l Benutzer, Entwickler, Techniker, Unternehmensführung, -organisation, Kunden ...
Prinzip der methodischen Standardisierung
l Für die Systementwicklung wird ein Bündel von Methoden, Konzepten, Techniken, Werkzeugen vom arbeitsteilig organisierten Entwicklungsteam eingesetzt.
l Alle Beteiligte sollten im Systementwicklungsprozeß gemäß einem best. Vorgehensmodell und mit Instrumenten arbeiten, die aufeinander abgestimmt sind und
damit die Koordination von Ablauf und Entwicklungsergebnissen fördern.
Projektstart
Situationsstudie
Projektende
Fachkonzeption
Systemkonzeption
Systemrealisierung
Systemanwendung
Zwischenergebnisse weiterentwickeln
Toolbox
Paradigma
60
Prinzipien
VG-Modell
Modellierungsansätze
Konzepte,
Notationen
CASEWerkzeuge
Nutzungsbereite Software
Gewartete Komponenten
Installation
Wartung
Systemanwendung
Montierte Programm-Moduln
Getestetes Programmsystem
Systemtest
4.
5.
Programmierte Moduln
Programmierung
Hardwarekonfiguration
Hardwaresystementwurf
Integration
Systemrealisierung
Programmstruktur
Datenstruktur
Programmsystementwurf
Datensystementwurf
Systemkonzeption
3.
Inkarnation: Konstruktive Sicht
Fachliches Detailkonzept
Anforderungsspezifizierung
Essenz: Fachliche Sicht
Fachliches Basiskonzept
Fachkonzeption
2.
Anforderungsermittlung
Projektvorschlag
Problemerkennung
Situationsstudie
1.
Zwischenprodukt
Tätigkeiten
Phase
l ”Design first, code later.”
grammierung strikt nach Plan.
l ”Inkarnation” danach: Technik und Pro-
halb gewonnen.
l ”Essenz” zuerst: Gut (fachlich) geplant ist
Prinzip der Trennung von
Essenz und Inkarnation
61
2.5 Objekt und Sichtweisen der Modellierung von betrieblichen IKS
Objekt der Modellierung von betrieblichen IKS
l Jedes IKS wird entwickelt, um bestimmte fachliche Aufgaben zu erfüllen.
l Analyse und Entwurf des Aufgabensystems sind die wichtigsten Schritte für die
Planung des IKS.
l Das Objekt der Modellierung ist demnach das durch das IKS betroffene
Aufgabengefüge im Unternehmen.
Sichtweisen der Modellierung von betrieblichen IKS
l Das Aufgabengefüge im Unternehmen läßt sich gemäß den Merkmalen von
Aufgaben unter folgenden relevanten Sichtweisen betrachten.
l Struktur von Aufgaben: Statische und dynamische Strukturaspekte
l Ressourcen von Aufgaben: Sachmittel und vor allem Daten
l Einbindung in die Organisationsstruktur: Einordnung in die Aufbau- und
Ablauforganisation des Unternehmens
62
Aufgabenmodellierung: Statische Funktionen
VERTRIEB
Angebotsbearbeitung
63
Auftragsbearbeitung
Auftragsverwaltung
Auslieferung
Auftragsabrechnung
Angebotskonfiguration
Auftragserfassung
Fälligkeitsüberwachung
Versandplanung
Fakturierung
Angebotskalkulation
Auftragsprüfung
Lieferfreigabe
Versandunterlagen
Provisionsabrechnung
Lieferterminermittlung
Auftragskalkulation
Auftragsänderungsdienst
Angebotsüberwachung
Auftragsbestätigung
Auftragsnachkalkulation
Aufgabenmodellierung: Dynamische Prozesse (Funktionen)
Eigenfertig.
prüfen
KDAuftrag
KD-Bezieh.
prüfen
VertreterAuftrag
Auftrag
konfig.
Auftrag
kalkulieren
Auftrag
Auftrag
terminieren bestätigen
Fremdbezug
prüfen
Auftrags
bestätigung
64
Aufgabenmodellierung: (Ereignisgesteuerte) Prozeßketten
Kunde
wird nicht
beliefert
Kundenauftrag
eingetr.
Kundenbeziehung
prüfen
abgelehnt.
Kundenauftrag
Auftragsablehnung
schreiben
XOR
EF-Teile
für KDA
Kunde
wird
beliefert
Auftrag
konfigurieren
V
FB-Teile
für KDA
65
Antrag auf
Hypothek
liegt vor
Aufgabenmodellierung:
(Ereignisgesteuerte)
Prozeßketten
Beantragung
einer
Hypothek
XOR
Bauunterlagen
prüfen
Sicherheiten
prüfen
XOR
XOR
Unterlagen
unvollständig
Unterlagen
vollständig
Sicherheiten
vorhanden
weitere
Unterlagen
beschaffen
(Stahlknecht 2002)
66
weitere
Unterlagen
liegen vor
Sicherheiten
nicht vorhanden
Hypothek
nicht bewilligen
Hypothek
bewilligen
Antrag
abgelehnt
Aufgabenmodellierung: Daten (semantisches Modell)
Name
Adresse
Bonität
Telefon
Telefax
Kunde
stellt
Bestelldatum
Lieferdatum
Bestellte Menge
Rabatt
Spezialpreis
Hersteller
Auftrag
Firmenname
Adresse
Telefon
Telefax
Entfernung
liefert
enthält
Artikel
67
Artikelbezeichnung
Lagerbestand
Mindestbestand
Einzelpreis
Verpackung
Aufgabenmodellierung: (Aufbau-) Organisationsstruktur
Geschäftsleitung
Marketing
Vertrieb
68
Einkauf
Produktion
Lager u.
Verkauf
Verwaltung
Aufgabenmodellierung: (Ablauf-) Organisationsstruktur
Abteilung Abteilung Abteilung Abteilung Abteilung
Vertrieb
Einkauf Produktion Lager/Vers. Verwaltung
Posteingang/-verteil.
X
Auftrag erfassen
X
Auftrag prüfen
X
Auftrag konfigurieren
X
X
Auftrag kalkulieren
X
X
Auftrag terminieren
X
Auftrag bestätigen
X
X
X
X
X
X
.
.
.
69
Resultierende Modellierungsansätze von betrieblichen IKS
l Aufgrund der vorgenannten Sichtweisen auf das Aufgabengefüge eines
Unternehmens sind zu modellieren:
- Funktionen
- Prozesse
- Daten
- Organisationsstrukturen
l Es existieren verschiedene Ansätze zur Modellierung von IKS, die jeweils auf
bestimmte Modellierungsobjekte fokussieren:
- Funktionsorientierte Modellierungsansätze (z. B. HIPO)
- Datenorientierte Modellierungsansätze (z. B. ERM)
- Datenflußorientierte Modellierungsansätze (z. B. SA und SADT)
l Weiterhin existieren Modellierungsansätze, die die verschiedenen
Modellierungsobjekte integrieren wie z. B.:
- Sichtweisen-integrierende Modellierung (z. B. mit ARIS)
- Objektorientierte Modellierung (z. B. mit der UML)
70
Gliederung
71
3. Funktionsorientierte Modellierung
Funktionsorientierte Aufbauorganisation des Unternehmens
l Die traditionellen betriebswirtschaftlichen Funktionalbereiche definieren die
statischen Aufbau-Organisationseinheiten des Unternehmens.
l Traditionell mit verrichtungsorientierter dynamischer Ablauforganisation
Geschäftsleitung
72
Beschaffung
Produktion
ReWe
Vertrieb
Stelle
Stelle
Stelle
Stelle
Stelle
Stelle
Stelle
Stelle
3. Funktionsorientierte Modellierung
Funktionsorientierte Ablauforganisation des Unternehmens
l Verrichtungsorientierte dynamische Ablauforganisation
l Beispiel “Ersatzteilbeschaffung”
l Anfrage Kunde an Vertriebsleiter - Sb. A erstellt Angebot - Vertriebsleiter
kontrolliert - Sb. A verschickt - Kunde bestellt bei Sb. C - Sb. D erfaßt Bestellung Vertriebsleiter kontrolliert - Auftragsbestätigung an Kunde durch Sb. A - ..........
73
3.1 Funktions- und Verrichtungsorientierung
Funktions-/
verichtungsorientierte
Ablauforganisation
Hier stehen wir.
l Hohe Arbeitsteilung,
l Viele Schnittstellen in der
Bearbeitungsfolge
l Lange Bearbeitungszeiten
l Hoher Koordinationsbedarf
l Hierarchiegrenzen sind
Ablaufgrenzen.
74
Kunde “droht mit Auftrag"
3.2 Funktionsorientierte Modelle
Funktionale betriebliche IuK-Anwendungssysteme
l
l
l
l
Häufig “Insel-Systeme” mit viele internen Schnittstellen
Kein durchgehender Informationsfluß; evtl. Medienbrüche
Geringe Flexibilität, hoher Koordinationsbedarf
Geringe Kundennähe, hohe Redundanzen
VERTRIEB
Funktion
..........
Angebotsbearbeitung
Auftragsbearbeitung
Auftragsverwaltung
AuftragsAngebotskonfiguration erfassung
Unterfunktion
Unterfunktion
Unterfunktion
Angebotskalkulation
Auftragsprüfung
Lieferfreigabe
..........
..........
..........
Elementarfunktion
Elementarfunktion
Elementarfunktion
75
Funktion
Unterfunktion
Funktionsstruktur
Unterfunktion
Beginn
EF 1
EF 2
EF 3
Unterfunktion
EF 4
Elementarfunktion
Elementarfunktion
76
Ende
Elementarfunktion
Struktogramm
x x ... x x
x x ... x x
x x ... x x
NF EF1 EF2 EF3 EF4
V
EF1
X
X
x x ... x x
x x ... x x
x x ... x x
EF2
Input
H
I
P
O
Process Output
Hierarchy
Input
EF 5
EF3
Process
X
X
EF4
Output
“I-P-O"-Beschreibung
Präzedenzmatrix
X
X
Bsp. Auftragsbearbeitung: Dekomposition der Funktionen
VERTRIEB
Angebotsbearbeitung
77
Auftragsbearbeitung
Auftragsverwaltung
Auslieferung
Auftragsabrechnung
Angebotskonfiguration
Auftragserfassung
Versandplanung
Fakturierung
Angebotskalkulation
Auftragsprüfung
Lieferfreigabe
Versandunterlagen
Lieferterminermittlung
Auftragskalkulation
Auftragsänderungsdienst
Angebotsüberwachung
Auftragsnachkalkulation
Bsp. Auftragsbearbeitung: Weitere Dekomposition der Funktionen
Ausgangsebene
78
Kundenauftragsführung
1. Dekomp.ebene
Auftragsverwaltung
Auftragsbearbeitung
Auslieferung
2. Dekomp.ebene
KD-Beziehung
prüfen
Auftrag
erfassen
Auftrag
bestätigen
Auftrag
z. Ausl. vorm.
3. Dekomp.ebene
Leitdaten
erfassen
Kopfdaten
erfassen
Pos.-Daten
erfassen
Auftrag
abschließen
Auftragsabrechnung
Vertr.-Nr.
KD-Nr.
Vertr.-Name
...
Vertr.-Anschrift
KD-NR.
Vertr.-Nr.
KD-Name
...KD-Anschrift
Kunde
Vertreter
Auftragskopf
KD-NR.
Vertr.-Nr.
Auftrags-Nr.
...Auftragsdatum
Auftragsposition
Rechnung
Sachbearbeiter
Auftr.-Nr.
Pos.-Nr.
Art.-Nr.
Menge.
..
Bsp. Vertrieb:
Informationsmodell
Konto
Produktlagerort
Produkt
79
KundenBeziehung
prüfen
3.2 Funktionsorientierte
Modelle
KundenBonität
prüfen
AuftragsLeitdaten
erfassen
AuftragsKopfdaten
erfassen
Bsp. Auftragsbearbeitung:
AuftragsPos.-Daten
erfassen
Dialogstruktur
Lagerbestand
prüfen
Auftrag
abschließen
Lagerbestand
reservieren
80
Auftrag
bestätigen
Auftrag
z. Auslief.
vormerken
Auftragsbearbeitung
Bsp. HIPO-Diagramm
Funktionendiagramm
Bestandsverwaltung
Fakturierung
Ebenendiagramm
Input
Output
Process
Kundenstammdaten
Rechnung
Fakturierung
Artikelstammdaten
Berichtswesen
Bestelldaten
Bestandsverwaltung
(Stahlknecht 2002)
Lagerbestandsdaten
Lagerbestandsdaten
81
Bsp. Auftragsbearbeitung: Auftragspositionsdaten erfassen
PROCESS
INPUT
Benutzer-Input:
- Artikel-Nr.
Gültigkeitsprüfung für Art.-Nr.
- Menge
Sperrfristprüfung für Art.-Nr.
- Preis (fakult.)
Lagerverfügbarkeit für bestellte
- Bemerkungen
Menge prüfen; ggf. Reservierung
(fakultativ)
- ..........
82
Verarbeitungsvorschrift:
OUTPUT
Benutzer-Output:
s. BS-MaskenEntwurf
für Kunden vornehmen
Mengeneinheit:
- default: ST
System-Output:
System-Input:
- zur Wahl: 12-Pack Palette
Daten an
Daten aus
Preis:
- Kunden-IS
- Produkt-IS
- Listenpreis
- Lager-IS
- Lager-IS
- Aktionspreis (fakultativ)
Steuerkonstrukte der Programmierung: PAP und Struktogramme (Stahlknecht 2002)
Verzweigung (Selektion, einfache Alternat.)
Sequenz (Reihung, Folge)
Strukturblock A
Strukturblock A
Strukturblock B
Strukturblock B
Strukturblock C
Strukturblock C
Wiederholung (Iteration, mit Bedingung)
Bedingung
erfüllt ?
Bedingung
erfüllt ?
J
J
Strukturblock A
Strukturblock B
Strukturblock A
Strukturblock B
Fallabfrage
Fallabfrage
N
J
Strukturblock A
Auswahl (Selektion, mehrfache Alternative)
Wiederholungsbedingung
Bedingung
erfüllt ?
N
N
Strukturblock A
Strukturblock A
Strukturblock B
Strukturblock C
Struktur- Struktur- Strukturblock A block B
block C
83
Vorstufe der
Programmierung:
Pseudocode
(Stahlknecht 2002)
84
BEGIN
Eröffne Datei Ausgangsrechnungen
R15 = 0, R20 = 0
Lies Datensatz Ausgangsrechnung
WHILE Datensätze vorhanden DO
IF
Rechnungsbetrag > € 3.000
THEN Rabatt = 0,20 x Rechnungsbetrag
R20 = R20 + Rabatt
ELSE Rabatt = 0,15 x Rechnungsbetrag
R15 = R15 + Rabatt
ENDIF
Lies Datensatz Ausgangsrechnung
ENDDO
RGES = R15 + R20
Drucke RGES , R15, R20
Schließe Datei Ausgangsrechnungen
END
Bsp. Auftragsbearbeitung: BS-Maskenentwurf zu
“Auftragspositionsdaten erfassen”
85
Stelle
Schadensregulierung
Poststelle
Aktion
Bsp. Schadenregulierung
bei einer Versicherung
Ablauforganisation Laufwegesteuerung
1
Sachbearbeiter
Meldung
prüfen
3
Zahlungsbetrag
ermitteln
Zahlungsbetrag
genehmigen
4
6
Buchhaltung
Schadensmeldung
annehmen
2
5
Leiter
Original
Mitteilung
erstellen
Kopie
Mitteilung
versenden
(Stahlknecht 2002)
7
86
Zahlungsbetrag
anweisen
KD
VL
BH
VS
FL
- Aufträge nachkalkulieren
- Faktura erstellen
Auftragsabrechnung
- Auslieferung rückmelden
- Versanddokumente schreiben
- Lieferschein schreiben
Auslieferung
- Auftragsänderungen
vornehmen
- Auslieferung freigeben
- Zuteilen
- Rückstände überwachen
- Fälligkeit überwachen
- Reservieren
erstellen
Aufträge verwalten
- Verfügbarkeit prüfen
- Bonität prüfen
Aufträge bearbeiten
Angebote bearbeiten
AB
Bearbeitungsschritte:
87
Abteilungen
Bsp. Kundenauftragsführung
Organisatorische Laufwegesteuerung
Funktionsorientierte Modellierung von IKS
l Hierarchische Zerlegung
l Teilungskriterien sind die Funktionen des IKS im Sinne der zu erfüllenden
betrieblichen Aufgaben.
l Funktionsbäume: Untergeordnete Ebenen präzisieren die Teilfunktionen der
übergeordneten Ebenen.
l Statischer Aspekt: Aufbaustruktur des IKS (statische Funktionsstruktur im Stil
von Organigrammen)
l Dynamischer Aspekt: Ablaufstruktur des IKS, Reihenfolge der Funktionen (z. B.
durch IPO-Tabellen, Präzedenzmatrizen, Struktogrammen, Flußdiagramme,
Programmablaufpläne)
l Daten sind Ressourcen zur Erfüllung der Funktionen
l Funktionsspezifische Datendefinitionen und Datenzuordnungen verursachen
Redundanzen und Inkonsistenzen.
l In einem dynamischen Markt-/Unternehmensumfeld sind Definitionen von
Datenstrukturen zeitstabiler als Funktionsstrukturen.
l Daher wird in Literatur und Praxis ein stärker datenorientierter
88
Modellierungsansatz als zweckmäßiger angesehen.
Einkauf
F&E
Marketing
ReWe
Produktion
Logistik
Annahme
Service
Reklamation
Kunden = Partner
Hier wollen wir hin.
3.3 Wandel zur Prozeßorientierung
89
Merkmale der Prozeßorientierung
l Die Organisationsstruktur orientiert sich nicht mehr an betrieblichen Funktionen
sondern an den Wertschöpfungsprozessen des Unternehmens.
l Prozesse leiten sich aus den Kernkompetenzen ab und sind auf genau definierte
marktbezogene Leistungen ausgerichtet.
l Die Prozeßleistung ist meßbar und kontrollierbar.
l Im Gegensatz zu funktionsorientierten Arbeitsabläufen sind Prozesse stellen-,
abteilungs-, funktionsbereichsübergreifend. Sie verlaufen quer zu funktionalen
Organisationsstrukturen.
l Jeder Prozeß bildet einen eigenständigen Verantwortungsbereich. Prozesse
definieren somit die Organisationseinheiten des Unternehmens.
l Die Prozeßarbeit wird von Teams getragen.
Eigenfertig.
prüfen
KDAuftrag
KD-Bezieh.
prüfen
VertreterAuftrag
90
Auftrag
konfig.
Auftrag
kalkulieren
Fremdbezug
prüfen
Auftrag
Auftrag
terminieren bestätigen
Geschäftsfeld
Beschaffung
Produktion
ReWe
Vertrieb
Input
Markt
Team
Auftrag
des
Kunden
Team
Team
Annahme
Team
Produkt
beim
Kunden
Rechnung
Liefern
Bearbeitung
Prozeß-Team
91
Wertschöpfungskette(n):
EBENE 1
PCKunden
Marketing + Vertrieb von PCs
Geschäftsprozesse:
EBENE 2
Angebot
an
Kunde
GP Nr. 1: "Kunden aquirieren und Angebote abgeben"
3.3 Wandel
zur Prozeßorientierung
GP Nr. 2: "Kundenauftrag ausführen"
Auftr.-Bearbeitung
A-Überwachung
Auslieferung
92
Vorgang 1
"Bestellte
Konfiguration
prüfen"
Ereignis 1
Reklamation
erfüllter
Kundenauftrag
EBENE 3
Vorgangsketten:
Kundenauftrag
eingegangen
Auftr.-Abrechnung
geprüfte
Konfiguration
Vorgang 2
"Liefertermine
prüfen"
Ereignis 2
geprüfte
Liefertermine
Ereignis 3
Unternehmensleitung
Funktionsbereich 1
ProzeßVerantwortlicher
l Der Verbund von
Prozessen .....
l ..... verlangt nach
einem Verbund
von integrierten/
integrierenden
betrieblichen IKS
Funktionsbereich 3
Funktionsbereich 2
Funktionsbereich 4
Team
Prozeßleistung
Prozeß 1
93
Prozeß 2
Kopplung
von Prozessen
Merkmale der
Prozeßorientierung
Prozeßleistung
Prozeßleistung
Prozeß 3
Gliederung
94
4. Datenflußorientierte Modellierung
4.1 Datenflußorientierte Modellierungsansätze
l Betrachtet man eine einzelne Funktion als Blackbox und verknüpft die Funktionen über Input-Output-Beziehungen, so erhält man einen Graphen, bei dem
die Knoten Funktionen entsprechen und die Pfeile Datenflüsse repräsentieren.
l Der funktions- bzw. prozeßorientierten Sicht sehr nahe
l Typische Beispiele datenflußorientierter Modelierungsansätze:
- SADT (Structured Analysis and Design Technique)
- SA (Structured Analysis)
Datenbestand
Datenbestand
VASchritt
VASchritt
Datenquelle
Datensenke
VASchritt
Datenbestand
95
VASchritt
nd
ta
es
nb
te
Da
4. Datenflußorientierte Modellierung: SADT
SADT - Structured Analysis and Design Technique
l
l
l
l
l
l
l
Mitte der 70er Jahre entwickelt (D. Ross, Firma Softech)
Prinzip der schrittweisen Verfeinerung
Objekte werden top-down in mindestens 3 und höchstens 6 Teilobjekte zerlegt.
Mindestens 3: verhindert triviale Zergliederungen
Höchstens 6: verhindert zu starke Zergliederung und Unübersichtlichkeit
Objekte: Funktionen oder Daten (”WAS”)
Steuerflüsse werden nicht modelliert (”WIE”)
SADT - Anwendungsbereiche
l Allgemeiner Ansatz, um Systeme jeglicher Art zu analysieren und zu entwerfen
l Das “WAS” eines Systems steht im Vordergrund, nicht das “WIE”.
l IKS-Entwicklung: Grobentwurf, Requirements Engineering
96
Anwendungsfelder SADT
Situationsstudie
Entwicklungsebenen
Situationsstudie
Fachkonzeption
Systemkonzeption
Systementwicklung
Systeminstallation
Meilenstein
1
Validierung
Fachkonzeption
Validierung
Meilenstein
2
Systemkonzeption
Validierung
Meilenstein
3
Systementwicklung
Validierung
Meilenstein
4
Systeminstallation
Validierung
Meilenstein
5
Zeit
97
SADT - Darstellungselemente
l Nur Kästchen und Pfeile für Funktionen, Tätigkeiten, Daten, Datenflüsse
l Immer duale Modelldarstellung: Aktivitäts- und Datenmodell
Aktivitätsmodell
(Aktigramm)
Initiierendes
Eingabeobjekt
Eingabeobjekt
Initiierende
Tätigkeit
Funktion
Tätigkeit
(Verb)
Ausgabeobjekt
Mechanismus
(Prozessor)
98
Datenmodell
(Datagramm)
Herkunft
(Tätigkeit)
Daten
Objekte
(Substantiv)
Verwendung
(Tätigkeit)
Mechanismus
(Speicher)
SADT - Beispiel “Bibliotheksverwaltung” (Aktigramm)
l Zunächst oberste Hierarchieebene: Gesamtsystem “Bibliothek verwalten”
l Start mit Aktigramm (funktionsorientiert)
S1: Haushaltsplan
S2: Bestandspolitik
E1: Eingänge von Buchhändlern
E2: Eingänge von Benutzern
A1: Ausgänge an Buchhändler
Bibliothek
verwalten
A2: Ausgänge an Benutzer
E3: Personal
A3: Personal
99
SADT - Beispiel “Bibliotheksverwaltung” (Aktigramm)
l Dann: “Bibliothek verwalten” zerlegen/verfeinern in seine Teilfunktionen
S1 (HH-Plan)
E1 (Buchhändler)
S2 (Best.-Pol.)
Kaufe
Bücher
Bestellungen
:A1 (Buchhändler)
Rücksendungen
Bücher
E2 (Benutzer)
Bediene
Benutzer
Ausgänge
:A2 (Benutzer)
Angestelltes
Personal
E3 (Personal)
100
Verwalte
Personal
Ausgeschiedenes
Personal
:A3 (Personal)
SADT - Beispiel “Bibliotheksverwaltung” (Datagramm)
l Dann: Daten modellieren mit Bezug auf die bekannten Funktionen
Stelle Finanzierung
sicher
Prüfe, ob zum Bestand passend
Prüfe, ob bestellt
Verlagsankündigungen
Bestellbelege
Bestelle
Bestellungen
Empfange
Versende
Sende zurück
Bücher
Inventarisiere
101
SADT - Beispiel “Schalterverkehr Bibliothek” (Aktigramm)
Benutzerdaten
Keine Ausleihe
Identifiziere
Benutzer
Benutzerdaten
Benutzerdaten
Benutzerdatei
Bücher
Buchdaten
Rückgabebestätigung
Bücher zurück geben
Reservierungsschein
Datei “Ausgeliehene Bücher”
Datei “Reservierungen”
Entleihschein
Bücher
Buchdaten
102
Bücher
ausleihen
Buchdatei
Keine Ausleihe
Vormerkschein
Kundenauftrag
Kundendaten
Artikeldaten
Auftragsbearbeitung
Auftragsdaten
Programm
Auftragsbearbeitung
Kundendaten
Artikeldaten
SADT - Beispiel
“Auftragsbearbeitung”
(Aktigramm)
Rechnung
Fakturierung
Rechnungssumme
Programm
Fakturierung
Kundenkonto
Fibu/
Debitoren
(Stahlknecht 2002)
Programme
Finanzbuchhaltung
103
SADT - Vorteile
l
l
l
l
Allgemeine System-Analyse und -Entwurfsmethode
Integriert Funktionen und Daten mit Fokus auf Datenflüsse
Konsequente schrittweise Verfeinerung, leicht erlernbar und leicht verständlich
Im Requirements Engineering für benutzerpartizipative Grobentwürfe geeignet
SADT - Nachteile
l Aufbauorganisatorische Darstellung und Datenmodell mit anderen Methoden zu
ergänzen.
l Kontroll-/Steuerflüsse werden nicht modelliert (”WIE”). Ablauforganisatorische
Beziehungen werden somit nicht erfaßt.
l Berücksichtigt nicht Lokalitäts-/Geheimnisprinzip: Daher nicht zur Blockbildung
und Modularisierung geeignet.
l Beschränkung auf 3 bis 6 Teil-Objekte pro Verfeinerungsschritt kann
sachlogischen Erfordernissen zuwiderlaufen.
104
4. Datenflußorientierte Modellierung: SA
SA - Structured Analysis (Tom DeMarco)
l Ende der 70er Jahre entwickelt von Tom DeMarco
l Grundidee: Es ist leichter, eine Problemlösung zunächst vom Datenfluß her
l
l
l
l
l
l
gesehen zu entwickeln, als sie top-down in Funktionen zu zerlegen.
Eine Entwurfsaufgabe wird zunächst mit Hilfe von Datenflüssen in Teilaufgaben
(Prozesse) zerlegt.
Prozesse transformieren eingehende Datenflüsse in ausgehende Datenflüsse.
Die identifizierten Prozesse werden dann schrittweise verfeinert.
Alle Datenflüsse eines hierarchisch nachgeordneten Datenflußgraphen müssen
im übergeordneten Datenflußgraphen vorhanden sein.
Somit werden lediglich Prozesse dekomponiert, nicht jedoch die Datenflüsse.
Ein Data Dictionary enthält Beschreibungen aller nicht mehr weiter zerlegbaren
Prozesse sowie der Datenflüsse.
Kontroll-/Steuerflüsse werden nicht modelliert.
SA - Anwendungsbereiche
l Das “WAS” eines Systems steht im Vordergrund, nicht das “WIE”.
l IKS-Entwicklung: Grobentwurf, Requirements Engineering
105
Anwendungsfelder SA
Situationsstudie
Entwicklungsebenen
Situationsstudie
Validierung
Fachkonzeption
Systemkonzeption
Systementwicklung
Systeminstallation
Meilenstein
1
Fachkonzeption
Validierung
Meilenstein
2
Systemkonzeption
Validierung
Meilenstein
3
Systementwicklung
Validierung
Meilenstein
4
Systeminstallation
Validierung
106
Meilenstein
5
Zeit
SADT - Darstellungselemente
l Zusätzlich zu den aus Symbolen bestehenden Graphen wird das Data Dictionary
(Datenlexikon mit sog. Minispecs) mitgeführt.
Symbol
Bedeutung
Beispiele
Datenfluß,
Materialfluß
Benutzerdaten
Ausleihe
Prozeß
Speicher,
Materiallager
Magazin
Datenquelle,
Datensenke
Benutzer
107
SA - Beispiel “Schalterverkehr (SV) Bibliothek”
l Zunächst oberste Hierarchieebene: Gesamtsystem “Schalterverkehr”
l Alle relevanten Datenflüsse sind enthalten.
l 1. SV: 1.1 Benutzeridentifikation, 1.2 Überprüfung Benutzersperre, 1.3 Ausleihe
Benutzerdaten
Buchnummer
Buchdaten
1.
SV
Benutzer
Buchbestand
Buch
Leihkennzeichen
Entleihschein
Buch
Entleihschein
Magazin
108
SA - Beispiel “Schalterverkehr (SV) Bibliothek”
Benutzerdaten
1.1
BI
Rückweisung
Zwischenspeicher Benutzerdaten
Ausgeliehene Bücher
Unbek.
Benutzer
Benutzerdaten
Buchnr.
Entliehenes
Buch
Buchnr.
Benutzerdatei
Rückweisung
Rü
ck
w
ei
En
n
date
h
c
Bu
in
Benutzerdaten
he g
c
s
n
ih
su
e
tl
1.2
ÜBS
1.3
AL
c
Bu
Buchbestand
Leihkennz.
h
Buch,
Entleihschein
Entleihschein
Magazin
109
SA - Beispiel
“Auftragsbearbeitung”
(Stahlknecht 2002)
Kundendatei
Kundendaten
Kunde
Bestellung
Bestandsdaten
Bestellung
bearbeiten
Entnahmedaten
Lagerbestandsdatei
110
Lieferdaten
Rechnung Rechnung
schreiben
Rechnungssummen
Debitorendatei
Kunde
SA - Vorteile
l
l
l
l
Analyse und -Entwurfsmethode für Software-Systeme (Prozesse + Daten)
Integriert Funktionen (Prozesse) und Daten mit Fokus auf Datenflüsse
Schrittweise Prozeß-Verfeinerung, leicht erlernbar und leicht verständlich
Im Requirements Engineering für benutzerpartizipative Grobentwürfe geeignet
SA - Nachteile
l Aufbauorganisatorische Darstellung und Datenmodell mit anderen Methoden zu
ergänzen.
l Kontroll-/Steuerflüsse werden nicht modelliert (”WIE”). Ablauforganisatorische
Beziehungen werden somit nicht erfaßt (Teil-Prozesse stellen keine Sequenz dar,
obwohl durchlaufend numeriert).
l Datenflüsse, -quellen und -senken werden nicht dekomponiert. Alle diese
Elemente müssen auf allen Verfeinerungsebenen mitgeführt werden.
l Darstellungen werden sehr schnell unübersichtlich.
111
Gliederung
112
5.1 Datenorientierte Modellierungsansätze
Datenorientierte Modellierungsansätze
l Datenorientierte Modellierungsansätze für IKS konzentrieren sich auf die
betriebliche Datenstruktur, Datenrepräsentationsformen und die
Datenmanipulation.
l Datenstruktur bspw. für ein IKS: Kunden, Artikel, Lager, Vertriebsbeauftragte,
Aufträge, Lieferanten etc.
l Datenstruktur bspw. für ein IKS: Merkmale (Attribute) von Artikeln wie z. B. Preis,
Bezeichung, Menge etc. und Beziehungen z. B. zu Auftrag, Lieferant etc.
l Datenstrukturen sind i. d. R. zeitstabiler als Funktionen und eignen sich daher oft
besser für eine längerfristig gültige Modellbasis eines IKS.
l Typisches Beispiel für datenorientierte Modellierungsansätze:
- ERM (Entity Relationship Modeling)
113
5.2 Daten, Datenmanagement und Datenmodellierung
! Information = Datum +
Zweckbezug
SAP-Dividenden-Info
SAP: 471,00; 21.09.97
SAP: 484,00; 21.10.97
Konjunktur-Informat.
Dollarkursentwicklung
Wissen
484,00 Kurs SAP-Aktie
am 21. Oktober 1997
Information
Regeln,
Vernetzung
! Wissen = Information
+ Verstehen
! Information vermindert
Unsicherheit
484,00
0123456789
Zweckbezug,
Bedeutungsinhalt
! Unsicherheit
Daten
Syntax ###,##
! Information =
zweckorientiertes
Wissen / Daten
Zeichen
Zeichenvorrat
! Information = Kenntnis
von Sachverhalten
(DIN 44 300)
! Information = Wissen,
Denken, Nachricht
114
Isoliert betrachtet sind Daten zweckneutral und bedeutungslos.
Daten
abstrakte, strukturierte
Darstellung der Realität,
zweckneutral
Entscheidung
Auswahl aus einer
Menge von Alternativen
Beziehungszusammenhang,
Verarbeitung
Abstraktion,
Abbildung
115
g
un
rt
we
r
Ve
Umsetzung
Information
Handlung
Wissen über die
Realität, zweckgerichtet
Durchführung zielgerichteter
Aktionen
Erzeugung
Informations-Darstellung
strukturiert
unstrukturiert
dynamisch
statisch
sichtbar
Daten
Texte
hörbar
Bilder
bewegte
Bilder
kombinierte Dokumente
akust.
Signale
Video
Multimedia-Anwendungen
116
Datenspeicherung: Analog, EDV-extern
l Kopf, Zettel, Papier, Notizen .....
l Karteikarten, Ordner, Bücher .....
Datenspeicherung: Digital, EDV-intern
l Unstrukturiert in Files: Doc, ASCII, HTML .....
l Strukturiert in Files: Index-/sequentielle Files
mit festen/variablen Feldlängen
l Strukturiert in Datenbanken: MS-Access,
SQL-Server, Oracle, Informix, DB2 .....
117
Unstrukturierte Datenspeicherung
l Beispiel Word-Dokument mit Adressen
l Bedarf keiner weiteren Erläuterung .....
Martin Wild, Berlenbacher Weg 3,
06231-21029
Guba, Andreas, Mainz-530201, Geb.Dat.23.2.74
Schwickert, Axel, Handy 0171-5873937
Udo, 2.3.75, 931210
Private Adressen:
Tom Franke, Königstein, 200 DM offene
Rechnung!!!
118
Strukturierte Datenspeicherung in Files
l Bspw. in COBOL-, Pascal-Files mit festen oder variablen Feldlängen
l Jede Applikation speichert “ihre” Daten in “ihren” Files.
l Zugriff auf Daten i. d. R. nur mit bestimmten Applikationen
Franke;Thomas;23.04.1953; Welderweg 4;55124;Mainz;06131;22018
Müller;Olf;4.12.1969;Kweg 4;45129;Ollern;0531;34962
Ging;Uoh;1.2.2000;Frankfurter Str. 4;21201;Hamburg;0531;34962
[...]
FrankeThomas23.04.1953Welderweg 4
55124Mainz 0613122018
MüllerOlf
04.12.1969Kweg 4
45129Ollern 0531 34962
Ging Uoh
01.02.2000Frankfurter Str. 4 21201Hamburg0531 34962
[...]
119
Strukturierte Datenspeicherung in Files
Programm 1
ProzedurTeil
Programm 2
Datenbeschreibung
Datenbeschreibung
Datenzugriff
Datenzugriff
ProzedurTeil
Datei 1
Datei 2
120
Etwas übertrieben, aber deutlich .....
l Vetter, M.: Das Jahrhundertproblem der Informatik, in: Müller-Ettrich (Hrsg.):
Effektives Datenbankdesign, Köln 1989, S. 11-31.
“Das Jahrhundertproblem der Informatik besteht
in der Bewältigung des Datenchaos, das infolge
historisch, mitunter auch hysterisch und archaisch,
sicher aber unkontrolliert gewachsener Datenbestände
fast überall entstanden ist.”
121
Strukturierte Datenspeicherung in Datenbanken
l Trennung der Daten von den Applikationen
l DBMS (Datenbankmanagement-System) zwischen Applikationen und Daten
l Datenbanken sind ein Hilfsmittel zur effizienten, rechnergestützten Organisation,
Manipulation und Verwaltung großer Datenbestände.
l Datenbanken bieten (u. a.) den anwendungsneutralen Zugriff auf Daten, DatenIntegration und -Konsistenz, Zugriffsregelungen und Multi-User-Zugriffe in
Netzwerken: alles Problembereiche der Daten-Speicherung in Files.
122
Programm 1
Strukturierte
Datenspeicherung in
Datenbanken
123
Datenbank-System
ProzedurTeil
Programm 2
ProzedurTeil
Datenbank-Management-System (DBMS)
Tabelle 1
Tabelle 2
Tabelle 3 .....
Anforderungen an betriebliche IKS:
Architektur
Gestern/heute
Spartenlösungen
Isolierte AW-Inseln
Geschlossene, teilweise
inkompatible Systeme
Begrenzte Integrierbarkeit
neuer Techniken
Heute/morgen
Integrierte Gesamtlösungen
Bereichsübergreifende AWS
Sicht des Gesamtunternehmens
Integration neuer Technologien
–Bürokommunikation
–Teamunterstützung
–Wissensbas. Systeme
124
Informationsaktualität
125
Gestern/heute
Heute/morgen
Begrenzte Auswertbarkeit
der Datenbestände
Periodische Auswertungen
Hohe Anteil Stapelverarbeitung
Daten-/Dateienredundanz
Unterschiedl. update-Zyklen
Max. Unterstützung der Bereichsund Unternehmensziele
Online-Verfügbarkeit aller
wesentlichen Informationen
Umfassende, abschließende
Sofortverarbeitung
Konsistente Datenbestände
Einsatz der indiv. DV
Entwicklung und Wartung
Gestern/heute
Heute/morgen
Hohe Redundanz bei
Daten und Funktionen
Unterschiedliche Standards
Abhängigkeit von Spezialisten,
mangelhafte Dokumentation
Erhebl. Wartungsaufwand
Hoher Anwendungsrückstau
Unternehmensweites
Datenmodell
Unternehmensweite
Standards
Toolunterstützung
Wiederverwendbarkeit
Schnelle Reaktionsfähigkeit
126
“DV-Abteilung” und Datenmanagement
l Aus Daten müssen Informationen werden.
l Informationen sind als wirtschaftliches Gut zu interpretieren.
l Aufgabe der “DV-Abteilung: Nicht “Datenverarbeitung”, sondern
Informationsversorgung
Aufgaben und Ziele des Datenmanagements
l Alle im Unternehmen verwendeten Daten planen, überwachen, steuern
l Dies unabhängig von den zur Datenspeicherung eingesetzten Sachmitteln
l Ziele: Richtigkeit, Vollständigkeit, Aktualität, Konsistenz, Aufgabenadäquanz
der Daten / Problem: “Unternehmensweites Datenmodell” (UDM)
Konkrete Aktivitätsbereiche des Datenmanagements
127
l Entwicklung und Implementierung von Datenmodellen
l Organisation der Datenbeschaffung und Datennutzung
l Wartung und Pflege der Datenbestände
Datenmanagement setzt Datenmodellierung voraus
l Informationen
werden zunehmend
wettbewerbsrelevant.
Objekt
Kunde
Angebot
Organisation
l Datensicht stabiler
als Funktionssicht.
l Gefordert: Integrierte
Sichtweise auf alle
Unternehmensdaten.
Police
Vertrag
l Die Organisation (auf
der Basis einer
Modellierung)
bestimmt wesentlich
die Leistung der
betrieblichen IKS.
Be
En
titä
t
zie
Schaden
hu
ng
128
Integrationswirkungen der Daten- und Prozeß-Modellierung
l Konstitierende Voraussetzung für jede Landschaft von IKS ist die
Modellierung der Informations-/Datenobjekte
eines Unternehmens.
Auftragsbearbeitung
Vertreter
l Die parallele Prozeßmodellierung gibt die Hinweise für die Zusammenfassung von
Integrationseinheiten.
Kundenstammdatenverwaltung
Kunde
Auftrag
Rechnung
Produkt
l Die Modelleure benötigen den Überblick über
die Kernziele und
-Aktivitäten eines
Unternehmens.
129
Konto
DebitorenBuchhaltung
Lagerbestandsführung
Lager
5.3 Vorgehen bei der Datenmodellierung
Datenmodellierung: Begriff
l Formale Beschreibung von Daten und deren Zusammenhänge
l ”Business Rules” implizit im Modell enthalten
Datenmodellierung: Ziele
l Systematische, strukturierte Erfassung und Dokumentation von Informationen
l Verwaltung und Nutzung von Daten/Informationen mit einem Datenbanksystem
l Datenmodellierung ist zwingende Voraussetzung für den Entwurf und die
Implementierung von Datenbanksystemen.
Exkurs: Datenbanksysteme
l Die Konstruktionsmerkmale eines (relationalen) Datenbanksystems beeinflussen
die Modellierung der Daten, die in diesem Datenbanksystem verwaltet werden.
l 3 Schichten (Schemata) in einem (relationalen) Datenbanksystem:
130
- Konzeptionelles (konzeptuelles) Schema
- Externes Schema (Views, Sichten)
- Internes (physisches) Schema
131
Externes
Schema:
ProzeßView 3
Konzeptionelles
Schema:
Gesamtes
Daten-Modell
(ERM)
Externes
Schema:
Anwend.View 2
Tab. 7
Tab. 5 Tab. 6
Tab. 3 Tab. 4
Tab. 1 Tab. 2
DBMS
Modellierung
Daten-Basis
Informationsmodell
Internes
Schema:
Phys.
DatenOrganis.
Physische
Abbildung
Externes
Schema:
BenutzerView 1
Realwelt
5.3 Vorgehen bei der Datenmodellierung: Exkurs Datenbanksystem
Konzeptionelles Schema
l Stellt die Beschreibung des gesamten Realitätsausschnittes (dar (Unternehmen),
der im Datenbanksystem abgebildet werden soll.
l Durch Beobachtung der Realität wird ein Informationsmodell erzeugt, aus dem
das konzeptionelle Modell (ERM) abgeleitet wird.
Internes Schema
l Stellt die physische Organisation der Datenelemente dar (bis hin zur physischen
Anordnung der Daten auf Speichermedien).
l Wird aus dem konzeptionellen Datenmodell abgeleitet/erzeugt
Externe Schemata
l Ausschnitte des konzeptionellen Modells; Separierung aufgrund bestimmter
Aufgaben, die der jeweilige Ausschnitt erfüllen soll.
l Die Aufgaben sind durch die Anforderungen einzelner Benutzer, Anwendungen
oder Prozesse festgelegt.
132
l ”Benutzersicht” auf die Daten
Internes/physisches Schema
(physisches Datenbankmodell)
1
1
Logisches Relationenmodell
(Normalisierung)
-)Schema
P
1
P
Konzeptionelles Datenmodell
(ERM)
Abgrenzung
Realitätsausschnitt
133
Konzeptionelles Datenmodell
l
l
l
l
l
Modellierung des Realitätsausschnittes aus fachlicher Sicht
Von der (technischen) Implementierung unabhängig
Semantisches Datenmodell (z. B. mit ERM)
Trennung von Essenz und Inkarnation
Erlaubt die Mitwirkung von Nicht-Informatikern bei der Datenmodellierung
(Benutzerpartizipation).
Logisches Relationenmodell
l Überführung des konzeptionellen Datenmodells in ein logisches Schema (hier:
Relationenmodell), das dann direkt in ein technisches (hier: relationales)
Datenbanksystem (interne, physische Umsetzung auf Speichermedien) überführt
werden kann.
l Hier: Relationenmodell ist somit abhängig vom anvisierten (hier: relationales)
Datenbanksystem, in das es umgesetzt werden soll.
134
Datenstruktur entwerfen und implementieren
Anwendungsproblem
Konzeptuelles
Datenmodell
Fakturierung
PC-Händler
z. B. als
ER-Modell
Automatisierung der
Rechnungsstellung,
Typische Rechnung
sieht wie folgt aus:
.......................
..................
verbal,
textuell,
visuell
135
Relationales
Datenmodell
Menge von
Relationenschemata
Internes
Datenbankmodell
Phys. Datenorganisation
Kunde (KNr,
KName, KStr,
KPlz, KOrt)
Artikel (ANr,
ABez, APreis)
z. B. Oracle
formal,
vollständig,
graphisch
Namen, Attribute,Keys,
Werte, ...
DDL/SQL:
create database, table
Datenmodellierung
Normalisierung
5.4 ERM - Entity Relationship Modeling
ERM - Entity Relationship Modeling
l 1976 von Peter Chen vorgestellt
l Semantische Datenmodelle
l In ERM (Entity-Relationship-Modellen) werden permanent zu speichernde Daten
und ihre Beziehungen modelliert.
l Keine Berücksichtigung von Datenflüssen, Organisationsstrukturen, Funktionen
ERM - Anwendungsbereiche
l Allgemeiner Ansatz, um Datenmodelle zu
entwerfen
l Unabhängig vom anvisierten Datenbanksystem
(klassisch, relational)
l Das “WAS” eines Systems steht im Vordergrund,
nicht das “WIE”.
l IKS-Entwicklung: Grobentwurf, Fach- und
Systemkonzeption
136
Anwendungsfelder ERM
Situationsstudie
Entwicklungsebenen
Situationsstudie
Validierung
Fachkonzeption
Systemkonzeption
Systementwicklung
Systeminstallation
Meilenstein
1
Fachkonzeption
Validierung
Meilenstein
2
Systemkonzeption
Validierung
Meilenstein
3
Systementwicklung
Validierung
Meilenstein
4
Systeminstallation
Validierung
137
Meilenstein
5
Zeit
ERM Darstellungselemente
(klassisch)
l
l
l
l
Entitätsmengen
Entitätsmenge
erteilt
Attribut
Relationen
Attribute
Kunde
Kardinalitäten
1
n
bucht
Leihwagen
Leihdatum
Preis
Dauer
138
5.4 ERM - Entity Relationship Modeling: Entität
Entitätsmenge
l Entitätsmenge, Entity Set, Entitätstyp, Objekttyp
l Eine Entitätsmenge enthält Entitäten (Ausprägungen)
l Entität: Individuelles, identifizierbares Exemplar von Dingen, Personen, Begriffen
der realen oder Vorstellungswelt; wird durch Eigenschaften beschrieben.
l Entitätsmenge: Zusammenfassung von Entitäten mit gleichen Eigenschaften
unter einem gemeinsamen Oberbegriff
l Symbol: Rechteck
l Beschriftung: Substantiv (Singular)
l Bsp: Kunde = Entitätsmenge / Müller, Meier, Schmidt ... = Entitäten
Entitätsmenge
139
5.4 ERM - Entity Relationship Modeling: Attribut
Attribut
l
l
l
l
(Beschreibendes) Attribut, Property
Fachliche Eigenschaft, die allen Entitäten einer Entitätsmenge gemeinsam ist.
Symbol: Oval
Beschriftung: Substantiv (Singular)
Kunde
Name
Adresse
Telefon
140
5.4 ERM - Entity Relationship Modeling: Schlüsselattribut
Identifizierendes Attribut: “Schlüssel”
l
l
l
l
l
l
Identifizierendes Attribut, Schlüsselattribut, Key (primary, foreign)
Schlüssel zur eindeutigen Identifizierung einer Entität
Schlüssel: minimale identifizierende Attributkombination
Symbol: Oval mit unterstrichener Beschriftung
Künstliche Schlüssel: i. d. R. Nummern
Zusammengesetzte Schlüssel:
z. B. Name + PLZ
Kunde
Kunden-Nr.
Name
Adresse
141
Telefon
5.4 ERM - Entity Relationship Modeling: Relation
Relation, Beziehungstyp
l
l
l
l
Relation, Beziehungstyp, Relationstyp, Assoziation, Relationship
Verbindet Entitätstypen / Symbol: Raute / Beschriftung: Verb (i. d. R.)
Beziehungstypen können Attribute besitzen
Zwei Entitätstypen können durch mehrere Beziehungstypen miteinander in
Verbindung stehen.
l Zum Beziehungstyp gehört die Kardianlität (s. ff.)
Kunde
1
bucht
n
Leihwagen
Leihdatum
Preis
Dauer
142
5.4 ERM - Entity Relationship Modeling: Kardinalität
Kardinalität
l Kardinalität, Komplexitätsgrad
l Gibt an, mit wieviel A-Entitäten eine B-Entität in Verbindung stehen kann.
l Symbol: Jeweils an den verbundenen Entitäten
1 : 1 oder
1 : n oder
n:m
l Symbolplazierungen sollten modellweit in der gleichen Leserichtung erfolgen.
l Entscheidend für die Kardinalität eines Beziehungstyps sind die fachlichen
Gegebenheiten im Zusammenhang mit den zu verbindenden Entitätsmengen.
l Bsp.: Studenten müssen mehrere Klausuren schreiben und an jeder Klausur
nehmen mehrere Studenten teil.
l Bsp.: Ein Bibliotheksbenutzer leiht mehrere Bücher aus und ein Buch kann von
mehreren Benutzern ausgeliehen worden sein (hintereinander).
l Häufig: Zeitpunkt-/Zeitraumbetrachtungsproblem
143
• 1:1 - Ein Mann heiratet
eine Frau. Eine Frau
heiratet einen Mann.
Mann
• 1:n - Ein Kunde kann
mehrere PKWs kaufen.
Ein PKW wird immer von
genau einem Kunden
gekauft.
Kunde
• n:m - Ein Student kann
mehrere Seminare
besuchen. Ein Seminar
wird von mehreren
Studenten besucht (i. d. R.).
Student
1
heiratet
1
n
kauft
n
1
besucht
m
144
Auftrag
1
besteht
aus
n
Position
Artikelbez.
Eingang
Einzelpreis
Kunden-Nr.
Menge
l Ein Auftrag besteht aus einer oder mehreren Auftragspositionen.
l Eine Auftragsposition gehört immer zu genau einem Auftrag.
145
Frau
PKW
Seminar
Produkt
n
m
liegt
Lager
Bezeichnung
Gewicht
Adresse
Farbe
Leiter
l Ein bestimmtes Produkt kann sowohl im Lager Mainz als auch im Lager Trier
vorgehalten werden.
l Hier fachlich gegeben: In einem bestimmten Lager können immer mehrere
Produktarten vorgehalten werden.
l 1 Lager mit genau einer Produktart müßte mit 1:1 modelliert sein.
146
Firmen- 1
Kunde
n
leiht
Leihwagen
Entleihdatum
Rückgabe am
Preis
l Zu modellieren ist: Wer hat einen bestimmten Wagen zur Zeit geliehen?
l Ein Firmenkunde hat in einem bestimmten Zeitraum keinen, einen oder mehrere
Wagen für seine Mitarbeiter ausgeliehen.
l Ein Wagen ist zu einem bestimmten Zeitraum genau an einen Kunden verliehen.
l Kann nicht beantworten: Wer hatte wann welchen Wagen geliehen?
147
Firmen- n
Kunde
leiht
m
Leihwagen
Name
Fabrikat
Adresse
Farbe
Bonität
Laufleistung
l Zu modellieren ist: Welche Kunden hatten wann welche Wagen gemietet?
Welche Kunden hatten bereits den Wagen “X” gemietet?
l Ein Wagen wird in seiner Nuzungszeit an viele Kunden verliehen.
l Ein Kunde kann einen oder mehrere Wagen leihen.
148
Komplexitätspräzisierung
•
•
•
•
149
Die (1,n,m)-Notation
der Komplexität kann
durch die (min, max)Notation präzisiert
werden.
min: die mindestens
erforderliche Anzahl
von Beziehungen
max: die maximal
zulässige Anzahl von
Beziehungen
Zur Besetzung der
min- und max-Position werden 0, 1, *
(viele) oder genaue
Zahlenangaben
verwendet.
Mann
•
(0,1)
Frau
(1,1)
kauft
(0,*)
PKW
Genau 1 Kunde kann entweder beliebige viele oder null PKWs
kaufen. Jeder PKW wird von genau einem Kunden gekauft oder ist
noch nicht verkauft.
Student
•
heiratet
1 Mann kann maximal 1 Frau heiraten und umgekehrt. Nicht jeder
Mann oder jede Frau muß heiraten.
Kunde
•
(0,1)
(2,20)
besucht
(3,*)
Seminar
Ein Seminar findet nur mit mindestens 2 und maximal 20 Studenten
statt. Jeder Student muß mindestens 3 Seminare besuchen; er kann
beliebig viele besuchen.
Kardinalität: Vielzahl von Notationsformen (Beispiele)
MCNumerische
Notation
Notation
(0,1)
C
MartinNotation
A
max.
1
(1,1)
A
genau
MC
(0,n)
A
max.
M
(1,n)
A
genau
B
genau
PfeilNotation
A
BachmannNotation
B
B
genau
A
B
B
max.
A
B
B
max.
A
A
B
A
B
B
150
Kardinalität
l
l
l
l
l
Beispiel: Fluggesellschaft - Passagierverwaltung
Entitätsmenge “Passagier” mit Name, Vorname, Personalausweis-Nr., .....
Entitätsmenge “Flug” mit Flugnummer, Datum, Reiseziel, .....
Ein Passagier kann mit verschiedenen Flügen (Wien, Paris etc.) fliegen.
Also 1: n ?
Merke:
Kardinalität immer von beiden Seiten betrachten.
Analyse nicht nach erstbester Interpretation abschließen.
151
5.4 ERM - Entity Relationship Modeling: Schwache Entitäten
Schwache Entitätsmengen
l Schwache Entitätsmengen enthalten Entitäten, die nur in Abhängigkeit von einer
anderen Entität existieren können.
l Voll partiziperende vs. schwache Entitätsmenge
l Symbol: Doppeltes Rechteck
YachtEigner
1
Voll partizipierende
Entitätsmenge
besitzt
n
Yacht
Schwache
Entitätsmenge
Yachteigner: YEigner_nr, YE_Name, YE_Bankverbindung
Yacht:
YEigner_nr, Yacht_nr, Yacht_Name
152
5.4 ERM - Entity Relationship Modeling: Rekursive Beziehungen
Rekursive Beziehungstypen
l Entitätsmange steht mit sich selbst in Beziehung
1
Mitarbeiter
n
153
hat Personalverantwortung für
5.4 ERM - Entity Relationship Modeling: Beziehung “Aggregation”
Beziehungstyp “Aggregation”
l ist-Teil-von / is-part-of / Über-Untergeordneten-Beziehung
l Vererbt von Teilen auf Ganzes, von unten nach oben
Motorrad
Kolben
Ventile
Teil von
Teil von
Speichen
Teil von
Ventil
Motor
Felge
Rahmen
Kolben
Speichen
Gabel
Ventile
Ventil
Quertr.
Gabel
Quertr.
154
5.4 ERM - Entity Relationship Modeling: Beziehung “Generalisierung”
Beziehungstyp “Generalisierung”
l Attribute einer Entitätsmenge (subtype) sind einer übergeordneten Entitätsmenge
(supertype) zuzuordnen (subtype relationship).
l Vererbung vom Ganzen auf´s Spezielle, von oben nach unten
Name
Person
Geb.-Dat.
Name
Geb.-Dat.
155
ist ein
ist ein
ist ein
Kunde
Mitarbeiter
Lieferant
5.4 ERM - Entity Relationship Modeling: Beziehung “Student - Klausur”
Beispiel “Student - Klausur”
l
l
l
l
Fachbereich
1
Ein Fachbereich besteht aus mehreren Abteilungen.
Jede Abteilung besteht aus mehreren Lehrstühlen.
n
Jeder Lehrstuhl bietet Klausuren an.
Studenten schreiben pro Lehrstuhl 1 Klausur.
Abteilung
Problembereich
l Mehrere Studenten nehmen an einer Klausur teil.
Lehrstuhl
Aber: 1 Student schreibt nur 1 Klausur?
Student
n
1
Klausur
156
5.4 ERM - Entity Relationship Modeling: Beispiel “Ruderboot”
ERM-Beispiel: Ruderboot-Vermietung
l Ein Ruderverein hat Mitglieder, die ihre (Ein-Mann-) Ruderboote an
vereinsexterne Hobbysportler vermieten.
l Ein Vereinsmitgleid kann mehrere Boote besitzen und anbieten.
l Die Vermietung bezieht sich immer auf das Abfahren einer vorgegebenen
(sicheren) Ruder-Tour. Diese Tour ist Bestandteil des Mietvertrags.
l Der Mieter kann sich sein Boot nach Gewicht und Farbe aussuchen.
l Für jede Tour gibt es eine festgelegte Anzahl an Rudermeilen. Am Jahresende
bekommen alle Hobbysportler mit mehr als 100 Rudermeilen ein Geschenk.
157
Tour
Tour_nr
Starke EM
Ziel
Rudermeilen
wird vereinbart in
Hobbysportler
Ruderboot
Mietvertrag
Kunden_Nr
Nachname
Vorname
Identifiz. 1:N Bzt.
schließt
Mietvertragnr
Boot_Name
umfaßt
Schwache EM
Farbe
Gewicht
Datum
gehört
Bootsbesitzer
Ruderverein
Vereins_Nr
BB_Nr
Verein_Name
V_Telefon_Nr
BB_Nachname
BB_Vorname
BB_Telefon
Nicht- ident. 1:N Bzt.
158
Tour
l Jeder Vertrag ist
Tour_nr
Ziel
Rudermeilen
eindeutig einem
Mieter zugeordnet.
wird vereinbart in
l Jedem Vertrag ist
eindeutig eine
Tour mit best.
Rudermeilen
zugeordnet.
Hobbysportler
Nachname
Vorname
Ruderboot
Mietvertrag
Kunden_Nr
schließt
Mietvertragnr
Datum
umfaßt
Boot_Name
Farbe
Gewicht
gehört
Ruderverein
159
Bootsbesitzer
Vereins_Nr
BB_Nr
Verein_Name
V_Telefon_Nr
BB_Nachname
BB_Vorname
BB_Telefon
5.4 ERM - Entity Relationship Modeling: Beispiel “Segeltörn”
ERM-Beispiel: Segeltörn-Vermittlung
l In der Mitsegler-Agentur Windei GmbH werden Yachteignern Teilnehmer an
Segeltörns vermittelt. Einem Eigner können mehrere Yachten gehören, während
eine Yacht nur einem Eigentümer gehört. Jeder Törn findet mit einem
festgelegten Start- und Endedatum statt.
l Jede Jacht kann während der Saison für mehrere Törns verplant werden. Jeder
Törn hat genau ein Reiseziel, das aber von mehreren Törns angelaufen werden
kann. Der Preis des Törns ist abhängig vom Reiseziel und von der Yacht.
l Jeder Mitsegler kann während der Saison an mehreren Törns teilnehmen. Er
schließt dazu für jeden Törn einen Vertrag mit dem betreffenden Yachteigner.
l [Zusatz, nicht zu modellieren: Es ist auch
möglich, daß sich mehrere Segler zu
einer Gruppe zusammenschließen und
gemeinsam einen Vertrag mit dem Eigner
abschließen.]
160
ERM-Beispiel: Segeltörn-Vermittlung
eingeplant für
Yachteigner
161
fährt nach
schließt ab
wird angefahren von
Reiseziel
abgeschlossen für
Törn
gebucht in
findet statt mit
besitzt
Yacht
Vertrag_Törn
schließt ab
Kunde
Yacht
Törn
Törn_nr
Yacht_nr
Yachteigner_nr (FK)
Yacht _Name
Baujahr
Modell
Farbe
Max_teilnehmer
Motor
Y_Preiskategorie
Yacht_nr (FK)
Yachteigner_nr (FK)
Dauer
Mittagessen
Komfortkl asse
Reiseziel_nr (FK)
Startdatum
Endedatum
wird eingeplant für /
findet statt mit
besitzt
Inselname
Hafen
Beschreibung
Sandstrand
Klima
Meilen
Preiskategorie
wird gebucht in /
für
Kunde
Yachteigner
Kunden_nr
Yachteigner_nr
Name_YE
Adresse_YE
Schiffschein
Erf ahrung
Kontoverbindung
162
Rei seziel
Reiseziel_nr
fährt zu /
wird angefahren von
schließt
Vertrag_Törn
Yachteigner_nr (FK)
Vertrag_nr
Törn_nr (FK)
schl ießt
Preis
Versicherungsschutz
Sonderleistungen
Name_kd
Adresse_Kd
Geburtstag
Kundenklasse
Werbung_erwünscht
5.4 ERM - Entity Relationship Modeling: Tool “ERWin”
ERWin: Datenmodellierungs- und Data-Base-Design-Tool
l
l
l
l
Ziel: Modell in physische, relationale Datenbanken umsetzen
l
l
l
l
l
Auslesen und analysieren bestehender Datenbanken (reverse engineering)
Unterstützt bei der Erstellung von semantischen Datenmodellen (ERM: “logical”)
Setzt Logical Model um in (normalisierte) Relationenschemata
Setzt Schemata um in physische Datenstrukturen des DBMS
(forward engineering)
Synchronisieren von Modell und bestehender Datenbank (altering DB)
Datenmengengerüst-Berechnungen (Volumetrics)
Umfangreiche Report-Funktionen
Integriert in Produktfamilie u. a. mit BPWin zur Modellierung von
Geschäftsprozessen
l ERWin-Modell-Input für die wichtigsten Datenbanksysteme: DB2, Informix,
Ingres, Oracle, Progess, SQL-Server, Sybase, MS Access, Clipper, dBase,
Foxpro, Paradox, ......
163
ERWin: Erstellen “logical” und “physical modell”
Konzeptuelles Schema
Konzeptuelles Schema
(sem. Datenmodell)
(logische Ebene)
l Érstellen von Entitätsmengen
l Erstellen von Relationstypen
l Konkretisierung von
Kardinalitäten (auch n:m)
l Hinzufügen von Attributen
Relationenmodell
Relationenmodell
Internes/physisches
Internes/physisches
Schema
Schema
l ERWin löst n:mBeziehungen auf
l Konkretisierung der
Datentypen
l Ziel-DBMS angeben
l Generierung per
Knopfdruck
l Physical Model
(ohne Datentypen)
l Hinterlegung von
Informationen zu Attributen
164
l Logical Model
ERWin: Logical Model
(konzeptionelles)
165
ERWin:
Physical
Model
(Relationenschema,
normalisiert)
166
5.4 ERM - Entity Relationship Modeling: Exkurs “Normalisierung”
Datenstruktur entwerfen und implementieren
Anwendungsproblem
Konzeptuelles
Datenmodell
Fakturierung
PC-Händler
z. B. als
ER-Modell
Automatisierung der
Rechnungsstellung,
Typische Rechnung
sieht wie folgt aus:
.......................
..................
verbal,
textuell,
visuell
167
Relationales
Datenmodell
Menge von
Relationenschemata
Internes
Datenbankmodell
Phys. Datenorganisation
Kunde (KNr,
KName, KStr,
KPlz, KOrt)
Artikel (ANr,
ABez, APreis)
z. B. Oracle
formal,
vollständig,
graphisch
Namen, Attribute,Keys,
Werte, ...
DDL/SQL:
create database, table
Datenmodellierung
Normalisierung
Datenbankentwurf und Normalisierung
l Jede Relation repräsentiert nur eine sachliche Bedeutungseinheit.
l Daten sollen redundanzfrei gespeichert werden.
l Der Normalisierungsprozeß soll dies sicherstellen.
Der Normalisierungsprozeß
l Relationenschemata prüfen und ggfs. ohne Informationsverlust in
mehrere Basis-Relationenschemata zerlegen
l Normalerweise: „Normalisierende“ Nachbearbeitung eines ERM
l Nachfolgend: Vorbereitung
Unnormalisiert
1.
2.
3. NF
168
Beispiel “ Rechnungstellung an Kunden eines PC-Händlers”
l Beschreibung des Problems bekannt, kein ER-Modell vorhanden
l Zusammenstellung aller relevanten Daten mit Beispielrechnungen
l Tabellarische Gesamtsicht als Vorbereitung für Normalisierung
Tabellarische Zusammenstellung relevanter Daten und Beispielrechnungen
ReNr ReDat
KNr KName KStr
005 13.05.00 224
006 13.05.00 123
169
KOrt ANr ABez
55128 Mainz 125
120
Krause B-Straße 8 55131 Mainz 300
Schulze C-Allee 4 55131 Mainz 200
930
250
Meier D-Platz 3 55116 Mainz 200
Krause B-Straße 8 55131 Mainz 310
002 12.05.00 543 Meier
003 12.05.00 123
004 13.05.00 379
KPlz
A-Weg 5
ZIP-100
PC-800
CD-300
DVD-10
HUB-20
HDD-40
DVD-10
SCA-63
APreis AMe
198,00
999,00
248,00
448,00
110,00
598,00
448,00
799,00
4
1
1
1
3
1
2
1
Daten nach Hauptkriterien ordnen: Unnormalisierte Relationen
l
l
l
l
Kunden und Artikel eigenständige Bedeutungseinheiten je mit Primärschlüssel
Übrig für “Rechnungs-Daten”: ReNr, ReDat, AMe
Informationsverlust !!
Welche Rechnung an welchen Kunden? Welche Artikel in welcher Rechnung?
Daher: Aufnahme der Fremdschlüssel KNr, ANr in “Rechnungs-Daten”
Rechnungs-Daten
Artikel-Daten
Kunden-Daten
KNr KName KStr
KPlz
KOrt
123
224
379
543
55131
55116
55131
55128
Mainz
Mainz
Mainz
Mainz
Krause
Meier
Schulze
Meier
B-Straße 8
D-Platz 3
C-Alle 4
A-Weg 5
ANr ABez
APreis
120
125
200
250
300
310
930
999,00
198,00
448,00
598,00
248,00
799,00
110,00
PC-800
ZIP-100
DVD-10
HDD-40
CD-300
SCA-63
HUB-20
ReNr ReDat
002
003
004
005
006
KNr ANr AMe
12.05.00 543 120
125
12.05.00 123 300
13.05.00 379 200
250
930
13.05.00 224 200
13.05.00 123 310
170
Von der unnormalisierten zur 1. Normalform
l 1. NF: Wiederholungsgruppen beseitigt / nur einwertige, elementare Felder
l Datensatz-Identifikation nun nur über komb. Primärschlüssel “ReNr + ANr”
Unnormalisiert: 5 Datensätze
1. Normalform: 8 Datensätze
Rechnungs-Daten
Rechnungs-Daten
ReNr ReDat
002
003
004
005
006
171
KNr ANr AMe
12.05.00 543 120
125
12.05.00 123 300
13.05.00 379 200
250
930
13.05.00 224 200
13.05.00 123 310
1
4
1
1
1
3
2
1
Wiederholungsgruppen !
Mehrwertige Zellen (Felder)
ReNr ReDat
002
002
003
004
004
004
005
006
12.05.00
12.05.00
12.05.00
13.05.00
13.05.00
13.05.00
13.05.00
13.05.00
KNr ANr AMe
543
543
123
379
379
379
224
123
120
125
300
200
250
930
200
310
1
4
1
1
1
3
2
1
Wiederholungsgruppen durch
“Auffüllen” zu einwertigen Feldern
1
4
1
1
1
3
2
1
Vorüberlegungen für die 2. Normalform
l Redundanzerhöhung, da einige Nichtschlüsselattribute nur von einem Teil des
kombinierten Primärschlüssel abhängig sind (”funktional abhängig”).
l Siehe bspw. 2. Datensatz: Für die Rechnungsposition mit der ANr 125 müssen
ReDat und KNr nicht eigens nochmal gespeichert werden, da beide
Informationen eindeutig über die ReNr bestimmt sind.
1. Normalform:
Redundante Mehrfacheinträge
in ReDat und KNr
Rechnungs-Daten
ReNr ReDat
002
002
003
004
004
004
005
006
172
KNr ANr AMe
12.05.00
12.05.00
12.05.00
13.05.00
13.05.00
13.05.00
13.05.00
13.05.00
543
543
123
379
379
379
224
123
120
125
300
200
250
930
200
310
1
4
1
1
1
3
2
1
Von der 1. Normalform zur 2. Normalform
l 2. NF: In 1. NF und alle Nichtschlüsselattribute sind vom Primärschlüssel nicht
nur “funktional abhängig”, sondern “voll funktional abhängig”.
l Zerlegen in 2NF-Relationen mit “voll funktionaler Abhängigkeit”
Neue Relation in 2. Normalform
Weitere neue Relation in 2. Normalform
Rechnungs-Köpfe
Rechn.-Positionen
ReNr ReDat
KNr
ReNr ANr AMe
002
003
004
005
006
543
123
379
224
123
002
002
003
004
004
004
005
006
12.05.00
12.05.00
13.05.00
13.05.00
13.05.00
Auslagerung der Attribute, die
nur vom Primärschlüssel
“ReNr” voll abhängig sind.
173
120
125
300
200
250
930
200
310
1
4
1
1
1
3
2
1
Die Attribute, die vom kombinierten
Schlüssel “ReNr+ANr” voll abhängig sind.
Vorüberlegungen für die 3. Normalform
l
l
l
l
l
Betrachtung von funktionalen Abhängigkeiten zwischen Nichtschlüsselattributen
Bspw. in Relation “Kunden-Daten”: KOrt ist abhängig von KPlz
KPlz wiederum ist abhängig von KNr
KNr determiniert KPlz und KPlz determiniert KOrt (keine Umkehrung)
KOrt ist transitiv abhängig von KNr
2. Normalform
Nur voll funktionale Abhängigkeiten
(da nur ein einziges Schlüsselattribut)
Redundanz: Postleitzahl des
Wohnorts von Krause und Schulze
doppelt enthalten
Kunden-Daten
Transitive Abhängigkeit
174
KNr KName KStr
KPlz
KOrt
123
224
379
543
55131
55116
55131
55128
Mainz
Mainz
Mainz
Mainz
Krause
Meier
Schulze
Meier
B-Straße 8
D-Platz 3
C-Alle 4
A-Weg 5
KPlz
KNr
KOrt
Keine Umkehrung
KPlz
KOrt
KNr
Von der 2. Normalform zur 3. Normalform
l 3. NF: In 2. NF und kein Nichtschlüsselattribut ist vom Primärschlüssel transitiv
abhängig.
l Zerlegen in 3NF-Relationen ohne transitive Abhängigkeiten
l Funktional abhängige Nichtschlüsselattribute auslagern
Neue Relation in 3. Normalform
Kunden-Daten
175
KNr KName KStr
KPlz
123
224
379
543
55131
55116
55131
55128
Krause
Meier
Schulze
Meier
B-Straße 8
D-Platz 3
C-Alle 4
A-Weg 5
“Alte” Tabelle ohne KOrt;
KPlz wird zum Fremdschlüssel
Weitere neue Relation
in 3. Normalform
Orts-Daten
KPlz
KOrt
55116 Mainz
55128 Mainz
55131 Mainz
KPlz wird zum
Primärschlüssel
Die Basis-Relationenschemata in 3. Normalform
Kunden-Daten
Orts-Daten
Artikel-Daten
KNr KName KStr
KPlz
KPlz
123
224
379
543
55131
55116
55131
55128
55116 Mainz 120 PC-800
55128 Mainz 125 ZIP-100
55131 Mainz 200 DVD-10
250 HDD-40
300 CD-300
310 SCA-63
930 HUB-20
Krause
Meier
Schulze
Meier
B-Straße 8
D-Platz 3
C-Alle 4
A-Weg 5
KOrt
ANr ABez
Rechnungs-Köpfe
Rechn.-Positionen
APreis ReNr ReDat
KNr
ReNr ANr AMe
999,00
198,00
448,00
598,00
248,00
799,00
110,00
543
123
379
224
123
002
002
003
004
004
004
005
006
002
003
004
005
006
12.05.00
12.05.00
13.05.00
13.05.00
13.05.00
Kunden
Kunden(KNr,
(KNr,KName,
KName,KStr,
KStr,KPlz)
KPlz)
KOrt)
Orte
(KPlz,
Orte (KPlz, KOrt)
Artikel
Artikel(ANr,
(ANr,ABez,
ABez,APreis)
APreis)
Rechnungsköpfe
(ReNr,
ReDat,KNr)
KNr)
Rechnungsköpfe (ReNr,ReDat,
Rechnungspositionen
ANr,AMe)
AMe)
Rechnungspositionen(ReNr,
(ReNr,ANr,
176
Positive Anmerkungen zur Normalisierung
l Redundanzen in den Tabellen sind beseitigt
l Dabei keine Verluste von Informationen oder Abhängigkeiten
l ”One fact in one place”: Änderungsfreundlichkeit, Konsistenz
Alle Datenstrukturierungsprobleme gelöst ?
l
l
l
l
l
l
l
177
Für die Paxis meist ausreichend: 1., 2., 3. Normalform
Weitere: Boyce-Codd, 4. und 5. Normalform
Anzahl der Tabellen (Komplexität) steigt mit höherer Normalform
Applikationen, mehrere Tabellen betreffend: Performance sinkt
Schlüssel-Redundanzen entstehen
Kompromiß: Redundanz vs. Performance/Konsistenz
Bspw.: “Kunden” in 2. Normaform belassen, da begrenzte,
kontrollierte Redundanz
120
125
300
200
250
930
200
310
1
4
1
1
1
3
2
1
Gliederung
178
6.1 Zum Paradigma der Objektorientierung: Aufsetzpunkte
Aufsetzpunkte der objektorientierten Entwicklung
l Konkurrierender Ansatz zur funktionsorientierten und datenorientierten
Entwicklung von Anwendungssystemen
l Funktions- und Datenorientierung sind relativ eigenständige Komplemente der
Systementwicklung, die sich in der Entwicklungssequenz stark auf die SystemAnalyse und den System-Entwurf konzentrieren.
l Funktions- und Datenorientierung priorisieren und kombinieren sich je selbst mit
dem je anderen Ansatz, um die relevanten Systemelemente (Gegenstände,
Abläufe) abzudecken. Probleme: Organisation, Steuerung, Integration
Funktion
Unterfunktion
Unterfunktion
Fachbereich
Funktionen
Unterfunktion
Abteilung
Organisation ?
Steuerung ?
Daten
Lehrstuhl
179
Elementarfunktion
Elementarfunktion
Elementarfunktion
Integration ?
Student
Klausur
6.1 Zum Paradigma der Objektorientierung: Beispiel OOA-Modell
2
OOA-Modell
nach
Coad/Yourdon
Sachgebiete:
1: Auftraggeber
2: Auftrag
3: Mitarbeiter
3
1
180
6.1 Zum Paradigma der Objektorientierung: Beispiel OO mit UML
Konto (abstrakt)
Nummer
Eröffnungsdatum
Saldo
Zinssatz für Habenzinsen
eröffne (Datum, Betrag)
zahle ein (Datum, Betrag)
hebe ab (Datum, Betrag)
schreibe Zinsen gut ()
löse auf ()
berechne Kontoführungs
gebühr ()
berechne Quartalsumsatz()
Girokonto
berechne
Kontoführungsgebühr ()
Sparkonto
181
1
1..*
Kunde (abstrakt)
Name
Adresse
drucke Adresse ()
berechne Quartalsumsatz ()
# erstelle Serienbrief ()
1..*
1
Kundenbetreuer
Name
Personalnummer
berechne
Quartalsumsatz ()
1
..*
1..*
1
Buchung
Datum
Währung
Betrag
Art
BLZ
Verwendungszweck
stornieren ()
ist storniert ()
# Anzahl Buchungen
pro Quartal ()
# berechne
Quartalsumsatz ()
Privatkunde
Geburtsdatum
Firmenkunde
Name des Ansprechpartners
Anrede des Ansprechpartners
OO-Modell
in UML
6.1 Zum Paradigma der Objektorientierung: Anliegen
Intentionen, Anliegen der OO: “Natürlichkeit, Verständlichkeit” (?)
l Konsistente (durchgängige) Integration der zu modellierenden Systemelemente
l Ganzheitliche Systementwicklung mit Durchgängigkeit über System-Analyse,
System-Entwurf und System-Implementierung
l Konzentration auf Entitäten (Objekte) und Priorisierung dessen, was ein Objekt
ist, weniger wie es verwendet wird. Demnach hat die Datenstruktur ein größeres
Gewicht als die Funktionsstruktur.
l Objektorientiert modelliert/entwickelte Systeme besitzen angeblich folgende
besondere Eigenschaften im Vgl. zu Systemen, die nach dem tradierten
funktionsorientierten Paradigma entwickelt wurden:
- Verkürzung der Entwicklungszeiten
OO ohmmm
- Niedrigere Entwicklungskosten
OO ohmm
- Reduzierung der Modell- und System-Komplexität
- Höhere Qualität der Modelle und Entwürfe
- Bessere Umsetzung der Benutzeranforderungen
- Methodische Durchgängigkeit und Rückverfolgbarkeit
- Einfachere Portierung auf andere Plattformen
- Erheblich vereinfachte Pflege und Weiterentwicklung
- Wiederverwendbarkeit von Systemteilen
l .... etc. pp.: “Alles wird gut!” (Man muß nur dran glauben.)
182
6.1 Zum Paradigma der Objektorientierung
Anwendungsfelder OO-Methoden (Anspruch!)
Situationsstudie
Entwicklungsebenen
Situationsstudie
Validierung
Fachkonzeption
Systemkonzeption
Systementwicklung
Systempflege
Meilenstein
1
Fachkonzeption
Validierung
Meilenstein
2
Systemkonzeption
Validierung
Meilenstein
3
Systementwicklung
Validierung
Meilenstein
4
Systeminstallation
Validierung
183
Meilenstein
5
Zeit
6.1 Zum Paradigma der Objektorientierung: Chronologie
Chronologie: OO-Entwicklung/-Programmierung/-Codierung
l Von der Programmierung (Entwicklung, Implementierung, 70er) über Entwurf
(Systemkonzeption, 80er) zur Analyse (Fachkonzeption, Situationsanalyse, 90er)
l
l
l
l
1967: Objektorientierte Programmierung mit SIMULA 67
1976: Programmiersprache Smalltalk; erstmals Begriff “Objektorientierung”
1985: Programmiersprache C++
1989 bereits ca. 88 oo/-basierte/oo-erweiterte Sprachen
(Eiffel, Oberon, Objective-C, Pascal, Modula-2, Lisp etc.)
70er Jahre:
OO-Codierung
Chronologie: OO-Entwurf/-Design/-Konzeption
l Ausrichtung der Systemkonzeption (Design, Entwurf)
nach den Grundgedanken der Objektorientierung
(nicht mehr nach der Funktions-/Prozedur-Orientierung)
184
l
l
l
l
80er Jahre:
OO-Design
1977: Beschreibungssprache DELTA
1981: OO-Entwurf von Booch auf Basis von ADA
1988: OO-Design nach Wirfs-Brock
1992: BON (Better Object Notation) von Nerson
90er Jahre:
OO-Analyse
6.1 Zum Paradigma der Objektorientierung: Chronologie
Chronologie: OO-Analyse / Fachkonzeption
l In den 90er Jahren erst OO-Ausrichtung auch der frühen Phasen der Situationsanalyse und Fachkonzeption (auch “Fachentwurf” genannt)
l Damit hatte sich das OO-Pardigma bottom-up von der Programmierung her bis
zur fachlichen Planung eines Systems auf den gesamten Entwicklungsprozeß
ausgedehnt.
l 1988: Shlaer und Mellor mit “OO Systems Analysis”
l 1990: Coad und Yourdon mit “OOA”
l 1991: “Booch” nach Booch und “OMT” nach Rumbaugh
90er Jahre:
OO-Analyse
l 1992: OOSE nach Jacobsen
l 1995: Mehr als 40 Analysemethoden, die den Anspruch erheben “oo” zu sein
l 1995: Unified Method nach Booch/Rumbaugh
l 1996: Unified Modeling Language (UML 0.91) nach Booch/Rumbaugh/Jacobsen
185
6.1 Zum Paradigma der Objektorientierung: Ziele
Ziele der Objektorientierung
l Warum ein neues Paradigma mit neuen
Methoden, Techniken, Tools?
l Immer größere und kompliziertere
Softwarepropjekte scheitern am
traditionellen Instrumentarium der
Softwareentwicklung.
l Projekte dauern zu lange, sind zu teuer,
erfüllen nicht die an sie gestellten
Anforderungen.
186
6.1 Zum Paradigma der Objektorientierung: Ziele
Ziele der Objektorientierung
Durch Objekt- und
Klassenbildung
Wiederverwendbarkeit / Modularität
Fehler,
Kosten,
Komplexität,
Entwicklungszeit
reduzieren
Durchgängigkeit
187
... der Methoden von
Analyse bis Codierung
Verständlichkeit
Orientierung am
“Menschen”
6.2 Grundelemente der Objektorientierung: Überblick
Die Grundelemente der Objektorientierung im Überblick
l Je nach Autor werden bestimmte Konstrukte aus der Welt der Objektorientierung
als grundlegende “Elemente”, “Konzepte”, “Prinzipien” o. ä. herausgestellt.
l Weder die Bezeichungen dieser Konstrukte noch deren Auswahl und
Zusammenstellung ist einheitlich.
l Nachfolgend werden die wichtigsten dieser Konstrukte erläutert, die einen
Überblick zur Objektorientierung im allgemeinen geben.
-
Objektbildung
Kapselung
Klassenbildung
Assoziationen
Vererbung
Nachrichtenaustausch
Polymorphismus
188
6.2 Grundelemente der Objektorientierung: Objektbildung
Objektbildung: Was bedeutet “objektorientiert”?
l Grob: Ein System ist eine Ansammlung unterscheidbarer Objekte, die sowohl
eine Datenstruktur als auch ein bestimmtes Verhalten in sich vereinen.
Objektbildung: Was ist ein “Objekt”?
l Ein Objekt ist ein Gegenstand des Interesses, inbesondere einer Betrachtung,
Untersuchung oder Messung.
l Objekte können gegenständliche Dinge oder Begriffe (künstlich) sein.
l Ein Objekt hat Eigenschaften (Attribute).
l Ein Objekt hat gleichzeitig ein Verhalten. Dieses Verhalten wird durch
Operationen (Methoden) ausgedrückt.
Objekt:
Elsa Euter
189
Attribute:
- Farbe (weiß)
- Beine (4)
- Milchmenge (15)
Operationen:
- Melken
- Füttern
- Fortpflanzen
Objektbildung: Eine Tür wird beschrieben durch ....
.... Attribute:
- Größe
- Farbe
- Material
.... Operationen:
- Öffnen
- Schließen
190
Objektbildung: Jedes Objekt hat eine eindeutige Identität
Objekt: Schlüssel
Objekt: Tür
Objekt: Haus
Objekt: Vera Vollmilch
191
6.2 Grundelemente der Objektorientierung: Kapselung
Was bedeutet “Kapselung”?
l Auf die Attributwerte eines Objektes kann nur das Objekt selbst zugreifen.
l Zugriff nur über die Operationen des betreffenden Objektes.
l Ein Objekt “verbirgt“ (kapselt) seine Attribute in sich und gibt nur bekannt, welche
Operationen von ihm zur Verfügung stehen.
l Verhinderung unkontrollierter Datenmanipulationen durch Realisierung des
“Geheimnisprinzips”
Anja Alms Milchproduktion?
Objekt: Anja Alm
Allein ihre Sache!!
192
6.2 Grundelemente der Objektorientierung: Klassenbildung
Was bedeutet “Klassenbildung”?
l Eine Klasse beschreibt eine Menge von Objekten mit gleichen Eigenschaften,
gemeinsamen Operationen, gemeinsamen Beziehungen zu anderen Objekten
und gemeinsamer Semantik.
l Eine Klasse ist somit ein “Bauplan” für bestimmte (reale) Objekte.
Kuh
Klasse
Objekte
Vera Vollmilch
193
Elsa Euter
Anja Alm
6.2 Grundelemente der Objektorientierung: Klassenbildung
Klassenbildung: Darstellung von Klassen und Objekten
l Strukturgleiche (Name, Attribute, Operationen), aber in Details unterschiedliche
Darstellungsformen je nach “OO-Guru”
l Unten Notation in Anlehnung an Rumbaugh
l UML aber z. B. ohne Liste der Operationen bei Objektdarstellung
Darstellung Klasse
Klassenname
Liste der
Attribute
Liste der
Operationen
Darstellung Objekt
:Kuh
Elsa Euter : Kuh
Exemplar von
Instanz von
Instance of
Class Instance
Farbe
Beine
Milchmenge
Melken ()
Füttern ()
Fortpflanzen ()
Farbe = weiß
Beine = 4
Milchmenge = 15 [Liter]
Melken (Liter)
Füttern (Kilo)
Fortpflanzen (Kälber)
194
6.2 Grundelemente
6.1 Zum Paradigma
der Objektorientierung:
der Objektorientierung
Assoziationen
Assoziationen: Beziehungen zwischen Objekten
l Beziehungen zwischen Objekten (gleichgeordneter) Klassen
l Werden durch einfache Linien dargestellt (bi-/unidirektional).
l Nach Möglichkeit werden Assoziationen durch Namen, Kardinalitätsangaben
und/oder Rollennamen beschrieben.
: Kunde
: Auftrag
Name = Meier
Status = aktiv
eMail = [email protected]
1
erteilt
n
Nummer = A-12345
Datum = 15. Mai 2001
Wert = 200.000 [DM]
1
verantwortlich für
n
1
“Objektdiagramm”
: Kundenbetreuer
Name = Müller
Persnr = P-987654321
Branche = Maschinenbau
195
gehört zu
1
: Rechnung
n
hat
m
Nummer = R-232323
Betrag = 300.000 [DM]
Zahlungsart = Bar
6.2 Grundelemente der Objektorientierung: Assoziationen
Spezielle Assoziation: Aggregation
l Aggregation: Ganzes-Teile-Beziehung zwischen Objekten
l Die Objekte sind dabei nicht gleichberechtigt; eine der beteiligten Klassen hat
eine führende Rolle.
l Hier: Fahrrad besteht aus Rahmen und Bremsen (u. a.).
: Fahrrad
Bauteil
Bezeichung = Berglust
Artikelnr = AR-1245
Kategorie = Mountainbike
hat
0..*
besteht aus
1
1
1
n
hat
: Rahmen
: Bremse
Bezeichnung = Longlast
Rahmennr = R-9987
Material = Aluminium
Bezeichnung = LX-20
Hersteller = Hercules
Kategorie = Handbremse
196
6.2 Grundelemente der Objektorientierung: Assoziationen
Spezielle Assoziation: Komposition
l Komposition: spezielle Aggregation
l Existenz der Teile hängt von Existenz des Ganzen ab.
l Hier: Ohne Auftrag keine Positionen und keine Rechnung
: Auftrag
Nummer = A-12345
Datum = 15. Mai 2001
Wert = 200.000 [DM]
hat
197
0..*
1
1
1
n
gehört zu
: Auftragsposition
: Rechnung
Posnr = PO-98765
Artikelnr = AR-1245
Menge = 300
Nummer = R-232323
Betrag = 300.000 [DM]
Zahlungsart = Bar
6.2 Grundelemente der Objektorientierung: Vererbung
Vererbung: Beziehungen zwischen (Ober- und Unter-) Klassen
l Generalisierungs-/Spezialisierungsbeziehung zwischen den beteiligten Klassen
l Vererbung: Beziehung zwischen allg. Ober- und spezialisierten Unterklassen
Insekten
Ur-Insekten
Flug-Insekten
Springschwänze
Ein Flügelpaar
Zwei Flügelpaare
Beintastler
Borstenschwänze
198
Libellen
Bsp. “Taxonomie” (Einordnung in ein biologisches System)
Vererbung: Beziehungen zwischen (Ober- und Unter-) Klassen
l Vererbung (generalization) bedeutet, daß eine spezialisierte Klasse (Unterklasse,
abgeleitete Klasse, subclass) über die Eigensschaften, das Verhalten und die
Assoziationen einer oder mehrerer allgemeiner Klassen (Oberklassen,
Basisklassen, supperclasses) verfügen kann.
l Eine Unterklasse ist vollständig konsistent mit ihrer Oberklasse, enthält aber i. d.
R. zusätzliche Attribute, Operationen und/oder Assoziationen.
l Jede Klasse “kennt” nur ihre eigenen Attribute, Operationen und Assoziationen
und die ihrer Oberklassen(n), sofern diese für die Unterklasse sichtbar sind.
l Für eine Oberklasse sind generell die Attribute, Operationen und Assoziationen
ihrer Unterklassen nicht sichtbar.
l Die Vererbungsbeziehung wird durch einen Pfeil zur Oberklasse gekennzeichnet.
.... oder ....
199
Vererbung: Abstrakte Klassen
l Generalisierungs-/Spezialisierungs-
: Person {abstract}
beziehung zwischen den beteiligten
Klassen
Name
Adresse
Geburtsdatum
l Immer: Jedes Objekt der Unterklasse
“ist ein” (is a) Objekt der Oberklasse.
l Abstrakte Klassen werden nur modelliert,
um ihre Informationen an spezialisierte
Klassen zu vererben.
drucke Adreßaufkleber ()
l Von einer abstrakten
Klasse können keine
(realen) Objekte erzeugt
werden. Im Bsp.: Es gibt
konkret nur Kunden und
Mitarbeiter, keine
“Personen”.
: Kunde
: Mitarbeiter
Branche
Umsatz
Status
Abteilung
Gehalt
Familienstand
ermittele durchschnittl. Umsatz ()
erstelle Urlaubsplan ()
200
Vererbung: Einfachvererbung
l Bei der “Einfachvererbung” hat jede Klasse genau 1 direkte Oberklasse (mit
Ausnahme der Wurzel).
l Es entsteht eine Hierarchie in Form eines (umgedrehten) Baumes.
Oberklasse (Wurzel)
Kraftfahrzeug
Unterklasse
Oberklasse
Unterklasse
201
PKW
Limousine
LKW
Caravan
Sattelschlepper
Auflieger
Vererbung: Mehrfachvererbung
l Bei der “Mehrfachvererbung” (multiple Vererbung) kann jede Klasse mehrere
direkte Oberklassen haben (mit Ausnahme der Wurzel).
l Problem: Eine Klasse kann z. B. zwei Attribute oder Operationen gleichen
Namens von verschiedenen Oberklassen erben. Konfliktlösung erforderlich.
Fahrzeug
Oberklasse (Wurzel)
Unterklasse
Landfahrzeug
Oberklasse
Unterklasse
PKW
LKW
Wasserfahrzeug
AmphibienFZ
Schiff
202
6.2 Grundelemente der Objektorientierung: Nachrichtenaustausch
Nachrichtenaustausch: Grundlegendes
l Die Funktionalität (das dynamische Verhalten) eines objektorientierten Systems
ist in den Operationen seiner Objekte hinterlegt.
l Die Realisierung dieser Funktionalität setzt voraus, daß die Operationen
verkettet werden können.
l Dazu müssen Beziehungen zwischen den beteiligten Objekten bestehen. Die
Objekte müssen “sich kennen” (Vererbungsbeziehungen, Assoziationen).
l Die Operationen der Objekte müssen “aufgerufen, initialisiert” werden.
l Dies geschieht über “Botschaften” (Nachrichten) als “Operationsausführungsanweisungen” zwischen den beteiligten Objekten.
l Die Botschaft (message) trägt den Namen der Operation, die sie aufruft.
Objekt 1 : Klasse A
Attribut 1 =
Attribut 2 =
203
Operation A1 ()
Operation A2 ()
Objekt 1 : Klasse B
Operation B1 ()
Attribut 1 =
Attribut 2 =
Operation B1 ()
Operation B2 ()
Nachrichtenaustausch: Polymorphismus
l Der Empfänger interpretiert die Botschaft, führt seine Operation aus und schickt
das Ergebnis an den Sender zurück.
l Der Sender weiß nicht, wie die Operation vom Empfänger ausgeführt wird.
l Die Menge der Botschaften, auf die die Objekte einer Klasse reagieren können,
wird als Protokoll der Klasse bezeichnet.
l Polymorphismus: Bei der Versendung 1 Botschaft an Objekte verschiedener
Klassen können verschiedene Operationen mit verschiedenen Ergebnissen
ausgelöst werden.
l Bspw. “drucken ()” gesendet an die Klassen “Auftrag” und “Buch”
204
Hans Müller : Mitarbeiter
A-9876543 : Auftrag
Persnr = 1234567890
Abteilung = Vertrieb
Funktion = Sachbearbeiter
Anr = 98786543
Datum = 12.10.2001
Wert = 200.000 [DM]
ändern ()
Kunden kontaktieren ()
Auftrag aufnehmen ()
Auftrag betreuen ()
drucken ()
ändern ()
löschen ()
Nachrichtenaustausch in einer Vererbungsstruktur
l Erhält ein Objekt in einer
Vererbungsstruktur eine Botschaft,
“sucht” es in der Liste seiner eigenen
Klasse nach einer Operation, mit der es
reagieren kann.
l Findet das Objekt dort keine ausführbare
Operation, wird die Suche in der direkten
Oberklasse fortgesetzt (usw.).
: Person {abstract}
Name
Adresse
Geburtsdatum
drucke Adreßaufkleber ()
l Bsp.: Erhält das Kundenobjekt
Müller die Botschaft “drucke
Adreßaufkleber ()”, wird die
entsprechende Operation der
direkten Oberklasse “Person”
ausgeführt.
205
: Kunde
: Mitarbeiter
Branche
Umsatz
Status
Abteilung
Gehalt
Familienstand
ermittele durchschnittl. Umsatz ()
erstelle Urlaubsplan ()
6.2 Grundelemente der Objektorientierung: Überblick
Die Grundelemente der Objektorientierung im Überblick
l Die wichtigsten Konstrukte der OO wurden erläutert, um einen Überblick zur
Objektorientierung im allgemeinen zu geben.
- Objektbildung
- Kapselung
- Klassenbildung
- Assoziationen
- Vererbung
- Nachrichtenaustausch
- Polymorphismus
l Autoren wie z. B. Coad/Yourdon (OOA), Rumbaugh (OMT), Jacobsen (OOSE)
bündelten, erweiterten, variierten die grundlegenden Konstrukte in je eigener
Weise und verwendeten je eigene (graphische und textuelle) Darstellungsformen
(Notationen) für ihre eigenen Methoden der objektorientierten Analyse/Entwurf.
l Grob: Jeder Autor lieferte also je seine bestimmte Menge von Konzepten (was ist
wie darzustellen? = Ergebnissicht) und sein Vorgehensmodell zur Anwendung
der Konzepte (in welchen Schritten wird was ausgeführt, um ein System zu
modellieren? = Prozeßsicht).
l Ergebnis 1: Verschiedene konkurrierende OO-Ansätze
206
l Ergebnis 2: Bedürfnis nach Vereinheitlichung, Standardisierung der OO-Ansätze
6.3 Die Unified Modeling Language (UML): Entstehung
Chronologie zur Unified Modeling Language (UML)
l 1994: Rumbaugh wechselt zu Rational, wo bereits Booch arbeitet.
l 1995: Booch und Rumbaugh veröffentlichen “Unified Method”
l 1995: Rational kauft Objectory, wo Jacobsen arbeitet.
l 1995 - 1997: Booch, Rumbaugh, Jacobsen (”drei Amigos”) erarbeiten die UML
l 1996: UML Ver 0.91 wird veröffentlicht
l 1997: Die Object Management Group (OMG) standardisiert UML Ver 1.1
l 1998: UML Ver. 1.2 wird freigegeben
l 1999: UML Ver. 1.3 wird veröffentlicht
l Nov. 2000: UML Ver. 1.4 als Betaversion veröffentlicht
l Ende 2002: Im Auftrag der OMG wird an UML 2.0 gearbeitet
l Maerz 2005: Freigabe der UML Version 2.0 durch die OMG
207
Die UML hat sich inzwischen als die Standard-Notation
der Objektorientierung durchgesetzt.
6.3 Die Unified Modeling Language (UML): Charakteristika
Zur Bedeutung des Begriffs “Unified”
l Vereinheitlichung historischer OO-Begriffe und -Notationen: Allgemein
akzeptierte Begriffsbildungen aus dem OO-Bereich zusammenführen
l Unterstützung einer durchgängigen (einheitlichen) Methodik über alle Phasen der
Systementwicklung: Nahtloser Übergang von Req. Eng. bis zur Implementierung
l Einheitliche Modellierung bei unterschiedlichen Einsatzgegebenheiten: kleine,
große, verteilte, Real-time, rechenintensive, datenintensive Systeme etc.
l Vereinheitlichung bezgl. verschiedener Programmiersprachen und
Ablaufumgebungen: Identisches Front-End bei flexiblem Back-End
l Vereinheitlichung unterschiedlicher Modellierungsperspektiven: Daten-,
Funktions-, Organisations-, Steuerungssicht; flexibel erweiterbar
Die UML als die “eierlegende Wollmilchsau”
für die konzeptionelle System-Modellierung!?
208
Was die UML ist und was sie nicht ist
l Die UML ist keine Programmiersprache.
l Die UML ist keine Methode zur Systementwicklung.
l Die UML ist/hat kein Vorgehensmodell.
N
I
E
N
l Die UML ist eine der Objektorientierung verpflichtete Technik.
JA
l Technik: Kollektion von Beschreibungsmitteln, Modellierungssprache
“UML is not intended to be a complete development method.
It does not include a step-by-step development process.”
Rumbaugh, J.; Booch, G.; Jacobsen, I.: The UML Reference Manual, Addison-Wesley 1999, S. 8.
209
Wie “funktioniert” die UML?
l Die UML stellt für die Grundelemente der Objektorientierung (siehe Abschnitt 6.2)
UML-eigene Notationselemente zur Verfügung (Klasse, Assoziationen etc.)
l Darüber hinaus verügt die UML über weitere Notationselemente, die aus den
zugrundeliegenden OO-Methoden entstanden sind und möglichst alle Aspekte
eines zu modellierenden Systems darstellen können sollen.
l Die Notationselemente (die darzustellenden Aspekte) werden (häufig) “Konzepte”
(engl.: Classifier) genannt.
l Bei der Systemmodellierung werden aus jeweils bestimmten Notationselementen
verschiedene Diagramme erzeugt (z. B. Klassen- oder Interaktionsdiagramm)
l Jedes Diagramm verdeutlicht eine bestimmte Perspektive (Sicht) auf das zu
modellierende System (z. B. Sicht des Systembenutzers, statische Sicht, Sicht
der Abläufe, Sicht der Implementierungskomponenten etc.)
Menge von
Notationselementen
Verschiedene Diagramme
Verschiedene Sichten
auf das zu mod. System
System
210
Wie “funktioniert” die Systemmodellierung mit der UML?
l Die UML legt fest, welche Diagramme aus welchen Notationselementen gebildet
werden und welche Sichten mit den Diagrammen erzeugt werden.
l Die UML liefert keinen Plan, in welcher Reihenfolge welche Diagramme erzeugt
und weiterentwickelt werden sollen, um ein System schrittweise zu modellieren.
l Es bleibt den Entwicklern überlassen, sich solche Vorgehensmodelle durch die
passende Zusammenstellung (”methodische Durchgängigkeit”) von Sichten,
Diagrammen und Konzepten zu “bauen”.
l Der Mangel an Vorschriften zur “Prozeßsicht der Systementwicklung” (siehe
Analyse
Entwurf
211
Implement.
Vorgehensmodell ?
Abschnitt 2) ist gleichzeitig ein Vorzug der UML: Sie erlaubt (fordert auf),
problemangepaßte Vorgehensmodelle zu entwickeln.
Menge von
Notationselementen
Verschiedene
Diagramme
Verschiedene
Sichten
System
Charakteristika der UML
l Die UML hat nicht die verschiedenen OO-Analyse-Entwurfs-Methoden (OOA,
OMT, OOSE etc.) zusammengeführt.
l Die UML stellt lediglich eine standardisierte objektorientierte Modellierungssprache dar, die präziser und vollständiger ist als die Sprachen, die die o. g. OOMethoden aufwiesen.
l Die UML ist eine semi-formale Technik; sie dient zur Vereinheitlichung und
Strukturierung prosaischer Formulierungen.
l Die UML verfügt über eine Vielzahl vom Diagrammarten, mit denen die
Grundelemente der OO, eine Vielzahl deren Varianten und Erweiterungen sowie
alle Phasen der Systementwicklung von der Analyse über den Entwurf bis zur
Implementierung unterstützt werden.
l Erst seit 1998 existiert mit “Rational Unified Process” ein Vorgehensmodell
(Prozeßsicht) mit explizitem Bezug zur UML.
212
6.3 Die Unified Modeling Language (UML): Sichten, Diagramme, Konzepte
Sichten, Diagrammarten und Konzepte in der UML
l Mit der UML können verschiedene Sichten auf ein (zu modellierendes) System
mit bestimmten Diagrammarten (und Notationselementen) dargestellt werden.
213
Sicht/Abstraktion
Diagrammart
Konzepte (Notationselemente)
Statische
Klassen-
Klasse, Assoziation, Attribut, Operation
Dynamische
Zustands-
Zustand, Ereignis, Transition, Aktion
Systemnutzung
Anwendungsfall-
Anwendungsfall, Akteur, Assoziation
Interaktion
SequenzKollaborations-
Interaktion, Botschaft, Aktivierung
Kollaboration, Interaktion, Botschaft
Prozeß
Aktivitäts-
Zustand, Aktivität, Transition, ....
Implementierung
Komponenten-
Komponente, Schnittstelle, Abhängigkeit
Einsatz
Einsatz-
Knoten, Komponente, Abhängigkeit
6.3 Die Unified Modeling Language (UML): Sichten, Diagramme, Konzepte
UML: Views, Diagrams, Classifier (Concepts)
l Hier die englischen Originalbegriffe; die vorgenannten deutschen Übersetzungen
werden nicht einheitlich verwendet.
214
View
Diagram
Classifier (Concepts)
Static
Class ~
Class, Association, Attribute, Operation
Dynamic
State Chart ~
State, Event, Transition, Action
User
Use Case ~
Use Case, Actor, Association
Interaction
Sequence ~
Collaboration ~
Interaction, Message, Activation
Collaboration, Interaction, Message
Process
Activity ~
State, Activity, Transition, Completion, ...
Implementation
Component ~
Component, Interface, Dependency
Deployment
Deployment ~
Node, Component, Dependency
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiele
Aufbau einer Methode mit der UML als Technik
l Zielrichtung der Methode: Entwicklung von Web Sites
l Davon abhängig: Zusammenstellung von UML-Sichten, -Diagrammarten und
-Notationselementen, die die Methode nutzt.
l Die nachfolgende Methode kombiniert Diagramme und Notationselemente zu
“Modellen”, die (ähnlich wie die Sichten) die Hauptaspekte des zu entwickelnden
Systems (Web Site) aus verschiedenen Perspektiven darstellen.
l Das “Tayloring” der vorgestellten Methode geht somit über die geschilderten
Grundzusammenhang “Sichten, Diagrammarten, Notationselemente” hinaus.
215
Die konstituierenden Elemente einer Methode:
Spezifikationsrahmen
dient einer Definition der zu modellierenden Grundaspekte des Realitätsausschnitts, die durch das dahingehend zu entwickelnde AWS zu repräsentieren
sind sowie einer Festlegung der diese Aspekte veranschaulichenden Modelle
(Aspekte = Klassifikationskriterium für Anforderungen)
Vorgehensweise
dient einer logischen und durchgängigen Erarbeitung der
im Spezifikationsrahmen definierten Modelle, zur Erreichung
einer vollständigen und widerspruchsfreien Fachlichen Detaillösung
Technik
dient einer zielgerichteten Erarbeitung der im jeweiligen Spezifikationsrahmen
definierten Modelle
216
determines
Relevant business environment
of a “web site” system
Target groups
determines
determine
Integration and transparent
presentation of areas of
responsibility and processes
determine
determine
Spezifikationsrahmen
Illustration
of tasks
Grundlegende,
kontexbestimmende
Aspekte des Systems
determines
Contextual support of
tasks and activities
Bsp.: “Web Site”
217
Elements of a web-site-oriented Method
Process Model
Specification Framework
det.
Relevant business environment
of a “web site” system
Target groups
determines
Integration and transparent
presentation of areas of
responsibility and processes
determine
+
determine
Illustration
of tasks
determines
Contextual support of
tasks and activities
218
Technique
Process Model
Step
Results
UML concept
1
Prepare application of method
Uniform domain terminology, development groups
-------
2
Requirements as regards the relevant
business web site environment
Business environment
model
Package
3
Characteristics of the web site
target groups
Participation model
Actor
4
Business requirements as regards the
links between task areas or processes
within the same business area
Integration / transparency
model
Use case
diagram
5
Business requirements as regards
the tasks or processes
Task model
Use case
6
the sequence of the tasks
Dynamic context model
Use case
step graph
7
the detailed structure of the tasks
Detailed static context
model
Detailed business class
8
the basic structure of the tasks
Approximate static
context model
Business
class
Permanent analysis of the specifications
(possible returns to previous steps)
and extensions of domain terminology
219
Tasks (describe ...)
Technique
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
Ausgangslage:
Sachziel: Erweiterung der bestehenden Web Site
eines Lehrstuhls, um Pages zum Web-basierten
Vertrieb von Schriften
1. Schritt:
Vorbereitung auf Anwendung der Methode:
1.1 Festlegung des in die Entwicklung einzubindenden
Personenkreises
1.2 Kategorisierung der ermittelten fachlichen
Anforderungen entsprechend ihrer Affinität zu den
grundlegenden fachlichen Aspekten von Web Sites und
Einrichtung einer Kategorie zur Darlegung der
die Adressaten charakterisierenden Merkmale
220
1.3 Fixierung einer Entwicklungsprozeß-konformen
Terminologie
2. Schritt:
Darstellung
der fachlich relevanten Umgebung
der zu entwickelnden eBusiness-Präsenz
Konkretisierung im:
Fachlichen Umgebungsmodell
Anhand des UML-Konzepts:
- Paket 221
222
Hier können
Erläuterungen
zu den Inhalten der Pakete aufgeführt werden.
Fachliches Umgebungsmodell
224
Verfasser
V
von
Schriften
S
fe
Pote ttieller
Potentieller
el
Besteller
t l
von
Schriften
r ft
IInteressent
s
t
von
v
n
Schriften
S
r t
Besteller
t le
von
S
Schriften
h
hrif
i en
e
Z hler
Zahler
h
von
Schriften
S h f n
Vertriebsprozeß
t ie
unterstützendes
t s t e
Anwendungssystem
Anwendu
d gssyste
s
IIn Vertriebsproze
Vertriebsproz
V rtrie
rtriebspr
rtr
p
(entgeltlich)
((ent
nt eltlich)
lt ic )
Beratungsleistungen
err tungsleistungen
ung leis u
in
iinvolvierte/-s
olvierte/-s
l i rt /- Per
Person/Anwener o
on/Anwen/An en
dungssystem
u g syst
rt
d
Vertrieb
der
f
Schriften
S hriften
ü
e
ausführender
iitarbeiter
r i r des
e
Mitarbeiter
L
r
l
Lehrstuhls
IIn Vertriebsprozeß
e ri
rie
rro e
((entgeltlich)
ntgeltli
n
g ltl h)
Schriften
c rrif
iinvolvierte/-s
olvierte/-s
v te - Pers
Person/
r n/
Anwendungssysteme
nwendu gssyste
g
e
LehrstuhlLe
L
rstuhlr t leitung
e
Entgeltlicher
Vertrieb “Schriften”
IIn Vertriebsprozeß
ertriebsprozeß
tr s r z
(entgeltlich)
((entg
g ltlic
tl )
Software
S
ftware
iinvolvierte/-s
v llvierte/-s
i r Person/AnwenPerso
r
/An
An en-dungssystem
dung
u
sy
system
Entgeltlicher
Vertrieb
Beteiligungsmodell
3. Schritt:
Darstellung der Adressaten
der zu entwickelnden eBusiness-Präsenz
Konkretisierung im:
Beteiligungsmodell
- Akteur -
223
4. Schritt:
Darstellung der Aufgabenbereiche und
Prozesse, die in der zu entwickelnden
eBusiness-Präsenz abzubildenden sind
Konkretisierung im:
Integrations-/Transparenzmodell
Anhand des
(aus dem UML-Konzept - Anwendungsfall - abgeleiteten)
UML-Konzepts:
- Anwendungsfalldiagramm 225
Integration-/Transparenzmodell
226
pB
VAS
VAS
pB
VAS
VAS
VAS
VAS
pB
VAS
VAS
VAS
...
2.3
2.3.1
2.3.2
2.3.3
2.3.4
...
pB
VAS
1.
1.1
1.2
2.
2.1
2.2
2.3
2.4
2.5
2.6
2.7
potentieller Besteller hat sich als Neubesteller identifiziert
Eingabe persönlicher Daten
Prüfung der eingegebenen persönlichen Daten auf Konsistenz
Bestellfreigabe
Ausnahme: Eingegebene persönliche Daten sind inkonsistent
...
Ausnahmen:
Bestellprozeß initialisieren
Eingabe der Bestellabsicht
Aufforderung sich als Stamm- oder Neubesteller zu identifizieren
Identifikation realisieren
Identifikation als Stamm- oder Neubesteller
Aufforderung den Namen und die Kundennummer einzugeben
Ausnahme: potentieller Besteller hat sich als Neubesteller identifiziert
Eingabe des Namens und der Kundennummer
Prüfung der eingegebenen Daten auf Konsistenz
Bestellfreigabe
Ausnahme: Eingegebene Daten sind inkonsistent
Ablauf:
Vertriebsprozeß unterstützendes
Anwendungssystem (VAS)
Beteiligte
Akteure
potentieller Besteller
(pB)
Potentieller Besteller wird als Stamm- od. Neubesteller identifiziert
Kurzbeschreibung
228
Identifikation potentieller Besteller
Aufgabenmodell
5. Schritt:
Beschreibung der Aufgaben, die in der zu
entwickelnden eBusiness-Präsenz
abzubildenden sind
Konkretisierung im:
Aufgabenmodell
- Anwendungsfall -
227
6. Schritt:
Darstellung der dynamischen Struktur der
Aufgaben, die in der zu entwickelnden
eBusiness-Präsenz abzubildenden sind
Konkretisierung im:
Dynamischen Kontextmodell
- Aktivitätsdiagramm 229
230
nicht
konsistent
Bestellfreigabe
erteilt
Bestellfreigabe
erteilen
kon sistent
Konsistenzprüfung
eingegebene
Daten
Eingabe
Name, Kd.-Nr.
Identifikation
umsetzen
Stamm
Identifikation
nicht
konsistent
Eingabe
pers. Daten
Neu
pB
Aufforderung zur
Identifikation
VAS
pB
Identifikation realisieren
Aufgabe
Dynamisches Kontextmodell
7. Schritt:
Darstellung der wesentlichen Elemente der
statischen Struktur der Aufgaben, die
in der zu entwickelnden eBusiness-Präsenz
abzubildenden sind
Konkretisierung im:
Groben statischen Kontextmodell
Anhand des
(aus dem UML-Konzept - Klasse - abgeleiteten)
UML-Konzepts:
- Geschäftsklasse 231
Statisches Kontextmodell
Web-Site-Geschäftsklasse
Potentieller Besteller
Aufgabe Identifikation realisieren
1
ver anlaßt
1
Identifikation
1
führt zu
*
232
Bestellung
8. Schritt:
Darstellung der Detailelemente der statischen Struktur der
Aufgaben, die in der zu entwickelnden eBusiness-Präsenz
abzubildenden sind
z. B. Geschäftsklasse „Bestellung“ wird in Fachklassen
„Adresse“, „Bestellposition“, „ Zahlungsweise“ zerlegt.
Konkretisierung im:
Detaillierten statischen Kontextmodell
Anhand des (aus dem UML-Konzept - Klasse - abgeleiteten)
UML-Konzepts:
- Fachklasse 233
An Example of the UML-based Method
Extending a University´s Web Site with an Application
for web-based Allocation of teaching Facilities
1st Step „Prepare“:
define Development Groups,
uniform Terminology
Go to Step 2 ...
234
Step 2: Business Environment Model
235
Step 3: Participation Model (Target groups)
236
office for allocation of
teaching facilities
- available search result
- or a preliminary reservation is made
- final reservation
- or a preliminary reservation is made
- or the reservation is cancelled
(.....)
“pre-”
conditions
“post-”
conditions
long
description
registered customer
to reserve a facilityin line with the
customers request and existing reservations
actors
short
description
238
to reserve a facility
Step 5: Task Model
Step 4: Integration / Transparency Model
237
[prelim. reservation]
Step 6: Dynamic Context Model (graphic)
239
Step 7: Detailed Static Context Model
240
Step 8: Approximate Static Context Model
<< web-site-business-class >>
customer
1
carries out
*
event
1
is the basis for
1
reservation
241
Process Model
Step
Results
UML concept
1
Prepare application of method
Uniform domain terminology, development groups
-------
2
Requirements as regards the relevant
business web site environment
Business environment
model
Package
3
Characteristics of the web site
target groups
Participation model
Actor
4
Business requirements as regards the
links between task areas or processes
within the same business area
Integration / transparency
model
Use case
diagram
5
the tasks or processes
Task model
Use case
6
the sequence of the tasks
Dynamic context model
Use case
step graph
7
the detailed structure of the tasks
Detailed static context
model
Detailed business class
8
the basic structure of the tasks
Approximate static
context model
Business
class
Permanent analysis of the specifications
(possible returns to previous steps)
and extensions of domain terminology
242
Tasks (describe ...)
Technique
Gliederung
243
ARIS Rahmenkonzept
eEPK
© IDS SCHEER AG
Unternehmen
Personal
Marketing ProdukEntwicklung Vertrieb
tion
Auftragsabwicklung
Produktentwicklung
KundenService
Personal
Abb. 86: Übergang von der Funktions- zur Prozeßorientierung
EntMarketing
wicklung Vertrieb Produktion
Kundenanfrage
technische
Zeichnungen
Kundenanfrage
ungeprüft
Kundenanfrage technisch
prüfen
technischer
Vertrieb
Lagerbestand
technischer
Bericht
Kundenanfrage
Kostenschätzung
Kundenanfrage
techn. i.O.
Kundenafrage
kaufmännisch
prüfen
Kundendaten
kaufmännischer
Vertrieb
technischer
Bericht
Produktkalkulation
Kundenanfrage
kfm. i.O.
Kundenbonität
prüfen
Produktverfügbarkeit
prüfen
Disposition
Lagerauskunft
Produktkalkulation
Kundenanfrage
Kundenanfrage
Kundenbonität
gegeben
Bonitätsauskunft
Produktverfügbarkeit
gegeben
Kundenanfrage
bestätigen
Lagerauskunft
Buchhaltung
Kundenauftrag
Bonitätsauskunft
Abb. 88: EPK für den Geschäftsprozess “Kundenauftragsbearbeitung”
Kundenanfrage
bestätigt
kaufmännischer
Vertrieb
Selected BPR Tool Vendors
Challengers
Leaders
IDS Prof. Scheer
Oracle
ICL
Popkin
IBM
Ability
to
Execute
Rational
Sterling Software
Logic Works
Meta Software
Wizdom Systems
Visio
Lanner Group
KBSI Promodel
Micrografx
CACI Software
ABC Technologies
Aonix
Systems Modeling
Holosofx
IntelliCorp
CASEwiseInterfacing Technologies
NEC
Action Technologies
UBIS
Gensym
Ptech
Mosaix
Hitachi SE
Imagine That
Scitor
Mega Intl.
High Performance Sys.
Proforma
Powersim
Software AG
Refocused/Niche Players
Visionaries
As of 8/97
Completeness of Vision
Source: Gartner Group
Abb. 78: Modellierungstools
Geschäftsprozeßkomponenten
Ereignisse lösen Funktionen aus
Funktionen generieren Ereignisse
Kundenauftrag
erhalten
Bestätigen
des Kundenauftrags
erstellt
Ereignis
Funktion
Ereignis
© IDS SCHEER AG
Auftragsverfolgung
Rückmeldung
erhalten
Funktion
Ereignis
Produktionsplan
Produktionsplan
erstellt
Funktion
Ereignis
Daten werden in Funktionen verarbeitet
Daten
Produktionsdaten
Daten
Kundendaten
Auftragsverfolgung
Rückmeldung
erhalten
Daten
Kundenauftrag
erhalten
Bestätigen
des Kundenauftrags
erstellt
Ressourcen
Produktionsplan
© IDS SCHEER AG
Produktionsplan
erstellt
Mitarbeiter sind verantwortlich für Funktionen
Mitarbeiter
Frau Müller
Kundendaten
Kundenauftrag
erhalten
Bestätigen
des Kundenauftrags
Produktionsdaten
Auftragsverfolgung
erstellt
Ressourcen
Produktionsplan
Herr Schmidt
Mitarbeiter
Mitarbeiter
© IDS SCHEER AG
Rückmeldung
erhalten
Herr Meyer
Produktionsplan
erstellt
Mitarbeiter gehören zu Organisationseinheiten
Organisationseinheit
Produktion
Frau Müller
Kundendaten
Kundenauftrag
erhalten
Vertrieb
Bestätigen
des Kundenauftrags
Produktionsdaten
Auftragsverfolgung
erstellt
Ressourcen
Produktionsplan
Herr Schmidt
© IDS SCHEER AG
Rückmeldung
erhalten
Produktionsplanung
Herr Meyer
Produktionsplan
erstellt
Funktionen erzeugen und verarbeiten Leistungen
Produktion
Leistung
Kundenbestellung
Frau Müller
Leistung
Produktionsdaten
Kundenauftrag
Auftragsverfolgung
Rückmeldung
erhalten
Leistung
Kundendaten
Kundenauftragsbestätigung
Leistung
Kundenauftrag
erhalten
Vertrieb
Bestätigen
des Kundenauftrags
erstellt
Herr Schmidt
Produktionsplanung
© IDS SCHEER AG
Ressourcen
Produktionsplan
Produktionsplan
Produktionsplan
erstellt
Herr Meyer
Komplexitätsreduzierung durch Sichtenbildung
Datensicht
Umfelddaten
Ereignis
Funktion
Ereignis
Funktion
Funktionssicht
Org. Einheit
Mitarbeiter
Organisationssicht
© IDS SCHEER AG
Leistung
Leistungssicht
ARIS - Sichten
4 Datensicht
Welche Informationen sind wichtig?
(z. B.: Kunde, Lieferant, Produkt, Materialrechnungen)
4 Funktionssicht
Welche Funktionen werden ausgeführt?
(z. B.: Produktionsplanerstellung, Auftragsbearbeitung)
Organisationssicht
4 Organisationssicht
Welche Organisationseinheiten gibt es?
(z. B.: Einkauf, Vertrieb, Finanzbuchhaltung)
4 Steuerungssicht
Beziehung zwischen Daten, Funktionen
und Organisationseinheiten
4 Leistungssicht
Welche Leistungen sind wichtig?
(z. B.: geprüfter Auftrag, Kundenzahlung)
© IDS SCHEER AG
DatenDatensicht
SteuerungsSteuerungssicht
Leistungssicht
FunktionsFunktionssicht
ARIS - Sichten
Organisationssicht
Datensicht
Steuerungssicht
Leistungssicht
© IDS SCHEER AG
Funktionssicht
Phasenkonzept
Problem
Fachkonzept
DV-Konzept
Implementierung
Informationstechnik
© IDS SCHEER AG
ARIS - Beschreibungsebenen
4Fachkonzept
Standardisierte fachliche Beschreibung der Unternehmenskonzepte
4DV-Konzept
Übernahme der fachlichen Anforderungen
in die Beschreibungssprache der DV-Technik
4Implementierung
Beschreibung der konkreten Hardund Softwarekomponenten, die für
die Umsetzung des Unternehmenskonzeptes verwendet werden
© IDS SCHEER AG
Architektur integrierter Informationssysteme
© IDS SCHEER AG
Methodenintegration
Geschäftsleitung
Materialwirtschaft
Disposition
Vertrieb
Einkauf
Anfrage ist
eingegangen
Angebot
Anfrage
Anfrage
Vertriebsabwicklung
Anfragebearbeitung
Vertrieb
Anfrage ist
bearbeitet
Kunde
Kundenangebot
Kundenanfrage
© IDS SCHEER AG
Kundenangebot
Anfrage- Angebotsbearbeitung bearbeitung
Bonität
prüfen
Angebotsbearbeitung
Kundenauftrag
Liefertermin
ermitteln
Strategische Geschäftsprozeßanalyse und Sollkonzeption
Fachkonzept
DV - Konzept
Or
ga
nis
atio
n
ARIS-Haus
Implementierung
Fachkonzept
Fachkonzept
Fachkonzept
DV - Konzept
DV - Konzept
DV - Konzept
Implementierung
Implementierung
Implementierung
Daten
Steuerung
Fachkonzept
DV - Konzept
Implementierung
Leistung
Informations- und
Kommunikationstechnik
Abb. 17: ARIS-Haus mit Phasenkonzept
Funktion
Projektstart
Fachkonzept
Steuerungssicht (EPK)
Fachkonzept
Steuerungssicht beendet
Fachkonzept
Funktionssicht
erstellen
Fachkonzept
Organisationssicht erstellen
Fachkonzept
Datensicht
erstellen
Fachkonzept
Leistungssicht
erstellen
Fachkonzepte abgeschlossen
DV-Konzept
Funktionssicht
erstellen
DV-Konzept
Organisationssicht erstellen
DV-Konzept
Datensicht
erstellen
DV-Konzept
Leistungssicht
erstellen
DV-Konzept
Steuerungssicht erstellen
Impl.
Leistungssicht
Impl.
Steuerungssicht
DV-Konzepte
abgeschlossen
Implementierung
Funktionssicht
Impl.
Organisationssicht
Impl.
Datensicht
Projekt abgeschlossen
Abb. 21: EPK des groben ARIS-Vorgehensmodells
Was ist ARIS?
4ARIS = Architektur Integrierter Informationssysteme
4Rahmenkonzept zur Beschreibung von Unternehmen und
Anwendungssoftware
4Entwickelt von Prof. Dr. A.-W. Scheer
4Verwendet StandardModellierungsmethoden
4Konzentriert auf den
Geschäftsprozeß
4Effektiv in allen Umgebungen:
Unabhängig von der Anzahl der
Abteilungen, der Unternehmensgröße oder der vorhandenen
Software
© IDS SCHEER AG

Modellierung von IuK-Systemen

Transcription

Similar documents

LEHÁR FESTIVAL BAD ISCHL 12. Juli bis 31. August 2008

PDF-Version - am Institut für Baustatik

Pharmareport 2012-01 vom 27.02.12

Datenmodellierung und Datenbanktechnik

- PAUL KUHN

PDF-Vorlage zum Ausdrucken - Advent

Konfigurationsmanagement komponentenorientierter betrieblicher

Traditionelle „strukturierte“ Spezifikationsmethoden

25 Jahre ars electronica

Volltanken mit FiDEs

3D-Modelle noch realistischer rendern

iPod nano Benutzerhandbuch

Datenbankanfragen und -operationen mittels SQL

Informix Warehouse – neue Möglichkeiten der Informationsanalyse

Berater-Profil 3305

Relationales Datenmodell

Activity Diagram

Datenbanksysteme