Universität Stuttgart Wissensverarbeitung und Numerik I nstitut für K ernenergetik und E...

Universität Stuttgart W

isse

nsv

erar

be

itu

ng

un

d N

um

erik

Institut für Kernenergetikund Energiesysteme

Simulation technischer Systeme, WS 01/02 Kap. 2: Virtuelle Anlagen

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

Wiederverwendung bewährter Komponenten

Qualitätssicherung mit den Elementen

Prozessüberwachung

Produktüberprüfung

Projektmanagement


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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


isse

nsv

erar

be

itu

ng

un

d N

um

erik




Nutzung (analog detaillierter Modelle)

Einhaltung von äußeren Vorgaben, z.B. Sicherheitsanforderungen

Überprüfung innerer Konsistenzz.B. Verbindung von Teilsystemen

Datenkonsistenz zwischen einzelnen Abteilungenz.B. Komponentenauslegung, Verfahrenstechnik, Leittechnik

Einbringung von Änderungen

Vereinheitlichung der Dokumentation

Bindeglied zwischen Theorie und Realität

ErstellungAnalog Planung, Bau und Betrieb realer Anlagen


isse

nsv

erar

be

itu

ng

un

d N

um

erik




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


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Beispiel Gebäudemodellierung


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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)


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Lösung von Problemen

Methoden zurBeschreibung

Datenstruktur Algorithmen

Problem

ModellReduktion

Modulares System

AbstrakteDatentyp-Module

Methoden zur Lösung (Beschreibung des Verhaltens)

Simulationsprogramm

Reduktion Komplexität

Komplexität

Funktions-Module


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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 DatentypDatenstruktur + darauf definierten Operationen


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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.


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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.


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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.


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Beispiele für abstrakte Datentypen

GrundtypenInteger, Real, Character, etc.

ADT's aus der DatenverarbeitungTupel - 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 NumerikVektor - 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)


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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.


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Algorithmen -1

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


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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.


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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 DatenAbstrakter 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.


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Integration von Modulen im System

Schritt 1: Verbinden der Schnittstellen (Semantik)

Regelung

Wärme-Erzeuger

Wärme-Verteiler

Wärme-ÜbergabeRaum 3



Nutzer 1

Nutzer 2

Nutzer 3

T,M T

Schritt 2: Steuerung des Ablaufes

Schritt 3: Verfeinerung einzelner Teilaufgaben


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Beispiel Auswertungsmodellierung Verbindung von ADT- und Funktions- Modulen


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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


isse

nsv

erar

be

itu

ng

un

d N

um

erik



SE-Methoden zur Reduktion der Komplexität

ZerlegungZeitliche Zerlegung - Software-Lebenszyklus

Funktionale Zerlegung - Modularisierung

StrukturierungStrukturierung der Beschreibung - Datenabstraktion, strukturierte Analyse

Strukturierter Entwurf

Strukturierte Programmierung

Basisprinzipien zur Kapselung

Abstraktionsprinzip Beschreibung

Geheimnisprinzip Implementierung

Schichtenkonzept Teilsysteme

Trennung von Beschreibung und VerarbeitungProduktmodell bestehend aus Produktdatenmodell und Verhaltensmodell


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Zeitliche Zerlegung Software-Lebenszyklus

1. Problemanalyse - Pflichtenheft

2. Programmentwurf - Spezifikation

3. Programmierung - Programm

4. Testprogramm - Testbericht

5. Abnahme - Abnahmebericht

6. Verifikation

7. Wartung


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Kritik am Modell Lebenszyklus

ErfahrungDie Behebung von Fehlern ist umso schwieriger, je früher sie im Lebenszyklus-Modell entstanden ist.

Kritik am LebenszyklusmodellZu 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.


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Beispiel für strukturierte Analyse: die YOURDON-Methode

Daten-Flussdiagramm


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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.


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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)


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Kritik am funktionalen Ansatz

Operation 1

Operation n

:

Ausgangsdaten

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


isse

nsv

erar

be

itu

ng

un

d N

um

erik



RSYSTEntwicklungssystem 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


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Allgemeine Architektur von RSYST

FunctionalModules(Tools)


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Modul in RSYST

MONITOR(Control Programm)

RSYST Data Base

......FunctionalModules

.........ADT-Modules

Tools, Applications

AbstractDataTypes

DATA


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Systeme in RSYST

Struktur komplexer Systeme auf der Basis von RSYSTAnwender-Ebene


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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.


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Einsatz der Datenmodelle in CAE


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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).


isse

nsv

erar

be

itu

ng

un

d N

um

erik



LOTUS Notes zum Management von Dokumenten

Dokumente

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.

Elemente von NotesServer mit Dateisystemen

Klienten mit nutzerspezifischen Notes-Programmen

Netzwerk zur Verbindung

Dienst elektronische Post

Dienst Replikation

Dienst Sicherheit (Zugriffsschutz und Rollen)


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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


isse

nsv

erar

be

itu

ng

un

d N

um

erik



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, 1053-1058, 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, 221-227, 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.

Universität Stuttgart Wissensverarbeitung und Numerik I nstitut für K ernenergetik und E...

Documents

Transcript of Universität Stuttgart Wissensverarbeitung und Numerik I nstitut für K ernenergetik und E...