UML: système de gestion des inventaires QR codes
Analyse et conception
2.0 Introduction
Les techniques de programmation n’ont pas cessé de progresser depuis l’époque de la programmation par cartes perforées de nos jours.
Cette évolution a toujours été dictée par le besoin de concevoir et de maintenir des applications toujours plus complexes. La technologie objet est donc la conséquence ultime de la modularisation.
Ce deuxième chapitre traitera donc les étapes fondamentales pour le déroulement et le développement de notre système de gestion des inventaires du patrimoine en permanance avec les QR codes.
Pour la conception et la réalisation de notre application, nous avons donc adopté de modéliser graphiquement à base de pictogrammes, c’est-à-dire de construire un système fiable et stable avec le formalisme UML (Unified Modeling Language), qui s’impose aujourd’hui comme le langage de modélisation objet standardisé pour la conception des logiciels.
Il permet la modélisation des activités de l’entreprise, et est employé dans les projets logiciels, où il offre une flexibilité marquante.
Figure 16: fonctionnalités de l’application QR237
2.1 Présentation UML
UML (Unified Modeling Language) permet de présenter et de manipuler les concepts objet, et de faire une démarche d’analyse qui permet de concevoir une solution de manière itérative grâce aux diagrammes, et d’exprimer visuellement une solution objet.
Il se caractérise comme un langage de modélisation graphique et textuel qui est une étape importante du cycle de développement des systèmes utilisé ainsi pour visualiser, comprendre et définir des besoins, spécifier et construire les documents nécessaires au bon développement d’un logiciel orienté objet, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue.
Ces modèles doivent être proches de la réalité.
* Les points forts d’UML
-UML est un langage formel et normalisé :
- >gain de précision.
- >gage de stabilité.
- >encourage l’utilisation d’outils.
- -UML est un support de communication performant.
- >Il cadre l’analyse.
- >Il facilite la compréhension de représentations abstraites complexes.
- >Son caractère polyvalent et sa souplesse en font un langage universel.
UML propose 13 types de diagrammes dépendants hiérarchiquement et se complètent, pour modéliser un système, selon qu’on veut décrire statique ou dynamique, ces diagrammes sont :
* Représentation statique du système (structurel)
- >Le diagramme de classes.
- >Le diagramme d’objets.
- >Le diagramme de composants.
- >Le diagramme de déploiement.
- >Le diagramme de packages.
- >Le diagramme de cas d’utilisation.
- >Le diagramme de structure composite.
* Représentation dynamique du système (comportemental)
- >Le diagramme d’activité.
- >Le diagramme de séquence.
- >Le diagramme d’état-transition.
- >Le diagramme de collaboration.
- >** Le diagramme de communication.
Pour la modélisation des besoins de notre système, nous utilisons les diagrammes UML suivant :
Diagramme de cas d’utilisation, diagramme de séquence, et le diagramme de classe.
2.2 Diagramme de cas d’utilisation globale
* Identification des cas d’utilisations
Un cas d’utilisation centre l’expression des exigences du système sur ces utilisateurs, ils se limitent aux préoccupations « réelles » des utilisateurs, ils ne présentent pas de solutions d’implémentation et ne forment pas un inventaire fonctionnel du système.
Ils identifient les utilisateurs du système et leur interaction avec celui-ci.
C’est un ensemble de séquences d’actions qui sont réalisées par le système et qui produisent un résultat observable pour un acteur particulier du système, il permet de décrire ce que le futur système devra faire sans spécifier comment il le fera.
Voici les cas d’utilisation de notre application (notre system) :
Authentification : l’application vérifie que c’est bien les utilisateurs (la commission de control ou le chef de service moyen généraux par exemple) qui veulent utiliser le système et les donne ensuite l’autorisation d’accès.
Lire QR Code : l’équipe d’inventaire doit lire les QR code à barre collé dans chaque article afin de générer un fichier texte (c’est l’inventaire physique)
Afficher les investissements : la commission de control et le chef de service de moyen généraux peut consulter la liste de tous les articles avec leur détail.
Recherche des produits par date : lorsque le chef service moyen généraux veut consulter les produits reçu dans certain intervalle périodique, il doit saisir ce dernier et l’application affichera les produits dont leur date d’acquisition correspond à l’intervalle entré.
Récupérer données : la commission de control doit récupérer les données à partir du lecteur de QR code afin de calculer les écarts et savoir l’emplacement de chaque articles.
Calcul écart positif : après la récupération, la commission veut savoir s’il y’a des articles qui ne sont pas enregistré dans sa base de données et se retrouve dans son patrimoine.
Calcul écart négatif : cette opération ce fait après la récupération de données, la commission veut contrôler s’il n’y pas de manque dans son patrimoine par rapport à ces données enregistrées au niveau de la base de données.
Les articles déplacés : l’application répond à cette fonctionnalité en montrant les articles mal placé (les articles qui ne sont pas dans leurs bons emplacements).
Imprimer les QR codes des articles : l’application lance l’impression des étiquettes de QR codes pour tous les articles.
Imprimer les articles par site : cette fonctionnalité est utile lorsque l’utilisateur veut imprimer les articles par site…
Il doit sélectionner le site, et l’application imprimera la fiche détaillée du site ou bien les QR codes des investissements de site sélectionner (selon le choix de l’utilisateur).
Le diagramme de cas d’utilisation (use case diagram) est le premier diagramme du modèle UML utilisé pour la modélisation des besoins des utilisateurs.
Les cas d’utilisations décrivent le comportement du système étudié du point de vue de l’utilisateur, et décrivent les possibilités d’interactions fonctionnelles entre le système et les acteurs, ils permettent de définir les limites et les relations entre le système et son environnement.
Il est destiné à structurer les besoins des utilisateurs et les objectifs par rapport au système.
C’est donc l’image d’une fonctionnalité en réponse à la simulation d’un acteur externe. Il s’agit de la solution UML pour représenter le modèle conceptuel.
>Les use cases permettent de structurer les besoins des utilisateurs et les objectifs correspondants d’un système.
>Ils centrent l’expression des exigences du système sur ses utilisateurs : ils partent du principe que les objectifs du système sont tous motivés.
>Ils se limitent aux préoccupations «réelles» des utilisateurs. Ils identifient les utilisateurs du système (acteurs) et leur interaction avec le système.
>Ils permettent de classer les acteurs et structurer les objectifs du système.
Les diagrammes des cas d’utilisation (DCU) sont des diagrammes UML utilisés pour une représentation du comportement fonctionnel d’un système logiciel. Ils sont utiles pour des présentations auprès de la direction ou des acteurs d’un projet, mais pour le développement, les cas d’utilisation sont plus appropriés.
Pour le cas de notre conception, nous avons retenus le diagramme des cas d’utilisation suivant :
Figure 17: diagramme des cas d’utilisation de l’application de gestion d’inventaire en utilisant le QR code
2.3 Raffinement des Diagrammes de cas d’utilisation
* Cas d’utilisation «Créer un compte»
Figure 18: Diagramme de cas d’utilisation « Gérer les utilisateurs »
Tableau 1 : Description Textuelle «Créer un compte»
| Cas d’utilisation | Créer un compte |
| Acteurs | Administrateur, utilisateur |
| Pré condition | Etre un membre de la plateforme |
| Description du scénario (Scénario Nominale) | L’acteur demande de s’inscrire à la plateforme Le système affiche le formulaire d’inscription L’acteur remplit le formulaire avec l’ensemble des informations nécessaires à son inscription et les valide Le système vérifie l’existence du nom de l’utilisateur Le système vérifie les informations saisies par l’utilisateur Le système créé le compte utilisateur Le compte est créé |
| Post condition | Inscription achevée et le système rédige l’utilisateur vers la page d’authentification |
| Exception (Scénario alternatif) | Champ obligatoire vide ; 8. Le système affiche un message d’erreur |
La figure suivante représente le diagramme de cas de séquence système « Créer un compte»
Figure 19: Diagramme de cas de séquence système « Créer un compte »
Tableau 2 : Description Textuelle «S’authentifier»
| Cas d’utilisation | S’authentifier |
| Acteurs | Administrateur, utilisateur |
| Pré condition | Etre un membre de la plateforme |
| Description du scénario (Scénario Nominale) | L’acteur demande de se connecter Le système affiche le formulaire de connexion L’acteur remplit le formulaire avec les informations nécessaires Le système vérifie les informations saisies par l’utilisateur Le système vérifie l’activation de l’utilisateur Le système affiche la page principale |
| Post condition | Authentification réussie |
| Exception (Scénario alternatif) | Si les coordonnées ne sont pas correctes : demande de ressaisir les données Si l’utilisateur n’est pas activé : Demande d’activation |
Figure 20: Diagramme de cas de séquence système« S’authentifier »
2.4 Diagramme de classes entités
Le diagramme de classe constitue un élément très important de la modélisation : il permet de définir quelles seront les composantes du système final.
Il représente les classes intervenant dans le système. 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.
* Son utilisation
Le diagramme des classes est un schéma utilisé en génie logiciel pour présenter les classes et les interfaces des systèmes ainsi que leurs relations.
Ce diagramme fait partie de la partie statique d’UML, qui ne s’intéresse pas aux aspects temporels et dynamiques. Pour le cas de notre projet, nous avons utilisés le logiciel de modélisation StarUML pour réaliser notre diagramme des classes.
* Identification des classes
Une classe est une description d’un groupe d’objets partageant un ensemble commun de propriétés (les attributs), de comportements (les opérations) et de relations avec d’autres objets (les associations et les agrégations).
Une classe contient
Des attributs : (ou champs, ou variables d’instances) : Les attributs d’une classe est une caractéristique d’un objet, décrivent la structure de ses instances (les objets). Un attribut souligné correspond à un attribut de classe.
Les méthodes : (ou opérations de la classe) : Les méthodes décrivent les opérations qui sont applicables aux instances de la classe. C’est un service dont un objet peut demander l’exécution.
La Multiplicité : sert à compter le nombre minimum et maximum de possibilité que chaque classe contient dans la relation liant deux ou plusieurs classes.
Une agrégation : Il s’agit d’une relation entre deux classes, spécifiant que les objets d’une classe sont des composants de l’autre classe.
C’est donc une association qui, lorsqu’elle est lue dans un sens signifie «est une partie de» et lorsqu’elle est lue dans l’autre sens elle signifie «est composé de».
Une composition : Forme d’agrégation quand l’ensemble ou « composé » est responsable de la création et de la destruction de ses parties.
- Le Composant n’existe que dans l’association au composé.
- La partie (composant) n’existe pas sans l’agrégat (composé).
- Si le composé (agrégat) disparaît le composant (partie) disparaît aussi
Généralisation, superclasse, sous-classe :
Une superclasse est une classe plus générale reliée à une ou plusieurs autres classes plus spécialisées (sous-classes) par une relation de généralisation.
Les sous-classes «héritent des propriétés de leur superclasse et peuvent comporter des propriétés spécifiques Supplémentaires.
Les classes sur lesquelles se porte notre application sont les suivantes :
User : c’est la classe qui contient les identifiants et les mots de passe des utilisateurs de l’application.
Produit : c’est la classe qui contient les produits disponibles en stock, avec leurs caractéristiques ainsi que les différentes opérations exécutables sur les produits.
Admin : c’est la classe qui contient l’identifiant et le mot de passe de l’administrateur de la plateforme de gestion d’inventaire.
Catégorie : c’est la classe qui contient l’ensemble des catégories des produits gérer par l’entreprise avec QR237, ainsi que les fonctions applicables à ces dernières.
QR code : c’est la classe qui va contenir toute les images des QR codes des produits enregistrés dans la base de données, et les actions effectuables sur eux.
* Compréhension des règles
>Un utilisateur peut ajouter un ou plusieurs produits.
>Un produit peut être ajouté par un et un seul utilisateur.
>A une catégorie peut appartenir un ou plusieurs produits.
>Un produit peut appartenir à une et une seule catégorie.
>Un produit peut posséder un unique QR code.
>Un QR code peut posséder un unique produit.
A l’aide des règles précédentes, on est arrivé à construire le diagramme de classe suivant :
Figure 21: diagramme des classes de l’application de gestion d’inventaire en utilisant le QR code : QR237.
2.5 Diagramme dynamique (diagramme de séquence de cas d’utilisation)
Le diagramme de séquence suit le diagramme de cas d’utilisation car il le complète.
Il permet de décrire les scénarios (déroulement des traitements entre les éléments du système et les acteurs) de chaque cas d’utilisation en mettant l’accent sur la chronologie des opérations en interaction avec les objets.
En particulier, il montre aussi les objets qui participent à l’interaction par leur «ligne de vie» et les messages qu’ils échangent présentés en séquence dans le temps.
Voici quelques notions de base du diagramme:
– Scénario : une liste d’actions qui décrivent une interaction entre un acteur et le système.
-Interaction : un comportement qui comprend un ensemble de messages échangés par un ensemble d’objets dans un certain contexte pour accomplir une certaine tâche.
-Message : Un message représente une communication unidirectionnelle entre objets qui transporte de l’information avec l’intention de déclencher une réaction chez le récepteur.
* Diagramme de séquence pour «authentification»
Notre system peut être utilisé par 2 acteur qui doivent entrez un nom d’utilisateur et un mot de passe, C’est l’opération d’authentification.
Ce diagramme présente le scénario qui se passe entre l’utilisateur et le system : C’est à dire l’utilisateur qui est l’agent exécute l’application. Notre application affiche le formulaire d’authentification.
L’agent saisit le login et le mot de passe, le système de sa part vérifie la validité des valeurs entré qui affichera par la suite la page d’accueil, sinon erreur. Tous les autres diagrammes se réfèrent à ce dernier.
Figure 22: Diagramme de séquence pour l’authentification.
* Diagramme de séquence pour «imprimer les articles par site «
Pour consulter la liste des articles correspondent à un site ; l’utilisateur doit sélectionner dans un premier temps le site concerné ; après validation, les biens répondent à la demande de l’agent vont être affiché suite à l’exécution d’une requête sur la base de données.
Figure 23 : Diagramme de séquence pour «imprimer les articles par site».
* Diagramme de séquence pour «recherche par date»
Dans cette partie le chef de service des moyens généraux peut effectuer une recherche sur un article par date d’acquisition.
Toujours un dialogue se déroule entre l’agent, notre système et la base de données. >L’utilisateur demande le formulaire correspondant à la recherche, ce dernier va être affiché par l’application.
>L’agent saisit alors l’intervalle périodique correspondant aux articles qu’on veut consulter.
Notre système envoi les données entrée à la BDD.
>Une requête est exécutée au niveau de la BDD, auquel se charge par la suite l’entité à rechercher vers le système qui l’affiche par la suite à l’agent.
Figure 24 : Diagramme de séquence pour «recherche par date».
* Diagramme de séquence pour «afficher fiche investissement»
Lorsque l’utilisateur veut consulter les détails d’un article ; il doit sélectionner l’investissement considéré pour l’affichage.
Figure 25 : Diagramme de séquence pour «Afficher fiche d’investissement «.
* Diagramme de séquence pour «imprimer fiche investissement»
Lorsque l’utilisateur consulte une fiche d’investissement d’un article, il a aussi la possibilité de l’imprimer.
Figure 26 : Diagramme de séquence pour «Imprimer fiche investissement».
* Diagramme de séquence pour «Paramètres d’impression»
Les étiquettes des QR codes peuvent prendre plusieurs paramètres pour l’impression selon le choix de l’utilisateur.
Lorsque ce dernier veut modifier ces paramètres, il doit accéder à la fenêtre paramètre d’impression, là où il peut connaitre les paramètres par défaut et les modifier, enfin il doit valider le changement.
Figure 27 : Diagramme de séquence pour «Paramètres d’impression».
La modélisation et la conception de la base de données, et des interactions des différents acteurs avec le système est une étape indispensable à la réalisation des applications comme QR237, car de façon technique il s’agit des interactions entre des QR code que l’on scanne par un mobile pour accéder aux produits logés dans une base de données distante d’un serveur.
