Modelación Orientada al Proceso para SOA, Parte 3: Modelación de caso de uso

Cómo se definen casos de uso alineados a SOA

Aprenda cómo los arquitectos y analistas empresariales pueden especificar casos de uso que estén alineados a la Arquitectura Orientada a Servicios. Este artículo describe una técnica de modelación de caso de uso basada en la técnica de modelación de procesos descrita en la Parte 1. En esta serie, conozca una nueva técnica de descomposición de procesos empresariales que puede ayudar a especificar procesos empresariales alineados a una Arquitectura Orientada a Servicios (SOA).

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.



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.



29-07-2011

Introducción

En las Partes 1 y 2 de esta serie, aprendió un método de especificar modelos empresariales muy alineados a la arquitectura orientada a servicios (SOA) basada en arquitectura objeto. Esos modelos son más fieles a la solución propiamente dicha que se está implementando. Este artículo amplía el principio a la definición de los modelos de caso de uso.

La Parte 4 usará un ejemplo de estudio de caso de uso para ilustrar los conceptos de las tres primeras partes.

Aprenda una técnica de descomposición de casos de uso basada en el modelo de proceso que deja los casos de uso semejantemente alineados a la arquitectura objeto.

Por qué necesitamos modelos de caso de uso alineados a SOA

Se usa la modelación de caso de uso en proyectos de TI para capturar los requisitos funcionales de un sistema. Los modelos de caso de uso se basan en conceptos que soportan la reutilización, los cuales deben ajustarse bien a una arquitectura como SOA, que promueve la reutilización. Infelizmente, la mayoría de las técnicas de modelación de caso de uso utilizadas hoy se basan en conceptos que son anteriores a SOA y a la gestión de procesos empresariales (BPM), con las siguientes consecuencias:

  • Con demasiada frecuencia, los casos de uso se traducen en artefactos técnicos (como flujos y servicios), lo que lleva a sistemas mal proyectados que no proporcionan los beneficios de la SOA.
  • Por necesidad, los diseños frecuentemente involucran una nueva factorización de la estructura definida inicialmente en el modelo de caso de uso, lo que proporciona sistemas que implementan funciones que no se correlacionan fácilmente a los requisitos. La duración y utilidad de los casos de uso originales se reducen. La gestión de las expectativas de los clientes, eficiencia del proceso de entrega de TI, rastreabilidad de extremo a extremo, prueba y reutilización futura también son problemáticas.

Una alineación más cercana entre los modelos funcionales y la arquitectura tiene muchos beneficios. Facilita la comunicación entre los interesados en la empresa y los tecnólogos, acelera la entrega de proyectos y aumenta significativamente el potencial de reutilización. La reutilización en el área de requisitos puede corresponder directamente a la reutilización en la arquitectura.

Los modelos de caso de uso que usted desarrolla con la técnica descrita en este artículo pueden permanecer válidos y útiles más allá de la entrega. Corresponderán a los artefactos reales del sistema que se están entregando, como servicios, procesos o componentes de interfaz de usuario. Los modelos de caso de uso se pueden usar como referencia para nuevos proyectos que buscan la reutilización más allá de la duración de un único proyecto de entrega. Frecuentemente los casos de uso resultantes son análogos a servicios; por tanto, la especificación de los casos de uso es el primer paso de la especificación de servicios.

Modelación de caso de uso alineados a SOA

La Figura 1 muestra la estructura de descomposición de procesos propuesta en la Parte 1. Cada proceso pertenece a una de las capas. Los procesos sólo pueden llamar o suscribirse a eventos de subprocesos de las capas en sentido descendente, como indican las flechas. Cada proceso debe desconocer los procesos de las capas en sentido ascendente.

Figura 1. Infraestructura de descomposición de procesos
Infraestructura de descomposición de procesos

Relaciones "Incluye" y "Amplía"

Hay mucha confusión respecto a las relaciones Incluye y Amplía en un modelo de caso de uso, a qué significan y cómo se deben usar. La diferencia clave entre ellas radica en dónde está la conciencia de la relación — y es esa diferencia que determina la relación más adecuada para usar en una dada situación.

Incluye

Donde el Caso de Uso A incluye el Caso de Uso B, es A que "está enterado" de B. El Caso de Uso B no tiene conocimiento respecto a los usos de caso por los cuales está siendo incluido. En el flujo del Caso de Uso A, el Caso de Uso B es realizado enteramente antes que el Caso de Uso A continúe (aunque modifiquemos eso ligeramente en el caso de invocaciones del tipo "disparar y olvidar"). Luego el Caso de Uso A debe tratar correctamente de la salida y de las pos condiciones del Caso de Uso B (no importando si fue exitoso o fallado). Se debe usar la relación Incluye para evitar la repetición del mismo contenido en varios casos de uso — en otras palabras, para extraer funcionalidades comunes y permitir su reutilización.

Amplía

Donde el Caso de Uso B amplía el Caso de Uso A, es B que "está enterado" de A. El Uso de Caso A no está enterado de los casos de uso que lo amplían. Sin embargo, el Caso de Uso A debe definir un "punto de extensión" o más en su flujo. El caso de uso B, que está ampliando, efectivamente "escucha" el caso de uso A y es invocado en un punto de extensión específico. A diferencia de la relación Incluye, el Caso de Uso A ahora continúa sin aguardar la conclusión del Caso de Uso B (ya que no está enterado de su invocación) y, semejantemente, no trata de ninguna pos condición de éxito o falla. Es mucho menos común usar (o necesitar) la relación Amplía, pero ella puede ser muy útil al definir nuevas funcionalidades a añadir a un sistema ya existente o, lo que es más importante en el contexto de ese enfoque, definir el procesamiento basado en eventos.

Los procesos de consumidor — y todos los procesos de las capas inferiores — se implementan en la solución tecnológica. La capa de proceso manual o de "experiencia de cliente" es una capa virtual que muestra toda la actividad no automatizada en la empresa; ilustra como los procesos soportados por el sistema se ajustan a ese contexto.

Ahora puede usar la estructura de descomposición de procesos para impulsar la forma de definición de los requisitos. Cada proceso del modelo está especificado con más detalles en la forma de un caso de uso -- la estructura de casos de uso resultante duplica la estructura de descomposición de procesos.

  • Cada proceso corresponderá a un caso de uso del sistema (con excepción de los procesos manuales y de experiencia del cliente que están fuera de los límites del sistema).
  • La invocación de un subproceso es equivalente a un enlace de caso de uso incluye (consulte la barra lateral), lo que posibilita la definición del subproceso en un caso de uso separado que puede ser reutilizado por otros procesos en las capas arriba.
  • El enlace de caso de uso amplía puede ser adecuado para soportar conceptos de arquitectura basados en eventos.

    Por ejemplo: un proceso de corta duración genera un evento que resulta en el lanzamiento de un proceso de larga duración. El proceso de larga duración amplía el de corta duración, y el proceso de corta duración sigue sin enterarse del proceso de larga duración (consulte SOA Basada en Eventos en la Parte 1).

  • Las actividades automatizadas son equivalentes a pasos en los casos de uso en las capas más altas, aunque pueda haber excepciones a eso (descritas más adelante).

La aplicación de esos principios resulta en una estructura de casos de uso que también tiene capas, así como el modelo de proceso, como muestra la Figura 2.

Figura 2. Modelo de caso de uso en capas
Modelo de caso de uso en capas

Cada caso de uso define un proceso correspondiente con más detalles. También define las características del servicio que se usará para invocar ese proceso. Por ejemplo: las precondiciones y pos condiciones, entradas y salidas del caso de uso definen las dependencias del servicio, los límites y los requisitos de datos.

Procesos manuales y procesos de experiencia del cliente

La capa de "Procesos manuales y procesos de experiencia del cliente", en la parte superior de la Figura 1, se destina a establecer el contexto de los procesos de las capas inferiores. Es para mostrar cómo los procesos del sistema se ajustan al proceso empresarial global. Los procesos de esa capa quedan fuera de los límites del sistema y no describen funciones del mismo; por tanto, no hay necesidad de un caso de uso de sistema correspondiente.

Resumen del proceso

Además de los procesos manuales, procesos de experiencia del cliente y del modelo de caso de uso, un resumen del proceso de extremo a extremo es otra herramienta de comunicación útil para mostrar la secuencia global de casos de uso. El resumen es útil porque:

  • El modelo de casos de uso es estático; no muestra la secuencia en la cual se realizan los casos de uso. En modelos más simples, frecuentemente es posible inferir la secuencia, pero eso puede no ser posible en los modelos más complejos.
  • El modelo de experiencia del cliente sigue el principio de capas y, por tanto, no muestra ningún proceso por debajo de la capa de consumidor. Su valor radica en mostrar lo que el consumidor externo "ve," pero no actúa como un resumen para los interesados que necesitan revisar todo el modelo.

La notación elegida para el resumen puede variar, pero se debe tener cuidado al usar la BPMN pues puede dar a entender una precisión que no corresponde a la realidad. Por ejemplo: se puede usar una notación con el estilo de cadena de valor.

Casos de uso de procesos de consumidor

Los procesos de consumidor (consulte la Figura 1) se traducen sin problemas en la vista tradicional de un caso de uso porque enfocan la interacción entre los actores (usuarios finales o sistemas externos) y el sistema. Esos casos de uso incluyen procesos empresariales reutilizables (de corta o larga duración) en las capas abajo.

Casos de uso de larga y corta duración

Orquestación vs. encadenamiento de procesos

Un error frecuente en la modelación de caso de uso es la definición de relaciones entre los casos de uso para describir su secuencia de realización. Por ejemplo: debe iniciar la sesión en el sistema para enviar un pedido. Se deben describir las dependencias entre los casos de uso en las pre condiciones y pos condiciones, en lugar de modelarlas como una relación (el Inicio de Sesión no debe incluir Someter Pedido). El enlace de casos de uso para describir los procesos empresariales a veces es conocido como encadenamiento. No refleja el comportamiento real del sistema, lleva a modelos de caso de uso que son difíciles de entender y mantener y disfraza áreas en las cuales el sistema está realmente orquestando procesos.

Donde el sistema administra activamente las dependencias entre los casos de uso al invocarlos en secuencia (por ejemplo: en un proceso de flujo de trabajo), eso puede y debe ser modelado como un caso de uso que incluye otros casos de uso en una secuencia especificada. Es el sistema actúa como el controlador de proceso global, y no el usuario final.

LaParte 1 explicó que los procesos de corta y larga duración son ejecutados en la capa de procesos empresariales de la arquitectura, posiblemente por un motor de orquestación de proceso empresarial. En los casos de uso de corta y de larga duración, no hay Actor Principal; siempre son desencadenados por otros casos de uso y no involucran directamente ninguna interacción con el usuario. Todos los procesos describirán el procesamiento de sistema (inclusión) de otros casos de uso (por ejemplo: un caso de uso de proceso de larga duración puede incluir un caso de uso de actividad humana).

Los casos de uso de procesos de corta duración también pueden ser ampliados por un caso de uso de proceso de larga duración como resultado de un evento que generan. Debe notar claramente — en el diagrama de procesos y en el flujo de casos de uso — donde se invoca un proceso en el modo "disparar y olvidar", ya que una relación de incluye tradicionalmente implica que el caso de uso incluido debe ser concluido antes de la continuación.

La equivalencia entre un caso de uso y un proceso de larga duración va en contra de las reglas tradicionales de identificación de casos de uso (un actor, un lugar, un momento). Se puede considerar un proceso de larga duración como un proceso de flujo de trabajo; puede aguardar la ocurrencia de un evento externo o bien llamar a una persona o más para que realice una tarea. Sin embargo, la información necesaria para especificar un proceso de larga duración es la misma que se necesita en otras especificaciones de caso de uso. Al representar el proceso de larga duración como un caso de uso, el modelo de casos de uso claramente representa las otras actividades que están siendo orquestadas por el proceso de larga duración (consulte la barra lateral).

Un proceso de larga duración desencadenado por un evento se describe junto con la relación amplía. Además de desencadenar el inicio de un proceso de larga duración, un evento también puede solicitar un proceso de larga duración que está esperando para continuar. Se propone que la relación amplía también debe ser usada para representar ese enlace de continuación. Así, se representan todas las dependencias basadas en eventos en el modelo de casos de uso. La Figura 3 muestra ejemplos de los diferentes usos de la relación "amplía".

Figura 3. Usos de la relación "amplía"
Usos de la relación

Se trata de una ligera modificación del significado tradicional de la relación amplía que es necesaria porque los procesos de larga duración rompen la regla usual "un actor, un lugar, un momento". Tal vez el término más significativo en esa instancia sea es informado por o espera por — pero vamos a dejar ese asunto antes que propongamos un nuevo estereotipo para ese fin.

Casos de uso de actividad humana

Así como en los procesos de consumidor, los casos de uso de actividad humana describen interacciones entre un usuario y el sistema. Una actividad humana, también conocida como actividad de flujo de trabajo, es iniciada por un proceso de larga duración y normalmente puede iniciar cuando un usuario selecciona la actividad en una lista de trabajos. Una vez concluida la actividad por parte del usuario, todo el procesamiento empresarial subsiguiente debe ser manejado por el proceso de larga duración. El ámbito de la actividad humana debe estar limitado a la interacción con el usuario. Las salidas del caso de uso de actividad humana (exitosas o no) deben ser detectadas y manejadas por el caso de uso de proceso de larga duración que lo incluyó.

Casos de uso de actividad automatizada

Normas empresariales
Las normas empresariales, definidas en conjunto con los casos de uso, proporcionan un mecanismo eficiente para definir una lógica empresarial reutilizable en todo el modelo de casos de uso. Las normas empresariales representan la lógica del sistema, normalmente para realizar una de las dos alternativas siguientes:

  • Derivación de datos (como el cálculo de una tarifa)
  • Toma de decisiones automatizada (verificar la elegibilidad o validar una transacción)

Las normas empresariales se documentan mejor separadas de los casos de uso (para posibilitar la reutilización), con referencias cruzadas entre la norma y cada paso de caso de uso que la utiliza.

Con ese enfoque, las normas empresariales son equivalentes a las actividades automatizadas en el modelo de procesos.

Por lo general, las actividades automatizadas corresponden a los pasos en los flujos de caso de uso (caso de ejemplo principal y flujos alternativos). Las actividades automatizadas pueden corresponder a las normas empresariales, referenciadas en los casos de uso, que luego pueden ser reutilizadas en operaciones de datos. Frecuentemente esas actividades automatizadas tienen una granularidad demasiado fina para justificar la existencia de un caso de uso referente a ellas.

Sin embargo, en algunos casos, puede ser útil definir una actividad automatizada como un caso de uso separado debido a sus propias características. Por ejemplo: una interfaz a un sistema externo que involucra una interacción compleja puede requerir la definición de varios pasos o flujos alternativos. Deben ser documentados como un caso de uso separado para facilitar la reutilización de la interfaz.

De los modelos de proceso y caso de uso a los modelos de servicio

Como aprendió en la Parte 1, los procesos de larga duración, procesos de corta duración y actividades automatizadas son invocados por un servicio. Los procesos de consumidor generalmente no lo son (ellos consumen servicios), exceptuándose donde se expone el proceso a un consumidor externo, como un asociado de negocios que usa una interfaz de empresa a empresa (B2B).

Si aplica la técnica de modelación de caso de uso descrita en este artículo, los casos de uso (con excepción de los casos de uso de consumidor) corresponderán a los servicios en la misma forma. Convenientemente, las especificaciones de casos de uso comparten muchas características de las especificaciones de servicio; se pueden considerar las especificaciones de caso de uso como una versión anterior de la especificación de servicios. Ambas tienen:

  • Un nombre exclusivo
  • Una meta o propósito
  • Entradas y salidas
  • Precondiciones y pos condiciones
  • Un flujo de proceso asociado
  • Dependencias de otros casos de uso o servicios

Conclusión

Procesos, servicios y operaciones de servicio

Los términos "proceso" y "servicio" frecuentemente son intercambiables: ambos cumplen un objetivo determinado y tienen entradas y salidas claramente definidas. Sin embargo, hay diferencias claras en la definición:

  • Un servicio define "qué" se está proporcionando, pero oculta el "cómo". Enfoca el objetivo y representa la interfaz y no la implementación.
  • Un proceso (empresarial) define los pasos y el flujo que son necesarios para prestar el servicio correspondiente. Se puede usar un modelo de proceso para definir cómo se está prestando un servicio. Los pasos individuales de un proceso pueden, por su turno, invocar otros servicios (de capa inferior).

La literatura sobre SOA frecuentemente menciona el término "operación de servicio". En términos estrictos, al adherir al estándar WSDL de servicios web, un servicio es una agrupación de operaciones de servicio. En nuestro artículo no aplicamos esa definición estricta: siempre que mencionamos la palabra "servicio", se puede intercambiarla con "operaciones de servicio". Sin embargo, eso significa que aún se necesita un paso adicional que identifica la descomposición de los servicios en operaciones de servicio.

En este artículo, aprendió cómo la técnica de descomposición de procesos de las partes 1 y 2 de esa serie puede ser aplicada también a los casos de uso. La identificación de los casos de uso se basa en modelos de proceso que están alineados a SOA. Los requisitos, según lo articulado en los casos de uso, se acercan mucho más a la implementación en la forma de servicios en una SOA.

Análisis empresarial y arquitectura de TI

La modelación de caso de uso alineada a SOA y basada en procesos, si es bien realizada, resulta en más fidelidad de la especificación de requisitos respecto a la solución real. Debido a su estrecha relación, es realizada mejor en conjunto por el analista empresarial y el arquitecto o bien por personas con gran habilidad en las dos áreas. Predecimos que la aplicación de técnicas como las de esa serie llevará a una confusión de las fronteras entre los roles de analista empresarial y arquitecto. Habrá una demanda cada vez mayor por personas con esas dos habilidades.

De arriba hacia abajo y de abajo hacia arriba

Se puede considerar el enfoque de modelación de caso de uso como un enfoque de arriba hacia abajo al diseño de la SOA, donde las operaciones de servicio son identificadas de acuerdo con el punto en el cual son necesarias. En el contexto del método de IBM para Modelación y Arquitectura Orientada a Servicios (SOMA), eso formaría parte del paso Descomposición de Dominio.

La cuestión de la elección de los servicios correctos por parte del analista o arquitecto depende de otros factores, como los servicios que ya son soportados por los sistemas ya existentes de la organización. En un entorno maduro de SOA, las informaciones acerca de los servicios están disponibles en un repositorio de servicios y pueden ser "incluidas" en modelos de requisitos funcionales. En entornos menos maduros, se necesita un análisis del sistema ya existente para entender totalmente lo que ya está disponible. En SOMA, correspondería a Análisis del Sistema Ya Existente.

No se pierda la Parte 4, que usará un estudio de casos de uso para ilustrar las técnicas de las tres primeras partes.


Agradecimientos

Los autores agradecen a Richard Solly, Pete Cripps, Bruce Anderson y Sunny Shah por sus comentarios constructivos sobre las versiones de este artículo.

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.
  • Modelación de Caso de Uso proporciona una introducción excelente al asunto y tiene recomendaciones prácticas importantes sobre el uso de relaciones incluye y amplía en el Capítulo 10.
  • "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=453872
ArticleTitle=Modelación Orientada al Proceso para SOA, Parte 3: Modelación de caso de uso
publish-date=07292011