Agenda Why 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

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 Principles Not propose a new language, integrate existing ones Prioritise industrial languages, allow academic ones Allow UEML to continue to grow Allow local tailoring/adaption of UEML Separation of syntax from semantics Both ontological and mathematical semantics Provide 'semantic' (or referential) integration through a common ontology

UEML comprises: A structured approachAn evolving common ontologyA correspondence analysis approachA quality frameworkA modular meta-meta modelA 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 represent The properties it is intended to represent, if any The states it is intended to represent, if any The events it is intended to represent, if any The instantiation levels it is intended to represent: Classes, instances or either The 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 specialisation Property precedence State and transformation specialisation The hierarchies are interrelated The concepts are attributed