Advertisement

Grundlagen der Informationssystemmodellierung

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

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.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. 8.
    Hesse et al. (Teil 1) (1994), S. 42.Google Scholar
  2. 9.
    Zu den Ausführungen zum Systembegriff vgl. Schütte (Referenzmodellierung) (1997), S. 24ff. und die dort zitierte Literatur.Google Scholar
  3. 10.
    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.Google Scholar
  4. 11.
    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.Google Scholar
  5. 12.
    Zur Verwendung des Begriffes ‚Informationssystem‘ vgl. Mertens/Holzner (1992), S. 21 f.Google Scholar
  6. 13.
    Krcmar (1990), S. 396. Vergleichbare Definitionen finden sich beispielsweise bei Seibt (Anwendungsarchitektur) (1997), S. 39; Balzert (1996), S. 24.Google Scholar
  7. 14.
    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.Google Scholar
  8. 15.
    Zu den folgenden Ausführungen vgl. Ferstl/Sinz (1993), S. 3f.Google Scholar
  9. 16.
    Zu den Begriffen ‚Erklärungsmodell‘ und ‚Gestaltungsmodell‘ vgl. Adam (1996), S. 87f.Google Scholar
  10. 17.
    Schütte (Referenzmodellierung) (1997), S. 42.Google Scholar
  11. 18.
    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.Google Scholar
  12. 19.
    Vgl. Schütte (Referenzmodellierung) (1997), S. 35.Google Scholar
  13. 20.
    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.Google Scholar
  14. 21.
    Schütte (Referenzmodellierung) (1997), S. 45. Der Begriff ‚Informationsmodell‘ wird synonym zum Begriff ‚Informationssystemmodell‘ verwendet.Google Scholar
  15. 22.
    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.Google Scholar
  16. 23.
    Vgl. Frick (1996), S. 45; Balzert (1996), S. 40f. Zum Übergang vom objektorientierten zum strukturierten Paradigma vgl. Quibeldey-Cirkel (1994), S. 10ff.Google Scholar
  17. 24.
    Vgl. Hesse et al. (Teil 2) (1994), S. 98.Google Scholar
  18. 25.
    Die elementaren Konzepte des objektorientierten Paradigmas werden in Kapitel 3.2 skizziert.Google Scholar
  19. 26.
    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.Google Scholar
  20. 27.
    Zu den folgenden Ausführungen vgl. Rosemann (Komplexität) (1996), S. 22–38.Google Scholar
  21. 28.
    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.Google Scholar
  22. 29.
    Der Begriff ‚Abbildung‘ wird nachfolgend, korrespondierend zur gewählten Modelldefinition, im Sinne von ‚Konstruktion‘ verwendet.Google Scholar
  23. 30.
    Zur ARIS-Architektur und den unterschiedenen Sichten vgl. Scheer (Methode) (1998), S. 33ff. Ergänzend wird in den neuesten Veröffentlichungen eine Leistungssicht differenziert.Google Scholar
  24. 31.
    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.Google Scholar
  25. 32.
    Vgl. Hesse et al. (Teil 1) (1994), S. 45.Google Scholar
  26. 33.
    Zur Darstellung der Entity-Relationship-Modellierung vgl. Kapitel 4.4.1.Google Scholar
  27. 34.
    Eine Modellierung auf Exemplarebene erfolgt beispielsweise in Objekt- oder Sequenzdiagrammen. Vgl. Kapitel 6.2.2.Google Scholar
  28. 35.
    Vgl. Hesse et al. (Teil 1) (1994), S. 45.Google Scholar
  29. 36.
    Vgl. Schütte (Referenzmodellierung) (1997), S. 50.Google Scholar
  30. 37.
    Vgl. Scheer (Geschäftsprozeß) (1998), S. 38ff.Google Scholar
  31. 38.
    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.Google Scholar
  32. 39.
    Auch der Quellcode oder der Binärcode eines Softwaresystems kann als Modell angesehen werden. Vgl. Hammel/Schlitt/Wolf (1998), S. 25.Google Scholar
  33. 40.
    Das Merkmal ‚Konkretisierungsgrad‘ basiert auf dem Ansatz von Holl und Mitterbauer, wiederverwendbare Artefakte nach dem Abstraktionsgrad zu differenzieren. Vgl. Holl/Mitterbauer (1998), S. 65.Google Scholar
  34. 41.
    Zu ‚Frameworks‘ und ‚Design Patterns‘ vgl. Kapitel 5.Google Scholar
  35. 42.
    Vgl. Rosemann/Rotthowe (1995), S. 14.Google Scholar
  36. 43.
    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.Google Scholar
  37. 44.
    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.Google Scholar
  38. 45.
    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.Google Scholar
  39. 46.
    Balzert (1996), S. 639. Der Begriff ‚Softwarearchitektur‘ wird synonym zum Begriff ‚Anwendungssystemarchitektur‘ verwendet.Google Scholar
  40. 47.
    Zu Anforderungen an Anwendungssystemarchitekturen vgl. Strunz (1997), S. 35f.Google Scholar
  41. 48.
    Vgl. Ghanei (1997), S. 80.Google Scholar
  42. 49.
    Vgl. Grotehen/Dittrich (1995). Aktuelle Informationen zu CORBA finden sich auf den WWW-Seiten der Object Management Group unter http://www.omg.org.
  43. 50.
    Zu dieser Sichtweise des Architekturbegriffes vgl. Kremar (1990), S. 399f.Google Scholar
  44. 51.
    Vgl. Scheer (Geschäftsprozeß) (1998) und Scheer (Methode) (1998).Google Scholar
  45. 52.
    Vgl. Ferstl/Sinz (1993).Google Scholar
  46. 53.
    Vgl. Becker (CIM) (1991), S. 16ff. und die dort zitierte Literatur.Google Scholar
  47. 54.
    Vgl. Scheer (1990).Google Scholar
  48. 55.
    Vgl. Becker/Schütte (1996).Google Scholar
  49. 56.
    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.Google Scholar
  50. 57.
    Lorenz (1995), S. 876.Google Scholar
  51. 58.
    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.Google Scholar
  52. 59.
    Vgl. Raue (1996), S. 7.Google Scholar
  53. 60.
    Zu den Anforderungen an Modellierungssprachen vgl. Frank/Prasse (1997), S. 2ff.Google Scholar
  54. 61.
    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.Google Scholar
  55. 62.
    Zum Begriff ‚Vorgehensmodell‘ vgl. Seibt (Vorgehensmodell) (1997), S. 431 ff.Google Scholar
  56. 63.
    Vgl. Scheer (Methode) (1998).Google Scholar
  57. 64.
    Vgl. Ferstl/Sinz (1993).Google Scholar
  58. 65.
    Vgl. Österle (1995).Google Scholar
  59. 66.
    Vgl. DeMarco (1979); Gane/Sarson (1977). Zur Entwicklung der Strukturierten Analyse vgl. Dischinger (1995), S. 61ff.Google Scholar
  60. 67.
    Vgl. Yourdon/Constatine (1979); Balzert (1996), S. 802–826 und die dort zitierte Literatur.Google Scholar
  61. 68.
    Vgl. Balzert (1996), S. 828–862 und die dort zitierte Literatur.Google Scholar
  62. 69.
    Vgl. Appelfeller (1995), S. 50f.Google Scholar
  63. 70.
    Vgl. Rumbaugh et al. (1991).Google Scholar
  64. 71.
    Vgl. Booch (1994).Google Scholar
  65. 72.
    Vgl. Coad/Yourdon (1991).Google Scholar
  66. 73.
    Zu einer Darstellung der UML vgl. Kapitel 6.2.Google Scholar
  67. 74.
    Zu den folgenden Ausführungen vgl. Becker/Schütte (1996), S. 23f.; Rosemann (Komplexität) (1996), S. 42ff.Google Scholar
  68. 75.
    Zum Begriff ‚Software-Referenzmodell‘ vgl. Kapitel 4.1.Google Scholar
  69. 76.
    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.Google Scholar
  70. 77.
    Zum Begriff ‚Customizen‘ vgl. Görk (1997), S. 101 f.Google Scholar
  71. 78.
    Vgl. Scherahn (Referenzmodell) (1996), S. 112.Google Scholar
  72. 79.
    Vgl. Zencke (1996); Keller/Schröder (1996); Scheer/Hoffmann/Wein (1994); Keller/Meinhardt (Analyzer) (1994), S. 88.Google Scholar
  73. 80.
    Zur Bedeutung konzeptueller Modelle für die Anwendungssystementwicklung vgl. Brooks (1987), S. 11.Google Scholar
  74. 81.
    Zu den Begriffen ‚Software Reengineering‘ und ‚Software Reverse Engineering‘ vgl. Pietsch (1997), S. 364f.Google Scholar
  75. 82.
    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.Google Scholar
  76. 83.
    Zur Ableitung von Workflow-Modellen aus Geschäftsprozeßmodellen vgl. Galler (1997); Galler/Scheer (1995).Google Scholar
  77. 84.
    Vgl. Becker (CIM) (1991), S. 166–191.Google Scholar
  78. 85.
    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.Google Scholar
  79. 86.
    Helling beschreibt beispielsweise die Zertifizierung nach DIN ISO 9000 mit ARIS-Modellen. Vgl. Helling (1998).Google Scholar
  80. 87.
    Vgl. bspw. Hammer/Champy (1993); Davenport (1993).Google Scholar
  81. 88.
    Vgl. Liem/Blecher/Gehr (1997).Google Scholar
  82. 89.
    Zum Begriff der multiperspektivischen Modellierung vgl. Rosemann (Multiperspektivisch) (1996); Frank (1994), S. 163ff.Google Scholar
  83. 90.
    Vgl. Rosemann (Multiperspektivisch) (1996), S. 230.Google Scholar
  84. 91.
    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.Google Scholar
  85. 92.
    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.Google Scholar
  86. 93.
    Vgl. Becker/Schütte (1996), S. 67; Rosemann (Komplexität) (1996), S. 94.Google Scholar
  87. 94.
    Fowler (1997), S. 2.Google Scholar
  88. 95.
    „[...] a schema is minimal if no concept can be deleted from the schema without losing some information“ Batini/Ceri/Navathe (1992), S. 140.Google Scholar
  89. 96.
    Vgl. Becker/Schütte (1996), S. 69.Google Scholar
  90. 97.
    Vgl. Schütte (Referenzmodellierung) (1997), S. 4. Die Modelltiefe ist ein Maß für die Detailliertheit eines Modells. Vgl. dazu Fußnote 307.Google Scholar
  91. 98.
    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.Google Scholar
  92. 99.
    Vgl. Willmer (1985), S. 32; Wiegert (1995), S. 88; Moody/Shanks (1994), S. 105.Google Scholar
  93. 100.
    Diese Begriffe sind nicht disjunkt. Zum Begriff der Verständlichkeit vgl. auch Nietsch (1996), S. 94.Google Scholar
  94. 101.
    Zur Verwendung von Beziehungsmetamodellen vgl. Strahringer (1996), S. 85–120; Rosemann/zur Mühlen (1996), S. 10ff.Google Scholar
  95. 102.
    „[...] 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.Google Scholar
  96. 103.
    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.Google Scholar
  97. 104.
    Zu einem Überblick möglicher Beziehungen zwischen den GoM vgl. Schütte (Referenzmodellierung) (1997), S. 106–111.Google Scholar
  98. 105.
    Vgl. Becker/Schütte (1996), S. 70–92.Google Scholar
  99. 106.
    Vgl. Meyer (1997), S. 47.Google Scholar
  100. 107.
    Zu Namenskonventionen für Prozeßmodelle vgl. Rosemann (Komplexität) (1996), S. 201–206.Google Scholar
  101. 108.
    Vgl. Schütte (Referenzmodellierung) (1997), S. 94f.Google Scholar
  102. 109.
    Zu einer Darstellung der EPK-Notation vgl. Kapitel 4.4.2.Google Scholar
  103. 110.
    Vgl. Reisig (1990).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