Principe de conception
Un «bon» module est un module réutilisable, c’est-à-dire conçu dans l’optique d’être placé dans une bibliothèque à des buts de réutilisation. Afin de marier modularité et réutilisabilité, quelques conditions nécessaire à la conception de bons modules ont été définis :
– un module doit pouvoir manipuler plusieurs types différents. Un module de liste par exemple doit pouvoir manipuler aussi bien des entiers que des types composites ;
– un module doit pouvoir s’adapter aux différentes structures de données manipulées dotées de méthodes spécifiques. Il devra ainsi par exemple pouvoir rechercher de la même manière une information contenue dans un tableau, une liste, un fichier ;
– un module doit pouvoir offrir des opérations aux clients qui l’utilisent sans que ceux-ci ne connaissent l’implantation de l’opération. Ceci est une conséquence directe du masquage de l’information préconisé.
– les opérations communes à un groupe de module doivent pouvoir être factorisées dans un même module. Ainsi par exemple, les modules effectuant du stockage de données, tels que les listes, les tables, etc. doivent être dotés d’opérations de même nom permettant d’accéder à des éléments, d’effectuer un parcours, de tester la présence d’éléments. Ceci peut permettre entre autres de définir des algorithmes communs, tels que la recherche, quelle que soit la structure de données utilisée pour stocker les données. Ceux-ci satisfont en particulier les critères de modularité. En ce qui concerne les critères de réutilisabilité, il est possible d’aller encore plus loin. De nouvelles notions vont permettre de franchir ce pas :
– la surcharge : cette notion prévoit que des opérations appartenants à des modules différents peuvent être associées an même nom. Les opérations ne sont donc plus indépendantes, elles prennent leur signification contextuellement en fonction du cadre dans lequel elles sont utilisées. Cela peut permettre par exemple de définir une fonction insérer dans chaque module de stockage, permettant d’écrire de manière uniforme : insérer (elt, container) quelque soit le type de container (liste, tableau, fichier, …) ;
– la généricité cette notion permet de définir des modules paramétrés par le type qu’ils manipulent. Un module générique n’est alors pas directement utilisable : c’est plutôt un patron de module qui sera « instancié» par les types paramètres qu’il accepte. Cette notion est très intéressante, car elle va permettre la définition de méthodes (façon de travailler) que de fonctions (plus formelles). Dans cette version récente d’ACCEAO, nous devons changer l’interface graphique afin de simplifier l’implantation de la souris.
La souris
La souris est plus confortable et plus pratique pour certaines actions du programme. Les boutons de la souris jouent rôle important. L’état de la souris et de son pointeur se définit à partir des éléments suivants :
• position du pointeur ;
• état des boutons (enfoncé ou non enfoncé) ;
Ecrire un programme supportant la souris est un peu difficile et compliqué quand il s’agit de programmer sous DOS. Toutefois DOS supporte la souris, pourvu que l’on ait une souris et un « driver » approprié. ACCEAO 4.2 utilise la version 8.20 du driver mouse.com de Microsoft®. Programmer la souris sous DOS implique d’invoquer l’interruption 33h [5]. En des termes simples, une interruption est un signal qui dit au processeur d’arrêter temporairement ce qu’il est en train de faire et l’invite à aborder une autre tâche. On utilise la fonction geninterrupt() [6] pour invoquer l’interruption.
Les messages
Un événement est tout changement d’état de l’écran, de la souris ou du clavier. Certains événements qui pourraient être utiles au programme sont traduits en messages. Les messages sont des événements traduits en nombre entier pour pouvoir être traité par des fonctions. Il y a deux types de messages :
− le premier est obtenu lorsque l’utilisateur exécute une commande à partir du menu. Ce sont les messages normaux.
− le second est obtenu lorsque l’utilisateur exécute une commande en combinant quelque touche du clavier. Ce sont les raccourcis clavier. Ces deux messages ne suivent pas la même chaîne de traitement. Le premier « sort » des « menu_item » et le second « sort » d’un e fonction spéciale qui scanne les touches appuyées pour identifier le message. On peut dire que le programme boucle sur deux fonctions (Fig. 2.5) :
• menu.activate() qui active la barre de menu et attend que l’utilisateur choisit une commande à partir du menu,
• shortcut(msg) qui scanne tout appui sur le clavier et identifie la commande correspondante.
CONCLUSION
Tout d’abord, des efforts ont été apportés pour améliorer la rubrique d’aide « HELP » de ACCEAO 4.2 : la présentation a été changé et les rubriques sont accessibles avec le pointeur de la souris. Ensuite, pour faciliter l’introduction de la souris dans l’utilisation du logiciel, il a été nécessaire de recoder l’interface graphique. L’interface de la version 4.1 n’était pas conçue, pour l’accueil d’une souris. L’interface de ACCEAO 4.2 a été obtenue à partir de quelques classes développées à l’aide de Turbo C++ version 3.1 de Borland, sous MS-DOS. Ainsi le tracé des circuits, la sélection des composants, leur déplacement et l’accès aux menus peut se faire à l’aide de la souris. Et tout ceci n’empêche pas le clavier de perdre ses fonctionnalités. Les travaux ont été réalisés sous environnement MS-DOS mais le « double clique » n’est pas encore fonctionnelle. Ainsi pour la prochaine amélioration de ce logiciel, il est souhaitable d’étudier le travail sous le système d’exploitation WINDOWS ou sous LINUX pour cibler le grand public qui pourrait être intéressé par ACCEAO et accroître la puissance de calcul. Et il ne faut pas perdre de vue, que le traitement des circuits numériques ou composants numériques est encore à considérer.
|
Table des matières
Introduction
Chapitre I : DESCRIPTION du LOGICIEL
1. La nouvelle version d’ACCEAO
1.1. Améliorations apportées par la version 4.2
1.2. Implantation de l’interface graphique et de la souris
2. Technique de conception d’un logiciel
2.1. La modularité
Principes de conception
2.2. La réutilisabilité
Principe de conception
3. Application de la technique à la version
3.1. Les obligations graphiques
3.2. La souris
a. Traiter les messages de la souris
b. Propriétés des messages de la souris
3.3. Le programme
La boucle de messages
Chapitre II : IMPLANTATION DE LA NOUVELLE INTERFACE UTILISATEUR
1. La souris
2. L’interface graphique
2.1. La classe btn
2.2. La classe menu_item
2.3. La classe drop_menu
2.4. La classe menu_bar
3. Les gestionnaires d’événement
3.1. Les messages
3.2. La fonction de message
3.3. Les raccourcis claviers
3.4. La boucle de message
4. Structure de l’application
Chapitre III : UTILISATION DU LOGICIEL
1. Les menus
1.1. Le menu « file »
a. Créer un nouveau fichier
b. Charger un fichier
c. Sauvegarder un fichier
d. Quitter un programme
1.2. Le menu « tools »
a. Ajouter un composant discret
b. Ajouter nue source
c. Editer un composant
d. Enlever un composant
e. Consulter la bibliothèque
1.3. Le menu « analysis »
1.4. Le menu « design »
a. Concevoir un circuit à transistor
b. Tracer le diagramme de Bode
1.5. Le menu « help »
2. Utiliser l’aide
Télécharger le rapport complet