The main goal of our research is to take advantage of Model-Driven Engineering (MDE) techniques to support an architecture-driven development and analysis of wireless sensor networks. As shown in the figure, the A4WSN platform is composed of two main parts:
- modeling environment for describing the architecture of a WSN
- programming framework for accessing the architectural models of the WSN
Modeling environment
The modeling environment exposes three modeling languages for describing specific architectural views of a wireless sensor network:
- SAML - the Software Architecture Modeling Language for WSN
- NODEML - the Node Modeling Language
- ENVML - the Environment Modeling Language
The SAML language focuses on the application layer of the WSN. It is used to break down the application into a set of software entities (e.g., components), to show how they relate to each other, to better reason on their distribution throughout the network, and to reason on the business logic of the WSN.
The NODEML language concerns all the low-level aspects underneath the application layer of the WSN. In this context, stakeholders reason about routing protocols, middleware, hardware configuration of the nodes, etc.
The ENVML language is about the site in the real world where the WSN will be deployed. This viewpoint could be specially useful for developers and system engineers when they have to reason about the network topology, the presence of possible physical obstacles (e.g., walls, trees) within the network deployment area, and so on.
The three proposed modeling languages are linked together via two auxiliary modeling languages in order to create a combined software, nodes, and environmental view of a WSN; these languages are called Mapping Modeling Language ( MAPML ) and Deployment Modeling Language ( DEPML ), and they link together SAML to NODEML and NODEML to ENVML , respectively.
More specifically, MAPML links are used for assigning software components to the corresponding hardware node configuration they will be executed on. Whereas, DEPML links are used for virtually deploying WSN nodes into specific areas within the physical environment. We decided to use those two auxiliary modeling languages for (i) a clear separation of concerns and duties while architecting the WSN (e.g., a software architect can focus on the application layer in the SAML model only, while a system engineer may focus on the nodes configurations in the NODEML model), and (ii) making the used models reusable across projects and organizations (for example, the same nodes configuration defined in a NODEML model can be shared across different applications produced by a software company). The main concepts of each modeling language will be described in the A4WSN section.
Programming Framework
The programming framework provides a set of facilities for supporting the development and integration of either code generation or analysis engines. Each engine is realised as a plugin of this framework. Our proposed programming framework knows at run-time which plugins are installed into the framework, and automatically provides to the user the available target implementation languages or the available analysis techniques.
Code generation and analysis plugins are structurally similar. Basically, an analysis plugin manages analyses for WSN (e.g., coverage, connectivity, energy consumption analysis), instead of a code generation plugin which is tailored to the generation of implementation code conforming to a set of specific target languages. More specifically, in A4WSN the main difference between code generation and analysis plugins resides in their returned output: the main output of a code generation engine can either be a set of source files, or binary packages, whereas the main output of an analysis engine can be a violated property, a counter-example, a set of numerical values, and so on. A detailed description of the programming framework is provided in the Programming Framework section.
The A4WSN platform is generic since it is independent from the programming language, hardware and network topology. Starting from a set of models (each one reflecting a certain WSN viewpoint), the code generation and analysis components can be plugged into the framework for generating executable code or analysis outcomes.