Advertisement

Grundlagen der Objektorientierung

  • Ansgar Schwegmann
Part of the Informationsmanagement und Controlling book series (IMC)

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.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. 111.
    Vgl. Hesse et al. (Teil 1) (1994), S. 42.Google Scholar
  2. 112.
    Vgl. Kosiol (1962), S.50ff.Google Scholar
  3. 113.
    Vgl. Bühner (1989), S. 10.Google Scholar
  4. 114.
    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.Google Scholar
  5. 115.
    „Unter der Aufbauorganisation wird die Festlegung der Aufgabe nach den Merkmalen der Verrichtung und des Objekts verstanden. “ Bühner (1989), S. 11.Google Scholar
  6. 116.
    Zur Gruppierung ist auch die Verwendung von Ausgangsobjekten (Rohstoffe, Zwischenprodukte, Dienstleistungen usw.) oder Arbeitsmittel (Werkzeuge, Transportmittel usw.) denkbar. Vgl. Kosiol (1962), S. 50f.Google Scholar
  7. 117.
    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.Google Scholar
  8. 118.
    „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.Google Scholar
  9. 119.
    Vgl. Davenport (1993); Hammer/Champy (1993); Gaitanides (1992), S. 15–16.Google Scholar
  10. 120.
    Rosemann (Komplexität) (1996), S. 9.Google Scholar
  11. 121.
    Vgl. Rosemann (Komplexität) (1996), S. 8ff. und S. 76–84.Google Scholar
  12. 122.
    Vgl. zu den folgenden Ausführungen Becker (Objektorientierung) (1991), S. 136ff.Google Scholar
  13. 123.
    Zu einer ausführlichen Darstellung der Entwicklung der Objektorientierung in der Informatik vgl. beispielsweise Dischinger (1995), S. 4–17.Google Scholar
  14. 124.
    Vgl. Schäfer (1994), S. 57ff.; Appelfeller (1995), S. 17; FerstVSinz (1993), S. 2.Google Scholar
  15. 125.
    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).Google Scholar
  16. 126.
    Vgl. Becker (Objektorientierung) (1991), S. 142ff.Google Scholar
  17. 127.
    Ein Überblick und Vergleich der Konzepte verschiedener objektorientierter Programmiersprachen findet sich beispielsweise in Gall/Hauswirth/Klösch (1995); Srinivasan/Jayaraman (1994).Google Scholar
  18. 128.
    Meyer unterscheidet beispielsweise sieben Stufen der Objektorientierung. Vgl. Meyer (1990), S. 65ff.Google Scholar
  19. 129.
    Zu einer Einführung in die Technologie objektorientierter Datenbanken vgl. Heuer (1992); Unland (1995).Google Scholar
  20. 130.
    Zur Entwicklung objektorientierter Datenbanken vgl. Unland (1995), S. 9ff.Google Scholar
  21. 131.
    Vgl. Lausen/Vossen (1996), S. 7; Heuer (1992), S. 125f.Google Scholar
  22. 132.
    Vgl. Dischinger (1995), S. 12.Google Scholar
  23. 133.
    Vgl. Balzert (1996), S. 468ff.Google Scholar
  24. 134.
    Meyer (1997), S. 218.Google Scholar
  25. 135.
    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.Google Scholar
  26. 136.
    „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.Google Scholar
  27. 137.
    Zum Begriff des abstrakten Datentyps vgl. Balzert (1996), S. 859f. und die dort zitierte Literatur.Google Scholar
  28. 138.
    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.Google Scholar
  29. 139.
    Zur unterschiedlichen Verwendung des Objektbegriffes vgl. Coad/Yourdon (1991), S. 30.Google Scholar
  30. 140.
    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.Google Scholar
  31. 141.
    Zu einer umfassenden Einführung in die Konzepte des objektorientierten Paradigmas vgl. bspw. Meyer (1997); Quibeldey-Cirkel (1994).Google Scholar
  32. 142.
    Vgl.Vossen(1999), S. 268.Google Scholar
  33. 143.
    Vgl. Schwegmann/Schlagheck (1997), S. 21f.Google Scholar
  34. 144.
    Zur Verwendung des Strukturbegriffes vgl. Fußnote 10.Google Scholar
  35. 145.
    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.Google Scholar
  36. 146.
    Zur Differenzierung von Instanz- und Klassenvariablen bzw. Instanz- und Klassenmethoden vgl. Meyer (1997), S. 168f.; Booch(1994), S. 133f.Google Scholar
  37. 147.
    Zum Begriff der Vererbung und zu den Arten von Vererbungsbeziehungen vgl. Abschnitt 3.2.2.Google Scholar
  38. 148.
    Vgl. Meyer (1997), S. 134f.; Coad/Yourdon (1991), S. 146ff. Eine trennscharfe Abgrenzung zwischen algorithmisch komplexen und algorithmisch einfachen Methoden ist nicht möglich.Google Scholar
  39. 149.
    Zur Kompositionsbeziehung zwischen Objekten vgl. Oestereich (1997), S. 205f.Google Scholar
  40. 150.
    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).Google Scholar
  41. 151.
    Vgl. Raasch (1991), S. 393.Google Scholar
  42. 152.
    Vgl. dazu auch die Ausführungen in Abschnitt 3.2.1.4.Google Scholar
  43. 153.
    Der Begriff des Information Hiding wurde Anfang der siebziger Jahre von Parnas geprägt. Vgl. Parnas (1972) zitiert bei Balzert (1996), S. 828.Google Scholar
  44. 154.
    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.Google Scholar
  45. 155.
    Zur Forderung, im Rahmen der fachlichen Systemspezifikation keine implementierungsrelevanten Sachverhalte zu berücksichtigen, vgl. Schienmann (1995), S. 155 und die dort zitierte Literatur.Google Scholar
  46. 156.
    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.Google Scholar
  47. 157.
    Vgl. Schäfer (1994), S. 47ff.; Coad/Yourdon (1991), S. 79–97; Rumbaugh et al. (1991), S. 27–43; Booch (1994), S. 179ff.Google Scholar
  48. 158.
    Zum Unterschied zwischen Generalisierung/Spezialisierung und Vererbung vgl. Kapitel 3.2.2.Google Scholar
  49. 159.
    Zum Begriff und zur Verwendung von Diskriminatoren vgl. Oestereich (1997), S. 185f.Google Scholar
  50. 160.
    Zu ER-Modellen vgl. Kapitel 4.4.1. Zum Unterschied zwischen der Abbildung in ER-Modellen und Klassenmodellen vgl. Kapitel 6.2.1.3.Google Scholar
  51. 161.
    Vgl. Bungert/Heß (1995), S. 53; Rumbaugh et al. (1991), S. 58.Google Scholar
  52. 162.
    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.Google Scholar
  53. 163.
    Der Begriff ‚Referenzmodell‘ (i. e. S.) wird hier nur für Modelle auf Fachkonzeptebene verwendet. Vgl. dazu Kapitel 4.1.1.Google Scholar
  54. 164.
    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.Google Scholar
  55. 165.
    ‚Abstraktion‘ bezeichnet das Prinzip, nur die Aspekte eines Gegenstandes zu betrachten, die entsprechend einer gegebenen Zielsetzung als relevant erachtet werden.Google Scholar
  56. 166.
    Vgl. Meyer (1997), S. 230f.Google Scholar
  57. 167.
    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‘.Google Scholar
  58. 168.
    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.Google Scholar
  59. 169.
    Zur Differenzierung von Instanz- und Klassenvariablen bzw. Instanz- und Klassenmethoden vgl. Kapitel 3.2.1.1.Google Scholar
  60. 170.
    Zur Darstellung dieser Konzepte vgl. Heuer (1992), S. 215ff.Google Scholar
  61. 171.
    Vgl. Wiegert (1995), S. 132ff.Google Scholar
  62. 172.
    Statisch getypte objektorientierte Programmiersprachen verwenden das Typkonzept, um Inkonsistenzen bereits bei der Compilierung des Quellcodes feststellen zu können. Vgl. Meyer (1997), S. 612f.Google Scholar
  63. 173.
    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.Google Scholar
  64. 174.
    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.Google Scholar
  65. 175.
    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.Google Scholar
  66. 176.
    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.Google Scholar
  67. 177.
    Zu einer Beschreibungssprache, die explizit die Trennung von Mikro- und Makroverhalten unterstützt, vgl. Kapitel 6.2.3.Google Scholar
  68. 178.
    Vgl. Raue (1996), S. 4; Rost (1997), S. 358.Google Scholar
  69. 179.
    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.Google Scholar
  70. 180.
    Vgl. Yourdon et al. (1996), S. 336ff. und die dort zitierte Literatur.Google Scholar
  71. 181.
    Zum Begriff ‚Typ‘ und ‚abstrakter Datentyp‘ vgl. Fußnoten 136 und 137.Google Scholar
  72. 182.
    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.Google Scholar
  73. 183.
    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.Google Scholar
  74. 184.
    Vgl. Adolf/Fillhardt (1993), S. 40.Google Scholar
  75. 185.
    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.Google Scholar
  76. 186.
    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.Google Scholar
  77. 187.
    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)).Google Scholar
  78. 188.
    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.Google Scholar
  79. 189.
    Zur Auflösung von Namenskonflikten bei der Mehrfachvererbung vgl. Meyer (1997), S. 535ff.Google Scholar
  80. 190.
    Zu einer ausführlichen Darstellung dieser Problematik vgl. Meyer (1997), S. 519–568.Google Scholar
  81. 191.
    Vgl. Meyer (1997), S. 527ff.Google Scholar
  82. 192.
    Vgl. beispielsweise Meyer (1997), S. 522.Google Scholar
  83. 193.
    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.Google Scholar
  84. 194.
    Zu Nachteilen der Anwendungssystemerweiterung durch Vererbung vgl. auch Guntermann/Popp (1998), S. 13f.Google Scholar
  85. 195.
    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.Google Scholar
  86. 196.
    Zum Konzept der Delegation vgl. Frank/Halter (1996); Oestereich (1997), S. 191.Google Scholar
  87. 197.
    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.Google Scholar
  88. 198.
    Vgl. Meyer (1997), S. 851–858. Eine vergleichbare Technik wird auch im Rahmen der ER-Modellierung diskutiert. Vgl. Elmasri/Navathe (1994), S. 620f.Google Scholar
  89. 199.
    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.Google Scholar
  90. 200.
    Gall/Hauswirth/Klösch (1995), S. 196.Google Scholar
  91. 201.
    Vgl. Gall/Hauswirth/Klösch (1995), S. 196 und die dort zitierte Literatur.Google Scholar
  92. 202.
    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.Google Scholar
  93. 203.
    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.Google Scholar
  94. 204.
    Zu Verständnisproblemen durch dynamische Bindung vgl. Wiegert (1995), S. 198f.Google Scholar
  95. 205.
    Zum Single Choice-Prinzip vgl. Meyer (1997), S. 61–63.Google Scholar
  96. 206.
    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.Google Scholar
  97. 207.
    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.Google Scholar
  98. 208.
    “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.Google Scholar
  99. 209.
    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.Google Scholar
  100. 210.
    Zum Begriff der Wiederverwendung vgl. Kapitel 5.1.1.Google Scholar
  101. 211.
    „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.Google Scholar
  102. 212.
    Vgl. Appelfeller (1995), S. 63f.Google Scholar
  103. 213.
    Vgl. die zitierte Literatur in Fußnote 178.Google Scholar
  104. 214.
    Vgl. Raue (1996), S. 40f. und die dort zitierte Literatur.Google Scholar
  105. 215.
    Vgl. Meier/Röpert (1994), S. 199. Zur Diskussion von Frameworks und Design Patterns vgl. Kapitel 5.Google Scholar
  106. 216.
    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.Google Scholar
  107. 217.
    Vgl. Heß (1993), S. 40f. und die dort zitierte Literatur. Adolf/Fillhardt (1993), S. 36; Nietsch (1996), S. 132.Google Scholar
  108. 218.
    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).Google Scholar
  109. 219.
    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.Google Scholar
  110. 220.
    Zu einer Liste, welche Aspekte beim Übergang von der Analyse zum Design zu betrachten sind, vgl. Schader/Rundshagen (1994), S. 140f.Google Scholar
  111. 221.
    Vgl. Raasch (1991), S. 393.Google Scholar
  112. 222.
    Vgl. Meyer (1997), S. 22f.Google Scholar
  113. 223.
    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.Google Scholar

Copyright information

© Betriebswirtschaftlicher Verlag Dr. Th. Gabler GmbH, Wiesbaden, und Deutscher Universitäts-Verlag GmbH, Wiesbaden 1999

Authors and Affiliations

  • Ansgar Schwegmann

There are no affiliations available

Personalised recommendations