Discussion :

[Pero]

Bonjour à tous,

Comment modéliser (diagramme de classe) le fait qu'un patient doive se rendre chez un médecin 1x/an si il a moins de 40 ans ou 2x/an si il a plus de 40 ans (ou ... autres cas possibles), et qu'il reçoive lors de chaque visite une attestation signalant si il est en bonne ou mauvaise santé :

Merci d'avance.

[Hephaistos007]

Tu ne peut pas modéliser de telles informations sur un diagramme de classe (par définition). Un diagramme d'activité serait je pense plus approprié.

PS : si UML propose plusieurs diagramme, ce n'est pas pour rien

Bonne continuation.

[TheLeadingEdge]

Bonsoir,

1 spécialisation patient (-/+ de 40 ans) n'étant pas vraiment judicieuse, je mettrait 1 stéréotype <<Check>> avec la définition de ta règle sur ta classe... En attendant de trouver mieux.

A +

[Franckintosh]

Diagramme de classe -> représentation de la statique du système.
"Action" = dynamique donc il faut utiliser un diagramme représentant la dynamique du système pour modéliser ton "action conditionnelle".

[TheLeadingEdge]

Bonjour,

Pas d'accord. Ce n'est pas 1 action conditionnelle, c'est la représentation d'1 règle métier qui stipule que si champ age > 40 alors champ visite doit être 2 et si champs age =< 40 alors champs visite = 1. C'est 1 règle d'intégrité de la base de la base de donnée. Pas 1 ttmt.

[Hephaistos007]

Oui on peut le voir aussi comme une règle métier. Dans ce cas moi je propose d'exprimer cette condition avec de l'OCL. Ou même sans rentrer dans les détails, de mettre visite comme attribut dérivé (c-a-d calculable) noté : /visite : int.

De toute façon il n'y a pas UNE solution. Tout dépend de la somme d'informations que l'on veut proposer.

[TheLeadingEdge]

Re,

En fait je m'aperçoit que j'ai été 1 peu catégorique ds ma réponse. Il n'y a pas assez d'éléments ds la question.
Il faudrait savoir savoir si le champs nb de visites est mis à jour à la suite d'1 visite, ou si c'est la valeur du champ nbre de visites qui déclenche l'action visite médicale.
De tte façons on peut bien représenter la contrainte sur la valeur ds le diagramme des classes (et c'est ce que je voulais dire ds mes posts) mais elle doit effectivement avoir 1 pendant ds 1 diagramme dynamique (séquence ou activité).
Comme tu le dis justement il n'y a pas UNE solution, le but étant d'arriver à en modéliser 1 que tout le monde comprend de la même manière et qui corresponde à la réalité de ce qu'on veut faire.

[Pero]

Je concède que ma question n'est peut être pas des plus claires.

Ce que j'aimerais savoir, ce sont les relations que je pourrais avoir entre les entités Patient, Médecin et Attestation, en sachant que la délivrance de l'attestation dépend du fait que le patient se soit rendu chez le médecin ou non.

Pour ce qui est du 40 ans ou moins, je vois une contrainte OCL comme proposé par Hephaistos007.

Merci.

[ego]

Moi, je suis de l'avis de TheLeadingEdge. C'est une règle métier.

Le problème n'est pas vraiment comment la représenter en UML mais, comme c'est une règle métier, que vas-tu mettre en ouvre au sein de ton application pour assurer que cette règle sera vérifiée.
Probablement que tu vas mettre en oeuvre un procesus de vérification tous les ans, voir mettre un processus d'alerte qui, vers la fin de l'année listera les patients qui risquent de ne pas respecter cette règle.
D'autre part, si d'un point de vue métier on ne t'a pas dit quoi faire vraiment avec cette règle, tu ne sauras pas quoi mettre en oeuvre dans ton appli.

Bref, une fois que tu as défini la classe ou le package qui va prendre en charge cette règle métier, tu n'as plus qu'à la référencer au niveau de la classe ou du package. Là, tout dépend de l'outillage dont tu disposes. Pour faire simple tu peux mettre la référence de la règle dans la "documentation" de la classe ou de package.

Pour ce qui est de l'expression même de la règle, ceci est du ressort de la gestion des exigences, non de la modélisation. Une expression de cette règle dans un "dossier des exigences" (SRS dans le jargon du RUP) est une bonne solution.

[Hephaistos007]

Dans l'absolue, tu peux même décrire ta contrainte en langage naturel dans une note de commentaire associée à ta classe !

Ta question soulève en fait un problème de fond. Comptes-tu utiliser ton diagramme de classe de manière :
1) contemplative
2) générative

La solution n°2 consiste à procéder à un traitement informatisé du diagramme (génération de code, vérification de contraintes, ...). Il est bien évident que dans cette optique, une note de commentaire est totalement inexploitable alors qu'une expression OCL est tout à fait adaptée.


Si tu réponds à cette question, tu as presque la solution.