Advertisement

Ansätze zur Wiederverwendung

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

Zusammenfassung

Die Softwareentwicklung wird zum einen durch die Wiederverwendung von Software(-teilen) aus frühen Entwurfsstufen und zum anderen durch den häufigen Einsatz von Bauteilen qualitativ hochwertiger und produktiver. Durch häufige Nutzung der bestehenden Entwicklungsprodukte und -bauteile wird eine frühere Amortisation dieser Investitionen erreicht. Daher sollte das Augenmerk auf der Entwicklung wiederverwendbarer Entwicklungsprodukte liegen.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. 258.
    Vgl. Beutler, K. /Ähnlichkeitsmaße/ S. 65.Google Scholar
  2. 259.
    Dazu werden neben Code, Datenstrukturen und Entwurfsinformationen wie Spezifikations- und Konstruktionsunterlagen auch Testdaten und Dokumentationen gezählt.Google Scholar
  3. 260.
    Vgl. Incorvaia, A.; Davis, A.; Fairley, R. /Case Studies in Software Reuse/ S. 305.Google Scholar
  4. 261.
    Vgl. Haynes, W.; Dewell, M.; Herman, P. /The Cross System Product application generator/ S. 384.Google Scholar
  5. 262.
    Vgl. Goodell, M. /Recurring Functions/ S. 198ff.Google Scholar
  6. 263.
    Vgl. Goodell, M. /Recurring Functions/ S. 204ff.Google Scholar
  7. 264.
    Vgl. Goodell, M. /Recurring Functions/ S. 200ff.Google Scholar
  8. 265.
    Vgl. Boehm, B. /Small-Scale-Application/ S. 484. Er stellte die Hypothese auf, daß der größte Anteil von Code in Housekeeping-Funktionen (Benutzerführung, Fehlerbehandlung, Mode-Management und Datenbehandlung) anfällt und bestätigte sie.Google Scholar
  9. 266.
    Vgl. Lanergan, R.; Grasso, C. /Software Engineering with Reusable Design and Code/ S. 498ff. Die Untersuchung fand 1976 statt.Google Scholar
  10. 267.
    Vgl. Lanergan, R.; Grasso, C. /Software Engineering with Reusable Design and Code/ S. 498. Es wurden logische Strukturen aufgebaut, die für jede der häufig vorkommenden Funktionen ein vorgefertigtes Gerippe vorhält. Diese logischen Strukturen geben den Programmierern einen “head start” und einen einheitlichen Ansatz vor, dessen Wert beim Testen und Warten in Erscheinung tritt.Google Scholar
  11. 268.
    Vgl. Emery, J. /Small-Scale Software Components/ S. 18ff.Google Scholar
  12. 269.
    Vgl. Emery, J. /Small-Scale Software Components/ S. 19.Google Scholar
  13. 270.
    Der festzustellende Produktivitätseffekt ergibt sich aus dem Anteil der Codierung an der gesamten Entwicklung und dem Einsparungseffekt aus der Wiederverwendung dieser kleinen Bausteine.Google Scholar
  14. 271.
    Vgl. Marty, R. /Objektorientierte Softwaretechnik bei der BSG/ S. 10. Vgl. Nawrot, B. /objectiF/ S. 1ff. Vgl. Johnson, R.; Foote, B. /Designing Reusable Classes/ S. 22ff. Vgl. Liebherr, K.; Riel, A.; Demeter, A. /Case Study of Software Growth/ S. 8ff. Vgl. Heß, H. /Wiederverwendung von Software/ S. 46ff.Google Scholar
  15. 272.
    Vgl. Kaiser, G.; Garlan, D. /Melding Software/ S. 269. Vgl. Jones, T. /Reusability in Programming/ S. 54. Vgl. Rich, C.; Waters, R. /Formalizing Reusable software components/ S. 318. Vgl. Horowitz, E.; Munson, J. B. /An Expansive View of Reusable Software/ S. 42. Vgl. Gargaro, A. /Reusability Issues and Ada/ S. 234.Google Scholar
  16. 273.
    Vgl. Caldiera, G.; Basili, V. /Identifying and Qualifying/ S. 61. Vgl. Zöller, H. /Wiederverwendbare Software-Bausteine/ S. 20. Vgl. Honiden, S.; Sueda, N.; Hoshi, A.; Uchihira, N.; Mikame, K. /Software Prototyping/ S. 113ff. Vgl. Wagner, B. /Wissensbasierte Unterstützung/ S. 615ff. Vgl. Heß, H.; Scheer, A.-W. /Retrieval wiederverwendbarer Bausteine/S. 6ff. Vgl. Honiden, S.; Sueda, N.; Hoshi, A.; Uchihira, N.; Mikame, K. /Software Prototyping/ S. 114. Vgl. Gibbs, S.; Tsichritzis, D.; Casais, E.; Nierstrasz, O.; Pintado, X. /Class Management/ S. 94. Vgl. Heß, H.; Scheer, A.-W. /Retrieval wiederverwendbarer Bausteine/ S. 6. Vgl. Gibbs, S.; Tsichritzis, D.; Casais, E.; Nierstrasz, O.; Pintado, X. /Class Management/ S. 94. Vgl. Calidera, G.; Basili, V./Identifying and Qualifying/ S. 61ff.Google Scholar
  17. 274.
    Vgl. Lauber, R. /CASE/ S. 254f. Vgl. Maiden, N.; Sutcliffe, N. /Analogical Matching for specification reuse/ S. 3f.Google Scholar
  18. 275.
    Vgl. Selby, R. /Empirically Analyzing Software Reuse in a Production Environment/ S. 176ff.Google Scholar
  19. 276.
    Jedes System bestand aus 22 bis 853 Modulen. Als Module wurden Subroutinen, Dienstfunktionen, Hauptprogramme, Makros und Datenblöcke bezeichnet.Google Scholar
  20. 277.
    SLOC = Source Lines of Codes; QuellcodezeilenGoogle Scholar
  21. 278.
    Vgl. Selby, R. /Empirically Analyzing Software Reuse in a Production Environment/ S. 185f.Google Scholar
  22. 279.
    Vgl. Selby, R. /Quantitative Studies/ S. 218f.Google Scholar
  23. 280.
    Vgl. McCabe, T./Complexity Measure/ S. 308ff. Die Kontrollstrukturen werden im Verhältnis zu der Anzahl der Source-Code-Lines gemessen.Google Scholar
  24. 281.
    Vgl. Selby, R. /Quantitative Studies/ S. 2281Google Scholar
  25. 282.
    Vgl. Selby, R. /Empirically Analyzing Software Reuse in a Production Environment/ S. 188.Google Scholar
  26. 283.
    Vgl. Selby, R. /Empirically Analyzing Software Reuse in a Production Environment/ S. 188.Google Scholar
  27. 284.
    Vgl. Denert, E. /Software-Engineering/ S. 220f.Google Scholar
  28. 285.
    Vgl. Liskov, B. /Programming with Abstract Data Types/ S. 56.Google Scholar
  29. 286.
    Vgl. Embley, D., Woodfield, S. /Knowledge Structure/ S. 368.Google Scholar
  30. 287.
    Vgl. Braun, U., Schmid, H. /Wiederverwendbare ADT/ S. 168.Google Scholar
  31. 288.
    Vgl. Druffel, L. /Potential Effect of Ada/ S. 135.Google Scholar
  32. 289.
    Vgl. Tracz, W. /Ada Reusability Efforts/ S. 24.Google Scholar
  33. 290.
    Vgl. Druffel, L. /Potential Effect of Ada/ S. 137.Google Scholar
  34. 291.
    Vgl. Tonndorf, M. /ADA Software/ S. 186.Google Scholar
  35. 292.
    Da Ada als standardisierte Sprache vom DoD für alle Flugkörperentwicklungen verwendet wurde, existiert ein Ada Software Repository, das in einigen Teilen über Arpanet seit 1984 öffentlich zugänglich ist. Es ist eine Sammlung von Ada-Programmen, Komponenten, Informationen, Dokumentationen und Tools und dient als Basis-Bibliothek für Ada-Realzeit-Anwendungen, zur Ausbildung und zum freiem Austausch der Komponenten. Inhalte sind Ausbildungsinformationen, Softwareentwicklung mit Tools, wiederverwendbare Softwareteile, Projektmanagement, Datenbankmanagement und Kommunikationsprotokolle. Zugleich werden auch verschiedene Dienste für die Ada-Community angeboten. Vgl. Tracz, W. /Ada Reusability Efforts/ S. 24. Vgl. Conn, R. /The Ada Software Repository and Reusability/ S. 238. Vgl. Tonndorf, M. /Ada Software/ S. 185. Vgl. Tracz, W. /Ada Reusability Efforts/ S. 25. Vgl. Gargaro, A./Reusability Issues and Ada/ S. 229.Google Scholar
  36. 293.
    Vgl. Russel, G. /Experiences implementing reusable data structures/ S. 247.Google Scholar
  37. 294.
    Vgl. Russel, G. /Experiences implementing reusable data structures/ S. 248f.Google Scholar
  38. 295.
    Vgl. Russel, G. /Experiences implementing reusable data structures/ S. 250ff. Dort findet sich ein Beispiel für die Definition und die zugrundeliegenden Annahmen der Objekte.Google Scholar
  39. 296.
    Vgl. Tracz, W. /Ada Reusability Efforts/ S. 28f.Google Scholar
  40. 297.
    Vgl. Lewis, J.; Henry, S.; Kafura, D. /Empirical Study/ S. 184ff.Google Scholar
  41. 298.
    Vgl. Lewis, J.; Henry, S.; Kafura, D. /Empirical Study/ S. 188f.Google Scholar
  42. 299.
    Vgl. Futatsugi, K.; Goguen, J.; Meseguer, J.; Okada, K. /Parameterized Programming/ S. 337.Google Scholar
  43. 300.
    Vgl. Futatsugi, K.; Goguen, J.; Meseguer, J.; Okada, K. /Parameterized Programming/ S. 337.Google Scholar
  44. 301.
    S. Futatsugi, K.; Goguen, J.; Meseguer, J.; Okada, K. /Parameterized Programming/ S. 340.Google Scholar
  45. 302.
    Vgl. Futatsugi, K.; Goguen, J.; Meseguer, J.; Okada, K. /Parameterized Programming/ S. 341.Google Scholar
  46. 303.
    Vgl. Futatsugi, K.; Goguen, J.; Meseguer, J.; Okada, K. /Parameterized Programming/ S. 345.Google Scholar
  47. 304.
    Vgl. Borning, A. H. /Classes versus Prototyping in object-oriented languages/ S. 36. Borning will das Problem der Komplexität durch sog. Prototyp- statt Klassennutzung umgehen; dabei wird der Prototyp als standard example instance behandelt, von dem neue Objekte durch kopieren und modifizieren gebildet werden. Dies entspricht dem Wiederverwendungsvorgehen “copy and modify”. Dennoch ist die Idee, aus Komponenten Rapid Prototypen zu bauen, urn schnell die Funktionsweise des Programms mit der Anforderung zu vergleichen in objektorientierten Sprachen recht einfach zu realisieren. Vgl. Raj, R.; Levy, H. /A Compositional Model for Software Reuse/ S. 10. Vgl. Jul, E.; Levy, H.; Hutchinson, N.; Black, A. /Fine-Grained Mobility in the Emerald System/ S. 110.Google Scholar
  48. 305.
    Vgl. Kaiser, G.; Garlan, D. /Melding Software/ S. 267.Google Scholar
  49. 306.
    Vgl. Kaiser, G.; Garlan, D. /Melding Software/ S. 269. Meld kombiniert Elemente aus den bibliotheks-, objekt- und transformationsorientierten Ansätzen.Google Scholar
  50. 307.
    Vgl. Prieto-Díaz, R.; Neighbors, J. /Module Interconnection Languages/ S. 117. Vgl. Börstler, J. /Wiederverwendbarkeit und Softwareentwicklung/ S. 11.Google Scholar
  51. 308.
    Vgl. Prieto-Díaz, R.; Neighbors, J. /Module Interconnection Languages/ S. 119.Google Scholar
  52. 309.
    Vgl. Prieto-Díaz, R.; Neighbors, J. /Module Interconnection Languages/ S. 123.Google Scholar
  53. 310.
    Das statische Typ-Checking würde das Einbinden verschiedener Module stark erleichtern.Google Scholar
  54. 311.
    Vgl. Börstler, J. /Wiederverwendbarkeit und Softwareentwicklung/ S. 12.Google Scholar
  55. 312.
    Vgl. Kernighan, B. /The Unix System/ S. 145ff.Google Scholar
  56. 313.
    Vgl. Börstler, J. /Wiederverwendbarkeit und Softwareentwicklung/ S. 11. Vgl. Kernighan, B. /The Unix System/ S. 145ff.Google Scholar
  57. 314.
    Vgl. Rice, J.; Schwetman, H. /Interface Issues/ S. 125.Google Scholar
  58. 315.
    Vgl. Rice, J.; Schwetman, H. /Interface Issues/ S. 127. Vgl. Kernighan, B. /The Unix System/ S. 146f.Google Scholar
  59. 316.
    Vgl. Hall, P. /Software Components/ S. 14f.Google Scholar
  60. 317.
    Vgl. Hall, P. /Software Components/ S. 14.Google Scholar
  61. 318.
    Vgl. Volpano, D.; Kieburtz, R. /The Templates Approach/ S. 247.Google Scholar
  62. 319.
    Vgl. Volpano, D.; Kieburtz, R. /The Templates Approach/ S. 250.Google Scholar
  63. 320.
    Vgl. Volpano, D.; Kieburtz, R. /The Templates Approach/ S. 251.Google Scholar
  64. 321.
    Vgl. Katz, S.; Richter, C.; The, K. /PARIS; A System/ S. 290ff.Google Scholar
  65. 322.
    Vgl. Lenz, M.; Schmid, A.; Wolf, P. /Software Reuse through Building Blocks/ S. 100.Google Scholar
  66. 323.
    Vgl. Bröstler, J. /Wiederverwendbarkeit und Softwareentwicklung/ S. 9.Google Scholar
  67. 324.
    Vgl. Bröstler, J. /Wiederverwendbarkeit und Softwareentwicklung/ S. 9.Google Scholar
  68. 325.
    Vgl. Lenz, M.; Schmid, A.; Wolf, P. /Software Reuse through Building Blocks/ S. 101.Google Scholar
  69. 326.
    Vgl. Lenz, M.; Schmid, A.; Wolf, P. /Software Reuse through Building Blocks/ S. 103. Das Performance-Problem wird durch die inline-Generierung von Code gelöst.Google Scholar
  70. 327.
    Vgl. Lenz, M.; Schmid, A.; Wolf, P. /Software Reuse through Building Blocks/ S. 105.Google Scholar
  71. 328.
    S. Lenz, M.; Schmid, A.; Wolf, P. /Software Reuse through Building Blocks/ S. 101.Google Scholar
  72. 329.
    Vgl. Lenz, M.; Schmid, A.; Wolf, P. /Software Reuse through Building Blocks/ S. 104.Google Scholar
  73. 330.
    Vgl. Favaro, J. /Tutorial on Software Reuse/ II — 16. Die Organisation der Entwicklung mit wiederverwendbaren Bauteilen wird häufig als Managementproblem bezeichnet. Tatsächlich scheint sich eine geeignete, projektübergreifende Organisation zu finden, wenn das Wiederverwendungskonzept vorhanden ist.Google Scholar
  74. 331.
    Vgl. Gargaro, A. /Reusability Issues and Ada/ S. 230f.Google Scholar
  75. 332.
    Vgl. Bartels, R. /Entwicklungsumgebung für Telekooperationssysteme/Google Scholar
  76. 333.
    Beispielsweise setzten diese Ansätze implizit Baustein-Bibliotheken voraus.Google Scholar
  77. 334.
    Vgl. Goodell, M. /Recurring Functions/ S. 200ff. Vgl. Boehm, B. /Small-Scale-Application/ S. 484. Vgl. Lanergan, R.; Grasso, C. /Software Engineering with Reusable Design and Code/ S. 498ff. Vgl. Emery, J. /Small-Scale Software Components/ S. 18ff.Google Scholar
  78. 335.
    Bei Rayethon wurden Programmlogik-Gerüste in Cobol aufgebaut. Sie dokumentierten Ähnlichkeiten und ließen Unterschiede in spezifischen Ausprägungen von Daten und Funktionen zu. Letztendlich erfordern solche Gerüste ein standardisiertes Design mit spezifischen Annahmen über die Basissystemumgebung, urn übertragbar zu sein. Programmschablonen können für dieselben Branchen entwickelt werden; handelt es sich bspw. urn Update-Programme für Banken und werden bspw. Konten bearbeitet, bleiben sogar die Variablennamen dieselben, die Anweisungsfolge bleibt in etwa dieselbe, so daß hier die höchsten Produktivitätserfolge erzielt werden können.Google Scholar
  79. 336.
    Vgl. Bassett, P. /Frame-Based Software Engineering/ S. 122. Noma Industries entwickelte bspw. ihre Programme mit 30 Input/Output-Frames, 38 anwendungsorientierten Frames sowie etwa 400 Dataview-Frames, Screen- und Reportframes.Google Scholar
  80. 337.
    Dieses Vorgehen wird bei der Programmentwicklung im Großen praktiziert; bspw. verfügen Unternehmensberatungen über Skelette für bestimmte Branchen.Google Scholar
  81. 338.
    S. Bassett, P. /Frame-Based Software Engineering/ S. 122.Google Scholar
  82. 339.
    Vgl. Bassett, P. /Frame-Based Software Engineering/ S. 123.Google Scholar
  83. 340.
    Vgl. Deutsch, P. /Design Reuse and Frameworks/ S. 58.Google Scholar
  84. 341.
    Vgl. Deutsch, P. /Design Reuse and Frameworks/ S. 60. Der Ansatz weist eine gewisse Ähnlichkeit vom Konzept her mit dem von ObjectiF auf; in beiden Fällen werden die Interfaces standardisiert, um wiederverwendbare Klassen und Objekte zu erhalten. Damit wird das Schnittstellenproblem in objektorientierten Systemen, das durch Message-Passing in großen objektorientierten Systemen entsteht, vermindert.Google Scholar
  85. 342.
    Vgl. Johnson, R.; Foote, B. /Designing Reusable Classes/ S. 22f. Vgl. Liebherr, K.; Riel, A.; Demeter, A. /Case Study of Software Growth/ S. 8ff. Vgl. Nawrot, B. /objectiF/S. 6ff.Google Scholar
  86. 343.
    Vgl. Goodell, M. /Recurring Functions/ S. 200ff. Vgl. Boehm, B. /Small-Scale-Application/ S. 484. Vgl. Lanergan, R.; Grasso, C. /Software Engineering with Reusable Design and Code/ S. 498ff. Vgl. Emery, J. /Small-Scale Software Components/ S. 18ff.Google Scholar
  87. 344.
    Vgl. Lanergan, R.; Grasso, C. /Software Engineering with Reusable Design and Code/ S. 498ff.Google Scholar
  88. 345.
    Vgl. Lanergan, R.; Grasso, C. /Software Engineering with reusable Designs and Code/ S. 189ff.Google Scholar
  89. 346.
    Vgl. Lanergan, R.; Grasso, C. /Software Engineering with reusable Designs and Code/ S. 189.Google Scholar
  90. 347.
    Vgl. Lanergan, Grasso /Reusable Design and Code/ S. 500.Google Scholar
  91. 348.
    Die angewendeten Methoden und Verfahren können die Darstellung des “Was” einer Domäne bzw. eines Anwendungsfalles einer Domäne entscheidend beeinflussen. D.h., die Verfahren und Methoden müssen auf die Domäne abgestimmt werden.Google Scholar
  92. 349.
    S. Neighbors, J. /Draco Approach/ S. 188.Google Scholar
  93. 350.
    Vgl. Denert, E. /Software-Engineering/ S. 45.Google Scholar
  94. 351.
    Vgl. Denert, E. /Software-Engineering/ S. 48.Google Scholar
  95. 352.
    Vgl. Dubinsky, E.; Freudenberger, S.; Shonberg, E.; Schwartz, J./Reusability of Design/ S. 275.Google Scholar
  96. 353.
    Vgl. Lubars, M.; Harandi, M. /Adressing Software Reuse/ S. 346.Google Scholar
  97. 354.
    Vergleiche dazu die Ansätze zur Wiederverwendung von Wissen in Kapitel 4.2.6.Google Scholar
  98. 355.
    Vgl. Biggerstaff, T. /Reusability is the essence of design/ S. 474.Google Scholar
  99. 356.
    Vgl. Biggerstaff, T. /Reusability is the essence of design/ S. 475.Google Scholar
  100. 357.
    Hier wird erkennbar, daß der Lösungsweg zu einem bestimmten Ergebnis führt. Soll das Ergebnis wiederverwendet werden, muß der Lösungsweg nachvollziehbar sein und zu vergleichbaren Entwurfsprodukten führen. Zum anderen wird deutlich, daß es neben dem Lösungsweg offenbar bestimmte Entwurfsrichtlinien sowie Anwendungsvoraussetzungen bei der Erstellung wiederverwendbarer Teile zu beachten gilt.Google Scholar
  101. 358.
    Vgl. Jameson, K. /Model for Reuse of Software Design Information/ S. 205ff.Google Scholar
  102. 359.
    Dazu zählt auch die Weiterentwicklung existierenden Designs.Google Scholar
  103. 360.
    Vgl. Jameson, K. /Model for Reuse of Software Design Information/ S. 206.Google Scholar
  104. 361.
    Vgl. Jameson, K. /Model for Reuse of Software Design Information/ S. 210.Google Scholar
  105. 362.
    Vgl. Yeh, R.; Mittermeir, R.; Roussopoulos, N.; Reed, J. /A Programming Environment/ S. 277f.Google Scholar
  106. 363.
    Vgl. Yeh, R.; Mittermeir, R.; Roussopoulos, N.; Reed, J. /A Programming Environment/ S. 279.Google Scholar
  107. 364.
    Vgl. Nawrot, B. /objectiF/ S. 6ff.Google Scholar
  108. 365.
    Die Klassen der oberen Ebenen werden einmal erstellt und wiederverwendet. Auch die Ebene der Basistechnologie kann für mehrere Anwendungen verwendet werden.Google Scholar
  109. 366.
    Vgl. Wald, E. /Software Engineering with Reusable Parts/ S. 109.Google Scholar
  110. 367.
    Graphenvariable können als Eingabe und/oder Ausgabe für eine beliebige Anzahl Knoten spezifiziert werden, um Speicherpuffer für Daten, die von mehreren Knoten benötigt werden, zu definieren. Vgl. Wald, E. /Software Engineering with Reusable Parts/ S. 111.Google Scholar
  111. 368.
    Vgl. Wald, E. /Software Engineering with Reusable Parts/ S. 111.Google Scholar
  112. 369.
    Vgl. Jameson, K. /Model for Reuse of Software Design Information/ S. 205.Google Scholar
  113. 370.
    Vgl. Neighbors, J. /Draco Approach/ S. 188.Google Scholar
  114. 371.
    Vgl. Maiden, N.; Sutcliffe, A. /Exploiting Reusable Specifications/ S. 58f.Google Scholar
  115. 372.
    Vgl. Balzer, R.; Cheatham, T.; Cordell, G. /Software Technologie in the 1990’s/ S. 40.Google Scholar
  116. 373.
    Vgl. Balzer, R.; Cheatham, T.; Cordell, G. /Software Technologie in the 1990’s/ S. 39.Google Scholar
  117. 374.
    Vgl. Neighbors, J. /The Draco Approach/ S. 564. DRACO gilt als Transformationssystem.Google Scholar
  118. 375.
    Vgl. Seppänen, V. /Reusability in Software Engineering/ S. 286.Google Scholar
  119. 376.
    Vgl. Freeman, P. /Conceptual Analysis of the Draco Approach/ S. 192.Google Scholar
  120. 377.
    Vgl. Neighbors, J. /Draco/ S. 303. Vgl. Neighbors, J. /Draco Approach/ S. 184.Google Scholar
  121. 378.
    Eine Transformation bildet einen Umsetzungsprozeß von einem Programmschema auf ein zweites ab. Transformationen können auf formalen Sprachen beruhende Entwicklungsprodukte in Code umsetzen. Voraussetzung ist die Kenntnis und Formalisierung des Umsetzungsprozesses. Vgl. Freeman, P. /Conceptual Analysis of the Draco Approach/ S. 192. Vgl. Neighbors, J. /Draco Approach/ S. 182f.Google Scholar
  122. 379.
    Vgl. Neighbors, J. /Draco/ S. 302.Google Scholar
  123. 380.
    Vgl. Neighbors, J. /Draco Approach/ S. 181.Google Scholar
  124. 381.
    Daher war der historisch nächste Schritt der Einsatz von wissensbasierten Systemen, urn die Umsetzung anzuleiten.Google Scholar
  125. 382.
    Vgl. Neighbors, J. /The Draco Approach/ S. 564.Google Scholar
  126. 383.
    Vgl. Partsch, H.; Steinbrüggen, R. /Program Transformation Systems/ S. 295.Google Scholar
  127. 384.
    S. Dubinsky, E.; Freudenberger, S.; Shonberg, E.; Schwartz, J./Reusability of Deisgn/ S. 276.Google Scholar
  128. 385.
    Vgl. Johnson, W.L.; Feather, M., S.; Harris, D.R. /Applying domain and design knowledge/ S. 48.Google Scholar
  129. 386.
    In ARIES wird nicht zwischen Anforderungen und Spezifikationen getrennt; vielmehr werden Spezifikationen als Ergebnis der Akquirierung und Formalisierung von Anforderungen gesehen. Spezifikationen werden aufgrund bestehender Anforderungsdefinitionen mit Hilfe graphischer Werkzeuge erarbeitet.Google Scholar
  130. 387.
    Vgl. Johnson, W.L.; Feather, M., S.; Harris, D.R. /Applying domain and design knowledge/ S. 52.Google Scholar
  131. 388.
    In ARIES sind einige “evolution transformations” gespeichert, die der Nutzer auswählen muß; die ausgewählten Umsetzungsregeln werden durch Anwendbarkeitsbedingungen in ARIES überprüft.Google Scholar
  132. 389.
    Vgl. Lubars, M.; Harandi, M. /Intelligent Support for Software Specification and Design/ S. 33f.Google Scholar
  133. 390.
    Vgl. Lubars, M.; Harandi, M. /Adressing Software Reuse/ S. 346f. Vergleiche dazu auch die Ansätze zur Analogiebildung, in Kapitel 4.2.4.2.Google Scholar
  134. 391.
    Vgl. Lubars, M.; Harandi, M. /Adressing Software Reuse/ S. 346.Google Scholar
  135. 392.
    Vgl. Lubars, M.; Harandi, M. /Intelligent Support for Software Specification and Design/ S. 35.Google Scholar
  136. 393.
    S. Lubars, M.; Harandi, M. /Adressing Software Reuse/ S. 349.Google Scholar
  137. 394.
    Vgl. Lubars, M.; Harandi, M. /Adressing Software Reuse/ S. 355.Google Scholar
  138. 395.
    Vgl. Lubars, M.; Harandi, M. /Adressing Software Reuse/ S. 361. Vgl. Lubars, M.; Harandi, M. /Intelligent Support for Software Specification and Design/ S. 37.Google Scholar
  139. 396.
    Vgl. Lubars, M.; Harandi, M. /Adressing Software Reuse/ S. 364.Google Scholar
  140. 397.
    Es werden abstrakte Designschemata verwendet, um eine Design- und Programmfamilie in einer Domäne zu entwerfen. Die bei ihrer Spezialisierung angewendeten Designentscheidungen grenzen die Familienmitglieder voneinander ab. Familienmitglieder werden aufgrund von Ähnlichkeiten der Spezifikation, der Designschemata sowie der Entwurfsentscheidungen entwickelt. Sie gehören einer Domäne an.Google Scholar
  141. 398.
    Vgl. Finkelstein, A. /Re-use of formatted requirements specifications/ S. 186ff.Google Scholar
  142. 399.
    Vgl. Finkelstein, A. /Re-use of formatted requirements specifications/ S. 186.Google Scholar
  143. 400.
    Die wichtigsten Schritte der Methode (aus Toolunterstützungssicht) sind 1. Viewpoint Structuring: Die Modellierungswelt wird in eine Anzahl von Viewpoints (Agents, Actors) unterteilt. Diese unterscheiden sich durch spezifische Verantwortung, Funktionalitäten und Attribute, 2. Tabular Collection: Identifizierung der auszuführenden Aktionen und des In- und Outputs an Datenströmen, 3. Data Structuring: Strukturierung der ausgehenden Datenflüsse bspw. nach Jackson System Development, 4. Single-Viewpoint Modelling: Hinzufugung von Kontrollinformationen (Aktions-Trigger) zu den Viewpoints, 5. Combined-Viewpoint Modelling. Identifizierung von Transaktionen die sich durch das System ziehen.Google Scholar
  144. 401.
    S. Finkelstein, A. /Re-use of formatted requirements specifications/ S. 187.Google Scholar
  145. 402.
    Vgl. Finkelstein, A. /Re-use of formatted requirements specifications/ S. 188.Google Scholar
  146. 403.
    Vgl. Finkelstein, A. /Re-use of formatted requirements specifications/ S. 194.Google Scholar
  147. 404.
    Vgl. Maiden, N. /Analogy as a paradigms for specification reuse/ S. 4.Google Scholar
  148. 405.
    S. Carbonell, J. /Derivational analogy/ zit. in Maiden, N. /Analogy as a paradigm for specification reuse/ S. 5.Google Scholar
  149. 406.
    Vgl. Gentner, D. /Structure-Mapping/ S. 168.Google Scholar
  150. 407.
    Vergleiche dazu das Kapitel 4.2.6.Google Scholar
  151. 408.
    Vgl. Gentner, D. /Structure-Mapping/ S. 168.Google Scholar
  152. 409.
    Gentner bezeichnet als Analogie einen Vergleich, bei dem “relational predicates”, aber weniger oder keine Objektattribute von der Basis- zur Zieldomäne abgebildet werden. Vgl. dazu Gentner, D. /Structure-Mapping/ S. 159. Verdeutlicht wird dies am Beispiel der Analogie zwischen dem Sonnensy-stem und einem Atom anhand der Beziehungen Distanz, betrachtete Körper, “Herumkreisen” und spezi-fisches Gewicht. Vgl. dazu Gentner, D. /Structure-Mapping/ S. 163.Google Scholar
  153. 410.
    S. Gentner, D. /Structure-Mapping/ S. 168.Google Scholar
  154. 411.
    Vgl. Maiden, N.; Sutcliffe, A. /Exploiting Reusable Specifications/ S. 58ff.Google Scholar
  155. 412.
    Vgl. Maiden, N.; Sutcliffe, A. /Exploiting Reusable Specifications/S. 58.Google Scholar
  156. 413.
    Vgl. Maiden, N.; Sutcliffe, A. /Exploiting Reusable Specifications/S. 59.Google Scholar
  157. 414.
    Vgl. Maiden, N.; Sutcliffe, A. /Exploiting Reusable Specifications/ S. 59.Google Scholar
  158. 415.
    Vgl. Maiden, N.; Sutcliffe, A. /Exploiting Reusable Specifications/ S. 60.Google Scholar
  159. 416.
    S. Maiden, N.; Sutcliffe, A. /Exploiting Reusable Specifications/ S. 60.Google Scholar
  160. 417.
    Dies zeigt auch die Untersuchung von Holt/Boehm-Davis, die die Ursache für Fehler im Entwurfsprozeß im fehlenden Domänenverständnis sehen. Vergleiche dazu Kapitel 4.2.6.Google Scholar
  161. 418.
    Als releyantes Wissen für analoge Spezifikationen dienen das Lösungsweg-, das Quelldomänen- und das Zieldomänenwissen. Das Lösungswegwissen beschreibt die in der Spezifikation dargelegten Grundkonzepte. Das Domänenwissen beschreibt das Domänen- und das reale-Welt-Wissen, die die Anwendungsdomäne darstellen. Das Zieldomänenwissen beschreibt den Zweck der wiederverwendbaren Spezifikation und die Anforderungen des Zielsystems.Google Scholar
  162. 419.
    Maiden, N. /Analogy as a paradigm for specification reuse/ S. 8.Google Scholar
  163. 420.
    Maiden, N. /Analogy as a paradigm for specification reuse/ S. 8.Google Scholar
  164. 421.
    Vgl. Maiden, N. /Analogy as a paradigm for specification reuse/ S. 14f.Google Scholar
  165. 422.
    Vgl. Maiden, N.; Sutcliffe, A. /Exploiting Reusable Specifications/ S. 55.Google Scholar
  166. 423.
    Vgl. Maiden, N. /Analogy as a paradigm for specification reuse/ S. 14.Google Scholar
  167. 424.
    Vgl. Maiden, N.; Sutcliffe, A. /Exploiting Reusable Specifications/S. 58.Google Scholar
  168. 425.
    Vgl. dazu auch die Ansätze von Prieto-Díaz, der Vorgehensweisen zur Domänenmodellerstellung vergleicht und schließlich eine Vorgehensweise vorschlägt. Dort werden auch die spezifischen Zieldomänen definiert und abgegrenzt, bevor mit der Erstellung wiederverwendbarer Teile begonnen wird. Prieto-Díaz, R. /Domain Analysis for Reusability/ S. 347ff.Google Scholar
  169. 426.
    Die Abbildung von Spezifikationen in unterschiedlicher Darstellungsform aufgrund verschiedener methodischer Vorgehen erschwert den syntaktischen und semantischen Abgleich der Domänen.Google Scholar
  170. 427.
    Vgl. Maiden, N.; Sutcliffe, A. /Exploiting Reusable Specifications/ S. 58f.Google Scholar
  171. 428.
    Vgl. Gomaa, H. /Object-oriented domain analysis and modeling method/ S. 46ff.Google Scholar
  172. 429.
    Vgl. Gomaa, H. /Object-oriented domain analysis and modeling method/ S. 46.Google Scholar
  173. 430.
    S. Gomaa, H. /Object-oriented domain analysis and modeling method/ S. 46.Google Scholar
  174. 431.
    Vgl. Gomaa, H. /Object-oriented domain analysis and modeling method/ S. 47.Google Scholar
  175. 432.
    Vgl. Booch, G. /Software Engineering with ADA/ Vgl. Meyer, B. /Objektorientierte Software-Entwicklung/Google Scholar
  176. 433.
    Vgl. Gomaa, H. /Object-oriented domain analysis and modeling method/ S. 50.Google Scholar
  177. 434.
    PORTOS ist ein Betriebssystem der Siemens AG für Mikrorechner.Google Scholar
  178. 435.
    Vgl. Gietl, J. / Software-Baukasten/ S. 129.Google Scholar
  179. 436.
    Vgl. Gietl, J. / Software-Baukasten/ S. 131.Google Scholar
  180. 437.
    Vgl. Gietl, J. / Software-Baukasten/ S. 133.Google Scholar
  181. 438.
    Im Grunde wird hier Modul- und Designwiederverwendung betrieben, wie auch im BB/LX-Ansatz.Google Scholar
  182. 439.
    Vgl. Schüle, H.; Schumann, M. /CASE-basierte Unternehmensmodelle /S. 32.Google Scholar
  183. 440.
    Vgl. Prieto-Díaz, R. /Domain Analysis for Reusability/ S. 347ff.Google Scholar
  184. 441.
    Vgl. dazu auch ARIES in Kapitel 4.2.4.1.Google Scholar
  185. 442.
    Vgl. Caldiera, G.; Basili, V. /Identifying and Qualifying/ S. 61.Google Scholar
  186. 443.
    Vgl. Curtis, B. /Cognitive Issues/ S. 269.Google Scholar
  187. 444.
    Vergleiche dazu auch Kapitel 4.2.3.1, Wiederverwendung von Design mittels einer Softwarearchitektur.Google Scholar
  188. 445.
    Vgl. Holt, R.; Boehm-Davis, D. /Mental Representations of Programs/ S. 33ff.Google Scholar
  189. 446.
    Vgl. Soloway, E.; Ehrlich, K. /Empirical Studies of Programming Knowledge/ S. 235ff.Google Scholar
  190. 447.
    Vgl. Soloway, E.; Ehrlich, K. /Empirical Studies of Programming Knowledge/ S. 235f.Google Scholar
  191. 448.
    Vgl. Curtis, B. /Cognitive Issues/ S. 270f.Google Scholar
  192. 449.
    Vgl. Soloway, E.; Ehrlich, K. /Empirical Studies of Programming Knowledge/ S. 237.Google Scholar
  193. 450.
    Vgl. Soloway, E.; Ehrlich, K. /Empirical Studies of Programming Knowledge/ S. 242.Google Scholar
  194. 451.
    Zum gleichen Ergebnis kamen auch die Untersuchungen von Selby und Lewis. Vgl. Lewis, J.; Henry, S.; Kafura, D. /Empirical Study/ S. 184ff. Vgl. Selby, R. /Empirically Analyzing Software Reuse in a Production Environment/ S. 176ff.Google Scholar
  195. 452.
    Vgl. Curtis, B. /Cognitive Issues/ S. 269f.Google Scholar
  196. 453.
    Vgl.Curtis, B. /Cognitive Issues/ S. 270.Google Scholar
  197. 454.
    Das Item “sum array” bewirkt nicht nur den Abruf der Additionszeile, sondern auch die dazugehörenden “statements”, die die Additionszeile zu kleinen Routinen ergänzen, aus dem Langzeit-Gedächtnis.Google Scholar
  198. 455.
    Vgl. Curtis, B. /Cognitive Issues/ S. 271.Google Scholar
  199. 456.
    Vgl. Curtis, B. /Cognitive Issues/ S. 272.Google Scholar
  200. 457.
    Vgl. Curtis, B. /Cognitive Results/ S. 272. Ein Schema spezifiziert charakteristische Attribute der Mitgliedschaft in einer Kategorie, aktuellen “principal members of the class” und verfügbaren Operationen dieses Schemata. Schemata geben deklaratives Wissen wieder, repräsentieren allgemeines Wissen über Konzepte und können Informationen über das Wie der Zielerreichung enthalten. Dabei nimmt mit zunehmender Erfahrung der Programmierer die einheitliche Klassifizierung zu.Google Scholar
  201. 458.
    Adelson, B.; Soloway, E. /The role of domain experience in software design/ zit. in: Curtis, B. /Cognitive Results/ S. 277.Google Scholar
  202. 459.
    Vgl. Curtis, B. /Cognitive Results/ S. 277.Google Scholar
  203. 460.
    Vgl. Woodfield, S.; Embley, D.; Scott, D. /Can Programmers Reuse Software?/ S. 168ff.Google Scholar
  204. 461.
    Vgl. Holt, R.; Boehm-Davis, D. /Mental Representations of Programs/ S. 33ff.Google Scholar
  205. 462.
    Vgl. Maiden, N. /Analogy as a paradigm for specification reuse/ S. 3.Google Scholar
  206. 463.
    Vgl. Prieto-Díaz, R. / Domain Analysis for Reusability/ S. 347.Google Scholar
  207. 464.
    Vgl. Maiden, N. /Analogy as a paradigm for specification reuse/ S. 3.Google Scholar
  208. 465.
    Das aus der Erstellung wissensbasierter Systeme bekannte Problem der Abgrenzung des Wissensgebiets wird umgangen, indem man bereits existierende Systeme betrachtet. Das in ihnen inhärente Wissen wird herausgeschält.Google Scholar
  209. 466.
    Vgl. auch Prieto-Díaz, R. /Domain Analysis for Reusability/ S. 350.Google Scholar
  210. 467.
    Vgl. Prieto-Díaz, R. /Domain Analysis for Reusability/ S. 350.Google Scholar
  211. 468.
    Vgl. Prieto-Díaz, R. /Domain Analysis for Reusability/ S. 350.Google Scholar
  212. 469.
    Vgl. Iscoe, N. /Domain-Specific Reuse/ S. 299ff.Google Scholar
  213. 470.
    Vgl. Iscoe, N. /Domain-Specific Reuse/ S. 300.Google Scholar
  214. 471.
    Vgl. Iscoe, N. /Domain-Specific Reuse/ S. 300.Google Scholar
  215. 472.
    Vgl. Iscoe, N. /Domain-Specific Reuse/ S. 303.Google Scholar
  216. 473.
    Entsprechend sieht der Forschungsplan 9 Schritte vor: 1. Bau eines Modell für das Domänenwissen, 2. Implementierung des Modells, 3. Instanziierung des Systems in der Domäne, 4. Spezifizierung und Generierung von Programmen in der Domäne, 5. Instanziierung des Modells für eine andere Domäne, 6. Verbesserung und Verfeinerung des Modells, 7. Vergleich der Instanziierungen, 8. Identifikation der Charakteristika, die in verschiedenen Domänen gleich und verallgemeinerbar sind, und 9. Identifikation von Algorithmen und Techniken, die über verschiedene Domänen hinweg genutzt werden können.Google Scholar
  217. 474.
    Vgl. Iscoe, N. /Domain-Specific Reuse/ S. 305.Google Scholar
  218. 475.
    Vgl. Osterweil, L. /Software Processes are Software too/ S. 6f.Google Scholar
  219. 476.
    Vgl. Osterweil, L. /Software Processes are Software too/ S. 6f. Vgl. Basili, V. /Experience Factory/ S. 3_lff. Basili schlägt den Aufbau einer Erfahrungsdatenbank auf Basis eines generischen Prozeßmodells vor.Google Scholar
  220. 477.
    S. Osterweil, L. /Software Processes are Software too/ S. 6.Google Scholar
  221. 478.
    Vgl. Osterweil, L. /Software Processes are Software too/ S. 4.Google Scholar
  222. 479.
    S. Osterweil, L. /Software Processes are Software too/ S. 12.Google Scholar
  223. 480.
    Vgl. Osterweil, L. /Software Processes are Software too/ S. 12. Vgl. Curtis, B.; Kellner, M.; Over, J. /Process Modelling/ S. 79f.Google Scholar
  224. 481.
    Vgl. Guindon, R. /Designing the Design Process/ S. 308.Google Scholar
  225. 482.
    Vgl. Guindon R. /Designing the Design Process/ S. 308.Google Scholar
  226. 483.
    S. Guindon, R. /Designing the Design Process/ S. 323.Google Scholar
  227. 484.
    Vgl. Guindon, R.; Curtis, B. /Control of cognitive processes/ S. 263 ff.Google Scholar
  228. 485.
    Vgl. Guindon, R.; Curtis, B. /Control of cognitive processes/ S. 263.Google Scholar
  229. 486.
    Vgl. dazu Guindon, R. /Designing the Design Process/ S. 324. “A design method (..) dictates or suggests a sequence of activities performed”.Google Scholar
  230. 487.
    Vgl. Guindon, R. /Designing the Design Process/ S. 320.Google Scholar
  231. 488.
    Vgl. Guindon, R. /Designing the Design Process/ S. 326.Google Scholar
  232. 489.
    Vgl. Guindon, R. /Designing the Design Process/ S. 335.Google Scholar
  233. 490.
    Vgl. Curtis, B.; Krasner, H.; Iscoe, N. /Field Study of the Software Design Process/ S. 1268ff.Google Scholar
  234. 491.
    Vgl. Curtis, B.; Krasner, H.; Iscoe, N. /Field Study of the Software Design Process/ S. 1275.Google Scholar
  235. 492.
    Vgl. Curtis, B.; Krasner, H.; Iscoe, N. /Field Study of the Software Design Process/ S. 1282.Google Scholar
  236. 493.
    Ein Prozeßmodell ist eine Sammlung von beziehungsreichen Prozeßkomponenten. Dargestellt werden die Prozesse in Form von Netzen, die sequentielle und hierarchische Bestandteile auftveisen. Durch die Sammlung von Erfahrungswissen wird das generische Prozeßmodell für spezifische Entwicklungen genutzt. Das System soll Unterstützung bei der Planumstellung, der Entscheidungsunterstützung, der integrierten Produkt- und Prozeßqualitätsmetriken, Kostenplanung und Unterstützung für verschiedene Modellsichten bieten.Google Scholar
  237. 494.
    Eines der Ziele der Softwareprozeßmodellierung ist die detaillierte Beschreibung aller Schritte, so daß sie die Steuerung durch den Entwicklungsprozeß unterstützt. Der Prozeß der Softwareerstellung ist aber geprägt durch das Hinzuziehen vieler Wissensgebiete, kreativer Problemlösungen und vielfaltiger menschlicher Interaktionen.Google Scholar
  238. 495.
    Vgl. Krasner, H.; et.al. /Lessons learned from a Software Process Modelling System/ S. 91.Google Scholar
  239. 496.
    Vgl. Curtis, B.; Kellner, M.; Over, J: /Process Modelling/ S. 83.Google Scholar
  240. 497.
    Vgl. Krasner, H.; et.al. /Lessons learned from a Software Process Modelling System/ S. 95. Ein in SPMS definiertes generisches Vorgehensmodell gibt Meilensteine, Aufgaben, Bedingungen und Produkte zur Produktion eines spezifischen Softwaressystems vor. Die prototypische Implementierung eines IEEE-Draft-Standard-Modells für Prozesse ergab ein wiederverwendbares Set, welches Prozeßwiederverwendung und den Einbau vorgefertigter Komponenten erlaubt.Google Scholar
  241. 498.
    Vgl. Krasner, H.; et.al. /Lessons learned from a Software Process Modelling System/ S. 92. Die Features sind die Verbindung von Projektmanagementproblemen mit dem Prozeßmanagment, die Möglichkeit graphischer Prozeßmodellierung, die Integration von Produktqualitätsmetriken in das Prozeßmodell und eine Basis und Technik für die Synthese wiederverwendbarer Prozeßbestandteile. Das Werkzeug soll portable und integrierbare Systeme erreichen.Google Scholar
  242. 499.
    Vgl. Curtis, B.; Kellner, M.; Over, J: /Process Modelling/ S. 75.Google Scholar
  243. 500.
    Vgl. Curtis, B.; Kellner, M.; Over, J: /Process Modelling/ S. 75.Google Scholar
  244. 501.
    Vgl. Basili, V. /The Experience Factory/ S. 3_3. Vgl. Koch, G. /The Bootstrap Initiative/ S. 21.Google Scholar
  245. 502.
    Vgl. Curtis, B. /Cognitive Issues/ S. 269f.Google Scholar
  246. 503.
    Vgl. Guindon, R.; Curtis, B. /Control of cognitive processes/ S. 264f.Google Scholar
  247. 504.
    Vgl. Curtis, B. /Cognitive Issues/ S. 269f.Google Scholar
  248. 505.
    Vgl. vetter, M. /Strategic der Anwendungssystementwicklung/ S. 130.Google Scholar
  249. 506.
    Vgl. dazu auch Nawrot, B. /Objectify S. 14. bzw. Johnson, R.; Foote, B. /Designing Reusable Classes/ S. 22ff. bzw. Liebherr, K.; Riel, A.; Demeter, A. /Case Study of Software Growth/ S. 8ff.Google Scholar
  250. 507.
    Vgl. Denert, E. / Software-Engineering/ S. 221ff.Google Scholar
  251. 508.
    Vgl. Denert, E. / Software-Engineering/ S. 48. Er stellt fest, daß in der Systemkonstruktion die Modularisierung teilweise anwendungsabhängig, aber kaum basissystemabhängig, der Datenbasisentwurf sowohl anwendungsabhängig wie auch basissystemabhängig und die Prozeßorganisation kaum anwendungsabhängig, aber basissystemabhängig ist.Google Scholar
  252. 509.
    Vgl. Jameson, K. /Model for Reuse of Software Design Information/ S. 205.Google Scholar
  253. 510.
    Da heute bereits Anwendungsgeneratoren für die Programmierung eingesetzt werden, ist der Beitrag der wiederverwendbaren Module bzw. Codeteile zur Systementwicklung recht gering.Google Scholar
  254. 511.
    Vgl. Prieto-Díaz, R. /Domain Analysis for Reusability/ S. 347.Google Scholar
  255. 512.
    Unter Suchprozeß wird die Arbeit der Präferenzenermittlung, der Abschlätzung der möglichen Lösungsmöglichkeiten und der Auswahl einer Lösungsmöglichkeit verstanden.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