Discussion :

[megamario]

Bonjour a vous,

Pour mon projet du BTS nous avons l'analyse UML à produire. Et j'ai un petit souci avec mon diagramme de séquence qui est trop long.

D'un coté mon prof me demande d'y inclure ce qui se passe réellement mais il me dit que c'est bien trop long car du coup faudrait que j'imprime ce diagramme sur un A3 pour que se soit lisible.

N'étant pas non plus un programme extrêmement compliqué, je suppose que bien d’autres programmes se retrouvent avec une étude de séquence bien plus longue encore.

Malgré mes quelques recherches et les 2 livres que je possède je n'arrive pas bien à voir ce qu'il faut faire ou du moins la norme à respecter pour éventuellement couper le diagramme en plusieurs morceau.

Le transfert en FTP depuis le lycée c'étant mal passé je n'est pas le diagramme complet sous ma main actuellement, mais je vais le refaire ce soir si cela peut éclairer mes propos.

Dans un 1er temps je vais vous le commenté:

Pour le démarrage et initialisation du logiciel j’ai crée un diagramme à part.

Le but est de faire de l’acquisition de données (mesures ou états) sur une supervision.
L’appli (gestion relevé « GR ») puis lance l’IHM en thread.
L’IHM se paramètre suivant un fichier XML contenant les code d’appel pour les mesures et état de chaque supervisions

Séquence Acquisition:

 L’utilisateur choisi l’option acquisition.
 Il choisi la version de supervision
 L’appli charge les mesures et état disponible pour cette supervision (XML)
 Il sélectionne les mesures ou état qu’il a besoin. (Mini 1 mesure)
 Il sélectionne sur si une interruption sera programmer, ou pas, sur une ou plusieurs des mesures ou état sélectionnées.
 Il sélectionne les courbes des mesures à afficher 1 min à 4 max.
 Il sélectionne la durée maxi de l’acquisition ainsi que la période de mesures.
 Il sélectionne le type de connexion (Ethernet ou port COM) ainsi que les paramètres associés. Et le Nom de la référence mesurée. Et s’il y a une sauvegarde à faire ou pas
 Il demande la connexion.

Pendant tout ce temps, le thread principal « GR » fait un pooling sur un tableau de booléen que l’IHM rempli en fonction des besoins des besoins qu’elle a ou des attentes. (Sont état) Le tableau se nomme EtatIHM.

 Le GR récupère le tableau lui indiquant qu’il y a une connexion à faire.
 Le GR récupère les informations qui lui sont nécessaires : Get...() : ...
o Les paramètres de COM (tableau de String)
o Le Nom (string)
o Le Dictionnaire contenant toutes les infos pour récupérer les mesures et état ainsi que les façons de les traités.

J’en ai peut être oublié..

 Le GR crée un objet Communication en lui envoyant le paramètre de COM. Qu’il mémorise.
 Communication crée soit l’Objet Ethernet ou COM.
 Communication écris dans l’un ou l’autre les Login et doit gérer les erreurs.
 Communication retour l’état de connexion.
 Le GR envoie toute les commandes des mesures à Communication (sauf celle déjà envoyer dans cette cession (le même code d’appel pouvant servir a avoir plusieurs information dans la trame de retour).
 Communication lui retourne les trames.
 GR traite les Trame pour y récupérer les informations.
 Une fois toute les informations traité GR renvoie toute mes mesures a l’IHM grâce au delegate..
 L’utilisateur doit examiner les mesures pour voir s’il n’y a pas d’incohérence.
 L’utilisateur lance l’acquisition.
 GR examine EtatIHM et lance l’acquisition.
 Rebelote pour l’envoie des trames et la réception mais cette fois en boucle toute les périodes jusqu'à la fin ou d’une interruption programmé.
 Gr enregistre ou pas les données par l’intermédiaire d’un buffer de 5 périodes.
o Il crée un Objet CSV. (thread)
o Il crée un Objet SGBD si elle est disponible(thread)
 Fin de la séquence à la fin du temps ou d’une interruption voir de l’utilisateur. On sauvegarde les restes du buffer s’il y a encore des lignes de rempli
 En cas d’arrêt de l’utilisateur, on demande à l’utilisateur s’il veut ou pas supprimer les données enregistrés (il se peut que l’arrêt soit du a des erreurs de mesure donc inutile de garder les données).


Voila, je vais essayer de vous refaire mon diagramme se soir, J’en ai une partie mais il n’est pas complet. Mais si déjà vous pouviez me dire comment procéder se serai sympa.

[megamario]

Voila le schéma, je doit pas être loin de ce que j'ai effectué.



Comme vous pouvez le constater, c'est impossible à mettre sur un format A4.

D'autre part je suis preneur de toute infos concernant ce diagramme, si j'ai des erreur, des maladresses, des choses à représente différemment.

Merci

[hegros]

Il n'y a pas d'autres choix que de découper la question est selon quel critère et cela dépend de à qui s'adresse la présentation du schéma.

Pour des personnes fonctionnel on pourrait déjà faire sauter toute la partie de sauvergarde et pour des personnes du technique (genre administrateur base de données) on ne pourrait laisser que la partie sauvegarde.


On peut découper toujours en plus petit même si cela doit ajouter de nouvelles classes pour avoir de plus petit diagramme et ainsi opter pour la sélection de séquences en fonction de à qui cela s'adresse (cela change aussi la conception mais à priori en mieux)

[megamario]

Par exemple est qu'il est correct de faire un diagramme coupé en plusieurs parties:

J’imaginais de faire un diagramme concernant la préparation de l'acquisition.
-> Jusqu'à la connexion
-> Puis un autre diagramme représentant le reste mais avec les classes Communication représentées mais pas détaillées ainsi que les classes de sauvegarde pas détaillés non plus.
-> Du coup je représente 2 autres diagrammes avec cette fois le détail de la partie connexion et l'autre le détaillé de la partie sauvegarde.

Certes ces 2 derniers diagrammes ne seront pas bien conséquents mais je pense que se serait plus clair.

Reste à savoir si c'est une pratique acceptable et si c'est comme cela qu'il faut faire.

[megamario]

Personne pourrais me confirmer, se serais sympa, j'ai une revue de projet à présente la semaine prochaine. A défaut d'être au top je voudrais pas être hors du coup.

[bruno_pages]

j'arrive sans doute un peu tard, mais pour n'aborder que la partie graphique du problème un diagramme de séquence peut en en référencer d'autres via des combined fragment de type ref

[megamario]

Bonjour à vous,

je vous remercie, effectivement j'avais trouvé les Ref mais j'ai trouvé sa dans des livres.


Une autre petite question si quelqu'un passe par la. Il faut indiquer les nom de méthode avec les paramètres (entrées et retour) ou juste les nom de méthode? J'ai les 2 présentés sur 2 livres. Et j'ai vu effectivement des différences aussi sur le net.

A l'image de mon diagramme bien long que j'ai découpé en 3 parties (Préparation à l'acquisition, La connexion, L'acquisition), est-ce que l'on peut le considérer comme correct au niveau de l'écriture?

[bruno_pages]

Bonjour,

Il faut indiquer les nom de méthode avec les paramètres (entrées et retour) ou juste les nom de méthode?

cela dépend des cas, la seule règle 'absolue' est que le diagramme soit lisible et utile c.a.d. apporte de l'information.

En cas de surcharge de méthode les paramètres différentient les cas.

La même question se pose dans le cas des autres diagrammes, par exemple les diagrammes de classe.

indiquer les arguments (et non les paramètres) dans un diagramme de séquence peut également être utile dans certains cas, soit à la place des paramètres si votre outil le permet, sinon via une note

A l'image de mon diagramme bien long que j'ai découpé en 3 parties (Préparation à l'acquisition, La connexion, L'acquisition), est-ce que l'on peut le considérer comme correct au niveau de l'écriture?

difficile de répondre sans voir le diagramme

[megamario]

Bonjour,

en ce qui concerne mon diagramme de séquence à découper, il est un peut plus haut, mais voici mon diagramme de classe, je me suis ocuper de la partie IHM et la classe XML est bien grosse



Merci

[bruno_pages]

Bonjour,

en ce qui concerne mon diagramme de séquence à découper, il est un peut plus haut

je parlais du diagramme après découpe , mais c'est pas grave

J'ai du mal à situer le niveau auquel se trouve ce diagramme.
La présence de l'acteur pourrait faire penser à un diagramme d'analyse extrait des cas d'utilisation, mais ce qui est plus à droite contredit cela, par exemple XML est déjà un choix de conception.
De même il ne s'agit pas d'un diagramme de conception car XML et IHM (au moins) ne sont certainement pas des classes, leur nom doit être changé. Les opération représentées ne sont pas toujours celles du diagramme de classes (mais peut être qu'il n'ont pas le même age/niveau de maturité et qu'il y a donc un décalage entre eux ?). Le nom et le rôle apparent des classes fait plus penser au besoin qu'à une implémentation effective.

Quand on fait un diagramme il faut qu'il est un but, quel est donc le but de ce diagramme ?, que veut-il montrer ?

malgré tout attention de séparer ce qui est du domaine de l'affichage et ce qui est du domaine des traitement/données, un affichage ne fait qu'afficher des données et (indirectement) provoqué des actions. Il ne peut donc pas y avoir une classe faisant tout.

quelques remarques :

• il faut couper les barres d'activité en plusieurs, et donc au moins tout nouveau message envoyé par l'acteur introduit une nouvelle barre distincte de la précédente
• je pense que pas mal de retour n'ont pas à être indiqué, on sait que getX retourne un X
• les messages 3 et 4 sont les même mais ne retournent pas la même chose, est-ce que 3 ne devrait pas être lister_mesures et 4 lister_etats ?
• il y a plusieurs actions identiques (par exemple 7, 9 et 11) issues de commandes différentes (6, 8 et 10), les actions devraient être plus précise, sinon il n'y a pas de raison que l'implémentation des actions ne soient pas exactement la même ... ou alors le diagramme ne sert pas à grand chose puisqu'il ne faut pas le lire pour savoir quoi faire
• il semble aussi bizarre que le fait de choisir (par exemple 6) aboutisse à une modification des dictionnaires eux même (par exemple 7), il s'agirait plutôt de mémoriser les informations pour le futur affichage.
• qu'est ce qui déclenche 17) ?
• j'ai du mal à croire qu'ethernet soit une classe, de même pour port com, est-il utile de distinguer ces deux cas ici (toujours le problème du niveau diagramme, il est soit trop précis soit pas assez suivant le niveau choisi)
• qu'est-ce qui fait que 40) est forcément après 39) ? il doit y avoir quelque chose 'empêchant' ou ne proposant pas avant à l'acteur de faire 40) trop tôt
• c'est un détail, mais plutôt que d'utiliser un fragment alt avec une seule alternative, il est plus clair d'utiliser un fragment opt
• le positionnement vertical de 59) et 60) laisse à penser qu'ils sont concurrents (et de ce fait une IHM est souvent asynchrone), mais il n'y a que des messages synchrone

voici mon diagramme de classe, je me suis ocuper de la partie IHM et la classe XML est bien grosse

je ne vais pas tout balayer, un peu comme avant je me demande si ce sont des 'vraies' classes issue de la conception ou des 'fausses' classes issues d'une première analyse pour savoir ce qui doit être fait (et non véritablement 'comment' le faire), plus quelques remarques rapides :

• XML ne toujours pas une classe ou s'appeler ainsi
• logout est un attribut ?
• Collection est bizarre, déjà c'est à priori une classe paramétrée (générique, template), on manipule des collections de quelque chose. La chose n'a que des attributs, pas d'opération genre ajouter, retirer, chercher etc. Ou alors il y a un problème de nommage et collection représente en fait un élément ?
• il faut nommer les rôles et mettre des multiplicités, je doute que la multiplicité soit toujours de 1
• je doute aussi que toutes les relations soient des agrégations, si cela n'est pas encore su il est à priori préférable d'utiliser des relations simples (mais c'est peut être à cause de l'outil ?)
• une classe comme langue ne sert sans doute pas seulement à être chargée, on va sans doute lui demander de retourner les mots/phrases à partir d'un identificateur ?

je pense que cela donne déjà du grain à moudre

attention cependant à ne pas prendre forcément ce que je dis au pied de la lettre, des remarques peuvent tout simplement venir du fait que j'ai mal compris

[megamario]

Bonsoir, un grand merci déjà pour avoir vraiment détaillé votre point de vu, je vais me servir immédiatement de vos conseils.

je vous répond en détaille dés que j'ai fini m'a revue de projet car je suis interrogé demain matin 8 h donc c'est chaud.

En tout cas effectivement pas mal de chose sont à revoir mais j'ai aussi des données à vous apporter.

En espérant pas finir trop tard, je vous tiens au courant le plutôt possible.