JUSTUS-LIEBIG-UNIVERSITÄT GIESSEN
ALLG. BWL UND WIRTSCHAFTSINFORMATIK
UNIV.-PROF. DR. AXEL C. SCHWICKERT
Scriptum zur Vorlesung im Master-Modul
Systems Engineering
Wintersemester 09/10
Univ.-Prof. Dr. Axel C. Schwickert
JLU Gießen – Vorlesung „Systems Engineering“ – Master – WS 09/10
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 WBT-Serie zur Geschäftsprozeßmodellierung mit ARIS
JLU Gießen – Vorlesung „Systems Engineering“ – Master – WS 09/10
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)
Systems Engineering – WS 09/10 – Prof. Dr. Axel C. Schwickert
Systems Engineering
Vorlesung zur Wirtschaftsinformatik
y g g
Justus-Liebig-Universität Gießen
Wintersemester 09/10
Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 1
Prof. Dr. Axel C. Schwickert
Master: 02-BWL: MA-B9-01 Master-Modul besteht aus:2 SWS Vorlesung Systems Engineering2 SWS Übung: IT-Sicherheitsmanagement (Falk)
Systems Engineering: Organisatorisches
Diplom: 2 SWS Vorlesung, Tiefenfach Wirtschaftsinformatik
Prüfung: Diplom: 90 Min. Klausur = 3 CP / Stoff: VorlesungMaster: 90 Min. Klausur Vorl./Üb + Projekt-Präs. Üb.
Scriptum: http://wi.uni-giessen.de/ Download-Center / SPIC
Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 2
Dozent: Univ.-Prof. Dr. Axel C. SchwickertProfessur für BWL und WIJustus-Liebig-Universität GießeneMail: [email protected]
Systems Engineering – WS 09/10 – Prof. Dr. Axel C. Schwickert
1. Donnerstag, 15. Oktober 20092. Donnerstag, 22. Oktober 20093. Donnerstag, 29. Oktober 20094. Donnerstag, 05. November 20095 Donnerstag 12 November 2009
VL-Termin:Vorlesung
Systems Engineering: Organisatorisches
5. Donnerstag, 12. November 20096. Donnerstag, 19. November 2009 WBT 1 statt Vorles.7. Donnerstag, 26. November 2009 WBT 2 statt Vorles.8. Donnerstag, 03. Dezember 2009 WBT 3 statt Vorles.9. Donnerstag, 10. Dezember 2009 WBT 4 statt Vorles.10. Donnerstag, 17. Dezember 2009 WBT 5 statt Vorles.
Donnerstag, 24. Dezember 2009 FerienDonnerstag, 31. Dezember 2009 Ferien
gDonnerstags,10.15 Uhrbis 11.45 Uhr
VL-Ort:Vorlesung imRaum 031 (HS 031)
Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 3
Donnerstag, 07. Januar 2010 Ferien12. Donnerstag, 14. Januar 2010 Ferien13. Donnerstag, 21. Januar 201014. Donnerstag, 28. Januar 201015. Donnerstag, 04. Februar 2010
Klausur: Spätestens 2 Wochen nach Ende der Vorlesungszeit
Kontakt: eMail: Axel. [email protected] Sprechzeit nach den VorlesungenO S
Systems Engineering: Organisatorisches
Oder Sprechzeit nach Vereinbarung
Infos: http://wi.uni-giessen.de oder SPIC
Über die Web Site erhalten Sie aktuelleInformationen und per Download alle Skripten zu allen Lehrveranstaltungen
Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 4
Skripten zu allen Lehrveranstaltungen.
Papieraushänge und gedruckte Skripten nur in (angekündigten) Ausnahmefällen !
Systems Engineering – WS 09/10 – Prof. Dr. Axel C. Schwickert
Systems Engineering: Organisatorisches
Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 5
http://wi.uni-giessen.de
Systems Engineering: Organisatorisches
Abonnieren !
Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 6
Systems Engineering – WS 09/10 – Prof. Dr. Axel C. Schwickert
Systems Engineering: Organisatorisches
Infos zu Vorlesungen und Übungen
Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 7
Systems Engineering: Organisatorisches
• Downloads• Bookmarks• Forum• Evaluation• WBT
Click !
Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 8
Systems Engineering – WS 09/10 – Prof. Dr. Axel C. Schwickert
Literatur zur Vorlesung
Balzert, Helmut: Lehrbuch der Soft-ware-Technik – Band 1: Software-Ent-wicklung. 2. Aufl., Heidelberg, Berlin: Spektrum Akademischer Verlag 2000.
Gadatsch, Andreas: Management von Geschäftsprozessen. 2. Aufl., Braunschweig/Wiesbaden:Viehweg 2002.
Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 9
Empfohlene Zeitschriften
Das Wirtschaftsstudium – WISUAllgemein sehr förderlich für Studierendeder Wirtschaftswissenschaften
c´t: Technik! Wirtschaftsinformatik
Pflicht für Studierendeder Wirtschaftsinformatik
Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 10
IT-ZeitungenWöchentlich!
1
Vorlesung im Master und zum Wahlfach Wirtschaftsinformatik
Systems Engineering - Modellierung von IuK-Systemen
Prof. Dr. Axel C. Schwickert
Wintersemester 09/10
2
Gliederung
Systems Engineering - Modellierung von IuK-Systemen
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
Wirtschaftsinformatik - Wintersemester 09/10
3
1.1 Gegenstand, Charakter, Ziele der Wirtschaftsinformatik
Gegenstand der WI: IuK-Systeme in Wirtschaft und Verwaltung
Handhabung der Komplexität von IuK-Systemen
�
�
�
IKS sind sozio-technische Systeme
Befriedigung der Informationsnachfrage zur Erfüllung von Aufgabenin Wirtschaft und Verwaltung
Koordination arbeitsteilig wirkender Aufgabenträger
�
�
�
Komponenten von IKS
Arten von IKS unterscheiden
isolieren, untersuchen, integrieren
Komponenten von IKS: Funktionen, Daten, Objekte, Schnittstellen
durch Fokussierung auf Unternehmen,Arbeitsgruppen, Einzelpersonen, Branchen, betriebliche Funktionen,unternehmensübergreifende Funktionen.
4
Wissenschaftstheoretischer Charakter der Wirtschaftsinformatik
Ziele und methodischer Ansatz der Wirtschaftsinformatik
�
�
�
Realwissenschaft:
Formalwissenschaft:
Ingenieurwissenschaft:
Untersuchungsgegenstand sind Phänomene der Wirklichkeit
Beschreibung, Erklärung, Prognose und Gestaltungder IKS bedürfen der Entwicklung und Anwendung formalerBeschreibungsverfahren und Theorien
Die Gestaltung von IKS verlangt nach einerKonstruktionssystematik
�
�
Erkenntnisziel der WI:
Praxiskontakte
Gewinnung von Theorien, Methoden und Werkzeugenzur Beschreibung und Erklärung von IKS, zur Prognose des Systemverhaltensund zur Gestaltung “besserer” Systeme
zur Gewinnung und Validierung von Erkenntnissen über IKSsind unverzichtbar (empirisch, induktiv, realistisch).
1.1 Gegenstand, Charakter, Ziele der Wirtschaftsinformatik
5
1.2 Zur Bedeutung von Modellen und Modellierungsansätzen
Komplexe Landschaft von IKS im Unternehmen
Verschiedene Sichten (Perspektiven) auf IKS
- System-Umwelt und ihre Beziehungsstruktur erkennen
- Systeme, ihre Bestandteile und ihr Funktionieren verstehen
- Komplexität beherrschbar machen
Modelle:
�
�
Vielzahl von IKS
Integration der IKS
für verschiedene Funktionalbereiche (z. B. Beschaffung,Produktion, Absatz, Rechnungswesen) oder Verwendungszwecke (Planung,Steuerung, Kontrolle, Leistungserbringung) im Unternehmen
in der Regel erforderlich
�
�
�
�
Entwickler:
Organisatoren:
Management:
Benutzer:
Modelle, Methoden, Werkzeuge, Programmierung
Aufgaben, Abläufe, Aufgabenträger, Anforderungen
Planung, Steuerung, Kontrolle von IKS-Entwicklung und -Nutzung
Aufgabenerfüllung, Anforderungen, Oberflächen, Verhalten, Bedienung
6
1.2 Zur Bedeutung von Modellen und Modellierungsansätzen
Ergebnissicht: Was ist zu modellieren?
Ergebnissicht: Anforderungen an das Modellieren
�
�
Modell: Eine idealisierte, vereinfachte in gewisser Hinsicht ähnliche Darstellungeines Gegenstands, Systems oder sonstigen Weltausschnitts mit dem Ziel,daran bestimmte Eigenschaften des Vorbilds besser analysieren zu können(Balzert, S. 100)
Wie das Modell eines IKS erstellt wird und wie es aussieht, hängt vomEntwicklungsparadigma, dem Verwendungszweck des Modells und häufig auchvom Anwendungsbereich des zu modellierenden IKS ab.
�
�
�
Nutzen:
Verständlichkeit:
Standardisierung:
Zweckgerichtet umfassende und genaue Abbildung desVorbilds erforderlich
Die Modelldarstellung muß der zweckgerichteten Verwendungdes Modells (z. B. System-Analyse, -Optimierung, -Modifikation) förderlich sein.
Die Festlegung auf ein Set von Modellierungskonventionenfördert Vergleichbarkeit, Erlernbarkeit, Verständlichkeit.
7
1.3 Anvisierte Lernziele
Lernziele: Sie sollten wissen, .....
�
�
�
�
�
�
..... welche Ansätze und Prinzipien für die Modellierung vonbetrieblichen IKS zur Verfügung stehen,
..... wie IKS modelliert werden,
..... wie IKS mit SA, SADT modelliert werden,
..... wie IKS per ERM modelliert werden,
..... wie IKS mit ARIS und EPKs modelliert werden,
..... wie IKS mit der UML modelliert werden.
funktionsorientiert
datenflußorientiert
datenorientiert
objektorientiert
prozeßorientiert
8
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
Gliederung
Systems Engineering - Modellierung von IuK-Systemen
Wirtschaftsinformatik - Wintersemester 09/10
9
2.1 Prozeß- und Systemgestaltung
Zwei Sichten der Planung von (Organisations-) Systemen
Prozeßsicht der IKS-Planung, -Entwicklung
Ergebnissicht der IKS-Planung, -Entwicklung
�
�
Ergebnissicht:
Prozeßsicht:
Das “Was” der Planung - die Systemgestaltung
Die Vorgehensweise der Planung - die Prozeßgestaltung
�
�
Vorgehensmodelle:
Methodische Durchgängigkeit:
Wie z. B. sequentielle Phasenmodelle, evolutionäreSpiralmodelle, Prototyping-Modelle (RAD) etc.
Die einzelnen Prozeßschritte werden durchaufeinander abgestimmte Analyse- und Darstellungstechniken unterstützt (z. B.durch ein Bündel von UML-Konzepten).
�
�
Modellierungsansätze:
Prinzipien:
Wie z. B. funktions-, datenfluß-, daten-, prozeß- oderobjektorientierte Modellierung
Grundlagen der Systemtheorie, Abstraktion, hierarchischeStrukturierung, schrittweise Verfeinerung, Modularisierung
10
2.1 Prozeß- und Systemgestaltung
Prozeßsicht: Gliederung von Software-Entwicklungsprojekten
Prozeßsicht: Vorgehensmodelle zur Entwicklung von IKS
�
�
Für die sachliche und zeitliche Gliederung von SWE-Projekten gibt es eine Füllevon Vorschlägen, deren gemeinsamer Nenner ein allgemeines gestuftesVorgehen ist.
Siehe dazu nachfolgend das “Allgemeine Vorgehensmodell” und seine“Wasserfallstruktur”.
�
�
�
�
�
Es lassen sich folgende Grundformen unterscheiden:
Sequentielle Vorgehensmodelle
Parallel-sequentielle Vorgehensmodelle
Evolutionäre Vorgehensmodelle
Agile Vorgehensmodelle
11
2.1 Prozeß- und Systemgestaltung: Allgemeines Vorgehensmodell
Pro
jekt
an
sto
ß
Vo
rpro
jekt
Sys
tem
ba
u
Sys
tem
üb
erg
ab
e
Sys
tem
nu
tzu
ng
Ha
up
tpro
jekt
De
tailp
roje
kt
Sys
tem
ein
füh
run
g
Projektplanung Projekt-realisierung
Projekt-kontrolle
Projektmanagement
12
2.1 Prozeß- und Systemgestaltung: Allg. VG-Modell - Wasserfallstruktur
1. Schritt
3. Schritt
2. Schritt
4. Schritt
5. Schritt
Vorprojekt
Detailprojekt
Systembau,Systemeinführung und -übergabe
Systemnutzung
Hauptprojekt
13
2.1 Prozeß- und Systemgestaltung: Allg. VG-Modell - Phasen
Phasen derSystementwicklung
(allgemein)
(Stahlknecht 2002)
Phasenbezeichnung Phaseninhalt
Vorphase
Analyse
Entwurf
Realisierung
Einführung
Projektbegründung
Istanalyse- Erhebung des Istzustands- Bewertung des Istzustands
Sollkonzept- Fachentwurf- IV-Grobentwurf- Wirtschaftlichkeitsvergleiche
SystementwurfProgrammspezifikationProgrammentwurf
ProgrammierungTest
SystemfreigabeSystemeinführung
14
2.1 Prozeß- und Systemgestalt.: Allg. VG-Mod. - Phasen, Aktivitäten, Ergebnisse
Ph
as
en
un
dA
kti
vit
äte
nE
rge
bn
iss
e
Pro
jekta
nsto
ß
· · ·
Pro
jekt
auftra
gfo
rmulie
ren
Pro
jekt
org
anis
atio
nsf
orm
wähle
nP
roje
ktprioritä
tbest
imm
en
· · · ·
Zie
lsetz
ung
übera
rbeite
nG
esa
mtk
onze
pt
(evt
l.m
itV
ariante
n)
era
rbeite
nW
irts
chaftlic
hke
itüberp
rüfe
nP
lanung
akt
ualis
iere
n
· · · · · · · ·
Pro
ble
mst
ellu
ng
überp
rüfe
nU
nte
rsuch
ungsb
ere
ich
abgre
nze
nS
ituatio
nsa
naly
se/S
tandort
best
imm
ung
vorn
ehm
en
Gest
altu
ngsm
öglic
hke
iten
abkl
äre
nZ
iele
era
rbeite
nL
ösu
ng
sprin
zip
ien
era
rbeite
ners
teW
irts
chaftlic
hke
its-
und
Nutz
enüberlegungen
anst
elle
nP
roje
ktpla
nung
ers
telle
n(w
eite
reV
org
ehen
pla
nen)
· · ·
Pro
ble
m,Id
ee
Pro
jekt
würd
igke
itP
roje
ktauftra
g
· ·L
ösu
ng
sprin
zip
ien
Vorg
ehensk
onze
pt
·G
esa
mtk
onze
pt,
Mast
erp
lan
·D
eta
ilplä
ne
Vo
rpro
jekt
Hau
ptp
roje
kt
Deta
ilp
roje
kt
· · · ·
realis
ieru
ngsr
eife
Lösu
ngen
ausa
rbeite
ndeta
illie
rte
Wirts
chaftlic
hke
itsre
chnung
ers
telle
nU
nte
rhalts
org
anis
atio
npla
nen
Sch
ulu
ngs-
und
Ein
führu
ngsk
onze
pt
ers
telle
n
Syste
mb
au
· · ·
Sys
tem
bauen
(Lösu
ngen
benutz
ungsr
eif
mach
en)
Sys
tem
test
en,abnehm
en
Kost
en
und
Wirts
chaftlic
hke
itüberp
rüfe
n·
ein
führu
ngsb
ere
ites
Sys
tem
Syste
mein
füh
run
g
· ·S
chulu
ng
Unte
rhalts
org
anis
atio
naufs
telle
n·
ein
gefü
hrt
es
Sys
tem
15
2.1 Prozeß- und Systemgestalt.: Allg. VG-Mod. - Phasen, Aktivitäten, Ergebnisse
Vorphase
Phase Analyse
Phase Entwurf
Phase Realisierung
Phase Einführung
Projekt-begründung
Istanalyse
Sollkonzept
Systementwurf
Programmentwurf
Programmierungund Test
Anpassung derStandardsoftware
Auswahl undAnschaffung vonStandardsoftware
System-einführung
Eigen-entwicklung Fremdbezug
Vorghehensmodell derSystementwicklung
(allgemein)
(Stahlknecht 2002)
16
2.1 Prozeß- und Systemgestaltung: Sequentielles VG-Modell “Wasserfallmodell”
Entw
ickl
ungse
benen
Situations-studie
Fach-konzeption
System-konzeption
System-entwicklung
System-installation
Zeit
Meilen-stein
1
Situations-studie
Validierung
Meilen-stein
2
Fachkon-zeption
Validierung
Meilen-stein
3
System-konzep-tion
Validierung
Meilen-stein
4
System-entwick-lung
Validierung
Meilen-stein
5
System-installa-tion
Validierung
17
2.1 Prozeß- und Systemgestaltung: Sequentielle Vorgehensmodelle
Sequentielle Vorgehensmodelle: Merkmale
Sequentielle Vorgehensmodelle: Eignung
�
�
�
�
�
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
�
�
�
�
Anforderungen an zu entwickelndes IKS liegen präzise vor
Wenig komplexe IKS
IKS mit relativ stabilem Projektumfeld
IKS, die relativ wenig Arbeitsteilung erforden
18
2.1 Prozeß- und Systemgestaltung: Parallel-sequent. VG-Modell “V-Modell”
Sy
ste
m-
An
ford
eru
ng
s-
an
aly
se
un
d-E
ntw
urf
SW
E1
DV
-A
nfo
rde
run
gs
-a
na
lys
eu
nd
-En
twu
rf
SW
E2
SW
-A
nfo
rde
run
gs
-a
na
lys
e
SW
E3
Gro
b-
en
twu
rf
SW
E4
Fe
in-
en
twu
rf
SW
E5
Imp
lem
en
tie
run
g
SW
E6
Sy
ste
m-
Inte
gra
tio
n
SW
E9
DV
-In
teg
rati
on
SW
E8
SW
-In
teg
rati
on
SW
E7
SW
KE
-In
tegra
tion
Kom
po-
nente
n-
Inte
gra
tion
Sys
tem
an
ford
eru
ng
en
Sys
tem
arc
hite
ktu
rS
yste
min
teg
ratio
nsp
lan
DV
-An
ford
eru
ng
en
DV
-Arc
hite
ktu
rD
V-I
nte
gra
tion
spla
n
SW
-Arc
hite
ktu
rS
chn
ittst
elle
ne
ntw
urf
SW
KE
-In
teg
ratio
nsp
lan
Da
ten
kata
log
SW
-En
twu
rf
SW
-An
ford
eru
ng
en
Legende: P
rüf-
akt
ivitä
t(Q
S)
SW
E-A
ktiv
ität
19
2.1 Prozeß- und Systemgestaltung: Parallel-sequentielle Vorgehensmodelle
Parallel-sequentielle Vorgehensmodelle: Merkmale
Parallel-sequentielle Vorgehensmodelle: Eignung
�
�
�
�
Ü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)
�
�
�
�
�
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
20
2.1 Prozeß- und Systemgestaltung: Evolutionäres VG-Modell - Grundstruktur
System-installation
System-realisierung
System-konzeption
Fach-konzeption
Situations-studie E
R
V1
ER
V2
ER
V3
ER
V4
ER
V5
Phasen
Zeit
Legende:
ERV
===
EntwickelnRealisierenValidieren
21
2.1 Prozeß- und Systemgestaltung: Evolutionäres VG-Modell “Sprialmodell”
Risiko-analyse
Risiko-analyse
Risiko-analyse
Risiko-analyse
Vorgehens-konzept
Anforde-rungen
Validierungder Anforde-rungen
Entwick-lungsplan
Validierung desEntwurfs
Installa-tion
Akzeptanz-test
Integra-tion undTest
Modul-test
Codie-rung
Reali-sierung
Entwurf
Ziele,Alternativen,Randbedingungenfestlegen
KumulierteKosten
schrittweisesVorgehen Alternativen und
Risiken bewerten,Prototypen entwickeln
Prototyp 1
Prototyp
2
Prototyp
3
Prototyp
4
Integrationund Testplan
22
2.1 Prozeß- und Systemgestaltung: Evolutionäre Vorgehensmodelle
Evolutionäre Vorgehensmodelle: Merkmale
Evolutionäre Vorgehensmodelle: Eignung
�
�
�
�
Weitgehender Verzicht auf Sequentialisierung und vordefinierteZwischenergebnisse
Zwischenresultate werden durch “systematisches Probieren” in zyklisch gestufterAbfolge von Entwerfen, Realisieren und Validieren erzeugt.
Grundlage “Prototyping”: explorativ, experimentell, evolutionär
Spiralmodell (Böhm): inkrementell-iteratives Vorgehen
�
�
�
�
Innovative, komplexe IKS
Im voraus schwierig zu strukturierende IKS
Rapid Application Development
Nachteil: Meilenstein-Zäsuren verschwimmen
22a
2.1 Prozeß- und Systemgestaltung: Agile Vorgehensmodelle
22b
2.1 Prozeß- und Systemgestaltung: Agile Vorgehensmodelle
22c
2.1 Prozeß- und Systemgestaltung: Agile Vorgehensmodelle
Agile Vorgehensmodelle: Merkmale
Agile Vorgehensmodelle: Eignung
�
�
�
�
�
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
ö
-
ä
�
�
�
�
�
Innovative IKS mit hoher Unsicherheit
Umwelt, System, Anforderungen offen
Kleine IuK Systeme
Kleine Teams
Nachteil: Funktioniert nur mit
-
“Helden”
22d
2.1 Prozeß- und Systemgestaltung: Agile Vorgehensmodelle
23
2.2 Systemtheoretische Grundlagen
Gegenstand der allgemeinen Systemtheorie
Hauptaspekte der Analyse und Gestaltung von Systemen
Zum Begriff “System”
�
�
Anordnung von Elementen zu einem System und die Analyse der Beziehungenzwischen den Elementen
Begründer: Ludwig von Bertalanffy, 1951
�
�
Wirkungsaspekte, Strukturaspekte
Abstraktion, Dekomposition
�
�
�
Ein System wird durch eine abgegrenzte und geordnete Menge von Elementengebildet, die untereinander in Beziehung stehen.
Das System bildet als Ganzes eine Einheit und läßt sich deutlich von seinerUmwelt abgrenzen.
System-Emergenz: Das Ganze ist mehr als die Summe seiner Teile.
24
System
als
Blackbox
Umweltbeziehungen
Umweltelement
Umweltelement
Umweltelement
Systemgrenze
Systemabgrenzung und Wirkungsanalyse
2.2 Systemtheoretische Grundlagen
25
Umweltbeziehungen
Umweltelement
Umweltelement
Umweltelement
SystemgrenzeSystem
Strukturanalyse
2.2 Systemtheoretische Grundlagen
26
Subsystem Subsystem
.....
Gesamtsystem ProblemnaheEbene
Transformationsebene(n)
Schnittstelle
Schnittstelle
Teilaufgabe
Logische Komponente: suche, lies, schreibe ...
Teilaufgabe
Maschinennahe Ebene
Abstraktionund
schrittweiseVerfeinerung
2.2 Systemtheoretische Grundlagen
�
�
�
Hauptsachverhalte
Vom Allgemeinenzum Speziellen
Top-down,hierarchisch
27
Sub
sys.
1
Sub
sys.
2
Sub
sys.
3
Mod
uln
Mod
uln
Gesamtsystem
Ebene 1
Input Output
GeordneteSammlungvon Moduln
Ebene 2
Ebene 3
2.2 Systemtheoretische Grundlagen
Blockkonzept,Modularisierung
�
�
VollständigeSchachtelung
Logische Komp. =Bausteine, Moduln
Modul-Abgrenzung
Interne Struktur und funktionale Einheit
Modul
Input Output
Kontext und Schnittstellen
Modul
Black Box
Input Output1
2
1
2
1
2
1
2
Umsystem Umsystem
28
2.2 Systemtheoretische Grundlagen
Blockkonzept,Modularisierung
�
�
Mehrfach verwend-bare Moduln mitdefinierten Schnitt-stellen
Keine Nebeneffektebei Modul-Änderung/-Austausch
Unter-Modul
Sequenz
Selektion
Iteration
A
B
A B
A
Kein Spaghetti Junction Design !
29
2.2 Systemtheoretische Grundlagen
Blockkonzept,Modularisierung
�
�
�
Beschränkung derStrukturblockarten
StandardisierteAblaufabbildungen
BeherrschbareDynamik
- - - - - - - -- -- - - - - - - -- -
- - - - - - - -- -- - - - - - - -- -
- - - - - - - -- -- - - - - - - -- -
- - - - - - - -- -- - - - - - - -- -
- - - - - - - -- -- - - - - - - -- -
- - - - - - - -- -- - - - - - - -- -
Par 1
Par 2
Par 3
Par 4
Par 5
Par 6
Einga
ng
Ausgang
30
2.3 Graphen und Petri-Netze
Graphentheorie
Zum Begriff “Graph”
Graph Gerichteter Graph
�
�
Formale Theorie, die Vorgänge und Abfolgen untersucht
Konzentriert sich auf Beziehungen zwischen Knoten und Kanten
�
�
�
Unter einem Graph versteht man eine Menge von , .....
..... die untereinander mit verbunden sind (siehe Begriff “System” !).
zeigen auch die Art der Verbindung (Richtung derEinflußnahme) zwischen den Knoten an.
Knoten
Kanten
Gerichtete Graphen
31
Anwendungsbereiche der Graphentheorie
Eulersches Brückenproblem
�
�
Operations Research: Quantitative Methoden zur Planung undEntscheidungsvorbereitung
Ingenieur- und wirtschaftswissenschaftliche Bereiche
� Euler 1736 in Königsberg: Gibt es einen Spazierweg über das Brückensystemder Pregel, bei dem jede Brücke genau einmal passiert wird?
Insel
Ufer
Ufer
Ufer
2.3 Graphen und Petri-Netze
32
Travelling-Salesman-Problem
� Ein Vertriebsbeauf-tragter will einebestimmte Mengevon Kunden auf einer
abklappern.
Rundreise mitminimaler Länge
Kunde 2
Kunde 1
Kunde 3
Kunde 4
Kunde 5
Kunde 6
Depot = Startort = ZielortZeit-/Weg-
minimierung
2.3 Graphen und Petri-Netze
33
Kunde 2
Kunde 1
Kunde 3 Kunde 4
Kunde 5
Kunde 6
Depot = Startort = Zielort
Tour 1
Tour 2
Tour 3
Zeit-/Weg-und Kosten-minimierung
$
Touren-Problem
� Innerhalb eines best. Zeitraums ist eine best. Menge von Kunden mit einer best.Menge Lieferwagen mit best. Produktmengen möglichst effizient zu beliefern.
2.3 Graphen und Petri-Netze
34
SN
I
Depot 1
SN
I
Depot 2
SN
I
Depot 3
Kunde 1 Kunde 2 Kunde 3 Kunde 4
Kosten-minimierung $ $
Transport-Problem
� Von einer best. Menge an Depots aus ist eine best. Menge von Kunden (miteiner best. Menge Lieferwagen) mit best. Produktmengen möglichst effizient zubeliefern (keine Transport zwischen Kunden oder zwischen Depots).
2.3 Graphen und Petri-Netze
35
10 0
5 5
30 30
30 30
30 37
47 47
45 45
2
3
4 6
7
5
START
ZIEL
AC
S1
F
H
Netzplantechnik (NPT)
� Große, komplexe Projekte planen, analysieren, steuern, kontrollieren, optimieren
Ablaufstrukturplan mit zeitbeanspruchenden und zeitpunktbezogenen Elementenmuß vorher erstellt worden sein
Zeitdauern und Vorgänger-/Nachfolgerbeziehungen sind bekannt.
�
�
2.3 Graphen und Petri-Netze
36
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
Petri-Netze
�
�
�
Begründer: C. A. Petri, 1962, Ges. für Mathematik und Datenverarbeitung (GMD)
Petri-Netze sind gerichtete Graphen.
Petri-Netze sind keine Instrumente, um Fische zu fangen. (Stahlknecht)
37
Petri-Netze: Anwendungsbereiche
Petri-Netze: Elemente
�
�
�
�
�
Anwendungsneutral: Mit Petri-Netzen lassen sich Systeme und Abläufemodellieren, die auf diskreten Aktionen und Abhängigkeitsbeziehungen zwischendiesen Aktionen basieren.
Erlauben die Simulation der Modell-Dynamik mittels Verhaltensregeln.
Bspw. Modellierung, Analyse umd Simulation im Bereich derAutomatisierungstechnik
Wirtschaftswissenschaften: Modellierung von betrieblichen Abläufen alshochaktuelles Anwendungsgebiet - Geschäftsprozeß-Modellierung
U. a.: Geschäftsprozesse, Workflow-Management-Systeme, Customizing vonStandard-Anwendungssoftware
�
�
�
Statische Knoten-Elemente:
Kanten:
Dynamische Elemente:
Zustände (passiv) und Ereignisse (aktiv)
Kausal-logische Zusammenhänge zwischen Zuständen und Ereignissen
Marken (für Zustände)
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
38
Passive Elemente: Zustände (Kreise)
Kausal-logische Zusammenhänge: Kanten (Pfeile)
Aktive Elemente: Ereignisse (Rechtecke)
�
�
�
�
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.
� Gerichtete Kanten = Pfeile
�
�
�
�
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.
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
39
Ereignisse und Zustände
Richtig:
Falsch:
�
�
�
�
�
�
�
Ein Ereignis beschreibt die Erzeugung, Veränderung, den Transport von z. B.Daten oder Rohstoffen bei der Realisierung von Prozessen.
Ein Ereignis setzt genau definierte und erfüllte Zustände voraus und/oder führt zueiner genau definierten Menge von Zuständen.
Die Beendigung eines Zustands erfolgt durch mind. ein Ereignis.
Der Beginn eines neuen Zustands wird von mind. einem Ereignis angestoßen.
Eingangszustand:
Ausgangszustand:
Zustände und Ereignisse wechseln sich immer ab: bipartider Graph
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
40
Ereignisse und Zustände Falsch Richtig
�
�
�
�
Wege beginnen und endennicht mit einer Kante.
Es gibt keine alleinstehendenKnoten.
Es gibt keine parallelverlaufenden Kanten.
Es gibt keine bidirektionalenKanten.
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
41
Zustand 1 Zustandsübergangkann eintreten, wennZustand 1 realisiert ist
Zustand 2wird durch den Ein-
tritt des Zustands-
übergangsrealisiert
Erteiltes
Angebot AuftragAuftrags-
bearbeitung
Eingangszustand Ausgangszustand
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
42
Dynamische Elemente: Marken (in Zuständen)
�
�
�
�
�
�
�
�
�
Durch das Setzen von Marken (Markierungen) in Zuständen wird die Dynamikeines Systems oder Prozesses abgebildet.
Jeder Zustand der realisiert ist, wird markiert.
Markiert wird durch einen Punkt.
Marken können exogen (empirische Beobachtung des Modellbenutzers) oderendogen (aufgrund der modellbedingten Kausal-Logik) verursacht sein.
Eine Zustandsübergang (Ereignis) kann “schalten” (durchgeführt werden), wennder Zustandsübergang aktiviert ist.
Ein Zustandsübergang ist aktiviert, wenn alle Eingangszustände markiert undalle Ausgangszustände markenfrei sind.
Es besteht kein Schaltautomatismus. Schaltvorgänge verbrauchen keine Zeit.
Erfolgt ein Zustandsübergang, werden von allen seinen Eingangszuständen dieMarken weggenommen und alle seine Ausgangszustände mit Marken belegt.
Diese Vereinbarung zum Setzen von Marken (Schalten des Zustands-übergangs) heißt “Schaltregel” (Transitions-, Simulationsregel, Firing Rule).
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
43
Markierungssituationen in Petri-Netzen
Unproblematische Situation: Aktivierung (Schaltbarkeit, Concession)
�
�
Wenn pro Zustand maximal 1 Marke zulässig ist, spricht man von einemBedingungs-/Ereignis-Netz (B/E-Netz).
Lokalitätsprinzip: Zustände und Ereignisse werden immer nur durch ihre direkte,lokale Umgebung beeinflußt (Kapselung, Modularisierung).
� Markierte Eingangszustände stehen unmarkierten Ausgangszuständengegenüber. Ereignis kann geschaltet werden.
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
44
Konflikt-Situation: Begegnung (Contact)
A?
�
�
Mindestens 1 Ausgangszustand (hier A) ist bereits markiert. Das Ereignis kannmithin nicht schalten.
Kann eintreten, wenn A zugleich Ausgangszustand eines anderen Ereignisses istoder wenn nicht vorhergesehene exogene Störungen auftreten.
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
45
Konflikt-Situation: Verzweigung (Branch Conflict)
A A
a b
1 1
2 2C C
B B
�
�
�
�
�
�
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.
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
Konflikt-Situation: Wettbewerb (Meet Conflict)
AA
a b
11
22
CC BB
�
�
�
�
�
”Markenüberangebot”: Die Ereignisse 1 und 2 können nicht gleichzeitig schalten,da dann Ausgangszustand C vereinbarungswidrig mit zwei Marken belegt würde.
Lösung 1: Modellbenutzer bestimmt das schaltende Ereignis exogen.
Oder Lösung 2: Entscheidungsregel zur abwechselnden Schaltung
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.
46
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
Konflikt-Situation: Symmetrische Konfusion
A1
2
3
C
D
EB
�
�
�
�
Verflochtene Konfliktsituation: Verzweigung und Wettbewerb
Bspw.: Herstellung der Produkte C, D, E mit den Ressourcen A und B
Lösung 1: Modellbenutzer bestimmt das schaltende Ereignis exogen.
Oder Lösung 2: Entscheidungsregel zur abwechselnden Schaltung
47
a
1b
A
2
1
B
C
D
E
32
b
c
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
Konflikt-Situation: Asymmetrische Konfusion
b. w.
�
�
�
�
Konflikt (zwischen 2 und 3) tritt erst ein, wenn ein Ereignis (hier 1) schaltet unddie Marke dann von A nach B wandert.
Wenn dann 2 schaltet, wird die C-Marke eliminiert und 3 kann nicht geschaltetwerden.
Wenn statt dessen 3 schaltet, sind nicht alle Eingangszustände für 2 aktiviert.
Lösung 1: Exogener Eingriff
48
A 21 B
C
D
E3
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
Konflikt-Situation: Asymmetrische Konfusion
� Oder Lösung 2: Entscheidungsregel zur abwechselnden Schaltung
49
a b
A 21 B
C
D
E3
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
50
NichtunterscheidbareMarken
Markenkapazitätder Zustände = 1
Bedingungs-/Ereignis-Netze(B/E)
Stellen-/Transitions-Netze(S/T)
Prädikats-/Transitions-Netze(Pr/T)
Prädikats-/Transitions-Netze(Pr/T)
Markenkapazitätder Zustände > 1
UnterscheidbareMarken
Verschiedene markenorientierte Petri-Netz-Typen
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
51
EingegangeneBestellung
Mitarbeiterverfügbar Bearbeitung
der Bestellung
GeschriebeneRechnung
AusgelieferteWare
EingegangeneBestellung
Mitarbeiterverfügbar Bearbeitung
der Bestellung
GeschriebeneRechnung
AusgelieferteWare
Kurzbeschreibung: B/E-Netze
�
�
�
�
�
�
�
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
Marke vorhanden / nicht vorhanden: Bedingung wahr / falsch
Voraussetzungen für Ereignis-Schaltung: Alle Eingangsbedingungen sind wahr(markiert), alle Ausgangsbedingungen sind falsch (nicht markiert).
Ereignisschaltung: Allen Eingangsbedingungen wird eine Marke entnommen,allen Ausgangsbedingungen wird eine Marke zugefügt
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
52
Kurzbeschreibung: S/T-Netze
�
�
�
�
�
�
�
Zustand = Stelle / Zustandsübergang = Transition
Jede Stelle kann mehr als 1 Marke haben: Stellen-Kapazität > 1
Marken sind nicht unterscheidbar.
Mit jeder Transitions-Schaltung können mehrere Marken transportiert werden:Kanten-Kapazität > 1 (”Kanten-Gewichtung” gibt max. Markenmenge vor)
Voraussetzungen für Transitions-Schaltung: Anzahl Marken in jederEingangsstelle >= Kapazität der abgehenden Kante und freie Kapazität jederAusgangsstelle >= Gewichtung der dort eingehenden Kante.
Transitions-Schaltung: Allen Eingangsstellen wird diejenige Anzahl an Markenentnommen, die der Gewichtung der abgehenden Kante entspricht.
Transitions-Schaltung: Allen Ausgangsstellen wird diejenige Anzahl an Markenzugewiesen, die der Gewichtung der eingehenden Kante entspricht.
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
53
EingegangeneBestellung
Mitarbeiterverfügbar Bearbeitung
der Bestellung
GeschriebeneRechnung
AusgelieferteWare
K=50
K=10K=10
K=10
2
1 1
1
Kurzbeschreibung: S/T-Netze (Beispiel)
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
54
Kurzbeschreibung: Pr/T-Netze
�
�
�
�
�
�
�
�
�
�
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ügenPrä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 hatdiejenigen Tupel, die die Kanten der Ausgangsprädikate fordern und jedesAusgangsprädikat enthält nicht die Tupel, die die eingehende Kante fordert.
Transitions-Schaltung: Den Eingangsprädikaten werden die durch die Kanten-beschriftungen festgelegten Tupel entnommen und die Ausgangsprädikate wer-den durch die Tupel ergänzt, die die jeweilige Kantenbeschriftungen fordert.
Die Marken (Relationen) aus den Eingangsprädikaten werden in die Marken derAusgangsprädikate umgesetzt.
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
55
EingegangeneBestellung
Mitarbeiterverfügbar
Bearbeitung derBestellung
GeschriebeneRechnung
AusgelieferteWare
K=50
K=10K=10
K=10
19.12.2000241299Muster GmbH
Eing-DatumBestellnummerFirma
22.12.200024129936 58 778
Erstellungs-DatumBestellnummerPersonalnummer
36 58 778Hr. Friedrich
PersonalnummerMitarbeiter
24129936 58 778
BestellnummerPersonalnummer
Kurzbeschreibung: Pr/T-Netze (Beispiel)
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
56
Vorteile Petri-Netze
Nachteile Petri-Netze
�
�
�
�
�
�
�
Klare Abbildung von Sequenzen, Nebenläufigkeiten und Verklemmungen inProzeß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- undGraphentheorie) finden sich in der geschilderten oder in abgewandelter Form inden Modellierungsansätzen für IKS wieder.
�
�
�
Fehlen allgemeiner Systematiken zum Vorgehen bei der Erstellungvon Petri-Netzen
Modellierung subjektiv / keine Petri-Netz-orientierten Methoden
Erhöhter Lernaufwand höherer Netz-Typen (Pr/T-Netze)
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
Entw
ickl
ungse
benen
Situations-studie
Fach-konzeption
System-konzeption
System-entwicklung
System-installation
Zeit
Meilen-stein
1
Situations-studie
Validierung
Meilen-stein
2
Fachkon-zeption
Validierung
Meilen-stein
3
System-konzep-tion
Validierung
Meilen-stein
4
System-entwick-lung
Validierung
Meilen-stein
5
System-installa-tion
Validierung
57
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
Anwendungsfelder Petri-Netze
Ausgewählte Quellen-Hinweise zu Petri-Netzen
�
�
�
�
Balzert, Helmut: Lehrbuch der Software-Technik - Software-Entwicklung. 2. Aufl.,Heidelberg, Berlin: Spektrum Akademischer Verlag 2000. Kapitel 2.17,S. 346-374.
Desel, Jörg; Oberweis, Andreas: Petri-Netz in der Angewandten Informatik. In:Wirtschaftsinformatik, 4/1994, S. 359-366.
Desel, Jörg; Erwin, Thomas: Simulation von Geschäftsprozessen mit Petri-Netzen. In: WISU, 3/1999, S. 337-344.
Rosenstengel, Bernd; Winand, Udo: Petri-Netze - Eine anwendungsorientierteEinführung. 4. Aufl., Braunschweig: Viehweg 1991.
58
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
59
2.4 Prinzipien für die Entwicklung von betrieblichen IKS
Prinzip der hierarchischen Dekomposition
Prinzip der Strukturierung und Modularisierung
� Nach den systemtheoretischen Grundlagen der Abstraktion und schrittweisenVerfeinerung (siehe Kap. 2.2)
� Nach den systemtheoretischen Grundlagen der Blockbildung undModularisierung (siehe Kap. 2.2)
Prinzip der konstruktiven Voraussicht
�
�
�
Schon ab den ersten Schritten der Systementwicklung ist auf Qualitätssicherung,Änderbarkeit, Wartbarkeit zu achten.
Erstellungsprozeß durch praktikables Vorgehensmodell und methodischeStandardisierung strukturieren
Integration aller Dokumentationsaktivitäten (in allen Phasen)
Prinzip der perspektivischen Betrachtung
�
�
Abhängig vom Betrachter werden verschiedene Aspekte eines Systemsherausgehoben. Die Integration der Sichtweisen ist erforderlich.
Benutzer, Entwickler, Techniker, Unternehmensführung, -organisation, Kunden ...
60
2.4 Prinzipien für die Entwicklung von betrieblichen IKS
Prinzip der methodischen Standardisierung
Toolbox
Projektstart Projektende
Paradigma
Situations-studie
Fach-konzeption
System-konzeption
System-realisierung
System-anwendung
Prinzipien VG-Modell
Zwischenergebnisse weiterentwickeln
Modellierungs-ansätze
Konzepte,Notationen
CASE-Werkzeuge
�
�
Für die Systementwicklung wird ein Bündel von Methoden, Konzepten, Techni-ken, Werkzeugen vom arbeitsteilig organisierten Entwicklungsteam eingesetzt.
Alle Beteiligte sollten im Systementwicklungsprozeß gemäß einem best. Vorge-hensmodell und mit Instrumenten arbeiten, die aufeinander abgestimmt sind unddamit die Koordination von Ablauf und Entwicklungsergebnissen fördern.
61
2.4 Prinzipien für die Entwicklung von betrieblichen IKS
Pri
nzip
der
Tre
nn
un
gvo
nE
ssen
zu
nd
Inkarn
ati
on
� � �
”Ess
enz”
zuers
t:G
ut(f
ach
lich)
gepla
ntis
thalb
gew
onnen.
”Inka
rnatio
n”
danach
:Te
chnik
und
Pro
-gra
mm
ieru
ng
strikt
nach
Pla
n.
”Desi
gn
first
,co
de
late
r.”
Ph
ase
Tä
tig
ke
ite
nZ
wis
ch
en
pro
du
kt
Situ
atio
nss
tud
ieP
roje
ktvo
rsch
lag
Fa
chko
nze
ptio
nA
nfo
rde
run
gse
rmitt
lun
g
An
ford
eru
ng
s-sp
ezi
fizie
run
g
Sys
tem
-ko
nze
ptio
nP
rog
ram
msy
ste
me
ntw
urf
Da
ten
syst
em
en
twu
rf
Ha
rdw
are
syst
em
en
twu
rf
Sys
tem
-re
alis
ieru
ng
Pro
gra
mm
ieru
ng
Inte
gra
tion
Sys
tem
test
Sys
tem
-a
nw
en
du
ng
Inst
alla
tion
Wa
rtu
ng
Fa
chlic
he
sB
asi
sko
nze
pt
Fa
chlic
he
sD
eta
ilko
nze
pt
Pro
gra
mm
stru
ktu
r
Da
ten
stru
ktu
r
Ha
rdw
are
kon
figu
ratio
n
Pro
gra
mm
iert
eM
od
uln
Mo
ntie
rte
Pro
gra
mm
-Mo
du
ln
Ge
test
ete
sP
rog
ram
msy
ste
m
Nu
tzu
ng
sbe
reite
So
ftw
are
Ge
wa
rte
teK
om
po
ne
nte
n
1.
2.
3.
4.
5.
Pro
ble
me
rke
nn
un
g
Es
se
nz:
Fa
ch
lic
he
Sic
ht
Ink
arn
ati
on
:K
on
str
uk
tiv
eS
ich
t
62
2.5 Objekt und Sichtweisen der Modellierung von betrieblichen IKS
Objekt der Modellierung von betrieblichen IKS
Sichtweisen der Modellierung von betrieblichen IKS
�
�
�
Jedes IKS wird entwickelt, um bestimmte fachliche Aufgaben zu erfüllen.
Analyse und Entwurf des Aufgabensystems sind die wichtigsten Schritte für diePlanung des IKS.
Das Objekt der Modellierung ist demnach das durch das IKS betroffeneAufgabengefüge im Unternehmen.
�
�
�
�
Das Aufgabengefüge im Unternehmen läßt sich gemäß den Merkmalen vonAufgaben unter folgenden relevanten Sichtweisen betrachten.
Statische und dynamische Strukturaspekte
Sachmittel und vor allem Daten
Einordnung in die Aufbau- undAblauforganisation des Unternehmens
Struktur von Aufgaben:
Ressourcen von Aufgaben:
Einbindung in die Organisationsstruktur:
Aufgabenmodellierung: Statische Funktionen
63
2.5 Objekt und Sichtweisen der Modellierung von betrieblichen IKS
VERTRIEB
Angebots-bearbeitung
Auftrags-bearbeitung
Auftrags-verwaltung
Aus-lieferung
Auftrags-abrechnung
Versand-planung
Versand-unterlagen
Fakturierung
Provisions-abrechnung
Auftrags-nachkalku-lation
Fälligkeits-überwachung
Liefer-freigabe
Auftrags-änderungs-dienst
Angebots-konfiguration
Angebots-kalkulation
Liefertermin-ermittlung
Angebots-überwachung
Auftrags-erfassung
Auftrags-prüfung
Auftrags-kalkulation
Auftrags-bestätigung
Aufgabenmodellierung: Dynamische Prozesse (Funktionen)
64
2.5 Objekt und Sichtweisen der Modellierung von betrieblichen IKS
Eigen-fertig.prüfen
Fremd-bezugprüfen
Auftragterminieren
Auftragkalkulieren
Auftragbestätigen
Vertreter-Auftrag
KD-Auftrag
Auftragkonfig.
KD-Bezieh.prüfen
Auftragsbestätigung
Aufgabenmodellierung: (Ereignisgesteuerte) Prozeßketten
65
2.5 Objekt und Sichtweisen der Modellierung von betrieblichen IKS
Kundewird nichtbeliefert
Auftrags-ablehnungschreiben
Kunden-auftrageingetr. EF-Teile
für KDA
FB-Teilefür KDA
Auftragkonfigurieren
Kunden-beziehung
prüfen
abgelehnt.Kunden-auftrag
XOR
VKundewird
beliefert
Aufgabenmodellierung:(Ereignisgesteuerte)Prozeßketten
BeantragungeinerHypothek
(Stahlknecht 2002)
66
2.5 Objekt und Sichtweisen der Modellierung von betrieblichen IKS
Antrag aufHypothekliegt vor
Bauunterlagenprüfen
Sicherheitenprüfen
Unterlagenunvollständig
weitereUnterlagenbeschaffen
Unterlagenvollständig
Sicherheitenvorhanden
Sicherheitennicht vorhanden
Hypothekbewilligen
Hypotheknicht bewilligen
weitereUnterlagenliegen vor
XOR XOR
XOR
Antragabgelehnt
Aufgabenmodellierung: Daten (semantisches Modell)
67
2.5 Objekt und Sichtweisen der Modellierung von betrieblichen IKS
stellt
enthält liefert
Kunde
NameAdresse
BonitätTelefonTelefax
Auftrag
BestelldatumLieferdatum
Bestellte MengeRabatt
Spezialpreis
Artikel
ArtikelbezeichnungLagerbestandMindestbestandEinzelpreisVerpackung
Hersteller
FirmennameAdresseTelefonTelefaxEntfernung
Aufgabenmodellierung: (Aufbau-) Organisationsstruktur
68
2.5 Objekt und Sichtweisen der Modellierung von betrieblichen IKS
Produktion Lager u.VerkaufEinkauf
MarketingVertrieb Verwaltung
Geschäftsleitung
Aufgabenmodellierung: (Ablauf-) Organisationsstruktur
69
2.5 Objekt und Sichtweisen der Modellierung von betrieblichen IKS
Auftrag erfassen
Auftrag prüfen
Auftrag konfigurieren
Auftrag kalkulieren
Auftrag terminieren
Auftrag bestätigen
X
X
X
X
X
X
X
X
X
X
X
X
X
Posteingang/-verteil.
AbteilungVertrieb
AbteilungEinkauf
AbteilungProduktion
AbteilungLager/Vers.
AbteilungVerwaltung
X
.
.
.
Resultierende Modellierungsansätze von betrieblichen IKS
�
�
�
Aufgrund der vorgenannten Sichtweisen auf das Aufgabengefüge einesUnternehmens sind zu modellieren:
- Funktionen- Prozesse- Daten- Organisationsstrukturen
Es existieren verschiedene Ansätze zur Modellierung von IKS, die jeweils aufbestimmte Modellierungsobjekte fokussieren:
- Funktionsorientierte Modellierungsansätze (z. B. HIPO)- Datenorientierte Modellierungsansätze (z. B. ERM)- Datenflußorientierte Modellierungsansätze (z. B. SA und SADT)
Weiterhin existieren Modellierungsansätze, die die verschiedenenModellierungsobjekte integrieren wie z. B.:
- Sichtweisen-integrierende Modellierung (z. B. mit ARIS)- Objektorientierte Modellierung (z. B. mit der UML)
70
2.5 Objekt und Sichtweisen der Modellierung von betrieblichen IKS
71
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
Gliederung
Systems Engineering - Modellierung von IuK-Systemen
Wirtschaftsinformatik - Wintersemester 09/10
72
3. Funktionsorientierte Modellierung
Funktionsorientierte des UnternehmensAufbauorganisation
�
�
Die traditionellen betriebswirtschaftlichen Funktionalbereiche definieren diestatischen Aufbau-Organisationseinheiten des Unternehmens.
Traditionell mit verrichtungsorientierter dynamischer Ablauforganisation
Geschäftsleitung
Beschaffung Produktion ReWe Vertrieb
Stelle Stelle Stelle Stelle
Stelle Stelle Stelle Stelle
73
3. Funktionsorientierte Modellierung
Funktionsorientierte des UnternehmensAblauforganisation
� Verrichtungsorientierte dynamische Ablauforganisation
�
�
Beispiel “Ersatzteilbeschaffung”
Anfrage Kunde an Vertriebsleiter - Sb. A erstellt Angebot - Vertriebsleiterkontrolliert - Sb. A verschickt - Kunde bestellt bei Sb. C - Sb. D erfaßt Bestellung -Vertriebsleiter kontrolliert - Auftragsbestätigung an Kunde durch Sb. A - ..........
74
3.1 Funktions- und Verrichtungsorientierung
Funktions-/verichtungsorientierte
Ablauforganisation
�
�
�
�
�
Hohe Arbeitsteilung,
Viele Schnittstellen in derBearbeitungsfolge
Lange Bearbeitungszeiten
Hoher Koordinationsbedarf
Hierarchiegrenzen sindAblaufgrenzen.
Kunde “droht mit Auftrag"
Hier stehen wir.
75
Funktionale betriebliche IuK-Anwendungssysteme
�
�
�
�
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
Angebots-bearbeitung
Auftrags-bearbeitung
Auftrags-verwaltung
Fälligkeits-überwachung
Liefer-freigabe
..........
..........
Angebots-konfiguration
Angebots-kalkulation
..........
Auftrags-erfassung
Auftrags-prüfung
..........
3.2 Funktionsorientierte Modelle
Unter-funktion
Unter-funktion
Unter-funktion
Elementar-funktion
Elementar-funktion
Elementar-funktion
76 Präzedenzmatrix
EF1
EF1
EF2
EF2
EF3
EF3
EF4
EF4
VNF
X
X X
X X
X
Funktion
Unter-funktion
Unter-funktion
Unter-funktion
Elementar-funktion
Elementar-funktion
Elementar-funktion
“I-P-O"-Beschreibung
Hierarchy
Input
Process
Output
HIPO
x x ... x x
x x ... x x
x x ... x x
x x ... x x
x x ... x x
x x ... x x
Input Process Output
Struktogramm
Beginn
Ende
EF 1EF 2EF 3
EF 4 EF 5
3.2 Funktionsorientierte Modelle
Funktionsstruktur
77
3.2 Funktionsorientierte Modelle
VERTRIEB
Angebots-bearbeitung
Auftrags-bearbeitung
Auftrags-verwaltung
Aus-lieferung
Auftrags-abrechnung
Versand-planung
Versand-unterlagen
Fakturierung
Provisions-abrechnung
Auftrags-nachkalku-lation
Fälligkeits-überwachung
Liefer-freigabe
Auftrags-änderungs-dienst
Angebots-konfiguration
Angebots-kalkulation
Liefertermin-ermittlung
Angebots-überwachung
Auftrags-erfassung
Auftrags-prüfung
Auftrags-kalkulation
Auftrags-bestätigung
Bsp. Auftragsbearbeitung: Dekomposition der Funktionen
78
3.2 Funktionsorientierte Modelle
Bsp. Auftragsbearbeitung: Weitere Dekomposition der Funktionen
Ausgangsebene
1. Dekomp.-ebene
2. Dekomp.-ebene
3. Dekomp.-ebene
Auftrags-bearbeitung
Auftrags-verwaltung
Auslieferung Auftrags-abrechnung
KD-Beziehungprüfen
Auftragerfassen
Auftragbestätigen
Auftragz. Ausl. vorm.
Leitdatenerfassen
Kopfdatenerfassen
Pos.-Datenerfassen
Auftragabschließen
Kundenauftragsführung
Vertreter
Auftragskopf
Kunde
ProduktProdukt-lagerort
Konto
RechnungAuftrags-position
Sachbe-arbeiter
KD-NR.Vertr.-Nr.KD-NameKD-Anschrift......
Vertr.-Nr.KD-Nr.
Vertr.-NameVertr.-Anschrift...
Auftr.-Nr.Pos.-Nr.Art.-Nr.Menge...
KD-NR.Vertr.-Nr.Auftrags-Nr.Auftragsdatum...
79
3.2 Funktionsorientierte Modelle
Bsp. Vertrieb:Informationsmodell
80
Bsp. Auftrags-bearbeitung:
Dialogstruktur
Auftragz. Auslief.vormerken
Kunden-Bonitätprüfen
Auftrags-Leitdatenerfassen
Auftrags-Kopfdatenerfassen
Auftrags-Pos.-Daten
erfassen
Lager-bestandprüfen
Lager-bestand
reservieren
Kunden-Beziehung
prüfen
Auftragabschließen
Auftragbestätigen
3.2 Funktions-orientierte
Modelle
81
3.2 Funktionsorientierte Modelle
Funktionendiagramm
Ebenendiagramm
Input Process Output
Kunden-stammdaten
Artikel-stammdaten
Bestelldaten
Lager-bestands-daten
Faktu-rierung
Bestands-verwaltung
Rechnung
Berichts-wesen
Lager-bestands-daten
Auftrags-bearbeitung
Bestands-verwaltungFakturierung
Bsp. HIPO-Diagramm
(Stahlknecht 2002)
82
3.2 Funktionsorientierte Modelle
Bsp. Auftragsbearbeitung: Auftragspositionsdaten erfassen
PROCESSINPUT OUTPUT
Benutzer-Input:
System-Input:
- Artikel-Nr.
- Menge
- Preis (fakult.)
- Bemerkungen
(fakultativ)
- ..........
Daten aus
- Produkt-IS
- Lager-IS
Benutzer-Output:
System-Output:
s. BS-Masken-
Entwurf
Daten an
- Kunden-IS
- Lager-IS
Verarbeitungsvorschrift:
Gültigkeitsprüfung für Art.-Nr.
Sperrfristprüfung für Art.-Nr.
Lagerverfügbarkeit für bestellte
Menge prüfen; ggf. Reservierung
für Kunden vornehmen
Mengeneinheit:
- default: ST
- zur Wahl: 12-Pack Palette
Preis:
- Listenpreis
- Aktionspreis (fakultativ)
83
3.2 Funktionsorientierte Modelle
Sequenz (Reihung, Folge)
Strukturblock A
Strukturblock B
Strukturblock C
Strukturblock B
Strukturblock C
Strukturblock A
Verzweigung (Selektion, einfache Alternat.)
Struktur-block A Struktur-
block A
Struktur-block B Struktur-
block B
Bedingungerfüllt ?
Bedingungerfüllt ?
NJNJ
Bedingungerfüllt ?
Wiederholung (Iteration, mit Bedingung)
Strukturblock A
Strukturblock A
Wiederholungsbedingung
N
J
Auswahl (Selektion, mehrfache Alternative)
Struktur-block A
Struktur-block B
Struktur-block C
Fallabfrage
Fall-abfrage
Struktur-block A
Struktur-block B
Struktur-block C
Steuerkonstrukte der Programmierung: PAP und Struktogramme (Stahlknecht 2002)
84
3.2 Funktionsorientierte Modelle
Vorstufe derProgrammierung:Pseudocode
(Stahlknecht 2002)
BEGINEröffne Datei AusgangsrechnungenR15 = 0, R20 = 0Lies Datensatz AusgangsrechnungWHILE Datensätze vorhanden DO
IF Rechnungsbetrag > € 3.000THEN Rabatt = 0,20 x Rechnungsbetrag
R20 = R20 + RabattELSE Rabatt = 0,15 x Rechnungsbetrag
R15 = R15 + RabattENDIFLies Datensatz Ausgangsrechnung
ENDDORGES = R15 + R20Drucke RGES , R15, R20Schließe Datei Ausgangsrechnungen
END
85
3.2 Funktionsorientierte Modelle
Bsp. Auftragsbearbeitung: BS-Maskenentwurf zu“Auftragspositionsdaten erfassen”
86
3.2 Funktionsorientierte Modelle
Stelle
Aktion
1
2
3
4
5
6
7
Poststelle
Schadensregulierung
Sach-bearbeiter Leiter
Buchhaltung
Schadens-meldungannehmen
Meldungprüfen
Zahlungs-betragermitteln
Zahlungs-betraggenehmigen
Mitteilungerstellen
Mitteilungversenden
Zahlungs-betraganweisen
Original Kopie
Bsp. Schadenregulierungbei einer Versicherung
Ablauforganisation -Laufwegesteuerung
(Stahlknecht 2002)
87
3.2 Funktionsorientierte Modelle
Ab
teil
un
ge
n
Be
arb
eit
un
gs
sc
hri
tte
:A
BF
LV
SB
HV
LK
D
An
ge
bo
teb
ea
rbe
ite
n
Au
fträ
ge
be
arb
eit
en
-B
on
ität
prü
fen
-V
erf
üg
ba
rke
itp
rüfe
n
-R
ese
rvie
ren
Au
ftra
gs
be
stä
tig
un
ge
rste
lle
n
Au
fträ
ge
ve
rwa
lte
n-
Fä
llig
keit
üb
erw
ach
en
-R
ück
stä
nd
eü
be
rwa
che
n
-Z
ute
ilen
-A
usl
iefe
run
gfr
eig
eb
en
-A
uft
rag
sän
de
run
ge
nvo
rne
hm
en
Au
sli
efe
run
g-
Lie
fers
che
insc
hre
ibe
n
-V
ers
an
dd
oku
me
nte
sch
reib
en
-A
usl
iefe
run
grü
ckm
eld
en
Au
ftra
gs
ab
rec
hn
un
g
-F
akt
ura
ers
telle
n
-A
uft
räg
en
ach
kalk
ulie
ren
Bsp
.K
un
den
au
ftra
gsfü
hru
ng
Org
an
isato
risch
eL
au
fweg
este
ueru
ng
88
3.2 Funktionsorientierte Modelle
Funktionsorientierte Modellierung von IKS
�
�
�
�
�
�
�
�
�
Hierarchische Zerlegung
Statischer Aspekt:
Dynamischer Aspekt:
Teilungskriterien sind die Funktionen des IKS im Sinne der zu erfüllendenbetrieblichen Aufgaben.
Funktionsbäume: Untergeordnete Ebenen präzisieren die Teilfunktionen derübergeordneten Ebenen.
Aufbaustruktur des IKS (statische Funktionsstruktur im Stilvon Organigrammen)
Ablaufstruktur des IKS, Reihenfolge der Funktionen (z. B.durch IPO-Tabellen, Präzedenzmatrizen, Struktogrammen, Flußdiagramme,Programmablaufpläne)
Daten sind Ressourcen zur Erfüllung der Funktionen
Funktionsspezifische Datendefinitionen und Datenzuordnungen verursachenRedundanzen und Inkonsistenzen.
In einem dynamischen Markt-/Unternehmensumfeld sind Definitionen vonDatenstrukturen zeitstabiler als Funktionsstrukturen.
Daher wird in Literatur und Praxis ein stärker datenorientierterModellierungsansatz als zweckmäßiger angesehen.
89
3.3 Wandel zur Prozeßorientierung
An
na
hm
eS
erv
ice
Re
kla
ma
tio
nM
ark
eti
ng
Ein
-k
au
f
F&
E
Lo
gis
tik
Re
We
Pro
du
kti
on
Ku
nd
en
=P
art
ner
Hie
rw
ollen
wir
hin
.
90
3.3 Wandel zur Prozeßorientierung
Merkmale der Prozeßorientierung
�
�
�
�
�
�
Die Organisationsstruktur orientiert sich nicht mehr an betrieblichen Funktionensondern an den Wertschöpfungsprozessen des Unternehmens.
Prozesse leiten sich aus den Kernkompetenzen ab und sind auf genau definiertemarktbezogene Leistungen ausgerichtet.
Die Prozeßleistung ist meßbar und kontrollierbar.
Im Gegensatz zu funktionsorientierten Arbeitsabläufen sind Prozesse stellen-,abteilungs-, funktionsbereichsübergreifend. Sie verlaufen quer zu funktionalenOrganisationsstrukturen.
Jeder Prozeß bildet einen eigenständigen Verantwortungsbereich. Prozessedefinieren somit die Organisationseinheiten des Unternehmens.
Die Prozeßarbeit wird von Teams getragen.
Eigen-fertig.prüfen
Fremd-bezugprüfen
Auftragterminieren
Auftragkalkulieren
Auftragbestätigen
Vertreter-Auftrag
KD-Auftrag
Auftragkonfig.
KD-Bezieh.prüfen
91
Geschäftsfeld
Prozeß-Team
Beschaffung Produktion ReWe Vertrieb
Team Team Team Team
Annahme
Bearbeitung
Rechnung
Liefern
Auftragdes
Kunden
Produktbeim
Kunden
Input Markt
3.3 Wandel zur Prozeßorientierung
92
3.3 Wandelzur Prozeß-orientierung
PC-
Kunden
GP Nr. 1: "Kunden aquirieren und Angebote abgeben"
Ereignis 1 Ereignis 2 Ereignis 3
Kunden-auftrageingegan-gen
geprüfteKonfi-guration
geprüfteLiefer-termine
Vorgang 1 Vorgang 2
"BestellteKonfiguration
prüfen"
"Liefertermineprüfen"
EBENE 2
EBENE 1
EBENE 3
A-Über-wachung
Aus-lieferung
Auftr.-Ab-rechnung ReklamationAuftr.-Be-
arbeitung
GP Nr. 2: "Kundenauftrag ausführen"
Vorgangsketten:
Geschäftsprozesse:
Wertschöpfungskette(n):
Marketing + Vertrieb von PCs
Angebotan
Kunde
erfüllterKunden-auftrag
93
3.3 Wandel zur Prozeßorientierung
Funktions-bereich 1
Funktions-bereich 3
Funktions-bereich 2
Funktions-bereich 4
Prozeß 1
Prozeß-leistung
Prozeß 3
Prozeß-leistung
Prozeß 2
Prozeß-leistung
Team
Ko
pp
lun
gv
on
Pro
ze
ss
en
Unter-nehmens-
leitung
Prozeß-Verantwort-
licher
Prozeß-Verantwort-
licher
Prozeß-Verantwort-
licher
Merkmale derProzeß-
orientierung
�
�
Der Verbund vonProzessen .....
..... verlangt nacheinem Verbundvon integrierten/integrierendenbetrieblichen IKS
94
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
Gliederung
Systems Engineering - Modellierung von IuK-Systemen
Wirtschaftsinformatik - Wintersemester 09/10
95
4. Datenflußorientierte Modellierung
4.1 Datenflußorientierte Modellierungsansätze
�
�
�
Betrachtet man eine einzelne Funktion als Blackbox und verknüpft die Funk-tionen über Input-Output-Beziehungen, so erhält man einen Graphen, bei demdie Knoten Funktionen entsprechen und die Pfeile Datenflüsse repräsentieren.
Der funktions- bzw. prozeßorientierten Sicht sehr nahe
Typische Beispiele datenflußorientierter Modelierungsansätze:- SADT (Structured Analysis and Design Technique)- SA (Structured Analysis)
Daten-quelle
Daten-senke
Datenbestand Datenbestand
DatenbestandDatenbesta
nd
VA-Schritt
VA-Schritt
VA-Schritt
VA-Schritt
96
4. Datenflußorientierte Modellierung: SADT
SADT - Structured Analysis and Design Technique
SADT - Anwendungsbereiche
�
�
�
�
�
�
�
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”)
� Allgemeiner Ansatz, um Systeme jeglicher Art zu analysieren und zu entwerfen
�
�
Das “WAS” eines Systems steht im Vordergrund, nicht das “WIE”.
IKS-Entwicklung: Grobentwurf, Requirements Engineering
97
Entw
ickl
ungse
benen
Situations-studie
Fach-konzeption
System-konzeption
System-entwicklung
System-installation
Zeit
Meilen-stein
1
Situations-studie
Validierung
Meilen-stein
2
Fachkon-zeption
Validierung
Meilen-stein
3
System-konzep-tion
Validierung
Meilen-stein
4
System-entwick-lung
Validierung
Meilen-stein
5
System-installa-tion
Validierung
Anwendungsfelder SADT
4. Datenflußorientierte Modellierung: SADT
98
4. Datenflußorientierte Modellierung: SADT
SADT - Darstellungselemente
Aktivitätsmodell(Aktigramm)
FunktionTätigkeit
(Verb)
Eingabe-
objekt
Herkunft
(Tätigkeit)
Ausgabe-
objekt
Verwendung
(Tätigkeit)
Mechanismus(Prozessor)
Mechanismus(Speicher)
InitiierendesEingabeobjekt
InitiierendeTätigkeit
DatenObjekte
(Substantiv)
Datenmodell(Datagramm)
�
�
Nur Kästchen und Pfeile für Funktionen, Tätigkeiten, Daten, Datenflüsse
Immer duale Modelldarstellung: Aktivitäts- und Datenmodell
99
4. Datenflußorientierte Modellierung: SADT
Bibliothekverwalten
E1: Eingänge von Buchhändlern A1: Ausgänge an Buchhändler
E2: Eingänge von Benutzern A2: Ausgänge an Benutzer
E3: Personal A3: Personal
S1: Haushaltsplan S2: Bestandspolitik
SADT - Beispiel “Bibliotheksverwaltung” (Aktigramm)
�
�
Zunächst oberste Hierarchieebene: Gesamtsystem “Bibliothek verwalten”
Start mit Aktigramm (funktionsorientiert)
VerwaltePersonal
BedieneBenutzer
KaufeBücher
E1 (Buchhändler)Bestellungen
Ausgänge
Rücksendungen
:A1 (Buchhändler)
E2 (Benutzer):A2 (Benutzer)
E3 (Personal)
:A3 (Personal)
S1 (HH-Plan)
Bücher
AngestelltesPersonal
AusgeschiedenesPersonal
S2 (Best.-Pol.)
SADT - Beispiel “Bibliotheksverwaltung” (Aktigramm)
� Dann: “Bibliothek verwalten” zerlegen/verfeinern in seine Teilfunktionen
4. Datenflußorientierte Modellierung: SADT
100
Bücher
Bestell-belege
Bestel-lungen
Verlagsan-kündigungen
Prüfe, ob bestellt
Versende
Bestelle
Empfange
Stelle Finanzierungsicher
Sende zurück
Inventarisiere
Prüfe, ob zum Bestand passend
SADT - Beispiel “Bibliotheksverwaltung” (Datagramm)
� Dann: Daten modellieren mit Bezug auf die bekannten Funktionen
101
4. Datenflußorientierte Modellierung: SADT
102
4. Datenflußorientierte Modellierung: SADT
SADT - Beispiel “Schalterverkehr Bibliothek” (Aktigramm)
Bücherausleihen
Bücher zu-rück geben
IdentifiziereBenutzer
Keine Ausleihe
Bücher
Bücher
Entleihschein
Rückgabebestätigung
Keine Ausleihe
Reservierungsschein
Vormerkschein
Benutzerdaten Benutzerdaten
Buchdaten
Buchdaten
Benutzerdaten
Benutzerdatei
Buchdatei
Datei “Ausgeliehene Bücher”Datei “Reservierungen”
103
4. Datenflußorientierte Modellierung: SADT
SADT - Beispiel“Auftragsbearbeitung”(Aktigramm)
(Stahlknecht 2002)
ProgrammAuftragsbearbeitung
Kundendaten
Kundendaten
Artikeldaten
Artikeldaten
Kundenauftrag
Kundenkonto
Rechnung
Auftragsdaten
Rechnungssumme
ProgrammFakturierung
Auftrags-bearbeitung
Fakturierung
Fibu/Debitoren
ProgrammeFinanzbuchhaltung
104
SADT - Vorteile
SADT - Nachteile
� Aufbauorganisatorische Darstellung und Datenmodell mit anderen Methoden zuergänzen.
Kontroll-/Steuerflüsse werden nicht modelliert (”WIE”). AblauforganisatorischeBeziehungen werden somit nicht erfaßt.
Berücksichtigt nicht Lokalitäts-/Geheimnisprinzip: Daher nicht zur Blockbildungund Modularisierung geeignet.
Beschränkung auf 3 bis 6 Teil-Objekte pro Verfeinerungsschritt kannsachlogischen Erfordernissen zuwiderlaufen.
�
�
�
� 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
�
�
�
4. Datenflußorientierte Modellierung: SADT
105
4. Datenflußorientierte Modellierung: SA
SA - Structured Analysis (Tom DeMarco)
SA - Anwendungsbereiche
�
�
�
�
�
�
�
�
Ende der 70er Jahre entwickelt von Tom DeMarco
Grundidee: Es ist leichter, eine Problemlösung zunächst vom Datenfluß hergesehen zu entwickeln, als sie top-down in Funktionen zu zerlegen.
Eine Entwurfsaufgabe wird zunächst mit Hilfe von Datenflüssen in Teilaufgaben(Prozesse) zerlegt.
Kontroll-/Steuerflüsse werden nicht modelliert.
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üssenim ü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 zerlegbarenProzesse sowie der Datenflüsse.
�
�
Das “WAS” eines Systems steht im Vordergrund, nicht das “WIE”.
IKS-Entwicklung: Grobentwurf, Requirements Engineering
106
4. Datenflußorientierte Modellierung: SA
Entw
ickl
ungse
benen
Situations-studie
Fach-konzeption
System-konzeption
System-entwicklung
System-installation
Zeit
Meilen-stein
1
Situations-studie
Validierung
Meilen-stein
2
Fachkon-zeption
Validierung
Meilen-stein
3
System-konzep-tion
Validierung
Meilen-stein
4
System-entwick-lung
Validierung
Meilen-stein
5
System-installa-tion
Validierung
Anwendungsfelder SA
107
4. Datenflußorientierte Modellierung: SA
SADT - Darstellungselemente
� Zusätzlich zu den aus Symbolen bestehenden Graphen wird das Data Dictionary(Datenlexikon mit sog. Minispecs) mitgeführt.
Datenfluß,Materialfluß
Prozeß
Benutzerdaten
Benutzer
Speicher,Materiallager
Datenquelle,Datensenke
Symbol Bedeutung Beispiele
Aus-leihe
Magazin
108
SA - Beispiel “Schalterverkehr (SV) Bibliothek”
�
�
�
Zunächst oberste Hierarchieebene: Gesamtsystem “Schalterverkehr”
Alle relevanten Datenflüsse sind enthalten.
1. SV: 1.1 Benutzeridentifikation, 1.2 Überprüfung Benutzersperre, 1.3 Ausleihe
Benutzer Buchbestand
Magazin
Benutzerdaten
Entleihschein
Entleihschein
Buchdaten
Buchnummer
Leihkennzeichen
Buch
Buch
1.SV
4. Datenflußorientierte Modellierung: SA
109
1.1BI
1.2ÜBS
1.3AL
4. Datenflußorientierte Modellierung: SA
Magazin
Unbek.Benutzer
Benutzer-daten
EntliehenesBuch
Benutzerdaten
Rück-weisung
Rück-weisung
Benutzer-daten
Entleihschein
Rück
wei
sung
Entle
ihschein
Buchnr.
Buchdaten
Buchnr.
Buch Leihkennz.
Buch,Entleih-schein
Benutzerdatei
Ausgeliehene Bücher
Zwischenspeicher Benutzerdaten
Buchbestand
SA - Beispiel “Schalterverkehr (SV) Bibliothek”
110
4. Datenflußorientierte Modellierung: SA
SA - Beispiel“Auftragsbearbeitung”
Kundendatei
Kundendaten
Bestellung Lieferdaten Rechnung
Bestands-daten
Entnahme-daten
Rechnungs-summen
Bestellungbearbeiten
RechnungschreibenKunde Kunde
Lagerbestandsdatei Debitorendatei
(Stahlknecht 2002)
111
SA - Vorteile
SA - Nachteile
� Aufbauorganisatorische Darstellung und Datenmodell mit anderen Methoden zuergänzen.
Kontroll-/Steuerflüsse werden nicht modelliert (”WIE”). AblauforganisatorischeBeziehungen werden somit nicht erfaßt (Teil-Prozesse stellen keine Sequenz dar,obwohl durchlaufend numeriert).
Datenflüsse, -quellen und -senken werden nicht dekomponiert. Alle dieseElemente müssen auf allen Verfeinerungsebenen mitgeführt werden.
Darstellungen werden sehr schnell unübersichtlich.
�
�
�
� 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
�
�
�
4. Datenflußorientierte Modellierung: SA
112
1 Struktur und Ziele der Vorlesung
2 Grundlagen der Modellierung von IKS
3 Funktionsorientierte Modellierung
4 Datenflußorientierte Modellierung
5 Datenorientierte Modellierung
6
7 Prozeßmodellierung mit ARIS
Objektorientierte Modellierung
Gliederung
Systems Engineering - Modellierung von IuK-Systemen
Wirtschaftsinformatik - Wintersemester 09/10
113
5.1 Datenorientierte Modellierungsansätze
Datenorientierte Modellierungsansätze
�
�
�
�
Datenorientierte Modellierungsansätze für IKS konzentrieren sich auf diebetriebliche Datenstruktur, Datenrepräsentationsformen und dieDatenmanipulation.
Datenstruktur bspw. für ein IKS: Kunden, Artikel, Lager, Vertriebsbeauftragte,Aufträge, Lieferanten etc.
Typisches Beispiel für datenorientierte Modellierungsansätze:- ERM (Entity Relationship Modeling)
� 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.
Datenstrukturen sind i. d. R. zeitstabiler als Funktionen und eignen sich daher oftbesser für eine längerfristig gültige Modellbasis eines IKS.
114
5.2 Daten, Datenmanagement und Datenmodellierung
0 1 2 3 4 5 6 7 8 9 Zeichenvorrat
484,00 Syntax ###,##
Zweckbezug,Bedeutungsinhalt
Regeln,Vernetzung
484,00 Kurs SAP-Aktieam 21. Oktober 1997
SAP-Dividenden-InfoSAP: 471,00; 21.09.97SAP: 484,00; 21.10.97
Konjunktur-Informat.Dollarkursentwicklung
Wissen
�
�
�
�
�
�
�
Information = Datum +Zweckbezug
Wissen = Information+ Verstehen
Information vermindertUnsicherheit
Unsicherheit
Information = Kenntnisvon Sachverhalten(DIN 44 300)
Information =zweckorientiertesWissen / Daten
Information = Wissen,Denken, Nachricht
Information
Daten
Zeichen
115
HandlungDurchführung zielgerichteterAktionen
EntscheidungAuswahl aus einerMenge von Alternativen
UmsetzungVerwertung
Datenabstrakte, strukturierteDarstellung der Realität,zweckneutral
InformationWissen über dieRealität, zweckgerichtet
Beziehungszu-sammenhang,Verarbeitung
Abstraktion,Abbildung
Erzeugung
Isoliert betrachtet sind Daten zweckneutral und bedeutungslos.
5.2 Daten, Datenmanagement und Datenmodellierung
116
Informations-Darstellung
strukturiert unstrukturiert
statisch dynamisch
sichtbar hörbar
kombinierte Dokumente Video
Multimedia-Anwendungen
Daten BilderTexte bewegteBilder
akust.Signale
5.2 Daten, Datenmanagement und Datenmodellierung
117
Datenspeicherung: Analog, EDV-extern
Datenspeicherung: Digital, EDV-intern
�
�
Kopf, Zettel, Papier, Notizen .....
Karteikarten, Ordner, Bücher .....
�
�
�
Unstrukturiert in Files: Doc, ASCII, HTML .....
Strukturiert in Files: Index-/sequentielle Filesmit festen/variablen Feldlängen
Strukturiert in Datenbanken: MS-Access,SQL-Server, Oracle, Informix, DB2 .....
5.2 Daten, Datenmanagement und Datenmodellierung
118
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!!!
Unstrukturierte Datenspeicherung
�
�
Beispiel Word-Dokument mit Adressen
Bedarf keiner weiteren Erläuterung .....
5.2 Daten, Datenmanagement und Datenmodellierung
119
Strukturierte Datenspeicherung in Files
�
�
�
Bspw. in COBOL-, Pascal-Files mit festen oder variablen Feldlängen
Jede Applikation speichert “ihre” Daten in “ihren” Files.
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
[...]
5.2 Daten, Datenmanagement und Datenmodellierung
120
Programm 1 Programm 2
Prozedur-Teil
Prozedur-Teil
Daten-beschreibung
Daten-beschreibung
Datei 1 Datei 2
Daten-zugriff
Daten-zugriff
Strukturierte Datenspeicherung in Files
5.2 Daten, Datenmanagement und Datenmodellierung
121
Etwas übertrieben, aber deutlich .....
“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.”
� Vetter, M.: Das Jahrhundertproblem der Informatik, in: Müller-Ettrich (Hrsg.):Effektives Datenbankdesign, Köln 1989, S. 11-31.
5.2 Daten, Datenmanagement und Datenmodellierung
122
Strukturierte Datenspeicherung in Datenbanken
�
�
�
�
Trennung der Daten von den Applikationen
DBMS (Datenbankmanagement-System) zwischen Applikationen und Daten
Datenbanken sind ein Hilfsmittel zur effizienten, rechnergestützten Organisation,Manipulation und Verwaltung großer Datenbestände.
Datenbanken bieten (u. a.) den anwendungsneutralen Zugriff auf Daten, Daten-Integration und -Konsistenz, Zugriffsregelungen und Multi-User-Zugriffe inNetzwerken: alles Problembereiche der Daten-Speicherung in Files.
5.2 Daten, Datenmanagement und Datenmodellierung
123
Programm 1 Programm 2
Prozedur-Teil
Prozedur-Teil
Tabelle 1 Tabelle 2 Tabelle 3 .....
Date
nb
an
k-S
yste
m
Datenbank-Management-System (DBMS)
StrukturierteDaten-
speicherung inDatenbanken
5.2 Daten, Datenmanagement und Datenmodellierung
124
Integrierte GesamtlösungenBereichsübergreifende AWSSicht des GesamtunternehmensIntegration neuer Technologien
–Bürokommunikation–Teamunterstützung–Wissensbas. Systeme
SpartenlösungenIsolierte AW-InselnGeschlossene, teilweiseinkompatible Systeme
Begrenzte Integrierbarkeitneuer Techniken
Gestern/heute Heute/morgen
Anforderungen an betriebliche IKS:Architektur
5.2 Daten, Datenmanagement und Datenmodellierung
125
5.2 Daten, Datenmanagement und Datenmodellierung
Anforderungen an betriebliche IKS:Informationsaktualität
Gestern/heute Heute/morgen
Max. Unterstützung der Bereichs-und Unternehmensziele
Online-Verfügbarkeit allerwesentlichen Informationen
Umfassende, abschließendeSofortverarbeitung
Konsistente DatenbeständeEinsatz der indiv. DV
Begrenzte Auswertbarkeitder Datenbestände
Periodische AuswertungenHohe Anteil StapelverarbeitungDaten-/DateienredundanzUnterschiedl. update-Zyklen
126
5.2 Daten, Datenmanagement und Datenmodellierung
Anforderungen an betriebliche IKS:Entwicklung und Wartung
Gestern/heute Heute/morgen
UnternehmensweitesDatenmodellUnternehmensweiteStandardsToolunterstützungWiederverwendbarkeitSchnelle Reaktions-fähigkeit
Hohe Redundanz beiDaten und FunktionenUnterschiedliche StandardsAbhängigkeit von Spezialisten,mangelhafte DokumentationErhebl. WartungsaufwandHoher Anwendungs-rückstau
127
5.2 Daten, Datenmanagement und Datenmodellierung
“DV-Abteilung” und Datenmanagement
Aufgaben und Ziele des Datenmanagements
Konkrete Aktivitätsbereiche des Datenmanagements
�
�
�
Aus Daten müssen Informationen werden.
Informationen sind als wirtschaftliches Gut zu interpretieren.
Aufgabe der “DV-Abteilung: Nicht “Datenverarbeitung”, sondernInformationsversorgung
�
�
�
Alle im Unternehmen verwendeten Daten planen, überwachen, steuern
Dies unabhängig von den zur Datenspeicherung eingesetzten Sachmitteln
Ziele: Richtigkeit, Vollständigkeit, Aktualität, Konsistenz, Aufgabenadäquanzder Daten / Problem: “Unternehmensweites Datenmodell” (UDM)
�
�
�
Entwicklung und Implementierung von Datenmodellen
Organisation der Datenbeschaffung und Datennutzung
Wartung und Pflege der Datenbestände
128
5.2 Daten, Datenmanagement und Datenmodellierung
Datenmanagement setzt Datenmodellierung voraus
�
�
�
�
Informationenwerden zunehmendwettbewerbsrelevant.
Datensicht stabilerals Funktionssicht.
Gefordert: IntegrierteSichtweise auf alleUnternehmensdaten.
Die Organisation (aufder Basis einerModellierung)bestimmt wesentlichdie Leistung derbetrieblichen IKS.
Objekt Kunde Angebot Organisation
PoliceVertrag
SchadenBeziehung
Entität
129
5.2 Daten, Datenmanagement und Datenmodellierung
Integrationswirkungen der Daten- und Prozeß-Modellierung
�
�
�
Konstitierende Voraus-setzung für jede Land-schaft von IKS ist dieModellierung der Infor-mations-/Datenobjekteeines Unternehmens.
Die parallele Prozeßmo-dellierung gibt die Hin-weise für die Zusam-menfassung vonIntegrationseinheiten.
Die Modelleure benöti-gen den Überblick überdie Kernziele und-Aktivitäten einesUnternehmens.
Ver-treter Kunde
Rech-nung
Konto
Pro-dukt
Lager
Auf-trag
Lager-bestands-führung
Debitoren-Buchhaltung
AuftragsbearbeitungKundenstammdatenverwaltung
Provisions-abrechnung
130
5.3 Vorgehen bei der Datenmodellierung
Datenmodellierung: Begriff
Datenmodellierung: Ziele
Exkurs: Datenbanksysteme
�
�
Formale Beschreibung von Daten und deren Zusammenhänge
”Business Rules” implizit im Modell enthalten
�
�
�
Systematische, strukturierte Erfassung und Dokumentation von Informationen
Verwaltung und Nutzung von Daten/Informationen mit einem Datenbanksystem
Datenmodellierung ist zwingende Voraussetzung für den Entwurf und dieImplementierung von Datenbanksystemen.
�
�
Die Konstruktionsmerkmale eines (relationalen) Datenbanksystems beeinflussendie Modellierung der Daten, die in diesem Datenbanksystem verwaltet werden.
3 Schichten (Schemata) in einem (relationalen) Datenbanksystem:- Konzeptionelles (konzeptuelles) Schema- Externes Schema (Views, Sichten)- Internes (physisches) Schema
131
5.3 Vorgehen bei der Datenmodellierung: Exkurs Datenbanksystem
Ext
ern
es
Sch
em
a:
Be
nu
tze
r-V
iew
1
Ext
ern
es
Sch
em
a:
An
we
nd
.-V
iew
2
Ext
ern
es
Sch
em
a:
Pro
ze
ß-
Vie
w3
Ko
nze
ptio
ne
lles
Sch
em
a:
Ge
sa
mte
sD
ate
n-M
od
ell
(ER
M)
Inte
rne
sS
che
ma
:P
hy
s.
Da
ten
-O
rga
nis
.
Re
alw
elt
Ph
ys
isc
he
Ab
bil
du
ng
DB
MS
Mo
de
llie
run
g
Da
ten
-Ba
sis
Info
rma
tio
ns
-m
od
ell
Tab.1
Tab.6
Tab.7
Tab.2
Tab.3
Tab.5
Tab.4
132
5.3 Vorgehen bei der Datenmodellierung: Exkurs Datenbanksystem
�
�
Stellt die Beschreibung des gesamten Realitätsausschnittes (dar (Unternehmen),der im Datenbanksystem abgebildet werden soll.
Durch Beobachtung der Realität wird ein Informationsmodell erzeugt, aus demdas konzeptionelle Modell (ERM) abgeleitet wird.
�
�
Stellt die physische Organisation der Datenelemente dar (bis hin zur physischenAnordnung der Daten auf Speichermedien).
Wird aus dem konzeptionellen Datenmodell abgeleitet/erzeugt
�
�
�
Ausschnitte des konzeptionellen Modells; Separierung aufgrund bestimmterAufgaben, die der jeweilige Ausschnitt erfüllen soll.
Die Aufgaben sind durch die Anforderungen einzelner Benutzer, Anwendungenoder Prozesse festgelegt.
”Benutzersicht” auf die Daten
Konzeptionelles Schema
Internes Schema
Externe Schemata
133
5.3 Vorgehen bei der Datenmodellierung: Exkurs Datenbanksystem
AbgrenzungRealitätsausschnitt
Konzeptionelles Datenmodell(ERM)
-)Schema
Logisches Relationenmodell(Normalisierung)
Internes/physisches Schema(physisches Datenbankmodell)
1
P
1 P
1
134
�
�
�
�
�
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).
�
�
Überführung des konzeptionellen Datenmodells in ein logisches Schema (hier:Relationenmodell), das dann direkt in ein technischesDatenbanksystem (interne, physische Umsetzung auf Speichermedien) überführtwerden kann.
Hier: Relationenmodell ist somit abhängig vom anvisierten (hier: relationales)Datenbanksystem, in das es umgesetzt werden soll.
(hier: relationales)
Konzeptionelles Datenmodell
Logisches Relationenmodell
5.3 Vorgehen bei der Datenmodellierung: Exkurs Datenbanksystem
Anwendungs-problem
FakturierungPC-Händler
verbal,textuell,visuell
formal,vollständig,graphisch
Namen, Attri-bute,Keys,Werte, ...
DDL/SQL:create data-base, table
z. B. alsER-Modell
Menge vonRelationen-schemata
Phys. Daten-organisation
z. B. Oracle
Kunde ( ,KName, KStr,KPlz, KOrt)
KNrAutomatisierung derRechnungsstellung,Typische Rechnungsieht wie folgt aus:.........................................
Artikel ( ,ABez, APreis)
ANr
KonzeptuellesDatenmodell
Datenstruktur entwerfen und implementieren
RelationalesDatenmodell
InternesDatenbank-
modell
NormalisierungDatenmodellierung135
5.3 Vorgehen bei der Datenmodellierung: Exkurs Datenbanksystem
136
5.4 ERM - Entity Relationship Modeling
ERM - Entity Relationship Modeling
ERM - Anwendungsbereiche
�
�
�
�
1976 von Peter Chen vorgestellt
Semantische Datenmodelle
In ERM (Entity-Relationship-Modellen) werden permanent zu speichernde Datenund ihre Beziehungen modelliert.
Keine Berücksichtigung von Datenflüssen, Organisationsstrukturen, Funktionen
� Allgemeiner Ansatz, um Datenmodelle zuentwerfen
Unabhängig vom anvisierten Datenbanksystem(klassisch, relational)
�
�
�
Das “WAS” eines Systems steht im Vordergrund,nicht das “WIE”.
IKS-Entwicklung: Grobentwurf, Fach- undSystemkonzeption
137
5.4 ERM - Entity Relationship Modeling
Entw
ickl
ungse
benen
Situations-studie
Fach-konzeption
System-konzeption
System-entwicklung
System-installation
Zeit
Meilen-stein
1
Situations-studie
Validierung
Meilen-stein
2
Fachkon-zeption
Validierung
Meilen-stein
3
System-konzep-tion
Validierung
Meilen-stein
4
System-entwick-lung
Validierung
Meilen-stein
5
System-installa-tion
Validierung
Anwendungsfelder ERM
138
5.4 ERM - Entity Relationship Modeling
erteilt
Entitätsmenge
Attribut
Leihdatum
Kunde Leihwagenbucht1 n
ERM -Darstellungs-
elemente(klassisch)
Preis
Dauer
�
�
�
�
Entitätsmengen
Relationen
Attribute
Kardinalitäten
139
5.4 ERM - Entity Relationship Modeling: Entität
Entitätsmenge
�
�
�
�
�
�
�
Entitätsmenge, Entity Set, Entitätstyp, Objekttyp
Eine Entitätsmenge enthält Entitäten (Ausprägungen)
Entität: Individuelles, identifizierbares Exemplar von Dingen, Personen, Begriffender realen oder Vorstellungswelt; wird durch Eigenschaften beschrieben.
Entitätsmenge: Zusammenfassung von Entitäten mit gleichen Eigenschaftenunter einem gemeinsamen Oberbegriff
Symbol: Rechteck
Beschriftung: Substantiv (Singular)
Bsp: Kunde = Entitätsmenge / Müller, Meier, Schmidt ... = Entitäten
Entitätsmenge
140
5.4 ERM - Entity Relationship Modeling: Attribut
Attribut
�
�
�
�
(Beschreibendes) Attribut, Property
Fachliche Eigenschaft, die allen Entitäten einer Entitätsmenge gemeinsam ist.
Symbol: Oval
Beschriftung: Substantiv (Singular)
Name
Kunde
Adresse
Telefon
141
5.4 ERM - Entity Relationship Modeling: Schlüsselattribut
Identifizierendes Attribut: “Schlüssel”
�
�
�
�
�
�
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
Name
Kunden-Nr.
Kunde
Adresse
Telefon
142
5.4 ERM - Entity Relationship Modeling: Relation
Relation, Beziehungstyp
�
�
�
�
�
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 inVerbindung stehen.
Zum Beziehungstyp gehört die Kardianlität (s. ff.)
Leihdatum
Kunde Leihwagenbucht1 n
Preis
Dauer
143
5.4 ERM - Entity Relationship Modeling: Kardinalität
Kardinalität
�
�
�
�
�
�
�
�
Kardinalität, Komplexitätsgrad
Gibt an, mit wieviel A-Entitäten eine B-Entität in Verbindung stehen kann.
Symbol: Jeweils an den verbundenen Entitäten1 : 1 oder1 : n odern : m
Symbolplazierungen sollten modellweit in der gleichen Leserichtung erfolgen.
Entscheidend für die Kardinalität eines Beziehungstyps sind die fachlichenGegebenheiten im Zusammenhang mit den zu verbindenden Entitätsmengen.
Bsp.: Studenten müssen mehrere Klausuren schreiben und an jeder Klausurnehmen mehrere Studenten teil.
Bsp.: Ein Bibliotheksbenutzer leiht mehrere Bücher aus und ein Buch kann vonmehreren Benutzern ausgeliehen worden sein (hintereinander).
Häufig: Zeitpunkt-/Zeitraumbetrachtungsproblem
144
heiratet
kauft
besucht
• - Ein Student kannmehrere Seminarebesuchen. Ein Seminarwird von mehrerenStudenten besucht (i. d. R.).
n:m
• - Ein Kunde kannmehrere PKWs kaufen.Ein PKW wird immer vongenau einem Kundengekauft.
1:n
• 1:1 - Ein Mann heirateteine Frau. Eine Frauheiratet einen Mann.
Mann
Kunde
Student
1
1
n
1
n
m
Frau
PKW
Seminar
5.4 ERM - Entity Relationship Modeling: Kardinalität
145
Eingang
Artikelbez.
Auftrag Positionbestehtaus
1 n
Einzelpreis
Kunden-Nr. Menge
�
�
Ein Auftrag besteht aus einer oder mehreren Auftragspositionen.
Eine Auftragsposition gehört immer zu genau einem Auftrag.
5.4 ERM - Entity Relationship Modeling: Kardinalität
146
Adresse
Bezeichnung
Produkt Lagerliegtn m
Gewicht
LeiterFarbe
�
�
�
Ein bestimmtes Produkt kann sowohl im Lager Mainz als auch im Lager Triervorgehalten werden.
Hier fachlich gegeben: In einem bestimmten Lager können immer mehrereProduktarten vorgehalten werden.
1 Lager mit genau einer Produktart müßte mit 1:1 modelliert sein.
5.4 ERM - Entity Relationship Modeling: Kardinalität
147
Entleihdatum
Firmen-Kunde
Leihwagenleiht1 n
Rückgabe am
Preis
�
�
�
�
Zu modellieren ist: Wer hat einen bestimmten Wagen zur Zeit geliehen?
Ein Firmenkunde hat in einem bestimmten Zeitraum keinen, einen oder mehrereWagen für seine Mitarbeiter ausgeliehen.
Ein Wagen ist zu einem bestimmten Zeitraum genau an einen Kunden verliehen.
Kann nicht beantworten: Wer hatte wann welchen Wagen geliehen?
5.4 ERM - Entity Relationship Modeling: Kardinalität
148
Farbe
FabrikatName
Leihwagenleihtn m
Adresse
LaufleistungBonität
�
�
�
Zu modellieren ist: Welche Kunden hatten wann welche Wagen gemietet?Welche Kunden hatten bereits den Wagen “X” gemietet?
Ein Wagen wird in seiner Nuzungszeit an viele Kunden verliehen.
Ein Kunde kann einen oder mehrere Wagen leihen.
Firmen-Kunde
5.4 ERM - Entity Relationship Modeling: Kardinalität
•
•
•
•
Die (1,n,m)-Notationder Komplexität kanndurch die (min, max)-Notation präzisiertwerden.
die mindestenserforderliche Anzahlvon Beziehungen
die maximalzulässige Anzahl vonBeziehungen
Zur Besetzung dermin- und max-Posi-tion werden 0, 1, *(viele) oder genaueZahlenangabenverwendet.
min:
max:
• 1 Mann kann maximal 1 Frau heiraten und umgekehrt. Nicht jederMann oder jede Frau muß heiraten.
• Genau 1 Kunde kann entweder beliebige viele oder null PKWskaufen. Jeder PKW wird von genau einem Kunden gekauft oder istnoch nicht verkauft.
Mann
Kunde
Student
heiratet
kauft
besucht
(0,1)
(1,1)
(2,20)
(0,1)
(0,*)
(3,*)
Frau
PKW
Seminar
• Ein Seminar findet nur mit mindestens 2 und maximal 20 Studentenstatt. Jeder Student muß mindestens 3 Seminare besuchen; er kannbeliebig viele besuchen.
149
Komplexitäts-präzisierung
5.4 ERM - Entity Relationship Modeling: Kardinalität
MC-Notation
NumerischeNotation
Martin-Notation
Pfeil-Notation
Bachmann-Notation
C
1
MC
M
(0,1)
(1,1)
(0,n)
(1,n)
B
B
B B
BB
B
B B
B
A
A
A A
AA
A
A A
A
max.
max.
genau
genau
max.
max.
genaugenau
150
Kardinalität: Vielzahl von Notationsformen (Beispiele)
5.4 ERM - Entity Relationship Modeling: Kardinalität
151
Kardinalität
Merke:
Kardinalität immer von beiden Seiten betrachten.
Analyse nicht nach erstbester Interpretation abschließen.
�
�
�
�
�
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 ?
5.4 ERM - Entity Relationship Modeling: Kardinalität
152
5.4 ERM - Entity Relationship Modeling: Schwache Entitäten
Schwache Entitätsmengen
�
�
�
Schwache Entitätsmengen enthalten Entitäten, die nur in Abhängigkeit von eineranderen Entität existieren können.
Voll partiziperende vs. schwache Entitätsmenge
Symbol: Doppeltes Rechteck
Yacht-Eigner
Voll partizipierendeEntitätsmenge
SchwacheEntitätsmenge
Yachtbesitzt1 n
Yachteigner: YEigner_nr, YE_Name, YE_Bankverbindung
Yacht: YEigner_nr, Yacht_nr, Yacht_Name
153
5.4 ERM - Entity Relationship Modeling: Rekursive Beziehungen
Rekursive Beziehungstypen
� Entitätsmange steht mit sich selbst in Beziehung
Mitar-beiter
1
n
hat Personal-verantwor-
tung für
154
5.4 ERM - Entity Relationship Modeling: Beziehung “Aggregation”
Beziehungstyp “Aggregation”
�
�
ist-Teil-von / is-part-of / Über-Untergeordneten-Beziehung
Vererbt von Teilen auf Ganzes, von unten nach oben
Motor-rad
Teil von Teil von Teil von
Kolben
Kolben
Speichen
Speichen
Gabel
Gabel
Ventile
Ventile
Ventil
Ventil
Quertr.
Quertr.
Motor Felge Rahmen
155
Beziehungstyp “Generalisierung”
�
�
Attribute einer Entitätsmenge (subtype) sind einer übergeordneten Entitätsmenge(supertype) zuzuordnen (subtype relationship).
Vererbung vom Ganzen auf´s Spezielle, von oben nach unten
Kunde Mitarbeiter Lieferant
ist ein ist ein ist ein
Name
NameGeb.-Dat.
Geb.-Dat.
Person
5.4 ERM - Entity Relationship Modeling: Beziehung “Generalisierung”
156
Beispiel “Student - Klausur”
Problembereich
�
�
�
�
Ein Fachbereich besteht aus mehreren Abteilungen.
Jede Abteilung besteht aus mehreren Lehrstühlen.
Jeder Lehrstuhl bietet Klausuren an.
Studenten schreiben pro Lehrstuhl 1 Klausur.
� Mehrere Studenten nehmen an einer Klausur teil.Aber: 1 Student schreibt nur 1 Klausur?
5.4 ERM - Entity Relationship Modeling: Beziehung “Student - Klausur”
Student Klausur
Abteilung
Lehrstuhl
Fachbereich
1
1
n
n
157
5.4 ERM - Entity Relationship Modeling: Beispiel “Ruderboot”
ERM-Beispiel: Ruderboot-Vermietung
�
�
�
�
�
Ein Ruderverein hat Mitglieder, die ihre (Ein-Mann-) Ruderboote anvereinsexterne Hobbysportler vermieten.
Ein Vereinsmitgleid kann mehrere Boote besitzen und anbieten.
Die Vermietung bezieht sich immer auf das Abfahren einer vorgegebenen(sicheren) Ruder-Tour. Diese Tour ist Bestandteil des Mietvertrags.
Der Mieter kann sich sein Boot nach Gewicht und Farbe aussuchen.
Für jede Tour gibt es eine festgelegte Anzahl an Rudermeilen. Am Jahresendebekommen alle Hobbysportler mit mehr als 100 Rudermeilen ein Geschenk.
158
wird vereinbart in
umfaßtschließt
gehört
TourTour_nr
ZielRudermeilen
BootsbesitzerBB_Nr
BB_NachnameBB_VornameBB_Telefon
MietvertragMietvertragnr
Datum
RuderbootBoot_Name
FarbeGewicht
RudervereinVereins_Nr
Verein_NameV_Telefon_Nr
HobbysportlerKunden_Nr
NachnameVorname
Starke EM
Schwache EM
Identifiz. 1:N Bzt.
Nicht- ident. 1:N Bzt.
5.4 ERM - Entity Relationship Modeling: Beispiel “Ruderboot”
159
wird vereinbart in
umfaßtschließt
gehört
TourTour_nr
ZielRudermeilen
BootsbesitzerBB_Nr
BB_NachnameBB_VornameBB_Telefon
MietvertragMietvertragnr
Datum
RuderbootBoot_Name
FarbeGewicht
RudervereinVereins_Nr
Verein_NameV_Telefon_Nr
HobbysportlerKunden_Nr
NachnameVorname
�
�
Jeder Vertrag isteindeutig einemMieter zugeordnet.
Jedem Vertrag isteindeutig eineTour mit best.Rudermeilenzugeordnet.
5.4 ERM - Entity Relationship Modeling: Beispiel “Ruderboot”
160
�
�
�
In der Mitsegler-Agentur Windei GmbH werden Yachteignern Teilnehmer anSegeltörns vermittelt. Einem Eigner können mehrere Yachten gehören, währendeine Yacht nur einem Eigentümer gehört. Jeder Törn findet mit einemfestgelegten Start- und Endedatum statt.
Jede Jacht kann während der Saison für mehrere Törns verplant werden. JederTörn hat genau ein Reiseziel, das aber von mehreren Törns angelaufen werdenkann. Der Preis des Törns ist abhängig vom Reiseziel und von der Yacht.
Jeder Mitsegler kann während der Saison an mehreren Törns teilnehmen. Erschließt dazu für jeden Törn einen Vertrag mit dem betreffenden Yachteigner.
� [Zusatz, nicht zu modellieren: Es ist auchmöglich, daß sich mehrere Segler zueiner Gruppe zusammenschließen undgemeinsam einen Vertrag mit dem Eignerabschließen.]
5.4 ERM - Entity Relationship Modeling: Beispiel “Segeltörn”
ERM-Beispiel: Segeltörn-Vermittlung
161
5.4 ERM - Entity Relationship Modeling: Beispiel “Segeltörn”
KundeVertrag_TörnYachteigner
ReisezielTörnYachteingeplant für
findet statt mit
fährt nach
wird angefahren von
schließt abschließt ab
ge
bu
cht
in
ab
ge
sch
loss
en
für
be
sitz
t
ERM-Beispiel: Segeltörn-Vermittlung
162
5.4 ERM - Entity Relationship Modeling: Beispiel “Segeltörn”
wird eingeplant für /findet statt mit
wird gebucht in /für
schließt schl ießt
fährt zu /wird angefahren von
besitzt
Vertrag_Törn
Yachteigner_nr (FK)
Vertrag_nr
Törn_nr (FK)
PreisVersicherungsschutzSonderleistungen
Reiseziel
Reiseziel_nr
InselnameHafenBeschreibungSandstrandKlimaMeilenPreiskategorie
Kunde
Kunden_nr
Name_kdAdresse_KdGeburtstagKundenklasseWerbung_erwünscht
Törn
Törn_nr
Yacht_nr (FK)Yachteigner_nr (FK)
DauerMittagessenKomfortklasseReiseziel_nr (FK)StartdatumEndedatum
Yacht
Yacht_nrYachteigner_nr (FK)
Yacht_NameBaujahrModellFarbeMax_teilnehmerMotorY_Preiskategorie
Yachteigner
Yachteigner_nr
Name_YEAdresse_YESchiffscheinErf ahrungKontoverbindung
163
5.4 ERM - Entity Relationship Modeling: Tool “ERWin”
ERWin: Datenmodellierungs- und Data-Base-Design-Tool
�
�
�
�
�
�
�
�
�
�
Ziel: Modell in physische, relationale Datenbanken umsetzen
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)
Auslesen und analysieren bestehender Datenbanken (reverse 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 vonGeschäftsprozessen
ERWin-Modell-Input für die wichtigsten Datenbanksysteme: DB2, Informix,Ingres, Oracle, Progess, SQL-Server, Sybase, MS Access, Clipper, dBase,Foxpro, Paradox, ......
164
Konzeptuelles Schema(logische Ebene)
Konzeptuelles Schema(sem. Datenmodell)
RelationenmodellRelationenmodell
Internes/physischesSchema
Internes/physischesSchema
ERWin: Erstellen “logical” und “physical modell”
�
�
�
�
�
�
Érstellen von Entitätsmengen
Erstellen von Relationstypen
Konkretisierung vonKardinalitäten (auch n:m)
Hinzufügen von Attributen(ohne Datentypen)
Hinterlegung vonInformationen zu Attributen
Logical Model
�
�
�
ERWin löst n:m-Beziehungen auf
Konkretisierung derDatentypen
Physical Model
�
�
Ziel-DBMS angeben
Generierung perKnopfdruck
5.4 ERM - Entity Relationship Modeling: Tool “ERWin”
165
ERWin: Logical Model(konzeptionelles)
5.4 ERM - Entity Relationship Modeling: Tool “ERWin”
166
ERWin:PhysicalModel
(Relationen-schema,normalisiert)
5.4 ERM - Entity Relationship Modeling: Tool “ERWin”
Anwendungs-problem
FakturierungPC-Händler
verbal,textuell,visuell
formal,vollständig,graphisch
Namen, Attri-bute,Keys,Werte, ...
DDL/SQL:create data-base, table
z. B. alsER-Modell
Menge vonRelationen-schemata
Phys. Daten-organisation
z. B. Oracle
Kunde ( ,KName, KStr,KPlz, KOrt)
KNrAutomatisierung derRechnungsstellung,Typische Rechnungsieht wie folgt aus:.........................................
Artikel ( ,ABez, APreis)
ANr
KonzeptuellesDatenmodell
Datenstruktur entwerfen und implementieren
RelationalesDatenmodell
InternesDatenbank-
modell
NormalisierungDatenmodellierung167
5.4 ERM - Entity Relationship Modeling: Exkurs “Normalisierung”
168
5.4 ERM - Entity Relationship Modeling: Exkurs “Normalisierung”
Datenbankentwurf und Normalisierung
Der Normalisierungsprozeß
�
�
�
Jede Relation repräsentiert nur eine sachliche Bedeutungseinheit.
Daten sollen redundanzfrei gespeichert werden.
Der Normalisierungsprozeß soll dies sicherstellen.
�
�
�
Relationenschemata prüfen und ggfs. ohne Informationsverlust inmehrere Basis-Relationenschemata zerlegen
Normalerweise: „Normalisierende“ Nachbearbeitung eines ERM
Nachfolgend: Vorbereitung Unnormalisiert 1. 2. 3. NF
169
5.4 ERM - Entity Relationship Modeling: Exkurs “Normalisierung”
Tabellarische Zusammenstellung relevanter Daten und Beispielrechnungen
ReDat KNr
55128
5513155131
5511655131
KStr KPlz KOrt ANr ABez AMeAPreis
543
123379
224123
125120300200930250200310
198,00999,00248,00448,00110,00598,00448,00799,00
41113121
ZIP-100PC-800CD-300DVD-10HUB-20HDD-40DVD-10SCA-63
002
003004
005006
12.05.00
12.05.0013.05.00
13.05.0013.05.00
ReNr
Meier
KrauseSchulze
MeierKrause
A-Weg 5
B-Straße 8C-Allee 4
D-Platz 3B-Straße 8
KName
Mainz
MainzMainz
MainzMainz
Beispiel “ Rechnungstellung an Kunden eines PC-Händlers”
�
�
�
Beschreibung des Problems bekannt, kein ER-Modell vorhanden
Zusammenstellung aller relevanten Daten mit Beispielrechnungen
Tabellarische Gesamtsicht als Vorbereitung für Normalisierung
170
5.4 ERM - Entity Relationship Modeling: Exkurs “Normalisierung”
Daten nach Hauptkriterien ordnen: Unnormalisierte Relationen
�
�
�
�
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”
Kunden-Daten
Artikel-DatenRechnungs-Daten
KNr
55131551165513155128
KStr KPlz KOrt
ANrKNr ANr AMeReNr ReDat
ABez APreis
123224379543
120125200250300310930
543
123379
224123
120125300200250930200310
14111321
002
003004
005006
12.05.00
12.05.0013.05.00
13.05.0013.05.00
999,00198,00448,00598,00248,00799,00110,00
PC-800
DVD-10HDD-40
SCA-63
ZIP-100
CD-300
HUB-20
KrauseMeierSchulzeMeier
B-Straße 8D-Platz 3C-Alle 4A-Weg 5
KName
MainzMainzMainzMainz
171
5.4 ERM - Entity Relationship Modeling: Exkurs “Normalisierung”
Von der unnormalisierten zur 1. Normalform
�
�
1. NF: Wiederholungsgruppen beseitigt / nur einwertige, elementare Felder
Datensatz-Identifikation nun nur über komb. Primärschlüssel “ReNr + ANr”
Rechnungs-Daten
Wiederholungsgruppen !
Mehrwertige Zellen (Felder)
Wiederholungsgruppen durch
“Auffüllen” zu einwertigen Feldern
Unnormalisiert: 5 Datensätze 1. Normalform: 8 Datensätze
KNrReNr ReDat
543
123379
224123
002
003004
005006
12.05.00
12.05.0013.05.00
13.05.0013.05.00
Rechnungs-Daten
KNrReNr ReDat
543543123379379379224123
002002003004004004005006
12.05.0012.05.0012.05.0013.05.0013.05.0013.05.0013.05.0013.05.00
ANr AMe
120125300200250930200310
14111321
ANr AMe
120125300200250930200310
14111321
172
5.4 ERM - Entity Relationship Modeling: Exkurs “Normalisierung”
Vorüberlegungen für die 2. Normalform
�
�
Redundanzerhöhung, da einige Nichtschlüsselattribute nur von einem Teil deskombinierten Primärschlüssel abhängig sind (”funktional abhängig”).
Siehe bspw. 2. Datensatz: Für die Rechnungsposition mit der ANr 125 müssenReDat und KNr nicht eigens nochmal gespeichert werden, da beideInformationen eindeutig über die ReNr bestimmt sind.
1. Normalform: Rechnungs-Daten
KNrReNr ReDat ANr AMe
120125300200250930200310
14111321
543543123379379379224123
002002003004004004005006
12.05.0012.05.0012.05.0013.05.0013.05.0013.05.0013.05.0013.05.00
Redundante Mehrfacheinträge
in ReDat und KNr
173
5.4 ERM - Entity Relationship Modeling: Exkurs “Normalisierung”
Von der 1. Normalform zur 2. Normalform
�
�
2. NF: In 1. NF und alle Nichtschlüsselattribute sind vom Primärschlüssel nichtnur “funktional abhängig”, sondern “voll funktional abhängig”.
Zerlegen in 2NF-Relationen mit “voll funktionaler Abhängigkeit”
Die Attribute, die vom kombinierten
Schlüssel “ReNr+ANr” voll abhängig sind.
Auslagerung der Attribute, die
nur vom Primärschlüssel
“ReNr” voll abhängig sind.
Neue Relation in 2. Normalform Weitere neue Relation in 2. Normalform
Rechn.-PositionenRechnungs-Köpfe
KNr ReNrReNr ReDat
543123379224123
002002003004004004005006
002003004005006
12.05.0012.05.0013.05.0013.05.0013.05.00
ANr AMe
120125300200250930200310
14111321
174
5.4 ERM - Entity Relationship Modeling: Exkurs “Normalisierung”
Vorüberlegungen für die 3. Normalform
�
�
�
�
�
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
Kunden-Daten
KNrKNr
KNr
55131551165513155128
KStr KPlzKPlz
KPlz
KOrtKOrt
KOrt
123224379543
KrauseMeierSchulzeMeier
B-Straße 8D-Platz 3C-Alle 4A-Weg 5
KName
MainzMainzMainzMainz
Redundanz: Postleitzahl desWohnorts von Krause und Schulze
doppelt enthalten
Transitive Abhängigkeit
Keine Umkehrung
2. NormalformNur voll funktionale Abhängigkeiten
(da nur ein einziges Schlüsselattribut)
175
5.4 ERM - Entity Relationship Modeling: Exkurs “Normalisierung”
Von der 2. Normalform zur 3. Normalform
�
�
�
3. NF: In 2. NF und kein Nichtschlüsselattribut ist vom Primärschlüssel transitivabhängig.
Zerlegen in 3NF-Relationen ohne transitive Abhängigkeiten
Funktional abhängige Nichtschlüsselattribute auslagern
Kunden-Daten
KNr
55131551165513155128
KStr KPlz
123224379543
KrauseMeierSchulzeMeier
B-Straße 8D-Platz 3C-Alle 4A-Weg 5
KName
Neue Relation in 3. Normalform
“Alte” Tabelle ohne KOrt;KPlz wird zum Fremdschlüssel
KPlz wird zumPrimärschlüssel
Orts-Daten
551165512855131
KPlz KOrt
MainzMainzMainz
Weitere neue Relationin 3. Normalform
176
5.4 ERM - Entity Relationship Modeling: Exkurs “Normalisierung”
Die Basis-Relationenschemata in 3. Normalform
Kunden-Daten
KNr
55131551165513155128
KStr KPlz
123224379543
KrauseMeierSchulzeMeier
B-Straße 8D-Platz 3C-Alle 4A-Weg 5
KName
Orts-Daten
551165512855131
KPlz KOrt
MainzMainzMainz
Rechnungs-Köpfe
KNrReNr ReDat
543123379224123
002003004005006
12.05.0012.05.0013.05.0013.05.0013.05.00
Rechn.-Positionen
ReNr
002002003004004004005006
ANr AMe
120125300200250930200310
14111321
Artikel-Daten
ANr ABez APreis
120125200250300310930
999,00198,00448,00598,00248,00799,00110,00
PC-800
DVD-10HDD-40
SCA-63
ZIP-100
CD-300
HUB-20
Kunden (KNr, KName, KStr, KPlz)
Orte (KPlz, KOrt)
Artikel (ANr, ABez, APreis)
Rechnungsköpfe (ReNr, ReDat, KNr)
Rechnungspositionen (ReNr, ANr, AMe)
Kunden (KNr, KName, KStr, KPlz)
Orte (KPlz, KOrt)
Artikel (ANr, ABez, APreis)
Rechnungsköpfe (ReNr, ReDat, KNr)
Rechnungspositionen (ReNr, ANr, AMe)
177
5.4 ERM - Entity Relationship Modeling: Exkurs “Normalisierung”
Positive Anmerkungen zur Normalisierung
Alle Datenstrukturierungsprobleme gelöst ?
�
�
�
Redundanzen in den Tabellen sind beseitigt
Dabei keine Verluste von Informationen oder Abhängigkeiten
”One fact in one place”: Änderungsfreundlichkeit, Konsistenz
�
�
�
�
�
�
�
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
178
1 Struktur und Ziele der Vorlesung
2 Grundlagen der Modellierung von IKS
3 Funktionsorientierte Modellierung
4 Datenflußorientierte Modellierung
5 Datenorientierte Modellierung
6
7 Prozeßmodellierung mit ARIS
Objektorientierte Modellierung
Gliederung
Systems Engineering - Modellierung von IuK-Systemen
Wirtschaftsinformatik - Wintersemester 09/10
179
6.1 Zum Paradigma der Objektorientierung: Aufsetzpunkte
Aufsetzpunkte der objektorientierten Entwicklung
Funktionen
Daten
Organisation ?
Steuerung ?
Integration ?
�
�
�
Konkurrierender Ansatz zur funktionsorientierten und datenorientiertenEntwicklung von Anwendungssystemen
Funktions- und Datenorientierung sind relativ eigenständige Komplemente derSystementwicklung, die sich in der Entwicklungssequenz stark auf die System-Analyse und den System-Entwurf konzentrieren.
Funktions- und Datenorientierung priorisieren und kombinieren sich je selbst mitdem je anderen Ansatz, um die relevanten Systemelemente (Gegenstände,Abläufe) abzudecken. Probleme: Organisation, Steuerung, Integration
Funktion
Unter-funktion
Unter-funktion
Unter-funktion
Elementar-funktion
Elementar-funktion
Elementar-funktion Student Klausur
Abteilung
Lehrstuhl
Fachbereich
1
2
3
OOA-Modellnach
Coad/Yourdon
Sachgebiete:
1: Auftraggeber2: Auftrag3: Mitarbeiter
180
6.1 Zum Paradigma der Objektorientierung: Beispiel OOA-Modell
Sparkonto
Privatkunde
Geburtsdatum
Firmenkunde
Name des AnsprechpartnersAnrede des Ansprechpartners
1..*
Buchung
DatumWährungBetragArtBLZVerwendungszweck
stornieren ()ist storniert ()
# Anzahl Buchungenpro Quartal ()
# berechneQuartalsumsatz ()
1
Kundenbetreuer
NamePersonalnummer
berechneQuartalsumsatz ()
1..*1
Kunde (abstrakt)
NameAdresse
drucke Adresse ()berechne Quartalsumsatz ()# erstelle Serienbrief ()
11..*1..*
Konto (abstrakt)
NummerEröffnungsdatumSaldoZinssatz 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()
1
1
..*
11..*
Girokonto
berechneKontoführungsgebühr ()
181
6.1 Zum Paradigma der Objektorientierung: Beispiel OO mit UML
OO-Modellin UML
182
6.1 Zum Paradigma der Objektorientierung: Anliegen
Intentionen, Anliegen der OO: “Natürlichkeit, Verständlichkeit” (?)
�
�
�
�
�
Konsistente (durchgängige) Integration der zu modellierenden Systemelemente
Ganzheitliche Systementwicklung mit Durchgängigkeit über System-Analyse,System-Entwurf und System-Implementierung
Konzentration auf Entitäten (Objekte) und Priorisierung dessen, was ein Objektist, weniger wie es verwendet wird. Demnach hat die Datenstruktur ein größeresGewicht als die Funktionsstruktur.
Objektorientiert modelliert/entwickelte Systeme besitzen angeblich folgendebesondere Eigenschaften im Vgl. zu Systemen, die nach dem tradiertenfunktionsorientierten Paradigma entwickelt wurden:
- Verkürzung der Entwicklungszeiten- Niedrigere Entwicklungskosten- 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
.... etc. pp.: “Alles wird gut!” (Man muß nur dran glauben.)
OOOO
ohmmm
ohmm
183
6.1 Zum Paradigma der Objektorientierung
Entw
ickl
ungse
benen
Situations-studie
Fach-konzeption
System-konzeption
System-entwicklung
System-pflege
Zeit
Meilen-stein
1
Situations-studie
Validierung
Meilen-stein
2
Fachkon-zeption
Validierung
Meilen-stein
3
System-konzep-tion
Validierung
Meilen-stein
4
System-entwick-lung
Validierung
Meilen-stein
5
System-installa-tion
Validierung
Anwendungsfelder OO-Methoden (Anspruch!)
184
6.1 Zum Paradigma der Objektorientierung: Chronologie
Chronologie: OO-Entwicklung/-Programmierung/-Codierung
Chronologie: OO-Entwurf/-Design/-Konzeption
�
�
�
�
�
Von der Programmierung (Entwicklung, Implementierung, 70er) über Entwurf(Systemkonzeption, 80er) zur Analyse (Fachkonzeption, Situationsanalyse, 90er)
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.)
�
�
�
�
�
Ausrichtung der Systemkonzeption (Design, Entwurf)nach den Grundgedanken der Objektorientierung(nicht mehr nach der Funktions-/Prozedur-Orientierung)
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
70er Jahre:
OO-Codierung
80er Jahre:
OO-Design
90er Jahre:
OO-Analyse
185
Chronologie: OO-Analyse / Fachkonzeption
�
�
�
�
�
�
�
�
�
In den 90er Jahren erst OO-Ausrichtung auch der frühen Phasen der Situations-analyse und Fachkonzeption (auch “Fachentwurf” genannt)
Damit hatte sich das OO-Pardigma bottom-up von der Programmierung her biszur fachlichen Planung eines Systems auf den gesamten Entwicklungsprozeßausgedehnt.
1988: Shlaer und Mellor mit “OO Systems Analysis”
1990: Coad und Yourdon mit “OOA”
1991: “Booch”
1995: Mehr als 40 Analysemethoden, die den Anspruch erheben “oo” zu sein
1995: Unified Method nach Booch/Rumbaugh
1996: Unified Modeling Language (UML 0.91) nach Booch/Rumbaugh/Jacobsen
nach Booch und “OMT” nach Rumbaugh
1992: OOSE nach Jacobsen
90er Jahre:
OO-Analyse
6.1 Zum Paradigma der Objektorientierung: Chronologie
186
6.1 Zum Paradigma der Objektorientierung: Ziele
Ziele der Objektorientierung
�
�
�
Warum ein neues Paradigma mit neuenMethoden, Techniken, Tools?
Immer größere und kompliziertereSoftwarepropjekte scheitern amtraditionellen Instrumentarium derSoftwareentwicklung.
Projekte dauern zu lange, sind zu teuer,erfüllen nicht die an sie gestelltenAnforderungen.
187
6.1 Zum Paradigma der Objektorientierung: Ziele
Ziele der Objektorientierung
Wiederverwendbarkeit / Modularität
Durchgängigkeit Verständlichkeit
Fehler,Kosten,
Komplexität,Entwicklungszeit
reduzieren
Durch Objekt- undKlassenbildung
Orientierung am“Menschen”
... der Methoden vonAnalyse bis Codierung
188
6.2 Grundelemente der Objektorientierung: Überblick
Die Grundelemente der Objektorientierung im Überblick
- Objektbildung
- Kapselung
- Klassenbildung
- Assoziationen
- Vererbung
- Nachrichtenaustausch
- Polymorphismus
�
�
�
Je nach Autor werden bestimmte Konstrukte aus der Welt der Objektorientierungals grundlegende “Elemente”, “Konzepte”, “Prinzipien” o. ä. herausgestellt.
Weder die Bezeichungen dieser Konstrukte noch deren Auswahl undZusammenstellung ist einheitlich.
Nachfolgend werden die wichtigsten dieser Konstrukte erläutert, die einenÜberblick zur Objektorientierung im allgemeinen geben.
189
6.2 Grundelemente der Objektorientierung: Objektbildung
Objektbildung: Was bedeutet “objektorientiert”?
Objektbildung: Was ist ein “Objekt”?
� Grob: Ein System ist eine Ansammlung unterscheidbarer Objekte, die sowohleine Datenstruktur als auch ein bestimmtes Verhalten in sich vereinen.
�
�
�
�
Ein Objekt ist ein Gegenstand des Interesses, inbesondere einer Betrachtung,Untersuchung oder Messung.
Objekte können gegenständliche Dinge oder Begriffe (künstlich) sein.
Ein Objekt hat Eigenschaften (Attribute).
Ein Objekt hat gleichzeitig ein Verhalten. Dieses Verhalten wird durchOperationen (Methoden) ausgedrückt.
Objekt:Elsa Euter
Attribute:- Farbe (weiß)- Beine (4)- Milchmenge (15)
Operationen:- Melken- Füttern- Fortpflanzen
190
Objektbildung: Eine Tür wird beschrieben durch ....
.... Attribute:
.... Operationen:
- Größe
- Farbe
- Material
- Öffnen
- Schließen
6.2 Grundelemente der Objektorientierung: Objektbildung
191
Objektbildung: Jedes Objekt hat eine eindeutige Identität
Objekt: Tür
Objekt: Schlüssel
Objekt: Haus
Objekt: Vera Vollmilch
6.2 Grundelemente der Objektorientierung: Objektbildung
192
6.2 Grundelemente der Objektorientierung: Kapselung
Was bedeutet “Kapselung”?
�
�
�
�
Auf die Attributwerte eines Objektes kann nur das Objekt selbst zugreifen.
Zugriff nur über die Operationen des betreffenden Objektes.
Ein Objekt “verbirgt“ (kapselt) seine Attribute in sich und gibt nur bekannt, welcheOperationen von ihm zur Verfügung stehen.
Verhinderung unkontrollierter Datenmanipulationen durch Realisierung des“Geheimnisprinzips”
Objekt: Anja Alm
Anja Alms Milchproduktion?
Allein ihre Sache!!
193
6.2 Grundelemente der Objektorientierung: Klassenbildung
Was bedeutet “Klassenbildung”?
Objekte
Klasse
Vera Vollmilch Anja AlmElsa Euter
�
�
Eine Klasse beschreibt eine Menge von Objekten mit gleichen Eigenschaften,gemeinsamen Operationen, gemeinsamen Beziehungen zu anderen Objektenund gemeinsamer Semantik.
Eine Klasse ist somit ein “Bauplan” für bestimmte (reale) Objekte.
Kuh
194
6.2 Grundelemente der Objektorientierung: Klassenbildung
Klassenbildung: Darstellung von Klassen und Objekten
�
�
�
Strukturgleiche (Name, Attribute, Operationen), aber in Details unterschiedlicheDarstellungsformen je nach “OO-Guru”
Unten Notation in Anlehnung an Rumbaugh
UML aber z. B. ohne Liste der Operationen bei Objektdarstellung
:Kuh Elsa Euter : KuhExemplar vonInstanz vonInstance ofClass Instance
Klassenname
Liste derAttribute
Liste derOperationen
FarbeBeineMilchmenge
Farbe = weißBeine = 4Milchmenge = 15 [Liter]
Melken ()Füttern ()Fortpflanzen ()
Melken (Liter)Füttern (Kilo)Fortpflanzen (Kälber)
Darstellung Klasse Darstellung Objekt
195
6.1 Zum Paradigma der Objektorientierung6.2 Grundelemente der Objektorientierung: Assoziationen
Assoziationen: Beziehungen zwischen Objekten
“Objektdiagramm”
�
�
�
Beziehungen zwischen Objekten (gleichgeordneter) Klassen
Werden durch einfache Linien dargestellt (bi-/unidirektional).
Nach Möglichkeit werden Assoziationen durch Namen, Kardinalitätsangabenund/oder Rollennamen beschrieben.
: Kunde
: Kundenbetreuer : Rechnung
: Auftrag
erteilt
hat
1
n
1
n 1
1
n
m
gehört zuverantwortlich für
Name = MeierStatus = aktiveMail = [email protected]
Name = MüllerPersnr = P-987654321Branche = Maschinenbau
Nummer = R-232323Betrag = 300.000 [DM]Zahlungsart = Bar
Nummer = A-12345Datum = 15. Mai 2001Wert = 200.000 [DM]
196
Spezielle Assoziation: Aggregation
�
�
�
Aggregation: Ganzes-Teile-Beziehung zwischen Objekten
Die Objekte sind dabei nicht gleichberechtigt; eine der beteiligten Klassen hateine führende Rolle.
Hier: Fahrrad besteht aus Rahmen und Bremsen (u. a.).
: Fahrrad
: Rahmen : Bremse
1
1 n
1
hathat
Bezeichung = BerglustArtikelnr = AR-1245Kategorie = Mountainbike
Bezeichnung = LonglastRahmennr = R-9987Material = Aluminium
Bezeichnung = LX-20Hersteller = HerculesKategorie = Handbremse
Bauteil
besteht aus
0..*
0..*
6.2 Grundelemente der Objektorientierung: Assoziationen
197
6.2 Grundelemente der Objektorientierung: Assoziationen
Spezielle Assoziation: Komposition
�
�
�
Komposition: spezielle Aggregation
Existenz der Teile hängt von Existenz des Ganzen ab.
Hier: Ohne Auftrag keine Positionen und keine Rechnung
: Auftrag
: Auftragsposition : Rechnung
1
1 n
1
gehört zuhat
Posnr = PO-98765Artikelnr = AR-1245Menge = 300
Nummer = A-12345Datum = 15. Mai 2001Wert = 200.000 [DM]
Nummer = R-232323Betrag = 300.000 [DM]Zahlungsart = Bar
198
6.2 Grundelemente der Objektorientierung: Vererbung
Vererbung: Beziehungen zwischen (Ober- und Unter-) Klassen
Bsp. “Taxonomie” (Einordnung in ein biologisches System)
�
�
Generalisierungs-/Spezialisierungsbeziehung zwischen den beteiligten Klassen
Vererbung: Beziehung zwischen allg. Ober- und spezialisierten Unterklassen
Insekten
Borstenschwänze
Zwei Flügelpaare
Beintastler
Ur-Insekten Flug-Insekten
Libellen
Springschwänze Ein Flügelpaar
199
Vererbung: Beziehungen zwischen (Ober- und Unter-) Klassen
.... oder ....
�
�
�
�
Vererbung (generalization) bedeutet, daß eine spezialisierte Klasse (Unterklasse,abgeleitete Klasse, subclass) über die Eigensschaften, das Verhalten und dieAssoziationen einer oder mehrerer allgemeiner Klassen (Oberklassen,Basisklassen, supperclasses) verfügen kann.
Eine Unterklasse ist vollständig konsistent mit ihrer Oberklasse, enthält aber i. d.R. zusätzliche Attribute, Operationen und/oder Assoziationen.
Jede Klasse “kennt” nur ihre eigenen
Die Vererbungsbeziehung wird durch einen Pfeil zur Oberklasse gekennzeichnet.
Attribute, Operationen und Assoziationendie ihrer Oberklassen(n), sofern diese für die Unterklasse sichtbar sind.
Für eine Oberklasse sind generell die Attribute, Operationen und Assoziationenihrer Unterklassen nicht sichtbar.
und
�
6.2 Grundelemente der Objektorientierung: Vererbung
200
6.2 Grundelemente der Objektorientierung: Vererbung
Vererbung: Abstrakte Klassen
�
�
�
Generalisierungs-/Spezialisierungs-beziehung zwischen den beteiligtenKlassen
Immer: Jedes Objekt der Unterklasse“ist ein” (is a) Objekt der Oberklasse.
Abstrakte Klassen werden nur modelliert,um ihre Informationen an spezialisierteKlassen zu vererben.
� Von einer abstraktenKlasse können keine(realen) Objekte erzeugtwerden. Im Bsp.: Es gibtkonkret nur Kunden undMitarbeiter, keine“Personen”.
: Kunde : Mitarbeiter
BrancheUmsatzStatus
AbteilungGehaltFamilienstand
ermittele durch-schnittl. Umsatz ()
erstelle Urlaubs-plan ()
: Person {abstract}
NameAdresseGeburtsdatum
drucke Adreß-aufkleber ()
201
6.2 Grundelemente der Objektorientierung: Vererbung
Vererbung: Einfachvererbung
�
�
Bei der “Einfachvererbung” hat jede Klasse genau 1 direkte Oberklasse (mitAusnahme der Wurzel).
Es entsteht eine Hierarchie in Form eines (umgedrehten) Baumes.
LKWPKWUnterklasse
Unterklasse
Oberklasse
KraftfahrzeugOberklasse (Wurzel)
SattelschlepperLimousine AufliegerCaravan
202
6.2 Grundelemente der Objektorientierung: Vererbung
Vererbung: Mehrfachvererbung
�
�
Bei der “Mehrfachvererbung” (multiple Vererbung) kann jede Klasse mehreredirekte Oberklassen haben (mit Ausnahme der Wurzel).
Problem: Eine Klasse kann z. B. zwei Attribute oder Operationen gleichenNamens von verschiedenen Oberklassen erben. Konfliktlösung erforderlich.
WasserfahrzeugLandfahrzeug
Fahrzeug
AmphibienFZPKW LKW Schiff
Unterklasse
Unterklasse
Oberklasse
Oberklasse (Wurzel)
203
6.2 Grundelemente der Objektorientierung: Nachrichtenaustausch
Nachrichtenaustausch: Grundlegendes
�
�
�
�
�
�
Die Funktionalität (das dynamische Verhalten) eines objektorientierten Systemsist in den Operationen seiner Objekte hinterlegt.
Die Realisierung dieser Funktionalität setzt voraus, daß die Operationenverkettet werden können.
Dazu müssen Beziehungen zwischen den beteiligten Objekten bestehen. DieObjekte müssen “sich kennen” (Vererbungsbeziehungen, Assoziationen).
Die Operationen der Objekte müssen “aufgerufen, initialisiert” werden.
Dies geschieht über “Botschaften” (Nachrichten) als “Operationsausführungs-anweisungen” zwischen den beteiligten Objekten.
Die Botschaft (message) trägt den Namen der Operation, die sie aufruft.
Objekt 1 : Klasse A Objekt 1 : Klasse B
Attribut 1 =Attribut 2 =
Attribut 1 =Attribut 2 =
Operation A1 ()Operation A2 ()
Operation B1 ()Operation B2 ()
Operation B1 ()
204
6.2 Grundelemente der Objektorientierung: Nachrichtenaustausch
Hans Müller : Mitarbeiter A-9876543 : Auftrag
Persnr = 1234567890Abteilung = VertriebFunktion = Sachbearbeiter
Anr = 98786543Datum = 12.10.2001Wert = 200.000 [DM]
Kunden kontaktieren ()Auftrag aufnehmen ()Auftrag betreuen ()
drucken ()ändern ()löschen ()
ändern ()
Nachrichtenaustausch: Polymorphismus
�
�
�
�
�
Der Empfänger interpretiert die Botschaft, führt seine Operation aus und schicktdas Ergebnis an den Sender zurück.
Der Sender weiß nicht, wie die Operation vom Empfänger ausgeführt wird.
Die Menge der Botschaften, auf die die Objekte einer Klasse reagieren können,wird als Protokoll der Klasse bezeichnet.
Polymorphismus: Bei der Versendung 1 Botschaft an Objekte verschiedenerKlassen können verschiedene Operationen mit verschiedenen Ergebnissenausgelöst werden.
Bspw. “drucken ()” gesendet an die Klassen “Auftrag” und “Buch”
205
Nachrichtenaustausch in einer Vererbungsstruktur
�
�
Erhält ein Objekt in einerVererbungsstruktur eine Botschaft,“sucht” es in der Liste seiner eigenenKlasse nach einer Operation, mit der esreagieren kann.
Findet das Objekt dort keine ausführbareOperation, wird die Suche in der direktenOberklasse fortgesetzt (usw.).
� Bsp.: Erhält das KundenobjektMüller die Botschaft “druckeAdreßaufkleber ()”, wird dieentsprechende Operation derdirekten Oberklasse “Person”ausgeführt.
6.2 Grundelemente der Objektorientierung: Nachrichtenaustausch
: Kunde : Mitarbeiter
BrancheUmsatzStatus
AbteilungGehaltFamilienstand
ermittele durch-schnittl. Umsatz ()
erstelle Urlaubs-plan ()
: Person {abstract}
NameAdresseGeburtsdatum
drucke Adreß-aufkleber ()
206
6.2 Grundelemente der Objektorientierung: Überblick
Die Grundelemente der Objektorientierung im Überblick
- Assoziationen
- Vererbung
- Nachrichtenaustausch
- Polymorphismus
- Objektbildung
- Kapselung
- Klassenbildung
� Die wichtigsten Konstrukte der OO wurden erläutert, um einen Überblick zurObjektorientierung im allgemeinen zu geben.
�
�
�
�
Autoren wie z. B. Coad/Yourdon (OOA), Rumbaugh (OMT), Jacobsen (OOSE)bündelten, erweiterten, variierten die grundlegenden Konstrukte in je eigenerWeise und verwendeten je eigene (graphische und textuelle) Darstellungsformen(Notationen) für ihre eigenen Methoden der objektorientierten Analyse/Entwurf.
Grob: Jeder Autor lieferte also je seine bestimmte Menge von Konzepten (was istwie darzustellen? = Ergebnissicht) und sein Vorgehensmodell zur Anwendungder Konzepte (in welchen Schritten wird was ausgeführt, um ein System zumodellieren? = Prozeßsicht).
Ergebnis 1: Verschiedene konkurrierende OO-Ansätze
Ergebnis 2: Bedürfnis nach Vereinheitlichung, Standardisierung der OO-Ansätze
207
6.3 Die Unified Modeling Language (UML): Entstehung
Chronologie zur Unified Modeling Language (UML)
Die UML hat sich inzwischen als die Standard-Notation
der Objektorientierung durchgesetzt.
�
�
�
�
�
�
�
�
�
�
�
1994: Rumbaugh wechselt zu Rational, wo bereits Booch arbeitet.
1995: Booch und Rumbaugh veröffentlichen “Unified Method”
1995: Rational kauft Objectory, wo Jacobsen arbeitet.
1995 - 1997: Booch, Rumbaugh, Jacobsen (”drei Amigos”) erarbeiten die UML
1996: UML Ver 0.91 wird veröffentlicht
1997: Die Object Management Group (OMG) standardisiert UML Ver 1.1
1998: UML Ver. 1.2 wird freigegeben
1999: UML Ver. 1.3 wird veröffentlicht
Nov. 2000: UML Ver. 1.4 als Betaversion veröffentlicht
Ende 2002: Im Auftrag der OMG wird an UML 2.0 gearbeitet
Maerz 2005: Freigabe der UML Version 2.0 durch die OMG
208
6.3 Die Unified Modeling Language (UML): Charakteristika
�
�
�
�
�
Vereinheitlichung historischer OO-Begriffe und -Notationen:
Unterstützung einer durchgängigen (einheitlichen) Methodik
Einheitliche Modellierung bei unterschiedlichen Einsatzgegebenheiten:
Vereinheitlichung bezgl. verschiedener Programmiersprachen undAblaufumgebungen:
Vereinheitlichung unterschiedlicher Modellierungsperspektiven:
Allgemeinakzeptierte Begriffsbildungen aus dem OO-Bereich zusammenführen
über alle Phasen derSystementwicklung: Nahtloser Übergang von Req. Eng. bis zur Implementierung
kleine,große, verteilte, Real-time, rechenintensive, datenintensive Systeme etc.
Identisches Front-End bei flexiblem Back-End
Daten-,Funktions-, Organisations-, Steuerungssicht; flexibel erweiterbar
Zur Bedeutung des Begriffs “Unified”
Die UML als die “eierlegende Wollmilchsau”
für die konzeptionelle System-Modellierung!?
209
6.3 Die Unified Modeling Language (UML): Charakteristika
�
�
�
�
�
Die UML ist keine Programmiersprache.
Die UML ist keine Methode zur Systementwicklung.
Die UML ist/hat kein Vorgehensmodell.
Die UML ist eine der Objektorientierung verpflichtete Technik.
Technik: Kollektion von Beschreibungsmitteln, Modellierungssprache
Was die UML ist und was sie nicht ist
“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.
NEIN
JA
210
6.3 Die Unified Modeling Language (UML): Charakteristika
�
�
�
�
�
Die UML stellt für die Grundelemente der Objektorientierung (siehe Abschnitt 6.2)UML-eigene Notationselemente zur Verfügung (Klasse, Assoziationen etc.)
Darüber hinaus verügt die UML über weitere Notationselemente, die aus denzugrundeliegenden OO-Methoden entstanden sind und möglichst alle Aspekteeines zu modellierenden Systems darstellen können sollen.
Die Notationselemente (die darzustellenden Aspekte) werden (häufig) “Konzepte”(engl.: Classifier) genannt.
Bei der Systemmodellierung werden aus jeweils bestimmten Notationselementenverschiedene Diagramme erzeugt (z. B. Klassen- oder Interaktionsdiagramm)
Jedes Diagramm verdeutlicht eine bestimmte Perspektive (Sicht) auf das zumodellierende System (z. B. Sicht des Systembenutzers, statische Sicht, Sichtder Abläufe, Sicht der Implementierungskomponenten etc.)
Wie “funktioniert” die UML?
Verschiedene Sichtenauf das zu mod. System
Menge vonNotationselementen
Verschiedene Diagramme
System
211
6.3 Die Unified Modeling Language (UML): Charakteristika
�
�
�
�
Die UML legt fest, welche Diagramme aus welchen Notationselementen gebildetwerden und welche Sichten mit den Diagrammen erzeugt werden.
Die UML liefert keinen Plan, in welcher Reihenfolge welche Diagramme erzeugtund weiterentwickelt werden sollen, um ein System schrittweise zu modellieren.
Es bleibt den Entwicklern überlassen, sich solche Vorgehensmodelle durch diepassende Zusammenstellung (”methodische Durchgängigkeit”) von Sichten,Diagrammen und Konzepten zu “bauen”.
Der Mangel an Vorschriften zur “Prozeßsicht der Systementwicklung” (sieheAbschnitt 2) ist gleichzeitig ein Vorzug der UML: Sie erlaubt (fordert auf),problemangepaßte Vorgehensmodelle zu entwickeln.
Wie “funktioniert” die Systemmodellierung mit der UML?
Analyse
Entwurf
Implement.
Menge vonNotationselementen
VerschiedeneDiagramme
VerschiedeneSichten
System
Vorg
ehens-
modell
?
212
�
�
�
�
�
Die UML hat nicht die verschiedenen OO-Analyse-Entwurfs-Methoden (OOA,OMT, OOSE etc.) zusammengeführt.
Die UML stellt lediglich eine standardisierte objektorientierte Modellierungsspra-che dar, die präziser und vollständiger ist als die Sprachen, die die o. g. OO-Methoden aufwiesen.
Die UML ist eine semi-formale Technik; sie dient zur Vereinheitlichung undStrukturierung prosaischer Formulierungen.
Die UML verfügt über eine Vielzahl vom Diagrammarten, mit denen dieGrundelemente der OO, eine Vielzahl deren Varianten und Erweiterungen sowiealle Phasen der Systementwicklung von der Analyse über den Entwurf bis zurImplementierung unterstützt werden.
Erst seit 1998 existiert mit “Rational Unified Process” ein Vorgehensmodell(Prozeßsicht) mit explizitem Bezug zur UML.
Charakteristika der UML
6.3 Die Unified Modeling Language (UML): Charakteristika
213
6.3 Die Unified Modeling Language (UML): Sichten, Diagramme, Konzepte
� Mit der UML können verschiedene Sichten auf ein (zu modellierendes) Systemmit bestimmten Diagrammarten (und Notationselementen) dargestellt werden.
Sichten, Diagrammarten und Konzepte in der UML
Sicht/Abstraktion
Statische
Dynamische
Systemnutzung
Interaktion
Prozeß
Implementierung
Einsatz
Klassen-
Zustands-
Anwendungsfall-
Sequenz-Kollaborations-
Aktivitäts-
Komponenten-
Einsatz-
Klasse, Assoziation, Attribut, Operation
Zustand, Ereignis, Transition, Aktion
Anwendungsfall, Akteur, Assoziation
Interaktion, Botschaft, AktivierungKollaboration, Interaktion, Botschaft
Zustand, Aktivität, Transition, ....
Komponente, Schnittstelle, Abhängigkeit
Knoten, Komponente, Abhängigkeit
Diagrammart Konzepte (Notationselemente)
214
� Hier die englischen Originalbegriffe; die vorgenannten deutschen Übersetzungenwerden nicht einheitlich verwendet.
UML: Views, Diagrams, Classifier (Concepts)
View
Static
Dynamic
User
Interaction
Process
Implementation
Deployment
Class ~
State Chart ~
Use Case ~
Sequence ~Collaboration ~
Activity ~
Component ~
Deployment ~
Class, Association, Attribute, Operation
State, Event, Transition, Action
Use Case, Actor, Association
Interaction, Message, ActivationCollaboration, Interaction, Message
State, Activity, Transition, Completion, ...
Component, Interface, Dependency
Node, Component, Dependency
Diagram Classifier (Concepts)
6.3 Die Unified Modeling Language (UML): Sichten, Diagramme, Konzepte
215
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiele
�
�
�
�
Zielrichtung der Methode: Entwicklung von Web Sites
Davon abhängig: Zusammenstellung von UML-Sichten, -Diagrammarten und-Notationselementen, die die Methode nutzt.
Die nachfolgende Methode kombiniert Diagramme und Notationselemente zu“Modellen”, die (ähnlich wie die Sichten) die Hauptaspekte des zu entwickelndenSystems (Web Site) aus verschiedenen Perspektiven darstellen.
Das “Tayloring” der vorgestellten Methode geht somit über die geschildertenGrundzusammenhang “Sichten, Diagrammarten, Notationselemente” hinaus.
Aufbau einer Methode mit der UML als Technik
216
Die konstituierenden Elemente einer Methode:
dient einer Definition der zu modellierenden Grundaspekte des Realitätsaus-schnitts, die durch das dahingehend zu entwickelnde AWS zu repräsentierensind sowie einer Festlegung der diese Aspekte veranschaulichenden Modelle(Aspekte = Klassifikationskriterium für Anforderungen)
Spezifikationsrahmen
dient einer logischen und durchgängigen Erarbeitung derim Spezifikationsrahmen definierten Modelle, zur Erreichungeiner vollständigen und widerspruchsfreien Fachlichen Detaillösung
Vorgehensweise
dient einer zielgerichteten Erarbeitung der im jeweiligen Spezifikationsrahmendefinierten Modelle
Technik
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiele
217
determines
determines
determines
determine
determine
determine
Target groupsRelevant business environment
of a “web site” system
Illustrationof tasks
Contextual support oftasks and activities
Integration and transparentpresentation of areas of
responsibility and processes
Spezifikationsrahmen
Bsp.: “Web Site”
Grundlegende,kontexbestimmende
Aspekte des Systems
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiele
218
Elements of a web-site-oriented Method
Technique
Process ModelSpecification Framework
+
det.
determines
determines
determine
determine
Target groupsRelevant business environment
of a “web site” system
Illustrationof tasks
Contextual support oftasks and activities
Integration and transparentpresentation of areas of
responsibility and processes
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiele
219
Step
1
2
3
4
5
6
7
8
Prepare application of method
Requirements as regards the relevantbusiness web site environment
Business requirements as regardsthe basic structure of the tasks
Business requirements as regardsthe detailed structure of the tasks
Business requirements as regardsthe sequence of the tasks
Business requirements as regardsthe tasks or processes
Business requirements as regards thelinks between task areas or processeswithin the same business area
Characteristics of the web sitetarget groups
Uniform domain termino-logy, development groups
Business environmentmodel
Participation model
Integration / transparencymodel
Task model
Dynamic context model
Detailed static contextmodel
Approximate staticcontext model
-------
Package
Pe
rma
ne
nt
an
alysis
of
the
spe
cificatio
ns
(po
ssible
retu
rns
top
revio
us
step
s)a
nd
exte
nsio
ns
of
do
ma
inte
rmin
olo
gy
Actor
Use casediagram
Use case
Use casestep graph
Detailed busi-ness class
Businessclass
Process Model Technique
Tasks (describe ...) Results UML concept
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiele
220
Sachziel: Erweiterung der bestehenden Web Site
eines Lehrstuhls, um Pages zum Web-basierten
Vertrieb von Schriften
Ausgangslage:
1. Schritt:Vorbereitung auf Anwendung der Methode:
1.1 Festlegung des in die Entwicklung einzubindendenPersonenkreises
1.2 Kategorisierung der ermittelten fachlichenAnforderungen entsprechend ihrer Affinität zu dengrundlegenden fachlichen Aspekten von Web Sites undEinrichtung einer Kategorie zur Darlegung derdie Adressaten charakterisierenden Merkmale
1.3 Fixierung einer Entwicklungsprozeß-konformenTerminologie
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
221
2. Schritt:
Darstellungder fachlich relevanten Umgebungder zu entwickelnden eBusiness-Präsenz
Konkretisierung im:
Anhand des UML-Konzepts:
- Paket -
Fachlichen UmgebungsmodellFachlichen Umgebungsmodell
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
222
Hie
rkö
nnen
Erläute
rungen
zuden
Inhal-
ten
der
Pa-
kete
aufg
e-
führt
werd
en.
Fach
lich
es
Um
geb
un
gsm
od
ell
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
223
3. Schritt:
Darstellung der Adressatender zu entwickelnden eBusiness-Präsenz
Konkretisierung im:
Anhand des UML-Konzepts:
- Akteur -
BeteiligungsmodellBeteiligungsmodell
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
224
InV
ert
rie
bs
pro
ze
ß
(en
tge
ltli
ch)
So
ftw
are
inv
olv
iert
e/-s
Pe
rso
n/A
nw
en-
du
ng
ss
ys
tem
En
tge
ltli
ch
er
Vert
rie
b
InV
ert
rie
bs
pro
ze
ß
(en
tge
ltli
ch)
Sc
hri
fte
n
inv
olv
iert
e/-s
Pe
rso
n/
An
we
nd
un
gs
sy
ste
me
InV
ert
rie
bs
pro
ze
(en
tge
ltlic
h)
Be
ratu
ng
sle
istu
ng
en
inv
olv
iert
e/-s
Pe
rso
n/A
nw
en-
du
ng
ss
ys
tem
Le
hrs
tuh
l-
leit
un
g
Ve
rfa
ss
er
vo
n
Sc
hri
fte
n
Ve
rtri
eb
sp
roze
ß
un
ters
tütz
en
de
s
An
we
nd
un
gs
sy
ste
m
Inte
res
se
nt
vo
n
Sc
hri
fte
n
Po
ten
tie
lle
r
Be
ste
lle
r
vo
n
Sc
hri
fte
n
Be
ste
lle
r
vo
n
Sc
hri
fte
n
Za
hle
r
vo
n
Sc
hri
fte
n
Ve
rtri
eb
de
r
Sc
hri
fte
n
au
sfü
hre
nd
er
Mit
arb
eit
er
de
s
Le
hrs
tuh
ls
InV
ert
rie
bs
pro
ze
ß
(en
tge
ltli
ch)
So
ftw
are
inv
olv
iert
e/-s
Pe
rso
n/A
nw
en-
du
ng
ss
ys
tem
En
tge
ltli
ch
er
Vert
rie
b
InV
ert
rie
bs
pro
ze
ß
(en
tge
ltli
ch)
Sc
hri
fte
n
inv
olv
iert
e/-s
Pe
rso
n/
An
we
nd
un
gs
sy
ste
me
InV
ert
rie
bs
pro
z
(en
tge
ltlic
h)
Be
ratu
ng
sle
istu
ng
en
inv
olv
iert
e/-s
Pe
rso
n/A
nw
en-
du
ng
ss
ys
tem
Iert
rie
bs
pro
ze
ß
(en
tglt
lic
)
Sft
wa
re
iv
lvie
rte/
-s
Pe
rso
/An
en-
du
ng
sy
ste
m
Itr
sr
z
(g
tl)
iv
li
r-
rA
n-
us
y
En
tge
ltli
ch
er
Vert
rie
b
InV
ert
rie
bs
pro
ze
ß
(n
tge
ltli
h)
Sc
hri
fte
n
inv
olv
iert
e/-s
Pe
rso
n/
An
we
nd
un
gs
sy
ste
me
InV
rtri
eb
sp
r
(en
tge
ltlic
h)
Be
ratu
ng
sle
istu
ng
en
inv
olv
iert
e/-s
Pe
rso
n/A
nw
en-
du
ng
ss
ys
tem
En
tge
ltli
ch
er
Vert
rie
b
En
tge
ltli
ch
er
Vert
rie
b
Ie
rie
roe
(n
glt
lh)
cri
f
io
lvie
rte/
-sP
ers
n/
nw
en
du
gs
sy
ste
e
Iri
r
r
iv
te-
r
g
Inrt
rie
p
(en
te
ltlic
h)
er
tun
gs
leis
tun
ge
n
ino
lvie
rte/
-sP
er
on
/An
we
n-
du
ng
ss
ys
tem
Irt
r
(n
tlt
ic)
ru
ng
leis
u
il
irt
/-e
ro
/An
en
ug
sy
st
Le
hrs
tuh
l-
leit
un
g
Ve
rfa
ss
er
vo
n
Sc
hri
fte
n
Ve
rtri
eb
sp
roze
ß
un
ters
tütz
en
de
s
An
we
nd
un
gs
sy
ste
m
Inte
res
se
nt
vo
n
Sc
hri
fte
n
Po
ten
tie
lle
r
Be
ste
lle
r
vo
n
Sc
hri
fte
n
Be
ste
lle
r
vo
n
Sc
hri
fte
n
Za
hle
r
vo
n
Sc
hri
fte
n
Ve
rtri
eb
de
r
Sc
hri
fte
n
au
sfü
hre
nd
er
Mit
arb
eit
er
de
s
Le
hrs
tuh
ls
En
tge
ltli
ch
er
Vert
rie
b“S
ch
rift
en
”
Le
hrs
tuh
l-
leit
un
g
Ve
rfa
ss
er
vo
n
Sc
hri
fte
n
Ve
rtri
eb
sp
roze
ß
un
ters
tütz
en
de
s
An
we
nd
un
gs
sy
ste
m
Inte
res
se
nt
vo
n
Sc
hri
fte
n
Po
ten
tie
lle
r
Be
ste
lle
r
vo
n
Sc
hri
fte
n
Be
ste
lle
r
vo
n
Sc
hri
fte
n
Za
hle
r
vo
n
Sc
hri
fte
n
Ve
rtri
eb
de
r
Sc
hri
fte
n
au
sfü
hre
nd
er
Mit
arb
eit
er
de
s
Le
hrs
tuh
ls
Le
rstu
hl-
leit
un
g
Lr
t-
e
Ve
rfa
ss
er
vo
n
Sc
hri
fte
n
V Sf
e
Ve
rtri
eb
sp
roze
ß
un
ters
tütz
en
de
s
An
we
nd
ug
ss
ys
te
tie
ts
te
ds
Inte
res
se
nt
vn
Sc
hri
fte
n
Is
t
v
Sr
t
Po
teti
ell
er
Be
ste
lle
r
vo
n
Sc
hri
fte
n
te
l
tl
rft
Be
ste
lle
r
vo
n
Sh
rif
en
tl
e
Sh
ie
Zh
ler
vo
n
Sc
hri
fte
n
h
Sh
fn
Ve
rtri
eb
de
r
Sh
rift
en
au
sfü
hre
nd
er
ita
rbe
ite
rd
es
Le
hrs
tuh
ls
rtd
f
üe
ir
ir
e
Lr
l
Bete
ilig
un
gsm
od
ell
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
225
4. Schritt:
Darstellung der Aufgabenbereiche undProzesse, die in der zu entwickelndeneBusiness-Präsenz abzubildenden sind
Konkretisierung im:
Anhand des(aus dem UML-Konzept - Anwendungsfall - abgeleiteten)
UML-Konzepts:
- Anwendungsfalldiagramm -
Integrations-/TransparenzmodellIntegrations-/Transparenzmodell
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
226
Inte
gra
tio
n-/
Tra
nsp
are
nzm
od
ell
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
227
5. Schritt:
Beschreibung der Aufgaben, die in der zuentwickelnden eBusiness-Präsenzabzubildenden sind
Konkretisierung im:
Anhand des UML-Konzepts:
- Anwendungsfall -
AufgabenmodellAufgabenmodell
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
228
Au
fgab
en
mo
dell
Iden
tifi
kati
on
po
ten
tieller
Beste
ller
Ku
rz-
besch
reib
un
gP
ote
ntie
ller
Be
ste
ller
wird
als
Sta
mm
-od.N
eubest
elle
rid
entif
izie
rt
Bete
ilig
teA
kte
ure
pote
ntie
ller
Best
elle
r(p
B)
Ab
lau
f:1.
Beste
llp
rozeß
init
ialisie
ren
1.1
pB
Ein
gabe
der
Best
ella
bsi
cht
1.2
VA
SA
ufford
eru
ng
sich
als
Sta
mm
-ode
rN
eu
be
ste
ller
zuid
en
tifiz
iere
n
2.
Ide
nti
fik
ati
on
rea
lis
iere
n
2.1
pB
Identif
ikatio
nals
Sta
mm
-oder
Neubest
elle
r
2.2
VA
SA
ufford
eru
ng
den
Nam
en
und
die
Kundennum
mer
ein
zugeben
2.3
VA
SA
usn
ah
me:
pote
ntie
ller
Best
elle
rhatsi
chals
Neubest
elle
rid
entif
izie
rt
2.4
pB
Ein
gabe
des
Nam
ens
und
der
Kundennum
mer
2.5
VA
SP
rüfu
ng
der
ein
gegebenen
Date
naufK
onsi
stenz
2.6
VA
SB
est
ellf
reig
abe
2.7
VA
SA
usn
ah
me:
Ein
gegebene
Date
nsi
nd
inko
nsi
stent
Au
sn
ah
men
:
2.3
VA
Sp
ote
nti
ell
er
Be
ste
lle
rh
at
sic
hals
Neu
beste
ller
iden
tifi
zie
rt
2.3
.1pB
Ein
gabe
pers
önlic
her
Date
n
2.3
.2V
AS
Prü
fung
der
ein
gegebenen
pers
önlic
hen
Date
nauf
Konsi
stenz
2.3
.3V
AS
Best
ellf
reig
abe
2.3
.4V
AS
Au
sn
ah
me:
Ein
gegebene
pers
önlic
he
Date
nsi
nd
inko
nsi
stent
...
...
...
Vert
riebsp
roze
ßu
nte
rstü
tzendes
Anw
endungss
yste
m(V
AS
)
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
229
6. Schritt:
Darstellung der dynamischen Struktur derAufgaben, die in der zu entwickelndeneBusiness-Präsenz abzubildenden sind
Konkretisierung im:
Anhand des UML-Konzepts:
- Aktivitätsdiagramm -
Dynamischen KontextmodellDynamischen Kontextmodell
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
230
Dyn
am
isch
es
Ko
nte
xtm
od
ell
pB
Ide
ntif
ika
tion
Au
ffo
rde
run
gzu
rId
en
tifik
atio
n
Au
fga
be
Ide
nti
fik
ati
on
rea
lis
iere
n
Sta
mm
nic
ht
kon
sist
en
tn
ich
tko
nsi
ste
nt
kon
sist
en
t
Ne
u
Be
ste
llfre
iga
be
ert
eilt
VA
Sp
B
Ide
ntif
ika
tion
um
setz
en
Ko
nsi
ste
nz-
prü
fun
ge
ing
eg
eb
en
eD
ate
n
Be
ste
llfre
iga
be
ert
eile
n
Ein
ga
be
pe
rs.
Da
ten
Ein
ga
be
Na
me
,K
d.-
Nr.
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
231
7. Schritt:
Darstellung der wesentlichen Elemente derstatischen Struktur der Aufgaben, diein der zu entwickelnden eBusiness-Präsenzabzubildenden sind
Konkretisierung im:
Anhand des(aus dem UML-Konzept - Klasse - abgeleiteten)
UML-Konzepts:
- Geschäftsklasse -
Groben statischenGroben statischen KontextmodellKontextmodellGroben statischenGroben statischen KontextmodellKontextmodell
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
232
Aufgabe Identifikation realisieren
Web-Site-GeschäftsklassePotentieller Besteller
ver anlaßt
führt zu
1
1
1
*
Web-Site-GeschäftsklasseIdentifikation
Web-Site-GeschäftsklasseBestellung
Statisches Kontextmodell
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
233
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:
Anhand des (aus dem UML-Konzept - Klasse - abgeleiteten)
UML-Konzepts:
- Fachklasse -
Detaillierten statischenDetaillierten statischen KontextmodellKontextmodell
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1
234
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 2
Extending a University´s Web Site with an Application
for web-based Allocation of teaching Facilities
An Example of the UML-based Method
1st Step „Prepare“:
define Development Groups,
uniform Terminology
Go to Step 2 ...
235
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 2
Ste
p2
:B
us
ine
ss
En
vir
on
me
nt
Mo
de
l
236
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 2
Ste
p3
:P
art
icip
ati
on
Mo
de
l(T
arg
et
gro
up
s)
237
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 2
Ste
p4:
Inte
gra
tio
n/Tra
nsp
are
ncy
Mo
del
238
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 2
Ste
p5:
Task
Mo
del
short
desc
riptio
nto
rese
rve
afa
cilit
yin
line
with
the
cust
om
ers
request
and
exi
s tin
gre
serv
atio
ns
tore
serv
ea
facilit
y
act
ors
offic
efo
rallo
catio
nof
teach
ing
faci
litie
sre
gis
tere
dcu
stom
er
“pre
-”co
nditi
ons
-ava
ilable
searc
hre
sult
-or
apre
limin
ary
rese
rvatio
nis
made
“post
-”co
nditi
ons
-fin
al r
ese
rvatio
n-
or
apre
limin
ary
rese
rvatio
nis
made
-or
the
rese
rvatio
nis
cance
lled
long
desc
riptio
n(.
....)
239
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 2
Ste
p6
:D
yn
am
icC
on
tex
tM
od
el
(gra
ph
ic)
[pre
lim
.re
se
rva
tio
n]
240
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 2
Ste
p7
:D
eta
ile
dS
tati
cC
on
tex
tM
od
el
241
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 2
Step 8: Approximate Static Context Model
customer
<< web-site-business-class >>
<< web-site-business-class >>
carries out
1
1
*
1
is the basis for
<< web-site-business-class >>
event
reservation
242
6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 2
Step
1
2
3
4
5
6
7
8
Prepare application of method
Requirements as regards the relevantbusiness web site environment
Business requirements as regardsthe basic structure of the tasks
Business requirements as regardsthe detailed structure of the tasks
Business requirements as regardsthe sequence of the tasks
Business requirements as regardsthe tasks or processes
Business requirements as regards thelinks between task areas or processeswithin the same business area
Characteristics of the web sitetarget groups
Uniform domain termino-logy, development groups
Business environmentmodel
Participation model
Integration / transparencymodel
Task model
Dynamic context model
Detailed static contextmodel
Approximate staticcontext model
-------
Package
Pe
rma
ne
nt
an
alysis
of
the
spe
cificatio
ns
(po
ssible
retu
rns
top
revio
us
step
s)a
nd
exte
nsio
ns
of
do
ma
inte
rmin
olo
gy
Actor
Use casediagram
Use case
Use casestep graph
Detailed busi-ness class
Businessclass
Process Model Technique
Tasks (describe ...) Results UML concept
243
1 Struktur und Ziele der Vorlesung
2 Grundlagen der Modellierung von IKS
3 Funktionsorientierte Modellierung
4 Datenflußorientierte Modellierung
5 Datenorientierte Modellierung
6
7 Prozeßmodellierung mit ARIS
Objektorientierte Modellierung
Gliederung
Systems Engineering - Modellierung von IuK-Systemen
Wirtschaftsinformatik - Wintersemester 09/10
Unternehmen
Personal Ent-wicklung
MarketingVertrieb
Produk-tion
PersonalEnt-
wicklungMarketingVertrieb Produktion
Auftrags-abwicklung
Produkt-entwicklung
Kunden-Service
Abb. 86: Übergang von der Funktions- zur Prozeßorientierung
Kundenanfra-ge technisch
prüfen
Kundenafragekaufmännisch
prüfen
Kunden-bonitätprüfen
Kunden-anfrage
technischeZeichnungen
technischerBericht
Kunden-anfrage
Kosten-schätzung
Produkt-kalkulation
Kunden-anfrage
Kundendaten
Bonitäts-auskunft
Produkt-verfügbarkeit
prüfen
Kunden-anfrage
bestätigen
Kunden-anfrage
Lager-bestand
Lager-auskunft
technischerBericht
Produkt-kalkulation
Bonitäts-auskunft
Lager-auskunft
Kunden-auftrag
Kunden-anfrage
ungeprüft
Kunden-anfrage
techn. i.O.
Kunden-anfrage kfm. i.O.
Kunden-bonität
gegeben
Produkt-verfügbarkeit
gegeben
Kunden-anfragebestätigt
Disposition
kauf-männischer
Vertrieb
technischerVertrieb
kauf-männischer
Vertrieb
Buchhaltung
Abb. 88: EPK für den Geschäftsprozess “Kundenauftragsbearbeitung”
Selected BPR Tool VendorsChallengers Leaders
Abilityto
Execute
Refocused/Niche Players VisionariesAs of 8/97
Source: Gartner Group
Completeness of Vision
Oracle
Popkin
Rational
ABC Technologies
NEC
Micrografx
Sterling Software
Proforma
Logic Works
Aonix
Software AG
Holosofx
Powersim
Action TechnologiesMosaix
Scitor
IntelliCorp
Visio
Mega Intl.Hitachi SE
Lanner Group
ICL
Meta Software
IDS Prof. Scheer
Wizdom Systems
CACI Software
High Performance Sys.
Systems ModelingInterfacing Technologies
UBIS Gensym
Imagine That
IBM
Ptech
PromodelKBSI
CASEwise
Abb. 78: Modellierungstools
© IDS SCHEER AG
Funktionen generieren EreignisseFunktionen generieren Ereignisse
GeschäftsprozeßkomponentenGeschäftsprozeßkomponenten
Ereignisse lösen Funktionen ausEreignisse lösen Funktionen aus
Kunden-auftragerhalten
Ereignis
Bestätigendes Kunden-
auftrags
Funktion
Auftrags-bestätigung
erstellt
Ereignis
Produktions-plan
Funktion
Auftrags-verfolgung
Funktion
Rück-meldungerhalten
Ereignis
Produktions-plan
erstellt
Ereignis
© IDS SCHEER AG
Kunden-auftragerhalten
Bestätigendes Kunden-
auftrags
Auftrags-bestätigung
erstellt
Rück-meldungerhalten
Produktions-plan
erstellt
Auftrags-verfolgung
Produktions-plan
Daten werden in Funktionen verarbeitetDaten werden in Funktionen verarbeitet
Kunden-daten
Daten
Produktions- daten
Daten
Ressourcen
Daten
GeschäftsprozeßkomponentenGeschäftsprozeßkomponenten
© IDS SCHEER AG
Kunden-daten
Kunden-auftragerhalten
Bestätigendes Kunden-
auftrags
Produktions- daten
Ressourcen Auftrags-
bestätigungerstellt
Rück-meldungerhalten
Produktions-plan
erstellt
Auftrags-verfolgung
Produktions-plan
Mitarbeiter sind verantwortlich für FunktionenMitarbeiter sind verantwortlich für Funktionen
Herr Schmidt
Mitarbeiter
Herr MeyerMitarbeiter
Frau MüllerMitarbeiter
GeschäftsprozeßkomponentenGeschäftsprozeßkomponenten
© IDS SCHEER AG
Kunden-auftragerhalten
Bestätigendes Kunden-
auftrags
Frau Müller
Auftrags-bestätigung
erstellt
Rück-meldungerhalten
Produktions-plan
erstelltHerr Schmidt
Herr Meyer
Auftrags-verfolgung
Produktions-plan
Mitarbeiter gehören zu OrganisationseinheitenMitarbeiter gehören zu Organisationseinheiten
Vertrieb
Organisations-einheit
Produktions-planung
Organisations-einheit
ProduktionOrganisations-einheit
Kunden-daten
Produktions- daten
Ressourcen
GeschäftsprozeßkomponentenGeschäftsprozeßkomponenten
© IDS SCHEER AG
Kunden-auftragerhalten
Bestätigendes Kunden-
auftrags
Frau Müller
Vertrieb
Auftrags-bestätigung
erstellt
Rück-meldungerhalten
Produktions-plan
erstellt
Produktion
Produktions-planung
Herr Schmidt
Herr Meyer
Auftrags-verfolgung
Produktions-plan
Funktionen erzeugen und verarbeiten LeistungenFunktionen erzeugen und verarbeiten Leistungen
Kunden-bestellung
Leistung
Kunden-auftrags-
bestätigung
Leistung
Kunden-auftrag
Leistung
Produktions-plan
Leistung
Kunden-daten
Produktions- daten
Ressourcen
GeschäftsprozeßkomponentenGeschäftsprozeßkomponenten
© IDS SCHEER AG
OrganisationssichtOrganisationssicht
DatensichtDatensicht
FunktionssichtFunktionssicht
LeistungssichtLeistungssicht
Komplexitätsreduzierung durch SichtenbildungKomplexitätsreduzierung durch Sichtenbildung
Umfeld-Umfeld-datendaten
EreignisEreignis FunktionFunktion
OrgOrg. Einheit. Einheit MitarbeiterMitarbeiter LeistungLeistung
EreignisEreignis FunktionFunktion
© IDS SCHEER AG
�DatensichtWelche Informationen sind wichtig?(z. B.: Kunde, Lieferant, Produkt, Materialrechnungen)
� FunktionssichtWelche Funktionen werden ausgeführt?(z. B.: Produktionsplanerstellung, Auftragsbearbeitung)
�OrganisationssichtWelche Organisationseinheiten gibt es?(z. B.: Einkauf, Vertrieb, Finanzbuchhaltung)
�SteuerungssichtBeziehung zwischen Daten, Funktionenund Organisationseinheiten
� LeistungssichtWelche Leistungen sind wichtig?(z. B.: geprüfter Auftrag, Kundenzahlung)
SteuerungsSteuerungs--sichtsicht
OrganisationssichtOrganisationssicht
FunktionsFunktions--sichtsicht
LeistungssichtLeistungssicht
DatenDaten--sichtsicht
ARIS -ARIS - Sichten Sichten
© IDS SCHEER AG
SteuerungsSteuerungs--sichtsicht
OrganisationssichtOrganisationssicht
FunktionsFunktions--sichtsicht
LeistungssichtLeistungssicht
DatenDaten--sichtsicht
ARIS -ARIS - Sichten Sichten
© IDS SCHEER AG
PhasenkonzeptPhasenkonzept
ProblemProblem
FachkonzeptFachkonzept
DV-KonzeptDV-Konzept
ImplementierungImplementierung
InformationstechnikInformationstechnik
© IDS SCHEER AG
ARIS -ARIS - Beschreibungsebenen Beschreibungsebenen
��FachkonzeptFachkonzeptStandardisierte fachliche Beschreibung der Unternehmenskonzepte
��DV-DV-KonzeptKonzeptÜbernahme der fachlichen Anforderungenin die Beschreibungssprache der DV-Technik
��ImplementierungImplementierungBeschreibung der konkreten Hard-und Softwarekomponenten, die fürdie Umsetzung des Unternehmens-konzeptes verwendet werden
© IDS SCHEER AG
Architektur integrierter InformationssystemeArchitektur integrierter Informationssysteme
© IDS SCHEER AG
Anfrage isteingegangen
AnfrageAngebot
Kunde
Geschäfts-leitung
Material-wirtschaft Vertrieb
EinkaufDisposition
Angebots-bearbeitung
Vertriebs-abwicklung
Lieferterminermitteln
Anfrage-bearbeitung
Angebots-bearbeitung
Bonitätprüfen
Kunden-angebot
Kunden-angebot
Kunden-anfrage
Kunden-auftrag
MethodenintegrationMethodenintegration
Anfrage ist bearbeitet
Anfrage VertriebAnfrage-bearbeitung
Organisation
Fachkonzept
DV - Konzept
Implemen-tierung
Strategische Geschäftsprozeß-analyse und Sollkonzeption
Fachkonzept
DV - Konzept
Implementierung
Fachkonzept
DV - Konzept
Implementierung
Fachkonzept
DV - Konzept
Implementierung
Daten Steuerung FunktionFachkonzept
DV - KonzeptImplementierung
Leistung
Informations- undKommunikationstechnik
ARIS-Haus
Abb. 17: ARIS-Haus mit Phasenkonzept
Abb. 21: EPK des groben ARIS-Vorgehensmodells
Projekt-start
FachkonzeptSteuerungs-sicht (EPK)
FachkonzeptSteuerungs-
sicht beendet
FachkonzeptFunktionssicht
erstellen
FachkonzeptOrganisations-sicht erstellen
FachkonzeptDatensicht erstellen
FachkonzeptLeistungssicht
erstellen
Fach-konzepte ab-geschlossen
DV-KonzeptFunktionssicht
erstellen
DV-KonzeptOrganisations-sicht erstellen
DV-KonzeptDatensichterstellen
DV-KonzeptLeistungssicht
erstellen
DV-Konzept Steuerungs-
sicht erstellen
DV-Konzepteabge-
schlossen
Implemen-tierung
Funktionssicht
Impl.Organisations-
sicht Impl.
Datensicht Impl.
LeistungssichtImpl.
Steuerungs-sicht
Projekt ab-geschlossen
© IDS SCHEER AG
WasWas ist ist ARIS? ARIS?
�ARIS = Architektur Integrierter Informationssysteme
�Rahmenkonzept zur Beschreibung von Unternehmen undAnwendungssoftware
�Entwickelt von Prof. Dr. A.-W. Scheer
�Verwendet Standard-Modellierungsmethoden
�Konzentriert auf denGeschäftsprozeß
�Effektiv in allen Umgebungen:Unabhängig von der Anzahl derAbteilungen, der Unternehmens-größe oder der vorhandenenSoftware