limite des cas d'utilisation en POO

limite des cas d'utilisation en POO - Algo - Programmation

Marsh Posté le 13-06-2009 à 12:35:43    


 
bonjour,
 
je suis en train d'étudier les cas d'utilisation (CU) pour un modelisation objet de mon programme. Mais dégager différents CU me pose problème. J'arrive mal à voir ou est la limite d'un cas d'utilisation. A terme je voudrais évoluer vers un schéma MVC avec 1 controleur par CU. Je vous donne un exemple.
 
Exemple 1 :
 
J'ai une interface de paramètrage simple qui me permet d'ajouter/modifier/supprimer des enreg. dans une table BDD. Dois-je faire un CU par action ?
 
CU1 => ajouter
CU2 => modifier
CU3 => supprimer
 
ou bien un CU unique pour ce module simple. Comme je veux  faire un objet controleur par CU, je trouvais un peu lourd de faire un objet controleur différent pour l'ajout, pour la modification et pour la suppression.
 
Exeemple 2 :
 
J'ai un programme des gestion de document. Je voudrais ouvrir un document soit en mode lecture seule, soit en mode modification, pour ensuite le modifier.
 
Dois-je faire une cas d'utilisation différent (et donc un objet controleur différent) pour la lecture seule et la modification ?
 
Merci de vos réponses, ça pourrait bien m'aider
 
 
 

Reply

Marsh Posté le 13-06-2009 à 12:35:43   

Reply

Marsh Posté le 13-06-2009 à 12:55:50    

jamesbond2 a écrit :

A terme je voudrais évoluer vers un schéma MVC avec 1 controleur par CU.


IMO c'est une erreur. Les use cases sont les fonctionalités "haut niveau" et les problèmes que l'implémentation doit résoudre, mais ça ne veut absolument pas dire que l'implémentation doit suivre les use cases [:spamafote] Deux use-cases semblant très différents en surface peuvent parfaitement n'avoir que des différences réelles mineures une fois implémentés (ils utiliseront donc globalement les même code paths) et inversement.

jamesbond2 a écrit :


J'ai une interface de paramètrage simple qui me permet d'ajouter/modifier/supprimer des enreg. dans une table BDD. Dois-je faire un CU par action ?
 
CU1 => ajouter
CU2 => modifier
CU3 => supprimer
 
ou bien un CU unique pour ce module simple. Comme je veux  faire un objet controleur par CU, je trouvais un peu lourd de faire un objet controleur différent pour l'ajout, pour la modification et pour la suppression.


Ca dépend [:spamafote] Ca dépend des différents use cases, ça dépend de ton modèle, ça dépend de ta tech, ... [:spamafote]
 
Par exemple une création peut être vue comme une version dégénérée d'une modification (c'est une modification d'un objet n'existant pas encore); ou bien si tes objets sont versionnés et en fonction de la manière dont tu gères ton versionnement il est parfaitement possible que C, U et D soient à peu de chose près les mêmes opérations.

jamesbond2 a écrit :

Exeemple 2 :
 
J'ai un programme des gestion de document. Je voudrais ouvrir un document soit en mode lecture seule, soit en mode modification, pour ensuite le modifier.
 
Dois-je faire une cas d'utilisation différent (et donc un objet controleur différent) pour la lecture seule et la modification ?


Tu vas pas avoir "1 cas d'utilisation différent" pour chaque, ça n'a pas de sens. Par contre pour chaque opération sur laquelle ça peut faire une différence tu peux avoir un cas d'utilisation pour chaque état dans lequel un document peut se trouver (ou un sous-cas).
 
Je te suggère de lire ce qu'est un use case, parce que là ça a l'air vraiment flou dans ta tête [:petrus75]


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 10-07-2009 à 10:25:09    


 
Ton implémentation ne suivra pas parfaitement tes UC !
 
Mon idée serait :
ex1 :  
                    /->UC01_Add
UC00_Admin BD->UC02__Update
                    \->UC03_Delete  
 
Comme ça tu décompose bien ton fonctionnel de façon compréhensible et tu te laisse le choix de l'implémentation. 1 ou 3 controlleurs.
 
ex2 : 2 use cases : Lecture et Modification.
Modification inclut Lecture


---------------
How can I save my little boy from Oppenheimer's deadly toy ? There is no monopoly of common sense on either side of the political fence
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed