Représentation d'une notation Pointée [Séquence]

Bonjour,

je suis actuellement entrain de rédiger mon dossier d'analyse pour un petit projet. ( Module de synthèse de stage AFPA pour développeur informatique ).

Mon soucis se situe au niveau des diagrammes de séquences.

Grosso modo, il y a 2 manière de coder Objet avec des classes métiers, un controleur et une classe persistance ( je passe sur les instanciations des objets dans mon exemple, on considere qu'on cherche juste à accéder aux infos d'objets déjà chargés en mémoire ) :

1- La notation pointée, où l'on accède directement à la méthode voulue à partir du contrôleur ( ex : oObject_A.oObject_B.oObject_C.MethodeObject_C(param1,param2) )

2- La déléguation dans les méthodes :
A partir du controleur on lance oObject_A.MaMethode_A(param1,param2) Arrivé dans la classe A, dans le corps de MaMethode_A(param1,param2) on a : oObject_B.MaMethode_B(param1,param2).
Arrivé dans la classe B, dans le corps de MaMethode_B(param1,param2) on a : oObject_C.MaMethodeObject_C(param1,param2) et arrivé dans la classe C, le code que l'on souhaite réellement exécuté y est implémenté.

Voilà donc pour le contexte, maintenant ma véritable question :

Le soucis est au niveau des diagrammes de séquences, et de comment noter les messages entre les classes dedans. Pour la méthode 2 c'est très clair c'est une simple flèche ( enfin un escalier descendant de flèches suivant si il faut passer par beaucoup de classes ou pas ).

Mais pour la méthode 1 ? Comment je note ça ? Si je mets une flèche à chaque passage dans un object ( oObjectA.oObjectB.oObjectC etc... ) cela signifie que je crée une méthode là où pointe la flèche or ce n'est pas le cas.
Si je ne mets pas de flèche là où les objets sont traversés et seulement du point dedépart au point d'arrivée, je pars du controleur directement dans oObjectC dans mon exemple. Ce qui signifie que le controleur connait oObjectC or ce n'est pas le cas. Le controleur ne connait que A qui contient B qui contient C. Donc le controleur s'adresse à A, A s'adresse à B, et B s'adresse à C et la méthode voulue s'exécute.

Je ne sais pas si je suis clair

En tout cas merci de me lire

Si je suis pas clair dites le, j'essaierai de reformuler mon problème.

Par contre, d'un point de vu objet, cette première solution est bien moins évolutive que la seconde (pattern GRASP : ne parle pas aux inconnus). La solution 1 est plutot de la programmation spaghetti... mais plus rapide à développer (en tous cas au début).

Oui c'est la conclusion que nous avons eu après une loooongue discussion entre stagiaires et formateurs, en gros, ça revient à faire du batch dans le controleur.

Mais désolé ce n'était pas la question

J'ai choisi de faire en pointé pour une question de temps justement, et parce que cette appli n'évoluera pas.

Mon problème se situe au niveau de la notation dans le diagramme de séquence.

Si je fais ça :

tu peux reformuler le cas 1 en passant par des accesseurs :
oObject_A.getObjectB().getObjectC().MethodeObject_C(param1,param2)

Je perds le gain de temps de la notation pointée puisque le gain viens du fait qu'il n'y a pas besoin de créer une méthode à chaque étape de l'escalier. Créer des assesseurs c'est pareil que créer des méthodes. Enfin le gain de temps s'efface quoi...

Tu peux être plus explicite en assignant un nom à chaque variable accédé :
X -- oObject_B = getObjectB() --> oObject_A

Ca je comprends pas dsl, mais c'est la fin dejournée et j'en ai plein la tête

Donc je reviens à mon problème de notation, normalement, quand on est dans le DS, on est pas censer penser en code, or on sait pertinament que chaque flèche se traduira par une méthode, et le pointé permet justement d'éviter la création de nombreuses méthodes ( une ligne avec plusieurs flèches = en gros une seule méthode au bout de la flèche. )

Comment je note ça sur un diagramme de séquence ? Je veux dire comment je note le passage au travers des objets ? Je suis obligé de le noter pour une raison de clartée.

J'ai opté pour tracer une flèche, mais sans y attribuer un nom. Maintenant je ne trouve rien dans UML en Action, ni sur les sites UML que j'ai pu lire, ni sur la doc que j'ai sur UML 2.0. Donc il doit y avoir une méprise, probablement que "coder en batch" dans le controleur ne se fait tout simplement pas en objet.

C'est la conclusion à laquelle j'arrive en fin de compte.

C'est dommage que les DS d'UML ne tiennent pas compte de ça parce que dans le cas où l'on veut coder vite, en objet, et que l'on sait que l'appli ne va pas évoluer ou très peu, le pointé est un bon gain de temps...

Pour répondre à ta question initiale, tu confonds modèle et implémentation.
La vraie différence entre tes 2 options et que dans le premier cas ton contrôleur ne connait pas C et dans le second il le connait !!
Donc dans le premier cas tu fais des appels encapsulés et dans le second un appel direct. Dans ce second cas, le fait de passer par les autres objets intermédiares est un détail d'implémentation/structure de tes classes; ton contrôleur connait bien C oui oui !
C'est pour cela d'ailleurs que alex00 fait référence aux GRASP. Il a tout à fait raison

Je connais pas GRASP, je ferai une recherche.

Mais je suis pas d'accord sur ce que vous dites. Dans les 2 cas, le controleur ne connait QUE A.

Que l'on fasse un pointage ou que l'on délègue les responsabilité le controleur ne connait que A.

Dans le cas du pointage, on fait oObjectA.oObjectB.etc...
le controleur ne connait que A, je veux dire, il n'a que A en attribut ( en attribut parce que en fin de compte le controleur est une classe comme les autres ), il appelle A, et c'est au travers de A qui lui connait B qu'il s'adresse à B, puis à C au travers de B etc...

Dans le cas de la délégation, le controleur demande à A d'exécuter une méthode, il passe la main à A. A exécute sa méthode qui contient un objet B qui exécute une méthode. A passe la main à B qui exécute une méthode qui contient un objet C qui exécute une méthode etc...

En code ce n'est pas la même chose, dans le cas de la délégation on a une méthode par escalier, dans la 1ère on a une seule méthode au bout de l'escalier sur le DS.

Or lorsqu'on note une flèche sur un DS cela signifie la création d'une méthode. Que l'on soit encore un conception, à la limite... Je veux dire, si vous utilisez rationnal rose par ex, la création de la méthode se fait directement, vous la constatez dans vos classes !

Ce n'est pas un problème de modélisation puisque dans le cas de la délégation, je veux dire si on a structuré son DS pour déléguer, arrivé à la phase prog on peut si on veut faire du pointage ce n'est pas un problème.

Donc en fin de compte, il n'y a rien dans la modélisation UML qui permette de faire cette distinction dans les DS, et pourtant c'est un choix important de structure puisque cela réduit le temps de codage mais augmente les temps éventuels de maintenance/mise à jour.

Enfin bref, ptet que GRASP résoud ma question je vais voir.



En tout cas merci pour vos réponses.

Ok je viens de lire le document PDF de Pierre Chauvin " Introduction aux GRASP Pattern "

Le pattern controleur EST ce que j'appelle la délégation.

Cela dit, cela ne résoud pas mon problème qui est que l'on n'a la possibilité techniquement de coder en batch dans le controleur et que même si ce n'est pas un pattern, cela à ses avantages et ses inconvénients.

Mébon c'est plus clair merci J'ai capté que en théorie on doit se limiter au GRASP pattern controleur et ne pas faire du pointé dans le controleur

Juste pour te dire que alex00 et moi avons bien raison quoi que tu puisses croire.

Si tu suis ce que l'on a dit, tu n'auras plus de problème.

Et ne confond pas modélisation et implémentation

Oui oui je sais bien que la méthode que vous proposez est la plus objet et la meilleure d'un certain point de vue. J'en suis convaincu moi même ce n'était pas vraiment le problème ^^

C'est juste qu'on ( on = les stagiaires ) a beaucoup de questions et les formateurs n'ont pas eu forcément le temps d'explorer à fond UML, et comme on a pas mal avancé voilà quoi.

Mais c'est difficile de parler d'un truc aussi précis via un forum.

Enfin bon merci

Je mets le tag résolu mais pas de bon coeur je suis pas certain qu'on se soit totalement bien compris, ça serait plus simple à l'oral devant un DS ^^