Modelar casos de usuario

El equipo puede crear modelos que le ayudan a entender los casos de usuario que está a punto de calcular o desarrollar. El equipo puede usar también los modelos en las discusiones en curso con el propietario del producto que se producen durante el desarrollo, si las preguntas son suficientemente complejas.

Por ejemplo, el proyecto puede implicar un conjunto de conceptos que son nuevos en el equipo. Si trabaja con el propietario del producto, el equipo puede desarrollar un diagrama de clases de dominio para capturar estos conceptos y las relaciones entre ellos. Si el equipo debe entender las secuencias principales en una actividad de usuario, puede crear un diagrama de actividades.

Para obtener más información, vea Crear modelos de los requisitos de los usuarios.

El modelo de dominio: el lenguaje de los usuarios

Diagramas de clases de dominio

Un diagrama de clases de dominio muestra los conceptos y relaciones asociados a la aplicación. Todas las personas asociadas a la aplicación podrán usar esos conceptos para lograr conocimientos más coherentes.

El ejemplo de la ilustración anterior no es exactamente un diagrama de clases de la solución de software, que podría representar estas relaciones de varias maneras diferentes. En su lugar, muestra un vocabulario con el que se pueden escribir los casos de usuario:

El cliente elige un Menú a partir del cual crea un Pedido y, a continuación, el cliente crea Elementos del pedido en el Pedido al seleccionar Elementos del menú en el Menú.

Dado que es un modelo de conceptos en lugar de objetos de un programa, las operaciones no se asignan normalmente a las clases cuando el diagrama se usa con este propósito. En su lugar, los diagramas de actividades se pueden usar para describir las acciones que realizan los usuarios.

Para obtener más información, vea Diagramas de clases de UML: Instrucciones.

Diagramas de actividades

El equipo puede explicar el flujo de actividades que un usuario puede realizar y mostrar las líneas de acción alternativas en cada punto mediante los diagramas de actividades.

Cuando el equipo crea las pruebas, puede hacer referencia a los diagramas de actividades y crear una prueba para cada ruta de acceso a través del diagrama de actividades.

Un caso de usuario podría incluir una ruta de acceso en un diagrama de actividades existente. Por ejemplo, un caso de usuario podría ser "En mi calidad de cliente, puedo guardar un pedido para más adelante en lugar de pagarlo ahora". Cuando el caso se lleva a un sprint para desarrollarlo, el diagrama de actividades se puede actualizar para expresar la nueva característica.

El diagrama de actividades puede describir un conjunto completo de rutas de acceso que el usuario pueda seguir a través de una versión concreta de la aplicación, si actualiza el diagrama para reflejar todos los casos de usuario que el equipo ha implementado.

Para obtener más información, vea Diagramas de actividades UML: Instrucciones.

Usar el modelo para detectar lagunas

El equipo puede entender mejor los requisitos de los usuarios si se evitan los malentendidos que se producen en las conversaciones no respaldadas por un diagrama. Por ejemplo, en un diagrama se distinguiría claramente entre un elemento de un pedido y un elemento de un menú.

La creación del modelo ayuda al equipo a hacerse preguntas que, de lo contrario, no se haría hasta mucho más adelante en el desarrollo. Algunas técnicas incluyen lo siguiente:

• Preguntar las cardinalidades en un diagrama de clases (por ejemplo, "¿Puede aparecer un elemento de menú en más de un menú? ").

• Preguntar sobre los bucles del diagrama de clases (por ejemplo, "En un pedido, ¿son todos los elementos del mismo menú? ").

Las respuestas a estos tipos de pregunta se pueden agregar como comentarios al diagrama.

Coherencia del modelo

El equipo puede resolver las ambigüedades si se asegura de que los casos de modelo y de usuario son coherentes:

• En los casos de usuario se usan los términos que se definen en el modelo y son coherentes con las relaciones definidas. Si el modelo define los elementos de menú, en los casos no se debe usar el término "productos" para indicar lo mismo. Si en el diagrama de clases se muestra que un elemento de menú pertenece exactamente a un menú, los casos no deben hacer referencia a compartir un elemento entre menús.

• En cada caso de usuario se describe una serie de pasos que los diagramas de actividades permiten.

• En los casos de usuario o en las actividades, se describe cómo se crea y se destruye cada clase y cada relación en el diagrama de clases. Por ejemplo, ¿qué caso de usuario crea un elemento de menú? ¿Cuándo se destruye un pedido?

Modelos y trabajo pendiente del producto

El equipo puede marcar los modelos y guiones gráficos para mostrar qué elementos modificará cada caso de usuario, y puede colorear o comentar un modelo como ayuda para planear el desarrollo. Por ejemplo, el equipo podría colorear las acciones en un diagrama de actividades para indicar las que se han completado y cuáles se completarán en el siguiente sprint.

Para obtener más información, vea Crear modelos de los requisitos de los usuarios.

Modelos y pruebas

El equipo puede usar un modelo de dominio como base para las pruebas del sistema, lo que entabla una relación clara entre las pruebas y los requisitos de los usuarios. Esta relación ayuda al equipo a actualizar las pruebas rápida y correctamente, y ayuda a garantizar que el producto cumpla los nuevos requisitos.

El equipo puede vincular cualquier elemento de un modelo UML (Lenguaje de modelado unificado) a cualquier elemento de trabajo, por ejemplo, a una prueba. Cuando alguna parte del modelo cambia, el modelo ayudará al equipo a localizar las pruebas a las que está asociado.

Use el modelo de dominio como ayuda para crear las pruebas:

• Cree al menos una prueba que implique la construcción de cada tipo o asociación, por ejemplo, un elemento de menú o elemento de pedido, y al menos una prueba que implique su destrucción.

• Asegúrese de que se prueban todas las rutas de acceso descritas por los diagramas de actividades.

  Nota

  Las pruebas también deben cubrir las rutas de acceso excepcionales que no se mostrarían normalmente en los diagramas de actividades.

• Use el vocabulario de modelo de dominio para definir las pruebas. Por ejemplo, las pruebas incluirían una prueba de la acción Seleccionar elemento de menú, que comprobaría que la acción da como resultado que el Pedido contenga un nuevo Elemento de pedido. Para escribir pruebas automatizadas, puede usar clases y relaciones basados directamente en el diagrama.

Para obtener más información, vea Desarrollar pruebas en un modelo.