4.3. Salida del Proceso de Captura de Requerimientos

Casi todo el resultado del proceso de captura de requerimientos es documental. El unico diagrama es el diagrama de casos de uso, mostrando las relaciones entre casos de uso y actores.

4.3.1. Documento de Visión

Las secciones tipicas de este documento serían como sigue.

  • Resumen. Una declaración del contexto, problema y objetivo de la solutión.

  • Objetivos. Que estamos intentando alcanzar (y como deseamos alcanzarlo).

  • Contexto de Mercado o Convenios Contractuales. Para un desarrollo guiado por el mercado, esto debería indicar mercados objetivo, diferencidores competitivos, eventos motivadores y cosas así. Para un desarrollo contractual esto debería explicar los factores clave contractuales.

  • Partes Implicadas. Los usuarios (en el sentido más amplio) del sistema. Muchos de ellos se mapearán en actores, o equipamiento de control que se mapea en actores.

  • Caracteristicas clave. Los aspectos funcionales clave de la solución deseada al problema al nivel mas alto. Estos se mapearán ampliamente en los casos de uso. Es de ayuda poner algo de priorización aquí.

  • Limitaciónes. Una visión general de los parametros no funcionales del sistema. Estos serán tratados detalle en la especificación de requerimientos suplementarios.

  • Apendice. Un listado de los actores y casos de uso que serán necesarios para cumplir esta visión. Es util enlazar a estos desde las secciones tempranas para asegurar una cobertura exahustiva.

4.3.2. Diagrama de Casos de Uso

El documento de visión ha identificado los casos de uso y los actores. El diagrama de casos de uso captura como interaccionan. En nuestro ejemplo de Cajero Automatico hemos identificado “cliente usa cajero”, “mantener cajero” y “auditar” como los tres casos de uso principales. Hemos identificado “cliente”, ingeniero de mantenimiento“, ” “oficial de sucursal” y “sistema central” como los actores.

Figura 4.1, “ Diagrama de casos de uso basico para un sistema de Cajero Automatico muestra como esto puede ser visualizado en un diagrama de casos de uso. Los casos de uso son mostrados como ovalos, los actores como monigotes (incluso cuando son maquinas), con lineas (conocidas como asociaciones) conectando los casos de uso a los actores que están involucrados en ellos. Un cuadro alrededor de los casos de uso enfatiza la frontera entre el sistema (definido por los casos de uso) y los actores que son externos.

[Nota]Nota

No todos los analisis gustan de usar un cuadro alrededor de los casos de uso. Es un asunto de opción personal.

Figura 4.1. Diagrama de casos de uso basico para un sistema de Cajero Automatico

Diagrama de casos de uso basico para un sistema de Cajero Automatico

Las siguientes secciones muestran como el diagrama de casos de uso básico puede ser extendido para mostrar información adicional sobre el sistema que está siendo diseñado.

4.3.2.1. Actores Activos y Pasivos

Los actores Activos inician la interacción con el sistema. Esto puede ser mostrado colocando una flecha en la asociación desde el actor apuntando hacia el caso de uso. En le ejemplo del Cajero Automatico, el cliente es un actor activo.

La interacción con los actores pasivos es iniciada por el sistema. Esto puede ser mostrado colocando una flecha en la asociación desde el caso de uso apuntando hacia el actor. En el ejemplo del Cajero Automatico el sistema central es un actor pasivo.

Este es un buen ejemplo donde la flecha ayuda, puesto que nos permite distinguir un sistema conducido por eventos (el Cajero Automático inicia la interacción con el sistema central) de un sistema de consulta continua (el sistema central interroga al Cajero Automático de tiempo en tiempo).

Donde un actor puede ser, una de dos, activo o pasivo, dependiendo de las circunstancias, la flecha puede ser omitida. En el ejemplo del Cajero Automático el ingeniero del banco se ajusta a esta categoría. Normalmente el está activo, poniendose en funcionamiento en cicles regulares para dar servicio al Cajero. Sin embargo is el Cajero Automático detecta un fallo, puede convocar al ingeniero para repararlo.

El uso de flechas en asociaciones es referido como la navegación de la asociación. Veremos esto usado en otro lugar en UML mas tarde.

Figura 4.2, “ Diagrama de casos de uso para un Cajero Automático mostrando navegación. muestra el diagrama de casos de uso del Cajero Automático con navegación representada.

Figura 4.2. Diagrama de casos de uso para un Cajero Automático mostrando navegación.

Diagrama de casos de uso para un Cajero Automático mostrando navegación.

4.3.2.2. Multiplicidad

Puede ser util mostrar la multiplicidad de asociaciones entre actores y casos de uso. Con esto queremos decir cuantas instancias de un actor interacciona con cuantas instancias del caso de uso.

Po defecto asumimos que una instancia de un actor interacciona con una instancia de un caso de uso. En otros casos podemos etiquetar la multiplicidad de un extremo de la asociación, una de dos con un número para indicar cuantas instancias están involucradas, o con un rango separado por dos puntos (..). Un asterisco (*) es usado para indicar un número arbitrario.

En el ejemplo del Cajero Automático, solo hay un sistema central, pero el puede estar gestionando cualquier número de usos de Cajero Automático. Por lo tanto colocamos la etiqueta 0..* en el extremos del caso de uso. No se necesita etiqueta en el otro extremo, ya que por defecto es uno.

Un banco local tendrá hasta tres oficiales autorizados para cargar y descargar los Cajeros Automáticos. Asi en el extremo del actor de la relación con el caso de uso Mantenimiento Cajero Automático, colocamos la etiqueta 1..3. Ellos pueden estar tratando con cualquier número de Cajeros Automaticos, así en el otro extremo colocamos la etiqueta 0..*.

Puede haber cualquier número de clientes y puede haber cualquier número de sistemas de Cajero Automático que pueden usar. Así a cada extremo de la asociación colocamos la etiqueta 0..*.

Figura 4.3, “ Diagrama de casos de uso para un sistema de Cajero Automático mostrando multiplicidad. muestra el diagrama de casos de uso del Cajero Automático con multiplicidad representada.

Figura 4.3. Diagrama de casos de uso para un sistema de Cajero Automático mostrando multiplicidad.

Diagrama de casos de uso para un sistema de Cajero Automático mostrando multiplicidad.

La multiplicidad puede abarrotar un diagrama, y a menudo no se muestra, excepto donde es crítico comprenderlo. En el ejemplo de Cajero Automatico solo elegiriamos mostrar 1..3 contra el oficial del banco, ya que todos los demas son obvios por el contexto.

4.3.2.3. Jerarquías de Casos de Uso

En nuestro ejemplo de Cajero Automatico hasta ahora tememos solo tres casos de uso para describir el comportamiento del sistema. Mientras los casos de uso siempre deberían describir un trozo significativo del comportamiento del sistema, si son demasiado generales pueden ser dificiles de describir.

Podríamos por ejemplo definir el comportamiento del caso de uso “Uso Cajero” en terminos del comportamiento de los tres casos de uso mas simples, “Depositar Dinero”, “Retirar Dinero” y “Consultas de Cuenta”. El caso de uso principal podría ser especificado incluyendo el comportamiento de los casos de uso subsidiarios necesarios.

Similarmente el caso de uso “Mantener Cajero” podría ser definido en terminos de dos casos de uso “Mantener Equipamiento” y “Recargar Cajero”. En este caso los dos actores involucrados en el caso de uso principal están realmente solo involucrados en uno u otro de los dos casos de uso subsidiarios y esto puede ser mostrado en el diagrama.

La descomposición de un caso de uso en subcasos de uso mas simples es mostrada en UML usando una relación de inclusión, una flecha punteada desde el caso de uso principal hasta el subsidiario, con la etiqueta «include».

Figura 4.4. Diagrama de caso de uso para un sistema de Cajero Automático mostrando relaciones de inclusión.

Diagrama de caso de uso para un sistema de Cajero Automático mostrando relaciones de inclusión.

Las relaciones de inclusión son buenas para desmantelar los comportamientos de casos de uso en jerarquias. Sin embargo podemos tambien querer mostrar un caso de uso que es una extensión de un caso de uso existente para atender a una circunstancia particular.

En el ejemplo del Cajero tenemos un caso de uso cubriendo la rutina de mantenimiento del Cajero, “Mantener Equipamiento”. Tambien queremos cubrir el caso especial de una reparación no programada causada por la detección de un fallo interno por parte del Cajero.

Esto está mostrado en UML por la relación de extensión. En el caso de uso principal, especificamos un nombre para un lugar en la descripción, donde una extensión del comportamiento podría ser adjuntada. El nombre y lugar son mostrados en un compartimento separado dentro del ovalo del caso de uso. La representación de relación de extensión es la misma que la de la relación de inclusión, pero con la etiqueta «extend». Paralelamente a la relación de extensiñon, especificamos la condicion bajo la cual ese comportamiento será adjuntado.

Figura 4.5, “ Diagrama de casos de uso para un sistema de Cajero Automático mostrando una relación de extensión. muestra el diagrama de casos de uso del Cajero con una relación de extensión a un caso de uso para reparaciones no programadas. El diagrama se está volviendo bastante complejo, y así lo hemos dividido en dos, uno para el lado del mantenimiento, el otro para el uso del cliente y auditoría.

El caso de uso “Mantener Equipamiento” define un nombre “Unsched”, al comienzo de su descripción. El caso de uso extendido “Unscheduled Repair” es adjuntado ahí cuando el Cajero detecta un error interno.

Figura 4.5. Diagrama de casos de uso para un sistema de Cajero Automático mostrando una relación de extensión.

Diagrama de casos de uso para un sistema de Cajero Automático mostrando una relación de extensión.

Los casos de uso pueden ser enlazados juntos de una forma adicional. Un caso de uso puede ser una generalización de un caso de uso subsidiario (o alternativamente el subsidiario es una especializatión del caso de uso principal).

Esto es muy parecido a la relación de extension, pero sin la limitación de puntos de extensión especificos en los cuales el caso de uso principal puede ser extendido, y sin condiciones sobre cuando puede ser usado el caso de uso subsidiario.

La generalización está representada en un diagrama de casos de uso por una flecha con una linea continua y una punta de flecha blanca desde el subsidiario al caso de uso principal.

Esto puede ser util cuando un caso de uso subsidiario especializa el comportamiento del caso de uso principal en un gran número de posiciones y bajo un amplio rango de circunstancias.

Sin embargo la falta de alguna restricción hace la generalización muy dificil de especificar con precisión. En general usa una relación de extensión en su lugar.

4.3.3. La Especificación de Casos de Uso

Cada caso de uso debe ser documentado para explicar en detalle el comportamiento que está especificando. Este documento es conocido por diferentes nombres en diferentes procesos: especificación de caso de uso, escenario de caso de uso o incluso (confusamente) solo caso de uso.

Un caso de uso tipico incluirá las siguientes secciones.

  • Nombre. El nombre del caso de uso al que esto se refiere.

  • Objetivo. Un resumen de una o dos lineas de que realiza este caso de uso por sus actores.

  • Actores. Los actores involucrados en este caso de uso, y cualquier contexto con respecto a su participación.

    [Nota]Nota

    Esto no debería ser una descripción del actor. Eso debería estar asociado con el actor en el diagrama de casos de uso.

  • Pre-condición. Sería mejor llamarlas “pre-asumciones”, pero el termino usado en todos sitios es pre-condiciones. Es una declaración de cualesquiera asumciones de simplificación que podemos hacer al comienzo del caso de uso.

    En el ejempli del Cajero Automatico, podemos hacer la asumción para el caso de uso de “Mantener Equipamiento” que un ingeniero está siempre disponible, y no necesitamos preocuparnos sobre el caso de que una visita de mantenimiento de rutina se halla dejado pasar.

    [Atención]Atención

    Evita pre-condiciones todo lo posible. Necesitas tener la absoluta certeza de que las pre-condiciones caben bajo todas las posibles circunstancias. Si no tu sistema estará debilmente especificado y por lo tanto fallara cuando la pre-condición no es cierta. Alternativamente, cuando no tienes la certeza de que la pre-condición es siempre cierta, necesitaras especificar un segundo caso de uso para manejar la pre-condición siendo falsa. En el primer caso, las pre-condiciones son una fuente de problemas, en el segundo una fuente de mas trabajo.

  • Flujo Básico. La secuencia lineal de pasos que descruben el comportamiento de el caso de uso en el escenarío “normal”. Donde un caso de uso tiene un número de escenarios que podrían ser normales, uno es seleccionado arbitrariamente. Especificar el flujo básico está descrito con más detalle mas Sección 4.3.3.1, “” abajo.

  • Flujos Alternativos. Unas series de secuencias lineales describiendo cada uno de los comportamientos alternativos al flujo básico. Especificar flujos alternativos está descrito con mas detalle en Sección 4.3.3.2, “”.

  • Post-condiciones. Sería mejor llamarlas “post-asumciones”. Esta es una especificación de cualesquiera asumciones que podemos hacer al final del caso de uso. Son mas utiles donde el caso de uso es uno de una serie de casos de uso subsidiarios que estan incluidos en un caso de uso principal, donde pueden formar las pre-condiciones del siguiente caso de uso que va a ser incluido.

    [Atención]Atención

    Como las pre-condiciones, las post-condiciones son mejor evitarlas. Colocan una carga en la especificación de los flujos de caso de uso, para asegurar que la post-condición siempre se mantiene. Por lo tanto son tambien una fuente de problemas y trabajo extra.

  • Requerimientos. En un mundo ideal el documento de visión, los diagramas de casos de uso, las especificaciones de casos de uso y la especificacion de requerimientos suplementarios formarián los requerimientos para un proyecto.

    Para la mayoría de los desarrollos lideres del mercado, donde la propiedad de los requerimientos esta dentro del mismo negocio que el equipo que hará el desarrollo, este no es normalmente el caso. El departamento de marketing puede aprender captura de requerimientos basada en casos de uso y analisis para enlazar con las actividades primarias de sus consumidores.

    Sin embargo para desarrollos externos por contrato, los consumidores pueden insistir en una “lista de caracteristicas” tradicional como la base del contrato. Cuando este es el caso, esta sección de la especificación de casos de uso debería enlazar con las caracteristicas del contrato que son cubiertas por el caso de uso.

    Esto es hecho a menudo a traves de una herramienta de terceros que puede enlazar documentos, proporcionando una prueba automatizada de cobertura de requisitos, en tal caso esta sección no es necesaria, o puede ser generada automaticamente.

El tamaño final de la especificacíon de caos de uso dependerá de la complejidad del caso de uso. Como pequeña regla, la mayoría de los casos de uso toman alrededor de 10-15 paginas para especificar, la mayoría de las cuales son flujos alternativos. Si el tuyo es mucho mas largo que esto, considera simplificar el caso de uso. Si el tuyo es mucho mas pequeño considera que el caso de uso esta describiendo una parte demasiado pequeña del comportamiento.

4.3.3.1.

Todos los flujos en una especificación de casos de uso son lineales (esto es que no hay ramas condicionales). Cualesquiera elecciones en los flujos son manejadas especificando otro flujo alternativo que recoge el punto de elección. Es importante recordar que estamos especificando comportamiento aqui, no programandolo.

Un flujo es especificado como una serie de pasos numerados. Cada paso debe implicar alguna interacción con un actor, o al menos generar un cambio que sea observable externamente por un actor. La captura de requerimientos no debería estar especificando comportamiento interno y oculto del sistema.

Por ejemplo nosotros podemos dar la siquiente secuencia de pasos para el flujo basico del casos de uso "Retirar Dinero" en nuestro ejemplo de Cajero Automatico.

  1. Consumidor indica que se requiere recibo.

  2. Consumidor introduce cantidad de dinero requerido.

  3. Cajero Automatico verifica con el ordenador central que el consumidor puede realizar esta operación.

  4. Cajero Automatico entrega el dinero a el consumidor.

  5. Cajero Automatico emite recibo al consumidor.

Recuerda que esta es un sub-caso de uso incluido en el caso de uso principal “Usar Cajero Automatico”, el cual presumiblemente manejará la verificación de tarjetas y PINs antes de invocar este caso de uso incluido.

[Nota]Nota

El primer paso no es una condición. Tomamos como nuestro flujo básico el caso donde el consumidor quiere un recibo. El caso donde de consumidor no quiere un recibo será un flujo alternativo.

4.3.3.2.

Esto captura los escenarios alternativos, como flujos lineales, mediante referencia la flujo básico. Inicialmente unicamente construimos una lista de los flujos alternativos.

    1. Consumidor no requiere recibo.

    2. La cuenta del consumidor no soportará el retiro de dinero.

    3. Comunicación con el ordenador central está interrumpida.

    4. El consumidor cancela la transacción.

    5. El consumidor falla a coger el dinero entregado.

4.3.3.3.

4.3.4.

[Nota]Nota