| Historial de revisiones | ||
|---|---|---|
| Revisión Entrega007.01 | 2007-09-01 | |
| Creación del documento. | ||
| Revisión Entrega007.02 | 2007-09-07 | |
| Revisión final | ||
| Revisión Entrega008.01 | 2007-10-14 | |
| Detalles de informes pasan a It5-AyD_Informes [PDF] . | ||
| Revisión Entrega008.02 | 2007-10-14 | |
| Última revisión. | ||
Para que el sistema satisfaga los requerimientos, adaptándose al modelo conceptual descripto en el documento It5-Modelo_Conceptual [PDF] , debe permitir la definición de las plantillas y el ingreso de operaciones a través de informes. Con esa información deberá poder representar el estado de las entidades de su dominio en cualquier momento indicado.
La definición de plantillas ya esta resuelta en las iteraciones anteriores, mientras que el enfoque actual acerca de los estados, cambios e informes es muy diferente al implementado en dichas iteraciones.
Teniendo en cuenta que en esta iteración no se espera una interfase para el usuario final, se deberán tomar decisiones de diseño relacionadas con el formato de los informes y su persistencia en la base de datos, así como también la forma de obtener los estados de los elementos a partir de esa información.
El diseño de las tablas y campos de la base de datos se describirá en: It5-AyD_Base_de_Datos [PDF] .
El diseño del Schema XML para describir la estructura de los informes se describirá en: It5-AyD_Informes [PDF] .
En las iteraciones anteriores, al orientar el diseño a los objetos del sistema propiamente dichos, como los artículos, centramos la atención en el estado actual de dichos objetos. Por esta razón, el acceso a los estados anteriores se complico en sobremanera.
Si bien el estado actual será el mas utilizado y sobre el que se insertarán las operaciones, no debería ser el "mas importante" para el sistema ya que el objeto del mismo no es solo reflejar el estado actual, sino, principalmente brindar información histórica.
Por lo anterior, se tomo la decisión de que el sistema maneje de "forma nativa" las transiciones de los estados y en base a ellas infiera los estados en cada momento. Por supuesto, en futuras iteraciones podrán implementarse tablas que conserven los estados actuales, con el único fin de optimizar la operación del sistema.
Los informes deberán permitir describir cualquier cambio de estado en el dominio del sistema, de manera que se vean reflejados en el estado interno del mismo.
Como se explica en It5-Modelo_Conceptual [PDF] el sistema recibirá informes, los cuales están compuestos de operaciones, y dichas operaciones le indicarán que cambios deberá aplicar a estados de los objetos.
Pueden identificarse tres fechas relacionadas con el
informe y las operaciones: fechaSuceso, fechaRecepcion,
fechaCarga como se explica mas extensamente en
It5-Modelo_Conceptual
[PDF]
.
fechaSuceso esta relacionada con el suceso,
ya que en un informe pueden referirse sucesos
de distintas fechas. En cambio, fechaRecepcion y
fechaCarga se relacionan con el informe.
Deberá registrarse:
Si una persona externa a la organización realizó el informe: sus datos.
Que persona interna a la organización recibió o realizó el informe.
Que usuario cargó el informe al sistema.
Para las operaciones que deseamos implementar en esta etapa, con los datos indicados sería suficiente, pero debemos tener en cuenta que en futuras etapas las operaciones, los parámetros de estas, y los datos a registrar van a incrementarse.
Por ejemplo: deberemos crear operaciones relacionadas con ubicaciones y con almacenes; también registrar datos de las personas que realizaron las operaciones (clientes, proveedores, técnicos) entre otras cosas.
Por lo general, los informes se generarán por la misma interfase del sistema, osea, tendrán una representación interna como objetos, o bien, lineas en tablas de la base de datos.
Sin embargo, el objetivo es dar una orientación diferente al sistema que le permita operar en un entorno desconectado, por ejemplo, en un futuro, debería existir la posibilidad de redactar el informe en una PDA o un mail y que luego pueda ser capturado y procesado automáticamente por el sistema.
Por esta razón, se definirá un tipo de archivo XML para redactar los informes.
Se pensó, también, en utilizar un formato de texto plano, lo cual facilitaría, por ejemplo, la redacción de un mail, pero se descarto ya que exigiría mas complejidad en el desarrollo del parsing del archivo y dificultaría la creación de nuevas interfases para redactar dichos informes.
Para definir el formato y estructura de los archivos XML de los informes, se redactará un Schema XML. Este archivo XSD permitirá validar de forma sencilla la correcta redacción del informe y con determinados programas de edición de XML también facilitará la redacción.
A medida que se incremente la complejidad de los informes (agregando nuevas operaciones y opciones) se deberá actualizar dicho Schema.
Al conservar todas las transiciones de los estados de los elementos se dispone de la información necesaria para reconstruir dichos estados en cualquier instante.
El procedimiento genérico podría definirse de la siguiente forma:
Obtener la lista ordenada temporalmente de los cambios relacionados con la entidad deseada.
Identificar el cambio inmediato anterior al instante consultado.
El estado resultado de dicho cambio corresponderá al estado buscado.
Al revisar con atención el procedimiento anterior, nos
encontramos con el problema de que el sistema puede no conocer
con exactitud el instante de la transición, ya que fechaSuceso
es un valor poco confiable. De cualquier manera, habrá que
confiar en ese valor, ya que es el único directamente relacionado con
el cambio.
Un único cambio puede alterar el estado de mas de una entidad, y aún de diferentes tipos de entidades.
Entidades del dominio del sistema
Existencia de los artículos.
Valor de los atributos de los artículos.
Contenido o no contenido de los artículos contenibles.
Partes de los artículos continentes.
Como hemos visto, fechaSuceso será el valor para
comparar temporalmente las fechas con los cambios, pero el
orden de los cambios no será dado por ese valor, sino que
deberá ser consecutivo según su ingreso al sistema. Consideremos el siguiente ejemplo:
Se indica al sistema que el día "1" ingresa el artículo "A", y su atributo "B" es seteado en el valor "I".
Se indica al sistema que el día "10" se modifica el valor del atributo "B" del artículo "A" del valor "I" al valor "J".
Se indica al sistema que el día "5" se modifica el valor del atributo "B" del artículo "A" del valor "I" al valor "K".
El paso 3 no debería ser admitido ya que contradice el sentido del paso 2[1].
La regla para aceptar cambios será: la fecha del cambio recibido deberá ser mayor que la del último cambio que afecte alguno de los estados afectados por el [2] , y por supuesto, que el estado anterior de la transición ingresada se corresponda con el posterior de la última existente.
Pudiera ser que se hubiera introducido erróneamente una operación en el sistema, esto generaría graves inconvenientes ya que impediría el ingreso de cambios con fecha anteriores que afecten a los mismos estados. Por lo tanto, tiene que permitirse la eliminación o anulación de operaciones.
Por supuesto, no deberán ser eliminaciones físicas y los cambios anulados no se ocultarán en los listados sino que se listarán como anulados, indicándose el responsable de la anulación y dejarán de tener efecto sobre el estado.
Siguiendo los lineamientos para el ingreso de cambios, solo se permitirá la anulación de las últimos cambios activos para cada estado.
En realidad, el usuario no ingresará ni anulará directamente los cambios, sino las operaciones, las cuales podrían corresponder a mas de un cambio. En ese caso, solo se permitirá el ingreso o anulación de una operación si se permite para todas las transiciones relacionadas.
| [1] | Aún sería incorrecto si en el paso 2 se omitiera la especificación del estado anterior. |
| [2] | También podría ser igual, lo cual indicaría un cambio inmediato posterior al ya existente. |