Este documento describe los diagramas de casos de uso en UML. Define actores como entidades externas que interactúan con el sistema, y casos de uso como grupos de actividades del sistema que producen un resultado tangible desde la perspectiva del actor. Detalla los tipos de relaciones entre casos de uso como inclusión, extensión y generalización. Explica que los diagramas de casos de uso muestran gráficamente casos de uso, actores y sus relaciones para proporcionar una vista general del comportamiento del sistema.

1. “AÑO DE LA CONSOLIDACIÓN DEL MAR DE GRAU”.
Ingeniería De Software
Densy De La Cruz Lucero
Yulina Arrieta Flores
Diagramas De Caso De Uso
Computación e Informática
Marco Aurelio Porro Chulli

2. “AÑO DE LA CONSOLIDACIÓN DEL MAR DE GRAU”.
V
Noche
2016
En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una
forma de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado
Unificado(UML), define una notación gráfica para representar casos de uso
llamada modelo de casos de uso. UML no define estándares para que el formato
escrito describa los casos de uso, y así mucha gente no entiende que esta
notación gráfica define la naturaleza de un caso de uso; sin embargo una notación
gráfica puede solo dar una vista general simple de un caso de uso o un conjunto
de casos de uso. Los diagramas de casos de uso son a menudo confundidos
con los casos de uso. Mientras los dos conceptos están relacionados, los casos de
uso son mucho más detallados que los diagramas de casos de uso. En los
conceptos se debe detallar más de un caso de uso para poder identificar qué es lo
que hace un caso de uso.
 La descripción escrita del comportamiento del sistema al afrontar una tarea de
negocio o un requisito de negocio. Esta descripción se enfoca en el valor
suministrado por el sistema a entidades externas tales como usuarios
humanos u otros sistemas.
 La posición o contexto del caso de uso entre otros casos de uso. Dado que es
un mecanismo de organización, un conjunto de casos de uso coherente y
consistente promueven una imagen fácil de comprender del comportamiento
del sistema, un entendimiento común entre el cliente/propietario/usuario y el
equipo de desarrollo.

3. “AÑO DE LA CONSOLIDACIÓN DEL MAR DE GRAU”.
En esta práctica es común crear especificaciones suplementarias para capturar
detalles de requisitos que caen fuera del ámbito de las descripciones de los casos
de uso. Ejemplos de esos temas incluyen restricciones de diseño como:
rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.
Actor: Un actor es una entidad externa (de fuera del sistema) que
interacciona con el sistema participando (y normalmente iniciando) en un
caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios
del sistema), otros ordenadores o eventos externos.
Los actores no representan a personas físicas o a sistemas, sino su rol.
Esto significa que cuando una persona interactúa con el sistema de
diferentes maneras (asumiendo diferentes papeles), estará representado
por varios actores. Por ejemplo, una persona que proporciona servicios
de atención telefónica a clientes y realiza pedidos para los clientes
estaría representada por un actor «equipo de soporte» y por otro actor
«representante de ventas».
Caso de uso:
Un caso de uso describe, desde el punto de vista de los actores, un
grupo de actividades de un sistema que produce un resultado concreto y
tangible.
Los casos de uso son descriptores de las interacciones típicas entre los
usuarios de un sistema y ese mismo sistema. Representan el interfaz

4. “AÑO DE LA CONSOLIDACIÓN DEL MAR DE GRAU”.
externo del sistema y especifican qué requisitos de funcionamiento debe
tener este (recuerde, únicamente el qué, nunca el cómo).
Cuando se trabaja con casos de uso, es importante tener presentes
algunas sencillas reglas:
 Cada caso de uso está relacionado como mínimo con un actor
 Cada caso de uso es un iniciador (es decir, un actor)
 Cada caso de uso lleva a un resultado relevante (un resultado con
«valor intrínseco»)
Los casos de uso pueden tener relaciones con otros casos de uso. Los
tres tipos de relaciones más comunes entre casos de uso son:
 <<include>> que especifica una situación en la que un caso de uso
tiene lugar dentro de otro caso de uso
 <<extends>> que especifica que en ciertas situaciones, o en algún
punto (llamado punto de extensión) un caso de uso será extendido
por otro.
 Generalización que especifica que un caso de uso hereda las
características del «super» caso de uso, y puede volver a
especificar algunas o todas ellas de una forma muy similar a las
herencias entre clases.
Relaciones:
Conjunto de secuencias de
acciones, cada secuencia
representa un posible
comportamiento del sistema.
Variantes, son versiones
especializadas, un caso de uso
que extiende a otro o un caso de
uso que incluye a otro.
Como veremos a continuación,
en los diagramas de casos de
uso se muestran: casos de uso
(representados en forma de

5. “AÑO DE LA CONSOLIDACIÓN DEL MAR DE GRAU”.
elipses), actores (en forma de personajes) y relaciones (en forma de líneas y/o
flechas). UML define cuatro tipos de relaciones en los diagramas de casos de
uso:
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:
Inclusión: Un caso de uso base incorpora explícitamente el comportamiento de
otro en algún lugar de su secuencia. 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 reemplazó al denominado
<<uses>>.
Veamos un ejemplo de inclusión entre casos de uso:

6. “AÑO DE LA CONSOLIDACIÓN DEL MAR DE GRAU”.
Extensión: Un caso de uso base incorpora implícitamente el comportamiento de
otro caso de uso en el lugar especificado indirectamente por este otro caso de
uso. En el caso de uso base, la extensión se hace en una serie de puntos
concretos y previstos en el momento del diseño, llamados puntos de extensión,
los cuáles no son parte del flujo principal. 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 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>>.
Veamos un ejemplo de extensión:

7. “AÑO DE LA CONSOLIDACIÓN DEL MAR DE GRAU”.
En este ejemplo usamos la relación de extensión entre los casos de uso Abrir
acción de mejora yResolver consulta. En este caso tendremos el punto de
extensión “resolución retrasada” (en el caso de uso Resolver consulta) debido a
que cuando haya pasado un tiempo estipulado por la organización (por ejemplo 3
días laborales) se abrirá una acción de mejora para dejar constancia del retraso y
realizar posteriormente las acciones pertinentes, de ahí que digamos que el caso
de uso Abrir acción de mejora es una subfunción de uso que puede extender al
caso de uso Resolver consulta.
Especialización y generalización de los casos de uso: 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.
Veamos un ejemplo de generalización:

8. “AÑO DE LA CONSOLIDACIÓN DEL MAR DE GRAU”.
Como podemos ver en este último ejemplo también pueden existir vínculos de
generalización o herencia entre actores. Los actores especializados (Abogado y
Psicólogo) heredan los casos de uso del actor general (Profesional). La punta de
flecha apunta al actor más general. Hay que reseñar que los actores
especializados pueden tener otros casos de uso propios que no estarán
disponibles para los demás actores. Este tipo de herencia entre actores si que se
usa frecuentemente puesto que nos simplifica considerablemente el diagrama, nos
ahorra un número importante de relaciones de comunicación entre actores y casos
de uso y nos sirve para esclarecer visualmente la jerarquía entre actores del
sistema.
Resumen
DEFINICION:
En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una
forma de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado
Unificado(UML), define una notación gráfica para representar casos de uso
llamada modelo de casos de uso. UML no define estándares para que el formato
escrito describa los casos de uso, y así mucha gente no entiende que esta
notación gráfica define la naturaleza de un caso de uso; sin embargo una notación
gráfica puede solo dar una vista general simple de un caso de uso o un conjunto
de casos de uso.
ELEMENTOS:
Actor:
Un actor es una entidad externa (de fuera del sistema) que interacciona con el
sistema participando (y normalmente iniciando) en un caso de uso. Los actores
pueden ser gente real (por ejemplo, usuarios del sistema), otros ordenadores o
eventos externos.

9. “AÑO DE LA CONSOLIDACIÓN DEL MAR DE GRAU”.
Caso de uso:
Un caso de uso describe, desde el punto de vista de los actores, un grupo de
actividades de un sistema que produce un resultado concreto y tangible.
Cuando se trabaja con casos de uso, es importante tener presentes algunas
sencillas reglas:
 Cada caso de uso está relacionado como mínimo con un actor
 Cada caso de uso es un iniciador (es decir, un actor)
 Cada caso de uso lleva a un resultado relevante (un resultado con «valor
intrínseco»)
Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos
de relaciones más comunes entre casos de uso son:
 <<include>> que especifica una situación en la que un caso de uso tiene
lugar dentro de otro caso de uso
<<extends>> que especifica que en ciertas situaciones, o en algún punto (llamado
punto de extensión) un caso de uso será extendido por otro.
Generalización que especifica que un caso de uso hereda las características del
«super» caso de uso, y puede volver a especificar algunas o todas ellas de una
forma muy similar a las herencias entre clases.
Relaciones:
Conjunto de secuencias de acciones, cada secuencia representa un posible
comportamiento del sistema.
Variantes, son versiones especializadas, un caso de uso que extiende a otro o un
caso de uso que incluye a otro.
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.
Inclusión: Un caso de uso base incorpora explícitamente el comportamiento de
otro en algún lugar de su secuencia. 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

10. “AÑO DE LA CONSOLIDACIÓN DEL MAR DE GRAU”.
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>>.
Extensión: Un caso de uso base incorpora implícitamente el comportamiento de
otro caso de uso en el lugar especificado indirectamente por este otro caso de uso.
En el caso de uso base, la extensión se hace en una serie de puntos concretos y
previstos en el momento del diseño, llamados puntos de extensión, los cuáles no
son parte del flujo principal. 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 determinado.
Especialización y generalización de los casos de uso: 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.
RECOMENDACIONES
Cada elemento de diagramas de casos de uso tiene una función diferente. Lo
recomendable es aplicarla de acuerdo a lo que uno necesite para que así tenga un
buen funcionamiento.
CONCLUCIONES
En conclusión podemos decir que existen diferentes diagramas de casos de uso
del cual aprendemos mucho.
APRECIACIOPN DEL EQUIPO
En, este trabajo nosotros como equipo hemos descubierto todo con respecto a
diagramas de casos de uso y sus elementos que lo componen. Es muy interesante
la manera en como se ha ido actualizando en cuanto a la tecnología.
LINKOGRAFIA:

11. “AÑO DE LA CONSOLIDACIÓN DEL MAR DE GRAU”.
https://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso
https://docs.kde.org/stable4/es/kdesdk/umbrello/uml-elements.html
http://www.seas.es/blog/informatica/tipos-de-relaciones-en-diagramas-de-casos-
de-uso-uml/