GooMod : Langage de modélisation des BPs 

Introduction générale

De nos jours les systèmes informatiques sont de plus en plus complexes. Face à cette complexité, les spécialistes s’intéressent de plus en plus aux conséquences de l’évolution des logicielles, activité incontournable, sur leur qualité. En effet, la qualité a toujours suscité l’intérêt aussi bien les chercheurs, dans le domaine du domaine du génie logiciel, que des développeurs dont le souci est d’assurer les exigences de leurs clients.
Beaucoup d’études sont menées pour trouver des méthodes efficaces pour l’amélioration de la qualité du logiciel : plusieurs métriques [Chidamber et al., 1994], [Brito et al., 1994], plusieurs modèles de qualité [AliKacem et Sahraoui, 2006] et plusieurs normes [Masud al., 2008],[ISO , 2001] ont été proposés afin de contribuer à la production de logiciels de qualité. L’une des méthodes qui peut nous aider à améliorer la qualité du produit logiciel est l’application des bonnes pratiques.
L’étude des bonnes pratiques nécessite la collecte des données dans un contexte industriel.
Il se trouve qu’un partenaire industriel (Agrostar) a décidé de se doter d’un processus assurant le développement de logiciel de qualité. Dans ce projet de recherche, il s’agit d’utiliser cette opportunité pour définir un processus d’identifier l’impact des bonnes pratiques de modélisation sur la qualité du code produit. L’intérêt pour notre partenaire industriel est d’avoir la définition d’une bonne pratique de modélisation lui assurant un certain niveau de qualité de son code.
Le présent rapport est divisé en cinq chapitres : Le premier chapitre est consacré à l’état de l’art. Dans une première partie, de ce chapitre, nous présenterons quelques notions fondamentales sur la qualité des logiciels, ensuite nous évoquerons quelques exemples de métriques, dans le double but d’illustrer la problématique de la mesure et de montrer son influence sur le code.
La deuxième partie vise à donner un aperçu sur les bonnes pratiques appliquées aux systèmes logiciels. Dans le deuxième chapitre nous présenterons notre approche pour la définition d’une bonne pratique de modélisation adaptée au contexte industriel définit par Agrostar. Dans ce même chapitre, nous présenterons le langage GooMod, un langage permettant la définition et l’application des bonnes pratiques de modélisation. Le troisième chapitre, sera consacré à l’exploitation des résultats obtenus. Dans le dernier chapitre, nous ferons une analyse empirique des métriques pour vérifier et valider notre contribution.

Introduction

Dans le présent chapitre, nous présentons quelques notions fondamentales nécessaires pour mener une étude sur les bonnes pratiques et critique de l’existant. Nous commencerons par définir un certain nombre de notions lié à la qualité du logiciel.
Ensuite, nous dévoilerons le besoin de mesurer. Ainsi, nous présenterons l’état de l’art sur les différentes manières de spécifier et d’implémenter des métriques, Enfin, nous présentons un volet sur quelques outils de bonnes pratiques.

Qu’est ce qu’un logiciel de qualité ?

Il n’y a pas un accord universel sur le sens de la qualité d’un logiciel. En effet, il existe plusieurs définitions. En voici deux exemples :
Définition 1 : Selon le standard ISO 9000 [ISO, 2000], la qualité d’un logiciel est l’ensemble des caractéristiques intrinsèques qui lui confère l’aptitude à satisfaire les besoins et attentes exprimés ou implicites des clients et autres parties intéressées.
Définition 2 : : Selon le standard IEEE [IEEE, 1998], la qualité logicielle correspond au degré selon lequel un logiciel possède une combinaison d’attributs désirés.
Donc, la qualité ne réside pas uniquement dans le fait d’avoir un logiciel opérationnel, mais également dans l’évaluation par rapport à des objectifs mesurables de qualité.
En effet, Pour construire des produits de qualité, il nous faut des activités standardisées. A cet effet, plusieurs mesures de qualité et normes ont été proposées. Selon le standard ISO 9126, la qualité d’un produit est représentée par un ensemble de caractéristiques opérationnelles, qu’on appelle facteurs de qualité.

La crise du logiciel

Les problèmes du développement du logiciel ont été identifiés par la crise du logiciel (software crisis). Ses principaux symptômes sont :
– Le logiciel n’est pas délivré à temps et les coûts dépassent le budget alloué, le dépassement de délai et de coût moyen est compris entre 50 et 70 %.
– La qualité du logiciel correspond rarement aux attentes des clients.
– Les modifications des logiciels coûtent cher et sont à l’origine de nouveaux défauts.
– 50 % des projets n’aboutissent jamais.
Ces dernières indications montrent à quel point ce secteur d’ingénierie a besoin de s’améliorer d’où plusieurs travaux de recherche ont été réalisés pour pallier à cette crise.

Facteurs de qualité

Pour qu’un logiciel soit de bonne qualité, il doit répondre à un nombre important de critères qui sont représentés dans la figure 1.1.
La qualité du logiciel est définie par six facteurs principaux décrits dans la norme ISO 9126.
– Capacité fonctionnelle : en quoi le logiciel satisfait les besoins exprimés ?
– Fiabilité : le produit fait-il tout le temps les tâches prévues avec la précision requise ?
– Ergonomie : est-il facile d’utiliser le logiciel ?
– Efficacité : quels sont les performances du logiciel ?
– Maintenabilité : Est-il facile d’identifier et corriger les composants en dysfonctionnement ou des données erronées ?
– Portabilité : est-il facile d’adapter le logiciel et le transférer dans un autre environnement matériel ou sur une nouvelle configuration ?

Quelques exemples de métriques

Il existe de nombreuses métriques bien connues qui mesurent par exemple la taille du code, la structure des produits logiciels (« Complexité cyclomatique » ou « Fan-in/Fan-out »). Chidamber et al. [Chidamber et al. 1994] définissent six métriques pour les classes dans le cas des logiciels orientés-objets sont les plus cités en génie logiciel [Wohlin, 2007] : – WMC : la somme des complexités de toutes les méthodes.
– DIT : la profondeur de l’héritage de la classe.
– NOC : le nombre de classes immédiatement dérivées d’une classe.
– CBO : la mesure de couplage correspondant au nombre de classes dont la classe considérée est dépendante.
– RFC : le nombre de méthodes qui peuvent être potentiellement exécutées en réponse à un message.
– LCOM : la mesure du manque de cohésion, c’est le nombre de paires de méthodes qui n’utilisent aucune variable d’instance en commun.
Basili et al. [Basili et al. ,1996] ont montré empiriquement que ces métriques sont de bons indicateurs pour prédire la probabilité de faute.
Brito et Carapuça [Brito et al., 1994] ont proposé une autre type de classification, ils ont classifié les métriques selon six dimensions (conception, taille, complexité, réutilisabilité, productivité et qualité) et ont proposé trois niveaux de granularité (méthode, classe et système). Il en résulte 18 classes de métriques.

Utilité des métriques

Une étape indispensable à l’amélioration du domaine de la mesure est de déterminer l’utilité de la mesure pour chaque logiciel. En effet, on ne mesure pas un logiciel pour le plaisir de mesurer mais pour des objectifs bien définis.
Oman et Pfleeger [Oman et al. ,1997] ont distingué six objectifs pour mesurer. Ces objectifs sont : mesurer pour la compréhension, mesurer pour 1’expérimentation, mesurer pour le contrôle de projet, mesurer pour l’amélioration du processus, mesurer pour l’amélioration du produit et mesurer pour la prédiction.

Normalisation des métriques

Les métriques de produits logiciels ont été intégrées dans la pratique, vu leurs importances. Bansiya et Davis [Bansiya et al. , 1997] ont développé des métriques originales pour leurs projet QMOOD (Quality Model for Object-Oriented Design). Toutefois, comme il n’y a aucune norme, il est difficile de déterminer les valeurs des seuils métriques.
L’approche de la normalisation [Masud et al. , 2008] fournit une plate-forme standard pour les métriques de la qualité des systèmes logiciels sans tenir compte de la qualité de leur conception, de la complexité et de la taille. Cette approche, comme le montre la figure 1.2, se base sur trois niveaux fondamentaux.

Démarches d’amélioration de la qualité

De nombreuses approches ont déjà été proposées sur la qualité des processus des systèmes d’information. La plupart affirment qu’il y a un fort besoin pour des mesures appropriées de logiciel dès les premières phases du développement des logiciels, tels que l’analyse des besoins, spécification, conception, et la partie initiale du codage. De ce fait, le cycle de vie d’un logiciel et l’assurance qualité sont fortement lié.
Il a été démontré aussi [Boehm, 1981] que les erreurs de conception sont extrêmement coûteuses lorsqu’elles ne sont pas corrigées dans les premières phases du cycle de vie des projets.
Dès lors, il devient donc important de pouvoir contrôler la qualité d’un logiciel au début de la phase de conception.
Le but principal de la mesure en phase amont du développement logiciel est la prédiction de la qualité finale du logiciel pour réduire les coûts et éviter les erreurs de conception. Les activités d’assurance de la qualité, pour ce type, sont l’inspection plutôt que le test [Tian , 1998]. Ce type de mesure permet de valider l’architecture du logiciel, sachant que les propriétés de celle-ci influent sur les caractéristiques finales de qualité (voir figure 1.4).

Bonnes pratiques

Pour produire des logiciels de qualité une méthodologie des bonnes pratiques a été mise en place. [LeGloahec et al. , 2009] Les bonnes pratiques sont des techniques et des méthodes, rassemblées par une entreprise ou par une communauté, dont l’efficacité a été constatée lors des projets de développement.
Les bonnes pratiques présentent l’expertise et la valeur ajoutée de l’entreprise, c’est une assurance de la conformité et du respect de la norme.
L’ingénierie dirigée par les modèles, permet de rendre les bonnes pratiques productives et permet la vérification automatique de leurs respects.

Lignes directrices

D’après les recherches antérieures qui ont été faites pour l’évaluation de la qualité du logiciel, les chercheurs ont montré que la taille du modèle d’un processus, sa structure, l’expertise de son concepteur ainsi que d’autres facteurs ont un impact sur le modèle du processus. A cet effet, une série de lignes directrices a été présenté [Mendling et al., 2010].
Les spécialistes du domaine ont défini une relation entre les caractéristiques structurelles d’un modèle de processus et les différents facteurs de compréhension y compris la mesure de compréhension d’un modèle de processus, la probabilité d’erreur et de l’ambiguité. Donc, évaluer un processus revient à déterminer certaines mesures (cohérence, lisibilité…).
Les sept lignes directrices de modélisation (Seven Process Modeling Guidelines) (7 PMG) fournissent un ensemble de recommandations sur la façon de construire un modèle de processus pour l’améliorer. Chacune des lignes directrices s’appuie sur des recherches empiriques décrites ci-dessous. Il est important de noter que les 7 PMG s’appuient sur l’idée qu’il y a différentes façons pour décrire le même comportement pour un même modèle de processus.
Les 7 PMG sont les suivantes [Mendling et al., 2010] :
– 1 : Utiliser le moins d’éléments dans le modèle de processus que possible.
– 2 : Minimiser les chemins de routage de chaque élément.
– 3 : Utiliser un unique événement de départ et un unique événement de fin.
– 4 : Structurer le modèle le mieux possible.
– 5 : Éviter les éléments de routage OR.
– 6 : Utiliser des étiquettes d’activité verbe-objet.
– 7 : Décomposer le modèle s’il a plus de 50 éléments.
Les 7 PMG sont utiles pour guider les utilisateurs à améliorer la qualité de leurs modèles et pour devenir plus compréhensible. Chacune de ces lignes donne des directives sur la façon dont un modèle de processus peut être amélioré. Donc, les 7 PMG permettent d’améliorer l’efficacité des projets au sein des entreprises qui s’appuient sur ce type de modèles conceptuels pour modéliser leurs systèmes.
Il est important de noter que l’application des 7 PMG ne touche pas la logique qui se trouve derrière le modèle original.

Les contraintes

Afin de garantir une bonne construction du modèle, nous pouvons définir des pré- et/ ou post-conditions pour chaque étape de BP. L’application des conventions de codage est une étape de base dans le processus d’amélioration de la qualité et l’efficacité. Le langage GooMod est utilisé pour établir les conventions de codage dés la phase de la modélisation. Ces conventions ont été définit par le langage OCL(Object Constraint Language). Ce langage de spécification formelle, permet de définir syntaxiquement et sémantiquement des restrictions sur les modèles exprimés dans des notations graphiques, étendant ainsi la capacité expressive de telles notations.
De cette façon, les schémas complétés par des expressions OCL sont plus exacts et complets.

Contraintes qualitatives

L’avantage avec GooMod que l’amélioration de la lisibilité du code du logiciel est forcée, ce qui permet après aux membres de l’équipe de comprendre le code plus rapidement et en profondeur. Pour une bonne lisibilité du code, les conventions de nommage doivent être respectées.

Introduction

Afin d’améliorer la qualité de ses logiciels produits, Agrostar, filiale du groupe STEF-TFE, a besoin d’améliorer le processus de développement logiciel.
Dans ce chapitre, nous présenterons le processus du développement d’un logiciel, chez Agrostar avec et sans la BP définie dans le chapitre précédent. Ensuite, nous nous intéresserons aux résultats des mesures de la qualité prise avec l’outil CAST dans les deux cas. Enfin, nous interpréterons les courbes obtenues de différents facteurs de qualité.

Processus du développement d’un logiciel sans BP

La mise en œuvre du programme de mesure à Agrostar a été motivée par des raisons de la qualité. Le but était d’améliorer la qualité du code en premier lieu. Nous présentons dans la figure 3.1 le processus du développement d’un logiciel dans Agrostar avant d’intégrer l’outil de BP.

Analyse des résultats

Les tableaux de corrélation (voir Annexe), obtenus avec le logiciel de statistique R, présentent les matrices de corrélation respectives de métriques de classes et de méthodes. Dans le cas des métriques de classe, le tableau est donc constitué de 441 cellules et pour celui des métriques de méthode 256 cellules.
Certains des coefficients sont particulièrement petits, par exemple entre le CE et le CA (0.01) ou entre Num_Fields et Num_Children(-0.04) pour les métriques de classe, et entre Fan_In et Cm_Ratio (0.01) ou entre Coupling et Fan_out (-0.01) pour les métriques de méthodes. Il n ’ y a aucun intérêt pour s’intéresser à ces métriques qui sont indépendants, il faut nécessairement que les variables soient intercorrélées.
Les deux matrices de corrélation comportent aussi un certain nombre de coefficients de taille intéressante entre CE et Cfan_Out (0.93), Lcom et Is_Interface (-0.80) pour les métriques de classe et entre Code_Lines et H_Volume (0.95) pour les métriques de méthodes.
Les corrélations sont présentées dans les 2 tableaux en Annexe, les corrélations positives sont marquées en gris, et les corrélations négatives sont marquées en rouge.

Conclusion

Les systèmes logiciels doivent obligatoirement subir des modifications et afin de répondre à l’évolution des exigences. Aujourd’hui, les bonnes pratiques est parmi les techniques les plus importantes pour améliorer la qualité du logiciel. Cette qualité peut être mesurée en utilisant plusieurs métriques.
Nous nous sommes intéressés, dans ce travail, au développement d’une bonne pratique permettant d’aider les concepteurs, dans un contexte industriel bien défini (Agrostar), lors de la phase de la modélisation afin d’améliorer la qualité du code produit. Pour cela, nous avons utilisé le langage GooMod développé par l’équipe SE du Laboratoire Valoria.
Pour aboutir à ces résultats, nous avons tout d’abord commencé par établir une étude approfondie les métriques et leurs liens avec les bonnes pratiques. Ensuite, nous avons présenté les différentes règles que devra satisfaire le modèle conceptuel du logiciel. Finalement, nous avons abordé l’étape de réalisation où nous avons traduit les étapes de bonnes pratiques en une implémentation via GooMod.
Nous avons examiné les impacts des bonnes pratiques appliquées. Les résultats indiquent un changement significatif. Plus précisément, il semble que les bonnes pratiques ont provoqué une augmentation non négligeable au niveau des trois facteurs de qualité : transferabilité, changeabilité et sécurité. Par contre, cela à causer une régression au niveau de la robustesse. Cette dernière constatation nous a mené à étudier la corrélation entre les différentes métriques de classe et de méthode.
Nous sommes, maintenant, convaincus que les différentes métriques ne sont pas toujours compatibles et qu’il est nécessaire de trouver des compromis. Dans tous les cas, les objectifs de qualité doivent être définis pour chaque logiciel, et la qualité du logiciel doit être contrôlée par rapport à ces objectifs.

Table des matières
Remerciements 
Introduction générale 
1 Etat de l’art 
1.1 Qu’est ce qu’un logiciel de qualité ?
1.2 La crise du logiciel
1.3 Facteurs de qualité
1.4 Métriques
1.4.1 Quelques exemples de métriques
1.4.2 Utilité des métriques
1.4.3 Normalisation des métriques
1.4.4 Outils d’évaluation de la qualité
1.5 Démarches d’amélioration de la qualité
1.5.1 Bonnes pratiques
2 Modélisation des bonnes pratiques
2.1 GooMod : Langage de modélisation des BPs
2.1.1 Syntaxe abstraite de GooMod
2.1.2 Architecture générale de la plateforme GooMod
2.2 Définition de BP
2.2.1 Les contraintes
2.2.2 Les actions
2.2.3 Les concepts
2.3 Exemple de définition de BPs
3 Etude de cas
3.1 Processus du développement d’un logiciel sans BP
3.2 Processus du développement d’un logiciel avec BP
3.3 Interprétation des résultats
4 Etude emirique 
4.1 Métriques
4.1.1 Métriques de classe
4.1.2 Métriques de méthode
4.2 Evaluation des métriques
4.2.1 Etude de la corrélation
4.2.2 Analyse des résultats
Conclusion 
Bibliographie
Annexes 
A Tableaux 

Télécharger le rapport complet