Philadelphia University

Faculty of Information Technology

DEPARTMENT OF COMPUTER SCIENCE

USING THE SOFTWARE RESOURCE MODEL SUB-PROFILE

FOR MULTISCALE COUPLING LIBRARY AND
ENVIRONMENT SIMULATION PLATFORM MODELING

By
Mujahed Ahmad Ibrahim

Supervisor
Prof. Mohamed Bettaz

This Thesis was Submitted in Partial Fulfillment of the

Requirements for the Master's Degree in Computer Science

Deanship of Academic Research and Graduate Studies

Philadelphia University

2018
 II

‫جبهعخ فيالدلفيب‬
‫ًوىرج التفىيض‬

‫جبهعاخ فيالدلفياب ثتضوياذ ًسا هاي سسابلت للوكتجابد أو الوؤسسابد أو‬ ‫ أفاى‬،‫أًاب هجبهاذ أمواذ ًواش اثاشاهين‬
.‫الهيئبد أو األشخبص عٌذ طلجهب‬
:‫التىقيع‬
: ‫التبسي‬

Philadelphia University
Authorization Form
I am Mujahed Ahmad Nimer Ibrahim authorize Philadelphia University to supply
copies of my Thesis to libraries or establishments or individuals upon request.

Signature:
Date:
 ‫‪III‬‬

‫استخذام الولف الفشع قبلت الوصذس الجشهج ف ًوزجخ هٌصخ هحبكبح ثيئخ وهكتجخ اقتشاى هتعذد الٌطبقبد‬

‫اعذاد‬
‫هجبهذ أموذ اثشاهين‬

‫الوششف‬
‫أ‪.‬د هحوذ ثطبص‬

‫قذهذ هزٍ الشسبلخ استكوبال لوتطلجبد الحصىل على دسجخ الوبجستيش ف علن الحبسىة ‪.‬‬

‫عوبدح الجحث العلو والذساسبد العليب‬

‫جبهعخ فيالدلفيب‬

‫كبًىى الثبً ‪1028 ،‬‬

 IV

USING THE SOFTWARE RESOURCE MODEL SUB-PROFILE FOR

MULTISCALE COUPLING LIBRARY AND ENVIRONMENT
SIMULATION PLATFORM MODELING

By
Mujahed Ahmad Ibrahim

Supervisor
Prof. Mohamed Bettaz

This Thesis was Submitted in Partial Fulfillment of the Requirements for the
Master’s Degree in Computer Science.

Deanship of Academic Research and Graduate Studies

Philadelphia University

Jan, 2018
 V

Committee Decision
 VI

DEDICATION

I dedicate this work to my beloved parents; my wife; my little daughters; my

brothers and my sister; to my great supervisor and my friends, I appreciate
everything they did for me.

Eng.Mujahed Ibrahim
 VII

ACKNOWLEDGEMENT

I would first like to thank my thesis supervisor Prof.Mohamed Bettaz for his
endless support and for his patience.
My thanks to Dr. Mourad Maouche for his help, advice and support.

A lot of thanks to all my teachers at Philadelphia University for

Everything they have done for me. Special thanks to my friends for their
Continuous support and encouragement.

Eng.Mujahed Ibrahim
 VIII

Table of Contents

Subject Page
Committee Decision V
Dedication VI
Acknowledgement VII
Table of Contents VIII
List of Figures X
List of Tables XI
List of Abbreviations XII
Abstract XIII

CHAPTER ONE: INTRODUCTION 1

1.1 Preface 2
1.2 Research Context 3
1.3 Problem Statement 4
1.4 Motivation 5
1.5 Research Methodology 6
1.6 Thesis Contributions 6
1.7 Thesis layout 7

CHAPTER TWO: BACKGROUND 8

2.1 Introduction 9
2.2 Multiscale Modeling 9
2.2.1 Scale Separation Map (SSM) 10
2.2.2 Generic Submodel Execution Loop (SEL) 11
2.3 Multiscale Coupling Library and Environment (MUSCLE) 11
2.3.1 Architecture of MUSCLE 12
2.3.2 Using MUSCLE for Modeling (Coral Growth as example) 14
2.4 MDA Y-Structure 16
2.5 UML/MARTE 16

CHAPTER THREE: LITERATURE REVIEW 18

3.1 Introduction 19
3.2 UML/MARTE Methodology for Heterogeneous systems design 19
3.3 Extending UML/MARTE-GRM for integrating Tasks migrations in class 20
diagram
3.4 Generic framework for multi-disciplinary environmental modeling 20
3.5UML profile for modeling and analysis of RTES (MARTE) 20
3.6 Conclusion 21
 IX

CHAPTER FOUR: METHODOLOGY AND CONTRIBUTION 22

4.1 Introduction 23
4.2 Software Resource Model (SRM) sub-profile for DMMS 24
4.3 Outline of the SRM domain view 25
4.4 A three-step modeling methodology 26
4.4.1 Step1: identifying the core concepts of MUSCLE 27
4.4.2 Step2: Selecting a relevant subset of SRM stereotypes 28
4.4.3 Step3: SRM stereotypes adaptations, refinements and UML extensions 30
4.5 Modeling MUSCLE core elements 32
4.6 MDA Y-structure and MUSCLE core elements 44
4.7 Conclusion 46

CHAPTER FIVE: EVALUATION 47

5.1 Introduction 48
5.2 Evaluation 48

CHAPTER SIX: CONCLUSION AND FUTURE WORK 49

6.1 Conclusion 50
6.2 Future Work 50

REFERENCES 51

‫ملخص‬ 55
 X

List of Figures

Figure Number Figure Title Page

1.1 Methodological levels of the research project 4
2.1 An example SSM of a classical macro–micro model 10
2.2 Multiscale model with two submodels 10
2.3 SEL of a submodel 11
2.4 An example of the MUSCLE runtime environment 12
2.5 Simulated coral growth and its three subsystems 14
2.6 Coral growth subsystems as submodels 15
2.7 Structure of the SRM modeling framework 17
2.8 Device extended by server stereotype 17
4.1 Ways of modeling MUSCLE using MARTE 23
4.2 SRM profile overview 26
4.3 Methodology for reusing the SRM profile in modeling the 27
target domain (MUSCLE)
4.4 MUSCLE core concepts 28
4.5 UML extensions for SRM 31
4.6 Modeling a MUSCLE Submodel with SRM step1 33
4.7 The SW_Concurrency profile overview 34
4.8 Modeling a MUSCLE Submodel with SRM step2 35
4.9 Modeling a MUSCLE Submodel with SRM step3 36
4.10 Modeling Single scale model with SRM 37
4.11 Modeling Controller with SRM 39
4.12 Modeling Conduit with SRM 40
4.13 Modeling Port with SRM 41
4.14 Modeling Filter with SRM 42
4.15 Modeling Mapper with SRM 43
4.16 MDA principle 44
4.17 MUSCLE core elements as MDA Y-structure 45
 XI

List of Tables

Table Number Table Title Page

4.1 MUSCLE Concepts with SW_Concurrency 31
4.2 MUSCLE Concepts with SW_Interaction 32
5.1 Comparison between modeling MUSCLE with DMMS 48
and with MDE
 XII

List of Abbreviations

Abbreviation Full Name

API Application Programming Interface
CSP Communicating sequential processes
DMMS Distributed Multiscale Modeling and Simulation
GRM General Resource Model
HRM Hardware Resource Model
MARTE Modeling and Analysis of Real-Time and Embedded systems
MDA Model Driven Architecture
MDE Model-Driven Engineering
MUSCLE Multiscale Coupling Library and Environment
OZ Object-Z
PDM Platform Description Model
PIM Platform Independent Model
PSM Platform Specific Model
RTES Real-Time Embedded Systems
RTOS Real-Time Operating System
SEL Submodel Execution Loop
SRM Software Resource Model
UML Unified Modeling Language
 XIII

USING THE SOFTWARE RESOURCE MODEL SUB-PROFILE

FOR MULTISCALE COUPLING LIBRARY AND
ENVIRONMENT SIMULATION PLATFORM MODELING
Abstract

This research work proposes a development methodology that aims to adopt the
UML/MARTE through its SRM and bridging the gap between the e-science and Software
Engineering communities. In recent years it has been noticed that the design practices are
moving from traditional code-based engineering to Model-Driven Engineering (MDE)
approaches. In UML, a profile can be defined to customize the standard model elements for
specific purposes. A profile furthermore defines one or more UML stereotypes in order to
mark a type as a representation of a particular kind of object. In the Real-time and
Embedded Systems (RTES) domain, the UML/MARTE is used. MARTE has a Generic
Resource Model (GRM) profile which offers the concepts that are necessary to model a
general platform for executing real-time embedded applications. The GRM has two profiles
(SRM and HRM) acting as API. SRM (Software Resource Model) is a UML profile used to
describe API of software execution and allows users to describe RTE API and specific RTE
libraries (middleware) as well; which are involved in the design cycle. As a motivation and
after deeper study conducted on the e-science and Software Engineering fields, we have
found that both UML/MARTE and Distributed Multiscale Modeling and Simulation
(DMMS) modelers are using similar modeling methodology (Y structure design).
Furthermore, the fact that SRM sub-profile can be used to model OS (for instance: RTOS)
as well as modeling specific RTE libraries or Middleware (in DMMS; MUSCLE might be
seen as a kind of middleware). This motivated us to go forward in reusing the SRM sub-
profile in the context of the simulation domain.
As a result, the proposed software development methodology is applicable for some of
MUSCLE core elements, some other elements could not be modeled by SRM due to the
incompatibility issues with SRM stereotypes. Due to the result, it has been concluded that
using the second way of modeling (extending the SRM) would be better for modeling all
the core elements of MUSCLE.
 1

Chapter One:

INTRODUCTION
 2

1.1 Preface

Models and modeling have been essential tools of engineering since long time ago.
An engineering model has been defined in (Selic, B., Gérard, S., 2013) as: “a reduced
representation of some system that captures accurately and concisely all the essential
properties of interest for a given set of concerns”. Models are not new in software
development and the application of models to software development has become more
popular since the development of the Unified Modeling Language (UML) (Topçu, O. et al,
2016).
Model Driven Engineering (MDE) (Gherbi, T. et al, 2009) is a software
development approach family based on the use of models in the software construction. It
allows the exploitation of models to simulate, estimate, understand, communicate and
produce code. Therefore, MDE considers that everything is a model. The authors of (Topçu,
O. et al, 2016) presented the principles and the concepts of developing Distributed
Simulation (DS) from the Model Driven Engineering (MDE) perspective and they have
shown the potential synergies between DS and MDE technologies.

In several disciplines, what is known as Distributed Multiscale Modeling and

Simulation (DMMS) approach is used to model complex natural processes. Furthermore,
researches (Borgdorff, J. et al, 2013), (Borgdorff, J. et al, 2014), and (Belgacem, M. B. et al,
2013) have shown the use of the DMMS approach for modeling e-science phenomena; the
papers also introduced a framework known as Multiscale Coupling Library and
Environment (MUSCLE) that used in MAPPER project (Hoekstra, A. G., 2010). MUSCLE
(Borgdorff, J., 2012) is designed to implement and execute tightly coupled multiscale
models on heterogeneous hardware and clusters. In addition, MUSCLE has some modeling
elements such as: Controller, Conduit and filter; a controller in MUSCLE is implemented
by a so-called Submodel Execution Loop (SEL) (Borgdorff, J. et al, 2013, a).
 3

As a supplement to UML; MARTE (Modeling and Analysis of Real-Time and

Embedded systems) has been designed as a domain specific modeling language intended
for model-based design and analysis. MARTE provides support for: specification, design
and verification/validation stages.

1.2 Research Context

This research work is a part of the research project entitled “Towards a UML/MARTE
CSP-OZ Based Software Development Methodology” (Maouche, M., Bettaz, M., 2016, a),
the research work is going to adopt the software development methodology combining in a
sound way a UML profile (UML/MARTE) for the requirements level.

The idea of the research project that our work is related to was born from the current
preoccupations met by the stakeholders of the Dead Sea environmental issues (water
quality, water level, climatology, geology, tourism, agriculture, etc.). One of the potential
solutions to study the interaction and coupling between phenomena coming from different
domains (natural science and socio-economic disciplines) is Modeling and Simulation, so
the project is aimed to fulfill the objective of setting a systematic and sound software
development methodology for the development of Multi-discipline and multi-scale
simulation environments (development and simulation platforms).

The research project (Maouche, M., Bettaz, M., 2016, a) proposes a software
development methodology combining in a sound way a UML profile (UML/MARTE) for
the requirements level, CSP-OZ for the specification and design level, and PyCSP
(programming language mixing Python and CSP) for the implementation level. Figure 1.1
shows the different methodological levels of the research project (our research work is
going to handle the requirements level).
 4

Figure 1.1: Methodological levels of the research project

The context of this research work is to use the existing SRM profile (from
UML/MARTE) for the context of the simulation domain (MUSCLE is our target domain).
The research work will show that the proposed software development methodology is
applicable to Distributed Multiscale Modeling and Simulation frameworks (DMMS). Also,
fulfilling the requirements level will help in moving to the design level (CSP-OZ).

1.3 Problem Statement

Multiscale computing has become increasingly popular recently in many disciplines.

The Distributed Multiscale Modeling and Simulation (DMMS) approach is being used to
model complex natural processes and phenomena. While recently, it has been seen that the
design practice is moving from traditional code-based engineering to Model-Driven
Engineering (MDE) approaches. So, there is a gap between the e-science and the Software
Engineering communities. Furthermore, we cannot go directly from the DMMS to CSP to
formally verify the properties of the system. While in the other hand, the UML/MARTE
models are deadlock free and can be transformed to CSP.
 5

The research work is aiming to solve the following issues:

- The design practice in DMMS is traditional code-based engineering.
- Modeling the MUSCLE core elements by using UML/MARTE.
-We cannot go directly from the DMMS to CSP to formally verify the properties of the
system.

1.4 Motivation

As it has been previously mentioned, the modern design practice is moving from
traditional code-based engineering to Model-Driven Engineering (MDE) approaches. But
the DMMS is adopting the traditional design practice, so by adopting the UML/MARTE
through its SRM and apply it to the DMMS we are bridging the gap between the e-science
and Software Engineering communities.

As a motivation why to apply UML/MARTE to DMMS, a deeper study of both

UML/MARTE and DMMS shows:
1- UML/MARTE and DMMS modelers are using similar modeling methodology (Y
structure design).
2- UML/MARTE and DMMS are adopting a component-based approach.
3- UML/MARTE supports concurrency, synchronization and communication features.
4- UML/MARTE defines an explicit model for the (logical/physical) time concept.
 6

1.5 Research Methodology

The objectives of the research work have been achieved through:

1- Studying the distributed multiscale modeling and its related methodologies and
approaches.
2- Specifying the core elements of DMMS (MUSCLE is our target domain).
3- Studying the UML/MARTE- GRM in depth.
4- Deepen the study of the PIM, PSM and PDM submodels.
5- Specifying an approach for reusing the SRM profile in modelling the target domain
(MUSCLE).
6- Modeling MUSCLE core elements using some relevant SRM sub-profiles.
7- Evaluate the proposed approach

1.6 Thesis Contributions

By adopting the UML/MARTE through its SRM and apply it to the DMMS, the
research work will contribute through:

1- Using the SRM sub-profile in the context of the simulation domain.

2- Using the SRM sub-profile for MUSCLE simulation platform modeling (MUSCLE
is our target domain)
3- Highlighting the advantages of modeling using model driven approaches.
4- Applying the proposed software development methodology to Distributed
Multiscale Modeling and Simulation frameworks (DMMS).
 7

1.7 Thesis Layout

The rest of this thesis is organized as:

Chapter two presents the main concepts that have been used in the research work. And
chapter three presents the literature review and the related work of the thesis. In chapter
four, the contribution of the research work will be introduced and shows how the SRM sub-
profile has been used in the context of the simulation domain. The evaluation of the
research work will be presented in chapter five. Finally, chapter six presents the conclusion
and future work
 8

Chapter Two:

BACKGROUND
 9

2.1 Introduction

This chapter highlights the main concepts used in this research work including:
- Multiscale Modeling
- MUSCLE (Multiscale Coupling Library and Environment)
- MDA Y-structure
-UML/MARTE

2.2 Multiscale Modeling

The authors of (Borgdorff, J. et al, 2013, b) defined Multiscale Modeling as: “A way to
gain knowledge about complex systems by explicitly modeling the interaction between
phenomena on different scales”. Before going deep, some terms related to the multiscale
modeling should to be defined, these definitions (Borgdorff, J. et al, 2013, a) are:

Definition 1: a scale is an order of magnitude along a coordinate. For natural processes,

however, at least temporal and spatial scales are considered.
Definition 2: a phenomenon is a finite amount of data describing a natural process on a
given set of scales.
Definition 3: a submodel is a component model that describes only one scale of the system.
Definition 4: the e-science is applying computer technology to the undertaking of modern
scientific investigations and experiments and accessibility of all materials generated
through the scientific process. These may include data modeling and analysis.

The reason for using multiscale models is simply that there is no hope to
computationally track complex natural processes at their finest spatio-temporal scales.
Even with the ongoing (exponential) growth in computational power. Multiscale Modelling
and Simulation should address:
-What is the information that needs to be transferred from one model or scale to another?
- What (physical) principles must be satisfied during the transfer of information?
-What is the optimal way to achieve such transfer of information?
- How to quantify variability of physical parameters and how to account for it to ensure
design robustness?
 11

2.2.1 Scale Separation Map (SSM)

A way to assess the scales of the phenomena involved in a multiscale phenomenon is

to draw its scale separation map (SSM). Figure 2.1(Borgdorff, J. et al, 2013, a) shows an
example SSM of a classical macro–micro model, showing on the axes spatial and temporal
scale, with granularity Δx, Δt; and total size Ωx, Ωt respectively. In (a) the multiscale
model without separating the scales; in (b) macro single scale model A and micro single
scale model B.

Figure 2.1: An example SSM of a classical macro–micro model

Figure 2.2 (Borgdorff, J., 2012) below shows a multiscale model with two submodels:
Macro-model and Micro-model.

Figure 2.2: Multiscale model with two submodels

Figure 2.2 shows that:

- Micro is called at each iteration of Macro.
- Macro sends density to Micro.
- Macro receives viscosity from Micro.
 11

2.2.2 Generic Submodel Execution Loop (SEL)

The Submodel Execution Loop describes the submodel flow. Figure 2.3 (Hoekstra, A.
G., 2010) shows a generic SEL for a submodel, in which finit is for initialization, S is for
one iteration of the Solver, B is to specify the boundaries, Oi is for intermediate observation
and Of is for final observation.

Figure 2.3: SEL of a submodel

2.3 Multiscale Coupling Library and Environment (MUSCLE)

MUSCLE is a modeling and simulation framework. It treats single scale models as

separate components and facilitates their coupling according to a given topology. These
single scale models are independent from each other in the sense that they only rely on
messages (observations) they send or receive at specific ports. Figure 2.2 (Borgdorff, J.,
2014) shows an example of the MUSCLE runtime environment.
 12

Figure 2.4: an example of the MUSCLE runtime environment.

Figure 2.4 also shows the core elements of MUSCLE, these elements have been
described in the next section.

2.3.1 Architecture of MUSCLE

This section is going to illustrate the architecture of MUSCLE in terms of its core
elements and concepts, these elements are:

1-Multiscale model: is a set of coupled single scale models.

2- Single scale model: is the result of decomposing a problem into a set of single scale
models that exchange information across the scales. It starts by decomposing a
phenomenon into multiple single scale phenomena using a scale separation map as a visual
aid. Based on these single scale phenomena, single scale models are created; ideally, these
single scale models are independent and rely only on new messages at specific input ports,
while sending messages with observations of their state at output ports. Each single scale
model is handled as an independent component owning its simulation time, spatial and
temporal scales. It synchronizes with other single scale models by exchanging messages
 13

carrying time points. Moreover, the code of the e-science models is encapsulated in the
single scale models.

3- MUSCLE controllers: controllers are responsible for communicating with other

instances and with the Simulation Manager. Controllers encapsulated sequences of actions
which execute concurrently (sequence of calls to a set of specific operators).

4- MUSCLE Conduits: special kinds of communication channels are used to couple single
scale models through their input/output ports; a multiscale model is formed as a result of
the coupling process. MUSCLE provides additional specific computational elements like
filters and mappers that are kinds of smart conduits. Furthermore, there are two types of
conduits: The so-called Plain Conduit which transports data between controllers without
any transformation, and the so-called Scale Bridge Conduit which transform the data along
their conveying through the conduit. MUSCLE provides two specific scale bridge conduits:
Filter and Mapper. The last one plays also the role of a Simulation Controller.

5- Ports: MUSCLE distinguishes two types of ports, input and output. Input ports are
capable of receiving messages, while the output ports can send messages.

6- Observations: data passed between single scale models or messages contain data, for
instance an observation of a submodel state, the time point of the event it is associated with,
and the time point of the next message that will be sent over the conduit. Single scale
models are independent from each other in the sense that they only rely on messages
(observations) they send or receive at specific ports.

7- Filters: are specific computational elements that are kinds of smart conduits. Data
exchanged between single scale models can be modified in transit because data expected by
a single scale model does not automatically match the observation of the other single scale
model in this case filters change data in a single conduit to assure the correctness of
communications. Filters are allowed to have a state, so they can do time averaging by
aggregating data coming in.

8- Mappers: are specific computational elements that are kinds of smart conduits. Mappers
may combine data from multiple sources or extract multiple data from one observation.
Mappers can be used to optimize a coupling (do not repeat twice the same calculation,
build complex coupling). MUSCLE proposes two types of mappers: fan-in and fan-out.
 14

9- Simulation Manager: each MUSCLE simulation has a single Simulation Manager. The
Simulation Manager is needed for keeping the track of which instances have been started
and what their location is.

10- Local Managers: each MUSCLE simulation has one or more Local Managers. The
Local Manager starts the instances (such as controllers, single scale models, etc.) that were
assigned to it in separate threads and listens for incoming connections. Instances will start
computation immediately but they will block and become idle as soon as they try to receive
a message that has not yet been sent, or try to send a message to an instance that has not
been started.

11- Submodel: is a well-defined process which allows a distributed execution.

12- Submodel Execution Loop (SEL): is the description of submodel flow, or in other
words it is the dynamic behaviour of MUSCLE Controllers (a cycle of single scale
simulation steps).

2.3.2 Using MUSCLE for Modeling (Coral Growth as example)

This section will explain a modeling example of coral growth (Hoekstra, A. G., 2010)
Figure 2.5 shows the simulated coral growth and its three subsystems in SSM.

Figure 2.5: Simulated coral growth and its three subsystems

 15

In the simulated coral growth, the growth dictated by influx of nutrients at coral surface
and the nutrients are transported by water flow around the coral. All the three subsystems
are operating on the same length scale of coral. Figure 2.6 shows the Coral growth
subsystems as submodels.

Figure 2.6: Coral growth subsystems as submodels

 16

2.4 MDA Y-structure

UML-MARTE system models are divided into three sub-models:

1- Platform Independent Model (PIM), which describes the views of the system (data,
functional, application, communication, etc.).
2- Platform Description Model (PDM), which represents the target platform used to
implement the application.
3- Platform Specific Model (PSM), which performs the mapping of the PIM on the PDM.

2.5 UML/MARTE

MARTE is UML profile that has been designed as a domain specific modeling
language intended for model-based design and analysis. MARTE provides support for
specification, design and verification/validation stages.

The Software Resource Modeling (SRM) profile (OMG, 2011) is a sub-part of the
General Resource Modeling (GRM). SRM is used for describing the application
programming interfaces of software multi-tasking execution supports. There are some
similarities between the domain model of the SRM and the domain model of the resource
modeling elements in the DMMS, in other words; both SRM and DMMS are using almost
similar resource types. Figure 2.7 (OMG, 2011) shows the structure of the SRM modeling
framework. SRM has four sub-packages: the SW_ResourceCore, SW_Concurrency,
SW_Interaction and SW_Brokering. Each sub-package contains a set of stereotypes that
will be used to model the core elements of MUSCLE.

A UML stereotype (OMG, 2011) is a profile class which defines how an

existing metaclass may be extended as part of a profile. It enables the use of a platform or
domain specific terminology or notation in place of, or in addition to, the ones used for the
extended metaclass. A stereotype cannot be used by itself, but must always be used with
one of the metaclasses it extends.
 17

A stereotype uses the same notation as a class, with the keyword «stereotype» shown
before or above the name of the stereotype. Stereotype names should not clash with
keyword names for the extended model element.

Figure 2.7: Structure of the SRM modeling framework

Because stereotype is a class, it may have properties. Properties of a stereotype are

referred to as tag definitions. When a stereotype is applied to a model element, the values of
the properties are referred to as tagged values. Figure 2.8 (OMG, 2011) shows device
extended by server stereotype with tag definitions.

Figure 2.8: device extended by server stereotype

 18

Chapter Three:

LITERATURE REVIEW
 19

3.1 Introduction

Multiscale modelling and simulation field is receiving a wide interest from

mathematics, biology, physics, engineering, and many other disciplines.
A number of research papers on multiscale modeling exist. As one of the
methodological papers; authors (Borgdorff, J. et al, 2013, a) proposed foundations for
multiscale modeling and distributed multiscale computing. The architecture is analyzed
using directed acyclic task graphs, facilitating validity checking, scheduling distributed
computing resources, estimating computational costs. Furthermore, the middleware
framework that can help in executing multiscale models is the Multiscale Coupling Library
and Environment (MUSCLE) (Borgdorff, J., 2012). By studying such research papers we
can have an overview of the DMMS approach which will be compared to the research work.
On the other hand, many research papers on UML/MARTE exist, as one of these papers is:
“UML profile for Modeling and Analysis of RTES tutorial” (Frédéric, T. et al, 2008). This
chapter will present the most recent research works related to the thesis work and
comparing these research works to the thesis work.

3.2 UML/MARTE Methodology for Heterogeneous Systems design

This research work (Peñil, P., 2014) introduced the PHARAON specification which
is based on the UML/MARTE profile that intended to provide features for Real-Time and
Embedded Systems. PHARAON defines a profile that extends the UML/MARTE profile in
order to offer some features for the specific description of the goals of the project. In fact
this work aimed to use the UML/MARTE for Real-Time and Embedded Systems (RTES),
on the other hand the research work will use the UML/MARTE for Distributed Multiscale
Modeling Systems (DMMS).
 21

3.3 Extending UML/MARTE-GRM for Integrating Tasks Migrations in Class

Diagrams

The authors of (Magdich, A. et al, 2014) claimed that the GRM does not allow
designers to specify data to be used neither in half-partitioned nor in global scheduling
approaches, also it does not support the modeling of task migration concept. In order to
solve this issue, the authors also proposed an extension of MARTE/GRM sub-profile to
consider the modeling of information needed for the half-partitioned and global scheduling
step. On the other hand, the research work will reuse the SRM in the context of DMMS
domain.

3.4 A Generic Framework for Multi-Disciplinary Environmental Modeling

In (Hennicker, R. et al, 2010), the authors proposed an integration of UML with

concrete simulation models of particular disciplines in the requirement and design phases
and they present a generic framework which is applicable to any kind of model which
simulates spatially distributed environmental processes. The research work will use the
UML/MARTE only for the requirement phase.

3.5 UML profile for Modeling and Analysis of RTES (MARTE)

The proposed approach is based on the tutorial presented in (Frédéric, T. et al, 2008)
in which the authors outlined the Software Resource Model (SRM) as a UML profile for
modeling and analysis of real-time and embedded systems.

The authors defined the SRM as: “a UML profile to describe API of software
execution supports”, also they outlined the design steps and the typical cases in which the
SRM could be used. Moreover, the tutorial takes the OSEK/VDX (Open systems and the
corresponding interfaces for automotive electronics / Vehicle Distributed eXecutive) as a
case study to show the use of SRM for RTOS API modeling, some examples of API model
were clearly outlined in the robotic case study.
 21

3.6 Conclusion

The previous sections outlined some methods for extending the UML/MARTE-GRM
profile and some methods for using the SRM for RTES; but in fact, our work is intended to
use the SRM sub-profile for the DMMS and the MUSCLE is going to be our target domain.

The approach presented in this research work is based on the related work presented
in section 3.5.
 22

Chapter Four:

METHODOLOGY AND CONTRIBUTION

 23

4.1 Introduction

Modeling MUSCLE simulation platform using MARTE has two approaches according
to (Maouche, M., Bettaz, M., 2016, c); the first approach might be accomplished by
creating MARTE models for all MUSCLE core concepts. While the second approach can
be done by extending the MARTE profile in order to support the core concepts related to
multiscale modeling and simulation frameworks, but after investigation conducted on the
MUSCLE and SRM sub-profile we found a way for modeling MUSCLE simulation
platform using MARTE. Figure 4.1 presents the two ways of modeling MUSCLE, either by
using the existing SRM as it is, or by extending it and make a Specific Software Resource
Model (SSRM) intended for modeling the MUSCLE simulation platform. This thesis work
presents the use of the first approach, which is using the existing SRM as it is. The next
section will present the investigation results and the findings that lead to the modeling
approach.

Figure 4.1: ways of modeling MUSCLE using MARTE

 24

4.2 Software Resource Model (SRM) sub-profile for DMMS

This section explains and answers the question: why to choose the SRM for modeling
the MUSCLE?

In order to answer the previous question, an investigation conducted on the MUSCLE

and SRM sub-profile, the results below have been found:

1) Reference (OMG, 2011):

“The SRM profile is not a new multi-tasking API standard. It provides modeling
artifacts to describe such API. Moreover, even if this clause focuses on RTOS APIs, it is
useful not only to describe such support but also to depict specific multi-tasking libraries
and more generally multi-tasking framework API (e.g., RTE middleware and RTE virtual
machine)”.

2) Reference (Belgacem, M. B. et al, 2013):

“On top of MUSCLE, the QoSCosGrid middleware is used (QCG) for the submission.
It supports an advance reservation mechanism, essential to block several computing
resources for the same period of times. Job submission can be made through the command
line or through the GridSpace web based environment”.

3) Reference (Falcone, J. L. et al, 2010):

“Together with the theoretical concepts, we have also developed coupling software
called MUSCLE, which provides the glue to run simulations with these interacting
submodels”.

4) Reference (Borgdorff, J. et al, 2013, b):

“MUSCLE is integrated with the QosCosGrid middleware stack. This stack provides
automation of the process of submitting cross-cluster simulations by: collocating resources
on multiple sites (using the Advance Reservation mechanism)”.
“Likewise, runtime settings such as library paths are now recognized as environment
variables by MUSCLE 2, to make it more customizable for middleware”.
 25

As a result, MUSCLE might be considered as a type of middleware (Service-specific

middleware) (Mzid, R., Abid, M., 2016), and which means “MUSCLE simulation
platform” is a system (middleware or software glue) that is built to support an execution
process and not execution platform. Furthermore, the SRM sub-profile can be used to
model OS as well as modeling specific RTE libraries or Middleware. That means it is
possible to model MUSCLE using MARTE. The thesis work will adopt reusing the existing
SRM for the context of the simulation domain which seems logically acceptable.

4.3 Outline of the SRM domain view

The whole domain model has been built on the basis of a detailed analysis of the
MUSCLE standards ((Borgdorff, J. et al, 2013, a), (Borgdorff, J. et al, 2014) and
(Borgdorff, J., 2012)), and Multiscale modeling standards (e.g. (Borgdorff, J., 2014) and
(Kroc, J. et al, 2010)). As a rule, Multiscale modeling concepts relate to:
- Concurrent execution (i.e. parallel execution) contexts such as each individual
MUSCLE local managers may concurrently support more than one controller, MUSCLE
controllers are seen as concurrent schedulable resources.

- Interactions between concurrent contexts both for communication and synchronization

purposes, such as Conduits as communication resource.

- Hardware and software resource brokering concepts, such as memory management

(shared memory) and drivers.

The domain model is organized in four packages (OMG, 2011):

1. SW_ResourceCore: intended to provide the basic software resource concepts.

2. SW_Concurrency: provides classification of concurrent execution contexts.

3. SW_Interaction: for sorting communication and synchronization resources.

4. SW_Brokering: refers to hardware and software resources management.

 26

The domain view has been implemented as a UML 2.0 profile. Each MUSCLE concept
will be modeled by a relevant SRM stereotype. Figure 4.2 (OMG, 2011) below provides an
overview of the profile architecture.

Figure 4.2: SRM profile overview

4.4 A three-step modeling methodology

To begin with, figure 4.3 shows the methodological processes and steps that the thesis
work proposes for reusing the SRM profile in modeling an instance of our target domain
(MUSCLE is an instance from this domain). The methodology has three main steps or
stages. The purpose of the first stage is to define all concepts required to cover a specific
domain. The resulted output of this stage is the domain model of the SRM sub-profile, it is
considered as a specification of the domain-specific language. The second stage selects a
relevant subset of the existing SRM stereotypes that can be used to model the abstract
concepts identified in step1. The last stage is to implement the specification in terms of
UML extensions. In other words proposing the necessary adaptations of these stereotypes
(adding new attributes for instance) and / or necessary refinements of some relevant SRM
stereotypes.
 27

Figure 4.3: Methodology for reusing the SRM profile in modeling the target domain (MUSCLE)

4.4.1 Step1: identifying the core concepts of MUSCLE:

This section applies step1 of the methodology, in which the core concepts of
MUSCLE are identified. The identification process came after a deep study of the most
recent DMMS methodological research papers (Borgdorff, J. et al, 2013, a) and (Borgdorff,
J. et al, 2013, b). Figure 4.4 shows the core concepts and elements of MUSCLE.
 28

Figure 4.4: MUSCLE core concepts

The MUSCLE core elements mentioned above (single scale models, controllers,
conduits, ports, filters, mappers, simulation managers, and local managers) are going to be
modelled by using MARTE resources. MUSCLE uses shared memory for models started in
the same command and TCP/IP for multiple commands that means memory management is
needed.

4.4.2 Step2: Selecting a relevant subset of SRM stereotypes that can be used to model
the abstract concepts identified in step1

As it has been previously mentioned, the research work will adopt reusing the SRM
sub-profile in the context of simulation domain. So, this section applies the step2 of the
proposed methodology in which the suitable subset of SRM stereotypes are selected to be
used in modeling the MUSCLE core elements as follows:
 29

1- SW_Concurrency:

Classifies concurrent execution contexts and can be used to model the following
MUSCLE concepts:

1.1 MUSCLE Controller

Encapsulated sequences of actions which execute concurrently (sequence of calls to a set of

specific operators).

1.2 Single Scale Model

Provides single scale model that synchronizes with other single scale models by
exchanging messages carrying time points. These single scale models encapsulate the code
of e-science models. Also they simulated concurrently and encapsulated into Controllers.

1.3 Submodel

It is a well-defined process which allows a distributed execution. The (SEL) is the

description of submodel flow.

2- SW_Interaction:

Sorts communications and synchronization resources and can be used to model the
following MUSCLE concepts:

2.1 Ports

Communication resource used to exchange messages (Used by controllers to exchange

simulation data).

2.2 MUSCLE Conduits

Communication resource used by the simulation controllers to exchange the simulation data
through their input and output ports. Conduits have two types:

1-Plain Conduit transports data between controllers without any transformation.

2-Scale Bridge Conduit transforms the data along their conveying through the conduit.
 31

2.3 Filters

Computational elements that are kinds of smart conduits. Filters change data in a single
conduit to assure the correctness of communications.

2.4 Mappers

Computational elements that are kinds of smart conduits. Mappers may combine data from
multiple sources or extract multiple data from one observation.

3- SW_Brokering:

Due to the fact that MUSCLE uses shared memory for models started in the same
command and TCP/IP for multiple commands that means a memory management is needed,
also the fact that a simple MUSCLE simulation might be done over two machines or hosts
(M1 and M2 or H1 and H2) so, a device broker has to be used.

SW_Brokering refers to hardware and software resources management; some brokering

resources might be used such as:
A) MemoryBroker:

Resource that manages memory allocation, memory protection and Memory access.

B) DeviceBroker:

Such as a driver, it interfaces peripheral devices to the software execution support. By

initializing that resource, user makes devices accessible for software.

4.4.3 Step3: SRM stereotypes adaptations, refinements and UML extensions

This step proposes the necessary adaptations of the stereotypes (adding new attributes
for instance) and do the necessary refinement of some relevant SRM stereotypes. Figure 4.5
shows an overview of the UML extensions for SRM.
 31

Figure 4.5: UML extensions for SRM

MUSCLE core concepts, their properties and the provided services (grouped
according to their relevant subsets of SRM stereotypes) are shown in table 4.1 and table 4.2.

Table 4.1: MUSCLE Concepts with SW_Concurrency

SRM::SW_Concurrency
MUSCLE Concept Properties Services Constraints

SSModelID: String
Single scale model TimeScale: String Coupling()
SpaceScale: String
SimulationTime: Duration
TimeStep: INT
getScale()
ControllerID: String
Controller addPortals()
Period: Duration
execute()

SubmodelID: String start()

runSEL() CouplingTemplateKind:
Priority: INT
sleep() Interact
Period: Duration
Submodel yield() Call
Suspended: Boolean
resume() Release
Stopped: Boolean
suspend() Dispatch
CouplingTemplate: CouplingTemplateKind
stop()
 32

Table 4.2: MUSCLE Concepts with SW_Interaction

SRM::SW_Interaction
MUSCLE Concept Properties Services Constraints

MessageResourceKind:
ConduitID: String MessageQueue
read() Pipe
Conduit IsFixed: Boolean
write() Blackboard
Mechanism: MessageResourceKind
Undef
Other

FlowDirectionKind:
PortID: String In_portReceive()
Port In
Direction: FlowDirectionKind Out_portSend() Out
MsgSize: DataSize
Inout

MessageResourceKind:
MessageQueue
FilterID: String WriteToConduit() Pipe
IsFixed: Boolean ReadFromConduit() Blackboard
Filter FilterType: MessageResourceKind Undef
Interplate()
Datatype_from: datatype Rescale() Other :
Datatype_to: datatype Datatype Converter
Scale reduction
Interpolation
MessageResourceKind:
MessageQueue
MapperID: String Pipe
IsFixed: Boolean Combine_data() Blackboard
Mapper
MapperType: MessageResourceKind Extract_data() Undef
Other :
Fan-in
Fan-out

4.5 Modeling MUSCLE core elements

This section presents how each core element of MUSCLE will be modelled using the
relevant SRM stereotype. The detailed steps explained (OMG, 2011) only for modelling the
first concept (Submodel), although we followed the same steps for modelling all core
concepts of MUSCLE.

1-Model of a MUSCLE Submodel with <<SwSchedulableResource>> :

Step 1: Define a UML model for MUSCLE::Submodel

-Add model library applying the SRM profile

-Add a class and defines its features (properties and operations)

 33

Figure 4.6 shows the implementation of step 1.

Figure 4.6: Modeling a MUSCLE Submodel with SRM step1

Step 2: Apply stereotype «SwSchedulableResource»

Submodel is an instance of the stereotype «SwSchedulableResource» that means all the

properties and operations of submodel should be compatible with the property elements and
services existed in the SwSchedulableResource stereotype. After referring to (OMG, 2011)
manual and studying the SRM stereotypes, it has been found that the submodel is
compatible. This step has been applied on all the MUSCLE core elements before start
modeling. Figure 4.7 (OMG, 2011) shows the SW_Concurrency profile which the
SwSchedulableResource stereotype refer to. Figure 4.8 shows the result of implementing
step 2 (Apply stereotype «SwSchedulableResource»).
 34

Figure 4.7: The SW_Concurrency profile overview

By referring to the figures 4.7 and 4.8, we conclude that the submodel properties are
compatible with SwSchedulableResource stereotype property elements as follows:

1) (SubmodelID) is compatible with (IdenfierElements)

2) (Priority) is compatible with (PriorityElements)
3) (Period) is compatible with (PeriodElements)
 35

Also, by referring to the figures 4.7 and 4.8, we conclude that the submodel operations
are compatible with SwSchedulableResource stereotype services as follows:

1) (start()) is compatible with (CreateServices)

2) (runSEL()) is compatible with (activateServices)
3) (sleep()) is compatible with (delayServices)
4) (yield()) is compatible with (yieldServices)
5) (resume()) is compatible with (resumeServices)
6) (suspend()) is compatible with (suspendServices)
7) (stop()) is compatible with (terminateServices)

Figure 4.8: Modeling a MUSCLE Submodel with SRM step2

 36

Step 3: Set its tagged values properly

Figure 4.9 below shows the result of implementing step 3.

Figure 4.9: Modeling a MUSCLE Submodel with SRM step3

 37

2-Model of a MUSCLE Single Scale Model with <<SwSchedulableResource>> :

A real phenomenon is decomposed into a set of coupled submodels exchanging data

across different scales. Submodel (Single scale model) is a model of a single scale process.
Submodels are governed by a Submodel Execution Loop (SEL) and encapsulated into
Controllers. Moreover, the author of (Belgacem, M. B., 2015) clarified that a submodel is a
program that resolves a physical process at a given scale.

Single scale models encapsulate the code of e-science models and simulated
concurrently. Figure 4.10 below shows how Single scale model has been modeled with
SRM.

Figure 4.10: Modeling Single scale model with SRM

 38

3- Model of a MUSCLE Controller with <<SwSchedulableResource>> :

In MUSCLE (Borgdorff, J., 2012), controller is the implementation of a submodel or a

mapper and it is unaware of other submodels. In other words we may say that submodels
and mappers extend controller.

Due to the fact that each individual MUSCLE local manager may concurrently support
more than one controller (Borgdorff, J. et al, 2014), MUSCLE controllers can be seen as
concurrent schedulable resources which are a kind of resources already defined in the SRM
(Maouche, M., Bettaz, M., 2016, b), Figure 4.11 shows how to model the Controller with
SRM.

In MUSCLE (Belgacem, M. B., 2015), a submodel has input and output ports that
intended to send and receive data in the form of messages. For example, the Oi
(intermediate observation) is an example of data sent out using an output port. The message
is transported through conduits. In SEL (Submodel Execution Loop; which is the behaviour
of the MUSCLE controllers), each operator can be associated to an input or output port in a
submodel; for instance, the operators Oi and Of (final observation) can use output ports to
send data. On the other hand, the operators Finit (initialization SEL), S (solving step) and B
(boundary conditions) can use input ports to receive data. Therefore, a conduit between an
input and output ports is just a coupling between two SEL operators of two submodels.
 39

Figure 4.11: Modeling Controller with SRM

4- Model of a MUSCLE Conduit with <<MessageComResource>> :

A conduit is a unidirectional connection between an output port and an input port and
intended for transferring data in the form of messages (Borgdorff, J. et al, 2013, a).
Moreover, conduit is an implementation of coupling (coupling input and output ports)
forming what is known as multiscale model.

Conduits are composed of three parts (Kroc, J. et al, 2010):

1- The entrance (incoming buffer).

2- The exit (outgoing buffer).

3- Zero or several data filters between different scales (data filters are optional which are
used to perform interpolation, restriction and discretization, etc.). A filter is applied only on
a conduit between two submodels.
 41

In MUSCLE there are two types of conduits:

1-Plain Conduit: transports data between controllers without any transformation.
2-Scale Bridge Conduit: transforms the data along their conveying through the conduit.

Figure 4.12 shows modeling a Conduit with SRM.

Figure 4.12: Modeling Conduit with SRM

5- Model of a MUSCLE Port with <<MessageComResource>> :

MUSCLE Port is a communication resource used by controllers to exchange messages

(simulation data). In a submodel, each operator can be associated to an input or output port.
Therefore, submodels may define ports based on their SEL operator. In other words, output
ports may be defined for operators Oi and Of and input ports for Finit, S and B (Borgdorff, J.,
2014). Ports have two main methods for sending and receiving messages, In_PortReceive()
and Out_PortSend(). Figure 4.13 shows the modeling of MUSCLE Port with SRM.
 41

Figure 4.13: Modeling Port with SRM

6- Model of a MUSCLE Filter with <<MessageComResource>> :

MUSCLE Filter is a specific computational element which is responsible for

converting data or altering the flow of data of a conduit. Filter is applied to messages that
are being transferred over a conduit to ensure that both submodels are handling the data in a
way most convenient to them and still communicate correctly. In (Borgdorff, J., 2014), the
authors clarified that: “conduit filters should not model phenomena, but rather do a
physically correct data transformation that enables each submodel to reason about its own
data”. Figure 4.14 shows the modeling of MUSCLE Filter with SRM.
 42

Figure 4.14: Modeling Filter with SRM

7- Model of a MUSCLE Mapper with <<MessageComResource>> :

MUSCLE Mapper is a specific computational element that is responsible for

combining data from multiple sources or extract multiple data from one observation
(Borgdorff, J. et al, 2014). The author of (Belgacem, M. B., 2015) defined Mapper as: “a
component that receives data from one or more submodels, performs a computation
reflecting the nature of the coupling, and sends updated information to the corresponding
recipient submodels (many-to-many relation)”.

The reason behind using the Fan-in or Fan-out Mappers is that the Filter applies to
only one conduit, which means it cannot do a data transformation for which multiple
sources are necessary, also it cannot distribute the transformed data to multiple submodels.
 43

Furthermore, in order to increase the separation between the model and the runtime
environment each mapper or submodel has its own instance controller that will do the
actual communication with other parts of the simulation (Borgdorff, J., 2014). Figure 4.15
shows the modeling of MUSCLE Mapper with SRM.

Figure 4.15: Modeling Mapper with SRM

 44

4.6 MDA Y-structure and MUSCLE core elements

MDE (Model-Driven Engineering) (Lelionnais, C. et al, 2012) is based on an

architecture known as Model Driven Architecture (MDA) which involves a design process
where a Platform- Independent Model (PIM) (description of the application without
considering the platform) is transformed into a Platform Specific Model (PSM) (description
of the application deployed on the platform), according to a Platform Description Model
(PDM) (description of the platform). See figure 4.16 (Völter, M. et al, 2013).

Figure 4.16: MDA principle

Figure 4.17 shows the previously mentioned core elements of MUSCLE as Y-

structure components.
 45

Figure 4.17: MUSCLE core elements as MDA Y-structure

 46

4.7 Conclusion

The previous sections show adopting of the UML/MARTE through its SRM and
applying it to the DMMS (MUSCLE is the target domain). As a result, the proposed
software development methodology is applicable for some of MUSCLE core elements,
some other elements could not be modeled by SRM due to the incompatibility issues with
SRM stereotypes.
 47

Chapter Five:

EVALUATION
 48

5.1 Introduction

The research work has been evaluated with (Borgdorff, J. et al, 2014) in which the
authors present modeling MUSCLE with DMMS.

5.2 Evaluation

By comparing our work with what have been done in the DMMS (e-Science work)
the table 5.1 below summarizes the results and findings.

Table 5.1: Comparison between modeling MUSCLE with DMMS and with MDE (the proposed approach)

MUSCLE with DMMS MUSCLE with MDE

Criteria
(Code-based) (UML/MARTE)

Community domain E-science (DMMS) Software Engineering (MDE)

Traditional code-based Model-Driven Engineering (MDE)

Design practice
Engineering approaches

We cannot go directly from the

DMMS to CSP to formally verify
Ability to move to CSP
the properties of the system.
We can directly go from the
UML/MARTE to CSP to formally
verify the properties of the system.

Some of MUSCLE core elements have

been modeled successfully with SRM;
Modeling MUSCLE core All MUSCLE core elements have some other elements could not be
elements been modeled modeled by SRM due to the
incompatibility with SRM stereotypes.

As a result, the proposed software development methodology is applicable for some of

MUSCLE core elements, some other elements such as: Observations, Simulation Manager
and Local Manager could not be modeled by SRM due to the incompatibility issues with
SRM stereotypes. Due to the result, it has been concluded that using the second way of
modeling (extending the SRM) would be better for modeling all the core elements of
MUSCLE.
 49

Chapter Six:

CONCLUSION AND FUTURE WORK

 51

6.1 Conclusion

Multiscale computing has become increasingly popular recently in many disciplines.

This thesis work shows that the proposed software development methodology is applicable
for some of MUSCLE core elements, some other elements such as: Observations,
Simulation Manager and Local Manager could not be modeled by SRM due to the
incompatibility issues with SRM stereotypes. Due to the result, it has been concluded that
using the second way of modeling (extending the SRM) would be better for modeling all
the core elements of MUSCLE.

Our contribution highlighted the following:

1- Highlighting the advantages of modeling using model driven approaches.

2- Bridging the gap between the E-science and Software Engineering communities.

2- Using the SRM sub-profile for MUSCLE simulation platform Modeling

6.2 Future Work

As a future work, we are going to extend the existing SRM sub-profile and make it
specific for MUSCLE; the extended profile will be SSRM (Specific Software Resource
Model). And in terms of requirements, design and implementation the work might be
extended to cover the design phase by fully transforming UML/MARTE to CSP-OZ, and
also transforming the Multiscale Modeling Language (MML) to UML/MARTE.
 51

REFERENCES
 52

-Belgacem, M. B., Chopard, B., Borgdorff, J., Mamoński, M., Rycerz, K. and
Harezlak, D., (2013). Distributed multiscale computations using the MAPPER
framework. Procedia Computer Science, 18, 1106-1115.

-Belgacem, M. B., (2015). Distributed and multiscale computing for scientific applications ,
University of Geneva.

-Borgdorff, J., (2012). MUSCLE tutorial. Retrieved from http://www.mapper-project.eu

-Borgdorff, J., Falcone, J. L., Lorenz, E., Bona-Casas, C., Chopard, B. and Hoekstra,
A. G., (2013, a). Foundations of distributed multiscale computing: Formalization,
specification, and analysis. Journal of Parallel and Distributed Computing, 73(4), 465-483.

-Borgdorff, J., Mamonski, M., Bosak, B., Groen, D., Belgacem, M. B., Kurowski, K.,
and Hoekstra, A. G., (2013, b). Multiscale computing with the multiscale modeling
library and runtime environment. Procedia Computer Science, 18, 1097-1105.

-Borgdorff, J., (2014). Distributed multiscale computing. University of Amsterdam.

-Borgdorff, J., Mamonski, M., Bosak, B., Kurowski, K., Belgacem, M. B., Chopard, B.,
Groen, D., Coveney, P.V. and Hoekstra, A. G., (2014). Distributed multiscale computing
with MUSCLE 2, the Multiscale Coupling Library and Environment. Journal of
Computational Science, 5(5), 719-731.

-Falcone, J. L., Chopard, B., and Hoekstra, A., (2010). MML: towards a multiscale
modeling language. Procedia Computer Science, 1(1), 819-826.

-Frédéric T., Sébastien G., and Chokri M., (2008). UML Profile for Modeling and
Analysis of Real-time and Embedded Systems (MARTE) Tutorial, 1-39.

-Gherbi, T., Meslati, D., and Borne, I., (2009). MDE between Promises and Challenges.
In Computer Modelling and Simulation, 11th International Conference. IEEE, 152-155.

-Hennicker, R., Bauer, S. S., Janisch, S., and Ludwig, M., (2010). A Generic Framework
for Multi-disciplinary Environmental Modelling. International Environmental Modelling
and Software Society.
 53

-Hoekstra, A. G., (2010). MAPPER project website. http://www.mapper-project.eu

- Kroc, J., Sloot, P. M., and Hoekstra, A. G., (2010). Simulating Complex Systems by
Cellular Automata. Springer, 1-393.

- Lelionnais, C., Brun, M., Delatour, J., Roux, O. H., and Seidner, C., (2012). Formal
Behavioral Modeling of Real-Time Operating Systems. In The 14th International
Conference on Enterprise Information Systems (ICEIS (2) 2012).

-Magdich, A., Kacem, Y. H., and Mahfoudhi, A., (2014). Extending uml/marte-grm for
integrating tasks migrations in class diagrams. In Software Engineering Research,
Management and Applications . Springer, 73-84.

-Maouche, M., Bettaz, M., (2016, a). Towards a UML/MARTE CSP-OZ Based Software
Development Methodology. IFIP WG1.3 Workshop, Netherlands.

-Maouche, M., Bettaz, M., (2016, b). Towards a Software Engineering Approach to Multi-
Scale Modeling and Simulation. International Journal of Software Engineering and Its
Applications, 10(11), 205-218.

-Maouche, M., Bettaz, M., (2016, c). CSP-OZ: Semantics, Tools and Applications.
Technical report. Philadelphia University.

-Mzid, R., Abid, M., (2016). UML-based reconfigurable middleware for design-level
timing verification in model-based approach. In Design and Test Symposium (IDT). IEEE,
181-186.

-OMG, (2011). UML Profile for MARTE: Modeling and Analysis of Real-Time
Embedded Systems. Retrieved from http://www.omg.org/spec/MARTE/1.1

-Peñil, P., (2014). UML/MARTE Methodology for Heterogeneous System Design.

Microelectronics Engineering Group. University of Cantabria.

-Selic, B., Gérard, S., (2013). Modeling and Analysis of Real-Time and Embedded
Systems with UML and MARTE: Developing Cyber-Physical Systems. Elsevier.
 54

-Topçu, O., Durak, U., Oğuztüzün, H., and Yilmaz, L., (2016). Model Driven
Engineering. Distributed Simulation. Springer, 23-38.

-Völter, M., Stahl, T., Bettin, J., Haase, A., and Helsen, S., (2013). Model-driven
Software Development: Technology, Engineering, Management. John Wiley and Sons.
 ‫‪55‬‬

‫استخذام الولف الفشع قبلت الوصذس الجشهج ف ًوزجخ هٌصخ هحبكبح ثيئخ وهكتجخ اقتشاى هتعذد الٌطبقبد‬

‫الولخض‬
‫ٕزٓ االغشٗزت تقتشذ ٍْٖد‪ٞ‬ت ىيتط٘‪ٝ‬ش ٗاىت‪ ٜ‬تٖذف إى‪ ٚ‬اػتَاد ‪ ٍِ UML/MARTE‬خاله ‪ SRM‬ز‪ٞ‬ث س‪ٞ‬تٌ ٍذ‬
‫اىدس٘س ٍا ب‪ٍ ِٞ‬دتَغ ْٕذست اىبشٍد‪ٞ‬اث ٍٗا ‪ٝ‬سَ‪ ٚ‬بـَدتَغ ‪ . e-science‬ف‪ ٜ‬اىسْ٘اث األخ‪ٞ‬شة الزظْا اُ ٍَاسساث اىتصَ‪ٌٞ‬‬
‫تتسشك ٍِ اىْٖذست اىقائَت ػي‪ ٚ‬اىتؼي‪َٞ‬اث اىبشٍد‪ٞ‬ت اىتقي‪ٞ‬ذ‪ٝ‬ت اى‪ ٚ‬اىْٖذست اىقائَت ػي‪َّ ٚ‬زخت اىبشٍد‪ٞ‬اث ‪.MDE‬‬

‫ف‪َٝ ،UML ٜ‬نِ تؼش‪ٝ‬ف ٍيف تؼش‪ٝ‬ف ىتخص‪ٞ‬ص ػْاصش اىَْ٘رج اىق‪ٞ‬اس‪ ٜ‬ألغشاض ٍسذدة‪ .‬اظافت اى‪ ٚ‬رىل فاُ ىيَيف اىفشػ‪ٜ‬‬
‫أ‪ٝ‬عا ص٘سة َّط‪ٞ‬ت ‪ٗ UML‬ازذة أٗ أمثش تستخذً ٍِ أخو تَ‪ٞٞ‬ض ّ٘ع مََثو ىْ٘ع ٍؼ‪ ٍِ ِٞ‬اىنائِ ‪.‬ف‪ٍ ٜ‬داه أّظَت اىضٍِ اىسق‪ٞ‬ق‪ٜ‬‬
‫اىعَْ‪ٞ‬ت (‪ٝ ، )RTES‬تٌ استخذاً ‪.UML/MARTE‬‬

‫ف‪ ٜ‬اىـ ‪ْٕ UML/MARTE‬اك ٍيف فشػ‪ٗ GRM ٜ‬اىز‪ ٛ‬بذٗسٓ ‪ٝ‬قً٘ باىتضٗ‪ٝ‬ذ اىالصً ىيَفإ‪ ٌٞ‬اىَستخذٍت ف‪َّ ٜ‬زخت تطب‪ٞ‬قاث‬
‫أّظَت اىضٍِ اىسق‪ٞ‬ق‪ٕٗ ،ٜ‬زا اىَيف اىَزم٘س آّفا ‪ٝ‬س٘‪ ٛ‬ػي‪ٍ ٚ‬يف‪ ِٞ‬فشػ‪َٕ ِٞٞ‬ا‪ HRM ٗ SRM :‬اىيزاُ ‪ٝ‬ؤد‪ٝ‬اُ ػَو اه ‪.API‬‬
‫اه ‪ٍ ٕ٘ SRM‬يف فشػ‪ٝ UML ٍِ ٜ‬ستخذً ى٘صف ‪ API‬اىالصً ىتفؼ‪ٞ‬و اىبشّاٍح ٗا‪ٝ‬عا ‪ٝ‬ت‪ٞ‬ر ىيَستخذٍ‪ٗ ِٞ‬صف ‪ API‬اىالصً‬
‫ىَنتباث ‪ RTE‬اىَسذدة ٗاىت‪ ٜ‬تنُ٘ ٍ٘خ٘دة ف‪ٍ ٜ‬شزيت اىتصَ‪.ٌٞ‬‬

‫ٗمَسفض ىيَع‪ ٜ‬قذٍا ف‪ ٜ‬ػَي‪ٞ‬ت اىبسث ٗبؼذ دساست ػَ‪ٞ‬قت ػي‪ٍٗ e-science ٚ‬داه ْٕذست اىبشٍد‪ٞ‬اث‪ ،‬قذ تب‪ ِٞ‬ىْا أُ اىز‪ٝ ِٝ‬ؼَيُ٘‬
‫ف‪ ٜ‬اىَْزخت ف‪ ٜ‬مال ‪ٝ DMMS ٗ UML/MARTE‬ستخذٍُ٘ ّفس ٍْٖد‪ٞ‬اث اىَْزخت ‪.Y‬‬

‫باالظافت اى‪ٍ ٚ‬ا سبق‪ ،‬زق‪ٞ‬قت أُ اىَيف اىفشػ‪َٝ SRM ٜ‬نِ استخذأٍ ىَْزخت أّظَت اىتشغ‪ٞ‬و ٍثو ‪ٗ RTOS‬ا‪ٝ‬عا َّزخت ٍنتباث‬
‫اىبشاٍح‪-‬اىَت٘سطت راث اىضٍِ اىسق‪ٞ‬ق‪ . ٜ‬اىْتائح اىبسث‪ٞ‬ت اىسابقت ماُ ىٖا دٗس ف‪ ٜ‬اىتسف‪ٞ‬ض ىيََع‪ ٜ‬قذٍا ف‪ ٜ‬اػادة استخذاً اىَيف‬
‫اىفشػ‪ SRM ٜ‬ف‪ٍ ٜ‬داه اىَساماة‪.‬‬

‫ٗمْت‪ٞ‬دت ىٖزا اىبسث‪ ،‬فقذ تب‪ ِٞ‬أُ ٍْٖد‪ٞ‬ت تط٘‪ٝ‬ش اىبشٍد‪ٞ‬اث اىَقتشزت قذ أٍنِ تطب‪ٞ‬قٖا ػي‪ ٚ‬بؼط ػْاصش ‪ MUSCLE‬اىَشمض‪ٝ‬ت‪،‬‬
‫ٗبؼط اىؼْاصش اىَشمض‪ٝ‬ت األخش‪ ٙ‬ىٌ ‪ٝ‬تٌ اىتَنِ ٍِ َّزختٖا باستخذاً ‪ SRM‬بسبب ػذً ٍالئَتٖا ٍغ ‪SRM stereotypes‬‬
‫اىَت٘فشة‪ّ .‬ت‪ٞ‬دت ىزىل‪ ،‬فقذ خيص اى‪ ٚ‬أُ استخذاً اىطش‪ٝ‬قت اىثاّ‪ٞ‬ت ف‪ ٜ‬اىَْزخت (ت٘س‪ٞ‬غ ‪ ٜٕ )SRM‬األفعو ىَْزخت خَ‪ٞ‬غ ػْاصش‬
‫‪ MUSCLE‬اىَشمض‪ٝ‬ت‪.‬‬