Advertisement

Objektorientierte Referenzmodellierung

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

Zusammenfassung

In der Literatur zur objektorientierten Softwareentwicklung wird vielfach argumentiert, daß aus den spezifischen Konzepten des objektorientierten Paradigmas unter anderem eine höhere Wiederverwendbarkeit, Anpaßbarkeit und Verständlichkeit der Anwendungssysteme bzw. der entsprechenden Anwendungssystemmodelle resultiert.443 In Kapitel 4.3 wurden Anforderungen an Referenzmodelle erarbeitet, die zu den genannten Vorteilen der Objektorientierung korrespondieren. Wiederverwendbarkeit ist eine der Referenzmodellierung inhärente Anforderung, die durch die elementaren Anforderungen Klarheit, modularer Aufbau, Allgemeingültigkeit und Anpaßbarkeit determiniert wird. Anhand dieser elementaren Anforderungen erfolgt eine Bewertung der Konzepte des objektorientierten Paradigmas für die Referenzmodellierung..

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. 443.
    Eine erste kritische Bewertung dieser Potentiale des objektorientierten Paradigmas wurde in Kapitel 3.3 vorgenommen.Google Scholar
  2. 444.
    Vgl. dazu die zitierte Literatur in Kapitel 3.3.Google Scholar
  3. 445.
    Diese Aussage bezieht sich i. d. R. auf die Modellierung betriebswirtschaftlicher Sachverhalte. Der Nutzen der Objektorientierung bzw. der Kapselung von Struktur und Verhalten im Rahmen der GUI-Programmierung oder vergleichbaren Anwendungsgebieten ist unbestritten. Zum Nutzen der Objektorientierung im Rahmen der GUI-Entwicklung vgl. bspw. Cox/Hunt (1986).Google Scholar
  4. 446.
    Die Abbildung von Makroverhalten wird in Kapitel 6.2.3 thematisiert.Google Scholar
  5. 447.
    Zur Vorteilhaftigkeit der Objektorientierung bei der Abbildung anwendungsnaher Abstraktionen vgl. bspw. Taylor (1995), S. 30f.Google Scholar
  6. 448.
    Vgl. Adolf/Fillhardt (1993), S. 38.Google Scholar
  7. 449.
    Zu den wünschenswerten Eigenschaften eines Moduls vgl. Kapitel 4.3.1.Google Scholar
  8. 450.
    Die Syntax der Methodenschnittstelle ist im Rahmen der fachkonzeptuellen Modellierung von untergeordneter Bedeutung.Google Scholar
  9. 451.
    Zum Nutzen des Information Hiding bei der Integration von Struktur- und Verhaltenssicht in konzeptuellen Informationssystemmodellen vgl. Kapitel 6.2.4.Google Scholar
  10. 452.
    Vgl. dazu die Ausführungen in Kapitel 6.1.4.Google Scholar
  11. 453.
    Vgl. Raue (1996), S. 4.Google Scholar
  12. 454.
    Hot Spots sind explizit definierte Anpassungspunkte in einem generischen Modell, die bei der Ableitung eines spezifischen Modells anzupassen sind. Vgl. Japan GUIDE/SHARE (OOA) (1997), Abschnitt 2.2 (3).Google Scholar
  13. 455.
    Jacobson erweitert Anwendungsfallbeschreibungen um eine use case-inheritance. Dies ist jedoch keine Vererbung im Sinne der Objektorientierung. Vgl. Jacobson/Griss/Jonsson (1997), S. 127.Google Scholar
  14. 456.
    Zur Darstellung der View-Vererbung vgl. Kapitel 3.2.2.3.Google Scholar
  15. 457.
    Zum Nutzen des Information Hiding bei der Integration von Struktur- und Verhaltenssicht in konzeptuellen Informationssystemmodellen vgl. Kapitel 6.2.4.Google Scholar
  16. 458.
    Vergleiche verschiedener existierender objektorientierter Analysemethoden finden sich beispielsweise in Stein (1996); Schäfer (1994); Stein (1993); Heß/Scheer (OOD) (1992).Google Scholar
  17. 459.
    Zur geschichtlichen Entwicklung der UML vgl. beispielsweise Oestereich (1997), S. 20f.Google Scholar
  18. 460.
    Die Object Management Group ist eine Non-Profit-Organisation, die sich zum Ziel gesetzt hat, die Entwicklungen im Bereich der Objektorientierung voranzutreiben und eine Referenzarchitektur für verteilte objektorientierte Systeme zu schaffen. Zum aktuellen Stand der Normierungsbestrebungen der UML vgl. http://www.omg.org oder auch http://www.rational.com/uml/index.html. Konkurrierend zur OMG bemüht sich das OPEN Konsortium um die Standardisierung von objektorientierten Modellierungsmethoden. Die entwickelte Notation OML wird hier nicht berücksichtigt. Vgl. dazu Firesmith/Henderson-Sellers/Graham (1997).
  19. 461.
    Vgl. Reinhold (1997). Zu den Vorgehensmodellen anderer OOA-Methoden vgl. beispielsweise Rumbaugh et al. (1991); Coad/Yourdon (1991); Booch (1994), S. 229–266; Balzert (1997).Google Scholar
  20. 462.
    Zur Einführung in die UML vgl. Fowler (1997); Oestereich (1997); Burkhardt (1997). Die exakte Spezifikation der UML Version 1.1 findet sich in Rational et al. (Semantics) (1997) und Rational et al. (Notation) (1997).Google Scholar
  21. 463.
    Zur Abbildung von Integritätsregeln wurde eine eigene ergänzende Modellierungssprache zur UML entwickelt, die Object Constraint Language. Vgl. Rational (1997). Zur Abbildung von Integritätsregeln und Business Rules in objektorientierten Analysemodellen vgl. Odell (1998), S. 97–118; Moriarty (1993). Zu einer allgemeinen Einführung in die Modellierung von Business Rules vgl. bspw. Knolmayer/Herbst (1995); Knolmayer/Herbst (1993).Google Scholar
  22. 464.
    Die Abbildung von Dynamik ist nur dann notwendig, wenn ausführbare Modelle erstellt werden sollen, z. B. für Zwecke einer Simulation. Referenzmodelle dienen der Dokumentation fachlichen (betriebswirtschaftlichen) Wissens, was i. d. R. keine Dokumentation detaillierter Ablaufregeln erfordert.Google Scholar
  23. 465.
    Entsprechend der Intention der Referenzmodellierung werden nur Klassen berücksichtigt, die einen engen Bezug zur Problemdomäne aufweisen und nur die fachliche Logik eines Systems beinhalten. Zu einer Charakterisierung von Systemelementen, die im Rahmen der fachkonzeptuellen Modellierung betrachtet werden, vgl. Kapitel 3.2.1.3.Google Scholar
  24. 466.
    Konstruktormethoden sind Klassenmethoden, die zur zugehörigen Klasse eine Instanz (Objekt) erzeugen. Die Methode Auftrag_anlegen in der Klasse AuftragsBestand ist keine Konstruktormethode, da sie die Erzeugung eines Objekts einer anderen Klasse, der Klasse Auftrag, initiiert.Google Scholar
  25. 467.
    Oestereich(1997),S. 171.Google Scholar
  26. 468.
    Auch die Diagramme der Verhaltenssicht sind für diesen Zweck ungeeignet. Das Zustandsübergangsdiagramm veranschaulicht beispielsweise nur die möglichen Zustandsübergänge genau eines Objekts. Vgl. dazu Kapitel 6.2.2.Google Scholar
  27. 469.
    Coad und YOURDON verwenden für diesen Zweck Subjects. Vgl. Coad/Yourdon (1991), S. 106–118.Google Scholar
  28. 470.
    Zu den Begriffen ‚Kohäsion‘ und ‚Kopplung‘ vgl. Kappel/Schreffl (1996), S. 202ff.; Myers (1976), S. 92ff.; Hruschka (1986), S. 73.Google Scholar
  29. 471.
    Die Clusterung ist dann optimal, wenn die resultierenden Pakete die in Kapitel 4.3.1 erarbeiteten Anforderungen an Module erfüllen.Google Scholar
  30. 472.
    Vgl. Coad/Yourdon (1991), S. 111; Schader/Rundshagen (1994), S. 99ff.Google Scholar
  31. 473.
    Vgl. Appelfeller (1995), S. 150.Google Scholar
  32. 474.
    Vgl. dazu die Darstellung in Abb. 3.1.Google Scholar
  33. 475.
    Vgl. dazu beispielsweise das Unternehmensdatenmodell von SCHEER. Vgl. Beilage zu Scheer (1990). Dieses Datenmodell enthält zahlreiche Relationshiptypen, die nur einer Zuordnung von Entitytypen dienen, aber keine für die Modellbildung relevante betriebswirtschaftliche Semantik aufweisen.Google Scholar
  34. 476.
    Sauer beschreibt, wie ein Datenmodell in ein Klassenmodell überführt werden kann. Vgl. Sauer (1995), S. 61ff.Google Scholar
  35. 477.
    Vgl. Ferstl/Sinz (1998), S. 141–153. Eine weitere Erweiterung der ERM-Darstellung stellt die SAP-SERM-Notation der SAP dar. Vgl. Seubert (1996).Google Scholar
  36. 478.
    Inwieweit die zusätzliche Abbildung von Methoden der Modellklarheit nutzt, wurde bereits in Kapitel 6.1.1 thematisiert.Google Scholar
  37. 479.
    Es existieren empirische Untersuchungen, die belegen, daß ER-Modelle nicht von allen Modellesern als anschaulich empfunden werden. Vgl. Hitchman (1995); Goldstein/Storey (1990) zitiert bei Frank/Prasse (1997), S. 2. Empirische Untersuchungen, welche die Anschaulichkeit von ER-Modellen und OOA-Mo-dellen vergleichen, konnten nicht recherchiert werden.Google Scholar
  38. 480.
    Zu einer Übersicht und Bewertung verschiedener Verdichtungsoperationen in konzeptionellen Datenmodellen vgl. Boßhammer/Winter (1995) und die dort angegebene Literatur.Google Scholar
  39. 481.
    Vgl. Fowler (1997), S. 43–51. Use Cases wurden von der OOA-Methode durch Jacobson et al. in die UML übertragen. Vgl. Jacobson et al. (1992), S. 159–166. Vergleichbar mit Use Cases sind die ‚scripts‘ der Object Behavior Analysis. Vgl. Rubin/Goldberg (1992), S. 50ff.; Berard (1998), S. 4f.Google Scholar
  40. 482.
    Vgl. Jacobson/Ericson/Jacobson (1994), S. 102.Google Scholar
  41. 483.
    Vgl. Oestereich (1997), S. 87f. Zur Modellierung von Geschäftsprozessen mit Anwendungsfallbeschreibungen vgl. Yourdon et al. (1996), S. 71–81.Google Scholar
  42. 484.
    Burkhardt vertritt beispielsweise die Auffassung, daß Anwendungsfall-Beschreibungen zur Dokumentation grobkörniger Prozesse verwendet werden. Vgl. Burkhardt (1995), S. 14. Zum Verhältnis von Anwendungsfallbeschreibungen und EPK vgl. Loos/ Allweyer (1998), S. 13f.Google Scholar
  43. 485.
    Vgl. Berard (1998), S. 4.Google Scholar
  44. 486.
    Zur Veranschaulichung dieses und der folgenden Diagramme wird jeweils ein einfaches Beispiel verwendet: Die Kundenaufträge eines Unternehmens werden in der Abteilung Auftragserfassung in das Auftragsverwaltungssystem eingegeben. Bei Aufträgen mit einem Auftragswert größer 1000 DM ist eine Kreditwürdigkeitsprüfung des Kunden vorzunehmen. Anschließend wird die Verfügbarkeit der bestellten Artikel geprüft. Danach werden die Aufträge an das Liefersystem übergeben.Google Scholar
  45. 487.
    Vgl. Bungert/Heß (1995), S. 54Google Scholar
  46. 488.
    Vgl. Meyer (1997), S. 738ff.Google Scholar
  47. 489.
    Vgl. Berard(1998), S. 7.Google Scholar
  48. 490.
    Zu einem Ansatz Anwendungsfallbeschreibungen und Klassendiagramme zu verbinden vgl. Kösters/Pagel/ Winter (1998), S. 118.Google Scholar
  49. 491.
    Zu einer ausführlichen Darstellung des Sequenzdiagramms vgl. Rational et al. (Notation) (1997), S. 80–87.Google Scholar
  50. 492.
    Vgl. Scheer/Nütgens/Zimmermann (1997), S. 14.Google Scholar
  51. 493.
    Zu einer ausführlichen Darstellung des Kollaborationsdiagramms vgl. Rational et al. (Notation) (1997), S. 88–102.Google Scholar
  52. 494.
    Vgl. Scheer/Nütgens/Zimmermann (1997), S. 13f.Google Scholar
  53. 495.
    Zu einer ausführlichen Darstellung des Zustandsdiagramms vgl. Rational et al. (Notation) (1997), S. 103–120.Google Scholar
  54. 496.
    Vgl. Oestereich (1998), S. 49; Scheer/Nütgens/Zimmermann (1997), S. 15; Bungert/Heß (1995), S. 55.Google Scholar
  55. 497.
    Vgl. Martin/Odell (1992), S. 325f.Google Scholar
  56. 498.
    Vgl. Oestereich (1998), S. 49f.Google Scholar
  57. 499.
    Zu einer ausführlichen Darstellung des Aktivitätsdiagramms vgl. Rational et al. (Notation) (1997), S. 121–131.Google Scholar
  58. 500.
    Aktivitätsdiagramme weisen eine gewisse Ähnlichkeit zur nachfolgend vorgestellten objektorientierten EPK auf. Oestereich zeigt die Beziehungen zwischen Aktivitätsdiagrammen und EPK auf und verwendet entgegen der originären Definition der UML Aktivitätsdiagramme auch zur Darstellung von Abläufen, an denen mehrere Objekte beteiligt sind. Vgl. Oestereich (1998), S. 49ff.Google Scholar
  59. 501.
    Vgl. Loos/Allweyer (1998), S. 8f.; Nüttgens/Zimmermann (1998), S. 2; Bungert/Heß (1995), S. 55; Schienmann/Gremeyer/Lindner (1994), S. 85; Frank/Prasse (1997), S. 3. Zum grundsätzlichen Problem der Beschreibung von Dynamik in objektorientierten Modellen vgl. Dischinger (1995), S. 219.Google Scholar
  60. 502.
    Vgl. Nüttgens/Zimmermann (1998); Scheer/Nütgens/Zimmermann (1997); Bungert/Heß (1995).Google Scholar
  61. 503.
    Zu den folgenden Ausführungen vgl. Loos/Allweyer (1998), S. 9–13.Google Scholar
  62. 504.
    Beispielsweise wurde die Verhaltenssicht des Handelsreferenzmodells von Becker und Schütte mit EPK dokumentiert. Vgl. Becker/Schütte (1996).Google Scholar
  63. 505.
    Verschiedene Autoren berücksichtigen auch das Nachrichtenkonzept bei der Integration von EPK und Klassendiagrammen. Vgl. Bungert/Heß (1995), S. 57; Scheer/Nütgens/Zimmermann (1997), S. 18ff. Ein Ereignis der EPK korrespondiert bei diesen Ansätzen mit einem Nachrichtenaufrufeines Objekts. Eine derartige Integration von EPK und Klassendiagrammen ist im Rahmen der fachkonzeptuellen Modellierung abzulehnen, da diese Darstellung die Modellkonstruktion unnötig verkompliziert und die Klarheit und Flexibilität der (Referenz-) Modelle negativ beeinflußt.Google Scholar
  64. 506.
    Zur Kennzeichnung von Objektwechseln beschriftet Remme die Kontrollflußkanten der EPK mit (1 :n) bzw. (n:l). Vgl. Remme (1996), S. 121. Zu einer Detaillierung dieses Ansatzes vgl. Schütte (Referenzmodellierung) (1997), S. 228ff.Google Scholar
  65. 507.
    Zu den möglichen Beziehungen zwischen Struktur- und Verhaltensmodell vgl. Loos/Allweyer (1998), S. 11.Google Scholar
  66. 508.
    Zur Integration von Daten- und Prozeßmodell bei einer Generalisierung/Spezialisierung im Datenmodell vgl. Schütte (Referenzmodellierung) (1997), S. 227ff.Google Scholar
  67. 509.
    Es wird unterstellt, daß sich abgebildete Varianten sowohl in der Struktur- als auch in der Verhaltenssicht auf die gleichen Objekte beziehen. D. h., der Fall, daß im Klassenmodell ein einzelnes Objekt spezialisiert wird, während in der Prozeßsicht aufgrund des höheren Abstraktionsniveaus eine Menge dieser Objekte betrachtet werden, wird hier vernachlässigt. Vgl. dazu Schütte (Referenzmodellierung) (1997), S. 227ff.Google Scholar
  68. 510.
    Je nach Zielsetzung der Modellbildung kann eine Sicht dominieren und einen höheren Konkretisierungsgrad der Modelle erforderlich machen.Google Scholar
  69. 511.
    Zum Zuordnungsproblem von Methoden zu Klassen vgl. Hruschka (1996); Yourdon et al. (1996), S. 355ff.Google Scholar
  70. 512.
    Vgl. dazu das Beispiel in Abb. 6.13 d). I. d. R. wird es jedoch in fachkonzeptuellen Modellen keine detaillierte Beschreibung der Funktionsweise einer Methode geben, da im Fachkonzept lediglich das WAS und nicht das WIE dokumentiert wird.Google Scholar
  71. 513.
    Zum korrespondierenden Strukturmodell mit der abgebildeten Vererbungshierarchie vgl. Abb. 6.15.Google Scholar
  72. 514.
    Auf die explizite Darstellung der Informationssystemmodellarchitektur des dargestellten Ansatzes zur objektorientierten Referenzmodellierung in Form eines Metamodells wird hier verzichtet, da sowohl die EPK-Notation als auch die UML in der angegebenen Literatur exakt spezifiziert werden. Die Integration von EPK und UML ist trivial und wurde zuvor hinreichend genau beschrieben.Google Scholar
  73. 515.
    Ergänzend ist anzumerken, daß die dargestellten Vorteile für die objektorientierte Analyse allgemein Gültigkeit haben und nicht nur für die objektorientierte Referenzmodellierung von Bedeutung sind.Google Scholar
  74. 516.
    Zu betonen ist, daß es sich um eine Abbildung rein fachlicher Entscheidungen und nicht um die Dokumentation implementierungstechnischer Entscheidungen handelt.Google Scholar
  75. 517.
    Variantenbehälter können als Stereotyp bzw. als redefinierender Stereotyp modelliert werden, um dieses Konstrukt in die Unified Modeling Language zu integrieren. Zur Verwendung von Stereotypen vgl. Oestereich (1997), S. 177f. Zu einer Klassifikation unterschiedlicher Stereotypen und zur Semantik redefinierender Stereotypen vgl. Joos/Berner/Glinz (1998), S. 112ff. Ein Stereotyp wird in der UML durch doppelte Winkelklammern gekennzeichnet (‚≪≫‘).Google Scholar
  76. 518.
    Die Anforderungen an ein Modellierungswerkzeug, das die in Kapitel 6.3 vorgestellten Modellierungstechniken unterstützt, werden in Kapitel 8 skizziert.Google Scholar
  77. 519.
    Vgl. Kapitel 6.2.4, Abb. 6.15.Google Scholar
  78. 520.
    EBNF (erweiterte Backus-Naur-Form) dienen der kompakten Spezifikation der Syntax einer Sprache über eine Menge grammatikalischer Regeln. Diese Regeln (Produktionen) bestehen aus einem einzelnen Strukturnamen (z. B. <Parameter>), aus einem Metasymbol ‚::= ‘ (zu übersetzen als ‚besteht aus‘) und einer Folge von Elementen. Elemente repräsentieren entweder Metasymbole, Terminalsymbole oder Nicht-Terminalsymbole. Metasymbole sind neben dem ‚besteht aus‘ (‚::=‘) das ODER (‚|‘) und die geschweiften Klammern (‚{}‘). Geschweifte Klammern dienen der Abbildung sich beliebig oft wiederholender Elemente. Terminalsymbole sich Bestandteil der zu spezifizierenden Sprache und werden in Hochkomma eingeschlossen. Nicht-Terminalsymbole werden durch spitze Klammern (‚<>‘) hervorgehoben, und Nicht-Terminalsymbole der rechten Seite einer Regel sind bei der Ableitung einer Sprache solange zu ersetzen, bis nur noch Terminalsymbole übrig bleiben. Zur Beschreibung von kontextfreien Grammatiken mit BNF bzw. EBNF vgl. bspw. Louden (1994), S. 83–102.Google Scholar
  79. 521.
    Um die Darstellung zu vereinfachen, wurde auf eine Parametrisierung der Kanten verzichtet.Google Scholar
  80. 522.
    Im Rahmen des Projekts KEBBA wird versucht, eine betriebswirtschaftliche Systematisierung von Merkmalen vorzunehmen und aus abstrakten betriebswirtschaftlichen Merkmalen detaillierte IV-Anforderungen abzuleiten. Ergebnis der unternommenen Experimente ist, daß eine solche Abbildung nicht möglich bzw. zumindest problematisch ist. Vgl. Mertens et al. (1997), S. 74ff. Dieses Ergebnis läßt sich auf die hier vorliegende Problemstellung übertragen.Google Scholar
  81. 523.
    Beispiele für die aufgeführten Beziehungskategorien finden sich in der Fallstudie in Kapitel 7.2.Google Scholar
  82. 524.
    Zu entsprechenden Beispielen vgl. Kapitel 7.4.Google Scholar
  83. 525.
    Die Anforderungen an ein Modellierungswerkzeug, das die in Kapitel 6.3 vorgestellten Modellierungstechniken unterstützt, werden in Kapitel 8 skizziert.Google Scholar
  84. 526.
    Zur Spezialisierung von Geschäftsprozessen vgl. Kueng/Schrefl (1995), S. 87ff.; Müller-Luschnat/Hesse/ Heydenreich(1993), S. 82ff.Google Scholar
  85. 527.
    Lang definiert Referenzprozeßbausteine, die eine Ablaufbeschreibung enthalten, als ein Objekt. Vgl. Lang (1997), S. 49f. MÜller-Luschnat, Hesse und Heydenreich verwenden analog den Begriff ‚Vorgangsklasse‘. Vgl. Müller-Luschnat/Hesse/Heydenreich (1993), S. 82f. Dieser Begiffsdefinition wird hier nicht gefolgt, da Klassen im Sinne des objektorientierten Paradigmas lediglich das Mikroverhalten und die Mikrostruktur eines Systemelements beschreiben. Die Verwendung der Begriffe ‚Klasse‘ bzw. ‚Objekt‘ für Systemelemente, die das Makroverhalten von Systemen beschreiben, verändert den Charakter dieser Begriffe und kann zu Mißverständnissen führen.Google Scholar
  86. 528.
    Die Elimination von Elementen des Basismodells in Erweiterungsmodellen wird in Kapitel 6.3.3.3 veranschaulicht.Google Scholar
  87. 529.
    Zur Spezialisierung und Decomposition von Prozessen vgl. Lang (1997), S. 50ff.Google Scholar
  88. 530.
    Kueng und Schrefl kapseln Prozesse in Klassen und definieren den Begriff ‚Widerspruchsfreiheit‘ auf dieser Basis wie folgt: „Eine Spezialisierung eines Verhaltensdiagramms ist dann widerspruchsfrei, wenn aus jeder gültigen Folge von Prozeßzuständen der Subklasse eine gültige Folge von Prozeßzuständen der Superklasse entsteht. “ Kueng/Schrefl (1995), S. 90.Google Scholar
  89. 531.
    Diese Art der Variantenabbildung ist vergleichbar mit der Abbildung von Varianten in der industriellen Produktion mit Hilfe von ‚+/- ‘- Stücklisten. Vgl. Kurbel (1993), S. 89ff.Google Scholar
  90. 532.
    Zu einer objektorientierten Modellierung der Auftragsverwaltung vgl. Lorenz et al. (1996), S. 14–34. Diese Darstellungstechnik läßt sich auf die Abbildung von Prozeßmodellen übertragen. Vgl. dazu beispielsweise Abb. 7.12.Google Scholar
  91. 533.
    Zur Abbildung alternativer und optionaler Beziehungen in Klassenmodellen vgl. Kapitel 6.2.1.1.Google Scholar
  92. 534.
    Zur Spezifikation von Parametern vgl. Abb. 6.21.Google Scholar
  93. 535.
    In der Fallstudie finden sich Beispiele, in denen die zusätzliche Angabe des Erweiterungsmerkmals erforderlich ist. Vgl. Abb. 7.11 und Abb. 7.15.Google Scholar
  94. 536.
    Die Anforderungen an ein Modellierungswerkzeug, das die in Kapitel 6.3 vorgestellten Modellierungstechniken unterstützt, werden in Kapitel 8 skizziert.Google Scholar
  95. 537.
    Schütte verwendet für die Strukturierung der Referenzmodellvarianten und der beschreibenden Merkmale Prozeßobjekte bzw. Prozeßobjektauswahlmatritzen. Vgl. Schütte (Referenzmodellierung) (1997), S. 132 undS. 172–181.Google Scholar
  96. 538.
    Bezugsobjekte sind somit keine Objekte in Sinne der Informatik bzw. Betriebswirtschaftslehre.Google Scholar
  97. 539.
    Die Konflikte sind vergleichbar mit dem Problem des wiederholten Erbens im Rahmen der objektorientierten Programmierung. Während bei der OOP aber nur jeweils einzelne Klassen betrachtet werden, sind bei dem vorgestellten Ansatz vollständige Klassen- bzw. Prozeßmodelle zu untersuchen. Dies erschwert die Integration erheblich. Zum Problem des wiederholten Erbens in der objektorientierten Programmierung vgl. Meyer (1997), S. 543–563.Google Scholar
  98. 540.
    Namenskonflikte sollten prinzipiell bereits bei der Erstellung des Referenzmodells entdeckt und beseitigt werden. Das Problem von Namenskonflikten tritt in vergleichbarer Form auch bei der Mehrfachvererbung im Rahmen der OOP auf. Vgl. Meyer (1997), S. 535ff.Google Scholar
  99. 541.
    Abb. 7.18 der Fallstudie veranschaulicht dieses Szenario.Google Scholar
  100. 542.
    Ähnliche Probleme ergeben sich bei der Konstruktion von Modellen auf Basis von Patterns. Vgl. Hammel/ Schlitt/Wolf(1998),S. 29.Google Scholar
  101. 543.
    Zu einem Vorgehensmodell zur fiinktionsorientierten Referenzmodellierung vgl. Schütte (Referenzmodellierung) (1997), S. 140–144.Google Scholar
  102. 544.
    Zu Vorgehensmodellen zur Software-Wiederverwendung vgl. Appelfeller (1995), S. 109–119.Google Scholar
  103. 545.
    Vgl. Volkmer (1997).Google Scholar
  104. 546.
    Vgl. Gamma et al. (1996), S. 33ff.Google Scholar
  105. 547.
    Vgl. Arango (1994); Sametinger (1997), S. 163ff.; Krabbel/Wetzel (1998).Google Scholar
  106. 548.
    Eine Basis für Modellierungskonventionen sind beispielsweise die GoM. Die GoM definieren sichtenunab-hängige und sichtenspezifische Gestaltungsempfehlungen, die der Qualität von Referenzmodellen dienen. Zu methoden- und sichtenspezifischen Gestaltungsempfehlungen vgl. Becker/Schütte (1996), S. 70–92.Google Scholar
  107. 549.
    Zu Indikatoren für einen geeigneten Abstraktionsgrad von Prozeßmodellen vgl. Rosemann (Komplexität) (1996), S. 138ff. Der adäquate Konkretisierungsgrad von Referenzmodellen wird durch die Zielsetzung der Referenzmodellierung determiniert.Google Scholar
  108. 550.
    Zu potentiellen Quellen für die Referenzmodellierung vgl. Arango (1991), S. 18f.Google Scholar
  109. 551.
    Vgl. Simos(1997), S. 129f.Google Scholar
  110. 552.
    Zum Fehler ‚dritter Art‘ vgl. Schütte (Referenzmodellierung) (1997), S. 141 und die dort zitierte Literatur.Google Scholar
  111. 553.
    Die Zerlegung der Problemdomäne in Teilbereiche ist nicht mit der Zerlegung eines Referenzmodells in Basis- und Erweiterungsmodelle zu verwechseln. Vgl. Abb. 6.27.Google Scholar
  112. 554.
    D. h., Objekte im Sinne des betriebswirtschaftlichen Objektbegriffes. Vgl. Kapitel 3.1.1.Google Scholar
  113. 555.
    Zu einer Beschreibung der Strukturen und Prozesse von Lagerware und Aktionsware vgl. Becker/Schütte (1996), S. 147–418 und S. 432–444.Google Scholar
  114. 556.
    Die Identifikation von Klassen wird in der Literatur zur objektorientierten Analyse als das Problem des ‚How to find the objects‘ thematisiert. Vgl. bspw. Meyer (1997), S. 719.Google Scholar
  115. 557.
    Zu verschiedenen Heuristiken zur Identifizierung von Klassen vgl. Meyer (1997), S. 731–340. Zur Bedeutung der Identifizierung von Klassen vgl. Appelfeller (1995), S. 151.Google Scholar
  116. 558.
    Vgl. Shlaer/Melore (1988), S. 15–19; Coad/Yourdon (1991), S. 58ff.Google Scholar
  117. 559.
    Vgl. Abbott (1983), S. 887; Düwel/Hesse (1998). Verschiedene OOA-Methoden setzen auf diesem Ansatz auf. Vgl. bspw. Rumbaugh et al. (1991), S. 153ff.Google Scholar
  118. 560.
    Vgl. Schäfer (1994), S. 28ff.Google Scholar
  119. 561.
    Vgl. Volkmer (1997).Google Scholar
  120. 562.
    Vgl. Jacobson et al. (1992), S. 129f. Zur Eignung von Anwendungsfallbeschreibungen für die Identifizierung von Klassen vgl. Meyer (1997), S. 738ff.Google Scholar
  121. 563.
    Vgl. Meyer (1997), S. 740.Google Scholar
  122. 564.
    Vgl. Sauer (1995), S. 56–65.Google Scholar
  123. 565.
    Vgl. Meyer (1997), S. 725ff. Meyer gibt eine Reihe von Heuristiken an, die Hinweise auf die modellierungstechnische Relevanz einer Klasse liefern.Google Scholar
  124. 566.
    Vgl. Hruschka(1996).Google Scholar
  125. 567.
    Vgl. Schwegmann/Schlagheck (1997), S. 13. Die Methoden zur objektorientierten Analyse bieten keine Hilfestellung bzw. nur grobe Heuristiken, wie das Zuordnungsproblem von Methoden zu Klassen gelöst werden kann. Vgl. Coad/Yourdon (1991), S. 143ff.; Rumbaugh et al. (1991), S. 183ff.; Booch (1991), S. 125f.; Jacobson et al. (1992), S. 78.Google Scholar
  126. 568.
    Im Rahmen der Rechnungsprüfung werden Differenzen zwischen Lieferantenrechnungen und Wareneingangsbelegen ermittelt, korrigiert und die Rechnungen dann zur Zahlung freigegeben. Zum Prozeß der Rechnungsprüfung vgl. Becker/Schütte (1996), S. 239ff.Google Scholar
  127. 569.
    Vgl. dazu die Ausführungen in Kapitel 3.2.2.3.Google Scholar
  128. 570.
    Schütte empfiehlt die Modellierung von drei bis vier Hierarchieebenen bei der Referenzmodellierung. Vgl. Schütte (Referenzmodellierung) (1997), S. 185. Eine tiefere Schachtelung der Modelle vermindert die Klarheit, da der Gesamtzusammenhang der Modelle nicht mehr zu erkennen ist.Google Scholar
  129. 571.
    Die Modelidekomposition ist nicht mit der Modellspezialisierung zu verwechseln. Zur Unterscheidung von Modelldekomposition und Modellspezialisierung vgl. Abb. 6.27.Google Scholar
  130. 572.
    Vgl. Scheer (Geschäftsprozeß) (1998), S. 32f.Google Scholar
  131. 573.
    Zur Ableitung eines Klassendiagramms aus EPK vgl. Volkmer (1997).Google Scholar
  132. 574.
    Zur Klassifizierung und dem Retrieval von Softwarekomponenten vgl. Convent/Wernecker (1994), S. 61ff. Zur Klassifizierung von Patterns vgl. Gamma et al. (1996), S. 7ff; Japan GUIDE/SHARE (OOA) (1997), S. 18.Google Scholar
  133. 575.
    Die Qualität des Referenzmodells wird durch die allgemeinen Grundsätze ordnungsmäßiger Modellierung (GoM) und durch die erarbeiteten spezifischen Anforderungen an Referenzmodelle determiniert.Google Scholar
  134. 576.
    Vgl. Schütte (Referenzmodellierung) (1997), S. 232ff.Google Scholar
  135. 577.
    Im folgenden wird der Begriff ‚unternehmensspezifisches Modell‘ verwendet. Im Spezialfall der Entwicklung von Standardsoftware ist dieses Modell nicht notwendigerweise unternehmensspezifisch.Google Scholar
  136. 578.
    Darüber hinaus kann ein Referenzmodell auch zur vergleichenden Beurteilung existierender Modelle herangezogen werden. Dieser Fall wird hier nicht betrachtet.Google Scholar
  137. 579.
    Zu Vorgehensweisen zur Ableitung unternehmensspezifischer Modelle aus Referenzmodellen vgl. Schütte (Referenzmodellierung) (1997), S. 258ff; Japan GUIDE/SHARE (OOA) (1997), S. 17ff; Raue (1996), S. 30. HARS beschreibt ausführlich eine Vorgehensweise zur Anpassung von Referenzdatenmodellen. Vgl. Hars(1994),S. 129–231.Google Scholar
  138. 580.
    Zur Verwendung von Referenzmodellen vgl. Schütte (Referenzmodellierung) (1997), S. 251ff.Google Scholar
  139. 581.
    Im Kontext der Softwarewiederverwendung wird dieses Problem als das Reuse-Redo-Dilemma bezeichnet. Vgl. Meyer (1997), S. 82f.Google Scholar
  140. 582.
    Die Generierung und Komposition von Partialmodellen eines Referenzmodells entspricht der Generierung und Komposition von Softwarebausteinen. Vgl. Kapitel 5.1.2.3.Google Scholar
  141. 583.
    Zu Anforderungen an Tools zur Verwaltung von wiederverwendbaren Softwarekomponenten vgl. Heß/ Scheer (Softwarebausteine) (1992), S. 192f.; Lindner (1996), S. 14f.Google Scholar
  142. 584.
    Vgl. Meier/Röpert (1994), S. 49f.; Convent/Wernecker (1994), S. 62ff.Google Scholar
  143. 585.
    Die Generierung von Modellen aus Referenzmodellen entspricht dem Übergang vom Problembereichsmodell zum konkretem Analysemodell, so wie er beispielsweise von Appelfeller beschrieben wird. Vgl. Appelfeller (1995), S. 116.Google Scholar
  144. 586.
    Vgl. Simos(1995), S. 2f.Google Scholar
  145. 587.
    Dies entspricht bei Appelfeller dem Schritt 9 des Übergangs von oo-Problembereichsmodellen zu konkreten ooA-Modellen. Vgl. Appelfeller (1995), S. 136–148.Google Scholar
  146. 588.
    Zur Organisationsgestaltung mit Informationssystemmodellen vgl. bspw. Heib (1998). Zur Entwicklung von Anwendungssystemen auf Basis konzeptueller Informationssystemmodelle vgl. bspw. Emrany/Bock (1998).Google Scholar
  147. 589.
    Eine iterative Verfeinerung von objektorientierten Analysemodellen wird von verschiedenen Autoren als sinnvoll erachtet. Vgl. bspw. Booch (1994), S. 231 f.; Coad/Yourdon (1991), S. 60; Rumbaugh et al. (1991), S. 262.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