Milan Kabáč
email: milan.kabac@inria.fr

Nic Volanschi
email: eugene.volanschi@inria.fr

Charles Consel
email: charles.consel@inria.fr

An Evaluation of the DiaSuite Toolset by Professional Developers Learning Cost and Usability

Keywords: CR-number [subcategory]: third-level software engineering tools, domain-specific language, learning cost, usability, sensors and actuators

HAL is

Introduction

This paper is an evaluation of the learning cost and usability of an existing design-driven, tool-based approach, called Dia-Suite [START_REF] Bertran | DiaSuite: a Tool Suite To Develop Sense/Compute/Control Applications[END_REF], dedicated to developing applications orchestrating sensors and actuators. This evaluation is a first step for assessing the potential for transferring DiaSuite to the industrial practice of this domain.

The evaluation has been carried out in the context of a French collaborative project, called Objects World, involving five IoT manufacturers and four research labs [START_REF]Objects World project[END_REF]. Objects

Copyright is held by the author/owner(s). This paper was published in the proceedings of the Workshop on Evaluation and Usability of Programming Languages and Tools (PLATEAU) at the ACM SPLASH Conference. October, 2015. Pittsburgh, Pennsylvania, USA.

World aims at building a sustainable ecosystem of Internetof-Things (IoT) stakeholders based upon a nationwide, lowbandwidth radio network, called Sigfox. 1 This network already supports products and services that demonstrate its market potentials. It has been deployed in a number of countries (e.g., France, United Kingdom, Spain, Netherlands) [START_REF]Sigfox Network Operator[END_REF][START_REF] Sigfox | Sigfox continues to expand network coverage worldwide[END_REF]. Sigfox is supported by major players such as Samsung, which integrated the Sigfox network protocol into its ARTIK IoT platform [START_REF] M2m | Samsung Adds SIGFOX Internet of Things Protocol to Its New Samsung ARTIK Platform and Invests in IoT Pioneer[END_REF].

When the Objects World project was being set up, the companies involved knew from their experience how much software development is a bottleneck to realize the full potential of IoT. In fact, this domain is just emerging from an industrial viewpoint. While extensive work has been devoted to the infrastructure of IoT, such as traffic management and device constraints (e.g., battery life), little effort has been dedicated to the process of developing applications and services [START_REF] Links | The Internet of Things will Change our World[END_REF]. This situation prompted the Objects World consortium to invite a research group specialising in software engineering to participate to the project and bring tools to improve the development process of IoT applications. Hence, our participation to the project.

Our methodology and its supporting toolset, DiaSuite, have been used for developing many successful proof-ofconcept applications in several domains: telecommunications [START_REF] Bertran | A SIP-Based Home Automation Platform: An Experimental Study[END_REF], building automation [START_REF] Bruneau | DiaSim: A Parameterized Simulator for Pervasive Computing Applications[END_REF], avionics [START_REF] Enard | Design-driven Development of Dependable Applications: A Case Study in Avionics[END_REF], software monitoring [START_REF] Cassou | Leveraging Software Architectures to Guide and Verify the Development of Sense/Compute/Control Applications[END_REF], robotics [START_REF] Cassou | Using the DiaSpec design language and compiler to develop robotics systems[END_REF], and assisted living [START_REF] Caroux | Verification of Daily Activities of Older Adults: A Simple, Non-Intrusive, Low-Cost Approach[END_REF]. The variety of domains successfully targeted by DiaSuite demonstrates the broad applicability of the methodology and tools in various kinds of applications involving sensors and actuators. However, most of these applications were developed in a research setting. Although some specifications were fueled by industrial needs, they were implemented by researchers in our group, not by developers from the industry.

As a first step for assessing the potential of industrial transfer of our technology, we evaluated DiaSuite by soliciting professional programmers from the IoT industry in a usability study. In this paper, we present the results of this work. The contributions of this paper can be summarised as follows.

• By means of a preliminary usability study, we show that the technology can be efficiently transferred to developers in the IoT industry with only half a day of training.

• Further quantitative and qualitative data are provided, including a usability questionnaire and developer interviews to investigate the perceived utility of the tools.

• We sketch the following steps we are currently taking to consolidate these preliminary results into a more complete evaluation of the DiaSuite toolset, including its impact on programmers' productivity and application quality.

DiaSuite

Let us start by introducing DiaSuite and its main concepts. DiaSuite revolves around the Sense/Compute/Control (SCC) architectural pattern [START_REF] Taylor | Software Architecture: Foundations, Theory, and Practice[END_REF]. It is dedicated to the design of applications that interact with their physical and software environment using sensors and actuators. This kind of applications covers the IoT domain, but also several other domains such as robotics, avionics, telecommunications, and assisted living. Following the SCC paradigm, applications can be decomposed into three kinds of components:

• entities interacting with the environment, either as data sources (for sensing entities) or data sinks (for actuating entities);

• contexts: software components refining raw data coming from sensing entities into higher-level "context" information;

• controllers: software components fueled by high-level context information and triggering actions on actuating entities.

An application can be viewed as a directed acyclic graph flowing from sensing entities to actuating entities via context and controller components. For instance, the application in Figure 1 records in a log the events coming from two different sensing entities of a connected door lock: the lock-/unlock events and state information, such as the battery level. The Format context is responsible for unifying information coming from heterogeneous devices within a common data structure called an Event. Events created by this context are forwarded to the Logger controller that is responsible for triggering a Log action on a Logger actuating entity, possibly implemented as a service on top of a file system.

Developing SCC applications is complex because of the number of intertwined aspects to be taken into account by the developer, including heterogeneous devices, communication infrastructure, system APIs, synchronisation, and so on. These aspects force the developer to write a lot of boilerplate code to interact with devices, glue code to interface with various underlying communication and OS technologies, technical code for low-level device coordination, etc. Moreover, this manually-written low-level code tends to introduce platform dependencies in application-level code. DiaSuite [START_REF] Bertran | DiaSuite: a Tool Suite To Develop Sense/Compute/Control Applications[END_REF] provides a domain-specific, tool-based development methodology specifically addressing the SCC paradigm; it covers the complete application lifecycle, as shown in Figure 2. DiaSuite provides a declarative design language dedicated to SCC, called DiaSpec, which consists of two layers: the taxonomy layer and the application design layer. Based on high-level declarations, a compiler called DiaGen, generates application-specific support for the subsequent development phases: implementation, testing, deployment, and maintenance. Let us examine the key phases of DiaSuite from design to maintenance.

Taxonomy design. A domain expert uses the taxonomy layer of the DiaSpec language to classify the entities involved in a given application domain (see label (1) in Figure 2). For each entity, either hardware or software, its data sources and actions are declared, as well as attributes such as a name, a unique identifier or a location. Entities can be grouped into a hierarchy in order to inherit sources, actions, and attributes. This results in a flexible and reusable catalog of entities for a given application domain, abstracting over underlying technologies and implementation details.

Application design. Based on a taxonomy (1), an application architect can use the application design layer of the Dia-Spec language to declare the application components and the possible flows of data connecting them together (2), as has been illustrated in Figure 1. DiaSuite applications are reactive, which means that any computation is initially triggered by data coming from some sensing entity, which activates all the contexts connected to it. To respond to its activation, a context can request extra data from other connected entities or contexts. Thus, both push and pull models of reactive applications are covered. Subsequently, controllers may be activated by the propagations along the reactive chain, and may trigger actions on the actuator entities when needed. Using application-specific code generation, DiaSuite ensures that data only flows along the data flow graph declared during application design. In particular, the implementation of a context or controller cannot retrieve data from components that are not connected to it in the architecture definition; nor can a sensing entity or context push a value to a context or controller that is not connected to it in the architecture.

Implementation support. Given a taxonomy declaration [START_REF]Sigfox Network Operator[END_REF] and an application design declaration (2), the DiaGen compiler produces a Java programming framework customised for the application. This framework contains an abstract class for each declared component: entities, contexts, and controllers. Abstract classes contain both concrete methods supporting the development (e.g., entity discovery), and abstract methods that must be implemented by developers in a subclass with device-specific behaviour -when subclassing entities (4) -and with application logic -when subclassing contexts and controllers [START_REF] Bangor | An Empirical Evaluation of the System Usability Scale[END_REF]. Thus, the generated framework guides the implementation of all the components, by requiring the developer to implement the abstract methods, and facilitates programming via the generated concrete methods.

Testing support. Given a taxonomy declaration (1), DiaGen also produces simulation support [START_REF] Bertran | A SIP-Based Home Automation Platform: An Experimental Study[END_REF] for every entity, in the form of a concrete class implementing a "mock" entity, containing methods to simulate each possible activity of a device, such as pushing data from a sensing entity or making some data available for subsequent pulls. This support allows a complete testing of an SCC application before deploying it on a real infrastructure of sensors and actuators. With no code changes in the application, the mock devices can be gradually substituted by real devices. Similarly, support is generated for testing entity implementations (also called drivers) before any application is developed on top of them.

Deployment platform. Finally, given a taxonomy declaration (1) and an application design declaration (2), the backend of the DiaGen compiler produces a runtime layer dedicated to a given deployment platform [START_REF] Bertran | DiaSuite: a Tool Suite To Develop Sense/Compute/Control Applications[END_REF]: it can be local (e.g., OSGi) or distributed (e.g., WebServices). This support allows application developers to abstract over how communications between components are implemented. It also allows applications to be deployed in an already running platform, reusing available entities. Thus, the implementation of entities is typically deployed independently of applications: deploying an application simply consists of deploying its context and controller components, reusing the already installed entities, possibly shared with other applications.

Maintenance support. There is no specific code generated by DiaGen for supporting the maintenance of an application. Rather, maintenance is supported by automatically regenerating all the pieces of code mentioned above, whenever the taxonomy or the application design are modified. The separation of generated code, provided as abstract classes, from developer-supplied code, as separate sub-classes, enables a smooth update of the generated code. Typically, following a design change, the developer-supplied code has to be adapted to conform to the regenerated code API. During this maintenance process, developers are guided by the Java builtin type checker that points at the code locations needing changes. Thanks to the integration of DiaSuite into the Eclipse IDE [START_REF]The Eclipse Foundation[END_REF], most of the time, the needed changes are available as suggested editing actions (e.g., adding a method parameter or changing a type).

Experimental Evaluation

In this section, we present the evaluation of DiaSuite, which was carried out by means of a usability study, questionnaires and interviews. We give details about the different stages of the user study and the results we obtained. Application code, the used questionnaires and the training material are available on the accompanying Objects World website [START_REF]Objects World project[END_REF].

Usability Study Definition

The main goal of the usability study is to evaluate the cost of learning DiaSuite for programmers with various levels of experience. Experimental results are used to validate an upper bound of the learning cost needed for transferring Dia-Suite to professional programmers. The study was carried out on a group of four participants with different levels of experience in software development. Participants were assigned a software engineering task, which involved the design, implementation and testing of an IoT application in DiaSuite. Each participant attended a DiaSuite training session prior to the experiment. The perceived usability of DiaSuite was assessed using questionnaires. Finally, an interview was conducted with each participant to acquire further information on the experience in programming with DiaSuite.

Methodology

Participants. Our study involved four professional software developers with a background in the development of IoT applications and currently working for sensor manufacturing companies. The participants had different level of experience in software development, ranging from 0 to 7 years as depicted in Table 1. The study required the participants to have basic experience in Java programming and the usage of the Eclipse IDE [START_REF]The Eclipse Foundation[END_REF]. Three participants matched these criteria. We also recruited one participant who did not match any of the above stated criteria to examine whether a developer with no prior experience in Java programming/Eclipse usage finds the development support provided by DiaSuite useful and easy to use. It is important to note that for this participant, only data collected from questionnaires and the interview have been taken into account in the evaluation process of DiaSuite.

Training session. The usability study was preceded by a training session to give the participants basics on rapid prototyping of IoT applications in DiaSuite. The training was dedicated to the development of an IoT application revolving around an HVAC (Heating, Ventilation, and Air Conditioning) system. The application development was guided by a Dia-Suite expert, member of our group, and addressed all the development phases from design to testing. The training session lasted approximately four hours.

Object of the study. The study was dedicated to the development of the DoorLocks application presented in Figure 1. The DoorLocks application was specified by Axible Technologies [4], a provider of digital products and services for gate access control. The goal of this application is to remotely monitor instances of electronic door locks, connected to the Internet through an onboard Sigfox transmitter. The features specified were: real-time event logging, abnormal event alerts (stuck or forced door), and low battery state notifications. These features can be implemented by integrating in a DiaSuite application the smart door locks, an email web service, a logging device, and mobile phones for SMS notifications.

Figure 1 shows the architecture of the application. Door locks provide two sensing capabilities: the ""locked"" facet detecting when a door has been locked or unlocked, and the ""state"" facet detecting state changes, such as a door becoming stuck or forced and the battery level. The Format context component is triggered by any event coming from a door lock. The two kinds of sensors do not provide the same information, but the Format context builds a uniform Event structure. Event structures are received by the Logger controller component, which forwards them to the Logger device. Thus, the Format context together with the Logger controller completely implement the feature of real-time event logging. A separate data flow, going through the Battery context and the MailNotifier controller implements the low battery notification feature: the Battery context parses the events coming from the state sensor of the door locker, selects those concerning a low battery state, and forwards them as a concise string to the MailNotifier controller. This latter controller reformats these compact messages in more explicit textual form, producing a complete e-mail message for a pre-defined e-mail address -the service ensuring general maintenance of the door locks. Finally, a third data flow going through the Alert context and the SmsNotifier controller implements the critical conditions notification feature: whenever a stuck or forced door is detected, an SMS is sent to a predefined cellphone number, for urgent intervention.

Following the training session, the software engineering task evaluated in the study comprised the design, implementation and testing of this application. All the participants had precisely four hours to complete the task. Participants had access to the training material, the online help of DiaSuite and Eclipse, but no internet access was provided. At first, participants were asked to establish the design of the application. We enforced a limit of 30 minutes for this phase, with the possibility for us to provide a correct design after this period, in case the produced design was too complex or incorrect. This limit was imposed to avoid compromising the measurements of the subsequent phases.

Then, all the functionalities had to be implemented and tested one by one. The implementation of a specific functionality had to be validated via unit tests, which were given to the participants prior to the task assignment. An application functionality was considered complete upon the successful execution of the corresponding tests. Participants who provided a valid application design were allowed to redefine their design if needed during the study.

Questionnaires. Participants filled out a first questionnaire assessing their experience in software development, Java programming and the usage of the Eclipse IDE. A standard System Usability Scale (SUS) [START_REF] Brooke | SUS: a "quick and dirty" usability scale[END_REF] questionnaire and a custom DiaSuite evaluation questionnaire were handed out to the participants at the end of the study.

Interviews. The interviews with the participants were conducted to collect further information on the DiaSuite programming experience and to discuss the software development process and support currently used by these companies. We also discussed the possibility of programming IoT applications with DiaSuite.

Experimental Results

The experimental results of the development task assigned to the participants are given in Table 1. The first two columns give the participants' experience in Java programming and the usage of Eclipse in years. The next four columns give the time it took for each participant to complete the design phase, respectively the coding of each of the three application features, in minutes. The last two columns give the size of the code of the completed application, and the percentage of the manually written part. As the participant Dev0 has been included only for the questionnaire and interview, his development times were not measured (he was assisted to complete them, to sample the DiaSuite functionalities). The other participants are generically called Dev1 to Dev3, in order of increasing experience in Java/Eclipse. The last participant is a DiaSuite expert in our research group, used as a baseline for the development times.

From Table 1, we can see that the design phase lasted between 15 and 30 minutes for all the participants. To achieve our 30-minute time limit for this phase, we had to fix the design for only one participant, namely Dev2; his design was 80% correct and the corresponding time in Table 1 is marked by an asterisk.

Globally, the first feature of the DoorLocks application took most of the time to develop. This is due to the fact that participants changed the application design and returned back to the implementation more than once when working on the first feature. Also some helper classes had to be created only once for all the features. One participant did not finish the last feature on time. 89% of the the final application code was generated by the compiler for all the participants.

Overall, data in Table 1 constitutes a preliminary validation of our hypothesis that the initial cost of learning DiaSuite, before starting to code real-world applications, is roughly half a day. Indeed, after such a training, two developers out of three completed the design phase, and the third one completed it at 80%; this represents an average completion rate of 93%. As for the implementation and testing phase, 89% (i.e., 8 out of 9) of the application features were correctly developed and tested. Moreover, DiaSuite appears easy to learn for developers with various levels of experience in Java and Eclipse, ranging from 1 to 7 years.

Questionnaires. The pre-experiment questionnaire revealed that three out of four participants used to define their software architecture in an informal way on a piece of paper and were skeptical about the utility of tools dedicated to software architecture and code generation. Only one participant had a positive opinion on the usefulness of such tools and used to define his software architecture via UML diagrams. Two participants had a prior experience with code generation tools, such as Rational Rose [START_REF] Ibm | Rational Rose family[END_REF], AndroMDA [START_REF] Andromda | Generate components quickly with AndroMDA[END_REF] and ArgoUML [START_REF] Argouml | Welcome to ArgoUML[END_REF]. The post-experiment SUS questionnaire revealed that experienced developers found DiaSuite more usable than developers with little or no experience in Java/Eclipse programming. Interestingly, Dev2 and Dev3's SUS questionnaires revealed an identical usability score of 67,5 points. Dev0 and Dev1 scores were 62,5 and 57,5 respectively. The overall SUS score of 63,75 indicates a usability level in the middle between OK and GOOD, which makes DiaSuite a candidate for continued improvement to reach high acceptability [START_REF] Bangor | An Empirical Evaluation of the System Usability Scale[END_REF]. The post-experiment DiaSuite questionnaire investigated the perceived level of complexity related to design, implementation and testing in DiaSuite, as well as the usefulness of DiaSuite for coping with challenges in development of IoT applications presented earlier. The questionnaire revealed a unanimity on the application design being easily defined using DiaSuite. Also, three out of four participants found testing applications in DiaSuite easy. Two participants (Dev3 and Dev0) considered the implementation phase easy, while the remaining ones had a neutral opinion. The usefulness of DiaSuite for coping with heterogeneous APIs of smart objects has been confirmed by all participants. Three out of four participants confirmed that DiaSuite is useful for rapid prototyping of IoT applications, thanks to the generated code support, which also greatly facilitates application testing. Half of the participants agreed that DiaSuite can be useful for rapid evolution of applications, although the experiment did not involve this task. Interestingly, the participant having a positive opinion about software architecture tools prior to the experiment, considered DiaSuite useful for the design of IoT applications. In contrast, the rest of the participants kept a neutral opinion. The questionnaire also revealed that DiaSuite-generated code was considered useful by three participants. This is a positive outcome of the experiment because only one participant found code generation tools useful prior to being exposed to DiaSuite. Finally, participants expressed a unanimous appreciation of the integration of DiaSuite with Eclipse.

Interviews. In the following, we present key comments of our participants on various aspects of DiaSuite. We asked the participants about their assessment on the development process in DiaSuite. One participant stated: "Once the design is established, a big part of the work is already done". Another participant compared the design phase in DiaSuite with UML: "DiaSpec appears to be simpler since it is more abstract. UML is much closer to the programming language". When asking participants about how DiaSuite could be used in their companies, one participant stated: "It could be useful to cross multiple data sources when increasing the number of products. We could provide a solution by rapidly combining the different products we have, even with products from different manufacturers in an heterogeneous environment".

We also asked participants what they think about the transfer of DiaSuite to industry. A participant stated: "It's difficult to move to a new technology when you already master a more "traditional" one". Another participant proposed to improve DiaSuite as follows: "The integration of DiaSuite with the Java EE platform and the Spring framework [START_REF]Spring framework[END_REF] would be a great asset".

Threats to Validity

In this section we review the threats to the validity of our usability study results and the measures we took for avoiding them as much as possible.

Construct validity. These threats concern the adequacy of the experimental setup for measuring the desired outcome.

The training required participants to develop a minimal application, called HVAC, that regulates the temperature of a room. As a result, one concern is whether this application ressembles the one they have to develop autonomously. If they were similar, the participants could program the Door-Locks application by imitation based on the HVAC example, possibly without really understanding DiaSuite. To address this threat, we intentionally introduced many differences in the DoorLocks application, including greater size (three times more components and three times more features) and several important differences in the interaction contracts, addressing typical pitfalls of a superficial assimilation of DiaSuite. This definitely prevented participants from programming by imitation.

As a downside, these subtleties increased the risk for the participants to get lost during the design phase, and potentially end up with a design more complex than necessary. As the implementation is partially generated from the design, this increased the risk of not finishing the implementation on time. Thus, verifying the design ability could have compromised verifying the implementation ability, while both abilities are complementary indicators of a correct DiaSuite assimilation. To address this second construct threat, we introduced the time bound of 30 minutes for the application design.

Internal validity. These threats concern factors other than the control variables, which may influence the output variables.

In our case, one potential perturbation could come from discomfort with the assigned workstation, as compared to the participant's usual computing environment, because of a different operating system, for instance. To avoid this threat, we asked participants to come with their own laptop computer, and installed DiaSuite on their machines.

External validity. These threats are factors that may invalidate the generalisation of our result. The intended scope for our result is the industrial prototyping and development of IoT applications. This is why we selected the participants among professional developers within companies addressing the smart objects market. The first issue is that professional developers are a scarce resource for research experiment. This is why we could only include 4 participants, among which one participated just in the questionnaire and interview parts. The generalisation of our result is thus limited by the representativeness of this very limited population sample. To mitigate this threat, we recruited the participants with various levels of experience, ranging from 0 to 7 years of experience in Java/Eclipse development project. This makes our result more likely to be generalised, but still constitutes only preliminary data, to be confirmed by a larger experiment.

Another external threat concerns the size of the software engineering task under test. Four hours of development is not negligible, but is small in comparison with a real-world development. Nevertheless, application prototyping is a very common task for sensor and smart object manufacturers, as confirmed by our interviews.

Finally, usability studies are frequently externally threatened by the fact that they occur in a closed world, where participants are isolated from the interruptions they handle every day in the real world. To alleviate this threat, we only isolated them during the training, but allowed some amount of interruptions during the development exercise. For example, one participant handled a phone call during 15 minutes, and another participant was preempted for a (real) work meeting in another room during 25 minutes.

Related Work

Languages and tools for sensor/actuator applications. Several other approaches than DiaSuite provide languages and tools for developing applications dealing with sensors and actuators, including IoT applications. For instance, several dedicated languages for describing smart object APIs and features have been defined, such as DomoML for the home automation domain [START_REF] Miori | Home Automation Devices Belong to the IoT World[END_REF] and the Puzzle building blocks [START_REF] Danado | A Mobile End-User Development Environment for IoT Applications Exploiting the Puzzle Metaphor[END_REF]. Some approaches provide graphical tools for composing applications out of modules, either by developers in Reactive Blocks [START_REF] Kraemer | Creating Internet of Things Applications from Building Blocks[END_REF], Dioptase [START_REF] Billet | Dioptase: Data Streaming Middleware for the Internet of Things[END_REF], and Compose [START_REF] Raggett | COMPOSE: An Open Source Cloud-Based Scalable IoT Services Platform[END_REF], or by end users in Puzzle [START_REF] Danado | A Mobile End-User Development Environment for IoT Applications Exploiting the Puzzle Metaphor[END_REF]. Boilerplate code for integrating reactive application modules is generated for instance in Reactive Blocks from UML component descriptions [START_REF] Kraemer | Creating Internet of Things Applications from Building Blocks[END_REF]. Support for testing IoT applications on simulated devices is provided by the Cooja network simulator [START_REF] Eriksson | COOJA/MSPSim: Interoperability Testing for Wireless Sensor Networks[END_REF], [START_REF] Osterlind | Cross-Level Sensor Network Simulation with COOJA[END_REF]. Tool support for maintenance of IoT application is provided in tools such as PervML [START_REF] Serral | Towards the Model Driven Development of Context-aware Pervasive Systems[END_REF].

While these approaches present several similarities with the DiaSuite approach, none of them generates, starting from a device taxonomy and a specific application design, a customised programming framework that both guides and constraints the developer during all the application lifecycle, namely design, implementation, testing, deployment, and maintenance. We refer the reader to an existing paper [START_REF] Bertran | DiaSuite: a Tool Suite To Develop Sense/Compute/Control Applications[END_REF] for a more detailed comparison between DiaSuite and related approaches. On the other hand, we are not aware about empirical studies on these approaches involving professional developers, aimed at assessing learning cost and usability.

Experiments on using tools supporting software development. Vogel-Heusen [START_REF] Vogel-Heuser | Usability Experiments to Evaluate UML/SysML-Based Model Driven Software Engineering Notations for Logic Control in Manufacturing Automation[END_REF] presents a usability study and seven usability experiments for evaluating the use of UML to increase the efficiency and quality in designing and maintaining software for manufacturing systems. Both generic UML versions such as UML 2.0 and domain-specific dialects such as SysML-AT are considered. A number of interesting aspects about experiment design are discussed. Maeder and Egyed [START_REF] Mäder | Do developers benefit from requirements traceability when evolving and maintaining a software system[END_REF] present a controlled experiment to measure the benefits of a source code navigation tool able to trace requirements, when used in software comprehension and software maintenance tasks. Hanenberg et al. perform controlled experiments to measure the benefits of using Aspect Oriented Programming (AOP) tools for developing crosscutting concerns. A more general overview of controlled experiments in software engineering can be found in a survey by Sjøberg et al. [START_REF] Sjoberg | A Survey of Controlled Experiments in Software Engineering[END_REF]. According to their classification, our software engineering experiment has the following features: the task category is Create, with subcategories Design and Coding; the number of subjects falls in the Small category, professionals only; the task duration falls in the Large category; globally, the experiment size is then considered as Medium.

Finally, let us contrast this work with other works evaluating the usability of IDEs for developers, for instance those using various visual languages [START_REF] Rouly | Usability and suitability survey of features in visual ides for non-programmers[END_REF]. First, DiaSpec is a textual language, although the application architecture can be visualised as a graph (see Figure 1). More importantly, our study investigates the usability of DiaSuite's approach, not of its IDE in particular. Indeed, DiaSuite is integrated most naturally within the Eclipse IDE, and it does not aim at changing the usability of Eclipse.

Conclusion

This section discusses some important lessons we learned during our experiments.

Learning cost. The usability study constitutes promising preliminary evidence that the DiaSuite tools can be efficiently transferred to professional developers in the IoT domain. Indeed, with a minimal learning cost of half a day, developers are able to rapidly develop a typical prototype application.

Need for further experiments. A larger study is needed to confirm these findings on a statistically representative population, and to cover all the development phases addressed by DiaSuite, including the deployment and maintenance phases. Additionally, the impact of DiaSuite on programmers' productivity and application quality also needs to be evaluated. For this purpose, within the ObjectsWorld project, we are currently developing 10 small but representative industrial applications with DiaSuite, each of them deployed on thousands of sensors and actuators. As it is difficult to precisely measure programmers' productivity and application quality, we identified 6 key challenges in developing applications in the IoT domain. Using these challenges, we will provide a qualitative evaluation by rating the impact of DiaSuite on each of these challenges in terms of development effort and result quality, for each particular application. These results will hopefully be reported in an article in the coming months.

Another, complementary, experiment we are currently preparing consists in assigning to groups of students small projects of sensors/actuators applications, to be developed twice, once with DiaSuite and another time using direct coding in Java.This controlled experiment will aim at estimating in a quantitative way the impact of DiaSuite on development cost and application quality.

Simple contexts help with the implementation, but may complicate testing. By comparing the different solutions of the developers to the assigned development task, we found that cutting application functionalities into several specialised contexts greatly simplifies the subsequent implementation phase. It also allows developers to anticipate many design decisions and uncover architecture defects earlier in the development process, before coding has even started. At the other end of the spectrum is an application architecture with a unique context, connected to all the data sources, and one controller connected to all actuator actions. This degenerated design leads to complex code, where all application features are intertwined. This architecture style postpones the identification of defects, increasing the cost of fixes. A much lighter version of this design error appeared in the solution of developer dev2, who defined a single controller for two devices which mixed two completely independent application features. The manual and training should therefore be improved by adding some explicit design counter-examples to be avoided, clearly mentioning their drawbacks. However, we found a limit to the benefits of modularisation: when the application architecture graph becomes deeper, the test cases are more difficult to produce. Here, we identified a lack of support in DiaSuite for simulating the output of context modules. This support should be added in a future version of the tools, to further encourage modular application structure.

2 Figure 2 :

 22 Figure 2: DiaSuite tools support for the SCC application lifecycle.

  The graphical view of the DoorLocks application.

		Logger Log	Mailer SendMessage	SMS Sender SendMessage
		Logger Controller	Mail Notifier	SMS Notifier
		Event	String	String
		Format	Battery	Alert
		State	State
			State
		Boolean
		Door Locker locked	Locker Door state
	DiaSpec descriptions	Area Expert Figure 1: Distributed Tester Entity Developer back-end Programming Application Developer framework Simu-lation Entities Appli-cations DiaGen code generator	DiaSpec application
	Application Architect	System Administrator

Table 1 :

 1 Java Eclipse Design Dev. Dev. Dev. Code Man. Experimental results for the DoorLocks development task.

	Developer exp.	exp.		feat1 feat2 feat3	size	part
		(years) (years) (min) (min) (min) (min) (LOC) (%)
	Dev0	0	0	N/A	N/A N/A N/A	N/A	N/A
	Dev1	1	1	30	92	30	-	1671 10.4
	Dev2	3	3	30*	55	15	5	2141 10.7
	Dev3	7	7	27	87	18	9	1724 10.3
	Expert	3	3	15	32	14	6	1760 10.2

http://www.sigfox.com


Claire Mouquet Rivier

Christèle Icard-Vernière

Jean-Pierre Guyot

E Hassane Tou

Isabelle Rochette

Serge Trêche

Mouquet-Rivier Claire

Icard-Vernière Christèle

Guyot Jean-Pierre

Tou El Hassane

Rochette Isabelle

Trèche Serge

Consumption pattern, biochemical composition and nutritional value of fermented pearl millet gruels in Burkina Faso

Keywords: pearl millet, fermented gruel, energy density, nutritional value, phytate, alphagalactosides

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Fermented cereal gruels prepared mainly from maize, sorghum or millet are widely eaten in West Africa [START_REF] Blandino | Cereal-based fermented foods and beverages[END_REF]. In urban areas, they are produced at a small scale in informal micro-enterprises. Gruels are usually prepared in the yard of the homestead by one woman, who is sometimes helped by another member of the family. In Ouagadougou, the gruels are prepared from pearl millet (Pennisetum glaucum) every day, sold in ready-to-eat form with a ladle by the producer just in front of her home or at the local market. In mooré, the language of the Mossi, one of the main ethnic groups of Burkina Faso, the gruels are called ben-kida or ben-saalga, depending on whether pearl millet flour granules are added during cooking or not. Ben-kida and ben-saalga are mainly eaten as breakfast. The processing of pearl millet into ben-saalga or ben-kida has already been described in detail by [START_REF] Tou | Study through surveys and fermentation kinetics of the traditional processing of pearl millet (Pennisetum glaucum) into ben-saalga, a fermented gruel from Burkina Faso[END_REF]. It comprises five main steps: soaking of the grains, milling, sieving, decantation and cooking. Lactic acid fermentation occurs during the decantation step, leading to the final low pH and giving the gruels a sour taste. The processing sequence is very similar to that used to produce other African fermented gruels [START_REF] Blandino | Cereal-based fermented foods and beverages[END_REF][START_REF] Lei | Microbiological characterization and probiotic potential of koko and koko sour water, African spontaneously fermented millet porridge and drink[END_REF]. The nutritional value of these gruels depends on the intrinsic nutritional quality of cereals [START_REF] Mckevith | Nutritional aspects of cereals[END_REF], on the effect of the different processing steps and on the value putatively added by fermentation [START_REF] Chavan | Nutritional improvement of cereals by fermentation[END_REF]. However, the pearl millet used to prepare the gruels is purchased by small producers at traditional retail markets in Ouagadougou. Pearl millet grains are sold as a mixture of genotypes that are not very well identified and whose composition varies with the genotype and the environmental conditions during cultivation [START_REF] Buerkert | Variation in grain quality of pearl millet from Sahelian West Africa[END_REF][START_REF] Ouattara | A comparative study on nutritional and technological quality of fourteen (14) cultivars of pearl millets [Pennisetum glaucum (L) Leeke] in Burkina Faso[END_REF]. Added to variability caused by differences in processing conditions between traditional production units [START_REF] Tou | Study through surveys and fermentation kinetics of the traditional processing of pearl millet (Pennisetum glaucum) into ben-saalga, a fermented gruel from Burkina Faso[END_REF], this can result in variability in gruel composition. Since these gruels are frequently given to young children as complementary food [START_REF] Blandino | Cereal-based fermented foods and beverages[END_REF], a great deal of care has to be paid to their nutritional quality, above all to micro-and macronutrient density and in particular to energy density [START_REF] Trèche | Viscosity, energy density and osmolality of gruels for infants prepared from locally produced commercial flours in some developing countries[END_REF][START_REF] Dewey | Update on technical issues concerning complementary feeding of young children in developing countries and implications for intervention programs[END_REF]. The objectives of our study were first to identify the consumption pattern of the two types of pearl millet gruels in Ouagadougou, and second to characterize the nutritional quality of gruels produced in the field and its variability, in order to assess their suitability as complementary foods for infants and young children.

Material and methods

Collection of data on the consumption pattern of fermented millet gruels

To identify the consumption pattern of fermented millet gruels, a survey was made of 320 households in Ouagadougou, among which 160 consumed such gruels and 160 did not. The households were selected at random by cluster sampling in 29 of the 30 administrative areas of the town of Ouagadougou (area n°4 was discarded because it contains mainly administrative buildings and ministries). Eighty points distributed in the 29 areas as a proportion of their population were determined graphically on the map of each area of the town, and from each point, two households who consumed the fermented gruels and two households which did not were interviewed. A household was considered as a "consumer household" (CH) when someone in the household had consumed ben-kida or ben-saalga at least once in the month preceding the day of the survey. Otherwise, the household was considered as a "non-consumer household" (NCH). To obtain the 2 CH and 2 NCH at each point selected for the survey, it was sometimes necessary to visit more than 4 households. In order to estimate the extent of consumption of fermented millet gruel by people living in Ouagadougou, all the households visited were noted and classified as CH or NCH. The person interviewed in each household was the one responsible for the preparation of the meals for the whole family. The questionnaire included two parts. The first part aimed at collecting data on the frequency and way of consumption of the fermented gruels and their usual suppliers. The second part concerned the perception of the quality of the gruels. Data concerning the socio-cultural and economic profile of the household were also recorded.

Collection of samples for biochemical analyses

The survey enabled the identification of 130 ben-kida or ben-saalga production units (PU) in Ouagadougou. Samples of raw millet and final gruels -ben-kida or ben-saalga, depending on the type of gruel produced in the PU -were taken in 48 of them, which were selected at random. To detect possible seasonal variability of the composition of gruels, samples were collected over a period of one year at the rate of four pairs of samples (raw millet and final gruel) per month from four different PUs. Final gruels were sampled as sold by the producers, without added sugar. All the samples were taken back to the laboratory where part was used for analyses of dry matter content and measurements of consistency and pH. The rest was freeze-dried, ground (particle size < 500 µm) and stored at -18°C until further analyses. An average sample was made by mixing identical aliquots of the 48 samples of raw millet seeds, ground and analysed. The variability of the composition of raw millet was assumed to be rather limited and was assessed by analysing only 14 samples which were selected at random.

Measurement of pH and consistency

The pH of the gruels was determined at room temperature using a WTW 340i pH-meter with automatic compensation of temperature. The consistency of the gruels was measured after cooling at 45°C using a Bostwick consistometer according to the procedure described by [START_REF] Mouquet | Characterization of the consistency of gruels consumed by infants in developing countries: assessment of the Bostwick consistometer and comparison with viscosity measurements and sensory perception[END_REF]. The Bostwick consistency parameter is expressed in mm/30s. This parameter ranges from 0 (almost solid) to >240mm/30s (very fluid, corresponding to a gruel that can be drunk).

Biochemical analyses Proximate composition

Dry matter (DM) contents were determined by oven drying at 105°C to constant weight. Protein contents (N x 6.25) were determined by the method of Kjeldahl (standard NF. V03-050, AFNOR, 1970). Lipids were extracted with ether oil using the HT6 Soxtec system (Tecator, Höganäs, Sweden) according to the AOAC official method 2003.06. Insoluble fibre (Acid Detergent Fibre, ADF) contents were determined by the method of Van Soest (1963) using a Dosi-fiber (Selecta, Barcelona, Spain). ADF corresponds approximately to cellulose and lignin, which are the compounds of fibres most likely to chelate minerals. Determination of residual ashes and proteins (as Kjeldahl N × 6.25) was carried out in the residues for corresponding corrections. Ash contents were determined by calcination in a furnace at 530°C. Available carbohydrates were calculated by difference (100 -proteins -lipids -ADF -ashes). Energy density of the gruels was then calculated by using Atwater coefficients: 4 kcal/g DM (16.7 kJ/g DM) for proteins and available carbohydrates and 9 kcal/g DM (37.6 kJ/g DM) for lipids.

Soluble carbohydrates

After extraction in ethanol solution (80% v/v), and drying using a Speedvac centrifugal evaporator (JOUAN RC 10-10, Saint Herblain, France), soluble carbohydrates were analysed by HPAE-PAD using a Dionex DX 500 apparatus (Sunnyvale, CA, USA) with a Carbo PA1 column according to the method described by [START_REF] Calderon | Nutritional requirements and simplified cultivation medium to study growth and energetics of a sourdough lactic acid bacterium Lactobacillus fermentum Ogi E1 during heterolactic fermentation of starch[END_REF]. The soluble carbohydrates that were analysed in gruel samples were glucose, fructose, sucrose, maltose, and alphagalactosides, i.e. melibiose, stachyose and raffinose. The eluant used was 90 mM sodium hydroxide solution.

Iron and Zinc contents

After mineralization at 530°C [START_REF] Laporte | Milieux végétaux. In: Pinta M, Spectrométrie d'absorption atomique[END_REF], total iron and zinc contents were determined by atomic absorption spectrophotometry (SpectrAA 200,Varian,Victoria,Australia).

Compounds reducing nutrient bioavailability

Phytate Inositol 6-phosphate contents were determined according to the method described by [START_REF] Talamond | Rapid and sensitive liquid chromatographic method using a conductivity detector for the determination of phytic acid in food[END_REF]. After extraction in acid solution (HCl 0.5 M), inositol-6-phosphate (IP6) content was determined by ionic chromatography using a Dionex DX 4500i apparatus equipped with an Ion Pac AS11 column. Detection was by conductivity. The values are expressed in g IP6/100 g DM.

Iron-binding phenolic compounds Iron-binding phenolic compounds were analysed according to the colorimetric method of [START_REF] Brune | Iron absorption and phenolic compounds: importance of different phenolic structures[END_REF] using a ferric ammonium sulphate reagent which enabled measurement of galloyl and catechol group contents at 578 and 680 nm, respectively. Results are expressed as the sum of the tannic acid and catechin equivalent in g/100 g DM.

Lactic acid and D-lactic acid contents.

Total lactic acid content of gruels was determined by HPLC using an Aminex HPX687H column (Biorad, Ivry sur Seine, France). D-lactic acid content was determined by a colorimetric method using the kit EnzyPlus TM D-lactic acid (Raisio Diagnostics, Lyon, France).

Data management and statistical analysis

Survey data were captured and analysed using Epi Info 6.04d software (CDC, Atlanta). The results of biochemical analyses were checked for normality using the Kolmogorov-Smirnov test. For the variables that approximated a normal distribution, the mean value, the minimum and maximum values, and the standard deviation are given. For variables that did not pass the normality test, the median value is also given.

Results and discussion

Consumption pattern of fermented millet gruels

To reach the initially desired sample size of 160 CH and 160 NCH (two of each at each of the 80 survey points of the town), a total of 521 households were visited, comprising 342 CH and 179 NCH. This allowed us to estimate that 65.6% of the households in Ouagadougou are "consumers" of this type of gruel, i.e. had consumed ben-kida or ben-saalga during the month before the survey.

Extent and conditions of consumption

Almost half CH consumed fermented gruels daily, mainly early in the morning, for breakfast (Table 1). As it was stated by [START_REF] Blandino | Cereal-based fermented foods and beverages[END_REF] for fermented cereal gruels in other West-African countries, people of all ages ate the gruels and young children under the age of two appear to be frequent consumers: 80% of them in the CH had consumed the last gruel that had been purchased by the household and almost 70% consumed it every day. Several mothers reported that the liquid ben-saalga is given to the younger, and that children begin to receive ben-kida when the first teeth appear. Sugar was added before consumption in 98% of cases. The weighing of the amounts of sugar and gruel purchased at the same time at one point of sale by 10 different customers enabled us to estimate that the mean concentration of added sugar was 4.4 g/100 g of sweetened gruel. Almost 75% of the consumers ate only the gruel; the remainder ate it with cake or bread to fill the stomach better. The gruels were either eaten immediately where they were purchased, or taken home for the whole family. Ben-kida was by far the most popular and most often consumed type of gruel (83% of CH, against 17% for ben-saalga) mainly because it was perceived to be more nourishing and substantial.

Socio-cultural and economic context of the consumption of ben-kida and ben-saalga

The weekly frequency of consumption of fermented millet gruels by the households in Ouagadougou is independent of their ethnic group, their religion and their urban or rural origin. But the mean weekly frequency was significantly higher (p<0.05) in households where the head was older or less educated, had more than four children, or a lower socio-economic status.

Demand and preferences of consumers

The main reasons most frequently given by people for consuming or not consuming ben-kida or ben-saalga are listed in Figure 1. These results highlight the very good acceptability of the fermented gruel and also the importance of the convenience of such ready-to-eat products (figure 1b). Among NCH, 31% declared they did not know much about this type of gruel as it was not part of their food habits (figure 1a). The second reason for not consuming fermented millet gruel was that it is not nutritious enough: according to 26% of them, it fills the stomach but it does not last a long time, and "it does not kill hunger". The third main reason was the gruels' reputation for poor hygienic quality. Only 7% of NCH said it was too expensive. More than 70% of CH and NCH interviewed made suggestions for improvement: respectively 46 and 39% would like producers to pay more attention to hygiene during preparation and at points of sale; 31 and 45% of CH and NCH would like a more substantial or nutritious gruel, even enriched with vitamins. Many people also said that more aromatic ingredients, such as ginger, mint, and tamarind, should be used to improve the taste of the gruels.

Biochemical composition and nutritional value of the fermented millet gruels

The main physicochemical characteristics of the fermented millet gruels are presented in Table 2. The Bostwick flow values are high, corresponding to very fluid gruels, which can either be eaten with a spoon or drunk. Only one gruel had a Bostwick flow value higher than 240 mm/30s and was considered as an outlier with an undesirable consistency. To obtain such a fluid consistency, producers must dilute the gruels considerably, which results in low dry matter contents, most between 5 and 8 g/100 g of gruel (figure 2) and consequently low energy density, below 133.8 kJ (32 kcal)/100g. Three outliers, all three of the ben-kida type, had higher concentrations that may be due to the addition of larger quantities of flour granules. Nevertheless, there was no significant difference between the concentrations of ben-saalga and ben-kida. And the maximum value did not exceed 10.24 g of DM/100g of gruel, corresponding to an energy density of about 171 kJ (41 kcal)/100g, which is far below the minimum energy density of 351 kJ/100 g (84 kcal/100g) recommended for complementary food [START_REF] Dewey | Update on technical issues concerning complementary feeding of young children in developing countries and implications for intervention programs[END_REF]. Due to lactic acid fermentation that occurs during processing [START_REF] Tou | Study through surveys and fermentation kinetics of the traditional processing of pearl millet (Pennisetum glaucum) into ben-saalga, a fermented gruel from Burkina Faso[END_REF], fermented gruels have a low pH that gives them a sour taste. The pH of the gruels of the ben-kida type is slightly but significantly (pH<0.05) higher than that of gruels of the ben-saalga type, which may be explained by the addition of granules prepared with unfermented flour. Nevertheless, all pH values were below 4.5, most were near 4.0, like all other African cereal-based gruels that undergo lactic acid fermentation, such as ogi and mahewu [START_REF] Simango | Effective acidification of traditional fermented foods[END_REF] , or togwa [START_REF] Chavan | Nutritional improvement of cereals by fermentation[END_REF]). In the poor hygienic conditions that prevail in production units in developing countries, this low pH, combined with the production of lactic acid, H 2 O 2 , diacetyl and bacteriocins, has the advantage of preventing or limiting the growth of food-borne pathogens or undesirable microorganisms, even after cooking [START_REF] Nout | Accelerated natural lactic fermentation of infant food formulations[END_REF][START_REF] Kingamkono | pH and acidity in lactic-fermenting cereal gruels: effect on viability of enteropathogenic microorganisms[END_REF][START_REF] Blandino | Cereal-based fermented foods and beverages[END_REF]. The variability of the pH of fermented millet gruels was low, 75% had a pH between 3.89 and 4.09 (figure 3). Data on proximate and mineral composition of raw millet and fermented millet gruel are given in Table 3. Millet grains are richer in proteins and lipids than most other cereals available in west-africa, such as rice, maize, sorghum [START_REF] Fao | Toxicological evaluation of certain food additives with a review of general principles and of specifications[END_REF]. The iron content of the raw millet was highly variable with a maximum value around 74 mg of iron/100g of DM. It is likely that such a high value corresponds not only to intrinsic iron, but also to additional iron from dust or ferrous soil as it has been previously shown for tef [START_REF] Abebe | Phytate, zinc, iron and calcium content of selected raw and prepared foods consumed in rural Sidama, Southern Ethiopia, and implications for bioavailability[END_REF]. Mean values of iron and zinc content (22.7 and 2.47 mg/100 g DM, respectively) are higher (for iron) and similar (for zinc) than recently reported values obtained from samples of millet collected in different regions of Mali (5.8 and 2.9 mg/100 g corresponding to 6.4 and 3.2 mg/100g DM, respectively) [START_REF] Barikmo | Differences in micronutrients content found in cereals from various parts of Mali. 6th International Food Data Conference[END_REF]. Authors pointed out the considerable variability in mineral, and particularly iron, content of cereal, across the region of origin. Fibre and ash contents decreased during processing due to the removal of hulls during the sieving step. Protein and lipid contents in gruels also decreased but to a lesser extent, and were highly variable. In the grains, proteins and lipids are mainly located in the germ. Depending on the fineness of the wet flour milling, and on the mesh size during sieving, a varying proportion of the germs is removed simultaneously with the hulls, which probably explains the final high variability of protein and lipid contents. Processing also results in a considerable decrease in total iron and zinc. These losses are mainly due to leaching of soluble minerals during the soaking step (Lestienne et al., 2005a). For protein content only, a positive correlation was found between the initial content in the millet grain and the final content in the gruel (n=14, p<0.05). This means that the use of pearl millet genotypes that are rich in protein would enable preparation of gruels with higher protein contents. However, the increase that could be obtained in this way is limited. Concerning the final lipid content, processing (particularly the step of sieving) appears to have a greater effect than the initial lipid content of the grain used.

As shown in Table 4, mean glucose and fructose contents, which are very low in raw millet grains, increased dramatically in fermented gruels, whereas sucrose content, which was initially rather high, fell dramatically. This decrease in sucrose content during processing was observed in all samples and the average percentage of variation approached 100%. This may be explained by the action of a microbial invertase during fermentation, which hydrolyses the sucrose into glucose and fructose, thus helping increase the contents of these sugars. Then, as glucose and fructose are substrates for the lactic acid bacteria during fermentation, their final contents in the gruels were highly variable. Maltose was not detected in raw millet grains, but was present at concentrations above 0.01 g/100g DM in 36 gruel samples out of 47, the maximum value being 0.52g/100 g DM. The appearance of maltose, even in small quantities, is likely due to very partial starch hydrolysis under the action of amylolytic strains of lactic acid bacteria (ALAB) in certain production units. The isolation and use of ALAB as starter culture, as proposed by [START_REF] Nguyen | Effect of fermentation by amylolytic lactic acid bacteria, in process combinations, on characteristics of rice/soybean slurries: A new method for preparing high energy density complementary foods for young children[END_REF] for rice-based gruels, could be a way of increasing the energy density of the gruel by reducing their viscosity at high concentration through partial starch depolymerisation. This phenomenon would also help increase glucose content. Similar as for sucrose, there was a marked decrease in raffinose and stachyose contents in most samples, with the simultaneous appearance of small quantities of melibiose (table 5). The decrease in raffinose and stachyose may be due to leaching into the water during soaking as well as hydrolysis by bacterial -galactosidase during fermentation. This can be regarded as a positive effect as -galactosides are responsible for digestive disorders in infants, as they are indigestible and fermented by intestinal microflora in the colon causing flatulence. However, it would only be of real interest in the case of cofermentation of millet with legumes, since the initial -galactoside content of millet is moderate. Factors such as phytate and iron-binding phenolic compounds, which have chelating effect and thus reduce mineral bioavailability, also decreased during fermentation (table 5). The extent of this decrease varied considerably from one production unit to another, and the maximum decrease observed was 86.3% and 68.0% for phytate and iron-binding phenolic compounds respectively. El [START_REF] El Hag | Effect of fermentation and dehulling on starch, total polyphenols, phytic acid content and in vitro protein digestibility of pearl millet[END_REF] also reported decreases in the contents of phytate and polyphenol in millet-based fermented dough prepared at laboratory scale. In their experiments, phytate and polyphenols were reduced by respectively 50% and 66% after 12 h of fermentation. These decreases can be partially explained by the leaching of the soluble part of polyphenols and phytates during the soaking step, but this is not enough to explain the decrease of more than 29% in phytate content (Lestienne et al., 2005a and b). Additional losses are likely due to a partial removal of germs, which contains about 60% of the phytate of the grains [START_REF] Abdelrahman | The proportions and chemical compositions of hand-dissected anatomical parts of pearl millet[END_REF], during sieving or to degradation through hydrolysis by endogenous or microbial phytase or polyphenoloxydase during fermentation [START_REF] Lopez | Release of phosphorus from phytate by natural lactic acid fermentation[END_REF][START_REF] Khetarpaul | Effect of fermentation by pure cultures of yeasts and lactobacilli on phytic acid and polyphenol content of pearl millet[END_REF]. This also suggests that the isolation and use as starter culture of bacterial strains with high phytase or polyphenol oxydase activities could improve the bioavailability of minerals in fermented gruels. Indeed, even if polyphenols can have also positive effects as antioxidants as described by [START_REF] Dykes | Sorghum and millet phenols and antioxidants[END_REF], their negative role as mineral-chelating agent might be of greater importance in the context of young child feeding in developing countries, given the low micronutrient availability in their food diet [START_REF] Zimmermann | Nutritional iron deficiency[END_REF]. Final fermented millet gruels had an average total lactic acid content of 197.4 ± 56.1 mg/100g of gruel (with a maximum value of 342.4 mg/100g), far below that of yogurt, which is around 1 g/100g. The determination of D-lactic acid content revealed its presence in all gruel samples in non-negligible proportions: gruels contained an average of 62.3 mg of D-lactic acid/100 g of gruel, representing 32.2% of the total lactic acid formed during fermentation. To our knowledge, few data on D-lactic acid content in African fermented cereal-based gruel are available in the literature. [START_REF] Nout | Accelerated natural lactic fermentation of infant food formulations[END_REF] reported that D-lactic acid represent about 42% of total acidity in a modified sorghum-based gruel, and, according to Yusof (1993), the main lactic acid bacteria strains involved in the processing of fermented cereal products produce a mixture of D-and L-lactate. The presence of the D-isomer in non-negligible quantities is not surprising since the natural microflora responsible for cereal fermentation are a mixture of lactic acid bacteria belonging to different metabolic groups. In the human body, D-lactic acid is metabolized more slowly than its chiral isomer L-lactic acid (Urribari et al., 1998). This may be a problem in newborn infants due to renal immaturity which limits the excretion of hydrogen ions by the kidney [START_REF] Mack | D(-)-lactic acid-producing probiotics, D(-)-lactic acidosis and infants[END_REF], for whom ingestion of large quantities of D-lactic acid could result in its accumulation in the blood and consequently in metabolic acidosis. However, young children are not concerned by this issue as the international recommendation not to add D or DL-lactate concerns food destined for infants less than three months old (FAO/ WHO, 1974;Yusof, 1993). And the D-lactate load that can be ingested through the consumption of fermented gruel is much lower than that absorbed from yoghurt by healthy adults in the study of [START_REF] Vrese | Postprandial plasma D-lactate concentrations after yogurt ingestion[END_REF], which had no harmful effects. As previously mentioned, sugar is almost always added to fermented millet before consumption. Therefore, the nutritional properties of fermented gruels as eaten were calculated taking into account the addition of sugar and were then compared to recent recommendations for complementary foods (table 6). Due to the very low dry matter content of traditional fermented millet gruels, the added sugar represents a large proportion (>40 %) of the dry matter of the gruel eaten. The addition of sugar led to an increase in the mean gruel energy density from about 109 kJ/100 g to 180 kJ/100 g (26 to 43 kcal/100g). However, as sugar contains mainly "empty" calories, this increase is limited to energy, and other macronutrient (protein and lipid) or micronutrient (iron and zinc) contents are even further below recommended levels. And anyway, the final energy density of gruel after the addition of sugar is still far below the recommended value of 351 kJ/100 g (84 kcal/100g).

Conclusion

The survey of households in Ouagadougou showed that a large proportion of young children receive traditional fermented millet gruels as complementary food. These gruels are well accepted from an organoleptic viewpoint and mothers appreciate them because they are relatively cheap and practical (as they are sold in ready-to-eat form). The most frequently cited problems of quality of ben-kida and ben-saalga gruels are their unreliable hygienic quality and poor nutritional quality. Actually, the low pH and the high lactic acid content (which has antiseptic properties) of ben-kida and ben-saalga, thanks to the lactic acid fermentation that occurs during processing, can be expecting to offer some protecting effect against growth and survival of food-borne pathogens. Due to processing and mainly to fermentation, the biochemical composition of gruel differs from that of raw millet. The putative diversity of lactic acid microflora and differences in the know-how of producers means these changes vary considerably from producer to producer. These assumptions are supported by the fact that, although -galactoside and phytate contents generally decreased during processing, their final contents in gruels varied considerably from one production unit to another. It would be interesting to explore the possibility of optimizing the degradation of phytate and -galactoside by the use of starter cultures selected for their marked phytasic or -galactosidasic activity. In all samples, final energy density and macronutrient contents were very low, far below the recommendations for adequate complementary foods. Concerning iron and zinc contents, a positive influence of the decrease in factors that have a chelating effect (phytate, iron-binding phenolic compounds and insoluble fibres) on their bioavailability would be expected in traditional fermented millet gruels, but losses of soluble minerals due to processing result in very low final total mineral contents. Thus, improvement of the nutritional quality of traditional gruels requires many modifications to simultaneously increase energy, and macro-and micro-nutrient densities. The decrease in mineral-chelating factors achieved by processing would then be useful to improve bioavailability of both intrinsic and extrinsic (added by fortification) minerals.

Figure 1 .Figure 2 .Figure 3 .

 123 Figure 1. Main reasons cited by households for not consuming (a) or for consuming ben-kida or ben-saalga (b)

Table 1 .

 1 Frequency and mode of consumption of ben-kida and ben-saalga as a function of age in CH.

		Adults
			12-17 yrs 6-11 yrs	2-5 yrs	< 2 yrs	Total
		> 17 yrs
	Number of people in the	254	119	136	105	30	644
	159 CH
	People who consumed the last fermented gruel that was purchased by the household (%)
		63	59	63	71	80	64
	Frequency of consumption (%)
	Daily	44	42	49	59	69	48
	From 1 to 6 times/week	44	52	45	38	27	44
	Less than once a week	12	6	6	3	4	8
	Meal times that gruel was eaten (%)
	Before 8 am	89	91	93	94	97	91
	Between 8 am and 12 pm	3	6	3	2	0	3
	Between 2 pm and 6 pm	6	2	3	3	3	4
	After 6 pm	2	1	0	1	0	1
	Ingredients added to gruel before consumption (%)
	Sugar	96	96	99	100	100	98
	Millet cake	22	28	16	11	10	20
	Bread	3	6	4	5	0	4

Table 2 .

 2 Physicochemical characteristics of pearl millet and fermented gruels

		Number	Mean	Standard	Range
			value	deviation
	DM content of pearl millet (%)	47	91.99	1.49	88.40-95.20
	DM content of gruel (%)
	Ben-saalga	9	7.06	1.02	5.53-8.09
	Ben-kida	39	6.50 (6.44) 1	1.02	5.02-10.24
	Together	48	6.61 (6.45) 1	1.03	5.02-10.24
	Bostwick flow (mm/30s)
	Ben-saalga	2	--	--	110 ->240 2
	Ben-kida	24	129	26	70-172
	Together	26	128 2	26	70->240
	pH
	Ben-saalga	9	3.88	0.08	3.75-4.00
	Ben-kida	38	4.00	0.14	3.75-4.47
	Together	47	3.98 (3.96) 1	0.14	3.75-4.47
	1 Median value is given in brackets
	2 Only 2 values were collected

3

This value was calculated without the only gruel whose consistency was too fluid to be measured with the Bostwick apparatus (value > 240mm/30s), and was thus considered to be an outlier.

Table 3 .

 3 Proximate composition and iron and zinc contents of pearl millet and fermented gruels

		Average sample of pearl millet 1		Pearl millet grains n=14	Fermented gruel (ben-kida or ben-saalga) n=47	Change (%) 3
		Mean 2	Mean	Standard deviation	Range	Mean	Standard deviation	Range
	Proteins (g/100g DM)	9.68	9.28	0.93	8.33 -11.7	8.22	0.87	5.77 -9.96	-15
	Lipids (g/100g DM)	5.31	5.24	0.34	4.69 -5.71	4.69	0.76	2.54 -6.63	-12
	Fibres (g/100g DM)	2.87	2.64	0.51	1.91 -3.60	2.14	0.48	1.27 -3.18	-25
	Ash (g/100g DM)	2.03	2.03	1.18	1.35 -5.98	1.41	0.20	0.90 -1.82	-31
	Iron (mg/100g DM)	22.7	21.2	22.0	4.79 -73.5	8.33	2.83	3.82 -15.0	-63
	Zinc (mg/100g DM)	2.47	2.66	0.74	1.85 -4.04	2.05	0.51	1.07 -3.20	-17

1 average sample prepared by blending the 47 samples of raw pearl millet -2 mean of 2 measurements -3 percentage of change between the mean final content of gruels and the initial content of raw pearl millet measured on the average sample of raw pearl millet on the basis of initial content

Table 4 .

 4 Soluble sugar contents of pearl millet and fermented gruels average sample prepared by blending identical aliquots of dry matter of the 47 samples of raw pearl millet 2 mean of 2 measurements 3 percentage of change between the mean value obtained from n samples of raw pearl millet and the mean value obtained from corresponding gruels on the basis of initial content.

		Average sample of millet 1			Pearl millet		Fermented gruel ben-kida & ben-saalga	Change (%) 3
		Mean 2	n	Mean value	Std dev.	Range	n	Mean value	Std dev.	Range
	Glucose (g/100 g DM)	0.063	13 0.07	0.007	0.05-0.08	47	0.61	0.543	0.01-2.64	868
	Fructose (g/100 g DM)	0.038	14 0.04	0.005	0.03-0.05	47	0.18	0.139 0.001-0.49	374
	Sucrose (g/100 g DM)	1.513	14 1.51	0.010	1.24-1.66	47	0.04	0.07	0.000-0.32	-97
	Maltose (g/100 g DM)	n.d.	14	n.d.	-	-	47	0.11	0.137 0.000-0.52	-

1 4 n.d. = not detected

Table 5 .

 5 Factors reducing nutrient bioavailability and D-lactic acid contents of pearl millet and fermented gruels

	Average sample of millet 1	Pearl millet		Fermented gruel ben-kida & ben-saalga	Change 3
	Mean 2	n	Mean value	Std dev. Range	n	Mean value	Std dev. Range	%

1 average sample prepared by blending identical aliquots of dry matter of the 47 samples of raw pearl millet.

Acknowledgments

The authors wish to express their thanks to C. Picq and I. Lestienne for technical assistance with analyses of proximate composition, minerals, and phenolic compounds. This work is part of the Cerefer project (www.mpl.ird.fr/cerefer) funded by European Commission Contract N°ICA4- CT-2002-10047.


Milan Kabáč
email: milan.kabac@inria.fr

Charles Consel
email: charles.consel@inria.fr

Orchestrating Masses of Sensors: A Design-Driven Development Approach

Keywords: D.2.11 [Software Engineering]: Software Architectures-domain-specific architectures, languages, patterns Generative programming, domain-specific languages, programming frameworks, sensors, pervasive computing

This paper proposes a design-driven development approach that is dedicated to the domain of orchestration of masses of sensors.

The developer declares what an application does using a domainspecific language (DSL). Our compiler processes domain-specific declarations to generate a customized programming framework that guides and supports the programming phase.

Introduction

Masses of sensors are being deployed at the scale of metropolitan areas, country-wide transportation infrastructures, and campuses of buildings. Examples include smart parking lots across entire cities that can direct drivers to available parking spaces, and pollution sensors that are distributed over a city to measure pollution levels and warn frail persons. In this context, the key challenge is to harness the potential benefits of such infrastructures by providing users with innovative and useful services. To achieve this goal, developing software is a crucial activity that enables exploring the scope of potential services, anticipating and responding to users' needs. Developing applications that orchestrate masses of objects raises major challenges because of the scale at which this orchestration takes place. Let us introduce the main challenges by reviewing the typical conceptual phases of an application in this domain, namely service discovery, data gathering and actuating. Service discovery. In contrast with standard service discovery that addresses individual objects, masses of sensors demand a high-level approach to designating subsets of interest. Specifically, selecting objects of interest among a myriad of objects should be tamed by application-specific abstractions that provide meaningful constructs for grouping sensors. For example, an application may need to manipulate parking spaces at the level of lots or districts. The developer should be able to directly express these application-specific concepts. Beyond expressiveness, when considering masses of sen-sors, the scalability of a service discovery mechanism is critical to making an orchestrating application usable. In this context, exploiting information about the application behavior is essential to reduce the cost of such activites as service discovery and data gathering, as shown by various works [START_REF] Heidemann | Matching data dissemination algorithms to application requirements[END_REF][START_REF] Liu | Balancing push and pull for efficient information discovery in large-scale sensor networks[END_REF]. Furthermore, it has been shown that a mismatch between the application behavior and the network routing algorithms can result in poor performance [START_REF] Heidemann | Matching data dissemination algorithms to application requirements[END_REF]. Data gathering. Delivery models used to gather data must accommodate masses of sources. For example, applications may require data to be pushed from any number of CO2 sensors located in underground parking lots, when a given air pollution level is reached. Delivery models have a direct impact on the structure and the logic of an application. Besides, making explicit the delivery models used by an application can be valuable information to ensure an optimal routing structure of the underlying sensor network [START_REF] Liu | Balancing push and pull for efficient information discovery in large-scale sensor networks[END_REF]. Actuating. Processing data may result in taking actions by actuating devices. For example, computing the number of available spaces in parking lots allows to periodically update this number on the entrance screen of each lot.

Our Approach

To address the challenges examined earlier, we propose a software development approach that covers all the phases of an orchestrating application. To do so, we introduce a domain-specific language dedicated to designing orchestrating applications. Design declarations are then processed to support and guide the programmer using generative programming. This strategy allows to abstract over the characteristics of the sensor network. Domain-specific design language. To cope with the many dimensions of the orchestration of masses of sensors, we introduce a design language that is dedicated to this domain, allowing the developer to declare what an application does, prior to programming it. This design language, named DiaSwarm, consists of constructs dedicated to manipulating objects at a large scale. For example, it provides high-level constructs to declare delivery models of sensors at design time. Design-specific programming frameworks. We have developed a compiler for DiaSwarm that produces programming support customized with respect to a given DiaSwarm design. This programming support takes the form of a programming framework [START_REF] Fayad | Object-oriented application frameworks[END_REF]. For example, the DiaSwarm compiler generates code that gathers data from sensors with declared delivery models, allowing the developer to concentrate on what to do once the data is gathered.

Our Contributions

DiaSwarm. We introduce a design language dedicated to the domain of orchestrating masses of objects. This language provides high-level, declarative constructs that allow a developer to deal with masses of objects at design time, prior to programming applications.

Compiler. We have developed a compiler that generates programming frameworks dedicated to DiaSwarm designs. These programming frameworks provide high-level support to the developer, while ensuring that programming is driven by the design.

DiaSwarm

Our presentation of DiaSwarm focuses on the aspects pertaining to orchestrating objects in the large. The other aspects are inspired by a design language, named DiaSpec, dedicated to traditional pervasive computing environments (e.g., homes, offices) and introduced by Cassou et al. [START_REF] Cassou | Towards a Toolbased Development Methodology for Pervasive Computing Applications[END_REF].

Working Example

Throughout this paper, we illustrate our approach using a parking management system, whose purpose is to monitor the occupancy of parking lots and regulate the flow of traffic to direct cars to available parking spaces. The working example is inspired by existing smart city projects [START_REF] Libelium | Smart City project in Santander to monitor Parking Free Slots[END_REF]. In our scenario, we envision an infrastructure capable of monitoring the availability of parking spaces. Sensors measure magnetic field variations to determine whether a parking space is occupied by a car. They are encapsulated inside a waterproof casing, buried underground, and emit their status at regular intervals. The application gathers values from these sensors and provides drivers with the number of available parking spaces for a given parking lot by displaying this information on a screen at the entrance of the lot. In addition, the application suggests parking lots to drivers entering the city in an attempt to optimize the flow of traffic. In this case, suggestions are being broadcast to drivers via panels located at the entrances to the city. Furthermore, the application processes sensor data acquired over a period of 24 hours to determine the average occupancy of a parking lot. Parking managers are kept informed about the occupancy level of a parking lot via messages (e.g., email, text messages).

Device Declarations

An infrastructure relies on numerous objects that allow applications to determine the current state of the environment and to execute actions accordingly. We refer to these elementary building blocks as devices, whether they are hardware (e.g., sensors) or software (e.g., web services). A device declares its ability to sense the state of the environment as a source. Also, a device may have an action facet that comprises a set of operations that can alter the current state of the environment. Device properties (e.g., id, location, etc.) allow device instances to be distinguished from each other; they are called attributes and are defined at deployment time. Finally, device declarations offer inheritance, promoting the reusability of sources, actions and attributes. Figure 1 shows device declarations for the parking management system. Line 1 declares the PresenceSensor device, which consists of an attribute (line 2), defining the location of the parking space it is associated with. This device only declares one source of information (line 3): a boolean value indicating whether a car is present at the space associated with a sensor. Two actuators are defined in lines 5 and 7. Each class of actuator defines a location attribute specific to its purpose (i.e., parking lot and city entrance). Both share a method to display information (update -line 4). Likewise, the Messenger actuator (line 9) declares a method (sendMessage -line 9) to provide parking managers with information about parking lots.

Application Design

In our target domain, applications can be seen as interacting with an external environment to measure its state via sensors and modify it via actuators. For such a domain, the application logic is naturally expressed with a Sense/Compute/Control (SCC) paradigm, depicted As can be seen in Figure 3, at a high level, the design of our parking management application does not depend on whether masses of sensors are involved. However, as we examine this application further by presenting the declarations of its constituent components, the need to account for masses of sensors becomes evident, calling for specific constructs. This situation first arises when considering how a context can gather data from a large number of sensors. Data gathering. Because of the nature of our domain, context components mostly gather information from objects at a large scale. To cope with this dimension, our declarative approach provides three data delivery models, inspired by the domain of wireless sensor networks [START_REF] Tilak | A Taxonomy of Wireless Micro-Sensor Network Models[END_REF], namely periodic, event-driven and query-driven.

Let us illustrate these three data delivery models with our working example and its DiaSwarm declarations given in Figure 4. A context is declared with the keyword context, as illustrated in line 1 with the declaration of the ParkingAvailability context, whose output type is a sequence of values of type Availability. Next, line 2 defines how this context component interacts with its input sensor, namely, PresenceSensor. Specifically, the data delivery model for this context is defined as periodic. Indeed, recall that presence sensors are assumed to send their status periodically. Thus, our declaration specifies that the ParkingAvailability context must be activated following a periodic model, every 10 minutes (i.e., <10 min> with presence values). However, the application and the myriad of presence sensors are managed independently. This means that values from the presence sensors are gathered at the sensors' pace, and values are pushed to the application at the application's pace, specified by the context declaration. If the context is faster than the sensors, it will be activated with the same values. If it is too slow, it will miss values. This latter case is illustrated by the Par-kingUsagePattern that collects parking space occupancy every hour (line 7), as opposed to every 10 minutes, because usage patterns can be determined from coarser-grained information. Finally, the AverageOccupancy context determines the average occupancy of a parking lot by processing sensor data acquired over 24 hours (line 15).

DiaSwarm also offers two other delivery models: event-driven and query-driven. They are denoted by when provided and when required activation conditions, respectively. The ParkingSuggestion context requires data from the ParkingAvailability and ParkingUsagePattern contexts to produce a list of suggestions of parking lots. This list is computed when the ParkingAvailability context outputs a result (see line 19). In fact, all components declared as interacting with the ParkingAvailability context will be invoked whenever it produces a value. How the ParkingAvailability context produces values is declared in line 4: always publish. This construct specifies that the context must publish an output to subscribed components whenever it is activated (i.e., every 10 minutes). The second input to the ParkingSuggestion context is the ParkingUsagePattern context. The interaction with this context is query-driven, as denoted by the declaration get used in line 20. In fact, the ParkingUsagePattern context never publishes values (see line 9). It is assumed that its clients request values from it. This activation condition is expressed by the when required declaration. Service discovery at design time. Discovering in the large requires high-level constructs that are application-tailored. To achieve this goal, we propose discovery constructs that leverage applicationspecific design concepts. Specifically, DiaSwarm offers the grouped by construct parameterized by an attribute. For example, in line 3, the ParkingAvailability context requires grouping presence statuses in parking spaces by parking lot, enabling availability to be computed for each lot.

Note that in DiaSwarm, service discovery is part of the design phase, contrasting with existing service discovery that are part of the programming phase [START_REF] Zhu | Service Discovery in Pervasive Computing Environments[END_REF]. This is a key feature to achieve scalability, as discussed later. Furthermore, because our service discovery approach is global (i.e., not specific to individual sensors), it abstracts over sensor failures; this aspect is delegated to an underlying middleware layer. Actuating. The declaration of a controller component begins with the controller keyword followed by its name. A controller is activated exclusively by the when provided condition. For example, the ParkingEntrancePanel controller (line 23) is activated by the ParkingAvailability context (line 24), causing the update action to be triggered on the ParkingEntrancePanel device (line 25).

Programming Framework

DiaSwarm designs are processed by a compiler that generates customized programming frameworks, currently written in Java. These frameworks provide domain-specific functionalities, including service discovery, data gathering and component interaction. To connect the design phase to the programming phase, the DiaSwarm compiler generates an abstract class for each component declaration. The application logic is implemented by subclassing each abstract class, which in turn requires the abstract methods to be implemented by filling these placeholders with code. The support for devices is examined in our previous work [START_REF] Cassou | Towards a Toolbased Development Methodology for Pervasive Computing Applications[END_REF].

Context Components

We start by examining the implementation of the ParkingAvailability context component, shown in Figure 5. The developer extends the generated AbstractParkingAvailability class with the ParkingAvailability class. This subclassing requires the developer to implement a callback method (i.e., onPeriodicPresence) that receives the data gathered from the presence sensors, in conformance with the DiaSwarm declaration. Because of the grouped by directive, the callback method receives a list of parking spaces indexed by the parkingLot attribute. This directive is compiled into a map, which holds entries of the <ParkingLotEnum, List<Boolean>> key-value type (line 5), allowing the developer to focus on the data treatment. This treatment is performed by a for loop (line 8) over this map. Each iteration processes the parking spaces of a given parking lot. Each entry holds a list of values, indicating the availability of individual parking spaces in a parking lot. In our example, we simply count the number of available parking spaces for each parking lot (line 11). Our example implementation of ParkingAvailability returns a list of counts of available parking spaces, indexed by parking lot identifiers, which matches the type of the component declaration. As can be noted, our generative approach allows the developer to abstract over how sensed data are gathered. In particular, the onPeriodicPresence method can be implemented without knowing the frequency at which sensors emit measurements, and how many sensors are involved.

Controller Components

The role of a controller component is to trigger actions on devices to alter the current state of the environment. Similar to a context, a controller is implemented by subclassing the generated abstract class, as illustrated in Figure 6. The generated abstract class Abstract-ParkingEntrancePanel ensures that the ParkingEntrancePanel controller receives data from the ParkingAvailability context in conformance with design declarations. As a result, the ParkingEn-trancePanel controller will be notified via the onParkingAvailability callback method (line 4) whenever the ParkingAvailability context publishes the availability of parking lots. The onParkingAvailability method is implemented by overriding the generated abstract method. The arguments passed to the callback method comprise context data (parkingAvailability) and the discover object. This object is set by the programming framework according to which actuators (and operations) were declared as interacting with this controller component. As shown in line 9, the discover object is used to access the display panel of each parking lot. To do so, the discover object returns a collection of proxies, wrapped inside a composite object, following the composite design pattern [START_REF] Gamma | Design Patterns: Elements of Reusable Object-Oriented Software[END_REF]. A proxy provides a means to invoke a remote device, without the need to manage distributed systems details.

Conclusion and Future Work

We have presented DiaSwarm, a design language dedicated to the domain of applications orchestrating masses of sensors. We have introduced domain-specific declarations that express the key aspects of such applications: service discovery, data gathering, and actuating. We have illustrated our approach with a working example that exercised the salient features of our language. In the future, we plan to investigate how design declarations can be used to expose parallelism to implement efficient strategies for processing large amounts of data collected from sensors.

1 device PresenceSensor 2 {{{Figure 1 .

 121 Figure 1. Device declarations.

Figure 2 .

 2 Figure 2. The Sense/Compute/Control paradigm.in Figure2. The SCC paradigm, promoted by Taylor et al.[START_REF] Taylor | Software Architecture: Foundations, Theory, and Practice[END_REF], is general enough for orchestrating objects both in the small and in the large. Consequently, this aspect of DiaSwarm reuses the way DiaSpec declares the design of an application[START_REF] Cassou | Leveraging Software Architectures to Guide and Verify the Development of Sense/Compute/-Control Applications[END_REF]. Specifically, a design consists of (1) declarations of components and devices and (2) descriptions how they interact with each other, forming an acyclic, directed graph from sensors to actuators. DiaSpec introduces two types of components: contexts and controllers. Context components interact with device sources; they receive raw data from the devices, via their sources. They refine (e.g., filter, aggregate) this data into application values, possibly interacting with other context components. When the environment needs to be acted on, a context component declares an interaction with controller components. These components are invoked with refined values and determine what and how actuators are to be invoked.Figure3presents a graphical view of the parking management application in the SCC paradigm. The application declares the PresenceSensor device, which produces presence values via its presence source to the ParkingAvailability, ParkingUsage-Pattern and AverageOccupancy contexts. The ParkingAvailability context computes the number of available parking spaces in parking lots. This information is passed to the ParkingEn-trancePanel controller; it is in charge of refreshing the number of available spaces. To do so, this controller component invokes the update method of the display panel at the entrance of parking lots.The ParkingSuggestion context provides a list of suggestions of parking lots, based on the information computed by the Parking-Availability component and the usage statistics of parking lots, accumulated by the ParkingUsagePattern component. The list of suggestions is passed to the CityEntrancePanel controller that administers display panels located at the entrances of the city. The AverageOccupancy context calculates the average occupancy of individual parking lots and passes this information to the Messenger controller, which notifies parking managers by sending a message via the Messenger device.As can be seen in Figure3, at a high level, the design of our parking management application does not depend on whether masses of sensors are involved. However, as we examine this application further by presenting the declarations of its constituent components, the need to account for masses of sensors becomes evident, calling for specific constructs. This situation first arises when considering how a context can gather data from a large number of sensors.

Figure 3 .

 3 Figure 3. Graphical view of the parking management application.

1 contextFigure 4 .

 14 Figure 4. The design of the parking management application.

Figure 5 .Figure 6 .

 56 Figure 5. ParkingAvailability context implementation.

Availability Average Occupancy