Generally, various models can be used to describe a given application domain on different aspects and thus give rise to several views. To have a complete view of the application domain, heterogeneous models need to be unified, which is a hard task to do. To tackle this problem, we have proposed a method to relate partial models without combining them in a single model. In our approach, partial models are organized as a network of models through a virtual global model called M1C (Model of correspondences between models) which conforms to a ubiquitous language based on a Meta-Model of Correspondences (MMC). This paper presents an application of our method to an “Emergency Department” case study. It has been performed as a collaborative process involving model designers and a supervisor. The focus is put on the building of the M1C model from 3 partial models.
The development of a complex system is usually based on a varied set of
languages, tools and environments that are generally used separately by
modeling experts working on different dimensions of the system. In addition,
developers are often located in distant geographical areas, as it is the case in
distributed collaborative development. This complicates their cooperation. Thus,
a complex system can be often divided into several subsystems: each
subsystem belongs to a specific business domain and may be represented by one or
several partial models designed in a specific language that describes this
business area. It is mandatory to construct a global model to understand and
effectively use knowledge of such a system. The creation of this global model
requires identifying the existing connections between elements of these
partial models. However, the global model construction remains hard, given the
different semantics and the difficulty of identifying correspondences between
these partial models. This issue is typically known as heterogeneity problem.
This problem is shared by the community of complex software systems
designers which gave birth to the GEMOC initiative [
Our approach sets a process that allows the creation of a global view of the system through a composition based on aligning partial models. For establishing correspondences between models, the process first identifies correspondences (HLC - High Level Correspondences) between elements of related metamodels that we call meta-elements, and then generates semi-automatically correspondences between model elements (LLC - Low Level Correspondences).
In El Hamlaoui and al. [
In this paper we present the design of a complex system via a collaborative process by modeling the Emergency Department (ED) of a hospital. Partial models are produced by separate designers who work independently. First, the produced models were analyzed and treated manually by a design expert named “supervisor” so as to remove conflicts due to possible contradictions (e.g. incompatible attribute values, contradictory relationships among classes, etc.). Then the obtained models were aligned by means of correspondences so as to produce a global model which is in fact a network of partial models. The rest of this paper is organized as follows. Section 2 presents a recall of our matching approach. Section 3 introduces the ED case study. Section 4 presents the models defined by different designers, shows the correspondence model that has been obtained and discusses the result of the ED case study. Finally, we present in section 5 some conclusions and future works.
Our solution consists in aligning heterogeneous models by establishing
correspondences between their model elements. Correspondences are saved in a
correspondence model. The following process – see [
Fig. 1. above shows the MMC, annotated with the semantic expression of the relationships, applicable for the Emergency Department case study. For example, the Similarity relationship is described by an expression in Java. The expression explicitly states, using the sameAs function, that the related elements are similar. For the Dependency relationship, since we did not manage to find an expression that can describe it, we have specified it in a natural language.
Emergency Departments (EDs) represent a critical branch of any country's health system. Such departments are usually faced with emergency situations (accidents, natural disasters, terrorist attacks, wars, epidemics, etc.) that need special skills provided by a multidisciplinary approach where viewpoints are complementary. Moreover, a need of coordination between actors must be taken into account in the design phase of such systems, so that the different partial models developed in this phase are synchronized. In addition, models usually evolve due to changing laws, business rules, security constraints and personal data protection. In this case, it is important to re-align partials models to ensure the overall coherence of the system.
Many business domains are involved to represent the functioning of an ED. To design this application domain, we have chosen to represent the scope of three points of view managed separately by the following designers: Medical report designer: responsible for building digital mockups that define an Emergency Examination Report (EER). He creates a model expressed through a form meta-model, Software designer: responsible for the representation of organizational data of the information system. He creates a model expressed through an object-oriented meta-model, Process designer: responsible for the establishment of medical protocols to be applied by ED staffs. He creates a model expressed through a processbased meta-model.
Due to space limit, we invite readers to see meta-models in [
To lead this study, we asked various partners to participate in the elaboration
of partial models describing parts of this complex system. Table 1 shows an
overview of designers and their produced models whereas [
Actor, Laboratory Role Model produced An EER is a form that contains information concerning the patient such as his medical history and diagnosis. Fig. 2 presents an excerpt of this model by using UML object diagram’s concrete syntax.
Fig. 3 below presents an extract of the organizational model of ED, based on UML class diagram’s concrete syntax. For instance, an emergency physician treats a patient and makes diagnosis. The diagnosis decision can lead to a surgery operation. gency physician. For instance, the emergency physician achieves a consultation and makes prescriptions, whereas the nurse takes care of the patient, takes his blood sample and explains doctor’s prescriptions.
Before starting the creation of the different correspondences models, the MMC may have to be specialized to add some relationships specific to the ED domain. Within this context, Fig. 1. (see section 2 above) shows the relationships which have been added to MMC’s kernel with their semantics: Requirement, Deduction and Induction. The first one allows to know the fields that an activity needs for its smooth running. The second one allows to deduce, through a function, the value of another element. The third one is used to represent the operations that an activity invokes for it execution. The following step is the creation of the M2C model (Fig. 5). An example of created HLC is those that relate the meta-element Attribute from the organizational metamodel, to the meta-element Field from the Form meta-model through the following relationships: Similarity, Deduction and Aggregation.
A HLC allows anticipating the complexity of matching by first establishing correspondences between meta-model elements. Thereafter, the accuracy of certain details of abstract model can be managed at the LLC level, obtained by refining HLCs through a propagation operation. HLCs are then refined to produce the M1C model. Primarily, a reproduction operation is initiated on the M2C followed by a selection operation. In other words: M1C = Propagation (M2C) = Selection o Reproduction (M2C). is to duplicate all correspondences defined at the meta-model level into the model ones. In other words, there are as many potential LLCs for a given HLC as Cartesian product of instances of meta-elements involved in the HLC. This operation limits the generation of correspondences to elements whose type participates in a HLC. Even if the contextual information helps avoiding the creation of correspondences between elements of types that do not match (e.g., an Operation and a Field) it does not guarantee that all generated correspondences are semantically correct.
Selection.
This operation consists in filtering out correspondences produced by the reproduction operation in order to keep only those who are valid, with respect to the semantic expression associated to relationships, and filter out the incorrect ones.
Fig. 6. M1C – ED LLCs For relationships with informal expression (in natural language), it is supervisor’s role to decide whether or not to keep the correspondences depending on the expression associated to relationships. Considering the relationships with a formal expression, their expressions (represented as a note in Fig. 1. ) have to be executed. Execution of body’s expressions requires an interpreter of the language in which the expression is written (a Java Virtual Machine JVM in our case). Fig. 6 illustrates the M1C model obtained at end of selection phase. For example, execution of the following method: “tel”. sameAs(“phoneNumber”) returns true. The decision consists in keeping the correspondence involving both elements and deleting the others.
As illustrated in Fig. 5, the alignment at meta-model level is composed of 7 HLCs created semi-automatically with the HMCS tool. Alignment at model level should be obtained automatically. In our ED case study, 15 LLCs have been produced semi-automatically (automatically for the reproduction step and in assisted way for the selection step). The reason for this is firstly to have a model that can serve as reference alignments to evaluate our approach (a golden model) and secondly, because the Semantic Expression DSL has not been yet fully implemented in HMCS to take into account all relationships’ semantics.
In the presented approach we assume that semi-automatic tasks are performed by the supervisor with a global understanding of the various models. This assumption makes the process dependent on him and therefore relatively centralized. For instance, he intervenes in checking whereas the MMC contains all needed specific relationships related to the studied domain. Throughout HMCS, he is responsible for adding appropriate semantics, defining correspondences between meta-elements and removing some correspondences generated at model level, expressed in natural language, that are not valid. These tasks are very difficult to perform by a single person. Relationships defined between partial models may be complex and the number of correspondences generated in reproduction step may be huge. Supervisor may have to ask models’ designers to clarify the scope or meaning of an element and to help deciding whether or not to keep the correspondence, particularly when the semantics is expressed in a natural language.
Our general research addresses the matching of interrelated heterogeneous
models in the context of complex system development. Thereby, we are
interested in establishing correspondences between heterogeneous models
described through different meta-models used in a given application domain. In
industrial developments, this work is done by several (ream of) designers
working collaboratively by involving partial models’ designers. We are aware
that the case studies treated in our previous works (Bug Tracking System, [
Acknowledgment – We thank very much all the participants to the ED case study and in particular Lee Osterweil and Seung Yeob Shin who provided a medical protocol model.