Type document : CR	
PROJET RNTL MORSE	Date :13/10/04	
		N° doc : 
MORSE-CR-041013-JPV
	
Sous-projets n° 1,2,5
		Rédacteur (s): 
VELU J.Pierre	

Tâches : 			

Compte-rendu de la réunion 
du 8 Octobre 2004

Etaient présents : M.Assouline (AONIX), F.Kordon (LIP6), F.Gilliers (Sagem/LIP6), JM. Richard-Foy (AONIX), JP Vélu (Sagem) 

Le but de cette réunion était surtout axé sur la conduite du projet et la définition plus précise des tâches de chacun.

1	Etat d’avancement

1.1	Sagem

1.1.1	Introduction

Une réunion avec l’URD14 a eu lieu le 29 septembre 2004. Le but était de définir les grandes lignes d’une application-témoin :

1.	qui ne contienne pas d’aspects confidentiels,
2.	qui soit répartie (ou qui peut être vue comme telle),
3.	dont les communications sont asynchrones,
4.	qui fasse avancer à la fois MORSE et Sagem,
5.	qui puisse être vue comme l’exemple final du projet : ce qui exige une certaine continuité dans la suite des exemples que l’on traitera.

Le nombre de conditions est important ce qui explique qu’il est difficile de trouver une telle application et que le choix actuel (décrit ci-dessous) n’est pas encore complètement définitif.

1.1.2	L’application-témoin candidate

La figure ci-dessous définit le cadre de ce qui pourrait être proposé. 

Dans un calcul central (MCU) sont implantées des fonctions Fi requises pour le vol du drone. Ces fonctions sont alimentées en données d'une part par un mini-calculateur d'acquisition (ACQ) [données moteur] et de l'autre par une centrale inertielle [données de localisation]. Les bus et les protocoles qui seront utilisés ne sont pas encore fixés. Il est possible que la communication ACQ/MCU passe par un bus CAN et que la communication centrale/MCU passe par un bus 1553.

Par ailleurs, pour des raisons de sûreté de fonctionnement, il a été décidé que le calculateur MCU sera doublé (dans un second temps). Le système réparti qui pourrait être étudié par MORSE serait le suivant :

Système  { ACQ, C1,…Cn , Centrale }  Application-témoin		(1)

où les Ci sont des composants déployés dans les MCU pour la réalisation des fonctions-métiers et la réalisation de la redondance.

Les protocoles Centrale/MCU sont actuellement synchrones/asynchrones (commandes + données fournies à différentes fréquences) mais rien n'est défini concernant la sémantique de la communication ACQ/MCU et le protocole MCU/MCU. Il en est de même pour Ci /Ci.

Durant l'étude, on pourrait supposer, concernant ce système, que  :

•	les différents composants sont déployés de différentes façons,
•	que les communications sont toutes asynchrones,
•	que les bus ne sont pas ceux finalement envisagés.

On aura toute liberté, en cours de projet,  pour modifier cet exemple "dans tous les sens".

Toutefois, pour que l'application finale (qui en résultera) reste industrielle et réaliste, il faudra que les fonctionnalités incarnées par les Ci soient réelles. L'idée sera de considérer seulement quelques-unes des fonctions Fi et de traiter les différents exemples du projet MORSE en "les tirant" à partir de ces fonctions.

Il est envisagé d’autres séances de travail avec l'URD14 pour au moins :

1.	ouvrir les boîtes MCU : quelles sont les fonctions Fi ?
2.	choisir celles qui nous intéressent (et qui ne sont pas confidentielles),
3.	écrire les modèles UML et LfP impliquant les composants Ci,
4.	définir des protocoles de communications réalistes (ou réalisables),

1.1.3	Conclusion

Les partenaires et en particulier le LIP6 et le Labri demandent à ce que les propriétés pertinentes (correspondant à un besoin industriel) de cette application soient recensées au plus tôt.

Les tâches identifiées qui reviennent à Sagem sont donc les suivantes :

SAGEM 
			
Tâche APPLI.1	Fixer l’application-témoin
Enoncer quelques propriétés-candidates interessantes à étudier
	Fin novembre	
Tâche APPLI.2	Ecrire les spécifications de cette application
Enoncer les propriétés à vérifier
	Fin décembre	

1.2	AONIX

Il est prévu une personne supplémentaire pour AMEOS. La prise en compte de LfP par ACD (génération de code) devrait donner des premiers résultats courant novembre. Par contre, la tâche UML  LfP ne pourra être envisagée qu’à partir de Mars 2005.

M.Assouline a présenté une étude concernant ce dernier point plus particulièrement la définition du profil UML pour LfP. L’exemple en cours c’est-à-dire le client/serveur a été traité, toutefois il manque les diagrammes de comportement (y compris dans le profil).

Les grandes lignes de ce profil sont les suivantes (voir les transparents de Maurice pour plus de précision) :

•	Les attributs des bindings sont représentés par des noms associés aux ports du composants UML représentant une classe LfP (stéréotype lfp_class). Certains auront des valeurs par défaut : multiplicity=1, ordering=fifo, capacity=1.

•	Les binders sont représentés par des liens boules/sockets entre les composants. Les ports conjugés ont la même interface.

•	Le sens des appels est le sens socket  boule, il faut donc deux connecteurs d’assemblage pour mentionner les échanges croisés.

•	Le type port LfP sera représenté par une classe UML munie du stéréotype lfp_port_type. 

•	On n’indiquera pas le type des ports mais seulement leur nom.

Par ailleurs, il a été mis en évidence une modification de LfP concernant les ports. Ci-dessous les propositions de F.Gilliers (qu'il faudra discuter lors de la prochaine réunion) :

A- MODIFICATION CONCERNANT LES BINDERS D'ACTIVATION D'UNE METHODE

Comportement actuel : Chaque méthode déclare un binder d'activation, il s'agit du binder sur lequel est attendu le message d'activation de la méthode lorsque celle-ci peut être exécutée. Ce binder est une constante et ne peut être changé.

Comportement proposé : FG propose de préciser le binder d'activation dans l'instruction d'attente de message. Cette instruction permettrait donc :
1. de préciser la liste des méthodes activables
2. de préciser le ou les binders d'activations de chaque méthode dans l'état courant. 

FG propose de laisser la possibilité de laisser un binder d'activation par défaut dans la déclaration de la méthode. Cette déclaration serait utilisée si le binder d'activation n'est pas précisé dans l'instruction d'attente de message. Cela permet de :

1. rester "backward compatible" avec la sémantique utilisées dans les modèles existants (très important).
2. faciliter l'écriture des composants dont les méthodes ont des binders d'activation constants. 

Justification : La proposition permet de rendre la gestion des files de messages plus dynamiques et permet de prendre en compte l'état coutant du composant. Elle est "backward compatible" avec l'existant. Elle peut être résolue au moment de la "compilation" du modèle LfP et n'introduit pas de modification du runtime.

B- AJOUT DE CANAUX DIRECTS ENTRE LES CLASSES D'UN MODELE

Comportement actuel : LfP ne permet pas de relier directement deux classes par une file de message. Il est nécessaire d'intercaller un média. Ce mécanisme est très intéressant lorsque les protocoles de routages entre composants sont complexes. Néanmoins dans les cas les plus simples, ce mécanisme introduit des recopies de messages inutiles, ainsi que la création inutile de la thread corresopndant au média. 

Ajout proposé à LfP : FG propose donc de définir un type "link" ou "channel" (nom encore à définir) permettant de relier deux classes entre elles. Ce canal serait de type "bi-directionnel asymétrique" : un sens dédié aux messages d'activation, l'autre sens dédié aux éventuels messages de retour. On définit deux types de canaux : 

1. les canaux statiques (multiplicité all des binders). Toute classe reliée au canal sur le diagramme d'architecture peut y déposer un message
2. les canaux "dynamiques" multiplicité 1)  Toute classe reliée à la classe qui déclare le canal peut y déposer un message. Les channels sont en plus définis de manière suivante:

1. Les canaux statiques sont instanciés lors de l'initialisation des classes. La liste des classes pouvant envoyer et recevoir des messages est spécifiée dans sa déclaration. 

2. Les canaux "dynamiques" sont instanciés lorsque la classe qui les déclare comme attribut est instanciée (même shéma que pour les binders). Ils des un "point d'entrée" de la classe. Toutes les classes reliée sur le diagramme d'architecture à la classe qui définit le canal peuvent y déposer des messages. La classe qui définit le canal peut s'en servir pour envoyer les messages de retour correspondant. 

Justification : Cette modification permet de modéliser simplement des liens de communication point à point entre classes. On évite les recopies inutiles pour la modélisation de schémas d'interaction simples entre les composants. On reste backward compatible avec la sémantique actuelle du langage ce qui permet de conserver les spécifications existantes. 

Concernant la méthodologie (qui n’a pas avancé depuis longtemps), il a été remarqué qu’au fil des travaux et du traitement des exemples des éléments méthodologiques seraient “ naturellement ” considérés. Ainsi dans un premier temps, nous n’envisageons de programmer explicitement de tâches sur ce sujet.

Les tâches identifiées qui reviennent à Aonix sont donc les suivantes :

AONIX
			
Tâche CLIENT/SERVEUR
	Diagramme de comportement
	Fin Novembre ?	
Tâche PROFIL.1	Terminer le profil (diagrammes de comportement)
	Fin Novembre ?	
Tâche GENCODE.1	Prise en compte de LfP par ACD
	Fin Novembre	

Il faudra préciser très vite :
•	Les dates de terminaison des deux premières tâches,
•	La tâche GENCODE.1 (voir ci-dessous).

On rappelle ci-dessous les différentes tâches attachées à l'activité AONIX (Cf document MORSE-DOW du 17/06/04) . La tâche GENCODE.1 correspond à T3, T4.1.

T1. Réalisation d’un profil UML et définition des règles de transformation UML->LfP
T1.1. Compréhension de l’exemple en cours (client/serveur)
T1.2. Etude UML2.0 (capsules, diagrammes d’activités…)
T1.3. Etude ROOM (vérifier le bien-fondé de cette exigence du partenaire Sagem)
T1.4. Identification des concepts LfP et identification concepts UML correspondant
(composant, média, binder, port)
T2. Mise en oeuvre des règles de transformation UML  LfP
T2.1. Choix de la technique de transformation
T2.2. Implémentation des règles
T3. Définition des règles de transformation LfP  Jlangages Java et C++
T3.1. Définition des règles LfP  Java
T3.2. Définition des règles LfP  C++
T4. Mise en oeuvre des règles de transformation LfP  langages Java et C++
T4.1. Choix de la technique de transformation
T4.2. Réflexion sur la mise en facteur de la transformation
T4.3. Implémentation des règles pour Java
T4.4. Implémentation des règles pour C++
T5. Rédaction d’un document de méthodologie de développement.
T6. Activité de communication dans le cadre de la dissémination du produit des travaux.

1.3	LIP6/LABRI

En vrac…

L’interface graphique de LfP est en cours de portage sur Windows.

Pour des raisons d’interfaçage entre les différents coopérants, il est prévu une spécification textuelle de LfP.

F.Bréant a identifié les homomorphismes qui seront utilisés pour LfP. Toutefois, il n’existe pas aujourd’hui d’outil intégré pour la vérification, les différentes opérations sont faites à la main. 

La vérification est confrontée à une grande explosion combinatoire (l’exemple en cours – client/serveur – pourtant simple montre qu’il y a un grand nombre d’états à considérer). L’une des voies explorées est de construire un espace d’état limité uniquement par les propriétés que l’on veut étudier. Une personne supplémentaire doit traiter cette question au LABRI. Actuellement elle est en train d’élaborer un état de l’art concernant OCL.

Par ailleurs, des travaux doivent être lancés concernant l’expression des propriétés et également la vue déploiement pour LfP.

Les tâches recensées sont les suivantes  (on rappelle que la tâche LfP.2 doit être précisée) :

LIP6/Labri
			
Tâche WINDOWS	Portage de LfP sur Windows		
Tâche LfP.1	Spécification textuelle de LfP	Fin novembre	
Tâche LfP.2	Modification concernant les ports 	Fin novembre	
Tâche OCL	Etat de l’art OCL	Fin novembre	
Tâche LfP.3	Expression des propriétés	Fin décembre	
Tâche LfP.4	Vue déploiement	Fin décembre	
Tâche DDD.1	Optimisation de l’espace des états		
Tâches DDD.2	Spécifications de l’outil de vérification		

Des interrogations subsistent encore concernant l’outil de vérification :

•	Que sait-on de sa faisabilité ?– en particulier, aura-t-on un outil pour traiter dans un an l’application-témoin ?
•	Quelles sont les tâches qui s’y rattachent et auxquelles il est lié ?
•	Quelle road-map est envisagée ?
2	Autres points importants qui feront avancer…

•	LfP textuel (rappel),
•	Définition du prochain exemple à traiter (après novembre) – on s’orienterait vers une messagerie instantanée –
•	Exhibition des propriétés à vérifier pour l’application-témoin (rappel)
•	Un document concernant les homomorphismes identifiés pour LfP,
•	Une roadmap pour la vérification (les tâches principales et quelques jalons).

3	Administratif

Il a été décidé d’émettre tous les 15 jours un petit compte-rendu d’avancement concernant les tâches que nous avons chacun en charge. Pour faire simple, le mieux c’est d’adresser ce CR à JPV qui les rediffusera.

Prochaine date de réception du compte-rendu : 22 octobre.

Prochaines réunions : 5 novembre (chez Sagem Ponant 9H 30), 26 novembre, 17 décembre.