0% ont trouvé ce document utile (0 vote)
59 vues53 pages

Sfe Madispro

Ce document présente un projet de stage de fin d'études dont le but est de réaliser une application web de gestion de production avec le framework Symfony. Le document décrit le contexte du projet, l'organisme d'accueil, les fonctionnalités, technologies et outils utilisés. Il présente également la planification du projet avec les diagrammes de cas d'utilisation et de classes ainsi que le planning.

Transféré par

assia ghannam
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats DOCX, PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
59 vues53 pages

Sfe Madispro

Ce document présente un projet de stage de fin d'études dont le but est de réaliser une application web de gestion de production avec le framework Symfony. Le document décrit le contexte du projet, l'organisme d'accueil, les fonctionnalités, technologies et outils utilisés. Il présente également la planification du projet avec les diagrammes de cas d'utilisation et de classes ainsi que le planning.

Transféré par

assia ghannam
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats DOCX, PDF, TXT ou lisez en ligne sur Scribd

STAGE DE FIN D’ÉTUDE POUR L’OBTENTION

DU DIPLÔME UNIVERSITAIRE DE TECHNOLOGIE

Thème : Réalisation d’une Application Web de


gestion MADISPRO avec le framework Symfony 3

Réalisé par : Maître de stage :


 M. Rizki AKERKAOU M. Zouhair Gabouri
 M. Ayoub BAROUCH

Année universitaire : 2017/2016

Ecole Supérieure de Technologie d’Agadir BP 33/AGADIR. Tél: 0528227824 Site


Web: [Link]
Dédicaces

Avec un grand amour que nous dédions ce travail, à


toute notre famille et nos amis. Particulièrement :

 Nos chers parents pour leur soutien illimité, et


qui grâce à eux nous avons pu atteindre ce niveau.

 Nos professeurs pour leur aide et leur


confiance en nous.

 Nos amis, et tout le personnel du Service de


ArtMedia et BelmoonCommunication.

A tous ceux qui nous sont chers.


Remerciements

Premièrement, nous tenons à exprimer notre gratitude, nos sincères


remerciements à Monsieur Zouhair GABOURI le responsable digital des
Services de ArtMedia, qui a eu l’amabilité de nous accepter au sein
d’ArtMedia.

Nous tenons aussi à adresser notre profonde gratitude à Monsieur


Nasser BELGHITI Directeur générale de la société BELMOON
COMMUNICATION qui a eu l’amabilité de nous accepter au sein de son
équipe et pour son aide offerte chaque fois demandée.

Nos remerciements les plus vifs à tout le personnel d’ArtMedia


pour leur disponibilité qui nous a permettent de mener à bien notre stage.
Sommaire
Table des figures_______________________________________________________7

Liste des tableaux______________________________________________________8

Introduction générale___________________________________________________4

Chapitre 1. Présentation générale_________________________________________6

Introduction_______________________________________________________________6

1.1. Contexte du projet______________________________________________________6

1.2. Présentation de l’organisme d’accueil_______________________________________6


1.2.1. Présentation de ARTMEDIA___________________________________________________6
1.2.2. Secteur d’activité___________________________________________________________7

1.3. Présentation du projet___________________________________________________8


1.3.1. Fonctionnalités_____________________________________________________________8
1.3.2. Contraintes techniques_______________________________________________________9
1.3.3. Technologies et Architecture applicative :_______________________________________10
1.3.4. Outils de développement et de conception :_____________________________________12
1.3.5. Langages de programmation :________________________________________________12

Conclusion_______________________________________________________________13

Chapitre 2. Planification et Architecture général_____________________________14

Introduction______________________________________________________________14

2.1. Captures des besoins___________________________________________________14


2.1.1. Identification des acteurs____________________________________________________14
2.1.2. Diagramme de contexte statique______________________________________________15

2.2. Planning du traitement des cas d’utilisation_________________________________16

2.3. Diagramme de cas d’utilisation global______________________________________20

2.4. Planification des phases_________________________________________________21


2.4.1. Technique de planification : GANTT, PERT, …_____________________________________21
2.4.2. Planning globale de projet___________________________________________________22

Conclusion_______________________________________________________________23

Chapitre 3. Etude et réalisation de la phase technique et maintenance__________24


Introduction______________________________________________________________24

3.1. Diagrammes des cas d’utilisations_________________________________________24

3.2. Conception____________________________________________________________27
3.2.1. Diagrammes de séquences système____________________________________________27
3.2.2. Diagramme de classes_______________________________________________________31

3.3. Réalisation____________________________________________________________32

Conclusion_______________________________________________________________33

Chapitre 4. Etude et réalisation de la phase de production_____________________34

Introduction______________________________________________________________34

4.1. Diagrammes des cas d’utilisations_________________________________________34

4.2. Conception____________________________________________________________36
4.2.1. Diagrammes de séquences système____________________________________________36
4.2.2. Diagramme de classes_______________________________________________________38

4.3. Réalisation____________________________________________________________39

Conclusion_______________________________________________________________40

Chapitre 5. Etude et réalisation de la phase comptes utilisateurs et messagerie___41

Introduction______________________________________________________________41

5.1. Diagrammes des cas d’utilisations_________________________________________41

5.2. Conception____________________________________________________________42
5.2.1. Diagrammes de séquences système____________________________________________43
5.2.2. Diagramme de classes_______________________________________________________44

5.3. Réalisation____________________________________________________________45

Conclusion générale___________________________________________________47
Table des figures

Figure 1_ Le mode de fonctionnement du MVC 11


Figure 2_ Diagramme de contexte statique 15
Figure 3_ Diagramme de cas d’utilisations global 20
Figure 4_ Diagramme de Gantt 23
Figure 5_ Raffinement du cas d’utilisation « Gérer les produits » 25
Figure 6_ Raffinement du cas d’utilisation « Gérer les marques » 26
Figure 7_ Raffinement du cas d’utilisation « Gérer les machines » 27
Figure 8_ Diagramme de séquence d'ajout de produit 28
Figure 9_ Diagramme de séquence de suppression d'une marque 29
Figure 10_ Diagramme de séquence d'ajout d'une maintenance corrective 31
Figure 11_Diagramme de classe de la première phase 32
Figure 12_Tableau de bord 32
Figure 13_Interface d’ajout d’un produit 33
Figure 14_Interface de la liste des machines 33
Figure 15_ Raffinement du cas d’utilisation gérer les demandes d’intervention. 35
Figure 16_ Raffinement du cas d’utilisation « Gérer les ordres de production » 36
Figure 17_ Diagramme de séquence d'ajout d'une demande d'intervention 38
Figure 18_ Diagramme de classe de la deuxième phase 39
Figure 19_ Interface d'ajout d'un ordre de production 39
Figure 20_ Diagramme de cas d’utilisation s'authentifier 41
Figure 21_ Diagramme de cas d'utilisation « Gérer messagerie » 42
Figure 22_ Diagramme de séquence de « S’authentifier » 44
Figure 23_ Diagramme de classe troisième phase 45
Figure 24_ Interface Pré-Inscription 46
Figure 26_ Interface Boite de réception 46
Figure 25_ Interface Modifier Utilisateur 46
Liste des tableaux

Tableau 1_ La technique MoSCoW 16


Tableau 2_ Description des cas d’utilisation 16
Tableau 3_ Liste des tâches 22
Tableau 4_ Description textuelle du cas d’utilisation « Ajouter produit » 28
Tableau 5_ Description textuelle du cas d’utilisation « Supprimer marque » 29
Tableau 6_ Description textuelle du C.U. « Ajouter une maintenance corrective » 30
Tableau 7_ Description de cas d'utilisation <<Ajouter Demande d'intervention>> 37
Tableau 8_ Description textuelle du cas d’utilisation « S’authentifier». 43
Introduction générale

Dans le cadre de notre formation de technicien supérieur à l’Ecole Supérieur de


Technologie d’Agadir, l’établissement cherche à évoluer les compétences et le savoir-faire de
ses étudiants par divers moyens tels que des stages, des projets en classe et des projets de fin
d’études. Pour cela, on a réalisé un projet de stage de fin d’études qui a comme thème «
Réalisation d’une application web avec le framework Symfony pour la gestion de
production » afin de concrétiser nos acquis durant les deux années d’études.

En effet, les systèmes d’informations ont répondu à un besoin vif pour n’importe quel
type d’organisation, c’est la gestion d’information qui est parmi les enjeux les plus
primordiaux pour les entreprises et touche pratiquement toutes les activités telles que la
production, le stockage et la vente.

L’Internet est un système de communication qui permet la communication et l’échange


facile des informations. Ce dernier permet donc, de généraliser l’utilisation des outils
informatiques (logiciel) plus performants avec des clients légers (navigateur web complet et
sans demander l’installation de logiciel sur des machines individuelles). Ceci permet l’accès
aux ressources sans contraintes particulières. Cette technologie permet le développement des
applications pouvant tourner sous différents navigateurs, tout en assurant la sécurité.

Dans ce contexte, on se propose de présenter une solution qui facilite la gestion de la


production, le stock et la vente en suivant la disponibilité des marchandises, les commandes et
en affichant les produits dont le stock est bas, ainsi qu’un petit outil de messagerie intégré
dans le système qui permet la communication interne entre les utilisateurs du système que
nous avons réalisé au sein de l’entreprise ArtMedia.

Pour retracer l’acheminement chronologique de notre travail, le présent rapport a été


subdivisé en plusieurs chapitres :

• Le premier chapitre sera dédié à la « Présentation générale » avec une présentation de


la société et de son secteur d’activité.

• Le deuxième chapitre « Planification », nous commençons par capturer les besoins et


nous allons présenter le diagramme de cas d’utilisation global de notre futur système et nous

4
finissons par une planification des phases et un prototypage des interfaces pour mieux
comprendre les besoins du client.

• Le reste des chapitres décrit la conception et la réalisation des phases 1, 2 et 3. Nous


présentons tout d’abord les diagrammes pour la conception et ensuite nous mettons quelques
interfaces de l’application.

Le rapport s’achève par une conclusion générale rappelant les réalisations essentielles
de notre travail et présentant les perspectives futures de développement de l’application.

5
Chapitre 1. Présentation générale

Introduction

Nous présentons dans ce chapitre une étude préliminaire du projet. Dans un premier
temps, nous présentons l’environnement du stage. Par la suite, nous décrivons la
problématique, ainsi que les principaux objectifs du projet.

1.1. Contexte du projet

Dans le cadre de la formation de Génie Informatique (GI) à l’école supérieur de


technologie (EST), nous avons eu l’occasion d’effectuer notre projet de fin d’études pour
l’obtention du diplôme universitaire de technologie au sein de l’entreprise « ARTMEDIA ».
Généralement ce projet vise à compléter notre formation universitaire acquise, durant deux
ans, au sein de cet établissement, et de nous introduire dans la vie professionnelle grâce à une
mise en pratique de nos connaissances, à l’utilisation des compétences acquises et à mettre en
épreuve notre esprit d’équipe. Le projet consiste à mettre en place un module de gestion de
production et de stock.

1.2. Présentation de l’organisme d’accueil

Cette partie sera consacrée à la présentation de notre organisme d’accueil :


ARTMEDIA.

1.2.1. Présentation de ARTMEDIA

ARTMEDIA est une agence de communication basée à Casablanca qui accompagne


ses clients dans leurs stratégies de communication classiques et digitales se focalisant sur
chacun de leurs besoins dans plusieurs domaines d’expertise, en le conseil stratégique, la
conception, la création et la coordination du design graphique et digital, le développement
d’applications de gestion et l’aide à la décision.

6
Ses visions

MADISPRO croit fermement que son succès passe nécessairement par celui de leurs
clients. Partant de ce principe, il s’engage dans un rapport de partenariat durable et de profit
réciproque avec tous ceux pour qu’il travaille. Pour toutes les solutions qu’il propose, il
veuille à fournir tous les atouts afin d’assurer un retour sur investissement intéressant pour
leurs clients. Avec leurs clients, il ne se contente pas de réaliser un besoin mais il essaye de
les accompagner durant toutes les étapes de leur projet dans une démarche qualité bien
étudiée.

Démarche qualité

Afin d’assurer une qualité irréprochable pour toutes les solutions qu’elle offre,
ARTMEDIA accompagne ses clients dans toutes les phases de réalisation de leurs projets.
Ainsi, ils mettent leur expérience à profit de leur client dès la phase de l’analyse et de
l’élaboration du cahier des charges car un besoin bien étudié et bien exprimé constitue
souvent la pierre angulaire d’un projet réussi. Une fois le besoin du client est fixé, ils
entament une phase de conception de la solution à proposer. Lors de cette étape, ils font appel
aux modèles Unified Modeling Language (UML) pour décrire les différentes fonctionnalités
du nouveau système ainsi que leur déploiement. Ces modèles sont alors discutés avec le client
pour être certains de répondre exactement à ses attentes. Dès la validation de la phase de
conception, ils entament la réalisation de la solution. Au cours de cette phase, les versions
intermédiaires sont présentées régulièrement au client afin qu’il puisse suivre de près l’état
d’avancement de son projet. Une fois la solution est prête pour le déploiement, ils assurent la
mise en place d’une infrastructure adéquate pour une efficacité optimale. Ils cherchent
également à bien former les futurs utilisateurs de l’application pour être certains qu’ils tireront
pleinement profit de leur nouvelle acquisition.

1.2.2. Secteur d’activité


Web Design

ARTMEDIA réalise les projets web tels que la création, le développement, la


maintenance et le web marketing, elle met à la disponibilité de ces clients des compétences en
matière de technologies web, afin de réaliser les attentes dans un projet web.

7
Marketing Digital

ARTMEDIA propose à ses clients un ensemble de services E-Marketing : optimisation


des performances, analyse de besoin, recommandations et conseils, emailing, personnalisation
des profils, élaboration de messages ciblés, gestion de programmes relationnels, suivi
analytique de la fréquentation des supports, attraction visuelle optimale.

1.3. Présentation du projet

De nos jours, les besoins d’une entreprise industrielle sont augmentés d’une façon
exorbitante pour cela on est face à une mise en place d’un logiciel de gestion qui présente
aujourd’hui une base fondamentale au sein d’une entreprise dont son secteur d’activité est la
production.

1.3.1. Fonctionnalités

L’application web serve à :

 Aider à la gestion de la production, le stock, la vente, et les commandes.


 Faciliter la communication interne entre les utilisateurs du système.

L’outil mis à disposition devra de ce fait pouvoir proposer différents services à son
utilisateur :

 Gestion des produits : Consiste à gérer la liste des produits qui sont définis par
des données générales (code, libellé, description et caractéristiques), des
données de structure (les composants), des données de planification (stock
minimum, maximum, stock de sécurité).
 Gestion des marques : Consiste à gérer la liste des marques des produits qui
est une forme de regroupement des produits.
 Gestion des cartons : Consiste à gérer la liste des cartons dans lesquels en met
des produits avec des caractéristiques spécifiques.
 Gestion des gammes de fabrication : Consiste à gérer les étapes de
fabrication d’un produit qui sont la séquence et la durée estimative
d’opérations, les outils nécessaires par opération (postes de charges).

8
 Gestion des postes de charges : Consiste à gérer les postes de charges qui se
focalisent sur l’état de la machine et la disponibilité des opérateurs
(employées). Cette gestion permet de réaliser l’adéquation entre ce que l’on
peut faire (capacité) et ce que l’on doit faire (charge). C’est le calcul de la
charge sur chaque poste de charge et du délai d’obtention des produits.
 Gestion des ressources : Consiste à gérer la liste des ressources qui sont les
employées (qualification des personnes qui exécuteront chaque opération –
Gestion de compétences), les machines (fiches machines–Caractéristiques) et
les outils (fiches outils).
 Gestion des maintenances : Consiste à gérer la liste des interventions qui se
caractérise par leurs types et ses classifications, l’équipement nécessaire et les
compétences requises.
 Gestion des ordres de fabrication : Consiste à gérer les commandes externes
(d’un client) ou internes (au système productif, pour l’approvisionnement des
stocks de semis ouvrés). Chaque ordre est caractérisé par sa date de livraison en
jours ouvrables et une suite ordonnée d’opérations y compris le temps de
chargement et le temps de réglage requis.
 Gestion des commandes : Consiste à gérer la liste des commandes qui sont
définis par (numéro, identifiant du carton, et quantités).
 Gestion des ventes : Consiste à gérer la liste des ventes, afin de permettre à un
vendeur de contrôler un produit quelconque dans le stock dans le cas où la
clientèle le demande. A l’inverse, le magasinier désire également savoir la
disponibilité des produits au magasin afin de régler plus efficacement le stock.
Dès lors, un des buts de cette application permet d’examiner aussi le magasin.
Toutefois, la vente qui a lieu sans cesse nous oblige également à ajuster
souvent les données.
 Gestion des contacts : Consiste à gérer la liste des clients et des fournisseurs
qui se caractérise par leurs noms, prénoms, adresses e-mail, sociétés.
 Gestion des utilisateurs : Consiste à gérer les utilisateurs du système ainsi que
leurs privilèges.

1.3.2. Contraintes techniques

 Modélisation :

9
 Logiciels de modélisation UML (Enterprise Architect) ;
 Langages et outils de programmation :
 PHP ;
 CSS3 ;
 HTML5 ;
 JavaScripts, JQuery …

 Serveur :
 Serveur d’applications : WampServer ;
 Serveur De Base de données : MySQL ;
 Environnements de travail :
 PhpMyAdmin;
 PhpStorm;
 Navigateurs web :
 Le site doit être adapté avec les principaux navigateurs web tels que :
Chrome, Internet Explorer et Mozilla.

1.3.3. Technologies et Architecture applicative :

Afin de réaliser cette application web, nous allons utiliser plusieurs technologies web
et outils informatiques.

Pour le back-office on a utilisées comme langage de programmation coté serveur le


php5 et PhpMyAdmin pour la gestion de la base de données.

Puisque on a utilisé le coté procédurale de PHP dans la réalisation de notre application


web, la maintenance du site pose des problèmes énormes, et ainsi la sécurité reste toujours
non assurée, c’est pourquoi l’utilisation d’un Framework dans la nouvelle version sera très
utile, le Framework utilisé dans notre cas, c’est SYMFONY.

MVC : Model–View–Controller

“MVC” : ”Model-View-Controller” (Modèle / Vue / Contrôleur en français donc).


C’est un design pattern (patron de conception), c’est à dire un concept d’architecture
logicielle pour son application. Il permet d’avoir un code plus structuré, plus évolutif, plus

10
maintenable, permettant de profiter de plusieurs mécanismes, d’avoir de la persistance de
données, et bien d’autres choses encore.

Le “Modèle” est la représentation interne des données. Il permet comme son nom
l’indique de modéliser les données que l’on va manipuler dans l’application. Le modèle
représente les véritables données avec toutes les informations qu’elles véhiculent.

La “Vue” quant à elle est la représentation visuelle de ces données à l’écran. Le


contrôleur enfin, sert à faire l’interface entre le modèle et la vue. En e ffet, puisque le modèle
et la vue sont censés être au maximum indépendants, le contrôleur sert à faire le lien pour
faire communiquer l’un (M) avec l’autre (V).

Ci-dessous, le mode de fonctionnement du MVC :

Figure 1_ Le mode de fonctionnement du MVC

Symfony3

Est un Framework MVC libre écrit en PHP, destiné


Majoritairement aux professionnels du développement. Il fournit
des fonctionnalités modulables et adaptables qui permettent de
faciliter le développement et d’accélérer d'un site web.

Doctrine

Doctrine est un Object-Relational Mapping (ORM)


composé d’énorme fonctionnalités ; à commencer par le DQL
(Doctrine Query Language). Finies les requêtes SQL ! Le DQL

11
vous permet de créer et d’exécuter vos requêtes via le paradigme de la programmation
orientée objet.

Twig

Twig est un moteur de template PHP directement intégré


dans Symfony. Très puissant, Twig permettra de gérer de
l’héritage entre templates et layout, séparer les couches de
présentation et couches métiers... Idéal si vous travaillez en
équipe avec des intégrateurs, qui n’auront qu’à modifier les
templates dans le répertoire views/ de votre bundle en symfony.

1.3.4. Outils de développement et de conception :

Dans cette partie nous allons décrire les outils de développement et de conception
utilisées pour réaliser ce projet.

Enterprise Architect 12.0.1215 Corporate Edition :

Enterprise Architect est un logiciel édité par l'entreprise Sparx


Systems pour créer et éditer les différents diagrammes du modèle UML
(Unified Modeling Language) d'un logiciel.

Enterprise Architect
PhpStorm :

PhpStorm est un éditeur pour PHP, HTML et JavaScript, édité


par JetBrains. Il possède : une coloration syntaxique, affichage des
erreurs à la volée, auto-complétion intelligente du code, Réusinage du
code. Le gros point fort de phpStorm c'est son plugin Symfony 3 et
annotation juste parfait pour du développement sous Symfony 3.

WampServer :

WampServer est une plate-forme de développement Web sous


Windows pour des applications Web dynamiques à l’aide du serveur
Apache, du langage de scripts PHP et d’un serveur de base de données

12
MySQL. Il possède également PHPMyAdmin pour gérer plus facilement les bases de
données.

1.3.5. Langages de programmation :


UML:

Le langage de modélisation unifié, en anglais Unified Modeling


Language (UML), est un langage de modélisation graphique à base de
pictogrammes conçu pour fournir une méthode normalisée pour
visualiser la conception d'un système. Il est couramment utilisé en
développement logiciel et en conception orientée objet.

PHP : HyperText Preprocessor

Le langage PHP est un langage de programmation web côté


serveur, ce qui veut dire que c'est le serveur qui va interpréter le code
PHP (langage de scripts) et Générer du code HTML qui pourra être
interprété par votre navigateur.

HTML & CSS :

L’HyperText Markup Language, généralement abrégé HTML,


est le format de données conçu pour représenter les pages web.

Les feuilles de style en cascade, généralement appelées CSS de


l'anglais Cascading Style Sheets, forment un langage informatique qui
décrit la présentation des documents HTML et XML.

JavaScript :

JavaScript est un langage de programmation de scripts


principalement employé dans les pages web interactives mais aussi pour les
serveurs avec l'utilisation (par exemple) de [Link].

13
Conclusion

Dans ce chapitre introductif, nous avons présenté l’organisme d’accueil ainsi que le
cadre général de notre projet en déterminant la problématique et en proposant la solution
envisagée pour faire face à la situation courante. Nous avons dévoilé le langage et la
méthodologie de conception qui seront utilisés dans les prochains chapitres de ce rapport.

14
Chapitre 2. Planification et Architecture général

Introduction

Ce chapitre s’agit en fait d’une phase de planification et architecture qui ne se termine


pas nécessairement par une livraison. Les travaux réalisés dans cette période conduits à
construire une bonne vision du produit, identifier les acteurs de notre projet, ceux qui
toucheront de façon direct notre application, puis nous allons présenter les besoins de notre
système à travers le diagramme de cas d’utilisation global, finissons par produire le plan de
travail.

2.1. Captures des besoins

Nous procéderons par l’identification des acteurs puis la description des cas
d’utilisation de notre futur projet.

2.1.1. Identification des acteurs

Un acteur, représente un rôle joué par une entité externe qui interagit directement avec
le système. Dans le cadre de notre application les acteurs sont les suivants :

 Administrateur : (D.G. Directeur Général) C’est la personne qui possède le


privilège de plus haut niveau. Cet acteur est capable de manipuler toutes les
fonctionnalités proposées par l’application notamment la gestion des données
techniques des produits, la gestion des équipements, gestion de maintenance,
etc. Ainsi que la gestion des utilisateurs.
 Responsable technique : (D.C. Directeur Commercial) C’est la personne qui
constitue l’ensemble des informations décrivant la structure du système de
production et chaque fois que l’on ajoute ou sort des produits-finis du stock, il
fait l’enregistrement de ces transactions au système. Ainsi entrer et afficher les
informations concernant les commandes.
 Responsable production : (Chimiste) Il planifie et optimise les méthodes de
fabrication et la gestion de production, c’est lui le chef d’orchestre de tout ce
qui entre et qui sort dans les ateliers. Il définit la fiche technique des produits

15
ainsi que ses composants, les machines et les compétences nécessaires à sa
fabrication. Il organise et coordonne la production (planification), affecte à
chaque ressource (machine, homme) une charge de travail. Il gère aussi les
compétences des employées et demande une intervention de maintenance en
cas de panne.
 Responsable maintenance : Il assure la gestion des machines ainsi la
maintenance périodique et les missions de maintenance.

2.1.2. Diagramme de contexte statique

Le diagramme de contexte statique permet de positionner le système dans son


environnement selon un point de vue matériel. Le système est donc décrit physiquement, et
non pas en tenues de fonctionnalités. De plus, pour chaque type d’élément matériel extérieur
au système, il est précisé les nombres minimal et maximal d’éléments, appelés cardinalités,
qui sont mis en jeu.

La Figure 2 illustre le diagramme de contexte statique qui montre les relations des
différents acteurs avec le système. Il spécifie le nombre d’instances de chaque acteur relié.

Figure 2_ Diagramme de contexte statique

16
2.2. Planning du traitement des cas d’utilisation

Après l’identification des cas d’utilisation, nous devons maintenant les classifier. La
classification des cas d’utilisation doit tenir compte d’un facteur principal qui est la priorité.
Cette technique est utilisée généralement lors de la conception des applications se basant sur
le processus unifié, mais elle reste valable et intéressante pour notre cas.

 Priorité :

Le choix des priorités dans cette section s’est basé sur la dépendance entre les
fonctionnalités de l’application. Par exemple, nous ne pouvons pas planifier un ordre de
production sans avoir déterminer les composants d’un produit ainsi que ses étapes de
production. Par conséquent, nous pouvons utiliser la technique MoSCoW pour attribuer les
priorités aux différents cas d’utilisation.

Le tableau 1 représenté les priorités des cas d’utilisation, technique MoSCoW.

Tableau 1_ La technique MoSCoW


Priorité Signification

M (Must have) Spécification obligatoire et fondamentale du système


S (Should have) Spécification importante qui peut être omise sous certaines conditions
C (Could have) Spécification optionnelle, réalisé si on a le temps
W (Could to have) Spécification qui peut attendre les dernières livraisons du système

Dans le tableau suivant, chaque cas d’utilisation est caractérisé par sa priorité, le nom,
la description, et les acteurs principales. Pour le traitement de nos cas d’utilisation nous
faisons le choix de commencer avec les cas d’utilisation les plus prioritaires et plus
importante.

Tableau 2_ Description des cas d’utilisation

Acteurs
Id Nom Priorité Description
Principaux
1 Gestion des M • Afficher la liste des marques qui contient les Responsable
marques champs suivants : libellé, description, nombre technique,
de produits. Administrateur

17
• Rechercher une marque par : libellé,
référence produit.
• Afficher un formulaire d’édition d’une
Responsable
Gestion des marque qui contient les champs suivant :
2 M technique,
marques libellé, description.
Administrateur
• Ajouter, modifier ou supprimer une marque.
• Afficher la liste des produits qui contient les
champs suivants : référence, libellé, marque, Responsable
Gestion des
3 M état en stock (disponible, critique ou épuisé). technique,
produits
• Rechercher un produit par : référence, libellé, Administrateur
marque.
• Afficher un formulaire d’édition d’un produit
qui contient les champs suivant : référence,
Responsable
Gestion des libellé, marque, stock critique, description,
4 S technique,
produits fiche technique, image, . . . en tant que pièce
Administrateur
jointe.
• Ajouter, modifier ou supprimer un produit.
• Saisir les étapes nécessaires à la production
qui doit contenir les champs suivants : numéro
de l’étape, description, durée estimative (en Responsable
Gestion des
5 C heures continues ou discontinues), produits production,
produits
utilisés, équipement utilisé, compétence Administrateur
requise, description textuelle.
• Ajouter, modifier ou supprimer une étape.
• Saisir la liste des matières premier qui le Responsable
Gestion des
6 C compose. production,
produits
• Associer à chaque composant sa quantité. Administrateur
7 Gestion des S • Afficher la liste des machines qui contient les Responsable
machines champs suivants : référence, libellé, maintenance,
fournisseur, sous garantie (oui ou non), contrat Administrateur
de maintenance (oui ou non), date
d’acquisition, état (arrêtée, en production, en
attente de maintenance ou maintenance en

18
cours).
• Rechercher une machine par : référence,
fournisseur, libellé).
• Afficher un formulaire d’édition d’une
machine qui contient les champs suivant :
référence, fournisseur, libellé, date Responsable
Gestion des
8 S d’acquisition, consommation, durée de maintenance,
machines
garantie, contrat de maintenance, fiche Administrateur
technique, image, . . . en tant que pièce jointe ;
• Ajouter, modifier ou supprimer une machine.
• Afficher la liste des maintenances
périodiques.
• Formulaire d’édition d’une maintenance
Responsable
Gestion des périodique qui doit contenir les champs
9 M maintenance,
machines suivants : libellé, description, durée, durée en
Administrateur
activité.
• Ajouter, modifier ou supprimer une
maintenance périodique.
• Afficher la liste des demandes d’intervention
Gestion des
de maintenance qui contient les champs Responsable
demandes
10 M suivants : libellé, description. production,
d’interventions
• Rechercher une demande d’intervention de Administrateur
de maintenance
maintenance par : libellé, référence machine.
• Afficher un formulaire d’édition d’une
Gestion des demande d’intervention de maintenance qui
Responsable
demandes contient les champs suivant : libellé,
11 C production,
d’interventions description.
Administrateur
de maintenance • Ajouter, modifier ou supprimer une demande
d’intervention de maintenance.
12 Gestion des C • Afficher la liste des compétences qui Responsable
compétences contient les champs suivants : libellé, nombre production,
d’employés, nombre de produits. • Rechercher Administrateur
une compétence par : libellé, matricule

19
employé, référence produit.
• Afficher un formulaire d’édition d’une
compétence qui contient les champs suivant : Responsable
Gestion des
13 M libellé, description. production,
compétences
• Ajouter, modifier ou supprimer une Administrateur
compétence.
• Afficher la liste des ordres de production qui
contient les champs suivants : référence
Gestion des Responsable
produit, date début, date fin, nombre d’étapes.
14 ordres de C production,
• Rechercher un ordre de production par :
production Administrateur
référence produit, date, état (pas encore
commencé, en cours, terminé ou suspendu).
• Afficher un formulaire d’édition d’un ordre
de production qui contient les champs suivant :
Gestion des Responsable
référence produit, quantité à produire, date
15 ordres de M production,
début, date fin.
production Administrateur
• Ajouter, modifier ou supprimer un ordre de
production
• Planifier la date début et la date fin de
Gestion des Responsable
chaque étape en tenant compte de la
16 ordres de M production,
disponibilité des machines, des composants et
production Administrateur
des compétences.

20
2.3. Diagramme de cas d’utilisation global

Un cas d’utilisation (use case) représente un ensemble de séquences d’actions réalisées


par le système et produisant un résultat observable intéressant pour un acteur particulier.

Dans cette section nous présentons les besoins de notre système de manière formelle.
C’est-à-dire en utilisant le diagramme des cas d’utilisations du langage de modélisation UML.

La Figure 3 illustre le diagramme des cas d’utilisations global

Figure 3_ Diagramme de cas d’utilisations global

21
2.4. Planification des phases

C’est l’activité qui consiste à déterminer et à ordonnancer les tâches du projet, à


estimer leurs charges et à déterminer les profils nécessaires à leur réalisation. Les objectifs du
planning sont les suivants :

 Déterminer si les objectifs sont réalisés ou dépassés


 Suivre et communiquer l’avancement du projet
 Affecter les ressources aux tâches

Nous avons divisé les tâches en trois phases du système (Technique, Production,
Utilisateur et messagerie).

2.4.1. Technique de planification : GANTT, PERT, …

La construction du planning passe par la modélisation du réseau de dépendance entre


tâches sous forme graphique. Il s’agit d’une décomposition structurée du travail. Il faut
décomposer le projet en sous-ensembles plus simples. Plusieurs représentations existent, à la
base de toute construction de planning :

La technique GANTT : planning à barres

La technique PERT : méthode des potentielles étapes et planning des tâches

Le réseau des antécédents : méthode des potentiels tâche

Nous avons utilisé le diagramme de GANTT, technique et représentation graphique


permettant de renseigner et situer dans le temps les phases, activités, tâches et ressources du
projet. En ligne, on liste les tâches et en colonne les jours, semaines ou mois. Les tâches sont
représentées par des barres dont la longueur est proportionnelle à la durée estimée.

22
2.4.2. Planning globale de projet

Au démarrage du projet, l’analyse du système en place a permis d’identifier ses


tâches :

23
Tableau 3_ Liste des tâches

24
Les Figures 7.15 et 7.16 illustre le diagramme de GANTT présentant le planning du
développement des différents modules et des tâches réalisées.

Figure 4_ Diagramme de Gantt

Conclusion

Dans ce chapitre, nous avons passé en revue par les différentes notions nécessaires à la
compréhension de notre sujet. Nous avons préparé notre plan de travail, nous avons capturé
les besoins fonctionnels de notre application, les rôles des utilisateurs, par la suite nous avons
préparé l’architecture logique ainsi que le plan Gantt de notre projet.

25
Chapitre 3. Etude et réalisation de la phase
technique et maintenance

Introduction

Après avoir connu l’environnement matériel, logiciel et une vision précise sur le
déroulement de notre projet, il ne nous reste que de nous diriger vers les phases qui décrivent
les principaux objectifs et les fonctionnalités de notre futur système.

3.1. Diagrammes des cas d’utilisations

Les besoins à réaliser dans la première phase, ont été spécifiés et pour mieux expliquer
nous allons vous présenter les diagrammes de cas d’utilisation de la gestion des produits, la
gestion des marques, la gestion des commandes, la gestion des machines, et la gestion des
maintenances avec les descriptions textuelles.

 Gérer les produits

L’utilisateur (Administrateur ou Responsable technique) peut consulter la liste des


produits, afficher les détails d’un produit, ajouter (en ajoutant un produit l’utilisateur peut
ajouter une pièce jointe ou ajouter une étape de production), modifier ou supprimer un
produit. En outre, il peut chercher un produit. Chaque produit peut posséder une liste des
composants qui peut être consultée et modifiée par l’utilisateur et une liste des étapes de
production que l’utilisateur peut la consulter, modifier ou supprimer une étape de production.

26
La Figure 5 montre le diagramme de cas d’utilisation de la gestion des produits.

Figure 5_ Raffinement du cas d’utilisation « Gérer les produits »

 Gérer les marques

L’utilisateur (Administrateur ou Responsable technique), peut consulter la liste des


marques, afficher les détails d’une marque, ajouter, modifier, supprimer une marque. En
outre, il peut chercher une marque en se basant sur le critère de recherche et la valeur
cherchée.

27
La Figure 6 montre le diagramme de cas d’utilisation de la gestion des marques.

Figure 6_ Raffinement du cas d’utilisation « Gérer les marques »

 Gérer les machines

L’utilisateur (Administrateur, Responsable Maintenance), peut consulter la liste des


machines, les afficher, ajouter qu’ainsi modifier ou supprimer. D’autres parts, il pourra
l’identifier en se référant sur un critère de recherche et une valeur désirée. En effet, on a la
possibilité pour chaque machine qu’on pourra lui accorder une liste des maintenances
périodiques. Parmi ces tâches, on a l’occasion d’ajouter, supprimer, modifier ou afficher une
maintenance périodique, ainsi qu’on pourra administrer ses maintenances correctives ayant dû
à une demande d’intervention en éclaircissant le symptôme et la panne.

28
La Figure 7 montre le diagramme de cas d’utilisation de la gestion des machines.

Figure 7_ Raffinement du cas d’utilisation « Gérer les machines »

3.2. Conception

Nous effectuons dans ce qui suit les diagrammes de séquence pour chaque cas
d’utilisation de cette première phase.

3.2.1. Diagrammes de séquences système

Dans cette partie nous mettons l’accent sur les diagrammes de séquences qui
représentent les interactions entre objets en indiquant la chronologie des échanges. Cette
représentation peut se réaliser par cas d’utilisation en considérant les différents scénarios
associés.

29
Ajouter produit

Le tableau suivant décrive la description textuelle du cas d’utilisation « Ajouter


produit».

Tableau 4_ Description textuelle du cas d’utilisation « Ajouter produit »

Cas d’utilisation Ajouter produit


Acteur : Administrateur ou Responsable technique.
Pré condition : Utilisateur authentifié.
Post condition : Produit Ajouté.
1. L’utilisateur accède à l’interface d’ajout de produit.
Scénario principal : 2. Le system affiche le formulaire d’ajout.
3. L’utilisateur remplit le formulaire par les
informations adéquates et confirme sa saisie.
4. Le système enregistre les informations saisies et une
vue de succès d’ajout sera affiché.
Exception : L’utilisateur annule l’ajout d’un produit.

La Figure 8 met en évidence le diagramme de séquence d’ajout de produit.

Figure 8_ Diagramme de séquence d'ajout de produit

30
Supprimer une marque

Le tableau suivant décrive la description textuelle du cas d’utilisation « Supprimer


marque ».

Tableau 5_ Description textuelle du cas d’utilisation « Supprimer marque »

Cas d’utilisation Supprimer marque


Acteur : Administrateur ou Responsable technique.
Pré condition : Utilisateur authentifié.
Post condition : Marque Supprimée.
1. L’utilisateur accède à la liste des marques et
Description des scénarios : sélectionner la marque qu’il veut supprimer.
2. L’utilisateur clique sur le bouton supprimer afin de
réaliser l’action delete.
3. Un message de confirmation de choix s’ouvre,
l’utilisateur valide la suppression.
4. Le système supprime la marque et affiche la
nouvelle liste de marque.
Exception : L’utilisateur annule la suppression d’une marque.

La Figure 9 met en évidence le diagramme de séquence de suppression d’une marque.

31
Figure 9_ Diagramme de séquence de suppression d'une marque
Ajouter une maintenance corrective
Le tableau suivant décrive la description textuelle du cas d’utilisation « Ajouter
une maintenance corrective »
Tableau 6_ Description textuelle du C.U. « Ajouter une maintenance corrective »

Cas d’utilisation Ajouter une maintenance corrective


Acteur : Administrateur ou Responsable maintenance.
Pré condition : Utilisateur authentifié et demande de maintenance déjà
existante.
Post condition : Maintenance corrective ajoutée.
1. L’utilisateur affiche la demande d’intervention de
Description des scénarios : maintenance et accède à l’interface d’ajout d’une
maintenance corrective.
2. Le system affiche le formulaire d’ajout.
3. L’utilisateur remplit le formulaire par les
informations adéquates et confirme sa saisie.
6. Le système enregistre les informations saisies et une
vue de succès d’ajout sera affiché.
Exception : L’utilisateur annule l’ajout d’une maintenance
corrective.

La Figure 10 met en évidence le diagramme de séquence d’ajout d’une maintenance


corrective.

32
Figure 10_ Diagramme de séquence d'ajout d'une maintenance corrective
3.2.2. Diagramme de classes

Nous pouvons maintenant construire notre diagramme de classes pour la première


phase en ajoutant les différents éléments (classes, associations, attributs, etc.) déduits à partir
des activités précédentes.

La Figure 11 illustre le diagramme de classes de la première phase.

Figure 11_Diagramme de classe de la première phase

33
3.3. Réalisation

Les Figures 12, 13, 14 présentent respectivement l’interface de tableau de bord,


l’interface d’ajout d’un produit, l’interface de la liste des machines.

Figure 13_Interface d’ajout d’un produit

Figure 12_Tableau de bord

34
Figure 14_Interface de la liste des machines

35
Conclusion

Ce chapitre concerne la gestion des produits, matière première et la maintenance.


Lorsque nous avons terminé cette phase, et après avoir testé les fonctionnalités, on va valider
cette phase. Nous attaquons la deuxième phase qui décrit la gestion de production, des
demandes d’interventions et les ordres de production.

36
Chapitre 4. Etude et réalisation de la phase de
production

Introduction

Ce chapitre décrit la gestion des ordres de production, la gestion des compétences ainsi
que la gestion des demandes d’intervention de maintenance. Nous allons exposer tout d’abord
l’étape de la conception et par la suite la phase de réalisation.

4.1. Diagrammes des cas d’utilisations

 Gérer les demandes d’intervention de maintenance

L’utilisateur (Administrateur ou Responsable production), peut consulter la liste des


demandes d’intervention, afficher les détails, ajouter, modifier ou supprimer une demande
d’intervention. En outre, il peut chercher une demande en se basant sur le critère de recherche
et la valeur cherchée.

La Figure 15 montre le diagramme de cas d’utilisation de la gestion des demandes


d’intervention.

37
Figure 15_ Raffinement du cas d’utilisation gérer les demandes d’intervention.
 Gérer les ordres de productions

L’utilisateur (Administrateur ou Responsable production), pourra lister les ordres de


productions, les affichées, ajouter qu’ainsi modifier ou supprimer. D’autre part, il pourra
l’identifié en se référant sur un critère de recherche et une valeur désirée. En effet, il a la
possibilité pour chaque ordre d’afficher le nombre d’heures de la durée en fabrication en
fonction des étapes à faire, soit en ajoutant ou affichant ses détails. Ainsi qu’il pourra lui
calculer la date fin en saisissant la quantité à produire et vérifiant la disponibilité des
machines, des compétences et des composants.

La Figure 16 montre le diagramme de cas d’utilisation de la gestion des ordres de


productions.

Figure 16_ Raffinement du cas d’utilisation « Gérer les ordres de production »

38
4.2. Conception

Nous effectuons dans ce qui suit les diagrammes de séquence pour chaque cas
d’utilisation de cette première phase.

4.2.1. Diagrammes de séquences système

Dans cette partie nous mettons l’accent sur les diagrammes de séquences qui
représentent les interactions entre objets en indiquant la chronologie des échanges. Cette
représentation peut se réaliser par cas d’utilisation en considérant les différents scénarios
associés.

Ajouter une demande d’intervention

Le tableau suivant décrive la description textuelle du cas d’utilisation « Ajouter une


demande d’intervention ».

Tableau 7_ Description de cas d'utilisation <<Ajouter Demande d'intervention>>

Cas d’utilisation Ajouter une demande d’intervention


Acteur : Administrateur ou Responsable production.
Pré condition : Utilisateur authentifié.
Post condition : Demande d’intervention ajoutée.
1. L’Utilisateur accède à l’interface d’ajout d’une
Scénario principal : demande d’intervention et souhaite ajouter un produit.
2. Le system affiche le formulaire d’ajout.
3. L’utilisateur remplit le formulaire par les
informations adéquates et confirme sa saisie.
4. Le système enregistre les informations saisies et une
vue de succès d’ajout sera affiché.

Exception : L’utilisateur annule l’ajout d’une demande.

39
La Figure 17 met en évidence le diagramme de séquence d’ajout de la demande
d’intervention.

Figure 17_ Diagramme de séquence d'ajout d'une demande d'intervention


4.2.2. Diagramme de classes

Nous pouvons maintenant construire notre diagramme de classes pour la deuxième


phase en ajoutant les différents éléments (classes, associations, attributs, etc.) déduits à partir
des activités précédentes.

40
La Figure 18 illustre le diagramme de classes de la deuxième phase.

Figure 18_ Diagramme de classe de la deuxième phase


4.3. Réalisation

La Figures 19 représente l’interface d’ajout d’un ordre de production

Figure 19_ Interface d'ajout d'un ordre de production

41
Conclusion

L’évaluation de notre projet dans cette phase revêt une importance primordiale dans la
phase de conception, puisque cette expertise permet de diriger l’application vers
éclaircissement. Le premier pas dans cette phase consistait à dessiner les diagrammes de
séquences. Ces diagrammes révèlent qu’ils sont répétitifs. Pour qu’on évite cette répétition
dans la partie qui suit nous choisissons les cas d’utilisations importantes afin d’illustrer ses
diagrammes de séquences.

42
Chapitre 5. Etude et réalisation de la phase
comptes utilisateurs et messagerie

Introduction

Après avoir terminé l’environnement de l’application, logiciel et une vision précise sur
le déroulement de notre projet, il ne nous reste que de nous diriger vers la phase qui
s’intéresse aux principaux objectifs et les fonctionnalités de gestion des comptes utilisateurs
ainsi qu’un outil de messagerie.

5.1. Diagrammes des cas d’utilisations

 S’authentifier

L’utilisateur s’authentifie en saisissant son login et son mot de passe. Le système


vérifie son existence dans la base de données : Si le login et le mot de passe sont valides,
l’utilisateur est connecté au système et il peut par la suite accéder à différentes fonctionnalités
qu’offre l’application. Si le login et le mot de passe sont invalides, une interdiction d’accès est
signalée.

La Figure 20 illustre le diagramme de cas d’utilisation de l’authentification.

Figure 20_ Diagramme de cas d’utilisation s'authentifier

43
 Gérer messagerie

Le système dispose d’un outil de messagerie permet à l’utilisateur de consulter sa boite


de réception afin de lire les messages reçus, il peut répondre à un message, ou bien envoyer
un nouveau message en spécifiant le destinataire, le sujet, le contenu, et ouvrir une nouvelle
conversation avec un autre utilisateur du système.

Figure 21 illustre le diagramme de cas d’utilisation de gestion de la messagerie.

Figure 21_ Diagramme de cas d'utilisation « Gérer messagerie »

5.2. Conception

Nous effectuons dans ce qui suit les diagrammes de séquence pour chaque cas
d’utilisation de cette troisième phase.

44
5.2.1. Diagrammes de séquences système

Dans cette partie nous mettons l’accent sur les diagrammes de séquences qui
représentent les interactions entre objets en indiquant la chronologie des échanges. Cette
représentation peut se réaliser par cas d’utilisation en considérant les différents scénarios
associés.

S’authentifier

Le tableau suivant décrive la description textuelle du cas d’utilisation «


S’authentifier».

Tableau 8_ Description textuelle du cas d’utilisation « S’authentifier».

Cas d’utilisation S’authentifier


Acteur : Utilisateur.
Pré condition : Serveur disponible.
Post condition : Utilisateur authentifié.
1. L’utilisateur accède à l’interface de connexion et
Scénario principal : saisit son login et son mot de passe.
2. Le système vérifie l’existence de l’utilisateur dans la
table user, et le redirige vers l’interface de tableau de bord.
Exception : Si un des champs est invalide, le système affiche un
message d’erreur.

La Figure 22 met en évidence le diagramme de séquence de l’authentification.

45
5.2.2. Diagramme de classes

Nous pouvons maintenant construire notre diagramme de classes pour la première


phase en ajoutant les différents éléments (classes, associations, attributs, etc.) déduits à partir
des activités précédentes.

La Figure 23 illustre le diagramme de classes de la troisième phase.

Figure 23_ Diagramme de classe troisième phase

5.3. Réalisation

46
Les Figures 24, 25 et 26 présentent respectivement l’interface de la pré-inscription,
l’interface de modification d’un utilisateur, et l’interface de la boite de réception.

Figure 24_ Interface Pré-Inscription

Figure 25_ Interface Modifier Utilisateur

Figure 26_ Interface Boite de réception

47
Conclusion générale

Après un mois et demi de stage au sein de la société ArtMedia, nous avons conçu et
développé une application de gestion de production et de maintenance. Le présent manuscrit
détaille toutes les étapes par lesquelles nous sommes passées pour arriver au résultat attendu.
Nous avons essayé tout au long de notre travail de construire notre application phase par
phase. Ce stage de fin d’études nous a permis de découvrir un environnement professionnel
différent de nos expériences précédentes.

Nous avons pu ainsi découvrir le travail en équipe au sein d’un plateau de plusieurs
personnes. Ensuite au niveau du management, nous avons appris à nous organiser, à utiliser
des outils et des méthodes de managements. Malgré toutes les difficultés rencontrées au
niveau du Framework Symfony3 et les bundle FOSUserBundle et SonataBundle et les
contraintes de temps, nous avons réussi à réaliser la totalité de notre application tout en
respectant l’aspect sécuritaire et en préparant la documentation nécessaire.

Finalement, notre travail ne s’arrête pas à ce niveau, en effet plusieurs fonctionnalités


peuvent être ajoutées à notre application notamment le calcul des besoins en composants et en
capacités, suivi des ordres d’approvisionnements et d’achats, inventaire des équipements,
gestion des achats de pièces détachées ou de services (sous-traitance, . . .), gestion des
fournisseurs et une gestion du planning de charge des ressources.

48

Vous aimerez peut-être aussi