Propuesta de Sistemas de Informacion

8/17/2019 Propuesta de Sistemas de Informacion

1/17

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/277268668

Propuesta de Lenguaje para Descripción deInterfaces de Sistemas Turísticos Basados enTécnicas de Ingeniería Inversa y en ModeladoWorkflow.

Conference Paper · January 2006

READS

30

5 authors, including:

José L. Leiva

University of Malaga

11 PUBLICATIONS 4 CITATIONS

SEE PROFILE

José L. Caro



SEE PROFILE

Antonio Guevara



SEE PROFILE

Andrés Aguayo



SEE PROFILE

Available from: José L. Leiva

Retrieved on: 15 May 2016

https://www.researchgate.net/profile/Antonio_Guevara?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_7https://www.researchgate.net/profile/Antonio_Guevara?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_4https://www.researchgate.net/institution/University_of_Malaga?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_6https://www.researchgate.net/institution/University_of_Malaga?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_6https://www.researchgate.net/profile/Jose_Leiva3?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_4https://www.researchgate.net/publication/277268668_Propuesta_de_Lenguaje_para_Descripcion_de_Interfaces_de_Sistemas_Turisticos_Basados_en_Tecnicas_de_Ingenieria_Inversa_y_en_Modelado_Workflow?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_3https://www.researchgate.net/publication/277268668_Propuesta_de_Lenguaje_para_Descripcion_de_Interfaces_de_Sistemas_Turisticos_Basados_en_Tecnicas_de_Ingenieria_Inversa_y_en_Modelado_Workflow?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_3https://www.researchgate.net/?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_1https://www.researchgate.net/profile/Andres_Aguayo2?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_7https://www.researchgate.net/institution/University_of_Malaga?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_6https://www.researchgate.net/profile/Andres_Aguayo2?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_5https://www.researchgate.net/profile/Andres_Aguayo2?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_4https://www.researchgate.net/profile/Antonio_Guevara?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_7https://www.researchgate.net/institution/University_of_Malaga?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_6https://www.researchgate.net/profile/Antonio_Guevara?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_5https://www.researchgate.net/profile/Antonio_Guevara?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_4https://www.researchgate.net/profile/Jose_Caro3?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_7https://www.researchgate.net/institution/University_of_Malaga?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_6https://www.researchgate.net/profile/Jose_Caro3?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_5https://www.researchgate.net/profile/Jose_Caro3?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_4https://www.researchgate.net/profile/Jose_Leiva3?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_7https://www.researchgate.net/institution/University_of_Malaga?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_6https://www.researchgate.net/profile/Jose_Leiva3?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_5https://www.researchgate.net/profile/Jose_Leiva3?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_4https://www.researchgate.net/?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_1https://www.researchgate.net/publication/277268668_Propuesta_de_Lenguaje_para_Descripcion_de_Interfaces_de_Sistemas_Turisticos_Basados_en_Tecnicas_de_Ingenieria_Inversa_y_en_Modelado_Workflow?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_3https://www.researchgate.net/publication/277268668_Propuesta_de_Lenguaje_para_Descripcion_de_Interfaces_de_Sistemas_Turisticos_Basados_en_Tecnicas_de_Ingenieria_Inversa_y_en_Modelado_Workflow?enrichId=rgreq-a7e2d046-8a09-4a54-9f86-186a3393d093&enrichSource=Y292ZXJQYWdlOzI3NzI2ODY2ODtBUzoyNjczNjMxMjc5MTg2MDFAMTQ0MDc1NTc0NTI1OQ%3D%3D&el=1_x_2


2/17

Propuesta de Lenguaje para Descripción de

Interfaces de Sistemas Turísticos Basados en

Técnicas de Ingeniería Inversa y en Modelado

Workflow.

Rocío Rodríguez, José L. Leiva 1, José L. Caro 2, Antonio Guevara 3, Andrés Aguayo 4.

Departamento de Lenguajes y Ciencias de la Computación. Universidad de Málaga, España.

1. [email protected]




Resumen:

La evolución constante del desarrollo de sistemas de información turísticos, obliga a

afrontar nuevos métodos de trabajo. La complejidad y coste de comenzar a diseñar un nuevo

sistema, es evitable si se modifican y mejoran aspectos necesarios del sistema anterior. La

ingeniería inversa surge como alternativa fundamental en todo proceso de reingeniería, ya

que la recuperación de especificaciones de diseño y de flujos de trabajo, permiten crear una

representación de alto nivel de abstracción. Nuestra propuesta se basa en el diseño de

herramientas que permitan un método de trabajo cooperativo en el que impliquemos al

usuario en las fases de análisis y diseño, suministrándole para ello herramientas de fácil uso

para conseguir unas especificaciones con un alto grado de coherencia con las exigencias

finales de los usuarios. El marco establecido permitirá la obtención de especificaciones sobre

las interfaces y de los flujos de trabajo presentes y futuros del sistema de información.


3/17

VI Congreso “Turismo y Tecnologías de la Información y las Comunicaciones” Turitec 2006

Este artículo estudia la base teórica de nuestro método así como la aplicación de dicha

tecnología en las empresas del sector turismo, centrándose en la mejora de sus sistemas de

información para obtener una mayor satisfacción en los requerimientos del cliente.

Palabras clave: Reingeniería; Ingeniería Inversa; Workflow; Interacción persona-ordenador;

CSCW; BPR.

1. Introducción.

Con la proliferación de las nuevas tecnologías y los grandes avances de la informática en las

últimas décadas, muchas empresas cuentan con un sistema software adecuado a lasnecesidades de su negocio con la que organizan la información necesaria para llevar a cabo su

trabajo.

Debido al paso del tiempo y a la gran velocidad a la que evoluciona la informática, la

aparición de nuevas plataformas, sistemas operativos, avances en los lenguajes de

programación, y la aparición de nuevas necesidades para los usuarios, estos sistemas software

van quedando anticuados, por lo que requieren de un mantenimiento, para evitar que queden

obsoletos.

No siempre es posible llevar a cabo el mantenimiento del software, ya que en

ocasiones existen multitud de dificultades, tales como son las restricciones de tamaño y

espacio de almacenamiento, las herramientas con la que se implementó en un principio han

quedado desfasadas, la gran cantidad de modificaciones que han ido sucediéndose en el

sistema para adaptarlo o mejorarlo ha ocasionado que sea cada vez menos estructurado y la

imposibilidad de establecer contacto con los ingenieros que lo desarrollaron.

Una solución al problema ante la imposibilidad de realizar un mantenimiento puede

ser la utilización de técnicas de reingeniería e ingeniería inversa, de manera que sea posible

realizar un examen del sistema heredado y reconstruirlo. En el apartado 2 comentaremos la

problemática actual así como las características de estas técnicas. Propondremos la

participación de los usuarios que utilizan el sistema, de modo que partiendo de una aplicación


4/17


inicial nos proporcione los datos necesarios de las modificaciones a realizar tanto en la

interfaz como de los flujos de trabajo[7].

Para ello, contaremos con una aplicación en la cuál el usuario proporcionará un diseño

de cada una de las interfaces que compondrán el proyecto, dichas interfaces serán traducidas a

un lenguaje de definición basado en XML, de modo, que puedan ser reconstruidas en

cualquier lenguaje de programación [2]. Existe un gran número de lenguajes declarativos para

la definición de interfaces de usuario (diseño externo), los cuales resumiremos en el apartado

3. En el apartado 4 y 5, haremos una descripción del lenguaje que nosotros proponemos, que

permitirá describir todas las interfaces del sistema y del modelado workflow de los procesos

existentes en las interfaces. El apartado 6 estará dedicado a la descripción de la aplicación

propuesta(EXINUS1), del lenguaje que hemos utilizado para la describir las interfaces de

usuario, el proceso de diseño de las interfaces y la generación de los flujos a partir de los

datos capturados del usuario. En el apartado 7, definiremos un ejemplo, acabando en el

apartado 8 con las conclusiones.

2. Problemática.

Como ya se ha comentado anteriormente el usuario posee una aplicación que por

diversos motivos desea remodelarse. En este apartado describimos como la ingeniería inversa

y la reingeniería puede ayudarnos a la reconstrucción del sistema, ya que por diversos

motivos se ha concluido que no es posible realizar actividades de mantenimiento debido a la

falta de documentación sobre el sistema y a la imposibilidad de contactar con los

desarrolladores iniciales.

Debido a la escasa información que se posee de la aplicación a reconstruir es necesaria

la recopilación de los datos necesarios tanto de las características del sistema anterior como de

las nuevas funcionalidades que se desea incluir en el nuevo sistema. Para poder realizar la

captura de datos es fundamental la utilización de la ingeniería inversa como parte del proceso

de reingeniería, ya que, a través de ella podemos realizar una obtención de las

especificaciones del diseño del sistema y de los flujos de trabajo, obteniendo una

1 EXINUS (EXtracción INformación USuario)


5/17


representación de alto nivel de abstracción, que permita obtener un sistema de mayor calidad,

mayor eficiencia, corrección, usabilidad, etc.[7]

De este modo la reingeniería es una solución al problema del remodelado de una

aplicación. Sin embargo, estas técnicas, a pesar de conseguir aplicaciones de calidad y

proporcionar grandes ventajas, pueden generar aplicaciones que no cumplan del todo los

requisitos que propone el usuario que la utiliza. Por ello, se propone, que sea éste el que nos

proporcione las especificaciones del diseño de las interfaces y los flujos de trabajo necesarios,

tanto presentes como futuros. La base del método es el proporcionar al usuario las

herramientas necesarias que permitan realizar un diseño externo (interfaces) e interno (flujos

de trabajo) del sistema, de una forma sencilla y amigable, implicando a los usuarios en el

desarrollo del nuevo sistema[7].

3. Lenguajes declarativos para la descripción de interfaces de usuario.

En este apartado expondremos algunas características de los principales lenguajes para

la descripción de interfaces, además de sus ventajas e inconvenientes, características y

finalidad de estos lenguajes.

El objetivo principal de estos lenguajes es proporcionar una descripción de la

estructura de la interfaz, de manera sencilla y con alto nivel de abstracción, de modo que a

partir de dicha especificación sea posible la generación de la interfaz de usuario final.

Los lenguajes declarativos no están relacionados con ningún lenguaje de programación

en concreto sino que son independientes del mismo, además de la plataforma y el dispositivo.

El hecho de que sean independientes del contexto es una gran ventaja, ya que gracias a esto,

será posible generar la interfaz en cualquier lenguaje de programación, con capacidad de crear

interfaces de usuario, o en cualquier dispositivo, tanto un PC como un PDA o dispositivos

móviles[1][2].

El lenguaje para descripción de documentos XML proporciona una sintaxis robusta y

estructurada para definir lenguajes declarativos jerárquicos. Los lenguajes basados en XML

son serios candidatos para soportar especificaciones, gracias a su versatilidad, facilidad de


6/17


mantenimiento y refinamiento. A continuación se muestran las principales características de

los lenguajes más importantes basados en XML[2][5].

3.1. AAIML.

AAIML es un lenguaje en vías de desarrollo, cuya finalidad, es ampliar el mercado

haciendo interfaces más accesibles, por ejemplo, por medio de la voz, esto puede ser

interesante para personas con discapacidades. Para que esto sea posible es necesaria la

comunicación entre los dispositivos de E/S. Debido a que los dispositivos están fabricados por

diferentes compañías, es necesario la utilización de una consola, Consola Remota Universal

(URC), para controlar dichos dispositivos[5].

3.2. AUIML.

Lenguaje desarrollado por IBM y diseñado para permitir la definición de la semántica

de la interacción con el usuario. Esta centrado, por tanto, en la descripción de aspectos de

interacción más que en aspectos de presentación. Toda la información se codifica una sola vez

y se traduce utilizando una traducción dependiente del dispositivo final. Esta diseñado para

ser independiente de la plataforma, del lenguaje de programación final y de la tecnología de

implementación. [5]

3.3. UIML.

Este lenguaje, permite obtener definiciones declarativas de interfaces de usuario

independientes de la plataforma, tipo de interacción y del lenguaje de programación.

Para escribir una interfaz en UIML se debe realizar, por un lado una definición de la interfazgenérica, y por otro lado un documento UIML que representa el estilo de presentación

apropiado para el dispositivo en el cuál la interfaz se va a ejecutar. De este modo, una misma

aplicación solo necesitará un documento UIML de especificación para cualquier dispositivo y

un documento de estilo para cada dispositivo.

3.4. XIML.


7/17


Suministra el soporte necesario para la modelización, diseño y generación de

interfaces multiplataforma. Es capaz de representar las cinco dimensiones de una interfaz

(tareas, dominio, usuarios, presentación y diálogo) y las relaciones que se puedan establecer

entre los elementos de cada una de estas dimensiones. Las tres primeras dimensiones se

pueden considerar abstractas y las otras dos concretas.

3.5. XUL.

El lenguaje XUL es un lenguaje de descripción de interfaces específicamente diseñado

para aplicaciones en red como navegadores y programas de correo. Está integrado dentro de la

arquitectura de Mozilla para el desarrollo de interfaces Web multiplataforma, haciendo uso de

tecnologías W3C ya existentes.

La filosofía de XUL consiste en no reinventar nada, sino en utilizar estándares actuales

para crear interfaces y aplicaciones multiplataformas. La arquitectura se basa en el uso de

paquetes, los cuáles se componen de contenido, apariencia, comportamiento y plataforma. En

cada unos de ellos se hace uso de diferentes tecnologías.[2]

3.6. XFORMS.

XForms es una propuesta del consorcio W3C para la especificación de formularios

para la web que puedan ser usados en una amplia variedad de plataformas. Su versión 1.0 ha

llegado a ser recientemente una recomendación de W3C.

La característica más importante que proporciona esta tecnología es que, a diferencia

que los formularios web habituales, las especificaciones del diseño de la interfaz se define porseparado a la funcionalidad de esta. De esta manera el comportamiento de los formularios no

se ve alterado al cambiar de plataforma, mientras que el aspecto de las ventanas vendrá dado

por los recursos de la plataforma donde se deseen mostrar. Con esto se pretende cubrir las

limitaciones de los formularios HTML tradicionales que no disponen de una separación entre

el propósito y la presentación del formulario.


8/17


Como se ha comentado antes XForms surge con la finalidad de sustituir los actuales

formularios web. Para ello, define una serie de componentes visuales más ricas, capaces de

generar interfaces mucho más útiles y usables.[2,5]

4. Exinus-XML. Lenguaje de descripción de proyectos e interfaces.

A continuación describiremos la estructura que utilizamos para guardar los

formularios o interfaces. El objetivo es que las interfaces de usuario diseñadas por el usuario

puedan ser generadas desde cualquier lenguaje de programación capaz de crear formularios.

Para ello cada una de las interfaces estará determinada por un fichero que contendrá las

propiedades de esta organizados en una estructura basada en XML, los cuales se caracterizan

por su alto nivel de abstracción.

La estructura que proponemos se basa en etiquetas anidadas unas dentro de otras:

……..

Para almacenar los datos de un proyecto usaremos la siguiente estructura:

“id proyecto” ”Nombre del Proyecto”

id usuario

“dni”

“nombre de usuario”

“apellidos”

“login”

“contraseña

encriptada”

“rol o perfil de usuario”

…

…

”Nombre del

Propietario”

”id interfaz1”

”id interfaz2”

…

… indican comienzo y final de la especificación del

proyecto. Entre estas dos etiquetas distinguimos las siguientes propiedades:

Etiqueta Definición

… identificador del proyecto

… nombre del proyecto

… propietario del proyecto


9/17


A continuación se definen cada uno de los usuarios que tienen permiso para

acceder al proyecto, cada una de las especificaciones estará enmarcada por las etiquetas:

… Entre las cuáles se incluirán los datos de los usuarios:

Etiqueta Defincion

… identificador o código del usuario

… Dni

… Nombre

… Apellidos

… Login

… contraseña que usa el usuario, encriptada para más seguridad.

… perfil del usuario, administrador, jefe de proyectos …

Por último se incluirá el identificador de las interfaces que forman parte del

proyecto. “identificador de la interfaz”

Por tanto, al guardar un proyecto, se generará un fichero con la información

incluida en la estructura anterior, en la que se indica el nombre, el propietario del

proyecto, los usuarios que tienen acceso al proyecto y las interfaces que lo componen.

En esta estructura solo se almacena una referencia a la interfaz, puesto que para cada

una de las interfaces del proyecto existirá otro fichero con las propiedades de la misma.

La estructura de los ficheros de las interfaces será parecida a la que sigue:

En esta estructura se incluyen los datos generales de

la interfaz, nombre, descripción… para

posteriormente definir cada uno de los objetos que

la componen y los atributos de cada uno de ellos.

La descripción de la estructura general de un

formulario puede dividirse en dos zonas bien

diferenciadas: zona de definición de propiedades de

la interfaz y una zona de definición de componentes de la interfaz. El principio y el final

de la interfaz estarán definido por las etiquetas: …

Entre estas dos etiquetas se incluirán dos zonas, en la primera se incluirán las

propiedades relacionadas con el formulario:


10/17


Etiqueta Definición

… identificador del formulario

… nombre del formulario

… numero de componentes que contiene el formulario

… Propietario

… posición: coordenada X … posición: coordenada Y

… anchura del formulario

… altura del formulario

… color del formulario

…

…

…

0/1

0/1

0/1

0/1

fuente de la letra del formulario

nombre

tamaño

color

estilo de la fuente

0/1 = normal / negrita

0/1 = normal / cursiva

0/1 = normal / subrayado

0/1 = normal / tachado

En la segunda zona de definirán cada una de las componentes que forman el

formulario. Cada componente estará enmarcada por las etiquetas:

… y para cada componente se almacenarán las siguientes

propiedades:

Etiquetas Definición

… indica el tipo de componente: botón, campo de texto, etiqueta…

… nombre de la componente

… Etiqueta

… posición: coordenada X

… posición: coordenada Y

… Anchura

… Altura

… Color

... Descripcion

... Objetivos

... indica cuando desea el usuario que la componente este visible,

tomará los valores :

0 siempre

1 nunca

2 cuando se cumpla una condición

… Condición que indica cuando se desea que una componente se

establezca como visible.

… indica cuando desea el usuario que la componente este

habilitada, tomará los valores :0 siempre


11/17


1 nunca

2 cuando se cumpla una condición

... Condición que indica cuando se desea que una componente se

establezca como habilitada.

... Valor que tomara la componente: tendrá significado en

componentes como etiquetas, campos de texto … … indica cuando desea el usuario que la componente este

enmascarada, tomará los valores :

0 No

1 Si

2 Contraseña: los caracteres serán sustituidos por ‘*’

Esta propiedad solo será útil para campos de texto.

… Indica la estructura de la máscara, en el caso, de que el campo

de texto esté enmascarado.

…

…

…

0/1

0/1

0/1

0/1

fuente de la letra del formulario

nombre

tamaño

color

estilo de la fuente

0/1 = normal / negrita

0/1 = normal / cursiva

0/1 = normal / subrayado

0/1 = normal / tachado

Estas propiedades, serán las mismas para todas las componentes, en el caso deque una propiedad no esté presente en una componente, esta tomará un valor nulo.

5. Diagramas para representar Flujos de trabajo

Una vez definido el aspecto externo así como las funcionalidades intrínsecas de

cada uno de los objetos descritos, la herramienta debe extraer información respecto a la

identificación de los flujos de trabajo para obtener unas especificaciones de los mismos.De la misma manera que en la descripción externa, deben distinguirse los flujos de

trabajo del sistema actual así como modificaciones o incremento de flujos del nuevo

sistema. [4]

A continuación se incluye una tabla con las características de cada una de las

primitivas que formarán parte de los diagramas de flujo de trabajo antes propuesto:


12/17


Nombre de laInterfaz

E S

Componente Representación Descripción

Workflow

Cada workflow representa una subtarea que forma

parte del f lujo de trabajo. Los flujos representados con

línea discontinua (c y d) indican que dicho flujo no esta

en el sistema actual y se desea que lo esté en el futuro,

los flujos con doble línea (b y d) indican que la tarea es primitiva y no se divide en más subtareas.

Transición de interfaz.

Esta componente se usa para indicar el paso de una

interfaz a otra.

Puede que en la transición se produzca un paso de

parámetros, de entrada (E), de salida (S) o ambas (E/S).

Objeto

Representación de cada uno de los objetos que

formarán parte de la interfaz. La descripción puede

acarrear un listado de precondiciones y/o

postcondiciones que deben cumplirse antes y/o después

de la aparición de dicho objeto en la interfaz

Flujos de trabajos de un

objeto.

Se representará de la misma forma que los flujos de

trabajos indicados anteriormente, con la diferencia de

que en lugar de usar una caja usaremos una elipse.

Inicio y fin

Comienzo y final del flujo de trabajo.

Interfaz

Usuario

Nombre

Tipo:

Descripción:

Nombre tarea

Nombre tarea

Nombre tarea

Nombre tarea

i f

Nombre flujo

Nombre flujo Nombre flujo

Nombre flujoa) c)

d) b)


13/17


Alternancia y Unión de

flujos de trabajo

Con estás componentes se indica la posible ejecución

de varios flujos a la vez. A partir de un flujo de trabajo

base se produce una descomposición en varios

subfujos, de modo que, se puede ejecutar uno de ellos o

varios.

Bifurcación y Reunión

de flujos.

Estos constructores se refieren a la ejecución paralela

de flujos de trabajo, creando nuevos subflujos nuevos

de longitud temporal indeterminada que en algún

momento, mediante el constructor de reunión se

sincronizarán.

Opcionabilidad de

flujos.

Con esta componente se producirá la ejecución de uno

de los flujos, dependiendo del resultado del predicado

P.

Bloque de repetición.

Conjunto de flujos de trabajo que se repetirán mientras

se cumpla la condición P.

Descripción de las componentes para la especificación de flujos de trabajo.

6. Herramienta EXINUS.

En este punto realizaremos una descripción breve de la herramienta EXINUS, la

cuál ofrece una solución a la problemática explicada anteriormente. Como ya

comentamos en apartados anteriores partimos de un sistema que debe ser remodelado.

El primer paso para realizar la reestructuración del sistema es la recopilación de

los datos necesarios para ello. Para esta tarea se ha considerado realizar un

n

n

P

P

T

T

F

F

P


14/17


aprovechamiento de la experiencia y el conocimiento que el usuario posee de la

aplicación a remodelar, de modo, que será este el que proporcione la información.

Por los motivos antes expuestos, el objetivo principal de la aplicación EXINUS

es la de proporcionar un entorno sencillo y de las herramientas adecuadas con las que el

usuario sea capaz de realizar el diseño de las interfaces de su aplicación. Una vez que se

han realizado el diseño del aspecto externo de la interfaz se procederá a la captura de los

datos relacionados con la funcionalidad de la interfaz, con el fin de obtener los

diagramas de flujos de trabajo correspondientes.

La aplicación permite el control de las

interfaces creadas en el proyecto actual,

desde una sola ventana, desde la cual se

podrá crear interfaces nuevas, modificar,

eliminar o compartir las ya creadas.

Además de la creación de formularios, la

herramienta permitirá la creación de

tareas con el fin de agrupar las interfaces que participan en un mismo proceso. Al crear

una nueva interfaz, se puede seleccionar las tareas en las que actúa la interfaz o crearlassi no lo están aún. Para que el usuario pueda realizar la descripción de las distintas

interfaces, se le suministrará una barra de herramientas con distintas clases de objetos.

Cada objeto tendrá una serie de propiedades, relacionadas con su aspecto externo, como

puede ser el tamaño, color, posición…, y otras relacionadas con su comportamiento

individual o en función de las demás componentes, por ejemplo, un determinado botón

permanecerá deshabilitado mientras que no se haya dado un valor a todos campos de

texto, realizará un determinado proceso si unos determinados datos han sidointroducidos, etc.

7. Ejemplos.

En este apartado

incluimos un ejemplo de cómo

con la ayuda del usuario puede

Ilustración 1. Pantalla de Exinus para gestión de

Interfaces.

Ilustración 2. Interfaz diseñada con Exinus que simula la

reserva de un Hotel.


15/17


Ilustración 4. Botón Buscar Hotel

obtenerse el diagrama de flujo usando el método de reingeniería propuesto. Para ello, en

la imagen se muestra una interfaz cuya tarea es realizar la reserva de una habitación de

hotel una vez diseñada por el usuario.

El flujo de trabajo correspondiente a esta ventana se observa en la siguiente

figura. El flujo de trabajo es disparado manualmente por el usuario al recibir la solicitud

de un cliente para la realización de una reserva, o bien, por acción de otro evento como

puede ser un correo electrónico o una

llamada de teléfono del cliente.

Como se indica en la sección dirigida a

las transacciones de interfaces, la

ventana que es objeto de nuestro

ejemplo, es precedida por la ventana

principal, de ahí que se incluya en la

entrada, pero también puede darse el caso de que esta ventana principal la suceda, en el

caso de que no exista ninguna oferta es ese momento, por ello será incluida también en

la salida, tras lo cuál se finalizará la tarea. En el caso de que exista una reserva, se

procederá a su solicitud, por ello, a esta

ventana también puede ser sucedida por

“Solicitar Reserva”.La representación de

los objetos que forman tendrá un aspecto

similar a la componente antes descrita.

En el siguiente gráfico se muestra la

especificación del botón ‘Buscar Hotel’:

Para finalizar mostraremos la descripción del flujo de trabajo RESERVAR HOTEL:

Ilustración 5. Flujo de trabajo RESERVAR HOTEL

Ilustración 3. Proceso Reserva Hotel.


16/17


A continuación mostraremos un ejemplo de la especificación que obtendríamos,

en el caso de que tuviéramos un proyecto ‘Photel’, con una sola ventana, la cual

llamaremos ‘Cargar Concepto’, cuya función es la de cargar un concepto de un cliente a

su factura, o bien cargarla en su cuenta personal o bien a su tarjeta de crédito.

La especificación del proyecto (no completa) seria la siguiente:

10 Hotel 19 12345678 Pepe

Perez

Admin xjdfjsf Administrador

19 18

11 FormCuentaCliente

139 161 407 261

TExtEtiqueta etCodCliente Codigo Cliente:

contiene el codigo que identifica al cliente.

0 0

-1 CodCliente

-16777201 34 24 74

13 MS Sans Serif 8 -16777208

0 0 0 0

……………………….

……………………….

8. Conclusiones.

Pensamos, que es muy adecuado utilizar el conocimiento de los usuarios desistemas turísticos, para que expresen de forma clara y concisa qué aspectos serían

mejorables en los sistemas de información con los que trabajan. Actualmente, se está

perfeccionando la nueva versión de la herramienta Exinus, y es deseable la creación de

un módulo específico para que pueda modelarse de forma automática y manual

directamente los flujos de trabajo de dichas interfaces. Además, el grupo SICUMA

trabaja actualmente en el desarrollo de un lenguaje de definición de los procesos de

trabajo, así como en el desarrollo de una lógica temporal que describa los flujos dedatos.


17/17


Bibliografía

F.CASADO, T.NAVARRETE, S.SAYAGO, J.BLAT. Una herramienta para

la creación de interfaces multiplataforma con UIML Proceedings on theVI Congreso de Interacción Persona Ordenador (INTERACCIÓN' 2005).

Editores: Ángel R. Puerta, Miguel Gea. Granada, Spain. ISBN: 84-9732-436-6,

pp: 181-189

JORGE GARCÍA OCHOA DE ASPURU. Lenguajes XML para la definición de

interfaces de usuario. Julio, 2005

JOSÉ A. MACÍAS, ÁNGEL R. PUERTA, PABLO CASTELLS. MBUI Para

Procesos de Ingeniería Inversa

JOSE L. CARO HERRERO, A. GUEVARA PLAZA, JOSÉ L. LEIVA

OLIVENCIA (GRUPO SICUMA). Aplicación de técnicas workflow a la

reingeniería de sistemas de información. CISTI 2006. Esposende, Portugal.

NURIA HURTADO RODRÍGUEZ, J.MARIANO GONZÁLEZ ROMANO,

JESÚS TORRES VALDERRAMA. Revisión de lenguajes declarativos para la

descripción de Interfaces de Usuarios Independientes del Dispositivo.

Interacción 2004. Mayo 2004.

JUAN ANTONIO LÓPEZ QUESADA. Mantenimiento del software. 2004-2005

Departamento de Informática y Sistemas. Facultad de Informática, Murcia.

JOSÉ L.LEIVA. Construcciones de especificaciones de interfaces en un proceso

de reingenieria, en: 2da. Conferencia Iberoamericana en Sistemas, Cibernética

e Informática CISCI 2003, Orlando (Florida)-EEUU .

Propuesta de Sistemas de Informacion

Documents

Transcript of Propuesta de Sistemas de Informacion