Zusammenfassung
Der Begriff des Objekts weist unterschiedliche Facetten auf. Einerseits wird der Begriff umgangssprachlich für die Bezeichnung beliebiger Gegenstände der ‚Realwelt‘ verwendet. Andererseits hat der Begriff in unterschiedlichen Bereichen (z. B. Kunst, Immobilienbranche) und insbesondere in verschiedenen wissenschaftlichen Forschungsdisziplinen (z. B. Philosophie, Sprachwissenschaften, Informatik, Betriebswirtschaftslehre) eine spezifische Semantik.111 In diesem Kontext ist die Differenzierung des Objektbegriffs der Betriebswirtschaftslehre (als Gegenstandsbereich der Informationssystemmodellierung) und der Informatik (als Disziplin, die sich u. a. mit der Modellierung und Implementierung von Anwendungssystemen befaßt) relevant.
This is a preview of subscription content, log in via an institution.
Buying options
Tax calculation will be finalised at checkout
Purchases are for personal use only
Learn about institutional subscriptionsPreview
Unable to display preview. Download preview PDF.
Literatur
Vgl. Hesse et al. (Teil 1) (1994), S. 42.
Vgl. Kosiol (1962), S.50ff.
Vgl. Bühner (1989), S. 10.
Organisation bezeichnet einerseits den Prozeß der Gestaltung einer Aufbau- und Ablauforganisation, und andererseits ist die Organisation das Ergebnis dieses Prozesses. Vgl. Bühner (1989), S. 1ff.
„Unter der Aufbauorganisation wird die Festlegung der Aufgabe nach den Merkmalen der Verrichtung und des Objekts verstanden. “ Bühner (1989), S. 11.
Zur Gruppierung ist auch die Verwendung von Ausgangsobjekten (Rohstoffe, Zwischenprodukte, Dienstleistungen usw.) oder Arbeitsmittel (Werkzeuge, Transportmittel usw.) denkbar. Vgl. Kosiol (1962), S. 50f.
Ein Objekttyp bezeichnet eine Klasse ähnlicher Objekte. In der betriebswirtschaftlichen Literatur wird der Begriff ‚Objekt‘ statt ‚Objekttyp‘ verwendet. Dieser Sichtweise wird hier nicht gefolgt, da mit einem Objekt konkrete, eindeutig identifizierbare Dinge der Realwelt assoziiert werden.
„Die Ablauforganisation ist [...] durch die Festlegung der Aufgabe nach den Merkmalen ‚Raum‘ und insbesondere ‚Zeit‘ gekennzeichnet. “ Bühner (1989), S. 11. Vgl. auch Kosiol (1962), S. 32.
Vgl. Davenport (1993); Hammer/Champy (1993); Gaitanides (1992), S. 15–16.
Rosemann (Komplexität) (1996), S. 9.
Vgl. Rosemann (Komplexität) (1996), S. 8ff. und S. 76–84.
Vgl. zu den folgenden Ausführungen Becker (Objektorientierung) (1991), S. 136ff.
Zu einer ausführlichen Darstellung der Entwicklung der Objektorientierung in der Informatik vgl. beispielsweise Dischinger (1995), S. 4–17.
Vgl. Schäfer (1994), S. 57ff.; Appelfeller (1995), S. 17; FerstVSinz (1993), S. 2.
Die im Kontext dieser Arbeit wesentlichen Konzepte des objektorientierten Paradigmas der Informatik werden in Abschnitt 3.2 skizziert. Zu einer umfassenden Einführung vgl. bspw. Meyer (1997); Quibeldey-Cirkel(1994).
Vgl. Becker (Objektorientierung) (1991), S. 142ff.
Ein Überblick und Vergleich der Konzepte verschiedener objektorientierter Programmiersprachen findet sich beispielsweise in Gall/Hauswirth/Klösch (1995); Srinivasan/Jayaraman (1994).
Meyer unterscheidet beispielsweise sieben Stufen der Objektorientierung. Vgl. Meyer (1990), S. 65ff.
Zu einer Einführung in die Technologie objektorientierter Datenbanken vgl. Heuer (1992); Unland (1995).
Zur Entwicklung objektorientierter Datenbanken vgl. Unland (1995), S. 9ff.
Vgl. Lausen/Vossen (1996), S. 7; Heuer (1992), S. 125f.
Vgl. Dischinger (1995), S. 12.
Vgl. Balzert (1996), S. 468ff.
Meyer (1997), S. 218.
Meyer (1997), S. 165. Die Begriffe ‚Klasse‘ und ,Objekt‘ werden in der Literatur häufig nicht exakt getrennt. So wird der Begriff ‚Objekt‘ verwendet, wenn strenggenommen eine Klasse gemeint ist. Vgl. Meyer (1997), S. 166ff.; Hesse et al. (Teil 1) (1994), S. 42.
„A type is a precise characterization of structural or behavioural properties which a collection of entities (actual or potential) all share. An instance of a type is an entity which has the properties of the type. “ Zilles (1994), S. 442. Das Typkonzept dient dazu, die Transparenz und Verständlichkeit von Quellcode zu erhöhen und durch eine Typüberprüfung Fehler zu entdecken. Bei objektorientierten Programmiersprachen kann zwischen static typing, strong typing und untyped differenziert werden. Vgl. Gall/Hauswirth/Klösch (1995), S. 196.
Zum Begriff des abstrakten Datentyps vgl. Balzert (1996), S. 859f. und die dort zitierte Literatur.
Die Definition von Klassen als Implementierung eines abstrakten Datentyps ist als idealtypisch anzusehen. In objektorientierten Programmen finden sich häufig Klassen, die den strengen Anforderungen eines abstrakten Datentyps nicht gerecht werden.
Zur unterschiedlichen Verwendung des Objektbegriffes vgl. Coad/Yourdon (1991), S. 30.
Rumbaugh et al. (1991), S. 21. Streng genommen sind in dieser Definition Klassen und nicht Objekte gemeint. Ähnliche Definitionen finden sich beispielsweise bei Martin/Odell (1992), S. 15f.; Coad/Yourdon (1991), S. 53.
Zu einer umfassenden Einführung in die Konzepte des objektorientierten Paradigmas vgl. bspw. Meyer (1997); Quibeldey-Cirkel (1994).
Vgl.Vossen(1999), S. 268.
Vgl. Schwegmann/Schlagheck (1997), S. 21f.
Zur Verwendung des Strukturbegriffes vgl. Fußnote 10.
Einige objektorientierte Programmiersprachen wie C++ oder Eiffel unterscheiden zwischen elementaren Datentypen und Klassen. Objektorientierte Programmiersprachen, die das objektorientierte Paradigma ‚in Reinform‘ unterstützen, kennen nur das Konstrukt der Klasse. Dies ist beispielsweise bei der Programmiersprache Smalltalk der Fall. Zu Vor- und Nachteilen getypter und ungetypter objektorientierter Programmiersprachen vgl. Meyer (1997), S. 615–621.
Zur Differenzierung von Instanz- und Klassenvariablen bzw. Instanz- und Klassenmethoden vgl. Meyer (1997), S. 168f.; Booch(1994), S. 133f.
Zum Begriff der Vererbung und zu den Arten von Vererbungsbeziehungen vgl. Abschnitt 3.2.2.
Vgl. Meyer (1997), S. 134f.; Coad/Yourdon (1991), S. 146ff. Eine trennscharfe Abgrenzung zwischen algorithmisch komplexen und algorithmisch einfachen Methoden ist nicht möglich.
Zur Kompositionsbeziehung zwischen Objekten vgl. Oestereich (1997), S. 205f.
Seubert unterscheidet in diesem Kontext zwischen Prozeßwissen und Objektwissen. Vgl. Seubert (1997), S. 59ff. Prozeßwissen ist das Wissen über die Ablaufsteuerung bzw. den Kontrollfluß zwischen mehreren Objekten. Objektwissen repräsentiert die Mikrostruktur und das Mikroverhalten von Systemelementen, welche sich auf ein Objekt beziehen (Struktur des Objektes, mögliche Zustände und Zustandsübergänge, Integritätsbedingungen).
Vgl. Raasch (1991), S. 393.
Vgl. dazu auch die Ausführungen in Abschnitt 3.2.1.4.
Der Begriff des Information Hiding wurde Anfang der siebziger Jahre von Parnas geprägt. Vgl. Parnas (1972) zitiert bei Balzert (1996), S. 828.
Zur Realisierung des Information Hiding in der Programmiersprache Eiffel vgl. Meyer (1997), S. 191ff. Zur Problematik des Exports von Attributen vgl. Meyer (1997), S. 204–208.
Zur Forderung, im Rahmen der fachlichen Systemspezifikation keine implementierungsrelevanten Sachverhalte zu berücksichtigen, vgl. Schienmann (1995), S. 155 und die dort zitierte Literatur.
Vgl. dazu auch Ausführungen auf S. 170. Die Notationen der verbreiteten objektorientierten Analysemethoden weisen hinsichtlich der getrennten Abbildung von Mikro- und Makroverhalten Defizite auf. Zur Abbildung von (Makro-) Verhalten in objektorientierten Analysemodellen und zu einer Bewertung der Notationen vgl. Kapitel 6.2.2.
Vgl. Schäfer (1994), S. 47ff.; Coad/Yourdon (1991), S. 79–97; Rumbaugh et al. (1991), S. 27–43; Booch (1994), S. 179ff.
Zum Unterschied zwischen Generalisierung/Spezialisierung und Vererbung vgl. Kapitel 3.2.2.
Zum Begriff und zur Verwendung von Diskriminatoren vgl. Oestereich (1997), S. 185f.
Zu ER-Modellen vgl. Kapitel 4.4.1. Zum Unterschied zwischen der Abbildung in ER-Modellen und Klassenmodellen vgl. Kapitel 6.2.1.3.
Vgl. Bungert/Heß (1995), S. 53; Rumbaugh et al. (1991), S. 58.
Das Mikroverhalten, also auf welche Attribute innerhalb einer Methode zugegriffen wird bzw. welche Nachrichten an untergeordnete Objekte gesendet werden, wird im Rahmen der fachkonzeptuellen Modellierung i. d. R. nicht explizit dokumentiert, so wie dies Abb. 3.3 suggeriert.
Der Begriff ‚Referenzmodell‘ (i. e. S.) wird hier nur für Modelle auf Fachkonzeptebene verwendet. Vgl. dazu Kapitel 4.1.1.
Vgl. Meyer (1997), S. 731ff. Die Differenzierung korrespondiert mit den Ausführungen von Monarchi und Puhr, die zwischen Klassen der Problem Domain un der Solution Domain unterscheiden. Monarchie/ Puhr(1992),S.37f.
‚Abstraktion‘ bezeichnet das Prinzip, nur die Aspekte eines Gegenstandes zu betrachten, die entsprechend einer gegebenen Zielsetzung als relevant erachtet werden.
Vgl. Meyer (1997), S. 230f.
Die Begriffe ‚Objekt‘, ‚Instanz‘, ‚Ausprägung‘ und ‚Exemplar‘ werden synonym verwendet. Der Begriff ‚Instanz‘ bzw. das zugehörige Verb ‚instanziieren‘ sind ungenaue Übersetzungen der englischen Begriffe ‚Instance‘ bzw. ‚instantiate‘.
Eine Ausnahme stellt beispielsweise die Programmiersprache SELF dar. Vgl. Ungar et al. (1991), S. 38ff. Zur Objektvererbung in objektorientierten Datenbanken vgl. Heuer (1992), S. 206.
Zur Differenzierung von Instanz- und Klassenvariablen bzw. Instanz- und Klassenmethoden vgl. Kapitel 3.2.1.1.
Zur Darstellung dieser Konzepte vgl. Heuer (1992), S. 215ff.
Vgl. Wiegert (1995), S. 132ff.
Statisch getypte objektorientierte Programmiersprachen verwenden das Typkonzept, um Inkonsistenzen bereits bei der Compilierung des Quellcodes feststellen zu können. Vgl. Meyer (1997), S. 612f.
Zur Realisierung generischer Klassen in Eiffel vgl. Meyer (1997), S. 320–330. Die Realisierung von generischen Klassen als Templates in C++ beschreibt beispielsweise Stoustrup (1991), S. 595–601.
Zu dieser Art der Architekturbildung vgl. Olofson (1996), S. 28; Object Management Group (1995), S. 25. Monarchi und Puhr unterscheiden analog zwischen Base/Utility Objects, Application Objects und Interface Objects. Die Autoren betonen jedoch nicht den engen Bezug der Application Objects zu Phänomenen der Problemdomäne. Vgl. Monarchie/Puhr (1992), S. 37f.
Vgl. Leymann (1995), S. 91. Zu den Begriffen ‚Kopplung‘ und ‚Kohäsion‘ vgl. Kappel/Schreffl (1996), S. 202ff.; Myers (1976), S. 92ff.; Hruschka (1986), S. 73.
Vgl. Ferstl/Sinz (1998), S. 160ff.; Jablonski/Stein (1995), S. 107f.; Jacobson/Ericson/Jacobson (1994), S. 116; Jacobson et al. (1992), S. 190ff; Kohl (1996), S. 70f.; Kueng/Bichler/Schrefl (1996), S. 48; Müller-Luschnat/Hesse/Heydenreich(1993), S. 82; Schwegmann/Schlagheck (1997), S. 14ff.; Taylor (1995), S. 108ff.; Turowski (1997), S. 100ff.
Zu einer Beschreibungssprache, die explizit die Trennung von Mikro- und Makroverhalten unterstützt, vgl. Kapitel 6.2.3.
Vgl. Raue (1996), S. 4; Rost (1997), S. 358.
Vgl. bspw. Adolf/Fillhardt (1993), S. 36; Yourdon et al. (1996), S. 331f. „Der Mechanismus der Vererbung wird meist als Königsweg der Anpassung objektorientierter Anwendungssysteme an kundenspezifische Bedürfhisse behandelt. “ Guntermann/Popp (1998), S. 10.
Vgl. Yourdon et al. (1996), S. 336ff. und die dort zitierte Literatur.
Zum Begriff ‚Typ‘ und ‚abstrakter Datentyp‘ vgl. Fußnoten 136 und 137.
Zumindest die konkreten Klassen einer Typvererbungshierarchie müssen jedoch disjunkt sein. In Kapitel 3.2.2.3 wird im Rahmen der View-Vererbung dargestellt, wie nicht-disjunkte, abstrakte Klassen zu konkreten Klassen komponiert werden, die einen Typ repräsentieren.
In der Literatur werden weitere Vererbungsarten unterschieden. Meyer differenziert 12 verschiedene Kategorien von Vererbungsmechanismen. Vgl. Meyer (1997), S. 822–833. Diese Kategorien lassen sich auf die Typ- und die Modulvererbung zurückfuhren. Vgl. Adolf/Fillhardt (1993), S. 40ff. Bei einer Modulvererbung werden analog zur Typvererbung Schnittstellenbeschreibungen und Code an einen Subtyp vererbt. Ziel ist es jedoch nicht, einen Typ als syntaktisch-semantische Einheit zu vererben, sondern losgelöst von fachlichen Aspekten Coderedundanzen zu vermeiden. Die Unterscheidung zwischen Typ- und Modulvererbung wird als künstlich angesehen, da sich kaum Beispiele finden lassen, in denen eine solche Differenzierung Sinn macht.
Vgl. Adolf/Fillhardt (1993), S. 40.
Prinzipiell ist das Unterdrücken ererbter Eigenschaften bei einer objektorientierten Vererbung nicht möglich. Es existieren jedoch Programmiersprachen, die um entsprechende Konstrukte erweitert wurden. Vgl. Adolf/Fillhardt (1993), S. 43.
Vgl. Quibeldey-Cirkel (1994), S. 86f. In diesem Kontext sind Klassen Gegenstand der Generalisierung bzw. Spezialisierung. Generalisierungs-/Spezialisierungsbeziehungen werden auch im Rahmen der seman-tischen Datenmodellierung zwischen Entitytypen abgebildet. Vgl. Vossen (1999), S. 95ff.; Elmasri/Navathe (1994), S. 617ff.
Zu einem Beispiel, in dem dies nicht der Fall ist, vgl. Yourdon et al. (1996), S. 337f. und die dort zitierte Literatur (insbesondere Lalonde (1991)).
Vgl. Rational et al. (Notation) (1997), S. 68ff. Oestereich (1997), S. 187f. Im Rahmen der ER-Modellierung wird zwischen totalen und partiellen Spezialisierungen differenziert. Vgl. Elmasri/Navathe (1994), S. 618ff. Eine vergleichbare Differenzierung wird bei der objektorientierten Modellierung anhand von abstrakten und konkreten Klassen vorgenommen.
Zur Auflösung von Namenskonflikten bei der Mehrfachvererbung vgl. Meyer (1997), S. 535ff.
Zu einer ausführlichen Darstellung dieser Problematik vgl. Meyer (1997), S. 519–568.
Vgl. Meyer (1997), S. 527ff.
Vgl. beispielsweise Meyer (1997), S. 522.
Auch in der Literatur wird das Konzept der Mehrfachvererbung teilweise falsch verwendet. Vgl. dazu das bei Meyer zitierte Beispiel. Vgl. Meyer (1997), S. 819f. Zur Problematik der Mehrfachvererbung vgl. auch Yourdon et al. (1996), S. 341f.
Zu Nachteilen der Anwendungssystemerweiterung durch Vererbung vgl. auch Guntermann/Popp (1998), S. 13f.
Zum Verhältnis von Aggregations- und Vererbungsbeziehungen vgl. Oestereich (1997), S. 124f.; Meyer (1997), S. 812–820 und S. 855; Adolf/Fillhardt (1993), S. 45; Gamma et al. (1996), S. 22f.
Zum Konzept der Delegation vgl. Frank/Halter (1996); Oestereich (1997), S. 191.
Streng genommen handelt es sich um eine Spezialisierung und nicht um eine Vererbung. Der Begriff der Vererbung im Sinne der OOP wird nur für disjunkte Verfeinerungen verwendet.
Vgl. Meyer (1997), S. 851–858. Eine vergleichbare Technik wird auch im Rahmen der ER-Modellierung diskutiert. Vgl. Elmasri/Navathe (1994), S. 620f.
Appelfeller (1995), S. 115. Zu den Defiziten des Vererbungsmechanismus vgl. auch Ellis/Carrol (1994), S. 54 und Lehner/Sikora (1994), S. 40. Einige Programmiersprachen wie beispielsweise C++ wurden um zusätzliche Konstrukte ergänzt, um diesen Nachteil zu vermeiden. Vgl. Adolf/Fillhardt (1993), S. 43.
Gall/Hauswirth/Klösch (1995), S. 196.
Vgl. Gall/Hauswirth/Klösch (1995), S. 196 und die dort zitierte Literatur.
Ein Container kann bei ungetypten Programmiersprachen (z. B. Smalltalk) Objekte beliebiger Klassen enthalten. Bei stark getypten Programmiersprachen (z. B. Eiffel oder C++) wird jedem Container eine Klasse zugewiesen. Der Container kann nur Exemplare dieser Klasse oder Subtypen dieser Klasse enthalten.
Der inclusion-Polymorphismus muß nicht unbedingt vererbungsgebunden sein. Objektorientierte Programmiersprachen ohne Typprüfung (z. B. Smalltalk) unterstützen auch den signaturgebundenen Polymorphismus. Um polymorphe Operationen zu realisieren, müssen die entsprechenden Klassen dann nicht in einer Vererbungshierarchie stehen. Vgl. Eisenecker (1995), S. 168.
Zu Verständnisproblemen durch dynamische Bindung vgl. Wiegert (1995), S. 198f.
Zum Single Choice-Prinzip vgl. Meyer (1997), S. 61–63.
Vgl. bspw. Peisl (1994), S. 26f.; Scholz (1994), S. 77ff. Eine Übersicht über die Beweggründe, weshalb Unternehmen Objektorientierung einsetzen, findet sich bei Kavanagh (1996), S. 275. Eine differenziertere Beurteilung der Vorteilhaftigkeit objektorientierter Systementwicklung findet sich in Lehner/Sikora (1994), S. 39ff.
Zur Vorteilhaftigkeit der objektorientierten Systementwicklung vgl. bspw. Jacobson/Ericson/Jacobson (1994), S. 68f.; Schäfer (1994), S. 60f. und die dort zitierte Literatur; Heß (1993), S. 38–44; Cox/Hunt (1986), S. 176; Dischinger (1995), S. 18ff.; Martin/Odell (1992), S. 32ff.; Kappel/Schreffl (1996), S. 58ff.; Brooks (1987), S. 14; Yourdon et al. (1996), S. 22ff.
“Die objektorientierten Metaphern der Softwaretechnik [...] rufen Assoziationen und Analogien hervor. Die rechte Hemisphäre des Gehirns wird angeregt und führt mit den algorithmischen Komponenten der linken zu einem ganzheitlichen Denken. Objektorientierung ist intuitiv: Sie unterstützt die Wahrnehmung und kognitive Verarbeitung eines Problems. Sie stellt zugleich ein ontologisches Grundprinzip dar, das geeignet ist, auch technische Artefakte einfach und ganzheitlich zu modellieren [...].” Quibeldey-Cirkel (1994), S. 14.
Vgl. Taylor (1995), S. 30f.; Dischinger (1995), S. 216 und die dort zitierte Literatur; Heß (1993), S. 38ff; Nietsch (1996), S. 124. Scholz konstatiert objektorientierten Modellen keine unbegrenzt hohe Verständlichkeit. Vgl. Scholz (1994), S. 84f.
Zum Begriff der Wiederverwendung vgl. Kapitel 5.1.1.
„What is truly revolutionary about object-oriented programming is that it helps programmers reuse existing code [...]“ Cox/Hunt (1986), S. 160. Vgl. auch Japan GUIDE/SHARE (00) (1996), S. 4ff; Heß (1993), S.42;Kauba(1996), S.21f.
Vgl. Appelfeller (1995), S. 63f.
Vgl. die zitierte Literatur in Fußnote 178.
Vgl. Raue (1996), S. 40f. und die dort zitierte Literatur.
Vgl. Meier/Röpert (1994), S. 199. Zur Diskussion von Frameworks und Design Patterns vgl. Kapitel 5.
Information hiding „enhances the reusability of components because of the isolating effect of information hiding. It allows the components to be reused in more of a black box mode, and even if modifications must be made, they are easier to make because all of the information pertaining to a specific module is organized (e.g., hidden) in that module rather than being randomly scattered about the overall design. “ Biggerstaff/ Perlis (1989), S. XX.
Vgl. Heß (1993), S. 40f. und die dort zitierte Literatur. Adolf/Fillhardt (1993), S. 36; Nietsch (1996), S. 132.
Vgl. Appelfeller (1995), S. 202ff; Quibeldey-Cirkel (1994), S. 104ff.Otterbein (1993), S. 282. Kurbel und Teubner beurteilen die Durchgängigkeit der Objektorientierung im Kontext der Neuentwicklung von Software auf Basis reorganisierter Prozesse kritisch. Vgl. Kurbel/Teubner (1996).
Die Entwicklung objektorientierter Softwaresysteme läßt sich grob in drei Phasen einteilen: Analyse, Design und Implementierung. Vgl. bspw. Nerson (1992), S. 63–74; Schäfer (1994), S. 76–77. Zur Problematik der evolutionären Softwareentwicklung vgl. Hesse (1997), S. 21–28.
Zu einer Liste, welche Aspekte beim Übergang von der Analyse zum Design zu betrachten sind, vgl. Schader/Rundshagen (1994), S. 140f.
Vgl. Raasch (1991), S. 393.
Vgl. Meyer (1997), S. 22f.
Die von Meyer entwickelte Programmiersprache Eiffel enthält Sprachkonstrukte, um die Semantik von Klassen bzw. Klassenschnittstellen beschreiben zu können und um dadurch eine fehlerfreie Spezifikation von Klassen zu ermöglichen. Vgl. Meyer (1997), S. 331–410. Die Art der Spezifikation mit Vor-, Nachbedingungen, Invarianten usw. ist jedoch sehr formal und daher kaum für Fachanwender verständlich.
Rights and permissions
Copyright information
© 1999 Betriebswirtschaftlicher Verlag Dr. Th. Gabler GmbH, Wiesbaden, und Deutscher Universitäts-Verlag GmbH, Wiesbaden
About this chapter
Cite this chapter
Schwegmann, A. (1999). Grundlagen der Objektorientierung. In: Objektorientierte Referenzmodellierung. Informationsmanagement und Controlling. Deutscher Universitätsverlag, Wiesbaden. https://doi.org/10.1007/978-3-322-99774-6_3
Download citation
DOI: https://doi.org/10.1007/978-3-322-99774-6_3
Publisher Name: Deutscher Universitätsverlag, Wiesbaden
Print ISBN: 978-3-8244-7014-3
Online ISBN: 978-3-322-99774-6
eBook Packages: Springer Book Archive