Génération dynamique d'interfaces spécifiques dans l'exploitation des processus d'ingénierie logicielle en apprentissage

Chapitre 2

Problématique

La question

Peut-on abstraire la définition des interfaces pour le déroulement d'un processus de développement à des fins pédagogiques?

a-t-elle une réponse plausible tenant compte des attributs, méthodes et objets manipulés par celles-ci?

Dans ce chapitre, nous présentons les motivations ayant sous-tendu nos travaux pour l'intégration d'une troisième dimension dans les bases de connaissances des processus de développement à l'aide des objets réutilisables. Ensuite, nous faisons un tour d'horizon des approches de résolutions existantes, puis un comparatif de celles-ci en termes d'avantages et d'inconvénients tenant compte des attributs de qualité logicielle. Mais avant, nous présentons la notion d'IHM.

2.1 Notions d'Interaction Homme-Machine

Hans V. Vliet résume l'Interaction Homme-Machine dans [Vliet 2002] à la résolution du problème suivant : comment rapprocher le plus possible le modèle mental de l'utilisateur (acquis par les formations et la documentation) du modèle conceptuel (modèle technique) d'une application? L'IHM est devenue le leimotiv de l'ingéniérie du domaine. On a ainsi assisté à l'émergence de plusieurs modèles d'IHM ayant toutes en commun la séparation des fonctionnalités du système, des interactions du système avec l'utilisateur. La décomposition largement adoptée aujourd'hui est le paradigme Modèle-Vue-Contrôleur' (MVC). La figure 2.1 présente les trois concepts du paradigme et les relations entre ces trois concepts et l'utilisateur. L'utilisateur se sert du contrôleur qui lui-même manipule le modèle, le modèle met à jour la vue qui est présentée à l'utilisateur. C'est dans un souci de séparation du

'MVC, http :// www.cs.indiana.edu/ cbaray/projects/mvc.html

contenu, du modèle et de la vue que nous vous présentons la nécessité des interfaces pour l'exploitation des connaissances sur les processus de développement en apprentissage.

FIG. 2.1 Paradigme MVC

2.2 D'ou vient le besoin d'un interfaçage dynamique?

Adopter un processus et le mettre en oeuvre c 'est, logiquement, une démarche qni consiste à instancier les artefacts, les consulter, les modifier et les supprimer au besoin; par des rOles précis au conrs d'activités spécifiqnes.

Le développement de logiciels de complexité croissante s'avère de plus en plus difficile aujourd'hui. Les développeurs apprennent continuellement les pratiques des nouvelles méthodologies de développement en les appliquant à leurs projets. Ces dernières elles mêmes de plus en plus complexes ne fournissent des résultats qu'après plusieurs années de mise en oeuvre dans divers autres projets et une adaptation conséquente au type de projet. Une approche de solution a été proposée dans [Moghomaye 2003] avec l'élaboration et l'exploitation d'une base de connaissances qui vient essayer de solutionner ce problème en permettant de capitaliser des connaissances et les mettre à la disposition du développeur à des fins pédagogiques

dans le cas du processus RUP².

Aujourd'hui, l'évolution des methodologies de developpement a separe celles-ci du langage sous-jacent utilise; il y'a neanmoins une panoplie de langages ou plutôt de semantiques à prendre en compte dans l'exploitation des connaissances sur le processus. Pour illustrer notre propos : avec MERISE, on parle d'entites, associations, flux, graphe de dependances; avec RUP et les derives qui utilisent UML, on parle de classes, associations, diagramme de sequence, diagramme d'activite, . . . Alors, comment derouler un processus en faisant abstraction du langage, mieux, de la terminologie sous-jacente utilisee?

Alfred AHO dans [Aho et al. 1998] definissait l'informatique comme la mecanisation de l'abstraction, une science de l'abstraction où il s'agit de creer le bon modèle pour un problème et d'imaginer les bonnes techniques automatisables et appropriees pour le resoudre. On se demande donc comment mettre en oeuvre le processus de moulage des processus conformes au metamodèle SPEM.

Les systèmes à base de connaissances ont jusqu'ici abstrait deux (02) dimensions pour l'elaboration des bases de connaissances les plus complexes. Ce qui est assez singulier c'est qu'on ait fourni un effort considerable à l'elaboration beaucoup plus qu'à l'exploitation de celles-ci. En effet, très souvent l'exploitation se limite à une restitution plus ou moins lineaire (voir figure 2.2 l'outil RUP de IBM³ Rational Software) à la manière des livres des connaissances factuelles sur le processus [Nasser 2002, Krol et al. 2003]. Ceci etant très souvent l'agent vecteur d'une surcharge cognitive de l'apprenant. Pourtant, au-delà de l'interêt que nous avons toujours voue aux systèmes à base de connaissances sur ces deux (02) dimensions, nous pensons qu'il faudrait y integrer à des fins pedagogiques une troisième : la dimension GUI qui consiste à decrire les interfaces d'apprentissage (voir figure 2.3).

On peut se demander, en faisant une analogie avec les Bases de Donnees, de l'utilite de munir les Bases de Connaissances de Processus d'interfaces specifiques pour l'exploitation. En effet, l'approche est assez deplacee vu le contexte actuel des BD, on ne saurait munir les donnees d'interfaces specifiques pour les exploiter, ce serait contraindre leur utilisation. Mais, il faudrait se dire que la BD stocke des donnees tandis que la BC stocke des connaissances; une connaissance étant une ou plusieurs donnée(s) et des informations sur celle(s)-ci. D'ohi peut-être la necessite de gerer des interfaces d'exploitation. On peut egalement se demander si cette approche couplee aux technologies XUL pour la description des interfaces, et XSL pour le formatage et la presentation ne serait pas idoine pour les BD, car il est communement admis que l'on effectue generalement sur les donnees les operations d'ajout, de consultation, de mise à jour et de suppression. Et aussi des interfaces permettant d'exploiter les mêmes donnees ne diffèrent très souvent que par l'Interface Homme Machine qui concerne beau-

^2pational Unified Process

³IBM Rational Software, http ://www.ibm.eom/rational/

FIG. 2.2 Description linéaire du processus RUP par IBM

FIG. 2.3 Les trois (03) dimensions d'une base de connaissances

coup plus les aspects de style. De plus, ce ne serait pas nouveau, l'approche de Microsoft Access qui permet de monter des projets de bases de données avec des interfaces prédéfinies et modelables va dans ce sens. Néanmoins, il sera peut-être difficile de définir un standard pour les objets (tables) manipulés car ne les connaissant pas à priori : une base de données pouvant servir à plusieurs applications dans différents domaines contrairement à une base de connaissances.

Il s'agit donc pour nous de fournir des préalables à l'élaboration et l'exploitation des objets réutilisables des processus de développement afin d'intégrer effectivement ces trois (03) dimensions.