Discussion :

[PINGOUIN_GEANT]

Salut à toutes et tous,

J'aimerais avoir votre avis sur la modélisation de la logique avec des states diagrams. Est-ce que pour vous les concepts sont suffisants ? Ou avez-vous besoin d'autres langages (je pense à OCL) ?

J'ai l'impression qu'on est vite limité par la quantité d'états à créer. Si on doit avoir 5 conditions pour qu'une opérations se réalise et qu'on explore dans quels états on se retrouve suivant les valeurs de ces conditions, cela devient ingérable.

Merci pour vos réponses.

[ego]

Si pour toi "logique" veut dire algorithme, on n'utilise pas les "state diagram" pour cela. On utilise des diagrammes d'activités ou des diagrammes de séquence.
Les "state diagram" servent à modéliser les états et transitions possible au niveau d'un objet. Dans ce diagramme, il n'est pas dit pourquoi l'objet reçoit un évènement.

[Hephaistos007]

Je ne comprends pas le sens de ta question.

[PINGOUIN_GEANT]

Merci pour les réponses.

Je suis en train de réfléchir en même temps donc cela paraîtra confus.
On pourrait faire ainsi :
Un état d'un système est caractérisé par un ensemble d'attributs prenant certaines valeurs.
Passer d'un état un autre veut donc dire que les valeurs des attributs changent.
Par cela, on pourrait parler ainsi de logique avec des règles de changement des valeurs.

Mais maintenant, je pense que, au moins au niveau système, un état est là pour structurer son comportement, et, à un état on associe un ensemble d'opérations.

C'est vrai que par logique, je ne pensais pas aux booléens, mais plutôt à des conditions, des expression à évaluer (sont-elles vraies ou pas ?) et les conséquences qui en découlent. Cela ressemble un peu à ce qu'on peut faire avec des state diagrams, mais j'ai l'impression qu'ils restent limités.

J'espère que j'arrive plus à préciser ma pensée.

[kossistus]

Humm!!!
PINGOUIN_GEANT a dit ....mais j'ai l'impression qu'ils restent limités.

Tu te trompes ou alors je n'ai rien compris à ce que tu dis.
Il faut que tu lises absolument la vrai définition du pattern state au risque de lui faire faire ce qu'il n'est pas censé faire.

[ego]

Il faut distinguer "je suis dans l'état X" avec "Parce que mes attributs 1, 2, 3 et 4 sont passés aux valeurs V1, V2, v3 et V4 donc je suis dans l'état X".
En fait, dans le diagramme d'états-transitions tu vas lister les états possibles de ton objet, indépendamment du fait que cet état est représenté ou non par une série d'attributs. Puis tu ajoutes les transitions.
Ensuite, tu te poses la question : Comment implémenter cette machine à états. Là le pattern State tel que décrit dans le GoF peut être utile. La forme proposée est en effet utile si le comportement de ton objet est vraiment fonction de l'état dans lequel il se trouve. Si tu as peu ou beaucoup d'états mais que le comportement ne dépend pas beaucoup des états, une implémentation sous la forme d'enumération est suffisante.
En fait, il est recommandé de gérer ton état soit via une énumération soit avec le pattern State et surtout de ne pas le géré en utilisant des combinaisons de multiples attributs.