UNIVERSIDAD NACIONAL DE EDUCACION

Enrique Guzmán y Valle

“Alma Máter del Magisterio Nacional”

PROGRAMA DE SEGUNDA TITULACIÓN DE LA UNE - 2018

SEDE COMAS

TRABAJO DE INVESTIGACIÓN

CASOS DE USOS
Diagramas de Caso de Uso y sus relaciones

CURSO:

DOCENTE: Mg. José Alberto MARQUEZ BELTRÁN

INTEGRANTES:
 Ñery Rodríguez Huerta
 Jorge P. Calderón Marreros

2018
 INTRODUCCION

Los casos de uso forman parte del UML Lenguaje Unificado de Modelado que sirve para especificar
construir y documentar sistemas representado a través de un conjunto de símbolos que son fáciles de
entender por cualquier desarrollador.

El modelo de casos de uso describe la funcionalidad propuesta del nuevo sistema es una unidad discreta
de interacción entre un usuario (humano o máquina) y el sistema.

En un caso de uso uno o más actores interaccionan con el sistema que realiza algunas acciones.

2
 CASOS DE USOS
¿Qué son los casos de uso?
Un caso de uso es una descripción de las actividades que deben realizarse para llevar a cabo un proceso.
Representan las funciones que proporciona un sistema que son de valor para sus usuarios.

Un caso de uso es una descripción de las actividades que deben realizarse para llevar a cabo un proceso.
Representan las funciones que proporciona un sistema que son de valor para sus usuarios.

Un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un
evento que inicia un actor sobre el propio sistema.

Los casos de uso son una técnica para la especificación de requisitos funcionales propuesta inicialmente
en [Jac93] y que actualmente forma parte de la propuesta de UML [Boo99].

Un caso de uso es la descripción de una secuencia de interacciones entre el sistema y uno o más actores
en la que se considera al sistema como una caja negra y en la que los actores obtienen resultados
observables.

Características
 Realiza entrevista con el usuario de tal manera que le proporcione información necesaria para
crear caso de uso.
 Realiza su modelamiento de datos a través de Lenguaje Unificado de Modelado UML.
 Utiliza diagramas de relaciones el cual mediante una representación gráfica nos muestra las
causas y efectos entre diversos actores o casos de uso.

Los casos de uso sus ventajas y desventajas

Actualmente los casos de Uso nos brindan una gran ayuda para representar los requerimientos que
compondrán el sistema a desarrollar. Recordemos que los casos de uso son una descripción de los pasos
o las actividades que deberán realizarse para llevar a cabo algún proceso.

Por tanto podemos decir que en ingeniería de software, un caso de uso es una secuencia de interacciones
que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal
sobre el propio sistema. Así es que los diagramas de casos de uso sirven para especificar la comunicación

3
y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. Las
ventajas y desventajas de utilizar los casos de uso son:

Ventajas
 Fácil diagramación
 Facilita el entendimiento de los procesos realizados por el sistema para el desarrollador
 Plantea las interacciones básicas entre usuario y sistema
 Expresar la intención que tiene el actor (usuario)
 Extraer los requerimientos del usuario y del sistema
 Centrar al analista en las tareas principales de usuario (describiendo los casos de mayor
importancia).
 Tener en cuenta todos los usuarios evitando que las personas especializadas en informática
dirijan la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos.

Desventajas
 No establecen los requisitos funcionales.
 Tampoco permiten establecer los requisitos no funcionales.
 Cuando el diagrama es muy extenso o muy amplio se dificulta su entendimiento
 No se marcan los tiempos de duración de las actividades
 No se pueden diagramar dos casos de uso exactamente igual
 Los casos de uso deben complementarse con información adicional como:
 Reglas de negocio
 Requisitos no funcionales
 Diccionario de datos que complementen los requerimientos del sistema.
 Cada caso crítico del uso debe tener un requisito no funcional centrado en el funcionamiento
asociado.

Limitaciones
Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no establecen
completamente los requisitos funcionales ni permiten determinar los requisitos no funcionales. Los casos
de uso deben complementarse con información adicional como reglas de negocio, requisitos no
funcionales, diccionario de datos que complementen los requisitos del sistema. Sin embargo la ingeniería

4
del funcionamiento especifica que cada caso crítico del uso debe tener un requisito no funcional centrado
en el funcionamiento asociado.

Pasos para la Definición de un Caso de Uso:

 ID
 NOMBRE
 REFERENCIAS CRUZADAS
 CREADO POR
 ULTIMA ACTUALIZACIÓN POR
 FECHA DE CREACIÓN
 FECHA DE ULTIMA ACTUALIZACIÓN
 ACTORES
 DESCRIPCIÓN
 TRIGGER
 PRE-CONDICIÓN
 POST-CONDICIÓN
 FLUJO NORMAL
 FLUJOS ALTERNATIVOS
 INCLUDES
 FRECUENCIA DE USO
 REGLAS DE NEGOCIO
 REQUISITOS ESPECIALES
 NOTAS Y ASUNTO

Finalidad del caso de uso

Su finalidad es definir una pieza de comportamiento coherente sin revelar la estructura interna del
sistema. Tenemos dos puntos de vista de un caso de uso:
 En el modelo, la ejecución de cada caso de uso es independiente de los otros.
 En el sistema, representan el comportamiento externo del mismo y como es percibido por los
actores.
 Cada caso de uso se debe corresponder con las clases que implementan un sistema. Su
comportamiento se corresponde con las transacciones y operaciones de las clases. Su

5
 implementación se puede modelar como un conjunto de una o más colaboraciones (una
colaboración es la realización de un caso de uso).
 Su dinámica se materializa en diagramas de estados, diagramas de secuencia, diagramas de
comunicación o descripciones informales de texto.

El propósito del caso de uso

El propósito primario del modelo caso de uso es comunicar las funciones y el comportamiento del
sistema al cliente o al usuario final.

Describir lo que debería hacer el sistema mediante estudio o análisis del sistema para representarlo
mediante diagramas haciendo uso de los diversos elementos como: caso de uso, actores, relaciones.

Importancia de los casos de uso

El caso de uso es una excelente herramienta para estimular a que los usuarios potenciales hablen, de un
sistema, desde su propio punto de vista.
La idea es involucrar los usuarios en las etapas iniciales del análisis y diseño del sistema. Esto aumenta
la probabilidad de que el sistema sea de mayor provecho a la gente para la que supuestamente ayudaría,
en lugar de ser un manejo de expresiones de computación incompresibles e inimaginables para los
usuarios finales.

¿Porque es importante los casos de uso y diagramas UML para un analistas de sistema?
Los casos de uso y los diagramas UML son muy importantes para analistas de sistemas ya que son los
pasos a realizar para realizar un programa o deberes de una vida cotidiana, es lo que hacemos nosotros

6
en nuestra vida diaria, cuando una persona va a estudiar o trabajar tiene que realizar una serie de pasos
logrando un objetivo, la que estudia su objetivo es terminar su carrera o sus estudios para poder salir
adelante y formar su futuro y el que trabaja quiere que su trabajo salga bien y satisfaga a su jefe para
poder lograr un mayor puesto y seguir trabajando.

Tipos de casos de uso

Casos de Uso Casos de usos según la importancia: primarios, secundarios y opcionales.
o Primario: los casos primarios de uso representan los procesos comunes más importantes.
Representan los procesos comunes más importantes. Ejemplo Comprar Productos.
o Secundario: los casos secundarios de uso representan procesos menores o raros.
Representan procesos menores o raros. Ejemplo Solicitud de surtir el nuevo producto.
o Opcional: los casos opcionales de uso representan procesos que pueden no abordarse.
Representan procesos que pueden no abordarse.

Según cual sea el nivel de detalle:

o Breve: Descripción en unas pocas líneas.
o Informal: varios párrafos que cubren varios escenarios
o Completo: Descripción detallada con una plantilla
o Resumidos o de “Alto nivel”: durante la fase de inicio (RUP) la mayor parte de los casos de uso
deben tener esta forma.
o Extendidos: Durante la fase de elaboración (RUP) los casos de uso deben escribirse de esta
forma.
Según el nivel de abstracción se distingue entre:
o Esenciales: hacen referencia a la funcionalidad esperada. Intenciones del usuario y
responsabilidades del sistema.
Son casos expandidos que se expresan en una forma teórica que contiene poca tecnología y pocos
detalles de implementación. Son de carácter esencial, debido a su brevedad y abstracción.
o Concreto: se contemplan detalles de implementación.
o Implementación: reales o concretos: hacen referencia a detalles de la interfaz.
Los Casos Reales de Uso, describe concretamente el proceso a partir de su diseño concreto
actual, sujeto a las tecnologías específicas de entrada y salida, etc. Cuando se trata de la interfaz
para el usuario, a menudo ofrece presentaciones de pantalla y explica la interacción con los

7
 elementos. El Cliente se identifica a sí mismo, del caso de uso se realizó ahora concretamente
en la serie de acciones comenzando con el cliente introduce su tarjeta.
Casos de Uso Casos de uso Esencial – Ejemplo Compra de Productos
Casos de Uso Casos de uso Real – Ejemplo Compra de Productos

Existen formas: Gráfica y Narrativa.

Tipos de actores
 Primarios: interaccionan con el sistema para explotar su funcionalidad; trabajan directa y
frecuentemente con el software.
 Secundarios: soporte del sistema para que los primarios puedan trabajar.
 Iniciadores: no utilizan directamente el sistema pero desencadenan el trabajo de otro actor. (No
aparecen en UML pero sí los consideran otros autores).

Normas de aplicación
Los casos de uso evitan típicamente el lenguaje técnico, prefiriendo la lengua del usuario final o del
experto del campo del saber al que se va a aplicar. Los casos del uso son a menudo elaborados en
colaboración por los analistas de requisitos y los clientes.

Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea. Desde una perspectiva
tradicional de la ingeniería de software, un caso de uso describe una característica del sistema. Para la
mayoría de proyectos de software, esto significa que quizás a veces es necesario especificar decenas o
centenares de casos de uso para definir completamente el nuevo sistema. El grado de la formalidad de
un proyecto particular del software y de la etapa del proyecto influenciará el nivel del detalle requerido
en cada caso de uso.

Los casos de uso pretenden ser herramientas simples para describir el comportamiento del software o de
los sistemas. Un caso de uso contiene una descripción textual de todas las maneras que los actores
previstos podrían trabajar con el software o el sistema. Los casos de uso no describen ninguna
funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se implementará. Simplemente
muestran los pasos que el actor sigue para realizar una operación.

Un caso de uso debe:

8
  Describir una tarea del negocio que sirva a una meta de negocio.
 Tener un nivel apropiado del detalle.
 Ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento.
Situaciones que pueden darse:
 Un actor se comunica con un caso de uso (si se trata de un actor primario la comunicación la
iniciará el actor, en cambio si es secundario, el sistema será el que inicie la comunicación).
 Un caso de uso extiende otro caso de uso.
 Un caso de uso utiliza otro caso de uso.

Relaciones de casos de uso

Las relaciones principales entre los casos de uso son soportadas por el estándar UML, el cual describe
notación gráfica para esas relaciones.

 Asociación
 Inclusión
 Extensión
 Generalización

 Comunicación: Relación (asociación) entre un actor y un caso de uso. El estereotipo de la

relación de comunicación es: <<communicate>> aunque generalmente no se estipula ningún
nombre, como podemos apreciar en el siguiente ejemplo de comunicación:

 Asociación: La asociación sólo es entre actores y casos de uso. Denota la participación de ese
actor en ese caso de uso.

9
 Inclusión: Esta relación es entre dos casos de uso. Se usa para evitar describir el mismo flujo de
eventos repetidas veces. Se usa cuando muchos casos de uso van a usarlo, que especifica una
situación en la que un caso de uso tiene lugar dentro de otro caso de uso.
La relación de inclusión sirve para enriquecer un caso de uso con otro y compartir una
funcionalidad común entre varios casos de uso, también puede utilizarse para estructurar un caso
de uso describiendo sus subfunciones. El caso de uso incluido existe únicamente con ese
propósito, ya que no responde a un objetivo de un actor.
Estas relaciones se representan mediante una flecha discontinua con el estereotipo <<include>>.
Algunos casos de uso típicos de inclusión son: comprobar, verificar, buscar, validar, autentificar
o login… En principio, no deberíamos abusar de este tipo de relación, para no hacer una
descomposición funcional del sistema. A partir de UML 1.3 la relación <<include>> reemplazó
al denominado <<uses>>.

Ejemplo de la biblioteca: supongamos que si un usuario tiene 3 libros prestados no puede coger
otro libro. Por tanto cuando el empleado de la biblioteca vaya a registrar el préstamo, el sistema
tendrá que comprobar los préstamos que tiene ese usuario. Ese se podría modelar así:

Prestar “include” Comprobar

Libro Préstamo

Empleado

El caso de uso Prestar Libro incluye el caso de uso Comprobar Préstamos.

 Extensión: Esta relación también es entre dos casos de uso. Se utiliza cuando un caso de uso
extiende el comportamiento de otro. Sirven para separar el comportamiento obligatorio del
opcional, o para modelar ciertos subflujos de eventos que se ejecutan sólo bajo ciertas
condiciones.
La relación de extensión sirve para modelar: la parte opcional del sistema, un subflujo que sólo
se ejecuta bajo ciertas condiciones o varios flujos que se pueden insertar en un punto

10
 determinado. Este tipo de relación produce confusión y no debería utilizarse en exceso. Conviene
su uso sólo para insertar un nuevo comportamiento no previsto en un caso de uso existente. Estas
relaciones se representan mediante una flecha discontinua con el estereotipo <<extend>>.
Imaginemos que queremos modelar el funcionamiento de un tienda online. Los usuarios pueden
realizar pedidos. Cuando están realizando el pedido hay una opción que es “urgente”. Si
seleccionan esa opción el pedido se envía lo más rápido posible aunque el coste será mayor. Eso
lo modelaríamos de la siguiente forma:

Realizar pedido Realizar

“extend” pedido
Extensión points urgente urgente
Urgente

El caso de uso Realizar Pedido Urgente extiende al caso de uso Realizar Pedido.

Empleado

 Generalización: es el mismo comportamiento que en herencia. La generalización en los casos

de uso es igual que la de las clases. Tenemos un caso de uso abstracto cuyo comportamiento lo
proporcionarán sus hijos.
Un caso de uso (subcaso) hereda el comportamiento y significado de otro, es decir las relaciones
de comunicación, inclusión y extensión del super-caso de uso. En muchas ocasiones este super-
caso de uso es abstracto y corresponde a un comportamiento parcial completado en el subcaso
de uso. O dicho de otra manera, Los casos de uso “hijo” son una especialización del caso de uso
“padre”. En la medida de lo posible debería evitarse puesto que produce cierta confusión en
algunas ocasiones.
Por ejemplo hay sistemas en los que es necesario validarse para poder usarlos. Podemos
validarnos con la típica forma de usuario y contraseña o con formas más futuristas como la
comprobación de retina o de huellas dactilares. Eso lo podemos modelar así:

Validar usuario

11
Modelo de Casos de Uso
Comprobar Examinar Comprobar
clave retina huella
Beneficios del Modelado con casos de Uso:
El caso de uso es una excelente herramienta para estimular a que los usuarios potenciales hablen, de un
sistema, desde sus propios puntos de vista. No siempre es fácil para los usuarios explicar como pretenden
utilizar un sistema. Puesto que el desarrollo tradicional de los sistemas era, con frecuencia, algo así como
una ciencia oculta, con muy poca información para los usuarios, a aquellos que osaban preguntar se les
daba información muy poco explícita o ciertamente confusa respecto a lo que utilizarían.

 Los casos usos son: Usados para comunicarse con el usuario final y el experto del dominio
proporciona credibilidad en una etapa inicial del desarrollo del sistema. Asegura una
comprensión mutua de los requisitos

 Los casos... Es usado para identificar

Quién interactuará con el sistema y qué deberá hacer el sistema Qué interfaz deberá tener el
sistema Es usado para verificar que: Se capturan todos los requisitos. Que los desarrolladores
hayan entendido los requisitos

En el siguiente modelo quedarán representados los diferentes "roles" con los que se puede hacer uso del
sistema y que serán representados por los actores, así como los distintos casos de uso a través de los
cuales podrán interactuar con él.

2.1.1 Glosario del MCU

Invitado: se trata de un actor que accede a la plataforma, pero no se ha identificado. Usuario: un actor
que sí ha completado los procesos de registro e identificación y que por tanto tiene acceso a las
funcionalidades que muestra el diagrama de casos de uso. Como se puede observar en la jerarquía de
actores, también tiene acceso a las actividades propias del Invitado. Administrador: actor que puede
realizar todas funcionalidades del Usuario (y por extensión del Invitado) y que además puede Gestionar
Usuarios. A continuación se procederá a explicar cada caso y subcaso de uso de manera más detallada
en el Modelo de Casos de Uso Extendido.

12
2.2 Modelo de Casos de Uso Extendido
Tabla Nº : 1

Nombre Evaluar
Descripción: Permite al usuario evaluar una campaña. Este caso de uso consta de 2 subcasos de uso. Esto se
debe a que tanto "Crear Campaña" como "Registrar Empresa" a pesar de que no son funcionalidades totalmente
independientes, es decir, no pueden ser ejecutadas de manera independiente en el sistema; poseen la
funcionalidad y el peso suficiente como para ser tratados como casos de uso en el modelo. Sin embargo, al no
tratarse de casos de uso como tal, no se vinculan a un actor directamente, sino que quedan conectadas a la
funcionalidad que precede su ejecución. Además en este caso, están relacionadas con dicha funcionalidad:
siempre que se evalúa una campaña, una instancia de esta es creada y almacenada en la BBDD (<<include>>).
Por otro lado, si en el proceso de evaluación se desea, el usuario puede "Registrar una Empresa" nueva en el
sistema de manera que aparezca en su historial y le sea propuesta en futuras evaluaciones para facilitarle el
proceso.(<<extend>>).
Aquí se dan relaciones entre un caso de uso y 2 subcasos de uso, de ahí que el modelo resulte de este modo. El
modelo resultaría diferente si se tratara de una relación entre 2 casos de uso. Por ejemplo, la relación dada entre
"Consultar Historial" y "Eliminar Campañas" en la cual ambos son casos de uso.
Actores: Usuario.
Precondiciones: Ninguna.
Flujo de eventos:
1. El usuario selecciona “Go!” en la barra de navegación del menú principal.
2. El usuario elige la plataforma para la cual desea evaluar la campaña y pulsa “Aceptar”.
3. Introduce los datos requeridos para la evaluación y pulsa "Continuar".
4. Si los datos no son correctos, se validará el formulario y se mostrará un mensaje de error debajo de los
campos correspondientes.
5. Si los datos son correctos accederá al menú de selección de empresa, donde dispondrá de 3 opciones:
a. Si la empresa con la que desea relacionar la campaña ya está en el sistema, podrá elegirla
directamente de la lista de empresas registradas.
b. Si el usuario desea seleccionar una empresa con la que ya ha trabajado anteriormente, podrá hacerlo
desde el menú de empresas utilizadas por dicho usuario que le será mostrada por pantalla.
c. Si la empresa buscada no está en el sistema y lo desea, podrá registrarla seleccionando "Crear nueva
Empresa".
c1 Para registrar una empresa deberá introducir su nombre y presupuesto y pulsar "Crear".
C2 Si los datos no son correctos, se validará el formulario y se mostrará un mensaje de error debajo
de los campos correspondientes.

13
 C3 Si los datos son correctos se creará una nueva empresa en el sistema. 6. Se mostrará la pantalla
del balance final de la campaña con su correspondiente imagen y evaluación sobre ella.
Post-condiciones: Se evalúa la campaña, se crea una instancia de dicha campaña en la BBDD y si el usuario ha
decidido insertar una nueva empresa en el proceso, será almacenada en el sistema.
Tabla Nº : 2

Nombre: Consultar Historial.

Descripción: Permite al usuario consultar su historial de campañas y eliminar las deseadas.

Actores: Usuario.
Precondiciones: Ninguna.
Requisitos no funcionales: Ninguno.
Flujo de eventos:
1. El usuario selecciona “Historial” en la barra de navegación del menú principal.
2. Se le pedirá al usuario que introduzca 2 fechas para realizar un filtrado entre ambas y facilitarle la
búsqueda de campañas de manera más eficiente.
3. Una vez seleccionados dichos datos le aparecerán las campañas entre esas 2 fechas.
a. Si lo desea podrá eliminar la campaña directamente desde esta vista.

Post-condiciones: Las campañas seleccionadas para ser eliminadas desaparecerán del sistema si así lo desea el
usuario. En cualquier otro caso no se daría post-condición alguna.

Tabla Nº : 3

Nombre: Modificar Perfil.

Descripción: Permite al usuario modificar los datos de su perfil.
Actores: Usuario.
Precondiciones: Ninguna.
Requisitos no funcionales: Ninguno.
Flujo de eventos:
1. El usuario selecciona “Modificar Perfil” en la barra de navegación del menú principal.
2. Se le mostrarán sus datos de usuario y se le permitirá modificar algunos de ellos como son su nombre
de inicio de sesión y su contraseña. Modificará sus credenciales y pulsará "Aceptar".

14
 3. Si los datos no son correctos, se validará el formulario y se mostrará un mensaje de error debajo de los
campos correspondientes.
4. Si los datos son correctos se modificarán en la base de datos.
Post-condiciones: Los datos de dicho usuario son actualizados en base de datos.

Tabla Nº : 4

Nombre: Eliminar Campañas.

Descripción: Permite al usuario eliminar las campañas que no desee mantener.
Actores: Usuario.
Precondiciones: Ninguna.
Requisitos no funcionales: Ninguno.
Flujo de eventos:
1. El usuario selecciona “Eliminar Campañas” en la barra de navegación del menú principal.
2. Se cargarán por pantalla todas las campañas evaluadas por dicho usuario. Este seleccionará el icono en
forma de cubo de basura de la campaña que desee eliminar del sistema.

Post-condiciones: Las campañas seleccionadas serán eliminadas de la base de datos.

Tabla Nº : 5

Nombre: Contactar.
Descripción: Permite a cualquiera que visite nuestra web contactar con nosotros.
Actores: Invitado.
Precondiciones: Ninguna.
Requisitos no funcionales: Ninguno.
Flujo de eventos:
1. El Invitado selecciona “Contacto” en la barra de navegación del menú principal.
2. Rellenará los campos del formulario con la información requerida, así como el Captcha y pulsará
"Enviar".

15
 3. Si los datos no son correctos, se validará el formulario y se mostrará un mensaje de error debajo de los
campos correspondientes.
4. Si los datos son correctos el email será enviado correctamente.

Post-condiciones: Se recibirá el email correspondiente en la cuenta de correo configurada para ello.

Tabla Nº : 6

Nombre: Ver información omRocket.

Descripción: Permite a cualquiera que visite nuestra web conocer más a cerca de nosotros.
Actores: Invitado.
Precondiciones: Ninguna.
Requisitos no funcionales: Ninguno.
Flujo de eventos:
1. El Invitado selecciona “sobre omRocket” en la barra de navegación del menú principal.
2. Se le muestra al invitado información acerca de omRocket.

Post-condiciones: Ninguna.

Tabla Nº : 7

Nombre: Ver información ROI.

Descripción: Permite a cualquiera que visite nuestra web conocer más sobre el concepto ROI y sus
aplicaciones según la plataforma.
Actores: Invitado.
Precondiciones: Ninguna.
Requisitos no funcionales: Ninguno.
Flujo de eventos:

16
 1. El Invitado selecciona “ROI?” en la barra de navegación del menú principal.
2. Se le muestra al invitado información relativa al concepto ROI y sus aplicaciones en función de la
plataforma elegida.

Post-condiciones: Ninguna.

Tabla Nº : 8

Nombre: Registrarse.
Descripción: Permite a cualquiera que visite nuestra web registrarse en nuestra base de datos.
Actores: Invitado.
Precondiciones: Ninguna.
Requisitos no funcionales: Ninguno.
Flujo de eventos:
1. El usuario selecciona “Registro” en la barra de navegación del menú principal.
2. El usuario rellena con sus credenciales el formulario de registro, así como el Captcha y pulsa
"Registrar".
3. Si los datos no son correctos o son duplicados en BBDD, se validará el formulario y se mostrará un
mensaje de error debajo de los campos correspondientes.
4. Si los datos son correctos se registrarán los datos del nuevo usuario en el sistema y se le devolverá a la
página de inicio de la aplicación, pero ya como usuario.

Post-condiciones: Un nuevo Usuario con sus correspondientes campos es creado en la base de datos de la
aplicación y este es redirigido a la pantalla principal de usuario.

Tabla Nº : 9

Nombre: Identificarse.
Descripción: Permite a cualquiera que no se haya identificado en nuestra web identificarse.
Actores: Invitado.
Precondiciones: Registrarse.
Requisitos no funcionales: Ninguno.
Flujo de eventos:
1. El usuario selecciona “Identificarse” en la barra de navegación del menú principal.
2. El usuario rellena con sus credenciales (nombre de usuario y contraseña) el formulario de inicio de
sesión y pulsa "Login".

17
 3. Si los datos no son correctos, se validará el formulario y se mostrará un mensaje de error debajo de los
campos correspondientes.
4. Si los datos son correctos se identificará al Invitado en el sistema y será redireccionado a la página de
inicio de la aplicación, pero ya como role de Usuario.
Post-condiciones: El Invitado cambia de role y pasa a ser Usuario en el sistema siendo es redirigido a la pantalla
principal de usuario.
Tabla Nº : 10

Nombre: Gestionar Usuarios.

Descripción: Permite al administrador gestionar los usuarios existentes en el sistema, así como añadir nuevos.
Actores: Administrador.
Precondiciones: Ninguna.
Requisitos no funcionales: Ninguno.
Flujo de eventos:
1. El usuario selecciona “Admin” en la barra de navegación del menú principal.
2. Se cargarán todos los usuarios registrados en el sistema de manera que el administrador podrá disponer
de 3 opciones:
a. Eliminarlos pulsando el icono en forma de cubo de basura.
b. Modificar sus datos seleccionando el icono en forma de lápiz.
b.1. El administrador modificará los datos del usuario seleccionado y pulsará "Aceptar".
b.2. Si los datos no son correctos, se validará el formulario y se mostrará un mensaje de error
debajo de los campos correspondientes.
b.3. Si los nuevos datos introducidos son correctos, se modificarán los campos del usuario elegido
para ser modificado.
c. Crear un nuevo usuario pulsando el botón "Crear Usuario" c.1. El administrador rellenará las
credenciales del nuevo usuario y pulsará "Aceptar
Post-condiciones: Los usuarios correspondientes se verán actualizados o eliminados del sistema. Los nuevos
usuarios creados quedarán registrados en la base de datos del sistema.

18
 DIAGRAMAS DE CASOS DE USO
 Un diagrama de casos de uso muestra la relación entre actores y los casos del sistema.
Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En
el diagrama de caso de uso se representa también el sistema como una caja rectangular con el
nombre en su interior. Los casos de uso están en el interior de la caja el sistema y los actores fuera,
y cada actor está unido a los caos de uso en lo que participa mediante una línea.
 Describe que hace un sistema pero no como.
 Un diagrama de casos de uso es un diagrama que muestra un conjunto de casos de uso, actores y
sus relaciones.
 Un diagrama de casos de uso es simplemente un tipo especial de diagrama que comparten
propiedades comunes con otros diagramas – un nombre y un contenido gráfico que estan dentro de
un modelo. Lo que distingue un diagrama de casos de uso de los otros tipos es su particular
contenido.
Ejemplo de diagrama de casos de uso (nos basaremos en el caso de uso, Hacer Pedido

19
Utilidad del diagrama de caso de uso
Es útil para:
 Para definir como sería el comportamiento de una parte del sistema, ya que solo específica
como debe comportarse y no como se debe implementar.
 Para documentar código que va a ser reutilizado por otros programadores.

Elementos del diagrama de caso de uso

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en
desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de
uso).

Los casos de uso corresponden con los requisitos funcionales del sistema. Si vamos a realizar un sistema
para gestionar los préstamos de una biblioteca tendremos unos requisitos que nos diga: El empleado de
la biblioteca seleccionará la opción de “Prestar Libro” para hacer efectivo el préstamo. La idea es que
cuando alguien quiera
coger un libro
prestado, irá al
mostrador, el
empleado
pulsará en “Prestar
Libro”, introducirá los
datos del libro y del
cliente y el préstamo quedará registrado en el sistema. Eso se modelaría así:

20
 El caso de uso sería Prestar Libro y se representa con una elipse.

Un diagrama de casos de uso consta de los siguientes elementos:

Autores
Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema
informatizado, un hardware u otro sistema interactúa con nuestro sistema.

Un caso de uso
Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el
sistema, cuando el actor usa el sistema para llevar a cabo una tares especifica.
Expresa una unidad coherente de funcionalidad.

Realizar
operaciones

Cambiar
Cliente PIN

Obtener últimos
movimientos
y saldos

Empleado de Agregar clientes

Socurd

21
Se muestra en el diagrama de casos de uso de una máquina expendedora de café. Los actores son los
sujetos de las acciones que representan los casos de uso. Existen dos actores:
 Cliente. Es el que obtiene el café de la máquina. Realiza las acciones siguientes:
 Entrega el dinero.
 Escoge el producto.
 Escoge el azúcar.
 Máquina. Es el actor que realiza las funciones que ponen a disposición del cliente el café. La
máquina realiza las siguientes acciones:
 Prepara el producto.
 Entrega el producto
 Devuelve el cambio
 Imprime el recibo.

Relaciones
Relaciones de inclusión:
El caso de uso "Entrega de producto" incluye la preparación del mismo ya que si no no se podría
entregar. Así "Entrega producto" incluye "Prepara producto".

22
El caso de uso "Prepara producto" incluye "escoge producto" y "Escoge azúcar" ya que no se podría
realizar la primera sin estas.

Relaciones de extensión.
El caso de uso "Devuelve cambio" e "Imprime recibo" extienden "Entrega producto" ya que se realizan
una vez hecho este.

Relaciones de comunicación.
Los casos de uso "Entrega dinero" "Escoge producto" y "Escoge azúcar" son realizados por cliente y por
tanto se comunican con él. De la misma forma "Prepara producto" y "Entrega producto" se comunican
con la máquina.

Tipos de relaciones
Existen los siguientes tipos de relaciones entre los casos de uso:

Relación Función Notación

Asociación Indica la relación entre el actor o caso de uso base con otro caso de
uso. Puede indicarse restricción de cardinalidad.

Extensión El caso de uso principal extiende su funcionalidad mediante otro caso

de uso final bajo unas condiciones específicas. Se usan entre casos de
uso similares

Generalización Indica una relación entre un caso de uso general y un caso de uso
específico. Dicha relación puede ser de herencia(<<extends>>) o de
uso(<<uses>>. Son relaciones taxonómicas.

Entra actores indica que uno es más general y el otro más

especializado. Pudiendo comunicarse el más especializado con los
mismos casos de uso que el más general.

Inclusión El caso de uso inicial incluye al caso de uso final. Siempre que se
realice el caso de uso inicial se realizará también el caso de uso final.

Importancia de los diagramas de casos de uso

Los diagramas de casos de uso son importantes para:

23
  Visualizar, especificar, y documentar el comportamiento de un elemento. Ellos hacen sistemas,
subsistemas, y clases entendibles para presentar una vista exterior de cómo estos elementos
pueden ser usados dentro del contexto.
 Probar sistemas ejecutables a través de ingeniería hacia adelante y para comprender sistemas
ejecutables a través de ingeniería inversa.

Contenido de los diagramas de casos de uso

Los diagramas de casos de uso comúnmente contienen:
 Casos de uso
 Actores
 Dependencias, generalización, y relaciones de asociación.
Igual que todos los diagramas, los casos de uso pueden contener notas y restricciones.

Construcción de los diagramas de casos de Uso

Para construir el Modelo de Casos de Uso en la fase de Planificación y especificación de Requisitos se
siguen los siguientes pasos:
1. Después de listar las funciones del sistema, se definen los límites del sistema y se identifican los
actores y los casos de uso.
2. Se escriben todos los casos de uso en el formato de alto nivel. Se categorizan como primarios,
secundarios u opcionales.
3. Se dibuja el Diagrama de Casos de Uso.
4. Se detallan relaciones entre casos de uso, en caso de ser necesarias, y se ilustran tales relaciones
en el Diagrama de Casos de Uso.
5. Los casos de uso más críticos, importantes y que conllevan un mayor riesgo, se describen en el
formato expandido esencial. Se deja la definición en formato expandido esencial del resto de
casos de uso para cuando sean tratados en posteriores ciclos de desarrollo, para no tratar toda la
complejidad del problema de una sola vez.
6. Se crean casos de uso reales sólo cuando:
o Descripciones más detalladas ayudan significativamente a incrementar la comprensión
del problema.
o El cliente pide que los procesos se describan de esta forma.
7. Ordenar según prioridad los casos de uso (este paso se va a ver a continuación).

24
Construcción del diagrama de casos de uso
Estructurado en tres niveles:
 Diagrama de contexto y diagrama inicial
 Plantillas de descripción
 Diagrama estructurado o Modelo de Casos de Uso

Diagrama de contexto: Nos sirve para identificar cual es el entorno del sistema, es decir los límites del
sistema software que vamos a desarrollar al cual lo damos un nombre en este caso por ejemplo empezar
de “pedidos” una vez identificado el sistema software a desarrollar podemos identificar cuáles son los
actores externos que van a interactuar con ese sistema, estos actores van hacer entidades humanos u otros
dispositivos o otros módulos de desarrollo software que quedan fuera de lo que es el sistema en el que
estamos involucrados en especificar que es la empresa de pedidos en este caso tenemos dos actores
empleado y administrador.

Diagrama inicial: refina el modelo anterior indicando los principales casos de uso o funcionalidades del
sistema. Por ejemplo para el actor empleado identifican como caso de uso: introducir pedido, cancelar
pedido, tener estado del pedido, etc. y para el actor administrador se utilizan se especifica los casos de
uso nuevo producto u borrar producto.

Introducir Empresa de pedidos

pedido

Cancelar
pedido

25
 Obtener Nuevo
pedido producto

Borrar pedido

Borrar
Buscar
producto
pedido

Empleado Administrador

Alto cliente

Buscar
clientes

Diagrama estructurado o Modelo de Casos de Uso

Una vez obtenido el diagrama de contexto y el diagrama inicial podemos refinar aún más el diagrama
con las relaciones con lo que hemos explicado y obtenemos así el modelo de caso de uso
modelo de diagrama estructurado completo.

Alto Buscar
cliente cliente

Introducir
pedido

Obtener Pago en Pago con

estado cuenta
tarjeta
pedido

Cancelar Buscar
Empleado pedido pedido

26
Técnicas de Modelado
• Modelado del Contexto: Identificar los actores
– Requieren ayuda del sistema para llevar a cabo sus tareas
– Necesarios para ejecutar las funciones del sistema
– Interactúan con el HW externo u otros sistemas SW.
– Funciones secundarias de administración y mantenimiento.
• Organizarlos en jerarquías de especialización/generaliz.
• Especificar las vías de comunicación de cada actor con los casos de uso.
• Modelado de requisitos:
– Establecer el contexto.
– Considerar el comportamiento que cada actor espera del sistema o necesita que le brinde.
Nombrarlos como Casos Uso
– Factorizar el comportamiento.

Ejemplos de diagramas de uso

27
Conclusiones:
 Los casos de uso son descripciones de los pasos o las actividades que deberán realizarse para
llevar a cabo algún proceso.
 El propósito caso de uso es comunicar las funciones y el comportamiento del sistema al cliente
o al usuario final.
 El caso de uso es una excelente herramienta para estimular a que los usuarios potenciales hablen,
de un sistema, desde su propio punto de vista.
 El diagrama de casos de uso nos permite especificar las principales funcionalidades que el
sistema ofrece a los actores
 UML proporciona una anotación para representar dicho diagrama.
 Caso de Uso y Actores
 Relaciones entre caso de usos: Inclusión, Extensión, Herencia.
 Relaciones entre actores: Herencia.
 Cada caso de uso se especifica en una plantilla de descripción textual.
 En un Diagrama de Casos de Uso se visualizan los actores, los casos de uso y las relaciones entre
ellos, pudiéndose colocar la cardinalidad.

28
 En un Diagrama de Casos de Uso se muestran las relaciones entre Casos de Uso; éstas son de
tres tipos: inclusión, generalización y extensión.

29