Mémoire PEF application client server gestion des projet collaborative

République Algérienne Démocratique et Populaire Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université Constantine 2

Faculté des Nouvelles Technologies de l’Information et la Communication

Département de l’Informatique Fondamentale et ses Applications

Projet de fin d’études pour l’obtention du diplôme de

Licence en Informatique

Option : Sciences et Technologie de l’Information et de la Communication

Thème

Conception et réalisation d’un

Système de gestion de projet en groupe

Dirigé par : Réalisé par :

Lezzar Fouzi Merabet Seddam Hussien

Hatri Messaoud

Kadjouh Hatem

- Session Juin 2013 -

exÅxÜv|xÅxÇàáexÅxÜv|xÅxÇàáexÅxÜv|xÅxÇàáexÅxÜv|xÅxÇàá

Nous remercions Allah le tout puissant de nous avoir donné la

force, la patience et le courage pour la réalisation

de notre travail.

A notre promoteur « Mr. LEZZAR F. » ainsi qu’a

« Mme. CHIKHI S. » pour leurs suivis

et leurs précieuses orientations.

A tous nos amis pour leur aide et leur soutient.

Enfin, à toute personne ayant contribuée de prés ou de loin à la

réalisation de ce travail.

ListListListListeeee des des des des figuresfiguresfiguresfigures

Figure 2.1 : Exemple d’association …………………………..………

Figure 2.2 : Exemple d’agrégation et de composition ……..…...…

Figure 2.3 : Exemple de généralisation ………………………..…...

Figure 2.4 : Exemple d’un diagramme de classe ………………..…

Figure 2.5 : Exemple d’un diagramme d’objet ……………..………

Figure 2.6 : Exemple d’un diagramme de déploiement ……..……

Figure 2.7 : Exemple d’un diagramme de packages …………..…..

Figure 2.8 : Exemple d’un diagramme de composants ………..….

Figure 2.9 : Exemple d’un diagramme cas d’utilisation ………....

Figure 2.10 : Exemple d’un diagramme de séquence ……………....

Figure 2.11 : Exemple d’un diagramme d’activité …………….……

Figure 2.12 : Exemple d’un diagramme d’état …………………..…..

Figure 2.13 : Les diagrammes UML utilisés …………………..…….

Figure 3.1 : Diagramme cas d’utilisation ……………………..…....

Figure 3.2 : Diagramme d’activité « S’authentifier » …………......

Figure 3.3 : Diagramme d’activité « Ajouter client » …………..….

Figure 3.4 : Diagramme d’activité « Modifier une tâche » …….....

Figure 3.5 : Diagramme d’activité « Supprimer tâche» ………….

Figure 3.6 : Diagramme d’activité « Envoyer message» ……….....

Figure 3.7 : Diagramme séquence « S’authentifier » …………...…

Figure 3.8 : Diagramme séquence « Ajouter utilisateur » ……..…

Figure 3.9 : Diagramme séquence « Modifier une tâche » …….....

Figure 3.10 : Diagramme séquence « Supprimer une tâche » …….

Figure 3.11 : Diagramme séquence « Envoyer message » ………....

Figure 3.12 : Diagramme de classe …………………………………...

Figure 3.13 : Diagramme déploiement ……………………………….

Figure 4.1 : Page d’authentification ………………………………...

Figure 4.2 : Interface d’espace de travaille ………………………...

Figure 4.3 : L’interface de gestion des clients ………………..…….

Figure 4.4 : L’interface de gestion des ressources ………………...

Figure 4.5 : L’interface d’ajout ou d’une modification d’une tâche

Figure 4.6 : L’interface d’ouvrir ou enregistrer un projet ……..…

Figure 4.7 : L’interface d’un diagramme du GANTT …………..…

14

15

15

16

16

17

17

18

19

20

20

21

22

24

30

31

32

33

34

35

36

37

38

39

40

41

44

45

46

46

47

48

49

ListListListListeeee des des des des tablestablestablestables

Tableau 1.1 : Gestion produit logiciel ………………...……………………..

Tableau 3.1 : Description du cas d’utilisation « s’authentifier »………..

Tableau 3.2 : Description du cas d’utilisation « Ajouter tâche » ……….

Tableau 3.3 : Description du cas d’utilisation « Modifier tâche » ……...

Tableau 3.4 : Description du cas d’utilisation «Supprimer tâche » ……

Tableau 3.5 : Description du cas d’utilisation « Envoyer un message » ..

Tableau 3.6 : Description du cas d’utilisation «Ajouter client»…………..

Tableau 3.7 : Description du cas d’utilisation « Modifier client» ………..

Tableau 3.8 : Description du cas d’utilisation «Supprimer client» ……...

Tableau 4.1 : Les couches de modèle TCP/IP .……………………………...

5

25

26

26

27

27

28

28

29

52

Table des matières

Introduction générale ………………………………………………………..

Chapitre 1Chapitre 1Chapitre 1Chapitre 1 :::: Processus de développement UP 1.1 Introduction ………………………………………………………....

1.2 Définition ………………………………………………………….....

1.3 Les caractéristiques de processus…………………………………

1.3.1 Itératif et incrémental ……………………………………………..

1.3.2 Centré sur l’architecture …………………………………………..

1.3.3 Conduit par les cas d’utilisation ………………………………….

1.3.4 Piloté par les risques ……………………………………………….

1.4 Cycle de vie du processus ………………………………………….

1.4.1 La phase d’initialisation …………………………………………...

1.4.2 La phase d’élaboration ……………………………………………..

1.4.3 La phase de conception …………………………………………….

1.4.4 La phase d’implémentation ……………………………………….

1.4.5 La phase de transition ……………………………………………..

1.5 Les Activités …………………………………………………………

1.5.1 Expression des besoins …………………………………………….

1.5.2 Analyse des besoins …………………………………………………

1.5.3 Conception ……………………………………………………………

1.5.4 Implémentation ……………………………………………………..

1.5.5 Test ……………………………………………………………………

1.6 Avantages d’un processus itératif contrôlé ……………………..

1.7 Conclusion ……………………………………………………………

Chapitre Chapitre Chapitre Chapitre 2222 :::: Langage de modélisation UML 2.1 Introduction ………………………………………………………….

2.2 La Programmation Orientée Objet ……………………………….

2.2.1 Le concept d’objet ……………………………………………………

2.2.2 Le concept d’encapsulation ………………………………………..

2.2.3 Le concept de classe ………………………………………………...

2.2.4 L’héritage …………………………………………………………….

2.2.5 Le polymorphisme ………………………………………………….

2.3 Historique ……………………………………………………………

2.4 Définition …………………………………………………………….

2.5 Principes de mise en œuvre d’UML ………………………………

2.5.1 Les avantages d’UML ………………………………………………

2.5.2 Les inconvénients d’UML …………………………………………

2.6 Les diagrammes d’UML ……………………………………………

2.6.1 Modélisation statique ………………………………………………

2.6.1.1 Diagramme de classes ……………………………………………...

2.6.1.2 Diagramme d’objets ………………………………………………...

2.6.1.3 Diagramme de déploiement ……………………………………….

2.6.1.4 Diagramme de packages …………………………………………...

2.6.1.5 Diagramme de composants ………………………………………..

2.6.2 Modélisation dynamique …………………………………………..

1

2

2

3

3

3

4

4

4

5

6

6

7

7

8

8

8

8

9

9

9

9

10

10

10

10

10

11

11

11

12

12

13

13

13

14

14

16

16

17

18

19

2.6.2.1 Diagramme de cas d’utilisation …………………………………..

2.6.2.2 Diagramme de séquence …………………………………………...

2.6.2.3 Diagramme d’activité ………………………………………………

2.6.2.4 Diagramme d’états ………………………………………………....

2.7 Conclusion ……………………………………………………………

Chapitre 3Chapitre 3Chapitre 3Chapitre 3 :::: Conception de l’application 3.1 Introduction ………………………………………………………….

3.2 Présentation du projet ……………………………………………...

3.3 Etude préliminaire ………………………………………………….

3.3.1 Diagramme de cas d’utilisation …………………………………..

3.3.2 Fiches descriptives ………………………………………………….

3.3.2.1 Fiche descriptive du cas d’utilisation « s’authentifier » ……….

3.3.2.2 Fiche descriptive du cas d’utilisation « ajouter tâche » ……….

3.3.2.3 Fiche descriptive du cas d’utilisation « modifier tâche » ……...

3.3.2.4 Fiche descriptive du cas d’utilisation « supprimer tâche » ……

3.3.2.5 Fiche descriptive du cas d’utilisation « envoyer message » …..

3.3.2.6 Fiche descriptive du cas d’utilisation « ajouter client » ……….

3.3.2.7 Fiche descriptive du cas d’utilisation « modifier client » ……...

3.3.2.8 Fiche descriptive du cas d’utilisation « supprimer client » …...

3.4 Diagrammes d’activité ……………………………………………..

3.5 Diagrammes de séquence ………………………………………….

3.6 Diagrammes de classe ……………………………………………...

3.7 Diagrammes de déploiement ……………………………………...

3.8 Conclusion ……………………………………………………………

Chapitre Chapitre Chapitre Chapitre 4444 :::: Réalisation de l’application 4.1 Introduction ………………………………………………………….

4.2 Les technologies utilisées ………………………………………….

4.2.1 Langage de programmation JAVA ………………………………

4.2.2 Environnement Netbeans ………………………………………….

4.2.3 SGBD utilisé …………………………………………………………

4.3 Fonctionnalités de l'application …………………………………..

4.3.1 Authentification ……………………………………………………..

4.3.2 Fenêtre principale …………………………………………………..

4.3.3 Gestion des clients ………………………………………………….

4.3.4 Gestion des ressources ……………………………………………..

4.3.5 Ajouter une tâche …………………………………………………...

4.3.6 Enregistrer / ouvrir un projet …………………………………….

4.3.7 Diagramme de GANTT …………………………………………….

4.4 Technologies réseau utilisées ……………………………………..

4.4.1 Les sockets …………………………………………………………...

4.4.1.1 Protocol TCP/IP ……………………………………………………..

4.4.1.2 L’aspect Client/serveur ……………………………………………

4.4.2 La sérialisation ……………………………………………………...

4.5 Conclusion ……………………………………………………………

Conclusion générale ………………………………………………………….

19

19

19

21

22

23

23

24

24

25

25

26

26

27

27

28

28

29

30

35

40

41

41

42

42

42

43

43

44

44

45

46

46

47

48

49

50

50

52

53

54

54

55

1 Introduction généraleIntroduction généraleIntroduction généraleIntroduction générale

Introduction généraleIntroduction généraleIntroduction généraleIntroduction générale

Le développement des réseaux informatiques est l’un des éléments

importants qui ont contribué dans l’évolution des technologies de

l’information et de la communication. Avec l’arrivée de nouvelles

technologies, les attentes des utilisateurs, à l’égard des applications et des

sites Web, se sont développées énormément. Actuellement, on s’attend de

plus en plus à des applications complètes, interactives et mises à jour

rapidement, utilisant des technologies de pointe et offrant plus de

fonctionnalités.

Le travail collaboratif est un facteur très important dans une

entreprise. En raison de l’expansion du marché et de la diversité

des clients potentiels, adopter une gestion des projets collaborative

d’où plusieurs utilisateurs séparés géographiquement peuvent travailler

d’une manière collaborative pour planifier un projet ce processus

sera bénéfique en termes de temps.

L’objectif de notre travail, consiste alors à concevoir et réaliser une

application « client/serveur » qui facilitera l’interaction entre la maîtrise

d’œuvre et la maîtrise d’ouvrage, le chef du projet sera l’administrateur.

Ce travail est organisé en quatre chapitres :

Le premier chapitre s’intitule «Processus de développement UP», a pour

objectifs de définir méthodologie sur lesquels est basé notre travail.

Le deuxième chapitre s’intitule «Langage de modélisation objet UML».

Nous avons décri l’outil UML et ses différents diagrammes.

Le troisième chapitre s’intitule «Conception du l'Application » qui est le

noyau de notre travail. Nous avons d’abord recensé les acteurs qui

interagissent avec notre application, puis nous avons décrit les besoins

de chaque acteur sous forme de cas d’utilisation et pour chaque cas

d’utilisation, un diagramme de séquence et d’activité. Enfin, nous avons

établi le diagramme de classe et diagramme de déploiement dont l’objectif

est d’implémenter notre application.

Le quatrième chapitre s’intitule «Réalisation» dans lequel nous définirons

les outils de développement que nous avons utilisés. Nous illustrerons

également quelques interfaces du l’application développé.

CHAPITRE 1CHAPITRE 1CHAPITRE 1CHAPITRE 1

ProcessusProcessusProcessusProcessus

DuDuDuDu

DéveloppementDéveloppementDéveloppementDéveloppement

---- UP UP UP UP ----

2 Chapitre IChapitre IChapitre IChapitre I : : : : ProcessusProcessusProcessusProcessus de développement de développement de développement de développement UP UP UP UP

1111....1111 IntroductionIntroductionIntroductionIntroduction

Un processus de développement logiciel a pour but la formalisation des activités liées à l’élaboration des systèmes informatiques. Tout processus de développement logiciel décrit :

• Les règles de modélisation et de conception de systèmes logiciels de manière fiable et Reproductible ;

• Les règles de mise en œuvre qui représentent l’enchaînement des actions, l’ordonnancement des tâches et la répartition des responsabilités.

UP vient de compléter la systémique des modèles UML qui est souvent qualifiée de langage de modélisation. Elle permet en fait de ‘penser objet’ au moment de la conception et de la modélisation afin de permettre un développement objet plus aisé. Par contre le cycle de vie du logiciel, le processus de création et même de conception des modèles ne sont pas pris en charge par UML. Le processus unifié UP c’est un patron de processus pouvant être adapté à des projets informatiques de toutes tailles. Il présente l’ensemble des activités depuis la conception jusqu’au livrable ; tout en exprimant les différentes étapes de développement. Un processus définit une séquence d’étapes, partiellement ordonnées, qui concourent à l’obtention d’un système logiciel ou à l’évolution d’un système existant. L’objet d’un processus de développement est de produire des logiciels de qualité qui répondent aux besoins de leurs utilisateurs dans des temps et des coûts prévisibles.

• Les délais doivent être tenus pour que le projet aboutisse, • Le coût doit rester en rapport avec les moyens financiers disponibles • et la qualité qui doit être à niveau compatible avec la critique du

système. Un processus doit permettre de répondre à la question fondamentale : « Qui fait quoi et quand ? ».

1111....2222 DéfinitionDéfinitionDéfinitionDéfinition Le Processus Unifié (UP pour Unified Process) est un processus générique de développement logiciel construit sur UML. Générique signifie qu’il est nécessaire d’adapter UP au contexte du projet, de l’équipe, du domaine et/ou de l’organisation. C'est un patron de processus pouvant être adapté à une large classe de systèmes logiciels, à différents domaines d'application, à différents types d'entreprises, à différents niveaux de compétences et à différentes tailles d'entreprises.

MESSAOUD

Highlight

MESSAOUD

Sticky Note

Accepted set by MESSAOUD


Il existe un certain nombre de méthodes issues de UP à savoir : � RUP : Rational Unified Procces Proposé par la société IBM RATIONAL SOFTWARE ; � XP : eXtreme Programming

Proposé par la société FIRST CLASS SOFTWARE INC ; � 2TUP : Two Track Unified Process

Proposé par la société VALTECH ;

1111....3333 Les caractéristiques dLes caractéristiques dLes caractéristiques dLes caractéristiques de processuse processuse processuse processus Le Processus Unifié (UP, pour Unified Process) est un processus de développement logiciel « itératif et incrémental, centré sur l’architecture, conduit par les cas d’utilisation et piloté par les risques » :

1111....3333....1111 Itératif et incrémentalItératif et incrémentalItératif et incrémentalItératif et incrémental Le développement d’un produit logiciel destiné à la commercialisation par une vaste entreprise qui peut s’étendre sur plusieurs mois. On ne va pas tout développer d’un coup. On peut découper le travail en plusieurs parties qui sont autant de mini projets. Chacun d’entre eux représentant une itération qui donne lieu à un incrément. Le projet est découpé en itérations de courte durée (environ 1 mois) qui aident à mieux suivre l’avancement global. On peut découper le travail en plusieurs parties qui sont autant de mini projets. Chacun d’entre eux représentant une itération qui donne lieu à un incrément. Une itération désigne la succession des étapes de l’enchaînement d’activités, tandis qu’un incrément correspond à une avancée dans les différents stades de développement. A chaque itération, les développeurs identifient et spécifient les cas d’utilisations pertinents, créent une conception en se laissant guider par l’architecture choisie, implémentent cette conception sous forme de composants et vérifie que ceux-ci sont conformes aux cas d’utilisation. Dès qu’une itération répond aux objectifs fixés le développement passe à l’itération suivante.

À la fin de chaque itération, une partie exécutable du système final est produite, de façon incrémentale.

1111....3333....2222 Centré sur l’architectureCentré sur l’architectureCentré sur l’architectureCentré sur l’architecture

Tout système complexe doit être décomposé en parties modulaires afin de garantir une maintenance et une évolution facilitées. Dès le démarrage du processus, on aura une vue sur l'architecture à mettre en place. L’architecture d’un système logiciel peut être décrite comme les différentes vues du système qui doit être construit. L’architecture logicielle équivaut aux aspects statiques et dynamiques les plus significatifs du système. L’architecture émerge des besoins de l’entreprise, tels qu’ils sont exprimés par les utilisateurs et autres intervenants et tels qu’ils sont reflétés par les cas d’utilisation.

MESSAOUD

Highlight

MESSAOUD

Cross-Out

MESSAOUD

Highlight


Cette architecture (fonctionnelle, logique, matérielle, etc.) doit être modélisée en UML et pas seulement documentée en texte.

1111....3333....3333 CondCondCondConduit par les cas uit par les cas uit par les cas uit par les cas d’utilisationd’utilisationd’utilisationd’utilisation Le projet est mené en tenant compte des besoins et des exigences des utilisateurs; il faut par conséquent bien comprendre les désirs et les besoins des futurs utilisateurs. Le processus de développement sera donc centré sur l'utilisateur. Le terme utilisateur ne désigne pas seulement les utilisateurs humains mais également les autres systèmes. L’utilisateur représente donc une personne ou une chose dialoguant avec le système en cours de développement. Ce type d’interaction est appelé cas d’utilisation. Les cas d’utilisation garantissent la cohérence du processus de développement du système. Les cas d’utilisation du futur système sont identifiés, décrits avec précision et priorisés.

1111....3333....4444 Piloté par lesPiloté par lesPiloté par lesPiloté par les risquesrisquesrisquesrisques Les risques majeurs du projet doivent être identifiés au plus tôt, mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce cadre déterminent l’ordre des itérations.

1111....4444 Cycle de vie du processusCycle de vie du processusCycle de vie du processusCycle de vie du processus

L'objectif d'un UP est de maîtriser la complexité des projets informatiques en diminuant les risques. UP est un ensemble de principes génériques adaptés en fonction des spécificités des projets. UP répond aux préoccupations suivantes :

• QUI participe au projet ? • QUOI, qu'est-ce qui est produit durant le projet ? • COMMENT doit-il être réalisé ? • QUAND est réalisé chaque livrable ?

UP répète un certain nombre de fois une série de cycles. Tout cycle se conclut par la livraison d’une nouvelle version du produit (logiciel) aux clients. Ce produit se compose d’un code source réparti sur plusieurs composants pouvant être compilés et exécutés et s’accompagne de manuels associés. Pour mener efficacement un tel cycle, les développeurs ont besoin de toutes les représentations du produit logiciel :

MESSAOUD

Highlight

MESSAOUD

Highlight

MESSAOUD

Highlight


Modèle de cas d'utilisation

Expose les cas d’utilisation et leurs relations avec les utilisateurs

Modèle d'analyse Détaille les cas d'utilisation et procède à une première répartition du comportement du système entre divers objets

Modèle de conception Définit la structure statique du système sous forme de sous-systèmes, classes et interfaces.

Décrit les cas d’utilisation sous forme de collaborations entre les sous-systèmes, les classes et les interfaces

Modèle d'implémentation

Intègre les composants (code source) et la correspondance entre les classes et les composants

Modèle de déploiement Définit les nœuds physiques des ordinateurs et l’affectation des composants sur ces nœuds.

Modèle de test Décrit les cas de test vérifiant les cas d’utilisation

Représentation de l'architecture

Décrit la forme de l’application (l’architecture logicielle).

Tableau 1-1 : gestion produit logiciel Tous les modèles sont liés. Ensemble, ils représentent le système comme un tout. Chaque cycle de développement du système s’articule en 4 phases :

• l’analyse des besoins (démarrage) ; • l’élaboration ; • la construction ; • la transition.

Chaque phase se subdivise à son tour en plusieurs itérations limitées dans le temps (2 à 4 semaines) et séquentielles. Le résultat d’une itération est un système testé, intégré et exécutable. A la fin d’une itération, les modèles définis précédemment sont affinés et améliorés par des ajouts successifs. Le système croît dans le temps de façon incrémentale (d’où la désignation : développement itératif et incrémental).

1111....4444....1111 La La La La phase d’initialisatiophase d’initialisatiophase d’initialisatiophase d’initialisationnnn (expression des besoins)(expression des besoins)(expression des besoins)(expression des besoins)

Conduit à définir la « vision » du projet, sa portée, sa faisabilité, son business case, afin de pouvoir décider au mieux de sa poursuite ou de son arrêt ;

• Recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui conduisent à l'élaboration des modèles de cas d'utilisation ;

• Appréhender les besoins non fonctionnels (technique) et livrer une liste des exigences ;

Le modèle de cas d'utilisation présente le système du point de vue de l'utilisateur et représente sous forme de cas d'utilisation et d'acteur, les besoins du client.

MESSAOUD

Cross-Out


1111....4444....2222 La phase d’élaboratioLa phase d’élaboratioLa phase d’élaboratioLa phase d’élaboration (Analyse)n (Analyse)n (Analyse)n (Analyse) L'objectif de l'analyse est d'accéder à une compréhension des besoins et des exigences du client. Il s'agit de livrer des spécifications pour permettre de choisir la conception de la solution. Un modèle d'analyse livre une spécification complète des besoins issus des cas d'utilisation et les structure sous une forme qui facilite la compréhension (scénarios), la préparation (définition de l'architecture), la modification et la maintenance du futur système. Il s'écrit dans le langage des développeurs et peut être considéré comme une première ébauche du modèle de conception. Elle répond aux questions suivantes :

• Que va faire le système pour les utilisateurs? • Par rapport aux utilisateurs principaux, quels services va-t-il rendre? • Quelle va être l'architecture générale (cible) de ce système ? Etude

Préliminaire • Quels vont être les délais, les coûts, les ressources, les moyens à

déployer? Poursuit trois objectifs principaux en parallèle :

• Identifier tous les acteurs et les cas d’utilisation, et en dessinant les cas d’utilisation essentiels (20% du modèle);

• construire l’architecture de base du système et pas seulement décrire dans un document ;

• Un plan de gestion de projet est fait pour déterminer les ressources nécessaires pour le projet.

• lever les risques majeurs du projet ;

1111....4444....3333 La phase de La phase de La phase de La phase de conceptionconceptionconceptionconception La conception permet d'acquérir une compréhension approfondie des contraintes liées au langage de programmation, à l'utilisation des composants et au système d'exploitation.

Durant cette phase on se concentre sur deux choses : • avoir une bonne connaissance des besoins (90%) et • établir une base de l’architecture.

Elle détermine les principales interfaces et les transcrit à l'aide d'une notation commune. Constitue un point de départ à l'implémentation et décompose le travail d'implémentation en sous-système. Elle créée une abstraction transparente de l'implémentation. Consiste surtout à concevoir l’ensemble des éléments opérationnels (autres que ceux de l’architecture de base). C’est la phase la plus consommatrice en ressources et en effort ; Les taches à effectuer dans la phase élaboration sont les suivantes :

Créer une architecture de référence • Identifier les risques, ceux qui sont de nature à bouleverser le plan,

le coût et le calendrier • Définir les niveaux de qualité à atteindre

MESSAOUD

Cross-Out


• Formuler les cas d’utilisation pour couvrir les besoins fonctionnels et planifier la phase de construction

• Elaborer une offre abordant les questions de calendrier, de personnel et de budget

1111....4444....4444 La phase d’implémentationLa phase d’implémentationLa phase d’implémentationLa phase d’implémentation

L'implémentation est le résultat de la conception pour implémenter le système sous formes de composants, c'est-à-dire, de code source, de scripts, de binaires, d'exécutables et d'autres éléments du même type. Les objectifs principaux de l'implémentation sont de planifier les intégrations des composants pour chaque itération, et de produire les classes et les sous-systèmes sous formes de codes sources. Critères d’évaluation :

• Stabilité et maturité des réalisations (en vue du déploiement)

• Capacité de mettre en œuvre la transition. • Coûts acceptables.

1111....4444....5555 La phase de transitionLa phase de transitionLa phase de transitionLa phase de transition (Test)(Test)(Test)(Test)

Faire passer le système informatique des mains des développeurs à celles des utilisateurs finaux. Les tests permettent de vérifier des résultats de l'implémentation en testant la construction. Pour mener à bien ces tests, il faut les planifier pour chaque itération, les implémenter en créant des cas de tests, effectuer ces tests et prendre en compte le résultat de chacun. Chaque phase est elle-même décomposée séquentiellement en itérations limitées dans le temps (entre 2 et 4 semaines). Le résultat de chacune d’elles est un système testé, intégré et exécutable. L’approche itérative est fondée sur la croissance et l’affinement successifs d’un système par le biais d’itérations multiples, feedback et adaptation cycliques étant les moteurs principaux permettant de converger vers un système satisfaisant. Le système croît avec le temps de façon incrémentale, itération par itération, et c’est pourquoi cette méthode porte également le nom de développement itératif et incrémental. Il s’agit là du principe le plus important du Processus Unifié UP gère le processus de développement par deux axes : a) L'axe verticalL'axe verticalL'axe verticalL'axe vertical représente les principaux enchaînements d'activités, qui

regroupent les activités selon leur nature. Cette dimension rend compte l'aspect statique du processus qui s'exprime en termes de composants, de processus, d'activités, d'enchaînements, d'artefacts et de travailleurs.

b) L'axe horizontalL'axe horizontalL'axe horizontalL'axe horizontal représente le temps et montre le déroulement du cycle

de vie du processus; cette dimension rend compte de l'aspect dynamique du processus qui s'exprime en termes de cycles, de phases et d'itérations.

MESSAOUD

Cross-Out


Chaque itération comprend les caractéristiques d’un projet de développement logiciel : planification, analyse des besoins, conception, implémentation et tests. Entre deux itérations, il y a réception des retours utilisateurs, ce qui permet de réajuster le développement pour l’étape ultérieure. Les itérations exécutées dan les premières phases correspondent surtout à l’étude générale, au calcul des risques et à l’élaboration de l’architecture générale. Au fur et à mesure que l’on avance dans le projet, les composants sont créés, les itérations deviennent des incréments.

1111....5555 Les ActivitésLes ActivitésLes ActivitésLes Activités 1111....5555....1111 ExpExpExpExpression des besoinsression des besoinsression des besoinsression des besoins

L'expression des besoins comme son nom l'indique, permet de définir les différents besoins :

• inventorier les besoins principaux et fournir une liste de leurs fonctions • recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui

conduisent à l'élaboration des modèles de cas d'utilisation • appréhender les besoins non fonctionnels (techniques) et livrer une liste

des exigences. Le modèle de cas d'utilisation présente le système du point de vue de l'utilisateur et représente sous forme de cas d'utilisation et d'acteur, les besoins du client.

1111....5555....2222 Analyse des besoinsAnalyse des besoinsAnalyse des besoinsAnalyse des besoins L'objectif de l'analyse est d'accéder à une compréhension des besoins et des exigences du client. Il s'agit de livrer des spécifications pour permettre de choisir la conception de la solution. Un modèle d'analyse livre une spécification complète des besoins issus des cas d'utilisation et les structures sous une forme qui facilite la compréhension (scénarios), la préparation (définition de l'architecture), la modification et la maintenance du futur système. Il s'écrit dans le langage des développeurs et peut être considéré comme une première ébauche du modèle de conception.

1111....5555....3333 ConceptionConceptionConceptionConception La conception permet d’acquérir une compréhension approfondie des contraintes liées au langage de programmation, à l'utilisation des composants et au système d'exploitation. Elle détermine les principales interfaces et les transcrit à l'aide d'une notation commune. Elle constitue un point de départ à l'implémentation :

� elle décompose le travail d'implémentation en sous-systèmes ; � elle créée une abstraction transparente de l'implémentation ;


1111....5555....4444 ImplémentationImplémentationImplémentationImplémentation L'implémentation est le résultat de la conception pour implémenter le système sous formes de composants, c'est-à-dire, de code source, de scripts, de binaires, d'exécutables et d'autres éléments du même type. Les objectifs principaux de l'implémentation sont de planifier les intégrations des composants pour chaque itération, et de produire les classes et les sous-systèmes sous formes de codes sources.

1111....5555....5555 TestTestTestTest Les tests permettent de vérifier des résultats de l'implémentation en testant la construction. Pour mener à bien ces tests, il faut les planifier pour chaque itération, les implémenter en créant des cas de tests, effectuer ces tests et prendre en compte le résultat de chacun.

1111....6666 Avantages d’un processus itératif contrôléAvantages d’un processus itératif contrôléAvantages d’un processus itératif contrôléAvantages d’un processus itératif contrôlé On peut citer quelques avantages :

1. Permet de limiter les coûts, en termes de risques, aux strictes dépenses liées à une itération.

2. Permet de limiter les risques de retard de mise sur le marché du produit développé (identification des problèmes dès les premiers stades de développement et non en phase de test comme avec l’approche « classique »).

3. Permet d’accélérer le rythme de développement grâce à des objectifs clairs et à court terme.

4. Permet de prendre en compte le fait que les besoins des utilisateurs et les exigences correspondantes ne peuvent être intégralement définis à l’avance et se dégagent peu à peu des itérations successives.

1111....7777 ConclusionConclusionConclusionConclusion

Le Processus Unifié UP répond bien à ces exigences. C’est un processus de développement moderne, itératif, efficace sur des projets informatique de toutes tailles. Très complet, il couvre l’ensemble des activités, depuis la conception du projet jusqu’à la livraison de solution.


Langage Langage Langage Langage

De De De De

ModélisationModélisationModélisationModélisation

- UMLUMLUMLUML ----

10 Chapitre IIChapitre IIChapitre IIChapitre II : Le : Le : Le : Le Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation UMLUMLUMLUML


Le recours à la modélisation est depuis longtemps une pratique indispensable au développement logiciel, car un modèle est prévu pour arriver à anticiper les résultats du codage. Un modèle est en effet une représentation abstraite d’un système destiné à en faciliter l’étude et à le documenter. C’est un outil majeur de communication entre les différents intervenants au sein d’un projet. Chaque membre de l’équipe, depuis l’utilisateur jusqu’au développeur, utilise et enrichit le modèle différemment. En outre, les systèmes devenant de plus en plus complexes, leur compréhension et leur maîtrise globale dépassent les capacités d’un seul individu. La construction d’un modèle abstrait aide à y remédier. Le modèle présente notamment l’atout de faciliter la traçabilité du système, à savoir la possibilité de partir d’un de ses éléments et de suivre ses interactions et liens avec d’autres parties du modèle.

2222....2222 La Programmation Orientée OLa Programmation Orientée OLa Programmation Orientée OLa Programmation Orientée Objetbjetbjetbjet La Programmation Orientée Objet (P.O.O) Contribue à la fiabilité des

logiciels et elle facilite la réutilisation de code existant. Elle introduit de nouveaux concepts, en particulier ceux d’objets, d’encapsulation, de classe et d’héritage.

2222....2222....1111 Le conceLe conceLe conceLe concept d’objetpt d’objetpt d’objetpt d’objet En P.O.O., un programme met en œuvre différents objets. Chaque objet associe des données et des méthodes agissant exclusivement sur les données de l’objet. Cela signifie qu’il n’est pas possible d’agir directement sur les données d’un objet ; il est nécessaire de passer par ses méthodes, qui jouent ainsi le rôle d’interface obligatoire. On disant que l’appel d’une méthode est fait l’envoi d’un message à l’objet.

2222....2222....2222 Le concept d’encapsulationLe concept d’encapsulationLe concept d’encapsulationLe concept d’encapsulation Vu de l’extérieur, un objet se caractérise uniquement par les spécifications de ses méthodes (abstraction des données). L’encapsulation facilite considérablement la maintenance : une modification éventuelle de la structure des données d’un objet n’a d’incidence que sur l’objet lui-même. De la même manière, l’encapsulation des données facilite grandement la réutilisation d’un objet.

2222....2222....3333 Le concept de classeLe concept de classeLe concept de classeLe concept de classe Une classe n’est rien d’autre que la description d’un ensemble d’objets ayant une structure de données commune et disposant des mêmes méthodes. Les objets apparaissent alors comme des variables d’un tel type classe (on dit instance de sa classe). Seule la structure est commune, les valeurs des champs étant propres à chaque objet, les méthodes sont effectivement communes à l’ensemble des objets d’une même classe.


2222....2222....4444 L’héritageL’héritageL’héritageL’héritage Il permet de définir une nouvelle classe à partir d’une classe existante, à laquelle on ajoute de nouvelles données et de nouvelles méthodes l’héritage facilite largement la réutilisation de produits existants, d’autant plus qu’il peut être réitéré autant de fois que nécessaire. Certains langages, tels C++, offrent la possibilité d’un héritage multiple : une même classe peut hériter simultanément de plusieurs autres.

2222....2222....5555 Le polymorphismeLe polymorphismeLe polymorphismeLe polymorphisme Une classe peut "redéfinir" (modifier) certaines des méthodes héritées de sa classe de base, la possibilité de traiter de la même manière des objets de types différents, pour peu qu’ils soient issus de classes dérivées d’une même classe de base. Le polymorphisme permet d’ajouter de nouveaux objets dans un scénario préétabli et éventuellement, écrit avant d’avoir connaissance du type exact de ces objets.

2222....3333 HistoriqueHistoriqueHistoriqueHistorique 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. 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.

• OOD de Grady Booch, définie pour le « Department of Defense », introduit le concept de paquetage (package).

• 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 É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. 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ée 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 (Object Management Group). 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 à la fin 2006 est UML 2.0 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.

2222....4444 DéfinitioDéfinitioDéfinitioDéfinition n n n UML «langage de modélisation unifié» se définit comme un langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue.

2222....5555 Principes de mise en œuvre d’UMLPrincipes de mise en œuvre d’UMLPrincipes de mise en œuvre d’UMLPrincipes de mise en œuvre d’UML UML unifie à la fois les notations et les concepts orientés objet. Il ne s’agit pas d’une simple notation graphique, car les concepts transmis par un diagramme ont une sémantique précise et sont porteurs de sens au même titre que les mots d’un langage. UML unifie également les notations nécessaires aux différentes activités d’un processus de développement et offre, par ce biais, le moyen d’établir le suivi des décisions prises, depuis l’expression de besoin jusqu’au codage. Dans ce cadre, un concept appartenant aux exigences des utilisateurs projette sa réalité dans le modèle de conception et dans le codage. Il permet de :

• Modéliser les objets et Visualiser chaque symbole graphique à une sémantique.

• Représenter les applications sous forme de diagramme. • Spécifier de manière précise et complète, sans ambiguïté. • Construire les classes, les relations SQL peuvent être générées

automatiquement. • Documenter les différents diagrammes, notes, contraintes, exigences

seront présentées dans un document.


2222....5555....1111 Les avantages d’UMLLes avantages d’UMLLes avantages d’UMLLes avantages d’UML On peut citer quelques avantages d’UML :

• Un gain de précision ; • Un gage de stabilité ; • UML est un support de communication performant ; • Il cadre l'analyse et facilite la compréhension de représentations

abstraites complexes ; • Son caractère polyvalent et sa souplesse en font un langage

universel ;

2222....5555....2222 Les inconvénients d’UMLLes inconvénients d’UMLLes inconvénients d’UMLLes inconvénients d’UML La mise en pratique d'UML nécessite un apprentissage assez long

et rigoureux qui peut être également un frein à son utilisation. La lourdeur relative de sa mise en place au sein de n'importe quel processus.

2222....6666 Les diagrammes d’UML Les diagrammes d’UML Les diagrammes d’UML Les diagrammes d’UML UML 2 s’articule autour de treize types de diagrammes, chacun d’eux étant dédié à la représentation des concepts particuliers d’un système logiciel. Ces types de diagrammes sont répartis en deux grands groupes : • Six diagrammes structurels :

• Diagramme de classes : il montre les briques de base statiques : classes, associations, interfaces, attributs, opérations, généralisations.

• Diagramme d’objets : il montre les instances des éléments structurels et leurs liens à l’exécution.

• Diagramme de packages : il montre l’organisation logique du modèle et les relations entre packages.

• Diagramme de structure composite : il montre l’organisation interne d’un élément statique complexe.

• Diagramme de composants : il montre des structures complexes, avec leurs interfaces fournies et requises.

• Diagramme de déploiement : il montre le déploiement physique des «artefacts » sur les ressources matérielles.

• Sept diagrammes comportementaux :

• Diagramme de cas d’utilisation : il montre les interactions fonctionnelles entre les acteurs et le système à l’étude.

• Diagramme de vue d’ensemble des interactions : il fusionne les diagrammes d’activité et de séquence pour combiner des fragments d’interaction avec des décisions et des flots.

• Diagramme de séquence : il montre la séquence verticale des messages passés entre objets au sein d’une interaction.

• Diagramme de communication : il montre la communication entre objets dans le plan au sein d’une interaction.

• Diagramme de temp

séquence pour montrer l’évolution de l’état d’un objet au cours du• Diagramme d’activité

décisions au sein d’une activité.• Diagramme d’état

possibles des objets d’une classe.

2222....6666....1111 MMMModélisation statiqueodélisation statiqueodélisation statiqueodélisation statique2222....6666....1111....1111 Diagramme de classeDiagramme de classeDiagramme de classeDiagramme de classe

Le diagramme de classesdans toutes les méthodes orientées objet. C’est celui que les outils de génération automatique de code utilisent en priorité. C’est également celui qui contient la plus grande gamme de notations et de varianted’utiliser correctement tous ces concepts.

Une classe : représente la description abstraite dpossédant les mêmes caractUn objet est une entitencapsulant un état et un comportement. Un objet est une instance (ou occurrence) d’une classe.Exemples : la classe Voiture, la classe Personne.

Un attribut : représente un type dExemples : vitesse courante, cylindrattributs de la classe Voiture.Une opération représente un dans une classe.

Une association : reprclasses. Exemple : une personne peut possassociation entre les classes Personne et Voiture. Une association semble privilconcepts dans un modèDonc implicitement, l’exemple prest possédée par une personne.

Figure

Une agrégation : est un cas particulier dexprimant ne relation nommées : implicitement

Chapitre IIChapitre IIChapitre IIChapitre II : Le : Le : Le : Le Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation

Diagramme de temps : il fusionne les diagrammes d’états et deséquence pour montrer l’évolution de l’état d’un objet au cours du

d’activité : il montre l’enchaînement des actions etdécisions au sein d’une activité. Diagramme d’états : il montre les différents états et transitionspossibles des objets d’une classe.

odélisation statiqueodélisation statiqueodélisation statiqueodélisation statique Diagramme de classeDiagramme de classeDiagramme de classeDiagramme de classessss

Le diagramme de classes a toujours été le diagramme le plus important dans toutes les méthodes orientées objet. C’est celui que les outils de génération automatique de code utilisent en priorité. C’est également celui qui contient la plus grande gamme de notations et de variantes, d’où la difficulté d’utiliser correctement tous ces concepts.

sente la description abstraite d’un ensemble dmes caractéristiques. On peut parler également de type.

é aux frontières bien définies, possédant une identittat et un comportement. Un objet est une instance (ou

une classe. Exemples : la classe Voiture, la classe Personne.

sente un type d’information contenu dans une classe.Exemples : vitesse courante, cylindrée, numéro d’immatriculation, etc. sont des

de la classe Voiture. sente un élément de comportement (un service) contenu

représente une relation sémantique durable entre deux

Exemple : une personne peut posséder des voitures. La relationentre les classes Personne et Voiture.

ne association semble privilégier un sens de lecture, une association entre èle du domaine est par défaut bidirectionnelle.exemple précédent inclut également le fait qu

e par une personne.

Figure 2-1 : exemple d’association

est un cas particulier d’association de contenance. Les agrégations n’ont pas besoin d

es : implicitement elles signifient « contient », « est compos

14 Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation UMLUMLUMLUML

l fusionne les diagrammes d’états et de séquence pour montrer l’évolution de l’état d’un objet au cours du temps.

l montre l’enchaînement des actions et

l montre les différents états et transitions

a toujours été le diagramme le plus important dans toutes les méthodes orientées objet. C’est celui que les outils de génération automatique de code utilisent en priorité. C’est également celui qui

s, d’où la difficulté

un ensemble d’objets galement de type.

dant une identité et tat et un comportement. Un objet est une instance (ou

information contenu dans une classe. immatriculation, etc. sont des

ment de comportement (un service) contenu

durable entre deux

der des voitures. La relation possède est une

lecture, une association entre faut bidirectionnelle. galement le fait qu’une voiture

non symétrique ont pas besoin d’être

est composé de ».

Une composition : est une agr• un élément ne peut non partagée) ; • la destruction de l’éléments.

Figure 2

Une généralisation :

Une super-classe : est autres classes plus généralisation.

Les sous-classes

peuvent comporter des propri-Exemple : les voitures, les bateaux et les avions sont des moyens de transport. Ils possèdent tous une marque, un modles bateaux ont un tirant d

Figure

Une classe abstraite

qui représente une pure abstraction afin de factoriser des propricommunes. Elle se note enl’exemple précédent. Le diagramme de classes met en des opérations, et relié


est une agrégation plus forte impliquant que :ment ne peut appartenir qu’à un seul agrégat composite (agr

’agrégat composite entraîne la destruction de tous ses

2-2 : exemple d’agrégation et de composition

:

est une classe plus générale reliée à spécialisées (sous-classes) par une relation de

classes « héritent » des propriétés de leur superpeuvent comporter des propriétés spécifiques supplémentaires.Exemple : les voitures, les bateaux et les avions sont des moyens de transport.

dent tous une marque, un modèle, une vitesse, etc. Par contre, seuls les bateaux ont un tirant d’eau et seuls les avions ont une altitude

Figure 2-3 : exemple de généralisation

Une classe abstraite : est une classe qui ne s’instancie pas directement mais

sente une pure abstraction afin de factoriser des proprinote en italique. C’est le cas de Moyen de Transport

Le diagramme de classes met en œuvre des classes, contenant des attributs et ées par des associations ou des généralisations.


gation plus forte impliquant que : gat composite (agrégation

ne la destruction de tous ses

exemple d’agrégation et de composition

une ou plusieurs classes) par une relation de

s de leur super-classe et mentaires.

Exemple : les voitures, les bateaux et les avions sont des moyens de transport. le, une vitesse, etc. Par contre, seuls

eau et seuls les avions ont une altitude…

instancie pas directement mais sente une pure abstraction afin de factoriser des propriétés

Moyen de Transport dans

des classes, contenant des attributs et ralisations.


Figure 2-4 : exemple d’un diagramme de classe

2222....6666....1111....2222 Diagramme d’objetsDiagramme d’objetsDiagramme d’objetsDiagramme d’objets

Il montre les instances des éléments structurels et leurs liens à l’exécution, est une photo d’un sous-ensemble des objets d’un système à un certain moment du temps. La fig.2-5 illustre un exemple simple d’un diagramme d’objet.

Figure 2-5 : exemple d’un diagramme d’objet

2222....6666....1111....3333 Diagramme de déploiement Diagramme de déploiement Diagramme de déploiement Diagramme de déploiement

Le diagramme de déploiement montre la configuration physique des différents matériels qui participent à l’exécution du système, ainsi que les artefacts qu’ils supportent. Ce diagramme est constitué de « nœuds » connectés par des liens physiques. Les symboles des nœuds peuvent contenir des artéfacts. La fig.2-6 illustre un exemple simple d’un diagramme de déploiement.

Figure 2-

2222....6666....1111....4444 Diagramme deDiagramme deDiagramme deDiagramme de Il montre l’organisation logique du modèle et les relations entre

packages. Il permet de structurer les classes d’analyse et de conception, mais aussi les cas d’utilisation.

Package : mécanisme gprincipalement utiliséclasses et des associations.La structuration d’un modElle doit s’appuyer indépendance. Le premier principe consiste de vue sémantique. Un critdes instances de concept et s’efforce de minimiser lesLa fig.2-7 illustre un exemple simple d’un diagramme de packages

Figure 2


-6 : exemple d’un diagramme de déploiement

Diagramme deDiagramme deDiagramme deDiagramme de packagespackagespackagespackages Il montre l’organisation logique du modèle et les relations entre

Il permet de structurer les classes d’analyse et de conception, mais aussi les cas d’utilisation.

canisme général de regroupement d’éléments en UML, qui est é en analyse et conception objet pour regrouper des

classes et des associations. un modèle en packages est une activité délicate. sur deux principes fondamentaux :

Le premier principe consiste à regrouper les classes qui sont proches dmantique. Un critère intéressant consiste à évaluer les dur

concept et à rechercher l’homogénéité. Le deuximinimiser les relations entre packages. illustre un exemple simple d’un diagramme de packages

2-7 : exemple d’un diagramme de packages


exemple d’un diagramme de déploiement

Il montre l’organisation logique du modèle et les relations entre Il permet de structurer les classes d’analyse et de conception, mais

ments en UML, qui est en analyse et conception objet pour regrouper des

licate. sur deux principes fondamentaux : cohérence et

regrouper les classes qui sont proches d’un point valuer les durées de vie . Le deuxième principe

illustre un exemple simple d’un diagramme de packages

exemple d’un diagramme de packages


2222....6666....1111....5555 Diagramme deDiagramme deDiagramme deDiagramme de composantcomposantcomposantcomposantssss Il montre des structures complexes, les unités logicielles à partir desquelles

on a construit le système informatique, ainsi que leurs dépendances. La fig.2-8 illustre un exemple simple d’un diagramme de composants.

Figure 2-8 : exemple d’un diagramme de composants

2222....6666....2222 Modélisation dynamiqueModélisation dynamiqueModélisation dynamiqueModélisation dynamique

2222....6666....2222....1111 Diagramme deDiagramme deDiagramme deDiagramme de Il montre les interactions fonctionnellesl’étude. Utilisé dans l’activité Un acteur : représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel système étudié, il peut consulter et/ou modifier directement l’état du système, en émettant et/ou en recevant des messages susceptibles d’être porteurs de données. Un cas d’utilisation

d’actions qui sont réalisées par le système et qui produisent un résultat observable intéressant pour un acteur particulier. Chaque cas d’utilisation spécifie un comportement attendu du système considéré comme un tout, sanscomportement. Il permet de décrire spécifier comment il le fera.La fig.2-9 illustre un exemple simple d’un diagramme

Figure 2-9

2222....6666....2222....2222 Diagramme de séquencDiagramme de séquencDiagramme de séquencDiagramme de séquenc

Il montre la séquence verticale des messagesd’une interaction. Est un échanges de messages entre éléments, dans le cadreparticulier du système. Les diagrammes dedévelopper en analyse les scénarios d’utilisationLa fig.2-10 illustre un exemple simple d’un diagramme


Modélisation dynamiqueModélisation dynamiqueModélisation dynamiqueModélisation dynamique

Diagramme deDiagramme deDiagramme deDiagramme de cas cas cas cas d’utilisationd’utilisationd’utilisationd’utilisation Il montre les interactions fonctionnelles entre les acteurs et le système à tilisé dans l’activité de spécification des besoins.

représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le

peut consulter et/ou modifier directement l’état du système, en émettant et/ou en recevant des messages susceptibles d’être porteurs de

Un cas d’utilisation (« use case ») représente un ensemble de séquences d’actions qui sont réalisées par le système et qui produisent un résultat observable intéressant pour un acteur particulier. Chaque cas d’utilisation spécifie un comportement attendu du système considéré comme un tout, sans imposer le mode de réalisation de ce comportement. Il permet de décrire ce que le futur système devra faire, sans

il le fera. illustre un exemple simple d’un diagramme de case d’utilisation.

9 : exemple d’un diagramme cas d’utilisation

Diagramme de séquencDiagramme de séquencDiagramme de séquencDiagramme de séquenceeee Il montre la séquence verticale des messages passés entre objets au sein

. Est un diagramme d’interactions UML. Ils représentent des échanges de messages entre éléments, dans le cadre d’un fonctionnement particulier du système. Les diagrammes de séquence servent d’abord à développer en analyse les scénarios d’utilisation du système.

10 illustre un exemple simple d’un diagramme de séquence


entre les acteurs et le système à

représente un rôle joué par une entité externe (utilisateur ou autre système) qui interagit directement avec le

peut consulter et/ou modifier directement l’état du système, en émettant et/ou en recevant des messages susceptibles d’être porteurs de

ésente un ensemble de séquences d’actions qui sont réalisées par le système et qui produisent un résultat

Chaque cas d’utilisation spécifie un comportement attendu du système imposer le mode de réalisation de ce

le futur système devra faire, sans

de case d’utilisation.

diagramme cas d’utilisation

passés entre objets au sein Ils représentent des d’un fonctionnement

séquence servent d’abord à

de séquence.

Figure 2

2222....6666....2222....3333 Diagramme d’activitéDiagramme d’activitéDiagramme d’activitéDiagramme d’activité Un diagramme d'activité permet de modéliser un processus interactif, global ou partiel pour un système donné (logiciel, système informatique). Il est recommandable pour exprimer une dimension temporelle sur une partie du modèle, à partir de diagramme de cl Le diagramme d'activités est une représentation proche de l'organigramme ; la description d'un cas d'utilisation par un diagramme d'activités correspond à sa traduction algorithmique. Une activité est l'exécution d'une partie du cas d'utilisation, elle est représentée par un rectangle aux bords arrondis.

Figure


2-10 : exemple d’un diagramme de séquence

Diagramme d’activitéDiagramme d’activitéDiagramme d’activitéDiagramme d’activité Un diagramme d'activité permet de modéliser un processus interactif,

global ou partiel pour un système donné (logiciel, système informatique). Il est recommandable pour exprimer une dimension temporelle sur une partie du modèle, à partir de diagramme de classe ou de cas d’utilisation, par exemple.

Le diagramme d'activités est une représentation proche de l'organigramme ; la description d'un cas d'utilisation par un diagramme d'activités correspond à sa traduction algorithmique. Une activité est

n d'une partie du cas d'utilisation, elle est représentée par un rectangle aux bords arrondis.

Figure 2-11 : exemple d’un diagramme d’activité


séquence

Un diagramme d'activité permet de modéliser un processus interactif, global ou partiel pour un système donné (logiciel, système informatique). Il est recommandable pour exprimer une dimension temporelle sur une partie du

asse ou de cas d’utilisation, par exemple. Le diagramme d'activités est une représentation proche de

l'organigramme ; la description d'un cas d'utilisation par un diagramme d'activités correspond à sa traduction algorithmique. Une activité est

n d'une partie du cas d'utilisation, elle est représentée par un

exemple d’un diagramme d’activité


2222....6666....2222....4444 Diagramme d’étatsDiagramme d’étatsDiagramme d’étatsDiagramme d’états Il montre les différents états et transitions possibles des objets d’une

classe. Représente le cycle de vie commun aux objets d’une même classe.

Un éUn éUn éUn étattattattat :::: représente une situation durant la vie d’un objet pendant laquelle : • il satisfait une certaine condition ; • il exécute une certaine activité ; • ou bien il attend un certain événement. Un objet passe par une succession d’états durant son existence. Un état a une durée finie, variable selon la vie de l’objet, en particulier en fonction des événements qui lui arrivent. Une transitioUne transitioUne transitioUne transitionnnn : : : : décrit la réaction d’un objet lorsqu’un événement se produit (généralement l’objet change d’état). En règle générale, une transition possède un événement déclencheur, une condition de garde, un effet et un état cible. UUUUn événemenn événemenn événemenn événementttt : : : : spécifie qu’il s’est passé quelque chose de significatif, localisé dans le temps et dans l’espace. Dans le contexte des machines à états finis, il représente l’occurrence d’un stimulus qui peut déclencher une transition entre états. Un messagUn messagUn messagUn messageeee : : : : est une transmission d’information unidirectionnelle entre deux objets, l’objet émetteur et l’objet récepteur. Le mode de communication peut être synchrone ou asynchrone. La réception d’un message est un événement qui est doit être traité par le récepteur.

Une Une Une Une condition de gardecondition de gardecondition de gardecondition de garde :::: est une expression booléenne qui doit être vraie lorsque l’événement arrive pour que la transition soit déclenchée. Elle peut concerner les attributs de l’objet ainsi que les paramètres de l’événement déclencheur. Plusieurs transitions avec le même événement doivent avoir des conditions de garde différentes.

Figure 2-12 : exemple d’un diagramme d’état


L’ensemble des treize types de diagrammes UML peut ainsi être résumé sur la figure 2-13

Figure 2–13 : Les diagrammes UML utilisés.


UML est un langage de modélisation orienté objet le plus puissant, et le plus robuste pour une application informatique. Son indépendance du domaine d’application et des langages de programmation lui donne la puissance d’être adapté à n’importe quel domaine.


ConceptionConceptionConceptionConception

DuDuDuDu

L’applicationL’applicationL’applicationL’application

23 Chapitre IChapitre IChapitre IChapitre III II II II :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application


Dans la partie courante on présente toutes les fonctionnalités offertes

par le système par un diagramme de cas d'utilisation avec une démonstration,

pour chaque cas d'utilisation, par les scénarios d'exécution (scénario nominale,

scénario alternatif) ainsi après avoir déterminer le déroulement des différents

processus, on raffinera tous ces cas d'utilisation par des diagrammes de

séquences, modélisant les différentes interactions entre les acteurs

déclencheurs et le système, et des diagrammes d'activités, qui représentent

exactement le processus de la tâche courante, qui sont à la pour pouvoir bien

développer notre application.

3333....2222 Présentation du projetPrésentation du projetPrésentation du projetPrésentation du projet L’objectif de ce projet, est de développer une application de gestion des

projets en groupe, plusieurs utilisateurs séparés géographiquement peuvent

travailler d’une manière collaborative pour planifier un projet. Chaque action

d’un utilisateur sur son interface, va apparaitre immédiatement sur l’écran des

autres.

Pour cette application ya deux types d’utilisateurs. Chacun d’eux doit

s’authentifier en utilisant un mot de passe pour accéder au logiciel ;

Utilisateur simpleUtilisateur simpleUtilisateur simpleUtilisateur simple : est la personne qui participe à la planification d’un projet, et

qui à sa disposition les fonctionnalités suivantes :

• Ajouter une tâche au projet ;

• Supprimer une tâche du projet ;

• Modifier les données d’une tâche existante ;

• Enregistrer un projet ;

• Discuter avec les autres utilisateurs connectés par la messagerie

instantanée.

Chef de projetChef de projetChef de projetChef de projet : à sa disposition les mêmes fonctionnalités que l’utilisateur

simple, en plus la gestion des utilisateurs et la gestion des ressources :

• Ajouter un nouvel utilisateur ;

• Supprimer un utilisateur ;

• Ouvrir un projet.


3333....3333 Etude préliminaireEtude préliminaireEtude préliminaireEtude préliminaire

3333....3333....1111 Diagramme de cas d’utilisationDiagramme de cas d’utilisationDiagramme de cas d’utilisationDiagramme de cas d’utilisation Un diagramme de cas d’utilisation permet de modéliser le

fonctionnement d’un système par découpage en fonctionnalités. Il illustre de

plus la nature des interactions avec ces fonctionnalités offertes à titre de

services à des acteurs externes au système.

Un cas d’utilisation correspond à un certain nombre d’actions que le

système devra exécuter en réponse à un besoin d’un acteur. Un cas d’utilisation

doit produire un résultat observable pour un ou plusieurs acteurs ou parties

prenantes du système.

Le diagramme suivent regroupe les cas d’utilisation qui concernent

l’administrateur, chaque cas d’utilisation doit passer par le cas d’utilisation

« Authentifier », ce qui explique l’utilisation de la relation d’inclusion.

Figure 3-1 : Diagramme cas d’utilisation


3333....3333....2222 Fiches descriptivesFiches descriptivesFiches descriptivesFiches descriptives Une description textuelle couramment utilisé se compose de deux parties

La première partie permet d’identifier le cas, elle doit contenir les informations

tell que nom, objectif, Acteurs principaux et secondaires

La deuxième partie contient la description du fonctionnement du cas sous la

forme de séquence de messages échangés entre les acteurs et le système. Elle

contient une séquence nominale s’ajoutent fréquemment des séquences

alternatives (des embranchements dans la séquence nominale).

3333....3333....2222....1111 Fiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisation «««« s’s’s’s’aaaauthentifieruthentifieruthentifieruthentifier »»»» L’authentification consiste à vérifier l’identité de l’utilisateur avant de

lui donner l’accès à son espace de travail, l’identité est représentée par un login

et un mot de passe.

Ces informations associées à l’utilisateur sont préétablies dans une base de

données.

Cas d’utilisation N° 1 S’authentifier Résumé Vérification d’identités des utilisateurs Acteur Administrateur de l’application, client. Pré condition le serveur doit être lancé. Scenario nominal 1. Le système affiche le formulaire

d’authentification ; 2. L’utilisateur saisit son login et son mot de passe ; 3. Le système vérifie la conformité des informations fournies A1 ; 4. Le système donne l’accès à l’interface correspondante.

Scenario Alternative A1 les informations saisit sont incorrectes ; Le système réaffiche le formulaire d’authentification et attend que l’utilisateur ressaisisse ses informations.

Tableau 3-1 : Description du cas d’utilisation « s’authentifier ».


3333....3333....2222....2222 Fiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisation «««« ajouter tâcheajouter tâcheajouter tâcheajouter tâche »»»» Après l’authentification de l’utilisateur, il participe à la planification

d’un projet par l’ajout des tâches.

Cette fiche permet de décrire l’enchainement du cas « ajouter tâche »

Cas d’utilisation N° 2 Ajouter une tâche Résumé Ajouter une tâche dans le tableau. Acteur Administrateur du l’application, client. Pré condition le serveur doit être lancé. Scenario nominal 1. L’utilisateur choisir l’ajout d’une tâche ;

2. Le système donne la main pour saisit les informations de la tâche ; 3. L’utilisateur saisit les informations de la tâche A1; 4. Le système enregistre la tâche. 5. Le système envoie la tâche ajouté. 6. Le système affiche la tâche dans le tableau.

Scenario Alternative A1 Le champ nom de la tâche est vide ou existe déjà; Le système réaffiche le formulaire d’ajout pour que l’utilisateur ressaisisse ses informations.

Tableau 3-2 : Description du cas d’utilisation « Ajouter tâche ».

3333....3333....2222....3333 Fiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisation «««« modifier tâchemodifier tâchemodifier tâchemodifier tâche »»»» Cette fiche décrire l’enchainement du cas « modifier une tâche » déjà

existante.

Cas d’utilisation No 3 Modifier une tâche Résumé Modifier une tâche déjà enregistrée. Acteur Administrateur du l’application, client. Pré condition le serveur doit être lancé.

L’utilisateur sélectionne une tâche. Scenario nominal 1. L’utilisateur choisir la modification d’une

tâche ; 2. Le système donne la main pour modifier les informations de la tâche sélectionnée ; 3. L’utilisateur modifie les informations de la tâche A1; 4. Le système enregistre la modification de la tâche. 5. Le système envoie la tâche modifié. 6. Le système affiche la tâche modifie dans le tableau.

Scenario Alternative A1 Le champ nom de la tâche est vide ou existe déjà; Le système réaffiche le formulaire d’ajout pour que l’utilisateur ressaisisse ses informations.

Tableau 3-3 : Description du cas d’utilisation « Modifier tâche »


3333....3333....2222....4444 Fiche Fiche Fiche Fiche descriptive du cas d’utilisationdescriptive du cas d’utilisationdescriptive du cas d’utilisationdescriptive du cas d’utilisation «««« supprimsupprimsupprimsupprimer tâcheer tâcheer tâcheer tâche »»»» Cette fiche décrire l’enchainement du de la suppression d’une tâche déjà

existante.

Cas d’utilisation No 4 Supprimer une tâche Résumé Supprimer une tâche dans le tableau. Acteur Administrateur du l’application, client. Pré condition le serveur doit être lancé.

L’utilisateur sélectionne une tâche. Scenario nominal 1. L’utilisateur choisir la suppression d’une

tâche ; 2. Le système affiche un message de confirmation ; 3. L’utilisateur confirme la suppression A1; 4. Le système envoie le numéro de la tâche a supprimée. 5. Le système supprime la tâche de tableau.

Scenario Alternative A1 Le système annule la suppression. Le système reprendre l’étape 1.

Tableau 3-4 : Description du cas d’utilisation « Supprimer une tâche »

3333....3333....2222....5555 Fiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisation «««« envoyer message envoyer message envoyer message envoyer message »»»»

Cette fiche décrire l’enchainement du d’envoie d’un message privé ou

public.

Cas d’utilisation No 5 Envoyer un message Résumé Envoyer un message aux utilisateurs. Acteur Administrateur du l’application, client. Pré condition le serveur doit être lancé. Scenario nominal 1. L’utilisateur tape un message A1;

2. Le système affiche le message dans la zone des messages; 3. Le système diffus le message à tous les utilisateurs connectés;

Scenario Alternative A1 L’utilisateur sélectionne un autre utilisateur connecté. Le système envoie le message à l’utilisateur sélectionné.

Tableau 3-5 : Description du cas d’utilisation « Envoyer un message »


3333....3333....2222....6666 Fiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisation «««« ajouter clientajouter clientajouter clientajouter client »»»» Cette fiche décrire l’enchainement du l’ajout d’un client qui va participer

à la planification d’un projet.

C’est le chef du projet qu’à l’autorisation d’ajouter des nouveaux clients, il

affecte à eux un pseudonyme et un mot de passe.

Cas d’utilisation No 6 Ajouter un client Résumé Ajouter un client dans la base de données. Acteur Administrateur du l’application. Pré condition le serveur doit être lancé.

La base de données doit être crée. Scenario nominal 1. L’administrateur choisir l’ajout d’un

client ; 2. Le système donne la main pour saisit les informations de client ; 3. L’administrateur saisit les informations de client E1; 4. Le système établir une connexion avec la base de données ; 5. Le système enregistre le client dans la base de données ;

Scenario Alternative E1 Le champ nom et le mot de passe de client est vide ou le nom existe déjà. Le système réaffiche le formulaire d’ajout pour que l’administrateur ressaisisse ses informations.

Tableau 3-6 : Description du cas d’utilisation «Ajouter un client »

3333....3333....2222....7777 Fiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisation «««« modifiemodifiemodifiemodifier client »r client »r client »r client » Cette fiche décrire l’enchainement de la modification des informations

(pseudonyme et mot de passe) d’un client déjà existant.

Cas d’utilisation No 7 Modifier un client Résumé Modifier un client dans la base de données. Acteur Administrateur du l’application. Pré condition le serveur doit être lancé.

La base de données doit être crée. L’administrateur sélectionne un client.

Scenario nominal 1. L’administrateur choisir la modification d’un client; 2. Le système donne la main pour modifier les informations de client; 3. L’administrateur saisit les informations de client E1; 4. Le système établir une connexion avec la base de données ;


5. Le système enregistre les modifications de client dans la base de données ;

Scenario Alternative E1 Le champ nom et le mot de passe de client est vide ou le nom existe déjà. Le système réaffiche le formulaire d’ajout pour que l’administrateur ressaisisse ses informations.

Tableau 3-7 : Description du cas d’utilisation «Modifier un client»

3333....3333....2222....8888 Fiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisationFiche descriptive du cas d’utilisation «««« supprimsupprimsupprimsupprimer client »er client »er client »er client » Cette fiche décrire l’enchainement de la suppression d’un client de la

base de donnée. Cas d’utilisation No 8 Supprimer un client Résumé Supprimer un client dans la base de

données. Acteur Administrateur du l’application. Pré condition le serveur doit être lancé.

La base de données doit être crée. L’administrateur sélectionne un client.

Scenario nominal 1. L’administrateur choisir la suppression d’un client; 2. Le système affiche un message de confirmation ; 3. L’utilisateur confirme la suppression A1; 4. Le système établir une connexion avec la base de données ; 5. Le système supprime le client dans la base de données ;

Scenario Alternative A1 Le système annule la suppression. Le système reprendre l’étape 1.

Tableau 3-8 : Description du cas d’utilisation «Supprimer un client»


3333....4444 Diagrammes d’activitéDiagrammes d’activitéDiagrammes d’activitéDiagrammes d’activité Dans cette partie on décrit pour chaque cas d’utilisation par un

diagramme d’activité.

Ce diagramme décrire l’enchainement de la vérification l’identité de

l’utilisateur avant de lui donner l’accès à son espace de travail.

Figure 3-2 : Diagramme d’activité « S’authentifier ».


Après l’authentification le chef du projet peut ajouter des nouveaux

clients participant à la planification du projet d’après l’enchainement suivant :

Figure 3-3 : Diagramme d’activité « Ajouter client ».


Ce diagramme décrire l’ensemble des actions pour modifier une tâche

Figure 3-4 : Diagramme d’activité « Modifier une tâche ».


Ce diagramme décrire le cas de la suppression d’une tâche

Figure 3-5 : Diagramme d’activité « Supprimer une tâche».


Ce diagramme décrire l’enchainement d’action pour envoyer un message privé

ou public :

Figure 3-6 : Diagramme d’activité « Envoyer message».


3333....5555 Diagrammes de séquenceDiagrammes de séquenceDiagrammes de séquenceDiagrammes de séquence L’objectif du diagramme de séquence est de représenter les interactions

entre objets en indiquant la chronologie des échanges. Cette représentation

peut se réaliser par un cas d’utilisation en considérant les différents scénarios

associés.

Figure 3-7 : Diagramme séquence « S’authentifier ».


Le chef du projet peut ajouter des nouveaux clients participant à la

planification du projet suivent l’enchainement suivant :

Figure 3-8 : Diagramme séquence « Ajouter client ».


Ce diagramme décrit l’enchainement d’exécution du cas « modifier une tâche »

Figure 3-9 : Diagramme séquence « Modifier une tâche ».


Ce diagramme décrit l’enchainement d’exécution du cas « supprimer une

tâche »

Figure 3-10 : Diagramme séquence « Supprimer une tâche ».


Ce diagramme décrit l’enchainement d’exécution du cas « Envoyer message »

Figure 3-11 : Diagramme séquence « Envoyer message ».


3333....6666 Diagrammes de classe Diagrammes de classe Diagrammes de classe Diagrammes de classe (côté serveur)

Figure 3-12 : Diagramme de classe.

♣ La classe ThreadClient utilise la fenêtre pour afficher les objets reçus et appelle la classe GestionClient pour les diffusés ;

♣ La classe fenêtre appelle la classe GestionBaseDonnee pour

ajouter,modifier ou supprimer un client ;

♣ La vérification l’identité du client ce fait en passant par l’administrateur

pour contacter la classe GestionBaseDonnee ;

♣ Les types d’objet à envoyer sont multiples : messages, ressources, tâches,

ou même un fichier.


3333....7777 Diagrammes de déploiementDiagrammes de déploiementDiagrammes de déploiementDiagrammes de déploiement Ce diagramme décrire l’implantation physique de notre application

Figure 3-13 : Diagramme déploiement.


En adoptant une conception orienté objet basée sur la méthode UP, on a

pu modéliser notre application et déduire le modèle relationnel qui constitue la

base de données pour la réalisation de notre application.

Le chapitre suivant, quant à lui, sera consacré à la phase de développement de

notre application et qui se réalisera en détaillant les différentes interfaces qui

le composent.


RéalisationRéalisationRéalisationRéalisation

DuDuDuDu

L’applicationL’applicationL’applicationL’application

42 Chapitre IChapitre IChapitre IChapitre IVVVV :::: RéalisationRéalisationRéalisationRéalisation du l’applicationdu l’applicationdu l’applicationdu l’application


Après avoir réalisé la conception appropriée à notre projet, nous allons

dans ce chapitre décrire le processus de réalisation de notre application. Ceci

en spécifiant l’environnement de développement, l’implémentation de la base

de données et un aperçu sur les interfaces de notre application.

4444....2222 Les Les Les Les technologies utiliséestechnologies utiliséestechnologies utiliséestechnologies utilisées

4444....2222....1111 Langage de programmationLangage de programmationLangage de programmationLangage de programmation JAVAJAVAJAVAJAVA JAVA est un langage objet ressemblant au langage C++. Il a été mis au

point en 1991 par la firme Sun Microsystems.

Le but de JAVA à l'époque était de constituer un langage de programmation

pouvant être intégré dans les appareils électroménagers, afin de pouvoir les

contrôler et les rendre interactifs.

Etant donné que le langage C++ comportait trop de difficultés, « James

Gosling », un des acteurs du projet décida de créer un langage orienté objet

reprenant les caractéristiques principales du C++, en éliminant ses points

difficiles, et en le rendant moins encombrant et plus portable (il devait pouvoir

être intégré dans n'importe quel appareil...). Ainsi, ce langage fut baptisé dans

un premier temps Oak « Oak signifiant chêne ». Toutefois, puisque ce nom était

déjà utilisé, il fut rebaptisé JAVA en l'honneur de la boisson préférée des

programmeurs, c'est-à-dire le café, dont une partie de la production provient de

l'île Java.

La plateforme JAVA, uniquement software, est exécutée sur la plateforme du

système d’exploitation, La « Java Platform » est constituée par :

• La « Java Virtual Machine » (JVM).

• Des interfaces de programmation d’application (Java API).

Nos motivations pour utiliser java sont :

• JAVA est aujourd'hui un langage aussi rapide que le c++ pourvu qu'on

ne l'utilise pas pour une application très lourde (jeux en ligne, logiciel de

traitement d'image, encodage vidéo etc.) ;

• Java est organisée, il contient des classes bien conçu et bien reparties ;

• Java est connu et donc plus de chance de trouver des développeurs java

pour concevoir ou amélioré une application (grand communauté des

développeurs);

• Java est portable et Multiplateformes ;

• Java est gratuit.


4444....2222....2222 EnvironnementEnvironnementEnvironnementEnvironnement NNNNetbeansetbeansetbeansetbeans

NetBeans c’est l’outil Visuel qui nous permet une grande facilité de

développement, en prenant en charge des difficultés et des parties secondaires

de projet. En utilisant NetBeans nous concentrer facilement sur votre code.

Nos motivations pour utiliser Netbeans sont :

• Création graphique des fenêtres, panel... très facile ce qui nous permet

de ce concentrer que sur le code ;

• pas besoin d'installer tout un tas de plugins ;

• très riche en documentation et s'améliore avec le temps;

4444....2222....3333 SGBD utiliséSGBD utiliséSGBD utiliséSGBD utilisé On a utilisés MySQL pour la création et la manipulation de notre base

de données.

Les points forts de MySQL sont :

• Implémentation libre et populaire;

• Facile à mettre en œuvre;

• Rapide à apprendre;

• Support multiplateforme;

• fiable et rapide.

Ses principaux points faibles sont :

• Ne possède pas de mécanisme transactionnel dans ses versions ;

• N'implémente pas les références d'intégrité relationnelles ;

Notre base de données contient les tables suivantes :

Utilisateur (Nom-utilisateur, mot-de-passe) ;

Cette table est utilisé en vue de vérification de l’identité des utilisateurs pour

les autorisés à accéder à leurs espace de travail.

4444....3333 Fonctionnalités de l'applicationFonctionnalités de l'applicationFonctionnalités de l'applicationFonctionnalités de l'applicationDans cette partie on va présenter les interfaces

application.

4444....3333....1111 AuthentificationAuthentificationAuthentificationAuthentification

Cette vue représente l’interface de l’authentification

Figure 4

Chapitre IChapitre IChapitre IChapitre IVVVV :::: RéalisationRéalisationRéalisationRéalisation du l’applicationdu l’applicationdu l’applicationdu l’application

Fonctionnalités de l'applicationFonctionnalités de l'applicationFonctionnalités de l'applicationFonctionnalités de l'application Dans cette partie on va présenter les interfaces implémenté

AuthentificationAuthentificationAuthentificationAuthentification

représente l’interface de l’authentification d’un utilisateur

Figure 4-1 : Page d’authentification

1

2

3

44 du l’applicationdu l’applicationdu l’applicationdu l’application

implémentées de notre

d’un utilisateur.

1) Nom utilisateur

2) Mot de passe

3) Adresse IP du serveur

4444....3333....2222 Fenêtre principaleFenêtre principaleFenêtre principaleFenêtre principale

Cette vue représente l’interface

Figure 4

1


Fenêtre principaleFenêtre principaleFenêtre principaleFenêtre principale

Cette vue représente l’interface d’espace de travail du chef projet

Figure 4- 2: l’interface d’espace de travail.

1) Logo de l’application

2) Tableau des tâches

3) Gestionnaire des clients

4) Les utilisateurs connectés

5) L’outil du chat

6) Barre d’outils

2

3

6


du chef projet.

5

4

4444....3333....3333 Gestion des clientsGestion des clientsGestion des clientsGestion des clients Cette vue représente l’interface

fonctionnalité caractérise le chef de projet

Figure 4

4444....3333....4444 Gestion des Gestion des Gestion des Gestion des Cette vue représente l’interface du

modification et la suppression des ressources par

Figure 4


Gestion des clientsGestion des clientsGestion des clientsGestion des clients Cette vue représente l’interface de la gestion des

fonctionnalité caractérise le chef de projet.

Figure 4- 3 : l’interface du la gestion des clients.

Gestion des Gestion des Gestion des Gestion des ressourcesressourcesressourcesressources Cette vue représente l’interface du la gestion des ressources, l’ajout, la

modification et la suppression des ressources par le chef de projet.

Figure 4- 4 : l’interface du la gestion des ressources.

2

3

1

4

3

2

1


gestion des clients, cette

clients.

ressources, l’ajout, la

chef de projet.

ressources.

1) Liste des clients 2) Nom du client

3) Mot de passe

1) Liste des ressources 2) Nom du la ressource

3) Quantité 4) Le coût

4444....3333....5555 Ajouter une tâcheAjouter une tâcheAjouter une tâcheAjouter une tâche

Cette vue représente l’interface

Figure 4- 5 : l’interface d’ajout ou d’une modification d’une tâche.


Ajouter une tâcheAjouter une tâcheAjouter une tâcheAjouter une tâche

Cette vue représente l’interface d’ajout ou modification d’une tâche.

l’interface d’ajout ou d’une modification d’une tâche.

1) Nom de la tâche

2) Date 3) Date fin4) Durée calculé5) Ressource6) Ressource

1

2

3

4

5

6


d’ajout ou modification d’une tâche.

l’interface d’ajout ou d’une modification d’une tâche.

Nom de la tâche

Date début

Date fin

Durée calculée

Ressources du la tâche

Ressources disponibles

4444....3333....6666 Enregistrer / ouvrir un projetEnregistrer / ouvrir un projetEnregistrer / ouvrir un projetEnregistrer / ouvrir un projet Cette vue représente l’interface d’espace de travaille

fonctionnalité d’ouvrir un projet dédier seulement au chef projet et

d’enregistrer un projet dans un support externe par chef projet ou un client

simple.

Figure 4- 6

2


Enregistrer / ouvrir un projetEnregistrer / ouvrir un projetEnregistrer / ouvrir un projetEnregistrer / ouvrir un projet Cette vue représente l’interface d’espace de travaille



6 : l’interface d’ouvrir ou enregistrer un projet.

Ouvrir un projet

1 Enregistrer un projet


Cette vue représente l’interface d’espace de travaille illustre la



l’interface d’ouvrir ou enregistrer un projet.

Enregistrer un projet

4444....3333....7777 Diagramme de Diagramme de Diagramme de Diagramme de

Cette vue est la

diagramme de GANTT.

Figure 4


Diagramme de Diagramme de Diagramme de Diagramme de GANTTGANTTGANTTGANTT

est la représentation des tâches d’un projet

diagramme de GANTT.

Figure 4- 7 : l’interface d’un diagramme du GANTT


ation des tâches d’un projet par un

d’un diagramme du GANTT.


4444....4444 Technologies réseau utiliséesTechnologies réseau utiliséesTechnologies réseau utiliséesTechnologies réseau utilisées Notre application est un système distribué qui utilise l’architecture

client/serveur d’ou on distingue des postes clients qui sont les utilisateurs

collaborant à la réalisation du projet. Plus un serveur qui contrôle tous les

services offres par notre système. Qu’est le chef du projet.

Le client demande des services via une interface graphique, après la

demande, un message est envoyé au serveur à l’aide d’un socket.

Cette demande sera enregistrée auprès du serveur puis sera transférée au

client concerné.

4444....4444....1111 Les socketsLes socketsLes socketsLes sockets

Les sockets sont des flux de données, permettant à des machines locales

ou distantes de communiquer entre elles via des protocoles.

Les différents protocoles sont TCP qui est un protocole dit "connecté", et UDP

qui est un protocole dit "non connecté".

Les sockets servent à communiquer entre deux hôtes appelés

Client / Serveur à l'aide d'une adresse IP et d'un port que on appelle prise ; ces

sockets permettront de gérer des flux entrant et sortant afin d'assurer une

communication entre les deux (le client et le serveur), soit de manière fiable à

l'aide du protocole TCP/IP, soit non fiable mais plus rapide avec le protocole

UDP. Nous allons travailler avec le premier mode, le mode TCP/IP.

Côté serveur :

<code java> ServerSocket sersoc = new ServerSocket (numero_port) ; (1) while (true){ Socket soc = sersoc.accept(); (2) InputStream flux = soc.getInputStream (); (3) BufferedReader entree = new BufferedReader (new InputStreamReader (flux)) ; (4) }

(1) Créer un objet de type ServerSocket, pour que le serveur soit prêt à recevoir des informations, associé au numéro de port choisi ;

(2) On obtiendra une "socket" associée à l’objet sersoc, en utilisant la méthode accept() ;

(3) la méthode getInputStream de la classe Socket permettra d’obtenir un

flux de type InputStream associé à cette socket ; (4) lire classiquement des informations sur ce flux.


Côté client:

<code java> Socket soc = new Socket (hote, port) ; (1) OutputStream flux = soc.getOutputStream() ; (2) OutputStreamWriter sortie = new OutputStreamWriter (flux) ; (3) sortie.write("message à envoye au serveur \n"); (4) sortie.flush(); // forcer l'envoi de la ligne

(1) Pour pouvoir communiquer avec le serveur, le client créera un objet

de type Socket, associé à la fois à l’adresse IP du serveur (hôte) et au

numéro de port du service (port) ;

(2) Pour émettre sur cette socket, on lui associera un flux de type

OutputStream ;

(3) nous construirons sur cette socket un objet de type

OutputStreamWriter ; (4) écrire les lignes de texte à envoyer au serveur.

Le Principe de fonctionnement des sockets ce résume :

• Le serveur enregistre son service sous un numéro de port,

indiquant des clients qu'il accepte de faire buffériser à un instant

donné ;

• Le serveur se met en attente d'une connexion méthode «accept() »

de son instance ;

• Le client peut alors établir une connexion en demandant la

création d’un socket à destination du serveur pour le port sur

lequel le service a été enregistré ;

• Le serveur sort de son «accept()» et crée un canal de

communication avec le client ;

• Le client et le serveur peuvent alors utiliser des flux d’entrée et

des flux de sortie pour échanger les données.


4444....4444....1111....1111 Protocol Protocol Protocol Protocol TCP/IPTCP/IPTCP/IPTCP/IP

TCP/IP signifie «Transmission Control Protocol / Internet Protocol».

TCP/IP représente d'une certaine façon l'ensemble de règles de communication

sur internet et se base sur la notion adressage IP. Le fait de fournir

une adresse IP à chaque machine du réseau afin de pouvoir acheminer des

paquets de données.

Afin de pouvoir appliquer le modèle TCP/IP à n'importe quelles

machines, ce système de protocoles TCP/IP a été décomposé en plusieurs

modules effectuant chacun une tâche précise. C’est le modèle en couches.

Le modèle TCP/IP est très proche du modèle OSI (modèle comportant

7 couches) qui a été mis au point par l'organisation internationale des

standards (ISO) afin de normaliser les communications entre ordinateurs.

Le modèle TCP/IP, inspiré du modèle OSI, mais en contient uniquement quatre

couches :

Modèle TCP/IP Modèle OSI

Couche Application

Couche Application

Couche Présentation

Couche Session

Couche Transport (TCP) Couche Transport

Couche Internet (IP) Couche Réseau

Couche Accès réseau Couche Liaison données

Couche Physique

Tableau 4.1 : les couches de modèle TCP/IP

Les rôles des différentes couches sont les suivants :

• Couche Accès réseauCouche Accès réseauCouche Accès réseauCouche Accès réseau : elle spécifie la forme sous laquelle les données

doivent être acheminées quel que soit le type de réseau utilisé ;

• Couche InternetCouche InternetCouche InternetCouche Internet : elle est chargée de fournir le paquet de données

(datagramme) ;

• Couche TransportCouche TransportCouche TransportCouche Transport : elle assure l'acheminement des données, ainsi

que les mécanismes permettant de connaître l'état de la

transmission ;

• Couche ApplicationCouche ApplicationCouche ApplicationCouche Application : elle englobe les applications standard du

réseau (Telnet, SMTP, FTP, ...).


4444....4444....1111....2222 L’aspect Client/serveurL’aspect Client/serveurL’aspect Client/serveurL’aspect Client/serveur

L'architecture client/serveur désigne un mode de communication entre

plusieurs ordinateurs d'un réseau qui distingue un ou plusieurs postes clients

du serveur.

L'architecture caractérise les systèmes clients/serveurs pour lesquels le

client demande une ressource et le serveur la lui fournit, en utilisant ses

propres ressources. Cela signifie que le serveur ne fait pas appel à une autre

application afin de fournir une partie du service.

Un serveur peut être spécialisé en serveur d'applications, de fichiers, de

terminaux, ou encore de messagerie électronique. I est maître et à l'écoute, prêt

à répondre aux requêtes envoyées par des clients ;

Le client et le serveur doivent utiliser le même protocole de

communication. Un serveur est généralement capable de servir plusieurs

clients simultanément.

� Avantages par rapport aux architectures distribuéesAvantages par rapport aux architectures distribuéesAvantages par rapport aux architectures distribuéesAvantages par rapport aux architectures distribuées

• Toutes les données sont centralisées sur un seul serveur, ce qui simplifie les contrôles de sécurité et la mise à jour des données et des

logiciels ;

• Les technologies supportant l'architecture client/serveur sont plus matures que les autres.

� InconvénientsInconvénientsInconvénientsInconvénients

• Si trop de clients veulent communiquer avec le serveur au même

moment, ce dernier risque de ne pas supporter la charge (alors que les

réseaux P2P marchent mieux en ajoutant de nouveaux participants) ;

• Si le serveur n'est plus disponible, plus aucun des clients ne marche (le

réseau P2P continue à marcher, même si plusieurs participants

quittent le réseau).

• Le dialogue entre le client et le serveur se fait par échange de messages

plutôt que par mémoire partagée, il est réalisé par échange de deux

messages :

- Une requête (demande) du client pour l’exécution d’un service par

le serveur.

- Une réponse envoyée par le serveur et qui contient le résultat du

service.


4444....4444....2222 La sérialisationLa sérialisationLa sérialisationLa sérialisation

La sérialisation correspond au processus de conversion de l'état d'un

objet en un formulaire persistant ou transportable. Le complément de la

sérialisation est la désérialisation, qui convertit un flux de données en un

objet. Ces deux processus permettent de stocker et de transférer facilement des

données.

La sérialisation utilise l'interface Serializable et les classes

ObjectOutputStream et ObjectInputStream.

� Exemple d’applicationExemple d’applicationExemple d’applicationExemple d’application

<code java> import java.io.Serializable; import java.util.Vector; public class ObjetModifier implements Serializable { Vector v; // tâche int i; //numéro de ligne int port; //spécifier l’émetteur ObjetModifier() { } //le constructeur est obligatoire }

Cet exemple de notre application d’une classe sérialisable permet

d’instancier des objets de type « objetModifier » qui permet de modifier une

tâche existant dans le modèle des tâches puis transférer cet objet pour tous les

utilisateurs connectés.


La phase de réalisation est l’étape la plus importante dans le cycle de vie

de développement d’une application. Dans ce chapitre, nous avons présenté les

aspects pratiques liés à la réalisation de notre thème gestion de projet, à savoir

les outils de développement nécessaire. En dernier, nous avons illustré

quelques interfaces que comprend notre application.

55 Conclusion généraleConclusion généraleConclusion généraleConclusion générale

Conclusion généraleConclusion généraleConclusion généraleConclusion générale

Suite à cette étude on peut affirmer que ce projet a été avant tout

une synthèse de notions acquises durant les trois années précédentes

et permet d'acquérir de nouvelles connaissances.

Le présent travail nous a permis d'acquérir des connaissances

dans le domaine de la programmation réseau, et de conforter

nos connaissances en conception logicielle.

Après le passage par les différentes étapes de développement,

l'application a abouti à un logiciel fonctionnel qui répond globalement aux

critères imposés dans le domaine de gestion des projets.

Finalement, on souhaite que nos efforts donnent une vie à ce projet,

et nous espérons avoir réussi à répondre à vos attentes.

BibliographieBibliographieBibliographieBibliographie

♣ Pascal Roques, Les cahiers du programmeur UML2, Eyrolles,

2007,4ème édition.

♣ Pascal roques, UML 2 par la pratique, Eyrolles, 2006, 5ème édition.

♣ Claude Delannoy, Programmer en JAVA, Eyrolles, 2008,

5ème édition.

♣ Cyrille Herby, Apprenez à programmer en JAVA, Crolet, 2011.

Webographie ♣ http://www.devloppez.com ♣ http://www.siteduzero.com ♣ http://www.commentcamarche.net

Mémoire ♣ Licence académique « développement d’une application réseaux Client

Serveur sous Windows » par Mokhtari El Abidine ,UMC

année 2008/2009.

♣ Licence informatique« Conception et Réalisation d’un Site Web

Dynamique pour Commande en Ligne destiné à l’Entreprise SCS

(Soummam Computer System) » par Kehoul Université de Bejaia

année 2011/2013.

Engineering

Mémoire PEF application client server gestion des projet collaborative