Cours d'Analyse Principes et Méthodes








télécharger 448.36 Kb.
titreCours d'Analyse Principes et Méthodes
page4/7
date de publication02.02.2018
taille448.36 Kb.
typeCours
ar.21-bal.com > droit > Cours
1   2   3   4   5   6   7

1.2Etape1 identification des besoins


L’objectif est de définir les besoins de l’application.

Démarche 01 (pour l’identification des besoins)

On identifie les acteurs et on établit un premier diagramme de haut niveau d’abstraction, appelé diagramme de contexte.

Ce diagramme sert à délimiter précisément les frontières du système.




Démarche 02 (pour l’identification des besoins).

Lorsque le diagramme de contexte est établi on identifie les cas d’utilisation du système




Démarche 03 (pour l’identification des besoins).

On donne une description textuelle des cas d’utilisation afin de les décrire.





Démarche 04 facultative (pour l’identification des besoins).

On documente les cas d’utilisation et les scénarios d’une description graphique.


  • Pour représenter graphiquement les cas d’utilisation, on peut utiliser un diagramme d’activité .

  • Pour représenter un scénario particulier, on peut utiliser un diagramme de séquence.




Démarche 05 (pour l’identification des besoins)

Facultative

On affine les diagrammes et les descriptions en organisant les cas d’utilisation par des relations d’inclusion, d’extension, de généralisation (très controversé) et par regroupements en package.
RUP : une méthode pour aider à modéliser

1.3Etape 2 identifier les classes et attribuer les responsabilités


Après avoir défini les besoins (via les use cases), il faut décider des objets nécessaires pour les réaliser et donc des classes nécessaires pour les fabriquer et les contrôler.

C’est pendant cette étape qu’on fait les choix d’affectation des responsabilités.

Cette étape a pour but d’aboutir à un modèle de conception.

L’établissement d’un modèle de conception nécessite 3 connaissances :
La connaissance du domaine qu’on doit informatiser

La connaissance des règles d’affectations des responsabilités

La connaissance de solutions reconnues par le monde informatique (patterns)


Démarche 6 ( identification des classes et des responsabilités)

Etablir un modèle du domaine.
Un modèle du domaine est un diagramme de classes conceptuelles.
Il sert uniquement à comprendre le domaine et à mettre en évidence le vocabulaire du domaine

1.3.1Comment identifier les classes conceptuelles ?



Deux stratégies sont proposées dans la littérature :

1ère stratégie :

On débusque des classes potentielles en se basant sur une liste de catégories.

LISTE CLASSE CONCEPTUELLE

Objets physiques caisse, article

Spécification ou description d’objet descriptionProduit

Lieux magasin

Transaction vente, payement

Ligne d’une transaction ligne article, acompte

Rôle des personnes caissier, acheteur

Conteneurs magasin, rayonnage, tiroir caisse

Contenu d’un conteneur article, pièce de monnaie

Autre système externe informatique ou non système autorisation de crédit

Concepts faim

Organisation département vente

Evénement vente, paiement, réunion

Règle et politique politique de remboursement,de ristourne

Catalogue publicité, catalogue produits

Documents comptables reçu, livre de caisse
2ème stratégie :
On analyse les textes des scénarios et on relève les groupes nominaux qui peuvent représenter des entités, des attributs ou ne pas intéresser.
Scénario nominal

  1. Un client arrive à la caisse avec de la marchandise.

  2. Le caissier démarre une nouvelle vente

  3. Le caissier enregistre le numéro d’identification de chaque article, ainsi que la quantité si elle est supérieure à un.

  4. La caisse affiche le prix de chaque article et son libellé au caissier et au client ainsi que le total en cours déjà atteint

  5. Le caissier répète les étapes 3 et 4 jusqu’à ce que tous les articles soient passés.

  6. le caissier signale la fin de la vente

  7. La caisse affiche le total à payer.

  8. Le client paye

  9. La caisse enregistre la vente et imprime un ticket.

  10. Le caissier donne le ticket au client


Remarque : ce n’est pas automatique : le paiement n’apparaît pas sous forme de groupe nominal mais sous forme de verbe : le client paie.

1.3.2Quelques conseils.


  1. Faut-il prendre en compte les objets de trace ?
    Un objet de trace est une facture, un reçu ; quelque chose qui représente la trace de quelque chose d’autre. (le reçu est la trace des achats)
    S’il s’agit d’une simple trace (c'est-à-dire d’une information qu’on peut retrouver à partir de éléments qui la compose), l’inclure dans le modèle injecte de la redondance.
    S’il s’agit par contre d’un élément qui représente plus que la trace il faut alors l’inclure.
    Exemple : Faut-il le faire figurer le reçu dans le modèle ?
    Réponse : Oui car il donne à son porteur un droit d’échanger la marchandise.
    Ce reçu a donc un rôle supplémentaire et n’est donc plus une simple
    trace.
    Remarque : Comme on ne gère dans cette itération que les ventes et pas les retours, on ne prend pas en compte le reçu



  2. C
    Vente

    magasin

    Vente

    Magasin

    Ou
    lasse ou attribut ?

    ou


  3. Astuce :
    Si la « chose » est composée de chiffres et de lettres, c’est probablement un attribut, sinon c’est vraisemblablement une classe.
    Un magasin n’est pas composé de chiffres et des lettres. C’est un lieu physique avec une adresse, une surface. C’est donc un concept (une classe).
    Dans le doute il est préférable d’en faire une classe qu’un attribut.
    Les attributs sont rares dans un modèle de domaine.



  4. Ne pas oublier les classes qui spécifient ou décrivent d’autres classes.



Cette modélisation est déconseillé.
Si toutes les vidéos sont vendues, toutes les occurrences vidéo sont détruites et on perd le descriptif, le prix etc,

De plus il y a une duplication d’informations.



Meilleure solution : utiliser une classe de description de la vidéo.


Les objets de description interviennent fréquemment en modélisation objet.

1.3.3Application de ces stratégies au cas caisse enregistreuse




1.3.4

1.3.5Les associations.


On détermine les associations significatives en relation avec le scénario en cours de développement.
Exemple :



Les associations du modèle du domaine stipulent des relations significatives au niveau conceptuel. Certaines de ces associations disparaîtront dans le modèle de conception. Inversement, certaines associations apparaîtront dans le modèle de conception.

1.3.6Comment trouver les associations ?


On peut s’inspirer d’une liste des associations courantes.
Il y a association entre A et B si


  • A est un élément physique de B Caisse et Tiroir

  • A est un élément logique de B Vente et LigneArticle

  • A est physiquement contenu dans B Caisse et Magasin

  • A est logiquement contenu dans B DescriptionArticle et Catalogue

  • A décrit B DescriptionArticle et Article

  • A fait l’objet d’une transaction de B LigneArticle et Vente

  • A est consigné/enregistré dans B Vente et Caisse

  • A est membre de B Caissier et Magasin

  • A est une sous unité organisationnelle de B Rayon et Magasin

  • A utilise et gère B Caissier et Caisse

  • A communique avec B Client et Caissier

  • A est lié à une transaction B Client et Paiement

  • A est une transaction liée à une transaction B Vente et paiement

  • A est voisin de B Article a et Article b

  • A appartient à B Caisse et Magasin

  • A est un évènement lié à B Vente et client,
    Vente et Magasin

Parmi cette liste, les associations prioritaires sont :
A est un élément physique ou logique de B
A est physiquement ou logiquement contenu dans B
A est enregistré dans B


1.3.7




1.3.8

1.3.9

1.3.10

1.3.11

1.3.12

1.3.13

1.3.14

1.3.15



Modèle du domaine avec associations :

Remarque :

Une caisse est mono utilisatrice. A tout moment la caisse ne gère qu’une seule vente à la fois. Ceci explique entre autre les multiplicités 1-1 entre vente et caisse.
Pour rappel : ce modèle du domaine est partiel : il n’a été inspiré que par l’analyse du morceau de scénario « traiter une vente » qui correspond à l’itération choisie.

Ce modèle du domaine n’est pas figé et peut subir des corrections.

Sa raison d’être est de mettre à disposition du vocabulaire décrivant l’application.
Démarche 7 : (identification des classes et des responsabilités)

On écrit des contrats pour certaines opérations système en utilisant le vocabulaire du modèle du domaine (facultatif).

Soit les opérations systèmes suivantes :


1.3.16

1.3.17L’expression des contrats peut conduire à la modification du modèle de domaine.



Exemple : contrat de terminer vente
Opération : terminerVente()

Référence croisée : cas d’utilisation : traiter une vente

Préconditions : il existe une vente en cours

Postconditions :



L’expression de la postcondition n’est pas possible avec le vocabulaire du modèle de domaine actuel. Il faut donc le modifier en ajoutant par exemple un boolean venteTerminée .

Postconditions : venteTerminee est vrai

1   2   3   4   5   6   7

similaire:

Cours d\Cours d'Analyse : principes et méthodes

Cours d\Chapitre 2 : Les Méthodes d’analyse de la Cellule – Bernard Rousset

Cours d\0 Urbanisme (2). Note du 22/3/02
«analyse des contenus des cours existants et futurs» afin de «formuler une proposition d’un ensemble de cours structuré et complémentaire...

Cours d\L´évolution des sciences a travers le temps et les civilisations
«la connaissance claire et certaine de quelque chose, fondée soit sur des principes évidents et des démonstrations, soit sur des...

Cours d\Analyse de la situation d’effondrement progressif du cours du baril du brut
«les cours du pétrole peuvent être manipulés. L’Arabie Saoudite a commencé à faire chuter les prix. Ceci est de la manipulation politique....

Cours d\Cours 1 : Principes du diagnostic anatomo-pathologique des tumeurs
«je vois une tuméfaction» car cela n’est pas forcément grave, dans ce cas on fait une biopsie pour faire le diagnostic

Cours d\Mme Bezeau est une conseillère principale qui a plus de 26 ans d'expérience...

Cours d\Cours d’analyse des organisations
«la nécessité d’un concept d’organisation qui ne se réduise pas àcelui de structure» (Le Moigne 1977 d’après F. Varella p17)

Cours d\Le cours de
«phénomène le plus évident de la vie économique» (cf. A. Benachenhou : Introduction à l’analyse économique, opu, Alger, 1976, p....

Cours d\Méthodes de construction de dériveurs légers








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com