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

Version imprimable

Voir 40 message(s) de cette discussion en une page

30/07/2007, 16h17
firaponte

1 pièce(s) jointe(s)

Bonjour,

alors voilà mon dernier diagramme de cas d'utilisation, j'espère que celui ci sera correct! ;)

Sinon pour ce qui concerne la description, je n'ai finalement pas différencié les modes maîtres et esclaves, j'ai fait autre chose que les 2 cas exposés plus haut.
Finalement le mode esclave apparait comme un enchainement alternatif à certaines étapes du processus.
J'ai choisi en fait de décrire le scénario nominal: session de communication simple avec message court sans préavis en mode maître.
Il y a ensuite deux enchainements principaux:
- 1/ emission de message
- 2/ réception de message
et chaque enchainement est détaillé au niveau inférieur (1.1, 1.2, 1.3, etc...)
et je gère les différents modes à l'aides des enchainements alternatifs et des exceptions.

Et j'essaye de faire un maximum de diagrammes et tableaux pour illustrer .
06/08/2007, 10h21
firaponte

Merci Alex00 pour ton aide!
Comme tu n'a pas contesté le dernier message je suppose que mon dernier diagramme est correct, et je met le tag résolu!

encore merci!
07/08/2007, 17h40
ego

Histoire de ramener ma science :oops:

Un cas d'utilisation "Etre connecté" n'est pas très bon. Le verbe utilisé dans le nom du cas d'utilisation doit désigner une action pas un état.
Pour la description de protocoles, UML propose les "protocol state machines". C'est très utile pour décrire les enchainements autorisés par le protocole.

D'autre part, mais j'ai lu rapidemment le post, utiliser des cas d'utilisation pour décrire un protocole me parait, au premier abord, un peu tordu. Les cas d'utilisation ne servent pas forcément à tout.
Mais bon, si vous êtes arrivé à qq chose de satisfaisant, pourquoi pas.
08/08/2007, 09h40
firaponte

Citation:

Envoyé par ego

Un cas d'utilisation "Etre connecté" n'est pas très bon. Le verbe utilisé dans le nom du cas d'utilisation doit désigner une action pas un état.

Merci pour cette réponse!!

Pour le cas d'utilisation Etre connecté, je l'ai remplacé par une pré-condition , du coup il faut bien un état non?

Citation:

Envoyé par ego

Pour la description de protocoles, UML propose les "protocol state machines". C'est très utile pour décrire les enchainements autorisés par le protocole.

Et bien je vais essayer de comprendre comment ça fonctionne alors, si ça peut m'aider, je suis pour!!
Mais est-ce que ça m'aidera pour faire mon diagramme de classe après? car la j'ai un peu (voir pas mal) de mal avec !!

Citation:

Envoyé par ego

D'autre part, mais j'ai lu rapidemment le post, utiliser des cas d'utilisation pour décrire un protocole me parait, au premier abord, un peu tordu. Les cas d'utilisation ne servent pas forcément à tout.
Mais bon, si vous êtes arrivé à qq chose de satisfaisant, pourquoi pas.

Disons que je suis arrivée à quelque chose qui décrit les besoins, je pense que ça peut être utile, mais c'est sur que c'est loin de suffire! c'est pourquoi je cherche à faire aussi d'autres diagrammes
08/08/2007, 13h19
Joshua Beharia

Je m'invite...

Bonjour bonjour,

je rnetre dans la conversation si vous le permettez car elle me parait des plus interessantes !

J'ai parcouru vos messages et je tiens donc à ressortir l'essentiel de ce que j'ai retenu (je comprend vite mais il faut m'expliquer longtemps):
-> faire un protocole de communication
-> étude avec langage UMl et une méthode UseCase Driven (type USDP)

J'ai raison or not ?

Je présume que oui et je donne mon avis comme Mister Ego.

J'ai déjà réaliser implémenter et réaliser plusieurs protocoles de communication en utilisant une méthodologie Objet propre à mon entreprise dérivée de USDP.
Déjà, je n'ai jamais pris un protocole de communication comme le system à isoler et donc celui dont on trouve les cas d'utilisation.

Un protocole de communication sert juste à "communiquer" donc les UC sont très restreints. C'est à dire pas d'UC "se connecter" ou autre. "Se connecter" est une fonctionnalité du protocole.

Un protocole de communication est interne au system étudié. Il va apparaitre en phase d'Analyse sous forme d'un bloc "Communication" qui sera explosé en design en pls objets (Protocol, Frame, SerialDevice...) ceci dépedant du type étudié et de ta plateforme.

J'espère que cela te servira en tout et pour toutes remarques, il faut pas hésiter, j'ai pas de vacances cette année ! Sacrés projets...:aie:
08/08/2007, 14h02
firaponte

bonjour!!

Et bien finalement ma discussion ne tourne plus seulement autour des cas d'utilisation (contrairement au titre) mais bon, je ne pense pas que ce soit grave, car à mon avis, ça va bien m'aider, surtout que pour le reste je suis encore bien embétée (et j'hésitais à créer un autre topic pour la suite du coup je continue ici! :yaisse2:

Citation:

Envoyé par Joshua Beharia

J'ai parcouru vos messages et je tiens donc à ressortir l'essentiel de ce que j'ai retenu (je comprend vite mais il faut m'expliquer longtemps):
-> faire un protocole de communication
-> étude avec langage UMl et une méthode UseCase Driven (type USDP)

J'ai raison or not ?

disons que oui c'est ça, sauf que je ne veux pas me restreindre aux cas d'utilisation. Je veux juste m'en servir comme point de départ, ça m'a servit à faire mes premiers pas dans ce projet en le décrivant d'une maniere (par les use case) mais maintenant j'aimerait utiliser d'autres diagrammes pour compléter.

Citation:

Envoyé par Joshua Beharia

J'ai déjà réaliser implémenter et réaliser plusieurs protocoles de communication en utilisant une méthodologie Objet propre à mon entreprise dérivée de USDP.

alala, bien des personnes disent avoir travaillé sur ce type de projets, trouvent ça limite "trivial", mais quand on débute comme moi, on ne trouve rien sur le net de précis la dessus!! pourquoi!! :arf:
si tant de gens modélisent et implémentent des protocoles, il doit bien y avoir des modélisations type, des diagrammmes de classe type ou quelque chose non? :mur:
Est-ce que c'est moi qui suis un :boulet: ou bien comme ça touche souvent au domaine de l'info indus les gens gardent ça pour eux? :question:

Citation:

Envoyé par Joshua Beharia

Déjà, je n'ai jamais pris un protocole de communication comme le system à isoler et donc celui dont on trouve les cas d'utilisation.

Un protocole de communication sert juste à "communiquer" donc les UC sont très restreints. C'est à dire pas d'UC "se connecter" ou autre. "Se connecter" est une fonctionnalité du protocole.

En fait j'ai retiré le UC "se connecter" pour le mettre en précondition.
ensuite je ne modelise que le protocole, le but etant ensuite de pouvoir le réutiliser avec nimporte quelle couche supérieure utilisant ce protocole
Est-ce que ça semble abhérent? peut etre que finalement ce n'est pas quelque chose qui se fait et que c'est pour ça que je ne trouve pas la doc voulue.

Citation:

Envoyé par Joshua Beharia

Un protocole de communication est interne au system étudié. Il va apparaitre en phase d'Analyse sous forme d'un bloc "Communication" qui sera explosé en design en pls objets (Protocol, Frame, SerialDevice...) ceci dépedant du type étudié et de ta plateforme.

Donc en fait je peux dire que mon projet se résume à l'analyse et la modélisation du bloc communication nan?
Puisque je me répète mais mon système peut prendre plusieurs tailles selon comment on le considère et en fait je ne modélise que la couche liaison/transport, du coup mon système se réduit à ce bloc communication. c'est possible?

Quand tu parles de "explosé en design", tu sous-entend design pattern? Je ne comprend pas?

Hum je suis désolée mais alors je ne vois pas ce que peuvent être les objets que tu cites: protocol? Quesqu'il ferai cet objet?
Frame? je suppose que c'est ce qui est échangé?
Serial device: alors la je vois pas non plus!! :oops:

Citation:

Envoyé par Joshua Beharia

J'espère que cela te servira

Et bien déjà ça me fait me poser pas mal de question, ce qui est un début non?
Je pense que j'ai pas mal à apprendre ! ouaou! Mais malheureusement peu de temps! comme toujours! alors merci pour votre aide, c'est super sympa!!
08/08/2007, 14h22
Joshua Beharia

firaponte, j'ai pas le tps de répondre maintenant mais on va dire que demain on se fait un ptit topo la dessus avec exemple et tout et tout si tu veux.
Et oui, les gens de l'indus ce sont des salauds ! :yaisse2:

A demain ou ce soir si j'ai un moment.
08/08/2007, 14h26
firaponte

ok :merci: beaucoup!!! :D
c'est super sympatique!! :D
09/08/2007, 11h19
alex00

Bonjour,

je reprends la discussion en cours.

sur le diagramme :
mieux vaut en faire 2 distincts (un diag d'uc, un diag de classes).

Entre UC et PSM (protocol state machine) :
Réaliser de but en blanc la PSM est très risqué, ca fige tout de suite une solution alors qu'on ne la pas encore cernée par les user stories.
=> la PSM est une synthèse (des scénarios), très formelle, qui arrive en fin d'étude des UC.

UC "être connecte"
c'est un état, pas l'obtention d'une valeur ajoutée, effectivement.
c'est un UC secondaire, ou de support, dont "le système a besoins" pour garantir le bon fonctionnement du système.
(remarque sur le formalisme, pas sur la methode : une fois que l'on "est connecte", on peut (au sens <<extends>> réaliser les autres UC (services a valeurs ajoutée)).

approche UC driven :
et oui, modéliser un protocole tout seul sans connaitre le contexte englobant est risqué (un bon système informatique est adapte a son système d'information).
On ne sait toujours pas ce que c'est concrètement qu'un 'Machin' (cf. premiers posts).

approche "réduction des risques" (toujours USDP) :
- regarde les couches de plus haut niveau (pas seulement la communication), ca peut paraitre hors sujet, mais c'est la seule garantie de comprendre ce qu'on te demande et de réaliser quelque chose d'adapté.
- une fois les principaux scénarios définis (les plus usuels + les cas particuliers), tu pourra faire la PSM.

Alex
09/08/2007, 12h06
firaponte

1 pièce(s) jointe(s)

Citation:

Envoyé par alex00

approche "réduction des risques" (toujours USDP) :
- regarde les couches de plus haut niveau (pas seulement la communication), ca peut paraitre hors sujet, mais c'est la seule garantie de comprendre ce qu'on te demande et de réaliser quelque chose d'adapté.
- une fois les principaux scénarios définis (les plus usuels + les cas particuliers), tu pourra faire la PSM.

Bonjour!
Je vais vous représentez un peu mieux mon projet.
En fait, dans un plus long terme, le système que je concoit (enfin que j'essaye de concevoir! ;) ) sera intégré à des systèmes plus complets par une autre personne que moi. Ces système globaux pourront en fait chacun etre particulierement différents les uns des autres au niveau de la couche de présentation et de traitement des données. Mais auront tous en commun la couche de liaison/transport, qui en fait contient le protocole que j'essaye d'implémenter.
C'est pour ça qu'il ne faut pas que j'étudie une couche supérieure trop précisément, pour que mon système puisse être intégré facilement à d'autres applications.
Comme il faut quand même une IHM minimale pour pouvoir tester mon système, et puis faut bien envoyer les données quelque part, je réalise une toute petite et simple couche de présentation qui est composée d'une ihm avec une texbox pour taper le message à encapsuler et envoyer, et un autre cadre dans lequel s'affiche les données arrivées et traitées par le système.
De l'autre côté de mon système, on a un port série. puisqu'il s'agit d'un protocole de communication via port serie. ce port série est relié à un équipement ou un pc qui possède lui aussi le protocole.
ca se résume par le dessin que j'ai mis. :)

Donc je sais particulièrement bien ce qu'il y a au dessus de mon protocole, mais pour mon projet je me restreint à un truc super simple, sans sgbd, ou modules plus complexes.
09/08/2007, 12h13
firaponte

Citation:

Envoyé par alex00

On ne sait toujours pas ce que c'est concrètement qu'un 'Machin' (cf. premiers posts).

En fait, du coup je pense que le "machin" intervient quand on considere le logiciel global, et mpas seulement mon petit module qui s'occupe du protocole.
mais sinon ça peut être le port série d'un côté ( qui communque avec un pilote via la liaison série) et de l'autre côté c'est l'utilisateur qui remplit le textbox (mais qui sera remplacé, par la suite par un module de présentation)
Donc finalement on a le module de presentation comme machin1 et le port série ou l'équipement en face (est-ce que je dois considérer le port série dans mon système??? je demande car en modélisation objet on voit des objets ports) comme machin2
Est-ce que ça semble plus correct?
09/08/2007, 12h18
firaponte

J'ai encore une question :oops: courte, cette fois, car à force de gros texte long, je vais vous faire fuire! désolée

Est-ce qu'il y a de grosses différences entre RUP et USDP? Vous parlez de USDP, mais je n'ai pas trouvé de cours/tuto dessus, alors que sur rup, j'ai des bouquins et on trouve plus de truc

En tout cas :merci: beaucoup!!!
09/08/2007, 14h06
Joshua Beharia

me revoila

bon je vais essayer de faire bref car sinon mon projet va être à la rue... ;o)

RUP: c'est en gros USDP mais vu par Rational. Pas très interessant. Il existe de très bons bouquins sur USDP dont le principal rédiagé par les 3 gourous.
09/08/2007, 14h08
alex00

USDP, RUP, 2TUP :
cf. http://www.developpez.net/forums/sho...81&postcount=9
09/08/2007, 14h18
Joshua Beharia

explcation rapide

J'ai autant de tps qu'hier donc dézo.

Citation:

Envoyé par firaponte

Bonjour!
Je vais vous représentez un peu mieux mon projet.
En fait, dans un plus long terme, le système que je concoit (enfin que j'essaye de concevoir! ;) ) sera intégré à des systèmes plus complets par une autre personne que moi. Ces système globaux pourront en fait chacun etre particulierement différents les uns des autres au niveau de la couche de présentation et de traitement des données. Mais auront tous en commun la couche de liaison/transport, qui en fait contient le protocole que j'essaye d'implémenter.
C'est pour ça qu'il ne faut pas que j'étudie une couche supérieure trop précisément, pour que mon système puisse être intégré facilement à d'autres applications.

-> j'ai bien cerné ton problème, ne t'inquiètes pas.
A moi de te recentrer maintenant (:D ):
But: raliser un protocol de comm couche de liaison/transport
Utilisation: peut être utilisé dans pls applications non identiques

Je crois que tu n'arrives pas à différencier les UC du system englobant et ton protocol. Toi ce que tu veux réaliser, c'est une brique fonctionnelle réutlisable par pls soft. Je pense que ton prob vient du fait que tu veux trouver des UCs à ton protocol.
Avant de faire ton protocol, tu vas d'abord définir comment il va être utilisé.
Donc tu n'as pas à t'interressé aux UC du system qui va se servir de ton protocol.

Citation:

Comme il faut quand même une IHM minimale pour pouvoir tester mon système, et puis faut bien envoyer les données quelque part, je réalise une toute petite et simple couche de présentation qui est composée d'une ihm avec une texbox pour taper le message à encapsuler et envoyer, et un autre cadre dans lequel s'affiche les données arrivées et traitées par le système.
De l'autre côté de mon système, on a un port série. puisqu'il s'agit d'un protocole de communication via port serie. ce port série est relié à un équipement ou un pc qui possède lui aussi le protocole.
ca se résume par le dessin que j'ai mis. :)

Donc je sais particulièrement bien ce qu'il y a au dessus de mon protocole, mais pour mon projet je me restreint à un truc super simple, sans sgbd, ou modules plus complexes.

On s'en cogne en fait de savoir si ton protocol va être utilisé par une appli de synchro de grille-pain et bien servir à une ferme de calcul.
Ton protocole il reçoit de l'info et il la transmet.<- le principal !!!
Il peut être connecté ou déconnecté.<- c'est important aussi.. :D

Maintenant à moi de poser 2 ou 3 questions:
->qu'est-ce qu'un objet pour toi ? [general]

-> as-tu définit les limites de ton protocole ?
09/08/2007, 14h40
alex00

A la vue de ta description, c'est tout simple (volontairement rudimentaire) :

<<Acteur>> Application --- send(text) ---> Equipement

Que du texte ? pas de binaire, pas de nombres ?
Pas de reponse de l'equipement ?
S'il y a besoins d'une réponse, doit-elle être synchrone ?
Toujours a l'initiative de l'application, jamais de l'équipement ?
L'envoi de message est-t-il bloquant ?
S'il y a plusieurs équipements, peut-on faire du broadcast, du point a point ?

Tant que tu reste au niveau communication, ces questions restent sans réponse.
Les SGBD et modules plus complexes sont du "détail d'implémentation", par contre leur besoins en communication (comme ceux listes plus haut) sont des fondamentaux.

et... pourquoi ne pas re-utiliser un protocole série déjà existant ? (parce que ca ne répond pas a tel et tel besoins des applications).
09/08/2007, 14h42
firaponte

Citation:

Envoyé par Joshua Beharia

J'ai autant de tps qu'hier donc dézo.

Alors je ne peux dire que merci de me consacrer quand même un bout de ce temps! ;)

Citation:

Envoyé par Joshua Beharia

-> j'ai bien cerné ton problème, ne t'inquiètes pas.

On s'en cogne en fait de savoir si ton protocol va être utilisé par une appli de synchro de grille-pain et bien servir à une ferme de calcul.
Ton protocole il reçoit de l'info et il la transmet.<- le principal !!!

et bien ça fait plaisir de voir ecrit ce que je pense! :D

Citation:

Envoyé par Joshua Beharia

A moi de te recentrer maintenant (:D ):

Je ne demande que ça!! :)

Citation:

Envoyé par Joshua Beharia

Maintenant à moi de poser 2 ou 3 questions:
->qu'est-ce qu'un objet pour toi ? [general]

-> as-tu définit les limites de ton protocole ?

Et bien instinctivement, maintenant, après les cours d'uml que j'ai eu quand on dit objet je pense instance de classe. mais sinon concretement je vois ça comme un élément du système qui réagit a des évènement, à un état, des caractéristiques et possède des méthodes.

Après j'ai apercu sur des etudes qu'il existe le terme de objet passif/actif . j'en déduit que c'est la différence entre ceux qui peuvent effectuer des methodes et ceux qui ne peuvent que renvoyer une information sur leur état?

Pour les limites de mon protocole, oui il me semble bien les avoir cernées. en entrée un message ou un ordre d'acquittement , en sortie une trame . (et inversement) sachant qu'entre les deux le protocole, encapsule, découpe, controle, désencapsule... (je résume là sinon je dirais: gestion du multiblock, de l'adressage, des entetes et fin de messages, gestion de controle de flux...)

après c'est sûr que cette satanée connexion pourrait poser problème dans le sens ou: dans ce protocole, il n'y a pas de notion de connexion car on dit que les deux entités sont connectées en permanence, toutefois il y a une configuration a faire à l'installation (vitesse de transfert, parité, ...), donc du coup on peut assimiler ça a une connexion non?

voilà!!
09/08/2007, 14h50
firaponte

Citation:

Envoyé par alex00

A la vue de ta description, c'est tout simple (volontairement rudimentaire) :

<<Acteur>> Application --- send(text) ---> Equipement

Que du texte ? pas de binaire, pas de nombres ?
Pas de reponse de l'equipement ?
S'il y a besoins d'une réponse, doit-elle être synchrone ?
Toujours a l'initiative de l'application, jamais de l'équipement ?
L'envoi de message est-t-il bloquant ?
S'il y a plusieurs équipements, peut-on faire du broadcast, du point a point ?

Tant que tu reste au niveau communication, ces questions restent sans réponse.
Les SGBD et modules plus complexes sont du "détail d'implémentation", par contre leur besoins en communication (comme ceux listes plus haut) sont des fondamentaux.

et... pourquoi ne pas re-utiliser un protocole série déjà existant ? (parce que ca ne répond pas a tel et tel besoins des applications).

heu je suis désolée je ne suis pas sure d'avoir compris le sens de ce que tu dis. Essayes tu de me dire qu'il n'est pas optimum de ne considérer que le module de ocmmunication?
Si c'est le cas, il faut peut être que je précise que avant de me lancer dans le protocole meme j'ai quand meme passé un bon moment à étudier ce qu'il y a autour, c'est juste que je me restreint à la modélisation et l'implémentation du protocole et pas du reste pour que ce soit adaptable

sinon (cf premiers posts :) ):
Que du texte ? pas de binaire, pas de nombres ? de l'hexadecimal et des caracteres imprimables
Pas de reponse de l'equipement ? si, c'est un systeme de question réponse: une question, une reponse
S'il y a besoins d'une réponse, doit-elle être synchrone ? non asynchrone
Toujours a l'initiative de l'application, jamais de l'équipement ? non parfois c'est l'équipement qui prend l'initiative
L'envoi de message est-t-il bloquant ? il me semble puisque c'est asynchrone
S'il y a plusieurs équipements, peut-on faire du broadcast, du point a point ? c'est du multipoints : un pc pour plusieurs equipements
10/08/2007, 09h06
alex00

objet actif / passif (a mon sens) :
un objet actif peut émettre spontanément un message : en général un objet qui possède une activité (cf. machine a états "behavioral", hors PSM), objet qui possède un thread).
un objet passif ne fait que 'répondre' a des messages (rien de spontané).

Le problème de la démarche actuelle, c'est qu'elle n'est pas guidée : on se pose de questions et on essaye d'y répondre (réponse du type "il me semble").
=> tu risque de passer a cote d'éléments importants pour les couches logicielles supérieures.

Remarque : le mode asynchrone n'est pas bloquant.

Ceci étant dit :
ok, on ne parle plus des couches plus hautes.
Quelles sont les questions que tu te pose encore pour faire une première ébauche de ton protocole ?
10/08/2007, 09h14
Joshua Beharia

Objet

Citation:

Envoyé par firaponte

Et bien instinctivement, maintenant, après les cours d'uml que j'ai eu quand on dit objet je pense instance de classe.

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

Citation:

Envoyé par firaponte

mais sinon concretement je vois ça comme un élément du système qui réagit a des évènement, à un état, des caractéristiques et possède des méthodes.

9a c'est vachement mieux. On bvoit que tu as un cerveau et que tu te limites pas aux cours et bouquin !:king:

Maintenant je te donne ma définition d'un objet et on vera ce que cela soulève.
"Un objet est une entité possédant des responsabilités et un comportement."

@+

Voir 40 message(s) de cette discussion en une page