Phoenix - INRIA Research Group

DiaSuite provides a tool-based development methodology that relies on the Sense/Compute/Control (SCC) paradigm and covers the whole development process, as depicted in Figure 1.1, “The development life-cycle of an SCC application using DiaSuite ” . This paradigm originates from the Sense/Compute/Control architectural pattern and is pervasively used in domains such as telecommunications, building automation, robotics and avionics. Like a programming paradigm, the SCC paradigm provides concepts and abstractions to solve a software engineering problem. These concepts and abstractions are dedicated to a design style, raising the level of abstraction above programming. Because of its dedicated nature, such a development paradigm allows a more disciplined engineering process, as advocated by Shaw [Shaw, 1995].

Figure 1.1. The development life-cycle of an SCC application using DiaSuite

In the following sections, we briefly illustrate each step of the DiaSuite methodology using a simple application that displays ``Hello World'' on a TV screen when motion is detected by a motion detector.

DiaSuite provides a design language, named DiaSpec, that is dedicated to the SCC paradigm. This design language consists of two layers: the taxonomy layer and the application design layer. The grammar of DiaSpec is available at DiaSpec grammar .

 
      	
device LocatedDevice { 
  attribute location as String; 
 }

device MotionDetector extends LocatedDevice {
	source motion as Boolean;
}
 
device TvMessenger extends LocatedDevice {
	action SendMessage;
}       
      
action SendMessage { display(message as String); } 
      	 
				

Application Design Layer

The application design layer of DiaSpec (stage 2 in Figure 1.1, “The development life-cycle of an SCC application using DiaSuite ” ) allows the application logic to be decomposed into contexts and controllers. The application design can be graphically represented by its data flow using an oriented graph, whose nodes are the components, and edges indicate data exchange between components. Note that the sensors and actuators are the two facets of an entity described in the taxonomy. The data-flow graph is structured into four layers as depicted in Figure 1.2, “Graphical representation of the ``HelloWorld'' application design. ” :

1. Sensors send information sensed from the environment to the context layer through data sources
2. Contexts refine (aggregate and interpret) the information given by the sensors
3. Controllers transform the information given by the contexts into orders for the actuators
4. Actuators trigger actions on the environment

Figure 1.2. Graphical representation of the ``HelloWorld'' application design.

For example, the ``HelloWorld'' application is specified by a Presence context, responsible for reporting when motion is detected, and by SendMessageController that displays messages on TV screens when presence is reported. The application design is given in Figure 1.2, “Graphical representation of the ``HelloWorld'' application design. ” . The corresponding DiaSpec specification is as follows:

 
         
context Presence as Boolean { 
  when provided motion from MotionDetector
    always publish;
}
          
controller SendMessageController { 
  when provided Presence
    do SendMessage on TvMessenger; 
}
           
			

Sensors are proactive or reactive components whereas contexts, controllers and actuators are always reactive. All computations are thus initiated by a publish/subscribe interaction from the sensors. A context or a controller is defined by a list of interaction contracts separated by commas.

An interaction contract is composed of three parts:

1. The activation condition . A context can only be activated either by a data requirement from a parent context ( when required ) or a new value published from either a context or a sensor (e.g., when provided Presence , when provided motion from MotionDetector ). A controller can only be activated by a new value from a context (e.g., when provided Presence ) ;
2. The data requirements list . A context can require data from sensors or contexts (e.g., get motion from MotionDetector, Presence ). A controller can only require data from contexts (e.g., get Presence ) ;
3. The emission . When activated, a context can either always or maybe or never publishes a new value ( corresponding respectively to always publish , maybe publish and no publish declarations). For a controller, the emission part corresponds to a list of entity actions that the controller can call (e.g., do SendMessage on TvMessenger).

Given a DiaSpec description, a compiler generates a dedicated Java programming framework (stage 3 in Figure 1.1, “The development life-cycle of an SCC application using DiaSuite ”). This framework guides and supports the programmer to implement the various parts of the software system: entities, contexts and controllers. Specifically, it includes an abstract class for each component declaration, providing abstract methods to guide the programming of the application logic (e.g., triggering entity actions) and concrete methods to support the development (e.g., entity discovery).

Implementing a component is done by sub-classing the corresponding generated abstract class and by implementing each abstract method of the super class (stages 4 and 5 in Figure 1.1, “The development life-cycle of an SCC application using DiaSuite ”). For example, the implementation of the Presence context is defined as follows.

 
      	
package fr.inria.phoenix.scenario.helloworld.impl;

import fr.inria.diagen.core.ServiceConfiguration;
import fr.inria.phoenix.diasuite.framework.context.presence.AbstractPresence;
import fr.inria.phoenix.diasuite.framework.device.motiondetector.MotionFromMotionDetector;

public class Presence extends AbstractPresence {

    public Presence(ServiceConfiguration serviceConfiguration) {
        super(serviceConfiguration);
    }

    @Override
    protected Boolean onMotionFromMotionDetector(MotionFromMotionDetector motionFromMotionDetector) {
        return motionFromMotionDetector.value();
    }

}
        

By default, the component subscribes to all the motion detectors. It would have been possible to subscribe to a subset of the motion detectors by selecting them with respect to their attributes. To do so, the developer has to redefine the postInitialize method:

 
      	
@Override
  protected void postInitialize() {
    discoverMotionDetectorForSubscribe.whereLocation("LivingRoom").subscribeMotion();
}
    
		

From the taxonomy description, the compiler generates a field for each entity that can be discovered. These fields correspond to dedicated filter objects on which it is possible to add filters over attributes associated with the entity class. For example, the Presence abstract class defines a discoverMotionDetectorForSubscribe field that returns a MotionDetectorFilter This filter can be refined by adding a filter over the location attribute inherited by the MotionDetector . This entity discovery support relies on a Java-embedded, type-safe Domain-Specific Language (DSL), inspired by the fluent interfaces proposed by Fowler [Fowler, 2005]. Existing works often use strings to express queries, deferring to runtime the detection of errors in queries. By using fluent interfaces, generated from the taxonomy declarations, the Java type checker ensures that the query is well-formed at compile time. In the expression above, it is for example not possible to pass anything else than a string to the whereLocation method as the location attribute is of type String .

The onNewMotion method is declared abstract in the AbstractPresence class and has to be implemented by the developer in the Presence sub-class. This method corresponds to the application logic of the Presence component. It is automatically called by the framework when the component is activated to process a new motion-source value published by any subscribed motion detector. For the sake of simplicity, the application logic presented here is trivial as the developer simply propagates the value from the sensor to the controller. A more realistic implementation would cross-check this information using motion detectors nearby.

The implementation of a controller component is very similar. For example, the SendMessageController is defined as follows:

 
      	
package fr.inria.phoenix.scenario.helloworld.impl;

import fr.inria.diagen.core.ServiceConfiguration;
import fr.inria.phoenix.diasuite.framework.context.presence.PresenceValue;
import fr.inria.phoenix.diasuite.framework.controller.sendmessagecontroller.AbstractSendMessageController;

public class SendMessageController extends AbstractSendMessageController {

    public SendMessageController(ServiceConfiguration serviceConfiguration) {
        super(serviceConfiguration);
    }

    @Override
    protected void onPresence(PresenceValue presence, DiscoverForPresence discover) {
        if (presence.value()) {
            discover.tvMessengers().anyOne().sendMessage(null, null, "Hello World !", null);
        }
    }
}
        

The first parameter corresponds to the published value corresponding to the activation condition of the interaction contract. The discover parameter allows to call actions on entities. The DiscoverForPresence type is specialized, allowing the developer to only access entity actions that were declared in the emission part of the interaction contract.

The programming framework leverages the Java type checker to ensure the conformance between the design and the implementation. There are three basic conformance criteria: decomposition (each component in the design is implemented), interface conformance (each component implementation conforms to its design interface), and communication integrity (each component implementation communicates only with the components it is connected to in the design). In our approach, these criteria are expressed as Java typing constraints and verified by the Java type checker during compilation. As a result, our generative approach ensures that the implementation conforms by construction to its design.

Deploying an SCC application for testing purposes can be expensive and time consuming because it requires to acquire, test and configure all the necessary entities. To overcome this problem, DiaSuite provides support for testing applications with mock entities. This support corresponds to the fr.inria.phoenix.diasuite.framework.mocks.Mock class. For example, we can define the following JUnit test class:

package fr.inria.phoenix.scenario.helloworld.tests;

import static fr.inria.phoenix.diasuite.framework.mocks.Mock.*;
import static org.junit.Assert.*;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;

import fr.inria.phoenix.diasuite.framework.mocks.MotionDetectorMock;
import fr.inria.phoenix.diasuite.framework.mocks.TvMessengerMock;
import fr.inria.phoenix.scenario.mailontv.impl.ComponentBinder;

public class HelloworldTest {

    @Before
    public void setUp() throws Exception {
        underTest(ComponentBinder.class);
    }

    @After
    public void tearDown() throws Exception {
        shutdown();
    }

    @Test
    public void test() {
    	MotionDetector detector = mockMotionDetector("MockMotionDetector")
        TvMessengerMock tv = mockTvMessenger("MockTvMessenger","LivingRoom");
        // Publish a motion value
        detector.motion(true);
        // And expect a message on the tv
        assertTrue(tv.expectSendMessage("HelloWorld"));
    }
    
}

		

Using mocks, you can make the device publish certain values on certain sources using the setXXX() methods while simply the source name do a publication on the source. Then you can test for action occurring with expectXXX() methods. Those methods return true if the action occurs and match the given parameters (if a parameter is not specified, then all values are accepted). The action is supposed to not have occurred after TIMEOUT milliseconds. This TIMEOUT can be modified any time in your tests.

An application is deployed in a specific execution platform, whether distributed (e.g., RMI, Web Service, and SIP) or local (e.g., OSGi, plain Java). For now, only the plain Java and OSGi back-ends are included in the public release. In doing so, a component is prepared to be deployed in the target execution platform while initializing communication mechanisms to enable component interactions using the target platform. Associated with the Java programming framework, a Java deployment framework helps the developer select a specific execution platform (stage 7 in in Figure 1.1, “The development life-cycle of an SCC application using DiaSuite ”).

Our approach allows an application to be deployed in a running platform, reusing available entities. For example, an application may be deployed on an OSGi platform and leverage existing deployed entities. More generally, as the entities are shared by several applications, their implementations are usually deployed separately. Then, the deployment of an application consists of only deploying the context and controller components, while reusing the available entities already deployed in the platform.

For example, when using the OSGi backend, the ComponentBinder class is automatically generated. Similarly to the development of the application, this class extends the AppComponentBinder abstract class. The developer has to implement all the abstract methods of this class corresponding to the deployment of each context and controller component.

 
      	
package fr.inria.phoenix.scenario.helloworld.impl;

import fr.inria.phoenix.diasuite.framework.context.presence.AbstractPresence;
import fr.inria.phoenix.diasuite.framework.controller.sendmessagecontroller.AbstractSendMessageController;
import fr.inria.phoenix.diasuite.framework.misc.AppComponentBinder;

/* (non-Javadoc)
 * The binder to provides the various components of the application
 * @see fr.inria.phoenix.diasuite.framework.misc.AppComponentBinder
 */
public class ComponentBinder extends AppComponentBinder {

    @Override
    protected Classextends AbstractPresence> getPresenceClass() {
        return Presence.class;
    }

    @Override
    protected Classextends AbstractSendMessageController> getSendMessageControllerClass() {
        return SendMessageController.class;
    }
}
     

This chapter describes how to implement an application for the DiaSuite platform version 3.0. The DiaSuite development methodology is illustrated with a simple example named Mail On TV. The goal of the Mail on TV application is to display all important messages on a TV using the TvMessenger device. Messages are considered important when they are sent by a contact from the address book. It shows also how the plugin can be used to test the application and how it can be deployed.

To understand this documentation, you should first understand the overall principles of DiaSuite as explained in the concept section.

To develop the Mail On TV application, we will create a new DiaSuite project. In Eclipse, click File > New > Project... , then choose DiaSuite Application Project from the list.

In the next screen, give the project a name and click Finish.

A new project will be created, and the corresponding DiaSpec file will automatically be opened. By default, it has an empty context and controller. We will be filling these in with our own DiaSpec specification.

The goal of the Mail on TV application is to display all important messages on a TV using the TvMessenger device. The DiaSpec design is composed of one context named Importance and one controller named Notifier . The Importance context reacts to the lastMessage source and refines it into important messages (important messages are the ones sent by a contact of the address book). When an important message is received, the Notifier controller notifies the user on TvMessenger devices.

In the mailontv.diaspec file, we can write the following DiaSpec specification:

include "taxonomy.diaspec";

context Importance as Message {
    when provided lastMessage from Mailer 
      get contacts from AddressBook 
      maybe publish;
}

controller Notifier {
    when provided Importance 
      do SendMessage on TvMessenger;
}

			

The include keyword includes the DiaSuiteBox taxonomy that introduces the Mailer , AddressBook and the TvMessenger devices. The rest of the specification describes both the context and the controller.

You can get the graphical view of the application in the "Graphical View" tab of the DiaSpec file:

The DiaSpec specification is used to drive the rest of the development. The section called “Implementation” describes how to implement the Mail On TV application. The section called “Testing” describes how to test your application locally before deploying it on the application store. The section called “Submission to the application store” describes the deployment on the application store. Finally, The section called “Configuration Parameters” explains how to develop an application enabler that let you have configuration parameters for your application.

Now, we need to implement the context and controller components. To do so, we generate stubs from the DiaSpec specification, by right-clicking on the DiaSpec file and selecting "DiaSuite" / "Generate Context and Controller Stubs".

We will first look at the stub generated for the Importance context. The methods we will need to implement here (they can be obtained using the Eclipse feature to auto-generate missing method stubs, inherited from the abstract class we are extending) are onLastMessageFromMailer .

The method onLastMessageFromMailer is called whenever a new mail message is received. The method signature reflects the interaction contract of the context:

protected ImportanceValuePublishable onLastMessageFromMailer(
            LastMessageFromMailer lastMessageFromMailer,
            DiscoverForLastMessageFromMailer discover);

The first parameter contains the actual message received whenever the Mailer publishes, the second parameter, discover, is the mechanism for getting access to an AddressBook. Finally, the return type of the function is how we publish whatever value our context computes. We only want to publish if the sender of the email is in our contact list, otherwise we will ignore the email. Let us examine the implementation of this example:

protected ImportanceValuePublishable onLastMessageFromMailer(
        LastMessageFromMailer lastMessageFromMailer,
        DiscoverForLastMessageFromMailer discover) {

    // retrieve the pushed value from the method parameter
    Message message = lastMessageFromMailer.value();    

    // pull the list of contacts from the AddressBook device by
    // using discovery
    List contacts = discover.addressBooks().anyOne()
				.getContacts(message.getSender());
            
	// if the sender was found among address book contacts
		if ((contacts != null) && (contacts.size() != 0))
			// publish the message
			return new ImportanceValuePublishable(message, true);

    // in other case do not publish the value
    return new ImportanceValuePublishable(message, false);
}

The ImportanceValuePublishable type of the return value comes from the maybe publish declaration of the interaction contract. The first parameter is the value our context returns after computation, the second value, a boolean, says whether we want to publish the result or not. This corresponds to an option type, like in functional languages. In this example, this controls whether the mail gets displayed on the screen or not, since the controller will subscribe to our notifications.

Finally, the controller should be implemented. It is simpler, since it should only subscribe to the context, and will write to the screen any message that is published. Starting with the generated file, Notifier.java , we can use Eclipse's feature to generate missing function stubs. This allows us to fill in the onImportance method, which is triggered whenever the context publishes a value. This time we will only be needing the discovery parameter to find TV messengers, since we are only interested in the published value, and do not need to retrieve other values.

protected void onImportance(ImportanceValue importance,
        DiscoverForImportance discover) {

    // here we retrieve the value pushed from the Importance context
    Message message = importance.value();

    String messageTitle = message.getTitle();
    String messageContent = message.getText();
    List messageAttachements = message.getAttachments();

    // here we use discovery in order to trigger the sendMessage method
    discover.tvMessengers()
            .anyOne()
            .sendMessage(new Contact(), messageTitle, messageContent,
                    messageAttachements);
}

See how we use the value() method to retrieve the Message, then we extract the applicable parts of the message to forward to any available TV messenger. Once again, we could broadcast to all deployed TV devices by using all() instead of anyOne() .

The last step is to define the deployment of the DiaSpec components defined in the DiaSpec specification. This is done by customising the ComponentBinder class, which is an auto generated stub. For each method, for example getImportanceClass , simply returns the corresponding implementation class:

    @Override
    public Classextends AbstractImportance> getImportanceClass() {
        return Importance.class;
    }