Universidad Nacional Amaznica de Madre de Dios

Facultad de Ingeniera
Carrera Profesional de Ingeniera de Sistemas

MODELANDO: CASOS DE
USO DEL SISTEMA
Asignatura: Anlisis y Diseo de Sistemas II
Docente: Ing. Mijail Gualdimar Quispe Mamani
Contacto: mijailgmardl@gmail.com

RUP
Fase

Actividad

Entregable
Documento de Visin

Inicio

Modelamiento del
Negocio

UML

RESUMEN

Extensin para Modelado del

Negocio
Documento de visin
Plan de desarrollo del software
Modelado de caso de uso del
negocio
Entorno de trabajo

Plan de desarrollo del software

Modelo de caso de uso del negocio
Entorno de trabajo

Requerimientos

Elaboracin

Anlisis y Diseo

Modelo de caso de uso

Diagrama de caso de uso

Diagrama de caso de uso

Modelo del anlisis

Diagrama de colaboraciones

Diagrama de colaboraciones

Diseo de interfaces

Diagrama de secuencia

Diagrama de secuencias

Diseo de clases

Diagrama de clases

Diagrama de clases
Diagrama de Vistas

Plantilla de Clases

Plantilla de clases

Diseo de la base de datos

Diseo de la base de datos

Modelo de despliegue

Modelo de Despliegue

Prototipo arquitectnico
Implementacin
Construccin

Modelo de componentes

Modelo de despliegue
Prototipo arquitectnico

Diagrama de componentes

Diagrama de componentes
Vistas de componentes

Modelo de caja negra

Modelo de caja negra

Prototipo del software

Prototipo del software

Prueba de aceptacin

Documento de aceptacin del

producto software

Prueba

Transicin

Despliegue

Agenda
1. Caso de Uso

2. Documento Especificacin de Caso de Uso

3. Estructurar el Modelo de Casos de Uso

I. MODELO DE CASOS DE USO

1. Definicin
Artefacto de UML
Casos de uso
Propuestos inicialmente por Jacobson
Mecanismos para ayudar a representar y
comprender
los
objetivos
y
Requisitos
Funcionales, de forma simple y comprensible
para todo el personal involucrado (Cliente
Desarrolladores).

2. Actividades
Requisitos

de

la

Captura

de

Segn el RUP, los principales pasos para capturar

los requerimientos son:
Identificacin de Actores y Casos de uso
Priorizar Casos de Uso
Detallar Casos de Uso
Estructurar el MCU
Prototipar la interfaz de usuario (GUI).

: Analista de sistemas

: Arquitecto

: Especificador de casos de uso

: Diseador de interfaces de usuario

Encontrar actores y
casos de uso
Priorizar los
casos de uso

Detallar un caso
de uso

Estructurar el modelo
de caso de uso

Prototipar la interfaz
de usuario

2.1. Encontrar Actores y Casos de Uso

Objetivos
Delimitar el sistema y su entorno
Esbozar quin y qu (actores) interactuarn con el
sistema, y qu funcionalidad se espera del sistema
Capturar y definir un glosario de trminos comunes
esenciales para poder describir detalladamente los CU
del sistema.
Actividad decisiva
requerimientos

para

obtener

adecuadamente

Responsabilidad del Analista de Sistemas

los

2.1. Encontrar Actores y Casos de Uso

Actividades (no tienen por qu seguir este orden)
Establecer el lmite del sistema: solo software,
hardware y software como un todo, lo utiliza una
persona, una organizacin, etc.
Encontrar actores principales: Usuarios que
satisfacen con el uso de los servicios del sistema

se

Para cada actor, identificar sus objetivos de usuario

Definir los CU que satisfagan los objetivos de usuario.
Nombrarlos de acuerdo con sus objetivos
Describir brevemente (descripcin informal) cada CU.

2.1.1. Actores
Representan
entidades
externas
que
interactan
(mantenimiento y/o operacin) con el sistema
Puede ser un usuario o un sistema externo
Un actor representa un rol:
No se corresponde directamente con personas concretas
Toda persona que interacta con el sistema es representado
al menos por un actor en el MCU
Identificacin de Actores
Qu grupos de usuarios necesitan el sistema para su
trabajo?
Qu usuarios realizan las funciones principales del sistema?
Qu usuarios realizan funciones secundarias, como
mantenimiento o administracin?
Existe algn sistema externo de hardware o software?
Se da nombre a los actores y se describen brevemente sus
papeles y para qu utilizan el sistema.

Identificar Actores principales y objetivos

Adems de actores principales y objetivos, se pueden
utilizar diferentes preguntas para identificar otros menos
evidentes:
Quin arranca y detiene el sistema?
Quin administra el sistema?
Quin gestiona los usuarios y la seguridad?
Es un actor el tiempo porque el sistema hace algo
como respuesta a un evento de tiempo?
Quin evala la actividad o el rendimiento del sistema?

La diferencia entre un actor y un usuario del sistema es que el

actor representa a un tipo particular de usuario o rol.

Tambin existe la posibilidad de tener a un usuario jugando

varios roles. Es decir, el usuario se comporta como varios
actores.

Encontrar a los actores significa tambin definir las

fronteras del sistema. Slo aquellos que se comunican
directamente con el sistema son actores.

Si est desarrollando un sistema de reservaciones, para un

agente de viajes, el actor ser el Agente de Viaje. El viajero no
interacta con el sistema, entonces no ser un actor.

Si est desarrollando un sistema de reservaciones,

para que los viajeros se puedan conectar a travs de
Internet, el viajero ahora si interactuar con el Sistema
y se convertir en ACTOR.

Tipos de Actores
<Actor Name>
(f rom Actors)

Actor Principal: ejemplo opciones principales

Actor Secundario: ejemplo consulta
Actor Hardware: ejemplo hullera
Actor Sistema: ejemplo interactuar con el sistema
bancario

La Lista Actor - Objetivo (recoge los Actores

principales y sus objetivos de usuario).
Actor

Objetivo

Actor

Objetivo

Cajero

Procesar ventas
Gestionar devoluciones
Abrir caja
Cerrar caja

Administrador
del sistema

Aadir usuarios
Modificar usuarios
Eliminar usuarios
Gestionar
seguridad
Gestionar tablas

Jefe de
cajas

Controlar productividad
cajero
Distribuir cajeros en
cajas

Sistema de
Control de
Ventas

Analizar datos de
ventas y
rendimiento

2.1.2. Identificacin de Casos de Uso

Escenario (o instancia de caso de uso)
Es una descripcin narrativa de lo que la gente hace cuando utiliza una
aplicacin, es una secuencia especfica de acciones e interacciones entre
los actores y el sistema.
Descripcin concreta e informal de una sola caracterstica del sistema,
desde el punto de vista de un solo actor
Los analistas y los usuarios escriben y refinan diversos escenarios para
comprender mejor lo que debe hacer el sistema
Identificacin de escenarios
Qu tareas necesita el actor que realice el sistema?
Qu informacin consulta el actor? quin crea esos datos? se pueden
modificar? quin puede hacerlo?
Qu cambios externos necesita informar el actor al sistema? Cundo y
con qu frecuencia?
De qu eventos necesita el actor que le informe el sistema? cundo y
con qu frecuencia?

Caso de Uso

Especifica todos los escenarios posibles para una

determinada funcionalidad
Es iniciado por un Actor
Puede interactuar con otros actores
Representa un flujo de eventos completo a travs del
sistema, es decir, describe una serie de interacciones
relacionadas que resultan de la inicializacin del CU.

Errores en la identificacin de los casos de

uso
Un error muy extendido, y que es cometido en la mayora de la
bibligrafa sobre casos de uso, es considerar las opciones del
men o funciones del sistema como casos de uso (puede
revisar el libro de Larman [LAR99] y podr encontrar este tipo
de errores).
Kurt Bittner [BIT00] seala que los casos de uso deben mostrar
lo que el usuario necesita del sistema y no mostrar las
funciones u opciones del men que permitirn realizar lo
solicitado; por ejemplo, en un sistema donde se debe
almacenar la informacin de los clientes, lo que al usuario le
importa es actualizar la informacin de clientes. Esta actividad
la podr realizar accediendo a las opciones del men agregar,
modificar y eliminar clientes; por lo tanto la funcionalidad del
sistema ser representada con el caso de uso Gestionar
cliente

Errores en la identificacin de los casos de

uso

Agregar Cliente

<<communicate>>

(from <Use Case Name>)

<<communicate>>

<<communicate>>

Modificar cliente

Usuario
(f rom Actors)

Usuario

<<communicate>>

Eliminar Cliente

(f rom Actors)

Gestionar Cliente

2.1.3. Relaciones entre Actores y CU

Representan el flujo de informacin durante el CU
Se puede distinguir entre el Actor que inicia el CU y los
dems actores que intervienen posteriormente
Los CU identificados previamente a partir de los objetivos
de los actores, se representan mediante valos y
representan una tarea que el sistema en desarrollo tiene
que incorporar
El Modelo de Casos de Uso representa el contexto del
sistema:
Lmites del sistema
Qu permanece fuera del sistema
Cmo se utiliza el sistema
Resume el comportamiento de un sistema y sus actores

Error: casos de uso como DFD

Error: el caso de uso que es incluido por uno

solo

Error: uso de noticin antigua de UML

2.2. Priorizacin de casos de uso

Determinar cules son necesarios para el desarrollo en las
primeras iteraciones y cules pueden dejarse para
posteriores iteraciones
Cuestiones a tener en cuenta:
CU con dificultad de desarrollo
CU imprescindibles para la puesta en marcha del
sistema
Organizacin del desarrollo incremental
Disponibilidad de equipo de desarrollo
Se revisa la priorizacin con el Jefe de Proyecto y se utiliza
como entrada para la planificacin de cada iteracin del
proyecto.

2.3. Detallar los casos de Uso

Objetivo principal: describir su flujo de sucesos en detalle

Cmo comienza
Cmo termina
Cmo interactan con los actores
Se detalla paso a paso la secuencia de acciones del CU
Se trabaja estrechamente con los usuarios reales de los
CU
Resultado: descripcin detallada mediante
Texto
Diagramas

2.4. Estructurar el modelo de Casos de Uso

Extraer descripciones de funcionalidad (de casos de uso)

generales y compartidas que pueden ser utilizadas por
casos de uso ms especficos
Extraer descripciones de funcionalidad (de casos de uso)
adicionales u opcionales que pueden extender casos de
uso ms especficos (relaciones de extensin)
Extraer descripciones de funcionalidad (de casos de uso)
adicionales e incondicionales incluidas en la ejecucin de
casos de uso especficos (relaciones de inclusin).

Objetivos:

Identificar las relaciones entre casos de uso.

Diferenciar las relaciones entre casos de uso
Brindar un ejemplo de las relaciones entre caso de
uso.

Pre Requisitos
Tener
documentados los
casos de uso:
Flujo de Eventos.

La presentacin
se
realizar
tomando
como
ejemplo
el
Sistema Notas.

Razones
Existen
3
razones
para
estructurar el Modelo de Casos
de Uso:
Hacer que los casos de
uso
sean
fciles
de
entender.
Permite
extraer
el
comportamiento
comn
encontrado
en
varios
casos de uso.
Hacer que el Modelo de
Casos de Uso sea fcil de
mantener.

Tipos De Relaciones

Existen 3 tipos de relaciones

estructurar los casos de uso:
Include
Extend
Generalizacin

para

Relacin Include

Conecta un caso de uso base a un caso de uso incluido.

El caso de uso incluido es abstracto.
La
inclusin
es
encapsulada
y
representa
el
comportamiento que es reutilizado por varios casos de
uso.
Se factoriza el comportamiento que es comn en un
nuevo caso de uso.

Se tiene el siguiente diagrama:

Los pasos del 2 al 5 se repiten en

los flujos de eventos de los dos
casos de usos.
Es decir, se est llevando a cabo
el mismo comportamiento en
ambos casos de uso.

Este comportamiento se
extrae en un nuevo caso de
uso: Buscar Alumnos

Buscar Alumnos

El nuevo diagrama con include:

CU Base

CU Base

CU Incluido

Inicialmente la
relacin con el
caso de uso que
AUN no existe
Se usa para
FACTORIZAR un
caso de uso por
ejemplo:
2 casos de uso
que tienen una
funcionalidad en
comn, ambos
casos de uso se
unen con
include al tercer
caso de uso (la
funcionalidad en
comn)

Relacin Extend

Conecta un caso de uso extendido a un caso de uso base.

En el caso de uso base estn referenciados los puntos de
extensin.
El caso de uso extendido es a menudo abstracto, pero no
necesariamente tiene que serlo.
s

Se pueden usar la relacin extend para varios propsitos:

a.Para demostrar que una parte del caso de uso es opcional, de

esta manera se separa el comportamiento opcional del
comportamiento obligatorio en su modelo. Tambin se le
conoce como comportamiento aadido.
b.Para demostrar que un subflujo es ejecutado slo bajo
ciertas condiciones como un trigger o alarma.
c. Los segmentos de comportamiento que son insertados como
puntos de extensin en el caso de uso base, dependern de la
interaccin con los actores durante la ejecucin del caso de
uso base.
d.La extensin es condicional, lo que quiere decir que su
ejecucin es dependiente de lo que suceda mientras se
ejecuta el caso de uso base.

El nuevo diagrama con Extend

Relacin de Generalizacin

Se utiliza cuando el
caso de uso padre
debe
ser
subclasificado
en
uno o ms casos de
uso hijos.

Alumno

Reservar recursos

El caso de uso hijo

hereda
la
estructura,
comportamiento y
las relaciones del
padre.

Reservar libros

Reservar cubiculos

2.5. Prototipado de la interfaz

Diseo lgico de la interfaz: se decide qu se necesita de las
interfaces de usuario para habilitar los CU para cada actor
Diseo fsico de la interfaz: se desarrollan prototipos que
ilustran cmo pueden utilizar el sistema los usuarios para
ejecutar los CU
Resultado final: conjunto de esquemas de interfaces de usuario
y prototipos de interfaces que especifican la apariencia de esas
interfaces para los actores ms importantes.
___
___
___
___
Requisitos
Modelo de
casos de uso adicionales
Caso de uso ___
(descrito)
___
Prototipar
___
la interfaz
___
Glosario

Prototipo de interfaz de
us uario

II. ESPECIFICACION DE CASOS DE USO

1. QU ES LA ECU?
Se describen QUE hacen el Actor y el Sistema y
NO COMO se implementa
Tanto el camino bsico como los alternativos
deben describirse textualmente en una seccin
de la ECU.

2. PARTES DE UNA ECU

1. Nombre
Debe indicar el ttulo del Caso de Uso
2. Breve Descripcin
Descripcin pequea de las actividades o
pasos principales que realiza el CU.
Debe incluir el propsito del CU.

3. Flujo de Eventos
Evento Disparador
Evento que demandan la ejecucin del CU del
sistema.
Evento ante el cul el sistema de software debe
reaccionar.
Indica que Actor inicia el CU: El Caso de Uso
comienza cuando el Actor solicita ..
Se pone antes del Flujo Bsico.

3.1. Flujo Bsico

Incluir el punto de inicio y de termino del CU.
Conjunto ordenado de acciones (enumerados)
realizados por el Actor y el Sistema, para
alcanzar el propsito
La instancia del CU se inicia y pasa a un estado
de comienzo
El CU es invocado por el mensaje de un actor
Transita a otro estado realizando una secuencia
de acciones (clculos, seleccin de camino,
mensajes de salida, etc.)

 Queda a la espera (en el nuevo estado) de otro

mensaje externo
Es invocado (otra vez) por un nuevo mensaje
Termina la instancia del CU
El camino elegido como bsico debe ser el
normal, el ms habitual u obvio para el Actor
que acta en la mayora de los escenarios
Incluir mensajes de confirmacin.

FLUJO BASICO

10

CASO INCLUIDO
Activacin mandatorio del CU incluido, en algn
evento del flujo de eventos del CU principal (el
que incluye)
El sistema incluye el Caso de Uso <nombre
CU>
Se grafica en la actividad Estructurar el
Modelo de Caso de Uso.

4. Flujo(s) Alternativo(s)
Los caminos alternativos, desviaciones o excepciones
pueden ocurrir porque:
El Actor puede elegir entre diferentes caminos
Si est implicado ms de un actor, las acciones de uno
de ellos pueden influenciar el camino de las acciones
de los otros
El sistema puede detectar ingresos errneos de los
actores
Violacin de Reglas del Negocio.
Alguna falla en el funcionamiento de alguno de los
recursos del sistema, por lo que ste no puede efectuar
su trabajo hasta el fin del CU.
Incluir si el CU continua o termina, adems de los
mensajes preventivos o alertas

10

Escenario
3.1

3.n

FLUJO ALTERNATIVO

5. Subflujos
Los subflujos se dan cuando el actor elige otra
opcin dentro del CU.
Por Ejemplo en Gestin de Productos: Ingresar
Producto es el Flujo Bsico. Los Subflujos seran:
Actualizar
Producto,
Eliminar
Producto,
Consultar Producto.
Los
Subflujos
tambin
tienen
Flujos
Alternativos.

6. Pre Condiciones
Son estados del sistema de los que el
usuario puede darse cuenta.

7. Post Condiciones
Son estados del sistema de los que el
usuario puede darse cuenta.

6.1. Pre Condiciones

Expresan condiciones o restricciones para que el
flujo de eventos del CU comience (no es el evento
inicial)
Se expresan en trminos de:
Estado interno del sistema de software
Condiciones externas al sistema de software
(estado del contexto)
Una precondicin de un CU no se aplica a
subflujos individuales, sino a todo el CU.
Futuro (debe).

EVENTO

CONDICION

QUE

ACCION

= ECA

8. Prototipos (GUI)
Una alternativa para la definicin de los
requerimientos.
Consiste en capturar un conjunto inicial de
necesidades e implementarlas rpidamente con
la intencin de expandirlas y refinarlas
iterativamente, al ir aumentando la compresin
que tienen del sistema los Usuarios y
Desarrolladores.

3. TIPS PARA DETALLAR LOS CU

Escriba oraciones cortas, concisas

Evite adverbios: muy, casi, mejor que, bastante,
etc.
Emplee correctamente los signos de puntuacin
Evite usar oraciones compuestas
Describa el flujo, no slo el propsito del CU
Describa slo el flujo del CU, evite mencionar
eventos de otros CU que pudieran ejecutarse en
paralelo.
No mencione actores que no intervienen en el CU
Si el orden de los eventos no es fijo, esta
caracterstica debe ser explcita
Emplee lenguaje simple y claro, evitando trminos
tcnicos

4. QUINES LEEN LAS ECU?

Clientes: aprueban lo que debe hacer el sistema

Usuarios: obtienen comprensin del sistema
Desarrolladores
del
Sistema:
documentan
el
comportamiento del sistema
Revisores: examinan el flujo de eventos
Analistas del Sistema / Diseadores: proveen la base
para un anlisis y diseo
Testeadores del Sistema: usado como base para casos
de prueba
Lder de Proyecto: provee entradas para el
planeamiento de proyectos
Escritor Tcnico (Documentador): para el Manual de
Usuario.

5. PLANTILLA

1. Nombre del Caso de Uso

2. Breve Descripcin
3. Flujo de Eventos
Evento Disparador
3.1 Flujo Bsico (Ejm. ingresar nota)
1.
2. Incluir Casos de Uso <<nombre>>
3.
n.
3.2 Flujos Alternativos (siempre los hay)
3.2.1 < Primer Flujo Alternativo >
3.2.2 < Segundo Flujo Alternativo >

3.3 < Sub Flujos > (Depende de la funcionalidad,

ejemplo, modificar nota)
3.3.1 < Flujos Alernativos del Sub Flujo >
4. Requerimientos Especiales
4.1 < Primer Requerimiento Especial >
5. Pre Condiciones
5.1 < Precondicin 1 >
6. Post Condiciones
6.1 < Post Condicin 1 >
7. Puntos de Extension
7.1 << Nombre del Caso de Uso Extendido>>
8. Prototipo (hay casos de uso que no tienen GUI)
(GUI).

Ejemplo de Caso de Uso

EVENTOS
Login
:
Passwor
d:
Aceptar
Evento:
accin
sobre
algn elemento de la
interfaz y que provoca
una
reaccin
DE
IMPORTANCIA
en
el
sistema.

Cancelar

Cuando
el
usuario
indica
Aceptar
el
Sistema vlida si el
password y el login son
vlidos.

FLUJO BSICO DE EVENTOS

Qu hace el usuario?

Qu hace el sistema?

1. Ingresar login
2. Ingresar password

3. Indicar Aceptar

4. El sistema vlida
si el password y el
login son vlidos

Flujo alternativo de Eventos

Qu hace el usuario?

Qu hace el sistema? Alternativas

1. Ingresar login
2. Ingresar password

3. Indicar Aceptar

4.
El
sistema
valida si el
password y
el login son
vlidos

Si
en
4
el
Sistema
determina que el
password y el
login no son
vlidos entonces
emitir
al
usuario
el
mensaje: login y
password
invlidos. Y se
regresa al paso 1