Schwickert 2009 - Scriptum Zur Vorlesung Im Master-Modul

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
Vorlesung zur Wirtschaftsinformatik
Systems
y Engineering
g g
Justus-Liebig-Universität Gießen
Prof. Dr. Axel C. Schwickert
Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 1
Systems Engineering: Organisatorisches
 Master: 02-BWL: MA-B9-01  Master-Modul besteht aus:

2 SWS Vorlesung Systems Engineering
2 SWS Übung: IT-Sicherheitsmanagement (Falk)
 Diplom: 2 SWS Vorlesung, Tiefenfach Wirtschaftsinformatik
 Prüfung: Diplom: 90 Min. Klausur = 3 CP / Stoff: Vorlesung

Master: 90 Min. Klausur Vorl./Üb + Projekt-Präs. Üb.
 Scriptum: http://wi.uni-giessen.de/  Download-Center / SPIC
 Dozent: Univ.-Prof. Dr. Axel C. Schwickert

Professur für BWL und WI
Justus-Liebig-Universität Gießen
eMail: Axel.Schwickert@wirtschaft.uni-giessen.de

1. Donnerstag, 15. Oktober 2009

 VL-Termin: 4. Donnerstag, 05. November 2009
Vorlesungg
5 Donnerstag,
5. Donnerstag 12.
12 November 2009
Donnerstags,
6. Donnerstag, 19. November 2009  WBT 1 statt Vorles.
10.15 Uhr
bis 11.45 Uhr 7. Donnerstag, 26. November 2009  WBT 2 statt Vorles.
8. Donnerstag, 03. Dezember 2009  WBT 3 statt Vorles.
 VL-Ort: 9. Donnerstag, 10. Dezember 2009  WBT 4 statt Vorles.
Vorlesung im 10. Donnerstag, 17. Dezember 2009  WBT 5 statt Vorles.
Raum 031 Donnerstag, 24. Dezember 2009  Ferien
(HS 031) Donnerstag, 31. Dezember 2009  Ferien
Donnerstag, 07. Januar 2010  Ferien
12. Donnerstag, 14. Januar 2010  Ferien
13. Donnerstag, 21. Januar 2010
14. Donnerstag, 28. Januar 2010
15. Donnerstag, 04. Februar 2010
 Klausur: Spätestens 2 Wochen nach Ende der Vorlesungszeit
 Kontakt: eMail: Axel. Schwickert@wirtschaft.uni-giessen.de

Oder Sprechzeit nach den Vorlesungen
O
Oder Sprechzeit
S nach Vereinbarung
 Infos: http://wi.uni-giessen.de oder SPIC
Über die Web Site erhalten Sie aktuelle

Informationen und per Download alle
Skripten zu allen Lehrveranstaltungen
Lehrveranstaltungen.
Papieraushänge und gedruckte Skripten

nur in (angekündigten) Ausnahmefällen !

http://wi.uni-giessen.de
Abonnieren !

Infos zu Vorlesungen
und Übungen
• Downloads
• Bookmarks
• Forum
• Evaluation
• WBT
Click !

Literatur zur Vorlesung
 Balzert, Helmut: Lehrbuch der Soft-  Gadatsch, Andreas: Management

ware-Technik – Band 1: Software-Ent- von Geschäftsprozessen. 2. Aufl.,
wicklung. 2. Aufl., Heidelberg, Berlin: Braunschweig/Wiesbaden:
Spektrum Akademischer Verlag 2000. Viehweg 2002.
Empfohlene Zeitschriften
 Das Wirtschaftsstudium – WISU

Allgemein sehr förderlich für Studierende
der Wirtschaftswissenschaften
 c´t: Technik!
 Wirtschaftsinformatik
Pflicht für Studierende
der Wirtschaftsinformatik
 IT-Zeitungen
Wöchentlich!

Systems Engineering - Modellierung von IuK-Systemen
Vorlesung im Master und zum Wahlfach Wirtschaftsinformatik
Prof. Dr. Axel C. Schwickert

Gliederung
1 Struktur und Ziele der Vorlesung

2 Grundlagen der Modellierung von IKS
3 Funktionsorientierte Modellierung
4 Datenflußorientierte Modellierung
5 Datenorientierte Modellierung
6 Objektorientierte Modellierung
7 Prozeßmodellierung mit ARIS
Wirtschaftsinformatik - Wintersemester 09/10

2
1.1 Gegenstand, Charakter, Ziele der Wirtschaftsinformatik
Gegenstand der WI: IuK-Systeme in Wirtschaft und Verwaltung

lIKS sind sozio-technische Systeme
lBefriedigung der Informationsnachfrage zur Erfüllung von Aufgaben
in Wirtschaft und Verwaltung
lKoordination arbeitsteilig wirkender Aufgabenträger
Handhabung der Komplexität von IuK-Systemen

lKomponenten von IKS isolieren, untersuchen, integrieren
l Komponenten von IKS: Funktionen, Daten, Objekte, Schnittstellen
l Arten von IKS unterscheiden durch Fokussierung auf Unternehmen,
Arbeitsgruppen, Einzelpersonen, Branchen, betriebliche Funktionen,
unternehmensübergreifende Funktionen.
1.1 Gegenstand, Charakter, Ziele der Wirtschaftsinformatik
Wissenschaftstheoretischer Charakter der Wirtschaftsinformatik

l Realwissenschaft: Untersuchungsgegenstand sind Phänomene der Wirklichkeit
l Formalwissenschaft: Beschreibung, Erklärung, Prognose und Gestaltung
der IKS bedürfen der Entwicklung und Anwendung formaler
Beschreibungsverfahren und Theorien
l Ingenieurwissenschaft: Die Gestaltung von IKS verlangt nach einer
Konstruktionssystematik
Ziele und methodischer Ansatz der Wirtschaftsinformatik

l Erkenntnisziel der WI: Gewinnung von Theorien, Methoden und Werkzeugen
zur Beschreibung und Erklärung von IKS, zur Prognose des Systemverhaltens
und zur Gestaltung “besserer” Systeme
l Praxiskontakte zur Gewinnung und Validierung von Erkenntnissen über IKS
sind unverzichtbar (empirisch, induktiv, realistisch).
4
1.2 Zur Bedeutung von Modellen und Modellierungsansätzen
Komplexe Landschaft von IKS im Unternehmen

l Vielzahl von IKS für verschiedene Funktionalbereiche (z. B. Beschaffung,
Produktion, Absatz, Rechnungswesen) oder Verwendungszwecke (Planung,
Steuerung, Kontrolle, Leistungserbringung) im Unternehmen
l Integration der IKS in der Regel erforderlich
Verschiedene Sichten (Perspektiven) auf IKS

l Entwickler: Modelle, Methoden, Werkzeuge, Programmierung
l Organisatoren: Aufgaben, Abläufe, Aufgabenträger, Anforderungen
l Management: Planung, Steuerung, Kontrolle von IKS-Entwicklung und -Nutzung
l Benutzer: Aufgabenerfüllung, Anforderungen, Oberflächen, Verhalten, Bedienung
- System-Umwelt und ihre Beziehungsstruktur erkennen

Modelle: - Systeme, ihre Bestandteile und ihr Funktionieren verstehen
- Komplexität beherrschbar machen
5
1.2 Zur Bedeutung von Modellen und Modellierungsansätzen
Ergebnissicht: Was ist zu modellieren?

l Modell: Eine idealisierte, vereinfachte in gewisser Hinsicht ähnliche Darstellung
eines Gegenstands, Systems oder sonstigen Weltausschnitts mit dem Ziel,
daran bestimmte Eigenschaften des Vorbilds besser analysieren zu können
(Balzert, S. 100)
l Wie das Modell eines IKS erstellt wird und wie es aussieht, hängt vom
Entwicklungsparadigma, dem Verwendungszweck des Modells und häufig auch
vom Anwendungsbereich des zu modellierenden IKS ab.
Ergebnissicht: Anforderungen an das Modellieren

l Nutzen: Zweckgerichtet umfassende und genaue Abbildung des
Vorbilds erforderlich
l Verständlichkeit: Die Modelldarstellung muß der zweckgerichteten Verwendung
des Modells (z. B. System-Analyse, -Optimierung, -Modifikation) förderlich sein.
l Standardisierung: Die Festlegung auf ein Set von Modellierungskonventionen
fördert Vergleichbarkeit, Erlernbarkeit, Verständlichkeit.
6
1.3 Anvisierte Lernziele
Lernziele: Sie sollten wissen, .....
l ..... welche Ansätze und Prinzipien für die Modellierung von

betrieblichen IKS zur Verfügung stehen,
l ..... wie IKS funktionsorientiert modelliert werden,
l ..... wie IKS datenflußorientiert mit SA, SADT modelliert werden,
l ..... wie IKS datenorientiert per ERM modelliert werden,
l ..... wie IKS prozeßorientiert mit ARIS und EPKs modelliert werden,
l ..... wie IKS objektorientiert mit der UML modelliert werden.
Gliederung


8
2.1 Prozeß- und Systemgestaltung
Zwei Sichten der Planung von (Organisations-) Systemen

l Ergebnissicht: Das “Was” der Planung - die Systemgestaltung
l Prozeßsicht: Die Vorgehensweise der Planung - die Prozeßgestaltung
Prozeßsicht der IKS-Planung, -Entwicklung

l Vorgehensmodelle: Wie z. B. sequentielle Phasenmodelle, evolutionäre
Spiralmodelle, Prototyping-Modelle (RAD) etc.
l Methodische Durchgängigkeit: Die einzelnen Prozeßschritte werden durch
aufeinander abgestimmte Analyse- und Darstellungstechniken unterstützt (z. B.
durch ein Bündel von UML-Konzepten).
Ergebnissicht der IKS-Planung, -Entwicklung

l Modellierungsansätze: Wie z. B. funktions-, datenfluß-, daten-, prozeß- oder
objektorientierte Modellierung
l Prinzipien: Grundlagen der Systemtheorie, Abstraktion, hierarchische
Strukturierung, schrittweise Verfeinerung, Modularisierung
9
2.1 Prozeß- und Systemgestaltung
Prozeßsicht: Gliederung von Software-Entwicklungsprojekten

l Für die sachliche und zeitliche Gliederung von SWE-Projekten gibt es eine Fülle
von Vorschlägen, deren gemeinsamer Nenner ein allgemeines gestuftes
Vorgehen ist.
l Siehe dazu nachfolgend das “Allgemeine Vorgehensmodell” und seine
“Wasserfallstruktur”.
Prozeßsicht: Vorgehensmodelle zur Entwicklung von IKS

l Es lassen sich folgende Grundformen unterscheiden:
l Sequentielle Vorgehensmodelle
l Parallel-sequentielle Vorgehensmodelle
l Evolutionäre Vorgehensmodelle
l Agile Vorgehensmodelle
10
2.1 Prozeß- und Systemgestaltung: Allgemeines Vorgehensmodell
Projektmanagement
Systemeinführung
Systemübergabe
Systemnutzung
Projektanstoß
Hauptprojekt
Detailprojekt
Systembau
Vorprojekt
Projekt- Projekt-
Projektplanung
realisierung kontrolle
11
2.1 Prozeß- und Systemgestaltung: Allg. VG-Modell - Wasserfallstruktur
1. Schritt Vorprojekt
2. Schritt Hauptprojekt
3. Schritt Detailprojekt
4. Schritt Systembau,
Systemeinführung und -übergabe
5. Schritt Systemnutzung
12
14
13
Phasen und Aktivitäten Ergebnisse
Projektanstoß
· Projektauftrag formulieren · Problem, Idee
· Projektorganisationsform wählen · Projektwürdigkeit
· Projektpriorität bestimmen · Projektauftrag
Vorprojekt
(allgemein)
Phasen der
· Problemstellung überprüfen
(Stahlknecht 2002)
· Untersuchungsbereich abgrenzen Systementwicklung
· Situationsanalyse / Standortbestimmung
vornehmen
· Gestaltungsmöglichkeiten abklären · Lösungsprinzipien
· Ziele erarbeiten · Vorgehenskonzept
· Lösungsprinzipien erarbeiten
· erste Wirtschaftlichkeits-
und Nutzenüberlegungen anstellen
Entwurf
Analyse
· Projektplanung erstellen
Vorphase
(weitere Vorgehen planen)
Einführung
Realisierung
Hauptprojekt
· Zielsetzung überarbeiten
· Gesamtkonzept (evtl. mit Varianten) · Gesamtkonzept,
erarbeiten Masterplan
· Wirtschaftlichkeit überprüfen
· Planung aktualisieren
Test
Detailprojekt
· realisierungsreife Lösungen ausarbeiten
· detaillierte Wirtschaftlichkeitsrechnung · Detailpläne
Istanalyse
erstellen
Sollkonzept
· Unterhaltsorganisation planen
Phasenbezeichnung Phaseninhalt
- Fachentwurf
· Schulungs- und Einführungskonzept

Systementwurf
Systemfreigabe
erstellen
- IV-Grobentwurf
Programmierung
Programmentwurf
Systemeinführung
Projektbegründung
Systembau
· System bauen
Programmspezifikation
(Lösungen benutzungsreif machen)

· System testen, abnehmen · einführungsbereites System
2.1 Prozeß- und Systemgestaltung: Allg. VG-Modell - Phasen
· Kosten und Wirtschaftlichkeit überprüfen

- Erhebung des Istzustands
- Bewertung des Istzustands
- Wirtschaftlichkeitsvergleiche
Systemeinführung
· Schulung
· eingeführtes System
· Unterhaltsorganisation aufstellen
2.1 Prozeß- und Systemgestalt.: Allg. VG-Mod. - Phasen, Aktivitäten, Ergebnisse
2.1 Prozeß- und Systemgestalt.: Allg. VG-Mod. - Phasen, Aktivitäten, Ergebnisse
Projekt-
Vorphase begründung
Istanalyse
Phase Analyse
Sollkonzept
Vorghehensmodell der
Eigen- Systementwicklung
Fremdbezug
entwicklung (allgemein)
Systementwurf
Phase Entwurf
Auswahl und
Programmentwurf Anschaffung von
Standardsoftware
Phase Realisierung Programmierung Anpassung der

und Test Standardsoftware
(Stahlknecht 2002)
System-
Phase Einführung einführung
15
2.1 Prozeß- und Systemgestaltung: Sequentielles VG-Modell “Wasserfallmodell”
Situations- Fach- System- System- System-

studie konzeption konzeption entwicklung installation
Situations-
studie Meilen-
stein
Entwicklungsebenen
Validierung 1
Fachkon-
zeption Meilen-
stein
Validierung 2
System-
konzep- Meilen-
tion stein
Validierung 3
System-
entwick- Meilen-
lung stein
Validierung 4
System-
installa- Meilen-
tion stein
Validierung 5
Zeit
16
2.1 Prozeß- und Systemgestaltung: Sequentielle Vorgehensmodelle
Sequentielle Vorgehensmodelle: Merkmale

l Auch “Phasenkonzepte” genannt
l Folgen dem Prinzip der “schrittweisen Verfeinerung”
l Phasenergebnisse (”Meilensteine”) pro Phase zu definieren
l Folgephase beginnt, wenn vorhergehende Phase vollständig abgeschlossen ist
l Wasserfallmodell sieht (die in der SW-Entwicklung allfälligen) Rücksprünge vor
Sequentielle Vorgehensmodelle: Eignung

l Anforderungen an zu entwickelndes IKS liegen präzise vor
l Wenig komplexe IKS
l IKS mit relativ stabilem Projektumfeld
l IKS, die relativ wenig Arbeitsteilung erforden
17
2.1 Prozeß- und Systemgestaltung: Parallel-sequent. VG-Modell “V-Modell”

Integration
System-
SWE 9
Integration
SWE 8
Integration
Integration
DV-
SWKE-
SWE 7
Integration
SW-
Kompo-
nenten-
Implementierung
SWE 6
Anforderungs-
entwurf
SWE 5
entwurf
Fein-
SWE 4
Anforderungs-
Anforderungs-
Grob-
analyse
und -Entwurf
und -Entwurf
SWE 3
SW-
System-
analyse
analyse
SWE 1
SWE 2
DV-
SWE-Aktivität
aktivität (QS)
Datenkatalog
SW-Entwurf
SWKE-Integrationsplan
Schnittstellenentwurf
SW-Anforderungen
Prüf-
SW-Architektur
DV-Integrationsplan
Systemintegrationsplan
DV-Anforderungen
Systemanforderungen
Legende:
DV-Architektur
Systemarchitektur
18
2.1 Prozeß- und Systemgestaltung: Parallel-sequentielle Vorgehensmodelle
Parallel-sequentielle Vorgehensmodelle: Merkmale

l Überlappte, zeitlich versetzte Arbeitsschritte phasenintern und phasenübergreifend
l Keine Fixierung mehr auf umfassende, monolithische Phasenresultate
l Statt dessen kleinere Leistungseinheiten (”Arbeitspakete”) zu definieren
l V-Modell: Bündel aus Submodellen (PM, QM, Konfig.-Man., SW-Erstellung)
Parallel-sequentielle Vorgehensmodelle: Eignung

l Für komplexere Projekte (V-Modell gültig im öffentlichen Sektor)
l Realitätsnäher als rein sequentielle Vorgehensmodelle
l Kleinere, einzeln abprüfbare Teilkomponenten
l Änderungen im Projektumfeld können flexibler berücksichtigt werden
l Nachteil: Vergleichsweise hoher Koordinationsaufwand
19
2.1 Prozeß- und Systemgestaltung: Evolutionäres VG-Modell - Grundstruktur
Zeit
R
System-
E5
installation
V
System- R
realisierung E4
P V
h
R
a System-
E3
konzeption
s V
e
n Fach- R
konzeption E2
V Legende:
R E = Entwickeln
Situations- R = Realisieren
studie E1
V = Validieren
V
20
2.1 Prozeß- und Systemgestaltung: Evolutionäres VG-Modell “Sprialmodell”
Kumulierte
Kosten
schrittweises
Ziele, Vorgehen Alternativen und
Alternativen, Risiken bewerten,
Randbedingungen Prototypen entwickeln
festlegen
Risiko-
analyse
Risiko-
analyse
Risiko-
analyse
Prototyp
Risiko- 4
analyse Prototyp
Prototyp 3
Prototyp 1 2
Vorgehens-
konzept
Anforde-
rungen Entwurf
Reali-
sierung
Entwick- Validierung
lungsplan der Anforde-
rungen
Modul- Codie-
Integration test rung
Validierung des
und Testplan Entwurfs
Integra-
tion und
Akzeptanz- Test
Installa- test
tion
21
2.1 Prozeß- und Systemgestaltung: Evolutionäre Vorgehensmodelle
Evolutionäre Vorgehensmodelle: Merkmale

l Weitgehender Verzicht auf Sequentialisierung und vordefinierte
Zwischenergebnisse
l Zwischenresultate werden durch “systematisches Probieren” in zyklisch gestufter
Abfolge von Entwerfen, Realisieren und Validieren erzeugt.
l Grundlage “Prototyping”: explorativ, experimentell, evolutionär
l Spiralmodell (Böhm): inkrementell-iteratives Vorgehen
Evolutionäre Vorgehensmodelle: Eignung

l Innovative, komplexe IKS
l Im voraus schwierig zu strukturierende IKS
l Rapid Application Development
l Nachteil: Meilenstein-Zäsuren verschwimmen
22
2.1 Prozeß- und Systemgestaltung: Agile Vorgehensmodelle
22a
22b
Agile Vorgehensmodelle: Merkmale

l Völliger Verzicht auf Sequentialisierung und vordefinierte Zwischenergebnisse
l Geringe Regelungs- und Dokumentationsdichte
l Grundlage “Prototyping”: explorativ, experimentell, evolutionär
l Hohe Eigenverantwortung, gestaltbare Abläufe und Produkte
l Beispiel: Extreme Programming
Agile Vorgehensmodelle: Eignung

l Innovative IKS mit hoher Unsicherheit
l Umwelt, System, Anforderungen offen
l Kleine IuK-Systeme
l Kleine Teams
l Nachteil: Funktioniert nur mit “Helden”
22c
22d
2.2 Systemtheoretische Grundlagen
Gegenstand der allgemeinen Systemtheorie

l Anordnung von Elementen zu einem System und die Analyse der Beziehungen
zwischen den Elementen
l Begründer: Ludwig von Bertalanffy, 1951
Zum Begriff “System”

l Ein System wird durch eine abgegrenzte und geordnete Menge von Elementen
gebildet, die untereinander in Beziehung stehen.
l Das System bildet als Ganzes eine Einheit und läßt sich deutlich von seiner
Umwelt abgrenzen.
l System-Emergenz: Das Ganze ist mehr als die Summe seiner Teile.
Hauptaspekte der Analyse und Gestaltung von Systemen

l Wirkungsaspekte, Strukturaspekte
l Abstraktion, Dekomposition
23
Systemabgrenzung und Wirkungsanalyse
Umweltbeziehungen Umweltelement
Systemgrenze
System
als
Umweltelement Blackbox
Umweltelement
24
Strukturanalyse
Umweltbeziehungen Umweltelement
Systemgrenze
System
Umweltelement
Umweltelement
25
Gesamtsystem Problemnahe
Abstraktion Ebene
und
schrittweise Schnittstelle
Verfeinerung
Subsystem Subsystem
l Hauptsachverhalte
l Vom Allgemeinen
.....
zum Speziellen
Transformationsebene(n)
l Top-down, Schnittstelle
hierarchisch
Teilaufgabe Teilaufgabe
Maschinennahe Ebene
26
Logische Komponente: suche, lies, schreibe ...
Ebene 1
Input Output
Blockkonzept,
Modularisierung Gesamtsystem
l Vollständige
Schachtelung Ebene 2
l Logische Komp. =
Bausteine, Moduln
.3
.1
ys
ys
bs
bs
.2
Su
ys
Su
bs
Su
Ebene 3
n
ul
ul
Geordnete
od
od
Sammlung
M
M
von Moduln
27
Blockkonzept,
Modularisierung Umsystem Modul Umsystem
l Mehrfach verwend- Modul-Abgrenzung

bare Moduln mit
definierten Schnitt-
stellen Input 1 Output 1
Modul
l Keine Nebeneffekte 2
Black Box 2
bei Modul-Änderung/
-Austausch Kontext und Schnittstellen
Input 1 Output 1
Unter-
2 Modul 2
28
Interne Struktur und funktionale Einheit
A
Blockkonzept, Kein Spaghetti Junction Design !
Modularisierung B
g
an
Sequenz Par 1 ng Par 4
Ei
- - - - - - - - - - - - - - - -
l Beschränkung der -
-
-
- - - - - - -
-
-
-
- - - - - - -
Strukturblockarten - - - -
l Standardisierte
us
A
gan
g
Ablaufabbildungen A B
l Beherrschbare Par 2 Par 5

- - - - - - - - - - - - - - - -
Dynamik - - - -
Selektion - - - - - - - - - - - - - - - -
- - - -
A Par 3 Par 6
- - - - - - - - - - - - - - - -
- - - -
- - - - - - - - - - - - - - - -
- - - -
Iteration
29
2.3 Graphen und Petri-Netze
Graphentheorie
l Formale Theorie, die Vorgänge und Abfolgen untersucht
l Konzentriert sich auf Beziehungen zwischen Knoten und Kanten
Zum Begriff “Graph”

l Unter einem Graph versteht man eine Menge von Knoten, .....
l ..... die untereinander mit Kanten verbunden sind (siehe Begriff “System” !).
l Gerichtete Graphen zeigen auch die Art der Verbindung (Richtung der
Einflußnahme) zwischen den Knoten an.
Graph Gerichteter Graph

30
Anwendungsbereiche der Graphentheorie

l Operations Research: Quantitative Methoden zur Planung und
Entscheidungsvorbereitung
l Ingenieur- und wirtschaftswissenschaftliche Bereiche
Eulersches Brückenproblem
l Euler 1736 in Königsberg: Gibt es einen Spazierweg über das Brückensystem
der Pregel, bei dem jede Brücke genau einmal passiert wird?
Ufer
Insel Ufer
Ufer
31
Travelling-
Salesman- Kunde 2 Kunde 4
Problem
l Ein Vertriebsbeauf-
tragter will eine
bestimmte Menge
Kunde 3
von Kunden auf einer
Rundreise mit Kunde 5
minimaler Länge Kunde 1
abklappern.
Kunde 6
Zeit-/Weg-
Depot = Startort = Zielort minimierung
32
Touren-Problem
l Innerhalb eines best. Zeitraums ist eine best. Menge von Kunden mit einer best.
Menge Lieferwagen mit best. Produktmengen möglichst effizient zu beliefern.
Kunde 2 Kunde 3 Kunde 4
Tour 2
Tour 1 Kunde 5
Kunde 1 Tour 3
Kunde 6
Zeit-/Weg-
33
und Kosten-
minimierung
$ Depot = Startort = Zielort
Transport-Problem
l Von einer best. Menge an Depots aus ist eine best. Menge von Kunden (mit
einer best. Menge Lieferwagen) mit best. Produktmengen möglichst effizient zu
beliefern (keine Transport zwischen Kunden oder zwischen Depots).
Kunde 1 Kunde 2 Kunde 3 Kunde 4
Kosten-
$ $
SNI
SNI
SNI
minimierung
Depot 1 Depot 2 Depot 3

34
Netzplantechnik (NPT)
l Große, komplexe Projekte planen, analysieren, steuern, kontrollieren, optimieren
l Ablaufstrukturplan mit zeitbeanspruchenden und zeitpunktbezogenen Elementen
muß vorher erstellt worden sein
l Zeitdauern und Vorgänger-/Nachfolgerbeziehungen sind bekannt.
2 4 F 6
5 5 30 30 45 45
S C
A H Z
S1
T I
1 3 7
A 0 0 30 30 47 47 E
R L
T
5
30 37
35
2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”
Petri-Netze
l Begründer: C. A. Petri, 1962, Ges. für Mathematik und Datenverarbeitung (GMD)
l Petri-Netze sind gerichtete Graphen.
l Petri-Netze sind keine Instrumente, um Fische zu fangen. (Stahlknecht)
36
Petri-Netze: Anwendungsbereiche
l Anwendungsneutral: Mit Petri-Netzen lassen sich Systeme und Abläufe
modellieren, die auf diskreten Aktionen und Abhängigkeitsbeziehungen zwischen
diesen Aktionen basieren.
l Erlauben die Simulation der Modell-Dynamik mittels Verhaltensregeln.
l Bspw. Modellierung, Analyse umd Simulation im Bereich der
Automatisierungstechnik
l Wirtschaftswissenschaften: Modellierung von betrieblichen Abläufen als
hochaktuelles Anwendungsgebiet - Geschäftsprozeß-Modellierung
l U. a.: Geschäftsprozesse, Workflow-Management-Systeme, Customizing von
Standard-Anwendungssoftware
Petri-Netze: Elemente
l Statische Knoten-Elemente: Zustände (passiv) und Ereignisse (aktiv)
l Kanten: Kausal-logische Zusammenhänge zwischen Zuständen und Ereignissen
l Dynamische Elemente: Marken (für Zustände)
37
Passive Elemente: Zustände (Kreise)

l Zustand (auch: Stelle, Platz, Bedingung)
l Momentane Lage, Situation eines Systems bzw. Stand eines Prozesses
l Bspw: Lagerbestand, in Bearbeitung, offene Rechnung, warm, bereit
l Zustände werden als Kreise dargestellt.
Kausal-logische Zusammenhänge: Kanten (Pfeile)

l Gerichtete Kanten = Pfeile
Aktive Elemente: Ereignisse (Rechtecke)

l Ereignis (auch: Transition, Zustandsübergang, Aktion)
l Bewirken den Übergang von einem Zustand in einen anderen Zustand
l Bspw.: Lagerbewegung, bearbeitet, Bezahlung, Erhitzung, fertigstellen
l Ereignisse werden als Rechtecke dargestellt.
38
Ereignisse und Zustände

l Ein Ereignis beschreibt die Erzeugung, Veränderung, den Transport von z. B.
Daten oder Rohstoffen bei der Realisierung von Prozessen.
l Ein Ereignis setzt genau definierte und erfüllte Zustände voraus und/oder führt zu
einer genau definierten Menge von Zuständen.
l Die Beendigung eines Zustands erfolgt durch mind. ein Ereignis.
l Der Beginn eines neuen Zustands wird von mind. einem Ereignis angestoßen.
l Eingangszustand:
l Ausgangszustand:
l Zustände und Ereignisse wechseln sich immer ab: bipartider Graph
Richtig:
Falsch:
39
Ereignisse und Zustände Falsch Richtig
l Wege beginnen und enden

nicht mit einer Kante.
l Es gibt keine alleinstehenden

Knoten.
l Es gibt keine parallel

verlaufenden Kanten.
l Es gibt keine bidirektionalen

Kanten.
40
Eingangszustand Ausgangszustand
Zustand 1 Zustandsübergang Zustand 2

kann eintreten, wenn wird durch den Ein-
Zustand 1 realisiert ist tritt des Zustands-
übergangsrealisiert
Erteiltes Auftrags-
Angebot Auftrag bearbeitung
41
Dynamische Elemente: Marken (in Zuständen)

l Durch das Setzen von Marken (Markierungen) in Zuständen wird die Dynamik
eines Systems oder Prozesses abgebildet.
l Jeder Zustand der realisiert ist, wird markiert.
l Markiert wird durch einen Punkt.
l Marken können exogen (empirische Beobachtung des Modellbenutzers) oder
endogen (aufgrund der modellbedingten Kausal-Logik) verursacht sein.
l Eine Zustandsübergang (Ereignis) kann “schalten” (durchgeführt werden), wenn
der Zustandsübergang aktiviert ist.
l Ein Zustandsübergang ist aktiviert, wenn alle Eingangszustände markiert und
alle Ausgangszustände markenfrei sind.
l Es besteht kein Schaltautomatismus. Schaltvorgänge verbrauchen keine Zeit.
l Erfolgt ein Zustandsübergang, werden von allen seinen Eingangszuständen die
Marken weggenommen und alle seine Ausgangszustände mit Marken belegt.
l Diese Vereinbarung zum Setzen von Marken (Schalten des Zustands-
übergangs) heißt “Schaltregel” (Transitions-, Simulationsregel, Firing Rule).
42
Markierungssituationen in Petri-Netzen
l Wenn pro Zustand maximal 1 Marke zulässig ist, spricht man von einem
Bedingungs-/Ereignis-Netz (B/E-Netz).
l Lokalitätsprinzip: Zustände und Ereignisse werden immer nur durch ihre direkte,
lokale Umgebung beeinflußt (Kapselung, Modularisierung).
Unproblematische Situation: Aktivierung (Schaltbarkeit, Concession)

l Markierte Eingangszustände stehen unmarkierten Ausgangszuständen
gegenüber. Ereignis kann geschaltet werden.
43
Konflikt-Situation: Begegnung (Contact)

l Mindestens 1 Ausgangszustand (hier A) ist bereits markiert. Das Ereignis kann
mithin nicht schalten.
l Kann eintreten, wenn A zugleich Ausgangszustand eines anderen Ereignisses ist
oder wenn nicht vorhergesehene exogene Störungen auftreten.
A
?
44
Konflikt-Situation: Verzweigung (Branch Conflict)

l Die Anordnung der Elemente ermöglicht verschiedene Zustandsübergänge.
l Die Schaltregel gibt keinen Aufschluß darüber, welches Ereignis schalten soll.
l Lösung 1: Modellbenutzer bestimmt das schaltende Ereignis exogen.
l Oder Lösung 2: Entscheidungsregel zur abwechselnden Schaltung
l Dabei: Zunächst schaltet Ereignis 1 und die Marke wandert von a nach b.
l Bei erneuter Markierung von A schaltet dann Ereignis 2.
1 B 1 B
a b
A A
2 C 2 C
45
Konflikt-Situation: Wettbewerb (Meet Conflict)

l ”Markenüberangebot”: Die Ereignisse 1 und 2 können nicht gleichzeitig schalten,
da dann Ausgangszustand C vereinbarungswidrig mit zwei Marken belegt würde.
l Dabei: Zunächst schaltet Ereignis 2 und die Marke wandert von a nach b.
l Bei erneuter Markierung von A und B schaltet dann Ereignis 1.
1 1
A A
a b
B C B C
2 2
46
Konflikt-Situation: Symmetrische Konfusion

l Verflochtene Konfliktsituation: Verzweigung und Wettbewerb
l Bspw.: Herstellung der Produkte C, D, E mit den Ressourcen A und B
1 a
A C
1
A C 2 b1
2 D
D
3 3 b2
B E B
E
c
47
Konflikt-Situation: Asymmetrische Konfusion

l Konflikt (zwischen 2 und 3) tritt erst ein, wenn ein Ereignis (hier 1) schaltet und
die Marke dann von A nach B wandert.
l Wenn dann 2 schaltet, wird die C-Marke eliminiert und 3 kann nicht geschaltet
werden.
l Wenn statt dessen 3 schaltet, sind nicht alle Eingangszustände für 2 aktiviert.
l Lösung 1: Exogener Eingriff
A 1 B 2 D
C b. w.
3 E
48
Konflikt-Situation: Asymmetrische Konfusion

A 1 B 2 D
a b
3
C E
49
Verschiedene markenorientierte Petri-Netz-Typen
Markenkapazität Markenkapazität
der Zustände = 1 der Zustände > 1
Nicht Bedingungs-/ Stellen-/

unterscheidbare Ereignis-Netze Transitions-Netze
Marken (B/E) (S/T)
Unterscheidbare Prädikats-/ Prädikats-/

Marken Transitions-Netze Transitions-Netze
(Pr/T) (Pr/T)
50
Kurzbeschreibung: B/E-Netze
l Zustand = Bedingung / Zustandsübergang = Ereignis
l Jeder Zustand kann maximal 1 Marke haben: Knoten-Kapazität = 1
l Marken sind nicht unterscheidbar.
l Mit jeder Ereignis-Schaltung kann max. 1 Marke gesetzt werden:
Kanten-Kapazität = 1
l Marke vorhanden / nicht vorhanden: Bedingung wahr / falsch
l Voraussetzungen für Ereignis-Schaltung: Alle Eingangsbedingungen sind wahr
(markiert), alle Ausgangsbedingungen sind falsch (nicht markiert).
l Ereignisschaltung: Allen Eingangsbedingungen wird eine Marke entnommen,
allen Ausgangsbedingungen wird eine Marke zugefügt
Eingegangene Ausgelieferte
Bestellung Ware
Mitarbeiter Geschriebene
verfügbar Bearbeitung Rechnung
der Bestellung
51
Kurzbeschreibung: S/T-Netze
l Zustand = Stelle / Zustandsübergang = Transition
l Jede Stelle kann mehr als 1 Marke haben: Stellen-Kapazität > 1
l Marken sind nicht unterscheidbar.
l Mit jeder Transitions-Schaltung können mehrere Marken transportiert werden:
Kanten-Kapazität > 1 (”Kanten-Gewichtung” gibt max. Markenmenge vor)
l Voraussetzungen für Transitions-Schaltung: Anzahl Marken in jeder
Eingangsstelle >= Kapazität der abgehenden Kante und freie Kapazität jeder
Ausgangsstelle >= Gewichtung der dort eingehenden Kante.
l Transitions-Schaltung: Allen Eingangsstellen wird diejenige Anzahl an Marken
entnommen, die der Gewichtung der abgehenden Kante entspricht.
l Transitions-Schaltung: Allen Ausgangsstellen wird diejenige Anzahl an Marken
zugewiesen, die der Gewichtung der eingehenden Kante entspricht.
52
Kurzbeschreibung: S/T-Netze (Beispiel)
K=50 K=10
Ausgelieferte
Eingegangene 1 1 Ware
Bestellung
2 1
Geschriebene
Mitarbeiter Rechnung
verfügbar K=10 Bearbeitung K=10
der Bestellung
53
Kurzbeschreibung: Pr/T-Netze
l Zustand = Prädikat / Zustandsübergang = Transition
l Prädikate repräsentieren Relationen.
l Marken nehmen Werte an und sind damit unterscheidbar.
l Marken = Tupel oder Listen von Tupeln (aus Relationen)
l Jedes Prädikat kann über mehr als 1 Marke (Relation) verfügen
Prädikats-Kapazität >= 1
l Transitionen sind Operationen, die auf ein- bzw. ausgehende Relationen
(Marken) auszuführen sind.
l Der Modelleur bestimmt, welche Prädikate welche Marken (Relationen)
aufnehmen können.
l Voraussetzungen für Transitions-Schaltung: Jedes Eingangsprädikat hat
diejenigen Tupel, die die Kanten der Ausgangsprädikate fordern und jedes
Ausgangsprädikat enthält nicht die Tupel, die die eingehende Kante fordert.
l 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.
l Die Marken (Relationen) aus den Eingangsprädikaten werden in die Marken der
54 Ausgangsprädikate umgesetzt.
Kurzbeschreibung: Pr/T-Netze (Beispiel)
Firma Bestellnummer Eing-Datum Personalnummer Bestellnummer
Muster GmbH 241299 19.12.2000 36 58 778 241299
K=50 K=10
Ausgelieferte
Eingegangene Ware
Bestellung
Geschriebene
Mitarbeiter Bearbeitung der Rechnung
verfügbar K=10 Bestellung K=10
Mitarbeiter Personalnummer Personalnummer Bestellnummer Erstellungs-Datum
Hr. Friedrich 36 58 778 36 58 778 241299 22.12.2000
55
Vorteile Petri-Netze
l Klare Abbildung von Sequenzen, Nebenläufigkeiten und Verklemmungen in
Prozeßstrukturen
l Semantik der Petri-Netze läßt sich einfach identifizieren
l Verschiedene Abstraktionsebenen möglich (Vergröberung, Verfeinerung)
l Sowohl Statik als auch Dynamik von Prozessen modellierbar, analysierbar
l Relativ leichte Erlernbarkeit (besonders B/E-Netze)
l Mathematische Verifizierbarkeit der Netze
l Die Petri-Netz-Grundlagen (basieren auf den den Grundlagen der System- und
Graphentheorie) finden sich in der geschilderten oder in abgewandelter Form in
den Modellierungsansätzen für IKS wieder.
Nachteile Petri-Netze
l Fehlen allgemeiner Systematiken zum Vorgehen bei der Erstellung
von Petri-Netzen
l Modellierung subjektiv / keine Petri-Netz-orientierten Methoden
l Erhöhter Lernaufwand höherer Netz-Typen (Pr/T-Netze)
56
Anwendungsfelder Petri-Netze

Situations-
studie Meilen-
stein
Entwicklungsebenen
Validierung 1
Fachkon-
zeption Meilen-
stein
Validierung 2
System-
konzep- Meilen-
tion stein
Validierung 3
System-
entwick- Meilen-
lung stein
Validierung 4
System-
installa- Meilen-
tion stein
Validierung 5
57 Zeit
Ausgewählte Quellen-Hinweise zu Petri-Netzen
l Balzert, Helmut: Lehrbuch der Software-Technik - Software-Entwicklung. 2. Aufl.,

Heidelberg, Berlin: Spektrum Akademischer Verlag 2000. Kapitel 2.17,
S. 346-374.
l Desel, Jörg; Oberweis, Andreas: Petri-Netz in der Angewandten Informatik. In:

Wirtschaftsinformatik, 4/1994, S. 359-366.
l Desel, Jörg; Erwin, Thomas: Simulation von Geschäftsprozessen mit Petri-

Netzen. In: WISU, 3/1999, S. 337-344.
l Rosenstengel, Bernd; Winand, Udo: Petri-Netze - Eine anwendungsorientierte

Einführung. 4. Aufl., Braunschweig: Viehweg 1991.
58
2.4 Prinzipien für die Entwicklung von betrieblichen IKS
Prinzip der hierarchischen Dekomposition

l Nach den systemtheoretischen Grundlagen der Abstraktion und schrittweisen
Verfeinerung (siehe Kap. 2.2)
Prinzip der Strukturierung und Modularisierung

l Nach den systemtheoretischen Grundlagen der Blockbildung und
Modularisierung (siehe Kap. 2.2)
Prinzip der konstruktiven Voraussicht

l Schon ab den ersten Schritten der Systementwicklung ist auf Qualitätssicherung,
Änderbarkeit, Wartbarkeit zu achten.
l Erstellungsprozeß durch praktikables Vorgehensmodell und methodische
Standardisierung strukturieren
l Integration aller Dokumentationsaktivitäten (in allen Phasen)
Prinzip der perspektivischen Betrachtung
l Abhängig vom Betrachter werden verschiedene Aspekte eines Systems
herausgehoben. Die Integration der Sichtweisen ist erforderlich.
59 l Benutzer, Entwickler, Techniker, Unternehmensführung, -organisation, Kunden ...
Prinzip der methodischen Standardisierung

l Für die Systementwicklung wird ein Bündel von Methoden, Konzepten, Techni-
ken, Werkzeugen vom arbeitsteilig organisierten Entwicklungsteam eingesetzt.
l Alle Beteiligte sollten im Systementwicklungsprozeß gemäß einem best. Vorge-
hensmodell und mit Instrumenten arbeiten, die aufeinander abgestimmt sind und
damit die Koordination von Ablauf und Entwicklungsergebnissen fördern.
Projektstart Projektende
studie konzeption konzeption realisierung anwendung
Zwischenergebnisse weiterentwickeln
Toolbox
Modellierungs- Konzepte, CASE-
Paradigma Prinzipien VG-Modell ansätze Notationen Werkzeuge
60
Zwischenprodukt
Getestetes Programmsystem
Montierte Programm-Moduln
l ”Essenz” zuerst: Gut (fachlich) geplant ist
Inkarnation: Konstruktive Sicht
Nutzungsbereite Software
Fachliches Detailkonzept
Fachliches Basiskonzept
Gewartete Komponenten
Programmierte Moduln
l ”Inkarnation” danach: Technik und Pro-
Hardwarekonfiguration
Programmstruktur
Projektvorschlag
Datenstruktur
grammierung strikt nach Plan.
Essenz: Fachliche Sicht

Prinzip der Trennung von
l ”Design first, code later.”

Essenz und Inkarnation
Programmsystementwurf
Hardwaresystementwurf
Anforderungsermittlung
Datensystementwurf
Tätigkeiten
Problemerkennung
Programmierung
Anforderungs-
spezifizierung
halb gewonnen.
Systemtest
Installation
Integration
Wartung
Situationsstudie
Fachkonzeption
anwendung
realisierung
Phase
konzeption
System-
System-
System-
1.
2.
3.
4.
5.
61
2.5 Objekt und Sichtweisen der Modellierung von betrieblichen IKS
Objekt der Modellierung von betrieblichen IKS

l Jedes IKS wird entwickelt, um bestimmte fachliche Aufgaben zu erfüllen.
l Analyse und Entwurf des Aufgabensystems sind die wichtigsten Schritte für die
Planung des IKS.
l Das Objekt der Modellierung ist demnach das durch das IKS betroffene
Aufgabengefüge im Unternehmen.
Sichtweisen der Modellierung von betrieblichen IKS

l Das Aufgabengefüge im Unternehmen läßt sich gemäß den Merkmalen von
Aufgaben unter folgenden relevanten Sichtweisen betrachten.
l Struktur von Aufgaben: Statische und dynamische Strukturaspekte
l Ressourcen von Aufgaben: Sachmittel und vor allem Daten
l Einbindung in die Organisationsstruktur: Einordnung in die Aufbau- und
Ablauforganisation des Unternehmens
62
Aufgabenmodellierung: Statische Funktionen
VERTRIEB
Angebots- Auftrags- Auftrags- Aus- Auftrags-

bearbeitung bearbeitung verwaltung lieferung abrechnung
Angebots- Auftrags- Fälligkeits- Versand- Fakturierung

konfiguration erfassung überwachung planung
Angebots- Auftrags- Liefer- Versand- Provisions-

kalkulation prüfung freigabe unterlagen abrechnung
Liefertermin- Auftrags- Auftrags- Auftrags-

ermittlung kalkulation änderungs- nachkalku-
dienst lation
Angebots- Auftrags-
überwachung bestätigung
63
Aufgabenmodellierung: Dynamische Prozesse (Funktionen)
Eigen-
KD-
fertig.
Auftrag
prüfen
KD-Bezieh. Auftrag Auftrag Auftrag Auftrag
prüfen konfig. kalkulieren terminieren bestätigen
Vertreter- Fremd-
Auftrag bezug
prüfen
Auftrags
bestätigung
64
Aufgabenmodellierung: (Ereignisgesteuerte) Prozeßketten
Kunde Auftrags- abgelehnt.

wird nicht ablehnung Kunden-
beliefert schreiben auftrag
Kunden- Kunden-
auftrag beziehung XOR
eingetr. prüfen EF-Teile
für KDA
Kunde Auftrag V
wird konfigurieren
beliefert
FB-Teile
für KDA
65

Antrag auf
Hypothek
Aufgabenmodellierung: liegt vor
(Ereignisgesteuerte)
XOR
Prozeßketten
Bauunterlagen Sicherheiten
prüfen prüfen
Beantragung
einer XOR XOR
Hypothek Unterlagen Unterlagen Sicherheiten Sicherheiten

unvollständig vollständig vorhanden nicht vorhanden
weitere Hypothek
Unterlagen nicht bewilligen
beschaffen
weitere
Unterlagen Hypothek
liegen vor bewilligen
(Stahlknecht 2002)
Antrag
abgelehnt
66
Aufgabenmodellierung: Daten (semantisches Modell)
Name
Adresse
Bonität Kunde
Telefon
Telefax
stellt
Firmenname
Bestelldatum Adresse
Lieferdatum
Bestellte Menge Auftrag Hersteller Telefon
Telefax
Rabatt Entfernung
Spezialpreis
enthält liefert
Artikelbezeichnung
Lagerbestand
Artikel Mindestbestand
Einzelpreis
67 Verpackung
Aufgabenmodellierung: (Aufbau-) Organisationsstruktur
Geschäftsleitung
Marketing Lager u. Verwaltung

Vertrieb Einkauf Produktion
Verkauf
68
Aufgabenmodellierung: (Ablauf-) Organisationsstruktur
Abteilung Abteilung Abteilung Abteilung Abteilung

Vertrieb Einkauf Produktion Lager/Vers. Verwaltung
Posteingang/-verteil. X
Auftrag erfassen X
Auftrag prüfen X X
Auftrag konfigurieren X X X
Auftrag kalkulieren X X
Auftrag terminieren X X X X
Auftrag bestätigen X
.
.
.
69
Resultierende Modellierungsansätze von betrieblichen IKS

l Aufgrund der vorgenannten Sichtweisen auf das Aufgabengefüge eines
Unternehmens sind zu modellieren:
- Funktionen
- Prozesse
- Daten
- Organisationsstrukturen
l Es existieren verschiedene Ansätze zur Modellierung von IKS, die jeweils auf
bestimmte Modellierungsobjekte fokussieren:
- Funktionsorientierte Modellierungsansätze (z. B. HIPO)
- Datenorientierte Modellierungsansätze (z. B. ERM)
- Datenflußorientierte Modellierungsansätze (z. B. SA und SADT)
l Weiterhin existieren Modellierungsansätze, die die verschiedenen
Modellierungsobjekte integrieren wie z. B.:
- Sichtweisen-integrierende Modellierung (z. B. mit ARIS)
- Objektorientierte Modellierung (z. B. mit der UML)
70
Gliederung


71
3. Funktionsorientierte Modellierung
Funktionsorientierte Aufbauorganisation des Unternehmens

lDie traditionellen betriebswirtschaftlichen Funktionalbereiche definieren die
statischen Aufbau-Organisationseinheiten des Unternehmens.
l Traditionell mit verrichtungsorientierter dynamischer Ablauforganisation
Geschäftsleitung
Beschaffung Produktion ReWe Vertrieb
Stelle Stelle Stelle Stelle
72
Stelle Stelle Stelle Stelle
3. Funktionsorientierte Modellierung
Funktionsorientierte Ablauforganisation des Unternehmens

l Verrichtungsorientierte dynamische Ablauforganisation
l Beispiel “Ersatzteilbeschaffung”
l Anfrage Kunde an Vertriebsleiter - Sb. A erstellt Angebot - Vertriebsleiter
kontrolliert - Sb. A verschickt - Kunde bestellt bei Sb. C - Sb. D erfaßt Bestellung -
Vertriebsleiter kontrolliert - Auftragsbestätigung an Kunde durch Sb. A - ..........
73
3.1 Funktions- und Verrichtungsorientierung
Funktions-/ Hier stehen wir.

verichtungsorientierte
Ablauforganisation
l Hohe Arbeitsteilung,
l Viele Schnittstellen in der
Bearbeitungsfolge
l Lange Bearbeitungszeiten
l Hoher Koordinationsbedarf
l Hierarchiegrenzen sind
Ablaufgrenzen.
74 Kunde “droht mit Auftrag"

3.2 Funktionsorientierte Modelle
Funktionale betriebliche IuK-Anwendungssysteme

l Häufig “Insel-Systeme” mit viele internen Schnittstellen
l Kein durchgehender Informationsfluß; evtl. Medienbrüche
l Geringe Flexibilität, hoher Koordinationsbedarf
l Geringe Kundennähe, hohe Redundanzen
VERTRIEB Funktion
..........
Angebots- Auftrags- Auftrags- Unter- Unter- Unter-

bearbeitung bearbeitung verwaltung funktion funktion funktion
Angebots- Auftrags- Fälligkeits-

konfiguration erfassung überwachung
Angebots- Auftrags- Liefer-
kalkulation prüfung freigabe Elementar- Elementar- Elementar-
funktion funktion funktion
.......... .......... ..........
75
Funktion Funktionsstruktur Beginn

EF 1
EF 2
Unter- Unter- Unter- EF 3
EF 4 EF 5
Elementar- Elementar- Elementar- Ende

funktion funktion funktion Struktogramm
Input Process Output NF EF1 EF2 EF3 EF4

V
x x ... x x x x ... x x x x ... x x EF1 X X
H Hierarchy
EF2 X X
x x ... x x x x ... x x x x ... x x
I Input
EF3 X X
P Process
EF4
O Output
76 “I-P-O"-Beschreibung Präzedenzmatrix
Bsp. Auftragsbearbeitung: Dekomposition der Funktionen
VERTRIEB
Angebots- Auftrags- Auftrags- Aus- Auftrags-

bearbeitung bearbeitung verwaltung lieferung abrechnung
Angebots- Auftrags- Fälligkeits- Versand- Fakturierung

konfiguration erfassung überwachung planung
Angebots- Auftrags- Liefer- Versand- Provisions-

kalkulation prüfung freigabe unterlagen abrechnung
Liefertermin- Auftrags- Auftrags- Auftrags-

ermittlung kalkulation änderungs- nachkalku-
dienst lation
Angebots- Auftrags-
überwachung bestätigung
77
Bsp. Auftragsbearbeitung: Weitere Dekomposition der Funktionen
Ausgangsebene Kundenauftragsführung
1. Dekomp.- Auftrags- Auftrags- Auslieferung

Auftrags-
ebene verwaltung bearbeitung abrechnung
2. Dekomp.- KD-Beziehung Auftrag Auftrag Auftrag

ebene prüfen erfassen bestätigen z. Ausl. vorm.
3. Dekomp.- Leitdaten Kopfdaten Pos.-Daten Auftrag

ebene erfassen erfassen erfassen abschließen
78
Vertr.-Nr. KD-NR.
KD-Nr. Vertr.-Nr.
Vertr.-Name Vertreter Kunde KD-Name
...
Vertr.-Anschrift ...KD-Anschrift
KD-NR.
Auftragskopf Vertr.-Nr.
Auftrags-Nr.
...Auftragsdatum
Sachbe-
arbeiter
Auftr.-Nr. Auftrags-
Rechnung
Pos.-Nr. position
Art.-Nr.
Bsp. Vertrieb: Menge.
..
Informationsmodell
Konto
Produkt-
Produkt lagerort
79
Kunden- Kunden-
Beziehung Bonität
prüfen prüfen
3.2 Funktions-
orientierte
Auftrags-
Modelle Leitdaten
erfassen
Auftrags-
Kopfdaten
Bsp. Auftrags- erfassen
bearbeitung:
Auftrags-
Pos.-Daten
Dialogstruktur erfassen
Lager-
bestand Auftrag
prüfen abschließen
Lager- Auftrag
bestand bestätigen
reservieren
Auftrag
z. Auslief.
vormerken
80
Auftrags- Funktionendiagramm
bearbeitung
Bsp. HIPO-Diagramm Bestands-

Fakturierung
verwaltung
Ebenendiagramm
Input Process Output
Kunden-
stammdaten Rechnung
Faktu-
rierung
Artikel-
stammdaten
Berichts-
wesen
Bestelldaten
Bestands-
(Stahlknecht 2002) verwaltung
Lager- Lager-
bestands- bestands-
daten daten
81
Bsp. Auftragsbearbeitung: Auftragspositionsdaten erfassen
INPUT PROCESS OUTPUT

Benutzer-Input: Verarbeitungsvorschrift: Benutzer-Output:
- Artikel-Nr. Gültigkeitsprüfung für Art.-Nr. s. BS-Masken-
- Menge Sperrfristprüfung für Art.-Nr. Entwurf
- Preis (fakult.) Lagerverfügbarkeit für bestellte
- Bemerkungen Menge prüfen; ggf. Reservierung
(fakultativ) für Kunden vornehmen
- .......... Mengeneinheit:
- default: ST System-Output:
System-Input: - zur Wahl: 12-Pack Palette Daten an
Daten aus Preis: - Kunden-IS
- Produkt-IS - Listenpreis - Lager-IS
- Lager-IS - Aktionspreis (fakultativ)
82
Steuerkonstrukte der Programmierung: PAP und Struktogramme (Stahlknecht 2002)
Sequenz (Reihung, Folge) Verzweigung (Selektion, einfache Alternat.)
Bedingung
Strukturblock A Strukturblock A erfüllt ?
Bedingung
erfüllt ? J N
Strukturblock B J N
Strukturblock B
Struktur- Struktur-
block A block B Struktur- Struktur-
Strukturblock C Strukturblock C block A block B
Wiederholung (Iteration, mit Bedingung) Auswahl (Selektion, mehrfache Alternative)
Wiederholungsbedingung Fallabfrage
Fall-
N abfrage
Bedingung
erfüllt ?
J
Strukturblock A
Struktur- Struktur- Struktur- Struktur- Struktur- Struktur-
Strukturblock A block A block B block C block A block B block C
83
BEGIN
Eröffne Datei Ausgangsrechnungen
R15 = 0, R20 = 0
Vorstufe der Lies Datensatz Ausgangsrechnung
Programmierung: WHILE Datensätze vorhanden DO
Pseudocode IF Rechnungsbetrag > € 3.000
THEN Rabatt = 0,20 x Rechnungsbetrag
R20 = R20 + Rabatt
(Stahlknecht 2002) ELSE Rabatt = 0,15 x Rechnungsbetrag
R15 = R15 + Rabatt
ENDIF
Lies Datensatz Ausgangsrechnung
ENDDO
RGES = R15 + R20
Drucke RGES , R15, R20
Schließe Datei Ausgangsrechnungen
END
84
Bsp. Auftragsbearbeitung: BS-Maskenentwurf zu

“Auftragspositionsdaten erfassen”
85

Schadensregulierung
Stelle
Poststelle Sach- Buchhaltung
bearbeiter Leiter
Aktion
Schadens-
Bsp. Schadenregulierung 1 meldung
annehmen
bei einer Versicherung
Meldung
2 prüfen
Ablauforganisation -
Laufwegesteuerung Zahlungs-
3 betrag
ermitteln
Zahlungs-
4 betrag
genehmigen
Original Mitteilung Kopie

5 erstellen
Mitteilung
6 versenden
(Stahlknecht 2002)
Zahlungs-
7 betrag
anweisen
86
KD
Organisatorische Laufwegesteuerung
VL
Bsp. Kundenauftragsführung
Abteilungen
BH
VS
FL
AB
- Versanddokumente schreiben
Bearbeitungsschritte:
Angebote bearbeiten
Auftragsabrechnung
Auftragsbestätigung
Aufträge bearbeiten
Aufträge verwalten
- Rückstände überwachen
- Auslieferung rückmelden
- Aufträge nachkalkulieren
- Lieferschein schreiben
- Auslieferung freigeben
- Fälligkeit überwachen
- Verfügbarkeit prüfen
- Auftragsänderungen
- Faktura erstellen
Auslieferung
- Bonität prüfen
- Reservieren
vornehmen
erstellen
- Zuteilen
87
Funktionsorientierte Modellierung von IKS

l Hierarchische Zerlegung
l Teilungskriterien sind die Funktionen des IKS im Sinne der zu erfüllenden
betrieblichen Aufgaben.
l Funktionsbäume: Untergeordnete Ebenen präzisieren die Teilfunktionen der
übergeordneten Ebenen.
l Statischer Aspekt: Aufbaustruktur des IKS (statische Funktionsstruktur im Stil
von Organigrammen)
l Dynamischer Aspekt: Ablaufstruktur des IKS, Reihenfolge der Funktionen (z. B.
durch IPO-Tabellen, Präzedenzmatrizen, Struktogrammen, Flußdiagramme,
Programmablaufpläne)
l Daten sind Ressourcen zur Erfüllung der Funktionen
l Funktionsspezifische Datendefinitionen und Datenzuordnungen verursachen
Redundanzen und Inkonsistenzen.
l In einem dynamischen Markt-/Unternehmensumfeld sind Definitionen von
Datenstrukturen zeitstabiler als Funktionsstrukturen.
l Daher wird in Literatur und Praxis ein stärker datenorientierter
88 Modellierungsansatz als zweckmäßiger angesehen.
3.3 Wandel zur Prozeßorientierung
kauf
Ein-
Reklamation
Annahme
Logistik
Service
Hier wollen wir hin.
Produktion
Kunden = Partner
ReWe
Marketing
F&E
89
Merkmale der Prozeßorientierung

l Die Organisationsstruktur orientiert sich nicht mehr an betrieblichen Funktionen
sondern an den Wertschöpfungsprozessen des Unternehmens.
l Prozesse leiten sich aus den Kernkompetenzen ab und sind auf genau definierte
marktbezogene Leistungen ausgerichtet.
l Die Prozeßleistung ist meßbar und kontrollierbar.
l Im Gegensatz zu funktionsorientierten Arbeitsabläufen sind Prozesse stellen-,
abteilungs-, funktionsbereichsübergreifend. Sie verlaufen quer zu funktionalen
Organisationsstrukturen.
l Jeder Prozeß bildet einen eigenständigen Verantwortungsbereich. Prozesse
definieren somit die Organisationseinheiten des Unternehmens.
l Die Prozeßarbeit wird von Teams getragen.
Eigen-
KD-
fertig.
Auftrag
prüfen
KD-Bezieh. Auftrag Auftrag Auftrag Auftrag
prüfen konfig. kalkulieren terminieren bestätigen
Vertreter- Fremd-
Auftrag bezug
90 prüfen
Geschäftsfeld
Beschaffung Produktion ReWe Vertrieb
Input Markt
Team Team Team Team
Auftrag Annahme Produkt

des Rechnung beim
Kunden Kunden
Bearbeitung Liefern
Prozeß-Team
91
Wertschöpfungskette(n): EBENE 1
PC-
Marketing + Vertrieb von PCs Kunden
Geschäftsprozesse: EBENE 2
Angebot
GP Nr. 1: "Kunden aquirieren und Angebote abgeben" an
Kunde
3.3 Wandel GP Nr. 2: "Kundenauftrag ausführen"

zur Prozeß- erfüllter
Auftr.-Be- A-Über- Aus- Auftr.-Ab- Kunden-
orientierung arbeitung wachung lieferung rechnung Reklamation
auftrag
Vorgangsketten: EBENE 3
Kunden- Vorgang 1 geprüfte Vorgang 2 geprüfte

auftrag Konfi- Liefer-
eingegan- "Bestellte guration "Liefertermine termine
gen Konfiguration prüfen"
prüfen"
Ereignis 1 Ereignis 2 Ereignis 3
92
Unter-
nehmens-
leitung
Merkmale der Funktions- Funktions- Funktions- Funktions-

Prozeß- bereich 1 bereich 2 bereich 3 bereich 4
orientierung
Team
Prozeß-
l Der Verbund von Verantwort- Prozeß-
leistung
Prozessen ..... licher
Prozeß 1
l ..... verlangt nach
einem Verbund
von integrierten/
Prozeß- Prozeß-
integrierenden Verantwort- leistung
von Prozessen
betrieblichen IKS licher
Prozeß 2
Kopplung
Prozeß- Prozeß-
Verantwort- leistung
licher
93 Prozeß 3
Gliederung


94
4. Datenflußorientierte Modellierung
4.1 Datenflußorientierte Modellierungsansätze

l Betrachtet man eine einzelne Funktion als Blackbox und verknüpft die Funk-
tionen über Input-Output-Beziehungen, so erhält man einen Graphen, bei dem
die Knoten Funktionen entsprechen und die Pfeile Datenflüsse repräsentieren.
l Der funktions- bzw. prozeßorientierten Sicht sehr nahe
l Typische Beispiele datenflußorientierter Modelierungsansätze:
- SADT (Structured Analysis and Design Technique)
- SA (Structured Analysis)
Datenbestand Datenbestand
VA- VA-
Schritt Schritt
Daten- Daten-
quelle senke
VA-
VA- Schritt
Schritt nd
ta
es
te nb
Datenbestand
95 Da
4. Datenflußorientierte Modellierung: SADT
SADT - Structured Analysis and Design Technique

l Mitte der 70er Jahre entwickelt (D. Ross, Firma Softech)
l Prinzip der schrittweisen Verfeinerung
l Objekte werden top-down in mindestens 3 und höchstens 6 Teilobjekte zerlegt.
l Mindestens 3: verhindert triviale Zergliederungen
l Höchstens 6: verhindert zu starke Zergliederung und Unübersichtlichkeit
l Objekte: Funktionen oder Daten (”WAS”)
l Steuerflüsse werden nicht modelliert (”WIE”)
SADT - Anwendungsbereiche
l Allgemeiner Ansatz, um Systeme jeglicher Art zu analysieren und zu entwerfen
l Das “WAS” eines Systems steht im Vordergrund, nicht das “WIE”.
l IKS-Entwicklung: Grobentwurf, Requirements Engineering
96
Anwendungsfelder SADT

Situations-
studie Meilen-
stein
Entwicklungsebenen
Validierung 1
Fachkon-
zeption Meilen-
stein
Validierung 2
System-
konzep- Meilen-
tion stein
Validierung 3
System-
entwick- Meilen-
lung stein
Validierung 4
System-
installa- Meilen-
tion stein
Validierung 5
97 Zeit
SADT - Darstellungselemente
l Nur Kästchen und Pfeile für Funktionen, Tätigkeiten, Daten, Datenflüsse
l Immer duale Modelldarstellung: Aktivitäts- und Datenmodell
Aktivitätsmodell Datenmodell
(Aktigramm) (Datagramm)
Initiierendes Initiierende
Eingabeobjekt Tätigkeit
Eingabe- Funktion Ausgabe- Herkunft Daten Verwendung

Tätigkeit Objekte
objekt objekt (Tätigkeit) (Tätigkeit)
(Verb) (Substantiv)
Mechanismus Mechanismus
(Prozessor) (Speicher)
98
SADT - Beispiel “Bibliotheksverwaltung” (Aktigramm)

l Zunächst oberste Hierarchieebene: Gesamtsystem “Bibliothek verwalten”
l Start mit Aktigramm (funktionsorientiert)
S1: Haushaltsplan S2: Bestandspolitik
E1: Eingänge von Buchhändlern A1: Ausgänge an Buchhändler
E2: Eingänge von Benutzern Bibliothek A2: Ausgänge an Benutzer

verwalten
E3: Personal A3: Personal
99
SADT - Beispiel “Bibliotheksverwaltung” (Aktigramm)

l Dann: “Bibliothek verwalten” zerlegen/verfeinern in seine Teilfunktionen
S1 (HH-Plan) S2 (Best.-Pol.)
E1 (Buchhändler) Bestellungen
Kaufe :A1 (Buchhändler)
Bücher
Rücksendungen
Bücher
E2 (Benutzer) Bediene Ausgänge

:A2 (Benutzer)
Benutzer
Angestelltes
Personal
E3 (Personal) Verwalte
Personal :A3 (Personal)
Ausgeschiedenes
100 Personal
SADT - Beispiel “Bibliotheksverwaltung” (Datagramm)

l Dann: Daten modellieren mit Bezug auf die bekannten Funktionen
Stelle Finanzierung Prüfe, ob zum Bestand passend

sicher
Prüfe, ob bestellt
Verlagsan- Bestell-
Bestelle
kündigungen belege
Bestel- Versende
Empfange lungen
Sende zurück
Bücher
101 Inventarisiere
SADT - Beispiel “Schalterverkehr Bibliothek” (Aktigramm)

Benutzerdaten
Keine Ausleihe
Identifiziere
Benutzer Benutzerdaten Benutzerdaten
Benutzerdatei
Bücher Rückgabebestätigung
Buchdaten Bücher zu- Reservierungsschein
rück geben
Datei “Ausgeliehene Bücher”

Datei “Reservierungen” Entleihschein
Bücher Bücher Keine Ausleihe

ausleihen Vormerkschein
Buchdaten
Buchdatei
102
Kundenauftrag
Kundendaten
Auftrags- Auftragsdaten
Artikeldaten bearbeitung
Programm
Auftragsbearbeitung
Kundendaten Rechnung
Artikeldaten Fakturierung Rechnungssumme
SADT - Beispiel Programm

Fakturierung
“Auftragsbearbeitung”
(Aktigramm) Kundenkonto Fibu/
Debitoren
(Stahlknecht 2002)
Programme
103 Finanzbuchhaltung
SADT - Vorteile
l Allgemeine System-Analyse und -Entwurfsmethode
l Integriert Funktionen und Daten mit Fokus auf Datenflüsse
l Konsequente schrittweise Verfeinerung, leicht erlernbar und leicht verständlich
l Im Requirements Engineering für benutzerpartizipative Grobentwürfe geeignet
SADT - Nachteile
l Aufbauorganisatorische Darstellung und Datenmodell mit anderen Methoden zu
ergänzen.
l Kontroll-/Steuerflüsse werden nicht modelliert (”WIE”). Ablauforganisatorische
Beziehungen werden somit nicht erfaßt.
l Berücksichtigt nicht Lokalitäts-/Geheimnisprinzip: Daher nicht zur Blockbildung
und Modularisierung geeignet.
l Beschränkung auf 3 bis 6 Teil-Objekte pro Verfeinerungsschritt kann
sachlogischen Erfordernissen zuwiderlaufen.
104
4. Datenflußorientierte Modellierung: SA
SA - Structured Analysis (Tom DeMarco)

l Ende der 70er Jahre entwickelt von Tom DeMarco
l Grundidee: Es ist leichter, eine Problemlösung zunächst vom Datenfluß her
gesehen zu entwickeln, als sie top-down in Funktionen zu zerlegen.
l Eine Entwurfsaufgabe wird zunächst mit Hilfe von Datenflüssen in Teilaufgaben
(Prozesse) zerlegt.
l Prozesse transformieren eingehende Datenflüsse in ausgehende Datenflüsse.
Die identifizierten Prozesse werden dann schrittweise verfeinert.
l Alle Datenflüsse eines hierarchisch nachgeordneten Datenflußgraphen müssen
im übergeordneten Datenflußgraphen vorhanden sein.
l Somit werden lediglich Prozesse dekomponiert, nicht jedoch die Datenflüsse.
l Ein Data Dictionary enthält Beschreibungen aller nicht mehr weiter zerlegbaren
Prozesse sowie der Datenflüsse.
l Kontroll-/Steuerflüsse werden nicht modelliert.
SA - Anwendungsbereiche
l Das “WAS” eines Systems steht im Vordergrund, nicht das “WIE”.
l IKS-Entwicklung: Grobentwurf, Requirements Engineering
105
Anwendungsfelder SA

Situations-
studie Meilen-
stein
Entwicklungsebenen
Validierung 1
Fachkon-
zeption Meilen-
stein
Validierung 2
System-
konzep- Meilen-
tion stein
Validierung 3
System-
entwick- Meilen-
lung stein
Validierung 4
System-
installa- Meilen-
tion stein
Validierung 5
106 Zeit
SADT - Darstellungselemente
l Zusätzlich zu den aus Symbolen bestehenden Graphen wird das Data Dictionary
(Datenlexikon mit sog. Minispecs) mitgeführt.
Symbol Bedeutung Beispiele

Datenfluß, Benutzerdaten
Materialfluß
Prozeß Aus-
leihe
Speicher,
Materiallager Magazin
Datenquelle,
Benutzer
Datensenke
107
SA - Beispiel “Schalterverkehr (SV) Bibliothek”

l Zunächst oberste Hierarchieebene: Gesamtsystem “Schalterverkehr”
l Alle relevanten Datenflüsse sind enthalten.
l 1. SV: 1.1 Benutzeridentifikation, 1.2 Überprüfung Benutzersperre, 1.3 Ausleihe
Benutzerdaten
Buchnummer
Buchdaten
1.
Benutzer SV Buchbestand
Buch
Entleihschein Leihkennzeichen
Buch Entleihschein
Magazin
108
SA - Beispiel “Schalterverkehr (SV) Bibliothek”

Benutzer-
daten
1.1
BI Zwischenspeicher Benutzerdaten
Rück-
weisung
Ausgeliehene Bücher
Unbek. Benutzer- Buchnr.

Benutzer daten
Entliehenes
Buch
Benutzerdatei n Buchnr.
ch date 1.3
Bu Buchbestand
AL
Benutzerdaten in
c he g Leihkennz.
s n c h
ih su
tle Bu Buch,
ei
En
1.2
w
Entleih-
ck
Rück- ÜBS Entleihschein

schein
Rü
weisung
Magazin
109
SA - Beispiel Kundendatei (Stahlknecht 2002)

“Auftragsbearbeitung”
Kundendaten
Bestellung Bestellung Lieferdaten Rechnung Rechnung

Kunde bearbeiten schreiben Kunde
Bestands- Entnahme- Rechnungs-

daten daten summen
Lagerbestandsdatei Debitorendatei
110
SA - Vorteile
l Analyse und -Entwurfsmethode für Software-Systeme (Prozesse + Daten)
l Integriert Funktionen (Prozesse) und Daten mit Fokus auf Datenflüsse
l Schrittweise Prozeß-Verfeinerung, leicht erlernbar und leicht verständlich
l Im Requirements Engineering für benutzerpartizipative Grobentwürfe geeignet
SA - Nachteile
l Aufbauorganisatorische Darstellung und Datenmodell mit anderen Methoden zu
ergänzen.
l Kontroll-/Steuerflüsse werden nicht modelliert (”WIE”). Ablauforganisatorische
Beziehungen werden somit nicht erfaßt (Teil-Prozesse stellen keine Sequenz dar,
obwohl durchlaufend numeriert).
l Datenflüsse, -quellen und -senken werden nicht dekomponiert. Alle diese
Elemente müssen auf allen Verfeinerungsebenen mitgeführt werden.
l Darstellungen werden sehr schnell unübersichtlich.
111
Gliederung


112
5.1 Datenorientierte Modellierungsansätze
Datenorientierte Modellierungsansätze
l Datenorientierte Modellierungsansätze für IKS konzentrieren sich auf die
betriebliche Datenstruktur, Datenrepräsentationsformen und die
Datenmanipulation.
l Datenstruktur bspw. für ein IKS: Kunden, Artikel, Lager, Vertriebsbeauftragte,
Aufträge, Lieferanten etc.
l Datenstruktur bspw. für ein IKS: Merkmale (Attribute) von Artikeln wie z. B. Preis,
Bezeichung, Menge etc. und Beziehungen z. B. zu Auftrag, Lieferant etc.
l Datenstrukturen sind i. d. R. zeitstabiler als Funktionen und eignen sich daher oft
besser für eine längerfristig gültige Modellbasis eines IKS.
l Typisches Beispiel für datenorientierte Modellierungsansätze:
- ERM (Entity Relationship Modeling)
113
5.2 Daten, Datenmanagement und Datenmodellierung
SAP-Dividenden-Info ! Information = Datum +

SAP: 471,00; 21.09.97 Zweckbezug
SAP: 484,00; 21.10.97 Regeln,
Wissen Vernetzung ! Wissen = Information
Konjunktur-Informat. + Verstehen
Dollarkursentwicklung
! Information vermindert
Unsicherheit
484,00 Kurs SAP-Aktie Zweckbezug, ! Unsicherheit
Information Bedeutungsinhalt
am 21. Oktober 1997 ! Information = Kenntnis
von Sachverhalten
(DIN 44 300)
484,00 Daten Syntax ###,## ! Information =
zweckorientiertes
Wissen / Daten
! Information = Wissen,
0123456789 Zeichen Zeichenvorrat Denken, Nachricht
114
Isoliert betrachtet sind Daten zweckneutral und bedeutungslos.
Daten
abstrakte, strukturierte
Darstellung der Realität,
zweckneutral
Entscheidung
Auswahl aus einer
Menge von Alternativen
Beziehungszu-
sammenhang,
g
Verarbeitung rtun
rwe
Abstraktion, Ve Umsetzung
Abbildung
Information Handlung
Wissen über die Durchführung zielgerichteter
Realität, zweckgerichtet Erzeugung Aktionen
115
Informations-Darstellung
strukturiert unstrukturiert
statisch dynamisch
sichtbar hörbar
bewegte akust.
Daten Texte Bilder
Bilder Signale
kombinierte Dokumente Video

Multimedia-Anwendungen
116
Datenspeicherung: Analog, EDV-extern

l Kopf, Zettel, Papier, Notizen .....
l Karteikarten, Ordner, Bücher .....
Datenspeicherung: Digital, EDV-intern

l Unstrukturiert in Files: Doc, ASCII, HTML .....
l Strukturiert in Files: Index-/sequentielle Files
mit festen/variablen Feldlängen
l Strukturiert in Datenbanken: MS-Access,
SQL-Server, Oracle, Informix, DB2 .....
117
Unstrukturierte Datenspeicherung
l Beispiel Word-Dokument mit Adressen
l Bedarf keiner weiteren Erläuterung .....
Martin Wild, Berlenbacher Weg 3,

06231-21029
Guba, Andreas, Mainz-530201, Geb.-
Dat.23.2.74
Schwickert, Axel, Handy 0171-5873937
Udo, 2.3.75, 931210
Private Adressen:
Tom Franke, Königstein, 200 DM offene
Rechnung!!!
118
Strukturierte Datenspeicherung in Files

l Bspw. in COBOL-, Pascal-Files mit festen oder variablen Feldlängen
l Jede Applikation speichert “ihre” Daten in “ihren” Files.
l Zugriff auf Daten i. d. R. nur mit bestimmten Applikationen
Franke;Thomas;23.04.1953; Welderweg 4;55124;Mainz;06131;22018

Müller;Olf;4.12.1969;Kweg 4;45129;Ollern;0531;34962
Ging;Uoh;1.2.2000;Frankfurter Str. 4;21201;Hamburg;0531;34962
[...]
FrankeThomas23.04.1953Welderweg 4 55124Mainz 0613122018

MüllerOlf 04.12.1969Kweg 4 45129Ollern 0531 34962
Ging Uoh 01.02.2000Frankfurter Str. 4 21201Hamburg0531 34962
[...]
119
Strukturierte Datenspeicherung in Files
Programm 1 Programm 2
Daten- Daten-
beschreibung beschreibung
Daten- Daten-
Prozedur- zugriff Prozedur- zugriff
Teil Teil
Datei 1 Datei 2
120
Etwas übertrieben, aber deutlich .....

l Vetter, M.: Das Jahrhundertproblem der Informatik, in: Müller-Ettrich (Hrsg.):
Effektives Datenbankdesign, Köln 1989, S. 11-31.
“Das Jahrhundertproblem der Informatik besteht

in der Bewältigung des Datenchaos, das infolge
historisch, mitunter auch hysterisch und archaisch,
sicher aber unkontrolliert gewachsener Datenbestände
fast überall entstanden ist.”
121
Strukturierte Datenspeicherung in Datenbanken

l Trennung der Daten von den Applikationen
l DBMS (Datenbankmanagement-System) zwischen Applikationen und Daten
l Datenbanken sind ein Hilfsmittel zur effizienten, rechnergestützten Organisation,
Manipulation und Verwaltung großer Datenbestände.
l Datenbanken bieten (u. a.) den anwendungsneutralen Zugriff auf Daten, Daten-
Integration und -Konsistenz, Zugriffsregelungen und Multi-User-Zugriffe in
Netzwerken: alles Problembereiche der Daten-Speicherung in Files.
122
Programm 1 Programm 2
Prozedur- Prozedur-
Teil Teil
Strukturierte
Daten-
speicherung in
Datenbanken
Datenbank-System
Datenbank-Management-System (DBMS)
Tabelle 1 Tabelle 2 Tabelle 3 .....
123
Anforderungen an betriebliche IKS:

Architektur
Gestern/heute Heute/morgen
Spartenlösungen Integrierte Gesamtlösungen
Isolierte AW-Inseln Bereichsübergreifende AWS
Geschlossene, teilweise Sicht des Gesamtunternehmens
inkompatible Systeme Integration neuer Technologien
Begrenzte Integrierbarkeit –Bürokommunikation
neuer Techniken –Teamunterstützung
–Wissensbas. Systeme
124

Informationsaktualität
Begrenzte Auswertbarkeit Max. Unterstützung der Bereichs-
der Datenbestände und Unternehmensziele
Periodische Auswertungen Online-Verfügbarkeit aller
Hohe Anteil Stapelverarbeitung wesentlichen Informationen
Daten-/Dateienredundanz Umfassende, abschließende
Unterschiedl. update-Zyklen Sofortverarbeitung
Konsistente Datenbestände
Einsatz der indiv. DV
125

Entwicklung und Wartung
Hohe Redundanz bei Unternehmensweites
Daten und Funktionen Datenmodell
Unterschiedliche Standards Unternehmensweite
Abhängigkeit von Spezialisten, Standards
mangelhafte Dokumentation Toolunterstützung
Erhebl. Wartungsaufwand Wiederverwendbarkeit
Hoher Anwendungs- Schnelle Reaktions-
rückstau fähigkeit
126
“DV-Abteilung” und Datenmanagement

l Aus Daten müssen Informationen werden.
l Informationen sind als wirtschaftliches Gut zu interpretieren.
l Aufgabe der “DV-Abteilung: Nicht “Datenverarbeitung”, sondern
Informationsversorgung
Aufgaben und Ziele des Datenmanagements

l Alle im Unternehmen verwendeten Daten planen, überwachen, steuern
l Dies unabhängig von den zur Datenspeicherung eingesetzten Sachmitteln
l Ziele: Richtigkeit, Vollständigkeit, Aktualität, Konsistenz, Aufgabenadäquanz
der Daten / Problem: “Unternehmensweites Datenmodell” (UDM)
Konkrete Aktivitätsbereiche des Datenmanagements

l Entwicklung und Implementierung von Datenmodellen
l Organisation der Datenbeschaffung und Datennutzung
l Wartung und Pflege der Datenbestände
127
Datenmanagement setzt Datenmodellierung voraus
l Informationen
werden zunehmend
Objekt Kunde Angebot Organisation
wettbewerbsrelevant.
l Datensicht stabiler
als Funktionssicht.
l Gefordert: Integrierte
Sichtweise auf alle
Unternehmensdaten. Vertrag Police
l Die Organisation (auf
der Basis einer
Modellierung)
bestimmt wesentlich
die Leistung der Be
En zie Schaden
betrieblichen IKS. titä hu
t ng
128
Integrationswirkungen der Daten- und Prozeß-Modellierung

Kundenstammdatenverwaltung
l Konstitierende Voraus- Auftragsbearbeitung
setzung für jede Land-
schaft von IKS ist die Provisions-
Modellierung der Infor- Ver- abrechnung Kunde
treter
mations-/Datenobjekte
eines Unternehmens.
l Die parallele Prozeßmo- Auf-
dellierung gibt die Hin- trag
weise für die Zusam-
menfassung von Rech- Pro-
Integrationseinheiten. nung dukt
l Die Modelleure benöti-

gen den Überblick über
die Kernziele und Lager-
Konto bestands- Lager
-Aktivitäten eines
Unternehmens. führung
Debitoren-
129 Buchhaltung
5.3 Vorgehen bei der Datenmodellierung
Datenmodellierung: Begriff
l Formale Beschreibung von Daten und deren Zusammenhänge
l ”Business Rules” implizit im Modell enthalten
Datenmodellierung: Ziele
l Systematische, strukturierte Erfassung und Dokumentation von Informationen
l Verwaltung und Nutzung von Daten/Informationen mit einem Datenbanksystem
l Datenmodellierung ist zwingende Voraussetzung für den Entwurf und die
Implementierung von Datenbanksystemen.
Exkurs: Datenbanksysteme
l Die Konstruktionsmerkmale eines (relationalen) Datenbanksystems beeinflussen
die Modellierung der Daten, die in diesem Datenbanksystem verwaltet werden.
l 3 Schichten (Schemata) in einem (relationalen) Datenbanksystem:
- Konzeptionelles (konzeptuelles) Schema
- Externes Schema (Views, Sichten)
130 - Internes (physisches) Schema
5.3 Vorgehen bei der Datenmodellierung: Exkurs Datenbanksystem

Tab. 1 Tab. 2
Tab. 3 Tab. 4
Tab. 5 Tab. 6
Tab. 7
Daten-Basis
Physische
Abbildung
Organis.
Schema:
Internes
Daten-
DBMS
Phys.
Konzeptionelles
Daten-Modell
Informations-
Gesamtes
Schema:
Realwelt
modell
(ERM)
Modellierung
Benutzer-
Anwend.-
Externes
Schema:
Externes
Schema:
Externes
Schema:
Prozeß-
View 1
View 2
View 3
131
Konzeptionelles Schema
l Stellt die Beschreibung des gesamten Realitätsausschnittes (dar (Unternehmen),
der im Datenbanksystem abgebildet werden soll.
l Durch Beobachtung der Realität wird ein Informationsmodell erzeugt, aus dem
das konzeptionelle Modell (ERM) abgeleitet wird.
Internes Schema
l Stellt die physische Organisation der Datenelemente dar (bis hin zur physischen
Anordnung der Daten auf Speichermedien).
l Wird aus dem konzeptionellen Datenmodell abgeleitet/erzeugt
Externe Schemata
l Ausschnitte des konzeptionellen Modells; Separierung aufgrund bestimmter
Aufgaben, die der jeweilige Ausschnitt erfüllen soll.
l Die Aufgaben sind durch die Anforderungen einzelner Benutzer, Anwendungen
oder Prozesse festgelegt.
132 l ”Benutzersicht” auf die Daten
Internes/physisches Schema
(physisches Datenbankmodell)
Logisches Relationenmodell
1
1
(Normalisierung)
-)Schema
P
1 P
Konzeptionelles Datenmodell
(ERM)
Abgrenzung
Realitätsausschnitt
133
Konzeptionelles Datenmodell
l Modellierung des Realitätsausschnittes aus fachlicher Sicht
l Von der (technischen) Implementierung unabhängig
l Semantisches Datenmodell (z. B. mit ERM)
l Trennung von Essenz und Inkarnation
l Erlaubt die Mitwirkung von Nicht-Informatikern bei der Datenmodellierung
(Benutzerpartizipation).
Logisches Relationenmodell
l Überführung des konzeptionellen Datenmodells in ein logisches Schema (hier:
Relationenmodell), das dann direkt in ein technisches (hier: relationales)
Datenbanksystem (interne, physische Umsetzung auf Speichermedien) überführt
werden kann.
l Hier: Relationenmodell ist somit abhängig vom anvisierten (hier: relationales)
Datenbanksystem, in das es umgesetzt werden soll.
134
Datenstruktur entwerfen und implementieren
Anwendungs- Konzeptuelles Relationales Internes

problem Datenmodell Datenmodell Datenbank-
Menge von modell
Fakturierung z. B. als
PC-Händler ER-Modell Relationen- Phys. Daten-
schemata organisation
Automatisierung der Kunde (KNr,

Rechnungsstellung, KName, KStr,
Typische Rechnung KPlz, KOrt)
sieht wie folgt aus:
....................... Artikel (ANr, z. B. Oracle
.................. ABez, APreis)
verbal, formal, Namen, Attri- DDL/SQL:

textuell, vollständig, bute,Keys, create data-
visuell graphisch Werte, ... base, table
Datenmodellierung Normalisierung
135
5.4 ERM - Entity Relationship Modeling
ERM - Entity Relationship Modeling

l 1976 von Peter Chen vorgestellt
l Semantische Datenmodelle
l In ERM (Entity-Relationship-Modellen) werden permanent zu speichernde Daten
und ihre Beziehungen modelliert.
l Keine Berücksichtigung von Datenflüssen, Organisationsstrukturen, Funktionen
ERM - Anwendungsbereiche
l Allgemeiner Ansatz, um Datenmodelle zu
entwerfen
l Unabhängig vom anvisierten Datenbanksystem
(klassisch, relational)
l Das “WAS” eines Systems steht im Vordergrund,
nicht das “WIE”.
l IKS-Entwicklung: Grobentwurf, Fach- und
136 Systemkonzeption
Anwendungsfelder ERM

Situations-
studie Meilen-
stein
Entwicklungsebenen
Validierung 1
Fachkon-
zeption Meilen-
stein
Validierung 2
System-
konzep- Meilen-
tion stein
Validierung 3
System-
entwick- Meilen-
lung stein
Validierung 4
System-
installa- Meilen-
tion stein
Validierung 5
137 Zeit
ERM - Entitätsmenge
Darstellungs-
elemente
(klassisch) erteilt
l Entitätsmengen Attribut
l Relationen
l Attribute
1 n
l Kardinalitäten Kunde bucht Leihwagen
Leihdatum
Preis
Dauer
138
5.4 ERM - Entity Relationship Modeling: Entität
Entitätsmenge
l Entitätsmenge, Entity Set, Entitätstyp, Objekttyp
l Eine Entitätsmenge enthält Entitäten (Ausprägungen)
l Entität: Individuelles, identifizierbares Exemplar von Dingen, Personen, Begriffen
der realen oder Vorstellungswelt; wird durch Eigenschaften beschrieben.
l Entitätsmenge: Zusammenfassung von Entitäten mit gleichen Eigenschaften
unter einem gemeinsamen Oberbegriff
l Symbol: Rechteck
l Beschriftung: Substantiv (Singular)
l Bsp: Kunde = Entitätsmenge / Müller, Meier, Schmidt ... = Entitäten
Entitätsmenge
139
5.4 ERM - Entity Relationship Modeling: Attribut
Attribut
l (Beschreibendes) Attribut, Property
l Fachliche Eigenschaft, die allen Entitäten einer Entitätsmenge gemeinsam ist.
l Symbol: Oval
l Beschriftung: Substantiv (Singular)
Kunde
Name
Adresse
Telefon
140
5.4 ERM - Entity Relationship Modeling: Schlüsselattribut
Identifizierendes Attribut: “Schlüssel”

l Identifizierendes Attribut, Schlüsselattribut, Key (primary, foreign)
l Schlüssel zur eindeutigen Identifizierung einer Entität
l Schlüssel: minimale identifizierende Attributkombination
l Symbol: Oval mit unterstrichener Beschriftung
l Künstliche Schlüssel: i. d. R. Nummern
l Zusammengesetzte Schlüssel: Kunde
z. B. Name + PLZ
Kunden-Nr.
Name
Adresse
Telefon
141
5.4 ERM - Entity Relationship Modeling: Relation
Relation, Beziehungstyp
l Relation, Beziehungstyp, Relationstyp, Assoziation, Relationship
l Verbindet Entitätstypen / Symbol: Raute / Beschriftung: Verb (i. d. R.)
l Beziehungstypen können Attribute besitzen
l Zwei Entitätstypen können durch mehrere Beziehungstypen miteinander in
Verbindung stehen.
l Zum Beziehungstyp gehört die Kardianlität (s. ff.)
1 n
Kunde bucht Leihwagen
Leihdatum
Preis
Dauer
142
5.4 ERM - Entity Relationship Modeling: Kardinalität
Kardinalität
l Kardinalität, Komplexitätsgrad
l Gibt an, mit wieviel A-Entitäten eine B-Entität in Verbindung stehen kann.
l Symbol: Jeweils an den verbundenen Entitäten
1 : 1 oder
1 : n oder
n:m
l Symbolplazierungen sollten modellweit in der gleichen Leserichtung erfolgen.
l Entscheidend für die Kardinalität eines Beziehungstyps sind die fachlichen
Gegebenheiten im Zusammenhang mit den zu verbindenden Entitätsmengen.
l Bsp.: Studenten müssen mehrere Klausuren schreiben und an jeder Klausur
nehmen mehrere Studenten teil.
l Bsp.: Ein Bibliotheksbenutzer leiht mehrere Bücher aus und ein Buch kann von
mehreren Benutzern ausgeliehen worden sein (hintereinander).
l Häufig: Zeitpunkt-/Zeitraumbetrachtungsproblem
143
• 1:1 - Ein Mann heiratet 1 1

eine Frau. Eine Frau Mann heiratet Frau
heiratet einen Mann.
• 1:n - Ein Kunde kann

mehrere PKWs kaufen. 1 n
Ein PKW wird immer von Kunde kauft PKW
genau einem Kunden
gekauft.
• n:m - Ein Student kann

mehrere Seminare n m
besuchen. Ein Seminar Student besucht Seminar
wird von mehreren
Studenten besucht (i. d. R.).
144
1 besteht
n
Auftrag Position
aus
Artikelbez.
Eingang Einzelpreis
Kunden-Nr. Menge
l Ein Auftrag besteht aus einer oder mehreren Auftragspositionen.

l Eine Auftragsposition gehört immer zu genau einem Auftrag.
145
n m
Produkt liegt Lager
Bezeichnung
Gewicht Adresse
Farbe Leiter
l Ein bestimmtes Produkt kann sowohl im Lager Mainz als auch im Lager Trier
vorgehalten werden.
l Hier fachlich gegeben: In einem bestimmten Lager können immer mehrere
Produktarten vorgehalten werden.
l 1 Lager mit genau einer Produktart müßte mit 1:1 modelliert sein.
146
Firmen- 1 leiht
n
Leihwagen
Kunde
Entleihdatum
Rückgabe am
Preis
l Zu modellieren ist: Wer hat einen bestimmten Wagen zur Zeit geliehen?
l Ein Firmenkunde hat in einem bestimmten Zeitraum keinen, einen oder mehrere
Wagen für seine Mitarbeiter ausgeliehen.
l Ein Wagen ist zu einem bestimmten Zeitraum genau an einen Kunden verliehen.
l Kann nicht beantworten: Wer hatte wann welchen Wagen geliehen?
147
Firmen- n leiht
m
Leihwagen
Kunde
Name Fabrikat
Adresse Farbe
Bonität Laufleistung
l Zu modellieren ist: Welche Kunden hatten wann welche Wagen gemietet?

Welche Kunden hatten bereits den Wagen “X” gemietet?
l Ein Wagen wird in seiner Nuzungszeit an viele Kunden verliehen.
l Ein Kunde kann einen oder mehrere Wagen leihen.
148
Komplexitäts- (0,1) (0,1)

Mann heiratet Frau
präzisierung
• Die (1,n,m)-Notation • 1 Mann kann maximal 1 Frau heiraten und umgekehrt. Nicht jeder
der Komplexität kann Mann oder jede Frau muß heiraten.
durch die (min, max)-
Notation präzisiert
werden. (1,1) (0,*)
• min: die mindestens Kunde kauft PKW
erforderliche Anzahl
von Beziehungen
• Genau 1 Kunde kann entweder beliebige viele oder null PKWs
• max: die maximal kaufen. Jeder PKW wird von genau einem Kunden gekauft oder ist
zulässige Anzahl von noch nicht verkauft.
Beziehungen
• Zur Besetzung der
min- und max-Posi- (2,20) (3,*)
tion werden 0, 1, * Student besucht Seminar
(viele) oder genaue
Zahlenangaben
verwendet. • Ein Seminar findet nur mit mindestens 2 und maximal 20 Studenten
statt. Jeder Student muß mindestens 3 Seminare besuchen; er kann
beliebig viele besuchen.
149
Kardinalität: Vielzahl von Notationsformen (Beispiele)
MC- Numerische Martin- Pfeil- Bachmann-

Notation Notation Notation Notation Notation
A B
C (0,1) A B
max. genau
A B
A B
1 (1,1) A B
genau genau
MC (0,n) A B
max. max. A B
A B
A B
M (1,n) A B
genau max.
150
Kardinalität
l Beispiel: Fluggesellschaft - Passagierverwaltung
l Entitätsmenge “Passagier” mit Name, Vorname, Personalausweis-Nr., .....
l Entitätsmenge “Flug” mit Flugnummer, Datum, Reiseziel, .....
l Ein Passagier kann mit verschiedenen Flügen (Wien, Paris etc.) fliegen.
l Also 1: n ?
Merke:
Kardinalität immer von beiden Seiten betrachten.
Analyse nicht nach erstbester Interpretation abschließen.
151
5.4 ERM - Entity Relationship Modeling: Schwache Entitäten
Schwache Entitätsmengen
l Schwache Entitätsmengen enthalten Entitäten, die nur in Abhängigkeit von einer
anderen Entität existieren können.
l Voll partiziperende vs. schwache Entitätsmenge
l Symbol: Doppeltes Rechteck
Yacht- 1 n
besitzt Yacht
Eigner
Voll partizipierende Schwache

Entitätsmenge Entitätsmenge
Yachteigner: YEigner_nr, YE_Name, YE_Bankverbindung

Yacht: YEigner_nr, Yacht_nr, Yacht_Name
152
5.4 ERM - Entity Relationship Modeling: Rekursive Beziehungen
Rekursive Beziehungstypen
l Entitätsmange steht mit sich selbst in Beziehung
Mitar- hat Personal-

verantwor-
beiter tung für
153
5.4 ERM - Entity Relationship Modeling: Beziehung “Aggregation”
Beziehungstyp “Aggregation”
l ist-Teil-von / is-part-of / Über-Untergeordneten-Beziehung
l Vererbt von Teilen auf Ganzes, von unten nach oben
Motor-
rad Kolben
Ventile
Teil von Teil von Teil von Speichen
Ventil
Motor Felge Rahmen
Gabel
Kolben Speichen Gabel Quertr.
Ventile Ventil Quertr.

154
5.4 ERM - Entity Relationship Modeling: Beziehung “Generalisierung”
Beziehungstyp “Generalisierung”
l Attribute einer Entitätsmenge (subtype) sind einer übergeordneten Entitätsmenge
(supertype) zuzuordnen (subtype relationship).
l Vererbung vom Ganzen auf´s Spezielle, von oben nach unten
Name Person
Geb.-Dat. Name
Geb.-Dat.
ist ein ist ein ist ein
Kunde Mitarbeiter Lieferant

155
5.4 ERM - Entity Relationship Modeling: Beziehung “Student - Klausur”
Beispiel “Student - Klausur” Fachbereich

l Ein Fachbereich besteht aus mehreren Abteilungen. 1
l Jede Abteilung besteht aus mehreren Lehrstühlen.
l Jeder Lehrstuhl bietet Klausuren an. n
l Studenten schreiben pro Lehrstuhl 1 Klausur.
Abteilung
Problembereich
l Mehrere Studenten nehmen an einer Klausur teil.
Aber: 1 Student schreibt nur 1 Klausur? Lehrstuhl
n 1
Student Klausur
156
5.4 ERM - Entity Relationship Modeling: Beispiel “Ruderboot”
ERM-Beispiel: Ruderboot-Vermietung
l Ein Ruderverein hat Mitglieder, die ihre (Ein-Mann-) Ruderboote an
vereinsexterne Hobbysportler vermieten.
l Ein Vereinsmitgleid kann mehrere Boote besitzen und anbieten.
l Die Vermietung bezieht sich immer auf das Abfahren einer vorgegebenen
(sicheren) Ruder-Tour. Diese Tour ist Bestandteil des Mietvertrags.
l Der Mieter kann sich sein Boot nach Gewicht und Farbe aussuchen.
l Für jede Tour gibt es eine festgelegte Anzahl an Rudermeilen. Am Jahresende
bekommen alle Hobbysportler mit mehr als 100 Rudermeilen ein Geschenk.
157
Tour
Tour_nr
Ziel Starke EM
Rudermeilen
wird vereinbart in Identifiz. 1:N Bzt.
Hobbysportler Ruderboot
Mietvertrag
Kunden_Nr Boot_Name
schließt Mietvertragnr umfaßt Schwache EM
Nachname Farbe
Vorname Datum Gewicht
gehört
Ruderverein Bootsbesitzer
Vereins_Nr BB_Nr
Verein_Name BB_Nachname
V_Telefon_Nr BB_Vorname
BB_Telefon
Nicht- ident. 1:N Bzt.
158
Tour
l Jeder Vertrag ist Tour_nr
eindeutig einem Ziel

Rudermeilen
Mieter zugeordnet.
wird vereinbart in
l Jedem Vertrag ist
eindeutig eine
Tour mit best. Hobbysportler Ruderboot
Mietvertrag
Rudermeilen Kunden_Nr Boot_Name
schließt Mietvertragnr umfaßt
zugeordnet. Nachname Farbe
Vorname Datum Gewicht
gehört
Ruderverein Bootsbesitzer
Vereins_Nr BB_Nr
Verein_Name BB_Nachname
V_Telefon_Nr BB_Vorname
BB_Telefon
159
5.4 ERM - Entity Relationship Modeling: Beispiel “Segeltörn”
ERM-Beispiel: Segeltörn-Vermittlung
l In der Mitsegler-Agentur Windei GmbH werden Yachteignern Teilnehmer an
Segeltörns vermittelt. Einem Eigner können mehrere Yachten gehören, während
eine Yacht nur einem Eigentümer gehört. Jeder Törn findet mit einem
festgelegten Start- und Endedatum statt.
l Jede Jacht kann während der Saison für mehrere Törns verplant werden. Jeder
Törn hat genau ein Reiseziel, das aber von mehreren Törns angelaufen werden
kann. Der Preis des Törns ist abhängig vom Reiseziel und von der Yacht.
l Jeder Mitsegler kann während der Saison an mehreren Törns teilnehmen. Er
schließt dazu für jeden Törn einen Vertrag mit dem betreffenden Yachteigner.
l [Zusatz, nicht zu modellieren: Es ist auch

möglich, daß sich mehrere Segler zu
einer Gruppe zusammenschließen und
gemeinsam einen Vertrag mit dem Eigner
abschließen.]
160
ERM-Beispiel: Segeltörn-Vermittlung
eingeplant für fährt nach

Yacht Törn Reiseziel
findet statt mit wird angefahren von
abgeschlossen für
gebucht in
besitzt
schließt ab schließt ab
Yachteigner Vertrag_Törn Kunde
161
Yacht
Törn
Yacht_nr
Yachteigner_nr (FK) Törn_nr
Yacht _Name Yacht_nr (FK) fährt zu / Rei seziel
wird eingeplant für /
Baujahr findet statt mit Yachteigner_nr (FK) wird angefahren von Reiseziel_nr
Modell Dauer
Inselname
Farbe Mittagessen
Hafen
Max_teilnehmer Komfortkl asse
Beschreibung
Motor Reiseziel_nr (FK)
Sandstrand
Y_Preiskategorie Startdatum
Klima
Endedatum
Meilen
Preiskategorie
besitzt wird gebucht in /

für
Yachteigner Kunde
Yachteigner_nr Kunden_nr
Vertrag_Törn
Name_YE Name_kd
Yachteigner_nr (FK) Adresse_Kd
Adresse_YE Vertrag_nr
Schiffschein schließt schl ießt Geburtstag
Törn_nr (FK) Kundenklasse
Erf ahrung
Kontoverbindung Preis Werbung_erwünscht
Versicherungsschutz
Sonderleistungen
162
5.4 ERM - Entity Relationship Modeling: Tool “ERWin”
ERWin: Datenmodellierungs- und Data-Base-Design-Tool

l Ziel: Modell in physische, relationale Datenbanken umsetzen
l Unterstützt bei der Erstellung von semantischen Datenmodellen (ERM: “logical”)
l Setzt Logical Model um in (normalisierte) Relationenschemata
l Setzt Schemata um in physische Datenstrukturen des DBMS
(forward engineering)
l Auslesen und analysieren bestehender Datenbanken (reverse engineering)
l Synchronisieren von Modell und bestehender Datenbank (altering DB)
l Datenmengengerüst-Berechnungen (Volumetrics)
l Umfangreiche Report-Funktionen
l Integriert in Produktfamilie u. a. mit BPWin zur Modellierung von
Geschäftsprozessen
l ERWin-Modell-Input für die wichtigsten Datenbanksysteme: DB2, Informix,
Ingres, Oracle, Progess, SQL-Server, Sybase, MS Access, Clipper, dBase,
Foxpro, Paradox, ......
163
ERWin: Erstellen “logical” und “physical modell”
Relationenmodell
Relationenmodell
Konzeptuelles Schema
Konzeptuelles Schema
(sem. Datenmodell)
(logische Ebene) Internes/physisches
Internes/physisches
Schema
Schema
l Érstellen von Entitätsmengen l ERWin löst n:m-
l Erstellen von Relationstypen Beziehungen auf l Ziel-DBMS angeben
l Konkretisierung von l Konkretisierung der l Generierung per
Kardinalitäten (auch n:m) Datentypen Knopfdruck
l Hinzufügen von Attributen l Physical Model
(ohne Datentypen)
l Hinterlegung von
Informationen zu Attributen
l Logical Model
164
ERWin: Logical Model

(konzeptionelles)
165
ERWin:
Physical
Model
(Relationen-
schema,
normalisiert)
166
5.4 ERM - Entity Relationship Modeling: Exkurs “Normalisierung”
Datenstruktur entwerfen und implementieren
Anwendungs- Konzeptuelles Relationales Internes

problem Datenmodell Datenmodell Datenbank-
Menge von modell
Fakturierung z. B. als
PC-Händler ER-Modell Relationen- Phys. Daten-
schemata organisation
Automatisierung der Kunde (KNr,

Rechnungsstellung, KName, KStr,
Typische Rechnung KPlz, KOrt)
sieht wie folgt aus:
....................... Artikel (ANr, z. B. Oracle
.................. ABez, APreis)
verbal, formal, Namen, Attri- DDL/SQL:

textuell, vollständig, bute,Keys, create data-
visuell graphisch Werte, ... base, table
Datenmodellierung Normalisierung
167
Datenbankentwurf und Normalisierung

l Jede Relation repräsentiert nur eine sachliche Bedeutungseinheit.
l Daten sollen redundanzfrei gespeichert werden.
l Der Normalisierungsprozeß soll dies sicherstellen.
Der Normalisierungsprozeß
l Relationenschemata prüfen und ggfs. ohne Informationsverlust in
mehrere Basis-Relationenschemata zerlegen
l Normalerweise: „Normalisierende“ Nachbearbeitung eines ERM
l Nachfolgend: Vorbereitung Unnormalisiert 1. 2. 3. NF
168
Beispiel “ Rechnungstellung an Kunden eines PC-Händlers”

l Beschreibung des Problems bekannt, kein ER-Modell vorhanden
l Zusammenstellung aller relevanten Daten mit Beispielrechnungen
l Tabellarische Gesamtsicht als Vorbereitung für Normalisierung
Tabellarische Zusammenstellung relevanter Daten und Beispielrechnungen
ReNr ReDat KNr KName KStr KPlz KOrt ANr ABez APreis AMe
002 12.05.00 543 Meier A-Weg 5 55128 Mainz 125 ZIP-100 198,00 4
120 PC-800 999,00 1
003 12.05.00 123 Krause B-Straße 8 55131 Mainz 300 CD-300 248,00 1
004 13.05.00 379 Schulze C-Allee 4 55131 Mainz 200 DVD-10 448,00 1
930 HUB-20 110,00 3
250 HDD-40 598,00 1
005 13.05.00 224 Meier D-Platz 3 55116 Mainz 200 DVD-10 448,00 2
006 13.05.00 123 Krause B-Straße 8 55131 Mainz 310 SCA-63 799,00 1
169
Daten nach Hauptkriterien ordnen: Unnormalisierte Relationen

l Kunden und Artikel eigenständige Bedeutungseinheiten je mit Primärschlüssel
l Übrig für “Rechnungs-Daten”: ReNr, ReDat, AMe Informationsverlust !!
l Welche Rechnung an welchen Kunden? Welche Artikel in welcher Rechnung?
l Daher: Aufnahme der Fremdschlüssel KNr, ANr in “Rechnungs-Daten”
Rechnungs-Daten
Artikel-Daten
ReNr ReDat KNr ANr AMe
Kunden-Daten ANr ABez APreis
002 12.05.00 543 120 1
KNr KName KStr KPlz KOrt 120 PC-800 999,00
125 4
125 ZIP-100 198,00
123 Krause B-Straße 8 55131 Mainz 003 12.05.00 123 300 1
200 DVD-10 448,00
224 Meier D-Platz 3 55116 Mainz 004 13.05.00 379 200 1
250 HDD-40 598,00
379 Schulze C-Alle 4 55131 Mainz 250 1
300 CD-300 248,00
543 Meier A-Weg 5 55128 Mainz 930 3
310 SCA-63 799,00
005 13.05.00 224 200 2
930 HUB-20 110,00
006 13.05.00 123 310 1
170
Von der unnormalisierten zur 1. Normalform

l 1. NF: Wiederholungsgruppen beseitigt / nur einwertige, elementare Felder
l Datensatz-Identifikation nun nur über komb. Primärschlüssel “ReNr + ANr”
Unnormalisiert: 5 Datensätze 1. Normalform: 8 Datensätze

Rechnungs-Daten Rechnungs-Daten
ReNr ReDat KNr ANr AMe ReNr ReDat KNr ANr AMe
002 12.05.00 543 120 1 002 12.05.00 543 120 1

125 4 002 12.05.00 543 125 4
003 12.05.00 123 300 1 003 12.05.00 123 300 1
004 13.05.00 379 200 1 004 13.05.00 379 200 1
250 1 004 13.05.00 379 250 1
930 3 004 13.05.00 379 930 3
005 13.05.00 224 200 2 005 13.05.00 224 200 2
006 13.05.00 123 310 1 006 13.05.00 123 310 1
Wiederholungsgruppen ! Wiederholungsgruppen durch
171 Mehrwertige Zellen (Felder) “Auffüllen” zu einwertigen Feldern
Vorüberlegungen für die 2. Normalform

l Redundanzerhöhung, da einige Nichtschlüsselattribute nur von einem Teil des
kombinierten Primärschlüssel abhängig sind (”funktional abhängig”).
l Siehe bspw. 2. Datensatz: Für die Rechnungsposition mit der ANr 125 müssen
ReDat und KNr nicht eigens nochmal gespeichert werden, da beide
Informationen eindeutig über die ReNr bestimmt sind.
1. Normalform: Rechnungs-Daten
Redundante Mehrfacheinträge ReNr ReDat KNr ANr AMe
in ReDat und KNr
002 12.05.00 543 120 1
002 12.05.00 543 125 4
003 12.05.00 123 300 1
004 13.05.00 379 200 1
004 13.05.00 379 250 1
004 13.05.00 379 930 3
005 13.05.00 224 200 2
006 13.05.00 123 310 1
172
Von der 1. Normalform zur 2. Normalform

l 2. NF: In 1. NF und alle Nichtschlüsselattribute sind vom Primärschlüssel nicht
nur “funktional abhängig”, sondern “voll funktional abhängig”.
l Zerlegen in 2NF-Relationen mit “voll funktionaler Abhängigkeit”
Neue Relation in 2. Normalform Weitere neue Relation in 2. Normalform

Rechnungs-Köpfe Rechn.-Positionen
ReNr ReDat KNr ReNr ANr AMe
002 12.05.00 543 002 120 1

003 12.05.00 123 002 125 4
004 13.05.00 379 003 300 1
005 13.05.00 224 004 200 1
006 13.05.00 123 004 250 1
004 930 3
Auslagerung der Attribute, die 005 200 2
nur vom Primärschlüssel 006 310 1
“ReNr” voll abhängig sind.
Die Attribute, die vom kombinierten
173 Schlüssel “ReNr+ANr” voll abhängig sind.
Vorüberlegungen für die 3. Normalform

l Betrachtung von funktionalen Abhängigkeiten zwischen Nichtschlüsselattributen
l Bspw. in Relation “Kunden-Daten”: KOrt ist abhängig von KPlz
l KPlz wiederum ist abhängig von KNr
l KNr determiniert KPlz und KPlz determiniert KOrt (keine Umkehrung)
l KOrt ist transitiv abhängig von KNr
2. Normalform Redundanz: Postleitzahl des

Nur voll funktionale Abhängigkeiten Wohnorts von Krause und Schulze
(da nur ein einziges Schlüsselattribut) doppelt enthalten
Kunden-Daten
Transitive Abhängigkeit
KNr KName KStr KPlz KOrt
KNr KPlz KOrt
123 Krause B-Straße 8 55131 Mainz
224 Meier D-Platz 3 55116 Mainz Keine Umkehrung
379 Schulze C-Alle 4 55131 Mainz KPlz KOrt
KNr
543 Meier A-Weg 5 55128 Mainz
174
Von der 2. Normalform zur 3. Normalform

l 3. NF: In 2. NF und kein Nichtschlüsselattribut ist vom Primärschlüssel transitiv
abhängig.
l Zerlegen in 3NF-Relationen ohne transitive Abhängigkeiten
l Funktional abhängige Nichtschlüsselattribute auslagern
Neue Relation in 3. Normalform Weitere neue Relation

in 3. Normalform
Kunden-Daten
Orts-Daten
KNr KName KStr KPlz
KPlz KOrt
123 Krause B-Straße 8 55131
224 Meier D-Platz 3 55116 55116 Mainz
379 Schulze C-Alle 4 55131 55128 Mainz
543 Meier A-Weg 5 55128 55131 Mainz
“Alte” Tabelle ohne KOrt; KPlz wird zum
KPlz wird zum Fremdschlüssel Primärschlüssel
175
Die Basis-Relationenschemata in 3. Normalform

Kunden-Daten Orts-Daten Artikel-Daten Rechnungs-Köpfe Rechn.-Positionen
KNr KName KStr KPlz KPlz KOrt ANr ABez APreis ReNr ReDat KNr ReNr ANr AMe
123 Krause B-Straße 8 55131 55116 Mainz 120 PC-800 999,00 002 12.05.00 543 002 120 1
224 Meier D-Platz 3 55116 55128 Mainz 125 ZIP-100 198,00 003 12.05.00 123 002 125 4
379 Schulze C-Alle 4 55131 55131 Mainz 200 DVD-10 448,00 004 13.05.00 379 003 300 1
543 Meier A-Weg 5 55128 250 HDD-40 598,00 005 13.05.00 224 004 200 1
300 CD-300 248,00 006 13.05.00 123 004 250 1
310 SCA-63 799,00 004 930 3
930 HUB-20 110,00 005 200 2
006 310 1
Kunden
Kunden(KNr,
(KNr,KName,
KName,KStr,
KStr,KPlz)
KPlz)
Orte (KPlz, KOrt)
Orte (KPlz, KOrt)
Artikel (ANr,ABez,
Artikel(ANr, ABez,APreis)
APreis)
Rechnungsköpfe (ReNr,ReDat,
Rechnungsköpfe (ReNr, ReDat,KNr)
KNr)
Rechnungspositionen (ReNr,ANr,
Rechnungspositionen(ReNr, ANr,AMe)
AMe)
176
Positive Anmerkungen zur Normalisierung

l Redundanzen in den Tabellen sind beseitigt
l Dabei keine Verluste von Informationen oder Abhängigkeiten
l ”One fact in one place”: Änderungsfreundlichkeit, Konsistenz
Alle Datenstrukturierungsprobleme gelöst ?

l Für die Paxis meist ausreichend: 1., 2., 3. Normalform
l Weitere: Boyce-Codd, 4. und 5. Normalform
l Anzahl der Tabellen (Komplexität) steigt mit höherer Normalform
l Applikationen, mehrere Tabellen betreffend: Performance sinkt
l Schlüssel-Redundanzen entstehen
l Kompromiß: Redundanz vs. Performance/Konsistenz
l Bspw.: “Kunden” in 2. Normaform belassen, da begrenzte,
kontrollierte Redundanz
177
Gliederung


178
6.1 Zum Paradigma der Objektorientierung: Aufsetzpunkte
Aufsetzpunkte der objektorientierten Entwicklung

l Konkurrierender Ansatz zur funktionsorientierten und datenorientierten
Entwicklung von Anwendungssystemen
l Funktions- und Datenorientierung sind relativ eigenständige Komplemente der
Systementwicklung, die sich in der Entwicklungssequenz stark auf die System-
Analyse und den System-Entwurf konzentrieren.
l Funktions- und Datenorientierung priorisieren und kombinieren sich je selbst mit
dem je anderen Ansatz, um die relevanten Systemelemente (Gegenstände,
Abläufe) abzudecken. Probleme: Organisation, Steuerung, Integration
Funktion Funktionen Fachbereich
Organisation ?
Abteilung
Unter- Unter- Unter-
Daten Steuerung ?
Lehrstuhl
Elementar- Elementar- Elementar-

Integration ?
funktion funktion funktion Student Klausur
179
6.1 Zum Paradigma der Objektorientierung: Beispiel OOA-Modell
2 Sachgebiete:
OOA-Modell
nach 1: Auftraggeber
2: Auftrag
Coad/Yourdon 3: Mitarbeiter
1 3
180
6.1 Zum Paradigma der Objektorientierung: Beispiel OO mit UML
Konto (abstrakt) Kunde (abstrakt)

Nummer Name Kundenbetreuer
Eröffnungsdatum Adresse Name
1..* 1 1..* 1
Saldo Personalnummer
Zinssatz für Habenzinsen drucke Adresse ()
berechne Quartalsumsatz () berechne
eröffne (Datum, Betrag) # erstelle Serienbrief () Quartalsumsatz ()
zahle ein (Datum, Betrag)
hebe ab (Datum, Betrag) 1
schreibe Zinsen gut ()
löse auf ()
berechne Kontoführungs
gebühr () 1..*
1 ..*
berechne Quartalsumsatz()
Buchung
Datum
Privatkunde OO-Modell
Geburtsdatum
Währung in UML
Betrag
Art
BLZ
Verwendungszweck
Firmenkunde
Girokonto
stornieren () Name des Ansprechpartners
berechne ist storniert () Anrede des Ansprechpartners
Kontoführungsgebühr ()
# Anzahl Buchungen
pro Quartal ()
# berechne
Sparkonto Quartalsumsatz ()
181
6.1 Zum Paradigma der Objektorientierung: Anliegen
Intentionen, Anliegen der OO: “Natürlichkeit, Verständlichkeit” (?)

l Konsistente (durchgängige) Integration der zu modellierenden Systemelemente
l Ganzheitliche Systementwicklung mit Durchgängigkeit über System-Analyse,
System-Entwurf und System-Implementierung
l Konzentration auf Entitäten (Objekte) und Priorisierung dessen, was ein Objekt
ist, weniger wie es verwendet wird. Demnach hat die Datenstruktur ein größeres
Gewicht als die Funktionsstruktur.
l Objektorientiert modelliert/entwickelte Systeme besitzen angeblich folgende
besondere Eigenschaften im Vgl. zu Systemen, die nach dem tradierten
funktionsorientierten Paradigma entwickelt wurden:
- Verkürzung der Entwicklungszeiten OO ohmmm
- Niedrigere Entwicklungskosten OO ohmm
- Reduzierung der Modell- und System-Komplexität
- Höhere Qualität der Modelle und Entwürfe
- Bessere Umsetzung der Benutzeranforderungen
- Methodische Durchgängigkeit und Rückverfolgbarkeit
- Einfachere Portierung auf andere Plattformen
- Erheblich vereinfachte Pflege und Weiterentwicklung
- Wiederverwendbarkeit von Systemteilen
182 l .... etc. pp.: “Alles wird gut!” (Man muß nur dran glauben.)
6.1 Zum Paradigma der Objektorientierung
Anwendungsfelder OO-Methoden (Anspruch!)

studie konzeption konzeption entwicklung pflege
Situations-
studie Meilen-
stein
Entwicklungsebenen
Validierung 1
Fachkon-
zeption Meilen-
stein
Validierung 2
System-
konzep- Meilen-
tion stein
Validierung 3
System-
entwick- Meilen-
lung stein
Validierung 4
System-
installa- Meilen-
tion stein
Validierung 5
183 Zeit
6.1 Zum Paradigma der Objektorientierung: Chronologie
Chronologie: OO-Entwicklung/-Programmierung/-Codierung
l Von der Programmierung (Entwicklung, Implementierung, 70er) über Entwurf
(Systemkonzeption, 80er) zur Analyse (Fachkonzeption, Situationsanalyse, 90er)
l 1967: Objektorientierte Programmierung mit SIMULA 67
l 1976: Programmiersprache Smalltalk; erstmals Begriff “Objektorientierung”
l 1985: Programmiersprache C++
70er Jahre:
l 1989 bereits ca. 88 oo/-basierte/oo-erweiterte Sprachen
(Eiffel, Oberon, Objective-C, Pascal, Modula-2, Lisp etc.) OO-Codierung
Chronologie: OO-Entwurf/-Design/-Konzeption
l Ausrichtung der Systemkonzeption (Design, Entwurf) 80er Jahre:
nach den Grundgedanken der Objektorientierung
(nicht mehr nach der Funktions-/Prozedur-Orientierung) OO-Design
l 1977: Beschreibungssprache DELTA
l 1981: OO-Entwurf von Booch auf Basis von ADA
l 1988: OO-Design nach Wirfs-Brock 90er Jahre:
184
l 1992: BON (Better Object Notation) von Nerson OO-Analyse
6.1 Zum Paradigma der Objektorientierung: Chronologie
Chronologie: OO-Analyse / Fachkonzeption

l In den 90er Jahren erst OO-Ausrichtung auch der frühen Phasen der Situations-
analyse und Fachkonzeption (auch “Fachentwurf” genannt)
l Damit hatte sich das OO-Pardigma bottom-up von der Programmierung her bis
zur fachlichen Planung eines Systems auf den gesamten Entwicklungsprozeß
ausgedehnt.
l 1988: Shlaer und Mellor mit “OO Systems Analysis”
90er Jahre:
l 1990: Coad und Yourdon mit “OOA”
OO-Analyse
l 1991: “Booch” nach Booch und “OMT” nach Rumbaugh
l 1992: OOSE nach Jacobsen
l 1995: Mehr als 40 Analysemethoden, die den Anspruch erheben “oo” zu sein
l 1995: Unified Method nach Booch/Rumbaugh
l 1996: Unified Modeling Language (UML 0.91) nach Booch/Rumbaugh/Jacobsen
185
6.1 Zum Paradigma der Objektorientierung: Ziele
Ziele der Objektorientierung
l Warum ein neues Paradigma mit neuen

Methoden, Techniken, Tools?
l Immer größere und kompliziertere
Softwarepropjekte scheitern am
traditionellen Instrumentarium der
Softwareentwicklung.
l Projekte dauern zu lange, sind zu teuer,
erfüllen nicht die an sie gestellten
Anforderungen.
186
6.1 Zum Paradigma der Objektorientierung: Ziele
Ziele der Objektorientierung Durch Objekt- und

Klassenbildung
Wiederverwendbarkeit / Modularität
Fehler,
Kosten,
Komplexität,
Entwicklungszeit
reduzieren
Durchgängigkeit Verständlichkeit
... der Methoden von Orientierung am

Analyse bis Codierung “Menschen”
187
6.2 Grundelemente der Objektorientierung: Überblick
Die Grundelemente der Objektorientierung im Überblick

l Je nach Autor werden bestimmte Konstrukte aus der Welt der Objektorientierung
als grundlegende “Elemente”, “Konzepte”, “Prinzipien” o. ä. herausgestellt.
l Weder die Bezeichungen dieser Konstrukte noch deren Auswahl und
Zusammenstellung ist einheitlich.
l Nachfolgend werden die wichtigsten dieser Konstrukte erläutert, die einen
Überblick zur Objektorientierung im allgemeinen geben.
- Objektbildung
- Kapselung
- Klassenbildung
- Assoziationen
- Vererbung
- Nachrichtenaustausch
- Polymorphismus
188
6.2 Grundelemente der Objektorientierung: Objektbildung
Objektbildung: Was bedeutet “objektorientiert”?

l Grob: Ein System ist eine Ansammlung unterscheidbarer Objekte, die sowohl
eine Datenstruktur als auch ein bestimmtes Verhalten in sich vereinen.
Objektbildung: Was ist ein “Objekt”?

l Ein Objekt ist ein Gegenstand des Interesses, inbesondere einer Betrachtung,
Untersuchung oder Messung.
l Objekte können gegenständliche Dinge oder Begriffe (künstlich) sein.
l Ein Objekt hat Eigenschaften (Attribute).
l Ein Objekt hat gleichzeitig ein Verhalten. Dieses Verhalten wird durch
Operationen (Methoden) ausgedrückt.
Attribute: Operationen:
Objekt: - Farbe (weiß) - Melken
Elsa Euter - Beine (4) - Füttern
- Milchmenge (15) - Fortpflanzen
189
Objektbildung: Eine Tür wird beschrieben durch ....
.... Attribute: - Größe

- Farbe
- Material
.... Operationen: - Öffnen

- Schließen
190
Objektbildung: Jedes Objekt hat eine eindeutige Identität
Objekt: Schlüssel
Objekt: Tür
Objekt: Haus
Objekt: Vera Vollmilch

191
6.2 Grundelemente der Objektorientierung: Kapselung
Was bedeutet “Kapselung”?

l Auf die Attributwerte eines Objektes kann nur das Objekt selbst zugreifen.
l Zugriff nur über die Operationen des betreffenden Objektes.
l Ein Objekt “verbirgt“ (kapselt) seine Attribute in sich und gibt nur bekannt, welche
Operationen von ihm zur Verfügung stehen.
l Verhinderung unkontrollierter Datenmanipulationen durch Realisierung des
“Geheimnisprinzips”
Anja Alms Milchproduktion?

Objekt: Anja Alm
Allein ihre Sache!!
192
6.2 Grundelemente der Objektorientierung: Klassenbildung
Was bedeutet “Klassenbildung”?

l Eine Klasse beschreibt eine Menge von Objekten mit gleichen Eigenschaften,
gemeinsamen Operationen, gemeinsamen Beziehungen zu anderen Objekten
und gemeinsamer Semantik.
l Eine Klasse ist somit ein “Bauplan” für bestimmte (reale) Objekte.
Klasse Kuh
Objekte
Vera Vollmilch Elsa Euter Anja Alm

193
6.2 Grundelemente der Objektorientierung: Klassenbildung
Klassenbildung: Darstellung von Klassen und Objekten

l Strukturgleiche (Name, Attribute, Operationen), aber in Details unterschiedliche
Darstellungsformen je nach “OO-Guru”
l Unten Notation in Anlehnung an Rumbaugh
l UML aber z. B. ohne Liste der Operationen bei Objektdarstellung
Darstellung Klasse Darstellung Objekt

Klassenname :Kuh Elsa Euter : Kuh
Exemplar von
Liste der Farbe Instanz von Farbe = weiß
Attribute Beine Instance of Beine = 4
Milchmenge Class Instance Milchmenge = 15 [Liter]
Liste der Melken () Melken (Liter)

Operationen Füttern () Füttern (Kilo)
Fortpflanzen () Fortpflanzen (Kälber)
194
6.2 Grundelemente
6.1 Zum Paradigma
der Objektorientierung:
der Objektorientierung
Assoziationen
Assoziationen: Beziehungen zwischen Objekten

l Beziehungen zwischen Objekten (gleichgeordneter) Klassen
l Werden durch einfache Linien dargestellt (bi-/unidirektional).
l Nach Möglichkeit werden Assoziationen durch Namen, Kardinalitätsangaben
und/oder Rollennamen beschrieben.
: Kunde : Auftrag
Name = Meier 1 erteilt n Nummer = A-12345
Status = aktiv Datum = 15. Mai 2001
eMail = Meier@home.de Wert = 200.000 [DM]
1 1
verantwortlich für “Objektdiagramm” gehört zu
n 1
: Kundenbetreuer : Rechnung
Name = Müller n hat m Nummer = R-232323
Persnr = P-987654321 Betrag = 300.000 [DM]
Branche = Maschinenbau Zahlungsart = Bar
195
6.2 Grundelemente der Objektorientierung: Assoziationen
Spezielle Assoziation: Aggregation

l Aggregation: Ganzes-Teile-Beziehung zwischen Objekten
l Die Objekte sind dabei nicht gleichberechtigt; eine der beteiligten Klassen hat
eine führende Rolle.
l Hier: Fahrrad besteht aus Rahmen und Bremsen (u. a.).
: Fahrrad 0..*
Bauteil
Bezeichung = Berglust
Artikelnr = AR-1245 0..*
Kategorie = Mountainbike besteht aus
1 1
hat hat
1 n
: Rahmen : Bremse
Bezeichnung = Longlast Bezeichnung = LX-20
Rahmennr = R-9987 Hersteller = Hercules
Material = Aluminium Kategorie = Handbremse
196
6.2 Grundelemente der Objektorientierung: Assoziationen
Spezielle Assoziation: Komposition

l Komposition: spezielle Aggregation
l Existenz der Teile hängt von Existenz des Ganzen ab.
l Hier: Ohne Auftrag keine Positionen und keine Rechnung
: Auftrag
Nummer = A-12345
Datum = 15. Mai 2001
Wert = 200.000 [DM]
1 1
hat gehört zu
1 n
: Auftragsposition : Rechnung
Posnr = PO-98765 Nummer = R-232323
Artikelnr = AR-1245 Betrag = 300.000 [DM]
Menge = 300 Zahlungsart = Bar
197
6.2 Grundelemente der Objektorientierung: Vererbung
Vererbung: Beziehungen zwischen (Ober- und Unter-) Klassen

l Generalisierungs-/Spezialisierungsbeziehung zwischen den beteiligten Klassen
l Vererbung: Beziehung zwischen allg. Ober- und spezialisierten Unterklassen
Insekten
Ur-Insekten Flug-Insekten
Springschwänze Ein Flügelpaar Zwei Flügelpaare

Beintastler
Borstenschwänze Libellen
198 Bsp. “Taxonomie” (Einordnung in ein biologisches System)
Vererbung: Beziehungen zwischen (Ober- und Unter-) Klassen

l Vererbung (generalization) bedeutet, daß eine spezialisierte Klasse (Unterklasse,
abgeleitete Klasse, subclass) über die Eigensschaften, das Verhalten und die
Assoziationen einer oder mehrerer allgemeiner Klassen (Oberklassen,
Basisklassen, supperclasses) verfügen kann.
l Eine Unterklasse ist vollständig konsistent mit ihrer Oberklasse, enthält aber i. d.
R. zusätzliche Attribute, Operationen und/oder Assoziationen.
l Jede Klasse “kennt” nur ihre eigenen Attribute, Operationen und Assoziationen
und die ihrer Oberklassen(n), sofern diese für die Unterklasse sichtbar sind.
l Für eine Oberklasse sind generell die Attribute, Operationen und Assoziationen
ihrer Unterklassen nicht sichtbar.
l Die Vererbungsbeziehung wird durch einen Pfeil zur Oberklasse gekennzeichnet.
.... oder ....

199
Vererbung: Abstrakte Klassen

l Generalisierungs-/Spezialisierungs-
: Person {abstract}
beziehung zwischen den beteiligten
Klassen Name
l Immer: Jedes Objekt der Unterklasse Adresse
“ist ein” (is a) Objekt der Oberklasse. Geburtsdatum
l Abstrakte Klassen werden nur modelliert, drucke Adreß-
um ihre Informationen an spezialisierte aufkleber ()
Klassen zu vererben.
l Von einer abstrakten
Klasse können keine
(realen) Objekte erzeugt : Kunde : Mitarbeiter
werden. Im Bsp.: Es gibt Branche Abteilung
konkret nur Kunden und Umsatz Gehalt
Mitarbeiter, keine Status Familienstand
“Personen”.
ermittele durch- erstelle Urlaubs-
schnittl. Umsatz () plan ()
200
Vererbung: Einfachvererbung
l Bei der “Einfachvererbung” hat jede Klasse genau 1 direkte Oberklasse (mit
Ausnahme der Wurzel).
l Es entsteht eine Hierarchie in Form eines (umgedrehten) Baumes.
Oberklasse (Wurzel) Kraftfahrzeug
Unterklasse
PKW LKW
Oberklasse
Unterklasse Limousine Caravan Sattelschlepper Auflieger
201
Vererbung: Mehrfachvererbung
l Bei der “Mehrfachvererbung” (multiple Vererbung) kann jede Klasse mehrere
direkte Oberklassen haben (mit Ausnahme der Wurzel).
l Problem: Eine Klasse kann z. B. zwei Attribute oder Operationen gleichen
Namens von verschiedenen Oberklassen erben. Konfliktlösung erforderlich.
Oberklasse (Wurzel) Fahrzeug
Unterklasse
Landfahrzeug Wasserfahrzeug
Oberklasse
Unterklasse PKW LKW AmphibienFZ Schiff
202
6.2 Grundelemente der Objektorientierung: Nachrichtenaustausch
Nachrichtenaustausch: Grundlegendes
l Die Funktionalität (das dynamische Verhalten) eines objektorientierten Systems
ist in den Operationen seiner Objekte hinterlegt.
l Die Realisierung dieser Funktionalität setzt voraus, daß die Operationen
verkettet werden können.
l Dazu müssen Beziehungen zwischen den beteiligten Objekten bestehen. Die
Objekte müssen “sich kennen” (Vererbungsbeziehungen, Assoziationen).
l Die Operationen der Objekte müssen “aufgerufen, initialisiert” werden.
l Dies geschieht über “Botschaften” (Nachrichten) als “Operationsausführungs-
anweisungen” zwischen den beteiligten Objekten.
l Die Botschaft (message) trägt den Namen der Operation, die sie aufruft.
Objekt 1 : Klasse A Objekt 1 : Klasse B

Attribut 1 = Operation B1 () Attribut 1 =
Attribut 2 = Attribut 2 =
Operation A1 () Operation B1 ()
Operation A2 () Operation B2 ()
203
Nachrichtenaustausch: Polymorphismus
l Der Empfänger interpretiert die Botschaft, führt seine Operation aus und schickt
das Ergebnis an den Sender zurück.
l Der Sender weiß nicht, wie die Operation vom Empfänger ausgeführt wird.
l Die Menge der Botschaften, auf die die Objekte einer Klasse reagieren können,
wird als Protokoll der Klasse bezeichnet.
l Polymorphismus: Bei der Versendung 1 Botschaft an Objekte verschiedener
Klassen können verschiedene Operationen mit verschiedenen Ergebnissen
ausgelöst werden.
l Bspw. “drucken ()” gesendet an die Klassen “Auftrag” und “Buch”
Hans Müller : Mitarbeiter A-9876543 : Auftrag

Persnr = 1234567890 Anr = 98786543
Abteilung = Vertrieb Datum = 12.10.2001
Funktion = Sachbearbeiter ändern () Wert = 200.000 [DM]
Kunden kontaktieren () drucken ()
Auftrag aufnehmen () ändern ()
204
Auftrag betreuen () löschen ()
Nachrichtenaustausch in einer Vererbungsstruktur

l Erhält ein Objekt in einer
Vererbungsstruktur eine Botschaft, : Person {abstract}
“sucht” es in der Liste seiner eigenen
Name
Klasse nach einer Operation, mit der es
Adresse
reagieren kann.
Geburtsdatum
l Findet das Objekt dort keine ausführbare
Operation, wird die Suche in der direkten drucke Adreß-
Oberklasse fortgesetzt (usw.). aufkleber ()
l Bsp.: Erhält das Kundenobjekt

Müller die Botschaft “drucke
Adreßaufkleber ()”, wird die
: Kunde : Mitarbeiter
entsprechende Operation der
direkten Oberklasse “Person” Branche Abteilung
ausgeführt. Umsatz Gehalt
Status Familienstand
ermittele durch- erstelle Urlaubs-
schnittl. Umsatz () plan ()
205
6.2 Grundelemente der Objektorientierung: Überblick
Die Grundelemente der Objektorientierung im Überblick

l Die wichtigsten Konstrukte der OO wurden erläutert, um einen Überblick zur
Objektorientierung im allgemeinen zu geben.
- Objektbildung - Assoziationen - Nachrichtenaustausch

- Kapselung - Vererbung - Polymorphismus
- Klassenbildung
l Autoren wie z. B. Coad/Yourdon (OOA), Rumbaugh (OMT), Jacobsen (OOSE)
bündelten, erweiterten, variierten die grundlegenden Konstrukte in je eigener
Weise und verwendeten je eigene (graphische und textuelle) Darstellungsformen
(Notationen) für ihre eigenen Methoden der objektorientierten Analyse/Entwurf.
l Grob: Jeder Autor lieferte also je seine bestimmte Menge von Konzepten (was ist
wie darzustellen? = Ergebnissicht) und sein Vorgehensmodell zur Anwendung
der Konzepte (in welchen Schritten wird was ausgeführt, um ein System zu
modellieren? = Prozeßsicht).
l Ergebnis 1: Verschiedene konkurrierende OO-Ansätze
l Ergebnis 2: Bedürfnis nach Vereinheitlichung, Standardisierung der OO-Ansätze
206
6.3 Die Unified Modeling Language (UML): Entstehung
Chronologie zur Unified Modeling Language (UML)

l 1994: Rumbaugh wechselt zu Rational, wo bereits Booch arbeitet.
l 1995: Booch und Rumbaugh veröffentlichen “Unified Method”
l 1995: Rational kauft Objectory, wo Jacobsen arbeitet.
l 1995 - 1997: Booch, Rumbaugh, Jacobsen (”drei Amigos”) erarbeiten die UML
l 1996: UML Ver 0.91 wird veröffentlicht
l 1997: Die Object Management Group (OMG) standardisiert UML Ver 1.1
l 1998: UML Ver. 1.2 wird freigegeben
l 1999: UML Ver. 1.3 wird veröffentlicht
l Nov. 2000: UML Ver. 1.4 als Betaversion veröffentlicht
l Ende 2002: Im Auftrag der OMG wird an UML 2.0 gearbeitet
l Maerz 2005: Freigabe der UML Version 2.0 durch die OMG
Die UML hat sich inzwischen als die Standard-Notation
207
der Objektorientierung durchgesetzt.
6.3 Die Unified Modeling Language (UML): Charakteristika
Zur Bedeutung des Begriffs “Unified”

l Vereinheitlichung historischer OO-Begriffe und -Notationen: Allgemein
akzeptierte Begriffsbildungen aus dem OO-Bereich zusammenführen
l Unterstützung einer durchgängigen (einheitlichen) Methodik über alle Phasen der
Systementwicklung: Nahtloser Übergang von Req. Eng. bis zur Implementierung
l Einheitliche Modellierung bei unterschiedlichen Einsatzgegebenheiten: kleine,
große, verteilte, Real-time, rechenintensive, datenintensive Systeme etc.
l Vereinheitlichung bezgl. verschiedener Programmiersprachen und
Ablaufumgebungen: Identisches Front-End bei flexiblem Back-End
l Vereinheitlichung unterschiedlicher Modellierungsperspektiven: Daten-,
Funktions-, Organisations-, Steuerungssicht; flexibel erweiterbar
Die UML als die “eierlegende Wollmilchsau”

für die konzeptionelle System-Modellierung!?
208
Was die UML ist und was sie nicht ist

l Die UML ist keine Programmiersprache.
l Die UML ist keine Methode zur Systementwicklung.
N E I N
l Die UML ist/hat kein Vorgehensmodell.
l Die UML ist eine der Objektorientierung verpflichtete Technik. JA

l Technik: Kollektion von Beschreibungsmitteln, Modellierungssprache
“UML is not intended to be a complete development method.

It does not include a step-by-step development process.”
Rumbaugh, J.; Booch, G.; Jacobsen, I.: The UML Reference Manual, Addison-Wesley 1999, S. 8.
209
Wie “funktioniert” die UML?

l Die UML stellt für die Grundelemente der Objektorientierung (siehe Abschnitt 6.2)
UML-eigene Notationselemente zur Verfügung (Klasse, Assoziationen etc.)
l Darüber hinaus verügt die UML über weitere Notationselemente, die aus den
zugrundeliegenden OO-Methoden entstanden sind und möglichst alle Aspekte
eines zu modellierenden Systems darstellen können sollen.
l Die Notationselemente (die darzustellenden Aspekte) werden (häufig) “Konzepte”
(engl.: Classifier) genannt.
l Bei der Systemmodellierung werden aus jeweils bestimmten Notationselementen
verschiedene Diagramme erzeugt (z. B. Klassen- oder Interaktionsdiagramm)
l Jedes Diagramm verdeutlicht eine bestimmte Perspektive (Sicht) auf das zu
modellierende System (z. B. Sicht des Systembenutzers, statische Sicht, Sicht
der Abläufe, Sicht der Implementierungskomponenten etc.)
Menge von Verschiedene Diagramme Verschiedene Sichten

Notationselementen auf das zu mod. System
System
210
Wie “funktioniert” die Systemmodellierung mit der UML?

l Die UML legt fest, welche Diagramme aus welchen Notationselementen gebildet
werden und welche Sichten mit den Diagrammen erzeugt werden.
l Die UML liefert keinen Plan, in welcher Reihenfolge welche Diagramme erzeugt
und weiterentwickelt werden sollen, um ein System schrittweise zu modellieren.
l Es bleibt den Entwicklern überlassen, sich solche Vorgehensmodelle durch die
passende Zusammenstellung (”methodische Durchgängigkeit”) von Sichten,
Diagrammen und Konzepten zu “bauen”.
l Der Mangel an Vorschriften zur “Prozeßsicht der Systementwicklung” (siehe
Abschnitt 2) ist gleichzeitig ein Vorzug der UML: Sie erlaubt (fordert auf),
problemangepaßte Vorgehensmodelle zu entwickeln.
Analyse Menge von Verschiedene Verschiedene

Vorgehens-
Notationselementen Diagramme Sichten

modell ?
Entwurf
System
Implement.
211
Charakteristika der UML

l Die UML hat nicht die verschiedenen OO-Analyse-Entwurfs-Methoden (OOA,
OMT, OOSE etc.) zusammengeführt.
l Die UML stellt lediglich eine standardisierte objektorientierte Modellierungsspra-
che dar, die präziser und vollständiger ist als die Sprachen, die die o. g. OO-
Methoden aufwiesen.
l Die UML ist eine semi-formale Technik; sie dient zur Vereinheitlichung und
Strukturierung prosaischer Formulierungen.
l Die UML verfügt über eine Vielzahl vom Diagrammarten, mit denen die
Grundelemente der OO, eine Vielzahl deren Varianten und Erweiterungen sowie
alle Phasen der Systementwicklung von der Analyse über den Entwurf bis zur
Implementierung unterstützt werden.
l Erst seit 1998 existiert mit “Rational Unified Process” ein Vorgehensmodell
(Prozeßsicht) mit explizitem Bezug zur UML.
212
6.3 Die Unified Modeling Language (UML): Sichten, Diagramme, Konzepte
Sichten, Diagrammarten und Konzepte in der UML

l Mit der UML können verschiedene Sichten auf ein (zu modellierendes) System
mit bestimmten Diagrammarten (und Notationselementen) dargestellt werden.
Sicht/Abstraktion Diagrammart Konzepte (Notationselemente)

Statische Klassen- Klasse, Assoziation, Attribut, Operation
Dynamische Zustands- Zustand, Ereignis, Transition, Aktion
Systemnutzung Anwendungsfall- Anwendungsfall, Akteur, Assoz

Sprache

Schwickert 2009 - Scriptum Zur Vorlesung Im Master-Modul

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Schwickert 2009 - Scriptum Zur Vorlesung Im Master-Modul

Hochgeladen von

Copyright:

Verfügbare Formate

JUSTUS-LIEBIG-UNIVERSITÄT GIESSEN

ALLG. BWL UND WIRTSCHAFTSINFORMATIK

Scriptum zur Vorlesung im Master-Modul

Univ.-Prof. Dr. Axel C. Schwickert

1. Struktur und Ziele der Vorlesung .................................................................................. 1

2. Grundlagen der Modellierung betrieblicher IKS ........................................................... 8

3. Funktionsorientierte Modellierung .............................................................................. 71

4. Datenflußorientierte Modellierung ............................................................................... 94

5. Datenorientierte Modellierung ................................................................................... 112

6. Objektorientierte Modellierung .................................................................................. 178

7. Prozeßmodellierung mit ARIS .................................................................................... 243

Falls ausgewählte Quellen in den einzelnen Abschnitten der Begleitunterlagen angegeben

Balzert, Helmut: Lehrbuch der Software-Technik – Band 1: Software-Entwicklung.

Gadatsch, Andreas: Management von Geschäftsprozessen.

Vorlesung zur Wirtschaftsinformatik

Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 1

Systems Engineering: Organisatorisches

 Master: 02-BWL: MA-B9-01  Master-Modul besteht aus:

 Diplom: 2 SWS Vorlesung, Tiefenfach Wirtschaftsinformatik

 Prüfung: Diplom: 90 Min. Klausur = 3 CP / Stoff: Vorlesung

 Scriptum: http://wi.uni-giessen.de/  Download-Center / SPIC

 Dozent: Univ.-Prof. Dr. Axel C. Schwickert

Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 2

Systems Engineering: Organisatorisches

1. Donnerstag, 15. Oktober 2009

Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 3

Systems Engineering: Organisatorisches

 Klausur: Spätestens 2 Wochen nach Ende der Vorlesungszeit

 Kontakt: eMail: Axel. Schwickert@wirtschaft.uni-giessen.de

 Infos: http://wi.uni-giessen.de oder SPIC

Über die Web Site erhalten Sie aktuelle

Papieraushänge und gedruckte Skripten

Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 4

Systems Engineering: Organisatorisches

Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 5

Systems Engineering: Organisatorisches

Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 6

Systems Engineering: Organisatorisches

Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 7

Systems Engineering: Organisatorisches

Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 8

Literatur zur Vorlesung

 Balzert, Helmut: Lehrbuch der Soft-  Gadatsch, Andreas: Management

Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 9

 Das Wirtschaftsstudium – WISU

Systems Engineering – WS 09/10 – Prof. Dr. Schwickert 10

Vorlesung im Master und zum Wahlfach Wirtschaftsinformatik

Prof. Dr. Axel C. Schwickert

Systems Engineering - Modellierung von IuK-Systemen

1 Struktur und Ziele der Vorlesung

Wirtschaftsinformatik - Wintersemester 09/10

Gegenstand der WI: IuK-Systeme in Wirtschaft und Verwaltung

Handhabung der Komplexität von IuK-Systemen

1.1 Gegenstand, Charakter, Ziele der Wirtschaftsinformatik

Wissenschaftstheoretischer Charakter der Wirtschaftsinformatik

Ziele und methodischer Ansatz der Wirtschaftsinformatik

Komplexe Landschaft von IKS im Unternehmen

Verschiedene Sichten (Perspektiven) auf IKS

- System-Umwelt und ihre Beziehungsstruktur erkennen

1.2 Zur Bedeutung von Modellen und Modellierungsansätzen

Ergebnissicht: Was ist zu modellieren?

Ergebnissicht: Anforderungen an das Modellieren

Lernziele: Sie sollten wissen, .....