LWiSSy: A Domain Specific Language to Model ...

LWiSSy: A Domain Specific Language to Model Wireless Sensor and Actuators Network Systems Priscilla Dantas, Taniro Rodrigues, Thais Batista UFRN – Universidade Federal do Rio Grande do Norte Natal,Brazil {pridnt, tanirocr, thaisbatista}@gmail.com

Flávia C. Delicato, Paulo F. Pires

Wei Li, Albert Y. Zomaya

UFRJ – Universidade Federal do Rio de Janeiro Rio de Janeiro,Brazil {fdelicato, paulo.f.pires}@gmail.com

University of Sydney [email protected], Sydney, Australia [email protected]

Abstract—Wireless sensor and actuator network systems (WSAN) are built on a broad range of sensor platforms and low level programming languages. Such systems are potentially useful for a myriad of applications, from different domains. Thus, developers need to deal with details of different platforms and programming abstractions of sensor operational systems, and they also need to have specific knowledge on the distinct domains. In this context, we propose LWiSSy, a domain specific language (DSL) to model WSAN systems whose main goals are to allow (i) domain experts to directly contribute in the development of WSANs without having knowledge on low level sensor platforms, and (ii) network experts to program sensor nodes to meet application needs without having specific knowledge on the application domain. We describe how to develop WSAN systems using LWiSSy and analyze the impact of its usage through an experiment. Index Terms—Wireless Sensor and Actuator Network, Domain Specific Language

I. INTRODUCTION Due to recent technological advances in microelectronics and wireless networks technologies, Wireless Sensor and Actuator Networks (WSANs) have become technically and economically feasible and have great potential to extend their applications in our daily lives. WSAN systems were normally designed from scratch targeting on a single application with the main goal of ensuring efficient energy consumption. Due to this design trend, developers were required to have sound knowledge of both the application domain and the underlying sensor platform. Additionally, no formal or systematic methodology can be adopted during the system‟s development process, this makes the WSAN system design is highly-dependent on the specific hardware and the target application, which is even harder to maintain, modify, and reuse. Nowadays, several approaches have been proposed to solve the aforementioned issue. One particular approach is beginning to draw researchers‟ attention, which aims to build a large scale WSAN for different applications that can be run, simultaneously or not, in the network nodes; this kind of network is known as Shared Sensor Networks[1]. The approach of designing specific networks for a target application has been replaced by a general-purpose network design, where the

sensing and communication infrastructure is shared by different applications [1]. In this new approach, WSAN nodes must be programmed for each application, preferably by using highlevel interfaces that abstract the underlying platform and allow developers to build applications using languages they are more familiar with. It is important to enable domain experts‟ participation during the development process of WSAN applications and to decouple the application design from the underlying network infrastructure. It is also essential to allow the optimization of the generated application considering the WSAN resource constraints. Several works [3], [10] have pointed out the close relationship between application requirements and WSAN performance, and demonstrated that application-specific optimization can increase overall system performance, mainly regarding the energy consumption. Such optimization often requires handling low level features, such as the data delivery model or network topology, thus generating a tradeoff between the high abstraction level desired by the domain experts and the optimization level desired by the network experts. Furthermore, there are different granularity levels for WSAN programming, encompassing the high level process specification (describing a sensing application in terms of data or control flows – macroprogramming) and the individual processing ( realized in only one network node – micro-programming). Considering these granularity levels, we identify different abstraction levels in terms of users‟ requirements that directly impacts on the software optimization capacity. In this context, we propose LWiSSy (Domain Language for Wireless Sensor and Actuators Networks Systems), a domain specific language (DSL) to design WSAN systems. LWiSSy is part of the MDA (Model-Driven Architecture) infrastructure proposed in [7]. Such MDA infrastructure allows organizing WSAN systems into abstraction levels dependent or not on the sensor platform. The design of each level is in charge of their respective expert. Other DSLs were proposed for this context [5],[8],[9], but they do not encompass all requirements addressed by LWiSSy, such as support for actuators, WSAN protocols and more than one application simultaneously running in a system. Moreover, LWiSSy has expressivity enough to encompass a wide range of application domains and to allow optimization of the WSAN operation. During the

language development, legibility was considered a key feature in LWiSSY in order to facilitate the domain experts‟ contribution to the development process without requiring from them in-depth knowledge on WSAN technical specificities. This paper is organized as follows. Section II provides background on DSLs. Section III presents LWiSSy and an illustrative example describing the development of WSAN systems using it. Section IV describes the evaluation performed to assess language features. Section V gives an overview on related works and Section VI presents our final remarks.

A. Meta-model LWiSSy meta-model represents the design dimension and it is organized in three views: structural, behavioral, and optimization. Each view includes components to design applications according to the needs of both the specification granularity and expert profile dimensions.

II. DOMAIN SPECIFIC LANGUAGES DSL is a language that offers a power of expressiveness focused in a particular problem domain[2]. A domain is a restricted area of interest, a concrete point of view or a family of related products characterized by a set of terminologies and concepts. The language definition requires a meta-model construction, which is able to capture common points and domain variables. This meta-model defines the language structure and formation rules to be used to express the models. The high abstraction level provided by DSLs allows domain experts to directly contribute during the system development process. In this way, domain experts can understand, validate, and even develop DSLs. Changes in application requirements are also quickly performed by experts since it is only necessary to make a modification in the specific part of the model affected by the change [2]. DSLs increase the productivity, confidence, maintenance, and portability due to the reduced and easier way to program when compared with general purpose languages (GPLs). III. LWISSY LWiSSy is a DSL which considers three dimensions in the WSAN systems development: (i) developer profile (domain or network expert), (ii) specification granularity (network, node groups or single node programming) and (iii) design (structural, behavioral, and optimization). The need of managing the existing tradeoff between application prototyping cost (domain experts) and optimization capacity (network experts) was a driving factor when designing LWiSSy. To accommodate this need, LWiSSy encompasses three different graphic models. The option of using only one graphical model in the DSL design would produce models where both behavioral and structural features would be tangled, thus hampering the application modeling once the elements used to express structural concepts are semantically different from those used to express behavioral concepts. LWiSSy meta-model is specified using the Eclipse Modeling Framework (EMF1), a framework for building tools and other applications based on a structured data model; and the Graphical Modeling Framework (GMF2), a framework that provides a generative component and runtime infrastructure for developing graphical editors.

1 2

http://www.eclipse.org/modeling/emf http://www.eclipse.org/gmf

Fig. 1. Structural meta-model

The first view (Fig. 1. ) is composed of structural components encompassing WSAN structural features. It is used by domain experts and deals with network and node groups programming. This view defines which and how many resources (the Resource element) and regions (the Region element) belong to the WSAN being modeled (the WSANSystem element). Additionally, it is possible to specify which and how many applications (the Application element) may be executed per each node group, thus enabling modeling of shared sensor networks. The communication between different node groups is made by the WirelessLink element. A Region defines a place where a set of nodes (the NodeGroup element) will be physically deployed close to each other. Applications (the Application element) are run by the node groups (the providedApp connection). These applications can be executed by all nodes in the group or only by a sub-set of them (the nodesQuantity attribute). It is possible to define the life span per each node group (the lifetime attribute). The value of this attribute will determine the energy policy adopted by the application. Node groups can use some type of resource (the usedResource connection), such as temperature sensors, USB ports and others. Only sink nodes can use Port resources to connect them with base stations. Sensor nodes can use Sensor or Actuator as resources. A sensing node can contain more than one Sensor resource (representing the several type of sensing devices). Nowadays, integrating multiple sensing devices on the same sensor node is a design choice that can reduce hardware cost because the sensing units can share the same computation and communication components. The Application element has the dataAccuracyRange attribute which deals with an important QoS requirement in WSAN, namely the data accuracy required by applications. Its value guides the decision on which communication protocol will be used, since different protocols provide different QoS guarantees. Such attribute assumes values between 0 and 1, where 0 means that data accuracy is not important to the application (i.e. smart home and environmental monitoring) and 1 means data accuracy is a critical requirement (i.e. petrochemical industry monitoring applications). It is important to note that there is a tradeoff between lifetime

anddataAccuracy attributes, once these features are conflicting in WSAN applications. So, it is not possible to set both of them for their maximum values.

Fig. 2. Behavioral view of LWiSSy meta-model

The second view (Fig. 2. ) defines behavioral elements intended to be used by domain experts. It deals with programming of node groups and single nodes and it is responsible for designing the WSAN application behavior. InitialState is the DSL element that starts an application. An application is composed of activities (the activityconnection). Each activity (the Activityelement) can use resources (the usedResourceName attribute), which were defined in the first view. Moreover, a timer (the finalTimer attribute) that is triggered at the end of the activity may be defined. This timer can be seen as a mandatory delay that occurs in the end of the activity. During the timer definition, the expert needs to choose its type. If he/she chooses a continuous timer, it will be triggered every time the activity happens. If he/she chooses one shot timer, it will be triggered just in the first time the activity happens. An activity can be an Action, a Fork, a Choice or a Join. The Action element represents functionalities performed by the application, which can be messaging (the Send element), radio configuring (the RadioConfig element), LEDs (LightEmitting Diode) managing (the LED element), data aggregating (the Aggregation element) or other basic action (the Common element), like sensor data reading or message display. The Fork element splits application‟s main flow into two or more parallel flows. The Join element joins parallel flows in a single flow. The Choice element defines application‟s main flow considering the result of the guard attribute. The last element is FinalState, which indicates the end of the application flow. An application must have only one initial state, but it can have several final states according to its behavior. According to the structural view, each node group can run one or more applications (Application element), this feature allows LWiSSy to design Shared Sensor Networks. So, it is necessary to design a behavioral graphic model instance per each application. The model generated by the behavioral view is similar to an activity diagram since its goal is to describe the system behavior. Other diagrams could be used, such as the state or sequence diagram. However, state diagrams model a single node behavior while the activity diagram outlines the application general behavior and domain experts are more interested in designing the application considering the general context.

The last view (Fig. 3. ) defines optimization elements and it is targeted to network experts. It deals with the network structural dimension encompassing WSAN specific features, such as network protocols. However, it is important to mention that modeling details of protocols‟ behavior is out of scope of our work. Through this view, network experts can determine which transport protocol (the transportProtocol attribute) (if any) is used in the WSAN system (the System element), besides routing (the routingProtocol attribute) and communication between nodes (the communicationProtocol attribute) protocols. In addition, the network expert can access GroupOfNodes to define which types of sensor nodes are used by them (the nodesType attribute). If he/she chooses a SPOT sensor, the Sun SPOT platform is used, in other words, this choice will influence the platform to be used. Furthermore, the expert must define the maximum latency (the latency attribute) allowed per application.

Fig. 3. Optimization meta-model

B. Illustrative Example: WSAN Systems Development using LWiSSy In this section a simple WSAN system will be designed with LWiSSY to illustrate the steps of the development process and highlight the DSL features. The described system is the same that will be used in the conducted experiment (Section IV). The goal of the system is to control LEDs in WSAN nodes according to the local temperature in a forest, and to trigger an alarm if it is necessary. The system illustrates a simplified version of a WSAN for fire detection in forest. Whenever the temperature in the monitored environment is higher than 40ºC, a red LED is turned on in the nodes and they send a message to a sink node, which triggers a sound alarm. Otherwise, neither the LED is turned on nor the alarms are triggered. Initially, the domain expert needs to design the structural part of the system. The expert specifies, by using LWiSSy structural view, all the network structural components and links them together (Fig. 4. ). In this case, the expert is dealing with the network and node groups programming (macro level). In this WSAN system, named DetectionSystem, two regions were defined. SensorNodesRegion is composed of sensor nodes deployed in the environment and SinkNodeRegion is composed of a sink located in a remote place. SensingNodes is a group composed of 30 nodes. SinkNode is a group composed of only one node. The first group has sensor resources named TemperatureSensor and the second has an actuator resource named AlarmActuator. Finally, two applications, TemperatureMonitoring and TriggerAlarm, are designed, one representing the sensing tasks and the other the actuation task.

IV. EVALUATION

Fig. 4. System Structural view specified by the domain expert

After that, the domain expert needs to model the behavioral view to specify the application specific behavior. In this moment, the expert deals with programming at the level of node groups (macro) and single nodes (microprogramming). Fig. 5. (a) shows the behavior of Temperature Monitoring application. The application is divided in five activities. Initially, the radios are configured and the temperature data is collected. In the third activity a message will be sent only if the local temperature is higher than 40ºC. This feature is modeled by the Send component and its PushModelType is EVENT_DRIVEN, where the parameter attribute is if (TemperatureSensor> 40). In addition to the message sending, a red LED is turned on during 5sec. Finally, the LED is turned off and the application returns to the second activity (ReadTemperature). The last model designed by the domain expert defines the behavioral view for TriggerAlarm application (Fig. 5. (b)). The illustrated graphic model encompasses three activities. First, the radio is configured and the sink node waits for the arrival of messages. When a message arrives, the sink triggers an alarm during 10sec and returns to the first activity.

We conducted an evaluation to determine if LWiSSy meets our goals and to assess the complexity and benefits of using it when compared to a general-purpose language used to program WSAN nodes, such as Java ME. A controlled experiment was conducted to analyze the impact of using LWiSSy over the effectiveness of the language to facilitate the comprehension and maintainability of WSAN systems. A. Experiment The goal of the study is to analyze LWiSSy for the purpose of evaluating its effectiveness with respect to facilitate the comprehension and maintainability of WSAN systems. The quality focus is to improve the effectiveness obtained during WSAN systems development and the perspective is Domain and Network Experts. The experiment is performed in a context where participants are students from an undergraduate program in computer science. The experiment material consists of two WSAN systems, designed with LWiSSy and Java ME. The experiment was replicated at two different groups using the same design, procedure, and material. In the remainder, the two groups will be named as Group A and Group B, respectively. TABLE I. provides a concise overview of the main elements of the experiment. TABLE I. OVERVIEW OF THE EXPERIMENTAL DESIGN Goal Context Null hypotheses Main factor Dependent variables

(a)

(b)

Fig. 5. (a)Temperature Monitoring and (b) Trigger Alarm applications‟ behavioral view

Fig. 6. Optimization view for the fire detection system

The last model, optimization view, is specified by the network expert. Several features designed as part of previous models, as lifetime and dataAccuracyRange need to be considered in this model, since they directly affect the choice of the best protocols to be used. This model includes the communication protocol and WSAN topology. After these steps, the system source code is automatically generated using the MDA infrastructure [7].

Evaluating the effectiveness of LWiSSy to facilitate the comprehension and maintainability of WSAN systems. Classroom exercise, systems are analyzed. (1) No effect on effectiveness regarding comprehension. (2) No effect on effectiveness regarding maintainability. Type of languages used; source code (Java ME) vs. graphic models (LWiSSy) Comprehension level and time

Participants. The participants were students from the Software Architecture course, in their last year of an undergraduate program in Computer Science at the Federal University of Rio Grande do Norte. The students previously attended computer networks, programming and software engineering courses. The students had a mixed background; in general they had limited, although similar, knowledge and expertise level in programming, software engineering, and network topics. The sample of participants taking part in the experiment was composed of all students belonging to the course who, on a voluntary basis, agreed to participate to the experiment. Ultimately, the experiment was not mandatory, results were made anonymous for privacy purposes and students were not evaluated on their performance. Material. The experiment was performed on two WSAN systems. The first, Detection System (Section 3.2), was designed using LWiSSy language. The second one, which was built in Java ME, is a demo Sun SPOT application that sends periodic sensor readings measured on one or more Sun SPOTs to an application on a laptop or PC that displays the values. It is composed of two applications: one deployed in sensor nodes and the other in a host computer to which a sink is attached.

The first application periodically samples a sensor value on the sensor node and transmits it to a desktop application where the values are displayed. The second application collects sensor samples sent by the first application running on neighboring sensor nodes and prints them out. Although simple, the systems are realistic enough and can be considered as representative of WSANs. Moreover, both systems have the same complexity and similar network and application features. Hypotheses definition. The research questions this experiment aims at addressing are: RQ1. Does the LWiSSy usage help experts to understand WSAN system design? RQ2. Does the LWiSSy usage affect the time required in the comprehension of the designed systems? Once the research questions are formulated, it is possible to turn them into null hypotheses to be tested in the experimentation: H0c: LWiSSy usage does not significantly affect the comprehension level; H0t: LWiSSy usage does not significantly affect the comprehension time. While the alternative hypotheses are: Hac: LWiSSy usage significantly affects the comprehension level; Hat: LWiSSy usage significantly affects the comprehension time. Variable selection. The dependent variables of our study are the systems comprehension level and the time needed to understand them. The comprehension level was measured by the participants‟ answer in each questionnaire. Once the questions are subjective, they are assessed by the general explanation about the system and keywords. The time needed to answer each question was measured by asking participants to fill-in a proper time sheet (Time metric). Overall, for each system y and participant P we considered two metrics: (a)Correct Py - whether the answer was correct or not; (b)TimeryP - time required to study the system specification and to answer the question. The main factor in our study is the approach used to express the system: either a traditional approach (Java ME) or our approach (LWiSSy). Design. We adopt a simple experiment design intended to fit two 3-hours lab session. Participants were split in two groups (A and B). Since participants‟ skills were comparable, it was not necessary any particular strategy to ensure that the skills were homogeneously distributed across groups. Each group had a specific session. In the first session, initially, the participants were provided with a system designed in LWiSSy language. Then, they analyzed that system and answered the questionnaire. After that, the other system, designed in Java ME, was analyzed by them. It is worth note that both systems have been designed so that the assignment received by the participants in each group is of comparable difficulty. The second session is similar to the first session, but the systems were provided to the participants in the opposite order. Training. Initially, a WSAN overview was presented to the participants. After that, they were trained to use LWiSSy and Java ME languages with a theoretical lesson (20 minutes) for each language. The trainings were made by video to ensure that the same training could be provided to both Group A and B. Procedure. The experiment was carried out following a well-defined procedure. First, the participants received a short

introduction about the experiment and then they were randomly assigned to either of the two groups. After that, they received the modeled system in the specific language (LWiSSy or Java ME). It was given a free time for them to understand the system and to answer a questionnaire about its functionalities. At the end, they were asked to compile a post-experiment questionnaire in order to gain insights about their behavior during the experiment and to achieve a better explanation about the quantitative results. The questionnaire is composed of nineteen questions. A first group of questions (Q1 through Q8) have the purpose of validating the instrumentation source of the internal validity. The second group of questions (Q9 through Q14) focused on the comparison between the usage of LWiSSy and Java ME languages. The last group of question was about opinion of the participants about LWiSSy and Q13, in special, was devoted to measure the perceived usefulness of LWiSSy. Eventually, the questions are expressed on a Likert scale [6]. Experiment results. Twenty (20) participants (10 for each experiment) took part to the experimentation. The way the material was prepared made difficult and risky a re-assignment on-the-fly. The following subsections report results aimed at answering research questions RQ1 and RQ2. RQ1. Does the LWiSSy usage help experts to understand WSAN systems design? The average percentage of correct answers among all participants was 68% for the system developed using LWiSSy. To test hypothesis H0c, we considered the number of correct and wrong answers given by the participants belonging to the two experimental samples. To assess the answers, we consider a set of keywords and the general system description gave by the participants. Results indicate that the usefulness of LWiSSy depends on the participant background on UML. They also show that people with little knowledge on WSAN do not have problems to understand systems developed with LWiSSy. In general, participants had some difficult in identifying loops and control structures. Considering the overall set of systems and results from both experiments, there is a significant difference between LWiSSy and Java ME: the number of correct answers was significantly higher for LWiSSy than for Java. The average percentage of correct answers among all participants was 48% for the system developed using Java ME. The results indicated that LWiSSy usage can facilitate the WSAN systems comprehension thus helping to improve their maintenance. RQ2. Does the LWiSSy usage affect the time required in the comprehension of designed systems? The participants spent, on average, 12 min to understand the system designed with LWiSSy. To address H0t, we made a comparison between the time spent by participants to describe the system designed with LWiSSy and the time spent by them to describe the system designed with Java ME. Results show that participants analyzing the Java ME specification spent 15% more time than when they analyze the LWiSSy specification. We can conclude that LWiSSy has a positive impact on comprehension time when comparing to Java ME. Threats to validity. A threat to the validity of this case study is how the system comprehension and effort were measured. System comprehension was assessed by asking

questions related to each system (Section 4.1). Our results may be generalized to junior developers, but to draw any conclusions about more experienced developers, empirical studies involving professionals are needed. Furthermore, the small sample size (overall 20 participants) may limit the capability of statistical tests to reveal any effect. To avoid social threats due to evaluation apprehension, students were not evaluated on their performance. Finally, participants were not aware of the experimental hypotheses. V. RELATED WORK Several papers discuss using DSLs for the development of WSAN systems [5], [8], [9]. However, existent work does not promote a clear division between structural and behavioral concepts. Thus, these languages are either very extensive (consequently more generics), in order to include as many features as possible, regarding both network and application, or very simplistic, keeping some important features invariant and consequently becoming very restrictive. Establishing a balance between generality and specificity is a challenge during the DSL project. In this paper we tried to circumvent this drawback. Losilla[5] presents a DSL that helps domain experts to include application level information by using UML models. This DSL was our initial point to build LWiSSy. Initially, some limitations were identified in Losilla meta-model, such as the use of a class diagram to represent the behavioral features and the high level of abstraction used which sometimes do not include important features in WSANs (communication model between sensor nodes, for instance). In order to improve the DSL expressiveness we defined an extension for that DSL which is described in [7]. Such improvements are: (i) Support for data aggregation: with the addition of this concept it is possible to work with large scale„s wireless sensor and actuators networks; (ii) Network topology definition: this feature allows the expert to define which kind of network topology will be used; (iii) Decision component: the DSL became more flexible allowing the expert to define components which deal with decision-making. LWiSSy differs from the DSL proposed in [5], [7] in several aspects. It organizes, by different views, WSAN systems modeling into three views. The use of just one view in previous DSLs hampered the applications modeling and did not support the tradeoff between prototyping cost and capacity of performance optimization. LWiSSy still allows domain and network experts to design their views independently from each other. Moreover, it is possible to define the specific protocol to be used in the WSAN. The last import point is that LWiSSy considers three levels of programming granularity which may have distinct characteristics regarding the used platform or data processing. Shimizu [9] proposes a WSAN system development process including three distinct models. According to the authors, this separation was proposed because in the WSAN systems development, we must be able to (i) develop the prototype in a low-cost way and (ii) modify the prototype in order to optimize the performance and these features cannot be solved by a single model. Although in [9] the built of several models is proposed, such models describe

static features of applications and are not able to describe the applications behavior, which is a crucial feature during the WSAN modeling. Moreover, Shimizu does not consider the participation of experts with different levels of knowledge and skills. Furthermore, the meta-models do not include several low level features, which are very important, such as the communication protocol and network topology. VI. CONCLUSIONS AND FUTURE WORK LWiSSy facilitates the WSAN systems development, increasing the abstraction level and enabling the division of responsibilities between the developers. LWiSSy requires from experts only their specific knowledge. Results of controlled experiment showed that the adoption of LWiSSy led to a better understanding of the systems, in comparison to the use of Java ME. We consider that the obtained results have practical implications. Given that LWiSSy helps in the understanding of systems, project managers could consider using it in the software development process to reduce interpretation mismatches between analysts and developers with the final goal of improving software quality. As future work we intend to make experiments for assessing the development of WSAN applications using LWiSSy compared to the use of other wellknown WSAN programming languages. ACKNOWLEDGMENT This work was partially supported by Brazilian Agencies: CNPq (grants 311363/2011-3, 470586/2011-7, 312383/2012-6, 485935/2011-2, 560266/2010-3, 310661/2012-9), CAPES, INCT in Web Science (CNPq 557.128/2009-9) and FAPERJ. REFERENCES [1]

S. Bhattacharya, et al., “Multi-Application Deployment in Shared Sensor Networks Based on Quality of Monitoring”, RTAS'10, Stockholm, Sweden, April 2010, pp. 259-268. [2] K. Czarnecki, “Overview of Generative Software Development”. LNCS. v. 3566, p. 326-341, 2005. [3] T. He, et al.,“AIDA: Adaptive application independent data aggregation in wireless sensor network”. ACM Trans. Embed. Comput. Syst., Special issue on Dynamically Adaptable Embedded Systems; vol.3, no.2, pp. 426–457, May 2004. [4] N. Juristo and A. Moreno,“Basics of Software Engineering Experimentation”, Kluwer Academic Publishers, Englewood Cliffs, NJ, 2001. [5] F. Losilla, et al., “Wireless Sensor Network Application Development: An Architecture-Centric MDE Approach”, LNCS v 4758, Springer, pp. 179-194, 2007. [6] A. Oppenheim,“Questionnaire Design, Interviewing and Attitude Measurement”, Pinter, London, 1992. [7] T. Rodrigues, et al., “Model-Driven Development of Wireless Sensor Network Applications”. In: Proceedings of the 9th IEEE/IFIP EUC‟11, Melbourne, Australia, 2011. [8] D. Sadilek,“Prototyping Domain-Specific Languages for Wireless Sensor Networks”. In: Proc. of 4th ATEM, 2007. [9] R. Shimizu, et al.,“Model Driven Development for Rapid Prototyping and Optimization of Wireless Sensor Network Applications.”In: Proc. of the 2nd SESENA, Honolulu (2011). [10] S. Tilak, et al.,“A taxonomy of wireless micro-sensor network models”. ACM SIGMOBILE Mobile Computing and Communications Review 2002 April; vol. 6, no. 2, pp. 28-36.