Revisar el diseño de la estructura de las clases de resultados

[Pedro Gea]

Algunos tiques apuntan a una revisión del diseño de las clases de resultados. Véase #543 o #469.

Las mejoras necesarias estarían relacionadas con:

• la comunicación con las clases del módulo de modelos: el acceso desde un objeto al objeto paralelo en la definición,
• la comunicación dentro del mismo bloque de resultados: el acceso desde un objeto-resultado al objeto-resultado padre, y
• la adecuada creación y destrucción de las instancias.

[Pedro Gea]

Es necesario también revisar y completar particularmente algunas clases de previsión (véase #448).

[Pedro Gea]

Véase también el tique #336.

[Pedro Gea]

(In [2403]) Se crean métodos especiales para facilitar la adaptación de los objetos a los estimadores y poder eliminar así la dependencia provisional de los adaptadores con las clases de resultados.
Refs #563

[Pedro Gea]

(In [2404]) Se da homogeneidad a las clases de las estrategias y subestrategias.
Se reubica el adaptador de resultados (y los resultados nativos) así como otra información no persistente en la estrategia.
Se facilita el acceso a otra información temporal de estimación (y se retarda su destrucción) para facilitar la comprensión de los mecanismos de adaptación y su depuración.
Se añaden informes de los procesos de estimación en la estrategia.
Se separa la subestrategia LinReg en dos según su uso con submodelos o con jerarquías.
Se elimina la dependencia provisional de algunos adaptadores con las clases de resultados.
Refs #563, #510

[Pedro Gea]

(In [2411]) Se eliminan los métodos especiales de las clases de resultados creados para facilitar la adaptación de los objetos a los estimadores.
Refs #563

[Pedro Gea]

(In [2485]) Se deshacen los cambios sobre los métodos ::GetRoute de los parámetros, ya que esta solución para #573 introducía nuevos errores.
Se introduce un mecanismo alternativo para GetAbsoluteIdentifier(?) en los parámetros de los resultados para acceder provisionalmente un identificador absoluto, hasta que las clases de resultados se revisen (#563) para poder introducirlo adecuadamente (#543).
Se introduce una alternativa de ObtainMElement para indexar los parámetros por nombre allí donde corresponde.
Se introduce una variante de la función tcl TclList2SetOfText capaz de tratar textos con comillas en su interior.
Refs #543, #563, #573

[Pedro Gea]

Se sugiere incorporar un método general GetDefinition en las clases de resultados que faciliten el acceso a la instancia del objeto correspondiente en la definición del modelo, y facilitar así el acceso a otros métodos que no hayan sido incorporados en las clases de resultados. Véase #680.

[Pedro Gea]

Véase también #569.

[Pedro Gea]

(In [2886]) Se revisan las clases de resultados dotándolas de una estructura jerárquica padre-hijos semejante a la del diseño del módulo de modelos.
Cada instancia de las clases de resultados (o de previsiones) está vinculada con dos instancias:
(i) su par en el diseño del módulo de modelos, y que puede obtenerse mediante ::GetDefinition y
(ii) la instancia padre en el árbol de resultados ::GetParent(?). Véase: #563.

Se incorpora la ruta a las instancias de los objetos de resultados. Véase: #543.

Se simplifica el uso de escenarios e intervalos de previsión, manteniendo aún así los métodos relacionados con los FScenarios y los FIntervals.
Véanse: #570, #794.

Se incorporan iconos característicos para los parámetros en las clases de resultados y previsiones y se extiende su menú contextual a las combinaciones de parámetros. Véase: #362.

Refs #563, #543, #570, #794, #362