Limites cruciales (espace/temps)

L’objectif de cette section est de recadrer les spécifications du prototype dans les limites liées aux contraintes matérielles de son existence effective.

Ces considérations ont pour conséquence de limiter le projet par son coût en espace et en temps, et par ses perspectives d’utilisation en tenant compte du contexte de l’existence commerciale de Cabri-géomètre.

Le dernier aspect, qui joue un rôle important pour les différents choix de conception, est la prise en compte de l’insertion du prototype dans le contexte d’un « projet » d’équipe. En effet, le logiciel Cabri-géomètre définit un cadre propice aux investigations dans des recherches nouvelles et plusieurs personnes travaillent simultanément à son évolution.

Examinons donc les contraintes liées au surcoût matériel, au produit commercial et enfin au projet Cabri-géomètre.

1°) Surcoût matériel

a . E s p a c e

La version officielle de Cabri II tient sur une disquette (1,4 Mo), et une version existe sur une calculatrice, la TI-92. Ces qualités doivent être préservées : l’intégration de nouvelles fonctionnalités dans ce logiciel doit consommer un minimum de place mémoire supplémentaire. Pour estimer le surcoût tolérable, on peut s’appuyer sur quelques principes issus du sens commun.

L’augmentation du code due à l’intégration de nouvelles fonctionnalités dans un logiciel doit être en rapport avec l’importance de ces fonctionnalités dans l’étendue des fonctionnalités déjà supportées par le logiciel.

Dans le cas de Cabri, la programmation n’est pas le domaine pour lequel le logiciel a été conçu. Même si nous avons montré que des activités de programmation résultaient de l’utilisation de ce logiciel, son domaine d’application et le principal centre d’intérêt de ses utilisateurs est la visualisation de notions mathématiques ou la modélisation de phénomènes physiques par des outils mathématiques dynamiques.

Lors de l’intégration d’une nouvelle vue des données, le surcoût doit être réparti entre les différentes vues potentielles, mais l’éloignement des traitements nécessaires par rapports aux traitements déjà implémentés peut mener à un surcoût plus important. La vue structurelle constitue un nouvel accès aux données, déjà accessibles directement (pour la plupart) par la vue géométrique. Les traitements nécessaires à son intégration ne doivent pas prendre plus de place que les traitements purement géométriques.

L’estimation du surcoût toléré peut être basée sur un examen de la répartition des coûts dans le code du logiciel (en %). Le surcoût peut être estimé dans chaque rubrique, en fonction de l’éloignement des besoins à mettre en œuvre pour la vue structurelle, des traitements déjà codés.

Le tableau ci-dessous présente la répartition du code en fonction des fonctionnalités qu’il gère.

Répartition Description Code Données

Librairies récupération de code extérieur 115 Ko 10 % 24 Ko

Ressources communication avec le système 0 Ko 0 % 4 Ko

Squelette d’IHM Programme principal, gestion des

menus, des fichiers, des fenêtres, des dialogues, des préférences, du défaire/refaire et du magnétophone

338 Ko 30 % 24 Ko

Gestion fine du graphique et de l’impression

écran avec l’« allumage » des pixels et l’équivalent papier

114 Ko 10 % 5 Ko

Gestion de la structure de donnée

noyau fonctionnel, constructions, initialisations, sauvegarde et sauvegarde textuelle

126 Ko 12 % 17 Ko

Calculs pour les objets géométriques « simples »

Objet 214 Ko 19 % 7 Ko

Coniques Coniques 103 Ko 9 % 4 Ko

Calculatrice Rpn 32 Ko 3 % 14 Ko

Texte, Table, Nom 32 Ko 3 % 5 Ko

Macros définir, appliquer, sauvegarder 25 Ko 2 % 3 Ko

TI-92 18 Ko 2 % 3 Ko

Ainsi, le squelette devra prendre en charge la gestion d’une « sortie » supplémentaire en réponse à un nouvel item d’un menu. Les boutons du magnétophone devront être complétés par des boutons de gestion des déplacements dans le programme.

Le prototype aura besoin d’une gestion spécifique pour les supports de la vue textuelle : fenêtres et bulles d’aide. Les déplacements de la feuille sous la fenêtre sont à implémenter pour des feuilles de texte, car les feuilles déjà gérées sont uniquement graphiques. La gestion des ascenseurs, le zoom, etc. requièrent une gestion spécifique, aussi coûteuse que celle qui est déjà implémentée. Les transpositions textuelles des déplacements dans l’« historique » de la figure sont aussi entièrement nouvelles. La première version du prototype ne permet pas d’imprimer le programme généré.

L’affichage du texte préparé dans la fenêtre et des attributs graphiques conduit à un surcoût lié principalement à la spécificité des supports de ces « sorties ».

L’insertion de nouvelles structures de donnée est nécessaire pour mémoriser des informations sur la représentation textuelle des objets. Ces nouveaux supports d’information doivent permettre essentiellement de gérer les notations secondaires et de synchroniser les animations de la vue textuelle avec les manipulations directes des objets géométriques.

Le noyau fonctionnel devra être alourdi du traitement de l’identification des objets, de la préparation du texte du programme qui représente une figure, et de la construction dynamique du texte. De plus, pour les quelques types de données qui ont un comportement spécifique (les polygones, avec prise en compte de leurs côtés, les formules, les nombres munis d’unité, les textes et les tables dont les traitements spécifiques pour les coniques, la calculatrice et les objets « non-géométriques »), il est nécessaire de définir une transcription textuelle à supporter par le noyau fonctionnel.

La quantité de code liée au traitement des macros est a priori plus importante dans le prototype que dans la version officielle, puisque les macros sont aussi importantes que les figures dans le programme.

Pour ce prototype, nous n’avons pas considéré le portage sur la TI-92.

Cependant, la réalisation d’un prototype ne subit pas aussi strictement ces contraintes que la réalisation d’un produit. Les attentes du prototype peuvent être décomposées en plusieurs niveaux d’exigence sur le résultat. Le surcoût toléré est alors lié à ce niveau de qualité atteint.

En conséquence, les choix de mise en œuvre du prototype doivent permettre de

• récupérer tout investissement possible en recherchant dans le code existant si des procédures similaires à celles qui s’avèrent nécessaires ne sont pas déjà intégrées,

• minimiser les ressources spécifiques, par exemple en faisant appel principalement à des chaînes de caractères déjà mémorisées.

b . T e m p s

Cabri-géomètre gère un retour d’information pour guider l’utilisateur dans ses choix. Pour cette gestion, chaque donnée déjà introduite par l’utilisateur est considérée dans la boucle d’attente d’événements de l’IHM, de façon à calculer le retour d’information à lui associer.

L’introduction d’une nouvelle vue pour donner accès à ces données implique d’insérer de nouveaux calculs et traitements pour gérer la nouvelle forme des données.

En entrée, seule la vue active est concernée pour calculer si chacune des données est concernée par l’action courante. Par contre, en sortie, toutes les vues synchronisées doivent supporter le retour d’information qui leur est adapté, et ce pour chacune des données.

Par conséquent, toute insertion de retour d’information dans une vue synchronisée conduit à une augmentation du temps d’exécution de cette boucle, à cause du code introduit dans la boucle générale d’attente d’événements.

Le risque, dans le cadre de la programmation en C, est de voir apparaître un scintillement du curseur.

Les structures de données définies dans le logiciel sont optimisées pour le traitement de données géométriques. La gestion d’une autre forme d’affichage des données conduit à la gestion de nouvelles structures de données associées aux structures initiales et donc à un coût supplémentaire pour leurs traitements.

Cela conduit à un compromis entre la modification des structures porteuses des données et la mise au point de traitements plus compliqués. En effet, ces traitements devraient alors compenser l’inadéquation des structures initiales avec la forme des données nécessaire afin de les supporter efficacement.

Les risques encourus sont :

• une augmentation perceptible du temps de chargement du logiciel ou d’une figure,

• un temps de latence apparaissant avant la réalisation des rendus lorsque la vue textuelle est active.

Un moyen pour vérifier si le prototype répond bien à ces exigences, est de réaliser des bancs d’essais (BenchMark), c’est-à-dire des expériences qui dégagent des valeurs quantitatives (voir §III-3-A-1°).

2°) Prolongement commercial

Notre prototype doit conduire à des réalisations intégrées dans les prochaines versions commerciales du logiciel. Les utilisateurs sont habitués à un certain nombre de spécificités du logiciel, qui ont même contribué à leur choix de Cabri. Ces spécificités sont fondamentales et le prototype doit les respecter.

a. Même philosophie

Cabri est muni d’une interface épurée qui permet cependant une très large gamme de possibilités. Comme pour les jeux de société, les logiciels les plus intéressants sont le plus souvent ceux dont les règles sont simples et peu nombreuses, mais dont la combinatoire laisse la place à l’initiative la plus libre pour l’utilisateur.

Cette spécificité conduit à deux principes de conception pour le prototype :

• minimum de « boutons » supplémentaires,

• choix textuel non bloqué.

Le premier point a pour objectif de préserver l’interface épurée sans l’alourdir de choix permanents visibles en dehors quand ils n’ont pas de rapport avec l’activité en cours de l’utilisateur.

Le second point a pour objectif de laisser l’utilisateur libre de choisir le support qui lui convient le mieux pour effectuer les tâches à réaliser.

b. Mêmes prestations

Les prestations d’un logiciel correspondent à l’étendue des fonctionnalités qu’il propose, dans chacune des directions supportées par son noyau fonctionnel.

Font partie des prestations :

• la liste des outils associés au domaine,

• la liste des caractéristiques graphiques paramétrables,

• la liste des langues de dialogue des interfaces…

Si on intègre une nouvelle vue, son comportement doit être cohérent avec celui des autres vues, et par conséquent toutes les fonctionnalités supportées dans les autres vues et qui ont un sens pour la forme des données dans cette vue doivent y être étendues. La vue programme du prototype doit donc avoir un comportement équivalent au comportement des outils supportés par la vue résultat.

Ainsi, la gestion des attributs graphiques doit être maîtrisable depuis la vue programme, et le multilinguisme de l’interface doit être prolongé au niveau du texte du programme de construction.

c. Niveau de qualité des fonctionnalités

Il s’agit là encore principalement d’une conséquence de la préservation de la cohérence. Par exemple, pour la gestion du multilinguisme, les énoncés proposés par le logiciel sont proches de l’expression naturelle dans chacune des langues offertes. La désignation par des démonstratifs accordés, l’accord des adjectifs au genre des noms propres, l’ordre des mots, etc. respectent (dans une certaine mesure) les caractéristiques des langues. La qualité proposée dans la version officielle du logiciel doit être conservée dans le prototype.

Un autre point est que l’intégration d’une vue programme ne doit pas se faire au détriment de la qualité. Si la version officielle respecte subtilement les principes de la manipulation directe, le prototype ne doit pas alourdir les artefacts qui y contribuent (§II-C-2°-a). Il doit aussi respecter les principes de manipulation directe dans chacune des vues, et par conséquent proposer un correspondant satisfaisant pour la forme des données présentées.

3°) Insertion dans un projet

Différents travaux de maintenance, de recherche et de développements des nouvelles fonctionnalités, sont effectués en parallèle sur le logiciel par plusieurs développeurs et chercheurs, effectuant leurs travaux indépendamment les uns des autres. Il en découle un certain nombre de principes de conception parmi lesquels :

• sortir du code commun pour aller dans une zone personnelle de développement par appel de

procédure,

• implémenter en prévoyant les évolutions ultérieures du logiciel, pour que les autres développeurs n’aient pas à se soucier de la maintenance de nos fonctionnalités nouvelles,

• réutiliser au maximum les procédures déjà écrites et maintenues,

• croiser les tests de toutes les procédures définies en définissant de nouvelles utilisations,

• préserver la portabilité en réutilisant du code déjà porté,

• prendre en considération l’avenir pour effectuer les choix,

• minimiser les choix irréversibles.