Professional Documents
Culture Documents
Suivie des
enseignements du LMD
par application de la
méthode 2TUP
Projet de Fin d’Etudes pour l’obtention du Diplôme
d’Ingénieur d’Etat en Informatique
Option : informatique industrielle
A la mémoire de mes oncles Lotfi et Amine, que leurs âmes reposent en paix
Bassim
Je dédie ce mémoire
A ma chère mère pour son soutien tout au long de mes études
A mes sœurs et frères :
nadjia, mohamed, toufik, choumicha, chahrazed
ainsi qu’à mes belles sœurs et beaux frères : amine, hicham, khalil, sihem, leïla
sans oublier mes nièces et mes neveux :
chahinez, wafaa, farah, walid, sarah, ryadh, marouane et mouhcine
A tous mes amis et à toute mes amies
et à tous ceux qui m’ont encouragé
Zaki
Page 2
Remerciements
On remercie Monsieur Ziani Cherif Salim pour l’aide qu’il nous a apporté
Aussi, on remercie Hakim (Kimz) pour l’aide qu’il nous a apporté afin de rendre
notre rapport meilleur,
et Zakia et Nadia pour le temps qu’ils ont passé à corriger le mémoire
Page 3
Résumé :
Nous proposons dans le cadre de ce projet de fin d’études, d’appliquer la méthode
2TUP au problème de la gestion des enseignements LMD à l’université de Tlemcen.
La gestion d’un cycle de vie de logiciel requit un grand sens de la rigueur et de
l’adaptation aux changements continuels imposés au monde de l’entreprise.
C’est pour ça que nous avons choisi d’axer notre travail sur une méthode de
développement qui est née de travaux poussés vers la standardisation et la flexibilité, et ce
pour répondre aux contraintes actuelles de gestion des développements.
Le mémoire sera découpé en 5 grands chapitres :
5. Conclusion générale
Page 4
TABLE DES MATIERES
INTRODUCTION ...................................................................................................................................................... 7
1. LE CONTEXTE DE TRAVAIL.................................................................................................................................. 7
2. OBJECTIFS ........................................................................................................................................................ 7
3. COMPARAISON ENTRES LES DIFFERENTES APPROCHES ............................................................................................. 8
4. PRESENTATION DE L’APPLICATION A RÉALISER .................................................................................................... 9
LA METHODE 2TUP............................................................................................................................................... 10
Page 5
BIBLIOGRAPHIE ...................................................................................................................................................104
ANNEXE : .............................................................................................................................................................105
Page 6
Introduction
1. LE CONTEXTE DE TRAVAIL
2. OBJECTIFS
Notre but est d’appliquer une méthode rigoureuse de conduite d’un projet réel. Le
projet en question concerne la gestion des enseignements.
Ce projet a pour objectif principal de proposer une solution à un problème concret,
et ceci en partant d’une définition des besoins. Nous espérons à travers celui-ci,
démontrer l’importance de l’application d’une méthodologie de développement, et
aussi permettre par la suite que ce produit puisse être évolutif et facilement
maintenable par des intervenants tiers.
Page 7
3. COMPARAISON ENTRES LES DIFFERENTES APPROCHES
Modélisation
Par le passé, le modèle Entité-Relation représentait une grande partie des
approches les plus utilisées.
Actuellement, les nouvelles technologies s’appuient sur le modèle objet.
En termes d’analyse et de modélisation objet, UML est devenu un standard
incontournable, stabilisé, industriel.
Conduite de projet
Au début, le cycle en cascade (ex : le cycle en V) était très utilisé. Mais on a
vite constaté son incapacité à s’adapter aux différents changements.
Une méthode semi-itérative est apparut (RAD) pour pallier aux carences de
ce dernier.
Une méthode fortement axée sur l’itératif et le modèle UML est alors
apparut, il s’agit de UP (Unified Process). Cette méthode comme son nom
l’indique, a été le fruit de travail de plusieurs personnes voulants « unifier » les
différentes méthodes objets existantes à ce moment comme Booch, OMT et OOSE.
Page 8
4. PRESENTATION DE L’APPLICATION A RÉALISER
De nos jours, une des tendances les plus en vue et qui concerne tout les secteurs
de développement, est l’informatisation.
Depuis l’apparition de l’informatique et son introduction dans le monde
économique, les entreprises et entités publiques aspirent à optimiser et à rendre fiable
la gestion de leur structure interne.
L’université de Tlemcen possède quelques milliers d’étudiants qu’il est difficile de
gérer en continu. Avec la mise en place récente du système LMD, la situation s’est
davantage compliquée et la tâche de gestion est devenue plus complexe.
Le projet que nous proposons nous permettra de faciliter la gestion des enseignements,
à travers la conception d’un logiciel avec une méthode que nous allons présenter.
Page 9
La méthode 2TUP
Notre choix s’est porté vers la méthode 2TUP, du fait de son approche nouvelle,
originale.
Notre projet est basé sur un processus de développement bien défini qui va de la
détermination des besoins fonctionnels attendus du système jusqu’à la conception et le
codage final.
Ce processus se base lui-même sur le Processus Unifié (Unified Process) qui est
devenu un standard général réunissant les meilleures pratiques de développement.
Cette méthode ne se base aucunement sur un processus linéaire mais bien, sur un
développement itératif et incrémental.
Nous allons d’abord définir les différents concepts qui vont être utilisés dans ce
document.
Page 10
1. DEFINITION D’UN PROCESSUS DE DEVELOPPEMENT
LOGICIEL
2. LE PROCESSUS UNIFIÉ
Le Processus Unifié (PU ou UP en anglais pour Unified Process) est une méthode
de développement logiciel construite sur UML ; elle est itérative et incrémentale,
centrée sur l’architecture, conduite par les cas d’utilisation et pilotée par les risques.
conduite par les cas d’utilisation : elle est orientée utilisateur pour répondre
aux besoins de celui-ci.
La gestion d’un tel processus est organisée d’après les 4 phases suivantes :
Page 11
3. Construction : sert à livrer progressivement toutes les fonctions du
système.
3. LE PROCESSUS 2TUP
Page 12
Figure : Le système d’information soumis à deux types de contraintes
Page 13
Figure : Le processus de développement en Y
UML unifie à la fois les notations et les concepts orientés objet.il ne s’agit pas d’une
simple notation, mais 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, c’est pour ça
qu’UML est présenté parfois comme une méthode alors qu’il ne l’est absolument pas.
Page 14
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 la définition des besoins jusqu’au codage. (Roques, 2006)
Voici une présentation rapide des différents diagrammes UML qui vont être utilisés
tout au long du projet :
Le diagramme d’états : représente le cycle de vie d’un objet. Il spécifie les états
possibles d’une classe et leur enchainement.
Ce diagramme est utilisé lors des étapes d’analyse et de conception.
Page 15
Conception du logiciel
1. ETUDE PRÉLIMINAIRE
L’étude préliminaire (ou Préetude) est la toute première étape du processus 2TUP.
Elle consiste à effectuer un premier repérage des besoins fonctionnels et
opérationnels, en utilisant principalement le texte, ou diagrammes très simples. Elle
prépare les activités plus formelles de capture des besoins fonctionnels et de capture
techniques.
Page 16
Organisation des départements :
_____________________________________________________________________
Progression :
_____________________________________________________________________
Page 17
La progression de la première à la deuxième année de la Licence, est de droit si l’étudiant
a acquis les deux premiers semestres du cursus de formation. Cependant, elle peut être
autorisée pour tout étudiant ayant acquis au moins 30 crédits.
La progression de la deuxième à la troisième année est de droit si l’étudiant a acquis les 4
premiers semestres du cursus de formation. Mais elle peut être autorisée si l’étudiant a validé
80% des crédits relatifs aux 4 premiers semestres, et si l’étudiant a validé aussi les unités
d’enseignements fondamentales.
Pour chaque département et chaque année d’études, une promotion doit être crée.
La promotion contient un certain nombre d’étudiants encadrés par des enseignants.
Un étudiant dés son inscription à l’université, peut être affecté à une promotion selon la
filière qu’il a choisie.
Page 18
1.4. Identification des acteurs
Nous allons maintenant énumérer les acteurs susceptibles d’interagir avec le
système, mais d’abord nous donnons une définition de ce que c’est un acteur.
Définition : un acteur représente l'abstraction d'un rôle joué par des entités
externes (utilisateur, dispositif matériel ou autre système) qui interagissent
directement avec le système étudié.
Page 19
1.5. Identification des messages
On va détailler les différents messages échangés entre le système et l’extérieur.
Page 20
1.6. Modélisation du contexte
A partir des informations obtenues lors des deux précédentes étapes, nous
allons modéliser le contexte de notre application.
Ceci va nous permettre dans un premier temps, de définir le rôle de chaque acteur
dans le système :
Page 21
2. CAPTURE DES BESOINS FONCTIONNELS
ArgoUML 1: c’est un outil gratuit écrit avec Java, nous l’avons utilisé au début
puis nous l’avons délaissé pour sa lourdeur et son interface peu intuitive.
Bouml 2: sûrement l’outil le plus léger sur le marché, il est très puissant et
agréable à utiliser, et en plus il est gratuit.
1
Peut être téléchargé à l’adresse suivante : http://argouml.tigris.org/
2
Peut être téléchargé à l’adresse suivante : http://bouml.free.fr/
3
Le site de NetBeans : http://www.netbeans.org/
Page 22
Identification des cas d’utilisation :
L’identification des cas d’utilisation une première fois, nous donne un aperçu des
fonctionnalités futures que doit implémenter le système.
Cependant, il nous faut plusieurs itérations pour ainsi arriver à constituer des cas
d’utilisation complets. D’autres cas d’utilisation vont apparaître au fur à mesure de la
description de ceux là, et l’avancement dans le « recueil des besoins fonctionnels ».
Pour constituer les cas d’utilisation, il faut considérer l'intention fonctionnelle de
l'acteur par rapport au système dans le cadre de l'émission ou de la réception de
chaque message. En regroupant les intentions fonctionnelles en unités cohérentes, on
obtient les cas d'utilisations.
Page 23
Gérer les emplois du temps Scolarité Emet : Créer/modifier les emplois du temps
Consulter les emplois du Etudiant, Enseignant Reçoit : consulter les emplois du temps.
temps
Emet : Création, modification, suppression
Gérer les profils Administrateur de profils.
Remarque : Du fait qu’elle ne rentre pas dans le cadre de notre projet, la gestion des salles
a été délibérément omise.
Page 24
2.2. Description préliminaire des cas d’utilisations
Voici une description préliminaire des cas d’utilisations énumérés précédemment :
Page 25
2.3. Description détaillée des cas d’utilisations
Nous allons maintenant détailler chaque cas d’utilisation qui doit faire l’objet
d’une définition a priori qui décrit l’intention de l’acteur lorsqu’il utilise le système et
les séquences d’actions principales qu’il est susceptible d’effectuer. Ces définitions
servent à fixer les idées et n’ont pas pour but de spécifier un fonctionnement complet
et irréversible.
Page 26
Organiser les DÉPARTEMENTS:
Sommaire D’IDENTIFICATION:
______________________________________________________________
Résumé : créer un nouveau domaine, une nouvelle spécialité, une nouvelle option
Préconditions :
Le chef de département est authentifié.
Scénario nominal :
Ce cas d’utilisation commence lorsque le chef de département demande au système de
créer un nouveau domaine.
Page 27
Si le domaine existe déjà déclencher : [Exception1 : DomaineExistant]
Enchaînements alternatifs :
Exceptions :
[Exception1 : DomaineExistant] : le domaine est marqué en anomalie tant que le code n’a pas été
changé.
[Exception2 : UEExistante] : l’UE est marqué en anomalie tant que le code n’a pas été changé.
L’UE ne peut plus être validée.
[Exception3 : ModuleExistant] : le module est marqué en anomalie tant que le code n’a pas été
changé. Le module ne peut plus être validé.
[Exception5 : UEUtilisee] : un message est affiché à l’écran avisant l’utilisateur que l’UE ne pas
être supprimée.
Page 28
Etablir les PROMOTIONS:
Sommaire D’IDENTIFICATION:
______________________________________________________________
Préconditions :
1- Le chef de département est authentifié.
2- Au moins un enseignant existe dans la base.
3- Au moins un domaine existe.
Scénario nominal :
Ce cas d’utilisation commence lorsque le chef de département demande au système de
créer une nouvelle promotion.
Page 29
Le chef de département fixe les dates des examens. Il fixe les dates de début/fin, il crée les
groupes …
Enchaînement (g) : valider une promotion en construction
Le chef de département valide la promotion si aucune exception n’est levée.
Enchaînements alternatifs :
Exceptions :
[Exception1 : NoUECree] : la promotion est marqué en anomalie tant qu’une UE n’a pas été
crée. La promotion ne peut plus être validée.
Page 30
Suivre une PROMOTION:
Sommaire D’IDENTIFICATION:
______________________________________________________________
Préconditions :
1- Le chef de département est authentifié.
2- Au moins un enseignant existe dans la base.
3- Au moins un domaine existe.
4- Au moins une promotion existe.
Scénario nominal :
Ce cas d’utilisation commence lorsque le chef de département demande au système de
commencer les études dans une promotion.
Page 31
Si tous les relevés de notes sont remplis terminer le semestre, sinon déclencher :
[Exception2 : SemestreIncomplet ]
Enchaînement (d) : passer au prochain semestre
Si c’est le premier semestre de l’année, le passage est automatique pour tous les
étudiants, sinon si c’est le deuxième, alors une session de rattrapage est prévu pour les
étudiants qui n’ont pas tous les crédits requis. Les résultats à la suite des rattrapages vont
déterminer :
Les étudiants aptes à passer au palier supérieur.
Les étudiants recalés.
Si le dernier semestre est terminé, remise des diplômes aux étudiants ayants réussis.
Si une spécialisation se présente, orienter les étudiants vers les spécialités choisies.
Enchaînements alternatifs :
Enchaînement (e) : Exclure un étudiant de la promotion
Le chef de département peut exclure un étudiant de la promotion.
Exceptions :
[Exception1 : ModuleDejaAttribue] : un message d’erreur est affiché à l’écran avisant
l’utilisateur que le module est déjà attribué.
[Exception2 : SemestreIncomplet]: un message d’erreur est affiché sur l’écran avisant
l’utilisateur que des relevés de notes ne sont pas complets.
Diagramme D’ACTIVITÉS:
______________________________________________________________
Page 32
Diagramme d’activités représentant l’enchainement des étapes d’une promotion
Page 33
Etablir les emplois du TEMPS:
Sommaire D’IDENTIFICATION:
______________________________ ________________________________
Préconditions :
1- Le chef de département est authentifié.
2- Au moins une promotion a été crée.
Scénario nominal :
Ce cas d’utilisation commence lorsque le chef de département demande au système
de créer un nouvel emploi du temps.
Page 34
Le chef de département valide l’emploi du temps.
Enchaînements alternatifs :
Exceptions :
[Exception1 : moduleErreur] : un message d’erreur reste affiché sur l’écran tant que le module
n’a pas été enlevé de l’emploi du temps.
[Exception2 : enseignantErreur] : un message d’erreur reste affiché sur l’écran tant que
l’enseignant n’a pas été enlevé de l’emploi du temps.
Diagramme d’activités
Page 35
Consulter les emplois du TEMPS:
Sommaire D’IDENTIFICATION:
______________________________________________________________
Préconditions :
L’utilisateur est authentifié.
Scénario nominal :
Page 36
Gérer les fiches des étudiants :
Sommaire D’IDENTIFICATION:
______________________________________________________________
Acteurs : Scolarité.
Préconditions :
La Scolarité est authentifiée.
Scénario nominal :
Ce cas d’utilisation commence lorsque le chef de département/Scolarité demande
au système de créer un nouveau/modifier un dossier étudiant.
Enchaînements alternatifs :
Enchaînement (c) : Modifier un dossier étudiant en construction ou validé
Page 37
Enchaînement (d) : Supprimer un dossier étudiant
Diagramme d’activités
Page 38
Maintenir les notes des ÉTUDIANTS:
Sommaire D’IDENTIFICATION:
______________________________________________________________
Préconditions :
1. Le responsable de la scolarité ou l’enseignant est authentifié.
2. Au moins une promotion existe.
3. Au moins un dossier étudiant est crée.
Scénario nominal :
Ce cas d’utilisation commence lorsque le responsable de la scolarité affiche le
relevé de notes.
Enchaînements alternatifs :
Exceptions :
Page 39
[Exception1 : FicheNotesDejaExistante] : un message d’erreur s’affiche à l’écran avisant
l’utilisateur que la fiche existe déjà pour ce semestre.
Diagrammes d’activités:
______________________________________________________________
Diagramme d’activités
Remarque : cet algorithme, ne correspondant pas assez aux besoins du langage choisi et à l’IHM,
va être sensiblement changé.
Page 40
Consulter les NOTES:
Sommaire D’IDENTIFICATION:
______________________________________________________________
Acteurs : étudiant.
Préconditions :
Scénario nominal :
Il choisit un étudiant.
Page 41
Gérer les PROFILS:
Sommaire D’IDENTIFICATION:
______________________________________________________________
Acteurs : Administrateur.
Préconditions :
Aucunes.
Scénario nominal :
Page 42
2.4. Structuration des cas d’utilisations dans des packages
Cette phase va permettre de structurer les cas d’utilisations en groupes fortement
cohérents, ceci afin de préparer le terrain pour la prochaine phase qui est le
« découpage en catégories ».
Page 43
Gérer les profils Administrateur Gestion des profils
Définition : une responsabilité est une sorte de contrat, ou d’obligation, pour une
classe. Elle se place à un niveau d’abstraction plus élevé que les attributs ou les
opérations. On formalise ensuite ces concepts métier sous forme de classes et
d’associations rassemblées dans un diagramme statique pour chaque cas
d’utilisation. Ces diagrammes préliminaires sont appelés « diagramme des classes
participantes », n’ont pas pour objectif d’être complet. Ils servent uniquement à
démarrer la découverte des classes du modèle d’analyse.
Exemple :
Resp
onsabilités de la classe « Domaine »
Page 44
Diagramme des classes participantes du cas d’utilisation
« Organiser les départements » :
Les classes candidates sont tirées de la description textuelle du cas
d’utilisation et des diagrammes dynamiques représentant celui-ci :
Page 45
Diagramme des classes participantes du cas d’utilisation
« Etablir les promotions » :
Les classes candidates sont tirées de la description textuelle du cas
d’utilisation et des diagrammes dynamiques représentant celui-ci :
Page 46
Diagramme des classes participantes du cas d’utilisation
« Suivre les promotions » :
Les classes candidates sont tirées de la description textuelle du cas
d’utilisation et des diagrammes dynamiques représentant celui-ci :
Page 47
Diagramme des classes participantes du cas d’utilisation
« Etablir les emplois du temps » :
Les classes candidates sont tirées de la description textuelle du cas
d’utilisation et des diagrammes dynamiques représentant celui-ci :
Page 48
Diagramme des classes participantes du cas d’utilisation
« Maintenir les notes étudiants » :
Les classes candidates sont tirées de la description textuelle du cas
d’utilisation et des diagrammes dynamiques représentant celui-ci :
Page 49
3. ANALYSE
Pour passer à l’analyse, il faut se baser sur les principes de l’Approche Orientée
Objet, notamment celle de l’encapsulation. À cet effet, il faut passer d’une
structuration fonctionnelle via les cas d’utilisations, à une structuration objet via
les classes et les catégories.
Page 50
Découpage en catégories
Classe « Promotion » :
Page 51
Classe « Fiche notes » :
Page 52
Classe « Emploi du temps » :
Page 53
3.3. Diagramme de packages d’analyse
Ce diagramme va représenter les différentes dépendances entre les packages
d’analyse :
Remarque 2: cette phase peut être utilisée par un chef de projet pour constituer les
équipes. Chaque équipe pourra se concentrer sur le développement d’une seule
catégorie/package.
Page 54
3.4. Développement du modèle statique
Le développement du modèle statique constitue la deuxième étape d’analyse.
Les diagrammes de classes établis sommairement dans les diagrammes de classes
participantes, puis réorganisés lors du découpage en catégories, vont être, complétés,
et optimisés.
Catégorie « Etudes » :
Voici le diagramme de classe de la catégorie Etudes.
Diagramme de classe
Page 55
Catégorie « Promotions » :
Voici le diagramme de classe de la catégorie Promotion et aussi Etudiants.
Page 56
Et voici les opérations/attributs de la classe Promotion.
Page 57
Et voici les opérations/attributs de la classe Semestre.
Page 58
Catégorie « Relevé de notes » :
Voici le diagramme de classe de la catégorie Relevé de notes.
Page 59
Catégorie « Enseignants » :
Voici le diagramme de classe de la catégorie Enseignants.
Diagramme de classe
Page 60
Catégorie « Etudiant » :
Page 61
3.5. Développement du modèle dynamique
Le développement du modèle dynamique constitue la troisième activité de l’étape
d’analyse. Il s’agit d’une activité itérative, fortement couplée avec la modélisation
statique.
Nominaux : ils réalisent les post conditions du cas d’utilisation, d’une façon
naturelle et fréquente ;
Aux limites : ils réalisent les post conditions du cas d’utilisation, mais
modifient le système de telle sorte que la prochaine exécution du cas
d’utilisation provoquera une erreur ;
Il faut signaler que tous les scénarios possibles ne peuvent être énumérés et décrits
du fait qu’ils en existent beaucoup. C’est pour cette raison que nous allons faire une
description des scénarios les plus pertinents.
Page 62
SCÉNARIOS DE « Organiser les licences »:
Parmi tous les scénarios possibles pour le cas d’utilisation « Organiser les
licences » (OL) nous avons choisi les suivants :
Scénarios alternatifs :
OL_A1 : modifier un domaine par ajout d’une spécialité.
OL_A2 : modifier un domaine par ajout d’une option.
OL_A3 : modifier un domaine par création d’UE et modules.
OL_A4 : modifier un domaine par suppression d’une UE.
Scénarios d’exception :
OL_E1 : non validation de la création de domaine pour cause de nom existant
déjà.
OL_E2 : non validation de la modification du domaine par suppression d’une UE
pour cause d’existence d’une promotion utilisant l’UE.
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
Page 63
o Un objet Domaine crée au cours du scénario.
o Un objet Tronc_Commun crée au cours du scénario.
o Un objet Specialite crée au cours du scénario.
Il sélectionne le tronc commun / une spécialité qui n’a pas encore des UE.
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
Page 64
o Un objet UE crée au cours du scénario.
o Un objet Module crée au cours du scénario.
Page 65
SCÉNARIOS DE « Etablir les promotions »:
Parmi tous les scénarios possibles pour le cas d’utilisation « Etablir les
promotions » (EP) nous avons choisi les suivants :
Scénarios alternatifs :
EP _A1 : modifier une promotion par ajout d’un enseignant.
EP _A2 : modifier une promotion par attribution d’un module à un enseignant non
encore attribué.
EP _A3 : modifier une promotion par libération d’un enseignant chargé d’un
module.
EP _A4 : modifier une promotion par ajout d’un étudiant.
EP _A5 : modifier une promotion par enlèvement d’un étudiant.
Scénarios d’exception :
EP _E1 :
EP _E2 :
Page 66
o Un multi-objet représentant l’ensemble des instances de Enseignant qui
vont être affectés à la nouvelle promotion.
o Un multi-objet représentant l’ensemble des instances de Etudiant qui vont
être rattachés à la nouvelle promotion.
Page 67
EP _A1 : modifier une promotion par ajout d’un enseignant.
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
Diagramme de séquence du scénario « modifier une promotion par ajout d’un enseignant »
EP _A2 : modifier une promotion par attribution d’un module à un enseignant non
encore attribué.
Page 68
Il sélectionne un module.
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
Diagramme de séquence du scénario « modifier une promotion par attribution d’un module à un enseignant non
encore attribué»
EP _A3 : modifier une promotion par libération d’un enseignant chargé d’un
module.
Page 69
Il sélectionne une promotion.
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
Diagramme de séquence du scénario « modifier une promotion par libération d’un enseignant chargé d’un
module »
Page 70
Il sélectionne une promotion.
Il sélectionne un étudiant.
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
Page 71
SCÉNARIOS DE « Etablir les emplois du temps »:
Il choisit la promotion.
Il choisit le semestre.
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
Page 72
Diagramme de séquence du scénario « créer un nouvel emploi du temps »
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
o Un acteur Scolarité.
o Un étudiant crée au cours du scénario.
Parmi tous les scénarios possibles pour le cas d’utilisation « Etablir les
promotions » (MN) nous avons choisi les suivants :
Scénarios alternatifs :
MN _A1 : modifier une note pour un étudiant.
MN _A2 : modifier une promotion par attribution d’un module à un enseignant
non encore attribué.
MN _A3 : modifier une promotion par libération d’un enseignant chargé d’un
module.
Scénarios d’exception :
MN _E1 :
MN _E2 :
Page 73
Description détaillée des scénarios :
Scénarios nominaux :
MN _N1 : créer une fiche de notes.
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
o Un acteur Scolarité.
o Un étudiant crée au cours du scénario.
o Une Promotion crée au cours du scénario.
o Une Fiche notes.
Page 74
Pour chaque module, elle affecte une note (examen, TD, TP, Devoir).
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
o Un acteur Scolarité.
o Un étudiant crée au cours du scénario.
o Un objet Promotion crée au cours du scénario.
o Un objet Note.
Page 75
Construction des diagrammes d’états :
On recourt au concept de machine à états finis, qui consiste à s’intéresser au
cycle de vie d’un objet générique d’une classe particulière au fil de ses interactions
avec les autres classes, dans tous les cas possibles. Cette vue locale d’un objet,
décrivant comment il réagit à des événements en fonction de son état courant et passe
dans un nouvel état, est représentée graphiquement sous forme d’un diagramme
d’états.
Définition : un état représente une situation durant la vie d’un objet pendant laquelle :
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.
Page 76
Diagramme d’états de la classe Promotion
Rattaché : cet état représente un étudiant qui est attaché à une promotion.
En cours d’études : cet état représente un étudiant qui est entrain d’étudier.
En cours de passage : cet état survient après qu’un étudiant ait réussi le
passage au niveau supérieur. Au cours de cet état, l’étudiant fait le choix de
la prochaine branche.
Recalé : cet état survient après qu’un étudiant ait échoué le passage au
niveau supérieur.
Etudes terminées : cet état survient après qu’un étudiant ait terminé ses
études supérieures.
Page 77
Diagramme d’états de la classe Etudiant
Page 78
4. CONCEPTION
La conception détaillée qui vient juste après est une activité qui s’inscrit dans
l’organisation définie par la conception préliminaire. Le modèle logique y est
particulièrement important dans la mesure où c’est dans cette étape qu’on génère le
plus grand nombre d’informations. Il est ainsi possible de confier les catégories à des
personnes différentes, qui pourront travailler indépendamment les unes des autres.
Les concepteurs dans cette phase construisent les classes, les vue d’IHM, les
interfaces, les tables et les méthodes qui vont donner une image « prête à coder » de la
solution.
Architecture 3-Tiers :
Pour avoir une architecture robuste, modulable et évolutive, il nous faut
utiliser le principe de « couche ».
Nous allons donc séparer au maximum les différents types de traitement de
l’application (Dao, Métier, Présentation).
Page 79
Architecture 3-Tiers
Page 80
Les Designs Patterns proviennent du travail de nombreux développeurs qui se sont
tour à tour penchés sur les mêmes problèmes. En mettant en corrélation ces travaux on
a pu désigner les meilleures solutions découvertes sous le terme de motifs de
conception. La connaissance de ces motifs permet au programmeur de trouver
rapidement des implémentations pour ses programmes. La principale difficulté réside
dans l'identification du problème et dans sa mise en relation avec des motifs connus.
Pour nous, les Design Pattern nous ont aidé à trouver une solution élégante à un
problème conceptuel. En fait, ils vont nous aider à coder les différents concepts qui se
dégagent dans la phase de conception.
Donc on peut dire que les Design Pattern interviennent aussi dans la phase de
codage.
Remarque : les diagrammes qui vont suivre ont été crée avec l’outil UML de
NetBeans 5.5
Page 81
La Classe Promotion :
Page 82
La classe Promotion délègue la gestion de ses états à l’interface EtatPromotion et
ses différentes implémentations (EtatEnCreation, EtatValide, EtatEnCours,
EtatTerminee)
Page 83
La classe Promotion et ses différents états
La Classe Etudiant :
Page 84
La classe Etudiant délègue la gestion de ses états à l’interface « EtatEtudiant »
Page 85
Le Design Pattern « Façade » :
Définition : Le patron de conception Façade a pour but de cacher une
conception et une interface complexe difficile à comprendre. La façade permet de
simplifier cette complexité en fournissant une interface simple du sous-système.
Habituellement, la façade est réalisée en réduisant les fonctionnalités de ce dernier
mais en fournissant toutes les fonctions nécessaires à la plupart des utilisateurs.
Page 86
La couche Métier à accès à la BDD grâce au Pattern DAO
Ce Design Pattern est intégré à Java au travers des classes Observable et Observer
du package Java.util. (Florian GRISONI)
Remarque : Ce Design Pattern a été intensément utilisé dans notre logiciel pour sa
facilité de mise en œuvre, et les différentes possibilités qu’il nous offre afin de
mettre en pratique un autre Design Pattern qui est le MVC.
Page 87
présentation. La vue n'effectue aucun traitement, elle se contente d'afficher
les résultats des traitements effectués par le modèle, et de permettre à
l'utilisateur d'interagir avec elles.
le Contrôleur : prend en charge la gestion des événements de
synchronisation pour mettre à jour la vue ou le modèle. Il n'effectue aucun
traitement, ne modifie aucune donnée, il analyse la requête du client et se
contente d'appeler le modèle adéquat et de renvoyer la vue correspondant à
la demande.
Page 88
5. CODAGE
Le choix du langage s’est porté vers Java, qui étant Orienté Objet à la base, nous
facilitera la transformation de notre modèle objet vers le code.
Notre choix s’est porté vers l’EDI NetBeans, qui nous fournit le confort et la
simplicité nécessaires à un développement propre et rapide.
Nous bénéficierons dans ce cas d’un gain de temps non négligeable, du fait
qu’il peut générer aussi les différents packages avec leurs classes respectives.
Page 89
Structure générale de l’application :
L’application est découpée en 3 couches distinctes, Présentation, Métier et
DAO.
La couche « Présentation » est chargée de tout ce qui est affichage.
La couche « Métier » est la logique métier de l’application, elle est le cœur
et c’est elle qui définit toutes les règles régissantes au fonctionnement de
l’application.
La couche « DAO » est l’intermédiaire entre les autres couches et la Base de
données.
Page 90
La couche Métier :
Voici quelques figures représentants un échantillon du code source de cette
couche :
Page 91
La classe « Domaine » (à gauche les Attributs et les Méthodes)
Page 92
La classe « Etudiant » (à gauche les Attributs et les Méthodes)
Page 93
La couche Présentation :
Voici quelques figures représentants l’interface du logiciel :
La fenêtre principale
Page 94
Fiche de création d’un nouvel étudiant
Page 95
Fiche de création d’une nouvelle promotion
Page 96
Fiche de consultation d’une promotion
Page 97
Fiche de relevé de notes
Page 98
Le stockage de données :
La technique choisie pour persister les données est : la sérialisation.
Une technique plus aboutie aurait été un meilleur choix comme : le mapping
Objet/Relationnel avec un outil comme Hibernate. Cependant, l’apprentissage de
cet outil demande un temps supplémentaire.
Mais la solution de la sérialisation réponds largement à nos besoins pour ce projet,
c’est pour ça que nous avons jugé pertinent de la garder.
Page 99
Bilan de la méthode
Du fait de notre manque d’expérience dans le domaine et, du cadre limité (humain
et matériel) dans lequel nous avons mené notre projet, on ne va pas tirer de conclusion
définitive sur la méthode.
Mais en ce qui concerne la prise en compte d’une évolution possible de
l’application, on va alors donner un cas concret de ce que pourrait être un ajout d’un
nouveau besoin fonctionnel.
Nous allons donc montrer comment on pourrait ajouter cette fonctionnalité à notre
projet de façon concrète.
Identification du besoin :
On suppose que la « gestion de salles » se trouve finalement, être un besoin réel
pour les utilisateurs de notre application.
Nous allons d’abord identifier les acteurs du système devant interagir avec le
système à travers cette nouvelle fonctionnalité :
Page
100
Cas d’utilisation « Gérer les salles »
On peut à la suite de création d’une promotion, lui affecter une salle. De ce fait, le
cas d’utilisation « gérer les salles » pourra étendre le cas d’utilisation « établir les
promotions ».
La « gestion des salles » pourra aussi être comprise comme une spécification de
chaque département. Ce qui nous amène à l’introduire au package « Gestion des
départements ».
D’autres enchainements …
Nous pouvons cependant dire que ce nouveau besoin fonctionnel, se traduira par
un ajout de ces deux classes au package Etudes. Et il devrait y avoir un lien entre la
classe Salle et Promotion. Dans le code, ça se traduira par l’ajout d’un attribut de Type
Salle.
Page
101
Ceci ne devrait pas affecter le codage en général, du fait que les responsabilités des
différentes classes et packages ont été bien séparées.
Conclusion
Nous pouvons constater que l’ajout de nouvelles fonctionnalités peut être simplifié,
pour peu qu’on respecte bien les étapes définies par 2TUP. Ça demande de faire une
itération complète ou partielle selon le besoin, du cycle Y, et ne pas succomber à la
tentation de toucher rapidement au code.
Page
102
Conclusion générale
Nous avons tenté à travers ce projet de démontrer l’importance de l’application d’une
méthode de développement.
Nous pensons aussi que 2TUP pourra être utilisée dans des projets de moyenne à
grande envergure.
A titre personnel, le bénéfice qu’on en a tiré est l’apprentissage de concepts à la pointe
de la technologie et des tendances actuelles dans le monde professionnel. Une
recherche profonde a été indispensable pour essayer de comprendre ces concepts là.
Nous pouvons citer à ce propos, un excellent livre traitant ce sujet qui s’appelle : UML
2 En Action.
Ce projet nous a permis d’enrichir nos connaissances dans des domaines très variés
comme : L’Orienté Objet, UML, 2TUP, le langage JAVA, les Design Patterns, Swing…
En termes d’évolution, l’application pourra par la suite être adaptée à une utilisation à
l’université. Par exemple, une base de données pourra être utilisée soit par le biais d’un
pont JDBC, ou par le biais d’une solution de Mapping Objet/ Relationnel comme
Hibernate. Aussi, un déploiement sur un réseau pourra être fait grâce au framework
J2EE.
Page
103
Bibliographie
Chromatic. (2005). Extreme programming. O'Reilly.
Rocques, P., & Vallée, F. (2004). UML 2 En Action (De l'analyse des besoins à la conception J2EE). Eyrolles.
Page
104
Annexe :
Notion de classe
Tout d’abord, introduisons la notion de classe. Une classe est un type de
données abstrait, caractérisé.
Par des propriétés (attributs et méthodes) communes à toute une famille d’objets et
permettant de créer (instancier) des objets possédant ces propriétés. Les autres
concepts importants qu’il nous faut maintenant introduire sont l’encapsulation,
l’héritage et l’agrégation.
Encapsulation
L’encapsulation consiste à masquer les détails d’implémentation d’un objet,
en définissant une interface. L’interface est la vue externe d’un objet, elle définit
les services accessibles (offerts) aux utilisateurs de l’objet.
Page
105
Ainsi, la spécialisation et la généralisation permettent de construire des hiérarchies
de classes. L’héritage peut être simple ou multiple. L’héritage évite la duplication
et encourage la réutilisation.
L’Agrégation
Il s’agit d’une relation entre deux classes, spécifiant que les objets d’une
classe sont des composants de l’autre classe. Une relation d’agrégation permet
donc de définir des objets composés d’autres objets.
L’agrégation permet donc d’assembler des objets de base, afin de construire des
objets plus complexes. (Meyer, 2000)
UML
Introduction
La description de la programmation par objets a fait ressortir l’étendue du
travail conceptuel nécessaire: définition des classes, de leurs relations, des attributs
et méthodes, des interfaces etc.
Page
106
pourra être immédiatement compris par les informaticiens. En principe seulement,
car la modélisation demande aux maîtrises d’ouvrage une compétence, un
professionnalisme qui ne sont pas aujourd’hui répandus.
UML en œuvre
UML n’est pas une méthode (i.e. une description normative des étapes de la
modélisation): ses auteurs ont en effet estimé qu’il n’était pas opportun de définir
une méthode en raison de la diversité des cas particuliers. Ils ont préféré se borner
à définir un langage graphique qui permet de représenter, de communiquer les
divers aspects d’un système d’information (aux graphiques sont bien sûr associés
des textes qui expliquent leur contenu). UML est donc un méta-langage car il
fournit les éléments permettant de construire le modèle qui, lui, sera le langage du
projet.
Page
107
diagramme d’états-transitions (State machine diagram)
diagrammes d’interaction(Interactiondiagram)
diagramme de séquence (Sequence diagram)
diagramme de communication (Communication diagram)
diagramme global d’interaction (Interaction overview diagram)
diagramme de temps (Timing diagram)
Ces diagrammes, d’une utilité variable selon les cas, ne sont pas
nécessairement tous produits à l’occasion d’une modélisation. Les plus utiles pour
la maîtrise d’ouvrage sont les diagrammes d’activités, de cas d’utilisation, de
classes, d’objets, de séquence et d’états-transitions. Les diagrammes de
composants, de déploiement et de communication sont surtout utiles pour la
maîtrise d’œuvre à qui ils permettent de formaliser les contraintes de la réalisation
et la solution technique.
LE LANGAGE JAVA
Lors de la création du langage Java, il avait été décidé que ce langage devait
répondre à 5 objectifs :
Le système Java est basé sur le langage Java, la machine virtuelle java, et
l'API JAVA (ces deux derniers composants forment l'environnement d'exécution,
ou JRE, pour Java Runtime Environment).
Page
108
DIFFERENCE ENTRE L’ARCHITECTURE 3-TIERS ET LE
MODELE MVC
Les noms d'architectures MVC et 3-Tiers sont très couramment utilisés dans
les cours de génie logiciel. Il est facile de s'emmêler les pinceaux car ces deux
pratiques sont à la fois différentes et similaires.
L'architecture MVC
Model View Controller (Modèle Vue Contrôleur) est souvent décrit comme
un simple design pattern (motif de conception) mais c'est plus un architectural
pattern (motif d'architecture) qui donne le ton à la forme générale d'une solution
logiciel plutôt qu'à une partie restreinte.
1. Model : Le modèle défini les données de l'application et les méthodes d'accès. Tout les
traitements sont effectués dans cette couche.
2. View : La vue prend les informations en provenance du modèle et les présente à
l'utilisateur.
3. Controller : Le contrôleur répond aux événements de l'utilisateur et commande les
actions sur le modèle. Cela peut entrainer une mise à jour de la vue.
L'architecture 3-Tiers
Pour qu'une application MVC soit une vraie application 3-Tiers il faut lui
ajouter une couche d'abstraction d'accès aux données de type DAO (Data Access
Object).
Page
109
Inversement pour qu'une application 3-Tiers respecte MVC il faut lui ajouter
une couche de contrôle entre User interface et Buisness logic.
Page
110