Version imprimable
Bonjour,
voilà tout est dans le titre, j'ai une appli qui contient des enchainements d'écrans , un peu à la manière des Wizard et je souhaiterais les modéliser pour bien comprendre les enchainements genre quand il clique sur tel bouton ca doit charger tel écran etc ...
Quel diagramme UML me conseilleriez vous ?
Merci :roll:
Un diagramme d'état transition, avec une sémantique détournée, car chaque état va représenter une fenêtre/IHM de ton applications. Chaque transition pourra être étiquettée par le label d'un boutton par exemple.Citation:
Envoyé par loverdose
:roll: merci , il semble effectivement que c'est le diagramme qu'il me faut :)
tant que , je sais pas si tu t'y connais un peu en design pattern mais est ce que tu crois qu'il y a des design pattern que l'on pourrait utiliser avec ce genre de problème ? sachant que sur chaque écran on devrait pouvoir revenir ou avancer , comme dans un wizard en fait .. le pattern Command me semblerait approprié mais j'aurai besoin de confirmation :)
merci encore
Non, le pattern commande est plutôt utilisé pour pouvoir effectuer une liste de tâches, mais aussi pouvoir les annuler. (exemple dans les traitements de texte).
Toi tu as besoin d'exprimer les transitions possibles d'une fenêtre à une autre. Il n'y a rien de mieux qu'un diagramme d'états-transitions dans ce cas ;) .
Mais je comprends ton interrogation, tout cela est subtil.
Helllo :roll:
merci pour ta réponse, maintenant j'ai fini de modéiliser les enchainements de mes écrans grace au graphe d'etat ... maintenana mon grosproblème c'est que j'arrive pas à voir comment je pourrai transformer ca en algorithme programmable :?
Si vous avez des lients intéréssants sur l'implémentation des graphes d'etat ca m'intéresse , merci d'avance du coup de main ;)
Est-ce que http://pcaboche.developpez.com/artic...patterns/etat/ peut t'aider ? Ca ne parle pas directement de wizard, mais c'est proche :)
Merci pour le lien ! Oui le pattern State m'a aidé même si je ne l'ai pas appliqué aussi scrupuleusement :) , et la j'ai un bel enchainement d'écrans qui marche bien :) .
J'ai juste une derniere ptite question pas très difficile en fait car c'est juste un problème d'architecture.
Le problème se présente comme ceci :
Je tiens d'abord à préciser que je programme en VB6 donc les notions d'héritages etc ... c'est pas terrible.
J'ai plusieurs écrans qui contiennent exactement les mêmes controles sauf que les textes sur les controles sont différents et aussi les traitements lors de click sur les boutons. Flemmard comme je suis , je me suis dit que j'avais qu'à faire une seule feuille et utiliser cette unique feuille pour chaque écran en changeant juste les textes et en rajoutant tous les traitements possible selon le type d'écran à afficher .. j'espère que c'est plutôt clair jusque là .. :?
Le souci c'est que cela m'oblige à avoir dans le code de la feuille des codes du genre :
bref un énorme "Select case" ou "Switch" qui va etre très dur à entretenir et qui fait grosse tâche dans un code.Code:
2
3
4
5
6
7
8
9
10
11
12
Je me suis donc dit pour résoudre mon problème que je vais créer des classes (qui auront une interface commune) pour chaque type d'écran et que comme ca selon le type d'écran , je vais lier ma feuille à une classe qui correspond donc à un type d'écran.
Le souci c'est que dans chacune de mes classes, je suis obligé d'avoir une référence sur la feuille pour pouvoir initialiser les textes des controles , donc comme ceci
Et tout ca tourne bien sauf que je me suis dit que maintenant mes classes (donc les couches en dessous d'apres le pattern Model-View-Controller) , reposent pas mal sur mes feuilles alors que ca devrait etre le contraire et c'est ca qui me gene un peu car on est obligé de modifier la classe par exemple si on efface un controle de la feuille (dans mon exemple ci-dessus , si le bouton "unBoutonDeMaFeuille" est éffacé de ma feuille, cela m'oblige à modifier ma classe aussi) et ca je trouve ca pas terrible , cependant je trouve pas non plus meilleure organisation ou meilleur moyen de résoudre mon souci , voilà voilà , si vous avez un avis ca m'intéresse beaucoup merci :roll:Code:
2
3
4
5
6
7
8
9
10
11
Tu ne peux pas avoir une méthode à appeler dans ta classe feuille qui remplirait correctement l'interface graphique ?
si bien sur mais comme je le mentionnais un peu plus haut ca m'obligerait à faire des SELECT CASE énorme genre :
et je trouve ca pas tres objet et pas tres propre sachant que pour les boutons je vais etre obligé de faire pareil :Code:
2
3
4
5
6
7
8
9
10
11
12SELECT CASE TypeEcran CASE EcranBleu : 'Ici remplissage écran bleu CASE EcranRouge : 'Ici remplissage écran rouge .... END SELECT
tu vois le truc ? En fait je me demandais comment les gens font quand ils veulent réutiliser une même feuille pour afficher différent type d'écrans , je me dis qu'il doit y avoir une sorte de design pattern ou une astuce mais j'ai pas trouvé jusque là ... :roll:Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18Private sub Monbouton_Click () SELECT CASE CASE EcranBleu : 'Ici traitement du bouton quand l'écran est bleu CASE EcranRouge : 'Ici traitement du bouton quand l'écran est rouge .... END SELECT End Sub
Mes connaissances en VB sont vraiment faibles pour pouvoir t'aider à ce niveau, peut-être tu pourrais demander dans le forum VB6 s'il existe une solution élégante ?
mais je pense que c'est pas vraiment lié au langage en fait , c'est un problème de conception et d'architetecutre et non de programmation , c'est pour ca que j'ai posté ici mais je continue à chercher, si je trouve une solution je la posterai et merci ;) :roll:
Tu peux faire des dérivées de tes objets ? Le polymorphisme sous VB fonctionne comment ?
tu peux implémenter une interface et faire du polymorphisme oui.
Dans l'héritage ,seuls les méthodes et les propriétés sont transmis aux classes filles et pas les variables ni les constantes :roll:
D'ailleurs je fais comme ca en ce moment , c'est à dire que j'ai une seule feuille et deux classes clsEcranBleu et clsEcranRouge qui implémentent tous les deux une interface clsIEcrans.
Dans ma feuille j'ai une proriété déclaré en tant que clsIEcrans et qui donc sera initialisé à clsEcranBleu ou clsEcranRouge selon l'écran que je veux afficher.
Et là viens mon petit problème c'est que pour faire le traitement du design de l'écran bleu par exemple et bien je suis obligé d'avoir une référence surma feuille comme ceci :
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17'Dans ma classe clsEcranBleu 'Ceci nous dit que cette classe implémente 'l'interface clsIEcrans Implements clsIEcrans Public uneReferenceAMaFeuille as Form 'La méthode qui design la feuille , donc qui remplace les textes selon les écrans etc .. Public Sub DesignMaFeuille () uneReferenceAMaFeuille.unBouton.Caption = "Ceci est un écran BLEU" ... End sub
vois tu mais, là cela implique que mes classes sont dépendantes de ma feuille et c'est là que cette facon de faire m'embete un peu :roll:Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17'Dans ma classe clsEcranRouge 'Ceci nous dit que cette classe implémente 'l'interface clsIEcrans Implements clsIEcrans Public uneReferenceAMaFeuille as Form 'La méthode qui design la feuille , donc qui remplace les textes selon les écrans etc .. Public Sub DesignMaFeuille () uneReferenceAMaFeuille.unBouton.Caption = "Ceci est un écran ROUGE" ... End sub
Tu ne pourrais pas faire une méthode implémentée dans tes écrans qui renverrait ces valeurs sous forme de chaîne de caractères ?
je ne comprends pas très bien ce que tu veux dire ... tu peux donner un exemple de code ? :roll:
Je ne sais pas trop programmer en VB, mais ça serait qqch du style :
Maintenant, ça marche si tu as tout le temps les mêmes objets - toujours 2 boutons, ... -, autrement, c'est plus chaud, et là, il faudrait retourner une classe plus complexe avec un pattern style composite par exemple.Code:
2
3
4
5
6
7
8
Et oui mais à partir du moment ou la classe est dépendante de la feuille , je trouve que ca fait pas tres propre non ? parce que si on enleve un bouton de l'interface , la classe planterait, or cela ne devrait pas arriver puisque c'est la feuille qui doit dépendre de la classe et non l'inverse :roll:
mais je crois qu'il y a quand meme quelque chose à retenir dans ce que tu as proposé car si je fait des fonctions qui retourne le texte à afficher dans la classe,du coup meme en modifiant ma feuille , la classe reste intacte et utilisable ... je vais essayer de creuser un peu de ce côté là :roll:
Voilà, c'est ça l'intérêt ;) mais c'est vrai que si tu dois rajouter des éléments, ça devient moins bon :|
en tout cas merci de ta gentillesse et de ta disponibilité !! ;) :mouarf1: