Universität Stuttgart Wissensverarbeitung und Numerik Institut für Kernenergeti und Energiesystem Simulation technischer Systeme, WS 01/02 Kap. 2: Virtuelle Anlagen 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
40
Embed
Universität Stuttgart Wissensverarbeitung und Numerik I nstitut für K ernenergetik und E nergiesysteme Simulation technischer Systeme, WS 01/02Kap. 2:
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Simulation komplexer technischer AnlagenWas wir bisher gelernt haben
Ziel der VorlesungKennen lernen von Methoden zum Bau virtueller AnlagenVorlesung 1: Modelle als Basis realer und virtueller AnlagenVorlesung 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
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.
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.
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.
Beispiel Modul zur Beschreibung des Wärmetransportes in einem Rohr
IN P U T
O U T P U T
Te i n
Te m b
Te x
m
.
m
.Q.
PA R A M E T E R
L , D , , c
h o r iso n ta le o d e r
v e rtik a le R o h re
p
T Y P E 7 0
R o h rle itu n g
T Y P E -IN P U T S :T ein E in tri t ts te m p e ra tu r d e s H e iz w a ss e rm a ss e n flu s se i [G ra d C e ls iu s ]m H e iz w a ss e rm a s se n flu ß [k g /s ]T am b U m g e b u n g s te m p e ra tu r [G ra d C e ls iu s]
T Y P E -P A R A M E T E R .L R o h rlä n g e l [m ]D R o h rd u rc h m e ss e r [m ] E m is s io n s z a h l fü r d ie ä u ß e re R o h ro b e r flä c h e [ .]c p s p e z if isc h e W ä rm e k a p a z ite t d e s F lu id s [ J /k g K ]
> o d e r = 0 v e rtik a le s o d e r h o riz o n ta le s R o h r [ .]T Y P E -O U T P U T S :
T ex A u s trit ts te m p e ra tu r d e s H e iz w a s se rm a ss e n f lu ss e s [G ra d C e ls iu s ]m H e iz w a ss e rm a s se n flu ß [k g /s ]
Q a b g e g e b e n e W ä rm e s tro m [W ]
Durchführung:
Prinzip: Input - Prozess - Output
Erweiterung zu Hierarchischem Input - Prozess - Output HIPO
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
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.
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
• 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
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.
sind Datensätze variabler Länge, die aus Feldern des Typs Text, Zahl, Zeit oder Rich-Text aufgebaut sind (unstrukturierte Daten).
Dokumente 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.
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.