¡Arma tu propia fiesta aplicando casos de uso!

Imagina esto: tu hijo ( o sobrino ) preferido te pide una fiesta de cumpleaños. La realidad es que comienza a lloriquear, hace pataletas en el suelo, dando la ilusión de una hélice de helicóptero suelta. ¡El niño quiere un una fiesta para su cumpleaños!.
Tu comienzas a desesperarte y debido a que ese niño es tu debilidad deseas complacerlo. Comienzas a preguntarle que quiere exactamente. Imaginemos dicha tertulia:
-¿Quieres que haya un mago?
-No, No quiero un mago! ¡Quiero payasos!
-¿Pastel de chocolate?
-No! Quiero un pastel de fresa, unas piñatas de (Inserte personaje de caricatura aquí), bolos, un brincolín y mucha comida.

Una fiesta de cumpleaños de ensueño

Y en tu cabeza comienza a formarse la idea de lo que el niño quiere. Luego de un par de preguntas, lloriqueos y respuestas cortas, el niño te describe su fiesta perfecta:
El quiere una fiesta de vaqueros, con sombreros de vaquero, que haya un DJ que ponga la canción de El ratón vaquero una y otra vez, payasos que les maquillen la cara y les hagan show, pastel, piñatas, hamburguesas de comer y helado de postre (vaya niño exigente).

Detengamonos un momento. Como ya se habrán dado cuenta en mis anteriores entradas, estas historias intentan explicar conceptos de software de forma sencilla.
Como ingenieros de software, nos topamos con clientes que pocas veces saben lo que quieren. Los requermientos (representados por el acto anterior) nos ayudan a darnos una idea concreta sobre lo que el cliente quiere y (cree) que necesita. Evidentemente, el producto final debe cumplir con las necesidades del cliente.
Así como le preguntarías al pequeño cual es la fiesta perfecta para él, al grado de poderte hacer una idea específica de lo que desea.

Volvamos a la historia. Le dices al niño que tendrá su fiesta (vaya que lo tienes consentido). El niño para este entonces ya tiene fantasías con su cumpleaños. El no se preocupa de donde lo vas a obtener.
Sin embargo, tú como adulto, has comenzado a pensar y hacer planes: ¿Le voy a dar bolo solo a los niños o a todos los invitados? Es necesario contar cuantos invitados necesito, cuantos niños y cuantos adultos. ¿Haré las hamburguesas yo solo, le pido ayuda a mi madre o contrato un servicio de comida? ¿Contrataré payasos? Entonces debo buscar una agencia, llamarles y contratarlos. ¿Y si hacemos la fiesta en casa?, sería divertido tener una pequeña pijamada para sus amigos. ¿O que tal si realizo una fiesta de disfraces y les pido que vengan disfrazados? ¿Le pediré a mi tía, que es buena con manualidades, que haga la decoración? ¿Que tal si solo contrato una agencia de eventos y delego este dolor de cabeza que me acaba de asaltar?

Al niño no le interesa el modo en que vas a organizar la fiesta. Así como el cliente no se interesa en absoluto el funcionamiento del producto, mientras se ajuste a sus requerimientos.

Sin embargo, para nosotros los desarrolladores, es importante hacernos una idea muy clara de como van a interactuar los distintos usuarios y componentes en nuestro producto.
Para describir las distintas acciones a realizar entre dichos elementos, realizamos casos de uso.
En nuestra historia, los casos de uso serían los posibles escenarios que ocurren en la fiesta. Mientras los niños están en el show de payasos, ofreceré cervezas a los padres de familia. Mis familiares se sentarán en una misma mesa, los vecinos en otra. La piñata solo la romperán los pequeños, para los adolescentes y adultos tendremos una rifa de regalos. A los amigos más cercanos se les dará un juguete, la decoración la realizará un servicio contratado.
Lo importante aquí, es definir claramente los actores involucrados, así como las acciones (relaciones) que ejercen sobre otros componentes.
Aún no nos adentramos en el diseño de la arquitectura de nuestro proyecto. Los casos de uso describen solamente las interacciones entre componentes y actores, las enuncian. El cómo viene después.

Entrados en contexto, podemos ya explicar de forma más concreta que es un caso de uso:

El caso de uso es una descripción más detallada de un conjunto de interacciones entre el sistema y uno o más actores, donde un actor es un usuario u otro sistema.

El caso de uso se crea como un documento que incluye:

  • Breve descripción con el objetivo
  • El trigger (evento o secuencia de eventos que inician el caso de uso)
  • La especificación de los actores
  • Condiciones previas (las cosas que deben suceder en el sistema)
  • Flujo normal, flujo alternativo, excepciones (desviaciones del flujo normal)
  • Publicar condiciones (qué sistema debe haberse logrado al final de los pasos de flujo normales o alternativos)

Como ya mencionamos, los casos de uso tienen más que ver con el comportamiento que el equipo técnico tendrá que incorporar al software. Se describe claramente todo lo que un desarrollador necesita construir para satisfacer las necesidades de los usuarios. ¡Y los desarrolladores tendrán una buena idea de lo que debe hacer el software!
Si quieres seguir leyendo, encontré una entrada que aterriza a nivel profesional la utilización de los casos de uso. El link lo encuentras Aquí.
Los casos de uso son comúnmente representados como diagramas. La notación que recomienda UML para dichos diagramas la presentaremos a continuación.

Simbología de los diagramas de caso de uso propuesto por UML

Simbología de los casos de uso
Sistema: El rectángulo representa los límites del sistema que contiene los casos de uso. Los actores se ubican fuera de los límites del Sistema.
Caso de uso: Se representan con óvalos. La etiqueta en el óvalo indica la función del sistema. ( Es fundamental que cada caso de uso conlleve una acción específica. Es decir, el caso de uso conlleva un verbo involucrado, así como al objeto al cual se le aplica la acción).
Actor: Un diagrama de caso de uso contiene los símbolos del actor y del caso de uso, junto con líneas conectoras. Los actores son similares a las entidades externas; existen fuera del sistema. El término actor se refiere a un rol específico de un usuario del sistema. ( Generalmente son asociados los actores con sustantivos, ya sea otros componentes, sistemas o usuarios).

Relaciones
Las relaciones entre un actor y un caso de uso, se dibujan con una línea simple. Para relaciones entre casos de uso, se utilizan flechas etiquetadas “incluir” o “extender.” Una relación “incluir” indica que un caso de uso es necesitado por otro para poder cumplir una tarea. Una relación “extender” indica opciones alternativas para un cierto caso de uso. ( Las palabras incluir y extender, son ampliamente utilizadas en el paradigma orientado a objetos! ).
Relaciones de los casos de uso
Las relaciones activas se conocen como relaciones de comportamiento y se utilizan principalmente en los diagramas de casos de uso. Hay cuatro tipos básicos de relaciones de comportamiento: comunica, incluye, extiende y generaliza.

Conclusiones
Por ahora, no me adentraré en detalles técnicos en esta entrada de blog. Mi objetivo principal es que al leer este pequeño escrito, tengas una idea clara de en que situaciones se aplica un caso de uso y lo sepas diseñar. No es mi intención que te vuelvas un maestro en diagramas de casos de uso en UML, o forzarte a realizarlos de una u otra manera. Lo importante aqui, es que nos demos cuenta que, en las actividades cotidianas que solemos planear y diseñar, aplicamos de forma implícita buenas prácticas para diseño de software.

Mi objetivo principal, es que te vuelvas observador, que identifiques en las situaciones de la vida cotidiana patrones de modelado y de diseño. Que tu mente se acostumbre a abstraer, a ver en tus problemas y proyectos potencial para aplicar estos conceptos de modelado.

Los lenguajes, terminologías, aspectos técnicos, buenas practicas y estándares generados por UML, o cualquier otra organización, nos ayudan aplicar de forma ordenada estas ideas de diseño, que por mucho tiempo, han sido intuitivas, pero ocultas para nuestro entendimiento.

Si quieres seguir aprendiendo, no te limites y adéntrate en la red. Algunos consejos útiles para hacer casos de uso están por aquí.

Si eres más de comprender con ejemplos, manzanitas y peritas, te recomiendo esta entrada.

Nota random: los artistas del modernismo nos mostraron el objeto cotidiano, abstrajeron sus percepciones y nos llevaron a la unidad mínima de expresión. Los artistas modernos comprendieron el paradigma orientado a objetos antes de que incluso existiera.

Anuncios

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Crea tu página web en WordPress.com
Empieza ahora
A %d blogueros les gusta esto: