GUYARD Matthieu LALLEMAND Michael MEUSBURGER Matthias POTHIER Damien TRUCHE Damien

SOMMAIRE

INTRODUCTION

I - PRESENTATION DU SUJET

II - PRESENTATION DES FONCTIONNALITES DE LAPPLICATION

III LIMITES ET EVOLUTION POSSIBLES DE LAPPLICATION

15

IV ASPECT HUMAIN

18

CONCLUSION

21

INTRODUCTION

Dveloppe en 1994 afin de raliser lunification des principales mthodes objets, Booch et OMT, la mthode UML (Unified Modeling Language) constitue aujourdhui linvitable travail prparatoire toute conception de programme orient objet. Cependant, effectuer cette tche la main peut se rvler rapidement fastidieux.

Cest pourquoi nous avons choisi pour notre projet tutor de deuxime anne de concevoir un programme permettant llaboration de modles UML.

Nous allons ici essayer de vous prsenter les principales caractristiques de notre application, bien quil soit ncessaire dexpliciter en premier lieu les notions de base qui constituent la modlisation UML. Nous allons galement rendre compte des limites de notre logiciel ainsi que de ses volutions possibles. Finalement, nous allons parler de laspect humain, composante intrinsque llaboration de ce projet.

I)

Prsentation du sujet
I.1) La modlisation U.M.L :

LUML (Unified Modeling Language) est une mthode permettant de reprsenter sous forme de schmas les diffrents composants dun programme orient objet, la manire de la mthode MERISE qui permet de reprsenter la structure dun systme dinformation. Les diffrentes notions manipules dans les modles U.M.L sont :

Les classes (qui peuvent tre considres comme quivalentes aux entits de MERISE) Une classe peut tre concrte ou abstraite. Elle est abstraite si aucun objet de cette classe nest instanci. Si une classe est abstraite, son nom est not entre accolades { nomClasse }

Les attributs (qui peuvent tre considrs comme quivalents aux proprits de MERISE) Un attribut possde un type et peut tre daccs public (+), priv (-) ou protg (#).

Les mthodes Une mthode possde un type de retour (ventuellement nul) et une suite (ventuellement nulle) de paramtres. A la manire des attributs, les mthodes ont un accs qui peut tre, soit public, soit priv, soit protg.

tudiant
- Chaine nom - Entier numEtudiant + etudiant (Chaine nom, Entier numEtudiant) + Chaine RenvoieNom() + Entier RenvoieNum()

Les liens, qui servent reprsenter les relations entre les diffrentes classes. Ils peuvent tre de 4 types :

o Association niveau.

Reprsente deux classes conceptuellement au mme

o Hritage

La classe fille hrite des proprits de la classe mre.

o Agrgation classes.

Reprsente la notion partie/ensemble entre deux

o Composition Comme lagrgation, la composition reprsente la notion partie/ensemble entre deux classes, la diffrence quici, la vie de la classe partie est lie celle de la classe ensemble

On notera par ailleurs dans ces liens (except lhritage) la prsence du concept de cardinalit, qui encore une fois, se retrouve dans la mthode Merise.

I.2) Pourquoi un gnrateur de modles UML ? Tout dabord, il nexiste notre connaissance aucun logiciel de modlisation UML dans le domaine public. Nous pensions ainsi pouvoir mettre disposition les fonctionnalits de base dun logiciel de ce type, qui puisse, pourquoi pas, tre repris et amlior par dautres. I.3) Choix de conception : Nous avons adopt pour la programmation de ce logiciel, le langage JAVA, qui est luimme un langage objet, et nous semblait donc tout particulirement adapt ce sujet. En ce qui concerne linterface graphique, nous avons choisi dutiliser les composants Swing, notamment pour les plus grandes possibilits offertes par rapport Awt. Finalement, le systme dexploitation utilis a t choisi librement par chaque membre de groupe. Le java tant portable, cela na pas pos de problme majeur lors de la phase de dveloppement.

II)

Prsentation des fonctionnalits de lapplication

Lditeur de modle UML a t conu pour une utilisation prive et est caractris par une conomie des fonctions, des contrles simples et une interface graphique accueillante qui permettent une prise en main rapide pour des dbutants en UML. Cette application nest ni de trs haut niveau, ni trs riche, cest pourquoi ses menus simples mais efficaces apportent lutilisateur un rconfort permettant de mettre en forme un modle UML. Lapplication met en uvre les principaux concepts de la modlisation comme la notion de classe, de lien, dattribut ou encore de mthode. Les notions complexes de la modlisation tant dlaisses pour simplifier lapplication. Nous verrons donc dans un premier temps les diffrentes fonctionnalits de ce petit logiciel agrable et fonctionnel.

II.1 Cration des diffrents objets II.1.1 Cration dune classe Rappelons tout dabord ce quest la notion de classe : la classe est llment central de la modlisation UML comme pour le langage JAVA. Celle-ci est compose dun nom, dun type, de ses attributs et enfin de ses mthodes. Le tout compose la classe qui sera la base de notre application. Le nom dune classe ne sera, premirement, pas unique pour une classe cest dire que plusieurs classes pourront porter le mme nom mais chaque classe sera caractrise par sa liste dattributs et de mthodes et deuximement ce nom sera accompagn de son type reprsent traditionnellement comme le veut la norme par des accolades entourant le nom de la classe dans le cas dune classe abstraite et sans accolade dans le cas dune classe concrte. A la cration dune classe, son nom ne sera aucunement vrifi mais admettra uniquement des caractres alphanumriques. Exemple :

En ce qui concerne son type, lutilisateur sera limit dans son choix par une liste droulante indiquant les seules possibilits autorises.

Illustration :

Pour ce qui est de la forme gnrale, chaque classe sera dessine en trois parties distinctes : lentte de la classe sera occupe par son nom et son type, la partie centrale dfinira ses attributs, enfin le bas de page numrera ses diffrentes mthodes.

Schma type dune classe telle quelle est affiche par notre application :

On considrera une classe acheve lorsque son type et son nom seront entrs par lutilisateur.

II.1.2 Cration dun attribut

Les attributs dune classe recensent toutes les variables qui vont tre utilises par cette classe au niveau local. Cest pourquoi il est ncessaire de dfinir un type, un nom, et un accs. Ladaptation de la taille de la classe en fonction de ses donnes tant dcrite plus loin, nous allons tudier la procdure de cration dun attribut. Au dbut de la cration dun attribut, sa classe propritaire nest pas connue et chaque information est saisie au fur et mesure par lutilisateur. On dbute donc avec le nom de lattribut saisi de la mme manire que celui de la classe. Ensuite, on doit connatre le type de celui-ci. Le type dun attribut reprsente ce que la variable va contenir comme nature de donne. Ici, le type pouvant tre de diverses natures, on laisse lutilisateur le rentrer.

Mais un attribut possde galement un type daccs. Cet accs correspond au comportement de la variable vis--vis dautres classes. Pour respecter la norme de la modlisation UML, rappelons que nous lavons reprsent sous forme de trois symboles : +, -, # respectivement pour un accs public, priv et protg. Le choix tant limit ces trois types daccs, il est demand par une liste droulante indiquant les seuls choix autoriss. Exemple :

Ensuite il est attribu la classe choisie par lutilisateur grce une liste des classes susceptibles de le recevoir ce qui permet lutilisateur de ne pas se faire derreur quant au propritaire. Illustration :

Nous avons vu comment crer un attribut et laffecter une classe, mais une classe est galement susceptible de comporter des mthodes. Cest ce que nous allons tudier maintenant.

II.1.3 Cration dune mthode

Une mthode peut tre vue comme une fonction, elle accepte donc des paramtres, ce qui va nous amener dcouper notre tude en deux sous-parties. Tout dabord, tout comme la cration dun attribut, son nom, et sa classe propritaire sont rentrs. Mais une mthode possde en plus un type de retour. Comme pour le type dun attribut, le type de retour dune mthode sera saisi par lutilisateur. Ensuite, chaque paramtre est rentr un par un. Un paramtre possde un type et un nom qui sont demands de la mme manire quun attribut pour accentuer le caractre agrable de la saisie. De la mme faon que pour un attribut, chaque mthode est cre indpendamment de la classe qui en est la propritaire. Cest une fois que la mthode est dfinie que lutilisateur va lattribuer une classe via un menu droulant.

Exemple :

Illustration :

Mthode

II.1.4 Cration de liens Nous arrivons llment le plus complexe de lapplication et le plus difficile de mise en uvre tant par la diversit que par le souci de clart. Cest ainsi que nous avons dcid de ne pas reprsenter certains liens comme la dpendance qui nest pas indispensable. Les autres types de liens comme lassociation, la composition, lagrgation ou encore lhritage sont disponibles et sont reprsents selon la normalisation UML. La notion de lien apporte galement celle de sens car un lien est toujours orient. Ce qui nous amne tudier de plus prs ces diffrents liens. Tout dabord, la relation dassociation sera modlise par une simple droite entre deux classes surmonte par son nom ainsi quun triangle indiquant le sens de celle-ci. Illustration :

Quant la composition et lagrgation, elles seront respectivement reprsentes par un trait se terminant par un losange plein et un trait se terminant par un losange vide.

Illustrations : - Compositions :

10

Dans le cas de lhritage une simple flche oriente vers la classe mre sera dessine. Illustration :

Dans les trois premiers cas, les cardinalits seront dites sur le lien et se dplaceront avec ceux-ci lors de la mise en forme manuelle. Lentre des cardinalits ne faisant lobjet daucun test, lutilisateur pourra afficher les cardinalits quil souhaite. Le lien hritage ne faisant tat daucune cardinalits, celles-ci ne sont pas sujettes une saisie utilisateur. Illustration dun modle UML complet : Sujet : gestion dun htel Nous allons voir un modle UML complet cest dire avec des classes comportant des attributs et des mthodes mais aussi diffrents liens.

11

II.2 Dplacement

Pour pouvoir organiser son modle de manire claire et lisible, lutilisateur aura la possibilit de dplacer les diffrentes classes cres en cliquant sur la classe intresse et en dplaant la souris. Bien entendu, les diffrents liens que possde la classe dplacer sorienteront automatiquement en fonction des mouvements de la classe. Dplacement dune classe :

Lapplication permettra galement de grer un modle dune taille assez consquente puisque le panneau graphique utilisable dpasse la taille de la fentre et lutilisateur pourra se mouvoir dans la zone de travail laide de barres de dfilements prsentes dans le bas et droite de la fentre.

Dplacement en utilisant les barres de dfilement :

12

II.3 Suppression

Lutilisateur pourra choisir de supprimer une certaine classe ou un certain lien tout en sachant que lorsquil supprimera une classe, tous les liens se rattachant cette classe seront supprims. Exemple : suppression dune classe :

Pour ce faire, suivant quun lien ou une classe doit tre supprim(e), une boite de dialogue apparatra contenant un menu droulant par le biais duquel lutilisateur pourra choisir la classe ou le lien supprimer. Cependant, en ce qui concerne la suppression dun lien, celui-ci est identifi par la slection des deux classes quil relie. Lorsquune classe ou un lien est retir(e), elle ou il napparat videmment plus dans le menu droulant.

13

II.4 Protection Nous avons prvu les cas o lutilisateur souhaiterait effectuer des actions impossibles ou dnues de sens. Par exemple, sil veut relier une mme classe par un lien, le programme le prviendra par une boite de dialogue de limpossibilit daccomplir cette action.

Exemple: interdiction de crer un lien entre une mme classe :

Par contre, lutilisateur a une entire libert sur le choix des cardinalits. En ce qui concerne les mthodes et les attributs, le programme ne lempchera pas de crer un champs (type, nom, retour) vide. Lorsque lutilisateur dcide de crer un nouveau modle (cliquant sur nouveau), un message apparatra lui demandant sil veut vraiment quitter le modle actuellement en cours dutilisation.

II.5 Sauvegarde / Restauration Lapplication donne la possibilit de sauvegarder le modle en passant par le menu fichier puis loption enregistrer ou enregistrer sous . Si le modle a t enregistr prcdemment, le fait de cliquer sur enregistrer enregistrera le programme sous le mme nom de fichier alors que laction enregistrer sous propose une boite de dialogue dans laquelle lutilisateur entre le nom de fichier voulu. En ce qui concerne la restauration, si lutilisateur souhaite charger un fichier pralablement sauvegard, il pourra cliquer sur charger et entrer le nom du fichier quil souhaite restaurer. Le fichier cre par la sauvegarde nest pas lisible avec un diteur de texte, il sert seulement la restauration, et sil est modifi, la restauration ne pourra pas tre faite.

14

III)

Limites et volutions possible de lapplication

Dans cette partie, les limites ainsi que les volutions possibles de notre application seront prsentes. On pourrait se demander pourquoi diffrencier ces deux catgories puisque chaque limite de lapplication peut tre galement considre comme une volution possible. En fait, les limites de lapplication sont constitues de dfauts prsents dans notre version de lapplication, alors que les volutions possibles nont pas encore eu dimplantation dans notre programme. III.1 Limites de lapplication

- En ce qui concerne la sauvegarde et la restauration dun modle UML : o Labsence de fentre de balayage de larborescence et de visualisation des fichiers implique que : - les fichiers sont sauvs et restaurs dans le rpertoire courant - lutilisateur doit se souvenir du nom de fichier du modeler restaurer. o Labsence de test concernant lcrasement dun fichier existant implique que lutilisateur doit faire attention au nom de fichier donn lors de la sauvegarde. - Il nexiste pas de possibilit de modifier un objet du modle. En effet, pour modifier un objet, lutilisateur doit supprimer cet objet et le recrer. Cette contrainte, qui peut savrer mineure lorsquil sagit de modifier lattribut dune classe peut ltre beaucoup moins lorsquil sagit de changer le nom ou laccs dune classe, puisque la suppression dune classe entrane automatique la suppression de tous les liens quelle possde. - La suppression des mthodes na pas t implmente - Sil est possible, comme indiqu dans la partie 2, de dplacer une classe avec la souris, cette technique introduit une faiblesse. En effet, le dplacement dune classe seffectuant par le coin haut/gauche de celle-ci, si lutilisateur la dplace lextrmit basse ou lextrmit droite du panneau graphique, et la laisse cet endroit, cest--dire lextrieur du panneau, il lui sera impossible de la rcuprer. Cette faiblesse est tout de mme pallie par le fait que le panneau graphique est beaucoup plus grand que la fentre elle-mme puisque ses dimensions sont de 3000 pixels par 3000. Ainsi, les chances quun modle stende jusqu un de ces bords sont faibles.

15

III.2

Evolutions possibles

Lditeur UML prsent est oprationnel. En effet il gre toutes les fonctions ncessaires llaboration dun modle. Cependant, il prsente quelques lacunes notamment au niveau des donnes, au niveau graphique, mais aussi au niveau de la simplicit dutilisation. Une meilleure gestion des donnes : Le programme prsent permet de crer et de supprimer les donnes laide de deux menus. Pour modifier une donne il faut donc la supprimer et la recrer. Une volution possible est la cration dun menu similaire aux deux prcdents qui permettrait de modifier toutes les donnes de la mme manire quune suppression. Il serait possible de modifier ainsi chaque partie du modle. Cette volution parat tout fait ralisable : au niveau de la programmation des diffrents objets UML, chaque donne possde des accesseurs en modification. De plus, le filtrage des donnes aurait pu tre mieux gr. Par exemple, en ce qui concerne les cardinalits lutilisateur est libre de rentrer nimporte quelle chane de caractre, ce qui pose des problmes laffichage si cette chane est trop longue.

III.2.1 Les amliorations graphiques Lapplication UML affiche lcran tous les objets crs de la mme couleur. Une volution simple consiste grer les couleurs : dessiner chaque objet du mme type de la mme couleur (ex : toutes les classes en rouge). Dun point de vue pratique, il est possible dajouter une barre doutils avec des raccourcis pour permettre lutilisateur daccder directement certaine partie du logiciel sans tre obliger daccder chaque fois au menu. Une autre volution est la gestion de la slection des objets lcran. Ainsi lorsque lutilisateur clique sur une classe, cette dernire changerait de couleur. Lvolution permettrait de rduire le temps de saisie de lutilisateur. Par exemple, lorsque lutilisateur voudrait crer un lien, il cliquerait sur licne cration de lien et ensuite sur les 2 classes entre lesquelles se trouve le lien. De plus, il faudrait aussi grer lagrandissement ou la rduction des classes. En effet, dans le projet les classes prennent la taille de la plus longue ligne. Ceci donnerait plus de libert lutilisateur pour agencer son modle. De mme la possibilit de dplacer les liens apporterait plus de lisibilit lapplication. En effet laffichage dun lien se fait entre les milieux de chaque classe. Un problme survient donc lorsque quune classe est relie 2 autres qui se trouvent du mme cot. Les cardinalits des deux liens se superposent.

16

Une autre volution graphique consisterait grer le clic droit pour faire apparatre un menu contextuel. On afficherait ainsi les oprations relatives llment sur lequel on a cliqu. La dernire volution graphique serait la possibilit de modifier directement sur le dessin les proprits de chaque proprit dun objet. On raccourcirait considrablement la saisie des donnes et on augmenterait la simplicit dutilisation.

III.2.2 Impression du modle La fonction principale dun diteur UML est de reprsenter un modle plus propre et plus clair quun dessin ralis la main. Limpression est donc une volution ncessaire lutilisation future du projet. En effet, lutilisateur ne trouvera pas le logiciel dun grand intrt sil ne peut pas par la suite imprimer le modle quil a ralis. De plus, limplmentation dun gestionnaire dimpression en java nest pas extrmement difficile mettre en place.

III.2.3 La gestion de plusieurs modles en mme temps Une autre volution consisterait grer plusieurs modles la fois dans le but de pouvoir exporter les lments de lun vers lautre. Ceci implique la cration dun menu dition avec lequel il serait possible de dupliquer des classes par exemple (copier coller). En pratique, au niveau des donnes, il suffirait dajouter une liste de modle au sein du programme. Mais cette volution na de sens que si lutilisateur peut passer dun modle lautre tout moment, via un menu affichant les diffrentes fentres ouvertes. De nombreuses volutions sont donc possibles pour ce projet. Elles sont plus ou moins intressantes et demandent un tant soit peu de travail. Avec un peu plus de temps, il aurait t possible de soccuper de la suppression des mthodes, de la modification des donnes ou de la gestion des couleurs sans grande difficult. Quant aux diffrentes amliorations graphiques ou la gestion multi-modles , elles demanderaient sans doute des tudes plus approfondies.

17

IV)

Laspect humain

Au long de cette partie, nous aborderons laspect humain de notre projet, cest dire tout ce qui concerne la gestion du planning, la gestion des diffrentes versions de chacun et la rpartition du travail au sein du groupe. Tous ces points ont t, un degr moindre, des problmes rsoudre. Nous verrons les choix pris en terme dorganisation pour palier ces problmes.

IV.1

Problmes de planning

Le respect du planning et des objectifs na pas t ais, en effet au dpart du projet, le groupe destin le raliser tait compos de six personnes mais un de nous ayant quitt lIUT et par la mme occasion le projet, lquipe se vu donc rduite cinq personnes. Au dpart, nous avions divis le groupe en trois sous-groupes de deux programmeurs pour avoir une meilleure productivit. Lorsque deux personnes travaillent ensembles, le travail se fait plus vite et mieux et il y a moins de conflits qua trois ou plus. Cette organisation a du tre remise en cause avec le dpart de notre collgue. Il a donc fallu rorganiser le travail au sein du groupe pour quune personne ne fasse pas le travail attribu au dpart deux personnes. Il a galement t difficile de reprendre le travail fait par la personne qui a quitt le groupe et de lintgrer lapplication. Nous avons ainsi pris un retard non ngligeable sur le planning. Ceci va nous amener parler des problmes de rassemblement des diffrentes versions du programme faites ou compltes par chacun.

IV.2

Problmes de versions

A certains moments de la conception de lapplication, il tait indispensable de mettre en commun les versions de chacun. Il fallait donc que chaque personne sache parfaitement dans quelles parties du programme elle avait ajout ou modifi du code, nous nous sommes donc fis la mmoire de chacun ou aux notes prises par le programmeur lorsquil a ajout ou modifi des lignes de codes ou des fichiers du programme. Ce projet tant notre premier projet, nous navions pas prvu ce problme, mais pour nos prochains projets, nous pourrions adopter lutilisation dun outil permettant de grer les diffrentes versions dune application comme le fait CVS vu cette anne dans le cours de Systme.

IV.3

Rpartition du travail

Voyons maintenant de quelle faon les taches ont t rparties au sein du groupe. Matthias sest occup de concevoir linterface graphique, en rsum tout le systme de menu destin a lutilisateur, ainsi que du dplacement des classes avec la souris. Il a aussi gr toutes les versions du programme, cest lui qui mettait en commun les parties de chacun.

18

Damien T sest consacr au systme de sauvegarde et de restauration des modles crs a laide de lapplication. Michal, Damien P et Matthieu se sont occup du dessin du modle lcran (Classes, liens) et de la reprsentation des donnes dans le programme cest--dire reprsenter en JAVA un modle UML. Cependant, il serait restrictif de sarrter cette description du travail, puisque chacun sest intress aux parties des autres, et quau final, mme si effectivement la programmation sest droule en grande partie selon cette rpartition, nous avons tous une bonne connaissance globale du programme. On peut surtout noter que lambiance tait bonne au sein du groupe, avec une entraide collective. Par exemple quand un de nous avait un problme concernant la partie quil avait raliser, il pouvait sans problmes demander conseil aux autres membres du groupe qui essayaient de lui donner une solution. En rsum, chacun de nous tait au service des autres, il ny avait pas de rivalit au sein du groupe.

Il est clair que tous les choix pris pour lorganisation du travail ne sont pas les meilleurs, mais cela nous a montr des problmes que lon ne connaissait pas en ralisant des projets individuellement. Une bonne organisation du travail est la cl de la russite dans un tel type de projet o plusieurs personnes doivent travailler ensemble.

19

CONCLUSION

Finalement, nous pensons avoir atteint les objectifs fixs, puisque notre application est oprationnelle et permet de crer un modle dans son ensemble, malgr la prsence de quelques lacunes, dont les principales sont limpossibilit de supprimer une mthode et de modifier un objet du modle.

Cependant, ce projet nous a apport chacun une exprience non ngligeable concernant le travail en groupe, puisque cela nous a amen rflchir des problmes que nous ne nous tions jamais poss lorsquil sagissait de conduire un dveloppement individuel. Le travail en groupe constitue certainement une composante essentielle de la vie professionnelle, et ce projet nous permettra sans aucun doute daborder le monde du travail de manire plus sereine.

De plus, nous pensons que notre projet est viable et pourrait servir de base un dveloppement ultrieur afin den complter les possibilits. En effet, la reprise de cette application par dautres dveloppeurs serait certainement la plus grande rcompense notre travail.

20

TABLE DES MATIERES

INTRODUCTION 2

I - PRESENTATION DU SUJET
I.1 - La modlisation U.M.L I.2 - Pourquoi un gnrateur de modles UML ? I.3 - Choix de conception

3
3 5 5

II - PRESENTATION DES FONCTIONNALITES DE LAPPLICATION

II.1 Cration des diffrents objets II.1.1 Cration dune classe II.1.2 Cration dun attribut II.1.3 Cration dune mthode II.1.4 Cration de liens II.2 Dplacement II.3 Suppression II.4 Protection II.5 Sauvegarde / Restauration

6
6 6 7 9 10 12 13 14 14

III LIMITES ET EVOLUTION POSSIBLES DE LAPPLICATION

III.1 III.2 Limites de lapplication Evolutions possibles III.2.1 Les amliorations graphiques III.2.2 Impression du modle III.2.3 La gestion de plusieurs modles en mme temps

15
15 16 16 17 17

IV ASPECT HUMAIN
IV.1 IV.2 IV.3 Problmes de planning Problmes de versions Rpartition du travail

18
18 18 18

CONCLUSION

21

21