State-of-the-Art der Referenzmodellierung für Medieninformationsssyteme

Inhaltsverzeichnis

Abbildungsverzeichnis

1 Einleitung

2 Grundlagen
2.1 Informationssystemmodelle
2.1.1 Begriffsabgrenzung
2.1.2 Informationssystem-Architektur
2.2 Referenzmodelle
2.2.1 Begriffsabgrenzung
2.2.2 Anforderungen an Referenzmodelle

3 Modellierungstechniken
3.1 Strukturierter Ansatz
3.1.1 Entity-Relationship-Modelle
3.1.2 Ereignisgesteuerte Prozeßketten
3.2 Objektorientierter Ansatz

4 Referenzmodellierung im branchenspezifischen Kontext
4.1 ARIS
4.2 Existierende Branchen-Referenzmodelle
4.2.1 Referenzmodelle für die Industrie
4.2.2 Referenzmodelle für den Handel
4.3 Referenzmodellierung für die Medienbranche
4.3.1 Motivation
4.3.2 Wahl des objektorientierten Ansatzes für die Modellierung
4.3.3 Vorgehensmodell und Spezifizierung der Modellierungstechniken

5 Fazit

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 2.1.1/1: Morphologischer Kasten der Informationssystemmodellierung

Abbildung 4.1/1 : ARIS-Konzept

Abbildung 4.2.1/1: ERM-Modell einer Kontenstruktur

Abbildung 4.2.2/1: Handels-H-Modell

Abbildung 4.3.3/1: Vorgehensmodell

Abbildung 4.3.3/2: Integration von Struktur- und Verhaltenssicht

1 Einleitung

Die vorliegende Arbeit befasst sich mit der Thematik der Referenzmodellierung von Informationssystemen und untersucht in diesem Zusammenhang besonders die Anwendung im Bereich der Medieninformationssysteme. Dazu werden zunächst die Grundlagen von Informationssystem- und Referenzmodellen behandelt, um in einem nächsten Schritt geeignete Techniken zur Beschreibung dieser Modelle zu skizzieren. Anschließend werden bestehende Referenzmodelle, die sich in branchenabhängige Modelle und jene aufteilen, die keiner speziellen Branche zugeordnet sind, dargestellt. Vor dem Hintergrund existierenden Lösungen wird diskutiert, inwieweit diese sich auf die Medienbranche übertragen lassen und ob ggf. ein eigenes Referenzmodell für diesen Bereich entwickelt werden muß. In dieser Betrachtung spielt dann auch die Art und Weise eines evtl. Vorgehens eine erhebliche Rolle, das beispielhaft skizziert wird.

2 Grundlagen

2.1 Informationssystemmodelle

2.1.1 Begriffsabgrenzung

Ein Informationssystemmodell bildet auf einem gewissen Abstraktionsniveau ein zu erstellendes bzw. bestehendes betriebliches Informationssystem ab und „ist das Ergebnis einer Konstruktion eines Modellierers, der für Anwendungs- und Organisationsgestalter Informationenüber zu modellierende Elemente eines Systems zu einer Zeit als relevant mit Hilfe einer Sprache deklariert hat¹.“ Die Erstellung von Informationssystemmodellen ist durch zwei vorherrschende Paradigmen gekennzeichnet: den strukturierten und den objektorientierten Ansatz. Das strukturierte Paradigma zeichnet sich dadurch aus, daß durch einen Top-Down- Ansatz, wie man ihn aus der Systemtheorie kennt, die einzelnen Aspekte eines Informationssystems zerlegt und in Form von Funktions-, Daten- und Verhaltensmodellen dargestellt werden. Die Modellierung auf Implementierungsebene, also die Anwendungssystemerstellung, erfolgt mit Hilfe prozeduraler bzw. imperativer Programmiersprachen².

Beim objektorientierten Ansatz werden Struktur (Daten bzw. Objekte) und Verhalten (Funktionen³ bzw. Prozesse) gekapselt , so daß keine generelle Trennung von Daten, Funktionen und Prozessen stattfindet.

Informationssystemmodelle können anhand verschiedener Merkmale differenziert und somit nach bestimmten Klassifikationskriterien eingeteilt werden:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1.1/1: Morphologischer Kasten der Informationssystemmodellierung⁴

Zur Beschreibung von Informationssystemmodellen kann bezüglich des Merkmals Beschreibungssicht zwischen den Ausprägungen Struktursicht und Verhaltenssicht differenziert werden. Die Struktursicht hat einen statischen Charakter und bildet die Elemente (Daten bzw. Objekte) eines Informationssystems und deren Beziehungen untereinander ab. Bei der Modellierung hat sich für den strukturierten Ansatz als Beschreibungssprache das Entity-Relationship-Modell (ERM) durchgesetzt. Verfolgt man die Entwicklung beim objektorientierten Paradigma, so ist die Unified Modelling Language (UML) im Begriffe, sich als Praxis-Standard zu etablieren.

Die Verhaltenssicht zeichnet sich durch eine dynamische Betrachtungsweise aus, in der Prozesse bzw. das Systemverhalten abgebildet werden. Die beim strukturierten Paradigma in Theorie und Praxis bevorzugte Beschreibungssprache ist die Methode der Ereignisgesteuerten Prozeßketten (EPK), beim objektorientierten Vorgehen wird wiederum UML am häufigsten verwendet.

Die Abstraktionsebenen eines Informationssystemmodells beschreiben den Detaillierungsgrad eines abzubildenden Originals und sind zu unterscheiden in Ausprägungsebene (Beschreibung konkreter Gegenstände des abzubildenden Teils der Realwelt, z.B. Kunde), Typebene (durch weitere Abstraktion von der Ausprägungsebene, z.B. Klasse von Kunden), Meta-Ebene (durch wiederum weitergeführte Abstraktion von der Typebene, z.B. beschreibt beim ERM ein Entitytyp die Typen Kunde und Auftrag) und Meta-Metaebene (beliebige Erhöhung des Abstraktionsgrades).

Die Beschreibungsebene stellt die Nähe des Modells zur Informationstechnik bzw. in anderer Richtung zur Problemdomäne⁵ dar und ist nur für Modelle auf Typebene gültig. Eine Unterteilung erfolgt in Fachkonzept, DV-Konzept und Implementierung.

Das Fachkonzept als abstrakteste Modellierungsstufe eines Informationssystemmodells dokumentiert die Anforderungen an ein Informationssystem und wird zusammen mit den Anwendern aus den jeweiligen Fachabteilungen erstellt und hat somit die Zielsetzung, "die Funktionen sowie ihre Zusammenhänge und die zu verarbeitenden Informationen in einem abgegrenzten Unternehmensbereich herauszuarbeiten⁶." Es ist unabhängig von der späteren Implementierung, so daß evtl. Änderungen im Programmcode - entstanden bspw. durch technischen Fortschritt - sich nicht auf das Fachkonzept auswirken.

Bei der DV-technischen Konzeption orientiert sich die Modellierung näher an der physischen Implementierung bzw. der Laufzeitumgebung des Informationssystems. Auf Basis des Fachkonzepts werden die dort erarbeiteten Daten- und Funktionsmodelle mittels geeigneter Beschreibungsformen in eher implementierungsorientierte und -vorbereitende Modelle überführt.

Die Implementierung weist als detaillierteste Stufe eines Informationssystemmodells die größte Nähe zur Informationstechnik auf und wird ausgedrückt in Programmierbzw. Datenbanksprachen. Diese Modelle können nach einer Compilierung interpretiert bzw. ausgeführt werden.

Der Detaillierungsgrad eines Informationssystemmodells auf der Beschreibungsebene spiegelt sich im Konkretisierungsgrad wider und hat die Ausprägungen abstrakt oder ausformuliert. Ein abstraktes Beispiel auf Fachkonzeptebene wäre eine textuelle Beschreibung, das ausformulierte Pendant dazu die Formulierung mit Hilfe der EPK.

Bezüglich des Merkmals Geltungsanspruch ist zu unterscheiden zwischen Ist-Modell (dokumentiert den aktuellen Zustand einer Problemdomäne), Ideal-Modell (beschreibt die optimale Gestaltung einer Problemdomäne) und Soll-Modell (realisierungsfähige Version eines Ideal-Modells).

Den Umfang des Adressatenkreises, für den ein Informationssystemmodell von Bedeutung ist, charakterisiert die inhaltliche Individualität. Zu Differenzieren ist zwischen (unternehmens-) spezifischen Informationssystemmodellen (beziehen auf spezielles und in dieser Form einmaliges Problem eines Anwendungsbereiches einer Unternehmung bzw. eines Elementes einer Unternehmung⁷, das in der Regel nicht übertragbar auf andere Probleme anderer Unternehmen bzw. auf deren einzelne Elemente ist), und nicht spezifischen Informationssystemmodellen, die grundsätzlich Referenzmodell-Charakter haben. Hierbei kann noch unterschieden werden zwischen domänenunabhängigen Referenzmodellen („enthalten universelles fachliches bzw. modellierungstechnisches Know-how, ohne Bezug zu einem bestimmten Anwendungsbereich⁸ “) und domänenabhängigen Referenzmodellen (beziehen sich auf eine bestimmte Branche oder betrieblichen Funktionsbereich).

2.1.2 Informationssystem-Architektur

Wie bei der Beschreibung des Informationssystemmodells deutlich geworden ist, kann selbiges aus unterschiedlichen Blickwinkeln heraus modelliert werden, z.B. je nachdem, wie eng der Bezug zur Problemdomäne bzw. zur Informationstechnik ist oder ob eher statischer bzw. dynamischer Sachverhalt abgebildet werden soll. Bei letzterem erfolgt somit mindestens eine Trennung auf Beschreibungssichtebene zwischen Struktur- und Verhaltenssicht, wodurch unterschiedliche Partialmodelle mit u.U. unterschiedlichen Beschreibungssprachen generiert werden. Um eine Verbindung zwischen den Partialmodellen zu schaffen, bedient man sich einer Informationssystem-Architektur, die „die für ein Informationssystem relevanten Elemente und deren Beziehungen⁹ “ definiert.

Informationssystemarchitekturen können domänenunabhängig sein, was bedeutet, daß die Teilmodelle zwar in einen Rahmen eingeordnet werden können, eine betriebswirtschaftliche Einordnung aber nicht möglich ist (z.B. ARIS¹⁰ oder SOM¹¹). Domänenabhängige Informationssystem-Architekturen hingegen erlauben die Einordnung der Modelle entsprechend der abgebildeten betriebswirtschaftlichen Semantik (z.B. Handels-H¹² oder CIM-OSA¹³ bzw. CIM-Y¹⁴).

Die Gestaltung der Architektur impliziert in gewisser Weise die Wahl der Beschreibungssprachen, da eine Unterteilung in Sichten vorgenommen wird, die wiederum mit unterschiedlichen Sprachen beschieben werden. Bei der Integration der unterschiedlichen Sprachen müssen evtl. Inkompatibilitäten mit der durch die Architektur vorgegebenen Systemstrukturierung vermiedenen werden, was in der Praxis durch Architekur-Sprachen-Kombinationen geschieht.

2.2 Referenzmodelle

2.2.1 Begriffsabgrenzung

Ein Referenz-Informationsmodell, im folgenden abkürzend mit Referenzmodell bezeichnet, ist "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 hat, so daßein Bezugspunkt für ein Informationssystem geschaffen wird¹⁵." Die Grundidee von Referenzmodellen ist es, induktiv auf Basis bereits bestehender Modelle, Anwendungssystemdokumentationen, Fachkonzepten, Expertenbefragungen etc. und deduktiv durch theoretische Erkenntnisse fachliches als auch modellierungstechnisches Know-how zu speichern, um eine Empfehlung für nun hieraus abzuleitende unternehmensspezifische Modelle zu geben. Entsprechend des morphologischen Kastens der Informationssystemmodellierung kann nun ein Referenzmodell charakterisiert werden:

Bzgl. der Beschreibungssicht sowohl die Struktur- als auch die Verhaltenssicht relevant, wenn auch die Beschreibung statischer Inhalte durch die Struktursicht dominiert, nicht zuletzt aufgrund einfacheren Modellierung und Verständlichkeit. Referenzmodelle bewegen sich bei Abstraktionsebene nur auf Typebene, um später aus ihnen individuelle Modelle gewinnen zu können.

Bei der Beschreibungsebene spielt im Rahmen der Referenzmodellierung nur das Fachkonzept eine Rolle, vor allem wegen der gegebenen Allgemeingültigkeit und der längeren "Lebensdauer". Das bedeutet, daß Referenzmodelle völlig unabhängig von der späteren Implementierung zu interpretieren sind.

Der Konkretisierungsgrad von Referenzmodellen kann beliebig sein.

Für den Geltungsanspruch gilt, daß Referenzmodelle grundsätzlich Idealmodelle sind.

Bezüglich der inhaltlichen Individualität gilt für Referenzmodelle, daß sie stets unternehmensunspezifisch sind, also immer für eine Klasse von Unternehmen mit ähnlichen Strukturen entwickelt werden.

2.2.2 Anforderungen an Referenzmodelle

Wichtigste Anforderung an Referenzmodelle und gleichzeitig der Grundidee immanent ist das Prinzip der Wiederverwendbarkeit. Aus den für Informationssystemmodelle geltenden "Grundsätzen ordnungsmäßiger Modellierung (GoM)¹⁶ ", die auf ROSEMANN¹⁷ zurückgehen, können für Referenzmodelle spezielle Anforderungen abgeleitet werden, die die Forderung nach Wiederverwendbarkeit unterstützen:

- Modularer Aufbau: Durch Module¹⁸ wird die Wiederverwendbarkeit erhöht, da es einfacher ist, einen einzelnen Baustein wiederzuverwenden als das ganz Modell.
- Allgemeingültigkeit: Durch einen gewissen Abstraktionsgrad, der gegeben sein muß, ist gewährleistet, daß ein Referenzmodell Allgemeingültigkeit besitzt und auf unterschiedliche Problemstellungen anwendbar ist.
- Anpassbarkeit: Referenzmodelle dürfen nicht zu abstrakt formuliert werden, da sonst die Aussagekraft verloren geht. Andererseits führt eine zu hohe Komplexität zu unverständlichen Modellen mit geringer Aussagekraft. Um Referenzmodelle dennoch der gegebenen Problemstellung anpassen zu können, müssen die Voraussetzungen für mögliche durchzuführende Modifikationen, Erweiterungen und Eliminierungen geschaffen werden, was durch eine modulare Struktur erreicht wird. Da jeweils einzelne Module aus dem Refernzmodell übernommen und geändert bzw. erweitert werden können, ist die Anpassbarkeit an jeweilige unternehmensspezifische Informationssystemmodell gegeben.

3 Modellierungstechniken

Wie in Abschnitt 2.1.1 angedeutet, existieren bei der Informationssystemmoldellierung auf fachkonzeptueller Ebene - und somit auch bei der Referenzmodellierung - zwei konträre Ideologien: der strukturierte und der objektorientierte Ansatz. Die mit dem jeweiligen Paradigma einhergehenden Beschreibungssprachen werden im folgenden kritisch betrachtet und bzgl. ihrer Einsatzmöglichkeiten hin untersucht.

3.1 Strukturierter Ansatz

3.1.1 Entity-Relationship-Modelle

Die Struktursicht, also die statischen Elemente eines Referenzmodells in Form von Daten, werden beim strukturierten Paradigma gegenwärtig in aller Regel mit dem Entity-Relationship-Modell (ERM)¹⁹ abgebildet, da es „als das gegenwärtig am meisten verwendete Beschreibungsverfahren für sachlogische Datenstrukturen²⁰ “ gilt. Das ERM zeichnet sich vor allem durch seine Einfachheit und leichte Verständlichkeit aus, wodurch es auch Personen zugänglich ist, die keine größere Affinität zu Referenzmodellierung bzw. Informationssystemerstellung haben. Hiermit sind insbesondere Mitarbeiter der Fachabteilungen gemeint, die wesentlichen Anteil an Erstellung des Fachkonzepts haben. Durch den Einsatz von ERMs wird somit eine interdisziplinäre Kommunikationsgrundlage geschaffen, die die Qualität des Referenzmodells erhöht.

Die Einfachheit der Beschreibungssprache in ihrer Urform impliziert den Nachteil, die betriebliche Realität nur begrenzt zu erfassen. Um diesen Nachteil zu eliminieren, wurden verschiedene Erweiterungen, zu denen bspw. SERM²¹ zählt, vorgenommen, die aber auch die Komplexität erhöhen und damit die Verständlichkeit mindern²².

3.1.2 Ereignisgesteuerte Prozeßketten

Die Verhaltenssicht, also Prozesse dargestellt durch Funktionen, werden durch Ereignisgesteuerte Prozeßketten (EPKs) modelliert, da dieses Verfahren ebenfalls sehr verbreitet ist²³. Genau wie für das ERM gilt für die EPKs, daß sie aufgrund ihrer Einfachheit auch den Fachanwendern ohne modellierungstechnisches Know-how zugänglich sind, was allerdings dazu führt, daß sehr komplexe Abläufe mit zahlreichen Verzweigungen und Fallunterscheidungen kaum darstellbar sind. Außerdem wird durch die Bedingung, daß jeder Funktion ein Ereignis folgen bzw. eine Funktion durch ein Ereignis ausgelöst werden muß, ungewollt erreicht, daß einfache Sachverhalte kompliziert und u.U. unüberschaubar dargestellt werden.

3.2 Objektorientierter Ansatz

Im Gegensatz zur klassischen Referenzmodellierung erfolgt beim objektorientierten Vorgehen keine grundsätzliche Trennung von Struktur- und Verhaltenssicht, indem die zu modellierenden Funktionen und Daten in Klassen gekapselt werden.

[...]

¹ Vgl. Schütte (1998), S. 63.

² Vgl. Schwegmann (1999), S. 8.

³ Bei der objektorientierten Programmierung (Implementierungsebene) werden Funktionen als Methoden bezeichnet, um den Unterschied zum strukturierten Paradigma zu verdeutlichen. Dieser Unterschied wird auf der Fachebene, die bei der Referenzmodellieung von maßgeblichem Interesse ist, nicht getroffen. Man spricht auf dieser Abstraktionsstufe nur zusammenfassend von dem "Verhalten" eines Systems.

⁴ Vgl. Rosemann (1996), S. 22-38.

⁵ Der Begriff Domäne wird innerhalb dieser Arbeit im Sinne von Branche (Handel, Industrie) oder betriebswirtschaftlichem Funktionsbereich (Rechnungswesen, Lager, Einkauf usw.) verstanden, vgl. Schwegmann (1999), S. 12.

⁶ Vgl. Schumann/ Schüle/ Schumann (1994), S. 50.

⁷ Je nach Gestaltung der Aufbauorganisation der betrachteten Unternehmung kann ein Element in dem hier verwendeten Zusammenhang ein betrieblicher Funktionsbereich aber auch z.B. eine Sparte bei Spartenorganisation sein, Vgl. Wöhe (1996), S. 183ff.

⁸ Vgl. Schwegmann (1999), S. 12.

⁹ Vgl. Scheer (1992), S. 2.

¹⁰ Vgl. Scheer (1992), S. 18.

¹¹ Vgl. Ferstl/ Sinz (1993), S. 216f.

¹² Vgl. Becker/ Schütte (1996) S. 11.

¹³ Vgl. Becker (1991), S. 16ff.

¹⁴ Vgl. Scheer (1990).

¹⁵ Vgl. Schwegmann (1999), S. 53.

¹⁶ Zu den Grundsätzen ordnungsmäßiger Modellierung zählen Richtigkeit, Relevanz, Wirtschaftlichkeit, Klarheit, Vergleichbarkeit und systematischer Aufbau. Durch alle Faktoren wird die Informationsmodellqualität beeinflußt.

¹⁷ Vgl. Rosemann (1998).

¹⁸ Unter Modul versteht man im Softwareengineering einen abgeschlossenen Softwarebaustein, der Dienstleistungen über klar definierte Schnittstellen anbietet.

¹⁹ Das ERM geht auf Chen zurück, vgl. Chen (1976).

²⁰ Vgl. Schumann/ Schüle/ Schumann (1994), S. 53.

²¹ Vgl. Ferstl/ Sinz (2001), S.141ff.

²² Vgl. Schumann/ Schüle/ Schumann (1994), S. 58ff.

²³ Vgl. Nüttgens/ Zimmermann (1998), S. 2.