Objektorientierte Mathematische Modellbildung

Einleitung

Diese Seite zum Thema Objektorientierte Mathematische Modellbilung kann als Wiki2Reveal Folien a angezeigt werden. Einzelne Abschnitte werden als Folien betrachtet und Änderungen an den Folien wirken sich sofort auf den Inhalt der Folien aus.

Teilaspekte der OOMM

Dabei werden die folgenden Teilaspekte im Detail behandelt:

(1) Mathematische Beschreibung von Objekten/Instanzen und Klassen,
(2) Mathematische Beschreibung von Zuständen von Objekten,
(3) Prozesse und Methoden zur mathematischen Beschreibung von Veränderungen in Netzen von kommunizierenden Objekten

Modellbildung

In der Modellbildung betrachtet man ein System und erarbeitet durch Systemanalyse eine Modell als Ergebnis der Analyse. Dieser Prozess ist in der Regel iterativ, da man durch Erkenntnisgewinn über das betrachtete System das Modell weiter verbessern kann. In der Mathematischen Modellbildung erfolgt die Beschreibung des Systems mit mathematischen Methoden und in einer mathematischen Syntax.

Modellbildungszyklus

Die Abbildung zeigt, wie ausgehend von einer Realsituation ein Modellierungsproblems definiert wird und in einem iterativen Ablauf das mathematische Modell und dessen Implementation in ein rechnergestütztes ablauffähiges Modell schrittweise verbessert werden kann.

Modellbildungszyklus

Objektorientierte Programmierung

Die objektorientierte Programmierung' (kurz OOP) ist ein auf dem Konzept der Objektorientierung basierendes Programmierparadigma. Die Grundidee besteht darin, die Architektur einer Software an den Grundstrukturen desjenigen Bereichs der Wirklichkeit auszurichten, der die gegebene Anwendung betrifft.

Entwurfsphase

Ein Modell dieser Strukturen wird in der Entwurfsphase aufgestellt. Es enthält Informationen über die in dem System

auftretenden Objekte und deren Klassifikation,
der Kommunikation zwischen Objekten

In der OOP geht es um die Erstellung eines Softwareproduktes. Im wissenschaftlichen Kontext geht es z.B. um Simulationsumgebungen, mit dem Systemverhalten bzw. beobachtbare und messbares Aspekte eines Systems untersucht werden können. Durch vergleichende Analysen mit dem realen System geht es um Strukturaufklärung und Strukturbeschreibung des Systems.

Grundlegende Konzepte

Die Umsetzung dieser Denkweise erfordert die Einführung verschiedener Konzepte, insbesondere Klassen, Vererbung, Polymorphie und spätes Binden (dynamisches Binden).

Zielsetzung

Diese Lernressource zu Thema Objektorientierte Mathematische Modellbilung in der Wikiversity hat das Ziel, mathematische Modellbildung mit Prinzipien der Objektorientierung zu verbinden.

Nachhaltigkeitsziele

Vor dem Hintergrund der Nachhaltigkeitsziele der Vereinten Nationen versucht man Objekte in einem System zu klassifizieren, deren Ressourcenverbrauch zu modellieren und diesen auch zu optimieren.

Zielgruppe

Die Zielgruppen der Lernressource zum Thema Objektorientierte Mathematische Modellbilung sind

Studierende im Fach Mathematik
Studierende im Fach Umweltwissenschaften

Lerneinheiten

Geschichte
Zustandsraum - (Foliensatz)

Klassen

Basisklassen - (Foliensatz)
Vererbung - (Foliensatz)

Einführende Aufgaben

Mit den folgenden Aufgaben zum Thema Objektorientierte Mathematische Modellbilung werden zunächst grobe Strukturen eines Systems definiert.

Betrachten Sie das Thema Mobilität und Transport und definieren Sie in betrachteten System die Objekte und Klassen, die Sie in die mathematische Modellbildung einbinden möchten (z.B. Autos, Schiffe, ÖPNV).
Welche internen Zustände möchten Sie in diesem Modellen betrachten (z.B. Füllstand in Tank, Ladezustand von Batterien, ...)?
Welche Prozesse möchten Sie in dem Modell abbilden (z.B. die Bewegung im Raum zusammen mit dem Ressourceverbrauch)?

Definition

Die Definition, was objektorientierte Programmierung ist und im Kern ausmacht, variiert und ist auch Veränderungen unterworfen.

Konzepte

Im Vergleich mit anderen Programmiermethoden verwendet die objektorientierte Programmierung neue, andere Begriffe.

Die einzelnen Bausteine, aus denen ein objektorientiertes Programm während seiner Abarbeitung besteht, werden als Objekte bezeichnet. Die Objekte werden dabei in der Regel auf Basis der folgenden Konzepte entwickelt:

Abstraktion

Abstraktion: Jedes Objekt im System kann als ein abstraktes Modell eines Akteurs betrachtet werden, der Aufträge erledigen, seinen Zustand berichten und ändern und mit den anderen Objekten im System kommunizieren kann,

Klasse - Gemeinsamkeiten von Objekten

Eine Klasse in mathematische gesehen eine Menge von Objekten, die gemeinsame Eigenschaften besitzen, die durch

Attribute und
Methoden

beschrieben werden können.

Das Verhalten des Objekts wird von den Methoden der Klasse bestimmt. Klassen können von anderen Klassen abgeleitet werden (Vererbung). Dabei erbt die Klasse die Datenstruktur (Attribute) und die Methoden von der vererbenden Klasse (Basisklasse).

Prototyp: Objekte werden durch das Klonen bereits existierender Objekte erzeugt und können anderen Objekten als Prototypen dienen und damit ihre eigenen Methoden zur Wiederverwendung zur Verfügung stellen, wobei die neuen Objekte nur die Unterschiede zu ihrem Prototyp definieren müssen. Änderungen am Prototyp werden dynamisch auch an den von ihm abgeleiteten Objekten wirksam.

Datenkapselung: Als Datenkapselung bezeichnet man in der Programmierung das Verbergen von Implementierungsdetails. Auf die interne Datenstruktur kann nicht direkt zugegriffen werden, sondern nur über definierte Schnittstellen. Objekte können den internen Zustand anderer Objekte nicht in unerwarteter Weise lesen oder ändern. Ein Objekt hat eine Schnittstelle, die darüber bestimmt, auf welche Weise mit dem Objekt interagiert werden kann. Dies verhindert das Umgehen von Invarianten des Programms.

Feedback: Verschiedene Objekte kommunizieren über einen Nachricht-Antwort-Mechanismus, der zu Veränderungen in den Objekten führt und neue Nachrichtenaufrufe erzeugt. Dafür steht die Kopplung als Index für den Grad des Feedbacks.

Persistenz: Objektvariablen existieren, solange die Objekte vorhanden sind und „verfallen“ nicht nach Abarbeitung einer Methode.

Polymorphie (dt. Mehrgestalt): Fähigkeit eines Bezeichners, abhängig von seiner Verwendung unterschiedliche Datentypen anzunehmen. Verschiedene Objekte können auf die gleiche Nachricht unterschiedlich reagieren. Wird die Art der Reaktion auf die Nachricht erst zur Laufzeit aufgelöst, wird dies auch späte Bindung genannt.

Vererbung: Vererbung heißt vereinfacht, dass eine abgeleitete Klasse die Methoden und Attribute der Basisklasse ebenfalls besitzt, also „erbt“. Somit kann die abgeleitete Klasse auch darauf zugreifen. Neue Arten von Objekten können auf der Basis bereits vorhandener Objektdefinitionen festgelegt werden. Es können neue Bestandteile hinzugenommen werden oder vorhandene überlagert werden.

Objekte

Objekt (von dt. Ding / Sache): Ein Element, welches Funktionen, Methoden, Prozeduren, einen inneren Zustand, oder mehrere dieser Dinge besitzt.

Entität: Ein Objekt mit einer eindeutigen Identität zur Speicherung von Daten. Beispiel: Eine Person mit den Daten Adresse, Telefonnummer oder Name. Die Daten können geändert werden, ohne dass die Person ihre Identität verliert. Eine Person ist also eine Entität.^[1]

Wertobjekt: Ein Objekt, welches über seinen Wert definiert wird. Eine Telefonnummer, welche sich ändert, ist also eine andere Telefonnummer. Gleichartig ist eine Adresse, bei der sich lediglich die Hausnummer ändert, eine andere Adresse, selbst wenn alle anderen Daten gleich bleiben. Somit stellt eine Telefonnummer und eine Adresse keine Entität dar, sondern ein Wertobjekt.^[1]

Eigenschaft: Ein Bestandteil des Zustands eines Objekts. Hierbei kann es sich um eine Entität oder ein Wertobjekt handeln.

Dienst: Ein Objekt, welches ein Verhalten (z. B. eine Geschäftslogik) in Form von Prozeduren, Funktionen oder Methoden implementiert. Der Dienst verwendet hierbei Entitäten oder Wertobjekte.^[1]

Prozedur: Verändert den Zustand eines Objektes, ohne einen Rückgabewert zu liefern. Eine Prozedur kann andere Objekte als Parameter entgegennehmen.

Funktion: Ordnet einer gegebenen Eingabe einen bestimmten Rückgabewert zu. Eine Funktion zeichnet sich insbesondere dadurch aus, dass sie nicht den Zustand eines Objekts verändert.^[1]

Methode: Verändert den Zustand eines Objekts und liefert zudem einen Rückgabewert. Eine Methode kann andere Objekte als Parameter entgegennehmen.

Modul: Eine zusammengefasste Gruppe von Objekten.

Klassen

Zur besseren Verwaltung gleichartiger Objekte bedienen sich die meisten Programmiersprachen des Konzeptes der Klasse. Klassen sind Vorlagen, aus denen Instanzen genannte Objekte zur Laufzeit erzeugt werden. Im Programm werden nicht einzelne Objekte, sondern eine Klasse gleichartiger Objekte definiert. Existieren in der gewählten Programmiersprache keine Klassen oder werden diese explizit unterdrückt, so spricht man zur Unterscheidung oft auch von objektbasierter Programmierung.

Man kann sich die Erzeugung von Objekten aus einer Klasse vorstellen wie das Fertigen von Autos aus dem Konstruktionsplan eines bestimmten Fahrzeugtyps. Klassen sind die Konstruktionspläne für Objekte.

Die Klasse entspricht in etwa einem komplexen Datentyp wie in der prozeduralen Programmierung, geht aber darüber hinaus: Sie legt nicht nur die Datentypen fest, aus denen die mit Hilfe der Klassen erzeugten Objekte bestehen, sie definiert zudem die Algorithmen, die auf diesen Daten operieren. Während also zur Laufzeit eines Programms einzelne Objekte miteinander interagieren, wird das Grundmuster dieser Interaktion durch die Definition der einzelnen Klassen festgelegt.

Beispiel

Die Klasse „Auto“ legt fest, dass das Auto vier Reifen einer bestimmten Größe, fünf farbige Türen, einen Motor mit einer bestimmten Leistung und fünf Sitze mit wählbaren Bezügen hat.

Das Objekt „Auto1“ hat vier Reifen mit dem Durchmesser 19 Zoll und der Breite 255 mm, fünf rote Türen, einen Motor mit 150 kW und fünf Ledersitze.
Das Objekt „Auto2“ hat vier Reifen mit dem Durchmesser 19 Zoll und der Breite 255 mm, fünf rote Türen, einen Motor mit 150 kW und fünf Ledersitze.
Ein weiteres Objekt „Auto3“ hat vier Reifen mit dem Durchmesser 16 Zoll und der Breite 205 mm, fünf blaue Türen, einen Motor mit 90 kW und fünf Sitze mit Textilbezug.

Es handelt sich um drei Objekte; zwei davon haben gleiche Attribute. Alle drei sind aber Ausprägungen (Instanzen) der Klasse „Auto“.

Methoden bei Klassen

Die einer Klasse von Objekten zugeordneten Algorithmen bezeichnet man auch als Methoden.

Häufig wird der Begriff Methode synonym zu den Begriffen Funktion oder Prozedur aus anderen Programmiersprachen gebraucht. Die Funktion oder Prozedur ist jedoch eher als Implementierung einer Methode zu betrachten. Im täglichen Sprachgebrauch sagt man auch „Objekt A ruft Methode m von Objekt B auf.“

Eine besondere Rolle spielen Methoden für die Kapselung, insbesondere die Zugriffsfunktionen. Spezielle Methoden zur Erzeugung und Zerstörung von Objekten heißen Konstruktoren beziehungsweise Destruktoren.

Methoden können Parameter erhalten, die beim Aufruf übergeben werden müssen, und einen Rückgabewert besitzen, den sie am Ende dem Aufrufer zurückgeben. Beispielsweise hat die Methode addiere die Parameter Zahl 1 und Zahl 2 und gibt als Rückgabewert die Summe der Zahlen zurück.

In vielen objektorientierten Programmiersprachen lässt sich festlegen, welche Objekte eine bestimmte Methode aufrufen dürfen. So wird meist zwischen folgenden vier Zugriffsebenen unterschieden, die bereits zur Übersetzungszeit geprüft werden.

(1) Öffentliche (public) Methoden dürfen von allen Klassen aufgerufen werden.
(2) Geschützte (protected) Methoden dürfen von Klassen im selben Paket und abgeleiteten Klassen aufgerufen werden.
(3) Methoden auf Paket-Ebene können nur von Klassen aufgerufen werden, die sich im selben Paket befinden – diese Zugriffsebene ist nur bei Programmiersprachen vorhanden, die Pakete bzw. Namespaces kennen.
(4) Private Methoden können nur von anderen Methoden derselben Klasse aufgerufen werden.

Analog zu diesen vier Zugriffsebenen sind in der Unified Modeling Language (UML) vier Sichtbarkeiten für Operationen definiert.

Attribute

Objekte (Fenster, Schaltflächen, Laufleisten, Menüs, …) besitzen verschiedene Eigenschaften (Farbe, Größe, Ausrichtung, …). Diese Eigenschaften eines Objekts heißen Attribute.

Polymorphie

Unter bestimmten Voraussetzungen können Algorithmen, die auf den Schnittstellen eines bestimmten Objekttyps operieren, auch mit Objekten davon abgeleiteter Klassen zusammenarbeiten.

Geschieht dies so, dass durch Vererbung überschriebene Methoden an Stelle der Methoden der vererbenden Klasse ausgeführt werden, dann spricht man von Polymorphie. Polymorphie stellt damit eine Möglichkeit dar, einer durch ähnliche Objekte ausgeführten Aktion einen Namen zu geben, wobei jede Klasse die Aktion in einer für das Objekt geeigneten Weise implementiert.

Diese Technik, das sogenannte Overriding, implementiert aber keine universelle Polymorphie, sondern nur die sogenannte Ad-hoc-Polymorphie.

Terminologie

Die Begriffe der objektorientierten Programmierung haben teilweise unterschiedliche Namen. Folgende Bezeichnungen werden synonym verwendet:

Bezeichnungen in der objektorientierten Programmierung
Deutscher Begriff	Alternativen	Englisch
Abgeleitete Klasse	Kindklasse, Unterklasse, Subklasse	child class, subclass
Attribut	Objektvariable, Instanzvariable, Datenelement, Eigenschaft	member, property
Basisklasse	Elternklasse, Oberklasse, Superklasse	parent class, superclass
Objekt	Exemplar, Instanz	instance
Methode	Elementfunktion	method
Statische Methode	Klassenfunktion, Metafunktion	static method

Objektorientierte Programmiersprachen

Objektorientierte Programmiersprachen unterstützen die Programmstrukturierung mit einem speziellen Datentyp – dem Objekt, der die Objektorientierung ermöglicht. Die rein objektorientierten Sprachen, wie Smalltalk, folgen dem Prinzip: „Alles ist ein Objekt.“ Auch elementare Typen wie Ganzzahlen werden dabei durch Objekte repräsentiert – selbst Klassen sind hier Objekte, die wiederum Exemplare von Metaklassen sind. Die verbreiteten objektorientierten Programmiersprachen, unter anderem C#, C++ und Java, handhaben das Objektprinzip nicht alle so streng. Bei ihnen sind elementare Datentypen keine vollwertigen Objekte, da sie auf Methoden und Struktur verzichten müssen. Sie stellen dem Entwickler auch frei, wie stark er die Kapselung objektinterner Daten einhält.

Die erste bekannte objektorientierte Programmiersprache war Simula-67. Später wurden die Prinzipien der Kapselung in einer Klassenhierarchie dann in Smalltalk weiter ausgebaut. Mit dem ANSI/X3.226-1994-Standard wurde Common Lisp/CLOS zur ersten standardisierten objektorientierten Programmiersprache und mit ISO 8652:1995 wurde Ada 95 als erste nach dem internationalen ISO-Standard normierte objektorientierte Programmiersprache festgelegt.

Gängige moderne Programmiersprachen (z. B. Python) unterstützen sowohl die OOP als auch den prozeduralen Ansatz, der in den klassischen Programmiersprachen der 1970er- und 1980er-Jahre wie Pascal, Fortran oder C vorherrschte. Im Gegensatz dazu setzt Smalltalk, die älteste heute noch bedeutsame OOP-Sprache, auf kompromisslose Objektorientierung und hatte damit starken Einfluss auf die Entwicklung populärer OOP-Sprachen, ohne selber deren Verbreitung zu erreichen, weil keine kostengünstig allgemein verfügbare Implementierung angeboten wurde. Auch wenn der Durchbruch der OOP erst in den 1990er-Jahren stattfand, wurde die objektorientierte Programmierung bereits Ende der 1960er Jahre mit Simula-67 als Lösungsansatz für die Modularisierung und die Wiederverwendbarkeit von Code entwickelt.

Techniken

Objekt-Konzepte in Programmiersprachen

In einigen objektorientierten Programmiersprachen wie Go, NewtonScript und Self wird auf die Deklaration von Klassen gänzlich verzichtet. Stattdessen werden neue Objekte von bestehenden Objekten, den sogenannten Prototypen, abgeleitet. Die Attribute und Methoden des Prototyps kommen immer dann zum Einsatz, wenn sie im abgeleiteten Objekt nicht explizit überschrieben wurden. Dies ist vor allem für die Entwicklung kleinerer Programme von Vorteil, da es einfacher und zeitsparend ist.

In manchen Programmiersprachen, beispielsweise in Objective-C, gibt es zu jeder Klasse ein bestimmtes Objekt (Klassenobjekt), das die Klasse zur Laufzeit repräsentiert; dieses Klassenobjekt ist dann auch für die Erzeugung von Objekten der Klasse und den Aufruf der korrekten Methode zuständig.

Klassen werden in der Regel in Form von Klassenbibliotheken zusammengefasst, die häufig thematisch organisiert sind. So können Anwender einer objektorientierten Programmiersprache Klassenbibliotheken erwerben, die zum Beispiel den Zugriff auf Datenbanken ermöglichen.

Entwurf von Objekt-Konzepten

Die Wortarten einer sprachlichen Problembeschreibung können hilfreiche Hinweise dafür geben, eine Objekt-basierte Modellierung zu konzipieren (sogenannte Verb-Substantiv-Methode).^[2] Dabei werden Objekte und Klassen in der Regel sprachlich durch Substantive beschrieben, wobei Eigennamen auf Objekte und Appellative wie Haus und Tier auf Klassen hindeuten.^[3] Verben stehen in der Regel für Methoden, wobei Adverbien und Substantive ergänzende Charakterisierungen der Methoden geben können. Die Werte von Objektattributen entsprechen häufig Numeralien oder Adjektiven.^[4]

Es gibt inzwischen auch Verfeinerungen der objektorientierten Programmierung durch Methoden wie Entwurfsmuster, Design by contract und grafische Modellierungssprachen wie die Unified Modeling Language.

Einen immer höheren Stellenwert nimmt die aspektorientierte Programmierung ein, bei der Aspekte von Eigenschaften und Abhängigkeiten beschrieben werden. Erste Ansätze sind beispielsweise in Java mit Jakarta EE oder der abstrakten Datenhaltung über Persistenzschichten sichtbar.

Grenzen der OOP

Das objektorientierte Paradigma hat Vor- und Nachteile je nach Anwendungsfeld in der Softwaretechnik oder konkreter Problemstellung.

Abbildung von Problemstellungen auf OOP-Techniken

Die OOP kann, wie auch andere Programmierparadigmen, verwendet werden, Probleme aus der realen Welt abzubilden. Als ein typisches Beispiel für Problemstellungen, die sich einer geschickten Modellierung mit OOP-Techniken entziehen, gilt das Kreis-Ellipse-Problem.

Objektorientierte Programmiersprachen und natürliche Sprachen

Objektorientierte Programmiersprachen können auch unter sprachwissenschaftlichen Aspekten mit natürlichen Sprachen verglichen werden. OO-Programmiersprachen haben ihren Fokus auf den Objekten, welche sprachlich Substantive sind. Die Verben (Aktionen) sind sekundär, fest an Substantive gebunden (gekapselt) und können im Allgemeinen nicht für sich allein stehen. Bei natürlichen Sprachen und z. B. prozeduralen Sprachen existieren Verben eigenständig und unabhängig von den Substantiven (Daten), z. B. als Imperativ und Funktion. Es kann argumentiert werden, dass diese sprachliche Einschränkung in einigen Anwendungsfällen zu unnötig komplizierten Beschreibungen von Problemen aus der realen Welt mit objektorientierten Sprachen führt.^[5]^[6]

OOP und Kontrollfluss

Häufig genannte Vorzüge des OOP-Paradigmas sind eine verbesserte Wartbarkeit und Wiederverwendbarkeit des statischen Quellcodes.^[7] Hierzu werden jedoch die Kontrollflüsse und das dynamische Laufzeitverhalten den Daten/Objekten im Allgemeinen untergeordnet, abstrahiert und weggekapselt. Die Kontrollflüsse bilden sich nicht mehr für den Entwickler transparent direkt in den Codestrukturen ab (wie z. B. bei prozeduralen Sprachen), eine Umsetzung in dieser Hinsicht wird dem Compiler überlassen. Hardware-nähere Sprachen wie das prozedurale C oder Assembler bilden den echten Kontrollfluss und das Laufzeitverhalten transparenter ab.^[8] Mit der wachsenden Bedeutung von paralleler Hardware und nebenläufigem Code wird jedoch eine bessere Kontrolle und Entwickler-Transparenz der komplexer werdenden Kontrollflüsse immer wichtiger – etwas, das schwierig mit OOP zu erreichen ist.^[9]^[10]

OOP und relationale Datenbanken

Ein häufig genannter Bereich, in dem OOP-Techniken als unzureichend gelten, ist die Anbindung von relationalen Datenbanken. OOP-Objekte lassen sich nicht direkt in allen Aspekten mit relationalen Datenbanken abbilden. Umgekehrt können über OOP die Stärken und Fähigkeiten von relationalen Datenbanken ebenfalls nicht vollständig ausgeschöpft werden. Die Notwendigkeit, eine Brücke zwischen diesen beiden Konzeptwelten zu schlagen, ist als object-relational impedance mismatch bekannt. Hierzu existieren viele Ansätze, beispielsweise die häufig verwendete objektrelationale Abbildung, jedoch keine allgemeingültige Lösung ohne den einen oder anderen Nachteil.^[11]

Laufzeitverhalten und Energieeffizienz

Die Effektivität des Laufzeitverhaltens von Anwendungen, die auf OOP-Techniken basieren, wird seit jeher kontrovers diskutiert. Alexander Chatzigeorgiou von der Universität Makedonien verglich die Laufzeiteffektivität und die Energieeffizienz von typischen Algorithmen (Gauß-Jordan-Algorithmus, Trapez-Integration und QuickSort) von prozeduralen Ansätzen und OOP-Techniken, implementiert als C- und C++-Software. Auf dem verwendeten ARM-Prozessor ergab sich für drei Algorithmen im Mittel eine um 48,41 % bessere Laufzeiteffektivität mit den prozeduralen C-Algorithmusvarianten. Es ergab sich außerdem eine im Mittel um 95,34 % höhere Leistungsaufnahme der C++-Varianten zu den C-Varianten.^[12] Für Anwendungen auf mobilen Geräten, wie Handys oder MP3-Spielern mit begrenzten Leistungs- und Energiespeichervermögen, sind derartige Unterschiede signifikant, allerdings machen derartige Algorithmen in der Regel nur einen Bruchteil der Applikationen aus. Als Grund für den Unterschied in Effektivität und Energieeffizienz werden in dem Artikel generelle Abstraktions-Leistungseinbußen und die deutlich größere Anzahl von Zugriffen auf den Arbeitsspeicher durch OOP-Techniken genannt.

Kritik

Modularisierung und andere Prinzipien nicht ausgereift

Luca Cardelli untersuchte 1996 für das DEC Systems Research Center die Effizienz von OOP-Ansätzen in dem Artikel Bad Engineering Properties of Object-Oriented Languages mit den Metriken Programmablaufgeschwindigkeit (economy of execution), Kompilationsgeschwindigkeit (economy of compilation), Entwicklungseffizienz für große und kleine Teams (economy of small-scale development und economy of large-scale development) und die Eleganz des Sprachumfangs selbst (economy of language features). Er kam zu dem Schluss, dass das objektorientierte Sprachdesign noch viel aus dem prozeduralen Sprachendesign lernen müsste, insbesondere im Bereich der guten Modularisierung, der Datenabstraktion und des Polymorphismus, um die hochgesteckten Erwartungen zu erfüllen.^[13]

Keine Erhöhung der Produktivität gegenüber prozeduralen Ansätzen

Eine Studie von Potok et al. aus dem Jahre 1999 zeigte keine signifikanten Produktivitätsunterschiede zwischen OOP und prozeduralen Ansätzen.^[14]

Die Autoren definieren „Produktivität“ in der Einheit „entwickelte/geänderte Programmzeilen pro Zeiteinheit“ und untersuchen insbesondere den Einfluss von Code Reuse auf diese Metrik. Sie weisen darauf hin, dass eine Konzentration auf Code Reuse unter Umständen der objektorientierten Programmierung nicht gerecht wird, da sie sich noch auf andere Weisen positiv auf die Produktivität auswirken könnte (beispielsweise durch ein einfacheres Design).

Die Autoren führen mehrere Gründe an, weshalb die Ergebnisse ihrer Studie verzerrt sein könnten:

Es könnte sein, dass als „objektorientiert“ deklarierte Software in Wirklichkeit prozedural entwickelt wurde.
Sie analysierten nur zwei Generationen objektorientierter Software, was ihrer Aussage nach zu wenig sein könnte.
Es könnte sein, dass die Qualifikation der verschiedenen Entwicklungsteams unterschiedlich war. Insbesondere wäre es möglich, dass die objektorientierte Software von geringer qualifizierten Teams entwickelt wurde.

Die Autoren vertreten die Meinung, diese Punkte träfen nicht zu.

Literatur

Bernhard Lahres, Gregor Raýman: Praxisbuch Objektorientierung. Galileo Computing, ISBN 3-89842-624-6 (Frei verfügbar auf der Verlags-Website).
Harold Abelson, Gerald Jay Sussman, Julie Sussman: Structure and Interpretation of Computer Programs. The MIT Press, ISBN 0-262-01153-0.
Heide Balzert: Objektorientierte Systemanalyse. Spektrum Akademischer Verlag, Heidelberg 1996, ISBN 3-8274-0111-9.
Grady Booch: Object-Oriented Analysis and Design with Applications. Addison-Wesley, ISBN 0-8053-5340-2.
Peter Eeles, Oliver Sims: Building Business Objects. John Wiley & Sons, ISBN 0-471-19176-0.
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns: Elements of Reusable Object Oriented Software. Addison-Wesley, ISBN 0-201-63361-2.
Paul Harmon, William Morrissey: The Object Technology Casebook. Lessons from Award-Winning Business Applications. John Wiley & Sons, ISBN 0-471-14717-6.
Ivar Jacobson: Object-Oriented Software Engineering: A Use-Case-Driven Approach. Addison-Wesley, ISBN 0-201-54435-0.
Bertrand Meyer: Object-Oriented Software Construction. Prentice Hall, ISBN 0-13-629155-4.
Bernd Oestereich: Objektorientierte Programmierung mit der Unified Modeling Language. Oldenbourg, ISBN 3-486-24319-5.
James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen: Object-Oriented Modeling and Design. Prentice Hall, ISBN 0-13-629841-9.

Weblinks

Praxisbuch Objektorientierung (openbook)
Objektorientiertes Programmieren in Java (openbook)
Aufgaben der OOP
Flash ActionScript OOP – Einführung in die objektorientierte Programmierung
Fachwissen auf ELEKTRONIKPRAXIS ONLINE Objektorientierte Programmierung mit C

Einzelnachweise

↑ ^a ^b ^c ^d Debasish Ghosh: Functional and Reactive Domain Modeling. Manning, 2016, ISBN 978-1-61729-224-8 (englisch, 325 S.).
↑ David J. Barnes, Michael Kölling: Java lernen mit BlueJ: Eine Einführung in die objektorientierte Programmierung. München 2009, ISBN 978-3-86894-001-5, S. 496.
↑ Russell J. Abbott: Program design by informal English descriptions. In: Communications of the ACM. 26. Jahrgang, 1983, S. 882–894, doi:10.1145/182.358441.
↑ Jörg Bewersdorff: Objektorientierte Programmierung mit JavaScript: Direktstart für Einsteiger. 2. Auflage. Wiesbaden 2018, ISBN 978-3-658-21076-2, S. 30–33, doi:10.1007/978-3-658-21077-9_4.
↑ Steve Yegge: Execution in the Kingdom of Nouns. steve-yegge.blogspot.com. 30. März 2006. Abgerufen am 3. Juli 2010..
↑ Timothy Boronczyk: What’s Wrong with OOP. zaemis.blogspot.com. 11. Juni 2009. Abgerufen am 3. Juli 2010..
↑ Scott Ambler: A Realistic Look at Object-Oriented Reuse. drdobbs.com. 1. Januar 1998. Abgerufen am 4. Juli 2010..
↑ Asaf Shelly: Flaws of Object Oriented Modeling. Intel® Software Network. 22. August 2008. Abgerufen am 4. Juli 2010..
↑ Justin James: Multithreading is a verb not a noun. techrepublic.com. 1. Oktober 2007. Abgerufen am 4. Juli 2010..
↑ Asaf Shelly: HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions. support.microsoft.com. 22. August 2008. Abgerufen am 4. Juli 2010..
↑ Ted Neward: The Vietnam of Computer Science. Interoperability Happens. 26. Juni 2006. Archiviert vom Original am 4. Juli 2006. Abgerufen am 2. Juni 2010..
↑ Alexander Chatzigeorgiou: Performance and power evaluation of C++ object-oriented programming in embedded processors. In: Information and Software Technology. 45. Jahrgang, Nr. 4, 2003, ISSN 0950-5849, S. 195–201, doi:10.1016/S0950-5849(02)00205-7.
↑ Luca Cardelli: Bad Engineering Properties of Object-Oriented Languages. In: ACM Comput. Surv. 28. Jahrgang. ACM, 1996, ISSN 0360-0300, S. 150, doi:10.1145/242224.242415 (@1@2Vorlage:Toter Link/lucacardelli.name(Seite nicht mehr abrufbar, Suche in Webarchiven: lucacardelli.name) [abgerufen am 21. April 2010]).
↑ Thomas Potok, Mladen Vouk, Andy Rindos: Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment. In: Software – Practice and Experience. 29. Jahrgang, Nr. 10, 1999, S. 833–847 (@1@2Vorlage:Toter Link/www.csm.ornl.gov(Seite nicht mehr abrufbar, Suche in Webarchiven: ornl.gov) [abgerufen am 21. April 2010]).

Siehe auch

Seiteninformation

Diese Lernresource können Sie als Wiki2Reveal-Foliensatz darstellen.

Wiki2Reveal

Dieser Wiki2Reveal Foliensatz wurde für den Lerneinheit Mathematische Modellbildung' erstellt der Link für die Wiki2Reveal-Folien wurde mit dem Wiki2Reveal-Linkgenerator erstellt.

Die Seite wurde als Dokumententyp PanDocElectron-SLIDE erstellt.
Link zur Quelle in Wikiversity: https://de.wikiversity.org/wiki/Objektorientierte%20Mathematische%20Modellbildung
siehe auch weitere Informationen zu Wiki2Reveal und unter Wiki2Reveal-Linkgenerator.

Wikipedia2Wikiversity

Diese Seite wurde auf Basis der folgenden Wikipedia-Quelle erstellt:

[ghosh-1] Debasish Ghosh: Functional and Reactive Domain Modeling. Manning, 2016, ISBN 978-1-61729-224-8 (englisch, 325 S.).

[2] David J. Barnes, Michael Kölling: Java lernen mit BlueJ: Eine Einführung in die objektorientierte Programmierung. München 2009, ISBN 978-3-86894-001-5, S. 496.

[3] Russell J. Abbott: Program design by informal English descriptions. In: Communications of the ACM. 26. Jahrgang, 1983, S. 882–894, doi:10.1145/182.358441.

[4] Jörg Bewersdorff: Objektorientierte Programmierung mit JavaScript: Direktstart für Einsteiger. 2. Auflage. Wiesbaden 2018, ISBN 978-3-658-21076-2, S. 30–33, doi:10.1007/978-3-658-21077-9_4.

[executioniKoN-5] Steve Yegge: Execution in the Kingdom of Nouns. steve-yegge.blogspot.com. 30. März 2006. Abgerufen am 3. Juli 2010..

[executioniKoN2-6] Timothy Boronczyk: What’s Wrong with OOP. zaemis.blogspot.com. 11. Juni 2009. Abgerufen am 3. Juli 2010..

[realisticcodereuse-7] Scott Ambler: A Realistic Look at Object-Oriented Reuse. drdobbs.com. 1. Januar 1998. Abgerufen am 4. Juli 2010..

[flaws-8] Asaf Shelly: Flaws of Object Oriented Modeling. Intel® Software Network. 22. August 2008. Abgerufen am 4. Juli 2010..

[multithreadingisaverb-9] Justin James: Multithreading is a verb not a noun. techrepublic.com. 1. Oktober 2007. Abgerufen am 4. Juli 2010..

[multicore-10] Asaf Shelly: HOW TO: Multicore Programming (Multiprocessing) Visual C++ Class Design Guidelines, Member Functions. support.microsoft.com. 22. August 2008. Abgerufen am 4. Juli 2010..

[RDMDBobjectmis-11] Ted Neward: The Vietnam of Computer Science. Interoperability Happens. 26. Juni 2006. Archiviert vom Original am 4. Juli 2006. Abgerufen am 2. Juni 2010..

[chatz-12] Alexander Chatzigeorgiou: Performance and power evaluation of C++ object-oriented programming in embedded processors. In: Information and Software Technology. 45. Jahrgang, Nr. 4, 2003, ISSN 0950-5849, S. 195–201, doi:10.1016/S0950-5849(02)00205-7.

[badproperties-13] Luca Cardelli: Bad Engineering Properties of Object-Oriented Languages. In: ACM Comput. Surv. 28. Jahrgang. ACM, 1996, ISSN 0360-0300, S. 150, doi:10.1145/242224.242415 (@1@2Vorlage:Toter Link/lucacardelli.name(Seite nicht mehr abrufbar, Suche in Webarchiven: lucacardelli.name) [abgerufen am 21. April 2010]).

[potok-14] Thomas Potok, Mladen Vouk, Andy Rindos: Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment. In: Software – Practice and Experience. 29. Jahrgang, Nr. 10, 1999, S. 833–847 (@1@2Vorlage:Toter Link/www.csm.ornl.gov(Seite nicht mehr abrufbar, Suche in Webarchiven: ornl.gov) [abgerufen am 21. April 2010]).

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]