Entwicklung Technischer Informationssysteme

Transkript

1 Entwicklung Technischer Informationssysteme Vorlesungsskript (in Arbeit) von Georg Paul Martin Endig Magdeburg, den 1.Juni

2 Inhaltsverzeichnis 1 Einleitung Überblick zu betrieblichen Informationssystemen Informatik im Unternehmen (am Beispiel Maschinenbau) Entwicklungsstand im Diskursbereich Vorgehensweise bei der Entwicklung von Technischen Informationssystemen Vorgehensmodelle/Softwarelebenszyklus Software-Entwicklungssysteme (CASE, 4GL,...) Anwendungsentwicklung (Vorgehen) Analyse und Modellierung Anforderungen an die Entwicklung technischer Informationssysteme Analysemethoden und Werkzeuge Allgemeines Formen / Arten der Systemanalyse Objektorientierte Methoden und Werkzeuge UML- Unified Modeling Language Integrationsarchitekturen und Standards Integrationskonzepte Integrationsebenen Integrationstypen Kommunikationsmechanismen Verteilte Umgebungen Distributed Object Management Systems Die Integrationsarchitektur CORBA Die Integrationsarchitektur OLE CORBA und OLE: Ein Vergleich Weitere Standards Graphikstandards Datenaustausch-Schnittstellen Normen für Benutzungsschnittstellen Referenzmodelle Integrationsansatz der Magdeburger Schule Softwarearchitekturen Einführung Architekturmuster Formale Methoden und Spezifikationstechniken Architekturbeschreibungssprachen (ADL) Entwurfsmuster (Design Pattern) Definitionen Beispiele Frameworks Einführung Klassifikation von Frameworks Vorteile beim Einsatz und Beispiele Abbildungsverzeichnis Abbildung 1 Die einzelnen Produktionsbereiche...8 2

3 Abbildung 2: Einteilung der Entwicklungsschritte...11 Abbildung 3 Wasserfallmodell...13 Abbildung 4 V-Modell...14 Abbildung 5 Spiralmodell...15 Abbildung 6 Die funktionsorientierte Anwendungsentwicklung [14]...19 Abbildung 7 Die objekt- und datenorientierte Anwendungsentwicklung [14]...19 Abbildung 8 Die Schaffung eines betriebsbezognen Kollektivbewußtseins [14]...20 Abbildung 9 Kommunikationsprinzipien im Verlaufe der Zeit [14]...21 Abbildung 10 Kommunikationsprinzip solidarisch [14]...22 Abbildung 11 Problemlösungsprozeß...22 Abbildung 12 Vorgehensmodell nach [14]...23 Abbildung 13 Erfolgspotentiale im Produktentwicklungsprozeß [7]...25 Abbildung 14 Aufbau eines integrierten Ingenieursystems [7]...26 Abbildung 15 Forschungsgebiete für Rechnerunterstützte Ingenieursysteme [7]...27 Abbildung 16 Umfeld für CAE-Systeme...27 Abbildung 17 CAD-Referenzmodell [1]...28 Abbildung 18 Prozeß...30 Abbildung 19 Fluß...31 Abbildung 20 Speicher...31 Abbildung 21 Terminator...31 Abbildung 22 Datenflußdiagramm für eine Bank...31 Abbildung 23 Notation zum ERD...31 Abbildung 24 Notation STD...32 Abbildung 25 DFD und STD in Kombination...32 Abbildung 26 Historische Entwicklung der Programmiersprachen...35 Abbildung 27 Entwicklung der oo Softwareentwicklungsmethoden...35 Abbildung 28 Notation UML (Quelle: Oesterreich)...36 Abbildung 29 Klassendiagramm...36 Abbildung 30 Objektdiagramm...36 Abbildung 31 Anwendungsfalldiagramm...37 Abbildung 32 UML-Zustandsdiagramm...37 Abbildung 33 Sequenzdiagramm...37 Abbildung 34 Aktivitätendiagramm...38 Abbildung 35 Kollaborationsdiagramm...38 Abbildung 36 Komponentendiagramm...38 Abbildung 37 Einsatzdiagramm...38 Abbildung 38 Pakete, Notizen, Stereotype...39 Abbildung 39 Ergänzende Notationen...40 Abbildung 40 Assoziationen...41 Abbildung 41 Vererbung, abstrakte Klasse...42 Abbildung 42 Abhängigkeit...42 Abbildung 43 Computer als Teile-Ganzes-Beziehung...42 Abbildung 44 Einschränkung für eine Aggregation...43 Abbildung 45 Kompositum Tisch...43 Abbildung 46 Kontextdiagramm...43 Abbildung 47 Schnittstelle...44 Abbildung 48 Architektur...44 Abbildung 49 SWEP mit UML...44 Abbildung 50 Integrationsebenen nach [1]...45 Abbildung 51 : Integrationsebenen nach Österle [29 ]...46 Abbildung 52 Kopplung [1]

4 Abbildung 53: Kapselung [1]...48 Abbildung 54: direkte Integration [1]...48 Abbildung 55 Integrationsanforderungen [29]...48 Abbildung 56 Middleware als Softwareschicht [29]...49 Abbildung 57 Applikationsarchitektur [29]...50 Abbildung 58 Integrationsbeziehungen [29]...50 Abbildung 59 Middlewarekategorien [29]...50 Abbildung 60 Auftretensformen von Middleware [29]...51 Abbildung 61 Ebenen einer verteilten Umgebung [29]...51 Abbildung 62 Aufgaben des Systemmanagement [29]...52 Abbildung 63 Metamodell zur Kommunikation [29]...53 Abbildung 64 RPC...54 Abbildung 65 Message Queueing [29]...55 Abbildung 66 system [29]...55 Abbildung 67 CORBA [29]...56 Abbildung 68 Übersicht verteilte Umgebungen [29]...56 Abbildung 69 DCE [29]...57 Abbildung 70 TP-Monitor [29]...57 Abbildung 71 Komponenten von CORBA und OLE/COM [29]...58 Abbildung 72 Middleware für SAP/R3 [29]...58 Abbildung 73 Internetanwendung [30]...59 Abbildung 74 Integration über CGI...60 Abbildung 75 Integration über Java Applets...60 Abbildung 76 Integration über Web-Technologie...60 Abbildung 77 DOMS...62 Abbildung 78 Entwicklungswerkzeuge RPC-Verfahrens...63 Abbildung 79 Die Object Management Architecture...65 Abbildung 80 Erweiterungen des COM um Extensionen...65 Abbildung 81 Die Common Object Request Broker Architecture...66 Abbildung 82 Das Funktionsprinzip des Basic Object Adapters [10]...67 Abbildung 83 Interoperabilität zwischen ORBs in CORBA Abbildung 84 Kategorien der Common Facilities...72 Abbildung 85 Container-Dokument mit verschiedenen OLE-Objekten...74 Abbildung 86 Die Kernbereiche von OLE Abbildung 87 Client-Server-Beziehungen in der OLE-Terminologie...77 Abbildung 88 Die wichtigsten technologischen Bereiche von OLE2 [11]...78 Abbildung 89 Schichtweiser Aufbau der OLE-Architektur...79 Abbildung 90 OLE-Automation übernimmt die Funktionalität eines ORBs [11]...80 Abbildung 91 Broker-Architektur in Form eines OMT-Diagramms...82 Abbildung 92 OMT-Diagramm: CORBA Architektur...83 Abbildung 93OMT-Diagramm: Distributed OLE - Architektur...84 Abbildung 94 Funktionen der Produktdatenverarbeitung...90 Abbildung 95 Aufbau eines Anwendungsbeispieles...91 Abbildung 96 OSI- /-Schichtenmodell...92 Abbildung 97 Internetkommunikation...92 Abbildung 98 Aktivität-Material-Metapher...95 Abbildung 99 Primitive Komponente und Interaktor sowie komplexe Komponente [SATTLER98]...95 Abbildung 100 Integrationsprozeß mit TIL [SATTLER98]...96 Abbildung 101 Beispiel einer primitiven Komponente...97 Abbildung 102 Beispiel einer komplexen Komponente

5 Abbildung 103 Beispiel einer Konfiguration...97 Abbildung 104 Einordnung der Kompositionsdienste in eine Entwurfsumgebung...98 Abbildung 105 reflexive Systemarchitektur...99 Abbildung 106Architektur des Laufzeitsystems...99 Abbildung 107 PACO-Architektur Abbildung 108Aufteilung der Systemteile des Prototyps Abbildung 109 Prototyp Abbildung 110 Datenbankanwendung als Client-Server - Architektur Abbildung 111 Pipeline Abbildung 112 Datenabstraktion Abbildung 113 Unix-Betriebssystem Abbildung 114 Repository Abbildung 115 SimpleExample Abbildung 116 Komponente Abbildung 117zusammengesetzte Komponente Abbildung 118 Observer-Problem Abbildung 119Lösung Observer-Problem Abbildung 120 Document Editor-Problem Abbildung 121Lösung Document Editor-Proxy Abbildung 122 Bridge -Problem Abbildung 123Lösung Bridge Abbildung 124 Vergleich Abbildung 125 Klassenstruktur Abbildung 126 Applikationsstruktur

6 1 Einleitung 1.1 Überblick zu betrieblichen Informationssystemen Aufgaben (allgemein) [23]: Beschaffung, Erarbeitung, Aufbereitung, Speicherung und Bereitstellung von Informationen auf allen betrieblichen Ebenen Verwaltungsaufgaben (a) Datenpflege: insbesondere Daten, die sich kaum oder wenig ändern (Stammdaten) Kundendaten, Lieferantendaten, Betriebsmitteldaten, Kataloge für Normen, Standards u.ä. Hauptfunktionen dabei sind: ERFASSEN, ÄNDERN, LÖSCHEN, SPEICHERN, (b) Abwicklungsaufgaben: hauptsächlich geschäftliche Abläufe Auftragsabwicklung, Beschaffung von Angeboten, Ausführungen von Bestellungen, Reklamationen, usw. (c) Abrechnungsaufgaben: Lohn- und Gehaltsabrechnung, Kostenrechnung, Materialabrechnung,... (d) Buchhaltungsaufgaben (e) Zahlungsverkehr E-Commerce! Besondere Kennzeichen der Verwaltungsaufgaben: Es handelt sich dabei um eine Massendatenverarbeitung. Informationsaufgaben: (a) Informationsgewinnung: Gewinnung betriebsinterner Informationen Gewinne berechnen, Bilanzen, Betriebsdaten über einen verfahrenstechnischen Zustand Gewinnung betriebsexterner Informationen Personalmarkt, Absatz, Materialmarkt, Beschaffungsmarkt (b) Informationsbearbeitung: Aufbereitung von Informationen Auswahl und Strukturierung (Zuordnung) von Informationen Speicherung von Informationen (c) Informationsbereitstellung:... wird unterschieden nach: Informationsart : Berichte, Mitteilungen, Zeichnungen, u.ä. Datenträger : Papier, Dateien, Arbeitsplatz im Netz Bereitstellungsanlaß : Zeitpunkt, Aufforderung zu bestimmten Ereignissen Bereitstellungsart : Zustellung der Informationen über Mail oder News (abrufbar), Internet Planungsaufgaben: Hierbei werden der technische und der kaufmännische Bereich unterschieden. (a) technischer Bereich: Zeichnungen, Arbeitspläne, Qualitäts- und Prüfpläne, Stücklisten z.b. CAx-, EDM-/PDM-Systeme (Engineering-/Product Data Management) Verwendung von Produktstrukturen + Dokumente Ein Fahrrad besteht aus Rahmen, Räder, Lenker, Zubehör; ein Auto kann ein 6

7 LKW, PKW oder Bus sein. (b) kaufmännischer Bereich: Projektplanung, Terminplanung, Finanz- und Absatzplanung Dispositionsaufgaben: Dispositive Aufgaben können etwa wie folgt charakterisiert werden: Die Entscheidungserfordernisse sind vorhersehbar; sie sind häufig periodisch/wiederkehrend. Oft ist auf der Basis vorgegebener Anweisungen/Festlegungen zu entscheiden. Beispielhafte Dispositionsaufgaben sind die Materialdisposition, die Fertigungsdiposition oder eine Lieferantenauswahl. Steuerungsaufgaben: Steuern bedeutet (nach REFA): das Veranlassen, Überwachen und Sichern einer Auftragsabwicklung. Darunter fallen u.a. die Fertigungssteuerung (mit Maschinen-, Roboter-, Transportsteuerung), die Steuerung von Rechentechnik oder die Steuerung des Außendienstes. Kontrollaufgaben: Schwerpunkt ist das Ermitteln aktueller Ergebnisse. Hierbei wird u.a. ein Vergleich Soll-Ist vorgenommen, um z.b. das Einhalten gewünschter Vorgaben zu ermöglichen. Daneben sind jedoch auch weitergehende Funktionen zur Verfügung zu stellen, wie z.b. die Ermittlung von Abweichungsursachen sowie Maßnahmen zur Korrektur oder das Ändern von Sollwerten. 1.2 Informatik im Unternehmen (am Beispiel Maschinenbau) 7

8 (Kopie) Abbildung 1 Die einzelnen Produktionsbereiche Die Aufgaben der Informatik lassen sich traditionell nach betrieblichen Funktionen einteilen. Somit ergeben sich folgende Schwerpunkte: Unterstützung der Auftragsabwicklung, Materialwirtschaft, Produktion, Vertrieb, Rechnungswesen, Personalwesen. Diese einzelnen Hauptschwerpunkte gliedern sich wiederum in Teilschwerpunkte, auf die bereits in der Lehrveranstaltung Rechnerunterstützte Ingenieursysteme eingegangen worden ist. Zur tieferen Untersuchung wurden Teilbereiche aus dem Bereich PRODUKTION gewählt(vgl. Abb.1). Nach Taylor ( Anfang des 20. Jahrhunderts) kann dabei eine Arbeitsteilung in 8 Bereiche vorgenommen werden : Entwicklung- und Konstruktion Arbeitsplanung Betriebsmittelplanung Technischer Bereich Fertigung (Produktionsausführung) Produktionsplanung und -steuerung Qualitätssicherung Unternehmensplanung (nicht zu technischen Bereichen) Marketing/Vertrieb (nicht zu technischen Bereichen) 8

9 Für weitere Betrachtungen bilden im speziellen die produktionsvorbereitenden Bereiche sowie die dort unterstützende Systeme den Schwerpunkt. So stehen beispielhaft CAD/CAM-, CAP, EDM/PDM- und Workflow-Systeme und deren Integration im Vordergrund. Heutige Organisationsformen zur Produktion orientieren sich weniger an der Arbeitsteilung, denn an eindeutig ökonomischen Zielen. Dabei stehen Resourceneinsparung und Qualität im Vordergrund. Auch die Steigerung der Mitverantwortung der Mitarbeiter ist Schwerpunkt der Konzepte ( Total Quality Management, fraktale Fabrik, Lean Production...). 1.3 Entwicklungsstand im Diskursbereich EDM/PDM: (Engineering Data Management/Product Data Management) Diese Systeme erfüllen bereichsübergreifende Funktionen (innerhalb der Produktionsvorbereitung). ursprüngliches Ziel: Schaffung einer einheitlichen, unternehmensweiten, technischen DB (im Augenblick: vorrangig produktionsvorbereitende Bereiche) Produktdaten sind nach Anderl/Trippner [ANDTRI00] (Anderl/Trippner : STEP, Eine Eiführung in die Entwicklung..., Teubner Verlag Stuttgart Leipzig, 2000) 1. Daten zur Produktdefinition (administrative und organisatorische Produktdaten zur Identifikation, Klassifikation, Struktur, zu den Phasen des Lebenszyklus) 2. Daten zur Produktrepräsentation (z.b. Geometriedaten) 3. Daten zur Produktpräsentation ( Daten zur grafischen und textuellen Darstellung, z. B. VR-Daten) Als Basiswerkzeug dienen zumeist Relationale Datenbanksysteme. Beispiele (im Umfeld der Vorlesung): PDV (B.I.M. Consulting mbh Magdeburg); CADIM/EDB (Eigner) CAD/CAM-Systeme: Merkmale: 3D-Technik Parametrische Modellierung, history-based Design Arbeiten mit Konstruktionselementen (Featuretechnik) Sehr komplexe Systeme sind meist modular aufgebaut; sehr großer Funktionsumfang. Problem: viele geometrische Modellierer, viele Datenaustauschformate automatische Bemaßung, Freiformflächenmodellierer Zusatzfunktionalität zur Strukturverwaltung, Stücklistenerzeugung, Simulationsschnittstellen, NC- Programmierer Beispiele: Pro/Engineer, CATIA, Euclid, ICEM, Solid Designer, AutoCAD,CADDS,.. CAP-Systeme: Haben meist verwaltenden Charakter, sind weniger generierende Systeme. Oftmals dann auch Bestandteil von PPS-Systemen. Arbeitsplanung: meist intuitive, iterative Entscheidungen Eingangsdaten sind nicht in ausreichender Form verwendbar im Vergleich zu CAD-Systemen: weniger entwickelt, weniger eingesetzt Müssen auf Stammdaten zurückgreifen. Beinhalten - wenn generierend - einen Logikteil (auch wissensbasierend). Konzepte zur Planung und Steuerung Nach Schönsleben [SCHÖ99] gibt es unterschiedliche Ansichten über die Güte von verschiedenen Ansätzen und Konzepten zur Planung und Steuerung in der Produktionslogistik. 9

10 (Schönsleben: Konzepte zur Planung und Steuerung in der Unternehmenslogistik, PPS- Management 4 (1999)1, S ) Dabei haben sich 4 Klassen herausgebildet: MRPII/ERP-Konzept Just-in-time/Kanban-Konzepte Variantenorientierte Konzepte Verfahrensorientierte Konzepte. 1. MRPII-Konzept Stammt aus Amerika (1960er Jahre) und bedeutet Manufacturing Ressource Planning. Eine Vorstufe davon war MRP-Materials Requirements Planning. Die deutsche Umschreibung lautet PPS (Produktionsplanung und steuerung). Es ist für konvergierende Produktionsstrukturen gedacht ( Automobil-, Flugzeugbau,..) In der Absicht, alle Bereiche des Unternehmens zu umfassen, spricht man heute von Enterprise Ressource Plannning (ERP). 2. Just-in-Time- Konzept Stammt aus Japan (1970er Jahre) und hatte das Ziel der Verbesserung des Güterflusses.Lieferung hat Priorität. 3. Verfahrensorientierte Konzepte Stammen aus Europa (1970er Jahre) und unterstützen das Management zur Herstellung von Produkten, die quasi einer Produktfamilie zuzuordnen sind (Kleinserien, Einzelproduktion..). 4. Verfahrensorientierte Konzepte Stammen aus Nordamerika (1980er Jahre) und sind Konzepte für die Prozeßindustrie (Process Flow Scheduling). Diese Konzepte sind sowohl für die Massenproduktion als auch für die Prozeßindustrie, insbesondere die grundstoffverarbeitende Industrie angedacht. Data Warehousing [Matin98] (W. Martin (Hrsg.): Data Warehousing, Thomson Publishing Bonn, 1998) Unterstützen Geschäftsvorgänge im Unternehmen, um sein eigenes Produkt- oder Dienstleistungsportfolio im Wettbewerb zu positionieren. Sind mehr als ein Ersatz für ein Berichtswesen. (Macht aus Daten Informationen!) DataWarehousing macht aus Daten Informationen, die zu Wissen verarbeitet werden, um daraus Aktionen abzuleiten. OLAP (Online Analytical Processing) und Data Mining (Extraktion vorher nicht bekannter Informationen aus großen Datenmengen) sind dabei komplementäre Verfahren. Supply Chain Management - SCM [DANG99] (Dangelmeier u.a.: Produktions- und Supply-Chain-Management bei größeren Stückzahlen, PPS Management 4(1999) 1, S ) Ergänzt die bis heute vornehmlich auf die innerbetrieblichen Belange eines Unternehmens ausgerichteten Produktionsplanungs und steuerungssysteme (PPS) um die Kunden- Lieferanten-Problematik. Customer Relationship Management CRM Die Pflege der Kundenbeziehungen hat Priorität in diesem Anwendungsfeld. 2 Vorgehensweise bei der Entwicklung von Technischen Informationssystemen (Reiner Dumke: Software Engineering Vieweg Verlag Braunschweig, 2000 Max Vetter: Aufbau betrieblicher Informationssysteme Teubner Stuttgart 1998) 10

11 (Hinweis: Technische Informationssysteme = TIS) Ziel: ingenieurmäßige Entwicklung von Software im Bereich technischer Anwendungen (im Produktionsbereich) ein möglicher Ansatz strukturierter, objektorientierter methodischer Ansatz Systemgestaltung (Kopie) Abbildung 2: Einteilung der Entwicklungsschritte 2.1 Vorgehensmodelle/Softwarelebenszyklus (Hinweis: Quellen [12, 16, 26]) Softwarelebenszyklusmodell: abstrakte, modellhafte Vorstellung über die Strukturierung des SE-Prozess Phasen: (a) Requirement Analysis (Anforderungsanalyse), Problemdefinition * Zusammenstellen aller notwendigen Informationen über das Problemgebiet und das geplante System * spezielle Aufgaben der Anwender berücksichtigen (Lastenheft!) * Ergebnis: vollständige, konsistente Beschreibung; verständlich für Anwender und Entwickler (b) Systemspezifikation * Abgrenzung des Softwaresystems gegenüber der Umwelt * keine neuen Informationen, sondern Strukturierung und Formalisierung der Informationen *UML OMT, OOA (c) Architectual Design (Grobentwurf) * vom Entwickler durchgeführt *erstes Design auf einer abstrakten Ebene (unabhängig von der verwendeten Implementierungsplattform) (d) Detailed Design (Feinentwurf) * Anreicherung des Grobentwurfs um abstrakte Algorithmen und Datenstrukturen * unabhängig von Implementierungsplattform und Programmiersprachen * Hält sich strikt an Vorgaben der Phase c. (e) Implementation * Umsetzen des Design in ein physisch auf einem Rechner abarbeitbares Programm Programmiersprachen 11

12 (f) Maintenance / Evolution * Einsatz und Wartung des Systems (Beseitigung von Fehlern, Anpassung von Funktionen) (g) Archivieren, Vernichten Die Phasen (a) und (b) werden auch als Requirement Engineering und die Phasen (c) und (d) werden als Design Engineering bezeichnet. Vorgehensmodelle Anleitung zum Handeln Enthalten die einzelnen Arbeitsschritte innerhalb der Phase. Bedingungen der Aufeinanderfolge der Arbeitsschritte Es werden sequentielle und evolutionäre Lebenszyklusmodelle unterschieden. Beispiele für sequentielle Modelle: 12

13 (Kopie) Abbildung 3 Wasserfallmodell 13

14 (Kopie) Abbildung 4 V-Modell Ein evolutionäres Modell ist das Spiralmodell. 14

15 (Kopie) Abbildung 5 Spiralmodell Erläuterungen: V-Diagramm (sequentiell): *Zeigt die zeitliche Folge der Phasen. * Rechtecke stellen die Phasen dar; die Ovale enthalten Ergebnisse / Produkte. * Sogenannte "Baselines definieren jede Entwicklungsstufe des Produktes. * Sie enthalten Informationen, die das Produkt beschreiben. * Der Abschluß einer Stufe wird durch "Reviews bestimmt, wobei die Erfüllung der "Baselines kontrolliert wird. * Aus den entstandenen Zwischenprodukten werden "Baselines für die jeweils nächsten Entwicklungsstufen geformt. * Das V-Diagramm liefert Überblick zum Software-Entwicklungsobjekt, muß im Detail jedoch durch verfeinerte Prozessmodelle untersetzt werden. - Wasserfallmodell (sequentiell): * Dem klassischen Wasserfallmodell liegt die Idee zugrunde, daß iterative Interaktionen zwischen aufeinanderfolgende Phasen möglich sind. * Bietet sich an bei individuellen Entwicklungen und Entwicklungen in kleinen Teams. 15

16 - Spiralenmodell (nicht sequentiell): * Kumulative Kosten werden in radialer Dimension dargestellt. * Jeder Zyklus beginnt im oberen linken Quadranten mit der Bestimmung der Ziele, Alternativen und Constraints. * Der nächste Schritt ist jeweils die Evaluierung der Alternativen und der Risikoabbau. * Es folgen Entwicklung, Verifizierung der nächsten Produktstufe. * Im 4. Quadranten werden jeweils die nächsten Phasen geplant. * Die Quadranten werden mehrfach durchlaufen. * Ein Risikomanagement wird in jedem Zyklus betrieben. * Jeder Spiralzyklus bestimmt Produkt- und Prozeßziele und constraints. Alternativen können schrittweise eliminiert werden Beispielaktivitäten für die Entwicklung eines Technischen Informationssystems: Phase Lebenszyklus Entwicklungsphase Entwicklungsschritt Arbeitsschritt zum Beispiel Entwicklung eines TIS logischer DB-Entwurf Definition neuer Datentypen Einfügen eines neuen Entities 2.2 Software-Entwicklungssysteme (CASE, 4GL,...) (Hinweis: Quelle [23] Böhm u.a.: Systementwicklung in der Wirtschaftsinformatik, v/dif Zürich 1993) Software-Entwicklungssyteme sind Hilfsmittel zur Organisation und Programmierung von Anwendungen. Die Merkmale/Aufgaben sind folgend genannt: - Verfügbarkeit mehrerer Entwurfsmittel - Vorgabe einer Entwurfslogik - Minderung des Programmieraufwandes durch Codegenerierung - Prüfung hinsichtlich Konsistenz und Abhängigkeiten über alle Stufen - Verwaltung von Benutzungschnittstellen Software-Entwicklungssysteme unterstützen die Phasen des Software-Lebenszykluss (jedoch nicht immer alle Phasen). Wesentliche Unterstützung wird bei der Wartung von Systemen verlangt. Ein Hauptziel ist auch die Verbesserung der Qualität von Software. Beispiele: - strukturierte Analyse und Designmethode * SADT: Structured Analysis and Design Technique * JSD : Jackson System Development * SSADM: Structured System Analysis and Design Methodology - objektorientierte Methoden (OMT, OOA/D) * OMT: Object Modeling Technique *UML: Unified Modelling Language Werkzeuge (Tool): Als Werkzeuge werden sogenannte eigenständige Software-Werkzeuge verwendet, die einen 16

17 oder mehrere Entwicklungsschritte unterstützen. - CASE-Tools Unterstützen ganz spezielle Phasen der Softwareentwicklung. * Upper-CASE Diagramm-Editoren, Dokumentationswerkzeuge Sie unterstützen die Phasen (a), (b), (c) (siehe 2.2). * Lower-CASE 3GL, 4GL, Compiler, Debugger, Programmgeneratoren Sie unterstützen die Phasen (c), (d), (e) (siehe 2.2). * I-CASE Dies sind Tools, die alle Entwurfsschritte unterstützen sollen. - Software-Tools im engeren Sinne Diese haben Einfluß auf den Code: Debugger, Compiler, Sprachen. - Software-Tools im weiteren Sinne Diese unterstützen den Vorgang der Softwareherstellung: Versionsmanager, Projektmanager Aktivitäten für die Entwicklung TIS: Phase Lebenszyklus Entwicklungsphase Entwicklungsschritt Arbeitsschritt zum Beispiel Softwareentwicklungssystem Gruppe von Tools Tool Tool-Funktion 2.3 Anwendungsentwicklung (Vorgehen) (Hinweis: Quelle [14) (a) Prinzip: vom Groben zum Detail (Top-down) [14] *Ist-Zustand analysieren (Stärken, Schwächen) *Ziele/Anforderungen festlegen *Groblösung entwicklen *schrittweises Verfeinern (Detaillierung) *mögliche Varianten untersuchen, evaluieren, eleminieren (b) Prinzip: von Detail zum Groben (Bottom-up) (c) Kombination von (a) und (b) anders: - Zielsuche: * Situationsanalyse *Zielfomulierung - Lösungssuche: * Synthese * Analyse - Auswahl: * Bewertung * Entscheidung 17

18 3 Analyse und Modellierung 3.1 Anforderungen an die Entwicklung technischer Informationssysteme Für dieses Themengebiet kann u.a. auf die folgende Quellen verwiesen werden: Max Vetter: Informationssysteme in der Unternehmung Teubner-Verlag Stuttgart 1994 Dieses Buch beschreibt die globale Sicht auf das Problem [14] J. Gausemeier u.a.: Erfolgspotentiale integrierter Ingenieursysteme Vortrag auf CAD-94 Dieser Vortrag beschreibt die Entwicklung von TIS [7]. Olaf Abeln: CAD-Referenzmodelle Teubner-Verlag 1995 Dieses Buch beschreibt die Realisierung von TIS [1]. Reiner Dumke: Software Engineering Vieweg Verlag 2000 Dieses Buch gibt uns eine generelle Übersicht zum Thema Software Engineering [4] Bernd Oesterreich: Objektorientierte Softwareentwicklung Oldenburg Verlag 1998 Dieses Buch vermittelt insbesondere UML.[28] Als Motivation für die Entwicklung Technischer Informationssysteme kann man die Anforderungen aus der globalen Verantwortung heranziehen:... nach Vetter gilt folgender Grundsatz: Globales Denken und globales Handeln ist die Voraussetzung zur Vermeidung der fortschreitenden Zerstörung der natürlichen Lebensgrundlage. Wege dazu: kleine, lokale Schritte mit genereller Zielstellung Für die Informatik gilt: Isolierte Betrachtungen führen in das Datenchaos! Man muss Lösungen entwickeln, die ein ganzheitliches Vorgehen unterstützen Es ist erforderlich: Eine neue Denkweise, insbesondere hinsichtlich - eines betriebsbezogenen Kollektivbewußtseins - des Kommunikationsverhaltens (ändern) - des Problemlösungsverhaltens (ändern). Neues Denken in der Informatik/Wirtschaftsinformatik bedeutet: - weg vom analytischen Denkmuster (kartesisch-newtonscher Prägung) weg von isolierten Lösungen (Insellösungen) - hin zu systemtheoretischen Denkweisen hin zu vernetzten Lösungen Bisher praktizierte Vorgehensweise in der Informatik: Im Vordergrund stand funktionsorientiertes Verhalten, funktionsorientierte Entwicklung d.h. eine analytische Vorgehensweise. Es werden zunächst relevante Funktionen für die Anwendung heraus gearbeitet, dann notwendige Daten ermittelt. Methode zeitigt wenig Erfolg! Sie führt in die Sackgasse wegen des zu erwartenden Datenchaos! 18

19 (Kopie) Abbildung 6 Die funktionsorientierte Anwendungsentwicklung [14] Neuer Ansatz: Ein objekt- und datenorientiertes Vorgehen wird praktiziert. Es entspricht dem systemtheoretischen Denkmuster (Kopie) Abbildung 7 Die objekt- und datenorientierte Anwendungsentwicklung [14] 19

20 Legende: A = Anwendung, Z,DZ = zentrale und dezentrale Datenbestände Mitarbeiter und Anwendungen orientieren sich an globalen, konzeptionellen Modellen; d.h., erst relevante Objekte, dann Methoden, daraus Objektmodell, darauf funktionale Anwendungen Vorteil: Objekte sind leichter zu erkennen und leben auch länger: Wichtiger Grundsatz:... Die globale Objektstruktur ist nur solidarisch und kooperativ zwischen allen Beteiligten zu entwerfen. globales Denken = systemtheoretische Betrachtung Weiterer Vorzug des systemtheoretischen Denkens: Durch globalen Ansatz werden Lösungen übersichtlicher, indem z.b. föderalistische Lösungen und verständlichere Lösungen erzeugt werden. Prinzip der Stärkung des Kollektivbewußtseins (Kopie) Abbildung 8 Die Schaffung eines betriebsbezognen Kollektivbewußtseins [14] Legende: Bedeutung der eingekreisten Ziffern: 1 Der Mitarbeiter orientiert sich an den von der Geschäftsleitung vorgegebenen Unternehmenszielen. 2 Die Kenntnisse eines Mitarbeiters fließen in das globale konzeptionelle Datenmodell mit ein. 3 Im globalen konzeptionellen Datenmodell konvergiert das Wissen und die Denktätigkeit der Belegschaft. 20

21 (Kopie) Abbildung 9 Kommunikationsprinzipien im Verlaufe der Zeit [14] Prinzip der Solidarität 21

22 (Kopie) Abbildung 10 Kommunikationsprinzip solidarisch [14] Zusammenfassend: - Bei einer konzeptionellen Arbeitsweise wird die Lösung für ein Problem vom Groben zum Detail (top-down) entwickelt. - Konzeptionell arbeiten heißt abstrahieren. - Bei einer konzeptionellen Arbeitsweise werden hardware- und softwarespezifische Überlegungen zurückgestellt, bis eine logisch einwandfreie Lösung vorliegt. Ein Problemlösungsverhalten entsprechend der Systemtheorie bedeutet, ein System von einem Ist-Zustand über die Lösung des Problems in einen Soll-Zustand zu überführen. Problem dabei: Problem ist soll - Vorstellung Abbildung 11 Problemlösungsprozeß Definition System: 22

23 Ist eine abgeschlossene Einheit von Elementen, die durch Beziehungen verknüpft sind und gemeinsam ihren Zweck erfüllen sollen. Möglichkeiten zur Abbildung der Realität z.b. durch: - Konstruktionselemente: Objekte, Methoden, Entitäten, Eigenschaften, Beziehungen - Überlagerungstechniken: Generalisierung, Spezialisierung, Aggregation - Beziehungstypen: Assoziationen - konzeptionelle objekt- oder datenorientierte Modelle Ein praktisches Vorgehen könnte diesem entsprechend dem Denkmuster nach Vetter [14] entsprechen. (Kopie) Abbildung 12 Vorgehensmodell nach [14] Legende: A1, A2,... = Anwendungen OSD = Objektsystem-Design ISD = Informationssystem-Design KDBD = Konzeptionelles Datenbankdesign PD = Prozessdesign Die einzelnen Ebenen: Strategiefestlegung - konzeptionelles Datenmodell - Anwendungen darauf Objektsystem-Design OSD Im Rahmen dieses Prozesses sind folgende Punkte zu klären (Klärungsprozess): - Problemfeld - Ist-Zustand mit Stärken und Schwächen - Anforderungen an Soll-System - systemmäßige Groblösung - Konzept zur Einbettung in Umgebung Informationssystem-Design ISD (Layouts, Benutzersichten, struktureller Aufbau) - Outputs und dazugehörige Layouts und Strukturen 23

24 - Inputs - Ablaufprozesse für die Bearbeitung der Inputs zu Outputs Konzeptionelles Datenbankdesign (KDBD) - konzeptionelles Daten- bzw. Objektmodell - Views Prozessdesign (PD) - Logik der Prozesse für die Bearbeitung - Realisierung - Nutzung Entwicklungsanforderungen an TIS nach Gausemeier[7] (vgl. Abb ) Synonyme: -Technisches Informationssystem -rechnerunterstützte Ingenieursysteme -integrierte Ingenieursysteme - CAE Computer Aided Engineering Als Werkzeuge sind solche erforderlich, - die die frühen Phasen des Produktentwicklungsprozesses unterstützen (Konstruktion, Entwurf), - die Prozesstechnologie unterstützen, - die Lösungselemente benutzen (Feature-Techologie) - die moderne Architekturen unterstützen, - die Führungsinstrumente schaffen (EDM -Engineering Database Management system), PDM - Product Database Management,...). 24

25 (Kopie) Abbildung 13 Erfolgspotentiale im Produktentwicklungsprozeß [7] 25

26 (Kopie) Abbildung 14 Aufbau eines integrierten Ingenieursystems [7] (Kopie) 26

27 Abbildung 15 Forschungsgebiete für Rechnerunterstützte Ingenieursysteme [7] (Kopie) Abbildung 16 Umfeld für CAE-Systeme Anforderungen aus der Realisierung nach Abeln [1] sind (Hinweis: anhand des Beispiels CAD-System erfolgt die Erläuterung.) 1.aus Prozess heraus: Anforderungen sind spezifisch für den Diskursbereich oder übergreifender Art. Für den Entwurf eines CAD-Systems gelten z.b. nach Abeln Anforderungen bezüglich - der Organisation des Konstruktionsablaufs, - des Produktmodells, - der Systemkonfiguration, - des Modellierers, - der Analyse, Berechnung und Simulation, - der Wissensverarbeitung und Dokumentation, - der Benutzungsoberfläche und Benutzerunterstützung, - der Integration. Anforderungen an die Konstruktionsunterstützungsmittel sind - Werkzeuge zur Modellierung aller produktbeschreibenden Daten (z.b. zur Prinzipienmodellierung, Feature), - Komponenten zur Informationsbereitstellung und wissensbasierten Unterstützung, - Werkzeuge zur Kommunikation mit entfernten Partnern (Mail, DesignKonferenzen), - Softwarekomponenten zur Unterstützung kooperativer Arbeitstechniken, - Analysemethoden. 27

28 (Kopie) Abbildung 17 CAD-Referenzmodell [1] 2. aus Sicht des Informatikers: - Nutzung vorhandener Systeme, - modernste Plattform nutzen, - Offenheit (Wiederverwendbarkeit) garantieren, - Konfigurierbarkeit sichern, - Prototyping verwenden - Auf die Verwaltung größerer Datenmengen einstellen, - Behandlung komplexer Modelle (tiefere Strukturen) realisieren, - Standards berücksichtigen. 3.2 Analysemethoden und Werkzeuge Allgemeines Literaturhinweise: Rumbaugh u.a.: "Objektorientiertes Modellieren und Entwerfen\ (Quelle [19]) Martin/Odell: "Objectoriented Analysis and Design\ (Quelle [18]) Schäfer: "Objektorientierte Entwurfsmethoden\ (Quelle [20]) Yourdon: "Moderne strukturierte Analyse\ (Quelle [27]) Vetter: "Aufbau betrieblicher Informationssysteme\ (Quelle [14]) Achatzi: "Praxis der strukturierten Analyse\ (Quelle [2) Dumke: "Modernes Software Engineering\ (Quelle [4]) Analyse Einordnung: erste Lebenszyklus-Phasen Definition (Systemanalyse) Systemanalyse ist das Studium und die Beschreibung eines Systems, um den prinzipiellen Aufbau zu verdeutlichen und die wichtigsten Merkmale zu dokumentieren. 28

29 Schritte: - Untersuchen (Studium) - Abstraktion (Begriffe definieren; Verallgemeinerung; Feststellung des prinzipiellen Aufbaus) - Dokumentation In der Informatik bedeutet dies: Systemanalyse ist die Erforschung des Problemumfelds. Problematik der Analyse: - Im Bereich der betrieblichen Informationssysteme sind die Mitarbeiter des Unternehmens/Abteilung die Spezialisten und Fachleute. Sie sollten die Prozesse und die Zusammenhänge im Unternehmen am besten kennen. - Der Softwareentwickler/Informatiker weiß meist nur sehr wenig über die internen Abläufe und Strukturen, jedoch ist fachliche Kenntnis (Grundwissen) von großem Vorteil. - Eine Analyse wird nicht ausschließlich von Informatikern durchgeführt, sondern immer in Zusammenarbeit mit den jeweiligen Fachleuten. - Ein wichtiges Hilfsmittel bei der Analyse ist die GRAPHISCHE DARSTELLUNG von Abläufen, Strukturen und Zusammenhängen. - Es sollte unbedingt eine einheitliche Begriffs- und Darstellungswelt geschaffen werden (verwendet werden), um Mißverständnisse zu vermeiden. (Denn ein Ingenieur hat eine andere Sicht als ein Informatiker.) Formen / Arten der Systemanalyse Natürlichsprachlicher Ansatz - einfachste Form der Analyse - einfachste Form etwas zu beschreiben - Bestandteile und Charakteristik eines Systems werden ausschließlich in Textform beschrieben - Daten, Strukturen und Abläufe sind über das gesamte Dokument verteilt. - Für einfache Sachverhalte reicht dies aus, aber nicht für komplexe Systeme. - Eigentlich kann jede Problemstellung beschrieben werden. Funktionsorientierte Analyse - Herausfinden der für die Anwendung relevanten Funktionen - Funktionen werden in Schritte, Unterschritte zerlegt. - Daten zuordnen / Schnittstellen zwischen den Funktionen organisieren. z.b.durch klassische Programmiersprachen (PASCAL, C, FOTRAN) Vorteil: relativ günstige Voraussetzungen für spätere Programmierung; Programmerstellung ist der gleiche Prozess. Nachteil: kein optimales Datenmodell ( zum Beispiel: Auftreten von Redundanz) Datenorientierte Analyse - Daten stehen im Mittelpunkt der Betrachtung. - grobe/umfassende Datenstruktur (sehr grobes, konzeptionelles Datenmodell) -Architektur wird detailliert. - nachträgliche Beschreibung der (datenbearbeitenden) Funktionen Vorteil: umfassendes Abdecken der betrachteten Bereiche Nachteil: schwierige Wartung; schwer nachvollziehbare Zuordnung zwischen 29

30 Funktionen und Daten Strukturierte Analyse -Vereint prozess- (funktionsorientierte) und datenorientierte Vorgehensweise. (Vorteile!) zum Beispiel durch + Datenflussdiagramme + Zustandsübergangsdiagramme - Zunächst Konzentration auf Funktionsbeschreibung Funktion Daten zuordnen Funktionen verfeinern Neustrukturierung der Daten (Verfeinern) - Verfeinerung immer schrittweise und unter Berücksichtigung beider Aspekte Werkzeuge zur Strukturierten Analyse Das Ziel der Strukturierten Analyse ist das Finden und Aufstellen eines Modells. Die dabei benutzten Werkzeuge sind u.a.: + Datenflußdiagramm (DFD): Sie illustrieren Funktionen, die das System ausfüllen muß. + Entity Relationship Diagram (ERD): Zur Darstellung der Beziehungen der Daten untereinander. + Zustand- Übergangs-Diagramm (STD): Konzentrieren sich auf das zeitabhängige Verhalten des Systems (Folge von Zuständen). zum DFD: Illustrieren Funktionen, die das System ausfüllen muß. System wird als Netzwerk von Prozessen aufgefaßt. Auch Bubble Chart, Prozeßmodell, Arbeitsflußdiagramm, Funktionsmodell genannt. Besonders für aufgaben- (funktions-) orientierte Systeme, wo die Funktionen wichtiger (schwieriger/komplizierter) erscheinen als die Daten, geeignet. Komponenten von DFD sind: + Prozess (Funktion): Ist ein Teil des Systems, der umgewandelt/transformiert wird. Es wird das WAS beschrieben, nicht das WIE! Beispiel: Hinweis: Darstellungsvarianten: Kreis, Oval, Rechteck Berechne Verkaufssteuer Abbildung 18 Prozeß + Fluß: Repräsentiert Daten in Bewegung. Telefonnummer Überprüfen Telefonnummer gültige Telefonnummer ungültige Telefonnummer 30

31 Eingabefluß Ausgabefluß Dialogfluß Divergierender Fluß Abbildung 19 Fluß + Speicher: Stellt den Ruhezustand der Daten dar. Ist immer in Kontext mit Datenfluß. Speicher sind passive Komponenten. Veränderungen nur durch Prozesse am anderen Ende des Flusses (Schreiben, Aktualisieren, Löschen,...). Hinweis: Der Datenfluß in bzw. aus einem Speicher ist nur durch Prozesse möglich. Aufträge Abbildung 20 Speicher + Terminatoren: Handlungsobjekt kommuniziert mit dem System (externes Objekt). Bsp.: Person / Gruppe oder anderes System Befindet sich außerhalb des Systems. Beziehungen zwischen Terminatoren werden nicht dargestellt. Inhalt und Funktionsweise kann nicht vom Systemanalytiker verändert werden. Buchhaltungsabteilung Abbildung 21 Terminator Karte Bank wählen Konto Name Saldo Kunde Wunsch aktualisieren Abbildung 22 Datenflußdiagramm für eine Bank zum ERD: Komponenten sind: + Entity + Relationen + Objekte Entity Relation Abbildung 23 Notation zum ERD ERD eignen sich besonders zum Entwurf relationaler Datenbanken. zum STD (State Transition Diagram): 31

32 Es wird die Frage beantwortet: Was passiert in welcher Folge? Komponenten sind: Zustände, Übergänge Dabei ist ein Zustand eine Gruppe von Umständen oder Eigenschaften, die eine Person oder einen Gegenstand zu einem gewissen Zeitpunkt charakterisieren.?beispiel: Zustand: "Warte auf Eingabe! Warten heißt, daß im externen Umfeld etwas geschieht oder, daß eine Tätigkeit im Umfeld durch eine andere abgelöst wird. Zusätzlich (optional) ist es möglich, Bedingungen und Aktionen zu definieren. Bedingung Aktion Zustand 1 Zustand 2 Abbildung 24 Notation STD Wichtig ist die Klärung der folgenden Fragen bzw. es ist zu überprüfen, ob alle Zustände definiert sind, alle Zustände erreichbar sind, alle Zustände (bis auf den Endzustand) einen Ausgang haben, das System in jedem Fall richtig reagiert unter Berücksichtigung der Bedingungen und der Aktionen. Anwendung eines Zustands-Übergangs-Diagramms in Zusammenspiel mit anderen Diagrammen (DFD, ERD, usw.) ist möglich. Abbildung 25 DFD und STD in Kombination Objektorientierte Methoden und Werkzeuge Objektorientierung bedeutet: Software als Kollektion diskreter Objekte Nach Bernd Oesterreich [28] Der ganzheitliche und am Menschen orientierte Ansatz, wie er von den maßgeblichen Begründern der Objektorientierung (im Xerox PARC) von Anfang an verfolgt wurde, wird an vielen Stellen deutlich: Das Klassenkonzept begünstigt die Entwicklung von Softwareeinheiten, die nicht einer speziellen Anwendung, sondern einem speziellen Konzept bzw. einer bestimmten Idee von der Realität dienen und die als solche in verschiedenen Kontexten und somit auch verschiedenen Anwendungen operieren können. Die Welt der oo Softwareentwicklung ist eine bildreiche Welt: Begriffe wie Vererbung, Botschaftenaustausch, das Werkzeug-Material-Leitbild usw. belegen die Methaphorik und deuten die ontologischen Grundprinzipien an. Die Symbole der grafischen Benutzeroberflächen wie Mülleimer, Drucker, Lupe, Ordner, Pinsel, Schere und so weiter tun ein übriges und ermöglichen den BenutzerInnen ein anschauliches und intuitives Handeln. 32

33 Objektorientierte grafische Benutzeroberflächen verhelfen zu einer einheitlichen Bildschirmorganisation und zu Bedienungsstandards, sie leiten die ApplikationsentwicklerInnen an, diese Standards zu übernehmen und ihr Look-&-Feel nachzuahmen Zu den Unterschieden zwischen strukturierten und objektorientierten Methoden heißt es: Ganzheitliche Arbeitsgegenstände Statt der Trennung von Daten und Operationen wird nun durch das Klassenkonzept mit Einheiten aus Daten und Operationen gearbeitet. Bessere Abstraktionsmöglichkeiten Die oo Methoden verschieben die Modellierung stärker als die strukturierten vom Lösungs- in den Problembereich. Methodische Durchgängigkeit Die Ergebnisse einer Aktivität i im oo Entwicklungsprozeß läßt sich ohne weiteres in die Aktivität i+1 übernehmen und umgekehrt: in allen Phasen der Softwareentwicklung wird mit denselben Konzepten gearbeitet (Klassen, Objekte, Beziehungen,etc.) Es findet kein Wechsel der Modellpräsentation statt. Evolutionäre Entwicklung Ein komplexes System entsteht nicht in einem Rutsch. Alle komplexen Systeme in der Natur haben sich schrittweise entwickelt, jeder Zwischenschritt mußte sich erst einmal stabilisieren und seine Funktions- und Lebensfähigkeit beweisen. Im Laufe der Zeit ist auf diese Weise das komplexe System Mensch entstanden. Mit den oo Softwareentwicklungsmethoden kann das Prinzip der Evolution auf die Softwareentwicklung übertragen werden. Es existieren eine Reihe von Anwendungsfeldern für objektorientierte Methoden: OOGUI (Oberflächen) OOP (objektorientierte Programmiersprachen) ODBMS (Datenbanken) OOA/OOD (Analyse- und Entwurfsmethoden). Wichtige Aspekte sind: - Identität von Objekten: Daten werden diskreten, unterscheidbaren Entitäten zugeordnet. Objekte sind klar voneinander unterscheidbar. (zum Beispiel: Adressen im Speicher des Computers) - Klassifikationen von Objekten: Objekte mit gleicher Struktur (Attribute) und mit gleichem Verhalten (Methoden) werden zu Klassen zusammen gefaßt. (Klasse Abstraktion) - Polymorphismus: Bedeutet gleiche Operationen in unterschiedlichen Klassen. Sie werden dabei aber verschieden realisiert, d.h. sie besitzen eine unterschiedliche Bedeutung bzw. haben eine unterschiedliche Realisierung. - Vererbung: Gemeinsame Verwendung von Attributen und Operationen durch verschiedene Klassen auf der Basis hierarchischer Relationen. OO-Entwicklungsmethoden: Ziel: Abbildung der Struktur des Problembereiches auf die Implementierung Vorteil: Durchgängigkeit: Eine Methode über alle Phasen des Softwarelebenszyklusses Wiederverwendbarkeit: Gesamtsystem in kleine Objekte zerlegen, die dann wieder verwendet werden können. "sanfter Übergang zwischen den Phasen: In der Analyse gefundene Objekte werden im Entwurf kontinuierlich weiterentwickelt (verfeinert). Oft wird mit gleicher Notation weitergearbeitet. 33

34 Methoden und Vertreter dieser Richtung: - OOA/OOD von Coad/Yourdon - OMT von Rumbaugh - Booch `91 von Booch Die drei Amigos! - OOSE Jacobson - OOSA Shlaer/Mellor - RDD Wirfs-Brock - UML Amigos siehe auch [28, Seite 20] OMT [19] nach Rumbaugh - Vertreter des evolutionären Ansatzes - Werkzeuge: StP/OMT und OMTool (Software through Pictures) - Blickwinkel +Objektmodell +Dynamikmodell +Funktionsmodell Entwicklungsprozess innerhalb von OMT Phasen und Aktivitäten - Analyse (1) Problembeschreibung (2) Objektmodellierung + Identifizierung der Objekte und Klassen + Erstellen eines Data Dictionary + Identifizierung der Assoziation + Identifizierng der Attribute + Organisieren und Vereinfachung durch Vererbung + Überprüfen und Verfeinern + Gruppieren der Klassen in Subsysteme + Objektmodell = Objektmodelldiagramm + Data Dictionary (3) Dynamikmodellierung + Vorbereiten von Szenarien mit typische Interaktionssequenzen + Identifizierung der Ereignisse zwischen Objekten : Ereignisflußdigramme für das System + Erstellen des Zustandsdiagramms für jede Klasse + Konsistenz und Vollständigkeitsüberprüfung der Ereignisse, die sich auf mehrere Zustandsdiagramme beziehen. dynamisches Modell = Zustandsdiagramm + globales Ereignisflußdiagramm (4) Funktionsmodellierung + Identifizieren der Ein- und Ausgabewerte + Erstellen eines DFD + Beschreiben der Funktionen + Identifikation von Einschränkungen Funktionales Modell = Datenflussdiagramm + Einschränkungen - Entwurf (1) Systemdesign + Aufteilung in Subsysteme + Identifizierung der Nebenläufigkeit 34

35 + Zuweisen der Subsysteme zu Prozessen / Prozessoren + Speicherung der Daten + Bestimmen der Implementierung der Steuerung Systementwurfsdokumente = Struktur der grundlegenden Systemarchitektur und globale Strategieentscheidungen (2) Objektdesign + Erweitern des Objektmodells um Operationen + Entwurf von Algorithmen + Optimierung + Implementierung der Steuerung + Festlegen der Implementierung von Assoziationen + physische Gruppierungen + Dokumentation des Designs Entwurfsdokument = detailliertes Objektmodell + detailliertes dynamisches Modell + detailliertes funktionales Modell Methode nach Grady Booch 1991/94 (OOAD) - Object-Oriented Analysis and Design with Application - Rational Rose ist entsprechendes Werkzeug. - Ist eine evolutionäre Entwurfsmethode. - Ist gibt verschiedene Blickwinkel auf das System: +logische und physische Sicht Klassendiagramm,Objektdiagramm, Moduldiagramm & Prozeßdiagramm + Beschreibung der Dynamik Zustandsdiagramm, der Klasse zugeordnet Interaktionsdiagramm, unterstützt Objektdiagramm OOSE-Methode nach Jacobsen Objekt-Oriented Software Engineering Brachte den Ansatz der Use Cases (Anwendungsfälle ) mit ein UML- Unified Modeling Language Einführung Als Zusammenfassung der Erkenntnisse von Booch, Rumbaugh und Jacobson 1997 als UML bei der OMG eingebracht. (Papier-Kopie) Abbildung 26 Historische Entwicklung der Programmiersprachen (Papier-Kopie) Abbildung 27 Entwicklung der oo Softwareentwicklungsmethoden Neben den Ideen dieser drei Amigos sind z.b. die State Charts (Zustandsdiagramme) von Harel [D.Harel: Statecharts: A Visual Formalism for Complex Systems, in: Science of Computer Programming 8, 1987,S.231ff) mit verwendet worden. Die UML arbeitet mit diesen Komponenten: - Klassendiagrammm - Objektdiagramm - Anwendungsfalldiagramm 35

36 - Zustandsdiagramm - Sequenzdiagramm - Aktivitätsdiagramm - Kollaborationsdiagramm - Komponentendiagramm - Einsatzdiagramm Weitere Features sind: Pakete, Notizen, Stereotypen (Papier-Kopie) Abbildung 28 Notation UML (Quelle: Oesterreich) Zur Erläuterung der UML: Nach Joseph Schmuller : UML, Markt und Technik 2000 [29] - Klassendiagramm Gegenstände lassen sich von Natur aus in Kategorien einteilen: Bäume, Autos, Möbel. Diese Kategorien wollen wir Klassen nennen. Klassen faßt demzufolge eine Gruppe von Dingen mit ähnlichen Attributen und gemeinsamen Verhaltensweisen zusammen. Beispiel Klasse Waschmaschine Waschmaschine Herstellernahme Modellbezeichnung Seriennummer Kapazität Wäsche einfüllen() Waschmittel einfüllen() Wäsche ausladen () Abbildung 29 Klassendiagramm Wozu Klassen? Klassen abstrahieren in konzentrierter Weise von der Realität. Sie unterstützen ebenfalls die Analysearbeit sehr gut. Unter Verwendung von Beziehungen zwischen Klassen entstehen Klassendiagramme. - Objektdiagramm Ein Objekt ist die Instanz einer Klasse, d.h., die Attribute und Verhaltensweisen haben spezifische Werte. Beispiel_Objekt Mein Wäscher Mein Wäscher: Waschmaschine Herstellername: Siemens Modellbezeichnung:. Abbildung 30 Objektdiagramm Über Verknüpfungen zwischen Objekten werden Objektdiagramme gebildet. - Anwendungsfalldiagramm 36

37 Ein Anwendungsfall (use case) ist die Beschreibung des Verhaltens eines Systems vom Standpunkt des Anwenders aus. Hiermit können die Beziehungen zwischen Kunden, Entwicklern und Anwendern von Softwaresystemen beschrieben werden. Beispiel Anwendungsfall Wäsche waschen Akteur Anwendungsfall Abbildung 31 Anwendungsfalldiagramm - Zustandsdiagramm Jedes Objekt hat in einem bestimmten Zeitpunkt einen bestimmten Zustand. Ein Mensch kann z. B. ein Neugeborenes, ein Säugling, ein Kind, ein Teenager usw. sein. Ein UML-Zustandsdiagramm hält einen Ausschnitt der Realität fest. Beispiel Zustandsdiagramm einer Waschmaschine Einweichen Waschen Spülen Schleudern Abbildung 32 UML-Zustandsdiagramm - Sequenzdiagramm Klassen und Objektdiagramme halten den statischen Aspekt fest. In einem System interagieren aber die Objekte miteinander. Das UML-Sequenzdiagramm zeigt die Dynamik der Interaktionen. Es wird darin festgehalten, wie die Objekte über einen Zeitraum interagieren. Wasserrohr Trommel Abfluß Frisches Wasser Schicken Anhalten Stop Abbildung 33 Sequenzdiagramm - Aktivitätsdiagramm Das Aktivitätendiagramm bildet die Abfolge der Aktivitäten ab, ohne den Bezug zu den Objekten oder Anwendungsfällen zu zeigen. 37

38 Trommel 15 Min. hin und her rotieren lassen Seifenwasser ablaufen lassen Erneut Wasser zuführen Abbildung 34 Aktivitätendiagramm - Kollaborationsdiagramm Elemente eines Systems arbeiten zusammen, um die Zielstellung zu erreichen. Diesen Zusammenhang verdeutlicht das Kollaborationsdiagramm. Interner Timer 1: Stop 2: Hin und her rotieren Wasserrohr Trommel Abbildung 35 Kollaborationsdiagramm - Komponentendiagramm Komponentendiagramme sind ausdrücklich für die Softwareentwicklung gedacht, d.h., sie sind auf Computersysteme orientiert. Komponente Abbildung 36 Komponentendiagramm - Einsatzdiagramm Zeigt die physische Architektur eines computergestützten Systems. Prozessor 1 Prozessor 2 Prozessor 3 Abbildung 37 Einsatzdiagramm - weitere Features Pakete fassen Klassen zusammen. Notizen geben ergänzende Erläuterungen. Stereotype passen UML-Elemente an. 38

39 Paket 1 Text Klasse1 Klasse 2 Klasse Klasse 3 <<Interface>> Klasse 1 Abbildung 38 Pakete, Notizen, Stereotype Bisherige Zusammenfassung zu UML: Systementwicklung ist eine menschliche Aktivität. Ohne eine leicht verständliche Notation ist der Entwicklungsprozeß sehr fehleranfällig. UML ist zum Standard geworden. Ein UML-Modell sagt aus, was ein System tun soll, aber nicht, wie. Objektorientierte Konzepte und UML OO Konzepte sind: + Abstraktion Abstraktion bedeutet, die Realität soweit zu filtern, bis die für den Zweck wesentlichen Aspekte ( Attribute und Methoden) übrig bleiben. + Vererbung Ein Objekt nimmt alle Charakteristika seiner Klasse als Instanz an. Darüber hinaus können auch Hierarchien aufgebaut werden, indem Klassen in Beziehung zu anderen Klassen als Suboder Superklassen gesetzt werden können. Die Subklasse erbt alle Charakteristika von der Superklasse. + Polymorphismus Oftmals haben Operationen aus der Sicht der Gewohnheit in unterschiedlichen Klassen den gleichen Namen (z.b. zeige Punkt, zeige Kreis, zeige Fenster..). Diese sind natürlich in jeder Klasse unterschiedlich implementiert und es wird während der Ausführung auf die "richtige" Operation Bezug genommen. + Kapselung Klassen können organisieren, daß bestimmte Attribute und Methoden nur intern im Rahmen der Klasse verwendet werden dürfen (Information hiding!). Damit sichert man sich gegen unbefugte Benutzung. Die Kommunikation mit den Objekten erfolgt über öffentliche Methoden, die die Schnittstelle bilden. + Versenden von Nachrichten Objekte arbeiten in einem System zusammen, indem sie einander Nachrichten senden. Dazu werden Schnittstellen benutzt. + Assoziationen Objekte können miteinander eine oder mehrere Beziehungen aufbauen, die über Assoziationen zwischen den Klassen ausgedrückt werden. + Aggregationen Die Aggregation ist eine besondere Form der Assoziation, indem die Klassen bzw. Objekte über eine Hierarchie zusammenhängen. Es wird quasi die Beziehung " besteht aus" ausgedrückt. 39