Advertisement

Grundlagen der Referenzmodellierung

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

Zusammenfassung

Im umgangssprachlichen Sinne versteht man unter einer Referenz224 einen Befähigungsnachweis oder eine Empfehlung.225 Der Begriff ,Referenzmodeir wird für unterschiedliche Sachverhalte verwendet (beispielsweise für das ISO/OSI-Schichtenmodell226 oder das Referenzmodell der Workflow Management Coalition227).228 Im Kontext dieser Arbeit werden Referenz-Informationssystemmodelle (verkürzt Referenzmodelle) betrachtet, die der Dokumentation betriebswirtschaftlichen Know-hows dienen. In der Literatur existieren verschiedene Definitionen für den Begriff ,Referenzmodeir.229 Die folgenden Ausführungen stützen sich auf die Definition von Schütte, der ein Referenzmodell als „das Ergebnis einer Konstruktion eines Modellierers, der für Anwendungssystem- und Organisationsgestalter Informationen über allgemeingültig zu modellierende Elemente eines Systems zu einer Zeit als Empfehlung mit einer Sprache deklariert, so daß ein Bezugspunkt für ein Informationssystem geschaffen wird“230 definiert.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. 224.
    „Referenz. 1. Eine (geschäftliche) Empfehlung. [...]“ o. V. (Referenz) (1988), S. 1195. Vgl. auch Schütte (Referenzmodellierung) (1997), S. 51.Google Scholar
  2. 225.
    Raue (1996), S. 26.Google Scholar
  3. 226.
    Vgl. Tanenbaum (1996), S. 28–35.Google Scholar
  4. 227.
    Vgl. Lawrence (1997), S. 259f.Google Scholar
  5. 228.
    Weitere Referenzmodelle nennt Hars. Vgl. Hars (1994), S. 13ff.Google Scholar
  6. 229.
    Weitere Definitionen und Abgrenzungen des Begriffes finden sich bei Sinz (Modellierung) (1997), S. 271; Mertens/Holzner (1992), S. 8; Becker/Schütte (1996), S. 25f.; Raue (1996), S. 26f.Google Scholar
  7. 230.
    Schütte (Referenzmodellierung) (1997), S. 51.Google Scholar
  8. 231.
    Vgl. Raue (1996), S. 29.Google Scholar
  9. 232.
    Best-practice ist das Wissen über die zu einem Zeitpunkt als ‚optimal‘ angesehenen Prozesse, Verfahren, Techniken usw. einer Domäne. Common-practice ist das Wissen über Prozesse, Verfahren, Techniken usw. wie es zu einem Zeitpunkt als Maßstab oder Standard für eine Domäne angesehen wird.Google Scholar
  10. 233.
    Zu den Begriffen ‚Application Framework‘ und ‚Patterns‘ vgl. Kapitel 5.Google Scholar
  11. 234.
    Vgl. Schütte (Referenzmodellierung) (1997), S. 4.Google Scholar
  12. 235.
    Vgl. Hammel/Schlitt/Wolf (1998), S. 26.Google Scholar
  13. 236.
    Zum Handelsreferenzmodell vgl. Becker/Schütte (1996).Google Scholar
  14. 237.
    Zum Nutzen von Referenzmodellen vgl. Schütte (Referenzmodellierung) (1997), S. 52ff.; Nonnenmacher (1994), S. 142f.Google Scholar
  15. 238.
    Dies wird auch als Requirements Engineering bezeichnet. „Software requirements engineering is the discipline for developing a complete, consistent unambigous specification — which can serve as a basis for common agreement among all parties concerned ~ describing what the software product will do (but not how it will do it; this is to be done in the design specification). “ Boehm (1979), S. 47 zitiert bei Schienmann (1995), S. 153.Google Scholar
  16. 239.
    Das Problem der Identifizierung und Modellierung relevanter Systemelemente wird in der Literatur zur objektorientierten Systemanalyse unter dem Stichwort „How to find the objects? “ thematisiert. Es existieren verschiedene Vorgehensmodelle, welche die Identifizierung relevanter Klassen, Methoden und Attribute unterstützen. Eine befriedigende Lösung existiert jedoch nicht, so daß Referenz-Anwendungssystemmodelle hier einen wertvollen Beitrag leisten können. Die Identifizierung geeigneter Klassen für objektorientierte Informationssystemmodelle wird in Kapitel 6.4.1.4 diskutiert.Google Scholar
  17. 240.
    Vgl. Schütte (Referenzmodellierung) (1997), S. 53.Google Scholar
  18. 241.
    Vgl. Schütte (Referenzmodellierung) (1997), S. 55; Reiter (1997), S. 36.Google Scholar
  19. 242.
    Vgl. Scheruhn (1997), S. 92f.; Scheruhn (Referenzmodell) (1996); Scheruhn (Geschäftsprozeß) (1996).Google Scholar
  20. 243.
    Zum Nutzen von Referenzmodellen vgl. Becker/Schütte (1996), S. 27f.; Schütte (Referenzmodellierung) (1997), S. 55ff.; Mertens et al. (1997), S. 66; Raue (1996), S. 27; Hars (1994), S. 32ff.; Maier (1996), S. 76f. Schütte unterscheidet hinsichtlich der Anwendung von Referenzmodellen zwischen Referenzmodellen als Konstruktionshilfe und Referenzmodellen zur Analyse einer bestehenden Situation. Vgl. Schütte (Referenzmodellierung) (1997), S. 251. Referenzmodelle werden hier primär zur Unterstützung der Konstruktion spezifischer Modelle verwendet. Nutzen und Risiken der Referenzmodellierung decken sich weitgehend mit denen der (Software-) Wiederverwendung. Vgl. dazu Kapitel 5.1.Google Scholar
  21. 244.
    Anforderungen, welche die Qualität von Referenzmodellen determinieren, werden in Kapitel 4.3 vorgestellt.Google Scholar
  22. 245.
    Vgl. Hellenack (1997), S. 23.Google Scholar
  23. 246.
    Zum Nutzen von Referenzmodellen bei der Reorganisation von Prozessen vgl. Aichele/Elsner/ Thewes (1994).Google Scholar
  24. 247.
    Vgl. Raue (1996), S. 29.Google Scholar
  25. 248.
    Vgl. Hars (1994), S. 33f.; Frank (1994), S. 17. Dieser Effekt entspricht dem Phänomen der Vereinheitlichung von organisatorischen Strukturen und Abläufen durch Standardsoftwaresysteme. Vgl. Barbitsch (1996), S. 17.Google Scholar
  26. 249.
    Zum Begriff ‚Komparativer Konkurrenzvorteil‘ vgl. Backhaus (1997), S. 21 f.Google Scholar
  27. 250.
    Vgl.Österle(1990), S. 21f.Google Scholar
  28. 251.
    Vgl. Schütte (Referenzmodellierung) (1997), S. 205 und die dort zitierte Literatur.Google Scholar
  29. 252.
    Scheer verwendet den Begriff für Unternehmensdatenmodelle, die als Ausgangsmodell zur Erstellung unternehmensindividueller Datenmodelle verwendet werden. Vgl. Scheer (1990), S. 519.Google Scholar
  30. 253.
    Vgl. Hars (1994); Kruse (1996); Nonnenmacher (1994); Remme (1996); Schütte (Referenzmodellierung) (1997).Google Scholar
  31. 254.
    Vgl. Becker/Schütte (1996).Google Scholar
  32. 255.
    Vgl. Scheer (1997).Google Scholar
  33. 256.
    Vgl. Hay (1996). Hay verwendet den Begriff ‚Pattern‘ statt ‚ReferenzmodeU‘. Zur Differenzierung dieser Begriffe vgl. Kapitel 5.3.Google Scholar
  34. 257.
    Zu einem Überblick über existierende branchenspezifische Referenzmodelle vgl. Marent (branchenspezifisch) (1995).Google Scholar
  35. 258.
    Vgl. Scheer/Hoffmann/Wein (1994); Scheruhn (Referenzmodell) (1996). Aktuelle Informationen finden sich im Internet unter http://www.ids-scheer.de/.
  36. 259.
    Vgl. IAA (1992), S. 1 ff. Aktuelle Informationen finden sich im Internet unter http://www.insurance.ibm.com/insur/iaa/.
  37. 260.
    Vgl. Keller/Teufel (1998); Lietschulte (1998); Zencke (1996).Google Scholar
  38. 261.
    Vgl. Brockmann (1998); Scheruhn (Referenzmodell) (1996), S. 118.Google Scholar
  39. 262.
    Zu den Aktivitäten der ORI vgl. http://www.cwk.de.
  40. 263.
    Vgl. Japan GUIDE/SHARE (OOA) (1997), S. 16f.; Appelfeller (1995), S. 34f.; Schütte (Referenzmodellierung) (1997), S. 63.Google Scholar
  41. 264.
    Zur Abgrenzung der Begriffe ‚Wiederverwendung‘ und ‚Referenzmodellierung‘ vgl. Kapitel 5.1.Google Scholar
  42. 265.
    Zur Forderung nach Wiederverwendung von Entwurfs- oder Analysemodellen vgl. Nietsch (1996), S. 37; Appelfeller (1995), S. 34f.; Tracz (1990), S. 43; Prieto-Diaz (1993), S. 65; McClure (1997), S. 2. Technische Aspekte bei der Wiederverwendung von Designmodellen werden beispielsweise bei Castano/De Anto-nellis (1993) und Lübars (1990) diskutiert.Google Scholar
  43. 266.
    Vgl. Raue (1996).Google Scholar
  44. 267.
    Vgl. Appelfeller (1995), S. 121–154. Zum Begriff ‚Domain Analysis‘ vgl. Kapitel 5.2.Google Scholar
  45. 268.
    Vgl. Japan GUIDE/SHARE (OOA) (1997).Google Scholar
  46. 269.
    Vgl. Simoneit (1998).Google Scholar
  47. 270.
    Vgl. Schildheuer (1998).Google Scholar
  48. 271.
    Vgl. Coad/North/Mayfield (1997).Google Scholar
  49. 272.
    Zu Anforderungen an Referenzmodelle vgl. Japan GUIDE/SHARE (OOA) (1997), S. 5; Raue (1996), S. 31f; Nonnenmacher (1994), S. 141f; Hars (1994), S. 15f; Aichele/Elsner/Thewes (1994), S. 254. Die Problematik, Modelle hinsichtlich der Anforderungserfüllung bewerten zu müssen, wird im folgenden nicht explizit thematisiert. Vgl. dazu bspw. Moody/Shanks (1994), S. 99f.Google Scholar
  50. 273.
    Ein Modell zeichnet sich durch eine hohe inhaltliche Qualität aus, wenn unter Berücksichtigung der Zielsetzung des Modellverwenders alle relevanten Sachverhalte semantisch richtig abgebildet wurden. Die inhaltliche Qualität wird somit durch den Grundsatz der Relevanz und der semantischen Richtigkeit der GoM determiniert. Die modellierungstechnische Qualität eines Modells wird vor allem durch die Konsistenz des Modells (keine oder wenige Redundanzen, keine Inkonsistenzen), die gemäß der gewählten Beschreibungssprache syntaktisch richtige Modellierung und die geeignete graphische Aufbereitung der Modelle determiniert. Die modellierungstechnische Qualität eines Modells wird durch die Grundsätze der Klarheit, der syntaktischen Richtigkeit und des systematischen Aufbaus der GoM beeinflußt.Google Scholar
  51. 274.
    Vgl. Raue (1996), S. 51, Appelfeller (1995), S. 42; Meyer (1997), S. 75.Google Scholar
  52. 275.
    Vgl. Holl/Mitterbauer (1998), S. 68.Google Scholar
  53. 276.
    Wenn möglich, sollte ein Modellierer, der an der Erstellung des Referenzmodells beteiligt war, auch bei der Modellverwendung mitwirken, um ggf. nicht dokumentierte Sachverhalte darstellen zu können. Vgl. Japan GUIDE/SHARE (OOA) (1997), Abschnitt 4.2.Google Scholar
  54. 277.
    Hinsichtlich der Wirtschaftlichkeit der Referenzmodellierung ist die Perspektive des Referenzmodell-erstellers und des Referenzmodellverwenders zu unterscheiden. Vgl. dazu Kapitel 4.1.3.Google Scholar
  55. 278.
    Allgemein bezeichnet ein Modul eine Bau- oder Schaltungseinheit. Vgl. o. V. (Modell) (1989), S. 465. Ein Softwaremodul besteht aus einer Schnittstelle und einem Rumpf. Die Schnittstelle gliedert sich in eine Export- und eine Importschnittstelle. Die Exportschnittstelle spezifiziert, welche Dienste eines Moduls von anderen Modulen verwendet werden können. Der Rumpf enthält die Implementierungen der in der Exportschnittstelle spezifizierten Dienstleistungen. Für die Implementierung werden ggf. Dienste anderer Module benötigt. Diese werden in der Importschnittstelle beschrieben. Vgl. Balzert (1996), S. 848; Hruschka (1986), S. 68ff.Google Scholar
  56. 279.
    Zum strukturierten und modularen Entwurf von Softwaresystemen vgl. Balzert (1996), S. 801–862. Zu einer Übersicht über verschiedene Modularten vgl. insbesondere Balzert (1996), S. 844.Google Scholar
  57. 280.
    Diese Erkenntnis kann aus der Literatur zur Softwarewiederverwendung übertragen werden. Vgl. Biggerstaff/Perlis (1989), S. XVf.Google Scholar
  58. 281.
    Vgl. Taylor (1995), S. 25; Coad/Yourdon (1991), S. 107 und die dort zitierte Literatur.Google Scholar
  59. 282.
    Das Korrelat zur Modularisierung im Software Engineering ist die Clusterung und Hierarchisierung von (konzeptuellen) Informationssystemmodellen. Vgl. dazu bspw. Mistelbauer (1993).Google Scholar
  60. 283.
    Zu den Anforderungen an Module vgl. Meyer (1997), S. 83ff.; Appelfeller (1995), S. 38ff.; Hruschka (1986).Google Scholar
  61. 284.
    Ein vergleichbares Vorgehen wählen Batini, Ceri und Navathe. Vgl. Batini/Ceri/Navathe (1992), S. 171.Google Scholar
  62. 285.
    Synonym zum Terminus ‚Unabhängigkeit‘ wird der Begriff ‚Kopplung‘ verwendet. Vgl. Kappel/Schreffl (1996), S. 202ff.; Myers (1976), S. 92ff.; Hruschka (1986), S. 73.Google Scholar
  63. 286.
    Zu den möglichen Beziehungen zwischen Modulen vgl. Balzert (1996), S. 848ff.Google Scholar
  64. 287.
    Vgl. Wiegert (1995), S. 92f.Google Scholar
  65. 288.
    Zum Begriff ‚Information Hiding‘ vgl. S. 36.Google Scholar
  66. 289.
    Integration bezeichnet den Vorgang bzw. das Ergebnis der „(Wieder-)Herstellung eines Ganzen“ o. V. (Integration) (1989), S. 307. Zu den Zielen und Dimensionen der Integration vgl. auch Rosemann (Komplexität) (1996), S. 155–165.Google Scholar
  67. 290.
    Vgl. Meyer (1997), S.42f.Google Scholar
  68. 291.
    Vgl. Meyer (1997), S.48ff.Google Scholar
  69. 292.
    Meyer bezeichnet dies als modulare Verständlichkeit. Vgl. Meyer (1990), S. 15.Google Scholar
  70. 293.
    Zum Begriff ‚Kohäsion‘ vgl. Kappel/Schreffl (1996), S. 226ff.Google Scholar
  71. 294.
    In der Literatur werden diese Eigenschaften häufig an Datentyp-Modulen veranschaulicht. Vgl. Balzert (1996), S. 840f. Datentyp-Module sind beispielsweise Module zur Verwaltung einer Menge von Elementen (z. B. STACK, LIST, QUEUE) und zeichnen sich durch eine Reihe kohärenter Dienste (z. B. PUSH, POP, is_ empty, isfull) und einen internen Speicher aus. Alle erforderlichen Operationen an den intern verwalteten Elementen können über die bereitgestellten Dienste ausgeführt werden.Google Scholar
  72. 295.
    Vgl. Meyer (1997), S. 57ff.Google Scholar
  73. 296.
    Vgl. Raue (1996), S. 33; Meyer (1990), S. 15f.Google Scholar
  74. 297.
    Meyer bezeichnet dies als ‚Modular understandability‘. Vgl. Meyer (1997), S. 43f.Google Scholar
  75. 298.
    Vgl. Becker/Schütte (1996), S. 25; Hars (1994), S 15.Google Scholar
  76. 299.
    Vgl. Jacobson/Griss/Jonsson (1997), S. 124ff.Google Scholar
  77. 300.
    Es existieren verschiedene Ansätze, Unternehmen nach Merkmalen zu klassifizieren. Vollständige Klassifizierungssysteme, die alle Aspekte von Unternehmen abdecken, existieren jedoch nicht. Dies ist darauf zurückzuführen, daß eine Vielzahl von potentiellen, i. d. R. nicht exakt definierten Kriterien existiert, die vielfaltige Abhängigkeiten zueinander aufweisen. Einerseits werden Kriterien synoym oder homonym verwendet. Andererseits beeinflussen sich die Merkmalsausprägungen gegenseitig und sind nicht orthogonal zueinander. Vgl. Mertens et al. (1997), S. 74ff.Google Scholar
  78. 301.
    Zu den Begriffen ‚Kannvariante‘ und ‚Mußvariante‘ vgl. bspw. Kurbel (1993), S. 86.Google Scholar
  79. 302.
    Vgl. Schlitt(1998), S.47.Google Scholar
  80. 303.
    Vgl. zu den folgenden Ausführungen auch Schütte (Referenzmodellierung) (1997), S. 160ff. Zum Begriff und zu Anforderungen an Merkmale vgl. Kapitel 6.3.2.3.Google Scholar
  81. 304.
    Zu den Modellierungsprimitiven des ER-Modells vgl. Kapitel 4.4.1.Google Scholar
  82. 305.
    Abhängigkeiten zwischen Merkmalen werden in Kapitel 6.3.2.3 thematisiert.Google Scholar
  83. 306.
    Die Bestimmung des optimalen Konkretisierungsgrads ist ein wesentliches Problem der Referenzmodellierung. Vgl. Schütte (Referenzmodellierung) (1997), S. 185f.; Raue (1996), S 29; Marent (branchenspezifisch) (1995), S. 312; Scholz-Reiter (1990), S. 31. Die Autoren verwenden den Begriff ‚Abstraktionsgrad‘, der hier durch den in Kapitel 2.2 definierten Begriff ‚Konkretisierungsgrad‘ ersetzt wird.Google Scholar
  84. 307.
    Die Modelltiefe ist allgemein ein Maß für die Detailliertheit eines Modells, die durch den Konkretisierungsgrad des Modells beeinflußt wird. Im Kontext der Referenzmodellierung wird die Modelltiefe eines Referenzmodells durch den Konkretisierungsgrad und den Variantenabdeckungsgrad determiniert. Bezogen auf Abb. 4.2 handelt es sich in Fall 1 um ein tiefes und in Fall 3 um ein flaches Modell.Google Scholar
  85. 308.
    Vgl. Schütte (Referenzmodellierung) (1997), S. 186.Google Scholar
  86. 309.
    Die Bedeutung der Anpaßbarkeit wird auch in der Literatur zur Software-Wiederverwendung betont: „The modifying process is the lifeblood of reusability“ Biggerstaff/Richter (1989), S. 7.Google Scholar
  87. 310.
    Zur Bedeutung der Anpaßbarkeit bzw. Flexibilität von Modellen vgl. Moody/Shanks (1994), S. 103f. und die dort zitierte Literatur.Google Scholar
  88. 311.
    Zur Forderung anpaßbarer Referenzmodelle vgl. Raue (1996), S. 33. Zum Begriff der Anpaßbarkeit im Rahmen der Softwareentwicklung vgl. beispielsweise Wiegert (1995), S. 30–98. Zur Forderung nach flexiblen Modellen vgl. beispielsweise Moody/Shanks (1994), S. 103f. Die Begriffe ‚Anpaßbarkeit‘, ‚Flexibilität‘ und ‚Adaptivität‘ werden synonym verwendet.Google Scholar
  89. 312.
    Der hier diskutierte Begriff der Anpaßbarkeit bezieht sich auf das Referenzmodell als Ganzes und ist nicht zu verwechseln mit dem modulbezogenen Begriff der Anpaßbarkeit. Die Anpaßbarkeit von Modulen dient der Anpaßbarkeit des Gesamtmodells.Google Scholar
  90. 313.
    Vgl. S. 8.Google Scholar
  91. 314.
    Auf die Darstellung einer Informationssystemmodell-Architektur für Referenzmodelle und auf die Beschreibung eines Vorgehensmodells für die Erstellung und Verwendung von Referenzmodellen wird hier verzichtet. Zu Vorgehensmodellen für die Referenzmodellerstellung und -Verwendung vgl. Schütte (Referenzmodellierung) (1997), S. 140–144. HARS beschreibt eine Vorgehensweise für die Anpassung von Referenzdatenmodellen. Vgl. Hars (1994), S. 129–231.Google Scholar
  92. 315.
    Die Entity-Relationship-Modelle gehen auf Chen zurück. Vgl. Chen (1976). Weitere bekannte Notationen zur Abbildung von Datenmodellen, die auf den ‚klassischen‘ ER-Modellen aufsetzen, sind SERM (vgl. Ferstl/Sinz (1998), S. 101–113) und SAP-SERM (vgl. Becker/Schütte (1996), S. 39–46).Google Scholar
  93. 316.
    Vgl. Schüngel (1995), S. 141.Google Scholar
  94. 317.
    Zur Verwendung von Entity-Relationship-Modellen zur Beschreibung der Struktursicht von Referenzmodellen vgl. Schütte (Referenzmodellierung) (1997); Becker/Schütte (1996); Hay (1996) und Hars (1994).Google Scholar
  95. 318.
    Zum hier verwendeten Strukturbegriff vgl. Fußnote 10. Auf die Darstellung einer Funktionsmodellierung, die auch Bestandteil der Referenzstrukturmodellierung ist, wird hier verzichtet.Google Scholar
  96. 319.
    Zu einer ausführlichen Darstellung der ER-Modellierung vgl. beispielsweise Vossen (1999), S. 65–114; Elmasri/Navathe (1994), S. 37–68 und 611–622.Google Scholar
  97. 320.
    Vgl. zu den folgenden Ausführungen Rosemann/Schütte (1997), S. 31 f.; Schütte (Referenzmodellierung) (1997), S. 208–221.Google Scholar
  98. 321.
    Denkbar ist auch die Einführung eines Operators für die Konjunktion (UND). Da es jedoch bei der Abbildung von Varianten um die Darstellung von Alternativen geht, ist dieser Operator irrelevant.Google Scholar
  99. 322.
    Ein besonderes Problem bei der Abbildung von Varianten in klassischen ER-Modellen besteht in der Strukturierung des Modells, da keine eindeutigen Anordnungskriterien existieren. Diese Problematik wird hier nicht thematisiert. Zur Strukturierung von ER-Modellen vgl. Tamassia/Batini/Talamo (1983); Becker/ Schütte (1996), S. 77; Ferstl/Sinz (1998), S. 101–113; Hay (1996), S. 16ff.Google Scholar
  100. 323.
    Zum Überblick und Vergleich existierender Prozeßmodellierungsmethoden vgl. beispielsweise Kruse (1996), S. 90–106; Rosemann (Komplexität) (1996), S. 48–84.Google Scholar
  101. 324.
    Zu einer ausführlichen Darstellung der EPK-Notation vgl. Keller/Nüttgens/Scheer (1992); Scheer (Methode) (1998), S. 125ff.Google Scholar
  102. 325.
    Vgl. Nüttgens/Zimmermann (1998), S. 2.Google Scholar
  103. 326.
    Die Modellierung von Datenfluß- oder Objektflußdiagrammen wird hier nicht thematisiert.Google Scholar
  104. 327.
    Vgl. Scheer (Geschäftsprozeß) (1998); Scheer (Methode) (1998).Google Scholar
  105. 328.
    Vgl. Keller/Nüttgens/Scheer (1992), S. 7ff. v. Uthmann ist der Auffassung, daß EPK mit den sog. Ka-nal/Instanzen-Netzen zu vergleichen sind. Vgl. v. Uthmann (1997), S. 10. Zu den Grundlagen der Petri-Netz-Theorie vgl. beispielsweise Reisig (1990).Google Scholar
  106. 329.
    Die Begriffe ‚Funktion‘ und ‚Prozeß‘ lassen sich nicht eindeutig trennen, da Prozesse eine Abfolge von Funktionen enthalten und Funktionen wiederum durch Prozesse spezifiziert werden können. Zu dieser Problematik vgl. v. Uthmann (1997), Fußnote 8 und die dort zitierte Literatur; Schütte (Referenzmodellierung) (1997), S. 74. Der Begriff ‚Funktion‘ wird verwendet, wenn es das Ziel ist, Aktivitäten als Black-Box zu kapseln. Der Begriff ‚Prozeß‘ wird gebraucht, wenn Folgen von elementaren Funktionen zu spezifizieren sind.Google Scholar
  107. 330.
    Ereignisse können in Bereitstellungsereignisse und Auslöseereignisse differenziert werden. Vgl. Schütte (Referenzmodellierung) (1997), S. 75ff. Auf diese Differenzierung wird im folgenden verzichtet.Google Scholar
  108. 331.
    Ein weiteres Defizit der EPK ist, daß sich Objektwechsel nicht adäquat darstellen lassen und daß EPK grundsätzlich nur die statische Prozeßstruktur abbilden. Dadurch können Ressourceninterdependenzen zwischen verschiedenen Prozessen nicht dokumentiert und analysiert werden. Für diesen Zweck existieren geeignetere Modellierungsmethoden, wie beispielsweise Petri-Netze. Zu dieser Problematik vgl. v. Uthmann (1997).Google Scholar
  109. 332.
    Vgl. Rosemann/Schütte (1997), S. 27ff.; Schütte (Referenzmodellierung) (1997), S. 193–207.Google Scholar
  110. 333.
    Zur Abbildung von Varianten in Prozeßmodellen vgl. auch Schlitt (1998), S. 47ff.Google Scholar
  111. 334.
    Neben dem XOR- und dem OR-Operator wird der Entscheidungstabellenoperator (vgl. Rosemann (Komplexität) (1996), S. 140ff.) und der Sequence-Operator (vgl. Priemer (1995), S. 270) zur Modellierung von Verzweigungen verwendet. Zur Verwendung dieser Operatoren in Referenzprozeßmodellen vgl. Schütte (Referenzmodellierung) (1997), S. 196ff.Google Scholar
  112. 335.
    Zu den Ableitungsregeln von Runtime-Operatoren aus Buildtime-Operatoren vgl. Schütte (Referenzmodellierung) (1997), S. 199f.Google Scholar
  113. 336.
    Vgl. Schütte (Referenzmodellierung) (1997), S. 195f.Google Scholar
  114. 337.
    Vgl. Schütte (Referenzmodellierung) (1997), S. 221.Google Scholar
  115. 338.
    Zu Namenskonventionen für Modellelemente vgl. Rosemann (Komplexität) (1996), S. 201–206; Schütte (Referenzmodellierung) (1997), S. 222f.Google Scholar
  116. 339.
    Zu einer ausführlichen Darstellung, in welchem Verhältnis die Operatoren der Struktur- und der Verhaltenssicht zueinander stehen, vgl. Schütte (Referenzmodellierung) (1997), S. 224ff. Zum Verhältnis von Generalisierungs-/Spezialisierungsbeziehungen im Strukturmodell zu Verzweigungen im Verhaltensmodell vgl. Kapitel 6.2.4.Google Scholar
  117. 340.
    Zur Modellierung der Prüffunktion vgl. Alternative 1 in Abb. 4.6.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