Diferencias entre MMS_0.5 y MMS_0.6

Diferencias generales

El paquete MMS

La diferencia más evidente de MMS_0.6 respecto a MMS_0.5 es su implementación en forma de paquete TOL: MMS pasa a ser un NameBlock que contiene todas las clases y funciones definidas anteriormente como globales.

Clases

Las clases en MMS_0.6 pierden el prefijo "MMS." que las caracterizaba y que ahora se sustituye con la llamada via el NameBlock del paquete.

En general las clases pasan de: @MMS.[ClassName] a: MMS::@[ClassName].

Nótese que localmente (en el código interno de desarrollo del paquete) estas llamadas no van precedidas de MMS::.

Contenedor principal

El contenedor principal que en MMS_0.5 se denominaba MMS, ahora pasa a llamarse Container de modo que su llamada global pasa a ser: MMS::Container.

Jerarquía entre objetos

Las clases en MMS_0.6 siguen una jerarquía, de modo que naturalmente un objeto necesita de otro superior para existir y poder definirse. Esto da naturalidad a las relaciones padre-hijo implementadas en el módulo de modelos en MMS_0.5 con las clases @MMS.Parent y @MMS.Child. Asimismo impide la creación aislada de objetos no principales (que no son primeros en la jerarquía) y hace más comprensible la comunicación entre los objetos dentro de la jerarquía.

Desde el punto de vista de la implementación esto puede apreciarse en el atributo _parent_ de las clases o en el argumento parent de sus constructores.

Referencias y Objetos dentro de objetos

Se detectó un problema de eficiencia grave en TOL al introducir NameBlocks dentro de NameBlocks, de modo que toda estas relaciones se implementan interponiendo un Set entre ellos. Esto facilita además la redefinición de estos atributos y su tratamiento como referencias.

A causa de la existencia de referencias a la clase principal entre las clases hijas los objetos principales de volvían idecompilables, para evitar esto se creó el par MMS::@[Object] - MMS::@[Object]Kernel para cada clase principal de acuerdo al tique ​#863 de TOLProject. Posteriormente, (versión MMS.0.6020) se solucionó de manera alternativa considerando todos los objetos prinicipales dependientes (i) de otro objetos principal (objetos suplementarios) o (ii) del contenedor principal y haciendo la dependencia con éste no explícita (y evitando así los priblemas de decompilación) ya que el contendor es único y accesible globalmente.

Diferencias en el Módulo de Variables

La estructura de clases del módulo de variables en MMS_0.5 está formada por un único tipo de clase (@MMS.Variable) que representa a una variable con dos clases derivadas según la gramática de la variable.

• @MMS.Variable (abstracta)
  • @MMS.VariableSerie
  • @MMS.VariableMatrix

En la versión 0.6, el módulo se amplía con un objeto contenedor de variables denominado "conjunto de datos" (MMS::@DataSet) que agrupa en torno a sí un conjunto de variables entre las que pueden existir dependencias. Desaparecen las clases derivadas de MMS::@Variable según la gramática. Aparece una nueva clase para la definición de variables virtuales según el escenario: MMS::@BaseVariable.

• MMS::@DataSet
• MMS::@Variable
• MMS::@BaseVariable

La jerarquía de objetos queda como sigue:

• MMS::@DataSet
  • MMS::@Variable
  • MMS::@BaseVariable

Diferencias en MMS::@Variable

Atributo Source

Desaparece el atributo "_.source" al no tener clara su utilidad. Según el ejemplo de "Matriculación de Vehículos" ésta se utiliza para indicar de dónde se obtuvieron los datos. Este tipo de información debería indicarse en el campo descripción que es lo bastante general para indicar todo lo que se necesite.

Otro tipo de atributo "source" podría definirse en el momento en el que MMS tuviera un cierto control sobre la procedencia de los datos y ésta pudiera ser una base de datos, por ejemplo.

Diferencias en el Módulo de Modelos

La estructura de clases del módulo de modelos está formada por una clase "modelo" (@MMS.Model) sobre la cual se construyen el resto de objetos que permiten la definición del modelo.

Estas clases en la versión 0.5 son:

• @MMS.Model
• @MMS.ModelVariable (abstracta)
  • @MMS.Output
    • @MMS.OutputARIMA
  • @MMS.Input
• @MMS.BaseParameterExpTerm
• @MMS.BaseExpTerm (abstracta)
  • @MMS.BaseExpTermUniInput (abstracta)
    • @MMS.BaseExpTermLinear
    • @MMS.BaseExpTermOmega
    • @MMS.BaseExpTermRatio
  • @MMS.BaseExpTermMultiInput (abstracta)
• @MMS.Parameter (abstracta)
  • @MMS.ParameterExpTerm
  • @MMS.ParameterHyper
  • @MMS.ParameterMissing
  • @MMS.ParameterARIMA
  • @MMS.ParameterResidual
  • @MMS.ParameterSigma2
• @MMS.ExpTerm
• @MMS.Combination
• @MMS.CombinationTerm
• @MMS.Hierarchy
• @MMS.HierarchyTerm
• @MMS.Prior
• @MMS.Constraint

y se estructuran de la siguiente forma:

• @MMS.Model
  • @MMS.Output
    • @MMS.ParameterMissing
    • @MMS.ParameterARIMA
    • @MMS.ParameterResidual
    • @MMS.ParameterSigma2
  • @MMS.BaseExpTerm
    • @MMS.BaseExpTermParameter
    • @MMS.Input
      • @MMS.ParameterMissing
  • @MMS.ExpTerm
    • @MMS.ParameterExpTerm
  • @MMS.Combination
    • @MMS.CombinationTerm
  • @MMS.Hierarchy
    • @MMS.HierarchyTerm
      • @MMS.ParameterHyper
    • @MMS.ParameterSigma2
  • @MMS.Prior
  • @MMS.Constraint

Nótense los siguientes aspectos:

1. Las instancias de clases derivadas de @MMS.ModelVariable no comparten un único lugar en el modelo, de modo que se admite un rol bastante diferenciado en inputs y outputs.
2. Los inputs son elementos creados específicamente para un término explicativo base, de modo que dos términos no podrían contener el mismo input (aunque sí dos inputs definidos de la misma forma).
3. Los términos explicativos son elementos del modelo y no de un output, de hecho, un mismo término explicativo puede pertenecer a varios outputs.
4. Parte de la definición de un término explicativo está incluida en un término base, de manera que, por ejemplo, hay una dependencia de un único parámetro base con varios parámetros de término explicativo.
5. Las restricciones y las distribuciones a priori de los parámetros o combinaciones son externas a ellos y no elementos suyos.
6. Hay dos clases (junto a sus clases complementarias) que se crean independientemente de la creación del modelo con la intención de poder extender su uso y que tienen la siguiente estructura:
   • @MMS.ARIMAModel
     • @MMS.ARIMABlock
   • @MMS.Transformation
     • @MMS.TransformationBlock

En la versión 0.6 se revoluciona en gran parte la estructura del módulo intentando evitar algunos dificultades encontradas y dándole un orden más adecuado.

Las clases en la versión 0.6 son:

• MMS::@Model
• MMS::@MVariable
• MMS::@Transformation (abstracta)
  • MMS::@Transformation.BoxCox
• MMS::@MNode (abstracta)
  • MMS::@Submodel
  • MMS::@Hierarchy
• MMS::@HierarchyTerm
• MMS::@Noise (abstracta)
  • MMS::@NoiseNormal
  • MMS::@NoiseARIMA
• MMS::@NoiseARIMABlock
• MMS::@MElement
  • MMS::@Parameter (abstracta)
    • MMS::@ParameterLinear
    • MMS::@ParameterNonLinear
    • MMS::@ParameterHyper
    • MMS::@ParameterMissing
    • MMS::@ParameterARIMA
    • MMS::@ParameterSigma2
  • MMS::@BaseParameter (abstracta)
    • MMS::@BaseParameterMissing
  • MMS::@MCombination
  • MMS::@MEquivalence
• MMS::@Constraint
• MMS::@Prior
• MMS::@ExpTerm (abstracta)
  • MMS::@ExpTermLinear
  • MMS::@ExpTermOmega
  • MMS::@ExpTermRatio
  • MMS::@ExpTermNonLinear

Creando una jerarquía de objetos como la siguiente:

• MMS::@Model
  • [MMS::@DataSet]
  • MMS::@MVariable
    • MMS::@ParameterMissing : MMS::@MElement
    • MMS::@BaseParameterMissing : MMS::@MElement
  • MMS::@Submodel : MMS::@MNode
    • MMS::@ExpTerm
      • MMS::@ParameterLinear : MMS::@MElement
      • MMS::@ParameterNonLinear : MMS::@MElement
  • MMS::@MCombination : MMS::@MElement
  • MMS::@Hierarchy : MMS::@MNode
    • MMS::@HierarchyTerm
      • MMS::@ParameterHyper : MMS::@MElement
  • MMS::@MEquivalence : MMS::@MElement

donde las clases derivadas de MMS::@MNode y MMS::@MElement se amplían con las estructuras:

• MMS::@MNode
  • MMS::@Noise (MMS::@NoiseNormal | MMS::@NoiseARIMA)
    • MMS::@ParameterSigma2 : MMS::@MElement
    • MMS::@NoiseARIMABlock
      • MMS::@ParameterARIMA : MMS::@MElement

• MMS::@MElement
  • MMS::@Prior
  • MMS::@Constraint

Nótense los siguientes aspectos:

1. Las variables del modelo (MMS::@MVariable) son contenidas como elementos del modelo, desaparece una diferencia clara entre outputs e inputs.
2. La información de los outputs como modelos de observaciones está recogida en una nueva clase submodelo: MMS::@Submodel.
3. Los términos explicativos pasan a ser elementos de un submodelo, de modo que estrictamente desaparece la posibilidad de definir parámetros que pertenezcan simultáneamente a distintos submodelos (parámetros internodales). Sin embargo, pueden definirse relaciones de equivalencia entre parámetros (MMS::@MEquivalence) en las que se indica que dos o más parámetros han de estimarse (de ser posible) como uno solo.
4. Desaparecen los términos explicativos base, aunque podrían volver a crearse como plantillas generadoras de términos explicativos.
5. Las restricciones y las distribuciones a priori de los parámetros o combinaciones (elementos del modelo) son internas a ellos, les pertenecen.
6. La estructura de la información ARIMA es recogida por la nueva clase MMS::@NoiseARIMA como un tipo de ruido (MMS::@Noise) de un nodo o segmento del modelo (MMS::@MNode).
7. El manejo de las transformaciones cambia, las transformaciones no se construyen según los criterios del usuario, sino que ha de escogerse alguna de las familias derivadas ya implementadas.
8. Aparecen nuevas clases abstractas encargadas de aunar en torno a sí, distintos tipos de objetos que comparten naturaleza o cualidades:
   • MMS::@Submodel, MMS::@Hierarchy -> MMS::@MNode
   • MMS::@Parameter, MMS::@BaseParameter, MMS::@MCombination, MMS::@MEquivalence -> MMS::@MElement
   • MMS::@NoiseARIMA, MMS::@NoiseNormal -> MMS::@Noise