Vous êtes sur la page 1sur 16

Table de Matières

Page 1 sur 16
Introduction Générale

De nos jours, la maîtrise des nouvelles technologies IT est un facteur pertinent pour l’intégration
dans le domaine professionnel et de recherche scientifique.
Pour cette raison, le mini-projet C++ présente un rôle crucial pour y adhérer à ce processus et
accomplir les connaissances théoriques et forger les pratiques du développement logiciel.
Notre travail de mini-projet C++ consiste à mettre en œuvre, concevoir et développer avec C++ un
système de gestion de stock, en utilisant différentes technologies : UML, C++, MySQL, Qt.
Par ailleurs, ce rapport de mini-projet C++ contient 3 chapitres :
 1er chapitre intitulé « Spécification des Besoins » : contient les critiques de l’existant, décrit
les besoins fonctionnels, les besoins non fonctionnels, présente UML2 ainsi qu’une mise en
œuvre globale de l’application via un diagramme de Cas d’Utilisation général et diagramme
de séquences de chaque cas d’utilisation.
 2ème chapitre intitulé « Conception» : renferme l’architecture du système, le plan de
conception avec UML en schématisant certains diagrammes statiques et dynamiques ainsi le
schéma relationnel de la Base de Données.
 3ème chapitre intitulé « Réalisation » : expose l’environnement logiciel et matériel, quelques
aspects de l’orienté objet, explicite le script de création de la Base de Données et les
différentes interfaces (screenshots) développées avec Qt ainsi que leur description.

Page 2 sur 16
Partie 1 :
Spécification des
Besoins

Page 3 sur 16
I. INTRODUCTION
Dans ce chapitre, on va entamer la partie « Spécification des Besoins » en définissant les anomalies
de l’Existant, les besoins fonctionnels, les besoins non fonctionnels, une mise en œuvre globale de
UML2 ainsi l’application des diagrammes de Cas d’Utilisation et des diagrammes de Séquence
pour chaque cas d’utilisation.

II. ÉTUDE PRÉALABLE

1. Étude de l’Existant
Le stock des articles est enregistré manuellement dans plusieurs registres, donc il y avait autant de
problèmes rencontrés tels que :
 Une difficulté de suivre le stock sur une période déterminée.
 Pas d’historique (Archives décentralisés)
 Rupture brusque de Stock pour certains produits.
 Désorganisation de Réapprovisionnement

L’application informatique vise à remédier à toutes ces anomalies en centralisant toutes les tâches
via une plateforme.

2. Critiques de l’Existant
Il y avait autant de problèmes rencontrés tels que :
 Une difficulté de suivre le stock sur une période déterminée.
 Pas d’historique (Archives décentralisés)
 Rupture brusque de Stock pour certains produits.
 Désorganisation de Réapprovisionnement

3. Solution envisageable
L’objectif est de mettre en place une application logicielle afin de mieux gérer le stock des articles
et pallier les défaillances existantes dans ce processus.

4. Justification du choix de la Solution


Le but de cette application:
 Gérer la quantité de stock
 Déclencher une alerte lorsque la quantité restante est égale au seuil.
 Gérer les bons d’E/S

III. SPECIFICATION DES BESOINS

Il s’agit d’expliciter la liste des besoins fonctionnels et besoins non fonctionnels.

1. Les Besoins Fonctionnels

- Gestion des Articles : développer toutes les opérations CRUD d’un article (faire les
interfaces avec leurs implémentations.
- Réserver Article : En cas de rupture de stock, le responsable commercial doit réserver un
article à un client.

Page 4 sur 16
- Commander Article : C’est une étape qui vient après la vérification de la disponibilité de la
quantité stock, le client passe une commande contenant un ou plusieurs articles.
- Facturation : Après la validation de la commande, le Comptable prépare une facture au
nom du client.

2. Les Besoins Non-Fonctionnels

- Sécurité de l’application web : implémenter le protocole SSL pour sécuriser toutes les pages
web de l’application.
- Edition des factures : imprimer toutes factures sous le format PDF afin de garder intact
toutes les données de toute modification.

IV. DESCRIPTION DE L'UML


UML est une norme du langage de modélisation objet qui a été publiée, dans sa première version,
en novembre 1997 par l’OMG (Object Management Group), instance de normalisation
internationale du domaine de l’objet.
UML dans sa version 2 propose treize diagrammes qui peuvent être utilisés dans la description d’un
système. Ces diagrammes sont regroupés dans deux grands ensembles.
• Les diagrammes structurels – Ces diagrammes, au nombre de six, ont vocation à
représenter l’aspect statique d’un système (classes, objets, composants…).
– Diagramme de classe – Ce diagramme représente la description statique du système en intégrant
dans chaque classe la partie dédiée aux données et celle consacrée aux traitements. C’est le
diagramme pivot de l’ensemble de
la modélisation d’un système.
– Diagramme d’objets – Le diagramme d’objet permet la représentation d’instances des classes et
des liens entre instances.
– Diagramme de composants (modifié dans UML 2) – Ce diagramme représente les différents
constituants du logiciel au niveau de l’implémentation d’un système.
– Diagramme de déploiement (modifié dans UML 2) – Ce diagramme décrit l’architecture
technique d’un système avec une vue centrée sur la répartition des composants dans la configuration
d’exploitation.
– Diagramme de paquetages (nouveau dans UML 2) – Ce diagramme donne une vue d’ensemble
du système structuré en paquetage. Chaque paquetage représente un ensemble homogène
d’éléments du système (classes, composants…).
– Diagramme de structure composite (nouveau dans UML 2) – Ce diagramme permet de décrire la
structure interne d’un ensemble complexe composé par exemple de classes ou d’objets et de
composants techniques. Ce diagramme met aussi l’accent sur les liens entre les sous-ensembles qui
collaborent.
• Les diagrammes de comportement – Ces diagrammes représentent la partie dynamique
d’un système réagissant aux événements et permettant de produire les résultats attendus par les
utilisateurs. Sept diagrammes sont proposés par UML :
– Diagramme des cas d’utilisation – Ce diagramme est destiné à représenter les besoins des
utilisateurs par rapport au système. Il constitue un des diagrammes les plus structurants dans
l’analyse d’un système.
– Diagramme d’état-transition (machine d’état) – Ce diagramme montre les différents états des
objets en réaction aux événements.
– Diagramme d’activités (modifié dans UML 2) – Ce diagramme donne une vision des
enchaînements des activités propres à une opération ou à un cas d’utilisation. Il permet aussi de
représenter les flots de contrôle et les flots de données.
– Diagramme de séquence (modifié dans UML 2) – Ce diagramme permet de décrire les scénarios

Page 5 sur 16
de chaque cas d’utilisation en mettant l’accent sur la chronologie des opérations en interaction avec
les objets.
– Diagramme de communication (anciennement appelé collaboration) – Ce diagramme est une
autre représentation des scénarios des cas d’utilisation qui met plus l’accent sur les objets et les
messages échangés.
– Diagramme global d’interaction (nouveau dans UML 2) – Ce diagramme fournit une vue
générale des interactions décrites dans le diagramme de séquence et des flots de contrôle décrits
dans le diagramme d’activités.
– Diagramme de temps (nouveau dans UML 2) – Ce diagramme permet de représenter les états et
les interactions d’objets dans un contexte où le temps a une forte influence sur le comportement du
système à gérer.

Figure 1 - Diagrammes de UML 2

V. LA MODELISATION DES BESOINS

On va schématiser notre besoin en un diagramme de contexte statique, comme montré ci-dessous :

1. Diagramme de Contexte Statique

Page 6 sur 16
Figure 2 - Diagramme de Contexte Statique

1.1 Identification des Acteurs


 Le Magasinier : C’est le responsable du magasin qui le gère le flux d’entrée/sortie des
articles et valide la commande passée par un client.
 Le Client : C’est un élément externe au système, peut commander un article et paye sa
facture avec plusieurs modes de règlement.
 Le Comptable : s’occupe de la génération de la facture d’un client et fait le suivi du
payement.

1.2 Description du Diagramme


Ce diagramme donne une idée générale sur notre Système de Gestion de Stocks. Il illustre une vue
globale sur les acteurs le système.

2. Diagramme des cas d'utilisation

Figure 3 - Diagramme des Cas d'Utilisation

Page 7 sur 16
2.1 Description textuelle des Cas d’Utilisation « Commander Article »

 But : détailler les étapes permettant au Client de commander un article.


 Acteur principal : Client.
 Préconditions :
- Notre Système de Gestion de Stocks doit être disponible : un utilisateur est connecté.
 Scénario nominal :
1. Le Client ouvre la page contenant la liste des articles à choisir.
2. Le Client choisit les articles à commander.
3. Le Client enregistre sa commande.

 Scénario alternatif :
A2 : Un article demandé est inexistant au stock
L’enchaînement A2 démarre au point 2 du scénario nominal.
1. Si l’article n’existe pas en stock, un message d’alerte sera affiché au Client que l’article est
épuisé et qu’il va être contacté dans n jours.
2. Un message d’alerte est envoyé au Magasinier que l’article est épuisé et qu’il faut faire un
réapprovisionnement.

 Scénario d’exception
E1 : La commande ne peut pas être enregistrée
Le Client ne peut pas enregistrer sa commande suite à un bug du système

2.2 Description textuelle des Cas d’Utilisation « Commander Article »

 But : détailler les étapes permettant au Client de commander un article.


 Acteur principal : Client.
 Préconditions :
- Notre Système de Gestion de Stocks doit être disponible : un utilisateur est connecté.
 Scénario nominal :
4. Le Client ouvre la page contenant la liste des articles à choisir.
5. Le Client choisit les articles à commander.
6. Le Client enregistre sa commande.

 Scénario alternatif :
A2 : Un article demandé est inexistant au stock
L’enchaînement A2 démarre au point 2 du scénario nominal.
3. Si l’article n’existe pas en stock, un message d’alerte sera affiché au Client que l’article est
épuisé et qu’il va être contacté dans n jours.
4. Un message d’alerte est envoyé au Magasinier que l’article est épuisé et qu’il faut faire un
réapprovisionnement.

 Scénario d’exception
E1 : La commande ne peut pas être enregistrée

Le Client ne peut pas enregistrer sa commande suite à un bug du système

Page 8 sur 16
VI. CONCLUSION
Durant ce chapitre, on a pu finaliser la partie « Spécification des Besoins » en définissant les
anomalies de l’Existant, les besoins fonctionnels et non fonctionnels, une présente de UML2 ainsi
l’application du diagramme de Cas d’Utilisation et des diagrammes de Séquence.
Au chapitre suivant, on pourra définir notre modélisation statique et dynamique afin de mieux
cerner les fonctionnalités de notre application.

Page 9 sur 16
Partie 2 :
Conception

Page 10 sur 16
I. INTRODUCTION
Dans ce chapitre, on va entamer la partie « Conception » en définissant l’architecture de notre
application, la modélisation statique et dynamique, et ce grâce aux diagrammes de Classe, et le
diagramme de Séquence.

II. ARCHITECTURE GLOBALE DU SYSTEME

III. CONCEPTION DE L'ASPECT STATIQUE

I. Diagrammes de classes
5. Étude de l’Existant
Le stock des articles est enregistré manuellement dans plusieurs registres, donc il y avait autant de

Travail demandé
1. Architecture globale du système

2. Conception de l'aspect statique

1. Description des classes


2. Diagrammes de classes

3. Conception de l'aspect dynamique

1. Diagrammes de séquences
2. Diagrammes d'activités

4. Conception du niveau présentation

1. Modèle de navigation
2. Charte graphique

Conclusion
Durant ce chapitre, on a pu finaliser la partie « Conception » en définissant l’architecture de notre
application, la modélisation statique et dynamique.
Au chapitre suivant, on pourra passer au développement des interfaces en toute sérénité.

Page 11 sur 16
Partie 3 :
Réalisation

Page 12 sur 16
I. INTRODUCTION
Dans ce chapitre, on va entamer la partie « Réalisation » en définissant le script de la Base de
Données, l’architecture du système la modélisation statique et dynamique grâce aux diagrammes :
Diagramme de Composants, Diagramme de Déploiement et une brève description de quelques
interfaces de l’application.

Phase 3 : Réalisation

Réalisation de l'application en appliquant les notions de la programmation orientée Objet :

1 - Constructeur et destructeur : Définir pour une classe au moins un constructeur et un destructeur.

2 - Agrégation et association : Présenter un modèle objet comportant plusieurs classes (au moins 3)
avec des relations d'agrégation et d'association.

3 - Héritage : présenter un objet comportant une classe avec au moins deux classes filles de la
première.

Il faut créer l'application avec une Interface Homme Machine Graphique et utiliser des classes
permettant de gérer l'interface graphique de Windows.

L'application doit comporter les éléments graphiques suivants : libellé, zone de


saisie, liste déroulante, case à radio, case à cocher et bouton.

L'application est avec accès à une base de données

Dans tous le mini projet l'interface homme machine de l'application est désormais graphique.

Travail demandé

Le rapport doit comporter les parties suivantes :

1 - Environnement de travail

 Environnement matériel
 Environnement logiciel

2 - Création de la base de données

3 - Implémentation de la partie Orientée Objet

 Constructeurs et destructeur
 Agrégation et association
 Héritage

4 - Les interfaces de l'application

Page 13 sur 16
II. ENVIRONNEMENT DE RÉALISATION

 Environnement Matériel : Ordinateur Portable avec un microprocesseur Intel Dual Core.


 Environnement Logiciel : Windows 7 Pro
 Environnement de Développement C++ : Qt Creator 5
 Environnement de modélisation UML : Visual Paradigm for UML (version 10)
 SGBD : MySQL 5.4

III. CREATION DE LA BASE DE DONNEES

IV. IMPLEMENTATION DE LA PARTIE ORIENTEE OBJET


Une représentation du Modèle Physique se Données (MPD) du système.

V. DESCRIPTION DES INTERFACES DE L‘APPLICATION


Description des différentes interfaces du système à travers un scénario d'exécution

fllustrafif des traitements développés.

VI. Conclusion
Rappel brève des étapes principales du chapitre.

Page 14 sur 16
Conclusion Générale

Ce rapport de mini-projet a été très utile ayant pour but la conception et le développement d’une
application de gestion de stock des articles chez n’importe quelle société.
Naturellement, un tel projet permet de renforcer nos connaissances théoriques et de les mettre en
application dans notre monde professionnel.
Certes, les besoins fonctionnels ont été quasiment achevés, mais certains besoins non fonctionnels
ont été délaissés vu les contraintes temporelles (très peu de temps consacré pour cerner tous les
besoins) pour la livraison de ce rapport et le code source de l’application.
Toutefois, certaines fonctionnalités techniques (implémentation des web services, des tests
unitaires, etc..) peuvent être élaborées prochainement et ce dans un contexte de maintenance
évolutive qui doit être pris en compte afin d’assurer une bonne continuité du système et garantir
une meilleure assurance qualité.
Malgré diverses contraintes, on a pu finalement pallier certaines anomalies de l’ancien système de
gestion de stock grâce à une approche modulaire interactive et interopérable.

Page 15 sur 16
Bibliographie

 SITES WEB

 Programmez avec le langage C++


https://openclassrooms.com/courses/programmez-avec-le-langage-c

 Introduction à Qt
https://openclassrooms.com/courses/programmez-avec-le-langage-c/introduction-a-qt

 Maîtrisez les bases de données avec QtSQL


https://openclassrooms.com/courses/maitrisez-les-bases-de-donnees-avec-qtsql

 LIVRES

 UML 2 ANALYSE ET CONCEPTION, Joseph Gabay & David Gabay (Dunod)

 Apprendre le C++ , Claude Delannoy (Eyrolles)

 UML 2 pour les bases de données, Christian Soutou, (Eyrolles)

 UML 2 par la Pratique, Pascal Roques, (Eyrolles)

Page 16 sur 16