Rapport final : Projet NETG

Transcription

1 Rapport final : Projet NETG Génie Logiciel Introduction Il nous été demandé de réaliser une librairie permettant de manipuler des nombres entiers très grands dont les capacités dépassent les représentations des entiers 32 ou 64 bits. En plus de cela une librairie permettant de supporter les opérations arithmétiques basiques : addition, soustraction, multiplication et division ainsi que des opérations sur les flux d entrées/sorties des nombres entiers très grands. Voici présentement le rapport final exigé concernant le développement du composant logiciel demandé à la date limite du jeudi 10 juin 2010.

2 1 - Le cahier des charges A) La demande La rédaction du cahier des charges s est faite selon les seules informations fournies se résumant à une demande de deux modules l un permettant la formalisation des nombres entiers très grands puis leur manipulation et l autre une calculatrice usant de ce premier modèle. Ceux-ci pour une utilisation variée et indéterminée comme par exemple la cryptographie. Il a aussi été exigée que l application soit développée afin d être utilisée sous Linux. B) La répartition des tâches Lors de son élaboration nous avons assigné à notre équipe de 5 membres les tâches primaires que chacun occupera au cours du projet. Nous avons répartis 3 développeurs principaux, 1 responsable des tests, et 1 chef de projet. Ces titres n ont cependant été qu indicatifs, la plupart des rôles s étant étendus pour chacun de nous. C) Les fonctions Il était nécessaire de synthétiser la demande sous différentes fonctions directrices. Nous avons déterminé quelles étaient celles de l addition, soustraction, multiplication, division, sauvegarde et chargement des nombres entiers très grands D) Les limites Nous avons définis les limites comme étant que le logiciel ne pourrait effectuer que 4 opérations arithmétiques élémentaires précitées, uniquement utilisable sous Linux et que la taille maximale des nombres serait sans limite si ce n est la puissance de l ordinateur de l utilisateur. Nous verrons que ces limites ont différés du résultat final. E) Elaboration du planning Nous avons découpé les différentes tâches d une première idée et les avons répartis au mieux parallèlement. Nous disposions de 18h maximum pour 27h de travail estimée.

3 2 Spécifications fonctionnelles A) Concept Il était important d avoir notre idée directrice sur comment permettre le stockage des entiers très grands. Plusieurs idées existaient sûrement mais nous nous sommes dirigés vers la solution des tableaux dynamiques de caractères. B) Le pourquoi du concept - Tout d abord le tableau dynamique semblait une bonne solution puisqu il permettrait d avoir une capacité modulable et donc sans limite déterminée, ce qui est grandement nécessaire aux nombres entiers très grands. - Ensuite utiliser des caractères au lieu par exemple d entiers permettrait de manipuler quasi directement ce que l utilisateur saisie, en effet comme il est demandé par la suite de résoudre des expressions arithmétiques a partir de très grands nombres et d une chaine de caractères. Le passage d une chaine de caractère à un tableau dynamique de caractère n est pas une transition difficile. - Ce tableau dynamique de caractère permet aussi d avoir une vision très rapprochée d un nombre puisqu elle consiste a ranger la suite de chiffres aussi logiquement que l on écrit un nombre sur du papier. Par soucis de lisibilité et d accessibilité cette solution ne semble pas être mauvaise et nous avons donc poursuivit dans cet optique de réalisation. C) Elaboration du concept de la calculatrice Il était important d établir une grammaire qui permettrait d identifier ce qu est une expression arithmétique, quelles sont ses composants et comment les reconnaitre et dans quel ordre les calculer. Nous avons modélisés la grammaire arithmétique des expressions que nous avons subdivisées en plusieurs classes : Facteur, Termes, Expression, Operateur d addition et de multiplication ou encore Parenthèse. Ces composants nous permettront ensuite de faciliter la gestion des priorités. D) Algorithmes de calculs A ce stade nous n avions qu une très vague idée de quels algorithmes employer pour telle ou telle opération arithmétique au final nous avons optés par les solutions les plus évidentes comme une modélisation de la division proche de la division euclidienne. E) API Comme les librairies avaient une volonté d être réutilisable nous avons du définir quel serait l API des librairies en questions avec les méthodes principales. Cependant au final cette première conception diffère partiellement du résultat final notamment au niveau de l organisation des méthodes dans les librairies par soucis de clarté et de cohérence ou encore au niveau des noms des méthodes.

4 3 Conception A) Rédiger la conception Partant d une première structure qu était l API, il était ensuite nécessaire de détailler toute la modélisation de nos librairies. B) Soucis de conception Peu après avoir établit la conception et attaqué la modélisation puis ensuite l implémentation nous avons rapidement constaté qu il existait des incohérences au niveau de la conception ou certaines parties qui ne convenaient pas c est pourquoi nous avons été contraints de faire des changements majeurs à celui-ci. C) Changement Premier gros changement effectué peu de temps après l élaboration de la conception fût le changement du langage employé. La conception a été rédigée dans une optique d être programmée en C++ mais finalement nous avons opté pour le langage Java vu que l on s est au final beaucoup plus orienté vers une modélisation objet et que ce langage ne permettrait plus aisément de le faire bien qu il n était pas exclu au départ de le faire sur C++ il semblait plus aisant de travailler sur du java et ce fût le cas. D autre part le Java à une très grande portabilité en plus d être utilisable dans des logiciels, les librairies pourraient être utilisées dans des applications sur navigateurs par exemple. La librairie n a pas énormément souffert de modifications mais c est moins le cas de celle de la calculatrice qui a subit des changements conséquents comme par exemple le fait que chaque élément possède sa propre fonction de résolution de calcul. Le tout finissant par un appel récursif de chacun des éléments d une expression jusqu à obtenir un résultat. Cependant la majeure partie des calculs s effectue dans la libraire Netg et plus exactement NetgMath. D) Plus orienté objet Comme dit précédemment nous nous sommes un peu plus orienté objet et avons essayés de rendre le code plus clair notamment en divisant certaines parties des librairies. La librairie/package Netg se divisant entre plusieurs classes Netg (structure), NetgMath (opérations) et NetgIO (flux I/O). Et la calculatrice de même sera divisée entre le modèle de l interface de la calculatrice CalcInterface et sa structure : Facteur, Terme, Expression etc

5 4 Implémentation, Javadoc et Profiler Pour implémenter le code nous avons utilisé Eclipse plutôt adapté au Java grâce à ses outils pratiques comme l auto-complétion, son auto-indentation, son outil de génération de Javadoc ou encore son plugin de profiling. 1 - Profiler TPTP d'eclipse 2 - Javadoc générée

6 5 Travail en équipe : Coordination Il était important de bien se coordonner lors des différentes éditions des fichiers sources pour cela nous avons du utiliser un gestionnaire de version SVN, il s agit de la première chose auquel nous ayons pensés avant même de déterminer les spécifications fonctionnelles. Nous avons opté pour celui proposé par Google Code dès le démarrage du projet qui offrait une interface à notre goût, proposait une mise en page sur laquelle nous avions un aperçu direct sur le planning par exemple, chose bien pratique. 3 - Project hosting Google Code Pour utiliser SVN, nous avons utilisé la console de Linux ou encore TortoiseSVN sur Windows. En général nous nous mettions d accord sur qui travaillait sur telle fichier source a tel moment afin d éviter les conflits bien que généralement ceux qui se présentaient se résolvaient assez rapidement. Le serveur SVN de Google Code présentaient par moments quelques soucis qui nous empêchaient d y accéder, nous avions du alors nous débrouiller comme nous pouvions.

7 6 Pour terminer Ce projet terminé nous avons finalement réussi à réaliser les librairies avec leurs fonctionnalités demandées avec une application Calculatrice qui permet de tester ces différentes fonctionnalités et ses différentes documentations. En plus de cela l API de NETG permet en plus des opérations arithmétiques d effectuer des comparaisons, d indiquer avec quelle précision effectuer votre division ou encore de ne récupérer qu une partie d un NETG à l instar d une fonction substring. Comme demandée les NETG ne gèrent a la base que les entiers cependant il est possible d afficher les résultats des divisions produisant des nombres décimaux ou encore les résultats de soustractions produisant des nombres négatifs. Il est cependant conseiller de modérer leur manipulation sous faute de fausser les calculs.