Vous êtes sur la page 1sur 18

Transformation de modèles UML

vers programmes Fiacre

Transformation de modèles UML vers programmes Fiacre HENG Sotharith heng.sotharith@gmail.com 03 février 2012
Transformation de modèles UML vers programmes Fiacre HENG Sotharith heng.sotharith@gmail.com 03 février 2012
Transformation de modèles UML vers programmes Fiacre HENG Sotharith heng.sotharith@gmail.com 03 février 2012
Transformation de modèles UML vers programmes Fiacre HENG Sotharith heng.sotharith@gmail.com 03 février 2012
Transformation de modèles UML vers programmes Fiacre HENG Sotharith heng.sotharith@gmail.com 03 février 2012
Transformation de modèles UML vers programmes Fiacre HENG Sotharith heng.sotharith@gmail.com 03 février 2012
Transformation de modèles UML vers programmes Fiacre HENG Sotharith heng.sotharith@gmail.com 03 février 2012

HENG Sotharith

heng.sotharith@gmail.com 03 février 2012

HENG Sotharith heng.sotharith@gmail.com 03 février 2012 Encadrant: Philippe DHAUSSY

Encadrant: Philippe DHAUSSY

HENG Sotharith heng.sotharith@gmail.com 03 février 2012 Encadrant: Philippe DHAUSSY philippe.dhaussy@ensta-bretagne.fr
HENG Sotharith heng.sotharith@gmail.com 03 février 2012 Encadrant: Philippe DHAUSSY philippe.dhaussy@ensta-bretagne.fr
Plan de présentation • Motivation • Diagrammes UML à traduire • Règles de traduction •
Plan de présentation • Motivation • Diagrammes UML à traduire • Règles de traduction •
Plan de présentation • Motivation • Diagrammes UML à traduire • Règles de traduction •
Plan de présentation • Motivation • Diagrammes UML à traduire • Règles de traduction •

Plan de présentation

Plan de présentation • Motivation • Diagrammes UML à traduire • Règles de traduction • Conclusion

Motivation

Diagrammes UML à traduire

Règles de traduction

Conclusion

1/13
1/13
Motivation | Diagrammes UML à traduire | Règles de traduction | Conclusion
Motivation | Diagrammes UML à traduire | Règles de traduction | Conclusion

Motivation

à traduire | Règles de traduction | Conclusion Motivation Pourquoi a-t-on besoin de cette transformation? •
à traduire | Règles de traduction | Conclusion Motivation Pourquoi a-t-on besoin de cette transformation? •
à traduire | Règles de traduction | Conclusion Motivation Pourquoi a-t-on besoin de cette transformation? •

Pourquoi a-t-on besoin de cette transformation?

Pour assurer la construction du système non défaillant, alors les

modèles UML doivent être traduits aux codes formels qui sont exploitables par les model-checkers.

L’ENSIETA a développé OBP Explorer, un model-checkers qui a pour entrée un modèle du système en Fiacre, des diagrammes CDL et des

patrons d’exigences.

en Fiacre, des diagrammes CDL et des patrons d’exigences. Alors, on a besoin d’un transformation de
en Fiacre, des diagrammes CDL et des patrons d’exigences. Alors, on a besoin d’un transformation de

Alors, on a besoin d’un transformation de modèles UML en

programmes Fiacre

voir [Quei82, Clark86, Berth04, Fern1996, Lars97, Bern07, Philip11]

2/13
2/13

Motivation | Diagrammes UML à traduire | Règles de traduction | Conclusion

1

|

2

| 3

Diagrammes UML à traduire

| Conclusion 1 | 2 | 3 Diagrammes UML à traduire  Diagrammes de classes: voir
| Conclusion 1 | 2 | 3 Diagrammes UML à traduire  Diagrammes de classes: voir
| Conclusion 1 | 2 | 3 Diagrammes UML à traduire  Diagrammes de classes: voir

Diagrammes de classes:

voir [Max08, Hab04, Philip05]

 Diagrammes de classes: voir [Max08, Hab04, Philip05] Représentent la vue statique du système (la structure
 Diagrammes de classes: voir [Max08, Hab04, Philip05] Représentent la vue statique du système (la structure
 Diagrammes de classes: voir [Max08, Hab04, Philip05] Représentent la vue statique du système (la structure

Représentent la vue statique du système (la structure interne du système)

Eléments traduits:

Classes

Attributs

Méthodes

Collaborations

Concepts d’objet

 Eléments traduits: • Classes • Attributs • Méthodes • Collaborations • Concepts d’objet 3/13
3/13
3/13

Motivation | Diagrammes UML à traduire | Règles de traduction | Conclusion

1

|

2

| 3

| Règles de traduction | Conclusion 1 | 2 | 3  Diagrammes d’états: voir [Max08,
| Règles de traduction | Conclusion 1 | 2 | 3  Diagrammes d’états: voir [Max08,

Diagrammes d’états:

voir [Max08, Hab04, Philip05]

Représentent la vue dynamique du système

Hab04, Philip05] Représentent la vue dynamique du système  Eléments traduits: • Etats • Sous- machines
Hab04, Philip05] Représentent la vue dynamique du système  Eléments traduits: • Etats • Sous- machines
Hab04, Philip05] Représentent la vue dynamique du système  Eléments traduits: • Etats • Sous- machines

Eléments traduits:

Etats

Sous-machines d’états

Transitions

Actions

Appel d’opérations

traduits: • Etats • Sous- machines d’états • Transitions • Actions • Appel d’opérations 4/13
4/13
4/13

Motivation | Diagrammes UML à traduire | Règles de traduction | Conclusion

1

|

2

| 3

| Règles de traduction | Conclusion 1 | 2 | 3  Diagrammes d’objets: voir [Max08,
| Règles de traduction | Conclusion 1 | 2 | 3  Diagrammes d’objets: voir [Max08,

Diagrammes d’objets:

voir [Max08, Hab04, Philip05]

Représentent la configuration initiale du système

Philip05] Représentent la configuration initiale du système  Eléments traduits: • Objets • Relations 5/13
Philip05] Représentent la configuration initiale du système  Eléments traduits: • Objets • Relations 5/13

Eléments traduits:

Objets

Relations

Philip05] Représentent la configuration initiale du système  Eléments traduits: • Objets • Relations 5/13
Philip05] Représentent la configuration initiale du système  Eléments traduits: • Objets • Relations 5/13
5/13
5/13

Motivation | Diagrammes UML à traduire | Règles de traduction | Conclusion

1

|

2

|

3 |

4 | 5

|

6 |

7

Règles de traduction

2 | 3 | 4 | 5 | 6 | 7 Règles de traduction  Configuration
2 | 3 | 4 | 5 | 6 | 7 Règles de traduction  Configuration
2 | 3 | 4 | 5 | 6 | 7 Règles de traduction  Configuration

Configuration initiale:

voir [Hab04]

de traduction  Configuration initiale: voir [Hab04] D i a g r a m m e

Diagrammes dobjets

D i a g r a m m e s d ’ o b j e

processus de configuration initiale

Classe d’un objet actif + son diagramme d’état

initiale Classe d’un objet actif + son diagramme d’état Code du processus Fiacre La relation entre

Code du

processus

Fiacre

actif + son diagramme d’état Code du processus Fiacre La relation entre les objets sera traduit

La relation entre les objets sera traduit par sa collaboration

+ son diagramme d’état Code du processus Fiacre La relation entre les objets sera traduit par
6/13
6/13

Motivation | Diagrammes UML à traduire | Règles de traduction | Conclusion

1

|

2

|

3 |

4 | 5

|

6 |

7

Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Vue
Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Vue
Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Vue
Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Vue

Vue statique:

voir [Max08, Hab04, Philip08, Jul07]

Classes:

Classe active sera traduit par le processus Fiacre.

Classe inactive sera traduit par le processus Fiacre avec un seul état qui demeure vide ou par le type record en Fiacre.

Attributs:

Attributs de types primitifs seront traduits par les variables de type

basic en Fiacre.

Attributs qui sont les références vers des instances des autres classes seront traduits par pid.

Collaboration:

classes seront traduits par pid .  Collaboration: • Pour chaque collaboration, deux ports sont créés

Pour chaque collaboration, deux ports sont créés entre le processus correspondant aux processus liés.

7/13
7/13

Motivation | Diagrammes UML à traduire | Règles de traduction | Conclusion

1

|

2

|

3 |

4 | 5

|

6 |

7

Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Opérations:
Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Opérations:

Opérations:

Un processus est créé pour chaque opération.

Deux signaux sont créés pour chaque opération. Ces signaux correspondent à l’appel et au retour de l’opération.

correspondent à l’appel et au retour de l’opération.  Concepts d’objet:  Héritage: • L’héritage
correspondent à l’appel et au retour de l’opération.  Concepts d’objet:  Héritage: • L’héritage

Concepts d’objet:

Héritage:

L’héritage des machines d’états ne est pas traduit.

On va recopier les propriétés de la classe mère dans chaque classe fille.

Accès concurrent aux attributs:

Il faut garantir qu’une opération primitive ne possède qu’une seule instance en même temps.

attributs: • Il faut garantir qu’une opération primitive ne possède qu’une seule instance en même temps.
8/13
8/13

Motivation | Diagrammes UML à traduire | Règles de traduction | Conclusion

1

|

2

|

3 |

4 | 5

|

6 |

7

Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Vue
Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Vue

Vue dynamique:

voir [Max08, Hab04, Philip08, Jul07]

automate en Fiacre

Diagramme d’état Sous-machines d’états

Fiacre Diagramme d’état  Sous- machines d’états • Un processus sera créé pour chaque sous- machine

Un processus sera créé pour chaque sous-machine d’états

processus sera créé pour chaque sous- machine d’états correspondant. • Le processus mère passe son pid
processus sera créé pour chaque sous- machine d’états correspondant. • Le processus mère passe son pid
processus sera créé pour chaque sous- machine d’états correspondant. • Le processus mère passe son pid

correspondant.

Le processus mère passe son pid lors de la création de la sous- machine d’état, et reste dans d’état wait. Il continue son exécution lorsqu’il reçoit le message d’acquittement.

Le processus mère peut passer à un autre état s’il reçoit un signal

externe.

le message d’acquittement. • Le processus mère peut passer à un autre état s’il reçoit un
9/13
9/13

Motivation | Diagrammes UML à traduire | Règles de traduction | Conclusion

1

|

2

|

3 | 4 | 5

|

6 |

7

| Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7 
| Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7 
| Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7 
| Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7 
| Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7 

Transitions UML:

Lorsque dans une transition, nous avons une condition, on crée un état instable « S » dont les transitions sortantes traduisent les éléments de la condition.

L’état « S » sera traduit par un état simple en Fiacre dont sa transition

vers les autres états peut effectuer sans attendre la réception des signaux.

simple en Fiacre dont sa transition vers les autres états peut effectuer sans attendre la réception
10/13
10/13

Motivation | Diagrammes UML à traduire | Règles de traduction | Conclusion

1

|

2

|

3 |

4 | 5

|

6 |

7

Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Actions
Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Actions
Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Actions
Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Actions
Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Actions

Actions en entrée et en sortie d’un état

Il faut que toutes les transitions fassent la même opération.

La traduction de ces modèles peut se faire en mettant un état instable « S » juste avant l’état « destination ».

On ne peut pas effectuer la même transformation pour les actions en sortie d’un état.

« destination ». • On ne peut pas effectuer la même transformation pour les actions en
11/13
11/13

Motivation | Diagrammes UML à traduire | Règles de traduction | Conclusion

1

|

2

|

3 |

4 | 5

|

6 |

7

Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Appel
Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Appel
Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Appel
Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Appel
Conclusion 1 | 2 | 3 | 4 | 5 | 6 | 7  Appel

Appel d’opération

On crée un processus pour chaque opération. A la fin de l’opération, il enverra un message d’acquittement au processus appelant et s’arrêtera.

Le processus courant d’évolution crée le processus correspondant et

se place dans un état d’attente de fin de l’opération.

d’évolution crée le processus correspondant et se place dans un état d’attente de fin de l’opération.
12/13
12/13
Motivation | Diagrammes UML à traduire | Règles de traduction | Conclusion
Motivation | Diagrammes UML à traduire | Règles de traduction | Conclusion

Conclusion

à traduire | Règles de traduction | Conclusion Conclusion • On a défini les règles importants
à traduire | Règles de traduction | Conclusion Conclusion • On a défini les règles importants

On a défini les règles importants pour la transformation de

a défini les règles importants pour la transformation de modèles UML en programmes Fiacre.  Difficultés
a défini les règles importants pour la transformation de modèles UML en programmes Fiacre.  Difficultés
a défini les règles importants pour la transformation de modèles UML en programmes Fiacre.  Difficultés

modèles UML en programmes Fiacre.

Difficultés et Perspectives:

On a présenté la notion pid, mais on ne sait encore comment le modéliser et le référencer dans le programme Fiacre.

On a représenté l’état instable par un état simple en Fiacre. On pense qu’il n’est encore suffisant, alors il faut encore l’examiner.

La lecture des fichiers XMI du modèle UML Rhapsody va être utilisé pour leur analyse.

13/13
13/13
Merci de votre attention! Questions?
Merci de votre attention!
Questions?
Références  Queille J.-P., Sifakis J. Specification and verification of concurrent systems in CESAR. Proceedings
Références  Queille J.-P., Sifakis J. Specification and verification of concurrent systems in CESAR. Proceedings
Références  Queille J.-P., Sifakis J. Specification and verification of concurrent systems in CESAR. Proceedings

Références

Queille J.-P., Sifakis J.

Specification and verification of concurrent systems in CESAR.

Proceedings of the 5th Colloquium on International Symposium on Programming,

Springer- Verlag, London, UK, p. 337-351, 1982.

Clarke E., Emerson E., Sistla A.

Automatic verification of finite-state concurrent systems using temporal logic specifications .

ACM Trans. Program. Lang. Syst., vol. 8, n° 2, p. 244- 263, 1986.

Berthomieu B., Ribet P.-O., Verdanat F.

The tool TINA - Construction of Abstract State Spaces for Petri Nets and Time Petri Nets. International Journal of Production Research, 2004.

Fernandez J.-C., Garavel H., Kerbrat A., Mounier L., Mateescu R., Sighireanu M.

CADP : A Protocol Validation and Verification Toolbox. CAV ’96 : Proceedings of the 8th International Conference on Computer Aided Verification, Springer-Verlag, London, UK, ’96 : Proceedings of the 8th International Conference on Computer Aided Verification, Springer-Verlag, London, UK, p. 437-440, 1996.

Références  Larsen K. G., Pettersson P., Yi W. UPPAAL in a Nutshell . International
Références  Larsen K. G., Pettersson P., Yi W. UPPAAL in a Nutshell . International
Références  Larsen K. G., Pettersson P., Yi W. UPPAAL in a Nutshell . International
Références  Larsen K. G., Pettersson P., Yi W. UPPAAL in a Nutshell . International

Références

Larsen K. G., Pettersson P., Yi W.

UPPAAL in a Nutshell .

International Journal on Software Tools for Technology Transfer, vol. 1, n° 1-2, p. 134-

152, 1997.

Bernard Berthomieu, Frédéric Lang.

Le langage pivot asynchrone Fiacre. réunion WP3 Topcased - LAAS - Toulouse, 13 novembre 2007

Maxime FROMENTIN.

Identification des mécanismes de transformation entre UML et IF (V1). 7 novembre 2008

Philippe DHAUSSY, « Plugin UML_to_IF », version 0: 08/10/2008

Philippe DHAUSSY, « La transformation UML vers IF Base de transparents », version du 21 mai 2005

Julien AUVRAY, Mémoire de projet de fin d’études « Validation formelle de modèles

UML », promotion 2007

Références  Maxime FROMENTIN. Identification des mécanismes de transformation entre UML et IF (V4) »,
Références  Maxime FROMENTIN. Identification des mécanismes de transformation entre UML et IF (V4) »,
Références  Maxime FROMENTIN. Identification des mécanismes de transformation entre UML et IF (V4) »,
Références  Maxime FROMENTIN. Identification des mécanismes de transformation entre UML et IF (V4) »,

Références

Maxime FROMENTIN.

Identification des mécanismes de transformation entre UML et IF (V4) », version du 26 février 2009

Habart OLIVIER.

Rapport de PFE « Modélisation et validation formelles de propriétés en environnement », 23 juillet 2004

B. Berthomieu, P.-O. Ribet, F. Vernadat, J. Bernartt, J.-M. Farines, J.-P. Bodeveix, M.

Fi-lali, G. Padiou, P. Michel, P. Farail, P. Gaufillet, P. Dissaux, and J.-L. Lambert.

Towards the verification of real-time systems in avionics: the Cotre approach volume 80 of Electronic Notes in Theoretical Computer Science, pages 201216. Elsevier, June 2003.

Hubert Garavel and Fr´ed´eric Lang.

NTIF: A general symbolic model for communicating sequential processes with data

volume 2529 of Lecture Notes in Computer Science, pages 276291. Springer Verlag,

November 2002.

Philippe Dhaussy, Jean-Charles Roger, « OBPe (OBP Explorer) Document »