Bartholomé Anthony Année 2010-2011 Fejoua Btissam Université de Nantes Moueza Peter Tréguer Fabien M1 ALMA 1er livrable rapport projet génie logiciel a objets : Gestion de taches
Introduction : Le but de ce livrable est de fournir une approche simple du projet, nous permettant de définir les limites et les utilisations de notre futur programme. Ce livrable propose une analyse du problème qui nous est posé : Cette analyse est composé de plusieurs étapes. 1) Reformulation synthétique du sujet Cette étape permettra de savoir le rôle primordial de notre programme, a quoi va t' il réellement servir? 2) Diagramme de cas d'utilisation Ce diagramme est la pour connaître les interactions qu'il y aura ou pourrait avoir entre notre programme et les utilisateurs. 3) Différents scénarios : Les scénarios permettent de définir les applications pratiques que l'on pourra avoir de notre programme. 4) Diagramme de classes Ce diagramme dans la partie analyse nous permet plutôt d'avoir une vision globale du programme que de réellement définir les classes, attributs méthodes et interfaces de notre programme.
1) Reformulation synthétique du sujet: Le but de ce tp est de définir un programme permettant la gestion d'un rayon dans un magasin. Le programme se limite a à un seul rayon donné. Chaque rayon est découpé en 3 zones, ces 3 zones sont définies par des coefficients de progressions diminutions. Dans toutes les zones, nous trouvons exactement 30 produits. Nous supposons que nous avons toujours 7 produits différents par rayon. Chaque zone est plus ou moins exposée, ainsi chaque produit a plus ou moins de chances d'être vendu selon la zone ou il se trouve. Un produit a également son propre coefficient, en effet il y a toujours des produits plus ou moins vendus. Une fois un produit enlevé, nous considérons qu'il se trouve dans une zone dite zone «poubelle». Il est impossible de récupérer un produit se trouvant dans cette zone. Nous gérons le programme par tour, à chaque tour nous allons recalculer l'ensemble des statistiques de vente. Ces statistiques calculées aléatoirement mais grâce aux bornes et aux coefficients nous permettront de mettre en place au besoin des changements dans le rayon. Par exemple si un produit se trouve dans la zone la plus exposée mais ne génère pas un assez bon chiffre d'affaire, celui ci sera remplacé par un nouveau, pouvant générer plus de profits. 2) Diagramme de cas d'utilisation Voici ensuite un diagramme de cas d'utilisation de notre futur programme : Un utilisateur externe pourra faire une des 5 actions décrites ci dessus. Ce diagramme nous permet ainsi de définir les scénarios:
3) Différents scénarios: Le responsable demande les déplacements de produits à effectuer. Le système recherche les ventes des produits; Le système considère le résultat, les bornes des zones, et les bornes de produits, et selon ça et la stratégie, le système donne l'emplacement adéquat dans une zone du rayon, poubelle comprise. Le responsable, suit cette directive, et place donc le produit. On suppose que l'exécutant des ordres fait bien ce qu'on lui demande, qu'il met bien les produits dans les bonnes zones, scénario bras armé. Nous aurions pu implémenter la vérification de ces actions grâce a l'utilisation d'une classe inventaire. Cette classe aurait permis de vérifier si l'exécutant a bien effectué les actions demandées, par comparaison des produits présents dans l'inventaire avant et après l'ordre donné. Cependant, nous ne le ferons car nous pensons que cela franchit les limites de notre programme..2eme scénario: le responsable demande l'historique d'un produit..3eme scénario: le responsable demande où se situe un produit..4eme scénario: le responsable demande la composition d'une zone..5eme scénario: le responsable demande la composition du rayon. Les scénarios seront fait graphiquement dans le 2e livrable
4) Diagramme de classes Notre diagramme de classe est ici sous sa forme la plus simple, une étude plus approfondie se fera lors de la partie conception.