Conception modulaire

Apprendre à programmer ressemble à apprendre à utiliser un kit de jeu de construction. Il faut alors commencer à construire quelques bouts de la construction à partir de quelques morceaux du jeu. Les quelques fragments ne peuvent être réalisés sans que l’individu ait un minimum d’images du résultat final. Il en est de même avec un programmeur qui ne peut commencer à écrire une ligne d’instruction telle la déclaration d’une variable sans savoir pourquoi. Les différents fragments seront ensuite rassemblés pour constituer l’ensemble. Le concepteur du programme doit alors connaître les relations qui peuvent avoir lieu entre les différents fragments, donc avoir une vision d’ensemble du programme.

Chaque fragment de ce jeu de construction correspond à une des fonctions qui composent l’ECLR. Sachant que l’objectif principal d’un ECLR est de minimiser les difficultés et incidents de conception de l’auteur de niveau 1, chaque fonction doit être suffisamment fiable et bien écrite afin d’être indépendante des autres. Comme dans un kit, un élément doit être transparent par rapport aux autres pour obtenir une convivialité et une facilité dans l’utilisation. Enfin, l’ECLR doit être construit de telle manière que chaque élément peut être associé à un ou plusieurs autres éléments sans difficulté. Dans cette partie de notre étude,

Chapitre 4 ————————————————————————————————— modulaire : l’indépendance, la transparence et la généralité de fonctions octroyées dans chaque module.

4.3.1.1.Indépendance des modules

La résistance d’un environnement de développement aux diverses actions de l’utilisateur peut être garantie en partie par la résolution de dysfonctionnements et de difficultés inter-modules, sachant qu’un module représente pour nous un ensemble de fonctions et opérations

nécessaires pour effectuer une tâche de l’ECLR. En effet, se trouver bloqué pour une action

imprévue par un logiciel est très vite pénible même décourageant surtout si l’auteur de niveau 1 est un néophyte en informatique. Pour éviter qu’un problème ou un dysfonctionnement d’un module ne se répande sur les autres modules, il faut que les modules de l’ECLR soient les plus autonomes et les plus indépendants que possible.

Pour assurer l’indépendance des modules, on peut intégrer le principe de décomposition en couche des modules et de la hiérarchie des composants de chaque module33. Cela offre une meilleure visibilité et contrôle des actions faites par les composants de chaque module et de l’interdépendance entre les modules. Pour ce faire nous allons nous inspirer des réseaux de télécommunication où une couche est constituée d’un module. Chaque couche ne communique avec une autre qu’à travers des services tel que le décrit la figure 4.1. Selon le contexte, il peut s’agir d’un service demandé à la couche supérieure ou inférieure exemple : demande de données ; ou d’un service rendu qui résulte soit d’une demande venant d’une autre couche soit du déroulement normal du programme ECLR.

niveau n + 1

niveau n SAP

Service demandé

Service rendu

Figure 4-1 : Echange de services

—————————— Vers des environnements de création de logiciels robustes ou ECLR Afin de valider et de contrôler ces échanges entre les couches, nous allons introduire la notion de SAP ou Service Access Point34. Les SAP sont gérés par une couche transversale globale et commune à tous les modules.

couche n-1 SAP couche n SAP couche n+1 couche transversale

Figure 4-2 : Couche transversale et SAP

Ainsi, comme le montre la figure 4-2, l’indépendance des couches est bien évidente d’autant plus que toute communication entre elles est contrôlée par la couche transversale. Le module transversal sert également à respecter la structure de l’ECLR à travers la gestion de l’interdépendance des modules. Cette transversalité est le garant de la séparation fonctionnelle des différentes couches. Aussi la gestion et la prise de décision se positionnent dans un niveau hiérarchique indépendant offrant ainsi une meilleure lisibilité et un bon niveau de contrôle des fonctions assurées par l’ECLR.

4.3.1.2.Transparence des modules

Lors de l'exécution d'une commande pendant l'utilisation du SAM, le concepteur du produit final n'a pas à savoir qu'à un instant donné, le contrôle est passé de l'interpréteur (le SAM) au système d'exploitation. Ainsi, tout signe d'erreur ou de problème provenant du SAM et envoyé au système doit être contrôlé et résolu en arrière plan (background).

Deux solutions peuvent être appliquées :

1. Etudier les différentes étapes parcourues par la commande dans le système en repérant le cheminement et en étudiant les conséquences éventuelles. Cette solution peut être très complexe.

Chapitre 4 ————————————————————————————————— 2. L'appel système envoyé par une action dans le SAM doit être traité auparavant par un

autre programme qui analysera la cohérence des commandes engendrées par l'action. Dès qu'un danger par rapport au système se pose, le programme envoie un signal au SAM qui proposera éventuellement par exemple à l'utilisateur de revenir en arrière dans ses démarches. Il y aura donc un lien de retour entre le SAM et le programme d'analyse d'erreurs.

Action de l'utilisateur

A1 A2 An An+1

FILTRE ECLR

Figure 4-3 : Rôle de filtre de l’ECLR

Dans l’ECLR nous allons opter pour la seconde solution. L’ECLR doit alors jouer le rôle de

filtre : seules les commandes syntaxiquement correctes et les actions conformes au cahier des

charges ainsi qu’aux possibilités du SAM sont envoyées au système. Mais toutes ses actions attribuées à l’ECLR doivent être transparentes pour l’utilisateur, d’où la transparence des modules.

Cette notion de transparence rejoint également celle de l’indépendance dans le sens où les activités d’un module ne doivent avoir un impact direct sur les autres. Eventuellement, un module fait appel à un autre pour acquérir des données, en revanche s’il y a un dysfonctionnement interne, les autres couches n’en sauront rien, même si des résultats sont attendus de la part de celui-ci. En effet, grâce au SAP, la couche transversale prend directement en charge la situation, suite à un time-out ou un signal du module défaillant.

4.3.1.3.Modules génériques et standardisés

L’arrivée et le succès de l’Internet démontrent l’importance d’utiliser des fonctions standards c’est-à-dire courantes et normalisées et des fonctions génériques c’est-à-dire communes ; pour toucher un maximum d’utilisateurs. Ces derniers peuvent s’y retrouver plus rapidement et s’habituer aux résultats d’autant plus que les fonctions sont conviviales et faciles à utiliser. A titre d’exemple, nous pouvons citer l’intégration d’un lien hypertexte comme fonction

—————————— Vers des environnements de création de logiciels robustes ou ECLR standard et le bouton «retour en arrière» comme fonction générique. En effet, certains principes sont incontournables pour laisser l’utilisateur «libre» de ses actes, tel que stopper l’action en cours pour effectuer un autre choix. Procurer à l’utilisateur des fonctions génériques et standards devient alors une nécessité voire une obligation pour lui assurer confort, confiance et réussite.

L’un des rôles majeurs de l’ECLR consiste également à assurer à l’utilisateur ces qualités. Pour le concepteur de l’ECLR comme pour l’utilisateur d’un SAM avec un ECLR, avoir un maximum de modules génériques et/ou standards minimise la variété d’erreurs possibles et simplifie le développement en terme de programmation résolvant ainsi une partie des blocages et de mauvaise performance pour atteindre un résultat satisfaisant.

Le savoir-faire de l’ECLR signifie alors un mode d’optimisation de l’attribution de sens à des

données (en acquisition ou en génération), «court-circuitant» le passage par les connaissances

nécessaires qui auraient abouti au même résultat [Prince, 96]. L’ECLR doit garantir la cohérence entre les données utilisateurs et le SAM. Pour ce faire, nous allons intégrer la notion d’agent qui détient le savoir-faire pour manipuler toutes les données. Un agent représente dans ce sens un élément actif du module ou du SAP (figure 4.2), sachant que chaque module ou couche et chaque SAP peuvent être composés en un ou plusieurs agents.