Version imprimable
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.
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.
Je ne comprends pas le sens de ta question.
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.
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.
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.
Salut,
D'autant plus que, l'un dans l'autre, il est plus facile de "calculer" l'état dans lequel se trouve un objet lorsque l'un de ses attributs subit une modification, et de maintenir cet état (sous forme d'un énumération) jusqu'à ce qu'il y ait de nouveau modification d'attribut que de "perdre son temps" à calculer l'état de l'objet à chaque fois, même s'il n'y a pas eu de modification...
Au pire, rien ne t'empêche de créer une méthode renvoyant un booléen pour chaque état et selon la valeur de l'énumération, mais là, il faut voir si cela se justifie
Par exemple, en C++, tu pourrais envisager une classe du genre de
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Merci pour vos réponses.
Les détails d'implémentation, c'est un peu trop low level pour moi. Je me situe à un niveau systémique.
Par contre le pattern state me fait poser quelques questions. Si j'avais un système embarqué, est-ce que je pourrais utiliser des mécanismes "d'héritage" (ou d'autres dépendences) pour représenter des comportements dégradés du système embarqué que j'associerai à un même état. Suivant le comportement (dégradé ou non), ce qui se passerait quand le système l'état serait différent.
Cela aurait le mérite d'être concis dans la construction mais c'est très peu intuitifquad on manipule des objets réels.
En fait, le pattern State me semble tout à fait adapté à ce que tu décris.
Ce que sait faire une classe à un moment donné est représenté par l'instance courante de l'état qu'elle référence. Le pattern State utilise la notion de délégation entre l'objet principal et l'objet "état".
Oui pour l'héritage des états, mais en systémique un prb se présente car l'état du super système est la résultante:
1/ De l'état des sous systèmes
2/ De l'état du réseau d'interaction entre les sous systèmes.
Un héritage à l'envers on dirait.
Déjà, je n'utiliserais pas la notion d'héritage pour représenter le système et ses sous-système...
Un héritage représente, généralement, une liaison "est un(e)" (une voiture est un véhicule).
L'agrégation représente bien mieux le système et ses sous système:
Le système "complet" a une composante (réseau, sous-système, ...) :mouarf:
Ensuite, si l'on considère souvent l'héritage comme le moyen d'étendre les possibilités de la classe fille par rapport à la classe parente, il est tout à fait possible d'envisager l'héritage de manière à restreindre les possibilités de la classe fille par rapport à la classe parente.
Enfin, il y a sûrement des situations qui sont incompatibles entre elles, soit parce qu'elles n'ont aucun sens (avoir la date de naissance d'un client qui n'existe pas), soit parce que un état particulier d'un des sous-système aura déjà empêché un autre sous-système d'arriver à un état incohérent:
Si la connexion réseau est indisponible, tout sous-système qui doit l'utiliser est déjà dans l'impossibilité d'effectuer certaines opérations (d'identification, par exemple)
Il est donc "cohérent" d'envisager que chaque sous-système dispose de sa propre machine à état, et dont il est strictement responsable.
Au dessus de tous ces sous-systèmes, on trouve alors le système principal qui, lui, reçoit les états de chacun des sous-systèmes, et qui en tire les conclusions qui s'imposent pour assurer son propre fonctionnement ;)
N'oublie pas la règle d'or qui est de déléguer le travail :D
Si on regarde un distributeur de billets, c'est au distributeur de savoir qu'il ne peut pas autoriser le retraits si son "réservoir" est vide...
Cela empêchera le serveur qui a connaissance de l'état des comptes des clients d'accepter un retrait... qui n'a jamais été effectué (et donc d'avoir un client sur le compte duquel il manque XXX€ parce qu'il les aurait soi-disant retiré, mais qu'il ne les aurait jamais reçus).
Tu as tout à fait raison vu que je suis parti du pattern state pour décrire l'exemple:D.Citation:
Envoyé par ego
En fait, mon problème intial n'avait rien à voir, mais le pattern state m'a fait penser à un autre problème que j'ai.
La remarque d'Alec6 est tout à fait pertinente pour des systèmes.
En fait le pattern state serait une solution si le contrôleur (dsl connais pas le terme exact Wikipedia parle de context) et l'objet à plusieurs variantes d'états étaient le même.
Un petit exemple:
J'utilise mon autoradio en mode AM et FM. C'est des variantes d'utilisation (écouter la radio avec quelques fonctionnalités) avec comme variantes que la réalisation de cette utilisation diffère d'un cas à l'autre (une fois AM et une fois FM).
Bon, dans ce cas particulier, cela ne change pas beaucoup sur la technologie mais dans d'autres cas cela pourrait.
On peut penser qu'on essaie de décrire les fonctions liées à AM d'un côté et celles liées à FM de l'autre.
Le problème est si on veut analyser fonctionnellement la transition entre FM et AM. Par exemple, on doit s'assurer que le display s'effectue bien etc.
Le pattern state serait intéressant pour visualiser les variantes. Mais ce sont deux ensembles de fonctions qui appartiennent à autoradio et la sélection s'effectue dans auto-radio. Il n'y a plus de "contrôleur" extérieur. Du coup, comment s'adapter ?
Au faite vous avez jeté un oeil à SysML ?
Citation:
Envoyé par PINGOUIN_GEANT
Bonjour,Citation:
Envoyé par PINGOUIN_GEANT
Je pense que c'est la que ce trouve la complexité ingérable : tu considère la machine a états globale.
Si tu divise pour régner : l'autoradio est compose d'un display et d'un récepteur, le récepteur ayant 2 états, alors chacune des machines a états devient plus simple.
Il faut aussi définir la relation entre les 2 (pattern observer ?).
Une bonne référence pour les machines a états : le livre OMT, de James Rumbaugh (on y parle entre autres de sous-états, d'héritage et d'agrégation de machines a états).
Pour mon retour d'expérience : plus il y a d'objets identifiés, (du domaine, techniques), plus leurs machines a états sont simples.
Alex.
Alex,
Je suis d'accord avec ce que tu dis sauf que je conçois par (ensemble de) fonctions et non pas par système.
Quand pour chaque système, on assemblera les deux fonctions venant d'équipes différentes, comment s'y prendre pour que cela se passe bien ?
Au niveau de States machines ? Sequence Diagrams ?...
Que de grandes questions :P
Quelles sont les bonnes pratiques actuelles en modélisation ?
partir des cas d'utilisation du sytème (des acteurs, un seul objet),
les réaliser en mettant en scène chaque sous-système (les même acteurs, un objet par sous-système),
et faire la réalisation (l'implémentation) des sous-système.
Ceci de manière itérative, ce qui implique pas mal de 'review meeting' dans les "grosses" organisations pour valider les interfaces (et malheureusement aussi souvent une intégration trop tardive).
C'est a peu près la même chose, que chaque sous-système soit accessible par une interface (type librairie, ou tout est caché par une <<design pattern>> façade) ou par une API de granularité plus fine (type bibliothèque, presque tout est visible de l'utilisateur).
cf. MIL-STD-498 :
les SSS (system subsystem specification) et les SRS (software requirements specifications) sont composées d'IRS (interface requirement specification).
C'est la revue de ces interfaces qui prend du temps en revues, tout au long de l'avancement du projet.
Evidemment, une modélisation du domaine (indépendamment de la technique) avant la modélisation en sous-systèmes (fortement lie aux critères techniques) permet de partir assez rapidement dans une bonne direction pour chaque sous-systèmes. Car dans l'auto-radio, c'est bien les même notions (ex : 'station radio', avec un flux de son et message RDS) qui sont utilisées dans le display et le(s) récepteur(s).
edit après relecture :
je n'ai pas assez insisté : l'intégration tardive n'est pas une bonne pratique, mais l'intégration continue n'est pas toujours réalisable, surtout s'il y a sous-traitance ou sous-systèmes matériels.
Il y a des concepts intéressants, de toute façon, l'avantage d'UML, c'est qu'on peut étendre et rajouter ce dont on a besoin.Citation:
Envoyé par Alec6
Le problème vient des outils. Ils sont fait dans une optique de générer le code pour le software et les éditeurs les vendent aussi comme des outils de modélisation des systèmes, alors que les problématiques sont différentes.
Du coup, j'ai bien l'impression que Topcased qui s'est affranchi de cette contrainte devient un bon candidat pour le niveau système.