Sobre o estudo empírico…

Les deux mondes des besoins et de spécification formelle doivent évoluer en même temps. Afin

de garantir un passage aisé entre les différentes étapes du développement, l’automatisation par

réutili-sation de l’existant se présente comme une des alternatives dans ce contexte. Cette section présente un

aperçu des patrons et leur utilisation en génie logiciel. Servant à résoudre une classe de problèmes, un

patron aide au développement grâce au concept d’instanciation en s’adaptant au problème en question.

Nous nous intéressons spécifiquement aux patrons de conception et à ceux de spécification formelle.

2.4.1 Généralités

2.4.1.1 Réutilisation en génie logiciel

Partons du principe"ne pas réinventer la roue". Celui-ci introduit un concept fondamental en

in-formatique : laréutilisation de l’existantpermet aux projets informatiques d’optimiser le coût de

déve-loppement en termes de temps, d’argent et d’efforts. La réutilisation permet l’évolution des systèmes

existants. Cependant, une mauvaise réutilisation peut mener à de lourdes pertes. Prenons l’exemple

du crash du vol 501 d’Ariane 5. Il s’agit d’un vol inaugural du lanceur Ariane 5 ayant lieu le 4 juin

1996. La fusée s’est auto-détruite environ 37 secondes après son lancement à une altitude de 3700

mètres. Aucune perte humaine n’a été déplorée, mais plusieurs centaines de millions de dollars ont

été perdus. Après cet accident, un groupe de chercheurs comprenant Gilles Kahn et Jacques-Louis

Lions a été désigné pour faire une enquête et préciser la ou les causes de cet échec. Dans leur rapport

publié le 19 juillet 1996 [Lions et al., 1996]

⁴⁰

, les auteurs ont précisé que la cause principale concerne

une défaillance du logiciel de la référence inertielle du système, système de guidage de la fusée entre

autres. Il s’agit d’un dépassement de capacité dans la mémoire pour une variable d’accélération

ho-rizontale. Cette variable devait être codée sur 9 bits au lieu de 8 bits. Une différence d’un seul bit a

causé ce lourd échec. En réalité, le logiciel de navigation de la fusée Ariane 5 était celui qui avait

été conçu pour son prédécesseur, Ariane 4. Ceci a induit une incompatibilité entre le logiciel et le

matériel vu que la fusée Ariane 5 est plus puissante et nécessite plus d’espace mémoire pour effectuer

les calculs. En revenant sur ce détail, nous découvrons l’importance et le danger qui contournent la

notion de réutilisation. Elle favorise un gain de temps et d’argent, mais sa mauvaise adaptation mène

à de lourdes pertes.

D’une manière générale, le développement des systèmes et logiciels corrects critiques et

com-plexes est une tâche fastidieuse. D’une part, elle nécessite des connaissances des langages utilisés et

des efforts importants en termes de temps et d’investissement des développeurs pour l’élaboration des

systèmes. D’autre part, elle est guidée par l’utilisation des outils disponibles dans le développement.

Bien qu’il existe des aides et des méthodes, telles que la méthode agile, qui permettent l’obtention

de systèmes et logiciels pertinents, il n’existe quasiment pas de guides méthodologiques qui facilitent

le développement. Un problème donné peut être perçu dans plusieurs projets informatiques. Il peut

également être développé pour plusieurs langages et formats mais il n’est pas généralisé dans une

optique de réutilisation. Par conséquent, le travail pour un problème similaire est refait plusieurs fois

de différentes manières. Parmi les idées proposées dans le cadre de réutilisation, nous identifions :

- la programmation orientée composants: comme en électronique, un composant en informatique est

un élément logiciel pouvant être présenté sous forme d’un code compilé. Il est développé, testé

et mis à disposition des développeurs pour le réutiliser, l’adapter et l’intégrer dans un projet. Cet

aspect de réutilisation du composant n’est assuré que lorsque ce composant a un comportement

générique. D’où la notion degénéricité. Celle-ci consiste à abstraire des comportements ou des

éléments logiciels de manière à les rendre facilement réutilisables dans différentes applications

indépendamment des types de données traitées.

- L’utilisation des patrons: ce concept découle de la notion de généricité et favorise la réutilisation.

2.4.1.2 Qu’est-ce qu’un patron ?

L’idée des patrons a été initialement introduite par l’architecte Christopher Alexander dans le

livre [Alexander et al., 1977], portant sur l’architecture et l’habitation. Dans leur ouvrage, les auteurs

ont décrit un nouveau langage appelé"langage de schéma". Ce langage est caractérisé par des

"mo-dèles"appelés"patrons"permettant de décrire une méthode de travail dans le domaine d’architecture

urbaine. D’une manière générale, un patron décrit un savoir-faire du domaine. Il présente et identifie

un sous-problème "déjà vu" et pour lequel une solution réutilisable acquise par l’expérience a été

dé-veloppée. En informatique, cette solution est paramétrée et provient de l’expertise des développeurs

ayant travaillé sur ces problèmes récurrents. Le patron est instancié pour un problème particulier en

donnant des valeurs effectives à ses paramètres génériques. Dans le cycle de développement d’un

lo-giciel, les patrons existent et s’appliquent dans différentes phases. Ils concernent la phase de codage,

de conception et de spécification, voir figure 2.12.

Analyse et

expression

des besoins

Patrons de conception

(GoF, 1995)

Patrons de spécification

formelle (Abrial, 2008)

Spécification

Conception

générale

Conception

détaillée ^{Tests unitaires}

Codage

FIGURE2.12 – Place des patrons dans un processus en V

2.4.2 Patrons de conception

Les plus connus sont ceux introduits dans les années 95 par la"Bande des quatre, GoF (Gang of

Four)"et les patronsGRASP (General Responsibility Assignment Software Patterns) dans un cadre

orienté objet présentés dans la suite.

2.4.2.1 Organisation

Un patron ou modèle de conception, selon les auteurs de [Gamma et al., 1996], fait "la description

d’objets coopératifs et de classes que l’on a spécialisés pour résoudre un problème général de

concep-tion dans un contexte particulier". Dans ce cadre, les auteurs ont développé un catalogue comprenant

23 patrons. Leurs descriptions sont fournies sous forme :

- de graphiques à l’aide des diagrammes en UML et

- de prototypes ou exemples de codes implémentés en langage C++ [Delannoy, 2000].

Le catalogue des patrons de GoF est organisé selon deux critères :

- Lerôlequi traduit ce que fait le modèle. Selon ce critère, les patrons de conception de GoF

s’orga-nisent autour de trois types

⁴¹

:

— créateurs’intéressant au processus de création des objets,

— structureldéfinissant comment organiser les classes ou les objets dans une structure plus

large séparant l’interface de l’implémentation et

— comportemental décrivant la manière d’organiser et d’interagir des classes ou des objets

et de se répartir les responsabilités.

- Ledomaine qui précise si le modèle s’applique à des classes ou à des objets. Selon ce critère, un

patron peut concerner :

— des modèles de classesqui traitent des relations entre les classes et leurs sous-classes ou

— des modèles d’objetsqui s’intéressent aux relations entre les objets. Ces relations peuvent

être modifiées lors de l’exécution et sont considérées dynamiques.

2.4.2.2 Formalisme

Outre les notations graphiques, les patrons de conception de GoF sont décrits via uncanevas.

Celui-ci désigne un format unique permettant l’apprentissage facile des modèles, leur compréhension

et leur utilisation. Pour chaque patron, un canevas est décrit selon les éléments suivants :

- Nom : décrit le principe du patron. Les auteurs définissent, dans la section 1.1 du chapitre 1 du

livre [Gamma et al., 1996], un nom comme "un moyen de décrire en un ou deux mots un

pro-blème de conception, ses solutions et leurs conséquences". Ils assument aussi que"trouver de

bons noms a été une des tâches les plus difficiles de la constitution de notre catalogue".

- Problème: décrit la raison d’être du patron ainsi que le problème qu’il résout.

- Solution: définit les éléments de la solution proposée par ce patron. Cette solution est décrite en

donnant une structure du patron, ses constituants et la collaboration entre ses constituants.

- Conséquences: présente les effets résultants de l’application du patron concerné ainsi que les

com-promis qui émergent lors de cette application.

2.4.2.3 Utilisation

Le canevas décrit précédemment fournit un guide permettant d’aider à décider lequel, parmi les

patrons définis, est plus adapté à un problème donné. Les noms des patrons donnent une indication

précieuse au développeur pour sa décision.

Prenons l’exemple du patronSingleton. Il s’agit d’un modèle dont le rôle estcréateur et le domaine

estobjet. Comme son nom l’indique, celui-ci permet la création d’une instance unique d’une classe.

Il est utile dans les applications nécessitant la création d’un seul objet d’une classe comme celles

demandant la création d’un seul administrateur.

2.4.3 Patrons de spécification formelle

Ils ont été décrits en 2008 par [Abrial and Hoang, 2008]. Ce sont des modèles en B événementiel

consacrés à la formalisation d’un sous-problème typique tel que celui des protocoles de

communica-tion [Hoang et al., 2013]. De tels modèles sont prouvés mathématiquement sous la plateforme Rodin.

Pour un problème issu du monde réel, l’idée consiste à instancier le patron de spécification concerné

afin d’aider à la construction du modèle formel et de réduire l’effort de preuve. Cette idée est inspirée

des patrons de conception. Elle est rentable lorsqu’il s’agit de spécifier un système critique complexe.

Les auteurs de ces patrons soulignent les atouts de leur approche, notamment :

- La réduction de l’effort de développement : les composants - machines et contextes - du patron sont

développés et prêts à la réutilisation. L’élaboration de certaines parties de la spécification pour

une application réelle est guidée par une instanciation du patron concerné. Ceci implique un

effort et un temps réduits de développement mais aussi un risque affaibli d’oubli de certains

éléments formels de la spécification.

- L’automatisation de la preuve : le patron est vérifié correct avant son instanciation. Ceci se réalise

grâce aux outils de preuves de la plateforme Rodin. Par conséquent, les parties de la

spécifica-tion formelle élaborées à partir de l’instanciaspécifica-tion des patrons sont automatiquement prouvées

correctes.

- L’existence d’un outilPattern

⁴²

développé comme plugin de la plateforme Rodin. Cet outil permet

une adaptation systématique des patrons décrits en B événementiel et leur incorporation ou

intégration dans des spécifications formelles complexes.

- Le support du raffinement : un patron de spécification formelle peut être identifié, instancié et

appli-qué graduellement dans chaque pas de raffinement. Il est adapté et intégré dans une spécification

formelle de taille plus large.

No documento Os processos supervisivos nas estruturas de gestão intermédia : possibilidades e limites. Um estudo de caso numa escola secundária (páginas 189-200)