Modelación Orientada al Proceso para SOA, Parte 4: Relacionando todo con un estudio de caso

Cómo su modelo de proceso impulsa los modelos de casos de uso y servicios

Aprenda cómo un modelo de proceso impulsa tanto un modelo de casos de uso como un modelo de servicios. Este artículo junta todo con un estudio de caso acerca de compras online que ilustra los conceptos de las partes anteriores de esta serie. En esta serie, aprenda una técnica nueva de descomposición de procesos empresariales que puede ayudar a especificar procesos empresariales que estén alineados a una Arquitectura Orientada a Servicios (SOA).

Mike Evans, Senior Managing Consultant, Business Analyst, IBM

Photo of Mike EvansMike es analista de negocios de IBM Global Business Services UK. Trabaja con clientes en programas de integración de sistemas complejos para ayudarlos a desarrollar requisitos para soportar sus objetivos empresariales y definir soluciones apropiadas.



Ruud Schoonderwoerd, Managing Consultant, IT Architect, IBM

Ruud Schoonderwoerd photoRuud Schoonderwoerd es consultor de administración y arquitecto de TI para IBM Global Business Services en el Reino Unido. Trabaja en programas grandes de TI en sitios de clientes de IBM, con enfoque en BPM, SOA y métodos de entrega.



05-08-2011

Introducción

En las Partes 1 y 2 de esta serie, aprendió un método de crear modelos de proceso muy alineados a la arquitectura orientada a servicios (SOA) destino. Los modelos son más fieles a la solución propiamente dicha que se está implementando. La Parte 3 amplía el principio, al describir una técnica de modelación de casos de uso basada en el modelo de procesos, que deja los casos de uso semejantemente alineados a la arquitectura destino.

Este artículo usa como ejemplo un estudio de caso de una compañía hipotética, Books R Us, para ilustrar los conceptos de las tres primeras partes de esta serie. Aprenda cómo un modelo de proceso impulsa tanto un modelo de caso de uso como un modelo de servicios.


Estudio de caso sobre compras online

La compañía ficticia Books 'R Us vende libros online. Los clientes pueden examinar el catálogo de libros en varias formas y hacer pedidos de libros desde el Web site de la compañía. Minoristas de terceros pueden hacer pedidos de libros con un interfaz de servicios web de empresa a empresa (B2B) y vincularlo a sus propios sistemas. Una vez que un cliente o socio de negocios hace un pedido a través de uno de esos canales, se atiende el pedido. La atención de pedidos involucra el proceso de pagos y la remesa de los productos al cliente. El estudio de caso trata de problemas específicos relacionados con pagos y stock que pueden ocurrir durante la atención.

Acerca de los ejemplos

Por una cuestión de brevedad, no todos los procesos están documentados pero se dan ejemplos en cada una de las capas de proceso. Donde un proceso y el caso de uso que lo acompaña están documentados, se les representan en negrita en los diagramas.

Se presentan los casos de uso en forma de esbozo, no en especificaciones de caso de uso totalmente detalladas. Por ejemplo: los flujos están resumidos y no se presentan como casos de ejemplo principal y alternativo, paso a paso y con detalles. No se han definido normas empresariales.

Los propios modelos de proceso se basan en la Notación de Modelación de Procesos Empresariales (BPMN) versión 1.1. La notación puede ser ligeramente distinta de la explicación de los patrones de procesos en la Parte 2, que usó la BPMN versión 1.0. Este artículo usa ciertas convenciones para dejar los diagramas tan claros y concisos como sea posible. El ejemplo usa los mismos íconos de la Parte 2, como se muestra a continuación.

Figura 1. Clave de los diagramas
Clave de los diagramas

Representando interacciones del usuario con BPMN 1.1

La notación BPMN tiene varias sutilezas. Aunque BPMN no haya sido proyectada para modelar interfaces de usuario, soporta varias formas de representar las interacciones de los usuarios. Para dejar las cosas más compactas, el caso de uso utiliza una notación que no está rigurosamente de acuerdo con el estándar BPMN. La Figura 2 muestra un ejemplo.

Figura 2. Notación de flujo de pantalla
Notación de flujo de pantalla

La notación, por una interpretación estricta del estándar BPMN, significa que se pueden elegir varios caminos en paralelo, pero no es eso que queremos decir. Esperamos que tenga en cuenta la alternativa en la Figura 2.


Capa de experiencia del cliente

La Figura 3 muestra el proceso de experiencia del cliente, que es la capa virtual. Por supuesto, la experiencia del cliente no se modela fácilmente como un proceso sin ambigüedades; se destina a mostrar los procesos del cliente dentro de un contexto.

Figura 3. Proceso de experiencia del cliente: Buscar Libros
Proceso de experiencia del cliente: Buscar Libros

Modelo de caso de uso

Las secciones posteriores de este artículo muestra la descomposición de procesos debajo del proceso de experiencia del cliente Buscar Libros y mostrar esbozos de casos de uso del sistema para cada proceso. El modelo de caso de uso resultante se muestra en la Figura 4 como un resumen. En realidad, es una salida del ejercicio de modelación y no el punto de partida.

Figura 4. Modelo de caso de uso de compras online (resultado final)
Modelo de caso de uso de compras online (resultado final)

Resumen del proceso

En la Figura 5, se ve una ilustración de la "cadena de valor" del proceso de extremo a extremo que muestra la secuencia de realización de los casos de uso.

Figura 5. Resumen del proceso de compras online
Resumen del proceso de compras online

Capa de proceso del consumidor

Esta sección repasa los casos de uso numerados en la sección de Proceso del Consumidor en la parte superior de la Figura 4.

Caso de Uso UC01: Seleccionar Producto

Los clientes inician el proceso en la tienda online, donde examinan libros y pueden insertar un libro en la canasta. Se puede repetir ese caso de uso para varios libros.

Meta
Seleccionar un producto y añadirlo a la canasta de compras.
Desencadenante
El usuario opta por examinar el catálogo de productos.
Actor principal
Cliente.
Precondiciones
El cliente está online.
Post-condiciones
Se añadió un producto a una canasta preexistente o a una recién creada si no hay una canasta ya disponible.

O bien, en el caso de tiempo de espera excedido, no sucede nada.

Flujo
Descripción del caso de uso
El sistema presenta al usuario las opciones de navegar por categorías o realizar una búsqueda. El usuario también puede seleccionar un producto para ver sus detalles. El caso de uso termina cuando el cliente opta por añadir un producto a su canasta de compras o como resultado del tiempo de espera excedido.

Caso de Uso UC02: Finalización de Compra Online

El cliente debe finalizar la compra tras terminar de poner los libros en la canasta.

Meta
Hacer un pedido referente a los libros que actualmente están en la canasta de compras.
Desencadenante
El usuario elige proseguir a la finalización.
Actor principal
Cliente.
Precondiciones
Debe haber un producto o más en la canasta de compras del cliente.
Post-condiciones
Se ha hecho un pedido referente a los elementos en la canasta.

O bien se ha hecho un pedido en el cual: el usuario no logra iniciar la sesión, no se han podido capturar exitosamente los detalles de entrega o de pago o se excedió el tiempo límite de la sesión.

Flujo
Descripción del caso de uso
Este caso de uso permite que el usuario haga un pedido referente a los elementos en la canasta de compras. El sistema primero asegura que el usuario está conectado y luego captura la dirección de entrega y los detalles de pago. El sistema muestra un resumen del pedido para que el usuario confirme. Una vez confirmado el pedido, se invoca el proceso de corta duración Hacer Pedido. Cuando se concluye Hacer Pedido con éxito, se muestra al usuario una confirmación final.
Incluye
UC04 Capturar Dirección Online, UC05 Capturar Detalles de Pago Online, UC10 Hacer Pedido, UC12 Iniciar Sesión

Caso de Uso UC03: Hacer Pedido de B2B

Books ‘R Us también soporta un canal de pedidos para sus asociados de negocios a través de una interfaz de B2B. Ese canal y el canal online utilizan el mismo caso de uso Hacer Pedido.

Meta
Hacer un pedido o más a través de una interfaz de B2B.
Desencadenante
Un socio de negocios de terceros envía un lote con dos pedidos o más.
Actor principal
Sistema minorista de terceros.
Precondiciones
Ninguna.
Post-condiciones
Se han realizado cero pedidos o más. Se ha retornado un lote de respuestas al sistema de terceros.
Flujo
Descripción de caso de uso
Este caso de uso permite que un minorista de terceros envíe pedidos a la librería a través de una interfaz de B2B. Los pedidos son extraídos del lote y procesados en turnos por el proceso de corta duración Hacer Pedido. Las respuestas son mezcladas y retornadas al sistema de terceros.
Incluye
UC10 Hacer Pedido

Capa de proceso de larga duración

Esta sección repasa el caso de uso en la sección de Larga Duración de la Figura 4.

Caso de Uso UC06: Atender Pedido

Cuando un nuevo pedido es hecho (por el caso de uso Hacer Pedido), se inicia el proceso de atención de pedidos. Se trata de un proceso de larga duración.

Meta
Enviar productos al cliente en respuesta al pedido que se hizo.
Desencadenante
Se ha hecho un nuevo pedido.
Actor principal
N/D
Precondiciones
Es necesario que se haya hecho un nuevo pedido.
Post-condiciones
Los elementos del pedido fueron registrados como enviados. Se cobró el pago del cliente. Se envió al cliente un anuncio de confirmación de envío.

O bien un elemento o más del pedido no está disponible o no se puede recibir el pago. Si cualquiera de ellos permanece sin resolución, el cliente recibe una confirmación de la cancelación del pedido.

O bien se modifica el pedido para tratar de los elementos no disponibles y para atenderlo en lo que respecta las otras post-condiciones.

Flujo
Descripción de caso de uso
Ese caso de uso representa un proceso de larga duración que orquesta las actividades para atender un pedido que se hizo. Si los elementos del pedido están en el stock, se invoca una Actividad Humana para enrutar el pedido al almacén para seleccionar y enviar los elementos adecuados y cobrar el pago. Luego se envía una confirmación al cliente y se actualiza el estado del pedido para registrar que fue atendido exitosamente.

Si los elementos del pedido no están en el stock pero son esperados, el proceso aguarda el reabastecimiento del stock.

Si los elementos del pedido no están en el stock y no son esperados, se invoca otra Actividad Humana para resolver la cuestión de los elementos no disponibles. Eso puede involucrar un contacto con el cliente para que se modifique el pedido.

Si hay problemas respecto a la captura de los detalles de pago, se invoca otra Actividad Humana para resolver los problemas de pago.

Si cualquiera de las actividades humanas no resulta en una resolución exitosa, aun así se envía una confirmación al cliente, pero con un contenido distinto. Por ejemplo: informará al cliente que se canceló el pedido.

Incluye
UC009 Seleccionar, Enviar, Recibir Pago, UC011 Resolver Elementos No Disponibles, UC012 Resolver Problemas de Pago

Capa de Actividad Humana

Esta sección explora los casos de uso en la capa de Actividad Humana en la Figura 4.

Caso de Uso UC07: Seleccionar, Enviar, Recibir Pago

Los principales aspectos de la atención de un pedido son seleccionar elementos en un almacén, recibir el pago y enviar las mercancías. Frecuentemente eso es hecho por una única persona; por tanto, se agrupa todo en una única actividad humana en el modelo de proceso.

Meta
Recibir el pago y enviar los elementos del pedido al cliente.
Desencadenante
Se asignó un pedido al usuario, quien lo selecciona en la lista de trabajo.
Actor principal
Seleccionador del pedido.
Precondiciones
Se pasa al proceso la ID de un pedido nuevo y válido.
Post-condiciones
Se ha recibido el pago y se han enviado los elementos del pedido.

O bien se ha congelado el pedido (y se ha informado la razón en el resultado que se pasó al proceso de larga duración que llama).

Flujo
Descripción de caso de uso
Ese caso de uso representa una Actividad Humana realizada por un empleado del almacén que selecciona las mercancías de los pedidos. El usuario registra cada elemento como seleccionados a medida que se encuentran los productos en el almacén. Una vez seleccionados todos los elementos, se procesa el pago del cliente y el sistema muestra los detalles de envío para que el seleccionador de los elementos del pedido envíe los elementos. El caso de uso termina cuando se confirma el envío.

Si hay elementos no disponibles o si el pago no es exitoso, se puede congelar el pedido y el caso de uso termina en una anomalía.

Caso de Uso UC08: Resolver Elementos No Disponibles

El proceso de larga duración Atender Pedido también tiene actividades humanas para resolver problemas en los pedidos. Uno de los problemas es la indisponibilidad de elementos en el almacén.

Meta
Resolver problemas de disponibilidad en el stock.
Desencadenante
El usuario selecciona un pedido en la lista de trabajo.
Actor principal
Corrector del pedido.
Precondiciones
Es necesario que se haya identificado un pedido que tiene un elemento indisponible o más.
Post-condiciones
Se modificó el pedido y se registró el problema como resuelto.

O bien se canceló el pedido.

Flujo
Descripción del caso de uso
Este caso de uso representa una Actividad Humana realizada por un representante de atención al cliente que resuelve problemas de disponibilidad en el stock. El usuario puede examinar la tienda en la intranet y buscar productos alternativos (tal vez mientras está en contacto con el cliente) y puede modificar el pedido para sustituir o eliminar los elementos no disponibles. El caso de uso termina cuando el cliente confirma que se resolvió el problema de los elementos no disponibles.

O bien el usuario puede seleccionar para cancelar el pedido.


Capa de proceso de corta duración

Esta sección repasa un caso de uso en el área de Corta Duración en la parte inferior de la Figura 4.

Caso de Uso UC10: Hacer Pedido

Hacer pedidos es un caso de uso central en nuestro caso de ejemplo. Ese proceso de corta duración sigue el patrón Ejecutar Transacción descrito en la Parte 2 de esta serie.

Meta
Validar y almacenar un pedido enviado.
Desencadenante
Se envía un pedido.
Actor Principal
N/D
Precondiciones
Se debe haber enviado el pedido de un producto o más.
Post-condiciones
Se ha almacenado un nuevo pedido.
Flujo
Descripción del caso de uso
Este caso de uso representa un proceso de corta duración que confirma los detalles de un pedido enviado y almacena el nuevo pedido listo para el procesamiento posterior. Las validaciones realizadas incluyen los detalles de producto, dirección y pago.

Si alguna validación falla, se retorna un mensaje de error al que llama. Si la validación es exitosa, se crea el pedido y se retornan sus detalles al que llama. El evento de nuevo pedido desencadena el procesamiento subsiguiente.


Modelo de servicio

Puede derivar el modelo de servicio directamente de las descomposiciones de procesos y casos de uso arriba. Todos los procesos debajo de la capa de proceso de consumidor se exponen a través de servicios. El proceso de consumidor Hacer Pedido B2B se expone como servicio a sistemas de terceros minoristas.

Los servicios en la capa de actividades automatizadas se identifican a partir de los pasos detallados en los procesos de las capas superiores. Se presupone que las Actividades Humanas son invocadas a través de una llamada de servicio. Se muestra el modelo de servicio resultante en la Figura 6.

Figura 6. Modelo de servicio para un escenario de Compras en Línea
Modelo de servicio para un escenario de Compras en Línea

Conclusión

En esta serie, aprendió una técnica basada en procesos para definir el formato de una solución orientada a servicios. Tratamos de la modelación orientada a procesos — de los mapas de procesos a los casos de uso y servicios. Los ejemplos del artículo describieron los resultados benéficos.

Alineación empresarial

Esa técnica proporciona modelos que pueden ser entendidos fácilmente por los interesados en la empresa, un hecho confirmado por la experiencia práctica del autor con la técnica. Cada proceso representa conceptos que deben resultar claros a los interesados que no son del área técnica. Por ejemplo: los procesos de consumidor representan los canales de la organización, los procesos de corta duración representan las transacciones que ellos soportan y los procesos de larga duración representan el flujo de trabajo. Todo eso puede ser soportado por los servicios en la forma de actividades automatizadas. Esa técnica lleva a mapas de procesos concisos, pero completos, que evitan la gran cantidad de conexiones confusas entre varias páginas.

Facilita la reutilización

El modelo de servicio en la Figura 6 demuestra la reutilización, en la cual varias flechas de invocación llegan al mismo servicio. Por ejemplo:

  • El servicio Hacer Pedido está siendo reutilizado por dos canales (online y B2B).
  • Varios servicios de Actividad Automatizada son reutilizados por varios procesos, como Obtener Detalles del Pedido.

El ejemplo está incompleto, pero se puede esperar que existan varias oportunidades de reutilización. Por ejemplo: si concluyó la transacción Modificar Pedido, puede esperar reutilizar algunos de los servicios de validación que Crear Pedido usó.

Mejor rastreabilidad

En la industria de TI, el hecho de demostrar que una solución hace lo que debe hacer es problemático. Normalmente, se resuelve ese problema en una de estas dos formas:

  • Los arquitectos frecuentemente proyectan una solución estrechamente alineada a la estructura de los requisitos, lo que en muchos casos toma la forma de un modelo de casos de uso. A menudo, la estructura es proyectada por analistas empresariales cuya preocupación principal es satisfacer a los clientes de la empresa. No tienen en cuenta la arquitectura de TI, lo que puede llevar a arquitecturas inadecuadas, inflexibles y arbitrarias.
  • Para evitar la situación mencionada arriba, los arquitectos proyectan soluciones separadas y mantienen matrices elaboradas y costosas de rastreabilidad para demostrar, de alguna manera, que se está cumpliendo con cada requisito. Los artefactos de rastreabilidad muchas veces son tan grandes, complejos y difíciles de administrar que ocultan las preguntas que deben contestar, como “¿Si pruebo esta parte del sistema, qué requisitos habré probado?” o ¿Se cumplió con todos los requisitos?"

La rastreabilidad resulta mucho más fácil si lo que se requiere es expresado en el contexto de la arquitectura que se adoptará para la solución. Se mejora mucho la rastreabilidad en los proyectos de SOA si los arquitectos y analistas empresariales trabajan en conjunto y usan la técnica de modelación orientada a procesos que se describió (en combinación con el análisis de los sistemas ya existentes).

Recursos

Aprender

  • Consulte las otras partes de esta serie:
    • La Parte 1 explora la técnica de descomposición de procesos para SOA en la cual se basa este artículo.
    • La Parte 2 da ejemplos de modelación de procesos a través de patrones de procesos empresariales.
    • La Parte 3 explica cómo se puede extender esa técnica a la modelación de casos de uso.
  • Los modelos de procesos de este artículo buscan adherir a la más reciente especificación del estándar BPMN (Notación de Modelación de Procesos Empresariales 1.1).
  • Los consultores y arquitectos de IBM Global Business Services tienen mucha experiencia en la aplicación de técnicas como ésa.
  • Use Case Modeling proporciona una introducción excelente a la modelación de casos de uso.
  • "Modelación y arquitectura orientada a servicios" (developerWorks, Noviembre de 2004) trata de los puntos destacados de ese asunto.

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=SOA y servicios web
ArticleID=453904
ArticleTitle=Modelación Orientada al Proceso para SOA, Parte 4: Relacionando todo con un estudio de caso
publish-date=08052011