Diferencia entre revisiones de «Tarea C: Evolucionando la arquitectura del registro»

Revisión del 14:26 27 nov 2008

En nuestro registro, cada vez que un interesado presenta documentación, tenemos que escribir su nombre en el campo Remitente. Este sistema es válido, pero presenta algunas carencias. Si la misma persona presenta documentación en varias ocasiones, tendremos que estar repitiendo su nombre con el riesgo de equivocarnos, arriesgándonos a perder la coherencia de los datos. Además, tenemos muy poca información sobre esa persona. Si está iniciando un procedimiento administrativo y tenemos que ponernos en contacto con ella, no tenemos ni su DNI, ni su teléfono, ni su dirección. Tampoco podemos poner estos campos en el formulario del objeto Entrada ya que la introducción de datos sería muy tediosa. ¿Qué podemos hacer? Comencemos por abstraer el concepto de Tercero en el diagrama que propusimos al comienzo del tutorial.

Figura 10 - Abstraemos el concepto Tercero y lo relacionamos con las entradas y las salidas

En esta figura lo que decimos es:

• Un Fichero de terceros se compone de muchos terceros. Un Tercero representa una persona (física o jurídica) y contiene los datos jurídicos y de contacto de dicha persona.
• Un Libro de entrada se compone de muchas entradas. Cada Entrada tiene Número, Fecha y Destinatario (a qué departamento de la organización se dirige). También se relaciona con una ficha de Tercero; esta relación expresa que el Tercero es el Remitente de la documentación. Adicionalmente, puede tener uno o más documentos adjuntos.
• Un Libro de salida se compone de muchas salidas. Cada Salida tiene Número, Fecha y Origen (departamento de la organización de donde sale el documento). También se relaciona con una ficha de Tercero; esta relación expresa que el Tercero es el Destinatario de la documentación de salida. Además, puede tener uno o más documentos adjuntos.

La definición del tipo Tercero es inmediata:

tipo [Tercero] es contenedor
   [Datos generales] es formulario
       [Nombre/Razón social] es texto
       [Apellidos] es texto
       [CIF/NIF] es texto
       [Dirección] es texto
       [Código postal] es texto
       [Municipio] es texto
       [Provincia] es texto
       [Teléfono 1] es texto
       [Teléfono 2] es texto
       [Fax] es texto
       [Email] es texto
   fin
fin

Ahora tenemos que definir el Fichero de terceros como un objeto de sistema. La definición es muy parecida a la del Libro de entrada.

[Fichero de terceros] es contenedor
   [Contenido] es coleccion
       -nombre_tabla = "TC$TERCEROS";

       contiene [Tercero]

       columna [Denominación]
           -columna_bd.nombre = "DENOMINACION";
           -origen = [Datos generales].[Nombre/Razón social] + " " + [Datos generales].[Apellidos];
       columna [CIF/NIF]
           -columna_bd.nombre = "CIF";
           -columna_bd.nombre = "EMAIL";
           -{AT|origen}} = [Datos generales].[Email];
   fin
fin

Como ya explicamos en la Tarea 1, las columnas de una coleccion no tienen por qué tener una correspondencia directa con los campos de los objetos que contiene. En esta ocasión, hemos definido la columna Denominación como una concatenación del

1. ombre y los Apellidos, para no tener que diferenciar entre personas físicas y jurídicas

(que no tendrían apellidos). En ODL, todo recurso debe definirse antes de que se haga uso de él o de su definición. Como más adelante haremos uso tanto del tipo Tercero como del Fichero de terceros para establecer la relación, debemos asegurarnos de que las definiciones aparecen antes de que se definan los objetos Entrada o Salida. Por último, para hacer este fichero accesible para los usuarios, tenemos que ubicarlo en el Registro de entrada y salida. En este caso lo ubicaremos en Ficheros, en vez de en Libros. Si compilamos y actualizamos ya podremos comenzar a crear fichas de Tercero en nuestro sistema. Observa cómo en la barra de navegación lateral la plataforma crea un nuevo grupo con el nombre Ficheros.