Modélisation de scénarios..

Bonjour,

Je travail dans un bureau d'étude dans le domaine des énergies renouvelables et mon patron voudrai que je développe un logiciel de diagnostique énergétique pour les bâtiments.

Le principe du logiciel serait le suivant:
1. Paramétrage - Je dois saisir la valeur des paramètre pour l'ensemble des objets de mon modèle. Cela comprends les caractéristiques géométriques et thermiques des bâtiments étudiés ainsi que divers paramètres sur la ventillation. Il faut aussi saisir des paramètres sur la ventillation, le climat, le système de chauffage, etc... Le tout est consigné dans un modèle sous forme d'arbre.

2. Calcul - J'exécute le calcul selon un algorithme qui dépend de la méthode utilisée. Le résultat est la consommation énergétique du bâtiment et le coût que cela représente.

3. Améliorations - Je dois pouvoir modifier les paramètres saisies en (1) afin de de proposer des améliorations (isolation des paroies, changement de chaudière, etc.) et recommencer le calcule de la consommation. Mais je ne veux pas écraser les paramètres du calcul initial. Ce calcul initial représente le scénario 0, je veux pouvoir créer d'autres scénari à partir du premier en procédant par héritage du scénario initial, surdéfinition des paramètres à changer et ajout ou suppresion d'autres paramètres. Donc ce que je veux c'est un système de paramétrage basé sur l'héritage.

Ma question est la suivante. Comment mettre en oeuvre ce système de paramétrage basé sur l'héritage? Existe t-il des designs patterns pour cela? Qu'elle est la meilleure technologie pour le mettre en oeuvre? Je pense à des technologies comme Java, SmallTalk, Lisp, ...

Je pensai aussi procéder en deux étapes: La première étant la réalisation d'un moteur de calcul basé sur des fichiers de paramétrage en XML et la seconde la réalisation de l'interface graphique.

Merci pour votre aide.

Patrick

Bonjour,

Citation:

---

Envoyé par gelinp

... je veux pouvoir créer d'autres scénari à partir du premier en procédant par héritage du scénario initial...
...Comment mettre en oeuvre ce système de paramétrage basé sur l'héritage? ...

---

c'est assez curieux comme méthode de raisonnement, pourquoi vouloir impérativement utiliser l'héritage alors que cela te pose des problèmes et que tu ne sais pas comment faire avec ? Bref alors que tu as déjà un problème à résoudre (faire ton prog), tu t'en ajoutes un autre venant de nulle part, c'est pas comme cela qu'on converge ;)

retire ton héritage, garde une liste de scenarii ordonnés (le premier étant le scénario original) et crée les autres scénario non pas par héritage mais par référence ou simplement pas recopie lors de leur construction

une bonne implémentation n'est pas quelque chose de compliqué (pour (se) dire ensuite, qu'est-ce que je suis fort d'avoir terminer cette implémentation si compliquée), mais au contraire quelque chose le plus simple et le plus court possible. La majorité des programmes sont des usines à gaz parce que la majorité des informaticiens feraient mieux de faire un autre métier :aie:

Je crois que je n'ai pas très bien expliqué ma problématique et je tiens à préciser que je suis un fervant adepte des solutions simples.

Pourquoi utiliser l'héritage? Et bien pour comprendre pourquoi je veux utiliser l'héritage et bannir la copie il faut imaginer le scénario d'utilisation suivant:

1. Je paramètre mon premier scénario et je calcul mes consommations initiales.

2. Je paramètre les améliorations dans des scénarios différents (par ex. dans le premier je change l'isolation, dans le second je change la chaudière et dans le troisième je change tout) et je calcul les nouvelles consommations. On remarque déjà que le troisième scénario est le cumul des autres et je n'ai pas envie de me taper son paramétrage surtout que je risque de faire des erreurs. Il faudrai pouvoir faire la somme de deux voir d'avantage de scénarios pour en créer un autre!

Bon disons que jusque là tout va bien et pour trois scénarios je pourrai effectivement utiliser la copie.

Mais voilà que le problème se complique car je m'aperçois que j'ai fait une erreur dans le paramétrage initiale et je dois le corriger de partout, c'est à dire dans le scénario initiale et dans les trois autres scénarios qui sont des copies du premier. Ca parait simple à dire mais je fais des diagnostiques sur des sites industriels qui comportent des dizaines de bâtiments avec 5 à 6 scénarios différents pour chaque bâtiment. Donc pour un projet je peux arriver à une demi-centaine de scénrios sans compter tous les croisements possibles entre chacun. Par ailleurs je gère plusieurs projets par mois et avec la fatigue je peux malheureusement facilement faire des erreurs de paramétrage...

Donc il est très important pour moi que ce soit le programme qui gère cette compléxité et pas ma petite tête! En d'autres termes il est fondamentale que le programme me permette de créer rapidement un scénario en éritant d'un autre déjà existant et surtout qu'il m'évite de faire des erreurs et qu'il me facilite la vie grâce à l'héritage plutôt que je me casse les couilles à vérifier l'intégrité de l'ensemble de mon projet après chaque modification que j'ai fais !

Patrick

il est ici question de dépendance entre scénario et non d'héritage (au sens UML/langage de prog)

Effectivement, il te faudrait procéder par "delta". C'est à dire par empilement de modifications.

La base de ta pile est le scénario 0 qui décrit la majorité des paramètres.

Ensuite, à chaque évolution proposée, tu empiles cette évolution.

Pour avoir le scénario complet, tu instancie un nouveau scénario, pour lequel l'ensemble des paramètres est la somme des paramètres de la pile.

(une liste est aussi bien adaptée, j'ai dit pile par habitude.)

A vrai dire, tous les languages permettent de faire ce que tu decris

Commence par le debut, quels sont les languages que tu maitrises ?

Solution la plus simple pour ce genre d'appli: excel ou calc d'open office.

Avantage, tu n'as pas a t'occuper de l'interface graphique. Une feuille de calcul te permet de rentrer tes paramètres tres facilement.
Pour faire un seconde scenar : un simple bouton copie par reference la page 1 par exemple.
Tout tes champs deviennent des references à ta premiere feuille. Tu ne changes plus que les champs qui t'interesse et te voila ac un deuxieme scenario

La grosse limitation de ces utilitaires viendra de la complexité de tes calculs.

Apres, la reference en terme d'appli de calcul scientifique reste matlab.

Je réponds à plusieurs messages à la fois,

D'abord je tiens à préciser qu'avant de travailler dans l'énergie j'ai fait pratiquement dix ans en conception logiciel avec les technologies objet, notamment C++, Java, Deplhi, Python, ...

A mon point de vue mon problème relève vraiment de l'héritage et en particulier de la redéfinition et du polymorphisme. La redéfinition car un paramètre du calcul héritée peut être redéfinie et le polymorphisme parce que, par exemple, une chaudière d'un type peut être remplacée par une autre d'un autre type. Par ailleurs, comme je l'ai déjà expliqué, la modification d'un scénario "ancêtre" doit être répercuté sur tous ceux qui en hérite.

Maintenant je n'ai pas envie de me compliquer la vie et si l'analyse montre clairement qu'il s'agit d'un problème d'héritage je suis prêt a essayer n'importe quelle solution qui simplifie le problème en y répondant convenablement.

Je retiens deux bonnes idées dans vos réponses. La première avec le concept de pile de scénarios, et l'autre avec la copie par référence dans Excel.

Pour la seconde, la copie par référence d'une feuille de calcul, je viens de faire une recherche dans l'aide de Excel mais je n'ai rien trouvé sur le sujet. Peut être n'est ce accessible que par programmation. Par ailleurs il y a un problème de taille à résoudre c'est que une fois les feuilles du classeur câblées les unes avec les autres par les formules, il ne suffit pas de créer une autre feuille, il faut aussi modifier le câblage des calculs pour qu'ils prennent en compte la nouvelle feuille à la place de l'ancienne... Pour cela j'imagine qu'il faudrait imaginer une indirection définie dans une cellule qui contiendrai le non de la feuille active pour le calcul. L'intérêt de cette solution c'est que je peux utiliser Excel plutôt que de me taper à moi tout seul la programmation d'un logiciel. C'est beaucoup de temps de gagner. L'inconvénient c'est que je vais avoir beaucoup de feuilles de calculs à gérer et ça c'est un pétage de tête en perspective...

Pour la première idée, une pile de modifications, avec à chaque étage une modification qui surdéfinit celle de l'étage inférieur. Ca me semble une bonne solution mais attention, il n'y a pas que modifications de paramètre. Par exemple si je passe d'un logement collectif avec chauffage individuel à un logement collectif avec chauffage collectif, il faut supprimer toutes les chaudières individuelles et les remplacer par une collective. C'est à dire que là, je ne modifie pas la valeur de mon paramètre chaudière individuelle mais je transforme la structure de mon problème en une autre structure. Ce n'est plus une modification, c'est une transformation.

Merci pour vos réponses elles m'ont permis d'avancer!

On est tous d'accord sur héritage/polymorphisme sur les élements.

Par contre, pas pour les scénarii.
Une règle en général : "Preferer la composition à l'héritage" => plus souple, on peut modifier lors de l'exécution, etc..

C'est pour cela que faire hériter les scénarii est une mauvaise idée selon moi.

Pour la modification de la structure :
scénario de base { 3 logements dans un immeuble, 3 chauffages individuels }
empilement du 'paramètre' { - chauffage1, - chauffage2, - chauffage3, + chaudière collective, }

Oui je suis entièrement d'accord. Je parle d'héritage au niveau de l'analyse mais en conception se serait un héritage dynamique d'instance et non un héritage statique de classe. Ca n'existe pas! Avec les desings templates j'ai bien compris les avantages de la composition mais là c'est vraiment d'un héritage qu'il s'agit.

Je rajoute que je viens de découvrir un logiciel, DiagDPE pour ne pas le nommer, et qui fait ce que je cherche à faire. Sauf qu'il est mal foutu car on ne peut pas gérer le scénario "chaudières individuelles remplacées par chaudière collective". Pourquoi? Parce que la structure de donnée du modèle est un arbre du type:

Bâtiment collectif
+-- Appartement 1
+-- Chaudière Gaz
+-- Appartement 2
+-- Chaudière Gaz

Et dans les scénarios on ne peut pas modifier la structure de cet arbre! Ca parait rien mais ca m'oblige à faire un tas de calcul en dehors du logiciel et j'y passe un temps fou!

Pour ma part je pense plutôt faire un logiciel basé sur un langage fonctionnel (à la lisp) du type:

(Creer Batiment BatCollectif {paramètres constructeur...})
(Creer Local Appt1 {paramètres constructeur...})
(Creer ChaudièreIndividuelleGaz {paramètres constructeur...})
(Creer ChaudièreCollectiveGaz {paramètres constructeur...})

(Def Scenario0
(Ajouter BâtCollectif Appt1)
(Ajouter BâtCollectif.Appt1 ChaudièreIndividuelleGaz)
(Ajouter BâtCollectif Appt2)
(Ajouter BâtCollectif.Appt2 ChaudièreIndividuelleGaz)
...
)

(Def Scenario1
(Ajouter BâtCollectif ChaudièreCollectiveGaz)
(Ajouter BâtCollectif Appt1)
(Ajouter BâtCollectif Appt2)
...
)

(CalculerConsommations Scenario0 toRTF)
(CalculerConsommations Scenario1 toRTF)

Je pense sérieusement l'implémenter en lisp, j'en ai vraiment raz le bol des langages actionnels que sont Java, C++ et compagnie. Le seul problème c'est que je veux générer un rapport au format RTF ou créer un fichier Excel (ou calc). Je ne sais pas si Common lisp à des modules pour m'aider à faire ça?

A+

Je crois que pour excel, tu cherches trop compliqué.

Case A1 de la feuille 2 reprenant la valeur de la feuille1, valeur : "=Feuil1!A1"
Case A1 de la feuille 3 reprenant la valeur de la feuille2, valeur : "=Feuil2!A1"
Si tu modifies la case 2 a la main, la feuille 3 fera appelle à la nouvelle valeur de la feuille2

Apres VBA est la pour ça (ou OOOobasic voir python pour openoffice). Un script va balayer tes feuilles existantes, si le scenario est deja calculé, on saute et on passe a la suivante, et ainsi de suite.
Il te suffit pour cela de rajouter une case en A1 de chaque feuille = a 0 ou a 1
Si cette case est egale à 1, tu recalcules et tu la passes à 0 en prog. Des qu'une feuille est recalculé, toutes les suivantes le sont à leur tour

VBA te permet de modifier une feuille excel et l'interface du soft. Tu peux automatiser et ajouter des interfaces à la visual basique.

Pour info, VBA c'est de la gnognote, c'est vraiment un langage simple (temps d'apprentissage : 3 jours grand max)

Rien ne t'empeche d'avoir un modele que tu derives pour chaque projet ou sous projet. Ce modele contiendra tous les controles VBA

Pour Excel je suis sceptique et cela pour la simple et bonne raison que les structures de données que je gère sont des arbres or Excel ne sais pas gérer facilement des arbres. Par ailleurs j'ai bien compris le concept de reference mais il devrait être poussé à l'extrême. Ce que je cherche n'étant pas de référencé une ou deux cellules, ça je le fait déjà tous les jours, mais de référencer des feuilles entières et de les permuter les unes et les autres pour générer des scénarios différents. Si je me projette dans cette solution j'imagine déjà que ça va être une usine à Gaz. Pour information j'utilise déjà des applications Excel pour le calcul des consommations mais ça fonctionne pour des petits bâtiments et par pour des sites industriels.

Patrick

Ok, je comprends votre problématique.

Excel n'est ni plus ni moins qu'un gros tableau 2D donc c'est vrai que pour les arbres, ce n'est pas top, il faut truander.

Reellement, l'avantage d'excel ca reste l'accessibilité pour l'ensemble des utilisateurs. (le code c'est bien mais dans le domaine technique, je sais que c'est tres difficile de le faire rentrer dans les moeurs, je bosse la dedans, je suis technicien en mesure physique)

Pour votre appli, j'ignore comment se structure vos problème d'arbre mais je pense que vous pourriez aisément utiliser access dans ce cas la pour supporter vos données.

L'usine a Gaz, c'est le developpeur qui l'a fait. Si beaucoup d'appli bureautique le sont c'est qu'elles ne sont pas designé correctement.
Avec votre experience si vous suivez un shéma de conception, excel ou un autre, je vois pas ou peut se trouver l'usine à gaz
Pour beaucoup d'application de ce genre, la ou ca peche c'est justement à cause du manque de base de donnée

Imaginons votre structure de projet tel que je la vois :
[1 feuille de remplissage, 1 feuille de résultat], [1 classeur de definition]

1 database pour supporter les données élémentaires
id : appartement
component_id : chaudiere_collectif
id : appartement
component_id : climatiseur_collectif
id : maison_individuelle
component_id : chaudiere_individuel
id : maison_individuelle
component_id : climatiseur_individuel

feuille de remplissage :
A1 : 2 A2 : appartement
B1 : 3 B2 : maison individuelle

1 requete SQL, vous composez vos objets (bon en faite plusieurs requetes sql, on est dans du recursif) et implémenter les variables à partir du classeur de definition

Chacun de vos projets a sa propre base access (ou sql) ainsi que son propre classeur de definition ainsi qu'un classeur pour le remplissage ac remp1 et result1 (puis remp2, result2)

Pour moi, j'ai beaucoup de mal à comprendre ou sera l'usine à gaz.

Le modèle de tables relationnel des SGBD n'est pas plus outillé pour gérer des arbres que les feuilles de calcul d'Excel. C'est vrai que beaucoup de projets Excel gagneraient à utiliser un SGBD mais en ce qui me concerne ce serait plutôt des fichiers XML, bien mieux adapté à la gestion des arbres. Par ailleurs il faudrai utiliser deux technologies: Excel et Access. Par expérience je sais que la programmation Access est merdique, ce n'est pas une vrai base de donnée car il n'y a pas les opérateurs ensemblistes. Je préfère nettement un SGBD comme Postresql qui est très performant et permet l'héritage dans la création des tables! Plus j'y pense et plus je m'oriente vers une application XML, basée sur Lisp ou Java, je n'ai pas encore décidé.

Patrick

C'est vrai que pour une structure arbre, excel n'est pas une bonne solution.

Pour le java, l'utilisation d'xml est une bonne solution. Je ne vais pas citer les avantages de ce langage que tu trouveras partout.

Pour le lisp, c'est un langage excellent. Par contre, utiliser lisp avec xml, c'est gaché en partie son extraordinaire potentiel.
Je n'ai jamais utilisé lisp en temps que systeme complet avec interface graphique, je l'ai toujours utilisé en temps qu'extension des softs cadence pour la CAO. (l'implantation s'appelle SKILL et elle est un peu moins puissante.).
Pour les interfaces graphiques, j'ai toujours utilisé l'api de cadence (qui est surement etendu de quelques parts mais a vrai dire, j'ai jamais été très passionné par les interfaces graphiques).

Par contre, c'est vrai que pouvoir ecrire du code interprétable dans des fichiers et l'usage des macros est vraiment top.

Honnetement, pour s'amuser et se faire un peu plaisir, je conseillerai le LISP. Le defaut du LISP reste la faible communauté et donc les compentences pas vraiment disponibles pour le futur.
Par contre, il y'a de tres bonnes documentations ecrites en français.

Oui je partage complètement votre analyse. Mais pourquoi XML ne serait pas compatible avec Lisp? Je pense que Common Lisp à certainement les modules qui vont bien. Par ailleurs Xslt est un langage complètement récursif, proche du Lisp en fin de compte. Je pense que ça devrait bien aller au contraire.

Ce que j'apprécie dans Lisp c'est que du fait qu'il soit un langage de haut niveau ont fait beaucoup moins d'erreur et la programmation est sensiblement plus rapide. Et puis ce qui m'intéresse c'est de développer un langage et pas une interface graphique. Les clickodromes ça m'énerve! Je pense que Lisp se prêtera bien à cet exercice. Reste comme vous l'avez bien fait remarqué que la communauté est peu étendue, ça c'est un problème pour un projet d'entreprise. Je ne pourrai pas être soutenu. Peut être que le couple Java/XML est plus prudent, par ailleurs j'aurai accès à de nombreuses API pour faire des graphs, manipuler les fichiers RTF et PDF, parser des expressions mathématiques, etc.

Patrick

Un des gros interets du LISP, c'est le concept de s-expressions.
En gros tout est du code meme les données, ça ouvre des possibilités titanesques.

Le xml est plus facile à remplir pour un novice, par contre ça peut devenir plus contraignant pour un mec qui s'y connait car a chaque feuille XML si il veut se simplifier la tache, il va ecrire la feuille xslt qui va bien.

Dans le lisp, tu vas simplement ecrire la boule dans tes datas. Celle ci sera executé au chargement du fichier. Ca donnerait (pardonne moi pour mes syntaxes, il y'aura des erreurs)

Code:

---

1 2 3 4 5 6 7

(loop for x from 1 to 3 (collect (list (sprintf "%s%d" "label" x) (list ('param1' 1) ('param2' 1));list );list );collect );loop

---

Le meme fichier xml sera :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

<label1> <param1>1</param1> <param2>1</param2> </label1> <label2> <param1>1</param1> <param2>1</param2> </label2> <label3> <param1>1</param1> <param2>1</param2> </label3>

---

Tu vas me dire que le fichier xml est plus lisible par un humain et plus facilement modifiable.
C'est tout a fait exact.

Le lisp est un langage "difficile" car tout est mélangé. Neanmoins, ça reste un des languages les plus adaptés à la generation de code intermédiaire puisque manipuler des expressions est exactement la meme chose que manipuler des datas.
Apres un des concepts peut etre de faire des feuilles xsl qui vont générer du code LISP (ça me permet plus logique dans ce sens vu le language), peut etre un module existe pour ce genre de cas.

C'est sur que pour les fonctionnalités, java a beaucoup d'avance sur le lisp. Comme vous le dites, vous pourrez bien plus facilement rajouter des fonctionnalités comme les graphs ou la generation de rapport avec du JAVA.

Si j'avais ce choix a faire (LISP ou JAVA) pour une appli d'entreprise, ça serait vers le java que je me tournerai. Non pas que ce language m'attire plus mais j'ai tendance à bouger facilement donc je prefere que l'application soit perenne apres mon départ.

Oui je fais le même calcul, il faut penser à la pérénité de l'application. Lisp reste malheureusement une technologie très universitaire.

En tout cas merci pour votre aide, vous m'avez permis d'avancer!

Patrick