Introducción a los casos de uso
Ningún sistema existe de manera aislada. Todo sistema interesante interacciona con actores humanos o automatizados que utilizan el sistema con algún propósito, y esos actores esperan que el sistema se comporte previsiblemente. Un caso de uso especifica el comportamiento de un sistema o una parte de él y es la descripción de un conjunto de secuencias de acciones, incluyendo variaciones, que un sistema realiza para producir un resultado de valor observable por un actor.
Los casos de uso capturan el comportamiento del sistema que se está desarrollando, sin tener que especificar cómo se implementa ese comportamiento. Los casos de uso proporcionan a los desarrolladores una ruta para lograr un entendimiento común con los usuarios finales del sistema y expertos del dominio. Además, los casos de uso sirven para validar la arquitectura y para verificar que el sistema evolucione durante el desarrollo de manera congruente.
Casos de uso
Cuando empezamos a analizar un problema con el propósito de implementar una solución en software podemos usar los casos de uso como una herramienta de análisis de los requerimientos. Los casos de uso contestan las preguntas:
- ¿Quiénes son los diferentes usuarios del sistema y qué papeles desempeñan?
- ¿Qué necesita cada usuario que realice el sistema?
- ¿Cuáles son los pasos que deben seguirse para que el sistema satisfaga las necesidades de cada usuario?
Un factor importante al crear casos de uso es que se hace sin especificar cómo el caso de uso se implementa. Por ejemplo, se puede especificar cómo un sistema de cajero bancario debería comportarse al enunciar en casos de uso de la manera en que los usuarios interactúan con el sistema. No se necesita saber nada acerca de los aspectos internos del cajero. Los casos de uso especifican el comportamiento deseado, no dictan cómo debe llevarse a cabo el comportamiento. Lo importante de este enfoque es que permite (al usuario final y experto del dominio) comunicarse con los desarrolladores (quienes construyen sistemas para satisfacer tus requerimientos) sin quedar atrapado en detalles. Esos detalles llegarán, pero los casos de uso permiten enfocarse en aspectos de alto riesgo para desarrollar el sistema..
En el Lenguaje de Modelado Unificado (UML), todo este comportamiento se modela como casos de uso que pueden ser especificado independientemente de su cómo se implementarán en código. Un caso de uso es una descripción de un conjunto de secuencias de acciones, incluyendo variaciones, que un sistema realiza para lograr un resultado observable de valor para un actor. En esta definición, existe un número importante de partes.
Un caso de uso describe un conjunto de secuencias, en las cuales cada secuencia representa la interacción de cosas fuera del sistema (actores) con el sistema (y sus abstracciones clave). Estos comportamientos son funciones a nivel del sistema que acostumbra visualizar, especificar, construir y documentar en la fase de obtención y análisis de los requerimientos. Un caso de uso representa un (o más) requerimiento funcional completo del sistema. Por ejemplo, un caso de uso central de un banco es procesar préstamos.
Un caso de uso involucra la interacción de actores con el sistema. Un actor representa un conjunto de roles coherente que los usuarios del caso de uso juegan cuando interactúan con el sistema. Los actores pueden ser personas o sistemas automatizados. Por ejemplo, en el modelado bancario, el procesamiento de un préstamo involucra, entre otras cosas, la interacción entre un cliente y el ejecutivo de préstamos.
Un caso de uso puede tener variaciones. En todos los sistemas interesantes, se encuentran casos de uso que son versiones especializadas de otros casos de uso, casos de uso que son incluidos como parte de otros casos de uso y casos de uso que extienden el comportamiento de otros casos de uso centrales. Se puede separar el comportamiento reutilizable y común de un conjunto de casos de uso al organizarlos de acuerdo a estas tres clases de relaciones: generalización, inclusión y extensión. Por ejemplo, en el modelado del banco, se encuentran muchas variaciones entre el caso de uso básico para procesar un préstamo, así como la diferencia entre procesar una gran hipoteca contra un préstamo para un pequeño comercio. En cada caso, sin embargo, estos casos de uso comparten en algún grado comportamiento común, tal como la calificación del cliente para el préstamo, un comportamiento que es una parte del procesamiento de cada clase de préstamo.
Un caso de uso lleva a cabo alguna cantidad de trabajo tangible. Desde la perspectiva de un actor dado, un caso de uso hace algo que es de valor para el actor, tal como calcular un resultado, generar un nuevo objeto o cambiar el estado de otro objeto. Por ejemplo, en el modelo del banco, el procesamiento de un préstamo resulta en la entrega de un préstamo aprobado, manifestado por el dinero en las manos del cliente.
Los casos de uso se pueden aplicar al sistema completo, pero también a una parte del sistema, incluyendo subsistemas y aún clases individuales e interfaces. En cada caso, estos casos de uso no sólo representan el comportamiento deseado de estos elementos, sino que también pueden ser usados como una base para casos de prueba de estos elementos conforme evolucionan en el desarrollo. Los casos de uso aplicados a subsistemas son fuentes excelentes de pruebas de regresión. Los casos de uso aplicados a los subsistemas son fuentes excelentes de pruebas de integración y de sistema. El UML, proporciona una representación gráfica de un caso de uso y un actor, como lo muestra la figura 1. Esta notación permite visualizar un caso de uso independiente de su implementación y en el contexto de otros casos de uso.
Figura 1. Actores y casos de uso.
Términos y conceptos
Un caso de uso es una descripción de un conjunto de secuencias de acciones, incluyendo variaciones, que un sistema realiza para lograr un resultado observable de valor para un actor. Gráficamente, un caso de uso se representa como una elipse.
Nombres
Cada caso de uso debe tener un nombre que lo distinga de otros casos de uso. Un nombre es una cadena de texto. En la práctica, los nombres de los casos de uso son frases verbales activas nombrando algún comportamiento encontrado en el vocabulario del sistema que se está modelando.
Casos de uso y actores
Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso juegan cuando interactúan con el sistema. Típicamente, un actor representa un rol que un humano, dispositivo de hardware, o aún otro sistema juega con el sistema. Por ejemplo, si alguien trabaja en un banco, pudiera ser el ejecutivo de préstamos. Si esta persona usa los servicios financieros ahí mismo, también juega el rol de cliente. Una instancia de un actor, entonces, representa una interacción individual con el sistema de una forma específica. Aunque se usan actores en los modelos, los actores no son parte del sistema. Ellos viven fuera del sistema.
Los actores pueden estar conectados a los caso de uso sólo por asociaciones. Una asociación entre un actor y un caso de uso indica que el actor y el caso de uso se comunican entre sí, cada un posiblemente enviando y recibiendo mensajes.
Casos de uso y flujo de eventos
Un caso de uso describe qué hace un sistema (o subsistema, clase o interfaz) pero no especifica cómo lo hace. Cuando se modela, es importante que mantenga clara esta separación de aspectos entre las vistas internas y externas del sistema.
El comportamiento de un caso de uso se puede especificar al describir el flujo de eventos en texto, lo suficientemente claro para que alguien ajeno pueda entenderlo fácilmente. Cuando se escribe este flujo de eventos, se deberá incluir cómo y cuándo el caso de uso inicia y termina, cuando el caso de uso interactúa con los actores y cuando se intercambian objetos, así como el flujo básico y el flujo alternativo del comportamiento.
El flujo de eventos del caso de uso se puede especificar en formas distintas, incluyendo texto estructurado informal, texto estructurado formal (con pre y poscondiciones) y pseudocódigo.
Casos de uso y escenarios
Cuando inicia el proceso de especificación de un caso de uso, primero se describe, en términos generales, el flujo de eventos para un caso de uso en texto. Conforme se refina la comprensión de los requerimientos del sistema, se detallará hasta tener un caso de uso conceptual expandido con pre y poscondiciones, especificando las acciones del actor y las respuestas del sistema.
Es deseable separar los flujos principales de los alternativos porque un caso de uso describe un conjunto de secuencias, no sólo una secuencia simple y pudiera ser imposible expresar todos los detalles de un caso de uso interesante en sólo una secuencia. Por ejemplo, en un sistema de recursos humanos, se puede encontrar un caso de uso Contratar Empleado. Esta función general del negocio puede tener muchas variaciones posibles. Se puede contratar a una persona de otra compañía (el escenario más común); se puede transferir una persona de una división a otra (común en trasnacionales); o se puede contratar a un extranjero (que involucra reglas especiales). Cada una de estas variaciones puede ser expresada en una secuencia diferente.
Este caso de uso (Contratar Empleado) actualmente describe un conjunto de secuencias en la cual cada secuencia del conjunto representa un flujo posible a través de todas estas variaciones. Cada secuencia es denominada escenario. Un escenario es una secuencia específica de acciones que ilustran el comportamiento. Los escenarios son a los casos de uso como los objetos son a las clases, lo que significa que un escenario es básicamente una instancia de un caso de uso.
Organización de los casos de uso
Los casos de uso se pueden organizar agrupándolos en paquetes. También se pueden organizar al especificar generalizaciones, relaciones de inclusión y de extensión entre ellos. Estas relaciones se pueden aplicar para separar el comportamiento común o para factorizar las variaciones.
La generalización entre casos de uso es como la generalización entre clases. Significa que un caso de uso hijo hereda el comportamiento y significado del caso de uso padre. El hijo puede agregar o redefinir el comportamiento de su padre y el hijo puede ser sustituido en cualquier parte que el padre aparezca. Por ejemplo, en un sistema bancario, se puede tener el caso de uso validar usuario, el cual es responsable de verificar la identidad del usuario. Además, se podría tener dos hijos especializados para este caso de uso (revisa contraseña y escudriña retina), ambos llegan a ser como valida usuario y pueden ser aplicados en cualquier lugar en el cual valida usuario aparece, aunque cada uno de ellos usa su propio comportamiento. La generalización entre componentes se presenta como una línea sólida dirigida con una flecha abierta grande, del mismo modo que la generalización entre clases.
Una relación entre casos de uso del tipo incluye significa que el caso de uso base explícitamente incorpora el comportamiento de otro caso de uso en la localidad especificada en la base. El caso de uso incluido nunca permanece solo, sólo es instanciado como parte de algún caso de uso mayor que lo incluye. Puedes pensar en incluye como el caso de uso base que extrae el comportamiento de un caso de uso proveedor.
La relación de inclusión se utiliza para evitar describir el mismo flujo de eventos varias veces, al poner el comportamiento común en un caso de uso. La relación incluye es esencialmente un ejemplo de delegación –tomas un conjunto de responsabilidades del sistema y lo captura en un lugar (el caso de uso incluido), entonces le permites a otras partes del sistema (otros casos de uso) incluir la nueva agregación de responsabilidades en cualquier parte que requieras utilizar esa funcionalidad.
En UML, la relación incluye se presenta como una dependencia, estereotipada como include. Para especificar la localidad en el flujo de eventos en el cual el caso de uso base incluye el comportamiento de otro, simplemente se escribe include seguido del nombre del caso de uso que deseas incluir.
Una relación de extiende entre casos de uso significa que el caso de uso base implícitamente incorpora el comportamiento de otros caso de uso en la localidad especificada indirectamente por el caso de uso extendido. El caso de uso base puede estar solo, pero bajo ciertas condiciones, su comportamiento puede ser extendido por el comportamiento de otro caso de uso. Este caso de uso base puede ser extendido sólo en ciertos puntos, en sus puntos de extensión. Puedes pensar en extiende como la extensión de un caso de uso que empuja el comportamiento de un caso de uso base.
En UML, la relación extiende se presenta como una dependencia, esteriotipada como extend. Se pueden listar los puntos de extensión del caso de uso base en un compartimiento extra. Estos puntos de extensión son sólo etiquetas que pueden aparecer en el flujo del caso base.
Técnicas de modelado comunes
El uso más común de un caso de uso es modelar el comportamiento de un elemento, ya sea el sistema completo, un subsistema o una clase. Cuando modelas el comportamiento de estas cosas, es importante enfocarse en qué hace el elemento, no cómo lo hace.
Aplicar los casos de uso a los elementos de esta manera es importante por tres razones. Primero, al modelar el comportamiento de un elemento con casos de usos, proporcionas una manera para que los expertos del dominio especifiquen la vista externa en grado suficiente para que los desarrolladores construyan su vista interna. Los casos de uso proveen un foro para que los expertos del dominio, usuarios finales y desarrolladores, se comuniquen entre sí. Segundo, los casos de uso proporcionan a los desarrolladores un mecanismo para aproximarse a un elemento y entenderlo. Un sistema, subsistema o clase puede ser complejo y lleno de operaciones y otras partes. Al especificar los caso de uso de un elemento, puedes ayudar a los usuarios de estos elementos a enfocarse de una manera directa, de acuerdo a como ellos los utilizan. En la ausencia de tales casos de uso, los usuarios tienen que descubrir por sí mismos como usar aquellos elementos. Los casos de uso le permiten a un autor de un elemento comunicar su propósito de cómo debe ser usado. Tercero, los casos de uso sirven como una base para probar cualquier elemento contra sus casos de uso, continuamente validas su implementación. No sólo haces que los casos de uso provean una fuente de pruebas de regresión, pero cada vez que generas un nuevo caso de unos para un elemento, te fuerzas a reconsiderar tu implantación para asegurar que este elemento es congruente al cambio. Si no, deber corregir tu arquitectura apropiadamente.
Para modelar el comportamiento de un elemento:
- Identifica los actores que interaccionan con el elemento. Los actores candidatos incluyen grupos que requieren cierto comportamiento par realizar sus tareas o que son necesarios directa o indirectamente para realizar las funciones del elemento.
- Organiza a los actores al identificar roles generales y especializados.
- Para cada actor, considera la forma básica en la cual el actor interactúa con el elemento. Considera también las interacciones que cambian el estado del elemento o su ambiento o que involucran la respuesta a algún evento.
- Considera también las maneras excepcionales en la cual cada actor interactúa con el elemento.
- Organiza estos comportamientos como casos de uso, aplicando las relaciones de incluye y extiende para factorizar el comportamiento común y distinguir el comportamiento excepcional.
Conforme el modelo crezca, encontrarás que los casos de uso tienden a agruparse en áreas que están relacionadas conceptual o semánticamente. En el UML, puedes usar paquetes para modelar estos grupos de clases.
Recomendaciones
Cuando modeles un caso de uso en UML, cada caso de uso representa algún comportamiento distinto e identificable del sistema o parte del sistema. Un caso de uso bien estructurado:
- Nombra a un comportamiento simple, identificable y razonablemente atómico del sistema o parte del sistema.
- Factoriza el comportamiento común al extraer tal comportamiento de otros casos de uso que lo incluyen.
- Factoriza variantes al empujar tales comportamientos en otros casos de uso que lo extienden.
- Describe el flujo de eventos lo suficientemente claro para que alguien ajeno lo comprenda fácilmente.
- Está descrito por un conjunto mínimo de escenarios que especifican la semántica normal y variante del caso de uso.
Cuando dibujes un caso de uso en el UML,
- Muestra sólo aquellos casos de uso que son importantes para entender el comportamiento del sistema o parte del sistema en este contexto.
- Muestra sólo aquellos actores que están relacionados a estos casos de uso.
Diagramas de casos de uso
Los diagramas de caso de uso son uno de los cinco diagramas en UML para modelar los aspectos dinámicos del sistema (diagramas de actividad, diagramas de estado, diagramas de secuencia y diagramas de colaboración son los otros cuatro). Los diagramas de caso de uso son centrales para modelar el comportamiento de un sistema, subsistema o una clase. Cada uno muestra un conjunto de casos de uso y actores y sus relaciones.
Aplicarás diagramas de caso de uso para modelar la vista de caso de uso de un sistema. Para la mayoría de las partes, esto involucra modelar el contexto de un sistema, subsistema o clase o modelar los requerimientos del comportamiento de estos elementos.
Los diagramas de caso de uso son importantes para visualizar, especificar y documentar el comportamiento de un elemento. Hacen al sistema, subsistema y clases accesibles y entendibles al presentar una vista externa de cómo aquellos elementos pueden ser usados en contexto. Los diagramas de caso de uso también son importantes para probar sistemas ejecutables a través de ingeniería hacia delante y para comprender sistemas ejecutables a través de ingeniería en reversa.
Suponga que alguien le da una caja. En un lado de esa caja hay algunos botones y un panel pequeño de LCD. Aparte de esto, la caja no está descrita; no te dan ninguna pista de cómo usarlo. Puedes azarosamente oprimir los botones y ver qué sucede, pero estarás estresado para darte una idea de qué hace la caja y cómo lo usas apropiadamente a menos que dediques mucho tiempo a prueba y error.
Sistemas de software intensivos pueden ser como lo anterior. Si eres un usuario, pudieras tener una aplicación y solicitarte que la uses. Si la aplicación sigue las convenciones normales del sistema operativo que acostumbras, puede ser que hagas algo útil después de un rato, pero no tendrás una comprensión de su comportamiento más detallado y complejo de esta manera. Similarmente, si eres un desarrollador, puede ser que tengas una aplicación heredada o un conjunto de componentes y te dicen que los uses. Estarás presionado para saber cómo usar los elementos hasta que te hayas formado un modelo conceptual de su uso.
Con UML aplicas los diagramas de caso de uso para visualizar el comportamiento del sistema, subsistema o clase para que los usuarios puedan comprender cómo usar ese elemento y los desarrolladores puedan implantarlo.
Un diagrama de casos de uso es sólo una clase especial de diagrama y comparte propiedades comunes como todos los otros diagramas. Un nombre y contenido gráfico que son proyecciones del modelo. Lo que distingue a un diagrama de caso de uso de otros diagramas es su contenido particular.
Contenido
Un diagrama de caso de uso contiene
- Casos de uso
- Actores
- Relaciones de dependencia, generalización y asociación
Como todos los demás diagramas, puede tener notas y restricciones.
También pueden contener paquetes, los cuales se usan para agrupar elementos de tu modelo en grupos más grandes. Ocasionalmente, querrás poner instancias de casos de uso en tus diagramas para visualizar la ejecución específica del sistema.
Usos comunes
Aplicas diagramas de caso de uso para modelar la vista estática del caso de uso de un sistema. Esta vista primariamente soporta el comportamiento de un sistema –los servicios externos que el sistema provee en el contexto de su ambiente.
Cuando modelas la vista estática del caso de uso de un sistema, típicamente aplicarás los diagramas de caso de uso en una de dos maneras:
- Para modelar el contexto de un sistema. Modelar el contexto de un sistema involucra dibujar una línea alrededor del sistema completo y especificando cuáles actores están fuera del sistema e interactúan con él. Aquí, aplicaras los diagramas de caso de uso para especificar los actores y el significado de sus roles.
- Para modelar los requerimientos de un sistema. Modelar los requerimientos de un sistema involucra especificar que debe hacer el sistema (desde un punto externo del sistema), independientemente de cómo el sistema debe hacerlo. Aquí aplicarás los diagramas de caso de uso para especificar el comportamiento deseado del sistema. De esta manera, los diagramas de caso de uso te permiten ver el sistema como una caja negra, puedes ver la parte externa al sistema y puedes ver cómo el sistema reacciona a los casos externas, pero no puedes ver cómo el sistema trabaja por dentro.
Técnicas de modelado comunes
Modelar el contexto de un sistema.
Dado un sistema, algunas cosas están dentro del sistema y otras están afuera. Por ejemplo, un sistema de validación de tarjetas de crédito, encontraras cosas como cuentas, transacciones, agentes de detección de fraude dentro del sistema. Similarmente, encontrarás tales cosas como clientes de tarjeta de crédito e instituciones de servicios financieros fuera del sistema. Las cosas que viven dentro del sistema son responsables de llevar a cabo el comportamiento de aquellas cosas que los de afuera esperan que el sistema provea. Todas las cosas que están afuera e interactúan con el sistema constituye el contexto de un sistema. Este contexto define el ambiente en el cual el sistema vive.
En el UML, puedes modelar el contexto de un sistema con un diagrama de casos de uso, enfatizando a los actores que rodean al sistema. Decidir qué incluir como actor es importante para al hacerlo especificar una clase de cosas que interactúan con el sistema. Decidir que no incluir como actor es igualmente, si no más, importante porque restringe el ambiente del sistema al incluir sólo aquellos actores que son necesarios para la vida del sistema.
Para modelar el contexto de un sistema,
- Identifique los actores que rodean al sistema al considerar cuales grupos requieren ayuda del sistema para realizar sus tareas, cuales gurpos son necesarios para ejecutar las funciones del sistema, cuales grupos interactúan con sistemas externos de hardware o software, y cuáles grupos realizan funciones secundarias para la administración y mantenimiento.
- Organiza a los actores que son similares entre sí en una jerarquía de generalización/especialización.
- Donde ayude a la comprensión, proporciona un estereotipo para cada actor.
- Llena un diagrama de caso de uso con estos actores y especifica las trayectorias de comunicación de cada actor con los casos de uso del sistema.
Esta misma técnica se aplica para modelar el contexto de un subsistema. Un sistema en un nivel de abstracción generalmente es un subsistema en un sistema mayor en un nivel de abstracción más alto. Modelar el contexto de un subsistema es entonces útil cuando construyes productos de sistemas interconectados.
Modelar los requerimientos de un sistema
Un requerimiento es una característica del diseño, propiedad o comportamiento de un sistema. Cuando enuncias los requerimientos de un sistema estás estableciendo un contrato, establecido entre las cosas que están afuera del sistema y las que están dentro, el cual declara que es lo que espera que el sistema haga. En la mayoría de los casos, no te importa cómo lo hace el sistema, sólo que sí lo hace. Un sistema bien definido llevará todos sus requerimientos completa y previsiblemente. Cuando construyes un sistema, es importante hincar con un acuerdo lo que hará el sistema, aunque ciertamente evolucionará tu entendimiento de aquellos requerimientos conforme iterativa e incrementalmente implementes el sistema. Similarmente, cuando tengas que usar un sistema, saber cómo lo hace es esencial para usarlo apropiadamente.
Los requerimientos pueden ser expresados en varias formas, desde texto no estructurado a expresiones en un lenguaje formal, y todo lo que esté entre estos dos extremos. La mayoría, si no es que todo, los requerimientos funcionales de un sistema pueden ser expresados como casos de unos, y los diagramas de caso de uso de UML son esenciales para administrar estos requerimientos.
Para modelar los requerimientos de un sistema:
- Establece el contexto del sistema al identificar los actores que lo rodean.
- Para cada actor, considera el comportamiento que cada uno espera o requiere que el sistema proporcione.
- Designe estos comportamientos comunes como casos de uso.
- Factorice el comportamiento común en nuevos casos de uso que serán usados por otros; factorice variantes de comportamiento en nuevos casos de uso que extiendan más los flujos principales.
- Modele estos casos de uso, actores y sus relaciones en diagramas de casos de uso.
- Agregue observaciones a estos casos de uso con notas que incluyan requerimientos no funcionales; pudieran anexar algunos de estos al sistema completo.
Ejemplos
En esta sección se presentan dos ejemplos en los cuales se analizan los requerimientos del enunciado del problema, se identifican los casos de uso y se describe el escenario de cada uno de ellos.
El juego del 7
En este juego participa un jugador y se requieren dos dados. El jugador tira ambos dados y suma las caras superiores. Previamente, se hace una apuesta sobre lo que será la suma de los dados (debajo del 7, 7 o arriba del 7). En caso de que haya apostado a que la suma sería abajo del siete y acertó, gana la suma apostada. Lo mismo sucede cuando apuesta arriba del 7. En caso de que haya elegido el 7 y acierta, gana el triple de la apuesta. En caso de no acertar, pierde la cantidad apostada.
Requerimientos funcionales
Del jugador
® El sistema deberá registrar el capital inicial del jugador.
® El jugador podrá apostar una cantidad menor o igual a su capital.
® El jugador podrá elegir las siguientes jugadas: arriba del 7, debajo del 7 y el 7.
® El sistema deberá registrar el capital, apuesta y jugada del jugador.
De los dados
® Los dados tienen seis caras, numeradas del 1 al 6.
® El juego consta de dos dados.
® El sistema deberá generar los valores de una cara cuando se tire el dado.
® El sistema deberá presentar los resultados de tirar los dos dados en un juego y la suma de éstos.
Determinación del ganador y ajuste del capital
® El jugador gana si su jugada corresponde a la suma de las caras superiores de los dos dados.
® El jugador pierde si su jugada no corresponde a la suma de las caras superiores de los dos dados.
® Si el jugador gana, al elegir arriba del 7 o debajo del siete, se le deberá pagar el 100% de su apuesta.
® Si el jugador gana, al elegir el 7, se le pagará el 300% de su apuesta.
® Si el jugador pierde se le descontará de su capital la cantidad apostada.
® El sistema deberá informar al jugador los resultados de su juego (ganaste/perdiste).
® El sistema deberá presentar el nuevo capital del jugador.
|
Caso de uso: |
Juega al 7 |
|
Participantes: |
Jugador |
|
Tipo |
Primario |
|
Descripción: |
Este caso de uso comienza cuando el jugador hace una apuesta en el juego del 7 recoge los dados y los hace rodar. Si la suma de los dados corresponde a su apuesta gana; de lo contrario, pierde. |
Curso normal de
eventos
|
Acción del actor |
Respuesta del sistema |
|
1. Este caso de uso comienza cuando el jugador hace una apuesta y elige su jugada en el juego del 7 |
|
|
|
2. El sistema registra la apuesta y jugada. |
|
3. El jugador tira los dos dados. |
|
|
|
4. El sistema presenta los valores de la cara superior de los dos dados. |
|
|
5. El sistema calcula y presenta la suma de las caras superiores de los dados. |
|
|
5. El sistema determina si el jugador ganó el juego con su jugada y presenta el resultado. |
|
|
6. El sistema hace el ajuste de capital del jugador. |
|
|
7. El sistema presenta el nuevo capital del jugador. |
Precondición. Antes de que el jugador haga la apuesta debe registrar su capital.
Curso alterno:
Línea 2. El sistema deberá verificar que la apuesta del jugador sea mayor al capital y que la jugada sea válida.
El Hotel
El hotel Baja tiene cinco salones de eventos (numerados del 1 al 5) y 40 habitaciones (numeradas del 6 al 45). Las primeras 10 habitaciones son sencillas, mientras que las restantes son dobles. Cuando un cliente llega al hotel, éste se registra en la primera habitación disponible requerida (sencilla, doble). Se registra el nombre del cliente y el pago de la habitación ($ 600.00 pesos habitación sencilla y $1000.00 habitación doble).
Los salones tienen una tarifa de $10 000.00 pesos. El hotel sólo tiene un equipo de presentación, así que si se renta un salón y se requiere este servicio tendrá que instalarse en el salón alquilado. El equipo siempre se queda en el salón que lo utilizó la última vez. El cliente puede elegir el salón que desee, siempre y cuando esté disponible. El cliente puede ocupar y desocupar la habitación o el salón el mismo día.
Este hotel es muy especial, ya que no trabaja con reservaciones ni con fechas. Además, todos los días el gerente genera los siguientes reportes:
- Cuántas habitaciones y salones están ocupados.
- Los números de habitaciones ocupados y la información de los residentes.
- Los números de salones ocupados y la información del cliente.
- El salón que tiene el equipo de presentación.
- Cuál es la ganancia del día.
Lista de
requerimientos
Hotel
- El hotel tiene habitaciones sencillas, dobles y salones de eventos.
- El hotel alquila sus espacios a los clientes.
- El hotel requiere los reportes siguientes, realizados por el gerente:
- Cuántas habitaciones y salones están ocupados.
- Los números de habitaciones ocupados y la información de los residentes.
- Los números de salones ocupados y la información del cliente.
- El salón que tiene el equipo de presentación.
- Cuál es la ganancia del día.
Salones de eventos
- Existen cinco salones de eventos, numerados del 1 al 5.
- La tarifa de cada salón es de $10 000.00 diarios.
- El cliente puede alquilar el salón que desee siempre y cuando esté desocupado.
- El alquiler y renta del salón ocurre el mismo día.
- Cuando el cliente alquile el salón este último estará ocupado.
Equipo de presentación
- El hotel cuenta con un equipo de presentación.
- El equipo de presentación únicamente se puede instalar en un salón.
- El equipo de presentación puede ser solicitado por el cliente.
- El equipo se puede mover al salón que lo solicite el cliente.
- El equipo está ocupado si el salón está alquilado y se solicitó el equipo.
Habitaciones sencillas
- Existen 10 habitaciones sencillas, numeradas del 6 al 15.
- Deberá conocerse la primera habitación desocupada de la secuencia.
- El cliente puede solicitar el alquiler de una habitación sencilla.
- La tarifa por habitación sencilla es de $600.00 pesos.
- Cuando el cliente alquile la habitación sencilla esta última estará ocupada.
- Cuando el cliente entregue la habitación, el estatus será desocupado.
Habitaciones dobles
- Existen 30 habitaciones sencillas, numeradas del 16 al 45.
- Deberá conocerse la primera habitación desocupada de la secuencia.
- El cliente puede solicitar el alquiler de una habitación doble.
- La tarifa por habitación doble es de $600.00 pesos.
- Cuando el cliente alquile la habitación doble esta última estará ocupada.
- Cuando el cliente entregue la habitación, el estatus será desocupado.
Cliente
- El cliente puede solicitar cualquier habitación o salón de eventos, siempre y cuando haya vacantes.
- El recepcionista deberá registrar el nombre del cliente y el pago de la habitación.
- Se asume que el cliente paga en efectivo con la cantidad exacta.
- El cliente puede rentar varios espacios cuando llega al hotel.
Actores
Cliente – Persona que alquila un espacio (salón, habitación, sencilla, habitación doble)
Recepcionista – Persona que atiende al cliente cuando llega al hotel y se retira de éste.
Gerente – Persona que se encarga de analizar el estado del negocio.
Casos de uso
Descripción de los casos de uso
|
Caso de uso: |
Alquilar espacio |
|
Participantes: |
Cliente (iniciador), recepcionista |
|
Tipo |
Primario |
|
Descripción: |
Un cliente llega al hotel para alquilar un espacio. El recepcionista verifica que haya vacantes, registra los datos del cliente y asigna el espacio. |
Curso normal de eventos
|
Acción del actor |
Respuesta del sistema |
|
|
|
|
4. El sistema busca un espacio disponible en el hotel. 5. El sistema indica el número del espacio disponible y el costo. |
|
|
|
|
|
|
11. El recepcionista le indica al cliente que ya puede usar el espacio. |
|
Simplificaciones, metas y suposiciones.
Curso alterno:
Línea 4. Si no hay vacantes, el recepcionista deberá informar al cliente.
Si la renta es de un salón de eventos y requiere el equipo de presentación, deberá verificar que esté disponible.
|
Caso de uso: |
Solicitar equipo de presentación |
|
Participantes: |
Cliente (iniciador), Recepcionista |
|
Tipo |
Primario |
|
Descripción: |
Cuando el cliente alquila el salón de eventos, si lo requiere solicita el equipo de presentación para que sea instalado en dicho salón. |
Curso normal de eventos
|
Acción del actor |
Respuesta del sistema |
|
|
|
|
2. El sistema muestra el estatus del equipo y el número de salón en que está. |
|
3. El recepcionista registra el cambio de equipo de salón y cambia su estado a ocupado. |
|
|
|
4. El sistema actualiza la localización del equipo y su estado. |
|
5. El recepcionista le informa al cliente que el equipo está disponible. |
|
Simplificaciones, metas y suposiciones.
Precondición. Para que pueda ser asignado el equipo a un salón, el cliente primero deberá alquilar el espacio.
Curso alterno:
Línea 2. El sistema deberá informar al cliente que el equipo está ocupado.
|
Caso de uso: |
Entregar espacio |
|
Participantes: |
Cliente (iniciador), recepcionista |
|
Tipo |
Primario |
|
Descripción: |
Cuando el cliente desocupa un espacio, le informa al recepcionista. El recepcionista actualiza la información del espacio. |
Curso normal de eventos
|
Acción del actor |
Respuesta del sistema |
|
|
|
|
3. El sistema realiza la búsqueda de los datos del cliente con el número de espacio. 4. El sistema muestra la información del cliente y el estado del espacio. |
|
5. El recepcionista registra la entrega del espacio. |
|
|
|
6. El sistema actualiza el estado del espacio. |
|
7. El recepcionista le informa al cliente que terminó el proceso. |
|
Simplificaciones, metas y suposiciones.
Precondición. El cliente debió haber alquilado un espacio.
Curso alterno:
Línea 4. Si la información que muestra el sistema no corresponde al cliente, el recepcionista deberá solicitar nuevamente el número de espacio alquilado.
Deberá mostrar si el cliente solicitó el equipo.
Línea 6:
Si el cliente había solicitado el equipo, deberá actualizar su estado a desocupado.
|
Caso de uso: |
Generar informes |
|
Participantes: |
Gerente |
|
Tipo |
Primario |
|
Descripción: |
El gerente desea conocer el estado del negocio para lo cual, solicita informes al sistema. |
Curso normal de eventos
|
Acción del actor |
Respuesta del sistema |
|
1. Este caso de uso comienza cuando el gerente desea saber cual es el estado del negocio. |
|
|
|
2. El sistema muestra los distintos informes que puede generar. |
|
3. El gerente elige el informe. |
|
|
|
4. El sistema presenta el informe. |
|
4. El gerente adquiere el informe. |
|
|
|
|
|
|
|
|
|
|
Simplificaciones, metas y suposiciones.
Los informes son:
1. Cuántas habitaciones y salones están ocupados.
2. Los números de habitaciones ocupados y la información de los residentes.
3. Los números de salones ocupados y la información del cliente.
4. El salón que tiene el equipo de presentación.
5. Cuál es la ganancia del día.
Bibliografía
Pressman, Roger.
Ingeniería del software: Un enfoque práctico. 5ta. ed.
Larman, Craig. UML y Patrones. Introducción al análisis y
diseño orientado a objetos. Prentice Hall, México, 1999.
Fowler,
Martin. UML gota a gota. Addison Wesley Longman de México, México, 1999.
Sintes, Anthony. Aprendiendo programación
orientada a objetos en 21 lecciones avanzadas. Pearson
Educación, México, 2002.
Jacobson, I., Booch,
G. y Rumbaugh, J. El proceso unificado de desarrollo
de software. Pearson Educación,
Rosenberg, Doug y Scott, Kendall. Use Case
Driven Obejct Modeling with UML: A practical
approach. Addison Wesley,
Rosenberg, Doug y Scott, Kendall. Appying Use Case Driven Object Modeling with UML: An
annotated e-commerce Example. Addison Wesley,
Booch, Grady, Rumbaugh, J. y Jacobson, I. The
Unified Modeling Language User Guide. Addison Wesley, 1998.