[UML] modelisation d'une navigation

Bonjour,

J'hésite sur la modélisation de navigation suivante (plus exactement, aucune des modélisations que j'ai trouvées ne me parait satisfaisante).
Un formulaire peut être appelé en utilisant différentes voies, et l'endroit d'où il est appelé a un effet sur son comportement / contenu.

Par exemple (et ce n'est qu'un exemple) :
- S'il est appelé à partir du menu principal, le formulaire "facture" permettra d'afficher toutes les factures et éventuellement d'appliquer un filtre sur l'entité "client". Le bouton permettant de fermer le formulaire s'appellera "retour menu" (c'est une demande du client), et reviendra... sur le menu (incroyable, non ?)
- S'il est appelé à partir du formulaire client, ce même formulaire "facture" permettra d'afficher uniquement les factures du client courrant, et aucun filtre ne sera possible sur l'entité "client" (logique, non ?). Le bouton permettant de fermer le formulaire s'appellera "retour client", et reviendra sur la fiche client appelante (avec raffraichissement de cette dernière en cas de modification de la facture).

Le formulaire facture (pour ne parler que de lui) peut être appelé de 4 endroits différents, avec à chaque fois de subtiles nuances dans son comportement.

Auriez-vous une modélisation à me suggérer ? Eventuellement hors UML (j'ai regardé SNI, très intéressante mais à mon avis non adaptée à ce cas)

UMLment,

Yvan

Bonjour

comportement => dynamique

à priori 4 diagrammes de séquence, ou 1 seule machine à états,
je vois moins les diags activité ni collaboration pour ton cas (mais je regarde de loin ;-)

J'avais écarté les diag de séquence et d'activité car cela revenait à la multiplication des diags (entre 3 et 6 moyens d'atteindre un formulaire, et une douzaine de formulaires), et on pert totalement la vision globale.

Une machine à état est la solution que j'avais à prioris retenu, mais se pose le pb des "états" correspondants à des formulaires.

Voici une version très abrégée du modèle...
http://perso.wanadoo.fr/yvan.picot/M...Navigation.png

Au niveau du formalisme, je ne trouve pas ça très propre, et c'est la raison pour laquelle je demandais un éclairage

Yvan

ce que tu ne dis pas, et qui pourrait peut etre nous aider a te repondre, c'est le contexte de ta modelisation : veux-tu exprimer un besoin, reflechir a l'architecture haut niveau de ton systeme, ou veritablement implementer la chose ?

Citation:

---

Envoyé par bruno_pages

ce que tu ne dis pas, et qui pourrait peut etre nous aider a te repondre, c'est le contexte de ta modelisation : veux-tu exprimer un besoin, reflechir a l'architecture haut niveau de ton systeme, ou veritablement implementer la chose ?

---

Excellente question !
Le but est double (enfin, le dernier point est moins technique...)
- visualiser l'architecture globale (de la navigation), pour être sûr que je n'ai pas oublié un cas qque part, et m'en servir de référence quand je devrais implémenter tout ça.
- laisser une doc qui en jette au client :wink:

A titre indicatif, cela sera implémenté en Filemaker.
Pour l'anecdote, la dernière version de Filemaker (la version 8 ) implémente une nouveauté qui fait figure de révolution : il y a maintenant des variables. On n'est plus obligé de stocker ses "variables" dans le champ d'une table.

Défense de rire !
On est assez loin de java et autre delphi.

UMLment,

Yvan

Moi, je ferai 2 choses :

- Un diagramme d'états pour modéliser les chemins de navigation dans l'ensemble de ton application. Dans ce diagramme (ou ces diagrammes si la navigation est complexe), les états représentent des pages/formulaires et les évènements entre états des évènements graphiques ou évènements en provenance des contrôleurs graphiques.

- Un diagramme d'états pour la modélisation des différents états dans lesquels ton formulaire peut être en fonction des évènements qu'il reçoit. Ces évènements étant typés par la source qui les émet puisque visiblement c'est cette source qui conditionne l'état de ton formulaire.

Ego, j'achète ta solution. Je n'avais pas pensé au double diag d'état.

Merci !

Yvan