1) comment exprimer le fait que 2 objets doivent être de type différent ?
pour le moment, sachant qu'il y a une relation 1 à 1..2 de Foo à Bar, Bar étant une classe abstraite, possédant 2 classes d'implémentation Baz1 et Baz2, je veux exprimer le fait que si cette cardinalité est de 2, les deux objets ne doivent pas être de meme type
 
 je fais
 

 
2) est ce qu'il vaut mieux rajouter un lien de navigation supplémentaire ou une contrainte OCL ?
 
j'ai Foo <-> Bar <-> Baz, je veux exprimer que pour un foo, il n'y a par navigation, qu'un seul baz associé.
 
pour le moment j'ai fait

ok, y a personne qui connaît OCL ici

Kad c'est un pro de ça normalement.
Mais le modèle me parraît hautement suspect.

non, il l'est pas. Pour le 1, imagine, tu peux avoir une  collection d'objets sous-type de Bar (genre baz{i}), seulement la contrainte sur cette collection, c'est que deux instances ne soit pas de même types ( typeof(c->at(i))!=typeof(c->at(j)), pour tout i,j)
 
seulement typeof il existe pas en OCL ...

Non, il existe pas c'est vrai.  
 
L'expression que tu présentes dans ton premier post semble être correcte pour exprimer cela sinon.

bah je m'en sers, ça va ma collection est petite. mais c'est pas très souple quand même
sinon j'aime bien comme petit langage

C'est quoi tes multiplicités sur tes associations ?
 
La tu exprimes avec ton invariant, que l'ensemble formé de tous les Baz en relation avec tous les Bar en relation avec l'objet courant n'a qu'un seul élément.

C'est sur que c'est pas très élégant de le définir comme ca, mais bon, je vois pas trop sinon
 
Et c'est clair, c'est bien pratique l'OCL si tu veux être rigoureux  

oh là c'est compliqué
 
à un FOO on associe 1..2 BAR
 
à un BAR on associe 1 seul BAZ
il y a une classe d'association SPAM sur le lien BAR<->BAZ
 
le truc c'est que étant donné un FOO, il ne doit y avoir qu'une relation BAR<-(SPAM)->BAZ
 
donc en fait, pour le moment, je dis que
context Foo inv;
self.bar.spam->size() = 1
 
scompliqué  

Tiens c'est super original comme réponse.

c'est toi qui fait chier. je pose une question et toi direct "c'est mal foutu" alors que j'ai absolument rien dit

J'ai peut etre raté un truc, mais je trouve qu'il y a un truc qui cloche
 
D'après tes multiplicités, et en naviguant dans le sens que l'on a, il ne peut y avoir par principe qu'un seul Baz et qu'un seul Spam associé à chaque Bar.
 
Donc écrire dans le contexte de Foo que self.bar.spam->size() = 1, ca revient à écrire self.bar -> size () = 1 donc que ta multiplicité de 1..2 entre Foo et Bar du coté de Bar est en fait 1.
 
Voila ce que j'en ai compris en tout cas

non. je prends le cas concret.
 
j'ai un Article. sur cet Article il peut y avoir 1..2 Annonces
« à un FOO on associe 1..2 BAR »
 
une Personne peut établir un contrat sur un Article, via une annonce. Mais il ne peut y avoir qu'un seul contrat par Article, même si plusieurs annonces existent pour cet Article
« BAR<-(SPAM)->BAZ »
 
tu comprends le truc ?

Je crois
 
Mais j'ai pas l'impression que ca corresponde à ce que tu décrivais au-dessus
 
Je tente de détailler ca :
 

Avec Annonce étant en plus une classe d'association de l'association entre Article et Personne.
 
Si je me gourre, corrige moi

oui mais non.
 
La Personne est associé à une Annonce, ça peut pas changer ça.
 
à la base, tu as un article et des annonces. un gus se pointe, il engage un contrat relatif à une annonce.
 
ma question initiale, c'est est-ce que en plus du
 
Personne <-(Contrat) -> Annonce <-> Article
 
je rajoute un lien Personne<->Article, tout en spécifiant que c'est le même article quelque soit la navigation.
 
ou alors ma contrainte comme actuellement

J'essaye de comprendre ton schéma avant de répondre à ta question
 
Si je complète, ca donne ca :
 

 
C'est bon la ?

oui, c'est ça. ma question c'est esque que rajoute le personne-article ou est ce que ma contrainte va ?

Je pense que ton diagramme pourrait déjà être amélioré. Ta classe Contrat semble être quand même plus importante que seulement pour rajouter des infos sur l'association entre Personne et Annonce.  
 
Personnelement, je rajouterais donc une association entre Article et Contrat.
 
Et pour l'association entre Personne et Annonce, je mettrais pas de classes d'association. A la limite, je mettrais plutot une association entre Personne et Contrat en mettant Annonce en classe d'Association de cette association.

Le problème c'est qu'un contrat est intimement lié à une annonce. et que les annonces préexistent au contrats, et que des annonces n'entrainent pas forcément un contrat

Il est aussi lié à un Article non ?
Et ça, tu le fais pas apparaître explicitement sur ton diagramme.

ben un contrat est associé à un article oui, mais on a le lien par navigation sans problème (la navigation n'est possible que dans un sens)

Oui, tu as le lien par navigation, mais je pense que de le faire ressortir explicitement serait une bonne chose.
 
Le but d'une classe d'association est vraiment de préciser des infos locales à l'association. Déduire des relations entre cette classes en suivant les associations de l'une des deux classes de l'association, c'est pas ce qu'il y a de plus élégant je trouve
 
Mais bon, si on reste sur ton diagramme, c'est quoi exactement la contrainte que tu veux écrire ?

ben que par article, il peut y avoir qu'une seule relation Personne-(Contrat)-Annonce

Tu peux faire un truc du genre:
 
context Article inv:
personne.contrat -> size() = 1
 
Mais bon, en même temps, en rajoutant un lien Article <--> Contrat avec une cardinalité de 1 je continue à trouver ça plus propre  
 
En plus sur ton diagramme, t'oblige qu'un contrat soit systématiquement associé entre une Personne et une Article. On peut pas avoir de lien entre Personne et Article sans contrat. C'est ça que tu veux ?

oui. merci de ton aide.

Pas de quoi