Sobre los modelos

Al revisar el correo encontré unos comentarios de uno de ustedes, diciendo que los modelos lógicos son muy prácticos. Si, lo son, siempre y cuando estemos hablando de diseño de aplicaciones a secas, no de RAD, diseño RAPIDO de aplicaciones, y que el analista sea el mismo que el programador. Muchas personas que no saben programar o de bases de datos, son capaces de hacer esquema lógico. Pero un modelo físico decente es raro, y mas raro alguien que lo pueda hacer a la primera.

Una mentira frecuente que se oye, o error a medias, es que un buen modelo de datos hecho en dos semanas, puede hacerse en una semana la programación, y se ahorra tiempo sobre un diseño/sistema normal de cuatro semanas. El problema es que como suele ser diferente la persona que hace el análisis al que hace el programa, suelen verse a veces cosas ridículas tipo teléfono descompuesto, y a nivel programación entender el proceso lógico y aterrizarlo a datos puede dar muchos problemas. Es común que alguien debe hacer un programa sobre el diseño de otra persona, sin poder corregir errores del análisis original.

Voy a citar dos ejemplos que me pasaron a mi.

caso a)

En una empresa que me contrató me pasaron un manual de 200 paginas por mail hechas sobre un modelo de datos de Data Arquitect. Para mi resultó obvio que no lo iba a poder leer, me negué a recibirlo, y después me pasaron un esquema de una hoja lógico, sobre el modelo físico.

Una vez que tuve casi terminado el sistema, y se mandó a una persona a instalarlo, me di cuenta que todo el modelo estaba hecho sobre el supuesto de que algo llamado “sesión” era único y era la clave de todo un esquema. Pues al confirmar un dato con el usuario.. resultó que la sesión se repetía a diario. Ese “pequeño” fallo lógico no hubiera sucedido si el analista hubiera hecho antes una sesión de preguntas con el usuario.

caso

En otra empresa, la que mencioné antes sobre conciliaciones bancarias, recibí una impresión de 9 hojas siendo una maestro y otra detalle sobre un proceso de consolidación de sucursales. En papel se veía muy bonito, pero si ustedes ven que un modelo dice Facturas suponen que es facturas, pero si ven un esquema con las tablas donde se ven las relaciones NO hay dudas. Si el titulo dice “Consolidación de facturas”, suponen que se refiere a facturas, no a cuentas por cobrar.

En ciertos casos si es conveniente crear modelos lógicos, pero no en RAD. En todo caso, crear el modelo Lógico después de terminado el programa. El modelo físico si se debe hacer sobre al marcha, [color=#00FF00]Y ES EL QUE DEBE USARSE COMO BASE.

Por lo general este es un tema que se brinda a muchas discusiones, pero normalmente se entiende casi por default que nos referimos a esquemas de Power Designer de Sybase. Los Modelos Lógicos con extensión PAM se crean con el Process Analyst, y los físicos con Data Arquitect Extensión PDM. Mas adelante hablaremos de las limitaciones de esos programas, pero son menores a las de Visio o los productos de Embarcadero

Por otra parte, un modelo lógico valido debe ser consultado con el usuario antes de hacer algo realmente complicado ( eso dice Yourdon ), y los modelos RAD suelen ser sencillos. Si alguien hace un modelo lógico complicado, y sobre el nos pide que hagamos RAD, nos quita el criterio que es necesario para desarrollar RAD. Además, la lógica de un modelo no necesariamente se aplica a los datos de que hablamos.

Dicho de otra manera, un modelo lógico no necesariamente habla de interacción con Datos. Y los datos no necesariamente siguen un modelo.

En días recientes me vi en la necesidad de explicar a una serie de abogados y contadores un esquema bancario aparentemente complejo, con el cual se evitan los problemas actuales de una organización. Pero para explicarlo en términos lógicos, NO DE DATOS, tuve que reducirlo a los elementos comunes de un esquema lógico:

  1. Entidades
  2. Procesos
  3. Receptores de datos ( NO NECESARIAMENTE Tablas o bases )
  4. Y sus relaciones.

El resultado de esto fue un esquema que les envío, esta hecho en Process Analyst y yo lo convertí a PDF, verán que la frase de “Esquema personal de bancos” sale encimada, pero se debe al proceso de conversión. Si ustedes imprimen el modelo, verán que no es tan complicado por la división en grupos y la explicación contigua.

En este caso las entidades son los bancos ( rectángulos ), los procesos los círculos, y los rectángulos a medias las cuentas de banco. El proceso en especial puede verse demasiado complicado de entrada, pero no necesita explicación adicional, y explica un proceso realmente complicado en términos No técnicos. Ahora bien, un modelo de este tipo se entrega en una pagina, la persona lo revisa sin problemas porque no tiene ramificaciones. Si quiere saca una copia y la raya, pero es a final de cuentas, un resumen Lógico, que es lo que debe ser un modelo lógico. Y me repito pero nunca lo suficiente. Un modelo comprensible sea LOGICO O FISICO debe de ser Pequeño, de 1 a 4 Páginas SIN RAMIFICACIONES y Subdocumentos

La parte técnica seria un modelo físico de datos sobre las transacciones a cuentas bancarias, pero como se dan cuenta, el modelo lógico es de procesos , pero no de DATOS. El modelo físico si nos da relaciones entre los datos.

[url=http://darakan.com/images/esquem.pdf]http://darakan.com/images/esquem.pdf[/url] (link roto de manera temporal )

Comments are Closed