Discussion :

[Nehmé]

Bonjour,

Je travaille sur un logiciel qui devrait être capable sans et avec une interface graphique. Pour exécuter sans interface graphique, on passe les paramètres dans un fichier xml.

On peut voir ca comme trois modules: gui, xml et core. Le core est un algorithme heuristique.

Lorsque l'application est exécuté à partir du mode graphique, le gui configure le core en lui passant les paramètres et l'exécute:

Code :

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

1
2
3
4
5
6
7
8
// dans gui:
int time = this->timeSpinBox->value();
int nIterations = this->nIterationsSpinBox->value();

core.setRunTime(time);
core.setNumberOfIterations(nIterations);
...

De même pour le mode xml:

Code :

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

1
2
3
4
5
6
7
8
// dans xml:
int time = this->readFromXML("time");
int nIterations = this->readFromXML("nIterations");

core.setRunTime(time);
core.setNumberOfIterations(nIterations);
...

On peut remarquer tout de suite qu'il y a du code dupliqué et que ca pourrai arriver qu'un développeur ajoute des paramètres au mode graphique et oublies des les ajouter au mode xml et vice versa. En conséquence on ne peut garantir que les deux modes fonctionnent de la même façon.

Pour éviter ce problème, j'ai pensé à faire en sorte que gui écrive un fichier xml et que xml le lise par la suite pour exécuter core. De cette façon on est au moins sure que si gui fonctionne correctement, xml fonctionne aussi car gui passe par xml. L'autre sens est moins grave car habituellement c'est gui qui évolue avant xml.

Est ce que vous pensez que c'est la bonne façon de faire ? sinon des propositions ?

Merci

[bruno_pages]

Bonjour,

ca risque d'être une sacrée usine à gaz

de plus je ne suis pas sure que les deux modes soient vraiment identiques, sauf à avoir en guise d'IHM une boite de dialogue avec seulement des saisies de valeur avec un bouton ok et u autre cancel

que fait votre application ?

[Nehmé]

Bonjour,
(
WOW disons que je suis très content de voir que l'auteur de Bouml répond à mon poste ! Merci . J'utilise Bouml d'ailleurs pour faire du reverse engineering de diagrammes de classes c++ et j'adore !
)

que fait votre application ?

L'application contient plusieurs algorithmes d'optimisation pour résoudre des problèmes de recouvrement d'ensembles que j'applique à des problèmes réels. L'exécution de l'algorithme peut durer des heures voir jours ... Le but d'avoir l'entrée xml est de pouvoir exécuter l'algorithme sur un serveur et des machines hautes performance en passant par ssh.

Bonjour,
ca risque d'être une sacrée usine à gaz

de plus je ne suis pas sure que les deux modes soient vraiment identiques, sauf à avoir en guise d'IHM une boite de dialogue avec seulement des saisies de valeur avec un bouton ok et u autre cancel

L'interface est un peu plus compliquée qu'une simple boite de dialog (d'ailleurs c'est fait en Qt comme Bouml !).
Ce que j'ai fait pour l'instant est le suivant:
- Chaque Widget dans l'interface graphique possède une fonction exportXML() qui est utilisée pour écrire les fichiers xml.
- Un xml reader lit le fichier xml et donne en sortie une instance d'un objet composite AlgoProperty qui contient toutes les paramètres et possède une interface simple et générique:

Code :

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

1
2
3
4
5
getStringParameter()
getIntParameter()
getDoubleParameter()
getChildParameter()
...

- AlgoProperty est ensuite passé à l'algorithme qui l'utilise pour connaitre ses paramètres d'entrée:

Code :

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

1
2
3
4
5
algo->run(algoProperty);

// dans Algo:
this->numberOfIterations = algoProperty->getIntParameter("nIterations");
...

Certains paramètres sont plus compliqués qu'un simple "int" mais avec les objets composite, j'arrive à les passer quand même.

J'espère que ma description est claire !

Merci

[bruno_pages]

Bonjour,

je n'ai pas été clair, ma question portait sur ce que faisait la partie IHM en plus du graphisme pure, mais puisque vous connaissez Bouml ca va m'aider pour faire un parallèle avec votre application

Si on s'intéresse à la partie génération de code dans Bouml le modeleur est une IHM permettant de bâtir le modèle à permettant au générateurs de faire leur travail. Il est également possible de lancer la génération de code (comme n'importe quel plug-out) en batch via un shell sans affichage/IHM. Peut-on alors envisager de baser le fonctionnement de Bouml sur le passage d'un intermédiaire en XML comme vous ? La réponse est non car le plus gros du travail n'est pas au niveau générateur de code mais est au niveau du modeleur, le modeleur n'est pas qu'un producteur de modèle basé sur des boites de dialogue sans intelligence, il permet aussi à des plug-outs de modifier le modèle (par exemple les reverses) tout en vérifiant la validité des modifications dans ce cas comme dans le cas de modifications manuelles.

Pour prendre un autre exemple dans les boites de dialogue des artefact/classe/opération/attribut/relation on voit le code qui sera généré (simplifié pour les artefacts/classes) avec une mise à jour en live qui suit chaque modification de la déclaration/définition, il n'est pas concevable de demander le calcul de cette (pseudo) génération au vrai générateur de code.

La complexité de ce qui est déclenché par l'IHM, ce qu'il y a derrière hors IHM pure, ainsi que les contraintes d'exécution doivent donc vous guider pour savoir si le passage systématique par XML au autre représentation est une bonne solution

J'ajouterai de plus que si aucune autre application que la votre n'utilisera les données alors XML est un mauvais choix. XML c'est lourd et pas pratique, le prix inhérent à son utilisation ne se justifie que si d'autres applications peuvent également utiliser cette entrée, c'est à dire si on a besoin d'un interface exposée avec l'extérieur. Pour refaire un parallèle avec UML, XMI se justifie car il s'agit d'une vrai interface utilisée par des applications tiers. Par contre utiliser XML comme moyen de sauvegarde du modèle seul, c'est à dire d'une certaine façon pour s'interfacer avec soi même, est une absurdité ... malheureusement utilisée par certains modeleurs (my two cents)

[souviron34]

Bonjour,

Je travaille sur un logiciel qui devrait être capable sans et avec une interface graphique. Pour exécuter sans interface graphique, on passe les paramètres dans un fichier xml.

On peut voir ca comme trois modules: gui, xml et core. Le core est un algorithme heuristique.

...
Est ce que vous pensez que c'est la bonne façon de faire ? sinon des propositions ?

Merci

Je te référerai à la discussion architecture-4-tiers où j'ai exposé mon point de vue pour faire exactement ça...

[Nehmé]

Bonjour,

Bonjour,

J'ajouterai de plus que si aucune autre application que la votre n'utilisera les données alors XML est un mauvais choix. XML c'est lourd et pas pratique, le prix inhérent à son utilisation ne se justifie que si d'autres applications peuvent également utiliser cette entrée, c'est à dire si on a besoin d'un interface exposée avec l'extérieur. Pour refaire un parallèle avec UML, XMI se justifie car il s'agit d'une vrai interface utilisée par des applications tiers. Par contre utiliser XML comme moyen de sauvegarde du modèle seul, c'est à dire d'une certaine façon pour s'interfacer avec soi même, est une absurdité ... malheureusement utilisée par certains modeleurs (my two cents)

Merci pour les explications. Je suis d'accord mais quelle serai l'alternative ? comment lancer mon application et passer les paramètres sur un serveur auquel je n'ai accès que par ssh ?

Je te référerai à la discussion architecture-4-tiers où j'ai exposé mon point de vue pour faire exactement ça...

Merci oui en effet c'est très utile !
Le seul défaut que je vois de l'architecture discutée par rapport à mon application est le fait que les couches IHM et XML ne seront pas nécessairement synchronisées. Il est possible qu'un programmeur ajoute des paramètres à l'interface et à la couche applicative et oublie de le faire pour la couche XML. Ce qui arrive souvent puisque c'est le IHM qui évolue principalement. Par contre, si la couche XML est forcée comme couche intermédiaire, on est toujours sure que la couche XML possède les mêmes fonctionnalités que la couche IHM.

[souviron34]

Merci oui en effet c'est très utile !
Le seul défaut que je vois de l'architecture discutée par rapport à mon application est le fait que les couches IHM et XML ne seront pas nécessairement synchronisées. Il est possible qu'un programmeur ajoute des paramètres à l'interface et à la couche applicative et oublie de le faire pour la couche XML. Ce qui arrive souvent puisque c'est le IHM qui évolue principalement. Par contre, si la couche XML est forcée comme couche intermédiaire, on est toujours sure que la couche XML possède les mêmes fonctionnalités que la couche IHM.

D'après ce que tu dis, tu aurais :

Code :

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

1
2
3
IHM ----
            ------- > core 
XML ----

On s'en fiche que ce ne soit pas synchronisé, c'est tout l'avantage de cette construction..

Si jamais tu dois modifier une fonction du core, à ce compte-là à la prochaine reconstruction de l'autre côté ce sera pris en compte. Si jamais ça n'est que côté IHM ou que côté XML, pas de pbe, ça n'a aucun impact sur l'autre côté...

Dans l'exemple météo que je donne dans la discussion en référence, le besoin était de mettre le plus possible en correspondance les 2, donc pratiquement toutes les fonctionalités étaient dans le core..

Maintenant, par exemple la fonctionalité "voir des animations" n'était que du côté IHM, alors que la fonctionalité "sauvegarder des animations" était dans le core, et donc des 2 côtés.. Par contre, la fonctionalité "modifier les couleurs" ést présente dans le core, mais la fonctionalité "modifier via ascensceur" ne l'est que du côté IHM...

Si il y a ajout de paramètres du côté IHM et pas du côté XML, et que c'est pas bien, c'est qu'alors la focnionalité aurait dû faire partie du core...

Si il y a quelque chose qui doit être développé d'un côté ou de l'autre sans contreparties, c'est forcément une fonctionalité.

Si il y a des paramètres supplémentaires à une fonctionalité, et que il serait important que le développement soit cohérent, alors cette fonctionalité doit être dans le core, et donc de nouveaux paramètres seront automatiquement répercutés..

Si par contre il est peu important que les développements soient cohérent à propos de cette fonctionalité, alors uniquement le coeur commun est dans le core...

La base de toute bonne architecture est une bonne analyse....



Maintenant, utliser XML comme couche intermédiaire peut être correct pour un démarrage de l'appli, mais pas pour un runtime, où le temps de réponse intervient grandement...

[Nehmé]

Si il y a ajout de paramètres du côté IHM et pas du côté XML, et que c'est pas bien, c'est qu'alors la fonctionnalité aurait dû faire partie du core...

Toutes les fonctionnalités font partie du core. Ce que je suis en train de dire est que dans l'architecture que tu proposes, si on ajoute un paramètre dans le IHM (ce paramètre est ajouté aussi dans core), il faut qu'on fasse le même travail dans XML pour être sure qu'il est capable de répondre aux besoins de core en lui passant tous les paramètres requis. Ce que on peut facilement oublier de faire et introduire des bugs.

Si il y a quelque chose qui doit être développé d'un côté ou de l'autre sans contreparties, c'est forcément une fonctionalité.

Si il y a des paramètres supplémentaires à une fonctionalité, et que il serait important que le développement soit cohérent, alors cette fonctionalité doit être dans le core, et donc de nouveaux paramètres seront automatiquement répercutés..

Oui tout est dans core dans le fond, sauf que l'utilisateur passe ces paramètres à core à partir du IHM ou des fichiers XML. C'est pourquoi ces deux entrées doivent avoir toujours les mêmes capacités.

Maintenant, utliser XML comme couche intermédiaire peut être correct pour un démarrage de l'appli, mais pas pour un runtime, où le temps de réponse intervient grandement...

Si tu parles du temps réel, les paramètres passés par xml servent seulement à démarrer l'algorithme et ne sont passés qu'une seule fois. Pour exécuter une action en temps réel, comme interrompre l’exécution ou changer un paramètre, IHM peut quand même communiquer directement avec core mais seulement dans ce cas précis. Pour le retour d'informations de core à IHM ou autres, j'utilise des observateurs (core notifie de temps en temps ses observateurs pour retourner certaines informations)

[bruno_pages]

Bonjour,

la discussion semble virer au dialogue de sourd

pour revenir au seul problème initial est ce que vous pensez que c'est la bonne façon de faire ? je pense que passer par la porte et rentrer par la fenêtre en utilisant XML à partir de l'IHM n'est pas une bonne solution pour assurer de ne pas oublier de mettre à jour la partie XML lors d'évolution de l'IHM/moteur

certes le choix d'une architecture doit permettre de facilité/sécuriser autant que faire ce peut les évolutions futures, mais pas au niveau est-ce que j'ai pas oublié de développer une nouvelle feature dans une sous partie de l'application, cela se résout via une traçabilité feature/code et/ou des tests

[Nehmé]

Oui ca bien du sens ! Merci