Página principal

Informe Técnico / Technical Report


Descargar 136.93 Kb.
Fecha de conversión18.07.2016
Tamaño136.93 Kb.
Departamento de Sistemas Informáticos y Computación

Universidad Politécnica de Valencia

P.O. Box: 22012 E-46071 Valencia (SPAIN)

Informe Técnico / Technical Report



Ref. No: DSIC-II/08/05 Pages: 11

Title: Estructuras de adquisición

Author (s): A. González

Date: 06-09-2005

Key Words:

VºBº Author (s):

Leader of Reasearch Group
    1. Mensajes y Sistemas de Información de Gestión


Como se viene planteando desde loas primeras propuestas de marcos conceptuales, un Sistema de Información es, básicamente, un sistema de comunicaciones que intercambia mensajes con su entorno [Van Griethuysen 1982].



  1. Modelo ISO de Sistema de información.

La comunicación de mensajes entre el sistema y el entorno se realiza mediante dos clases de diálogos. Diálogos de entrada y diálogos de salida.

Los diálogos de entrada suponen la comunicación al sistema de nueva información que el sistema desconocía hasta ese instante. Los diálogos de salida suponen la consulta al sistema sobre mensajes que se le han comunicado previamente.

Uno de los aspectos esenciales en el análisis y diseño de aplicaciones de gestión es la especificación de la estructura de los mensajes que se intercambian con el entorno.

Sin esa definición es difícil conseguir un correcto modelado de datos. A fin de cuentas un modelo de datos, en una aplicación de gestión, es la estructura de la memoria que permite recordar todos los mensajes que se han comunicado al sistema a lo largo del tiempo.

Un diálogo tiene asociado un proceso editorial de adquisición de datos para construir la representación del mensaje que se va a comunicar. El diálogo comprende la asistencia necesaria para guiar a los usuarios en la edición del mensaje.

2- Estructuras de adquisición


Una estructura de adquisición es una especificación de una estructura de datos para la descripción de un mensaje en la que cada elemento se asocia con la operación editorial que permitirá instanciar su valor.

2.1- Notación para la definición de estructuras de mensajes


La notación BNF fue propuesta por Backus y Naur en el desarrollo del compilador de Algol 60 [Backus 1963].

En la propuesta inicial los constructores gramaticales fueron dos: la secuencia representada mediante contigüidad y la alternativa representada por la barra vertical de separación.



Los paréntesis angulares se utilizaban para delimitar símbolos no terminales.

Extensiones posteriores incorporarían las llaves {,} para repeticiones y los paréntesis rectos [,] para la opcionalidad. La cantidad de notaciones propuestas provocaría el artículo de Wirth “What can we do about the unnecessary diversity of notation for syntactic definitions” [Wirth 1977].

Una adaptación significativa de la notación BNF sería la utilizada para la descripción de estructuras de datos en el Análisis Estructurado de Sistemas [DeMarco 1979].


La notación que aquí se propone se basa en los tres constructores clásicos de secuencia alternativa y repetición. La diferencia fundamental con la mayoría de notaciones propuestas estriba en el uso de paréntesis para la secuencia.

< + > Secuencia o composición

[ | ] Alternativa o especialización

{ } Iteración

Ni el análisis estructurado de sistemas ni las notaciones iniciales de BNF permiten la parentización de secuencias. Esta ausencia de parentización impide la descripción de estructuras dentro de estructuras. Por ejemplo:

Vehículo=Matrícula+Marca+Modelo+Motor=Cilindrada+Válvulas+Combustble+Color+Extras

Vehículo=Matrícula+Marca+Modelo+Motor=+Color+Extras

La primera forma, la que permite el análisis estructurado de sistemas, es ambigua. La ausencia de parentización obliga a dividir las estructuras cada vez que queremos nominar una subestructura o grupos datos.

Vehículo=Matrícula+Marca+Modelo+Motor+Color+Extras

Motor=Cilindrada+Válvulas+Combustible

Esta peculiaridad impide una edición simple de estructuras complejas. De hecho las herramientas CASE de las técnicas estructuradas presentaban una interfaz para la definición de diccionarios de datos costosa y pesada. Para ver una estructura completa era necesario navegar por el árbol de subestructuras abriendo un formulario para cada una de ellas.

Con la notación presentada la estructura del mensaje que nos informa de la existencia de una nueva persona puede definirse como:


Persona=




< código+




fecha_alta+




CIF+




nombre+




calle+




número+




escalera+




puerta+




C.P.+




población +




provincia >



Pero una estructura de adquisición de datos indica además el origen de los datos que constituyen el mensaje.


2.2- Operaciones de adquisición de datos


Podemos vincular una operación de adquisición de datos a cada elemento de una estructura. Esta idea fue propuesta en [Brodie 1984] para la técnica ACM/PCM. Utilizaremos las siguientes abstracciones básicas de operaciones de adquisición de datos:

i para los datos que el usuario introducirá o aportará al sistema de forma libre. Estos datos no son predecibles por el sistema. El sistema desconoce el instante exacto y el valor de los datos que un agente puede comunicar al sistema. El gerente de un videoclub no sabe en qué momento se pasará un socio del videoclub ni las películas que le pedirá.

e para los datos que el usuario aportará pero en un dominio que el sistema puede prever. Por lo tanto el usuario elegirá entre las opciones que el sistema le proponga. El socio del videoclub sólo podrá pedir películas en video o en dvd. Toda operación de elección supone la indicación de un conjuto asociado de valores. En el caso de tipos enumerados se puede utilizar el constructor de alternativas e [dvd|video]

d para los datos que puedan ser calculados o derivados de otros. El precio final a pagar por el cliente no es necesario introducirlo si es calculable a partir de los precios unitarios.

g para los datos que pueden ser generados por el propio sistema. Como es el caso de los códigos o de la fecha del día o de las constantes. No dependen de la voluntad de un agente externo y pueden ser generados en cualquier instante por agentes del sistema. Toda generación se asociará a una función g funcion() o a una constante g ‘iniciado’.

Añadiendo las operaciones de captura de datos podemos describir la estructura de adquisición de los mensajes que nos informan de la existencia de nuevas personas como:




Persona=




< código+

G F1()

fecha_alta+

G hoy()

CIF+

I

nombre+

I

calle+

I

número+

I

escalera+

I

puerta+

I

población +

I

C.P.+

I

provincia >

D F2 (C.P.)

Donde indicamos que en el suceso el código de persona se generará según una función específica, que la fecha se generará a partir de la función hoy(), que el resto de datos se introducirán por el usuario y que la provincia se derivará a partir del Código Postal (C.P.).


2.3- Composición de operaciones


Las operaciones de adquisición pueden componerse en diferentes formas.

Las operaciones de generación o derivación pueden ser una forma de establecer valores iniciales. Es posible que una operación de generación de lugar a datos editables por el usuario.

Por ejemplo la fecha de alta puede generarse a partir de la fecha actual y además puede ser editada por el usuario


Persona=




< código+

g F1()

fecha_alta+

g i hoy()






>



La estructura de operaciones de adquisición puede expresarse con más rigor como < g hoy() + i >


2.4- Expresiones de derivación


En su forma más simple una expresión derivada refleja que un campo de un formulario es el resultado de una operación a partir de otros campos.

Sea, por ejemplo, el siguiente fragmento de estructura de adquisición que describe la introducción de un pedido:



< { LINEA DE PEDIDO=




< Referencia)=

I

Descripción+




Precio >+




Cantidad +

I

Total línea

d Cantidad*Precio

>




}+




Total

>


d  (Total línea)

En una aparecen dos propiedades que por comodidad no hemos prefijado con el nombre de su estructura.

Total línea

d Cantidad*Precio

De forma más rigurosa debiéramos haber escrito para referirnos a estas propiedades:

LINEA DE PEDIDO.Precio y LINEA DE PEDIDO.Cantidad

Sin embargo no necesitamos prefijar las propiedades puesto que no existe ambigüedad.

Igual ocurre con la segunda expresión.



Total

d  (Total línea)

El sumatorio se refiere sin ambigüedad a una propiedad que pertenece a una iteración.

3- Derivación de estructuras

3.1- Selectores


La estructura de datos que soporta un diálogo no sólo contiene referencias a los nuevos datos. También puede contener referencias a datos previamente conocidos por el sistema.

Supongamos que queremos representar la estructura de adquisición asociada a mensajes del tipo “Una persona cambia de domicilio”. Lo primero que tendremos que hacer es “recordar” los datos de la persona en cuestión. Para ello usaremos los paréntesis de selección. El uso de paréntesis de selección con una estructura indica una referencia al entorno de la memoria del sistema en vez de una referencia al entorno editorial.



Persona=

D Persona(código I)




< código+

< código+




fecha_alta+

fecha_alta+




CIF+

CIF+




nombre+

nombre+




calle+

calle+

I

número+

número+

I

escalera+

escalera+

I

puerta+

puerta+

I

población +

población +

I

C.P.+

C.P.+

I

provincia >

provincia >

D F2 (C.P.)

Esta forma supone una derivación estructural. Lo que se está expresando es que la información origen del mensaje que se va a construir se obtiene del propio sistema de información.

No derivamos un campo sino una instancia de la estructura completa de persona. Por simplicidad y dada la total similitud de propiedades podemos reducirlo a la forma siguiente.




Persona (código) =

I

< fecha_alta +




CIF+




nombre+




calle+

I

número+

I

escalera+

I

puerta+

I

población +

I

C.P.+

I

provincia >

D F2 (C.P.)

Mediante expresiones de derivación podemos obtener valores elementales, conjuntos de valores o conjuntos estructurados de valores.

Por ejemplo Cliente(provincia){} denota el conjunto de apellidos y nombre de los clientes de una determinada provincia.

3.2- Relaciones


Las estructuras mantienen entre ellas relaciones de contigüidad que se expresan de diferentes formas según el modelo de datos usado.

En el modelo relacional se utilizan los mecanismos de clave ajena. En el modelo ER se utilizan las relaciones. En los modelos de objetos se usan la asociación y la agregación.

En la notación propuesta dos estructuras tienen relación de contigüidad si una de ellas es componente de la otra.

Sea el ejemplo de la figura siguiente que muestra un fragmento de una cabecera de pedido.



PEDIDO=




< num_pedido +




fecha_pedido+




CLIENTE=




< CIF+




nombre+




razón social+




provincia+



En esta estructura pedido y cliente son estructuras relacionadas, de la misma forma que lo serán en los modelos de datos correspondientes. Toda relación de contigüidad requiere una definición de cardinalidad o multiplicidad. Sabemos que entre pedido y cliente existe una cardinalidad M-1.

Las siguientes expresiones derivadas son equivalentes. Denotan las fechas en que un determinado cliente ha realizado algún pedido.

Cliente(cif).Pedido{}, Cliente(cif).{Pedido}, Cliente(cif).{Pedido.fecha}, {Cliente(cif).Pedido}, {Cliente(cif).Pedido.fecha}

Si bien hay varias maneras de expresar lo mismo, se recomienda usar siempre una forma estándar. Preferiblemente se optará por una de la dos últimas porque expresan mejor que el resultado es una iteración y, además, permiten el uso de operaciones poblacionales (equivalentes a las operaciones agregadas de SQL). Por ejemplo “la fecha del primer pedido que se hizo en una determinada provincia”:



Min{Cliente(provincia).Pedido.fecha_pedido}

En la estructura de pedido que se muestra, cliente y lineas no mantienen relación de contigüidad. Pero las dos son contiguas al pedido.




PEDIDO=




< num_pedido+




fecha_pedido+




CLIENTE=




< CIF+




nombre+




razón social+




calle+




número+




escalera+




puerta+




C.P.+




provincia >




LINEAS=




{




descripción+




cantidad




precio +




importe




> } LINEAS +




total




> PEDIDO



Por ello para obtener “la cantidad de artículos de la referencia 33 que solicitaron los clientes de huelva en el mes de mayo” es necesario utilizar el hecho de que ambas mantienen relación de contigüidad con PEDIDO.

Sum{CLIENTE(provincia=’huelva’).PEDIDO(mes(fecha_pedido)=’mayo-05’).LINEAS(referencia=33)}

3.3- Iteraciones derivadas


En algunos casos es necesario usar conjuntos de iteración en la definición de estructuras de adquisición. Una iteración es un conjunto de instancias de una clase que se derivan del sistema y que usaremos en un diálogo.

Por ejemplo, supongamos que queremos indicar que una factura se realiza a partir de los datos que se almacenaron en el pedido correspondiente.




FACTURA=




< num_factura+

g

fecha factura+

g

num_pedido+

e PEDIDO(estado=’por facturar’)

CLIENTE=

d PEDIDO(num_pedido=:num_pedido).CLIENTE

< CIF+




nombre+




razón social+




calle+




número+




escalera+




puerta+




C.P.+




provincia > +




LINEAS=

d PEDIDO(num_pedido=:num_pedido).LINEAS =

{

{

descripción+

descripción

cantidad

cantidad_pedida

precio +

precio_pedido>}

importe

d cantidad*precio

> } LINEAS +




total

d ∑ (cantidad*precio)

> FACTURA



La estructura anterior expresa que el usuario elige un pedido que está por facturar y los datos de la factura se derivan de éste. Las elecciones de este tipo se describen con la expresión:

e CLASE (selección){}

El criterio de selección determina el dominio de instancias de la clase que se ofrecen para la elección, la parte de visualización indica los atributos de esas instancias que se presentarán al usuario y la proyección indica los campos que se derivan para la interfaz. En el momento de diseñar la interfaz, estas selecciones dan lugar a ayudas de campo.

Obsérvese que, en los selectores, se ha prefijado con dos puntos los parámetros que hacen referencia a campos de la interfaz; esto es especialmente útil en casos en que se puede dar ambigüedad.

Cuando se utilizan la expresiones de derivación para instanciar campos o estructuras es posible que exista una posterior edición de los valores instanciados. Añadimos una “columna de edición” para separar con nitidez la derivación de la posible edición del valor derivado.




FACTURA=







< num_factura+

g




fecha factura+

g




num_pedido+

e

e PEDIDO(estado=’por facturar’)

CLIENTE=




d PEDIDO(num_pedido=:num_pedido).CLIENTE

< CIF+







nombre+







razón social+







calle+







número+







escalera+







puerta+







C.P.+







provincia > +







LINEAS=




d PEDIDO(num_pedido=:num_pedido).LINEAS =

{

d

{

descripción+

d i

descripción

cantidad

d

cantidad_pedida

precio +

d

precio_pedido>}

importe

d

d cantidad*precio

> } LINEAS +







total

d

d ∑ (cantidad*precio)

> FACTURA


















3.4- Derivación de Iteraciones y agrupación.


La agrupación es equivalente al uso de la cláusula GROUP BY en SQL.

Una agrupación es una operación que a partir de un conjunto de instancias devuelve otro conjunto de instancias mediante un cambio de identificación.

Por ejemplo, sea el conjunto de las personas identificadas mediante el dni. Al agrupar este conjunto por provincia tenemos una representación de las personas de cada provincia. Las personas pierden su identificación individual y pasan a tener identificación poblacional. Podemos saber cuantas personas hay en cada provincia, cuantas personas tienen cada edad o cuántas personas hay en cada provincia con cada edad.

Una agrupación se define a partir de una clase básica, un criterio cociente y un criterio de proyección.



  • La clase básica está caracterizada por sus atributos, sus identificadores y sus instancias. Por ejemplo la clase básica:

Personas{<dni+nombre+apellidos+ provincia+población+edad>}

Como la clase ya ha sido definida con anterioridad, no necesitamos presentar sus atributos en la expresión de derivación. Sí se indicará mediante selectores los posibles criterios de selección a aplicar sobre el conjunto de instancias de la clase base.



  • El criterio cociente define el cambio en el punto de vista de identificación. Por ejemplo:
    .


Las propiedades del criterio cociente, o propiedades cocientes, pertenecen forzosamente al conjunto de propiedades de la clase básica. El resto de propiedades de la clase básica las denominaremos propiedades no cocientes.

La operación de agrupación la representamos mediante una barra inclinada (como la cocientación en Teoría de Conjuntos) y se parentiza con las llaves de iteración porque devuelve un conjunto de instancias:

{clase básica / criterio cociente}


  • El criterio de proyección define las propiedades que nos interesa conocer de la agrupación; es la forma en que resumimos cada conjunto de instancias de las propiedades no cocientes.

Es obvio que a cada valor
le corresponderá un conjunto de valores nombre, apellidos, población o dni. Es necesario elegir para cada una de estas propiedades la operación agregada que a partir de todas sus instancias nos devuelve un único valor. Tradicionalmente SQL utiliza las operaciones agregadas max, min, sum, avg o count.
En el ejemplo siguiente las líneas de factura se obtienen seleccionando todas las lineas de pedido del cliente para un determinado mes agrupándolas por referencia y precio.

Factura=




< Numero factura+

G

Fecha factura+

I

Mes de facturación+

I

CLIENTE(cif )=

I

< nombre+




domicilio+




población >+




LINEAS DE FACTURA=

d { PEDIDO(CIF=cif y fecha_pedido.mes=Mes de facturación).LINEAS /

}=

{

{

descripción+

descripción+

precio+

Precio+

cantidad facturada +

suma(cantidad) >}

importe > }

d Precio* cantidad facturada

> Factura



La expresión de agrupación no tiene en cuenta descripción. Desde el punto de vista conceptual sería necesario indicar que una referencia determina un único valor de descripción y se sobreentiende que por tanto la agrupación no afecta a la descripción. Pero si se piensa en el ámbito del diseño o de la construcción, en el lenguaje SQL, es necesario garantizar el valor único de la descripción. Podemos asumir una regla implícita estableciendo que, a los campos que no figuran en el criterio cociente pero sí en el criterio de proyección, se les aplica una función agregada por defecto.


3.5- Iteraciones derivadas con multiselección


Otra funcionalidad de derivación editorial es la multiselección. La multiselección permite elegir, manualmente, un subconjunto de un conjunto derivado. La Multiselección permite un Marcado de los elementos de un conjunto de iteración que se requieren para una determinada función.

Por ejemplo, supongamos que queremos indicar que una factura se realiza a partir de los datos que se almacenaron en el pedido correspondiente.



Factura=




< Nfac+

G

Fecha_factura+

G

según pedido+

e Pedido

CLIENTE=

d Pedido(según pedido).CLIENTE

< CIF+




nombre+




Razón social+




calle+




Número+




Escalera+




puerta+




C.P.+




Provincia >> +




LINEAS=

M Pedido(según pedido).LINEAS =

{

{

Descripción+

Descripción

Cantidad

Cantidad_pedida

Precio +

Precio_pedido>}

Importe

d Cantidad*Precio

> } LINEAS +




Total

d ∑ (Cantidad*Precio)

> PEDIDO



En este caso el usuario elige las líneas que se incluirán en la factura a partir del conjunto derivado.


4- Especialización


El uso de estructuras de especialización en formularios indica la existencia de variedades estructurales excluyentes. Cada variedad estructural recoge diferentes campos que deberán ser cumplimentados según el caso.

Normalmente aparecen campos cuyo valor puede determinar el uso de una u otra variedad estructural. En este caso podemos hablar de indicadores de especialización. Un indicador de especialización es un campo de un formulario cuyos valores determinan el uso de una u otra variedad estructural. Por ejemplo, supongamos que un proyecto puede ser interno o externo. Tendríamos un campo del formulario Tipo de proyecto cuyos valores posibles serían [interno|externo]. En el caso de que fuera interno en el formulario se indicará el Departamento que lo realizará. En el caso de que sea externo en el formulario se indicará el CIF y la razón social de la empresa adjudicataria.

La persona que cumplimente el formulario deberá indicar la opción deseada y según la opción cumplimentará los campos adecuados.

En la estructura de adquisición el indicador de especialización se asocia a una operación de captura de elección.



< . . . +




Tipo de proyecto+

e [interno|externo]

REALIZACIÓN=




[ INTERNA=

Tipo de proyecto=’interno’

< Departamento >

i

| EXTERNA=

Tipo de proyecto=’externo’

< cif+

i

Razón Social >

i

]




. . . +




>




Cada una de las variantes estructurales (INTERNA, EXTERNA) lleva asociada una condición que se vincula al indicador de especialización.

Es posible también que en un formulario aparezcan variantes estructurales sin que exista un indicador de especialización “nominal”. Por ejemplo supongamos que en función del valor de un campo es necesario cumplimentar de modo diferente el formulario.



< . . . +




importe+

i

[ Obra mayor=

importe > 100 & importe < 200


i

tasas de consolidación>+

i

| Obra doiro=

importe >= 200

< plazo reposición+

i

retorno de freseles >

i

] +




. . . +




>




Obsérvese que se ha omitido el nombre de la estructura que contiene las diferentes variantes estructurales.

Las estructuras opcionales se tratan como variantes con una sola opción.



< . . . +




importe+

i

[ Obra mayor=

importe > 100


i

tasas de consolidación>+

i

] +




. . . +




>




Bibliografía


[Backus 1963]


John W. Backus, Friedrich L. Bauer, Julien Green, C. Katz, John L. McCarthy, Alan J. Perlis, Heinz Rutishauser, Klaus Samelson, Bernard Vauquois, Joseph Henry Wegstein, Adriaan van Wijngaarden, Michael Woodger, Peter Naur: Revised report on the algorithm language ALGOL 60. Commun. ACM 6(1): 1-17 (1963)

[Brodie 1984]

Brodie,M., and Silva,E. "Active and Pasive Component Modelling: ACM/PCM".

[DeMarco 1979]

Demarco,T. "Structured Analysis and System Specification", Yourdon Press 1979.

[Van Griethuysen 1982]

I.S.O. TC97]/SC5 /WG3 "Concepts and terminology for the conceptual schema and the information base" Ed. J.J. Van Griethuysen. 1982.

[WIRT 1977]

Wirth, N. " What can we do about the unnecessary diversity of notation for syntactic definitions " Communications of the ACM, Vol. 20, No. 11, November 1977, pp. 822-823.


La base de datos está protegida por derechos de autor ©espanito.com 2016
enviar mensaje