Discussion :

[wiztricks]

Oui mais je ne vais pas intégrer mon programme dans le programme existant car celui-ci est développé en clipper... Donc je vais faire un programme assez indépendant de ce qui est fait. D'où un diagramme qui ne s'intéresse qu'à ce que le programme traitera. J'ai peut être tord.

C'est mon avis
Comme vous êtes en phase de conception, il me semble essentiel d'inventorier les dépendances que vous avez avec l'extérieur.

Si vous les zappez, vous risquez d'avoir des incohérences dans:
- le vocabulaire utilisé par les deux programmes,
- les informations demandées et fournies pour réaliser une activité particulière.

Considérez vos UC comme des extensions des activités qui sont réalisées dans l'entrepôt: les pré-requis et les informations à produire en sortie seront plus "naturels".
Vous n'avez pas besoin d'aller dans les détails, ie y passer beaucoup de temps, mais cela va vous fixer un contexte pour les opérations que vous allez assister par ordinateur.
- préparer une livraison
- stocker des colis de
- ...
-W

[maa]

J'ai simplifié un peu mon digramme de cas d'utilisation et réalisé un premier diagramme de séquence.

Diagramme de cas d'utilisation :
http://www.mynetdomain.de/mathmax/useCases2.jpg

Diagramme de séquence pour la mise à jour des places des produits :


J'ai plusieurs questions sur ce diagramme :
-Tout d'abord je suis un peu étonné par la légèreté du diagramme. J'ai traité un de mes cas les plus complexe et le diagramme ne parait pas très riche en information. Ai-je oublié quelque chose ? C'est un peu ce dont j'avais peur, tous mes cas d'utilisation sont assez simple et je ne suis pas sûr de l'utilité de diagramme de séquence pour les expliquer. Pour de cas d'utilisations comme "Consulter des infos", le diagramme va se résumé à 2 flèches : "demande d'infos" et "infos fournie". Est-ce bien utile alors de faire un diagramme séquence pour chaque cas d'utilisation ?

- Existe t-il un fragment d'interaction combiné ou un autre moyen pour dire qu'on exécute une procédure pour chaque produit. Par exemple, en 2 on obtiens une liste de produits et en 3, pour chaque produits, on lui affecte un ou plusieurs frigo. Je ne sais pas si c'est suffisamment compréhensible comme ça.

- Je n'ai pas su comment insérer le cas d'utilisation "Vérifier disponibilité d'une place". Pourtant c'est quelque chose qui doit être fait côté programme. De plus si la place n'est effectivement pas disponible, il faudrait que l'utilisateur en saisisse une autre. J'ai arrangé cela en fournissant une liste de produits disponible plutôt que de laisser le choix à l'utilisateur de saisir un champ libre. C'est peut être mieux en fin de compte mais je me demande comment on aurait put représenté un tel cas de figure qui implique parfois de recommencer une opération.

- Est-ce qu'un diagramme d'activité vous semble nécessaire pour décrire un tel cas d'utilisation ?

Merci d'avance pour vos conseils.

[hegros]

C'est le diagramme le plus important et c'est souvent à partir de lui qu'on construit le diagramme de classe, peut-être n'en vois-tu pas l"utilité parce que tu débutes en uml et que tu n'as défini le lien entre les diagrammes uml et les étapes de ton projet.


Tu dis que le diagramme est léger mais cela veut dire que ton scénario nominal pour ce cas d'utilisation est léger. Tu es sûr qu'il corresponds bien au scénario réel du responsable de rangement et que rien ne manque? De plus tu as l'air d'avoir utilisé une généralisation du cas ce qui veut dire que ce n'est pas complet puisqu'il manque le ds de mettre à jour les frigos ce qui est un peu bizar...


Ensuite tout les diagrammes UML sont inutiles sauf s'il apporte une meilleure compréhension soit si un diagramme d'activité peut t'aider à modéliser un cas d'utilisation ne t'en prive pas mais cela n'ira pas plus loin que le diagramme de séquence au vu de où tu en es dans ton projet et finira probablement aux oubliettes lorsqu'il faudra concevoir(contrairement au diagramme de séquence)


Pour ton UC, les ? cela veut dire peut-être ou je ne sais pas ? Soit c'est un cas soit s'en est pas un, normalement on s'assure auprés des intervenants que les UC corresponds bien à ce qu'ils veulent. Pareil pour les cas avec dedans des grandes phrases terminant par etc... Pour les stocks il faudrait en parler avec le manutentionnaire il te dira le scénario que tu pourras retranscrire avec lui sur un DS. Connaître la travée est un drôle de cas on a du mal à imaginer un scénario. Bref ton UC ne me semble pas encore épuré et terminé ce qui rends de tout manière des difficultés pour la suite (diagramme de séquence ou d'activité) encore dit autrement : l'expression des besoins n'a pas l'air stable.


Pour finir, le fragment pour faire des boucles c'est loop.

[maa]

C'est le diagramme le plus important et c'est souvent à partir de lui qu'on construit le diagramme de classe, peut-être n'en vois-tu pas l"utilité parce que tu débutes en uml et que tu n'as défini le lien entre les diagrammes uml et les étapes de ton projet.

Ok, mais penses-tu qu'il faille en faire pour les cas d'utilisation simple comme "consulter des infos" ? Est-ce que ça te semble vraiment utile d'en faire un par cas d'utilisation ?

tu as l'air d'avoir utilisé une généralisation du cas ce qui veut dire que ce n'est pas complet puisqu'il manque le ds de mettre à jour les frigos ce qui est un peu bizar...

Je ne comprends pas trop ce qu'il manque. Peux-tu me le ré expliquer ?

Pour ton UC, les ? cela veut dire peut-être ou je ne sais pas ? Soit c'est un cas soit s'en est pas un, normalement on s'assure auprés des intervenants que les UC corresponds bien à ce qu'ils veulent. Pareil pour les cas avec dedans des grandes phrases terminant par etc...

Ce sont des fonctionnalités qui ont été évoquées. Je ne sais pas encore si elles seront implémentés. Je vais essayer de l'épurer encore, de la clarifier et, comme me le conseillait wiztricks, de voir comment l'intégrer avec les activité des programmes existants.

Pour finir, le fragment pour faire des boucles c'est loop.

Comme ça ?


Concernant les messages comme "vérifier des disponibilités" qui nécessitent éventuellement de recommencer certaines opérations, comment les modéliser ? On pourrait par exemple pouvoir redemander la saisie d'une place tant qu'on en a pas choisie une qui est disponible.

[hegros]

Ok, mais penses-tu qu'il faille en faire pour les cas d'utilisation simple comme "consulter des infos" ? Est-ce que ça te semble vraiment utile d'en faire un par cas d'utilisation ?

On commence normalement par faire les cas d'utilisation les plus prioritaires et les plus importants puis on les implémente. Il peut toujours être utile d'en faire un par cas d'utilisation si cela s'avére nécessaire. Normalement on ne passe pas plus de 1-2H sur un diagramme UML surtout en ce qui concerne les UC on passe plus de temps à le rédiger (pré et post condition, déclenchement...)

Je ne comprends pas trop ce qu'il manque. Peux-tu me le ré expliquer ?

Il y a des cours et des tutoriels pour cela. Normalement tu es sensé savoir ce qu'est une généralisation puisque tu l'utilises dans ton modèle de cas d'utilisation sinon tu ne l'utiliserais pas. A vrai dire j'évite de m'en servir d'ailleurs cela ne m'est pas encore arrivé.

Ce sont des fonctionnalités qui ont été évoquées. Je ne sais pas encore si elles seront implémentés. Je vais essayer de l'épurer encore, de la clarifier et, comme me le conseillait wiztricks, de voir comment l'intégrer avec les activité des programmes existants.

Tu ne peux pas travailler tout seul il faut en parler avec les intervenants jusqu'à ce que tu stabilises ton UC avec ce qu'il y a réellement à réaliser. Il y a d'autres diagrammes comme composant et deployement qui peuvent t'aider par rapport à l'existant.

Comme ça ?

Regarde les nombreux exemples dans les cours developpez et sur internet

Concernant les messages comme "vérifier des disponibilités" qui nécessitent éventuellement de recommencer certaines opérations, comment les modéliser ? On pourrait par exemple pouvoir redemander la saisie d'une place tant qu'on en a pas choisie une qui est disponible.

Je ne vois pas de message verifier des disponibilités dans le ds...

Le fragment loop semblerait répondre : loop: place disponible choisi operation:saisie d'une place

[maa]

Normalement tu es sensé savoir ce qu'est une généralisation puisque tu l'utilises dans ton modèle de cas d'utilisation sinon tu ne l'utiliserais pas.

En fait c'était ta phrase que je n'avais pas compris.

il manque le ds de mettre à jour les frigos ce qui est un peu bizar...

En fait j'ai fais une généralisation car on peut vouloir affecter un frigo à un produit sans lui attribuer une place. C'est un cas moins précis qu'attribuer une place dans un frigo. J'avais pensé que le second cas est e ce fait une généralisation du premier. En fait ça serait plutôt une extension, non ?
Je n'ai représenté que le DS pour le cas le plus détaillé. Pour le cas d'utilisation "mettre simplement à jour un frigo", j'aurais put rendre optionel les flèches 4, 5 et 6. Ou alors aurais-je du refaire un autre diagramme sans ces points ?

Je ne vois pas de message verifier des disponibilités dans le ds...

Finalement le programme propose directement les place disponibles. De son côté il fait la vérification, mais ça je ne peux pas le représenter sur le DS. En fait, d'après ce tutoriel, le loop servirait plus à recommencer une opération tant qu'une condition n'est pas satisfaite et répondrait donc à ma question "comment modéliser des opérations qui sont susceptibles de se répéter".
En revanche il ne conviens pas trop pour les points 3, 5 et 6, pour dire : "j'applique cette opération à chaque produits/chaque frigos". Et je n'ai pas trouvé d'opérateurs pour dire cela. Mais peut être que ça se comprend suffisamment sans fragment ?

[hegros]

En fait j'ai fais une généralisation car on peut vouloir affecter un frigo à un produit sans lui attribuer une place. C'est un cas moins précis qu'attribuer une place dans un frigo. J'avais pensé que le second cas est e ce fait une généralisation du premier. En fait ça serait plutôt une extension, non ?
Je n'ai représenté que le DS pour le cas le plus détaillé. Pour le cas d'utilisation "mettre simplement à jour un frigo", j'aurais put rendre optionel les flèches 4, 5 et 6. Ou alors aurais-je du refaire un autre diagramme sans ces points ?

je n'utilise pas les généralisations du coup je ne peux pas t'aider dessus.

Pour le reste je n'ai rien compris.

[maa]

Je n'ai représenté que le DS pour le cas le plus détaillé. Pour le cas d'utilisation "mettre simplement à jour un frigo", j'aurais put rendre optionel les flèches 4, 5 et 6. Ou alors aurais-je du refaire un autre diagramme sans ces points ?

Quand je parle des flèche 4, 5 et 6, ce sont les messages numéroté 4, 5 et 6 sur le diagramme. Si on met à jour seulement les frigo sans affecter de place, on n'est pas concerné par ces flèches.

En revanche il ne conviens pas trop pour les points 3, 5 et 6, pour dire : "j'applique cette opération à chaque produits/chaque frigos". Et je n'ai pas trouvé d'opérateurs pour dire cela. Mais peut être que ça se comprend suffisamment sans fragment ?

En 2, on obtient une liste de produits.
En 3, on voudrait affecter un ou plusieurs frigo à chaque produit
En 4, on obtient une liste de places disponibles.
En 5, on voudrait affecter une ou plusieurs places à chaque couple produit-frigo
Ma question est : comment représenter ces itérations ?

[hegros]

Quand je parle des flèche 4, 5 et 6, ce sont les messages numéroté 4, 5 et 6 sur le diagramme. Si on met à jour seulement les frigo sans affecter de place, on n'est pas concerné par ces flèches.

Comme dis dans un précédent message c'est la première voir que je vois une numérotation pour un DS et je n'y trouve encore aucun interet.

En 2, on obtient une liste de produits.
En 3, on voudrait affecter un ou plusieurs frigo à chaque produit
En 4, on obtient une liste de places disponibles.
En 5, on voudrait affecter une ou plusieurs places à chaque couple produit-frigo
Ma question est : comment représenter ces itérations ?

une itération se fait avec un fragment loop donc ce que tu as dans le DS semble bien correspondre, je ne comprends pas ce qui te géne

Normalement le passage entre UC et DS est naturel lorsqu'on a rédigé en texte essentiel le cas d'utilisation en question. Là à priori tu ne te sers que de la vision du diagramme uc pour ton ds ce qui est quand même insuffisant

[maa]

Comme dis dans un précédent message c'est la première voir que je vois une numérotation pour un DS et je n'y trouve encore aucun interet.

Je pense que ca peut être utile quand on expose son projet pour dire plus facilement et plus rapidement de quoi on parle.

Penses-tu donc qu'il vaut mieux faire un diagramme par cas d'utilisation :
- affecter des frigos à des produits
- affecter des places dans des frigos à des produits
Comme le second cas "englobe" le premier, je pense que je ne peux en faire qu'un seul et rendre l'affectation de place optionnelle. Qu'en penses-tu ?

[hegros]

Penses-tu donc qu'il vaut mieux faire un diagramme par cas d'utilisation :

En général oui c'est plutôt conseillé cependant on commence toujours par les plus prioritaires et les plus importants, ce qui est/sera le plus signifiant pour l'architecture final.

- affecter des frigos à des produits
- affecter des places dans des frigos à des produits
Comme le second cas "englobe" le premier, je pense que je ne peux en faire qu'un seul et rendre l'affectation de place optionnelle. Qu'en penses-tu ?

Pas vraiment non. Un DS c'est d'une part le scénario nominal et d'autre part,séparemment, on fait d'autres DS pour les extensions et les exceptions. C'est le diagramme d'activité qui te permettrait de réunir tout les scénarios d'un cas mais je n'ai pas encore vu un diagramme qui permet de modéliser 1,2 ou 3 cas d'utilisation en même temps...

[maa]

je n'ai pas encore vu un diagramme qui permet de modéliser 1,2 ou 3 cas d'utilisation en même temps...

Il me semble que beaucoup d'exemples sur le web montres des DS qui reprennent plusieurs cas d'utilisations.
Par exemple celui-ci :

[hegros]

le lien est mort.

[maa]

Bizarre. J'ai mis l'image directement dans mon post. Elle apparait bien chez moi même après rafraichissement. Il est possible que mon serveur ai eu un petit moment de faiblesse. Peux tu ré essayer ?

[hegros]

Mouais on a quand même du mal à distinguer les cas cela fait tout mélanger et on ne s'y retrouve pas trop surtout qu'il n'y a pas de commentaires. En plus ce n'est pas un diagramme de séquence système (ce dont on parle depuis le début) c'est un diagramme d'interaction. Je préfére de loin(pour des raisons de conduite de projet que je ne détaillerais pas) avoir dans un diagramme de séquence système ce qui corresponds à 1 UC.