IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Diagrammes de Classes Discussion :

[UML] Pour une même classe, avoir un comportement différent suivant les objets ?


Sujet :

Diagrammes de Classes

  1. #1
    Futur Membre du Club
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 8
    Points : 5
    Points
    5
    Par défaut [UML] Pour une même classe, avoir un comportement différent suivant les objets ?
    Bonjour,

    Dans mon projet, la partie du système concernant l'application est représentée par une classe.
    Pour le moment, on représente chaque mode par une classe différente ... mais qui a la même architecture "physique", seul le comportement change.

    Est-il possible et si oui, comment ? de donner un comportement différent à des objets issus d'une même classe ?
    Ou il faut absolument avoir des classes différentes ?

    Ou alors en utilisant l'héritage ?

    Merci de vos réponses.

  2. #2
    Modérateur
    Avatar de bruno_pages
    Homme Profil pro
    ingénieur informaticien à la retraite
    Inscrit en
    Juin 2005
    Messages
    3 533
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 64
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : ingénieur informaticien à la retraite
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Juin 2005
    Messages : 3 533
    Points : 6 709
    Points
    6 709
    Par défaut
    par définition de ce qu'est une classe les instances d'une même classe partagent un même comportement, c'est a dire que si tu défini une opération 'print' au niveau d'une classe est est vraiment pas souhaitable que pour une instance donnée cela fasse une lecture

    Maintenant il y a évidemment des limites à la chose au niveau du détail sinon on ne pourait rien faire, bref si une classe a plusieurs instances ce n'est pas pour qu'elles soient toutes strictement égales ...
    Bruno Pagès, auteur de Bouml (freeware), mes tutoriels sur DVP (vieux, non à jour )

    N'oubliez pas de consulter les FAQ UML et les cours et tutoriels UML

  3. #3
    Futur Membre du Club
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 8
    Points : 5
    Points
    5
    Par défaut
    Merci pour ta réponse.

    Entre-temps, j'ai trouvé une bidouille (c'est sous Tau-G2) avec les diagrammes d'états-transitions.

  4. #4
    Nip
    Nip est déconnecté
    Rédacteur

    Inscrit en
    Juin 2004
    Messages
    963
    Détails du profil
    Informations forums :
    Inscription : Juin 2004
    Messages : 963
    Points : 1 076
    Points
    1 076
    Par défaut
    La dessus je suis totalement d'accord avec bruno_pages; ca fait partie des principes de la POO: une classe = une responsabilite, apres si tu commences a bidouiller comme ca pour arriver a tes fins, c'est que peut etre t'as un probleme de conception quelque part!

  5. #5
    Membre expérimenté Avatar de davcha
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    1 258
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 1 258
    Points : 1 539
    Points
    1 539
    Par défaut
    Peut-être aller voir le design pattern strategy...

  6. #6
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2004
    Messages : 1 883
    Points : 3 510
    Points
    3 510
    Billets dans le blog
    2
    Par défaut
    Je ne serai pas aussi catégorique.
    Il est possible qu'on décrive au niveau d'une classe, un diagramme d'états-transitions qui fait que les différentes instances de cette classe, les objets donc, ont des comportements tellement dépendant de l'état dans lequel ils sont que l'on a presque l'impression qu'on a à faire à des objets de classes différentes.
    Ceci est assez bien illustré d'ailleurs avec le pattern State.
    Mais ok, il s'agit quand même de la même classe mais bon......

  7. #7
    Membre expert
    Avatar de TheLeadingEdge
    Inscrit en
    Mai 2005
    Messages
    1 199
    Détails du profil
    Informations forums :
    Inscription : Mai 2005
    Messages : 1 199
    Points : 3 100
    Points
    3 100
    Par défaut
    Bien sur on peut représenter des structures alternatives ds 1 diagramme d'état-transition, mais si cela dépend du type d'objet je suis d'accord avec Nip, il y a peut-etre mieux à faire.
    selon le principe ''polymorphisme'' (1 des 9 GRASP), quand des méthodes similaires ont des comportements differents selon les ''types'' d'objets il est conseillé de créer 1 méthode polymorphe.

  8. #8
    Membre habitué
    Inscrit en
    Août 2004
    Messages
    113
    Détails du profil
    Informations forums :
    Inscription : Août 2004
    Messages : 113
    Points : 127
    Points
    127
    Par défaut
    Bonjour

    3 points de vue :

    1) Le comportement d'un objet correspond à sa réaction au messages qu'on lui envoie. Ce comportement est le cycle de vie de l'objet ; il se modélise avec une machine à états.

    2)Dans le premier post, milk-at parle de "la partie du système concernant l'application".
    Je comprend la partie applicative d'une architecture en couche (n-tiers).
    Ce qui correspond à un controleur (de Use Case) d'une décomposition Boundary-Control-Entity (Jacobson)

    On peut donc avoir un même objet qui se comporte différemment selon son état (créé, initialisation 1 réalisée, initialisation 2 réalisée, prêt, en service, en erreur, ...).

    L'utilisation des machines à états n'est pas une bidouille, mais une modélisation très formelle (que je recommande fortement).

    3) d'après le titre : pour des objet d'une même classe qui sont dans des états différents, on peut avoir des réponses différentes à un même message. Tous les objets d'une même classe ont le même cycle de vie, donc sont décris par la même machine à état.
    cf. point 1 de ce message et message d'ego : que veut dire pour toi "comportement" ? (réponse possible à un message OU cycle de vie complet sous forme de machine à états).

  9. #9
    Futur Membre du Club
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 8
    Points : 5
    Points
    5
    Par défaut
    Quand je parlais de bidouille, j'ai un peu exagéré.

    Il n'ya pas de méthodes (je sais c'est effrayant mais c'est comme ça), le comportement est modélisé avec les machines à états.
    J'ai essayé avec l'héritage mais là encore ça bloque

    alex00 : Pour moi, le comportement est un cycle de vie complet sous forme de machine à états en réponse à un message. donc le point1.

    Disons que ma classe A à plusieurs modes de fonctionnements.
    Selon le mode, un cycle de vie différent : La réponse à un même message sera différente suivant le mode dans lequel on se trouve.

    Evidemment, le mieux serait de faire dériver cette classe par des classes B, C, D qui contiendrait chacune le comportement (la machine à états) pour un seul mode.
    C'est tordu mais le problème c'est que le diagramme d'architecture est déjà énorme. Si il faut que je rajoute une classe pour chacun des modes, je multiplie d'autant les liaisons. J'ai l'impression de m'embrouiller de plus en plus là

    Milk-at ... vu ! on me l'a fait tout le temps

  10. #10
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2004
    Messages : 1 883
    Points : 3 510
    Points
    3 510
    Billets dans le blog
    2
    Par défaut
    Au lieu de théoriser, si tu nous montrais ce que tu as fait ?

  11. #11
    Modérateur
    Avatar de bruno_pages
    Homme Profil pro
    ingénieur informaticien à la retraite
    Inscrit en
    Juin 2005
    Messages
    3 533
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 64
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : ingénieur informaticien à la retraite
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Juin 2005
    Messages : 3 533
    Points : 6 709
    Points
    6 709
    Par défaut
    je suis d'accord avec ego, se serait plus facile si on en voyait un peu plus ...

    En tout cas il y a quelque chose que je ne comprends pas : pourquoi la/les machine(s) à états ne suffise(nt) pas et tu y attaches des classes annexes par mode ?
    Bruno Pagès, auteur de Bouml (freeware), mes tutoriels sur DVP (vieux, non à jour )

    N'oubliez pas de consulter les FAQ UML et les cours et tutoriels UML

  12. #12
    Membre habitué
    Inscrit en
    Août 2004
    Messages
    113
    Détails du profil
    Informations forums :
    Inscription : Août 2004
    Messages : 113
    Points : 127
    Points
    127
    Par défaut
    si tu as beaucoup d'états, utilise le pattern state (cf. http://pcaboche.developpez.com/artic...page=page_2#L2)

    ce n'est pas tordu.
    les liaisons (je comprends attributs et associations) sont toutes mises une seule fois au niveau de UneClasse (ou déléguées dans une structure de données UneClasseData)
    Un diagramme d'architecture (ou de conception) n'a jamais à être complet : il vaut mieux faire plusieurs vues (ex : une d'ensemble avec UneClasse et ses liaisons, une autre qui détaille UneClasse et ses classes-états).

  13. #13
    Futur Membre du Club
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 8
    Points : 5
    Points
    5
    Par défaut

    Donc on a un système modélisé par un ensemble de classes qui composent la classe principale Main.
    Les Class1, Class2, …. ont des rôles subalternes et je l’ai juste mises pour montrer qu’elles existent.
    La classe gestion recupère toutes les infos de configuration du système, entre autre les infos sur le mode dans lequel on se trouve. Qu’elle transmet à la classe application.
    Les SousModule sont chargés de différentes opérations, chacune étant caractérisés par une fonction gloable (décision, traitement, exécution, récupération de données).
    L’architecture gloable du système a été défini avant que je n’arrive sur le projet, donc je ne connais pas exactement tous les comment et pourquoi de ce choix de modélisation.
    Donc, ce que j’essaye de faire, c’est que la classe d’application change de mode et le répercute sur tous les sous-modules.

    Donc à partir de là, plusieurs solutions :
    1) dans le diagramme de la machine à états, suivant le mode où l’on se trouve, la réaction à l’arrivée d’un même message sera différente. Et tout sera inclus dans la même machine à états, donc un critère de choix à placer avec l’arrivée de chaque message (y en a une cinquantaine).


    2) L’héritage, une classe Sous Module est parente de N classes pour N modes. Dans chaque classe fille, un comportement différent avec la même structure physique (pour les ports entre autre).

    Pour l’instant mon problème avec cette solution , c’est que même si je crée la class avec New herit1() (avec le langage d'action dans Tau-G2)
    Lorsque je simule, je me retrouve à suivre la machine à états de la classe mère.

    bruno_pages : c'est un point que je ne contrôle pas, pour moi, j'aurais tout mis dans la même classe et bye bye
    mais mes responsables tiennent à ce qu'il est y est une classe pour un mode de façon, je cite " à pouvoir rajouter facilement un mode si besoin est"

    alex00 effectivement, j'avais oublié ce détail mais reste quand même la création des classes qui prend quand même un certain temps (le simple copier-coller ne marche pas).
    Alors, j'ai regardé le pattern state ; j'arrive pas à voir si ça marche avec juste les machines à états ?

  14. #14
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2004
    Messages : 1 883
    Points : 3 510
    Points
    3 510
    Billets dans le blog
    2
    Par défaut
    Je ne comprend pas tout mais bon.........

    N'es-tu pas dans un système complexe qui comporte différentes parties, chacune réalisant un boulot particulier ?
    Ces parties ont un comportement qui dépend d'un état "global" du système.
    Quand il y a un changement d'état, il faut en avertir les différentes sous-parties qui vont réagir en conséquence.
    Si j'ai bon, je ne suis pas certain qu'un seul diagramme d'états-transitions soit suffisant, il faut en faire un par sous-partie.
    Le "vrai" diagramme d'état de ton système étant la somme des diagrammes d'états des sous-parties; c'est le cas dans un système complexe; prend le cas d'une voiture avec, le moteur, la climatisation, son GPS,...Dans le cas de la voiture, le diagramme d'état de la voiture ne peut être qu'une somme de diagrammes sachant qu'il peut y avoir des évènements au "niveau de la voiture" qui ont un impact sur les sous-éléments pré-cités (genre contact éteint).

    Dernier point, ton archi n'est-elle pas issue de la mise en place du pattern "Blackboard" ?

    En espérant avoir donné des idées utiles........

  15. #15
    Modérateur
    Avatar de bruno_pages
    Homme Profil pro
    ingénieur informaticien à la retraite
    Inscrit en
    Juin 2005
    Messages
    3 533
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 64
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : ingénieur informaticien à la retraite
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Juin 2005
    Messages : 3 533
    Points : 6 709
    Points
    6 709
    Par défaut
    Citation Envoyé par ego
    N'es-tu pas dans un système complexe qui comporte différentes parties, chacune réalisant un boulot particulier ?
    Ces parties ont un comportement qui dépend d'un état "global" du système.
    Quand il y a un changement d'état, il faut en avertir les différentes sous-parties qui vont réagir en conséquence.
    Je suis 100% d'accord avec ego

    Par contre je suis 100% contre l'utilisation du pattern state qui simule un changement de classe, car cela c'est vraiment un choix à la shadock
    Bruno Pagès, auteur de Bouml (freeware), mes tutoriels sur DVP (vieux, non à jour )

    N'oubliez pas de consulter les FAQ UML et les cours et tutoriels UML

  16. #16
    Futur Membre du Club
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    8
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 8
    Points : 5
    Points
    5
    Par défaut
    Désolé pour le temps de réponse, j'étais pas dans le coin.

    Donc depuis mon message de mercredi, j'ai réussi à mettre en place la solution de l'héritage et pour l'instant ça tourne.
    Donc pour le patern state, je penses que je vais faire sans.

    Pour le pattern "Blackboard" , en réalité, je ne sais même pas de quoi il s'agit, donc si c'est ça, c'est pas fais exprès.

    Il s'agit bien d'un système complexe dont le comportement de chaque partie dépend de l'état global et qu'il faut transmettre (messages).
    Il y a bien un diagramme par sous-partie. le problème était de changer de "version" de sous-partie suivant le mode, ce que j'ai fais avec l'héritage.

    Donc merci pour ces remarques ego et tous les autres.

    Si il n'y a pas d'autres remarques, je pense que je pourrais appuyer sur le magnifique et tant désiré bouton "résolu".

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 1
    Dernier message: 20/04/2015, 11h41
  2. Liste déroulante avec comportement différent suivant les navigateurs
    Par smfoa dans le forum Bibliothèques & Frameworks
    Réponses: 1
    Dernier message: 30/01/2011, 12h55
  3. Réponses: 0
    Dernier message: 25/10/2008, 11h50
  4. Réponses: 5
    Dernier message: 30/01/2007, 14h23
  5. [POO] Deux constructeurs pour une même classe
    Par amika dans le forum Langage
    Réponses: 4
    Dernier message: 16/12/2006, 17h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo