Simulation komplexer technischer Anlagen Was wir bisher gelernt haben

Präsentation zum Thema: "Simulation komplexer technischer Anlagen Was wir bisher gelernt haben"—  Präsentation transkript:

1 Simulation komplexer technischer Anlagen Was wir bisher gelernt haben
Ziel der Vorlesung Kennen lernen von Methoden zum Bau virtueller Anlagen Vorlesung 1: Modelle als Basis realer und virtueller Anlagen Vorlesung 2: Ingenieurmethoden zur Reduktion und Beherrschung von Komplexität Abstraktion und Strukturierung mit den Elementen Strukturierung der Systeme Ganzes und Teile - Allgemeines und spezielles Diversifikation der Funktionalitäten - fachlich + zeitlich Verbergen von Details hinter Schnittstellen Formalisierung der Beschreibungen - Produktmodelle Formalisierung der Funktionen - Dienste und Komponenten Wiederverwendung bewährter Komponenten Qualitätssicherung mit den Elementen Prozessüberwachung Produktüberprüfung Projektmanagement

2 Das sollten Sie heute lernen
Teil I: Reale und virtuelle Anlagen Kapitel 2: Wie lässt sich eine Anlage auf dem Rechner modellieren ? Klassische Methoden des Software Engineerings Was ist eine virtuelle Anlagen Grundelemente der Informationsverarbeitung: Daten und Methoden Algorithmen und Datenstrukturen Abstrakte Datentyp Module und Funktionsmodule Methoden des Software Engineerings zur Reduktion der Komplexität: Strukturierung, Funktionale Zerlegung, Lebenszyklus RSYST als Beispiel eines Systems zum Bau virtueller Anlagen auf Basis von ADT- und Funktions-Modulen. Techniken zur Unterstützung des kooperativen Arbeitens

3 Virtuelle Anlagen -1 Definition
Modellierung eines komplexen Systems auf Rechner Eigenschaften Beschreibung als System - Gesamtsystem mehr als Summe von Teilen Systembeiträge aus verschiedenen Bereichen - Erstellung interdiszipliär Systemerscheinung benutzerangepasst - verschiedene Sichten nötig

4 Virtuelle Anlagen -2 Nutzung (analog detaillierter Modelle) Erstellung
Einhaltung von äußeren Vorgaben, z.B. Sicherheitsanforderungen Überprüfung innerer Konsistenz z.B. Verbindung von Teilsystemen Datenkonsistenz zwischen einzelnen Abteilungen z.B. Komponentenauslegung, Verfahrenstechnik, Leittechnik Einbringung von Änderungen Vereinheitlichung der Dokumentation Bindeglied zwischen Theorie und Realität Erstellung Analog Planung, Bau und Betrieb realer Anlagen

5 Virtuelle Anlagen -3 Zusammenfassung
Virtuelle Anlagen müssen Grundeigenschaften der Anlagen haben, sind also hierarchisch und funktionsbezogen aufzubauen Virtuelle Anlagen müssen parallel zur Planung der Anlage entstehen, sind also dynamisch anzusetzen Virtuelle Anlagen müssen direkt in Anlagen umsetzbar sein, sind also über projektangepasstes Produktmodell zu beschreiben Virtuelle Anlagen sind Formalisierungen des Planungsprozesses und können daher in reale Anlagen umgesetzt werden

6 Beispiel Gebäudemodellierung

7 Techniken zum Bau virtueller und realer Anlagen
Bildung hierarchischer Modelle zur Beschreibung und funktionalen Zerlegung (SIMPLIFIZIERUNG) Identifizierung funktionaler Einheiten Beschreibung von Funktionen, Schnittstellen und Verbindungen Verschiedene Sichten auf Produktdaten ermöglichen Reduktion der Komplexität durch (SPEZIALISIERUNG) Beschreibung über Entitäten, die Funktionen und dazu benötigte Daten kapseln Zerlegung in unabhängig bearbeitbare Teilaufgaben, die Lösungsdetails hinter Schnittstelle verbergen Verteilung der Aufgaben an Spezialisten entsprechend dem Projektstand Integration von Teilen zu Systemen (STANDARDISIERUNG) Systementwicklung interdisziplinär und iterativ Systemverständnis theoriegestützt und dynamisch Verbindung der Komponenten durch Verbinden der Schnittstellen Qualitätssicherung durch organisatorische Maßnahmen technische Maßnahmen (Kooperation, Koordination, Kommunikation)

8 Lösung von Problemen Problem Reduktion Modell Methoden zur
Abstrakte Datentyp-Module Methoden zur Lösung (Beschreibung des Verhaltens) Simulationsprogramm Reduktion Komplexität Funktions- Module Reduktion Modell Methoden zur Beschreibung Datenstruktur Algorithmen Modulares System

9 Datenstruktur -1 Definition Zusammenfassung von Daten verschiedenen Typs zur Beschreibung eines Problems Realisierung eines Abstrakten Datentyps auf Rechner Datentypen Beschreibt für die Variablen eines Typs die Menge der möglichen Werte und die darauf zulässigen Operationen Abstrakter Datentyp Datenstruktur + darauf definierten Operationen

10 Datenstruktur -2 Implementierung einer Datenstruktur
bestimmt Effizienz der darauf definierten Operationen Erfahrung Falsch gewählte Datenstrukturen können Lösung eines Problems unmöglich machen Schlussfolgerung Es müssen verschiedene Sichten auf Daten eines Problems möglich sein

11 Abstrakte Datentypen qualitative Beschreibung
Ein ADT ist eine Klasse von Datenobjekten, welche durch Operationen, die mit diesen Datenobjekten ausführbar sind, die Resultate dieser Operationen und evtl. Korrekt-heitsbedingungen und Ausnahmebedingungen vollständig charakterisiert ist. ADT's heißen abstrakt, weil - keine Aussage darüber gemacht (und benötigt) wird, wie die Operationen auf den Datenobjekten der Klasse realisiert (implementiert) sind, - die Operationen, ihre Ergebnisse und die Ausnahmebedingungen vollständig in einem mathematischen Formalismus definiert werden können, der u.U. später sogar zum formalen Beweis der Korrektheit einer Implementierung des ADT herangezogen werden kann. Da man nicht weiß und auch nicht herausfinden kann, wie der ADT 'von innen aussieht', ist für die Verwendung des ADT in einem System nur der Satz von Operationen relevant, die ihn charakterisieren.

12 Eigenschaften eines ADT
1. Ein ADT ist durch die Definition der Operationen auf allen Datenobjekten des Typs, die zulässigen Parameter sowie die festgelegten Bedingungen erschöpfend beschrieben. 2. Der Benutzer des ADT weiß nichts über dessen Realisierung. 3. Datenobjekte eines ADT sind ausschließlich über die definierten Operati-onen ansprechbar; evtl. zur Implementierung benötigte Speicherstrukturen sind (idealerweise) unerreichbar, dürfen aber jedenfalls nicht verwendet werden.

13 Abstrakte Datentypen: formale Beschreibung
Definition: ADT enthält Datenstrukturen und definiert Funktionen bzw. Schnittstellen zu ihrer Verarbeitung. Datenstruktur und Funktionen (Methoden) bilden Klasse. Klasse benötigt Beschreibung (Definition, abstrakte Klasse) Ausprägung (Exemplar, Objekte, Instanz) Nachrichten (messages) aktivieren in Klasse definierte Methoden. Sie liefern von Exemplar abhängige Resultate - Polymorphie Strukturierte Klassen: Klassen enthalten als Attribute Klassen Oberklasse + Unterklasse. Kann Unterklasse Methoden und Daten ihrer Oberklasse verwenden, spricht man von Vererbung.

14 Beispiele für abstrakte Datentypen
Grundtypen Integer, Real, Character, etc. ADT's aus der Datenverarbeitung Tupel - Satz von Grundtypen Operationen: SQL Menge - Sammlung gleichartiger Datenobjekte Operationen: Schnitt und Vereinigung Abbildung - Relation zwischen ADT's Operation: Erzeugung von Tupeln Folge - Geordnete Menge Operation: Warteschlangen ADT's aus der Numerik Vektor - Folge von Zahlen, Länge N Operationen: Vektoroperationen Matrix - zweidimensionale Anordnung einer Menge Text - Folge von Character Operationen: abhängig von Semantik (Beschreibung, Programm, Prozedur, Eingabe)

15 ADT - Modul Zu jeder Datenstruktur gehören Basisoperationen wie
Generieren, Modifizieren, Speichern oder Darstellen Module, die diese Operationen für einen Datentyp zur Verfügung stellen, heißen Abstrakte Datentyp-Module. ADT-Module können als Folge von Operationen unter einer Schnittstelle beschrieben werden. Sie verbergen Details der Implementierung der Datenstruktur. Beim Aufruf eines ADT-Moduls muss die gewünschte Operation angegeben werden. Das Resultat der Operation ist vom Zustand des Datenobjektes abhängig, ADT-Module haben ein Gedächtnis.

16 Algorithmen -1 - einer konkreten Programmiersprache
Definition Verfahren zur Lösung von Problemen, die auf Modellen basieren Eigenschaften Korrektheit - durch Testen kann man Anwesenheit von Fehlern nachweisen Effizienz - Speicherbedarf Rechenzeitbedarf je als Funktion der Problemgröße Implementierung Abbildung eines Verfahrens auf Grundoperationen - einer konkreten Programmiersprache - eines konkreten Rechners

17 Algorithmen -2 Grundoperationen Methoden abstrakter Datentypen (Algorithmen können so formuliert werden, dass sie nur auf Datentypen und ihre Methoden zurückgreifen). Erfahrung Es sind in der Regel konkurrierende Verfahren, konkurrierende Implementierungen, konkurrierende Datentypen möglich.

18 Modul Fasst man die Operationen zur Lösung einer Aufgabe unter einer Schnittstelle zusammen, so erhält man ein Modul. Beschreibung Funktion Interface Validierung Typen Funktionsmodul Eingabedaten - aus Eingabe folgt eindeutige Ausgabe in Form neuer Daten Abstrakter Datentyp-Modul Eingabe Methode - aus Eingabe folgt Zustandsveränderung. Realisierung Unterprogramm Prozedur Hierarchische Strukturierung des Kontrollflusses Hierarchische funktionale Zerlegung durch schrittweise Verfeinerung (HIPO) Modularisierungskonzepte betreffen sowohl den Entwurf, die Spezifikation als auch die Programmierung.

19 Beispiel Modul zur Beschreibung des Wärmetransportes in einem Rohr
Prinzip: Input - Prozess - Output Durchführung: Erweiterung zu Hierarchischem Input - Prozess - Output HIPO

20 Integration von Modulen im System
Schritt 1: Verbinden der Schnittstellen (Semantik) Regelung T,M T Nutzer 1 Wärme- Übergabe Raum 1 Wärme- Erzeuger Wärme- Verteiler Nutzer 2 Wärme- Übergabe Raum 2 Schritt 2: Steuerung des Ablaufes Schritt 3: Verfeinerung einzelner Teilaufgaben Wärme- Übergabe Raum 3 Nutzer 3

21 Beispiel Auswertungsmodellierung Verbindung von ADT- und Funktions- Modulen

22 Was unterscheidet Module von Komponenten
Mit Funktionsmodulen kann man das Verhalten technischer Komponenten nachbilden. Dies gelingt bisher nur ungenügend, da Module an folgenden Einschränkungen leiden: Trennung von Daten und Methoden prozedurales Abarbeiten von Operationen als grundlegendes Modellierungsmodell Keine inhärente Rekursivität kein Vererben keine Polymorphie Keine Berücksichtigung von Semantik oder Ontologie (es werden auch falsche Eingaben verarbeitet) Konsequenzen Ansatz mächtig, aber in seiner Reichweite beschränkt geringe Wiederverwendbarkeit geringe Erweiterbarkeit Master-Slave Beziehung statt Koordination, Kooperation, Kommunikation Erweiterung führt zu Objektorientierung, zu komponentenbasierten Systemen und zu aktiven Objekten oder Agenten

23 SE-Methoden zur Reduktion der Komplexität
Zerlegung Zeitliche Zerlegung - Software-Lebenszyklus Funktionale Zerlegung - Modularisierung Strukturierung Strukturierung der Beschreibung - Datenabstraktion, strukturierte Analyse Strukturierter Entwurf Strukturierte Programmierung Basisprinzipien zur Kapselung Abstraktionsprinzip Beschreibung Geheimnisprinzip Implementierung Schichtenkonzept Teilsysteme Trennung von Beschreibung und Verarbeitung Produktmodell bestehend aus Produktdatenmodell und Verhaltensmodell

24 Zeitliche Zerlegung Software-Lebenszyklus
1. Problemanalyse - Pflichtenheft 2. Programmentwurf - Spezifikation 3. Programmierung - Programm 4. Testprogramm - Testbericht 5. Abnahme - Abnahmebericht 6. Verifikation 7. Wartung

25 Kritik am Modell Lebenszyklus
Erfahrung Die Behebung von Fehlern ist umso schwieriger, je früher sie im Lebenszyklus-Modell entstanden ist. Kritik am Lebenszyklusmodell Zu starrer Ablauf, zu wenig Wechselwirkung zwischen Phasen, zu unflexibel bei Fehlern, Änderungen. Kaum Möglichkeiten für Überspringen von Phasen, Überarbeitung früherer Phasen, inkrementelle Erweiterung.

26 Beispiel für strukturierte Analyse: die YOURDON-Methode
Daten-Flussdiagramm

27 Elemente der Yourdon-Methode
Im Rahmen der Yourdon-Methode werden Systeme durch Angabe von Datenströmen und den darauf wirkenden Prozessen beschrieben. Datenflussdiagramme (DFD) zeigen die Verbindung von Prozessen durch Daten als ein Netzwerk von Aktivitäten, das durch einen Informationsfluss verbunden ist. Datenflussdiagramme sind hierarchisch angeordnet. Die Wurzel der DFD-Hierarchie, das Kontextdiagramm, zeigt die Schnittstelle eines Systems mit der Außenwelt. Zur Beschreibung der Datenströme wird ein Data Dictionary angelegt. Im Data Dictionary können Einzeldaten (Attribute) und Datenklassen (Entities) beschrieben werden. Die Beziehungen zwischen den Objekten des Data Dictionary sind in einem erweiterten Entity-Relationship-Diagramm festgehalten. Zur Beschreibung der Prozesse wird ein Process Dictionary angelegt. Die physikalische Struktur eines Prozesses wird mit Hilfe von Strukturdiagrammen (Structure Chart) beschrieben. Ein Strukturdiagramm zeigt die hierarchische Anordnung von Modulen, den Kontrollfluss und den Datentausch. Module lassen sich als die Gruppe von Instruktionen auffassen, die nötig sind, eine bestimmte Aufgabe auszuführen. Es wird angenommen, dass immer nur ein Modul aktiv sein kann. Zur Dokumentation von Modulen dienen die Prozess-Spezifikationen. Sie können in Pseudo-Code oder im Quell-Code erfolgen. Ältere Case-Werkzeuge unterstützen den Software-Entwurf nach der Yourdon-Methode.

28 Kritik am datenorientierten Ansatz
Sicht Datenfluss berücksichtigt zu wenig Kontrollfluss Beschreibung von Beziehungen Koordination mit Modellierung Module hauptsächlich Prozeduren auf Daten Keine interagierenden Prozesse Keine Mehrfachbenutzung (Kopieren durch Transformatoren ist verboten)

29 Funktionale Zerlegung - Modularisierung
Wie finden wir Module ? Sprachliche modulare Einheiten Module müssen zu syntaktischen Einheiten der Sprache passen. Minimum an Schnittstellen Module sollten möglichst wenig untereinander kommunizieren. Schwache Kopplung Bei der Kommunikation sollte so wenig Information wie möglich ausgetauscht werden. Was charakterisiert Module ? Explizit erkennbare Schnittstelle Geheimnisprinzip (Information Hiding) Abgeschlossenheit Handhabbarkeit Isolierte Prüfbarkeit Integrierbarkeit Planbarkeit Lokalität der Entwurfsentscheidung

30 Kritik am funktionalen Ansatz
Ausgangsdaten Operation 1 : Operation n Ergebnisdaten Zu starke Ausrichtung auf von Neumann-Maschine Zu wenig Berücksichtigung der Datenaspekte Zu wenig Berücksichtigung von Vernetzungen und Parallelität Modul: Input - Prozess - Output nur für einfache Datenstrukturen übersichtlich Strukturelement Funktionsmodul ist zu ergänzen durch ADT-Modul

31 RSYST Entwicklungssystem zur Modellierung komplexer Systeme
Reduktion der Komplexität a) Zerlegung - Modularisierung - Software Life Cycle b) Abstraktion - Abstrakte Datentypen - Schnittstellen Zerlegung: Funktionales Entwicklungsparadigma Ÿ Welche Aufgaben sollen auf einer Datenstruktur durchgeführt werden ? Problem: Menge von Operationen (Module) Ÿ Top-Down-Zerlegung Ÿ Struktursystem analog Struktur der Funktionen Abstraktionsprozess: Integration der Datenmodellierung mit Hilfe Abstrakter Datentypen (ADT) Ÿ ADT’s = Struktur + Funktionen Ÿ Zugriff über ADT-Modelle mit bekannten Schnittstellen Ÿ Information-Hiding

32 Allgemeine Architektur von RSYST
Functional Modules (Tools)

33 Modul in RSYST MONITOR ... RSYST Data Base ê DATA (Control Programm)
Functional Modules ADT- Tools, Applications Abstract Data Types ê DATA

34 Systeme in RSYST Struktur komplexer Systeme auf der Basis von RSYST
Anwender-Ebene

35 CAE-Integration in der Fahrzeugentwicklung
Simultaneous Engineering erfordert eine strategische Entwicklungsplanung und ein unternehmerisch orientiertes Projektmanagement. Dann können die einzelnen Entwicklungsphasen zeitparallel angegangen werden, d.h. dass bereits in der Definitionsphase eines neuen Fahrzeugs Teams gebildet wer-den, in denen neben den Konstrukteuren auch Berechnungs- und Versuchs-ingenieure, Fertigungsplaner, Werkstoffspezialisten usw. hinzugezogen wer-den. Dieses Zusammenarbeiten erfordert ein hohes Maß an Vertrauen und Zuverlässigkeit. Den CAE-Anwendern fällt dabei die ganz wichtige Aufgabe zu, konzeptionelle Ideen eines Lastenheftes für ein neues Fahrzeug frühestmöglich und umfas-send im Rechner auszutesten und mögliche Schwachstellen bzw. Zielkonflikte zu bewerten. Nach Schelkle bietet sich dabei eine CAx-Prozesskette an, die die Schritte Design (CAD), Styling (CAS), Engineering (CAE), Manufacturing (CAM), Qualitätskontrolle (CAQ) und Test (CAT) umfasst.

36 Einsatz der Datenmodelle in CAE

37 Mechanical Computer Aided Engineering (MCAE)
als Beispiel für die Integration von Entwurf, Konstruktion und Berechnung Ablauf einer Entwicklung nach MCAE-Stufe II MCAE verbunden mit dem Simultaneous Engineering-Konzept erlaubt es, Entwicklungszeiten zu verkürzen, Kosten zu sparen und optimale Lösungen zu finden (Vorlesung Schelkle).

38 LOTUS Notes zum Management von Dokumenten
sind Datensätze variabler Länge, die aus Feldern des Typs Text, Zahl, Zeit oder Rich-Text aufgebaut sind (unstrukturierte Daten). werden über Formulare (Master) erstellt und in Reports (Ansichten) zusammengefasst. Dokumente, Masken, Reports und Ablaufsteuerungen werden gemeinsam in einer Datenbank (Daten-System) gespeichert und verwaltet. Sie werden über elektronische Post getauscht und über Replikation innerhalb einer Arbeitsgruppe abgeglichen. Damit sind innerhalb der Gruppe Daten und die darauf wirkenden Methoden immer auf demselben Stand. Elemente von Notes Server mit Dateisystemen Klienten mit nutzerspezifischen Notes-Programmen Netzwerk zur Verbindung Dienst elektronische Post Dienst Replikation Dienst Sicherheit (Zugriffsschutz und Rollen)

39 Diese Fragen sollten Sie neu beantworten können
Was ist eine virtuelle Anlage und wozu können wir sie einsetzen Was ist ein Modul und welche Typen unterscheiden wir Warum trennen wir Beschreibung und Verhalten und wie hängen beide zusammen, wenn wir Verhalten simulieren Wie unterscheidet sich der modulare Ansatz vom Ansatz der „technischen Objekte“ Warum sind auch im Softwareengineering die 3S und die 3K unverzichtbar 3K modernen Ingenieurwesens Kooperation Koordination Kommunikation 3S hoher Produktivität Simplifizierung Spezialisierung Standardisierung

40 Simulation komplexer technischer Anlagen
Literatur: Parnas, D.L.: On the Criteria to be Used in Decomposing Systems into Mdules. Communications of the ACM, Vol. 5, No. 12, , 1972. De Marco, T.: Structured Analysis and System Specification. New York: YOURDON Inc., 1978/1979. Raasch, J.: Systementwicklung mit strukturierten Methoden. München/Wien: Hanser, 2. Auflage,1992. Ward, P.T.; Mellor, S.J.: Strukturierte Systemanalyse von Echtzeit-Systemen. München/Wien: Hanser; London: Prentice-Hall, 1991. Wirth, H.: Program Development by Stepwise Refinement. Communications of the ACM, Vol. 14, No. 4, , 1971. Yourdon, E.; Constantine, L.L.: Structured Design. New Yor: Yourdon Press, 1975, 1979. Yourdon, E.: Modern Structured Analysis. Englewood Cliffs, Prentice-Hall, 1989. Wedeking, H.: Objektorientierte Schema-Entwicklung - Ein kategorialer Ansatz für Datenbanken und Programmierung. Mannheim: B.I. Reihe Informatik, Bd. 85, 1992.