View
8
Download
0
Category
Preview:
Citation preview
i
Resumen
El desarrollo del trabajo que se describe en este documento complementa el proceso de
composición de servicios Web que lleva a cabo el sistema WS-SIDDOO, en el que se genera
código en BPEL4WS a partir de diagramas de actividades y que representan la interacción de
los servicios Web involucrados en el proceso de composición.
Este trabajo se propuso para resolver algunas de las limitaciones a las cuales se
enfrentaba el usuario durante el modelado de un proceso de composición de servicios, tales
como limitarse al uso de los elementos UML: fork, join, mensajes de flujo, expresiones de
resguardo y note, durante el modelado del proceso, ya que WS-SIDDOO no permitía modelar
procesos de composición donde se requería el uso de concurrencia y sincronización de
actividades.
Para generar código en BPEL4WS correspondiente a los elementos del diagrama de
actividades de UML, se definió una metodología cuyo objetivo principal fue el análisis e
identificación de las correspondencias entre los elementos UML y elementos BPEL4WS.
El resultado de este trabajo fue la definición de nuevas estructuras para modelar
composiciones de servicios Web denominadas: estructura de concurrencia y sincronización
simple, estructura de concurrencia y sincronización compleja, y estructura de combinación
definida. Para probar el funcionamiento correcto de estas nuevas estructuras se realizaron 18
pruebas, las cuales todas fueron satisfactorias, se logró que el sistema WS-SIDDOO modele
composiciones donde se necesita la concurrencia y sincronización (flow), actividades en
espera de tiempos (wait) o actividades nulas (empty), estructuras condicionales que generen la
condición asociada de forma automática y estructuras con notas informativas que ayudan al
usuario a identificar las actividades, el envío, recepción de mensajes y la secuencia de
interacción del proceso.
ii
Abstract
The work described in this document complements the Web services composition process
implemented in the WS-SIDDOO system, in which BPEL4WS code is generated from activity
diagrams that represent the interaction among the Web services involved in the composition
process.
This work was proposed in order to overcome some limitations a user faced during the
process of Web services composition modeling, since WS-SIDDOO allowed the modeling of
some elements of the activity diagrams in UML such as fork, join, messages flows, guard
expressions and notes. However, elements such as concurrency and synchronization belong to
the activity diagrams and are also needed in a composition process.
In order to generate the BPEL4WS code that corresponds to the concurrency and
synchronization elements a methodology was defined. Its main objective was to analyze and to
identify the correspondences among those elements and BPEL4WS code. As a result, in this
thesis new structures for modeling Web services compositions were defined. The structures
are: simple concurrency and synchronization structure, complex concurrency and
synchronization structure, and, defined combination structure.
The new structures were implemented in the WS-SIDDOO and their performance was
tested using 18 test cases, all of them proved as expected. With the new structures, WS-
SIDDOO is now able to support the modeling of Web services compositions where
concurrency and synchronization, activities in waiting state, empty activities, conditional
structures with associated conditions, informative notes that support a user to understand the
activities, sending and receiving of messages and the sequence of the interaction process are
needed.
iii
Tabla de contenido Índice de figuras .................................................................................................................................. v
Índice de tablas................................................................................................................................. viii
Definiciones, acrónimos y abreviaturas .............................................................................................. ix
Capítulo I. Introducción
1.1 Introducción ........................................................................................................................ 1
1.2 Descripción del problema .................................................................................................... 2
1.3 Objetivo ............................................................................................................................... 3
1.4 Justificación ......................................................................................................................... 3
1.5 Beneficios ............................................................................................................................ 3
1.6 Alcances .............................................................................................................................. 4
1.7 Limitaciones ........................................................................................................................ 4
1.8 Organización de la tesis ....................................................................................................... 5
Capítulo II. Antecedentes
2.1 Antecedentes ....................................................................................................................... 6
2.2 Estado del arte ................................................................................................................... 10
2.3 Trabajos relacionados ........................................................................................................ 10
2.3.1 Herramientas de modelado para la composición de servicios Web ............................ 11
2.3.2 Enfoque: manejo por modelo UML 2.0 & Perfiles UML .......................................... 14
2.3.3 Análisis comparativo ................................................................................................. 17
Capítulo III. Marco Conceptual
3.1 Servicios Web .................................................................................................................... 19
3.1.1 XML (eXtensible Markup Language) ........................................................................ 21
3.1.2 WSDL (Web Services Description Language) .......................................................... 21
3.1.3 SOAP (Simple Object Access Protocol) .................................................................... 22
3.1.4 UDDI (Universal Description, Discovery and Integration) ....................................... 22
3.2 Composición de servicios .................................................................................................. 22
3.2.1 Coreografía ................................................................................................................ 23
3.2.2 Orquestación .............................................................................................................. 23
3.3 Lenguaje de composición BPEL4WS ................................................................................ 23
3.3.1 Elementos del lenguaje BPEL4WS............................................................................ 24
3.4 Diagramas de actividades .................................................................................................. 26
Capítulo IV. Análisis y solución del problema
4.1 Una visión general hacia WS-SIDDOO............................................................................. 29
4.1.1 Arquitectura de WS-SIDDOO ................................................................................... 29
4.1.2 Gramática visual WS-SIDDOO ................................................................................. 30
4.1.3 WS-SIDDOO como servicio Web ............................................................................. 31
4.1.4 Cliente WS-SIDDOO ................................................................................................ 31
4.2 Analizador de documentos WSDL (WS-Compositor) ............................................... 32
4.3 Módulo de composición de servicios Web ......................................................................... 32
4.3.1 Arquitectura de clases del módulo de composición ................................................... 33
4.3.2 Descripción del módulo de composición ................................................................... 34
4.4 Módulo ventanas ............................................................................................................... 35
4.4.1 Arquitectura de clases del módulo ventanas .............................................................. 35
iv
4.4.2 Descripción del módulo ventanas .............................................................................. 35
4.5 Identificación de las correspondencias semánticas en BPEL a partir de un diagrama de
actividad ....................................................................................................................................... 36
4.5.1 Elementos BPEL implementados .............................................................................. 37
4.5.2 Escenarios para la generación de código en BPEL .................................................... 38
4.5.3 Restricciones ............................................................................................................. 50
4.6 Metodología de solución propuesta ................................................................................... 50
Capítulo V. Diseño e implementación de la extensión del sistema
5.1 Diseño de casos de uso general del sistema WS-SIDDOO ................................................ 53
5.2 Diseño del diagrama de secuencia del sistema WS-SIDDOO ........................................... 55
5.3 Diseño de los diagramas de secuencia de la extensión al módulo de composición ............ 57
5.4 Diseño de la extensión al módulo de composición ............................................................ 63
5.5 Implementación de la extensión al sistema WS-SIDDOO ................................................. 72
5.5.1 Módulo de composición y ventanas ........................................................................... 72
Capítulo VI. Pruebas
6.1 Hipótesis a probar .............................................................................................................. 81
6.2 Identificador del plan de pruebas ....................................................................................... 81
6.3 Documentación de prueba ................................................................................................. 81
6.4 Descripción del plan de pruebas ........................................................................................ 81
6.5 Especificación del diseño de pruebas ................................................................................ 85
6.6 Especificación de casos de prueba ..................................................................................... 88
6.7 Especificación del procedimiento de pruebas .................................................................... 99
6.8 Resultados de las pruebas ................................................................................................ 100
6.9 Análisis de los resultados ................................................................................................ 101
Capítulo VII. Conclusiones
7.1 Aportaciones.................................................................................................................... 103
7.2 Estado anterior y estado actual del sistema ...................................................................... 104
7.3 Trabajo futuro .................................................................................................................. 104
Referencias ...................................................................................................................................... 105
Anexo A. Descripción de los escenarios de los casos de uso ........................................................... 108
Anexo B. Descripción de las clases de la extensión a los módulos composición y ventanas ............ 115
Anexo C. Descripción de los casos de prueba .................................................................................. 118
v
Índice de figuras
Figura 1. Esquema de relación de los trabajos antecedentes de investigación ......................................... 6
Figura 2. Sistema SIDDOO ..................................................................................................................... 7
Figura 3. Sistema SIDDOO visto como servicio Web ............................................................................. 8
Figura 4. Modelo conceptual de la herramienta WS- Compositor ........................................................... 8
Figura 5.Modelo conceptual del sistema de búsqueda y selección de servicios Web (SBSSW) .............. 9
Figura 6.Sistema de composición de servicios Web WS-SIDDOO ......................................................... 9
Figura 7. Elementos de la Arquitectura Orientada a Servicios (SOA) ................................................... 20
Figura 8. Sistema de composición de servicio Web WS-SIDDOO ....................................................... 29
Figura 9. Diagrama de clases del Módulo Composición ....................................................................... 33
Figura 10. Diagrama de clases del módulo ventanas ............................................................................. 35
Figura 11. Correspondencia en BPEL con la actividad Wait ................................................................. 38
Figura 12. Correspondencia en BPEL con la actividad Empty .............................................................. 38
Figura 13. Estructura de concurrencia y sincronización simple con dos flujos ...................................... 39
Figura 14. Estructura de concurrencia y sincronización simple con tres flujos ..................................... 40
Figura 15. Estructura de concurrencia y sincronización compleja con una estructura condicional
simple, y su correspondencia en código BPEL ...................................................................................... 41
Figura 16. Estructura de concurrencia/sincronización compleja utilizando una estructura condicional
doble y su correspondencia en código BPEL ........................................................................................ 41
Figura 17. Estructura de concurrencia y sincronización compleja utilizando una estructura condicional
tipo selección en cascada, y su correspondencia en código BPEL ........................................................ 42
Figura 18. Estructura de concurrencia y sincronización compleja utilizando una estructura condicional
tipo selección múltiple, y su correspondencia en código BPEL ............................................................ 43
Figura 19. Estructura de concurrencia y sincronización utilizando una estructura iterativa while, y su
correspondencia en código BPEL ......................................................................................................... 43
Figura 20. Estructura de concurrencia y sincronización compleja utilizando una estructura iterativa
do_while, y su correspondencia en código BPEL ................................................................................. 44
Figura 21. Escenario de combinación de estructura de concurrencia y sincronización simple con una
estructura condicional simple; notas informativas; y su correspondencia en código BPEL................... 45
Figura 22. Escenario de combinación de estructura de concurrencia y sincronización simple con una
estructura condicional doble; notas informativas; y su correspondencia en código BPEL .................... 46
Figura 23. Escenario de combinación de estructura de concurrencia y sincronización simple con una
estructura de selección en cascada; notas informativas; y su correspondencia en código BPEL ........... 47
Figura 24. Escenario de combinación de estructura de concurrencia y sincronización compleja, con una
estructura condicional iterativa (while); notas informativas; y su correspondencia en código BPEL .... 48
Figura 25. Escenario de combinación de estructura de concurrencia y sincronización compleja, con una
estructura de selección múltiple; notas informativas; y su correspondencia en código BPEL ............... 49
Figura 26. Metodología de solución propuesta ...................................................................................... 51
Figura 27. Diagrama general de casos de uso del sistema WS-SIDDOO .............................................. 53
Figura 28. Diagrama general de casos de uso Generar código BPEL .................................................... 54
vi
Figura 29. Diagrama de secuencia general del sistema WS-SIDDOO................................................... 56
Figura 30. Diagrama de secuencia para generar código para estructuras de concurrencia/sincronización
simples .................................................................................................................................................. 58
Figura 31. Diagrama de secuencia para generar código para estructuras de concurrencia/sincronización
complejas .............................................................................................................................................. 60
Figura 32. Diagrama de secuencia para generar código para estructuras de combinación definidas ..... 62
Figura 33.Estructuras concurrentes y de sincronización simples ........................................................... 64
Figura 34. Estructura concurrente y de sincronización compleja con una estructura interna condicional
simple .................................................................................................................................................... 64
Figura 35. Estructura concurrente y de sincronización compleja con una estructura interna condicional
doble ..................................................................................................................................................... 65
Figura 36. Estructura concurrente y de sincronización compleja con una estructura interna de selección
en cascada ............................................................................................................................................. 65
Figura 37. Estructura concurrente y de sincronización compleja con una estructura interna de selección
múltiple ................................................................................................................................................. 66
Figura 38. Estructura concurrente y de sincronización compleja con una estructura interna iterativa
while ..................................................................................................................................................... 66
Figura 39. Estructura concurrente y de sincronización compleja con una estructura interna iterativa do
while ..................................................................................................................................................... 67
Figura 40. Estructura concurrente y sincronización de combinación definida con una estructura
condicional simple externa y notas informativas ................................................................................... 68
Figura 41. Estructura concurrente y sincronización de combinación definida con una estructura
condicional doble externa y notas informativas..................................................................................... 69
Figura 42. Estructura concurrente y sincronización de combinación definida con una estructura interna
condicional doble, una estructura externa iterativa y notas informativas ............................................... 69
Figura 43. Estructura concurrente y sincronización de combinación definida con estructura externa de
selección en cascada y notas informativas ............................................................................................ 70
Figura 44. Estructura concurrente y sincronización de combinación definida con una estructura externa
de selección múltiple y notas informativas ............................................................................................ 71
Figura 45. Arquitectura de clases extendida del módulo de composición ............................................. 72
Figura 46. Arquitectura de clases extendida del módulo ventanas ........................................................ 73
Figura 47. Ventana de configuración de la actividad Wait .................................................................... 75
Figura 48. Ventana de configuración de la actividad Empty ................................................................. 76
Figura 49. Ventana de configuración para la condición booleana ......................................................... 76
Figura 50. Ventana para construir expresiones XPath ........................................................................... 78
Figura 51. Ventana para configurar las notas informativas ................................................................... 79
Figura 52. Ventana para desplegar las condiciones booleanas definidas en el proceso BPEL ............... 79
Figura 53. Diagrama de actividad CSW-CP01 .................................................................................... 118
Figura 54. Estructura de código BPEL esperado CSW-CP01 ............................................................. 119
Figura 55. Diagrama de actividad CSW-CP02 .................................................................................... 120
Figura 56. Estructura de código BPEL esperado CSW-CP02 ............................................................. 121
Figura 57. Diagrama de actividad CSW-CP03 .................................................................................... 122
vii
Figura 58. Estructura de código BPEL esperado CSW-CP03 ............................................................. 122
Figura 59. Diagrama de actividad CSW-CP04 .................................................................................... 123
Figura 60. Estructura de código BPEL esperado CSW-CP04 ............................................................. 124
Figura 61. Diagrama de actividad CSW-CP05 .................................................................................... 125
Figura 62. Estructura de código BPEL esperado CSW-CP05 ............................................................. 126
Figura 63. Diagrama de actividad CSW-CP06 .................................................................................... 127
Figura 64. Estructura de código BPEL esperado CSW-CP06 ............................................................. 128
Figura 65. Diagrama de actividad CSW-CP07 .................................................................................... 129
Figura 66. Estructura de código BPEL esperado CSW-CP07 ............................................................. 130
Figura 67. Diagrama de actividad CSW-CP08 .................................................................................... 131
Figura 68. Estructura de código BPEL esperado CSW-CP08 ............................................................. 132
Figura 69. Diagrama de actividad CSW-CP09 .................................................................................... 133
Figura 70. Estructura de código BPEL esperado CSW-CP09 ............................................................. 134
Figura 71. Diagrama de actividad CSW-CP10 .................................................................................... 135
Figura 72. Estructura de código BPEL esperado CSW-CP10 ............................................................. 136
Figura 73. Diagrama de actividad CSW-CP11 .................................................................................... 137
Figura 74. Estructura de código BPEL esperado CSW-CP11 ............................................................. 138
Figura 75. Diagrama de actividad CSW-CP12 .................................................................................... 139
Figura 76. Estructura de código BPEL esperado CSW-CP12 ............................................................. 140
Figura 77. Diagrama de actividad CSW-CP13 .................................................................................... 141
Figura 78. Estructura de código BPEL esperado CSW-CP13 ............................................................. 142
Figura 79. Diagrama de actividad CSW-CP14 .................................................................................... 143
Figura 80. Estructura de código BPEL esperado CSW-CP14 ............................................................. 144
Figura 81. Diagrama de actividad CSW-CP15 .................................................................................... 145
Figura 82. Estructura de código BPEL esperado CSW-CP15 ............................................................. 146
Figura 83. Diagrama de actividad CSW-CP16 .................................................................................... 147
Figura 84. Estructura de código BPEL esperado CSW-CP16 ............................................................. 148
Figura 85.Diagrama de actividad CSW-CP17 ..................................................................................... 149
Figura 86. Estructura de código BPEL esperado CSW-CP17 ............................................................. 151
Figura 87.Diagrama de actividad CSW-CP18 ..................................................................................... 152
Figura 88. Estructura de código BPEL esperado CSW-CP18 ............................................................. 156
viii
Índice de tablas
Tabla 1. Patrones básicos ...................................................................................................................... 15
Tabla 2. Tabla comparativa de herramientas de investigación para modelado y composición de
servicios Web ........................................................................................................................................ 17
Tabla 3. Tabla comparativa de trabajos de investigación para perfiles UML ........................................ 18
Tabla 4. Actividades primitivas ............................................................................................................. 25
Tabla 5. Actividades estructuradas ........................................................................................................ 25
Tabla 6. Elementos de un diagrama de actividad .................................................................................. 26
Tabla 7. Atributos de configuración para la actividad Wait .................................................................. 37
Tabla 8. Atributo de configuración para la actividad Empty ................................................................. 37
Tabla 9. Atributo de configuración para la actividad Flow.................................................................... 38
Tabla 10. Documentación de pruebas .................................................................................................... 81
Tabla 11. Servicios Web simples .......................................................................................................... 82
Tabla 12. Resultados obtenidos de las pruebas .................................................................................... 100
Tabla 13. Tabla comparativa del estado anterior y actual del sistema WS-SIDDOO .......................... 104
ix
Definiciones, acrónimos y abreviaturas
API (Application Programming Interface). La Interfaz de Programación de Aplicaciones.
Representa una interfaz de comunicación entre componentes de software. Ofrece un
conjunto de llamadas a ciertas bibliotecas para ser utilizado por otro software como una
capa de abstracción.
BPEL4WS (Business Process Execution Language for Web Services). El Lenguaje de Ejecución de
Procesos de Negocio para Servicios Web define una notación para especificar el
comportamiento de los procesos de negocio basados en servicios Web. También se
conoce como BPEL.
BPM (Business Process Management). Gestión de procesos empresariales es un enfoque de
gestión empresarial que promueve la eficacia y la eficiencia al mismo tiempo para la
innovación, la flexibilidad y la integración con la tecnología.
BPML (Business Process Modeling Language). Es un metalenguaje basado en XML, se usa
para modelar procesos de negocios.
BPMN (Business Process Modeling Notation). Estándar para modelar flujos de procesos de
negocio y servicios Web. Define diagramas de procesos de negocios basados en la
técnica de diagramas de flujo, adaptados para graficar las operaciones de los procesos de
negocio.
CORBA (Common Object Request Broker Architecture). Es un estándar que establece una
plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos
remotos bajo un paradigma orientado a objetos.
C-Wf Es un modelo que se basa en el enfoque orientado a objetos para modelar procesos de
negocio en sistemas de producción utilizando workflows.
DAML (DARPA Agent Markup Language). Es un lenguaje para modelar ontologías, creado con
una extensión de RDF. En las nuevas versiones se conoce como OWL-S.
DCOM (Distributed Component Object Model). Modelo de Objetos de Componentes
Distribuidos, es una tecnología propietaria de Microsoft para desarrollar componentes de
software distribuidos sobre varios ordenadores y que se comunican entre sí.
DSDM (Desarrollo de Software Dirigido por Modelos). Esquema de desarrollo de sistemas de
software, basada en la separación entre la especificación de la funcionalidad esencial del
sistema y la implementación de dicha funcionalidad usando plataformas de
implementación específicas.
EJB (Enterprise Java Beans). Son una de las API que forman parte del estándar de
construcción de aplicaciones empresariales J2EE de Sun Microsystems.
ER (Entity Relationship). Modelo Entidad-Relación es una herramienta para el modelado de
datos de un sistema de información. Estos modelos expresan entidades relevantes para
un sistema de información, sus inter-relaciones y propiedades.
Frameworks (Marco de trabajo). Es una estructura de soporte definida en la cual otro proyecto de
software puede ser organizado y desarrollado.
HTML (HyperText Markup Language). Es un lenguaje de marcado predominante para la
construcción de páginas web.
HTTP (HyperText Transfer Protocol). Es el protocolo usado en cada transacción de la Web
(WWW).
IBM (International Business Machines). Empresa multinacional que fabrica y comercializa
herramientas, programas y servicios relacionados con la informática.
IEEE (Institute of Electrical and Electronics Engineers). Instituto de Ingenieros Eléctricos y
Electrónicos. Asociación técnico-profesional mundial dedicada a la estandarización.
IT (Information Technology). Tecnología de Información es el estudio, diseño, desarrollo,
implementación, soporte o dirección de los sistemas de información computarizados, en
particular de software de aplicación y hardware.
x
IU (Interface User). Interfaz de usuario. Es el medio con que el usuario puede comunicarse
con una máquina, un equipo o una computadora, y comprende todos los puntos de
contacto entre el usuario y el equipo.
JDOM Es un API para leer, crear y manipular documentos XML de una manera sencilla y muy
intuitiva para cualquier programador en Java.
LMED (Lenguaje de Modelado Específico de Dominio). Es un lenguaje de modelado que
provee la precisión semántica necesaria para describir sin ambigüedad los modelos
conceptuales que participan en los procesos de desarrollo de software.
Middleware Es un software de conectividad que ofrece un conjunto de servicios que hacen posible el
funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas.
MIME (Multipurpose Internet Mail Extensions). Extensiones de Correo de Internet
Multipropósito. Son una serie de convenciones o especificaciones dirigidas a que se
puedan intercambiar a través de Internet todo tipo de archivos (texto, audio, vídeo) de
forma transparente para el usuario.
OASIS (Organization for the Advancement of Structured Information Standards). Es una
organización que aprueba estándares para la interoperabilidad de los datos.
OO-Method Es una metodología de desarrollo de software basada en una clara separación del
Espacio del Problema (el 'qué') del Espacio de la Solución (el 'cómo').
OMG (Object Management Group). El Grupo de Gestión de Objetos es un consorcio dedicado
al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a
objetos, tales como UML, XMI, CORBA.
P2P (Peer-to-Peer). Punto a punto se refiere a una red que no tiene clientes ni servidores
fijos, sino una serie de nodos que se comportan simultáneamente como clientes y como
servidores respecto de los demás nodos de la red.
PSE (Problem Solving Environment). Ambiente para Solución de Problemas, es un completo
e integrado entorno de computación para la composición, la compilación y la ejecución
de aplicaciones en un dominio específico.
RDF (Resource Description Framework). Marco de Descripción de Recursos es un
framework para metadatos en la World Wide Web (WWW), desarrollada por el World
Wide Web Consortium (W3C).
SDL (Specification and Description Language). Es un lenguaje de especificación formal y
visual normado por la ITU-T en el estándar Z.100. Está diseñado para la especificación
de sistemas complejos, interactivos, orientados a eventos, de tiempo real o que presenten
un comportamiento paralelo, y donde módulos o entidades independientes se
comuniquen por medio de señales para efectuar su función.
SGML (Standard Generalized Markup Language). Es un lenguaje de marcado generalizado
que consiste en un sistema para la organización y etiquetado de documentos.
SOA (Service Oriented Architecture). Es un estilo de arquitectura de software que promueve
el desacoplamiento entre componentes de forma que se puedan reutilizar.
SOAP (Simple Object Acces Protocol). Es el protocolo que se emplea para el intercambio de
datos entre aplicaciones.
Stubs Objeto que forma parte del cliente (entidad que usa el servicio), se encarga de establecer
la conexión con los servicios Web.
UDDI (Universal Description Discovery and Integration). Permite el registro y la búsqueda de
servicios Web para su utilización.
UML (Unified Modeling Language). El Lenguaje Unificado de Modelado es un lenguaje
gráfico para visualizar, especificar, construir y documentar un sistema de software.
UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo
aspectos conceptuales como procesos de negocios y funciones del sistema, entre otros.
URL (Uniform Resource Locator). El Localizador Uniforme de Recurso. Es una secuencia de
caracteres, de acuerdo a un formato estándar, que se usa para nombrar recursos, como
documentos e imágenes en Internet, por su localización
xi
WAD (Workflow Activity Diagram). Es una extensión del diagrama de actividad UML, aplica
los conceptos del modelo C- Wf. Utiliza el mecanismo de extensión de estereotipo
(stereotype) y define nuevas propiedades para este diagrama. Describe el modelo
workflow que identifica sus actividades y recursos necesarios para su ejecución,
definiendo su secuencia y relaciones.
WorkFlow (Flujo de trabajo). Es el estudio de los aspectos operacionales de una actividad de
trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo,
cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace
seguimiento al cumplimiento de las tareas.
WSDL (Web Services Description Language). Se emplea para describir las funciones del
servicio Web, su ubicación y la forma en que debe utilizarse.
WS-SIDDOO Es un Servicio Web que contiene el analizador de diagramas de actividad del Sistema
Visual para el Diseño Detallado de Métodos de Clases (SIDDOO).
W3C (World Wide Web Consortium). Es un consorcio internacional donde las organizaciones,
personal a tiempo completo y el público en general, trabajan conjuntamente para
desarrollar estándares Web.
XML (eXtensible Markup Language). Es un lenguaje de etiquetado extensible, empleado en el
intercambio de información.
XPath Es un lenguaje que se utiliza para localizar información dentro de un documento XML.
Se utiliza para navegar a través de los elementos y atributos del documento.
XSD (XML Schema Definition). Un archivo XSD tiene por finalidad validar que el
documento XML que se está generando sea exactamente igual al indicado en el interior
de este documento.
1
Capítulo I Introducción
En este capítulo se presenta una introducción al tema de tesis; la descripción del problema; el
objetivo; alcances; limitaciones; justificaciones; beneficios; y la estructura en que está
organizado este documento de tesis.
1.1 Introducción
Hoy en día, Internet es la plataforma que muchas organizaciones utilizan para comunicarse
con sus socios e interactuar con sus sistemas, realizar intercambios de información y
transacciones electrónicas. Además, es una forma eficiente y rentable para vender sus
productos y liberar información, también como una plataforma para la prestación de servicios
a empresas y clientes individuales.
En los últimos años se ha visto un crecimiento tecnológico donde se pueden usar los
sistemas abiertos y distribuidos como una disciplina de ingeniería de software. Esta disciplina
permite la transformación del modelo centralizado y rígido hacia un modelo descentralizado,
abierto y distribuido.
Este modelo da inicio a las tecnologías que ayudan a las organizaciones a intercambiar
información, a realizar transacciones y colaborar entre sí. Las tecnologías para la ejecución de
aplicaciones distribuidas son: XML (Extensible Markup Language); SOAP (Simple Object
Acces Protocol); WSDL (Web Services Description Language); UDDI (Universal Description
Discovery and Integration); HTTP (HyperText Transfer Protocol); y los servicios Web, entre
otras.
Un servicio Web (Web service) es una colección de protocolos y estándares que sirven
para intercambiar datos entre aplicaciones. Un servicio Web complejo es un servicio
implementado como combinación de múltiples servicios Web [SER02].
Capítulo I. Introducción
2
Los estándares básicos de los servicios Web son: SOAP (Simple Object Acces
Protocol), WSDL (Web Services Description Language) y UDDI (Universal Description
Discovery and Integration), éstos no son suficientes para determinados dominios que
requieren una infraestructura de middleware1 más compleja para facilitar el desarrollo de
servicios Web.
BPEL4WS [SPE03] (Business Process Execution Language for Web Services)
proporciona una infraestructura de middleware potente para facilitar la ejecución de procesos
de negocio. Permite definir procesos complejos implementados como composiciones de
servicios Web, y ejecutarlos automáticamente.
Para facilitar la ejecución de procesos de negocio, surge el concepto de orquestación de
servicios Web. La orquestación permite modelar la lógica de negocio que involucra a más de
un servicio, esta orquestación de servicios Web está basada en reglas para los procesos de
negocios que son ejecutadas por un motor de ejecución. Actualmente los lenguajes más
comunes para orquestación son: BPEL4WS y BPML (Business Process Modeling Language).
Estos procesos de negocio son modelados a través de costosas herramientas de diseño
que aseguran al cliente un correcto resultado, sin embargo este resultado final dependerá de las
precondiciones que sean configuradas durante el modelado del proceso.
Actualmente, en el CENIDET (Centro Nacional de Investigación y Desarrollo
Tecnológico) se cuenta con un sistema de diseño detallado orientado a objeto como servicio
Web (WS-SIDDOO) desarrollado en ambiente java que lleva a cabo el proceso de
composición de servicios Web. Este sistema genera código BPEL ejecutable a partir de un
diagrama de actividad UML. Este diagrama representa la interacción entre las operaciones de
los servicios Web involucrados en el proceso de composición. El código BPEL generado es
puesto en marcha sobre un motor de ejecución para obtener un resultado final. Este resultado
dependerá de las especificaciones que el diseñador modele en el diagrama de actividad.
En esta tesis se analiza el proceso de composición que lleva a cabo el sistema WS-
SIDDOO, ya que en su estado anterior para el proceso de composición involucraba sólo a los
elementos UML básicos, tales como: inicio, fin, actividad, transición y decisión, esto limitaba
al sistema para modelar composiciones que involucraran todos los elementos UML integrados
en la interfaz del sistema, tales como: fork, join, mensajes de flujo, expresiones de resguardo y
note. En esta tesis el sistema se extendió para lograr modelar composiciones que requieran
utilizar todos los elementos del diagrama de actividad UML que están integrados en la interfaz
actual de WS-SIDDOO.
1.2 Descripción del problema
Actualmente, muchas de las aplicaciones que se desarrollan son basadas en tecnología Web,
un servicio Web está construido como una unidad independiente, por lo cual en ocasiones no
satisface la necesidad de los clientes sino que se requiere la interacción entre varios servicios
Web para satisfacer esa necesidad.
El sistema WS-SIDDOO en su estado anterior realizaba el proceso de composición de
servicios apoyado en la transformación de algunos elementos UML (inicio, actividad,
1 Middleware es un software de conectividad que ofrece un conjunto de servicios que hacen posible el funcionamiento de
aplicaciones distribuidas sobre plataformas heterogéneas.
Capítulo I. Introducción
3
transición, decisión y fin) del diagrama de actividad a código semánticamente equivalente en
lenguaje BPEL4WS, el problema radicaba en que el sistema se encontraba limitado al uso de
algunos elementos UML (fork, join, mensajes de flujo, expresiones de resguardo y note) para
el proceso de composición, lo cual no permitía al diseñador modelar procesos con estructuras
de concurrencia y sincronización, modelar las condiciones asociadas a las estructuras
condicionales, modelar composiciones con notas informativas, modelar estructuras con
actividades en tiempo de espera o nulas. Con base a esto se propuso la generación automática
de bloques de código en BPEL4WS de los elementos UML faltantes y así modelar las
estructuras anteriormente descritas.
1.3 Objetivo
El objetivo de este trabajo de tesis es generar de manera automática código en BPEL4WS, que
tenga como entrada un diagrama de actividad y que tenga como salida código en BPEL4WS
semánticamente equivalente al diagrama. En particular, se incorporan los elementos: fork,
join, mensajes de flujo, expresiones de resguardo y note, del diagrama de actividad integrados
en la interfaz del sistema WS-SIDDOO.
1.4 Justificación
El WS-SIDDOO es un sistema que permite modelar la composición de servicios Web
generando código en BPEL a partir de diagramas de actividades. Dada la complejidad de
implementar diagramas de actividades a código en BPEL4WS, se planeó desarrollarlo en
diferentes etapas. La primera etapa genera código en BPEL a partir de algunos elementos
UML básicos, tales como: inicio, fin, actividad, decisión y transición. Para lograr modelar
composiciones de servicios involucrando todos los elementos del diagrama de actividad
integrados en la interfaz del sistema, es necesario transformar los elementos del diagrama de
actividad faltantes: fork, join, mensajes de flujo, expresiones de resguardo y note, a código
semánticamente equivalente en BPEL4WS.
1.5 Beneficios
Este trabajo de tesis proporciona un ambiente de modelado para la composición de servicios
Web y la generación de código BPEL a partir de los elementos: inicio, fin, actividad, decisión,
transición, fork, join, mensajes de flujo, expresiones de resguardo y note del diagrama de
actividad integrados en la interfaz del sistema WS-SIDDOO que representan la interacción
entre las operaciones de los servicios Web involucrados.
Los desarrolladores podrán modelar composiciones utilizando todos los elementos UML
integrados en la interfaz del sistema sin limitar el uso de alguno de ellos, permitiendo modelar
composiciones que representen estructuras de concurrencia y sincronización, modelar las
condiciones asociadas a las estructuras condicionales, modelar estructuras con actividades en
espera de tiempo o nulas y modelar estructuras con notas informativas. Al incluir todos los
elementos en el proceso de composición se incrementó la expresividad de los diagramas de actividad.
Capítulo I. Introducción
4
1.6 Alcances
Los alcances obtenidos en el desarrollo de la extensión al sistema WS-SIDDOO para el
proceso de composición de servicios, se listan a continuación:
El módulo de composición genera de forma automática código semánticamente
equivalente en BPEL4WS para los elementos: fork, join, note, mensajes de flujo y
expresiones de resguardo, que se encuentran presentes en la interfaz del sistema para
el proceso de composición de servicios.
El módulo de composición genera código BPEL4WS a partir de estructuras de
concurrencia y sincronización simple, compleja y de combinación definida.
El módulo de composición genera código BPEL4WS de actividades en espera de
tiempo.
El módulo de composición genera código BPEL4WS de actividades nulas, útiles para
las llamadas en paralelo de los servicios Web involucrados en el proceso.
El módulo de composición genera código BPEL4WS de las condiciones asociadas a
las estructuras condicionales.
El cliente WS-SIDDOO presenta al usuario una serie de ventanas que permiten
configurar las actividades primitivas BPEL: wait, empty.
El cliente WS-SIDDOO presenta al usuario la opción de asignar variables a través de
la configuración de expresiones XPath.
El cliente WS-SIDDOO presenta una interfaz que facilita el modelado de diagramas de
actividad y evita la pérdida de tiempo.
1.7 Limitaciones
A continuación se describen las limitaciones que presenta este trabajo.
La integración de nuevos elementos UML en la interfaz del sistema WS-SIDDOO no
se consideró en este trabajo de tesis.
La anidación de actividades no se consideró en este trabajo de tesis.
La modificación de la implementación de la versión anterior del WS-SIDDOO no está
contemplada en este trabajo de tesis, por lo que el cliente WS-SIDDOO genera código
BPEL de las condiciones asociadas a las estructuras condicionales, sin embargo en
algunos casos las condiciones se repiten de acuerdo a la implementación anterior,
dando lugar a que las condiciones sean agregadas manualmente a través de una
ventana externa donde se desplegarán todas las condiciones generadas durante el
modelado del proceso.
La modificación de la gramática del sistema WS-SIDDOO no está contemplada en este
trabajo de tesis, por lo que las estructuras de concurrencia y sincronización quedan
limitadas a máximo tres flujos.
El manejo de errores y compensación en tiempo de ejecución no están contemplados
en este trabajo de tesis, por lo que en las estructuras de concurrencia y sincronización
no se consideró.
Capítulo I. Introducción
5
1.8 Organización de la tesis
La estructura restante de este documento se compone de seis capítulos los cuales se describen
a continuación.
Capítulo II
En este capítulo se presentan los trabajos que anteceden esta investigación como parte de la
evolución del sistema; el estado del arte; los trabajos relacionados; y el análisis comparativo
con algunos trabajos de investigación y herramientas de modelado.
Capítulo III
En este capítulo se presentan los conceptos básicos sobre las tecnologías involucradas que
permitieron identificar el diseño y desarrollo de las correspondencias semánticas entre los
elementos UML y las actividades en BPEL4WS implementadas.
Capítulo IV
En este capítulo se describe el análisis realizado a la herramienta de diseño WS-SIDDOO y los
módulos que lo integran; el lenguaje de composición BPEL4WS y los diagramas de actividad
en el cliente WS-SIDDOO. Así mismo, se presenta la propuesta de solución y las
correspondencias entre los elementos y las actividades BPEL; los atributos de las actividades
(primitivas y estructuradas) implementadas en este trabajo de tesis; y los escenarios válidos
para la generación de código de las nuevas estructuras: concurrencia y sincronización simple;
concurrencia y sincronización compleja; y de combinación definida (con agregación de notas
informativas).
Capítulo V
En este capítulo se presenta el diseño de las correspondencias semánticas implementadas en el
módulo de composición, el cual consiste en diagramas de casos de uso; diagramas de clases y
diagramas de secuencia. También se presenta el diseño de las ventanas de configuración para
las actividades BPEL implementadas.
Capítulo VI
En este capítulo se presenta el plan de pruebas para evaluar la funcionalidad correcta de la
extensión a los módulos composición y ventanas que implementan las correspondencias
semánticas diseñadas en el capitulo V.
Capítulo VII
En este capítulo se detallan las conclusiones alcanzadas; las aportaciones que se obtuvieron
durante esta investigación; y algunos puntos que pueden ser considerados para futuros
proyectos.
Finalmente se describen los anexos y las referencias bibliográficas.
6
Capítulo II Antecedentes
En este capítulo se describen los antecedentes que dan soporte a este trabajo de tesis como
parte de la evolución del sistema WS-SIDDOO; así como el estado del arte; los trabajos
relacionados y el análisis comparativo.
2.1 Antecedentes
Los antecedentes de esta tesis son cinco trabajos de investigación desarrollados en el área de
ingeniería de software del CENIDET.
Figura 1. Esquema de relación de los trabajos antecedentes de investigación
Capítulo II. Antecedentes
7
En la figura 1, se ilustra la relación que existe entre cada trabajo de investigación antecedente.
A continuación se enlistan de acuerdo al orden en que fueron desarrollados.
1. “Sistema visual para el diseño detallado de métodos de clases con UML” [ROM03]
2. “Generación de servicios Web a partir de software legado” [VAS04]
3. “Composición de servicios Web” [GUZ06]
4. “Sistema de búsqueda y selección de servicios Web” [SOL06]
5. “Sistema de composición de servicios Web utilizando diagramas de actividad”
[GYV07]
Este último trabajo que se encuentra enmarcado con líneas punteadas en la figura 1, fue origen
para el desarrollo de esta tesis. En los apartados siguientes se describen cada uno de ellos.
2.1.1 Sistema visual para el diseño detallado de métodos de clases con UML [ROM03]
El objetivo de este trabajo de tesis fue diseñar y construir una herramienta de software, que
utilice técnicas de programación visual y permita modelar el diseño detallado de los métodos
de las clases de un sistema orientado a objetos, utilizando los diagramas de actividad
propuestos por UML, a la herramienta producto de esta tesis se le conoce como SIDDOO y se
presenta en la figura 2.
Figura 2. Sistema SIDDOO
2.1.2 Generación de servicios Web a partir de software legado [VAS04]
El objetivo de este trabajo de tesis fue generar una metodología para la implementación de
servicios Web a partir de software legado de tipo centralizado, cuyo enfoque principal es
facilitar el proceso de desarrollo de software, como caso de prueba se utilizó la herramienta
SIDDOO descrita anteriormente, al producto de esta tesis se le conoce como WS-SIDDOO y se presenta en la figura 3.
Capítulo II. Antecedentes
8
Figura 3. Sistema SIDDOO visto como servicio Web
2.1.3 Composición de servicios Web [GUZ06]
El objetivo de este trabajo de tesis fue desarrollar un proceso para habilitar al desarrollador de
software a crear aplicaciones informáticas reduciendo los costos de producción, aumentando la
calidad de los productos y reduciendo también su complejidad, mediante la composición de
servicios Web, que proporcionen la funcionalidad que se requiere, a la herramienta producto
de esta herramienta se le conoce como WS-Compositor y se presenta en la figura 4.
Figura 4. Modelo conceptual de la herramienta WS- Compositor
2.1.4 Sistema de búsqueda y selección de servicios Web [SOL06]
El objetivo de este trabajo de tesis fue diseñar, implementar y evaluar un modelo de búsqueda
y selección de servicios Web que extiende la funcionalidad de los registros actuales a través de
una biblioteca basada en casos y un módulo razonador que manipula dicha biblioteca,
Capítulo II. Antecedentes
9
proporcionando un mecanismo para la clasificación y selección de servicios en base a su
funcionalidad, permitiendo realizar la búsqueda de las descripciones de los servicios
seleccionados de forma no secuencial dentro de los mismos registros, al producto de esta tesis
se le conoce como SBSSW “Sistema de búsqueda y selección de servicios Web” y se presenta
en la figura 5.
Figura 5.Modelo conceptual del sistema de búsqueda y selección de servicios Web (SBSSW)
2.1.5 Composición de servicios Web utilizando diagramas de actividad [GYV07]
El objetivo de este trabajo de tesis fue evitar que el desarrollador de aplicaciones escribiera el
código de interacción entre las operaciones de los servicios Web involucrados en un proceso
de composición, mediante la generación automática de código de composición, a partir de
diagramas de actividad de UML modelados en el cliente del WS-SIDDOO y se presenta en la
figura 6.
Figura 6.Sistema de composición de servicios Web WS-SIDDOO
Capítulo II. Antecedentes
10
2.2 Estado del arte
Los grandes sistemas de información están basados en el modelo cliente/servidor con
arquitecturas multicapa que se comunican a través de los modelos distribuidos como:
CORBA(Common Object Request Broker Architecture); EJB(Enterprise Java Beans) y/o
DCOM (Distributed Component Object Model); haciendo uso de normas y nuevas tecnologías
como XML para la representación intermedia de información entre componentes de software,
o SOAP para la localización y activación automática de servicios Web, entre otras nuevas
tecnologías.
Los servicios Web son aplicaciones auto-contenidas, modulares, accesibles a través de
la Web, abiertos a lenguajes estándares y proporcionan un conjunto de funcionalidades para
las empresas o individuos [SAM05].
La tendencia en los procesos de ingeniería de software para el desarrollo de sistemas de
información distribuidos, es la creación de sistemas de información cooperativos y
colaborativos, compuestos por subsistemas, componentes y objetos especializados y
coordinados para ofrecer servicios.
Actualmente el desarrollo de aplicaciones complejas no se escribe en código
monolítico, sino que se componen de un conjunto de servicios Web que pueden conjuntamente
solucionar un problema. Los frameworks de composición exigen a los usuarios generar
especificaciones de flujos que son enviados a un motor de ejecución. Los detalles de la
especificación del flujo de los servicios y el orden de los mensajes que tienen que ser
intercambiados entre estos servicios se componen.
Hay muchos lenguajes para la composición de servicios Web, los más conocidos son:
BPEL4WS (Business Process Execution Language for Web Services) y BPML (Business
Process Modeling Language). Estos proporcionan un cierto nivel de automatización en el
proceso de ejecución. Sin embargo, el uso de estos frameworks requiere que el usuario realice
programación de bajo nivel [MAJ04].
2.3 Trabajos relacionados
Un proceso de negocio se define como un conjunto estructurado de tareas, que contribuyen
colectivamente a lograr los objetivos de una organización [ALV05]. Los procesos de negocios
son la base operativa de una empresa y el éxito de la misma depende fuertemente de la
eficiencia con que sean administrados. Una mala administración trae altos costos, baja
productividad e inadecuados tiempos de respuesta. Por lo que el modelado de procesos está
siendo objeto de estudio. Como respuesta al problema del modelado de procesos de negocio
dentro de una organización, en la década de los 90 surge la tecnología de workflow. Esta
tecnología permite representar total o parcialmente los procesos de negocio en formato
entendible por una máquina [ALV05].
Los servicios Web pueden ser simples o compuestos. Los servicios simples no se basan
en otro servicio Web, actúan de manera atómica. Un servicio compuesto es similar a un flujo
de trabajo (workflow). Incluye un conjunto de servicios simples (atómicos) junto con el control y el flujo de datos entre los servicios.
Capítulo II. Antecedentes
11
Un servicio compuesto automático o semi–automático no es fácil de construir, se
requiere de una cantidad considerable de programación y esfuerzo para componer servicios.
Estas limitaciones han provocado un gran esfuerzo en investigación y desarrollo enfocado en
el área de composición de servicios Web. Estas investigaciones han logrado la colaboración
entre las organizaciones proponiendo herramientas de composición y modelado de procesos de
negocio algunos basados en flujos de trabajo (workflow) y otros proponiendo métodos de
modelado basados en restricciones de precondiciones y post condiciones. Para propósito de
esta tesis los trabajos relacionados se clasifican en dos tipos:
Herramientas de modelado para la composición de servicios
Manejo por modelo UML 2.0 & Perfiles UML
2.3.1 Herramientas de modelado para la composición de servicios Web
Las composiciones de servicios Web se usan para realizar aplicaciones basadas en servicios.
Estos servicios están construidos a partir de muchas aplicaciones existentes, a menudo
expuestas como servicios Web que se pueden utilizar por medio de interfaces predefinidas
[BAR06]. La composición de servicios implica encontrar un mecanismo que permita a dos o
más de ellos cooperar entre sí para resolver requerimientos que van más allá del alcance de sus
capacidades individuales. A continuación se analizan las características y carencias de algunas
herramientas, métodos y modelos de investigación para la composición de servicios Web.
Algunas permiten hoy en día que diferentes organizaciones tengan una óptima canalización de
esfuerzos y recursos hacia las ventajas en costo, calidad, servicio y experiencia.
ZenFlow: A Visual Web Service Composition Tool for BPEL4WS [MAR05]
Zenflow es una herramienta visual para la composición de servicios Web que genera código
en BPEL4WS, es un sistema completo que da las facilidades visuales para que el diseñador
navegue y edite procesos de negocio, soportando operaciones de edición visuales como cortar
y pegar elementos del diagrama, comprobando la sintaxis para evitar los errores sintácticos.
Esta herramienta soporta dos estilos de composición de servicios Web: de abajo hacia
arriba (bottom -up) y de arriba hacia abajo (top-down). El estilo de composición de abajo hacia
arriba, el diseñador construye el proceso paso a paso añadiendo las invocaciones a los
servicios Web hasta completar todo el proceso. Por otro lado el estilo de arriba hacia abajo, el
diseñador parte de un solo proceso representando la coreografía de los servicios Web externos.
iGrafx ® BPEL A Standard for the Agile Enterprise [IGR07]
La interfaz iGrafx BPEL es una extensión del modelo de procesos para clientes iGrafx y está
diseñado para los departamentos de IT (Information Technology). Su objetivo es desplegar
procesos de negocio en un entorno de ejecución.
ThUsing iGrafx es un cliente modelador de procesos de negocio; los analistas crean
diagramas de procesos utilizando modelos de aplicación de métodos, tales como swimlane y
diagramas de notación de procesos de negocios BPMN (Business Process Modeling Notation).
Una vez que estos modelos se crean, la interfaz iGrafx BPEL genera código ejecutable, que
llevan a ejecución los motores BPM (Business Process Management).
Capítulo II. Antecedentes
12
TIBCO iProcess Suite [TIB06]
TIBCO iProcess Suite es un conjunto de módulos de aplicación construida sobre una
arquitectura abierta que se ha diseñado para proporcionar una solución completa de procesos
de negocios. Está diseñado para permitir a las organizaciones crear una infraestructura de IT
(Information Technology) que se basa en los procesos de negocio. Al separar la aplicación
lógica de la capa de proceso, las organizaciones pueden lograr la flexibilidad y escalabilidad
con facilidad.
TIBCO utiliza la combinación de los enfoques de abajo hacia arriba (bottom-up) que
integra las aplicaciones en el contexto del proceso de negocio y el enfoque de arriba hacia
abajo (top-down) utilizado por BPM (Business Process Management) que comienza con la
definición y análisis de los procesos de negocio y la integración de las aplicaciones y personas
involucradas en ese proceso.
Adaptive and Dynamic Service Composition in eFlow [CAS00a]
eFlow es un sistema desarrollado en Java por Hewlett Packard que permite la definición de
servicios compuestos a partir de servicios simples. Soporta la especificación, publicación y
manejo de servicios compuestos y la especificación de procesos adaptativos y dinámicos que
pueden configurarse a sí mismos en tiempo de ejecución de acuerdo a las necesidades de cada
cliente y al tipo de servicios disponibles en Internet.
La composición de servicios es modelada por un grafo, definiendo el flujo de servicios
de forma similar a un diagrama UML (Unified Modeling Language). Provee plantillas de
proceso, nodos de servicio y repositorio de datos de servicio para rehusar y controlar la
adaptabilidad.
eFlow proporciona características que soportan el manejo y especificación de procesos
de servicios, incluyendo un lenguaje simple para la composición de servicios, manejo de
excepciones y eventos, transacciones a nivel de servicio, manejo de seguridad y herramientas
de monitoreo.
SELF-SERV: A Platform for Rapid Composition of Web Services in a Peer-to-Peer
Environment
SELF-SERV es una herramienta e infraestructura de software para el modelado de alto nivel
que soporta herramientas para buscar, componer, ejecutar, monitorear y evolucionar los
servicios Web. Proporciona un marco en el cual los servicios son compuestos con lenguajes
declarativos y el servicio resultante compuesto se ejecuta de manera centralizada o en un
entorno punto a punto P2P, dentro de un ambiente dinámico [BEN02].
SELF-SERV se desarrolló para una rápida composición de servicios Web. La
ejecución de un servicio compuesto es coordinada por varios pares de componentes de
software llamados coordinadores. Los coordinadores son adjuntos a cada estado de un servicio
compuesto. Son los encargados de iniciar, controlar y monitorear el estado relacionado, y
colaborar con sus compañeros a gestionar la ejecución del servicio [SHE02].
Capítulo II. Antecedentes
13
Argos: An Ontology and Web Service Composition Infrastructure for Goods Movement
Analysis [AMB03]
El objetivo del proyecto Argos es desarrollar técnicas para crear automáticamente flujos de
trabajo (workflow) computacional en respuesta a las solicitudes de los datos de usuario. Argos
representa el acceso de datos y las operaciones de procesamiento de datos como servicios
Web. Propone integrar datos a partir de fuentes secundarias para estimar el flujo de productos
básicos. Argos presenta un diseño inicial para la composición automática de servicios Web,
del análisis del movimiento de productos. Consiste en tres pasos:
1. Define una ontología del dominio para modelar datos procesados a través de un flujo
de trabajo (workflow).
2. Describe fuentes de datos y operaciones usando esta ontología.
3. Compone un flujo de trabajo (workflow) automáticamente en respuesta a la solicitud
del usuario basada sobre técnicas mediador.
Triana as a Graphical Web Services Composition Toolkit [MAJ04]
Triana es un sistema para la composición de servicios Web de código abierto, distribuido,
independiente de la plataforma de Ambiente para Solución de Problemas (PSE) escrito en el
lenguaje de programación Java. Un PSE es un completo, ambiente de computación integrado
para la composición, compilación y ejecución de aplicaciones en un dominio específico.
Triana fue desarrollado originalmente para el proyecto GEO600 gravitacional. PSE Triana es
un entorno interactivo gráfico que permite a los usuarios componer aplicaciones y especificar
su comportamiento distribuido.
La manera para crear un flujo de trabajo (workflow), es cuando el usuario arrastra los
elementos deseados de la caja de herramientas hacia el área de trabajo e interconecta éstos al
arrastrar una conexión entre ellos. Triana permite al usuario descubrir, componer, invocar,
publicar servicios atómicos y compuestos de una manera transparente y ejecutar un servicio
compuesto por una red P2P o middleware.
Triana permite al usuario utilizar los servicios de dos maneras: una consulta UDDI o
importar un documento WSDL. El usuario debe especificar la dirección de una empresa
pública o privada al publicar en un registro UDDI. También permite al usuario importar un
servicio Web directamente al especificar la ubicación WSDL. El documento WSDL es
analizado por una herramienta de Triana que representa el servicio. Esta herramienta es un
proxy para el servicio Web.
SWORD: A Developer Toolkit for Web Service Composition [PON02]
SWORD es un conjunto de herramientas que permiten la composición de un subconjunto de
servicios Web, como por ejemplo: la composición de los servicios que proporcionan
información, correo electrónico y los servicios de conversión de imagen.
Capítulo II. Antecedentes
14
La implementación de un prototipo demuestra que SWORD puede trabajar con
servicios Web sin que su desarrollo se base en estándares tales como WSDL, SOAP, RDF y
DAML. Las entradas y salidas de los servicios son especificadas utilizando el modelo Entidad-
Relación (ER). En SWORD un servicio es representado mediante la regla que expresa ciertas
entradas (precondiciones) y el servicio es capaz de producir salidas (post condiciones)
particulares y un sistema experto basado en reglas determinará automáticamente si el servicio
compuesto deseado puede ser generado usando servicios existentes.
Para crear un servicio compuesto, el desarrollador necesita especificar los estados de
inicio y fin del servicio compuesto, dada las reglas para los servicios base disponible en sus
modelos del servicio; SWORD utiliza un algoritmo para determinar si existe un plan para el
servicio compuesto. Se enfoca en comunidades de planeación por Inteligencia Artificial (IA).
La generación del plan se basa en reglas, mecanismo que utiliza SWORD para generar sus
planes.
2.3.2 Enfoque: manejo por modelo UML 2.0 & Perfiles UML
El enfoque del “manejo por modelos UML 2.0” para la composición de servicios Web facilita
la administración y desarrollo de composiciones dinámicas de servicios. UML (Unified
Modelling Language) se usa para proveer un alto nivel de abstracciones y permite el mapeo
directo con estándares como BPEL4WS (Business Process Execution Language for Web
Services).
La especificación de UML 2.0 [UML04] definida por OMG (Object Management
Group) [OMG07], incorpora una serie de características para mejorar las posibilidades de
extensión de este lenguaje mediante el uso de perfiles UML (UML Profiles). Las nuevas
características de los perfiles UML permiten definir la precisión semántica requerida por la
mayoría de las propuestas DSDM (Desarrollo de Software Dirigido por Modelos) existentes,
provocando que en los últimos años la cantidad de perfiles UML se incremente
considerablemente [GIA08].
Sin embargo, a pesar del uso masivo que se hace de los perfiles UML, aún no existe un
proceso estandarizado que indique cómo elaborar correctamente un perfil UML que integre
(en UML) la semántica requerida por una propuesta DSDM (Desarrollo de Software Dirigido
por Modelos).
Los perfiles UML permiten extender la sintaxis y la semántica UML para modelar
elementos de dominios particulares. Así como los perfiles UML extienden su vocabulario y
los patrones de diseño definen para los diseñadores un vocabulario común; también es posible
usar perfiles para definir un vocabulario de patrones en UML. De esta manera, los perfiles
pueden ser usados no solamente para dominios específicos, sino también para resolver
problemas particulares en diferentes dominios.
A continuación se analizan diferentes trabajos de investigación relacionados con los
perfiles UML y sus mecanismos de extensión, entre otras características relevantes.
Capítulo II. Antecedentes
15
Towards Modeling Web Service Composition in UML
Este trabajo propone una extensión a UML, para modelar y construir servicios Web
compuestos a partir de servicios ya existentes. Los servicios Web son componentes
funcionales, disponibles sobre el Internet, lo cual cumplen con un conjunto de estándares tales
como: HTTP, XML, SOAP, WSDL, entre otros.
Existen dos aspectos de modelado principales: el modelado del servicio y del flujo de
trabajo (workflow). Este trabajo se basa sobre el modelado del flujo de trabajo (workflow) que
identifica el control de flujo y de datos de un servicio a otro [GRO04].
En este trabajo se propone las extensiones UML con dos mecanismos: estereotipos
(stereotypes) y valores etiquetados (tagged values) cuando no se satisfaga una solución con la
construcción básica de una actividad UML. Se define un perfil UML para diagramas de
actividad UML para modelar servicios Web compuestos.
Aalst [AAL03] reúne el resultado de la investigación de workflow e identifica un
conjunto de 20 patrones relacionados con el aspecto de control de flujo. Un patrón se define
por Wohed en [PET03] como una forma de abstracción para encontrar situaciones recurrentes
en las diversas etapas de desarrollo de software.
Los cinco patrones básicos de control son apoyados por todos los lenguajes de
modelado. En la tabla 1, se identifica cómo UML 2.0 apoya estos patrones básicos.
Tabla 1. Patrones básicos
Nombre del patrón Descripción UML
Sequence Ejecuta actividades en secuencia Control – Flow
Parallel split Ejecuta actividades en paralelo Fork
Synchronization Sincroniza dos hilos paralelos de ejecución Join
Exclusive choice Elige un camino de ejecución de muchas alternativas. Decision - Node
Simple merge Une dos caminos alternativos de ejecución Merge
Extending the UML 2 Activity Diagram with Business Process Goals and Performance
Measures and the Mapping to BPEL [KOR02]
El diagrama de actividad de UML 2.0 está diseñado para modelar procesos de negocio que
describan el control de flujos en software, pero no incluye los conceptos para modelar metas
de procesos y las medidas de desempeño.
Se extiende el diagrama de actividad para modelar metas de procesos y medir su
desempeño para que sean visibles conceptualmente. Proporciona un mapeo en BPEL4WS para
crear medidas disponibles para la ejecución y supervisión.
Los perfiles UML son un mecanismo de extensión para la construcción de modelos
UML para particulares dominios o propósitos. Para extender el diagrama de actividad
orientado a las metas del proceso de negocio y el desempeño de las medidas. El perfil UML
2.0 y el mapeo en BPEL4WS permiten la transformación de los modelos de proceso de
negocio desarrollados en una herramienta de modelado UML en BPEL4WS.
Capítulo II. Antecedentes
16
Los modelos de procesos de negocio así como las extensiones basadas en los perfiles
UML pueden ser creados, presentados y editados fácilmente con herramientas de modelado
UML. Se puede extender el perfil de un metamodelo u otro perfil preservando su sintaxis y
semántica de los elementos UML actuales.
Los perfiles UML consisten de estereotipos, restricciones y los valores etiquetados.
Un estereotipo es un elemento del modelo definido por su nombre y por la clase base a
la que se le asigna.
Las restricciones especifican las pre o post-condiciones, invariantes y deben cumplir
con las restricciones de la clase base.
Los valores etiquetados son meta-atributos adicionales, asignados a un estereotipo,
especificados como pares de nombre-valor.
Extending UML Activity Diagram for Workflow Modeling in Production Systems
[BAS02]
Este trabajo presenta un enfoque para describir procesos de negocio en sistemas de
producción, utilizando conceptos workflow. Propone una extensión del diagrama de actividad
UML llamado Workflow Activity Diagram (WAD) que aplica los conceptos del modelo C-
Wf. En esta extensión, se asocian los elementos del diagrama de actividad con las clases del
modelo C-Wf. Utiliza el mecanismo de extensión de estereotipo (stereotype) y se define
nuevas propiedades para este diagrama. El WAD describe el modelo workflow que identifica
sus actividades y recursos necesarios para su ejecución definiendo su secuencia y relaciones.
En los diagramas de actividad se identifican las actividades que deben realizarse para
ejecutar un caso de uso y las relaciones entre ellos. Es posible identificar los objetos
involucrados en la actividad y cómo definir su rol, estado y atributos.
El modelo C-Wf representa los objetos estructurales y funcionales de la empresa
involucrados en el proceso de negocio, tales como: actividades empresariales, recursos
humanos, recursos de la máquina, entre otras.
Perfiles UML y Desarrollo Dirigido por Modelos: Desafíos y Soluciones para Utilizar
UML como Lenguaje de Modelado Específico de Dominio [GIA08]
El objetivo de este trabajo es presentar un proceso genérico para aquellas propuestas DSDM
que deseen extender UML mediante un perfil UML, y de esta manera poder utilizar UML
como LMED. Este proceso genérico está basado en la solución de integración con UML
desarrollada para la propuesta OO-Method, que ha sido aplicada exitosamente al desarrollo
industrial de software por la empresa CARE-Technologies.
Las extensiones de UML se suelen definir mediante un perfil UML que incorpora la
precisión semántica de un LMED, o en otras palabras, UML se convierte en el LMED. La
principal restricción radica en que los perfiles UML no pueden cambiar la semántica original
del metamodelo que extienden. En este trabajo se proponen algunos mecanismos con los que
se pueden inferir las extensiones (estereotipos, valores etiquetados y restricciones) así como
las metaclases que deben ser extendidas. Estas reglas proveen una primera aproximación de
cómo automatizar la generación de perfiles UML.
Capítulo II. Antecedentes
17
2.3.3 Análisis comparativo
La tabla 2, muestra la comparativa de los trabajos de las herramientas de modelado, técnicas y
métodos relacionados al proceso de composición y en la tabla 3, se muestra la comparativa de
los trabajos relacionados con los perfiles UML.
Tabla 2. Tabla comparativa de herramientas de investigación para modelado y composición de servicios Web
MODELADO DE
PROCESOS Y
COMPOSICIÓN
DE SERVICIOS
TRABAJOS
[MAR05] [IGR07] [TIB06] [CAS00a] [SHE02] [AMB03] [MAJ04] [PON02] Tesis
Diagramas para
modelar procesos
de negocio
Diagramas de flujo 2
Diagramas de
actividad
Diagramas de
estado
Exportar
diagramas de
procesos a BPEL
Tecnología
Workflow (Flujo de
trabajo)
3
Basado en procesos
de negocio
Procesos de negocio
basado en BPEL
Basado en
planeación IA
Basado en reglas Composición vista
textual y gráfica
Composición vista
Navegador Web
Modelo actualiza
dinámicamente
Genera WSDL
Genera
documentación
Es una herramienta
Es un demo
(prototipo)
Técnicas
2,3 Los diagramas de actividad se pueden considerar para modelar flujos y workflows
Capítulo II. Antecedentes
18
Tabla 3. Tabla comparativa de trabajos de investigación para perfiles UML
Perfiles UML TRABAJOS
[GRO04] [KOR02] [BAS02] [GIA08] Extiende el diagrama con el
mecanismo de estereotipos
Extiende el diagrama con el
mecanismo de valores etiquetados
Extiende el diagrama con el
mecanismo de restricciones
Apoyado por patrones de diseño
Patrones con álgebra basada en
redes Petri
Extender metaclases del metamodelo
UML
Basado en metas del proceso de
negocio y medidas de desempeño
Basado en Workflow Basado en procesos de negocio
19
Capítulo III Marco Conceptual
En este capítulo se describen los siguientes conceptos: servicios Web; XML (eXtensible
Markup Language); WSDL (Web Services Description Language); SOAP (Simple Object
Acces Protocol); UDDI (Universal Description Discovery and Integration); composición de
servicios; coreografía; orquestación; lenguaje BPEL4WS (Business Process Execution
Language for Web Services) y los diagramas de actividad. Estos conceptos en conjunto forman
parte fundamental en el desarrollo de esta tesis.
3.1 Servicios Web
Un servicio Web es una colección de protocolos y estándares que sirven para intercambiar
datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de
programación diferentes, y ejecutadas sobre distintas plataformas, pueden utilizar los servicios
Web para intercambiar datos en redes de computadoras tales como intranet y/o internet. La
interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones
OASIS (Organization for the Advancement of Structured Information Standards) y W3C
(World Wide Web Consortium) son los comités responsables de la arquitectura y
reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas
implementaciones de servicios Web se ha creado el organismo WS-I, encargado de desarrollar
diversos perfiles para definir de manera más exhaustiva estos estándares [SER02].
Los servicios Web proporcionan un lenguaje estándar (adoptado por la totalidad de los
fabricantes de software) para el intercambio de datos XML (Extensible Markup Language)
que es independiente de la plataforma empleada, y además viaja a través del protocolo HTTP,
por lo que puede emplearse a través de Internet [SER02]. La plataforma funcional de los
servicios Web está basada en tecnologías como:
Capítulo III. Marco Conceptual
20
XML (Extensible Markup Language). Es un lenguaje de etiquetado extensible, que es
empleado en el intercambio de información.
WSDL (Web Services Description Language). Es empleado para describir las
funciones del servicio Web, su ubicación y la forma en que debe utilizarse.
SOAP (Simple Object Acces Protocol). Es el protocolo que se emplea para el
intercambio de datos entre aplicaciones.
UDDI (Universal Description Discovery and Integration). Permite el registro y la
búsqueda de servicios Web para su utilización.
Figura 7. Elementos de la Arquitectura Orientada a Servicios (SOA)
Como se muestra en la figura 7, la arquitectura orientada a servicios está compuesta de tres
entidades: el proveedor del servicio, el registro del servicio (UDDI), y el cliente del servicio.
Donde el proveedor es el encargado de implementar el servicio Web y ofrecerlo a los clientes,
el registro (UDDI) es un repositorio donde se almacenan las descripciones de los servicios,
para que los clientes puedan localizar el servicio Web que mejor se adapte a sus necesidades, y
el cliente es el que recupera la información del registro y utiliza la descripción del servicio
para consumirlo.
De acuerdo a la figura 7, la secuencia de ejecución es la siguiente:
1. El proceso inicia cuando las empresas (proveedores de servicios) deciden desarrollar y
exponer la funcionalidad de sus aplicaciones en forma de servicio Web.
2. Una vez que los servicios Web se han desarrollado, deben ser registrados en un
repositorio UDDI [UDD06], para poder ser localizados por los clientes, en dicho
registro se aportarán datos sobre la empresa, los servicios Web que ofrecen y la descripción de las interfaces de uso de cada servicio Web (WSDL).
Capítulo III. Marco Conceptual
21
3. Los posibles consumidores (clientes), se conectan al servidor UDDI para buscar los
servicios Web que les interesan.
4. Una vez que se encuentra el servicio Web que se desea, se obtiene la descripción de
sus interfaces de uso descritas en el WSDL.
5. De acuerdo a la descripción de las interfaces de uso, los clientes son capaces de
elaborar paquetes SOAP para comunicarse con el proveedor del servicio Web.
6. El proveedor del servicio Web elabora un paquete SOAP como respuesta a la petición
del cliente del servicio.
3.1.1 XML (eXtensible Markup Language)
XML es un Lenguaje de Marcado Extensible desarrollado por el World Wide Web
Consortium (W3C). Es una simplificación y adaptación del SGML (Standard Generalized
Markup Language) y permite definir la gramática de lenguajes específicos (de la misma
manera que HTML (HyperText Markup Language) es a su vez un lenguaje definido por
SGML).
XML se propone como un estándar para el intercambio de información estructurada
entre diferentes plataformas. Es un lenguaje similar a HTML pero su función principal es
describir datos y no mostrarlos como es el caso de HTML. XML es un formato que permite la
lectura de datos a través de diferentes aplicaciones. Las tecnologías XML son un conjunto de
módulos que ofrecen servicios útiles a los usuarios. XML sirve para estructurar, almacenar e
intercambiar información [XML08a].
Entre las tecnologías XML disponibles se pueden destacar [XML08b]:
XLS. Lenguaje Extensible de Hojas de Estilo, cuyo objetivo principal es mostrar
cómo debería estar estructurado el contenido.
XPath. Lenguaje de Rutas XML, es un lenguaje para acceder a partes de un
documento XML.
XLink. Lenguaje de Enlace XML, es un lenguaje que permite insertar elementos
en documentos XML para crear enlaces entre recursos XML.
XPointer. Lenguaje de Direccionamiento XML, es un lenguaje que permite el
acceso a la estructura interna de un documento XML, esto es, a sus elementos,
atributos y contenido.
XQL. Lenguaje de Consulta XML, es un lenguaje que facilita la extracción de
datos desde documentos XML.
3.1.2 WSDL (Web Services Description Language) [GRA02]
WSDL es un Lenguaje para Definición de Servicios Web que ofrece a los proveedores de
servicios Web una manera para describir el formato básico de un servicio requerido, a través
de diferentes protocolos. WSDL es usado para describir lo que un servicio Web puede hacer,
dónde reside, y cómo invocarlo. WSDL en el sentido más amplio hace posible que SOAP
(Simple Object Access Protocol), HTTP (HyperText Transfer Protocol) y MIME
(Multipurpose Internet Mail Extensions) sean los mecanismos de invocación para objetos
Capítulo III. Marco Conceptual
22
remotos. Los registros de UDDI (Universal Description, Discovery and Integration) describen
numerosos aspectos de los servicios Web, incluso los detalles del servicio. Con base a esto el
protocolo y la especificación del formato de datos para un tipo de puerto con WSDL,
constituye una liga reutilizable.
3.1.3 SOAP (Simple Object Access Protocol)
SOAP es un protocolo estándar denominado Protocolo de Acceso a Objetos Simples basado
en XML y creado por Microsoft, IBM y otros. Proporciona un mecanismo ligero para el
intercambio de información estructurada entre puntos en ambientes descentralizados y
distribuidos. Consta de tres partes: un sobre que define el marco para describir lo que está en
el mensaje y cómo procesarlo; un conjunto de reglas codificadas que definen el mecanismo de
serialización a utilizar en el intercambio de instancias de los datatypes definidos en la
aplicación; y una convención para representar las llamadas y respuestas a procedimientos
remotos [W3C02].
“SOAP Simplifica el acceso a los objetos, permitiendo a las aplicaciones invocar
métodos, objetos o funciones, que residen en sistemas remotos. Una aplicación SOAP crea una
petición bloque en XML, proporcionando los datos necesarios para el método remoto así como
la ubicación misma del objeto remoto” [PER02].
3.1.4 UDDI (Universal Description, Discovery and Integration) [WIK08]
UDDI son las siglas del catálogo de negocios de Internet denominado Universal Description,
Discovery and Integration. El registro en el catálogo se hace en XML. UDDI es una iniciativa
industrial abierta (sufragada por la OASIS) englobada en el contexto de los servicios Web.
El registro de un negocio en UDDI tiene tres partes:
1. Páginas blancas: dirección, contacto y otros identificadores conocidos.
2. Páginas amarillas: categorización industrial basada en taxonomías.
3. Páginas verdes: información técnica sobre los servicios que aportan las propias
empresas.
UDDI es uno de los estándares básicos de los servicios Web cuyo objetivo es ser accedido por
los mensajes SOAP y dar paso a documentos WSDL, en los que se describen los requisitos del
protocolo y los formatos del mensaje solicitado para interactuar con los servicios Web del
catálogo de registros.
3.2 Composición de servicios
El modelado de procesos de negocio y la interacción de varios servicios Web dan origen al
concepto de composición de servicios. Las composiciones de los servicios Web se refieren a la
implementación de servicios Web complejos que internamente invocan a otros servicios.
Los dos términos comúnmente usados para referirse a la colaboración entre varios
servicios Web son coreografía y orquestación. Ambos se enfocan en aspectos complementarios de la interacción entre ellos [CUB05].
Capítulo III. Marco Conceptual
23
3.2.1 Coreografía
La coreografía compone servicios para colaboraciones entre procesos de negocio, definiendo
la manera en que múltiples participantes colaboran. Es un modelo de composición de servicios
Web distribuido que define qué conversaciones se pueden producir entre distintos servicios
Web. Es el conjunto de reglas que rige las características de conducta en relación a la
interacción de un grupo de servicios Web. Estas reglas incluyen la secuencia en la cual los
servicios pueden ser invocados [THO04].
“La coreografía sigue la secuencia de los mensajes que pueden implicar múltiples
partes y fuentes, incluyendo clientes, proveedores y socios. Típicamente se asocia con el
intercambio público de mensajes que ocurre entre servicios Web, más que con un proceso
específico del negocio que sea ejecutado por una sola parte” [PEL03].
3.2.2 Orquestación
La orquestación compone servicios para generar un nuevo proceso de negocio. “Es la
implementación de una coreografía dentro del contexto de un flujo de trabajo o proceso de
negocio” [THO04]. La orquestación de servicios describe cómo pueden comunicarse los
servicios Web entre sí a nivel de mensajes, incluyendo la lógica de interacción para el negocio
y el orden de ejecución de las interacciones [PEL03]. Es un proceso de colaboración entre
distintos servicios Web bajo un patrón determinado y específico, basado en criterios de
interacción con base en el mensaje resultante de cada uno de ellos a nivel de ejecución
[MON06].
La orquestación de servicios Web se refiere a un proceso de negocio ejecutable que
puede interactuar con servicios Web internos y externos. Siempre representa el control de la
perspectiva de una parte. Esto lo distingue de la coreografía que es más de colaboración. La
orquestación define completamente las interacciones con los servicios componente y la lógica
requerida para dirigir correctamente esas interacciones [PEL03]. Une un conjunto de servicios
existentes con el fin de crear un nuevo servicio, mediante el uso de las tecnologías del flujo de
trabajo [HRA04].
3.3 Lenguaje de composición BPEL4WS
BPEL4WS (Business Process Execution Language for Web Services) es un lenguaje de
especificación basado en XML, se utiliza para describir procesos de negocio y administra la
interacción entre diferentes servicios Web.
El lenguaje BPEL4WS permite crear procesos de negocio mediante la composición de
servicios Web (SW) preexistentes y ofrecerlos a su vez como SW. Este lenguaje apoya el
modelado de dos tipos de procesos: abstractos y ejecutables. Los procesos abstractos
especifican coordinaciones de servicios Web, mientras que los procesos ejecutables
especifican sus composiciones.
BPEL es un lenguaje de flujo de procesos, el cual es desarrollado normalmente usando un editor visual para crear un diagrama de flujo, donde cada elemento en el proceso se llama
Capítulo III. Marco Conceptual
24
actividad “activity”. Las actividades en BPEL son las actividades que se llevan a cabo dentro
del proceso de negocio. Un ejemplo de aplicación de BPEL es la reserva de un boleto aéreo y
de un hotel en forma simultánea, a través de una agencia de viajes. En este caso, existen
muchas actividades asociadas a un mismo proceso, desde el punto del cliente.
En resumen, BPEL4WS puede tener un alto impacto en solucionar la compleja
integración tecnológica de las empresas, contribuir a definir procesos con mayor dinamismo y
de acuerdo a la lógica de cada negocio, monitorear procesos y obtener, como consecuencia de
lo anterior, un máximo aprovechamiento de la infraestructura de TI, una mayor flexibilidad y
escalabilidad de los sistemas.
3.3.1 Elementos del lenguaje BPEL4WS
En un proceso de composición de servicios, el intercambio de información está
representado por un esquema XML implementado en lenguaje BPEL. La estructura del
esquema tipo árbol consiste de varios elementos, en la que el nodo padre es el elemento
principal y está representado por una etiqueta <process>. Además los elementos constructivos
de un proceso BPEL4WS son las actividades, que pueden ser primitivas (assign, compensate,
empty, invoke, receive, reply, throw y wait) y estructuradas (sequence, switch, flow, while,
pick, scope). Las primitivas son las que realizan una determinada tarea, mientras que las
estructuradas pueden contener otras actividades y definen la lógica de negocio.
BPEL4WS permite realizar acciones en paralelo y de forma sincronizada. Por ejemplo,
la actividad flow permite ejecutar un conjunto de actividades concurrentemente especificando
las condiciones de sincronización entre ellas. Sin embargo, para que un código BPEL sea
ejecutable requiere de información adicional como la definición de los partner links y
variables. Los cuales se describen en el siguiente apartado.
3.3.1.1 Partner Links
Define las relaciones entre los socios por medio de mensajes SOAP y tipos de puerto
utilizados en las interacciones en ambas direcciones. Cada partner link tiene un nombre y se
caracteriza por un partnerLinkType. A continuación se muestra la sintaxis como se presenta
en la especificación del BPEL [SPE03].
<partnerLink name="nombre" partnerLinkType="nombrePLT" myRole="nombreMR"?
partnerRole="nombrePR"?> </partnerLink>
3.3.1.2 Variables
Define un identificador de un tipo de dato usado durante el proceso de composición. El
nombre de la variable debe ser único, los atributos messageType, type y element se utilizan
para especificar el tipo de la variable. Se muestra la sintaxis como se presenta en la
especificación de BPEL [SPE03].
<variable name="nombreVar" messageType="tipoMensaje"? type="tipoDato"? element=
"elemento"?/>
Capítulo III. Marco Conceptual
25
3.3.1.3 Actividades primitivas
Las actividades primitivas representan fundamentalmente acciones en el flujo de actividades y
acciones que pueden tomar dentro de un proceso. En la tabla 4, se describen brevemente las
actividades primitivas. Tabla 4. Actividades primitivas
Actividad
BPEL
Descripción
Assign
Asigna o actualiza un valor para una o más variables. Permite copiar datos de una variable
XML a otra o calcular el valor de una expresión y almacenarlo en una variable. Para esto, los
tipos de dato origen y destino deben ser compatibles.
Invoke
Invoca una operación de un servicio Web. Puede ser una operación síncrona o asíncrona. Esto
depende de los puertos definidos en el WSDL del servicio.
Receive
Especifica que el partner link espera recibir un mensaje por parte de la operación y el puerto
que invocó. Juega un rol importante en el ciclo de vida del proceso, ya que la única forma de
instanciarlo, es colocando el atributo createInstance=’yes’ en la primer actividad del proceso.
Reply
Envía un mensaje de respuesta a una petición aceptada previamente a través de una actividad
receive. La combinación de <receive> y <reply> forma una operación petición-respuesta en el
WSDL portType del proceso.
Throw Genera una falla desde el interior del proceso de negocio.
Compensate
Invoca la compensación interna al terminar la actividad. Esta puede ser invocada desde el
interior del manejador de fallas o de otro manejador de compensación.
Wait
Define un determinado tiempo de espera durante la ejecución del proceso. Uno de los criterios a
especificar debe ser la duración del tiempo que se va a esperar.
Empty Representa una actividad nula. Es útil para la sincronización de las actividades concurrentes.
3.3.1.4 Actividades estructuradas
Las actividades estructuradas contienen internamente a otras actividades (primitivas y/o
estructuradas) y están diseñadas con la finalidad de brindar una “estructura” al proceso a ser
modelado. En la tabla 5, se describen brevemente las actividades estructuradas.
Tabla 5. Actividades estructuradas
Actividad
BPEL
Descripción
Sequence
Permite definir un conjunto de actividades (primitivas o estructuradas) que se ejecutan de
manera secuencial. Invocación secuencial de actividades.
Switch Permite seleccionar exactamente una rama de actividad de un conjunto de opciones
condicionales, y definidas en elementos case, seguidas de forma opcional por un elemento
otherwise. Las ramas se evalúan en el orden en que fueron definidas. La rama cuya condición
se evalúe verdadera, se selecciona para ser ejecutada. Si ninguna condición se evalúa como
verdadera y se definió una opción otherwise, entonces se selecciona esta última.
Flow Permite realizar las invocaciones en paralelo de las actividades (primitivas o estructuradas).
While Permite indicar que una actividad se repetirá hasta que un cierto criterio se haya cumplido con
éxito. Soporta la ejecución iterativa de una actividad específica. Tiene asociada una condición
booleana y ejecuta la actividad interna mientras que la condición sea verdadera.
Pick Permite esperar la ocurrencia de algún evento de entre un conjunto de ellos.
Scope Permite definir actividades anidadas con sus propias variables asociadas, manipuladores de
fallas y de compensación.
Capítulo III. Marco Conceptual
26
3.4 Diagramas de actividades
Los diagramas de actividades aparecieron en la notación UML 1.3 y es uno de los más
utilizados para el modelado de aspectos dinámicos de un sistema. El diagrama de actividad
combina ideas de varias técnicas: el diagrama de eventos de Jim Odell [FOW94], las técnicas
de modelado de estados de SDL (Specification and Description Language) y las redes de
Petri. Estos diagramas son particularmente útiles en conexión con el flujo de trabajo y para la
descripción del comportamiento que tiene una gran cantidad de procesos paralelos.
Es importante mencionar que aunque un diagrama de actividad es muy similar en
definición a un diagrama de flujo, éstos no son lo mismo. Se puede considerar que un
diagrama de actividad describe el problema, mientras que un diagrama de flujo describe la
solución al problema [DAC08].
Los diagramas de actividad han sido diseñados para modelar los aspectos dinámicos
que muestran la secuencia de acciones concurrentes y los pasos dentro de un proceso
computacional, modelando el flujo de control de una operación [MAR01].
En la tabla 6, se describen los distintos elementos que integran un diagrama de
actividad UML 2.0 [DAC08]:
Tabla 6. Elementos de un diagrama de actividad
Elemento
Descripción Representación
Inicio Es representado por un círculo de color negro sólido.
Actividad Representa la acción que será realizada por el sistema la cual es
representada dentro de un óvalo.
Transición Se utiliza cuando se lleva a cabo el cambio de una actividad a otra,
la transición se representa por una línea con una flecha en su
terminación para indicar la dirección.
Ramificación
(Branch)
Se utiliza cuando existe la posibilidad que ocurra más de una
transición (resultado) al terminar determinada actividad. Este
elemento se representa a través de un rombo.
Unión
(Merge)
Se utiliza al fusionar dos o más transiciones en una sola transición o
actividad. Este elemento se representa a través de un rombo.
Expresiones
de resguardo
(Guard
expressions):
Se utiliza para indicar una descripción explicita acerca de una
transición. Es representada mediante corchetes ([…]) y se coloca
sobre la línea de transición.
[…]
Fork
Representa una necesidad de ramificar una transición en más de una
posibilidad. Aunque similar a una ramificación (branch) la
diferencia radica en que un fork representa más de una ramificación
obligada, esto es, la actividad debe proceder por ambos o más
caminos mientras que una ramificación (branch) representa una
transición hacia una u otra actividad (como una condicional). Un
fork se representa por una línea negra sólida, perpendicular a las
líneas de transición.
Capítulo III. Marco Conceptual
27
Join Se utiliza al fusionar dos o más transiciones provenientes de un
fork, se emplea para unir dichas transiciones en una sola, tal y como
ocurría antes de un fork. Se representa por una línea negra sólida,
perpendicular a las líneas de transición.
Fin Se representa por un círculo, con otro círculo concéntrico de color
negro sólido.
Canales
(swimlanes)
Se utiliza para dividir el diagrama de actividad en grupos
relacionados, donde cada uno representa la parte de la organización
responsable de esas actividades.
Un diagrama de actividad tiene como principales objetivos: definir los flujos de trabajo de una
organización; modelar operaciones complejas; formalizar escenarios de un caso de uso;
diseñar un proceso de negocio; entre otras.
En este capítulo se describieron los conceptos teóricos que respaldan el resto del
contenido de este trabajo de tesis, permitiendo al lector entender el dominio en que está
desarrollado este trabajo. Particularmente, el lenguaje BPEL4WS y sus elementos, así como
los diagramas de actividad UML han sido temas fundamentales en el desarrollo de esta tesis.
28
Capítulo IV Análisis y solución del problema
La composición de servicios requiere de una estructura que permita interpretar y detallar la
secuencia de actividades de un proceso. Para generar código BPEL4WS a partir de un
diagrama de actividad que represente la lógica de negocio, es necesario conocer la herramienta
que permite modelar dicha interacción y los módulos asociados; la correspondencia válida
entre el elemento del diagrama de actividad y el código que se desea generar.
En este capítulo se describe el análisis realizado a la herramienta de diseño WS-
SIDDOO y los módulos que lo integran. A partir de este análisis se construyó la propuesta de
solución y las correspondencias entre los elementos y las actividades BPEL; los atributos de
las actividades (primitivas y estructuradas) implementadas en este trabajo de tesis; y los
escenarios válidos para la generación de código de nuevas estructuras: concurrencia y
sincronización simple; concurrencia y sincronización compleja; y de combinación definida
(con agregación de notas informativas).
Capítulo IV. Análisis y solución del problema
29
4.1 Una visión general hacia WS-SIDDOO
La generación de código a través de diagramas de actividad permite que organizaciones
obtengan mucho éxito a nivel organizacional y de sistema. Las organizaciones confían en sus
diseñadores al modelar sus procesos de negocio o flujos de trabajo (workflow) a través de
herramientas sofisticadas que aseguran un alto porcentaje de éxito.
El prototipo WS-SIDDOO es una herramienta de modelado visual desarrollada bajo el
lenguaje de programación Java, que facilita al diseñador modelar procesos o flujos de trabajo
de manera intuitiva, que permite ir agregando el flujo de las actividades y la selección gráfica
de los elementos del diagrama de actividad, que se encuentran presentes en la interfaz de la
herramienta. La interfaz gráfica del cliente proporciona un ambiente visual que incluye menús,
barra de herramientas y barra de modelado, que se utilizan para el diseño de diagramas de
actividades. A fin de comprender más a detalle sobre el comportamiento de la herramienta.
Éste análisis se divide en los siguientes aspectos: arquitectura de WS-SIDDOO; gramática
visual que define el lenguaje de modelado visual; el analizador gramatical implementado
como servicio Web; y el cliente encargado de proporcionar la interfaz gráfica al usuario.
4.1.1 Arquitectura de WS-SIDDOO
WS-SIDDOO está diseñado para evitar que el desarrollador de aplicaciones escriba el código
de interacción entre las operaciones de los servicios Web, involucrados en el proceso de
composición mediante la generación automática de código de composición, a partir de
diagramas de actividades modelados en el cliente WS-SIDDOO. La figura 8, muestra la
integración de los módulos que componen el WS-SIDDOO son: el cliente WS-SIDDOO; el
analizador gramatical implementado como servicio Web WS-SIDDOO; la interfaz del sistema
de búsqueda y selección de servicios Web; el módulo analizador de documentos WSDL (WS-
Compositor); y el módulo de composición.
Figura 8. Sistema de composición de servicio Web WS-SIDDOO
Capítulo IV. Análisis y solución del problema
30
A través de la interfaz del sistema de búsqueda y selección de servicios Web, el desarrollador
de aplicaciones introduce las especificaciones funcionales de los servicios que desea, el
sistema los busca en el repositorio UDDI (Universal Description Discovery and Integration)
cuando se despliega el resultado, el desarrollador selecciona las descripciones de los servicios
que desea componer.
Los nombres y las URL (Uniform Resource Locator) de documentos WSDL de los
servicios seleccionados se envían al cliente WS-SIDDOO. En el cliente, el desarrollador
diseña el modelo de interacción (diagrama de actividad) entre los diferentes servicios. Cuando
se ha seleccionado un servicio, el módulo analizador de documentos WSDL obtiene la
información necesaria para la composición (métodos, enlaces entre los elementos a componer
y mensajes), la presenta al desarrollador para que éste configure la operación. El analizador
gramatical se encarga de validar las conexiones entre el flujo del proceso y los elementos del
modelo.
Finalmente, el desarrollador manda a llamar desde el cliente WS-SIDDOO al módulo
de composición [GYV07] que se encarga de generar el documento en código BPEL que
corresponde a la interacción entre las operaciones de los servicios Web de acuerdo al diagrama
de actividad generado por el diseñador. Este módulo está formado por una serie de algoritmos
que identifican las estructuras que conforman al diagrama de actividad, como las operaciones,
elementos y variables del proceso. Durante el análisis del comportamiento de esta herramienta,
se identificó que para generar código BPEL4WS (Business Process Execution Language for
Web Services) a través de los diagramas de actividad es necesario establecer las
correspondencias entre los elementos del lenguaje de composición BPEL4WS y los elementos
que integran un diagrama de actividad.
4.1.2 Gramática visual WS-SIDDOO
La gramática visual que define el lenguaje de modelado se realizó en base al formalismo de las
gramáticas posicionales. Esta gramática define las reglas sintácticas del lenguaje visual,
considerando la notación de los diagramas de actividad de UML.
La gramática visual se define como:
GP = (NT, T, S, P, POS, PE) donde:
NT: conjunto de símbolos no terminales.
T: conjunto de símbolos terminales.
S: símbolo inicial.
P: reglas de producción.
POS: elemento que proporciona la posición espacial de los símbolos gráficos.
PE: regla de evaluación.
El conjunto de elementos que integran a POS se define como:
POS = {FLUJO, FLUJO_OBJ, DER, ABA, IZQ, ARR}, donde:
FLUJO. Indica la interconexión o flujo de las actividades que se sigue de acuerdo al diseño
del diagrama.
Capítulo IV. Análisis y solución del problema
31
FLUJO_OBJ. Representa el flujo opcional de cambio de estado con alguna actividad.
DER, ABA, IZQ y ARR. Indican la posición espacial que tienen los símbolos con respecto a
otros.
El elemento PE, se define como una regla de evaluación que, convierte oraciones posicionales
derivadas de la aplicación de las reglas gramaticales, de acuerdo a su representación gráfica.
Más detalle sobre la gramática de la herramienta se presenta en [ROM03].
4.1.3 WS-SIDDOO como servicio Web
El WS-SIDDOO permite el análisis formal de la construcción de los diagramas de actividad
evaluando las relaciones entre los diferentes elementos del diagrama de actividad considerados
en la gramática visual implementada para el SIDDOO. Esta evaluación se realiza al momento
de ir construyendo los modelos en el área de modelado y al mismo tiempo se lanzan mensajes
de error si se realiza una conexión inválida entre los elementos.
Este servicio Web implementa el analizador gramatical para evaluar la correcta
construcción de un diagrama de actividad, y se compone de siete clases desarrolladas en Java,
que se encargan del manejo de la interfaz.
4.1.4 Cliente WS-SIDDOO
El cliente del WS-SIDDOO representa la interfaz principal con una serie de ventanas que
permiten configurar cada una de las actividades del modelo diagrama de actividad en relación
a las actividades en BPEL. El cliente permite al usuario definir el documento WSDL que
describe los tipos de datos de entrada y salida del servicio compuesto, utilizando tipos de datos
primitivos. El cliente WS-SIDDOO, se encarga de soportar la comunicación del Servicio Web
con la IU (Interfaz del Usuario) y las clases que participan para la creación de los elementos
gráficos del diagrama de actividad.
Al analizar este módulo se identificó que la principal clase es Amb_visual. Esta clase
representa la interfaz gráfica del usuario (GUI) de todo el sistema. Aquí se agregan todas las
clases de la Swing de Java, que contiene la barra de modelado, menús y el área de modelado.
Se crean las instancias para los objetos gráficos de la interfaz del cliente. Otras clases que
colaboran con Amb_visual son:
AreaModelado. Define el área de diseño y manipular los símbolos gráficos. Esta clase
recibe los eventos del ratón y del teclado que el usuario haga y los pasa a la clase
mediador.
Mediador. Lleva el control temporal de los símbolos y conexiones, se encargar de
recibir la petición del área de modelado para repintar los símbolos y conexiones
almacenados. Esta clase mediador actúa como coordinador de las clases que participan
en el ambiente visual (AreaModelado, DibujarS, Barras_Menús y ControlaHerr).
DibujarS. Es la clase que actúa como interfaz para pintar los diferentes símbolos
gráficos de los diagramas de actividad como: inicio, actividad, decisión, fork, join,
estado de un objeto y fin. Esta superclase hereda las clases concretas (pintaActi,
Capítulo IV. Análisis y solución del problema
32
PintaCondi, PintaDeci, PintaDiv, PintaFin, PintaFlecha, PintaIni, PintaObj, y
PintaUne).
Mcomandos. Es una interfaz para ejecutar los comandos del menú, opciones y la barra
de herramientas. Esta clase contiene un método abstracto que no se implementa en esta
clase, sino que toma la forma e implementa el código de acuerdo al comando
seleccionado para su ejecución. Esta clase deriva en las clases concretas (op_bherram,
op_borrar, op_copiar, op_cortar, op_pagina, op_pegar, op_seleccionar) que
implementan a Mcomandos. Estas clases concretas ejecutan acciones de acuerdo a los
eventos del ratón o teclado seleccionados.
WSAutomata. Implementa un método para realizar la conexión con el servicio Web.
CtrlConexiones. Accede a las funciones del servicio para validar las conexiones entre
los símbolos del modelo.
Adaptador. Se encarga de obtener los valores de los objetos de la clase DibujarS y los
transforma en objetos de tipo Vector, para enviarlos al servicio Web.
4.2 Analizador de documentos WSDL (WS-Compositor)
Este módulo obtiene los datos necesarios para la composición (métodos, enlaces entre los
elementos a componer y mensajes) y los presenta al desarrollador para que configure la
operación de los servicios a utilizar.
Está formado por dos clases AnalizadorWSDL y AnalizadorWSDLVar
desarrolladas en Java utilizando la API JDOM. Este módulo depende de las direcciones
(URLs) de los servicios Web seleccionados en la ventana de configuración del cliente del WS-
SIDDOO, este módulo realiza un recorrido del documento WSDL en forma de árbol, para
extraer los datos como: nombre del servicio, ubicación, métodos y parámetros (entrada y
salida). El módulo AnalizadorWSDL implementa los métodos para el análisis de los
documentos WSDL en forma de recorrido de árbol. La clase AnalizadorWSDLVar, permite
obtener los tipos de datos contenidos en los esquemas XML (XSD) para que el desarrollador
configure las operaciones del servicio que desea.
4.3 Módulo de composición de servicios Web
El módulo de composición está integrado por un conjunto de clases desarrolladas en Java,
permite reconocer, las distintas estructuras secuenciales, condicionales e iterativas y a partir de
estas, generar el código correspondiente en BPEL4WS. Para la generación de código en
BPEL4WS, el módulo implementa una serie de algoritmos basados en características definidas
para cada estructura y a los elementos que están presentes en la interfaz del cliente.
El análisis de este módulo en particular se consideró como punto clave para la solución del
problema, porque este módulo permite la generación de código BPEL4WS a partir de
diagramas de actividad. Sin embargo, este módulo requiere del soporte del módulo ventanas
para la configuración de los partner links y las variables del proceso de composición.
Capítulo IV. Análisis y solución del problema
33
4.3.1 Arquitectura de clases del módulo de composición
El diagrama de clases del módulo de composición se presenta en la figura 9, en el cual se
implementaron dos patrones de diseño: Composite y Strategy.
Esta arquitectura fue modificada de acuerdo al objetivo de la tesis, la modificación
consistió en agregar clases que implementen algoritmos para la generación de código BPEL
de las nuevas estructuras. El punto de extensión identificado se muestra en el recuadro
punteado.
Figura 9. Diagrama de clases del Módulo Composición
Las clases principales de la figura 9, son: CBPELElementos y CGeneraBPEL.
CBPELElementos. Contiene vectores estáticos que almacenan información
correspondiente a los servicios, variables y partner links involucrados en el proceso de composición y los métodos para recuperarla.
class ModuloComposicion
AGenElemento
+ xml: StringBuffer
+ fnGenera() : StringBuffer
AStrategy
+ conexion: DibujarS
+ conector: pintaFlecha
+ copiar: boolean
+ BPELAux: StringBuffer
+ control: pintaActi
+ empty: int
+ fnRecorre() : void
+ fnLlamaMetodos() : void
CActiv idad
# entradas: int
+ CActividad() : void
+ fnRecorre() : void
- fnCuentaES() : void
CBPELElementos
- servicios: Vector
- variables: Vector
- PL: Vector
- TNS: Vector
+ fnInicializa() : void
+ fnGuardaServicios() : void
+ fnGuardaTNS() : void
+ fnGuardaPL() : void
+ fnGuardaVariables() : void
+ fnGetServicios() : void
+ fnGetTNS() : void
+ fnGetPL() : void
+ fnGetVariables() : void
CDecision
+ CDecision() : void
+ fnRecorre() : void
- fnRecorreCond() : void
- fnRecorreWhile() : void
CFin
+ CFin() : void
+ fnRecorre() : void
CFork
+ CFork() : void
+ fnRecorre() : void
CGenEncabezado
+ CGenEncabezado() : void
+ fnGenera() : StringBuffer
CGeneraBPEL
+ BPEL: StringBuffer
+ genBPEL: CRecorreVect
+ genEnc: AGenElemento
+ CGeneraBPEL() : void
+ fnObtenerBPEL() : void
CGenPL
+ CGenPL() : void
+ fnGenera() : StringBuffer
CGenVariable
+ CGenVariable() : void
+ fnGenera() : StringBufferCGenXML
# doc: Document
+ CGenXML() : void
+ fnGuardaXML() : void
CJoin
+ CJoin() : void
+ fnRecorre() : void
CRecorreVect
+ conexiones: Vector
+ anterior: Vector
+ siguiente: Vector
+ i: int
+ BPEL: StringBuffer
+ obj: AStrategy
+ CRecorreVect() : void
+ fnIdentificaObj() : void
+ fnCuentaES() : void
+ fnGetBPEL() : StringBuffer
editor
amb_v isual
DibujarS pintaFlecha
Ventanas
CVentanaNombre
CVentanaBPEL
Modulo Analizador WSDL
AnalizadorWSDL
Name: ModuloComposicion
Author: Maribell Orozco A.
Version: 1.0
Created: 30/11/2008 06:09:01 p.m.
Updated: 01/12/2008 02:55:52 p.m.
genBPEL
identifica
genEnc
obj
ventanaN
analizador
objventana
objobj
obj
objobj
Capítulo IV. Análisis y solución del problema
34
CGeneraBPEL. Define el orden de creación de objetos y la ejecución de métodos para
la generación del código en BPEL, a partir de un diagrama de actividad.
A continuación se describen las clases que colaboran con las dos principales.
AGenElemento. Define el método fnGenera(), éste método abstracto se implementa
en sus clases derivadas.
CGenEncabezado. Implementa el método fnGenera(), para la generación del código
de la etiqueta <process>. En esta clase se aplica el patrón de diseño Strategy.
CGenPL. Implementa el método fnGenera(), para la generación del código de
definición de los partner links. En esta clase se aplica el patrón de diseño Strategy.
CGenVariable. Implementa el método fnGenera(), para la generación del código de
definición de las variables globales del proceso. En esta clase se aplica el patrón de
diseño Strategy.
CRecorreVect. Inicializa la generación de código de la actividad principal del proceso
BPEL.
AStrategy. Define el método fnRecorre() e implementa el método fnLlamaMetodos().
Permite crear nuevos objetos de los tipos de las clases concretas para el recorrido del
vector de conexiones.
CActividad. Implementa el método fnRecorre(), para la generación de código
correspondiente a las operaciones en BPEL definidas en el diagrama de actividad.
CDecision. Implementa el método fnRecorre(), para generar las etiquetas que indican
estructuras condicionales e iterativas.
CFin. Implementa el método fnRecorre(), para generar las etiquetas de fin de
secuencia al final de la rama de una condicional.
CFork y CJoin. Implementan el método fnRecorre(), para recorrer el vector en busca
del siguiente elemento del diagrama de actividad.
CGeneraXML. Es una clase que se encarga de generar el archivo bpel.xml, en el cual
se almacenan las URLs de los documentos WSDL de los servicios involucrados en el
proceso y se relacionan con su respectivo partner link.
4.3.2 Descripción del módulo de composición
El módulo de composición permite la generación de código BPEL correspondiente a los
elementos del diagrama de actividad diseñado en la interfaz del cliente WS-SIDDOO.
Las clases que colaboran para la composición de servicios son:
CGeneraBPEL. Clase principal para la generación de código BPEL.
CVentanaNombre. Crea una ventana para pedir al usuario que ingrese el nombre del
proceso.
CRecorreVect recorre el vector de conexiones acuerdo al elemento que se encuentre
en el vector de conexiones relacionado con el símbolo de inicio.
Las clases CGenEncabezado, CGenPL y CGenVariable generan el código en BPEL
del encabezado (etiqueta <process>), la definición de los partner links y la declaración
de variables. Este módulo implementa estructuras secuenciales, condicionales e
iterativas.
Capítulo IV. Análisis y solución del problema
35
4.4 Módulo ventanas
El módulo ventanas, está formado por un conjunto de clases desarrolladas en Java. Este
módulo implementado en el prototipo WS-SIDDOO, ofrece soporte al módulo de
composición, porque es el encargado de la configuración y generación del código en
BPEL4WS para la composición de servicios Web.
Estas ventanas de configuración son necesarias para complementar la interfaz del
cliente WS-SIDDOO. A través de estas ventanas, el usuario puede configurar elementos
involucrados en la composición y que son independientes de la notación UML, tales como: las
variables y los partner links. Así como también relacionar a cada una de las actividades del
diagrama con actividades en BPEL4WS, tales como: servicios, operaciones y variables
[GYV07].
4.4.1 Arquitectura de clases del módulo ventanas
En la figura 10, se muestra el diagrama de clases del módulo ventanas, que apoya a la
generación automática de código en BPEL a través de la configuración de algunos elementos
para la composición de servicios.
Figura 10. Diagrama de clases del módulo ventanas
4.4.2 Descripción del módulo ventanas
En la figura 10 se presenta el diagrama de clases del módulo ventanas que durante su análisis se determinaron las siguientes clases principales:
class ModuloVentanas
CAgregaPL
CAgregaVar CAgregaWS
CBVar
CConfPRole
CFiltro
CNVar
CVentanaAsignacion
CVentanaBPEL
CVentanacfg
CVentanaNombre
ModuloComposicion
CGeneraBPEL
CBPELElementos
editor
pintaActiDibujarS
ModuloAnalizador
AnalizadorWSDL
Name: ModuloVentanas
Author: Maribell Orozco A.
Version: 1.0
Created: 01/12/2008 02:57:08 p.m.
Updated: 01/12/2008 04:33:32 p.m.
obj
ventana
ventanaN
objobj
obj
obj
Capítulo IV. Análisis y solución del problema
36
CVentanaCfg. Crea una ventana de configuración, que permite al usuario configurar
una actividad del diagrama con relación a uno de los servicios seleccionados y una
operación en BPEL.
CAgregaVar. Permite crear ventanas para la creación de variables para las actividades
BPEL: invoke, receive y reply.
CAgregaPL Permite crear una ventana para agregar un partner link al proceso a partir
de un servicio que haya sido previamente registrado, y configurar sus atributos en base
a los roles y tipos definidos en el documento WSDL del servicio.
CVentanaAsignacion. Permite crear una ventana para seleccionar una variable o parte
de ella desde un árbol, para asignarla a otra variable dentro del proceso, así como
definir expresiones en el lenguaje XPath para obtener y manipular información.
CBVar Crea la ventana de búsqueda de variables, que permite buscar una variable que
fue previamente registrada, para relacionarla con la actividad en BPEL que se está
configurando.
CVentanaBPEL. Crea la ventana BPEL que presenta al usuario el código BPEL4WS
editable generado a partir del diagrama de actividad.
4.5 Identificación de las correspondencias semánticas en BPEL a partir de
un diagrama de actividad
A continuación se presenta el análisis realizado que identifica las correspondencias semánticas
en BPEL a partir de los elementos del diagrama de actividad existentes en la interfaz del
sistema WS-SIDDOO.
Un diagrama de actividad muestra la estructura gráfica, el flujo de las actividades y los
datos. Para realizar el mapeo a código BPEL es necesario capturar y configurar información
necesaria como los: partner links, variables, entre otros elementos.
Los procesos de negocio representan las interacciones entre servicios para lograr un
objetivo de negocio. Estos procesos introducen los mecanismos sistemáticos para tratar
excepciones y procesamiento de fallas. Estos mecanismos no se tomaron en cuenta, de
acuerdo a la aprobación de la propuesta definida; el objetivo consiste en implementar los
elementos gráficos del diagrama de actividad faltantes en la composición de servicios y que se
encuentran integrados en la interfaz del sistema WS-SIDDOO.
Las actividades primitivas implementadas en este trabajo de tesis se determinaron a
través del análisis de la gramática y ejecución de pruebas manuales en el sistema; estas
actividades BPEL primitivas son: <wait> y <empty>; y la actividad estructurada BPEL:
<flow>. Para esta estructura se determinó tres escenarios válidos: estructuras de concurrencia
y sincronización simple; estructuras de concurrencia y sincronización compleja; y estructuras
de combinación definidas (con agregación de notas informativas al proceso modelado).
Estas actividades primitivas y estructuradas fueron implementadas, ejecutadas y
probadas en este trabajo de tesis; las características definidas para cada una de estas
actividades y estructuras se describen a continuación.
Capítulo IV. Análisis y solución del problema
37
4.5.1 Elementos BPEL implementados
Las actividades BPEL implementadas se clasifican en dos grupos.
Primitivas Estas actividades en BPEL se identifican como: wait y empty. Su definición, especificación en
BPEL y sus atributos se muestran a continuación.
Wait
Define un determinado tiempo de espera durante la ejecución del proceso. Uno de los criterios
a especificar debe ser la duración del tiempo que se va a esperar. A continuación se muestra la
sintaxis de esta actividad según se determina en la especificación de BPEL [SPE03]. Los
atributos se definen en la tabla 7.
<wait (for="duration-expr" | until="deadline-expr") standard-attributes>
standard-elements </wait>
Tabla 7. Atributos de configuración para la actividad Wait
Empty
Representa una actividad nula. Es útil para la sincronización de las actividades concurrentes.
A continuación se muestra la sintaxis de esta actividad según se determina en la especificación
de BPEL [SPE03]. El atributo se define en la tabla 8.
<empty standard-attributes> standard-elements </empty>
Tabla 8. Atributo de configuración para la actividad Empty
Estructuradas
Estas actividades en BPEL se identifican como: flow. Las actividades estructuradas contienen
internamente a otras actividades (primitivas y/o estructuradas). Estas actividades están
diseñadas con la finalidad de brindar una “estructura” al proceso a ser modelado en el sistema.
Su definición, especificación en BPEL y sus atributos se muestran a continuación.
Atributos Descripción
nombre Opcional, puede ser definido por el usuario
for Define periodos de duración en tiempos.
( PnYnMnDTnHnMnS)
(P)Periodo. (Y)Años; (M)Meses; (D)Días; (T)Tiempo; (H)Horas; (M)Minutos; (S) Segundos.
until Define periodos en fecha y hora. DateTime.
(CCYY-MM-DDThh:mm:ss)
(CCYY). Año; (MM). Mes; (DD). Día; (T). Tiempo; (hh). Horas; (mm). Minutos; (ss).
Segundos
Atributo Descripción
nombre Opcional, puede ser definido por el usuario. Actividad nula que no hace nada dentro de la
ejecución del proceso.
Capítulo IV. Análisis y solución del problema
38
Flow
Proporciona concurrencia y sincronización. Ejecuta en paralelo una serie de actividades.
Permite especificar una o más actividades que se realizan simultáneamente. Las etiquetas
<Links> se pueden utilizar dentro de las actividades concurrentes para definir las estructuras
de control arbitrarias.
A continuación se muestra la sintaxis de la actividad <flow>, donde el símbolo (+) representa
que pueden existir una o más actividades (estructuradas o primitivas) dentro de una estructura
concurrente. El atributo se define en la tabla 9.
<flow standard-attributes> standard-elements <links>? <link name="ncname">+ </links> activity+
</flow>
Tabla 9. Atributo de configuración para la actividad Flow
4.5.2 Escenarios para la generación de código en BPEL
La generación de código BPEL a partir de diagramas de actividad modelados en el cliente
WS-SIDDOO, se obtiene como resultado del análisis gramatical y las pruebas manuales
efectuadas; verificando el tipo de estructuras nuevas válidas para modelar nuevos procesos de
negocio. La correspondencia o mapeo en BPEL de las actividades primitivas y las estructuras
válidas se definen en los siguientes escenarios.
4.5.2.1 Escenarios de correspondencia en BPEL para actividades primitivas
a) Wait
En la figura 11, se muestra la actividad wait la cual sirve para bloquear la ejecución hasta un
instante especificado. Este instante se especifica mediante una fecha y hora absolutas o como
una duración relativa al inicio de la actividad.
Figura 11. Correspondencia en BPEL con la actividad Wait
b) Empty
En la figura 12, se muestra la actividad empty la cual representa una operación nula.
Figura 12. Correspondencia en BPEL con la actividad Empty
Atributos Descripción
nombre Opcional, puede ser definido por el usuario.
<wait name= “Wait_1” for|until =
“PnYnMnDTnHnMnS| CCYY-MM-DD-
Thh:mm:ss”/>
<empty name = “Empty_1”/>
Capítulo IV. Análisis y solución del problema
39
4.5.2.2 Escenarios de correspondencia en BPEL para actividades estructuradas
I. Escenario para la generación de código BPEL de estructuras concurrentes y de
sincronización simples
La estructura concurrente y de sincronización simple, permite configurar internamente las
actividades primitivas como: assign, invoke, receive. Este tipo de estructuras se delimitan por
la actividad <flow>; esta actividad BPEL define los flujos concurrentes y sincronizados; el
inicio y fin de cada flujo dentro de una estructura <flow> se indicará por las etiquetas en
BPEL <sequence></sequence> relativamente.
La semántica de la etiqueta <sequence>, especifica que el inicio de esta estructura se
indica a partir de un elemento Fork indicado por la letra D que contendrá una entrada y dos o
tres posibles salidas; cada flujo de salida permitirá la ejecución de una o un conjunto de
actividades en BPEL tales como: assign, receive e invoke; el fin de todos los flujos
provenientes de un fork, se define por un elemento Join indicado por la letra U, el cual unirá
los flujos iniciados en una sola salida. Esta salida se habilita sólo todos los flujos han
terminado de ejecutar todas sus actividades y así poder habilitar la siguiente actividad para
continuar la ejecución del proceso.
En la figura 13, se muestra un diagrama modelado en el cliente WS-SIDDOO como el
escenario de éxito para la generación de código BPEL de estructuras de concurrencia y
sincronización simples con dos flujos concurrentes y su correspondencia en código BPEL. La
figura 14, muestra un diagrama de actividad similar al de la figura 13, la diferencia se define
porque esta estructura modela tres flujos concurrentes y de sincronización.
Figura 13. Estructura de concurrencia y sincronización simple con dos flujos
<flow name = “Flow”>
<sequence>
<invoke…/>
<assign . . . > … </assign>
<invoke … />
</sequence>
<sequence>
<assign . . . >…</assign>
<invoke…/>
</sequence>
</flow>
Capítulo IV. Análisis y solución del problema
40
Figura 14. Estructura de concurrencia y sincronización simple con tres flujos
II. Escenario para la generación de código BPEL de estructuras concurrentes y
sincronizadas complejas
La estructura de concurrencia y sincronización compleja, permite que dos o tres flujos se
ejecuten de manera concurrente y sincronizada; en este tipo de estructura se pueden configurar
actividades en espera de periodos de tiempo y actividades nulas; definidas manualmente por el
diseñador.
La semántica válida para esta estructura especifica que el inicio se indica a partir de un
elemento Fork indicado por la letra D que contendrá una entrada y dos o tres posibles salidas;
cada flujo de salida permitirá la ejecución de una o un conjunto de actividades en BPEL tales
como: assign, receive, invoke, wait, empty y estructuras secuenciales, condicionales e
iterativas anidadas. El fin de todos los flujos provenientes de un fork, se define por un
elemento Join indicado por la letra U, el cual serán todas las entradas del elemento Join que
unirá los flujos iniciados, y genera una sola salida, esta salida se habilita sólo si todos los
flujos han terminado de ejecutar todas sus actividades, y así poder pasar a la siguiente
actividad para continuar la ejecución del proceso.
La diferencia entre las estructuras simples y complejas, se determina por el tipo de actividades definidas dentro de la estructura de concurrencia y sincronización; es decir, en una
estructura simple sólo se pueden definir tres tipos de actividades primitivas BPEL: assign,
receive e invoke; y dos tipos de estructuras internas: secuencial y concurrente; en este caso, la
estructura de concurrencia y sincronización compleja puede definir cinco tipos de actividades
primitivas BPEL: assign, receive, invoke, wait y empty; y cuatro tipos de estructuras:
concurrencia y sincronización; secuenciales; condicionales e iterativas.
Las figuras 15 a la 20, muestran diagramas modelados en el cliente WS-SIDDOO
como escenarios de éxito para la generación de código BPEL de estructuras de concurrencia y
de sincronización compleja; con su correspondencia en código BPEL. Las estructuras
complejas permiten configurar internamente estructuras condicionales, representando los
símbolos de condición asociados a las estructuras, permitiendo generar las condiciones en
código BPEL, y así eliminar una de las limitaciones que el sistema en su estado anterior tenía.
<flow name = “Flow”>
<sequence>
<invoke…/>
<assign . . . > … </assign>
</sequence>
<sequence>
<invoke … />
</sequence>
<sequence>
<assign . . . > … </assign>
<invoke…/>
</sequence>
</flow>
Capítulo IV. Análisis y solución del problema
41
Figura 15. Estructura de concurrencia y sincronización compleja con una estructura condicional simple, y su
correspondencia en código BPEL
Figura 16. Estructura de concurrencia/sincronización compleja utilizando una estructura condicional doble y su
correspondencia en código BPEL
<flow name = “Flow”>
<sequence>
<empty name = “Empty_1”/>
<wait name= “Wait_1” for|until =
“PnYnMnDTnHnMnS| CCYY-MM-DD-
Thh:mm:ss”/>
</sequence>
<sequence >
<invoke …/>
<switch>
<case condition= condition >
<sequence>
<assign>…</assign>
</sequence> </case>
</switch>
</sequence>
</flow>
<flow name = “Flow”>
<sequence>
<empty name = “Empty_1”/>
</sequence>
<sequence>
<empty name = “Empty_2”/>
<wait name= “Wait_1” for|until =
“PnYnMnDTnHnMnS| CCYY-MM-DD-
Thh:mm:ss”/>
</sequence>
<sequence>
<assign>…</assign>
<invoke…/>
<switch>
<case condition= condition >
<sequence>
<assign>…</assign>
</sequence>
</case>
<case condition= condition >
<sequence>
<invoke…/>
</sequence>
</case>
</switch>
<empty name = “Empty_3”/>
</sequence>
</flow>
Capítulo IV. Análisis y solución del problema
42
Figura 17. Estructura de concurrencia y sincronización compleja utilizando una estructura condicional tipo
selección en cascada, y su correspondencia en código BPEL
<flow name = “Flow”>
<sequence>
<empty name = “Empty_1”/>
<empty name = “Empty_2”/>
</sequence>
<sequence>
<empty name = “Empty_3”/>
<wait name= “Wait_1” for|until =
“PnYnMnDTnHnMnS| CCYY-MM-DD-
Thh:mm:ss”/>
</sequence>
<sequence >
<assign . . . >…</assign>
<invoke…/>
<switch>
<case condition= condition />
<assign . . . > … </assign>
</case>
<case condition= condition />
<switch>
<case condition= condition />
<invoke…/>
</case>
<case condition= condition />
<assign . . . >… </assign>
</case>
</switch>
</case>
</switch>
<empty name = “Empty_4”/>
</sequence>
</flow>
Capítulo IV. Análisis y solución del problema
43
Figura 18. Estructura de concurrencia y sincronización compleja utilizando una estructura condicional tipo
selección múltiple, y su correspondencia en código BPEL
Figura 19. Estructura de concurrencia y sincronización utilizando una estructura iterativa while, y su
correspondencia en código BPEL
<flow name = “Flow”>
<sequence>
<assign . . . > … </assign>
<empty name = “Empty_1”/>
<wait name= “Wait_1” for|until =
“PnYnMnDTnHnMnS| CCYY-MM-DD-
Thh:mm:ss”/>
</sequence>
<sequence>
<invoke…/>
<switch>
<case condition= condition>
<assign . . . >… </assign>
</case>
<case condition= condition >
<assign . . . > … </assign>
</case>
<case condition= condition >
<assign . . . > … </assign>
</case>
</switch>
<empty name = “Empty_2”/>
</sequence>
</flow>
<flow name = “Flow”>
<sequence>
<assign . . . >
<copy>
<from . . . /> <to . . . />
</copy>
</assign>
<empty name = “Empty_1”/>
<invoke …/>
</sequence>
<sequence>
<while condition= condition >
<invoke…/>
<receive .../>
</while>
<wait name= “Wait_1” for|until =
“PnYnMnDTnHnMnS| CCYY-MM-DD-
Thh:mm:ss”/>
<assign . . . > … </assign>
</sequence>
</flow>
Capítulo IV. Análisis y solución del problema
44
Figura 20. Estructura de concurrencia y sincronización compleja utilizando una estructura iterativa do_while, y
su correspondencia en código BPEL
III. Escenario para la generación de código BPEL para las estructuras de combinación
definidas, con agregación de notas informativas al proceso.
Es la combinación de las estructuras ya existentes (secuenciales, condicionales e iterativas),
fuera de una estructura concurrente y de sincronización; en todas las estructuras se permite la
agregación de notas informativas al proceso de modelado en el cliente WS-SIDDOO, que
define la lógica e interacción de los servicios Web.
En las figuras 21 a la 25, se muestran los escenarios de combinación válidos para las
estructuras que permiten la configuración de las actividades primitivas BPEL: assign; receive;
invoke; reply; wait y empty; y las estructuras de concurrencia y de sincronización simple;
compleja; secuencial; condicional e iterativa; con notas informativas.
<flow name = “Flow”> <sequence>
<assign . . . > … </assign>
<empty name = “Empty_1”/>
<wait name= “Wait_1” for|until =
“PnYnMnDTnHnMnS| CCYY-MM-DD-
Thh:mm:ss”/>
<invoke …/>
</sequence>
<sequence>
<assign . . . > … </assign>
<invoke ..../>
<receive…/>
<while condition= condition >
<invoke ..../>
<receive…/>
</while>
<empty name = “Empty_2”/>
</sequence>
</flow>
Capítulo IV. Análisis y solución del problema
45
Figura 21. Escenario de combinación de estructura de concurrencia y sincronización simple con una estructura
condicional simple; notas informativas; y su correspondencia en código BPEL
<!--Nota: descripción de la nota !-->
<receive . . . />
<assign . . . > … </assign>
<flow name = “Flow”>
<sequence>
<empty name = “Empty_1”/>
<assign . . . > … </assign>
</sequence>
<sequence>
<!--Nota: descripción de la nota !-->
<wait name= “Wait_1” for|until =
“PnYnMnDTnHnMnS| CCYY-MM-
DD-Thh:mm:ss”/>
</sequence>
</flow>
<assign . . . > ... </assign>
<invoke ..../>
<switch>
<case condition= condition >
<sequence>
<assign> … </assign>
</sequence>
</case>
</switch>
Capítulo IV. Análisis y solución del problema
46
Figura 22. Escenario de combinación de estructura de concurrencia y sincronización simple con una estructura
condicional doble; notas informativas; y su correspondencia en código BPEL
<!--Nota: descripción de la nota !-->
<receive . . . />
<assign . . . > … </assign>
<flow name = “Flow”>
<sequence>
<!--Nota: descripción de la nota !-->
<empty name = “Empty_1”/>
<assign . . . > … </assign>
</sequence>
<sequence>
<wait name= “Wait_1” for|until =
“PnYnMnDTnHnMnS| CCYY-MM-
DD-Thh:mm:ss”/>
</sequence>
</flow>
<assign . . . > … </assign>
<!--Nota: descripción de la nota !-->
<invoke ..../>
<switch>
<case condition= condition>
<sequence>
<assign> …</assign>
</sequence>
</case>
<case condition= condition >
<sequence>
<assign> … </assign>
</sequence>
</case>
</switch>
Capítulo IV. Análisis y solución del problema
47
Figura 23. Escenario de combinación de estructura de concurrencia y sincronización simple con una estructura
de selección en cascada; notas informativas; y su correspondencia en código BPEL
<!--Nota: descripción de la nota !-->
<receive . . . />
<assign . . . >…</assign>
<switch>
<case condition= condition />
<invoke .../>
</case>
<case condition= condition />
<switch>
<case condition= condition />
<assign>…</assign>
</case>
<case condition= condition />
<assign>…</assign>
</case>
</switch>
</case>
</switch>
<assign . . . > … </assign>
<assign . . . > … </assign>
<flow name = “Flow”>
<sequence>
<invoke…/>
<!--Nota: descripción de la nota !-->
<wait name= “Wait_1” for|until =
“PnYnMnDTnHnMnS| CCYY-MM-DD-
Thh:mm:ss”/>
</sequence>
<sequence>
<empty name = “Empty_1”/>
</sequence>
</flow>
<reply…/>
Capítulo IV. Análisis y solución del problema
48
Figura 24. Escenario de combinación de estructura de concurrencia y sincronización compleja, con una
estructura condicional iterativa (while); notas informativas; y su correspondencia en código BPEL
<!--Nota: descripción de la nota !-->
<receive . . . />
<assign . . . > … </assign>
<flow name = “Flow”>
<sequence>
<empty name = “Empty_1”/>
<invoke…/>
<!--Nota: descripción de la nota !-->
<wait name= “Wait_1” for|until =
“PnYnMnDTnHnMnS| CCYY-MM-
DD-Thh:mm:ss”/>
</sequence>
<sequence>
<invoke…/>
<switch>
<case condition= condition >
<sequence>
<assign>…</assign>
</sequence>
</case>
<case condition= condition >
<sequence>
<assign>…</assign>
</sequence>
</case>
</switch>
<invoke…/>
</sequence>
</flow>
<receive…/>
<assign>… </assign>
<while condition= condition >
<invoke .../>
<receive .../>
</while>
<assign . . . > … </assign>
<invoke…/>
Capítulo IV. Análisis y solución del problema
49
Figura 25. Escenario de combinación de estructura de concurrencia y sincronización compleja, con una
estructura de selección múltiple; notas informativas; y su correspondencia en código BPEL
<!--Nota: descripción de la nota !-->
<receive . . . />
<assign . . . > … </assign>
<switch>
<case condition= condition>
<assign>… </assign>
<flow name = “Flow”>
<sequence>
<invoke…/>
<assign>… </assign>
</sequence>
<sequence>
<wait name= “Wait_1” for|until =
“PnYnMnDTnHnMnS| CCYY-MM-
DD-Thh:mm:ss”/>
</sequence>
</flow>
<invoke…/>
</case>
<case condition= condition >
<assign>… </assign>
<invoke.../>
<assign>… </assign>
</case>
<case condition= condition >
<assign>... </assign>
<empty name = “Empty_1”/>
<invoke.../>
<assign>... </assign>
</case>
</switch>
<reply>
Capítulo IV. Análisis y solución del problema
50
4.5.3 Restricciones
Para los escenarios presentados anteriormente se determinaron algunas restricciones de
acuerdo al análisis realizado a la gramática del sistema WS-SIDDOO.
Las estructuras de concurrencia y sincronización complejas no permiten habilitar
internamente estructuras de concurrencia y sincronización anidadas.
La generación automática del símbolo condicional asociado a una estructura
condicional doble, múltiple y de cascada, serán agregadas al final mediante una
ventana donde se desplegarán todas las condiciones modeladas durante el proceso.
Como conclusión de este análisis se implementaron tres estructuras nuevas: estructura
de concurrencia y sincronización simple, compleja y de combinación definida. Estas
estructuras permiten modelar procesos de negocio donde se utiliza la concurrencia y
sincronización de actividades e invocaciones en paralelo a servicios Web que participan en el
proceso. Para modelar estos procesos se habilitó el resto de los elementos UML: fork, join,
estado objeto (note), expresiones de resguardo (condición), y mensajes de flujo; integrados en
la interfaz del sistema WS-SIDDOO.
4.6 Metodología de solución propuesta
En la figura 26, se muestra un diagrama donde se describe la metodología de solución que
resolvió el problema planteado, y que consistió en las siguientes fases:
1. Se analizó y comprendió el código y funcionamiento del WS-SIDDOO con el fin de
familiarizarse con el entorno de notación de los diagramas de actividad y el proceso
que se lleva a cabo para la comunicación con el cliente.
2. Se realizó un análisis detallado del código y funcionamiento del Módulo Analizador de
documentos WSDL (WS-Compositor) y del Módulo de composición de servicios, con
el fin de comprender el proceso con el cual trabaja el módulo analizador y cómo se
específica el orden de interacción entre los servicios.
3. Se analizaron los diagramas de actividad para comprender la notación y relacionar
cada uno de los elementos de los diagramas con los elementos del lenguaje de
composición BPEL4WS.
4. Se identificaron los elementos del diagrama de actividad que no estaban
implementados en la parte de composición del sistema WS-SIDDOO.
5. Se identificaron las acciones semánticas que relacionaron cada elemento del diagrama
de actividad que no estaba implementado en el proceso de composición, para generar
de forma automática código semánticamente equivalente en BPEL4WS.
6. Se diseñaron e implementaron acciones semánticas transformando los elementos
faltantes del diagrama de actividad a código semánticamente equivalente en lenguaje
BPEL4WS para el proceso de composición de servicios.
7. Se diseñó un plan de casos de pruebas manuales para determinar si las acciones semánticas eran las correctas.
Capítulo IV. Análisis y solución del problema
51
Figura 26. Metodología de solución propuesta
El diseño e implementación de la solución propuesta que contempla la extensión al sistema
WS-SIDDOO se encuentra descrito en el siguiente capítulo.
52
Capítulo V Diseño e implementación de la extensión del sistema El desarrollo de esta tesis consistió en extender el sistema WS-SIDDOO para generar de forma
automática código de composición BPEL4WS a partir de los elementos de UML: bifurcación
(fork), unión (join), estado objeto (note), condición (guard expressions) y mensajes de flujo
(message flow), integrados en la interfaz del sistema. El análisis realizado permitió extender el
sistema para modelar procesos de negocio con estructuras de concurrencia y sincronización
simple, compleja y de combinación definida.
En este capítulo se describe el diseño de las correspondencias semánticas
implementadas en el módulo de composición con apoyo del módulo ventanas. Este diseño
consiste en diagramas de casos de uso; diagramas de clases y diagramas de secuencia.
Finalmente se muestra el diseño de las ventanas de configuración para las actividades BPEL
implementadas.
Capítulo V. Diseño e implementación de la extensión del sistema
53
5.1 Diseño de casos de uso general del sistema WS-SIDDOO
La figura 27, muestra el diagrama de casos de uso general del sistema. Las interacciones entre
el sistema y el diseñador se consideran como casos de uso principales, y a continuación se
mencionan:
Casos de uso principales:
1. Buscar y seleccionar servicios Web.
2. Modelar la interacción del proceso.
3. Generar código BPEL.
4. Analizar documentos WSDL.
Este trabajo de tesis extendió la funcionalidad del sistema que se define sobre los casos de
uso CU_03.5; CU_03.6; CU_3.7.
Figura 27. Diagrama general de casos de uso del sistema WS-SIDDOO
Los casos de uso CU_01; CU_02 y CU_03 se inician por el diseñador, que representa
el actor principal del sistema WS-SIDDOO. Una instancia del caso de uso CU_02 incluye el
comportamiento del caso de uso CU_04 el cual se encarga de analizar los documentos WSDL
de los servicios Web. La descripción completa de los escenarios de los casos de uso, se
describe en el anexo A de este documento de tesis.
uc Modelo Caso de Uso WSSIDDOO
Diseñador
CU_02. Modelar la
interacción del
proceso
CU_01. Buscar y
seleccionar
serv icios Web
CU_03. Generar
código BPEL
CU_04. Analizar
documentos WSDL«include»
Capítulo V. Diseño e implementación de la extensión del sistema
54
5.1.1 Caso de uso CU_01: Buscar y seleccionar servicios Web
El caso de uso Buscar y seleccionar servicios Web describe el proceso de registro, búsqueda y
selección de servicios Web.
5.1.2 Caso de uso CU_02: Modelar la interacción del proceso
El caso de uso Modelar la interacción del proceso describe el proceso del diseño del diagrama
de actividad.
5.1.3 Caso de uso CU_03: Generar código BPEL
El caso de uso Generar código BPEL describe el proceso de la generación de código en
BPEL4WS a partir del diagrama de actividad modelado en el cliente WS-SIDDOO.
Figura 28. Diagrama general de casos de uso Generar código BPEL
Este caso de uso define el módulo de composición de servicios Web; parte importante en este
trabajo de tesis que permite la generación de código BPEL de las diferentes estructuras válidas
para la composición.
La descripción de los escenarios de los casos de uso CU_03.1; CU_03.2; CU_03.3; y
CU_03.4 se define en el trabajo de [GYV07]; y el resto de los casos de uso CU_03.5;
CU_03.6; CU_03.7 para la generación de código BPEL de estructuras concurrentes y de
sincronización se detallan en el anexo A de esta tesis.
uc CU_03. Generar código BPEL
Diseñador
CU_03.1 Generar
código encabezado
CU_03.2 Generar
código para
estructuras secuenc.
CU_03.3 Generar
código para
estructuras condic.
CU_03.4 Generar
código para
estructuras
iterativ as
CU_03.5 Generar
código para
estructuras
concurr./sincron.
simples
CU_03.6 Generar
código para
estructuras
concurr./sincron.
complejas
CU_03.7 Generar
código para
estructuras de
combinación
definidas
«include»
«include»
«include»
«include»
«include»
«include»
Capítulo V. Diseño e implementación de la extensión del sistema
55
5.1.4 Caso de uso CU_04: Analizar documentos WSDL
El caso de uso Analizar documentos WSDL describe el proceso de análisis de los documentos
WSDL de los servicios Web seleccionados.
5.2 Diseño del diagrama de secuencia del sistema WS-SIDDOO
La figura 29, muestra la interacción para la generación de código BPEL, a partir de la
selección de los servicios Web a componer.
El diseñador registra, busca y selecciona los servicios que desea componer, a través de
la interfaz del sistema de búsqueda y selección de servicios, donde permite seleccionar el o los
servicios de acuerdo a las funcionalidades requeridas por el diseñador.
Después de que el diseñador selecciona los servicios requeridos el sistema envía al
cliente WS-SIDDOO un vector que contiene información de los servicios Web seleccionados,
tales como: nombres, las direcciones de los documentos de descripción de servicios Web
(WSDL). El diseñador selecciona cada uno de los servicios Web a utilizar y configura los
diferentes partner links que estarán involucrados en el proceso. El cliente envía las direcciones
de los documentos de descripción de cada servicio Web seleccionado (WSDL) al módulo
analizador, este módulo obtiene la información necesaria para la configuración.
El diseñador dibuja el diagrama de actividad del proceso que corresponde a las
actividades BPEL. Para su configuración, el cliente WS-SIDDOO envía al analizador de
documentos WSDL la dirección (URL) del partner link seleccionado para dicha actividad.
Este obtiene la información correspondiente a las operaciones y puertos del servicio. El cliente
recupera la información y la presenta al diseñador, dentro de una ventana de configuración,
para asignar las operaciones a las actividades del diagrama de actividad.
El diseñador dibuja las conexiones y las envía al servicio Web WS-SIDDOO para que
sean validados. Al terminar de modelar y configurar cada una de las actividades del diagrama,
el diseñador selecciona la opción componer integrada en la interfaz del cliente WS-SIDDOO.
El cliente envía el vector de conexiones al módulo de composición de servicios. El módulo de
composición recorre el vector de conexiones y los vectores que almacenan variables, partner
links y espacios de nombre para generar el código en BPEL4WS correspondiente al diagrama
de actividad y lo regresa al cliente del WS-SIDDOO.
Capítulo V. Diseño e implementación de la extensión del sistema
56
Figura 29. Diagrama de secuencia general del sistema WS-SIDDOO
sd Diagrama de secuencia general de WSSIDDOO
:Diseñador
Módulo de
composición
WS-SIDDOO
como Servicio
Web
Módulo
analizador de
WSDL
Sistema de búsqueda y
selección de Servicios
Web
Cliente
WS-SIDDOO
Registra_SW
Busca_SW
Devuelve_Resultados
Selecciona_SW
Selecciona_Componer
Envia_Vector
Selecciona_SW
Envia_URL_de_WSDL
Obtiene_Información
Recupera_Información
Presenta_Información
Configura_PartnerLink
Dibuja_Elementos
Configura_Elementos
Recupera_Información
Presenta_Información
Asigna_Operación *[Mientras exista figuras]
Dibuja_Conexión
Envía_Conexión
Valida_Conexión
Selecciona_Componer
Envía_Vector_Conexiones
Recorre_Vectores
Genera_BPEL
Regresa_BPEL
Despliega_BPEL
Capítulo V. Diseño e implementación de la extensión del sistema
57
5.3 Diseño de los diagramas de secuencia de la extensión al módulo de
composición 5.3.1 Diagrama de secuencia para generar código de estructuras de concurrencia y
sincronización simples
La figura 30, muestra el escenario para la generación de código BPEL de estructuras de
concurrencia y sincronización simples.
El cliente WS-SIDDOO permite modelar el proceso de negocio a través de diagramas
de actividad. En primer lugar el cliente crea una instancia de la clase principal del módulo,
CGeneraBPEL, que define la creación de objetos y la ejecución de métodos para la
generación de código de las estructuras modeladas en el diagrama de actividad.
CGeneraBPEL crea una instancia de la clase CRecorreVect que inicializa la generación de
código de la actividad principal del proceso BPEL.
Al hacer el recorrido se identifican los elementos del tipo CActividad y este a su vez
identifica los elementos Fork y Join, generando las etiquetas <flow> y <sequence> para el
inicio de los flujos salientes del símbolo Fork, y continuar con las actividades primitivas del
diagrama dentro del Fork y hasta encontrar un elemento Join que delimita el fin de estas
estructuras generando la etiqueta </sequence> por cada flujo saliente, y al final de estos flujos
se genera la etiqueta </flow> que indica el cierre del Fork.
Por último, se encuentra con el símbolo fin del diagrama de actividad y se genera su
correspondiente código en BPEL determinado por las etiquetas </sequence> y </process>.
La clase CGeneraBPEL llama al método fnGetBPEL() y recupera el código generado
a partir del diagrama de actividad modelado en el cliente WS-SIDDOO.
Capítulo V. Diseño e implementación de la extensión del sistema
58
Figura 30. Diagrama de secuencia para generar código para estructuras de concurrencia/sincronización
simples
sd Diagrama de secuencia para la estructura de concurr./sincron. simples
identifica:
CGeneraBPEL
obj : CFinobj : CForkobj : CActividadgenBPEL :
CRecorreVect
new CRecorreVect ( )
void fnIdentificaObj ( )
new CActividad ( )
void fnRecorre ( )
void fnLlamaMetodos ( )
new CFork ( )
void fnRecorre ( )
void fnRecorreFork ( )
void fnLlamaMetodos ( )
new CActividad ( )
void fnRecorre ( )
void fnLlamaMetodos ( )
void fnLlamaMetodos ( )
new CFin ( )
void fnRecorre ( )
StringBuffer fnGetBPEL ( )
Return BPEL
Capítulo V. Diseño e implementación de la extensión del sistema
59
5.3.2 Diagrama de secuencia para generar código de estructuras de concurrencia y
sincronización complejas
La figura 31, muestra el escenario para la generación de código BPEL de estructuras de
concurrencia y sincronización complejas.
El cliente WS-SIDDOO permite modelar el proceso de negocio a través de diagramas
de actividad. En primer lugar el cliente crea una instancia de la clase principal del módulo,
CGeneraBPEL, que define la creación de objetos y la ejecución de métodos para la
generación de código de las estructuras modeladas en el diagrama de actividad.
CGeneraBPEL crea una instancia de la clase CRecorreVect que inicializa la generación de
código de la actividad principal del proceso BPEL.
Al hacer el recorrido se identifican los elementos del tipo CActividad y este a su vez
identifica los elementos Fork y Join, generando las etiquetas <flow> y <sequence> para el
inicio de los flujos salientes del símbolo Fork y continuar con las actividades internas. Las
estructuras complejas definen internamente estructuras condicionales que se identifican con el
elemento decisión (rombo) que define el inicio de estas estructuras condicionales, de tal
manera que se crea una instancia de la clase CDecision, que llama el método fnRecorre () que
identifica si el rombo corresponde a una condicional o a una estructura iterativa. Al
identificarse el rombo como elemento que abre una estructura condicional; se generan las
etiquetas <switch>, <case> y <sequence>, se continúa con el recorrido y la generación del
código de las actividades internas de la estructura. Al llegar a un rombo que se identifica como
elemento de cierre de una estructura condicional, se generan las etiquetas </sequence> y
</case>; y si ya no existen más opciones se cierra la estructura agregando la etiqueta
</switch>. Continuando con el recorrido hasta encontrar un elemento Join que delimita el fin
de estas estructuras generando la etiqueta </sequence> por cada flujo saliente, y al final de
estos flujos se genera la etiqueta </flow> que indica el cierre del Fork.
Por último, se encuentra con el símbolo fin del diagrama de actividad y se genera su
correspondiente código en BPEL determinado por las etiquetas </sequence> y </process>.
La clase CGeneraBPEL llama al método fnGetBPEL() y recupera el código generado
a partir del diagrama de actividad modelado en el cliente WS-SIDDOO.
Capítulo V. Diseño e implementación de la extensión del sistema
60
Figura 31. Diagrama de secuencia para generar código para estructuras de concurrencia/sincronización
complejas
sd Diagrama de secuencia para estructuras de concurr./sincron. complejas
identifica :
CGeneraBPEL
obj : CActividadgenBPEL :
CRecorreVect
obj : CFork obj : CDecision obj : CFin
new CRecorreVect ( )
void fnIdentificaObj ( )
void fnCuentaES ( )
new CActividad ( )
void fnRecorre ( )
void fnLlamaMetodos ( )
new CFork ( )
void fnRecorre ( )
void fnRecorreFork ( )
void fnLlamaMetodos ( )
new CActividad ( )
void fnRecorre ( )
void fnLlamaMetodos ( )
new CDecision ( )
void fnRecorre ( )
void fnRecorreCond ( )
void fnLlamaMetodos ( )
new CActividad ( )
void fnRecorre ( )
void fnLlamaMetodos ( )
new CDecision ( )
void fnRecorre ( )
void fnRecorreCond ( )
void fnLlamaMetodos ( )
new CActividad ( )
void fnRecorre ( )
void fnLlamaMetodos ( )
new CFin ( )
void fnRecorre ( )
StringBuffer fnGetBPEL ( )
Return BPEL
Capítulo V. Diseño e implementación de la extensión del sistema
61
5.3.3 Diagrama de secuencia para generar código para estructuras de combinación
definidas
La figura 32, muestra el escenario para la generación de código BPEL de la combinación de
estructuras de concurrencia y sincronización con estructuras condicionales e iterativas en el
interior o exterior de la estructura concurrente.
El cliente WS-SIDDOO permite modelar el proceso de negocio a través de diagramas
de actividad. En primer lugar el cliente crea una instancia de la clase principal del módulo,
CGeneraBPEL, que define la creación de objetos y la ejecución de métodos para la
generación de código de las estructuras modeladas en el diagrama de actividad.
CGeneraBPEL crea una instancia de la clase CRecorreVect que inicializa la generación de
código de la actividad principal del proceso BPEL.
Al hacer el recorrido se identifican los elementos del tipo CActividad y este a su vez
identifica los elementos Fork y Join, generando las etiquetas <flow> y <sequence> para el
inicio de los flujos salientes del símbolo Fork. Si se continúa el recorrido interno de este tipo
de estructuras se pueden encontrar actividades primitivas y estructuradas definidas en el
diagrama, sin embargo en el tipo de estructuras complejas se pueden definir internamente
estructuras condicionales identificando un elemento decisión (rombo) que define el inicio de
estas estructuras condicionales, de tal manera que se crea una instancia de la clase CDecision,
que llama el método fnRecorre () que identifica si el rombo corresponde a una condicional o a
una estructura iterativa. Al identificarse el rombo como elemento que abre una estructura
condicional; se generan las etiquetas <switch>, <case> y <sequence>, se continúa con el
recorrido y la generación del código de las actividades internas de la estructura. Al llegar a un
rombo que se identifica como elemento de cierre de una estructura condicional, se generan las
etiquetas </sequence> y </case>; y si ya no existen más opciones se cierra la estructura
agregando la etiqueta </switch>.
Continuando con el recorrido hasta encontrar un elemento Join que delimita el fin de
estas estructuras generando la etiqueta </sequence> por cada flujo saliente, y al final de estos
flujos se genera la etiqueta </flow> que indica el cierre del Fork. La estructura anteriormente
definida se puede encontrar tanto en el interior o exterior de un Fork realizando el mismo
procedimiento de generación de etiquetas correspondientes.
Por último, se encuentra con el símbolo fin del diagrama de actividad y se genera su
correspondiente código en BPEL determinado por las etiquetas </sequence> y </process>.
La clase CGeneraBPEL llama al método fnGetBPEL() y recupera el código generado
a partir del diagrama de actividad modelado en el cliente WS-SIDDOO.
Capítulo V. Diseño e implementación de la extensión del sistema
62
Figura 32. Diagrama de secuencia para generar código para estructuras de combinación definidas
sd Diagrama de secuencia para estructuras de combinación definidas
identifica :
CGeneraBPEL
obj : CForkgenBPEL :
CRecorreVect ( )
obj : CActividad obj : CDecision obj : CFin
new CRecorreVect ( )
void fnIdentificaObj ( )void fnCuentaES ( )
new CActividad ( )
void fnRecorre ( )
void fnLlamaMetodos ( )
new CFork ( )
void fnRecorre ( )
void fnRecorreFork ( )
void fnLlamaMetodos ( )
new CActividad ( )
void fnRecorre ( )
void fnLlamaMetodos ( )
new CDecision ( )
void fnRecorre ( )void fnRecorreCond ( )
void fnLlamaMetodos ( )
new CActividad ( )
void fnRecorre ( )
void fnLlamaMetodos ( )
new CDecision ( )
void fnRecorre ( )
void fnRecorreCond ( )
void fnLlamaMetodos ( )
void fnRecorreCond ( )
void fnLlamaMetodos ( )
new CActividad ( )
void fnRecorre ( )
void fnLlamaMetodos ( )
new CFork ( )
new fnRecorre ( )
void fnRecorreFork
void fnLlamaMetodos
new CActividad ( )
void fnRecorre ( )
void fnLlamaMetodos ( )
new CDecision ( )
void fnRecorre ( )
void fnRecorreCond ( )
void fnLlamaMetodos ( )
new CActividad ( )
void fnRecorre ( )
void fnLlamaMetodos ( )
new CFin ( )
void fnRecorre ( )
StringBuffer fnGetBPEL ( )
Return BPEL
Capítulo V. Diseño e implementación de la extensión del sistema
63
5.4 Diseño de la extensión al módulo de composición
La extensión al sistema WS-SIDDOO se fundamentó en un análisis a la gramática visual para
establecer las conexiones entre los elementos del diagrama de actividad. Estas conexiones son
validadas a través del servicio Web WS-SIDDOO, y lo cual permite realizar los diferentes
recorridos de los vectores (símbolos, conexión) que almacenan información del diagrama de
actividad.
El vector de conexiones representa la relación que van a tener los símbolos a través de
una conexión, se deben tener mínimo dos símbolos para realizar la conexión. Una línea de
flujo o de conexión también es un símbolo gráfico. Cada conexión está formada por una línea
y una flecha según la dirección que se le desee dar. La línea se compone de uno o más
segmentos que le van dando diferentes direcciones, sin perder su conector de inicio y fin de la
relación. Esta línea de conexión puede ser punteada ó sólida. La información almacenada en el
vector de conexiones es analizada y de acuerdo a ella se determina la estructura diseñada en el
cliente WS-SIDDOO, posteriormente se inicia la generación de código de las distintas
actividades y estructuras BPEL configuradas por el diseñador.
Una estructura de sincronización y concurrencia es simple porque contiene
internamente sólo estructuras secuenciales y actividades BPEL primitivas, tales como: assign,
invoke, receive. Una estructura de sincronización y concurrencia es compleja porque contiene
internamente estructuras secuenciales y condicionales con actividades BPEL primitivas, tales
como: assign, invoke, receive, empty y wait. Finalmente una estructura es de combinación
definida porque contiene en el interior y/o exterior la combinación de ambas estructuras
anteriores agregando notas informativas al proceso modelado.
a) Estructuras concurrentes y de sincronización simples
La figura 33, muestra dos ejemplos de las estructuras de concurrencia y sincronización
simples, en el cual internamente se permite configurar actividades primitivas como: assign,
invoke, receive.
Su semántica especifica que el inicio de esta estructura se indica a partir de un
elemento Fork indicado por la letra D que contendrá una entrada y dos o tres posibles salidas;
cada flujo de salida permitirá la ejecución de una actividad o un conjunto de actividades en
BPEL tales como: assign, receive e invoke; el fin de todos los flujos provenientes de un fork se
define por un elemento Join indicado por la letra U, el cual tiene todas las entradas del
elemento Join que unirá los flujos iniciados, en una sola salida, esta salida se habilita sólo si
todos los flujos han terminado de ejecutar todas sus actividades, y así poder habilitar la
siguiente actividad para continuar la ejecución del proceso.
Capítulo V. Diseño e implementación de la extensión del sistema
64
Figura 33.Estructuras concurrentes y de sincronización simples
b) Estructuras concurrentes y de sincronización complejas
Las figuras 34 a la 39, muestran varios ejemplos de las estructuras de concurrencia y
sincronización complejas, en el cual internamente permiten que dos o tres flujos se ejecuten de
manera concurrente y sincronizada; en este tipo de estructuras se pueden configurar
actividades en espera de periodos de tiempo y actividades nulas definidas manualmente por el
diseñador.
La semántica válida para esta estructura especifica que el inicio se indica a partir de un
elemento Fork indicado por la letra D que contendrá una entrada y dos o tres posibles salidas,
cada flujo de salida permitirá la ejecución de una o un conjunto de actividades en BPEL tales
como: assign, receive, invoke, wait, empty y estructuras secuenciales, condicionales(simple,
doble, cascada, múltiple) e iterativas (while, do-while) anidadas; el fin de todos los flujos
provenientes de un fork, se define por un elemento Join indicado por la letra U, el cual tiene
todas las entradas del elemento Join que unirá los flujos iniciados, en una sola salida, esta
salida se habilita sólo si todos los flujos han terminado de ejecutar todas sus actividades para
continuar la ejecución del proceso.
Figura 34. Estructura concurrente y de sincronización compleja con una estructura interna condicional simple
Capítulo V. Diseño e implementación de la extensión del sistema
65
Figura 35. Estructura concurrente y de sincronización compleja con una estructura interna condicional doble
Figura 36. Estructura concurrente y de sincronización compleja con una estructura interna de selección en
cascada
Capítulo V. Diseño e implementación de la extensión del sistema
66
Figura 37. Estructura concurrente y de sincronización compleja con una estructura interna de selección múltiple
Figura 38. Estructura concurrente y de sincronización compleja con una estructura interna iterativa while
Capítulo V. Diseño e implementación de la extensión del sistema
67
Figura 39. Estructura concurrente y de sincronización compleja con una estructura interna iterativa do while
a) Estructuras concurrentes y de sincronización combinadas
Las figuras 40 a la 44, muestran estructuras de combinación definidas con estructuras
(secuenciales, condicionales e iterativas) internas y/o externas de una estructura concurrente y
de sincronización, en todas las estructuras se permite la agregación de notas informativas al
proceso modelado en el cliente WS-SIDDOO que define la lógica e interacción de los
servicios Web.
Capítulo V. Diseño e implementación de la extensión del sistema
68
Figura 40. Estructura concurrente y sincronización de combinación definida con una estructura condicional
simple externa y notas informativas
Capítulo V. Diseño e implementación de la extensión del sistema
69
Figura 41. Estructura concurrente y sincronización de
combinación definida con una estructura condicional
doble externa y notas informativas
Figura 42. Estructura concurrente y sincronización
de combinación definida con una estructura interna
condicional doble, una estructura externa iterativa y notas
informativas
Capítulo V. Diseño e implementación de la extensión del sistema
70
Figura 43. Estructura concurrente y sincronización de combinación definida con estructura externa de selección
en cascada y notas informativas
Capítulo V. Diseño e implementación de la extensión del sistema
71
Figura 44. Estructura concurrente y sincronización de combinación definida con una estructura externa de
selección múltiple y notas informativas
Capítulo V. Diseño e implementación de la extensión del sistema
72
5.5 Implementación de la extensión al sistema WS-SIDDOO 5.5.1 Módulo de composición y ventanas
En esta sección se describen las clases que implementan la funcionalidad del módulo de
composición para la generación de código de las nuevas estructuras.
La figura 45, muestra el diagrama de clases modificada, agregando las clases
sombreadas que conforman la extensión al módulo de composición definiendo algoritmos para
la generación de código BPEL de las nuevas estructuras. Así mismo, en el módulo ventanas se
implementaron nuevas clases para crear ventanas de configuración de los elementos de
condición y notas de información para el proceso. Las nuevas clases se muestran a color en la
figura 46. La descripción completa de las clases de ambos módulos se detalla en el anexo B de
este documento de tesis.
Figura 45. Arquitectura de clases extendida del módulo de composición
class ModuloComposicion
AGenElemento
+ xml: StringBuffer
+ fnGenera() : StringBuffer
AStrategy
+ BPELAux: StringBuffer
+ conector: pintaFlecha
+ conexion: DibujarS
+ control: pintaActi
+ copiar: boolean
+ empty: int
+ fnLlamaMetodos() : void
+ fnRecorre() : void
CActiv idad
# entradas: int
+ CActividad() : void
- fnCuentaES() : void
+ fnRecorre() : void
CBPELElementos
- PL: Vector
- servicios: Vector
- TNS: Vector
- variables: Vector
+ fnGetPL() : void
+ fnGetServicios() : void
+ fnGetTNS() : void
+ fnGetVariables() : void
+ fnGuardaPL() : void
+ fnGuardaServicios() : void
+ fnGuardaTNS() : void
+ fnGuardaVariables() : void
+ fnInicializa() : void
CDecision
+ CDecision() : void
+ fnRecorre() : void
- fnRecorreCond() : void
- fnRecorreWhile() : void
CFin
+ CFin() : void
+ fnRecorre() : void
CFork
+ CFork() : void
+ fnRecorre() : void
+ fnRecorreFork() : void
CGenEncabezado
+ CGenEncabezado() : void
+ fnGenera() : StringBuffer
CGeneraBPEL
+ BPEL: StringBuffer
+ genBPEL: CRecorreVect
+ genEnc: AGenElemento
+ CGeneraBPEL() : void
+ fnObtenerBPEL() : void
CGenPL
+ CGenPL() : void
+ fnGenera() : StringBuffer
CGenVariable
+ CGenVariable() : void
+ fnGenera() : StringBuffer
CGenXML
# doc: Document
+ CGenXML() : void
+ fnGuardaXML() : void
CJoin
+ CJoin() : void
+ fnRecorre() : void
+ fnRecorreJoin() : void
CRecorreVect
+ anterior: Vector
+ BPEL: StringBuffer
+ conexiones: Vector
+ i: int
+ obj: AStrategy
+ siguiente: Vector
+ CRecorreVect() : void
+ fnCuentaES() : void
+ fnGetBPEL() : StringBuffer
+ fnIdentificaObj() : void
editor
amb_v isual
DibujarS pintaFlecha
Ventanas
CVentanaNombre
CVentanaBPEL
Modulo Analizador WSDL
AnalizadorWSDL
CNote
CCondicion
CNota
+ CNota() : void
+ fnRecorre() : void
ventanaN
identifica
genBPEL
genEnc
obj
obj
condicion
note
obj
obj
objobj
ventanaobj
analizador
obj
obj
Capítulo V. Diseño e implementación de la extensión del sistema
73
Figura 46. Arquitectura de clases extendida del módulo ventanas
5.5.1.1 Nuevas ventanas de configuración
El módulo ventanas implementado en el sistema WS-SIDDOO, ofrece soporte al módulo de
composición, porque es el encargado de la configuración y generación del código en
BPEL4WS para la composición de servicios Web.
La extensión del sistema permite la configuración y generación de condiciones y notas
de información en el proceso. Estas ventanas permiten que el diseñador pueda configurar
elementos involucrados en la composición y que no estén relacionados con algún elemento del
diagrama de actividad modelado en el cliente.
Ventana principal de configuración para actividades BPEL
Esta ventana permite al usuario configurar una actividad del diagrama de actividad con
relación a uno de los servicios seleccionados y una operación en BPEL4WS. Se extendió para
agregar la configuración de actividades primitivas, tales como: wait y empty.
a) Ventana de configuración de la actividad wait
La figura 47, muestra la ventana que permite al usuario configurar la actividad wait de acuerdo
a las características definidas en BPEL. Sus componentes principales de acuerdo a la actividad
son:
class ModuloVentanas
CAgregaPL
CAgregaVar CAgregaWS
CBVar
CConfPRole
CFiltro
CNVar
CVentanaAsignacion
CVentanaBPEL
CVentanacfg
CVentanaNombre
ModuloComposicion
CGeneraBPEL
CBPELElementos
editor
pintaActiDibujarS
ModuloAnalizador
AnalizadorWSDL
CCondicion
CVentanaNota
CVentanaExpresion
CVentanaCondic
obj
ventana
obj
ventanaN
obj
obj
obj
obj
obj
Capítulo V. Diseño e implementación de la extensión del sistema
74
a) Actividad BPEL, permite seleccionar el tipo de actividad BPEL. De acuerdo a la
actividad seleccionada se presentan los atributos para su correspondiente
configuración.
b) Nombre, permite agregar el nombre de la actividad de forma automática, con la
opción de editarla.
c) Time (For), especifica una duración determinada en periodo de tiempos. La duración
se especifica en el siguiente formato:
PnYnMnDTnHnMnS
Donde:
P: letra definida para cada periodo de duración. Todas las expresiones siempre inician
con una P.
Y: letra definida para los años. Por ejemplo, 19 años. 19Y
M: letra definida para los meses. Por ejemplo, 10 meses. 10M
D: letra definida para los días. Por ejemplo, 25 días. 25D
T: letra opcional que indica el inicio de la duración del tiempo.
H: letra definida para las horas. Por ejemplo, 7 horas. 7H
M: letra definida para los minutos. Por ejemplo, 39 minutos. 25M
S: letra definida para los segundos. Por ejemplo, 46 segundos. 46S
d) Expresión, captura la expresión XPath configurada después de presionar el botón
Agregar Expresión XPath.
e) Botón Agregar expresión XPath, invoca a una nueva ventana para construir la
expresión XPath 1.0. Se define la expresión y devuelve el resultado al campo de texto
Expresión.
f) Time (Until), permite especificar fechas y tiempos determinados. Se especifica en el
siguiente formato.
CCYY-MM-DDThh:mm:ss
Donde:
CCYY: define el año determinado.
MM: siglas definidas para el mes, especificado por dos dígitos. Rango válido a partir
de 01 al 12.
DD: siglas definidas para el día, especificado por dos dígitos. Rango válido a partir de
01 al 31.
T: indica el inicio del Time. Especificado por dos dígitos. Rango válido a partir de 01
al 31.
hh: siglas definidas para la hora, especificado por dos dígitos. Rango válido a partir de
00 al 23.
mm: siglas definidas para el minuto, especificado por dos dígitos. Rango válido a
partir de 00 al 59.
ss: siglas definidas para el segundo, especificado por dos dígitos. Rango válido a partir
de 00 al 59.
Capítulo V. Diseño e implementación de la extensión del sistema
75
g) Expresión, captura la expresión XPath configurada después de presionar el botón
Agregar Expresión XPath.
h) Botón Agregar expresión XPath, invoca a una nueva ventana para construir la
expresión XPath 1.0. Se define la expresión y devuelve el resultado al campo de texto
Expresión.
i) Botón Aplicar, permite actualizar los campos correctos para la fecha en el atributo
Until. j) Botón Guardar, permite guardar los datos para cada campo de la actividad
configurada.
k) Botón Salir, permite cerrar la ventana de configuración de actividades BPEL.
Figura 47. Ventana de configuración de la actividad Wait
b) Ventana de configuración de la actividad empty
La figura 48, muestra la ventana que permite al usuario configurar la actividad empty de
acuerdo a las características definidas en BPEL. Sus componentes principales de acuerdo a la
actividad son:
a) Actividad BPEL, permite seleccionar una operación en relación a una actividad en
BPEL. En este caso, la actividad empty.
b) Nombre, permite agregar el nombre de la actividad de forma automática, con la
opción de editarla.
c) Botón Guardar, permite guardar la configuración de la actividad en el proceso.
d) Botón Salir, permite cerrar la ventana de configuración de las actividades en BPEL.
a)
b)
c)
d) e)
f)
g) h)
i) k)
j)
Capítulo V. Diseño e implementación de la extensión del sistema
76
Figura 48. Ventana de configuración de la actividad Empty
c) Ventana para configurar condición booleana
La figura 49, muestra la ventana que permite al usuario configurar las condiciones booleanas
para estructuras condicionales e iterativas definidas. Esta ventana a su vez llama a otra ventana
que permite construir las expresiones booleanas XPath 1.0 necesarias para el proceso. Sus
componentes principales son:
a) Expresión booleana, captura las expresiones XPath configuradas a partir de otra
ventana que se abre al presionar el botón Condición booleana, integrado en la interfaz
de la ventana.
b) Botón Condición booleana, permite al usuario abrir la ventana para construir las
expresiones XPath 1.0.
c) Botón Guardar, permite guardar la condición definida para el proceso modelado.
d) Botón Salir, permite cerrar la ventana de configuración de la condición booleana
definida.
Figura 49. Ventana de configuración para la condición booleana
a)
b)
d)
c)
a)
d)
b)
c)
Capítulo V. Diseño e implementación de la extensión del sistema
77
d) Ventana para construir expresión XPath 1.0
La figura 50, muestra la ventana para la configuración de expresiones manuales necesarias
para configurar actividades, tales como: wait y todas las expresiones XPath 1.0, de acuerdo a
las estructuras condicionales e iterativas durante el diseño del proceso.
Sus componentes se describen a continuación:
a) Expresión, define el área editable para construir la expresión XPath necesaria para
el proceso.
b) Botón Limpiar, limpia el área de la expresión XPath.
c) Botón Insertar Expresión, ingresa la ruta XPath de las variables definidas en el
proceso.
d) Variables BPEL, permite visualizar en forma de árbol todas las variables definidas
en el proceso.
e) XPath, permite capturar temporalmente la ruta XPath seleccionada para
posteriormente ingresarla al área de texto y construir la expresión necesaria.
f) Funciones, despliega todas las funciones XPath definidas que ayudan a construir
las expresiones booleanas o expresiones para duración de tiempos XPath 1.0.
g) Vista Previa, permite visualizar la vista previa de cada elemento seleccionado de
la lista antes de insertarlo al área de texto.
h) Descripción, permite visualizar las descripciones y algunos ejemplos breves de los
elementos seleccionados en la lista antes de insertarlo al área de texto.
i) Botón Guardar, guarda las expresiones construidas y las añade al proceso.
j) Botón Cerrar, permite cerrar la ventana.
Capítulo V. Diseño e implementación de la extensión del sistema
78
Figura 50. Ventana para construir expresiones XPath
e) Ventana para configurar las notas informativas al proceso BPEL
La figura 51, muestra la ventana de configuración para notas informativas en el proceso. Estas
notas son definidas para cada proceso; y su objetivo principal es informar al usuario el origen
de datos de entrada; tiempos de espera; e información adicional a las actividades del proceso
diseñado.
La clase CVentanaNota del módulo de ventanas, crea la ventana que genera las notas y
las almacena en un vector; el vector es llamado a través de la clase CNota del módulo de
composición y regresa el código BPEL generado. Sus componentes principales se describen a
continuación:
a) Notas informativas, permite capturar las notas que definen información adicional al
proceso.
b) Botón Modificar nota, permite modificar la nota al proceso modelado.
c) Botón Guardar, permite guardar la nota informativa en el proceso.
d) Botón Salir, permite cerrar la ventana de configuración de notas informativas.
a)
e)
b)
c)
d)
f)
g) h)
i)
j)
Capítulo V. Diseño e implementación de la extensión del sistema
79
Figura 51. Ventana para configurar las notas informativas
f) Ventana para visualizar las condiciones booleanas definidas en el proceso
La figura 52, muestra la ventana de despliegue para las condiciones definidas durante la
configuración del proceso. Esta ventana ayuda al usuario a integrar cada una de las
condiciones definidas para cada estructura condicional e iterativa. Sus componentes
principales son:
a) Condiciones XPath 1.0, permite visualizar las condiciones definidas durante el
modelado del proceso BPEL.
b) Botón Copiar, permite al usuario copiar cada una de las condiciones y agregarlas al
código BPEL generado para cada estructura condicional e iterativa modelada.
c) Botón Salir, permite cerrar la ventana de despliegue de las condiciones definidas
durante el modelado del proceso BPEL.
Figura 52. Ventana para desplegar las condiciones booleanas definidas en el proceso BPEL
a)
d)
b)
c)
a)
c) b)
80
Capítulo VI Pruebas
En este capítulo se describe el plan de pruebas que se basa en el estándar 829-1998 de la IEEE
(Institute of Electrical and Electronics Engineers) [IEE98], utilizado para pruebas de software.
Este plan de pruebas permite evaluar la extensión al sistema WS-SIDDOO que cubre el caso
de uso Generar código BPEL, en el módulo de composición de servicios Web.
Las pruebas fueron realizadas a través de la herramienta WS-SIDDOO que permite
modelar los diagramas de actividad y el módulo de composición que se encarga de generar el
código BPEL equivalente al diseño del cliente. Este módulo se evaluó realizando 18 pruebas
en el cual se integraron los elementos UML: fork, join, estado objeto (note), expresiones de
resguardo (condiciones), y estado flujo que faltaban en el proceso de composición.
Los diagramas de las pruebas efectuadas se modelaron utilizando estructuras de
concurrencia y sincronización simples, complejas y de combinación definidas, que permitían
las invocaciones a los servicios Web en paralelo.
El objetivo de estas pruebas fue demostrar que el modelo diseñado en el cliente WS-
SIDDOO era equivalente al código BPEL generado. Los módulos que se extendieron para
darle nueva funcionalidad son:
Módulo de composición
Módulo ventanas
Capítulo VI. Pruebas
81
6.1 Hipótesis a probar
“Al modelar la interacción entre servicios Web mediante estructuras de concurrencia y
sincronización simples, complejas y de combinación definidas a través de diagramas de
actividad es posible generar de forma automática código en BPEL4WS”.
6.2 Identificador del plan de pruebas
El código de identificación para la ejecución del plan de pruebas se presenta a continuación y
se establece para todo el proceso de evaluación del módulo de composición de servicios Web.
Número de versión
Tipo de documento
PP. Plan de pruebas
DP. Especificación de diseño de las pruebas
CP. Especificación de los casos de pruebas
PD. Especificación de procedimiento de pruebas
Composición de servicios Web
6.3 Documentación de prueba
Tabla 10. Documentación de pruebas
Tipo Nombre
CSW- PP XX Plan de pruebas
CSW- DP XX Especificación de diseño de las pruebas
CSW- CP XX Especificación de los casos de pruebas
CSW- PD XX Especificación de procedimiento de pruebas
6.4 Descripción del plan de pruebas 6.4.1 CSW- PP01. Plan de pruebas para el módulo de composición de servicios Web
6.4.1.1 Elementos de prueba
Se describe un conjunto de casos de prueba que tiene como objetivo verificar y validar la
correcta generación de código BPEL para la composición de servicios a través del diagrama de
actividad modelado en el cliente WS-SIDDOO.
CSW – AA XX
Capítulo VI. Pruebas
82
Los elementos para realizar las pruebas son:
a) Diagramas de actividad. Se modelarán diagramas que representen estructuras de
concurrencia y sincronización; secuencial y condicional. Las estructuras de
concurrencia y sincronización complejas y de combinaciones definidas, integrarán
actividades nulas y en espera de periodos de tiempo entre servicios Web. Son
correspondientes a las actividades BPEL básicas y estructuradas, tales como: receive,
assign, invoke, reply, wait, empty, sequence, flow, switch y while.
b) Servicios Web. Se implementará un conjunto de servicios Web que efectúen diferentes
operaciones, estos servicios serán base para llevar a cabo los procesos de composición.
Estos servicios se presentan en la tabla 11.
Tabla 11. Servicios Web simples
ID Nombre del servicio Descripción
S01 SW_calcSumarBPEL Calcula la suma de dos números.
S02 SW_calcRestarBPEL Calcula la resta de dos números reales.
S03 SW_calcProductoBPEL Calcula el producto de dos números reales.
S04 SW_calcDividirBPEL Calcula la división de dos números reales.
S05 SW_calcPotenciaBPEL Calcula la potencia “n” de un número real.
S06 SW_calcRaizBPEL Calcula la raíz “n” de un número.
S07 SW_calcTangenteBPEL Calcula la tangente de un número real.
S08 SW_calcValorAbsBPEL Calcula el valor absoluto de un número.
S09 SW_oEscribirArchBPEL Realiza la operación de escritura en un archivo de texto.
S10 SW_oLeerArchBPEL Realiza la operación de lectura de un archivo de texto.
S11 SW_oContarPalabrasBPEL Realiza la operación de contar palabras de un texto.
S12 SW_oBuscarPalabraBPEL Realiza la operación de buscar palabras en un archivo.
6.4.1.2 Características a ser probadas
A continuación se describen las características a ser probadas:
1. Generación de código BPEL de estructuras concurrentes y de sincronización,
utilizando los elementos fork y join de la notación UML, correspondiente al diagrama
de actividad modelado en el cliente WS-SIDDOO.
2. Generación de código BPEL de estructuras secuenciales, condicionales, concurrentes y
de sincronización; utilizando el elemento de condición de guarda de la notación
UML, correspondiente al diagrama de actividad modelado en el cliente WS-SIDDOO.
3. Generación de código BPEL correspondiente al elemento note (estado objeto) de la
notación UML, correspondiente al diagrama de actividad modelado en el cliente WS-
SIDDOO.
4. Generación de código BPEL a partir de la combinación de las diferentes estructuras
modeladas en el cliente WS-SIDDOO integrando los elementos: fork, join, note
(estado objeto), condiciones de resguardo y flujo de objeto.
5. Resultado de la ejecución del código BPEL4WS en el motor de ejecución BPEL.
Capítulo VI. Pruebas
83
6.4.1.3 Características que no se probarán
A continuación se presentan las características que no se van a probar:
El modelado de diagramas de actividad en el cliente del WS-SIDDOO
El funcionamiento del cliente WS-SIDDOO
El funcionamiento del servicio Web WS-SIDDOO
El funcionamiento del sistema de búsqueda y selección de servicios Web
El tiempo de duración de la prueba
El funcionamiento del motor de ejecución de BPEL
6.4.1.4 Enfoque
Este plan de pruebas se centra en los resultados que el módulo de composición espera obtener
durante su proceso, estas pruebas son de tipo funcional o conocidas como caja negra, donde se
considera únicamente el código BPEL generado a partir de los diagramas de actividad de los
casos de prueba y sus resultados.
Se intenta encontrar casos donde el módulo de composición no atiende a su
especificación, el estudio a realizar es de factibilidad. Motivo por el cual se determina que se
puede utilizar el tipo de pruebas funcionales o caja negra, ya que las pruebas de caja blanca
son más completas pero requieren mucho más tiempo.
6.4.1.5 Criterio aceptado / no aceptado
Un caso de prueba pasa con éxito si los resultados esperados coinciden con los descritos en el caso de prueba. En caso contrario, se determinará si es un fallo en la validación del módulo de
composición y si se debe continuar con los siguientes casos de prueba o bien dar por finalizada
la validación.
Para los casos de prueba del módulo de composición de servicios Web, el criterio
aceptado / no aceptado se realizará mediante la evaluación del código BPEL generado a partir
del diagrama de actividad y el cálculo manual del proceso BPEL modelado y comparar el
resultado con el obtenido al utilizar el servicio compuesto.
6.4.1.6 Criterio de suspensión y criterios de reanudación
Las pruebas se suspenderán temporalmente al menos que una de ellas no sea aceptada, e
inmediatamente se evaluará y corregirá el error.
Se reanudará la aplicación de pruebas al momento que se haya corregido el error y el
caso de prueba pase el criterio de aceptación.
6.4.1.7 Liberación de pruebas
Para aceptar y finalizar las pruebas se deberá tener que todos los códigos BPEL de salida y los
resultados de la ejecución del código en el motor, coincidan con los especificados en cada caso
de prueba del módulo de composición de servicios.
Capítulo VI. Pruebas
84
6.4.1.8 Requisitos ambientales
Las características físicas y lógicas necesarias para el entorno de pruebas son las siguientes:
Equipo físico hardware.
Procesador Intel P4 o superior
1 GB de memoria RAM o superior
Mouse
Teclado
Sistema operativo software.
Windows XP
Herramientas y servidores.
Servidor de aplicaciones Apache Tomcat v. 5.5.17
MySQL Server 5.0
Eclipse v. 3.1
Servidor Systinet v. 6.0 o superior
Servidor para BPEL (Oracle BPEL PM 10.1.2 o superior)
jDeveloper 10.1.2 o superior, que incluya un modelador para BPEL
Programas de prueba.
Servicios Web desarrollados en entorno Java
6.4.1.9 Responsabilidades
La responsable de administrar, diseñar, preparar y ejecutar las pruebas es la I.S.C. Maribell
Orozco Ayometzi. Persona que se encargará de modelar los diagramas, generar el código
BPEL4WS, ejecutar los documentos resultantes en un motor para BPEL y comparar los
resultados obtenidos con los esperados en cada caso de prueba.
6.4.1.10 Riesgos
Al planificar el proceso de los casos de pruebas se ha contemplado la ocurrencia de algunos
riesgos durante su ejecución.
Pérdida de tiempo en la generación de los casos de prueba
No contemplar algunos aspectos de importancia durante el diseño de los casos de
prueba
Pérdida de tiempo al ejecutar un caso de prueba incorrecto, su ejecución dará por
resultado pruebas defectuosas e incorrectas.
Pérdida de tiempo en corregir los errores. Se puede presentar errores y/o defectos que
habrá que corregir en su momento, y en ocasiones ya no habrá tiempo de corregirlos y
tampoco para seguir ejecutando los casos de prueba que faltan.
6.4.1.11 Aprobación El plan de pruebas debe ser aprobado por la M.C. Olivia Graciela Fragoso Díaz y el Dr. René
Santaolaya Salgado.
Capítulo VI. Pruebas
85
6.5 Especificación del diseño de pruebas 6.5.1 Propósito
En esta sección se describe el diseño de pruebas para obtener código BPEL4WS a partir de
diagramas de actividad diseñados en la herramienta WS-SIDDOO, sobre estructuras que
permitan realizar invocaciones a métodos de servicios Web en paralelo (concurrencia y
sincronización simple, compleja y de combinación definida); secuenciales; condicionales e
iterativas, integrando las actividades primitivas en BPEL tales como: wait y empty.
6.5.2 CSW–DP01. Diseño de prueba para la generación de código para estructuras de
concurrencia y sincronización simples
a) Características a ser probadas
Esta prueba tiene como característica lo siguiente:
1) Generación de código para estructuras de concurrencia y sincronización simples,
equivalentes al diagrama de actividad diseñado y configurado en el cliente WS-
SIDDOO.
b) Refinamiento del enfoque
El objetivo es probar que el código BPEL generado es equivalente al diagrama de actividad
que se diseña en el cliente WS-SIDDOO. En este modelo se definen las interacciones entre los
servicios Web.
Para cada caso de prueba, se modelará un diagrama de actividad que represente una
estructura concurrente y de sincronización, y que internamente defina actividades primitivas
BPEL, tales como: receive, assign, invoke.
Al terminar de modelar y configurar todas las actividades del diagrama, se generará el
código BPEL equivalente al modelo, y se evaluará por inspección visual utilizando
jDeveloper, porque este permite visualizar el código BPEL de manera gráfica.
c) Identificación de las pruebas
CSW-CP01
CSW-CP02
CSW-CP03
CSW-CP05
CSW-CP14
CSW-CP15
d) Característica de criterio de aceptación/rechazo
Para determinar el criterio de aceptación o rechazo, se debe realizar la evaluación visual del
código generado a partir del diagrama de actividad. Si el código es equivalente al diagrama
diseñado, entonces se considerará que la prueba ha sido exitosa.
En caso contrario, la prueba será rechazada, se tomará en cuenta que la herramienta no
será capaz de identificar los errores de diseño que contenga el modelo, por lo cual el diseñador
debe realizar una inspección visual al modelo.
Composición de servicios Web para generar código BPEL a
partir de estructuras concurrentes y de sincronización simples.
Capítulo VI. Pruebas
86
6.5.3 CSW–DP02. Diseño de prueba para la generación de código de estructuras de
concurrencia y sincronización complejas
a) Características a ser probadas
Esta prueba tiene como característica lo siguiente:
1) Generación de código para estructuras de concurrencia y sincronización complejas,
equivalentes al diagrama de actividad diseñado y configurado en el cliente WS-
SIDDOO.
b) Refinamiento del enfoque
El objetivo es probar que el código BPEL generado es equivalente al diagrama de actividad
que se modela sobre el cliente WS-SIDDOO. En este modelo se definen las interacciones
entre los servicios Web.
Para cada caso de prueba, se modelará un diagrama que represente estructuras de
concurrencia y sincronización complejas; es decir, que su estructura interna contenga
actividades básicas y estructuradas en BPEL tales como: receive, assign, invoke, wait, empty y
sequence, switch, while.
Al terminar de modelar y configurar todas las actividades del diagrama, se generará el
código BPEL equivalente al modelo y se evaluará por inspección visual utilizando el
jDeveloper porque este permite visualizar el código BPEL de manera gráfica.
c) Identificación de las pruebas
CSW-CP04
CSW-CP06
CSW-CP09
CSW-CP12
CSW-CP16
CSW-CP17
d) Característica de criterio de aceptación/rechazo
Para determinar el criterio de aceptación o rechazo, se debe realizar la evaluación visual del
código generado a partir del diagrama de actividad. Si el código es equivalente al diagrama
diseñado, entonces se considerará que la prueba ha sido exitosa.
En caso contrario, la prueba será rechazada, se tomará en cuenta que la herramienta no
será capaz de identificar los errores de diseño que contenga el modelo, por lo cual el diseñador
debe realizar una inspección visual al modelo.
Composición de servicios Web para generar código BPEL a
partir de estructuras de concurrencia y de sincronización
complejas.
Capítulo VI. Pruebas
87
6.5.4 CSW–DP03. Diseño de prueba para la generación de código de estructuras de
combinación definidas con agregación de notas informativas del proceso
a) Características a ser probadas
Esta prueba tiene como característica lo siguiente:
1) Generación de código de estructuras combinadas: concurrencia y de sincronización
simple, concurrencia y de sincronización compleja, secuencial, condicional e iterativa,
con notas informativas al proceso, equivalentes al diagrama de actividad diseñado y
configurado en el cliente WS-SIDDOO.
b) Refinamiento del enfoque
El objetivo es probar que el código BPEL generado es equivalente al diagrama de actividad
que se modela sobre el cliente WS-SIDDOO. En este modelo se definen las interacciones
entre los servicios Web.
Para cada caso de prueba, se modelará un diagrama que combine diferentes estructuras:
concurrencia y de sincronización simple; compleja; secuencial; condicional e iterativa; con
agregación de notas informativas. Las actividades básicas y estructuradas en BPEL a utilizar
son: receive, assign, invoke, reply, wait, empty, sequence, flow, switch y while.
Al terminar de modelar y configurar todas las actividades del diagrama, se generará el
código BPEL equivalente al modelo, y se evaluará por inspección visual utilizando el
jDeveloper porque este permite visualizar el código BPEL de manera gráfica.
c) Identificación de las pruebas
CSW-CP07
CSW-CP08
CSW-CP10
CSW-CP11
CSW-CP13
CSW-CP17
CSW-CP18
d) Característica de criterio de aceptación/rechazo
Para determinar el criterio de aceptación o rechazo, se debe realizar la evaluación visual del
código generado a partir del diagrama de actividad. Si el código es equivalente al diagrama
diseñado, entonces se considerará que la prueba ha sido exitosa.
En caso contrario, la prueba será rechazada, se tomará en cuenta que la herramienta no
será capaz de identificar los errores de diseño que contenga el modelo, por lo cual el diseñador
debe realizar una inspección visual al modelo.
Composición de servicios Web para generar código de estructuras
combinadas: concurrencia y de sincronización simple; compleja;
secuencial; condicional e iterativa; agregando notas de información
al modelo.
Capítulo VI. Pruebas
88
6.5.5 CSW–DP04. Diseño de prueba para la ejecución de código en BPEL4WS
a) Características a ser probadas
Esta prueba tiene como característica lo siguiente:
1) Probar el despliegue del código BPEL generado a partir del diagrama de actividad
diseñado y configurado en el cliente WS-SIDDOO, y el resultado de su ejecución.
b) Refinamiento del enfoque
Esta prueba tiene como objetivo probar que el código BPEL generado a partir del diagrama de
actividad se despliegue y ejecute correctamente en un motor para BPEL. Este diseño de
prueba se centra en los diagramas de actividad que modelan la interacción entre los servicios
Web. Estos modelos diseñados en el cliente WS-SIDDOO integrarán actividades básicas y
estructuradas en BPEL como: receive, assign, invoke, reply, wait, empty, sequence, flow,
switch y while.
Al terminar de modelar el diagrama y configurar las actividades BPEL para la lógica
del proceso, se generará el código BPEL y se almacenará en la carpeta de proyectos de
jDeveloper este código será desplegado en el servidor BPEL PM de Oracle y se probará su
ejecución desde la consola del servidor. El resultado de la ejecución del proceso se verificará
con el resultado de la operación efectuada de manera manual.
c) Identificación de las pruebas
CSW-CP01 a 18
d) Característica de criterio de aceptación/rechazo
Para determinar el criterio de aceptación o rechazo, se debe realizar el despliegue y la
ejecución del código BPEL del servicio compuesto generado a partir del diagrama de
actividad. Si este despliegue no se lleva a cabo correctamente o el resultado del servicio
compuesto es distinto al esperado, entonces la prueba será rechazada. Pero si el despliegue se
efectúa correctamente y si los resultados de la ejecución coinciden con el esperado, entonces
la prueba será aprobada.
En caso de rechazo, probablemente el diagrama de actividad contenga errores de
modelado, se tomará en cuenta que la herramienta no será capaz de identificar los errores de
diseño, por lo cual el diseñador debe realizar una inspección visual al modelo.
6.6 Especificación de casos de prueba Propósito
En esta sección se definen las características y los elementos requeridos para cada uno
de los casos diseñados para probar la generación correcta de código BPEL de las nuevas
estructuras implementadas, tales como: estructura de concurrencia y sincronización simple;
estructura de concurrencia y sincronización compleja; y estructura de combinación definida.
Ejecución del código BPEL generado a partir de los diagramas
de actividad UML modelados en el cliente WS-SIDDOO.
Capítulo VI. Pruebas
89
Las estructuras complejas y de combinación definidas integran actividades que
permiten definir períodos de tiempo y actividades nulas. Estas estructuras pueden combinarse
con las ya existentes (secuenciales, condicionales e iterativas).
Estos casos son definidos para probar y evaluar el correcto funcionamiento del módulo
de composición de servicios Web. Los datos de entrada y los resultados esperados para los
casos de prueba se describen a detalle en el anexo C de este documento de tesis.
6.6.1 Caso de prueba CSW-CP01
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización simples y la ejecución del código en el motor de Oracle, de acuerdo a las
especificaciones del diseño de pruebas CSW-DP01 y CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, calcule el área de un pentágono, utilizando cuatro servicios Web simples que son
independientes.
Elementos de prueba:
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_calcPotenciaBPEL. Calcula la potencia n de un número real.
SW_calcProductoBPEL. Calcula el producto de dos números reales.
SW_calcDividirBPEL. Calcula la división de dos números reales.
SW_calcTangenteBPEL. Calcula la tangente de un número real.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_AreaPentagono.
SW_calcPotenciaBPEL.
SW_calcProductoBPEL.
SW_calcDividirBPEL.
SW_calcTangenteBPEL
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.2 Caso de prueba CSW-CP02
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización simples y la ejecución del código en el motor de Oracle, de acuerdo a las
especificaciones del diseño de pruebas CSW-DP01 y CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, calcule el volumen de un cono, utilizando tres servicios Web simples que son
independientes.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
Capítulo VI. Pruebas
90
SW_calcPotenciaBPEL. Calcula la potencia “n” de un número real.
SW_calcProductoBPEL. Calcula el producto de dos números reales.
SW_calcDividirBPEL. Calcula la división de dos números reales.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_VolumenCono.
SW_calcPotenciaBPEL.
SW_calcProductoBPEL.
SW_calcDividirBPEL
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.3 Caso de prueba CSW-CP03
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización simples y la ejecución del código en el motor de Oracle, de acuerdo a las
especificaciones del diseño de pruebas CSW-DP01 y CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, calcule el área de un círculo, utilizando dos servicios Web simples que son
independientes.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios. SW_calcPotenciaBPEL. Calcula la potencia “n” de un número real.
SW_calcProductoBPEL. Calcula el producto de dos números reales.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_AreaCirculo.
SW_calcPotenciaBPEL.
SW_calcProductoBPEL
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.4 Caso de prueba CSW-CP04
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización complejas y la ejecución del código en el motor de Oracle, de acuerdo a las
especificaciones del diseño de pruebas CSW-DP02 y CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, realice el conteo de todas las palabras contenidas en un archivo de texto y éste
devuelva el numero de palabras y un mensaje “Palabras en él archivo”, si el archivo está
vacío manda un mensaje “Lo siento, el archivo está vacío”, utilizando tres servicios Web
simples que son independientes.
Capítulo VI. Pruebas
91
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_oEscribirArchBPEL. Realiza la operación de escritura en un archivo de texto.
SW_oLeerArchBPEL. Realiza la operación de lectura de un archivo de texto.
SW_oContarPalabrasBPEL. Realiza la operación de contar palabras de un texto.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_ContarPalabArch.
SW_oEscribirArchBPEL.
SW_oLeerArchBPEL.
SW_oContarPalabrasBPEL
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.5 Caso de prueba CSW-CP05
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización simples y la ejecución del código en el motor de Oracle, de acuerdo a las
especificaciones del diseño de pruebas CSW-DP01 y CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, calcule el área de un triangulo, utilizando dos servicios Web simples que son
independientes.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_calcProductoBPEL. Calcula el producto de dos números reales.
SW_calcDividirBPEL. Calcula la división de dos números reales.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_AreaTriangulo.
SW_calcProductoBPEL.
SW_calcDividirBPEL.
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.6 Caso de prueba CSW-CP06
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización complejas y la ejecución del código en el motor de Oracle, de acuerdo a las
especificaciones del diseño de pruebas CSW-DP02 y CSW-DP04.
Capítulo VI. Pruebas
92
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, calcule el área de una esfera, utilizando dos servicios Web simples que son
independientes.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_calcPotenciaBPEL. Calcula la potencia “n” de un número real.
SW_calcProductoBPEL. Calcula el producto de dos números reales.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_AreaEsfera.
SW_calcPotenciaBPEL.
SW_calcProductoBPEL.
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.7 Caso de prueba CSW-CP07
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización de combinación definidas y la ejecución del código en el motor de Oracle, de
acuerdo a las especificaciones del diseño de pruebas CSW-DP03 y CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, calcule el área de un elipse, utilizando un servicio Web simple que es independiente.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_calcProductoBPEL. Calcula el producto de dos números reales.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_AreaElipse.
SW_calcProductoBPEL.
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.8 Caso de prueba CSW-CP08
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización de combinación definidas y la ejecución del código en el motor de Oracle, de
acuerdo a las especificaciones del diseño de pruebas CSW-DP03 y CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, calcule el área de un trapecio, utilizando tres servicios Web simples que son
independientes.
Capítulo VI. Pruebas
93
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_calcSumarBPEL. Calcula la suma de dos números reales.
SW_calcProductoBPEL. Calcula el producto de dos números reales.
SW_calcDividirBPEL. Calcula la división de dos números reales.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_AreaTrapecio.
SW_calcSumarBPEL.
SW_calcProductoBPEL.
SW_calcDividirBPEL.
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.9 Caso de prueba CSW-CP09
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización complejas y la ejecución del código en el motor de Oracle, de acuerdo a las
especificaciones del diseño de pruebas CSW-DP02 y CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, realice la búsqueda de una palabra en un archivo de texto, utilizando tres
servicios Web simples que son independientes.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_oEscribirArchBPEL. Realiza la operación de escritura de archivo de texto.
SW_oLeerArchBPEL. Realiza la operación de lectura de un archivo de texto.
SW_oBuscarPalabraBPEL. Realiza la operación de buscar palabras de archivo.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_BusConPalabArch.
SW_oEscribirArchBPEL.
SW_oLeerArchBPEL.
SW_oBuscarPalabraBPEL.
Diagrama de actividad. Es modelado en el cliente WS SIDDOO y en el cual se define
la lógica del proceso
6.6.10 Caso de prueba CSW-CP10
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización de combinación definidas y la ejecución del código en el motor de Oracle, de
acuerdo a las especificaciones del diseño de pruebas CSW-DP03 y CSW-DP04.
Capítulo VI. Pruebas
94
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, calcule el volumen de un cilindro, utilizando dos servicios Web simples que son
independientes.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_calcPotenciaBPEL. Calcula la potencia “n” de un número real.
SW_calcProductoBPEL. Calcula el producto de dos números reales.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_VolumenCilindro.
SW_calcPotenciaBPEL.
SW_calcProductoBPEL.
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.11 Caso de prueba CSW-CP11
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización de combinación definidas y la ejecución del código en el motor de Oracle, de
acuerdo a las especificaciones del diseño de pruebas CSW-DP03 y CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, calcule el área de un rombo, utilizando dos servicios Web simples que son
independientes.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_calcProductoBPEL. Calcula el producto de dos números reales.
SW_calcDividirBPEL. Calcula la división de dos números reales.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_AreaRombo.
SW_calcProductoBPEL.
SW_calcDividirBPEL.
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.12 Caso de prueba CSW-CP12
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización complejas y la ejecución del código en el motor de Oracle, de acuerdo a las
especificaciones del diseño de pruebas CSW-DP02 y CSW-DP04.
Capítulo VI. Pruebas
95
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, realiza la verificación del contenido de un archivo de texto, si existen más de
cinco palabras envía un mensaje “Tu archivo tiene más de cinco palabras”, en caso contrario
manda el siguiente mensaje “Tu archivo tiene menos de cinco palabras” y si tu archivo tiene
las cinco palabras, entonces manda “Tu archivo tiene cinco palabras”; se utilizarán tres
servicios Web simples que son independientes.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_oEscribirArchBPEL. Realiza la operación de escritura en un archivo de texto.
SW_oLeerArchBPEL. Realiza la operación de lectura de un archivo de texto.
SW_oContarPalabrasBPEL. Realiza la operación de contar las palabras del archivo.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_VerificarArch.
SW_oEscribirArchBPEL.
SW_oLeerArchBPEL.
SW_oContarPalabrasBPEL.
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.13 Caso de prueba CSW-CP13
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización de combinación definidas y la ejecución del código en el motor de Oracle, de
acuerdo a las especificaciones del diseño de pruebas CSW-DP03 y CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, realiza la evaluación del promedio de cinco calificaciones; si el promedio es
mayor que 7; entonces manda un mensaje “Felicidades. Aprobaste amigo(a).”; si el promedio
es menor de 7; entonces manda otro mensaje “Lo siento! Reprobaste”, utilizando dos servicios
Web simples que son independientes.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_calcSumarBPEL. Calcula la suma de dos números reales.
SW_calcDividirBPEL. Calcula la división de dos números reales.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_EvaluarPromedio.
SW_calcSumarBPEL.
SW_calcDividirBPEL.
Capítulo VI. Pruebas
96
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.14 Caso de prueba CSW-CP14
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización simples y la ejecución del código en el motor de Oracle, de acuerdo a las
especificaciones del diseño de pruebas CSW-DP01 y CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, calcule el área de un prisma, utilizando dos servicios Web simples que son
independientes.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_calcProductoBPEL. Calcula el producto de dos números reales.
SW_calcDividirBPEL. Calcula la división de dos números reales.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_AreaPrisma.
SW_calcProductoBPEL.
SW_calcDividirBPEL.
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.15 Caso de prueba CSW-CP15
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización simples y la ejecución del código en el motor de Oracle, de acuerdo a las
especificaciones del diseño de pruebas CSW-DP01 y CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, calcule el volumen de un prisma regular, utilizando dos servicios Web simples
que son independientes.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_calcProductoBPEL. Calcula el producto de dos números reales.
SW_calcDividirBPEL. Calcula la división de dos números reales.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_VolumenPrisma.
SW_calcProductoBPEL.
SW_calcDividirBPEL.
Capítulo VI. Pruebas
97
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.16 Caso de prueba CSW-CP16
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización complejas y la ejecución del código en el motor de Oracle, de acuerdo a las
especificaciones del diseño de pruebas CSW-DP02 y CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, calcule el volumen de una esfera, utilizando tres servicios Web simples que son
independientes.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_calcPotenciaBPEL. Calcula la potencia “n” de un número.
SW_calcProductoBPEL. Calcula el producto de dos números reales.
SW_calcDividirBPEL. Calcula la división de dos números reales.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_VolumenEsfera.
SW_calcPotenciaBPEL.
SW_calcProductoBPEL.
SW_calcDividirBPEL
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.17 Caso de prueba CSW-CP17
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización complejas, y de combinación definida; y la ejecución del código en el motor de
Oracle, de acuerdo a las especificaciones del diseño de pruebas CSW-DP02, CSW-DP03 y
CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, calcule el área de la figura geométrica que desea: pentágono; triangulo; o
circulo; utilizando cuatro servicios Web simples que son independientes.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_calcPotenciaBPEL. Calcula la potencia “n” de un número.
SW_calcProductoBPEL. Calcula el producto de dos números reales.
SW_calcDividirBPEL. Calcula la división de dos números reales.
SW_calcTangenteBPEL. Calcula la tangente de un número real.
Capítulo VI. Pruebas
98
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_calcAreasGeom.
SW_calcPotenciaBPEL.
SW_calcProductoBPEL.
SW_calcDividirBPEL.
SW_calcTangenteBPEL.
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
6.6.18 Caso de prueba CSW-CP18
Evaluar la generación de código BPEL4WS correspondiente a estructuras de concurrencia y
sincronización de combinación definidas y la ejecución del código en el motor de Oracle, de
acuerdo a las especificaciones del diseño de pruebas CSW-DP03 y CSW-DP04.
El objetivo consiste en generar código BPEL que al ejecutarse en el servidor BPEL PM
de Oracle, calcule ecuaciones cuadráticas de segundo grado de la forma ax2 + bx + c = 0;
donde: a!=0; utilizando siete servicios Web simples que son independientes.
Elementos de prueba
Servicios Web. Son aplicaciones auto contenidas utilizadas para la composición de
servicios.
SW_calcPotenciaBPEL. Calcula la potencia “n” de un número.
SW_calcProductoBPEL. Calcula el producto de dos números reales.
SW_calcRestarBPEL. Calcula la resta de dos números reales.
SW_calcDividirBPEL. Calcula la división de dos números reales.
SW_calcValorAbsBPEL. Calcula el valor absoluto de un número.
SW_calcRaizBPEL. Calcula la raíz cuadrada de un número.
SW_calcSumarBPEL. Calcula la suma de dos números.
Documentos WSDL. Permiten llevar a cabo la configuración correcta de las
actividades del diagrama de actividad.
PSWC_EcuacCuadr.
SW_calcPotenciaBPEL.
SW_calcProductoBPEL.
SW_calcRestarBPEL.
SW_calcDividirBPEL.
SW_calcValorAbsBPEL.
SW_calcRaizBPEL.
SW_calcSumarBPEL.
Diagrama de actividad. Es modelado en el cliente WS-SIDDOO y en el cual se
define la lógica del proceso
Capítulo VI. Pruebas
99
6.7 Especificación del procedimiento de pruebas Propósito
En esta sección se describe el procedimiento general que se llevó a cabo para realizar cada
caso de prueba, según sus precondiciones y escenarios establecidos.
6.7.1 CSW- PD01 Composición de servicios Web en WS-SIDDOO
a) Crear los servicios Web simples
b) Modelar cada servicio simple en un proceso BPEL básico
c) Obtener el WSDL de cada servicio simple
Iniciar el servidor Oracle de la consola en http://localhost:8888/
Seleccionar Application Server Control
Verificar el servicio Web (Servicio Web BPEL)
Seleccionar home: OC4J
Seleccionar Servicios Web, elegir el SW creado
Seleccionar el WSDL del servicio Web
En el sistema WS-SIDDOO:
a) Registrar los servicios Web (flujos BPEL simples)
b) Buscar los servicios Web a componer
c) Definir el WSDL del servicio complejo (compuesto)
d) Definir los partners links (servicios Web simples)
e) Definir el WSDL compuesto, que se acaba de definir a través de la herramienta
f) Definir variables extras (opcional)
g) Modelar el proceso BPEL (crear diagrama de actividad que describe la lógica del
proceso)
h) Configurar cada elemento del diagrama actividad en relación a una actividad BPEL
(receive. assign, invoke, reply, wait, empty).
i) Dar clic en el botón componer ubicado en la interfaz de la herramienta,
automáticamente se genera el código BPEL.
j) Copiar el código BPEL generado.
k) Crear un proyecto BPEL en jDeveloper con el nombre del WSDL que se definió en la
herramienta WS-SIDDOO para el servicio compuesto.
l) Pegar el código BPEL en la etiqueta <source> y automáticamente se genera el
diagrama para el proceso BPEL construido en la herramienta.
m) Refrescar los WSDL de los partners links involucrados en el proceso generado.
n) Validar y compilar el proceso BPEL en jDeveloper.
o) Detonar (desplegar) el proceso.
p) Verificar en el servidor de Oracle.
q) Probar y obtener el resultado.
r) Comparar el resultado obtenido, con el definido en este plan de prueba.
s) Finalmente, si ambos resultados son iguales, la prueba se determinará exitosa; en caso
contrario se rechazará.
Capítulo VI. Pruebas
100
6.8 Resultados de las pruebas
En la tabla 12, se muestran los resultados obtenidos de las pruebas realizadas de acuerdo a las
especificaciones CSW-DP01; CSW-DP02; CSW-DP03 y CSW-CP04. Las tres primeras
especificaciones de diseño contemplan el proceso de generación de código BPEL a través de
las nuevas estructuras implementadas tales como: estructuras de concurrencia y sincronización
simples; estructuras de concurrencia y sincronización complejas; y estructuras de combinación
definidas. Estas nuevas estructuras utilizan los elementos UML: fork; join; estado objeto
(note); expresiones de resguardo (condiciones); y estado flujo, implementados en este trabajo
de tesis.
Los resultados de la generación de código BPEL se obtuvieron de acuerdo a la
representación visual del diagrama de actividad modelado en el cliente y del código BPEL
generado mediante el módulo de composición donde se implementaron los algoritmos para
generar el código BPEL correspondiente; el despliegue y ejecución de las pruebas se
realizaron sobre el servidor BPEL PM de Oracle cuyos resultados se resumen en la misma
tabla 12.
Tabla 12. Resultados obtenidos de las pruebas
Identificador Generación de código BPEL4WS Servidor BPEL PM Oracle
CSW-DP014 CSW-DP02
5 CSW-DP03
6 Despliegue Ejecución
CSW-CP01 No aplica No aplica CSW-CP02 No aplica No aplica CSW-CP03 No aplica No aplica CSW-CP04 No aplica No aplica CSW-CP05 No aplica No aplica CSW-CP06 No aplica No aplica CSW-CP07 No aplica No aplica CSW-CP08 No aplica No aplica CSW-CP09 No aplica No aplica CSW-CP10 No aplica No aplica CSW-CP11 No aplica No aplica CSW-CP12 No aplica No aplica CSW-CP13 No aplica No aplica CSW-CP14 No aplica No aplica CSW-CP15 No aplica No aplica CSW-CP16 No aplica No aplica CSW-CP17 No aplica CSW-CP18 No aplica No aplica
4 Estructuras de concurrencia y de sincronización simples 5 Estructuras de concurrencia y de sincronización complejas 6 Estructuras de combinación definidas
Capítulo VI. Pruebas
101
6.9 Análisis de los resultados
Al realizar cada uno de los casos de prueba especificados en CSW-DP01; CSW-DP02; CSW-
DP03; y CSW-DP04 y de acuerdo a los resultados que se muestran en la tabla 12 todos los
casos de prueba se concluyeron satisfactoriamente, logrando comprobar la hipótesis como
verdadera, ya que se logró la generación automática de código BPEL a partir de estructuras de
concurrencia y sincronización simples; complejas y de combinación definidas representadas
en un diagrama de actividad.
Así mismo, los casos de prueba CSW-CP01; CSW-CP15 y CSW-CP17 como se
muestran en la tabla 12 fueron concluidos satisfactoriamente como se esperaba dentro de los
alcances de esta tesis. Aunque si no se toman en cuenta los límites establecidos en este
proyecto como tomar en cuenta otros elementos del lenguaje BPEL, tales como: correlation
sets, se pueden generar errores en el sistema. Correlation sets evalúa la correspondencia entre
mensajes e interacciones con las instancias del proceso de negocio a las que pertenece.
Cuando el motor BPEL recibe un mensaje busca el proceso que puede manejarlo. Para realizar
esta búsqueda utiliza el conjunto de correlación que contiene los datos necesarios para realizar
la correspondencia entre el mensaje y el proceso que lo está esperando.
Sin embargo, los conjuntos de correlación son declarados dentro de bloques (scopes),
que son contenedores de otras actividades que agrupan una estructura funcional. Una de las
limitaciones del sistema WS-SIDDOO, es precisamente que no cuenta con elementos que
permitan agrupar en bloques o contenedores, el cual provee la posibilidad de utilizar los
manejadores de eventos, errores, compensación, variables y los conjuntos de correlación.
Para solucionar los conflictos tomando en cuenta las limitaciones del sistema, se
agregaron al proceso BPEL actividades empty y wait (actividades nulas y en espera de
tiempos) que sustituyeron a los conjuntos de correlación (correlation sets), dando oportunidad
a la recepción correcta de mensajes invocados desde los servicios instanciados en el proceso y
evitar estos problemas siempre y cuando el diseñador tome en cuenta las limitaciones del
sistema.
El resultado en el despliegue y ejecución de los casos de prueba fue concluido
satisfactoriamente. Cada uno fue probado conforme a las características y datos de entrada
definidos en las especificaciones.
Al finalizar la ejecución de pruebas, se afirma que un proceso BPEL representa la
lógica de negocio y la cual requiere de una estructura proporcionada en este caso por los
diagramas de actividad que definen las actividades y la interacción entre los métodos de los
servicios Web. Este diagrama de actividad puede ser modelado utilizando estructuras de
concurrencia y sincronización simples, complejas y de combinación definidas. JDeveloper
permitió desplegar y probar la ejecución de cada una de las pruebas de los procesos a través de
la consola del servidor de BPEL.
El desarrollo completo de las pruebas que dan soporte a la tabla de resultados se
describe en el anexo C de este documento de tesis.
102
Capítulo VII Conclusiones
La experiencia que se ha obtenido al término de este trabajo ha sido satisfactoria, se ha
alcanzado el objetivo definido como:
i) Generar de manera automatizada código en BPEL4WS, que tenga como entrada un
elemento del diagrama de actividad y que tenga como salida código en BPEL4WS
semánticamente equivalente al elemento de entrada. En particular, se incorporarán los
elementos: fork, join, mensajes de flujo, expresiones de resguardo, y note del diagrama
de actividad integrados en la interfaz del sistema WS-SIDDOO.
Para lograr este objetivo, se realizó una serie de actividades la cual permitió establecer
las correspondencias semánticas entre los lenguajes UML y BPEL4WS. Estas
correspondencias implementadas generan código BPEL que corresponden a los elementos de
un diagrama de actividad UML: fork, join, mensajes de flujo, expresiones de resguardo, y
note; en el cual se logró definir tres nuevas estructuras que contemplan procesos de
composición de concurrencia y sincronización; procesos de composición con actividades en
espera de tiempos o nulas; procesos con estructuras condicionales que generan la condición
asociada de manera automatizada y procesos con notas informativas que ayudan al usuario a
identificar la interacción entre las operaciones de los servicios, el envío y recepción de
mensajes.
Para probar la correcta generación de código BPEL a través de las nuevas estructuras
definidas, se ejecutaron 18 casos de pruebas de las cuales todas fueron concluidas
satisfactoriamente logrando correctamente la generación de código en BPEL4WS
correspondiente al diagrama de actividad y de acuerdo al análisis de los resultados obtenidos
se confirmó la hipótesis planteada y se demostró que “al modelar la interacción entre
servicios Web mediante estructuras de concurrencia y sincronización simples; complejas y de
combinación definidas a través de diagramas de actividad se puede generar de forma
automática código BPEL4WS”.
Capítulo VII. Conclusiones
103
En este trabajo de tesis se descubrió que las extensiones (perfiles UML) de los
diagramas de actividades pueden permitir modelar procesos de negocio dentro del ciclo de
vida de desarrollo de software.
La industria del software está dando un giro hacia las metodologías formales que
capturen mejor el conocimiento del negocio y que sean fáciles de implementar, más
declarativas y fundamentalmente adaptables a los cambios.
Los procesos de negocio son capaces de representar la lógica de negocio y su
optimización significa hoy, para cualquier empresa, la diferencia entre el éxito y el fracaso.
En este trabajo de tesis se realizó la extensión al sistema WS-SIDDOO en el cual se
implementaron los elementos UML (fork, join, mensajes de flujo, expresiones de resguardo, y
note) del diagrama de actividad en el módulo de composición para generar su correspondiente
código en BPEL, con este logro el sistema permite que el diseñador modele composiciones de
servicios que definan procesos de concurrencia y sincronización; composiciones con
actividades en espera de tiempos o nulas; composiciones con estructuras condicionales que
generen la condición asociada de manera forma automática y composiciones con notas
informativas que ayudan al usuario a identificar la interacción entre las operaciones de los
servicios, el envío y recepción de mensajes.
7.1 Aportaciones
La aportación principal de este trabajo de tesis es la extensión al sistema WS-SIDDOO y de
acuerdo a las pruebas ejecutadas permite generar código BPEL4WS de forma automática a
través de los elementos UML: fork, join, mensajes de flujo, expresiones de resguardo y note.
Se define estructuras concurrentes y de sincronización; procesos en espera de tiempos con
actividades nulas; estructuras condicionales que generan la condición asociada de manera
automatizada y procesos con notas informativas que ayudan al usuario a identificar las
actividades del proceso, el envío y recepción de mensajes, y la secuencia de la interacción del
proceso de negocio.
Otras aportaciones son:
I. Análisis de las correspondencias semánticas entre los elementos UML y las actividades
BPEL4WS.
II. El cliente WS-SIDDOO modela diagramas complejos.
III. Conexión válida de las notas informativas a través del servicio Web.
IV. WS-SIDDOO ofrece la capacidad necesaria para modelar procesos de negocio sin
limitar el uso de algún elemento UML integrado en la interfaz del sistema.
Capítulo VII. Conclusiones
104
7.2 Estado anterior y estado actual del sistema En la tabla 13, se presentan las características sobresalientes del estado anterior y actual del
sistema WS-SIDDOO. Tabla 13. Tabla comparativa del estado anterior y actual del sistema WS-SIDDOO
7.3 Trabajo futuro Como trabajo futuro se propone extender la gramática agregando elementos UML que
permitan agrupar en bloques o contenedores un conjunto de actividades o sub actividades para
definir manejadores de eventos; manejadores de fallos; manejadores de compensación.
Para evitar que el problema de correlación de mensajes mediante el uso de estructuras
concurrentes, se propone analizar e implementar elementos BPEL que permitan agrupar
actividades o sub actividades, tales como: throw, compensate, scope y pick.
Para eliminar la dependencia que existe con el motor de ejecución propia de Oracle se
propone realizar un estudio de factibilidad y diseño para un motor de ejecución. También se
propone realizar pruebas y comparaciones entre distintos motores con la finalidad de evitar la
dependencia que existe entre WS-SIDDOO y el motor de ejecución BPM de Oracle.
Para obtener procesos lógicos diseñados correctamente, se propone la creación de un
módulo que implemente un depurador de procesos para permitir validar el correcto modelado
de la lógica del proceso; el cual permitirá que el usuario evite tener errores antes de enviar el
código a la máquina de ejecución disponible.
WS-SIDDOO Anterior WS-SIDDOO Actual
Involucra cinco elementos gráficos UML. Involucra todos los elementos integrados en la
interfaz actual del sistema.
Implementa estructuras:
Secuenciales
Condicionales e iterativas
Implementa estructuras:
Secuenciales, condicionales e iterativas
Concurrencia y sincronización simple
Concurrencia y sincronización compleja
Combinación definida
No se permite modelar y generar el código
BPEL correspondiente a los símbolos
condicionales asociados a las estructuras
condicionales.
Se permite modelar y generar código BPEL
correspondiente a los símbolos condicionales
asociados a las estructuras condicionales.
Para las actividades <assign>, al configurar una
expresión Xpath el usuario define dicha
expresión sin apoyo de ventanas de
configuración.
Para configurar expresiones Xpath
correspondientes a las actividades wait , assign y las
condiciones, se cuenta con el apoyo de las ventanas
de configuración de forma más sencilla para el
usuario y así evitar que el usuario requiera tener un
conocimiento avanzado en expresiones XPath.
No permite el modelado de procesos que
involucren actividades en espera de tiempo y
fechas definidas.
Permite el modelado de procesos de negocio que
definan periodos de tiempo y fechas (wait).
No permite el modelado de proceso que
involucren actividades nulas (empty).
Permite el modelado de procesos de negocio que
definan actividades nulas (empty).
El servicio Web WS-SIDDOO no permite la
conexión de las notas en el modelado del
proceso BPEL.
El servicio Web WS-SIDDOO permite la conexión
de las notas informativas en el modelado del
proceso BPEL.
No permite la agregación y generación de
código BPEL de notas informativas al proceso
modelado BPEL.
Permite la agregación y generación de código BPEL
de las notas informativas al proceso modelado como
ayuda para el diseñador.
105
Referencias
[SER02] WikiPedia “Documentación libre”.: Servicio Web. Disponible en línea:
http://es.wikipedia.org/ wiki/Servicio_Web. [Citado: 2008/02/09]
[SPE03] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D.
Roller, D. Smith, S. Thatte, I. Trickovic, and S. Weerawarana.: Business Process
Execution Language for Web Services, BEA Systems, International Business Machines
Corporation. Microsoft Corporation, SAP AG, Siebel Systems. Version 1.1
Specification, 2003.
[ROM03] Román Castañeda, Javier.: Sistema Visual para el Diseño Detallado de Métodos de
Clases con UML. Laboratorio de Ingeniería de Software. Centro Nacional de
Investigación y Desarrollo Tecnológico. Cuernavaca, México. Tesis de Maestría en
ciencias. Marzo, 2003.
[VAS04] Vásquez Méndez, Isaac Moisés.: Generación de servicios web a partir de software
legado. Laboratorio de Ingeniería de Software. Centro Nacional de Investigación y
Desarrollo Tecnológico. Cuernavaca, México. Tesis de Maestría en ciencias.
Septiembre, 2004.
[GUZ06] Guzmán Ruíz, Mariana.: Composición de servicios web. Laboratorio de Ingeniería de
Software. Centro Nacional de Investigación y Desarrollo Tecnológico. Cuernavaca,
México. Tesis de Maestría en ciencias. Marzo, 2006.
[SOL06] Solís M. Ismael.: Sistema de búsqueda y selección de servicios Web. Laboratorio de
Ingeniería de Software. Centro Nacional de Investigación y Desarrollo Tecnológico.
Cuernavaca, México. Tesis de maestría en ciencias, 2006.
[GYV07] De Gyvés Ávila, Silvana.: Composición de Servicios Web Utilizando Diagramas de
Actividad. Laboratorio de Ingeniería de Software. Centro Nacional de Investigación y
Desarrollo Tecnológico. Cuernavaca, México. Tesis de Maestría en ciencias. Diciembre,
2007.
[SAM05] Samper J.J.: Ontologías para servicios Web semánticos de información de tráfico:
descripción y herramientas de explotación. Departamento de Informática, Universidad
de Valencia. [Citado: 2008/04/07]
[MAJ04] Majithia S., Taylor I., Shields M., Wang I.: Triana as a Graphical Web Services
Composition Toolkit. Proceedings of the IEEE International Conference on Web
Services (ICWS'04), 514-524. IEEE Computer Society, 2004.
[ALV05] Alvez P., Foti P., Scalone M.: Generador de Aplicaciones Orquestadoras. Facultad de
Ingeniería de la Universidad de la República. 2005. [Citado: 2008/10/01]
[BAR06] Barrett R., Pahl C., Patcas L. M., Murphy J.: Model Driven Distribution Pattern Design
for Dynamic Web Service Compositions. ICWE’06, Palo Alto, California USA. ACM
1-59593-352-2/06/0007. July 2006.
[MAR05]
Martinez A., Patiño M., Jimenez R., Pérez F.: ZenFlow: A Visual Web Service
Composition Tool for BPEL4WS. Proceedings of the 2005 IEEE Symposium on Visual
Languages and Human-Centric Computing (VL/HCC'05), 00, 181-188, 2005.
[IGR07] iGrafx. A division of Corel, Inc.: President: Ken Carraher.: iGrafx. Disponible en línea:
http://www.igrafx.com/. [Citado: 2008/03/07]
[TIB06]
TIBCO The Power of Now.: TIBCO iProcess Suite. Disponible en línea:
http://www.tibco.com/software/business_process_management/iprocess_suite/default.js
p. [Citado: 2008/03/07].
Referencias
106
[CAS00a] Casati F., Ilnicki S., Jin L., Krishnamoorthy V., Shan M.: Adaptive and Dynamic
Service Composition in eFlow. Software Technology Laboratory. Hewlett-Packard
Laboratories, 1U-4A 1501 Page Mill Road Palo Alto. HPL- 2000-39. March, 2000.
[BEN02] Benatallah B., Dumas M., Fauvet C., Rabhi F., Sheng Q.: Overview of Some Patterns
for Architecting and Managing Composite Web Services. School of Computer Science
and Engineering, UNSW and Centre for IT Innovation, QUT, Brisbane QLD 4001,
School of Information Systems, UNSW, Sydney NSW 2052, Australia. August 2002.
[SHE02]
Sheng Q., Benatallah B., Dumas M., Mak E.: SELF – SERV: A Platform for Rapid
Composition of Web Services in a Peer -to- Peer Environment. School of Computer
Science & Engineering The University of New South Wales. Sydney NSW 2052,
Australia. Proceedings of the 28th VLDB Conference, Hong Kong, China, 2002.
[AMB03] Ambite J., Giuliano G., Gordon P., Decker S., Harth A., Jassar K., Pan Q., Wang L.:
Argos: An Ontology and Web Service Composition Infrastructure for Goods Movement
Analysis. Information Sciences Institute. School of Policy, Planning and Development
University of Southem California 4676 Admiralty Way, Marina del Rey, USA. 2003.
[PON02] Ponnekanti S., Fo A.: SWORD: A Developer Toolkit for Web Service Composition.
Proceedings of the 11th International World Wide Web conference, Honolulu, Hawai,
USA. Mayo, 2002. [Citado: 2008/09/21]
[UML04] UML.: Unified Modeling Language (UML) Specification: Infrastructure version 2.0.
[OMG07] OMG Object Management Group.: Disponible en línea : <Web site,
http://www.omg.org/>. UML Superstructure, Version 2 Specification. Disponible en
línea:<http://www.omg.org/spec/ UML/2/Superstructure/PDF>
[GIA08] Giachetti G., Marín B., Pastor O.: Perfiles UML y Desarrollo Dirigido por Modelos:
Desafíos y Soluciones para utilizar UML como Lenguaje de Modelado Específico de
Dominio. Centro de Investigación en Métodos de Producción de Software. Universidad
Politécnica de Valencia, España. ISSN 1988–3455 SISTEDES, 2008.
[GRO04] Gronmo R., Solheim I.: Towards Modeling Web Service Composition in UML.
INSTICC Press. Presented at The 2nd International Workshop on Web Services:
Modeling, Architecture and Infrastructure, Porto, Portugal. April, 2004.
[AAL03] Wil.M.P. v.d. Aalst.: Don’t go with the flow: Web services composition standards
exposed. Dept. of Technology Management, Eindhoven University of Technology.
Trends & Controversies Jan/Feb 2003 issue of IEEE Intelligent Systems, 2003.
[PET03] Petia Wohed., Wil M.P. v. d. Aalst., Dumas M.,H.M. ter Hofstede.: Pattern Based
Analysis of BPEL4WS. Queensland University of Technology, Australia. Technical
Report FIT-TR-2002-04, QUT 2003.
[KOR02] Korherr B., List B.: Extending the UML 2 Activity Diagram with Business Process
Goals and Performance Measures and the Mapping to BPEL. Institute of Software
Technology and Interactive Systems. Austrian Federal Ministry for Education, Science,
and Culture, and the European Social Fund (ESF) 31.963/46. July, 2002.
[BAS02]
Bastos R.M., Dubugras D. D. A.: Extending UML Activity Diagram for Workflow
Modeling in Production Systems. Proceedings of the 35th Hawaii International
Conference on System Sciences, 2002.
[UDD06] Consorcio UDDI.: UDDI. Disponible en línea: http://www.uddi.org/. [Citado:
2008/03/12]
[XML08a] WikiPedia “Documentación libre”.: Extensible Markup Language, 2008. [Citado:
2008/06/17] Disponible en línea: http://es.wikipedia.org/wiki/XML.
[XML08b] W3C Tecnologías XML 2005. World Wide Web Consortium.: Disponible en línea:
http:// www.w3c.es/ divulgacion/guiasbreves/tecnologiasXML. [Citado: 2008/06/18]
Referencias
107
[GRA02] GRAHAM S. et al. Web Services and his applications with Java. SAMs publishing
2002. ISBN 0-672-32181-5.
[W3C02] W3C Note.: Simple Object Access Protocol (SOAP) 1.1. Disponible en línea: http://
www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383494. [Citado 2008/02/03]
[PER02] Peris P., Belenguer N.: Facultad de Informática - Universidad Politécnica de Valencia.:
Servicios Web. Disponible en línea: http://www.dsic.upv.es/asignaturas/facultad/
lsi/trabajos/272002.doc. [Citado: 2008/02/09]
[WIK08] WikiPedia “Documentación libre”.: UDDI. Disponible en línea: http://es.wikipedia.org
/wiki/ UDDI. [Citado: 2008/03/18]
[CUB05]
Cubillos J.A., Burbano J.E., Corrales J.C., Ordóñez J.A.: Composición semántica de los
servicios Web. RCT-OnLine, Revista Colombiana de Telecomunicaciones (ISSN 1692-
1585). 2005. Universidad del Cauca, Popayán, Colombia.
[THO04] Erl Thomas.: Service-Oriented Architecture. A field Guide to Integrating XML and Web
Services. Publishing as Prentice Hall PTR 2004. P.61-62. ISBN 0-13-142898-5.
[PEL03] Chris Peltz.: “Web Services Orchestration and Choreography”, IEEE Internet
Computing, Octubre, 2003; Vol.36, Núm. 10. pp 46-77.
[MON06] MONTEJAVA S.L.: Ciclo de vida de un servicio Web. Disponible en línea: http://
www.montejava.es/articulo14.asp. [Citado: 2008/03/10]
[HRA04] Hrastnik, P. (2004).: Execution of business processes based on web services.
International Journal of Electronic Business. Vol.2 Num.5. pp. 550-556.
[FOW94] Fowler M., Scott K.: UML Gota a Gota. Editorial Pearson. Addison Wesley. ISBN:
9684443641. 1994.
[DAC08] Osmosis Latina.: Diagrama de actividad, 2005. Disponible en línea: http://www.
osmosislatina.com/lenguajes/ uml/actividad.htm. [Citado: 2008/06/16]
[MAR01] Marlon Dumas, Arthur H.M.: UML Activity as a Workflow Specification Language.
Cooperative Information Systems Research Centre. Queensland University of
Technology. Australia 2001. [Citado: 2008/06/19]
[IEE98]
IEEE, 1998. Software Engineering Technical Committee of the IEEE Computer Society.
IEEE Standard for Software Test Documentation. Aprobado el 16 de septiembre 1998.
108
Anexo A
Descripción de los escenarios de los casos de uso En este anexo se describen los escenarios de los casos de uso CU_01; CU_02; CU_03 y
CU_04; correspondientes al sistema general; y los casos de uso CU_03.5; CU_03.6; CU_03.7
que corresponden a la extensión del sistema, que se desarrolló en este trabajo de tesis.
ID: CU_01
Nombre de caso de uso: Buscar y seleccionar servicios Web
Creador: Maribell Orozco Ayometzi
Fecha de creación: 15/Feb/2009 Fecha de última modificación: 21/Feb/2009
Actores: Diseñador
Descripción: Buscar y seleccionar los documentos WSDL que describen los servicios
Web.
Precondiciones: El diseñador debe tener definida la funcionalidad que busca.
Postcondiciones: Conjunto de documentos WSDL de los servicios seleccionados por el
diseñador.
Escenario principal de
éxito:
1. Dar clic en el botón de buscar servicios de la interfaz del sistema
2. Llenar todos los campos necesarios con las características de la
funcionalidad de los servicios que desea
3. Dar clic en buscar
4. Se establece comunicación con la UDDI
5. Se obtienen los servicios indicados por el diseñador
6. El diseñador selecciona los servicios que satisfacen sus
requerimientos
Escenarios de fracaso
1:
1. Dar clic en el botón de buscar servicios de la interfaz del sistema
2. Llenar los campos necesarios con características no relacionadas
con el dominio seleccionado
Escenarios de fracaso
2:
1. Dar clic en el botón de buscar servicios de la interfaz del sistema
2. Dejar en blanco algunos campos necesarios para la búsqueda de los
servicios
Escenarios de fracaso
3:
1. Dar clic en el botón de buscar servicios de la interfaz del sistema
2. Llenar todos los campos necesarios con las características de la
funcionalidad de los servicios que desea
3. Dar clic en buscar
4. Se establece comunicación con la UDDI
5. No se obtienen los servicios con las características indicadas por el
diseñador, y se presenta un mensaje.
Includes:
Prioridad: Alta
Subcasos de uso:
Suposiciones: Para buscar y seleccionar se debe dar clic en el botón “Buscar servicios”,
que se encuentra en la interfaz del sistema.
Anexo A. Descripción de los escenarios de los casos de uso
109
ID: CU_02
Nombre de caso de uso: Modelar la interacción del proceso
Creador: Maribell Orozco Ayometzi
Fecha de creación: 15/Feb/2009 Fecha de última modificación: 19/Feb/2009
Actores: Diseñador
Descripción: Diseñar el diagrama de actividad en el cliente WS SIDDOO, que modela la
lógica del proceso a implementar.
Precondiciones: Haber seleccionado los servicios Web a componer que satisfacen sus
requerimientos
Configurar los partner links, métodos y variables del proceso BPEL, de
manera manual.
El diseñador ha seleccionado los servicios Web a integrar en la lógica del
proceso.
Postcondiciones: El proceso representado a través de un diagrama de actividad, que contiene
invocaciones a métodos de los servicios Web seleccionados.
El vector de conexiones y de símbolos que guardan información del
diagrama modelado en el cliente.
Escenario principal de
éxito:
1. Haber seleccionado los servicios Web a componer
2. Dibujar cada actividad del diagrama de actividad
3. Configurar cada actividad que representa la lógica del proceso, los
partner links, métodos y variables descritos en los documentos
WSDL analizados.
4. El diseñador dibuja las conexiones entre cada elemento gráfico del
modelo (diagrama de actividad)
5. El cliente WS SIDDOO envía el vector de conexiones al servicio
Web WS SIDDOO
6. El servicio Web valida las conexiones
Escenario de fracaso 1: 1. El diseñador dibuja los elementos del modelo (diagrama de
actividad)
2. Configura las actividades del modelo con las actividades
correspondientes en BPEL, partner links, métodos y variables
3. El diseñador dibuja una conexión inválida entre los elementos del
modelo (diagrama de actividad)
4. El cliente WS SIDDOO envía la conexión entre los elementos al
servicio Web
5. El servicio Web inválida la conexión y manda un mensaje de error
Escenario de fracaso 2: 1. El diseñador dibuja los elementos del modelo (diagrama de
actividad)
2. Configura incorrectamente las actividades del modelo con las
actividades correspondientes en BPEL
3. El diseñador desea dibujar una conexión cuando el elemento del
diagrama tiene todos sus conectores ocupados
Includes: CU_04
Prioridad: Alta
Suposiciones: Para configurar cada elementos se supone que se debe configurar los partner
links, métodos y variables, de acuerdo a los resultados del módulo
analizador de los documentos WSDL de los servicios.
Anexo A. Descripción de los escenarios de los casos de uso
110
ID: CU_03
Nombre de caso de uso: Generar código BPEL
Creador: Maribell Orozco Ayometzi
Fecha de creación: 15/Feb/2009 Fecha de última modificación: 21/Feb/2009
Actores: Diseñador
Descripción: Genera código BPEL a partir del modelo (diagrama de actividad) diseñado
en el cliente WS SIDDOO y validado en el servicio Web.
Precondiciones: Se debe tener el modelo (diagrama de actividad) configurado correctamente
de acuerdo a las actividades BPEL, que definen la lógica del proceso.
Postcondiciones: Código BPEL equivalente al modelo (diagrama de actividad) diseñado en el
cliente WS SIDDOO.
Escenario principal de
éxito:
1. Se modela el diagrama de actividad
2. Se configura cada elemento del modelo con actividades BPEL
3. Se selecciona el botón componer de la interfaz del sistema
4. El cliente de WS SIDDOO envía el vector de conexiones del
diagrama al módulo de composición
5. Se recorre el vector de conexiones para reconocer la estructura que
modela el diagrama de actividad
6. Se recorre el vector que almacenan variables, partner links y
espacios de nombre.
7. El módulo de composición genera el código BPEL y lo envía al
cliente WS SIDDOO.
8. El cliente WS SIDDOO lo muestra sobre una ventana al diseñador.
Escenarios de fracaso
1:
1. Se modela el diagrama de actividad
2. No se configura correctamente un elemento del modelo con una
actividad BPEL
3. Se selecciona el botón componer de la interfaz del sistema
4. El cliente de WS SIDDOO envía el vector de conexiones del
diagrama al módulo de composición
5. Se recorre el vector de conexiones para reconocer la estructura que
modela el diagrama de actividad
6. Se recorre el vector que almacenan variables, partner links y
espacios de nombre.
7. El módulo de composición genera el código BPEL incorrecto y lo
envía al cliente WS SIDDOO.
8. El cliente WS SIDDOO lo muestra sobre una ventana al diseñador.
9. El código no permitirá la devolución del resultado esperado.
Escenarios de fracaso
2:
1. El desarrollador selecciona componer servicios en el cliente WS
SIDDOO.
2. El cliente WS SIDDOO envía el vector de conexiones del diagrama
al módulo de composición.
3. El diagrama de actividad está incompleto.
4. No se puede recorrer el vector de conexiones.
5. No se puede generar código.
Includes: CU_03.1 Generar código encabezado
CU_03.2 Generar código para estructuras secuenciales
CU_03.3 Generar código para estructuras condicionales
CU_03.4 Generar código para estructuras iterativas
CU_03.5 Generar código para estructuras concurr./sincron. simples
Anexo A. Descripción de los escenarios de los casos de uso
111
CU_03.6 Generar código para estructuras concurr./sincron. complejas
CU_03.7 Generar código para estructuras de combinación definidas
Prioridad: Alta
Suposiciones: Se supone que antes de modelar el diagrama de actividad, se configura y se
seleccionan los WSDL que formaran parte del proceso.
ID: CU_03.5
Nombre de caso de uso: Generar código para estructuras concurrentes/sincronizadas simples
Creador: Maribell Orozco Ayometzi
Fecha de creación: 20/Feb/2009 Fecha de última modificación: 11/Marzo/2009
Actores: Cliente de WS-SIDDOO
Descripción: El módulo de composición genera código BPEL para estructuras
concurrentes y de sincronización simples (actividades internas como:
receive, invoke, assign y reply). Definiendo la etiqueta <flow>.
Precondiciones: 1. Se definió los partner links, variables del proceso.
2. Se definió el modelo de interacción entre los servicios del proceso.
3. Se configuró cada actividad del modelo (diagrama de actividad).
4. La clase amb_visual del cliente del WS-SIDDOO creó un objeto de
la clase CGeneraBPEL y le ha enviado el vector de conexiones.
Postcondiciones: 1. Código BPEL generado con estructuras concurrentes y de
sincronización que se definen con las etiquetas <flow> </flow>.
Escenario principal de
éxito:
1. El módulo de composición recorre el vector de conexiones.
2. Si encuentra una barra de división (Fork) define el inicio de una
estructura concurrente y de sincronización, se añade una etiqueta
<flow> al código BPEL.
3. Continua con la secuencia de actividades primitivas internas, en
este tipo de estructuras sólo se encuentran actividades tales como:
receive, invoke, assign y reply.
4. Encuentra una barra de unión (Join) que define el final de la
estructura concurrente y de sincronización, y se añade la etiqueta
</flow> al código BPEL.
Escenarios de fracaso
1:
1. El módulo de composición recorre el vector de conexiones.
2. Encuentra una barra de división (Fork) define el inicio de una
estructura concurrente y de sincronización, se añade una etiqueta
<flow> al código BPEL.
3. Continua con la secuencia de actividades primitivas internas, en
este tipo de estructuras sólo se encuentran actividades tales como:
receive, invoke, assign y reply.
4. No encuentra ninguna barra de unión (Join) conectada con las
actividades internas de la estructura en el modelo del proceso.
Escenarios de fracaso
2:
1. El módulo de composición recorre el vector de conexiones.
2. No encuentra ninguna barra de división (Fork) conectada con las
actividades internas de la estructura en el modelo del proceso.
3. No se puede generar código BPEL.
Escenarios de fracaso
3:
1. El módulo de composición recorre el vector de conexiones.
2. Falta alguna conexión en el modelo (diagrama de actividad).
3. No se puede recorrer todo el vector.
4. El código BPEL se genera incompleto.
Includes:
Anexo A. Descripción de los escenarios de los casos de uso
112
Prioridad: Media
Subcasos de uso:
Suposiciones: Todas las actividades fueron configuradas inicialmente de acuerdo a
operaciones en BPEL.
ID: CU_03.6
Nombre de caso de uso: Generar código para estructuras concurrentes/sincronizadas complejas
Creador: Maribell Orozco Ayometzi
Fecha de creación: 23/Feb/2009 Fecha de última modificación: 17/Marzo/2009
Actores: Cliente de WS-SIDDOO
Descripción: El módulo de composición genera código BPEL para estructuras
concurrentes y de sincronización complejas (actividades internas como:
receive, invoke, assign, reply, wait y empty; y estructuras secuenciales;
condicionales e iterativas). Definiendo la etiqueta <flow>.
Precondiciones: 1. Se definió los partner links, variables del proceso.
2. Se definió el modelo de interacción entre los servicios del proceso.
3. Se configuró cada actividad del modelo (diagrama de actividad).
4. La clase amb_visual del cliente del WS-SIDDOO creó un objeto de
la clase CGeneraBPEL y le ha enviado el vector de conexiones.
Postcondiciones: 1. Código BPEL generado con estructuras concurrentes y de
sincronización que se definen con las etiquetas <flow> </flow>, y
etiquetas de acuerdo a las estructuras internas definidas en el
modelo, como: <sequence>, <while>, <switch>.
Escenario principal de
éxito:
1. El módulo de composición recorre el vector de conexiones.
2. Si encuentra una barra de división (Fork) define el inicio de una
estructura concurrente y de sincronización, se añade una etiqueta
<flow> al código BPEL.
3. Continua con la secuencia de actividades primitivas y estructuradas
internas, en este tipo de estructuras se definen actividades tales
como: receive, invoke, assign, reply, wait y empty. Estructuras
internas como: <sequence>,<while>, <switch>.
4. Encuentra una barra de unión (Join) que define el final de la
estructura concurrente y de sincronización, y se añade la etiqueta
</flow> al código BPEL.
Escenarios de fracaso
1:
1. El módulo de composición recorre el vector de conexiones.
2. Encuentra una barra de división (Fork) define el inicio de una
estructura concurrente y de sincronización, se añade una etiqueta
<flow> al código BPEL.
3. Continua con la secuencia de actividades primitivas y estructuradas
internas.
4. No encuentra ninguna barra de unión (Join) conectada con las
actividades internas de la estructura en el modelo del proceso.
Escenarios de fracaso
2:
1. El módulo de composición recorre el vector de conexiones.
2. Encuentra una barra de división (Fork) define el inicio de una
estructura concurrente y de sincronización, se añade una etiqueta
<flow> al código BPEL.
3. No se definen internamente actividades estructuradas como:
condicionales e iterativas.
4. El código generado no pertenece a estructuras complejas.
Anexo A. Descripción de los escenarios de los casos de uso
113
Escenarios de fracaso
3:
1. El módulo de composición recorre el vector de conexiones.
2. Falta alguna conexión en el modelo (diagrama de actividad).
3. No se puede recorrer todo el vector.
4. El código BPEL se genera incompleto.
Includes:
Prioridad: Media
Subcasos de uso:
Suposiciones: Todas las actividades fueron configuradas inicialmente de acuerdo a
operaciones en BPEL.
ID: CU_03.7
Nombre de caso de uso: Generar código para estructuras de combinación definidas
Creador: Maribell Orozco Ayometzi
Fecha de creación: 15/Feb/2009 Fecha de última modificación: 22/Marzo/2009
Actores: Cliente de WS-SIDDOO
Descripción: El módulo de composición genera código BPEL para estructuras de
combinación definidas. Se definen actividades internas y externas como:
receive, invoke, assign, reply, wait, empty y estructuras secuenciales;
condicionales e iterativas. Se definen notas informativas al proceso.
Definiendo la etiqueta <flow>.
Precondiciones: 1. Se definió los partner links, variables del proceso.
2. Se definió el modelo de interacción entre los servicios del proceso.
3. Se configuró cada actividad del modelo (diagrama de actividad).
4. La clase amb_visual del cliente del WS-SIDDOO creó un objeto de
la clase CGeneraBPEL y le ha enviado el vector de conexiones.
Postcondiciones: 1. Código BPEL generado con estructuras concurrentes y de
sincronización que se definen con las etiquetas <flow> </flow>, y
etiquetas de acuerdo a las estructuras internas y externas definidas
en el modelo, como: <sequence>, <while>, <switch>.
Escenario principal de
éxito:
1. El módulo de composición recorre el vector de conexiones.
2. Si encuentra una barra de división (Fork) define el inicio de una
estructura concurrente y de sincronización, se añade una etiqueta
<flow> al código BPEL.
3. Continua con la secuencia de actividades primitivas y estructuradas
internas y externas, en este tipo de estructuras se definen
actividades tales como: receive, invoke, assign, reply, wait y
empty. Estructuras como: <sequence>,<while>, <switch>.
4. Encuentra una barra de unión (Join) que define el final de la
estructura concurrente y de sincronización, y se añade la etiqueta
</flow> al código BPEL.
Escenarios de fracaso
1:
1. El módulo de composición recorre el vector de conexiones.
2. Encuentra una barra de división (Fork) define el inicio de una
estructura concurrente y de sincronización, se añade una etiqueta
<flow> al código BPEL.
3. No se definen fuera de la estructura concurrente actividades
estructuradas como: condicionales e iterativas.
4. El código generado no pertenece a estructuras de combinación.
Escenarios de fracaso
2:
1. El módulo de composición recorre el vector de conexiones.
2. Falta alguna conexión en el modelo (diagrama de actividad).
3. No se puede recorrer todo el vector.
Anexo A. Descripción de los escenarios de los casos de uso
114
4. El código BPEL se genera incompleto.
Prioridad: Media
Suposiciones: Todas las actividades fueron configuradas inicialmente de acuerdo a
operaciones en BPEL.
ID: CU_04
Nombre de caso de uso: Analizar documentos WSDL
Creador: Maribell Orozco Ayometzi
Fecha de creación: 15/Feb/2009 Fecha de última modificación: 21/Feb/2009
Actores: CU_02. Modelar la interacción del proceso
Descripción: Extraer las descripciones de los servicios Web, como métodos, partner liks,
variables.
Precondiciones: Buscar y seleccionar los servicios a través de la interfaz del sistema.
El diseñador selecciona la actividad a configurar y el servicio Web a
componer.
Postcondiciones: Lista de características correspondientes al servicio Web seleccionado
(métodos, mensajes y partner links).
Escenario principal de
éxito:
1. La ventana de configuración (cliente WS SIDDOO) envía al
módulo analizador de WSDL la dirección de la descripción del
partner link seleccionado.
2. El módulo analiza el documento WSDL del servicio (ligado a un
partner link) y obtiene los datos necesarios para la composición.
3. El cliente WS SIDDOO extrae la información necesaria del
servicio.
Escenarios de fracaso
1:
1. La ventana de configuración (cliente WS SIDDOO) envía al
módulo analizador de WSDL la dirección de la descripción del
partner link seleccionado.
2. Se genera un error porque la dirección es incorrecta.
3. El módulo envía un mensaje de error al cliente WS SIDDOO.
Includes:
Prioridad: Alta
Subcasos de uso:
Suposiciones: Se supone que los servicios Web están habilitados o disponibles, y que los
documentos WSDL de los servicios Web contienen la definición de partner
links.
115
Anexo B
Descripción de las clases de la extensión a los
módulos composición y ventanas En este anexo se describen los métodos de las clases principales y de las clases implementadas
en el desarrollo de la extensión a los módulos composición y ventanas.
Clases del módulo composición A continuación se describen las clases que integran el módulo composición. Para más detalle
ver en [GYV07].
Clases Descripción
CBPELElementos Contiene vectores estáticos que almacenan información correspondiente a los
servicios, variables y partner links involucrados en el proceso de composición y
los métodos para recuperarla. Esta es una clase principal para la generación de
código BPEL.
CGeneraBPEL Define el orden de creación de objetos y la ejecución de métodos para la
generación del código en BPEL, a partir de un diagrama de actividad. Esta es
una clase principal para la generación de código BPEL. Se definen dos métodos:
CGeneraBPEL (Vector conexiones) y fnObtenerBPEL().
AGenElemento Es una clase abstracta que define el método fnGenera(), éste método abstracto se
implementa en sus clases derivadas.
CGenEncabezado Es una clase derivada de la clase AGenElemento. Implementa el método
fnGenera(), para la generación del código de la etiqueta <process>.
CGenPL Es una clase derivada de la clase AGenElemento. Implementa el método
fnGenera(), para la generación del código de definición de los partner links.
CGenVariable Es una clase derivada de la clase AGenElemento. Implementa el método
fnGenera(), para la generación del código de definición de las variables globales
del proceso.
CRecorreVect Inicializa la generación de código de la actividad principal del proceso BPEL.
La clase.
AStrategy Es una clase abstracta que define el método fnRecorre() e implementa el método
fnLlamaMetodos(). Contiene una función que hereda a todas sus clases
derivadas, con la que se aplica el patrón Composite. Esto permite crear nuevos
objetos de los tipos de las clases concretas para el recorrido del vector de
conexiones.
CActividad Es una clase derivada de la clase AStrategy. Implementa el método fnRecorre(),
para la generación de código correspondiente a las operaciones en BPEL
definidas en el diagrama de actividad. En esta clase se aplica el patrón de diseño
Composite.
CDecision Es una clase derivada de la clase AStrategy. Implementa el método fnRecorre(),
para generar las etiquetas que indican estructuras condicionales e iterativas. En
esta clase se aplica el patrón de diseño Composite.
CFin Es una clase derivada de la clase AStrategy. Implementa el método fnRecorre(),
para generar las etiquetas de fin de secuencia al final de la rama de una
condicional. En esta clase se aplica el patrón de diseño Composite.
CGeneraXML Es una clase que se encarga de generar el archivo bpel.xml, en el cual se
almacenan las URLs de los documentos WSDL de los servicios involucrados en
el proceso y se relacionan con su respectivo partner link.
Anexo B. Descripción de las clases de la extensión a los módulos composición y ventanas
116
Extensión al módulo composición A continuación se describen las clases que definen algoritmos para la generación de código de
estructuras de concurrencia y sincronización simples; complejas y de combinación definidas.
Clases Descripción Métodos Descripción
CFork Es una clase derivada de la clase
AStrategy. Realiza la generación de
código de estructuras de concurrencia y
sincronización de actividades
fnRecorre() Para recorrer el vector en busca del
siguiente elemento del diagrama.
fnRecorreFork() Para generar el código BPEL de las
estructuras concurrentes y de
sincronización. En esta clase se aplica
el patrón de diseño Composite.
CJoin Es una clase derivada de la clase
AStrategy. Realiza la generación de
código de estructuras de concurrencia y
sincronización de actividades
fnRecorre() Para recorrer el vector en busca del
siguiente elemento del diagrama.
fnRecorreJoin() Para generar las etiquetas de
estructuras concurrentes y de
sincronización. En esta clase se aplica
el patrón de diseño Composite.
CNota Es una clase derivada de la clase
AStrategy. Realiza la generación de
código BPEL de las notas informativas
del proceso.
fnRecorre() Para recorrer el vector en busca del
siguiente elemento del diagrama. En
esta clase se aplica el patrón de diseño
Composite.
Clases del módulo ventanas A continuación se presentan las clases que integran el módulo ventanas. Para más detalle ver
en [GYV07].
Clases Descripción
CVentanaCfg Crea una ventana de configuración, que permite al usuario configurar una
actividad del diagrama de actividad con relación a uno de los servicios
seleccionados y una operación en BPEL. Se agregaron las actividades BPEL
primitivas: wait y empty.
CAgregaVar Permite crear ventanas para la creación de variables para las actividades BPEL:
invoke, receive y reply.
CAgregaPL Permite crear una ventana para agregar un partner link al proceso a partir de un
servicio que haya sido previamente registrado, y configurar sus atributos en base a
los roles y tipos definidos en el documento WSDL del servicio.
CVentanaAsignacion Permite crear una ventana para seleccionar una variable o parte de ella desde un
árbol, para asignarla a otra variable dentro del proceso, así como definir
expresiones en el lenguaje XPath para obtener y manipular información.
CBVar Permite crear la ventana de búsqueda de variables, que permite buscar una
variable que fue previamente registrada, para relacionarla con la actividad en
BPEL que se está configurando.
Anexo B. Descripción de las clases de la extensión a los módulos composición y ventanas
117
Extensión al módulo ventanas A continuación se describen las clases que permiten al usuario configurar condiciones,
expresiones XPath 1.0 y notas al proceso modelado. Estas clases funcionan como soporte al
módulo de composición para la generación de código en apoyo a las nuevas estructuras
implementadas.
Clases Descripción
CCondicion Crea la ventana para configurar las condiciones en relación a las estructuras
condicionales e iterativas existentes en el sistema. A su vez todas las condiciones
generadas durante la configuración de las actividades y estructuras del diagrama
de actividad serán desplegadas al visualizar en pantalla el código BPEL y después
de dar clic en el botón de las condiciones integrado en la interfaz de la ventana
BPEL.
CVentanaExpresion Crea la ventana que permite construir la condición de las estructuras
condicionales e iterativas, a través de expresiones XPath 1.0.
CVentanaCondic Crea la ventana de despliegue para las condiciones de estructuras condicionales e
iterativas generadas durante el modelado de proceso.
CVentanaNota Crea la ventana para configurar la nota informativa del proceso modelado en el
cliente. Las notas permiten definir información relevante de las actividades del
proceso.
CVentanaBPEL Crea la ventana BPEL que presenta al usuario el código BPEL4WS editable y las
condiciones generadas a partir del diagrama de actividad. Al guardar este código
en un archivo, se genera de forma automática en la misma dirección, el archivo
BPEL.xml, en el cual se almacenan las direcciones de los partner links
involucrados en el proceso de composición.
118
Anexo C
Descripción de los casos de prueba En este anexo se describen los datos de entrada y los resultados esperados para cada uno de los
casos de prueba que se ejecutaron para evaluar el correcto funcionamiento de la extensión a
los módulos composición y ventanas.
I. Caso de prueba CSW-CP01
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado:
Conjunto Datos de entrada
1 9.0
2 12
3 4.5
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 53).
Figura 53. Diagrama de actividad CSW-CP01
Anexo C. Descripción de los casos de prueba
119
b) Especificación de salida
Los resultados de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de
acuerdo a los conjuntos de entrada descritos anteriormente: Conjunto Datos esperados
1 139.35
2 247.74
3 34.83
El código BPEL equivalente al diagrama modelado a través del cliente WS-SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 54).
Figura 54. Estructura de código BPEL esperado CSW-CP01
<sequence>
<receive …/>
<assign…> <copy> <from . . . /> <to . . . /> </copy> </assign>
<assign…> <copy> <from . . . /> <to . . . /> </copy> </assign>
<flow>
<sequence>
<invoke …/>
<receive …/>
<assign…> <copy> <from . . . /> <to . . . /> </copy> </assign>
<assign…> <copy> <from . . . /> <to . . . /> </copy> </assign>
<invoke …/>
<receive …/>
<assign…> <copy> <from . . . /> <to . . . /> </copy> </assign>
<assign…> <copy> <from . . . /> <to . . . /> </copy> </assign>
<invoke …/>
<receive …/>
<assign…> <copy> <from . . . /> <to . . . /> </copy> </assign>
<empty…/>
</sequence>
<sequence>
<assign…> <copy> <from . . . /> <to . . . /> </copy> </assign>
<assign…> <copy> <from . . . /> <to . . . /> </copy> </assign>
<invoke …/>
<receive …/>
<assign…> <copy> <from . . . /> <to . . . /> </copy> </assign>
<invoke …/>
<receive …/>
<assign…> <copy> <from . . . /> <to . . . /> </copy> </assign>
<assign…> <copy> <from . . . /> <to . . . /> </copy> </assign>
<empty…/>
<empty…/>
<empty…/>
<wait…/>
<invoke …/>
<receive …/>
<assign…> <copy> <from . . . /> <to . . . /> </copy> </assign>
</sequence>
</flow>
<invoke …/>
<receive …/>
<assign…> <copy> <from . . . /> <to . . . /> </copy> </assign>
<invoke …/>
</sequence>
Anexo C. Descripción de los casos de prueba
120
II. Caso de prueba CSW-CP02
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son:
Conjunto Datos de entrada
1 Radio: 9
Altura: 35
2 Radio: 4.3
Altura: 15
3 Radio: 8
Altura: 25
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 55).
Figura 55. Diagrama de actividad CSW-CP02
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Anexo C. Descripción de los casos de prueba
121
Conjunto Datos esperados
1 2968.81
2 290.44
3 1675.51
El código BPEL equivalente al diagrama modelado a través del cliente WS-SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 56).
Figura 56. Estructura de código BPEL esperado CSW-CP02
III. Caso de prueba CSW-CP03
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son:
Conjunto Datos de entrada
1 9
2 4.5
3 12
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 57).
<sequence>
<receive… />
<assign…> <copy> <from …/> <to …/> </copy> </assign>
<assign…> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive… />
<assign…> <copy> <from …/> <to …/> </copy> </assign>
<assign…> <copy> <from …/> <to …/> </copy> </assign>
<flow …/>
<sequence>
<assign…> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
<sequence >
<invoke …/>
<receive… />
<assign…> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</flow>
<invoke …/>
<receive… />
<assign…> <copy> <from …/> <to …/> </copy> </assign>
<assign…> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive… />
<assign…> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
</sequence>
Anexo C. Descripción de los casos de prueba
122
Figura 57. Diagrama de actividad CSW-CP03
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 254.46
2 63.61
3 452.39
El código BPEL equivalente al diagrama modelado a través del cliente WS-SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 58).
Figura 58. Estructura de código BPEL esperado CSW-CP03
<sequence >
<receive …/>
<assign…> <copy> <from …/> <to …/> </copy> </assign>
<assign…> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence>
<assign…> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
<sequence >
<invoke …/>
<receive…/>
<assign…> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</flow>
<invoke …/>
<receive…/>
<assign…> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
</sequence>
Anexo C. Descripción de los casos de prueba
123
IV. Caso de prueba CSW-CP04
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son: Conjunto Datos de entrada
1 Esta es una prueba
2 Departamento de ingeniería de software
3 Oracle Enterprise Manager 10g
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 59).
Figura 59. Diagrama de actividad CSW-CP04
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 4 Palabras en el archivo
2 5 Palabras en el archivo
3 4 Palabras en el archivo
4 0 Lo siento, el archivo está vacío
Anexo C. Descripción de los casos de prueba
124
El código BPEL equivalente al diagrama modelado a través del cliente WS-SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 60).
Figura 60. Estructura de código BPEL esperado CSW-CP04
V. Caso de prueba CSW-CP05
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son: Conjunto Datos de entrada
1 Base: 6
Altura: 20
2 Base: 10
Altura: 35
3 Base: 12
Altura: 48.5
<sequence>
<receive …/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<flow>
<sequence>
<empty …/>
</sequence>
<sequence>
<empty …/>
<empty …/>
<wait …/>
</sequence>
<sequence >
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/> <receive…/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/> <receive…/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<switch> <case condition= condition >
<sequence>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
</sequence> </case>
<case condition= condition >
<sequence>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</case></switch>
<empty…/>
</sequence>
</flow>
<invoke…/>
</sequence>
Anexo C. Descripción de los casos de prueba
125
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 61).
Figura 61. Diagrama de actividad CSW-CP05
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 60
2 175.0
3 291.0
El código BPEL equivalente al diagrama modelado a través del cliente WS SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 62).
Anexo C. Descripción de los casos de prueba
126
Figura 62. Estructura de código BPEL esperado CSW-CP05
VI. Caso de prueba CSW-CP06
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son:
Conjunto Datos de entrada
1 6
2 3
3 11.2
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 63).
<sequence>
<receive …/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence >
<assign …> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
<sequence>
<invoke …/>
<receive …/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</flow>
<invoke …/>
<receive …/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
</sequence>
Anexo C. Descripción de los casos de prueba
127
Figura 63. Diagrama de actividad CSW-CP06
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 452.39
2 113.09
3 1576.32
El código BPEL equivalente al diagrama modelado a través del cliente WS-SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 64).
Anexo C. Descripción de los casos de prueba
128
Figura 64. Estructura de código BPEL esperado CSW-CP06
VII. Caso de prueba CSW-CP07
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son:
Conjunto Datos de entrada
1 Radio1: 4
Radio2: 3
2 Radio1: 7.5
Radio2: 6
3 Radio1: 12
Radio2: 10.5
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 65).
<sequence>
<receive …/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive…/>
<empty…/>
</sequence>
<sequence>
<invoke …/>
<receive…/>
<empty …/>
<wait …/>
</sequence>
</flow>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive…/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
</sequence>
Anexo C. Descripción de los casos de prueba
129
Figura 65. Diagrama de actividad CSW-CP07
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 37.69
2 141.37
3 395.84
El código BPEL equivalente al diagrama modelado a través del cliente WS SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 66).
Anexo C. Descripción de los casos de prueba
130
Figura 66. Estructura de código BPEL esperado CSW-CP07
VIII. Caso de prueba CSW-CP08
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son: Conjunto Datos de entrada
1 Altura: 15
Base mayor: 20
Base menor: 10
2 Altura: 13
Base mayor: 18
Base menor: 11
<sequence>
<!—Nota: descripción de la nota !-->
<receive …/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence >
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<empty …/>
</sequence>
<sequence> <!—Nota: descripción de la nota !-->
<invoke …/>
<receive …/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</flow>
<invoke …/>
<receive …/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<switch>
<case condition= condition >
<sequence>
<empty…/>
</sequence>
</case>
<case condition= condition >
<sequence>
<wait…/>
</sequence>
</case>
</switch>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
</sequence>
Anexo C. Descripción de los casos de prueba
131
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 67).
Figura 67. Diagrama de actividad CSW-CP08
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 225.0
2 188.5
El código BPEL equivalente al diagrama modelado a través del cliente WS-SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 68).
Anexo C. Descripción de los casos de prueba
132
Figura 68. Estructura de código BPEL esperado CSW-CP08
IX. Caso de prueba CSW-CP09
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son:
Conjunto Datos de entrada
1 Texto: Este es un proceso BPEL, es una prueba
Palabra: es
2 Texto: Generación de código BPEL a partir de diagramas de actividad
Palabra: diagramas
<sequence>
<!—Nota: descripción de la nota !-->
<receive …/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
<sequence>
<invoke …/>
<receive …/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</flow>
<invoke …/>
<!—Nota: descripción de la nota !-->
<receive …/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<switch>
<case condition= condition >
<sequence>
<invoke…/>
<receive…/>
</sequence>
</case>
<case condition= condition >
<sequence>
<empty…/>
</sequence>
</case>
</switch>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
</sequence>
Anexo C. Descripción de los casos de prueba
133
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 69).
Figura 69. Diagrama de actividad CSW-CP09
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 2
2 1
El código BPEL equivalente al diagrama modelado a través del cliente WS SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 70).
Anexo C. Descripción de los casos de prueba
134
Figura 70. Estructura de código BPEL esperado CSW-CP09
X. Caso de prueba CSW-CP10
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son:
Conjunto Datos de entrada
1 Radio: 5
Altura: 12
2 Radio: 3.2
Altura: 8
3 Radio: 8.5
Altura: 25
<sequence>
<receive …/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence>
<empty …/>
</sequence>
<sequence>
<invoke …/> <receive…/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/> <receive…/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive…/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<switch>
<case condition= condition >
<sequence>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</case>
<case condition= condition >
<sequence>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</case>
</switch>
</sequence>
<sequence>
<empty … />
<empty … />
<empty … />
<wait …/>
</sequence>
</flow>
<invoke…/>
</sequence>
Anexo C. Descripción de los casos de prueba
135
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 71).
Figura 71. Diagrama de actividad CSW-CP10
a) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 942.47
2 257.35
3 5674.50
El código BPEL equivalente al diagrama modelado a través del cliente WS-SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 72).
Anexo C. Descripción de los casos de prueba
136
Figura 72. Estructura de código BPEL esperado CSW-CP10
XI. Caso de prueba CSW-CP11
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son:
Conjunto Datos de entrada
1 D: 5.02
d: 2.54
2 D: 7.4
d: 5.1
3 D: 15.2
d: 7.8
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 73).
<sequence>
<!—Nota: descripción de la nota !-->
<receive …/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<empty …/>
<empty …/>
</sequence>
<sequence>
<invoke …/>
<!—Nota: descripción de la nota !-->
<receive…/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<wait…/>
</sequence>
</flow>
<invoke …/>
<receive…/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<empty …/>
<invoke …/>
<receive…/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
</sequence>
Anexo C. Descripción de los casos de prueba
137
Figura 73. Diagrama de actividad CSW-CP11
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 6.37
2 18.87
3 59.27
El código BPEL equivalente al diagrama modelado a través del cliente WS-SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 74).
Anexo C. Descripción de los casos de prueba
138
Figura 74. Estructura de código BPEL esperado CSW-CP11
XII. Caso de prueba CSW-CP12
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son:
Conjunto Datos de entrada
1 Verifica cantidad de palabras en el archivo
2 Esto es una prueba
3 Es un archivo de texto
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 75).
<sequence> <!—Nota: descripción de la nota !-->
<receive …/>
<assign …> <copy…> <from …/> <to…/> </copy> </assign>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<flow>
<sequence>
<assign …> <copy> <from …/> <to…/> </copy> </assign> <!—Nota: descripción de la nota !-->
<empty …/>
</sequence>
<sequence>
<invoke …/>
<receive …/>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
</sequence>
</flow>
<invoke …/>
<receive …/>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<invoke …/>
</sequence>
Anexo C. Descripción de los casos de prueba
139
Figura 75. Diagrama de actividad CSW-CP12
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 Tu archivo tiene más de cinco palabras
2 Tu archivo tiene menos de cinco palabras
3 Tu archivo tiene cinco palabras
El código BPEL equivalente al diagrama modelado a través del cliente WS-SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 76).
Anexo C. Descripción de los casos de prueba
140
Figura 76. Estructura de código BPEL esperado CSW-CP12
XIII. Caso de prueba CSW-CP13
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son:
Conjunto Datos de entrada
1 7– 8.8 – 10 – 9.2 – 6
2 10 –9.9 – 8.3 – 9.5 – 9.0
3 6 – 7.2 – 7.8 – 6 – 6
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 77).
<sequence>
<receive…/>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<invoke …/>
<receive…/>
<flow>
<sequence>
<empty …/>
<empty …/>
<wait …/>
</sequence>
<sequence>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<invoke …/>
<receive…/>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<invoke …/>
<receive…/>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<switch>
<case condition= condition>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
</case>
<case condition= condition>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
</case>
<case condition= condition>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
</case>
</switch>
</sequence>
</flow>
<invoke …/>
</sequence>
Anexo C. Descripción de los casos de prueba
141
Figura 77. Diagrama de actividad CSW-CP13
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 8.2 Felicidades. Aprobaste amigo (a)
2 9.34 Felicidades. Aprobaste amigo (a)
3 6.6 Lo siento! Reprobaste.
El código BPEL equivalente al diagrama modelado a través del cliente WS SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 78).
Anexo C. Descripción de los casos de prueba
142
Figura 78. Estructura de código BPEL esperado CSW-CP13
<sequence>
<!—Nota: descripción de la nota !-->
<receive …/>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<flow>
<sequence>
<empty …/> <!—Nota: descripción de la nota !-->
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<wait …/>
</sequence>
<sequence>
<invoke …/>
<receive …/>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<invoke …/>
<receive …/>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<invoke …/>
<receive …/>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<invoke …/>
<receive …/>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
</sequence>
</flow>
<invoke …/>
<receive …/>
<assign …> <copy> <from …/> <to…/> </copy> </assign>
<switch>
<case condition= condition>
<sequence>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</case>
<case condition= condition>
<sequence>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</case>
</switch>
<invoke …/>
</sequence>
Anexo C. Descripción de los casos de prueba
143
XIV. Caso de prueba CSW-CP14
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son:
Conjunto Datos de entrada
1 Perímetro: 18
Apotema: 2.6
2 Perímetro: 42
Apotema: 3.3
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 79).
Figura 79. Diagrama de actividad CSW-CP14
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 23.40
2 69.3
El código BPEL equivalente al diagrama modelado a través del cliente WS-SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 80).
Anexo C. Descripción de los casos de prueba
144
Figura 80. Estructura de código BPEL esperado CSW-CP14
XV. Caso de prueba CSW-CP15
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son:
Conjunto Datos de entrada
1 Perímetro: 35
Apotema: 3
Base: 7
Altura: 25
2 Perímetro: 18
Apotema: 2.6
Base: 5
Altura: 9
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 81).
<sequence>
<receive …/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
<sequence>
<invoke …/>
<receive…/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</flow>
<invoke …/>
<receive…/>
<assign …> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
</sequence>
Anexo C. Descripción de los casos de prueba
145
Figura 81. Diagrama de actividad CSW-CP15
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 9187.5
2 1053.0
El código BPEL equivalente al diagrama modelado a través del cliente WS-SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 82).
Anexo C. Descripción de los casos de prueba
146
Figura 82. Estructura de código BPEL esperado CSW-CP15
XVI. Caso de prueba CSW-CP16
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son:
Conjunto Datos de entrada
1 Radio: 5
2 Radio: 2
3 Radio: 8
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 83).
<sequence>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<empty…/>
<wait…/>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
<sequence>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</flow>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
</sequence>
Anexo C. Descripción de los casos de prueba
147
Figura 83. Diagrama de actividad CSW-CP16
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 523.6
2 33.51
3 2144.66
El código BPEL equivalente al diagrama modelado a través del cliente WS-SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 84).
Anexo C. Descripción de los casos de prueba
148
Figura 84. Estructura de código BPEL esperado CSW-CP16
XVII. Caso de prueba CSW-CP17
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son:
Conjunto Datos de entrada
1 Altura: 7
Figura: pentágono
2 Altura: 24
Base: 8
Figura: triangulo
3 Radio: 2.5
Figura: circulo
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 85).
<sequence>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
</sequence>
<sequence>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</flow>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<empty…/>
<invoke…/>
</sequence>
Anexo C. Descripción de los casos de prueba
149
Figura 85.Diagrama de actividad CSW-CP17
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 84.30
2 96.0
3 19.63
El código BPEL equivalente al diagrama modelado a través del cliente WS-SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 86).
Anexo C. Descripción de los casos de prueba
150
<sequence>
<receive …/>
<sequence>
<switch>
<case condition = condition>
<sequence>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence >
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<empty…/>
<empty…/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<empty…/>
<empty…/>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
<sequence>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<wait…/>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<empty …/>
</sequence>
</flow>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</case>
<case condition = condition>
<sequence>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
Anexo C. Descripción de los casos de prueba
151
Figura 86. Estructura de código BPEL esperado CSW-CP17
XVIII. Caso de prueba CSW-CP18
a) Especificación de entrada
Los elementos de entrada para probar la funcionalidad correcta del módulo de composición de
servicios Web son:
Los conjuntos de datos de entrada en la consola del servidor BPEL PM de Oracle para
probar la ejecución del código BPEL generado son:
Conjunto Datos de entrada
1 Ecuación: 2x2 + 5x -12 =0
2 Ecuación: 7x2 - 3x -4 =0
3 Ecuación: 3x2 - 7x +2 =0
4 Ecuación: a2 – 5a + 6 =0
El diagrama de actividad modelado y configurado en el cliente WS-SIDDOO (ver
figura 87).
<assign> <copy> <from …/> <to …/> </copy> </assign>
<wait … />
</sequence>
</case>
<case condition = condition>
<sequence>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<empty … />
<invoke …/>
<receive …/>
<wait … />
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<wait … />
</sequence>
</case>
</switch>
</sequence>
<invoke … />
</sequence>
Anexo C. Descripción de los casos de prueba
152
Figura 87.Diagrama de actividad CSW-CP18
b) Especificación de salida
El resultado de la ejecución del código BPEL en el servidor BPEL PM de Oracle, de acuerdo a
los conjuntos de entrada descritos anteriormente:
Conjunto Datos esperados
1 X1 = 1.5; X2= -4.0
2 X1 = 1.0; X2= -0.5714
3 X1 = 2.0; X2= 0.3333
4 X1 = 3.0; X2= 2.0
El código BPEL equivalente al diagrama modelado a través del cliente WS-SIDDOO
para este proceso, deberá tener la siguiente estructura (ver figura 88).
Anexo C. Descripción de los casos de prueba
153
<sequence>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<switch >
<case condition= condition>
<sequence>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<empty …/>
</sequence>
</case>
<case condition= condition>
<sequence>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence >
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
</sequence>
<sequence >
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<empty …/>
</sequence>
</flow>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<switch>
<case condition= condition>
<sequence>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence >
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
Anexo C. Descripción de los casos de prueba
154
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
<sequence>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</flow>
<empty…/>
</sequence>
</case>
<case condition= condition>
<sequence >
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</case>
<case condition= condition>
<sequence >
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<empty …/>
</sequence>
<sequence >
<invoke …/>
Anexo C. Descripción de los casos de prueba
155
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</flow>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<flow>
<sequence>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<empty…/>
<empty…/>
<empty…/>
<wait…/>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
</sequence>
<sequence>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<empty…/>
<empty…/>
<empty…/>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<invoke …/>
<receive …/>
</sequence>
</flow>
Anexo C. Descripción de los casos de prueba
156
Figura 88. Estructura de código BPEL esperado CSW-CP18
<empty …/>
</sequence>
</case>
</switch>
<assign> <copy> <from …/> <to …/> </copy> </assign>
<assign> <copy> <from …/> <to …/> </copy> </assign>
</sequence>
</case>
</switch>
<invoke …/>
</sequence>
Recommended