Discussion :

[GauthierVDD]

Bonjour,
J'ai "terminé" un diagramme d'activité et je me pose 2 questions sur des éventuelles problèmes que j'ai résolues à ma manière (qui n'est pas forcément la bonne^^).

Je vous met l'image de mon diagramme d'activité ci-dessous pour vous faciliter la compréhension.

1^ère question : Le Use Case qui est représenté par ce diagramme étends (relation "extend") 2 autres Use Case. La première idée qui vient donc en tête est de créer deux initial nodes seulement ceci n'est pas autorisé. J'ai résolu le problème en insérant après un unique initial node un point de décision allant dans une ou l'autre direction suivant le Use Case effectué avant. Pensez-vous que cela est correct ? Avez vous une autre solution pour moi ?

2^ème question : Dans ce diagramme d'activité, je n'ai indiqué que les actions qui concernent les intéractions entre le système et l'utilisateur et les conditions. Dois-je aussi indiquer les actions qui sont effectuées avant une intéraction ou condition ? Un exemple est l'activité "Imprime le bon de réservation" : est-ce qu'avant on doit indiquer que le système recherche les informations dans la base de données et/ou fait des calculs pour fournir de l'information pour ensuite créer le bon de réservation et l'imprimer ?

Voilà. Si jamais d'autres choses vous choquent, interpellent, n'hésitez pas à m'en faire part. Merci d'avance pour vos réponses ;-).

[bruno_pages]

pourrais-tu montrer les UCs ? je pense qu'il y a déjà des problèmes à leur niveaux

si l'activité correspond à un UC il y a un problème car celle-ci commence par se demandé d'où on vient, ce qui n'a pas de sens

il y a des actions qui correspondent à des actions utilisateur et non des actions du système ("clique sur ..." "sélectionne la réservation" ... ), cela n'est pas correct

[GauthierVDD]

1. Voici mes Use Case :


2. D'accord. Ces actions utilisateur doivent être mis en "déclencheur" des actions système c'est ça non ?

[bruno_pages]

c'est bien ce que je craignais, il y a déjà un énorme problème au niveau des UCs

vous deviez lire vos cours ou des tutoriels comme par exemple http://ego.developpez.com/uml/tutoriel/casUtilisation/, nommez correctement vos UCs

"accès ..." / "retour" n'ont aucune chance d'être des UCs, ils correspondent à rien, cela explique vos problèmes au niveau activité

oubliez vos activités pour le moment et recommencez au niveau UCs sinon vous n'allez pas y arriver

[GauthierVDD]

D'accord j'ai compris ce qui n'allait pas et il y a du boulot... Merci ;-)

Je compte supprimer "Retour aux fonctionnalités" et remplacer "Accès aux fonctionnalités disponibles pour l'utilisateur" par "Identification" et "Création d'un compte client". Tous les autres Use Case seraient liés par un include avec "Identification" (d'autres modifications sont prévues ne vous inquiétez pas...). Pensez-vous que "Identification" peut être Use Case dans ce cas-là afin d'éviter de multiples répétitions ?

Autre question : J'aimerais indiquer que les différents Use Case peuvent être atteints soit par une interface web soit par l’ordinateur de l'entreprise. Que me conseillez vous de faire ? (sachant que cela ne change pas l'identification ni d'autres Use Case)

[bruno_pages]

il y a du boulot... Merci ;-)

là on est 100% d'accord

Tous les autres Use Case seraient liés par un include avec "Identification"

oh non, car cela voudrait dire que l'utilisateur doit s'identifier avant chaque action et non une fois pour toute jusqu'a la déconnexion

a noté que la relation avec l'UC ientification ne peut pas non plus être un extend, car l'identification doit être faite AVANT, bref l'UC "identification" est simplement un pré requis des autres, et donné comme tel non pas dans le diagramme mais dans la description textuelles des autres UC

Pensez-vous que "Identification" peut être Use Case dans ce cas-là afin d'éviter de multiples répétitions ?

c'est bien un UC, mais il n'est donc ni inclue ni étendu

J'aimerais indiquer que les différents Use Case peuvent être atteints soit par une interface web soit par l’ordinateur de l'entreprise.

c'est l'autre gros problème de vos UCs actuels, cela n'a pas de sens, un UC ne doit pas commencer par se demander qui le déclenche (utilisateur externe ou interne), si le déroulement d'un UC dépend de l'acteur c'est que cet UC doit être découpé en plusieurs

je ne suis pas certain que vous ayez bien compris qu'un acteur correspondait à un rôle (et non une personne physique), relisez vos cours/tutoriels