Arrow Table de matières
4425536

CHAPITRE II : ORGANISATION ET APPROCHE METHODOLOGIQUE DU SYSTEME

2.1 HISTORIQUE DE MODELISATION OBJET

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.

2.2 ESSENTIEL SUR UML

            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.

  1. Spécification des besoins

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.

  1. Recueil des besoins 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.

  1. Fonctionnalités du système ou besoins fonctionnels

Notre système doit pouvoir offrir les différentes fonctions ou services que sont :

  • la navigation : L’utilisateur doit pouvoir, sur une interface web simple, naviguer sur la plate-forme sans trop de difficultés ;
  • la recherche : la recherche des travaux scientifiques doit être faite aisément.
  • la saisie des informations caractérisant un profil, (ex le profil de l’étudiant) à partir des formulaires doit être claire.
  1. Besoins opérationnels ou techniques

La mise en place du site doit tenir compte d’un certain nombre de besoins techniques dont :

  • la sécurité d’accès au système: Lors de sa connexion, l’agent et le propriétaire doivent, après inscription être reconnu du système par un nom, un mot de passe prédéfini, il est également chargé de la définition des profils;
  • la rapidité d’accès: le système doit pouvoir répondre aux demandes des utilisateurs en temps voulu ;
  • l’accessibilité: l’application doit être accessible via une interface web à partir d’un poste connecté à Internet

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 :

  • Agent ou Administrateur: ce sont les différents agents disponibles pouvant être doté du pouvoir d’usage qui a accès à toutes les fonctionnalités. Il valide les contenus et les mises à jour proposés par le public. En somme, il est en charge du bon fonctionnement et de la maintenance de la plate-forme ;
  • Etudiant : C’est un intervenant externe du système. Il peut s’inscrire dans le système et  soumettre son Travail de Fin de Cycle ou son mémoire.
  • Directeur : c’est un intervenant qui va interagir avec le système, en voyant les étudiants qui lui sont affectés pour la direction.

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 :

  • Plusieurs étudiants,
  • Plusieurs directeurs,
  • un agent ou administrateur.

Scenarios

Acteurs

Cas d’utilisation

Scenarios

Agent / administrateur

S’inscrire

S: 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

S: 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).


  1. a) Cas d’utilisation inscription
  • Description de CU1

CU1 Inscription

Résumé: Ce CU permet à l’acteur de s’inscrire.

Acteurs: Agent

Post-Condition: le cas démarre après le point 02 de l’enchainement nominal,

l’utilisateur s’inscrit au site

Scénario nominal

DESCRIPTION DU SCENARIO NOMINAL

« DEBUT»

01 : le système affiche un formulaire d’inscription à l’acteur

02 : l’acteur saisit ses informations.

03 : le système vérifie la validité des informations saisies.

04 : le système enregistre ces informations dans la base de données.

05 : le système notifie l’acteur du bon déroulement de l’inscription

« FIN»

Scenario alternative

les informations sont manquantes ou incorrectes: 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, garde les informations

saisies avant et le scénario reprend au point 02 du scénario nominal.

Tableau 2: description de cas d’utilisation inscription

  • Diagramme de séquence du CU1

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 »

  1. b) Cas d’utilisation Authentification
  • Description de CU2

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

  • Diagramme de séquence « 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

  1. c) Cas d’utilisation Ajout
  • Description de CU3

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

  • Diagramme de séquence « 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.

Diagramme de classe

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 :

  • Agent : l’agent est en même temps l’administrateur du site parce que les mêmes fonctions ne demande pas que l’on engage une personne dans le département ou attribuer les fonctions de la gestion du site à quelqu’un d’autre
  • Etudiant : pour ajouter les nouveaux étudiants dans le site.
  • dep_trav : lorsqu’un étudiant dépose son travail, ce dernier s’enregistre dans cette entité.
  • Sujet : réservé pour l’ajout des nouveaux sujets.
  • Directeur : disponible en fin que les directeurs des travaux puissent être aussi enregistrés.
  • Direction : cette table est allouée pour sauvegarder les informations sur la direction et codirection des travaux d’étudiants.

Dictionnaire des données

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

Représentation des classes

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 :

  • Attributs : représentant des données dont les valeurs représentent l’état de l’objet.
  • La méthode : il s’agit des opérations applicables aux objets.

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 :

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

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

Règles de gestion

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

Figure 5 Diagramme de classe

[1] Xavier Blac, Isabelle Mounier, UML 2 pour les developpeurs, Cours et exercices, Edition Eyrolles.

Partager ce travail sur :