bonjour à tous
 
j'ai un problème d'analyse UML sur la gestion d'un hotel au niveau de la reservation occupoation de chambre sur une période (séjour)
 
voila actuellement l'analyse :
 

 
j'aimerai amélioré ma solution car ici on exclu pas le faite qu'un séjour est soit occupé soit reservé    
 
donc la question est : quel pattern utiliser pour améliorer l'analyse schant qu'un séjour peut etre "réservé" ou "occupé" mais pas les deux à la fois.  
 
j'ai pensé au pattern STATE : un sejour a un etat abstrait, deux etats concrets ("reservé" et "occupé" herite de cette etat abstrait  
mais j'ai un doute.
 
merci d'avance de vos réponses

sejour est-il un état abstrait ?  
Non, il est un objet concept de ton application.
 
(la réponse n'a pas de classe association)

(avant de t'occuper de ton pattern, tu as un coup de ménage à faire dans ton modèle)

 
pour le moment mon analyse n'est pas fini ici je montre qu'un bout    
 
le "séjour" n'est pas abstrait
 
le but est de changer l'etat de mon sejour : je veux qu'un séjour à l'état reservé puisse devenir un séjour à l'état occupé (si le client est dans la chambre)
 
j'espère être claire  

voila ma solution avec design pattern STATE :
 

 
quand pensez vous ?  

On ne transforme pas le type d'un objet comme ça à la volée, s'il te plait.
 
Le pattern state doit plus ressembler à ça dans la pratique :  
 

 
 
seulement aux heures de bureau

(ma relation all states est cacateuse, mais j'ai pas mon GOF sur moi. Il fait des singletons des états, mais j'aime pas Par contre, la relation doit être de classes)

je te remerci  sincèrement de ta réponse si rapide (surtout vu l'heure tardive !!!)    
 
en fait, je m'inspire de ce diagramme qui utilise le desing pattern STATE:  

 
disponible ici : http://smeric.developpez.com/java/uml/etat/
 
donc mon exemple et cette exemple ne respect pas tes consignes  

(j'ai plus les yeux en face des trous, j'avais oublié la délégation de fonctionnalité suivant l'état courant)

donc ma solution est correcte    
 
(je pense que oui mais j'ai peux d'expérience dans le domaine)

je rajoute cette information (trouvé sur le même lien) pour la gestion de changement d'etat :
 
"Ensuite, nous observons les trajets possibles d'un état à l'autre à l'aide des transitions. Enfin, les triggers et les gardes nous permettent de savoir dans quelles conditions nous passons d'un état à l'autre."
 
donc ma solution STATE me semble bonne

up

oui, c'est un peu gros par rapport à tes besoins, mais pourquoi pas.
par contre, repense un peu à la définition du séjour, il y a moyen de le faire de manière plus élégante qu'avec une classe-association, qui est quadn même un truc à éviter...

IRL, j'utiliserais un attribut de type énuméré pour définir l'état courant, mais ici, je soupsonne un exercice, donc un petit pattern, ça toujours serieux et bon elève