Développement d'une application mobile métier: cas de l'application de gestion commerciale de Togo 3000 informatique

Chapitre 2

ANALYSE ET CONCEPTION

Comme tout projet informatique, notre projet nécessite une phase d'analyse et conception du système. Il s'agit d'une phase primordiale et déterminante dans la réalisation du projet. Elle nous permet de bien comprendre les besoins du client afin de mettre en oeuvre des solutions adéquates. La gestion de cette phase nécessite l'utilisation d'un langage d'analyse et de modélisation en plus d'une démarche à suivre.

1. PRESENTATION DE LA METHODE D'ANALYSE

Deux approches d'analyse se présentent : l'approche systémique et l'approche objet. Mais dans la cadre de notre projet nous allons nous intéresser qu'à l'approche objet, qui a été adoptée comme méthode d'analyse.

L'approche systémique définit un système comme un ensemble d'éléments en interaction dynamique, organisé en fonction d'un but. Le concept de base de cette approche est la séparation des données et des traitements. Ce type d'approche est efficace lorsque les interactions sont non linéaires et fortes. Mais en cas d'évolution, elle rend la maintenance des systèmes complexe et implique une lenteur dans le développement de logiciel.

L'approche objet désigne l'ensemble des processus et langages utilisés au cours du cycle de vie du logiciel, qui reposent sur la manipulation des objets. Dans cette approche un logiciel est vu comme un ensemble d'objets qui coopèrent. Avec cette approche, nous avons une vision externe définissant les actions qu'il est possible de faire subir à un objet ; et une vision interne dans laquelle, seule sa structure sera considérée.

Un autre concept qui est très souvent lié à l'approche objet est celui de classe qui permet de regrouper les propriétés communes des objets.

En conséquence, nous utiliserons dans le cadre de notre projet le processus unifié 2TUP avec le langage UML tout en adoptant la méthode agile SCRUM pour la gestion de la phase de réalisation.

1.1. Présentation du langage UML

En anglais, Unified Modeling Language (Langage de Modélisation Unifié), UML est un langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue.

C'est un langage de modélisation constitué de diagrammes. La version actuelle, UML 2.5, propose 14 types de diagrammes dont 7 structurels et 7 comportementaux. Ces diagrammes sont tous réalisés à partir du besoin des utilisateurs et

peuvent être regroupés selon les deux aspects suivants
( https://openclassrooms.com/fr/courses/2035826-debutez-lanalyse-logicielle-avec-uml/2048781-les-differents-types-de-diagrammes):

ANALYSE ET CONCEPTION

v Les aspects fonctionnels : Qui utilisera le logiciel et pour quoi faire ? Comment les actions devront-elles se dérouler ? Quelles informations seront utilisées pour cela ?

v Les aspects liés à l'architecture : Quels seront les différents composants logiciels à utiliser (base de données, librairies, interfaces, etc.) ? Sur quel matériel chacun des composants sera installé ?

1.2. Présentation du processus 2TUP

Les processus unifiés sont des processus de développement logiciel itératifs, centrés sur l'architecture, pilotés par des cas d'utilisation et orientés vers la diminution des risques⁷.

Pour un modèle 2TUP, tout développement peut être décomposé et traités en parallèle selon un axe fonctionnel et un axe technique. Nous pouvons ainsi suivre les évolutions liées aux changements des besoins fonctionnels et aux changements des besoins techniques. Ci-dessous, une représentation graphique du processus unifié 2TUP.

Figure 3: processus de développement 2TUP

Source : https://www.researchgate.net/figure/Methode-2TUP-etendue-31_fig17_299286702

1.3. Présentation du processus SCRUM

1.3.1. Définition

SCRUM est un schéma d'organisation de développement de produits complexes. Il est défini par ses créateurs comme un « cadre de travail holistique itératif⁸ qui se concentre sur les buts communs en livrant de manière productive et créative des produits de la plus grande valeur possible ⁹» (Wikipédia).

Cette méthode défini trois principaux rôles dans le processus.

v Le Scrum Master : il a pour rôle de vérifier l'application des principes de Scrum, s'assure que la communication fonctionne correctement au sein de l'équipe et explore toutes les pistes d'améliorations en termes de productivité et de savoir-faire.

⁷ https://sabricole.developpez.com/uml/tutoriel/unifiedProcess/

⁸ Le processus itératif est une séquence d'instructions destinée à être exécutée plusieurs fois et autant de fois qu'on peut en avoir besoin. C'est aussi une exécution de la séquence.

⁹ https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-French.pdf

18

19

ANALYSE ET CONCEPTION

+ L'équipe Scrum : il s'agit de l'équipe chargée de la réalisation des différentes tâches. Chaque membre est au même niveau, il n'y a pas de hiérarchie et chacun peut contribuer en fonction de ses compétences. L'objectif de l'équipe est de livrer le produit par incréments. Ainsi, à tout instant, il existe une version du produit « potentiellement livrable » disponible.

+ Le Product Owner : il est un expert du processus métier du client, définit les spécifications fonctionnelles et arbitre les priorités dans les réalisations.

1.3.2. Caractéristiques

+ C'est une démarche orientée client ; c'est-à-dire une focalisation sur les besoins du client tout au long du projet. Le changement est permanent. Bien entendu, réorienter un projet lorsqu'il le faut est la seule manière de livrer un produit conforme aux attentes clients.

+ C'est une démarche orientée produit ; une préoccupation sur le produit à réaliser plutôt que des principes et théories pour le réaliser. Le produit voit très rapidement le jour. Puis il est amélioré, perfectionné selon les spécifications, attentes et les exigences qualité.

+ La souplesse remplace la rigidité ; fondées sur un dialogue permanent avec le client, cette méthode vise la conformité quasi parfaite de la réalisation selon les attentes actuelles du client.

+ Planifier à volonté ; la modification des spécifications en cours de réalisation, véritable tourment pour les développeurs des projets classiquement conduits, est le principe fondateur de cette démarche. Pas de planning rigide aux stricts impératifs. Au contraire, on a la capacité non pas de chambouler les plans mais bien de « replanifier » à volonté. Un seul objectif : délivrer très rapidement un nouveau produit « fin » prêt à être évalué et amélioré. Le produit livré sera la nouvelle référence des échanges et du projet.

2. PRESENTATION DE L'OUTIL DE MODELISATION

2.1. Qu'est-ce que PowerAMC ?

PowerAMC actuellement devenu PowerDesigner est un logiciel de conception créé par la société SAP, qui permet de modéliser les traitements informatiques et leurs bases de données associées (Wikipédia). Il est basé sur le langage de modélisation UML.

2.2. Quels sont les atouts de PowerAMC ?

PowerAMC est un outil permettant d'effectuer les tâches suivantes :

+ Modélisation intégrée via l'utilisation de méthodologies et de notation standard : données (E/R, Merise), application (UML)

+ Génération automatique de code via des templates personnalisables : SQL (avec plus de 50 SGBD), Java, NET

+ Fonctionnalités de reverse engineering pour documenter et mettre à jour des systèmes existants ;

20

ANALYSE ET CONCEPTION

v Une solution de référentiel d'entreprise avec des fonctionnalités de sécurité et de gestion des versions très complètes pour permettre un développement multiutilisateur ;

v Fonctionnalités de génération et de gestion de rapports automatisés et personnalisables ;

Un environnement extensible, qui nous permet d'ajouter des règles, des commandes, des concepts et des attributs à nos méthodologies de modélisation et de codage.

3. ÉTUDE DÉTAILLÉE DE LA SOLUTION 3.1. Étude fonctionnelle

Dans cette partie nous allons identifier les différents acteurs qui vont interagir avec le système ainsi que les actions effectuées par ces derniers. Cette partie sera subdivisée en trois parties : la capture des besoins fonctionnels, l'analyse fonctionnelle statique et l'analyse fonctionnelle dynamique.

3.1.1. Capture des besoins fonctionnels

a) Identification des cas d'utilisation fonctionnels

L'étude de l'existant nous a permis de déceler un certain nombre de cas d'utilisation que nous résumons dans le tableau suivant.

N°	Cas d'utilisation	Acteur(s)
1	Gérer le système	Administrateur
2	Gérer les utilisateurs	Administrateur
3	Gérer les profils	Administrateur
4	Gérer les privilèges	Administrateur
5	S'authentifier	Administrateur, Commercial, Gestionnaire de stock, Comptable
6	Gérer les relations	Commercial
7	Gérer les devis	Administrateur, Commercial
8	Gérer les commandes	Administrateur, Commercial
9	Générer les factures	Administrateur, Commercial
10	Générer les livraisons	Administrateur, Commercial
11	Gérer les produits	Administrateur, Gestionnaire de stock
12	Gérer le stock	Administrateur, Gestionnaire de stock
13	Gérer les cautions	Administrateur, Comptable
14	Consulter les statistiques	Administrateur, Commercial

Tableau 12: liste des cas d'utilisation du système

21

ANALYSE ET CONCEPTION

b) Diagramme de cas d'utilisation

c)

^<<include>>

^{Gérer le stock}

^<<include>>

^<<include>>

^{gérer livraisons}

^{Administrateur}

^{Gérer les utilisateurs}

^{Gérer relations}

^<<include>>

^{gérer produits}

^<<include>>

^<<include>>

^{Gérer les achats}

^<<include>>

^<<include>>

^<<include>>

^{gérer factures}

^{Gérer devis gérer commandes}

^{Gérer règlements}

^{Agent commercial}

^<<include>>

^<<include>>

^<<include>>

^{Gérer les ventes}

^<<include>>

^<<include>>

^{Valider les operations}

^<<include>>

^<<include>>

^{Chef service commercial}

^{Consulter l'historique}

^<<include>>

^{S'authentifier}

^Comptable

^{Agent approvisionnement}

^{Gérer les cautions bancaires}

^<<include>>

^{Gérer les règlements}

^<<include>>

Figure 4 : diagramme de cas d'utilisation

^<<include>>

^<<include>>

^{Gérer les paramètres}

Description textuelle des cas d'utilisation

Cette description permet d'avoir une idée sur le fonctionnement de chaque cas d'utilisation.

22

ANALYSE ET CONCEPTION

? Cas d'utilisation « Gérer les utilisateurs » Sommaire d'identification :

Titre : Gérer les utilisateurs. But : inscription, activation, désactivation ou suppression des comptes utilisateurs. Résumé : L'administrateur créer un utilisateur en saisissant ses informations personnelles dans un formulaire, l'active et peut par la suite le désactiver si nécessaire via la page administrative. Acteurs : Administrateur
Préconditions : l'administrateur s'authentifie
Scénario nominal : 1-l'administrateur accède à la page de gestion des utilisateurs. 2-L'administrateur saisit les informations personnelles de l'utilisateur et valide 3-Le système vérifie(A1) (E1) 4-Le système envoie une notification de réussite de l'enregistrement Scénario alternatif : · A1 : le système détecte une erreur dans un champ de formulaire et affiche un message d'erreur champ obligatoire ou données incorrectes. L'administrateur peut réessayer au point 2. Scénario d'exception : · E1 : le système détecte un échec d'enregistrement dans la base de données et affiche un message précisant un échec d'inscription ; Le scénario nominal se termine par un échec.		Postconditions : l'utilisateur est inscrit sur la plateforme

? Cas d'utilisation « s'authentifier »

Titre : Authentification. But : la connexion d'un utilisateur au système. Résumé : L'utilisateur s'authentifie en saisissant son email et son mot de passe. Acteurs : Administrateur, utilisateur.

Préconditions : l'utilisateur lance l'application

Scénario nominal :

1-L'utilisateur saisit son email et son mot de passe puis valide

2-Le système vérifie(A1) (E1) (E2)

3-Le système envoie une notification de réussite

Scénario alternatif :

· A1 : le système détecte une erreur dans un champ de formulaire pour une 1ere ou 2ème fois et affiche un message d'erreur données incorrectes. L'utilisateur peut réessayer au point 1. Au bout d'un troisième essaie exécuter E2

Scénario d'exception :

· E1 : l'utilisateur n'existe pas dans la base de données et le système affiche un message précisant le précisant. Le scénario nominal se termine par un échec.

· E2 : Le système affiche un message de demande de réinitialisation du mot de passe

23

ANALYSE ET CONCEPTION

Postconditions : l'utilisateur se connecte au système et peut ainsi accéder aux rubriques correspondantes

? Cas d'utilisation « Gérer les relations »

Titre : Gérer les clients/prospects/fournisseurs.

But : Créer, mettre à jour ou supprimer une relation.

Résumé : le commercial se connecte à l'application, saisit les informations nécessaires dans les champs s'il s'agit de la création. Ou recherche le contact pour le mettre à jour via un champ de formulaire ou le supprime de la liste des relations.

Acteurs : Commercial.

Préconditions : L'utilisateur accède à la plateforme avec le profil requis

Scénario nominal :

1-Le commercial accède à l'interface de gestion des relations.

2- le commercial accède au formulaire d'ajout de la relation.

3- le commercial saisit les informations dans les champs puis valide 2-Le système vérifie(A1) (E1)

3-Le système envoie une notification de réussite

Scénario alternatif :

· A1 : le système détecte une erreur dans un champ de formulaire et affiche un message
d'erreur données incorrectes. L'utilisateur peut réessayer au point 3.

Scénario d'exception :

· E1 : la relation existe déjà dans la base de données et Le système affiche un message
précisant un échec de création ou de mise à jour. Le scénario nominal se termine par un échec.

- Postconditions : le commercial a pu créer ou mettre à jour une relation.

? Cas d'utilisation « Rechercher une entité »

Titre : rechercher une entité. But : Consulter une entité. Résumé : L'utilisateur effectue la recherche d'une entité en saisissant une information relative à l'entité recherchée. Acteurs : Tous les acteurs du système.
Préconditions : l'utilisateur s'authentifie
Scénario nominal : 1-L'utilisateur accède à l'interface affichant la liste des entités de la catégorie de l'entité recherchée. 2- saisit une information concernant l'entité recherché dans le champ de recherche puis valide. (A1) 3- le système affiche l'entité. Scénario alternatif : · A1 : Le système affiche un message indiquant que l'information n'existe pas dans la base. L'utilisateur peut réessayer au point 2.		Postconditions : L'utilisateur consulte l'information recherchée

24

ANALYSE ET CONCEPTION

? Cas d'utilisation « Gérer les devis »

Titre : Enregistrer un devis. But : Enregistrer un devis dans la base de données. Résumé : Le client demande un devis, le devis est enregistré pour être imprimer plus tard et envoyé au client. Acteurs : Commercial		Préconditions : Le commercial s'authentifie
Scénario nominal : 1-Le commercial accède à la page de gestion des devis, 2-Le commercial saisit les informations relatives au devis puis valide. 3-Le système vérifie(A1) (E1) 4-Le système envoie une notification de réussite Scénario alternatif : · A1 : le système détecte une erreur dans un champ de formulaire et affiche un message d'erreur données incorrectes. L'utilisateur peut réessayer au point 2.
Postconditions : devis enregistré

? Cas d'utilisation « Gérer les commandes »

Titre : Gestion des commandes. But : Mettre à jour les commandes. Résumé La validation d'un devis fait l'objet d'une commande, la commande est enregistrée. Elle peut ainsi être supprimée, imprimée ou modifiée plus tard. Acteurs : Commercial		Préconditions : Le commercial s'authentifie
Scénario nominal : 1-Le commercial accède à la page de gestion des commandes, 2-Le commercial saisit les informations relatives à la commande puis valide. 3-Le système vérifie(A1) (E1) 4-Le système envoie une notification de réussite Scénario alternatif : · A1 : le système détecte une erreur dans un champ de formulaire et affiche un message d'erreur données incorrectes. L'utilisateur peut réessayer au point 2.
Postconditions : Commande enregistrée

? Cas d'utilisation « Gérer les factures »

Titre : Gestion des factures. But : Gérer une facture. Résumé : Création, mise à jour, suppression ou édition d'une facture. Acteurs : Commercial

Préconditions : le commercial s'authentifie

Scénario nominal : 1-Le commercial accède à la page de gestion des factures, 2-Le commercial saisit les informations relatives à la facture puis valide. 3-Le système vérifie(A1) (E1)

25

ANALYSE ET CONCEPTION

4-Le système envoie une notification de réussite Scénario alternatif : · A1 : le système détecte une erreur dans un champ de formulaire et affiche un message d'erreur données incorrectes. L'utilisateur peut réessayer au point 2.

Postconditions : facture enregistrée et générée

? Cas d'utilisation « Gérer les livraisons »

Titre : Gérer les livraisons But : Mise à jour des livraisons. Résumé : le livreur enregistre, met à jour ou supprime une livraison. Acteurs : gestionnaire de stock		Préconditions : le gestionnaire de stock s'authentifie, facture réglée
Scénario nominal : 1-Le gestionnaire de stock accède à la page de gestion des livraisons, 2- Le gestionnaire de stock saisit les informations relatives à la livraison puis valide. 3-Le système vérifie(A1) (E1) 4-Le système envoie une notification de réussite Scénario alternatif : · A1 : le système détecte une erreur dans un champ de formulaire et affiche un message d'erreur données incorrectes. L'utilisateur peut réessayer au point 2.
Postconditions : bon de livraison généré

? Cas d'utilisation « Gérer le stock »

Titre : Gérer le stock. But : Ajouter, mettre à jour ou retirer un article du stock. Résumé : le gestionnaire de stock se connecte à l'application, puis effectue l'opération suivant qu'il s'agit d'un déstockage ou d'un stockage de marchandise ou s'il s'agit d'une mise à jour. Acteurs : le gestionnaire de stock.		Préconditions : l'utilisateur accède à la plateforme avec le profil requis
Scénario nominal : 1-Le gestionnaire de stock accède à l'interface de gestion du stock. 2-S'il s'agit d'un stockage, il accède au formulaire spécifié pour la création de l'article s'il s'agit d'un nouvel article ou au formulaire de stockage via l'interface de réception de marchandise pour ajouter au stock. 3-le système vérifie. (A1) (E1) (E2) 4-Le système envoie une notification de réussite Scénario alternatif : · A1 : le système détecte une erreur dans un champ de formulaire et affiche un message d'erreur données incorrectes. L'utilisateur peut réessayer au point 2. Scénario d'erreur : · E1 : le système détecte un échec d'enregistrement dans la base de données et affiche un message précisant un échec d'inscription ;
Postconditions : stock mis à jour

26

ANALYSE ET CONCEPTION

? Cas d'utilisation « Consulter les statistiques »

Titre : Consultation des statiques.

But : Affichage des états statistiques

Résumé : le système affiche à l'utilisateur les états statistiques (nombre d'achats ou de

ventes, le montant total des achats et le montant total des ventes, ...)

Acteurs : Administrateur, Commercial

Préconditions : L'administrateur ou le commercial s'authentifie.

Scénario nominal :

1-L'administrateur ou le commercial accède à la rubrique statistique appropriées. 2-Il choisit le type d'information.

3-Le système l'affiche les statistiques selon les paramètres choisis.

Postconditions : des états statistiques sont consultés

3.1.2. Analyse fonctionnelle statique

a) Diagrammes de classes participantes

Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et les interfaces des systèmes ainsi que les différentes relations entre celles-ci.

L'élaboration du diagramme de classes commence par l'identification des classes participantes du future modèle statique.

A partir de la description textuelle des cas d'utilisation nous pouvons tirer les classes candidates Client, Fournisseur, Prospect, Devis, LigneDevis, Commande, LigeCommande, Facture, Livraison, LigneLivraison, Article, Caution

Ce qui nous permet d'élaborer les diagrammes de classes suivant

b) Gestion des utilisateurs

^1..1

- ^{id_utilisateur}

- ^nom

- ^prenom

- ^email

- ^password

- ^status

^Utilisateur

: ^int

: ^String

: ^String

: ^String

: ^String

: ^boolean

- ^date_debut - ^date_fin

^{0..* 1..1}

^Avoir

- ^libelle

- ^{début_operation} - ^{fin_operation}

: ^Date : ^Date

- ^id_profil - ^libelle

^Operation

^Profil

: ^int

: ^String

- ^peut_lire

- ^peut_creer

- ^{peut_modifier} - ^{peut_suprimer}

: ^String
: ^Date
: ^Date

^Privilege

^1..1

: ^boolean : ^boolean : ^boolean : ^boolean

^1..1

- ^id_objet - ^libelle

^Objet

^1..1

: ^int

: ^String

Figure 5: Diagramme de classe gestion des utilisateurs

27

ANALYSE ET CONCEPTION

c) Gestion des cautions

^Organisme

^Projet

^{id_projet libelle description date_debut date_fin}

: ^int : ^String : ^String : ^Date : ^Date

-

-

-

-

-

^0..*

^0..1

^1..*

: ^int

: ^String

-

*

-

^1..1

^{id_type_caution}

^libelle_type

^Type_caution

^Caution

- ^id_type - ^libelle - ^montant - ^{date_emission} - ^{date_echeance} - ^condition

: ^int

: ^String : ^double : ^Date : ^Date : ^String

^0..*

- ^identifiant

^-type

- ^nom

- ^email

- ^adresse

- ^telephone

- ^observation

- ^bp

- ^pays

- ^ville

^PERSONNE

^{abstract}

: ^int

: ^String : ^String : ^String : ^String : ^String : ^String : ^String : ^String : ^String

^Banque

^1..1

^1..1

Figure 6: diagramme de classe gestion des caution

ANALYSE ET CONCEPTION

d) Gestion des achats et ventes

Le diagramme de classe ci-dessous est à la troisième forme normale.

^PERSONNE

^{abstract}

- ^{id_ligne_retour_client} - ^quantite

: ^int : ^int

^1..1

^0..*

^RETOUR_CLI

^0..*

-

-

-

^{id_livraison_client}

^{num_livraison}

^{date_livraison}

^{LIVRAISON_CLI}

^1..1

^0..*

^0..*

: ^int

: ^int

: ^Date

^1..1

^0..*

- ^{id_facture_client} - ^{date facture} - ^total__TTC

^FACTURE_CLI

^0..*

: ^int

: ^Date : ^int

^1..1

^0..1

^1..1

^1..1

^1..1

- ^activite : ^String

- ^{dernier_achat} : ^String

- ^{id_commande_client} - ^{date_commande} - ^{date_livraison} - ^total_TTC

^COMMANDE_CLI

^CLIENT

^1..1

^0..*

^1..1

^1..1

: ^int

: ^Date : ^Date : ^int

^0..*

^0..1

^0..*

^identifiant

^type

^nom

^{email adresse telephone observation bp}

^pays

^ville

- ^id_devis

- ^{date_commande} - ^{date_livraison} - ^total_TTC

- ^activite : ^String

^PROSPECT

^1..*

^DEVIS

^1..1

: ^int : ^String : ^String : ^String : ^String : ^String : ^String : ^String : ^String : ^String

: ^int

: ^Date : ^Date : ^int

^{ARTICLE_SERVICE}

^1..1

^1..1

^1..1

^1..*

^{LigneCommandeCli}

^LigneDevis

^0..*

^0..*

*

- ^{id_ligne_com_client} - ^prixTTC

-

^quantite

- ^tva

- ^remise

: ^int : ^double : ^int : ^double : ^double

: ^int

: ^double : ^int

^{id_ligne_devis}

^prixTTC

^quantite

^1..1

^1..*

^{LigneRetourCli}

^1..*

^{LigneLivraisonCli}

^1..1

^FOURNISSEUR

^1..1

^{numero_compte} : ^int

^1..1

^0..1

^1..1

^0..*

^0..*

^0..*

^COMMANDE_FRS

^FACTURE_FRS

^RECEPTION

: ^Date
: ^Date
: ^int

^1..1

- ^{id_facture_frs} - ^{date facture} - ^total__TTC

: ^int

: ^Date : ^int

- ^id_reception

- ^{num_reception} - ^{date_reception}

: ^int

: ^int

: ^Date

^1..1

^0..*

^0..1

- ^{id_commande_frs} - ^{date_commande} - ^{date_livraison} - ^total_TTC

: ^int

^RETOUR_FRS

^0..*

: ^int

: ^Date : ^int

- ^{id_retour_frs}

-

^{date reception}

- ^total__TTC

^{id_ligne_retour_frs}

^quantite

: ^int : ^int

^1..1

^1..

^0..1

^0..*

^{LigneRetourFrs}

1..1 0..*

^1..1

^1..1

^1..*

^{LigneCommandeFrs}

^0..* - - - - -

^1..*

^{LigneReception}

^{id_ligne_commande_frs}

^prixTTC

^quantite

^tva

^remise

: ^int : ^double : ^int : ^double : ^double

: ^int
: ^int
: ^int

^{id_ligne_reception}

^{quantite recu}

^{quantite__totale}

^0..*

- ^{id_service_article}

- ^libelle

- ^description

- ^prix_HT

: ^int

: ^String : ^String

: ^double

: ^int

: ^Date : ^int

- ^id

- ^{date_reception} - ^{total TTC}

: ^int
: ^int
: ^int

^{id_ligne_liv_client}

^{quantite_livree}

^{quantite_totale}

28

Figure 7:diagramme de classe gestion achats et ventes

29

ANALYSE ET CONCEPTION

3.1.3. Analyse fonctionnelle dynamique a) Diagrammes de séquences

? Administration

v Cas d'utilisation « ajouter un utilisateur »

^{Ajouter utilisateur}

^loop

		^Système

^ref

^{[Pour chaque ajout]}

^{Administrateur}

^{Demande l'accès à l'espace de gestion compte}

^{rempli les champs de formulaire}

^{demande d'ajout d'un utilisateur}

^{affiche formulaire d'ajout}

^{affiche l'epace demandé}

^{S'authentifier()}

^{verifie les champs}

^BDD

^{alt champs incomplet}

^{affiche un message d'erreur}

^{champ complet}

^{transfere les informations}

^{alt Utilisateur} existe

^{affiche message d'erreur}

^{informations incorectes}

^{Utilisateur n'existe} pas

^{affiche message de confirmation}

^{confirme la demande}

Figure 8: Diagramme de séquence du cas d'utilisation « ajouter un utilisateur »

30

ANALYSE ET CONCEPTION

v Cas d'utilisation « éditer un profil »

^{Editer_profil}

^loop

^ref

^{alt champs} incomplet ^{affiche un message d'erreur}

^{champ complet}

^{transfere les informations}

^Execute

^alt echec ^{affiche message d'erreur echec d'enregistrement}

succès ^{message de confirmation informations enregistrées}

^{[Pour chaque authentification]}

^{Administrateur}

^{Demande de la page profil}

^{saisir les informations}

^{S'authentifier()}

^Système

^{verifie les champs}

^BDD

^{affiche la page demandée}

Figure 9: Diagramme de séquence du cas d'utilisation « éditer un profil »

v Cas d'utilisation « s'authentifier »

^{S'authentifier}

^loop

^verifie

^Utilisateur

^{alt champs incomplet}

^{affiche un message d'erreur}

^champ complet ^{transfere les informations}

^alt

existe ^{affiche message d'erreur informations incorectes}

^{Utilisateur n'existe pas}

^{renvoie vers la page d'accueil}

^informations correctes

^{[Pour chaque authentification]}

^Utilisateur

^{saisir l'email et le mot de passe puis valider}

^{Demande de la page d'authentification}

^{affiche la page demandée}

^Système

^{verifie les champs}

^BDD

Figure 10: Diagramme de sequence du cas d'utilisation « s'authentifier »

31

ANALYSE ET CONCEPTION

? Achat

v Cas d'utilisation « demander une cotation »

^BDD

^Système

^Fournisseur

^{demander_cotation}

^ref

^{S'authentifier()}

^Commercial

^{Demande de la page de gestion des cotations}

^{affiche la page demandée}

^loop [Pour chaque demande] ^saisir les informations
^verifie les champs
					^alt champs incomplet ^affiche un message d'erreur
					^champ complet
^transfere les informations
			^Execute
^alt echec ^affiche message d'erreur	^echec d'enregistrement
succès ^message de confirmation	^informations enregistrées
^demande action utilisateur	^génère un pdf
^choisit action
alt^action=imprimer ouvrir_pdf()
^imprimer
^envoyer
^action=envoyer	^envoyer_pdf_par_email

Figure 11: Diagramme de séquence du cas d'utilisation « demander une cotation »

32

ANALYSE ET CONCEPTION

v Cas d'utilisation « commander un produit »

^commander_produit

^Système

^BDD

^Fournisseur

^Commercial

^ref S'authentifier()

^ref demandercotation()

^envoyer proforma

^Demande de la page d'enregistrement proforma

^affiche la page demandée

^saisir les informations

^verifie les champs

^alt champs incomplet affiche un message d'erreur

^champ complet

^transfere les informations ^Execute

^alt echec ^affiche message d'erreur

^echec d'enregistrement

succès ^message de confirmation

^informations enregistrées

^demande action utilisateur (valider toutes les lignes?) loop^pour chaque ligne de produit]

alt^â ligne devis approuvé valider la ligne

^reponse alt reponse=oui

^créer ligne commande

^ânon ^rejeter la ligne

^générer commande ^transferer informations commande

^renvoyer les données stocker

^reponse=non ^afficher interface de validation de la proforma

^générer la commande ^transférer informations commande

^renvoyer les données stocker

^choix action

^imprimer

^envoyer

action=envoyer

envoyer_pdf_par_email()

^demande action utilisateur

^générer pdf()

alt action=imprimer ^ouvrir pdf()

Figure 12: Diagramme de séquence du cas d'utilisation « commander un produit »

33

ANALYSE ET CONCEPTION

v

^{recevoir_marchandise}

^{Gérer_facture_frs}

^ref

^ref

^ref

^alt champs incomplet affiche un message d'erreur					^champ complet ^alt rapport=echec ^affiche message d'erreur rapport=succès ^message de confirmation ^demande action utilisateur (règler la facture?) ^reponse
^transfere les informations ^rapport de stockage stocker
alt reponse=oui ^message de confirmation ^reponse=non		^demande mise à jour état facture confirmation ^mise à jour

Figure 13: Diagramme de séquence du cas d'utilisation « gérer une facture fournisseur »

v Cas d'utilisation « Gérer une réception »

^Commercial

^{Demande de la page d'enregistrement facture}

^{affiche la page demandée}

^{saisir les informations}

^{commanderproduit()}

^{demandercotation()}

^{S'authentifier()}

^Système

^Système

^{envoyer facture}

^{verifie les champs}

^BDD

^BDD

^Fournisseur

^Fournisseur

Cas d'utilisation « gérer facture fournisseur »

^Commercial

^ref

^{S'authentifier()}

^ref

^{demandercotation()}

^ref

^{commanderproduit()}

^ref

^{Gérerfacturefrs()}

^{Demande de la page d'enregistrement de la reception}

^{affiche la page demandée}

^{saisir les informations}

^{verifie les champs}

alt ^{champs incomplet affiche un message d'erreur}

^champ complet	^transfere les informations
		^rechercher produit
alt^ancien produit ^message de confirmation	^confirmation	^mise à jour quantité et prix
^nouveau produit
loop^pour chaque ligne de produit] ^message de confirmation	^confirmation	^ajouter en stock

Figure 14: Diagramme de séquence du cas d'utilisation « Gérer une reception »

34

ANALYSE ET CONCEPTION

? Vente

v Cas d'utilisation « gérer un devis client »

^Système

^BDD

^Client

^gérer_devis

^Commercial

^ref

^S'authentifier()

^{demander devis}

^{Demande de la page de gestion des devis}

^{affiche la page demandée}

^loop [Pour chaque demande] saisir les informations
^verifie les champs
					^alt champs incomplet ^affiche un message d'erreur
					^champ complet
^transfere les informations
^rapport d'execution			^Execute
^alt echec ^affiche message d'erreur
succès ^message de confirmation
^demande action utilisateur	^génère un pdf
^choisit action
alt action=imprimer ouvrir_pdf()
^imprimer
^envoyer
action=envoyer

^{envoyer pdf par email}

Figure 15: Diagramme de séquence du cas d'utilisation « gérer un devis client »

35

ANALYSE ET CONCEPTION

v Cas d'utilisation « gérer une commande client »

^gérer_commande_client

^Système

^BDD

^Client

^Commercial

^ref S'authentifier()

^ref gérer_devis()

^commander produit

^Demande de la page d'enregistrement commande

^affiche la page demandée

^saisir les informations

^verifie les champs

^alt champs incomplet ^affiche un message d'erreur

^champ complet

^transfere les informations

^rapport d'execution

^Execute

^alt echec ^affiche message d'erreur

succès ^message de confirmation

^reponse

alt reponse=oui

^générer commande ^transferer informations commande

^renvoyer les données ^stocker commande

^créer facture

reponse=non ^afficher interface de validation des devis

loop^pour chaque ligne de produit]

^demande action utilisateur (valider toutes les lignes?) alt^si ligne devis approuvée ^valider la ligne

^créer ligne commande

^sinon rejeter la ligne

^générer la commande ^transférer informations commande

^renvoyer les données stocker commande

^créer facture

^demande action utilisateur

^générer facture en pdf()

^choix action

alt action=imprimer ouvrir_pdf()

^imprimer

^envoyer

action=envoyer

envoyer_facture_en_pdf_par_email()

Figure 16: Diagramme de séquence du cas d'utilisation « gérer une commande client »

36

ANALYSE ET CONCEPTION

v Cas d'utilisation « gérer une facture client »

^Commercial

^{S'authentifier()}

^{gérerdevis()}

^{ref gérer_commande_client()}

^{règler facture}

^ref

^ref

^{verifie les champs}

^{Demande de la page de règlement facture}

^{affiche la page demandée}

^{saisir les informations}

^alt champs incomplet affiche un message d'erreur						^champ complet
^transfere les informations
^rapport de mise à jour				^mise à jour facture
					^alt rapport=echec ^affiche message d'erreur
					rapport=succès ^message de confirmation
^générer bon de livraison ^transmettre informations livraison					^demande action utilisateur
^générer_pdf_livraison()				^reponse
alt imprimer ouvrir_pdf()
^imprimer
^envoyer le bon de livraison
envoyer	transmettre_pdf_bon_de_livraison_par_email()

^{Gérer_facture_client}

^Système

^BDD

^Client

Figure 17: Diagramme de séquence du cas d'utilisation « gérer une facture client »

v Cas d'utilisation « livrer une marchandise »

^recevoir_marchandise

^Système

^BDD

^Client

^Commercial

^ref S'authentifier()

^créer livraison ^ref gérer_devis()

^ref gérercommandeclient()

^ref Gérerfactureclient()

^Demande de la page d'enregistrement de la livraison

^affiche la page demandée

^saisir les informations

alt^champs incomplet ^affiche un message d'erreur

^verifie les champs

^champ complet

^confirmation

^mise à jour quantité

loop^pour chaque ligne de produit] ^n'existe pas ^message d'erreur

^transfere les informations ^produit absent

^rechercher produit en stock

alt existe

^message de confirmation

Figure 18: Diagramme de séquence du cas d'utilisation « livrer une marchandise »

ANALYSE ET CONCEPTION

? Stock

v Cas d'utilisation « Gérer article »

^{Gestionnaire de stock}

^ref	^S'authentifier()

^{demande la page de gestion des articles}

^{affiche la page demandée}

^{choix operation}

^alt nouveau	^affiche formulaire
^mise à jour	^selectionne l'article à mettre à jour
	^affiche le formulaire de mise à jour

^{saisit les informations puis valide}

^{vérifie les informations}

^alt données incorrectes	^envoie un message d'erreur
^données correctes		^transmet les informations

^te

^{Gérer_article}

^Système

^BDD

^l'operation

^{rapport d'execution}

^{message d'erreur}

^{message de confirmation}

Figure 19: Diagramme de sequence du cas d'utilisation « Gérer article »

37

^alt erreur

^succès

3.2. Étude technique

^execu

3.2.1. Capture des besoins techniques

La capture des besoins techniques permet de recenser toutes les contraintes techniques et logicielles exprimées dans l'étude préliminaire lors de l'expression des besoins opérationnels et des choix stratégiques de développement. Elle doit être suffisamment détaillée pour permettre d'aborder la conception générique du système.

Les choix stratégiques de développement faits au niveau du cahier des charges vont donner lieu à des contraintes relatives à la configuration du système. Ces contraintes concernent les performances d'accès aux données, la sécurité du système, l'interopérabilité, l'intégration des applications, la volumétrie et le mode d'utilisation du système.

38

ANALYSE ET CONCEPTION

a) Identification des cas d'utilisation techniques ? Les exploitants du système

L'exploitant est un acteur au sens d'UML, si ce n'est qu'il ne bénéficie que des fonctionnalités techniques du système.

Les exploitants de notre système sont :

V' L'utilisateur qui utilise une des applications du système. (La majorité des acteurs de la branche fonctionnelle sont donc des utilisateurs dans la dimension technique).

V' L'ingénieur d'exploitation qui est chargé de déployer et de dépanner le système.

? Les cas d'utilisations techniques

Un cas d'utilisation technique est destiné à l'exploitant. C'est une séquence d'action produisant une valeur ajoutée opérationnelle ou purement technique. Le tableau suivant résume les cas d'utilisation techniques.

Cas d'utilisation	Acteurs	Messages
Gérer les erreurs et exceptions	Utilisateur	Emet : erreurs
	Administrateur	Reçoit : liste erreurs
Gérer la sécurité	Utilisateur	Emet : ouverture de session, mot de passe crypté
	Administrateur	Reçoit : liste des sessions ouvertes Emet : sauvegarde des données
Utiliser l'aide	Utilisateur	Reçoit : l'aide

Tableau 13: Cas d'utilisation techniques

? Gérer les erreurs et les exceptions

Ce cas d'utilisation permet au système d'être exploitable ; il faut qu'il soit en mesure de générer des traces et des alertes qui vont faciliter la maintenance, ce qui introduit l'ingénieur d'exploitation comme exploitant du système.

Ci-dessous la description de ce cas d'utilisation.

V' Le système enregistre toute erreur survenue dans un fichier ;

V' Le responsable d'exploitation consulte le fichier d'erreurs et recherche les causes des erreurs ;

V' L'application propose au responsable d'exploitation un menu de résolution de problèmes liés à sa recherche ;

V' Le responsable d'exploitation choisit l'option lui permettant de résoudre le problème. V' Le système lui confirme la réussite de l'opération.

V' Le responsable d'exploitation fait un test. Si le test ne donne pas les résultats escomptés alors on repart au point (4). Si le test est ok le responsable d'exploitation valide puis ferme la fenêtre.

ANALYSE ET CONCEPTION

? Gérer la sécurité

Ce cas d'utilisation permet de protéger le système des intrusions externes. Les exploitants sont soumis à des règles de sécurité qui sont l'authentification, le cryptage.

? Utiliser l'aide

Ce cas d'utilisation permet d'exploiter le système de manière efficace. Chaque utilisateur doit disposer d'une aide contextuelle.

b) Architecture en 5 couches

Une couche logicielle représente un ensemble de spécifications ou de réalisations qui respectivement expriment ou mettent en oeuvre un ensemble de responsabilités techniques et homogènes pour un système logiciel.

Les couches s'empilent en niveaux pour couvrir des transformations logicielles successives, de sorte que la couche d'un niveau ne puisse utiliser que les services des couches des niveaux inférieurs.

	^Restituer les données aux utilisateurs, et transformer ses ^actions en évènement de l'application
	^l'application
^Exploitant

^{Présentation}

^Application

	^Implémente les objets du metier et implémente leurs ^règles de gestion
		^de stockage

^{représente les objets de contrôle et pilote les règles de}

^{Assure la persistence des données}

^Métier

^{Accès aux données}

^{Stockage de données}

39

^{Restitue les représentations métiers à partir du moyen}

Figure 20: Architecture en cinq couches

3.2.2. Conception générique

La conception générique est une activité de la branche technique (droite) du processus en « Y ». Elle s'appuie sur les couches logicielles déjà identifiées lors de l'étape précédente qui est la capture des besoins techniques. Cette conception est qualifiée de générique, car elle est entièrement indépendante des aspects fonctionnels. En effet, elle consiste à développer la solution qui répond aux spécifications techniques en construisant les classes techniques qu'on groupera dans des Framework techniques et en organisant ces Framework dans un modèle logique de conception technique.

40

ANALYSE ET CONCEPTION

a) Modèle logique de conception

En analyse, nous avons fait un découpage en catégorie des classes, ici les classes techniques seront regroupées non pas dans des catégories, mais dans des Frameworks techniques que nous allons organiser dans le modèle logique de conception technique.

Un Framework est un réseau de classes qui collaborent à la réalisation d'une responsabilité qui dépasse celle de chacune des classes qui y participent.

A chaque couche logicielle définie dans l'étape de la capture des besoins techniques correspond un Framework technique, l'organisation de ces derniers permet d'élaborer le modèle logique de conception qui est schématisé dans la figure suivante.

^{Noyau métier}

^{Noyau application}

^{Noyau accès aux données}

^{Noyau sécurité}

^{Noyau présentation}

Figure 21: Modèle logique de conception

b) Description des noyaux ? Le noyau présentation

Définit les classes, les Interfaces Homme/Machine (IHM) qui sont nécessaires à l'affichage des objets

^Page

^0..*

^0..*

^{Zone de saisie}

^Interface

^{1..1 1..*}

^1..1

^1..1

^1..1

^0..*

^{1..* 1..1}

^{0..* 0..1}

^Formulaire

^Bouton

Figure 22: Noyau de présentation

ANALYSE ET CONCEPTION

? Le noyau applicatif

Contient les éléments pour rafraichir les vues, gérer les exceptions, charger les modèles de fonctionnement et contrôler les commandes d'une application.

? Le noyau métier

Définit les éléments permettant d'identifier les objets métier et de définir leurs attributs caractéristiques.

? Le noyau d'accès aux données

Définit les mécanismes de chargement, de sauvegarde de mise à jour et de recherche des objets.

? Le noyau sécurité

Pilote les règles de sécurité pour les accès aux environnements de travail définis pour les acteurs du système. Il définit aussi les mécanismes d'authentification.

^Avoir

^{1..* 1..1}

^Rôle

^Privilège

^1..1

^{1..* 1..*}

^1..*

^1..*

^1..*

^Utilisateur

^Session

^Interface

41

Figure 23 : Le noyau de sécurité

42

ANALYSE ET CONCEPTION

c) Diagramme de déploiement

^Smartphone

^{Application mobile}

^<<HTTP>>

^Serveur

^{Administration}

^{Javascript+html}

^Navigateur

^{Web Services: JSON}

^<<HTTP>>

^PHP

^SGBD

^MySQL

Figure 24:Diagramme de déploiement

d) Diagramme de composants

^{<<Component>>}

^View

^{Notify changes Changes setting}

^{Port_1 Port_2}

^Port_1

^{Android Services}

^{<<Component>>}

^Model

^{Android widget}

^Port_1

^{<<Component>>}

^Controller

Figure 25: diagramme de composants

43

ANALYSE ET CONCEPTION

4. CONCLUSION

L'analyse du système étant élaborée, elle nous a permis de comprendre le fonctionnement du système à mettre en place. Le document d'analyse ainsi obtenu permettra d'entreprendre la réalisation du logiciel en répondant aux besoins du département commercial de TOGO 3000 INFORMATIQUE.

44

REALISATION ET MISE EN OEUVRE