Propuesta de Sistemas de Informacion

See
discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/277268668
Propuesta de Lenguaje para Descripcin de

Interfaces de Sistemas Tursticos Basados en
Tcnicas de Ingeniera Inversa y en Modelado
Workflow.
Conference Paper January 2006
READS
30
5 authors, including:
Jos L. Leiva
Jos L. Caro
University of Malaga
11 PUBLICATIONS 4 CITATIONS
SEE PROFILE
SEE PROFILE
Antonio Guevara
Andrs Aguayo
SEE PROFILE
SEE PROFILE
Available from: Jos L. Leiva

Retrieved on: 15 May 2016
Propuesta de Lenguaje para Descripcin de

Interfaces de Sistemas Tursticos Basados en
Tcnicas de Ingeniera Inversa y en Modelado
Workflow.
Roco Rodrguez, Jos L. Leiva 1, Jos L. Caro 2, Antonio Guevara 3, Andrs Aguayo 4.
Departamento de Lenguajes y Ciencias de la Computacin. Universidad de Mlaga, Espaa.

1. jlleivao@lcc.uma.es
2. jlcaro@lcc.uma.es
3. guevara@lcc.uma.es
4. aguayo@lcc.uma.es
Resumen:
La evolucin constante del desarrollo de sistemas de informacin tursticos, obliga a

afrontar nuevos mtodos de trabajo. La complejidad y coste de comenzar a disear un nuevo
sistema, es evitable si se modifican y mejoran aspectos necesarios del sistema anterior. La
ingeniera inversa surge como alternativa fundamental en todo proceso de reingeniera, ya
que la recuperacin de especificaciones de diseo y de flujos de trabajo, permiten crear una
representacin de alto nivel de abstraccin. Nuestra propuesta se basa en el diseo de
herramientas que permitan un mtodo de trabajo cooperativo en el que impliquemos al
usuario en las fases de anlisis y diseo, suministrndole para ello herramientas de fcil uso
para conseguir unas especificaciones con un alto grado de coherencia con las exigencias
finales de los usuarios. El marco establecido permitir la obtencin de especificaciones sobre
las interfaces y de los flujos de trabajo presentes y futuros del sistema de informacin.
VI Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones Turitec 2006
Este artculo estudia la base terica de nuestro mtodo as como la aplicacin de dicha
tecnologa en las empresas del sector turismo, centrndose en la mejora de sus sistemas de
informacin para obtener una mayor satisfaccin en los requerimientos del cliente.
Palabras clave: Reingeniera; Ingeniera Inversa; Workflow; Interaccin persona-ordenador;

CSCW; BPR.
1. Introduccin.
Con la proliferacin de las nuevas tecnologas y los grandes avances de la informtica en las
ltimas dcadas, muchas empresas cuentan con un sistema software adecuado a las
necesidades de su negocio con la que organizan la informacin necesaria para llevar a cabo su
trabajo.
Debido al paso del tiempo y a la gran velocidad a la que evoluciona la informtica, la

aparicin de nuevas plataformas, sistemas operativos, avances en los lenguajes de
programacin, y la aparicin 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 tamao 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 sucedindose 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 solucin al problema ante la imposibilidad de realizar un mantenimiento puede

ser la utilizacin de tcnicas de reingeniera e ingeniera inversa, de manera que sea posible
realizar un examen del sistema heredado y reconstruirlo. En el apartado 2 comentaremos la
problemtica actual as como las caractersticas de estas tcnicas. Propondremos la
participacin de los usuarios que utilizan el sistema, de modo que partiendo de una aplicacin
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 aplicacin en la cul el usuario proporcionar un diseo
de cada una de las interfaces que compondrn el proyecto, dichas interfaces sern traducidas a
un lenguaje de definicin basado en XML, de modo, que puedan ser reconstruidas en
cualquier lenguaje de programacin [2]. Existe un gran nmero de lenguajes declarativos para
la definicin de interfaces de usuario (diseo externo), los cuales resumiremos en el apartado
3. En el apartado 4 y 5, haremos una descripcin 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 descripcin de la aplicacin
propuesta(EXINUS1), del lenguaje que hemos utilizado para la describir las interfaces de
usuario, el proceso de diseo de las interfaces y la generacin 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. Problemtica.
Como ya se ha comentado anteriormente el usuario posee una aplicacin que por
diversos motivos desea remodelarse. En este apartado describimos como la ingeniera inversa
y la reingeniera puede ayudarnos a la reconstruccin del sistema, ya que por diversos
motivos se ha concluido que no es posible realizar actividades de mantenimiento debido a la
falta de documentacin sobre el sistema y a la imposibilidad de contactar con los
desarrolladores iniciales.
Debido a la escasa informacin que se posee de la aplicacin a reconstruir es necesaria

la recopilacin de los datos necesarios tanto de las caractersticas 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 utilizacin de la ingeniera inversa como parte del proceso
de reingeniera, ya que, a travs de ella podemos realizar una obtencin de las
especificaciones del diseo del sistema y de los flujos de trabajo, obteniendo una
EXINUS (EXtraccin INformacin USuario)
representacin de alto nivel de abstraccin, que permita obtener un sistema de mayor calidad,
mayor eficiencia, correccin, usabilidad, etc.[7]
De este modo la reingeniera es una solucin al problema del remodelado de una

aplicacin. Sin embargo, estas tcnicas, 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 diseo de las interfaces y los flujos de trabajo necesarios,
tanto presentes como futuros. La base del mtodo es el proporcionar al usuario las
herramientas necesarias que permitan realizar un diseo 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 descripcin de interfaces de usuario.

En este apartado expondremos algunas caractersticas de los principales lenguajes para
la descripcin de interfaces, adems de sus ventajas e inconvenientes, caractersticas y
finalidad de estos lenguajes.
El objetivo principal de estos lenguajes es proporcionar una descripcin de la

estructura de la interfaz, de manera sencilla y con alto nivel de abstraccin, de modo que a
partir de dicha especificacin sea posible la generacin de la interfaz de usuario final.
Los lenguajes declarativos no estn relacionados con ningn lenguaje de programacin

en concreto sino que son independientes del mismo, adems 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 programacin, con capacidad de crear
interfaces de usuario, o en cualquier dispositivo, tanto un PC como un PDA o dispositivos
mviles[1][2].
El lenguaje para descripcin de documentos XML proporciona una sintaxis robusta y

estructurada para definir lenguajes declarativos jerrquicos. Los lenguajes basados en XML
son serios candidatos para soportar especificaciones, gracias a su versatilidad, facilidad de
mantenimiento y refinamiento. A continuacin se muestran las principales caractersticas de

los lenguajes ms importantes basados en XML[2][5].
3.1. AAIML.
AAIML es un lenguaje en vas de desarrollo, cuya finalidad, es ampliar el mercado

haciendo interfaces ms accesibles, por ejemplo, por medio de la voz, esto puede ser
interesante para personas con discapacidades. Para que esto sea posible es necesaria la
comunicacin entre los dispositivos de E/S. Debido a que los dispositivos estn fabricados por
diferentes compaas, es necesario la utilizacin de una consola, Consola Remota Universal
(URC), para controlar dichos dispositivos[5].
3.2. AUIML.
Lenguaje desarrollado por IBM y diseado para permitir la definicin de la semntica

de la interaccin con el usuario. Esta centrado, por tanto, en la descripcin de aspectos de
interaccin ms que en aspectos de presentacin. Toda la informacin se codifica una sola vez
y se traduce utilizando una traduccin dependiente del dispositivo final. Esta diseado para
ser independiente de la plataforma, del lenguaje de programacin final y de la tecnologa de
implementacin. [5]
3.3. UIML.
Este lenguaje, permite obtener definiciones declarativas de interfaces de usuario

independientes de la plataforma, tipo de interaccin y del lenguaje de programacin.
Para escribir una interfaz en UIML se debe realizar, por un lado una definicin de la interfaz
genrica, y por otro lado un documento UIML que representa el estilo de presentacin
apropiado para el dispositivo en el cul la interfaz se va a ejecutar. De este modo, una misma
aplicacin solo necesitar un documento UIML de especificacin para cualquier dispositivo y
un documento de estilo para cada dispositivo.
3.4. XIML.
Suministra el soporte necesario para la modelizacin, diseo y generacin de

interfaces multiplataforma. Es capaz de representar las cinco dimensiones de una interfaz
(tareas, dominio, usuarios, presentacin y dilogo) 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 descripcin de interfaces especficamente diseado

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
tecnologas W3C ya existentes.
La filosofa de XUL consiste en no reinventar nada, sino en utilizar estndares actuales

para crear interfaces y aplicaciones multiplataformas. La arquitectura se basa en el uso de
paquetes, los cules se componen de contenido, apariencia, comportamiento y plataforma. En
cada unos de ellos se hace uso de diferentes tecnologas.[2]
3.6. XFORMS.
XForms es una propuesta del consorcio W3C para la especificacin de formularios

para la web que puedan ser usados en una amplia variedad de plataformas. Su versin 1.0 ha
llegado a ser recientemente una recomendacin de W3C.
La caracterstica ms importante que proporciona esta tecnologa es que, a diferencia

que los formularios web habituales, las especificaciones del diseo de la interfaz se define por
separado 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 separacin entre
el propsito y la presentacin del formulario.
Como se ha comentado antes XForms surge con la finalidad de sustituir los actuales
formularios web. Para ello, define una serie de componentes visuales ms ricas, capaces de
generar interfaces mucho ms tiles y usables.[2,5]
4. Exinus-XML. Lenguaje de descripcin de proyectos e interfaces.

A continuacin describiremos la estructura que utilizamos para guardar los
formularios o interfaces. El objetivo es que las interfaces de usuario diseadas por el usuario
puedan ser generadas desde cualquier lenguaje de programacin 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 abstraccin.
La estructura que proponemos se basa en etiquetas anidadas unas dentro de otras:

<PROJECT><INTERFACE> .</INTERFACE>. </PROJECT>
Para almacenar los datos de un proyecto usaremos la siguiente estructura:

<PROJECT>
<ROLE> rol o perfil de usuario
<ID> id proyecto </ID>
</ROLE>
<NAME>Nombre del Proyecto</NAME>
</USER>
<USER>
<USER>
<ID> id usuario </ID>
<DNI> dni </DNI>

<NAME>
nombre
</USER>
de
usuario
</NAME>
<OWNER>Nombre
<SURNAME>
apellidos
</SURNAME>
del
Propietario</OWNER>
<INTERFACE>id interfaz1</INTERFACE>
<LOGIN> login </LOGIN>

<PASSWORD>
encriptada </PASSWORD>
contrasea
<INTERFACE>id interfaz2</INTERFACE>
</PROJECT>
<PROJECT> </PROJECT> indican comienzo y final de la especificacin del

proyecto. Entre estas dos etiquetas distinguimos las siguientes propiedades:
Etiqueta
<ID>
</ID>
Definicin
identificador del proyecto
<NAME></NAME>
nombre del proyecto
<OWNER > </OWNER>
propietario del proyecto
A continuacin se definen cada uno de los usuarios que tienen permiso para
acceder al proyecto, cada una de las especificaciones estar enmarcada por las etiquetas:
<USER> </USER> Entre las cules se incluirn los datos de los usuarios:
Etiqueta
Defincion
<ID> </ID>
identificador o cdigo del usuario
<DNI> </DNI>
Dni
<NAME> </NAME>
Nombre
<SURNAME> </SURNAME>
Apellidos
<LOGIN> </LOGIN>
Login
<PASSWORD> </PASSWORD>
contrasea que usa el usuario, encriptada para ms seguridad.
<ROLE> </ROLE>
perfil del usuario, administrador, jefe de proyectos
Por ltimo se incluir el identificador de las interfaces que forman parte del
proyecto.
<INTERFACE> identificador de la interfaz </INTERFACE>
Por tanto, al guardar un proyecto, se generar un fichero con la informacin

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,
descripcin
para
posteriormente definir cada uno de los objetos que

la componen y los atributos de cada uno de ellos.
La descripcin de la estructura general de un
formulario puede dividirse en dos zonas bien
diferenciadas: zona de definicin de propiedades de
la interfaz y una zona de definicin de componentes de la interfaz. El principio y el final
de la interfaz estarn definido por las etiquetas: <INTERFACE> </INTERFACE>
Entre estas dos etiquetas se incluirn dos zonas, en la primera se incluirn las
propiedades relacionadas con el formulario:
Etiqueta
Definicin
<ID> </ID>
identificador del formulario
<NAME></NAME>
nombre del formulario
<NCOMPONENTS><NCOMPONENTS>
numero de componentes que contiene el formulario
<OWNER> </OWNER>
Propietario
<TOP> </TOP>
posicin: coordenada X
<LEFT> </LEFT>
posicin: coordenada Y
<WIDTH> </WIDTH>
anchura del formulario
<HEIGHT> </HEIGHT>
altura del formulario
<COLOR> </COLOR>
color del formulario
<FONT>
fuente de la letra del formulario
<NAME> </NAME>
nombre
<SIZE> </SIZE>
tamao
<COLOR></COLOR>
color
<STYLE>
estilo de la fuente
<BOLD> 0/1 </BOLD>
0/1 = normal / negrita
<ITALIC> 0/1 </ITALIC>
0/1 = normal / cursiva
<UNDERLINE> 0/1 </UNDERLINE>
0/1 = normal / subrayado
<STRIKEOUT> 0/1 </STRIKEOUT>
0/1 = normal / tachado
</STYLE>
</FONT>
En la segunda zona de definirn cada una de las componentes que forman el

formulario.
Cada
componente
estar
enmarcada
por
las
etiquetas:
</OBJECT></OBJECT> y para cada componente se almacenarn las siguientes

propiedades:
Etiquetas
Definicin
<TYPE> <TYPE>
indica el tipo de componente: botn, campo de texto, etiqueta
<NAME></NAME>
nombre de la componente
<CAPTION></CAPTION>
Etiqueta
<TOP> </TOP>
posicin: coordenada X
<LEFT> </LEFT>
posicin: coordenada Y
<WIDTH> </WIDTH>
Anchura
<HEIGHT> </HEIGHT>
Altura
<COLOR> </COLOR>
Color
<DESCRIPTION> ... </DESCRIPTION>
Descripcion
<OBJETIVES>...</OBJETIVES>
Objetivos
<VISIBLE> ... </VISIBLE>
indica cuando desea el usuario que la componente este visible,

tomar los valores :
0 siempre
1 nunca
2 cuando se cumpla una condicin
<VCONDITION> </VCONDITION>
Condicin que indica cuando se desea que una componente se

establezca como visible.
<ENABLED> </ENABLED>
indica cuando desea el usuario que la componente este

habilitada, tomar los valores :
0 siempre

1 nunca
2 cuando se cumpla una condicin
<ECONDITION>... </ECONDITION>
Condicin que indica cuando se desea que una componente se

establezca como habilitada.
<VALUE> ... </VALUE>
Valor que tomara la componente: tendr significado en
<MASKED> </MASKED>
indica cuando desea el usuario que la componente este
componentes como etiquetas, campos de texto
enmascarada, tomar los valores :

0 No
1 Si
2 Contrasea: los caracteres sern sustituidos por *
Esta propiedad solo ser til para campos de texto.
<MASK></MASK>
Indica la estructura de la mscara, en el caso, de que el campo

de texto est enmascarado.
fuente de la letra del formulario
<FONT>
<NAME> </NAME>
nombre
<SIZE> </SIZE>
tamao
<COLOR></COLOR>
color
<STYLE>
estilo de la fuente
<BOLD> 0/1 </BOLD>
0/1 = normal / negrita
<ITALIC> 0/1 </ITALIC>
0/1 = normal / cursiva
<UNDERLINE> 0/1 </UNDERLINE>
0/1 = normal / subrayado
<STRIKEOUT> 0/1 </STRIKEOUT>
0/1 = normal / tachado
</STYLE>
</FONT>
Estas propiedades, sern las mismas para todas las componentes, en el caso de
que 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 intrnsecas de
cada uno de los objetos descritos, la herramienta debe extraer informacin respecto a la
identificacin de los flujos de trabajo para obtener unas especificaciones de los mismos.
De la misma manera que en la descripcin externa, deben distinguirse los flujos de
trabajo del sistema actual as como modificaciones o incremento de flujos del nuevo
sistema. [4]
A continuacin se incluye una tabla con las caractersticas de cada una de las
primitivas que formarn parte de los diagramas de flujo de trabajo antes propuesto:
Componente
Representacin
Descripcin
Cada workflow representa una subtarea que forma
parte del flujo de trabajo. Los flujos representados con
a) Nombre flujo
c) Nombre flujo
b)
d) Nombre flujo
Workflow
lnea 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 lnea (b y d) indican que la tarea es
Nombre flujo
primitiva y no se divide en ms subtareas.
Esta componente se usa para indicar el paso de una

interfaz a otra.
Puede que en la transicin se produzca un paso de
parmetros, de entrada (E), de salida (S) o ambas (E/S).
Transicin de interfaz.
Nombre de la
Interfaz
Representacin de cada uno de los objetos que

formarn parte de la interfaz. La descripcin puede
Tipo:
Interfaz
acarrear
un
listado
de
precondiciones
y/o
postcondiciones que deben cumplirse antes y/o despus

de la aparicin de dicho objeto en la interfaz
Objeto
Nombre
Descripcin:
Usuario
Se representar de la misma forma que los flujos de

trabajos indicados anteriormente, con la diferencia de
Nombre tarea
Nombre tarea
que en lugar de usar una caja usaremos una elipse.
Flujos de trabajos de un
objeto.
Nombre tarea
Nombre tarea
Comienzo y final del flujo de trabajo.

Inicio y fin
Con ests componentes se indica la posible ejecucin

de varios flujos a la vez. A partir de un flujo de trabajo
base se produce una descomposicin en varios
subfujos, de modo que, se puede ejecutar uno de ellos o

Alternancia y Unin de
flujos de trabajo
varios.
n
Estos constructores se refieren a la ejecucin paralela
de flujos de trabajo, creando nuevos subflujos nuevos
de longitud temporal indeterminada que en algn

momento, mediante el constructor de reunin se
Bifurcacin y Reunin
de flujos.
sincronizarn.
Con esta componente se producir la ejecucin de uno
Opcionabilidad de
flujos.
T
F
de los flujos, dependiendo del resultado del predicado

P.
Conjunto de flujos de trabajo que se repetirn mientras
se cumpla la condicin P.
Bloque de repeticin.
Descripcin de las componentes para la especificacin de flujos de trabajo.
6. Herramienta EXINUS.
En este punto realizaremos una descripcin breve de la herramienta EXINUS, la
cul ofrece una solucin a la problemtica explicada anteriormente. Como ya
comentamos en apartados anteriores partimos de un sistema que debe ser remodelado.
El primer paso para realizar la reestructuracin del sistema es la recopilacin de

los datos necesarios para ello. Para esta tarea se ha considerado realizar un
aprovechamiento de la experiencia y el conocimiento que el usuario posee de la

aplicacin a remodelar, de modo, que ser este el que proporcione la informacin.
Por los motivos antes expuestos, el objetivo principal de la aplicacin EXINUS

es la de proporcionar un entorno sencillo y de las herramientas adecuadas con las que el
usuario sea capaz de realizar el diseo de las interfaces de su aplicacin. Una vez que se
han realizado el diseo 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 aplicacin 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.
Ilustracin 1. Pantalla de Exinus para gestin de

Interfaces.
Adems de la creacin de formularios, la

herramienta permitir la creacin 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 acta la interfaz o crearlas
si no lo estn an. Para que el usuario pueda realizar la descripcin 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 tamao, color, posicin, y otras relacionadas con su comportamiento
individual o en funcin de las dems componentes, por ejemplo, un determinado botn
permanecer deshabilitado mientras que no se haya dado un valor a todos campos de
texto, realizar un determinado proceso si unos determinados datos han sido
introducidos, etc.
7. Ejemplos.
En
este
apartado
incluimos un ejemplo de cmo

con la ayuda del usuario puede
Ilustracin 2. Interfaz diseada con Exinus que simula la

reserva de un Hotel.
obtenerse el diagrama de flujo usando el mtodo de reingeniera propuesto. Para ello, en

la imagen se muestra una interfaz cuya tarea es realizar la reserva de una habitacin de
hotel una vez diseada 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 realizacin de una reserva, o bien, por accin de otro evento como
puede ser un correo electrnico o una
llamada de telfono del cliente.
Como se indica en la seccin dirigida a
las transacciones de interfaces, la
ventana que es objeto de nuestro
ejemplo, es precedida por la ventana
Ilustracin 3. Proceso Reserva Hotel.
principal, de ah que se incluya en la
entrada, pero tambin 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 tambin en
la salida, tras lo cul se finalizar la tarea. En el caso de que exista una reserva, se
proceder a su solicitud, por ello, a esta
ventana tambin puede ser sucedida por
Solicitar Reserva.La representacin de
los objetos que forman tendr un aspecto
similar a la componente antes descrita.
En el siguiente grfico se muestra la
Ilustracin 4. Botn Buscar Hotel
especificacin del botn Buscar Hotel:

Para finalizar mostraremos la descripcin del flujo de trabajo RESERVAR HOTEL:
Ilustracin 5. Flujo de trabajo RESERVAR HOTEL
A continuacin mostraremos un ejemplo de la especificacin que obtendramos,

en el caso de que tuviramos un proyecto Photel, con una sola ventana, la cual
llamaremos Cargar Concepto, cuya funcin 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 crdito.
La especificacin del proyecto (no completa) seria la siguiente:
<PROJECT>
<ID>10</ID>
<NAME>Hotel</NAME><USER><ID> 19 </ID><DNI> 12345678 </DNI><NAME> Pepe
</NAME><SURNAME> Perez </SURNAME>

<LOGIN> Admin </LOGIN><PASSWORD> xjdfjsf </PASSWORD><ROLE> Administrador
</ROLE></USER><OWNER>19</OWNER><INTERFACE> 18 </INTERFACE>
</PROJECT>
<INTERFACE><COUNTOBJECT> 11 </COUNTOBJECT><NAME> FormCuentaCliente </NAME>

<TOP> 139 </TOP><LEFT> 161 </LEFT><WIDTH> 407 </WIDTH><HEIGHT> 261 </HEIGHT>
<OBJECT><TYPE> TExtEtiqueta </TYPE><NAME> etCodCliente </NAME><CAPTION> Codigo Cliente:
</CAPTION><DESCRIPTION> contiene el codigo que identifica al cliente. </DESCRIPTION><OBJETIVES> </OBJETIVES>
<VISIBLE> 0 </VISIBLE><VCONDITION> </VCONDITION><ENABLED> 0 </NAME><ECONDITION>
</ECONDITION><VALUE> </VALUE><ASOCIATED> -1 </ASOCIATED><COMP_ASOCIATED> CodCliente
</COMP_ASOCIATED><COLOR> -16777201 </COLOR><TOP> 34 </TOP><LEFT> 24 </LEFT><WIDTH> 74 </WIDTH>
<HEIGHT> 13 </HEIGHT><FONT><NAME> MS Sans Serif </NAME><SIZE> 8 </SIZE><COLOR> -16777208 </COLOR>
<STYLE><BOLD> 0 </BOLD><ITALIC> 0 </ITALIC><UNDERLINE> 0 </UNDERLINE><STRIKEOUT> 0 </STRIKEOUT>
</STYLE></FONT>
</OBJECT>
.
.
</INTERFACE>
8. Conclusiones.
Pensamos, que es muy adecuado utilizar el conocimiento de los usuarios de
sistemas tursticos, para que expresen de forma clara y concisa qu aspectos seran
mejorables en los sistemas de informacin con los que trabajan. Actualmente, se est
perfeccionando la nueva versin de la herramienta Exinus, y es deseable la creacin de
un mdulo especfico para que pueda modelarse de forma automtica y manual
directamente los flujos de trabajo de dichas interfaces. Adems, el grupo SICUMA
trabaja actualmente en el desarrollo de un lenguaje de definicin de los procesos de
trabajo, as como en el desarrollo de una lgica temporal que describa los flujos de
datos.
Bibliografa
F.CASADO, T.NAVARRETE, S.SAYAGO, J.BLAT. Una herramienta para

la creacin de interfaces multiplataforma con UIML Proceedings on the
VI Congreso de Interaccin Persona Ordenador (INTERACCIN' 2005).
Editores: ngel R. Puerta, Miguel Gea. Granada, Spain. ISBN: 84-9732-436-6,
pp: 181-189
JORGE GARCA OCHOA DE ASPURU. Lenguajes XML para la definicin de

interfaces de usuario. Julio, 2005
JOS A. MACAS, NGEL R. PUERTA, PABLO CASTELLS. MBUI Para

Procesos de Ingeniera Inversa
JOSE L. CARO HERRERO, A. GUEVARA PLAZA, JOS L.
LEIVA
OLIVENCIA (GRUPO SICUMA). Aplicacin de tcnicas workflow a la

reingeniera de sistemas de informacin. CISTI 2006. Esposende, Portugal.
NURIA HURTADO RODRGUEZ, J.MARIANO GONZLEZ ROMANO,

JESS TORRES VALDERRAMA. Revisin de lenguajes declarativos para la
descripcin de Interfaces de Usuarios Independientes del Dispositivo.
Interaccin 2004. Mayo 2004.
JUAN ANTONIO LPEZ QUESADA. Mantenimiento del software. 2004-2005

Departamento de Informtica y Sistemas. Facultad de Informtica, Murcia.
JOS L.LEIVA. Construcciones de especificaciones de interfaces en un proceso

de reingenieria, en: 2da. Conferencia Iberoamericana en Sistemas, Ciberntica
e Informtica CISCI 2003, Orlando (Florida)-EEUU .

Propuesta de Sistemas de Informacion

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Propuesta de Sistemas de Informacion

Cargado por

Copyright:

Formatos disponibles

See

Propuesta de Lenguaje para Descripcin de

Available from: Jos L. Leiva

Propuesta de Lenguaje para Descripcin de

Departamento de Lenguajes y Ciencias de la Computacin. Universidad de Mlaga, Espaa.

La evolucin constante del desarrollo de sistemas de informacin tursticos, obliga a

VI Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones Turitec 2006

Palabras clave: Reingeniera; Ingeniera Inversa; Workflow; Interaccin persona-ordenador;

Debido al paso del tiempo y a la gran velocidad a la que evoluciona la informtica, la

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

Una solucin al problema ante la imposibilidad de realizar un mantenimiento puede

VI Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones Turitec 2006

Debido a la escasa informacin que se posee de la aplicacin a reconstruir es necesaria

EXINUS (EXtraccin INformacin USuario)

VI Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones Turitec 2006

De este modo la reingeniera es una solucin al problema del remodelado de una

3. Lenguajes declarativos para la descripcin de interfaces de usuario.

El objetivo principal de estos lenguajes es proporcionar una descripcin de la

Los lenguajes declarativos no estn relacionados con ningn lenguaje de programacin

El lenguaje para descripcin de documentos XML proporciona una sintaxis robusta y

VI Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones Turitec 2006

mantenimiento y refinamiento. A continuacin se muestran las principales caractersticas de

AAIML es un lenguaje en vas de desarrollo, cuya finalidad, es ampliar el mercado

Lenguaje desarrollado por IBM y diseado para permitir la definicin de la semntica

Este lenguaje, permite obtener definiciones declarativas de interfaces de usuario

VI Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones Turitec 2006

Suministra el soporte necesario para la modelizacin, diseo y generacin de

El lenguaje XUL es un lenguaje de descripcin de interfaces especficamente diseado

La filosofa de XUL consiste en no reinventar nada, sino en utilizar estndares actuales

XForms es una propuesta del consorcio W3C para la especificacin de formularios

La caracterstica ms importante que proporciona esta tecnologa es que, a diferencia

VI Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones Turitec 2006

4. Exinus-XML. Lenguaje de descripcin de proyectos e interfaces.

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

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

<ROLE> rol o perfil de usuario

<ID> id proyecto </ID>

<NAME>Nombre del Proyecto</NAME>

<DNI> dni </DNI>

<LOGIN> login </LOGIN>

<PROJECT> </PROJECT> indican comienzo y final de la especificacin del

nombre del proyecto

<OWNER > </OWNER>

propietario del proyecto

VI Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones Turitec 2006

identificador o cdigo del usuario

contrasea que usa el usuario, encriptada para ms seguridad.

perfil del usuario, administrador, jefe de proyectos

Por tanto, al guardar un proyecto, se generar un fichero con la informacin

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

posteriormente definir cada uno de los objetos que

VI Congreso Turismo y Tecnologas de la Informacin y las Comunicaciones Turitec 2006

identificador del formulario

nombre del formulario

numero de componentes que contiene el formulario

anchura del formulario

altura del formulario

color del formulario

fuente de la letra del formulario

<BOLD> 0/1 </BOLD>

0/1 = normal / negrita

<ITALIC> 0/1 </ITALIC>

0/1 = normal / cursiva

<UNDERLINE> 0/1 </UNDERLINE>