Discussion :

[Yveke]

Hello,

J'ai une petite question concernant la relation d'include ! Dans la F.A.Q. UML de ce site on trouve l'exemple suivant : "Pour un système de retrait de monnaie. Le use case "retirer_une_somme" va faire appel systématiquement au use case "verifier_solvabilité_client" afin de vérifier que le client dispose effectivement de la somme d'argent demandée." Maintenant si on a un use case qui demande l'accomplissement d'un autre use case pour pouvoir être satisfait mais qu'ils ont une temporalité différente a t'on également un lien d'include ? Par exemple on a un cas d'utilisation "consulter un rapport de production" et un autre "encoder les données de production", le premier nécessite le bon accomplissement du second, mais ce n'est pas à dans le premier que le second est appelé ! alors si quelqu'un a suivi peut il me dire s'il y a un lien d'include ?
Merci d'avance.

Yves

[ego]

Un UC est une unité d'intention complète de la part de l'acteur vis-àvis du système. Ce n'est pas une décomposition procédurale de ce que sait faire le système.
Ton exemple d'encodage des données n'est donc pas bon car ce n'est pas un UC. L'utilisateur du système ne se connecte pas le matin à ton application pour encoder les données de production (sauf si ton application est une application spécifiquement dédiée à l'encodage des données). Ce n'est donc pas une unité d'intention complète !!

Mon conseil : NE PAS UTILISER LES RELATIONS ENTRE UC

Cela conduit malheureusement à un découpage procédural du système quand on débute avec les UC ou quand on ne maitrise pas encore le niveau sémantique que doit avoir un UC.

cf. http://ego.developpez.com/uml/tutoriel/casUtilisation/

[Yveke]

Ok mais en fait un acteur, le contrôleur qui se connecte bien de façon ponctuelle (chaque début de période) pour encoder les données relevées durant la période précédente, cela se rapproche donc d'une unité d'intention complète non ? On a donc un use case "encode données de période" ?
Le rapport de production est construit dynamiquement au départ d'un ensemble de données de la base de données (bon ça c'est une fonction) mais sur demande ponctuelle d'un autre acteur : l'ingénieur de production, on a donc a mon sens un use case "consulter rapport de production" qui est je crois aussi une unité d'intention a part entière.
Je vais lire ton tutoriel de ce pas ego ! Merci pour les conseils et excusez moi si je fais fausse route.

Yves.

[ego]

Qui est ton "contrôleur" ? un utilisateur de ton application ?
Si c'est le cas, ok pour avoir des UC sinon NOK

Pour le consulter rapport de production : ok

[Yveke]

oui le contrôleur est un utilisateur de l'application.
Merci pour ton éclairage Ego ! et finalement y a t'il un lien d'include entre les deux use case (question originelle).
A+

Yves.

[ego]

Non, il n'y a pas de lien d'include.
Le fait que l'exécution d'un usecase X soit nécessaire pour pouvoir réaliser le usecase Y ne s'exprime pas via les liens entre usecases.
Si UCX doit être réaliser pour faire UCY c'est qu'en fait les post-conditions du UCX sont un sous-ensemble des pre-conditions du UCY.
Ce serait dans une modélisation des processus métier que tu verrais que UCX doit être réalisé avant UCY mais pas dans un diagramme de UC.
Quand on en arrive à réaliser une application informatique, on est "censé" avoir fait la modélisation des processus métier avant. Ce n'est bien souvent pas le cas et cela explique que l'on est tenté de "faire" ce travail avec les UC; mais ce n'est pas là que l'on doit décrire cela car cela n'apporte rien pour réaliser l'application (il suffit de bien spécifier les pre et post-conditions)

[Franckintosh]

Le lien d'inclusion signifie que lorsqu'on réalise UCY alors on réalise UCX avec. Si ce n'est pas ce qui doit se produire alors ce n'est donc pas un lien d'inclusion.

[Yveke]

Merci ego et Franckintosh.

Yves