Resumen - CENIDET · El resultado de este trabajo fue la definición de nuevas estructuras para...

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


estructura condicional doble; notas informativas; y su correspondencia en código BPEL .................... 46


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


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


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




vii




























Figura 85.Diagrama de actividad CSW-CP17 ..................................................................................... 149


Figura 87.Diagrama de actividad CSW-CP18 ..................................................................................... 152


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

http://es.wikipedia.org/wiki/Internet

http://es.wikipedia.org/wiki/ITU-T

http://es.wikipedia.org/wiki/Tiempo_real

http://es.wikipedia.org/wiki/Paralelismo

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].


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.


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.


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ó.


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


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.


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,


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


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.


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).


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].


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.


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.


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.


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.


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


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:


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).


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


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].

http://es.wikipedia.org/wiki/Internet

http://es.wikipedia.org/wiki/OASIS_%28organizaci%C3%B3n%29

http://es.wikipedia.org/wiki/Servicios_Web

http://es.wikipedia.org/wiki/WSDL


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


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"?/>


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.


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.


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).


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


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.


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,


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.


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


- 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


- fnRecorreCond() : void

- fnRecorreWhile() : void

CFin

+ CFin() : void


CFork

+ CFork() : void


CGenEncabezado

+ CGenEncabezado() : void


CGeneraBPEL

+ BPEL: StringBuffer

+ genBPEL: CRecorreVect

+ genEnc: AGenElemento

+ CGeneraBPEL() : void

+ fnObtenerBPEL() : void

CGenPL

+ CGenPL() : void


CGenVariable

+ CGenVariable() : void

+ fnGenera() : StringBufferCGenXML

# doc: Document

+ CGenXML() : void

+ fnGuardaXML() : void

CJoin

+ CJoin() : void


CRecorreVect

+ conexiones: Vector

+ anterior: Vector

+ siguiente: Vector

+ i: int


+ 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


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.


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


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.


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.


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”/>


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>


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.


<sequence>

<invoke…/>


</sequence>

<sequence>

<invoke … />

</sequence>

<sequence>


<invoke…/>

</sequence>

</flow>


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



<sequence>




Thh:mm:ss”/>

</sequence>

<sequence >

<invoke …/>

<switch>

<case condition= condition >

<sequence>

<assign>…</assign>

</sequence> </case>

</switch>

</sequence>

</flow>


<sequence>


</sequence>

<sequence>




Thh:mm:ss”/>

</sequence>

<sequence>


<invoke…/>

<switch>


<sequence>


</sequence>

</case>


<sequence>

<invoke…/>

</sequence>

</case>

</switch>


</sequence>

</flow>


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


<sequence>



</sequence>

<sequence>




Thh:mm:ss”/>

</sequence>

<sequence >


<invoke…/>

<switch>

<case condition= condition />


</case>


<switch>


<invoke…/>

</case>


<assign . . . >… </assign>

</case>

</switch>

</case>

</switch>


</sequence>

</flow>


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



<sequence>





Thh:mm:ss”/>

</sequence>

<sequence>

<invoke…/>

<switch>

<case condition= condition>

<assign . . . >… </assign>

</case>



</case>



</case>

</switch>


</sequence>

</flow>


<sequence>

<assign . . . >

<copy>

<from . . . /> <to . . . />

</copy>

</assign>


<invoke …/>

</sequence>

<sequence>

<while condition= condition >

<invoke…/>

<receive .../>

</while>



Thh:mm:ss”/>


</sequence>

</flow>


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>





Thh:mm:ss”/>

<invoke …/>

</sequence>

<sequence>


<invoke ..../>

<receive…/>


<invoke ..../>

<receive…/>

</while>


</sequence>

</flow>

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



<receive . . . />



<sequence>



</sequence>

<sequence>



“PnYnMnDTnHnMnS| CCYY-MM-

DD-Thh:mm:ss”/>

</sequence>

</flow>

<assign . . . > ... </assign>

<invoke ..../>

<switch>


<sequence>

<assign> … </assign>

</sequence>

</case>

</switch>


46


condicional doble; notas informativas; y su correspondencia en código BPEL


<receive . . . />



<sequence>




</sequence>

<sequence>



DD-Thh:mm:ss”/>

</sequence>

</flow>



<invoke ..../>

<switch>


<sequence>

<assign> …</assign>

</sequence>

</case>


<sequence>

<assign> … </assign>

</sequence>

</case>

</switch>


47


de selección en cascada; notas informativas; y su correspondencia en código BPEL


<receive . . . />


<switch>


<invoke .../>

</case>


<switch>



</case>



</case>

</switch>

</case>

</switch>




<sequence>

<invoke…/>




Thh:mm:ss”/>

</sequence>

<sequence>


</sequence>

</flow>

<reply…/>


48


estructura condicional iterativa (while); notas informativas; y su correspondencia en código BPEL


<receive . . . />



<sequence>


<invoke…/>




DD-Thh:mm:ss”/>

</sequence>

<sequence>

<invoke…/>

<switch>


<sequence>


</sequence>

</case>


<sequence>


</sequence>

</case>

</switch>

<invoke…/>

</sequence>

</flow>

<receive…/>

<assign>… </assign>


<invoke .../>

<receive .../>

</while>


<invoke…/>


49


estructura de selección múltiple; notas informativas; y su correspondencia en código BPEL


<receive . . . />


<switch>




<sequence>

<invoke…/>


</sequence>

<sequence>



DD-Thh:mm:ss”/>

</sequence>

</flow>

<invoke…/>

</case>



<invoke.../>


</case>


<assign>... </assign>


<invoke.../>

<assign>... </assign>

</case>

</switch>

<reply>


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.


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.


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»


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»


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.


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


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.


58


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 ( )


new CActividad ( )

void fnRecorre ( )



new CFin ( )

void fnRecorre ( )

StringBuffer fnGetBPEL ( )

Return BPEL


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.









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.






60


complejas

sd Diagrama de secuencia para estructuras de concurr./sincron. complejas

identifica :

CGeneraBPEL

obj : CActividadgenBPEL :

CRecorreVect

obj : CFork obj : CDecision obj : CFin


void fnIdentificaObj ( )

void fnCuentaES ( )

new CActividad ( )

void fnRecorre ( )


new CFork ( )

void fnRecorre ( )



new CActividad ( )

void fnRecorre ( )


new CDecision ( )

void fnRecorre ( )

void fnRecorreCond ( )


new CActividad ( )

void fnRecorre ( )


new CDecision ( )

void fnRecorre ( )



new CActividad ( )

void fnRecorre ( )


new CFin ( )

void fnRecorre ( )


Return BPEL


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.









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.






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


void fnIdentificaObj ( )void fnCuentaES ( )

new CActividad ( )

void fnRecorre ( )


new CFork ( )

void fnRecorre ( )



new CActividad ( )

void fnRecorre ( )


new CDecision ( )

void fnRecorre ( )void fnRecorreCond ( )


new CActividad ( )

void fnRecorre ( )


new CDecision ( )

void fnRecorre ( )





new CActividad ( )

void fnRecorre ( )


new CFork ( )

new fnRecorre ( )

void fnRecorreFork

void fnLlamaMetodos

new CActividad ( )

void fnRecorre ( )


new CDecision ( )

void fnRecorre ( )



new CActividad ( )

void fnRecorre ( )


new CFin ( )

void fnRecorre ( )


Return BPEL


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.


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


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


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


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.


68

Figura 40. Estructura concurrente y sincronización de combinación definida con una estructura condicional

simple externa y notas informativas


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


70

Figura 43. Estructura concurrente y sincronización de combinación definida con estructura externa de selección

en cascada y notas informativas


71

Figura 44. Estructura concurrente y sincronización de combinación definida con una estructura externa de

selección múltiple y notas informativas


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


AStrategy

+ BPELAux: StringBuffer

+ conector: pintaFlecha

+ conexion: DibujarS

+ control: pintaActi

+ copiar: boolean

+ empty: int

+ fnLlamaMetodos() : void


CActiv idad

# entradas: int

+ CActividad() : void

- fnCuentaES() : 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


- fnRecorreCond() : void

- fnRecorreWhile() : void

CFin

+ CFin() : void


CFork

+ CFork() : void


+ fnRecorreFork() : void

CGenEncabezado

+ CGenEncabezado() : void


CGeneraBPEL


+ genBPEL: CRecorreVect

+ genEnc: AGenElemento

+ CGeneraBPEL() : void

+ fnObtenerBPEL() : void

CGenPL

+ CGenPL() : void


CGenVariable

+ CGenVariable() : void


CGenXML

# doc: Document

+ CGenXML() : void

+ fnGuardaXML() : void

CJoin

+ CJoin() : void


+ fnRecorreJoin() : void

CRecorreVect

+ anterior: Vector


+ 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


ventanaN

identifica

genBPEL

genEnc

obj

obj

condicion

note

obj

obj

objobj

ventanaobj

analizador

obj

obj


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


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.


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)


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)


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.


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)


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


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


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.


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.


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.


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.


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



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.



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.


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.


CSW-CP04

CSW-CP06

CSW-CP09

CSW-CP12

CSW-CP16

CSW-CP17








Composición de servicios Web para generar código BPEL a

partir de estructuras de concurrencia y de sincronización

complejas.


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



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.



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.


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.


CSW-CP07

CSW-CP08

CSW-CP10

CSW-CP11

CSW-CP13

CSW-CP17

CSW-CP18








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.


88

6.5.5 CSW–DP04. Diseño de prueba para la ejecución de código en BPEL4WS



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.


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.


CSW-CP01 a 18


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.


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






de Oracle, calcule el volumen de un cono, utilizando tres servicios Web simples que son

independientes.

Elementos de prueba


servicios.


90

SW_calcPotenciaBPEL. Calcula la potencia “n” de un número real.





PSWC_VolumenCono.



SW_calcDividirBPEL








de Oracle, calcule el área de un círculo, utilizando dos servicios Web simples que son

independientes.

Elementos de prueba


servicios. SW_calcPotenciaBPEL. Calcula la potencia “n” de un número real.




PSWC_AreaCirculo.


SW_calcProductoBPEL





sincronización complejas y la ejecución del código en el motor de Oracle, de acuerdo a las



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.


91

Elementos de prueba


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.



PSWC_ContarPalabArch.

SW_oEscribirArchBPEL.

SW_oLeerArchBPEL.

SW_oContarPalabrasBPEL








de Oracle, calcule el área de un triangulo, utilizando dos servicios Web simples que son

independientes.

Elementos de prueba


servicios.





PSWC_AreaTriangulo.


SW_calcDividirBPEL.








92


de Oracle, calcule el área de una esfera, utilizando dos servicios Web simples que son

independientes.

Elementos de prueba


servicios.





PSWC_AreaEsfera.







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.


de Oracle, calcule el área de un elipse, utilizando un servicio Web simple que es independiente.

Elementos de prueba


servicios.




PSWC_AreaElipse.









de Oracle, calcule el área de un trapecio, utilizando tres servicios Web simples que son

independientes.


93

Elementos de prueba


servicios.

SW_calcSumarBPEL. Calcula la suma de dos números reales.





PSWC_AreaTrapecio.

SW_calcSumarBPEL.


SW_calcDividirBPEL.








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.

SW_oEscribirArchBPEL. Realiza la operación de escritura de archivo de texto.


SW_oBuscarPalabraBPEL. Realiza la operación de buscar palabras de archivo.



PSWC_BusConPalabArch.


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






94


de Oracle, calcule el volumen de un cilindro, utilizando dos servicios Web simples que son

independientes.

Elementos de prueba


servicios.





PSWC_VolumenCilindro.










de Oracle, calcule el área de un rombo, utilizando dos servicios Web simples que son

independientes.

Elementos de prueba


servicios.





PSWC_AreaRombo.


SW_calcDividirBPEL.








95


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.

SW_oEscribirArchBPEL. Realiza la operación de escritura en un archivo de texto.


SW_oContarPalabrasBPEL. Realiza la operación de contar las palabras del archivo.



PSWC_VerificarArch.


SW_oLeerArchBPEL.

SW_oContarPalabrasBPEL.








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.

SW_calcSumarBPEL. Calcula la suma de dos números reales.




PSWC_EvaluarPromedio.

SW_calcSumarBPEL.

SW_calcDividirBPEL.


96








de Oracle, calcule el área de un prisma, utilizando dos servicios Web simples que son

independientes.

Elementos de prueba


servicios.





PSWC_AreaPrisma.


SW_calcDividirBPEL.








de Oracle, calcule el volumen de un prisma regular, utilizando dos servicios Web simples

que son independientes.

Elementos de prueba


servicios.





PSWC_VolumenPrisma.


SW_calcDividirBPEL.


97








de Oracle, calcule el volumen de una esfera, utilizando tres servicios Web simples que son

independientes.

Elementos de prueba


servicios.

SW_calcPotenciaBPEL. Calcula la potencia “n” de un número.





PSWC_VolumenEsfera.



SW_calcDividirBPEL





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.


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.




SW_calcTangenteBPEL. Calcula la tangente de un número real.


98



PSWC_calcAreasGeom.



SW_calcDividirBPEL.

SW_calcTangenteBPEL.








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.



SW_calcRestarBPEL. Calcula la resta 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.



PSWC_EcuacCuadr.



SW_calcRestarBPEL.

SW_calcDividirBPEL.

SW_calcValorAbsBPEL.

SW_calcRaizBPEL.

SW_calcSumarBPEL.




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á.


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


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”.


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.


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]

http://www.uddi.org/

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:


2. Llenar los campos necesarios con características no relacionadas

con el dominio seleccionado


2:


2. Dejar en blanco algunos campos necesarios para la búsqueda de los

servicios


3:


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



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.


é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.


110

ID: CU_03

Nombre de caso de uso: Generar código BPEL



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.


é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.


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.


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


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


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>.


é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.


1:


2. Encuentra una barra de división (Fork) define el inicio de una



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.


2:


2. No encuentra ninguna barra de división (Fork) conectada con las


3. No se puede generar código BPEL.


3:


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:


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




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>.







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>.


éxito:





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>.





1:






internas.

4. No encuentra ninguna barra de unión (Join) conectada con las



2:





3. No se definen internamente actividades estructuradas como:

condicionales e iterativas.

4. El código generado no pertenece a estructuras complejas.


113


3:





Includes:

Prioridad: Media

Subcasos de uso:



ID: CU_03.7

Nombre de caso de uso: Generar código para estructuras de combinación definidas




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>.







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>.


éxito:






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>.





1:





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.


2:





114


Prioridad: Media



ID: CU_04

Nombre de caso de uso: Analizar documentos WSDL



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).


é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.


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


código de estructuras de concurrencia y

sincronización de actividades


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


código BPEL de las notas informativas

del proceso.


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>


<flow>

<sequence>

<invoke …/>

<receive …/>



<invoke …/>

<receive …/>



<invoke …/>

<receive …/>


<empty…/>

</sequence>

<sequence>



<invoke …/>

<receive …/>


<invoke …/>

<receive …/>



<empty…/>

<empty…/>

<empty…/>

<wait…/>

<invoke …/>

<receive …/>


</sequence>

</flow>

<invoke …/>

<receive …/>


<invoke …/>

</sequence>


120

II. Caso de prueba CSW-CP02



servicios Web son:


probar la ejecución del código BPEL generado son:


1 Radio: 9

Altura: 35

2 Radio: 4.3

Altura: 15

3 Radio: 8

Altura: 25


figura 55).



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:


121

Conjunto Datos esperados

1 2968.81

2 290.44

3 1675.51




III. Caso de prueba CSW-CP03



servicios Web son:




1 9

2 4.5

3 12


figura 57).

<sequence>

<receive… />

<assign…> <copy> <from …/> <to …/> </copy> </assign>


<invoke …/>

<receive… />



<flow …/>

<sequence>


</sequence>

<sequence >

<invoke …/>

<receive… />


</sequence>

</flow>

<invoke …/>

<receive… />



<invoke …/>

<receive… />


<invoke …/>

</sequence>


122






1 254.46

2 63.61

3 452.39




<sequence >

<receive …/>



<flow>

<sequence>


</sequence>

<sequence >

<invoke …/>

<receive…/>


</sequence>

</flow>

<invoke …/>

<receive…/>


<invoke …/>

</sequence>


123

IV. Caso de prueba CSW-CP04



servicios Web son:


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


figura 59).






1 4 Palabras en el archivo



4 0 Lo siento, el archivo está vacío


124




V. Caso de prueba CSW-CP05



servicios Web son:



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 >


<invoke …/> <receive…/>




<switch> <case condition= condition >

<sequence>


</sequence> </case>


<sequence>


</sequence>

</case></switch>

<empty…/>

</sequence>

</flow>

<invoke…/>

</sequence>


125


figura 61).






1 60

2 175.0

3 291.0

El código BPEL equivalente al diagrama modelado a través del cliente WS SIDDOO



126


VI. Caso de prueba CSW-CP06



servicios Web son:




1 6

2 3

3 11.2


figura 63).

<sequence>

<receive …/>



<flow>

<sequence >


</sequence>

<sequence>

<invoke …/>

<receive …/>


</sequence>

</flow>

<invoke …/>

<receive …/>


<invoke …/>

</sequence>


127






1 452.39

2 113.09

3 1576.32




128


VII. Caso de prueba CSW-CP07



servicios Web son:




1 Radio1: 4

Radio2: 3

2 Radio1: 7.5

Radio2: 6

3 Radio1: 12

Radio2: 10.5


figura 65).

<sequence>

<receive …/>



<flow>

<sequence>



<invoke …/>

<receive…/>

<empty…/>

</sequence>

<sequence>

<invoke …/>

<receive…/>

<empty …/>

<wait …/>

</sequence>

</flow>



<invoke …/>

<receive…/>


<invoke …/>

</sequence>


129






1 37.69

2 141.37

3 395.84




130


VIII. Caso de prueba CSW-CP08



servicios Web son:



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 …/>



<flow>

<sequence >


<empty …/>

</sequence>

<sequence> <!—Nota: descripción de la nota !-->

<invoke …/>

<receive …/>


</sequence>

</flow>

<invoke …/>

<receive …/>


<switch>


<sequence>

<empty…/>

</sequence>

</case>


<sequence>

<wait…/>

</sequence>

</case>

</switch>


<invoke …/>

</sequence>


131


figura 67).






1 225.0

2 188.5




132


IX. Caso de prueba CSW-CP09



servicios Web son:




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>


<receive …/>



<flow>

<sequence>


</sequence>

<sequence>

<invoke …/>

<receive …/>


</sequence>

</flow>

<invoke …/>


<receive …/>



<switch>


<sequence>

<invoke…/>

<receive…/>

</sequence>

</case>


<sequence>

<empty…/>

</sequence>

</case>

</switch>


<invoke …/>

</sequence>


133


figura 69).






1 2

2 1




134


X. Caso de prueba CSW-CP10



servicios Web son:




1 Radio: 5

Altura: 12

2 Radio: 3.2

Altura: 8

3 Radio: 8.5

Altura: 25

<sequence>

<receive …/>


<flow>

<sequence>

<empty …/>

</sequence>

<sequence>






<invoke …/>

<receive…/>


<switch>


<sequence>


</sequence>

</case>


<sequence>


</sequence>

</case>

</switch>

</sequence>

<sequence>

<empty … />

<empty … />

<empty … />

<wait …/>

</sequence>

</flow>

<invoke…/>

</sequence>


135


figura 71).


a) Especificación de salida




1 942.47

2 257.35

3 5674.50




136


XI. Caso de prueba CSW-CP11



servicios Web son:




1 D: 5.02

d: 2.54

2 D: 7.4

d: 5.1

3 D: 15.2

d: 7.8


figura 73).

<sequence>


<receive …/>



<flow>

<sequence>


<empty …/>

<empty …/>

</sequence>

<sequence>

<invoke …/>


<receive…/>


<wait…/>

</sequence>

</flow>

<invoke …/>

<receive…/>



<empty …/>

<invoke …/>

<receive…/>


<invoke …/>

</sequence>


137






1 6.37

2 18.87

3 59.27




138


XII. Caso de prueba CSW-CP12



servicios Web son:




1 Verifica cantidad de palabras en el archivo

2 Esto es una prueba

3 Es un archivo de texto


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 …/>


</sequence>

</flow>

<invoke …/>

<receive …/>


<invoke …/>

</sequence>


139






1 Tu archivo tiene más de cinco palabras

2 Tu archivo tiene menos de cinco palabras

3 Tu archivo tiene cinco palabras




140


XIII. Caso de prueba CSW-CP13



servicios Web son:




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


figura 77).

<sequence>

<receive…/>


<invoke …/>

<receive…/>

<flow>

<sequence>

<empty …/>

<empty …/>

<wait …/>

</sequence>

<sequence>


<invoke …/>

<receive…/>


<invoke …/>

<receive…/>


<switch>



</case>



</case>



</case>

</switch>

</sequence>

</flow>

<invoke …/>

</sequence>


141






1 8.2 Felicidades. Aprobaste amigo (a)

2 9.34 Felicidades. Aprobaste amigo (a)

3 6.6 Lo siento! Reprobaste.




142


<sequence>


<receive …/>



<flow>

<sequence>

<empty …/> <!—Nota: descripción de la nota !-->


<wait …/>

</sequence>

<sequence>

<invoke …/>

<receive …/>



<invoke …/>

<receive …/>



<invoke …/>

<receive …/>



<invoke …/>

<receive …/>


</sequence>

</flow>

<invoke …/>

<receive …/>


<switch>


<sequence>


</sequence>

</case>


<sequence>


</sequence>

</case>

</switch>

<invoke …/>

</sequence>


143

XIV. Caso de prueba CSW-CP14



servicios Web son:




1 Perímetro: 18

Apotema: 2.6

2 Perímetro: 42

Apotema: 3.3


figura 79).






1 23.40

2 69.3




144


XV. Caso de prueba CSW-CP15



servicios Web son:




1 Perímetro: 35

Apotema: 3

Base: 7

Altura: 25

2 Perímetro: 18

Apotema: 2.6

Base: 5

Altura: 9


figura 81).

<sequence>

<receive …/>



<flow>

<sequence>


</sequence>

<sequence>

<invoke …/>

<receive…/>


</sequence>

</flow>

<invoke …/>

<receive…/>


<invoke …/>

</sequence>


145






1 9187.5

2 1053.0




146


XVI. Caso de prueba CSW-CP16



servicios Web son:




1 Radio: 5

2 Radio: 2

3 Radio: 8


figura 83).

<sequence>

<receive …/>

<assign> <copy> <from …/> <to …/> </copy> </assign>


<flow>

<sequence>



<empty…/>

<wait…/>

<invoke …/>

<receive …/>


</sequence>

<sequence>

<invoke …/>

<receive …/>



<invoke …/>

<receive …/>


</sequence>

</flow>

<invoke …/>

<receive …/>


<invoke …/>

</sequence>


147






1 523.6

2 33.51

3 2144.66




148


XVII. Caso de prueba CSW-CP17



servicios Web son:




1 Altura: 7

Figura: pentágono

2 Altura: 24

Base: 8

Figura: triangulo

3 Radio: 2.5

Figura: circulo


figura 85).

<sequence>

<receive …/>



<flow>

<sequence>



<invoke …/>

<receive …/>

</sequence>

<sequence>

<invoke …/>

<receive …/>


</sequence>

</flow>


<invoke …/>

<receive …/>



<invoke …/>

<receive …/>


<empty…/>

<invoke…/>

</sequence>


149

Figura 85.Diagrama de actividad CSW-CP17





1 84.30

2 96.0

3 19.63




150

<sequence>

<receive …/>

<sequence>

<switch>

<case condition = condition>

<sequence>



<flow>

<sequence >



<invoke …/>

<receive …/>

<empty…/>

<empty…/>


<invoke …/>

<receive …/>



<empty…/>

<empty…/>

<invoke …/>

<receive …/>


</sequence>

<sequence>

<invoke …/>

<receive …/>



<invoke …/>

<receive …/>



<wait…/>

<invoke …/>

<receive …/>


<empty …/>

</sequence>

</flow>

<invoke …/>

<receive …/>


</sequence>

</case>


<sequence>



<invoke …/>

<receive …/>



<invoke …/>

<receive …/>


151


XVIII. Caso de prueba CSW-CP18



servicios Web son:




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


figura 87).


<wait … />

</sequence>

</case>


<sequence>




<empty … />

<invoke …/>

<receive …/>

<wait … />


<invoke …/>

<receive …/>


<wait … />

</sequence>

</case>

</switch>

</sequence>

<invoke … />

</sequence>


152

Figura 87.Diagrama de actividad CSW-CP18





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




153

<sequence>

<receive …/>


<switch >


<sequence>


<empty …/>

</sequence>

</case>


<sequence>




<flow>

<sequence >

<invoke …/>

<receive …/>



<invoke …/>

<receive …/>

</sequence>

<sequence >

<invoke …/>

<receive …/>


<empty …/>

</sequence>

</flow>


<invoke …/>

<receive …/>

<switch>


<sequence>



<invoke …/>

<receive …/>


<flow>

<sequence >



<invoke …/>

<receive …/>



<invoke …/>

<receive …/>


<invoke …/>

<receive …/>



154

<invoke …/>

<receive …/>


<invoke …/>

<receive …/>



<invoke …/>

<receive …/>



<invoke …/>

<receive …/>


</sequence>

<sequence>



<invoke …/>

<receive …/>



<invoke …/>

<receive …/>


</sequence>

</flow>

<empty…/>

</sequence>

</case>


<sequence >



<invoke …/>

<receive …/>



<invoke …/>

<receive …/>


</sequence>

</case>


<sequence >





<flow>

<sequence>

<invoke …/>

<receive …/>


<empty …/>

</sequence>

<sequence >

<invoke …/>


155

<receive …/>



<invoke …/>

<receive …/>


</sequence>

</flow>

<invoke …/>

<receive …/>


<invoke …/>

<receive …/>




<invoke …/>

<receive …/>



<flow>

<sequence>



<invoke …/>

<receive …/>




<empty…/>

<empty…/>

<empty…/>

<wait…/>

<invoke …/>

<receive …/>



<invoke …/>

<receive …/>

</sequence>

<sequence>



<empty…/>

<empty…/>

<empty…/>

<invoke …/>

<receive …/>



<invoke …/>

<receive …/>



<invoke …/>

<receive …/>

</sequence>

</flow>


156


<empty …/>

</sequence>

</case>

</switch>



</sequence>

</case>

</switch>

<invoke …/>

</sequence>

Resumen - CENIDET · El resultado de este trabajo fue la definición de nuevas estructuras para...

Documents

Transcript of Resumen - CENIDET · El resultado de este trabajo fue la definición de nuevas estructuras para...