a mda-based approach for the development of devs/soa simulations
TRANSCRIPT
A MDA-based Approach for the Development of DEVS/SOA Simulations
Andrea D’Ambrogio University of Rome
TorVergata Rome, Italy
Daniele Gianni University of
Oxford, Oxford, UK
José L. Risco-Martín Universidad Complutense
de Madrid, Madrid, Spain
Alessandra Pieroni University of Rome
TorVergata Rome, Italy
Keywords: Discrete event simulation, DEVS, UML, MDA, model transformation, model-driven development Abstract The intrinsic complexity of the DEVS formalism and the manual production of DEVS-based simulations might constitute obstacles to the adoption of DEVS for both system modelers and simulation users. To overcome these obstacles, this paper introduces a model-driven approach for the development of DEVS simulations. The approach provides modelers and users with standard graphical modeling languages and with model transformation specifications for automated code production. Specifically, the approach enables the UML specification of DEVS models and automates the generation of DEVS simulations that make use of the DEVS/SOA implementation. An example application to the production of a DEVS/SOA simulation for a basic queuing system is also presented, to show the details of the proposed approach. 1. INTRODUCTION
The DEVS formalism introduces a notation for rigorous and systematic definition of discrete event system models. The DEVS formalism has been provided with various simulation technologies, such as DEVSJAVA [Zeigler and Sarjoughian 2005] or DEVS/C++ [DEVSc++], which are used to produce the implementation of DEVS simulations from DEVS-based model specifications. The widespread adoption of the DEVS technologies can be hindered by the inherent difficulties and specificities of the DEVS formalism and by the semantic gap between the model specification and the corresponding implementation, in other words by the manual-based approach to the production of the simulation code from a DEVS model specification. The first problem can be overcome by adopting standard, general-purpose (i.e., non-simulation specific), modeling formalisms that abstract from simulation- and DEVS-specific characteristics, whereas the second one can be overcome by automating the generation of the simulation code from the model specification. In the software engineering community, the OMG (Object Management Group) has introduced both a standard modeling formalism, i.e., UML (Unified Modeling Language [UML]), and a
framework for automated code generation, i.e., MDA (Model Driven Architecture [MDA]). This paper introduces a MDA-based approach for the development of DEVS simulations, with specific application to the DEVS/SOA implementation. The paper presents both the DEVS-oriented UML extensions that are at the basis of the proposed approach and the set of model transformations that have been specified to obtain the core portion of the final code from the high-level model specification of the system under simulation. The rest of the paper is organized as follows. The related work section outlines this paper contribution with respect to the state-of-the-art. The background section gives the main concepts of DEVS/SOA and MDA technologies. The DEVS-MDA section illustrates the proposed approach and the example section finally presents the application of the MDA-based approach to the development and configuration of a DEVS/SOA-based simulation of a basic queuing system. 2. RELATED WORK The contribution of this paper can be related to already existing contributions in terms of two independent aspects: the platform independent representations of DEVS models and the automatic development of DEVS simulations from DEVS models specifications. In the first group, significant contributions can be found: in [Risco-Martín et al. 2007], [Janousek et al. 2006], [Mittal et al. 2007], [Bendre and Sarjoughian 2005], [Choi et al. 2006], [Posse et al. 2003] and [Risco-Martín et al. 2009]. DEVS/XML is introduced in [Risco-Martín et al. 2007] as a standard XML format for the representation of DEVS Models (i.e., component structure and hierarchical notation). The DEVS/XML approach differs from this paper approach in two ways: the model representation is textual, thus less readable compared to UML diagrams, and the simulation system cannot be automatically produced from a DEVS/XML file. Similarly, XML formats to represent DEVS models are introduced in [Janousek et al. 2006] and [Mittal et al. 2007]. Their contribution also includes the transformation from Platform Specific Models (PSMs) to Platform Independent Models (PIMs). However, this approach is still based on a textual representation of DEVS models.
Analogously, the Scalable Entity Structure Modeler with Complexity Measures (SESM/CM) [Bendre and Sarjoughian 2005] introduces an XML format for DEVS models. This format is tailored to the specification of component-based hierarchical models and also offers the structures to represent behavioral aspects of atomic models. This paper approach differs in the notation used (UML diagrams) and in the wider scope of DEVS models development and deployment into the DEVS/SOA platform. The UML-based M&S domain [Choi 2006] introduces a methodology based on UML sequence diagrams to define DEVS model behavior, in analogy to [Posse et al. 2003] that makes use of a graphical definition of DEVS models suitable for simulation. Differently, this paper approach concerns mainly the structural properties (i.e., class diagrams) of DEVS models. Finally, the mapping of DEVS models (both structure and behavior) onto seven UML diagrams is illustrated in [Risco-Martín et al. 2009]. This paper operates the inverse mapping, by transforming UML diagrams to DEVS Models and by automatically producing the structural classes of DEVS simulation systems. In the second group, contributions aiming to automate the development of simulation systems, such as the ones in [Tolk and Muguira 2004] and [Parr and Keith 2003], can be found. Such contributions do not address the DEVS domain. Concerning the automation approach, the contribution in [Tolk and Muguira 2004] differs from this paper approach in terms of the application strategy, the UML diagrams adopted and the state of implementation. Concerning the application strategy, it proposes the creation of a specific domain for Modeling and Simulation (M&S) within MDA. Differently, this paper focuses on the application of MDA techniques to the production of simulation systems treated as general purpose software systems. This means that, in case of simulation of software systems, the same approach can be adopted to eventually generate both the operational system and the simulation system from the same model specification. The set of UML diagrams adopted in [Tolk and Muguira 2004] is wider and includes sequences diagram and deployment diagrams. Conversely, this paper focuses on a narrower set of diagrams, including class diagrams and interaction diagrams. The implementation of the contribution in [Tolk and Muguira 2004], however, is not complete, differently from this paper, which implements a model-driven process by introducing a set of DEVS-specific UML profiles and a set of model transformations for deriving the simulation code from the UML model specification. Similarly, the approach in [Parr and Keith 2003] introduces a visualization tool for representing HLA objects and for deriving the relevant FOM and SOM. Differently, this paper approach relies on standard UML-based tools, such as AndroMDA [AndroMDA] and ArgoUML [ArgoUML],
which also prove to be more reliable and more open to extensions. As regards software technologies for code derivation, the contribution in [Parr and Keith 2003] adopts proprietary technologies, while this paper contribution is founded on using standard languages for specifying model transformation. 3. BACKGROUND The following subsections overview the DEVS/SOA technology and the standard specifications introduced by MDA, respectively. 3.1. DEVS/SOA DEVS/SOA is an implementation of the DEVS formalism over a Service Oriented Architecture (SOA). The purpose of DEVS/SOA is to provide distributed simulation and interoperability [Mittal et al. 2009]. SOA is a framework consisting of three W3C standards: the Simple Object Access Protocol (SOAP), the Web Service Description Language (WSDL), and the Universal Description Discovery and Integration (UDDI). By means of SOA various computational components may be available as “services” interacting in an automated manner to achieve machine-to-machine interoperable interaction over the network. DEVS/SOA performs web-based simulation of DEVS-based models, which requires the convergence of simulation methodology and the World Wide Web (WWW) technology (mainly Web Service technology). Thus, DEVS/SOA is offering DEVS-based simulators as web services, which are based on these standard technologies. For illustration purposes, Figure 1 depicts the scheme of a typical DEVS/SOA simulation running the generator-processor-transducer model [Zeigler et al. 2000]. It involves three different computers and the client machine, which can be one of the computers running the simulation or not. Coordinators and Simulators are provided by DEVS/SOA as web services. The DEVS/SOA Atomic component serves as the adapter for the different DEVS modeling platforms (xDEVS, DEVSJAVA and DEVS.NET in the Figure), transforming their original messages to SOAP-based messages. How to configure a heterogeneous and distributed DEVS model using DEVS/SOA? Each DEVS M&S library is developed using a particular programming language (Java, C, C++, C#, etc.). Since DEVS/SOA provides interoperability, the composition of the desired DEVS model at the client application level is completed using a platform independent mechanism. Therefore, DEVS/SOA describes DEVS coupled models exploiting the eXtensible Markup Language (XML) description format. The schema used to define DEVS/SOA distributed and interoperable models is called DEVS Modeling Language (DEVSML), and was introduced in [Mittal et al. 2007]. These models encoded in DEVSML provide a detailed remote
characterization of a DEVS compound model. This document is referred to as the DEVS/SOA XML configuration file.
Figure 1. DEVS/SOA distributed simulation.
A DEVS/SOA simulation is executed by using such configuration file as input. A DEVS coupled model is split up into different submodels that run on multiple computers communicating over a network. To this end, the DEVS/SOA coordinator deals with simulators hosted anywhere over the web. Every DEVS/SOA simulator is responsible to manage its corresponding DEVS atomic model. Since the communication between simulators is performed using SOAP, the associated DEVS submodels can be implemented using different DEVS simulation engines (currently DEVSJAVA, xDEVS, MicroSim, CD++ and DEVS.NET are supported). As a result, DEVS models can be composed in a transparent, open, and scalable way. 3.2. MDA Model-driven development is founded on the idea of automating the design and implementation of systems specified by use of abstract models. Such models are transformed into more refined system models and eventually into the source code that implements the system [Mellor et al. 2003]. The Object Management Group (OMG) embraced the above idea with the introduction of MDA, the Model Driven Architecture. MDA supports the model-driven development of software-intensive systems through the transformation of platform independent models to platform specific models, executable components and applications. The main motivation behind MDA is to transfer the focus of work from coding to modeling, by treating models as the primary artifacts of development. MDA provides a set of guidelines for structuring specifications expressed as models and the transformations between such models [MDA]. The transformations map the elements of a source model,
conforming to a metamodel, to elements of a target model, conforming to a different metamodel. The Meta Object Facility (MOF) is the OMG standard that defines an abstract language and a framework for specifying, constructing, and managing technology neutral metamodels, or models used to describe other models [MOF]. MOF introduces a layered metadata architecture. As an example, the MOF Model provides the language to define the UML metamodel, which in turn provides the language to define UML models. A side standard of MOF is the OMG’s XML Metadata Interchange (XMI) specification, which provides a set of rules that are applied to model elements to produce an XML document [XMI]. These rules can be applied to any model instance of a MOF metamodel. The XMI specification also gives rules to produce a XML Schema/DTD from a MOF metamodel, against which XML documents are checked for validity. In response to the need for a standard approach to defining model transformations, the OMG issued the MOF 2.0 Query/View/Transformation (QVT) Request for Proposals, which eventually led to QVT Specification [QVT]. QVT provides standard languages for specifying model transformations defined in terms of the relationships between a source model, that conforms to a specific metamodel, and a target model, that conforms to the same or to a different metamodel. This paper describes an approach to rigorous modeling of pattern-based transformations that map the UML model of the system under simulation into first the UML model and then the code of the corresponding DEVS/SOA-based distributed simulation. In order to define the details of MDA platforms, and thus be able to specify platform specific models, the UML specification provides the UML profile mechanism, i.e., a generic extension mechanism for customizing UML models for particular domains and platforms. A profile specifies a set of stereotypes, or metaclasses that extend standard UML metaclasses [UML]. Each stereotype introduces a set of tags, or extra attributes of the UML metaclass extended by the stereotype. The use of UML profiles is essential for increasing the expressiveness of UML models. 4. DEVS-MDA APPROACH The MDA-based approach for the development of DEVS/SOA-based simulations consists of two main processes, i.e., the development process and the configuration process. The development process is shown in Figure 2 and illustrates the derivation of DEVSJAVA simulation code from a standard UML specification of the system under simulation. This process consists of a pipeline of five activities (flat squares), each producing an artifact in the form of an UML model or simulation code (ellipses). Each
activity can be carried out either manually or automatically, by use of a model transformation, as specified in Figure 2, where M2M stands for model-to-model transformation and M2T stands for model-to-text transformation. Some of the activities take as input an UML profile (rounded rectangles). The first activity is the system modeling activity and is typically carried at system development time, regardless of the fact that the system is to be simulated or not. The system modeling activity yields as output the platform independent model of the system specified in terms of a UML class diagram. Such input model is then transformed by the simulation marking activity into a UML class diagram annotated according to the UML simulation profile, which allows marking the model elements corresponding to the system entities to be simulated. The annotated model is taken as input by the DEVS profiling activity, which applies the UML DEVS profile to yield as output the model specification in terms of DEVS entities. Such model is then appropriately marked by the DEVS/SOA marking activity, so as to drive the final DEVS/SOA code generation activity, which produces the stubs of the DEVSJAVA classes to be deployed onto a DEVS/SOA platform.
Figure 2 Development process
The configuration process is executed to derive the XML configuration file for the DEVS/SOA execution platform. The configuration process is shown in Figure 3, which makes use of a notation identical to the one of Figure 2. The configuration process consists of a pipeline of four activities, each producing an artifact in the form of an UML model or a XML file. The first activity is named system structure modeling and yields as output the system structure specified in terms of UML composite structure diagrams, which conform to the UML class diagrams of the system. The subsequent DEVS/SOA configuration activity annotates the composite structure diagram by use of the DEVS/SOA configuration profile. The so-obtained model is then taken as input by the DEVS/SOA parameterization activity that requires the manual specification of the execution parameters (e.g., URLs of the DEVS/SOA simulators). Finally, the parameterized model is transformed into the DEVS/SOA XML configuration file by the DEVS/SOA XML serialization activity.
Figure 3 Configuration process
The following subsections illustrate both the set of UML
profiles (rounded rectangles in Figure 2 and Figure 3) that have been produced and the set of model transformations (M2M and M2T labels in Figure 2 and Figure 3) that have been specified in the definition of both the development process and the configuration process [D’Ambrogio et al. 2009]. 4.1. UML Profiles A UML profile defines the set of stereotypes that extend standard metaclasses of the UML metamodel. As illustrated in Figure 2 and Figure 3 (see rounded rectangles), the set of profiles defined by the DEVS-MDA approach consists of the Simulation Profile, the DEVS Profile, the DEVS/SOA Profile and the DEVS/SOA Configuration Profile. The stereotypes introduced by the proposed approach are described below, for each profile. 4.1.1. Simulation Profile The Simulation profile extends the UML metamodel to specifically represent the simulation entity concept. The profile consists of the SimulationProfile package, which contains the stereotypes BasicSimulationEntity and StructuredSimulationEntity. The former denotes a simple element (i.e., one that does not incorporate other entities). The latter denotes macro-entities (i.e., entities composed of a set of structured or basic entities, as shown by the relationships hasStructuredSimulationEntities and hasBasicSimulation-Entities). In addition to defining the stereotypes, the simulation profile defines a set of constraints that must be imposed when codifying the model through this profile. An example of such constraints is that a UML class marked as BasicSimulationEntity cannot be marked as StructuredSimulationEntity too. 4.1.2. DEVS Profile The DEVS profile extends the UML metamodel to represent the concepts (e.g., port or atomic entity) of the DEVS domain. The profile uses a terminology consistent with the
DEVS specification and consists of the following stereotypes: Entity, Content, Message, Port, InPort, OutPort, Devs, Atomic, Coupled and Coupling. Entity represents the root concept of the system. Content defines the data associated to a message, whose concept is defined by the Message stereotype. Port defines the communication socket within entities in the DEVS specification. Port is specialized into InPort and OutPort. The former models an input socket, while the latter models an output socket. The port stereotypes are associated to the Devs stereotype, which identifies the entire DEVS model. The Devs stereotype can be further specialized into Atomic and Coupled, which are in close analogy with the corresponding concepts in the DEVS specification. The Coupled stereotype consists of a set of Devs entities and a set of coupling rules (identified by the Coupling stereotype) among the entities. 4.1.3. DEVS/SOA Profile The DEVS/SOA profile extends the UML metamodel to represent the concepts of the DEVS/SOA domain. The profile enriches the DEVS Profile with concepts and features of the DEVS/SOA domain. The profile consists of the DEVSSOAProfile package, which can be divided into two parts: the standard DEVS concepts, which are illustrated in the DEVS profile and replicated in this profile, and the specific concepts of the DEVS/SOA platform. The first part consists of the following stereotypes: Entity, Content, Message, Port, InPort, OutPort, DevsSimulationComponent, AtomicSimulator, and CoupledSimulator. All such stereotypes are directly tied to the corresponding stereotypes of the DEVS profile, except for DevsSimulationComponent, AtomicSimulator and CoupledSimulator, which are to be related to the stereotypes Devs, Atomic and Coupled of the DEVS profile, respectively. The second part of the package consists of the following stereotypes: DevsSoaComponent, Simulator, Coordinator, CoupledCoordinator, and RootCoordinator. The stereotype DevsSoaComponent represents the DEVS simulation unit within the DEVS/SOA platform and incorporates the services and data described in the DEVS/SOA background section. This stereotype is specialized in the stereotypes Simulator and Coordinator. The former represents the simulator of an atomic DEVS component, whose stereotype is associated to the Simulator stereotype. The latter represents the simulator of a coupled DEVS component, whose stereotype is associated to the Coordinator stereotype. 4.1.4. DEVS/SOA Configuration Profile The DEVS/SOA Configuration profile extends the UML metamodel to represent the concepts related to the configuration of a DEVS/SOA simulation specified by use of the DEVS/SOA profile. The configuration profile, shown
in Figure 4, has been built by carrying out a reverse engineering activity from the existing DEVS/SOA XML configuration file. The profile consists of the following stereotypes: CoupledCoordinatorInstance, AtomicSimulatorInstance, CoupledSimulatorInstance, InPortInstance, OutPortInstance, ConnectionInstance.
Figure 4 DEVS/SOA configuration profile
The stereotype CoupledCoordinatorInstance indicates that each instance of an element stereotyped as CoupledCoordinator must be retrieved from a specified URL. 4.2. Model Transformations The automated activities of the development and configuration processes basically apply a series of model transformations that map the element of a source model to the element of a target model. The source model is a UML model, while the target model can be either a UML model (annotated by use of a different profile with respect to the source model) or a text file that represents Java code or XML data. The set of model transformations that have been introduced to automate the activities of both the development process and the configuration process are illustrated in the following subsections. Activities carried out manually, such as the simulation marking activity of the development process, are not discussed here. 4.2.1. Simulation-to-DEVS Transformation The simulation-to-DEVS transformation takes as input the UML model initially marked by use of the Simulation profile and yields as output an UML model annotated by use of the DEVS Profile. The transformation has been specified in the ATLAS Transformation Language (ATL) [ATLAS]. The choice of ATL in place of QVT is mainly due to the availability of an effective tool support. However, ATL
transformations can be easily mapped to QVT and vice versa [Joualult and Kurtev 2006]. The ATL-based simulation-to-DEVS transformation can be summarized by the following two mapping rules: 1) each element stereotyped as BasicSimulationEntity must be mapped to an element stereotyped as Atomic; and 2) each element stereotyped as StructuredSimulationEntity must be mapped to an element stereotyped as Coupled. Both rules are of immediate understanding and therefore not discussed further. 4.2.2. DEVS-to-DEVS/SOA Transformation The DEVS-to-DEVS/SOA transformation is a model-to-text mapping that takes as input the UML model annotated by use of the DEVS Profile and yields as output an UML model annotated by use of the DEVS/SOA Profile. The transformation has been specified in ATL and can be summarized by the following three mapping rules: 1) each element stereotyped as Atomic must be mapped to an element stereotyped as AtomicSimulator; 2) each element stereotyped as Coupled must be mapped to an element stereotyped as CoupledCoordinator, if the Coupled stereotyped element is root of a DEVS hierarchy; 3) each element stereotyped as Coupled must be mapped to an element stereotyped as CoupledSimulator, if the Coupled stereotyped element is not root of a DEVS hierarchy. These rules are also of immediate understanding in the DEVS and DEVS/SOA context. 4.2.3. DEVS/SOA-to-DEVSJAVA Transformation The DEVS/SOA-to-DEVSJAVA transformation is a model-to-text mapping that produces the DEVSJAVA stubs from the elements of the DEVS/SOA-annotated UML model. This transformation has been specified by use of the Xpand language. An Xpand transformation rule is specified using a template file that defines statements, entity placeholders and queries to retrieve the model elements to be converted into code. The Xpand transformation rules yields the skeleton of the Java classes corresponding to the DEVS/SOA stereotyped classes in the source UML model. For the sake of conciseness, such rules are not further detailed here. 4.2.4. UML-to-DEVS/SOAConf Transformation The UML-to-DEVS/SOAConf transformation takes as input the UML composite structure diagram and yields as output the UML composite structure diagram annotated by use of the DEVS/SOA Configuration profile. The transformation has been specified in ATL and consists of the following 6 mapping rules: 1) Each Class element must be mapped to an element stereotyped CoupledCoordinatorInstance; 2) Each Part property stereotyped as AtomicSimulator must be mapped to a Part property stereotyped as AtomicSimulatorInstance; 3) Each Part property stereotyped as CoupledSimulator must be mapped to a Part property
stereotyped as CoupledSimulatorInstance; 4) Each Port element of InPort type must be mapped to a Port element stereotyped as InPortInstance; 5) Each Port element of OutPort type must be mapped to a Port element stereotyped as OutPortInstance; 6) Each Connector element must be mapped to a Connector element stereotyped as ConnectionInstance. 4.2.5. DEVS/SOAConf-to-DEVS/SOAxml
Transformation The DEVS/SOAConf-to-DEVS/SOAxml transformation is a model-to-text mapping that produces the DEVS/SOA XML configuration file from the elements of the UML composite structure diagram (CSD) annotated by use of the DEVS/SOA Configuration profile. This transformation has been specified by use of the Xpand language and yields the XML elements corresponding to the DEVS/SOA stereotyped classes in the source UML model. For the sake of conciseness, such rules are not further detailed here. 5. EXAMPLE APPLICATION The development and configuration processes above defined are here exemplified for the Gen-Buf-Proc system, a simple queueing-based system consisting of a Poissonian Job Generator, a Buffer for job queueing and routing, a Transducer for the statistics collection, and a Processor Subnet consisting of one or more Processors. The generator produces a job and sends it to the Buffer. The Buffer either schedules the job – if the buffer is not empty, or sends the job to one of the available processors. The system specification consists of the following classes: Net, Generator, Job, Buffer, Transducer, Statistics, and Processor. The Net defines the queueing-based system as composed of a Generator, a Buffer, a Transducer, and a Processor. The Generator is described by the generation time (gen_time) and by the number of Jobs generated (count). A Job is described by an in-time (ti) and an exit-time (te). Jobs are stored in the Buffer. The Transducer collects statistical data on the Jobs entering and leaving the Buffer, for validation purposes. The Statistics class represents the statistical data. Finally, the Processor class introduces attributes such as a counter of the processed jobs, the average service time and the total processing time. The development process starts by manually marking the UML model by use of the stereotypes of the Simulation Profile. In particular, the BasicSimulationEntity stereotype is applied to the classes Generator, Buffer, Transducer, and Processor and the CoupledSimulationEntity stereotype is applied to the class Net. The so-obtained model is then transformed by use of the Simulation-to-DEVS and DEVS-to-DEVS/SOA transformations, respectively. Figure 5 illustrates the resulting model, which is annotated by use of the DEVS/SOA Profile.
Figure 5 Gen-Buf-Proc model annotated by use of the
DEVS/SOA Profile The DEVS/SOA-stereotyped model is finally given as input to the DEVS/SOA-to-DEVSJAVA transformation that yields as output the DEVSJAVA code. As an example, the Generator class, stereotyped as <<AtomicSimulator>>, is transformed into the following Java code: package gbp; import genDevs.modeling.Atomic; public class Generator extends Atomic { protected double gen_time; protected int count; public Generator() { this("Generator"); } … }
The above class represents a stub for the implementation within the DEVSJAVA platform. The stub consists of the declaration of the class, the attributes, the constructor and the accessor methods. Once the simulation logic is implemented, i.e., the state evolution and the message handling functions are coded, the DEVS component can be deployed within the DEVS/SOA platform. The configuration process is then executed to parameterize the DEVS/SOA platform and make the simulation ready to be executed. The process carries out the transformation of the composite structure diagram of the Gen-Buf-Proc system into the corresponding composite structure diagram annotated by use of the DEV/SOA Configuration profile. The diagram consists of the main package, gbts, which contains only the Net structure entity. This entity consists of four parts, each identifying a basic simulation entity (i.e., Generator, Buffer, Transducer, and Processor), a set of ports and a set of connections between ports. Finally, the composite structure diagram is given as input to the DEVS/SOAConf-to-DEVS/SOAxml model-to-text transformation that yields as output the DEVS/SOA XML configuration file. Such a file starts with the following root
<coupled> element, which is obtained from the Net element stereotyped as CoupledSimulationEntity: <coupled id="Net" platform="devsjava" host="http:/ /localhost/devs/Coordinator"> … </coupled>
The root element contains the declaration of all the atomic elements and of the connections in the diagram. For example, the Buf atomic element is declared as follows in the following XML excerpt: <atomic name="Buf" platform="devsjava" class="QN.Buffer" host="http://localhost/devs/Simulator"> … </atomic>
where the name attribute identifies the DEVS components (i.e., Buf), the platform attribute specifies the execution environment (i.e., DEVSJAVA), the class attribute indicates the Java class through the class full name (i.e., containing the packages) and the host attribute points to the URL where the class is accessible. The atomic element in turns contains the declaration of the input and output ports. As an example, the in input port and the out1 output port are transformed into the following XML code, where the attributes convey identical semantics as for the atomic element: <inport name="in" class="QN.Job"/> <outport name="out1" class="QN.Job"/>
The XML document ends with the definition of the connections, which in the case of the connections between the Buf entity and the ProcessorsSubnet entity yields the following XML code: <connection atomicFrom="buf" portFrom="phase_req" atomicTo="processorsSubnet" portTo="phase_req"/>
6. CONCLUSIONS The intrinsic complexity of the DEVS formalism and the manual production of DEVS simulations might constitute obstacles to the widespread adoption of DEVS. This paper has introduced a model-driven approach that allows to automate most of the activities that are traditionally carried out manually to implement a DEVS-based simulation from a high-level model of the system under simulation. The approach has been applied to simulations built by use of the DEVS/SOA implementation. The paper has illustrated the set of UML profiles and model transformations that endow simulation developers with an automated approach that produces a significant portion of the final simulation code. Both the profiles and the transformations have been specified and executed by use of model-driven tools. Specifically, model-to-model transformations specified in ATL have been executed by use of the ATL engine provided by the Eclipse Modeling Framework [EMF], while model-to-text transformations specified in Xpand have been executed by use of the openArchitectureware tool [oAW].
The approach has been left general enough to be easily adapted to additional DEVS-based implementation technologies when moving from the abstract, platform-independent, system model to more refined, platform-specific, models and eventually to the simulation code. In the paper case, specific and mostly automated processes have been introduced to yield not only the code but also the configuration data for the DEVS/SOA platform, so as to produce a DEVS/SOA simulation ready to be executed. In its present form, the approach only produces the core skeleton of Java classes that implement DEVS models. Work is in progress to deal with the inclusion of UML-based abstract models that specify the simulation logic too, in order to increase the portion of code that can be derived by use of an automated approach. REFERENCES [AndroMDA] AndroMDA project website, http://www.andromda.
org/. [ArgoUML] ArgoUML project website, http://argouml.tigris.org/.
[ATLAS] ATLAS Transformation Language project website, http://www.eclipse.org/m2m/atl/
[Bendre and Sarjoughian 2005] S. Bendre and H.S. Sarjoughian, Discrete-Event Behavioral Modeling in SESM: Software Design and Implementation, Advanced Simulation Technology Conf., San Diego, CA, 2005, pp. 23-28.
[Choi et al. 2006] KeungSik Choi, SungChul Jung, HyunJung Kim, Doo-Hwan Bae and DongHun Lee, UML-based Modeling and Simulation Method for Mission-Critical Real-Time Embedded System Development, IASTED Conf. on Software Engineering 2006, 2006, 160-165.
[D’Ambrogio et al. 2009] A. D'Ambrogio, A. Barbaccia, L. Sangemi, “A Model-driven Approach for the Development of DEVS/SOA-based Simulation Systems”, Technical Report RI.02.09, Software Engineering Lab, Dept. Computer Science, University of Roma TorVergata, Roma, Italy, July 2009.
[DEVS/C++] DEVS/C++ Reference Guide, available at http://www.acims.arizona.edu/SOFTWARE/
[EMF] Eclipse Modeling Framework Project website, http://www.eclipse.org/modeling/emf/.
[Janousek et al. 2006] Vladimir Janousek, Petr Polásek and Pavel Slavícek. Towards DEVS Meta Language. ISC 2006 Proceedings. Zwijnaarde, BE, 2006, pp. 69-73.
[Joualult and Kurtev 2006] F. Jouault and I. Kurtev, On the Architectural Alignment of ATL and QVT. In: Proceedings of the 2006 ACM Symposium on Applied Computing (SAC 06). ACM Press, Dijon, France, chapter Model transformation (MT 2006), pages 1188–1195. 2006.
[MDA] Object Management Group, MDA Guide, version 1.0.1, June 2003.
[Mellor et al. 2003] Model-driven development, IEEE Software Special Issue, S.J. Mellor, A.N. Clark, T. Futagami (eds.), vol 20, n. 5, September 2003.
[Mittal et al. 2007] Saurabh Mittal, José L. Risco-Martín and Bernard P. Zeigler. DEVSML: Automating DEVS Execution Over SOA Towards Transparent Simulators. DEVS Symposium. Spring Simulation Multiconference. Norfork, Virginia, 2007, pp. 287-295.
[Mittal et al. 2009] Mittal, S.; Risco-Martín, J. L. & Zeigler, B. P. DEVS/SOA: A Cross-Platform Framework for Net-Centric Modeling and Simulation in DEVS Unified Process SIMULATION: Transactions of SCS, 2009, 85, 419-450
[MOF] Object Management Group, Meta Object Facility (MOF) Core Specification, version 2.0, January 2006.
[MOF-QVT] Object Management Group, Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification, version 1.0, April 2008.
[oAW] openArchitectureware, an MDA/MDD generator frame-work, http://www.openarchitectureware.org/.
[Parr and Keith 2003] Parr, S., and Keith, R., The Next Step – Applying the Model Driven Architecture to HLA, Proceedings of the 2003 Spring Simulation Interoperability Workshop, 2003, 03S-SIW-123.
[Posse et al. 2003] E. Posse, J.S. Bolduc and H. Vangheluwe, Generation of DEVS modelling and simulation environments, Proc. of the Summer Computer Simulation Conference, Student Workshop, SCS, July 2003. Montréal, Canada.
[QVT] Object Management Group, MOF 2.0 Query / View / Transformations Request for Proposals, April 2002.
[Risco-Martín et al. 2007] José L. Risco-Martín, Saurabh Mittal, M. A. López-Peña and J. M. Cruz. A W3C XML Schema for DEVS Scenarios. DEVS Symposium. Spring Simulation Multiconference. Norfork, Virginia, 2007, pp. 279-286.
[Risco-Martín et al. 2009] Risco-Martín, J. L.; Mittal, S.; Cruz, J. M. & Zeigler, B. P. eUDEVS: Executable UML Using DEVS Theory of Modeling and Simulation SIMULATION: Transactions of SCS, 2009, 85, 750-777
[Tolk and Muguira 2004] Andreas Tolk and James A. Muguira, M&S within the Model Driven Architecture, Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC), December 2004, Paper 1477.
[UML] Object Management Group, Unified Modelling Language Superstructure, version 2.2, February 2009.
[XMI] Object Management Group, XML Metadata Interchange (XMI) Specification, version 2.0, May 2003.
[Zeigler et al. 2000] Zeigler, B. P.; Kim, T. & Praehofer, H. Theory of Modeling and Simulation: Integrating Discrete Event and Continuous Complex Dynamic Systems Academic Press, 2000
[Zeigler and Sarjoughian 2005] B.P. Zeigler, H.S. Sarjoughian, Introduction to DEVS Modeling and Simulation with JAVA: Developing Component-Based Simulation Models, January 2005, http://www.acims.arizona.edu/SOFTWARE/
[Zinoviev 2005] D. Zinoviev, Mapping DEVS Models onto UML Models, DEVS Symposium, Spring Simulation Multiconference, San Diego, CA, April 2005, 101-106.