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.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Literatur
„Referenz. 1. Eine (geschäftliche) Empfehlung. [...]“ o. V. (Referenz) (1988), S. 1195. Vgl. auch Schütte (Referenzmodellierung) (1997), S. 51.
Raue (1996), S. 26.
Vgl. Tanenbaum (1996), S. 28–35.
Vgl. Lawrence (1997), S. 259f.
Weitere Referenzmodelle nennt Hars. Vgl. Hars (1994), S. 13ff.
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.
Schütte (Referenzmodellierung) (1997), S. 51.
Vgl. Raue (1996), S. 29.
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.
Zu den Begriffen ‚Application Framework‘ und ‚Patterns‘ vgl. Kapitel 5.
Vgl. Schütte (Referenzmodellierung) (1997), S. 4.
Vgl. Hammel/Schlitt/Wolf (1998), S. 26.
Zum Handelsreferenzmodell vgl. Becker/Schütte (1996).
Zum Nutzen von Referenzmodellen vgl. Schütte (Referenzmodellierung) (1997), S. 52ff.; Nonnenmacher (1994), S. 142f.
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.
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.
Vgl. Schütte (Referenzmodellierung) (1997), S. 53.
Vgl. Schütte (Referenzmodellierung) (1997), S. 55; Reiter (1997), S. 36.
Vgl. Scheruhn (1997), S. 92f.; Scheruhn (Referenzmodell) (1996); Scheruhn (Geschäftsprozeß) (1996).
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.
Anforderungen, welche die Qualität von Referenzmodellen determinieren, werden in Kapitel 4.3 vorgestellt.
Vgl. Hellenack (1997), S. 23.
Zum Nutzen von Referenzmodellen bei der Reorganisation von Prozessen vgl. Aichele/Elsner/ Thewes (1994).
Vgl. Raue (1996), S. 29.
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.
Zum Begriff ‚Komparativer Konkurrenzvorteil‘ vgl. Backhaus (1997), S. 21 f.
Vgl.Österle(1990), S. 21f.
Vgl. Schütte (Referenzmodellierung) (1997), S. 205 und die dort zitierte Literatur.
Scheer verwendet den Begriff für Unternehmensdatenmodelle, die als Ausgangsmodell zur Erstellung unternehmensindividueller Datenmodelle verwendet werden. Vgl. Scheer (1990), S. 519.
Vgl. Hars (1994); Kruse (1996); Nonnenmacher (1994); Remme (1996); Schütte (Referenzmodellierung) (1997).
Vgl. Becker/Schütte (1996).
Vgl. Scheer (1997).
Vgl. Hay (1996). Hay verwendet den Begriff ‚Pattern‘ statt ‚ReferenzmodeU‘. Zur Differenzierung dieser Begriffe vgl. Kapitel 5.3.
Zu einem Überblick über existierende branchenspezifische Referenzmodelle vgl. Marent (branchenspezifisch) (1995).
Vgl. Scheer/Hoffmann/Wein (1994); Scheruhn (Referenzmodell) (1996). Aktuelle Informationen finden sich im Internet unter http://www.ids-scheer.de/.
Vgl. IAA (1992), S. 1 ff. Aktuelle Informationen finden sich im Internet unter http://www.insurance.ibm.com/insur/iaa/.
Vgl. Keller/Teufel (1998); Lietschulte (1998); Zencke (1996).
Vgl. Brockmann (1998); Scheruhn (Referenzmodell) (1996), S. 118.
Zu den Aktivitäten der ORI vgl. http://www.cwk.de.
Vgl. Japan GUIDE/SHARE (OOA) (1997), S. 16f.; Appelfeller (1995), S. 34f.; Schütte (Referenzmodellierung) (1997), S. 63.
Zur Abgrenzung der Begriffe ‚Wiederverwendung‘ und ‚Referenzmodellierung‘ vgl. Kapitel 5.1.
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.
Vgl. Raue (1996).
Vgl. Appelfeller (1995), S. 121–154. Zum Begriff ‚Domain Analysis‘ vgl. Kapitel 5.2.
Vgl. Japan GUIDE/SHARE (OOA) (1997).
Vgl. Simoneit (1998).
Vgl. Schildheuer (1998).
Vgl. Coad/North/Mayfield (1997).
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.
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.
Vgl. Raue (1996), S. 51, Appelfeller (1995), S. 42; Meyer (1997), S. 75.
Vgl. Holl/Mitterbauer (1998), S. 68.
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.
Hinsichtlich der Wirtschaftlichkeit der Referenzmodellierung ist die Perspektive des Referenzmodell-erstellers und des Referenzmodellverwenders zu unterscheiden. Vgl. dazu Kapitel 4.1.3.
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.
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.
Diese Erkenntnis kann aus der Literatur zur Softwarewiederverwendung übertragen werden. Vgl. Biggerstaff/Perlis (1989), S. XVf.
Vgl. Taylor (1995), S. 25; Coad/Yourdon (1991), S. 107 und die dort zitierte Literatur.
Das Korrelat zur Modularisierung im Software Engineering ist die Clusterung und Hierarchisierung von (konzeptuellen) Informationssystemmodellen. Vgl. dazu bspw. Mistelbauer (1993).
Zu den Anforderungen an Module vgl. Meyer (1997), S. 83ff.; Appelfeller (1995), S. 38ff.; Hruschka (1986).
Ein vergleichbares Vorgehen wählen Batini, Ceri und Navathe. Vgl. Batini/Ceri/Navathe (1992), S. 171.
Synonym zum Terminus ‚Unabhängigkeit‘ wird der Begriff ‚Kopplung‘ verwendet. Vgl. Kappel/Schreffl (1996), S. 202ff.; Myers (1976), S. 92ff.; Hruschka (1986), S. 73.
Zu den möglichen Beziehungen zwischen Modulen vgl. Balzert (1996), S. 848ff.
Vgl. Wiegert (1995), S. 92f.
Zum Begriff ‚Information Hiding‘ vgl. S. 36.
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.
Vgl. Meyer (1997), S.42f.
Vgl. Meyer (1997), S.48ff.
Meyer bezeichnet dies als modulare Verständlichkeit. Vgl. Meyer (1990), S. 15.
Zum Begriff ‚Kohäsion‘ vgl. Kappel/Schreffl (1996), S. 226ff.
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.
Vgl. Meyer (1997), S. 57ff.
Vgl. Raue (1996), S. 33; Meyer (1990), S. 15f.
Meyer bezeichnet dies als ‚Modular understandability‘. Vgl. Meyer (1997), S. 43f.
Vgl. Becker/Schütte (1996), S. 25; Hars (1994), S 15.
Vgl. Jacobson/Griss/Jonsson (1997), S. 124ff.
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.
Zu den Begriffen ‚Kannvariante‘ und ‚Mußvariante‘ vgl. bspw. Kurbel (1993), S. 86.
Vgl. Schlitt(1998), S.47.
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.
Zu den Modellierungsprimitiven des ER-Modells vgl. Kapitel 4.4.1.
Abhängigkeiten zwischen Merkmalen werden in Kapitel 6.3.2.3 thematisiert.
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.
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.
Vgl. Schütte (Referenzmodellierung) (1997), S. 186.
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.
Zur Bedeutung der Anpaßbarkeit bzw. Flexibilität von Modellen vgl. Moody/Shanks (1994), S. 103f. und die dort zitierte Literatur.
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.
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.
Vgl. S. 8.
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.
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).
Vgl. Schüngel (1995), S. 141.
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).
Zum hier verwendeten Strukturbegriff vgl. Fußnote 10. Auf die Darstellung einer Funktionsmodellierung, die auch Bestandteil der Referenzstrukturmodellierung ist, wird hier verzichtet.
Zu einer ausführlichen Darstellung der ER-Modellierung vgl. beispielsweise Vossen (1999), S. 65–114; Elmasri/Navathe (1994), S. 37–68 und 611–622.
Vgl. zu den folgenden Ausführungen Rosemann/Schütte (1997), S. 31 f.; Schütte (Referenzmodellierung) (1997), S. 208–221.
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.
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.
Zum Überblick und Vergleich existierender Prozeßmodellierungsmethoden vgl. beispielsweise Kruse (1996), S. 90–106; Rosemann (Komplexität) (1996), S. 48–84.
Zu einer ausführlichen Darstellung der EPK-Notation vgl. Keller/Nüttgens/Scheer (1992); Scheer (Methode) (1998), S. 125ff.
Vgl. Nüttgens/Zimmermann (1998), S. 2.
Die Modellierung von Datenfluß- oder Objektflußdiagrammen wird hier nicht thematisiert.
Vgl. Scheer (Geschäftsprozeß) (1998); Scheer (Methode) (1998).
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).
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.
Ereignisse können in Bereitstellungsereignisse und Auslöseereignisse differenziert werden. Vgl. Schütte (Referenzmodellierung) (1997), S. 75ff. Auf diese Differenzierung wird im folgenden verzichtet.
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).
Vgl. Rosemann/Schütte (1997), S. 27ff.; Schütte (Referenzmodellierung) (1997), S. 193–207.
Zur Abbildung von Varianten in Prozeßmodellen vgl. auch Schlitt (1998), S. 47ff.
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.
Zu den Ableitungsregeln von Runtime-Operatoren aus Buildtime-Operatoren vgl. Schütte (Referenzmodellierung) (1997), S. 199f.
Vgl. Schütte (Referenzmodellierung) (1997), S. 195f.
Vgl. Schütte (Referenzmodellierung) (1997), S. 221.
Zu Namenskonventionen für Modellelemente vgl. Rosemann (Komplexität) (1996), S. 201–206; Schütte (Referenzmodellierung) (1997), S. 222f.
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.
Zur Modellierung der Prüffunktion vgl. Alternative 1 in Abb. 4.6.
Rights and permissions
Copyright information
© 1999 Betriebswirtschaftlicher Verlag Dr. Th. Gabler GmbH, Wiesbaden, und Deutscher Universitäts-Verlag GmbH, Wiesbaden
About this chapter
Cite this chapter
Schwegmann, A. (1999). Grundlagen der Referenzmodellierung. In: Objektorientierte Referenzmodellierung. Informationsmanagement und Controlling. Deutscher Universitätsverlag, Wiesbaden. https://doi.org/10.1007/978-3-322-99774-6_4
Download citation
DOI: https://doi.org/10.1007/978-3-322-99774-6_4
Publisher Name: Deutscher Universitätsverlag, Wiesbaden
Print ISBN: 978-3-8244-7014-3
Online ISBN: 978-3-322-99774-6
eBook Packages: Springer Book Archive