modelisation uml d'un protocole de communication, pb avec mes use cases

Citation:

---

Envoyé par Joshua Beharia

Beurk beurk et rebeurk ! Sacré professeur, j'avais les mêmes, en UV Objet le gars il nous parlais de classes Java...

---

pourquoi beurk? pour le professeur ou la définition? :lol: nan sérieusement c'est quand même un peu vrai non? même si ce n'est pas complet bien sûr :?

je m'éloigne un peu de mon sujet , et au risque de paraître un peu naîve, mais quel problème avec les classes java? j'avais pas trouvé ça saugrenu et surtout c'est carré au moins comme mise en forme. (mais bon je n'ai pas le recul pour juger! ;) )

Citation:

---

Envoyé par Joshua Beharia

"Un objet est une entité possédant des responsabilités et un comportement."

---

Alors j'ai commencé à me demander si ça ne pouvait pas aussi aller pour définir une classe, mais non puisque une classe c'est totalement théorique et n'est donc pas une entité! Sinon dans responsabilité, je pense que tu sous-entend les relations avec les autres objets, et dans le comportement en général, on place les compétences de l'objet, ses actions et réactions. Mais où se situe, dans ta définition l'état de l'objet, avec la valeur de ses attribut, ainsi que son identité?
Donc finalement je refait une définition qui me semble mieux que ma première: un objet est une entité qui possède son identité, un état et un comportement.

Citation:

---

Envoyé par alex00

Quelles sont les questions que tu te pose encore pour faire une première ébauche de ton protocole ?

---

**Et bien déjà je me demande toujours s'il y a des objets types propres à un protocole de communication, j'ai vu en recherchant de la documentation qu'il y a certains objets qui reviennent par exemple "medium" ou "protocol entity", "receiver" "transmitter"
Y a-t-il vraiment des objets clés d'un protocole de communication, et si oui comment s'en servir?

** Autre interrogation: apres vos sugestions et des recherches (merci google et developpez bien sur!) je me lance donc dans les machines à état. Je me demande cependant quels sont les "objets" dont je dois décrire les variations d'état. Je pense qu'il faut que je décrive:
- l'état des données: commande brute/ commande encapsulée/ commande controlée/ commande non controlee/ trame prête à être envoyée
- l'état des buffers : vides / non vide
-l'état des ports : inactif/ en envoi/ en réception
-l'etat de la connexion: configurée/ non configurée (connexion permanente)
- l'état du text box: vide/ rempli
-l'etat du bloc d'affichage: vide/rempli
humm après je ne vois pas quoi d'autre

**apres en fait j'essaye de trouver comment caser mes modes de fonctionnement. Dois-je faire un objet "passif" qui n'a qu'un attribut qui correspond au mode de fonctionnement et deux méthodes get et set pour modifier cet attribut?

** l'encapsulation des données me pose aussi problème dans l'architecture de mon diagramme de classe: le début de message et la fin de message (ddm et fdm) doivent être "calculées " ou puis mises en place est-ce que je peux faire une interface qui possède ses méthodes par exemple? et quel objet doit appeller ses méthodes? les données? ou dois-je créer un objet "encapsulateur" qui s'occupe de ça?
Ce que je peux peut -être faire sinon c'est créer une classe ddm, une classe fdm, une classe numéro de bloc, une classe adresse, et à chaque message envoyé un objet est créé qui calcule le contenu de ces ddm, fdm..
bref, je crois que c'est aussi brouillon dans ma tête que dans ce que je viens d'écrire, désolée.

1) cf. exemple ci-dessous

2) les plus important a mon avis : etat des ports, etat de la connexion

3) qu'entends-tu par mode de fonctionnement ?

4) a mon avis l'encapsulation (ajout du ddm et fdm) font partie de la dynamique : ce sont des 'fonctions' (ou quelques lignes dans des fonctions) internes a ta couche de communication, pas des entites a part entiere.


l'exemple :
besoins : un objet A envoie un message m a un objet B (c'est de la comm...)
http://www.developpez.net/forums/att...1&d=1186750489

Avec 2 niveaux d'encapsulation :
http://www.developpez.net/forums/att...1&d=1186750489
L'exemple est fortement oriente : message de A vers B, et reponse (cf dissymetrie B_remote vs. receiver).

Sous forme de classes :
http://www.developpez.net/forums/att...1&d=1186750489

On peut avoir comme communication :
1) A vers B (simple, cf. diagramme 1)
2) A vers B (a travers B_remote puis receiver uniquement)
3) A vers B complet (cf. diagramme 2)

Merci pour cette réponse, je pense que ça va m'aider.
Il y a toutefois quelques trucs qui m'échappent:
1) C'est quoi cet objet A_remote?
2) La methode process c'est bien celle qui consiste à assembler la trame??
3) Le m() , je ne vois pas trop non plus son rôle. l'affichage peut être?
4) S'il y a un objet receiver, pourquoi pas un objet transmitter? ou est-ce que justement ce a_remote est l'équivalent d'un transmitter?

Sinon pour les modes de fonctionnement, en fait le protocole admet trois modes de fonctionnement qui diffèrent par leur sécurité et les controles faits: un mode terminal qui sert juste à configurer les equipements et donc avec un niveau de sécurité 0, un mode avec sécurité minimale pour les tests et un mode avec controle multiple pour le fonctionnement normal.
Ce qui correspond aux trois cas d'utilisation que nous avions cités en premiere page du topic.

selon le mode choisi (par le maitre) , il y a ou pas controle du cheksum, prise en compte du multibloc, prise en compte du multipoint, et type de caractères (imprimables ou pas)

Ma question par rapport à ca est donc comment on prend ça en compte dans le diagramme de classe? sachant que sur l'ihm, il y a un menu ou un boutton pour choisir le mode.

Bonjour,

le post précédent m'a pris du temps, j'explique un peu plus maintenant.

Ce que tu veux, c'est faire communiquer une appli (maitre) avec autre (distante, ou esclave).
cf. diag 1) : A (appli maitre) envoie le message m(text) a B (appli distante). C'est une version simplifiée, dans les grandes lignes, sans tenir compte que A et B sont sur des plateformes différentes.

Le deuxième diagramme reprend cette idée de faire communiquer A avec B.
Sauf que comme ils ne sont pas sur la même plateforme, il faut transmettre le message a travers les différentes couches de communication.
A dialogue sur sa plateforme avec quelque chose qui ressemble a B, qui a la couleur de B et l'odeur de B, pourtant ce n'est pas B, mais seulement quelque chose qui a la même interface.

cf. diagramme 3) : A connait l'interface de B, pas B directement.
diag. 2) :
A communique avec B_remote (et non pas A_remote ! ).
B_remote est une implementation de l'interface de B, qui transmet le message sur l'autre plateforme (creation de la trame).

en clair : l'interface
Ton API doit fournir l'envoi de texte : la méthode " m(text) : response ".

Ce qui n'est pas clair :
- A est l'appli maitre, et fait tout ce que tu veux,
- B est l'appli cliente, ou en tous cas le receveur de message coté esclave,
- ce diagramme est a faire dans les 2 sens : A envoi un message a B (ajouter le mode multipoints), et B envoi un message a A (message spontané par un esclave).

en clair : l'implémentation
1) A envoie m(text) a un truc qui ressemble a B (en fait, B_remote).
2) B_remote.m(text) cree la trame, et la passe au port serie
3) le port serie transmet la trame sur la liaison serie
De l'autre cote, ca decode, B recoit effectivement m(text), et retourne la reponse.

1) : B_remote, pas A_remote.
2) c'est B_remote.m(text) qui assemble la trame, pas LiaisonSerie.process() qui l'envoie sur le bus serie.
3) m(text) : une methode de ton API : transmettre du texte et retourner une reponse.
4) B_remote est l'equivalent d'un transmitter.

Donc :
A = appli (ou machine) maitre
B = appli (ou machine, ou equipement) esclave

Communication dans l'autre sens :
un B communique avec un A_remote
exemple : B appelle A.m'(param)

Remarque :
la transmission de texte ou d'hexa ne signifie rien au niveau applicatif, c'est de tres bas niveau.
les mode de fonctionnement sont d'un niveau un peut plus haut il me semble.
(a moins que le niveau applicatif soit indiqué par le nom de la fonction)

Pour gerer les droits d'acces, tu peux regarder du cote des patterns : 'decorateur', peut-etre aussi 'etat' (plus complique, pas forcement adapte).
http://en.wikipedia.org/wiki/Design_...mputer_science)

Citation:

---

Envoyé par alex00

le post précédent m'a pris du temps, j'explique un peu plus maintenant.

---

Merci beaucoup pour tout ce temps que tu passes à m'aider!!

Je pense avoir compris le principe du remote! merci! :king:

Sinon ,

Citation:

---

Envoyé par alex00

les mode de fonctionnement sont d'un niveau un peut plus haut il me semble.
(a moins que le niveau applicatif soit indiqué par le nom de la fonction)

---

Je ne comprend pas ce que tu veux dire :oops: , il faudrai que jindique si ca concerne la couche liaison/ transport/ ... dans le nom des fonctions?

Citation:

---

Envoyé par alex00

Pour gerer les droits d'acces, tu peux regarder du cote des patterns : 'decorateur', peut-etre aussi 'etat' (plus complique, pas forcement adapte).
http://en.wikipedia.org/wiki/Design_...mputer_science)

---

Je me penche un peu plus sur les design pattern alors! merci!!

Citation:

---

Envoyé par alex00

Ton API doit fournir l'envoi de texte : la méthode " m(text) : response ".

---

Si j'ai bien compris, on peut dire que je developpe une API??

concernant les modes de fonctionnements :
entre la description (de mémoire) :
... envoyer du texte et de l'hexa ...
et celle sur les droits d'accès (3 niveaux d'autorisations), je ne fais pas le liens.

d'un cote je vois :

Code:

---

1 2 3

send(text) : response send(hexa) : response

---

et de l'autre :

Code:

---

1 2 3 4

configurer( ?machin, valeur ?) // ou machin.set(valeur) tester(???) faire_fonctionner(???)

---

le premier est du niveau communication, le deuxième du niveau applicatif (normal pour le contrôle des droits d'accès).
peut-etre la solution est-elle (avec le niveau applicatif qui dialogue avec le niveau communication) :

Code:

---

1 2 3 4 5 6 7 8

X --- set(valeur) ---> machin_decorateur_mode_normal // niveau applicatif // controle droits d'accès fonction du mode machin_decorateur_mode_normal --- set(valeur) ---> machin_remote // niveau applicatif // conversion du message en text machin_remote --- send(text) ---> truc_remote // niveau communication // creation de la trame autour du text truc_remote --- process ---> port_serie // émission, niveau transmission

---

Citation:

---

Envoyé par alex00

concernant les modes de fonctionnements :
entre la description (de mémoire) :
... envoyer du texte et de l'hexa ...
et celle sur les droits d'accès (3 niveaux d'autorisations), je ne fais pas le liens.

---

en fait j'ai du mal m'exprimer.
Il y a trois modes. le mode de fonctionnement normal, et deux modes dits "de repli"
A chaque fois, le module maitre va envoyer une commande et attendre une réponse du module esclave.
Cette commande est en hexa.

Dans le mode dit "de fonctionnement normal", cette commande va etre encapsulée, il va y avoir une division en bloc si le bloc est trop long, un calcul du cheksum, une verrification de l'adressage, et elle est envoyée au port série.

Dans le mode dit "de configuration"
Cette commande va etre envoyee directement au port serie, sans aucune modification ou controle, c'est un mode terminal, en point à point

Et le mode de "test" est à mi-chemin entre ces deux modes. dans la commande envoyée par le module maitre, les caracteres non imprimables seront remplacés par des caracteres imprimables (y compris dans les entetes et queues de trame), elle sera ensuite encapsulee, divisee si besoin, verification de l'adressage, mais pas de calcul du cheksum.

En gros, il ne s'agit pas de droit d'accès, mais de niveau de sécurité des informations transmises. le mode de configuration etant le moins sécurisé. Le mode "test" intermédiaire, mais plus "ergonomique" pour l'utilisateur car caractères imprimables(plutot destiné a etre commandé par un operateur humain), le mode "normal" etant haute sécurité et fonctionnel (plutot destiné a etre commandé par une machine).

Ces trois modes se distinguent donc en fonction de la maniere dont on veut utiliser le module: en point a point direct avec un terminal simple, pour etablir les tests sur les equipements, ou alors en fonctionnement normal.

Citation:

---

Envoyé par alex00

le premier est du niveau communication, le deuxième du niveau applicatif (normal pour le contrôle des droits d'accès).

---

le controle des droits d'acces se fait dans les couches supérieures dont je ne m'occupe pas

Merci à tous pour votre aide. Pour ma part j'en ai fini avec l'uml sur ce stage.
merci donc de m'avoir aidé!!:king: