Etude et conception d’un système de

Pointage automatique

I. Présentation du projet

1 Introduction
Dans le but de contrôler le travail ; les entreprises doivent disposer un système de
pointeuse avec un téléphone mobile. Cette solution de géolocalisation par GSM
dispose comme fonctionnalité de réaliser un acte de pointage au moment de l’arrivée et
du départ des salariés de l’entreprise grâce à son smartphone ou d’une tablette ou de
tout autre équipement connecté à internet.

2 Solution proposée
Les applications mobiles offrent une meilleure expérience utilisateur, chargent du
contenu plus rapide que les sites web et sont plus faciles à utiliser. Et pour bien réparer
les problèmes cités, nous avons opté une solution mobile dénommée « CheckIn » qui
permet de pointer automatiquement les heures d’entrée et de sortie des employés.

3 Objectifs
L’objectif de ce projet est de proposer une solution de pointage des employés en
utilisant leurs smartphones connectés à internet via Wifi, 3G ou 4G. Elle permet de réaliser
un acte de pointage au moment de l’arrivée et du départ du site de travail. A travers cette
solution, l’utilisateur peut :

• Pointage automatique dès l’arrivée au lieu de travail et déconnexion en changeant

d’emplacement,

Aussi l’entreprise doit disposer d’un système (backoffice) avec le quelle elle peut :

• Visualiser l’arrivée et le départ des employées,

1
 • Gérer les horaires, les utilisateurs,

• Assurer une fonctionnalité de demande de présence manuelle en cas où l’employé

n’a pas pu se pointer ce jour-là.

4 Méthodologie adoptée

4.1 Choix de la méthodologie

La méthodologie est un ensemble de méthodes et des techniques d’un domaine

particulier pour parvenir à un résultat. Ce qui nous amène à définir la méthodologie
comme un ensemble de méthodes adoptées pour la rédaction d’un document structuré

4.2 Les méthodes AGILE

Les méthodes Agiles disponibles sont nombreuses et peuvent être source de

confusion. Les méthodes Agiles les plus populaires en usage aujourd’hui sont :

• l’eXtrême Programming (XP)

• Scrum

• Agile Unified Process (Agile UP ou AUP),

• Crystal

4.3 Présentation de SCRUM

La méthode agile Scrum est particulièrement destinée à la gestion de projets

informatiques Cette méthode de gestion, ou plutôt ce Framework de management de
projet, a pour objectif d’améliorer la productivité de son équipe. Scrum s’appuie sur le
découpage d’un projet en « boîtes de temps », nommés sprints. Les sprints peuvent durer
entre quelques heures et un mois. Chaque sprint commence par une estimation suivie
d’une planification opérationnelle. Le sprint se termine par une démonstration de ce
qui a été

2
achevé. Avant de démarrer un nouveau sprint, l’équipe réalise une rétrospective. Cette
technique analyse le déroulement du sprint achevé, afin d’améliorer ses pratiques. Le flux de
travail de l’équipe de développement est facilité par son auto-organisation, il n’y aura donc pas
de gestionnaire de projet.

4.4 Les rôles SCRUM

Le Product Owner :

• Responsable de maximiser la valeur du produit et du travail de l’Équipe de

Développement. La façon de jouer ce rôle peut varier grandement selon les
entreprises, les Équipes Scrum et les individus

L’Équipe de Développement :

• L’Équipe de Développement est constituée de professionnels qui livrent à chaque

Sprint un incrément « terminé » et potentiellement livrable du produit

Le Scrum Master :

• Le Scrum Master est responsable de s’assurer que Scrum est compris et mis en
œuvre

• Les Scrum Masters remplissent leur rôle en s’assurant que l’Équipe Scrum adhère
à la théorie, aux pratiques et aux règles de Scrum

• Le Scrum Master est un leader au service de l’Équipe Scrum

3
II. Analyse et Conception

1 Introduction
La spécification des besoins est la base de notre travail qui permettra de dresser la
problématique et les objectifs de notre projet afin de produire le backlog initial comme
une première planification des sprints et nous allons traiter la phase la plus importante
dans le cycle de développement Scrum « planification » et puis la conception.

2 La spécification des besoins

La détermination les besoins fonctionnels et non fonctionnels assurent la réussite de
toute étude. De ce fait, l’étude de ces besoins est la base de notre travail qui permettra
de dresser la problématique et les objectifs de notre projet afin de produire le backlog
initial comme une première planification des sprints et nous allons traiter la phase la plus
importante dans le cycle de développement Scrum « planification ». Elle sert à produire
le backlog initial ainsi qu’une première planification des sprints et par la suite préparer
le plan de release.

4
2.1 Sprint 0 : Capture des besoins

C’est une phase très importante et obligatoire elle doit permettre aux utilisateurs
finaux, de bien exprimer leurs besoins et de bien comprendre les fonctionnalités que le
système va fournir et doit aussi respecter les exigences non fonctionnelles à prendre en
considération dans la phase de développement.

2.1.1 Identification des acteurs

La première des missions est de bien identifier les acteurs qui vont interagir avec le
système. Dans notre cas nous avons typiquement des acteurs humains qui sont :

• L’administrateur : C’est la personne qui a la responsabilité de gérer l’application

de loin. Elle s’occupe de la gestion des employés et des horaires. Elle est
principalement responsable des droits d’accès en utilisant la plateforme Odoo
dédiée seulement pour lui comme administrateur.

• Les employés : Utilisateur aux rôles et permissions restreints, n’a pas beaucoup
de privilèges au sein du système. Il peut demander de pointer dès l’arrivée au lieu
de travail en cas de problème à la phase de pointage automatique, et il peut faire
une demande de congé, accéder à son profile..

2.1.2 Identification des besoins

Il s’agit d’analyser les acteurs acteur par acteur et de vérifier pour chacun qu’il dis-
pose de toutes les fonctionnalités qui lui seront utiles au regard de sa mission et du
périmètre du projet.

• L’administrateur interagit avec le système (plateforme Odoo) afin de :

1. S’authentifier : Il s’agit de saisir les paramètres de connexion pour

s’identifier.

2. Gérer employés : L’administrateur a le droit d’ajouter, de modifier ou de

supprimer un employé.

9
 3. Gérer profil : L’administrateur a le droit de consulter son compte, le modifier
et gérer les autres profils.

4. Gérer horaire : l’administrateur a le droit d’ajouter, de modifier ou de

supprimer les horaires.

5. Consulter pointage : l’administrateur a le droit de visualiser l’arrivé et le

départ des employés.

6. Répondre aux demandes de pointage manuelle : l’administrateur a le droit

d’accepter ou refuser les demandes de pointage manuelle.

7. Répondre aux demandes de congé : l’administrateur a le droit d’accepter ou

refuser les demandes de congé.

• L’employé interagit avec le système (l’application mobile) afin de :

1. S’authentifier : Il s’agit de saisir les paramètres de connexion afin d’accéder

à l’application.

2. Gérer profil : l’employé a le droit de consulter son compte et le modifier.

3. Consulter horaire : l’employé a le droit de consulter les horaires gérés par

l’administrateur.

4. Consulter historique pointage : l’employés a le droit de voir si le pointage est

effectué avec succès.

5. Effectuer une demande de présence manuelle : Employé peut effectuer une

demande de présence manuelle en cas où l’employé n’a pas pu se pointer ce
jour-là.

6. Effectuer une demande de congé : l’employés a le droit de demander un

congé.

10
3 Pilotage du projet avec Scrum

3.1 Les fonctionnalités du Backlog

Le backlog de produit est la liste des fonctionnalités attendues par notre module. Il
contient toutes les tâches qui seront développées par l’équipe. Les tâches ainsi que ses
priorités sont dégagées suite à des réunions avec le client et le chef de projet. Ce Tableau
résume le backlog produit de notre module :

11
 Fonctionnalité Acteur Description priorité
s’authentifier Administrateur, l’administrateur et 1
employé employé doivent
s’authentifier pour
accéder à ses ses-
sions
Gérer employée administrateur l’administrateur 3
peut ajouter mo-
difier et supprimer
employée.
Gérer les horaires administrateur Administrateur peut 5
gérer et consulter
l’horaire de travail
et de pointage des
employés
Gérer profile Administrateur, Administrateur et 2
employé employé peuvent
consulter leurs
profils
Effectuer une employé Employé peut effec- 4
demande de pré- tuer une demande de
sence manuelle présence manuelle
en cas où l’employé
n’a pas pu se pointer
ce jour-là.
Gérer les de- administrateur l’administrateur 4
mandes de peut accepter ou re-
présence ma- fuser le demande de
nuelle présence manuelle

Tableau 2.I – Backlog du produit

3.2 Diagramme des cas d’utilisation globale

Le diagramme de cas d’utilisation est l’un des diagrammes UML utilisé pour donner
une vision globale du comportement fonctionnel d’un système logiciel Un cas
d’utilisation représente une unité d’interaction entre un utilisateur et un système. Dans
notre

12
cas l’administrateur n’utilise pas l’application mobile pour effectuer sa mission, il utilise
une plateforme Odoo qui utilise la même base de donnée avec notre application. c’est
pour cela le diagramme de cas d’utilisation globale sera diviser en deux partie ; une pour
la plateforme Odoo dédiée pour l’administrateur et une autre pour l’application mobile.

Figure 2.1 – Diagramme de cas d’utilisation global partie 1

13
 Figure 2.2 – Diagramme de cas d’utilisation global partie 2

3.3 Planification des sprints

La planification des sprints est l’une des réunions qui rythment un projet Scrum. Elle
est indispensable au bon déroulement de chaque itération et détermine en grande partie
la réussite ou l’échec d’un sprint (c’est l’ensemble des user story inclus dans le sprint).
Une release est une période de temps à l’issue de laquelle une version du livrable est
proposée. Elle est constituée de plusieurs Sprints, leur nombre étant dépendant de leur
durée et de celle fixée pour la release. Pour notre projet nous avons choisi de développer
un release qui sera divisé en deux sprints, le premier est la gestion des paramétrages
(d’administration) et le second sera la gestion de demande de présence manuelle. Ce
tableau résume notre planning de travail :

14
 Sprint 1 Sprint 2
- S’authentifier - Effectuer une demande de présence manuelle
- Gérer employée - Gérer les demandes de présence manuelle
- Gérer les horaires - Effectuer une demande de congés
- Gérer profile - Gérer les demandes de congés
- Consulter pointage

Tableau 2.II – Tableau de planification des sprints

4 Développement du modèle statique : Diagramme de

classe
Le diagramme de classes est considéré comme le plus important de la modélisation
orientée objet. Il est le seul obligatoire lors d’une telle modélisation. Ce diagramme
fait partie de la partie statique d’UML car il fait abstraction des aspects temporels et
dynamiques.

15
 Figure 2.3 – Diagramme de classe

5 Le premier sprint

5.1 Backlog du sprint 1

16
 Fonctionnalité ID User story Acteur Priorité
- En tant que Administrateur je
peux m’identifier pour accéder
à ma session. Administrateur,
S’authentifier 1.1 1
- En tant qu’employé je peux employé
m’identifier
pour accéder à mon compte.

- En tant que Administrateur

Gérer employée 2.1 connecté je peux ajouter des Administrateur 3
nouvelles employées.
- En tant que Administrateur
2.2 connecté je peux modifier des
employée.
- En tant que Administrateur
2.3 connecté je peux supprimer
des employées.
- En tant que Administrateur
2.4 connecté je peux consulter la
liste des employées.
- En tant que Administrateur
Gérer les horaires 3.1 je peux gérer l’horaire de Administrateur 4
travail des employés.
- En tant que Administrateur
3.2 je peux visualiser l’arrivée et
le départ des employées.
- En tant qu’administrateur je
peux consulter mon profile. Administrateur,
Gérer profil 4.1 2
- En tant qu’employé je peut employé
consulter mon profile.

- En tant qu’administrateur je
peux modifier mon compte. Administrateur,
4.2
- En tant qu’employé je peux employé
modifier mon compte.

Tableau 2.III – Backlog du sprint 1

17
5.2 Spécification fonctionnelles

Dans cette activité, nous développerons les cas d’utilisation du sprint 1 en décrivant
les préconditions et postconditions dans chaque cas, ainsi que les principaux scénarios
et exceptions qui peuvent être liés à ce cas.

5.2.1 Gérer employé

Figure 2.4 – Raffinement de cas d’utilisation gérer employé

• Description textuelle de cas d’utilisations Gérer employé :

Nom C.U consulter employé

Acteur Administrateur
Objectif l’administrateur a la possibilité de consulter les employées.
précondition Authentification de l’acteur. Opération consultation em-
ployées choisi
Postcondition la liste des employées afficher
Scénario de base 1) l’administrateur choisit la consultation des informations
2) une liste des employées sera affichée

Tableau 2.IV – Scénario du cas d’utilisation Consulter employé

18
Nom C.U Ajouter employé
Acteur Administrateur
Objectif l’administrateur a la possibilité d’ajouter un employé.
précondition Une authentification préalable
Postcondition Un nouvel contact ajouté à la liste des contacts
Scénario de base 1. L’administrateur clique sur le bouton « Créer nouvelle
employées».
2. L’administrateur saisi les données du employé.
3. Le système vérifie les données saisies.
4. Le système enregistre le nouvel employé dans la liste des
employés.
4.a. L’employé existe déjà
4.a.1 Le système demande à l’administrateur modifier les
données.
4.a.2 Reprise de l’étape 2 du scénario nominal
4.b. L’administrateur saisi des données manquantes
4.b.1 Le système affiche un message d’erreur
4.b.2 Reprise de l’étape 2 du scénario nominal

Tableau 2.V – Scénario du cas d’utilisation Ajouter employées

19
Nom C.U Modifier employé
Acteur Administrateur
Objectif l’administrateur a la possibilité de modifier les données re-
latives à un employé
précondition Une authentification préalable « include» consulté employé.

Postcondition employé modifiée

Scénario de base 1) L’administrateur clique sur le bouton « Modifier » 2)
L’administrateur modifie les champs d’employé sélectionné
3) le système verifié la validation des données 4) Le système
enregistre les données 4.1 Modification non valide : 4.2 Le
système retourne à l’étape 2 du scenario de base

Tableau 2.VI – Scénario du cas d’utilisation Modifier employées

Nom C.U Supprimer employé

Acteur Administrateur
Objectif l’administrateur a la possibilité de supprimer un employé
précondition Une authentification préalable « include» consulté employé.
Postcondition employé supprimée
Scénario de base 1) L’administrateur clique sur le bouton « Supprimer »
2) Le système affiche un message d’avertissement indiquant
l’accord de suppression
3) L’administrateur valide la suppression
Scénario d’ex- L’administrateur annule la suppression
ception

Tableau 2.VII – Scénario du cas d’utilisation Supprimer employées

20
5.2.2 Gérer horaire

Figure 2.5 – Raffinement de cas d’utilisation gérer horaire

• Description textuelle de cas d’utilisations Gérer horaire :

Nom C.U Consulter horaire

Acteur Administrateur
Objectif l’administrateur a la possibilité de consulter l’horaire de tra-
vail des employés
précondition Une authentification préalable « include» consulter horaire
Postcondition Horaire de travail des employés consulté
Scénario de base 1) L’administrateur clique sur le bouton «consulter horaire»
2) Le système affiche les horaires

Tableau 2.VIII – Scénario du cas d’utilisation Consulter horaire

21
Nom C.U Ajouter horaire
Acteur Administrateur
Objectif l’administrateur a la possibilité d’ajouter l’horaire de travail
des employés
précondition Une authentification préalable « include» ajouter horaire
Postcondition Horaire de travail des employés ajouté
Scénario de base 1) L’administrateur clique sur le bouton «ajouter horaire» 2)
l’administrateur ajoute un horaire 3) l’administrateur clique
sur «valider» 4) Le système ajoute les horaires

Tableau 2.IX – Scénario du cas d’utilisation Ajouter horaire

Nom C.U Modifier horaire

Acteur Administrateur
Objectif l’administrateur a la possibilité de modifier l’horaire de tra-
vail des employés
précondition Une authentification préalable « include» modifier l’horaire
Postcondition Horaire de travail des employés modifier
Scénario de base 1) L’administrateur clique sur le bouton «modifier horaire»
2) Le système modifie les horaires des employées

Tableau 2.X – Scénario du cas d’utilisation Modifier horaire

22
 Nom C.U Supprimer horaire
Acteur Administrateur
Objectif l’administrateur a la possibilité de supprimer l’horaire de
travail des employés
précondition Une authentification préalable « include» supprimer l’ho-
raire
Postcondition Horaire de travail des employés supprimé
Scénario de base 1) L’administrateur clique sur le bouton «supprimer ho-
raire» 2) Le système supprime l’horaire cliqué

Tableau 2.XI – Scénario du cas d’utilisation Supprimer horaire

5.2.3 Consulter pointage

• Description textuelle de cas d’utilisations Consulter pointage :

Nom C.U Consulter pointage

Acteur Administrateur
Objectif l’administrateur a la possibilité de consulter l’horaire de
pointage des employés
précondition Une authentification préalable « include» consulter poin-
tage
Postcondition Horaire de pointage des employés consulté
Scénario de base 1) L’administrateur clique sur le bouton « consulter poin-
tage » 2) Le système affiche la fiche des horaires d’arrivée
et de départ des employées

Tableau 2.XII – Scénario du cas d’utilisation Consulter pointage

23
5.2.4 Gérer profile

Figure 2.6 – Raffinement de cas d’utilisation gérer profile

• Description textuelle de cas d’utilisations Gérer profile :

Nom C.U Consulter profile

Acteur Administrateur et employé
Objectif L’acteur peut consulter son compte
précondition Une authentification préalable Opération de consultation
choisie
Postcondition compte consulté
Scénario de base 1) L’acteur choisit la consultation du compte. 2) Le système
fournit l’interface de consultation du compte

Tableau 2.XIII – Scénario du cas d’utilisation Consulter profile

24
 Nom C.U Modifier profile
Acteur Administrateur et employé
précondition Une authentification préalable « include» consulter profil
Postcondition profil modifié
Scénario de base 1) L’acteur clique sur le bouton "Modifier". 2) L’acteur a
modifié le champ des informations personnelles. 3) L’ac-
teur clique sur le bouton «Soumettre». 4) Vérification des
données d’inspection du système 5) Le système enregistre
les données
Scénario d’ex- 1) Modification non valide 2) Le système retour à l’étape 2
ception du système.

Tableau 2.XIV – Scénario du cas d’utilisation Modifier profile

5.2.5 S’authentifier

Nom C.U S’authentifier

Acteur Administrateur, employé
précondition L’acteur doit avoir un login et un mot de passe.
Postcondition Acteur authentifié
Scénario de base 1) L’acteur demande l’interface d’authentification 2) L’ac-
teur saisit son login et son mot de passe 3) L’acteur clique
sur le bouton «Se connecter». 4) Le système verifie la com-
binaison login et mot de passe. 5) Le système affiche l’in-
terface de profil propre à l’acteur
Scénario d’ex- le login ou mot de passe non valide : 1) Le système affiche
ception un message d’erreur. 2) Retour ‘à l’étape 1 du scénario de
base

Tableau 2.XV – Scénario du cas d’utilisation S’authentifier

25
6 Le deuxieme sprint

6.1 Backlog du sprint 2

Fonctionnalité ID User story Acteur Priorité

Gérer les
-En tant que Administrateur
demandes
1.1 connecté je peux consulter Administrateur 2
de présence
les demandes de présence manuelle.
manuelle
-En tant que Administrateur
1.2 connecté je peux accepter les
demandes de présence manuelle.
-En tant que Administrateur
1.3 connecté je peux refuser les
demandes de présence manuelle.
Effectuer
-En tant que employé
une demandes
2 je peux effectuer une Employé 1
de présence
demande de présence manuelle.
manuelle

Gérer les - En tant qu’administrateur

demandes 3.1 je peux consulter les Administrateur 4
de congés demandes de conge.

- En tant qu’administrateur
3.2 je peux accepter les Administrateur
demandes de conge..
- En tant qu’administrateur
3.3 je peux refuser les
demandes de conge.
Effectuer une -En tant que employé je
demande 4 peux effectuer une demande Employé 3
de conge. de conge.

Tableau 2.XVI – Backlog du sprint 2

26
6.2 Spécification fonctionnelle

6.2.1 Répondre aux demandes de pointage manuelle

Figure 2.7 – Raffinement de cas d’utilisation repondre aux demande de pointage manuel

• Description textuelle de cas d’utilisations Répondre aux demandes de pointage

manuelle :

Nom C.U Accepter demande de pointage

Acteur Administrateur
Objectif l’administrateur a la possibilité d’accepter les demandes de
présence manuelle.
Précondition Une authentification préalable
Postcondition La demande de présence manuelle est acceptée.
Scénario de base 1) L’administrateur clique sur le bouton « accepter». 2) Le
système enregistre la demande de présence manuelle.

Tableau 2.XVII – Scénario du cas d’utilisation Accepter demande de pointage

27
 Nom C.U Refuser demande de pointage
Acteur Administrateur
Objectif l’administrateur a la possibilité de refuser les demandes de
présence manuelle.
Précondition Une authentification préalable
Postcondition La demande de présence manuelle est refusée.
Scénario de base 1) L’administrateur clique sur le bouton « refuser». 2) Le
système refuse la demande de présence manuelle.

Tableau 2.XVIII – Scénario du cas d’utilisation Refuser demande de pointage

6.2.2 Répondre aux demandes de congé

• Description textuelle de cas d’utilisations Répondre aux demandes de congés :

Nom C.U Accepter demande de congé

Acteur Administrateur
Objectif l’administrateur a la possibilité d’accepter les demandes de
congés.
Précondition Une authentification préalable
Postcondition La demande de congé est acceptée.
Scénario de base 1) L’administrateur clique sur le bouton « accepter». 2) Le
système enregistre le demande de congé.

Tableau 2.XIX – Scénario du cas d’utilisation Accepter demande de congé

28
 Nom C.U Refuser demande de congé
Acteur Administrateur
Objectif l’administrateur a la possibilité de refuser le demande de
congé.
Précondition Une authentification préalable
Postcondition La demande de congé est refusée.
Scénario de base 1) L’administrateur clique sur le bouton « refuser». 2) Le
système refuse la demande de congé.

Tableau 2.XX – Scénario du cas d’utilisation Refuser demande de congé

6.2.3 Demander un pointage manuel

Figure 2.8 – Raffinement de cas d’utilisation demander un pointage manuel

• Description textuelle de cas d’utilisations demander un pointage manuel :

29
 Nom C.U demander un pointage manuel
Acteur employé
précondition Une authentification préalable
Postcondition Demande de présence manuelle effectuer
Scénario de base 1) L’acteur clique sur le bouton "demande ". 2) L’acteur
remplit les champs. 3) L’acteur clique sur le bouton «en-
registrer». 4) Le système verfie le saisie 5) Le système en-
registre les données.
Scénario d’ex- 1) Données non valide : 2) Le système affiche un message
ception d’erreur. 3) Retour à l’étape 2 de Scenarios de base.

Tableau 2.XXI – Scénario du cas d’utilisation demander un pointage manuel

Nom C.U Saisir raison de pointage manuel

Acteur employé
précondition Une authentification préalable
Postcondition raison de la demande de présence manuelle saisie
Scénario de base 1) L’acteur clique sur le bouton "demande ". 2) L’acteur sai-
sie la raison. 3) L’acteur clique sur le bouton «enregistrer».
4) Le système verfie le saisie 5) Le système enregistre les
données.
Scénario d’ex- 1) Données non valide : 2) Le système affiche un message
ception d’erreur. 3) Retour à l’étape 2 de Scenarios de base.

Tableau 2.XXII – Scénario du cas d’utilisation saisir raison de pointage manuel

6.2.4 Demander un congé

• Description textuelle de cas d’utilisations demander un congé :

30
 Nom C.U Demander un congé
Acteur employé
précondition Une authentification préalable
Postcondition Demande de congé effectuer
Scénario de base 1) L’acteur clique sur le bouton "demande ".
2) L’acteur remplit les champs.
3) L’acteur clique sur le bouton «enregistrer».
4) Le système verfie le saisie
5) Le système enregistre les données.

Scénario d’ex- Données non valide :

ception 1) Le système affiche un message d’erreur.
2) Retour à l’étape 2 de Scenarios de base.

Tableau 2.XXIII – Scénario du cas d’utilisation Demander un congé

Nom C.U Saisir raison de congé

Acteur employé
précondition Une authentification préalable
Postcondition raison de congé saisie
Scénario de base 1) L’acteur clique sur le bouton "demande ". 2) L’acteur sai-
sie la raison. 3) L’acteur clique sur le bouton «enregistrer».
4) Le système verfie le saisie 5) Le système enregistre les
données.
Scénario d’ex- 1) Données non valide : 2) Le système affiche un message
ception d’erreur. 3) Retour à l’étape 2 de Scenarios de base.

Tableau 2.XXIV – Scénario du cas d’utilisation saisir raison de congé

6.3 Les diagrammes de séquence des cas d’utilisation

6.4 Les diagrammes de séquence

Le diagramme de séquence permet de montrer les interactions d’objets dans le cadre

d’un scénario d’un diagramme des cas d’utilisation et de décrire COMMENT les
éléments du système interagissent entre eux et avec les acteurs. Il faut mentionner que

31
notre application s’appuie sur l’architecture MVC (Modèle-Vue-Contrôleur) qui est une
architecture destinée ‘a répondre aux besoins des applications interactives en séparant
les problématiques liées aux différents composants en les regroupant par couches.
Comme son nom l’indique, MVC regroupe les fonctions nécessaires en trois
catégories: Modèle, Vue et Contrôleur.

Diagramme de séquence "Authentification"

Figure 2.9 – Diagramme de séquence d’authentification

Diagramme de séquence "Demande de pointage"

32
Figure 2.10 – Diagramme de séquence Demande de pointage

33