Table de Matières

Introduction Générale .......................................................................................................................... 3

Partie 1 : Spécification des Besoins ................................................................................................. 4
I. INTRODUCTION ............................................................................................................... 5
II. ÉTUDE PRÉALABLE ........................................................................................................ 5
1. Étude de l’Existant ......................................................................................................... 5
2. Critiques de l’Existant.................................................................................................... 5
3. Solution envisageable .................................................................................................... 5
4. Justification du choix de la Solution .............................................................................. 5
III. SPÉCIFICATION DES BESOINS.................................................................................... 5
1. Les Besoins Fonctionnels............................................................................................... 5
2. Les Besoins Non-Fonctionnels ...................................................................................... 6
IV. DESCRIPTION DE L'UML .............................................................................................. 6
V. LA MODÉLISATION DES BESOINS ............................................................................... 7
1. Diagramme de Contexte Statique .................................................................................. 7
1.1 Identification des Acteurs ........................................................................................... 8
1.2 Description du Diagramme ........................................................................................... 8
2. Diagramme des cas d'utilisation..................................................................................... 8
2.1 Description textuelle des Cas d’Utilisation « Commander Article » ............................ 9
VI. CONCLUSION.................................................................................................................. 9
Partie 2 : Conception ...................................................................................................................... 10
I. INTRODUCTION ............................................................................................................. 11
II. ARCHITECTURE GLOBALE DU SYSTÈME................................................................ 11
III. CONCEPTION DE L'ASPECT STATIQUE .................................................................. 11
1. Diagramme de classes .................................................................................................. 11
IV. CONCEPTION DE L'ASPECT DYNAMIQUE ............................................................. 12
1. Diagramme de Séquences ............................................................................................ 12
V. Conclusion ......................................................................................................................... 12
Partie 3 : Réalisation ...................................................................................................................... 13
I. INTRODUCTION ............................................................................................................. 14
II. ENVIRONNEMENT DE RÉALISATION ....................................................................... 14
III. CRÉATION DE LA BASE DE DONNÉES ................................................................... 14
IV. IMPLÉMENTATION DE LA PARTIE ORIENTÉE OBJET ........................................ 14
V. DESCRIPTION DES INTERFACES DE L‘APPLICATION........................................... 15
VI. CONCLUSION................................................................................................................ 15
Conclusion Générale .......................................................................................................................... 16

Page 1 sur 17
Bibliographie ...................................................................................................................................... 17

Page 2 sur 17
 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 3 sur 17
 Partie 1 :
Spécification des
Besoins

Page 4 sur 17
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 5 sur 17
 - 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 6 sur 17
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 7 sur 17
 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 8 sur 17
 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

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 17
 Partie 2 :
Conception

Page 10 sur 17
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

Notre système utilise les widgets Qt C++ qui sont à leurs traduits en cpp pour être exécutés.

Figure 4- Diagramme de déploiement

III. CONCEPTION DE L'ASPECT STATIQUE

1. Diagramme de classes

Page 11 sur 17
 Figure 5 - Diagramme de Classes

IV. CONCEPTION DE L'ASPECT DYNAMIQUE

1. Diagramme de Séquences

V. 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 12 sur 17
 Partie 3 :
Réalisation

Page 13 sur 17
I. INTRODUCTION
Dans ce chapitre, on va entamer la partie « Réalisation » en définissant l’environnement de travail,
le script de la Base de Données, l’implémentation de la Partie Orienté Objet et une brève
description de quelques interfaces de l’application.

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 : Sqlite 3

III. CREATION DE LA BASE DE DONNEES

Client (idClt, nomClt, adresseClt, telClt, emailClt, #refCmd)
Commande (refCmd, dateCmd)
Facture (numFact, dateFact, typeReglement, montantFact)
Article (refArtic, libelleArtic, prixArtic)

IV. IMPLEMENTATION DE LA PARTIE ORIENTEE OBJET

#include "mainwindow.h"
#include "ui_mainwindow.h"

 Constructeur prédéfini de la fenêtre d’affichage

MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
}

 Destructeur prédéfini de la fenêtre d’affichage

MainWindow::~MainWindow()
{
delete ui;

Page 14 sur 17
}

V. DESCRIPTION DES INTERFACES DE L‘APPLICATION

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

VI. CONCLUSION
Durant ce chapitre, on a pu finaliser la partie « Réalisation » en définissant l’environnement de
travail, le script de la Base de Données, l’implémentation de la Partie Orienté Objet et une brève
description de quelques interfaces de l’application.

Page 15 sur 17
 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 16 sur 17
 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 17 sur 17