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 desdesdesdes 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 desdesdesdes 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 ……………………………………………………………
ChapitreChapitreChapitreChapitre 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 ……………………………………………………………
ChapitreChapitreChapitreChapitre 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

1Introduction 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
---- UPUPUPUP ----

2Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde développementde développement UPUPUPUP
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.

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

Cette architecture (fonctionnelle, logique, matérielle, etc.) doit être modélisée
en UML et pas seulement documentée en texte.
1111....3333....3333CondCondCondConduit par les casuit par les casuit par les casuit 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....4444Piloté 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 :

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

1111....4444....2222La 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....3333La phase deLa phase deLa phase deLa 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

• 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....5555La 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.

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....1111ExpExpExpExpression 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....2222Analyse 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....3333ConceptionConceptionConceptionConception
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....4444Implé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....5555TestTestTestTest
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.

LangageLangageLangageLangage
DeDeDeDe
ModélisationModélisationModélisationModélisation
-UMLUMLUMLUML ----

10Chapitre 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....1111Le 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....2222Le 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....3333Le 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....4444L’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....5555Le 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éfinitionnnn
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....2222Les 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’UMLLes diagrammes d’UMLLes diagrammes d’UMLLes 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....1111MMMModélisation statiqueodélisation statiqueodélisation statiqueodélisation statique
2222....6666....1111....1111 Diagramme de classeDiagramme de classeDiagramme de classeDiagramme de classe
Le diagramme de classes
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 variante
d’utiliser correctement tous ces concepts.
Une classe : représente la description abstraite d
possédant les mêmes caract
Un objet est une entit
encapsulant 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 d
Exemples : vitesse courante, cylindr
attributs de la classe Voiture.
Une opération représente un
dans une classe.
Une association : repr
classes.
Exemple : une personne peut poss
association entre les classes Personne et Voiture.
Une association semble privil
concepts dans un modè
Donc implicitement, l’exemple pr
est possédée par une personne.
Figure
Une agrégation : est un cas particulier d
exprimant 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 de
séquence pour montrer l’évolution de l’état d’un objet au cours du
d’activité : il montre l’enchaînement des actions et
décisions au sein d’une activité.
Diagramme d’états : il montre les différents états et transitions
possibles 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
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 d
mes caractéristiques. On peut parler également de type.
é aux frontières bien définies, possédant une identit
tat 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 relation
entre 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
14Langage 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
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 mod
les bateaux ont un tirant d
Figure
Une classe abstraite
qui représente une pure abstraction afin de factoriser des propri
communes. Elle se note en
l’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 super
peuvent 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 propri
note 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éploiementDiagramme de déploiementDiagramme de déploiementDiagramme 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 g
principalement utilisé
classes et des associations.
La structuration d’un mod
Elle doit s’appuyer
indépendance.
Le premier principe consiste
de vue sémantique. Un crit
des instances de concept et
s’efforce de minimiser les
La 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 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 d
mantique. Un critère intéressant consiste à évaluer les dur
concept et à rechercher l’homogénéité. Le deuxi
minimiser 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 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....2222Modélisation dynamiqueModélisation dynamiqueModélisation dynamiqueModélisation dynamique
2222....6666....2222....1111 Diagramme deDiagramme deDiagramme deDiagramme de
Il montre les interactions fonctionnelles
l’é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, sans
comportement. 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 messages
d’une interaction. Est un
échanges de messages entre éléments, dans le cadre
particulier du système. Les diagrammes de
développer en analyse les scénarios d’utilisation
La fig.2-10 illustre un exemple simple d’un diagramme
Modélisation dynamiqueModélisation dynamiqueModélisation dynamiqueModélisation dynamique
Diagramme deDiagramme deDiagramme deDiagramme de cascascascas 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,
Un cas d’utilisation (« use case ») représente un ensemble de séquences
observable intéressant pour un acteur particulier.
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,
ésente un ensemble de séquences
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é
modèle, à partir de diagramme de classe ou de cas d’utilisation, par exemple.
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
asse ou de cas d’utilisation, par exemple.
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.
UneUneUneUne 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

23Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: 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.
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.
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 FicheFicheFicheFiche 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.
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 messageenvoyer messageenvoyer messageenvoyer 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.
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.
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à.
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.
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;
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à.
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.
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;
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 classeDiagrammes de classeDiagrammes de classeDiagrammes 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

42Chapitre 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 LesLesLesLes technologies utiliséestechnologies utiliséestechnologies utiliséestechnologies utilisées
4444....2222....1111Langage 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.

43Chapitre IChapitre IChapitre IChapitre IVVVV :::: RéalisationRéalisationRéalisationRéalisation du l’applicationdu l’applicationdu l’applicationdu l’application
4444....2222....2222EnvironnementEnvironnementEnvironnementEnvironnement 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....3333SGBD 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'application
Dans cette partie on va présenter les interfaces
application.
4444....3333....1111AuthentificationAuthentificationAuthentificationAuthentification
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
44du 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
fonctionnalité caractérise le chef de projet
Figure 4
4444....3333....4444 Gestion desGestion desGestion desGestion 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 desGestion desGestion desGestion 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
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 fin
4) Durée calculé
5) Ressource
6) 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 deDiagramme deDiagramme deDiagramme de
Cette vue est la
diagramme de GANTT.
Figure 4
Diagramme deDiagramme deDiagramme deDiagramme 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.

Mémoire PEF application client server gestion des projet collaborative

Mémoire PEF application client server gestion des projet collaborative

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Mémoire PEF application client server gestion des projet collaborative

Similaire à Mémoire PEF application client server gestion des projet collaborative (20)

Dernier

Dernier (20)

Mémoire PEF application client server gestion des projet collaborative