Advertisement

Technologien zur Wiederverwendung von Know-how

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

Zusammenfassung

Es existieren Technologien aus anderen Forschungsdisziplinen, die vergleichbare Ziele (die Wiederverwendung von Know-how) aufweisen wie die Referenzmodellierung. Gegenstand des folgenden Kapitels ist es, diese Technologien zu skizzieren, von der Referenzmodellierung abzugrenzen und zu evaluieren, welche Aspekte ggf. für die (objektorientierte) Referenzmodellierung adaptiert werden können. Von besonderem Interesse sind die Technologien der Patterns, Frameworks und Business Objekte, da diese auf Konzepten des objektorientierten Paradigmas beruhen. Die Software-Wiederverwendung und die Domain Analysis sind unabhängig von einem Paradigma der Softwareentwicklung.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. 341.
    Zur historischen Entwicklung der Wiederverwendung vgl. beispielsweise Prieto-Díaz (1993), S. 61 f.Google Scholar
  2. 342.
    Unter der WWW-Seite http://www.asset.comAVSRD/ASSET/A/1325/elements/a-f.htm. finden sich ca. 600 Literaturangaben zum Thema Wiederverwendung. Aktuelle Links zu Literaturquellen, Organisationen etc. finden sich unter http://www.rhein-neckar.de/~cetus/oo_reuse.html.Google Scholar
  3. 343.
    Vgl. Heß (1993), S. 20.Google Scholar
  4. 344.
    Biggerstaff/Perlis (1989), S. XV. Weitere Definitionen finden sich beispielsweise bei Appelfeller (1995), S. 24 und Nietsch (1996), S. 34.Google Scholar
  5. 345.
    Vgl. Heß (1993), S. 12f.; Meyer (1997), S. 70ff.Google Scholar
  6. 346.
    „A component is a type, class or any other workproduct that has been specifically engineered to be reusable“ Jacobson/Griss/Jonsson (1997), S. 85.Google Scholar
  7. 347.
    Vgl. Fußnote 265.Google Scholar
  8. 348.
    Vgl. Japan GUIDE/SHARE (OOA) (1997), S. 16f.; Appelfeller (1995), S. 34f.Google Scholar
  9. 349.
    Vgl. Meyer (1997), S. 80.Google Scholar
  10. 350.
    Eine Ausnahme stellt Softwareentwicklung auf Basis der Programmiersprache Java dar. Vgl. Arnold/Gosling (1996), S. XVIIf.Google Scholar
  11. 351.
    Das hohe Wiederverwendungspotential von mathematischen Funktionsbibliotheken ist darauf zurückzuführen, daß diese Bibliotheken die in Abschnitt 4.3.1 diskutierten Moduleigenschaften aufweisen.Google Scholar
  12. 352.
    Vgl. Appelfeller (1995), S. 24.Google Scholar
  13. 353.
    Zum Nutzen und zu den Risiken der Softwarewiederverwendung vgl. bspw. Meyer (1997), S. 68ff.Google Scholar
  14. 354.
    Vgl. Jacobson/Griss/Jonsson (1997), S. 9–15; Kauba (1996), S. 20f. und die dort zitierte Literatur; McClure (1997), S. 1ff.; Appelfeller (1995), S. 43ff. und die dort zitierte Literatur.Google Scholar
  15. 355.
    Vgl. Holl/Mitterbauer (1998), S. 63.Google Scholar
  16. 356.
    Vgl. Biggerstaff/Richter (1989), S. 5.Google Scholar
  17. 357.
    Vgl. Heß (1993), S. 20.Google Scholar
  18. 358.
    Vgl. Appelfeller (1995), S. 150.Google Scholar
  19. 359.
    Vgl. Biggerstaff (1994) zitiert bei Kauba (1996), S. 22.Google Scholar
  20. 360.
    Zu diesen und zu differenzierteren Klassifizierungen von Aspekten der Wiederverwendung vgl. Nietsch (1996), S. 35–42; Heß (1993), S. 10ff.Google Scholar
  21. 361.
    Vgl. Nietsch (1996), S. 39f. Zur Problematik des Begriffs der Domäne vgl. Kapitel 2.2. Das Kriterium der Domänenabhängigkeit korrespondiert mit dem diskutierten Merkmal der inhaltlichen Individualität von Informationssystemmodellen.Google Scholar
  22. 362.
    Vgl. Kapitel 5.4.Google Scholar
  23. 363.
    Vgl. Raue (1996), S. 3; Endres (1988), S. 87f.Google Scholar
  24. 364.
    Vgl. Biggerstaff/Perlis (1989), S. XIX.Google Scholar
  25. 365.
    Vgl. Rost (1997), S. 360.Google Scholar
  26. 366.
    Vgl. Prieto-Díaz (1993), S. 65.Google Scholar
  27. 367.
    Vgl. McClure (1997), S. 8; Adolf/Fillhardt (1993), S. 36ff.Google Scholar
  28. 368.
    Zu abstrakten Datentypen vgl. Fußnote 137.Google Scholar
  29. 369.
    Zu generischen Modulen vgl. Kapitel 5.1.2.3.Google Scholar
  30. 370.
    Zum Konzept der Vererbung vgl. Kapitel 3.2.2.Google Scholar
  31. 371.
    Zu den Erfolgsfaktoren der Softwarewiederverwendung vgl. Jacobson/Griss/Jonsson (1997), S. 8f.Google Scholar
  32. 372.
    Vgl. Raue (1996), S. 51.Google Scholar
  33. 373.
    Vgl. Nietsch (1996), S. 70.Google Scholar
  34. 374.
    Vgl. Fußnote 274.Google Scholar
  35. 375.
    Zu organisatorischen Anforderungen zur Etablierung der Wiederverwendung vgl. Nietsch (1996), S. 57–70; Appenzeller (1995), S. 46; Heß (1993), S. 182–246.Google Scholar
  36. 376.
    Vgl. Meier/Röpert (1994), S. 48f. Zu entsprechenden Vorgehensmodellen vgl. Appelfeller (1995), S. 110–119; Heß (1993), S. 23 und 198–206.Google Scholar
  37. 377.
    Zu den Anforderungen an Komponenten vgl. Nietsch (1996), S. 51 ff. Eine wesentliche Anforderung bei der Erstellung wiederverwendbarer Komponenten ist es, die richtige Komponentengröße zu modellieren. Komplexe Komponenten decken ein breites Aufgabenspektrum ab und erlauben eine signifikante Produktivitätssteigerung bei einer Wiederverwendung. Vgl. Biggerstaff/Perlis (1989), S. 2. Andererseits sinkt durch die hohe Komponentenkomplexität neben der Anpaßbarkeit insbesondere die Kombinierbarkeit dieser Komponente. Zur negativen Auswirkung der Komponentengröße auf die Anpaßbarkeit vgl. Guntermann/Popp (1998), S. 17f.; Biggerstaff/Perlis (1989), S. XVf; Biggerstaff/Richter (1989), S. 5. Biggerstaff und Richter betonen die Wichtigkeit einer geeigneten Repräsentation für die Wiederverwendung. Vgl. Biggerstaff/Richter (1989), S. 12.Google Scholar
  38. 378.
    Zu Anforderungen an Werkzeuge für die Verwaltung von Komponenten vgl. Heß (1993), S. 207–222.Google Scholar
  39. 379.
    Zur Generierung und Komposition von Referenzmodellen vgl. Kapitel 6.4.2.2.Google Scholar
  40. 380.
    Synonym zum Begriff ‚Domain Analysis‘ wird der Begriff ‚Domain Modelling‘ bzw. übersetzt ‚Domänenanalyse‘ verwendet. Zur Entwicklung der Domain Analysis vgl. Prieto-Diaz (1990), S. 48f.Google Scholar
  41. 381.
    Prieto-Diaz (1990), S. 47.Google Scholar
  42. 382.
    Welche Aspekte die Problemdomäne umfaßt ist kontextabhängig. Im Rahmen der DA wird i. d. R. die Abgrenzung der Problemdomäne anhand der betrachteten Anwendungssysteme vorgenommen. Alternativ kann die Abgrenzung der Problemdomäne auch nach rein fachlichen Gesichtspunkten erfolgen. Zum Begriff der Problemdomäne vgl. Arango (1994), S. 18; Simos et al. (1996), S. 20f.Google Scholar
  43. 383.
    Zum Nutzen der Domain Analysis vgl. Sametinger (1997), S. 163.Google Scholar
  44. 384.
    Eine Skizzierung und ein Vergleich verschiedener DA-Methoden findet sich bei Arango. Vgl. Arango (1994).Google Scholar
  45. 385.
    Vgl. Arango (1994), S. 33–37.Google Scholar
  46. 386.
    Vgl. Sametinger (1997), S. 165.Google Scholar
  47. 387.
    Vgl. Sametinger (1997), S. 160.Google Scholar
  48. 388.
    Die Notwendigkeit der Abbildung von Varianten wird beispielsweise in der DA-Methode ODM explizit thematisiert. Vgl. Simos (1995), S. 4f.; Simos et al. (1996), S. 170.Google Scholar
  49. 389.
    Vgl. Gamma et al. (1996), S. 2; Fowler (1997), S. 8. Eine Liste mit Veröffentlichungen und weiteren Links zum Thema Patterns findet sich beispielsweise unter http://www.rhem-neckar.de/~cetus/oo_patterns.html.Google Scholar
  50. 390.
    Vgl. Fowler (1997), S. 7.Google Scholar
  51. 391.
    Vgl. McGregor/Keddy (1996), S. 8.Google Scholar
  52. 392.
    Zum Nutzen von Patterns vgl. Raue (1996), S. 50; Quibeldey-Cirkel (1996), S. 327; Hellenack (1997), S. 23.Google Scholar
  53. 393.
    Vgl. Quibeldey-Cirkel (1996), S. 327.Google Scholar
  54. 394.
    Diese Beschreibungsform geht auf Alexander zurück, der Muster für Gebäude und Städte entwic??kelt hat. Vgl. Alexander (1979), S. 247 zitiert bei Hammel/Schlitt/Wolf (1998), S. 28. Gamma erweitert dieses Beschreibungsschema um weitere Elemente. Vgl. Gamma et al. (1996), S. 7ff.Google Scholar
  55. 395.
    Zur Klassifizierungen von Mustern vgl. Gamma et al. (1996), S. 11ff.; Quibeldey-Cirkel (1996), S. 326f.; Hammel/Schlitt/Wolf (1998), S. 28f.Google Scholar
  56. 396.
    Zu Idiomen vgl. Coplien (1992), S. 2f.Google Scholar
  57. 397.
    Zum Begriff ‚Strukturbaustein‘ vgl. Rosemann (Komplexität) (1996), S. 226.Google Scholar
  58. 398.
    Vgl. Gamma et al. (1996).Google Scholar
  59. 399.
    Zu einer ausführlichen Beschreibung des Pattern vgl. Gamma et al. (1996), S. 4ff.Google Scholar
  60. 400.
    Zur Kombination verschiedener Muster vgl. Buschmann (1996).Google Scholar
  61. 401.
    Vgl. Gamma et al. (1996), S. 4ff.Google Scholar
  62. 402.
    Balzert gebraucht den Begriff ‚OOA-Muster‘ Vgl. Balzert (1996), S. 349ff. Boreham verwendet die Begriffe ‚fragment‘ und ‚building block‘. Vgl. Boreham (1994), S. 68f.Google Scholar
  63. 403.
    Vgl. Fowler (1997).Google Scholar
  64. 404.
    Vergleichsweise früh wurde der Begriff ‚Business Pattern‘ in folgenden Quellen verwendet: Evitts (1996); Shelton(1996).Google Scholar
  65. 405.
    Die Idee der Patterns korrespondiert mit den Referenzbausteinen für Prozeßmodelle von Rosemann. Vgl. Rosemann (Komplexität) (1996), S. 227. Remme verwendet den Begriff ,Prozeßpartiker. Vgl. Remme (1996).Google Scholar
  66. 406.
    Vgl. Hellenack (1997), S. 23; Martin/Riehle/Buschmann (1998), S. 392; Hammel/Schlitt/Wolf (1998), S. 29. Hay hat eine Menge von Datenmodellen für spezifische betriebswirtschaftliche Anwendungsbereiche erstellt und bezeichnet diese als Data Model Patterns. Vgl. Hay (1996).Google Scholar
  67. 407.
    Weitere Beispiele zu Business Patterns finden sich bei Fowler (1997); Balzert (OO) (1996), S. 214ff.; Hellenack (1997); Boyd (1998).Google Scholar
  68. 408.
    Zu einer ausführlichen Beschreibung des Pattern vgl. Boyd (1998), S. 399ff.Google Scholar
  69. 409.
    Zur Erstellung wiederverwendbarer Patterns für die Untemehmensmodellierung vgl. Hammel/Schlitt/Wolf (1998), S. 29ff.Google Scholar
  70. 410.
    Vgl. zu den folgenden Ausführungen Hellenack (1997), S. 29ff.Google Scholar
  71. 411.
    Vgl. Fowler (1997), S. 10.Google Scholar
  72. 412.
    Zur Definition des Begriffes ‚Framework‘ vgl. Lewis et al. (1995), S. 34f.; Appelfeller (1995), S. 67f; Nietsch (1996), S. 118f.; Bäumer et al. (1995), S. 49. Eine umfangreiche Sammlung von Links zum Thema Frameworks findet sich beispielsweise unter http://www.rhein-neckar.de/~cetus/oo_frameworks.html.Google Scholar
  73. 413.
    Zu den Zielen der Frameworktechnologie vgl. beispielsweise Nietsch (1996), S. 121. Zu den Vor- und Nachteilen des Frameworkeinsatzes vgl. Appelfeller (1995), S. 74f.; Johnson/Russo (1991), S. 29f.; o. V. (Frameworks) (1995), S. 16.Google Scholar
  74. 414.
    Die Notwendigkeit, Frameworks an Stelle einzelner Klassen wiederzuverwenden, resultiert aus der zu geringen Granularität einzelner Klassen. Vgl. Kapitel 3.3 und Firesmith (1993), S. 6.Google Scholar
  75. 415.
    Beispiele für Benutzeroberflächen-Frameworks finden sich bei Appelfeller (1995), S. 67.Google Scholar
  76. 416.
    Eine Übersicht über existierende Frameworks findet sich beispielsweise in Heß (1993), S. 56ff. und Nietsch (1996), S. 119f. Zu einer Klassifizierung von Frameworks vgl. Firesmith (1993), S. 6.Google Scholar
  77. 417.
    Vgl. Heß (1993).Google Scholar
  78. 418.
    Vgl. Otterbein (1994).Google Scholar
  79. 419.
    Vgl. Nietsch (1996).Google Scholar
  80. 420.
    Vgl. Appelfeller (1995).Google Scholar
  81. 421.
    Aktuelle Informationen finden sich im WWW unter http://www.micado.de/home.htm.
  82. 422.
    Aktuelle Informationen finden sich im WWW unter http://www.marcam.com/protean/.
  83. 423.
    Vgl. Peter/Vollmer/Stripf (1997); Andrews/DeGiglio (1998); Andrews (1998). Aktuelle Informationen finden sich im WWW unter http://www.ibm.com/Java/Sanfrancisco.
  84. 424.
    Vgl. Johnson/Foote (1988), S. 26 zitiert bei Heß (1993), S. 55; Raue (1996), S. 42; Birrer/Bischoffberger/ Eggenschwiler (1995), S. 19f.; Frank (Framework) (1997), S. 167.Google Scholar
  85. 425.
    Zum Begriff und der Verwendung von ‚hot spots‘ in Frameworks vgl. Pree (1997), S. 34ff.Google Scholar
  86. 426.
    Vgl. Lewis et al. (1995), S. 33f.Google Scholar
  87. 427.
    Vgl. Bäumer et al. (1995), S. 53.Google Scholar
  88. 428.
    Zu Anforderungen an Frameworks vgl. Bäumer et al. (1995), S. 74.Google Scholar
  89. 429.
    Vgl. Stahlknecht/Hasenkamp (1997), S. 355.Google Scholar
  90. 430.
    Die Object Management Group ist eine 1989 gegründete Non-Profit-Organisation, die das Ziel hat, die Entwicklungen im Bereich Objektorientierung voranzutreiben und eine Referenzarchitektur für verteilte objektorientierte Systeme zu schaffen (Object Management Architecture). Zentrales Element dieser Architektur ist Corba (Common Object Requestbroker Architecture). Vgl. http://www.omg.org.
  91. 431.
    Object Management Group (1996), S. 18. Weitere Definitionen und Abgrenzungen des Begriffs finden sich beispielsweise bei Nüttgens/Zimmermann (1998), S. 28.; Hertel (1995), S. 36; Guntermann/Popp (1998), S. ll;Weske(1999), S.4f.Google Scholar
  92. 432.
    Hier wird primär die Sichtweise der OMG vertreten. Vgl. Object Management Group (1996), S. 18. Andere Autoren haben ein ähnliches Begriffsverständnis, betonen aber andere Aspekte. Vgl. Sims (1994), S. 32 und S. 278ff; Guntermann (1998), Kapitel 4 und 5; Guntermann/Popp (1998), S. 11f.Google Scholar
  93. 433.
    Vgl. Sutherland (1997).Google Scholar
  94. 434.
    Das Konzept der Business Objekte ist eine mögliche Realisierung der Component Ware-Idee. Zum Begriff ‚Component Ware‘ vgl. beispielsweise Malischewski (1995); Linssen/Seidel (1997); Frost/Allen (1997); Claußen (1997); Berg (1997).Google Scholar
  95. 435.
    Zu den Zielen des Business Objekt-Konzepts aus Sicht der OMG vgl. Object Management Group (BOCA) (1998), S. 19. Die dargestellten Zielsetzungen werden prinzipiell auch von solchen Unternehmen verfolgt, die eine von der OMG abweichende Auffassung des Begriffes ‚Business Objekt‘ haben. Vgl. Foley (1996), S. 52ff. Beispielsweise hat die Firma SAP ihr funktionsorientiertes System R/3 in ca. 170 Business Objekte zerlegt, um das Customizing des Systems zu erleichtern. Vgl. SAP (1997), S. 6; Graf (1997), S. 69; Guntermann/Popp (1998), S. 12ff.Google Scholar
  96. 436.
    Zur Forderung adaptiver Anwendungssysteme und zur Kopplung von Business Engineering und Software Engineering vgl. Taylor (1995), S. 7f.Google Scholar
  97. 437.
    Zur Notwendigkeit der Standardisierung im Rahmen des Business Objekt-Konzepts vgl. Object Management Group (1995), S. 20ff. Zum aktuellsten Stand der Normierungsbestrebungen der Business Object Domain Task Force vgl. http://www.dataaccess.com/bodtf.
  98. 438.
    Zu einer Liste aktuell existierender Domain Task Forces vgl. http://www.omg.org/about/sigs.htm.
  99. 439.
    Zu einer Darstellung der Common Object Requestbroker Architecture vgl. bspw. Grotehen/Dittrich (1995).Google Scholar
  100. 440.
    Zu einer Darstellung der Business Object Component Architecture vgl. Object Management Group (BOCA) (1998) und Object Management Group (Interoperability) (1998).Google Scholar
  101. 441.
    Zum modellgestützten Customizing vgl. Scheer/Hoffmann/Wein (1994), S. 93f.; Zencke (1996).Google Scholar
  102. 442.
    Zwischen den vorgestellten Konzepten bestehen weitere Beziehungen. Beispielsweise lassen sich Frameworks durch Patterns dokumentieren (vgl. Gamma et al. (1996), S. 32), und Frameworks können aus Business Objekten aufgebaut sein.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