Une approche dirigée par les modèles pour une conception flexible des systèmes distribués

(1)

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

UNIVERSITÉ MOHAMED KHIDER BISKRA

Faculté des Sciences Exactes et des Sciences de la Nature et de la Vie

Département d’Informatique

THÈSE

Pour l’obtention du diplôme de

Docteur en Sciences

Une approche dirigée par les modèles pour une conception

flexible des systèmes distribués

Présentée par : Ahmed HARBOUCHE

Directeur de thèse : Pr. NourEddine DJEDI

Soutenue le : 19 Juin 2018

Devant le jury composé de

Président : Dr Abdelmalik BACHIR Professeur Université Med Khider, Biskra.

Rapporteur : Dr NouEddine DJEDI Professeur Université Med Khider, Biskra.

Examinateurs: Dr Hamid AZZOUNE Professeur USTHB, Alger.

Dr Allaoua CHAOUI Professeur Université Constantine 2.

Dr Hammadi BENNAOUI MCA Université Med Khider, Biskra.

Biskra, Algérie.

(2)

ﻟا

ﺺﺨﻠﻤ

نأ مﻮﯿﻟا ﺪﻘﺘﻌﯾ

ﺔﺳﺪﻨﮭﻟا

ﻟا

ﺔﻋﻮﻓﺪﻤ

ﺑ

ﻟﺎ

جذﺎﻤﻨ

)

(IDM

ﺖﺒﻠﺟ

اﺮﯿﯿﻐﺗ

اﺮﯿﺒﻛ

ﻲﻓ

ﻢﯿﻤﺼﺗ

تﺎﻘﯿﺒﻄﺘﻟا

ﻦﻣ

لﻼﺧ

ﺬﺧﻷا

ﻲﻓ

رﺎﺒﺘﻋﻻا

ﺔﻣاﺪﺘﺳا

ﺔﻓﺮﻌﻤﻟا

ةﺮﺒﺨﻟا و

ﻟا ﻰﻟإ ﺔﻓﺎﺿإ

ﺐﺳﺎﻜﻤ

ﻦﯿﺴﺤﺗ ﻦﻋ ﺔﺒﺗﺮﺘﻤﻟا

ﺔﯿﺟﺎﺘﻧﻹا

.

عﻮﻧ ﻦﻣ ﺔﻤﻈﻧﻷا ﺪﻤﺘﻌﺗ

)

(IDM

ﻰﻠﻋ

ﻟ تﺎﯿﻠﻤﻋ

ﻮﺤﺘ

ﯾ

ﻞ

فﺪﮭﺑ جذﺎﻤﻨﻟا

ﻲﻨﻘﺗ ﻞﺣ ﻖﯿﻘﺤﺗ

ﻰﻠﻋ ﺪﻤﺘﻌﯾ

ﺔﺼﻨﻣ

ﺔﮭﺟﻮﻣ جذﺎﻤﻧ ﻦﻣ ﺎﻗﻼﻄﻧا ﺔﺻﺎﺧ

ﻦﮭﻤﻠﻟ

ﻦﻋ ﺔﻠﻘﺘﺴﻣو

ﺔﺼﻨﻣ يأ

ﺮﻛﺬﺗ

.

اﺬھ ﻲﻓ

ﺰﻜﺗﺮﯾ ﺚﺤﺒﻟا

ﺎﻨﻣﺎﻤﺘھا

ﻰﻠﻋ

ﻰﻟوﻷا ﻞﺣاﺮﻤﻟا

ﻟ

ﺮﯾﻮﻄﺘ

ﻷا

ﺔﻤﻈﻧ

ﻟا

،ﺔﻋزﻮﻤ

و

ﺔﻔﺼﺑ

ﺔﺻﺎﺧ

ﺔﯿﻠﻤﻋ

قﺎﻘﺘﺷا

ﺔﯾرﻮﺼﺘﻟ

)

ﻢﯿﻤﺼﺗ

مﺎﻈﻨﻟا

(

ﻊﻀﺨﺗ

ﻟ

تﺎﻔﺻاﻮﻤ

و

تﺎﺒﻠﻄﺘﻣ

ﻹا مﺎﻈﻨﻟا

ﻲﻟﺎﻤﺟ

.

و

ﺑ

ﺮﻈﻨﻟﺎ

ﻰﻟإ

ﻤﻧ ةﺪﺋﺎﻓو ﺔﯿﻤھأ

ﺎ

مﺎﻈﻨﻟا ﺮﯾﻮﻄﺗ ﻲﻓ تﺎﺒﻠﻄﺘﻤﻟا جذ

،مﺎﻈﻨﻟا كﻮﻠﺴﻟ ﻲﺋﺎﻘﻠﺘﻟا قﺎﻘﺘﺷﻻاو

حاﺮﺘﻗﺎﺑ ﺎﻨﻤﻗ

ﻣ

ﺞﮭﻨ

قﺎﻘﺘﺷﻹ

كﻮﻠﺳ

ﻒﻠﺘﺨﻣ

تﺎﻧﻮﻜﻤﻟا

وأ

ﻷا

راود

ﻟا

ﻟ ﺔﻔﻠﺘﺨﻤ

ﻠ

مﺎﻈﻨ

ﻟا

ﻢﺋﺎﻘ

،

ﻣ

ﺮ

ﺗ

ﺰﻜ

ﻰﻠﻋ

ﺔﯿﻠﻤﻋ

ﻮﺤﺗ

ﯾ

ﻞ

جذﺎﻤﻨﻟا

.

ﺔﯿﻠﻤﻋ

ﻮﺤﺘﻟا

ﯾ

ﻞ

هﺬھ

،ﺪﻋاﻮﻘﻟا ﻦﻣ ﺔﻋﻮﻤﺠﻣ ﺎﮭﻤﻜﺤﺗ ﻲﺘﻟا ،

ﺢﻤﺴﺗ فﻮﺳ

ﺑ

كﻮﻠﺴﻟا قﺎﻘﺘﺷﺎ

ﻟا

صﺎﺨ

ﺑ

ﻞﻜ

ﺮﺼﻨﻋ

مﺎﻈﻨﻟا ﻦﻣ

،

اﺬھو

ﺎﻗﻼﻄﻧا

مﺎﻈﻨﻟا تﺎﺒﻠﻄﺘﻣ ﻦﻣ

ﻹا

ﻲﻟﺎﻤﺟ

.

ﺔﺒﺳﺎﻨﻤﻟا ﻖﯿﺴﻨﺘﻟا ﻞﺋﺎﺳر قﺎﻘﺘﺷا ﺎﻀﯾأ ﺔﯿﻠﻤﻌﻟا هﺬھ ﺢﯿﺘﺘﺳو

ﺔﻘﺘﺸﻤﻟا تﺎﯿﻛﻮﻠﺴﻟا ﻦﯿﺑ

ﺔﻔﻠﺘﺨﻤﻟا

.

ﻦﻜﻤﯾو

نأ

يدﺆﺗ

ﺔﯿﻠﻤﻋ

قﺎﻘﺘﺷﻹا

ﻲﺋﺎﻘﻠﺘﻟا

هﺬھ

ﺔﻏﺎﯿﺻ ﻰﻟإ

لﻼﺧ ﻦﻣ ﺔﯾﻮﻗو ﺔﻤﯿﻠﺳ ﺔﻤﻈﻧأ

ﻲﺘﻟا ءﺎﻄﺧﻷا ﺐﻨﺠﺗ

ﺎﮭﻠﺧﺪﺗ ﺪﻗ

و

ﺐﺒﺴﺘﺗ

ﺔﯿﻠﻤﻌﻟا ﺎﮭﯿﻓ

ﺔﯾوﺪﯿﻟا

.

ﺔﻋزﻮﻤﻟا ﻢﻈﻨﻟا ﺮﯾﻮﻄﺗ ﻲﻓ ﺔﻣﺎﮭﻟا ﺐﻧاﻮﺠﻟا ﻦﻣو

ﺮﻛﺬﻧ ،

لﺎﺜﺘﻣا نﺎﻤﺿ

ﮫﺗﺎﻔﺻاﻮﻣ ﻊﻣ مﺎﻈﻨﻟا ﻢﯿﻤﺼﺗ

ﺔﯿﻟوﻷا

،

ﺮﺧآ ﺮﯿﺒﻌﺘﺑ

،ﺎﻨﯾﺪﻟ قﺎﻘﺘﺷﻻا ﺞﮭﻧ ﻲﻓ

ﺐﺠﯾ

ﺪﻛﺄﺘﻟا

ﺎھﺮﺸﻧ ﻞﺒﻗ ﺎﮭﻨﻣ ﻖﻘﺤﺘﻟاو ﺔﻘﺘﺸﻤﻟا تﺎﯿﻛﻮﻠﺴﻟا ﺔﺤﺻ ﻦﻣ

.

،ﻊﻗاﻮﻟا ﻲﻓ

ﺮﻓﻮﺗ

ﺔﺴﻓﺎﻨﺘﻤﻟا تﺎﻘﯿﺒﻄﺘﻟا ﺺﺤﻔﻟ ﺔﯾﻮﻗ تاودأ ﺔﯿﻤﺳﺮﻟا قﺮﻄﻟا

ﮭﺗﺎﯿﺣ تارود ﻦﻣ ﺔﻔﻠﺘﺨﻣ تﺎﯾﻮﺘﺴﻣ ﻰﻠﻋ

ﺎ

.

ﺔﯿﻠﻤﻋو

ﻖﻘﺤﺘﻟا

قﺮﻄﻟا ﻦﻣ ةﺪﺣاو ﻲھ جذﺎﻤﻨﻟا ﻦﻣ

ﻷا

ىﻮﻗ

ﻖﻘﺤﺘﻠﻟ ىﺪﺟﻷاو

ﻦﻣ

ﺔﻗﺪﻟا

ﻟا

ﺔﯿﻘﻄﻨﻤ

هﺬﮭﻟ

ﺔﺴﻓﺎﻨﺘﻤﻟا ﺔﻤﻈﻧﻷا

.

اﺬھ ﻲﻓ

ﺚﺤﺒﻟا

،

حاﺮﺘﻗﺎﺑ ﺎﻨﻤﻗ

ﺞﮭﻧ

ﻟ

ﻖﻘﺤﺘﻠ

و

ﻟا

ﺺﺤﻔ

ﻟ

ﻤﻨﻠ

ﺎ

ﻲﻨﺒﻣ جذ

ﻮﺤﺗ سﺎﺳأ ﻰﻠﻋ

ﯾ

ﻞ

ﻟا

جذﺎﻤﻨ

ﻖﻘﺤﺘﻠﻟ ﻚﻟذو

تﺎﯿﻛﻮﻠﺴﻟا ﻦﻣ

ﺎﯿﺋﺎﻘﻠﺗ ةﺪﻤﺘﺴﻤﻟا

ﻟ

ﻟا ﺔﻤﻈﻧﻸ

ﺔﻋزﻮﻤ

.

فﺪﮭﻟا

ﻮھ

ﻟا

ﻤﻟا ﺔﻘﯾﺮﻄﻟا ﺲﻔﻨﺑ فﺮﺼﺘﯾ ﻖﺘﺸﻤﻟا مﺎﻈﻨﻟا نﺎﻛ اذإ ﺎﻣ ﻖﻘﺤﺘ

دﺪﺤ

ﻲﻓ ة

ﺗﺎﻔﺻاﻮﻣ

ﮫ

ﺔﻠﻣﺎﺸﻟا

.

فﺪﮭﯾ

ﺞﮭﻧ

ا

ﻖﻘﺤﺘﻟ

اﺬھ

ﻰﻟإ

ءادﻷا ةدﺎﯾز

ةدﻮﺟو

ﻟا

ﺔﻣﺪﺨ

ﻟ

مﺎﻈﻨﻠ

.

رﻮﻄﻤﻠﻟ ﺢﻤﺴﯾ ﺞﮭﻨﻟا اﺬھ

ﺰﯿﻛﺮﺘﻟا

ﻰﻠﻋ

ﻟا

جذﻮﻤﻨ

ﻟ ﻞﻣﺎﺸﻟا

ﻦﻣ ﻻﺪﺑ مﺎﻈﻨﻠ

ﻰﻠﻋ ﺰﯿﻛﺮﺘﻟا

ﮫﺴﻔﻧ مﺎﻈﻨﻟا

.

ﻢﮭﺴﯾ ﺎﻤﻛ

ﻞﻤﻌﻟا

مﺪﻘﻤﻟا

ﻲﻓ

هﺬھ

ﺔﺣوﺮطﻷا

ﺎﻀﯾأ

ﻲﻓ

ﻢﯿﻤﺼﺗ

ﺔﻤﻈﻧأ

ﺔﺒﻗاﺮﻤﻟا

ﻰﻠﻋ ةﺪﻤﺘﻌﻤﻟا ﺔﯿﺒﻄﻟا

ﻜﺒﺷ

تﺎ

WBSN

ﻖﻘﺤﺘﻟاو

ﻦﻣ

ﺎﮭﺘﺤﺻ

.

ﺔﻜﺒﺷ

ﻻا

رﺎﻌﺸﺘﺳ

مﺎﺴﺟﻸﻟ ﺔﯿﻜﻠﺳﻼﻟا

(WBSN)

ﻲﻓ ﻞﺜﻤﺘﺗ

ﺔﻜﺒﺷ

رﺎﻌﺸﺘﺳا ةﺰﮭﺟأو

نﺎﺴﻧﻹا ﻢﺴﺟ ﻰﻠﻋ ﻖﻠﻌﺗ ﺔﯿﻜﻠﺳﻻ

حﺎﻤﺴﻠﻟ ﻚﻟذو

ﺑ

ﺪﺻﺮ

تﺎﻣﻮﻠﻌﻤﻟا

ﺔﯾﻮﯿﺤﻟا

ﻟ

اﺬﮭ

ﻟا

و ﻢﺴﺠ

ﻟا

ﺌﯿﺒ

ﮫﺑ ﺔﻄﯿﺤﻤﻟا ﺔ

.

ﺪﻗو

ﻲﻈﺣ

ﻢﯿﻤﺼﺗ

ﺮﯾﻮﻄﺗو

هﺬھ

تﺎﻜﺒﺸﻟا

،نﺎﺴﻧﻹا ﺔﺤﺻ ﺪﺻر ﺪﺼﻗ

رﺪﻘﺑ

ﺮﯿﺒﻛ

ﻦﻣ

مﺎﻤﺘھﻻا

اﺮﺧﺆﻣ

ﻲﻓ

ﺔﻋﺎﻨﺼﻟاو ﺚﺤﺒﻟا تﻻﺎﺠﻣ

.

ﻊﺟﺮﯾو

اﺬھ

مﺎﻤﺘھﻻا

عرﺎﺴﺘﻤﻟاو ﻒﺜﻜﻤﻟا

ﺎﺳﺎﺳأ

ﻰﻟإ

ﺔﯾﺎﻋﺮﻟا

ﺔﯿﺤﺼﻟا

ﺔﻔﻠﻜﻤﻟا

ﻰﻟإ ﺔﻓﺎﺿإ

مﺪﻘﺘﻟا

زﺮﺤﻤﻟا

اﺮﺧﺆﻣ

ﻲﻓ

ﺮﯾﻮﻄﺗ

ﺔﯿﺒﻄﻟا ﺔﺒﻗاﺮﻤﻠﻟ ةﺮﻐﺼﻤﻟا ةﺰﮭﺟﻷا

.

،ىﺮﺧأ ﺔﮭﺟ ﻦﻣ

نإ

ﺮﯿﻓﻮﺗ

ﺢﯾﺮﺻ ﻢﯿﻤﺼﺗ ﺞﮭﻧ

ﺔﻄﻘﻧ ﻞﺜﻤﯾ

ءﺎﻨﺒﻟ اﺪﺟ ةﺪﯿﻔﻣ

ﺔﻤﻈﻧﻷا هﺬھ ﺔﻧﺎﯿﺻو

.

ﺮﻛﺬﻤﻟا هﺬھ ﻲﻓو

ة

،

ﻣﺎﻈﻧ مﺪﻘﻧ

ﺎ

ﻖﯿﻘﺤﺘﺑ ﻞﻔﻜﺘﯾ

ﺔﯿﺋﺎﻗو ﺔﯿﺒط ﺔﺒﻗاﺮﻣ

.

مﺎﻈﻨﻟا اﺬھ ﺪﻨﺘﺴﯾو

ﻢﯿﻤﺼﺗ ﻰﻠﻋ

ﺑ ﻖﻓﺮﻣ

ﺪﻘﻌ

تا

ﺔﺴﻧﺎﺠﺘﻣ ﺮﯿﻏ

ﺖﻗﻮﻟا ﺲﻔﻧ ﻲﻓ ﻖﻘﺤﯾو

ﻲﻣﻮﯿﻟا ﺪﺻﺮﻟا ﻦﻣ ﻞﻛ

ﺮﻤﺘﺴﻤﻟا ﺪﺻﺮﻟاو

إ

ﺔﻓﺎﺿ

ﻰﻟإ

ﺔﺒﻗاﺮﻣ

ةدﺪﺤﻣ

.

ﺪﯾﺪﺤﺗو ﻒﯾﺮﻌﺘﺑ ﺎﻨﻤﻓ ،ﮫﻠﻛ اﺬھ قﻮﻓ

جذﻮﻤﻧ

كﻮﻠﺳ ﻒﺻﻮﻟ

ﻟا

مﺎﻈﻨ

WBSN

.

مﺪﺨﺘﺴﯾ

ﺞﮭﻧ

إ

قﺎﻘﺘﺷ

ا

ﻰﻠﻋ ﻢﺋﺎﻘﻟا كﻮﻠﺴﻟ

جذﻮﻤﻨﻟا

لﻮﺼﺤﻠﻟ

ﻲﻓ ةﺪﻘﻋ ﻞﻛ كﻮﻠﺳ ﻰﻠﻋ

مﺎﻈﻨﻟا

WBSN

مﺎﻈﻨﻠﻟ مﺎﻌﻟا كﻮﻠﺴﻟا ﻦﻣ ﺎﻗﻼﻄﻧا

WBSN

.

ﺢﻤﺴﯾ

اﺬھ

ﻢﯿﻤﺼﺗ ﻰﻠﻋ لﻮﺼﺤﻠﻟ ﻦﯾرﻮﻄﻤﻠﻟ ﺞﮭﻨﻟا

مﺎﻈﻨﻠﻟ

WBSN

ﻦﻣ ﺎﻗﻼﻄﻧا

ﺗﺎﺟﺎﯿﺘﺣﻻ ﺔﻣﺎﻌﻟا تﺎﻔﺻاﻮﻤﻟا

ﮫ

.

ﺢﻤﺴﺗ

ﺔﻘﯾﺮط

ﮫﺟﻮﻤﻟا ﻖﯿﻗﺪﺘﻟا

ﺎﻀﯾأ ﺔﺣﺮﺘﻘﻤﻟا جذﺎﻤﻨﻟا ﻞﺒﻗ ﻦﻣ

ﻟﺎﺑ

ﻲﻛﻮﻠﺴﻟا نوﺎﻌﺘﻟا نﺎﻛ اذإ ﺎﻣ ﻖﻘﺤﺘ

ﯾ ﻖﺘﺸﻤﻟا

ﺔﻣﺎﻌﻟا تﺎﻔﺻاﻮﻤﻟا ﻲﻓﻮﺘﺴ

ﻲﻟوﻷا مﺎﻈﻨﻠﻟ

.

تﺎﻤﻠﻜﻟا

ﺔﯿﺣﺎﺘﻔﻤﻟا

:

جذﻮﻤﻧ ،جذﺎﻤﻧ

ﻲﻟﺎﻋ

،

،جذﺎﻤﻨﻟا ﻞﯾﻮﺤﺗ

،كﻮﻠﺴﻟا قﺎﻘﺘﺷا

ﺔﺳﺪﻨﮭﻟا

،جذﺎﻤﻨﻟﺎﺑ ةﺪﯿﻘﻤﻟا

MDA

،ﻖﯿﻗﺪﺘﻟا ،

WBSN

ﻄﻟا فاﺮﺷﻹا ،

ﻲﺒ

.

(3)

Résumé

l’Ingénierie Dirigée par les Modèles (IDM) apporte un changement important dans la conception des applications en prenant en compte la pérennité du savoir faire et les gains en productivité. L’architecture IDM se base sur la transformation de modèles pour aboutir à une solution technique sur une plateforme donnée à partir de modèles métier indépendants de toute plateforme. Dans ce travail, nous nous intéressons aux phases initiales de développement des systèmes distribués, particulièrement au processus de dérivation des modèles conceptuels à partir de la spécification des exigences globales du système.

Considérant l’importance et l’utilité du modèle des exigences dans le développement des systèmes et la dérivation automatique du comportement d’un système, nous proposons une approche de dérivation du comportement des différents composants ou rôles d’un système basée sur la transformation de modèles. Le processus de transformation, régi par un ensemble de règles, permettra la dérivation du comportement local d’un composant, sous la forme d’un automate d’états-transitions, à partir des exigences du système décrites par un diagramme d’activités UML étendu avec les collaborations. Ce processus permettra aussi la dérivation des messages de coordination appropriés entre les différents comportements dérivés. Un tel processus de dérivation automatique peut conduire à des systèmes valides et robustes en évitant les erreurs introduites par les activités de conception manuelle.

Un important aspect dans le développement des systèmes distribués est d’assurer la conformité de la conception du système avec sa spécification, autrement dit dans notre approche de dérivation, les com-portements dérivés doivent être validés et vérifiés avant leur déploiement. En fait, les méthodes formelles sont des outils puissants pour la vérification des applications concurrentes aux différents niveaux de leurs cycles de vie. La vérification de modèles est l’une des méthodes formelles les plus puissantes pour vérifier l’exactitude logique des systèmes concurrents. Dans ce travail, nous proposons une approche de vérification de modèles basée sur une transformation de modèles pour valider les comportements automatiquement dé-rivés d’un système distribué. Cette approche dirigée par les modèles vérifiera si le système dérivé a le même comportement que celui décrit dans sa spécification globale. L’objectif est d’augmenter les performances et la qualité de service QoS du système. Cette approche permet au développeur de raisonner sur un modèle du système global plutôt que sur le système lui-même.

Le travail présenté dans cette thèse contribue également à la conception et la validation des appli-cations de surveillance médicale basées sur les WBSNs. Un réseau de capteurs sans fil corporel (Wireless Body Sensor Network (WBSN)) est un réseau de capteurs sans fil attachés au corps humain afin de permettre la surveillance des paramètres vitaux du corps humain et son environnement. La conception et le dévelop-pement de tels systèmes pour la surveillance médicale (health monitoring) ont récemment reçu beaucoup d’attention, dans les domaines de la recherche et de l’industrie. Cet engouement est principalement motivé par des soins de santé très coûteux et par les progrès récents accomplis dans le développement de dispositifs miniatures pour la surveillance médicale. L’existence d’une approche de conception explicite devrait être très bénéfique pour la construction et la maintenance de ces systèmes. Dans cette thèse, nous présentons un système de surveillance médicale préventive. Ce système est basé sur une architecture dotée de nœuds hété-rogènes et réalise à la fois une surveillance quotidienne et continue ainsi que des contrôles spécifiques. Nous avons défini un modèle pour décrire le comportement global du système WBSN. L’approche de dérivation du comportement dirigée par les modèles est utilisée pour obtenir le comportement de chaque nœud dans le WBSN à partir du comportement global du système. Cette approche permet aux développeurs d’obtenir une conception du système WBSN à partir de la spécification globale de ses besoins. L’approche de vérification dirigée par les modèles proposée permet également de vérifier si la collaboration des comportements dérivés satisfait la spécification globale du système initial.

Mots clés : Modèles, Méta-modèle, Transformation de modèles, Dérivation du comportement, Ingénierie

(4)

Abstract

The Model Driven Engineering (MDE) makes a significant change in application design by taking on consideration the durability of the expertise and productivity gains. The MDE architecture is based on the model transformation to achieve a technical solution on a given platform from business models independent of any platform. In this work, we are interested in the early development phases of a distributed software system, especially in the process of obtaining a system design from its global requirements specification.

Considering the great importance and usability of the requirements models in practice during a system development, and the importance of the automatic derivation of the system behavior, this work focuses on the derivation of the different system components’ behavior. To this end, we suggest an approach to derive the behavior of the system components by transforming the system global requirements model to the design model. The system global requirements model describes the functional behavior of a given system in an abs-tract way. The design model represents the local behavior of each component. The appropriate meta-models have been defined at each level of abstraction with the corresponding model transformations. The proposed approach allows designers to describe their system using UML activity diagram extended with collabora-tions. This requirements model is then automatically transformed to the behavior of the components. A set of rules is needed to govern the model transformations during the derivation process. As these derived system components execute in a distributed environment, the derivation process includes synchronization messages in the derived behaviors to ensure coordination between the system components. The collaboration of these behaviors should satisfy the initial requirements model.

To ensure the conformance of this design to its specification, the derived behaviors should be validated and verified before their deployment. In fact, formal methods are powerful tools for software engineers to verify the logical correctness of concurrent software at different levels of its life cycle. Model checking is one of the most powerful formal methods for verifying the logical correctness of such concurrent systems. In this work, we make use of a model checking approach that is based on a model transformation to validate the automatically derived behavior of a distributed system. This model-driven approach will check whether the derived system behaves correctly according to its global specification, while the objective is to increase the system’s performance and QoS. This approach allows the developer to reason about a model of the global system rather than about the system itself.

The work presented in this document also contributes to the design and validation of health moni-toring systems based on WBSNs. The Wireless Body Sensor Network (WBSN) is a wireless network that is designed to allow communication among sensor nodes that are attached to a human body to monitor the body’s vital parameters and environment. The design and development of such WBSN systems for health monitoring have received a large amount of attention recently, in research studies and in industry. This at-tention is mainly motivated by costly health care and by recent advances in the development of miniature health monitoring devices. The existence of an explicit approach to address the required software design and verification should be very beneficial for the construction and maintenance of such systems. In this work, we present a preventive health care system that has a flexible design. The proposed system is based on an architecture that has heterogeneous nodes and provides both daily continuous monitoring as well as speci-fic controls. The model-driven engineering (MDE) approach is used to derive each node’s behavior in the WBSN from the WBSN global behavior. This approach allows developers to obtain a system design from the global specification of its requirement. Then the proposed model-driven verification approach is used to verify whether the collaboration of the derived behaviors satisfies the initial system specification.

Keywords : Models, Meta-model, Model Transformation, Behavior derivation, Model driven engineering,

(5)

Remerciements

Avant, toute personne, je tiens à remercier notre Dieu Tout Puissant pour m’avoir éclaircit le chemin de ce travail.

Mes vifs remerciements vont tout d’abord à Monsieur Noureddine DJEDI, Professeur à l’Université Med Khider, Biskra, mon directeur de thèse pour m’avoir donné la possibilité d’ef-fectuer cette thèse sous sa direction. Je tiens aussi à le remercier pour ses ses précieux conseils durant mes travaux de thèse et la préparation de la soutenance.

Je tiens également à remercier vivement Monsieur Mohammed ERRADI, Professeur à l’EN-SIAS, Université Mohamed V Souissi, Rabat, Maroc pour l’accueil et l’aide précieuse qu’il m’a prodigué tout au long de cette thèse. Je tiens aussi à exprimer toute ma gratitude à Monsieur Abdel-latif KOBBANE, Professeur à l’ENSIAS, Université Mohamed V Souissi, Rabat, Maroc pour son soutien et pour son aide.

J’adresse mes plus vifs remerciements à Monsieur Abdelmalik BACHIR, Professeur à l’Uni-versité Med Khider, Biskra, pour m’avoir fait l’honneur de présider le jury de ma soutenance, ainsi qu’à Monsieur Samy AIT-AOUDIA, Professeur à l’ESI, Alger, Monsieur Hamid AZZOUNE, Pro-fesseur à l’USTHB, Alger, Monsieur Allaoua CHAOUI, ProPro-fesseur à l’Université Constantine 2, et Monsieur Hammadi BENNAOUI, Maître de conférences à l’Université Med Khider, Biskra pour avoir accepté d’examiner mon travail et pour avoir bien voulu juger le travail et faisant partie du jury de soutenance.

Un grand merci s’adresse en particulier à Monsieur KOUIDER EL OUAHED Abdellah, mon collègue au département d’informatique de l’UHBC de Chlef, qui m’a soutenu pendant toute la durée de ma thèse, et sans oublier toutes les personnes qui m’ont soutenu de prés ou de loin, je m’excuse de ne pouvoir tous les mentionner.

Et enfin, je remercie du fond de mon cœur mon défunt père et ma mère qui ont veillé à mon éducation, toute ma famille et tous mes proches et amis, qu’ils soient chaleureusement remerciés de m’avoir soutenu pour mener à bien cette thèse.

(6)

Table des matières

1 Introduction 1

1 Contributions . . . 3

2 Organisation du document . . . 6

2 Ingénierie dirigée par les modèles et transformations 9 1 Introduction . . . 9

2 Concepts essentiels de l’IDM . . . 10

2.1 Modèles . . . 10

2.2 Méta-modèles . . . 12

3 L’approche MDA (Model Driven Architecture) . . . 13

3.1 Principes du MDA . . . 14

3.2 Architecture MDA . . . 15

3.3 Processus de développement du MDA . . . 21

3.4 Les approches de transformation de modèles dans MDA . . . 25 i

(7)

TABLE DES MATIÈRES ii

3.5 L’approche en double Y . . . 27

4 Travaux sur la transformation de modèles . . . 29

5 Conclusion . . . 31

3 Dérivation du comportement d’un système par transformation de modèles 33 1 Introduction . . . 33

2 Processus de dérivation et méta-modèles de base . . . 36

2.1 L’architecture du processus de dérivation . . . 36

2.2 Les méta-modèles de base . . . 38

3 L’approche de transformation . . . 41

3.1 L’algorithme du processus de dérivation . . . 42

3.2 Les règles de transformation . . . 44

4 Étude de cas . . . 56

4 Mise en œuvre de l’approche de dérivation du comportement d’un système 65 1 Introduction . . . 65

2 Le langage de Transformation QVT . . . 67

3 Le langage de Transformation ATL . . . 69

3.1 Structure globale des programmes de transformation . . . 69

(8)

TABLE DES MATIÈRES iii

5 Une vérification formelle des comportements dérivés d’un système distribué 87 1 Introduction . . . 87

2 L’approche de vérification dirigée par les modèles . . . 90

3 Processus de vérification . . . 93

3.1 Le méta-modèle spécifique à la vérification . . . 95

3.2 Transformation Modèle-Modèle . . . 98

3.3 Transformation modèle-texte . . . 101

3.4 Propriétés comportementales (propriétés de correction) . . . 104

3.5 Vérification de modèles (SPIN) . . . 108

6 Une approche dirigée par les modèles pour la conception des réseaux WBSN 115 1 Introduction . . . 115

2 Les réseaux de capteurs corporels sans fil (WBSN) . . . 116

3 Architecture du WBSN pour la surveillance médicale . . . 120

4 L’approche de dérivation et vérification dirigée par les modèles pour les systèmes WBSN . . . 124

5 Processus de dérivation . . . 125

(9)

TABLE DES MATIÈRES iv

6.1 Propriétés comportementales du système WBSN . . . 131 6.2 Vérification de modèles du système WBSN par SPIN . . . 133 7 Conclusion . . . 138

7 Conclusions et Perspectives 141

1 Contributions . . . 142 2 Perspectives et Extensions . . . 145

(10)

Table des figures

2.1 Architecture du MDA. [70] . . . 16

2.2 Architecture MDA à quatre niveaux. . . 20

2.3 Architecture générale de l’approche MDA. . . 23

2.4 Le méta-modèle de MDA. [53] . . . 24

2.5 Transformation par annotation ou marquage. . . 26

2.6 Transformation par méta-modèles. . . 27

2.7 Cycle de transformation en double Y. [15] . . . 28

3.1 L’architecture du processus de dérivation. . . 37

3.2 Le méta-modèle des exigences. . . 39

3.3 Le méta-modèle cible de l’automate d’états-transitions. . . 40

3.4 Structure d’une collaboration. . . 44

3.5 Séquence Strong entre deux collaborations. . . 46

3.6 Séquence Weak entre deux collaborations. . . 48 v

(11)

TABLE DES FIGURES vi

3.7 Structure de choix. . . 49

3.8 Exemple du processus de dérivation. . . 51

3.9 Boucle Tantque avec séquencement Strong. . . 52

3.10 Boucle Tantque avec séquencement Weak. . . 54

3.11 Parallélisme entre deux collaborations. . . 55

3.12 Le comportement global du système (modèle des exigences). . . 57

3.13 Comportement Dérivé du neurologue (CHU). . . 59

3.14 Comportement Dérivé du médecin urgentiste (HA). . . 60

3.15 Comportement Dérivé du SMUR (ALS). . . 62

4.1 Architecture du langage QVT. . . 67

4.2 Contexte opérationnel de QVT. . . 68

4.3 L’approche de transformation par ATL. . . 70

4.4 Le processus de transformation de Modèles. . . 74

5.1 L’approche de vérification dirigée par les modèles. . . 91

5.2 Le processus de vérification. . . 95

5.3 Le méta-modèle machine à états finis communicante (FSM). . . 97

5.4 Le comportement du neurologue HA décrit par un FSM. . . 99

5.5 Le comportement du neurologue CHU décrit par un FSM. . . 100

(12)

TABLE DES FIGURES vii

5.7 Le comportement du SAMU décrit par un FSM. . . 101

5.8 Les résultats de la simulation aléatoire. . . 109

5.9 Les résultats de la vérification sans propriétés de correction. . . 110

5.10 Un scénario de la simulation aléatoire de l’application de télédiagnostic. . . 111

5.11 un scénario de l’application de télédiagnostic. . . 111

5.12 Les résultats de la vérification des propriétés comportementales. . . 112

6.1 Architecture d’un étage du WBSN. . . 120

6.2 Architecture du WBSN pour la surveillance médicale. . . 122

6.3 Approche de dérivation et de vérification dirigée par les modèles. . . 125

6.4 Comportement global du système WBSN. . . 126

6.5 Comportement dérivé du capteur. . . 127

6.6 Comportement dérivé du collecteur de données. . . 128

6.7 FSM du capteur et du collecteur de données. . . 129

6.8 Les résultats de la simulation aléatoire. . . 134

6.9 Un scénario de la simulation aléatoire du système WBSN. . . 134

6.10 Les résultats de la vérification sans propriétés de correction. . . 135

6.11 Les résultats de la simulation. . . 135

6.12 Variation du temps de simulation. . . 137

(13)

(14)

Liste des tableaux

3.1 Les correspondances entre les concepts des méta-modèles source et cible. . . 42 3.2 Règles de calcul des ensembles de rôles initiateurs, terminateurs et participants. [16] 45 3.3 Les rôles initiateurs, terminateurs et participants au niveau des collaborations. . . . 50

6.1 Résultats de la simulation. . . 136 6.2 Variation du temps de simulation. . . 137

(15)

Chapitre 1

Introduction

Les systèmes informatiques deviennent de plus en plus complexes. Il devient alors difficile de maintenir correctement les logiciels à moindre coût et ceci dans des délais raisonnables. Cette évolution consiste à redévelopper et porter ces logiciels vers de nouvelles plateformes, alors que globalement la logique métier de l’entreprise n’a pas changé.

L’évolution incessante et inévitable des technologies a été prise en compte au niveau des spécifications des logiciels, avec l’apparition de nouvelles méthodes d’analyse et de conception à base de modèles et à production de code. La plus célèbre de ces méthodes de modélisation de systèmes à objets est UML (Unified Modeling Language) de l’OMG. Avec ce langage graphique, les différentes dimensions d’un logiciel complexe peuvent être spécifiées, assemblées, visualisées et documentées. Ces différentes modélisations sont ensuite utilisées pour générer automatiquement la trame de code du logiciel cible sur une plateforme.

Pour permettre l’interopérabilité entre les différents systèmes, réduire les coûts de dévelop-pement et augmenter l’évolutivité, l’ingénierie dirigée par les modèles (IDM), ou Model Driven Engineering (MDE) en anglais, est devenue un domaine important de l’ingénierie logicielle. Elle a permis plusieurs améliorations significatives dans le développement de systèmes complexes en se concentrant sur une préoccupation plus abstraite que la programmation classique. C’est une forme d’ingénierie générative dans laquelle tout ou une partie d’une application est engendrée à partir

(16)

1. Introduction 2

de modèles. Pour l’IDM, le concept principal est le modèle. Un modèle est une abstraction, une simplification d’un système permettant de le comprendre. Le modèle représente une vue d’un sys-tème et il est défini dans le langage de son méta-modèle. Un syssys-tème peut être décrit par différents modèles liés les uns aux autres. L’utilisation de différents langages de modélisation pour décrire les aspects chronologiques ou technologiques du développement d’un système nécessite la définition de plusieurs méta-modèles. Afin de rendre opérationnels les modèles (pour la génération de code, la documentation et le test, la validation, la vérification, l’exécution, etc.), IDM introduit la notion de transformation de modèles. Autrement dit, un ensemble d’applications exécutables qui indiquent comment dériver un modèle cible à partir d’un modèle source. Les mappages sont décrits en termes de correspondances entre les concepts du méta-modèle source et ceux du méta-modèle cible. La transformation de modèles permet de réaliser une génération (semi-) automatique du code à partir des modèles.

En réponse au défi d’évolutivité (la nécessité de grands (méta) modèles et de transformations entre ces modèles), l’académie et l’industrie ont investi dans le soutien de cet outil. Par consé-quent, un certain niveau de maturité a été réalisé pour la (méta) modélisation et le développement de transformation de modèles. L’étape suivante était l’automatisation des tâches de développement de transformation de modèles. Cette automatisation est un réel défi dans le domaine de l’ingénie-rie des modèles (les transformations manuelles introduisent beaucoup d’erreurs). L’automatisation de la transformation consiste à produire de nouveaux modèles à partir de modèles existants. La transformation n’est alors plus limitée à la production du code source mais peut opérer sur tous les modèles décrivant un système.

L’approche MDA (Model Driven Architecture ou architecture dirigée par les modèles) est un exemple d’application de l’IDM. La MDA est recommandée par l’OMG (Object Management Group). Elle est basée sur d’autres recommandations de ce même organisme. Elle spécifie trois niveaux d’abstractions exprimés en termes de modèles, les modèles des exigences CIM (Compu-tation Independent Model), les modèles indépendants des plateformes PIM (Platform Independent Model), et les modèles spécifiques aux plateformes PSM (Platform Specific Model). Le système est ainsi représenté par différentes vues abstraites. Des transformations sont nécessaires entre les dif-férents niveaux d’abstraction en vue de la génération du code. Plusieurs travaux sur les approches MDA et IDM se sont concentrés sur les niveaux inférieurs et les transformations automatiques

(17)

1. Introduction 3

entre les uns et les autres. Ces travaux de recherches ont abordé la transformation des modèles de conception en modèles de déploiement et plus précisément des modèles PIM en modèles PSM et les modèles PSM vers du code dans MDA. Toutefois, moins d’attention a été accordée aux transfor-mations de haut niveau d’abstraction en IDM, à savoir la transformation des modèles des exigences en modèles conceptuels, les transformations des modèles CIM en modèles PIM dans l’approche MDA.

1 Contributions

Considérant l’importance et l’utilité du modèle des exigences dans le développement des systèmes. Celui-ci peut être utilisé pour décrire le comportement global d’un système, à savoir un système distribué. Ceci est dû au fait que le comportement global de ces systèmes n’est pas réalisé par un seul composant mais par la collaboration d’un ensemble de composants. Un tel comportement peut être décomposé en un ensemble de comportements partiels réalisés par les différents composants du système. Par conséquent, une approche de transformation est nécessaire pour dériver automatique-ment le comporteautomatique-ment de ces composants à partir de la spécification du comporteautomatique-ment global du système, modélisé par le modèle des exigences. Le processus de dérivation du comportement des composants ou entités du système est très important dans le développement des systèmes distribués tels que les systèmes d’information, les systèmes multi-agents et les applications distribuées. Un tel processus de dérivation automatique peut conduire à des systèmes valides et robustes en évitant les erreurs introduites par les activités de conception manuelle.

Les travaux présentés dans cette thèse ont pour objectif de contribuer à apporter une solution dans les domaines de la transformation des modèles des exigences et la dérivation du comportement d’un système et plus précisément un système distribué. Pour ce faire, nous proposons une approche de dérivation du comportement des différents composants d’un système basée sur la transformation de modèles. Nous considérons que le comportement global du système est modélisé par le modèle des exigences. Les éléments de base du comportement global du système sont des activités qui sont en fait des collaborations entre les composants ou les rôles du système. Les collaborations sont très appropriées pour modéliser les exigences car elles fournissent un cadre structurel pour ces

(18)

1. Introduction 4

exigences qui peut incarner à la fois les comportements des rôles et les interactions entre ces rôles nécessaires pour accomplir un service.

L’approche proposée consiste à dériver le comportement des rôles du système par la trans-formation du modèle des exigences, qui décrit le comportement fonctionnel d’un système d’une manière abstraite vers des modèles conceptuels où chaque rôle est identifié par son comporte-ment local. Les comportecomporte-ments des rôles du système doivent être déterminés de sorte que de la collaboration de ces comportements résulte un comportement satisfaisant le modèle global initial d’expression des besoins. Le processus de transformation, régi par un ensemble de règles, permet la dérivation du comportement local d’un composant, sous la forme d’un automate d’états-transitions, à partir des exigences du système décrites par un diagramme d’activités UML étendu. Ce proces-sus permettra aussi la dérivation des messages de coordination appropriés entre les comportements dérivés des différents composants du système. Cette approche commence par la définition du méta-modèle source des diagrammes d’activités UML étendus avec des collaborations, et le méta-méta-modèle cible des automates d’états-transitions UML. L’approche proposée considère les étapes suivantes :

• Définition du méta-modèle des exigences pour spécifier le comportement global d’un sys-tème donné.

• Choix du méta-modèle cible afin de modéliser le comportement des rôles du système au niveau conceptuel qui reflète le comportement local de chaque rôle.

• Établissement des règles de transformations qui régissent la transformation au cours du pro-cessus de dérivation.

Les concepteurs de logiciels savent par expérience que, très probablement, tout système lo-giciel ne fonctionne pas bien après la première compilation réussie, ni la deuxième ni la troisième. Parfois, il faut un certain temps pour découvrir qu’un logiciel apparemment supposé correct peut échouer de façon subtile. Les petits défauts peuvent se cacher pendant des années et apparaître au moment le plus gênant lorsqu’ils sont les moins attendus. Cependant, il existe des cas dans lesquels ces défauts ne sont pas acceptables, tels que les systèmes de surveillance médicale ou les applica-tions économiques critiques ; les défauts logiciels peuvent entraîner des pertes de vie ou causer des dommages économiques importants.

(19)

1. Introduction 5

Une grande partie de notre monde est maintenant contrôlée par des applications logicielles, le défi le plus important consiste à trouver les moyens et les outils nécessaires afin de rendre ces applications plus fiables. La vérification de tels systèmes implique une validation de la conception. Elle vérifie si une conception d’un système donné satisfait les exigences globales de celui ci. (Si ce n’est pas le cas, alors il est souhaitable de le savoir au début du processus de conception !) Ces tâches, la vérification du système et la validation de la conception, peuvent être accomplies en utilisant plusieurs techniques.

La vérification basée sur les modèles est l’une des méthodes formelles les plus puissantes et est particulièrement bien adaptée à la vérification automatisée des systèmes à états finis. La vérification de modèles nécessite des algorithmes sophistiqués basés sur la théorie des automates et la logique pour vérifier les modèles, mais pas les programmes. Ces modèles représentent fidèlement le système, tout en restant suffisamment concis pour permettre de vérifier son exactitude.

L’approche de dérivation du comportement d’un système se concentre sur les premières phases de développement d’un système logiciel distribué, en particulier dans le cas de l’obten-tion d’une concepl’obten-tion d’un système à partir de sa spécifical’obten-tion des exigences globales. Les com-portements dérivés du système s’exécutent dans un environnement distribué. Ainsi, le défi le plus important consiste à trouver les moyens nécessaires pour vérifier si ces comportements dérivés sont fiables. Cet objectif consiste à vérifier si le système dérivé en question se comporte tel que le système initial a été conçu. Toutes ces raisons ont motivé notre travail pour l’utilisation d’une approche dirigée par les modèles pour effectuer la vérification du comportement des composants dérivés du système.

Dans cette thèse, nous présentons une approche dirigée par les modèles pour vérifier et va-lider le processus de dérivation. Il s’agit de vérifier si la collaboration des comportements dérivés satisfait la spécification globale du système initial. L’approche décrit un processus de vérification qui permet de vérifier et d’analyser la cohérence logique du système dérivé. Ce processus de vé-rification est principalement basé sur la transformation automatique des modèles dérivés vers des modèles spécifiques requis par un vérificateur de modèles. Par la suite, la vérification de modèles peut être effectuée pour analyser les comportements dérivés du système et vérifier donc si ce com-portement est conforme à la spécification globale du système.

(20)

1. Introduction 6

La conception et le développement des systèmes pour la surveillance médicale (health mo-nitoring) utilisant les réseaux de capteurs (Wireless Body Sensor Network (WBSN)) est une tâche très complexe. La majorité des études dans ce domaine se sont axées sur les problèmes de mise en œuvre, et elles abordent rarement une méthodologie pour la construction et la maintenance de tels systèmes. La plupart de ces systèmes sont développés en sélectionnant d’abord la plateforme cible la plus appropriée et, ensuite, son système d’exploitation spécifique et son langage de pro-grammation. L’existence d’une approche de conception explicite devrait être très bénéfique pour la construction et la maintenance de tels systèmes.

Le travail présenté dans cette thèse contribue également à la conception et la validation des applications de surveillance médicale basées sur les WBSN. Nous proposons d’abord une archi-tecture composée de nœuds hétérogènes pour construire un système de surveillance médicale. Le système de surveillance médicale proposé est conçu pour effectuer une surveillance quotidienne et continue ainsi que des contrôles spécifiques pour les patients d’un hôpital. C’est une architecture WBSN basée sur un collecteur de données mobile. Le collecteur mobile est utilisé pour écono-miser les ressources (consommation d’énergie) des capteurs. Les nœuds capteurs ne peuvent être réveillés que lorsqu’ils sont en présence du collecteur de données. De plus, l’approche de dérivation du comportement dirigée par les modèles est utilisée pour obtenir le comportement de chaque nœud dans le WBSN à partir du comportement global du système WBSN. L’utilisation d’une approche d’ingénierie logicielle pour prendre en charge un tel processus de dérivation peut conduire à une conception hautement indépendante des plateformes d’implémentation. En outre, elle favorise la réutilisation des modules logiciels ; un modèle de comportement dérivé peut être reconsidéré sur différentes plateformes. L’approche de vérification dirigée par les modèles est adoptée pour vérifier les comportements dérivés et valider le processus de dérivation.

2 Organisation du document

La suite de ce document est constitué de sept chapitres, organisés comme suit :

Chapitre 2 : ce chapitre situe le cadre général de la thèse. Nous distinguons au niveau de ce chapitre la notion du paradigme de l’ingénierie dirigée par les modèles (IDM) et les techniques de

(21)

transfor-1. Introduction 7

mation dans l’IDM. La première partie de ce chapitre introduit l’ingénierie dirigée par les modèles et ses concepts. Au niveau de la deuxième partie, nous décrirons l’approche MDA et ses principes. A la fin de ce chapitre, les techniques de transformations de modèles sont décrites et notamment les transformations de haut niveau, à savoir les transformations des modèles des exigences (CIM) vers des modèles conceptuels (PIM). Cette description nous a permis de mettre en évidence la trans-formation des modèles des exigences pour réaliser la dérivation du comportement d’un système distribué.

Chapitre 3 : la première partie de ce chapitre sera consacrée à une description détaillée de la pro-blématique soulevée pour les transformations de modèles. Par la suite, nous décrirons l’approche proposée pour la transformation du modèle des exigences en modèles conceptuels. L’approche pro-posée consiste à dériver le comportement des rôles du système par transformation du modèle des exigences, qui décrit le comportement fonctionnel d’un système d’une manière abstraite vers des modèles conceptuels où chaque rôle est identifié par son comportement local.

Chapitre 4 : la première partie de ce chapitre sera consacrée à la description des langages de trans-formation de modèles, en particulier les langages QVT (Query View Transtrans-formation) et ATL (Atlas Transformation Language). La deuxième partie sera consacrée à la mise en œuvre de l’approche de dérivation proposée pour la transformation du modèle des exigences en modèles conceptuels. Chapitre 5 : ce chapitre présente une approche dirigée par les modèles pour vérifier et valider le processus de dérivation décrit dans le chapitre 3. Ce processus de vérification a pour but de vérifier que la collaboration des comportements dérivés satisfait la spécification globale du système initial. La première partie du chapitre est consacrée à la description du processus de vérification dirigé par les modèles qui est principalement basé sur la transformation automatique des modèles dérivés vers des modèles spécifiques requis par un vérificateur de modèles. La deuxième partie présente une vérification du système distribué de télédiagnostic en neuroscience décrit dans le chapitre 3. Cette vérification de modèles est effectuée pour analyser et vérifier le comportement dérivé du système. Chapitre 6 : ce chapitre présente un système de surveillance médicale préventive. Ce système est composé d’un réseau de capteurs corporels sans fil (Wireless Body Sensor Network (WBSN)) attachés au corps humain afin de permettre la surveillance des paramètres vitaux du corps humain et son environnement. Ce système est basé sur une architecture dotée de nœuds hétérogènes et réalise

(22)

1. Introduction 8

à la fois une surveillance quotidienne et continue ainsi que des contrôles spécifiques. Nous avons défini un modèle pour décrire le comportement global du système WBSN. L’approche de dérivation du comportement dirigée par les modèles est adoptée pour obtenir le comportement de chaque nœud dans le WBSN à partir du comportement global du système WBSN. Les comportements dérivés du système WBSN sont vérifiés par l’approche proposée de vérification dirigée par les modèles. Cette vérification consiste à déterminer si la collaboration de ces comportements satisfait la spécification globale du système initial.

Enfin, le chapitre 7 conclut cette thèse en présentant les contributions apportées durant cette thèse, et présente les perspectives ouvertes à l’issue de nos travaux.

(23)

Chapitre 2

Ingénierie dirigée par les modèles et

transformations

1 Introduction

Suite à l’approche objet des années 80 et de son principe de considérer que "tout est objet", l’in-génierie du logiciel s’oriente aujourd’hui vers l’inl’in-génierie dirigée par les modèles (IDM) et le principe du "tout est modèle". L’ingénierie des modèles peut être vu comme une généralisation de la technologie orientée objet. Les principaux concepts de la technologie objet sont les classes, les instances et les deux relations associées InstanceOf et InheritsFrom. Pour l’IDM, le concept classe est remplacé par le concept modèle. Un modèle représente une vue d’un système défini dans le langage de son méta-modèle. En d’autres termes, un modèle contient des éléments conformes aux concepts et aux relations exprimés dans son méta-modèle. Les deux relations de base sont Repre-sentedBy et ConformsTo. Un modèle représente un système et il est conforme à un méta-modèle. Les méta-modèles sont à leur tour conforme à un méta-méta-modèle qui est défini en termes de lui-même [12]. En ingénierie des modèles, les modèles ne sont pas seulement des moyens de communication entre les développeurs d’applications mais ils sont suffisamment précis pour être utilisés pour générer du code. Les concepts et les éléments peuvent correspondre à des classes et des instances, respectivement. A première vue, cela suggère des ressemblances entre la

(24)

2. Ingénierie dirigée par les modèles et transformations 10

logie objet et l’IDM, mais il existe une nette différence entre les deux. Il faut clairement séparer l’approche orientée objet de l’approche orientée modèle (IDM). Cependant, dans bien des cas la confusion est faite entre les concepts que l’on trouve dans l’IDM et leur incarnation dans le monde objet. Par exemple, la vision selon laquelle un modèle serait une "instance d’un" méta-modèle.

L’objectif de l’IDM est de définir une approche pouvant intégrer différents espaces technolo-giques [58]. Par exemple, l’espace technologique des grammaires, des documents structurés XML, ou des bases de données relationnelles, ne sont pas fondés sur le concept d’objet. Les deux relations de base InstanceOf et InheritsFrom ne sont pas adaptées aux autres espaces technologiques comme elles le sont pour le monde des objets [14]. L’IDM vise à fournir un grand nombre de modèles pour exprimer séparément chacune des préoccupations des utilisateurs, des concepteurs, des architectes, etc. C’est par ce principe de base, fondamentalement différent, que l’IDM peut être considérée en rupture par rapport aux travaux de l’approche objet. Ainsi, il est nécessaire de définir quels sont les concepts et les relations essentielles à l’IDM.

2 Concepts essentiels de l’IDM

L’approche orientée objet est basée sur deux relations fondamentales : la relation InstanceOf qui permet d’introduire la notion de classe et la relation InheritsFrom qui permet d’introduire la notion de superclasse. Le concept central de l’IDM est la notion de modèle et les deux relations fondamen-tales sont RepresentedBy et ConformsTo. La première relation, RepresentedBy, est liée à la notion de modèle, alors que la relation ConformsTo permet de définir la notion de modèle par rapport à celle de méta-modèle.

2.1 Modèles

Bien qu’il n’existe pas une définition universelle du modèle, néanmoins de nombreux travaux montrent cependant un relatif consensus sur une certaine compréhension. Les trois définitions ci-dessous sont représentatives de cette tendance.

(25)

Définition : "A model is an abstraction of a physical system, with a certain purpose."

Elle provient du standard UML [75]. Un modèle est une abstraction d’un système physique avec un certain objectif. Cette définition est contraignante car elle se limite à la représentation des concepts physiques et exclue les concepts abstraits tels que la notion de session de cours ou d’interaction dans de tels modèles.

Définition : "A model is a set of statements about some system under study." [100] Un modèle est un ensemble d’énoncés d’un système à l’étude.

Définition : "A model is a simplification of a system built with an intended goal in mind. The model should be able to answer questions in place of the actual system." [13]

Un modèle est une abstraction d’un système, modélisé sous la forme d’un ensemble de faits construits dans une intention particulière. Un modèle doit pouvoir être utilisé pour répondre à des questions sur le système modélisé. Toutefois, un modèle doit, par définition, être une abstraction pertinente du système qu’il modélise, i.e., qu’il doit être suffisant et nécessaire pour permettre de répondre à certaines questions en lieu et place du système qu’il représente.

Ces définitions provenant de sources différentes suggèrent qu’il existe une relation entre le modèle et le système étudié qu’il modélise. Cette relation est appelée RepresentedBy dans [8, 14, 100]. Notons que la nature exacte des systèmes considérés n’est pas explicitée dans les définitions précédentes. Ces définitions ne sont pas restreintes aux modèles et systèmes informatiques. Par exemple, une carte géographique peut jouer le rôle de modèle, alors que la région étudiée jouera celui du système modélisé. Dans cet exemple, une carte est un modèle (une représentation) de la réalité, avec une intention particulière (carte routière, administrative, des reliefs, etc.).

La notion de modèle dans l’IDM fait explicitement référence à la notion de langage bien défini dans lequel est exprimé le modèle. En effet, pour qu’un modèle soit productif, il faut qu’il puisse être manipulé par une machine. Donc, le langage dans lequel ce modèle est exprimé doit être clairement défini. La définition d’un langage de modélisation a pris la forme d’un modèle, appelé méta-modèle.

(26)

2.2 Méta-modèles

La notion de méta-modèle est au cœur même de l’ingénierie dirigée par les modèles (IDM). Un méta-modèle est définit dans la littérature par :"A meta-model is a model that defines the language for expressing a model". [80]

Un méta-modèle est un modèle qui définit le langage d’expression d’un modèle, i.e., le lan-gage de modélisation. La notion de méta-modèle conduit à l’identification d’une seconde relation, reliant le modèle et le langage utilisé pour le construire, appelée ConformTo [14, 31].

L’originalité de l’IDM n’est pas de mettre l’accent sur la relation RepresentedBy liant un modèle au système modélisé. Cette relation est attribuée aux méthodes de modélisation. Par contre, le point clé dans l’IDM est de mettre l’accent sur l’importance de la relation ConformTo liant un modèle au méta-modèle auquel il est conforme. Cette relation permet d’assurer qu’un modèle est correctement construit permettant ainsi à des transformations automatisées d’être envisagées.

La relation de conformité peut avoir plusieurs incarnations selon l’espace technologique considéré. Par exemple, dans l’espace technologique XML, on dira qu’un document XML est conforme à un schéma ou à une DTD, dans l’espace technologique des bases de données on dira que le contenu d’une base de données est conforme au schéma de cette base de données, dans l’espace technologique orienté-objet on dira qu’un objet est conforme à sa classe et dans l’espace technologique orienté modèle on dira qu’un modèle est conforme à son méta-modèle. La relation InstanceOf ressemble à l’incarnation de la notion de conformité dans le cadre orienté objet mais ce n’est là qu’un cas particulier. Plusieurs variantes de la relation de conformité peuvent être consi-dérées pour l’Ingénierie Dirigée par les Modèles. Les méta-modèles deviennent des entités de pre-mière classe. Ils sont définis comme des langages spécifiques de domaine (DSL) pour adresser les spécificités liées à tels secteurs d’activités, à tel métier, à tel point de vue, à tel niveau d’abstraction, ou à telles plateformes technologiques.

Le consensus sur UML fut décisif dans la transition vers des techniques de production basées sur les modèles. L’acceptation du concept méta-modèle comme langage de description de modèle a permis l’émergence de nombreux méta-modèles afin d’apporter chacun leurs spécificités dans un domaine particulier (développement logiciel, entrepôt de données, procédé de développement,

(27)

etc.). Cette grande diversité de méta-modèles indépendants et incompatibles induisait un besoin urgent de donner un cadre général pour leur description. La réponse fut donc d’offrir un langage de définition de méta-modèles qui prit lui-même la forme d’un modèle ; ce fut le méta-méta-modèle MOF (Meta-Object Facility) proposé par l’OMG [80]. L’OMG met surtout en avant actuellement une architecture dont le socle est le MOF, sur lequel s’appuie d’une part une collection de méta-modèles dont UML n’est qu’un élément parmi d’autres. Par la suite, l’approche MDA (Model Driven Architecture) [110] est devenue une variante particulière de l’Ingénierie Dirigée par les Modèles.

3 L’approche MDA (Model Driven Architecture)

L’évolution des systèmes informatiques a rendu difficile la maintenance des logiciels à moindre coût et ceci dans des délais raisonnables. Cette évolution a induit le redéveloppement des logi-ciels sur de nouvelles plateformes, alors que globalement la logique métier de l’entreprise n’a pas changé. En effet, du fait de l’évolution incessante et inévitable ; les technologies se sont succédées. Par exemple, CORBA (Common Object Request Broker Architecture) qui devait permettre une communication entre applications différentes ne s’est pas imposé en tant que standard du Middle-ware. Cela s’explique par sa complexité et l’apparition d’architectures concurrentes plus simples comme EJB (Entreprise Java Bean). Ainsi, les architectures se suivent et ne se ressemblent pas. Ces bouleversements ont aussi été pris en compte au niveau des spécifications des logiciels, avec l’apparition de nouvelles méthodes d’analyse et de conception à base de modèles et à production de code. La plus célèbre de ces méthodes de modélisation de systèmes à objets est UML (Unified Modeling Language) de l’OMG [17]. Avec ce langage graphique, les différentes dimensions d’un logiciel complexe peuvent être spécifiées, assemblées, visualisées et documentées. Ces différentes modélisations sont ensuite utilisées pour générer automatiquement la trame de code du logiciel cible.

Pour permettre l’interopérabilité entre les différents systèmes, réduire les coûts de développe-ment et augdéveloppe-menter l’évolutivité, l’OMG (Object Managedéveloppe-ment Group) propose la démarche MDA (Model Driven Architecture), où la notion de modèle devient essentielle et centrale. MDA est une

(28)

nouvelle approche d’écriture de spécifications et de développement d’applications. Cette approche prône l’utilisation de modèles indépendants de toute plateforme et technologie. Cette approche par abstraction permet de mieux se concentrer sur la partie "intelligente" et la rend pérenne car elle reste utilisable avec les technologies futures.

3.1 Principes du MDA

L’OMG (Object Management Group) propose de revoir la façon de penser une application. Cette révolution s’appuie sur des standards éprouvés, regroupés au sein du MDA (Model Driven Archi-tecture). Cette démarche apporte un changement important dans la conception des applications. Elle introduit une séparation nette entre la logique métier de l’entreprise et la logique d’implémen-tation. Cette révolution est d’autant plus importante qu’elle change non seulement la façon de voir mais aussi notre façon de faire. En effet, elle propose de mettre à disposition des développeurs des outils d’automatisation et de génération de code à partir de la logique métier.

L’approche MDA [72] fournit des outils pour :

• Spécifier (modéliser) un système indépendamment de la plateforme d’implémentation ; • Spécifier les plateformes ;

• Choisir une plateforme particulière pour le système ; et

• Transformer la spécification du système pour l’implémenter sur une plateforme particulière. Les trois objectifs de l’approche MDA sont la portabilité, l’interopérabilité et la réutilisation au moyen de la séparation entre la fonctionnalité d’une application et l’architecture où elle sera im-plémentée.

A terme, la démarche MDA propose de définir un modèle métier indépendant de toute pla-teforme technique et de générer automatiquement du code vers la plapla-teforme choisie. Pour cela, l’accent est mis non plus sur les approches orientées objet mais sur les approches orientées modèle. Le but est de favoriser l’élaboration de modèles de plus haut niveau.

(29)

Les avantages recherchés par cette approche sont :

• La pérennité du savoir faire. Ainsi il n’est pas nécessaire de recommencer la modélisation des fonctionnalités et des comportement du système chaque fois qu’une nouvelle technologie est adoptée ;

• Les gains de productivité, afin de permettre au développeur de réduire les coûts de mise en œuvre des applications nécessaires à son métier ;

• La prise en compte des plateformes d’exécution, permettant ainsi le déploiement d’une même application sur plusieurs plateformes.

3.2 Architecture MDA

L’OMG définit MDA comme une approche pour la spécification des systèmes informatiques qui sépare les fonctionnalités du système de ses détails d’implémentation sur une plateforme techno-logique particulière. La MDA est un cadre pour le développement d’applications dirigé par les modèles [72].

Les projets utilisant MDA se concentrent d’abord sur la fonctionnalité et le comportement d’une application ou d’un système, mettant à l’écart les technologies dans lesquelles ils seront mis en œuvre. Cette approche met l’accent sur les modèles qui fournissent un niveau plus élevé d’abstraction au cours du développement. Les applications créées à l’aide de MDA peuvent varier du transport, à l’industrie, à la santé et peuvent être déployées sur une gamme de marchés ouverts et plateformes propriétaires, tels que CORBA, J2EE, .NET et etc. (voir Fig. 2.1). L’architecture MDA se compose de quatre couches qui réfèrent à chaque niveau des standards déjà adoptés par l’industrie ou en cours de normalisation.

Le centre est composé par trois technologies spécifiées par l’OMG pour modéliser la lo-gique métier de l’application : UML (Unified Modeling Language), MOF (Meta Object Facility) et CWM (Common Warehouse Meta-model). Dans la couche suivante, se trouve aussi le standard XMI (XML Meta-data Interchange) qui permet le dialogue entre les middlewares (Java, CORBA,

(30)

.NET et web services). La troisième couche contient les services qui permettent de gérer les évé-nements, la sécurité, les répertoires et les transactions. Enfin, la dernière couche propose des fra-meworks spécifiques au domaine d’application (Finance, Télécommunication, Transport, Espace, Médecine, Commerce électronique, Manufacture,. . .) [70].

Fig. 2.1 : Architecture du MDA. [70]

3.2.1 Spécifications standards du MDA

Les principales normes qui composent la MDA [70] comprennent l’Unified Modeling Language (UML) [74], Object Facility (MOF) [80], XML data Interchange XMI [77] et Meta-model Common Warehouse (MCG).

3.2.1.1 Meta-Object Facility (MOF) : Le langage MOF fournit le standard de méta-modélisation et d’échange de constructions utilisées par MDA. Il est utilisé pour définir, manipuler et intégrer

(31)

les méta-données et les données d’une manière indépendante de la plateforme. Les autres modèles standards de l’OMG, comme UML et CWM, sont définis par des constructions MOF, ce qui permet de les relier entre eux. C’est également le mécanisme par lequel les modèles sont sérialisés en XMI. Le MOF est un exemple de méta-méta-modèle, ou de modèle du méta-modèle. Il définit les élé-ments essentiels, la syntaxe et la structure des méta-modèles utilisés pour construire des modèles orientés objet. L’intérêt de MOF est de définir des mécanismes génériques sur les méta-modèles grâce à une structuration commune. Il permet de faire inter opérer des méta-modèles différents. Une application MOF peut manipuler un modèle à l’aide d’opérations génériques sans connais-sances du domaine.

3.2.1.2 UML (Unified Modeling Langage) : Le langage UML (Unified Modeling Language) est une spécification, définissant un langage graphique pour visualiser, spécifier, construire et do-cumenter les artefacts de systèmes logiciels. Il a été adopté par l’OMG comme standard de modéli-sation des systèmes informatiques en novembre 1997. Il permet la modélimodéli-sation d’architectures, de structure d’objets, d’interactions entre ces objets, de données, de composants, de frameworks, etc. Les concepts définis par UML sont très proches de ceux définis par le MOF. Ainsi, le MOF utilise les représentations graphiques de UML. UML a apporté au domaine de la méta-modélisation sa notation graphique et ses concepts objet. Le langage UML permet la modélisation de systèmes in-dépendamment de toute démarche ou de plateforme. C’est pourquoi, dans la cadre du MDA, UML peut être utilisé pour décrire des plateformes, des organisations, des situations ou la plupart des systèmes logiciels.

Depuis sa version 1.1, UML intègre le langage OCL (Object Constraint Language) qui est un langage d’expression permettant de décrire des contraintes sur des modèles objet. Une contrainte est une restriction sur une ou plusieurs valeurs d’un modèle non représentable en UML. OCL est un langage sans effet de bord, il est incapable de modifier quoi que ce soit au sein des objets ou même des variables. Il donne des descriptions précises et non ambigües du comportement du logiciel en complétant les diagrammes. Il définit des pré-conditions, des post-conditions ou des invariants pour une opération. Il permet aussi la définition des expressions de navigation ou des expressions booléennes. OCL est un langage de haut niveau d’abstraction parfaitement intégré à UML qui permet de trouver des erreurs beaucoup plus tôt dans le cycle de vie d’une application.

(32)

Cette vérification d’erreurs est rendue possible grâce à la simulation du comportement du modèle. Avec l’apparition de la version 2.0, UML contient entre autres une évolution du langage d’expression de contrainte OCL, des concepts renforcés pour les composants et s’intègre plus faci-lement dans l’approche MDA grâce à un rapprochement avec le MOF. Le concept de profil UML permet d’adapter le langage UML à un domaine qu’il ne pouvait pas couvrir correctement. Les pro-fils sont utilisés pour la génération de modèles. Les spécificités de chaque plateforme peuvent être modélisées grâce aux mécanismes d’extension d’UML définis par les profils UML. Par exemple, les stéréotypes permettent l’ajout de nouveaux éléments au méta-modèle, les valeurs marquées (tagged values) permettent l’ajout de propriétés à une méta-classe et les contraintes permettent l’ajout ou la modification de règles. Il est possible d’associer les stéréotypes, les valeurs marquées et les contraintes à tout concept UML (classe, attribut, association, cas d’utilisation). Ces éléments permettent d’établir une correspondance entre les concepts UML et les concepts du domaine re-présentés par le profil. Le profil est aussi composé d’un ensemble de règles de présentation, de conception ou de transformation. Ce sont ces règles qui rendent le profil opérationnel.

3.2.1.3 XMI (XML Meta-data Interchange) : Le langage XMI est le langage d’échange entre le monde des modèles et le monde XML (eXtensible Markup Language). C’est le format d’échange standard entre les outils compatibles MDA. XMI décrit comment utiliser les balises XML pour représenter un modèle UML en XML. Cette représentation facilite les échanges de données (ou méta-données) entre les différents outils ou plateformes de modélisation. En effet, XMI définit des règles permettant de construire des DTD (Document Type Definition) et des schémas XML à partir de méta-modèles, et inversement. Ainsi, il est possible d’encoder un méta-modèle dans un document XML, mais aussi, à partir de document XML il est possible de reconstruire des méta-modèles. Le langage XMI a l’avantage de regrouper les méta-données et les instances dans un même document ce qui permet à une application de comprendre les instances grâce à leurs méta-données. Ceci facilite les échanges entre les applications.

3.2.1.4 Le méta-modèle Common Warehouse : Le Common Warehouse Meta-model ou CWM est une spécification de l’OMG. Il est composé d’un ensemble d’interfaces standards qui peuvent être utilisées pour permettre l’échange facile de méta-données d’un entrepôt et des applications

(33)

intelligentes avec les outils d’entrepôt, les plateformes et les entrepôts de méta-données dans les environnements distribués et hétérogènes. CWM est le standard pour l’intégration des entrepôts de données. Il standardise la façon de représenter les schémas, les modèles de transformation de schémas et les modèles de datamining.

3.2.2 La méta-modélisation

MDA ne considère plus le code exécutable comme le référentiel unique dans le processus de déve-loppement du logiciel. Les différents aspects élaborés par les développeurs vont se concrétiser par des modèles lisibles par les opérateurs humains mais surtout interprétables par les ordinateurs. A un aspect spécifique donné correspondra un modèle particulier. Chacun de ces modèles est exprimé dans un langage spécifié par un méta-modèle. Pour harmoniser ces méta-modèles en un langage unique, l’OMG a défini le MOF (Meta-Object Facilty).

3.2.2.1 Méta-modélisation : La modélisation est l’activité consistant à définir le méta-modèle d’un langage de modélisation. Elle vise donc à bien modéliser un langage, qui joue alors le rôle de système à modéliser.

3.2.2.2 Méta-méta-modèle : Un méta-méta-modèle est un modèle qui décrit un langage de méta-modélisation, i.e., les éléments de modélisation nécessaires à la définition des langages de modélisation. Il a de plus la capacité de se décrire lui-même.

MDA doit donc manipuler des modèles de natures très diverses (modèles d’objet métier, modèles de processus, modèles de règles, modèles de service, modèles de plateforme, etc.). Pour structurer et organiser tous ces modèles, l’OMG a défini une "architecture à quatre niveaux" décrite sous une forme de pyramide en se basant sur le principe de la méta-méta-modélisation (Fig. 2.2) :

• Le niveau M0 (ou instance) correspond au monde réel. Ce sont les informations réelles de l’utilisateur, instance du modèle de M1.

(34)

• Le niveau M1 (ou modèle) est composé de modèles d’information. Il décrit les informations de M0. Les modèles M1 sont conformes au méta-modèle de M2.

• Le niveau M2 (ou méta-modèle), il définit le langage de modélisation et la grammaire de représentation des modèles M1. Le méta-modèle UML, qui définit la structure interne des modèles UML, fait partie de ce niveau. Les profils UML, qui étendent le méta-modèle UML, appartiennent aussi à ce niveau. Les méta-modèles sont conformes au MOF.

• Le niveau M3 (ou méta-méta-modèle) est composé d’une unique entité qui s’appelle le MOF. Le MOF permet de décrire la structure des modèles, d’étendre ou de modifier les méta-modèles existants. Le MOF est réflexif, il se décrit lui-même.