Discussion :

[quanta]

Bonjour,
Voila dans le cadre d'un projet, j'ai commencé à concevoir un user case (voir pièce jointes) pour la modélisation des besoins utilisateurs. j'aurais voulu avoir un avis sur cette réalisation afin de savoir si j'applique la bonne méthode.
Merci d'avance.
(je m'excuse d'avance pour les fautes, elles sont en cours de correction)

[bruno_pages]

Bonjour,

vos 2 UCs gérer xxx sont trop vague, la description montre plusieurs interactions acteur-système, vous deviez les décomposer en plusieurs UCs

quel est le but du nommage "principal" des associations acteur-UC ?

pour mieux montrer les différentes possibilités au niveau diagramme de séquence le mieux est soit d'utiliser les combined fragment alt, soit de faire plusieurs diagrammes

[quanta]

Bonjour,

vos 2 UCs gérer xxx sont trop vague, la description montre plusieurs interactions acteur-système, vous deviez les décomposer en plusieurs UCs

quel est le but du nommage "principal" des associations acteur-UC ?

pour mieux montrer les différentes possibilités au niveau diagramme de séquence le mieux est soit d'utiliser les combined fragment alt, soit de faire plusieurs diagrammes

J'ai bien pris note de vos remarque, donc par exemple pour le cas de l'UC 'Gestion des fiches de suivi qualité' on pourrai avoir : comme UCs : ouvrir une fiche de suivi qualité, clôturer une fiche de suivi qualité ?

[bruno_pages]

oui

[quanta]

oui

Merci de me répondre xD
Je vais abuser j’ai une autre question (qui malheureusement n’est pas vraiment clairement expliquer dans la documentation et les ouvrages concernant l’uml) :
Soit un cas A qui inclut un cas B1 et B2 (c'est-à-dire que A se décompose en B1 et B2)
 Si j’ai bien compris la réalisation de B1 et de B2 est nécessaire pour clôturer A ? (sans dimension temporel toutefois)
 Faut-il faire le scénario textuel de A ou seuls les scénarios de B1 et B2 suffisent ?

[quanta]

« quel est le but du nommage "principal" des associations acteur-UC ? »

Le but de ce nommage est de stéréotypé la relation utilisateur – utilisation en «primary» (erreur de formalisme de ma part).

[bruno_pages]

Soit un cas A qui inclut un cas B1 et B2 (c'est-à-dire que A se décompose en B1 et B2)
Si j’ai bien compris la réalisation de B1 et de B2 est nécessaire pour clôturer A ? (sans dimension temporel toutefois)

oui

si c'est optionel (ie non obligatoire) il faut retourner la dépendance et la stéréotypée extend

Faut-il faire le scénario textuel de A ou seuls les scénarios de B1 et B2 suffisent ?

il faut faire celui de A mais sans y décrire ce qui est fait dans B1 et B2, ie B1 et B2 sont des boites noires, à moins bien sûr que les Bi soient triviaux et que leur 'expansion' ne pose vraiment pas de problème. Le danger est bien-sûr s'il y a 'expansion' des Bi d'oublier une mise a jour en cas de changement les concernant

Le but de ce nommage est de stéréotypé la relation utilisateur – utilisation en «primary» (erreur de formalisme de ma part).

vous voulez dire que l'acteur est un acteur principal ?
cela me parait bizarre de stéréotyper l'association et non l'acteur

de plus comme l'acteur est seul la question ne se pose pas. Il y a aussi une règle non officielle mais très pratique qui dit que les acteurs placés à gauche des UCs sont les acteurs principaux et que les acteurs placés à droite des UCs sont des acteurs secondaires

[quanta]

oui

si c'est optionel (ie non obligatoire) il faut retourner la dépendance et la stéréotypée extend


il faut faire celui de A mais sans y décrire ce qui est fait dans B1 et B2, ie B1 et B2 sont des boites noires, à moins bien sûr que les Bi soient triviaux et que leur 'expansion' ne pose vraiment pas de problème. Le danger est bien-sûr s'il y a 'expansion' des Bi d'oublier une mise a jour en cas de changement les concernant



vous voulez dire que l'acteur est un acteur principal ?
cela me parait bizarre de stéréotyper l'association et non l'acteur

de plus comme l'acteur est seul la question ne se pose pas. Il y a aussi une règle non officielle mais très pratique qui dit que les acteurs placés à gauche des UCs sont les acteurs principaux et que les acteurs placés à droite des UCs sont des acteurs secondaires

Merci beaucoup pour vos indications, j'en est tenu compte dans ma nouvelle version que je vous présente ici.

Je mesure a quel point cette phase et longue mais également nécessaire (pour bien comprendre les besoins utilisateurs mais également la logique métier qu'ils sous-entendent.

Je serait honoré d'avoir vos retour sur cette version (si c'est à jeter xD, les points a améliorer), ce cas "simple" est important pour moi car il me permettra d’adopter une méthode qui me sera fort utile pour la suite du projet.

Merci d'avance.
http://www.developpez.net/forums/att...1&d=1311093722

[bruno_pages]

Bonjour,

finalement on ne c'est pas compris, vous deviez découper vos 2 UCs en plusieurs UCs, pas les rassembler en un unique

Vous devez avoir un UC pour chaque interaction de votre acteur avec le système, avec les pré & post requis adéquats

[quanta]

Bonjour,

finalement on ne c'est pas compris, vous deviez découper vos 2 UCs en plusieurs UCs, pas les rassembler en un unique

Vous devez avoir un UC pour chaque interaction de votre acteur avec le système, avec les pré & post requis adéquats

Bonjour,

Il ne s'agit pas de cela mais simplement après un nouvelle entretient avec l'assistant qualité il s’avère que cette personne n'ouvre pas de fiche de suivi qualité (cas d'utilisation de la première version du document), mais que cette fiche et ouverte suite à l'action de la commercial (qui lorsqu'elle crée un nouveau bon de commande déclenche automatique la création de la fiche de suivi qualité). Donc au final l'assistant qualité n'a aucune action sur la création de fiche de suivi.

C'est plus cohérent avec cette explication ?

Merci d'avance.

[quanta]

oui
il faut faire celui de A mais sans y décrire ce qui est fait dans B1 ('expansion' ) et B2 ('expansion').

Bonjour,
La description de B1, de B2 je le fais dans le scénario nominal ou on considéré que lorsque l'extension est parcouru c'est un scénario alternatif ? (donc que le scénario nominal ne passe pas par le scénario alternatif ?).

Merci d'avance.

[quanta]

Le document : http://fcojean.11vm-serv.net/fichier...cification.pdf peut il être considérer comme une référence ?

[bruno_pages]

Bonjour,

C'est plus cohérent avec cette explication ?

difficile d'être sure sans voir la nouvelle version

ce que je peux vous (re)dire c'est que dans l'ancienne version l'UC était au moins 2 UCs, un de sélection de fiche (étapes 1 a 4) et un autre de validation de la conformité du CQ associé (autres étapes)

si vous regardez http://fcojean.11vm-serv.net/fichier...cification.pdf vous ne voyez pas dans un UC une séquence d'actions faites alternativement pas l'acteur er le système comme c'était le cas pour vous mais une action (ou un groupe d'actions) faite par l'acteur puis une action faite par le système (le cas de la confirmation de la suppression est un épiphénomène)

La description de B1, de B2 je le fais dans le scénario nominal ou on considéré que lorsque l'extension est parcouru c'est un scénario alternatif ? (donc que le scénario nominal ne passe pas par le scénario alternatif ?).

rien compris, pourquoi parlez vous de scénario alternatif ? la précédente fois il s'agissait de dépendance include, pas d'extension

Le document : http://fcojean.11vm-serv.net/fichier...cification.pdf peut il être considérer comme une référence ?

si la question est de savoir s'il est correct la réponse est oui, même si je n'ai pas tout lu en détail

cependant je n'aime pas les messages 2) et 6) envoyés à l'acteur en haut de la page 6, le système ne peut envoyer un message à l'acteur qui n'est pas un programme, il aurait été préférable d'avoir des messages réflexif, par exemple 2) est un message réflexif indiquant l'affichage de la confirmation, puis (peut être) l'acteur fait une confirmation/infirmation. On comprends que 2) et 6) sont a destination de l'acteur, mais ainsi c'est abusif.

en tout cas dans le même diagramme on y voit le combined fragment alt dont je vous avais parlé

[quanta]

Bonsoir,

rien compris, pourquoi parlez vous de scénario alternatif ? la précédente fois il s'agissait de dépendance include, pas d'extension

Je suis désolé j’ai du mal comprendre le passage :

il faut faire celui de A mais sans y décrire ce qui est fait dans B1 et B2, ie B1 et B2 sont des boites noires, à moins bien sûr que les Bi soient triviaux et que leur 'expansion' ne pose vraiment pas de problème. Le danger est bien-sûr s'il y a 'expansion' des Bi d'oublier une mise a jour en cas de changement les concernant

Au quel j’ai répondu :

La description de B1, de B2 je le fais dans le scénario nominal ou on considéré que lorsque l'extension est parcouru c'est un scénario alternatif ? (donc que le scénario nominal ne passe pas par le scénario alternatif ?).

Je pense que j’ai mal compris le «leur 'expansion' » : j’ai associé à ce terme la relation <<Extend>> (de ce que j’ai compris un UC A extend B signifie que A peut être occasionnellement appelé lors de l’exécution de B -si une condition spécifique se produit par exemple -).

Merci pour vos conseil je pense avoir compris le « une action (ou un groupe d'actions) faite par l'acteur puis une action faite par le système ».