Advertisement

Wiederverwendungsorientierte Systementwicklung

  • Karin Küffmann
Chapter
  • 38 Downloads
Part of the Programm Angewandte Informatik book series (PAI)

Zusammenfassung

In diesem Kapitel werden die grundlegenden Entwurfsprinzipien wiederverwendungs-orientierter Softwareentwicklung vorgestellt. Sie bilden die Grundlage für die in Kapitel 4 dargestellten Ansätze. Die Entwicklung von Software — insbesondere wiederverwendbarer — kann als schlecht strukturierte Aufgabe charakterisiert werden. “Die Ergebnisse der Software-Engineering-Forschung ergeben heute noch kein einheitliches Bild; es handelt sich vielmehr um ein heterogenes Konglomerat von Ratschlägen, Vorgehensweisen, Techniken, Methoden und Software-Werkzeugen”131. Daher können in der Systementwicklung immer nur als richtig empfundene, in der Praxis erprobte Leitlinien, nie aber der Lösungsweg an sich vorgegeben werden. Im folgenden werden zunächst die wichtigsten Entwurfsprinzipien der Systementwicklung und ein Vorgehensmodell behandelt, bevor die wiederverwendungsorientierte Entwicklung dargestellt wird.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. 131.
    Vgl. Wirtz, K.-W. /Software-Engineering/ S. 388.Google Scholar
  2. 132.
    Vgl. Schulz, A. /Software-Entwurf/ S. 14f.Google Scholar
  3. 133a.
    Ygi Balzert, H. /Allgemeine Prinzipien/ S. 2ff.Google Scholar
  4. 133b.
    Vgl. Martin, J.; McClure, С /CASE/ S. 33, S. 42, S. 18f.Google Scholar
  5. 133c.
    Vgl. Stahlknecht, P. /Einfuhrung in die Wirtschaftsinformatik/ S. 259.Google Scholar
  6. 133d.
    Vgl. Hausen, H.; Müllerburg, M; Schmidt, M. /Prüfen, Messen und Bewerten/ S. 136.Google Scholar
  7. 133e.
    Vgl. Scheibl, H.-J. /Kommerzielle Software-Entwicklung/ S. 72.Google Scholar
  8. 133f.
    Vgl. Stevens, W.; Myers, G.; Constantine, L. /Structured Design/ S. 116f.Google Scholar
  9. 133g.
    Vgl. Balzert, H. /Ökonomische Software-Wartung/ S. 57ff.Google Scholar
  10. 134a.
    Vgl. Parnas, D.; Clements, P.; Weiss, D. /Enhancing Reusability/ S. 83.Google Scholar
  11. 134b.
    Vgl. Booch, G. /Object Oriented Design/ S. 52.Google Scholar
  12. 134c.
    Vgl. Kurbel, K. /Datenabstraktion und Modularisierung/ S. 127.Google Scholar
  13. 134d.
    Vgl. Alten, W. /Industrielle Software-Produktion/ S. 173.Google Scholar
  14. 134e.
    Vgl. Wirth, N. /Program Development/ S. 221.Google Scholar
  15. 134f.
    Vgl. Denert, E. /Softwareentwicklung/ S. 212.Google Scholar
  16. 134g.
    Vgl. Pressman, R. /Software Engineering/ S. 223.Google Scholar
  17. 134h.
    Vgl. Booch /Object oriented Design/ S. 51.Google Scholar
  18. 134i.
    Vgl. Parnas, D.; Clements, P.; Weiss, D. /Enhancing Reusability/ S. 83.Google Scholar
  19. 135.
    Vgl. Stevens, W.; Myers, G.; Constantine, L. /Structured Design/ S. 117.Google Scholar
  20. 136a.
    Vgl. Denert, E. /Softwareentwicklung/ S. 213.Google Scholar
  21. 136b.
    Vgl. Endres, A. /Grundlagen der Software-Wiederverwendung/ S. 6.Google Scholar
  22. 136c.
    Vgl. Parnas, D.; Clements, P.; Weiss, D. /Enhancing Reusability with Information Hiding/ S. 143.Google Scholar
  23. 136d.
    Vgl. Stevens, W.; Myers, G.; Constantine, L. /Structured Design/ S. 116.Google Scholar
  24. 136e.
    Vgl. Parnas, D.; Clements, P.; Weiss, D. /Enhancing Reusability/ S. 83.Google Scholar
  25. 136f.
    Vgl. Martin, J.; McClure, С /CASE/ S. 69.Google Scholar
  26. 136g.
    Vgl. Burns, Kevin /Using Automated Techniques/ S. 183.Google Scholar
  27. 137.
    Vgl. Scheibl, H.-J. /Kommerzielle Softwareentwicklung/ S. 485.Google Scholar
  28. 138.
    Vgl. Wegner, P. /Varieties of Reusability/ S. 24.Google Scholar
  29. 139.
    Vgl. Berzins, V.; Gray, M.; Naumann, D. /Abstraction-Based Software Development/ S. 413.Google Scholar
  30. 140.
    Vgl. Schönthaler, F.; Németh, T. /Software-Entwicklungswerkzeuge/ S. 16.Google Scholar
  31. 141.
    Vgl. Endres, A. /Grundlagen der Software-Wiederverwendung/ S. 5.Google Scholar
  32. 142.
    Vgl. Futatsugi, K.; Goguen, J.; Meseguer, J.; Okada, K. /Parameterized Programming/ S. 337.Google Scholar
  33. 143.
    Vgl. Würges /Parameter/ S. 573.Google Scholar
  34. 144.
    Ygj futatsugi, K.; Goguen, J.; Meseguer, J.; Okada, K. /Parameterized Programming/ S. 337.Google Scholar
  35. 145a.
    Vgl. Deutsch, L. P. /Reusability in Smalltalk-80/ S. 91.Google Scholar
  36. 145b.
    Vgl. Meyer, B. /Eiffel; Reusability and Reliability/ S. 222.Google Scholar
  37. 145c.
    Vgl. Deutsch, L. P. /Reusability in Smalltalk-80/ S. 91.Google Scholar
  38. 145d.
    Vgl. Druffel, L. /Potential Effect of Ada/ S. 139.Google Scholar
  39. 146.
    Vgl. Booch, G. /Object Oriented Design/ S. 45.Google Scholar
  40. 147.
    S. Booch, G. /Object Oriented Design/ S. 54.Google Scholar
  41. 148.
    Vgl. Schönthaler, F. /Németh, T. /Software-Entwicklungswerkzeuge/ S. 15.Google Scholar
  42. 149.
    Vgl. Seibt, D. /Phasenkonzept/ S. 327.Google Scholar
  43. 150.
    Vgl. Seibt, D. /Phasenkonzept/ S. 326.Google Scholar
  44. 151a.
    Vgl. Seibt, D. /Phasenkonzept/ S. 326.Google Scholar
  45. 151b.
    Vgl. Nagl, M. /Softwaretechnik/ S. 50. In späteren Phasen erweist sich beispielsweise der geplante Detaillierungsgrad als zu genau und nicht notwendig, so daß in der vorhergehenden Phase die entsprechenden Unterlagen geändert werden müssenGoogle Scholar
  46. 152.
    Vgl. Bröhl, A.-P.; Dröschel, W. (Hrsg.) /Das V-Modell/Google Scholar
  47. 153.
    Vgl. Denert, E. /Software-Engineering/ S. 49ff.Google Scholar
  48. 154.
    Vgl. Seibt, D. /Phasenkonzept/ S. 328.Google Scholar
  49. 155a.
    Vgl. Nagl, M. /Softwaretechnik/ S. 50.Google Scholar
  50. 155b.
    Vgl. Boehm, B. /Wirtschaftliche Software-Produktion/ S. 30ff.Google Scholar
  51. 155c.
    Vgl. Speek, J. /Erhöhung der Software/ S. 90f.Google Scholar
  52. 156.
    Vgl. Denert, E. /Software-Engineering/ S. 36f.Google Scholar
  53. 157.
    Vgl. Denert, E. /Software-Engineering/ S. 39ff.Google Scholar
  54. 158.
    Vgl. Denert, E. /Software-Engineering/ S. 46f.Google Scholar
  55. 159.
    Vgl. Denert, E. /Software-Engineering/ S. 116.Google Scholar
  56. 160.
    Vgl. Denert, E. /Software-Engineering/ S. 45.Google Scholar
  57. 161.
    Vgl. Denert, E. /Software-Engineering/ S. 48.Google Scholar
  58. 162.
    Voraussetzung ist die Konsistenz, Aktualität und Qualität der Produkte, damit sie überhaupt genutzt werden. Die definierten Ergebnisse müssen mit den gleichen Entwicklungsmethoden, Entwurfsprinzipien und -verfahren erstellt werden, damit sie vergleichbar sind.Google Scholar
  59. 163.
    Vgl. Levendel, Y. /Improving Quality/ S. 13.Google Scholar
  60. 164.
    Vgl. Matsumoto, Y. /A Software Factory/ S. 156ff. Ein Beispiel für ein abgegrenztes Phasenschemata ist das Life-Cycle-Model von Matsumoto, das auf dem standardisierten Life-Cycle Model (ANSI/IEEE Std. 828–1983) aufbaut. Zwischen den Phasen sind festgelegte “baselines” definiert, an denen eine Qualitätskontrolle stattfindet (Design Review, Test Inspection, Control of Configuration). So orientieren sich alle Mitarbeiter der Software-Factory auch projektübergreifend an der gleichen Definition der Phasen, der gleichen Kontrolle. Damit sind die Voraussetzungen zur Produktion vergleichbarer Produkte gegeben.Google Scholar
  61. 165.
    Vgl. Rugaber, S.; Ornburn, S.; LeBlanc, R./ Recognizing/ S. 46f.Google Scholar
  62. 166.
    Vgl. Rugaber, S.; Ornburn, S.; LeBlanc, R/ Recognizing/ S. 46f.Google Scholar
  63. 167.
    Vgl. Denert, E. /Software-Engineering/S. 222.Google Scholar
  64. 168.
    Vgl. Haberman, A.; Flon, L.; Cooprider, L. /Modularization and Hierarchy/ S. 267.Google Scholar
  65. 169.
    Vgl. Gietl, J. /Software-Baukasten/ S. 129.Google Scholar
  66. 170.
    Vgl. Haberman, A.; Flon, L.; Cooprider, L. /Modularization and Hierarchy/ S. 268.Google Scholar
  67. 171.
    Vgl. Gietl, J./Software-Baukasten/ S. 128.Google Scholar
  68. 172.
    Vgl. Gietl, J./Software-Baukasten/ S. 129.Google Scholar
  69. 173.
    Vgl. Kernighan, В. /The Unix System/ S. 149.Google Scholar
  70. 174.
    Vgl. Denert, E. /Software-Engineering/ S. 55.Google Scholar
  71. 175.
    Vgl. Denert, E. /Software-Engineering/ S. 55.Google Scholar
  72. 176.
    Vgl. Denert, E. /Software-Engineering/ S. 223.Google Scholar
  73. 177.
    Vgl. Denert, E. /Software-Engineering/ S. 57ff.Google Scholar
  74. 178.
    Vgl. Denert, E. /Software-Engineering/ S. 221ff.Google Scholar
  75. 179.
    Vgl. Denert, E. /Software-Engineering/ S. 222ff.Google Scholar
  76. 180.
    Vgl. Denert, E. /Software-Engineering/ S. 222ff.Google Scholar
  77. 181.
    Vgl. Kapitel 2.5.3.Google Scholar
  78. 182.
    Vgl. Parnas, D. /Designing Software/ S. 128f.Google Scholar
  79. 183.
    Vgl. Haberman, A.; Flon, L.; Cooprider, L. /Modularization and Hierarchy/ S. 266.Google Scholar
  80. 184.
    Vgl. Parnas, D. /On the Design and Development of Program Families/ S. 1.Google Scholar
  81. 185.
    Vgl. Wirth, N. /Program Development/ S. 221.Google Scholar
  82. 186.
    Vgl. Wirth, N. /Program Development/ S. 221.Google Scholar
  83. 187.
    Vgl. Parnas, D. /On the Design and Development of Program Families/ S. 128ff.Google Scholar
  84. 188.
    Vgl. Parnas, D. /On the Design and Development of Program Families/ S. 3.Google Scholar
  85. 189.
    Vgl. Parnas, D. /Designing Software/ S. 244.Google Scholar
  86. 190.
    Vgl. Haberman, A.; Flon, L.; Cooprider, L. /Modularization and Hierarchy/ S. 266.Google Scholar
  87. 191.
    Vgl. Parnas, D.; Clements, P.; Weiss, D. /Enhancing Reusability/ S. 84.Google Scholar
  88. 192.
    Vgl. Parnas, D.; Clements, P.; Weiss, D. /Enhancing Reusability/ S. 84.Google Scholar
  89. 193.
    S. Haberman, A.; Flon, L.; Cooprider, L. /Modularization and Hierarchy/ S. 267.Google Scholar
  90. 194.
    Vgl. Haberman, Flon, Cooprider/Modularization and Hierarchy/S. 266.Google Scholar
  91. 195.
    Parnas schlägt zwei Wege der Entwicklung der Design-Familien vor: 1. Stepwise Refinement von Dijkstra, dann 2. eine Entwicklung nach dem Prinzip des Information Hiding, die die anderen Modulforderungen durchaus einschließen kann.Google Scholar
  92. 196.
    Der Modulkatalog dient auch als Nachschlagewerk für Wartung und Wiederverwendung.Google Scholar
  93. 197.
    S. Denert, E. /Software-Engineering/ S. 220.Google Scholar
  94. 198.
    Vgl. Denert, E. /Software-Engineering/ S. 220.Google Scholar
  95. 199.
    Vgl. Denert, E. /Software-Engineering/ S. 220.Google Scholar
  96. 200.
    Vgl. Scheibl, H.-J. /Kommerzielle Software-Entwicklung/ S. 72.Google Scholar
  97. 201.
    Vgl. Martin, J.; McClure, С /CASE/ S. 67fGoogle Scholar
  98. 202.
    S. Heinrich, L.J.; Roithmayr, F. /Komponente/ S. 271.Google Scholar
  99. 203.
    S. Booch, G. /Software Components/ S. 7.Google Scholar
  100. 204.
    Vgl. Denert, E. /Software-Engineering/ S. 220.Google Scholar
  101. 205a.
    Vgl. Sommerville, J. /Software Engineering/ S. 185.Google Scholar
  102. 205b.
    Vgl. Wegener, P. /Varieties of Reusability/ S. 28.Google Scholar
  103. 205c.
    Vgl. Denert, E. /Software-Engineering/ S. 220.Google Scholar
  104. 206.
    S. Wegener, P. /Varieties of Reusability/ S. 28.Google Scholar
  105. 207.
    Vgl. Sommerville, J. /Software-Engineering/ S. 185.Google Scholar
  106. 208.
    Vgl. Wegener, P. /Varieties of Reusability/ S. 28.Google Scholar
  107. 209.
    Vgl. Denert, E. /Software-Engineering/ S. 220.Google Scholar
  108. 210a.
    Vgl. Scheibl, H.-J. /Kommerzielle Software-Entwicklung/ S. 71.Google Scholar
  109. 210b.
    Vgl. Wegner, P. /Varieties of Reusability/ S. 28.Google Scholar
  110. 211.
    Vgl. Alten, W. flndustrielle Software-Produktion/ S. 173.Google Scholar
  111. 212.
    Vgl. Wegener, P. /Varieties of Reusability/ S. 28.Google Scholar
  112. 213.
    Vgl. Denert, E. /Software-Engineering/ S. 220.Google Scholar
  113. 214.
    Vgl. Wegner, P. /Varieties of Reusability/ S. 27.Google Scholar
  114. 215.
    Vgl. Rich, С; Waters, R. /Formalizing Reusable Software Components/ S. 315.Google Scholar
  115. 216a.
    Vgl. McCain, R. /Software development methodology/ S. 320.Google Scholar
  116. 216b.
    Vgl. Goguen, J. /Reusing and Interconnecting/ S. 251ff.Google Scholar
  117. 217.
    Vgl. Rich, C; Waters, R. /Formalizing Reusable Software Components/ S. 315.Google Scholar
  118. 218.
    Vgl. Rich, C; Waters, R. /Formalizing Reusable Software Components/ S. 316f.Google Scholar
  119. 219.
    Vgl. Wirsing, M. /Reusable Specifications Components/ S. 2.Google Scholar
  120. 220.
    Vgl. Emery, J. /Small-Scale Software Components/ S. 20.Google Scholar
  121. 221.
    Vgl. Denert, E. /Software-Engineering/ S. 316.Google Scholar
  122. 222.
    Vgl. Rich C., Waters, R. /Formalizing Reusable software components/ S. 316.Google Scholar
  123. 223.
    Vgl. McCain, R. /Software Development Methodology/ S. 320.Google Scholar
  124. 224.
    Vgl. Scheibl, H.-J. /Kommerzielle Software-Entwicklung/ S. 83f.Google Scholar
  125. 225.
    Vgl. Denert, E. /Software-Engineering/ S. 350.Google Scholar
  126. 226a.
    Vgl. Page-Jones, M. /Structured Systems Design/ S. 58f.Google Scholar
  127. 226b.
    Vgl. Stevens, W.; Myers, G.; Constantine, L. /Structured Design/ S. 115ff.Google Scholar
  128. 227.
    Vgl. Selby, R. /Quantitative Studies of Software Reuse/ S. 227f.Google Scholar
  129. 228.
    Vgl. McCain, R. /Software Development Methodology/ S. S. 320.Google Scholar
  130. 229.
    Vgl. Denert, E. /Software-Engineering/ S. 86.Google Scholar
  131. 230.
    Vgl. Kurbel, K. /Datenabstraktion und Modularisierung/ S. 128.Google Scholar
  132. 231a.
    Vgl. Braun, U., Schmid, H. /Wiederverwendbare ADT/ S. 165.Google Scholar
  133. 231b.
    Vgl. Pepper, P. et. al. /Abstrakte Datentypen/ S. 108.Google Scholar
  134. 232.
    Vgl. Liskov, В.; Zilles, S. /Specification Techniques/ S. 21.Google Scholar
  135. 233.
    Vgl. Braun, U., Schmid, H. /Wiederverwendbare ADT/ S. 166.Google Scholar
  136. 234.
    Vgl. Broy, M. et. al. /Abstrakte Datentypen/ S. 189.Google Scholar
  137. 235.
    Vgl. Braun, U, Schmid, H. /Wiederverwendbare ADT/ S. 166.Google Scholar
  138. 236.
    Vgl. Denert, E. /Software-Engineering/ S. 218.Google Scholar
  139. 237a.
    Vgl. Pepper, P. et. al. /Abstrakte Datentypen/ S. 108.Google Scholar
  140. 237b.
    Vgl. Liskov, В.; Zilles, S. /Specification Techniques/ S. 21.Google Scholar
  141. 237c.
    Vgl. Nehmer, J. /Monitorkonzept/ S. 272.Google Scholar
  142. 238.
    Vgl. Meyer, B. /Reusability/ S. 9.Google Scholar
  143. 239.
    Vgl. Braun, U., Schmid, H. /Wiederverwendbare ADT/ S. 165.Google Scholar
  144. 240.
    Vgl. Braun, U, Schmid, H. /Wiederverwendbare ADT/ S. 173.Google Scholar
  145. 241.
    Vgl. Kurbel, K. /Datenabstraktion/ S. 135f.Google Scholar
  146. 242.
    Vgl. Meyer, В. /Reusability: The Case for Object-Oriented Design/ S. 203.Google Scholar
  147. 243.
    Vg. Meyer, B. /Eiffel; Reusability and Reliability/ S. 218.Google Scholar
  148. 244.
    Vgl. Nawrot, B. /objectiF/ S. 4.Google Scholar
  149. 245a.
    Vgl. Schmitz, L. /Wiederverwendbarkeit von Software/ S. 72.Google Scholar
  150. 245b.
    Vgl. Meyer, В. /Objektorientierte Software-Entwicklung/ S. 241.Google Scholar
  151. 245c.
    Vgl. Meyer, B. /Eiffel: Reusability and Reliability/ S. 223.Google Scholar
  152. 246.
    Vgl. Booch, G. /Object Oriented Design/ S. 39ff.Google Scholar
  153. 247.
    Vgl. Booch, G. /Object Oriented Design/ S. 59.Google Scholar
  154. 248.
    Vgl. Deutsch, L. /Reusability in Smalltalk-80/ S. 91.Google Scholar
  155. 249.
    Vgl. Nawrot, B. /Objectif/Google Scholar
  156. 250.
    Vgl. Dermic R. /Reusable Ada Software Guidelines/ S. 257. Es enthält verschiedene Wiederverwendbar-keitsmerkmale, sprachunabhängige Charakteristika zur Durchführung dieser Merkmale und Richtlinien für die Implementierung enthältGoogle Scholar
  157. 251.
    Vgl. Dennis, R. /Reusable Ada Software Guidelines/ S. 259.Google Scholar
  158. 252.
    Unter Teilen werden im folgenden alle wiederverwendbaren Informationen (Wissen, Spezifikationen, Design und Module usw.) verstanden. Es kann sich also um Bausteine oder auch Bauteile handeln.Google Scholar
  159. 253.
    Vgl. Rice, J.; Schwetman, H. /Interface Issues/ S. 128.Google Scholar
  160. 254.
    Vgl. Rice, J.; Schwetman, H. /Interface Issues/ S. 102.Google Scholar
  161. 255.
    Vgl. Rice, J.; Schwetman, H. /Interface Issues/ S. 129. Ein semantischer Check ist zur Compilationszeit nicht durchzuführen, da die Datentypen erst später initialisiert werden und möglicherweise auch der Code nicht vollständig ist. Eine semantische Überprüfung ist zur Ladezeit sinnvoller, wenn der Code vollständig vorliegt und die Argumente individuell auf den korrekten Typ geprüft werden.Google Scholar
  162. 256.
    Aird, T.; Rice, J/ PROTRAN/ PROTRAN ist ein System, das auf Fortran aufbaut, Problemlösungsfähigkeiten ergänzt und Programme aus einer Bibliothek nutzt; diese werden inline aufgerufen, so daß einige syntaktische Probleme von Anfang an vermieden werden. Bei Auftreten von Fehlern wird das Bauteil nicht in das Programm integriert. Zur Ausführzeit wird das Programm erneut auch auf Problemformulierung und numerische Fehler inhaltlich geprüft. PROTRAN weist einen Syntax- und Semantikcheck auf.Google Scholar
  163. 257.
    Rice/Schwetman schlagen eine Interface-Spezifikationsstruktur vor, die den automatischen Check von Interface-Informationen möglich macht. Da diese Spezifikation nicht getestet wurde, soll hier nicht weiter darauf eingegangen werden. Die Durchsetzbarkeit solcher Interface-Spezifikationen wird aufgrund des damit verbundenen hohen Speicher- und CPU-Bedarfs schwierig sein.Google Scholar

Copyright information

© Friedr. Vieweg & Sohn Verlagsgesellschaft mbH, Braunschweig/Wiesbaden 1994

Authors and Affiliations

  • Karin Küffmann

There are no affiliations available

Personalised recommendations