Zusammenfassung
Einführend werden in diesem Kapitel die als wesentlich erachteten Grundbegriffe der Informationssystemmodellierung dargestellt und gegeneinander abgegrenzt. Weitere Definitionen und Abgrenzungen erfolgen später an der Stelle ihrer ersten Verwendung. Von besonderer Bedeutung ist Kapitel 2.6, welches die Darstellung allgemeiner Anforderungen an Informationssystemmodelle in Form der Grundsätze ordnungsmäßiger Modellierung (GoM) zum Gegenstand hat.
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
Hesse et al. (Teil 1) (1994), S. 42.
Zu den Ausführungen zum Systembegriff vgl. Schütte (Referenzmodellierung) (1997), S. 24ff. und die dort zitierte Literatur.
Diese Definition des Begriffes ‚Struktur‘ kennzeichnet die Verwendung des Terminus im engeren Sinne. Im weiteren Sinne umfaßt der Begriff auch die Struktur von Prozessen zur Beschreibung der Verhaltenssicht. Die Prozeßstruktur beschreibt die zeitlich-sachlogische Anordnung von Aktivitäten ohne die Berücksichtigung dynamischer Aspekte. Zur Unterscheidung von Struktur i. e. S. und Struktur i. w. S. vgl. Schütte (Referenzmodellierung) (1997), S. 25f. und die dort zitierte Literatur.
Hesse et al. definieren beispielsweise eine Reihe verschiedener Ausprägungen von Systemen, die im Kontext des Softwareengineering relevant sind. Vgl. Hesse et al. (Teil 1) (1994), S. 43 f.
Zur Verwendung des Begriffes ‚Informationssystem‘ vgl. Mertens/Holzner (1992), S. 21 f.
Krcmar (1990), S. 396. Vergleichbare Definitionen finden sich beispielsweise bei Seibt (Anwendungsarchitektur) (1997), S. 39; Balzert (1996), S. 24.
Zur Verwendung des Objektbegriffes von Ferstl und Sinz vgl. Ferstl/Sinz (1998), S. 4f. Eine allgemeine Definition und Abgrenzung des Begriffes ‚Objekt‘ findet sich in Kapitel 3.1.
Zu den folgenden Ausführungen vgl. Ferstl/Sinz (1993), S. 3f.
Zu den Begriffen ‚Erklärungsmodell‘ und ‚Gestaltungsmodell‘ vgl. Adam (1996), S. 87f.
Schütte (Referenzmodellierung) (1997), S. 42.
Modellierungstechnisches Wissen umfaßt im Kontext der Informationssystemmodellierung das Know-how über Modellierungsmethoden (z. B. SA, SD, OOA, OOD) und über Modellierungstools. Fachliches Wissen impliziert Kenntnisse über die Terminologie, theoretische Konzepte und Lösungsverfahren sowie konkrete Strukturen und Prozesse einer Problemdomäne.
Vgl. Schütte (Referenzmodellierung) (1997), S. 35.
Eine ausführliche Diskussion des philosophischen Streits um den ‚richtigen‘ Modellbegriff würde den Rahmen dieser Arbeit sprengen. Zur Diskussion des abbildungsorientierten bzw. des konstruktionsorien-tierten Modellbegriffes und zum Vergleich verschiedener Modellbegriffe aus der Betriebswirtschaftslehre, der Informatik und der Wirtschaftsinformatik vgl. Schütte (Referenzmodellierung) (1997), S. 32–45 und Hammel/Schlitt/Wolf (1998), S. 22ff.
Schütte (Referenzmodellierung) (1997), S. 45. Der Begriff ‚Informationsmodell‘ wird synonym zum Begriff ‚Informationssystemmodell‘ verwendet.
Der Begriff des Paradigmas (griech. Musterbeispiel) wurde Anfang der sechziger Jahre von Kuhn in die wissenschaftliche Diskussion eingebracht. Kuhn definiert ein Paradigma als eine „[...] allgemein anerkannte wissenschaftliche Leistung, die für eine gewisse Zeit einer Gemeinschaft von Fachleuten maßgebende Probleme und Lösungen liefert.“ Kuhn (1991), S. 10.
Vgl. Frick (1996), S. 45; Balzert (1996), S. 40f. Zum Übergang vom objektorientierten zum strukturierten Paradigma vgl. Quibeldey-Cirkel (1994), S. 10ff.
Vgl. Hesse et al. (Teil 2) (1994), S. 98.
Die elementaren Konzepte des objektorientierten Paradigmas werden in Kapitel 3.2 skizziert.
Inwieweit das objektorientierte Paradigma eine Ergänzung des funktionsorientierten Paradigmas oder ein neues Paradigma ist, soll hier nicht diskutiert werden. Vgl. zu dieser Problematik Frick (1996), S. 45f.
Zu den folgenden Ausführungen vgl. Rosemann (Komplexität) (1996), S. 22–38.
Die Bezeichnungen der Merkmale und Merkmalsausprägungen wurden zum Teil geringfügig modifiziert und werden nachfolgend erläutert. Um eine Übereinstimmung der Begriffe mit den Definitionen von Hesse et al. (Teil 1) (1994) zu erzielen, wurde der Begriff ‚Abstraktionsgrad‘ durch den Begriff ‚Abstraktionsebene‘ ersetzt. Weiterhin wurde das Merkmal ‚Konkretisierungsgrad‘ ergänzt.
Der Begriff ‚Abbildung‘ wird nachfolgend, korrespondierend zur gewählten Modelldefinition, im Sinne von ‚Konstruktion‘ verwendet.
Zur ARIS-Architektur und den unterschiedenen Sichten vgl. Scheer (Methode) (1998), S. 33ff. Ergänzend wird in den neuesten Veröffentlichungen eine Leistungssicht differenziert.
Vom Begriff der Abstraktionsebene ist der Begriff des Abstraktionsgrades zu differenzieren. Der Abstraktionsgrad kann sich auf die Abstraktionsebene (ein Modell auf Typebene ist abstrakter als ein Modell auf Exemplarebene), auf die Beschreibungsebene (ein fachkonzeptuelles Modell ist abstrakter als ein Modell auf Implementierungsebene) oder auf den Konkretisierungsgrad (ein Muster ist abstrakter als ein Framework) eines Modells beziehen. Abstraktionsgrad und Abstraktionsniveau werden synonym verwendet.
Vgl. Hesse et al. (Teil 1) (1994), S. 45.
Zur Darstellung der Entity-Relationship-Modellierung vgl. Kapitel 4.4.1.
Eine Modellierung auf Exemplarebene erfolgt beispielsweise in Objekt- oder Sequenzdiagrammen. Vgl. Kapitel 6.2.2.
Vgl. Hesse et al. (Teil 1) (1994), S. 45.
Vgl. Schütte (Referenzmodellierung) (1997), S. 50.
Vgl. Scheer (Geschäftsprozeß) (1998), S. 38ff.
Der Begriff ‚DV-Konzept‘ ist unglücklich gewählt, da er die Entwicklung von Softwaresystemen impliziert. Im Rahmen der Organisationsgestaltung wird i. d. R. keine spezifische Beschreibungsebene für das Design der Organisation differenziert.
Auch der Quellcode oder der Binärcode eines Softwaresystems kann als Modell angesehen werden. Vgl. Hammel/Schlitt/Wolf (1998), S. 25.
Das Merkmal ‚Konkretisierungsgrad‘ basiert auf dem Ansatz von Holl und Mitterbauer, wiederverwendbare Artefakte nach dem Abstraktionsgrad zu differenzieren. Vgl. Holl/Mitterbauer (1998), S. 65.
Zu ‚Frameworks‘ und ‚Design Patterns‘ vgl. Kapitel 5.
Vgl. Rosemann/Rotthowe (1995), S. 14.
Shlaer und Mellor definieren den Begriff der Domäne wie folgt: “A domain is a separate real, hypothetical, or abstract world inhabited by a distinct set of objects that behave according to rules and policies characteristic of the domain.” Mellor/Shlaer (1993), S. 16.
Es ist zu betonen, daß es absolut allgemeingültige Modelle nicht gibt, sondern daß diese Modelle aus der Perspektive eines Betrachters für eine Klasse von Domänen Gültigkeit haben.
Der Begriff ‚Architektur‘ entstammt dem Bauwesen und wird in den verschiedensten Bereichen verwendet. Im IT-Bereich beispielsweise für Rechnerarchitekturen (vgl. Stahlknecht/Hasenkamp (1997), S. 23ff.) oder hier für Informationssystem(modell)architekturen. Zum Begriff der Architektur in der Wirtschaftsinformatik vgl. Krcmar (1990), S. 396f.
Balzert (1996), S. 639. Der Begriff ‚Softwarearchitektur‘ wird synonym zum Begriff ‚Anwendungssystemarchitektur‘ verwendet.
Zu Anforderungen an Anwendungssystemarchitekturen vgl. Strunz (1997), S. 35f.
Vgl. Ghanei (1997), S. 80.
Vgl. Grotehen/Dittrich (1995). Aktuelle Informationen zu CORBA finden sich auf den WWW-Seiten der Object Management Group unter http://www.omg.org.
Zu dieser Sichtweise des Architekturbegriffes vgl. Kremar (1990), S. 399f.
Vgl. Scheer (Geschäftsprozeß) (1998) und Scheer (Methode) (1998).
Vgl. Ferstl/Sinz (1993).
Vgl. Becker (CIM) (1991), S. 16ff. und die dort zitierte Literatur.
Vgl. Scheer (1990).
Vgl. Becker/Schütte (1996).
Das CIM-Y und das Handels-H haben den Charakter einer Informationssystemmodellarchitektur. Primäres Ziel ist jedoch nicht die Definition von Partialmodellen und entsprechender Beziehungen zwischen diesen Modellen, sondern die inhaltliche Strukturierung der zu erstellenden Modelle. Derartige Architekturen werden auch als Ordnungsrahmen bezeichnet.
Lorenz (1995), S. 876.
Eine Beschreibungssprache urnfaßt neben der Syntax der Sprache auch Regeln, wie die gegebenen Sprach-konstrukte zu verwenden sind. Synonym zum Begriff ‚Regel‘ wird der Begriff ‚Modellierungstechnik‘ verwendet.
Vgl. Raue (1996), S. 7.
Zu den Anforderungen an Modellierungssprachen vgl. Frank/Prasse (1997), S. 2ff.
Es existieren Erweiterungen zu Programmiersprachen (z. B. Eiffel, vgl. Meyer (1997), S. 389) und Modellierungsnotationen (z. B. die Object Constraint Language als Erweiterung zur UML, vgl. Rational (1997), S. 1), um durch Zusicherungen (constraints) die Semantik von Systemelementen zu charakterisieren.
Zum Begriff ‚Vorgehensmodell‘ vgl. Seibt (Vorgehensmodell) (1997), S. 431 ff.
Vgl. Scheer (Methode) (1998).
Vgl. Ferstl/Sinz (1993).
Vgl. Österle (1995).
Vgl. DeMarco (1979); Gane/Sarson (1977). Zur Entwicklung der Strukturierten Analyse vgl. Dischinger (1995), S. 61ff.
Vgl. Yourdon/Constatine (1979); Balzert (1996), S. 802–826 und die dort zitierte Literatur.
Vgl. Balzert (1996), S. 828–862 und die dort zitierte Literatur.
Vgl. Appelfeller (1995), S. 50f.
Vgl. Rumbaugh et al. (1991).
Vgl. Booch (1994).
Vgl. Coad/Yourdon (1991).
Zu einer Darstellung der UML vgl. Kapitel 6.2.
Zu den folgenden Ausführungen vgl. Becker/Schütte (1996), S. 23f.; Rosemann (Komplexität) (1996), S. 42ff.
Zum Begriff ‚Software-Referenzmodell‘ vgl. Kapitel 4.1.
Zu den Vorteilen von Software-Referenzmodellen bei der Softwareauswahl vgl. Scheruhn (Referenzmodell) (1996), S. 117f.; Scheruhn (1995). Zur Problematik des Vergleichs verschiedener Modelle vgl. Rosemann (Komplexität) (1996), S. 102f.
Zum Begriff ‚Customizen‘ vgl. Görk (1997), S. 101 f.
Vgl. Scherahn (Referenzmodell) (1996), S. 112.
Vgl. Zencke (1996); Keller/Schröder (1996); Scheer/Hoffmann/Wein (1994); Keller/Meinhardt (Analyzer) (1994), S. 88.
Zur Bedeutung konzeptueller Modelle für die Anwendungssystementwicklung vgl. Brooks (1987), S. 11.
Zu den Begriffen ‚Software Reengineering‘ und ‚Software Reverse Engineering‘ vgl. Pietsch (1997), S. 364f.
Die Workflow Management Coalition definiert ein Workflowmanagementsystem wie folgt: „A system that completely defines, manages and executes workflow processes through the execution of software whose order of execution is driven by a computer representation of the workflow process logic. “ Workflow Management Coalition (1994), S. 39.
Zur Ableitung von Workflow-Modellen aus Geschäftsprozeßmodellen vgl. Galler (1997); Galler/Scheer (1995).
Vgl. Becker (CIM) (1991), S. 166–191.
Es existiert eine Fülle von Definitionen und eine Menge von Synonymen für den Begriff ‚Geschäftsprozeß‘. Im folgenden wird dem Begriffsverständnis von Becker und Vossen gefolgt, die einen Prozeß definieren als „inhaltlich abgeschlossene, zeitliche und sachlogische Abfolge von Funktionen, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objektes notwendig sind. [...] Eine besondere Untermenge dieser Prozesse sind die Geschäftsprozesse. Die Geschäftsprozesse einer Unternehmung repräsentieren ihre Geschäftsarten, ergeben sich damit aus den obersten Sachzielen und weisen zwingend Schnittstellen zu externen Marktpartnern auf. “ Becker/Vossen (1996), S. 19.
Helling beschreibt beispielsweise die Zertifizierung nach DIN ISO 9000 mit ARIS-Modellen. Vgl. Helling (1998).
Vgl. bspw. Hammer/Champy (1993); Davenport (1993).
Vgl. Liem/Blecher/Gehr (1997).
Zum Begriff der multiperspektivischen Modellierung vgl. Rosemann (Multiperspektivisch) (1996); Frank (1994), S. 163ff.
Vgl. Rosemann (Multiperspektivisch) (1996), S. 230.
Aus der konstruktionsorientierten Modelldefinition resultieren abweichende Anforderungen an die Modellqualität, so wie sie beispielsweise bei Raue (1996), S. 12ff. definiert werden. Homomorphie und Isomorphic zwischen Objekten der Modell- und der Realwelt können wegen der fehlenden Überprüfbarkeit nicht gefordert werden.
Vgl. Rosemann (Komplexität) (1996); Becker/Schütte (1996), S. 65; Becker/Rosemann/Schütte (1995); Rosemann (1998), S. 3–11. Zu einer Erweiterung der GoM vgl. Schütte (Referenzmodellierung) (1997), S. 84–133.
Vgl. Becker/Schütte (1996), S. 67; Rosemann (Komplexität) (1996), S. 94.
Fowler (1997), S. 2.
„[...] a schema is minimal if no concept can be deleted from the schema without losing some information“ Batini/Ceri/Navathe (1992), S. 140.
Vgl. Becker/Schütte (1996), S. 69.
Vgl. Schütte (Referenzmodellierung) (1997), S. 4. Die Modelltiefe ist ein Maß für die Detailliertheit eines Modells. Vgl. dazu Fußnote 307.
Zum Begriff der Komplexität vgl. Bronner (1992), S. 1112. Die Komplexität eines Systems bzw. eines Modells zur Abbildung des Systems ist prinzipiell von zwei Faktoren abhängig: der typmäßigen Komplexität und der extensionalen Komplexität.9 Die typmäßige Komplexität wird durch die Anzahl der verwendeten Systemelementtypen determiniert. Die extensionale Komplexität ergibt sich aus der Anzahl der Systemelemente und der Anzahl der Beziehungen zwischen diesen Elementen. Vgl. Becker/Rosemann (1998), S. 117 und die dort zitierte Literatur.
Vgl. Willmer (1985), S. 32; Wiegert (1995), S. 88; Moody/Shanks (1994), S. 105.
Diese Begriffe sind nicht disjunkt. Zum Begriff der Verständlichkeit vgl. auch Nietsch (1996), S. 94.
Zur Verwendung von Beziehungsmetamodellen vgl. Strahringer (1996), S. 85–120; Rosemann/zur Mühlen (1996), S. 10ff.
„[...] the design process is not deterministic: different designers can produce different enterprise models of the same enterprise“ Hawryszkiewycz (1991), S. 115 zitiert bei Frank (1994), S. 136. Vgl. auch Priemer (1995), S. 296; Moody/Shanks (1994), S. 95.
Vgl. Rosemann (Komplexität) (1996), S. 102. Die Grundsätze ordnungsmäßiger Modellierung (GoM) versuchen, die Modellierungsfreiheiten durch sichten- und methodenspezifische Grundsätze zu reduzieren. Vgl. Rosemann (1998), S. 3–11; Becker/Schütte (1996), S. 65–92; Rosemann (Komplexität) (1996), S. 85–152.
Zu einem Überblick möglicher Beziehungen zwischen den GoM vgl. Schütte (Referenzmodellierung) (1997), S. 106–111.
Vgl. Becker/Schütte (1996), S. 70–92.
Vgl. Meyer (1997), S. 47.
Zu Namenskonventionen für Prozeßmodelle vgl. Rosemann (Komplexität) (1996), S. 201–206.
Vgl. Schütte (Referenzmodellierung) (1997), S. 94f.
Zu einer Darstellung der EPK-Notation vgl. Kapitel 4.4.2.
Vgl. Reisig (1990).
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 Informationssystemmodellierung. In: Objektorientierte Referenzmodellierung. Informationsmanagement und Controlling. Deutscher Universitätsverlag, Wiesbaden. https://doi.org/10.1007/978-3-322-99774-6_2
Download citation
DOI: https://doi.org/10.1007/978-3-322-99774-6_2
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