République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Univ...
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, ...
ListListListListeeee desdesdesdes figuresfiguresfiguresfigures
Figure 2.1 : Exemple d’association …………………………..………
Figure 2...
ListListListListeeee desdesdesdes tablestablestablestables
Tableau 1.1 : Gestion produit logiciel ………………...……………………..
Tabl...
Table des matières
Introduction générale ………………………………………………………..
Chapitre 1Chapitre 1Chapitre 1Chapitre 1 :::: Processus d...
2.6.2.1 Diagramme de cas d’utilisation …………………………………..
2.6.2.2 Diagramme de séquence …………………………………………...
2.6.2.3 Diagramme...
1Introduction généraleIntroduction généraleIntroduction généraleIntroduction générale
Introduction généraleIntroduction gé...
CHAPITRE 1CHAPITRE 1CHAPITRE 1CHAPITRE 1
ProcessusProcessusProcessusProcessus
DuDuDuDu
DéveloppementDéveloppementDéveloppe...
2Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde dév...
3Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde dév...
4Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde dév...
5Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde dév...
6Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde dév...
7Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde dév...
8Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde dév...
9Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde dév...
CHAPITRE 2CHAPITRE 2CHAPITRE 2CHAPITRE 2
LangageLangageLangageLangage
DeDeDeDe
ModélisationModélisationModélisationModélis...
10Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de m...
11Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de m...
12Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de m...
13Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de m...
• Diagramme de temp
séquence pour montrer l’évolution de l’état d’un objet au cours du
• Diagramme d’activité
décisions au...
Une composition : est une agr
• un élément ne peut
non partagée) ;
• la destruction de l’
éléments.
Figure 2
Une généralis...
16Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de m...
Figure 2-
2222....6666....1111....4444 Diagramme deDiagramme deDiagramme deDiagramme de
Il montre l’organisation logique d...
18Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de m...
2222....6666....2222Modélisation dynamiqueModélisation dynamiqueModélisation dynamiqueModélisation dynamique
2222....6666....
Figure 2
2222....6666....2222....3333 Diagramme d’activitéDiagramme d’activitéDiagramme d’activitéDiagramme d’activité
Un ...
21Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de m...
22Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de m...
CHAPITRE 3CHAPITRE 3CHAPITRE 3CHAPITRE 3
ConceptionConceptionConceptionConception
DuDuDuDu
L’applicationL’applicationL’app...
23Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
24Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
25Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
26Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
27Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
28Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
29Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
30Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
31Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
32Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
33Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
34Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
35Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
36Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
37Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
38Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
39Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
40Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
41Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception d...
CHAPITRE 4CHAPITRE 4CHAPITRE 4CHAPITRE 4
RéalisationRéalisationRéalisationRéalisation
DuDuDuDu
L’applicationL’applicationL...
42Chapitre IChapitre IChapitre IChapitre IVVVV :::: RéalisationRéalisationRéalisationRéalisation du l’applicationdu l’appl...
43Chapitre IChapitre IChapitre IChapitre IVVVV :::: RéalisationRéalisationRéalisationRéalisation du l’applicationdu l’appl...
4444....3333 Fonctionnalités de l'applicationFonctionnalités de l'applicationFonctionnalités de l'applicationFonctionnalit...
4444....3333....2222 Fenêtre principaleFenêtre principaleFenêtre principaleFenêtre principale
Cette vue représente l’inter...
4444....3333....3333 Gestion des clientsGestion des clientsGestion des clientsGestion des clients
Cette vue représente l’i...
4444....3333....5555 Ajouter une tâcheAjouter une tâcheAjouter une tâcheAjouter une tâche
Cette vue représente l’interface...
4444....3333....6666 Enregistrer / ouvrir un projetEnregistrer / ouvrir un projetEnregistrer / ouvrir un projetEnregistrer...
4444....3333....7777 Diagramme deDiagramme deDiagramme deDiagramme de
Cette vue est la
diagramme de GANTT.
Figure 4
Chapit...
Mémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborative
Prochain SlideShare
Chargement dans…5
×

Mémoire PEF application client server gestion des projet collaborative

7 901 vues

Publié le

Mémoire PEF
conception et realisation
application client server gestion des projet collaborative

Publié dans : Ingénierie
0 commentaire
4 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
7 901
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
498
Commentaires
0
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Mémoire PEF application client server gestion des projet collaborative

  1. 1. 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 -
  2. 2. 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.
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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é.
  8. 8. CHAPITRE 1CHAPITRE 1CHAPITRE 1CHAPITRE 1 ProcessusProcessusProcessusProcessus DuDuDuDu DéveloppementDéveloppementDéveloppementDéveloppement ---- UPUPUPUP ----
  9. 9. 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.
  10. 10. 3Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde développementde développement UPUPUPUP 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.
  11. 11. 4Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde développementde développement UPUPUPUP 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 :
  12. 12. 5Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde développementde développement UPUPUPUP 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.
  13. 13. 6Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde développementde développement UPUPUPUP 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
  14. 14. 7Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde développementde développement UPUPUPUP • 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.
  15. 15. 8Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde développementde développement UPUPUPUP 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 ;
  16. 16. 9Chapitre IChapitre IChapitre IChapitre I :::: ProcessusProcessusProcessusProcessus de développementde développementde développementde développement UPUPUPUP 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.
  17. 17. CHAPITRE 2CHAPITRE 2CHAPITRE 2CHAPITRE 2 LangageLangageLangageLangage DeDeDeDe ModélisationModélisationModélisationModélisation -UMLUMLUMLUML ----
  18. 18. 10Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation UMLUMLUMLUML 2222....1111 IntroductionIntroductionIntroductionIntroduction 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.
  19. 19. 11Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation UMLUMLUMLUML 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).
  20. 20. 12Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation UMLUMLUMLUML 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.
  21. 21. 13Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation UMLUMLUMLUML 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.
  22. 22. • 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 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 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 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 ».
  23. 23. 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é Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation 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. 15Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation UMLUMLUMLUML 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.
  24. 24. 16Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation UMLUMLUMLUML 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.
  25. 25. 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 Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation -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 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 17Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation UMLUMLUMLUML 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
  26. 26. 18Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation UMLUMLUMLUML 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
  27. 27. 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 Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation 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, 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 19Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation UMLUMLUMLUML 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.
  28. 28. 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 Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation 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é 20Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation UMLUMLUMLUML 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é
  29. 29. 21Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation UMLUMLUMLUML 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
  30. 30. 22Chapitre IIChapitre IIChapitre IIChapitre II : Le: Le: Le: Le Langage de modélisationLangage de modélisationLangage de modélisationLangage de modélisation UMLUMLUMLUML 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. 2222....7777 ConclusionConclusionConclusionConclusion 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.
  31. 31. CHAPITRE 3CHAPITRE 3CHAPITRE 3CHAPITRE 3 ConceptionConceptionConceptionConception DuDuDuDu L’applicationL’applicationL’applicationL’application
  32. 32. 23Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 3333....1111 IntroductionIntroductionIntroductionIntroduction 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.
  33. 33. 24Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 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
  34. 34. 25Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 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 ».
  35. 35. 26Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 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 »
  36. 36. 27Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 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. 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 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. 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 »
  37. 37. 28Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 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 ;
  38. 38. 29Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 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»
  39. 39. 30Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 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 ».
  40. 40. 31Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 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 ».
  41. 41. 32Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application Ce diagramme décrire l’ensemble des actions pour modifier une tâche Figure 3-4 : Diagramme d’activité « Modifier une tâche ».
  42. 42. 33Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application Ce diagramme décrire le cas de la suppression d’une tâche Figure 3-5 : Diagramme d’activité « Supprimer une tâche».
  43. 43. 34Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application Ce diagramme décrire l’enchainement d’action pour envoyer un message privé ou public : Figure 3-6 : Diagramme d’activité « Envoyer message».
  44. 44. 35Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 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 ».
  45. 45. 36Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 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 ».
  46. 46. 37Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 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 ».
  47. 47. 38Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 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 ».
  48. 48. 39Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application Ce diagramme décrit l’enchainement d’exécution du cas « Envoyer message » Figure 3-11 : Diagramme séquence « Envoyer message ».
  49. 49. 40Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 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.
  50. 50. 41Chapitre IChapitre IChapitre IChapitre IIIIIIIII :::: Conception du l’applicationConception du l’applicationConception du l’applicationConception du l’application 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. 3333....8888 ConclusionConclusionConclusionConclusion 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.
  51. 51. CHAPITRE 4CHAPITRE 4CHAPITRE 4CHAPITRE 4 RéalisationRéalisationRéalisationRéalisation DuDuDuDu L’applicationL’applicationL’applicationL’application
  52. 52. 42Chapitre IChapitre IChapitre IChapitre IVVVV :::: RéalisationRéalisationRéalisationRéalisation du l’applicationdu l’applicationdu l’applicationdu l’application 4444....1111 IntroductionIntroductionIntroductionIntroduction 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.
  53. 53. 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.
  54. 54. 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
  55. 55. 4444....3333....2222 Fenêtre principaleFenêtre principaleFenêtre principaleFenêtre principale Cette vue représente l’interface Figure 4 1 Chapitre IChapitre IChapitre IChapitre IVVVV :::: RéalisationRéalisationRéalisationRéalisation du l’applicationdu l’applicationdu l’applicationdu l’application 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 45du l’applicationdu l’applicationdu l’applicationdu l’application du chef projet. 5 4
  56. 56. 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 desGestion desGestion desGestion des Cette vue représente l’interface du modification et la suppression des ressources par Figure 4 Chapitre IChapitre IChapitre IChapitre IVVVV :::: RéalisationRéalisationRéalisationRéalisation du l’applicationdu l’applicationdu l’applicationdu l’application 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 46du l’applicationdu l’applicationdu l’applicationdu l’application 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
  57. 57. 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. Chapitre IChapitre IChapitre IChapitre IVVVV :::: RéalisationRéalisationRéalisationRéalisation du l’applicationdu l’applicationdu l’applicationdu l’application 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 47du l’applicationdu l’applicationdu l’applicationdu l’application 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
  58. 58. 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 Chapitre IChapitre IChapitre IChapitre IVVVV :::: RéalisationRéalisationRéalisationRéalisation du l’applicationdu l’applicationdu l’applicationdu l’application 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 6 : l’interface d’ouvrir ou enregistrer un projet. Ouvrir un projet 1 Enregistrer un projet 48du l’applicationdu l’applicationdu l’applicationdu l’application Cette vue représente l’interface d’espace de travaille illustre la 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 l’interface d’ouvrir ou enregistrer un projet. Enregistrer un projet
  59. 59. 4444....3333....7777 Diagramme deDiagramme deDiagramme deDiagramme de Cette vue est la diagramme de GANTT. Figure 4 Chapitre IChapitre IChapitre IChapitre IVVVV :::: RéalisationRéalisationRéalisationRéalisation du l’applicationdu l’applicationdu l’applicationdu l’application 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 49du l’applicationdu l’applicationdu l’applicationdu l’application ation des tâches d’un projet par un d’un diagramme du GANTT.

×