Ingeniería de Requisitos

UNIDAD 1
INGENIERÍA DE SOFTWARE E INGENIERÍA DE REQUISITOS
Sesión 6

Ciro Rodriguez
crodriguezro@unmsm.edu.pe
2020
CARACTERÍSTICAS
UML es un lenguaje de modelado para visualizar, especificar, construir y
documentar partes de un sistema software desde distintos puntos de vista
• Puede usarse con cualquier proceso de desarrollo, a lo largo de todo el ciclo de
vida y puede aplicarse a todos los dominios de aplicación y plataformas de
implementación
• También puede usarse en tres áreas, como la ingeniería de negocio y modelado
de procesos gracias a los mecanismos de adaptación/extensión mediante perfiles
Lo que no es
• UML no es una notación propietaria
• UML no es un método, ni un proceso ni una metodología
El objetivo de UML es la unificación de los métodos de modelado de objetos
(Booch, OMT y OOSE) por medio de la:
• Identificación y definición de la semántica de los conceptos fundamentales y
elección de una representación gráfica con una sintaxis simple, expresiva e
intuitiva
La especificación UML se define usando el enfoque de un metamodelo
DIAGRAMAS Y VISTAS
UML define varios modelos para la representación de los sistemas que
pueden verse y manipularse mediante un conjunto de diagramas diferentes:
• Diagramas de estructura
• Diagrama de clases
• Diagrama de estructuras compuestas
• Diagrama de componentes
• Diagrama de despliegue
• Diagrama de objetos
• Diagrama de paquetes
• Diagramas de comportamiento
• Diagrama de casos de uso
• Diagrama de actividad
• Diagramas de interacción
• Diagrama de secuencia
• Diagrama de comunicación o colaboración
• Diagrama de visión global de la interacción
• Diagrama de tiempo
• Diagrama de maquina de estados
DIAGRAMAS Y VISTAS
Una vista es un subconjunto de las construcciones de modelado de UML que
representa un aspecto del sistema
Los diagramas UML se pueden organizar en las siguientes vistas [Rumbaugh et
al., 2007]
• Vista de diseño
• Vista estática
• Diagramas de estructuras
• Diagramas de clases
• compuestas
• Vista de casos de uso
• Diagramas de colaboración
• Diagramas de casos de uso
• Diagramas de componentes
• Vista de interacción
• Vista de despliegue
• Diagramas de secuencia
• Diagramas de despliegue
• Diagramas de comunicación
• Vista de actividad • Vista de gestión del Modelo
• Diagramas de actividad • Diagramas de paquetes
• Vista de la máquina de estados • Perfiles
• Diagramas de máquina de estados • Diagramas de paquetes
DIAGRAMAS Y VISTAS
Las vistas se pueden agrupar en áreas conceptuales

Área Vista
Vista estática
Estructural Vista de diseño
Vista de casos de uso
Vista de máquina de estados
Dinámica Vista de actividad
Vista de interacción
Física Vista de despliegue
Vista de gestión del modelo
Gestión
Perfiles
Vista de casos de uso
INTRODUCCIÓN
• La vista de casos de uso captura la funcionalidad de un
sistema, de un subsistema, o de una clase, tal como se
muestra a un usuario exterior
• Reparte la funcionalidad del sistema en transacciones
significativas para los usuarios ideales de un sistema
• Los usuarios del sistema se denominan actores y las particiones
funcionales se conocen con el nombre de casos de uso
• La técnica que se utiliza para modelar esta vista es el
diagrama de casos de uso
CARACTERÍSTICAS
Los casos de uso son una técnica para la especificación de
requisitos funcionales propuesta inicialmente por Ivar Jacobson
[Jacobson, 1987], [Jacobson et al. 1992] e incorporada a UML
Modela la funcionalidad del sistema tal como la perciben los agentes
externos, denominados actores, que interactúan con el sistema
desde un punto de vista particular
Sus componentes principales son:
• Sujeto: sistema que se modela
• Casos de uso: unidades funcionales completas
• Actores: entidades externas que interactúan con el sistema
El sujeto se muestra como una caja negra que proporciona los casos
de uso
El modelo de casos de uso se representa mediante los diagramas
de casos de uso
CARACTERÍSTICAS
Sujeto

Casos de uso
Biblioteca Multimedia

Hacer
Recomendaciones

Prestatario/a
Reservar

Gestionar Gestor/a Inventario

Inventario

Actores
Diagrama de
casos de uso
ACTORES
Un actor es un clasificador que modela un tipo de rol que juega una
entidad que interacciona con el sujeto pero que es externa a él
• Un actor puede tener múltiples instancias físicas
• Una instancia física de un actor puede jugar diferentes papeles
Los actores se comunican con el sujeto intercambiando mensajes
(señales, llamadas o datos)
Notación:
• Se representan con el icono estándar de “stick man” o “monigote” con el
nombre del actor (obligatorio) cerca del símbolo, normalmente se pone
encima o debajo
• También se puede representar mediante un símbolo de clasificador con
el estereotipo «actor»
• Los nombres de los actores suelen empezar por mayúscula
• Se pueden usar otros símbolos para representar tipos de actores, por
ejemplo para representar actores no humanos
ACTORES
Tipos de actores [Larman, 2002]
Principales
• Tiene objetivos de usuario que se satisfacen mediante el uso de los servicios
del sistema
• Se identifican para encontrar los objetivos de usuario, los cuales dirigen los
casos de uso
De apoyo
• Proporcionan un servicio al sistema
• Normalmente se trata de un sistema informático, pero podría ser una
organización o una persona
• Se identifican para clarificar las interfaces externas y los protocolos
Pasivos
• Está interesado en el comportamiento del caso de uso, pero no es principal ni
de apoyo
• Se identifican para asegurar que todos los intereses necesarios se han
identificado y satisfecho
• Los intereses de los actores pasivos algunas veces son sutiles o es fácil no
tenerlos en cuenta, a menos que estos actores sean identificados
explícitamente
ACTORES

«actor» Clasificador
Stick man
Cliente
Cliente

Actor humano Sistema Temporizador Dispositivo

Símbolos utilizados para representar tipos de actores

15
Ingeniería de Software I - Fundamentos de la vista de casos de uso
ABC
RELACIONES ENTRE
ACTORES
Los actores sólo pueden tener asociaciones con casos de uso,
subsistemas, componentes y clases y dichas asociaciones deben
ser binarias
Se pueden establecer relaciones de generalización entre actores
• El actor general describirá el comportamiento de un rol más
general
• Los actores especializados heredan el comportamiento del actor
general y lo extienden de alguna forma
• Una instancia de un actor descendiente siempre se puede
utilizar en aquellos casos en los que se espera una instancia del
actor antecesor
• Los actores pueden ser abstractos, en ese caso se representan
con el nombre en cursiva
RELACIONES ENTRE
ACTORES

Usuario
Reservar

Prestatario/a Gestor/a de Administrador/a

inventario

Asociación entre un actor y un caso de uso Relaciones de generalización entre actores

CASOS DE USO
Un caso de uso se define como un conjunto de acciones realizadas por el
sistema que dan lugar a un resultado observable
El caso de uso especifica un comportamiento que el sujeto puede realizar en
colaboración con uno o más actores, pero sin hacer referencia a su
estructura interna
El caso de uso puede contener posibles variaciones de su comportamiento
básico incluyendo manejo de errores y excepciones
Una instanciación de un caso de uso es un escenario que representa un uso
particular del sistema (un camino)
Características de los casos de uso:
• Un caso de uso se inicia por un actor
• Los casos de uso proporcionan valores a los actores
• La funcionalidad de un caso de uso debe ser completa
El comportamiento de un caso de uso se puede describir mediante
interacciones, actividades, máquinas de estado ...
CASOS DE USO
Notación:
• Elipse con el nombre del caso de uso dentro o debajo de ella. Se
puede colocar algún estereotipo encima del nombre y una lista de
propiedades debajo
• La representación alternativa es la del símbolo del clasificador con
una elipse pequeña en la esquina superior derecha

Recibir Pedido Recibir Pedido

Notaciones usadas para la representación de casos de uso

RELACIONES DE LOS CASOS
DE USO
Los casos de uso pueden tener asociaciones y dependencias con
otros clasificadores
Relación entre actores y casos de uso:
• Asociación
Relaciones entre casos de uso
• Generalización: Un caso de uso también se puede especializar en uno
o más casos de uso hijos
• Inclusión: Un caso de uso puede incorporar el comportamiento de otros
casos de uso como fragmentos de su propio comportamiento
• Extensión: Un caso de uso también se puede definir como una
extensión incremental de un caso de uso base
Relación entre un caso de uso y una colaboración
• Realización
RELACIONES DE LOS CASOS
DE USO
Relación Descripción Notación
Línea de comunicación entre un actor y
Asociación un caso de uso en el que participa
Una relación entre un caso de uso
general y un caso de uso más
Generalización específico, que hereda y añade
propiedades al caso de uso base
Inserción de comportamiento adicional «include»
Inclusión en un caso de uso base, que describe
explícitamente la inserción
Inserción de comportamiento adicional «extend»
Extensión en un caso de uso base que no tiene
conocimiento sobre él
Establece una relación entre el caso de
Realización uso y los diagramas que describen la
funcionalidad del caso de uso
RELACIONES DE LOS CASOS
DE USO
Generalización de casos de uso
• Una relación de generalización relaciona un caso de uso especializado con
otro caso de uso más general
• El hijo hereda las relaciones y comportamiento del padre y puede agregar
atributos y operaciones propios
• El caso de uso hijo añade comportamiento al caso de uso padre insertando
secuencias de acción adicionales en la secuencia del padre en puntos
arbitrarios
• También puede modificar algunas operaciones y secuencias heredadas,
pero debe hacerse de forma que la intención del padre se mantenga
• El caso de uso padre puede ser abstracto
Generar
Salida Formateada
Administrador/a

Generar Informe Generar

Datos a Exportar
RELACIONES DE LOS CASOS
DE USO
Relación de extensión (I)
• Dependencia entre dos casos de uso que especifica que el
comportamiento de un caso de uso base (extendido) puede ser
extendido con comportamiento adicional definido en otro caso de
uso (extensor)
• El caso de uso extendido define un comportamiento que tiene
significado con independencia del caso de uso extensor
• El comportamiento del caso de uso extensor incrementa el del caso
de uso base sólo en determinadas condiciones
• Un caso de uso extensor puede extender varios casos de uso base
y puede, a su vez, ser extendido por otro caso de uso
• La extensión tiene lugar en puntos de extensión
• pertenecen al caso de uso extendido
• Indican el lugar donde se insertan los fragmentos de
comportamiento del caso de uso extensor
RELACIONES DE LOS CASOS
DE USO
Relación de extensión (II)
• Notación de la relación de extensión: símbolo de dependencia con el
estereotipo «extend» y opcionalmente una nota con las condiciones
y las referencias a los puntos de extensión
• Notación de los puntos de extensión: se representan como una
cadena de texto dentro del caso de uso conforme a la sintaxis:
< nombre > [: <explicación> ]
RELACIONES DE LOS CASOS
DE USO
Procesar Factura
Relación de extensión (III)
• Si hay varios puntos de extensión en un caso de uso es Extension Points
mejor representar el caso de uso con el símbolo del Factura inválida
clasificador Factura devuelta
Factura pagada por otro
• Condición de la extensión Factura con demora

• Es única para todos los puntos de extensión de una relación de extensión

• Si es verdadera cuando se alcanza el primer punto de extensión al
ejecutar el caso de uso base, serán ejecutados todos los fragmentos del
caso de uso extensor correspondientes a todos los puntos de extensión.
Terminada la ejecución de un fragmento dado el control retorna al caso de
uso base y continua su ejecución hasta el siguiente punto de extensión
• Si la condición es falsa no se produce la extensión
• Si no hay condición la extensión es incondicional
RELACIONES DE LOS CASOS
DE USO
Relación de inclusión (I)
• Relación entre dos casos de uso que indica que el comportamiento de
un caso de uso (incluido) se inserta en el comportamiento de otro caso
de uso (base o inclusor) en la localización especificada en este último
• La inclusión no es condicional
• El propósito de la inclusión es la reutilización de porciones de
comportamiento comunes a varios casos de uso
• Un caso de uso incluido puede insertarse en varios casos de uso base y
puede, a su vez, incluir otros casos de uso
• Un caso de uso base puede tener relaciones de inclusión con varios
casos de uso incluidos
• La ejecución es análoga a las llamadas a procedimientos
• Notación de la relación de inclusión: símbolo de dependencia con el
estereotipo «include»
RELACIONES DE LOS CASOS
DE USO
Relación de inclusión (II)
ORGANIZACIÓN DE LOS
CASOS DE USO
Los casos de uso se pueden agrupar en paquetes
• Los paquetes se pueden organizar jerárquicamente
• Un caso de uso puede estar en más de un paquete
• Pueden existir relaciones entre casos de uso de diferentes paquetes
• Se pueden agrupar actores en un paquete
Los clasificadores pueden poseer casos de uso
• Forma de organización alternativa permitida en UML 2
• El conjunto completo de casos de uso de un clasificador especifica
todas las distintas formas que hay de utilizar ese clasificador
ORGANIZACIÓN DE LOS
CASOS DE USO

Diagrama de casos de uso del paquete Biblioteca

ORGANIZACIÓN DE LOS
CASOS DE USO
Paquete CasosDeUsoTransaccion condition: {cliente
Seleciona HELP} Oficina de ayuda financier a
extension point: Seleccion

Identificación Realizar Proporcionar

Transacción Ayuda ayuda
Tarjeta «extend» financiera

«include»
Paquete Distribuir
fondos
«include»

Retirar Depositar
Fondos Transferir Fondos Procesar
Fondos información
financiera

Paquete Administración
Casos de uso contenidos en
un clasificador
Registrar
Leer Log ATM

Relaciones entre casos de uso de diferentes paquetes

ORGANIZACIÓN DE LOS
CASOS DE USO

Paquetes de casos de uso en diferentes niveles de abstracción

ORGANIZACIÓN DE LOS
CASOS DE USO

Diagrama de casos de uso del paquete Préstamo

REALIZACIÓN DE LOS CASOS
DE USO
Las responsabilidades de realización de las acciones descritas en
los casos de uso se asignan a objetos que colaboran e implementan
la funcionalidad del caso de uso
Principios para la realización de los casos de uso (I)
• Una colaboración realiza un caso de uso: solución dependiente
de la implementación
• Contexto de la colaboración: relaciones entre clases y objetos
• Interacción de la colaboración: interacciones entre ellos para
alcanzar la funcionalidad deseada
El símbolo de la colaboración es una elipse con la línea discontinua y
con el nombre en su interior
Para explicar una colaboración se requieren diagramas que
muestren el contexto y la interacción entre los elementos que
colaboran: diagramas de comunicación, de secuencia, de visión
global de la interacción, de actividad y de máquina de estados
REALIZACIÓN DE LOS CASOS
DE USO
Principios para la realización de los casos de uso (II)
• Un escenario es una instancia de un caso de uso
• Un escenario es un camino de ejecución específico que representa
una instanciación específica de un caso de uso
• Un escenario visto como una ocurrencia de una colaboración incluye
la interacción entre las partes dentro del sistema
• Un caso de uso puede poseer diagramas que detallen su estructura
interna: pueden enfatizar su estructura de tiempo de ejecución u
otros elementos que surgen en la implementación del caso de uso
(por ejemplo un diagrama de máquina de estados)
Venta

Comprador/a Vendedor/a

34
REALIZACIÓN DE LOS CASOS
DE USO
Caso de uso Búsqueda recursos biblioteca

Máquina de estados Sesión de búsqueda

Caso de uso con diagramas que detallan su estructura interna

Casos de Uso
(¿Qué es un caso de uso?)

¿Caso de Uso?

3
4
Casos de Uso
(¿Qué es un caso de uso?)

Un caso de uso es un conjunto de escenarios que

tienen una meta de usuario en común
Martin Fowler

Caso de Uso: Es una descripción de un proceso fin-

a-fin, relativamente largo, que incluye varias etapas
o transacciones

Es una manera específica de utilizar el sistema, es

una historia que describe un uso particular del
sistema
Es la imagen de una funcionalidad del sistema,
desencadenada en respuesta al estímulo de un
actor o rol externo 3
Casos de Uso
(¿Qué es un caso de uso?)

¿Escenario?

3
6
Casos de Uso
(¿Qué es unescenario?)

¿Escenario?

Escenario: Es una secuencia de acciones e

interacciones (pasos) entre los usuarios (actores) y
el sistema
...por ejemplo:

“El usuario introduce su nombre de usuario y su contraseña.

El sistema verifica la validez del nombre de usuario y de la
contraseña y permite al usuario el acceso al sistema. El
sistema muestra la pantalla principal del sistema. El usuario
selecciona la opción de añadir nuevo empleado. El sistema
muestra...”
3
7
Casos de Uso
(¿Qué es unactor?)

¿Actor, Rol?

Un actor representa el rol jugado por una persona o

cosa que actúa con el sistema.

“Cliente, Administrador, Usuario no Registrado (Autenticado),

Usuario Registrado (Autenticado), Jefe de Compras, Jefe de
Personal, Moderador, Jefe de Departamento, Obrero de
Planta, Supervisor...”

¿Actor o Rol?: Sería mejor usar la palabra rol, pero

algunos piensan que “Actor” fue usado debido a una
mala traducción del Sueco
3
8
Casos de Uso
(¿Qué es un caso de uso?)

NOTA: NO TODOS los

interesados en el
sistema (stakeholders)
son actores, sólo son
actores aquellos que
utilizarán el sistema
3
9
Casos de Uso
(Algunas Características)

Actualmente, mucha gente considera que los casos

de uso son de vital importancia en los proyectos de
software (Procesos Guiados por Casos de Uso)

Describen bajo la forma de acciones y reacciones

el comportamiento de un sistema desde el punto de
vista de un usuario

Se puede considerar que hasta cierto punto, cada

caso de uso es independiente de los demás

Permiten definir los límites del sistema y las

relaciones entre el sistema y su entorno
(MUY IMPORTANTE)
4
0
Casos de Uso
(Algunas Características)

Un caso de uso NO es un diagrama, NO es un

símbolo dentro de un diagrama...
...es una forma de describir un escenario de
interacción usuario sistema...
...los diagramas vienen después (o antes) y son una
forma de tener una visión general de los casos de
uso, sus relaciones con los actores y con otros casos
de uso
4
1
Descripción Textual de los Actores del Sistema
(Requerimientos: ¿Quiénes interactúan con el sistema?)

Nombre: <nombre del actor>

Descripción:
<descripción del actor>

Nombre: Usuario no Autenticado

Descripción:

Representa a un usuario que no se a identificado frente

al sistema. Generalmente estos usuarios deberían
poder registrarse (crear un nuevo usuario) o ingresar al
sistema para transformarse en usuarios autenticados,
en moderadores o en administradores del sistema
... 10
Descripción Textual de un Caso de Uso
(Requerimientos: ¿Qué debe hacer el sistema?)
Nombre: <nombre del caso de uso>
Autor: <nombre del autor (o autores) del caso de uso>
Fecha: <fecha de creación del caso de uso>
Descripción:
<breve descripción del caso de uso>

Actores:
<actores participantes en el caso de uso>
Precondiciones:
<condiciones que deben cumplirse para poder ejecutar el caso de uso>
Flujo Normal:
<flujo normal (feliz) de ejecución del caso de uso>
Flujo Alternativo:
<flujos alternativos de ejecución del caso de uso>
Poscondiciones:
<condiciones que deben cumplirse al finalizar la ejecución del caso de uso>
11
Planillas de Casos de Uso (Generales)
Descripción Textual de un Caso de Uso
(Requerimientos: ¿Qué debe hacer el sistema?)

Nombre: Crear mensaje foro

Autor: Pedro Pérez
Fecha: 21/04/09
Descripción:
Permite crear un nuevo mensaje (hilo) en el foro de discusión.
Actores:
Usuario / Moderador
Precondiciones:
El usuario debe de estar autenticado en el sistema.

continúa...
44
Descripción Textual de un Caso de Uso
(Requerimientos: ¿Qué debe hacer el sistema?)
...continuación
Flujo Normal:
1.- El actor pulsa sobre el botón para crear un nuevo mensaje.
2.- El sistema muestra una caja de texto para introducir el título del
mensaje y una zona de mayor tamaño para introducir el cuerpo del
mensaje.
3.- El actor introduce el título del mensaje y el cuerpo del mismo.
4.- El sistema comprueba la validez de los datos y los almacena.
5.- El moderador recibe una notificación de que hay un nuevo mensaje.
6.- El moderador acepta y el sistema publica el mensaje si éste fue
aceptado por el moderador.
Flujo Alternativo:
4.A.- El sistema comprueba la validez de los datos, si los datos no son
correctos, se avisa al actor de ello permitiéndole que los corrija.

7.B.- El moderador rechaza el mensaje, de modo que no es publicado sino

devuelto al usuario.
Poscondiciones:
El mensaje ha sido almacenado en el sistema y fue publicado.
45
Descripción Textual de un Caso de Uso
(Requerimientos: ¿Qué debe hacer el sistema?)

En general, hay muchas variaciones sobre como se

puede describir un caso de uso

UML no define ningún estándar al respecto

Seleccione o diseñe una o más plantillas que

considere adecuadas para sus necesidades

Conozca bien la plantilla que va a utilizar, sepa para

que sirve cada campo (argumente sobre su utilidad y
sea coherente a lo largo de todas las plantillas)
46
Descripción Textual de un Caso de Uso
(Requerimientos: ¿Qué debe hacer el sistema?)

Por ejemplo, en la plantilla anterior sería bueno

añadir un campo prioridad...

Nombre: Crear mensaje foro

Autor: Pedro Pérez
Fecha: 21/04/09
Prioridad: 5
Descripción:
Permite crear un nuevo mensaje (hilo) en el foro de discusión.
Actores:
Usuario / Moderador
Precondiciones:
El usuario debe de estar autenticado en el sistema.
47
Modelo de Casos deUso

¿Cómo se
desarrolla un
modelo de
Casos de Uso?

48
Diagrama de Casos de Usos
(Requerimientos: ¿Qué debe hacer el sistema?)

Antes de hacer un caso de uso es necesario tratar de

entender los requerimientos del sistema. Trate de expresar lo
que el sistema debe hacer:

...el sistema debe permitir a los usuarios registrarse. El

administrador debe poder validar las peticiones de registro antes de
que los usuarios puedan publicar nuevos mensajes...

En base a esto, trate de responder las preguntas:

¿Que datos debe el actor

¿Cuales son las tareas
crear, guardar, modificar,
del/los actores involucrados?
destruir, leer?

¿Debe el actor informar al

¿Debe el el sistema informar
sistema de cambios externos
al actor de cambios internos?
ocurridos? 17
Diagrama de Casos de Usos

Límites del
Sistema

Generalización /
Caso de Uso Especialización
de Actores

Asociación
Caso de
Uso / Actor

Colaboración Actor
entre casos 18
de uso
Diagrama de Casos de Usos

Usado para
compartir
comportamiento
común entre varios
casos de uso

Usado para
modelar por
separado el
Usado para comportamiento
modelar excepcional (o
relaciones de adicional) del
Generalización / caso de uso base
Especialización
entre casos de
uso
51
Diagrama de Casos de Usos
(Diferencia entre generalizaciónuextensión)

Esto evidentemente está relacionado con la lámina

anterior...

Tomado de la documentación de la UOC (Universitat

Oberta de Catalunya), documento 917.pdf

52
Haciendo un paréntesis...
(Estereotipos)

planillas de
casos de uso
(CLEDA)

Ojo: Esto es sólo

un ejemplo de un
posible estereotipo, CRUD es un acrónimo
que viene de “Create,
no se lo tomen Read, Update, Delete”
21
literal...
Haciendo un paréntesis...
(Estereotipos)

Los estereotipos se pueden utilizar

en casi todos los elementos
disponibles de UML, de manera
que se puede extender y
enriquecer el lenguaje con su uso

En este caso los estereotipos se utilizan para diferenciar los distintos tipos
de actores (<<client>>, <<internal>>, <<system>>). Algunas personas
reemplazan el “monigote” por iconos personalizados (Ej. Una
computadora, monigotes de distintos colores, etcétera) 22
Haciendo un paréntesis...
(Estereotipos)

Se pueden utilizar imágenes para

representar cierto tipo especial de
actores 23
Diagrama de Casos de Usos
(Ejemplo / Include / Extends / Especialización)
Algunas personas utilizan la
inclusión para expresar que
el caso de uso asociado debe
de invocarse de manera
“obligatoria”

Múltiples casos de uso “reutilizan” otros casos

de uso. De esta forma no es necesario describir
varias veces el mismo caso de uso incluido
24
Diagrama de Casos de Usos
(Ejemplo / Include / Extends / Especialización)

Puntos de extensión
explícitos
Puntos de extensión
explícitos
57
Diagrama de Casos de Usos
(Ejemplo / Include / Extends / Especialización)

Las notas son un

elemento común de
UML, se pueden
asociar a casi todos
elementos
disponibles de UML
Una extensión puede estar asociada
a varios puntos de extensión
58
Algunas Reglas deEstilo
(Para los Diagramas de Casos de Uso)

Cada actor y caso de uso debe tener un

nombre único
Los actores deben tener nombres y/o iconos
representativos. Los nombres de los actores
deben representar roles

El nombre de un caso de uso debe indicar

acción y debe ser claro y conciso

Forma General: Imprimir

Verbo (Infinitivo) + Reporte de
Ventas
Predicado
59
Algunas Reglas deEstilo
(Para los Diagramas de Casos de Uso)

Mantener todos los casos de uso de un diagrama al

mismo nivel de abstracción

Evitar el cruce de líneas (En general, mantenga el

diagrama ordenado)

Evite tener demasiados casos de uso en el mismo

diagrama (Regla 5 ± 2) (¡Esto es relativo!)

Evite el uso complejo de relaciones de extensión,

especialización e inclusión (No más de tres niveles)

¡En general, use el sentido común y recuerde

utilizar la regla KISS! 60
Algunas Reglas deEstilo
(Para la Descripción Textual de Casos de Uso)

Narrar el flujo de eventos usando voz activa,

en tiempo presente y desde la perspectiva
del actor:

Evitar el uso de la “La clave es introducida

voz pasiva: por el usuario”

Preferir la voz “El usuario introduce la clave”

activa: “El sistema valida la clave”

61
Algunas Reglas deEstilo
(Para la Descripción Textual de Casos de Uso)

Exprese cada paso del flujo usando la forma llamada

y respuesta (reflejar el hecho de que el actor ejecuta
algo y el sistema responde a la solicitud del actor):

“El actor introduce su nombre de usuario y su contraseña, y

el sistema verifica si los datos concuerdan con lo que está
almacenado en la base de datos”

El caso de uso que se describe debe expresar un

solo requisito funcional (No trate de expresar más
de un requisito funcional en el mismo caso de uso)

Sin embargo, un caso de uso puede expresar más

de un requisito NO funcional (Esto está bien)
62
Ejemplo: ¿Qué esta terriblemente mal
en este diagrama?

¿Qué errores
puede
encontrar en
el diagrama? 32
Ejemplo: El Sistema Anterior
Mucho Mejor Representado

33
Detalle del Flujo deEventos
(Listar Solicitudes Pendientes)

Flujo Normal:
1.- El actor selecciona la opción para listar las Solicitudes Pendientes.
2.- El sistema presenta una lista de todas las Solicitudes Pendientes
(tanto de Registro de Usuario como de Publicación de Mensaje) junto
con una opción para ver más detalles sobre una solicitud en particular.
Flujo Alternativo:

En caso de un Registro de Usuario:

3A.- El usuario selecciona una solicitud.

4A.- Si se trata de una solicitud de Registro de Usuario el sistema le
envía al caso de uso Procesar Solicitud de Registro (CU-06)

En caso de una Publicación de Mensaje:

3B.- El usuario selecciona una solicitud.

4B.- Si se trata de una solicitud de Publicación de Mensaje el sistema le
envía al caso de uso Procesar Publicación de Mensaje (CU-07) 34
Ejemplo: Otra Representación

66
Detalle del Flujo deEventos
(Procesar Solicitud de Registro)

Flujo Normal:
1.- El actor selecciona la opción para procesar las solicitudes de Registro
de Usuario.
2.- El sistema invoca al caso de uso Listar Solicitudes Pendientes
(CU-08), lo que permite al usuario seleccionar una solicitud para procesar.
3.- El sistema presenta la información de la solicitud de Registro de
Usuario.
4.- El usuario decide si aprueba o rechaza la solicitud.
5.- Una vez aceptada la solicitud el sistema registra al nuevo usuario y
éste queda ya listo para acceder al foro.
Flujo Alternativo:

En caso de que la solicitud de Registro de Usuario sea Rechazada:

5A.- El sistema notifica al correo correspondiente a la solicitud que ésta ha

sido rechazada.
67
Ejemplo:
Una máquina expendedora de café (1)

68
Ejemplo:
Una máquina expendedora de café (2)

69
Ejemplo:
Una máquina expendedora de café (3)
El cliente enfrenta distintos
escenarios dependiendo de
lo que pretende comprar,
pero en general, comprar un
producto es algo muy
general con muchas
acciones comunes

70
Ejemplo:
Una máquina expendedora de café (4)

Cada despacho tiene

particularidades
acordes con el
producto solicitado
por el cliente
71
Modelo de Casos deUso

En Resumen

72
En Resumen ¿Qué Modelan los
Diagramas de Casos de Usos?

Actores del Sistema

Los Casos de Uso (Escenarios / Interacción Usuario

- Sistema)

Relaciones entre: Actores con Actores, Actorescon

Casos de Uso, Casos de Uso con Casos de Uso

Los límites del sistema, el alcance del sistema

El refinamiento o descomposición de los casos de

uso
73
Resumen de la Clase

Casos de Uso (Descripción Textual)

Casos de Uso (Diagramas)

Elementos Comunes de UML: Estereotipos, Notas,

Generalización (Especialización)

74