Soutenance mémoire
La problématique des métriques internes dans le monde composant
L’évolution de tout système logiciel est inévitable. La première loi de Lehman [LB85] stipule clairement ce fait : « Un programme utilisé dans un environnement du monde réel doit nécessairement changer sinon il deviendra progressivement de moins en moins utile dans cet environnement ». Cette loi, énoncée dans les années 70, n’a jamais été contredite. Malheureusement, suite aux modifications successives qu’il subit, l’architecture d’un système logiciel tend à se dégrader. Il devient alors de plus en plus difficile à comprendre et donc à modifier [Par94]. Inexorablement, les modifications nécessaires sont de plus en plus délicates à réaliser jusqu’à atteindre un coût prohibitif. Une fois atteint ce stade, le logiciel n’est plus maintenu. Il commence à perdre de son utilité, précipitant son abandon. Différentes concepts, méthodes et langages ont donc été proposés pour remédier au problème du « vieillissement » (software aging) des logiciels. On citera en particulier : les techniques de réingénierie, le paradigme composant et l’ingénierie dirigée par les modèles. Le paradigme composant, qui prône l’assemblage de briques logiciels autonomes et réutilisables, est une proposition intéressante pour diminuer les coûts de maintenance. Son usage tend donc à se répandre dans l’industrie. Dans le paradigme composant, comme dans tous les autres, les architectes et les développeurs doivent pouvoir évaluer la qualité de ce qu’ils produisent : au plus tôt, en particulier tout au long du processus de conception et de codage. De nombreux modèles de qualité ont donc été proposés pour aider à définir ce qu’est la qualité externe et interne des composants [WYF03, BV02, AAM05b, RM06]. Comme dans les autres paradigmes ces modèles insistent que le fait qu’il est utile de disposer de « métriques internes » applicables à un code ou à un modèle d’architecture pour prédire, dès que possible, la qualité « externe » du composant ou de l’architecture en cours de développement.
L’étude bibliographique que j’ai conduite sur les métriques de niveau code a permis d’obtenir une vision autant académique qu’industrielle des métriques actuellement proposées, utilisées et outillées à la fois dans les paradigmes impératif, objet et composant. Cette étude a mis en valeur d’un côté l’énorme diversité des métriques à disposition des développeurs pour mesurer des codes de type impératif et objet. Rien que dans le monde objet des dizaines de métriques ont été proposées ces vingt dernières années. On citera en particulier [Lak96, CK94, Mar03]. Plus encore on dispose désormais d’un recul suffisant, étayé par de nombreuses études, sur : leur formalisation, complétude, cohésion et intérêt pratique. En particulier, de multiples expérimentations ont été conduites pour évaluer selon les cas leur corrélation et/ou leur pouvoir de prédiction de la qualité externe des artefacts mesurés [LH93, BBM96, GFS05, NBZ06]. Mais cette étude a également révélé le manque évident de recul, de consensus et surtout l’absence totale d’outils supports dans le domaine des métriques du monde composant. S’il existe plusieurs propositions de métrique ad hoc dans la littérature [WYF03, CS08, WZWRZ09, CKK01, CKHK09], aucune n’a fait l’objet d’une étude sérieuse quant à leur complétude, leur cohésion et surtout à leur aptitude à prédire la qualité externe des artefacts développés. De toute façon, l’absence de prise en charge de ces métriques par les outils d’analyse de code du marché rend impossible tout usage industriel.
À ce jour, les développeurs du monde composant sont donc condamnés : au mieux à utiliser, lorsqu’ils le peuvent, de métriques non spécifiques au monde composant mais sans réel certitude sur l’intérêt qu’ils ont à collecter et à interpréter telle ou telle mesure, au pire à n’utiliser d’aucune métrique. Dans les deux cas, la prédiction à priori de la qualité de leur développement est un pari hautement hasardeux avec pour conséquence une augmentation des coûts consécutive à la découverte tardive de défauts. Comme l’indique [ASGJ13], en l’état le contrôle de la qualité dans le paradigme composant est difficile à effectuer.
Ingénierie des logiciels à base de composants
« When paradigms change, the world itself changes with them.» Ce propos de Kuhn [Kuh12], évoque les changements qu’introduit l’émergence d’un nouveau paradigme. Le paradigme composant change la manière de développer des applications mais en consolidant quelques-uns des grands principes de programmation en particulier le masquage d’information et la réutilisation. Dans cette section, je définis la notion d’ingénierie des logiciels à base de composants. J’introduis ensuite, la notion de composant logiciel en rappelant quelques-unes des définitions proposées dans la littérature. Je décris le processus du développement à base de composants qui est divisé en deux grands processus : le processus de développement d’un composant et le processus de développement d’un système. Enfin, je présente, les notions d’architecture logicielle puis de modèle de composant. Je me focalise en particulier sur le modèle de composant support de mon étude : le modèle OSGi, en mettant en avant les critères choisis pour sélectionner ce modèle.
Ingénierie des logiciels à base de composants
Certains ont considéré que le paradigme objet n’a pas tenu toutes ses promesses sur certains objectifs tels que la réutilisation et la modularité [Car96]. La complexité allant croissante des applications et le besoin d’accroître la réutilisation ont eu pour effet, à la fin des années soixante, de faire émerger un nouveau paradigme de développement : l’ingénierie des logiciels à base de composants . Qu’est-ce que la CBSE et quels sont ses objectifs ?
Le but du CBSE est d’envisager le développement d’une application informatique comme un processus d’assemblage d’unités informatiques de grosse granularité préexistantes ou non, que l’on nomme composant. La CBSE est une approche qui unifie les concepts de plusieurs domaines de logiciels, tels que la programmation orientée-objet, la méga-programmation, l’architecture logicielle et l’informatique répartie [KN96]. Elle supporte à la fois le développement de composants réutilisables (développement pour la réutilisation) et le développement des applications à base de composants (développement par la réutilisation).
Les objectifs posés par la CBSE sont multiples :
— La réutilisation : l’usage dans les projets de composants déjà existants et ayant fait leur preuve évite des développements inutiles et contribuent à l’augmentation de la qualité du produit.
— L’abstraction : est une aptitude importante pour faciliter la réutilisation du logiciel [KRW07]. Un composant doit être doté d’une description précise, complète et minimale : une spécification.
— L’autonomie : est une autre aptitude importante de la réutilisation. L’autonomie peut être quantifiée à travers le « nombre des interfaces requises » [CSO+07]. Un composant est complètement autonome s’il ne possède aucune interface requise.
— La modularité : est un principe fondamental du CBSE. Décomposer un logiciel en modules ayant chacun une fonction précise est une solution aux grands programmes qui sont difficiles à maintenir.
— L’assemblage : consiste à rechercher, adapter et assembler des composants hétérogènes qui viennent de différents fournisseurs afin d’atteindre la fonction désirée.
Bien que la notion de composant date de 1968 avec McIlroy [McI68], elle n’est devenue réellement émergente qu’à la fin des années 1990. La réussite de cette approche du développement est maintenant établie, en témoigne les nombreux développements industriels réalisés dans ce paradigme ces dernières années. On peut donc affirmer comme le soulignait Udell « Object orientation has failed but component software is succeeding » [Ude94].
|
Table des matières
I Introduction
1 Problématique de l’évaluation de la qualité dans le paradigme composant
1.1 La problématique des métriques internes dans le monde composant
1.2 Thèse soutenue et démarche suivie
1.3 Structuration du document
II Contexte du travail et État de l’art
2 Contexte du travail
2.1 Ingénierie des logiciels à base de composants
2.1.1 Ingénierie des logiciels à base de composants
2.1.2 Composant logiciel
2.1.3 Procédé de développement à base de composants
2.1.4 Architecture logicielle
2.1.5 Modèle de composants et infrastructure
2.1.5.1 Notion d’un modèle de composants
2.1.5.2 Le modèle de composant OSGi
2.2 Évaluation de la qualité
2.2.1 Qualité
2.2.2 Mesure
2.2.3 Modèle de qualité
2.2.4 Métrique de qualité
2.2.4.1 Métriques internes
2.2.4.2 Métriques externes
2.2.4.3 Validation des métriques
2.2.5 Outil d’évaluation de la qualité
2.2.5.1 Notion d’un outil d’évaluation statique de la qualité
2.2.5.2 L’outil d’évaluation de la qualité : Sonargraph
2.2.6 Modèle de prédiction
2.2.6.1 Prédire la qualité logicielle
2.2.6.2 Modèle de prédiction de la qualité logicielle
2.3 Résumé
3 État de l’art
3.1 Les modéles de qualité dans le domaine composant
3.1.1 Modèle de qualité de Washizaki et al
3.1.2 Modèle de qualité de Bertoa et Vallecillo
3.1.3 Modèle de qualité d’Alvaro et al
3.1.4 Modèle de qualité de Simao et Belchior
3.1.5 Modèle de qualité de Rawashdeh et Matalkah
3.1.6 Synthèse
3.2 Les métriques de qualité dans le domaine des composants
3.2.1 Les métriques de niveau composant
3.2.1.1 Les métriques de Washizaki et al
3.2.1.2 Les métriques de Sedigh-Ali et al
3.2.1.3 Les métriques de Cho et al
3.2.2 Les métriques de niveau application
3.2.2.1 Les métriques de Wei et al
3.2.2.2 Les métriques de Narasimhan et Hendradjaya
3.2.2.3 Les métriques proposées par Choi et al
3.2.3 Les métriques de niveau interface
3.2.3.1 Les métriques proposées par Rotaru et Dobre
3.2.3.2 Les métriques proposées par Boxall et Araban
3.2.4 Synthèse
3.3 Les métriques primitives
3.3.1 Les métriques de taille
3.3.1.1 Lignes de code
3.3.1.2 Points de fonction
3.3.2 Les métriques de complexité
3.3.2.1 La complexité cyclomatique basée sur la théorie des graphes
3.3.2.2 La complexité de la compréhension basée sur le nombre d’opérateurs et d’opérandes
3.3.2.3 La complexité de la structure basée sur le flux d’informations
3.3.3 Synthèse
3.4 Les métriques Orientées-Objet
3.4.1 Métriques d’encapsulation
3.4.2 Métriques d’héritage
3.4.3 Métriques de polymorphisme
3.4.4 Métriques d’abstraction
3.4.5 Synthèse
3.5 Les Modèles de prédiction dans l’OO
3.6 Résumé
III Contribution de la thèse
4 Identification de métriques exploitables dans le paradigme composant
4.1 Identification de métriques calculables
4.1.1 Choix de la granularité des mesures et points de vue
4.1.2 Métriques intra-composant
4.1.2.1 Métriques de tailles
4.1.2.2 Métriques de dépendances internes
4.1.3 Métriques interface
4.1.4 Métriques application
4.1.5 Synthèse
4.2 Étude de la distribution des métriques candidates
4.2.1 Applications utilisées
4.2.2 Processus d’étude utilisé
4.2.3 La distribution des métriques
4.2.3.1 Métriques intra-composant
4.2.3.2 Métriques interface
4.2.3.3 Métriques application
4.2.4 Signification des métriques utilisées selon leurs granularités
4.2.5 Discussion
4.2.5.1 Le point de vue du développeur
4.2.5.2 Le point de vue de l’architecte
4.2.6 Synthèse
4.3 Résumé
5 Validation des métriques
5.1 Processus de validation des métriques
5.1.1 Description du processus
5.1.1.1 Étapes du processus
5.1.2 Applications sélectionnées
5.1.3 Extraction des données
5.1.3.1 Les outils utilisés
5.1.3.2 Extraction des métriques et des 2 mesures externes
5.1.4 Techniques statistiques utilisées
5.2 Résultat
5.2.1 Corrélation avec les révisions
5.2.2 Corrélation avec les bugs
5.3 Discussion
5.4 Limite de travail effectué
5.5 Résumé
6 Construct
IV Conclusion
