Razones para usar el Modelo de Casos de Uso

Existe mucha controversia sobre el uso del Modelo de casos de uso como especificación funcional del desarrollo de una aplicación. A continuación daré una serie de razones para utilizarlo:

El usuario final aprueba el modelo de caso de uso para saber como va a actuar el sistema. Los usuarios potenciales utilizan el modelo de caso de uso para comprender mejor el sistema. El arquitecto de software utiliza el modelo de caso de uso para identificar la funcionalidad arquitectónicamente significativa. Los diseñadores utilizan el modelo de caso de uso para obtener una visión general del sistema. El gestor utiliza el modelo de caso de uso para planificar y hacer el seguimiento del modelado de caso de uso y también del diseño posterior. Las personas externas al proyecto pero dentro de la organización (ejecutivos, etc.), utilizan el modelo de caso de uso para obtener una perspectiva de lo que se ha llevado a cabo. Las personas revisan el modelo de caso de uso para proporcionar la información de retorno apropiada a los desarrolladores de forma regular. Los diseñadores utilizan el modelo de caso de uso como base para su trabajo. Los verificadores utilizan el modelo de caso de uso para planear las actividades de prueba (prueba de caso de uso y de integración) tan pronto como sea posible. Quienes desarrollarán la versión siguiente del sistema utilizan el modelo de caso de uso para comprender como funciona la versión existente. Los escritores de documentación utilizan los casos de uso como base para escribir los manuales de usuario del sistema.

 

Publicado con Blogsy

Ejemplo de Identificación de Servicios Funcionales

Ejemplo de Identificación de Servicios Funcionales en una aplicación de Seguros

Un ejemplo muy simplificado, que define la funcionalidad necesaria para realizar una consulta de Póliza, una consulta de Siniestros y una consulta de Recibos.

Funcionalidad requerida para la aplicación de seguros

• Habrá pólizas, habrá siniestros y habrá recibos.
• Habrá identificadores y datos diferentes para la póliza, para el siniestro y para el recibo.
• Tendremos nuestra red de oficinas y una entidad financiera como socio. Esta entidad financiera utilizará la Consulta de Póliza y Consulta de Recibo como ayuda en la toma de decisiones de cara a los créditos que conceden.

Primera aproximación para la aplicación de seguros

Como primera aproximación podría bastar con un único servicio:

• Consultar. Un único servicio que da soporte a toda la funcionalidad requerida. Permite consultar pólizas, siniestros y recibos.
  • Parámetros de entrada: Qué se desea consultar y el Identificador de lo que se desea consultar,
  • Parámetros de salida: Conjunto de datos que dependerá de lo que se ha decidido consultar.

Análisis de la primera aproximación para la aplicación de seguros

Si examinamos este servicio siguiendo los principios de identificación de servicios SOA, encontraremos lo siguiente:

• Sentido para el negocio: El servicio “consultar” es demasiado genérico, pero sí puede tener sentido para el negocio. Realmente en este caso, debería haber tres servicios:
  • Consultar Póliza.
  • Consultar Siniestro.
  • Consultar Recibo.
• No es modular. La funcionalidad de consultar una póliza puede ser semejante a consultar un recibo, pero los datos son distintos.

Por otra parte, tampoco logra un mínimo acoplamiento con sus clientes, ya que el mensaje de entrada hace referencia a una estructura común para todos los servicios. Esto añade dependencias que no son necesarias. Por ejemplo, un cambio en la consulta de póliza puede afectar a los clientes que no usan esta funcionalidad pero que usan el mismo servicio.

• No tiene el interfaz claramente definido. En el caso que se ha planteado, el parámetro de entrada es común, pero podríamos plantear otros tipos de consultas en los que como parámetro de entrada tuviéramos datos específicos dependiendo de la póliza, con lo que en ese caso, el interfaz debería ser específico.
• Seguridad. Al ser un único servicio no se puede limitar el acceso a diferentes clientes. Por ejemplo, necesitamos que nuestra red de oficinas pueda invocar las tres funcionalidades (consulta de Póliza, Siniestro, Recibo), mientras que nuestro socio (entidad financiera) no debería poder invocar a la consulta de Siniestro.

Cómo solo tenemos un servicio, no es posible lograr este nivel de autorización con los estándares de seguridad declarativa, teniendo que programar una solución ad-hoc para controlar el acceso de manera programática.

• Distribuible. Si bien el servicio “consultar” se puede implementar como un servicio web y por lo tanto es distribuible, no tiene toda la flexibilidad que nos podría aportar otro tipo de implementación. Es posible, por ejemplo, que la consulta de pólizas sea mucho mayor que la consulta de siniestros. Si en lugar de un solo servicio fuesen tres, se podría desplegar el servicio más demandado en una máquina más potente o en un mayor número de máquinas que el resto de servicios, logrando una mayor eficiencia y calidad de servicio de nuestra infraestructura.
• No es intercambiable. Al tener un solo servicio con un contrato poco definido nos impactaría mucho un posible cambio. Por ejemplo, en un hipotético caso, nuestra compañía compra un software estándar para la gestión de pólizas. Con una verdadera orientación a servicio, en el que las tres funcionalidades no estuviesen en el mismo servicio, sería sencillo cambiar el servicio de consultar póliza por este paquete comercial. Sin embargo, con esta implementación es muy difícil teniendo un impacto importante en el resto de funcionalidades que proporciona la empresa, estando expuestos a errores y pérdida de servicio. En realidad, un cambio en el servicio de consultar siniestro no tendría que afectar a la Entidad Financiera ya que no usa este servicio, pero no es así.
• No es compartible. Imaginémonos que nuestra organización llega a un acuerdo económico con otra empresa para proporcionarle pólizas. Esta nueva empresa tendrá que implementar la invocación a nuestro único servicio, teniendo que lidiar con parámetros (los de consultar siniestro y consultar recibo) que en realidad no le interesa para nada. Tal vez, en este caso, habría que decirle: tienes que mandarme 50 parámetros pero 40 tienen que venir vacios ya que no te hacen falta.

Aproximación definitiva para la aplicación de seguros

Teniendo en cuenta el análisis anterior y el sentido común, los servicios de negocio que se deberían implementar en la empresa del ejemplo, son:

• ConsultarPoliza: Un servicio que da soporte a la funcionalidad requerida para la consulta de pólizas.
• ConsultarSiniestro: Un servicio que da soporte a la funcionalidad requerida para la consulta de siniestros.
• ConsultarRecibo: Un servicio que da soporte a la funcionalidad requerida para la consulta de recibos.

Análisis de la aproximación definitiva de la aplicación de seguros

A diferencia respecto de la aproximación de un solo servicio, con el planteamiento de tres servicios:

• Sí tiene sentido para el negocio.
• Es modular, tiene cohesión (cada servicio se dedica a una cosa) y expone al consumidor únicamente la información que necesita (bajo acoplamiento).
• Cada uno de los servicios tiene el interfaz (el contrato con el cliente) claramente definido.
• Se puede securizar de manera independiente. Por seguridad declarativa se puede impedir el acceso desde la entidad financiera a la consulta de pólizas de auto.
• Es distribuible. Cada servicio se puede desplegar en una máquina diferente.
• Se puede sustituir un servicio por otra implementación sin afectar al resto.
• Lo puede invocar cualquier aplicación dentro o fuera de la organización.
• Se puede fácilmente construir (componer) un nuevo servicio más complejo a partir de los servicios anteriores.

Dificultades generales para identificar Servicios Funcionales

El camino para conseguir un buen catálogo de servicios está lleno de trampas. A continuación se describen algunos ejemplos comunes que se aplican a la identificación de servicios:

• Servicios sólo de nombre.

Los términos SOA y Servicio se utilizan con poco rigor en muchos entornos TI. Los equipos de proyecto etiquetan en ocasiones a sus aplicaciones como “orientada a servicios”, simplemente debido a la percepción errónea de que el uso de servicios Web constituye por sí solo una arquitectura SOA.

Se crean gran cantidad de servicios Web, sin tener en cuenta de la alineación con el negocio, reutilización o cualquier otra propiedad que un servicio debe tener. Esto lleva a una gran decepción cuando los beneficios esperados de SOA nunca llegan.

• Inexistencia de servicios perfectos.

En el otro lado del espectro está el peligro de tener analistas y arquitectos que modelan servicios maravillosos que simplemente no pueden ser construidos usando la tecnología actual. Esto se puede evitar a través del aseguramiento constante de que todos los esfuerzos de modelización se balancean con una dosis de realidad.

• Servicios de Babel.

Si una organización no tiene un modelo de datos canónico, los servicios son automáticamente incompatibles. El resultado es un entorno que dependerá de tecnologías de transformación y transición durante muchos años. Esto, en última instancia, inhibirá todos los aspectos de la orientación a servicios.

• Servicios Spaguetti.

Un problema que puede ocurrir cuando los servicios son definidos en múltiples niveles de granularidad es que la terminología técnica y la de negocio pueden estar tan mezcladas que los servicios pueden llegar a ser muy poco intuitivos, confusos y a veces, simplemente inutilizables.

Métodos para identificar Servicios Funcionales

En ocasiones los Analistas Funcionales tienen la necesidad de identificar los Servicios Funcionales que se necesitan para cubrir las funcionalidades descritas en los casos de uso.

A la hora de identificar servicios surgen las siguientes preguntas:

• ¿El servicio es demasiado genérico?
• ¿El servicio es demasiado específico?
• ¿El servicio tiene una granularidad demasiado grande?
• ¿El servicio tiene una granularidad demasiado pequeña?

Se mostrarán nueve métodos comunes para identificar y definir los servicios. A pesar de que estos métodos se describen por separado, en la práctica se pueden combinar.

• La descomposición de procesos de negocio.

Uno de los métodos más comunes para la identificación y la obtención de servicios, utiliza los procesos de negocio como punto de partida. El proceso de negocio se divide en sub-procesos o se descompone en actividades y tareas. Las tareas de menor nivel pueden estar formadas por pequeñas y cohesionadas “unidades lógicas de trabajo” que son soportadas por la funcionalidad que ofrecen distintos servicios.

Una gran ventaja de este enfoque es que los servicios resultantes tienen garantizado el ajuste con las necesidades funcionales de la organización. Este método es muy intuitivo, permitiendo a los equipos de proyecto usarlos para realizar pruebas de concepto y pilotos de proyectos.

Se puede dar una brecha entre procesos de negocio y aplicaciones si los servicios son sólo el modelo de negocio de acuerdo a las especificaciones de la definición del proceso y sin tomar en cuenta las consideraciones de implementación.

Además, a menos que se realice un esfuerzo de modelado en iterar a través de múltiples procesos empresariales, los servicios se pueden ajustar muy específicamente a las tareas y actividades de un proceso de negocio concreto, lo que da lugar a servicios que no se pueden reutilizar.

Incluso cuando se derivan los servicios de múltiples procesos, varias actividades pueden requerir funciones similares. Es necesario realizar una coordinación para evitar la redundancia entre los servicios definidos para los equipos de proyecto que trabajan en paralelo.

• Funciones del negocio.

Hay que tener en cuenta el contraste entre:

• La identificación de servicios basándose en un único proceso de negocio con lo que significa de estrecho vínculo entre el proceso y estos servicios.
• La idea subyacente de que los servicios deben proporcionar los medios para separar la lógica de negocio de servicios de TI.

Una posible solución a este problema es comenzar a partir de un modelo de las funciones de negocio. La identificación se abstrae de la forma en que los procesos de negocio se han implementado. Es similar al refinamiento paso a paso hacia los servicios desde el enfoque de proceso de negocio, sin embargo, en este caso la descomposición funcional de las funciones de negocio es lo que se traduce en servicios.

Conlleva los mismos riesgos que el anterior método.

• A partir del modelo de las entidades de negocio.

El propósito de la mayoría de los servicios es el procesamiento de la información de negocio. Al modelar servicios de acuerdo a los modelos de los objetos de negocio, suelen aparecer servicios del tipo CRUD. Debido a esto, se recomienda establecer modelos de datos canónicos que estandarizan el intercambio de datos entre servicios (se debe evitar que existan entidades que referencian la misma información con diferente estructura).

La dificultad principal de este método es la necesidad de modelos de datos estandarizados.

Nota: ¿Qué es un modelo de datos canónico?: Es un modelo que define la estructura de la información en una organización, siendo su objetivo no solo el limitarse a modelar los datos dentro de una sola base de datos, sino servir de referencia para todas las entidades y sus relaciones a través de todas las bases de datos de la empresa.

• Propiedad y Responsabilidad.

SOA requiere de una estructura bien definida para la toma de decisiones, dónde los roles y responsabilidades de los procesos y servicios están claramente distribuidas y asignadas. Cuando se identifican servicios, la parte que tiene la responsabilidad de poner a disposición la funcionalidad requerida determina qué servicios serán ofrecidos.

Los enfoques de diseño desempeñan un papel importante en este proceso, pero hay otras cuestiones que se deben tener en cuenta a la hora de decidirse por la opción final: Costes de desarrollo, costes de mantenimiento, gestión de ciclo de vida de las aplicaciones subyacentes, prioridades, disponibilidad de los recursos humanos, etc.

• Dirigido por objetivos de negocio (goal driven).

La mayor ventaja es que siempre está claro quién es propietario de un servicio. En otros métodos este tema puede convertirse en un punto de debate, e incluso puede derivar en consecuencias políticas. En el lado negativo, los servicios de diferentes ámbitos pueden acabar superponiéndose debido a la estructura de la propiedad requerida.

Con este enfoque, un equipo de proyecto descompone los objetivos de la empresa hasta el nivel de servicios. En este contexto, un servicio se considera como un objetivo que puede ser ejecutado a través de soporte automatizado. Por ejemplo, una meta como “aumentar la retención de clientes”, puede dar lugar a un servicio llamado “registro de clientes para el programa de fidelización”.

La ventaja es la fuerte relación establecida entre los servicios y la estrategia de la empresa. Sin embargo, surgen dos problemas: Los objetivos suelen ser subjetivos, y una buena cantidad de servicios tecnológicos no pueden ser directamente alienados con los objetivos de negocio.

La subjetividad puede provocar que dos objetivos de negocio se descompongan en dos servicios distintos, a pesar que la funcionalidad deseada es idéntica (lo que significa que hubiera sido preferible el uso de un único servicio). Además, debido a que muchas de las características TI no pueden estar directamente relacionadas con los objetivos de negocio, hay un riesgo constante de que muchos de los servicios potencialmente útiles, simplemente se pasen por alto.

• Basado en Componentes.

La esencia de la utilización de componentes TI, consiste en dividir la funcionalidad TI en unidades con máxima cohesión interna y mínimo acoplamiento externo. Los componentes son realmente unidades autónomas de funcionalidad.

Hay varios métodos para identificar componentes, pero un principio que guía estos métodos es que cada componente tiene exactamente un dueño y que las responsabilidades de cada componente tienen que ser definidas con la mayor precisión posible. Estas responsabilidades pueden ser utilizadas como punto de partida para la identificación de los servicios.

En la actualidad los proveedores de las grandes aplicaciones monolíticas (como los sistemas ERP y CRM), tienden a organizar sus aplicaciones de forma más modular y ponerlos a disposición a través de los servicios. Estos módulos se corresponden aproximadamente con los componentes.

La ventaja de basarse en los componentes es que el proceso de identificación de servicios se simplifica mucho. La mayor parte del trabajo de análisis ya se ha llevado a cabo como parte del método de desarrollo basado en componentes. Sin embargo, esto dar lugar a varios problemas: los componentes que pueden estar hechos hace tiempo, no encajen con la orientación a servicio o simplemente no respondan a la funcionalidad de negocio que se necesita.

• Partir de lo existente (Bottom-up).

Un método pragmático para una rápida definición de los servicios consiste en basarse en las necesidades inmediatas de información y funcionalidad. En este caso, el punto de partida es la funcionalidad proporcionada por las aplicaciones heredadas existentes. Se seleccionan los sistemas que proporcionan el grueso de la funcionalidad requerida por los principales procesos de negocio. Usando herramientas y asistentes, los interfaces existentes, las pantallas, transacciones, consultas y tablas son accesibles a través de los servicios.

La principal ventaja de este método es que requiere poco tiempo para llegar a una primera definición de los servicios. Se trata de un enfoque apropiado si se requiere con urgencia la funcionalidad de las aplicaciones existentes.

Se reaprovecha el software actualmente existente en la empresa aunque se hace problemático el orientar los servicios resultantes a una verdadera orientación a servicios de negocio ya que el resultado normalmente da lugar a servicios muy específicos y poco reusables.

• Análisis de las necesidades de la aplicación de frontal (frontend).

Analizando la aplicación web o de escritorio que sirve de interfaz con el usuario se puede ver rápidamente los servicios que necesita. Por ejemplo, si en una pantalla se muestran las pólizas que tiene un determinado cliente, obviamente se necesitará un servicio al que se le pasa el identificador del cliente y que devolverá un listado con la consulta que se necesita para presentar los datos al usuario.

Sin embargo, este enfoque tiene un problema importante, se están acoplando los servicios a una aplicación de frontal cuando los servicios deben desconocer quién los convoca. Además casi con total seguridad, los servicios resultantes serán muy específicos para ese caso concreto de frontal.

• Requisitos No Funcionales.

Este método utiliza los requisitos no funcionales como la entrada principal para identificar servicios. No es un método como tal, sino más bien un conjunto de técnicas que se pueden utilizar sobre los otros métodos.

Después de la identificación preliminar de un conjunto de servicios a través de las otras aproximaciones de identificación, el futuro proveedor de servicios verifica la viabilidad de los requisitos no funcionales de un futuro consumidor de servicios. Si los requisitos no funcionales son inviables, es más importante que los servicios puedan ser rediseñados que los principios de diseño que se han seguido en los métodos de identificación.

En la fase de Diseño Técnico, dos requisitos no funcionales que normalmente se tienen que tener en cuenta son seguridad y rendimiento. Por ejemplo: Se descubre que la funcionalidad que aporta el servicio X es necesaria para las aplicaciones A y B. Si la aplicación A se ajusta a los requisitos de seguridad impuestos en el servicio X y la aplicación B no puede, quizás tenga sentido dividir el servicio X en dos servicios separados, servicio securizado y servicio no securizado.

Por otra parte, si una organización decide implementar SOA a través de servicios Web, algunos servicios pueden no ser capaces de ofrecer el rendimiento necesario. Las opciones que se pueden realizar son la fusión de múltiples servicios (reduciendo la cantidad de necesidades de comunicación entre los servicios).   

Patrones Funcionales

Hasta ahora cuando hemos oído hablar de Patrones en Ingenieria del Software ha sido sobre Patrones de Diseño, pero hay más patrones...

La definición de Patrón según la Academia de la Lengua Española es "Modelo que sirve de muestra para sacar otra cosa igual", y eso es lo que haremos con las funcionalidades de las aplicaciones. Sacaremos modelos comunes en las funcionalidades de las aplicaciones que nos sirvan para no tener que pensar ni en cómo resolver ni en cuánto nos cuesta algo que ya hemos realizado antes.

Esto seán los Patrones Funcionales, cada Patrón describirá una serie de tipos de funcionalidades comunes que se encuentran en la mayoría de proyectos de desarrollo de aplicaciones software. Y gracias a ellos podremos reutilizar funcionalidades ya descritas de modo general, a las que tendremos que añadir las particularidades de las aplicaciones.

El contrato para cada Patrón Funcional, tendrá los siguientes apartados:

• Objetivo. ¿Qué resuelve el patrón?
• Estructura. ¿Qué casos de uso componen el patrón? y ¿qué hace cada caso de uso? ¿El patrón necesita datos de entrada? ¿El patrón devuelve datos de salida?
• Diagrama. ¿Cómo se relacionan los casos de uso del patrón?
• Estimación. ¿Cuánto cuesta en términos de UCP, cada caso de uso? ¿Qué catalogación de complejidad tiene cada caso de uso?

El modo de presentación de los Patrones Funcionales será el siguiente:

• Un Catálogo de Patrones dónde indicaremos el nombre del patrón, una descripción breve y el enlace a la documentación del patrón.
• Un documento para cada Patrón Funcional, que incluirá todos los apartados definidos.

Inicialmente comenzaremos abordando una serie de patrones básicos:

• Patrón Carga masiva de ficheros.
• Patrón CRUD Simple
• Patrón CRUD Medio
• Patrón CRUD Complejo
• Patrón Histórico

,para ir aumentando periódicamente la lista de patrones.