Discussion :

[firaponte]

Bonjour!!

Pourriez vous me donner un petit coup de pouce s'il vous plait, je tourne un peu en rond!

Je travaille actuellement sur la modélisation uml d'un logiciel simulant un protocole de communication.
Ce protocole permet à deux entités voir plus de communiquer avec toujours un maitre et un/plusieurs esclave(s) et se situe au niveau des couches de liaison et reseau (2 et 3).

Mon premier soucis est du aux cas d'utilisation. Il semble qu'un acteur doit être extérieur du système qu'on veut devellopper. A partir de là, les acteurs de mon modele seront soit l'opérateur soit le poste qui communique avec mon terminal. Et comme un cas d'utilisation doit forcément etre déclenché par un acteur (si j' ai bien compris) , il ne reste comme cas d'utilisation valables que ce qui est relatif à l'envoi et la reception de messages.
Est-ce que cela signifie que dès qu'on modelise un protocole de communication, on se restreint à seulement 2 use case? Il me semble que c'est vraiment peu car ça reste très vague!

Pourriez vous me donner votre avis sur ce que je pense faire
Dans le cadre de mon protocole, chaque entite qui utilise le protocole peut envoyer deux types de messages: un message informatif, ou un message qui attend une reponse appellé message de commande. Il peut aussi recevoir un message. Cette distinction est importante car en fonction du type de message, il ne prepare pas la trame à envoyer de la même maniere. Chaque trame possédant un debut de message et fin de message propre au type de message.
Je pensais donc faire trois use cases principaux:
-commander
-recueillir une information
-diffuser une information

Si je fais comme ça, j'ai ensuite un probleme avec le mode de fonctionnement du système. le protocole peut etre utilisé pour trois choses: configurer une entité avec laquelle il communique, assurer la maintenance de cette entité ou le mode de fonctionnement normal.

Est-ce qu'alors je dois considerer ces trois modes comme des relations extend de chacun des trois premiers cas d'utilisation (commander, recueillir et diffuser). ou au contraire dire que ces 3 modes correspondent aux cas d'utilisation? Ou alors, autre possibilité, je reste sur mes 3 use cases commander, recueillir et diffuser et je considere comme scenario nominal le fonctionnement normal et comme scenarios alternatifs les deux autres modes.

Disons que je tourne un peu en rond et j'ai un peu peur d'etre totalement à coté de la plaque alors n'hésitez surtout pas à me le dire que je puisse rebondir comme il faut .

Comme dans mon programme je n'ai que l'utilisateur du terminal et son interlocuteur, j'en déduit que tout ce qui est constitution, controle de la trame ne rentre pas dans les use cases car n'est géré que par le programme.

J'ai cherché des infos sur la modelisation uml appliquée aux protocoles de communication, mais ya pas grand chose! Meme sur le forum j'ai pas trouvé. Si jamais vous savez où je peux trouvez de la documentation ou des exemples propres à ça je prend volontier!!.

J'espère que c'est compréhensif!!
Merciiiii!!!

[alex00]

Bonjour,

Il me semble que les 3 cas d'utilisations que tu propses ("commander", "recueillir" et "diffuser") sont tres abstraits (ils manquent de sens informatif pour le lecteur).
D'autant plus que pour "recueillir", il a d'abord fallut qu'un acteur "diffuse".
Ensuite, meme si c'est en fonctionnement maitre-esclave, il manque la distinction point-a-point ou broadcast.

Je te proposes de prendre le probleme dans l'autre sens :
a quoi sert ce protocole de communication ?
1) a "configurer des machins",
2) a "gerer le fonctionnement normal de machins",
3) a "faire des operations de maintenances sur des machins".
J'ajouterai meme un quatrieme (qui n'a peut-etre pas de sens) :
4) a "connecter des machins" (si on ne peut rien faire en mode deconnecte, cf. distinction TCP vs. UDP).
La notion de machin prend ici tout son sens.
Les acteurs sont probablements "(machin ?) maitre" et "machin esclave".

Tu peux aussi voir ces cas d'utilisations comme des processus metiers, decrits par un diagramme d'activite (avec les acteurs dans les swin-lanes).

Ensuite, les distinctions "commande" et "diffusion + recueille" ne sont plus que des template structurant la description des messages echanges.

Qu'en penses-tu ?

Alex

[firaponte]

Bonjour!

Merci beaucoup pour la réponse!!

C'est vrai que faire les use case que tu proposes sont plus orientés besoin je pense et moins fonctionnel.
Par contre je ne m'étais pas posé la question de la connection (a tord surement) . et c'est une partie importante je pense car il s'agit d'une communication série donc il doit y avoir une étape de connection obligatoire.
Le role premier du programme étant de permettre à deux "machins" de communiquer, l'etablissement de la connection est primordiale.
Ceci dit, cette étape est aussi une étape de chacun des 3 premies cas d'utilisations proposés. Car pour pouvoir configurer les "machins" faut déja s'y connecter, pour gerer le fonctionnement normal aussi, etc.... Du coup est-ce qu'on ne peut pas voir ca comme une relation includ de chaque cas.
Oui mais alors, si on integre cette étape, on peut aussi integrer les autres etapes de chaque cas: preparation de la trame, controles, envoi sur les ports. Donc je ne suis pas sure que ce soit un cas d'utilisation, mais bon je n'ai pas l'expérience suffisante pour juger donc peut-être est- ce ce qui se fait d'habitude. qu'en penses tu?

Ensuite, meme si c'est en fonctionnement maitre-esclave, il manque la distinction point-a-point ou broadcast.

C'est vrai que je n'en ai pas encore tenu compte. ici ca peut être les deux. Mais je dois le faire figurer au niveau des cas d'utilisation? Je ne vois pas trop comment gérer ca à vrai dire.

En fait tu m'a fait réaliser que je ne considérais surement pas la bonne chose. Disons qu'à chaque fois je pense "message echangé" et du coup j'organise mon analyse autour des actions qui sont faites sur un message. Peut -etre qu'il serait préférable de penser "session d'échange" , etant donné que c'est un protocole de communication, ce qui permettrai effectivement de mieux justifier les cas d'utilisations en fonction du mode de fonctionnement.

En tout cas merci pour l'aide!!

ps: sympa l'utilisation de "machins"

[firaponte]

Ceci dit, après reflexion, je craint de ne mélanger les besoins liés aux couches basses de ceux liés aux couches hautes. Je m'explique: si après je dois modéliser la couche utilisateur, dans laquelle l'utilisateur rentrera des informations qui seront traitées, controlées, envoyées ou recues par la couche basse, si je choisis les cas d'utilisation configurer le ma chin, assurer le fonctionnement normal... ce sera les même cas d'utilisation pour les deux couches. Est-ce normal?
Parce que finalement, ces cas d'utilisation sont les besoins terminaux du soft global, mais pour l'instant je ne m'occupe que des couches basses qui elles ne s'occupent que de transmettre(envoyer ou recevoir), controler(adressage, structure du message, integrité...) , et mettre en forme (en tete, fin de message, adressage, decoupage en paquets, numerotation des paquets...)un datagramme édité par les couches supérieures. olala je tourne en rond non? est-ce que ce ne serait pas des cas d'utilisation plus pertinants?

[alex00]

Bonjour,

Le role premier du programme étant de permettre à deux "machins" de communiquer, l'etablissement de la connection est primordiale.

Il y a deja eu beaucoup de discussions sur ce sujet : include vs. extend dans le cas d'utilisation du type "se connecter a l'appli".
Pour ma part, je prefere un cas d'utilisation "etre connecte" a part (secondaire si c'est un besoins uniquement technique et non pas un besoins fonctionnel), et une pre-condition "connexion etablie" a chacun des 3 autres.

mais pour l'instant je ne m'occupe que des couches basses

Transmissions et mises en formes (en-tete, ...) ne sont qu'une suite d'appels de fonctions dans (a l'interieur) des cas d'utilisations. Ce ne sont que des fonctions (granularite tres fine).
Si tu t'occuppes des couches basses sans tenir compte des besoins fonctionnels, tu risque de rater des points essentiels.
=> Au mieux un "machin" a un nom fonctionnel (ex. "visseur de bouchon sur une bouteille"),
au pire, un "machin" reste completement abstrait, sans ligne directrice pour ton travail (or etre "guide par les cas d'utilisations" ou "implementer les users-stories" fait partie des bonnes pratiques actuelles).
Entre les deux, un "machin" est "la memoire ou le port d'E/S d'un automate (ou ce qui te concerne, ex une appli cliente)", ce qui reste assez flou quand meme mais peut etre suffisant (y'a deja des caracteristiques d'une ou plusieurs sortes d'"automate", ou d'objets manipules par l'appli cliente).

Alex.

[alex00]

Bonjour,

Au cas ou je n'ai pas ete assez clair :
quand je parle d'etre guide par les cas d'utilisations ou les user-stories, je parle de ceux du systeme global, pas du composant 'protocole de communication'.
A partir de ceux-la, on peut deriver ceux du protocole.
Question a 100 sous que seuls les cas d'utilisation du niveau systeme peuvent repondre : un client (esclave) peut-il initialiser une sequence de communication (comme emetre une alarme ) ?

Alex.

[firaponte]

Bonjour,

Question a 100 sous que seuls les cas d'utilisation du niveau systeme peuvent repondre : un client (esclave) peut-il initialiser une sequence de communication (comme emetre une alarme ) ?

Alex.

Oui il peut et dans ce cas devient maitre. chaque machin peut être soit maître soit esclave en fonction de qui initie la session.

Sinon j'ai modélisé par 4 cas d'utilisation dont un connexion. Est ce que ce cas d'utilisation peut reprendre ce qui est relatif à l'établissement de la connexion, l'ouverture des ports, le paramétrage de la connexion(vitesse, parité, etc..). C'est bien comme ça qu'il faut le comprendre?

Il y a deja eu beaucoup de discussions sur ce sujet : include vs. extend dans le cas d'utilisation du type "se connecter a l'appli".

Par contre ça j'ai pas trouvé de discussion la dessus. c'est sur developpez?

[firaponte]

Voilà mon diagramme use case. peux tu me dire si c'est correct?

Merciiii!!

[alex00]

Pour le diagramme :
le plus correct est de mettre des relations d'extensions :
Configurer un equipement --- <<extends>> ---> Connecter.
(ce qui revient grosso-modo a mettre une precondition dans chacun des 3 uc pertinents).

Et les relations simples (trait sans fleche) entre les acteurs et chacun des uc.
A la limite une fleche des uc vers l'esclave (pas UML dans la norme, mais c'est une habitude qui signifie que le maitre est le declencheur de l'uc, et l'esclave est sollicite par l' uc).

Reste le plus important et le plus significatif : detailler les uc (par exemple par des scenarii "les plus probables", puis "plus rare mais avec un cas particulier a prendre en compte").

Detail de Connecter :
- <detail de la procedure de connexion
- point d'extension : connexion etablie
- <detail de la procedure de deconnexion>
cas particulier :
- plantage de la connexion n'importe quand.

Detail de Configurer un equipement :
- 1 evenement declencheur (ex: message "setMode(configuration)") (il se peut que ce soit plus simple a decrire avec plusieurs evenements declencheurs).
- suite des messages echanges (plusieurs variantes car il y a plusieurs configurations possibles), avec des retours OK systematiques
cas particuliers :
- des retours KO (ex: parametre non modifiable),
- ou plantage connexion.

Pour les 3 uc significatifs : il est plus important de decrire des morceaux coherents de sequences, ou simplement l'echange d'un seul message, meme sans diagramme, que de faire un gros volume ou l'information serait repetee ou trop diluee.

Alex

[firaponte]

Encore une fois merci beaucoup!

J'ai mis à jour le diagramme des cas d'utilisation en prenant en compte tes remarques.

[firaponte]

En ce qui concerne le détail des uc, j'ai commencé à le faire de manière textuelle

Pour les 3 uc significatifs : il est plus important de decrire des morceaux coherents de sequences, ou simplement l'echange d'un seul message, meme sans diagramme, que de faire un gros volume ou l'information serait repetee ou trop diluee.

Ce que tu sous entend par là, c'est qu'il vaut mieux rester encore ici à un niveau pas très détaillé pour éviter les redondance? Ne décrire que les grandes lignes d'une session, d'échange et les différentes variantes possibles?
Et est-ce que la gestion du découpage en paquets ou multibloc peut être considérée comme un cas particulier?

Bon allez je m'y remets!

en tout cas merci!!

[alex00]

Bonjour,

Pour le diagramme, inspire toi de celui-ci (notamment pour les fleches) :
http://www.doughughes.net/images/UML...e/image009.gif

Pour la description des UC, fait comme tu veux, pour que ca te soit facile a ecrire, et si possible sans copier-coller pour que ce soit facile (pas trop fastidieu) a lire. Pour cela, a toi de trouver ton style.

bon courage,
Alex

[firaponte]

Bonjour!

j'ai refait mon uc en prenant en compte tes remarques. merci!
Par contre le fait que "Etre connecté" soit une précondition , est-ce qu'on peut le faire apparaitre sur le diagramme ou ça n'est mentionné que dans la description textuelle?

[alex00]

Sur le schema : la relation extends est dans l'autre sens (de "Configurer" vers "Etre connecter"). Le schema se lit alors 'Configurer etend Etre connecter'.

2 choix :
- soit tu utilises la relation extends,
- soit tu utilises la precondition.
Ce qui, dans le fond, revient au meme.
Sur la forme, la precondition est en generale plus facilement comprehensible que la relation extends (notamment pour un lecteur qui n'a pas forcement de notions 'approfondies' en UML).

Alex

[alex00]

Toujours sur le schema :
la relation d'agregation entre acteurs n'a rien a faire la, tout au plus sur un diagramme de classes separe.
De plus, est-tu sur que ce n'est pas tout simplement une association ?

[firaponte]

Bonjour!
En fait j'ai mis un lien d'agrégation car il s'agit d'une relation maître esclave et que en général, c l'exemple type de l'agrégation.
Il me semblait que l'agrégation représentait le fait qu'une classe joue un rôle plus fort que l'autre ce qui est le cas dans une relation maître esclave. Je me trompe??
Donc si j'ai bien compris, de toute manière, les relations entre acteurs ne doivent pas apparaitre dans le diagramme des cas d'utilisation. Pourtant on en voit souvent. ou alors il faut juste mettre une association sans préciser?

Merci pour la remarque sur le sens du extend. si je choisis la précondition, je dois la faire apparaitre sur le diagramme dans un bloc type commentaire? ou juste dans la description syntaxique des cas d'utilisation?

[alex00]

Bonjour,

La seule relation entre acteurs dans un diagramme d'UC est la relation d'heritage.

Dans ton diagramme de classe, je pense plutot que 0..1 Machin 'maitre' --- pilote ---> * Machin(s) 'esclaves'.
(classe Machin, roles 'maitre' et esclaves, relation 'pilote', et les cardinalites).

par exemple...

Mis a plat sur les roles :
2 classes '<< Actor>> Maitre' et '<< Actor>> Esclave', et toujours la relation pilote et les meme cardinalites.


(et oui, les acteurs jouent des roles...)
Alex

[firaponte]

En détaillant les scenarios, je me trouve face à un autre problème. et j'ai du mal à trouver quelle serait la meilleure solution.

La gestion du mode esclave m'embete. je m'explique.Pour un cas d'utilisation donné, comme le mode maintenance et tests, j'ai essayé plusieurs configurations différentes:
1)- le scénario nominal est session simple sans préavis avec message multibloc en mode maitre .
- un scenario alternatif avec session en mode esclave
2) -Le scenario nominal est : envoi d'une instruction
-un scenario alternatif est : diffusion d'une information
-un deuxieme scenario alternatif est : Reception

l'avantage du choix 1 est que l'on considere une session entiere.
et que comme le mode esclave a un comportement vraimen differen du module maitre, le fait de lui attribuer un scenario simplifie la description.
l'inconvénient: le scénario nominal va donner lieu a de nombreux enchainements alternatifs pour gérer les différentes configurations possible, et ça me semble pas évident de gérer les imbrications. (préavis ou pas, message court ou long, type de message,...)

pour le choix 2, l'avantage principal est que la répartition des scénarios permet de gérer plus facilement les différentes config possibles. Et il me semble (mais la je ne suis pas sure) que la description est plus orientée "métier" ce qui est mieux.
l'inconvenient principal est du au fait que l'on considère un envoi de trame et pas une session. Du coup l'enchainement entre les scenario n'est pas bien mis en évidence (ou alors par ajout de "élément déclencheur" pour chaque scénario) .

Qu'en penses tu?

[firaponte]

Mis a plat sur les roles :
2 classes '<< Actor>> Maitre' et '<< Actor>> Esclave', et toujours la relation pilote et les meme cardinalites.

Oui c'est sur que ça semble plus approprié! merci!

j'étais en train d'écrire le post précédent quand tu répondais!

[alex00]

Entre tes options 1) et 2), je ne peux pas te repondre simplement.
Je sais juste que pour ce genre d'applications, on risque de se retrouver avec une multitude de diagrammes de sequences, ca prend de la place mais ce n'est pas optimal.

La seule regle qui compte : que ce soit lisible. Il faut donc que tu penses au lecteur.

Tu peux essayer dans un premier temps d'etre guide par le metier, et s'il le faut (si beaucoup de scenarii se ressemblent : alors pourquoi pas les decrire sous forme de "templates de communication"), completer par des table(aux) de references de chacunes des fonctions.

Alex