37222279-2TUP

Suivie des enseignements du LMD par application de la mthode 2TUP

Universit Abou Bekr Belkaid de Tlemcen

Facult des Sciences de lIngnieur

Dpartement dInformatique

Suivie des enseignements du LMD par application de la mthode 2TUP

Projet de Fin dEtudes pour lobtention du Diplme dIngnieur dEtat en Informatique

Option : informatique industrielle

Kazi Aouel Bassim et Rostane Zakaria

Encadrs par Mr. Ziani CherifSalim

Prsent le 08 novembre 2007

devant le jury:

Mr. ABDERRAHIM AmineMr. CHIKH Azzeddine

Mr.CHOUITI S-Mohammed

Je ddie ce mmoire

mon pre et ma mre pour leur soutien tout au long de mes tudes

Un coucou Selma et Sofiane

mon grand pre 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 amiset amies

et tous ceux qui mont encourag

A la mmoire de mes oncles Lotfi et Amine, que leurs mes reposent en paix

Bassim

Je ddie ce mmoire

A ma chre mre pour son soutien tout au long de mes tudes

A mes surs et frres:

nadjia, mohamed, toufik, choumicha, chahrazed

ainsi qu mes belles surs et beaux frres: amine, hicham, khalil, sihem, lela

sans oublier mes nices et mes neveux:

chahinez, wafaa, farah, walid, sarah, ryadh, marouane et mouhcine

A tous mes amis et toute mes amieset tous ceux qui mont encourag

ZakiRemerciementsOn remercie Monsieur Ziani Cherif Salim pour laide quil nous a apportAussi, on remercie Hakim (Kimz) pour laide quil nous a apport afin de rendre notre rapport meilleur,

et Zakia et Nadia pour le temps quils ont pass corriger le mmoire

Rsum:

Nous proposons dans le cadre de ce projet de fin dtudes, dappliquer la mthode 2TUP au problme de la gestion des enseignements LMD luniversit de Tlemcen.

La gestion dun cycle de vie de logiciel requit un grand sens de la rigueur et de ladaptation aux changements continuels imposs au monde de lentreprise.

Cest pour a que nous avons choisi daxer notre travail sur une mthode de dveloppement qui est ne de travaux pousss vers la standardisation et la flexibilit, et ce pour rpondre aux contraintes actuelles de gestion des dveloppements.

Le mmoire sera dcoup en 5 grands chapitres:

1. Introduction: nous parlerons dans ce chapitre des objectifs que nous voudrions atteindre, ainsi quun aperu des diffrentes mthodes existantes.2. La mthode 2TUP: ce chapitre contient les dfinitions des diffrents concepts utiliss dans ce document.

3. Conception du logiciel: cest ici que nous allons appliquer la mthode 2TUP au problme de la gestion des enseignements en suivant les phases suivantes: ltude prliminaire, capture des besoins fonctionnels, analyse, conception et codage.

4. Bilan de la mthode 2TUP: nous allons donner un bref aperu de ce que pourrait tre un ajout dun nouveau besoin fonctionnel.5. Conclusion gnraleTable des matires4Table des matires

6Introduction

61.Le contexte de TRAVAIL

62.OBJECTIFS

73.Comparaison entres les diffrentes approches

84.Prsentation de lapplication RALISER

9La mthode 2TUP

101.Dfinition dun processus de dveloppement LOGICIEL

102.Le Processus UNIFI

113.Le Processus 2TUP

134.Un processus de modlisation avec UML

15Conception du logiciel

151.Etude PRLIMINAIRE

151.1.Prsentation du projet raliser

151.2.Recueil des besoins fonctionnels

171.3.Choix techniques

171.4.Identification des acteurs

181.5.Identification des messages

191.6.Modlisation du contexte

202.Capture des besoins FONCTIONNELS

212.1.Dterminer les cas dutilisations

242.2.Description prliminaire des cas dutilisations

252.3.Description dtaille des cas dutilisations

392.4.Structuration des cas dutilisationsdans des packages

402.5.Identification des classes candidates

473.ANALYSE

473.1.Dcoupage en catgories

483.2.Dpendances entre catgories

543.3.Diagramme de packages danalyse

553.4.Dveloppement du modle statique

633.5.Dveloppement du modle dynamique

794.CONCEPTION

794.1.Architecture de lapplication

804.2.Les Design Patterns

895.CODAGE

895.1.La gnration de code avec NetBeans5.5:

895.2.Lapplication JStudent

99Bilan de la mthode

102Conclusion gnrale

103Bibliographie

104Annexe:

104Lapproche Oriente OBJET

105UML

107Le langage Java

107Diffrence entre larchitecture 3-tiers et le modle MVC

Introduction

1. Le contexte de TRAVAIL

La complexit croissante des systmes informatiques a conduit les concepteurs sintresser aux mthodes de dveloppement. Ces dernires ont toujours essay dapporter un contrle continu sur un projet tout au long de son processus de vie.

Bien que des mthodes de dveloppement existent depuis 30 ans (Merise, SADT), nous ne pouvons constater aujourdhui lexistence dune rgle qui soit la fois formelle et commune aux diffrentes cultures.

Par ailleurs, des mthodes squentielles comme celles se basant sur le cycle en V, ont montr leur limite dans un environnement rgi par des changements rguliers, impliquant une impossibilit revenir en arrire, et de ce fait, laissant une trs petite marge lerreur.

Avec lavnement de la pense objet, de nouvelles mthodes sont apparues et diffrentes notations ont t tablies. UML a ouvert le terrain de lunification en fusionnant ces notations et en apportant prcision et rigueur la dfinition des concepts introduits.

Sur cet lan, les spcialistes ont aussi pens unifier non pas les processus, mais plus exactement les meilleures pratiques de dveloppement orient objet.2. OBJECTIFS

Notre but est dappliquer une mthode rigoureuse de conduite dun projet rel. Le projet en question concerne la gestion des enseignements.

Ce projet a pour objectif principal de proposer une solution un problme concret, et ceci en partant dune dfinition des besoins. Nous esprons travers celui-ci, dmontrer limportance de lapplication dune mthodologie de dveloppement, et aussi permettre par la suite que ce produit puisse tre volutif et facilement maintenable par des intervenants tiers.3. Comparaison entres les diffrentes approches

Modlisation

Par le pass, le modle Entit-Relation reprsentait une grande partie des approches les plus utilises.

Actuellement, les nouvelles technologies sappuient sur le modle objet.

En termes danalyse et de modlisation objet, UML est devenu un standard incontournable, stabilis, industriel.

Conduite de projetAu dbut, le cycle en cascade (ex: le cycle en V) tait trs utilis. Mais on a vite constat son incapacit sadapter aux diffrents changements.

Une mthode semi-itrative est apparut (RAD) pour pallier aux carences de ce dernier.

Litratif sest ensuite impos, parce quil rduit la complexit de ralisation des phases, en travaillant par approches successives et incrmentales.

Une mthode fortement axe sur litratif et le modle UML est alors apparut, il sagit de UP (Unified Process). Cette mthode comme son nom lindique, a t le fruit de travail de plusieurs personnes voulants unifier les diffrentes mthodes objets existantes ce momentcomme Booch, OMT et OOSE.

On constate aujourdhui, lmergence dune nouvelle approche: les mthodes agiles (Agile Modeling). Cest des mthodes itratives planification souple qui leur permettent de sadapter la fois aux changements du contexte et de spcifications du projet. (Chromatic, 2005)4. Prsentation de lapplication RALISER

De nos jours, une des tendances les plus en vue et qui concerne tout les secteurs de dveloppement, est linformatisation.

Depuis lapparition de linformatique et son introduction dans le monde conomique, les entreprises et entits publiques aspirent optimiser et rendre fiable la gestion de leur structure interne.

Luniversit de Tlemcen possde quelques milliers dtudiants quil est difficile de grer en continu. Avec la mise en place rcente du systme LMD, la situation sest davantage complique et la tche de gestion est devenue plus complexe. Le projet que nous proposons nous permettra de faciliter la gestion des enseignements, travers la conception dun logiciel avec une mthode que nous allons prsenter.

La mthode 2TUP

Devant le nombre de mthodes disponibles, le choix parmi elles devient difficile, beaucoup de questions peuvent se poser un chef de projet lors dun dmarrage de projet:

Comment vais-je organiser les quipes de dveloppement;

Quelles tches attribuer qui;

Quel temps faudrait-il pour livrer le produit;

Comment faire participer le client au dveloppement afin de capter les besoins de celui-ci;

Comment viter des drives et de mauvaises estimations qui vont allonger les cots et le temps de dveloppement.

Comment vais-je procder pour que le produit soit volutif et facilement maintenable.

Nous pouvons citer ce propos les mthodes de dveloppement objet suivantes: 2TUP, RUP, XP, AUP et OpenUP.

Notre choix sest port vers la mthode 2TUP, du fait de son approche nouvelle, originale.

Notre projet est bas sur un processus de dveloppement bien dfini qui va de la dtermination des besoins fonctionnels attendus du systme jusqu la conception et le codage final.

Ce processus se base lui-mme sur le Processus Unifi (Unified Process) qui est devenu un standard gnral runissant les meilleures pratiques de dveloppement.

Cette mthode ne se base aucunement sur un processus linaire mais bien, sur un dveloppement itratif et incrmental.

Nous allons dabord dfinir les diffrents concepts qui vont tre utiliss dans ce document.

1. Dfinition dun processus de dveloppement LOGICIEL

Un processus dfinit une squence dtapes, en partie ordonnes, qui concourent lobtention dun systme logiciel ou lvolution dun systme existant.

Lobjet dun processus de dveloppement est de produire des logiciels de qualit qui rpondent aux besoins de leurs utilisateurs dans des temps et des cots prvisibles. (Rocques & Valle, 2004)2. Le Processus UNIFI

Le Processus Unifi (PU ou UP en anglais pour Unified Process) est une mthode de dveloppement logiciel construite sur UML; elle est itrative et incrmentale, centre sur larchitecture, conduite par les cas dutilisation et pilote par les risques. itrative et incrmentale: la mthode est itrative dans le sens o elle propose de faire des itrations lors de ses diffrentes phases, ceci garantit que le modle construit chaque phase ou tape soit affin et amlior. Chaque itration peut servir aussi ajouter de nouveaux incrments. conduite par les cas dutilisation: elle est oriente utilisateur pour rpondre aux besoins de celui-ci. centre sur larchitecture: les modles dfinit tout au long du processus de dveloppement vont contribuer tablir une architecture cohrente et solide. pilote par les risques: en dfinissant des priorits pour chaque fonctionnalit, on peut minimiser les risques dchec du projet.

La gestion dun tel processus est organise daprs les 4 phases suivantes:1. Pretude(Inception): cest ici quon value la valeur ajoute du dveloppement et la capacit technique le raliser (tude de faisabilit).2. Elaboration: sert confirmer ladquation du systme aux besoins des utilisateurs et livrer larchitecture de base.3. Construction: sert livrer progressivement toutes les fonctions du systme.4. Transition: dployer le systme sur des sites oprationnels.Chaque phase est elle-mme dcompose squentiellement en itrations limites dans le temps (entre 2 et 4 semaines). Le rsultat de chacune delles est un systme test, intgr et excutable. Lapproche itrative est fonde sur la croissance et l'affinement successifs dun systme par le biais ditrations multiples. Le systme crot avec le temps de faon incrmentale, itration par itration, et cest pourquoi cette mthode porte galement le nom de dveloppement itratif et incrmental. Il sagit l du principe le plus important du Processus Unifi.

Ces activits de dveloppement sont dfinies par 6 disciplines fondamentales qui dcrivent la capture des besoins, la modlisation mtier, lanalyse et la conception, limplmentation, le test et le dploiement.

Notons que ces diffrentes tapes (ou disciplines) peuvent se drouler travers plusieurs phases.

Le processus unifi doit donc tre compris comme une trame commune des meilleures pratiques de dveloppement.3. Le Processus 2TUP

On dit de la mthode UP quelle est gnrique c..d. quelle dfinit un certain nombre de critres de dveloppement, que chaque socit peut par la suite personnaliser afin de crer son propre processus plus adapt ses besoins.

Cest dans ce cadre que la socit Valtech a cre la mthode 2TUP.2TUP signifie 2 Track Unified Process.Cest un processus qui rpond aux caractristiques du Processus Unifi. Le processus 2TUP apporte une rponse aux contraintes de changement continuel imposes aux systmes dinformation de lentreprise. En ce sens, il renforce le contrle sur les capacits dvolution et de correction de tels systmes.2 Track signifie littralement que le processus suit deux chemins. Il sagit des chemins fonctionnels et darchitecture technique, qui correspondent aux deux axes de changement imposs au systme dinformation.

Figure: Le systme dinformation soumis deux types de contraintesLa branche gauche (fonctionnelle): capitalise la connaissance du mtier de lentreprise. Elle constitue gnralement un investissement pour le moyen et le long terme.Les fonctions du systme dinformation sont en effet indpendantes des technologies utilises.Cette branche comporteles tapes suivantes : La capture des besoins fonctionnels, qui produit un modle des besoins focalis sur le mtier des utilisateurs.

Lanalyse.

La branche droite (architecture technique) : capitalise un savoir-faire technique. Elle constitue un investissement pour le court et moyen terme. Les techniques dveloppes pour le systme peuvent ltre en effet indpendamment des fonctions raliser.Cette branche comporteles tapes suivantes : La capture des besoins techniques.

La conception gnrique.

La branche du milieu : lissue des volutions du modle fonctionnel et de larchitecture technique, la ralisation du systme consiste fusionner les rsultats des 2 branches. Cette fusion conduit lobtention dun processus en forme de Y.Cette branche comporte les tapes suivantes:

La conception prliminaire.

La conception dtaille.

Le codage.

Lintgration.

Figure: Le processus de dveloppement en Y

4. Un processus de modlisation avec UML

Le processus 2TUP sappuie sur UML tout au long du cycle de dveloppement, car les diffrents diagrammes de ce dernier permettent de part leur facilit et clart, de bien modliser le systme chaque tape.

Unified Modeling Language: UML se dfinit comme un langage de modlisation graphique et textuel destin comprendre et dcrire des besoins, spcifier, concevoir des solutions et communiquer des points de vue. (Pitman, 2006)UML unifie la fois les notations et les concepts orients objet.il ne sagit pas dune simple notation, mais les concepts transmis par un diagramme ont une smantique prcise et sont porteurs de sens au mme titre que les mots dun langage, cest pour a quUML est prsent parfois comme une mthode alors quil ne lest absolument pas.UML unifie galement les notations ncessaires aux diffrentes activits dun processus de dveloppement et offre, par ce biais, le moyen dtablir le suivi des dcisions prises, depuis la dfinition des besoins jusquau codage. (Roques, 2006)Voici une prsentation rapide des diffrents diagrammes UML qui vont tre utiliss tout au long du projet:Le diagramme des cas dutilisation: reprsente la structure des fonctionnalits ncessaires aux utilisateurs du systme. Il est normalement utilis lors des tapes de capture des besoins fonctionnels et techniques.

Le diagramme dactivits: reprsente les rgles denchanement des activits et actions dans le systme. Il peut tre assimil comme un algorithme mais schmatis.

Le diagramme de packages: prsent depuis UML 2.0, ce diagramme modlise des catgories cohrentes entre elles, pour un souci de partage des rles.

Correspond ltape de modlisation des diffrents scnarios dun cas dutilisation.

Le diagramme de classes: srement lun des diagrammes les plus importants dans un dveloppement orient objet. Sur la branche fonctionnelle, ce diagramme est prvu pour dvelopper la structure des entits manipules par les utilisateurs.

En conception, le diagramme de classes reprsente la structure dun code orient objet.

Le diagramme de squence: reprsente les changes de messages entre objets, dans le cadre dun fonctionnement particulier du systme.Le diagramme dtats: reprsente le cycle de vie dun objet. Il spcifie les tats possibles dune classe et leur enchainement.

Ce diagramme est utilis lors des tapes danalyse et de conception.

Conception du logiciel

1. Etude PRLIMINAIRE

Ltude prliminaire (ou Pretude) est la toute premire tape du processus 2TUP. Elle consiste effectuer un premier reprage des besoins fonctionnels et oprationnels, en utilisant principalement le texte, ou diagrammes trs simples. Elle prpare les activits plus formelles de capture des besoins fonctionnels et de capture techniques.

1.1. Prsentation du projet raliser

Cest un logiciel qui doit grer le cursus universitaire des tudiants dans le systme LMD en gnral.

Il doit permettre de suivre les tudiants depuis leur inscription luniversit jusqu lobtention du diplme de Licence.1.2. Recueil des besoins fonctionnels

Nous avons effectu plusieurs recherches pour identifier au mieux les besoins de lapplication, et ceci afin de rpondre aux attentes des utilisateurs.

Nous sommes alls chercher les informations au sein de ladministration de la Facult. Cette phase correspond une recherche sur le terrain pour bien dfinir le cadre de notre systme.

Nous nous sommes aussi procur quelques documents, qui expliquent le mode de fonctionnement du systme LMD, et a nous a permis dtablir le cahier des charges prliminaire suivant:

Organisation des dpartements :

_____________________________________________________________________

Une universit se compose de plusieurs dpartements (informatique, physique, maths, chimie ), dont chacun est dirig par un chef de dpartement.

Chaque dpartement voit son parcours de formation structur en 3 paliers:

Le premier palier doit tre compos au plus de 2 semestres.

Le deuxime palier dau moins 2 semestres.

Le troisime palier est une tape de spcialisation. Organisation du parcours de formation dans le systme LMD:

_____________________________________________________________________

La formation en vue de lobtention du diplme de licence est rpartie en 6 semestres, la diffrence dune formation classique.

Les parcours sont organiss en units denseignements(UE) articules entre elles.

Une UE est constitue dune ou de plusieurs matires dispenss par toute forme denseignements (Cours, Travaux Dirigs, Travaux Pratiques, projets).

Chaque UE et chacune de ses matires constitutives sont affectes dune valeur en crdits. La valeur totale de ces crdits est fixe 30 par semestre.

Une UE est considre comme acquise si la moyenne de lensemble des notes obtenues dans les matires qui la constituent, affectes de leurs coefficients respectifs, est gale ou suprieur 10.

Pour chaque semestre denseignement, deux sessions de contrle sont organises.la deuxime session est une session de rattrapage.

Le semestre est acquis pour tout tudiant ayant obtenu lensemble des UEs qui le composent.

Le semestre peut tre galement acquis par compensation entres les diffrentesUEs.

La moyenne gnrale est calcule sur la base des moyennes obtenues aux UEs composant le semestre pondres par leurs coefficients respectifs.

Le semestre est alors acquis si cette moyenne est gale ou suprieure 10.

En cas dchec la premire session, ltudiant se prsente aux examens de rattrapage pour les UEs non acquises.

Ltudiant garde le bnfice des matires de lUE pour lesquelles il a obtenu une moyenne gale ou suprieure 10.

Progression:

_____________________________________________________________________

La progression du premier au second semestre dune mme anne universitaire est de droit pour tout tudiant inscrit dans le mme parcours.

La progression de la premire la deuxime anne de la Licence, est de droit si ltudiant a acquis les deux premiers semestres du cursus de formation. Cependant, elle peut tre autorise pour tout tudiant ayant acquis au moins 30 crdits.

La progression de la deuxime la troisime anne est de droit si ltudiant a acquis les 4 premiers semestres du cursus de formation. Mais elle peut tre autorise si ltudiant a valid 80% des crdits relatifs aux 4 premiers semestres, et si ltudiant a valid aussi les units denseignements fondamentales.

Lacquisition du diplme de Licence est effective si ltudiant a valid les 6 semestres du cursus de formation. Gestion des promotions:

_____________________________________________________________________

Pour chaque dpartement et chaque anne dtudes, une promotion doit tre cre.

La promotion contient un certain nombre dtudiants encadrs par des enseignants. Gestion des tudiants:

_____________________________________________________________________

Un tudiant ds son inscription luniversit, peut tre affect une promotion selon la filire quil a choisie.

1.3. Choix techniques

Voici les choix techniques qui ont t adopts pour le projet: La modlisation avec UML.

Adoption dune architecture 3 couches.

Utilisation du langage Java.

Omission dune base de donnes au profit de la srialisation (Java).

Utilisation des Design Patterns (MVC, Etat, Faade ). Utilisation de lEDI NetBeans et de son plugin UML.

Remarque: la branche droite qui dsigne ltude de larchitecture technique va tre ignore, du fait du manque de temps notre disposition et de la complexit de la chose.1.4. Identification des acteurs

Nous allons maintenant numrer les acteurs susceptibles dinteragir avec le systme, mais dabord nous donnons une dfinition de ce que cest un acteur.

Dfinition: un acteur reprsente l'abstraction d'un rle jou par des entits externes (utilisateur, dispositif matriel ou autre systme) qui interagissent directement avec le systme tudi.

Les acteurs du systme identifis dans un premier temps sont:

Etudiant: Un tudiant peut consulter ses relevs de notes, son emploi du temps. Chef de dpartement: le chef de dpartement tablit le cursus de son dpartement, il cre les promotions et suit leur volution.Il choisit les enseignants responsables des cours. Scolarit: la scolarit introduit les notes des tudiants. Enseignant: lenseignant affecte les notes des tudiants de son module.

Administrateur:cre les profils utilisateurs et attribue les droits daccs.

1.5. Identification des messages

On va dtailler les diffrents messages changs entre le systme et lextrieur.

Dfinition: un message reprsente la spcification dune communication unidirectionnelle entre les objets qui transporte de linformation avec lintention de dclencher une activit chez le rcepteur.

Le systme met les messages suivants: Les relevs de notes des tudiants. Ltat davancement dune promotion. Le cursus dun tudiant. Les emplois du temps dune promotion. Les modules dun dpartement. Les fiches des tudiants. Les fiches des enseignants. Lorganisation dun dpartement. La liste des tudiants passs et recals la fin dun semestre. La liste des tudiants ayant acquis leur diplme.

Le systme reoit les messages suivants: Les crations, modifications, suppressions de fiches des tudiants/enseignants. Les crations, modifications, de promotions. Le lancement/bouclage dune promotion.

Laffectation des tudiants/enseignants une promotion. Les ajouts, suppressions, modifications des filires pour un dpartement. Les crations, modifications, suppressions des emplois du temps dune promotion.

Les crations, modifications, suppressions de profils utilisateurs. Les crations, modifications de spcialits pour un dpartement.1.6. Modlisation du contexte

A partir des informations obtenues lors des deux prcdentes tapes, nous allons modliser le contexte de notre application.

Ceci va nous permettre dans un premier temps, de dfinir le rle de chaque acteur dans le systme:Utilisateurs finauxDescription des besoins fonctionnels

Chef de dpartementLapplication doit permettre au chef de dpartement de:

Sauthentifier

Crer son dpartement Crer une promotion

Crer les spcialits/options Crer les UE et les Modules Suivre les promotions en cours Affecter les tudiants/enseignants une promotion

ScolaritLapplication doit permettre la Scolarit de:

Sauthentifier

Crer/modifier les fiches des tudiants

Affecter les notes des tudiants

EnseignantLapplication doit permettre lenseignant de:

Sauthentifier

Affecter les notes des tudiants pour son module

EtudiantLapplication doit permettre ltudiant de:

Sauthentifier

Consulter son relev de notes Consulter son emploi du temps

Consulter ses modules en dettes

AdministrateurLapplication doit permettre ladministrateur de:

Sauthentifier

Crer les profils utilisateurs

Donner des droits daccs

2. Capture des besoins FONCTIONNELSCette phase reprsente un point de vue fonctionnel de larchitecture systme. Par le biais des cas dutilisation, nous serons en contact permanent avec les acteurs du systme en vue de dfinir les limites de celui-ci, et ainsi viter de trop sloigner des besoins rels de lutilisateur final.1.7. Dterminer les cas dutilisations

Dfinition: un cas dutilisation reprsente un ensemble de squences dactions ralises par le systme et produisant un rsultat observable intressant pour un acteur particulier.Un cas dutilisation modlise un service rendu par le systme. Il exprime les interactions acteurs/systme et apporte une valeur ajoute notable lacteur concern.Utilisation doutils de gnration de diagrammes UML :Tout au long du projet, nous sommes passs par plusieurs outils qui gnrent les diagrammes UML. Nous allons faire une prsentation rapide de ceux l.

ArgoUML: cest un outil gratuit crit avec Java, nous lavons utilis au dbut puis nous lavons dlaiss pour sa lourdeur et son interface peu intuitive.

Bouml: srement loutil le plus lger sur le march, il est trs puissant et agrable utiliser, et en plus il est gratuit.NetBeansUML: cest un plugin intgr lEDI NetBeans, il est trs puissant avec de grandes possibilits de personnalisation, cependant il souffre dune lourdeur assez gnante si on na pas une machine puissante. Nous lavons utilis pour quelques Design Pattern et pour la gnration de code.

Identification des cas dutilisation :

Lidentification des cas dutilisation une premire fois, nous donne un aperu des fonctionnalits futures que doit implmenter le systme.

Cependant, il nous faut plusieurs itrations pour ainsi arriver constituer des cas dutilisation complets. Dautres cas dutilisation vont apparatre au fur mesure de la description de ceux l, et lavancement dans le recueil des besoins fonctionnels.

Pour constituer les cas dutilisation, il faut considrer l'intention fonctionnelle de l'acteur par rapport au systme dans le cadre de l'mission ou de la rception de chaque message. En regroupant les intentions fonctionnelles en units cohrentes, on obtient les cas d'utilisations.

Cas dutilisationActeur principal, acteurs secondairesMessages mis/reus par les acteurs

Organiser un dpartementChef de dpartement

Emet : Crer son dpartement,

Crer/modifier les spcialits/options,

Crer les UE et les Modules.

Grer les promotionsChef de dpartement

Emet: Crer une promotion,

Affecter les tudiants une promotion

Suivre les promotionsChef de dpartement

Emet: Commencer la promotion, slectionner les enseignants/semestre,

commencer/terminer un semestre,

passer au prochain semestre, orienter les tudiants vers les spcialits,

Reoit: liste des tudiants endetts, Liste des tudiants non endetts.

Grer les tudiantsScolaritEmet: Crer/modifier les fiches des tudiants.

Maintenir les notesScolarit, Enseignant

Emet: Affecter les notes aux tudiants,grer les rattrapages,

grer les modules en dettes.

Reoit: relev de notes

Consulter les notesEtudiantReoit: consulter son relev de notes.

Grer les emplois du tempsScolaritEmet: Crer/modifier les emplois du temps

Consulter les emplois du tempsEtudiant, EnseignantReoit: consulter les emplois du temps.

Grer les profilsAdministrateurEmet: Cration, modification, suppression de profils.

Remarque: Du fait quelle ne rentre pas dans le cadre de notre projet, la gestion des salles a t dlibrment omise.Remarque2: Ce premier tableau n'est pas dfinitif, un processus de dveloppement avec UML est itratif, il se peut qu'il change au fur et mesure de l'avancement du projet.

Diagramme des cas dutilisation

1.8. Description prliminaire des cas dutilisationsVoici une description prliminaire des cas dutilisations numrs prcdemment:Organiser les dpartements:

Intention: grer les dpartements. Actions: crer un nouveau domaine, une nouvelle spcialit, une nouvelle option, crer les UE, modifier les UE Grer les promotions: Intention: grer les promotions. Actions: crer une nouvelle promotion, affecter des tudiants, modifier ou annuler la promotion.Etablir les emplois du temps:

Intention: crer lemploi du temps pour une promotion. Actions: crer un nouvel emploi du temps, affecter une unit dheure un module et un enseignant, modifier ou annuler lemploi du temps.Grer les tudiants:

Intention: suivi des dossiers des tudiants aprs inscription de ces derniers. Actions: crer le dossier tudiant, rattacher ltudiant une anne universitaire, mettre jour le dossier.Grer les profils:

Intention: crer les diffrents profils des utilisateurs du systme. Actions: crer un nouveau profil, attribuer une fonction, attribuer des droits daccs, modifier le profil, crer un mot de passe.Maintenir les notes des tudiants:

Intention: affecter les notes aux tudiants. Actions: affecter les notes aux tudiants pour chaque module.Consulter lemploi du temps:

Intention: consulter lemploi du temps dune promotion. Actions: consulter lemploi du temps.Consulter les notes:

Intention: consulter les notes dun tudiant. Actions: choisir un tudiant et consulter la liste de ses notes.1.9. Description dtaille des cas dutilisationsNous allons maintenant dtailler chaque cas dutilisation qui doit faire lobjet dune dfinition a priori qui dcrit lintention de lacteur lorsquil utilise le systme et les squences dactions principales quil est susceptible deffectuer. Ces dfinitions servent fixer les ides et nont pas pour but de spcifier un fonctionnement complet et irrversible.

Remarque: les descriptions vont tre organises de la faon suivante:

Un sommaire didentification: va rsumer les proprits du cas dutilisation.

Une description dtaille: des Prconditions au dclenchement du cas dutilisation doivent tre spcifies, un scnario nominal dcrivant celui-ci additionn des scnarios alternatifs et dexceptions.

Les diagrammes(optionnelle): plusieurs diagrammes vont apparaitre (mais pas ncessairement) pour apporter une comprhension additive au cas dutilisation. Organiser les DPARTEMENTS:Sommaire DIDENTIFICATION: ______________________________________________________________

SHAPE \* MERGEFORMAT

Descriptions des ENCHANEMENTS: ______________________________________________________________

Prconditions:

Le chef de dpartement est authentifi.

Scnario nominal:

Ce cas dutilisation commence lorsque le chef de dpartement demande au systme de crer un nouveau domaine.

Enchanement (a): Crer un domaine en construction

Le chef de dpartement choisit un nom pour le dpartement.

Enchanement (b): Crer un tronc communPour la premire anne un tronc commun va tre constitu.

La dure de ce tronc commun est variable selon le domaine.

Enchanement (c): Crer les spcialits/options

Il peut spcifier les spcialits/options que le domaine va contenir.

Une dure en semestres doit tre renseigne.

Enchanement (d): valider un domaine en construction

Le chef de dpartement valide la cration.

Si le domaine existe dj dclencher:[Exception1: DomaineExistant]

Enchanements alternatifs:

Enchanement (e): crer les UELe chef de dpartement cre une UE, et choisit le type de cette UE (fondamentale, complmentaire, mthodologique, optionnelle, transversale, dcouverte).

Il cre les modules pour cette UE, spcifie un nom, le nombre dheures enseigner, un coefficient, et un crdit pour chaque module.Il valide le module, si Code existe dj dclencher: [Exception2: ModuleExistant]

Il valide lUE, si Code existe dj dclencher: [Exception3: UEExistante]

Enchanement (f): Modifier un domaine en constructionou valid

Pour un domaine, le chef de dpartement peut ajouter/supprimer une spcialit/option ou modifier un tronc commun.

Enchanement (g): Supprimer un domaine

Le chef de dpartement peut supprimer un domaine.

Si une promotion appartient ce domaine dclencher:[Exception4: DomaineUtilise]

Enchanement (h): Supprimer une UE

Il peut aussi modifier une UE ou la supprimer.

Si lUE est utilise dans une promotiondclencher:[Exception5: UEUtilisee]

Exceptions:

[Exception1: DomaineExistant]: le domaine est marqu en anomalie tant que le code na pas t chang.[Exception2: UEExistante]: lUE est marqu en anomalie tant que le code na pas t chang. LUE ne peut plus tre valide.

[Exception3: ModuleExistant]: le module est marqu en anomalie tant que le code na pas t chang. Le module ne peut plus tre valid.

[Exception4: DomaineUtilise]: un message est affich lcran avisant lutilisateur que le domaine ne peut pas tre supprim.[Exception5: UEUtilisee]: un message est affich lcran avisant lutilisateur que lUE ne pas tre supprime.Ce cas dutilisation se termine lorsque le chef de dpartement a valid un domaine.

Etablir les PROMOTIONS:Sommaire DIDENTIFICATION: ______________________________________________________________



Prconditions:

1- Le chef de dpartement est authentifi.

2- Au moins un enseignant existe dans la base.

3- Au moins un domaine existe.

Scnario nominal:

Ce cas dutilisation commence lorsque le chef de dpartement demande au systme de crer une nouvelle promotion.

Enchanement (a): Crer une promotion en construction

Le chef de dpartement choisit un code/nom et lanne de cration pour la promotion.

Enchanement (b): Rattacher un domaine

Il rattache la promotion un domaine.

Si le tronc commun/Spcialit na pas dUE dclencher: [Exception1: NoUECree]

Enchanement (c): Rattacher les tudiants

Le chef de dpartement slectionne tous les tudiants faisant partie de la promotion.

Si ltudiant appartient dj une promotion dclencher: [Exception2: EtudiantDejaAffecte]

Enchanement (f): fixer les dates dexamens

Le chef de dpartement fixe les dates des examens. Il fixe les dates de dbut/fin, il cre les groupes

Enchanement (g): valider une promotion en construction

Le chef de dpartement valide la promotion si aucune exception nest leve.


Enchanement (h): Modifier une promotion en constructionou valideLe chef de dpartement peut changer en cours dtudes, lenseignant en charge dun module.

Enchanement (i): Supprimer une promotionLe chef de dpartement peut supprimer une promotion si celle-ci na pas encore commenc les tudes.

Exceptions:

[Exception1: NoUECree]: la promotion est marqu en anomalie tant quune UE na pas t cre. La promotion ne peut plus tre valide.[Exception2: EtudiantDejaAffecte]: un message derreur est affich sur lcran avisant lutilisateur que ltudiant appartient dj la promotion.

Ce cas dutilisation se termine lorsque le chef de dpartement a valid une promotion.

Suivre une PROMOTION:Sommaire DIDENTIFICATION: ______________________________________________________________



Prconditions:


2- Au moins un enseignant existe dans la base.

3- Au moins un domaine existe.

4- Au moins une promotion existe.

Scnario nominal:

Ce cas dutilisation commence lorsque le chef de dpartement demande au systme de commencer les tudes dans une promotion.Enchanement (a): commencer les tudesIl slectionne les enseignants chargs de donner des cours, et attribue pour chacun deux un ou plusieurs modules enseigner.Si le module est dj attribu dclencher: [Exception1: ModuleDejaAttribue REF Exception_Module_Deja_Attribue \h \* MERGEFORMAT

REF Exception_Module_Deja_Attribue \h \* MERGEFORMAT



REF Exception_Module_Deja_Attribue \h \* MERGEFORMAT ]Il spcifie les caractristiques du module TD/TP/Projet/Sminaire/confrence.Commencer le 1er semestre et la promotion.

Enchanement (b): remplir les relevs de notesCas dutilisation ( Maintenir les notesEnchanement (c): terminer le semestreSi tous les relevs de notes sont remplis terminer le semestre, sinon dclencher: [Exception2: SemestreIncomplet ]Enchanement (d): passer au prochain semestreSi cest le premier semestre de lanne, le passage est automatique pour tous les tudiants, sinon si cest le deuxime, alors une session de rattrapage est prvu pour les tudiants qui nont pas tous les crdits requis. Les rsultats la suite des rattrapages vont dterminer: Les tudiants aptes passer au palier suprieur.

Les tudiants recals. Si le dernier semestre est termin, remise des diplmes aux tudiants ayants russis.

Si une spcialisation se prsente, orienter les tudiants vers les spcialits choisies.Enchanements alternatifs:Enchanement (e): Exclure un tudiant de la promotion

Le chef de dpartement peut exclure un tudiant de la promotion.

Exceptions:

[Exception1: ModuleDejaAttribue] : un message derreur est affich lcran avisant lutilisateur que le module est dj attribu.[Exception2: SemestreIncomplet]: un message derreur est affich sur lcran avisant lutilisateur que des relevs de notes ne sont pas complets.

Ce cas dutilisation se termine lorsque le chef de dpartement a termin une promotion.Diagramme DACTIVITS: ______________________________________________________________

Voici un diagramme dactivits reprsentant lenchainement des vnements pour le cas dutilisation: Suivre une promotion.

Diagramme dactivits reprsentant lenchainement des tapes dune promotionEtablir les emplois du TEMPS:Sommaire DIDENTIFICATION: ______________________________________________________________ SHAPE \* MERGEFORMAT


Prconditions:


2- Au moins une promotion a t cre.

Scnario nominal:

Ce cas dutilisation commence lorsque le chef de dpartement demande au systme de crer un nouvel emploi du temps.

Enchanement (a): Crer un emploi du temps en construction

Le chef de dpartement choisit une promotion pour qui lemploi du temps est destine.

Il slectionne un semestre pour lanne en cours.

Il slectionne une plage horaire.

Enchanement (b): Affecter les chargesIl slectionne un module parmi les modules de la promo.

Il affecte le module enseigner cette plage horaire.

Si le module enseigner est dj attribu alors dclencher: [Exception1: moduleErreur]

Il affecte un enseignant cette plage horaire.

Si lenseignant est dj pris pour cette plage alors dclencher: [Exception2: enseignantErreur]

Enchanement (c): Valider un emploi du temps en construction

Le chef de dpartement valide lemploi du temps.


Enchanement (d): Modifier un emploi du temps en constructionou validLe chef de dpartement dsaffecte une charge pour une plage horaire.

Enchanement (e): Supprimer un emploi du tempsLe chef de dpartement supprime un emploi du temps.Exceptions:

[Exception1: moduleErreur]: un message derreur reste affich sur lcran tant que le module na pas t enlev de lemploi du temps.[Exception2: enseignantErreur]: un message derreur reste affich sur lcran tant que lenseignant na pas t enlev de lemploi du temps.Ce cas dutilisation se termine lorsque le chef de dpartement a valid un emploi du temps.

Diagramme DACTIVITS: _____________________________________________________________

Diagramme dactivits

Consulter les emplois du TEMPS:Sommaire DIDENTIFICATION: ______________________________________________________________ SHAPE \* MERGEFORMAT


Prconditions:

Lutilisateur est authentifi.Scnario nominal:

Ce cas dutilisation commence lorsque lutilisateur demande consulter lemploi du temps.

Enchanement (a): Consulter un emploi du tempsLutilisateur slectionne une promotion.

Lutilisateur slectionne ensuite un semestre pour lanne en cours.

Il affiche ensuite lemploi du temps correspondant.

Ce cas dutilisation se termine lorsque lutilisateur se dconnecte.

Grer les fiches des tudiants:

Sommaire DIDENTIFICATION: ______________________________________________________________



Prconditions:

La Scolarit est authentifie.Scnario nominal:

Ce cas dutilisation commence lorsque le chef de dpartement/Scolarit demande au systme de crer un nouveau/modifier un dossier tudiant.

Enchanement (a): Crer un dossier tudiant en construction

Le chef de dpartement choisit un nom/prnom/date et lieu de naissance.

Il remplit le numro dinscription.

Il peut choisir ventuellement lanne dinscription.

Remplir les informations sur ltat civil.

Enchanement (b): Valider dossier tudiant en constructionLe chef de dpartement doit avoir rempli toutes les informations obligatoires.


Enchanement (c): Modifier un dossier tudiant en construction ou valid

Le chef de dpartement met jour ce dossier quand cela est ncessaire.

Si ltudiant est dj inscrit, spcifier la nouvelle anne dinscription.

Enchanement (d): Supprimer un dossier tudiantLe chef de dpartement peut supprimer un dossier tudiant sil nappartient aucune promotion au pralable.

Ce cas dutilisation se termine lorsque le chef de dpartement a valid un dossier tudiant.

Diagrammesdactivits: ______________________________________________________________

Diagramme dactivits

Maintenir les notes des TUDIANTS:Sommaire DIDENTIFICATION: ______________________________________________________________ SHAPE \* MERGEFORMAT

Descriptions des ENCHANEMENTS: _______________________________________________________

Prconditions:

1. Le responsable de la scolarit ou lenseignant est authentifi.

2. Au moins une promotion existe.

3. Au moins un dossier tudiant est cre.Scnario nominal:

Ce cas dutilisation commence lorsque le responsable de la scolarit affiche le relev de notes.

Enchanement (a): remplir le relev de notes

Le responsable de la scolarit ou lenseignant choisit une promotion.

Il choisit un tudiant et affiche son relev de notes.

Choisir un module et affecter une note celui-ci.Enchanement (b): Valider une fiche notes

Valider les donnes.

Enchanements alternatifs:Enchanement (c): modifier une fiche notes en construction/valide

La scolarit peut modifier une note dun module.

Exceptions:[Exception1: FicheNotesDejaExistante]: un message derreur saffiche lcran avisant lutilisateur que la fiche existe dj pour ce semestre.

[Exception2: ModuleDejaNot]: Si lacteur est lenseignant alors il ne peut plus modifier la note, sinon un message dinformation reste affich sur lcran demandant la confirmation du changement de la note et de la raison.

Ce cas dutilisation se termine lorsque le chef de dpartement a valid la fiche de notes de ltudiant.

Diagrammesdactivits: ______________________________________________________________

Diagramme dactivits

Remarque: cet algorithme, ne correspondant pas assez aux besoins du langage choisi et lIHM, va tre sensiblement chang.Consulter les NOTES:Sommaire DIDENTIFICATION: ______________________________________________________________ SHAPE \* MERGEFORMAT


Prconditions:

1. Lutilisateur est authentifi.

2. Au moins un dossier tudiant est cre.

Scnario nominal:

Ce cas dutilisation commence lorsque ltudiant se connecte son compte.

Enchanement (a): Slectionner un tudiantLe responsable choisit une promotion.

Il choisit un tudiant.

Enchanement (b): Afficher les notesIl slectionne un semestre afficher et affiche ses notes.Ce cas dutilisation se termine lorsque ltudiant sest dconnect.

Grer les PROFILS:Sommaire DIDENTIFICATION: ______________________________________________________________



Prconditions:

Aucunes.

Scnario nominal:

Ce cas dutilisation commence lorsque ladministrateur lance le logiciel.

Enchanement (a): Crer un profil en construction

Ladministrateur choisit un nom / mot de passe pour le compte.

Il choisit le type de ce compte.

Ce cas dutilisation se termine lorsque le chef de dpartement a valid un profil en construction.

1.10. Structuration des cas dutilisationsdans des packagesCette phase va permettre de structurer les cas dutilisations en groupes fortement cohrents, ceci afin de prparer le terrain pour la prochaine phase qui est le dcoupage en catgories.Dfinition: un package reprsente un espace de nommage qui peut contenir:

1. Des lments dun modle.

2. Des diagrammes qui reprsentent les lments du modle.

3. Dautres packages.

La structuration des cas dutilisations se fait par domaine dexpertise mtier c..d. les lments contenus dans un package doivent reprsenter un ensemble fortement cohrent et sont gnralement de mme nature et de mme niveau smantique.Cas dutilisationActeursPackage

Organiser un dpartementChef de dpartement

Gestion des dpartements

Grer les promotionsChef de dpartementGestion des promotions

Suivre les promotionsChef de dpartement

Maintenir les notesScolarit, Enseignant

Gestion des notes

Consulter les notesEtudiant

Grer les emplois du tempsScolaritGestion des emplois du temps

Consulter les emplois du tempsEtudiant, Enseignant

Grer les profilsAdministrateurGestion des profils

1.11. Identification des classes candidatesCette phase va prparer la modlisation oriente objet en aidant trouver les classes principales du futur modle statique danalyse.

La technique utilise pour identifier les classes candidates est la suivante:

Chercher les noms communs importants dans les descriptions textuelles des cas dutilisation. Vrifier les proprits objet de chaque concept (identit, proprits, comportement), puis dfinir ses responsabilits.Dfinition: une responsabilit est une sorte de contrat, ou dobligation, pour une classe. Elle se place un niveau dabstraction plus lev que les attributs ou les oprations. On formalise ensuite ces concepts mtier sous forme de classes et dassociations rassembles dans un diagramme statique pour chaque cas dutilisation. Ces diagrammes prliminaires sont appels diagramme des classes participantes, nont pas pour objectif dtre complet. Ils servent uniquement dmarrer la dcouverte des classes du modle danalyse.Exemple:

Responsabilits de la classe Domaine Diagramme des classes participantes du cas dutilisation Organiser les dpartements :

Les classes candidates sont tires de la description textuelle du cas dutilisation et des diagrammes dynamiques reprsentant celui-ci:

Domaine, Discipline, UE, Module.

Diagramme des classes participantes Organiser les dpartements

Diagramme des classes participantes du cas dutilisation Etablir les promotions :


Promotion, Domaine, Enseignant, Etudiant, Tronc_Commun, Specialite.

Diagramme des classes participantes Etablir les promotions

Diagramme des classes participantes du cas dutilisation Suivre les promotions :


Promotion, Semestre, Domaine, Enseignant, Etudiant.

Diagramme des classes participantes Suivre les promotions Diagramme des classes participantes du cas dutilisation Etablir les emplois du temps :

Les classes candidates sont tires de la description textuelle du cas dutilisation et des diagrammes dynamiques reprsentant celui-ci:Emploi du temps, Plage horaire, UE, Module, Enseignant.

Diagramme des classes participantes Etablir les emplois du temps

Diagramme des classes participantes du cas dutilisation Maintenir les notes tudiants:


Fiche notes, Note, Module, Etudiant.

Diagramme des classes participantes Maintenir les notes 3. ANALYSE

3.1. Dcoupage en catgoriesCette phase marque le dmarrage de lanalyse objet du systme raliser.

Elle utilise la notion de package pour dfinir des catgories de classes danalyse et dcouper le modle UML en blocs logiques les plus indpendants possibles.

Le dcoupage en catgories constitue la premire activit de ltape danalyse et elle va saffiner de manire itrative au cours du dveloppement du projet. Elle se situe sur la branche gauche du cycle en Y et succde la capture des besoins fonctionnels.

Pour passer lanalyse, il faut se baser sur les principes de lApproche Oriente Objet, notamment celle de lencapsulation. cet effet, il faut passer dune structuration fonctionnelle via les cas dutilisations, une structuration objet via les classes et les catgories.

Dfinition: une catgorie consiste en un regroupement logique de classes forte cohrence interne et faible couplage externe.

Le dcoupage en catgories de notre projet a donn le rsultat suivant:

Dcoupage en catgories

1.12. Dpendances entre catgories Classe Promotion:

Associations de la classe Promotion

Classe Fiche notes :

Associations de la classe Fiche Notes

Associations de la classe Fiche Notes avec navigabilit

Classe Emploi du temps:

Associations de la classe Emploi du temps

Associations de la classe Emploi du temps avec navigabilit

Aprs affinage des relations, nous avons le diagramme de Package suivant:

Associations de la classe Emploi du temps affines

1.13. Diagramme de packages danalyse

Ce diagramme va reprsenter les diffrentes dpendances entre les packages danalyse:

Diagramme de packages danalyse

Remarque: ce diagramme a t obtenu aprs plusieurs itrations.Remarque2: cette phase peut tre utilise par un chef de projet pour constituer les quipes. Chaque quipe pourra se concentrer sur le dveloppement dune seule catgorie/package. 1.14. Dveloppement du modle statiqueLe dveloppement du modle statique constitue la deuxime tape danalyse.Les diagrammes de classes tablis sommairement dans les diagrammes de classes participantes, puis rorganiss lors du dcoupage en catgories, vont tre, complts, et optimiss.Il sagit dune activit itrative, fortement couple avec la modlisation dynamique.

Catgorie Etudes: voici le diagramme de classe de la catgorie Etudes.

Diagramme de classe

Catgorie Promotions : voici le diagramme de classe de la catgorie Promotion et aussi Etudiants.

Diagramme de classe

Et voici les oprations/attributs de la classe Promotion.

Classe Promotion (attributs/oprations)

Et voici les oprations/attributs de la classe Semestre.

Classe Semestre (attributs/oprations)

Catgorie Relev de notes: voici le diagramme de classe de la catgorie Relev de notes.

Diagramme de classe

Classes ReleveNotes et Note (attributs/oprations)

Catgorie Enseignants: voici le diagramme de classe de la catgorie Enseignants.

Diagramme de classe

Et voici les oprations/attributs de la classe Enseignant.

Classe Enseignant (attributs/oprations)

Catgorie Etudiant:

Classe Etudiant (attributs/oprations)

Catgorie Emploi du temps: voici le diagramme de catgories de la classe Emploi du temps.

Diagramme de catgories

1.15. Dveloppement du modle dynamique

Le dveloppement du modle dynamique constitue la troisime activit de ltape danalyse. Il sagit dune activit itrative, fortement couple avec la modlisation statique.

Identification des scnarios :

Un cas dutilisation dcrit un ensemble de scnarios. Un scnario dcrit une excution particulire dun cas dutilisation du dbut la fin.il correspond une slection denchainements du cas dutilisation.On peut distinguer plusieurs types de scnarios:

Nominaux: ils ralisent les post conditions du cas dutilisation, dune faon naturelle et frquente; Alternatifs: ils remplissent les post conditions du cas dutilisation, mais en empruntant des voies dtournes ou rares; Aux limites: ils ralisent les post conditions du cas dutilisation, mais modifient le systme de telle sorte que la prochaine excution du cas dutilisation provoquera une erreur; Derreur: ne ralisent pas les post conditions du cas dutilisation.Il faut signaler que tous les scnarios possibles ne peuvent tre numrs et dcrits du fait quils en existent beaucoup. Cest pour cette raison que nous allons faire une description des scnarios les plus pertinents selon nous.SCNARIOS DE Organiser les licences:Parmi tous les scnarios possibles pour le cas dutilisation Organiser les licences (OL) nous avons choisi les suivants:

Enumration des scnarios: Scnarios nominaux:

OL_N1: crer un nouveau domaine. OL_N2: crer des UE pour un Tronc_Commun ou Specialite. Scnarios alternatifs:

OL_A1: modifier un domaine par ajout dune spcialit. OL_A2: modifier un domaine par ajout dune option. OL_A3: modifier un domaine par cration dUE et modules. OL_A4: modifier un domaine par suppression dune UE. Scnarios dexception:

OL_E1: non validation de la cration de domaine pour cause de nom existant dj. OL_E2: non validation de la modification du domaine par suppression dune UE pour cause dexistence dune promotion utilisant lUE.Description dtailledes scnarios:La description dtaille va permettre de, mettre en vidence les interactions entre les diffrents objets.

Cependant, du fait de lexistence de nombreux scnarios, nous allons dtailler seulement quelques uns dentre eux. Scnarios nominaux:

OL_N1: crer un nouveau domaine.Le chef de dpartement donne un nom/mot de passe didentification.

Il choisit un code/nom pour le domaine. Un tronc commun est cr.

Le chef de dpartement fixe la dure en semestres de celui-ci.

Il cre les spcialits du domaine, en choisissant pour chacune delle la dure.

Pour dcrire ce scnario, nous allons faire intervenir les instances suivantes:

Un acteur Chef de dpartement.

Un objet Domaine cre au cours du scnario.

Un objet Tronc_Commun cre au cours du scnario.

Un objet Specialite cre au cours du scnario.

Diagramme de squences du scnario crer un nouveau domaine OL_N2: crer des UE pour un Tronc_Commun ou Specialite.Le chef de dpartement donne un nom/mot de passe didentification.

Il slectionne un Domaine existant.

Il slectionne le tronc commun / une spcialit qui na pas encore des UE.

Il cre une UE en donnant un code/intitul/crdit.

Pour chaque UE cre, il cre plusieurs modules en spcifiant un code/intitul/crdit.



Un objet Domaine cre au cours du scnario.

Un objet Tronc_Commun/ Specialite cre au cours du scnario.

Un objet UE cre au cours du scnario.

Un objet Module cre au cours du scnario.

Diagramme de squences du scnario crer une UE

OL_E1: non validation de la cration de domaine pour cause de nom existant dj.

Diagramme de squences du scnario non validation de la cration dun domaine

SCNARIOS DE Etablir les promotions:Parmi tous les scnarios possibles pour le cas dutilisation Etablir les promotions (EP) nous avons choisi les suivants:


EP _N1: crer une nouvelle promotion. Scnarios alternatifs:

EP _A1: modifier une promotion par ajout dun enseignant. EP _A2: modifier une promotion par attribution dun module un enseignant non encore attribu. EP _A3: modifier une promotion par libration dun enseignant charg dun module. EP _A4: modifier une promotion par ajout dun tudiant. EP _A5: modifier une promotion par enlvement dun tudiant. Scnarios dexception:

EP _E1: EP _E2: Description dtailledes scnarios: Scnarios nominaux:

EP_1: crer une nouvelle promotion.Le chef de dpartement donne un nom/mot de passe didentification.

Il choisit un nom pour la promotion et la dure en semestres, il choisit quel domaine elle appartient, si cest un tronc commun ou une spcialit le cas chant il spcifie lanne du LMD.

Le chef de dpartement slectionne les enseignants et leur attribue un module enseigner.

Le chef de dpartement slectionne les tudiants faisant partie de la promotion.

Le chef de dpartement valide la promotion.



Une Promotion cre au cours du scnario.

Un multi-objet reprsentant les Modules de la spcialit ou du tronc_commun cre cours du scnario.

Un multi-objet reprsentant lensemble des instances de Enseignant qui vont tre affects la nouvelle promotion.

Un multi-objet reprsentant lensemble des instances de Etudiant qui vont tre rattachs la nouvelle promotion.

Diagramme de squences du scnario crer une nouvelle promotion

EP _A1: modifier une promotion par ajout dun enseignant.Le chef de dpartement donne un nom/mot de passe didentification.

Il slectionne une promotion.

Le chef de dpartement ajoute un enseignant la promotion.





Un objet Enseignant qui va tre affect la promotion.

Diagramme de squence du scnario modifier une promotion par ajout dun enseignant EP _A2: modifier une promotion par attribution dun module un enseignant non encore attribu.Le chef de dpartement donne un nom/mot de passe didentification.


Il slectionne un module.

Il attribue le module un enseignant.





Un objet Enseignant qui va est affect la promotion.

Un objet Module qui va tre affect un enseignant.

Diagramme de squence du scnario modifier une promotion par attribution dun module un enseignant non encore attribu EP _A3: modifier une promotion par libration dun enseignant charg dun module.Le chef de dpartement donne un nom/mot de passe didentification.


Il slectionne un enseignant faisant parti de la promotion.

Il dsaffecte lenseignant de son module.





Un objet Enseignant qui va tre affect la promotion.

Un objet Module qui va tre affect un Enseignant.

Diagramme de squence du scnario modifier une promotion par libration dun enseignant charg dun module EP _A4, EP_A5: modifier une promotion par ajout/enlvement dun tudiant.Le chef de dpartement donne un nom/mot de passe didentification.


Il slectionne un tudiant.

Il dsaffecte ltudiant de la promotion.





Un objet Etudiant qui va tre affect la promotion.

Diagramme de squence du scnario modifier une promotion ajout/enlvement dun tudiant SCNARIOS DE Etablir les emplois du temps: Scnarios nominaux:

EET_1: crer un nouvel emploi du temps.Le chef de dpartement donne un nom/mot de passe didentification.

Il choisit la promotion.

Il choisit le semestre.

Pour chaque plage horaire slectionne, il affecte un module.



Un emploi du temps cre au cours du scnario.

Une Promotion.

Un Module.

Une plage horaire cre au cours du scnario.

Diagramme de squence du scnario crer un nouvel emploi du temps SCNARIOS DE Grer les fiches tudiants:Parmi tous les scnarios possibles pour le cas dutilisation Grer les fiches tudiants (GF) nous avons choisi les suivants:

Scnarios nominaux:

GF_1: crer un nouveau dossier tudiant.La scolarit donne un nom/mot de passe didentification.

Il saisit les informations obligatoires (n inscription, nom, prnom).

Il saisit les informations facultatives.

Il saisit les informations sur ltat civil.


Un acteur Scolarit.

Un tudiant cre au cours du scnario.

SCNARIOS DE Maintenir les notes tudiants:Parmi tous les scnarios possibles pour le cas dutilisation Etablir les promotions (MN) nous avons choisi les suivants:


MN _N1: crer une fiche de notes. MN _N2: affecter les notes pour un tudiant. Scnarios alternatifs:

MN _A1: modifier une note pour un tudiant. MN _A2: modifier une promotion par attribution dun module un enseignant non encore attribu. MN _A3: modifier une promotion par libration dun enseignant charg dun module. Scnarios dexception:

MN _E1: MN _E2: Description dtailledes scnarios: Scnarios nominaux:

MN _N1: crer une fiche de notes.La scolarit donne un nom/mot de passe didentification.

Elle choisit une promotion.

Elle slectionne un tudiant.

Elle cre la fiche de notes.


Un acteur Scolarit.



UneFiche notes.

Diagramme de squence du scnario crer une fiche de notes MN _N2: affecter les notes pour un tudiant.La scolarit donne un nom/mot de passe didentification.

Elle choisit une promotion.

Elle slectionne un tudiant.

Pour chaque module, elle affecte une note (examen, TD, TP, Devoir).

Le calcul de la moyenne se fait automatiquement.


Un acteur Scolarit.


Un objet Promotion cre au cours du scnario.

Unobjet Note.

Diagramme de squence du scnario affecter les notes pour un tudiant Remarque: Du fait des contraintes du langage, ces diagrammes sont difficilement implmentables en ltat. Cependant, ils servent faire surgir les interactions possibles entres les diffrents objets. Construction des diagrammes dtats:On recourt au concept de machine tats finis, qui consiste sintresser au cycle de vie dun objet gnrique dune classe particulire au fil de ses interactions avec les autres classes, dans tous les cas possibles. Cette vue locale dun objet, dcrivant comment il ragit des vnements en fonction de son tat courant et passe dans un nouvel tat, est reprsente graphiquement sous forme dun diagramme dtats.Dfinition: un tat reprsente une situation durant la vie dun objet pendant laquelle:

Il satisfait une certaine condition;

Il excute une certaine activit;

Ou bien il attend un certain vnement.

Un objet passe par une succession dtats durant son existence. Un tat a une dure finie, variable selon la vie de lobjet, en particulier en fonction des vnements qui lui arrivent.

Diagramme dtats de la classe Promotion:

En attente: de la cration dune instance de Promotion sa validation, cet tat inclut toutes les oprations de rattachement un domaine, de rattachements denseignants, de rattachements dtudiants. Valide (cre): il reprsente une Promotion cre et valide. En cours: cet tat reprsente une Promotion en cours denseignement. Aucun tudiant ne peut tre ajout ce moment et aucun changement de Module ou dUE ne peut tre autoris. Cependant, un enseignant peut tre remplac. Termine: cet tat survient aprs la fin des dlibrations de la dernire session dexamen. Diagramme dtats de la classe PromotionDiagramme dtats de la classe Etudiant:

Nouvellement inscrit: cet tat reprsente un tudiant qui vient dtre inscrit luniversit.il se produit lorsque ltudiant est introduit la premire fois dans la base et que cest sa premire anne la facult. Rattach: cet tat reprsente un tudiant qui est attach une promotion. En cours dtudes: cet tat reprsente un tudiant qui est entrain dtudier. En cours de passage: cet tat survient aprs quun tudiant ait russi le passage au niveau suprieur. Au cours de cet tat, ltudiant fait le choix de la prochaine branche.

Recal: cet tat survient aprs quun tudiant ait chou le passage au niveau suprieur. Etudes termines: cet tat survient aprs quun tudiant ait termin ses tudes suprieures.

Diagramme dtats de la classe Etudiant4. CONCEPTIONLa conception prliminaire est ltape o seffectue la fusion des tudes fonctionnelles et techniques.

La conception dtaille qui vient juste aprs est une activit qui sinscrit dans lorganisation dfinie par la conception prliminaire. Le modle logique y est particulirement important dans la mesure o cest dans cette tape quon gnre le plus grand nombre dinformations. Il est ainsi possible de confier les catgories des personnes diffrentes, qui pourront travailler indpendamment les unes des autres.

Les concepteurs dans cette phase construisent les classes, les vue dIHM, les interfaces, les tables et les mthodes qui vont donner une image prte coder de la solution.1.16. Architecture de lapplication

La technologie Objet requiert une architecture. C'est cette architecture qui organise les interactions entre objets. On a l'habitude de regrouper ces objets en classes, ces classes en domaines, et ces domaines en couches.

Les couches permettent de prsenter l'architecture de l'application. Les quipes de ralisation s'attribuent alors des responsabilits sur le dveloppement de chaque couche. Aussi, si modliser est indispensable, construire une architecture couche est un critre de qualit dans le cadre d'un dveloppement Objet. Reste choisir le nombre de couches et dfinir leur contenu.

Architecture 3-Tiers: Pour avoir une architecture robuste, modulable et volutive, il nous faut utiliser le principe de couche. Nous allons donc sparer au maximum les diffrents types de traitement de lapplication (Dao, Mtier, Prsentation).Ceci correspond une architecture 3-Tiers:

Architecture 3-Tiers1.17. Les Design Patterns

De nombreuses mthodes existent pour simplifier la phase de conception des logiciels. Parmi les plus connues, considrons Merise et UML.Mais une autre mthode existe, plus proche de l'implmentation. Lors de la conception d'une application de nombreux problmes peuvent survenir. Le systme des Design Patterns, ou motifs de conception, reprsente un systme objet destin la rsolution de problmes techniques. (Eric Freeman, 2005)Un Design Pattern constitue un petit ensemble de classes apte offrir la solution la plus efficace un problme. La dfinition d'un motif de conception repose donc sur trois critres. Premirement, le problme rsoudre est classique et bien connu. Ensuite, l'ensemble des classes employes porte un nom unique (on parle par exemple du motif "Decorator"). Enfin, la solution que propose ce motif correspond la rsolution la plus optimale du problme. (Guy)Les Designs Patterns proviennent du travail de nombreux dveloppeurs qui se sont tour tour penchs sur les mmes problmes. En mettant en corrlation ces travaux on a pu dsigner les meilleures solutions dcouvertes sous le terme de motifs de conception. La connaissance de ces motifs permet au programmeur de trouver rapidement des implmentations pour ses programmes. La principale difficult rside dans l'identification du problme et dans sa mise en relation avec des motifs connus.

Pour nous, les Design Pattern nous ont aid trouver une solution lgante un problme conceptuel. En fait, ils vont nous aider coder les diffrents concepts qui se dgagent dans la phase de conception.

Donc on peut dire que les Design Pattern interviennent aussi dans la phase de codage.Le Design Pattern Etat:Dfinition: Le Design Pattern Etat est une faon de concevoir le diagramme dtats dune classe danalyse. La gestion des tats est dlgue de sorte qu chaque tat corresponde une classe du patron. Une classe gre ainsi les activits et les transitions attaches ltat quelle reprsente.

Le Design Pattern Etat

Remarque: les diagrammes qui vont suivre ont t cre avec loutil UML de NetBeans 5.5

Voici les diffrents diagrammes Etats que nous avons conus:La Classe Promotion:

Diagramme dtats de la classe Promotion

La classe Promotion dlgue la gestion de ses tats linterface EtatPromotion et ses diffrentes implmentations (EtatEnCreation, EtatValide, EtatEnCours, EtatTerminee)

La classe Promotion et ses diffrents tatsLa Classe Etudiant:

Design Pattern Etat de la classe Etudiant

La classe Etudiant dlgue la gestion de ses tats linterface EtatEtudiantLe Design Pattern Faade:Dfinition: Le patron de conception Faade a pour but de cacher une conception et une interface complexe difficile comprendre. La faade permet de simplifier cette complexit en fournissant une interface simple du sous-systme. Habituellement, la faade est ralise en rduisant les fonctionnalits de ce dernier mais en fournissant toutes les fonctions ncessaires la plupart des utilisateurs.

Un exemple du Design Pattern Faade

Lapplication de ce Design Pattern notre application se concrtise comme suit:

La couche Mtier accs la BDD grce au Pattern DAOLe Design Pattern Observateur:

Dfinition: Le Design Pattern Observateur consiste synchroniser des objets en minimisant les dpendances qui devraient stablir entre eux. Nous distinguons de ce fait le sujet et les observateurs.Le sujet centralise les donnes et il est unique.il comprend des oprations permettant aux observateurs daccder ses donnes.

Lobservateur restitue les donnes du sujet auquel il est abonn, et plusieurs peuvent se synchroniser sur le mme sujet.La dynamique dchange entre le sujet et ses observateurs abonns stablit partir dune notification indiquant une modification du sujet. Ce dernier en avise ses observateurs qui questionnent en retour le sujet pour obtenir les informations ncessaires leur mise jour.

Ce Design Pattern est intgr Java au travers des classes Observable et Observer du package Java.util. (Florian GRISONI)Remarque: Ce Design Pattern a t intensment utilis dans notre logiciel pour sa facilit de mise en uvre, et les diffrentes possibilits quil nous offre afin de mettre en pratique un autre Design Pattern qui est le MVC.

Le Design Pattern MVC: L'architecture Modle Vue Contrleur (MVC) est une mthode de conception pour le dveloppement d'applications logicielles qui spare le modle de donnes, l'interface utilisateur et la logique de contrle. Ce modle d'architecture impose la sparation entre les donnes, les traitements et la prsentation, ce qui donne trois parties fondamentales dans l'application finale: le modle, la vue et le contrleur:

Le Modle: reprsente le comportement de l'application: traitements des donnes, interactions avec la base de donnes, etc. Il dcrit les donnes manipules par l'application et dfinit les mthodes d'accs. la Vue: correspond l'interface avec laquelle l'utilisateur interagit. Les rsultats renvoys par le modle sont dnus de toute prsentation mais sont prsents par les vues. Plusieurs vues peuvent afficher les informations d'un mme modle. Elle peut tre conue en html, ou tout autre langage de prsentation. La vue n'effectue aucun traitement, elle se contente d'afficher les rsultats des traitements effectus par le modle, et de permettre l'utilisateur d'interagir avec elles.

le Contrleur: prend en charge la gestion des vnements de synchronisation pour mettre jour la vue ou le modle. Il n'effectue aucun traitement, ne modifie aucune donne, il analyse la requte du client et se contente d'appeler le modle adquat et de renvoyer la vue correspondant la demande.En rsum, lorsqu'un client envoie une requte l'application, celle-ci est analyse par le contrleur, qui demande au modle appropri d'effectuer les traitements, puis renvoie la vue adapte au navigateur, si le modle ne l'a pas dj fait.Un avantage apport par ce modle est la clart de l'architecture qu'il impose. Cela simplifie la tche du dveloppeur qui tenterait d'effectuer une maintenance ou une amlioration sur le projet. En effet, la modification des traitements ne change en rien la vue. Par exemple on peut passer d'une base de donnes de type SQL XML en changeant simplement les traitements d'interaction avec la base, et les vues ne s'en trouvent pas affectes. (Wikipedia)Comme exemple, Swing la bibliothque graphique de Java pour la cration dinterfaces graphiques, est base sur le modle MVC. (Cornell)5. CODAGELe choix du langage sest port vers Java, qui tant Orient Objet la base, nous facilitera la transformation de notre modle objet vers le code.La programmation peut se faire pour des exemples simples avec le compilateur javac, mais pour avoir plus de confort il est prfrable d'utiliser un environnement de dveloppement intgr ou IDE.

Notre choix sest port vers lEDI NetBeans, qui nous fournit le confort et la simplicit ncessaires un dveloppement propre et rapide.

1.18. La gnration de code avec NetBeans5.5:Grace au plugin UML intgr NetBeans, nous avons pu crer les diffrents diagrammes UML dfinis lors de la phase de conception. Mais aussi, nous allons lutiliser pour la gnration du code partir des diagrammes de classes.

Nous bnficierons dans ce cas dun gain de temps non ngligeable, du fait quil peut gnrer aussi les diffrents packages avec leurs classes respectives.1.19. Lapplication JStudentStructure gnralede lapplication :

Lapplication est dcoupe en 3 couches distinctes, Prsentation, Mtier et DAO.

La couche Prsentation est charge de tout ce qui est affichage.

La couche Mtier est la logique mtier de lapplication, elle est le cur et cest elle qui dfinit toutes les rgles rgissantes au fonctionnement de lapplication.

La couche DAO est lintermdiaire entre les autres couches et la Base de donnes.

Figure reprsentant les 3 couches de lapplicationLa couche Mtier:

Voici quelques figures reprsentants un chantillon du code source de cette couche:

La classe Promotion ( gauche les Attributs et les Mthodes)

La classe Domaine ( gauche les Attributs et les Mthodes)

La classe Etudiant ( gauche les Attributs et les Mthodes)

La couche Prsentation:

Voici quelques figures reprsentants linterface du logiciel:

Cration dun nouvel tudiant Cration dune nouvelle promotion

Fiche de consultation dune promotion

Organisation en semestres dune promotionLe stockage de donnes :

La technique choisie pour persister les donnes est: la srialisation.

Une technique plus aboutie aurait t un meilleur choix comme: le mapping Objet/Relationnel avec un outil comme Hibernate. Mais lapprentissage de cet outil demande un temps supplmentaire.

Mais la solution de la srialisation rponds largement nos besoins pour ce projet, cest pour a que nous avons jug pertinent de la garder.Bilan de la mthodeDu fait de notre manque dexprience dans le domaine et, du cadre limit (humain et matriel) dans lequel nous avons men notre projet, on ne va pas tirer de conclusion dfinitive sur la mthode. Mais en ce qui concerne la prise en compte dune volution possible de lapplication, on va alors donner un cas concret de ce que pourrait tre un ajout dun nouveau besoin fonctionnel.

Etude du cas: Gestion des SALLES

Nous avons signal au dbut que la gestion des salles a t ignore pour manque de temps et pour rduire la complexit de notre projet.Nous allons donc montrer comment on pourrait ajouter cette fonctionnalit notre projet de faon concrte.

Identification du besoin:

On suppose que la gestion de salles se trouve finalement, tre un besoin rel pour les utilisateurs de notre application.

Nous allons dabord identifier les acteurs du systme devant interagir avec le systme travers cette nouvelle fonctionnalit:

Il sagit de la scolarit qui devra pour chaque promotion, chercher une salle libre afin que les cours puissent y tre enseigns.

Cas dutilisation Grer les salles

On peut la suite de cration dune promotion, lui affecter une salle. De ce fait, le cas dutilisation grer les salles pourra tendre le cas dutilisation tablir les promotions.

La gestion des salles pourra aussi tre comprise comme une spcification de chaque dpartement. Ce qui nous amne lintroduire au package Gestion des dpartements.Description dtaille du cas dutilisation:

Ce cas dutilisation commence lorsque la scolarit demande au systme de crer une nouvelle salle.

Enchanement (a): Crer une salle en construction

La scolarit choisit le bloc auquel la salle appartient.

Elle choisit un numro.

Elle spcifie ltage, le nombre de places disponibles

Dautres enchainements

Enchanement alternatifs: Crer un bloc en constructionIdentification des classes candidates:

A la suite de cette description dtaille, nous pouvons en dduire dj deux classes: Bloc, Salle.Concrtement dans le code:

Normalement, il aurait fallu faire une tude plus approfondie, et continuer avec le modle statique et dynamique, afin de dgager les liens possibles entre ces deux classes et les autres classes des autres packages.

Nous pouvons cependant dire que ce nouveau besoin fonctionnel, se traduira par un ajout de ces deux classes au package Etudes. Et il devrait y avoir un lien entre la classe Salle et Promotion. Dans le code, a se traduira par lajout dun attribut de Type Salle.

Ceci ne devrait pas affecter le codage en gnral, du fait que les responsabilits des diffrentes classes et packages ont t bien spares.Conclusion

Nous pouvons constater que lajout de nouvelles fonctionnalits peut tre simplifi, pour peu quon respecte bien les tapes dfinies par 2TUP. a demande de faire une itration complte ou partielle selon le besoin, du cycle Y, et ne pas succomber la tentation de toucher rapidement au code.Conclusion gnraleNous avons tent travers ce projet de dmontrer limportance de lapplication dune mthode de dveloppement.Nous pensons aussi que 2TUP pourra tre utilise dans des projets de moyenne grande envergure.

A titre personnel, le bnfice quon en a tir est lapprentissage 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 sappelle: UML 2 En Action.

Ce projet nous a permis denrichir nos connaissances dans des domaines trs varis comme: LOrient Objet, UML, 2TUP, le langage JAVA, les Design Patterns, SwingEn termes dvolution, lapplication pourra par la suite tre adapte une utilisation luniversit. Par exemple, une base de donnes pourra tre utilise soit par le biais dun pont JDBC, ou par le biais dune solution de Mapping Objet/Relationnel comme Hibernate. Aussi, un dploiement sur un rseau pourra tre fait grce au framework J2EE.

Nous esprons que la lecture de ce mmoire a t agrable et claire.BibliographieChromatic. (2005). Extreme programming. O'Reilly.

Cornell, G. Au Coeur de Java. Campus Press.

Eric Freeman, E. F.-C. (2005). Design Patterns Tte la premire. O'Reilly.

Florian GRISONI, N. G. (s.d.). Rcupr sur http://www.cyber06.com/article/mvc.php

Guy, R. (s.d.). Rcupr sur http://www.progx.org

Meyer, B. (2000). Conception et Programmation orientes objet. Eyrolles.

Pitman, N. (2006). UML 2 en concentr. O'Reilly.

Rocques, P., & Valle, 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.). Rcupr sur Wikipedia: http://fr.wikipedia.org/

Annexe:Lapproche Oriente OBJETNotion de classe

Tout dabord, introduisons la notion de classe. Une classe est un type de donnes abstrait, caractris.Par des proprits (attributs et mthodes) communes toute une famille dobjets et permettant de crer (instancier) des objets possdant ces proprits. Les autres concepts importants quil nous faut maintenant introduire sont lencapsulation, lhritage et lagrgation.

Encapsulation

Lencapsulation consiste masquer les dtails dimplmentation dun objet, en dfinissant une interface. Linterface est la vue externe dun objet, elle dfinit les services accessibles (offerts) aux utilisateurs de lobjet.

Lencapsulation facilite lvolution dune application car elle stabilise lutilisation des objets: on peut modifier limplmentation des attributs dun objet sans modifier son interface, et donc la faon dont Lobjet est utilis.

Lencapsulation garantit lintgrit des donnes, car elle permet dinterdire, ou de restreindre, laccs direct aux attributs des objets.

Hritage, Spcialisation, Gnralisation et polymorphisme

Lhritage est un mcanisme de transmission des proprits dune classe (ses attributs et mthodes) vers une sous-classe. Une classe peut tre spcialise en dautres classes, afin d y ajouter des caractristiques spcifiques ou den adapter certaines. Plusieurs classes peuvent tre gnralises en une classe qui les factorise, afin de regrouper les caractristiques communes dun ensemble de classes.

Ainsi, la spcialisation et la gnralisation permettent de construire des hirarchies de classes. Lhritage peut tre simple ou multiple. Lhritage vite la duplication et encourage la rutilisation.

Le polymorphisme reprsente la facult dune mthode pouvoir sappliquer des objets de classes diffrentes. Le polymorphisme augmente la gnricit, et donc la qualit, du code.

LAgrgation

Il sagit dune relation entre deux classes, spcifiant que les objets dune classe sont des composants de lautre classe. Une relation dagrgation permet donc de dfinir des objets composs dautres objets.

Lagrgation permet donc dassembler des objets de base, afin de construire des objets plus complexes. (Meyer, 2000)UMLIntroductionLa description de la programmation par objets a fait ressortir ltendue du travail conceptuel ncessaire: dfinition des classes, de leurs relations, des attributs et mthodes, des interfaces etc.Pour programmer une application, il ne convient pas de se lancer tte baisse dans lcriture du code : Il faut dabord organiser ses ides, les documenter, puis organiser la ralisation en dfinissant les modules et tapes de la ralisation. Cest cette dmarche antrieure lcriture que lon appelle modlisation; son produit est un modle.

Les spcifications fournies par la matrise douvrage en programmation imprative taient souvent floues: les articulations conceptuelles (structures de donnes, algorithmes de traitement) sexprimant dans le vocabulaire de linformatique, le modle devait souvent tre labor par celle-ci. Lapproche objet permet en principe la matrise douvrage des exprimer de faon prcise selon un vocabulaire qui, tout en transcrivant les besoins du mtier, pourra tre immdiatement compris par les informaticiens. En principe seulement, car la modlisation demande aux matrises douvrage une comptence, un professionnalisme qui ne sont pas aujourdhui rpandus.UML en uvreUML nest pas une mthode (i.e. une description normative des tapes de la modlisation): ses auteurs ont en effet estim quil ntait pas opportun de dfinir une mthode en raison de la diversit des cas particuliers. Ils ont prfr se borner dfinir un langage graphique qui permet de reprsenter, de communiquer les divers aspects dun systme dinformation (aux graphiques sont bien sr associs des textes qui expliquent leur contenu). UML est donc un mta-langage car il fournit les lments permettant de construire le modle qui, lui, sera le langage du projet.

Il est impossible de donner une reprsentation graphique complte dun logiciel, ou de tout autre systme complexe, de mme quil est impossible de reprsenter entirement une statue ( trois dimensions) par des photographies ( deux dimensions). Mais il est possible de donner sur un tel systme des vues partielles, analogues chacune une photographie dune statue, et dont la juxtaposition donnera une ide utilisable en pratique sans risque derreur grave.Les diagrammes dUMLUML 2.0 comporte ainsi treize types de diagrammes reprsentant autant de vues distinctes pour reprsenter des concepts particuliers du systme dinformation. Ils se rpartissent en deux grands groupes:

Diagrammes structurels ou diagrammes statiques (UML Structure)

diagramme de classes (Class diagram)

diagramme dobjets (Object diagram)

diagramme de composants (Component diagram)

diagramme de dploiement (Deployment diagram)

diagramme de paquetages (Package diagram)

diagramme de structures composites (Composite structure diagram)

Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior)

diagramme de cas dutilisation (Use case diagram)

diagramme dactivits (Activity diagram)

diagramme dtats-transitions (State machine diagram)

diagrammes dinteraction(Interactiondiagram)

diagramme de squence (Sequence diagram)

diagramme de communication (Communication diagram)

diagramme global dinteraction (Interaction overview diagram)

diagramme de temps (Timing diagram)

Ces diagrammes, dune utilit variable selon les cas, ne sont pas ncessairement tous produits loccasion dune modlisation. Les plus utiles pour la matrise douvrage sont les diagrammes dactivits, de cas dutilisation, de classes, dobjets, de squence et dtats-transitions. Les diagrammes de composants, de dploiement et de communication sont surtout utiles pour la matrise duvre qui ils permettent de formaliser les contraintes de la ralisation et la solution technique.Le langage Java

Java est la fois un langage de programmation et un environnement dexcution. Le langage Java a la particularit principale d'tre portable sur plusieurs systmes dexploitation. C'est la plateforme qui garantit la portabilit des applications dveloppes en Java. (Cornell)Lors de la cration du langage Java, il avait t dcid que ce langage devait rpondre 5 objectifs:

1. utiliser une mthode oriente objet,

2. permettre un mme programme d'tre excut sur plusieurs systmes d'exploitation diffrents,

3. pouvoir utiliser de manire native les rseaux informatiques,

4. pouvoir excuter du code distant de manire sre,

5. tre facile utiliser et possder les points forts des langages de programmation orients objet comme le C+

Documents

37222279-2TUP