UNIVERSIDAD VICTORIA DE WELLINGTON

Te Whare Wananga o te Upoko o te Ika a Maui

Facultad de Ciencias Matemáticas y Computación

Ciencias de la Computación

Apartado de correos 600 Tel: +64 4 463 5341, Fax: +64 4 463 5045
Wellington Correo electrónico: Tech.Reports@mcs.vuw.ac.nz

Nueva Zelanda http://www.mcs.vuw.ac.nz/research

Patrones para casos de uso esenciales

Robert Biddle, James Noble, Ewan Tempero

Ciencias de la Computación,

Universidad Victoria de Wellington, Nueva Zelanda.

robert, kjx, ewan @ mcs.vuw.ac.nz

Informe técnico CS-TR-01/02

Abril de 2000

Resumen

Los casos de uso esenciales son una forma eficaz de analizar los requisitos de usabilidad de un sistema en desarrollo. Los

casos de uso esenciales están bastante estilizados: escribir buenos casos de uso esencial es un arte secreto. Este documento

presenta los conceptos básicos de la redacción de casos de uso esenciales en forma de patrón. Los lectores de este documento

podrán escribir mejores casos de uso esenciales rápidamente, lo que facilitará la especificación de sistemas utilizables.
Introducción
Los sistemas deben ser utilizables. Si las personas no pueden usar los
sistemas que diseñamos, los evitarán, eludirán, menospreciarán y
sabotearán.
En los buenos tiempos de la informática, la gente estaba tan
patéticamente agradecida de tener cualquier tipo de sistema
informático que estaban muy felices de esperar en largas colas,
recoger impresiones varios días después de que se enviaran sus
trabajos, escribir programas en teclados de chicklet, y hacer todo tipo
de estupideces. Desafortunadamente para nosotros, los tipos de
desarrollo, estos días han terminado. En un número cada vez mayor
de sistemas, la usabilidad de un sistema es primordial: Si lo
construye, no vendrán si no pueden usarlo.
La Figura 1 resume los problemas tratados por esta
colección de patrones y las soluciones que brindan. En aras
del espacio, solo se presentan los esquemas básicos del
segundo grupo de patrones. Estos cubren la mecánica de
escribir casos de uso esenciales, organizarlos y
encontrarlos.
El contenido de estos patrones no es novedoso, más bien, este
documento es un intento de proyectar algunas de las técnicas del Diseño
Centrado en el Uso (extraídas particularmente de Software de uso) en
forma de patrón.
Ejemplo
Los patrones de este documento utilizan ejemplos extraídos de un

sistema de reserva simple para un centro de artes. El resumen inicial de

Esta lección se ha escrito en gran medida recientemente este sistema es el siguiente:

después de las fallas de varios sitios web de comercio de Internet

de alto perfil: si el sitio no se puede usar, nadie lo usará. Pero es Diseñar un programa para la oficina de reservas de un

cierto incluso para los sistemas administrativos establecidos por centro de artes. Hay varios teatros y las personas pueden

departamentos gubernamentales o grandes corporaciones o reservar asientos en cualquier teatro para cualquier

sistemas integrados y de consumo: si usar el sistema requiere evento futuro. Las personas deben poder discutir la

mucho esfuerzo, las personas que necesitan usarlo encontrarán disponibilidad de asientos, dónde se encuentran los

alguna otra forma de lograr sus objetivos, a menudo en su gasto. asientos y cuánto cuestan. Cuando las personas toman
una decisión, el programa debe imprimir el precio,
registrar la selección e imprimir un boleto.

La disciplina del Diseño Centrado en el Uso se ha introducido para incorporar la usabilidad en los procesos de desarrollo de
ingeniería de software. Descrito en Constantine & Lockwood's Software de uso Normalmente, esperaríamos tener mucho más [8], el
diseño centrado en el uso se basa en esencial información (ya sea más texto, o al menos la opción

casos de uso, y se basa en ideas de la oportunidad orientada a objetos para hablar con el patrocinador del proyecto). La metodología [11, 15, 7, 2], así
como el análisis de tareas, presentaremos más detalles a medida que avanza el ejemplo.

y técnicas de creación de prototipos comunes a los diseñadores de interacción

entre humanos y computadoras. Una característica clave del diseño centrado Formar

en el uso es que el profesional del diseño actúa como defensor de los

Los patrones están escritos en forma Portland eléctrica modificada.
usuarios, asegurando que la preocupación por la usabilidad se mantenga
Cada uno comienza con una pregunta (en cursiva) que describe un
durante todo el ciclo de desarrollo.
problema, seguida de una lista con viñetas de fuerzas y una discusión
de los problemas que aborda el patrón. Una negrita " Por lo tanto: ”Introduce
Los casos de uso esenciales están bastante estilizados, y
la solución (también en cursiva) seguida de las consecuencias de
escribir buenos casos de uso esencial es un arte secreto. Este
usar el patrón (los beneficios positivos primero, luego los pasivos
documento presenta los conceptos básicos de la redacción de casos
negativos, separados por una negrita Sin embargo:), un ejemplo de
de uso esenciales en forma de patrón. Los patrones se dividen en dos
su uso y algunos patrones relacionados.
grupos. El primer grupo se presenta con todo detalle y consta de seis
patrones básicos. Los primeros cuatro patrones describen cómo
identificar a los actores en un sistema y encontrar y priorizar casos de
uso. Los siguientes dos patrones describen cómo escribir diálogos
Usos conocidos
para cada caso de uso y cómo verificar esos diálogos usando juegos
de rol. Es estándar enumerar los usos conocidos de cada uno de los patrones.

En el caso de nuestros patrones, el conocido

1
 Patrón Problema Solución

¿Por dónde empezar el modelo de caso de uso? ¿Empiece con las personas (y otros sistemas) elling?
Actores
quién utilizará realmente el sistema.

Caso de uso candidato ¿Cómo se determina qué

Lista Casos de uso candidatos para cada actor.
Lista debe hacer el sistema?

¿Cómo puede gestionar una gran selección focal casos de uso para impulsar el diseño. cantidad de casos de uso?
Casos de uso focal

¿Cómo saber cuándo lo usas? Dibuja un diagrama de caso de uso para mostrar cómo se completan las accases?
Use el diagrama del caso
tors y casos de uso están relacionados.

¿Cómo puede describir lo que implica cada uno de los diálogos de casos de uso esenciales de Write para cada caso de uso?
Diálogos de casos de uso
caso de uso.

¿Cómo puede comprobar que el caso de uso Actúe en cada caso de uso antes de que una audiencia de los diálogos sea
Roleplay de casos de uso
correcta? Equipo de desarrollo.

Figura 1: Resumen de los patrones

Sistema utilizable

Casos de uso de CRUD

Casos de uso de informes

Caso de uso
Actores
Uso candidato Caso de uso Caso de uso
Juego de rol
Casos Diagrama Diálogos

Focal
Casos de uso

Solicitud Monitor de alarma Reporte

Confirmando
Incitación Paso

Figura 2: Los inicios de un lenguaje de patrones. Las flechas muestran el usos relación entre patrones. Sistema utilizable representa
todo el conjunto de patrones.

todos los usos son muy parecidos, por lo que hemos elegido 1 Encontrar casos de uso
discutirlos aquí.
Los patrones que describimos se han mostrado en Los primeros patrones describen cómo encontrar el uso de un número de proyectos en
los que hemos estado involucrados, casos en su sistema. Los primeros cuatro patrones incluyen el proyecto Siemens Step7Lite (para un
programa sobre la exploración del territorio, haciendo un entorno de gramática aproximada para la programación lógica del terreno que cubrirá
con más detalle los controladores), proyectos para la gestión de telecomunicaciones. patrones. Estos patrones también se refieren a la planta de
operaciones y la gestión de las solicitudes de servicio, la determinación del alcance, la toma de decisiones sobre lo que es (y los coros
académicos y de la industria.
lo que no está) dentro del sistema a construir. Los dos últimos
patrones son en realidad solo prototipos. Nosotros

2
Hemos notado que es bastante fácil pasar por alto casos de uso para
situaciones realmente comunes, casi aburridas, y hemos descubierto
que estos dos patrones son útiles para evitar este tipo de error.
1.1 Actores
¿Dónde comienza el modelado de casos de uso?
Tienes que empezar a modelar en alguna parte.
Puede haber muchas partes interesadas involucradas en el
desarrollo.
El tiempo de comercialización puede requerir un desarrollo muy
rápido.
Los problemas tecnológicos pueden ser primordiales.
Puede ser muy importante que interactúe con los sistemas
heredados.
Las partes interesadas pueden tener diferentes prioridades que los
usuarios.
Cada ejercicio de análisis, diseño o modelado debe comenzar en
alguna parte; sin embargo, a menudo no es obvio por dónde debe
comenzar. Empezar por el principio es un buen consejo si está
contando una historia o leyendo una novela; pero el "comienzo" de un
proyecto de desarrollo no es necesariamente el mejor lugar para
comenzar a modelar para ese proyecto. Normalmente, los proyectos
comienzan cuando uno o más interesados acordar sobre la necesidad
de desarrollo, pero las necesidades o los sueños de las partes
interesadas pueden no ser un buen lugar para comenzar. Por ejemplo,
pueden especificar soluciones particulares y detalladas ( "El sistema de
reservas debería ejecutarse en los nuevos teléfonos WAP de Nokia") en características, por lo general refiriéndose a manuales existentes o
lugar de los requisitos reales ( “Los horarios de las sesiones de teatro
deben ser accesibles a través de Internet”).
Más en serio, aunque por razones políticas las partes interesadas
pueden estar nominalmente de acuerdo en la importancia de un proyecto
en particular, pueden estar en total desacuerdo sobre para qué debería
ser el sistema, qué hará, qué se requiere para que sea un éxito, etc. . Las
partes interesadas también pueden poner trampas explosivas en un
proyecto de desarrollo antes de que se inicie insistiendo en que los
requisitos de tiempo de comercialización excluyen cualquier análisis,
modelado o diseño; o es posible que el sistema deba interactuar con los
sistemas heredados; o
3
cumplir estrictos desafíos tecnológicos o de recursos.
Por lo tanto: Comience con las personas (y otros sistemas) que
realmente usarán el sistema.
Una de las tareas más importantes en la definición de un
sistema es averiguar qué es el sistema (y, a la inversa, qué no es).
Hacemos esto considerando el Actores del sistema, es decir, las
personas (y otros sistemas) que son fuera de el sistema que
construiremos, pero que interactúan directamente con eso.
Primero, mediante lluvia de ideas, análisis textual,
entrevistas con clientes y actividades similares, elabora una lista de
los tipos de personas que utilizarán el sistema. Una vez que tenga la
lista, determine brevemente las características de cada usuario. Más
especialmente, debe intentar comprender los objetivos o intenciones
de los usuarios al usar el sistema, y luego las características
acterizar en detalle diferentes tipos de actores. Por ejemplo,
considere:
conocimiento de los actores del dominio
su conocimiento esperado del sistema que diseñará
si utilizarán el sistema con frecuencia o con poca frecuencia
cualquier requisito de soporte especial
Si los sistemas heredados son importantes, debe
también enumere el actores del sistema, es decir, los sistemas
importantes con los que tiene que interactuar. Luego, debe
caracterizar a los actores del sistema, describiendo sus
definiciones de protocolo.
Finalmente, debe priorizar aproximadamente a los actores en
términos de su importancia para el sistema en su conjunto.
Ejemplo
Al considerar quién usaría el Arts Center Booking System (ACBS),
un problema importante se hace evidente de inmediato: ¿este
sistema solo será utilizado por el personal del Arts Center o estará
disponible para los clientes (por ejemplo, como un quiosco o sitio
web? )? La respuesta a esta pregunta tendrá un impacto
significativo en la naturaleza del sistema, por lo que es mejor que
se responda rápidamente.
En el caso de nuestro ejemplo, no hay información suficiente
para responder a esta pregunta, por lo que tendríamos que volver al
patrocinador para averiguarlo.
Asumiremos que el sistema solo será utilizado por el personal del
Arts Center.
Simplemente enumerar al personal en el Centro de Artes da
una buena idea de los posibles actores. Dicha lista podría incluir: las
personas en la taquilla que realmente venden las entradas
(vendedores de entradas), la persona a la que le importa qué tan
bien van los eventos, como las tasas de asistencia a las
presentaciones (gerente comercial), la persona a cargo de qué
eventos están y qué representaciones hay (gerente de eventos), la
persona a cargo del centro de artes (director gerente), la persona a
cargo de finanzas (contador) y posiblemente otras personas de la
Sistema de contabilidad: Hablando con el Contador
organización (personal de administración). Y, por supuesto, también
están los patrocinadores del centro de artes, que claramente tienen
un interés en lo que hace el sistema. De esta lista, podemos hacer
un primer corte en nuestra lista de actores.
en absoluto, y así conseguirá que otra persona produzca
los informes que necesita del sistema. Sin embargo, esto
no significa que no haya un Actor Gerente de Negocios,
sino que hay alguien que desempeña ese papel. Por esa
razón, este actor no tendrá mucho conocimiento sobre el
dominio (en este caso, cuáles son las preocupaciones del
gerente comercial), o no tendrá mucho conocimiento
sobre el sistema (o posiblemente ambos).
tante, descubrimos que su único interés en el sistema
propuesto es obtener la información de ventas y, de
preferencia, le gustaría que se entregara directamente al
sistema contable existente. Suponiendo que este sistema
tiene la capacidad de interactuar con otros sistemas
informáticos, sería una actor del sistema para el sistema
propuesto.

Vendedor de boletos: Esta es la persona que vende tick-

ets, realiza reservas y responde a las consultas de los clientes sobre eventos en el

Centro de Artes Consecuencias

tre. Las personas que desempeñan este papel a menudo serán

personal ocasional, por lo que no se puede asumir que simplemente determina quiénes son los usuarios reales del sistema

tener mucho conocimiento del dominio. Por otra parte, pueden responder algunas preguntas importantes sobre la otra parte,
son empleados y, por lo tanto, lo que el sistema tendrá que hacer (o no). algún nivel mínimo de conocimiento del dominio
Averiguar a quién más le importa lo que se puede asumir el sistema (por ejemplo, a través del personal, incluso si nunca lo
usarán directamente, capacitación). No se espera que sepan que también pueden identificar rápidamente funciones
importantes. algo sobre los sistemas informáticos, pero muy pocos sistemas están construidos para ser independientes de

cualquier sistema existente en estos días, e interconectando

utilizará el sistema con mucha frecuencia.
con los sistemas existentes es a menudo la fuente de muchos
Ya hemos determinado que las artes frustran los problemas, por lo que es importante identificar a los usuarios que no usarán
directamente el sistema, estos sistemas temprano. Lo que el cliente quiere es que, sin embargo, tenga expectativas del portante,
por supuesto, es importante para usted, pero si qué vendedor de boletos, lo que se traducirá en el boleto que el cliente desea, es
diferente de las expectativas del vendedor de los usuarios del sistema.

desea, entonces debería saberlo tan pronto como

Administrador de evento: Esta es la persona que decide lo posible.

Sin embargo:
qué eventos se reservan en el centro de artes, cuándo ocurren las
La identificación de los actores requiere tiempo y esfuerzo, no solo
representaciones (o no), dónde se llevan a cabo y cuál es la
de los modeladores sino también de las partes interesadas y, por
disposición de los asientos. Las personas que desempeñan este
supuesto, de los usuarios reales. Obtener acceso a los usuarios puede
papel tendrán mucho conocimiento sobre los eventos y aspectos
ser difícil, especialmente si no son empleados de las instituciones de las
relacionados del trabajo, pero no se puede suponer que tengan
partes interesadas, y muchos actores no disfrutarán de ser objeto de
mucho conocimiento sobre los sistemas informáticos. Utilizarán el
análisis. Los usuarios de modelos también pueden irritar a las partes
sistema varias veces a la semana, pero probablemente no tan a
interesadas si no consideran a los usuarios una alta prioridad. Es
menudo como una vez al día.
posible que prefieran que su dinero se gaste en algo útil, como la

programación.

Gerente de negocios: El director comercial real

probablemente no quiera tocar el sistema

4
Discusión construir un sistema que sea utilizable por actores particulares a menudo

hace que su trabajo Más fuerte en lugar de más fácil, ya que tener que
Tenga en cuenta que consideramos solo los llamados actores
preocuparse por las personas que usarán un sistema es solo otro
directos, es decir, los actores que utilizan el sistema en sí. A
problema además de todos los problemas técnicos o administrativos de
menudo puede haber actores indirectos que utilizan el sistema en
hacer que cualquier tipo de sistema funcione.
nombre de otra persona; podemos anotarlos al no preocuparnos
principalmente por ellos.
Entonces, el solo hecho de conocer a los actores no ayuda a
determinar lo que un sistema debería realmente hacer. Lo que
Comenzar con actores puede ayudar a generar un sistema
necesita saber es qué deben lograr los actores con el sistema,
utilizable, pero puede hacer poco para aplacar a las partes
cuáles son sus intenciones u objetivos y qué responsabilidades
interesadas. Algún tipo de modelado o análisis de los objetivos y
incumben al sistema para apoyarlos.
requisitos de las partes interesadas, y el análisis de riesgos en curso
en todo el proyecto son prácticas importantes para todos los
De manera similar, las listas de requisitos ("listas de deseos")
proyectos; sin embargo, son actividades separadas de (y no
elaboradas por las partes interesadas o el departamento de marketing
sustituyen) el inicio del modelado mediante el análisis de los objetivos
suelen ser muy informales, imprecisas e irregulares, y combinan
y características de la gente pobre que tendrá que soportar el sistema
información grande y pequeña, detallada y vaga, importante e irrelevante
como parte de su vida.
en un solo documento.

Por supuesto, las partes interesadas todavía quieren que deje de

1.2 Lista de casos de uso de candidatos
hacer tonterías y entregue el sistema ayer.

¿Cómo se determina lo que debe Por lo tanto: Lista Casos de uso candidatos para cada hacer?
Actor.

Un caso de uso es un caso completo de uso del sistema. En

Tienes que empezar a modelar en alguna parte.
otras palabras, un caso de uso describe un sin-

Puede haber muchas partes interesadas involucradas en el secuencia de interacción entre un actor y un sistema. Desde el
desarrollo. punto de vista del actor, el nuevo sistema debería parecer una
“caja negra”, que exhibe solo comportamiento, sin
El tiempo de comercialización puede requerir un desarrollo muy
funcionamiento interno visible. Un caso candidato debe ser
rápido.
breve y sencillo, con lo suficiente para ser significativo.
Los actores no describen mucho sobre los requisitos
Algunos ejemplos son:
de un sistema.

Las ideas de las partes interesadas sobre lo que debería hacer el sistema
poner el texto en negrita
se expresan de manera informal.
imprimir su trabajo reiniciar
Los actores a menudo no pueden decir lo que quieren que haga el
una PC
sistema.

Es necesario que exista alguna forma de obtener una estimación del
tamaño del sistema para la planificación.
Tiene que haber alguna forma de decidir qué es
necesario para el sistema y qué características serían
agradables.
Las partes interesadas pueden tener diferentes prioridades que los
Cualquier sistema no trivial tendrá muchos casos de uso, y
tomará un tiempo determinar cuáles se aplican realmente a su
sistema, así que identifique tantos candidato casos de uso lo más
rápido posible. Un caso de uso candidato es justo lo que dice, algo
que puede convertirse en un caso de uso, pero no hay ningún
compromiso de que sea así en esta etapa.

usuarios.
Las partes interesadas pueden tener expectativas poco realistas.
Los problemas tecnológicos pueden ser primordiales.
En realidad, encontrar o determinar los casos de uso no es fácil
e implica toda la vaguedad e incertidumbre del análisis. Para
encontrar casos de uso, puede utilizar el conocimiento del dominio,
el análisis textual de listas de deseos u otros documentos,
estándares, otros

Lamentablemente, los actores son parte del problema, sistemas y entrevistar a las partes interesadas y a las personas que

no de la solución. Sabiendo que tienes trabajan en el dominio. Lo más importante, tú

5
Debe buscar usuarios potenciales del sistema, y tratar de lista de requisitos de tamaño aleatorio. También se pueden utilizar para

comprenderlos, así como sus objetivos e intenciones. derivar casos de prueba, estimar el esfuerzo (mediante el seguimiento del

número de casos de uso completados frente al tiempo invertido en cualquier

etapa) y para guiar la documentación.

Ejemplo
Sin embargo: La identificación de casos de uso candidatos para los
Mirando el texto y nuestra lista de actores, podemos encontrar
actores requiere tiempo y esfuerzo, lejos del desarrollo más obviamente
rápidamente un conjunto inicial de casos de uso:
"productivo" o del trabajo de generación de ingresos de los usuarios y las

partes interesadas. Enumerar casos de uso puede parecer inútil para las
Vendedor de boletos: Emitir boleto, Mostrar asiento disponible
partes interesadas que ya "saben lo que debe hacer el sistema". es-
mostrar ubicación del asiento, mostrar precio del asiento

Administrador de evento: Agregue eventos, programe el rendimiento, especialmente si ya tienen otros tipos de listas

Modificar la información de rendimiento

de requisitos para el sistema, y si resulta que esas listas
son incorrectas.
Gerente de negocios: Imprimir reporte

Discusión
Contador: Imprimir información de ventas

Los casos de uso fueron descritos por primera vez por Jacobson para
Este es solo un primer corte, basado en el texto que teníamos disponible para trazar los sistemas de telecomunicaciones daneses.

Podemos agregar fácilmente a esta lista, para Erricson [11]. Hay varios ejemplos de otros libros aplicando los patrones de la sección 3. Al

describir los casos de uso y su uso en la digitalización de software, también consideraríamos cambiar el nombre de qué desarrollo [13, 7,

1].
tenemos que hacerlos más consistentes. Un mayor
En la figura 3 se muestra un conjunto de casos de uso.
Patrones relacionados

Los patrones enumerados en la sección 3.

Consecuencias

Una lista de casos de uso puede darle una buena idea 1.3
Casos de uso focal
sobre lo que debe hacer el sistema y, por lo general,
bastante fácil de crear rápidamente un conjunto que Cómo ¿Puedes gestionar una gran cantidad de casos de uso?

representativo de lo que realmente quieren las partes interesadas.

La búsqueda de casos de uso debe involucrar a las partes Incluso un sistema pequeño puede tener una gran cantidad de casos

interesadas y a los miembros del equipo de usuarios, e incorporar de uso candidatos.

a estas personas en el proceso tiene la ventaja de que estarán

Algunos casos de uso serán fundamentales para el sistema,
mejor dispuestos hacia el proyecto (siempre que sean tratados con
mientras que otros son solo periféricos.
un mínimo de respeto).
La implementación de diferentes casos de uso puede requerir más (o

menos) esfuerzo.
Los casos de uso son lo suficientemente informales como para

permitir una buena comunicación con las partes interesadas, dándoles la Los diferentes casos de uso pueden ser más (o menos) riesgosos de

sensación de que comprenden lo que realmente hará el sistema. Esto implementar.

aumenta su confianza en el proyecto. Los casos de uso también son Algunos casos de uso son más importantes para los usuarios que
bastante específicos al detallar lo que el sistema tiene que hacer, otros
reduciendo así los malentendidos y la ambigüedad que a menudo se
Algunos casos de uso son más importantes para las partes interesadas
asocian con los requisitos informales.
que otros

La lista de casos de uso también da una buena idea del tamaño
del sistema en general. Debido a que cada caso de uso debe tener la
misma granularidad, describiendo aproximadamente la misma
"cantidad" de interacción con el sistema, una colección de casos de
uso dará una mejor idea de la complejidad de un sistema que una
Los casos de uso esencial candidatos son bastante pequeños,
cada describir un curso de uso de un sistema.
Debido a esto, puede haber un gran número de ellos, tal vez
40-50 para un sistema pequeño y 200300 para un sistema de
tamaño mediano. Esto plantea otro problema: ¿cómo
gestiona y prioriza

6
estos casos de uso. En particular, ¿cómo sabe por dónde empezar con
la siguiente parte del diseño? Algunos casos de uso son más iguales
que otros casos de uso. Pueden tomar más tiempo (o imponer más
riesgo) para implementar, pueden ser más importantes para los actores
(por ejemplo, porque se realizarán con más frecuencia que otros casos
de uso), o pueden ser más importantes para las partes interesadas (por
sus propias razones impenetrables). ). ¿Cómo puede aplacar a los
desarrolladores (que ya piensan que esto es demasiado grande y
demasiado difícil de construir) sin dejar de honrar a las partes
interesadas (que están pagando por esto, después de todo)?
Por lo tanto: Escoger focal casos de uso para impulsar el diseño.
No es fácil elegir en qué trabajar primero. Todos tienen su propia
idea de lo que es importante. Por eso no decimos "importante",
decimos "focal": elegimos centrarnos en estos casos de uso para
impulsar el diseño. Los casos de uso focal son típicamente aquellos
que son los más importantes para los usuarios, pero también incluyen
casos de uso para cubrir las principales responsabilidades con las
partes interesadas y cubrir los riesgos expresados por el desarrollo.
Para identificar los casos de uso focales, puede imprimir la lista
de cada caso de uso y luego trabajar rápidamente en la lista varias
veces, cada vez dando a cada caso de uso una puntuación (digamos
de 1 a 5) para un aspecto particular de importancia, como como:
frecuencia de uso, importancia para las partes interesadas, riesgo para
el desarrollo, etc. Varios desarrolladores pueden clasificar rápidamente
cada aspecto en paralelo, aunque es útil tener dos o tres estimaciones
de cada aspecto. Luego, sume los puntajes para cada aspecto, ordene
los casos de uso en diferentes combinaciones de puntajes de aspecto
(una hoja de cálculo es útil aquí) y luego elija el orden que parece tener
más sentido. El 10% superior de los casos de uso (hasta un máximo de
20) son sus casos de uso focales.
Al tomar esta decisión, es útil trabajar hacia un sistema
mínimamente útil, es decir, uno que pueda ser útil para algunos de los
usuarios. La razón de esto es que algunos casos de uso identificados
como focales pueden depender de otros casos de uso. Por ejemplo,
"retirar efectivo" no se puede hacer de manera útil sin efectivo en el
cajero automático, lo que implica que también se necesitará un caso
de uso como "agregar efectivo a la caja".
7
Ejemplo
Incluso una versión simple de nuestro Arts Center Booking System
podría tener 50 casos de uso, pero una versión que aún podría ser útil
puede que solo necesite implementar una docena de ellos. Por ejemplo:
Vendedor de boletos: Lista de actuaciones de eventos, compra
Entradas, informar la disponibilidad de los asientos, informar los
detalles del evento, mostrar la ubicación de los asientos
Administrador de evento: Agregar evento, programar nuevo período
formance
Esto no permite reservar asientos, cancelar eventos o informar
sobre la venta de entradas, pero aun así daría una muy buena idea de
lo que es el sistema final.
podría ser capaz de hacer.
Consecuencias
La clasificación de casos de uso y la búsqueda de casos de uso
focales le dan una buena idea de dónde ir a continuación en su
diseño. Ayuda a reducir el riesgo al concentrarse en los casos de
uso que tienen más probabilidades de producir un diseño que será
de mayor utilidad. Los casos de uso no focales no afectarán mucho
el diseño cuando se implementen, o no afectarán la utilidad del
sistema si no se implementa.
Sin embargo: Dar prioridad a los casos de uso puede dar una falsa
sensación de seguridad: el sistema se describe en todos los casos de uso, no
solo en los focales. Hacer que algunos casos de uso tengan una mayor
prioridad implica hacer que otros tengan una menor prioridad y correr el riesgo
de alienar a las partes interesadas que defienden esos casos de uso.
Patrones relacionados
El juego de planificación de programación extrema [4] es una versión
incremental de la misma idea, en la que los programadores y los
representantes de los clientes (partes interesadas) discuten de forma
constructiva sobre qué casos de uso priorizar en una iteración
determinada. Desde una perspectiva centrada en el uso, existe un
peligro en este proceso: si el cliente no es un usuario, entonces nadie
representa los intereses de los usuarios, de la misma manera que nadie
representa los intereses de un niño mientras su madre y su padre
discuten sobre el divorcio. Una responsabilidad importante y explícita de
un profesional del diseño centrado en el uso es equilibrar los intereses
en competencia de los desarrolladores, las partes interesadas y los
usuarios, con la prioridad clave para los usuarios.
1.4 Diagramas de casos de uso (dentro del sistema) resaltar las formas en que los usuarios
interactúan con el sistema.
¿Cómo sabe cuándo están completos sus casos de uso?

Discusión

Puede seguir modelando para siempre, pero claramente con Utilizando el diagrama, hágase explícitamente las siguientes
rendimientos decrecientes. preguntas:

Si se detiene demasiado pronto, es posible que se pierda cosas

¿Existe un actor que represente a cada tipo de usuario que
importantes.
utilizará el sistema?
Si se detiene demasiado tarde, desperdicia recursos.
¿Existe un actor de sistema para cada sistema heredado
Es fácil obtener muchos detalles de los modelos que está con el que este sistema debe combinarse?
construyendo.

Debe convencer a las partes interesadas y a otros miembros del ¿Puede cada actor hacer todo lo que necesita hacer utilizando solo los
equipo de que el modelado está hecho. casos de uso con los que están relacionados?

El análisis de sistemas sería un gran trabajo si nunca tuviéramos

¿Faltan casos de uso obvios? Por ejemplo, los
que entregar nada. En un proyecto de cualquier tamaño, puede seguir
modelos de casos de uso suelen ser simétricos: si hay
modelando para siempre, pero (visto desde fuera) el modelado continuo
casos de uso para crear reservas, imprimir recibos de
tiene rendimientos claramente decrecientes. Las partes interesadas no
reserva, imprimir recibos de rendimiento y cancelar
quieren pagar por modelos innecesarios, pero, de nuevo, pueden
actuaciones, quizás también debería haber casos de
considerar alguna modelado innecesario. Entonces, ¿cómo puede saber
uso para cancelar reservas y crear actuaciones.
cuándo tiene suficientes casos de uso

- para que puedas parar? Por el contrario, ¿cómo sabe cuándo no

tiene suficientes casos de uso, de modo que no termine revisando
cosas obvias que se ha perdido? Las respuestas a estas preguntas A menos que esté en un sistema pequeño (si no tiene más de

deberán convencer a otros miembros del equipo, partes 15-20 casos de uso), dibuje un diagrama de caso de uso para cada
interesadas, etc., entonces, ¿cómo debería presentar sus modelos actor (o para algunos actores relacionados), en lugar de un diagrama
de casos de uso para hacer estos argumentos? para todo el sistema.

Por lo tanto: Dibuje un diagrama de casos de uso para mostrar cómo se

relacionan los actores y los casos de uso.
Un diagrama de casos de uso muestra figuras de palo para los
actores dentro del sistema y óvalos para cada caso de uso.
Escribimos las descripciones de los usuarios a su lado y los nombres
de los casos de uso dentro de los óvalos. Los usuarios involucrados
en casos de uso particulares están conectados a esos casos por
líneas. Dibuje un cuadro (el "cuadro del sistema") que describa todos
los casos de uso, para aclarar los límites del sistema que se va a
diseñar.
Ejemplo
La Figura 3 muestra un diagrama de casos de uso para el sistema de
reservas Arts Center.
Consecuencias
Un diagrama de casos de uso proporciona una vista gestalt del sistema,
que muestra no solo las partes del sistema, sino que también da una idea
de cómo podrían interactuar las partes. También es útil para los nuevos
miembros del equipo que se incorporan a un proyecto y para convencer a

Un diagrama de casos de uso es bastante simple, pero puede tener
un propósito sutil. Al representar a los usuarios y el conjunto de casos de
uso, el diagrama puede ser un enfoque útil para las actividades para
verificar el modelo de casos de uso. El cuadro alrededor de los casos de
uso aclara la naturaleza de "caja negra" del sistema, y las líneas entre
los interesados que tienen problemas con los documentos escritos pero
les gustan las imágenes. Más importante aún, el proceso de dibujar y
mirar un diagrama puede ayudarlo a familiarizarse con el modelo en su
totalidad, a encontrar casos de uso faltantes o duplicados, actores
faltantes y

los usuarios (fuera del sistema) y los casos de uso

8
 Figura 3: Diagrama de un caso de uso que muestra los límites del sistema.

pronto. Las grandes organizaciones con procesos formales de diagramas de casos de uso con más detalle [8]. Jacobson y col. utilice una caja

desarrollo o certi fi cación ISO generalmente requieren aprobaciones y del sistema [11].

estos diagramas pueden resultar convincentes aquí.

1.5 Casos de uso de CRUD

Sin embargo: Los modelos nunca están realmente completos, por lo
¿Cómo se obtiene un conjunto completo de casos de uso?
que dibujar diagramas puede volver a dar una falsa sensación de seguridad.

Dibujar bonitos diagramas puede convertirse en un fin en sí mismo, en lugar de

una herramienta para ayudar al modelado, especialmente si está orgulloso de Hay muchos usos, incluso en un sistema pequeño.
su destreza con una herramienta CASE.

Muchos casos de uso se utilizan con poca frecuencia y

son "no críticos" para comprender lo que hará el sistema
Patrones relacionados
en general, pero son necesarios para una descripción
UMLDistilled [9] presenta brevemente los diagramas de casos de uso. completa.
Software para uso describe más complejos

9
 Incluso para un sistema pequeño, puede haber una mayor cantidad (por lo que debería recibir una prioridad baja). Por ejemplo, los casos de uso de

de casos de uso de lo que podría esperar inicialmente. Un error común que Eliminar a menudo se pueden dejar fuera de las primeras versiones.

cometen las personas es identificar un caso de uso que saben que

necesitan, pero pasan por alto los casos de uso relacionados. Por ejemplo, No todos los casos de uso de CRUD son necesarios para cada

puede haber un caso de uso para mostrar todos los detalles sobre un tipo concepto, por lo que el análisis CRUD no debe aplicarse a ciegas.

particular de registro, pero ningún caso de uso que realmente cree

registros. También perderán por completo un conjunto de casos de uso que
se aplican a un concepto en el modelo de dominio.
Por lo tanto: Aplicar el análisis CRUD a cada uno de los conceptos de
No se debería aplicar el análisis CRUD a todas las clases del
modelo de dominio. Por ejemplo, "Período de tiempo" puede ser
una clase sensata, pero este concepto nunca se requiere por sí
solo en la aplicación, por lo que no hay necesidad de casos de
uso solo para tratar con él.

dominio apropiados.

Mire los casos de uso que tiene y determine si alguno de

ellos corresponde a un Crear, leer, actualizar, o Eliminar ( CRUD)
de clase en el modelo de dominio. Si encuentra alguno en esta
categoría, compruebe si se necesita alguno de los otros casos
de uso de CRUD.
Usos conocidos
Alistair Cockburn habla sobre casos de uso de CRUD y cómo
presentarlos. Aboga por agruparlos a todos como un caso de uso
único, por ejemplo, un caso de uso “Modificar” [7].

Ahora considere el resto de las clases en el modelo de dominio y

verifique que también deberían tener casos de uso de CRUD. 1.6 Casos de uso de informes

¿Cómo obtener un conjunto completo de casos de uso para informar

Cambie el nombre de estos casos de uso si los nombres estándar no
información?
tienen sentido.

Los informes son muy importantes para muchos sistemas

Ejemplo

Considere "Evento" en la ACBS. Un caso de uso razonable sería

Informar es aburrido para los implementadores, por lo que
"Mostrar detalles del evento". Esto es realmente " Leer Evento". Si
pueden subestimar el esfuerzo requerido para producir
tenemos esto como un caso de uso, entonces podríamos querer lo
informes.
siguiente: " Crear
Los informes también pueden ser aburridos de modelar.
Evento ”,“ Eliminar Evento ”y“ Actualizar Evento".
También puede haber casos de uso relacionados. Por La presentación de informes suele ser aburrida para uno de los

ejemplo, otra forma de Crear algo es para usuarios o partes interesadas, pero al mismo tiempo es crucial para

Copiar (por ejemplo, "Reprogramar evento"), y puede haber más los demás.

de una forma de Eliminar algo (por ejemplo, "Cancelar evento",

donde los detalles del evento no se eliminan realmente del Por lo tanto: Asegúrese de tener al menos veinte casos de uso de

sistema). informes.

Podría tener sentido cambiar el nombre de algunos de los casos de uso

Aunque informar es aburrido, si es importante para alguien, tienes
("Modificar detalles del evento" en lugar de "Actualizar evento").
que modelarlo. Esto también garantizará que capture todos los casos

importantes sobre los que alguien necesitará informar y garantizará que

sus estimaciones de esfuerzo sean correctas si está utilizando casos de

Consecuencias uso para impulsar la estimación.

La aplicación del análisis CRUD puede obtener rápidamente muchos

casos de uso relevantes sin requerir mucho esfuerzo. De hecho, el

Ejemplo
análisis CRUD es susceptible de automatización.

La Figura 3 solo tiene dos casos de uso de informes ("Informe de

Sin embargo:
ocupación" e "Informe de ventas mensuales"), aunque algunos otros
Puede obtener rápidamente una gran cantidad de casos de uso,
también pueden considerarse informes (por ejemplo, "Informe de
muchos de los cuales no se necesitan de inmediato
disponibilidad de puestos".

10
Los casos de uso de informes pueden incluir: “Informe de ocupación por
teatro”, “Informe de ocupación por evento,“ Informe de ocupación por
desempeño ”,“ Informe de ocupación por semana ”, todos los cuales
serían de interés para el Gerente Comercial. Sin embargo, tipos
similares de informes (casi con certeza organizados de manera
diferente) serían útiles para el atareado vendedor de boletos que tuviera Lista de casos de uso (1.2), identificó el Casos de uso focal (1.3),
que responder preguntas del tipo "¿Hay suficientes asientos libres para
la actuación de Drácula de mañana?".
Consecuencias
En realidad, no es necesario encontrar 20 casos de uso de informes, el
punto principal es que el simple hecho de ser forzado a intentar llegar a
20 (o el número que sea en realidad) casos de uso de informes casi
siempre produce casos de uso que no estaban ya enumerados, pero
instantáneamente reconocible como crucial para el sistema.
Sin embargo:
A veces es demasiado fácil proponer muchos casos de
uso de informes, cuando solo algunos de ellos serán
necesarios en el sistema.
2 casos de uso detallados
Una vez que tenga una lista de casos de uso candidatos, debe
revisar cada uno y describirlos en detalle. Por supuesto, primero
comienza con los focales; de hecho, puede detallar los casos
focales antes de haber terminado el modelo de casos de uso
“completo”.
2.1 Diálogos de casos de uso esenciales
También conocido como: Cuerpos de casos de uso, tarjetas de casos de uso
¿Cómo puede describir lo que implica cada caso de uso?
Tiene una lista de casos de uso candidatos, pero esta
lista no proporciona muchos detalles. ¿Cómo puede
saber qué se debe implementar para cada caso de uso?
No tiene los detalles del diseño del sistema porque
aún no lo ha diseñado.
No querrá gastar demasiado tiempo o esfuerzo en
escribir documentación inútil.
No desea limitar sus opciones de implementación.
11
El tiempo de comercialización puede requerir un desarrollo muy
rápido.
Los problemas tecnológicos pueden ser primordiales.
Incluso cuando haya completado su Candidato
y tal vez revisé algunos Diagramas de casos de uso (1.4),
todavía no tiene muchos detalles sobre lo que involucrarán los
casos de uso: qué información deben proporcionar los actores y
qué comportamiento debe proporcionar el sistema para
implementar con éxito el caso de uso.
Los nombres de los casos de uso solo le dan una idea
aproximada de lo que se supone que debe hacer el sistema. Aún
debe determinar el detalle de la interacción con el sistema. Sin
embargo, no desea tener que tomar decisiones relacionadas con la
tecnología (por ejemplo, qué dispositivos de E / S estarán
disponibles, requisitos de interfaz de usuario, etc.), a pesar de la
presión de las partes interesadas para usar una tecnología particular
(probablemente cambiarán su mentes cuando comience la
implementación). Y además de eso, todavía tienes que pensar en
los detalles rápidamente.
Para abordar estos problemas, debe proporcionar más detalles
sobre cada caso de uso; pero, ¿cuánto detalle es demasiado? Podría
escribir descripciones detalladas de lo que involucrará cada caso de
uso, pero esto requerirá mucho esfuerzo, producirá una gran
cantidad de documentación densa que será difícil de administrar y
probablemente de poca utilidad para el eventual equipo de desarrollo.
Además, para poder escribir descripciones detalladas de la
interacción de cada caso de uso, es necesario que ya haya decidido
cómo se diseñará cada caso de uso, si no está ya implementado, si
esto será manejado por un sistema informático, por un trabajador
como parte de un proceso empresarial, mediante un programa de
aplicación, un sitio web o un teléfono WAP. Desafortunadamente, si
usted es el único responsable del análisis (digamos que el diseño se
subcontrata a una empresa de gráficos y la implementación a la
India), entonces no querrá tener que hacer un diseño que será
reemplazado más adelante. Si usted es responsable del diseño, no
puede comenzar con eso hasta que haya determinado los objetivos
que debe cumplir el diseño para que sea utilizable, es decir, lo que
los usuarios deben hacer para completar cada caso de uso.
Por lo tanto: Escribir diálogos de casos de uso esenciales
para cada caso de uso.
conseguir efectivo

Los casos de uso esenciales son parte del diseño centrado en el

Acción del usuario Respuesta del sistema
uso, desarrollado por Larry Constantine y Lucy Lockwood [8]. El
término "esencial" se refiere a modelos esenciales que "están insertar tarjeta

destinados a capturar la esencia de los problemas a través de

leer banda magnética
descripciones abstractas, idealizadas y sin tecnología". Constantine y
Lockwood definen un caso de uso esencial de la siguiente manera: solicitar PIN

ingrese su PIN

verificar PIN
Un caso de uso esencial es una narrativa
estructurada, expresada en el lenguaje del dominio de mostrar el menú de transacciones

la aplicación y de los usuarios, que comprende una

presione la tecla
descripción simplificada, generalizada, abstracta, sin
tecnología e independiente de la implementación de mostrar el menú de la cuenta

una tarea o interacción que es completa, significativa

presione la tecla
y bien definida. de fi nido desde el punto de vista de
los usuarios en algún rol o roles en relación con un pedir cantidad
sistema y que encarna el propósito o las intenciones
ingrese la cantidad
subyacentes a la interacción.
cantidad de visualización

presione la tecla

Constantine y Lockwood dan los ejemplos que se muestran

tarjeta de devolución
en las figuras 4 y 5. El diálogo en la figura 4 es para un caso de uso
convencional, descrito en términos de acciones y respuestas. El tomar tarjeta

diálogo de la figura 5 es para un caso de uso esencial, descrito en

dispensar efectivo
términos de intenciones y responsabilidades. Los pasos del caso
de uso esencial son más abstractos y permiten una variedad de tomar efectivo

implementaciones concretas. Sin embargo, sigue siendo fácil seguir

Figura 4: Un caso de uso convencional para obtener efectivo de
el diálogo y el caso de uso esencial es más corto.
un sistema de cajero automático. (De Constantine y Lockwood.)

Así que documentamos cada caso de uso con un "diálogo de caso

conseguir efectivo
de uso". Escribimos casos de uso en fichas, por lo que también llamamos

a estos diálogos "tarjetas de casos de uso". Un diálogo de caso de uso Responsabilidad del sistema de intención del usuario
documenta los pasos cronológicos en el caso de uso a medida que el
identificarse
usuario y el sistema interactúan. Por lo general, documentamos la tarjeta

de caso de uso con la parte de los usuarios en el lado izquierdo y la verificar identidad
identificamos como la "intención del usuario", que nos recuerda que
ofrecer opciones
debemos centrarnos en los objetivos reales de los usuarios para el paso.

En el lado derecho, identificamos la “responsabilidad” del sistema, escoger

enfatizando que el sistema también tiene metas que le incumben. La
dispensar efectivo
división en el centro puede considerarse como la "interfaz" entre el

usuario y el sistema, y sirve como recordatorio de que la interacción es tomar efectivo

comunicación a través de esta división.
Figura 5: Un caso de uso esencial para obtener efectivo de un
sistema de cajero automático. (De Constantine y Lockwood.)

Escribimos los pasos de las interacciones bajo el

supuesto de que el actor ya ha elegido

12
 puede ser difícil, por lo que puede tomar varios intentos para algunos casos

de uso.

Patrones relacionados

Escribir diálogos puede llevarlo a revisar la lista de casos de uso y

diagramas de casos de uso. Considere los cuerpos de cada caso
de uso: si dos casos de uso son iguales, probablemente deberían
ser el mismo caso de uso, así que elimine uno de ellos. Si un caso
parece necesitar más de un cuerpo, probablemente necesite
diferentes casos de uso. Dos casos de uso que son

Figura 6: Se puede modelar una tarjeta de caso de uso que muestra el similar esencial Especialización (4.3)
o Inclusión (4.2); los posibles errores que pueden ocurrir durante un caso
detalles de casos de uso para programar un nuevo rendimiento.
de uso pueden ser modelados por Exten-

siones (4.1) o Condiciones (4.4).

para hacer este caso de uso y ya le ha dicho al sistema que lo están
haciendo, por lo que no necesitamos incluir un paso separado para
iniciar el caso de uso.
Preferimos los casos de uso esenciales a los casos de uso
convencionales porque permiten una cierta independencia de las
opciones de tecnología en una implementación posterior o posterior, y
también nos permiten avanzar rápidamente, sin tener que tomar
decisiones difíciles que de otro modo serían necesarias. Además,
creemos que su énfasis en la responsabilidad del sistema conduce a
Las tarjetas de casos de uso se inspiraron en las tarjetas CRC
[3, 14, 5]. También son similares a las Story Cards utilizadas para
programar iteraciones de Extreme Programming [4]. Wirfs-Brock
introdujo la idea del formato de dos columnas [16].
2.2 Juego de roles de casos de uso
¿Cómo puede comprobar que los diálogos de casos de uso sean correctos?

una mejor trazabilidad entre los requisitos y el diseño.

Los diálogos de casos de uso deben ser correctos y coherentes.

Ejemplo Los casos de uso incorrectos pueden desperdiciar el esfuerzo de

desarrollo.
La Figura 6 muestra un ejemplo de una tarjeta de caso de uso.
Todos los miembros del equipo necesitan una comprensión

compartida de los casos de uso.

Consecuencias

Una vez que haya escrito algunos casos de uso esenciales,

Los diálogos de casos de uso esenciales capturan la
requisitos de cada caso de uso, pero sin obtenerlos, es necesario verificar que tienen sentido, que entran en detalles tecnológicos.
Debido a esto, describen que todas las comunicaciones que se necesitan son breves, rápidas de escribir y fáciles de administrar.
un usuario actor y el sistema para realizar el uso

Los casos de uso esenciales son más pequeños (y, por lo tanto, más rápidos, y no incluyen nada innecesario para escribir, revisar y
modificar) que los detalles de implementación más largos y complejos. Tu no solo escribes

casos de uso detallados (por ejemplo, los casos de uso más tradicionales por el gusto de hacerlo: el objetivo de los casos de uso de uso utilizados
en el modelo de caso unificado de Rational es dirigir el esfuerzo de desarrollo, por lo que

las inconsistencias o errores en los casos de uso pueden causar

ceso [10]).
problemas si no se detectan más adelante. Es importante que los
Sin embargo:
diferentes miembros del equipo tengan la misma comprensión de los
Todavía tienes que escribirlos, lo que requiere tiempo y
diálogos de casos de uso, o es más probable que se introduzcan
esfuerzo. Encontrar el nivel "correcto" de abstracción en el que
inconsistencias y errores.
escribir un caso de uso - suficientes detalles para que tenga
sentido, pero no demasiado para que determine los detalles del Por lo tanto: Actúe cada caso de uso ante una audiencia del
diseño de la interfaz - equipo de desarrollo.

En un juego de roles de caso de uso, una persona toma el

13
el rol del usuario y otra persona asume el rol del sistema. Luego Usuario: Digo qué actuación quiero.
proceden a representar la interacción, utilizando el cuerpo del caso de
El usuario hace una pausa esperando una respuesta, luego mira a la
uso como un script. Otras personas observan críticamente el juego de
persona que está reproduciendo el sistema, que todavía está
roles. Aunque los casos de uso no deberían ser muy largos, el juego de
mirando la tarjeta de caso de uso y no se da cuenta de que está
roles de casos de uso es bastante útil para verificar el caso de uso.
recibiendo una señal.

¿Sistema?
Hay varias cosas a tener en cuenta en el juego de roles de
casos de uso. Una es la continuidad, para asegurarse de que tanto
Sistema: Se supone que debes decir lo que te sienta
el usuario como el sistema comprendan cuándo tienen algo que
también quiero saber. Puntos a la tarjeta.
hacer y para asegurarse de que comprenden lo que se debe hacer.
Las pausas confusas pueden indicar malentendidos, que a menudo Usuario: Correcto

pueden resaltar problemas no resueltos al describir el caso de uso.

CORTAR. El juego de roles no permite que nadie se
Otra cosa a tener en cuenta es la información asumida. A veces, el
esconda: todos los participantes deben comprometerse
usuario o el sistema mencionarán información en la que confían,
con el caso de uso.
pero que en realidad no lo saben. Es importante verificar estos
detalles, porque nuevamente pueden mostrar que el caso de uso Toma 4:
aún no se ha descrito completamente. Y así. . .

Consecuencias

Los juegos de roles de casos de uso resaltan los problemas en sus

Ejemplo
diálogos de casos de uso, por lo que puede detectarlos y corregirlos

A continuación, se ofrece un ejemplo representativo de cómo se temprano. La audiencia del juego de roles puede ver cómo debería

desarrolla un juego de roles. En particular, da ejemplos de los tipos de funcionar el diálogo y hacer preguntas para asegurarse de que todos

errores que surgen. Informar la disponibilidad de puestos comprendan el caso de uso.

La escena: El vendedor de boletos ("usuario") está usando el Sin embargo:

"sistema" de computadora para determinar si los asientos solicitados por El juego de roles es otra práctica de verificación que

el patrón del Arts Center para una actuación están realmente está sujeto a rendimientos decrecientes: los pedantes pueden hacer que

disponibles. todo el proceso sea mucho más molesto y lento de lo necesario, los

Toma 1: pequeños errores en los casos de uso no son tan malos como pueden
detectarse fácilmente más tarde, y muchas personas se oponen a la
Usuario: Digo qué actuación quiero y la
humillación ritual de estar de pie arriba y actuando frente al resto del
El sistema me muestra los detalles de rendimiento.
equipo. Este tipo de actividades grupales también pueden verse

¡CORTAR! - es el trabajo del sistema decir lo que hace el afectadas por la participación de la gerencia, ya sea por una cultura de

sistema. A menudo, esto es solo un error cometido por el "diversión forzada" o, peor aún, convirtiendo los controles de coherencia

jugador de rol, pero también puede indicar confusión en interna en excusas para evaluar y despedir a los miembros del personal.

cuanto a dónde está el límite del sistema.

Tomar 2:

Usuario: Digo qué actuación quiero. Discusión

El uso de juegos de roles para ayudar a la verificación de casos de uso no

Sistema: Muestro los detalles de rendimiento y digo
es estrictamente necesario, pero sí aprovecha varias habilidades humanas.
si los asientos están disponibles o no.
Utiliza las habilidades de las personas que desempeñan los roles para
¡CORTAR! - los asientos aún no se han especificado.
identificarse con los roles, lo que a menudo puede hacer que se concentren

más intensamente en la intención del usuario o la responsabilidad del

sistema, y para detectar problemas. También utiliza la capacidad de una

Toma 3
audiencia crítica para seguir el diálogo y aporta

14
en juego habilidades desarrolladas en la comprensión de historias. Estas Consecuencias
habilidades ayudan a las personas a detectar discontinuidades o
El sistema asume la responsabilidad de iniciar el caso
suposiciones y así detectar posibles problemas en el caso de uso. El
de uso.
juego de roles de casos de uso hace que la actividad sea más divertida y

variada, y esto también aumenta la atención. El sistema puede pasar información sobre la alarma
al actor.

El actor no tiene que interrumpir su tarea actual de

Patrones relacionados inmediato para responder a la alarma.

Los juegos de roles de casos de uso se inspiraron en los juegos de roles de

tarjetas CRC [14, 5]. Se puede encontrar más información sobre el juego de El actor puede ignorar la alarma.

roles de casos de uso en [6]. Nuestro uso del juego de roles es similar al uso de

"conversaciones" de Wirf-Brock para evaluar casos de uso [17].

Si la alarma es importante, es posible que deba
incluir un Paso de con fi rmación (3.6):

3 Patrones de diálogo de casos de uso Advertir rendimiento teatral subestimado

Una vez que empiece a escribir casos de uso, se dará cuenta de Intención del usuario Responsabilidad del sistema

que surgen muchos tipos de casos de uso una y otra vez, que en
Señal "rendimiento un-
realidad existen patrones en los cuerpos de diálogo de los propios
dersold "
casos de uso esenciales. Esta sección enumera varios de estos
patrones. En aras del espacio, damos solo lo básico de cada Mostrar nombre, teatro,
tiempo o rendimiento,
patrón.
y porcentaje de asientos vendidos

3.1 Caso de uso de alarma Con fi rmar advertencia

¿Cómo hace que el sistema informe al usuario sobre algo? Esta variante tiene las siguientes consecuencias diferentes
para el patrón principal:

El sistema necesita llamar la atención del actor sobre un El actor no puede continuar con su tarea actual:
cambio en su estado interno. debe interrumpirla para con fi rmar la alarma.

El sistema está a punto de romper una regla comercial.

La notificación debe ser asincrónica, es decir, los actores El actor no puede ignorar la alarma.

no deben tener que activar el caso de uso.

Los casos de uso de alarmas a menudo pueden indicar violaciones

(potenciales) de las reglas comerciales, digamos que un

Por lo tanto: Escriba un caso de uso que comience con el mance no debe continuar si menos del 15% de
sistema teniendo la responsabilidad de advertir al usuario. los asientos se han vendido cuando comienza.

Ejemplo 3.2 Solicitud de caso de uso

¿Cómo se escribe un caso de uso cuando el usuario necesita

saber algo del sistema?
Advertir del inicio de la actuación

Por lo tanto: Escriba un caso de uso en el que el actor describa

Intención del usuario Responsabilidad del sistema
la información que necesita y luego
Señal "actuación el sistema presenta esa información.
a punto de empezar"

Nombre del espectáculo, teatro y

horarios de actuación.

15
Ejemplo 3.5 Paso de apoyo

¿Cómo debería escribir un caso de uso cuando el sistema conoce

Obtener precios de asientos alguna información que ayudaría al usuario a tomar una decisión?

Intención del usuario Responsabilidad del sistema

Por lo tanto: Dele al sistema la responsabilidad de ofrecer esa
Ofrecer actuaciones información antes de que el usuario tome la decisión.

Elige el rendimiento

Mostrar precios para los elegidos Ejemplo

actuación

3.3 Caso de uso de monitoreo Reserve asientos para el desempeño

Intención del usuario Responsabilidad del sistema

¿Cómo se escribe un caso de uso en el que el usuario a menudo
necesita conocer una cantidad relativamente pequeña de información
Ofrecer asientos sin reserva
importante del sistema?
Elige asientos
Por lo tanto: Escriba un caso de uso en el que el sistema presente esa

información.
3.6 Paso de con fi rmación

Ejemplo ¿Cómo debería escribir un caso de uso cuando es

Mostrar las actuaciones de hoy
Intención del usuario
importante que la información correcta se comunique entre el
actor y el sistema?
Por lo tanto: Exija al actor o al sistema que con fi rme la
Responsabilidad del sistema
información.
Mostrar el rendimiento de hoy
mances Ejemplo

3.4 Caso de uso de mando

Pagar la reserva
¿Cómo hace que el usuario consiga que el sistema haga algo?
Intención del usuario Responsabilidad del sistema

Presentar reserva de
Por lo tanto: Escriba un caso de uso donde el usuario
cruz
proporciona información sobre la solicitud y el sistema tiene
la responsabilidad de ejecutar el comando. Ofrecer métodos de pago

elige el método de pago

Ejemplo Suministro de pago de

cruz

Confirmar método y detalles

Programa de rendimiento de impresión

Intención del usuario Responsabilidad del sistema

Aceptar pago
Elija fechas de inicio y finalización
Confirmar reserva
Imprimir calendario de actuaciones

desde el principio hasta el final

4 Organización de casos de uso

En esta sección, enumeramos brevemente una serie de patrones que

describirán cómo modelar las relaciones

dieciséis
entre casos de uso, basados en UML y Usage- Referencias
Relaciones de diseño centradas.
[1] Frank Armour y Granville Miller. Avanzado
Modelado de casos de uso: sistemas de software, volumen
4.1 Extensión 1. Addison-Wesley, 2001.

¿Cómo modela errores y excepciones en casos de uso? [2] Kent Beck. Explicación de la programación extrema:
Aceptar el cambio. Addison-Wesley, 1999.

Por lo tanto: Utilice casos de uso extendidos. [3] Kent Beck y Ward Cunningham. Un laboratorio
para enseñar el pensamiento orientado a objetos. En Proc. de
OOPSLA-89: Conferencia ACM sobre lenguajes y aplicaciones de
4.2 Inclusión sistemas de programación orientados a objetos, páginas 1 a 6, 1989.

¿Cómo eliminar los elementos comunes entre los casos de uso?

[4] Kent Beck y Martin Fowler. Planificación extrema

Por lo tanto: Cree un nuevo caso de uso que contenga los pasos
Programación. La serie XP. Addison-Wesley,
comunes e inclúyalo en los casos de uso que tienen los pasos
2000.
comunes.
[5] David Bellin y Susan Suchman Simone. los
Libro de tarjetas CRC. Addison-Wesley, 1997.
4.3 Especialización
[6] Robert Biddle, James Noble y Ewan Tem-
¿Cómo maneja casos de uso más generales y específicos pero. Tarjetas de casos de uso y juegos de roles de casos de uso, 2001.

que hacen el mismo tipo de cosas?

[7] Alistair Cockburn. Redacción de casos de uso efectivos.

Por lo tanto: Utilice la especialización. Addison-Wesley, 2001.

[8] Larry L. Constantine y Lucy AD Lock-

Patrones relacionados madera. Software de uso: guía práctica de los modelos y
métodos de diseño centrado en el uso. Addison-Wesley,
Prefiere la inclusión a la especialización. 1999.

[9] Martin Fowler y Kendall Scott. UML Dis-

4.4 Condiciones tilled: una breve guía del lenguaje de modelado de objetos
estándar. Serie de tecnología de objetos. Addison-Wesley,
¿Cómo modela casos de uso que solo pueden funcionar en
segunda edición, 2000.
determinadas circunstancias?
[10] Ivar Jacobson, Grady Booch y James Rum-
Por lo tanto: Utilice condiciones previas y posteriores para controlar cuándo
baugh. El proceso de desarrollo de software unificado. Addison-Wesley,
se permiten los casos de uso. 1999.

[11] Ivar Jacobson, Mahnus Christerson, Patrik Jon-

Patrones relacionados sson y Gunnar Overgaard. Ingeniería de Software Orientada a
Objetos. Addison-Wesley, 1992.
Prefiere extensiones a las condiciones. Las condiciones previas y

posteriores deben coincidir en un modelo completo. [12] James Noble. Clasificando relaciones entre
patrones de diseño orientados a objetos. En Douglas D. Grant,
editor, Actas de la Conferencia Australiana de Ingeniería de
Conclusiones Software de 1998, páginas 98–109, noviembre de 1998.

En este documento, hemos presentado una serie de patrones para

[13] Doug Rosenberg y Kendall Scott. Caso de uso
escribir casos de uso esenciales para un sistema. Muchos de estos Modelado de objetos impulsado con UML: un enfoque práctico. Addison-Wesley,
patrones también pueden ser aplicables a casos de uso 1999.
convencionales, aunque creemos que los patrones son más
[14] Nancy Wilkinson. Uso de tarjetas CRC: una información
evidentes en la forma esencial del caso de uso. Claramente, varios
Mal enfoque para el desarrollo de OO. Prensa de la Universidad de
de los patrones que hemos discutido aquí necesitan más desarrollo, y Cambridge, 1996.
estamos investigando otros patrones posibles.
[15] Rebecca Wirfs-Brock, Brian Wilkerson y
LaurenWiener. Diseño de software orientado a objetos. Prentice
Hall, 1990.

17
[16] Rebecca J. Wirfs-Brock. Diseñar escenarios:
Argumentos a favor de un marco de casos de uso. El Informe
Smalltalk, 3 (3), 1993.

[17] Rebecca J. Wirfs-Brock. El arte de lo significativo

conversaciones. El Informe Smalltalk, 4 (5), 1994.

18