Discussion :

[maa]

Bonjour,

Je suis confronté au problème suivant.

Je dois développer une application qui permet d'organiser le rangement d'un entrepôt de produits alimentaires. Chaque produit est doit être rangé dans un frigo et affecté à une certaine place. Ensuite plusieurs acteurs ayant des rôles indépendants peuvent retrouver la place et le frigo d'un produit par le biais de l'application et plusieurs actions leurs sont proposées suivant leur rôle.

Pour le développement de cette application, et pour la première fois pour moi, j'ai décider d'adopter une approche UML.
Je n'ai pas eu trop de difficulté à créer un digramme de cas d'utilisation. Vous pouvez le consulter ici.
J'ai en revanche plus de mal à concevoir un diagramme de séquence système. J'ai même l'impression qu'il est inutile dans mon cas car il n'y a pas d'interactions entre les acteurs mais seulement entre un acteur et l'application.
Je me demande si des diagrammes d'activités pourrait remplacer ce diagramme de séquence système.
J'ai aussi lu qu'il était bien de réaliser des diagrammes d'activités de navigation pour décrire les interactions "utilisateur <-> interface graphique".
Pour un cas d'utilisation, vaut-il alors mieux réaliser d'abord un diagramme d'activité décrivant simplement chaque action puis un diagramme d'activité de navigation, ou vaut-il mieux ne faire qu'un seul diagramme, sachant que le deuxième ne fait que reprendre le premier en ajoutant les détails liés à l'interface graphique ?

Merci d'avance pour vos conseils

mathmax

[hegros]

Bonsoir,

J'ai en revanche plus de mal à concevoir un diagramme de séquence système. J'ai même l'impression qu'il est inutile dans mon cas car il n'y a pas d'interactions entre les acteurs mais seulement entre un acteur et l'application.

Les diagrammes de séquence système sont trés important il en faut au moins 1 pour chaque scénario nominal (sans les erreurs) de chaque cas d'utilisation. Ce travail n'est pas inutile les échanges entre acteurs/système sont porteurs d'informations qui seront les attributs de tes classes métiers.

J'ai aussi lu qu'il était bien de réaliser des diagrammes d'activités de navigation pour décrire les interactions "utilisateur <-> interface graphique".

Oui cela est trés pratique mais attention c'est pour modèliser la navigation pas pour concevoir le logiciel côté IHM.

Pour un cas d'utilisation, vaut-il alors mieux réaliser d'abord un diagramme d'activité décrivant simplement chaque action puis un diagramme d'activité de navigation, ou vaut-il mieux ne faire qu'un seul diagramme, sachant que le deuxième ne fait que reprendre le premier en ajoutant les détails liés à l'interface graphique ?

En fait pour chaque cas d'utilisation dans l'ordre (quand cela est possible) tu peux faire un diagramme d'activité (scénario nominal et scénarii d'exceptions), un diagramme de séquence (cela te permettra de faire un diagramme de classe d'analyse) et un diagramme de navigation une fois les écrans maquettés.

Attention un diagramme d'activité ce n'est pas un diagramme de navigation sans l'interface graphique ce sont 2 choses différentes. De plus un diagramme d'activité pour un cas d'utilisation n'est pas toujours nécessaire le diagramme de séquence est plus important pour chaque use case.

[maa]

Merci pour ces conseils.

Le problème est que mes diagrammes de séquences vont être bien pauvres car il n'y a pas d'interactions entre les acteurs. De plus l'aspect temps n'est pas important dans mon système.
Le risque est que les diagrammes de séquences systèmes ne disent rien de plus que le diagramme de cas d'utilisation, non ?

[hegros]

Les diagrammes de séquence système c'est les interactions entre acteurs et système s'il n'y en a pas c'est qu'il n'y a pas de cas d'utilisation. De quel aspect temps tu parles ?

Ce qui va dire de plus le DS c'est les attributs et de donner une vision dynamique du système ce que les cas d'utilisation ne disent pas du tout. les cas d'utilisation sont une vision fonctionnel du système à construire, d'ailleurs le tien en contient trop avec des extensions qui ont l'ait trés petite, un uc ne doit pas être un diagramme détaillé il doit resté au maximum compréhensible par tout le monde.

[maa]

Les diagrammes de séquence système c'est les interactions entre acteurs et système s'il n'y en a pas c'est qu'il n'y a pas de cas d'utilisation

Oui, il y a juste des interrections entre un acteur et l'application. Mais pas entre différents acteurs.

De quel aspect temps tu parles ?

Dans un diagramme de séquence les actions sont représenté selon une ligne du temps. Quand il y a plusieur acteurs qui intéragissent, certains doivent attendre le travail de l'un pour faire le leur. Il y a un ordre chronologique dans lequel se déroulent les chôses. Dans mon cas, il n'y a pas cet ordre. N'importe quel acteur peut utiliser le programme à n'importe quel moment sans attendre la fin d'un travail d'un autre.

d'ailleurs le tien en contient trop avec des extensions qui ont l'ait trés petite,

Que veux-tu dire par là ? Ca m'interesse car c'est la première fois que je fais une démarche UML.

Ce qui va dire de plus le DS c'est les attributs et de donner une vision dynamique du système ce que les cas d'utilisation ne disent pas du tout.

Le diagramme d'activité ne pourrait-il alors pas dire la même chose plus précisément ?

[hegros]

Oui, il y a juste des interrections entre un acteur et l'application. Mais pas entre différents acteurs.

C'est justement pour modèliser ces interactions qu'on utilise le DS

Dans un diagramme de séquence les actions sont représenté selon une ligne du temps. Quand il y a plusieur acteurs qui intéragissent, certains doivent attendre le travail de l'un pour faire le leur. Il y a un ordre chronologique dans lequel se déroulent les chôses. Dans mon cas, il n'y a pas cet ordre. N'importe quel acteur peut utiliser le programme à n'importe quel moment sans attendre la fin d'un travail d'un autre.

Prends le cas d'utilisation "Consulter une vente". Il y a un seul acteur qui interagit avec le système. L'ordre c'est celui des interactions pour un cas pas pour tout le programme.

Que veux-tu dire par là ? Ca m'interesse car c'est la première fois que je fais une démarche UML.

Un UC est un modèle d'usage c'est une vision fonctionnelle il ne faut pas chercher à faire un truc super complet du premier coup. On entends souvent qu'une dizaine de cas d"utilisation est suffisant. Tu peux faire passer le test à des UC. Celui de la taille : quand c'est estimé trop petit on le supprime par exemple "entrer un critere" est un cas d'utilisation vraiment trés petit il n'apporte pas de plus value au diagramme au contraire cela l'alourdit alors que le principe premier d'un diagramme uml c'est de l'utiliser comme moyen de communication (pour toi déja à comprendre ce que tu fais et aux autres intervenants)

Le diagramme d'activité ne pourrait-il alors pas dire la même chose plus précisément ?

Le diagramme d'activité n'est pas porteur d'information comme un diagramme de flux de données, ce sont des opérations avec des transitions automatiques. Il ne faut pas perdre de vue que dans une démarche UML il faut au minimum au final un diagramme de classe de conception (avec attributs et méthodes)

[maa]

Tu peux faire passer le test à des UC. Celui de la taille : quand c'est estimé trop petit on le supprime par exemple "entrer un critere" est un cas d'utilisation vraiment trés petit il n'apporte pas de plus value au diagramme au contraire cela l'alourdit

Ok, du coup est-ce que je laisse le cas d'utilisation "Chercher un lot de produits" ? Quels autres UC enlèverais-tu ?
Un autre truc sur lequel j'hésitais et l'UC "consulter les dates d'arrivages" qui est une extension de consulter les places des produits. Pour chaque produit, on donne en plus de sa place, la date à laquelle il est arrivé. Comme on ajoute cette date seulement pour certains utilisateurs, j'ai ajouté une condition. Ca te parait correct ? Ou faudrait-il plutôt faire un généralisation qu'une extension (mais avec une généralisation il n'y a pas de condition...) ?

Le diagramme d'activité n'est pas porteur d'information comme un diagramme de flux de données, ce sont des opérations avec des transitions automatiques.

J'ai du mal à voir quelles informations il apporte en plus par rapport au diagramme d'activité.
Voici un exemple de diagramme d'activité :

Pour cet exemple, qu'apporterait de plus le diagramme de séquence ?

[hegros]

Ok, du coup est-ce que je laisse le cas d'utilisation "Chercher un lot de produits" ? Quels autres UC enlèverais-tu ?

Je n'ai pas regardé dans le détail un autre test c'est celui du patron, on se pose la question est-ce que le patron est content lorsque "puis tu cites le cas d'utilisation" dans le cas d'une réponse non satisfaisante tu peux supprimer cet uc.

Un autre truc sur lequel j'hésitais et l'UC "consulter les dates d'arrivages" qui est une extension de consulter les places des produits. Pour chaque produit, on donne en plus de sa place, la date à laquelle il est arrivé. Comme on ajoute cette date seulement pour certains utilisateurs, j'ai ajouté une condition. Ca te parait correct ? Ou faudrait-il plutôt faire un généralisation qu'une extension (mais avec une généralisation il n'y a pas de condition...) ?

Cela me semble trop détaillé à mon avis au moment de la rédaction textuelle du cas d'utilisation tu écriras cette extension.

J'ai du mal à voir quelles informations il apporte en plus par rapport au diagramme d'activité.

Il montre les échanges/la communication entre le système et les acteurs il faut aussi penser que les messages échangés sont en fait des opérations que tu retrouveras par la suite dans ton diagramme de classe. Parce qu'il y a le DS boite noir et boite blanche d'ailleurs la conception logicielle se fait à moitié avec des DS (toute la partie dynamique, comportements et contrats)

Pour cet exemple, qu'apporterait de plus le diagramme de séquence ?

Essaie d'en faire un pour voir

[maa]

Essaie d'en faire un pour voir

Voilà, mais j'ai sûrement mal fait car je comprends toujours pas ce que le DS apporte en plus...



Pourrais tu me dire ce que j'ai raté ?

[hegros]

Ce que tu as raté ce sont les paramètres des messages et valeur de retour. Quand un acteur envoi un message au système c'est équivalent à appeler une méthode d'une classe du système. Là ce que tu as fais c'est un DS boîte noir après pour chaque opération (enfin celles qui semble complexe) tu devras faire un DS boite blanche.



Contre-exemple sur l'opération "Saisir nouvelle voiture" :

Elle devrait fournir plus d'éléments et syntaxiquement cela ressemble plus à une méthode de classe : saisirNouvelleVoiture(couleur,marque,prix)


On peut éviter les fragments en écrivant :

[voiture n'existe pas] saisirNouvelleVoiture(couleur, marque, prix)

La numérotation est inutile (1,2,3...) car un DS se lit systèmatiquement du haut vers le bas. Tu utilises quel logiciel ?

[wiztricks]

Merci pour ces conseils.

Le problème est que mes diagrammes de séquences vont être bien pauvres car il n'y a pas d'interactions entre les acteurs. De plus l'aspect temps n'est pas important dans mon système.
Le risque est que les diagrammes de séquences systèmes ne disent rien de plus que le diagramme de cas d'utilisation, non ?

Après avoir parcouru le diagramme d'UC joint, il manque des bouts dans la logique métier:
- qu'est ce qui déclenche un approvisionnement de produit x, y, z?
- à partir de quoi sait-on qu'il va falloir livrer a, b, c aux clients u, v, w?
- comment est ce qu'on facture les livraisons.
=> à priori, il y a des interactions avec ces autres acteurs (au sens "entités externes") qui font défaut

Il serait sage de modéliser un peu le "comment" et voir comment il torture le quoi (les UC). Le but étant d'enrichir, de reformuler les UC existants pour avoir une vision plus claire sur les points à compléter et sur les fonctions de base. Dit autrement, faire la part des choses entre le coeur de métier et "les extensions"

Ca veut dire quoi ce charabia.

C'est un entrepôt.
A droite, il y a des camions qui arrivent et livrent des produits par palettes.
-> réceptionner les camions : ou stocker ces palettes quelque part.
A gauche, il y a des camions partent pour livrer à des clients des produits dans les quantités qu'ils ont commandé.

-> préparer les livraisons en fonction des commandes et du disponible en stock. Cela produit des colis (ou autre conteneur) à livrer à X, Y, ...
-> placer les colis dans le camion en fonction de l'itinéraire "optimal".

Ce sont des UC qui correspondent aux flux physiques, le métier de base de l'entrepôt.

"Au dessus" de ces flux physiques, il y a toute la logique de gestion du stock en fonction des commandes ou des prévisions de commandes clients et/ou de la fréquence d'approvisionnement - quelque part il manque une sorte d'ERP.
=> "dans l'entrepôt", il y a un UC qui est optimiser la place en fonction des prévisions d'arrivées et de départ.

Un dernier UC est "gérer les invendus".
-W

[hegros]

maa dans ta démarche UML quel lien tu as entre ton diagramme de cas d'utilisation et ton diagramme d'activité ? Tu essayer de modéliser tout l'ensemble des cas à un plus haut niveau ? Tu remarqueras que le diagramme de séquence que je t'ai présenté est fait pour 1 seul cas d'utilisation, il permet aussi de repérer les entités métiers et ainsi de faciliter la transition vers un diagramme de classe métiers. Un diagramme d'activité devrait au mieux t'apporter des méthodes de classes.

Aussi comme le rappel wiztricks le UC n'est pas une fin en soi et la partie coeur de métiers n'est pas négligeable .

En pratique pour chaque use case on se pose ces questions : qu'est-ce qui déclenche le cas d'utilisation ? Quelles sont les pré et post conditions ? Qui sont les acteurs primaires et secondaires et leur interet ? Quelles sont les contraintes ? ... ?

Tu trouves sur internet des truc plus ou moins adoptés qui ressemblent à cela pour la rédaction textuelle des cas d'utilisation. C'est pour te donner un aperçu.

[maa]

Merci pour vos conseils.

Ce que tu as raté ce sont les paramètres des messages et valeur de retour. Quand un acteur envoi un message au système c'est équivalent à appeler une méthode d'une classe du système. Là ce que tu as fais c'est un DS boîte noir après pour chaque opération (enfin celles qui semble complexe) tu devras faire un DS boite blanche.

Là ça te parait mieux ?

Y a t-il encore des choses à corriger ? à améliorer ?

La numérotation est inutile (1,2,3...) car un DS se lit systèmatiquement du haut vers le bas. Tu utilises quel logiciel ?

La version démo de Visual Paradigm. Tu en connais un meilleur ? Gratuit ?

maa dans ta démarche UML quel lien tu as entre ton diagramme de cas d'utilisation et ton diagramme d'activité ?

Pour l'instant encore aucun car mon diagramme d'activité n'est pas encore réalisé.

Tu essayer de modéliser tout l'ensemble des cas à un plus haut niveau ?

Oui j'ai essayé d'inventorier tous les cas possible d'utilisation dans mon diagramme UC.

Tu remarqueras que le diagramme de séquence que je t'ai présenté est fait pour 1 seul cas d'utilisation, il permet aussi de repérer les entités métiers et ainsi de faciliter la transition vers un diagramme de classe métiers. Un diagramme d'activité devrait au mieux t'apporter des méthodes de classes.

Mais je croyais que le diagramme d'activité était plus "précis" que le diagramme de séquence ? Si je comprends bien, par plus précis on entends en fait qu'il découpe mieux les actions qui compose un certain cas d'utilisation mais reflètent moins la structure métier. C'est cela ?

wiztricks, je n'ai pas voulu ici modéliser tous le fonctionnement de l'entreprise car celle ci possède déjà un logiciel pour gérer ses stock, ses ventes, ses préparation de commande, ses expéditions,...
On m'a demandé de simplement concevoir un logiciel pour organiser le rangement des produits et gérer 2 ou 3 situations pour tirer parti de ce rangement (achalandeur, responsable inventaire, manutentionnaire).

=> "dans l'entrepôt", il y a un UC qui est optimiser la place en fonction des prévisions d'arrivées et de départ.

En revanche ceci est un aspect que je dois aussi traiter. Merci !

Sinon vois-tu des défaut ou des oublis dans la conception de mon diagramme UC ?

Merci beaucoup pour vos conseils. Chaque correction ou suggestion m'est d'une aide précieuse car je n'ai jamais suivi de formation UML (à part la lecture d'un tutoriel) et c'est la première fois que je met la démarche en pratique.

[hegros]

Là ça te parait mieux ?
Y a t-il encore des choses à corriger ? à améliorer ?

Oui c'est nettement mieux. il y a quelque chose assez important pour la lisibilité c'est qu'un DS tu le fais pour un UC et là on ne voit pas duquel il s'agit tu peux utiliser les commentaires UML pour commenter tes diagrammes.

Puis je ne comprends pas il y a des voitures des assurances des garanties dans ce DS et cela ne ressort pas dans le UC et aussi quand tu dis.

On m'a demandé de simplement concevoir un logiciel pour organiser le rangement des produits et gérer 2 ou 3 situations pour tirer parti de ce rangement (achalandeur, responsable inventaire, manutentionnaire).

La version démo de Visual Paradigm. Tu en connais un meilleur ? Gratuit ?

bouml regarde sur le forum il est trés pratique et rapide je n'en connais pas de meilleur et gratuit.

Pour l'instant encore aucun car mon diagramme d'activité n'est pas encore réalisé.

Oui j'ai essayé d'inventorier tous les cas possible d'utilisation dans mon diagramme UC.

Mais je croyais que le diagramme d'activité était plus "précis" que le diagramme de séquence ? Si je comprends bien, par plus précis on entends en fait qu'il découpe mieux les actions qui compose un certain cas d'utilisation mais reflètent moins la structure métier. C'est cela ?

Dans une démarche UML en principe 3 étapes: expression des besoins, analyse et conception. La quatrième étant l'implémentation.

Le diagramme d'activité est à la frontière entre l'analyse et la conception, en expression des besoins on utilise plutôt les diagrammes UC, diagramme de classe, les DS et aussi les écrans. En analyse et conception cela varie mais l'interet réside à enrichir ceux provenant de l'expression des besoins et de faire de nouveaux diagrammes comme celui de communication pour concevoir le logiciel ou de package pour l'architecture.

Aussi important, cela vient probablement avec le temps, il faut penser itération. On ne peux pas faire tout les UC d'un seul coup parfaitement. Une itération c'est 2-6 semaine sur les 3 étapes suivi de ce que tu estimes pour l'implémentation et une itération concerne un ensemble de scénarios de cas d'utilisation prédéfinis avec les utilisateurs finaux. C'est une façon d'aller vers un produit tangible ainsi itération 1 = version 0.1 du logiciel, itération 2 on termine le reste à faire , itération 3 etc jusqu'à terminer tout les cas d'utilisation J'avoue être jeune aussi dans ces pratiques si ce n'est pas clair desfois pour moi c'est pareil

[maa]

Puis je ne comprends pas il y a des voitures des assurances des garanties dans ce DS et cela ne ressort pas dans le UC et aussi quand tu dis.

Euh non les voitures c'était juste un exemple pour comparer diagramme de séquence et et d'activité. Rien à voir avec mon programme. Désolé, c'était pas très clair...

Maintenant je vais concevoir les diagramme de séquence pour chaque cas d'utilisation de mon projet. Si tu es d'accord je les posterais bien pour savoir ce que tu en penses.

Et donc après, si je comprend bien, je fais un diagramme de classe en m'appuyant sur le diagramme de séquence puis je réfléchi aux algorithmes avec les diagramme d'activités (tout en enrichissant mes classes, mes cas d'utilisation,...)

[hegros]

Et donc après, si je comprend bien, je fais un diagramme de classe en m'appuyant sur le diagramme de séquence puis je réfléchi aux algorithmes avec les diagramme d'activités (tout en enrichissant mes classes, mes cas d'utilisation,...)

OK.

le diagramme d'activité on peut s'en servir pour différentes choses, pour faire un diagramme de navigation dans l'ihm c'est trés intéressant, pour décrire un cas d'utilisation plus détaillé aussi, flux de documents/de données, décision, enfin pour pleins de choses de ce qui peut déja exister.

Découpe bien tes UC présente nous seulement ceux qui te semble le plus significatifs et importants pour l'application finale. Essaie de prendre en compte les remarques pour affiner ton UC.

[maa]

Découpe bien tes UC présente nous seulement ceux qui te semble le plus significatifs et importants pour l'application finale. Essaie de prendre en compte les remarques pour affiner ton UC.

Oui, j'attends encore le retour de wiztricks. J'ai essayé de faire un diagramme représentant les UC de mon application sans vouloir représenter le fonctionnement global de l'entreprise.

[wiztricks]

wiztricks, je n'ai pas voulu ici modéliser tous le fonctionnement de l'entreprise car celle ci possède déjà un logiciel pour gérer ses stock, ses ventes, ses préparation de commande, ses expéditions,...
On m'a demandé de simplement concevoir un logiciel pour organiser le rangement des produits et gérer 2 ou 3 situations pour tirer parti de ce rangement (achalandeur, responsable inventaire, manutentionnaire).

Mon propos était de dire que ton diagramme d'UC devrait peut être "montrer" comment les informations gérées par les logiciels existants s'articulent avec ce que tu te proposes de construire.

Sinon vois-tu des défaut ou des oublis dans la conception de mon diagramme UC ?

Des oublis je ne sais pas.

Le défaut est peut être de ne pas avoir organisé ces UC autour des activités principales de l'entrepôt (des camions qui arrivent et qui partent avec des implications sur les places et les produits).

Mais j'aime bien l'idée d'itérations présentée par Hegros:
-W






J'aime bien les itérations 0.1, 0.2, 0. dans la phase de conception présenté par Hegros.

[maa]

Le défaut est peut être de ne pas avoir organisé ces UC autour des activités principales de l'entrepôt (des camions qui arrivent et qui partent avec des implications sur les places et les produits).

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.

[hegros]

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.

Il faut voir avec ton responsable projet le fait de prendre en compte le programme existant il vous répondra clairement non pour le moment ou en dira plus. Cependant lister les interfaces possibles avec les autres applications métiers de l'entreprise ne serait pas vaine mais cela peut prendre du temps, il faut que vous validiez si cela fait parti ou pas de l'objet de votre étude.