Discussion :

[Rahustro]

Bonjour

Est ce que quelqu'un pourrait m'expliquer la différence qu'il existe entre une relation de type "extend" entre deux use case et une relation de nature generalisation.
Par exemple je peux avoir un use case "se détendre" et plusieurs extension de ce dernier qui peuvent être "aller au cinema" "ecouter de la musique" ou "faire du yoga"
Mais je peux aussi dire que le use case "se detendre" généralise ces trois possibilités.
Je voudrais donc savoir existe il une différence fondamentale ?
Quel sont les impactes de ces deux modélisation sur les autre diagrames d'interactions (diag de sequence et de collaboration) ?
et quels sont les impactes que ces deux modélisations engendrent sur l'implémentation, donc au niveau du code ?

merci beaucoup de vos explications

[guillaume goarnisson]

Pour moi l'exemple que tu donnes est plutot un cas de generalisation avec le CU "Se detendre" (encore que : Faire du yoga est-ce vraiment se detendre, plutot se ressourcer, puisser energie interieure.... mais bon là n'est pas le debat).

Oui dans ton cas il n'y a pas un scénario pour le CU "se detendre" qui est étendu pour les scénarios des autres CUs, nous avons plutot chacun des 3 CUs est un type de CU "se detendre" et donc un spécialisation/généralisation (symbolisme de l'heritage entre les CUs).

Guillaume

[YAMKI]

Je suis d'accord avec Guillaume.

L'extend correspond plutot a une option possible de ton use case si je ne dit pas de bétise. Par exemple si on garde ton use case "Se détendre" on pourrait avoir un use case "Dormir" en extend par rapport au premier use case. En effet, lorsqu'on se détend il est possible qu'on s'endorme mais ce n'est pas obligé.

J'espère avoir pu t'aider.

[Rahustro]

Merci de vos réponses

Donc si je comprends bien c'est une généralisation parcequ'il n'y a pas vraiment de scenarios pour "se detendre". Si je suis le raisonnement de YAMKI j'ai aussi plusieurs options "aller au cinema" ou "ecouter de la musique ce qui selon les dire de Yamki revient a une extension !!!

Si je prends un autre exemple le paiement des courses à un super marché
j'ai plusieurs options "liquid" "cheque" et "carte bancaire"
je n'ai pas de scenarios complet pour "paiement des courses" mais j'en ai pour les trois options donc selon guillaume c'est une généralisation et selon yamki une spécialisation !!!

donc aucune différence!!!! alors pourquoi la généralisation existent ???

et pour les autre questions concernant l'impacte sur les autre digrames d'interaction et l'implementation avez vous des reponse ou pistes a creuser ?

merci d'avance

[YAMKI]

J'ai pas du bien me faire comprendre car pour ton exemple de paiement je confirme c'est bien une généralisation.

Si on revient a ta détente.

Si tu as un UC "Se détendre" qui à pour scénario s'allonger, fermer les yeux et ne penser à rien. Alors tu pourrais tout a fait avoir un cas d'utilisation extend Dormir qui aurait pour scénario s'assoupir, réver et se réveiller.

en fonction de ton système ce 'extend' pourrait tres bien devenir un 'include' si tu es sur que quel que soit les circonstance au cours de ton scénario "se détendre" tu es obligé de dormir.




Pour la généralisation, tu l'utilise pour préciser qu'un certain nombre de cas d'utilisation se ressemble tout en étant différent. Exactement comme l'héritage en programmation.



Ai je été plus claire ou pas?

[Ziploppe]

Bonjour,

Si tu utilises une extension entre UseCase1 et UseCase2 :

UseCase1 <----- << extend >> ------- UseCase2
Condition.

Cela veut dire que ton cas d'utilisation 2 (UseCase2) ajoute son comportement au cas d'utilisation 1 (UseCase1). On utilise cette notion pour modéliser des variations de comportements. En effet il est possible de définir une condition indiquant quand le comportement UseCase2 est déclenché dans le scénario UseCase1.

Exemple de l'extension :
UseCase1 = "Payer par carte bancaire"
UseCase2 = " Vérification du compte"
Condition = " Si le montant > 500 €"
Dans cet exemple le scénario de paiement par carte bancaire se voit ajouté d'une vérification du compte quand le montant de l'achat dépasse 1000 €. On ne peut pas parler de généralisation (ou spécialisation, enfin bref d'héritage) entre UseCase1 et UseCase2 car un paiement et une vérification de compte n'ont rien en commun. Une vérification de compte n'est pas "une sorte de" paiement.

Exemple de la généralisation :

UseCase1 = "Payer ses courses"
UseCase2 = "Payer par carte bancaire"
UseCase3 = "Payer par chèque"
UseCase4 = "Payer en liquide"

UseCase1 <|--------------
/\ /\ |
| | |
| | |
UseCase2 UseCase3 UseCase4
L'exemple est très simple mais la notion d'héritage est à peu près la même qu'en programmation (à part que l'on travaille sur des scénarios et non sur des types purs).
J'espère avoir été clair en ayant expliqué l'extension pour montrer la différence avec la généralisation.

[Rahustro]

Salut
C'est effectivement très claire et ca confirme ce que j'ai lu sur le sujet. Cependant il reste un petit point noir. Dans le cas des paiements,
rien ne m'empeche de dire que les trois modes de paiement sont des variations du cas "paiement des courses". Je m'explique

je peux bien dire :
si client me donne sa CB ---> Paiement pas carte
si client de donne du liquide ---->paiement en liquide.

donc c'est bien des conditions qui suivant le cas déclenchera un use case particulier...donc une relation de type <<extend>>

J'ai aussi lu sur http://ego.developpez.com/uml/tutori...ation-v1.3.pdf que je cite

Cette relation est de mon point de vue la relation la plus discutable du point de vue de son utilité pratique.

et que

les relation de type generalisation/specialisation ajoutaient un niveau de complexite. .... les consultants font remarque qu'elle induit des complications et des pertes de temps

(UML et les design patterns 2ieme edition page 425)
Mais aucun des documents que j'ai lu n'expliquent pourquoi

[ego]

Regardes la longueur de ton thread sur le sujet et tu comprendras que ces notions font perdre du temps !!!

Il ne s'agit pas de "s'amuser" avec faire avec les UC comme en objet, c'est à dire essayer de faire de l'héritage, include, extend et autre.
Le UC doit avant tout représenter une unité d'intention complète de l'acteur vis-à-vis du système. Il faut donc se demander ce que les acteurs font faire du point de vue de leur métier avec ton application.
Ensuite, et si cela te permet d'expliquer qu'un UC peut être appelé depuis un autre tu utilises l'extend. Si tu veux utiliser l'héritage pour dire qu'un UC est conceptuellement le père d'autres UC libre à toi mais cela n'apporte pas grand chose au chmilblik. Le UC est avant tout fait pour recueillir les exigences client. Tu auras tout le loisir d'exprimer tes talents de modélisateur quand tu passeras à la modélisation objet.

[Ziploppe]

-->
Laisser des relations d'héritages précisent le UseCase héritier. Cela peut être utile au tout début pour clarifier la sémantique. Par la suite ces clarifications deviennent inutiles puisque le sujet devient de plus en plus clair et précis.

Exemple :

UseCaseA : "lire un texte"
UseCaseB : "Aide au jugement"

UseCase1 : "Prononcer un jugement"

Si UseCase1 dérive de UseCaseA nous sommes dans un cas où il nous faut lire un jugement. Ce jugement a donc déjà été réalisé. Il nous reste à le prononcer.
Il y a notion d'héritage car la prononciation d'un jugement est une sorte de lecture de texte (lecture de la sentence).

Si UseCase1 dérive de UseCaseB prononcer un jugement ne signifie plus du tout une lecture mais une élaboration d'un jugement. Le jugement n'est pas encore élaboré.
Il y a notion d'héritage car l'aide au jugement est une sorte de prononciation, d'élaboration d'un jugement.

Ici selon l'héritage nous avons un même cas d'utilisation (UseCase1) réalisant deux actions tout à fait différentes (significations différentes). D'où l'utilité de l'héritage parfois en début d'élaboration des UseCases.

J'ai essayé de trouver un exemple assez parlant même si l'héritage entre UseCase1 et UseCaseB est très discutable étant donné que le UseCaseB n'est pas très concrêt... Peut pas faire mieux.

-->
Comme un UseCase est couvert ensuite par une collaboration entre objets montrer une relation d'héritage entre deux UseCase peut être utile pour factoriser les messages utilisés dans les collaborations. Cependant faire ainsi montre que l'on ne s'attache plus à dire ce que doit faire l'application mais plutôt que l'on s'attache plus sur la question "Comment faire ? " alors que l'on a pas ancore répondu au "Quoi faire ?" !!!

[Mosley]

Bonjour à tous,
Je me trouve face à un dilemme, je ne comprends pas bien la différence entre un <<extend>> et une généralisation. Je travaille sur la gestion des stocks. J'ai les use case suivant:
use1: effectuer un mouvement
use2 :entrée
use3: sortie
Question : Généralisation ou extension?

use1: consulter l'état du stock
use2 :consulter bas de stock
Même question.....

SVP toute aide sera la bien venue!
Merci d'avance

[tonton16]

Bonjour,

Il faut te poser la question :
Est-ce qu'effectuer une entrée ou une sortie est la même chose qu'effectuer un mouvement ?
Si une entrée "est un" mouvement et une sortie "est un" mouvement alors c'est un héritage (généralisation/spécialisation).

Si par contre, effectuer une entrée ou une sortie n'est qu'une option d'effectuer un mouvement dans son scénario, c'est-à-dire que lorsque tu effectue un mouvement, il peut t'arriver de faire une sortie ou une entrée et ce n'est pas obligatoire, alors c'est une relation d'extension.

A toi de voir.

[kamylex]

bonsoir à tout le monde,j'aimerais qu'on m'explique clairement la difference entre la relation "include" "extend" si vous pouvez me donner un exemple a l'appui merci d'avance

[bruno_pages]

bonjour,

pourquoi ne pas simplement lire tutoriel cas d'utilisation ?