archivo

Archivo de la etiqueta: diagrama de casos de uso

En el artículo anterior vimos una posible forma de enfocar la gestión CRUD en los casos de uso. En este voy a añadir un par de posibles soluciones a circunstancias que se pueden dar en la definición de los casos de uso de un sistema de información:

1) Puede haber alguna tabla maestra que tenga alguna operación expecial como por ejemplo el duplicado de un registro (puede ser útil sobre todo en aquellos casos donde cada registro tengo un número elevado de atributos).

¿Cómo podemos llevar esto al modelo de casos de uso?

Seguiriamos teniendo la entidad donde se realiza esta operación con una relación de herencia sobre el caso de uso “Gestionar Entidad”. Al hacerlo entendemos que se hereda el comportamiento del mismo, así como las relaciones que tenga. Como se trata de una operación más, pues a nivel de diagrama de casos de uso bastará con incluir un nuevo caso de uso en el que se describa la interacción sistema/actores para la realización de la operación que extenderá al caso de uso de la entidad, el cual no será necesario describir ya que en nada varía su funcionamiento.

2) ¿Y si alguna operación tiene un comportamiento especial en la gestión de una entidad?

Una posible solución consiste en que se describa esa operación en un caso de uso y extienda al caso de uso de la entidad (que a su vez tiene una relación de herencia con el caso de uso genérico “Gestionar Entidad”).

Se entenderá que ese caso de uso “sobreescribe” al caso de uso definido para dicha operación en el caso de uso genérico.

3) A veces hay entidades más complejas que comparten parte del funcionamiento de una gestión CRUD (como por ejemplo el alta o la consulta), ¿cómo representarlo?.

Una posible solución sería aplicar una solución similar a la que he expuesto en el caso anterior, todo lo nuevo tendría relaciones extend con respecto al caso de uso de gestión de la entidad (no confundir con el caso de uso genérico).

Quiero dejar claro que estas soluciones o estratégicas no buscan una aplicación purista de UML o de la estrategia de diseños de caso de uso, se trata de una forma de aplicar los mismos con el objeto de no que los casos de uso no representen repetición de comportamientos y así poder invertir el esfuerzo en describir aquellas interacciones actores/sistema que tienen un comportamiento específico y que sí resultan interesantes ser descritas de la manera más exacta posible.

Por regla general, las empresas de desarrollo de software hacen uso de un determinado framework y de generadores de código, con el objetivo de estandarizar en cierta forma la construcción del sistema de información y solo incluyen variaciones sobre los mismos en proyectos concretos donde el cliente exige algún tipo de especificación distinta.

Si se quiere mejorar en productividad, el camino es ese (si bien, son necesarias muchas más variables para que la mejora de la productividad realmente sea efectiva).

Los generadores de código hacen repetible determinadas funcionalidades, como por ejemplo, la gestión de tablas maestras, la autenticación, etc… Por otro lado, aunque no se utilicen ese tipo de productos resulta aconsejable que salvo que se indique lo contrario por parte del cliente, se implementen determinadas funcionalidades de forma repetible entre un sistema de información y otro, así como dentro de un mismo sistema (no resulta lógico, salvo situaciones excepcionales, que la estrategia de diseño y construcción del mantenimiento de una tabla maestra sea distinta a la de otra).

Por este motivo, no resulta de utilidad invertir esfuerzo en el diseño de casos de uso, en repetir tanto el diagrama de casos de uso, como la descripción de los mismos, en elementos que van a tener un comportamiento similar, como por ejemplo, la gestión de tablas maestras. Eso dentro de un mismo proyecto, pero para proyectos donde se utilicen estrategias similares, bastará con tener dentro del proyecto base de la herramienta CASE la especificación de los casos de uso que pueden ser repetibles (y después realizar los ajustes que sean necesarios).

La clave de todo esto es racionalizar los esfuerzos de manera que se inviertan donde realmente merezca la pena.

En este artículo, voy a centrarme en exponer una definición de lo que son los casos de uso, los actores y las relaciones que existen entre casos los casos de uso.

Independientemente de lo que comente, lo importante es ser conscientes de que los casos de uso describen comportamientos del sistema ante interacciones con agentes externos y que esa descripción se puede hacer de múltiples formas, de manera que para un sistema de información puede haber una infinidad de soluciones que sean totalmente válidas.

¿Qué es un caso de uso?

– Conjunto de funcionalidad.
– Tienen relación con uno o más requisitos funcionales del sistema.
– Logra un objetivo discreto para el usuario.
– Visión de caja negra con respecto a los actores en cuanto a que reciben una petición y devuelven unos resultados.
– Con significado en sí mismo.
– Externamente visible (con excepción de algunos casos de uso que sean utilizados por otros), de manera que especifica la forma de funcionar del sistema tal y como se vería desde el exterior (capta una funcionalidad visible para el usuario).
– Aporta valor al actor que lo utiliza.
– Se expresaría como una secuencia de mensajes intercambiados por el sistema y uno o más actores.

¿Qué es un actor?

– Entidad externa al sistema que interactúa con él.
– Puede ser humano u otro sistema (externo).

¿Cuáles son las relaciones entre casos de uso?

Include: se representa como una flecha discontínua entre un caso de uso y otro. El sentido de la flecha va del caso de uso principal al secundario, estereotipada con la palabra include. Viene a representar que el caso de uso principal incluye al secundario, es decir, que hace uso del mismo para poder llevar a cabo su funcionalidad. Este tipo de casos de uso tienen razón de ser en aquellos casos donde un funcionalidad o comportamiento pueda ser utilizado por diferentes casos de uso o bien, porque la complejidad de un caso de uso, aconseje que se fraccione su comportamiento en diversos casos de uso.

Extend: se representa como una flecha discontínua entre un caso de uso y otro. El sentido de la flecha va del caso de uso secundario al principal, estereotipada con la palabra extend. En este caso, el caso de uso secundario proporciona una funcionalidad adicional al caso de uso principal, pero que solo se produce en algún caso, es decir, existirán circunstancias en las cuales el caso de uso principal se ejecutará completamente sin que para ello tenga que hacer uso del caso de uso que lo extiende, en esto se diferencia del include donde necesariamente se tiene que llevar a cabo el caso de uso secundario para que se pueda realizar el objetivo que persigue el caso de uso principal (en su camino básico). Por este motivo, si un caso de uso es extendido por otro, debe tener un camino alternativo que haga referencia a ese comportamiento que proporciona el otro caso de uso, pero que no se ejecuta en todos los casos.

Herencia: este tipo de relación se utiliza con mucho menos frecuencia que las anteriores, de hecho es muy utilizada entre los actores, pero por ejemplo en los diagramas de casos de uso que suelen entregar en proyectos de mi organización casi nunca los he visto aplicados a los casos de uso. Cuando un caso de uso hereda de otro, conserva su comportamiento. Se representa como una línea continua que va del caso de uso específico al más abstracto teniendo en el extremo el triángulo que representa la generalización en UML. En este tipo de relaciones el caso de uso específico hereda todas las características del más general, permitiendo dotarle de un significado y funcionalidad concreto.

Con respecto a los casos de uso, soy un converso, hasta hace poco tiempo pensaba que eran un trámite más en el proceso de desarrollo de software y que no aportaban nada. Ahora pienso todo lo contrario y, como la mayoría de los conversos, defiendo al máximo la realización de este entregable del proceso de análisis del sistema de información, ya que efectivamente, contribuye al ajuste del catálogo de requisitos y sirve de complemento idóneo al mismo en el sentido de que describe el comportamiento del sistema de información desde el punto de vista de la interacción entre el mismo y los diferentes actores, ya sean personas u otros sistemas.

Los requisitos y la descripción de casos de uso, van de la mano, si bien es importante tener una primera versión del catálogo de requisitos bastante sólida antes de comenzar a realizar los diagramas de casos de uso y lo más importante, la descripción de los mismos y de sus diferentes escenarios.

Cuando se estén definiendo los casos de uso saldrán dudas que permitirán aclarar o mejorar determinados requisitos y probablemente salgan a la luz nuevas funcionalidades o necesidades no tenidas en cuenta. Por ese motivo es esperable y deseable la modificación del catálogo de requisitos tanto en el proceso de definición de los casos de uso como en la obtención de su versión definitiva.

Es importante que una vez completados los casos de uso se verifique que cuadran con los requisitos, de manera que no haya casos de uso que hagan referencia a requisitos y requisitos que no se vean reflejados en casos de uso. Para ello es necesario realizar una matriz casos de uso/requisitos que ayude a la realización de esta actividad.

Una buena descripción de los casos de uso, guía el proceso de desarrollo, en cuanto a que describe el comportamiento del sistema, descompuesto en subsistemas de análisis (es un proceso previo a la realización de los casos de uso y que permite dar a la aplicación una división por grandes niveles funcionales o procesos de negocio) y a su vez descompuesto por funcionalidades específicas que se describen como una secuencia de pasos en los que interviene el sistema y los actores o agentes externos al mismo pero que interactúan con él. Es decir, a partir de los casos de uso, con mayor o menor detalle se especificará cómo se realizarán determinadas funcionalidades sin entrar en aspectos concretos de implementación.

En muchos casos una buena definición de casos de uso, acompañada por un diseño de interfaz de usuario y navegación aprobado por los usuarios y del modelo de datos, puede resultar suficiente para la construcción con ciertas garantías de un sistema de información.

Otra de las ventajas de los casos de uso es que a partir de ellos se pueden obtener otros productos de interés para el proyecto sin esfuerzo adicional (haciendo uso de herramientas CASE), como por ejemplo diagramas de actividad (que son otra forma de representar los caminos de un caso de uso, en la cual se pasa de la descripción textual a una representación de carácter gráfico) o la obtención de una buena parte del conjunto de casos de prueba del sistema.

También pueden ser utilizados como una técnica para la estimación del coste del proyecto, aplicando la estrategia de estimación por puntos de casos de uso (conceptualmente parecida a la técnica de puntos función, pero más simple).

¿Sirven para algo los casos de uso? En una charla con un grupo de amigos, uno de ellos hizo esa pregunta y se hicieron unos cuantos segundos de silencio.

Supongo que cada uno tendrá su experiencia y por tanto los casos de uso tendrán sus detractores y defensores. No es el objeto de este artículo analizar quién puede tener razón sino tan solo ofrecer mi punto de vista, acertado o equivocado.

Los casos de uso según Métrica versión 3, tendrían un doble propósito:

– Servir de herramienta para la especificación de requisitos ya que ayuda a los usuarios a reducir la complejidad de abstraer la aplicación que quieren que se desarrolle (o se mantenga).
– Guiar el proceso de desarrollo.

Tal vez no haya tenido suerte, pero en todo el tiempo que llevo en este negocio, no he tenido la oportunidad de estar en proyectos donde los casos de uso hayan resultado decisivos para la especificación de requisitos (es más, en la mayoría de las situaciones ha sido un producto que ha derivado de los requisitos o que se ha obtenido posteriormente) o para el proceso de desarrollo.

En lo que a la especificación de requisitos se refiere, los usuarios prefieren la especificación de requisitos en lenguaje natural (y ellos poder discutirlos) y trabajar con posibles interfaces de usuario. Los diagramas de casos de uso siguen siendo de otra galaxia y hay que explicárselos muy bien para que lo entiendan.

En mi opinión, para que los casos de uso tengan utilidad real hay que trabajar bien los diagramas y sobre todo realizar la especificación de cada caso de uso y eso requiere un gran esfuerzo importante en el momento en que la aplicación tiene una cierta complejidad y si se quiere que realmente el usuario entienda paso a paso las distintas funcionalidades que el desarrollador ha ido detectando en las distintas sesiones de recopilación de requisitos. Por supuesto, en todo lo anterior, es conveniente que el usuario esté asistido si así lo requiere, ya que es posible que tenga alguna duda en la interpretación de lo que está viendo y leyendo.