Outils pour utilisateurs
recherche:projets:syncomp:meetings:meeting130415
Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
|
recherche:projets:syncomp:meetings:meeting130415 [2015/04/13 12:16] tigli [Cadre Général : Une approche Middleware originale] |
recherche:projets:syncomp:meetings:meeting130415 [2015/04/13 12:49] (Version actuelle) tigli [Schéma de l'outil de design et génération de l'automate] |
||
|---|---|---|---|
| Ligne 29: | Ligne 29: | ||
| * Ces opérateurs sont souvent spécifiques à un type et donc fournis par défaut sur des types prédéfinis. | * Ces opérateurs sont souvent spécifiques à un type et donc fournis par défaut sur des types prédéfinis. | ||
| * L'utilisation d'autres types nécessite une spécification de ces types et des prédicats associés par l'utilisateur (ex. un type énumération, avec un opérateur d'appartenance d'un élément à cet ensemble) | * L'utilisation d'autres types nécessite une spécification de ces types et des prédicats associés par l'utilisateur (ex. un type énumération, avec un opérateur d'appartenance d'un élément à cet ensemble) | ||
| - | * | + | * En fait si on veut garder de la souplesse dans la chaine d'observation qui nous permettra de modifier "comment" le predicat est évalué alors il vaut mieux revenir au signaux purs en entrée de l'automate (résultats post évaluation / post prédicat). Exemple si je veux pouvoir remplacer un capteur de chute par SUP alors il ne faut pas intègrer pas le prédicat dans l'automate mais prendre en entrée le signal pure "chute vrai/faux" pour pouvoir wrapper l'un des deux capteurs indifféremment. |
| + | |||
| + | ==== Schéma de l'outil de design et génération de l'automate ===== | ||
| + | |||
| + | |||
| + | {{:recherche:projets:syncomp:meetings:syncom.jpg?200|photo tableau}} | ||
| + | |||
| + | ==== Roadmap : ==== | ||
| + | |||
| + | * Clarifier la notion de dispositif et Système Ambiant : Cf. papier ci-dessus | ||
| + | * Générer dans un Bean un automate avec des signaux d'entrée et de sortie purs à partir de clem | ||
| + | * L'automate sera celui du dispositif (ex. lampe) | ||
| + | * Ajouter des contraintes avec le langage DCL entre deux lampes d'une même pièce | ||
| + | * Ces deux lampes / dispositifs font alors parties d'un même système ambiant car couplés ( quelque soit l'état d'une lampe si l'autre est allumée la pièce est allumée). | ||
| + | * Calcul de la composition des automates des dispositifs du système pour modéliser les accès concurrent au système + les contraintes associées modélisée sous forme d'automate => model checking | ||
| + | * Génération du bean de l'automate correspondant (par dispositif ? par système ?) avec événement d'entrée et de sortie pur. | ||
| + | * Premier test de la chaine de conception / déploiement / exécution logicielle sous WComp ASAP pour se faire une idée des incréments nécessaires. | ||
| + | |||
recherche/projets/syncomp/meetings/meeting130415.1428920217.txt.gz · Dernière modification: 2015/04/13 12:16 par tigli
Outils de la page
Sauf mention contraire, le contenu de ce wiki est placé sous les termes de la licence suivante : CC Attribution-Noncommercial-Share Alike 4.0 International
