This paper presents a Unified Enterprise Modeling Language (UEML) and a set of mappings which support translating models represented under an Enterprise Modeling Language into another Enterprise Modeling Language. These mappings also permit to integrate (i.e.compose) different models represented in different enterprise modeling languages into a unique model. Additionally, UEML is a meta-model that represents the (abstract) syntax of a Unified Enterprise Modeling Language (UEML 1.0). This paper presents the foundations of the work performed during the UEML project funded by IST Programme of the European Commission 5th Framework. The rationale, the basic principles and the undertaken approach followed to define UEML 1.0. These basic principles and the approach are justified in terms of data integration and database schema integration.
In order to reduce costs and lead times, and to improve the quality (and the range) of
the offered services or products, enterprises take part in organisational paradigms, for
instance, EE (extended enterprise) and VE (virtual enterprise) organisations, where
they cooperate by exchanging flows of information & knowledge, material &
services, and money ([
Since the 80’s, two main approaches to Enterprise Integration (EI) have matured: (i) the integration of software applications that support the functionality of business processes; ii) the definition of Enterprise Models (EMs) by means of Enterprise Modelling Languages (EMLs) and integration of such models, for understanding, validating and effectively achieving EI.
Enterprise modelling is the art of externalising the internal knowledge of an
enterprise by the generation of EMs ([
Enterprises manage and use enterprise models through Enterprise Modelling Tools
(EMTs). The current landscape shows the existence of a lot of enterprises that used to
implement in-house enterprise modelling tools or to buy several tools for supporting
different types of analysis and other usage. Each EMT has a proprietary EML, and
may be coupled with a proprietary enterprise modelling process ([
When two enterprises use different EMLs and they want to exchange EMs there
are some problems which facets are ([
On the other hand, whenever the same EML is used with various and distinct purposes or because of the subjective nature of modelling, different models represented in an EML are probably difficult to be integrated. Problems arised are: − Scope: when two artifacts seem to represent the same meaning but this happens only partially − Coverage and granularity: models seem to embrace the same domain but it is not true. − Modelling conventions − Synonym terms: distinct terms share the same meaning. − Homonym terms: same terms with different meanings depending on the context.. − Encoding: values encoded in different formats (e.g, dates in dd/mm/yy vs mm/dd/yy).
In our opinion, these two dimensions (the first, mostly related to languages and the second, mostly related to models) have to be approached separately because each one comprises many kinds of complex problems and also because they differ in the scope (very broad for languages because languages should provide constructs for describing varieties of situations in most of enterprises, narrower for models because models usually apply to specific enterprises and situations1).
When enterprises pretend to share or combine some of their enterprise models, or whenever various kinds of analysis should be performed on these models, one possi1 We do not consider the problem of “generic reusable models” also called “partial models” in the EM literature. ble approach is to enable (partial) translations of models across distinct languages and tools of the enterprises. These translations should be model-independent.
Whenever an enterprise takes part in a network of enterprises the number of coexisting EMLs, is likely to increase. Therefore, translations between couples of languages, also called peer-to-peer translation (bidirectional arrows in Figure 1), are possible, though difficult and costly to carry out, and not suitable within networks of enterprises where fast changes of partners are usual. The other disadvantage of peerto-peer translations is related to the “maintenance of a global consistency” due to a clear lack of global, unique and consistent vision about the knowledge shared between the enterprises (each EML does not cover all enterprise aspects as it is shown in Figure 1 where three EMTs i.e. MOOGO, eMAGIM and METIS embrace respectively resource monitoring, decision support and enterprise planning).
Therefore, to reduce dramatically the number of interfaces (peer-to-peer translations ) needed to communicate a set of enterprises, and to increase the achievement of a “global consistency”, it is really useful to define an intermediate federator language (depicted in Figure 2) which eventually allows to represent a unique, consistent and modular vision on the shared (or integrated) knowledge of the whole set of enterprises. Thus, such a language, generally called UEML (Unified Enterprise Modelling Language), does not substitute existing EMLs, as its target is to provide effective support for enterprise model translation and integration. In this sense, a UEML should be equipped with standard translation mechanisms to and from existing EMLs. Furthermore, this UEML permits enterprises to retain their EMLs without forcing them to use the UEML itself.
UEML integration-platform
However, the UEML is only one of the needed components for effectively
achieving model translation and integration. Specifically, this UEML is a way to approach
integration problems within the language dimension. A list of current and real
business problems in which a UEML can play a central role is ([
How to build effectively such a UEML? There are various answers to this question
but some facts need to be taken into account:
a. most of the EMLs are not equipped with formal definition of the semantics of
their constructs; therefore it is not obvious (or maybe impossible) to state and to
prove (formally) that a language construct is represented (or translated) into a
construct belonging to some other language;
b. whenever EMLs are equipped with some formal semantics, the semantic
preserving relationships are not unique between distinct languages; therefore, establishing
these relationships is difficult as in the previous case (a); the main difference
between (a) and (b) is that in (b) it may be possible to prove formally that these
relationships are really semantics preserving;
c. whenever some semantic preserving relationships between EMLs have been
formally proved, this is not enough for making these semantic preserving
relationships as acceptable in term of the modelling domain; in other words, a formal
proof of some semantic preserving relationships is not enough for justifying that
two distinct constructs are similar/equivalent (or not similar/equivalent) in term of
the modelling domain (sometime referred to as “real world semantics”([
relationships
The UEML will be therefore the result of reasonable choices concerning relationships between languages. These choices may evolve, i.e. changing or increasing in the number, because it may appear interesting both new relationships between EMLs and new EMLs. As a consequence, any possible choice should be well identified and documented, together UEML itself. This is the reason for defining a “Strategy for UEML”2, Section 4, which represents an attempt for providing a well structured context for making choices about the UEML. The basic principles underlying this “Strategy for UEML” are explained in Section 3.
As any EML, UEML is equipped with a structure (abstract syntax) represented by the
set of constructs and links between them, and some meaning associated to each
construct (i.e. construct semantics) ([
UEML handles the integration problems enumerated in Section 1, essentially
within the language dimension, in the following ways:
− Differences in the (abstract) syntax of the languages: UEML is founded in the
agreement concerning the structure (i.e. the Constructs) of the knowledge (i.e. the
Concepts underlying the Constructs) being exchanged or translated. The way for
expressing this (abstract) syntax is a class model and specifically (just for
convenience) a UML class model ([
UEML3 = Common Concepts + (some of) Non Common Concepts;
This “equation” well represents the UEML as a federator component usually
containing what it is shared among various components (see also Section 4, step
f).
2 The name “Strategy for UEML” is not the most appropriate. However, in this paper, we
maintain the name originally given in the UEML project. Probably, in further developments,
the name may be modified to “Methodology for UEML”.
3 We prefer to distinguish carefully between the construct and the concept underlying the
construct which explicitly refers to “meaning” of the construct: in fact, for instance, while two
constructs may be distinct, the underlying concepts can be the comparable (or equivalent).
− Differences in semantics of “similar” constructs: this is the most difficult type of
problem and it is related to the definition of common concepts. A part of the
complexity comes up because the meaning (i.e. underlying concepts) of most EMLs
constructs is provided by text expressed in natural language: natural language is
ambiguous, words are vague and interpretation depends on both the context and
the person reading/writing the text. Then, using these texts for finding semantic
relationships between constructs belonging to distinct languages is hardly difficult
and quite subjective. To cope with similar problem, previous works concerning
techniques for database schema integration ([
For instance, the first semantic correspondence (1) can be paraphrased as: by looking into the available models, represented in EML1 and EML2 respectively, the model artifacts represented through the concept C1 are also represented by C2 and vice-versa.
In the general case, a common concept C can be introduced if C1 ∩ C2 ≠ ∅ and, in this case, if possible, mappings might be used for better characterising their semantic correspondences through two predicates Φ1 and Φ2 such that Φ1 (C1) ρ Φ2 ( C2) (1) where ρ is ‘=’ or ‘⊇’ or ‘⊆’.
The formula (1) is what can also be found in the peer-to-peer data integration
approach [
Without loosing in generality, a common concept C can be defined by the
following set of semantic correspondences, which characterises, in the data integration
literature, the GLAV approach [
C ⊇ Φ1 (C1).
C ⊇ Φ2 (C2).
C = Φ1 (C1).
C = Φ2 (C2).
These equations provide C as the best approximations of Φ1 (C1) and Φ2 (C2). This approximating concept C is closer to Φ1(C1) and Φ2 (C2) as the inclusion ‘⊇’ becomes the equivalence ‘=’ i.e.: Therefore, common concepts in UEML can be introduced by using the kind of equations defined above.. All these equations can also be used for realizing standard mechanisms for translations from an EML to UEML and vice-versa. However, this point requires some attention because these equations are verified on specific scenarios (i.e. specific models and model artifacts). Nevertheless, if these scenarios deal model-independent translations, this approach is able to find and to justify them.
The approach is also able to manage situations in which one concept in a
language is related to more than one concept in another language. Indeed, more
equations (1) involving a same concept are possible. The main problem is how to consider
this kind of situation for making a UEML. The early work concerning this problem
states that the key point is if the equations (1) whenever involving a same concept
should be used simultaneously or singularly. This early work identifies three
situations:
scenario models are not correct (this situation may not happen if models are
built by experts in the retained EMLs);
4 In this case, language meta-models may be reworked, introducing semantic enrichments as
for database schema integration ([
The UEML project was a pilot project to demonstrate the feasibility of a UEML
according to the objectives described in Section 1. Therefore, the results of the
UEML project were limited to the definition of a first version of the UEML (UEML
1.0) dealing with three EMLs: IEM ([
The ”Strategy for UEML”, that is, the procedure followed to define UEML, is composed of the following steps (depicted in Figure 4): a. It is defined a scenario (a specific description of a problem which plays the role of the set of models and related model artifacts). b. The scenario is modelled by using IEM, GRAI and EEML This task is performed by experts on each of such three languages (however, modelling remains a subjective task). c. Definition of the meta-models of the three languages using UML class diagrams: IEM, GRAI and EEML. These meta-models represent the constructs and the links among them. Each meta-model states what is possible to express with each language (i.e. the language abstract syntax). d. The meta-models of IEM, EEML and GRAI have been verified by UML experts. e. The models built up on step (b) are composed of a set of model artefacts. Following the principles described in Section 3, the semantic correspondences between constructs of each pair of the three modelling languages, have been stated. f. Common and also (some) non-common concepts of the three EMLs have been identified (it should be noted criteria defined in Section 3 work well for identifying common concepts; the remaining concepts can be classified as non common but again in the context of the specific scenario; this means that two concepts can be classified as distinct until new scenarios contradict their “non commonality”; this also means that the result is always correct because we may include in the UEML meta-model more distinct constructs that some other scenarios will reveal their commonality). g. The first version of UEML language has been defined by using the UML class diagram (i.e. UEML 1.0 meta-model). This version takes into account both the common and the non-common concepts, each of the three meta-model languages. h. The table of semantic correspondences between the UEML 1.0 meta-model and
A final verification (using the scenario itself) of the UEML 1.0 meta-model and the found semantic correspondences with the three language meta-models has been performed.
Building Models in EEML and Grai re-implementing the IEM Model in the Scenario of Application Meta-modelling in UML of IEM, Grai, EEML (especially oriented to the Models reimplementing the Scenario of Application)
Validation of Meta-models: IEM, EEML, Grai
Comparison (identifying Correspondences) between couples of Models and Generalisation to Meta-models
Identification the Common and non
Common Concepts Definition of the first version of the UEML meta-model in UML: the UEML1.0 Meta-model Definition of the New Correspondence Table between UEML1.0 Meta-model and each originating Meta-model Validation of the UEML1.0 Meta-model and Correspondences against a subset of the Scenario of Application
The resulting UEML 1.0 meta-model (without attributes) is shown in Figure 5 below.
The Table 2 (output of step h) shown below provides the semantic correspondences between the UEML 1.0 meta-model and the three language meta-models. Such a table is based on the principles advocated previously in Section 3. In fact, each row represents the equations characterising each common concept. Φ1 (C1)
GRAI
Ele
It has been shown the convenience of defining and using a UEML for supporting the EI. We have discussed and justified the basic principles and the adopted approach (“Strategy for UEML”). We have also presented the results of the undertaken approach, specifically the UEML 1.0 meta-model and semantic correspondences between the UEML 1.0 meta-model and the used EMLs i.e. IEM, EEML and GRAI.
The benefits of the “Strategy for UEML” are: - to provide a well defined context for making “decisions” on how to make a
UEML by reusing existing EMLs; - to be based on existing theories and approached in database schema integration and data integration; - to suggest mechanisms for realizing model-independent translations through a UEML between distinct EMLs.
The approach however needs to be refined because some points are not fully explored. Specifically, the definition of common and non common concepts, the use of the equations, the mechanisms for standardised model-independent translations, the relative complexity. Furthermore, alternative approaches to UEML should also be taken into account much more than in the UEML project. During the UEML project a number of needs where enterprise modelling plays a central role have been elicited (in targeted workshops) but poorly used for further improvements of the UEML 1.0 meta-model. Future UEML probably should also be driven by these needs even if they require a lot of work for their refinement.
The authors would like to thank all the UEML IST-2001-34229 core members for their scientific contribution to the work. This work is partially supported by the Commission of the European Communities under the sixth framework programme (INTEROP Network of Excellence, Contract N° 508011, <http://www.interopnoe.org>).