Ontologien zur Erstellung und Verbreitung von Unternehmensmodellen Anforderungen, Herausforderungen, Erfolgsfaktoren Ulrich Frank http://www.uni-koblenz.de/~iwi

Überblick Unternehmensmodellierung mit MEMO Ebenen von Unternehmensontologien Offene Probleme der Unternehmensmodellierung Kritische Anmerkungen zur Ontologieforschung Hinweise für eine erfolgreiche Ontologieforschung in der Wirtschaftsinformatik

Motivation: Vermeidung von Mehrarbeit und Friktionen durch gemeinsame Sprache Berater #include "mm_jsapi.h" /* Every implementation of a Javascript function must have this signature */ JSBool computeSum(JSContext *cx, JSObject *obj, unsigned int argc, jsval *argv, jsval *rval) { long a, b, sum; /* Make sure the right number of arguments were passed in */ if (argc != 2) return JS_FALSE; Programmierer Geschäftsführer

MEMO: Adaptierbare Methode = Struktur + Vorgehensweise Bewertungskriterien Makroprozess generischer Bezugsrahmen Mikroprozess Ziele Modellierungssprachen MEMO-Kern angepasster Bezugsrahmen erweiterte/modifizierte/neue Modellierungssprachen angepasster Makroprozess angepasster Mikroprozess angepasste Ziele Adaption (z.B.: E-Commerce)

Perspektiven Aspekte Aspekte Perspektiven Der MEMO-Bezugsrahmen Personal Technologie Plattform Anwendung Wertkette Wertsystem Organisations-struktur Mitarbeiter Betriebsmittel SGE Wettbewerbs-fähigkeit Aufgabe Prozess Operative Ziele Architektur Objektmodell Transaktion Workflow Anforderung Metrik Perspektiven Strategie Organisation Informations-system Aspekte Ressource Struktur Ziel Aspekte Ressource Struktur Prozess Ziel Personal Technologie Plattform Anwendung Wertkette Wertsystem Organisations-struktur Mitarbeiter Betriebsmittel SGE Wettbewerbs-fähigkeit Aufgabe Prozess Operative Ziele Architektur Objektmodell Transaktion Workflow Anforderung Metrik Strategie Organisation Informations-system Perspektiven

Auftragsbearbeitung in Baustoffgrosshandel (1) <Sachbearbeiter> Stop Kunden informieren Auftrag abgelehnt Menge nicht verfügbar <Sachbearbeiter> <Sachbearbeiter> Start Auslieferung an Wunschtermin nicht möglich <Fuhrparkleiter> Lieferfähgikeit klären Auftrag ablehnen Auftrag eingegangen <Sachbearbeiter> Menge verfügbar Logistik klären Auftrag bestätigen Auslieferung möglich

Auftragsbearbeitung in Baustoffgrosshandel (2) <Sachbearbeiter> <Sachbearbeiter> Menge nicht verfügbar OR Auftrag ablehnen Lieferfähgikeit klären Menge verfügbar Start Auftrag eingegangen <Fuhrparkleiter> <Sachbearbeiter> Auslieferung an Wunschtermin nicht möglich Logistik klären AND Auftrag bestätigen Auslieferung möglich

Ausschnitt eines Objektmodells in MEMO-OML

Metamodell der MEMO-OML (Ausschnitt) part of GenericClass ObjectModel Attribute 1,* 1,1 C1 BasicAttribute specialised from Redefined Attribute 0,* 0,* features ClassFeature 1,1 0,* Spezialisierungen dürfen nicht zyklisch sein C1 BasicService A Multiplicity InteractionLink 1,1 Deferred Interaction linked via Association Link Basic Interaction 0,* 1,1 Redefined Interaction

Metamodell der MEMO-OrgML (Ausschnitt)

Integration der Sprachen durch gemeinsame Konzepte MEMO-OrgML MEMO-OML MEMO-SML specifies 0,* GenericClass BasicService part of 0,1 InputOutput Spec Complex ProcessType OutputSpec Real Position Aggregated Unit specifies 1,1 0,* composed of 1,* A 0,1 probability Organisa-tionalUnit responsible for ProcessType context for 0,1 0,* ValueChain includes 1,1 1,* Activity

Die MEMO-Spracharchitektur Meta-Metamodell Instanz von Metamodelle MEMO-OML MEMO-OrgML MEMO-SML Objektmodelle als Rekonstruktionen Integriertes Objektmodell diverse dedizierte Werkzeuge Sichten auf

Ebenen von Unternehmensontologien Grundlegende Konzepte Klasse Ereignis Generalisierung Zustand Ausnahme Aggregation Spezialisierung Generische Anwendungskonzepte Ressource Rolle Organisationseinheit Strategie Geschäftsprozess Workflow Wertkette Speziellere Konzepte Elektronischer Zahlungsverkehr Prozesskosten Preisbildungs-mechanismus Prototypische Instanz

Offene Probleme der Unternehmensmodellierung Grenzen der Formalisierbarkeit Unterscheidung von Abstraktionsebenen Spezialisierung vs. Instanzierung Spezialisierung von Prozesstypen Semantische Friktionen zwischen Modellierung und Implementierung

Grenzen (?) der Formalisierbarkeit zahlreiche Begriffe, die sich gegen funktional äquivalente Formalisierung sperren (intentionale Semantik, nicht überschaubare Varianz ...) Beispiele: Wettbewerbsfähigkeit Kundenorientierung ... Gefahr: begriffsverzerrende Vereinfachungen Beschränkung auf sinnvoll formalisierbare Begriffe als Alternative?

Unterscheidung von Abstraktionsebenen gängige Unterscheidung in Meta- und Objektebene nicht immer hinreichend alltagsweltlicher Sprachgebrauch durch Überladung von Begriffen (Abstraktionsebenen) gekennzeichnet zusätzliches Problem: Systementwicklung sieht i.d.R. nur zwei Abstraktionsebenen vor

Beispiel: Modellierung von Produkten Product Name: String Description: String Product B Product C Product I Product D Product E Product F Product G Product H Home_Electronics Weight: Real E_Consumption: Real ... TV Screen_Type: S_Type Screen_Size: Real ... CD_Player Range: Integer Optical: Boolean ... + product specific semantics + use of generalization allows for additional abstraction - introduction of new product type implies modification of schema/code - configurations of products not possible

Levels of Abstraction (1) language to define product types Meta instance of Type product type instance of Initialized Product Type particular product type

Levels of Abstraction (1) language to define product types Meta instance of Type product type instance of Initialized Product Type particular product type includes Product_Type Name: String Description: String Feature_Type Name: String Type: String 1,1 0,*

Levels of Abstraction (1) language to define product types Meta instance of Type product type instance of Initialized Product Type particular product type TV Length_Unit: String Width_Unit: String Height_Unit: String Height: Real Width: Real Length: Real name: String Screen_Size: Real Frequency: Integer

Levels of Abstraction (1) language to define product types Meta instance of Type product type instance of Initialized Product Type particular product type TV Length_Unit: String Width_Unit: String Height_Unit: String Height: Real Width: Real Length: Real name: String Screen_Size: Real Frequency: Integer different levels of abstraction

Levels of Abstraction (1) language to define product types Meta instance of Type product type instance of Initialized Product Type particular product type TV Length_Unit: ‚cm‘ Width_Unit: ‚cm‘ Height_Unit: ‚cm‘ Height: 55 Width: 80 Length: 52 name: Sony TS-88 Screen_Size: 60 Frequency: 100

Levels of Abstraction (1) language to define product types Meta instance of Type product type instance of Initialized Product Type particular product type TV Length_Unit: ‚cm‘ Width_Unit: ‚cm‘ Height_Unit: ‚cm‘ Height: 55 Width: 80 Length: 52 name: Sony TS-88 Screen_Size: 60 Frequency: 100 redundant

Levels of Abstraction (2) Product Type product type specialized from Specialized Type product type

Levels of Abstraction (2) Product Type product type specialized from Specialized Type product type Internet-TV Length_Unit: String Width_Unit: String Height_Unit: String Height: Real Width: Real Length: Real name: String Screen_Size: Real Frequency: Integer OS: String

Levels of Abstraction (3) Initialized Product Type product type ‚cloned‘ from Cloned Type product type

Levels of Abstraction (3) Initialized Product Type product type ‚cloned‘ from Cloned Type product type TV Length_Unit: ‚cm‘ Width_Unit: ‚cm‘ Height_Unit: ‚cm‘ Height: 55 Width: 80 Length: 52 name: Sony T-88 Screen_Size: 60 Frequency: 50

Levels of Abstraction (4) Initialized Product Type product type ‚instance‘ of Particular Product Instance particular instance

Levels of Abstraction (4) Initialized Product Type product type ‚instance‘ of Particular Product Instance particular instance TV Length_Unit: ‚cm‘ Width_Unit: ‚cm‘ Height_Unit: ‚cm‘ Height: 55 Width: 80 Length: 52 name: Sony TS-88 Screen_Size: 60 Frequency: 100 Serial: ‚AV-7392C‘

Problem domain suggests multiple levels of abstraction in some cases conflict between instantiation and specialisation relationships common system architectures allow for two layers (schema, instance) only Consequences no perfect solution feasible instead: overloading of existing layers

Spezialisierung vs. Instanzierung Differenzierung umgangssprachlich diffus: in beiden Fällen häufig „is a“ formal allerdings eindeutig unterscheidbar Problem: mitunter beides benötigt, Konzepte aber nicht orthogonal

Abstraction 1: Generalisation identify common properties of a set of classes define superclass using these properties Example: GenericProcess startsAt: Time EndsAt: Time OrderManagement scheduledFor: Time CheckIn priority: Integer

Generalisation - Evaluation + fosters re-use of concepts within subclasses + corresponds to a common way to organize knowledge - restricted to the introduction of concepts that can be specialized from existing ones - hence, lacks flexibility required for continous growth of knowledge within a KMS

Abstraction 2: Metaconcepts define the concepts needed to specify a type ProcessType averageDur: Integer maxDur: Integer composed of Example: BasicProcessType AggProcessType

Instantiation - Evaluation + allows for introducing new concepts as instances of metaconcepts + corresponds to a specialized language - does not allow for the re-use of knowledge about features of instances - requires more levels of abstraction than usually available

Spezialisierung von Prozesstypen Order arrived Determine ability to deliver Determine logistics <Clerk> <Head of logistics> Start Amount not available Amount available Inform Customer Order denied Stop Delivery at requested date not possible Delivery possible Deny order Confirm order wichtiges Konzept zur Förderung von Wiederverwendbarkeit und Wartbarkeit einige Vorschläge zur Spezifikation von Spezialisierung in der Literatur aber: bisher keine überzeugende Lösung

Friktion zwischen Modellierungs- und Implementierungssprachen – Beispiel: Spezialisierung

Generalisierung/Spezialisierung scheinbar intuitives Konzept aber: keine einheitliche Semantik Alltagsweltliches Verständnis weicht in mitunter subtiler Weise von formaler Semantik bei Programmier- oder Datenbanksprachen ab. Vor allem: Semantik gängiger Programmiersprachen unterscheidet sich zum Teil erheblich vom Alltagsverständnis

Generalisierungshierarchie - Beispiel Dozent Student Person Programmierer Mitarbeiter Wieso ist diese Generalisierung problematisch?

Mehrfachvererbung Was ist hier problematisch? Person Dozent Student Studentischer Programmierer Person Studentischer Mitarbeiter ProgrammierenderStudentischerMitarbeiter Programmierer Mitarbeiter Was ist hier problematisch?

Problemursache Kontra-Intuitive Semantik von Generalisierung/ Spezialisierung in gängigen Programmiersprachen: Ein Objekt gehört immer genau einer (und nur einer) Klasse an Alltagsweltliche Bedeutung: Klassenzugehörigkeit kann mit dem Kontext variieren. Extensionale Klassenbegriffe in der Mathematik (Mengenlehre) oder Teilgebieten der Informatik (z.B. Datenbanken) erlauben ebenfalls, dass ein Objekt gleichzeitig mehreren Klassen zugehört.

Kritische Anmerkungen zur Ontologieforschung das Sprachparadoxon isoliert: in der Informatik weitgehend losgelöst von der (Referenz-) Modellierung unzureichende Profilierung gegenüber alternativen Ansätzen (vor allem: Sprachen) zentrales Problem: mangelnde Zielorientierung ergo: keine überzeugenden Maßstäbe für Qualität und Erfolgskontrolle

Fazit: Erfolgsfaktoren für die Ontologieforschung Kritik an Unzulänglichkeiten der Begriffsbildung in Fachdisziplinen, insbesondere im Bereich der konzeptionellen Modellierung aber auch: Präsentation leistungsfähiger Lösungen Ziele der Ontologieformulierung explizit machen, Ergebnisse daran messen offener Wettbewerb alternativer Ontologiesprachen (impliziert kritischen, nachvollziehbaren Vergleich)