Téléchargement : le mémoire de DEA aux formats DVI, pdf orienté impression, pdf orienté écran, ou au format PostScript. Les sources LaTeX sont également disponibles. Pour les formats dvi et LaTeX, les fichiers sont des archives tar.gz, contenant également les fichiers nécessaires (images encapsulated PostScript, references bibTeX, etc...).
Téléchargement : le mémoire de PFE aux formats DVI, pdf orienté impression, pdf orienté écran, ou au format PostScript. Les sources LaTeX sont disponibles ici, et les annexes pdf tar.gz'ées sont ici.
Cursus de DEA
L'école doctorale m'ayant accueillie est l'Université Joseph Fourier (www-ufrima.imag.fr), sur le campus de St Martin d'Hères. Les cours ont porté sur les méthodes de test, l'ingénierie logicielle, les technologies à composants, les systèmes répartis, et les technologies du web. Mon stage de DEA s'est déroulé au LCIS (Laboratoire de Conception et d'Intégration des Systèmes) à Valence, en partenariat avec le LSR (Logiciels, Systèmes et Réseaux) à Grenoble. Le sujet de mon mémoire, que j'ai défendu en juillet 2003, est (texto) : Testabilité des Systèmes Orientés Objet. Je vais vous en présenter les grandes lignes ci-après.
Le LCIS a commencé le développement, il y a quelques années (1979), de SATAN (System's Automatic Testability ANalysis). Il s'agit d'une technologie d'évaluation de la testabilité de circuits, basée sur l'analyse des flots de données à partir d'une modélisation fonctionnelle dudit circuit. L'avantage est double : d'une part, l'analyse peut se faire très tôt dans le processus de conception du circuit, puisque la modélisation fonctionnelle est une des premières étapes lors de la création. Par ailleurs, l'évaluation permet d'orienter le développement vers des solutions plus facilement testables. SATAN, ainsi, ne génère pas de vecteurs de test, mais seulement une estimation de la complexité et de la testabilité (ie. de la facilité à tester) du circuit. L'utilisation industrielle de cette technologique s'est vite enclenchée : de nombreuses entreprises, au rang desquelles Thalès-Avionics, utilisent lors de la conception de leurs circuits des outils de modélisation fonctionnelle ; un traducteur a donc été écrit pour passer directement du logiciel de conception à l'analyse.
Figure 1
D'un point de vue plus technique, SATAN construit un diagramme d'opérateurs flot de données, représentant les exécutions possibles le long des modules constitutifs des entrées vers les sorties. Le graphe ainsi construit s'appelle un Graphe de Transfert d'Information ou GTI ; on en a un exemple ci-contre. Sur le GTI, le logiciel calcule la contrôlabilité et l'observabilité des éléments rencontrés sur chaque chemin et donne une note à chaque élément.
Plusieurs personnes ont travaillé sur cet outil depuis, et l'ont amélioré et fait évoluer. Il a été adapté à de nouvelles modélisations, dont le langage VHDL, puis à des langages fonctionnels tels que le Pascal et le C. Dans ces deux derniers cas, le pas franchi est considérable puisque l'on peut analyser un programme à partir d'une spécification fonctionnelle formelle, et noter sa testabilité a priori. Cependant, l'analyse se fait toujours sur des flots de données et sur un paradigme séquentiel.
Mon travail de recherche a été d'appliquer la méthodologie utilisée par SATAN aux systèmes Orientés Objet. Le but est de pouvoir lancer des mesures de testabilité de structure (design) dès les premières phases du développement, c'est-à-dire pendant la conception. Les avantages sont multiples : en orientant le développement vers des solutions plus testables, le principe réduit considérablement les coûts et délais occasionnés par la phase de test (nota : dans des domaines critiques tels que l'aéronautique, le test représente jusqu'à 50% des coûts de développement d'un système). De plus, les erreurs de design, qui sont les plus difficiles à corriger en phase de test, peuvent être détectées très tôt, quand un changement de structure est encore possible aisément. Enfin, les estimations de ressources, de coûts et de délais peuvent être réalisés avec une bien plus grande précision, ce qui est important dans le contexte actuel et les démarches de qualité engagées par les entreprises.
Le stade à partir duquel nous souhaitons pouvoir analyser le système est celui du diagramme des classes. Nous nous plaçons pour cela dans le cadre du processus unifié de développement et du méta-langage UML. A ce stade, les classes ont été identifiées au sein de paquetages et les premières relations (associations, compositions et aggrégations) ont été définies entre ces éléments. Une des pistes étaient d'assimiler les classes aux modules du modèle séquentiel, et les relations entre classes à des flots de données, puis de pratiquer une analyse "classique" des écoulements.
Mais il s'est avéré que ce n'était pas possible, pour nombre de raisons répertoriées dans mon mémoire. Parmi celles-ci, notons que la notion de schéma d'opérateurs ou de flot de données est à un bas niveau, contrairement aux notions d'architecture et de design que nous souhaitons addresser. En revanche, quelques axes de prospection ont été proposés pour l'intégration d'indicateurs et l'amélioration de la testabilité dans les développements orientés objet. Ce sont ces axes que nous essaierons d'approfondir lors de la deuxième partie de ces travaux, le projet de fin d'étude.
Cursus d'ingénieur
Mon cursus d'ingénieur, de 1997 à 2003, s'est clot par un projet de fin d'études (PFE) de 4 mois. Ce stage s'est déroulé au sein de Thalès-Avionics, à Valence, dans le département NAT/DT (aka navigation / développement), en partenariat avec le LCIS et le LSR. Dans la continuité du travail précédent, l'objectif de ce stage était de développer un outil de mesure de la qualité logicielle applicable dès le stade de la conception.
Une importante phase de bibliographie, pratiquée lors du stage de DEA, a posé les bases théoriques nécessaires à la réflexion sur les notions de testabilité et les indicateurs de la qualité logicielle. Parmi ceux-ci, notons Subramanyam qui oriente sa réflexion sur une suite de mesures proposée par Chidamber et Kemerer quelques années plus tôt. A ces documents, plusieurs autres ont été ajoutés, davantages portés sur les architectures orientées objet. Ceux que j'ai retenus dans le cadre du projet sont les suivants :
* Chidamber et Kemerer (CK) ont été parmi les premiers à proposer une suite de mesure complète et intégralement étayée par des fondements théoriques. Leurs travaux, parus en 1991 puis en 1994, ont été considérablement repris depuis, certaines des métriques proposées ont confirmées et d'autres infirmées. Subramanyam a publié un article en 2003, confrontant la suite CK à l'expérience acquise en matière de génie logiciel orienté objet depuis 1994. Il propose une nouvelle métrique, la taille des composants, et confirme la pertinence de la plupart des métriques CK. Nous nous appuierons beaucoup sur ces deux travaux.
* Robert Martin propose une analyse s'appliquant au niveau des paquetages (les catégories au sens où l'entendait déjà Booch). Cette approche est intéressante à deux titres : d'une part, les analyses se concentrant sur les interactions entre paquetages sont rares, beaucoup des suites proposées s'intéressant aux classes, voire au contenu de celles-ci. D'autre part, les informations nécessaires à cette analyse sont toutes rapidement disponibles, étant d'un assez haut niveau.
Nous aurions encore pu citer Brito e Abreu, cependant son approche est in principio semblable à celle de la suite CK. Les métriques que nous retiendrons pour le projet sont divisées en deux groupes : celles respectivement dédiées aux paquetages et aux classes.
A chaque paquetage correspondent les valeurs suivantes, ainsi que des statistiques sur ses sous-classes (valeurs minimale, maximale et moyenne des métriques CBO, NOC et DIT) et ses sous-paquetages (valeurs minimale, maximale et moyenne des métriques Ca, Ce, I et A). Les métriques sont celles proposées par R. Martin.
- Le Couplage Afférent (Ca) : décompte des dépendances entrantes. Un paquetage possédant un fort couplage afférent est difficilement modifiable, car de nombreux paquetages dépendent de lui.
- Le Couplage Efférent (Ce) : décompte des dépendances sortantes. Un paquetage possédant un fort couplage efférent est très dépendant des autres paquetages, et sera difficile à tester de manière unitaire.
- L'Instabilité (I) est le couplage relatif, calculé par I = Ce / (Ca + Ce). C'est une valeur comprise entre 0 et 1.
- L'Abstraction (A) est le nombre de classe abstraites divisé par le nombre de classes total d'un paquetage. C'est une valeur comprise entre 0 et 1.
- Le nombre total de sous-classes et sous-paquetages du paquetage courant calculé de manière récursive. Cela donne une indication de la taille et de la complexité du paquetage.
Les métriques de classe sont données ci-après ; elles sont pratiquement toutes issues des travaux de Chidamber et Kemerer. Il aurait été intéressant, comme le proposait Subramanyam, de pouvoir calculer une métrique unique, basée sur le NOC, le DIT et le CBO. Une telle formule de calcul aurait la forme suivante : DEFECTS = f ( alpha * NOC, beta * CBO, gamma * DIT, delta * CBO * DIT ).
Mais la définition précise des coefficients implique la constitution d'un modèle de faute propre aux développements de l'entreprise, et représente un travail de longue haleine -- trop important pour le temps qui m'était imparti.
- Le couplage entre objets (CBO, Coupling Between Objects) : nombre de relations (association, composition, aggrégation) entre la classe courante et les autres classes.
- La profondeur d'héritage (DIT, Depth in Inheritance Tree) est la longueur du plus long chemin vers la racine de l'arbre d'héritage. Une grande profondeur d'héritage fait rapidement exploser la complexité du test (cf. Binder).
- Le nombre d'enfants (NOC, Number Of Children) est le nombre de classes directement héritées de la classe courante. Cette métrique représente la largeur de l'arbre d'héritage.
La solution qui a été envisagée en concertation avec les intervenants industriels est de pratiquer une analyse à partir des schémas modélisés dans l'AGL utilisé au sein de l'unité, soit I-Logix Rhapsody. Une telle intégration permettra aux développeurs d'évaluer aisément leur design de manière régulière sans perte de temps trop importante. Les données issues de l'analyse devront être présentées au développeur de manière conviviale et efficace, afin que la situation puisse être rapidement évaluée d'un simple coup d'œil, et approfondie si besoin est sur les éléments défectueux.
Un outil de mesure de la qualité logicielle était en cours de développement au sein de Thalès-Avionics : UML Checker. A partir de Rhapsody, il est possible de générer un fichier XMI contenant l'architecture et les artefacts du système modélisé. C'est ce fichier qui est passé à UML Checker pour analyse ; la sortie est du XML classique, avec une DTD propre à l'application mais simple. La sortie du logiciel comprend certaines des métriques que nous souhaitions, et d'autres ne nous intéressant pas ; j'ai donc fait le choix de transformer cette sortie en un fichier HTML, intégrant les métriques sélectionnées et quelques autres qui sont calculées pendant la transformation. L'utilisation du HTML permet également une grande navigabilité dans le design, afin de prospecter aisément et d'identifier les classes fautives.
La transformation du XML (en sortie de UML Checker) en HTML pour la présentation se fait au moyen d'un moteur XSLT : xalan. Plusieurs pages html sont générées, comportant plus ou moins de détails afin de cibler précisément les recherches. Le passage de l'une (vue d'ensemble) à l'autre (informations exhaustive) page se fait par liens, et il est possible de naviguer complètement dans l'architecture de classes en classes, en remontant le long des paquetages, en suivant les valeurs minimales et maximales de métriques...
Afin de confirmer la pertinence de la nouvelle suite, nous avons appliqué le logiciel à une architecture développée dans le cadre d'un prototype de conduite de vol. En analysant les résultats, j'ai identifié plusieurs classes qui avaient dû poser des problèmes lors de l'intégration ou du test, puis nous en avons discuté avec un des développeurs de l'équipe, qui avait travaillé sur ledit prototype. Il a confirmé point par point l'analyse, et applique désormais l'outil aux développements orientés objet destinés à la certification.
| < Précédent | Suivant > |
|---|
