P. 1
2TUP

2TUP

|Views: 864|Likes:
Publié parbong8

More info:

Published by: bong8 on Feb 02, 2011
Droits d'auteur :Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

04/19/2013

pdf

text

original

Sections

  • TABLE DES MATIERES
  • TABLE DES MATIERES ... 5
  • Introduction
  • 1. LE CONTEXTE DE TRAVAIL
  • 2. OBJECTIFS
  • 3. COMPARAISON ENTRES LES DIFFERENTES APPROCHES
  • 4. PRESENTATION DE L’APPLICATION A RÉALISER
  • 1. DEFINITION D’UN PROCESSUS DE DEVELOPPEMENT LOGICIEL
  • 2. LE PROCESSUS UNIFIÉ
  • 3. LE PROCESSUS 2TUP
  • 4. UN PROCESSUS DE MODELISATION AVEC UML
  • Conception du logiciel
  • 1. ETUDE PRÉLIMINAIRE
  • 1.1. Présentation du projet à réaliser
  • 1.2. Recueil des besoins fonctionnels
  • 1.3. Choix techniques
  • 1.4. Identification des acteurs
  • 1.5. Identification des messages
  • 1.6. Modélisation du contexte
  • 2. CAPTURE DES BESOINS FONCTIONNELS
  • 2.1. Déterminer les cas d’utilisations
  • 2.2. Description préliminaire des cas d’utilisations
  • 2.3. Description détaillée des cas d’utilisations
  • 2.4. Structuration des cas d’utilisations dans des packages
  • 2.5. Identification des classes candidates
  • 3. ANALYSE
  • 3.1. Découpage en catégories
  • 3.2. Dépendances entre catégories
  • 3.3. Diagramme de packages d’analyse
  • Diagramme de packages d’analyse
  • 3.4. Développement du modèle statique
  • 3.5. Développement du modèle dynamique
  • 4. CONCEPTION
  • 4.1. Architecture de l’application
  • 4.2. Les Design Patterns
  • 5. CODAGE
  • 5.1. La génération de code avec NetBeans 5.5:
  • 5.2. L’application « JStudent »
  • Bibliographie
  • Annexe :
  • L’APPROCHE ORIENTEE OBJET
  • LE LANGAGE JAVA
  • DIFFERENCE ENTRE L’ARCHITECTURE 3-TIERS ET LE MODELE MVC

Université Abou Bekr Belkaid de Tlemcen

Faculté des Sciences de l’Ingénieur Département d’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. 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 ainsi qu’à mes belles sœurs et beaux frères : amine, hicham, khalil, sihem, leïla sans oublier mes nièces et mes neveux : chahinez, wafaa, farah, walid, sarah, ryadh, marouane et mouhcine A tous mes amis et à toute mes amies et à tous ceux qui m’ont encouragé Zaki

Page 2

Remerciements

On remercie Monsieur Ziani Cherif Salim pour l’aide qu’il nous a apporté Aussi, on remercie Hakim (Kimz) pour l’aide qu’il nous a apporté afin de rendre notre rapport meilleur, et Zakia et Nadia pour le temps qu’ils ont passé à corriger le mémoire

Page 3

Résumé :
Nous proposons dans le cadre de ce projet de fin d’études, d’appliquer la méthode 2TUP au problème de la gestion des enseignements LMD à l’université de Tlemcen. La gestion d’un cycle de vie de logiciel requit un grand sens de la rigueur et de l’adaptation aux changements continuels imposés au monde de l’entreprise. C’est pour ça que nous avons choisi d’axer notre travail sur une méthode de développement qui est née de travaux poussés vers la standardisation et la flexibilité, et ce pour répondre aux contraintes actuelles de gestion des développements. Le mémoire sera découpé en 5 grands chapitres : 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. 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. Déterminer les cas d’utilisations............................................................................................................. 22 2.2. Description préliminaire des cas d’utilisations ....................................................................................... 25 2.3. Description détaillée des cas d’utilisations ............................................................................................. 26 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. Diagramme de packages d’analyse ........................................................................................................ 54 3.4. Développement du modèle statique ...................................................................................................... 55 3.5. Développement du modèle dynamique .................................................................................................. 62 CONCEPTION ................................................................................................................................................. 79 4.1. Architecture de l’application .................................................................................................................. 79 4.2. Les Design Patterns ................................................................................................................................ 80 CODAGE .......................................................................................................................................................... 89 5.1. La génération de code avec NetBeans 5.5: ............................................................................................ 89 5.2. L’application « JStudent »....................................................................................................................... 89

2.

3.

4.

5.

BILAN DE LA METHODE .......................................................................................................................................100 CONCLUSION GENERALE .....................................................................................................................................103

Page 5

BIBLIOGRAPHIE ...................................................................................................................................................104 ANNEXE : .............................................................................................................................................................105 L’APPROCHE ORIENTEE OBJET ............................................................................................................................... 105 UML ....................................................................................................................................................................... 106 LE LANGAGE JAVA .................................................................................................................................................... 108 DIFFERENCE ENTRE L’ARCHITECTURE 3-TIERS ET LE MODELE MVC ........................................................................... 109

Page 6

Bien que des méthodes de développement existent depuis 30 ans (Merise. des méthodes séquentielles comme celles se basant sur le cycle en V. impliquant une impossibilité à revenir en arrière. laissant une très petite marge à l’erreur. LE CONTEXTE DE TRAVAIL La complexité croissante des systèmes informatiques a conduit les concepteurs à s’intéresser aux méthodes de développement.Introduction 1. Sur cet élan. Page 7 . ont montré leur limite dans un environnement régi par des changements réguliers. 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. démontrer l’importance de l’application d’une méthodologie de développement. OBJECTIFS Notre but est d’appliquer une méthode rigoureuse de conduite d’un projet réel. SADT). nous ne pouvons constater aujourd’hui l’existence d’une règle qui soit à la fois formelle et commune aux différentes cultures. de nouvelles méthodes sont apparues et différentes notations ont été établies. Ces dernières ont toujours essayé d’apporter un contrôle continu sur un projet tout au long de son processus de vie. et aussi permettre par la suite que ce produit puisse être évolutif et facilement maintenable par des intervenants tiers. Avec l’avènement de la pensée objet. et ceci en partant d’une définition des besoins. Le projet en question concerne la gestion des enseignements. Par ailleurs. les spécialistes ont aussi pensé à unifier non pas les processus. mais plus exactement les meilleures pratiques de développement orienté objet. 2. et de ce fait. Nous espérons à travers celui-ci. Ce projet a pour objectif principal de proposer une solution à un problème concret.

stabilisé. 2005) Page 8 . COMPARAISON ENTRES LES DIFFERENTES APPROCHES Modélisation Par le passé.3. il s’agit de UP (Unified Process). a été le fruit de travail de plusieurs personnes voulants « unifier » les différentes méthodes objets existantes à ce moment comme Booch. L’itératif s’est ensuite imposé. Une méthode fortement axée sur l’itératif et le modèle UML est alors apparut. industriel. l’émergence d’une nouvelle approche : les méthodes agiles (Agile Modeling). Mais on a vite constaté son incapacité à s’adapter aux différents changements. parce qu’il réduit la complexité de réalisation des phases. (Chromatic. Conduite de projet Au début. 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. OMT et OOSE. En termes d’analyse et de modélisation objet. Cette méthode comme son nom l’indique. le cycle en cascade (ex : le cycle en V) était très utilisé. On constate aujourd’hui. UML est devenu un standard incontournable. Une méthode semi-itérative est apparut (RAD) pour pallier aux carences de ce dernier. le modèle Entité-Relation représentait une grande partie des approches les plus utilisées. Actuellement. en travaillant par approches successives et incrémentales. les nouvelles technologies s’appuient sur le modèle objet.

Page 9 . Avec la mise en place récente du système LMD. L’université de Tlemcen possède quelques milliers d’étudiants qu’il est difficile de gérer en continu. la situation s’est davantage compliquée et la tâche de gestion est devenue plus complexe. à travers la conception d’un logiciel avec une méthode que nous allons présenter. 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.4. Le projet que nous proposons nous permettra de faciliter la gestion des enseignements. PRESENTATION DE L’APPLICATION A RÉALISER De nos jours. les entreprises et entités publiques aspirent à optimiser et à rendre fiable la gestion de leur structure interne.

Nous allons d’abord définir les différents concepts qui vont être utilisés dans ce document. Quelles tâches attribuer à qui . XP. sur un développement itératif et incrémental. AUP et OpenUP. RUP.La méthode 2TUP Devant le nombre de méthodes disponibles. Nous pouvons citer à ce propos les méthodes de développement objet suivantes : 2TUP. Quel temps faudrait-il pour livrer le produit . Comment faire participer le client au développement afin de capter les besoins de celui-ci . le choix parmi elles devient difficile. du fait de son approche nouvelle. Comment vais-je procéder pour que le produit soit évolutif et facilement maintenable. Cette méthode ne se base aucunement sur un processus linéaire mais bien. 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. Comment éviter des dérives et de mauvaises estimations qui vont allonger les coûts et le temps de développement. 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. 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 . Page 10 . originale. Notre choix s’est porté vers la méthode 2TUP.

elle est itérative et incrémentale.  centrée sur l’architecture : les modèles définit tout au long du processus de développement vont contribuer à établir une architecture cohérente et solide.1. qui concourent à l’obtention d’un système logiciel ou à l’évolution d’un système existant. 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 . ceci garantit que le modèle construit à chaque phase ou étape soit affiné et amélioré. Page 11 .  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. Elaboration : sert à confirmer l’adéquation du système aux besoins des utilisateurs et à livrer l’architecture de base. DEFINITION D’UN PROCESSUS DE DEVELOPPEMENT LOGICIEL Un processus définit une séquence d’étapes. 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.  pilotée par les risques : en définissant des priorités pour chaque fonctionnalité.  conduite par les cas d’utilisation : elle est orientée utilisateur pour répondre aux besoins de celui-ci. on peut minimiser les risques d’échec du projet. 2004) 2. conduite par les cas d’utilisation et pilotée par les risques. Chaque itération peut servir aussi à ajouter de nouveaux incréments. La gestion d’un tel processus est organisée d’après les 4 phases suivantes : 1. (Rocques & Vallée. centrée sur l’architecture. 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é). en partie ordonnées. 2.

la modélisation métier. le test et le déploiement.3. l’implémentation. intégré et exécutable. Il s’agit des « chemins fonctionnels » et « d’architecture technique ». 4.à. 3. 2TUP signifie « 2 Track Unified Process» . qui correspondent aux deux axes de changement imposés au système d’information. Ces activités de développement sont définies par 6 disciplines fondamentales qui décrivent la capture des besoins. Il s’agit là du principe le plus important du Processus Unifié. Page 12 . itération par itération.d. qu’elle définit un certain nombre de critères de développement.C’est un processus qui répond aux caractéristiques du Processus Unifié. Construction : sert à livrer progressivement toutes les fonctions du système. Transition : déployer le système sur des sites opérationnels. que chaque société peut par la suite personnaliser afin de créer son propre processus plus adapté à ses besoins. Le résultat de chacune d’elles est un système testé. il renforce le contrôle sur les capacités d’évolution et de correction de tels systèmes. Notons que ces différentes étapes (ou disciplines) peuvent se dérouler à travers plusieurs phases. Le système croît avec le temps de façon incrémentale. « 2 Track» signifie littéralement que le processus suit deux chemins. Le processus unifié doit donc être compris comme une trame commune des meilleures pratiques de développement. Le processus 2TUP apporte une réponse aux contraintes de changement continuel imposées aux systèmes d’information de l’entreprise. 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. En ce sens. LE PROCESSUS 2TUP On dit de la méthode UP qu’elle est générique c. et c’est pourquoi cette méthode porte également le nom de développement itératif et incrémental. C’est dans ce cadre que la société Valtech a crée la méthode 2TUP. Chaque phase est elle-même décomposée séquentiellement en itérations limitées dans le temps (entre 2 et 4 semaines). l’analyse et la conception.

 L’analyse.Figure : Le système d’information soumis à deux types de contraintes La branche gauche (fonctionnelle) : capitalise la connaissance du métier de l’entreprise. Cette fusion conduit à l’obtention d’un processus en forme de Y. Les techniques développées pour le système peuvent l’être en effet indépendamment des fonctions à réaliser.  L’intégration. Elle constitue généralement un investissement pour le moyen et le long terme. Cette branche comporte les étapes suivantes :  La capture des besoins techniques.  Le codage. qui produit un modèle des besoins focalisé sur le métier des utilisateurs. Elle constitue un investissement pour le court et moyen terme. La branche droite (architecture technique) : capitalise un savoir-faire technique.  La conception détaillée. Page 13 . Cette branche comporte les étapes suivantes :  La capture des besoins fonctionnels.  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. Les fonctions du système d’information sont en effet indépendantes des technologies utilisées. Cette branche comporte les étapes suivantes :  La conception préliminaire.

(Pitman. de bien modéliser le système à chaque étape. « Unified Modeling Language » : UML se définit comme un langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins. spécifier. c’est pour ça qu’UML est présenté parfois comme une méthode alors qu’il ne l’est absolument pas. concevoir des solutions et communiquer des points de vue. 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é. 2006) UML unifie à la fois les notations et les concepts orientés objet.Figure : Le processus de développement en Y 4.il ne s’agit pas d’une simple notation. Page 14 . 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.

Le diagramme de classes : sûrement l’un des diagrammes les plus importants dans un développement orienté objet. Le diagramme de packages : présent depuis UML 2. ce diagramme modélise des catégories cohérentes entre elles. Sur la branche fonctionnelle. depuis la définition des besoins jusqu’au codage.0. Le diagramme de séquence : représente les échanges de messages entre objets. pour un souci de partage des rôles. Ce diagramme est utilisé lors des étapes d’analyse et de conception. (Roques.UML unifie également les notations nécessaires aux différentes activités d’un processus de développement et offre. Il spécifie les états possibles d’une classe et leur enchainement. 2006) Voici une présentation rapide des différents diagrammes UML qui vont être utilisés tout au long du projet : Le diagramme des cas d’utilisation : représente la structure des fonctionnalités nécessaires aux utilisateurs du système. ce diagramme est prévu pour développer la structure des entités manipulées par les utilisateurs. Page 15 . Le diagramme d’états : représente le cycle de vie d’un objet. En conception. le moyen d’établir le suivi des décisions prises. Il peut être assimilé comme un algorithme mais schématisé. le diagramme de classes représente la structure d’un code orienté objet. Il est normalement utilisé lors des étapes de capture des besoins fonctionnels et techniques. dans le cadre d’un fonctionnement particulier du système. Correspond à l’étape de modélisation des différents scénarios d’un cas d’utilisation. Le diagramme d’activités : représente les règles d’enchaînement des activités et actions dans le système. par ce biais.

Nous sommes allés chercher les informations au sein de l’administration de la Faculté. ETUDE PRÉLIMINAIRE L’étude préliminaire (ou Préetude) est la toute première étape du processus 2TUP. 1. Cette phase correspond à une recherche sur le terrain pour bien définir le cadre de notre système.Conception du logiciel 1. Recueil des besoins fonctionnels Nous avons effectué plusieurs recherches pour identifier au mieux les besoins de l’application.1. et ça nous a permis d’établir le cahier des charges préliminaire suivant : Page 16 . en utilisant principalement le texte. 1.2. Elle consiste à effectuer un premier repérage des besoins fonctionnels et opérationnels. Il doit permettre de suivre les étudiants depuis leur inscription à l’université jusqu’à l’obtention du diplôme de Licence. et ceci afin de répondre aux attentes des utilisateurs. qui expliquent le mode de fonctionnement du système LMD. Elle prépare les activités plus formelles de capture des besoins fonctionnels et de capture techniques. 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. ou diagrammes très simples. Nous nous sommes aussi procuré quelques documents.

Le semestre est alors acquis si cette moyenne est égale ou supérieure à 10. 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. dont chacun est dirigé par un chef de département. La valeur totale de ces crédits est fixée à 30 par semestre. Une UE est constituée d’une ou de plusieurs « matières » dispensés par toute forme d’enseignements (Cours. Pour chaque semestre d’enseignement. En cas d’échec à la première session. maths. Chaque département voit son parcours de formation structuré en 3 paliers : Le premier palier doit être composé au plus de 2 semestres. projets).Organisation des départements : _____________________________________________________________________ Une université se compose de plusieurs départements (informatique. Les parcours sont organisés en unités d’enseignements(UE) articulées entre elles. est égale ou supérieur à 10. chimie …). Le deuxième palier d’au moins 2 semestres. Page 17 . 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.la deuxième session est une session de rattrapage. Travaux Pratiques. 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. Le semestre est acquis pour tout étudiant ayant obtenu l’ensemble des UEs qui le composent. l’étudiant se présente aux examens de rattrapage pour les UEs non acquises. Chaque UE et chacune de ses matières constitutives sont affectées d’une valeur en crédits. Le semestre peut être également acquis par compensation entres les différentes UEs. deux sessions de contrôle sont organisées. 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. physique. Le troisième palier est une étape de spécialisation. Travaux Dirigés. à la différence d’une formation classique.

La progression de la première à la deuxième année de la Licence. Adoption d’une architecture à 3 couches. Choix techniques Voici les choix techniques qui ont été adoptés pour le projet :       La modélisation avec UML. est de droit si l’étudiant a acquis les deux premiers semestres du cursus de formation. Omission d’une base de données au profit de la sérialisation (Java). Cependant. Etat. Mais elle peut être autorisée si l’étudiant a validé 80% des crédits relatifs aux 4 premiers semestres. Utilisation des Design Patterns (MVC.3. et si l’étudiant a validé aussi les unités d’enseignements fondamentales. Utilisation de l’EDI NetBeans et de son plugin UML. peut être affecté à une promotion selon la filière qu’il a choisie. La promotion contient un certain nombre d’étudiants encadrés par des enseignants. Gestion des promotions : _____________________________________________________________________ Pour chaque département et chaque année d’études. Page 18 . elle peut être autorisée pour tout étudiant ayant acquis au moins 30 crédits. Utilisation du langage Java. Gestion des étudiants : _____________________________________________________________________ Un étudiant dés son inscription à l’université. 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. L’acquisition du diplôme de Licence est effective si l’étudiant a validé les 6 semestres du cursus de formation. Remarque : la branche droite qui désigne l’étude de l’architecture technique va être ignorée. une promotion doit être crée. Façade …). 1. du fait du manque de temps à notre disposition et de la complexité de la chose.

son emploi du temps. Définition : un acteur représente l'abstraction d'un rôle joué par des entités externes (utilisateur.  Administrateur : crée les profils utilisateurs et attribue les droits d’accès.1. 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 : Un étudiant peut consulter ses relevés de notes. Page 19 .  Enseignant : l’enseignant affecte les notes des étudiants de son module. Il choisit les enseignants responsables des cours. mais d’abord nous donnons une définition de ce que c’est un acteur. Identification des acteurs Nous allons maintenant énumérer les acteurs susceptibles d’interagir avec le système.  Chef de département : le chef de département établit le cursus de son département.4.  Scolarité : la scolarité introduit les notes des étudiants. il crée les promotions et suit leur évolution.

Les fiches des étudiants. Identification des messages On va détailler les différents messages échangés entre le système et l’extérieur. La liste des étudiants passés et recalés à la fin d’un semestre. Le système émet les messages suivants :           Les relevés de notes des étudiants. Les fiches des enseignants. suppressions des emplois du temps d’une promotion. Le système reçoit les messages suivants :  Les créations. modifications des filières pour un département. La liste des étudiants ayant acquis leur diplôme. modifications.1. L’organisation d’un département.  Le lancement/bouclage d’une promotion. modifications de spécialités pour un département. suppressions de profils utilisateurs. suppressions de fiches des étudiants/enseignants.  Les ajouts.  Les créations.  Les créations. 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. Page 20 .  L’affectation des étudiants/enseignants à une promotion.  Les créations.5. de promotions. Les emplois du temps d’une promotion. modifications.  Les créations. suppressions. Le cursus d’un étudiant. modifications. L’état d’avancement d’une promotion. Les modules d’un département. modifications.

de définir le rôle de chaque acteur dans le système : Utilisateurs finaux Description des besoins fonctionnels L’application doit permettre au chef de département de :  S’authentifier  Créer son département  Créer une promotion  Créer les 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  Créer/modifier les fiches des étudiants  Affecter les notes des étudiants L’application doit permettre à l’enseignant de :  S’authentifier  Affecter les notes des étudiants pour son module L’application doit permettre à l’étudiant de :  S’authentifier  Consulter son relevé de notes  Consulter son emploi du temps  Consulter ses modules en dettes L’application doit permettre à l’administrateur de :  S’authentifier  Créer les profils utilisateurs  Donner des droits d’accès Chef de département Scolarité Enseignant Etudiant Administrateur Page 21 .6. nous allons modéliser le contexte de notre application. Ceci va nous permettre dans un premier temps.1. Modélisation du contexte A partir des informations obtenues lors des deux précédentes étapes.

org/ Peut être téléchargé à l’adresse suivante : http://bouml. 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.fr/ 3 Le site de NetBeans : http://www.2.netbeans. Un cas d’utilisation modélise un service rendu par le système. 1 2 Peut être téléchargé à l’adresse suivante : http://argouml. Utilisation d’outils de génération de diagrammes UML : Tout au long du projet. Nous allons faire une présentation rapide de ceux là. Bouml 2: sûrement l’outil le plus léger sur le marché. 2. Par le biais des cas d’utilisation. il est très puissant et agréable à utiliser. et ainsi éviter de trop s’éloigner des besoins réels de l’utilisateur final. Il exprime les interactions acteurs/système et apporte une valeur ajoutée « notable » à l’acteur concerné. CAPTURE DES BESOINS FONCTIONNELS Cette phase représente un point de vue « fonctionnel » de l’architecture système.free. NetBeansUML 3: c’est un plugin intégré à l’EDI NetBeans.1. cependant il souffre d’une lourdeur assez gênante si on n’a pas une machine puissante. Nous l’avons utilisé pour quelques Design Pattern et pour la génération de code. il est très puissant avec de grandes possibilités de personnalisation.org/ Page 22 . ArgoUML 1: c’est un outil gratuit écrit avec Java. nous serons en contact permanent avec les acteurs du système en vue de définir les limites de celui-ci. nous sommes passés par plusieurs outils qui génèrent les diagrammes UML. nous l’avons utilisé au début puis nous l’avons délaissé pour sa lourdeur et son interface peu intuitive. et en plus il est gratuit.tigris.

Cependant. gérer les rattrapages. Messages émis/reçus par les acteurs Cas d’utilisation Acteur principal. Emet : Créer/modifier les fiches des étudiants. on obtient les cas d'utilisations. Reçoit : relevé de notes Suivre les promotions Chef de département Gérer les étudiants Scolarité Maintenir les notes Scolarité. Enseignant Consulter les notes Etudiant Reçoit : consulter son relevé de notes. Pour constituer les cas d’utilisation. passer au prochain semestre. sélectionner les enseignants/semestre. acteurs secondaires Emet : Créer son département. Organiser un département Chef de département Gérer les promotions Chef de département Emet : Créer une promotion. gérer les modules en dettes. orienter les étudiants vers les spécialités. Reçoit : liste des étudiants endettés. Affecter les étudiants à une promotion Emet : Commencer la promotion. En regroupant les intentions fonctionnelles en unités cohérentes.Identification des cas d’utilisation : L’identification des cas d’utilisation une première fois. D’autres cas d’utilisation vont apparaître au fur à mesure de la description de ceux là. Page 23 . il nous faut plusieurs itérations pour ainsi arriver à constituer des cas d’utilisation complets. nous donne un aperçu des fonctionnalités futures que doit implémenter le système. et l’avancement dans le « recueil des besoins fonctionnels ». Créer/modifier les spécialités/options. commencer/terminer un semestre. Créer les UE et les Modules. Liste des étudiants non endettés. 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. Emet : Affecter les notes aux étudiants.

Diagramme des cas d’utilisation Page 24 . Emet : Création. Administrateur Remarque : Du fait qu’elle ne rentre pas dans le cadre de notre projet. il se peut qu'il change au fur et à mesure de l'avancement du projet. la gestion des salles a été délibérément omise. suppression de profils. Enseignant Emet : Créer/modifier les emplois du temps Reçoit : consulter les emplois du temps. Remarque 2: Ce premier tableau n'est pas définitif.Gérer les emplois du temps Consulter les emplois du temps Gérer les profils Scolarité Etudiant. modification. un processus de développement avec UML est itératif.

rattacher l’étudiant à une année universitaire.  Actions : consulter l’emploi du temps.2.  Actions : créer un nouveau profil.  Actions : affecter les notes aux étudiants pour chaque module. modifier le profil. attribuer une fonction. Etablir les emplois du temps :  Intention : créer l’emploi du temps pour une promotion.2. attribuer des droits d’accès.  Actions : créer un nouvel emploi du temps. mettre à jour le dossier. une nouvelle option.  Actions : créer une nouvelle promotion. Consulter les notes :  Intention : consulter les notes d’un étudiant. Gérer les profils :  Intention : créer les différents profils des utilisateurs du système. affecter des étudiants.  Actions : choisir un étudiant et consulter la liste de ses notes. 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.  Actions : créer le dossier étudiant. affecter à une unité d’heure un module et un enseignant. Maintenir les notes des étudiants :  Intention : affecter les notes aux étudiants. créer les UE.  Actions : créer un nouveau domaine. Consulter l’emploi du temps :  Intention : consulter l’emploi du temps d’une promotion. une nouvelle spécialité. modifier ou annuler l’emploi du temps. Page 25 . modifier les UE … Gérer les promotions :  Intention : gérer les promotions. Gérer les étudiants :  Intention : suivi des dossiers des étudiants après inscription de ces derniers. modifier ou annuler la promotion. créer un mot de passe.

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.  Une description détaillée : des Préconditions au déclenchement du cas d’utilisation doivent être spécifiées. un scénario nominal décrivant celui-ci additionné à des scénarios alternatifs et d’exceptions.3. Ces définitions servent à fixer les idées et n’ont pas pour but de spécifier un fonctionnement complet et irréversible. Page 26 . Remarque : les descriptions vont être organisées de la façon suivante :  Un sommaire d’identification : va résumer les propriétés du cas d’utilisation.  Les diagrammes (optionnelle): plusieurs diagrammes vont apparaitre (mais pas nécessairement) pour apporter une compréhension additive au cas d’utilisation.2.

Scénario nominal : Ce cas d’utilisation commence lorsque le chef de département demande au système de créer un nouveau domaine. une nouvelle spécialité. Enchaînement (b) : Créer un tronc commun Pour la première année un tronc commun va être constitué.Organiser les DÉPARTEMENTS: Sommaire D’IDENTIFICATION: ______________________________________________________________ Titre : Organiser les licences But : créer des domaines. Enchaînement (d) : valider un domaine en construction Le chef de département valide la création. des options. Enchaînement (a) : Créer un domaine en construction Le chef de département choisit un nom pour le département. Enchaînement (c) : Créer les spécialités/options Il peut spécifier les spécialités/options que le domaine va contenir. La durée de ce tronc commun est variable selon le domaine. Résumé : créer un nouveau domaine. Une durée en semestres doit être renseignée. des spécialités. Page 27 . une nouvelle option Acteur : Chef de département Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions : Le chef de département est authentifié.

optionnelle. le nombre d’heures à enseigner. et choisit le type de cette UE (fondamentale. Il crée les modules pour cette UE. si Code existe déjà déclencher : [Exception2 : ModuleExistant] Il valide l’UE. Ce cas d’utilisation se termine lorsque le chef de département a validé un domaine. [Exception3 : ModuleExistant] : le module est marqué en anomalie tant que le code n’a pas été changé. Si l’UE est utilisée dans une promotion déclencher :[Exception5 : UEUtilisee] Exceptions : [Exception1 : DomaineExistant] : le domaine est marqué en anomalie tant que le code n’a pas été changé. Le module ne peut plus être validé. et un crédit pour chaque module. spécifie un nom. [Exception5 : UEUtilisee] : un message est affiché à l’écran avisant l’utilisateur que l’UE ne pas être supprimée. [Exception4 : DomaineUtilise] : un message est affiché à l’écran avisant l’utilisateur que le domaine ne peut pas être supprimé. complémentaire. L’UE ne peut plus être validée. [Exception2 : UEExistante] : l’UE est marqué en anomalie tant que le code n’a pas été changé. transversale. si Code existe déjà déclencher : [Exception3 : UEExistante] Enchaînement (f) : Modifier un domaine en construction ou validé Pour un domaine. Page 28 . méthodologique. Enchaînement (g) : Supprimer un domaine Le chef de département peut supprimer un domaine. découverte). le chef de département peut ajouter/supprimer une spécialité/option ou modifier un tronc commun.Si le domaine existe déjà déclencher : [Exception1 : DomaineExistant] Enchaînements alternatifs : Enchaînement (e) : créer les UE Le chef de département crée une UE. 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. un coefficient. Il valide le module.

Scénario nominal : Ce cas d’utilisation commence lorsque le chef de département demande au système de créer une nouvelle promotion. 3.Au moins un domaine existe. Enchaînement (b) : Rattacher à un domaine Il rattache la promotion à un domaine. lui rattacher des étudiants … Acteurs : Chef de département Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions : 1.Etablir les PROMOTIONS: Sommaire D’IDENTIFICATION: ______________________________________________________________ Titre : Etablir les promotions But : gérer des promotions.Le chef de département est authentifié. 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.Au moins un enseignant existe dans la base. Résumé : créer une nouvelle promotion. Si l’étudiant EtudiantDejaAffecte] appartient déjà à une promotion déclencher : [Exception2 : Enchaînement (f) : fixer les dates d’examens Page 29 . 2. Enchaînement (a) : Créer une promotion en construction Le chef de département choisit un code/nom et l’année de création pour la promotion.

Ce cas d’utilisation se termine lorsque le chef de département a validé une promotion. 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. 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. [Exception2 : EtudiantDejaAffecte] : un message d’erreur est affiché sur l’écran avisant l’utilisateur que l’étudiant appartient déjà à la promotion.Le chef de département fixe les dates des examens. l’enseignant en charge d’un module. Page 30 . 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. Il fixe les dates de début/fin.

Résumé : commencer les études. Enchaînement (b) : remplir les relevés de notes Cas d’utilisation  Maintenir les notes Enchaînement (c) : terminer le semestre Page 31 . Au moins une promotion existe. affecter des enseignants à chaque semestre … Acteurs : Chef de département Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions : 1234Le 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 commencer les études dans une promotion.Suivre une PROMOTION: Sommaire D’IDENTIFICATION: ______________________________________________________________ Titre : Suivre une promotion But : permettre le suivi du cursus des étudiants. Au moins un enseignant existe dans la base. Si le module est déjà attribué déclencher : [Exception1 : ModuleDejaAttribue ] Il spécifie les caractéristiques du module TD/TP/Projet/Séminaire/conférence. Commencer le 1er semestre et la promotion. Au moins un domaine existe. et attribue pour chacun d’eux un ou plusieurs modules à enseigner. Enchaînement (a) : commencer les études Il sélectionne les enseignants chargés de donner des cours.

sinon déclencher : [Exception2 : SemestreIncomplet ] Enchaînement (d) : passer au prochain semestre Si c’est le premier semestre de l’année. remise des diplômes aux étudiants ayants réussis. alors une session de rattrapage est prévu pour les étudiants qui n’ont pas tous les crédits requis. orienter les étudiants vers les spécialités choisies. le passage est automatique pour tous les étudiants. 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é. 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.  Si le dernier semestre est terminé.Si tous les relevés de notes sont remplis terminer le semestre. Ce cas d’utilisation se termine lorsque le chef de département a terminé une promotion. Les résultats à la suite des rattrapages vont déterminer :  Les étudiants aptes à passer au palier supérieur.  Les étudiants recalés. Si une spécialisation se présente. Page 32 . sinon si c’est le deuxième. [Exception2 : SemestreIncomplet]: un message d’erreur est affiché sur l’écran avisant l’utilisateur que des relevés de notes ne sont pas complets.

Diagramme d’activités représentant l’enchainement des étapes d’une promotion Page 33 .

2. Résumé : créer un nouvel emploi du temps. Si le module à enseigner est déjà attribué alors déclencher : moduleErreur] Il affecte un enseignant à cette plage horaire. Si l’enseignant est déjà pris pour cette plage alors déclencher : [Exception2 : enseignantErreur] [Exception1 : Enchaînement (c) : Valider un emploi du temps en construction Page 34 .Au moins une promotion a été crée. 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.Etablir les emplois du TEMPS: Sommaire D’IDENTIFICATION: ______________________________ ________________________________ Titre : Etablir les emploies du temps But : créer des emplois du temps. en modifier un. 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 (b) : Affecter les charges Il sélectionne un module parmi les modules de la promo. Il sélectionne une plage horaire. Il affecte le module à enseigner à cette plage horaire. Acteurs : Chef de département Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions : 1.Le chef de département est authentifié. Il sélectionne un semestre pour l’année en cours.

Enchaînement (e) : Supprimer un emploi du temps Le chef de département supprime un emploi du temps. 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. Diagramme D’ACTIVITÉS: _____________________________________________________________ Diagramme d’activités Page 35 . 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 temps.Le chef de département valide l’emploi du temps.

Ce cas d’utilisation se termine lorsque l’utilisateur se déconnecte. Il affiche ensuite l’emploi du temps correspondant.Consulter les emplois du TEMPS: Sommaire D’IDENTIFICATION: ______________________________________________________________ Titre : Consulter les emploies du temps But : consulter un emploi du temps. Page 36 . Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions : L’utilisateur est authentifié. Enchaînement (a) : Consulter un emploi du temps L’utilisateur sélectionne une promotion. L’utilisateur sélectionne ensuite un semestre pour l’année en cours. Scénario nominal : Ce cas d’utilisation commence lorsque l’utilisateur demande à consulter l’emploi du temps. étudiant. Acteurs : enseignant. Résumé : s’authentifier et afficher l’emploi du temps pour une promotion.

Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions : La Scolarité est authentifiée. Résumé : créer un nouveau dossier. Enchaînement (b) : Valider dossier étudiant en construction Le chef de département doit avoir rempli toutes les informations obligatoires. Il remplit le numéro d’inscription. Acteurs : Scolarité. Page 37 . 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. Il peut choisir éventuellement l’année d’inscription. modifier un dossier existant. spécifier la nouvelle année d’inscription. 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. Enchaînement (a) : Créer un dossier étudiant en construction Le chef de département choisit un nom/prénom/date et lieu de naissance.Gérer les fiches des étudiants : Sommaire D’IDENTIFICATION: ______________________________________________________________ Titre : Gérer les fiches des étudiants But : créer des dossiers étudiants. Si l’étudiant est déjà inscrit. Remplir les informations sur l’état civil.

Diagrammes d’activités: ______________________________________________________________ Diagramme d’activités Page 38 . Ce cas d’utilisation se termine lorsque le chef de département a validé un dossier étudiant.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.

Enchaînements alternatifs : Enchaînement (c) : modifier une fiche notes en construction/validée La scolarité peut modifier une note d’un module. Scénario nominal : Ce cas d’utilisation commence lorsque le responsable de la scolarité affiche le relevé de notes. un module. 2.Maintenir les notes des ÉTUDIANTS: Sommaire D’IDENTIFICATION: ______________________________________________________________ Titre : Maintenir les notes But : affecter les notes aux étudiants. 3. Choisir un module et affecter une note à celui-ci. affecter la note. Enchaînement (a) : remplir le relevé de notes Le responsable de la scolarité ou l’enseignant choisit une promotion. Au moins une promotion existe. Enchaînement (b) : Valider une fiche notes Valider les données. Scolarité. Le responsable de la scolarité ou l’enseignant est authentifié. Au moins un dossier étudiant est crée. Exceptions : Page 39 . Acteurs : Enseignant. Résumé : choisir un étudiant. Descriptions des ENCHAÎNEMENTS: _______________________________________________________ Préconditions : 1. Il choisit un étudiant et affiche son relevé de notes.

[Exception2 : ModuleDejaNoté] : Si l’acteur est l’enseignant alors il ne peut plus modifier la note. Diagrammes d’activités: ______________________________________________________________ Diagramme d’activités Remarque : cet algorithme.[Exception1 : FicheNotesDejaExistante] : un message d’erreur s’affiche à l’écran avisant l’utilisateur que la fiche existe déjà pour ce semestre. Page 40 . va être sensiblement changé. Ce cas d’utilisation se termine lorsque le chef de département a validé la fiche de notes de l’étudiant. ne correspondant pas assez aux besoins du langage choisi et à l’IHM. sinon un message d’information reste affiché sur l’écran demandant la confirmation du changement de la note et de la raison.

Consulter les NOTES: Sommaire D’IDENTIFICATION: ______________________________________________________________ Titre : Consulter les notes But : consulter une fiche de notes. Enchaînement (b) : Afficher les notes Il sélectionne un semestre à afficher et affiche ses notes. Il choisit un étudiant. Scénario nominal : Ce cas d’utilisation commence lorsque l’étudiant se connecte à son compte. Au moins un dossier étudiant est crée. Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions : 1. Ce cas d’utilisation se termine lorsque l’étudiant s’est déconnecté. Acteurs : étudiant. Enchaînement (a) : Sélectionner un étudiant Le responsable choisit une promotion. L’utilisateur est authentifié. Résumé : s’authentifier et afficher la fiche de notes pour un étudiant. 2. Page 41 .

Il choisit le type de ce compte.Gérer les PROFILS: Sommaire D’IDENTIFICATION: ______________________________________________________________ Titre : Gérer les profils But : créer les profils utilisateurs. Enchaînement (a) : Créer un profil en construction L’administrateur choisit un nom / mot de passe pour le compte. Ce cas d’utilisation se termine lorsque le chef de département a validé un profil en construction. Scénario nominal : Ce cas d’utilisation commence lorsque l’administrateur lance le logiciel. Acteurs : Administrateur. Page 42 . Descriptions des ENCHAÎNEMENTS: ______________________________________________________________ Préconditions : Aucunes. Résumé : créer un nouveau profil et lui affecter des droits d’accès.

Des diagrammes qui représentent les éléments du modèle. Cas d’utilisation Acteurs Package Organiser un département Chef de département Gestion des départements Gérer les promotions Suivre les promotions Maintenir les notes Chef de département Gestion des promotions Chef de département Scolarité.d. Structuration des cas d’utilisations dans des packages Cette phase va permettre de structurer les cas d’utilisations en groupes fortement cohérents. Des éléments d’un modèle. 2. Enseignant Gestion des notes Consulter les notes Gérer les emplois du temps Etudiant Scolarité Gestion des emplois du temps Etudiant. D’autres packages.à. La structuration des cas d’utilisations se fait par domaine d’expertise métier c. Enseignant Consulter les emplois du temps Page 43 .4. Définition : un package représente un espace de nommage qui peut contenir : 1. 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. 3. ceci afin de préparer le terrain pour la prochaine phase qui est le « découpage en catégories ».2.

Gérer les profils Administrateur Gestion des profils 2. 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. Exemple : Resp onsabilités de la classe « Domaine » Page 44 . propriétés. pour une classe. Ces diagrammes préliminaires sont appelés « diagramme des classes participantes ». comportement). Vérifier les propriétés « objet » de chaque concept (identité. Définition : une responsabilité est une sorte de contrat. 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. n’ont pas pour objectif d’être complet. Elle se place à un niveau d’abstraction plus élevé que les attributs ou les opérations. Ils servent uniquement à démarrer la découverte des classes du modèle d’analyse. puis définir ses responsabilités. ou d’obligation. 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.5.

Module. Discipline. Diagramme des classes participantes du cas d’utilisation « Organiser les départements » : Les classes candidates sont tirées de la description textuelle du cas d’utilisation et des diagrammes dynamiques représentant celui-ci : Domaine. UE. Diagramme des classes participantes « Organiser les départements » Page 45 .

Enseignant. 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. Specialite. Diagramme des classes participantes « Etablir les promotions » Page 46 . Etudiant. Domaine. Tronc_Commun.

Domaine. Semestre. Enseignant. Etudiant. Diagramme des classes participantes « Suivre les promotions » Page 47 . 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.

Enseignant. Module. UE. Plage horaire. Diagramme des classes participantes « Etablir les emplois du temps » Page 48 . 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.

Module. Note. Diagramme des classes participantes « Maintenir les notes » Page 49 . Etudiant. Diagramme des classes participantes du cas d’utilisation « Maintenir les notes étudiants » : Les classes candidates sont tirées de la description textuelle du cas d’utilisation et des diagrammes dynamiques représentant celui-ci : Fiche notes.

à une structuration objet via les classes et les catégories. il faut se baser sur les principes de l’Approche Orientée Objet. ANALYSE 3. 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.3. Définition : une catégorie consiste en un regroupement logique de classes à forte cohérence interne et faible couplage externe. À cet effet. Pour passer à l’analyse. Le découpage en catégories de notre projet a donné le résultat suivant : Page 50 . 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 plus indépendants possibles. Elle se situe sur la branche gauche du cycle en Y et succède à la capture des besoins fonctionnels. il faut passer d’une structuration fonctionnelle via les cas d’utilisations. notamment celle de l’encapsulation.1.

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 Page 53 .

Chaque équipe pourra se concentrer sur le développement d’une seule catégorie/package. 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.3. Page 54 . Remarque 2: cette phase peut être utilisée par un chef de projet pour constituer les équipes.3.

3. Il s’agit d’une activité itérative. Développement du modèle statique Le développement du modèle statique constitue la deuxième étape d’analyse.  Catégorie « Etudes » : Voici le diagramme de classe de la catégorie Etudes. Diagramme de classe Page 55 .4. vont être. et optimisés. fortement couplée avec la modélisation dynamique. complétés. Les diagrammes de classes établis sommairement dans les diagrammes de classes participantes. puis réorganisés lors du découpage en catégories.

 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) Page 57 .

Classe Semestre (attributs/opérations) Page 58 .Et voici les opérations/attributs de la classe Semestre.

 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 .

Classe Enseignant (attributs/opérations) Page 60 . Diagramme de classe Et voici les opérations/attributs de la classe Enseignant. Catégorie « Enseignants » : Voici le diagramme de classe de la catégorie Enseignants.

 Catégorie « Etudiant » : Classe Etudiant (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 .

Un scénario décrit une exécution particulière d’un cas d’utilisation du début à la fin.3. d’une façon naturelle et fréquente .5. On peut distinguer plusieurs types de scénarios :  Nominaux : 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 . mais en empruntant des voies détournées ou rares . Il s’agit d’une activité itérative.il correspond à une sélection d’enchainements 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. fortement couplée avec la modélisation statique. C’est pour cette raison que nous allons faire une description des scénarios les plus pertinents. Page 62 . Développement du modèle dynamique Le développement du modèle dynamique constitue la troisième activité de l’étape d’analyse. D’erreur : ne réalisent pas les post conditions du cas d’utilisation. Identification des scénarios : Un cas d’utilisation décrit un ensemble de scénarios. Alternatifs : ils remplissent les post conditions du cas d’utilisation. Aux limites : ils réalisent les post conditions du cas d’utilisation.

 Scénarios d’exception :  OL_E1 : non validation de la création de domaine pour cause de nom existant déjà. en choisissant pour chacune d’elle la durée. Le chef de département donne un nom/mot de passe d’identification.  OL_A2 : modifier un domaine par ajout d’une option. Un tronc commun est créé.  Scénarios nominaux :  OL_N1 : créer un nouveau domaine. 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.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 :  OL_N1 : créer un nouveau domaine. Pour décrire ce scénario.  OL_A3 : modifier un domaine par création d’UE et modules.  OL_E2 : non validation de la modification du domaine par suppression d’une UE pour cause d’existence d’une promotion utilisant l’UE. Il choisit un code/nom pour le domaine. du fait de l’existence de nombreux scénarios. Il crée les spécialités du domaine. Le chef de département fixe la durée en semestres de celui-ci.  OL_A4 : modifier un domaine par suppression d’une UE. Cependant.  OL_N2 : créer des UE pour un Tronc_Commun ou Specialite. Page 63 . nous allons faire intervenir les instances suivantes : o Un acteur Chef de département.  Scénarios alternatifs :  OL_A1 : modifier un domaine par ajout d’une spécialité. nous allons détailler seulement quelques uns d’entre eux.

o Un objet Tronc_Commun crée au cours du scénario. il crée plusieurs modules en spécifiant un code/intitulé/crédit. Pour décrire ce 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.o Un objet Domaine crée au cours du scénario. o Un objet Tronc_Commun/ Specialite crée au cours du scénario. Page 64 . nous allons faire intervenir les instances suivantes : o Un acteur Chef de département. Il sélectionne un Domaine existant. o Un objet Specialite crée au cours du scénario. Le chef de département donne un nom/mot de passe d’identification. 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. o Un objet Domaine crée au cours du scénario. Pour chaque UE crée.

Diagramme de séquences du scénario « non validation de la création d’un domaine » Page 65 . o Un objet Module crée au cours 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à.o Un objet UE crée au cours du scénario.

nous allons faire intervenir les instances suivantes : o Un acteur Chef de département. Le chef de département sélectionne les étudiants faisant partie de la promotion.  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. Pour décrire ce scénario. il choisit à quel domaine elle appartient.  EP _A5 : modifier une promotion par enlèvement d’un étudiant.  Scénarios alternatifs :  EP _A1 : modifier une promotion par ajout d’un enseignant. o Une Promotion crée au cours du scénario.  EP _A4 : modifier une promotion par ajout d’un étudiant. Page 66 .  EP _A2 : modifier une promotion par attribution d’un module à un enseignant non encore attribué. si c’est un tronc commun ou une spécialité le cas échéant il spécifie l’année du LMD.  EP _A3 : modifier une promotion par libération d’un enseignant chargé d’un module. Il choisit un nom pour la promotion et la durée en semestres.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 :  EP _N1 : créer une nouvelle promotion. Le chef de département valide la promotion. o Un multi-objet représentant les Modules de la spécialité ou du tronc_commun crée cours du scénario. Le chef de département sélectionne les enseignants et leur attribue un module à enseigner. Le chef de département donne un nom/mot de passe d’identification.

Diagramme de séquences du scénario « créer une nouvelle promotion » Page 67 .o Un multi-objet représentant l’ensemble des instances de Enseignant qui vont être affectés à la nouvelle promotion. o Un multi-objet représentant l’ensemble des instances de Etudiant qui vont être rattachés à la nouvelle promotion.

Le chef de département valide la promotion. Le chef de département ajoute un enseignant à la promotion. nous allons faire intervenir les instances suivantes : o Un acteur Chef de département. Il sélectionne une 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. Pour décrire ce scénario. Il sélectionne une promotion. o Un objet Enseignant qui va être affecté à la promotion. Le chef de département donne un nom/mot de passe d’identification. Page 68 . EP _A1 : modifier une promotion par ajout d’un enseignant. o Une Promotion crée au cours du scénario.

Un objet Enseignant qui va est affecté à la promotion. nous allons faire intervenir les instances suivantes : o o o o Un acteur Chef de département.Il sélectionne un module. Page 69 . Une Promotion crée au cours du scénario. Il attribue le module à un enseignant. Pour décrire ce scénario. Le chef de département donne un nom/mot de passe d’identification. Le chef de département valide 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.

EP_A5: modifier une promotion par ajout/enlèvement d’un étudiant. Page 70 . 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. Le chef de département valide la promotion.Il sélectionne une promotion. nous allons faire intervenir les instances suivantes : o o o o Un acteur Chef de département. Il sélectionne un enseignant faisant parti de la promotion. Un objet Enseignant qui va être affecté à la promotion. Il désaffecte l’enseignant de son module. Pour décrire ce scénario. Une Promotion crée au cours du scénario. Le chef de département donne un nom/mot de passe d’identification.

Diagramme de séquence du scénario « modifier une promotion ajout/enlèvement d’un étudiant » Page 71 . nous allons faire intervenir les instances suivantes : o Un acteur Chef de département.Il sélectionne une promotion. Il sélectionne un étudiant. Il désaffecte l’étudiant de la promotion. Pour décrire ce scénario. o Une Promotion crée au cours du scénario. Le chef de département valide la promotion. o Un objet Etudiant qui va être affecté à la promotion.

Il choisit la promotion. Une Promotion. Une plage horaire crée au cours du scénario. Un Module. il affecte un module.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. Pour décrire ce scénario. nous allons faire intervenir les instances suivantes : o o o o o Un acteur Chef de département. Il choisit le semestre. Page 72 . Le chef de département donne un nom/mot de passe d’identification. Pour chaque plage horaire sélectionnée. Un emploi du temps crée au cours du scénario.

 MN _A2 : modifier une promotion par attribution d’un module à un enseignant non encore attribué. 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 :  MN _N1 : créer une fiche de notes.  Scénarios d’exception :  MN _E1 :  MN _E2 : Page 73 .  MN _A3 : modifier une promotion par libération d’un enseignant chargé d’un module. prénom). Il saisit les informations obligatoires (n° inscription. nom. Il saisit les informations facultatives. o Un étudiant crée au cours du scénario. Il saisit les informations sur l’état civil. Pour décrire ce scénario. La scolarité donne un nom/mot de passe d’identification. nous allons faire intervenir les instances suivantes : o Un acteur Scolarité.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.  Scénarios alternatifs :  MN _A1 : modifier une note pour un étudiant.  MN _N2 : affecter les notes pour un étudiant.

nous allons faire intervenir les instances suivantes : o o o o Un acteur Scolarité. Diagramme de séquence du scénario « créer une fiche de notes »  MN _N2 : affecter les notes pour un étudiant. Une Promotion crée au cours du scénario. Pour décrire ce scénario. Elle choisit une promotion.Description détaillée des scénarios :  Scénarios nominaux :  MN _N1 : créer une fiche de notes. Une Fiche notes. La scolarité donne un nom/mot de passe d’identification. Elle sélectionne un étudiant. La scolarité donne un nom/mot de passe d’identification. Page 74 . Elle crée la fiche de notes. Elle sélectionne un étudiant. Elle choisit une promotion. Un étudiant crée au cours du scénario.

Page 75 . Pour décrire ce scénario. Le calcul de la moyenne se fait automatiquement. nous allons faire intervenir les instances suivantes : o o o o Un acteur Scolarité. Un objet Promotion crée au cours du scénario.Pour chaque module. TP. ces diagrammes sont difficilement implémentables en l’état. ils servent à faire surgir les interactions possibles entres les différents objets. Cependant. Un objet Note. Devoir). elle affecte une note (examen. TD. Diagramme de séquence du scénario « affecter les notes pour un étudiant » Remarque : Du fait des contraintes du langage. Un étudiant crée au cours du scénario.

Définition : un état représente une situation durant la vie d’un objet pendant laquelle :    Il satisfait une certaine condition . de rattachements d’étudiants. Cette vue locale d’un objet. de rattachements d’enseignants. Cependant. cet état inclut toutes les opérations de rattachement à un domaine. Il exécute une certaine activité . Ou bien il attend un certain évènement. Terminée : cet état survient après la fin des délibérations de la dernière session d’examen. est représentée graphiquement sous forme d’un diagramme d’états. 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. variable selon la vie de l’objet.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. décrivant comment il réagit à des événements en fonction de son état courant et passe dans un nouvel état. Un état a une durée finie. dans tous les cas possibles. Aucun étudiant ne peut être ajouté à ce moment et aucun changement de Module ou d’UE ne peut être autorisé. un enseignant peut être remplacé.    Page 76 . Un objet passe par une succession d’états durant son existence. 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.

Diagramme d’états de la classe Promotion Diagramme d’états de la classe Etudiant :  Nouvellement inscrit : cet état représente un étudiant qui vient d’être inscrit à l’université. Rattaché : cet état représente un étudiant qui est attaché à une promotion. Au cours de cet état. En cours d’études : cet état représente un étudiant qui est entrain d’étudier. l’étudiant fait le choix de la prochaine branche. Recalé : cet état survient après qu’un étudiant ait échoué le passage au niveau supérieur.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é.      Page 77 . Etudes terminées : cet état survient après qu’un étudiant ait terminé ses études supérieures. En cours de passage : cet état survient après qu’un étudiant ait réussi le passage au niveau supérieur.

Diagramme d’états de la classe Etudiant Page 78 .

La conception détaillée qui vient juste après est une activité qui s’inscrit dans l’organisation définie par la conception préliminaire. Architecture de l’application La technologie Objet requiert une architecture.1. Les équipes de réalisation s'attribuent alors des responsabilités sur le développement de chaque couche. Métier.4. Ceci correspond à une architecture 3-Tiers : Page 79 . les interfaces. qui pourront travailler indépendamment les unes des autres. les tables et les méthodes qui vont donner une image « prête à coder » de la solution. les vue d’IHM. C'est cette architecture qui organise les interactions entre objets. et ces domaines en couches. si modéliser est indispensable. construire une architecture à couche est un critère de qualité dans le cadre d'un développement Objet. Les couches permettent de présenter l'architecture de l'application. On a l'habitude de regrouper ces objets en classes. Nous allons donc séparer au maximum les différents types de traitement de l’application (Dao. CONCEPTION La conception préliminaire est l’étape où s’effectue la fusion des études fonctionnelles et techniques. Il est ainsi possible de confier les catégories à des personnes différentes. 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. Présentation). Les concepteurs dans cette phase construisent les classes. il nous faut utiliser le principe de « couche ». 4. ces classes en domaines. Reste à choisir le nombre de couches et à définir leur contenu. Aussi. Architecture 3-Tiers : Pour avoir une architecture robuste. modulable et évolutive.

(Guy) Page 80 . le problème à résoudre est classique et bien connu. considérons Merise et UML. (Eric Freeman. la solution que propose ce motif correspond à la résolution la plus optimale du problème. La définition d'un motif de conception repose donc sur trois critères. 2005) Un Design Pattern constitue un petit ensemble de classes apte à offrir la solution la plus efficace à un problème.Architecture 3-Tiers 4. Les Design Patterns De nombreuses méthodes existent pour simplifier la phase de conception des logiciels. Enfin. Ensuite. Lors de la conception d'une application de nombreux problèmes peuvent survenir. Premièrement. plus proche de l'implémentation. l'ensemble des classes employées porte un nom unique (on parle par exemple du motif "Decorator"). Le système des Design Patterns. représente un système objet destiné à la résolution de problèmes techniques. ou motifs de conception.2. Parmi les plus connues. Mais une autre méthode existe.

Les Designs Patterns proviennent du travail de nombreux développeurs qui se sont tour à tour penchés sur les mêmes problèmes. Pour nous. 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. Une classe gère ainsi les activités et les transitions attachées à l’état qu’elle représente. En mettant en corrélation ces travaux on a pu désigner les meilleures solutions découvertes sous le terme de motifs de conception.5 Voici les différents diagrammes Etats que nous avons conçus : Page 81 . La gestion des états est déléguée de sorte qu’à chaque état corresponde une classe du patron. La principale difficulté réside dans l'identification du problème et dans sa mise en relation avec des motifs connus. ils vont nous aider à coder les différents concepts qui se dégagent dans la phase de conception. les Design Pattern nous ont aidé à trouver une solution élégante à un problème conceptuel. Le Design Pattern « Etat » Remarque : les diagrammes qui vont suivre ont été crée avec l’outil UML de NetBeans 5. En fait. Donc on peut dire que les Design Pattern interviennent aussi dans la phase de codage. La connaissance de ces motifs permet au programmeur de trouver rapidement des implémentations pour ses programmes.

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 .

La façade permet de simplifier cette complexité en fournissant une interface simple du sous-système. 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.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. Un exemple du Design Pattern « Façade » L’application de ce Design Pattern à notre application se concrétise comme suit : Page 86 . Habituellement.

et les différentes possibilités qu’il nous offre afin de mettre en pratique un autre Design Pattern qui est le MVC. Ce Design Pattern est intégré à Java au travers des classes Observable et Observer du package Java. Ce modèle d'architecture impose la séparation entre les données. ce qui donne trois parties fondamentales dans l'application finale : le modèle. interactions avec la base de données.util. Ce dernier en avise ses observateurs qui questionnent en retour le sujet pour obtenir les informations nécessaires à leur mise à jour. Elle peut être conçue en html. Le sujet centralise les données et il est unique. 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. et plusieurs peuvent se synchroniser sur le même sujet. la Vue : correspond à l'interface avec laquelle l'utilisateur interagit. la vue et le contrôleur :   Le Modèle : représente le comportement de l'application : traitements des données. Nous distinguons de ce fait le sujet et les observateurs.il comprend des opérations permettant aux observateurs d’accéder à ses données. (Florian GRISONI) Remarque : Ce Design Pattern a été intensément utilisé dans notre logiciel pour sa facilité de mise en œuvre. 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’observateur restitue les données du sujet auquel il est abonné. Plusieurs vues peuvent afficher les informations d'un même modèle. ou tout autre « langage » de Page 87 . La dynamique d’échange entre le sujet et ses observateurs abonnés s’établit à partir d’une notification indiquant une modification du sujet. l'interface utilisateur et la logique de contrôle. Il décrit les données manipulées par l'application et définit les méthodes d'accès. etc.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épendances qui devraient s’établir entre eux. les traitements et la présentation.

(Cornell) Page 88 . et les vues ne s'en trouvent pas affectées. si le modèle ne l'a pas déjà fait. lorsqu'un client envoie une requête à l'application. En effet. le Contrôleur : prend en charge la gestion des événements de synchronisation pour mettre à jour la vue ou le modèle. « Swing » la bibliothèque graphique de Java pour la création d’interfaces graphiques. la modification des traitements ne change en rien la vue. ne modifie aucune donnée. 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. présentation. En résumé. La vue n'effectue aucun traitement. et de permettre à l'utilisateur d'interagir avec elles. 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. est basée sur le modèle MVC. Cela simplifie la tâche du développeur qui tenterait d'effectuer une maintenance ou une amélioration sur le projet. Il n'effectue aucun traitement. (Wikipedia) Comme exemple. elle se contente d'afficher les résultats des traitements effectués par le modèle. puis renvoie la vue adaptée au navigateur. celle-ci est analysée par le contrôleur. qui demande au modèle approprié d'effectuer les traitements. Un avantage apporté par ce modèle est la clarté de l'architecture qu'il impose.

nous allons l’utiliser pour la génération du code à partir des diagrammes de classes. Mais aussi. 5. 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.2. Notre choix s’est porté vers l’EDI NetBeans. nous facilitera la transformation de notre modèle objet vers le code. qui étant Orienté Objet à la base. 5. du fait qu’il peut générer aussi les différents packages avec leurs classes respectives. La génération de code avec NetBeans 5. L’application « JStudent » Page 89 . Nous bénéficierons dans ce cas d’un gain de temps non négligeable. CODAGE Le choix du langage s’est porté vers Java. nous avons pu créer les différents diagrammes UML définis lors de la phase de conception.5.1. qui nous fournit le confort et la simplicité nécessaires à un développement propre et rapide.5: Grace au plugin UML intégré à NetBeans.

Métier et DAO.  La couche « Présentation » est chargée de tout ce qui est affichage.  La couche « DAO » est l’intermédiaire entre les autres couches et la Base de données.  La couche « Métier » est la logique métier de l’application. Figure représentant les 3 couches de l’application Page 90 .Structure générale de l’application : L’application est découpée en 3 couches distinctes. elle est le cœur et c’est elle qui définit toutes les règles régissantes au fonctionnement de l’application. Présentation.

La couche Métier : Voici quelques figures représentants un échantillon du code source de cette couche : La classe « Promotion » (à gauche les Attributs et les Méthodes) Page 91 .

La classe « Domaine » (à gauche les Attributs et les Méthodes) Page 92 .

La classe « Etudiant » (à gauche les Attributs et les Méthodes) Page 93 .

La couche Présentation : Voici quelques figures représentants l’interface du logiciel : La fenêtre principale Page 94 .

Fiche de création d’un nouvel étudiant Page 95 .

Fiche de création d’une nouvelle promotion Page 96 .

Fiche de consultation d’une promotion Page 97 .

Fiche de relevé de notes Page 98 .

Cependant. Mais la solution de la sérialisation réponds largement à nos besoins pour ce projet. Une technique plus aboutie aurait été un meilleur choix comme : le mapping Objet/Relationnel avec un outil comme Hibernate. c’est pour ça que nous avons jugé pertinent de la garder. Page 99 . l’apprentissage de cet outil demande un temps supplémentaire.Le stockage de données : La technique choisie pour persister les données est : la sérialisation.

être un besoin réel pour les utilisateurs de notre application. Identification du besoin : On suppose que la « gestion de salles » se trouve finalement. on va alors donner un cas concret de ce que pourrait être un ajout d’un nouveau besoin fonctionnel. Page 100 . du cadre limité (humain et matériel) dans lequel nous avons mené notre projet. Mais en ce qui concerne la prise en compte d’une évolution possible de l’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. 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. on ne va pas tirer de conclusion définitive sur la méthode. chercher une salle libre afin que les cours puissent y être enseignés.Bilan de la méthode Du fait de notre manque d’expérience dans le domaine et. Nous allons donc montrer comment on pourrait ajouter cette fonctionnalité à notre projet de façon concrète.

lui affecter une salle. se traduira par un ajout de ces deux classes au package Etudes. 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.Cas d’utilisation « Gérer les salles » On peut à la suite de création d’une promotion. De ce fait. afin de dégager les liens possibles entre ces deux classes et les autres classes des autres packages. Et il devrait y avoir un lien entre la classe Salle et Promotion. et continuer avec le modèle statique et dynamique. Concrètement dans le code : Normalement. Elle choisit un numéro. Page 101 . Elle spécifie l’étage. il aurait fallu faire une étude plus approfondie. Salle. ça se traduira par l’ajout d’un attribut de Type Salle. Ce qui nous amène à l’introduire au package « Gestion des départements ». le cas d’utilisation « gérer les salles » pourra étendre le cas d’utilisation « établir les promotions ». nous pouvons en déduire déjà deux classes : Bloc. La « gestion des salles » pourra aussi être comprise comme une spécification de chaque département. Nous pouvons cependant dire que ce nouveau besoin fonctionnel. Dans le code. 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.

Ceci ne devrait pas affecter le codage en général. Page 102 . Ça demande de faire une itération complète ou partielle selon le besoin. du fait que les responsabilités des différentes classes et packages ont été bien séparées. et ne pas succomber à la tentation de toucher rapidement au code. Conclusion Nous pouvons constater que l’ajout de nouvelles fonctionnalités peut être simplifié. du cycle Y. pour peu qu’on respecte bien les étapes définies par 2TUP.

Conclusion générale
Nous avons tenté à travers ce projet de démontrer l’importance de l’application d’une méthode de développement. Nous pensons aussi que 2TUP pourra être utilisée dans des projets de moyenne à grande envergure. A titre personnel, le bénéfice qu’on en a tiré est l’apprentissage de concepts à la pointe de la technologie et des tendances actuelles dans le monde professionnel. Une recherche profonde a été indispensable pour essayer de comprendre ces concepts là. Nous pouvons citer à ce propos, un excellent livre traitant ce sujet qui s’appelle : UML 2 En Action. Ce projet nous a permis d’enrichir nos connaissances dans des domaines très variés comme : L’Orienté Objet, UML, 2TUP, le langage JAVA, les Design Patterns, Swing… En termes d’évolution, l’application pourra par la suite être adaptée à une utilisation à l’université. Par exemple, une base de données pourra être utilisée soit par le biais d’un pont JDBC, ou par le biais d’une solution de Mapping Objet/ Relationnel comme Hibernate. Aussi, un déploiement sur un réseau pourra être fait grâce au framework J2EE. 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 notion de classe. Une classe est un type de données abstrait, caractérisé. Par des propriétés (attributs et méthodes) communes à toute une famille d’objets et permettant de créer (instancier) des objets possédant ces propriétés. Les autres concepts importants qu’il nous faut maintenant introduire sont l’encapsulation, l’héritage et l’agrégation.

Encapsulation
L’encapsulation consiste à masquer les détails d’implémentation d’un objet, en définissant une interface. L’interface est la vue externe d’un objet, elle définit les services accessibles (offerts) aux utilisateurs de l’objet. L’encapsulation 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 dont L’objet est utilisé. L’encapsulation garantit l’intégrité des données, car elle permet d’interdire, ou de restreindre, l’accès direct aux attributs des objets.

Héritage, Spécialisation, Généralisation et polymorphisme
L’héritage 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.

Page 105

Pour programmer une application. Une relation d’agrégation permet donc de définir des objets composés d’autres objets. L’héritage évite la duplication et encourage la réutilisation. Les spécifications fournies par la maîtrise d’ouvrage en programmation impérative étaient souvent floues: les articulations conceptuelles (structures de données. son produit est un modèle. L’Agrégation Il s’agit d’une relation entre deux classes. et donc la qualité. la spécialisation et la généralisation permettent de construire des hiérarchies de classes. L’héritage peut être simple ou multiple. (Meyer. Page 106 .Ainsi. tout en transcrivant les besoins du métier. du code. de leurs relations. L’agrégation permet donc d’assembler des objets de base. les documenter. puis organiser la réalisation en définissant les modules et étapes de la réalisation. Le polymorphisme augmente la généricité. spécifiant que les objets d’une classe sont des composants de l’autre classe. Le polymorphisme représente la faculté dune méthode à pouvoir s’appliquer à des objets de classes différentes. algorithmes de traitement) s’exprimant dans le vocabulaire de l’informatique. 2000) UML Introduction La description de la programmation par objets a fait ressortir l’étendue du travail conceptuel nécessaire: définition des classes. afin de construire des objets plus complexes. des interfaces etc. le modèle devait souvent être élaboré par celle-ci. des attributs et méthodes. C’est cette démarche antérieure à l’écriture que l’on appelle modélisation. L’approche objet permet en principe à la maîtrise d’ouvrage des exprimer de façon précise selon un vocabulaire qui. il ne convient pas de se lancer tête baissée dans l’écriture du code : Il faut d’abord organiser ses idées.

En principe seulement. 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). ou de tout autre système complexe. car la modélisation demande aux maîtrises d’ouvrage une compétence. un professionnalisme qui ne sont pas aujourd’hui répandus.e. et dont la juxtaposition donnera une idée utilisable en pratique sans risque d’erreur grave. UML est donc un méta-langage car il fournit les éléments permettant de construire le modèle qui. sera le langage du projet. lui. Ils ont préféré se borner à définir un langage graphique qui permet de représenter. Mais il est possible de donner sur un tel système des vues partielles.pourra être immédiatement compris par les informaticiens. UML en œuvre UML n’est pas une méthode (i. analogues chacune à une photographie d’une statue. Les diagrammes d’UML UML 2. de même qu’il est impossible de représenter entièrement une statue (à trois dimensions) par des photographies (à deux dimensions). 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. Il est impossible de donner une représentation graphique complète d’un logiciel. 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 .0 comporte ainsi treize types de diagrammes représentant autant de vues distinctes pour représenter des concepts particuliers du système d’information.

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. 4. 2. Le langage Java a la particularité principale d'être portable sur plusieurs systèmes d’exploitation. 5. et l'API JAVA (ces deux derniers composants forment l'environnement d'exécution. utiliser une méthode orientée objet. ou JRE. de classes. d’objets. Page 108 . Les diagrammes de composants. LE LANGAGE JAVA Java est à la fois un langage de programmation et un environnement d’exécution. Le système Java est basé sur le langage Java. la machine virtuelle java. pouvoir exécuter du code distant de manière sûre. C'est la plateforme qui garantit la portabilité des applications développées en Java. il avait été décidé que ce langage devait répondre à 5 objectifs : 1. pouvoir utiliser de manière native les réseaux informatiques. 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. pour Java Runtime Environment). 3. être facile à utiliser et posséder les points forts des langages de programmation orientés objet comme le C++. de cas d’utilisation. ne sont pas nécessairement tous produits à l’occasion d’une modélisation. permettre à un même programme d'être exécuté sur plusieurs systèmes d'exploitation différents. Les plus utiles pour la maîtrise d’ouvrage sont les diagrammes d’activités. (Cornell) Lors de la création du langage Java. de séquence et d’états-transitions. d’une utilité variable selon les cas.

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. Model : Le modèle défini les données de l'application et les méthodes d'accès. l'application en trois parties bien distinctes : 1. tout comme MVC. Buisness logic : La couche métier qui s'occupe du traitement de l'information. 2. Page 109 . L'architecture 3-Tiers L'architecture 3-Tiers sépare.DIFFERENCE ENTRE L’ARCHITECTURE 3-TIERS ET LE MODELE MVC Les noms d'architectures MVC et 3-Tiers sont très couramment utilisés dans les cours de génie logiciel. 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). 3. Il est facile de s'emmêler les pinceaux car ces deux pratiques sont à la fois différentes et similaires. User interface : La partie présentation de l'application. 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. 2. Tout les traitements sont effectués dans cette couche. 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). 3. View : La vue prend les informations en provenance du modèle et les présente à l'utilisateur. Les trois parties du pattern MVC sont les suivantes : 1.

Loin d'être antagonistes.Inversement pour qu'une application 3-Tiers respecte MVC il faut lui ajouter une couche de contrôle entre User interface et Buisness logic. ces deux pratiques se combinent et sont la fondation de la plupart des frameworks de création d'applications Web. Page 110 .

You're Reading a Free Preview

Télécharger
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->