UEML

AgendaWhy UEML is needed?UEML Overview

Common Enterprise Models

Ref.:The Unified Enterprise Modelling Language Overview and Further Work-Victor Anaya, Giuseppe Berio, Mounira Harzallah, Patrick Heymans, Raimundas Matulevičius, Andreas L. Opdahl, Hervé Panettoand Maria Jose Verdecho

Some well-known EM techniques

Data Flow Diagrams: SSAD, Yourdon, De Marco, … Entity-relationship methods: MERISE, NIAM, M*, T-SER, … SADT IDEF suite of methods: IDEF0, IDEF1x and IDEF3 GRAI nets OMT and UML CIMOSA IEM ARIS method SA / RT Harel's Statecharts Activity-Based Costing methods

ARIS ToolSet FirstSTEP KBSI suite NCR Metis PrimeObjects Bonapart CimTool … Worfklow systems (WorkParty, IBM FlowMark,

IBM VisualAge, Action Workflow, COSA, Ensemble, …)

Some well-known EM tools

Issues Too many EM languages Unstable vocabulary and modelling

paradigms Many incompatible EM tools / weak

process interoperation

-> UEML

What is UEML intended to be

Not the ultimate EM language to replace all previous ones

But a standard meta-model (and underlying ontologies) widely accepted by business users and tool developers

Easy to learn and to use with sufficient descriptiveapabilities

Consensus in the EM community Provide a uniform interface to enterprise

modelling tools and a neutral format for exchange of enterprise models

UEML’s Vision:

An intermediate language for

integrated use of enterprise models

expressed in different languages

UEML PrinciplesNot propose a new language, integrate

existing onesPrioritise industrial languages, allow

academic onesAllow UEML to continue to growAllow local tailoring/adaption of UEMLSeparation of syntax from semanticsBoth ontological and mathematical semanticsProvide 'semantic' (or referential) integration

through a common ontology

UEML comprises:A structured approach

An evolving common ontology

A correspondence analysis approach

A quality framework

A modular meta-meta model

A set of tools to aid its use and evolution

UEML Language Description Structure

Language and Construct Description

Separation of Reference

What a modelling construct is intended to represent is described in terms of:The classes it is intended to representThe properties it is intended to represent, if anyThe states it is intended to represent, if anyThe events it is intended to represent, if anyThe instantiation levels it is intended to represent:

Classes, instances or eitherThe modality it is intended to represent:

Does it assert facts or express beliefs, knowledge, intentions etc.

The classes, properties, states and events are mapped onto the common UEML ontology

The UEML Meta-Meta Model

The Common UEML Ontology

Four interrelated taxonomies:Class specialisationProperty precedenceState and transformation specialisation

The hierarchies are interrelatedThe concepts are attributed