Modélisation d'un système d'information pour la gestion des activités liées aux demandeurs d'emploi cas de l'office national de l'emploi de Bandundu

Conclusion

Après avoir analysé et critiqué le fonctionnement du système de l'existant, nous sommes parvenir à la proposition des solutions, auquel nous proposons la solution informatique pour ses avantages évoqués ci-haut.

Cette deuxième partie est consacrée à faire une étude de l'existant, c'est-à-dire comprendre le fonctionnement du système actuel. C'est ce qui nous a permis de déceler les points forts et points faibles du système en place.

TROISIEME PARTIE : CONCEPTION DU NOUVEAU SYSTÈME D'INFORMATION

OBJECTIFS DU NOUVEAU SYSTEME

Le travail d'un informaticien est celui d'un architecte dit-on.Dans ce sens qu'il commence toujours par une conception avant d'aboutir à la réalisation.

La méthodologie de conception de systèmes d'information s'articule autour des méthodes et l'implémentation de la base des données s'effectue à l'aide d'un SGBD (Système de Gestion de Base des Données)^23(*).

Pour ce qui concerne notre mémoire, nous avons porté notre choix sur le Processus Unifié et la Méthode de Potentiels Métracomme méthode etau SGBD Microsoft SQL Serveur comme outil d'implémentation.

CHAPITRE 1 : CONCEPTION DU NOUVEAU SYSTEME D'INFORMATION AVEC UML

1.1. Présentation du Processus Unifie (PU)^24(*)

Le processus unifié est un processus de développement moderne, itératif,efficace sur des projets informatiques de toutes tailles. Très complet, il couvre l'ensemble des activités, depuis la conception du projet jusqu'à la livraison de la solution. Intégrant une organisation de projet type, une méthodologie utilisant UML et un ensemble de bonnes pratiques cohérentes entre elles.Un point d'excellence de cette démarche est son adaptabilité : le PU peut se décliner en fonction de l'ampleur d'un projet, de l'expérience de l'équipe qui l'assume, et de la nature de la solution à construire.

1.1.1. Principes d'UP

Le processus de développement UP, associé à UML, met en oeuvre les principes suivants :

ü Processus guidé par les cas d'utilisation ;

ü Processus itératif et incrémental ;

ü Processus centré sur l'architecture ;

ü Processus orienté par la réduction des risques.

Ces principes sont à la base du processus unifié décrit par les auteurs d'UML.

a) Processus guidé par les cas d'utilisation

Tout système d'information est construit sur base de besoins des utilisateurs. L'orientation forte donnée ici par UP est de montrer que le système àconstruire se définit d'abord avec les utilisateurs. Une seconde orientation est de montrer comment les cas d'utilisation constituent un vecteur structurant pour le développement et les tests du système. Ainsi le développement peut se décomposer par cas d'utilisation et la réception du logiciel sera elle aussi articulée par cas d'utilisation^25(*).

b) Processus itératif et incrémental

Ce type de démarche étant relativement connu dans l'approche objet, il paraîtnaturel qu'un PU préconise l'utilisation du principe de développement par itérations successives. Concrètement, la réalisation de maquette et prototype constitue la réponse pratique à ce principe. Le développement progressif, par incrément, est aussi recommandé en s'appuyant sur la décomposition du système en cas d'utilisation.

Les avantages du développement itératif se caractérisent comme suit :

Ø Les risques sont évalués et traités au fur et à mesure des itérations ;

Ø Les premières itérations permettent d'avoir un feed-back des utilisateurs ;

Ø Les tests et l'intégration se font de manière continue ;

Ø Les avancées sont évaluées au fur et à mesure de l'implémentation.

c) Processus centré sur l'architecture

Le choix de l'architecture doit se faire en amont (dès le début des travaux d'analyse et de conception). Il est importantde définir le plus tôt possible, même à grandes mailles, l'architecture type quisera retenue pour le développement, l'implémentation et ensuite ledéploiement du système. Le vecteur des cas d'utilisation peut aussi être utilisépour la description de l'architecture.

d) Processus orienté par la réduction des risques

L'analyse des risques doit être présente à tous les stades de développementd'un système. Il est important de bien évaluer les risques des développements afin d'aider à la bonne prise de décision. Du fait de l'application du processus itératif, UP contribue à la diminution des risques au fur et à mesure du déroulement des itérations successives.

1.1.2. Activités du processus unifié^26(*)

Les activités représentent les actions à effectuer au cours d'une phase. Voici la liste des activités du Processus Unifié :

1. Expression des besoins : UP propose d'appréhender l'expression des besoins en se fondant sur une bonne compréhension du domaine concerné pour le système à développer et une modélisation des procédures du système existant.

Ainsi, UP distingue deux types de besoins :

ü Les besoins fonctionnels qui conduisent à l'élaboration des cas d'utilisation ;

ü les besoins non fonctionnels (techniques) qui aboutissent à la rédaction d'une matrice des exigences.

2. Analyse : L'analyse permet une formalisation du système à développer en réponse à l'expression des besoins formulée par les utilisateurs. L'analyse se concrétise par l'élaboration de tous les diagrammes donnant une représentation du système tant statique que dynamique.

3. Conception : La conception prend en compte les choix d'architecture technique retenus pour le développement et l'exploitation du système.

4. Implémentation : Cette phase correspond à la production du logiciel sous forme de composants, de bibliothèques ou de fichiers. Cette phase reste, comme dans toutes les autres méthodes, la plus lourde en charge par rapport à l'ensemble des autres phases (au moins 40 %).

5. Test : Les tests permettent de vérifier :

ü La bonne implémentation de toutes les exigences (fonctionnelles et techniques),

ü Le fonctionnement correct des interactions entre les objets ;

ü La bonne intégration de tous les composants dans le logiciel.

1.1.3. Adaptation

Le processus unifié s'adapte à deux approches :

Ø L'approche standard ;

Ø L'approche 2TUP.

1.2. Présentation du langage UML

UML (UnifiedModelingLanguage, que l'on peut traduire par « Langage de Modélisation Unifié » est un langage permettant de modéliser un problème de façon standard. Officiellement UML est né en 1994. UML v2.0 date de 2005. Il s'agit d'une version majeure apportant des innovations radicales et étendant largement le champ d'application d'UML.

Le langage de modélisation unifiée (UML) est la synthèse de plusieursméthodes d'analyse et de conception des systèmes d'information orientéesobjet (OMT, BOOCH, OOSE), développée en vue de pallier aux insuffisances des méthodesclassiques^27(*) et devenu actuellement la référence en termes de modélisation objet.

UML n'est ni une méthode, ni un processus mais plutôt un langage de modélisation. Dans le cadre de la modélisation d'une application informatique, UML n'impose pas une démarche particulière pour l'analyse du système mais il préconise (recommander) d'adopter une démarche ayant les caractéristiques suivantes^28(*) :

Ø Itérative et incrémentale : c'est-à-dire comprendre et représenter un système complexe ;

Ø Guidé par le besoin des utilisateurs du système : avec UML, ce sont les utilisateurs qui guident la définition des modèles car le but du système à modéliser est de répondre aux besoins des utilisateurs ;

Ø Centré sur l'architecture logicielle : UML décrit des choix stratégiques qui déterminent en grande partie les qualités du logiciel : adaptabilité, performance et la fiabilité.

UML est un support de communication. Sa notation graphique permet d'exprimer visuellement une solution objet. L'aspect formel de sa notation limite les ambiguïtés et les incompréhensions.

Son aspect visuel facilite la comparaison et l'évaluation de solutions. Son indépendance (par rapport aux langages d'implémentation, domaine d'application, processus...) en font un langage universel.

Est-ce qu'UML est une solution à tout ?

Evidemment pas. L'UML n'est qu'un ensemble de formalismes permettant d'appréhender un problème et de le modéliser. Un formalisme n'est qu'un outil et son succès dépend de savoir utiliser les outils^29(*).

UML est utilisé pour proposer une version visuelle d'un projet que tout peut comprendre. UML utilise 14 diagrammes pour expliquer un projet à savoir :^30(*)

A. Diagrammes structurels ou statique

1) De classes (class diagram) : montre la structure du système à concevoir ;

2) D'objets (objectdiagram) : permet de vérifier la validité du diagramme de classe ;

3) De composants (component diagram) : illustre les éléments logiciels (exécutable) ;

4) De déploiement (deploymentdiagram) : il illustre la disposition physique du matériel et la répartition des composants sur ce matériel ;

5) De paquetages (package diagram) : schématise l'ensemble d'éléments de modélisation ;

6) De structure composite (composite structure diagram) : décrit les relations entre les composants d'une classe ;

7) De profil : est un diagramme structurel permettant l'utilisation de profil, pour un méta modèle donné.

B. Diagrammes de comportement

8) De cas d'utilisation (use case diagram) : montre comment chaque acteur exploite le système ;

9) D'états-transition (state diagram) : montre les différents états que peut prendre un objet instance de la classe lors de son cycle de vie.

10) D'activité (activitydiagram) : décrit le comportement du système ;

C. Diagrammes dynamiques ou d'interaction

11) De séquences (sequencediagram) : montre la manière dont se font les traitements et indique les interactions entre les éléments du système ;

12) De communication (communication diagram) :représentation simplifiée d'un diagramme de séquence se concentrant sur les échanges de messages entre les objets

13) De temps (timing diagram) : permet de décrire les variations d'une donnée au cours du temps ;

14) De vue générale d'interaction (interaction overviewdiagram) .

Ces diagrammes permettent de définir une application selon plusieurs points de vue :

o Fonctionnel (Cas d'utilisation)

o Statique (classes, objets, structure composite)

o Dynamique (séquence, états, activité, interaction, communication, temps)

o Implémentation (composants, déploiement, paquetage).

1.3. Eude au point de vue fonctionnel

1.3.1. Démarche d'élaboration d'un cas d'utilisation

Les cas d'utilisation sont une technique de description du système étudié privilégiant le point de vue de l'utilisateur. Un cas d'utilisation est une façon spécifique d'utiliser le système. Il est composé d'un ensemble d'actions déclenché par un acteur externe et qui produit un résultat identifiable^31(*).

Un cas d'utilisation représente la relation entre un acteur et une fonctionnalité du système. Dans la modélisation d'un système d'information, on considère que les processus sont des cas d'utilisation. Pour l'élaboration du cas d'utilisation, nous utilisons les concepts suivants :

ü Acteur ;

ü Cas d'utilisation ;

ü Association ;

· Inclusion

· Exclusion

A noter que dans une démarche d'élaboration du diagramme de cas d'utilisation il est nécessaire :

Ø D'identifier les acteurs ;

Ø D'organiser les acteurs par des relations ;

Ø De rechercher le cas d'utilisation du système pour chaque acteur ;

Ø De rechercher les fonctionnalités du système par ses cas d'utilisation.

a) Acteur : un acteur est un rôle attribué à une entité externe (humain, matériel) pour interagir directement avec le système^32(*) :

On distingue deux catégories d'acteurs :

- Acteurs primaires : sont ceux qui utilisent le système ;

- Acteurs secondaires : sont ceux qui administrent et maintiennent le système.

b) Cas d'utilisation : est un ensemble d'actions réalisées par un système à une action d'un acteur.

1.3.2. Identification des acteurs

Nous avons trois intervenants qui interagissent avec le système : le responsable de l'onem (Agent), l'Administrateur du système et le demandeur d'emploi.

1.3.3. Cas d'utilisation identifiés

Les différents cas d'utilisation recensés sont les suivants :

a) Responsable de l'ONEM

- Identification ;

- Authentification ;

- Consultation offres d'emplois ;

- Présélection demandeurs d'emploi ;

- Afficher la statistique.

b) Les demandeurs d'emploi

- Identification ;

- Authentification ;

- Modification de profil ;

- Impression de la carte de demandeur d'emploi.

c) L'administrateur

- Gestion technique de la plate-forme ;

- Authentification ;

- Gestion des comptes utilisateurs.

1.3.3.1. Les relations entre acteurs et cas d'utilisation

Il est parfois intéressant d'utiliser des liens entre les différents cas (sans passer par un acteur), UML en fournit de deux types : la relation d'inclusion (include) et la relation d'extension (extend).

- Inclusion de cas (include) : La relation d'inclusion (include) est employée quand deux cas d'utilisation ont en commun une même fonctionnalité et que l'on souhaite factoriser celle-ci en créant un sous cas, ou cas intermédiaire, afin de marquer les différences d'utilisation.

- Extension de cas (extend) : schématiquement, nous dirons qu'il y a extension d'un cas d'utilisation quand un cas est globalement similaire à un autre, toute effectuant un peu plus de travail (voire un travail plus spécifique). Cette notion à utiliser avec discernement permet d'identifier des cas particuliers (commandes, procédures à suivre en cas d'incident) dès le début ou lorsque l'attitude face à un utilisateur spécifique du système doit être spécialisée ou adaptée. Il s'agit grosso modo d'une variation du cas d'utilisation normale.

1.3.4. Diagramme de cas d'utilisation global

Les diagrammes de cas d'utilisation modélisent à QUOI sert le système. La figure suivante montre la structure globale de cas d'utilisation.

Figure n° 13 : Cas d'utilisation global

Description textuelle des cas d'utilisation

Afin de décrire les interactions entre les cas d'utilisation, nous présentons ces derniers de façon textuelle. Il s'agit donc d'associer à chaque cas d'utilisation un nom, un objectif, les acteurs qui y participent, les pré-conditions et des scénarii. Cependant ; il existe trois types de scénarii : les scénarii nominaux ; les scénarii d'exceptions et les scénarii alternatifs.

Dans notre description textuelle, nous présentons seulement les scénarii nominaux et alternatifs. Nous nous restreindrons à la description des cas d'utilisation suivants : authentification et identification.

CU1 : Authentification

Résumé: Ce CU permet à un utilisateur de se connectant au système ; et lui

présenter l'interface, les fonctionnalités relatives à son profil.

Acteurs: Préposé accueil actif, Demandeur d'emploi, Administrateur

Pré conditions : Introduire login et mot de passe

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

Scénario nominal

DESCRIPTION DU SCENARIO NOMINAL

« DEBUT»

01 : Le système invite l'acteur à entrer son login et son mot de passe.

02: L'acteur saisit le login et le mot de passe et choisit son profil.

03: Le système vérifie les paramètres.

04: Le système ouvre l'espace de travail correspondant au profil.

« FIN»

Scenario alternative

DESCRIPTION DU SCENARIO ALTERNATI F

Le login ou le mot de passe est incorrect: ce scénario commence au point 03 du scénario nominal.

01 : Le système informe l'acteur que les données saisies sont erronées et le scénario reprend au point 01 du scénario nominal.

CU2: Identification

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

Acteurs: Préposé accueil actif, Demandeur d'emploi

Post-Condition: le cas démarre après le point 02 de l'enchainement nominal, l'utilisateur s'inscrit au site

Scenario nominal

DESCRIPTION DU SCENARIO NOMINAL

« DEBUT»

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

02 : l'acteur saisit ses informations.

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

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

05 : le système notifie l'acteur du bon déroulement de l'identification

Scenario alternative

les informations sont manquantes ou incorrectes: ce scénario commence au point 03 du scénario nominal.

01 : Le système informe l'acteur que les données saisies sont erronées, garde les informationssaisies avant et le scénario reprend au point 02 du scénario nominal.

1.3.5. Elaboration du diagramme de séquence

Le diagramme de séquence est un diagramme d'interaction entre les objets, qui met l'accent sur le classement des messages par ordre chronologique durant l'exécution du système^33(*).

Les diagrammes de séquences permettent de décrire COMMENT les éléments du système interagissent entre eux et avec les acteurs :

· Les objets au coeur d'un système interagissent en s'échangeant des messages ;

· Les acteurs interagissent avec le système au moyen d'IHM (Interfaces Homme-Machine).

Diagramme de Séquence du cas « Authentification ».

Figure n° 14: Cas d'utilisation authentification

Diagramme de Séquence du cas « Identification ou enregistrement ».

Figure n° 15: Cas d'utilisation Identification

1.4. Eude au point de vue statique

1.4.1. Elaboration du diagramme de classes

Le diagramme de classes est un schéma utilisé pour présenter les classes et les interfaces des systèmes 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^34(*).

Une classe est la description d'un ensemble d'objets ayant une sémantique, des attributs, des méthodes et des relations en commun.

Avantages des diagrammes de classes

Les diagrammes de classes présentent des avantages ci-après :

F Illustrer des modèles de données pour des systèmesd'information ;

F Mieux comprendre l'aperçu général des schémas d'une application ;

F Créer des schémas détaillés qui mettent l'accent sur le codespécifique qui doit être programmé et mis en oeuvre dans lastructure décrite.

F Fournir une description indépendante de l'implémentation destypes utilisés dans un système, qui sont ensuite transmis entre sescomposants.

1. Formalisme de la classe

Une classe est la description d'un ensemble d'objets ayant une sémantique, des attributs, des méthodes et des relations en commun^35(*). Celle-ci est composée de trois compartiments à savoir : le nom, les attributs et les opérations.

Nom de la classe

attribut 1 : Int

attribut 2 : String

attribut 3 : Float

apération 1 () : void

apération 2 () : void

· Un attribut décrit une donnée de la classe.Les attributs prennent des valeurs lorsque la classe est instanciée ;

· Une méthode ou opération est un service offert par la classe (un traitement que les objets correspondant peuvent effectuer).

NB : Les attributs et les méthodes ou opérations sont les propriétés d'une classe. Leur nom commence par une minuscule.

2. Relation entre les classes

Une relation est un lien entre deux ou plusieurs classes.

2.1. Relation de généralisation ou d'héritage

Une relation d'héritage est une relation de généralisation permettant l'abstraction. (Abstraction est un processus qui permet à identifier une entité en mettant en évidence ses caractéristiques pertinentes du point de vue de son utilisation.

Une dépendance est une relation unidirectionnelle exprimant une dépendance sémantique entre les éléments du modèle (flèche ouverte pointillée).

a) Association

Une association est une relation entre deux classes décrivant les connexions structurelles entre les instances.

b) Multiplicité

La multiplicité en modélisation des données sert à compter le nombre minimum et maximum de possibilités que chaque classe contient dans la relation liant deux ou plusieurs objets.

Tableau n°9: Multiplicité

0.. 1 :	Aucune ou une instance
1 :	Une instance exactement
0.. * ou * :	Aucune ou plusieurs
1.. * :	Une instance ou plusieurs (au moins une)

c) Classe - association

Dans le modèle objet, seules les classes peuvent avoir des attributs, tandis qu'une association peut être raffinée et avoir ses propres attributs, qui ne sont disponibles dans aucune des classes qu'elle lie, cette association devient alors une classe appelée classe-association^36(*).

Ex : Entre les classes société et agent, nous avons l'association « emploi » dont les propriétés sont : salaire et date d'engagement.

2.2. Agrégation et composition^37(*)

a) Agrégation : Une agrégation est une forme particulière d'association. Elle représente la relation d'inclusion d'un élément dans un ensemble. On représente l'agrégation par l'ajout d'un losange vide du côté de l'agrégat.

b) Composition : une relation de composition est une relation d'agrégation dans laquelle il existe une contrainte de durée de vie entre la classe composant et la classe composée.

1.4.1.1. Classes d'objets identifiées

Lors de nos investigations à la Direction Provinciale de l'ONEM Bandundu, nous avons identifié les classes suivantes :

ü Demandeur d'emploi ;

ü Agent ;

ü Emploi ;

ü Service ;

ü Dossier ;

ü Document ;

ü Carte de demandeur.

Les différentes associations reliant les classes d'objets sont les suivantes :

ü Enregistrer ;

ü Proposer ;

ü Solliciter ;

ü Déposer ;

ü Analyser ;

ü sélectionner ;

ü Remettre ;

ü Vérifier ;

ü Se trouver ;

* ²³ KUHOSAKUBI Rolin, cours de Technique de base des données 3ème graduat, Info, ISC-BDD, 2014-2015, (Inédite).

* ²⁴ MUKENGE, J., Cours de Conception des Systèmes d'Information, L2 Info, ISC-BDD, 2022-2023, P.3-5, Inédit

* ²⁵DI GALLO Frédéric, Méthodologie des systèmes d'information - UML, EditionCNAM ANGOULEME 2000-2001

* ²⁶ MUKENGE, J., Cours de Conception des Systèmes d'Information, L2 Info, ISC-BDD, 2022-2023, Inédit

* ²⁷ MUKENGE, J., Cours de Conception des Systèmes d'Information, L2 Info, ISC-BDD, 2022-2023, P.26, Inédit

* ²⁸ Barro DRISSA et Traoré IBRAHIM, Gestion des inscriptions en ligne à l'Université Polytechnique de Bobo-Dioulasso, mémoire de fin de cycle, Université Polytechnique de Bobo-Dioulasso, 2009-2010, P.29, (inédit).

* ²⁹ BIMA, G., Cours de Génie logiciel, L1 Info, ISC-BDD, 2021-2022, P.28, Inédit

* ³⁰ BIMA, G., Op. Cit

* ³¹ BIMA, G., Op. Cit

* ³² PASCAL, R., UML 2 par la pratique étude de cas et exercices corrigés,5^èmeEd.Eyrolles, Paris, 2008.

* ³³ ROQUES Pascal, UML 2 Modéliser une application web, éd. Eyrolles, Paris, 2007.

* ³⁴ MUKENGE, J., Op. Cit

* ³⁵ BIMA, G., Cours de Génie logiciel, L1 Info, ISC-BDD, 2021-2022, P.28, Inédit

* ³⁶ BIMA, G., Op. Cit. ;

* ³⁷ BIMA, G., Op. Cit