Universität Stuttgart Wissensverarbeitung und Numerik I nstitut für K ernenergetik und E nergiesysteme Simulation technischer Systeme, WS 01/02Kap. 5:

5/1

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. 5: Entwurf

Simulation komplexer technischer Anlagen

Teil II: Elemente zum Bau virtueller Anlagenkomponenten

Kapitel 5:Wiederverwendung bei Entwurf und Programmierung

Inhalt

Von der Analyse zum Entwurf

Objektorientierter Entwurf mit Hilfe von Entwurfsmustern

Frameworks

Antipattern

Elemente der objektorientierten Programmierung - Kurse beachten

5/2


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Das sollten Sie heute lernen

Schichtenkonzept der Wiederverwendbarkeit Entwurfs als Modellierungsschritt

Entwurfsentscheidungen

Entwurfsziele

Entwurfsmuster Antipattern Framework OO Programmiersprachen

5/3


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Ergebnisse der Analyse

Analyse bedeutet die Abstraktion eines Problembereichs zu einer isolierten, definierten, allgemeingültigen Beschreibung und zu Anforderungen.

Ergebnis der Analyse ist eine Beschreibung eines realen Systems durch: Objekte Beziehungen der Objekte untereinander Eigenschaften und Verhalten der Objekte

und durch Angabe der gewünschten Funktionalität des geplanten SW-Systems etwa über Use Cases oder Anwendungsfälle.

Um die Funktionalitäten umzusetzen sind eine Vielzahl weiterer Schritte nötig

5/4


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Objekt & Klasse

Systeme

Anwendungen

Frameworks: Implementierung

MikroArchitektur: Entwurfsmuster

Kapselung von Daten und Methoden

Horizontale & Vertikale Frameworks Metadaten

Kapselung von Altlasten GUIs

Klassenhierarchien

Zusammenarbeit einzelner Klassen

Vom Objekt zum System - Aggregationsstufen

heute

Entwürfe sollten auf allen Stufen stattfinden - Top Down Ansatz

5/5


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Von der Analyse zum Entwurf: Mikro-Architektur

Die in der Analyse gefundenen Objekte sind eine Grundlage des

Entwurfs. Weitere, wichtige Grundlagen sind persönliche Erfahrungen und Entwurfsmuster

Der Schwerpunkt der Micro-Architektur liegt in „kleinen Entwürfen“, welche ein begrenztes Problem innerhalb einer Anwendung lösen.Solche kleinen Entwürfe können auch das Ergebnis eines Zwischenschrittes der Top Down Analyse sein

Die Anzahl betroffener Objekte ist relativ gering. Entwurfsmuster kombinieren mehrere Objekte so, dass die

Anwendung an künftige Änderungen leicht angepasst werden kann.

5/6


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Ziele des Entwurfs (1)

Entwurf ist Abstraktion des Lösungsbereichs im Hinblick auf Implementierung

Entwicklung einer Software-Architektur

Spezifikation eines Software-Systems, das bestimmte Anforderungen erfüllen muß:

Funktion/Korrektheit Erweiterbarkeit/Wartbarkeit/Lesbarkeit Wiederverwendbarkeit Portabilität, Effizienz

5/7


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Ziele des Entwurfs (2)

Die zentralen Fragen lauten nun: Wie können diese Ziele erreicht werden ? Gibt es ein optimales Verfahren, Software zu entwerfen ? Wie sieht der Lösungsraum aus: Daten(-typen), Funktionen, Dateien,

Programme ...

Merke: Softwaresystem ist ebenfalls (wie Realität) komplex und muß

geeignet strukturiert werden Architektur

Ergebnis: Spezifikation als formale Beschreibung der zu implementierenden

Software

5/8


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Die Schwierigkeit des Entwurfs

Das Entwickeln einer Software-Architektur ist ein gestalterischer Prozeß.

Ein Standardverfahren, das zum richtigen Entwurf führt, gibt es nicht.

Auch einen richtigen oder falschen Entwurf gibt es nicht. Es gibt nur, an den Erfordernissen gemessen, gute oder schlechte Entwürfe,

Entwürfe sind Modelle virtueller Systeme.

Entwerfen bedeutet immer ein Abwägen mehrerer, konkurrierender Alternativen und ein möglichst gutes Erfüllen der sich widersprechenden Entwurfsziele. Dabei sind pragmatisches Vorgehen und Nutzung von Erfahrungen gefragt. Iterative Verbesserung muß möglich sein.

5/9


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Schwierige Entwurfstätigkeiten

Finden passender SW-Objekte die während der Analyse-Phase gefundenen Objekte reichen oft

nicht

Festlegen der Objektgranularitäten komplexe Objekte dürfen nicht beliebig groß werden

Festlegen der Objekt/Methodenschnittstellen mit den richtigen Schnittstellen steht und fällt ein Entwurf

Festlegen der Objektimplementierung der richtige Einsatz von Vererbung kann den Aufwand vermindern

Wiederverwendungsmechanismen aktiv und passiv nutzen / vorsehen Vererbung ist bei weitem nicht die einzigste Möglichkeit

5/10


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Beispiele für Entwurfsentscheidungen

Implementierung der Part-Of-Relation? als Objekt, Zeiger, Liste, Array, ...

Virtuelle Methoden oder parametrisierten Typen? Flexibilität zur Laufzeit oder nur zur Compilezeit weniger oder mehr Effizienz bei der Ausführung des Programms

Vererbung oder Delegation? vermeiden von Mehrfachvererbung auf Kosten eines komplexeren

Entwurfs

Behandlung von mehrdimensionalen Klassifizierungshierarchien? durch Mehrfachvererbung oder mit parametrisierten Typen?

Erfahrung und Problemkenntnisse nötig

5/11


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Prinzipien der objektorientierten Softwareentwicklung

Die Erfahrungen, die Mitarbeiter der Abteilung Wissensverarbeitung und Numerik am IKE mit der objektorientierten Softwarentwicklung machten, wurden in zwei papieren zusammengestellt. Sie werden laufend ergänzt und stehen allen Studierenden in aktueller Form im Netz unter

http://www-is.ike.uni-stuttgart.de/intra/q-management/

richtlinien/entwicklung/oo richtlinien-v10-pdf

zur Verfügung.

5/12


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Entwurfsmethoden

Analog zu den vorgestellten Analyse-Methoden gibt es entsprechende Entwurfsmethoden, z.B. nach Booch, Coad/Yourdon, Rumbaugh und dazu Unterstützung durch UML und Case Tools

Viel wichtiger jedoch sind prinzipielle Erkenntnisse: wie läßt sich die Wartbarkeit von Code verbessern? wie läßt sich die Wiederverwendbarkeit von Code erhöhen? wie kann möglichst portabler Code geschrieben werden? wie kann ein Entwurf übersichtlich gehalten werden?

Außerdem müssen die Möglichkeiten der Programmiersprachen beim Entwurf berücksichtigt werden.

Eigene und fremde Erfahrungen lassen sich in Entwurfsmustern weitervermitteln und weiterverwenden

5/13


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Wartbarkeit

Wartung heißt meistens erweitern und anpassen alles, was sich in einem Programm ändern könnte, in abstrakten Klassen kapseln, um flexibel zu sein. Die Merkregel hier lautet:

Programmieren mit Schnittstellen, nicht mit Implementierungen

Beispiel: Abstrakter Datentypmodul

Beispiel: Iteratoren eine Schnittstelle zum Durchlaufen von Datenstrukturen wie Listen,

Bäume, Arrays, ... Vorteil: Datenstrukturen können (in Grenzen) ohne den die Datenstruktur

benutzenden Code ausgetauscht werden

5/14


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Wiederverwendbarkeit, Portabilität und Übersichtlichkeit

Wiederverwendbarkeit: Wiederverwendung heißt den gleichen Code in einer anderen

Umgebung für die selbe Funktion einzusetzen. Beim Entwurf andere Einsatzgebiete erkennen und bedenken.

Portabilität: Portieren von Software bedeutet das Übertragen eines Programmes

in eine andere Betriebssystemumgebung Kapseln aller betriebssystemkritischen API´s und Vorgehensweisen Möglichst keine Abweichungen von Standards

Übersichtlichkeit Sinnvolle Namen verwenden An bekannten Konzepten orientieren (Entwurfsmuster)

5/15


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Begriffsbestimmung: Was sind Entwurfsmuster

Zitat:"Ein Entwurfsmuster beschreibt ein Problem, das immer wieder in unserer Umwelt vorkommt, und beschreibt dann den Kern einer Lösung des Problems, so daß die Lösung millionenfach für Probleme dieses Typs verwendet werden kann, ohne zweimal genau dasselbe zu tun." (frei nach C.Alexander, Gamma et.at. S. 2).

Entwurfsmuster sind abstrakte Anweisungen, wie Software implementiert werden kann, damit bestimmte Eigenschaften eines Entwurfs erreicht werden, z.B. Änderbarkeit, Wartbarkeit, Wiederverwendbarkeit....

Entwurfsmuster sind programmiersprachenunabhängig

5/16


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Entwurfsmuster und persönliche Erfahrung

Entwurfsmuster: eine Zwischenlösung zwischen Frameworks und persönlicher Erfahrung

Persönliche Erfahrung: Schwierigster Weg:

nicht dokumentiert, daher schlecht nachvollziehbar von Person zu Person unterschiedlich

Wichtigster Weg: Software-Entwurf ist keine mechanische Tätigkeit, sondern ein

kreatives Abwägen von Alternativen, daß auf den Menschen angewiesen ist und sich (noch?) nicht automatisieren läßt.

5/17


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Was sind Entwurfsmuster nicht

Rezepte Rezepte können blind angewandt werden. Entwurfsmuster müssen zu

ihrer Anwendung verstanden werden, da sie wegen der breiten Anwendbarkeit sehr abstrakt sind.

Entwurfs-Regeln Entwurfsmuster sind keine starren Vorgaben, sondern flexible, anpaßbare

Vorschläge

Frameworks Frameworks sind komplette Speziallösungen

Idiome Idiome (Programmierstile) sind sprachspezifische Konstrukte

5/18


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Bestandteile eines Entwurfsmusters

Mustername kurze, prägnante Umschreibung der mit dem Muster realisierten

Funktionalität

Problembeschreibung Beschreibung dessen, was erreicht werden soll

Problemlösung Beschreibung, wie das gewünschte Ziel erreicht wird

Konsequenzen der Anwendung Beschreibung der Auswirkungen der Anwendung des Musters auf

andere Zielgrößen des Entwurfs, z.B. Effizienz, Speicherbedarf, Erweiterbarkeit, etc.

Diskussion von Alternativen

5/19


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Anwendung von Entwurfmustern

Anhand der Beschreibungen der Entwurfsmuster (Konsequenzen!) ein passendes auswählen

Übertragen des Entwurfsmusters in den konkreten Anwendungsfall

Informationen zum Thema Entwurfsmuster: E. Gamma et.al.: Design Patterns, Addison Wesley, 1994 J. Coplien, D. Schmidt: Pattern Languages of Program Design, Addison

Wesley, 1994 Konferenzen, z.B. PLoP, C++World, etc. WWW: Patterns Home Page

(http://st-www.cs.uiuc.edu/users/patterns/patterns.html)

5/20


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Vor- und Nachteile von Entwurfsmustern

Vorteile: einheitliche Kommunikationsbasis Dokumentationswerkzeug explizite Erweiterungspunkte eines Systems konstruieren geringere Gefahr der unbeabsichtigten Zerstörung eines Entwurfs in der

Wartung

Nachteile: manchmal zu kompliziert noch keine umfassenden, praktikablen Kataloge nur für eine bestimmte Ebene des Entwurfs sinnvoll

5/21


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Beispiel 1: Abstrakte Simulation

Name OODS - object oriented distributed simulation

Zweck: Definition der Grundstruktur von Objekten zur verteilten Simulation

Ziele: Generelle Beschreibung von Bausteinen in Simulationssysteme Kapselung von Funktionalität

Konsequenzen: Hohe Komplexität durch rekursive Vererbung Semantik der Daten muß in Schnittstelle verlagert werden Semantik der Anwendung nicht transparent

5/22


isse

nsv

erar

be

itu

ng

un

d N

um

erik



OODS_SimulationModel

OODS_Object

NameTypeDescription

CloneModel(...)SimulateModelState(...)

OODS_Parameter OODS_Port

SimulateModelState(...)GetModelState(...)

1

1

* *

1..*

*

1..*

*

1

*

* *

*

*

*

1

OODS_State

TimeValues

OODS_Value

Add(...)Subtract(...)...

Struktur des Entwurfsmusters Abstrakte Simulation

OODS Objekt enthält OODS S.M., Port, State und Para.

OODS S.M. verwendet

5/23


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Objekt & Klasse

Systeme

Anwendungen

Frameworks: Implementierung

MikroArchitektur: Entwurfsmuster

Kapselung von Daten und Methoden

Horizontale & Vertikale Frameworks Metadaten

Kapselung von Altlasten GUIs

Klassenhierarchien

Zusammenarbeit einzelner Klassen

Vom Objekt zum System - Aggregationsstufen

heute

Entwürfe sollten auf allen Stufen stattfinden - Top Down Ansatz

5/24


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Entwurf und Entwurfsmuster

Aufgabe des Entwurfs ist - aufbauend auf dem Ergebnis der Analyse - die Erstellung der Softwarearchitektur und die Spezifikation der Komponenten, d.h. die Festlegung von deren Schnittstellen, Funktions- und Leistungsumfang. Das Ergebnis soll die zu realisierenden Programme auf einem höheren Abstraktionsniveau widerspiegeln.

Ein Entwurfsmuster gibt eine bewährte, generische Lösung für ein immer wiederkehrendes Entwurfsproblem an, das in bestimmten Situationen auftritt. Es lassen sich klassen- und objektbasierte Muster unterscheiden. Klassenbasierte Muster werden durch Vererbungen ausgedrückt. Objektbasierte Muster beschreiben in erster Linie Beziehungen zwischen Objekten.

Entwurfsmuster beschreiben in abstrakter Form eine bewährte Entwurfslösung und setzen sie in Bezug zur Problemstellung und zur Systemumgebung.

5/25


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Architektur von Softwaresystemen

Architektur meint die logische und die physische Struktur eines Softwaresystems

Die Architektur beschreibt die wesentlichen strukturellen Elemente, deren Schnittstellen und Zusammenarbeit

Eine Architektur ist eine Menge von Architektur Mustern mit einer Menge von Architektur Operationen,die die Instanzierung von Architektur Exemplaren aus Architektur Mustern ermöglichen.

Damit beschreibt die Architektur Struktur und Verhalten eines Systems. Die Wahl der Architektur hat unter Gesichtspunkten wie Nutzung, Funktionalität, Performance, Robustheit, Wiederverwendbarkeit oder Verständlichkeit zu erfolgen. Wirtschaftliche und technische Randbedingungen sind einzuhalten. All dies bedeutet, dass ständig Kompromisse nötig sind und bewährte Lösungen mit bedacht werden sollten.

5/26


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Beispiel 2: Das Strategy-Pattern

Zweck:

Definition einer Familie von austauschbaren Algorithmen.

Ziele: Kapselung von Algorithmen und ihren Daten flexibles Ändern des Verhaltens eines Objekts vermeiden von Fallunterscheidungen im Code

Konsequenzen: Wiederverwendung ohne Vererbung. Das Strategy-Pattern ist ein

Beispiel für Delegation. Es entsteht ein gewisser Kommunikationsoverhead

(Funktionsaufrufe) Der Entwurf wird wegen der erhöhten Anzahl von Objekten

komplexer

5/27


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Das Strategie-Entwurfsmuster Strategy Pattern

KonkreteStrategieB

+ AlgorithmusSchnittstelle()

KonkreteStrategieC


KonkreteStrategieA


Kontext

+ KontextSchnittstelle()

Strategie

+ AlgorithmusSchnittstelle()11

+strategie

1 1

Class A ClassB

Class A ClassB

Class A ClassB

*11 *

Class A ClassB

*11 *

Vererbung

Abhängigkeit

Assoziation

Aggregation

5/28


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Beispiel: Integrationsalgorithmen in Simulationsprogrammen

Simulationsmodelle (z.B. für eine Wand) bestehen aus Differentialgleichungen.

Zur Lösung dieser Differentialgleichungen (z.B. in der Methode “BerechneTemperatur“) gibt es viele verschiedene Verfahren, die problemabhängig vom Anwender ausgewählt werden müssen.

Gesucht: Entwurf/Implementierung, der eine flexible Auswahl und eine einfache Erweiterbarkeit der Palette ermöglicht.

5/29


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Konkrete Anwendung: Zeitintegration

1 1 Integrator

_ZeitSchrittWeite

IntegriereZeitschritt

RungeKuttaIntegrator


EulerIntegrator


Wand

_Temperatur_Integrator_Material

BerechneTemperaturSetzeIntegrator

Vererbung

Aggregation

5/30


isse

nsv

erar

be

itu

ng

un

d N

um

erik



class Wand{public: void BerechneTemperatur (); void SetzeIntegrator ();private: Temperatur _Temperatur; Parameter _Material; Integrator* _Integrator;};

void Wand:: SetzeIntegrator (Integrator * integ) { _Integrator = integ; }

void Wand:: BerechneTemperatur (float waerme_strom, float delta_t) { // Berechnen der Wandtemperatur nach einem Zeitschritt aus // // dT // -- = m * c * Q // dt float dT_dt = _Material * waerme_strom; _Integrator->IntegriereZeitschritt(_Temperatur, dT_dt, delta_t);}

Implementierung

5/31


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Makro-Architektur - Frameworks

Der Schwerpunkt liegt in der Wiederverwendung sowohl von Entwurf als auch von Software-Code mit dem Ziel, eine spezielle Lösung für ein domänenspezifisches Problem zu finden.

Kombination einer oder mehrerer Mikro-Architekturen.

Ebene für den Einsatz von Frameworks

5/32


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Frameworks

"Ein Framework ist eine Anzahl wiederverwendbarer Klassen mit einer Systemarchitektur zur Erstellung von Anwendungen. Es stellt

den Königsweg dar: ein kompletter und geprüfter Entwurf samt Implementierung von Basisfunktionalität kann wiederverwendet werden.

Ein Framework besteht also aus einer Menge von zusammen-arbeitenden Klassen, die einen wiederverwendbaren Entwurf für einen bestimmten Anwendungsbereich implementieren. Es besteht aus konkreten und insbesondere aus abstrakten Klassen, die Schnittstellen definieren. Die abstrakten Klassen enthalten sowohl abstrakte als auch konkrete Operationen. Im allgemeinen wird vom Anwender (=Programmierer) des Frameworks erwartet, daß er Unterklassen definiert, um das Framework zu verwenden und anzupassen.

5/33


isse

nsv

erar

be

itu

ng

un

d N

um

erik



ExtensionPoint

Pattern

Framework

*

1

*

*

1

*

Component

**

**

*

*

*

*11

Beziehung zwischen Komponenten, Pattern und Frameworks

Eine Komponente kann in mehreren Patterns und Frameworks implementiert werden und ein Pattern oder ein Framework kann durch mehrere Komponenten implementiert werden.

Ein Framework kann mehrere Pattern enthalten und bietet Extension Points an Erweiterungsstellen beschreiben, wo und wie das Framework zu erweitern ist, damit das

Framework im Kontext einer konkreten Anwendung eingesetzt werden kann.

Class A ClassB

*11 *

Assoziation

implementiert

implementiert

Besteht ausenthält

5/34


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Anwendung von Frameworks

Wiederverwendung als White-Box Frameworks, Wiederverwendung und Erweiterung durch

Vererbung Black-Box Frameworks, Wiederverwendung und Erweiterung durch

Aggregation

Informationen zum Thema Frameworks Buschmann et al.: Pattern-Oriented Software Architecture: A System of

patterns, Wiley, 1996. G. Rogers, : Framework-Based Software Development in C++, Prentice

Hall, 1997. Konferenzen, z.B. PLoP, C++World, etc. WWW: Patterns Home Page

(http://st-www.cs.uiuc.edu/users/patterns/patterns.html)

5/35


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Vorgehensweise bei der Framework-Entwicklung

Identifiziere die spezifische(n) Domäne(n), wo das Framework angewandt werden soll.

Definiere Use Cases (Anwendungsfälle), welche das Framework erbringen soll.

Identifiziere bekannte Akteure, welche mit dem Framework agieren sollen.

Identifiziere Patterns oder andere geprüfte Lösungen, welche die Framework-Entwicklung unterstützen sollen.

Entwerfe Schnittstellen und spezifiziere Komponenten des Frameworks.

Implementiere die Schnittstellen des Frameworks prototypisch. Beschreibe und dokumentiere Erweiterungsstellen. Schreibe Prüfspezifikationen und plane den Entwicklungsprozess.

5/36


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Was sind Anti-Patterns ?

Ein Anti-Pattern beschreibt einen Lösungsvorschlag für ein bestimmtes Problem, welcher für den Software-Entwurf oder den gesamten Entwicklungsprozeß negative Konsequenzen hat.

Ein Anti-Pattern tritt auf, wenn die am Software-Projekt Beteiligten keine bessere Lösung für das Problem kennen, nicht genügend Erfahrung in Lösung bestimmter Probleme haben oder ein erprobtes Lösungsmuster in einem falschen Kontext einsetzen.

Anti-Patterns gliedern sich in: Entwurf-Antipatterns (Software-Entwickler) Architektur-Antipatterns (Software-Architekt) Management-Antipatterns (Projektleiter)

5/37


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Bestandteile eines Anti-Patterns

Hintergrund Antipattern (Generelle Form) Symptome und Konsequenzen Ursache Ausnahmen Verbesserungsvorschlag Variationen Beispiel Verwandte Antipatterns

5/38


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Anwendung von Antipatterns

Anti-Patterns sind überall.

Anti-Pattterns verdeutlichen die Fehler in dem Entwicklungprozess.

Informationen zum Thema Anti-Patterns W. Brown et al.: Anti Patterns, Wiley, 1998 WWW: The Portland Pattern Repository(http://c2/com/ppr)

5/39


isse

nsv

erar

be

itu

ng

un

d N

um

erik



CASE - Computer Aided Software Engineering

Durch die Formalisierung wird es möglich eine Vielzahl von Aufgaben bei der Software Entwicklung zu automatisieren. Dadurch kann die Software Produktivität gesteigert und die Softwarequalität verbessert werden. CASE befasst sich mit computergestützten Hilfsmitteln zur Erreichung dieses Zieles.

Wir unterscheiden CASE oder Software Entwicklungsumgebungen, CASE Plattformen

und CASE Werkzeuge CASE Werkzeuge stellen zur Softwareproduktion benötigte

Funktionen oder Dienstleistungen zur Verfügung CASE Plattformen (frameworks) stellen Basisdienstleistungen zur

Verfügung, die von CASE Werkzeugen in Anspruch genommen werden können.

CASE Umgebung heisst die Summe aus Plattform und Werkzeugen

5/40


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Basisdienste einer CASE Plattform

Reposity Service verwaltet Objekte und ihre Beziehungen

Data Integration Service verwaltet und verarbeitet Metadaten (Daten über Daten)

vertikale + horizontale Tools

Process Management Service unterstützt die Verarbeitung von Workflows und das Rollenmanagement

Interface User Service trennt Bedienung und Funktionalität und erlaubt Anpassung der Bedienung an Nutzung

Me

ss

age

Se

rvice

unte

rstützt K

omm

un

ikatio

n(T

ool-Tool; S

ervice-Service; T

ool-Service)

5/41


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Definition OO-Programmiersprache

Objektbasiert Datenabstraktion Klassen Beispiele: Visual Basic

Objektorientiert objektbasiert Vererbung Polymorphismus Beispiele: C++, Java, Smalltalk, ...

5/42


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Problem: Welche Programmiersprache ist die richtige ?Auswahlkriterien sind wichtig !

Problem: Welche Programmiersprache ist die richtige ?Auswahlkriterien sind wichtig !

Überblick OO-Programmiersprachen

OO-Programmiersprachen gibt es sehr viele:

Simula 67, Smalltalk, Object Pascal, Modula 3, C++, Objective C, CLOS, Ada 95, Eiffel, Beta, Object COBOL, Java, Python, Dylan; Self, Oberon, Occam, Russel, Arjuna, CC++, ...

(ca. 45 im comp.object FAQ)

Falls Sie sich erst einarbeiten müssen, empfehlen wir das JAVA Tutorial von SUN:

http://java.sun.com/docs/books/tutorial/

5/43


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Auswahlkriterien anhand von Beispielen (1)

Ada 95 C++ Eiffel Smalltalk Java

Programm-Ausführung

compiliert compiliert compiliert interpretiert/Bytecode/compiliert

interpretiert/Bytecode/compiliert

Typisierung ja,

statisch

ja,

dynamisch

ja,

dynamisch

nein,dynamisch

ja,

dynamisch

Laufzeit-effizienz

(Performance)gut hoch gut schlecht

schlecht(wird nochverbessert)

Komplexität hoch sehr hoch erträglich erträglich erträglich

5/44


isse

nsv

erar

be

itu

ng

un

d N

um

erik





Variablen-Kapselung

pub/priv pub/prot/priv priv priv pub/prot/privpackage

Methoden-Kapselung

pub/priv pub/prot/priv pub/priv public pub/prot/priv

Nebenläufig-keit

ja indirekt nein indirekt ja

Persistenz nein nein nein nein nein

5/45


isse

nsv

erar

be

itu

ng

un

d N

um

erik





Normung Standard(DOD)

Standard(ANSI)

proprietär proprietär demnächstStandard (ANSI)

Verbreitung mäßig sehr hoch gering mittel stark wachsend

besondereVorteile

Normung nähe zu C durchdachtesKonzept

PrototypingGUI

Mobile CodeInternet

besondereNachteile

aufwendigeCompiler

nähe zu CKomplexität

geringeVerbreitung

Laufzeit-effizienz

dynamischeEntwicklung

Literatur zu C++:

Deitel/Deitel: The Complete C++ Training Course (Bk/CD-ROM) Student Edition. 0-13-082925-0. Jg.1998. Verlag prentice hall. Www.prenhall.co.u

Ford/Topp: An Introduction to Computing Using C++ and Object Technology. 0-13-268152-8. Jg. 1998.

Kruse/Ryba: Data Structure and Program Design in C++. 0-13-768996-0. Jg. 1998.

Johnsonbaugh/Kalin: Applications Programming in C++. 0-13-748963-3. Jg. 1998.

Collopy: Introduction to C++ Programming: A Modular Approach. 0-13-888801-9. Jg. 1998.

Ramteke: Introduction to C and C++ for Technical Students. 0-13-249608-9. Jg. 1998.

Kashani: Programming in C++: An Applied Approach. 0-13-228818-4. Jg. 1998.

5/46


isse

nsv

erar

be

itu

ng

un

d N

um

erik



FORTRAN als Programmiersprache der Numerik (1)

Geschichtliche Entwicklung1954 John Backus von IBM begann, ein automatisches Programmiersystem zu entwickeln, das

Programme, die in mathematischer Notation geschrieben wurden, in Maschinenbefehle für den IBM 704-Computer umwandelt. Daraus entstand

1957 der erste FORTRAN-Compiler.

1958 IBM führt FORTRAN ein;

erste Erweiterung: Subroutinen

Anfang 60er FORTRAN hat sich seit FORTRAN II ständig weiterentwickelt. Es gab inzwischen viele FORTRAN-Compiler, jeder hatte seine eigenen Zusatzfunktionen, die nicht im Original-Compiler zu finden waren. Die Portabilität der Programme war durch die vielen Dialekte nahezu unmöglich.

Zur gleichen Zeit fing die ASA (American Standards Association, heute AmericanNational Standards Institute (ANSI) an, viele Aspekte der Datenverarbeitung zu standardisieren, u.a. auch Programmiersprachen.

1966 Erste standardisierte FORTRAN-Version FORTRAN66

1978 Ein neuer Standard wurde vorgestellt: FORTRAN77

Erneuerungen: viele neue Ein- und Ausgabemöglichkeiten, wie z.B. direkter Zugriff auf Dateien; IF-THEN-ELSE-Konstrukte, Character-Datentyp u.a.

Sobald FORTRAN77 vollständig war, haben sich ANSI und ISO der neuen FORTRAN-Version gewidmet, die heute FORTRAN90 heißt. Viele Verbesserungsvorschläge an FORTRAN77 wurden in FORTRAN90 übernommen.

5/47


isse

nsv

erar

be

itu

ng

un

d N

um

erik



FORTRAN

als Programmiersprache der Numerik (2)

1978-81 Verbesserungsvorschläge wurden gesammelt.

1979-85 Die meisten technischen Veränderungen wurden als detaillierte Vorschläge präsentiert. Anschließend wurden sie diskutiert und das Komitee stimmte über sie ab.

Eine große Menge der technischen Arbeit war bereits 1985 beendet.

Die folgenden 5 Jahre wurden die Vorschläge noch verfeinert.

1987 Vorversion des neuen Standards war fertiggestellt.

1990 Erneute Überarbeitung und technische Arbeit vollendet.

1991 FORTRAN90 offizieller internationaler Standard (ISO).

1992 U.S. nationaler Standard (ANSI).

Es gibt viele Gründe dafür, warum ein neuer Standard notwendig ist:

Es existieren inzwischen viele Dialekte des FORTRAN77-Standards, die verschiedene Teile des neuen FORTRAN90-Standards, vor allem Syntaxveränderungen, enthalten. Gerade deswegen ist es notwendig, diese Veränderungen und Verbesserungen in einem für alle Hersteller verbindlichen Standards festzuhalten.

Computertechnologie und Programmiermethoden entwickeln sich sehr schnell weiter. FORTRAN77 weist einige offenbare Unzulänglichkeiten auf.

Die Portabilität wurde durch den neuen Standard verbessert.

Die Computer-Hardware, die das Sprachen-Design beeinflußt, hat sich durch die Parallel- und Vektorrechner verändert.

Genauso gibt es viele Gründe dafür, nicht auf eine andere moderne Programmiersprache zurückzugreifen. Es bleibt so z.B. die Kompatibilität mit dem alten Standard und dem bereits in großer Menge existierenden Code erhalten. FORTRAN77-Programme müssen also nicht in FORTRAN90 umgeschrieben werden. Außerdem wurden einige Eigenschaften des alten FORTRAN-Standards in FORTRAN90 verbessert, einige davon werden in der nächsten FORTRAN-Version wohl wegfallen.

5/48


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Äquivalente Konstrukte in C++ und Fortran 90

Konstrukte C++ F90

KlasseZugangsbeschränkung Überdachen

Classprotected

moduleprivateoptional::<name> +if (present(<name>) then :end if

Zugangsöffnung Vererbung

Publicfriend

useüber use, das es erlaubt,daß Teile eines Moduls vonanderen verwendet werden

Objekte Initialisierung Beendung

über constructorüber destructor

nutzerdefiniertes Createfehlt

Static class variables static save

Dynamische Speicherplatz-verwaltung

new allocatable

Matrixoperationen nutzerdefiniert Array Operationen

Methoden object. Member Function ( )verbindetDaten + MethodenFest angebunden

Call Member Function ( )

über Schnittstelle angebunden

5/49


isse

nsv

erar

be

itu

ng

un

d N

um

erik



JAVA als Programmiersprache der Zukunft

JAVA ist die Programmiersprache der Zukunft

Es ist weitgehend rechnerunabhängig, voll objektorientiert und wesentlich einfacher als C++.

Insbesondere unterstützt JAVA voll die Komponententechnik.

Informationen zu JAVA Kursen finden Sie auf den Seiten des Informatik Verbundes Stuttgart IVS unter

http://www.iasweb.de/ivs/ivs/index.htm

5/50


isse

nsv

erar

be

itu

ng

un

d N

um

erik



Diese Fragen sollten Sie jetzt beantworten können

Geben Sie mindestens 3 Aggregationsstufen an und beschreiben Sie ihre Funktion bei der Wiederverwendung

Was sind Entwurfsmuster und welche Bedeutung haben sie Beschreiben Sie das Strategy Pattern Was sind Frameworks Beschreiben Sie die Beziehung zwischen Entwurfsmustern,

Frameworks und Komponenten und veranschaulichen Sie sie durch ein UML Diagramm

Wie entwickelt man ein Framework Was ist ein Antipattern Geben Sie 3 Kriterien zur Auswahl einer Programmiersprache an und

begründen Sie ihre Bedeutung

Documents

Universität Stuttgart Wissensverarbeitung und Numerik I nstitut für K ernenergetik und E nergiesysteme Simulation technischer Systeme, WS 01/02Kap. 5: