Université Abou Bekr Belkaid de Tlemcen Faculté des Sciences de l’ Ingénieur Ingénieur Département d’ Informatique Informatique
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
Kazi Aouel Bassim et Rostane Zakaria
Encadrés par Mr. par Mr. Ziani Ziani Cherif Salim Présenté le 08 novembre 2007 devant le jury : Mr. ABDERRAHIM Amine Mr. CHIKH Azzeddine Mr. CHOUITI S-Mohammed
Je dédie ce mémoire À mon père et ma mère pour leur soutien tout au long de mes études Un coucou à Selma et Sofiane À mon grand père « Ba » À tous mes oncles, tantes, cousins et cousines : nabil, djamil, zakia, dounia, nayla, amel et salim, malik, lamia, arselane, chakib, farid, karim, lina, rachida, mustafa, malik 2, ines, salim, linda … A tout mes amis et amies et à tous ceux qui m’ont encouragé
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 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 pour l’aide qu’il nous a apporté On remercie Monsieur Ziani Cherif Salim pour 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 mém oire
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 : 1. Introduction : nous parlerons dans ce chapitre des objectifs que nous voudrions atteindre, ainsi qu’un aperçu des différentes méthodes
existantes. 2. La méthode 2TUP : ce chapitre contient les définitions des
différents concepts utilisés dans ce document.
3. Conception du logiciel : c’est ici que nous allons appliquer la méthode 2TUP au problème de la gestion des enseignements en suivant les phases suivantes : l’étude préliminaire, capture des besoins fonctionnels , analyse, conception et codage. 4. Bilan de la méthode 2TUP : nous allons donner un bref aperçu de ce que pourrait être un ajout d’un nouveau besoin fonctionnel. 5. Conclusion générale
Page 4
TABLE DES MATIERES TABLE DES MATIERES ............................................................................................................................................. 5 INTRODUCTION ...................................................................................................................................................... 7
1. 2. 3. 4.
LE CONTEXTE DE TRAVAIL.......................... ........................................ ............................ ............................. ............................. ............................ ............................ ............................ ................... ..... 7 OBJECTIFS ........................... ......................................... ............................ ............................. ............................. ............................ ............................ ............................ ............................ .......................... ............ 7 COMPARAISON ENTRES LES DIFFERENTES APPROCHES ........................... ......................................... ............................ ............................. ............................ ....................... .......... 8 PRESENTATION DE L’APPLICATION A RÉALISER ........................... ......................................... ............................ ............................. ............................. ............................ ................ .. 9
LA METHODE 2TUP ............................................................................................................................................... 10
1. 2. 3. 4.
DEFINITION D’UN PROCESSUS DE DEVELOPPEMENT LOGICIEL ............................ ........................................... ............................. ........................... ..................... ........ 11 LE PROCESSUS UNIFIÉ ............................ .......................................... ............................ ............................ ............................ ............................. ............................. ............................ ..................... ....... 11 LE PROCESSUS 2TUP .......................... ........................................ ............................ ............................ ............................ ............................. ............................. ............................ .......................... ............ 12 UN PROCESSUS DE MODELISATION AVEC UML ............................ ........................................... ............................. ............................ ............................ ............................ ................. ... 14
CONCEPTION DU LOGICIEL ...................... ................................. ...................... ...................... ...................... ...................... ...................... ....................... ....................... ...................... .................... ......... 16
1.
2.
3.
4.
5.
ETUDE PRÉLIMINAIRE ........................... ......................................... ............................ ............................ ............................ ............................. ............................. ............................ ................... ..... 16 1.1.
Présentation du projet à réaliser ................................ .............................................. ............................ ............................. ............................. ............................ ................... ..... 16
1.2.
Recueil des besoins fonctionnels ........................... .......................................... ............................. ............................ ............................ ............................ ........................ .......... 16
1.3.
Choix techniques........................... ......................................... ............................ ............................ ............................ ............................. ............................. ............................ ..................... ....... 18
1.4.
Identification des acteurs ........................... ......................................... ............................ ............................ ............................ ............................. ............................ ..................... ........ 19
1.5.
Identification des messages ........................... .......................................... ............................. ............................ ............................ ............................ ............................ ................. ... 20
1.6.
Modélisation du contexte ........................... ......................................... ............................ ............................ ............................ ............................. ............................ ..................... ........ 21
CAPTURE DES BESOINS FONCTIONNELS .......................... ......................................... ............................. ............................ ............................ ............................ ........................ .......... 22 2.1.
............................. ............................. ............................ ............................ ............................ ........................ .......... 22 Déterminer les cas d’utilisations.............. d’utilisations............................
2.2.
Description préliminaire des cas d’utilisations ............................ .......................................... ............................ ............................ ............................ ................. ... 25
2.3.
......................................... ............................ ............................ ............................ ........................ .......... 26 Description détaillée des cas d’utilisations ...........................
2.4.
Structuration des cas d’utilisations dans des packages ............................ .......................................... ............................ ............................ ................. ... 43
2.5.
Identification des classes candidates ........................... .......................................... ............................. ............................ ............................ ............................ ................. ... 44
ANALYSE ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................. ........................... ............ 50 3.1.
Découpage en catégories ........................... ......................................... ............................ ............................ ............................ ............................. ............................ ..................... ........ 50
3.2.
Dépendances entre catégories ............................ .......................................... ............................ ............................. ............................. ............................ .......................... ............51
3.3.
............................ ............................ ............................. ............................. ............................ ................... ..... 54 Diagramme de packages d’analyse.............. d’analyse ............................
3.4.
Développement du modèle statique ............................ ........................................... ............................. ............................ ............................ ............................ ................. ... 55
3.5.
Développement du modèle dynamique ........................... ......................................... ............................ ............................. ............................. ............................ .............. 62
CONCEPTION ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................. .................... ..... 79 4.1.
......................................... ............................. ............................ ............................ ............................ ............................ ................. ... 79 Architecture de l’application ..........................
4.2.
Les Design Patterns .......................... ........................................ ............................ ............................. ............................. ............................ ............................ ............................ ................. ... 80
CODAGE .......................... ......................................... ............................. ............................ ............................ ............................ ............................ ............................ ............................. ............................ ............... 89 5.1.
La génération d e code avec NetBeans 5.5: ............................ .......................................... ............................ ............................. ............................ ..................... ........ 89
5.2.
»....................................... ............................. ............................ ............................ ............................ ............................ ........................ .......... 89 L’application « JStudent »........................
BILAN DE LA METHODE .......................................................................................................................................100 CONCLUSION GENERALE ..................... ................................ ...................... ...................... ....................... ....................... ...................... ...................... ...................... ...................... ...................... ............103 .103
Page 5
BIBLIOGRAPHIE
...................................................................................................................................................104
ANNEXE : .............................................................................................................................................................105
L’ APPROCHE ......................................... ............................ ............................. ............................. ............................ ............................ ............................ ................ 105 APPROCHE ORIENTEE OBJET ........................... UML ........................... .......................................... ............................. ............................ ............................ ............................ ............................ ............................ ............................. ............................. .......................... ............ 106 LE LANGAGE J AVA ........................... ......................................... ............................ ............................. ............................. ............................ ............................ ............................ ............................ ...................... ........ 108 DIFFERENCE ENTRE L’ ARCHITECTURE .......................................... ............................. ........................... ................... ...... 109 ARCHITECTURE 3-TIERS ET LE MODELE MVC ...........................
Page 6
Introduction 1. LE CONTEXTE DE TRAVAIL La complexité croissante des systèmes informatiques a conduit les concepteurs à s’intéresser aux méthodes de développement. Ces dernières ont toujours essayé d’apporter un contrôle continu sur un projet tout au long de son processus de vie.
Bien que des méthodes de développement existent depuis 30 ans (Merise, SADT), nous ne pouvons constater aujourd’hui l’existence d’une règle qui soit à la fois
formelle et commune aux différentes diff érentes cultures. Par ailleurs, des méthodes séquentielles comme celles se basant sur le cycle en V, ont montré leur limite dans un environnement régi par des changements réguliers, impliquant une impossibilité à revenir en arrière, et de ce fait, laissant une très petite marge à l’erreur . Avec l’avènement de la pensée objet, de nouvelles méthodes sont apparues et différentes notations ont été établies. UML a ouvert le terrain de l’unification en fusionnant ces notations et en apportant précision et rigueur à la définition des concepts introduits. Sur cet élan, les spécialistes ont aussi pensé à unifier non pas les processus, mais plus exactement les meilleures pratiques de développement orienté objet.
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éveloppemen t, 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. ensuite imposé, parce qu’il réduit la complexité de réalisation des phases, en travaillant par approches successives et incrémentales. L’itératif s’est
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 voulant s « unifier » les différentes méthodes objets existantes à ce moment comme Booch, OMT et OOSE . On constate aujourd’hui, l’émergence d’une nouvelle approche : les méthodes agiles (Agile Modeling). C ’est des méthodes itératives à planification souple qui leur permettent de s’adapter à la fois aux changements du contexte et de
spécifications du projet. (Chromatic, 2005)
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 Devant le nombre de méthodes disponibles, le choix parmi elles devient difficile, beaucoup de questions peuvent se poser à un chef de projet lors d’un démarrage de
projet : Comment vais-je organiser les équipes de développement ; Quelles tâches attribuer à qui ; Quel temps faudrait-il pour livrer le produit ; Comment faire participer le client au développement afin de capter les besoins de celui-ci ; Comment éviter des dérives et de mauvaises estimations qui vont allonger les coûts et le temps de développement. Comment vais-je procéder pour que le produit soit évolutif et facilement maintenable.
Nous pouvons citer à ce propos les méthodes de développement objet suivantes : 2TUP, RUP, XP, AUP et OpenUP. 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 PROC ESSUS DE DEVELOPPEMENT LOGICIEL 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 s ystè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)
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.
itérative et incrémentale : la méthode est itérative dans le sens où elle propose de faire des itérations lors de ses différentes phases, ceci garantit que le modèle construit à chaque phase ou étape soit affiné et amélioré. Chaque itération peut servir aussi à ajouter de nouveaux incréments. conduite par les cas d’utilisation
: elle est orientée utilisateur pour répondre
aux besoins de celui-ci. : les modèles définit tout au long du processus de développement vont contribuer à établir une architecture cohérente et solide.
centrée sur l’architecture
pilotée par les risques : en définissant des priorités pour chaque fonctionnalité, on peut minimiser les risques d’échec du projet.
La gestion d’un tel processus est organisée d’après les 4 phases suivan tes :
1. Préetude(Inception) Préetude(Inception) : c’est ici qu’on évalue la valeur ajoutée du
développement et la capacité technique à le réaliser (étude de faisabilité). 2. Elaboration : sert à confirmer l’adéquation du système aux besoins des utilisateurs et à livrer l’archite cture de base.
Page 11
3. Construction : sert à livrer progressivement toutes les fonctions du
système. 4. Transition : déployer le système sur des sites opérationnels.
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é.
Ces activités de développement sont définies par 6 disciplines fondamentales qui décrivent la capture des besoins, la modélisation métier, l’analyse et la conception , l’implémentation, le test et le déploiement . Notons que ces différentes étapes (ou disciplines) peuvent se dérouler à travers plusieurs phases. Le processus unifié doit donc être compris comme une trame commune des meilleures pratiques de développement.
3. LE PROCESSUS 2TUP On dit de la méthode
UP qu’elle est générique c.à.d. qu’elle définit un certain
nombre de critères de développement, que chaque société peut par la suite personnaliser afin de créer son propre processus plus adapté à ses besoins . C’est dans ce cadre que la société Valtech a crée la méthode 2TUP.
2TUP signifie « 2 Track Unified Process» .C’est
aux caractéristiques du Processus Unifié. Le processus 2TUP apporte une réponse aux un processus qui répond
contraintes de changement continuel imposées aux systèmes d’information de l’entreprise. En ce sens, il renforce le contrôle sur les capacités d’évolution et de
correction de tels systèmes. « 2 Track» signifie littéralement que le processus suit deux chemins. Il s’agit des « chemins fonctionnels » et « d’architecture technique », qui correspondent aux deux axes de changement imposés au système d’informati on.
Page 12
Figure : Le système d’information soumis à deux types de contraintes
La branche gauche (fonctionnelle) : capitalise la connaissance du métier de l’entreprise. Elle constitue généralement un investissement pour le moyen et le long
terme. Les fonctions du système d’ information
sont en effet indépendantes des technologies
utilisées. Cette branche comporte les étapes suivantes : La capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur le métier des utilisateurs. L’analyse.
La branche droite (architecture technique) : capitalise un savoir-faire technique. Elle constitue un investissement pour le court et moyen terme. Les techniques développées pour le système peuvent l’être en effet indépendamment des fonctions à réaliser.
Cette branche comporte les étapes suivantes : La capture des besoins techniques. La conception générique.
La branche du milieu : à l’issue des évolutions du modèle fonctionnel et de l’architecture technique , la réalisation du système consiste à fusionner les résultats des 2 branches. Cette fusion conduit à l’obtention d’un processus en forme de Y.
Cette branche comporte les étapes suivantes : La conception préliminaire. La conception détaillée. Le codage.
L’intégration.
Page 13
Figure : Le processus de développement en Y
4. UN PROCESSUS DE MODELISATION AVEC UML Le processus 2TUP s’appuie sur UML tout au long du cycle de développement,
car les différents diagrammes de ce dernier permettent de part leur facilité et clarté, de bien modéliser le système à chaque étape.
UML se définit comme un langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier, concevoir des solutions et communiquer des points de vue. (Pitman, 2006) « Unified Modeling Language » :
UML unifie à la fois les notatio ns et les concepts orientés objet.il ne s’a git 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 : représente la structure des fonctionnalités nécessaires aux utilisateurs du système. Il est normalement utilisé lors des étapes de capture des besoins fonctionnels et techniques. Le diagramme des cas d’utilisation :
représente les règles d’enchaînement des activités et actions dans le système. Il peut être assimilé comme un algorithme mais schématisé. Le diagramme d’activités :
Le diagramme de packages : présent depuis UML 2.0, ce diagramme modélise
des catégories cohérentes entre elles, pour un souci de partage des rôles. Correspond à l’étape de modélisation des différents scénarios d’un cas d’utilisation.
Le diagramme de classes : sûrement l’un des diagrammes les plus importants
dans un développement orienté objet. Sur la branche fonctionnelle, ce diagramme est prévu pour développer la structure des entités manipulées par les utilisateurs. En conception, le diagramme de classes représente la structure d’un code orienté objet. Le diagramme de séquence : représente les échanges de messages entre objets, dans le cadre d’un fonctionnement particulier du système. Le diagramme d’états : représente le cycle possibles d’une classe et leur enchainement.
de v ie d’un objet. Il spécifie les états
Ce diagramme est utilisé lors des étapes d’analyse et de conception.
Page 15
Concep Conc epttion du logic ogiciel iel 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.
1.1.
Présentation du projet à réaliser
C’est un logiciel qui doit gérer le
cursus universitaire des étudiants dans le système
LMD en général. Il doit permettre de suivre les étudiants depuis leur inscription à l’université jusqu’à l’obtention du diplôme de Licence.
1.2.
Recueil des besoins fonctionnels
Nous avons effectué plusieurs recherches pour identifier au mieux les besoins de l’application, et ceci afin de répondre aux attentes des utilisateurs. Nous sommes allés chercher les informations au sein de l’administration de la Faculté. Cette phase correspond à une recherche sur le terrain pour bien définir le cadre de notre système. Nous nous sommes aussi procuré quelques documents, qui expliquent le mode de fonctionnement du système LMD, et ça nous a permis d’établir le cahier des charges préliminaire suivant :
Page 16
Organisation des départements : _____________________________________________________________________
Une université se compose de plusieurs départements (informatique, physique, maths, chimie …), dont chacun est dirigé par un u n chef de département.
Chaque département voit son parcours de formation structuré en 3 paliers : -
Le premier palier doit être composé au plus de 2 semestres. Le deuxième palier d’au moins 2 semestres. semestres. Le troisième palier est une étape de spécialisation.
Organisation du parcours de formation dans le système LMD: _____________________________________________________________________
La formation en vue de l’obtention du diplôme de licence est répartie en 6 semestres, à la différence d’une formation classique. Les parcours sont organisés en unités d’enseignements(UE) articulées entre elles. Une UE est constituée d’une ou de plusieurs « matières » dispensés par toute forme d’enseignements (Cours, Travaux Dirigés, Travaux Pratiques, projets). Chaque UE et chacune de ses matières constitutives sont affectées d’une valeur en crédits.
La valeur totale de ces crédits est fixée à 30 par p ar semestre. Une UE est considérée comme acquise si la moyenne de l’ensemble des notes obtenues dans les matières qui la constituent, affectées de leurs coefficients respectifs, est égale ou supérieur à 10. Pour chaque semestre d’enseignement, deux sessions de contrôle sont organisées.la
deuxième session est une session de rattrapage. Le semestre est acquis pour tout étudiant ayant obtenu l’ensemble des UEs qui le
composent. Le semestre peut être également acquis par compensation entres les différentes UEs. La moyenne générale est calculée sur la base des moyennes obtenues aux UEs composant le semestre pondérées par leurs coefficients respectifs. Le semestre est alors acquis si cette moyenne est égale ou supérieure à 10. En cas d’échec à la première session, l’étudiant se présente aux examens de rattrapage pour les UEs non acquises. L’étudiant garde le bénéfice des matières de l’UE pour lesquelles il a obtenu une
moyenne égale ou supérieure à 10. Progression : _____________________________________________________________________
La progression du premier au second semestre d’une même année universitaire est de droit pour tout étudiant inscrit dans le même parcours.
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 3 0 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. L’acquisition du diplôme de Licence est effective si l’étudiant a validé les 6 semestres du
cursus de formation. Gestion des promotions : _____________________________________________________________________
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. Gestion des étudiants : _____________________________________________________________________
Un étudiant dés son inscription à l’université, peut être affecté à une promotion selon la filière qu’il a choisie.
1.3.
Choix techniques
Voici les choix techniques qui ont été adoptés pour le projet :
La modélisation avec UML.
Adoption d’une architecture à 3 couches.
Utilisation du langage Java.
Omission d’une base de données au profit de la sérialisat ion (Java). Utilisation des Design Patterns (MVC, Etat, Façade …). Utilisation de l’EDI NetBeans et de son plugin UML.
Remarque : la branche droite qui désigne l’étude de l’architecture technique va être ignorée, du fait du manque de temps à notre disposition et de la complexité de la chose.
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é. Les acteurs du système identifiés dans un premier temps sont :
Etudiant : Etudiant :
Un étudiant peut consulter ses relevés de notes, son emploi du
temps. le chef de département établit le cursus de son département, il crée les promotions et suit leur évolution. Il choisit les enseignants responsables des cours.
Chef de département :
Scolarité :
la scolarité introduit les notes des étudiants.
Enseignant : l’enseignant affecte les notes des étudiants de son module .
Administrateur : crée les profils utilisateurs et attribue les droits d’accès.
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. Définition : un message représente la spécification d’une communication unidirectionnelle entre les objets qui transporte de l’information avec l’intention de
déclencher une activité chez le récepteur. Le système émet les messages suivants :
Les relevés de notes des étudiants. L’état d’avancement d’une promotion. Le cursus d’un étudiant. Les emplois du temps d’une promotion. Les modules d’un département.
Les fiches des étudiants. Les fiches des enseignants.
L’organisation d’un département. La liste des étudiants passés et recalés à la fin d’un semestre.
La liste des étudiants ayant acquis leur diplôme.
Le système reçoit les messages suivants
:
Les créations, modifications, suppressions étudiants/enseignants. Les créations, créations, modifications, modifications, de promotions.
de
fiches
des
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 d es 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.
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 :
Description des besoins fonctionnels
Utilisateurs finaux
L’application doit permettre au chef de département de : S’authentifier
Chef de département
Créer son département Créer une promotion Créer les spécialités/options spécialités/options Créer les UE et les Modules Suivre les promotions en cours Affecter les étudiants/enseignants à une promotion
L’application doit permettre à la Scolarité de : S’authentifier
Scolarité
Enseignant
Créer/modifier les fiches des étudiants Affecter les notes des étudiants
L’application doit permettre à l’enseignant S’authentifier
Affecter les notes des étudiants pour son module
L’application doit permettre à l’étudiant S’authentifier
Etudiant
de :
de :
Consulter son relevé de notes Consulter son emploi du temps Consulter ses modules en dettes
L’application doit permettre à l’administrateur de S’authentifier
Administrateur
Créer les profils utilisateurs
Donner des droits d’accès
Page 21
:
2. CAPTURE DES BESOINS FONCTIONNELS Cette phase représente un point de vue « fonctionnel » de l’architecture système. Par le biais des cas d’uti lisation,
nous serons en contact permanent avec les acteurs du système en vue de définir les limites de celui-ci, et ainsi éviter de trop s’éloigner des
besoins réels de l’utilisateur final.
2.1.
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é. Utilisation d’outils de génération de diagrammes UML :
Tout au long du projet, nous sommes passés par plusieurs outils qui génèrent les diagrammes UML. Nous allons faire une présentation rapide de ceux là. 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. 2 Bouml : 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. NetBeansUML 3: c’est un plugin intégré à l’EDI NetBeans, il est très puissant avec de grandes possibilités de personnalisation, cependant il souffre d’une lourdeur assez gênante si on n’a pas une machine puissan te. Nous l’avons utilisé
pour quelques Design Pattern et pour la génération de code.
1
Peut être téléchargé à l’adresse suivante : http://argouml.tigris.org/ Peut être téléchargé à l’adresse suiv ante : http://bouml.free.fr/ 3 Le site de NetBeans : http://www.netbeans.org/ 2
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. d 'utilisations.
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, Créer les UE et les Modules.
Organiser un département
Chef de département
Gérer les promotions
Chef de département
Emet : Créer une promotion, Affecter les étudiants étudiants à une promotion promotion
Suivre les promotions
Chef de département
Emet : Commencer la promotion, sélectionner les enseignants/semestre, enseignants/semestre, commencer/terminer un semestre, passer au prochain semestre, orienter les étudiants vers les spécialités, Reçoit : liste des étudiants endettés, Liste des étudiants non endettés.
Gérer les étudiants
Scolarité
Maintenir les notes
Scolarité, Enseignant
Consulter les notes
Etudiant
Page 23
Emet : Créer/modifier les fiches des étudiants. Emet : Affecter les notes aux étudiants, gérer les rattrapages, gérer les modules en dettes. Reçoit : relevé de notes Reçoit : consulter son relevé de notes.
Gérer les emplois du temps
Scolarité
Consulter les emplois du temps
Etudiant, Enseignant
Gérer les profils
Administrateur
Emet : Créer/modifier les emplois du temps Reçoit : consulter les emplois du temps. Emet : Création, modification, suppression 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. Remarque 2: Ce premier tableau n'est pas définitif, un processus de développement avec UML est itératif, il se peut p eut qu'il change au fur et à mesure de l'avancement du projet.
Diagramme des cas d’utilisation
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
:
Organiser les départements :
Intention : gérer les départements d épartements. Actions : créer un nouveau domaine, une nouvelle spécialité, une nouvelle option, créer les UE, modifier les UE …
Gérer les promotions :
Intention : gérer les promotions. Actions : créer une nouvelle promotion, affecter des étudiants, modifier ou annuler la promotion.
Etablir les emplois du temps :
Intention : créer l’emploi du temps pour une promotion. Actions : créer un nouvel emploi du temps, affecter à une unité d’heure un module et un enseignant, modifier ou annuler l’emploi du temps.
Gérer les étudiants :
Intention : suivi des dossiers des étudiants après inscription de ces derniers. Actions : créer le dossier étudiant, rattacher l’étudiant à une année universitaire, universitaire, mettre à jour le dossier.
Gérer les profils :
Intention : créer les différents profils des utilisateurs du système. Actions : créer un nouveau profil, attribuer une fonction, attribuer des droits d’accès, modifier le profil, créer un mot de p asse.
Maintenir les notes des étudiants :
Intention : affecter les notes aux étudiants. Actions : affecter les notes aux étudiants pour chaque module.
Consulter l’emploi du temps :
Intention : consulter l’emploi du temps d’une promotion. Actions : consulter l’emploi du temps.
Consulter les notes :
Intention : consulter les notes d’un étudiant. Actions : choisir un étudiant et consulter la liste de ses notes.
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. Remarque : les descriptions vont être organisées de la façon f açon suivante :
Un sommaire d’identification : va résumer les propriétés du cas d’utilisation.
Une description détaillée : des Préconditions au déclenchement du cas d’utilisation doivent êtr e spécifiées, un scénario nominal décrivant celui-ci additionné à des scénarios alternatifs et d’exceptions.
Les diagrammes (optionnelle): plusieurs diagrammes vont apparaitre (mais pas nécessairement) pour apporter une compréhension additive au cas d’util isation.
Page 26
Organiser les DÉPARTEMENT DÉPARTEMENTS: S: Sommaire D’IDENTIFICATION: ______________________________________________________________ Titre : Organiser les licences But : créer des domaines, des spécialités, des options. Résumé : créer un nouveau domaine, une nouvelle spécialité, une nouvelle option Acteur : Chef de département
Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions 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. Enchaînement (a) : Créer un domaine en construction
Le chef de département choisit un nom pour le département. Enchaînement (b) : Créer un tronc commun
Pour la première année un tronc commun va être constitué. La durée de ce tronc commun est variable selon le domaine. Enchaînement (c) : Créer les spécialités/options spécialités/options
Il peut spécifier les spécialités/options que le domaine va contenir. Une durée en semestres doit être renseignée. Enchaînement (d) : valider un domaine en construction
Le chef de département valide la création.
Page 27
Si le domaine existe déjà déclencher : [Exception1 : DomaineExistant] DomaineExistant] Enchaînements Enchaînements alternatifs : Enchaînement (e) : créer les UE
Le chef de département département crée une une UE, et choisit choisit le type de cette UE (fondamentale, complémentaire, méthodologique, optionnelle, transversale, découverte). Il crée les modules pour cette UE , spécifie un nom, le nombre d’heures à enseigner, un coefficient, et un crédit crédit pour chaque chaque module. Il valide le module, si Code existe déjà déclencher : [Exception2 : ModuleExistant] Il valide l’UE, si Code existe déjà déclench er : [Exception3 : UEExistante]
Enchaînement (f) : Modifier un domaine
en construction construction ou validé
Pour un domaine, le chef de département peut ajouter/supprimer une spécialité/option ou modifier un tronc commun . Enchaînement (g) : Supprimer un domaine
Le chef de département peut supprimer un domaine. DomaineUtilise] Si une promotion appartient à ce domaine déclencher :[Exception4 : DomaineUtilise]
Enchaînement (h) : Supprimer une UE
Il peut aussi modifier une UE ou la supprimer. Si l’UE est utilisée dans une promot ion déclencher :[Exception5 : UEUtilisee]
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é. [Exception4 : DomaineUtilise] DomaineUtilise] : un message est affiché à l’écran avisant l’utilisateur
que le
domaine ne peut pas être supprimé. [Exception5 : UEUtilisee] : un message est affiché à l’écran avisant l’utilisateur que l’UE ne pas
être supprimée. Ce cas d’utilisation se termine lorsque le chef de département a validé un domaine.
Page 28
Etablir les PROMOTION PROMOTIONS: S: Sommaire D’IDENTIFICATION: ______________________________________________________________ Titre : Etablir les promotions But : gérer des promotions. Résumé : créer une nouvelle promotion, lui rattacher des étudiants … Acteurs : Chef de département
Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions 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înement (a) : Créer une
promotion en construction construction
Le chef de département choisit un code/nom et l’année de création pour la promotion. Enchaînement (b) : Rattacher à un domaine
Il rattache la promotion à un domaine. Si le tronc commun/Spécialité n’a pas d’UE déclencher :
[Exception1 : NoUECree]
Enchaînement (c) : Rattacher les étudiants
Le chef de département sélectionne tous les étudiants faisant partie de la promotion. Si l’étudiant EtudiantDejaAffecte]
appartient
déjà
à
une
Enchaînement (f) : fixer les dates d’examens
Page 29
promotion
déclencher :
[Exception2 :
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 Enchaînements alternatifs : Enchaînement (h) : Modifier une promotion
en construction ou validée
Le chef de département peut changer en cours d’études, l’enseignant en charge d’un module. Enchaînement (i) : Supprimer une promotion
Le chef de département peut supprimer une promotion si celle-ci n’a pas encore commencé les études. 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. [Exception2 : EtudiantDejaAffecte] : un message d’erreur est affiché sur l’écran avisant l’utilisateur que l’étudiant appartient déjà à la promotion.
Ce cas d’utilisation se termine lorsque le chef de département a validé une promotion.
Page 30
Suivre une PROMOTION: Sommaire D’IDENTIFICATION: ______________________________________________________________ Titre : Suivre une promotion promotion But : permettre le suivi du cursus des étudiants. Résumé : commencer les études, affecter des enseignants à chaque semestre … Acteurs : Chef de département
Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions Préconditions :
1234-
Le chef de département est authentifié. Au moins un enseignant existe dans la base. Au moins un domaine existe. 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. Enchaînement (a) : commencer les études
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. TD/TP/Projet/Séminaire/conférence. Commencer le 1er semestre et la promotion. Enchaînement (b) : remplir les relevés de notes Cas d’utilisation
Maintenir les notes
Enchaînement (c) : terminer le semestre
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 l es é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 l’utilisateur que des relevés de notes ne sont pas complets.
Ce cas d’utilisation se termine lorsque le chef de département a terminé une promotion.
Diagramme D’ACTIVITÉS: ______________________________________________________________
Voici un diagramme d’activités représentant l’enchainement des événements pour le cas d’utilisation : Suivre une promotion.
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:
______________________________________________________________ Titre : Etablir les emploies du temps But : créer des emplois du temps. Résumé : créer un nouvel emploi du temps, en modifier un. Acteurs : Chef de département
Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions 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. Enchaînement (a) : Créer un emploi du
temps en construction
Le chef de département choisit une promotion pour qui l’emploi du
temps est destinée.
Il sélectionne un semestre pour l’année en cours.
Il sélectionne une plage horaire. Enchaînement (b) : Affecter
les charges
Il sélectionne un module parmi les modules de la promo. Il affecte le module à enseigner à cette plage horaire. Si le module à enseigner est déjà attribué alors déclencher :
[Exception1 :
moduleErreur]
Il affecte un enseignant à cette plage horaire. Si l’enseignant est déjà pris pour cette plage alors déclencher : [Exception2 : enseignantErreur]
Enchaînement (c) : Valider un emploi du temps en
Page 34
construction
Le chef de département valide l’emploi du temps . Enchaînements Enchaînements alternatifs : Enchaînement (d) : Modifier un emploi du temps en construction ou validé
Le chef de département désaffecte une charge pour une plage horaire. Enchaînement (e) : Supprimer un emploi du temps
Le chef de département supprime un emploi du temps. 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.
Ce cas d’utilisation se termine lorsque le chef de d épartement a validé un emploi du d u temps.
Diagramme D’ACTIVITÉS: _____________________________________________________________
Diagramme d’activités
Page 35
Consulter les emplois du TEMPS: Sommaire D’IDENTIFICATION:
______________________________________________________________ Titre : Consulter les emploies du temps But : consulter un emploi du temps. Résumé : s’authentifier et afficher l’emploi du temps pour une promotion. Acteurs : enseignant, étudiant.
Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions Préconditions : L’utilisateur est authentifié.
Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande à consulter l’emploi
du temps. Enchaînement (a) : Consulter un emploi du temps L’utilisateur sélectionne une promotion. L’utilisateur L’utilisat eur sélectionne ensuite un semestre pour l’année en cours. Il affiche ensuite l’emploi du temps correspondant.
Ce cas d’utilisation se termine lorsque l’utilisateur se déconnecte.
Page 36
Gérer les fiches des étudiants : Sommaire D’IDENTIFICATION: ______________________________________________________________ Titre : Gérer les fiches des étudiants But : créer des dossiers étudiants. Résumé : créer un nouveau dossier, modifier un dossier existant. Acteurs : Scolarité.
Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions 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înement (a) : Créer un dossier étudiant en construction
Le chef de département choisit choisit un nom/prénom/date nom/prénom/date et lieu de naissance. Il remplit le numéro d’inscription. Il peut choisir éventuellement l’année d’inscription. Remplir les informations sur l’état civil.
Enchaînement (b) : Valider dossier étudiant en construction
Le chef de département doit avoir rempli toutes les informations obligatoires. Enchaînements Enchaînements alternatifs : Enchaînement (c) : Modifier un dossier étudiant en construction ou
validé
Le chef de département met à jour ce dossier quand cela est nécessaire. Si l’étudiant est déjà inscrit, spécifier la nouvelle année d’inscription.
Page 37
Enchaînement (d) : Supprimer un dossier étudiant Le chef de département peut supprimer un dossier étudiant s’il n’appartient
à aucune
promotion au préalable.
Ce cas d’utilisation se termine lorsque le chef de département a validé un dossier étudiant.
Diagrammes d’activités : ______________________________________________________________
Diagramme d’activités
Page 38
Maintenir les notes des ÉTUDIANTS: Sommaire D’IDENTIFICATION:
______________________________________________________________ Titre : Maintenir les notes But : affecter les notes aux étudiants. Résumé : choisir un étudiant, un module, affecter la note. Acteurs : Enseignant, Scolarité.
Descriptions des ENCHAÎNEMENTS: _______________________________________________________ Préconditions Préconditions :
1. Le responsable de la scolarité ou l’enseignant est authentifié. a uthentifié. 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înement (a) : remplir le relevé de notes Le responsable de la scolarité ou l’enseignant choisit une promotion.
Il choisit un étudiant et affiche son relevé de notes. Choisir un module et affecter une note à celui-ci. Enchaînement (b) : Valider une fiche notes
Valider les données. Enchaînements Enchaînements alternatifs : Enchaînement (c) : modifier une fiche notes en construction/validée La scolarité peut modifier une note d’un module.
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. [Exception2 : ModuleDejaNoté] : Si l’acteur est l’enseignant alors il ne p eut plus modifier la note, sinon un message d’information reste affiché sur l’écran demandant la confirmati on du
changement de la note et de la raison.
Ce cas d’utilisation se termine lorsque le chef de département a validé la fiche de notes de l’étudiant.
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: ______________________________________________________________ Titre : Consulter les notes But : consulter une fiche de notes. Résumé : s’authentifier et afficher la fiche de not es es pour un étudiant. Acteurs : étudiant.
Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions Préconditions :
1. L’utilisateur est authentifié. 2. Au moins un dossier étudiant est crée. Scénario nominal : Ce cas d’utilisation commence lorsque l’étudiant se connecte à son compte. Enchaînement (a) : Sélectionner un étudiant
Le responsable choisit une promotion. Il choisit un étudiant. Enchaînement (b) : Afficher les notes
Il sélectionne un semestre à afficher et affiche ses notes. Ce cas d’utilisation se termine lorsque l’étudiant s’est déconnecté.
Page 41
Gérer les PROFILS: Sommaire D’IDENTIFICATION: ______________________________________________________________ Titre : Gérer les profils But : créer les profils utilisateurs. Résumé : créer un nouveau profil et lui affecter des droits d’accès. Acteurs : Administrateur.
Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions Préconditions :
Aucunes. Scénario nominal : Ce cas d’utilisation commence lorsque l’administrateur lance le logiciel. Enchaînement (a) : Créer un profil en construction L’administrateur choisit un nom / mot de
passe pour le compte.
Il choisit le type de ce compte. Ce cas d’utilisation se termine lorsque le chef de département a validé un profil en construction.
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 ». Définition : un package représente un espace de nommage qui peut contenir : 1. Des éléments d’un modèle. 2. Des diagrammes qui représentent les éléments du modèle. 3. D’autres packages. La structuration des cas d’utilisations se fait par domaine d’expertise métier c.à.d. les éléments contenus dans un package doivent représenter un ensemble fortement
cohérent et sont généralement de même nature et de même niveau sémantique.
Cas d’utilisation
Acteurs
Package
Organiser un département
Chef de département
Gestion des départements
Gérer les promotions
Chef de département
Suivre les promotions
Chef de département
Maintenir les notes
Scolarité, Enseignant
Consulter les notes
Etudiant
Gérer les emplois du temps
Scolarité
Consulter les emplois du temps
Etudiant, Enseignant
Gestion des promotions
Gestion des notes
Page 43
Gestion des emplois du temps
Gérer les profils
2.5.
Administrateur
Gestion des profils
Identification des classes candidates
Cette phase va préparer la modélisation orientée objet en aidant à trouver les classes principales du futur modèle statique d’analyse.
La technique utilisée pour identifier les classes candidates est la suivante : - Chercher les noms communs importants dans les descriptions textuelles des cas d’utilisation.
- Vérifier les propriétés « objet » de chaque concept (identité, propriétés, comportement), puis définir ses responsabilités. 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écouve rte 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 d épartements » :
Les classes candidates sont tirées de la description textuelle du cas d’utilisation et des diagrammes dynamiques représentant celui-ci : Domaine, Discipline, UE, Module.
Diagramme des classes participantes « Organiser les départements »
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 : Promotion, Domaine, Enseignant, Etudiant, Tronc_Commun, Specialite.
Diagramme des classes participantes « Etablir les promotions »
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 : Promotion, Semestre, Domaine, Enseignant, Etudiant.
Diagramme des classes participantes « Suivre les promotions »
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 : Emploi du temps, Plage horaire, UE, Module, Enseignant.
Diagramme des classes participantes « Etablir les emplois du temps »
Page 48
Diagramme des classes participantes 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 : Fiche notes, Note, Module, Etudiant.
Diagramme des classes participantes « Maintenir les notes »
Page 49
3. ANALYSE 3.1.
Découpage en catégories
Cette phase marque le démarrage de l’analyse objet du système à réaliser. Elle utilise la notion de package pour définir des catégories de classes d’analyse et découper le modèle UML en blocs logiques les l es plus indépendants possibles. Le découpage en catégories constitue la première activité de l’étape d’analyse et elle va s’affiner de manière itérative au cours du développement du projet. Elle se
situe sur la branche gauche du cycle en Y et succède à la capture des besoins fonctionnels. Pour passer à l’analyse, il faut se base r 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.
Définition : une catégorie consiste en un regroupement logique de classes à forte cohérence interne et faible couplage externe. Le découpage en catégories de notre projet a donné le résultat suivant :
Page 50
Découpage en catégories
3.2.
Dépendances entre catégories
Classe « Promotion » :
Associations de la classe Promotion
Page 51
Classe « Fiche notes » :
Associations de la classe Fiche Notes
Page 52
Classe « Emploi du temps » :
Associations de la classe Emploi du temps te mps
Page 53
3.3.
Diagramme de packages d’analyse Ce diagramme va représenter les différentes dépendances entre les packages d’analyse :
Diagramme de packages d’analyse
Remarque : ce diagramme a été obtenu après plusieurs itérations. 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 Développeme nt 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. Il s’agit d’une activité itérative, fortement couplée avec la modélisation dynamique .
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.
Diagramme de classe de la catégorie « Promotion »
Page 56
Et voici les opérations/attributs de la classe Promotion.
Classe Promotion (attributs/opérations) (attributs/opérations)
Page 57
Et voici les opérations/attributs de la classe Semestre.
Classe Semestre (attributs/opérations) (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 de la catégorie « Relevé de Notes »
Et voici les opérations/attributs des classes Relevé de Notes et Note.
Classes ReleveNotes et Note (attributs/opérations)
Page 59
Catégorie « Enseignants » : Voici le diagramme de classe de la catégorie Enseignants.
Diagramme de classe
Et voici les opérations/attributs de la classe Enseignant.
Classe Enseignant (attributs/opérations) (attributs/opérations)
Page 60
Catégorie « Etudiant » Etudiant » :
Classe Etudiant (attributs/opérations) (attributs/opérations)
Catégorie « Emploi du temps » : Voici le diagramme de catégories de la classe Emploi du temps.
Associations de la catégorie « Emploi du temps »
Page 61
3.5.
Développement Développeme nt 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.
Identification des scénarios : Un cas d’utilisation décrit un ensemble de scénarios. Un scénario décrit une exécution particulière d’un cas d’utilisation du début à la fin.il correspond à une sélection d’enchainements du cas d’utilisation.
On peut distinguer plusieurs types de scénarios :
Nominaux : ils réalisent les post conditions du cas d’utilisation, d’une façon
naturelle et fréquente ;
Alternatifs : ils remplissent les post conditions du cas d’utilisation, mais en
empruntant des voies détournées ou rares ;
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 ;
D’erreur : ne réalisent pas les post conditions du cas d’utilisation.
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 : Enumération des scénarios :
Scénarios nominaux :
Scénarios alternatifs :
OL_N1 : créer un nouveau domaine. OL_N2 : créer des UE pour un Tronc_Commun ou Specialite.
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.
Description détaillée des scénarios :
La description détaillée va permettre de, mettre en évidence les interactions entre les différents objets. Cependant, du fait de l’existence de nombreux scénarios, nous allons détailler seulement quelques uns d’entre eux.
Scénarios nominaux :
OL_N1 : créer un nouveau domaine. Le chef de département donne un nom/mot de passe d’identification. Il choisit un code/nom pour le domaine. Un tronc commun est créé. Le chef de département fixe la durée en semestres de celui-ci. Il crée les spécialités du domaine, en choisissant pour chacune d’elle la durée. Pour décrire ce scénario, nous allons faire intervenir les instances suivantes : o
Un acteur Chef de département .
Page 63
o o o
Un objet Domaine crée au cours du scénario. Un objet Tronc_Commun crée au cours du scénario. Un objet Specialite crée au cours du scénario.
Diagramme de séquences du scénario « créer un nouveau domaine »
OL_N2 : créer des UE pour un Tronc_Commun ou Specialite. Le chef de département donne un nom/mot de passe d’identification.
Il sélectionne un Domaine existant. Il sélectionne le tronc commun / une spécialité qui n’a pas encore des UE. Il crée une UE en donnant un code/intitulé/crédit. Pour chaque UE crée, il crée plusieurs modules en spécifiant un code/intitulé/crédit. Pour décrire ce scénario, nous allons faire intervenir les instances suivantes : o o o
Un acteur Chef de département . Un objet Domaine crée au cours du scénario. Un objet Tronc_Commun/ Specialite Tronc_Commun/ Specialite crée au cours du scénario.
Page 64
o o
Un objet UE crée au cours du scénario. Un objet Module crée au cours c ours du scénario.
Diagramme de séquences du scénario « créer une UE »
OL_E1 : non validation de la création de domaine pour cause de nom existant déjà.
Diagramme de séquences du scénario « non validation de la création d’un domaine »
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 : Enumération des scénarios :
Scénarios nominaux :
Scénarios alternatifs :
EP _N1 : créer une nouvelle promotion.
EP _A1 : modifier une promotion par ajout d’un enseignant. 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 :
Description détaillée des scénarios :
Scénarios nominaux :
EP_1 : créer une nouvelle promotion. Le chef de département donne un nom/mot de passe d’identification. Il choisit un nom pour la promotion et la durée en semestres, il choisit à quel domaine elle appartient, si c’est un tronc commun ou une spécialité le cas échéant il spécifie l’année du LMD.
Le chef de département sélectionne les enseignants et leur attribue un module à enseigner. Le chef de département sélectionne les étudiants faisant partie de la promotion. Le chef de département valide la promotion. Pour décrire ce scénario, nous allons faire intervenir les instances suivantes : o o o
Un acteur Chef de département . Une Promotion crée au cours du scénario. Un multi-objet représentant les Modules de la spécialité ou du tronc_commun tronc_commun crée cours du scénario.
Page 66
o
o
Un multi-objet représentant l’ensemble des instances de Enseignant qui vont être affectés à la nouvelle promotion. Un multi-objet représentant l’ensemble des instances de Etudiant qui vont être rattachés à la nouvelle promotion.
Diagramme de séquences du scénario « créer une nouvelle promotion »
Page 67
EP _A1 : modifier une promotion par ajout d’un enseignant. Le chef de département donne un nom/mot de passe d’identification.
Il sélectionne une promotion. Le chef de département ajoute un enseignant à la promotion. Le chef de département valide la promotion. Pour décrire ce scénario, nous allons faire intervenir les instances suivantes : o o o
Un acteur Chef de département . Une Promotion crée au cours du scénario. Un objet Enseignant qui va être affecté à la promotion.
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é. Le chef de département donne un nom/mot de passe d’identification.
Il sélectionne une promotion.
Page 68
Il sélectionne un module. Il attribue le module à un enseignant. Le chef de département valide la promotion. Pour décrire ce scénario, nous allons faire intervenir les instances suivantes : o o o o
Un acteur Chef de département . Une Promotion crée au cours du scénario. Un objet Enseignant qui va est affecté à la promotion. Un objet Module qui va être affecté à un enseignant.
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. Le chef de département donne un nom/mot de passe d’identification.
Page 69
Il sélectionne une promotion. Il sélectionne un enseignant faisant parti de la promotion. Il désaffecte l’enseignant de son module.
Le chef de département valide la promotion. Pour décrire ce scénario, nous allons faire intervenir les instances suivantes : o o o o
Un acteur Chef de département . Une Promotion crée au cours du scénario. Un objet Enseignant qui va être affecté à la promotion. Un objet Module qui va être affecté à un Enseignant .
Diagramme de séquence du scénario « modifier une promotion par libération d’un enseignant chargé d’un module »
EP _A4, EP_A5: modifier une promotion par ajout/enlèvement d’un étudiant.
Le chef de département donne un nom/mot de passe d’identification.
Page 70
Il sélectionne une promotion. Il sélectionne un étudiant. Il désaffecte l’étudiant de la promotion.
Le chef de département valide la promotion. Pour décrire ce scénario, nous allons faire intervenir les instances suivantes : o o o
Un acteur Chef de département . Une Promotion crée au cours du scénario. Un objet Etudiant qui va être affecté à la promotion.
Diagramme de séquence du scénario « modifier une promotion ajout/enlèvement d’un étudiant »
Page 71
SCÉNARIOS DE « Etablir les emplois du temps »: Enumération des scénarios :
Scénarios nominaux :
EET_1 : créer un nouvel emploi du temps. Le chef de département donne un nom/mot de passe d’identification.
Il choisit la promotion. Il choisit le semestre. Pour chaque plage horaire sélectionnée, il affecte un module. Pour décrire ce scénario, nous allons faire intervenir les instances suivantes : o o o o o
Un acteur Chef de département . Un emploi du temps crée au cours du scénario. Une Promotion. Un Module. Une plage horaire crée au cours du scénario.
Page 72
Diagramme de séquence du scénario « créer un nouvel emploi du temps »
SCÉNARIOS DE « Gérer les fiches étudiants »: Parmi tous les scénarios possibles pour le cas d’utilisation «
Gérer les fiches
étudiants » (GF) nous avons choisi les suivants : Enumération des scénarios :
Scénarios nominaux : GF_1 : créer un nouveau dossier étudiant. La scolarité donne un nom/mot de passe d’identification.
Il saisit les informations obligatoires obligatoires (n° inscription, nom, prénom). Il saisit les informations facultatives. facultatives. Il saisit les informations sur l’état civil. Pour décrire ce scénario, nous allons faire intervenir les instances suivantes : o o
Un acteur Scolarité . Un étudiant crée au cours du scénario.
SCÉNARIOS DE « Maintenir les notes étudiants »: Parmi tous les scénarios possibles pour le cas d’utilisation « Etablir les promotions » (MN) nous avons choisi les suivants : Enumération des scénarios :
Scénarios nominaux :
Scénarios alternatifs :
MN _N1 : créer une fiche de notes. MN _N2 : affecter les notes pour un étudiant. 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. La scolarité donne un nom/mot de passe d’identification.
Elle choisit une promotion. Elle sélectionne un étudiant. Elle crée la fiche de notes. Pour décrire ce scénario, nous allons faire intervenir les instances suivantes : o o o o
Un acteur Scolarité . Un étudiant crée au cours du scénario. Une Promotion crée au cours du scénario. Une Fiche notes.
Diagramme de séquence du scénario « créer une fiche de notes »
MN _N2 : affecter les notes pour un étudiant. ét udiant. La scolarité donne un nom/mot de passe d’identification.
Elle choisit une promotion. Elle sélectionne un étudiant.
Page 74
Pour chaque module, elle affecte une note (examen, TD, TP, Devoir). Le calcul de la moyenne se fait automatiquement. Pour décrire ce scénario, nous allons faire intervenir les instances suivantes : o o o o
Un acteur Scolarité . Un étudiant crée au cours du scénario. Un objet Promotion crée au cours du scénario. Un objet Note.
Diagramme de séquence du scénario « affecter les notes pour un étudiant »
Remarque : Du fait des contraintes du langage, ces diagrammes sont difficilement implémentables en l’état. Cependant, ils servent à faire surgir les interactions possibles entres les différents objets.
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 possible s. 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 :
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. Diagramme d’états de la classe Promotion :
En attente : de la création d’une instance de Promotion à sa validation, cet
état inclut toutes les opérations de rattachement à un domaine, de rattachements d’enseignants, de rattachements d’étudiants.
Validée (crée) : il représente une Promotion crée et valide.
En cours : cet état représente une Promotion en cours d’enseignement.
Aucun étudiant ne peut être ajouté à ce moment et aucun changement de Module ou d’UE ne peut être autorisé. Cependant, un enseignant peut être remplacé.
Terminée : cet état survient après la fin des délibérations de la dernière session d’examen.
Page 76
Diagramme d’états de la classe Promotion
Diagramme d’états de la classe Etudiant :
Nouvellement Nouvellement inscrit : cet état représente un étudiant qui vient d’être inscrit à l’université.il se produit lorsque l’étudiant est introduit la première fois dans la base et que c’est sa première année à la faculté.
u ne promotion. Rattaché : cet état représente un étudiant qui est attaché à une
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 fai t 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 préliminaire est l’étape où s’effectue la fusion des études fonctionnelles et techniques. La conception détaillée qui vient juste après est une activité qui s’inscrit dans l’organisation définie p ar 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.
4.1.
Architecture de l’applic ation 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. Les couches permettent de présenter l'architecture de l'application. Les équipes de réalisation s'attribuent alors des responsabilités sur le développement de chaque couche. Aussi, si modéliser est indispensable, construire une architecture à couche est un critère de qualité dans le cadre d'un développement Objet. Reste à choisir le nombre de couches et à définir leur contenu.
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). Ceci correspond à une architecture 3-Tiers :
Page 79
Architecture 3-Tiers
4.2.
Les Design Patterns
De nombreuses méthodes existent pour simplifier la phase de conception des logiciels. Parmi les plus connues, considérons Merise et UML. Mais une autre méthode existe, plus proche de l'implémentation. Lors de la conception d'une application de nombreux problèmes peuvent survenir. Le système des Design Patterns, ou motifs de conception, représente un système objet destiné à la résolution de problèmes techniques. (Eric Freeman, 2005) Un Design Pattern constitue un petit ensemble de classes apte à offrir la solution la plus efficace à un problème. La définition d'un motif de conception repose donc sur trois critères. Premièrement, le problème à résoudre est classique et bien connu. Ensuite, l'ensemble des classes employées porte un nom unique (on parle par exemple du motif "Decorator"). Enfin, la solution que propose ce motif correspond à la résolution la plus optimale du problème. (Guy)
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.
Le Design Pattern « Etat » : Définition : Le Design Pattern « Etat » est une façon de concevoir le diagramme d’états d’une classe d’analyse. La gestion des états est déléguée de sorte qu’à chaque état corresponde une classe du patron. Une classe gère ainsi les activités et les transitions attachées à l’état qu’elle représente.
Le Design Pattern « Etat »
Remarque : les diagrammes qui vont suivre ont été crée avec l’outil UML de NetBeans 5.5
Voici les différents diagrammes Etats que nous avons conçus :
Page 81
La Classe Promotion :
Diagramme d’états de 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 :
Design Pattern Etat de 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.
Un exemple du Design Pattern « Façade »
L’application de ce
Design Pattern à notre application se concrétise comme suit :
Page 86
La couche Métier à accès à la BDD grâce au Pattern DAO
Le Design Pattern « Observateur » : Définition : Le Design Pattern Observateur consiste à synchroniser des objets en minimisant les dépe ndances qui devraient s’établir entre eux. Nous distinguons de ce fait le sujet et les observateurs. Le sujet centralise les données et il est unique.il comprend des opérations permettant aux observateurs d’accéder à ses données.
données du sujet auquel il est abonné, et plusieurs peuvent se synchroniser sur le même sujet. L’observateur restitue les
La dynamique d’échange entre le sujet et ses observateurs abonnés s’établit à partir d’une notification indiquant une modification du sujet. Ce dernier en avise ses
observateurs qui questionnent en retour le sujet pour obtenir les informations nécessaires à leur mise à jour. 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 .
Le Design Pattern « MVC » : 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. Ce modèle d'architecture impose la séparation entre les données, les traitements et la présentation, ce qui donne trois parties fondamentales dans l'application finale : le modèle, la vue et le contrôleur :
Le Modèle : représente le comportement de l'application : traitements des données, interactions avec la base de données, etc. Il décrit les données manipulées par l'application et définit les méthodes d'accès. la Vue : correspond à l'interface avec laquelle l'utilisateur interagit. Les résultats renvoyés par le modèle sont dénués de toute présentation mais sont présentés par les vues. Plusieurs vues peuvent afficher les informations d'un même modèle. Elle peut être conçue en html, ou tout autre « langage » de
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.
En résumé, lorsqu'un client envoie une requête à l'application, celle-ci est analysée par le contrôleur, qui demande au modèle approprié d'effectuer les traitements, puis renvoie la vue adaptée au navigateur, si le modèle ne l'a pas déjà fait. Un avantage apporté par ce modèle est la clarté de l'architecture qu'il impose. Cela simplifie la tâche du développeur qui tenterait d'effectuer une maintenance ou une amélioration sur le projet. En effet, la modification des traitements ne change en rien la vue. Par exemple on peut passer d'une base de données de type SQL à XML en changeant simplement les traitements d'interaction avec la base, et les vues ne s'en trouvent pas affectées. (Wikipedia) Comme exemple, « Swing » la bibliothèque graphique de Java pour la création d’interfaces graphiques, est basée sur le modèle MVC. (Cornell)
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. La programmation peut se faire pour des exemples simples avec le compilateur javac, mais pour avoir plus de confort il est préférable d'utiliser un environnement de développement intégré ou IDE. qui nous fournit le confort et la simplicité nécessaires à un développement propre et rapide.
Notre choix s’est porté vers l’EDI NetBeans,
5.1.
La génération de code avec NetBeans 5.5:
Grace au plugin UML intégré à NetBeans, nous avons pu créer les différents diagrammes UML définis lors de la phase de conception. Mais aussi, nous allons l’utiliser pour la génération du code à partir des diagrammes de classes. Nous bénéficierons dans ce cas d’un gain de temps non négligeable, du qu’il peut générer aussi les différents packages avec leurs classes respectives.
5.2.
L’application « JStudent »
Page 89
fait
Structure générale de l’application 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’inter médiaire médiaire entre les autres couches et la Base de données.
Figure représentant les 3 couches de l’application
Page 90
La couche Métier :
Voici quelques figures représentants un échantillon du code source de cette couche :
La classe « Promotion » (à gauche les Attributs et et les Méthodes)
Page 91
La classe « Domaine » (à gauche les Attributs et et les Méthodes)
Page 92
La classe « Etudiant » (à gauche les Attributs et les Méthodes) Méthodes)
Page 93
La couche Présentation : Voici quelques figures représentants l’interface du lo giciel :
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.
Etude du cas : Gestion des SALLES Nous avons signalé au début que la gestion des salles a été ignorée pour manque de temps et pour réduire la complexité de notre projet. p rojet. 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é : - Il s’agit de la scolarité qui devra pour chaque promotion, chercher une salle libre afin que les cours puissent puis sent y être enseignés.
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 ».
Description détaillée du cas d’utilisation : Ce cas d’utilisation commence lorsque
la scolarité demande au système de créer
une nouvelle salle. Enchaînement (a) : Créer une salle en construction
La scolarité choisit le bloc auquel la salle appartient. Elle choisit un numéro. Elle spécifie l’étage, le nombre de places disponibles … D’autres enchainements …
Enchaînement alternatifs : Créer un bloc en construction
Identification des classes candidates : A la suite de cette description détaillée, nous pouvons en déduire déjà deux classes : Bloc, Salle.
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 poss ibles 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.
Page 101
Ceci ne devrait pas affecter le codage en général, du fait que les responsabilités des d es 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 partielle selon le besoin, du cycle 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 domai nes 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.
Nous espérons que la lecture de ce mémoire a été agréable et claire.
Page 103
Bibliographie Chromatic. (2005). Extreme programming. O'Reilly. Cornell, G. Au Coeur de Java. Campus Press. Eric Freeman, E. F.-C. (2005). Design Patterns Tête la première. O'Reilly. Florian GRISONI, N. G. (s.d.). Récupéré sur http://www.cyber06.com/article/mvc.php Guy, R. (s.d.). Récupéré sur http://www.progx.org Meyer, B. (2000). Conception et Programmation orientées objet. Eyrolles. Pitman, N. (2006). UML 2 en concentré. O'Reilly. Rocques, P., & Vallée, F. (2004). UML 2 En Action (De l'analyse des besoins à la conception J2EE). Eyrolles. Roques, P. (2006). UML 2 en pratique. Eyrolles. Wikipedia. (s.d.). Récupéré sur Wikipedia: http://fr.wikipedia.org/
Page 104
Annexe : L’APPROCHE ORIENTEE OBJET Notion de classe Tout d’abord, introduisons la no tion 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, ell e définit les services accessibles (offerts) aux utilisateurs de l’objet.
facilite l’évolution dune application car elle stabilise l’utilisation des objets: on peut modifier l’implémentation des attributs d’un objet sans modifier son interface, et donc la façon f açon dont L’objet est utilisé. L’encapsulation
L’encapsulation garantit l’intégrité des données, car restreindre, l’accès direct aux attributs des objets.
elle permet d ’interdire, ou de
Héritage, Spécialisation, Généralisation et polymorphisme polymorphisme
est un mécanisme de transmission des propriétés d’une classe (ses attributs et méthodes) vers une sous-classe. Une classe peut être spécialisée en d’autres classes, afin d y ajouter des caractéristiques spécifiques ou d’en adapter certaines. Plusieurs classes peuvent être généralisées en une classe qui les factorise, afin de regrouper les caractéristiques communes d’un ensemble de classes. L’héritage
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. Le polymorphisme représente la faculté dune méthode à pouvoir s ’appliquer à des objets de classes différentes. Le polymorphisme augmente la généricité, et donc la qualité, du code. L’ Agrégation 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 UM L 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. Pour programmer une application, il ne convient pas de se lancer tête baissée dans l’écriture du code : Il faut d ’abord organiser ses idées, les documenter, puis organiser la réalisation en définissant les modules et étapes de la réalisation. C’est cette démarche antérieure à l ’écriture que l’on appelle modélisation; son produit est un modèle. Les spécifications fournies par la maîtrise d ’ouvrage en programmation impérative étaient souvent floues: les articulations conceptuelles (structures de données, algorithmes de traitement) s’exprimant dans le vocabulaire de l’informatique, le modèle devait souvent être élaboré par celle-ci. L’approche objet permet en principe à la maîtrise d ’ouvrage des exprimer de façon précise selon un vocabulaire qui, tout en transcrivant les besoins du métier,
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. Il est impossible de donner une représentation graphique complète d ’un logiciel, ou de tout autre système complexe, de même qu ’il est impossible de représenter entièrement une statue (à trois dimensions) par des photographies (à deux dimensions). Mais il est possible de donner sur un tel système des vues partielles, analogues chacune à une photographie d ’une statue, et dont la juxtaposition donnera une idée utilisable en pratique sans risque d ’erreur grave. Les diagrammes d’UML
UML 2.0 comporte ainsi treize types de diagrammes représentant autant de vues distinctes pour représenter des concepts particuliers du système d’information. Ils se répartissent en deux grands groupes: Diagrammes structurels ou diagrammes statiques (UML Structure)
diagramme de classes (Class diagram) diagramme d’objets (Object diagram) diagramme de composants (Component diagram) diagramme de déploiement (Deployment diagram) diagramme de paquetages (Package diagram) diagramme de structures composites (Composite structure diagram)
Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior)
diagramme de cas d’utilisation ( Use case diagram) diagramme d’activités (Activity diagram) 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 Java est à la fois un langage de programmation et un environnement d’exécution. Le langage Java a la particularité principale d'être portable sur plusieurs systèmes d’exploitation. C'est la plateforme qui garantit la port abilité des
applications développées en Java. (Cornell) Lors de la création du langage Java, il avait été décidé que ce langage devait répondre à 5 objectifs : 1. utiliser une méthode orientée objet, 2. permettre à un même programme d'être exécuté sur plusieurs systèmes d'exploitation différents, 3. pouvoir utiliser de manière native les réseaux informatiques, 4. pouvoir exécuter du code distant de manière sûre, 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 ). ).
Page 108
DIFFERENCE ENTRE L’ARCHITECTURE L’A RCHITECTURE 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. Les trois parties du pattern MVC sont les suivantes : 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
L'architecture 3-Tiers sépare, tout comme MVC, l'application en trois parties bien distinctes : 1. User interface : La partie présentation de l'application. 2. Buisness logic : La couche métier qui s'occupe du traitement de l'information. 3. Data access : La partie accès et stockage des données
Architecture MVC ou 3-Tiers ?
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 ). ).
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. Loin d'être antagonistes, ces deux pratiques se combinent et sont la fondation de la plupart des frameworks de création d'applications Web.
Page 110
