wiki:Dif0.6

Context Navigation

close Warning: Can't synchronize with repository "(default)" (/var/svn/mms does not appear to be a Subversion repository.). Look in the Trac log for more information.

Version 6 (modified by Pedro Gea, 15 years ago) (diff)
--

Diferencias entre las versiones MMS 0.5 y MMS 0.6

Diferencias generales

Jerarquía entre objetos

Las clases en la 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 0.5 con las clases @MMS.Parent y @MMS.Child. Asimismo impide la creación aislada de objetos no principales (los 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.

La existencia de referencias de la clase principal entre las clases hijas los objetos creados así son idecompilables, para evitar esto se crea un par @MMS.Object - @MMS.ObjectKernel para cada clase principal de acuerdo al tique #863 de TOLProject.

Diferencias en el Módulo de Variables

La estructura de clases del módulo de variables en 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 y aparece una clase derivada para las variables calculadas a partir de otras variables. También aparece una nueva clase para la definición de variables virtuales según el escenario: @MMS.BaseVariable.

@MMS.DataSet
@MMS.DataSetKernel
@MMS.Variable
- @MMS.VariableCalculated
@MMS.BaseVariable

La jerarquía de objetos queda como sigue:

@MMS.DataSet [@MMS.DataSetKernel]
- @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:

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.
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).
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.
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.
Las restricciones y las distribuciones a priori de los parámetros o combinaciones son externas a ellos y no elementos suyos.
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.ModelKernel
@MMS.ModelVariable
- @MMS.Output (?)
- @MMS.Input (?)
@MMS.ModelNode (abstracta) (!) @MMS.ModelBlock
- @MMS.Submodel
- @MMS.Hierarchy
@MMS.HierarchyTerm
@MMS.Noise (abstracta)
- @MMS.NoiseNormal
- @MMS.ARIMA
- @MMS.Prior
@MMS.ARIMABlock
@MMS.ModelElement
- @MMS.Parameter (abstracta)
  - @MMS.ParameterLinear
  - @MMS.ParameterNonLinear
  - @MMS.ParameterHyper
  - @MMS.ParameterMissing
  - @MMS.ParameterARIMA
  - @MMS.ParameterSigma2
- @MMS.BaseParameter (abstracta)
  - @MMS.BaseParameterMissing
- @MMS.ModelCombination
@MMS.Constraint
@MMS.ExpTerm (abstracta)
- @MMS.ExpTermLinear
- @MMS.ExpTermOmega
- @MMS.ExpTermRatio
- @MMS.ExpTermNonLinear

Creando una jerarquía de objetos como la siguiente:

@MMS.Model [@MMS.ModelKernel]
- [@MMS.DataSet]
- @MMS.ModelVariable
  - @MMS.ParameterMissing : @MMS.ModelElement
  - @MMS.BaseParameterMissing : @MMS.ModelElement
- @MMS.Submodel : @MMS.ModelNode
  - @MMS.ExpTerm
    - @MMS.ParameterLinear : @MMS.ModelElement
    - @MMS.ParameterNonLinear : @MMS.ModelElement
- @MMS.ModelCombination
- @MMS.Hierarchy : @MMS.ModelNode
  - @MMS.HierarchyTerm
    - @MMS.ParameterHyper : @MMS.ModelElement

donde las clases derivadas de @MMS.ModelNode y @MMS.ModelElement se amplían con las estructuras:

@MMS.ModelNode
- @MMS.Noise (@MMS.NoiseNormal | @MMS.ARIMA)
  - @MMS.ParameterSigma2 : @MMS.ModelElement
  - @MMS.ARIMABlock
    - @MMS.ParameterARIMA : @MMS.ModelElement

@MMS.ModelElement
- @MMS.Prior
- @MMS.Constraint

Download in other formats:

Plain Text