Problème de liste

Bonjour,

Toujours dans le cadre de mon projet de gestion d'alarmes, j'ai un souci pour réaliser mon DS (cf. pièce jointe):

J'ai la classe "Gestion des Alarmes" qui fait appel à la méthode "consigner" de la classe "Equipement" avec, comme paramètre, la liste des Equipements à consigner.
Cette méthode passe en revue l'ensemble des équipements et lorsqu'elle reconnait un repère d'équipements, elle consigne l'équipement. J'aimerais qu'elle fasse ensuite, pour chacun de ces équipements repérés :
- la liste des alarmes à désactiver
- appel à la méthode inhiber de la classe "alarme".

Comment puis-je représenter cela? Dans mon DS, je pense qu'on ne comprend pas que l'on souhaite inhiber les alarmes liées aux équipements consignés juste avant. Si je mets la liste des équipements à consigner en paramètre de la méthode "inhiber", je pense qu'on ne comprend pas que le traitement est récursif (c.a.d pour chaque équipement consigné-> création liste alarmes -> inhibition liste alarmes)
et je ne peux pas faire une méthode "inhiber_alarmes" puisque que l'attribut booléen "estInhibé" de la classe "Alarme" est privé...

Merci de votre aide!
La Pomme

Il s'agit d'un problème de récursivité.. L'algorithme est défini comme suit :
à chaque fois qu'un repère faisant partie du tableau passé en paramètre est atteint, l'équipement est consigné, la liste de ses alarmes associées est construite, puis celles-ci sont inhibées.
Le tout est de représenter ces fonction récursives sur un DS!!

Merci de votre aide!
La Pomme

bonjour,

j'avoue que je ne vois pas ou il y a des récursions
je vois par contre des itérations sur des listes/tableaux et cela peut se représenter via des fragments "loop"

Bonsoir,


Voici mes derniers diagrammes de classes et séquences. Pouvez-vous me donner vos impressions?

Dans le DS, je n'ai pas trouvé comment :
- écrire la condition autrement que par l'intermédiaire d'une note
- faire apparaitre le stéréotype "Interface" de Consignations

Merci,
La Pomme.

Citation:

---

Envoyé par La Pomme

- écrire la condition autrement que par l'intermédiaire d'une note

---

les conditions s'écrivent via un texte (bouton 'abc')

sinon le cas 'else' n'est pas bon, il ne faut pas créer un autre fragment, il faut 'couper' le fragment 'alt' en autant de sous cas que nécessaires en faisant un clic droit sur le fragment et choisissant 'add separator' autant de fois que necessaire (puis en déplaçant le trait de séparation verticalement à chaque fois sinon ils sont tous les uns sur les autres et on pense qu'il n'y en a qu'un). Dans le cas présent il ne se passe rien dans le cas 'else', il est donc préférable de remplacer le fragment 'alt' par 'opt'

Citation:

---

- faire apparaitre le stéréotype "Interface" de Consignations

---

ce n'est pas possible au niveau d'une instance/ligne de vie

Concernant le diagramme de classe, à quoi correspondent les relations entre les classes ? car il n'y a pas de nom de rôle

Bonsoir,

Citation:

---

sinon le cas 'else' n'est pas bon, il ne faut pas créer un autre fragment, il faut 'couper' le fragment 'alt' en autant de sous cas que nécessaires en faisant un clic droit sur le fragment et choisissant 'add separator' autant de fois que necessaire (puis en déplaçant le trait de séparation verticalement à chaque fois sinon ils sont tous les uns sur les autres et on pense qu'il n'y en a qu'un). Dans le cas présent il ne se passe rien dans le cas 'else', il est donc préférable de remplacer le fragment 'alt' par 'opt'

---

Pour ce qui est de ma boucle, voici mon algorithme :
Pour chaque équipement de la base de données, on regarde si le repère est inclus dans liste_des_consignations :
Si oui, il est consigné, la liste des alarmes liées est créée et les alarmes de la liste sont inhibées.
Si non, on passe à l'équipement de la BD suivant.
C'est ce que je voulais représenter avec la note else "suivant" dans mon DS.
'opt' pour option?

Je n'ai pas trouvé de nom satisfaisant pour nommer les deux associations entre "Gestion des consignations" et "alarme" et "équipement" . J'avais pensé à "concerne" . Qu'en pensez-vous?

Merci d'avance,
La Pomme.

Bonsoir,

Citation:

---

Envoyé par La Pomme

Pour chaque équipement de la base de données

---

déjà là il faut un fragment 'loop'

Citation:

---

Si oui, il est consigné, la liste des alarmes liées est créée et les alarmes de la liste sont inhibées.
Si non, on passe à l'équipement de la BD suivant.
C'est ce que je voulais représenter avec la note else "suivant" dans mon DS.

---

ok, j'avais dit cela car le cas 'else' était vide
il faut donc ajouter un séparateur pour séparer le car 'if' du cas 'else (pour ce dernier pas besoin de mettre d'expression, par défaut c'est 'else)

Citation:

---

'opt' pour option?

---

oui, c'est donc un 'alt' avec un seul compartiment, mais un 'opt' est plus clair

Citation:

---

Je n'ai pas trouvé de nom satisfaisant pour nommer les deux associations entre "Gestion des consignations" et "alarme" et "équipement" . J'avais pensé à "concerne" . Qu'en pensez-vous?

---

je ne parle pas de nom de relation, mais de nom de rôle (c.a.d. nom d'attribut supportant la relation)

généralement le fait qu'il soit difficile de trouver un nom indique un problème ...

Bonjour,

Merci pour vos réponses Bruno.
J'ai encore une question concernant la boucle que je dois représenter :
Dans mon algorithme, chaque équipement de la BD est passé en revue (d'où le "loop"). Si il est dans mon tableau, je le consigne. Sinon, je passe à l'équipement suivant de la BD. Comment représenter ce passage à l'équipement suivant dans mon DS? Je ne vois pas quoi écrire dans mon 'else' et si je ne mets pas de 'else', je ne sais pas si le passage à l'équipement suivant est implicite...

Merci d'avance,
La Pomme.

le langage naturel n'étant pas clair je ne suis pas sure de comprendre

Si il est dans mon tableau, je le consigne et après on passe à l'élément suivant aussi dans ce cas ou on sort de la boucle de parcours des éléments de la BD ?

ne pas hésiter à écrire la chose dans un pseudo langage de programmation pour que les choses soient claires ... ;)

Bonjour,


Dans mon DS, je représente l'appel à des méthodes internes de la classe "Equipement" qui se déclenchent après la réception du message "consigner" de la part de la classe "Gestion_Consignations". Est-ce que la représentation que j'ai adoptée sous BoUML est bonne? Je n'arrive pas à copier la flèche récursive dans la barre parent.

Merci d'avance,

La Pomme.

Bonjour,

ton diagramme indique que l'operation consigner appelle l'operation appartient_a... qui appelle l'operation effectuer_consignation

c'est sans doute ce que tu voulais

> Je n'arrive pas à copier la flèche récursive dans la barre parent.

sauf si tu passes en mode 'flat', tout appel produit une nouvelle barre d'activite, et c'est normal

oui, c'est bien ce que je souhaitais représenter. Merci :D

Comment passe-t-on en mode 'flat' sous BoUML?

Merci,

La Pomme.

Citation:

---

Envoyé par La Pomme

Comment passe-t-on en mode 'flat' sous BoUML?

---

en lisant la doc et recherchant le mot flat (paragraphe Picture menu) :mouarf:

j'ai essayé de faire cela avec bouml,soyez indulgent c'est mon premier ds :-)

tu remarqueras un message asynchrone de l'application cliente, le reste si besoin je peux commenter

Bonjour,

le diagramme ne vas pas :
- la barre d'activité du create doit s'arréter avant la reception du message suivant
- cf une précédente réponse l'utilisation du fragment else est a remplacer

[edit]le fragment else n'existe pas, je l'avais introduit par erreur[/edit]

ok voila quelques corrections

Il va vraiment falloir aller lire de la doc concernant les diagrammes de séquence, en particulier en ce qui concerne les barres d'activité ;)

Bref coté GestionnaireConsignation et DAO il ne doit y avoir qu'une unique barre d'activité,

Sinon je suis étonné que getListEquipment créé les Equipements

Citation:

---

Envoyé par bruno_pages

Il va vraiment falloir aller lire de la doc concernant les diagrammes de séquence, en particulier en ce qui concerne les barres d'activité ;)

---

C'est plus ou moins prévu en tout cas cela ne serait tarder parce que ton logiciel me plaît bien :P D'ailleurs je me demandais si tu avais utilisé UML pour le concevoir :mrgreen:

Citation:

---

Sinon je suis étonné que getListEquipment créé les Equipements

---

Oui c'est plus ou moins un choix pour séparer les couches cela pourrait être GestionnaireConsignation qui crée les equipements.

En vue d'implémentation la méthode (getListEquipment de DAO) retourne un vector (le loop avec le create permet de le construire).

listeEquipement est donc le vector renvoyé par DAO à GestionnaireConsignation.

GestionnaireConsignation fait un loop sur ce vector et appelle la méthode pour effectuer effectuerConsignation pour réaliser la consignation.

voilà en espérant que ces commentaires t'éclaireront un peu plus sur ce que j'ai voulu faire.

Citation:

---

Envoyé par hegros

je me demandais si tu avais utilisé UML pour le concevoir :mrgreen:

---

et non, pour les développements personnels je n'utilise pas UML, je suis trop dinosaure pour cela :mouarf:

Citation:

---

En vue d'implémentation la méthode (getListEquipment de DAO) retourne un vector (le loop avec le create permet de le construire).

listeEquipement est donc le vector renvoyé par DAO à GestionnaireConsignation.

GestionnaireConsignation fait un loop sur ce vector et appelle la méthode pour effectuer effectuerConsignation pour réaliser la consignation.

---

oui, j'avais bien compris cela, ce qui me gène c'est l'appellation, un get qui construit autant de chose cela me gène, ce qui n'aurait pas été le cas si l'opération c'était appelée par exemple establishEquipments

Avec le diagramme de séquence boite blanche nous sommes déja en conception du coup c'est normal d'avoir plusieurs solutions possibles, establishEquipments peut trés bien convenir il faut voir ce que donne son ds maintenant il peut trés bien être le mê à l'appelation qui change ;)

Si tu as une proposition (cela me fera voir les barres d'activités :king:) cela peut être sympa de montrer à quoi cela peut ressembler avec establishEquipments