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