Discussion :

[djflex68]

Bonjour,

Une simple question :
Quels diagrammes UML préconisez vous d'utiliser dans le cadre de la modélisation du fonctionnement d'une interface graphique ? Dans ce cas doit-on l'exploiter de façon particulière ?
Je songeais au diagramme d'activités mais est-il vraiment adapté aux modélisations du type : "Quand on clique sur le bouton A, on affiche B et C sauf si Condition 1 etc..." :

Merci

[slim]

salut

c'est le diagramme d'etats transitions qu'il faut utiliser. il associe un automate à une classe. et decrit les differents etats que peut avoir l'application.

[Invité]

Bonjour,

Les diagrammes UML ne sont pas fait pour modéliser les IHM -de base...
Toutefois, dans le cadre de mon Boulot (mise en place d'UML et d'une méthodologie adéquate), nous avons testé 2 diagrammes UML :
celui d'états transitions (DET) et celui d'activité (DAC) :

Le DET : avec l'outil Xde (pour WSAD & .NET), le DET était assez intéressant puisque l'outil permet de mettre plusieurs actions dans un état - chaque actions correspondants par exemple à un fonction applicative (ou un bouton). De plus, on pouvait jouer avec la notion de Super-état et sous-état.
Maintenant nous sommes passés à RSA - UML 2, et là c'est déjà moins intéressant - entre autre car nous ne pouvons plus mettre qu'une seule action par état ...


LE DAC : avec l'outil XDE, pas assez intéressant.
avec RSA, au vu des restrictions sur le DET, nous préférons passer sur le DAC qui semble mieux approprié... je l'ai utilisé et cela pemet de faire pas mal de chose.

Mais en fin de compte, UML n'est pas fait pour cela. Donc à toi de voir lequel des 2 est le plus approprié pour montrer ton point de vue, ou montrer tout autre information nécessaire au développement (actions struts par exemple)

CARPE DIEM[/img]

[ego]

En utilisant un (ou des) diagramme d'activités dans lequel tu peux mettre aussi des états, tu peux dire que les états sont les pages, les évènements faisant passer d'une page à une autre sont les actions utilisateur et tu peux aussi intercaler entre des états des activités pour montrer un traitement qui va décider vers quelle page aller.

Si tu ne veux pas montrer ce traitement qui décider vers quelle page aller, tu peux en rester au diagramme états-transitions avec évènement = action utilisateur.

Par rapport à la réponse précédente, je ne vois pas pourquoi utiliser plusieurs actions dans un état. En fait, je ne vois pas pourquoi utiliser les actions d'ailleurs.

[djflex68]

merci pour vos réponses !

Si tu ne veux pas montrer ce traitement qui décider vers quelle page aller, tu peux en rester au diagramme états-transitions avec évènement = action utilisateur.

ego, oui en fait ce que tu décris correspond exactement à ce que je suis en train de faire ... J'ai raisonné de la même façon : il suffit en fait de considérer l'IHM comme un objet (Page), dans ce cas on peut lui appliquer les évènements et activités comme n'importe quel autre objet (=> diagrammes d'états-transitions et d'activités)
merci à tous en tout cas

[ego]

Pour info, la manière de faire n'est pas trop débile car sur la base de ces diagrammes, on avait fait, dans ma précédente boite, un générateur de fichier struts-config.xml (sous Rose et TogetherControlCenter)

[Invité]

Par rapport à la réponse précédente, je ne vois pas pourquoi utiliser plusieurs actions dans un état. En fait, je ne vois pas pourquoi utiliser les actions d'ailleurs.

L'intérêt - dans le début de tes spéc IHM - est que tu peux rapidement modéliser par des actions ce que chaque page contient comme possibilités "fonctionnelles".
Par exemple sur un fournisseur => editer - imprimer - modifier - ajouter - etc.... Evidemment cela peut t'amener vers d'autres pages ou rester sur la même (d'où la notion d'action ).
Par exemple, nous étions partis sur la notion de super-etat pour des pages mises à jour dynamiquement avec des actions en entrée & sorties....
Notre principal souci - était la communication entre les différentes parties prenantes - afin d'arriver à une IHM stable ...( si cela peut exister).
ON reste finalement sur un constat récurrent : quel point vue veut on faire passer !!

Pour ta dernière intervention, l'intérêt comme tu le dis plus bas c'est que tu peux - en conception - faire appraître des actions struts par exemple - donc faciliter aussi l'implémentation de ces actions struts...

CARPE DIEM

[djflex68]

Personnelement, je mets des actions et activités dans mes états IHM aussi...
Au fait j'avais pensé à un projet (assez ambitieux) qui consistait à décrire l'état de tous les éléments d'une page (Visible, Invisible, Activé, Désactivé) en fonction de l'état dans lequel se trouve la page précisémment, et cela dans un fichier XML.. il y aurait un composant qu'il suffirait d'appeler et qui en fonction de l'état courant de la page et d'éventuelles conditions supplémentaires, chercherait dans le fichier XML comment afficher la page...
exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
<page>
    <etat nom="Lecture seule">
        <Label1 visible="true">
        <TextBox1 visible="false">
    </etat>
    <etat nom="Modification">
        <Label1 visible="false">
        <TextBox1 visible="true">
    </etat>
</page>

ça pourrait être sympa pour s'épargner les corvées du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Label1.Visible = true;

dans les pages... mais bon c'est certainement plus difficile à dire qu'à faire...

EDIT : XSL permet de faire ça je crois

[ego]

Par rapport à la sémantique des actions dans un état, je pense que l'usage des actions pour montrer les "fonctions" possibles quand on est sur une page n'est pas approprié.
Dans une logique évènementielle, il est préférable d'utiliser des évènements sur des transitions (classiques ou internes)

[djflex68]

j'utilise bien les évènements en tant que transition entre états (click...), par contre j'utilise aussi des actions (à distinguer des activités) dans les états pour modéliser un traitement "instantanné" (ex : remplir la liste)...

[ego]

ok, là je suis d'accord !