Conception et réalisation d'un système d'information de gestion du stock pour des boissons aromatisées aux fruits.

Chapitre II :

Conception

Introduction :

Après avoir connu la situation existante dans le chapitre précédent et compris le fonctionnement du système actuel, nous allons présenter dans ce chapitre la conception et la modélisation du futur système (application).

La phase de conception nécessite des méthodes ou des langages permettant la mise en place d'un modèle sur lequel on va s'appuyer, nous avons décidé de choisir le langage de modélisation UML en passant par la démarche suivante :

Choix de la démarche :

Présentation du modèle :

La présentation d'un modèle se compose de plusieurs documents en langage courant et d'un document formalisé, elle ne doit en aucun cas se limiter au seul document formalisé car celui- ci est pratiquement incompréhensible si on le présente seul.

Ses objectifs sont de comprendre, de concevoir, de communiquer et de documenter la solution informatique apportée à un système.

Elaboration du modèle :

Le modèle est réalisé par étapes successives, chaque étape enrichissant et précisant les résultats de la précédente.

On doit préciser le processus d'élaboration des modèles, pour cela nous avons choisi le processus de développement en cascade qui découpe le projet en phase distinct, lorsqu'une phase est achevée, son résultat sert de point d'entrée à la phase suivante, les unes après les autres.

L'avantage de ce processus est de proposer exactement une démarche de réduction des risques en minimisant l'impact des incertitudes.

L'inconvénient est l'exclusion de l'utilisateur dès la phase conception car elle est trop technique.

Figure 3 : Le modèle en cascade du langage UML

II.3.Définition d'UML :

UML << Unified Modeling language >> ou encore en français << Un langage de modélisation unifié >> offre un standard de modélisation, pour représenter l'architecture logicielle, il offre une manière claire de représenter le système selon différentes vues complémentaire grâce aux diagrammes qu'il fournit.

Ce langage est né de la fusion de plusieurs méthodes existantes auparavant :

· OMT (objet Modeling Techniq) de JAMESRUBGH.

· OOD (objet Oriented Design) de GRAY BOOCH.

· OOSE (Objet Oriented Softwer Engunering) de IVRA JACOBSON.

Les diagrammes UML :

UML permet de définir et de visualiser un modèle, à l'aide de diagrammes. Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis du modèle.

Chaque type de diagramme UML possède une structure (les types des éléments de modélisation qui le composent sont prédéfinis) et véhicule une sémantique précise (il offre toujours la même vue d'un système). Combinés, les différents types de diagrammes UML offrent une vue complète des aspects statiques et dynamiques d'un système.

UML 2.0 comporte treize types de diagrammes représentant autant de vues distinctes pour représenter des concepts particuliers du système d'information. Ils se répartissent en deux grands groupes :

· Diagrammes structurels ou diagrammes statiques :

Ø Diagramme de classes.

Ø Diagramme d'objets.

Ø Diagramme de composants.

Ø Diagramme de déploiement.

Ø Diagramme de paquetages.

Ø Diagramme de structures composites.

· Diagrammes comportementaux ou diagrammes dynamiques :

Ø Diagramme de cas d'utilisation.

Ø Diagramme d'activités.

Ø Diagramme d'états-transitions.

Ø Diagramme de séquence.

Ø Diagramme de communication.

Ø Diagramme global d'interaction.

Ø Diagramme de temps.

Dons notre projet, nous avons utilisé 3 digrammes qui sont les plus utilisés lors de la modélisation (cas d'utilisation, séquence, classes).

Les avantages et les inconvénients d'UML :

Les avantages :

Ø UML est un langage formel et normalisé : il permet un gain de précision, de stabilité et il encourage l'utilisation d'outils.

Ø UML est un support de communication performant : il permet grâce à sa notation graphique d'exprimer visuellement une solution objet, de faciliter la comparaison et l'évolution des solutions.

Ø Son caractère polyvalent et sa souplesse en font un langage universel.

Les inconvénients :

La mise en pratique d'UML nécessite un apprentissage qui passe par une période d'adaptation.

Analyse des besoins et Spécification :

Analyse des besoins :

L'analyse des besoins est la première étape de la conception qui consiste à analyser la situation pour tenir compte des contraintes et des risques.

C'est une méthode qui permet de caractériser le besoin exprimé.

Notre système doit faire la mise à jour du fichier auxiliaire, avec des entrée est des sorties des articles et permettre aussi de faire la comparaison entre le fichier auxiliaire et le physique existant lors des inventaires et de faire ressortir, par la suite, les différences.

Ce système permet au responsable de contrôler le patrimoine de son entreprise et de lui permettre de suivre son développement futur.

Ces informations doivent être fiables, synthétiques et disponibles.

II.5.1.1.Spécification :

Pour les vues dynamiques, on montre le fonctionnement et le comportement du système résultant de la spécification, ce qui permet d'utiliser le « diagramme de cas d'utilisation ».

Diagramme de cas d'utilisation :

· Définition :

Le diagramme de cas d'utilisation représente la structure des grandes fonctionnalités nécessaires aux utilisateurs du système. C'est le premier diagramme du modèle UML, celui où s'assure la relation entre l'utilisateur et les objets que le système met en oeuvre.

Il permet de décrire l'interaction entre les trois concepts suivants :

· Acteur : est l'idéalisation d'un rôle joué par une personne externe, un utilisateur type qui a toujours le même comportement vis-à-vis d'un cas d'utilisation (qui interagit avec un système)

· Cas d'utilisation : Un cas d'utilisation est une unité cohérente d'une fonctionnalité visible de l'extérieur. Il réalise un service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l'acteur qui l'initie.

Un cas d'utilisation modélise donc un service rendu par le système, sans imposer le mode de réalisation de ce service.

Un cas d'utilisation se représente par une ellipse contenant le nom du cas (un verbe à l'infinitif).

· Identification des acteurs :

L'étude préliminaire des besoins fonctionnels a révélé la présence de 4 acteurs :

· Responsable des achats

· Responsable des ventes

· Magasinier

· Gestionnaire de stock et de magasin

Diagramme de cas d'utilisation générale :

Figure 4 : diagramme de cas d'utilisation générale

Nous détaillons dans ce qui suit les cas d'utilisations suivantes :

· Gestion de commandes produites finis

· Gestion des ventes

· Gestion des produits en stocks

· Contrôle l'état des stocks

Diagramme de cas d'utilisation des commandes produits finis :

Figure 5 : diagramme de cas d'utilisation des commandes produits finis

Diagramme de cas d'utilisation gestion des ventes :

Figure 6 : diagramme de cas d'utilisation gestion des ventes

Diagramme de cas d'utilisation gestion des produits en stocks :

Figure 7 : Diagramme de cas d'utilisation gestion des produits en stocks

Conception :

Introduction :

Cette partie représente le système physique et l'interaction du système, les diagrammes utilisés lors de cette phase sont les diagrammes de séquence et de classe.

Diagramme de séquence :

Définition :

Le diagramme de séquence est un diagramme d'interaction mettant l'accent sur la chronologie

de l'envoi des messages.

  Montrer explicitement les interactions pouvant intervenir entre des objets.

  Représenter les interactions en favorisant une vision temporelle de celles-ci.

  Préciser la chronologie des interactions en précisant les contraintes temporelles.

Le diagramme de séquences permet de cacher les interactions d'objets dans le cadre d'un scénario d'un diagramme des cas d'utilisation. Dans un souci de simplification, on représente l'acteur principal à gauche du diagramme, et les acteurs secondaires éventuels à droite du système. Le but étant de décrire comment se déroulent les actions entre les acteurs ou objets.

La dimension verticale du diagramme représente le temps, permettant de visualiser l'enchaînement des actions dans le temps, et de spécifier la naissance et la mort d'objets. Les périodes d'activité des objets sont symbolisées par des rectangles, et ces objets dialoguent par le biais de messages.

Diagramme de séquence cas authentification :

Figure 8 : Diagramme de séquence cas authentification

Diagramme de séquence ajouter client :

Figure 9 : Diagramme de séquence ajouter client

Diagramme de séquence ajouter paiement :

Figure 10 : Diagramme de séquence ajouter paiement

II.5.4.5.Diagramme de séquence établir commande :

Figure 11 : Diagramme de séquence établir commande

Diagramme de séquence établir PV réception :

Figure 12 : Diagramme de séquence établir PV réception

Diagramme de séquence établir bon de commande :

Figure 13 : Diagramme de séquence établir bon de commande

Diagramme de séquence établir bon de sortie :

Figure 14 : Diagramme de séquence établir bon de sortie

Diagramme de séquence établir facture :

Figure 15 : Diagramme de séquence établir facture

Diagramme de séquence imprimer PV réception :

Figure 16 : Diagramme de séquence imprimer PV réception

Diagramme de séquence imprimer bon de commande :

Figure 17 : Diagramme de séquence imprimer bon de commande

Diagramme de séquence imprimer bon de sortie :

Figure 18 : Diagramme de séquence imprimer bon de sortie

Diagramme de séquence imprimer facture :

Figure 19 : Diagramme de séquence imprimer facture

Diagramme de séquence modifier client :

Figure 20 : Diagramme de séquence modifier client

Diagramme de séquence modifier PV réception :

Figure 21 : Diagramme de séquence modifier PV réception

Diagramme de séquence modifier commande :

Figure 22 : Diagramme de séquence modifier commande

Diagramme de séquence recherche produit :

Figure 23 : Diagramme de séquence recherche produit

Diagramme de séquence supprimer client :

Figure 24 : Diagramme de séquence supprimer client

Diagramme de séquence supprimer commande :

Figure 25 : Diagramme de séquence supprimer commande

Diagramme de classe :

Définition :

Le diagramme de classes est considéré comme le plus important de la modélisation orientée objet, il est le seul et l'obligatoire lors d'une telle modélisation.

Il s'agit d'une vue statique, car on ne tient pas compte du facteur temporel dans le comportement du système.

Chaque langage de Programmation « orienté objet » donne un moyen spécifique d'implémenter le paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais le diagramme de classes permet de modéliser les classes du système et leurs relations indépendamment d'un langage de programmation particulier.

Objectifs :

Le diagramme de cas d'utilisation montre un système du point de vue des acteurs, alors que le diagramme de classes en montre la structure interne.

Le diagramme de classes permet de représenter l'ensemble des informations finalisées qui sont gérées par le domaine. Ces informations sont structurées, c'est-à-dire qu'elles sont regroupées dans des classes.

Structuration du diagramme de classe :

Le diagramme de classes modélise les concepts du domaine d'application ainsi que les concepts internes créés de toutes pièces dans le cadre de l'implémentation d'une application.

Le diagramme de classes met en oeuvre des classes, contenant des attributs et des opérations, et reliées par des associations ou des généralisations.

Règles de gestion :

Avant d'établir le diagramme de classe, il fallait déterminer les principales règles de gestion. Le diagramme de classe du système se base sur les règles de gestion suivantes :

· Un client et caracteriser pas son ID , nom , prénom , adresse , email, numéro téléphone, numéro registre de commerce, numéro matricule fiscale, peut passer une ou plusieurs commandes, la commande concerne un seul client.

· Une commande peut contenir un ou plusieurs produits finis, le produit peut être dans plusieurs commandes.

· Une commande concerne plusieurs factures, et la facture concerne une seul commande

· Une facture concerne plusieurs PV de réception et le PV de réception concerne une seul facture

· II.6.1.4.Description des classes :

La collection et l'analyse des informations nous a permis d'établir le dictionnaire de données ci-dessous :

La Classe	Codification	Désignation	Type
Client	ID_Client	Identificateur du client	Integer
	Nom_C	Nom du client	Varchar
	Prénom_C	Prénom du client	Varchar
	Adr_C	Adresse personnelle du client	Varchar
	Email_C	Email du client	Varchar
	Num_Tel	Numéro téléphone du client	Varchar
	Num_RC_C	Numéro registre de commerce	Varchar
	Num_MF_C	Numéro matricule Fiscale	Varchar
Commande Client	ID_commande_C	Identificateur de la commande	Integer
	Date_Com_C	Date de la commande	Date
Produit Fini	ID_Prod	Identificateur du produit	Integer
	Int_Prod	Nom du produit	Varchar
	Prix_unit	Prix Unitaire du produit	Money
Commande Fournisseur	ID_Commande_F	Identificateur de la commande	Integer
	Date_Com_F	Date de la commande	Date
PV de Réception	ID_PV	Identificateur de PV de Réception	Integer
	Date_PV	Date de PV de Réception	Date
Facture Client	ID_Facture_C	Identificateur du Facture Client	Integer
	Date_Facture_C	Date Facture Client	Date
	Paiement_C	Paiement	Bool
	Prix_Total_F	Prix Total	Money
Facture Fournisseur	ID_Facture_F	Identificateur du Facture	Integer
	Date_Facture_F	Date Facture Fournisseur	Date
	Prix_Total_F	Prix Total	Money
Contient 1	Qte_Commander	Quantité Commander	Integer
Contient 2	Qte_Commander	Quantité Commander	Integer
Contient 3	Qte_délivré	Quantité Délivré	Integer
Contient 4	Qte_acheter	Quantité Acheter	Integer
	Date_Fab	Date de Fabrication	Date
	Date_Exp	Date d'Expiration	Date
Contient 5	Qte_théo_recu	Quantité théorique reçu	Integer
	Qte _manq	Quantité manquante	Integer
	Qte _avérer	Quantité avérer	Integer

Shéma de Diagramme de classe :

Figure 26 : Diagramme de classe

Modèle relationnel :

Définition :

Le modèle relationnel est une manière de modéliser les informations contenues dans une base de données qui repose sur des principes mathématiques.

On appelle relation un ensemble d'attributs qui définissent un fait.

C'est le premier modèle de base de données indépendant des critères, il permet :

· Une description simple des entités.

· Une mise à jour des données sans anomalies des stockages.

· D'associer la théorie de normalisation et d'éliminer les comportements anormaux des données lors une mise à jour afin de supprimer les redondances et d'éviter les incohérences de la base de donnée.

Dans le modèle relationnel tout est définie comme relation même les classes ainsi les associations et des liens sont représentés de façon unique.

Les règles de passage

- Les individués : chaque individu se transforme en une table.

- Les propriétés : deviennent des attributs de la relation.

- Les identifiants : chaque identifient devient la clé primaire.

Relation <<père-fils>>

- La cardinalité de l'individu père (0-n) et la cardinalité l'individu fils (1-1).

- L'identifiant de l'individu père devient attribut de la table fils.

- Cet attribut est appelé clé étrangère.

- La propriété de l'association devient les attributs de la table fils.

Passage au modèle relationnel :

Client (ID_Client, Nom_C, Prénom_C, Adr_C, Email_C, Num_Tel, Num_RC_C, Num_MF_C).

Commande Client (ID_commande_C, Date_Com_C, ID_Client*)

Produit Fini (ID_Prod, Int_Prod, Prix_unit)

Commande Fournisseur (ID_Commande_F, Date_Com_F)

PV de Réception (ID_PV, Date_PV, ID_Facture_F*)

Facture Client (ID_Facture_C, Date_Facture_C, Paiement_C, Prix_Total_F, ID_commande_C*)

Facture Fournisseur (ID_Facture_F, Date_Facture_F, Prix_Total_F, ID_Commande_F*)

Contient 1(ID_Prod,ID_Commande_F, Qte_Commander)

Contient 2(ID_commande_C,ID_Prod, Qte_Commander)

Contient 3(ID_Prod,ID_Facture_C, Qte_délivré)

Contient 4(ID_Prod,ID_Facture_F, Qte_acheter, Date_Fab, Date_Exp)

Contient 5(ID_Prod,ID_PV, Qte_théo_recu, Qte _manq, Qte _avérer)

Remarque :

Clé primaire :

Clé étrangère. :*

Les règles de passage du Digramme de classe au MLD :

Règle1 : une classe devient une table, ses attributs deviennent ceux de la table et son identifiant est la clé primaire de cette dernière.

Règle2 : pour chaque association "plusieurs à plusieurs " on crée une nouvelle table, la clé primaire est la concaténation des clés des relations traduisant les classes intervenantes dans l'association.

- Règle3 : une association "un à plusieurs" est traduite en incluant dans la relation de multiplicité 1 la clé primaire de l'autre comme clé étrangère.

- Règle4 : une association "un à un" est traduite en incluant la clé primaire de l'une des relations comme clé étrangère dans l'autre.

- Règle5 : la traduction d'une association n_aire est une relation ayant comme clé primaire, un sous ensemble des clés de relations traduisant les classes qui intervient dans l'association.

- Règle6 :L'héritage se traduit par une table pour chacune des sous classes en reportant les attributs de la super classe dans les tables des sous classes.

Le Modèle logique des données :

- Pour la création des tables de notre base de données on a utilisés

Microsoft SQL Server 2014

- Le schéma suivant représente le Modèle logique des données correspondant à notre système.

Figure 27 : Modèle Logique des données du Système

II.6.2.3.Conclusion :

A l'issue de ce chapitre nous avons appris à mieux connaitre la conception du système, c'est une phase très long et pénible, chaque étape de la conception est très importante, tout en respectant leurs normes grâce à la conception UML et le processus du développement en cascade, elle doit être effectuée en tenant compte des résultats des étapes qui la précèdent, elle permet de dégager l'architecture générale de notre application web représentée dans le prochain chapitre.