UNIDAD I

FUNDAMENTOS DE LA INGENIERÌA DEL SW

Tema 7 : Modelo de Casos de Uso

Asignatura: Ingeniería del Software

Titulación: Ingenieríaia en Informática
Profesor: Ing. Irma López Moreno
DIAGRAMA DE CASOS DE USOS

El Diagrama de casos de uso representa la forma en

como un cliente (llamado en UML 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).
¿QUÉ ES UML?

Es el Lenguaje Estándar para:

Visualizar
Especificar
Construir y,
Documentar los
planos del Sw.
(Fue desarrollado
por la OMG de UML
Características
Object
Management
-Proporciona el lenguaje (notación técnica)
Group)
-Permite expresar requisitos y pruebas
-Permite modelar actividades, procesos versiones
El Object Management Group (OMG)

Consorcio sin fines de lucro formado en 1989 , dedicado estudio y

establecimiento de estándares de tecnologías orientadas a objetos, tales

UML
XMI
CORBA
BPMN

Promueve el uso de tecnología orientada a Objetos.

Desarrolla guías y especificaciones normadas.
UML es un "lenguaje de modelado" para especificar o para
describir métodos o procesos.

Se utiliza para definir un sistema, para detallar los artefactos en

el sistema y para documentar y construir. En otras palabras, es el
lenguaje en el que está descrito el modelo.

Permite soportar metodología de desarrollo de software (tal

como el Proceso Unificado Racional o RUP), pero no especifica
en sí mismo qué metodología o proceso usar.

UML no puede compararse con la programación estructurada,

pues UML significa Lenguaje Unificado de Modelado, no es
programación
Diagramas de Casos de Uso con UML

Un factor clave al definir casos de uso es que no especifica su

implementación.

Éste define como debería comportarse un Sistema de Gestión y como

interactúan los usuarios con el sistema.

Los casos de uso especifican un comportamiento deseado, no

imponen como se llevara a cabo ese comportamiento.

Lo más importante es que se permite que los usuarios finales

y los expertos del dominio se comuniquen con lo desarrolladores sin
entrar en detalles.

Permiten centrarse en las cuestiones más importantes para el

usuario final.
UN DIAGRAMA DE CASOS DE USO CONSTA
DE LOS SIGUIENTES ELEMENTOS:

Actor
Casos de Uso
Relaciones de uso, herencia y comunicación o asociación.

Define la forma como los actores y casos de uso colaboran entre sí

 ELEMENTOS DE UN DIAGRAMA DE CASOS DE USOS

actor

Caso de uso

asociación

Una asociación entre un actor y un caso de

uso, indica que el actor y el caso de uso se
comunican entre sí, y cada uno puede enviar y
permite asociar objetos que
recibir mensajes
colaboran entre sí.
Una definición previa, es que un Actor es un rol que un usuario juega con respecto
al sistema.

Es importante destacar el uso de la palabra rol, pues con esto se especifica que un
Actor no necesariamente representa a una persona en particular, sino más bien la
labor que realiza frente al sistema.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en

que el rol de Vendedor con respecto al sistema puede ser realizado por un
Vendedor o bien por el Jefe de Local.
RELACIONES ENTRE ACTORES

•Los actores en UML son clases con el estereotipo <<actor>> y tienen un

estereotipo icono estándar.
-El nombre de la clase es el nombre del actor.
– Una clase actor puede tener atributos y comportamiento.
– Los actores pueden tener las mismas relaciones que las clases.
•Cuando varios actores, como parte de sus papeles, también representan un papel
más generalizado, se describe mediante una relación de generalización.
– El comportamiento del papel general se describe en una superclase actor. Los
actores especializados heredan el comportamiento de la superclase y extienden
ese comportamiento de algún modo.

Actor:= class <<cliente>>

atributos

<<Agente de seguros>>
métodos

<<cliente por teléfono>> <<cliente en persona>>

ES UNA OPERACIÓN/TAREA ESPECÍFICA QUE SE
REALIZA TRAS UNA ORDEN DE ALGÚN AGENTE
EXTERNO, SEA DESDE UNA PETICIÓN DE UN ACTOR
O BIEN DESDE LA INVOCACIÓN DESDE OTRO CASO
DE USO.

Asociación entre C.U y C.U

Asociación entre Actor y C.U
 Gestión de
Mnto. De
libros
Gestión de
fechas
>>
ses
u
<<
Encargado
<<primario>> Relación de inclusión
Gestión de
Préstamos
<<
ex
te
<<e
nd
ss> Relación por extensión
asociación xte
nds
s>>
>

Préstamos a préstamos a
investigadores estudiantes
Flujo de eventos Principal: Obtener y Verificar C.U. DESTINO
el libro pedido. include (Gestión
de fechas). Gestión de fechas

>>
s es
u
<<

Gestión de
Préstamos Verificar que el libro pedido
esté disponible.

C.U. origen

La relación de inclusión se usa para evitar describir el mismo flujo de eventos repetidas
veces, poniendo el comportamiento común en un caso de uso aparte (que será incluido
por un caso de uso base).

Una relación de inclusión se representa como una dependencia, estereotipada

con include ó uses.
 Validar usuario
>>
ses
u
<<

Usuario
Alertas de
mensaje

Buscando datos
>> del producto
ses
u
<<

e>>
clud

<<
inc
<<in

lud
e>
Selecciona café

>
<<GERENTE>>
<<Secundario>>
pedido Obtener reportes
de ventas por producto

<<empleado>>
<<primario>>
RELACIONES DE HERENCIA
(ESPECIALIZACIÓN/GENERALIZACIÓN)

Indica que una clase (clase derivada) hereda los métodos y atributos
especificados por una clase (clase base), por lo cual una clase derivada además
de tener sus propios métodos y atributos, podrá acceder a las características y
atributos visibles de su clase base.

Persona

Generalización
Alumno Profesor (relación es_un)

Especialización
La herencia es uno de los conceptos fundamentales de la programación orientada a
objetos, en la que una clase «recoge» todos los atributos y operaciones de la clase de la
que es heredera, y puede alterar/modificar algunos de ellos, así como añadir más atributos
y operaciones propias.

En UML, una asociación de generalización entre dos clases, coloca a estas en una jerarquía
que representa el concepto de herencia de una clase derivada de la clase base

Representación en UML de una Generalización

En el Diagrama de Clases (Modelo Estático)

En el Diagrama de Casos de Uso
CLASE BASE
(Modelo de Comportamiento

<<e
xten
<< dss
>>
s>>

ex
te
ds

nd
ten

ss>
>
ex
<<

CLASE DERIVADA
MAS DETALLES DE LAS ASOCIACIONES

Asociación
Es el tipo de relación más básica que indica la invocación desde un actor
o caso de uso a otra operación (caso de uso). Dicha relación se denota
con una línea simple.

Dependencia o Instanciación
Es una forma muy particular de relación entre clases, en la cual una
clase depende de otra, es decir, se instancia (se crea). Dicha relación se
denota con una flecha punteada.
Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función
dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia
(<<extends>>).
Este tipo de relación esta orientado exclusivamente para casos de uso (y no para
actores).
extends: Se recomienda utilizar cuando un caso de uso es similar a otro
(características).
uses: Se recomienda utilizar cuando se tiene un conjunto de características que son
similares en más de un caso de uso y no se desea mantener copiada la descripción de
la característica.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y
modelamiento de clases, en donde esta la duda clásica de usar o heredar.
 SISTEMA DE GESTIÓN DE
BIBLIOTECAS

Lector
Jefe

Estudiante Investigador

Diagrama de modelado de contexto del sistema a través del Diagrama de casos de uso.
También llamado Modelo de Comportamiento del sistema o modelo de casos de uso.
Modelado de los Requisitos de un Sistema

Para modelar los requisitos de un sistema:

• Hay que identificar el contexto del sistema, identificando los actores a su alrededor .
(Fuente: Booch, Jacobson, Rumbaugh)
• Hay que considerar el comportamiento que cada actor espera del sistema o requiere
que éste le proporcione.
• Hay que nombrar esos comportamientos comunes como casos de uso.
• Hay que factorizar el comportamiento común en nuevos casos de uso que puedan ser
utilizados por otros; hay que factorizar el comportamiento variante en nuevos casos de
uso que extiendan los flujos principales.
• Hay que modelar esos casos de uso, actores y relaciones en un diagrama de casos de
uso.
• Construir los Diccionarios de actores y diccionario de casos de uso para el documento
ERS
DICCIONARIO DE ACTORES

Nombre de
Actor Actor Descripción Actor Tipología Rol

Realiza consultas de notas, Consulta de notas

Director plantel Imprime constancia de Primario e Imprime
inscripción, constancia de Constancias.
estudio

Administrador Se encarga de llenar y editar la RegistrarDatos

de Control de base de datos con información Primario del docente y
Estudio del docente, alumnos alumno

Inserta las notas de los

alumnos dependiendo las Insertar notas de
Docente secciones, lapso y asignatura Primario los alumnos
que dicte

Realiza solicitud de Imprime

Representante constancia de estudio Secundario Constancias
DICCIONARIO DE CASOS DE USO

Nombre del caso de uso

Caso de Uso
Actor Descripción

Se encarga de la validación y autenticación del

Validación registro usuario

Consulta de notas Se encarga de efectuar consultas de notas ed

estudiantes así como de registrar notas por parte
del docente

Genera reportes se docentes activos y/o

jubilados
Impresión docentes

Realiza inscripción de estudiantes

inscripción
DICCIONARIO DE CASOS DE USO Nombre del caso de uso Actores que intervienen en el C.U
Descripción C.U
Ejemplos de DICCIONARIO DE C.U

Nombre Autenticación
Nombre Clase
Descripcion Docentes, Administrador, Director
Descatributos Permite validar los accesos permitidos al sistema
Eventos Actor Eventos Sistema
Introduce usuario
Introduce Contraseña El Sistema habilita la base de datos
Valida usuario y contraseña
Genera alerta en caso de error
Flujo Principal Si tiene acceso le establece los
niveles de acceso
En caso de no existir usuario y clave Invoca método de generación de error
Alternativa
Tiene que existir la clave y la contraseña
Precondición La interfaz tiene que estar habilitada
Pos condición Usuario validado
Presunción La base de datos para verificar está disponible.
 Diccionario de Clases

Nombre de la clase

Descripción

Atributos

Nombre Tipo Longitud Descripción Visibilidad

Métodos

Nombre Descripción Parámetros Visibilidad