WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

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

( Télécharger le fichier original )
par Kamel Eddine Heraguemi
Centre universitaire de Souk Ahras Algérie - Licence informatique 2010
  

Disponible en mode multipage

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

íãáÚáÇ ËÍÈáÇ æ íáÇÚáÇ ã?áÚÊáÇ ÉÑÇÒæ

Centre universitaire

de Souk-Ahras

ÜÚ ?? ? ? ÜÜ ? ?

ÓÇÑÜÜ ? ? ÜÓ

Institut : Sciences & Techniques
Département : Sciences

Mémoire

uwuuuwu w uuu Uu wuwuuuu UU UWWUU UU
LICENCE EN INFORMATIQUE

Génération automatique du code java

A partir d'un modèle de classe UML

Par

HERAGUEMI KAMEL EDDINE
OULD YESLEM MOUHAMED

devant le jury si-dessous

Président :
Examinateur :
Encadreur :

Mr MOUHAMED BENDRISS Mme NADIA BENATI

DR ABDELKRIM AMIRAT

UWW UUUU

Remerciement

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.

Introduction 1

Motivations et Objectifs 2

Organisation du document 2

Chapitre 1 Développement Orienté Objet 3

1.1. Introduction 3

1.2 Paradigme Orienté Objet 3

1.2.1 Encapsulation 4

1.2.2 Héritage 5

1.2.3 Polymorphisme 6

1.3 Définitions 7

1.3.1 Objet 7

1.3.2 Classe 7

1.4 UML langage de modélisation Orienté Objet 8

1.4.1 Historique 8

1.4.2 Description d'UML 2.0 9

1.4.2.1 Diagrammes structurels 9

1.4.2.2 Diagrammes comportementaux 10

1.5 Document XMI 11

1.5.1 Historique 11

1.5.2 Concepts de base 11

1.5.3 Le standard XMI 12

1.5.3.1 Principe de fonctionnement 12

1.5.3.2 Le format XMI 13

1.5.3.4 Structure générale d'un document 13

1.5.3.5 Représentation des diagrammes de classes en XMI 13

1.6. Conclusion 14

Chapitre 2 Diagramme de classe 15

2.1. Introduction 15

2.2 Les paquetages 15

2.3 Les interfaces 16

2.4 Classes 16

2.4.1 Classes abstraites 16

2.4.2 Classes non abstraites 17

2.4.3 Les attributs 17

2.4.4 Les méthodes 17

2.5 Relations entre classes 18

2.5.1 Relation d'association 18

2.5.2 Relation d'Association binaire et n-aire 19

2.5.2 .1 Relation d'Association binaire 19

2.5.2 .2 Relation d'Association n-aire 19

2.5.3 Multiplicité 20

2.5.4 Navigabilité 20

2.5.5 Qualification 21

2.5.6 Classe-association 22

2.5.6.1 Définition et représentation 22

2.5.6.2 Auto-association sur classe-association 22

2.5.7 Agrégation et composition 23

2.5.7 .1 Relation d'Agrégation 23

2.5.7.2 Relation Composition 24

2.5.8 Relation de Généralisation 24

2.5.9 Relation de Dépendance 25

2.5.10 Relation d'Implémentation 26

2.5.11 Commentaires en UML 26

2.6 Conclusion 27

Chapitre 3 Génération de code 28

3.1. Introduction 28

3.2 Définition 28

3.2 Objectifs 29

3.3 Etapes de génération de code 29

3.3.1 Génération structurelle de code 29

3.3.2 Génération comportementale du code 29

3.3.3 Génération de la spécification 29

3.4 Approches de la génération de code 30

3.5 Conclusion 31

Chapitre 4 Développement de l'outil 32

5.1. Introduction 32

4.2 Environnement de développement 32

4.2.1 Environnement matériel 32

4.2.1 Environnement logiciel 32

4.3 Choix technique 33

4.3.1 Choix de L'environnement 33

4.3.1.1 Java JDK 6.0 sur Eclipse 3.5 33

4.3.1.2 StarUML 5.02 34

4.4 Implémentation et validation de GenJava 35

4.4.1 Principe de fonctionnement 36

4.4.2 Phase de test et de validation 36

4.4.2.1 Déploiement de l'application 36

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

4.4.2.3 Installation de l'application 38

4.4.2.4 Interfaces de l'application 40

4.4.2.4.1 La page d'accueil 40

4.4.2.4.1 Page de travaille 41

4.4.2.5 Fonctionnement de GenJava 42

4.5 Limites de GenJava 44

4.5 Transformation de modèles de classe UML vers code JAVA 45

Conclusion 51

Bibliographie 53

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

Chapitre 2

2.1

Les modificateurs d'accès d'attributs

16

2.2

Les modificateurs d'accès des méthodes

16

2.3

Les multiplicités

19

 

Chapitre 4

 

4.1

Mapping UML vers Java

44

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.

Motivations et Objectifs

- 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.

Organisation du document

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, ...) ;

- fonctionnels (comme lisp, schème,...);

- objets (comme C++, Java,. . .).

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.

Paradigme Procédurale

Procédure

Variable

Variable

Procédure

Fonction

Variable

Attribut

Variable

Attribut

Paradigme Objet

Méthode

Méthode

Figure 1.1- Encapsulation.

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 ;

}

 
 
 
 
 
 
 
 
 
 
 
 
 

Figure 1.2- Héritage.

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.

Exemple :

abstract class Forme { abstract float aire() ; }

 

class Carre extends Forme{ float cote;

float aire() {

return cote *

cote;

class Cercle extends Forme{ float rayon;

float aire() {

return Math.PI*rayon*rayon;

 
 
 

}

}

 
 

}

 

}

Figure 1.3- Polymorphisme.

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 concrets (ex : des avions),

- 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),

- des éléments comportementaux (ex : des tâches), etc.

Tout système orienté objet est organisé autour des classes.

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

Figure 1.4 - Classe et Objet.

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 ;

- OOSE d'Ivar Jacobson (Ericsson) fonde l'analyse sur la description des

besoins des utilisateurs (cas d'utilisation, ou use cases).

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 diagramme de classes (Class)

2 diagramme d'objets (Object)

3 diagramme de composants (Component)

4 diagramme de déploiement (Deployment)

5 diagramme de paquetages (Package)

6 diagramme de structures composites (Composite structure)

1.4.2.2 Diagrammes comportementaux

1 diagramme de cas d'utilisation (Use case)

2 diagramme d'activités (Activity)

3 diagramme d'états-transitions (State machine)

4 Diagrammes d'interaction (Interaction)

4.1 diagramme de séquence (Sequence)

4.2 diagramme de communication (Communication)

4.3 diagramme global d'interaction (Interaction overview)

4.4 diagramme de temps (Timing)

Figure 1.5 - Description D'UML 2.0.

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.

<EtatCivile>

<Nom>Heraguemi</Nom> <Prenom>Kamel eddine </Prenom> <Naicence>

<Date>

<Jour>30</Jour>

<Moi>05</Moi>

<Annee>1989</Annee>

</Date> </Naicence>

</EtatCivile>

Figure 1.6 - Exemple de document XML.

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.

Figure 1.7 - Diagramme de classes UML.

Figure 1.8 - Transcription au format XMI du diagramme de figure 1.6.

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.

Rôles

· Ils regroupent des éléments de modélisation.

· Ils permettent d'encapsuler des éléments de modélisation.

· Ils permettent de structurer un système en catégories sous-systèmes.

Figure 2.1 - Notation des paquetages.

2.3 Les interfaces

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

public interface Test1 {

void f (int n) ; // signature d'une méthode f void g () ; // signature d'une méthode g

}

 

Figure2.2 - Notation des interfaces.

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).

Figure 2.3 - Classes abstraites.

2.4.2 Classes non abstraites

Une classe est représentée par un rectangle séparée en trois parties:

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

- la dernière contient les méthodes 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 :

Caractère

Rôle

Description

+

accès public

Tous les objets et les classes ont accès à cet attribut.

#

accès protégé

Seules les classes issues de classes filles (héritage) ont accès à cet attribut.

-

accès privé

Seule la classe elle-même a accès à cet attribut.

~

néant (droit de paquetage)

Accès possible depuis toutes les classes du même paquetage

Tableau 2.1 : Les modificateurs d'accès d'attributs

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 modificateurs sont identiques à ceux des attributs :

Caractère

Rôle

+

accès public

#

accès protégé

-

accès privé

Tableau 2.2- Les modificateurs d'accès des 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 (), ...,

NOM DE CLASSE ATTRIBUE

METHODES

 
 
 

Figure 2.4 - Classes non abstraites.

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.

Figure 2.5- Modélisation d'une association.

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.

Figure 2.6- Association binaire. 2.5.2 .2 Relation d'Association n'aire

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.

Figure 2.7- Association n'aire.

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 :

Multiplicité

Désignation

1 ou 1..1

exactement un

* ou 0..*

plusieurs

1..*

au moins un

1..6

de un à six

Tableau 2.3 - Les multiplicités.

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.

Figure 2. 8 : Navigabilité

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.

A

B

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

b- Un diagramme équivalant utilise l'association qualifiée.

- 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.

Figure 2.10- Exemple de classe-association.

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.

Figure 2.11- Auto-association sur classe-association.

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.

Figure 2.12- Relation d'agrégation.

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

Figure 2.13- Relation de composition.

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.

Les propriétés principales de l'héritage sont :

- 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.

- Une classe peut avoir plusieurs parents, on parle alors d'héritage multiple

Figure 2.14- Partie du règne animal décrit avec l'héritage multiple.

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.

Figure 2.15- Relation de dépendance.

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.

Figure 2.16 - Implémentation des interfaces.

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é.

Figure 2 .17 - Commentaires dans le diagramme de classe UML.

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.

Modèle C#

Description de
la Platform C#

Transformation

Modèle UML

Description de la
Platform JAVA

Transformation

Modèle
JAVA

Figure 3.1- Génération de code avec le mapping direct.

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

- ne sont pas restreintes à UML,

- peuvent être plate-forme indépendant ou spécifique,

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

Description de la
Platform JAVA

Modèle
Intermédiaire

Modèle
JAVA

Transformation

Transformation

Modèle UML

Figure 3. 2- Génération de code avec Un modèle Intermédiaire.

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

Pour développer notre application, nous avons choisi

d'utiliser l'environnement <<Eclipse Galileo 3.5>>.est un

environnement de développement intégré libre (le terme

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.

- Les nombreuses fonctionnalités de développement proposées par le JDT

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

- Un historique local des dernières modifications.

- 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.

Figure 4.1- Page d'accueil de StarUML.

Fiche d'identité :

- Version actuelle : 5.0.2.

- Langage de développement : Delphi (principalement).

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

Exporter UML vers XMI

---.XMI

GenJAVA

.JAVA

- Plate-forme Win32.

- Architecture plugin.

- Exécutable à télécharger sur http://staruml.sourceforge.net/

Point Fort de StarUML

- User Friendly. - Rapide.

- Résistant.

Point Faible de StarUML

- Ne marche que sur le système d'exploitation Windows.

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 .

Modele de classe

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).

Figure 4.3- Etape 1 pour Exporter le fichier .jar.

Figure 4.4 - Etape 2 pour Exporter le fichier .jar.

Figure 4.5 - Etape 3 pour Exporter le fichier .jar.

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 meilleure interface avec barres d'outils personnalisables.

- 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.

Figure 4.6 - l'interface de Clickteam Install Creator Pro.

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 .

Au cours de cette installation GenJava propode d'installer StarUML 5.0.2.

Figure 4.7 - Etapes d'installation de GenJava.

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.

4.4.2.4.1 La page d'accueil

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

Workspace

 
 

Nom de projet

Src

MyFile.XML

DisignModel.xml

Figure 4.8- Hiérarchie de Workspace.

Changer le Workspace
Chemin de Workspace

Validation de projet Nom de projet

Icon de GenJava

Figure 4.9 - La page d'accueil de GenJava. 4.4.2.4.1 Page de travaille

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.

En plus, en peut parcourir et ouvrir starUML a partir de de cette interface.

Figure 4.10 - Page de travaille.

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 :

- Creation de modele de classe à l'aide de l'outil StarUML.

Figure 4.11 - Création de modele de Classe.

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

Figure 4.12- sérialisation de modèle (Export vers XMI).

- Ouvrir GenJava et crier votre projet

Figure 4.13 - ouvrir GenJava.

- Ouvrir le fichier XMI précédemment crié ;

Figure 4.14 - Ouvrir le fichier XMI.

- Apres l'ouverture de fichier XMI on appuie sur Génération on obtient

Figure 4.15 - résultat de génération.

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:

- Pas des paquetages imbriqué.

- les rôles et les cardinalités des associations doivent être spécifies.

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 interface Inteface1{ public void Operation() ;

}

public class C1 { public getc2 () {

return c2;

}

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

}

private c2;

}

public class { public C1 getc1(){

return c1;

}

public void setc1( C1 E ){ this.c1 = E;

}

private C1 c1;

}

public class C1 {

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

}

private java.util.ArrayList<> c2 ;

}

public class {

public void addc1( C1 E ){

c1.add(E); E.addc2(this);

}

private java.util.ArrayList<C1> c1 ;

}

public class C1 {

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

}

private java.util.ArrayList<> c2 ;

}

public class { }

public class C1{

public C1(){

}

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

}

private java.util.ArrayList<> c2 ;

}

public class { public (C1 E) { this.c1.add(E);

}

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 E){

this.c1 = E ;

}

public C1 getc1(){

return c1;

}

public void setc1( C1 E ){

this.c1 = E;

}

private C1 c1; }

 

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;

 

}

public class C1 implements Interface{

public C1(){

}

}

public interface Interface{

}

public class Exception1 extends Exception{

public Exception1(){

}

}

public class {

public (){

}

public void c2Exception1()throws Exception1 {

}

}

public class C1{

}

public class extends C1{ }

public class C3 extends { }

}

public class {

public (){

}

public void depand(){}

public void depandc1(){ lienc2C1= new (); lienc2C1.depand();

}

public class C1{
public C1(){

}

}

 

public class C1 implements Interface1 , Interface2 , Interface3{

public C1(){

}

}

public interface Interface1{ }

public interface Interface2{ }

public interface Interface3{ }

Tableau 3.1 - Mapping UML vers Java.

Conclusion

Bilan

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,...),

- Nettoyage de ce fichier pour extraire le 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/

[Rational Rose] http://www.ibm.com/developerworks/downloads [Altova] www.Altova.com/

[Clickteam Install Creator Pro] http://www.clickteam.com, [Dev] http://hdd34.developpez.com/cours/artpoo/

[Wiki] http://fr.wikipedia.org/wiki/H%C3%A9ritage_ (Informatique)

[W3C] World Wide Web Consortium. Extensible Markup Language 1.0, 2004. [OMG] http://www.omg.org/technology/xml/

[XML] http://78.40.125.79/brillant/2004-Moniot/technos-XML.html.

[Laurent] http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML014.html

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.






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Il existe une chose plus puissante que toutes les armées du monde, c'est une idée dont l'heure est venue"   Victor Hugo