You are on page 1of 7

Creación de casos de uso 

Un caso de uso es una descripción de un sistema en términos de una secuencia de acciones. 
Se debe producir un resultado observable o el valor para el actor que interactúa con el 
sistema. 
Características de casos de uso: 
• Son iniciados por un actor. 
• Los modelos de una interacción entre un actor y el sistema. 
• Describen una secuencia de acciones. 
• Capturan requerimientos funcionales. 
• Se debe proporcionar un valor para un actor. 
• Representan un flujo completo y significativo de los acontecimientos. 
 
Según (Peter Zielczynski, 2008, pág. 129) “el propósito de un caso de uso es para facilitar el 
acuerdo entre los desarrolladores, clientes y los usuarios acerca de lo que debería hacer el 
sistema. Un caso de uso puede ser utilizado como un contrato entre los desarrolladores y los 
clientes. También es una base para las realizaciones de casos de uso, las cuales juegan un 
papel importante en el diseño. Por otra parte, usted puede obtener la documentación de 
usuario de casos de uso. Los casos de uso también pueden ser útiles en la planificación del 
contenido técnico de iteraciones y dar a los desarrolladores un mejor entendimiento del 
objetivo del sistema”. 
Durante la creación de casos de uso, también debe definir los escenarios específicos de las 
rutas a través un caso de uso. Usted puede producir los diagramas de secuencia, diagramas 
de comunicación, y los diagramas de clases de escenarios. También se utilizan como insumo 
para los casos de prueba. 
 

Identificar Actores 
  

Un actor es alguien o algo que interactúa con el sistema. Puede ser una persona, sino que 
también 
puede ser otro sistema. He aquí algunos ejemplos: 
• Los usuarios del sistema. 
• Los administradores. 
• Gestión. 
• Las personas que proveen información para el sistema. 
• Los sistemas externos de suministro de datos. 
• Sistemas externos que se hayan notificado. 
Todas las partes interesadas del sistema también son candidatos a ser actores: 

 Los  nombres se entienden no sólo por el equipo de desarrollo. todo el modelo de casos de uso se puede presentar en un diagrama. Use búsqueda de reservación y  búsqueda de viaje en lugar de la búsqueda 1 y de la búsqueda 2.UU.  • Los casos de uso describen la funcionalidad. Por ejemplo.  Los diagramas de casos     Los diagramas de casos representan actores.    También hay que tener en cuenta que los casos de uso no pueden ser demasiado pequeños  o demasiado grandes.  • Los nombres de los casos de uso serán significativos.  • Administrador de contenido.  • Representante de Servicio al Cliente.  .  • El usuario 1 (de los EE.•Dueño de la Agencia de Viajes.  sino también por los clientes y los usuarios. casos de uso. Nunca se tienen dos casos  de uso con el mismo nombre. ya que no representan un flujo completo de los eventos y no proporciona  ningún valor para el actor.  • Deberá ser claro que inicia el caso de uso. no la ejecución.  Pautas para la creación de casos de uso:  • Cada caso de uso deberá interactuar con por lo menos un actor.)  • El usuario 2 (de Francia)  • Desarrollador.  Los diagramas de casos de uso ilustran las relaciones en el modelo de casos de uso.  • Cada caso de uso deberá ser iniciado por un actor. envíe información de la tarjeta de crédito no es un caso  de uso correcto. Para  sistemas pequeños. y las relaciones entre ellos.    La identificación de casos de uso     Preguntas que pueden ayudar a identificar casos de uso:  • ¿Qué función puede esperar cada actor del sistema?  • Los actores deben ser informados sobre los acontecimientos que ocurren en el sistema?  • ¿Qué información necesitan los agentes de suministro para el sistema?  • ¿Qué información se necesita para recibir los actores del sistema?  • Acerca de los eventos fuera del sistema ¿hace que el sistema necesite ser notificado?    Los casos de uso pueden ser identificados en un taller de requisitos.

 tenemos que analizar los casos de uso y encontrar las piezas de los flujos que  contienen medidas similares.  Sin embargo.  Si dos casos de uso siempre se activan en la misma secuencia. así como a los actores. podemos estructurar. como caso de uso Comprar un billete de avión se produce  después de reservar un vuelo.     . por lo general esto significa que el caso de uso se está  volviendo demasiado complejo. Entonces podemos aplicar algunos de los tres tipos de relaciones  entre casos de uso:  • Incluir. es necesario dividir el todo el sistema en muchos diagramas.  • Los casos de uso que se ejecutan normalmente en una oración.  Podemos aplicar la generalización de los casos de uso.       Algunas opciones para lo que se pueden agrupar en un diagrama:  • Todos los casos de uso iniciados por el mismo actor o grupo de actores. Esta es una señal de que el caso de uso es un candidato para ser  dividido en dos diferentes casos de uso. se puede considerar la  combinación de ellos.  • Ampliar.  En primer lugar.Para grandes sistemas. El objetivo  principal de la estructuración del modelo es eliminar cualquier redundancia. podemos considerar su división.  • Los casos de uso relacionados con el mismo tipo de tareas (tales como tareas  administrativas). No hay  reglas estrictas sobre cómo el modelo debe ser dividido. Cuando hay un camino  alternativo para un camino alternativo. por lo que los casos  de uso son más fáciles de entender y mantener. Una técnica para decidir  cuándo un caso de uso debe ser dividido es buscar alternativas. no debe ser dividido en dos casos de uso.  • Generalización.  La estructuración del modelo de Casos  de Uso     Después de que el modelo de casos de uso inicial se hace. Por ejemplo. se ha decidido fusionarlos.  Si el caso de uso es muy complicado. si el caso de uso tiene muchos pasos que se realizan siempre juntos en la misma  secuencia. una ampliación del caso de uso base.

Incluir Relaciones     Si una parte importante del flujo se utiliza en más de un caso de uso. para que el modelo sea más claro. Derivados los casos de uso se puede agregar el comportamiento y modificar el  comportamiento definido en el caso de uso base. Sin embargo.              Relación Extendida     Si alguna parte del caso de uso es opcional o condicional. ya que esta técnica  puede ser difícil de comprender para las partes interesadas.  Documento de especificación de casos  de uso     . es un buen candidato  para ser extraído como un caso de uso separado que está conectado con una relación  incluida. IBM Rational sugiere evitar el  uso de la generalización de casos de uso. Es especialmente útil si un  conjunto de actores inician los mismos casos de uso. se puede extraer similitudes en el caso de uso  base.  podemos extraer como un caso de uso separado que está conectado con una relación de  extensión. El caso de uso padre no tiene por qué  saber que los niños son especializaciones de la misma. así como el que se  incluye.  Generalización de la relación entre casos de uso    Si dos o más casos de uso son similares. El caso de uso incluido debe ser autónomo y no puede hacer ninguna suposición  sobre cual caso de uso es incluido.  Generalización de relaciones entre los actores    La generalización también puede ser utilizada entre los actores. La instancia del caso de uso contendrá un caso de uso base.

       Puntos de extensión.  Representan las variaciones del flujo.     7. no sólo para el flujo básico. estos son  los requisitos no funcionales. También se menciona a todos los  actores que interactúan con el caso de uso. la postcondición será válida para cualquier flujo  alternativo. Sin embargo.  Una postcondición es el estado del sistema después de que el caso de uso termina.     3.  imprimir. si un requisito es genérico y se aplica en  muchos casos de uso.     5. salir.     8.       Condiciones previas.        Flujos alternativos.1.  Una condición previa es el estado del sistema antes de que el caso de uso se pueda  iniciar. A menos  que sea específicamente mencionada. ayuda)?  • ¿Alguna condición (por ejemplo.  La descripción deberá explicar claramente su propósito.       Flujo básico.  Un punto de extensión es un lugar desde el cual puede ser invocado un caso de uso  extendido.    2. Por lo general.  La sección de requisitos especiales contiene todos los requisitos relacionados con este  caso de uso que no fueron cubiertos por los flujos de eventos. una combinación específica de los datos introducidos)  cambia significativamente el flujo?           4. los datos faltantes.       Breve descripción. los pasos que ocurren  cuando todo va bien.       Postcondiciones.  Las siguientes preguntas pueden ayudar a encontrar flujos alternativos:  • ¿Qué otras medidas se pueden tomar en cada paso del flujo básico?  • ¿Qué errores pueden ocurrir en cada paso (datos erróneos.  El flujo básico contiene la secuencia más popular de las acciones.  Un diagrama de contexto es parte de un diagrama de casos de uso que muestra las  .       Diagrama de contexto. incluyendo los casos menos habituales y las  condiciones de error. se describe en la especificación complementaria.       Requisitos especiales.  problemas de conexión)?  • ¿Existe un comportamiento que puede ocurrir en cualquier momento (por ejemplo.     6.

     10. las flechas representan transiciones. y luego  hacer un bucle por segunda vez.  . En las versiones anteriores de UML.  El enfoque razonable es hacer el flujo básico una vez.     9. y las  ramas se modelan como diamantes.     11.     Escenarios     Para encontrar todos los escenarios. Todos los casos  de uso son incluidos. así como para derivar casos de prueba a partir  de los casos de uso.  Es importante identificar todos los escenarios válidos para todos los casos de uso. esto  podría generar un número infinito de escenarios. Un diagrama de actividades deberá contener el flujo  básico y todos los flujos alternativos.  A veces es posible que necesitemos describir el comportamiento de los objetos que  actúan de forma diferente dependiendo de su estado. Las cajas con esquinas  redondeadas representan estados de actividad. Puede ser utilizado para  representar gráficamente los flujos en el caso de uso. En él se describe una ruta específica a  través del flujo de los acontecimientos. hacer un bucle de una vez.  Un diagrama de actividad es similar a un diagrama de flujo. se les llaman diagramas de transición de estado o simplemente diagramas de  estado. y en otros lenguajes de  modelado.  estos diagramas fueron llamados diagramas de estado gráfico. Que  serán utilizados para el análisis y diseño. tenemos que identificar todos los caminos a través del  caso de uso dado. Las medidas que no tienen ramas en el medio  pueden ser combinadas.  ¿Qué debe hacer si usted tiene bucles infinitos (loops hacia atrás)? En teoría.  se puede asumir que funcionará para muchos bucles. En este caso podemos utilizar  diagramas UML 2 máquina de estados [AMB04]. el caso de uso  también debe ser mostrado en el diagrama de contexto.relaciones de este caso en particular a los actores y otros casos de uso. Si el programa funciona tanto para las instancias del ciclo. extendidos o generalizados con las relaciones.       Diagrama de actividad.   Diagramas de estado de la máquina.     Un escenario es una instancia de un caso de uso.   Escenarios.

 le da mucha  más funcionalidad. (2008). y la elaboración de informes relacionados. En la siguiente iteración un  esquema se puede añadir. Si usted no tiene acceso a RequisitePro.                    Referencias:     Peter Zielczynski. finalmente. puede crear un documento  asociado con una breve descripción que indica su propósito.Casos de uso en RequisitePro     El documento de especificación de casos de uso se crea a partir de una plantilla que contiene  las partes discutidas en la sección anterior. puede  crear este documento en Microsoft Word. Utilizando RequisitePro. el establecimiento  de la trazabilidad. sin embargo. Un análisis detallado de todas las etapas del ciclo de vida del caso  de uso se presenta en el libro de modelado de casos de uso de Kurt Bittner y Ian Spence  [Bit02]. Creación de un caso de uso es un  proceso iterativo. como la creación de requisitos del tipo de caso de uso.  USA: IBM Press. Tan pronto como el caso de uso se identifica.          .  No es necesario para terminar todo el documento a la vez. P. una descripción  detallada de cada paso. todos los pasos y. ​ Requeriments Management Using IBM Rational RequisitePro. a continuación.