| | 1 | = Diferencias entre las versiones MMS 0.5 y MMS 0.6 = |
| | 2 | |
| | 3 | == Diferencias generales == |
| | 4 | |
| | 5 | === Jerarquía entre objetos === |
| | 6 | |
| | 7 | Las clases en la 0.6 siguen una jerarquía, de modo que naturalmente |
| | 8 | un objeto necesita de otro superior para existir y poder definirse. |
| | 9 | Esto da naturalidad a las relaciones padre-hijo implementadas en |
| | 10 | el módulo de modelos en 0.5 con las clases @MMS.Parent y @MMS.Child. |
| | 11 | Asimismo impide la creación aislada de objetos no principales (los primeros |
| | 12 | en la jerarquía) y hace más comprensible la comunicación entre los objetos |
| | 13 | dentro de la jerarquía. |
| | 14 | |
| | 15 | Desde el punto de vista de la implementación esto puede apreciarse |
| | 16 | en el atributo _parent_ de las clases o en el argumento parent de |
| | 17 | sus constructores. |
| | 18 | |
| | 19 | === Referencias y Objetos dentro de objetos === |
| | 20 | |
| | 21 | Se detectó un problema de eficiencia grave en TOL al introducir NameBlocks |
| | 22 | dentro de NameBlocks, de modo que toda estas relaciones se implementan |
| | 23 | interponiendo un Set entre ellos. |
| | 24 | Esto facilita además la redefinición de estos atributos y su tratamiento |
| | 25 | como referencias. |
| | 26 | |
| | 27 | La existencia de referencias de la clase principal entre las clases hijas |
| | 28 | los objetos creados así son idecompilables, para evitar esto se crea |
| | 29 | un par @MMS.Object - @MMS.ObjectKernel para cada clase principal |
| | 30 | de acuerdo al tique #863 de TOLProject. |
| | 31 | |
| | 32 | == Diferencias en el Módulo de Variables == |
| | 33 | |
| | 34 | La estructura de clases del módulo de variables en 0.5 está formada |
| | 35 | por un único tipo de clase (@MMS.Variable) que representa a una |
| | 36 | variable con dos clases derivadas según la gramática de la variable. |
| | 37 | |
| | 38 | * @MMS.Variable (abstracta) |
| | 39 | * @MMS.VariableSerie |
| | 40 | * @MMS.VariableMatrix |
| | 41 | |
| | 42 | En la versión 0.6, el módulo se amplía con un objeto contenedor |
| | 43 | de variables denominado "conjunto de datos" (@MMS.DataSet) que |
| | 44 | agrupa en torno a sí un conjunto de variables entre las que pueden |
| | 45 | existir dependencias. |
| | 46 | Desaparecen las clases derivadas de @MMS.Variable según la gramática |
| | 47 | y aparece una clase derivada para las variables calculadas a partir |
| | 48 | de otras variables. |
| | 49 | También aparece una nueva clase para la definición de variables |
| | 50 | virtuales según el escenario: @MMS.BaseVariable. |
| | 51 | |
| | 52 | * @MMS.DataSet |
| | 53 | * @MMS.Variable |
| | 54 | * @MMS.VariableCalculated |
| | 55 | * @MMS.BaseVariable |
| | 56 | |
| | 57 | La jerarquía de objetos queda como sigue: |
| | 58 | |
| | 59 | + @MMS.DataSet |
| | 60 | + @MMS.Variable |
| | 61 | + @MMS.BaseVariable |
| | 62 | |
| | 63 | === Diferencias en @MMS.Variable === |
| | 64 | |
| | 65 | '''Atributo Source''' |
| | 66 | |
| | 67 | Desaparece el atributo "_.source" al no tener clara su utilidad. |
| | 68 | Según el ejemplo de "Matriculación de Vehículos" ésta se utiliza |
| | 69 | para indicar de dónde se obtuvieron los datos. |
| | 70 | Este tipo de información debería indicarse en el campo descripción |
| | 71 | que es lo bastante general para indicar todo lo que se necesite. |
| | 72 | |
| | 73 | Otro tipo de atributo "source" podría definirse en el momento |
| | 74 | en el que MMS tuviera un cierto control sobre la procedencia de los |
| | 75 | datos y ésta pudiera ser una base de datos, por ejemplo. |