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

Das sollten Sie heute lernen Schichtenkonzept der Wiederverwendbarkeit Entwurfs als Modellierungsschritt Entwurfsentscheidungen Entwurfsziele Entwurfsmuster Antipattern Framework OO Programmiersprachen

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

Vom Objekt zum System - Aggregationsstufen 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 heute Entwürfe sollten auf allen Stufen stattfinden - Top Down Ansatz

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.

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 Lösungsraum: Daten(-typen), Funktionen, Dateien, Programme ... Architektur: Softwaresystem ist ebenfalls (wie Realität) komplex und muß geeignet strukturiert werden. Spezifikation: formale Beschreibung der zu implementierenden Software

Ziele des Entwurfs (2) Die zentralen Fragen lauten nun: Merke: 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

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.

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 Siehe Gamma, 1.6 Design Problems (pp. 11 ff)

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

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.

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 Programmiersprachen: ein guter Entwurf für C++ muß noch lange kein guter Entwurf für Smalltalk sein C++-Abwägung: wann Templates/virtuelle Funktionen einsetzen?

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 Siehe z.B. Strategy-Pattern

Wiederverwendbarkeit, Portabilität und Übersichtlichkeit 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) Wiederverwendbaren Code zu schreiben bedeutet z.T. erheblichen Mehraufwand, der sich nur unter Umständen lohnt

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

Entwurfsmuster und persönliche Erfahrung 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.

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 Frameworks können Entwurfsmuster enthalten bzw. mit Entwurfsmustern Dokumentiert werden.

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

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)

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

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

Struktur des Entwurfsmusters Abstrakte Simulation OODS_SimulationModel OODS_Object Name Type Description CloneModel(...) SimulateModelState(...) OODS_Parameter OODS_Port GetModelState(...) 1 * 1..* OODS_State Time Values OODS_Value Add(...) Subtract(...) ... OODS Objekt enthält OODS S.M., Port, State und Para. OODS S.M. verwendet

Vom Objekt zum System - Aggregationsstufen 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 heute Entwürfe sollten auf allen Stufen stattfinden - Top Down Ansatz

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.

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.

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

Das Strategie-Entwurfsmuster Strategy Pattern Vererbung Abhängigkeit Assoziation Aggregation

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.

Konkrete Anwendung: Zeitintegration Aggregation Vererbung

Implementierung 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);

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

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.

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. implementiert enthält Besteht aus implementiert Assoziation

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)

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.

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)

Bestandteile eines Anti-Patterns Hintergrund Antipattern (Generelle Form) Symptome und Konsequenzen Ursache Ausnahmen Verbesserungsvorschlag Variationen Beispiel Verwandte Antipatterns

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)

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

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 (Tool-Tool; Service-Service; Tool-Service) unterstützt Kommunikation Message Service

Definition OO-Programmiersprache Objektbasiert Datenabstraktion Klassen Beispiele: Visual Basic Objektorientiert objektbasiert Vererbung Polymorphismus Beispiele: C++, Java, Smalltalk, ...

Ü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: Problem: Welche Programmiersprache ist die richtige ? Auswahlkriterien sind wichtig ! http://java.sun.com/docs/books/tutorial/

Auswahlkriterien anhand von Beispielen (1)

Auswahlkriterien anhand von Beispielen (2)

Auswahlkriterien anhand von Beispielen (3) 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.

FORTRAN als Programmiersprache der Numerik (1) Geschichtliche Entwicklung 1954 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 American National 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.

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.

Äquivalente Konstrukte in C++ und Fortran 90

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

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