Africa Rational

Formalisation technique du modèle

1.

La formalisation technique du modèle correspond au choix de la manière de « concrétiser » la formalisation conceptuelle du modèle. Il s’agit en quelques sortes de traduire des constructions abstraites (par ex. des villes dont la densité peut varier au fur et à mesure du temps) en modèle concret (par exemple : un ensemble de cellules caractérisées par une variable densité + la localisation d’un centre). Cela se fait en général en deux étapes : le choix d’un formalisme (mathématique, informatique, physique, etc.) et l’implémentation concrète (écrire d’un système d’équations mathématiques, code informatique, réalisation d’une maquette, etc.)

Guide de questionnement :

• Quel formalisme a été retenu pour la traduction du modèle conceptuel au modèle implémenté ?
• Par quel biais ce formalisme est-il concrètement implémenté dans le modèle (ex. : code informatique, équations aux dérivées partielles, etc.)
• Connaissez-vous d’autres modèles ayant procédé à des choix différents d’implémentation ?
• Le modèle étudié est-il à cet égard « standard » dans la littérature ou bien est-il original et le cas échéant pourquoi ce choix a été fait ?

• Le modèle Tasha est une micro simulation (Agent Based Modeling) qui utilise un formalisme informatique. Ce formalisme est implémenté par le biais de la programmation orientée objet et langage C#

2.

La formalisation conceptuelle du modèle a amené à proposer des objets élémentaires dans le modèle (un champ, un agent, etc.) et des relations entre ces objets : par exemple dans un modèle agent représentant les déplacements de piétons, chaque agent « piéton » interagit avec chaque autre agent « piéton » et par ailleurs avec l'environnement physique (poteaux, murs, etc.). A l'étape de conception, il s'agit de transcrire ces principes en règles / équations / etc. qui soient précises et ne laissent pas de place à l'interprétation lors de l'exécution du modèle. La machine (dans le cas d'un modèle informatique) doit savoir à chaque instant quelle « règle » appliquer, que cette règle soit déterministe ou non. Il s'agit donc dans cette étape de décrire avec précision ces règles et de les resituer par rapport à d’autres implémentations existant dans la littérature (autrement dit d’autres manières de formaliser ou d’écrire ces mêmes règles dans d’autres modèles de la littérature). Vous pouvez par exemple vous demander quelles fonctions sont mises en œuvre lors de cette transcription [par ex. réseaux de neurones ?]

Guide de questionnement :

• Comment sont concrètement implémentés les objets / relations entre objets issus de la formalisation conceptuelle du modèle ?
• Cette « transcription » a-t-elle donné lieu à des modifications dans les objets / relations entre objets conceptuels présents dans le modèle ?
• Connaissez-vous d’autres modèles ayant procédé à des choix différents dans la transcription des objets / relations entre objets ?
• Est-ce que votre modèle est à la pointe de la connaissance du point de vue de son « implémentation technique » ?

• Le modèle TASHA se base sur les objets élémentaires suivants : ménages, personnes, projets, activités et déplacements. Pour les implémenter, TASHA utilise des classes (entités du modèle) qui sont schématisées ci-dessous :

[pic 1]

Source : A Prototype Model of Household Activity/Travel Scheduling, Eric J. Miller et al

• Le schéma ci-dessus montre également les relations entre les objets : Chaque ménage est constitué de personnes et chaque personne a un programme qui contient des activités ainsi que les déplacements nécessaires pour les réaliser. Les ménages aussi bien que les personnes ont des projets. Chaque projet contient une série d’activités qui sont affectées aux personnes ou aux ménages.
• Les dernières versions de TASHA (GTA model V4.0) représentent également les interactions au sein des ménages et le partage de responsabilités (exemple : accompagnement des enfants) et des ressources (exemple : voiture)

3.

La transcription de règles dans le modèle implémenté requiert des choix techniques : par exemple la plateforme (le langage /  logiciel dans lequel est codé le programme dans le cas d'un modèle informatique). Ce choix peut provenir pour partie de considérations techniques liées à la performance (besoin d’une certaine puissance de calcul, besoin de langages de programmation orientés agents, etc.) et pour partie de considérations externes à la « sphère du modèle » (licences logicielles déjà acquises, habitude de programmation, besoin de transférabilité avec d’autres modèles). Il convient ici de préciser les choix techniques qui ont été faits et de les comparer à la littérature existante.

Guide de questionnement :

• Sur quelle plateforme / logiciel / autre dispositif est codé le modèle étudié ?
• Le modèle ainsi constitué est-il dépendant d’un environnement technique (par exemples s’il s’agit d’un plugin dépendant d’un logiciel, etc.) ? Vous parait-il pérenne ?
• Quelles sont les performances du modèle ? (ex. temps pour une simulation)
• Comparez les arbitrages réalisés en termes de performance / pérennité / coût de production par rapport aux modèles proches.

• Pour le modèle TASHA, la plateforme utilisée pour coder la solution est Visual C. Le modèle est implémenté dans le logiciel XTMF (eXtensible Travel Modelling Framework) développé par l’université de Toronto. Pour les auteurs, le choix de la simulation ABM (Agent Based Modeling) permet d’avoir des temps de calcul très compétitifs.

• Quant aux couts de production, Eric J. Miller évoque ‘une somme d’argent ridicule’ et six mois de travail. Le secret c’est les très bonnes relations avec la région du grand Toronto

• Par ailleurs, la solution nous semble être pérenne car depuis la première version du modèle en 2001, 2 autres versions ont été développées. Actuellement la version V.4 est en cours de création.

4.

L’ergonomie du modèle renvoie à l’  « expérience » de l’utilisateur du modèle. Le modèle peut être très simple d’utilisation (une interface web par exemple) ou plus « basique » (par exemple une macro VBA Excel qui implique que certaines cellules précises soient remplies selon une règle rigide). L’ergonomie concerne aussi les possibilités d’action sur l’objet « modèle » par exemple ce que l’utilisateur peut changer ou non, et les qualités visuelles du modèle. L’explicitation des choix faits sur l’ergonomie du modèle fait partie de l’étape de conception, que l’interface soit interactive ou non. Au niveau de la conception, les choix à faire portent principalement sur le confort d’utilisation et il convient que les choix soient en adéquation avec l’étape 1 (spécification) et l’étape 3 (utilisation).

Guide de questionnement :

• Comment se présente « concrètement » à l’utilisateur  le modèle étudié? Quelles qualités visuelles du modèle ? Quelle interface utilisateur ?
• Quel degré d’expertise est requis pour l’utilisation de ce modèle ?
• D’autres choix ont-ils été faits pour les modèles proches, et si oui pourquoi ?

• Le modèle TASHA est implémenté dans le logiciel XTMF (eXtensible Travel Modelling Framework) développé à l’université de Toronto pour plusieurs raisons, entre autres, améliorer l’expérience utilisateurs et l’ergonomie du modèle.

• Ce logiciel XTMF comporte une centaine de modules afin de créer de nouveaux modèles, de paramétrer et calibrer des modèles existants et aussi pour utiliser ces modèles. Cette multitude d’usages nous pousse à croire que le modèle demande un certain niveau d’expertise et n’est pas destiné au grand public.

5.

Les entrées / sorties du modèle ne sont pas qu’une question de spécification : à l’étape de la conception du modèle, il faut que le modèle implémenté soit capable d’utiliser effectivement les données fournies en entrée, ce qui impose souvent de préparer un petit module de « traduction » du fichier d’entrée en données attendues par le modèle. C’est la même chose en sortie, il y a une différence entre ce qu’on pourrait calculer à l’issue du modèle et ce que génère effectivement le modèle comme sorties. Une attention particulière doit être portée à la conception des entrées et des sorties, surtout lorsqu’il s’agit de travailler avec plusieurs modèles dont les sorties de l’un sont utilisées en entrée de l’autre.

Guide de questionnement :

• Comment les données d’entrée sont-elles concrètement « importées » dans le modèle étudié : des adaptations / compromis sont-ils faits par rapport à ce qui été attendu à l’issue de l’étape de spécification ? Pour les cas des modèles de simulation, nous vous encourageons à détailler ici comment sont générées les conditions initiales du modèle.
• Quelles données sont produites en sortie du modèle étudié ? S’agit-il d’indicateurs synthétiques ou sont-elles directement issues des objets / relations entre objets du modèle implémenté ? Y’a-t-il adéquation entre les données de sorties et les indicateurs attendus à l’étape de spécification ?
• Les entrées / sorties du modèle étudié diffèrent-elles beaucoup de celles des autres modèles proches ?
• Analyser quelles différences proviennent directement de l’étape de spécification et lesquelles proviennent de cette étape de conception.

• Le modèle TASHA prend en données d’entrée les données de population et emplois (âges, sexe,  emploi…) et les données de déplacement sur une période de 24h.   C’est le modèle qui contient des procédures de synthèse pour convertir les données d’entrée agrégées par zones en données désagrégées par personne et ménage nécessaires pour la micro-simulation.

• Pour les sorties du modèles, le modèle permet d’avoir les formats standards utilisables directement en entrées de logiciels comme EMME, MATSIM, VISUM…(TASHA est complètement interfacée avec ces logiciels)