Académique Documents
Professionnel 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
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
Page
3
Remerciements
Page
4
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
5
TABLE DES MATIÈRES
TABLE DES MATIÈRES.........................................................................................6
LE CONTEXTE DE TRAVAIL............................................................................................................7
OBJECTIFS.............................................................................................................................7
COMPARAISON ENTRES LES DIFFÉRENTES APPROCHES..................................................................................8
PRÉSENTATION DE L’APPLICATION À RÉALISER.....................................................................................9
DÉFINITION D’UN PROCESSUS DE DÉVELOPPEMENT LOGICIEL....................................................................10
LE PROCESSUS UNIFIÉ...............................................................................................................11
LE PROCESSUS 2TUP.................................................................................................................12
UN PROCESSUS DE MODÉLISATION AVEC UML.......................................................................................14
ETUDE PRÉLIMINAIRE.............................................................................................................16
Présentation du projet à réaliser.....................................................................................16
Recueil des besoins fonctionnels....................................................................................16
Choix techniques............................................................................................................18
Identification des acteurs................................................................................................18
Identification des messages............................................................................................19
Modélisation du contexte................................................................................................20
CAPTURE DES BESOINS FONCTIONNELS........................................................................................21
Déterminer les cas d’utilisations.....................................................................................22
Description préliminaire des cas d’utilisations................................................................25
Description détaillée des cas d’utilisations.....................................................................26
Structuration des cas d’utilisations dans des packages..................................................41
Identification des classes candidates..............................................................................42
ANALYSE.............................................................................................................................48
Découpage en catégories...............................................................................................48
Dépendances entre catégories.......................................................................................49
Diagramme de packages d’analyse................................................................................54
Développement du modèle statique...............................................................................55
Développement du modèle dynamique..........................................................................63
CONCEPTION......................................................................................................................79
Architecture de l’application...........................................................................................79
Les Design Patterns........................................................................................................80
CODAGE.............................................................................................................................90
La génération de code avec NetBeans 5.5:.....................................................................90
L’application « JStudent »...............................................................................................90
BIBLIOGRAPHIE...............................................................................................103
ANNEXE :........................................................................................................104
L’APPROCHE ORIENTÉE OBJET....................................................................................................104
UML..................................................................................................................................105
LE LANGAGE JAVA.....................................................................................................................107
DIFFÉRENCE ENTRE L’ARCHITECTURE 3-TIERS ET LE MODÈLE MVC..............................................................108
Page
6
Introduction
LE CONTEXTE DE TRAVAIL
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
COMPARAISON ENTRES LES DIFFÉRENTES
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
PRÉSENTATION DE L’APPLICATION À 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
Un processus définit une séquence d’étapes, en partie 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.
(Rocques & Vallée, 2004)
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
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. 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é.
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
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 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.
Choix techniques
Voici les choix techniques qui ont été adoptés pour le projet :
Page
18
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
• Les créations, modifications, suppressions de fiches des étudiants/enseignants.
• Les créations, modifications, de promotions.
• Le lancement/bouclage d’une promotion.
• L’affectation des étudiants/enseignants à une promotion.
• Les ajouts, suppressions, modifications des filières pour un département.
• Les créations, modifications, suppressions des emplois du temps d’une promotion.
• Les créations, modifications, suppressions de profils utilisateurs.
• Les créations, modifications de spécialités pour un département.
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
20
Utilisateurs finaux Description des besoins fonctionnels
Page
21
Déterminer les cas d’utilisations
Définition : un cas d’utilisation représente un ensemble de séquences d’actions
réalisées par le système et produisant un résultat observable intéressant pour un acteur
particulier.
Un cas d’utilisation modélise un service rendu par le système. Il exprime les
interactions acteurs/système et apporte une valeur ajoutée « notable » à l’acteur
concerné.
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
Messages émis/reçus par les acteurs
Cas d’utilisation Acteur principal, acteurs
secondaires
Emet : Créer son département,
Créer/modifier les spécialités/options,
Organiser un département Chef de département Créer les UE et les Modules.
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
23
Remarque 2: Ce premier tableau n'est pas définitif, un processus de développement avec
UML est itératif, il se peut qu'il change au fur et à mesure de l'avancement du projet.
Page
24
Description préliminaire des cas d’utilisations
Voici une description préliminaire des cas d’utilisations énumérés précédemment :
Page
25
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.
Sommaire D’IDENTIFICATION:
______________________________________________________________
Résumé : créer un nouveau domaine, une nouvelle spécialité, une nouvelle option
Préconditions :
Page
26
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.
Enchaînements alternatifs :
Page
27
Si une promotion appartient à ce domaine déclencher :[Exception4 : DomaineUtilise]
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.
Sommaire D’IDENTIFICATION:
______________________________________________________________
Page
28
Descriptions des ENCHAÎNEMENTS:
______________________________________________________________
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.
Enchaînements alternatifs :
Page
29
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.
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
30
Il sélectionne les enseignants chargés de donner des cours, et attribue pour chacun d’eux un
ou plusieurs modules à enseigner.
Si le module est déjà attribué déclencher : [Exception1 : ModuleDejaAttribue ]
Il spécifie les caractéristiques du module TD/TP/Projet/Séminaire/conférence.
Commencer le 1er semestre et la promotion.
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
31
Diagramme d’activités représentant l’enchainement des étapes d’une promotion
Page
32
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
33
Si l’enseignant est déjà pris pour cette plage alors déclencher : [Exception2 :
enseignantErreur]
Enchaînement (c) : Valider un emploi du temps en construction
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
34
Diagramme d’activités
Sommaire D’IDENTIFICATION:
______________________________________________________________
Préconditions :
L’utilisateur est authentifié.
Scénario nominal :
Page
35
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 :
Page
36
Enchaînement (d) : Supprimer un dossier étudiant
Diagrammes d’activités:
______________________________________________________________
Diagramme d’activités
Sommaire D’IDENTIFICATION:
______________________________________________________________
Page
37
Descriptions des ENCHAÎNEMENTS:
_______________________________________________________
Préconditions :
Scénario nominal :
Ce cas d’utilisation commence lorsque le responsable de la scolarité affiche le
relevé de notes.
Enchaînements alternatifs :
Exceptions :
[Exception1 : FicheNotesDejaExistante] : un message d’erreur s’affiche à l’écran avisant
l’utilisateur que la fiche existe déjà pour ce semestre.
Page
38
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é.
Sommaire D’IDENTIFICATION:
______________________________________________________________
Acteurs : étudiant.
Page
39
Préconditions :
Scénario nominal :
Il choisit un étudiant.
Sommaire D’IDENTIFICATION:
______________________________________________________________
Acteurs : Administrateur.
Préconditions :
Aucunes.
Page
40
Scénario nominal :
Page
41
Consulter les notes Etudiant
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 :
Page
42
Responsabilités de la classe « Domaine »
Page
43
• 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
44
Diagramme des classes participantes « Suivre les promotions »
Page
45
Diagramme des classes participantes « Etablir les emplois du temps »
Page
46
Diagramme des classes participantes « Maintenir les notes »
Page
47
ANALYSE
Découpage en catégories
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
48
Découpage en catégories
• Classe « Promotion » :
Page
49
• Classe « Fiche notes » :
Page
50
Associations de la classe Fiche Notes avec navigabilité
Page
51
• Classe « Emploi du temps » :
Page
52
Après affinage des relations, nous avons le diagramme de Package suivant :
Page
53
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
Développement du modèle statique
Diagramme de classe
Page
55
Catégorie « Promotions » : voici le diagramme de classe de la catégorie
Promotion et aussi Etudiants.
Diagramme de classe
Page
56
Classe Promotion (attributs/opérations)
Page
57
Classe Semestre (attributs/opérations)
Page
58
Catégorie « Relevé de notes » : voici le diagramme de classe de la catégorie
Relevé de notes.
Diagramme de classe
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
Catégorie « Emploi du temps » : voici le diagramme de catégories de la classe
Emploi du temps.
Diagramme de catégories
Page
62
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 selon nous.
Scénarios nominaux :
• OL_N1 : créer un nouveau domaine.
• OL_N2 : créer des UE pour un Tronc_Commun ou Specialite.
Scénarios alternatifs :
Page
63
• 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.
Scénarios nominaux :
• OL_N1 : créer un nouveau domaine.
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
Page
64
Diagramme de séquences du scénario «créer un nouveau domaine »
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
65
Diagramme de séquences du scénario « créer une UE »
Page
66
Enumération des scénarios :
Scénarios nominaux :
• EP _N1 : créer une nouvelle promotion.
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 :
Scénarios nominaux :
• EP_1 : créer une nouvelle promotion.
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
Page
67
o Un multi-objet représentant l’ensemble des instances de Etudiant qui vont
être rattachés à la nouvelle promotion.
Page
68
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 ajout d’un enseignant »
• EP _A2 : modifier une promotion par attribution d’un module à un enseignant non
encore attribué.
Il sélectionne un module.
Page
69
Le chef de département valide la 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 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
70
Le chef de département valide la 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 »
Il sélectionne un étudiant.
Page
71
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
Scénarios nominaux :
• EET_1 : créer un nouvel emploi du temps.
Il choisit la promotion.
Il choisit le semestre.
Page
72
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
Scénarios nominaux :
• GF_1 : créer un nouveau dossier étudiant.
Page
73
Il saisit les informations obligatoires (n° inscription, nom, prénom).
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.
Scénarios nominaux :
• MN _N1 : créer une fiche de notes.
• MN _N2 : affecter les notes pour un étudiant.
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 :
Scénarios nominaux :
• MN _N1 : créer une fiche de notes.
Pour décrire ce scénario, nous allons faire intervenir les instances suivantes :
Page
74
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.
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
Diagramme de séquence du scénario « affecter les notes pour un étudiant »
Définition : un état représente une situation durant la vie d’un objet pendant laquelle :
Page
76
• 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.
Page
77
Diagramme d’états de la classe Etudiant :
• 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.
o Recalé : cet état survient après qu’un étudiant ait échoué le passage au
niveau supérieur.
o Etudes terminées : cet état survient après qu’un étudiant ait terminé ses
études supérieures.
Page
78
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 de l’application
La technologie Objet requiert une architecture. C'est cette architecture qui organise
les interactions entre objets. On a l'habitude de regrouper ces objets en classes, ces classes
en domaines, et ces domaines en couches.
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
Voici les différents diagrammes Etats que nous avons conçus :
La Classe Promotion :
Page
82
La classe Promotion et ses différents états
Page
83
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
L'architecture Modèle Vue Contrôleur (MVC) est une méthode de conception
pour le développement d'applications logicielles qui sépare le modèle de données,
l'interface utilisateur et la logique de contrôle.
Page
88
Page
89
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.
L’application « JStudent »
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
Figure représentant les 3 couches de l’application
La couche Métier :
Voici quelques figures représentants un échantillon du code source de cette
couche :
Page
91
La classe « Promotion » (à gauche les Attributs et les Méthodes)
Page
92
La classe « Domaine » (à gauche les Attributs et les Méthodes)
Page
93
La couche Présentation :
Voici quelques figures représentants l’interface du logiciel :
Page
94
Création d’une nouvelle promotion
Page
95
Fiche de consultation d’une promotion
Page
96
Organisation en semestres d’une promotion
Page
97
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. Mais l’apprentissage de cet outil
demande un temps supplémentaire.
Page
98
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
99
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 …
Page
100
Concrètement dans le code :
Normalement, il aurait fallu faire une étude plus approfondie, et continuer avec le
modèle statique et dynamique, afin de dégager les liens possibles entre ces deux classes et
les autres classes des autres packages.
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.
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
101
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
102
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
103
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
104
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
105
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
106
diagramme de cas d’utilisation (Use case diagram)
diagrammes d’interaction(Interactiondiagram)
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 :
Page
107
5. être facile à utiliser et posséder les points forts des langages de
programmation orientés objet comme le C++.
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).
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.
L'architecture 3-Tiers
Page
108
La différence fondamentale se trouve dans le fait que l'architecture 3-Tiers
sépare la couche Buisness logic (couche métier) de la couche Data access (accès
aux données).
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).
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
109