2014 International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery

SPDML: Graphical Modeling Language for Executable Architecture of Systems

Jianpeng Hu1,2, Linpeng Huang2Bei Cao2,Xuling Chang2


College of Electrical and Electronic Engineering,
Shanghai University of Engineering Science, Shanghai, China

Dept. of Computer Science and Engineering
Shanghai Jiao Tong University, Shanghai, China
mr@sues.edu.cn, huang-lp@sjtu.edu.cncaobei.sjtu@gmail.com, changxl@sjtu.edu.cn

Abstract—Distributed Systems nowadays present System of executable architecting (e.g., specification, presentation,
Systems (SoS) characteristics such as large-scalability, simulation, and analysis of both the static structure and
composite systems consisting of software and hardware dynamic behavior of a system)[3]. Since UML has become
components and cooperative processes among independent the de facto standard modeling language for system design, a
systems. As architecture is a core element of Model Based lot of efforts have been made to make UML executable. The
System engineering (MBSE) for such systems, it is very foundational UML (fUML) standard [4] has been developed
important to validate functional requirements and evaluate to specify precise semantics for an executable subset of
Non Functional Requirements (NFR) of these systems through UML. And some venders that provide UML execution tools
an executable architecting process. To achieve this goal, we
have just started to adopt such semantics in their products,
propose a graphical modeling language based on Discrete
e.g. MagicDraw’s Cameo simulation toolkit [5] provides
Event System Specification (DEVS), the Scheduled Parallel
DEVS Modeling Language (SPDML). First we present an
extendable model execution framework based on fUML and
extension of the DEVS formalism, called the Scheduled State Chart XML (SCXML) standards. Even so, without a
Parallel DEVS formalism (SP-DEVS). Then an associated global view of the whole system behavior, simulations for
abstract syntax and a graphical notation for SPDML are those diagrams based on different semantic standards will
formally given. SPDML not only supports both textual and not be able to provide a complete system perspective for the
graphical modeling but also is suitable to be widely applied in system architect.
Modeling & Simulation (M&S) and executable architecting for At the same time, a lot of researches are made to
systems. To demonstrate the applicability of SPDML we’ll transform the UML models into other executable models.
discuss two examples as case study. Examples include automata, StateCharts, Petri Nets (PN) or
its variants, and Discrete Event System Specification (DEVS)
Keywords- MBSE; DEVS; Modeling & Simulation; System [6]. Automata and StateCharts, usually presented in
of Systems; Executable Architecture StateMachine Diagrams (SMD), build executable semantics
based on state transitions. Without a global view of
I. INTRODUCTION interactions and action sequences, using merely such
diagrams are incomplete for depicting interactive behavior.
Nowadays many distributed systems show system of
Conversely, PN transformed from Sequence Diagram or
systems (SoS) characteristics with cooperative processes
Activity Diagram can solve this problem. Unfortunately, the
involving multiple independent systems, the validation and
transformed PN including a lot of “places” and
evaluation can be very difficultAs noted in the Department “transactions” which gives an appearance completely
of Defense guidebook for Systems of Systems [1], different from the original system architecture, hence this
developing, evolving, and maintaining an SoS architecture kind of simulation can’t provide an intuitive observation of
was characterized as a core element of SoS Engineering. systems’ behavior and interactions between components. On
Architecting has become a distinct and essential life cycle the other hand, DEVS has been proven to be a universal
process for software engineering as well as systems formal mechanism to express a variety of discrete-event
engineering. For successful project managements, it is very system subclasses [7]. Therefore, DEVS which starts from
important to validate functional requirements and evaluate general system theory may be a better option as the target
Non-functional requirements (NFR) of these systems formalism to make the system architecture models
precisely in early design phase before implementation of the executable since it provides comprehensive and intuitive
systems. As simulation is a strongly recommended method to description of structure and behavior.
validate the requirements during the system development, In this paper, section 2 introduces the motivation of our
executable architectures are commonly defined to be work. Section 3 presents an extension of the DEVS
executable dynamic simulations that are automatically or formalism, called the Scheduled Parallel DEVS formalism
semi-automatically generated from architecture models or (SP-DEVS). Section 4 gives the abstract syntax and
products [2]. graphical notation of SPDML formally. Section 5
Executable architecting is not yet a mature field. No demonstrates the utility of SPDML in different ways with
single modeling tool currently available comes close to two examples. Section 6 discusses related work on
supporting the full range of capabilities needed for

978-1-4799-6236-5/14 $31.00 © 2014 IEEE 248

DOI 10.1109/CyberC.2014.52
executable architecting with DEVS. Section 7 concludes the an abstract syntax and a formally graphical notation of
paper and proposes directions for future research. SPDML. The ultimate goal of our work is to provide a
DEVS framework of M&S with consistency among
II. MOTIVATION formalism, modeling language and implementation, and a
DEVS is a formal specification for general discrete event comprehensive process from intuitive modeling to
dynamic systems. Starting from the classic DEVS proposed automatically generated simulation as well.
by Zeigler, the simulation community have proposed
different forms of DEVS for systems with different III. SCHEDULED PARALLEL DEVS )ORMALISM
characteristics. The later Parallel DEVS (P-DEVS) [6] Like P-DEVS, SP-DEVS models can also fall into two
removes constraints in the classic DEVS that originated with categories: atomic and coupled. The atomic model is the
the sequential operation of early computers and hindered the irreducible model definition that specifies the behavior for
exploitation of parallelism. any modeled entity. The coupled model represents the
Although DEVS has sound mathematical semantics for composition of two or more atomic and coupled models
modular and hierarchical modeling and good simulation connected by explicit couplings. An atomic model M and a
development environments such as DEVSim++ and coupled model N are defined by the following equations:
DEVSJAVA, a practical Modeling & Simulation (M&S)
engineer still experiences difficulties in applying the classic M = < IP, OP, X, S, Y, E, δport, δint, δext , δes, λ, ta > (1)
DEVS or P-DEVS formalism to a practical modeling of N = < IP, OP, X, Y, D, EIC, EOC, IC > (2)
complex systems, because DEVS is too mathematical for
practical use and modeling environments are not completely In an atomic model, S is the state space; IP, OP are the
graphical as they partially depend on programming set of input and output ports; X, Y are the set of
languages (like C++ and Java). What is still missing is a Inputs/Outputs (I/O), which are basically lists of port-value
standardized graphical language with clearly defined syntax pairs, are the basic exchange medium. E is a globe event list
that mathematically conforms to the DEVS formalism. storing unprocessed events with parameter and priority level.
Most of modeling environments of DEVS introduce the δport is the interface function of input ports,¥int is the internal
notions of state variables (e.g. two state variables are usually transition function, ¥ ext is the external transition function,
presented: “phase” and “sigma”. Sigma keeps the time and ¥ es is the scheduling function, which has the similar
advance value. In the absence of external events the system function as confluent transition function of P-DEVS in cases
stays in the current “phase” for the time given by “sigma”). of collision among simultaneous external and internal events.
And in complex systems the number of states or messages is ¬ is the output function, and ta is the time advance function.
usually too large that a more structured form of sequential In a coupled model, IP, OP, X and Y have similar
states and sequential messages is needed. Nevertheless, those connotation as in atomic model, but mean external (not
environments do neither fully implement these concepts nor coupled) elements; D is a set of DEVS component models.
explicitly formalize this idea [8]. In practice, when we depict EIC is the external input coupling relation; EOC is the
a system with previous DEVS Modeling Language external output coupling relation; IC is the internal coupling
(DEVSML) [9] based on Parallel DEVS and Finite relation. The coupled model can itself be a part of a
Deterministic DEVS (FD-DEVS) [10], it is inconvenient to component in a larger coupled model system giving rise to a
deal with nondeterministic state transitions, any state hierarchical DEVS model construction. Many concepts of
transition based on the message content is not realizable, and SP-DEVS have the same semantics as in P-DEVS
there may be a collision if two messages simultaneously (especially for coupled model). Therefore we only introduce
arrive on more than two ports. the extended parts in SP-DEVS.
To construct a scalable simulation, we need highly
scalable runtime performance and modeling methods that A. Structuring message: port, value and I/O variable
scale in terms of complexity and maintenance while As stated, X and Y are the set of I/O, which are basically
providing maximal reusability. Many discrete-event lists of port-value pairs, and a message is a bag of elements
simulation platforms take Event-Scheduling as their in X or Y. If a message is arrived, several ports may catch
modeling paradigm and have achieved great runtime some values at the same time. Therefore we have:
performance but poor modeling scalability. P-DEVS is a X = { (p,v)̮pęIP, vędom(p) } , Y = { (p,v)̮pęOP, v
good component-based specification because it has the ędom(p) }, where dom(p) is type or domain of port p, if a
ability to model complex systems by recursively dividing the coupling from one output port py to another input port px
initial system into smaller sub-systems. Nevertheless, it such that dom(py)⊆ dom(px).
could not well resolve confliction of simultaneously events
yet. Therefore we may introduce Event-Scheduling paradigm The message set M= XbƸ Yb , and Xb ={ mx̮mx⊆ X },
into DEVS to deal with these complex situations. Y ={ my ̮ my⊆ Y}. Sometimes, simultaneously arriving
b

To fill gaps between DEVS formalism and its inputs on different ports make it complex to describe the
implementation and propose a formally defined modeling behavior of the external transition function. If we choose an
language, we first extended P-DEVS by adding formally alternative transition to trigger, some inputs may be ignored
definitions of structured messages, states and transitions with or lost. Therefore we try to separate the processing of inputs
an Event-Scheduling world view; on this base we then give from state transition, if we first store these inputs in some I/O

249
variables, such that, any inputs will not be ignored or lost. To condition should be added to transition functions. It may be a
realize this idea, we define a set of Input-port-associate guard of messages or guard of variables.
Variables (IV) Vx, and a set of Output-port-associate The action is usually used to change value of variables
Variables (OV) Vy, these variables may be simple data type including state variables and I/O variables. After that the
(e.g. integer, floating number, string) or a container of simple output function¬can only be implemented by pushing out
data types (e.g. queue, stack, list). We can also define a the data stored in OV after an internal state transition. In this
binding between an I/O variable and a port: way, we revise the definition of the transition functions like
Rev ={ (p, vx, l)̮pęIP, vxęVx , dom(p)= dom(vx),lę these:
integer}, where l is the priority level. Sed = { (p, vy)̮pęOP, ¥port :QhXbėVxhE (5)
vy ę Vy , dom(p)= dom(vy)} where Rev is used to receive where Q = { (s,e) sęS, 0İeİta(s) } is the total state set,
messages and Sed is used to send messages. e is the time elapsed since last transition, and Xb is a set of
bags over elements in X;
B. Structuring state:phase and state variable
¥ext :QhEhVxhGėShA (6)
A discrete-event system’s status can be specified by a set where G is the guard condition set consisting of logical
of system variables or attributes. Each state variable expressions on messages or variables. It is denoted by:
represents an attribute characterizing the system. Thus a G:hvęSVƸVx dom(v)ėBoolean (7)
system state is a combination of values that the state
And the action A is a data process function, which may
variables have at a time. Now consider that we partition the construct a vector of individual actions for each variable:
composite state set into equivalent groups such that each
group has a set of sequential states. Let each group have a A:hvęSVƸVxƸVy dom(v) ė dom(v) (8)
single representative name, called a phase. Formally, a phase The internal transition function is also extended with
ψ is a representative value of a set of equivalent states which guards and actions:
produce the same output event and/or have the same time ¥int :ShGėShA (9)
advance at the states [8]. Therefore the state space S can be The output function¬: VyhSėYb and the time advance
defined as follow: function ta(s): SėR0+ ĤĞ are the same as original P-DEVS.
S = < Ψ, SV,{dom(sv)̮svęSV}, αs> (3) Finally the scheduling function is:
Ψ is a set of phases, SV is a set of state variables, dom(sv) ¥es : QhXbhGėOt (10)
is the range set of a state variable svęSV, and αs is the one- This function represents the scheduling strategy which
to-one assignment function which is subject to the constraint: decides the order of state transitions. Generally we have two
αs-1 : hsvęSV dom(sv) ė Ψ (4) choices to make: one has options including ignore-input,
which is a bijection such that S = { si= {ψi }Ƹ{sv1i ,sv2i,…} input-only, input-first and input-later, which decides the
order between δext and δint in case of the collision between
̮ψi ęΨ,sv1i ędom(sv1), sv2i ędom(sv2),…,svięSV,  si = simultaneous external and internal events; another has
s’ ={ψ’} Ƹ {sv1’,sv2’,…} }. An element svi = {sv1i ,sv2i,…} options including first in first out (FIFO), priority order and
mapped to a sequential state si is called a composite state in so on, which decides the order between simultaneous
the state space. s’ is the initial state of the state space and ψ’ external events.
is the initial phase. By the way, a phase can be hierarchical,
that is, a phase can be decomposed into sub-phases having IV. SCHEDULED PARALLEL DEVS MODELING
disjoint composite state members. It is always true that a LANGUAGE
union of sub-phases within a phase gives the total states set
To create a graphical modeling language, three levels of
of the phase and the intersection of all sub-phases results in
formal definitions are needed. First, the formalism with
an empty set. So this feature makes it easy to map SP-DEVS
mathematical base provides the semantics which describe the
onto StateCharts or UML StateMachine which also have
meaning of the models; then the syntax of the language must
composite state or sub-StateMachine. About this mapping,
be distinguished into two levels: an abstract syntax (the
we’ll present it in another paper soon.
conceptual elements and relationships between them) and a
C. Structuring Phase Transition: Event, Guard and Action concrete syntax (the graphical representation, figures, and
A state transition usually occurs by an connectors). A textual language is usually specified using
event/guard/action pair, and is actually a phase transition Extended Backus-Naur Form (EBNF) notation, and meta-
here. The event refers to an external message arrival or an modeling is a basic process of defining the syntax of a
internal event happening, we put unprocessed events in event graphical modeling language. We develop a modeling tool
list E. The guard and the action are still not formally defined for SPDML by using tool chains on Eclipse platform. Xtext
in P-DEVS, and they are just implemented within transition is a powerful framework for development of domain specific
functions in executable codes of DEVS. Some DEVS languages. After using Xtext's EBNF grammar language to
modeling languages are created based on FD-DEVS which define the abstract syntax of SPDML, it will create the meta-
only support deterministic state transitions. The guard model and the parser automatically by starting a generator.
condition is unnecessary in FD-DEVS, however, we wish This meta-model can be further used in GMF to create
SP-DEVS to be capable of coping with complex situations graphical diagram editors for SPDML. We use the tool
including nondeterministic state transitions. So the guard EuGENia [11] that automatically generates required models

250
for GMF diagram generation from a single annotated meta- be viewed as a part of a guard condition owing to that it is
model. For SPDML, both visual and textual models run on stored in an IV. For example, a variable is used for storage of
the same model instance, such that, a change to one of those inputs on a port, after receiving a message, if this variable is
models affects both models. not null (guard condition), transition is triggered. In both
Deltext and Deltint, for more flexible description of a guard
A. Meta-Modeling for SPDML condition, literal strings are used as standard format which
Considering of both convenience of use and conformity will be directly translated into executable codes. The
with the SP-DEVS formalism, we specify SPDML with UserFunction permit user to add code embedded in the
modular and object-oriented features. Models in SPDML are generated atomic and coupled model class source file, user-
divided into three primary elements: the Atomic, the defined method defined in an atomic model can be called by
Coupled and the Entity. the atomic itself and the coupled model comprising it to
1) Entity: DEVS is a component-based framework implement interoperability. The Hold allows the model to
where each of the components communicates using still stay in the source state but advance the elapsed time.
messages. These message objects are exchanged according The SetSigma also allows the resetting of time-advance of
to the port-value pairs specified in the atomic model, and the the target state.
datatype of a input value can be defined as an entity and
reused by some ports. According to the object-oriented
principles, the entities are defined not as a part of the
component but as a first-class citizen. Figure 1 gives the
meta-model of Entity. An Entity is specified by a name. It
may extend another entity. We define a variable type named
container which is a common data structure (e.g. queue) to
store a series of entities. The attribute deft assign values to
variables when model is started or restarted.

Figure 1. Meta-model for Entity model

2) Atomic: The Atomic is the most important and Figure 2. Meta-model for Automic model
complicated part of DEVS. Every core concepts in SP-
DEVS should be defined as corresponding elements. The
Atomic model is specified in meta-model as figure 2
showing.
Each state-time-advance pair is defined as a Phase. The
time-advance TimeAdv can have values of either DOUBLE,
infinity or a Variable declared above in the atomic model.
The state-machine contains the initial state InitState and the
atomic behavior AtomicBehavior. SP-DEVS has five
functions to specify the atomic behavior which is the main
part of operational sematic of SPDML. Correspondingly, the
AtomicBehevior is divided into five parts: Deltport, Deltext,
Deltint, Outfn (¬) and Confluent (¥es).
In Deltport, as any input ports may accept some inputs
when a message arrives during any state, the
ReceiveMessage is used to allocate the message (port-value Figure 3. Meta-model for Coupled model
pairs) to several IVs which is a static banding declared in an
atomic model. In this way these variables play roles as 3) Coupled: The meta-model of a coupled model is
buffers controlled by user. On the contrary in Outfn, the shown in figure 3. To put it simply, the coupled model can
SendMessage is a dynamic banding declared in the output
extend from another coupled model and it has the same
function to pack values of OVs and output ports into a
message. After outputs are pushed out these variables are interface specification as the atomic model. It is composed
cleared out automatically. A Guard may be variable correlate of a set of models which can be either atomic component or
or message correlate. We argue that a specific input can also coupled component. The definition of Coupling includes

251
EIC (defined for connections originating from input between the involved atomic models. The arrowhead also
interface of the coupled model to its subcomponents), IC points to the symbol representing the superType.
(specified between the subcomponents) and EOC (specified The most important part of an atomic model is the state-
from the contained component to the outside interface of the machine which has been defined in abstract syntax of atomic
coupled model). model. In this state-machine, each phase is shown as a
rounded rectangle with a time-advance box inside, and the
B. Formal Graphical Notation initial state has a double-line border. We use a straight line
1) Entity Diagram:An Entity is a data type of an input with arrow for an external transition and a dashed line with
arrow for an internal transition, and these transitions are also
or output and it is usually used to specify the type of a port.
labeled with guards and actions ([guard]/{actions}). For
It may contain attributes to support the modeling of output function, we embed Outfn into every rounded
structured data types. While an Entity Diagram (ED) is used rectangle of phase because at most one Outfn can be defined
to define all the reusable entities and their relationship. We for the same phase. Finally the scheduling function shown at
formally define the specification of ED as the following: the bottom includes two choices among the options
ED=<NE,ER > where NE={ ne ={nameƸVE} }; ne means mentioned above. As shown in figure 5, an atomic model
an entity node in NE includes a unique name and an attribute procCost and its superType processor are connected with
set composed of variables; and ER = NEhNE’ is an edge set link of inheritance, which is a simple example of AD. The
denoting relationships of generalization between entity nodes; corresponding textual source file for this model can be found
NE’ is a node set which is superType of the elements in NE. in figure 9. Note that if an atomic model extends from
For the notation of ED, an entity is shown as a solid-outline another one and changes are made on the state-machine, all
rectangle containing the entity’s name and its variables. And the description of the state-machine will be overloaded.
a relationship of generalization is shown as a line with a
hollow triangle as an arrowhead between the symbols
representing the involved entities. The arrowhead points to
the symbol representing the superType. Figure 4 gives a
simple example of ED: the entity job has only one variable
name typed as String, the entity jobWithSize and
jobWithTime extend it with additional variables.

Figure 5. An Atomic Diagram of processors

Figure 4. An Entity Diagram of jobs
3) Coupled Diagram:The Coupled Diagram (CD) is
2) Atomic Diagram: The most interesting feature of also composed of several nodes with links of generalization.
Atomic Diagram (AD) is that it allows for a combined Formally, a CD comprised of coupled models is specified
description of structure and behavior of models. This is by:
achieved by adding a state-machine to an UML-class-like- CD=<MC, CR > where MC={ mc ={name}ĤPxĤPyĤV
diagram being subject to inheritance. Formally, an AD Ĥ{cu}Ĥ{CA} }; mc means an coupled model in MC includes
comprised of atomic models is specified by: a unique name, a input port set Px and a output port set Py, an
AD=<MA, AR > where MA={ ma ={name}ĤPxĤPyĤVĤ attribute set V composed of user-define variables, some user-
Fu Ĥ {sm} }; ma means an atomic model in MA includes a defined codes cu (execute in the constructed function of
unique name, a input port set Px and a output port set Py, an generated codes of the coupled model) and a presentation of
attribute set V composed of state variables and I/O variables, Component Architecture (CA); and CR = MChMC’ is an edge
a set Fu composed of user-defined functions and a state- set denoting relationships of generalization between coupled
machine sm; and AR = MAhMA’ is also an edge set denoting models.
relationships of generalization between atomic models. For For the notation of AD, similar with an atomic model, a
the notation of AD, an atomic model can be specified as a coupled model can be specified as a box with input and
box with input and output ports on the border and the model output ports on the border, the model name at the top, a
name at the top, and these ports are labeled with their name variable box, a user-defined code box and a component
and type (name: type), the input ports further are labeled architecture box inside. In the component architecture box,
with IV(->variable name and port priority ). A variable box, component may be atomic model or coupled model shown as
a user-defined-function box and a state-machine box are set component object boxes. Recall that a component object
inside the model box. And a relationship of generalization is differs from a model for it is an instantiation of the model. A
shown as a line with a hollow triangle as an arrowhead component object box is the same as the model box except

252
for the box name of the form of object:model which code generation in Xtext can be found in [9] which is no
represents as an instantiation of the model. For the need to be presented in this paper. Finally we use one of the
couplings, the notation for EIC is a dashed line, IC is a open source DEVS simulator named DEVS-suite [12] to
continuous line, and EOC is a line-dot-dotted line. Note that validate the executable models.
if a coupled model extends from another one and changes are
made on the component architecture, all the description of
the component architecture will be overloaded. Figure 6
gives an example of a coupled model with corresponding
textual source file named EF which is an Experimental
Frame for evaluating the NFR (e.g. maximum throughput
and average turnaround time for jobs) and internally contains
two models viz. atomic genr and atomic transd. The genr is
a generator that sends entity job at a periodic rate (e.g. a job
per five minutes). The transducer transd is an observer that
keeps a count of generated as well as processed job. Figure 7. Recommended process of SPDML appication

Figure 6. An Coupled Diagram of Experimental Frame

Figure 8. Illustration of the Coupled model EFP

V. UTILITY OF SPDML WITH CASE STUDY

We consider that SPDML can be used in two different
ways: (1) it is directly applied in the design of systems
architecture as a modeling language because of its powerful
modeling ability with both textual and graphical features; (2)
it is used as a model transformation intermediary to make
systems architecture modeled in other Domain Specific
Language (DSL) executable. For example, UML models are
first converted to SPDML models, and then automatically
translated into executable codes. Both of these two methods
require assistance of corresponding model transformation
technologies (e.g. Xpand and Xtend). We give a
recommended process to achieve this goal in figure 7. The
first approach can be widely applied in M&S for all kinds of
discrete-event systems and the later one is also suitable for
models in wide-range of modeling languages such as UML,
SysML, BPMN/BPEL, etc. To illustrate the capability of the
SPDML, we’ll show two examples: one is classic EFP Figure 9. Textual source file of the processor and generated Java code
hierarchical model in SPDML. Another is a prototypical
multi-server architecture modeled in SysML which will be B. Example of Multi-server Architecture
transformed into DEVS executable codes using SPDML. The multi-server architecture model is common
A. Example of EFP workflow architecture such as in distributed computing,
EFP contains two models viz. the coupled model EF office systems, assembly lines and communication systems.
(Figure 6) and the atomic model processor (Figure 5). Figure In this case, as described in figure 11, the coupled model
8 shows the coupled model EFP and figure 9 shows the EFM contains two models viz. coupled EF and coupled
textual source file of the atomic model processor with multiServer. The multiServer receives jobs and processes
automatically generated java codes. The detailed process of them. On completion the genr reports it to the transducer
transd. The transd has an observation time after which it

253
reports the throughput. The coordinator in the coupled model suite, we can get visualization of models and their
multiServer, multiSco:serverCord keeps track of the status of animations are supported by “simView” (figure 11-a) , and
its servers in a queue called freeServers. A job arrives at the run-time display of message on ports and trajectory of states
input port in and is routed to the first passive server by being as two dimensional plots are supported by “TimeView”
sent out on a corresponding output port y. However, if no (figure 11-b). After simulation of several times by setting
server is free (assuming that a server can only handle one job different processing time for a job of single server, NFR
at the same time), the job will be stored in a queue jobsToDo. statistics is shown in figure 11-c.
When a completed job returns on corresponding port x, the
serverCord reroutes it to the output port out. Simultaneously VI. RELATED WORK
arrived completed jobs are stored in a queue jobsDone. Many efforts are made to translate some DSL models
Generating DEVS models through the diagrams of a DSL (such as UML as front-end of DEVS) into DEVS executable
may follow a certain order. First, we transform data models, or to provide textual or graphical modeling method
perspective diagrams into SPDML entities; second, we select for DEVS simulation. Some directly map formalism of DSL
the structural perspective diagram of components which to DEVS formalism and generating executable codes for
generates the corresponding SPDML coupled structure and DEVS simulator on different platforms [13][14][15]. These
class definition diagrams that generate variables in atomic methods can be implemented on a single platform, and the
model; at last, the behavior of each atomic model is defined conversion process is relatively complex. The others provide
by behavioral perspective diagrams which are augmented DEVS textual modeling languages (e.g. DEVSpecL [16],
with more information as per DEVS requirements. It is XFD-DEVS[17], DEVSML 2.0 [9],) or graphical modeling
important to emphasize that there are many alternative languages (e.g. DDML[18] and DEVS Diagram[8]), and a
combinations of different diagrams to generate SPDML extension of UML for DEVS are also proposed as a SysML
executable models. We take Block Definition Diagram, profile [19]. DEVSpecL based on classic DEVS formalism is
Internal Block Diagram and State Machine Diagram in the first specification language in the DEVS research area
SysML as example, which is sufficient to implement an that supports development of design tool (DEVSim++), but
automated transformation process. Figure 10 shows a it is limited by the classic DEVS to express complex system
StateMachine Diagram of the coordinator multiSco which is behaviors. XFD-DEVS based on XML and FD-DEVS has
the most important component in this multi-server many shortcomings, such as, no confluent function, no
architecture. Having received some inputs and being passive, multiple inputs, no multiple outputs, no complex message
it first process the message before going into a pseudostate types and no state variables. These shortcomings are
MessageInput, then if the queue jobsToDo and freeServers removed in its upgraded version DEVSML 2.0 based on P-
are both not empty, multiSco goes into state send_y and DEVS, by comparison with DEVSpecL, the DEVSML2.0 is
broadcasts a message to all the subordinate servers in the more close to the true DEVS formalism with some necessary
data type JobToServer (including the name of first element abstractions, but it has some limitations to express complex
of freeServers). If multiSco receives a completed job which transition logic as it employs deterministic properties of the
is also an instance of data type JobToServer on port x, it goes constituent elements, which are formally defined in FD-
into state send_out for a “zero” time, then send out this DEVS. DEVS-Driven Modeling Language (DDML) is a
completed job and add the name of the sever going into idle visual language with syntaxes and semantics defined but lack
state to the queue freeServers. Note that in figure 10, of precise formalism as basis, and its automatic generation of
jobsToDo, freeServers and jobsDone are IVs and jobToDo is codes for simulation and formal analysis are still under
an OV which is assigned in the action using a user-function research. DEVS Diagram, a structured graphical form of the
make_output. DEVS formalism, was proposed to provide both graphical
notations and mathematical formulations for DEVS.
Although its structured method gives us inspiration for
SPDML, problem of parallelism still exists as it is based on
classic DEVS. Our modeling language can be seen as
enhancement and exploration based on languages mentioned
above with some improvements such as Event-Scheduling
world view, separation of message processing from state
transition, support for nondeterministic state transitions and
other additional extended features.
VII. CONCLUSIONS AND FUTURE WORK
We have presented SPDML, a graphical modeling
language based on DEVS. It has not only graphical and
textual features but also versatility in Modeling & Simulation
Figure 10. StateMachine Diagram of the coordinator serverCord
(M&S), executable architecting for systems. Because it is
After an automated transformation process from SysML created on SP-DEVS that is a comprehensive formalism as
to SPDML, the final generated codes are executed in DEVS- an extension of P-DEVS, with formal definition of both
abstract syntax and graphical notation, it not only inherits the

254
advantages such as rigorous mathematical basis and [7] Vangheluwe, Hans LM. DEVS as a common denominator for multi-
operational semantics but also obtains additional benefits as formalism hybrid systems modelling. Computer-Aided Control
System Design, 2000. CACSD 2000. IEEE International Symposium
follow (1) SPDML enhances its capability and scalability to on. IEEE, 2000.
describe complex behavior of systems without the limitation [8] H. S. Song and T. G. Kim, “DEVS Diagram Revised: A Structured
of classic DEVS. (2) It helps modelers realize automated Approach for DEVS Modeling”, in: Proc. European Simulation
transformation from static architecture models to executable Conference (Eurosis, Belgium, 2010) 94 – 101.
codes to conduct a systematic simulation of the architecture. [9] Mittal, S., and S. A. Douglass. "DEVSML 2.0: The Language and
(3)It makes modelers no need to delve in the specific DEVS the Stack." Symposium on Theory of Modeling and Simulation,
simulator codes but only user-defined behavior logic of their Spring Simulation Multiconference. Orlando, FL: SCS. 2012.
own. We are currently in the process of completing an [10] Hwang, Moon Ho, and Bernard P. Zeigler. Reachability graph of
integrated modeling tool for SPDML. As the current status finite and deterministic DEVS networks. Automation Science and
Engineering, IEEE Transactions on 6.3 (2009): 468-478.
of SPDML is only support for static-architecture coupled
[11] EuGENia, http://www.eclipse.org/epsilon/doc/eugenia/, accessed
models, our future work also includes description of DEVS February 2013.
dynamic-architecture, which permits the coupled model to [12] Kim, Sungung, Hessam S. Sarjoughian, and Vignesh Elamvazhuthi.
evolve over time. "DEVS-suite: a simulator supporting visual experimentation design
and behavior monitoring." Proceedings of the 2009 Spring Simulation
ACKNOWLEDGMENT Multiconference on ZZZ. Society for Computer Simulation
International, 2009.
The work described in this paper was supported by the
[13] Pasqua, Roberto, et al. "FROM SEQUENCE DIAGRAMS UML 2. x
National Natural Science Foundation of China under Grant TO FD-DEVS BY MODEL TRANSFORMAT ION." European
No. 61232007, 91118004, and the Innovation Program of Simulation and Modelling (2012).
Shanghai Municipal Education Commission (No. 13ZZ023). [14] Shaikh, Reehan, and Hans Vangheluwe. "Transforming UML2. 0
class diagrams and statecharts to atomic DEVS." Proceedings of the
REFERENCES 2011 Symposium on Theory of Modeling & Simulation: DEVS
[1] Department of Defense (DoD), Systems engineering guide for sys- Integrative M&S Symposium. Society for Computer Simulation
tem of systems, version 1.0, Washington, DC, 2008, International, 2011
http://www.acq.osd.mil/sse/docs/SE-Guide-for-SoS.pdf. [15] Risco-Martín, José L., et al. "eUDEVS: Executable UML with DEVS
[2] Griendling, Kelly, and Dimitri N. Mavris. "Development of a theory of modeling and simulation." Simulation 85.11-12 (2009):
DoDAF-based executable architecting approach to analyze system-of- 750-777.
systems alternatives." Aerospace Conference, 2011 IEEE. IEEE, 2011. [16] Hong. KJ, Kim, TG, "DEVSpecL-DEVS specification language for
[3] Wang, Renzhong, and Cihan H. Dagli. Executable system modeling, simulation and analysis of discrete event systems,"
architecting using systems modeling language in conjunction with Information and Software Technology, Vol. 48, No. 4, pp. 221 - 234,
colored Petri nets in a modeĺdriven systems development process. Apr., 2006
Systems Engineering 14.4 (2011): 383-409. [17] Mittal, S, Zeigler, BP, Hwang, MH, “XFDDEVS: XML-Based Finite
[4] OMG (Object Management Group), Semantics of a foundational Deterministic DEVS”, last accessed Jan 2013 at:
subset for executable UML models, version 1.0, ptc/2011-02-01, http://www.duniptechnologies.com/research/xfddevs/
http://www.omg.org/spec/FUML/1.0/ [18] Ighoroje, etc. The DEVS-driven modeling language: syntax and
[5] No Magic Inc., Cameo Simulation Toolkit. Last accessed January semantics definition by meta-modeling and graph transformation.
2013. http://www.nomagic.com/products/magicdraw-addons/cameo- Proceedings of the 2012 Symposium on Theory of Modeling and
simulation-toolkit.html Simulation-DEVS Integrative M&S Symposium. Society for
Computer Simulation International, 2012.
[6] Zeigler, B. P., T. G. Kim, and H. Praehofer. Theory of Modeling and
Simulation: Integrating Discrete Event and Continuous Complex [19] Nikolaidou, Mara, Vassilis Dalakas, and etc. Integrating Simulation
Dynamic Systems Second Edition: Academic Press. 2000. Capabilities in SysML using DEVS. Proceedings of IEEE Systems
Conference. 2010.

Figure 11. Simulation results of the multi-server architecture case

255