Table de matières
Table de matières
Les méthodes utilisées dans les années 1980 pour organiser la programmation impérative (notamment Merise) étaient fondées sur la modélisation séparée des données et des traitements. Lorsque la programmation par objets prend de l’importance au début des années 1990, la nécessité d’une méthode qui lui soit adaptée devient évidente. Plus de cinquante méthodes apparaissent entre 1990 et 1995 (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE, etc.) mais aucune ne parvient à s’imposer. En 1994, le consensus se fait autour de trois méthodes :
– OMT de James Rumbaugh (General Electric) fournit une représentation graphique des aspects statique, dynamique et fonctionnel d’un système ;
– OOD de Grady Booch, définie pour le Department of Defense, introduit le concept de paquetage (package) ;
– OOSE d’Ivar Jacobson (Ericsson) fonde l’analyse sur la description des besoins des utilisateurs (cas d’utilisation, ou use cases).
Chaque méthode avait ses avantages et ses partisans. Le nombre de méthodes en compétition s’était réduit, mais le risque d’un éclatement subsistait : la profession pouvait se diviser entre ces trois méthodes, créant autant de continents intellectuels qui auraient du mal à communiquer. Événement considérable et presque miraculeux, les trois gourous qui régnaient chacun sur l’une des trois méthodes se mirent d’accord pour définir une méthode commune qui fédérerait leurs apports respectifs (on les surnomme depuis « the Amigos »). UML (Unified Modeling Language) est né de cet effort de convergence. L’adjectif unified est là pour marquer qu’UML unifie, et donc remplace. En fait, et comme son nom l’indique, UML n’a pas l’ambition d’être exactement une méthode : c’est un langage.
L’unification a progressé par étapes. En 1995, Booch et Rumbaugh (et quelques autres) se sont mis d’accord pour construire une méthode unifiée, Unified Method 0.8 ; en 1996, Jacobson les a rejoints pour produire UML 0.9 (notez le remplacement du mot méthode par le mot langage, plus modeste). Les acteurs les plus importants dans le monde du logiciel s’associent alors à l’effort (IBM, Microsoft, Oracle, DEC,
HP, Rational, Unisys etc.) Et UML 1.0 est soumis à l’OMG5. L’OMG (Object Management Group) adopte en novembre 1997 UML 1.1 comme langage de modélisation des systèmes d’information à objets. La version d’UML en cours à la fin 2006 est UML 2.0 et les travaux d’amélioration se poursuivent. UML est donc non seulement un outil intéressant mais une norme qui s’impose en technologie à objets et à laquelle se sont rangés tous les grands acteurs du domaine, acteurs qui ont d’ailleurs contribué à son élaboration.
De par les multiples études effectuées sur le langage UML, il nous a été aisé de présenter dans les quelques lignes son apport dans le présent projet. Nous serons, sans doute, malheureux de passer à la modélisation sans pour autant avoir une idée sur les pourquoi des diagrammes à utiliser.
UML présente 3 grandes catégories de diagrammes : fonctionnel, statique ainsi que dynamique. Les diagrammes fonctionnels dont le diagramme de cas d’utilisation se basant sur les limites du système, statiques dont le diagramme de classes et dynamiques dont le diagramme d’activités et de séquence dans le but de représenter sur schéma la manipulation du système ainsi que le diagramme de séquence.
Il est important de démarrer l’analyse par le positionnement le plus précis possible du système à étudier. Ainsi, il est opportun de recueillir les besoins des utilisateurs et de situer le contexte du système. Dans cette partie du document, il s’agira de décrire les besoins et les acteurs qui vont interagir avec notre système. Ces besoins vont des fonctionnalités jusqu’aux aspects techniques du système. Après avoir identifié les acteurs qui interagiront avec le système, nous développerons un premier modèle UML de niveau contexte, pour pouvoir établir précisément les frontières fonctionnelles du système.
S’inspirant des possibilités qu’offre le WebMapping et la Géolocalisation, ainsi que les différents défauts offert par les systèmes actuels, un certain nombre de besoins se sont fait sentir et dont la description est présenté dans les lignes qui suivent.
Notre système doit pouvoir offrir les différentes fonctions ou services que sont :
La mise en place du site doit tenir compte d’un certain nombre de besoins techniques dont :
2.3 IDENTIFICATION DES ACTEURS
Un acteur (Actors) représente l’abstraction d’un rôle joué par des entités externes (utilisateur, dispositif matériel ou autre système) qui interagissent directement avec le système étudié. Ils ne font pas partie du système à étudier. Ce sont toute personne, système ou machine pouvant interagir avec le système. Un acteur peut par exemple donner et/ou recevoir des informations.
C’est ainsi que nous avons identifié les acteurs, par rapport aux différents groupes, suivants qui interagissent avec le système :
Ces différents acteurs sont présentés sur le diagramme de contexte statique ci-dessous. Ce diagramme montre le nombre d’instances d’acteurs reliés au système à un moment donné. Dans notre cas, nous avons :
|
Acteurs |
Cas d’utilisation |
Scenarios |
|
Agent / administrateur |
S’inscrire |
S1 : S’inscrire |
|
Authentification |
S2: login et mot de passe |
|
|
Créer agent |
S3: Créer |
|
|
Affecter les directions |
S4: Affecter |
|
|
Mise à jour |
S5:MAJ |
|
|
Voir Affichage |
S6: Affichage |
|
|
Etudiant |
S’inscrire |
S7 : S’inscrire |
|
Authentification |
S8: login et mot de passe |
|
|
Déposé |
S9: Déposé |
|
|
Voir affichage |
S10: Voir affichage |
|
|
Directeur |
S’inscrire |
S11 : S’inscrire |
|
Authentification |
S12: login et mot de passe |
|
|
Voir affichage pour direction |
S10: Voir affichage |
Tableau 1: Scenario des cas d’utilisation
Ce qui donne le diagramme de contexte statique suivant :
Diagramme de cas d’utilisation général
Figure 1: diagrammes cas d’utilisation général :
Description textuelle de cas d’utilisation
Afin de décrire les interactions entre les cas d’utilisation, nous présentons ces derniers de façon textuelle.
Il s’agit donc d’associer à chaque cas d’utilisation un nom, un objectif, les acteurs qui y participent, les pré-conditions et des scénarii. Cependant ; il existe trois types de scénarii : les scénarii nominaux ; les scénarii d’exceptions et les scénarii alternatifs. Dans notre description textuelle, nous présentons seulement les scénarii nominaux et alternatifs
Nous nous restreindrons à la description des cas d’utilisation suivants : authentification et inscription (application Web).
|
CU1 Inscription |
||
|
||
|
Acteurs: Agent |
||
|
Post-Condition: le cas démarre après le point 02 de l’enchainement nominal, |
||
|
l’utilisateur s’inscrit au site |
||
|
||
|
Tableau 2: description de cas d’utilisation inscription
Ce cas d’utilisation commence lorsque l’utilisateur demande au système de faire une inscription. Une fois le formulaire est affiché, il remplit les champs de saisies puis enregistre ses données. Le système s’assure d’abord que les champs obligatoires n’ont pas la valeur NULL ensuite il enregistre les informations entrées dans la base de données (voir figure N° 1).
Figure 2 : Diagramme de séquence « Inscription »
|
CU2: Authentification |
|
Résumé: Ce CU permet à un utilisateur de se connecté au système ; et lui présenter l’interface, les fonctionnalités relatives à son profil. |
|
Acteurs: Agent |
|
Pré conditions : Introduire login et mot de passe |
|
Post-Condition: le cas démarre après le point 02 de l’enchainement nominal, l’utilisateur s’authentifie |
|
Scénario nominal |
|
DESCRIPTION DU SCENARIO NOMINAL « DEBUT» 01 : Le système invite l’acteur à entrer son login et son mot de passe. 02: L’acteur saisit le login et le mot de passe et choisit son profil. 03: Le système vérifie les paramètres. 04: Le système ouvre l’espace de travail correspondant au profil. « FIN» |
|
Scenario alternative |
|
DESCRIPTION DU SCENARIO ALTERNATI F Le login ou le mot de passe est incorrect: ce scénario commence au point 03 du scénario nominal. 01 : Le système informe l’acteur que les données saisies sont erronées et le scénario reprend au point 01 du scénario nominal. |
Tableau 3: description de cas d’utilisation Authentification
Après le démarrage de l’application, l’utilisateur saisi son pseudo et son mot de passe. Une fois qu’il valide la saisie des données, le système s’assure d’abord que les informations entrées n’ont pas la valeur NULL donc les champs vides ne sont pas autorisés puis il vérifie ces données auprès de la base de données. Cette étape s’achève soit par l’ouverture de l’espace personnel associé à l’utilisateur, soit par l’affichage de message d’erreur.
Dans ce diagramme « loop » indique qu’il aura une répétition d’affichage de l’interface d’authentification jusqu’à la validation du pseudo et mot de passe.
Figure 3 : Diagramme de séquence
|
CU3: Ajout |
|
Résumé: Ce CU permet à un utilisateur de se connectant au système ; et lui présenter l’interface, les fonctionnalités relatives à son profil. |
|
Acteurs: Agent |
|
Pré conditions : ouverture de formulaire d’ajout |
|
Post-Condition: le cas démarre après le point 02 de l’enchainement nominal, l’utilisateur s’authentifie |
|
Scénario nominal |
|
DESCRIPTION DU SCENARIO NOMINAL « DEBUT» 01 : Le système invite l’acteur à ajouter un étudiant ou un dépôt de travail. 02: L’acteur saisit les informations d’enregistrement. 03: Le système vérifie la validité des données. 04: Le système enregistre les données. « FIN» |
|
Scenario alternative |
|
DESCRIPTION DU SCENARIO ALTERNATI F Le login ou le mot de passe est incorrect: ce scénario commence au point 03 du scénario nominal. 01 : Le système informe l’acteur que les données saisies sont erronées et le scénario reprend au point 01 du scénario nominal. |
Tableau 4: description de cas d’utilisation Ajout
Après le démarrage de l’application, l’utilisateur saisi son pseudo et son mot de passe. Une fois qu’il valide la saisie des données, le système lui ouvre son espace. Ou il trouve le bouton d’enregistrement et ajout des données ; L’étape d’ajout s’achève soit par un message de confirmation d’enregistrement, soit par l’affichage de message d’erreur.
Figure 4 : Diagramme de séquence ajout
L’objectif du diagramme de séquence est de représenter les interactions entre objets en indiquant la chronologie des échanges. Cette représentation peut se réaliser par cas d’utilisation en considérant les différents scénarios associés.
Comme il est dit par Xavier Blanc et Isabelle Mounier ([1]) la vue structurelle du modèle UML est la vue la plus utilisée pour spécifier une application. Son objectif étant de modéliser la structure des différentes classes d’une application orientée objet ainsi que leurs relations. Rappelons que le diagramme de classes est la représentation graphique de cette vue. C’est par ces notes que notre diagramme de classes se présente de la manière suivante :
Pour ce qui est des tables relevées ou les entités de notre système, nous en avons eu :
Le tableau ci-dessous représente la liste des attributs composants toutes les classes formants notre système ainsi que leur description, leur taille et leur type.
|
No |
Attribut |
Description |
Type |
Taille |
|
I. |
Agent |
11 attributs |
||
|
1 |
id_agent |
Identifiant de l’agent |
Int |
(11) |
|
2 |
matricu |
Matricule de l’agent |
Varchar |
(25) |
|
3 |
nom |
Nom de l’agent |
Varchar |
(25) |
|
4 |
postnom |
Post-nom de l’agent |
Varchar |
(25) |
|
5 |
prenom |
Prénom de l’agent |
Varchar |
(25) |
|
6 |
sex |
Sexe de l’agent |
Varchar |
(5) |
|
7 |
et_civ |
Etat-civile de l’agent |
Varchar |
(25) |
|
8 |
dat_naiss |
Date de naissance de l’agent |
Date |
(5) |
|
9 |
grade |
Grage de l’agent |
Varchar |
(25) |
|
10 |
login |
Login de l’agent |
Varchar |
(100) |
|
11 |
pass |
Mot de passe de l’agent |
Varchar |
(100) |
|
II. |
dep_trav |
|||
|
12 |
id_ dep |
Identifiant du dépôt de travail |
int(11) |
(11) |
|
13 |
id_etudiant |
Identifiant de l’étudiant |
int(11) |
(11) |
|
14 |
ann_edit |
Année d’édition du travail |
Year |
(4) |
|
15 |
date_dep |
Date du dépôt du travail |
Date |
(4) |
|
16 |
type_tr |
Type du travail |
Varchar |
(25) |
|
15 |
titre |
Titre du travail |
Varchar |
(100) |
|
17 |
directeur |
Directeur du travail |
Varchar |
(25) |
|
18 |
co_directeur |
Co-directeur du travail |
Varchar |
(25) |
|
19 |
fichier_choisi |
Choisir le fichier à importer soit le mémoire |
Text |
|
|
III |
Directeur |
|||
|
20 |
id_dircteur |
Identifiant du directeur |
Int |
(11) |
|
21 |
nom |
Nom du directeur |
Varchar |
(25) |
|
22 |
postnom |
Post-nom du directeur |
Varchar |
(25) |
|
23 |
prenom |
Prénom du directeur |
Varchar |
(25) |
|
24 |
sexe |
Sexe du directeur |
Varchar |
(5) |
|
25 |
grade |
Grade du directeur |
Varchar |
(25) |
|
26 |
niv_etud |
Niveau d’étude du directeur |
Varchar |
(25) |
|
27 |
login |
Login du directeur |
Varchar |
(100) |
|
28 |
pass |
Mot de passe du directeur |
Varchar |
(100) |
|
IV |
direction |
|||
|
29 |
id_direction |
Identifiant de la direction |
Int |
(11) |
|
30 |
id_etud |
Identifiant |
Int |
(11) |
|
31 |
id_trav |
Identifiant |
Int |
(11) |
|
32 |
id_codir |
Identifiant du co-directeur |
Int |
(11) |
|
33 |
id_dir |
Identifiant du directeur |
Int |
(11) |
|
34 |
obs |
Observation avis du département à propos du sujet d’un étudiant |
Text |
|
|
V. |
etudiant |
|||
|
21 |
id_ etudiant |
Identifiant de l’etudiant |
Int |
(11) |
|
22 |
matricule |
Matricule de l’étudiant |
Varchar |
(25) |
|
23 |
Nom |
Nom de l’étudiant |
Varchar |
(25) |
|
24 |
postnom |
Post-nom de l’étudiant de l’étudiant |
Varchar |
(25) |
|
25 |
prenom |
Prénom de l’étudiant de l’étudiant |
Varchar |
(25) |
|
26 |
dat_nais |
Date de naissance de l’étudiant |
Date |
|
|
27 |
Sex |
Sexe de l’étudiant |
Varchar |
(1) |
|
28 |
Grade |
Grade de l’étudiant |
Varchar |
(25) |
|
29 |
departement |
Département de l’étudiant |
varchar(25) |
25 |
|
30 |
promotion |
Promotion de l’étudiant |
varchar(25) |
25 |
|
VI. |
Sujet |
|||
|
31 |
id_sujet |
Identifiant du sujet |
Int |
(11) |
|
32 |
id_etudiant |
Identifiant du sujet |
Int |
(11) |
|
33 |
ann_acd |
Année académique de l’étudiant |
Varchar |
(15) |
|
34 |
date |
Date limite du sujet |
Date |
|
|
35 |
sujet |
Sujet de recherche |
Text |
|
|
36 |
id_dir |
Identifiant du directeur du travail |
Int |
(11) |
|
37 |
id_codir |
Identifiant du co-directeur du travail |
Int |
(11) |
|
38 |
id_sujet |
Identifiant du sujet |
Int |
(11) |
Tableau 5: Dictionnaire des données
La modalisation objet est utilisée dans le langage UML pour définir des objets-métiers et l’architecture de l’application. Ces objets sont créés en tant qu’instance de classe et s’interagissent dynamiquement pour offrir le comportement décrit par les cas d’utilisation.
La modélisation objet définit le comportement requis par les différentes classes pour assurer la bonne mise en place des cas d’utilisation et des règles de gestion.
Les objets constituent la base de l’architecture des applications, ils peuvent être réutilisés à travers des domaines d’application ou encore être identifiés et dérivés directement des cas d’utilisation ou des domaines d’application. Une classe est composée :
Représentation des associations entre les classes
Les associations sont des relations entre classes. Elles représentent un lieu durable ou ponctuel entre deux objets, une appartenance, ou une collaboration. Elles sont représentées par une ligne entre les classes.
Le modèle de données d’UML comprend trois associations génériques principales :
Généralisation, association, dépendance à partir de ces trois associations de base, nous représentons ainsi les différents types d’association qui décrivent les dépendances entre les classes déjà citées
Association simple : les associations simples sont des liaisons logiques entre entités.
Les cardinalités : précisent combien d’objets de classe considérée peuvent être liés à un objet de l’autre classe.
Le tableau suivant illustre une représentation des cardinalités :
|
Désignation |
||
|
1 |
Un et un seul |
||
|
0…1 |
Zéro ou un |
||
|
N |
Entier naturel |
||
|
m…n |
De m à n (deux entiers naturels) |
||
|
0…* |
De 0 à plusieurs |
||
|
1…* |
De 1 à plusieurs |
Tableau 6: Présentation des cardinalité
Le tableau suivant illustre les associations simples en indiquant leurs désignations, les classes participantes et leurs cardinalités
|
N° |
Désignation |
Classes participantes |
Cardinalités |
|
1 |
déposer |
étudiant dep_trv sujet |
1, n 1..* 1..* |
|
2 |
affecter |
Agent Direction |
1 1..* |
|
4 |
diriger |
directeur etudiant |
1 0..* |
|
5 |
Etre affecter |
Etudiant Direction |
1 1..* |
Une règle de gestion décrit une condition d’exécutions d’une action.
Ci-dessous nous présentons les différentes règles de gestion de notre application.
RG1: Un utilisateur peut être un agent.
RG2: Un agent peut recevoir un ou plusieurs travaux scientifiques.
RG3: les étudiants peuvent déposer leurs sujets et leurs travaux de fin cycle et ou mémoires.
Présentation du Diagramme de classes
[1] Xavier Blac, Isabelle Mounier, UML 2 pour les developpeurs, Cours et exercices, Edition Eyrolles.
Afric mémoire est une plateforme web pour le partage des mémoires et TFC entre étudiants du monde entier.
Enregistrer en PDF
Imprimer cette page
