Discussion :

[elfive]

bonsoir,

un diagramme de navigation entre les ecran (fenetres) est un Diagramme d'activité ou un diagramme d'etat transition ?

merci

[bruno_pages]

bonsoir,

... est un ... ?

ni l'un ni l'autre, de la même façon qu'une planète n'est ni une orange ni un citron

par contre, de même qu'on peut utiliser des oranges / citron ou autre pour montrer les tailles respectives des planètes, il est possible de montrer un enchainement d'écran avec des diagrammes d'activité ou d'états. Le but étant à priori de montrer des boites reliées par des flux/transitions avec des conditions associées donnant les raisons des enchainements les deux diagrammes se valent

[elfive]

merci Mr.Bruno,
donc ca peut marché avec un cocktail (smile).

[Vlade]

Nous avons utilisé AndroMDA pour l'intégration de JSF/Strut et le diagramme d'état. Il s'agit dans ce cas de la génération de la couche présentation.
A vrai dire votre question est bonne car en UML 1.x on utlisait le diagramme d'état mais depuis le passage en UML2 l'élement associé dans la struture UML a changé et seul le diagramme d'état est possible.
On a écrit un tuto sur le sujet qui est à lire mais est réservé aux gens courageux car on fini par s'endormir après la 10 pages :
# PDF format
# Word format

Avec du recul je pense que très peu de projet on vraiment été jusqu'au bout de la démarche car la complexité est énorme par rapport aux avantages réels. L'approche MDD de génération de la couche de présentation est un echec. Seul les couche Spring pour le service et Hibernate pour la persistence sont vraiment utilisés. Les gens préférent une fois ces 2 couches généré le faire à la main et je les comprends. Les règles de validations du modèle AndroMDA sont si complexe qu'on va plus vite à le faire à la main et donc dans ce cas le MDD apporte rien. Je dirai que le state diagram est bien adapté pour la modélisation des contraintes métiers mais pas vraiment pour généré du code JSF/Strut d'ecran.

[elfive]

merci Mr.Vlade pour votre réponse,
je pense que les deux diagramme sert a une simple modélisation d'interactions entres les ecrans, qui est bien mon cas.

Je dirai que le state diagram est bien adapté pour la modélisation des contraintes métiers mais pas vraiment pour généré du code JSF/Strut d'ecran.

les JSF/Strut sont pour les application web, par contre ma futur application doit etre syteme répartie(client serveur) et pas de service web.
donc state diagram est bien pour mon systeme.