Table de matières
Table de matières
Dans ce chapitre, nous présentons les différents concepts utilisés pour en avoir une juste compréhension. La section sur la modélisation par le langage UML nous permet de présenter les différents diagrammes UML qui ont été retenus dans le cadre cette étude.
2.2.1 Système d’information (SI)
Un Système d’information est un ensemble organisé de ressources (matériels, logiciels, personnel, données et procédures), permettant d’acquérir, de traiter, de stocker des informations
(sous forme de données, textes, images, sons, etc.) dans et entre des organisations (Yannick, 2005). Il représente l’ensemble des ressources (humaines, matérielles, logicielles) organisées par l’entreprise pour collecter l’information, la mémoriser pour une utilisation ultérieure, la traiter et la diffuser. Pour permettre au système d’information de traiter les données de manière automatisée, l’entreprise y intègre le système d’information informatisé. Celui-ci assure le traitement des données grâce à l’utilisation des programmes informatiques.
2.2.2 Modélisation
Dans la conception d’un système d’information, la modélisation des données est l’analyse et la conception de l’information contenue dans le système.
La modélisation des données est une représentation abstraite, dans le sens où les valeurs des données individuelles observées sont ignorées au profit de la structure, des relations, des noms et des formats des données pertinentes, même si une liste des valeurs valides est souvent enregistrée (wiki, 2016).
Grâce au modèle, il est possible de représenter simplement un problème, un concept et le simuler. La modélisation comporte trois composantes, à savoir (i) l’analyse, c’est-à-dire l’étude du problème, (ii) la conception, soit la mise au point d’une solution au problème, (iii) le modèle constitue ainsi une représentation possible du système selon un point de vue donné (Pillou, 2015).
La modélisation d’un système d’information implique qu’il faut choisir le modèle de développement logiciel mais aussi l’atelier de génie logiciel. Ainsi le modèle en V tel que présenté à la figure 2.1 a-t-il été utilisé.
Dans ce modèle, les étapes retenues sont l’expression de besoins, l’implémentation et le codage.
Par ailleurs, l’atelier de génie logiciel Visual paradigme for UML a été utilisé comme outil de modélisation, notamment pour la représentation des diagrammes UML.
La modélisation d’un système d’information repose également sur la méthode ou le langage à suivre. Ainsi, le langage UML (Unified Modeling Language) a été choisi pour la présente étude.
L’agence de voyage routier LA COLOMBE EXPRESS, ne disposant actuellement d’aucun outil informatique pour optimiser sa gestion, a besoin d’une base de données pour enregistrer et répondre dans un plus bref délai aux demandes de ses abonnés afin de les fidéliser. Elle a besoin d’une application orientée base de données pour avoir des informations en temps réel sur son personnel et son charroi mobile. Cet outil informatique lui permettra de faire d’une manière automatique des rapports sur des activités, permettant ainsi à l’agence de maximiser les recettes aux décideurs de prendre des décisions.
UML est une notation permettant de modéliser un problème de façon standard. Ce langage est né de la fusion de plusieurs méthodes[1] existantes auparavant et est devenu désormais le standard en modélisation orientée objet, à un tel point que sa connaissance est souvent nécessaire pour obtenir un poste de développeur objet (Pillou, 2015).
Pour présenter de manière abstraite la réalité, la dernière version UML 2.3 comporte quatorze types de diagrammes répartis en trois vues distinctes, notamment la vue fonctionnelle, la vue statique et la vue dynamique, permettant ainsi de présenter des concepts particuliers du système d’information étudié.
Comme vues fonctionnelles, il y a le diagramme de cas d’utilisation, le diagramme étatstransitions et le diagramme d’activités. Comme vues statiques, il y a le diagramme de classes, le diagramme d’objets, le diagramme de composants, le diagramme de déploiement, le diagramme de paquets, le diagramme de structure composite et le diagramme de profils. Comme vues dynamiques, il y a le diagramme de séquence, le diagramme de communication, le diagramme global d’interaction et le diagramme de temps (wiki, 2016).
Dans cette étude, le diagramme de cas d’utilisation, le diagramme de classes, le diagramme de séquence, le diagramme de communication et le diagramme d’activités ont été retenus. Ces diagrammes nous ont permis de modéliser le système d’information sur lequel porte notre étude, en présentant les différentes activités que peut jouer un acteur dans le système, l’interaction entre lui et le système.
2.4.1 Diagramme de cas d’utilisation
Un cas d’utilisation (use case) représente une unité cohérente d’une fonctionnalité fournie par un système (ou sous-système ou classe) spécifiée par une séquence d’actions que le système peut exécuter en interagissant avec les acteurs du système (Guibert, 2010). Il décrit les services les plus importants rendus par un système, partant des acteurs, participants externes qui interagissent avec le système. Il représente les cas les plus importants du système en cours d’utilisation. Un cas d’utilisation peut être divisé en diagrammes de séquence qui détaillent les différentes fonctions du cas d’utilisation.
Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié (Roques, 2006). Les acteurs sont représentés par un pictogramme sous-titré par le nom de l’acteur.
On distingue deux types d’acteurs (i) les acteurs principaux qui sont des acteurs utilisant les fonctions principales du système (usager, client, etc.), (ii) les acteurs secondaires qui sont des acteurs effectuant des tâches administratives ou de maintenance (maintenancier, administrateur) (Jean Robert Kala, 2015).
Pour le système étudié, les acteurs identifiés sont le chef d’agence, le guichetier et le secrétaire.
Ils utilisent des fonctionnalités du système, c’est-à-dire des cas d’utilisation. Le chef d’agence utilise le système pour enregistrer un personnel, un véhicule, un congé, programmer un voyage, imprimer les statistiques, créer un nouvel utilisateur (en choisissant le niveau d’accès de ce dernier, en lui attribuant ainsi des droits).
Le guichetier est un acteur ayant un compte utilisateur avec un certain nombre de droits d’accès limités par rapport à ceux du chef d’agence. Il peut utiliser le système pour enregistrer un billet de voyage, effectuer une réservation et visualiser l’état statistique (voyage, vente de billets, locations véhicules).
Le secrétaire utilise le système pour enregistrer une absence, un client, une sanction, une demande de congé et visualiser l’état statistique (congés, sanctions, retraités, démissionnaires, licenciés). Ainsi, les figures 2.1, 2.2 et 2.3 présentent les diagrammes de cas d’utilisation du système tels que organisés en deux packages : gestion de cas d’utilisation (figure 2.1), gestion des voyages et du personnel (figure 2.2) et gestion des réservations (figure 2.3).
Pour que le chef d’agence puisse donner ou retirer un droit d’accès à un utilisateur, il doit s’authentifier au système comme indiqué dans le diagramme de la figure 2.1. L’objectif du diagramme de la figure 2.1 est de permettre au chef d’agence de gérer tous les comptes d’utilisateur du système.
Figure 2.2 : Diagramme de cas d’utilisation pour la gestion des comptes des utilisateurs.
L’objectif du diagramme de la figure 2.3 est de permettre au chef d’agence de programmer un voyage, au guichetier de créer un nouveau billet de voyage et au secrétaire d’enregistrer les présences et absences des employés.
Figure 2.3 : Diagramme de cas d’utilisation pour la gestion des voyages et du personnel.
Le chef d’agence programme un voyage en fonction de la disponibilité d’un véhicule et en se basant de l’horaire de voyage. Avant de programmer un voyage, il est obligatoire qu’il s’authentifie au système comme indiqué dans le diagramme de la figure 2.2. Le chef d’agence envoit une requête au système pour programmer un voyage et le système lui retourne un formulaire à remplir. Il remplit le formulaire et valide l’enregistrement. Le système vérifie s’il y a un chauffeur disponible et un véhicule pour valider la demande, sinon on lui retourne une exception.
Le guichetier ne peut enregistrer un billet ou produire une statistique de voyage que s’il est connecté au système. Il peut aussi produire la statistique des billets vendus en une journée. Le secrétaire enregistre les absences, les sanctions, les demandes de congé mais aussi les clients et visiteurs de l’agence. Toutes ses tâches ne doivent être effectuées que s’il est authentifié au système.
Le diagramme de la figure 2.3 concerne la gestion des réservations. Les acteurs identifiés dans ce diagramme sont le guichetier, le visiteur et le passager.
Figure 2.4 : Diagramme de cas d’utilisation pour la gestion des réservations.
D’après la figure 2.4, le guichetier doit s’authentifier au système avant de faire une réservation. Celle-ci n’est possible que s’il y a au moins une place disponible. Le passager ne fait que demander les informations nécessaires concernant le voyage ; et le guichetier définit les paramètres précis du passager puis l’affecte à une place.
2.4.2 Diagramme de classes
Le diagramme de classes décrit les classes d’une application et leurs relations statiques (Guillaume, 2007). Dans la phase de conception, il représente la structure objet d’un développement orienté objet. L’architecture de ce diagramme démontre les associations qui lient les différentes classes de l’application entre elles. Pour réaliser les diagrammes de figures 2.5, 2.6 et 2.7, nous avons utilisé certains attributs de différentes classes utilisées dans le langage java.
Ainsi, la figure 2.5 concerne la gestion des utilisateurs. En effet, un utilisateur est caractérisé par un profil pour définir son compte d’utilisateur dans l’application, il possède un id, un nom, un prénom, un numéro de téléphone, un e-mail, un login, un mot de passe plus un id_prof (il se présente comme une clé étrangère dans la classe utilisateur du fait qu’il permettra de récupérer certaines informations de la classe Profil).
Figure 2.5 : Diagramme de classes pour la gestion des utilisateurs.
Chaque profil est identifié par un id_prof (identifiant du profil), type_prof (type de profil), premis_prof (permission ou droit d’accès). La méthode getpermission (String) prend un certain nombre de caractère en paramètre qui désigne le droit d’accès que possède un profil d’utilisateur pour lui permettre d’avoir un accès à certain module de l’application.
La figure 2.6 représente le diagramme de classes pour la gestion des voyages.
Figure 2.6 : Diagramme de classes pour la gestion de voyages.
On observe qu’un véhicule est concerné un ou plusieurs voyages et un voyage peut concerner un et un seul véhicule. Chaque parking se situe dans une et une seule ville et une ville peut avoir un ou plusieurs parkings. Un voyage peut avoir plusieurs escales et un parking peut recevoir plusieurs escales. Une escale peut être effectuée dans un seul parking et il concerne un seul voyage.
La figure 2.7 représente le diagramme de classes pour la gestion des réservations. Il ressort qu’un guichetier peut ou ne pas confirmer une réservation.
Une réservation peut être confirmer par un et un seul guichetier. Un passager peut effectuer un ou plusieurs réservations et une réservation est effectuée par un et un seul passager. Chaque type de réservation est caractériser par un ou plusieurs réservations et une réservation est caractériser par un seul type de réservation.
Figure 2.7 : Diagramme de classes pour la gestion de réservation.
2.4.3 Diagramme de séquence
Le diagramme de séquence est une représentation temporelle des interactions entre objets
(Guillaume, 2007). Il décrit les interactions entre les acteurs, entre un groupe d’objets en montrant de façon séquentielle l’ensemble de messages envoyés, qui interviennent entre les objets et le système selon un ordre chronologique. Il peut également montrer les flux de données échangées lors des envois de messages.
Le schéma de la figure 2.8 présente le diagramme de séquence Réserver un voyage. En effet, pour effectuer une réservation, le client demande au guichetier les informations nécessaires pour le voyage. Si le client accepte les conditions préétablies par l’agence pour faire une réservation, le guichetier vérifie s’il y a encore des places disponibles pour le voyage. Le système retourne un message indiquant le nombre des places disponibles ; le guichetier remplit le formulaire par les informations du client, il entre le nombre de place que le client souhaite réserver et il valide ; si les informations sont bien rentrées, la réservation s’effectue et une notification est envoyée au guichetier pour lui certifier que la réservation a été effectuée avec succès. Sinon, le système lui retourne un message qui dit qu’il y a plus de place disponible pour effectuer la réservation.
Figure 2.8 : Diagramme de séquence Réserver un voyage.
Le schéma de la figure 2.9 présente le diagramme de séquence Créer un voyage. Pour créer un voyage, le chef d’agence doit avant tout s’authentifier au système. Il peut ensuite sélectionner un véhicule pour ce voyage. Et puis il choisit le lieu de départ et d’arrivée. Enfin, il crée le voyage après avoir spécifié les autres informations requises.
Figure 2.9 : Diagramme de séquence Créer un voyage.
Le diagramme de séquence Affecter un véhicule (figure 2.10) indique que le chef d’agence affecte un véhicule à un voyage. Pour cela, il doit sélectionner le véhicule concerné et l’affecter au dit voyage.
Figure 2.10 : Diagramme de séquence Affecter un véhicule.
2.4.4 Diagramme de communication
Le diagramme de communication est un diagramme UML qui fournit une représentation graphique des interactions entre les objets d’un scénario de cas d’utilisation, l’exécution d’une opération, ou une interaction entre des classes, en mettant l’accent sur la structure du système (Help, 2013).
Le diagramme de communication permet de mettre en évidence les interactions entre les différents objets du système étudié. La communication est réalisée à travers un échange des messages entre les objets. Le diagramme de communication explicite l’organisation spatiale des participants à l’interaction. Les objets peuvent être des instances d’une classe ou des acteurs. Ainsi dans la figure 2.11 représentant le diagramme de communication Réserver un voyage, si on veut enregistrer une réservation, le client en fait la demande au guichetier en donnant les informations le concernant. Sa demande est traitée au niveau du guichet où les informations reçues sont rentrées dans le système après avoir vérifié le nombre de places disponibles. Si sa demande est acceptée, le client reçoit un message informatif de confirmation ; le guichetier peut alors délivrer la facture (billet d’embarquement) au client. Sinon, le client reçoit un massage de non disponibilité de place pour le voyage souhaité.
2.4.5 Diagramme d’activités
Le diagramme d’activités est une machine à états particulière dans laquelle les états sont des activités représentant la réalisation d’opérations et où les transitions sont déclenchées par la fin des opérations (Olivier, 2010). Il représente le déroulement des actions, sans utiliser les objets.
En phase d’analyse, il est utilisé pour consolider les spécifications d’un cas d’utilisation.
Figure 2.11 : Diagramme de communication Réserver un voyage.
Le diagramme d’activités représente les activités que réalisent un ou plusieurs objets. Il peut correspondre à la description en détail d’une activité du diagramme d’états transitions, à la description d’une méthode. Il peut également décrire l’activité d’un système ou d’un soussystème en assignant les responsabilités à chaque acteur. Le diagramme d’activités constitue aussi un bon choix pour décrire un cas d’utilisation.
Nous avons utilisé ce diagramme dans notre travail afin de montrer comment les acteurs interagissent avec le système. Ainsi, le diagramme de la figure 2.11 représente les différentes activités réalisées par le client et le guichetier durant la procédure de réservation.
Figure 2.12 : Diagramme d’activités Réservation.
Tout commence par la création de la réservation par le client. Ensuite, le guichetier vérifie s’il y a des places disponibles ; s’il y en a, le guichetier valide la réservation, sinon il l’annule. Après que le guichetier ait validé la réservation, le client achève le processus de la réservation en complétant les informations nécessaires, sinon il l’annule. Enfin, le guichetier imprime le ticket ou annule la réservation si le client n’a pas payé.
Dans le diagramme d’activités Voyage de la figure 2.13, sont représentées les différentes activités réalisées par le chef d’agence pour créer un voyage. Le chef d’agence crée un nouveau voyage. Si un véhicule est disponible, il l’affecte directement au voyage prévis ; sinon il attend qu’un véhicule soit disponible, ou bien il annule le voyage.
Figure 2.13 : Diagramme d’activités voyage.
Ce chapitre a fait l’objet de la modélisation du nouveau système d’information grâce au langage UML. Ce langage nous a permis de représenter de manière abstraite la façon dont les utilisateurs interagissent avec le système.
En partant des besoins du système d’information de l’agence de voyage précité, nous avons utilisé les diagrammes suivants : le diagramme de cas d’utilisation, le diagramme de classes, le diagramme de séquence, le diagramme de communication et le diagramme d’activités afin de mettre en place ce nouveau système.
[1] Il s’agit de la méthode Booch, de la méthode OMT (Object Modeling Technique) et de la méthode OOSE (Object Oriented Software Engineering).
Afric mémoire est une plateforme web pour le partage des mémoires et TFC entre étudiants du monde entier.
Enregistrer en PDF
Imprimer cette page
