DIAGRAMME DE CLASSES 

DIAGRAMME DE CLASSES 

Introduction

Après avoir spécifié les besoins fonctionnels et non fonctionnels de l’application, nous allons aborder la conception de différentes parties du projet moyennant des diagrammes proposés par le standard UML. Cette phase de conception permet de décrire de manière non ambiguë le fonctionnement futur du système, afin d’en faciliter la réalisation.

Architecture de l’application

Les choix architecturaux d’une application sont décisifs dès lors qu’ils interviennent sur les performances, l’évolutivité, le temps de développement, et bien sûr le coût. Aujourd’hui nous parlons d’une séparation des applications en différentes couches, et nous parlons alors d’applications multi niveaux.
L’architecture de notre système est une architecture multi niveaux à base de composants respectant le paradigme JEE. Elle est constituée des couches suivantes modélisées dans la figure ci-dessous. Il s’agit d’un modèle logique d’architecture applicative qui vise à modéliser une application comme un empilement de trois couches logicielles dont le rôle est clairement défini :
La présentation des données : correspondant à l’affichage, la restitution sur le poste de travail, le dialogue avec l’utilisateur ;Le traitement métier des données : correspondant à la mise en oeuvre de l’ensemble des règles de gestion et de la logique applicative ;L’accès aux données persistantes : correspondant aux données qui sont destinées à être conservées sur la durée, voire de manière définitive.Dans cette approche, les couches communiquent entre elles au travers d’un « modèle d’échange », et chacune d’entre elles propose un ensemble de services rendus. Les services d’une couche sont mis à disposition de la couche supérieure. On s’interdit par conséquent qu’une couche invoque les services d’une couche plus basse que la couche immédiatement inférieure ou plus haute que la couche immédiatement supérieure (chaque couche ne communique qu’avec ses voisins immédiats).Le rôle de chacune des couches et leur interface de communication étant bien définis, les fonctionnalités de chacune d’entre elles peuvent évoluer sans induire de changement dans les autres couches. Cependant, une nouvelle fonctionnalité de l’application peut avoir des répercussions dans plusieurs d’entre elles. Il est donc essentiel de définir un modèle d’échange assez souple, pour permettre une maintenance aisée de l’application.

Table des matières

CHAPITRE 1 : CADRE DU PROJET 
1. PRESENTATION DE L’ENTREPRISE D’ACCUEIL
2. CONTEXTE : TRAVAIL A DISTANCE
3. PROBLEMATIQUE
4. SOLUTION PROPOSEE
1. LES BUREAUX VIRTUELS
2. LA VIRTUALISATION
3. LE CLOUD COMPUTING
1. ULTEO OPEN SOURCE(2)
2. MYBOOO(3)
3. MYNOX(4)
4. ZOHO DOCS (5)
1. LES METHODES AGILES (6)
2. LE PROCESSUS UNIFIE (PU) (7)
3. COMPARAISON ENTRE LES METHODES
4. METHODOLOGIE ADOPTEE : SCRUM
4.1. PRESENTATION DE SCRUM
CHAPITRE 3 : ANALYSE ET SPECIFICATION DES BESOINS 
1. IDENTIFICATION DES ACTEURS
2. IDENTIFICATION DES BESOINS FONCTIONNELS
3. CAPTURE DES BESOINS NON FONCTIONNELS
1. DEFINITION DU BACKLOG DU PRODUIT
1. DIAGRAMME DE CAS D’UTILISATION GENERAL
1. DESCRIPTION DETAILLEE DU DIAGRAMME DU CAS D’UTILISATIONS
CHAPITRE 4 : CONCEPTION
1. DIAGRAMME DE CLASSES 
2. DECOUPAGE EN PACKAGES
1. SCENARIO : «AUTHENTIFICATION »
2. SCENARIO : « AJOUT D’UN EMPLOYE »
3. SCENARIO 3 : MODIFICATION D’UN EMPLOYE
CHAPITRE 5 : MISE EN OEUVRE 
I. Environnement de travail et technologies utilisées 
1. TECHNOLOGIES
2. ARCHITECTURE ET DEPLOIEMENT
1. AUTHENTIFICATION
2. INTERFACE PRINCIPALE
3. EDITION DES FICHIERS
4. CHARGEMENT DES FICHIERS
5. WEB SERVICE METEO
6. WEB SERVICE RSS FOURNI PAR BING
1. LES TESTS
IV chronogramme 
CONCLUSION GENERALE ET PERSPECTIVES 
NETOGRAPHIE
BIBLIOGRAPHIE

Télécharger le rapport complet