rapport final recruteemnt finale

1

Dédicaces

Au symbole de douceur, de tendresse, d’amour et

d’affection, ma mère pour son soutien incessant.

A mon père, pour les sacrifices qu’il a consentis pour

mon éducation.

Que ce travail soit le témoignage de l'amour que je lui avoue.

A mon cher frère Amin qui qui m'a été d'un soutien

indéniable, que dieu te procure bonne santé et une longue

vie.

A mes chers amis qui m'ont soutenue, encouragée et

m'ont surtout permis de travailler dans une atmosphère

joviale.

Soumow

2

Remerciements

C'est avec un grand plaisir que je réserve cette page en signe de gratitude

et de profonde reconnaissance à tous ceux qui m'ont aidé à la réalisation de ce

travail.

Tout d’abord, je tiens à remercier la société OXIA qui m’a accueilli. En

effet j’ai eu le plaisir et l’honneur de travailler au sein d’une aussi grande

entreprise.

J'adresse mes sincères remerciements à mon encadreur Mr Amine

Laroussi, pour sa disponibilité, sa générosité, son encadrement de qualité et pour

tous ses conseils judicieux tout au long de mon projet.

Je remercie également mon encadreur à la Faculté des sciences de Tunis,

Mr Samir Elloumi pour son aide précieux, sa qualité d'encadrement et le savoir

qu'il m'a transmis.

Mes remerciements et reconnaissances s'étendent également à toute la

famille OXIA pour leur chaleureux accueil et particulièrement Mr Khaled Ben

Driss, Directeur Technique chez OXIA, pour sa disponibilité, sa clairvoyance et

son expérience qu’il nous a fait partager, et Mr Mohamed Karim Lili,

développeur chez OXIA, pour tous ses conseils et son soutien moral incessant.

Enfin, je tiens à remercier l'équipe de développeurs, constitué de Mr

Hassen Khalifa et Mr Jed Miled, avec qui j’ai travaillé tout au long de ce projet,

nous avons formé une équipe soudée et homogène dans le but de réussir notre

projet.

3

Table des matières

CHAPITRE 1 PRESENTATION DU CADRE DU PROJET ........................................ 12

INTRODUCTION .................................................................................................................. 13

1. PRESENTATION DE L’ORGANISME D’ACCUEIL .................................................. 13

1.1. MISSION .......................................................................................................................... 13

1.2. DOMAINES DE COMPETENCES .......................................................................................... 14

1.2.1. Finance .................................................................................................................... 14

1.2.2. Solutions de Gestion d’Entreprises ......................................................................... 14

1.2.3. e-business ................................................................................................................ 14

1.2.4. Télécommunications ............................................................................................... 14

2. ETUDE DE L’EXISTANT ................................................................................................ 14

3. CRITIQUE DE L’EXISTANT .......................................................................................... 15

4. SOLUTION PROPOSEE .................................................................................................. 15

5. METHODOLOGIE DU TRAVAIL ................................................................................. 16

5.1 METHODE AGILE .............................................................................................................. 16

5.1.1 Définition .................................................................................................................. 16

5.1.2 Valeurs des méthodes Agiles .................................................................................... 16

5.1.3 Principes des méthodes Agiles ................................................................................. 16

5.2 CHOIX DE LA METHODE AGILE SCRUM .......................................................................... 17

5.2.1 Définition .................................................................................................................. 17

5.2.2 Justification du choix ................................................................................................ 17

5.2.3 Mise en œuvre .......................................................................................................... 18

5.2.4 Planification .............................................................................................................. 19

5.2.5 Gestion des besoins .................................................................................................. 20

5.3 CHOIX CONCEPTUELS ....................................................................................................... 21

4

5.3.1 Choix de l’approche Objet ........................................................................................ 21

5.3.2 Langage de modélisation : UML .............................................................................. 22

5.3.3 Outils logiciel de conception .................................................................................... 22

CONCLUSION ....................................................................................................................... 23

CHAPITRE 2 SPECIFICATION DES BESOINS ........................................................... 24

INTRODUCTION .................................................................................................................. 25

1. SPECIFICATION INFORMELLE .................................................................................. 25

1.1. BESOINS FONCTIONNELS................................................................................................. 25

1.2. BESOINS NON FONCTIONNELS ......................................................................................... 26

2 IDENTIFICATION DES CAS D’UTILISATION ........................................................... 26

2.1 Définition ..................................................................................................................... 26

2.2 Diagrammes des cas d’utilisation : Framework .......................................................... 27

2.3 Diagrammes des cas d’utilisation : Workflow Recrutement ....................................... 28

3. VUE DYNAMIQUE : DIAGRAMME D’ACTIVITES .................................................. 34

3.1 DIAGRAMME D’ACTIVITE : FLUX DE TRAVAIL DE RECRUTEMENT .................................... 35

CONCLUSION ....................................................................................................................... 36

CHAPITRE 3 CONCEPTION DE LA SOLUTION ....................................................... 37

INTRODUCTION .................................................................................................................. 38

1. VUE STATIQUE : DIAGRAMME DE CLASSE ........................................................... 38

DESCRIPTION DU DIAGRAMME DE CLASSE .............................................................................. 40

2. DIAGRAMME DE SEQUENCE ...................................................................................... 42

2.1. DIAGRAMME DE SEQUENCE FRAMEWORK ....................................................................... 43

2.1.1. Diagramme de séquence : Administrateur Recrutement ......................................... 43

2.3. DIAGRAMME DE SEQUENCE WORKFLOW RECRUTEMENT ................................................ 45

2.3.1. Diagramme de séquence : Authentification ............................................................. 45

2.3.2. Diagramme de séquence : Chargé Recrutement ...................................................... 47

5

2.3. Diagramme de séquence : Evaluateur ........................................................................ 53

CONCLUSION ....................................................................................................................... 54

CHAPITRE 4 REALISATION ........................................................................................... 55

INTRODUCTION .................................................................................................................. 56

1. PRESENTATION DE L’ARCHITECTURE .................................................................. 56

1.1 CHOIX DE L’ARCHITECTURE ............................................................................................. 56

1.2 STRUCTURE DE L’APPLICATION ........................................................................................ 57

1.2.1 Présentation Layer .................................................................................................... 57

1.2.2 Service Layer ............................................................................................................ 58

1.2.3. Business Layer ......................................................................................................... 58

1.2.4. Data Layer ............................................................................................................... 58

1.2.5. Framework ............................................................................................................... 58

1.3 SCHEMA DE DEPENDANCE ENTRE COUCHES ...................................................................... 58

2. ENVIRONNEMENT DE DEVELOPPEMENT ............................................................. 60

2.1. ENVIRONNEMENT MATERIEL ........................................................................................... 60

2.2. ENVIRONNEMENT LOGICIEL ............................................................................................ 60

2.2.1 Framework utilisé ..................................................................................................... 60

2.2.2 Technologies de développement .............................................................................. 62

2.2.3 Langage de développement ...................................................................................... 64

2.2.4 Logiciels utilisés ....................................................................................................... 65

3. SCENARIOS D’EXECUTION ......................................................................................... 68

3.1 INTERFACES DU FRAMEWORK .......................................................................................... 68

3.1.1 Authentification ........................................................................................................ 68

3.1.2 Interface principale ................................................................................................... 69

3.1.3 Paramétrage des acteurs du workflow Recrutement ................................................. 70

3.1.4 Paramétrage des autorisations du workflow Recrutement ....................................... 71

6

3.1.5 Interface d’aide à la saisie : Recherche F12 ............................................................. 71

3.2 PRINCIPALES INTERFACES DU WORKFLOW RECRUTEMENT .............................................. 72

3.2.1 Ecran Candidat ......................................................................................................... 72

3.2.2 Ecran Test/Entretien ................................................................................................. 75

4. GESTION DU PROJET .................................................................................................... 77

CONCLUSION ....................................................................................................................... 78

CONCLUSION GENERALE ............................................................................................... 80

ANNEXES ............................................................................................................................... 82

ANNEXE A : DIAGRAMME DE FLUX DE CANDIDAT ................................................ 83

ANNEXE B : SCHEMATIQUEMENT WORKFLOW RH .............................................. 84

ANNEXE C : UML ................................................................................................................ 85

GLOSSAIRE ........................................................................................................................... 87

7

Liste des figures

Figure 1.1 : Logo de OXIA ..................................................................................................... 13

Figure 1.2 : Vue globale du processus Scrum ....................................................................... 21

Figure 1.3 : Emblème de SYBASE PowerAMC ................................................................... 22

Figure 2.1 : Diagramme des cas d’utilisation Framework .................................................. 27

Figure 2.2 : Les cas utilisation du système « Flux de travail de Recrutement » ................ 30

Figure 2.3 : Cas d’utilisation de l’acteur « Chargé Recrutement » .................................... 31

Figure 2.4 : Cas d’utilisation de l’acteur « Assistante de Direction » ................................. 33

Figure 2.5 : Cas d’utilisation de l’acteur « Administrateur » ............................................. 34

Figure 2.6 : Diagramme d’activité : Flux de travail de Recrutement................................. 35

Figure 3.1 : Diagramme de classe : Flux de travail de Recrutement .................................. 39

Figure 3.2 : Diagramme de séquence : Administration ....................................................... 43

Figure 3.3 : Diagramme de séquence : Authentification ..................................................... 45

Figure 3.4 : Diagramme de séquence : Insertion Candidat ................................................. 47

Figure 3.5 : Diagramme de séquence : Affichage Candidat ................................................ 49

Figure 3.6 : Diagramme de séquence : Planification Entretien .......................................... 51

Figure 3.7 : Diagramme de séquence : Réalisation Entretien ............................................. 53

Figure 4.1 : Architecture commune d’une application ........................................................ 56

Figure 4.2 : Structure en couche du Framework OXIADOTNET ..................................... 57

Figure 4.3 : Schéma de dépendance entre couches ............................................................... 59

Figure 4.4 : Logo Microsoft .NET .......................................................................................... 60

8

Figure 4.5 : Logo Microsoft Entreprise Library 5.0 ............................................................ 61

Figure 4.6 : Microsoft Visual Studio 2010 Ultimate ............................................................. 65

Figure 4.7 : Microsoft Expression Blend 4 ............................................................................ 66

Figure 4.8 : Oracle ................................................................................................................... 67

Figure 4.9 : Tortoise SVN ....................................................................................................... 67

Figure 4.10 : Interface d’authentification ............................................................................. 68

Figure 4.11 : Interface Principale .......................................................................................... 69

Figure 4.12 : Paramétrage des acteurs du Workflow Recrutement ................................... 70

Figure 4.13 : Paramétrage des autorisations du Workflow Recrutement ......................... 71

Figure 4.14 : Fenêtre d’aide à la saisie .................................................................................. 71

Figure 4.15 : Interface Candidat ............................................................................................ 72

Figure 4.16 : Ecran Ajout Candidat : Informations Personnelles ...................................... 73

Figure 4.17 : Ecrans Ajout Candidat : Niveau Académique et Expérience ....................... 73

Figure 4.18 : Ecrans Ajout Candidat : Références et Certifications .................................. 73

Figure 4.19 : Ecrans Recherche Candidat : Informations Personnelles et Expérience .... 74

Figure 4.20 : Ecran Candidat pour offre .............................................................................. 74

Figure 4.21 : Ecran Candidat : Offre à Faire ....................................................................... 75

Figure 4.23 : Ecran Entretien non planifié ........................................................................... 76

Figure 4.24 : Ecran planifier Entretien ................................................................................. 76

Figure 4.25 : Ecran Test planifié ............................................................................................ 77

Figure 4.26 : Diagramme de Gantt ........................................................................................ 78

9

Figure A.1 : Diagramme de flux de candidat ........................................................................ 83

Figure B.1 : Schématiquement workflow RH ....................................................................... 84

Figure C.1 : Emblème officiel d’UML ................................................................................... 85

10

Introduction Générale

La gestion des ressources humaines occupe aujourd'hui une place prépondérante au

sein de l'entreprise. Sa stratégie permet ainsi aux entreprises de diminuer les risques sociaux

internes à l'organisation comme les grèves, les plans sociaux, les conflits inter salariés. Un

secteur aujourd'hui considéré comme un des maillons les plus importants de l'entreprise. Au

niveau du management général, on cherche à optimiser l'apport des ressources humaines à

partir des éléments par lesquels on agit habituellement sur celles-ci : compétence, motivation,

information, organisation, gestion des groupes.

Le but des ressources humaines est donc de maintenir une gestion efficace des

employés, autant qualitative que quantitative, pour permettre à l’entreprise de prospérer grâce

à un personnel compétent et en nombre suffisant, Ce qui fait de la performance de la fonction

RH (ressources humaines) le cœur des préoccupations actuelles des DRH (direction

ressources humaines). La mesure de la performance dépend naturellement des objectifs fixés à

la fonction.

De ce fait le recrutement, l’une des missions confiées à la fonction RH, s’annonce une

tache de plus en plus ardue, exigeant plus de fiabilité et un temps de gestion minimale avec un

taux de certitudes et d’exactitude maximale.

C’est dans ce cadre que s’inscrit notre projet de fin d’études réalisé chez « OXIA

Tunisie », intitulé : « Conception et réalisation d’une Application de flux de travail de

recrutement ».

Le présent travail se veut une contribution à la mise en place d’une application pour

automatiser les activités du service recrutement. Pour mener à bien la réalisation de cet

objectif, une étude théorique du concept « Flux de travail de Recrutement» s’impose dans le

but de cerner les principales fonctionnalités et comprendre les besoins de la société.

Afin d’illustrer la démarche de notre travail, nous vous présenterons dans ce qui suit

l’organisation générale du rapport. Le présent rapport s’articule autour de cinq chapitres :

Dans le premier chapitre, nous vous exposerons le cadre du projet à travers une

présentation de la société, une étude minutieuse de l’existant (description et critique), pour

enfin conclure avec la solution proposée et la méthodologie utilisée.

11

Le deuxième chapitre sera consacré à la spécification des besoins en termes de besoins

fonctionnels et non-fonctionnels.

Dans le troisième chapitre qui concerne le volet de la conception, on présentera les

différents diagrammes statiques et dynamiques.

Le dernier chapitre sera consacré à la réalisation. L’architecture globale de la solution,

L'environnement matériel et logiciel détaillé du travail seront présentés, ainsi que quelques

captures d’écrans de l'application développée.

Pour conclure, nous présentons les connaissances acquises durant ce stage et nous

proposons comme extension logique de ce projet un ensemble de perspectives.

12

CHAPITRE 1

PRESENTATION DU CADRE DU PROJET

Chapitre 1 : PRESENTATION DU CADRE DU PROJET

13

Introduction

Dans ce premier chapitre, nous présentons l’organisme d’accueil qui est la société

« OXIA », à travers sa Mission, les services qu’elle offre ainsi que les domaines de

compétences qui font sa renommée.

1. Présentation de l’organisme d’accueil

1.1. Mission

Figure 1.1 : Logo de OXIA

OXIA [1] est une société d’ingénierie informatique spécialiste dans les solutions

intégrées d’entreprise. Elle agit sur le marché Tunisien, Européen, et Africain. Elle combine le

savoir-faire métier et l’expertise technique avec des méthodes rigoureuses de conduite de

projet.

OXIA est présente dans les domaines de la finance, la gestion intégrée d’entreprise

(ERP), la logistique, le transport (Supply Chain), le e-business et le conseil en

télécommunication. Elle est forte d’une expertise technique dans divers domaines

technologiques : les architectures d’entreprise, la plate-forme Java, la plate-forme .NET, les

Web Services, l’intégration de systèmes (EAI) sans oublier les technologies client/serveur et

4GL traditionnelles.


14

L’offre d’OXIA s’articule autour du conseil stratégique, le conseil en organisation et

processus, le conseil technologique et la mise en œuvre de solutions progicielles et

spécifiques.

OXIA est notamment certifiée ISO9001:2000 par l’AFAQ pour l’ensemble de ses activités, et

elle est actuellement engagée dans une certification CMMI niveau 3 avec certification SEI.

1.2. Domaines de compétences

1.2.1. Finance

OXIA a acquis une forte expérience dans les domaines du leasing, du factoring et de

l’intermédiation boursière et intervient en tant que cabinet de conseil, d’ingénierie

informatique, et d’intégration de progiciels dans ces trois domaines.

1.2.2. Solutions de Gestion d’Entreprises

OXIA apporte à ses clients une approche qui vise à accroître leur compétitivité et leur

profitabilité. Nous les aidons dans la définition de leur nouveau positionnement stratégique à

travers notre offre de management consulting.

1.2.3. e-business

Une démarche méthodique et des outils performants, fruit d’un processus continu de

recherche et développement, vous permettent de tirer profit du meilleur des technologies

internet afin de mettre en œuvre vos applications B2B, B2C, A2A…

1.2.4. Télécommunications

OXIA a développé une offre de conseil et de pilotage de projets dans le domaine des

télécommunications Voix/Données, et mis l’accent sur les opportunités d’optimisation ou de

réduction des coûts télécoms de ses clients.

2. Etude de l’existant

Le « Système Ressources Humaines » exerce ses activités à travers des requêtes et des

actions offertes par le système d’information actuel OPM. Ce dernier n’offre pas des services

adéquats pour le processus Flux de travail de Recrutement.


15

La planification, la modification, la mise à jour et suivi sont assurés à travers des

fichiers Excel, des fiches papier préparées manuellement et la communication se base par

mail à travers les dossiers de Outlook.

3. Critique de l’existant

Actuellement, la méthode de gestion des recrutements dans le système des ressources

humaines présente plusieurs inconvénients :

La manipulation avec les fichiers Excel, des fiches ; la communication avec les

dossiers Outlook, ne répond pas à un besoin vital de la Gestion ressource humaine qui

est le suivi du candidat dans tous les états du Flux de travail de Recrutement.

Risque manifestement présent des erreurs humaines : inattention, oubli, réplication,

perte de document.

Absence d’un système automatisé robuste pouvant couvrir les activités du Flux de

travail de Recrutement, les états des candidats, des tests et des entretiens, de leur suivi

et de leur historique.

Absence de contrôle sur le droit d’accès aux fichiers.

Absence de stockage de données dans des bases de données pour garantir leur sécurité

et leur intégrité.

4. Solution proposée

Dans le but d'accomplir la tache recrutement dans les meilleures des conditions

possibles, notre application vise une amélioration de la gestion des différents candidats, des

tests et des entretiens et du Flux de travail de Recrutement. Notre projet touche au service

ressources humaine ainsi que celui de développement logiciel vu qu'il met à la disposition de

la société une plateforme .net propriétaire et interne. Une interface graphique ergonomique

fondée sur une conception orientée objet engendrant une facilité de gestion tout en satisfaisant

toutes les normes d'accès en préservant les droit d'accès et les privilège de saisie, sauvegarde,

modification et mise à jour, en fait une authentification primaire et primordiale déclenche le

processus de contrôle des droits. Une configuration assez simple et compréhensible offrant à

l'administrateur un environnement complet et sécurisé de gestion de la tache recrutement.


16

5. Méthodologie du travail

La méthodologie adaptée pour la gestion de notre projet a été choisie par le directeur

technique Mr Khaled Ben Driss. Le choix s’est porté sur une méthodologie Agile : Scrum

Dans ce qui suit nous allons définir la méthodologie, pour ensuite présenter ses valeurs

et ses principes. Nous allons aussi justifier l’utilisation de la méthode Agile Scrum.

5.1 Méthode Agile

5.1.1 Définition

Les méthodes Agiles [2] sont des ensembles de pratiques appliquées principalement

sur les projets de développement informatique. Ce sont des méthodes qui se veulent plus

pragmatiques que les méthodes traditionnelles. Elles impliquent au maximum le demandeur

(client) et permettent une grande réactivité à ses demandes. Elles visent la satisfaction réelle

du besoin du client et non les termes d'un contrat de développement. La notion de méthode

agile a été officialisée en 2001 par un document, le Manifeste Agile (Agile Manifesto), signé

par 17 personnalités impliquées dans l'évolution du génie logiciel, en particulier, en tant

qu'auteur de leur propre méthode.

5.1.2 Valeurs des méthodes Agiles

Les quatre valeurs fondamentales Agiles [3] sont :

l’interaction avec les personnes que les processus et les outils.

un produit opérationnel qu’une documentation pléthorique.

la collaboration avec le client que la négociation de contrat.

la réactivité face au changement que le suivi d'un plan.

5.1.3 Principes des méthodes Agiles

Ces 4 valeurs se déclinent en 12 principes généraux [4] communs à toutes les méthodes

agiles :

Satisfaction Client en livrant régulièrement des logiciels utiles


17

Accepter les changements au cours de développement

livraison fréquente de logiciel (2 à 4 semaines)

Collaboration quotidienne entre le client et les développeurs

Motivation des personnes

Croire en la capacité des développeurs

Conversation face à face

Un logiciel fonctionnel est la meilleure façon de mesurer la progression du projet

Les équipes doivent s'auto-organiser

5.2 Choix de la méthode Agile SCRUM

5.2.1 Définition

Scrum[5] est une méthode agile pour la gestion de projets (principalement le

développement des logiciels). Elle a été conçue pour améliorer grandement la productivité

dans les équipes auparavant paralysées par des méthodologies plus lourdes. Par contre, elle ne

couvre aucune technique d'ingénierie du logiciel, c’est pourquoi il est nécessaire de lui joindre

une méthodologie complémentaire comme l’eXtreme Programming (méthode agile) ou bien

tout simplement les méthodologies de conception d’UML.

5.2.2 Justification du choix

Le choix s’est porté sur Scrum pour plusieurs raisons :

Présence de 2 stagiaires (en plus de moi-même) pour la réalisation de nos projets de

fin d’études. Ainsi nous avons pu former une petite équipe de développeurs.

Le besoin de développer un nouveau Framework propriétaire à OXIA à base de la

technologie .NET et pouvoir en profiter éventuellement après pour le développement

d’autres modules. Ce projet pourrait remplacer le système d’information actuelle OPM

(développé avec Centura à base de C++).


18

La nature des projets de fin d’études : en effet, il s’agit de répondre à des besoins en

interne, c’est ce qui facilite la communication avec le client.

5.2.3 Mise en œuvre

5.2.3.1 Définitions des rôles

La première étape est de définir les rôles au sein de l’équipe :

Le directeur de produit (Product Owner) : Mr. Amine Laroussi, chef projet à OXIA

et ayant pour tâche de maintenir à jour le Système d’informations d’OXIA. Il est le

représentant des clients et utilisateurs. C'est à lui que revient la tâche de définir l'ordre

dans lequel les fonctionnalités seront développées ainsi que la prise des décisions

importantes concernant l'orientation du projet. Il se trouve au même bureau que

l’équipe de développeurs.

L’équipe : elle est composée de trois développeurs dont je fais partie. Cette équipe a

eu comme tâche de réaliser le Framework dans lequel on intégrera les différentes

applications dont l’une est le Flux de travail de Recrutement.

Les tâches Framework sont :

Création de l’interface Graphique de l’Application en WPF4.

Intégration du Flux de travail de WF4 au Framework.

Integration du WCF4 (Windows Communication Foundation)

Conception et réalisation d’une fonction d’aide à la saisie.

Documentation et Utilisation d’Enterprise Library 5 dans le

Framework.

Documentation et Choix de design pattern pour la couche d’accès aux

données

Le facilitateur (ScrumMaster) : ce rôle est également assuré par Mr Amine Laroussi,

il s’est chargé de protéger l'équipe de tous les éléments perturbateurs extérieurs.


19

Les intervenants (Stakeholders) : Ce sont les personnes qui souhaitent avoir une vue

sur le projet sans réellement s'investir dedans.

o Khaled Ben Driss : Directeur Technique à OXIA, avec qui nous avons des

réunions bihebdomadaire, et qui a suivi de près l’avancement du projet.

o Imed Ayadi : Directeur Général à OXIA, avec qui nous avons eu une réunion

pour la validation des besoins du projet.

Les clients (Customers): Ceux à qui est offerte l’application.

o Dorra Bouziri : Directeur Ressources Humaines, avec qui nous avons eu trois

réunions pour définir les besoins fonctionnelles de l’application.

o Selma Bellouma : Chargée Recrutement, avec qui nous avons eu deux

réunions pour définir les besoins directes de l’application.

5.2.4 Planification

Scrum permet de définir trois niveaux de planification :

sprint

release/projet

quotidien

5.2.4.1 Les sprints

Scrum est un processus itératif : les itérations sont appelées des sprints qui durent

généralement entre 2 et 4 semaines. Chaque sprint possède un but et on lui associe une liste de

fonctionnalités à réaliser (appelées items de backlog de produit). Ces items sont décomposés

par l'équipe en tâches élémentaires de quelques heures ; les items de backlog de sprint.

Dans notre projet, nous avons opté pour des sprints de deux semaines, suffisant pour

avancer dans nos tâches respectives.


20

5.2.4.2 Releases

Il s’agit de regrouper les itérations (sprints) en unité plus grande portant généralement une

définition sémantique. Dans notre cas, on peut distinguer 3 releases :

Documentation et définitions de besoins.

Conception et réalisation du Framework.

Conception et réalisation du module Flux de travail Recrutement.

5.2.4.3 Quotidien

C’est une réunion quotidienne avec notre ScrumMaster afin de faire un point sur ce

qui a été réalisé la veille, ce que nous devons à faire dans la journée. C’est aussi l’occasion de

discuter des difficultés rencontrées lors de nos tâches respectives.

5.2.5 Gestion des besoins

5.2.5.1 Backlog de produit

Après avoir récolté les besoins fonctionnels des clients, le directeur de produit établit

une liste de fonctionnalités à réaliser, appeléeBacklog de produit.

5.2.5.2 Backlog de sprint

Au départ d’un sprint, Nous choisissons quels items du Backlog de produit seront

réalisés lors de ce sprint. Les items sont décomposés alors en liste de tâches élémentaires.

Chaque tâche est estimée en heures ou en jours. On constitue ainsi le Backlog de sprint.

Pendant le déroulement du sprint, chaque équipier s'affecte des tâches du Backlog de sprint et

les réalise.

Exemple : documentation et réalisation d’un tutoriel sur Enterprise Library 5 en un seul sprint

Item de Backlog de produit : documentation sur Enterprise Library 5 et réalisation

d’un tutoriel

Durée du sprint : 2 semaines

Durée de BackLog sprint : 4 heures


21

Tâches élémentaires : étudier 5 blocks d’Enterprise Library 5, pour chaque block, il

faut :

o Se documenter

o Réaliser des tests

o Réaliser une démonstration

o Mettre à jour le tutoriel

Le schéma suivant nous donne une idée globale du processus Scrum.

Figure 1.2 : Vue globale du processus Scrum

5.3 Choix conceptuels

5.3.1 Choix de l’approche Objet

Nous avons adopté une approche objet comme mode de conception de notre système

et ce pour les raisons suivantes:

Les concepts de base de l’approche objet sont stables, normalisés et largement

approuvés.


22

L’approche objet permet de bénéficier d’une panoplie d’outils et de langages

performants facilitant le développement.

La modélisation par objet correspond étroitement au monde réel. Il est par conséquent

plus souple pour les modifications.

Contrairement à l’approche fonctionnelle, l’approche objet représente une solution

destinée à faciliter l’évolution d’applications complexes telles que notre application

”Flux de travail de Recrutement”.

5.3.2 Langage de modélisation : UML

Ayant opté pour une approche objet, le choix d’UML [voir Annexe 3] nous semble une

évidence. En effet, il est reconnu comme étant le standard industriel par excellence de la

modélisation objet. Cela est d’autant plus probant quand nous prenons connaissance qu’UML

unifie à la fois les notations et les concepts orientés objet.

5.3.3 Outils logiciel de conception

Afin de modéliser notre travail en langage UML, nous avions eu recourt à un logiciel

complet de modélisation du nom de « Power AMC » dans sa version 15.

PowerAMC, le n°1 de la modélisation de données, est un outil tout-en-un de modélisation

d'entreprise et de gestion des métadonnées destiné à documenter l'architecture d'entreprise.

Figure 1.3 : Emblème de SYBASE PowerAMC

PowerAMC est un environnement graphique de modélisation d'entreprise très simple d'emploi

qui permet d'effectuer les tâches suivantes :

Modélisation intégrée via l'utilisation de méthodologies et de notations standards :


23

o Données (E/R, Merise)

o Métiers (BPMN, BPEL, ebXML)

o Application (UML)

o Génération automatique de code via des Template personnalisables

o SQL (avec plus de 50 SGBD)

o Java

o .NET

Fonctionnalités de reverse engineering pour documenter et mettre à jour des systèmes

existants

Une solution de référentiel d'entreprise avec des fonctionnalités de sécurité et de

gestion des versions très complètes pour permettre un développement multi-

utilisateurs

Fonctionnalités de génération et de gestion de rapports automatisés et personnalisables

Un environnement extensible, qui vous permet d'ajouter des règles, des commandes,

des concepts et des attributs à vos méthodologies de modélisation et de codage.

Conclusion

Dans ce chapitre, nous avons introduit l’entreprise d’accueil « OXIA » en présentant sa

procédure actuelle de recrutement. Nous avons ensuite procédé à une critique de l’existant et

nous avons proposé diverses solutions.

Dans le prochain chapitre, nous allons étudier la spécification de notre projet et nous allons

dresser des diagrammes de cas d’utilisation qui vont décrire les besoins de ce système ainsi

qu’un diagramme d’activité qui va mettre au point l’enchaînement du workflow recrutement.

24

CHAPITRE 2

SPECIFICATION DES BESOINS

Chapitre 2 : SPECIFICATION DES BESOINS

25

Introduction

Ce chapitre renferme une description des besoins du processus recrutement en

spécifiant ceux fonctionnels et non fonctionnels. On y étudiera en premier lieu les différents

diagrammes de cas d'utilisations pour aboutir à une description détaillée du diagramme

d'activité du flux de la tache recrutement.

1. Spécification informelle

L’objectif de ce projet est de concevoir et de réaliser une application de Flux de travail

de Recrutement permettant d’exercer les différentes activités au sein du processus

«Ressources Humaines ».

Comme toute autre application, notre application devrait répondre à certains besoins et

assurer plusieurs fonctionnalités, dégagées suite à des réunions avec les analystes métier, le

chef de projet et du responsable de la société.

1.1. Besoins fonctionnels

Les Besoins fonctionnels de notre application « Flux de travail recrutement » se présentent

comme suit :

- Gérer les candidats : création, modification, suppression.

- Gérer les tests : planification, réalisation, décision.

- Gérer les entretiens : planification, réalisation, décision.

- Gérer le suivi de l’état du candidat dans toutes les étapes : pour test, pour entretien,

retenu à chaud, rejeté, recruté.

- Faciliter la recherche du candidat, du test ou de l’entretien à travers des filtres.

- Assurer l’historique pour une meilleure gestion des statistiques de l’application.


26

1.2. Besoins non fonctionnels

Les besoins non-fonctionnels décrivent le comportement du système dans tous ses

aspects, se focalisant principalement sur les contraintes de temps de réponse de l’organisme

d’accueil (OXIA) vis à vis au client (OXIA). Le développement de l’application qui doit

respecter une architecture en couches, comprend la mise en place d’un Framework à travers

lequel il faut développer le «Flux de travail Recrutement» en tant que module tout en

garantissant l'extensibilité de l'application pour lui permettre accueillir d’autres modules,

d’autres couches, d’autres interfaces.

En fait, parmi les caractéristiques prises en charge dans l'application, on mentionne la

sécurité qui est un besoin primordiale pour préserver l’intégrité des données. On cite aussi la

maintenabilité cohérente et la moins couteuse possible. En effet, la clarté et la lisibilité du

code selon les normes de codage propre à la société, ouvre les horizons de son évolution et

amélioration aisée surtout avec des interfaces ergonomique simples à paramétrer.

En d'autres termes l'application doit faciliter à tous les coups la tache de recrutement

en supportant à la fois un flux de données large et une intervention de plusieurs utilisateurs ce

qui organise la tâche et minimise le temps de réponse des requêtes de l’utilisateur doit être le

plus optimisé que possible pour gagner en productivité.

2 Identification des cas d’utilisation

2.1 Définition

Un cas d’utilisation modélise un service rendu par le système. Il exprime les

interactions acteurs/système et apporte une valeur ajoutée notable aux acteurs.

Il représente une séquence d’actions réalisées par le système. L’identification des cas

d’utilisation se fait en cherchant :

Les tâches que l’acteur veut que le système exécute.

Les tâches de création, sauvegarde, modification, suppression ou consultation des

données dans le système par l’acteur.


27

Les tâches que l’acteur fera pour informer le système des changements soudains ou

externes.

Les informations que l’acteur doit connaître sur certains événements du système.

L’ensemble des fonctionnalités du futur système est déterminé en examinant les

besoins fonctionnels de chaque acteur, exprimés sous forme de familles d’interactions

dans les cas d’utilisation.

Dans ce qui suit nous présentons les cas d’utilisation pour chaque acteur défini

précédemment.

2.2 Diagrammes des cas d’utilisation : Framework

Figure 2.1 : Diagramme des cas d’utilisation Framework

Ce diagramme des cas d’utilisation du Framework (figure 2.1) par l’application « Flux de

travail de recrutement » trace la relation entre notre application et le Framework qu’on a

conçu afin de satisfaire ces besoins :


28

Utilisation de contrôles personnalisés comme le « OXIATextBox » qui hérite du

contrôle textBox de WPF et lui ajoute des méthodes propriétaires au Framework et

utilisables par la suite dans les différentes applications.

Utilisation de la fonction d’aide à la saisie, recherche F12 : c’est une fonction qui

facilite la recherche en cliquant sur F12 dans le champ personnalisé du Framework, la

fonction de recherche affiche une liste d’attributs souhaités selon ce champ-là.

Utilisation d’un seul « ToolBar » du Framework, dont les boutons contiennent des

méthodes qui facilitent l’utilisation et le traitement de l’application qui sera intégrée

par la suite.

Utilisation d’un menu générique à partir de la base de donnée et utilisable par toutes

les applications du Framework.

Les droits de l’accès sont gérés par la fenêtre authentification du Framewrok, elle gère

ainsi la gestion des profils.

Le Framework gère l’historique de toutes les opérations effectuées dans les

applications et les stocke dans la base de données par opération, date, heure et

utilisateur.

Le Framework gère la gestion des favoris, c’est une option donnée aux utilisateurs de

l’application intégrée dans le Framework, ils peuvent sauvegarder une opération qu’ils

voient répétitive par exemple une recherche avec un certain filtrage.

2.3 Diagrammes des cas d’utilisation : Workflow Recrutement

2.3.1 Identification des acteurs

Un acteur est un rôle joué par des entités externes qui interagissent directement avec le

système étudié. L’identification des acteurs se fait en cherchant :

- Les utilisateurs qui fournissent, utilisent ou retirent des informations du système.

- Les utilisateurs qui sont intéressés par un besoin donné.

- Les utilisateurs qui maintiennent le système.

- Les ressources externes du système.


29

- Les autres systèmes qui devront interagir avec le système.

Les spécifications fonctionnelles que nous avons dégagées nous nous ont permises d’identifier

les acteurs principaux suivants :

Administrateur : Il est le super-utilisateur du système, il possède tous les droits et

privilèges. Il est chargé de paramétrer l’application en affectant les rôles aux différents

utilisateurs. Il se réserve aussi tous les droits d’ajout, de saisie, de mise à jour,

d’édition et de suppression des fiches des candidats, des tests et des entretiens.

Chargé Recrutement : Personne appartenant au processus« Ressources Humaines »

et à qui est offerte l’application en premier lieu. Le chargé recrutement ajoute et met à

jour les fiches des candidats ; planifie les tests et les entretiens, suit le Flux de travail

de Recrutement dans tous ses états.

Assistante de Direction : Personne appartenant au processus « Direction », et à

laquelle a été affectée une action. Cette personne aide ne peut que mettre à jour

l’action qui lui concerne.

Evaluateur : Cette personne a pour tâche d’évaluer le candidat lors de l’entretien, elle

ne peut que modifier la fiche de l’entretien.

Utilisateur : Cette personne doit pouvoir visualiser, une fois authentifiée, la liste des

candidats et les informations les concernant.

Et les acteurs secondaires suivants :

SGBD : Le système de gestion de base de données utilisé pour le stockage des

données manipulées. Le SGBD contient aussi la liste des utilisateurs qui manipulent

l’application et la nature de leur droit d’accès.


30

2.3.1 Diagramme du système « Flux de travail de Recrutement »

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<SGBD>

Oracle 8i

Administrateur

Chargé Recrutement

Assistante de Direction

Evaluateur

Utilisateur

Gerer les candidats

Consulter

Evaluer

S'authentifier

Gerer les Tests

Gerer les Entretiens

Parametrer l 'application

Figure 2.2 : Les cas utilisation du système « Flux de travail de Recrutement »

La relation entre les différents acteurs est une relation de généralisation, ceci implique

l’héritage des cas d’utilisations entre acteurs :

- L’acteur « Utilisateur » : ne peut que consulter l’application.

- L’acteur « Evaluateur » : Il ne peut que modifier la fiche entretien.

- L’acteur « Assistante de Direction » : Gérer les tests en plus des cas d’utilisation

précédemment expliqués avec l’ « Utilisateur ».

- L’acteur « Chargé Recrutement » : Il un rôle fondamentale il gère le candidat, les

tests et les entretiens.

- L’acteur « Administrateur » : c’est le super utilisateur, il peut tout faire ainsi que le

paramétrage de l’application.

Les différents cas d’utilisation seront détaillés par acteur dans la partie suivante.


31

2.3.3 Cas de l’acteur « Chargé Recrutement »

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

Chargé Recrutement

Recherche Candidat

Creer Candidat

Planifier Test

Réaliser Test

Planifier Entretien

Réaliser Entretien

Décision Candidat

Modifier Canddiat

Supprimer Candidat

Annuler Test

Annuler Entretien

Gérer Candidat

Gérer Test

Gérer Entretien

Figure 2.3 : Cas d’utilisation de l’acteur « Chargé Recrutement »

Description

Après son authentification, le « Chargé Recrutement » est responsable de

- Gérer le candidat

Créer le candidat


32

Modifier le candidat

Rechercher le candidat

Supprimer le candidat

Décision du candidat : il s’agit en effet du statut du candidat à savoir pour

test, pour entretien, retenu à chaud, recruté, rejeté.

- Gérer le test

Planifier test

Réalisation test

Annuler test

- Gérer l’entretien

Planifier entretien

Réalisation entretien

Annuler entretien


33

2.3.4 Cas de l’acteur « Assistante de Direction »

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

Assistante de Direction

Recherche Candidat

Creer Candidat

Planifier Test

Réaliser Test

Annuler Test

Gérer Candidat

Gérer Test

Figure 2.4 : Cas d’utilisation de l’acteur « Assistante de Direction »

Apres son authentification, l’assistante de direction est responsable de :

- Gérer candidat

Créer candidat.

Recherche candidat.

- Gérer test

Planifier test.

Réaliser test.

Annuler test.


34

2.3.5 Cas de l’acteur « Administrateur »

<<include>>

<<include>>Administrateur

Attribuer les autorisations aux profils

Creer les autorisations

Gérer les autorisations

Figure 2.5 : Cas d’utilisation de l’acteur « Administrateur »

Description du Cas d’Utilisation « Gérer autorisations »

L’administrateur se charge d’attribuer des autorisations aux personnes concernées qui

accèdent à l’application.

L’administrateur a aussi tous les droits qu’a le chargé recrutement.

3. Vue Dynamique : Diagramme d’activités

Les diagrammes d’activités [10] permettent de mettre l’accent sur les traitements. Ils

sont adaptés à la modélisation du cheminement de flots de contrôle et de flots de données. Ils

permettent ainsi de représenter graphiquement le comportement d’une méthode ou le

déroulement d’un cas d’utilisation. Dans ce qui suit nous allons présenter le diagramme

d’activité du Flux de travail de Recrutement.


35

3.1 Diagramme d’activité : Flux de travail de Recrutement

[Expérience > 3]

[Expérience < 3]

[Test Réussi]

[Candidat pour Entretien][Test echoué]

[CV rejeté]

Creer Candidat

Décision CVRéaliser Test

Réaliser EntretienDécision Test

Décision Entretien

Recruter CandidatPlacer Candidat Retenu à Chaud

Rejeter Candidat sur CV

Rejeter Candidat sur Entretien

Rejeter Candidat sur Test

Figure 2.6 : Diagramme d’activité : Flux de travail de Recrutement

Description :

Ce diagramme d’activité (figure 2.6) représente le diagramme d’activité du flux de travail de

recrutement.

Apres la création du candidat, une opération de filtrage de cv se fait pour choisir les candidats

les plus adéquats aux différents profils proposés par OXIA. Suivant le nombre d’années

d’expérience, le candidat est soit mis dans le panier pour test, soit pour entretien.

Si le candidat réussi le test, il est mis pour entretien.

Apres chaque entretien, une note est donné au candidat et une décision est prise ; le candidat

est donc soit redirigé une autre fois vers un autre entretien, soit rejeté, soit mis à chaud, soit

recruté.


36

Conclusion

Dans ce chapitre, nous avons passé en revue les différents besoins exprimés par l’entreprise.

Cela nous a permis de définir la spécification fonctionnelle et non fonctionnelle du système

visé. Dans une deuxième partie, nous avons présenté la phase d’analyse qui nous a conduits à

élaborer les diagrammes de cas d’utilisations ainsi que le diagramme d’activité du flux de

travail du recrutement. Dans le chapitre suivant nous allons concevoir notre système en se

basant sur le langage de modélisation UML.

37

CHAPITRE 3

CONCEPTION DE LA SOLUTION

Chapitre 3 : CONCEPTION

38

Introduction

Dans le présent chapitre, on se base sur le langage UML pour la conception de notre

système d’information. Pour commencer, nous présenterons une conception générale du

système contenant le digramme des classes du système. Ensuite, nous passerons à une

spécification détaillée des fonctionnalités que le système doit assurer contenant l’ensemble

des digrammes de séquences présentant les principales fonctions du système.

1. Vue statique : Diagramme de Classe

Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et

les interfaces d'un système ainsi que les différentes relations entre celles-ci. Ce diagramme

fait partie de la partie statique d'UML car il fait abstraction des aspects temporels et

dynamiques.

Une classe décrit les responsabilités, le comportement et le type d'un ensemble d'objets. Les

éléments de cet ensemble sont les instances de la classe. C’est aussi un ensemble de fonctions

et de données (attributs) qui sont liées ensembles par un champ sémantique. Les classes sont

utilisées dans la programmation orientée objet. Elles permettent de modéliser un programme

et ainsi de découper une tâche complexe en plusieurs petits travaux simples.


39

0..

11

..1

0..

11

..1

1..

1

0..

*

0..

10

..*

1..

1

0..

*

1..

1

0..

*

1..

1

0..

*

1..

1

0..

*

1..

1

0..

*

1..

1

0..

*

0..

10

..*

0..

10

..* 0..

1

0..

*

1..

1

0..

*

1..

*

0..

*

1..

*

0..

*

1..

*

1..

*

1..

*

0..

*

1..

1

0..

*

0..

*

1..

1

Ca

nd

ida

t

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

id_

ca

nd

ida

t

em

ail

_ca

nd

ida

t

pre

no

m_

ca

nd

iat

no

m_

ca

nd

ida

t

sta

tut_

ca

nd

ida

t

sou

rce

_ca

nd

ida

t

CV

_ca

nd

ida

t

Le

ttre

Mo

tiva

tio

n_

ca

nd

ida

t

Da

teN

ais

san

ce

Lie

uN

ais

san

ce

sexe

situ

atu

tio

nfa

mil

le

CIN

_ca

nd

ida

t

Te

lep

ho

ne

1

Te

lep

ho

ne

2

Bu

lle

tin

Ad

ress

e

Ba

c

An

ne

Ba

c

Mo

ye

nn

eB

ac

No

teM

ath

Ba

c

No

teP

hysi

qu

eB

ac

No

teP

hil

oB

ac

No

teF

ran

ça

isB

ac

De

bu

tExp

eri

en

ce

Nb

An

ne

eE

xp

eri

en

ce

Sta

ge

Oxia

SIV

P

Da

teC

rea

tio

nC

an

did

at

: d

ecim

al

: st

rin

g

: st

rin

g

: st

rin

g

: st

rin

g

: st

rin

g

: b

yte

: b

yte

: D

ate

Tim

e

: st

rin

g

: st

rin

g

: st

rin

g

: in

t

: in

t

: in

t

: st

rin

g

: st

rin

g

: st

rin

g

: in

t

: fl

oa

t

: fl

oa

t

: fl

oa

t

: fl

oa

t

: fl

oa

t

: D

ate

Tim

e

: in

t

: st

rin

g

: st

rin

g

: D

ate

Tim

e

Use

r

- - - - - -

use

r_id

no

m

pre

no

m

pa

ssw

ord

pro

fil_

id

em

ail

: st

rin

g

: st

rin

g

: st

rin

g

: st

rin

g

: in

t

: st

rin

g

Sta

ge

- - - - - -

id_

sta

ge

suje

t_st

ag

e

typ

e_

sta

ge

socie

te_

sta

ge

da

ted

eb

ut_

sta

ge

da

tefi

n_

sta

ge

: in

t

: st

rin

g

: st

rin

g

: st

rin

g

: D

ate

Tim

e

: D

ate

Tim

e

Re

fere

nce

- - - - - -

id_

refe

ren

ce

no

m_

refe

ren

ce

socie

te_

refe

ren

ce

em

ail

_re

fere

nce

tele

ph

on

e_

refe

ren

ce

pre

no

m_

refe

ren

ce

: in

t

: st

rin

g

: st

rin

g

: st

rin

g

: in

t

: st

rin

g

Ce

rtif

ica

tio

n

- - - - -

id_

ce

rtif

ica

tio

n

Ca

teg

ori

e_

ce

rtif

ica

tio

n

Co

de

_ce

rtif

ica

tio

n

Att

ach

e_

ce

rtif

ica

tio

n

Typ

e_

ce

rtif

ica

tio

n

: in

t

: st

rin

g

: in

t

: st

rin

g

: st

rin

g

Pro

fil

- -

id_

Pro

fil

de

scri

pti

on

_p

rofi

l

: d

ecim

al

: st

rin

g

Eva

lua

teu

r_E

xte

rne

- - - - -

Eva

lua

teu

rExte

rne

_id

No

m_

Eva

lExte

rne

Pre

no

m_

Eva

lExte

rne

En

tre

pri

seE

va

lExte

rne

Po

ste

Eva

lExte

rne

: d

ecim

al

: st

rin

g

: st

rin

g

: st

rin

g

: st

rin

g

BA

- - - -

bA

_Id

de

scri

pti

on

BA

ab

revia

tio

nB

A

dir

ecte

urB

A

: in

t

: st

rin

g

: st

rin

g

: U

ser

BU

- - - -

bU

_Id

de

scri

pti

on

BU

ab

revia

tio

nB

U

dir

ecte

urB

U

: in

t

: st

rin

g

: st

rin

g

: U

ser

En

tre

tie

n

- - - - - - - - -

en

tre

tie

nid

da

tee

ntr

eti

en

lie

ue

ntr

eti

en

he

ure

En

tre

tie

n

Sta

tutE

ntr

eti

en

No

teE

ntr

eti

en

Re

ma

rqu

esE

ntr

eti

en

De

cis

ion

En

tre

tie

n

Da

teP

lan

ific

ati

on

En

tre

tie

n

: d

ecim

al

: D

ate

Tim

e

: st

rin

g

: T

ime

Sp

an

: st

rin

g

: st

rin

g

: st

rin

g

: st

rin

g

: D

ate

Tim

e

Dip

lom

e

- - - - -

id_

dip

lom

e

No

m_

dip

lom

e

Inst

itu

tio

n_

dip

lom

e

An

ne

e_

dip

lom

e

Pa

ys_

dip

lom

e

: in

t

: st

rin

g

: st

rin

g

: in

t

: st

rin

g

Te

st

- - - - - - - - - -

id_

test

typ

e_

test

Da

te_

test

lie

u_

test

he

ure

_te

st

sta

tut_

test

rem

arq

ue

s_te

st

no

te_

test

an

ima

teu

r_te

st

Da

teP

lan

ific

ati

on

Te

st

: d

ecim

al

: st

rin

g

: D

ate

Tim

e

: st

rin

g

: T

ime

Sp

an

: st

rin

g

: st

rin

g

: in

t

: U

ser

: D

ate

Tim

e

Mo

tsC

les

- -

id_

mo

tscle

s

de

scri

pti

on

_m

ots

cle

s

: in

t

: st

rin

g

Off

reC

an

did

at

- - - -

Da

teE

ntr

ée

So

ua

ité

e

Da

teE

ntr

ée

Co

nfi

rmé

e

Ca

nd

ida

t

Cre

ate

urO

ffre

: D

ate

Tim

e

: D

ate

Tim

e

: C

an

did

at

: U

ser

Eva

lua

teu

rIn

tern

e

-P

ost

e:

stri

ng

Figure 3.1 : Diagramme de classe : Flux de travail de Recrutement


40

Description du diagramme de classe

La classe Candidat

Elle définit le candidat par son identifiant, nom, prénom, date de naissance, lieu de naissance,

sexe, CIN email, statut, source, cv, lettre de motivation et d’autres attributs.

Cette classe est lié à la classe User afin de préciser l’utilisateur qui a créé le candidat ; elle est

également lié à la classe diplôme, stage, référence, certification, mots clés, offre candidat,

profils, test et entretien.

La classe User

Elle définit l’utilisateur OPM (OXIA Project Manager) à travers user_id, nom, prénom,

password, profil_id et email. La table qui représente cette classe existe déjà dans la base de

données de OXIA.

La classe Test

Elle définit le Test que subit le candidat au cours du flux de travail de recrutement et cela par

un id, type, date, lieu, statut, remarques, note, animateur et date de planification. Elle est en

liaison avec la classe Candidat et la classe User pour préciser l’utilisateur qui planifie le Test

ainsi que l’animateur du Test.

La classe Entretien

Elle définit l’entretien que subit le candidat au cours du flux de travail de recrutement et cela

par un id, date, lieu, statut, note, remarques, décision et date de planification. Elle est en

liaison avec la classe Candidat, Evaluateur interne et Evaluateur externe.

La classe EvaluateurInterne

La classe EvaluateurInterne hérite de la classe User car l’évaluateur interne est un utilisateur

de OXIA. On lui ajoute l’attribut poste.

La classe EvaluateurExterne

Elle est définit par un id, nom, prénom, entreprise et poste. Elle est en liaison avec la classe

Entretien.


41

La classe MotsCles

Elle est définit par id et description. Elle est en liaison avec la classe Candidat. Elle représente

les mots clés du candidat.

La classe Diplôme

Elle définit les diplômes du candidat par un id, nom, institution, année et pays.

La classe Certification

Elle définit les certifications du candidat par un id, catégorie, code, type et un booléen pour

voir si la certification est attachée ou pas au compte OXIA.

La classe Reference

Elle définit les références du candidat par id, nom, prénom, société, email et téléphone.

La classe Stage

Elle définit les stages du candidat par id, sujet, type, société, date début et date fin du stage.

La classe OffreCandidat

Elle définit l’offre du candidat, les attributs sont date entrée souhaitée, date entrée confirmée,

candidat et créateur. Elle est en liaison avec la classe Candidat et la classe User.

La classe BA

Elle définit la classe BA(Business Area) par un BA_id, descriptionBA, abreviationBA et

directeurBA. La table qui représente cette classe existe déjà dans la base de données de

OXIA.

La classe BU

Elle définit la classe BU (Business Unit) par un BU_id, descriptionBU, abreviationBU. La

table qui représente cette classe existe déjà dans la base de données de OXIA.

La classe Profil

Elle définit les profils potentiels que peut avoir le candidat, ces profils sont selon les BA BU.


42

2. Diagramme de séquence

Les diagrammes de séquences sont la représentation graphique des interactions entre les

acteurs et le système selon un ordre chronologique dans la formulation UML (Unified

Modeling Language).

On montre ces interactions dans le cadre d'un scénario d'un diagramme des cas d'utilisation.

Dans un souci de simplification, on représente l'acteur principal à gauche du diagramme, et

les acteurs secondaires éventuels à droite du système. Le but étant de décrire comment se

déroule les actions entre les acteurs ou objets.

Plusieurs types de messages (actions) peuvent transiter entre les acteurs et objets :

Message simple : le message n'a pas de spécificité particulière d'envoi et de réception.

Message avec durée de vie : l'expéditeur attend une réponse du récepteur pendant un

certain temps et reprend ses activités si aucune réponse n'a lieu dans un délai prévu.

Message synchrone : l'expéditeur est bloqué jusqu'au signal de prise en compte par le

destinataire. Les messages synchrones sont symbolisés par des flèches barrées.

Message asynchrone : le message est envoyé, l'expéditeur continue son activité que le

message soit parvenu ou pris en compte ou non. Les messages asynchrones sont

symbolisés par des demi-flèches.

Par la suite, on va choisir les scénarios les plus importants et on va les modéliser par des

diagrammes de séquences.


43

2.1. Diagramme de séquence Framework

2.1.1. Diagramme de séquence : Administrateur Recrutement

Figure 3.2 : Diagramme de séquence : Administration


44

Acteur : Administrateur.

But : Paramétrage du workflow Recrutement.

Enchaînement nominal :

L’administrateur introduit les paramètres souhaités : les autorisations par rôle et les acteurs de

l’application.

Ces paramètres passent par les différentes couches de l’application.

En effet, à partir de l’interface de paramétrage les données passent par la classe

« RecrutementProcessComponent »s dans la couche « UIProcessComponents », par la suite,

par la couche service WCF. Ils passent après par la classe

« ParametrageBusinessComponent » dans la couche « BusinessComponent », enfin par la

classe « ParametrageDAO » pour lancer la requête vers la base de données.

La requête s’effectue avec sucée, un « MessageBox » s’affiche à l’utilisateur indiquant le

succès de l’opération.

Enchaînement Alternatif :

Dans le cas où la requête échoue, un « MessageBox » s’affiche à l’utilisateur indiquant que

l’opération a échoué.


45

2.3. Diagramme de séquence Workflow Recrutement

2.3.1. Diagramme de séquence : Authentification

Co

uch

e

Se

rvic

e W

CF

Intr

od

uir

e (

log

in,p

ass

wo

rd)

Ge

tUse

rById

BC

(lo

gin

,pa

ssw

ord

)

Ge

tUse

rById

(lo

gin

,pa

ssw

ord

)

Exé

cu

tio

n R

eq

ue

te S

ele

ct(

)

Ve

rifi

ca

tio

n

Au

the

nti

fica

tio

n R

éu

ssie

Au

the

nti

fica

tio

n R

éu

ssie

Au

the

nti

fica

tio

n R

éu

ssie

Au

the

nti

fica

tio

n E

ch

ou

ée

Au

the

nti

fica

tio

n E

ch

ou

ée

Au

the

nti

fica

tio

n E

ch

ou

ée

Ge

tUse

rbyID

PC

(lo

gin

,pa

ssw

ord

)

Ge

tUse

rById

S(l

og

in,p

ass

wo

rd)

Au

the

nti

fica

tio

n R

éu

ssie

Au

the

nti

fica

tio

n R

éu

ssie

Au

the

nti

fica

tio

n E

ch

ou

ée

Au

the

nti

fica

tio

n E

ch

ou

ée

Uti

lisa

teu

r

Ecra

n A

uth

en

tifi

ca

tio

nS

GB

D:S

erv

ice

Au

ten

tifi

ca

tio

n:A

uth

en

tifi

ca

tio

n B

usi

ne

ss C

om

po

ne

nt

:Use

rDA

O:A

uth

en

tifi

ca

tio

nP

roce

ssC

om

po

ne

nt

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n E

ch

ou

ée

alt

Intr

od

uir

e (

log

in,p

ass

wo

rd)

Ge

tUse

rById

BC

(lo

gin

,pa

ssw

ord

)

Ge

tUse

rById

(lo

gin

,pa

ssw

ord

)

Exé

cu

tio

n R

eq

ue

te S

ele

ct(

)

Ve

rifi

ca

tio

n

Au

the

nti

fica

tio

n R

éu

ssie

Au

the

nti

fica

tio

n R

éu

ssie

Au

the

nti

fica

tio

n R

éu

ssie

Au

the

nti

fica

tio

n E

ch

ou

ée

Au

the

nti

fica

tio

n E

ch

ou

ée

Au

the

nti

fica

tio

n E

ch

ou

ée

Ge

tUse

rbyID

PC

(lo

gin

,pa

ssw

ord

)

Ge

tUse

rById

S(l

og

in,p

ass

wo

rd)

Au

the

nti

fica

tio

n R

éu

ssie

Au

the

nti

fica

tio

n R

éu

ssie

Au

the

nti

fica

tio

n E

ch

ou

ée

Au

the

nti

fica

tio

n E

ch

ou

ée

Figure 3.3 : Diagramme de séquence : Authentification


46

Acteur : Utilisateur.

But : S’authentifier par un login et un password.


1. Consulter l’application.

2. Introduire le login et le password.

3. Vérifier le login et le password dans la base de données en passant par les différentes

couches de l’application.

4. Accepter le login et le password


Le système cherche dans la base de données, ne trouve pas de correspondance et retourne à

l'utilisateur un message d'erreur.


47

2.3.2. Diagramme de séquence : Chargé Recrutement

2.3.2.1 Insertion Candidat C

ou

ch

e

Wo

rkfl

ow

WF

Inse

rtio

nC

an

did

at(

)

Se

nd

Re

ply

Ca

nd

ida

t()

Inse

rtC

an

did

atD

AO

()

Exé

cu

tio

n R

eq

ue

te I

nse

rt()

Inse

rtio

n R

éu

ssie

Inse

rtio

n R

éu

ssie

Re

ce

ive

Ca

nd

ida

t()

Inse

rtio

n E

ch

ou

ée

Inse

rtio

n E

ch

ou

ée

Inse

rtio

n E

ch

ou

ée

Inse

rtC

an

did

atP

C()

Inse

rtC

an

did

atS

()

Inse

rtio

n R

éu

ssie

Inse

rtio

n R

éu

ssie

Inse

rtio

n E

ch

ou

ée

Inse

rtio

n E

ch

ou

ée

ch

arg

é r

ecru

tem

en

t

SG

BD

:UI

Ca

nd

ida

t:W

ork

Flo

w R

ecru

tem

en

t:C

an

did

at

Bu

sin

ess

Co

mp

on

en

ts:C

an

did

at

DA

O:R

ecru

tem

en

tPro

ce

ssC

om

po

ne

nts

Inse

rtio

n R

éu

ssie

Inse

rtio

n E

ch

ou

ée

alt

Inse

rtio

nC

an

did

at(

)

Se

nd

Re

ply

Ca

nd

ida

t()

Inse

rtC

an

did

atD

AO

()

Exé

cu

tio

n R

eq

ue

te I

nse

rt()

Inse

rtio

n R

éu

ssie

Inse

rtio

n R

éu

ssie

Re

ce

ive

Ca

nd

ida

t()

Inse

rtio

n E

ch

ou

ée

Inse

rtio

n E

ch

ou

ée

Inse

rtio

n E

ch

ou

ée

Inse

rtC

an

did

atP

C()

Inse

rtC

an

did

atS

()

Inse

rtio

n R

éu

ssie

Inse

rtio

n R

éu

ssie

Inse

rtio

n E

ch

ou

ée

Inse

rtio

n E

ch

ou

ée

Figure 3.4 : Diagramme de séquence : Insertion Candidat


48

Acteur : Chargé Recrutement.

But : Insérer un candidat.


La chargée recrutement introduit les informations concernant le candidat : nom, prénom, date

de naissance, diplôme, etc…

Ces informations seront stockés dans l’entité business « Candidat » de la couche

« BusinessEntities », ensuite, l’entité candidat passera par les différentes couches de

l’application dont la couche Workflow qui assurera le dialogue avec la couche DAO et la base

de donnée.

En effet, à partir de l’interface d’insertion les données passent par la classe

« RecrutementProcessComponents » dans la couche « UIProcessComponents », par la suite,

par la couche Workflow service WF. Ils passent après par la classe

« CandidatBusinessComponent » dans la couche « BusinessComponent », enfin par la classe

« CandidatDAO » pour lancer la requête insert vers la base de données.





l’opération a échoué


49

2.3.2.2 Affichage Candidat

Co

uch

e

Se

rvic

e W

CF

Aff

ich

erC

an

did

at(

)

Aff

ich

erC

an

did

atB

C()

Aff

ich

erC

an

did

atD

AO

()

Exé

cu

tio

n R

eq

ue

te S

ele

ct(

)

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n E

ch

ou

ée

Op

éra

tio

n E

ch

ou

ée

Op

éra

tio

n E

ch

ou

ée

Aff

ich

erC

an

did

atP

C()

Aff

ich

erC

an

did

atS

()

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n E

ch

ou

ée

Op

éra

tio

n E

ch

ou

ée

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n R

éu

ssie

ch

arg

é r

ecru

tem

en

t

SG

BD

:UI

Ca

nd

ida

t:S

erv

ice

Re

cru

tem

en

t:C

an

did

at

Bu

sin

ess

Co

mp

on

en

t:C

an

did

at

DA

O:R

ecru

tem

en

tPro

ce

ssC

om

po

ne

nts

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n E

ch

ou

ée

alt

Aff

ich

erC

an

did

at(

)

Aff

ich

erC

an

did

atB

C()

Aff

ich

erC

an

did

atD

AO

()

Exé

cu

tio

n R

eq

ue

te S

ele

ct(

)

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n E

ch

ou

ée

Op

éra

tio

n E

ch

ou

ée

Op

éra

tio

n E

ch

ou

ée

Aff

ich

erC

an

did

atP

C()

Aff

ich

erC

an

did

atS

()

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n E

ch

ou

ée

Op

éra

tio

n E

ch

ou

ée

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n R

éu

ssie

Figure 3.5 : Diagramme de séquence : Affichage Candidat


50


But : Afficher le candidat.


La chargée recrutement choisit le type d’affichage de la liste des candidats par statut :

candidat soumis, pour test, pour entretien, retenu à chaud, pour décision, recruté, rejeté ou

tous les candidats.

Pour afficher la liste des candidats, cette demande doit passer par les différentes couches de

l’application.

En effet, à partir de l’interface de présentation, les données passent par la classe


par la couche service WCF. Ils passent après par la classe « CandidatBusinessComponent »

dans la couche « BusinessComponent », enfin par la classe « CandidatDAO » pour lancer la

requête insert vers la base de données.







51

2.3.2.3 Planification Entretien

Co

uch

e

Wo

rkfl

ow

WF

Pla

nif

ierE

ntr

eti

en

()

Inse

rtC

an

did

atB

C()

Inse

rtC

an

did

atD

AO

()

Exé

cu

tio

n R

eq

ue

te I

nse

rt()

Inse

rtio

n R

éu

ssie

Inse

rtio

n R

éu

ssie

Inse

rtio

n R

éu

ssie

Inse

rtio

n E

ch

ou

ée

Inse

rtio

n E

ch

ou

ée

Inse

rtio

n E

ch

ou

ée

Inse

rtC

an

did

atP

C()

Inse

rtC

an

did

atS

()

Inse

rtio

n R

éu

ssie

Inse

rtio

n R

éu

ssie

Inse

rtio

n E

ch

ou

ée

Inse

rtio

n E

ch

ou

ée

ch

arg

é r

ecru

tem

en

t

SG

BD

:UI

En

tre

tie

n:W

ork

flo

w R

ecru

tem

en

t:E

ntr

eti

en

Bu

sin

ess

Co

mp

on

en

t:E

ntr

eti

en

DA

O:R

ecru

tem

en

tPro

ce

ssC

om

po

ne

nts

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n E

ch

ou

ée

alt

Pla

nif

ierE

ntr

eti

en

()

Inse

rtC

an

did

atB

C()

Inse

rtC

an

did

atD

AO

()

Exé

cu

tio

n R

eq

ue

te I

nse

rt()

Inse

rtio

n R

éu

ssie

Inse

rtio

n R

éu

ssie

Inse

rtio

n R

éu

ssie

Inse

rtio

n E

ch

ou

ée

Inse

rtio

n E

ch

ou

ée

Inse

rtio

n E

ch

ou

ée

Inse

rtC

an

did

atP

C()

Inse

rtC

an

did

atS

()

Inse

rtio

n R

éu

ssie

Inse

rtio

n R

éu

ssie

Inse

rtio

n E

ch

ou

ée

Inse

rtio

n E

ch

ou

ée

Figure 3.6 : Diagramme de séquence : Planification Entretien


52


But : Planifier un Entretien.


La chargée recrutement introduit les informations nécessaires à la planification de l’entretien :

candidat, date, heure, lieu et évaluateur.

La planification est en fait l’insertion de nouvel entretien dans la base de donnée, pour ce

faire, un passage par toutes les couches de l’application est obligatoire surtout le passage par

la couche Workflow Service WF qui va créer une instance du workflow sur laquelle va se

faire le flux du travail.

En effet, à partir de l’interface de planification, les données passent par la classe


par la couche workflow service WF. Ils passent après par la classe

« EntretienBusinessComponent » dans la couche « BusinessComponent », enfin par la classe

« EntretienDAO » pour lancer la requête insert vers la base de données.







53

2.3. Diagramme de séquence : Evaluateur

Co

uch

e

Wo

rkfl

ow

WF

Ré

ali

sati

on

En

tre

tie

n()

Se

nd

Re

ply

En

tre

tie

n()

Mo

dif

ierE

ntr

eti

en

DA

O()

Exé

cu

tio

n R

eq

ue

te U

pd

ate

()

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n R

éu

ssie

Re

ce

ive

En

tre

tie

n()

Op

éra

tio

n E

ch

ou

ée

Op

éra

tio

n E

ch

ou

ée

Op

éra

tio

n E

ch

ou

ée

Mo

dif

ierE

ntr

eti

en

PC

()

Mo

dif

ierE

ntr

eti

en

S()

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n E

ch

ou

ée

Op

éra

tio

n E

ch

ou

ée

Eva

lua

teu

r

SG

BD

:UI

Fic

he

En

tre

tie

n:W

ork

flo

w R

ecru

tem

en

t:E

ntr

eti

en

Bu

sin

ess

En

titi

es

:En

tre

tie

nD

AO

:Re

cru

tem

en

tPro

ce

ssC

om

po

ne

nts

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n E

ch

ou

ée

alt

Ré

ali

sati

on

En

tre

tie

n()

Se

nd

Re

ply

En

tre

tie

n()

Mo

dif

ierE

ntr

eti

en

DA

O()

Exé

cu

tio

n R

eq

ue

te U

pd

ate

()

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n R

éu

ssie

Re

ce

ive

En

tre

tie

n()

Op

éra

tio

n E

ch

ou

ée

Op

éra

tio

n E

ch

ou

ée

Op

éra

tio

n E

ch

ou

ée

Mo

dif

ierE

ntr

eti

en

PC

()

Mo

dif

ierE

ntr

eti

en

S()

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n R

éu

ssie

Op

éra

tio

n E

ch

ou

ée

Op

éra

tio

n E

ch

ou

ée

Figure 3.7 : Diagramme de séquence : Réalisation Entretien


54

Acteur : Evaluateur.

But : Réaliser un Entretien.


L’évaluateur introduit les informations nécessaires à la fiche de l’entretien ainsi que la note

qu’il a attribué au candidat.

L’évaluation est en fait la modification d’un entretien existant dans la base de données.

Néanmoins, on doit passer par toutes les couches de l’application pour faire les modifications

nécessaires.

En effet, à partir de l’interface de réalisation de l’entretien, les données passent par la classe


par la couche service WCF. Ils passent après par la classe « EntretienBusinessComponent »

dans la couche « BusinessComponent », enfin par la classe « EntretienDAO » pour lancer la

requête insert vers la base de données.





l’opération a échoué

Conclusion

Dans ce chapitre, nous avons réalisé les principaux diagrammes représentatifs du déroulement

de notre application ainsi que ses aspects statiques et comportementaux. Ceci nous a permis

de déterminer la façon à travers laquelle nous allons réaliser une application répondant aux

besoins déjà spécifiés.

Dans le chapitre suivant nous présenterons les étapes de réalisation de notre application ainsi

que quelques interfaces représentatives de notre travail.

55

CHAPITRE 4

REALISATION

Chapitre 4 : REALISATION

Introduction

Après l’étude conceptuelle du système, nous passons à l’étape suivante; celle du

développement. Nous commençons par présenter les outils matériels et logiciels qui nous

ont permis de développer notre système, ensuite nous allons présenter une vue globale sur

ce dernier, et enfin une présentation de ses principales fenêtres.

1. Présentation de l’architecture

1.1 Choix de l’architecture

Pour la conception de l’architecture, nous avons suivi le guide des bonnes pratiques de

Microsoft pour la conception des architectures d’applications [11]. L’architecture suivante

(figure 4.1) présente le modèle de référence exhaustive pour toute application à développer

avec le langage .NET.

Figure 4.1 : Architecture commune d’une application


57

1.2 Structure de l’application

Parmi toutes ces couches, pour le besoins de notre application, nous avons implémenté les

couches suivantes :

Presentation Layer

Service Layer

Business Layer

Data Layer

Framework.

Figure 4.2 : Structure en couche du Framework OXIADOTNET

1.2.1 Présentation Layer

La couche Présentation est constituée de deux composants :

UI Components : C'est le composant visuel de l'interface. Elle permet d'afficher les

informations à l'utilisateur. Ce sont par exemple les pages ASP.NET, les WinForms, dans

notre cas des interfaces conçues en WPF.


58

UI Process Components : Il permet dans la plupart des cas, l'interaction de l'utilisateur avec le

système qui suit un processus connu. Par exemple, l'utilisateur va choisir une catégorie de

produits avant de sélectionner un produit particulier dans cette liste.

1.2.2 Service Layer

Service Interfaces : Ce composant ouvre le logique métier du système en exposant les services

disponibles. C'est grâce à cette interface qu'on va pouvoir " attaquer " le cœur de l'application.

Cette interface définit les modèles de communication en tenant compte des formats de

données, des exceptions. Dans notre cas, nous avons exposé les services à travers une couche

de communication WCF.

1.2.3. Business Layer

Business Components: Ce composant implémente les règles métier. C’est ici où est

implémenter la logique du métier.

Business Entity: Les composants de l'application doivent pouvoir s'échanger des données. Cet

échange peut se faire par différents formats. Cela peut être des données sérialisés (DataSets,

DataReaders, XML...) ou directement des classes. Ces classes sont appelées aussi POCO,

elles sont sollicitées partout dans l’application.

1.2.4. Data Layer

Data Access Components : C’est le composant qui accède directement à la base de données.

Nous l’avons conçu selon le patron de conception DAO. Il contient les requêtes SQL

permettant de manipuler les données de la base de données.

1.2.5. Framework

Cette dernière couche contient toutes les fonctionnalités propriétaires à notre

application : Contrôles, fonction d’aide à la saisie, gestionnaire d’exceptions, gestionnaire de

journalisation…

1.3 Schéma de dépendance entre couches

Le schéma suivant (figure 4.3) met en évidence la dépendance entre couches lors de la

conception de l’application.


59

Figure 4.3 : Schéma de dépendance entre couches

La liaison entre les différentes couches : (flèche « Référence ») est utilisée pour

décrire les interdépendances entre couches.

Exemple : la couche « Business Components » référence la couche « Business

Entities ».

La couche « Business Entities » contient les entités utilisées partout dans le système.

C’est pourquoi elle est référencée par toutes les autres couches.

La couche « Business Components » contient les classes métier de notre application.

Scénario : obtenir les informations d’un test.

La classe concernée au niveau de la couche « Business Components » : TestBC. Cette classe

a besoin des entités candidat, Test, User se trouvant au niveau de la couche « Business

Entities », d’où l’importance du référencement.


60

2. Environnement de développement

2.1. Environnement matériel

L’environnement matériel qu’on a utilisé se présente comme suit :

Processeur : Intel® Dual Core CPU T2080 @ 1.73 GHz

Mémoire RAM : 3 Go

Disque Dur : 120 Go

Carte Graphique : Mobile Intel 45 Express Chipset Family

Système d’Exploitation : MS Windows SEVEN 32-bit.

2.2. Environnement logiciel

2.2.1 Framework utilisé

.NET Framework 4.0

Figure 4.4 : Logo Microsoft .NET

Le Framework .NET est un produit Microsoft, société avec laquelle OXIA est

partenaire. Ce choix rentre dans une stratégie d’entreprise désirant implémenter entièrement

son système d’information à base de Framework .NET. Notre projet constitue ainsi un projet

pilote pour d’autres entreprises de plus grande taille.

Le choix s’est porté sur la version 4.0.Microsoft a annoncé la version 4 du Framework

.NET le 12 avril. Cette version offre comme nouveautés :

Autorisations des paramètres nommés et optionnels


61

Prise en charge totale des langages IronPython, IronRuby et F #.

Prise en charge d’un sous-ensemble du Framework .NET et ASP.NET avec la variante

"Server Core" de Windows Server 2008 R2.

Intégration de la plate-forme de modélisation Oslo.

Inclusion de nouveaux types de travailler avec précision arbitraire arithmétique

(System.Numerics.BigInteger) et les nombres complexes

(System.Numerics.Complex).

Microsoft Enterprise Library 5.0

Figure 4.5 : Logo Microsoft Entreprise Library 5.0

Enterprise Library [12] est un Framework contenant plusieurs blocs d'application. Ils

permettent de résoudre les problèmes courants auxquels on est confronté lorsqu'on développe

un projet. Les applications blocs encapsulent les méthodes de développement recommandées

par Microsoft (" best practices "). Enterprise Library contient 6 blocks d'application :

Caching

Cryptography

Data Access

Exception Handling

Logging

Security

Enterprise Library inclut également un ensemble de fonctions fondamentales, notamment

des services de configuration, d'instrumentation et de création d'objets. Ces fonctions sont

utilisées par tous les autres blocs d'application.


62

Il y a plusieurs avantages à utiliser le Framework Enterprise Library :

Uniformité : Tous les blocs d'application utilisent les design patterns.

Extensibilité : Les blocs d'application permettent d'être personnalisés en offrant la

possibilité d'ajouter du code dans les classes fournies.

Facile d'utilisation : Enterprise Library contient un outil graphique de configuration,

une installation simple, une documentation utilisateur et des exemples d'application.

Intégration : Les blocs d'application d'Enterprise Library sont conçus pour

communiquer ensemble.

Gratuité : Enterprise Library est redistribué gratuitement.

Pour le besoin de notre application nous avons utilisé tous les blocks sauf celui de

cryptographie :

Accès à la base de données (Block Data Access Application)

Gestion d’accès des utilisateurs par les autorisations (Block Security Application)

Gestion des exceptions (Block Exception Handling Application)

Journalisation des exceptions et des événements sur des fichiers (Block Logging

Application)

Enregistrement des données dans le cache de l’application (Block Caching

Application)

Le choix s’est porté sur la version 5 d’Enterprise Library car c’est la seule version qui

fonctionne avec le Framework .NET 4.0. Cette version d’Enterprise Library a été publiée le

20 Avril 2010.

2.2.2 Technologies de développement

WPF (Windows Presentation Foundation)

Windows Presentation Foundation (WPF) [13] est un sous-système graphique conçu pour le

rendu des interfaces utilisateur dans les applications basées sur Windows. Conçu pour


63

supprimer les dépendances sur le vieillissement du sous-système GDI, WPF est construit sur

DirectX, qui fournit l'accélération matérielle et permet les fonctions modernes de l'interface

utilisateur telles que la transparence, dégradés et transformations. WPF fournit un modèle de

programmation cohérent pour générer des applications et offre une séparation claire entre

l'interface utilisateur et le logique métier.

WPF offre également un nouveau langage de balisage, appelé XAML, qui est un autre

moyen pour définir les éléments d'interface utilisateur et les relations avec les autres éléments

de l’interface utilisateur. WPF peut être déployé sur le bureau ou hébergé dans un navigateur

web. Il permet également le contrôle riche, la conception et le développement des aspects

visuels de programmes Windows. Il vise à unifier un certain nombre de services applicatifs :

interface utilisateur, dessins 2D et 3D, documents fixes et adaptatives, typographie avancée,

graphiques vectoriels, raster graphique, animation, la liaison de données, audio et la vidéo.

WPF est inclus avec Windows 7, Windows Vista et Windows Server 2008 et est également

disponible pour Windows XP Service Pack 2 ou ultérieur et Windows Server 2003.

WCF (Windows Communication Foundation)

Windows Communication Foundation (WCF) [7] est la nouvelle technologie de

développement d’applications distribuées interopérables, fiables et sécurisées. L’objectif de

WCF est d’unifier les modes de communication que l’on a aujourd’hui à notre disposition

(services web, accès à distance, etc.) grâce à un nouveau modèle de programmation orienté

services.

WCF est utilisé dans notre application au niveau de la couche, son fonctionnement

consiste à implémenter des contrats de services permettant ainsi de relier la couche Business

Layer (Business Component) à la couche présentation (UI process Component).

WF4 (Windows Workflow Foundation)

Windows Workflow Foundation (WF) [8] est une technologie de Microsoft pour la

définition, l'exécution et la gestion des workflows. Tout d'abord, cette technologie a été

publiée en novembre 2006 dans le cadre du .NET Framework 3.0.


64

Un programme basique de workflow est comme les programmes traditionnels qui

permettent de coordonner les travaux et d'effectuer des opérations mais a quelques différences

près :

Les Workflows utilisent un modèle déclaratif d'écriture de programmes en reliant un

ensemble prédéfinies d'activités plutôt qu'un modèle de programmation impératif

d'écriture.

Les Workflows peuvent gérer un travail de longue durée par la persistance d’un

magasin durable, comme une base de données, lorsque inactif et se charger encore une

fois quand il y a du travail à effectuer.

Un Workflow peut être modifiée dynamiquement lors de l'exécution lorsque de

nouvelles conditions nécessitent qu’un workflow se comporte différemment que

lorsqu'il a été créé.

Les Workflows fournissent une séparation distincte des règles métier et de code de

l'application hôte, ce qui la rend plus facile à modifier.

Un Workflow prend en charge les workflows séquentiels pour les systèmes avec une

logique séquentielle et workflows de machine d'état pour les systèmes basés sur

l'événement logique.

Les Workflows ont généralement une contrepartie visuelle qui permet une description de

l'organigramme de leur logique

2.2.3 Langage de développement

Langage C#

Le C# (prononcé C-Sharp) est un langage de programmation orienté objet à typage

fort, créé par la société Microsoft, et notamment par l’un de ses employés, Anders Hejlsberg,

le créateur du langage Delphi.

Il a été créé afin que la plate-forme Microsoft .NET soit dotée d'un langage permettant

d'utiliser toutes ses capacités. C# 4.0 est la dernière version de la programmation langage C#,

elle a été publiée le 12 avril 2010.C’est la version que nous avons utilisé pour notre

développement.


65

Langage XAML

XAML [11] est un langage déclaratif basé sur le langage XML. Prononcé Zammel, ces

initiales correspondent à eXtensible Application MarkupLanguage.

XAML facilite le travail du développeur et permet d'écrire une application client

Windows aussi aisément qu'une application web. L'idée est en effet de séparer la déclaration

des objets d'un programme du code sous-jacent comme cela est déjà le cas dans les

applications Web de type ASP.NET.

Dans le cas de XAML pour WPF, le développement de l'interface utilisateur étant

confié à des designers, Microsoft propose à ceux-ci le logiciel Expression Interactive

Designer pour manipuler cette interface. XAML inclut également des fonctionnalités pour

manipuler des objets en trois dimensions, de manière analogue à X3D.

2.2.4 Logiciels utilisés

Microsoft Visual Studio 2010 Ultimate

Figure 4.6 : Microsoft Visual Studio 2010 Ultimate

Microsoft Visual Studio 2010 Ultimate est la suite complète d'outils de gestion du cycle de

vie application permettant aux équipes de garantir des résultats de qualité, de la conception au

déploiement. Si vous créez de nouvelles solutions ou améliorer les applications existantes,

Visual Studio 2010 Ultimate permet de vous faire vivre un nombre croissant de plates-formes

et de technologies de ciblage de votre vision — y compris l’informatique dans les nuages et le

calcul parallèle.

Visual Studio 2010 Ultimate présente divers fonctionnalités :

Application Lifecycle Management (ALM)


66

Débogage et diagnostics

Outils de test

Architecture et modélisation

Développement de base de données

Environnement de développement intégré

Prise en charge des plates-formes de développement

Team Foundation Server

Lab Management

Abonnement MSDN

Microsoft Expression Blend® 4

Figure 4.7 : Microsoft Expression Blend 4

Microsoft Expression Blend est l'outil professionnel de conception d'interfaces utilisateurs de

Microsoft pour créer des interfaces graphiques riches orientées Web pour des applications de

bureau mêlant le meilleur du Web et du poste de travail. Expression Blend est écrit en

utilisant le .NET Framework 3.0 et le Windows Presentation Foundation (WPF).

Le nom de code de ExpressionBlend était Sparkle. À l'origine le produit a été annoncé en tant

que Microsoft Expression Interactive Designer, avant qu'il ne soit renommé en Expression

Blend en décembre 2006.

Expression Blend supporte le moteur des textes de WPF avec une typographie OpenType

avancée, le ClearType, les gadgets 2D vectorisés, et les gadgets 3D avec accélération

matérielle par l'intermédiaire de DirectX. Expression Blend est écrit entièrement en Windows


67

Presentation Foundation à l'opposé des anciennes technologies comme le GDI ou GDI+.

Expression Blend fait partie de la suite Microsoft Expression Studio.

Oracle 8i

Figure 4.8 : Oracle

Oracle est un système de gestion de base de données relationnel (SGBDR) qui depuis

l'introduction du support du modèle objet dans sa version 8 peut être aussi qualifié de système

de gestion de base de données relationnel-objet (SGBDRO).

Oracle est un SGBD permettant d'assurer :

La définition et la manipulation des données

La cohérence des données

La confidentialité des données

L'intégrité des données

La sauvegarde et la restauration des données

La gestion des accès concurrents

TortoiseSVN

Figure 4.9 : Tortoise SVN

C’est un logiciel client de SVN (Système de gestion des versions). Il a permis à tous

les membres de l’équipe de développeurs de travailler sur un seul projet commun hébergé sur

un serveur.

En s'intégrant dans l'explorateur de Windows, TurtoiseSVN offre aux utilisateurs de

Windows une interface graphique permettant de réaliser la plupart des tâches qu'offre SVN en

ligne de commande.


68

L'explorateur Windows s'enrichit des fonctionnalités suivantes :

Superposition d'icône aux répertoires et fichiers permettant de visualiser

instantanément l'état (à jour, modifié, en conflit...)

Menu contextuel permettant de faire la mise à jour et de confirmer la modification, à

l'échelle d'un fichier, d'une sélection de fichiers ou encore d'un répertoire

Possibilité d'ajouter en mode détails de l'explorateur des colonnes de type numéro de

révision

3. Scénarios d’exécution

3.1 Interfaces du Framework

Dans cette partie, nous allons décrire les différentes interfaces propre au Framework qu’on a

conçu, et donc ces interfaces sont utilisées par toutes les applications intégrées dans le

Framework, dont notre application « Workflow Recrutement ».

3.1.1 Authentification

Figure 4.10 : Interface d’authentification

Cette interface (figure 4.10) est la première fenêtre lors du lançant l’application.

L’utilisateur est invité à saisir son login et mot de passe pour pouvoir accéder. Une fois

authentifié l’utilisateur accède à la fenêtre principale de l’application.


69

3.1.2 Interface principale

Figure 4.11 : Interface Principale

Cette interface (Figure 4.11) constitue la première interface lancée une fois

l’utilisateur authentifié. Chaque utilisateur possède un ensemble d’autorisations. Une

autorisation est une combinaison entre un profil et un module.

Le menu à gauche (1) permet d’afficher les modules auxquels l’utilisateur est autorisé.

En cliquant sur un module, une liste de liens apparaît dans la barre à gauche (2). Ces liens

sont ordonnés dans un ordre hiérarchique sous forme d’arbre.

En cliquant sur un lien, la fenêtre associée apparaît à l’interface principale dans la zone

(4).

La barre d’outils (3) offre plusieurs possibilités à travers des boutons dont l’activation

dépend de l’écran en cours. Parmi ces fonctionnalités, on peut trouver : Le retour à la page

d’accueil, l’enregistrement, la recherche, la mise en forme, l’impression, l’ajout, la

modification, le rafraîchissement des valeurs de l’écran, la suppression, l’affichage de

l’historique, l’export sous format Word (.doc), l’export sous format Excel (.xls), la validation,

l’annulation, l’ajout à la liste de favoris, l’affichage d’informations.

1

2

4

3


70

3.1.3 Paramétrage des acteurs du workflow Recrutement

Figure 4.12 : Paramétrage des acteurs du Workflow Recrutement

A travers cette interface (figure 4.12), le paramétrage devient une tache simple et facilement

accessible. En effet, elle permet d’ajouter, modifier ou supprimer un utilisateur dans la liste de

rôles du workflow recrutement et ceci en cliquant avec le bouton droit de la souris

directement sur la grille qui contient les utilisateurs de chaque profil.


71

3.1.4 Paramétrage des autorisations du workflow Recrutement

Figure 4.13 : Paramétrage des autorisations du Workflow Recrutement

A travers cette interface (figure 4.13), le paramétrage des autorisations devient une tache

simple et facilement accessible. En effet, il suffit de cocher le droit de chaque profil ensuite

cliquer sur valider dans la ToolBar.

3.1.5 Interface d’aide à la saisie : Recherche F12

Figure 4.14 : Fenêtre d’aide à la saisie

Cette interface (figure 4.14) est conçue pour faciliter la recherche.


72

En effet, après avoir placer le curseur de la souris sur le champs de texte souhaité pour la

recherche, en cliquant sur F12, une liste d’attributs souhaités s’affiche.

3.2 Principales interfaces du Workflow Recrutement

3.2.1 Ecran Candidat

Figure 4.15 : Interface Candidat

Cet écran (figure 4.15) s’affiche quand on clique sur Candidat dans le menu à gauche.

La grille au milieu affiche la liste de candidats selon le statut du candidat souhaité : candidat

soumis, pour test, pour entretien, pour offre, retenu à chaud, recruté ou rejeté.


73

3.2.1.1 Ecran Ajout Candidat

Figure 4.16 : Ecran Ajout Candidat : Informations Personnelles

Figure 4.17 : Ecrans Ajout Candidat : Niveau Académique et Expérience

Figure 4.18 : Ecrans Ajout Candidat : Références et Certifications


74

Ces écran (figure 4.16, 4.17 et 4.18) sont conçu pour ajouter un candidat, ajouter tous les

détails des candidats : ses informations personnelles, son niveau académique, son expérience,

ses stages, ses références et ses certifications.

3.2.1.2 Ecran Affichage et Modification Candidat

Les écrans d’affichage et de modification sont les mêmes que ceux de l’insertion avec en plus

la possibilité de choisir l’ID du candidat au début pour pouvoir afficher directement les détails

de ce candidat.

3.2.1.3 Ecran Recherche Candidat

Figure 4.19 : Ecrans Recherche Candidat : Informations Personnelles et Expérience

Ces écrans (figure 4.19) sont conçus pour faciliter la recherche du candidat selon des filtres

informations personnelles et synthèse expérience professionnelle. L’utilisateur introduit les

paramètres de recherche qu’il veut et ensuite il clique sur valider. Il obtient comme résultat

une liste de candidats selon les informations qu’il a introduites.

3.2.1.4 Candidat pour Offre

Figure 4.20 : Ecran Candidat pour offre


75

Cet écran (figure 4.20) sert à choisir les candidats pour offre. Quand on clique sur le bouton

valider après avoir choisi le candidat pour offre, un autre écran s’affiche : écran offre à faire

(figure 4.21).

Cet écran précise des informations concernant le profil à proposer au candidat.

Figure 4.21 : Ecran Candidat : Offre à Faire

3.2.1.5 Ecrans Candidat pour Test/pour Entretien/Recruté/Rejeté

Ces écrans contiennent tous des grilles de données qui affiche chacune la liste de candidat

selon son statut. Chaque écran contient également la tache suivante à faire.

Exemple : la tâche qui suit l’état « pour Test » c’est la planification du Test.

3.2.2 Ecran Test/Entretien

Figure 4.22 : Ecran Test/Entretien


76

Cet écran (figure 4.22) s’affiche quand on clique sur Test(ou Entretien) sur le menu de

gauche.

La grille au milieu affiche la liste de tests (ou d’entretiens) selon le statut du Test (ou de

l’entretien).

3.2.2.1 Ecran Test/Entretien non Planifié

Figure 4.23 : Ecran Entretien non planifié

Cet écran (figure 4.23) affiche les entretiens non planifiés, si on coche les entretiens à

planifier et on clique sur valider, un écran de planification du test ou de l’entretien (figure

4.24) s’affiche permettant d’introduire les différentes informations concernant le test ou

l’entretien.

Figure 4.24 : Ecran planifier Entretien


77

3.2.2.2 Ecran Test/Entretien Planifié

Figure 4.25 : Ecran Test planifié

Cet écran (figure 4.25) affiche la liste des candidats qui ont un test planifié. Dans la grille de

données, on peut cocher les cases « Réaliser le Test », « Reporter le Test » ou « Annuler le

Test » ensuite cliquer sur le bouton valider pour valider le choix et passer à l’état suivant du

workflow.

3.2.2.3 Ecran Test/Entretien Réalisé/Reporté/Annulé

Ces écrans sont semblables. Ils contiennent une grille de données qui affiche les candidats

suivant le statut du test ou de l’entretien : réalisé, reporté ou annulé.

4. Gestion du projet

Etant gérer par le processus Scrum, notre projet est organisé en sprints d’une durée de

deux semaines, une durée que notre ScrumMaster a jugée raisonnable pour que tous les

membres de l’équipe réalisent leurs tâches respectives. À chaque sprint, nous étions amenés à

réaliser un item de Backlog produit. La liste suivante présente les Backlog produit :

Apprentissage et Documentation (Langage WPF, WF, Enterprise Library 5, Couche

Persistance)


78

Conception et réalisation du Framework (Interface IHM, ToolBar avec Interface en

WPF, ToolBox en WPF générée à partir de la Base de données).

Conception et Réalisation flux de travail de Recrutement (Développement des entités

POCO, Développement de la Couche DAO, Diagramme de classes, Développement

des interfaces)

En parallèle, nous avons élaboré ce rapport de Projet de fin d’études.

A noter également qu’après chaque réunion avec le client, il nous est demandé de

préparer un compte rendu de réunion et de mettre à jour le document de spécifications

fonctionnelles. La démarche suivie pour élaborer ce document se base principalement sur des

captures d’écrans pour illustrer les différentes fonctionnalités de l’application, chaque capture

est accompagnée d’un tableau décrivant les paramètres illustrés par l’écran.

La figure ci-dessous (figure 4.26), présente un diagramme de Gantt, qui est

l’illustration des efforts impartis à chaque phase du projet.

Figure 4.26 : Diagramme de Gantt

Conclusion

Cette dernière partie de rapport nous a permis de présenter l’architecture adoptée pour

structurer notre application. Nous avons aussi présenté l’environnement matériel et logiciel de

l’application, notamment l’utilisation des Framework .NET 4.0 avec les outils les plus

récents.


79

Nous avons ensuite enchaîné avec la partie démonstration qui rassemble quelques captures

d’écran de l’application développée. La fin du chapitre a été consacrée à la présentation de

notre planning de projet en diagramme de Gantt.

Conclusion Générale

L’objectif de notre projet de fin d’étude consiste en la modélisation et la mise en œuvre des

Processus workflow de la gestion de recrutement avec le Framework Windows Workflow

Foundation. Un tel projet vise à construire une plateforme solide « OXIADOTNET »,

propriétaire à la société, intégrant une diversité d’autres modules bénéficiant ainsi de la

richesse et de la fluidité du Framework .NET.

Durant notre projet, nous avons eu pour mission, dans une première étape, l’étude du

Framework WF4 en mettant l’accent sur ses services et son environnement d’exécution, puis

nous avons procédé au recensement des besoins et évoqué les fonctionnalités que OxiaDotNet

peut offrir.

Dans la deuxième étape, nous avons modélisé les processus métiers de la gestion du

recrutement. La dernière étape consistait en la mise en œuvre d’une application WPF qui gère

la totalité des taches relatives au recrutement et dont le service ressource humaine en est

responsable.

Ainsi, au terme de ce projet, nous sommes parvenues à mener une étude analytique et

conceptuelle du Framework OXIADOTNET et achever la modélisation des processus métiers.

Outre, nous avons réussi à nous familiariser avec le développement des Workflows sous WF4

en implémentant l’application hôte des processus Workflows.

Ce projet de fin d’étude a constitué, pour nous, une occasion intéressante d’acquérir de

nouvelles connaissances dans le domaine de gestion de recrutement, la modélisation des

processus Workflows et leurs mise en œuvre sur le Framework Windows Workflow

Foundation 4.

En perspective, nous essayerons de compléter l’implémentation des fonctionnalités conformes

au processus de recrutement de départ. Et améliorer au fur et à mesure l’intégralité des taches

du service ressources humaine.

81

Bibliographie/Netographie

Netographie

[1] http://www.oxiasoft.com

[2] http://fr.wikipedia.org/wiki/Méthode_agile

[3] http://agilemanifesto.org

[4] http://agilemanifesto.org/principles.html

[5] http://fr.wikipedia.org/wiki/Scrum

[6] http://www.mountaingoatsoftware.com

[7] http://msdn.microsoft.com/fr-fr/netframework/aa663324.aspx

[8] http://msdn.microsoft.com/en-us/netframework/aa663328.aspx

[9] http://www.commentcamarche.net/contents/oracle/oracintro.php3

Bibliographie

[10] UML 2 par la pratique, 4ème

édition, Pascal ROQUES Editions Eyrolles

[11] Microsoft Application Architecture Guide 2nd

Edition, ISBN: 9780735627109 Microsoft

Corporation

[12] The Definitive guide of Microsoft Enterprise Library, Keenan Newton ISBN: 10: 1-59059-

655-2

[13] WPF par la pratique, Thomas Lebrun ISBN : 978-2-212-12422-4 Editions Eyrolles

http://www.oxiasoft.com/

http://fr.wikipedia.org/wiki/Méthode_agile

http://agilemanifesto.org/

http://agilemanifesto.org/principles.html

http://fr.wikipedia.org/wiki/Scrum

http://www.mountaingoatsoftware.com/

http://msdn.microsoft.com/fr-fr/netframework/aa663324.aspx

http://msdn.microsoft.com/en-us/netframework/aa663328.aspx

http://www.commentcamarche.net/contents/oracle/oracintro.php3

82

Annexes

83

Annexe A : Diagramme de flux de candidat

Processus Recrutement

Dire

ctio

n R

esso

urc

es

Hu

ma

ine

s

Re

sp

on

sa

ble

Te

ch

niq

ue

co

mp

te

Dire

cte

ur

En

ga

ge

me

nt/

Op

éra

tio

ns/S

SC

DG

BA

Ma

na

ge

r

Besoin en recrutement Gestion des entretiens Finalisation du recrutement Intégration Evaluation Titularisation

Besoin en

recrutement

Demande

d’ouverture

de poste

Validation

OK

Recherche de

profils

Réception des

candidatures

Réalisation des

entretiens de

recrutement(3)

Boîte RHAnnonce

Presse

Sites

emploi/

Atuge

Validation

OK

Décision de

recrutement

NOK

Fiche

évaluation

entretien

NOK

Préparation offre

& éléments

contractuels

Offre emploi Contrat de

travail

Préparation arrivée

nouvelle recrue

(compte réseau,droits

d’accès, boîte

mail...etc

Intégration

générale

Intégration

Spécifique

Evaluation poste

recrutement après

3 moisFiche

évaluation

Arrêt du contrat

Décision

NOK

Description de

Poste

Plan

intégration

Plan

intégration

Figure A.1 : Diagramme de flux de candidat

84

Annexe B : Schématiquement workflow RH

Figure B.1 : Schématiquement workflow RH

85

Annexe C : UML

Figure C.1 : Emblème officiel d’UML

UML [10] est la forme contractée de « Unified Modeling Language », qui peut se

traduire en français par langage unifié pour la modélisation. UML représente l’état de l’art des

langages de modélisation objet. Il fournit les fondements pour spécifier, construire, visualiser

et décrire un système logiciel. Pour cela, UML se base sur une sémantique précise et sur une

notation graphique expressive. Il définit des concepts de base et offre également des

mécanismes d’extension de ces concepts.

UML est un langage de modélisation objet. En tant que tel, il facilite l’expression et la

communication de modèles en fournissant un ensemble de symboles (la notation) et de règles

qui régissent l’assemblage de ces symboles (la syntaxe et la sémantique).

UML n’est pas un langage propriétaire : il est accessible à tous et les fabricants

d’outils ainsi que les entreprises de formation peuvent librement en faire usage. La volonté

d’ouverture, la richesse de la notation et la définition sémantique précise des éléments de

modélisation font d’UML un langage de modélisation général simple, sans être simpliste pour

autant.

Dans UML chaque diagramme permet d’exprimer certains points d’un même

problème. La combinaison de plusieurs digrammes permettra donc d’avoir une vue complète

du système informatique. Ainsi en fonction du problème à résoudre, il convient de choisir les

diagrammes adéquats à utiliser. UML définit neuf types de diagrammes dont nous détaillerons

ceux que nous utiliserons dans la suite :

86

Diagramme de cas d’utilisation : Les cas d'utilisations [9] décrivent le comportement du

système du point de vue utilisateur sous la forme d'actions et de réactions. Un cas d'utilisation

indique une fonctionnalité du système déclenché par un acteur externe au système. Ce genre

de diagramme permet de mettre en place et de comprendre les besoins du client. Dans le

diagramme, interviennent trois éléments : les acteurs, le système et les cas d'utilisation.

L'acteur représente un rôle joué par une personne ou un autre système qui interagit avec le

système en cours de modélisation. Un cas d'utilisation regroupe plusieurs scénarios

d'utilisation du système.

Diagramme de classe : Le diagramme de classes [9] est le point central dans un

développement orienté objet. En analyse, il a pour objectif de décrire la structure des entités

manipulées par les utilisateurs. En conception, le diagramme de classes représente la structure

d’un code orienté objet ou, à un niveau de détail plus important, les modules du langage de

développement.

Diagramme de déploiement : il indique comment l’application sera distribuée entre les

différents composants matériels.

Diagramme de séquence : Les diagrammes de séquences permettent de représenter des

collaborations entre objets selon un point de vue temporel, on y met l'accent sur la

chronologie des envois de messages. Les diagrammes de séquences peuvent servir à illustrer

un cas d'utilisation.

Diagramme d’état/transition : il modélise les aspects contrôle et temps du système.

Diagramme d’activité : UML permet de représenter graphiquement le comportement d'une

méthode ou le déroulement d'un cas d'utilisation, à l'aide de diagrammes d'activités (une

variante des diagrammes d'états-transitions).

Diagramme de collaboration : il modélise la communication possible entre les classes dans

un scénario particulier.

Diagramme des composants.

Diagramme d’objets.

http://uml.free.fr/cours/p18.html#coll

http://uml.free.fr/cours/p10.html#uc

http://uml.free.fr/cours/p10.html#uc

http://uml.free.fr/cours/i-p20.html

87

Glossaire

RH: Ressources Humaines

DRH: Direction Ressources Humaines

RRH: Responsable Ressources Humaines

CV: Curriculum Vitae

LM: Lettre de Motivation

RDV: Rendez-vous

BA: Business Area

BU: Business Unity

CMMI: Capability Maturity Model integration

DAO: Data Access Object

ENTLIB: Enterprise Library

ISBN: (International Standard Book Number)

Netographie: Bibliographie du net, synonyme de webographie

POCO: Plain Old CLR Object

SCRUM: Terme emprunté au rugby et signifie mêlée

SGBDR: Système de Gestion de Base de Données Relationnel

SQL: StructuredQueryLanguage, utilisée pour la manipulation des données d’une Base de

données

SSII: Société de Services en Ingénierie Informatique

88

SVN: SubVersion, système de gestion des versions.

UML: Unified Modeling Language

XAML: eXtensible Application Markup Language

XML: eXtensible Markup Language

WCF: Windows Communication Foundation

WPF: Windows Presentation Foundation

WF: Workflow Foundation

rapport final recruteemnt finale

Documents