Produits

Framework Scientifique (SFX)

Il est bien connu que les environnements de type «framework», application semi-complète sous forme d’abstractions de haut niveau, ont comme principal objectif de réduire de façon dramatique le temps et les efforts requis pour le développement de programmes pour des domaines d’applications particulier. L’avantage principal, le détail des «class» internes qui permet de compléter le «framework» est invisible au reste du programme et donc, les détails de l’implémentation peuvent être modifiés sans affecter le reste de l’application. Le «framework» que nous avons développé, toujours en cours de développement, est un environnement de programmation flexible pour le prototypage rapide de simulateur physique qui est composé d’un ensemble de class C++ sous forme de librairies. 

Concepts clés de notre application

Énoncé du problème – Résoudre un problème physique par simulation numérique.

Regardons comment les physiciens brisent le problème que nous voulons solutionner en concepts.

Système Physique

Premièrement nous commençons avec le système physique que nous voulons étudier. Chaque système physique est décrit par des objets physiques qui font parties du système que l’on étudie. 

Dans le dessin ci-haut PhysicalSystem et PhysicalObject sont des class de haut niveau d’abstraction. L’association entre PhysicalSystem et PhysicalObject est une association de type “has” ou appelé agrégation comme l’indique le petit losange. En d’autres termes ceci signifie que PhysicalSystem est composé de ou est fait de PhysicalObjects. Comment est-ce que le «framework» utilise ces deux class comme class de base afin d’étendre le système? Il faut noter que dans le diagramme UML (ci-haut) que ces deux class sont des class abstraites ce qui signifie qu’elles ne peuvent être instanciées. Elles ont été construites de cette façon afin d’être en mesure d’utiliser les patrons de conception de type Factory et Abstract Factory. Pour l’instant il faut seulement prendre pour acquis qu’une Factory est une façon standard de créer des objets qui sont similaires mais qui ne sont pas nécessairement reliés entre eux. Une abstract factory crée des objets similaires d’une façon standard ou les objets sont reliés entre eux. Puisqu’il peut y avoir plusieurs types de PhysicalSystems dépendamment de la physique que l’on veut simuler, une factory est très bien adaptée pour nous assister dans la création de ces objets. De la même manière, pour les PhysicalObjects une abstract factory est utilisée pour créer ceux-ci. Un diagramme de class UML plus détaillé ci-dessous:

physics11

Celles-ci ne sont que quelques unes des class qui font partie du SFX package. Au niveau le plus élevé de la hiérarchie de ce diagramme est la PhysicalSystemFactory. Cette class est une class concrète et est responsable pour la création du PhysicalSystem spécifié par l’utilisateur. Ceci se fait par la création d’une instance du PhysicalSystem spécifié par l’usager et ajoute à celui-ci le nombre spécifié de PhysicalObjects en utilisant la PhysicalObjectFactory appropriée.

La prochaine partie est de comprendre la relation entre les autres class du système du simulation package et leur association avec le PhysicsSimulator dans le SFX package. Le diagramme UML ci-dessous montre ces relations:

physics13

Les class au bout des flèches sont des Interfaces. Une interface spécifie un contrat qui doit être remplie par la class qui l’implémente. Par exemple,   l’interface IFinalReport spécifie qu’une méthode du nom de report doit être implémentée et qui prend comme arguments une instance de Simulation et une de PhysicalSystem.

Comme on l’a déjà  mentionné dans la section «Vue d’ensemble de la class PhysicsSimulator», la class PhysicsSimulator a deux responsabilités. La première est de créer des instances des class spécifiées par l’usager et qui implémente les interfaces de la figure ci-haut. Elle est aussi responsable pour l’appel au temps approprié des méthodes qui exécute le code de chaque class qui implémente l’interface. Pour continuer avec l’exemple de report, le PhysicsSimulator va créer une instance de la class IFinalReport et la méthode report sera appelée une fois la simulation complétée.

Les quatre interfaces que l’on montre ici sont celles pour lesquelles chaque développeur qui a l’intention d’utiliser le «framework» devra fournir une implémentation.

Le nom de chacune des interfaces parle par lui-même. L’implémentation de la class IPhysicalConfiguration est pour la mise en place de la solution initiale. Le PhysicsSimulator utilise l’implémentation de la class IPhysicalAlgorithm pour intégrer numériquement les équations du mouvement St-Venant. Dans l’exemple d’application un solveur de Runge-Kutta au deuxième ordre est utilisé pour résoudre l’équation semi-discrète. L’implémentation de la class IPhysicalMeasurement nous renseigne sur quelles quantités physiques seront mesurés périodiquement. L’implémentation de la class IFinalReport nous donne un sommaire sur les statistiques et les résultats finaux qui sont fournis à l’utilisateur sous forme d’un simple format texte.

La dernière class du SFX package est la class IDataStore. Le but de ces class (ses dérivées) est de rendre la class PhysicsSimulator transparente au reste de l’application sur la façon de sauver les données.

physics14

L’interface IDataStore spécifie qu’une implémentation doit être fournie pour les méthodes open(), save() et close() du data store. La seule class qui est implémentée présentement est le FileDataStore laquelle utilise la méthode toString() de la class IPhysicalMeasurement

NOUVELLES ET ARTICLES See all

  • Fonction Lambda, un incontournable

    Tips and Tricks!

    Les fonctions anonymes dites “lambda” introduites depuis C++11 trouvent de nombreux cas d’utilisation où l’on aurait à écrire une fonction pour réaliser des taches simples, qui nécessite quelques lignes de code. Je présente un exemple de l’utilisation de celle-ci de notre environnement de programmation.

clients and partners

Autolog