Ontologien zur Erstellung und Verbreitung von Unternehmensmodellen Anforderungen, Herausforderungen, Erfolgsfaktoren Ulrich Frank iwi

Ontologien zur Erstellung und Verbreitung von Unternehmensmodellen

Anforderungen, Herausforderungen, Erfolgsfaktoren

Ulrich Frank

http://www.uni-koblenz.de/~iwi

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

Geschäftsführer

#include "mm_jsapi.h"/* Every implementation of a Javascript function must have this signature */JSBoolcomputeSum(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

MEMO: Adaptierbare Methode

Methode Struktur Vorgehensweise+=

MEMO-KernMakroprozess

generischer Bezugsrahmen

Mikroprozess

Ziele

Modellierungssprachen

Adaption(z.B.: E-Commerce)

angepasster Bezugsrahmen

erweiterte/modifizierte/neue Modellierungssprachen

angepasster Makroprozess

angepasster Mikroprozess

angepasste Ziele

Bewertungskriterien

Der MEMO-Bezugsrahmen

PersonalTechnologie

PlattformAnwendung

WertketteWertsystem

Organisations-struktur

MitarbeiterBetriebsmittel

SGE Wettbewerbs-fähigkeit

AufgabeProzess

Operative Ziele

ArchitekturObjektmodell

TransaktionWorkflow

AnforderungMetrikP

ersp

ektiv

en

Strategie

Organisation

Informations-system

AspekteRessource Struktur Prozess Ziel

PersonalTechnologie

PlattformAnwendung

WertketteWertsystem

Organisations-struktur

MitarbeiterBetriebsmittel

SGE Wettbewerbs-fähigkeit

AufgabeProzess

Operative Ziele

ArchitekturObjektmodell

TransaktionWorkflow

AnforderungMetrikP

ersp

ektiv

en

Strategie

Organisation

Informations-system

AspekteRessource Struktur Prozess Ziel

http://www.visio.com /

Visio Corporation

http://205.185.183.34/htm l/a.htm l

Product Inform ation

http://205.185.183.34/htm l/i.htm l

Technology Briefs

http://205.185.183.34/htm l/i5.htm l

Technology BriefsBusiness Diagram m ing

http://www.visio.com /SCRIPTS/visio.exe

visio.exe

http://205.185.183.34/htm l/j.htm l

Case Studies

http://205.185.183.34/htm l/j3.htm l

Johnson Controls Inc.

http://205.185.183.34/htm l/j1.htm l

AMOCO Corporation

http://205.185.183.34/htm l/g.htm l

Visio Solutions Library

http://205.185.183.34/htm l/g3.htm l

Engineering

http://205.185.183.34/htm l/g6.htm l

Insurance and Law

http://205.185.183.34/htm l/g5.htm l

Inform ation System s

m ailto:webm aster@ visio.com

webm aster@ visio.com

http://www.visio.com /surveys/vssurv.htm

Download VisioQuickTour Dem o

Type

+m ultiplic ity : Multiplic ity

TypeExpression

+referncedTypes() : List of Type

Prim itive Type

+details : Uninterpreted

Value

-value : Uninterpreted

M odelElem ent Responsibility TaggedValue

Expression

Class UseCase

State

BehaviorInstance

1..n

0..n

references

{im plic it}

0..1

0..n

/characteristic

Instance0..n

0..1

0..n

0..1

0..1

0..n

actions

0..1

0..n

state instance

0..n

0..n

roles

Auftragsbearbeitung in Baustoffgrosshandel (1)

Auftrageingegangen

Lieferfähgikeit klären

Logistik klären

<Sachbearbeiter>

<Fuhrparkleiter>Start

Menge nicht verfügbar

Menge verfügbar

Kunden informieren

<Sachbearbeiter>

Auftrag abgelehnt

Stop

Auslieferung an Wunschtermin nicht

möglich

Auslieferung möglich

Auftrag ablehnen

<Sachbearbeiter>

Auftrag bestätigen

<Sachbearbeiter>

Auftragsbearbeitung in Baustoffgrosshandel (2)

Lieferfähgikeit klären

Logistik klären

<Sachbearbeiter>

<Fuhrparkleiter>Auftrag

eingegangen

Start

Menge nicht verfügbar

Menge verfügbar

Auslieferung an Wunschtermin nicht

möglich

Auslieferung möglich

AND

Auftrag bestätigen

<Sachbearbeiter>

OR

Auftrag ablehnen

<Sachbearbeiter>

Ausschnitt eines Objektmodells in MEMO-OML

Procure-mentAct

SalesOrder

Container

Company

Customer

AbstractPerson

AbstractOrder

Supplierpart of

1,* 1,*

1,* 1,*

acts asby

1,* 1,*

with

1,* 1,* ••

••

acts as

0,1

0,1

Person

MarketSegment

defined for offered as

0,*1,10,* 1,1 1,1

DeliverItem

SegmentItem

OrderItempart of

0,* 1,1

sold as

0,*assigned to

0,*assigned to

1,1

Product 0,*assigned to

0,1 produces

0,* 1,1

Metamodell der MEMO-OML (Ausschnitt)

ObjectModelGenericClass

InteractionLink

BasicAttribute

ClassFeature

BasicService

AssociationLink

BasicInteraction

DeferredInteraction

Attribute

RedefinedAttribute

C1

Spezialisierungen dürfen nicht zyklisch seinC1

part of

1,* 1,1

specialised from

0,* 0,*

features

1,1 0,*

linked via

0,* 1,1

MultiplicityA1,1

RedefinedInteraction

selects

0,*0,*

cont

ext f

or

0,*

0,*

Only InputSpecs that are assignedto BasicProcessType(s) can selectBasic-Service(s).

Str

ateg

y

I

nfor

mat

ion

Sys

tem

specifies

0,*1,1

specifies

0,1 1,1

includ

e1,

1

0,*

uses

1,10,*

specifies0,1

1,1

spec

ifies

0,1

1,1

triggers

0,1

1,*

triggers

1,*

0,1

consists of

0,1 0,*

0,11,*

InputOutputSpec

OutputSpec

probability: real

ProcessTypeInputSpec

ComplexProcessTypeBasicProcessType

ProcessUse

EventType

ContextOfProcessUse

OutputUse

InputOutputUse

InputUse

Position AggregatedUnit

OrganisationalUnit

takes place in

1,1 0,*

responsible for

1,*

0,*

uses

0,* 1,1

uses

0,*1,1

composed of

An Event must notbe isolated.

No cyclicdecomposition ofProcessType(s)

ValueChain

Activity

PrimaryActivity SupportingActivity

part

of

1,1

0,*

0,*

supports

1,*

BasicService

GenericClass

AbstractClass Class

part

of

1,1

0,*

Metamodell der MEMO-OrgML (Ausschnitt)

Integration der Sprachen durchgemeinsame Konzepte

MEMO-OrgML

MEMO-OML

MEMO-SML

InputOutputSpec

ComplexProcessType

OutputSpec

Real

PositionAggregated

Unit

specifies1,1 0,*

composed of

1,*0,*

A0,1

probability

Organisa-tionalUnit

composed of

1,* 0,1

responsib

le for

1,*0,*

ProcessTypecontext for0,1 0,*

ValueChain

incl

ude

s1,

11,

*

Activity

specifies

0,*

0,*

GenericClassBasicServicepart of

0,1 0,*

Die MEMO-Spracharchitektur

Meta-Metamodell

Instanz von

Objektmodelle als Rekonstruktionen

Integriertes Objektmodell

diverse dedizierte Werkzeuge

Sichten auf

Metamodelle

MEMO-OML MEMO-OrgML MEMO-SML

Ebenen von Unternehmensontologien

Grundlegende Konzepte

Generische Anwendungskonzepte

Speziellere Konzepte Elektronischer Zahlungsverkehr

Prozesskosten

Preisbildungs-mechanismus

Prototypische Instanz

Klasse

Ereignis Generalisierung

ZustandAusnahme

AggregationSpezialisierung

Ressource

Rolle Organisationseinheit

Strategie

Geschäftsprozess

Workflow

Wertkette

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 ProduktenProduct

Name: String Description: String

Home_Electronics

Weight: RealE_Consumption: Real...

TV

Screen_Type: S_TypeScreen_Size: Real...

CD_Player

Range: IntegerOptical: Boolean...

Product B Product C

Product I

Product D Product E Product F Product G

Product H

- introduction of new product type implies modification of schema/code

- configurations of products not possible

+ product specific semantics

+ use of generalization allows for additional abstraction

Levels of Abstraction (1)

Meta

Type

Initialized Product Type

language to define product types

product type

particular product type

instance of

instance of

Meta

Type



product type


includesProduct_Type

Name: String Description: String

Feature_Type

Name: StringType: String1,1 0,*

instance of

instance of



Meta

Type



product type


instance of

instance of

TV

Length_Unit: StringWidth_Unit: StringHeight_Unit: StringHeight: RealWidth: RealLength: Realname: StringScreen_Size: RealFrequency: Integer


Meta

Type



product type


TV

Length_Unit: StringWidth_Unit: StringHeight_Unit: StringHeight: RealWidth: RealLength: Realname: StringScreen_Size: RealFrequency: Integer

instance of

instance of

different levels of abstraction


Meta

Type



product type


instance of

instance of

TV

Length_Unit: ‚cm‘Width_Unit: ‚cm‘Height_Unit: ‚cm‘Height: 55Width: 80Length: 52name: Sony TS-88Screen_Size: 60Frequency: 100


Meta

Type



product type


instance of

instance of

redundant

TV

Length_Unit: ‚cm‘Width_Unit: ‚cm‘Height_Unit: ‚cm‘Height: 55Width: 80Length: 52name: Sony TS-88Screen_Size: 60Frequency: 100


Product Type

Specialized Type

product type

product type

specialized from


Product Type

Specialized Type

product type

product type

specialized from

Internet-TV

Length_Unit: StringWidth_Unit: StringHeight_Unit: StringHeight: RealWidth: RealLength: Realname: StringScreen_Size: RealFrequency: IntegerOS: String



Cloned Type

product type

product type

‚cloned‘ from



Cloned Type

product type

product type

‚cloned‘ from

TV

Length_Unit: ‚cm‘Width_Unit: ‚cm‘Height_Unit: ‚cm‘Height: 55Width: 80Length: 52name: Sony T-88Screen_Size: 60Frequency: 50



Particular Product Instance

product type

particular instance

‚instance‘ of



Particular Product Instance

product type

particular instance

‚instance‘ of

TV

Length_Unit: ‚cm‘Width_Unit: ‚cm‘Height_Unit: ‚cm‘Height: 55Width: 80Length: 52name: Sony TS-88Screen_Size: 60Frequency: 100Serial: ‚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

Example:

ProcessType

averageDur: Integer

maxDur: Integer

BasicProcessType AggProcessType

composed of

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

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

Order arrived

Determine ability to deliver

Determine

logistics

<Clerk>

<Head of logistics>

Start

Amount not

available

Amount available

Inform Customer

<Clerk>

Order denied

Stop

Delivery at requested date

not possible

Delivery possible

Deny order

<Clerk>

Confirm order

<Clerk>

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

Person

Dozent

Student

Programmierer

Mitarbeiter

Wieso ist diese Generalisierung problematisch?

PersonStudent

Dozent

Programmierer

Mitarbeiter

Studentischer Programmierer

Studentischer Mitarbeiter

ProgrammierenderStudentische

rMitarbeiter

Mehrfachvererbung

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)

Documents

Ontologien zur Erstellung und Verbreitung von Unternehmensmodellen Anforderungen, Herausforderungen, Erfolgsfaktoren Ulrich Frank iwi