Memoire Online - Génération automatique du code java à partir d'un modèle de classe UML

A l'issue de ce travail, nous remercions, en premier lieu, le bon Dieu de
nous avoir donné la force et le courage de le mener à terme.

Nous tenons, également, à exprimer notre sincère reconnaissance et
notre profonde gratitude à tous ceux qui ont contribué de près ou de
loin à la réalisation de ce mémoire, notamment notre promoteur
Dr : Amirat dont les conseils et orientations nous ont été
précieusement utiles.

Liste des figures

Chapitre 1
1.1		Encapsulation	5
1.2		Héritage	5
1.3		Polymorphisme	6
1.4		Classe et Objet	7
1.5		Description D'UML 2.0	10
1.6		Exemple de document XML	11
1.7		Diagramme de classes UML	12
1.8		Transcription au format XMI du diagramme de figure 1.6	12
		Chapitre 2
2.1		Notation des paquetages	16
2.2		Notation des interfaces	16
2.3		Classes abstraites	16
2.4		Classes non abstraites	18
2.5		Modélisation d'une association	19
2.6		Association binaire	19
2.7		Association n'aire.	19
2.8		Navigabilité	20
2.9-a		Un diagramme représentant l'association entre l'échiquier et la case qui le compose	21
2.9-b		Un diagramme équivalant utilisant l'association qualifiée	21
2.10		Exemple de classe-association	22
2.11		Auto-association sur classe-association.	23
2.12		Relation d'agrégation	23
2.13		Relation De composition	24
Liste des figures				x
2 .14	Partie du règne animal décrit avec l'héritage multiple			25
2.15	Relation de dépendance relation de dépendance			25
2.16	Implémentation des interfaces			26
2 .17	Commentaires dans le diagramme de classe UML			26
	Chapitre 3
3.1	Génération de code avec le mapping direct			30
3.2	Génération de code avec Un modèle Intermédiaire			31
	Chapitre 4
4 .1	Page d'accueil de StarUML.			34
4.2	Processus de génération d'un fichier au format .java à partir des modèles de classe			35
4.3	Etape 1 pour Exporter le fichier .jar			36
4.4	Etape 2 pour Exporter le fichier .jar			37
4.5	Etape 3 pour Exporter le fichier .jar			37
4.6	L'interface de Clickteam Install Creator Pro			38
4.7	Etapes d'installation de GenJava			39
4.8	Hiérarchie de Workspace			40
4.9	La page d'accueil de GenJava			41
4.10	Page de travaille de GenJava			41
4.11	Création de modèle de Classe			42
4.12	Sérialisation de modèle (Export vers XMI)			42
4.13	Ouvrir GenJava			43
4.14	Ouvrir le fichier XMI			43
4.15	Résultat de génération			44

Table des tables

Introduction

Au cours des 35 dernières années, les concepteurs de matériel informatique sont passés de machines de la taille d'un hangar à des ordinateurs portables légers basés sur de minuscules microprocesseurs. Au cours des mêmes années, les développeurs des logiciels sont passés de l'écriture de programmes en assembleur et en COBOL à l'écriture de programmes encore plus grands en C et C++. On pourra parler de progrès (bien que cela soit discutable), mais il est clair que le monde du logiciel ne progresse pas aussi vite que celui du matériel. Qu'ont donc les développeurs de matériel que les développeurs de logiciels n'ont pas?

La réponse est donnée par les composants. Si les ingénieurs en matériel électronique devaient partir d'un tas de sable à chaque fois qu'ils conçoivent un nouveau dispositif, si leur première étape devait toujours consister à extraire le silicium pour fabriquer des circuits intégrés, ils ne progresseraient pas bien vite. Or, un concepteur de matériel construit toujours un système à partir de composants préparés, chacun chargé d'une fonction particulière et fournissant un ensemble de services à travers des interfaces définies. La tâche des concepteurs de matériel est considérablement simplifiée par le travail de leurs prédécesseurs.

La réutilisation est aussi une voie vers la création de meilleurs logiciels. Aujourd'hui encore, les développeurs de logiciels en sont toujours à partir d'une certaine forme de sable et à suivre les mêmes étapes que les centaines de programmeurs qui les ont précédés. Le résultat est souvent excellent, mais il pourrait être amélioré. La création de nouvelles applications à partir de composants existants, déjà testés, a toutes chances de produire un code plus fiable. De plus, elle peut se révéler nettement plus rapide et plus économique, ce qui n'est pas moins important.

Le développement oriente objet de logiciel a été largement accepte pour ses propriété de flexibilité transition entre la phase de développement et la possibilité de la réutilisation. Dans la plupart de l'approche oriente objet, y compris UML (Unified Modeling Languages) [booch2001]. Des différentes spécifications bases sur des multiples modèles sont obtenues pour décrire les aspects différents d'un système. Cependant, l'industrie du logiciel ne peut pas fournir encore de solutions satisfaisantes pour un combler le vide entre langage de modélisation et de programmation.

UML est actuellement le langage de modélisation le plu rependu .UML peut être utilise dans tout genre de projet logiciel et il est accepté par l'industrie comme le langage standard pour l'analyse et la conception de logiciel.

Ce travail décrire une stratégie pour génèrera le code(Java) à partir d'un modèle de classe base sur modèle XMI exporte à l'aide de l'outil de modélisation open source StarUML [StarUML].

XMI (XML Metadata Interchange) est un standard pour l'échange d'informations de métadonnées UML basé sur XML. [XMI 2003]

En suivant cette stratégie, nous avant développé un outil qui génère automatiquement le code source Java à partir d'un modèle de Classe.

- Facilite le développement de logiciel à partir d'une notation UML (modèle de Classe).

- Création automatique des classes, attributs, méthodes, Interfaces ...etc....

- En plus, Ce type de projet n'a jamais abordé au niveau de notre département.

Cette mémoire est organisée en 4 chapitres, en plus d'une introduction et d'une conclusion générale. Une introduction au développement Oriente Objet est présentée dans le chapitre 1 ou on y trouve aussi quelques notions sur la méthode UML et la spécification XMI. Le chapitre 2 donne une vue générale sur le diagramme de classe et ces composants, La génération automatique de code ainsi que l'idée principale et l'approche utilisée sont décrie dans le chapitre 3. Le chapitre 4 présente l'architecture de l'outil proposée.

Chapitre1

Développement oriente objet

1.1 Introduction

Un système informatique est un système complexe, qui répond à des besoins issus du <<monde réel » et non pas des contraintes des ordinateurs sur lesquels il sera réalisé [Sommerville2001]. Le tout est de faire le pont entre les deux : exprimer une << modélisation du monde réel >> en termes de langage de programmation fatalement lié à l'ordinateur. Cette dichotomie a de tout temps existé pour l'informatique. Si on tient compte du très jeune âge de cette discipline relativement à d'autres domaines scientifiques, il paraît évident que les techniques les plus récentes sont les plus adéquates. Mais de quoi s'agit-il au juste ? De la modélisation du <<monde réel » à l'aide des techniques orientées-objet et de la programmation qui porte le même nom. Mais les deux ne sont pas indissociables, comme le prouvent des environnements très évolués, complexes, performants et fiables tels que X/Windows, Motif et DCE (tous disponible pour les plates-formes les plus courantes) conçus orienté-objet et réalisés en C [Lemesle2000].

1.2 Paradigme Oriente Objet

On classe souvent les langages de programmation en trois familles : - impératifs (comme les assembleurs, C, Perl, ...) ;

En fait, cette classification doit plus s'entendre comme des philosophies différentes dans l'approche de la programmation et les langages implémentent même souvent plusieurs de ces aspects. Ces trois philosophies sont complémentaires en fonction des situations.

permettre à une entreprise de concevoir et développer un logiciel sur une durée de plusieurs années, il est nécessaire de structurer les différentes parties du logiciel de manier efficace. Pour cela, des règles précises de programmation sont établies, afin que les différents groupes de personnes intervenant sur un même logiciel puissent échanger leurs informations. En pratique, on a constaté que malgré l'instauration de règles, l'adaptation ou la réutilisation d'une partie programme nécessitait généralement une modification très importante d'une grande partie du code.

La programmation orientée objet est donc apparue avec, pour objectifs principaux :

- Comprendre l'organisation de grands projets informatiques autour d'entités précisément structurés, mélange des données et des fonctions (les objets) facilitant la modélisation de concepts sophistiqués :

- Améliorer la sureté des logiciels en proposant un mécanisme simple et flexible des données sensibles de chaque objet en ne les rendant accessibles que par le truchement de certaines fonctions associées à l'objet (encapsulation) afin que celles-ci ne soient pas accessibles à un programmeur inattentif ou malveillant.

- Simplifier la réutilisation de code en permettant l'extensibilité des objets existants (héritage) qui peuvent alors être manipulés avec les mêmes fonctions (polymorphisme).

La Programmation Orientée Objet est dirigée par 3 fondamentaux qu'il convient de toujours garder à l'esprit : encapsulation, héritage et polymorphisme.

1.2.1 Encapsulation

L'encapsulation introduit une nouvelle manière de gérer des données. Il ne s'agit plus de déclarer des données générales puis un ensemble de procédures et fonctions destinées à les gérer de manière séparée, mais bien de réunir le tout sous le couvert d'une seule et même entité [Dev].

Ce concept se cache également un autre élément à prendre en compte : pouvoir masquer aux yeux d'un programmeur extérieur tous procédures et fonctions destinées à la gestion interne de l'objet, auxquelles le programmeur final n'aura pas à avoir accès. Comme il montre la figure 1.1.

1.2.2 Héritage

L'héritage est un principe de la programmation orientée Objet], permettant entre autres la réutilisabilité et l'adaptabilité des objets. Elle se nomme ainsi car le principe est en quelque sorte le même que celui d'un arbre généalogique. Ce principe est basé sur des classes dont les « filles » héritent des caractéristiques de leur(s) « mère(s) ». Chaque classe possède des attributs et/ou des méthodes qui lui sont propres. Lorsqu'une classe fille hérite d'une classe mère, elle peut alors utiliser ses attributs et ses méthodes [Dev]. Et la figure 1.2 montre la notation UML et Java de ce concept.


class Point { public void initialise (int abs, int ord) { x = abs ;y = ord ; } public void deplace (int dx, int dy) { x += dx ; y += dy ; } public void affiche (){ System.out.println ("Je suis en " + x + " " + y) ; } private int x, y ;}	class Pointcol extends Point { public void colore (bytecouleur){ this.couleur = couleur ; } private byte couleur ; }

1.2.3 Polymorphisme

Le polymorphisme, conséquence directe de l'héritage, permet à un même message, dont l'existence est prévue dans une superclasse, de s'éxécuter différemment, selon que l'objet qui le reçoit est d'une sous-classe ou d'une autre. Cela permet à l'objet responsable de l'envoi du message de ne pas avoir à se préoccuper dans son code de la nature ultime de l'objet qui le reçoit et donc de la façon dont il l'exécutera.

1.3 Définitions

Définissons maintenant d'une façon formelle les concepts de ce modèle. 1.3.1 Objet

Un objet est une instance d'une classe. C'est une entité discrète dotée d'une identité, d'un état et d'un comportement que l'on peut invoquer. Les objets sont des éléments individuels d'un système en cours d'exécution.

Par exemple, si l'on considère qu'Homme (au sens être humain) est un concept abstrait, on peut dire que la personne Djamel est une instance d'Homme. Si Homme était une classe, Djamel en serait une instance : un objet.

1.3.2 Classe

Une classe [Laurent] est un concept abstrait représentant des éléments variés comme :

- des éléments abstraits (ex : des commandes de marchandises ou services), - des composants d'une application (ex : les boutons des boîtes de dialogue), - des structures informatiques (ex : des tables de hachage),

Une classe est la description formelle d'un ensemble d'objets ayant une sémantique et des caractéristiques communes.

1.4 UML langage de modélisation OO

La description de la programmation par objets a fait ressortir l'étendue du travail conceptuel nécessaire : définition des classes, de leurs relations, des attributs et méthodes, des interfaces etc.

Pour programmer une application, il ne convient pas de se lancer tête baissée dans l'écriture du code: il faut d'abord organiser ses idées, les documenter, puis organiser la réalisation en définissant les modules et étapes de la réalisation. C'est cette démarche antérieure à l'écriture que l'on appelle modélisation ; son produit est un modèle.

Les spécifications fournies par la maîtrise d'ouvrage en programmation impérative étaient souvent floues : les articulations conceptuelles (structures de données, algorithmes de traitement) s'exprimant dans le vocabulaire de l'informatique, le modèle devait souvent être élaboré par Celle-ci. L'approche objet permet en principe à la maîtrise d'ouvrage de s'exprimer de façon précise selon un vocabulaire qui, tout en transcrivant les besoins du métier, pourra être immédiatement compris par les informaticiens. En principe seulement, car la modélisation demande aux maîtrises d'ouvrage une compétence et un professionnalisme qui ne sont pas aujourd'hui répandus [Pascal 2006].

1.4.1 Historique

Les méthodes utilisées dans les années 1980 pour organiser la programmation impérative (notamment Merise) étaient fondées sur la modélisation séparée des données et des traitements. Lorsque la programmation par objets prend de l'importance au début des années 1990, la nécessité d'une méthode qui lui soit adaptée devient évidente. Plus de cinquante méthodes apparaissent entre 1990 et 1995 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE, etc.) mais aucune ne parvient à s'imposer. En 1994, le consensus se fait autour de trois méthodes :

- OMT de James Rumbaugh (General Electric) fournit une représentation graphique des aspects statique, dynamique et fonctionnel d'un système ;

Chaque méthode avait ses avantages et ses partisans. Le nombre de méthodes en compétition s'était réduit, mais le risque d'un éclatement subsistait : la profession pouvait se diviser entre ces trois méthodes, créant autant de continents intellectuels qui auraient du mal à communiquer.

Événement considérable et presque miraculeux, les trois gourous qui régnaient chacun sur l'une des trois méthodes se mirent d'accord pour définir une méthode commune qui fédérerait leurs apports respectifs (on les surnomme depuis « the Amigos »). UML (Unified Modeling Language) est né de cet effort de convergence. L'adjectif unified est là pour marquer qu'UML unifie, et donc remplace.

En fait, et comme son nom l'indique, UML n'a pas l'ambition d'être exactement une méthode : c'est un langage. L'unification a progressé par étapes. En 1995, Booch et Rumbaugh (et quelques autres) se sont mis d'accord pour construire une méthode unifiée, Unified Method 0.8 ; en 1996, Jacobson les a rejoints pour produire UML 0.9 (notez le remplacement du mot méthode par le mot langage, plus modeste). Les acteurs les plus importants dans le monde du logiciel s'associent alors à l'effort (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) et UML 1.0 est soumis à l'OMG. L'OMG adopte en novembre 1997 UML 1.1 comme langage de modélisation des systèmes d'information à objets. La version d'UML en cours en 2008 est UML 2.1.1 et les travaux d'amélioration se poursuivent.

UML est donc non seulement un outil intéressant mais une norme qui s'impose en technologie à objets et à laquelle se sont rangés tous les grands acteurs du domaine, acteurs qui ont d'ailleurs contribué à son élaboration.

1.4.2 Description d'UML 2.0

UML est un métalangage car il fournit les éléments permettant de construire le modèle qui, lui, sera le langage du projet.

UML 2.0 [Audibert 2009] comporte ainsi treize types de diagrammes représentant autant de vues distinctes pour représenter des concepts particuliers du système d'information. Ils se répartissent en deux grands groupes :

1.4.2.1 Diagrammes structurels

1.4.2.2 Diagrammes comportementaux

1.5 Document XMI

1.5.1 Historique

Jon Bosak, de Sun Microsystems, compose en 1996 un groupe de travail destiné à proposer une version simplifiée de SGML1, un langage de description de documents structurés. De cette entreprise naît XML (Extensible Markup Language). Standardisé en 1998 par le World Wide Web Consortium, XML est aujourd'hui considéré comme le format de référence de la publication et des échanges, et joue notamment un rôle crucial dans la diffusion de documents sur Internet.

1.5.2 Concepts de base

Un fichier XML [Timothy 2002]ne tient pas compte de la mise en forme, mais seulement du contenu. Un système de balises permet de décrire les éléments de structure du document, ainsi que les relations entre ces éléments. Par exemple on peut, comme à la figure 1.4, décrire l'état civil d'une personne.

Chaque balise peut disposer d'un ou plusieurs attributs. Une balise n'a pas de contenu textuel, on peut simplifier l'écriture <Balise> </Balise> en <Balise/> [W3C].

1.5.3 Le standard XMI

1.5.3.1 Principe de fonctionnement

L'extension XMI (XML Métadata Interchange) [XMI2003] propose un format standard permettant d'exprimer les concepts de la modélisation objet. Pour transcrire les structures de graphe, très répandues dans ce domaine, on a recours à un mécanisme d'identifiants et de références à ces identifiants (car un document XML a les caractéristiques d'un arbre). Ainsi, il est possible d'encoder un modèle UML dans un fichier au format XML [OMG]. Les figures 1.7 et 1.8 présentent l'exemple d'un diagramme de classes élémentaire comportant deux classes et une association, puis sa transcription au format XMI.

1.5.3.2 Le format XMI

Si le format XMI constitue une norme de l'Object Management Group, chaque outil de modélisation UML en fait une interprétation personnelle. Ainsi, certains détails varient (le nom des balises, le choix de placer une information comme attribut ou comme contenu d'un noeud), rendant impossible à l'heure actuelle l'échange de fichiers XMI entre deux outils différents [XML].

1.5.3.4 Structure générale d'un document

La racine de tout document est une balise XMI, ayant comme attributs la version du standard XMI utilisé, ainsi que la date de création du fichier. À l'intérieur de cette balise XMI, on trouve une balise XMI.header, permettant d'identifier le modèle UML, et une balise XMI.content. Cette dernière contient principalement une balise Diagram renfermant toutes les informations liées à l'interface graphique (position des symboles, polices utilisées...), et une balise Model concernant le modèle UML en luimême. C'est au sein de cette balise Model que sont transcrits les différents diagrammes UML[XML].

1.5.3.5 Représentation des diagrammes de classes en XMI

Les diagrammes de classes sont représentés par un ensemble de balises Class (contenant des noeuds Attribute et des noeuds Operation) et un ensemble de balises Association. Une balise Association renferme un couple de balises AssociationEnd. Chaque balise AssociationEnd désigne une extrémité d'association, et contient un AssociationEnd.participant faisant référence à la classe adéquate. Éventuellement, une balise AssociationEnd.multiplicity permet de préciser la multiplicité correspondante. L'attribut aggregation de la balise AssociationEnd sert à spécifier à quelle catégorie appartient l'extrémité d'association : composition ('composition'), agrégation ('aggregate') ou simple association ('none').

La notion de classe-association est exprimée au moyen de balises AssociationClass, qui intègrent à la fois les concepts des classes et ceux des associations.

Les généralisations sont représentées par des balises Generalization, à l'intérieur desquelles une balise Generalization.child fait référence à la sous-classe, alors qu'une balise Generalization.parent référence la super-classe[XML].

1.6 Conclusion

En informatique, l'approche orientée objet est largement adoptée, tout simplement parce qu'elle a démontré son efficacité lors de la construction de systèmes dans les domaines métier les plus divers et qu'elle englobe toutes les dimensions et tous les degrés de complexité. De plus, la plupart des langages, des systèmes d'exploitation et des outils modernes sont au moins partiellement orientés objet, ce qui incite d'autant plus à voir les choses en termes d'objets. Le développement orienté objet fournit la base conceptuelle de l'assemblage de systèmes à partir de composants qui utilisent des technologies comme javabeans.

Chapitre2

Diagramme de Classe

2.1 Introduction

Le diagramme de classes constitue un élément très important de la modélisation : il permet de définir quelles seront les composantes du système final : il ne permet en revanche pas de définir le nombre et l'état des instances individuelles. Néanmoins, on constate souvent qu'un diagramme de classes proprement réalisé permet de structurer le travail de développement de manière très efficace; il permet aussi, dans le cas de travaux réalisés en groupe (ce qui est pratiquement toujours le cas dans les milieux industriels), de séparer les composantes de manière à pouvoir répartir le travail de développement entre les membres du groupe. Enfin, il permet de construire le système de manière correcte.

2.2 Les paquetages

Les paquetages permettent typiquement de définir des sous-systèmes. Un soussystème est formé d'un ensemble de classes ayant entre elles une certaine relation logique.

Un paquetage fait l'objet d'une réalisation largement indépendante, et peut être confiée à un groupe, ou à un individu n'ayant pas un contact étroit avec les responsables d'autres paquetages.

2.3 Les interfaces

Les interfaces représentent l'élément le plus abstrait du diagramme de classes.

2.4 Classes

2.4.1 Classes abstraites

Une classe abstraite ne peut donc pas être utilisée pour fabriquer des instances d'objets; elle sert uniquement de modèle, que l'on pourra utiliser pour créer des classes plus spécialisées par dérivation (héritage).

2.4.2 Classes non abstraites

- la première partie contient le nom de la classe, - la seconde contient les attributs de la classe,

2.4.3 Les attributs

Pour définir un attribut[Laurent] , il faut préciser son nom suivi du caractère « : » et du type de l'attribut.

Le modificateur d'accès de l'attribut doit précéder le nom et peut prendre les valeurs suivantes :

Les attributs privés et protégés ne sont accessibles qu'à travers des méthodes publiques (getters et setters).

2.4.4 Les méthodes

Les paramètres de la méthode peuvent être précisés en les indiquant entre les parenthèses sous la forme nom : type.

Si la méthode renvoie une valeur son type doit être précisé après un signe « : ». Exemple :

Une classe voiture : aurait pour caractéristiques, (CHAMPS ou ATTRIBUES), ses dimensions, sa couleur, sa puissance,..., Pour modes de fonctionnement (METODES) des actions telles que démarrer_moteur (), couper- moteur (), ...,

2.5 Relations entre classes

2.5.1 Relation d'association

Une association [Laurent] est une relation entre deux classes (association binaire) ou plus (association n-aire), qui décrit les connexions structurelles entre leurs instances. Une association indique donc qu'il peut y avoir des liens entre des instances des classes associées.

2.5.2 Relation d'Association binaire et n'aire

2.5.2 .1 Relation d'Association binaire

Une association [Laurent] binaire est matérialisée par un trait plein entre les classes associées. Elle peut être ornée d'un nom, avec éventuellement une précision du sens de lecture ( ou ) Quand les deux extrémités de l'association pointent vers la même classe, l'association est dite réflexive.

Une association n'aire lie plus de deux classes, La ligne pointillée d'une classeassociation peut être reliée au losange par une ligne discontinue pour représenter une association n'aire dotée d'attributs, d'opérations ou d'associations. On représente une association n'aire par un grand losange avec un chemin partant vers chaque classe participante, Le nom de l'association apparaît à proximité du losange.

2.5.3 Multiplicité

La multiplicité [Pierre 1997] associée à une terminaison d'association, d'agrégation ou de composition déclare le nombre d'objets susceptibles d'occuper la position définie par la terminaison d'association. Et le tableau 2.3 résume les multiplicités les plus courantes :

Dans une association binaire la multiplicité sur la terminaison cible contraint le nombre d'objets de la classe cible pouvant être associés à un seul objet donné de la classe source. Dans une association n'aire, la multiplicité apparaissant sur le lien de chaque classe s'applique sur une instance de chacune des classes,

Exemple : Si on prend une association ternaire entre les classes (A, B, C), la multiplicité de la terminaison C indique le nombre d'objets C qui peuvent apparaître dans l'association avec une paire particulière d'objets A et B.

2.5.4 Navigabilité

La navigabilité [Pierre 1997] indique s'il est possible de traverser une association. On représente graphiquement la navigabilité par une flèche du côté de la terminaison navigable et on empêche la navigabilité par une croix du côté de la terminaison non navigable. Par défaut, une association est navigable dans les deux sens.

commande. Inversement, la terminaison du côté de la classe Produit est navigable: chaque objet commande contient une liste de produits.

2.5.5 Qualification

Généralement, une classe peut être décomposée en sous-classes ou posséder plusieurs propriétés. Une telle classe rassemble un ensemble d'éléments (d'objets). Quand une classe est liée à une autre classe par une association, il est parfois préférable de restreindre la portée de l'association à quelques éléments ciblés (comme un ou plusieurs attributs) de la classe. Ces éléments ciblés sont appelés un qualificatif. Un qualificatif permet donc de sélectionner un ou des objets dans le jeu des objets d'un objet (appelé objet qualifié) relié par une association à un autre objet. L'objet sélectionné par la valeur du qualificatif est appelé objet cible. L'association est appelée association qualifiée. Un qualificatif agit toujours sur une association dont la multiplicité est plusieurs (avant que l'association ne soit qualifiée) du côté cible.

Un objet qualifié et une valeur de qualificatif génèrent un objet cible lié unique. En considérant un objet qualifié, chaque valeur de qualificatif désigne un objet cible unique.

Figure 2.9 a - Un diagramme représentant l'association entre l'échiquier et la
case qui le compose.

- Inversement, une instance de la classe Case est en association avec une instance unique du triplet {Echiquier, rangée, colonne}.

2.5.6 Classe-association

2.5.6.1 Définition et représentation

Une classe-association[Pierre 1997] possède les caractéristiques des associations et des classes: elle se connecte à deux ou plusieurs classes et possède également des attributs et des opérations. Une classe-association est caractérisée par un trait discontinu entre la classe et l'association qu'elle représente.

L'association Emploie entre une société et une personne possède comme propriétés le salaire et la date d'embauche. En effet, ces deux propriétés n'appartiennent ni à la société, qui peut employer plusieurs personnes, ni aux personnes, qui peuvent avoir plusieurs emplois. Il s'agit donc bien de propriétés de l'association Emploie. Les associations ne pouvant posséder de propriété, il faut introduire un nouveau concept pour modéliser cette situation: celui de classeassociation.

2.5.6.2 Auto-association sur classe-association

Si nous voulions ajouter une association Supérieur de dans le diagramme 2.11 pour préciser qu'une personne est le supérieur d'une autre personne. On ne peut simplement ajouter une association réflexive sur la classe Personne. En effet, une personne n'est pas le supérieur d'une autre dans l'absolu. Une personne est, en tant

qu'employé d'une entreprise donné, le supérieur d'une autre personne dans le cadre de son emploi pour une entreprise donné (généralement, mais pas nécessairement, la même). Il s'agit donc d'une association réflexive, non pas sur la classe Personne mais sur la classe-association Emploie.

2.5.7 Agrégation et composition

Une association simple entre deux classes représente une relation structurelle entre pairs, c'est à dire entre deux classes de même niveau conceptuel : aucune des deux n'est plus importante que l'autre. Lorsque l'on souhaite modéliser une relation tout/partie où une classe constitue un élément plus grand (tout) composé d'éléments plus petit (partie), il faut utiliser une agrégation ou composition.

2.5.7 .1 Relation d'Agrégation

Une agrégation [XMI2003] est une association qui représente une relation d'inclusion structurelle ou comportementale d'un élément dans un ensemble. Graphiquement, on ajoute un losange vide ( ) du côté de l'agrégat. Contrairement à une association simple, l'agrégation est transitive.

La signification de cette forme simple d'agrégation est uniquement conceptuelle. Elle ne contraint pas la navigabilité ou les multiplicités de l'association. Elle n'entraîne pas non plus de contrainte sur la durée de vie des parties par rapport au tout.

2.5.7.2 Relation Composition

La composition, également appelée agrégation composite, décrit une contenance structurelle entre instances. Ainsi, la destruction de l'objet composite implique la destruction de ses composants. Une instance de la partie appartient toujours à au plus une instance de l'élément composite: la multiplicité du côté composite ne doit pas être supérieure à 1 (1 ou 0..1). Graphiquement, on ajoute un losange plein ( ) du côté de l'agrégat

2.5.8 Relation de Généralisation

La généralisation [Pierre 1997] décrit une relation entre une classe générale (classe de base ou classe parent) et une classe spécialisée (sous-classe). La classe spécialisée est intégralement cohérente avec la classe de base, mais comporte des informations supplémentaires (attributs, opérations, associations). Un objet de la classe spécialisée peut être utilisé partout où un objet de la classe de base est autorisé.

Dans le langage UML, ainsi que dans la plupart des langages objet, cette relation de généralisation se traduit par le concept d'héritage. On parle également de relation d'héritage. Ainsi, l'héritage permet la classification des objets. Le symbole utilisé pour la relation d'héritage ou de généralisation est une flèche avec un trait plein dont la pointe est un triangle fermé désignant le cas le plus général.

- La classe enfant possède toutes les caractéristiques de ses classes parents, mais elle ne peut accéder aux caractéristiques privées de cette dernière.

- Une classe enfant peut redéfinir (même signature) une ou plusieurs méthodes de la classe parent.

- Toutes les associations de la classe parent s'appliquent aux classes dérivées.

- Une instance d'une classe peut être utilisée partout où une instance de sa classe parent est attendue.

2.5.9 Relation de Dépendance

Une dépendance est une relation unidirectionnelle exprimant une dépendance sémantique entre des éléments du modèle. Elle est représentée par un trait discontinu orienté. Elle indique que la modification de la cible peut impliquer une modification de la source. La dépendance est souvent stéréotypée pour mieux expliciter le lien sémantique entre les éléments du modèle.

On utilise souvent une dépendance quand une classe en utilise une autre comme argument dans la signature d'une opération.

Le diagramme de la figure 2.16 montre que la classe Confrontation utilise la classe Stratégie car la classe Confrontation possède une méthode confrontée dont deux paramètres sont du type Stratégie. Si la classe Stratégie, notamment son interface, change, alors des modifications devront également être apportées à la classe Confrontation.

2.5.10 Relation d'Implémentation

Une classe peut implémenter une interface; elle peut aussi en implémenter plusieurs. En Notation UML, cette relation est dénotée par une flèche en traitiez.

2.5.11 Commentaires

UML permet d'ajouter des notes (commentaires) à la représentation graphique. Les Annotations peuvent être nécessaires pour préciser les intentions du concepteur.

Les annotations peuvent être ou non traduites en commentaires dans le langage de projection: Tout dépend de l'outil utilisé.

2.6 Conclusion

Le diagramme de classe est une vue statique car on ne tient pas compte du facteur temporel dans le comportement du système. Le diagramme de classes modélise les concepts du domaine d'application ainsi que les concepts internes créés de toutes pièces dans le cadre de l'implémentation d'une application. Chaque langage de Programmation Orienté Objets donne un moyen spécifique d'implémenter le paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais le diagramme de classes permet de modéliser les classes du système et leurs relations indépendamment d'un langage de programmation particulier.

Les principaux éléments de cette vue statique sont les classes et leurs relations: association, généralisation et plusieurs types de dépendances, telles que la réalisation et l'utilisation.

Chapitre3

Génération de code

3.1 Introduction

La génération d'une application à partir de son modèle par génération de code est un processus en deux étapes. La première étape est une transformation du modèle en langage de programmation de haut niveau(C, C++, java, etc.).

La seconde étape consiste en la compilation de ce programme en binaires exécutable qui font l'application par utilisation d'un compilateur support du langage ciblé lors de la première étape.

Les types de générateurs sont multiples, selon les besoins, mais la fonctionnalité principale reste la même : produire du code automatique, et soulager le développeur de certaines lourdeurs de mise en place.

Le code obtenu peut être aussi bien du code source prêt à être modifier ou compilé, du byte-code pour une machine virtuelle, un exécutable...à partir du moment où le code produit est correct, rien n'empêche d'ajouter une étape où il sera compilé.

Un des types de générateur ceux qui prennent une définition abstraite(en UML, par exemple) et construisent un code complet, dans l'idéal exploitable directement.

3.2 Définition

Parmi les objectifs que la modélisation permet d'atteindre, la précision la structure ou le comportement d'un system et la fourniture d'un canevas qui guide la construction de ce dernier.

Même si UML n'est pas un langage de programmation visuelle, ses modèles peuvent être directement traduire dans les différents langages de programmation .Cela signifie qu'il est possible de traduire un modèle UML dans un langage de programmation tel qui Java, C++ ou Visual Basic, voire de l'exprimer à l'aide de tables dans des bases de données relationnelles ou dans la mémoire

persistante d'une base de données orientée objet. Avec UML, les éléments qu'il est préférable d'exprimer graphiquement sont traduits dans le langage de programmation [Booch 2001].

Cette correspondance permet d'appliquer l'ingénierie vers l'aval, c'est-à-dire la génération de code à partir d'un modèle UML vers un langage de programmation.

3.3 Objectifs

La génération du code exécutable à partir des modèles abstraits qui sont les diagrammes d'UML, a pour principaux objectifs les points suivants :

- réduire le temps de développement, - éviter les erreurs de programmation, - optimisation globale est faite.

Idéalement le processus de génération du code est automatique, peut être exécuté dans le processus de développement et autant de fois qu'exigé.

3.4 Etapes de génération de code

3.4.1 Génération structurelle de code

Un modèle ou une partie du modèle est traduit à des unités structurelles dans un langage de programmation tel que classes, composants, paquets, etc.

3.4.2 Génération comportementale du code

Un modèle ou une partie du modèle est traduit à des unités comportementales dans un langage de programmation tel que fonctions, méthodes, services

3.4.3 Génération de la spécification

Un modèle ou une partie du modèle est traduit à une spécification pour être utilise avec un outil d'analyse pour s'établir si le modèle endure quelque besoins fonctionnels ou non fonctionnelles.

3.5 Approches de la génération de code

- Un mapping direct des modèles UML vers un langage de programmation ou une plateforme spécifiée.

- Utilisation d'un ou plusieurs langages intermédiaires et de modèle de transformation, Comme XMI. Ces langages intermédiaires

- peuvent être visibles pour l'utilisateur ou utilisés intérieurement par le générateur de code.

3.6 Conclusion

A partir de ce chapitre on conclue quand peut générer toutes les classes d'un même modèle type en même temps et ensuite nous continuerons la génération. Plus spécialement, dans un premier temps nous Allons générer toutes les classes représentant un Etat, car il suffit dans ce cas d'aller rechercher les tags dont le propriété " UML:Class xmi.id" (dans le fichier xmi qui export à partir de l'outil « StarUML 5.0.2»).

Chaque classe possède des propriétés (XmiId, Name, Visibility, Namespace, IsSpecification, IsRoot, IsLeaf, IsAbstrect, IsActive). Nous récupérons la valeur du nom de l'état et créons une classe JAVA qui portera ce nom. La même démarche sera effectuée à chaque fois qu'il sera nécessaire d'aller rechercher une information venant du fichier XMI et donc du diagramme.

Mais il existe des classes, dans la structure que nous avons mise au point, quine puisent pas toutes leurs informations dans le diagramme. Celles-ci seront toujours présentent quelque soit le contexte d'exécution.

Chapitre4

Développement de l'outil

4.1 Introduction

La phase de réalisation est la plus importante étape dans le cycle de vie de notre application car à la fin de cette phase nous allons avoir le fruit de toutes les étapes précédentes. Pour réaliser notre application nous avons été face à plusieurs outils de développement dont nous avons choisi l'Environnement <<Eclipse Galileo 3.5>> suite à plusieurs contraintes matérielles et logicielles. Au cours de ce chapitre, nous allons présenter l'environnement matériel et logiciel ainsi que les différents choix techniques utilisés pendant cette phase. Puis, nous allons présenter les différentes interfaces de notre application.

4.2 Environnement de développement

4.2.1 Environnement matériel

Dans le développement de notre application nous avons utilisé deux PC l'un << HP >> avec un processeur Intel Pentium dual-core processor de vitesse 800 MHz 1M L2 cache doté d'une Ram de 1 G et d'un disque dur de 160 Go et, l'autre << Acer >> avec un processeur Intel Pentium dual-core processor de vitesse 800 MHz, doté d'une Ram de 2 G et d'un disque dur de 160 Go.

4.2.1 Environnement logiciel

Environnement de développement : Eclipse Galileo 3.5. Outil de conception: StarUML 5.0.2.

4.3 Choix technique

4.3.1 Choix de L'environnement

4.3.1.1 Eclipse Galileo 3.5

Eclipse désigne également le projet correspondant, lancé par IBM) extensible, universel et polyvalent, permettant potentiellement de créer des projets de développement mettant en oeuvre n'importe quel langage de programmation. Eclipse IDE est principalement écrit en Java (à l'aide de la bibliothèque graphique SWT, d'IBM), et ce langage, grâce à des bibliothèques spécifiques, est également utilisé pour écrire des extensions.

Ce choix n'était pas arbitraire, il a été fixé grâce aux nombreux points forts d'éclipse, et les principaux points sont :

- Une plate-forme ouverte pour le développement d'applications et extensible grâce à un mécanisme de plug-ins.

- Un support multi langage grâce à des plug-ins dédiés : Cobol, C, PHP, C#, ... - Support de plusieurs plates-formes d'exécution : Windows, Linux, Mac OS ...

- Malgré son écriture en Java, Eclipse est très rapide à l'exécution grâce à l'utilisation de la bibliothèque SWT.

- Une ergonomie entièrement configurable qui propose selon les activités à réaliser différentes <<perspectives>>.

- La construction incrémentale des projets Java grâce à son propre compilateur qui permet en plus de compiler le code même avec des erreurs, de générer des messages d'erreurs personnalisés.

- Une exécution des applications dans une JVM dédiée sélectionnable avec possibilité d'utiliser un débogueur complet (points d'arrêts conditionnels, visualiser et modifier des variables, évaluation d'expression dans le contexte d'exécution, changement du code à chaud avec l'utilisation d'une JVM 1.4).

- Propose le nécessaire pour développer de nouveaux plugins. - Possibilité d'utiliser des outils open source: CVS, Ant, JUnit.

- La plate-forme est entièrement internationalisée dans une dizaine de langue sous la forme d'un plug-in téléchargeable séparément.

- Le gestionnaire de mise à jour permet de télécharger de nouveaux plug-ins ou nouvelles versions d'un plug-in déjà installées à partir de sites web dédiés ( http://www.eclipse.org/). [Développant en java avec Eclipse].

4.3.1.2 StarUML 5.0.2

StarUML 5.0.2 [StarUML] est une application open source qui veut remplacer des applications commerciales à large couverture comme Rational Rose [Rational Rose] et Altova [Altova]. Supporte la plupart des diagrammes spécifiés par UML 2.0. Et la figure 4.1 présente sa page d'accueil.

- Mais de nombreux modules en C++, Java, Visual Basic, VB Script, C#, NET. - Licence : GNU GPL (General Public License).

4.4 Implémentation et validation de GenJava

4.4.1 Principe de fonctionnement

Le processus de génération d'un fichier au format .java à partir des modèles de classe réalisés passe par deux étapes (Figure 4.2). La première consiste à générer un fichier XMI D'écrivant ces modèles de classe et ceci en utilisant l'outil de transformation UML vers XMI offert par StarUML, la deuxième réside dans GenJava d'une traduction du fichier XMI pour générer le fichier au format .java .

4.4.2 Phase de test et de validation

4.4.2.1 Déploiement de l'application

Tout d'abord nous avons commencé par le déploiement de notre application : Pour générer le dossier d'installation nous avons utilisé l'assistant Export JAR de «Eclipse Galileo 3.5 » qui permet de créer tous les fichiers nécessaires (fichier.jar) pour l'installation et le bon fonctionnement de l'application sur n'importe quelle machine. Le détail du déploiement est présenté dans les figures au-dessous (Figure 4.3, Figure 4.4, Figure 4.5).

4.4.2.2 Création du fichier setup « GenJava.exe » de l'application

Pour créer un fichier exécutable (GenJava.exe) de notre application nous avons utilisé un logiciel de création de fichier d'installation « Clickteam Install Creator Pro » une version d'évaluation, qui est téléchargeable à partir d'un site dont l'URL est http://www.clickteam.com,

Install Creator Pro est le successeur de Click team Install Maker Pro. Leurs principes sont: sélectionner un répertoire de fichiers à installer, personnaliser votre programme d'installation en quelques clics souris et le construire. Il a par ailleurs de nombreuses nouvelles options, dont:

- une nouvelle interface, entièrement personnalisable pour vos programmes d'installation, avec un éditeur complet de boîtes de dialogue, la possibilité d'insérer des changeurs de style dans vos textes, de changer les couleurs et les polices, d'ajouter des liens, d'utiliser votre propre icône pour votre installeur, etc.

- une meilleure compression de nouvelles options pour visualiser ou exécuter plusieurs fichiers à différents moments de l'installation, pour empêcher un fichier d'être installé sur certaines versions de Windows, pour empêcher l'installation de démarrer si un fichier est en cours d'utilisation, pour installer des fichiers dans plusieurs répertoires.

Dans la figure 4.6 nous présentons l'interface de création du fichier setup de l'application.

4.4.2.3 Installation de l'application

L'installation ce fait à partir de double clic sur « GenJava.exe >>,et notre application s'installe par défaut au chemin « C:\program files\GenJava >> comment le montre la figure 4.7 .

4.4.2.4 Interfaces de l'application

Les interfaces graphiques de l'application sont très importantes, car elles permettent de faciliter le dialogue entre l'homme et la machine ainsi que d'améliorer les performances de l'application, l'interface de notre application est inspiré principalement de l'environnement Eclipse, tel que le concept de Workspace, le concept de projet, l'éditeur a plusieurs anglets ...

Notre application est composée de deux pages : Page d'accueil et Page de travaille.

La page d'accueil GenJava contient deux champs de texte (JTextfeild) le premier contient le chemin de Workspace par défaut « C:\ GenJavaWorkspace», et la deuxième porte le nom de projet à crier par l'utilisateur .E plus, il existe Deux buttons (JButon) :

- Browse (Parcourir) : qui permit d'ouvrir un sélecteur de répertoires (JDirectorychooser)

- OK (Valider) : permit de crier le projet nommée dans le champ de texte 2 dans le Workspace préciser selon hiérarchie présente dans la figure 4.7

L'espace de travail de GenJava est composer d'un éditeur multi anglet, la premier est réserver pour le fichier XMI n'est pas éditable, les autres anglets sont pour les fichiers crier apres la generation de code.

4.4.2.5 Fonctionnement de GenJava

Comme on a dit dans la section 4.4.1 la génération de code java avec GenJava est composée en deux phases, une sur StarUML et l'autre sur GenJava, la série des figures de 4.10 à 4. 14 Présente tous les étapes de fonctionnement :

- Serialisation de modele de classe en fichier XMI à partir de menu File -Export -XMI

4.5 Limites de GenJava

L'outil StarUML nous a permis de faire le lien avec le monde des spécifications formelles. Pour pouvoir générer un code Java complet et syntaxiquement correct avec GenJava, l'utilisateur doit respecter certaines conditions:

4.6 Transformation de modèles de classe UML vers code JAVA



		package PACK;



	public class Classe1{ }

	public class Classe1{ public Classe1(){ } public void O1(int x1){ } public int X; public boolean Bol;
}

public abstract class CLASSE{

			CLASSE(){ public } }

public interface Inteface1 { }

public class C1{

public C1(){

}

public void addc2( E ){ c2.add(E); E.addc1(this);

}

private java.util.ArrayList<> c2 ;

}

public class {

public (){

c1= new java.util.ArrayList<C1> (); }

public void addc1( C1 E ){ c1.add(E); E.addc2(this);

}
private java.util.ArrayList<C1>

c1 ;

}

public class C1{

public C1(){ }

public getc2(){

return c2;

}

public void setc2( E ){ this.c2 = E ;

}

private c2;

}

public class { public (){

c1 = new C1 ();

}

public C1 getc1(){

return c1;

}

public void setc1( C1 E ){

this.c1 = E;

}

private C1 c1;

}

Conclusion

Nous sommes arrivés maintenant au terme de ce mémoire. Celui-ci visait concrètement à implémenter un générateur automatique de code java à partir des diagrammes de classe UML. Nous avons pu démontrer que ceci est possible notamment grâce à l'outil « StarUML 5.0.2» qui permet de modéliser un système complexe en utilisant la notation définie dans le langage semi-formel d'UML 2.0.

Cette génération passe toutefois par plusieurs étapes. En effet, nous avons d'abord transcrit le diagramme de classe décrit par l'outil de modélisation UML (myDiagram.uml) en un fichier XMI (myDesign.xml) qui est un langage permettant de décrire les données présentent dans un diagramme de classe UML de manière structurée (comme à l'image d'un ficher XML). Ensuite il nous a fallu écrire un parseur pour:

- Récupérer le fichier XML qui contient tous les modèle UML (Use case, Analysis model, design model,...),

- Analyser les éléments de ce fichier concept par concept d'une manière séquentielle et générer le code java correspond au bloque de spécification définie dans une balise XML.

Le but premier du travail a été atteint. Toutefois, ce générateur est ouvert à de futurs travaux visant l'amélioration de celui-ci. En effet, nous pourrions par exemple, imaginer une sorte de programme intégrant un traducteur de langage UML vers XMI et le générateur lui-même. Celui-ci manque aussi peut-être d'une certaine ergonomie, problème qui pourrait être résolu par l'implémentation d'une interface graphique à partir de laquelle l'utilisateur pourrait directement générer le code.

D'un point de vue plus technique, ce générateur pourrait aussi, peut-être, amélioré. En effet, son implémentation manque peut-être d'une certaine souplesse. L'utilisation de celui-ci sur d'autres systèmes que notre distributeur pourrait faire l'objet d'une attention particulière lors d'un futur travail, afin de peut-être mettre en évidence certaines lacunes de celui-ci.

Enfin, d'un point de vue plus personnel, je dois dire que toutes mes attentes ont été comblées lors de la réalisation de ce mémoire. En effet, la notion de programmation orientée objet ma beaucoup intéressé lors de mes études.

CONCLUSION

C'est pourquoi j'ai choisi ce mémoire qui ma permis d'étendre mes connaissances dans ce domaine, notamment en m'initiant à l'utilisation des design modèles qui sont très important lors du développement de logiciel.

De plus, j'ai pu aussi m'intéresser à d'autres sujets tels que la transcription de diagrammes en code grâce au XMI et le parsing de fichier XML.

Bibliographie

[Booch2001] Gragy Booch, James Runbaugh, Ivar Jacobson ,UML le Guide Utilisateur .

[Lemesle 2001] R. lemeste. Techniques de modélisation et méta-modelisation. Thèse de Doctorat Universitaire de Nantes, 26 october 2000.

[Sommerville 2001] Somerville Software Engineering. 6th Edition, Addison-Wesley, 2001. [XMI2003] OMG. XML Metadata Interchange. Specification document Version 2.0. [Développons en java avec eclipse] Jean-Michel DOUDOUX Version0.80 du 25/01/2007

[Audibert 2009] UML de l'apprentissage à la pratique (cours et exercices) Laurent Audibert Ellipses 2009.

[Pascal 2006] Pascal Roques, UML 2 par la pratique - Études de cas et exercices corrigés, Eyrolles, 2006.

[Timothy 2002]Timothy J. Grose, Gary C. Doney, Stephen A. Brodsky, Ph.D. Mastering XMI Java Programming with XMI, XML, and UML.

[Hugues Bersini 2007] Hugues Bersini 2007, L'orienté objet Cours et exercices en UML 2, Eyrolles, 2007.

[Pierre 1997] Pierre Alien Muller, Modélisadation Objet Avec UML. [StarUML] http://staruml.sourceforge.net/

Résumé

UML peut être utilisé pour modéliser l'architecture et le comportement de tout genre de projet logiciel. C'est dû au fait qu'UML fournit plusieurs diagrammes qui s'adaptent à des différentes vues d'un système logiciel: diagrammes de classe, de composant et de déploiement visent l'aspect structurel d'un système pendant que les diagrammes comportementaux tels que les diagrammes de cas d'utilisation, de statechart, d'activité et d'interaction visent l'aspect dynamique d'un système. Nous présentons une stratégie pour la génération du code Java à partir d'un modèle de classe UML basée sur le modèle XMI pour la description comme langage intermédiaire, qui sérialise le modèle de classe sous forme d'un document XML.

Mots-clés : Génération Automatique de Code, UML 2 .0, Diagramme de Classe, XML, XMI, Java, StarUML 5.02, Eclipse 3.5.

Abstract

UML can be used to model the architecture and behavior of any kind of software project. This is because UML provides many different views and diagrams about a given system: class diagrams, component and deployment are the structural aspect of a system while the behavioral diagrams such as use cases; statecharts, activity, and interaction are dynamic aspects of the same system. In this project we present a strategy for generating code from a class model based on XMI description model as an intermediate language, which serialize the class model in form of an XML document.

Keywords: Automatic Code Generation, UML 2 .0, Class Diagram, XML, XMI, Java, StarUML 5.0.2, Eclipse 3.5.

Génération automatique du code java à partir d'un modèle de classe UML

Remerciement