Discussion :

[zelig]

salut à tous,
Je suis un novice en UML, j'ai pas mal avancé en UML, mais une question me laisse perplexe. Exemple Gestion de boutique:
J'ai un use case comme ça par exemple (j'espaire le bien déssiner):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
      O                 __________________
     -|-  ------------( Gérer les produits)
      ^                 ------------------
 Utilisateur

Bon, ensuite je décortique chaque use case, pour en extraire des scénarios.
Exemple:
Scénario 1: Ajouter un produit

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

[utilisateur]          [:ProductsManager]            [:productsTableManager]
     |                         |                                |
     |                         |                                |
     |                         |                                |
     - CreateProduct(product)  -                                |
    | |---------------------->| |                               |
    | |                       | | CreateProdIfNotExist(product) -
    | |                       | |----------------------------->| |
    | |                       | |          Response()          | |
    | |   Response()          | |<-----------------------------| |
    | |<----------------------| |                               -
    | |                        -                                |
     -                         |                                |
     |                         |                                |

L'utilisateur represente ici normalement le UI (interface utilisateur).
En travaillant sur Visual Studio par exemple, on peut remarquer que l'interface utilisateur peut combiner une, à plusieurs classes.
On en arrive à ma question:
<<Est ce que Utilisateur doit apparaitre obligatoirement et à chaque fois dans le diagramme des classes ou pas?>>
Dans ce cas, l'analyse englobera trop de classes, qui sont des fois tres dependant du langage ou technologie, et donc ça peut bloquer le process d'analyse.

En passant, merci de corriger d'eventuelles erreurs sur cet exemple.
NOTE:
ATTENTION a ne pas prendre l'exemple suivant pour apprentissage (pour les novice), car je suis moi même novice, et ça peut etre plein d'erreur.

[ndp]

Salut,

je te donne mon opinion.

S'il s'agit d'Analyse, il y a quand meme peu de chance que tu ais besoin de representer les classes de l'interface graphique dans un quelconque diagramme. Pour moi c'est un peu hors du scope de l'Analyse.
Ca peut rester tres simple, en fait, comme tu le fais deja dans tes diagrammes.

A mon avis, ces classes apparaitrons plus tard, pourquoi pas dans une phase tardive de la conception, au moment ou tu voudras te focaliser sur l'interface graphique.

[zelig]

Merci pour cette réponse.
J'espaire plus de commentaires à ce sujet.

[hed62]

Juste en passant, utilise un modeleur Je ne sais pas si j'aurais eu la patience de réaliser cet ascii-art

[ze_corsaire]

Je suis d'accord avec ndp, quand tu décris ton use case par un scénario, l'utilisateur n'est pas une classe mais un acteur.
Ensuite, en analyse, lorsque tu affineras ce même scénario fonctionnel, tu pourras utiliser une classe IHM stéréotypée <<boundary>> qui fera interface entre le même acteur et le système.

_____________