CHAPITRE II. CONCEPTION DU NOUVEAU SYSTÈME DE GESTION DES ENTRÉES ET SORTIES DES PRODUITS POUR L’ALIMENTATION DU MIDI

II.0.      Introduction

Pour faire face à la complexité croissante des systèmes d’information, de nouvelles méthodes et outils ont été créés. La principale avancée des quinze dernières années réside dans la programmation orientée objet (P.O.O.). Face à ce nouveau mode de programmation, les méthodes de modélisation classique ont rapidement montré certaines limites et ont dû s’adapter, de très nombreuses méthodes ont également vu le jour comme Booch, OMT[1] …

Dans ce contexte et devant le foisonnement de nouvelles méthodes de conception « Orientée objet », l’OMG[2] (Object Management Group) a eu comme objectif de définir une notation standard utilisable dans les développements informatiques basés sur l’objet.

 C’est ainsi qu’est apparu UML (Unified Modified Language « langage de modélisation objet unifié »), qui est issu de la fusion des méthodes Booch, OMT (Object Modelling Technique) et OOSE[3] (Object Oriented Software Engineering).

 

Issu du terrain et fruit d'un travail d'experts reconnus, UML est le résultat d'un large consensus.

De très nombreux acteurs industriels de renommé ont adopté UML et participent à son développement.

Comme le montre la figure ci-dessous, en l'espace d'une poignée d'années seulement, UML est devenu un standard incontournable [2].

 

 

 

Figure_01.JPG

UML sert principalement à :

§     Décomposer le processus de développement ;

§     Mettre en relation les experts métiers et les analystes ;

§     Coordonner les équipes d'analyse et de conception ;

§     Séparer l'analyse de la réalisation ;

§     Prendre en compte l'évolution de l'analyse et du développement ;

§     Migrer facilement vers une architecture objet d'un point de vue statique et dynamique.

 

UML est vaste, et plusieurs ouvrages consacrent plusieurs centaines de page pour couvrir tous les notions de ce langage. Nous ne prévoyons pas être exhaustifs dans ce travail, toute fois nous estimons que c’est important de présenter quelques diagrammes que nous avons utilisés [11].

II.1.      Présentation des diagrammes UML

UML dans sa version 2 propose quatorze diagrammes qui peuvent être utilisés pour la description d’un système. Ces diagrammes sont regroupés dans deux grands ensembles dont [11]:

Les diagrammes structurels : ont vocation de représenter l’aspect statique d’un système. Ils permettent d’identifier les objets constituant le programme, leurs attributs, leurs opérations et les méthodes qui leurs sont associés. Ils sont au nombre de six à savoir :

§     Diagramme de Classe ;

§     Diagramme d’objet ;

§     Diagramme de composant ;

§     Diagramme de déploiement ;

§     Diagramme de Paquetage ;

§     Diagramme de structure composite.

 

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 ;

§     Diagramme d’état-transition ;

§     Diagramme d’activités ;

§     Diagramme de séquence ;

§     Diagramme de communication ;

§     Diagramme global d’interaction ;

§     Diagramme de temps ;

§     Diagramme de profil.

II.1.1.   Diagramme de Classes

Le diagramme de classes est le point central dans un développement orienté objet. En analyse, il a pour objectif de décrire la structure des entités manipulées par les utilisateurs. En conception le diagramme de classes représente la structure d’un code oriente objet ou, à un niveau de détail plus important, les modules du langage de développement [2].

 

 

Figure_02.JPG

La description du diagramme de classe est fondée sur :

-Le concept d’objet ;

-Le concept de classe comprenant les attributs et les opérations ;

-Les différents types d’association entre classes [11].

 

§     Classe

Une classe représente la description abstraite d’un ensemble d’objets possédant les mêmes caractéristiques. On peut parler également de type [2].

Exemple : La classe personne, la classe voiture.

Une classe se représente à l’aide d’un rectangle comportant plusieurs compartiments : Les trois compartiments de base sont :

o   la désignation de la classe ;

o   la description des attributs ;

o   la description des opérations.

 

 

Deux autres compartiments peuvent être aussi indiqués :

o   la description des responsabilités de la classe ;

o   la description des exceptions traitées par la classe.

 

§     Objet

Un objet est une entité aux frontières bien définies, possédant une identité et encapsulant un état et un comportement. Un objet est une instance(ou Occurrence) d’une classe [2]. 

Par exemple : MUGISHA Fabrice est une instance de la classe Personne. Le présent livre est une instance de la classe livre.

§     Visibilité des attributs et opérations

Chaque attribut ou opération d’une classe peut être de type public, protégé, privé ou paquetage. Les symboles + (public), # (protégé), - (privé) et ~ (paquetage) sont indiqués devant chaque attribut ou opération pour signifier le type de visibilité autorisé pour les autres classes. Les droits associés à chaque niveau de confidentialité sont :

• Public (+) : Attribut ou opération visible par tous.

• Protégé (#) : Attribut ou opération visible seulement à l’intérieur de la classe et pour toutes     les sous-classes de la classe.

• Privé (-) : Attribut ou opération seulement visible à l’intérieur de la classe.

• Paquetage (~) : Attribut ou opération ou classe seulement visible à l’intérieur du paquetage où se trouve la classe.

§              Attribut et Opération

Un attribut représente un type d’information contenue dans une classe.

Exemples : Le nom, prénom, Année_de_naissance, etc. sont les attributs de la classe Personne ;

Une Opération représente un élément de comportement (un service) contenu dans une classe. Nous ajouterons plutôt les opérations en conception objet, car cela fait partie des choix d’attribution des responsabilités aux objets.

§     Association

Une Association représente une relation sémantique durable entre deux classes.

Exemple : Une personne peut posséder des voitures. La relation possède est une association entre les classes Personne et voiture.

Même si le verbe qui nomme une association semble privilégier un sens de lecture, une association entre concepts dans un modèle du domaine est par défaut bidirectionnelle. Donc implicitement, l’exemple précédent inclut également le fait qu’une voiture est possédée par une personne [2].

Comment les représenter ?

Aux deux extrémités d’une Association, on doit faire figurer une indication de multiplicité. Elle spécifie sous la forme d’un intervalle d’entiers positifs ou nuls le nombre d’objets qui peuvent participer à une relation avec un objet de l’autre classe dans le cadre d’une association [2].

Exemple : Une personne peut posséder plusieurs voitures (entre zéro et un nombre quelconque) ; une voiture est possédée par une seule personne.

 

 

Figure_03.JPG

§  La multiplicité 

La multiplicité indique un domaine de valeurs pour préciser le nombre d’une instance d’une classe vis-à-vis d’une autre classe pour une association donnée. La multiplicité peut aussi être utilisée pour d’autres usages comme par exemple un attribut multi-valué.

Le domaine de valeurs est décrit selon plusieurs formes :

-        Intervalle fermé Exemple : 2, 3, ..15 ;

-        Valeurs exactes Exemple : 3, 5, 8 ;

-        Valeur indéterminée notée * Exemple : 1..* ;

-        Dans le cas où l’on utilise seulement *, cela traduit une multiplicité 0..*.

Dans le cas de multiplicité d’associations, il faut indiquer les valeurs minimale et maximale d’instances d’une classe vis-à-vis d’une instance d’une autre classe.

 

 

Figure_04.JPG

ü  Agrégation et composition

Une agrégation est un cas particulier d’association non symétrique exprimant une relation de contenance. Les agrégations n’ont pas besoin d’être nommées : implicitement elles signifient <<contient>>, <<et composé de>>.

Une composition est une agrégation plus forte impliquant que :

·         Un élément ne peut appartenir qu’a un seul agrégat composite (agrégation non partagée) ;

·         La destruction de l’agrégat composite entraine la destruction de tous ses éléments (le composite est responsable du cycle de vie des parties).

 

 

Figure_05.JPG

 

§  GENERALISATION, SUPER-CLASSE, SOUS-CLASSE

Une Super-classe est une classe plus générale reliée à une ou plusieurs autres classes plus spécialisées (Sous classes) par une relation de généralisation. Les sous-classes <<héritent >> des propriétés de leur super-classe et peuvent comporter des propriétés spécifiques supplémentaires.

Exemple : les voitures, les bateaux et les avions sont des moyens de transport. Ils possèdent tous une marque, un modèle, une vitesse, etc. Par contre, seuls les bateaux ont un tirant d’eau et seuls les avions ont une altitude …

 

Figure_06.JPG

Une classe abstraite est simplement une classe qui ne s’instancie pas directement mais qui représente une pure abstraction afin de factoriser des propriétés communes. Elle se note en italique. C’est le cas de Moyen de Transport dans l’exemple précédent.

II.1.2.   Diagramme de Déploiement

Le diagramme de déploiement montre la configuration physique des différents matériels qui participent à l’exécution du système, ainsi que les artefacts qu’ils supportent.

Ce diagramme est constitué de « nœuds » connecté par des liens physiques. Les symboles des nœuds peuvent contenir des artefacts [2].

 

 

 

 

·                     Nœud

Un nœud correspond à une ressource matérielle de traitement sur laquelle des artefacts seront mis en œuvre pour l’exploitation du système. Les nœuds peuvent être interconnectés pour former un réseau d’éléments physiques. Un nœud ou une instance de nœud se représente par un cube ou parallélépipède

·                     Artefact

Un artefact est la spécification d’un élément physique qui est utilisé ou produit par le processus de développement du logiciel ou par le déploiement du système. C’est donc un élément concret comme par exemple : un fichier, un exécutable ou une table d’une base de données.

 

 

Figure_07.JPG

II.1.3.   Diagramme de Comportements

Les diagrammes comportementaux sont focalisés sur la description de la partie dynamique du système à modéliser. 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. Le modèle dynamique montre le comportement du système et l’évolution des objets dans le temps. Il va identifier les différents événements venant du monde externe et montrer l’enchaînement dans le système que provoquent ces événements externes.

Un événement : c’est quelque chose qui se produit à un moment donné dans le temps et qui n’a pas de durée.

II.1.4.   Diagramme de Cas d’utilisations

Ce diagramme permet de faire le point sur les besoins des acteurs par rapport au système. Il comprend les fonctionnalités fournies par le système (cas d'utilisation), les utilisateurs qui interagissent avec le système (acteurs), et les interactions entre ces derniers. Un diagramme de cas d’utilisation capture le comportement d’un système, tel qu’un utilisateur extérieur le voit.

Il constitue un des diagrammes les plus structurants dans l’analyse d’un système.

Les composants de base d’un diagramme des cas d'utilisations sont: l’acteur, le cas d’utilisation et l’interaction entre l’acteur et le cas d’utilisation.

§  Acteur

 

Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié.

 

Un acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou en recevant des messages susceptibles d’être porteurs de données.

 

La représentation graphique standard de l’acteur en UML est l’icône appelée stick man, avec le nom de l’acteur sous le dessin. On peut également figurer un acteur sous la forme rectangulaire d’une classe, avec le mot-clé « actor ». Une troisième représentation (intermédiaire entre les deux premières) est également possible avec certains outils, comme cela est indiqué ci-après.

 

 

Figure_08.JPG

Une bonne recommandation consiste à faire prévaloir l’utilisation de la forme graphique du stick man pour les acteurs humains et une représentation rectangulaire pour les systèmes connectés.

§  Cas d’utilisation

 

Un cas d’utilisation ou un (« use case ») représente un ensemble de séquences d’actions qui sont réalisées par le système et qui produisent un résultat observable intéressant pour un acteur particulier.

 

Chaque cas d’utilisation spécifie un comportement attendu du système considéré comme un tout, sans imposer le mode de réalisation de ce comportement. Il permet de décrire ce que le futur système devra faire, sans spécifier comment il le fera.

 

Le diagramme de cas d’utilisation est un schéma qui montre les cas d’utilisation (ovales) reliés par des associations (lignes) à leurs acteurs (icône du « stick man », ou représentation graphique équivalente). Chaque association signifie simplement «participe à ». Un cas d’utilisation doit être relié à au moins un acteur.

 

 

Figure_09.JPG

o   Relations entre cas d’utilisation

 

Afin d’optimiser la formalisation des besoins en ayant recours notamment à la réutilisation de cas d’utilisation, trois relations peuvent être décrites entre cas d’utilisation : une relation d’inclusion (« include »), une relation d’extension (« extend ») et une relation de généralisation.

§  Une relation d’inclusion d’un cas d’utilisation A par rapport à un cas d’utilisation B signifie qu’une instance de A contient le comportement décrit dans B.

§  Une relation d’extension d’un cas d’utilisation A par un cas d’utilisation B signifie qu’une instance de A peut être étendue par le comportement décrit dans B.

§  Une relation de généralisation de cas d’utilisation peut être définie conformément au principe de la spécialisation-généralisation déjà présentée pour les classes.

II.1.5.   Diagramme d’Etat-transition

UML a repris le concept bien connu de machine à états finis, qui consiste à s’intéresser au cycle de vie d’une instance générique d’une classe particulière au fil de ses interactions avec le reste du monde, dans tous les cas possibles. Cette vue locale d’un objet, qui décrit comment il réagit a des évènements en fonction de son état courant et comment il passe dans un nouvel état, est représentée graphiquement sous la forme d’un diagramme d’états [2].

 

 

Figure_10.JPG

§  Etat

Un état représente une situation durant la vie d’un objet pendant laquelle :

•         Il satisfait une certaine condition ;

•         Il exécute une certaine activité ;

•         Ou bien il attend un certain événement.

Un objet passe par une succession d’états durant son existence. Un état a une durée finie, variable selon la vie de l’objet, en particulier en fonction des évènements qui lui arrivent.

Etat initial et état final

En plus de la succession d’états « normaux » correspondant au cycle de vie d’un objet, le diagramme d’états comprend également deux pseudo-états :

•         L’état initial du diagramme d’états correspond à la création de l’instance.

•         L’état final du diagramme d’états correspond à la destruction de l’instance.

 

§  Transition

Une transition décrit la réaction d’un objet lorsqu’un événement se produit (généralement l’objet change d’état). En règle générale, une transition possède un événement déclencheur, une condition de garde, un effet et un état cible.

 

§  Evénement

Un événement est un fait survenu qui déclenche une transition. Un événement se produit à                    un instant précis et est dépourvu de durée. Quand un événement est reçu, une transition peut être déclenchée et faire basculer l’objet dans un nouvel état.

 

§  Effet : Action ou Activité [2]

Une transition peut spécifier un comportement optionnel réalisé par l’objet lorsque la transition est déclenchée. Ce comportement est appelle « effet » : cela peut être une simple action ou une séquence d’actions (une activité). Une action élémentaire peut représenter la mise à jour d’un attribut, un appel d’opération, la création ou la destruction d’un autre objet, ainsi que l’envoi d’un signal a un autre objet. Les activités associées aux transitions sont considérées comme atomiques, c’est-à-dire qu’elles ne peuvent être interrompues. Ce sont typiquement des séquences d’actions.

Les activités durables (do-activity), au contraire, ont une certaine durée, sont interruptibles et sont donc associées  aux états.

 

 

Figure_11.JPG

II.1.6.   Diagramme d’Activités

Le diagramme d’activité présente un certain nombre de points communs avec le diagramme d’état-transition puisqu’il concerne le comportement interne des opérations ou des cas d’utilisation. Cependant le comportement visé ici s’applique aux flots de contrôle et aux flots de données propres à un ensemble d’activités et non plus relativement à une seule classe. Les concepts communs ou très proches entre le diagramme d’activité et le diagramme d’état-transition sont [11]:

•         Transition ;

•         Nœud initial (état initial) ;

•         Nœud final (état final) ;

•         Nœud de fin flot (état de sortie) ;

•         Nœud de décision (choix).

 

Les concepts spécifiques au diagramme d’activité sont [11]:

 

·         Nœud de bifurcation : un nœud de bifurcation (fourche) permet à partir, d’un flot unique entrant, de créer plusieurs flots concurrents en sortie de la barre de synchronisation.

·         Nœud de jonction : un nœud de jonction (synchronisation) permet, à partir de plusieurs flots concurrents en entrée de la synchronisation, de produire un flot unique sortant. Le nœud de jonction est le symétrique du nœud de bifurcation.

·         Nœud de test-décision : un nœud de test-décision permet de faire un choix entre plusieurs flots sortants en fonction des conditions de garde de chaque flot. Un nœud de test-décision n’a qu’un seul flot en entrée. On peut aussi utiliser seulement deux flots de sortie : le premier correspondant à la condition vérifiée et l’autre traitant le cas sinon.

·         Nœud de fusion-test : un nœud de fusion-test permet d’avoir plusieurs flots entrants possibles et un seul flot sortant. Le flot sortant est donc exécuté dès qu’un des flots entrants est activé.

·         Pin d’entrée et de sortie : un pin d’entrée ou de sortie représente un paramètre que l’on peut spécifier en entrée ou en sortie d’une action. Un nom de données et un type de données peuvent être associés au pin. Un paramètre peut être de type objet.

·         Nœud d’objet : un nœud d’objet permet de représenter le flot de données véhiculé entre les actions. Les objets peuvent se représenter de deux manières différentes : soit en utilisant le pin d’objet soit en représentant explicitement un objet.

·         Partition : UML permet aussi d’organiser la présentation du diagramme d’activité en couloir d’activités. Chaque couloir correspond à un domaine de responsabilité d’un certain nombre d’actions.

 

Figure_12.JPG

 

II.1.7.   Diagramme de Séquences

 

L’objectif du diagramme de séquence est de représenter 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.

Ligne de vie

 

Une ligne de vie représente l’ensemble des opérations exécutées par un objet. Un message reçu par un objet déclenche l’exécution d’une opération. Le retour d’information peut être implicite (cas général) ou explicite à l’aide d’un message de retour.

Message synchrone et asynchrone

 

Dans un diagramme de séquence, deux types de messages peuvent être distingués :

o   Message synchrone – dans ce cas, l’émetteur reste en attente de la réponse à son message avant de poursuivre ses actions. La flèche avec extrémité pleine symbolise ce type de message. Le message retour peut ne pas être représenté car il est inclus dans la fin d’exécution de l’opération de l’objet destinataire du message.

o   Message asynchrone – dans ce cas, l’émetteur n’attend pas la réponse à son message, il poursuit l’exécution de ses opérations. C’est une flèche avec une extrémité non pleine qui symbolise ce type de message.

 

Figure_13.JPG

 

UML possède plus de diagramme que celles présenté ci-haut. Nous ne pouvons pas les présenter tous dans ce projet, de peur que cela soit long et que beaucoup de livre explique déjà toutes ses notions de façon claire avec des exemples à l’appui. Pour plus d’information, nous conseillons la consultation des livres UML2 par la pratique, Conception de bases de données avec UML [15], Analyse et Conception [2] et UML 2 pour les développeurs [14] qui ont été notre principale source d’inspiration dans cette partie.

 

II.2. Modélisation du nouveau système de gestion des entrées et sorties des produits de l’Alimentation DU MIDI

Dans ce chapitre, nous mettons en pratique la théorie UML annoncé dans le deuxième chapitre, en modélisant notre nouveau système.

 

En vue de construire le modèle du système de gestion des entrées et sorties des produits d’une alimentation, il nous faut respecter les deux axes de modélisation  du standard UML à savoir :

ü  l’axe dynamique ou comportemental;

ü  l’axe statique ou structurel.

II.2.1.   Axe dynamique

L’axe dynamique permet de proposer un mode de fonctionnement du système à travers les diagrammes des cas d’utilisation, d’activités, de séquences et d’états. Cet axe permet de suivre la succession des différentes fonctions selon les modalités.

II.2.1.1.            Diagramme des cas d’utilisation

Le diagramme des cas d’utilisation est un modèle de haut niveau destiné à concevoir les besoins des utilisateurs. Les cas d’utilisation, en anglais « use cases » nous ont permis de structurer les besoins des utilisateurs et les objectifs correspondant à notre système. Pour cela, les cas d’utilisation identifient les utilisateurs du système (acteurs) et leurs interactions avec le système. Avec ce diagramme, nous avons classé les acteurs et structuré les objectifs du système.  Ce diagramme nous a permis de comprendre le fonctionnement du système.

II.2.1.1.1.         Identification des acteurs

Les différents acteurs intervenants dans notre système sont:

  • le gestionnaire : il a pour rôle de gérer l’alimentation en général, les utilisateurs du système. Donc, il les enregistre, les modifie, les attribuent des rôles. Il a aussi le rôle de gérer les différentes prestations. Il pourra les enregistrer ou les modifier. C’est lui qui se charge des enregistrements des fournisseurs;
  • le caissier : il a pour rôle d’enregistrer les clients (a crédits) ou de les modifier. Il a aussi le rôle d’enregistrer les produits  entrant et sortant ainsi que les paiements des ventes et des fournitures;
  • le client : il  peut réserver les produits en ligne ;
  • le fournisseur : il peut proposer des prix sur des produits que l’alimentation souhaite    intégrer dans le stock, il peut voir les commandes qui lui sont affectées.

                                                  

Voici donc le diagramme de cas d’utilisations que nous avons établi :

N.B : Le mot gérer pour notre cas englobe la recherche, la création, la modification, la suppression ;

 

 

Figure_14.JPG

II.2.1.1.2.         Description textuelles des cas d’utilisation

Notre diagramme de cas d’utilisation étant grande, ici nous avons pris en considération quelques cas d’utilisation les plus courant pour la description textuelle.

a)       Cas d’utilisation : S’authentifier

            Sommaire d’identification   

Titre    : L’authentification d’un utilisateur.

Résumé : Ce cas d’utilisation permet à l’utilisateur de s’authentifier pour accéder au             système réservé aux utilisateurs.

Acteur     : Utilisateur

A. Description des scénarios

Précondition : étant connecté à l’internet, la page d’accueil de l’application est appelée à partir du navigateur web

Acteur

Système

 

1. L’utilisateur appelle la page d’authentification ;

 

3. L’utilisateur saisit son identifiant (nom d’utilisateur et son mot de passe)  puis valide ;

 

 

2. Le système affiche page d’authentification ;

 

4. Le système compare les informations saisies à celles de la base de données et affiche l’interface réservé à l’utilisateur.

 

Tableau 1: Scénario nominal du cas d’utilisation : S’authentifier

 

B. Enchainement Alternatif

Si le nom d’utilisateur et/ou le mot de passe ne sont pas correctes (à l’étape 3 du scénario nominal) l’enchainement alternatif dirige l’utilisateur vers une page d’erreurs qui comprend un lien vers la page d’accueil.

 

 

 

b)     Cas d’utilisation : Elaborer une commande

            Sommaire d’identification   

Titre        : L’élaboration d’une commande.

Résumé : Ce cas d’utilisation permet au Gestionnaire d’élaborer une commande.

Acteur    : Gestionnaire

A. Description des scénarios

Précondition : l’Authentification.

 

Acteur

Système

 

1. Le Gestionnaire choisit le menu commande;

 

3. Le Gestionnaire appelle le formulaire d’un nouveau commande en cliquant sur le bouton « nouveau commande » ;

 

5. Le Gestionnaire choisit le produit, le fournisseur;

7. Le Gestionnaire saisie la quantité et clique le bouton ajouter;

9. Le Gestionnaire valide la commande ;

 

 

2. Le système affiche la page correspondante aux commandes;

 

4. Le système affiche le formulaire d’une nouvelle commande ;

 

6. le système propose au gestionnaire de saisir la quantité;

 

 

8. Le système ajoute la commande sur la liste ; 

 

10. Le système informe le Gestionnaire via un message que la commande a été bien crée.

 

Tableau 2: Scénario nominal du cas d’utilisation : Elaborer une commande

 

 

 

B. Enchainement Alternatif

Si le gestionnaire saisie une quantité négative ou égale à zéro (étape 8 du scénario nominal), le système informe le gestionnaire que la quantité ne doit pas être inferieur ou égale à zéro, l’enchainement alternatif recommence à l’étape 7 du scénario nominal.

 

c)      Cas d’utilisation : Elaborer une facture pro forma

            Sommaire d’identification   

Titre        : L’élaboration d’une facture pro forma.

Résumé : Ce cas d’utilisation permet au gestionnaire d’élaborer une facture pro forma.

Acteur    : Gestionnaire

A. Description des scénarios

Précondition : le Gestionnaire étant authentifié et le client ayant ses coordonnées dans le système.

Acteur

Système

1. Le Gestionnaire choisit le menu pro forma ;

 

3. Le Gestionnaire choisit les produits que souhaite le client, leurs quantités et les ajoute sur le pro forma;

5. Le Gestionnaire demande l’impression du  facture pro forma ;

 

2. Le système affiche l’interface d’élaboration d’une facture pro forma ;

 

4. Le système calcule le prix total sur les produits ;

 

6. Le système imprime la facture pro forma.

 

Tableau 3: Scénario nominal du cas d’utilisation : Elaborer une facture pro forma

B. Enchainement Alternatif

Si le gestionnaire ajoute une quantité inférieure ou égale à zéro, le système lui informe que la quantité ne doit pas être inférieure ou égale à zéro, l’enchainement alternatif recommence à l’étape 3 du scénario nominal.

 

 

d)     Cas d’utilisation : Réserver un produit

            Sommaire d’identification   

Titre        : Réservation d’un produit.

Résumé : Ce cas d’utilisation permet au client de réserver un produit.

Acteur    : Client

A. Description des scénarios

Précondition : connexion  internet.

 

Acteur

Système

1. Le client appelle la page d’accueil de l’alimentation;

 

3. Le client choisit le menu correspondant à la réservation;

 

5. Le client choisit le produit qu’il veut réserver ;

6. Le client saisit la quantité ;

8. Le client valide la réservation;

 

 

2. Le système affiche la page d’accueil de l’application ;

 

 

4. Le système affiche la page correspondante à la réservation ;

 

7. Le système lui propose de saisir le mot clé ;

 

9. Le système génère et affiche le nouveau mot clé que le client présentera à l’alimentation et informe le client que sa réservation a été bien effectuée ; 

 

 

Tableau 4: Scénario nominal du cas d’utilisation : Réserver un produit

 

 

B. Enchainement Alternatif

Si le client saisie une quantité inférieure ou égale à zéro, ou supérieur à la quantité disponible au stock, le système lui informe via un message la marge de la quantité qu’il doit saisir. L’enchainement alternatif recommence à l’étape  6 du scenario nominal.

 

e)      Cas d’utilisation : proposer le prix

            Sommaire d’identification   

Titre        : proposition du prix d’un produit.

Résumé : Ce cas d’utilisation permet au fournisseur de proposer le prix d’un produit.

Acteur    : Fournisseur

A. Description des scénarios

Précondition : connexion  internet et l’authentification fournisseur.

 

Acteur

Système

 

1. Le fournisseur choisit le produit qu’il veut proposer ;

3. Le fournisseur saisit le prix auquel il peut livrer le produit;

4. Le fournisseur valide la proposition ;

2. Le système propose au fournisseur de saisir le prix auquel il peut livrer le produit ;

 

5. Le système informe le fournisseur via un message que sa proposition a été bien effectuée; 

 

 

Tableau 5: Scénario nominal du cas d’utilisation : Proposer le prix

B. Enchainement alternatif

 

Si le fournisseur ne saisit pas le prix auquel il veut proposer le produit (étape 3 du scénario nominal), l’enchainement alternatif redémarre à l’étape 2.

 

 

 

f)        Cas d’utilisation : Ajouter une personne

Titre          : Ajout d’une personne

Résumé    : Ce cas d’utilisation permet au gestionnaire  d’ajouter une personne.

Acteur      : Gestionnaire

A. Description des scénarios

Précondition : S’authentifier

Acteur

Système

1. Le Gestionnaire choisit le Menu personne.

 

3. Le Gestionnaire appelle le formulaire d’une nouvelle personne en cliquant le bouton « nouveau ».

 

5. Le Gestionnaire saisit les informations relatives à une personne, puis valide.

2. Le système affiche la page dédié aux personnes.

 

4. Le système affiche le formulaire d’une nouvelle personne.

 

6. Le système contrôle et compare les informations saisies par rapport à celles attendues

7. Le système informe le Gestionnaire via un message que la personne a été bien enregistrée.

Tableau 6: Scénario nominal du cas d’utilisation : Ajouter un une personne

B. Enchainement Alternatif

Si les informations saisies ne sont pas valides (étape 5 du scénario nominal), l’enchainement alternatif redémarre à l’étape 4 du scénario nominal.

g)      Cas d’utilisation : Vendre un produit (cash)

 

Sommaire d’identification   

Titre                 : Vente d’un produit (Cash)

Résumé           : Ce cas d’utilisation permet au caissier de vendre un produit (cash) se trouvant dans le stock.

Acteur              : Caissier

A. Description des scénarios

Pré-conditions : S’authentifier

 

Acteur

Système

1. Le Caissier  choisit  le menu Vente.

 

3. Le Caissier ouvre le menu de recherche du produit souhaité par le client et y saisit le nom du produit.

5. Le Caissier saisit la quantité souhaité par le client.

7. Le Caissier  ajoute le produit sur la liste de vente.

8. Le Caissier confirme l’achat.

 

10. Le Caissier lance l’impression de la facture;

 

2. Le système affiche la page de l’application dédié à la vente des produits de l’alimentation.

4. Le système affiche le résultat de la recherche du produit  trouvé.

6. Le système affiche le prix total correspondant à la quantité totale souhaité par le client. 

 

9. Le Système calcul le prix total, enregistre la vente et met à jour le stock

 

11. Le système imprime la facture.

Tableau 7 : Scénario nominal du cas d’utilisation : Vendre un produit (cash)

B. Enchainement Alternatif

Si le Caissier saisit la quantité qui n’est pas disponible dans le stock ou une quantité inférieure ou égale  à zéro (à l’étape 5), Le système affiche un message indiquant la quantité disponible dans le stock et l’enchainement alternatif recommence à l’étape 5 du scenario nominal.

h)      Cas d’utilisation : Vendre un produit (crédit)

 

Sommaire d’identification   

Titre                 : Vente d’un produit (crédit)

Résumé           : Ce cas d’utilisation permet au caissier de vendre un produit (crédit) se trouvant dans le stock.

Acteur              : Caissier

A. Description des scénarios

Pré-conditions : S’authentifier

 

Acteur

Système

1. Le Caissier  choisit  le menu Vente ;

 

3. Le Caissier enregistre le client ;

4. Le Caissier ouvre le menu de recherche du produit souhaité par le client et y saisit le nom du produit ;

6. Le Caissier saisit la quantité souhaité par le client ;

7. Le Caissier  ajoute le produit sur la liste de vente ;

9. Le Caissier saisit la somme présentée par le client à la place du prix total généré par le système ;

11. Le Caissier confirme l’achat ;

12. Le Caissier lance l’impression de la facture ;

2. Le système affiche la page de l’application dédiée à la vente des produits de l’alimentation;

 

5. Le système affiche le résultat de la recherche de produit  trouvé ;

 

 

 

8. Le système calcule et affiche le prix total correspondant à la quantité totale souhaitée par le client ;

10. Le Système calcule la différence qui est le crédit, enregistre la vente et met à jour le stock ;

13. Le système imprime la facture.

Tableau 8: Scénario nominal du cas d’utilisation : Vendre un produit (crédit)

B. Enchainement Alternatif

Si le Caissier saisit la quantité qui n’est pas disponible dans le stock ou qui est inférieure ou égale à zéro (à l’étape 6), Le système affiche un message indiquant la quantité disponible dans le stock et l’enchainement alternatif recommence à l’étape 6 du scenario nominal.

Si le Caissier ne saisit pas le client (étape 3 du scénario nominal) Le système affiche un message lui indiquant qu’il faut saisir le client, l’enchainement alternatif lui amène à l’étape 5 du scenario nominal.

II.2.1.2.            Diagramme d’Etat -transitions

Représentation du diagramme d’Etats-transition de l’objet produit dans notre système :

 

Figure_15.JPG

 

II.2.1.3.            Diagramme d’Activités

Les diagrammes d’activités nous permettent de décrire beaucoup plus en détails le flux des activités pour chaque cas d’utilisation. Ici nous considérons le cas le plus courant qui est la vente des produits :

 

 

Figure_16.JPG

 

II.2.1.4.            Diagramme de Séquences

Il s'agit d'une explication détaillée d'un cas d'utilisation. Les principales informations contenues dans un diagramme de séquence sont les messages échangés entre les objets de différentes classes, présentés dans un ordre chronologique.

a)      vendre des produits

 

 

Figure_17.JPG

 

 

Figure_17.JPG

 

b)      commander des produits

 

II.2.2.   Axe Statique

Précédemment nous avons parlé de deux grandes catégories de diagrammes UML (statique et dynamique) l'un des diagrammes statiques nous intéresse beaucoup pour pouvoir implémenter le code, il s'agit du diagramme de Classes.

II.2.2.1.            Diagramme de Classes

Le schéma ci-dessous nous donne une vue globale de notre application. On a les classes principales qui vont nous servir à réaliser l'application.

 

Figure_19.JPG

II.2.2.2.            Diagramme de Déploiement

Enfin, nous terminons notre modélisation avec le diagramme de déploiement qui décrit l’architecture physique de notre application.

 

Figure_20.JPG

 


[1] Méthode de spécification par modélisation des besoins à la mode en 1995.

[2] L’OMG (Object Management Group) est une association américaine à but non-lucratif créée en 1989 dont l’objectif est de standardiser et promouvoir le modèle objet sous toutes ses formes. L’OMG est notamment à la base des spécifications UML, MOF, CORBA et IDL. L’OMG est aussi à l’origine de la recommandation MDA

[3] Méthode d’analyse et de conception orienté objet

Ajouter un commentaire

Restricted HTML

  • Vous pouvez aligner les images (data-align="center"), mais également les vidéos, citations, etc.
  • Vous pouvez légender les images (data-align="center"), mais également les vidéos, citations, etc.