lunes, 20 de julio de 2015

Entendiendo los diagramas de casos de uso (use cases diagrams)

Aunque los casos de uso son descripciones de la funcionalidad del sistema que deben existir en forma textual (Ver esta entrada). Estos son usualmente acompañados por diagramas que capturan detalles como los nombres de los casos de uso, los límites de los sistemas, los actores y las relaciones entre ellos. El estándar UML proporciona notación para cada uno de estos detalles.

Estos diagramas siempre se dibujan desde la perspectiva de la organización sin distinguir entre procesos automáticos y manuales, hay que tener presente que los diagramas de caso de uso son la vista estática del sistema.

Lista de los elementos generales para un diagrama de casos de uso:

Actor: Un actor representa un rol ejecutado por una persona externa, por un proceso o por cualquier cosa que interactue con el sistema.

Caso de uso (use case): Un caso de uso es un clasificador que representa una unidad de funcionalidad proporcionada por un sistema, un subsistema o una clase que puede intercambiar mensajes entre las acciones del sistema y uno o más actores.


Paquete (package): Sirve para la agrupación de elementos, puede contener otros paquetes.

Límite (System Boundary): El limite del sistema consiste de todos los casos de uso que están relacionados con el dominio del sistema.

Asociación (association): La participación de un actor en un caso de uso, instancias del actor e instancias del caso de uso se comunican una con otra.

Extend: Esta relación desde un caso de uso A a un caso de uso B indica que una instancia de un caso de uso B puede ser aumentado por el comportamiento especificado en A.

Include: Este relación se utiliza para indicar que un caso de uso es una subrutina de otro caso de uso.

Los casos de uso son organizados de forma jerárquica con las relaciones: extend, e include.

Una herramienta muy buena para hacer diagramas es visual paradigm, hay versiones para Windows, Mac y Linux, se puede descargar una versión community edition del sitio.

viernes, 10 de julio de 2015

Entendiendo los casos de uso (use cases)

Los casos de uso (use cases) son unos artefactos muy recomendados para el entendimiento, descripción, documentación y trazabilidad de los requerimientos funcionales de un sistema. Hacer un modelo de casos de uso es un primer paso en el análisis de requerimientos para describir el comportamiento del sistema desde la perspectiva de los actores y los objetivos a realizar con él. Ivar Jacobson el creador de los casos de uso los describe de la siguiente manera:

Un caso de uso son todas las maneras en las que se usa un sistema para lograr una meta particular para un usuario particular. Si juntamos el conjunto de todos los casos de uso te da todas las maneras útiles para usar el sistema, e ilustra el valor que el sistema proporciona

El modelo de casos de uso es una de las vistas del modelo de arquitectura 4+1 de Philippe Kruchten, como en la siguiente imagen, el modelo de casos de uso es la quinta vista (+1).

Los casos de uso se emplean en muchos procesos de ingeniería de software entre todos ellos dos de los más ampliamente utilizados son: MSF (Microsoft Solution Framework) y RUP (Rational Unified Process).

Aunque ambos procesos cumplen el mismo objetivo (proyectos de software con éxito) cada uno de ellos ubica el modelo de casos de uso de forma un poco distinta.

En MSF se tienen 5 fases:

  • Envisioning (Visualizar)
  • Planning (Planear)
  • Developing (Desarrollar)
  • Stabilizing (Estabilizar)
  • Deploying (Despliegue)

Los casos de uso (algunas veces en MSF los nombran usage cases en vez de use case), estos se crean en la fase Planning en la etapa de diseño conceptual (Conceptual Design).

En RUP se tienen 4 fases:

  • Inception (Inicio)
  • Elaboration (Elaboración)
  • Construction (Construcción)
  • Transition (Transición)

En RUP el modelo de casos de uso se crea durante la fase de inicio. en la disciplina de requisitos.

A un caso de uso informalmente se le conoce como una colección de escenarios. Un escenario es una secuencia especifica de acciones e interacciones exitosas y erróneas entre actores y el sistema bajo diferentes condiciones de operación.

A los escenarios también se le conocen como instancias de casos de uso.

Formatos para casos de uso

Los casos de uso de caja negra son la clase más común ya que no describen el funcionamiento interno del sistema sino sus responsabilidades, especifican la interacción entre el sistema y el mundo exterior en este contexto el mundo exterior se refiere a los actores, un actor en este contexto es alguien que interactua con el sistema.

Las responsabilidades del sistema en este tipo de casos de uso describen siempre que es lo que hace el sistema sin decidir como lo hace (esto le corresponde al diseño). Los tipos de casos de uso son:

  1. Formato breve (brief): Es la historia del uso del sistema en un solo párrafo, por ejemplo:

    Crear una nueva cita: una persona entra al sitio del sistema en el menú de creación de citas, el sistema despliega la pantalla de creación de citas solicitando los siguientes datos: fecha, hora, servicio solicitado, nombre, apellido, teléfono de casa, teléfono celular, email. La persona ingresa los datos y ejecuta la acción guardar. El sistema valida los datos, una cita fue creada en el sistema.

  2. Formato casual (casual version): es un un formato informal que cubre varios escenarios, este es el más ampliamente utilizado. Ejemplo:

    Historial de versiones
    Fecha Descripción Autor
    Noviembre 6, 2002 Initial draft Heidi Steen
    Titulo (Title): Creación de una cita
    Identificador (ID): UC1
    Breve descripción (Summary): Este caso de uso inicia cuando la persona entra al menú creación de citas del sistema, el sistema ingresa los siguientes datos: fecha, hora, servicio, nombre, apellido, email, teléfono de casa, teléfono celular. Entonces ejecuta la acción guardar entonces el sistema hace la validación y la cita es creada.

    Actores/Actors (no siempre son seres humanos, pueden ser otros sistemas informáticos o procesos se incluye el propio sistema):

    Persona, sistema médico

    Precondiciones/Preconditions (establecen lo que siempre debe cumplirse antes de iniciar el caso de uso, se asume que son verdaderas):

    1. La persona tiene acceso a Internet
    2. La persona entro en el sitio de la aplicación
    3. Los catálogos esta online y trabajan bien.

    Postcondiciones/Postconditions (establecen que debe cumplirse cuando el caso de uso termina con éxito):

    Se creo la cita en la base de datos del sistema.

    Flujo básico/Basic flow: (por lo regular no incluye ninguna condición o bifurcación, se incluyen interacción entre actores, validaciones y cambios de estados)

    Actor Sistema
    1-. La persona entra a la aplicación y elije crear una nueva cita.
    2-.El sistema solicita los siguientes datos: fecha, hora, servicio, nombre, apellido, email, teléfono de casa y teléfono celular.
    3-.La persona ingresa todos los datos solicitados y ejecuta la acción de guardar.
    4-. El sistema recibe la petición, realiza la validación de los datos si no existe un error entonces crea una la cita en la base de datos y despliega un mensaje de éxito.
    5-. La persona ha creado una nueva cita.

    Flujos alternos/Alternate flows/extensions (indican los otros escenarios de éxito, las bifurcaciones del flujo básico se registran poniendo el número del paso):


    3a Ingresa solo los datos requeridos.

    3a1. La persona ingresa solo los datos mínimos requeridos: fecha, hora, servicio, nombre, apellido y al menos uno de los teléfonos: home phone y cel phone.


    Flujos de excepción: (Exception flows: Indican los escenarios de fallo, esta sección también puede incluirse dentro de los flujos alternos)

    3b Selecciona una fecha anterior a la fecha actual.

    3b1. El sistema envía el mensaje “No se permite una fecha anterior a la actual”


    4b. Faltan campos requeridos

    4b1 El sistema envía el mensaje indicando los campos requeridos que faltan.


    Requerimientos no funcionales/Non functional requirements:(aqui van los atributos de calidad que se relacionan con el caso de uso)

    • El modulo de citas debe ser visible desde cualquier dispositivo móvil.
    • La interfaz de usuario debe funcionar en cualquier navegador.
    • El tiempo de respuesta para guardar no debe sobrepasar los 10 segs.

  3. Formato completo (Fully Dressed): como ejemplos de este tipo de formatos, visitar el sitio usecases.org

Elementos gráficos

El formato de casos de uso tiene una sección para prototipos gráficos (opcionales en algunas ocasiones) llamada “Pantallas del prototipo” en caso de que el sistema tenga GUI.

Por ejemplo el prototipo del ejemplo quedaría mas o menos así:

Una excelente herramienta para realizar prototipos es el proyecto pencil pencil es un proyecto open-source que incluye versiones para Linux, MacOSX y Windows.

Escritura del caso de uso en estilo esencial (Olvidarse de la GUI)

La idea de No considerar la interfaz de usuario sino concentrase en la intensión según el libro Writing effective use cases de Alistair Cockburn se deben de evitar los detalles de la GUI, recomienda hacer la narración a nivel de las intenciones del usuario y las responsabilidades del sistema suena lógico ya que el GUI cambia con más frecuencia que los procesos de negocio EBP (Elementary Business Process). La definición de EBP según el libro Applying UML and patterns de Craig Larman es:

Una tarea realizada por una persona en un lugar, en un instante, como respuesta aun evento del negocio, que añade un valor cuantificable para el negocio y deja los datos en un estado consistente.

Hay que ser claros lo esencial de los casos de uso son historias y narrativas, el producto de esta técnica son documentos de texto, los diagramas y prototipos son únicamente un complemento.