Scriptum zur Vorlesung im Master-Modul · 4 Aufbau einer Methode mit der Unified Modeling Language...

JUSTUS-LIEBIG-UNIVERSITÄT GIESSEN

ALLG. BWL UND WIRTSCHAFTSINFORMATIK

UNIV.-PROF. DR. AXEL C. SCHWICKERT

Scriptum zur Vorlesung im Master-Modul

Systems Engineering

Wintersemester 09/10

Univ.-Prof. Dr. Axel C. Schwickert

JLU Gießen – Vorlesung „Systems Engineering“ – Master – WS 09/10

Gliederung 1. Struktur und Ziele der Vorlesung .................................................................................. 1 1 Gegenstand, Charakter und Ziele der Wirtschaftsinformatik ........................................ 3 2 Zur Bedeutung von Modellen und Modellierungsansätzen ........................................... 5 3 Anvisierte Lernziele der Vorlesung ............................................................................... 7 2. Grundlagen der Modellierung betrieblicher IKS ........................................................... 8 1 Prozeß- und Systemgestaltung .................................................................................... 9 2 Systemtheoretische Grundlagen ................................................................................ 23 3 Graphen und Petri-Netze ............................................................................................ 30 4 Prinzipien für die Entwicklung von betrieblichen IKS .................................................. 59 5 Objekte und Sichtweisen der Modellierung von betrieblichen IKS ............................. 62 3. Funktionsorientierte Modellierung .............................................................................. 71 1 Funktions- und Verrichtungsorientierung .................................................................... 72 2 Funktionsorientierte Modelle ....................................................................................... 74 3 Wandel zur Prozeßorientierung .................................................................................. 89 4. Datenflußorientierte Modellierung ............................................................................... 94 1 Datenflußorientierte Modellierungsansätze ................................................................ 95 2 SADT – Structured Analysis and Design Technique .................................................. 96 3 SA – Structured Analysis (Tom DeMarco) ................................................................ 105 5. Datenorientierte Modellierung ................................................................................... 112 1 Datenorientierte Modellierungsansätze .................................................................... 113 2 Daten, Datenmanagement und Datenmodellierung ................................................. 114 3 Vorgehen bei der Datenmodellierung ....................................................................... 130 4 ERM – Entity Relationship Modeling ........................................................................ 136 6. Objektorientierte Modellierung .................................................................................. 178 1 Zum Paradigma der Objektorientierung .................................................................... 179 2 Grundelemente der Objektorientierung .................................................................... 188 3 Die Unified Modeling Language (UML): Entstehung, Charakteristika, Elemente ..... 207 4 Aufbau einer Methode mit der Unified Modeling Language (UML) ........................... 215 7. Prozeßmodellierung mit ARIS .................................................................................... 243 1 Geschäftsprozeßorientierung und Workflow Management 2 Grundlagen der Prozeßmodellierung 3 WBT-Serie zur Geschäftsprozeßmodellierung mit ARIS

JLU Gießen – Vorlesung „Systems Engineering“ – Master – WS 09/10

Literatur Falls ausgewählte Quellen in den einzelnen Abschnitten der Begleitunterlagen angegeben sind, ergänzen und vertiefen diese Quellen die jeweiligen Stoffe. Die Lektüre dieser Quellen wird empfohlen, ist aber fakultativ. Die einschlägigen Kapitel der folgenden Quelle gelten als Pflichtlektüre für die Hörer der Vorlesung:

Balzert, Helmut: Lehrbuch der Software-Technik – Band 1: Software-Entwicklung. 2. Aufl., Heidelberg, Berlin : Spektrum Akademischer Verlag 2000. (ISBN 3827404800)

Gadatsch, Andreas: Management von Geschäftsprozessen.

2. Aufl., Braunschweig/Wiesbaden: Viehweg 2002. (ISBN 3528157593)

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

Systems Engineering

Vorlesung zur Wirtschaftsinformatik

Justus-Liebig-Universität Gießen

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

Prof. Dr. Axel C. Schwickert

Master: 02-BWL: MA-B9-01 Master-Modul besteht aus:2 SWS Vorlesung Systems Engineering2 SWS Übung: IT-Sicherheitsmanagement (Falk)

Systems Engineering: Organisatorisches

Diplom: 2 SWS Vorlesung, Tiefenfach Wirtschaftsinformatik

Prüfung: Diplom: 90 Min. Klausur = 3 CP / Stoff: VorlesungMaster: 90 Min. Klausur Vorl./Üb + Projekt-Präs. Üb.

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

Dozent: Univ.-Prof. Dr. Axel C. SchwickertProfessur für BWL und WIJustus-Liebig-Universität GießeneMail: Axel.Schwickert@wirtschaft.uni-giessen.de

1. Donnerstag, 15. Oktober 20092. Donnerstag, 22. Oktober 20093. Donnerstag, 29. Oktober 20094. Donnerstag, 05. November 20095 Donnerstag 12 November 2009

VL-Termin:Vorlesung

5. Donnerstag, 12. November 20096. Donnerstag, 19. November 2009 WBT 1 statt Vorles.7. Donnerstag, 26. November 2009 WBT 2 statt Vorles.8. Donnerstag, 03. Dezember 2009 WBT 3 statt Vorles.9. Donnerstag, 10. Dezember 2009 WBT 4 statt Vorles.10. Donnerstag, 17. Dezember 2009 WBT 5 statt Vorles.

Donnerstag, 24. Dezember 2009 FerienDonnerstag, 31. Dezember 2009 Ferien

gDonnerstags,10.15 Uhrbis 11.45 Uhr

VL-Ort:Vorlesung imRaum 031 (HS 031)

Donnerstag, 07. Januar 2010 Ferien12. Donnerstag, 14. Januar 2010 Ferien13. Donnerstag, 21. Januar 201014. Donnerstag, 28. Januar 201015. Donnerstag, 04. Februar 2010

Klausur: Spätestens 2 Wochen nach Ende der Vorlesungszeit

Kontakt: eMail: Axel. Schwickert@wirtschaft.uni-giessen.deOder Sprechzeit nach den VorlesungenO S

Oder Sprechzeit nach Vereinbarung

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

Über die Web Site erhalten Sie aktuelleInformationen und per Download alle Skripten zu allen Lehrveranstaltungen

Skripten zu allen 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-ware-Technik – Band 1: Software-Ent-wicklung. 2. Aufl., Heidelberg, Berlin: Spektrum Akademischer Verlag 2000.

Gadatsch, Andreas: Management von Geschäftsprozessen. 2. Aufl., Braunschweig/Wiesbaden:Viehweg 2002.

Empfohlene Zeitschriften

Das Wirtschaftsstudium – WISUAllgemein sehr förderlich für Studierendeder Wirtschaftswissenschaften

c´t: Technik! Wirtschaftsinformatik

Pflicht für Studierendeder Wirtschaftsinformatik

IT-ZeitungenWöchentlich!

Vorlesung im Master und zum Wahlfach Wirtschaftsinformatik

Systems Engineering - Modellierung von IuK-Systemen

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

1.1 Gegenstand, Charakter, Ziele der Wirtschaftsinformatik

Gegenstand der WI: IuK-Systeme in Wirtschaft und Verwaltung

Handhabung der Komplexität von IuK-Systemen

IKS sind sozio-technische Systeme

Befriedigung der Informationsnachfrage zur Erfüllung von Aufgabenin Wirtschaft und Verwaltung

Koordination arbeitsteilig wirkender Aufgabenträger

Komponenten von IKS

Arten von IKS unterscheiden

isolieren, untersuchen, integrieren

Komponenten von IKS: Funktionen, Daten, Objekte, Schnittstellen

durch Fokussierung auf Unternehmen,Arbeitsgruppen, Einzelpersonen, Branchen, betriebliche Funktionen,unternehmensübergreifende Funktionen.

Wissenschaftstheoretischer Charakter der Wirtschaftsinformatik

Ziele und methodischer Ansatz der Wirtschaftsinformatik

Realwissenschaft:

Formalwissenschaft:

Ingenieurwissenschaft:

Untersuchungsgegenstand sind Phänomene der Wirklichkeit

Beschreibung, Erklärung, Prognose und Gestaltungder IKS bedürfen der Entwicklung und Anwendung formalerBeschreibungsverfahren und Theorien

Die Gestaltung von IKS verlangt nach einerKonstruktionssystematik

Erkenntnisziel der WI:

Praxiskontakte

Gewinnung von Theorien, Methoden und Werkzeugenzur Beschreibung und Erklärung von IKS, zur Prognose des Systemverhaltensund zur Gestaltung “besserer” Systeme

zur Gewinnung und Validierung von Erkenntnissen über IKSsind unverzichtbar (empirisch, induktiv, realistisch).

1.1 Gegenstand, Charakter, Ziele der Wirtschaftsinformatik

1.2 Zur Bedeutung von Modellen und Modellierungsansätzen

Komplexe Landschaft von IKS im Unternehmen

Verschiedene Sichten (Perspektiven) auf IKS

- System-Umwelt und ihre Beziehungsstruktur erkennen

- Systeme, ihre Bestandteile und ihr Funktionieren verstehen

- Komplexität beherrschbar machen

Modelle:

Vielzahl von IKS

Integration der IKS

für verschiedene Funktionalbereiche (z. B. Beschaffung,Produktion, Absatz, Rechnungswesen) oder Verwendungszwecke (Planung,Steuerung, Kontrolle, Leistungserbringung) im Unternehmen

in der Regel erforderlich

Entwickler:

Organisatoren:

Management:

Benutzer:

Modelle, Methoden, Werkzeuge, Programmierung

Aufgaben, Abläufe, Aufgabenträger, Anforderungen

Planung, Steuerung, Kontrolle von IKS-Entwicklung und -Nutzung

Aufgabenerfüllung, Anforderungen, Oberflächen, Verhalten, Bedienung

1.2 Zur Bedeutung von Modellen und Modellierungsansätzen

Ergebnissicht: Was ist zu modellieren?

Ergebnissicht: Anforderungen an das Modellieren

Modell: Eine idealisierte, vereinfachte in gewisser Hinsicht ähnliche Darstellungeines Gegenstands, Systems oder sonstigen Weltausschnitts mit dem Ziel,daran bestimmte Eigenschaften des Vorbilds besser analysieren zu können(Balzert, S. 100)

Wie das Modell eines IKS erstellt wird und wie es aussieht, hängt vomEntwicklungsparadigma, dem Verwendungszweck des Modells und häufig auchvom Anwendungsbereich des zu modellierenden IKS ab.

Nutzen:

Verständlichkeit:

Standardisierung:

Zweckgerichtet umfassende und genaue Abbildung desVorbilds erforderlich

Die Modelldarstellung muß der zweckgerichteten Verwendungdes Modells (z. B. System-Analyse, -Optimierung, -Modifikation) förderlich sein.

Die Festlegung auf ein Set von Modellierungskonventionenfördert Vergleichbarkeit, Erlernbarkeit, Verständlichkeit.

1.3 Anvisierte Lernziele

Lernziele: Sie sollten wissen, .....

..... welche Ansätze und Prinzipien für die Modellierung vonbetrieblichen IKS zur Verfügung stehen,

..... wie IKS modelliert werden,

..... wie IKS mit SA, SADT modelliert werden,

..... wie IKS per ERM modelliert werden,

..... wie IKS mit ARIS und EPKs modelliert werden,

..... wie IKS mit der UML modelliert werden.

funktionsorientiert

datenflußorientiert

datenorientiert

objektorientiert

prozeßorientiert

Gliederung

2.1 Prozeß- und Systemgestaltung

Zwei Sichten der Planung von (Organisations-) Systemen

Prozeßsicht der IKS-Planung, -Entwicklung

Ergebnissicht der IKS-Planung, -Entwicklung

Ergebnissicht:

Prozeßsicht:

Das “Was” der Planung - die Systemgestaltung

Die Vorgehensweise der Planung - die Prozeßgestaltung

Vorgehensmodelle:

Methodische Durchgängigkeit:

Wie z. B. sequentielle Phasenmodelle, evolutionäreSpiralmodelle, Prototyping-Modelle (RAD) etc.

Die einzelnen Prozeßschritte werden durchaufeinander abgestimmte Analyse- und Darstellungstechniken unterstützt (z. B.durch ein Bündel von UML-Konzepten).

Modellierungsansätze:

Prinzipien:

Wie z. B. funktions-, datenfluß-, daten-, prozeß- oderobjektorientierte Modellierung

Grundlagen der Systemtheorie, Abstraktion, hierarchischeStrukturierung, schrittweise Verfeinerung, Modularisierung

2.1 Prozeß- und Systemgestaltung

Prozeßsicht: Gliederung von Software-Entwicklungsprojekten

Prozeßsicht: Vorgehensmodelle zur Entwicklung von IKS

Für die sachliche und zeitliche Gliederung von SWE-Projekten gibt es eine Füllevon Vorschlägen, deren gemeinsamer Nenner ein allgemeines gestuftesVorgehen ist.

Siehe dazu nachfolgend das “Allgemeine Vorgehensmodell” und seine“Wasserfallstruktur”.

Es lassen sich folgende Grundformen unterscheiden:

Sequentielle Vorgehensmodelle

Parallel-sequentielle Vorgehensmodelle

Evolutionäre Vorgehensmodelle

Agile Vorgehensmodelle

2.1 Prozeß- und Systemgestaltung: Allgemeines Vorgehensmodell

Projektplanung Projekt-realisierung

Projekt-kontrolle

Projektmanagement

2.1 Prozeß- und Systemgestaltung: Allg. VG-Modell - Wasserfallstruktur

1. Schritt

3. Schritt

2. Schritt

4. Schritt

5. Schritt

Vorprojekt

Detailprojekt

Systembau,Systemeinführung und -übergabe

Systemnutzung

Hauptprojekt

2.1 Prozeß- und Systemgestaltung: Allg. VG-Modell - Phasen

Phasen derSystementwicklung

(allgemein)

(Stahlknecht 2002)

Phasenbezeichnung Phaseninhalt

Vorphase

Analyse

Entwurf

Realisierung

Einführung

Projektbegründung

Istanalyse- Erhebung des Istzustands- Bewertung des Istzustands

Sollkonzept- Fachentwurf- IV-Grobentwurf- Wirtschaftlichkeitsvergleiche

SystementwurfProgrammspezifikationProgrammentwurf

ProgrammierungTest

SystemfreigabeSystemeinführung

2.1 Prozeß- und Systemgestalt.: Allg. VG-Mod. - Phasen, Aktivitäten, Ergebnisse

· · ·

auftra

rmulie

wähle

ktprioritä

· · · ·

übera

rbeite

ariante

rbeite

chaftlic

itüberp

lanung

· · · · · · · ·

überp

ituatio

tandort

öglic

rbeite

chaftlic

enüberlegungen

· · ·

ktauftra

· ·L

ehensk

ilplä

· · · ·

realis

rbeite

chaftlic

chnung

rhalts

führu

· · ·

(Lösu

benutz

en,abnehm

chaftlic

itüberp

führu

· ·S

rhalts

2.1 Prozeß- und Systemgestalt.: Allg. VG-Mod. - Phasen, Aktivitäten, Ergebnisse

Vorphase

Phase Analyse

Phase Entwurf

Phase Realisierung

Phase Einführung

Projekt-begründung

Istanalyse

Sollkonzept

Systementwurf

Programmentwurf

Programmierungund Test

Anpassung derStandardsoftware

Auswahl undAnschaffung vonStandardsoftware

System-einführung

Eigen-entwicklung Fremdbezug

Vorghehensmodell derSystementwicklung

(allgemein)

(Stahlknecht 2002)

2.1 Prozeß- und Systemgestaltung: Sequentielles VG-Modell “Wasserfallmodell”

Situations-studie

Fach-konzeption

System-konzeption

System-entwicklung

System-installation

Meilen-stein

Situations-studie

Validierung

Meilen-stein

Fachkon-zeption

Validierung

Meilen-stein

System-konzep-tion

Validierung

Meilen-stein

System-entwick-lung

Validierung

Meilen-stein

System-installa-tion

Validierung

2.1 Prozeß- und Systemgestaltung: Sequentielle Vorgehensmodelle

Sequentielle Vorgehensmodelle: Merkmale

Sequentielle Vorgehensmodelle: Eignung

Auch “Phasenkonzepte” genannt

Folgen dem Prinzip der “schrittweisen Verfeinerung”

Phasenergebnisse (”Meilensteine”) pro Phase zu definieren

Folgephase beginnt, wenn vorhergehende Phase vollständig abgeschlossen ist

Wasserfallmodell sieht (die in der SW-Entwicklung allfälligen) Rücksprünge vor

Anforderungen an zu entwickelndes IKS liegen präzise vor

Wenig komplexe IKS

IKS mit relativ stabilem Projektumfeld

IKS, die relativ wenig Arbeitsteilung erforden

2.1 Prozeß- und Systemgestaltung: Parallel-sequent. VG-Modell “V-Modell”

Legende: P

ivitä

2.1 Prozeß- und Systemgestaltung: Parallel-sequentielle Vorgehensmodelle

Parallel-sequentielle Vorgehensmodelle: Merkmale

Parallel-sequentielle Vorgehensmodelle: Eignung

Überlappte, zeitlich versetzte Arbeitsschritte phasenintern und phasenübergreifend

Keine Fixierung mehr auf umfassende, monolithische Phasenresultate

Statt dessen kleinere Leistungseinheiten (”Arbeitspakete”) zu definieren

V-Modell: Bündel aus Submodellen (PM, QM, Konfig.-Man., SW-Erstellung)

Für komplexere Projekte (V-Modell gültig im öffentlichen Sektor)

Realitätsnäher als rein sequentielle Vorgehensmodelle

Kleinere, einzeln abprüfbare Teilkomponenten

Änderungen im Projektumfeld können flexibler berücksichtigt werden

Nachteil: Vergleichsweise hoher Koordinationsaufwand

2.1 Prozeß- und Systemgestaltung: Evolutionäres VG-Modell - Grundstruktur

System-installation

System-realisierung

System-konzeption

Fach-konzeption

Situations-studie E

Phasen

Legende:

EntwickelnRealisierenValidieren

2.1 Prozeß- und Systemgestaltung: Evolutionäres VG-Modell “Sprialmodell”

Risiko-analyse

Vorgehens-konzept

Anforde-rungen

Validierungder Anforde-rungen

Entwick-lungsplan

Validierung desEntwurfs

Installa-tion

Akzeptanz-test

Integra-tion undTest

Modul-test

Codie-rung

Reali-sierung

Entwurf

Ziele,Alternativen,Randbedingungenfestlegen

KumulierteKosten

schrittweisesVorgehen Alternativen und

Risiken bewerten,Prototypen entwickeln

Prototyp 1

Prototyp

Integrationund Testplan

2.1 Prozeß- und Systemgestaltung: Evolutionäre Vorgehensmodelle

Evolutionäre Vorgehensmodelle: Merkmale

Evolutionäre Vorgehensmodelle: Eignung

Weitgehender Verzicht auf Sequentialisierung und vordefinierteZwischenergebnisse

Zwischenresultate werden durch “systematisches Probieren” in zyklisch gestufterAbfolge von Entwerfen, Realisieren und Validieren erzeugt.

Grundlage “Prototyping”: explorativ, experimentell, evolutionär

Spiralmodell (Böhm): inkrementell-iteratives Vorgehen

Innovative, komplexe IKS

Im voraus schwierig zu strukturierende IKS

Rapid Application Development

Nachteil: Meilenstein-Zäsuren verschwimmen

2.1 Prozeß- und Systemgestaltung: Agile Vorgehensmodelle

Agile Vorgehensmodelle: Merkmale

Agile Vorgehensmodelle: Eignung

V lliger Verzicht auf Sequentialisierung und vordefinierte Zwischenergebnisse

Geringe Regelungs und Dokumentationsdichte

Grundlage “Prototyping”: explorativ, experimentell, evolutionär

Hohe Eigenverantwortung, gestaltbare Abl ufe und Produkte

Beispiel: Extreme Programming

Innovative IKS mit hoher Unsicherheit

Umwelt, System, Anforderungen offen

Kleine IuK Systeme

Kleine Teams

Nachteil: Funktioniert nur mit

“Helden”

2.1 Prozeß- und Systemgestaltung: Agile Vorgehensmodelle

2.2 Systemtheoretische Grundlagen

Gegenstand der allgemeinen Systemtheorie

Hauptaspekte der Analyse und Gestaltung von Systemen

Zum Begriff “System”

Anordnung von Elementen zu einem System und die Analyse der Beziehungenzwischen den Elementen

Begründer: Ludwig von Bertalanffy, 1951

Wirkungsaspekte, Strukturaspekte

Abstraktion, Dekomposition

Ein System wird durch eine abgegrenzte und geordnete Menge von Elementengebildet, die untereinander in Beziehung stehen.

Das System bildet als Ganzes eine Einheit und läßt sich deutlich von seinerUmwelt abgrenzen.

System-Emergenz: Das Ganze ist mehr als die Summe seiner Teile.

System

Blackbox

Umweltbeziehungen

Umweltelement

Systemgrenze

Systemabgrenzung und Wirkungsanalyse

Umweltbeziehungen

Umweltelement

SystemgrenzeSystem

Strukturanalyse

Subsystem Subsystem

Gesamtsystem ProblemnaheEbene

Transformationsebene(n)

Schnittstelle

Teilaufgabe

Logische Komponente: suche, lies, schreibe ...

Teilaufgabe

Maschinennahe Ebene

Abstraktionund

schrittweiseVerfeinerung

Hauptsachverhalte

Vom Allgemeinenzum Speziellen

Top-down,hierarchisch

Gesamtsystem

Ebene 1

Input Output

GeordneteSammlungvon Moduln

Ebene 2

Ebene 3

Blockkonzept,Modularisierung

VollständigeSchachtelung

Logische Komp. =Bausteine, Moduln

Modul-Abgrenzung

Interne Struktur und funktionale Einheit

Input Output

Kontext und Schnittstellen

Black Box

Input Output1

Umsystem Umsystem

Mehrfach verwend-bare Moduln mitdefinierten Schnitt-stellen

Keine Nebeneffektebei Modul-Änderung/-Austausch

Unter-Modul

Sequenz

Selektion

Iteration

Kein Spaghetti Junction Design !

Beschränkung derStrukturblockarten

StandardisierteAblaufabbildungen

BeherrschbareDynamik

- - - - - - - -- -- - - - - - - -- -

Ausgang

2.3 Graphen und Petri-Netze

Graphentheorie

Zum Begriff “Graph”

Graph Gerichteter Graph

Formale Theorie, die Vorgänge und Abfolgen untersucht

Konzentriert sich auf Beziehungen zwischen Knoten und Kanten

Unter einem Graph versteht man eine Menge von , .....

..... die untereinander mit verbunden sind (siehe Begriff “System” !).

zeigen auch die Art der Verbindung (Richtung derEinflußnahme) zwischen den Knoten an.

Knoten

Kanten

Gerichtete Graphen

Anwendungsbereiche der Graphentheorie

Eulersches Brückenproblem

Operations Research: Quantitative Methoden zur Planung undEntscheidungsvorbereitung

Ingenieur- und wirtschaftswissenschaftliche Bereiche

� Euler 1736 in Königsberg: Gibt es einen Spazierweg über das Brückensystemder Pregel, bei dem jede Brücke genau einmal passiert wird?

Travelling-Salesman-Problem

� Ein Vertriebsbeauf-tragter will einebestimmte Mengevon Kunden auf einer

abklappern.

Rundreise mitminimaler Länge

Kunde 2

Kunde 1

Kunde 3

Kunde 4

Kunde 5

Kunde 6

Depot = Startort = ZielortZeit-/Weg-

minimierung

Kunde 2

Kunde 1

Kunde 3 Kunde 4

Kunde 5

Kunde 6

Depot = Startort = Zielort

Tour 1

Tour 2

Tour 3

Zeit-/Weg-und Kosten-minimierung

Touren-Problem

� Innerhalb eines best. Zeitraums ist eine best. Menge von Kunden mit einer best.Menge Lieferwagen mit best. Produktmengen möglichst effizient zu beliefern.

Depot 1

Depot 2

Depot 3

Kunde 1 Kunde 2 Kunde 3 Kunde 4

Kosten-minimierung $ $

Transport-Problem

� Von einer best. Menge an Depots aus ist eine best. Menge von Kunden (miteiner best. Menge Lieferwagen) mit best. Produktmengen möglichst effizient zubeliefern (keine Transport zwischen Kunden oder zwischen Depots).

Netzplantechnik (NPT)

� Große, komplexe Projekte planen, analysieren, steuern, kontrollieren, optimieren

Ablaufstrukturplan mit zeitbeanspruchenden und zeitpunktbezogenen Elementenmuß vorher erstellt worden sein

Zeitdauern und Vorgänger-/Nachfolgerbeziehungen sind bekannt.

2.3 Graphen und Petri-Netze: Exkurs “Petri-Netze”

Petri-Netze

Begründer: C. A. Petri, 1962, Ges. für Mathematik und Datenverarbeitung (GMD)

Petri-Netze sind gerichtete Graphen.

Petri-Netze sind keine Instrumente, um Fische zu fangen. (Stahlknecht)

Petri-Netze: Anwendungsbereiche

Petri-Netze: Elemente

Anwendungsneutral: Mit Petri-Netzen lassen sich Systeme und Abläufemodellieren, die auf diskreten Aktionen und Abhängigkeitsbeziehungen zwischendiesen Aktionen basieren.

Erlauben die Simulation der Modell-Dynamik mittels Verhaltensregeln.

Bspw. Modellierung, Analyse umd Simulation im Bereich derAutomatisierungstechnik

Wirtschaftswissenschaften: Modellierung von betrieblichen Abläufen alshochaktuelles Anwendungsgebiet - Geschäftsprozeß-Modellierung

U. a.: Geschäftsprozesse, Workflow-Management-Systeme, Customizing vonStandard-Anwendungssoftware

Statische Knoten-Elemente:

Kanten:

Dynamische Elemente:

Zustände (passiv) und Ereignisse (aktiv)

Kausal-logische Zusammenhänge zwischen Zuständen und Ereignissen

Marken (für Zustände)

Passive Elemente: Zustände (Kreise)

Kausal-logische Zusammenhänge: Kanten (Pfeile)

Aktive Elemente: Ereignisse (Rechtecke)

Zustand (auch: Stelle, Platz, Bedingung)

Momentane Lage, Situation eines Systems bzw. Stand eines Prozesses

Bspw: Lagerbestand, in Bearbeitung, offene Rechnung, warm, bereit

Zustände werden als Kreise dargestellt.

� Gerichtete Kanten = Pfeile

Ereignis (auch: Transition, Zustandsübergang, Aktion)

Bewirken den Übergang von einem Zustand in einen anderen Zustand

Bspw.: Lagerbewegung, bearbeitet, Bezahlung, Erhitzung, fertigstellen

Ereignisse werden als Rechtecke dargestellt.

Ereignisse und Zustände

Richtig:

Falsch:

Ein Ereignis beschreibt die Erzeugung, Veränderung, den Transport von z. B.Daten oder Rohstoffen bei der Realisierung von Prozessen.

Ein Ereignis setzt genau definierte und erfüllte Zustände voraus und/oder führt zueiner genau definierten Menge von Zuständen.

Die Beendigung eines Zustands erfolgt durch mind. ein Ereignis.

Der Beginn eines neuen Zustands wird von mind. einem Ereignis angestoßen.

Eingangszustand:

Ausgangszustand:

Zustände und Ereignisse wechseln sich immer ab: bipartider Graph

Ereignisse und Zustände Falsch Richtig

Wege beginnen und endennicht mit einer Kante.

Es gibt keine alleinstehendenKnoten.

Es gibt keine parallelverlaufenden Kanten.

Es gibt keine bidirektionalenKanten.

Zustand 1 Zustandsübergangkann eintreten, wennZustand 1 realisiert ist

Zustand 2wird durch den Ein-

tritt des Zustands-

übergangsrealisiert

Erteiltes

Angebot AuftragAuftrags-

bearbeitung

Eingangszustand Ausgangszustand

Dynamische Elemente: Marken (in Zuständen)

Durch das Setzen von Marken (Markierungen) in Zuständen wird die Dynamikeines Systems oder Prozesses abgebildet.

Jeder Zustand der realisiert ist, wird markiert.

Markiert wird durch einen Punkt.

Marken können exogen (empirische Beobachtung des Modellbenutzers) oderendogen (aufgrund der modellbedingten Kausal-Logik) verursacht sein.

Eine Zustandsübergang (Ereignis) kann “schalten” (durchgeführt werden), wennder Zustandsübergang aktiviert ist.

Ein Zustandsübergang ist aktiviert, wenn alle Eingangszustände markiert undalle Ausgangszustände markenfrei sind.

Es besteht kein Schaltautomatismus. Schaltvorgänge verbrauchen keine Zeit.

Erfolgt ein Zustandsübergang, werden von allen seinen Eingangszuständen dieMarken weggenommen und alle seine Ausgangszustände mit Marken belegt.

Diese Vereinbarung zum Setzen von Marken (Schalten des Zustands-übergangs) heißt “Schaltregel” (Transitions-, Simulationsregel, Firing Rule).

Markierungssituationen in Petri-Netzen

Unproblematische Situation: Aktivierung (Schaltbarkeit, Concession)

Wenn pro Zustand maximal 1 Marke zulässig ist, spricht man von einemBedingungs-/Ereignis-Netz (B/E-Netz).

Lokalitätsprinzip: Zustände und Ereignisse werden immer nur durch ihre direkte,lokale Umgebung beeinflußt (Kapselung, Modularisierung).

� Markierte Eingangszustände stehen unmarkierten Ausgangszuständengegenüber. Ereignis kann geschaltet werden.

Konflikt-Situation: Begegnung (Contact)

Mindestens 1 Ausgangszustand (hier A) ist bereits markiert. Das Ereignis kannmithin nicht schalten.

Kann eintreten, wenn A zugleich Ausgangszustand eines anderen Ereignisses istoder wenn nicht vorhergesehene exogene Störungen auftreten.

Konflikt-Situation: Verzweigung (Branch Conflict)

2 2C C

Die Anordnung der Elemente ermöglicht verschiedene Zustandsübergänge.

Die Schaltregel gibt keinen Aufschluß darüber, welches Ereignis schalten soll.

Lösung 1: Modellbenutzer bestimmt das schaltende Ereignis exogen.

Oder Lösung 2: Entscheidungsregel zur abwechselnden Schaltung

Dabei: Zunächst schaltet Ereignis 1 und die Marke wandert von a nach b.

Bei erneuter Markierung von A schaltet dann Ereignis 2.

Konflikt-Situation: Wettbewerb (Meet Conflict)

”Markenüberangebot”: Die Ereignisse 1 und 2 können nicht gleichzeitig schalten,da dann Ausgangszustand C vereinbarungswidrig mit zwei Marken belegt würde.

Dabei: Zunächst schaltet Ereignis 2 und die Marke wandert von a nach b.

Bei erneuter Markierung von A und B schaltet dann Ereignis 1.

Konflikt-Situation: Symmetrische Konfusion

Verflochtene Konfliktsituation: Verzweigung und Wettbewerb

Bspw.: Herstellung der Produkte C, D, E mit den Ressourcen A und B

Konflikt-Situation: Asymmetrische Konfusion

Konflikt (zwischen 2 und 3) tritt erst ein, wenn ein Ereignis (hier 1) schaltet unddie Marke dann von A nach B wandert.

Wenn dann 2 schaltet, wird die C-Marke eliminiert und 3 kann nicht geschaltetwerden.

Wenn statt dessen 3 schaltet, sind nicht alle Eingangszustände für 2 aktiviert.

Lösung 1: Exogener Eingriff

A 21 B

Konflikt-Situation: Asymmetrische Konfusion

� Oder Lösung 2: Entscheidungsregel zur abwechselnden Schaltung

A 21 B

NichtunterscheidbareMarken

Markenkapazitätder Zustände = 1

Bedingungs-/Ereignis-Netze(B/E)

Stellen-/Transitions-Netze(S/T)

Prädikats-/Transitions-Netze(Pr/T)

Markenkapazitätder Zustände > 1

UnterscheidbareMarken

Verschiedene markenorientierte Petri-Netz-Typen

EingegangeneBestellung

Mitarbeiterverfügbar Bearbeitung

der Bestellung

GeschriebeneRechnung

AusgelieferteWare

der Bestellung

AusgelieferteWare

Kurzbeschreibung: B/E-Netze

Zustand = Bedingung / Zustandsübergang = Ereignis

Jeder Zustand kann maximal 1 Marke haben: Knoten-Kapazität = 1

Marken sind nicht unterscheidbar.

Mit jeder Ereignis-Schaltung kann max. 1 Marke gesetzt werden:Kanten-Kapazität = 1

Marke vorhanden / nicht vorhanden: Bedingung wahr / falsch

Voraussetzungen für Ereignis-Schaltung: Alle Eingangsbedingungen sind wahr(markiert), alle Ausgangsbedingungen sind falsch (nicht markiert).

Ereignisschaltung: Allen Eingangsbedingungen wird eine Marke entnommen,allen Ausgangsbedingungen wird eine Marke zugefügt

Kurzbeschreibung: S/T-Netze

Zustand = Stelle / Zustandsübergang = Transition

Jede Stelle kann mehr als 1 Marke haben: Stellen-Kapazität > 1

Marken sind nicht unterscheidbar.

Mit jeder Transitions-Schaltung können mehrere Marken transportiert werden:Kanten-Kapazität > 1 (”Kanten-Gewichtung” gibt max. Markenmenge vor)

Voraussetzungen für Transitions-Schaltung: Anzahl Marken in jederEingangsstelle >= Kapazität der abgehenden Kante und freie Kapazität jederAusgangsstelle >= Gewichtung der dort eingehenden Kante.

Transitions-Schaltung: Allen Eingangsstellen wird diejenige Anzahl an Markenentnommen, die der Gewichtung der abgehenden Kante entspricht.

Transitions-Schaltung: Allen Ausgangsstellen wird diejenige Anzahl an Markenzugewiesen, die der Gewichtung der eingehenden Kante entspricht.

der Bestellung

AusgelieferteWare

K=10K=10

Kurzbeschreibung: S/T-Netze (Beispiel)

Kurzbeschreibung: Pr/T-Netze

Zustand = Prädikat / Zustandsübergang = Transition

Prädikate repräsentieren Relationen.

Marken nehmen Werte an und sind damit unterscheidbar.

Marken = Tupel oder Listen von Tupeln (aus Relationen)

Jedes Prädikat kann über mehr als 1 Marke (Relation) verfügenPrädikats-Kapazität >= 1

Transitionen sind Operationen, die auf ein- bzw. ausgehende Relationen(Marken) auszuführen sind.

Der Modelleur bestimmt, welche Prädikate welche Marken (Relationen)aufnehmen können.

Voraussetzungen für Transitions-Schaltung: Jedes Eingangsprädikat hatdiejenigen Tupel, die die Kanten der Ausgangsprädikate fordern und jedesAusgangsprädikat enthält nicht die Tupel, die die eingehende Kante fordert.

Transitions-Schaltung: Den Eingangsprädikaten werden die durch die Kanten-beschriftungen festgelegten Tupel entnommen und die Ausgangsprädikate wer-den durch die Tupel ergänzt, die die jeweilige Kantenbeschriftungen fordert.

Die Marken (Relationen) aus den Eingangsprädikaten werden in die Marken derAusgangsprädikate umgesetzt.

Mitarbeiterverfügbar

Bearbeitung derBestellung

AusgelieferteWare

K=10K=10

19.12.2000241299Muster GmbH

Eing-DatumBestellnummerFirma

22.12.200024129936 58 778

Erstellungs-DatumBestellnummerPersonalnummer

36 58 778Hr. Friedrich

PersonalnummerMitarbeiter

24129936 58 778

BestellnummerPersonalnummer

Kurzbeschreibung: Pr/T-Netze (Beispiel)

Vorteile Petri-Netze

Nachteile Petri-Netze

Klare Abbildung von Sequenzen, Nebenläufigkeiten und Verklemmungen inProzeßstrukturen

Semantik der Petri-Netze läßt sich einfach identifizieren

Verschiedene Abstraktionsebenen möglich (Vergröberung, Verfeinerung)

Sowohl Statik als auch Dynamik von Prozessen modellierbar, analysierbar

Relativ leichte Erlernbarkeit (besonders B/E-Netze)

Mathematische Verifizierbarkeit der Netze

Die Petri-Netz-Grundlagen (basieren auf den den Grundlagen der System- undGraphentheorie) finden sich in der geschilderten oder in abgewandelter Form inden Modellierungsansätzen für IKS wieder.

Fehlen allgemeiner Systematiken zum Vorgehen bei der Erstellungvon Petri-Netzen

Modellierung subjektiv / keine Petri-Netz-orientierten Methoden

Erhöhter Lernaufwand höherer Netz-Typen (Pr/T-Netze)

Situations-studie

Fach-konzeption

System-konzeption

System-entwicklung

System-installation

Meilen-stein

Situations-studie

Validierung

Meilen-stein

Fachkon-zeption

Validierung

Meilen-stein

System-konzep-tion

Validierung

Meilen-stein

System-entwick-lung

Validierung

Meilen-stein

Validierung

Anwendungsfelder Petri-Netze

Ausgewählte Quellen-Hinweise zu Petri-Netzen

Balzert, Helmut: Lehrbuch der Software-Technik - Software-Entwicklung. 2. Aufl.,Heidelberg, Berlin: Spektrum Akademischer Verlag 2000. Kapitel 2.17,S. 346-374.

Desel, Jörg; Oberweis, Andreas: Petri-Netz in der Angewandten Informatik. In:Wirtschaftsinformatik, 4/1994, S. 359-366.

Desel, Jörg; Erwin, Thomas: Simulation von Geschäftsprozessen mit Petri-Netzen. In: WISU, 3/1999, S. 337-344.

Rosenstengel, Bernd; Winand, Udo: Petri-Netze - Eine anwendungsorientierteEinführung. 4. Aufl., Braunschweig: Viehweg 1991.

2.4 Prinzipien für die Entwicklung von betrieblichen IKS

Prinzip der hierarchischen Dekomposition

Prinzip der Strukturierung und Modularisierung

� Nach den systemtheoretischen Grundlagen der Abstraktion und schrittweisenVerfeinerung (siehe Kap. 2.2)

� Nach den systemtheoretischen Grundlagen der Blockbildung undModularisierung (siehe Kap. 2.2)

Prinzip der konstruktiven Voraussicht

Schon ab den ersten Schritten der Systementwicklung ist auf Qualitätssicherung,Änderbarkeit, Wartbarkeit zu achten.

Erstellungsprozeß durch praktikables Vorgehensmodell und methodischeStandardisierung strukturieren

Integration aller Dokumentationsaktivitäten (in allen Phasen)

Prinzip der perspektivischen Betrachtung

Abhängig vom Betrachter werden verschiedene Aspekte eines Systemsherausgehoben. Die Integration der Sichtweisen ist erforderlich.

Benutzer, Entwickler, Techniker, Unternehmensführung, -organisation, Kunden ...

Prinzip der methodischen Standardisierung

Toolbox

Projektstart Projektende

Paradigma

Situations-studie

Fach-konzeption

System-konzeption

System-realisierung

System-anwendung

Prinzipien VG-Modell

Zwischenergebnisse weiterentwickeln

Modellierungs-ansätze

Konzepte,Notationen

CASE-Werkzeuge

Für die Systementwicklung wird ein Bündel von Methoden, Konzepten, Techni-ken, Werkzeugen vom arbeitsteilig organisierten Entwicklungsteam eingesetzt.

Alle Beteiligte sollten im Systementwicklungsprozeß gemäß einem best. Vorge-hensmodell und mit Instrumenten arbeiten, die aufeinander abgestimmt sind unddamit die Koordination von Ablauf und Entwicklungsergebnissen fördern.

Inkarn

� � �

”Ess

enz”

onnen.

”Inka

rnatio

danach

strikt

”Desi

2.5 Objekt und Sichtweisen der Modellierung von betrieblichen IKS

Objekt der Modellierung von betrieblichen IKS

Sichtweisen der Modellierung von betrieblichen IKS

Jedes IKS wird entwickelt, um bestimmte fachliche Aufgaben zu erfüllen.

Analyse und Entwurf des Aufgabensystems sind die wichtigsten Schritte für diePlanung des IKS.

Das Objekt der Modellierung ist demnach das durch das IKS betroffeneAufgabengefüge im Unternehmen.

Das Aufgabengefüge im Unternehmen läßt sich gemäß den Merkmalen vonAufgaben unter folgenden relevanten Sichtweisen betrachten.

Statische und dynamische Strukturaspekte

Sachmittel und vor allem Daten

Einordnung in die Aufbau- undAblauforganisation des Unternehmens

Struktur von Aufgaben:

Ressourcen von Aufgaben:

Einbindung in die Organisationsstruktur:

Aufgabenmodellierung: Statische Funktionen

VERTRIEB

Angebots-bearbeitung

Auftrags-bearbeitung

Auftrags-verwaltung

Aus-lieferung

Auftrags-abrechnung

Versand-planung

Versand-unterlagen

Fakturierung

Provisions-abrechnung

Auftrags-nachkalku-lation

Fälligkeits-überwachung

Liefer-freigabe

Auftrags-änderungs-dienst

Angebots-konfiguration

Angebots-kalkulation

Liefertermin-ermittlung

Angebots-überwachung

Auftrags-erfassung

Auftrags-prüfung

Auftrags-kalkulation

Auftrags-bestätigung

Aufgabenmodellierung: Dynamische Prozesse (Funktionen)

Eigen-fertig.prüfen

Fremd-bezugprüfen

Auftragterminieren

Auftragkalkulieren

Auftragbestätigen

Vertreter-Auftrag

KD-Auftrag

Auftragkonfig.

KD-Bezieh.prüfen

Auftragsbestätigung

Aufgabenmodellierung: (Ereignisgesteuerte) Prozeßketten

Kundewird nichtbeliefert

Auftrags-ablehnungschreiben

Kunden-auftrageingetr. EF-Teile

für KDA

FB-Teilefür KDA

Auftragkonfigurieren

Kunden-beziehung

prüfen

abgelehnt.Kunden-auftrag

VKundewird

beliefert

Aufgabenmodellierung:(Ereignisgesteuerte)Prozeßketten

BeantragungeinerHypothek

(Stahlknecht 2002)

Antrag aufHypothekliegt vor

Bauunterlagenprüfen

Sicherheitenprüfen

Unterlagenunvollständig

weitereUnterlagenbeschaffen

Unterlagenvollständig

Sicherheitenvorhanden

Sicherheitennicht vorhanden

Hypothekbewilligen

Hypotheknicht bewilligen

weitereUnterlagenliegen vor

XOR XOR

Antragabgelehnt

Aufgabenmodellierung: Daten (semantisches Modell)

stellt

enthält liefert

NameAdresse

BonitätTelefonTelefax

Auftrag

BestelldatumLieferdatum

Bestellte MengeRabatt

Spezialpreis

Artikel

ArtikelbezeichnungLagerbestandMindestbestandEinzelpreisVerpackung

Hersteller

FirmennameAdresseTelefonTelefaxEntfernung

Aufgabenmodellierung: (Aufbau-) Organisationsstruktur

Produktion Lager u.VerkaufEinkauf

MarketingVertrieb Verwaltung

Geschäftsleitung

Aufgabenmodellierung: (Ablauf-) Organisationsstruktur

Auftrag erfassen

Auftrag prüfen

Auftrag konfigurieren

Auftrag kalkulieren

Auftrag terminieren

Auftrag bestätigen

Posteingang/-verteil.

AbteilungVertrieb

AbteilungEinkauf

AbteilungProduktion

AbteilungLager/Vers.

AbteilungVerwaltung

Resultierende Modellierungsansätze von betrieblichen IKS

Aufgrund der vorgenannten Sichtweisen auf das Aufgabengefüge einesUnternehmens sind zu modellieren:

- Funktionen- Prozesse- Daten- Organisationsstrukturen

Es existieren verschiedene Ansätze zur Modellierung von IKS, die jeweils aufbestimmte Modellierungsobjekte fokussieren:

- Funktionsorientierte Modellierungsansätze (z. B. HIPO)- Datenorientierte Modellierungsansätze (z. B. ERM)- Datenflußorientierte Modellierungsansätze (z. B. SA und SADT)

Weiterhin existieren Modellierungsansätze, die die verschiedenenModellierungsobjekte integrieren wie z. B.:

- Sichtweisen-integrierende Modellierung (z. B. mit ARIS)- Objektorientierte Modellierung (z. B. mit der UML)

Gliederung

3. Funktionsorientierte Modellierung

Funktionsorientierte des UnternehmensAufbauorganisation

Die traditionellen betriebswirtschaftlichen Funktionalbereiche definieren diestatischen Aufbau-Organisationseinheiten des Unternehmens.

Traditionell mit verrichtungsorientierter dynamischer Ablauforganisation

Geschäftsleitung

Beschaffung Produktion ReWe Vertrieb

Stelle Stelle Stelle Stelle

3. Funktionsorientierte Modellierung

Funktionsorientierte des UnternehmensAblauforganisation

� Verrichtungsorientierte dynamische Ablauforganisation

Beispiel “Ersatzteilbeschaffung”

Anfrage Kunde an Vertriebsleiter - Sb. A erstellt Angebot - Vertriebsleiterkontrolliert - Sb. A verschickt - Kunde bestellt bei Sb. C - Sb. D erfaßt Bestellung -Vertriebsleiter kontrolliert - Auftragsbestätigung an Kunde durch Sb. A - ..........

3.1 Funktions- und Verrichtungsorientierung

Funktions-/verichtungsorientierte

Ablauforganisation

Hohe Arbeitsteilung,

Viele Schnittstellen in derBearbeitungsfolge

Lange Bearbeitungszeiten

Hoher Koordinationsbedarf

Hierarchiegrenzen sindAblaufgrenzen.

Kunde “droht mit Auftrag"

Hier stehen wir.

Funktionale betriebliche IuK-Anwendungssysteme

Häufig “Insel-Systeme” mit viele internen Schnittstellen

Kein durchgehender Informationsfluß; evtl. Medienbrüche

Geringe Flexibilität, hoher Koordinationsbedarf

Geringe Kundennähe, hohe Redundanzen

VERTRIEB Funktion

Auftrags-verwaltung

Liefer-freigabe

..........

Auftrags-erfassung

Auftrags-prüfung

..........

3.2 Funktionsorientierte Modelle

Unter-funktion

Elementar-funktion

76 Präzedenzmatrix

Funktion

Unter-funktion

Elementar-funktion

“I-P-O"-Beschreibung

Hierarchy

Process

Output

x x ... x x

Input Process Output

Struktogramm

Beginn

EF 1EF 2EF 3

EF 4 EF 5

Funktionsstruktur

VERTRIEB

Auftrags-verwaltung

Aus-lieferung

Auftrags-abrechnung

Versand-planung

Versand-unterlagen

Fakturierung

Auftrags-nachkalku-lation

Liefer-freigabe

Auftrags-änderungs-dienst

Liefertermin-ermittlung

Angebots-überwachung

Auftrags-erfassung

Auftrags-prüfung

Auftrags-kalkulation

Bsp. Auftragsbearbeitung: Dekomposition der Funktionen

Bsp. Auftragsbearbeitung: Weitere Dekomposition der Funktionen

Ausgangsebene

1. Dekomp.-ebene

2. Dekomp.-ebene

3. Dekomp.-ebene

Auftrags-verwaltung

Auslieferung Auftrags-abrechnung

KD-Beziehungprüfen

Auftragerfassen

Auftragbestätigen

Auftragz. Ausl. vorm.

Leitdatenerfassen

Kopfdatenerfassen

Pos.-Datenerfassen

Auftragabschließen

Kundenauftragsführung

Vertreter

Auftragskopf

ProduktProdukt-lagerort

RechnungAuftrags-position

Sachbe-arbeiter

KD-NR.Vertr.-Nr.KD-NameKD-Anschrift......

Vertr.-Nr.KD-Nr.

Vertr.-NameVertr.-Anschrift...

Auftr.-Nr.Pos.-Nr.Art.-Nr.Menge...

KD-NR.Vertr.-Nr.Auftrags-Nr.Auftragsdatum...

Bsp. Vertrieb:Informationsmodell

Bsp. Auftrags-bearbeitung:

Dialogstruktur

Auftragz. Auslief.vormerken

Kunden-Bonitätprüfen

Auftrags-Leitdatenerfassen

Auftrags-Kopfdatenerfassen

Auftrags-Pos.-Daten

erfassen

Lager-bestandprüfen

Lager-bestand

reservieren

Kunden-Beziehung

prüfen

Auftragabschließen

Auftragbestätigen

3.2 Funktions-orientierte

Modelle

Funktionendiagramm

Ebenendiagramm

Input Process Output

Kunden-stammdaten

Artikel-stammdaten

Bestelldaten

Lager-bestands-daten

Faktu-rierung

Bestands-verwaltung

Rechnung

Berichts-wesen

Lager-bestands-daten

Bestands-verwaltungFakturierung

Bsp. HIPO-Diagramm

(Stahlknecht 2002)

Bsp. Auftragsbearbeitung: Auftragspositionsdaten erfassen

PROCESSINPUT OUTPUT

Benutzer-Input:

System-Input:

- Artikel-Nr.

- Menge

- Preis (fakult.)

- Bemerkungen

(fakultativ)

- ..........

Daten aus

- Produkt-IS

- Lager-IS

Benutzer-Output:

System-Output:

s. BS-Masken-

Entwurf

Daten an

- Kunden-IS

- Lager-IS

Verarbeitungsvorschrift:

Gültigkeitsprüfung für Art.-Nr.

Sperrfristprüfung für Art.-Nr.

Lagerverfügbarkeit für bestellte

Menge prüfen; ggf. Reservierung

für Kunden vornehmen

Mengeneinheit:

- default: ST

- zur Wahl: 12-Pack Palette

Preis:

- Listenpreis

- Aktionspreis (fakultativ)

Sequenz (Reihung, Folge)

Strukturblock A

Strukturblock B

Strukturblock C

Strukturblock B

Strukturblock C

Strukturblock A

Verzweigung (Selektion, einfache Alternat.)

Struktur-block A Struktur-

block A

Struktur-block B Struktur-

block B

Bedingungerfüllt ?

Wiederholung (Iteration, mit Bedingung)

Strukturblock A

Wiederholungsbedingung

Auswahl (Selektion, mehrfache Alternative)

Struktur-block A

Struktur-block B

Struktur-block C

Fallabfrage

Fall-abfrage

Struktur-block A

Struktur-block B

Struktur-block C

Steuerkonstrukte der Programmierung: PAP und Struktogramme (Stahlknecht 2002)

Vorstufe derProgrammierung:Pseudocode

(Stahlknecht 2002)

BEGINEröffne Datei AusgangsrechnungenR15 = 0, R20 = 0Lies Datensatz AusgangsrechnungWHILE Datensätze vorhanden DO

IF Rechnungsbetrag > € 3.000THEN Rabatt = 0,20 x Rechnungsbetrag

R20 = R20 + RabattELSE Rabatt = 0,15 x Rechnungsbetrag

R15 = R15 + RabattENDIFLies Datensatz Ausgangsrechnung

ENDDORGES = R15 + R20Drucke RGES , R15, R20Schließe Datei Ausgangsrechnungen

Bsp. Auftragsbearbeitung: BS-Maskenentwurf zu“Auftragspositionsdaten erfassen”

Stelle

Aktion

Poststelle

Schadensregulierung

Sach-bearbeiter Leiter

Buchhaltung

Schadens-meldungannehmen

Meldungprüfen

Zahlungs-betragermitteln

Zahlungs-betraggenehmigen

Mitteilungerstellen

Mitteilungversenden

Zahlungs-betraganweisen

Original Kopie

Bsp. Schadenregulierungbei einer Versicherung

Ablauforganisation -Laufwegesteuerung

(Stahlknecht 2002)

Funktionsorientierte Modellierung von IKS

Hierarchische Zerlegung

Statischer Aspekt:

Dynamischer Aspekt:

Teilungskriterien sind die Funktionen des IKS im Sinne der zu erfüllendenbetrieblichen Aufgaben.

Funktionsbäume: Untergeordnete Ebenen präzisieren die Teilfunktionen derübergeordneten Ebenen.

Aufbaustruktur des IKS (statische Funktionsstruktur im Stilvon Organigrammen)

Ablaufstruktur des IKS, Reihenfolge der Funktionen (z. B.durch IPO-Tabellen, Präzedenzmatrizen, Struktogrammen, Flußdiagramme,Programmablaufpläne)

Daten sind Ressourcen zur Erfüllung der Funktionen

Funktionsspezifische Datendefinitionen und Datenzuordnungen verursachenRedundanzen und Inkonsistenzen.

In einem dynamischen Markt-/Unternehmensumfeld sind Definitionen vonDatenstrukturen zeitstabiler als Funktionsstrukturen.

Daher wird in Literatur und Praxis ein stärker datenorientierterModellierungsansatz als zweckmäßiger angesehen.

3.3 Wandel zur Prozeßorientierung

Merkmale der Prozeßorientierung

Die Organisationsstruktur orientiert sich nicht mehr an betrieblichen Funktionensondern an den Wertschöpfungsprozessen des Unternehmens.

Prozesse leiten sich aus den Kernkompetenzen ab und sind auf genau definiertemarktbezogene Leistungen ausgerichtet.

Die Prozeßleistung ist meßbar und kontrollierbar.

Im Gegensatz zu funktionsorientierten Arbeitsabläufen sind Prozesse stellen-,abteilungs-, funktionsbereichsübergreifend. Sie verlaufen quer zu funktionalenOrganisationsstrukturen.

Jeder Prozeß bildet einen eigenständigen Verantwortungsbereich. Prozessedefinieren somit die Organisationseinheiten des Unternehmens.

Die Prozeßarbeit wird von Teams getragen.

Eigen-fertig.prüfen

Fremd-bezugprüfen

Auftragterminieren

Auftragkalkulieren

Auftragbestätigen

Vertreter-Auftrag

KD-Auftrag

Auftragkonfig.

KD-Bezieh.prüfen

Geschäftsfeld

Prozeß-Team

Beschaffung Produktion ReWe Vertrieb

Team Team Team Team

Annahme

Bearbeitung

Rechnung

Liefern

Auftragdes

Kunden

Produktbeim

Kunden

Input Markt

3.3 Wandelzur Prozeß-orientierung

Kunden

GP Nr. 1: "Kunden aquirieren und Angebote abgeben"

Ereignis 1 Ereignis 2 Ereignis 3

Kunden-auftrageingegan-gen

geprüfteKonfi-guration

geprüfteLiefer-termine

Vorgang 1 Vorgang 2

"BestellteKonfiguration

prüfen"

"Liefertermineprüfen"

EBENE 2

EBENE 1

EBENE 3

A-Über-wachung

Aus-lieferung

Auftr.-Ab-rechnung ReklamationAuftr.-Be-

arbeitung

GP Nr. 2: "Kundenauftrag ausführen"

Vorgangsketten:

Geschäftsprozesse:

Wertschöpfungskette(n):

Marketing + Vertrieb von PCs

Angebotan

erfüllterKunden-auftrag

Funktions-bereich 1

Funktions-bereich 3

Funktions-bereich 2

Funktions-bereich 4

Prozeß 1

Prozeß-leistung

Prozeß 3

Prozeß-leistung

Prozeß 2

Prozeß-leistung

Unter-nehmens-

leitung

Prozeß-Verantwort-

licher

Prozeß-Verantwort-

licher

Prozeß-Verantwort-

licher

Merkmale derProzeß-

orientierung

Der Verbund vonProzessen .....

..... verlangt nacheinem Verbundvon integrierten/integrierendenbetrieblichen IKS

Gliederung

4. Datenflußorientierte Modellierung

4.1 Datenflußorientierte Modellierungsansätze

Betrachtet man eine einzelne Funktion als Blackbox und verknüpft die Funk-tionen über Input-Output-Beziehungen, so erhält man einen Graphen, bei demdie Knoten Funktionen entsprechen und die Pfeile Datenflüsse repräsentieren.

Der funktions- bzw. prozeßorientierten Sicht sehr nahe

Typische Beispiele datenflußorientierter Modelierungsansätze:- SADT (Structured Analysis and Design Technique)- SA (Structured Analysis)

Daten-quelle

Daten-senke

Datenbestand Datenbestand

DatenbestandDatenbesta

VA-Schritt

4. Datenflußorientierte Modellierung: SADT

SADT - Structured Analysis and Design Technique

SADT - Anwendungsbereiche

Mitte der 70er Jahre entwickelt (D. Ross, Firma Softech)

Prinzip der schrittweisen Verfeinerung

Objekte werden top-down in mindestens 3 und höchstens 6 Teilobjekte zerlegt.

Mindestens 3: verhindert triviale Zergliederungen

Höchstens 6: verhindert zu starke Zergliederung und Unübersichtlichkeit

Objekte: Funktionen oder Daten (”WAS”)

Steuerflüsse werden nicht modelliert (”WIE”)

� Allgemeiner Ansatz, um Systeme jeglicher Art zu analysieren und zu entwerfen

Das “WAS” eines Systems steht im Vordergrund, nicht das “WIE”.

IKS-Entwicklung: Grobentwurf, Requirements Engineering

Situations-studie

Fach-konzeption

System-konzeption

System-entwicklung

System-installation

Meilen-stein

Situations-studie

Validierung

Meilen-stein

Fachkon-zeption

Validierung

Meilen-stein

System-konzep-tion

Validierung

Meilen-stein

System-entwick-lung

Validierung

Meilen-stein

Validierung

Anwendungsfelder SADT

SADT - Darstellungselemente

Aktivitätsmodell(Aktigramm)

FunktionTätigkeit

(Verb)

Eingabe-

objekt

Herkunft

(Tätigkeit)

Ausgabe-

objekt

Verwendung

(Tätigkeit)

Mechanismus(Prozessor)

Mechanismus(Speicher)

InitiierendesEingabeobjekt

InitiierendeTätigkeit

DatenObjekte

(Substantiv)

Datenmodell(Datagramm)

Nur Kästchen und Pfeile für Funktionen, Tätigkeiten, Daten, Datenflüsse

Immer duale Modelldarstellung: Aktivitäts- und Datenmodell

Bibliothekverwalten

E1: Eingänge von Buchhändlern A1: Ausgänge an Buchhändler

E2: Eingänge von Benutzern A2: Ausgänge an Benutzer

E3: Personal A3: Personal

S1: Haushaltsplan S2: Bestandspolitik

SADT - Beispiel “Bibliotheksverwaltung” (Aktigramm)

Zunächst oberste Hierarchieebene: Gesamtsystem “Bibliothek verwalten”

Start mit Aktigramm (funktionsorientiert)

VerwaltePersonal

BedieneBenutzer

KaufeBücher

E1 (Buchhändler)Bestellungen

Ausgänge

Rücksendungen

:A1 (Buchhändler)

E2 (Benutzer):A2 (Benutzer)

E3 (Personal)

:A3 (Personal)

S1 (HH-Plan)

Bücher

AngestelltesPersonal

AusgeschiedenesPersonal

S2 (Best.-Pol.)

SADT - Beispiel “Bibliotheksverwaltung” (Aktigramm)

� Dann: “Bibliothek verwalten” zerlegen/verfeinern in seine Teilfunktionen

Bücher

Bestell-belege

Bestel-lungen

Verlagsan-kündigungen

Prüfe, ob bestellt

Versende

Bestelle

Empfange

Stelle Finanzierungsicher

Sende zurück

Inventarisiere

Prüfe, ob zum Bestand passend

SADT - Beispiel “Bibliotheksverwaltung” (Datagramm)

� Dann: Daten modellieren mit Bezug auf die bekannten Funktionen

SADT - Beispiel “Schalterverkehr Bibliothek” (Aktigramm)

Bücherausleihen

Bücher zu-rück geben

IdentifiziereBenutzer

Keine Ausleihe

Bücher

Entleihschein

Rückgabebestätigung

Keine Ausleihe

Reservierungsschein

Vormerkschein

Benutzerdaten Benutzerdaten

Buchdaten

Benutzerdaten

Benutzerdatei

Buchdatei

Datei “Ausgeliehene Bücher”Datei “Reservierungen”

SADT - Beispiel“Auftragsbearbeitung”(Aktigramm)

(Stahlknecht 2002)

ProgrammAuftragsbearbeitung

Kundendaten

Artikeldaten

Kundenauftrag

Kundenkonto

Rechnung

Auftragsdaten

Rechnungssumme

ProgrammFakturierung

Fakturierung

Fibu/Debitoren

ProgrammeFinanzbuchhaltung

SADT - Vorteile

SADT - Nachteile

� Aufbauorganisatorische Darstellung und Datenmodell mit anderen Methoden zuergänzen.

Kontroll-/Steuerflüsse werden nicht modelliert (”WIE”). AblauforganisatorischeBeziehungen werden somit nicht erfaßt.

Berücksichtigt nicht Lokalitäts-/Geheimnisprinzip: Daher nicht zur Blockbildungund Modularisierung geeignet.

Beschränkung auf 3 bis 6 Teil-Objekte pro Verfeinerungsschritt kannsachlogischen Erfordernissen zuwiderlaufen.

� Allgemeine System-Analyse und -Entwurfsmethode

Integriert Funktionen und Daten mit Fokus auf Datenflüsse

Konsequente schrittweise Verfeinerung, leicht erlernbar und leicht verständlich

Im Requirements Engineering für benutzerpartizipative Grobentwürfe geeignet

4. Datenflußorientierte Modellierung: SA

SA - Structured Analysis (Tom DeMarco)

SA - Anwendungsbereiche

Ende der 70er Jahre entwickelt von Tom DeMarco

Grundidee: Es ist leichter, eine Problemlösung zunächst vom Datenfluß hergesehen zu entwickeln, als sie top-down in Funktionen zu zerlegen.

Eine Entwurfsaufgabe wird zunächst mit Hilfe von Datenflüssen in Teilaufgaben(Prozesse) zerlegt.

Kontroll-/Steuerflüsse werden nicht modelliert.

Prozesse transformieren eingehende Datenflüsse in ausgehende Datenflüsse.Die identifizierten Prozesse werden dann schrittweise verfeinert.

Alle Datenflüsse eines hierarchisch nachgeordneten Datenflußgraphen müssenim übergeordneten Datenflußgraphen vorhanden sein.

Somit werden lediglich Prozesse dekomponiert, nicht jedoch die Datenflüsse.

Ein Data Dictionary enthält Beschreibungen aller nicht mehr weiter zerlegbarenProzesse sowie der Datenflüsse.

Das “WAS” eines Systems steht im Vordergrund, nicht das “WIE”.

IKS-Entwicklung: Grobentwurf, Requirements Engineering

Situations-studie

Fach-konzeption

System-konzeption

System-entwicklung

System-installation

Meilen-stein

Situations-studie

Validierung

Meilen-stein

Fachkon-zeption

Validierung

Meilen-stein

System-konzep-tion

Validierung

Meilen-stein

System-entwick-lung

Validierung

Meilen-stein

Validierung

Anwendungsfelder SA

SADT - Darstellungselemente

� Zusätzlich zu den aus Symbolen bestehenden Graphen wird das Data Dictionary(Datenlexikon mit sog. Minispecs) mitgeführt.

Datenfluß,Materialfluß

Prozeß

Benutzerdaten

Benutzer

Speicher,Materiallager

Datenquelle,Datensenke

Symbol Bedeutung Beispiele

Aus-leihe

Magazin

SA - Beispiel “Schalterverkehr (SV) Bibliothek”

Zunächst oberste Hierarchieebene: Gesamtsystem “Schalterverkehr”

Alle relevanten Datenflüsse sind enthalten.

1. SV: 1.1 Benutzeridentifikation, 1.2 Überprüfung Benutzersperre, 1.3 Ausleihe

Benutzer Buchbestand

Magazin

Benutzerdaten

Entleihschein

Buchdaten

Buchnummer

Leihkennzeichen

1.2ÜBS

Magazin

Unbek.Benutzer

Benutzer-daten

EntliehenesBuch

Benutzerdaten

Rück-weisung

Benutzer-daten

Entleihschein

ihschein

Buchnr.

Buchdaten

Buchnr.

Buch Leihkennz.

Buch,Entleih-schein

Benutzerdatei

Ausgeliehene Bücher

Zwischenspeicher Benutzerdaten

Buchbestand

SA - Beispiel “Schalterverkehr (SV) Bibliothek”

SA - Beispiel“Auftragsbearbeitung”

Kundendatei

Kundendaten

Bestellung Lieferdaten Rechnung

Bestands-daten

Entnahme-daten

Rechnungs-summen

Bestellungbearbeiten

RechnungschreibenKunde Kunde

Lagerbestandsdatei Debitorendatei

(Stahlknecht 2002)

SA - Vorteile

SA - Nachteile

� Aufbauorganisatorische Darstellung und Datenmodell mit anderen Methoden zuergänzen.

Kontroll-/Steuerflüsse werden nicht modelliert (”WIE”). AblauforganisatorischeBeziehungen werden somit nicht erfaßt (Teil-Prozesse stellen keine Sequenz dar,obwohl durchlaufend numeriert).

Datenflüsse, -quellen und -senken werden nicht dekomponiert. Alle dieseElemente müssen auf allen Verfeinerungsebenen mitgeführt werden.

Darstellungen werden sehr schnell unübersichtlich.

� Analyse und -Entwurfsmethode für Software-Systeme (Prozesse + Daten)

Integriert Funktionen (Prozesse) und Daten mit Fokus auf Datenflüsse

Schrittweise Prozeß-Verfeinerung, leicht erlernbar und leicht verständlich

Im Requirements Engineering für benutzerpartizipative Grobentwürfe geeignet

Objektorientierte Modellierung

Gliederung

5.1 Datenorientierte Modellierungsansätze

Datenorientierte Modellierungsansätze

Datenorientierte Modellierungsansätze für IKS konzentrieren sich auf diebetriebliche Datenstruktur, Datenrepräsentationsformen und dieDatenmanipulation.

Datenstruktur bspw. für ein IKS: Kunden, Artikel, Lager, Vertriebsbeauftragte,Aufträge, Lieferanten etc.

Typisches Beispiel für datenorientierte Modellierungsansätze:- ERM (Entity Relationship Modeling)

� Datenstruktur bspw. für ein IKS: Merkmale (Attribute) von Artikeln wie z. B. Preis,Bezeichung, Menge etc. und Beziehungen z. B. zu Auftrag, Lieferant etc.

Datenstrukturen sind i. d. R. zeitstabiler als Funktionen und eignen sich daher oftbesser für eine längerfristig gültige Modellbasis eines IKS.

5.2 Daten, Datenmanagement und Datenmodellierung

0 1 2 3 4 5 6 7 8 9 Zeichenvorrat

484,00 Syntax ###,##

Zweckbezug,Bedeutungsinhalt

Regeln,Vernetzung

484,00 Kurs SAP-Aktieam 21. Oktober 1997

SAP-Dividenden-InfoSAP: 471,00; 21.09.97SAP: 484,00; 21.10.97

Konjunktur-Informat.Dollarkursentwicklung

Wissen

Information = Datum +Zweckbezug

Wissen = Information+ Verstehen

Information vermindertUnsicherheit

Unsicherheit

Information = Kenntnisvon Sachverhalten(DIN 44 300)

Information =zweckorientiertesWissen / Daten

Information = Wissen,Denken, Nachricht

Information

Zeichen

HandlungDurchführung zielgerichteterAktionen

EntscheidungAuswahl aus einerMenge von Alternativen

UmsetzungVerwertung

Datenabstrakte, strukturierteDarstellung der Realität,zweckneutral

InformationWissen über dieRealität, zweckgerichtet

Beziehungszu-sammenhang,Verarbeitung

Abstraktion,Abbildung

Erzeugung

Isoliert betrachtet sind Daten zweckneutral und bedeutungslos.

Informations-Darstellung

strukturiert unstrukturiert

statisch dynamisch

sichtbar hörbar

kombinierte Dokumente Video

Multimedia-Anwendungen

Daten BilderTexte bewegteBilder

akust.Signale

Datenspeicherung: Analog, EDV-extern

Datenspeicherung: Digital, EDV-intern

Kopf, Zettel, Papier, Notizen .....

Karteikarten, Ordner, Bücher .....

Unstrukturiert in Files: Doc, ASCII, HTML .....

Strukturiert in Files: Index-/sequentielle Filesmit festen/variablen Feldlängen

Strukturiert in Datenbanken: MS-Access,SQL-Server, Oracle, Informix, DB2 .....

Martin Wild, Berlenbacher Weg 3,

06231-21029

Guba, Andreas, Mainz-530201, Geb.-

Dat.23.2.74

Schwickert, Axel, Handy 0171-5873937

Udo, 2.3.75, 931210

Private Adressen:

Tom Franke, Königstein, 200 DM offene

Rechnung!!!

Unstrukturierte Datenspeicherung

Beispiel Word-Dokument mit Adressen

Bedarf keiner weiteren Erläuterung .....

Strukturierte Datenspeicherung in Files

Bspw. in COBOL-, Pascal-Files mit festen oder variablen Feldlängen

Jede Applikation speichert “ihre” Daten in “ihren” Files.

Zugriff auf Daten i. d. R. nur mit bestimmten Applikationen

Franke;Thomas;23.04.1953; Welderweg 4;55124;Mainz;06131;22018

Müller;Olf;4.12.1969;Kweg 4;45129;Ollern;0531;34962

Ging;Uoh;1.2.2000;Frankfurter Str. 4;21201;Hamburg;0531;34962

FrankeThomas23.04.1953Welderweg 4 55124Mainz 0613122018

MüllerOlf 04.12.1969Kweg 4 45129Ollern 0531 34962

Ging Uoh 01.02.2000Frankfurter Str. 4 21201Hamburg0531 34962

Programm 1 Programm 2

Prozedur-Teil

Daten-beschreibung

Datei 1 Datei 2

Daten-zugriff

Strukturierte Datenspeicherung in Files

Etwas übertrieben, aber deutlich .....

“Das Jahrhundertproblem der Informatik besteht

in der Bewältigung des Datenchaos, das infolge

historisch, mitunter auch hysterisch und archaisch,

sicher aber unkontrolliert gewachsener Datenbestände

fast überall entstanden ist.”

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

Strukturierte Datenspeicherung in Datenbanken

Trennung der Daten von den Applikationen

DBMS (Datenbankmanagement-System) zwischen Applikationen und Daten

Datenbanken sind ein Hilfsmittel zur effizienten, rechnergestützten Organisation,Manipulation und Verwaltung großer Datenbestände.

Datenbanken bieten (u. a.) den anwendungsneutralen Zugriff auf Daten, Daten-Integration und -Konsistenz, Zugriffsregelungen und Multi-User-Zugriffe inNetzwerken: alles Problembereiche der Daten-Speicherung in Files.

Programm 1 Programm 2

Prozedur-Teil

Tabelle 1 Tabelle 2 Tabelle 3 .....

Datenbank-Management-System (DBMS)

StrukturierteDaten-

speicherung inDatenbanken

Integrierte GesamtlösungenBereichsübergreifende AWSSicht des GesamtunternehmensIntegration neuer Technologien

–Bürokommunikation–Teamunterstützung–Wissensbas. Systeme

SpartenlösungenIsolierte AW-InselnGeschlossene, teilweiseinkompatible Systeme

Begrenzte Integrierbarkeitneuer Techniken

Gestern/heute Heute/morgen

Anforderungen an betriebliche IKS:Architektur

Anforderungen an betriebliche IKS:Informationsaktualität

Max. Unterstützung der Bereichs-und Unternehmensziele

Online-Verfügbarkeit allerwesentlichen Informationen

Umfassende, abschließendeSofortverarbeitung

Konsistente DatenbeständeEinsatz der indiv. DV

Begrenzte Auswertbarkeitder Datenbestände

Periodische AuswertungenHohe Anteil StapelverarbeitungDaten-/DateienredundanzUnterschiedl. update-Zyklen

Anforderungen an betriebliche IKS:Entwicklung und Wartung

UnternehmensweitesDatenmodellUnternehmensweiteStandardsToolunterstützungWiederverwendbarkeitSchnelle Reaktions-fähigkeit

Hohe Redundanz beiDaten und FunktionenUnterschiedliche StandardsAbhängigkeit von Spezialisten,mangelhafte DokumentationErhebl. WartungsaufwandHoher Anwendungs-rückstau

“DV-Abteilung” und Datenmanagement

Aufgaben und Ziele des Datenmanagements

Konkrete Aktivitätsbereiche des Datenmanagements

Aus Daten müssen Informationen werden.

Informationen sind als wirtschaftliches Gut zu interpretieren.

Aufgabe der “DV-Abteilung: Nicht “Datenverarbeitung”, sondernInformationsversorgung

Alle im Unternehmen verwendeten Daten planen, überwachen, steuern

Dies unabhängig von den zur Datenspeicherung eingesetzten Sachmitteln

Ziele: Richtigkeit, Vollständigkeit, Aktualität, Konsistenz, Aufgabenadäquanzder Daten / Problem: “Unternehmensweites Datenmodell” (UDM)

Entwicklung und Implementierung von Datenmodellen

Organisation der Datenbeschaffung und Datennutzung

Wartung und Pflege der Datenbestände

Datenmanagement setzt Datenmodellierung voraus

Informationenwerden zunehmendwettbewerbsrelevant.

Datensicht stabilerals Funktionssicht.

Gefordert: IntegrierteSichtweise auf alleUnternehmensdaten.

Die Organisation (aufder Basis einerModellierung)bestimmt wesentlichdie Leistung derbetrieblichen IKS.

Objekt Kunde Angebot Organisation

PoliceVertrag

SchadenBeziehung

Entität

Integrationswirkungen der Daten- und Prozeß-Modellierung

Konstitierende Voraus-setzung für jede Land-schaft von IKS ist dieModellierung der Infor-mations-/Datenobjekteeines Unternehmens.

Die parallele Prozeßmo-dellierung gibt die Hin-weise für die Zusam-menfassung vonIntegrationseinheiten.

Die Modelleure benöti-gen den Überblick überdie Kernziele und-Aktivitäten einesUnternehmens.

Ver-treter Kunde

Rech-nung

Pro-dukt

Auf-trag

Lager-bestands-führung

Debitoren-Buchhaltung

AuftragsbearbeitungKundenstammdatenverwaltung

5.3 Vorgehen bei der Datenmodellierung

Datenmodellierung: Begriff

Datenmodellierung: Ziele

Exkurs: Datenbanksysteme

Formale Beschreibung von Daten und deren Zusammenhänge

”Business Rules” implizit im Modell enthalten

Systematische, strukturierte Erfassung und Dokumentation von Informationen

Verwaltung und Nutzung von Daten/Informationen mit einem Datenbanksystem

Datenmodellierung ist zwingende Voraussetzung für den Entwurf und dieImplementierung von Datenbanksystemen.

Die Konstruktionsmerkmale eines (relationalen) Datenbanksystems beeinflussendie Modellierung der Daten, die in diesem Datenbanksystem verwaltet werden.

3 Schichten (Schemata) in einem (relationalen) Datenbanksystem:- Konzeptionelles (konzeptuelles) Schema- Externes Schema (Views, Sichten)- Internes (physisches) Schema

5.3 Vorgehen bei der Datenmodellierung: Exkurs Datenbanksystem

Stellt die Beschreibung des gesamten Realitätsausschnittes (dar (Unternehmen),der im Datenbanksystem abgebildet werden soll.

Durch Beobachtung der Realität wird ein Informationsmodell erzeugt, aus demdas konzeptionelle Modell (ERM) abgeleitet wird.

Stellt die physische Organisation der Datenelemente dar (bis hin zur physischenAnordnung der Daten auf Speichermedien).

Wird aus dem konzeptionellen Datenmodell abgeleitet/erzeugt

Ausschnitte des konzeptionellen Modells; Separierung aufgrund bestimmterAufgaben, die der jeweilige Ausschnitt erfüllen soll.

Die Aufgaben sind durch die Anforderungen einzelner Benutzer, Anwendungenoder Prozesse festgelegt.

”Benutzersicht” auf die Daten

Konzeptionelles Schema

Internes Schema

Externe Schemata

AbgrenzungRealitätsausschnitt

Konzeptionelles Datenmodell(ERM)

-)Schema

Logisches Relationenmodell(Normalisierung)

Internes/physisches Schema(physisches Datenbankmodell)

Modellierung des Realitätsausschnittes aus fachlicher Sicht

Von der (technischen) Implementierung unabhängig

Semantisches Datenmodell (z. B. mit ERM)

Trennung von Essenz und Inkarnation

Erlaubt die Mitwirkung von Nicht-Informatikern bei der Datenmodellierung(Benutzerpartizipation).

Überführung des konzeptionellen Datenmodells in ein logisches Schema (hier:Relationenmodell), das dann direkt in ein technischesDatenbanksystem (interne, physische Umsetzung auf Speichermedien) überführtwerden kann.

Hier: Relationenmodell ist somit abhängig vom anvisierten (hier: relationales)Datenbanksystem, in das es umgesetzt werden soll.

(hier: relationales)

Konzeptionelles Datenmodell

Logisches Relationenmodell

Anwendungs-problem

FakturierungPC-Händler

verbal,textuell,visuell

formal,vollständig,graphisch

Namen, Attri-bute,Keys,Werte, ...

DDL/SQL:create data-base, table

z. B. alsER-Modell

Menge vonRelationen-schemata

Phys. Daten-organisation

z. B. Oracle

Kunde ( ,KName, KStr,KPlz, KOrt)

KNrAutomatisierung derRechnungsstellung,Typische Rechnungsieht wie folgt aus:.........................................

Artikel ( ,ABez, APreis)

KonzeptuellesDatenmodell

Datenstruktur entwerfen und implementieren

RelationalesDatenmodell

InternesDatenbank-

modell

NormalisierungDatenmodellierung135

5.4 ERM - Entity Relationship Modeling

ERM - Entity Relationship Modeling

ERM - Anwendungsbereiche

1976 von Peter Chen vorgestellt

Semantische Datenmodelle

In ERM (Entity-Relationship-Modellen) werden permanent zu speichernde Datenund ihre Beziehungen modelliert.

Keine Berücksichtigung von Datenflüssen, Organisationsstrukturen, Funktionen

� Allgemeiner Ansatz, um Datenmodelle zuentwerfen

Unabhängig vom anvisierten Datenbanksystem(klassisch, relational)

Das “WAS” eines Systems steht im Vordergrund,nicht das “WIE”.

IKS-Entwicklung: Grobentwurf, Fach- undSystemkonzeption

Situations-studie

Fach-konzeption

System-konzeption

System-entwicklung

System-installation

Meilen-stein

Situations-studie

Validierung

Meilen-stein

Fachkon-zeption

Validierung

Meilen-stein

System-konzep-tion

Validierung

Meilen-stein

System-entwick-lung

Validierung

Meilen-stein

Validierung

Anwendungsfelder ERM

erteilt

Entitätsmenge

Attribut

Leihdatum

Kunde Leihwagenbucht1 n

ERM -Darstellungs-

elemente(klassisch)

Entitätsmengen

Relationen

Attribute

Kardinalitäten

5.4 ERM - Entity Relationship Modeling: Entität

Entitätsmenge

Entitätsmenge, Entity Set, Entitätstyp, Objekttyp

Eine Entitätsmenge enthält Entitäten (Ausprägungen)

Entität: Individuelles, identifizierbares Exemplar von Dingen, Personen, Begriffender realen oder Vorstellungswelt; wird durch Eigenschaften beschrieben.

Entitätsmenge: Zusammenfassung von Entitäten mit gleichen Eigenschaftenunter einem gemeinsamen Oberbegriff

Symbol: Rechteck

Beschriftung: Substantiv (Singular)

Bsp: Kunde = Entitätsmenge / Müller, Meier, Schmidt ... = Entitäten

Entitätsmenge

5.4 ERM - Entity Relationship Modeling: Attribut

Attribut

(Beschreibendes) Attribut, Property

Fachliche Eigenschaft, die allen Entitäten einer Entitätsmenge gemeinsam ist.

Symbol: Oval

Beschriftung: Substantiv (Singular)

Adresse

Telefon

5.4 ERM - Entity Relationship Modeling: Schlüsselattribut

Identifizierendes Attribut: “Schlüssel”

Identifizierendes Attribut, Schlüsselattribut, Key (primary, foreign)

Schlüssel zur eindeutigen Identifizierung einer Entität

Schlüssel: minimale identifizierende Attributkombination

Symbol: Oval mit unterstrichener Beschriftung

Künstliche Schlüssel: i. d. R. Nummern

Zusammengesetzte Schlüssel:z. B. Name + PLZ

Kunden-Nr.

Adresse

Telefon

5.4 ERM - Entity Relationship Modeling: Relation

Relation, Beziehungstyp

Relation, Beziehungstyp, Relationstyp, Assoziation, Relationship

Verbindet Entitätstypen / Symbol: Raute / Beschriftung: Verb (i. d. R.)

Beziehungstypen können Attribute besitzen

Zwei Entitätstypen können durch mehrere Beziehungstypen miteinander inVerbindung stehen.

Zum Beziehungstyp gehört die Kardianlität (s. ff.)

Leihdatum

Kunde Leihwagenbucht1 n

5.4 ERM - Entity Relationship Modeling: Kardinalität

Kardinalität

Kardinalität, Komplexitätsgrad

Gibt an, mit wieviel A-Entitäten eine B-Entität in Verbindung stehen kann.

Symbol: Jeweils an den verbundenen Entitäten1 : 1 oder1 : n odern : m

Symbolplazierungen sollten modellweit in der gleichen Leserichtung erfolgen.

Entscheidend für die Kardinalität eines Beziehungstyps sind die fachlichenGegebenheiten im Zusammenhang mit den zu verbindenden Entitätsmengen.

Bsp.: Studenten müssen mehrere Klausuren schreiben und an jeder Klausurnehmen mehrere Studenten teil.

Bsp.: Ein Bibliotheksbenutzer leiht mehrere Bücher aus und ein Buch kann vonmehreren Benutzern ausgeliehen worden sein (hintereinander).

Häufig: Zeitpunkt-/Zeitraumbetrachtungsproblem

heiratet

besucht

• - Ein Student kannmehrere Seminarebesuchen. Ein Seminarwird von mehrerenStudenten besucht (i. d. R.).

• - Ein Kunde kannmehrere PKWs kaufen.Ein PKW wird immer vongenau einem Kundengekauft.

• 1:1 - Ein Mann heirateteine Frau. Eine Frauheiratet einen Mann.

Student

Seminar

Eingang

Artikelbez.

Auftrag Positionbestehtaus

Einzelpreis

Kunden-Nr. Menge

Ein Auftrag besteht aus einer oder mehreren Auftragspositionen.

Eine Auftragsposition gehört immer zu genau einem Auftrag.

Adresse

Bezeichnung

Produkt Lagerliegtn m

Gewicht

LeiterFarbe

Ein bestimmtes Produkt kann sowohl im Lager Mainz als auch im Lager Triervorgehalten werden.

Hier fachlich gegeben: In einem bestimmten Lager können immer mehrereProduktarten vorgehalten werden.

1 Lager mit genau einer Produktart müßte mit 1:1 modelliert sein.

Entleihdatum

Firmen-Kunde

Leihwagenleiht1 n

Rückgabe am

Zu modellieren ist: Wer hat einen bestimmten Wagen zur Zeit geliehen?

Ein Firmenkunde hat in einem bestimmten Zeitraum keinen, einen oder mehrereWagen für seine Mitarbeiter ausgeliehen.

Ein Wagen ist zu einem bestimmten Zeitraum genau an einen Kunden verliehen.

Kann nicht beantworten: Wer hatte wann welchen Wagen geliehen?

FabrikatName

Leihwagenleihtn m

Adresse

LaufleistungBonität

Zu modellieren ist: Welche Kunden hatten wann welche Wagen gemietet?Welche Kunden hatten bereits den Wagen “X” gemietet?

Ein Wagen wird in seiner Nuzungszeit an viele Kunden verliehen.

Ein Kunde kann einen oder mehrere Wagen leihen.

Firmen-Kunde

Die (1,n,m)-Notationder Komplexität kanndurch die (min, max)-Notation präzisiertwerden.

die mindestenserforderliche Anzahlvon Beziehungen

die maximalzulässige Anzahl vonBeziehungen

Zur Besetzung dermin- und max-Posi-tion werden 0, 1, *(viele) oder genaueZahlenangabenverwendet.

• 1 Mann kann maximal 1 Frau heiraten und umgekehrt. Nicht jederMann oder jede Frau muß heiraten.

• Genau 1 Kunde kann entweder beliebige viele oder null PKWskaufen. Jeder PKW wird von genau einem Kunden gekauft oder istnoch nicht verkauft.

Student

heiratet

besucht

(2,20)

Seminar

• Ein Seminar findet nur mit mindestens 2 und maximal 20 Studentenstatt. Jeder Student muß mindestens 3 Seminare besuchen; er kannbeliebig viele besuchen.

Komplexitäts-präzisierung

MC-Notation

NumerischeNotation

Martin-Notation

Pfeil-Notation

Bachmann-Notation

genaugenau

Kardinalität: Vielzahl von Notationsformen (Beispiele)

Kardinalität

Merke:

Kardinalität immer von beiden Seiten betrachten.

Analyse nicht nach erstbester Interpretation abschließen.

Beispiel: Fluggesellschaft - Passagierverwaltung

Entitätsmenge “Passagier” mit Name, Vorname, Personalausweis-Nr., .....

Entitätsmenge “Flug” mit Flugnummer, Datum, Reiseziel, .....

Ein Passagier kann mit verschiedenen Flügen (Wien, Paris etc.) fliegen.

Also 1: n ?

5.4 ERM - Entity Relationship Modeling: Schwache Entitäten

Schwache Entitätsmengen

Schwache Entitätsmengen enthalten Entitäten, die nur in Abhängigkeit von eineranderen Entität existieren können.

Voll partiziperende vs. schwache Entitätsmenge

Symbol: Doppeltes Rechteck

Yacht-Eigner

Voll partizipierendeEntitätsmenge

SchwacheEntitätsmenge

Yachtbesitzt1 n

Yachteigner: YEigner_nr, YE_Name, YE_Bankverbindung

Yacht: YEigner_nr, Yacht_nr, Yacht_Name

5.4 ERM - Entity Relationship Modeling: Rekursive Beziehungen

Rekursive Beziehungstypen

� Entitätsmange steht mit sich selbst in Beziehung

Mitar-beiter

hat Personal-verantwor-

tung für

5.4 ERM - Entity Relationship Modeling: Beziehung “Aggregation”

Beziehungstyp “Aggregation”

ist-Teil-von / is-part-of / Über-Untergeordneten-Beziehung

Vererbt von Teilen auf Ganzes, von unten nach oben

Motor-rad

Teil von Teil von Teil von

Kolben

Speichen

Ventile

Ventil

Quertr.

Motor Felge Rahmen

Beziehungstyp “Generalisierung”

Attribute einer Entitätsmenge (subtype) sind einer übergeordneten Entitätsmenge(supertype) zuzuordnen (subtype relationship).

Vererbung vom Ganzen auf´s Spezielle, von oben nach unten

Kunde Mitarbeiter Lieferant

ist ein ist ein ist ein

NameGeb.-Dat.

Geb.-Dat.

Person

5.4 ERM - Entity Relationship Modeling: Beziehung “Generalisierung”

Beispiel “Student - Klausur”

Problembereich

Ein Fachbereich besteht aus mehreren Abteilungen.

Jede Abteilung besteht aus mehreren Lehrstühlen.

Jeder Lehrstuhl bietet Klausuren an.

Studenten schreiben pro Lehrstuhl 1 Klausur.

� Mehrere Studenten nehmen an einer Klausur teil.Aber: 1 Student schreibt nur 1 Klausur?

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

Student Klausur

Abteilung

Lehrstuhl

Fachbereich

5.4 ERM - Entity Relationship Modeling: Beispiel “Ruderboot”

ERM-Beispiel: Ruderboot-Vermietung

Ein Ruderverein hat Mitglieder, die ihre (Ein-Mann-) Ruderboote anvereinsexterne Hobbysportler vermieten.

Ein Vereinsmitgleid kann mehrere Boote besitzen und anbieten.

Die Vermietung bezieht sich immer auf das Abfahren einer vorgegebenen(sicheren) Ruder-Tour. Diese Tour ist Bestandteil des Mietvertrags.

Der Mieter kann sich sein Boot nach Gewicht und Farbe aussuchen.

Für jede Tour gibt es eine festgelegte Anzahl an Rudermeilen. Am Jahresendebekommen alle Hobbysportler mit mehr als 100 Rudermeilen ein Geschenk.

wird vereinbart in

umfaßtschließt

gehört

TourTour_nr

ZielRudermeilen

BootsbesitzerBB_Nr

BB_NachnameBB_VornameBB_Telefon

MietvertragMietvertragnr

RuderbootBoot_Name

FarbeGewicht

RudervereinVereins_Nr

Verein_NameV_Telefon_Nr

HobbysportlerKunden_Nr

NachnameVorname

Starke EM

Schwache EM

Identifiz. 1:N Bzt.

Nicht- ident. 1:N Bzt.

wird vereinbart in

umfaßtschließt

gehört

TourTour_nr

ZielRudermeilen

BootsbesitzerBB_Nr

BB_NachnameBB_VornameBB_Telefon

MietvertragMietvertragnr

RuderbootBoot_Name

FarbeGewicht

RudervereinVereins_Nr

Verein_NameV_Telefon_Nr

HobbysportlerKunden_Nr

NachnameVorname

Jeder Vertrag isteindeutig einemMieter zugeordnet.

Jedem Vertrag isteindeutig eineTour mit best.Rudermeilenzugeordnet.

In der Mitsegler-Agentur Windei GmbH werden Yachteignern Teilnehmer anSegeltörns vermittelt. Einem Eigner können mehrere Yachten gehören, währendeine Yacht nur einem Eigentümer gehört. Jeder Törn findet mit einemfestgelegten Start- und Endedatum statt.

Jede Jacht kann während der Saison für mehrere Törns verplant werden. JederTörn hat genau ein Reiseziel, das aber von mehreren Törns angelaufen werdenkann. Der Preis des Törns ist abhängig vom Reiseziel und von der Yacht.

Jeder Mitsegler kann während der Saison an mehreren Törns teilnehmen. Erschließt dazu für jeden Törn einen Vertrag mit dem betreffenden Yachteigner.

� [Zusatz, nicht zu modellieren: Es ist auchmöglich, daß sich mehrere Segler zueiner Gruppe zusammenschließen undgemeinsam einen Vertrag mit dem Eignerabschließen.]

5.4 ERM - Entity Relationship Modeling: Beispiel “Segeltörn”

ERM-Beispiel: Segeltörn-Vermittlung

KundeVertrag_TörnYachteigner

ReisezielTörnYachteingeplant für

findet statt mit

fährt nach

wird angefahren von

schließt abschließt ab

ERM-Beispiel: Segeltörn-Vermittlung

wird eingeplant für /findet statt mit

wird gebucht in /für

schließt schl ießt

fährt zu /wird angefahren von

besitzt

Vertrag_Törn

Yachteigner_nr (FK)

Vertrag_nr

Törn_nr (FK)

PreisVersicherungsschutzSonderleistungen

Reiseziel

Reiseziel_nr

InselnameHafenBeschreibungSandstrandKlimaMeilenPreiskategorie

Kunden_nr

Name_kdAdresse_KdGeburtstagKundenklasseWerbung_erwünscht

Törn_nr

Yacht_nr (FK)Yachteigner_nr (FK)

DauerMittagessenKomfortklasseReiseziel_nr (FK)StartdatumEndedatum

Yacht_nrYachteigner_nr (FK)

Yacht_NameBaujahrModellFarbeMax_teilnehmerMotorY_Preiskategorie

Yachteigner

Yachteigner_nr

Name_YEAdresse_YESchiffscheinErf ahrungKontoverbindung

5.4 ERM - Entity Relationship Modeling: Tool “ERWin”

ERWin: Datenmodellierungs- und Data-Base-Design-Tool

Ziel: Modell in physische, relationale Datenbanken umsetzen

Unterstützt bei der Erstellung von semantischen Datenmodellen (ERM: “logical”)

Setzt Logical Model um in (normalisierte) Relationenschemata

Setzt Schemata um in physische Datenstrukturen des DBMS(forward engineering)

Auslesen und analysieren bestehender Datenbanken (reverse engineering)

Synchronisieren von Modell und bestehender Datenbank (altering DB)

Datenmengengerüst-Berechnungen (Volumetrics)

Umfangreiche Report-Funktionen

Integriert in Produktfamilie u. a. mit BPWin zur Modellierung vonGeschäftsprozessen

ERWin-Modell-Input für die wichtigsten Datenbanksysteme: DB2, Informix,Ingres, Oracle, Progess, SQL-Server, Sybase, MS Access, Clipper, dBase,Foxpro, Paradox, ......

Konzeptuelles Schema(logische Ebene)

Konzeptuelles Schema(sem. Datenmodell)

RelationenmodellRelationenmodell

Internes/physischesSchema

ERWin: Erstellen “logical” und “physical modell”

Érstellen von Entitätsmengen

Erstellen von Relationstypen

Konkretisierung vonKardinalitäten (auch n:m)

Hinzufügen von Attributen(ohne Datentypen)

Hinterlegung vonInformationen zu Attributen

Logical Model

ERWin löst n:m-Beziehungen auf

Konkretisierung derDatentypen

Physical Model

Ziel-DBMS angeben

Generierung perKnopfdruck

ERWin: Logical Model(konzeptionelles)

ERWin:PhysicalModel

(Relationen-schema,normalisiert)

Anwendungs-problem

FakturierungPC-Händler

verbal,textuell,visuell

formal,vollständig,graphisch

Namen, Attri-bute,Keys,Werte, ...

DDL/SQL:create data-base, table

z. B. alsER-Modell

Menge vonRelationen-schemata

Phys. Daten-organisation

z. B. Oracle

Kunde ( ,KName, KStr,KPlz, KOrt)

KNrAutomatisierung derRechnungsstellung,Typische Rechnungsieht wie folgt aus:.........................................

Artikel ( ,ABez, APreis)

KonzeptuellesDatenmodell

Datenstruktur entwerfen und implementieren

RelationalesDatenmodell

InternesDatenbank-

modell

NormalisierungDatenmodellierung167

5.4 ERM - Entity Relationship Modeling: Exkurs “Normalisierung”

Datenbankentwurf und Normalisierung

Der Normalisierungsprozeß

Jede Relation repräsentiert nur eine sachliche Bedeutungseinheit.

Daten sollen redundanzfrei gespeichert werden.

Der Normalisierungsprozeß soll dies sicherstellen.

Relationenschemata prüfen und ggfs. ohne Informationsverlust inmehrere Basis-Relationenschemata zerlegen

Normalerweise: „Normalisierende“ Nachbearbeitung eines ERM

Nachfolgend: Vorbereitung Unnormalisiert 1. 2. 3. NF

Tabellarische Zusammenstellung relevanter Daten und Beispielrechnungen

ReDat KNr

5513155131

5511655131

KStr KPlz KOrt ANr ABez AMeAPreis

123379

224123

125120300200930250200310

198,00999,00248,00448,00110,00598,00448,00799,00

41113121

ZIP-100PC-800CD-300DVD-10HUB-20HDD-40DVD-10SCA-63

003004

005006

12.05.00

12.05.0013.05.00

13.05.0013.05.00

KrauseSchulze

MeierKrause

A-Weg 5

B-Straße 8C-Allee 4

D-Platz 3B-Straße 8

MainzMainz

Beispiel “ Rechnungstellung an Kunden eines PC-Händlers”

Beschreibung des Problems bekannt, kein ER-Modell vorhanden

Zusammenstellung aller relevanten Daten mit Beispielrechnungen

Tabellarische Gesamtsicht als Vorbereitung für Normalisierung

Daten nach Hauptkriterien ordnen: Unnormalisierte Relationen

Kunden und Artikel eigenständige Bedeutungseinheiten je mit Primärschlüssel

Übrig für “Rechnungs-Daten”: ReNr, ReDat, AMe Informationsverlust !!

Welche Rechnung an welchen Kunden? Welche Artikel in welcher Rechnung?

Daher: Aufnahme der Fremdschlüssel KNr, ANr in “Rechnungs-Daten”

Kunden-Daten

Artikel-DatenRechnungs-Daten

55131551165513155128

KStr KPlz KOrt

ANrKNr ANr AMeReNr ReDat

ABez APreis

123224379543

120125200250300310930

123379

224123

120125300200250930200310

14111321

003004

005006

12.05.00

12.05.0013.05.00

13.05.0013.05.00

999,00198,00448,00598,00248,00799,00110,00

PC-800

DVD-10HDD-40

SCA-63

ZIP-100

CD-300

HUB-20

KrauseMeierSchulzeMeier

B-Straße 8D-Platz 3C-Alle 4A-Weg 5

MainzMainzMainzMainz

Von der unnormalisierten zur 1. Normalform

1. NF: Wiederholungsgruppen beseitigt / nur einwertige, elementare Felder

Datensatz-Identifikation nun nur über komb. Primärschlüssel “ReNr + ANr”

Rechnungs-Daten

Wiederholungsgruppen !

Mehrwertige Zellen (Felder)

Wiederholungsgruppen durch

“Auffüllen” zu einwertigen Feldern

Unnormalisiert: 5 Datensätze 1. Normalform: 8 Datensätze

KNrReNr ReDat

123379

224123

003004

005006

12.05.00

12.05.0013.05.00

13.05.0013.05.00

Rechnungs-Daten

KNrReNr ReDat

543543123379379379224123

002002003004004004005006

12.05.0012.05.0012.05.0013.05.0013.05.0013.05.0013.05.0013.05.00

ANr AMe

120125300200250930200310

14111321

ANr AMe

120125300200250930200310

14111321

Vorüberlegungen für die 2. Normalform

Redundanzerhöhung, da einige Nichtschlüsselattribute nur von einem Teil deskombinierten Primärschlüssel abhängig sind (”funktional abhängig”).

Siehe bspw. 2. Datensatz: Für die Rechnungsposition mit der ANr 125 müssenReDat und KNr nicht eigens nochmal gespeichert werden, da beideInformationen eindeutig über die ReNr bestimmt sind.

1. Normalform: Rechnungs-Daten

KNrReNr ReDat ANr AMe

120125300200250930200310

14111321

543543123379379379224123

002002003004004004005006

12.05.0012.05.0012.05.0013.05.0013.05.0013.05.0013.05.0013.05.00

Redundante Mehrfacheinträge

in ReDat und KNr

Von der 1. Normalform zur 2. Normalform

2. NF: In 1. NF und alle Nichtschlüsselattribute sind vom Primärschlüssel nichtnur “funktional abhängig”, sondern “voll funktional abhängig”.

Zerlegen in 2NF-Relationen mit “voll funktionaler Abhängigkeit”

Die Attribute, die vom kombinierten

Schlüssel “ReNr+ANr” voll abhängig sind.

Auslagerung der Attribute, die

nur vom Primärschlüssel

“ReNr” voll abhängig sind.

Neue Relation in 2. Normalform Weitere neue Relation in 2. Normalform

Rechn.-PositionenRechnungs-Köpfe

KNr ReNrReNr ReDat

543123379224123

002002003004004004005006

002003004005006

12.05.0012.05.0013.05.0013.05.0013.05.00

ANr AMe

120125300200250930200310

14111321

Vorüberlegungen für die 3. Normalform

Betrachtung von funktionalen Abhängigkeiten zwischen Nichtschlüsselattributen

Bspw. in Relation “Kunden-Daten”: KOrt ist abhängig von KPlz

KPlz wiederum ist abhängig von KNr

KNr determiniert KPlz und KPlz determiniert KOrt (keine Umkehrung)

KOrt ist transitiv abhängig von KNr

Kunden-Daten

KNrKNr

55131551165513155128

KStr KPlzKPlz

KOrtKOrt

123224379543

MainzMainzMainzMainz

Redundanz: Postleitzahl desWohnorts von Krause und Schulze

doppelt enthalten

Transitive Abhängigkeit

Keine Umkehrung

2. NormalformNur voll funktionale Abhängigkeiten

(da nur ein einziges Schlüsselattribut)

Von der 2. Normalform zur 3. Normalform

3. NF: In 2. NF und kein Nichtschlüsselattribut ist vom Primärschlüssel transitivabhängig.

Zerlegen in 3NF-Relationen ohne transitive Abhängigkeiten

Funktional abhängige Nichtschlüsselattribute auslagern

Kunden-Daten

55131551165513155128

KStr KPlz

123224379543

Neue Relation in 3. Normalform

“Alte” Tabelle ohne KOrt;KPlz wird zum Fremdschlüssel

KPlz wird zumPrimärschlüssel

Orts-Daten

551165512855131

KPlz KOrt

MainzMainzMainz

Weitere neue Relationin 3. Normalform

Die Basis-Relationenschemata in 3. Normalform

Kunden-Daten

55131551165513155128

KStr KPlz

123224379543

Orts-Daten

551165512855131

KPlz KOrt

MainzMainzMainz

Rechnungs-Köpfe

KNrReNr ReDat

543123379224123

002003004005006

12.05.0012.05.0013.05.0013.05.0013.05.00

Rechn.-Positionen

002002003004004004005006

ANr AMe

120125300200250930200310

14111321

Artikel-Daten

ANr ABez APreis

120125200250300310930

999,00198,00448,00598,00248,00799,00110,00

PC-800

DVD-10HDD-40

SCA-63

ZIP-100

CD-300

HUB-20

Kunden (KNr, KName, KStr, KPlz)

Orte (KPlz, KOrt)

Artikel (ANr, ABez, APreis)

Rechnungsköpfe (ReNr, ReDat, KNr)

Rechnungspositionen (ReNr, ANr, AMe)

Kunden (KNr, KName, KStr, KPlz)

Orte (KPlz, KOrt)

Artikel (ANr, ABez, APreis)

Rechnungsköpfe (ReNr, ReDat, KNr)

Rechnungspositionen (ReNr, ANr, AMe)

Positive Anmerkungen zur Normalisierung

Alle Datenstrukturierungsprobleme gelöst ?

Redundanzen in den Tabellen sind beseitigt

Dabei keine Verluste von Informationen oder Abhängigkeiten

”One fact in one place”: Änderungsfreundlichkeit, Konsistenz

Für die Paxis meist ausreichend: 1., 2., 3. Normalform

Weitere: Boyce-Codd, 4. und 5. Normalform

Anzahl der Tabellen (Komplexität) steigt mit höherer Normalform

Applikationen, mehrere Tabellen betreffend: Performance sinkt

Schlüssel-Redundanzen entstehen

Kompromiß: Redundanz vs. Performance/Konsistenz

Bspw.: “Kunden” in 2. Normaform belassen, da begrenzte,kontrollierte Redundanz

Gliederung

6.1 Zum Paradigma der Objektorientierung: Aufsetzpunkte

Aufsetzpunkte der objektorientierten Entwicklung

Funktionen

Organisation ?

Steuerung ?

Integration ?

Konkurrierender Ansatz zur funktionsorientierten und datenorientiertenEntwicklung von Anwendungssystemen

Funktions- und Datenorientierung sind relativ eigenständige Komplemente derSystementwicklung, die sich in der Entwicklungssequenz stark auf die System-Analyse und den System-Entwurf konzentrieren.

Funktions- und Datenorientierung priorisieren und kombinieren sich je selbst mitdem je anderen Ansatz, um die relevanten Systemelemente (Gegenstände,Abläufe) abzudecken. Probleme: Organisation, Steuerung, Integration

Funktion

Unter-funktion

Elementar-funktion

Elementar-funktion Student Klausur

Abteilung

Lehrstuhl

Fachbereich

OOA-Modellnach

Coad/Yourdon

Sachgebiete:

1: Auftraggeber2: Auftrag3: Mitarbeiter

6.1 Zum Paradigma der Objektorientierung: Beispiel OOA-Modell

Sparkonto

Privatkunde

Geburtsdatum

Firmenkunde

Name des AnsprechpartnersAnrede des Ansprechpartners

Buchung

DatumWährungBetragArtBLZVerwendungszweck

stornieren ()ist storniert ()

# Anzahl Buchungenpro Quartal ()

# berechneQuartalsumsatz ()

Kundenbetreuer

NamePersonalnummer

berechneQuartalsumsatz ()

Kunde (abstrakt)

NameAdresse

drucke Adresse ()berechne Quartalsumsatz ()# erstelle Serienbrief ()

11..*1..*

Konto (abstrakt)

NummerEröffnungsdatumSaldoZinssatz für Habenzinsen

eröffne (Datum, Betrag)zahle ein (Datum, Betrag)hebe ab (Datum, Betrag)schreibe Zinsen gut ()löse auf ()berechne Kontoführungs

gebühr ()berechne Quartalsumsatz()

Girokonto

berechneKontoführungsgebühr ()

6.1 Zum Paradigma der Objektorientierung: Beispiel OO mit UML

OO-Modellin UML

6.1 Zum Paradigma der Objektorientierung: Anliegen

Intentionen, Anliegen der OO: “Natürlichkeit, Verständlichkeit” (?)

Konsistente (durchgängige) Integration der zu modellierenden Systemelemente

Ganzheitliche Systementwicklung mit Durchgängigkeit über System-Analyse,System-Entwurf und System-Implementierung

Konzentration auf Entitäten (Objekte) und Priorisierung dessen, was ein Objektist, weniger wie es verwendet wird. Demnach hat die Datenstruktur ein größeresGewicht als die Funktionsstruktur.

Objektorientiert modelliert/entwickelte Systeme besitzen angeblich folgendebesondere Eigenschaften im Vgl. zu Systemen, die nach dem tradiertenfunktionsorientierten Paradigma entwickelt wurden:

- Verkürzung der Entwicklungszeiten- Niedrigere Entwicklungskosten- Reduzierung der Modell- und System-Komplexität- Höhere Qualität der Modelle und Entwürfe- Bessere Umsetzung der Benutzeranforderungen- Methodische Durchgängigkeit und Rückverfolgbarkeit- Einfachere Portierung auf andere Plattformen- Erheblich vereinfachte Pflege und Weiterentwicklung- Wiederverwendbarkeit von Systemteilen

.... etc. pp.: “Alles wird gut!” (Man muß nur dran glauben.)

6.1 Zum Paradigma der Objektorientierung

Situations-studie

Fach-konzeption

System-konzeption

System-entwicklung

System-pflege

Meilen-stein

Situations-studie

Validierung

Meilen-stein

Fachkon-zeption

Validierung

Meilen-stein

System-konzep-tion

Validierung

Meilen-stein

System-entwick-lung

Validierung

Meilen-stein

Validierung

Anwendungsfelder OO-Methoden (Anspruch!)

6.1 Zum Paradigma der Objektorientierung: Chronologie

Chronologie: OO-Entwicklung/-Programmierung/-Codierung

Chronologie: OO-Entwurf/-Design/-Konzeption

Von der Programmierung (Entwicklung, Implementierung, 70er) über Entwurf(Systemkonzeption, 80er) zur Analyse (Fachkonzeption, Situationsanalyse, 90er)

1967: Objektorientierte Programmierung mit SIMULA 67

1976: Programmiersprache Smalltalk; erstmals Begriff “Objektorientierung”

1985: Programmiersprache C++

1989 bereits ca. 88 oo/-basierte/oo-erweiterte Sprachen(Eiffel, Oberon, Objective-C, Pascal, Modula-2, Lisp etc.)

Ausrichtung der Systemkonzeption (Design, Entwurf)nach den Grundgedanken der Objektorientierung(nicht mehr nach der Funktions-/Prozedur-Orientierung)

1977: Beschreibungssprache DELTA

1981: OO-Entwurf von Booch auf Basis von ADA

1988: OO-Design nach Wirfs-Brock

1992: BON (Better Object Notation) von Nerson

70er Jahre:

OO-Codierung

80er Jahre:

OO-Design

90er Jahre:

OO-Analyse

Chronologie: OO-Analyse / Fachkonzeption

In den 90er Jahren erst OO-Ausrichtung auch der frühen Phasen der Situations-analyse und Fachkonzeption (auch “Fachentwurf” genannt)

Damit hatte sich das OO-Pardigma bottom-up von der Programmierung her biszur fachlichen Planung eines Systems auf den gesamten Entwicklungsprozeßausgedehnt.

1988: Shlaer und Mellor mit “OO Systems Analysis”

1990: Coad und Yourdon mit “OOA”

1991: “Booch”

1995: Mehr als 40 Analysemethoden, die den Anspruch erheben “oo” zu sein

1995: Unified Method nach Booch/Rumbaugh

1996: Unified Modeling Language (UML 0.91) nach Booch/Rumbaugh/Jacobsen

nach Booch und “OMT” nach Rumbaugh

1992: OOSE nach Jacobsen

90er Jahre:

OO-Analyse

6.1 Zum Paradigma der Objektorientierung: Chronologie

6.1 Zum Paradigma der Objektorientierung: Ziele

Ziele der Objektorientierung

Warum ein neues Paradigma mit neuenMethoden, Techniken, Tools?

Immer größere und kompliziertereSoftwarepropjekte scheitern amtraditionellen Instrumentarium derSoftwareentwicklung.

Projekte dauern zu lange, sind zu teuer,erfüllen nicht die an sie gestelltenAnforderungen.

6.1 Zum Paradigma der Objektorientierung: Ziele

Ziele der Objektorientierung

Wiederverwendbarkeit / Modularität

Durchgängigkeit Verständlichkeit

Fehler,Kosten,

Komplexität,Entwicklungszeit

reduzieren

Durch Objekt- undKlassenbildung

Orientierung am“Menschen”

... der Methoden vonAnalyse bis Codierung

6.2 Grundelemente der Objektorientierung: Überblick

Die Grundelemente der Objektorientierung im Überblick

- Objektbildung

- Kapselung

- Klassenbildung

- Assoziationen

- Vererbung

- Nachrichtenaustausch

- Polymorphismus

Je nach Autor werden bestimmte Konstrukte aus der Welt der Objektorientierungals grundlegende “Elemente”, “Konzepte”, “Prinzipien” o. ä. herausgestellt.

Weder die Bezeichungen dieser Konstrukte noch deren Auswahl undZusammenstellung ist einheitlich.

Nachfolgend werden die wichtigsten dieser Konstrukte erläutert, die einenÜberblick zur Objektorientierung im allgemeinen geben.

6.2 Grundelemente der Objektorientierung: Objektbildung

Objektbildung: Was bedeutet “objektorientiert”?

Objektbildung: Was ist ein “Objekt”?

� Grob: Ein System ist eine Ansammlung unterscheidbarer Objekte, die sowohleine Datenstruktur als auch ein bestimmtes Verhalten in sich vereinen.

Ein Objekt ist ein Gegenstand des Interesses, inbesondere einer Betrachtung,Untersuchung oder Messung.

Objekte können gegenständliche Dinge oder Begriffe (künstlich) sein.

Ein Objekt hat Eigenschaften (Attribute).

Ein Objekt hat gleichzeitig ein Verhalten. Dieses Verhalten wird durchOperationen (Methoden) ausgedrückt.

Objekt:Elsa Euter

Attribute:- Farbe (weiß)- Beine (4)- Milchmenge (15)

Operationen:- Melken- Füttern- Fortpflanzen

Objektbildung: Eine Tür wird beschrieben durch ....

.... Attribute:

.... Operationen:

- Größe

- Farbe

- Material

- Öffnen

- Schließen

Objektbildung: Jedes Objekt hat eine eindeutige Identität

Objekt: Tür

Objekt: Schlüssel

Objekt: Haus

Objekt: Vera Vollmilch

6.2 Grundelemente der Objektorientierung: Kapselung

Was bedeutet “Kapselung”?

Auf die Attributwerte eines Objektes kann nur das Objekt selbst zugreifen.

Zugriff nur über die Operationen des betreffenden Objektes.

Ein Objekt “verbirgt“ (kapselt) seine Attribute in sich und gibt nur bekannt, welcheOperationen von ihm zur Verfügung stehen.

Verhinderung unkontrollierter Datenmanipulationen durch Realisierung des“Geheimnisprinzips”

Objekt: Anja Alm

Anja Alms Milchproduktion?

Allein ihre Sache!!

6.2 Grundelemente der Objektorientierung: Klassenbildung

Was bedeutet “Klassenbildung”?

Objekte

Klasse

Vera Vollmilch Anja AlmElsa Euter

Eine Klasse beschreibt eine Menge von Objekten mit gleichen Eigenschaften,gemeinsamen Operationen, gemeinsamen Beziehungen zu anderen Objektenund gemeinsamer Semantik.

Eine Klasse ist somit ein “Bauplan” für bestimmte (reale) Objekte.

6.2 Grundelemente der Objektorientierung: Klassenbildung

Klassenbildung: Darstellung von Klassen und Objekten

Strukturgleiche (Name, Attribute, Operationen), aber in Details unterschiedlicheDarstellungsformen je nach “OO-Guru”

Unten Notation in Anlehnung an Rumbaugh

UML aber z. B. ohne Liste der Operationen bei Objektdarstellung

:Kuh Elsa Euter : KuhExemplar vonInstanz vonInstance ofClass Instance

Klassenname

Liste derAttribute

Liste derOperationen

FarbeBeineMilchmenge

Farbe = weißBeine = 4Milchmenge = 15 [Liter]

Melken ()Füttern ()Fortpflanzen ()

Melken (Liter)Füttern (Kilo)Fortpflanzen (Kälber)

Darstellung Klasse Darstellung Objekt

6.1 Zum Paradigma der Objektorientierung6.2 Grundelemente der Objektorientierung: Assoziationen

Assoziationen: Beziehungen zwischen Objekten

“Objektdiagramm”

Beziehungen zwischen Objekten (gleichgeordneter) Klassen

Werden durch einfache Linien dargestellt (bi-/unidirektional).

Nach Möglichkeit werden Assoziationen durch Namen, Kardinalitätsangabenund/oder Rollennamen beschrieben.

: Kunde

: Kundenbetreuer : Rechnung

: Auftrag

erteilt

gehört zuverantwortlich für

Name = MeierStatus = aktiveMail = Meier@home.de

Name = MüllerPersnr = P-987654321Branche = Maschinenbau

Nummer = R-232323Betrag = 300.000 [DM]Zahlungsart = Bar

Nummer = A-12345Datum = 15. Mai 2001Wert = 200.000 [DM]

Spezielle Assoziation: Aggregation

Aggregation: Ganzes-Teile-Beziehung zwischen Objekten

Die Objekte sind dabei nicht gleichberechtigt; eine der beteiligten Klassen hateine führende Rolle.

Hier: Fahrrad besteht aus Rahmen und Bremsen (u. a.).

: Fahrrad

: Rahmen : Bremse

hathat

Bezeichung = BerglustArtikelnr = AR-1245Kategorie = Mountainbike

Bezeichnung = LonglastRahmennr = R-9987Material = Aluminium

Bezeichnung = LX-20Hersteller = HerculesKategorie = Handbremse

Bauteil

besteht aus

6.2 Grundelemente der Objektorientierung: Assoziationen

Spezielle Assoziation: Komposition

Komposition: spezielle Aggregation

Existenz der Teile hängt von Existenz des Ganzen ab.

Hier: Ohne Auftrag keine Positionen und keine Rechnung

: Auftrag

: Auftragsposition : Rechnung

gehört zuhat

Posnr = PO-98765Artikelnr = AR-1245Menge = 300

Nummer = A-12345Datum = 15. Mai 2001Wert = 200.000 [DM]

Nummer = R-232323Betrag = 300.000 [DM]Zahlungsart = Bar

6.2 Grundelemente der Objektorientierung: Vererbung

Vererbung: Beziehungen zwischen (Ober- und Unter-) Klassen

Bsp. “Taxonomie” (Einordnung in ein biologisches System)

Generalisierungs-/Spezialisierungsbeziehung zwischen den beteiligten Klassen

Vererbung: Beziehung zwischen allg. Ober- und spezialisierten Unterklassen

Insekten

Borstenschwänze

Zwei Flügelpaare

Beintastler

Ur-Insekten Flug-Insekten

Libellen

Springschwänze Ein Flügelpaar

Vererbung: Beziehungen zwischen (Ober- und Unter-) Klassen

.... oder ....

Vererbung (generalization) bedeutet, daß eine spezialisierte Klasse (Unterklasse,abgeleitete Klasse, subclass) über die Eigensschaften, das Verhalten und dieAssoziationen einer oder mehrerer allgemeiner Klassen (Oberklassen,Basisklassen, supperclasses) verfügen kann.

Eine Unterklasse ist vollständig konsistent mit ihrer Oberklasse, enthält aber i. d.R. zusätzliche Attribute, Operationen und/oder Assoziationen.

Jede Klasse “kennt” nur ihre eigenen

Die Vererbungsbeziehung wird durch einen Pfeil zur Oberklasse gekennzeichnet.

Attribute, Operationen und Assoziationendie ihrer Oberklassen(n), sofern diese für die Unterklasse sichtbar sind.

Für eine Oberklasse sind generell die Attribute, Operationen und Assoziationenihrer Unterklassen nicht sichtbar.

Vererbung: Abstrakte Klassen

Generalisierungs-/Spezialisierungs-beziehung zwischen den beteiligtenKlassen

Immer: Jedes Objekt der Unterklasse“ist ein” (is a) Objekt der Oberklasse.

Abstrakte Klassen werden nur modelliert,um ihre Informationen an spezialisierteKlassen zu vererben.

� Von einer abstraktenKlasse können keine(realen) Objekte erzeugtwerden. Im Bsp.: Es gibtkonkret nur Kunden undMitarbeiter, keine“Personen”.

: Kunde : Mitarbeiter

BrancheUmsatzStatus

AbteilungGehaltFamilienstand

ermittele durch-schnittl. Umsatz ()

erstelle Urlaubs-plan ()

: Person {abstract}

NameAdresseGeburtsdatum

drucke Adreß-aufkleber ()

Vererbung: Einfachvererbung

Bei der “Einfachvererbung” hat jede Klasse genau 1 direkte Oberklasse (mitAusnahme der Wurzel).

Es entsteht eine Hierarchie in Form eines (umgedrehten) Baumes.

LKWPKWUnterklasse

Unterklasse

Oberklasse

KraftfahrzeugOberklasse (Wurzel)

SattelschlepperLimousine AufliegerCaravan

Vererbung: Mehrfachvererbung

Bei der “Mehrfachvererbung” (multiple Vererbung) kann jede Klasse mehreredirekte Oberklassen haben (mit Ausnahme der Wurzel).

Problem: Eine Klasse kann z. B. zwei Attribute oder Operationen gleichenNamens von verschiedenen Oberklassen erben. Konfliktlösung erforderlich.

WasserfahrzeugLandfahrzeug

Fahrzeug

AmphibienFZPKW LKW Schiff

Unterklasse

Oberklasse

Oberklasse (Wurzel)

6.2 Grundelemente der Objektorientierung: Nachrichtenaustausch

Nachrichtenaustausch: Grundlegendes

Die Funktionalität (das dynamische Verhalten) eines objektorientierten Systemsist in den Operationen seiner Objekte hinterlegt.

Die Realisierung dieser Funktionalität setzt voraus, daß die Operationenverkettet werden können.

Dazu müssen Beziehungen zwischen den beteiligten Objekten bestehen. DieObjekte müssen “sich kennen” (Vererbungsbeziehungen, Assoziationen).

Die Operationen der Objekte müssen “aufgerufen, initialisiert” werden.

Dies geschieht über “Botschaften” (Nachrichten) als “Operationsausführungs-anweisungen” zwischen den beteiligten Objekten.

Die Botschaft (message) trägt den Namen der Operation, die sie aufruft.

Objekt 1 : Klasse A Objekt 1 : Klasse B

Attribut 1 =Attribut 2 =

Operation A1 ()Operation A2 ()

Operation B1 ()Operation B2 ()

Operation B1 ()

Hans Müller : Mitarbeiter A-9876543 : Auftrag

Persnr = 1234567890Abteilung = VertriebFunktion = Sachbearbeiter

Anr = 98786543Datum = 12.10.2001Wert = 200.000 [DM]

Kunden kontaktieren ()Auftrag aufnehmen ()Auftrag betreuen ()

drucken ()ändern ()löschen ()

ändern ()

Nachrichtenaustausch: Polymorphismus

Der Empfänger interpretiert die Botschaft, führt seine Operation aus und schicktdas Ergebnis an den Sender zurück.

Der Sender weiß nicht, wie die Operation vom Empfänger ausgeführt wird.

Die Menge der Botschaften, auf die die Objekte einer Klasse reagieren können,wird als Protokoll der Klasse bezeichnet.

Polymorphismus: Bei der Versendung 1 Botschaft an Objekte verschiedenerKlassen können verschiedene Operationen mit verschiedenen Ergebnissenausgelöst werden.

Bspw. “drucken ()” gesendet an die Klassen “Auftrag” und “Buch”

Nachrichtenaustausch in einer Vererbungsstruktur

Erhält ein Objekt in einerVererbungsstruktur eine Botschaft,“sucht” es in der Liste seiner eigenenKlasse nach einer Operation, mit der esreagieren kann.

Findet das Objekt dort keine ausführbareOperation, wird die Suche in der direktenOberklasse fortgesetzt (usw.).

� Bsp.: Erhält das KundenobjektMüller die Botschaft “druckeAdreßaufkleber ()”, wird dieentsprechende Operation derdirekten Oberklasse “Person”ausgeführt.

: Kunde : Mitarbeiter

BrancheUmsatzStatus

AbteilungGehaltFamilienstand

ermittele durch-schnittl. Umsatz ()

erstelle Urlaubs-plan ()

: Person {abstract}

NameAdresseGeburtsdatum

drucke Adreß-aufkleber ()

6.2 Grundelemente der Objektorientierung: Überblick

Die Grundelemente der Objektorientierung im Überblick

- Assoziationen

- Vererbung

- Nachrichtenaustausch

- Polymorphismus

- Objektbildung

- Kapselung

- Klassenbildung

� Die wichtigsten Konstrukte der OO wurden erläutert, um einen Überblick zurObjektorientierung im allgemeinen zu geben.

Autoren wie z. B. Coad/Yourdon (OOA), Rumbaugh (OMT), Jacobsen (OOSE)bündelten, erweiterten, variierten die grundlegenden Konstrukte in je eigenerWeise und verwendeten je eigene (graphische und textuelle) Darstellungsformen(Notationen) für ihre eigenen Methoden der objektorientierten Analyse/Entwurf.

Grob: Jeder Autor lieferte also je seine bestimmte Menge von Konzepten (was istwie darzustellen? = Ergebnissicht) und sein Vorgehensmodell zur Anwendungder Konzepte (in welchen Schritten wird was ausgeführt, um ein System zumodellieren? = Prozeßsicht).

Ergebnis 1: Verschiedene konkurrierende OO-Ansätze

Ergebnis 2: Bedürfnis nach Vereinheitlichung, Standardisierung der OO-Ansätze

6.3 Die Unified Modeling Language (UML): Entstehung

Chronologie zur Unified Modeling Language (UML)

Die UML hat sich inzwischen als die Standard-Notation

der Objektorientierung durchgesetzt.

1994: Rumbaugh wechselt zu Rational, wo bereits Booch arbeitet.

1995: Booch und Rumbaugh veröffentlichen “Unified Method”

1995: Rational kauft Objectory, wo Jacobsen arbeitet.

1995 - 1997: Booch, Rumbaugh, Jacobsen (”drei Amigos”) erarbeiten die UML

1996: UML Ver 0.91 wird veröffentlicht

1997: Die Object Management Group (OMG) standardisiert UML Ver 1.1

1998: UML Ver. 1.2 wird freigegeben

1999: UML Ver. 1.3 wird veröffentlicht

Nov. 2000: UML Ver. 1.4 als Betaversion veröffentlicht

Ende 2002: Im Auftrag der OMG wird an UML 2.0 gearbeitet

Maerz 2005: Freigabe der UML Version 2.0 durch die OMG

6.3 Die Unified Modeling Language (UML): Charakteristika

Vereinheitlichung historischer OO-Begriffe und -Notationen:

Unterstützung einer durchgängigen (einheitlichen) Methodik

Einheitliche Modellierung bei unterschiedlichen Einsatzgegebenheiten:

Vereinheitlichung bezgl. verschiedener Programmiersprachen undAblaufumgebungen:

Vereinheitlichung unterschiedlicher Modellierungsperspektiven:

Allgemeinakzeptierte Begriffsbildungen aus dem OO-Bereich zusammenführen

über alle Phasen derSystementwicklung: Nahtloser Übergang von Req. Eng. bis zur Implementierung

kleine,große, verteilte, Real-time, rechenintensive, datenintensive Systeme etc.

Identisches Front-End bei flexiblem Back-End

Daten-,Funktions-, Organisations-, Steuerungssicht; flexibel erweiterbar

Zur Bedeutung des Begriffs “Unified”

Die UML als die “eierlegende Wollmilchsau”

für die konzeptionelle System-Modellierung!?

Die UML ist keine Programmiersprache.

Die UML ist keine Methode zur Systementwicklung.

Die UML ist/hat kein Vorgehensmodell.

Die UML ist eine der Objektorientierung verpflichtete Technik.

Technik: Kollektion von Beschreibungsmitteln, Modellierungssprache

Was die UML ist und was sie nicht ist

“UML is not intended to be a complete development method.

It does not include a step-by-step development process.”

Rumbaugh, J.; Booch, G.; Jacobsen, I.: The UML Reference Manual, Addison-Wesley 1999, S. 8.

Die UML stellt für die Grundelemente der Objektorientierung (siehe Abschnitt 6.2)UML-eigene Notationselemente zur Verfügung (Klasse, Assoziationen etc.)

Darüber hinaus verügt die UML über weitere Notationselemente, die aus denzugrundeliegenden OO-Methoden entstanden sind und möglichst alle Aspekteeines zu modellierenden Systems darstellen können sollen.

Die Notationselemente (die darzustellenden Aspekte) werden (häufig) “Konzepte”(engl.: Classifier) genannt.

Bei der Systemmodellierung werden aus jeweils bestimmten Notationselementenverschiedene Diagramme erzeugt (z. B. Klassen- oder Interaktionsdiagramm)

Jedes Diagramm verdeutlicht eine bestimmte Perspektive (Sicht) auf das zumodellierende System (z. B. Sicht des Systembenutzers, statische Sicht, Sichtder Abläufe, Sicht der Implementierungskomponenten etc.)

Wie “funktioniert” die UML?

Verschiedene Sichtenauf das zu mod. System

Menge vonNotationselementen

Verschiedene Diagramme

System

Die UML legt fest, welche Diagramme aus welchen Notationselementen gebildetwerden und welche Sichten mit den Diagrammen erzeugt werden.

Die UML liefert keinen Plan, in welcher Reihenfolge welche Diagramme erzeugtund weiterentwickelt werden sollen, um ein System schrittweise zu modellieren.

Es bleibt den Entwicklern überlassen, sich solche Vorgehensmodelle durch diepassende Zusammenstellung (”methodische Durchgängigkeit”) von Sichten,Diagrammen und Konzepten zu “bauen”.

Der Mangel an Vorschriften zur “Prozeßsicht der Systementwicklung” (sieheAbschnitt 2) ist gleichzeitig ein Vorzug der UML: Sie erlaubt (fordert auf),problemangepaßte Vorgehensmodelle zu entwickeln.

Wie “funktioniert” die Systemmodellierung mit der UML?

Analyse

Entwurf

Implement.

Menge vonNotationselementen

VerschiedeneDiagramme

VerschiedeneSichten

System

ehens-

modell

Die UML hat nicht die verschiedenen OO-Analyse-Entwurfs-Methoden (OOA,OMT, OOSE etc.) zusammengeführt.

Die UML stellt lediglich eine standardisierte objektorientierte Modellierungsspra-che dar, die präziser und vollständiger ist als die Sprachen, die die o. g. OO-Methoden aufwiesen.

Die UML ist eine semi-formale Technik; sie dient zur Vereinheitlichung undStrukturierung prosaischer Formulierungen.

Die UML verfügt über eine Vielzahl vom Diagrammarten, mit denen dieGrundelemente der OO, eine Vielzahl deren Varianten und Erweiterungen sowiealle Phasen der Systementwicklung von der Analyse über den Entwurf bis zurImplementierung unterstützt werden.

Erst seit 1998 existiert mit “Rational Unified Process” ein Vorgehensmodell(Prozeßsicht) mit explizitem Bezug zur UML.

Charakteristika der UML

6.3 Die Unified Modeling Language (UML): Sichten, Diagramme, Konzepte

� Mit der UML können verschiedene Sichten auf ein (zu modellierendes) Systemmit bestimmten Diagrammarten (und Notationselementen) dargestellt werden.

Sichten, Diagrammarten und Konzepte in der UML

Sicht/Abstraktion

Statische

Dynamische

Systemnutzung

Interaktion

Prozeß

Implementierung

Einsatz

Klassen-

Zustands-

Anwendungsfall-

Sequenz-Kollaborations-

Aktivitäts-

Komponenten-

Einsatz-

Klasse, Assoziation, Attribut, Operation

Zustand, Ereignis, Transition, Aktion

Anwendungsfall, Akteur, Assoziation

Interaktion, Botschaft, AktivierungKollaboration, Interaktion, Botschaft

Zustand, Aktivität, Transition, ....

Komponente, Schnittstelle, Abhängigkeit

Knoten, Komponente, Abhängigkeit

Diagrammart Konzepte (Notationselemente)

� Hier die englischen Originalbegriffe; die vorgenannten deutschen Übersetzungenwerden nicht einheitlich verwendet.

UML: Views, Diagrams, Classifier (Concepts)

Static

Dynamic

Interaction

Process

Implementation

Deployment

Class ~

State Chart ~

Use Case ~

Sequence ~Collaboration ~

Activity ~

Component ~

Deployment ~

Class, Association, Attribute, Operation

State, Event, Transition, Action

Use Case, Actor, Association

Interaction, Message, ActivationCollaboration, Interaction, Message

State, Activity, Transition, Completion, ...

Component, Interface, Dependency

Node, Component, Dependency

Diagram Classifier (Concepts)

6.3 Die Unified Modeling Language (UML): Sichten, Diagramme, Konzepte

6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiele

Zielrichtung der Methode: Entwicklung von Web Sites

Davon abhängig: Zusammenstellung von UML-Sichten, -Diagrammarten und-Notationselementen, die die Methode nutzt.

Die nachfolgende Methode kombiniert Diagramme und Notationselemente zu“Modellen”, die (ähnlich wie die Sichten) die Hauptaspekte des zu entwickelndenSystems (Web Site) aus verschiedenen Perspektiven darstellen.

Das “Tayloring” der vorgestellten Methode geht somit über die geschildertenGrundzusammenhang “Sichten, Diagrammarten, Notationselemente” hinaus.

Aufbau einer Methode mit der UML als Technik

Die konstituierenden Elemente einer Methode:

dient einer Definition der zu modellierenden Grundaspekte des Realitätsaus-schnitts, die durch das dahingehend zu entwickelnde AWS zu repräsentierensind sowie einer Festlegung der diese Aspekte veranschaulichenden Modelle(Aspekte = Klassifikationskriterium für Anforderungen)

Spezifikationsrahmen

dient einer logischen und durchgängigen Erarbeitung derim Spezifikationsrahmen definierten Modelle, zur Erreichungeiner vollständigen und widerspruchsfreien Fachlichen Detaillösung

Vorgehensweise

dient einer zielgerichteten Erarbeitung der im jeweiligen Spezifikationsrahmendefinierten Modelle

Technik

determines

determine

Target groupsRelevant business environment

of a “web site” system

Illustrationof tasks

Contextual support oftasks and activities

Integration and transparentpresentation of areas of

responsibility and processes

Spezifikationsrahmen

Bsp.: “Web Site”

Grundlegende,kontexbestimmende

Aspekte des Systems

Elements of a web-site-oriented Method

Technique

Process ModelSpecification Framework

determines

determine

Target groupsRelevant business environment

of a “web site” system

Illustrationof tasks

Contextual support oftasks and activities

Integration and transparentpresentation of areas of

responsibility and processes

Prepare application of method

Requirements as regards the relevantbusiness web site environment

Business requirements as regardsthe basic structure of the tasks

Business requirements as regardsthe detailed structure of the tasks

Business requirements as regardsthe sequence of the tasks

Business requirements as regardsthe tasks or processes

Business requirements as regards thelinks between task areas or processeswithin the same business area

Characteristics of the web sitetarget groups

Uniform domain termino-logy, development groups

Business environmentmodel

Participation model

Integration / transparencymodel

Task model

Dynamic context model

Detailed static contextmodel

Approximate staticcontext model

-------

Package

alysis

cificatio

ssible

Use casediagram

Use case

Use casestep graph

Detailed busi-ness class

Businessclass

Process Model Technique

Tasks (describe ...) Results UML concept

Sachziel: Erweiterung der bestehenden Web Site

eines Lehrstuhls, um Pages zum Web-basierten

Vertrieb von Schriften

Ausgangslage:

1. Schritt:Vorbereitung auf Anwendung der Methode:

1.1 Festlegung des in die Entwicklung einzubindendenPersonenkreises

1.2 Kategorisierung der ermittelten fachlichenAnforderungen entsprechend ihrer Affinität zu dengrundlegenden fachlichen Aspekten von Web Sites undEinrichtung einer Kategorie zur Darlegung derdie Adressaten charakterisierenden Merkmale

1.3 Fixierung einer Entwicklungsprozeß-konformenTerminologie

6.4 Die Unified Modeling Language (UML): Aufbau einer Methode, Beispiel 1

2. Schritt:

Darstellungder fachlich relevanten Umgebungder zu entwickelnden eBusiness-Präsenz

Konkretisierung im:

Anhand des UML-Konzepts:

- Paket -

Fachlichen UmgebungsmodellFachlichen Umgebungsmodell

Erläute

rungen

Inhal-

führt

3. Schritt:

Darstellung der Adressatender zu entwickelnden eBusiness-Präsenz

Konkretisierung im:

- Akteur -

BeteiligungsmodellBeteiligungsmodell

4. Schritt:

Darstellung der Aufgabenbereiche undProzesse, die in der zu entwickelndeneBusiness-Präsenz abzubildenden sind

Konkretisierung im:

Anhand des(aus dem UML-Konzept - Anwendungsfall - abgeleiteten)

UML-Konzepts:

- Anwendungsfalldiagramm -

Integrations-/TransparenzmodellIntegrations-/Transparenzmodell

5. Schritt:

Beschreibung der Aufgaben, die in der zuentwickelnden eBusiness-Präsenzabzubildenden sind

Konkretisierung im:

- Anwendungsfall -

AufgabenmodellAufgabenmodell

tieller

eubest

rozeß

ialisie

ufford

Identif

ikatio

Neubest

ufford

Kundennum

zugeben

rhatsi

Neubest

Kundennum

gegebenen

gegebene

önlic

gegebenen

önlic

gegebene

önlic

riebsp

tzendes

endungss

6. Schritt:

Darstellung der dynamischen Struktur derAufgaben, die in der zu entwickelndeneBusiness-Präsenz abzubildenden sind

Konkretisierung im:

- Aktivitätsdiagramm -

Dynamischen KontextmodellDynamischen Kontextmodell

7. Schritt:

Darstellung der wesentlichen Elemente derstatischen Struktur der Aufgaben, diein der zu entwickelnden eBusiness-Präsenzabzubildenden sind

Konkretisierung im:

Anhand des(aus dem UML-Konzept - Klasse - abgeleiteten)

UML-Konzepts:

- Geschäftsklasse -

Groben statischenGroben statischen KontextmodellKontextmodellGroben statischenGroben statischen KontextmodellKontextmodell

Aufgabe Identifikation realisieren

Web-Site-GeschäftsklassePotentieller Besteller

ver anlaßt

führt zu

Web-Site-GeschäftsklasseIdentifikation

Web-Site-GeschäftsklasseBestellung

Statisches Kontextmodell

8. Schritt:

Darstellung der Detailelemente der statischen Struktur der

Aufgaben, die in der zu entwickelnden eBusiness-Präsenz

abzubildenden sind

z. B. Geschäftsklasse „Bestellung“ wird in Fachklassen„Adresse“, „Bestellposition“, „ Zahlungsweise“ zerlegt.

Konkretisierung im:

Anhand des (aus dem UML-Konzept - Klasse - abgeleiteten)

UML-Konzepts:

- Fachklasse -

Detaillierten statischenDetaillierten statischen KontextmodellKontextmodell

Extending a University´s Web Site with an Application

for web-based Allocation of teaching Facilities

An Example of the UML-based Method

1st Step „Prepare“:

define Development Groups,

uniform Terminology

Go to Step 2 ...

riptio

request

facilit

“pre

-”co

ilable

rvatio

“post

-”co

rvatio

riptio

Step 8: Approximate Static Context Model

customer

<< web-site-business-class >>

carries out

is the basis for

<< web-site-business-class >>

reservation

Prepare application of method

Requirements as regards the relevantbusiness web site environment

Business requirements as regardsthe basic structure of the tasks

Business requirements as regardsthe detailed structure of the tasks

Business requirements as regardsthe sequence of the tasks

Business requirements as regardsthe tasks or processes

Business requirements as regards thelinks between task areas or processeswithin the same business area

Characteristics of the web sitetarget groups

Uniform domain termino-logy, development groups

Business environmentmodel

Participation model

Integration / transparencymodel

Task model

Dynamic context model

Detailed static contextmodel

Approximate staticcontext model

-------

Package

alysis

cificatio

ssible

Use casediagram

Use case

Use casestep graph

Detailed busi-ness class

Businessclass

Process Model Technique

Tasks (describe ...) Results UML concept

Gliederung

ARIS RahmenkonzeptARIS Rahmenkonzept

eEPKeEPK

Unternehmen

Personal Ent-wicklung

MarketingVertrieb

Produk-tion

PersonalEnt-

wicklungMarketingVertrieb Produktion

Auftrags-abwicklung

Produkt-entwicklung

Kunden-Service

Abb. 86: Übergang von der Funktions- zur Prozeßorientierung

Kundenanfra-ge technisch

prüfen

Kundenafragekaufmännisch

prüfen

Kunden-bonitätprüfen

Kunden-anfrage

technischeZeichnungen

technischerBericht

Kunden-anfrage

Kosten-schätzung

Produkt-kalkulation

Kunden-anfrage

Kundendaten

Bonitäts-auskunft

Produkt-verfügbarkeit

prüfen

Kunden-anfrage

bestätigen

Kunden-anfrage

Lager-bestand

Lager-auskunft

technischerBericht

Produkt-kalkulation

Bonitäts-auskunft

Lager-auskunft

Kunden-auftrag

Kunden-anfrage

ungeprüft

Kunden-anfrage

techn. i.O.

Kunden-anfrage kfm. i.O.

Kunden-bonität

gegeben

Produkt-verfügbarkeit

gegeben

Kunden-anfragebestätigt

Disposition

kauf-männischer

Vertrieb

technischerVertrieb

kauf-männischer

Vertrieb

Buchhaltung

Abb. 88: EPK für den Geschäftsprozess “Kundenauftragsbearbeitung”

Selected BPR Tool VendorsChallengers Leaders

Abilityto

Execute

Refocused/Niche Players VisionariesAs of 8/97

Source: Gartner Group

Completeness of Vision

Oracle

Popkin

Rational

ABC Technologies

Micrografx

Sterling Software

Proforma

Logic Works

Software AG

Holosofx

Powersim

Action TechnologiesMosaix

Scitor

IntelliCorp

Mega Intl.Hitachi SE

Lanner Group

Meta Software

IDS Prof. Scheer

Wizdom Systems

CACI Software

High Performance Sys.

Systems ModelingInterfacing Technologies

UBIS Gensym

Imagine That

PromodelKBSI

CASEwise

Abb. 78: Modellierungstools

Funktionen generieren EreignisseFunktionen generieren Ereignisse

GeschäftsprozeßkomponentenGeschäftsprozeßkomponenten

Ereignisse lösen Funktionen ausEreignisse lösen Funktionen aus

Kunden-auftragerhalten

Ereignis

Bestätigendes Kunden-

auftrags

Funktion

erstellt

Ereignis

Produktions-plan

Funktion

Auftrags-verfolgung

Funktion

Rück-meldungerhalten

Ereignis

Produktions-plan

erstellt

Ereignis

auftrags

erstellt

Produktions-plan

erstellt

Auftrags-verfolgung

Produktions-plan

Daten werden in Funktionen verarbeitetDaten werden in Funktionen verarbeitet

Kunden-daten

Produktions- daten

Ressourcen

Kunden-daten

auftrags

Produktions- daten

Ressourcen Auftrags-

bestätigungerstellt

Produktions-plan

erstellt

Auftrags-verfolgung

Produktions-plan

Mitarbeiter sind verantwortlich für FunktionenMitarbeiter sind verantwortlich für Funktionen

Herr Schmidt

Mitarbeiter

Herr MeyerMitarbeiter

Frau MüllerMitarbeiter

auftrags

Frau Müller

erstellt

Produktions-plan

erstelltHerr Schmidt

Herr Meyer

Auftrags-verfolgung

Produktions-plan

Mitarbeiter gehören zu OrganisationseinheitenMitarbeiter gehören zu Organisationseinheiten

Vertrieb

Organisations-einheit

Produktions-planung

Organisations-einheit

ProduktionOrganisations-einheit

Kunden-daten

Produktions- daten

Ressourcen

auftrags

Frau Müller

Vertrieb

erstellt

Produktions-plan

erstellt

Produktion

Produktions-planung

Herr Schmidt

Herr Meyer

Auftrags-verfolgung

Produktions-plan

Funktionen erzeugen und verarbeiten LeistungenFunktionen erzeugen und verarbeiten Leistungen

Kunden-bestellung

Leistung

Kunden-auftrags-

bestätigung

Leistung

Kunden-auftrag

Leistung

Produktions-plan

Leistung

Kunden-daten

Produktions- daten

Ressourcen

OrganisationssichtOrganisationssicht

DatensichtDatensicht

FunktionssichtFunktionssicht

LeistungssichtLeistungssicht

Komplexitätsreduzierung durch SichtenbildungKomplexitätsreduzierung durch Sichtenbildung

Umfeld-Umfeld-datendaten

EreignisEreignis FunktionFunktion

OrgOrg. Einheit. Einheit MitarbeiterMitarbeiter LeistungLeistung

EreignisEreignis FunktionFunktion

�DatensichtWelche Informationen sind wichtig?(z. B.: Kunde, Lieferant, Produkt, Materialrechnungen)

� FunktionssichtWelche Funktionen werden ausgeführt?(z. B.: Produktionsplanerstellung, Auftragsbearbeitung)

�OrganisationssichtWelche Organisationseinheiten gibt es?(z. B.: Einkauf, Vertrieb, Finanzbuchhaltung)

�SteuerungssichtBeziehung zwischen Daten, Funktionenund Organisationseinheiten

� LeistungssichtWelche Leistungen sind wichtig?(z. B.: geprüfter Auftrag, Kundenzahlung)

SteuerungsSteuerungs--sichtsicht

FunktionsFunktions--sichtsicht

DatenDaten--sichtsicht

ARIS -ARIS - Sichten Sichten

SteuerungsSteuerungs--sichtsicht

FunktionsFunktions--sichtsicht

DatenDaten--sichtsicht

ARIS -ARIS - Sichten Sichten

PhasenkonzeptPhasenkonzept

ProblemProblem

FachkonzeptFachkonzept

DV-KonzeptDV-Konzept

ImplementierungImplementierung

InformationstechnikInformationstechnik

ARIS -ARIS - Beschreibungsebenen Beschreibungsebenen

��FachkonzeptFachkonzeptStandardisierte fachliche Beschreibung der Unternehmenskonzepte

��DV-DV-KonzeptKonzeptÜbernahme der fachlichen Anforderungenin die Beschreibungssprache der DV-Technik

��ImplementierungImplementierungBeschreibung der konkreten Hard-und Softwarekomponenten, die fürdie Umsetzung des Unternehmens-konzeptes verwendet werden

Architektur integrierter InformationssystemeArchitektur integrierter Informationssysteme

Anfrage isteingegangen

AnfrageAngebot

Geschäfts-leitung

Material-wirtschaft Vertrieb

EinkaufDisposition

Vertriebs-abwicklung

Lieferterminermitteln

Anfrage-bearbeitung

Bonitätprüfen

Kunden-angebot

Kunden-anfrage

Kunden-auftrag

MethodenintegrationMethodenintegration

Anfrage ist bearbeitet

Anfrage VertriebAnfrage-bearbeitung

Organisation

Fachkonzept

DV - Konzept

Implemen-tierung

Strategische Geschäftsprozeß-analyse und Sollkonzeption

Fachkonzept

DV - Konzept

Implementierung

Fachkonzept

DV - Konzept

Implementierung

Fachkonzept

DV - Konzept

Implementierung

Daten Steuerung FunktionFachkonzept

DV - KonzeptImplementierung

Leistung

Informations- undKommunikationstechnik

ARIS-Haus

Abb. 17: ARIS-Haus mit Phasenkonzept

Abb. 21: EPK des groben ARIS-Vorgehensmodells

Projekt-start

FachkonzeptSteuerungs-sicht (EPK)

FachkonzeptSteuerungs-

sicht beendet

FachkonzeptFunktionssicht

erstellen

FachkonzeptOrganisations-sicht erstellen

FachkonzeptDatensicht erstellen

FachkonzeptLeistungssicht

erstellen

Fach-konzepte ab-geschlossen

DV-KonzeptFunktionssicht

erstellen

DV-KonzeptOrganisations-sicht erstellen

DV-KonzeptDatensichterstellen

DV-KonzeptLeistungssicht

erstellen

DV-Konzept Steuerungs-

sicht erstellen

DV-Konzepteabge-

schlossen

Implemen-tierung

Funktionssicht

Impl.Organisations-

sicht Impl.

Datensicht Impl.

LeistungssichtImpl.

Steuerungs-sicht

Projekt ab-geschlossen

WasWas ist ist ARIS? ARIS?

�ARIS = Architektur Integrierter Informationssysteme

�Rahmenkonzept zur Beschreibung von Unternehmen undAnwendungssoftware

�Entwickelt von Prof. Dr. A.-W. Scheer

�Verwendet Standard-Modellierungsmethoden

�Konzentriert auf denGeschäftsprozeß

�Effektiv in allen Umgebungen:Unabhängig von der Anzahl derAbteilungen, der Unternehmens-größe oder der vorhandenenSoftware

Scriptum zur Vorlesung im Master-Modul · 4 Aufbau einer Methode mit der Unified Modeling Language...

Documents

Transcript of Scriptum zur Vorlesung im Master-Modul · 4 Aufbau einer Methode mit der Unified Modeling Language...

Grundlagen der Computergrafik - THM€¦ · Prof. Dr. Aris Christidis • SS 2019 Grundlagen der Computergrafik – für Bachelor-Studierende – (CS2306) Prof. Dr. Aris Christidis

Aris Produktbroschuere ClassicLine 2018 EN RZ · ARIS Stellantriebe GmbH Rotter Viehtrift 7-9 Tel.: +49 2241 25186-0 53842 Troisdorf / Germany Fax: +49 2241 25186-99

ARIS Actuators Manuals

EPK in ARIS

Systemarchitektur ARIS-SCHNITTSTELLEN ZU SAP®-SYSTEMEN

ARIS UP PLUS

Prozeßmodellierung und Tailoring in Prolog · 1 Einleitung Der Schwerpunkt dieser Arbeit liegt im fünften Kapitel. Es zeigt die Model-lierung der Softwareprozesse und dessen Tailoring.

ARIS-Konzept: 1 ARIS Toolset ist eine eingetragene Marke der IDS Scheer AG Konzept der ARIS-Architektur Modellierung der ARIS-Sichten - Funktionsbaum -

Allgemeine Lehren des Sozialrechts - rewi.uni-jena.de · PDF fileSchwerpunktbereich 3: Deutsches und Europäisches Arbeits- und Sozialrecht Vorlesungsbegleitendes Scriptum Allgemeine

Transformation of ARIS Markup Language to EPML

Mit ARIS Modelle erstellen und auswerten - DINI · Geschäftsprozessmodelle erstellen und auswerten mit ARIS David Lehmkuhl DINI AG eFramework Dortmund, 2. ... Infrastructure Architecture

Scriptum: Mathematische Grundlagen MSE€¦ · INHALTSVERZEICHNIS iii Vorbermerkungen AlsGrundlagefürdieVorbereitungdieserVorlesungdientendieBücher R. Ansorge und H.-J. Oberle:

Praemedikation.doc · Web viewKlinik für Anästhesiologie und Operative Intensivmedizin Medizinische Fakultät Mannheim der Ruprecht-Karls-Universität Heidelberg . Scriptum Anästhesie

Willkommen in der Zukunft der … · Professionelles Upgrade und Migration auf ARIS 9 ARIS 9 Upgrade Readiness Check ARIS Publisher Server ARIS Mashzone Bestehende Anwender Durch

Geschäftsprozessmodellierung mit ARIS · JLU Gießen – FB 02 – Geschäftsprozessmodellierung mit ARIS II A Die Web-Based-Trainings Der Lernstoff zum Themenbereich „Geschäftsprozessmodellierung

Systementwicklung: ARIS Toolset · 2012. 11. 28. · tt-t tik l.-y ARIS und IDS Scheer 6 Das ARIS-Konzept wurde in den 1990er Jahren von Prof. Dr. A.-W. Scheer an der Universität

ARIS Architektur integrierter Informationssysteme.

ARIS Manual PMR3 de-En-fr

2016 – 2017€¦ · Контроллер присоединения (Bay Controller) ARIS C303 /303.1 предназначен для мониторинга и управления

PD/PE · ARIS Stellantriebe GmbH Rotter Viehtrift 7-9 Fon: +49 (0)2241 25186-0 aris@stellantriebe.de D-53842 Troisdorf Fax: +49 (0)2241 25186-99