Spécifications pour Amda NG

Introduction

Le chantier de refonte d'Amda est lancé: l'intégration de données externes, que ce soit des données plasma ou bien des images du soleil, nécessite une reconstruction du système. On pourra trouver une liste exhaustive des impératifs techniques nécessitant une refonte dans le document AmdaRefactoring ainsi qu'un description des solutions envisagées ici: AmdaNgArchitecture.

Mais au delà des contraintes d'ordre purement informatique, c'est toujours le besoins de l'utilisateur qui guide le développement d'un projet. Ces besoins évoluent, et a mesure de leur travail, les utilisateurs scientifiques d'Amda rencontrent des obstacles que nous devons aider à résoudre.

C'est tout l'intérêt du présent document qui est là pour recueillir l'ensemble des requête d'évolution.

Echo de la réunion Interne

Christian nous a fait part de desideratas et autres blocages rencontrés pendant le séjour de ses stagiaires. Je reproduis les paroles, mais je ne comprends pas tout: il faudrait une rencontre développeurs/scientifiques pour éclaircir ces points:

généralités

1. pb d'archi entre Plot et DL (bcp d'arguments pour l'un moins pour l'autre)
2. alimentation séparée des différents arbres de données, à réunifier ???
3. un module global pour les différents menus ???
4. transformation de coordonnées, modèles, distance à la couche neutre
5. scatter plot, fonctions du temps

VHM

1. complications pour associer une image solaire à un évenement de la magnétosphere
2. accéder au catalogue d'évènements solaires EGSO
3. faire appel à des compétences scientifiques solaires pour spécifier les évènements de catalogues
4. ouvrir le catalogue d'évènements à de la Recherche conditionnelle pour extraire des time tables ?

Chantiers

architecture, modularisation

travail en cours par Elena et Richard, décrit dans le document de référence en évolution constante: AmdaNgArchitecture.

Les deux principaux use cases retenus pour valider la nouvelle archi:

• import ext data to ddsys
• get ext image data from user interface

ces deux cas sont emblématiques des interactions avec des données extérieures et permettront de mettre à l'épreuve les idées retenues à la conception pour des mises au points inévitables avant de continuer sur l'implémentation de UseCase suivant: l'interaction avec Sitools

connexion bases de données externes, renseignement à la volée du système, développement des interface machine-machine

vaste programme, déjà pris en compte dans la nouvelle archi et mis à l'épreuve lors de l'implémentation des deux premiers usecases. Ce sera l'occasion de mettre au point (ou réinventer) les solutions retenues.

développement fonctions graphiques

à lister, dépend nouvel UserInterface ?

développement fonction numériques, analyse, fonctions temporelles

à lister

développement du event list manager et fonctions sur les event lists

à lister et voir le document de référence: AmdaTimeTables

développement des user interfaces

Les user_interfaces ?

il faut évidemment améliorer l'interface web actuelle. Des pistes sont évoquées dans AmdaRefactoring, mais il faut bien formaliser ça plus exhaustivement.

à noter que le découplage UserInterface/AmdaServer est primordial avant d'envisager tout développement supplémentaire sur l'interface; c'est aussi l'objectif numéro 2 d'amda NG aprés (ou en même temps) que l'interfaçage avec sitools.

Toujours du javascript mais plus portable ?

Onglet "External Data Tree"

Mardi 11 Sept 2007: Elena, Vincent, Richard

Il est convenu de rajouter à l'interface utilisateur un onglet pour autoriser l'élaboration par l'utilisateur de son arbre de données personnelles. Cet arbre perso (userTree) est construit à partir des données disponibles sur les bases extérieures.

Visuellement, l'écran est partagé en deux verticalement:

• les arbres de données externes à gauche
• l'arbre utilisateur à droite.

Les opérations possibles sur la partie gauche (arbre externe) sont:

• ajouter un noeud terminal (typiquemement un paramètre) à l'arbre perso.
• ajouter un noeud de niveau terminal-1 (jeu ou instrument) à l'arbre perso.

Les opérations possibles sur la partie droite (arbre utilisateur) sont:

• suppression d'un noeud terminal.
• suppression d'une branche complète.

L'arbre utilisateur résultant sera accessible en lecture dans tous les autres onglets de l'IHM, à savoir Workspace, Plot, Download, Search.

Le mode d'intégration du nouvel arbre dans l'arborescence reste à préciser.

On se laisse la possibilité de mettre en oeuvre un principe d'Alias pour pallier l'excessive longueur de noms de variable.

Voir Specs Precises décrivant l'architecture mise en oeuvre pour réaliser ce module.