You are on page 1of 14

IronWorksIronWorksIronWorksIron

WorksIronWorksIronWorksIronWor
ksIronWorksIronWorksIronWorksIr
onWorksIronWorksIronWorksIron
Documento de Casos de Uso
WorksIronWorksIronWorksIronWor
[Nombre del proyecto]
ksIronWorksIronWorksIronWorksIr
onWorksIronWorksIronWorksIron
WorksIronWorksIronWorksIronWor
ksIronWorksIronWorksIronWorksIr
onWorksIronWorksIronWorksIron
WorksIronWorksIronWorksIronWor
ksIronWorksIronWorksIronWorksIr
onWorksIronWorksIronWorksIron
WorksIronWorksIronWorksIronWor
ksIronWorksIronWorksIronWorksIr
onWorksIronWorksIronWorksIron
[Fecha]
[Versin 1.0]

[Nombre de la empresa]
[Logo de la empresa]

[Logo de la empresa]
Casos de uso: [Nombre del proyecto]
Documento de Casos de Uso[Nombre del proyecto]

HISTORIAL DE REVISIONES
En esta seccin se presenta una tabla que describe la evolucin y los cambios
que se le realizan al documento desde que se inicia hasta que se haya llegado
a la versin base.

Versin

Fecha

Indica la versin
del documento,
que depende
segn la forma de
administracin de
configuraciones
seleccionada.

Se incluye la
fecha en la
que fue
realizado el
cambio del
documento.

Descripcin de
cambios (corta)

Es un pequeo
resumen de los
cambios ms
relevantes que
fueron realizados
en la versin

Responsable
(S)
Indica las
personas del
grupo de
trabajo que son
responsables
del o los
cambios
realizados en el
documento.

Tabla 1: Historial de cambios

Creado por IronWorks Ingeniera de Sistemas PUJ

[Logo de la empresa]
Casos de uso: [Nombre del proyecto]
Documento de Casos de Uso[Nombre del proyecto]

1. Introduccin
1.1

Lista de Casos de Uso

Esta seccin permite poner en contexto al lector sobre los casos de uso del
proyecto que se pretende desarrollar, mostrando la evolucin de los casos de
uso y los requerimientos asociados a este.

Ilustracin 1: Lista de Casos de Uso

VERSIN

CASO DE USO

Indica la versin del


caso de uso, que
depende segn la
forma de
administracin de
configuraciones
seleccionada

El nombre del caso de


uso

REQUERIMIENTOS
ASOCIADOS
Se deben poner los
identificadores (asignados en
el documento de
Especificacin de
Requerimientos de Software)
de los requerimientos
asociados al caso de uso.

Creado por IronWorks Ingeniera de Sistemas PUJ

[Logo de la empresa]
Casos de uso: [Nombre del proyecto]
Documento de Casos de Uso[Nombre del proyecto]

1.2

Diagrama de Casos de Uso

La ilustracin 2 muestra varios consejos para la realizacin de los casos de uso


as como tambin, la forma de evaluarlos despus de la realizacin para
verificar que cumpla con lo que los usuarios finalmente quieren.

Ilustracin 2: Definicin casos de Uso

Creado por IronWorks Ingeniera de Sistemas PUJ

[Logo de la empresa]
Casos de uso: [Nombre del proyecto]
Documento de Casos de Uso[Nombre del proyecto]
En general, un caso de uso especifica el comportamiento deseado del sistema
ms no especifica cmo realizar dicho comportamiento, es decir, no
compromete el proyecto con un tipo de tecnologa en particular ni mucho
menos con un lenguaje[1]. Una de las grandes ventajas de los casos de uso es
que permite comunicar el equipo de analistas con los desarrolladores, dando
espacio para que los gerentes sin entrar en detalle, conozcan el avance del
proyecto de acuerdo a los casos de uso implementados[2]. En s, un caso de
uso tiene un conjunto de secuencias, en donde cada secuencia representa una
interaccin con elementos que se encuentran afuera del sistema, dichos
elementos pueden ser actores o inclusive otros sistemas[3].
Para la realizacin de casos de uso es importante tener en cuenta los
siguientes dos conceptos que por lo general siempre se utilizan en cualquier
diagrama:
Inclusin: Una relacin entre casos de uso de tipo inclusin significa
que el caso de uso base incorpora explcitamente el comportamiento de
otro caso de uso. El caso de uso incluido nunca inicia solo, solamente es
activado como parte de un caso de uso ms grande que lo incluya.

Creado por IronWorks Ingeniera de Sistemas PUJ

[Logo de la empresa]
Casos de uso: [Nombre del proyecto]
Documento de Casos de Uso[Nombre del proyecto]
uc Primary Use Cases
Sistema de telefono movil

Rev isar mensaj es


env iados

include
Usuario

Validar usuario

include

Rev isar llamadas


recibidas

Ilustracin 3: Ejemplo de inclusin

En UML una inclusin se define como <<include>> y ayuda a evitar


reescribir el mismo flujo de eventos muchas veces, esto se logra,
especificando un comportamiento comn entre un caso de uso base y el
caso de uso incluido[3].
Extensin: Una extensin entre casos de uso significa que el caso de
uso base incorpora implcitamente el comportamiento de otro caso de
uso. A diferencia de la inclusin, el caso base de extensin no debe estar
asociado a ningn actor o sistema externo, ya que su comportamiento
es extendido por el comportamiento de otro caso de uso. Una extensin
se puede ver como una padre de un caso de uso que el usuario final
vera como un comportamiento opcional del sistema, de esta forma, el
analista
debe
separar
el
comportamiento
obligatorio
del
comportamiento opcional del sistema. Por otra parte una extensin
tambin se utiliza para separar un sub flujo que se ejecuta solo bajo
algunas circunstancias[3].
Creado por IronWorks Ingeniera de Sistemas PUJ

[Logo de la empresa]
Casos de uso: [Nombre del proyecto]
Documento de Casos de Uso[Nombre del proyecto]

uc Primary Use Cases


Sistema de telefono movil

Rev isar mensaj es


env iados

include
Usuario

Validar usuario

include

Rev isar llamadas


recibidas

Realizar llamada

extend

Recibir llamadas
adicionales

Ilustracin 4: Ejemplo de extensin

Creado por IronWorks Ingeniera de Sistemas PUJ

[Logo de la empresa]
Casos de uso: [Nombre del proyecto]
Documento de Casos de Uso[Nombre del proyecto]

Como se muestra en la ilustracin 4, en UML, una extensin es definida


como <<extend>>, en dicha extensin, existe un caso de uso Realizar
Llamada que en general permite a un usuario de un telfono mvil
realizar una llamada, dicho caso de uso es extendido por el caso de uso
Recibir llamadas adicionales, el cual permite que un usuario reciba
otra llamada cuando est hablando por el telfono mvil, pero ntese,
que este ltimo caso de uso solo se puede activar bajo condiciones
especiales, es decir, cuando el usuario este en una llamada activa y que
adems, reciba otra llamada.

Creado por IronWorks Ingeniera de Sistemas PUJ

[Logo de la empresa]
Casos de uso: [Nombre del proyecto]
Documento de Casos de Uso[Nombre del proyecto]

2. Documentacin de Casos de Uso


Cada uno de los casos de uso debe ser documentado para que los
desarrolladores conozcan el comportamiento de las funcionalidades del
sistema, a continuacin, se presenta una tabla para la documentacin de los
casos de uso, cada campo especifica que se debe diligenciar en cada uno de
ellos:

Id Caso de
Uso:

Nombr
e:
Para cada caso
de uso se debe
especificar un
nico
identificador
nombrado X
para los
ejemplos de las
dems casillas.
[4]

Proyecto:

Autor:

Nombre del
proyecto al que
pertenece el
caso de uso.
[4]

Autores que
realizaron el
caso de uso.
[4]

El nombre del caso de uso


debe reflejar las tareas que el
usuario final podr realizar
haciendo uso del sistema. El
nombre
debe
incluir
una
ACCIN, un VERBO y un
ADJETIVO,
adems,
dicho
nombre debe ser nico entre
los casos de uso que describen
el sistema. [4]
Ejemplos:
Registrar Usuario
Administrar Usuarios

Fecha:

Fecha de la ltima modificacin


del caso de uso y/o creacin.
[4]

Versi
n:

En esta casilla se define la


versin del caso de uso.
Para
un
proyecto
con
administracin
de
configuracin,
esta
versin
debe hacer referencia a una
lnea base para que los
desarrolladores
pueden
basarse en este caso de uso
para realizar la implementacin
del mismo. [4]

Creado por IronWorks Ingeniera de Sistemas PUJ

[Logo de la empresa]
Casos de uso: [Nombre del proyecto]
Documento de Casos de Uso[Nombre del proyecto]

Prioridad

Para la fase de implementacin, el grupo de trabajo debe


priorizar los casos de uso de acuerdo a las necesidades
propias del proyecto, es decir, si se le da mayor prioridad a
los deseos de los stakeholders o si simplemente se prioriza
por dificultad de implementacin, dicha priorizacin se
especifica en esta casilla, una medida usada en proyectos
de software y por herramientas de desarrollo son las
prioridades Alto, Medio y Bajo, pero el equipo de trabajo
puede definir sus propias prioridades ya sea con intervalos
de nmeros o con otros nombres.[3]
Es esta casilla se da una breve descripcin del
objetivo de implementar el caso de uso en el
sistema.

Objetivo en Contexto
(Resumen):

Actores Participantes

Entradas

Salidas

Ejemplo para un caso de uso Registrar usuario:


Este caso de uso le permite al sistema almacenar
la informacin personal de un usuario, donde
informacin personal se define como nombre,
apellidos, cdula y e-mail. [3]
Es una persona u otra entidad externa al sistema
de
software
que
interacta
con
este.
Generalmente se definen diferentes actores para
hacer referencia a diferentes tipos de usuarios,
clases o roles identificados en un grupo de
usuarios finales potenciales del sistema. En
resumen, se nombra el actor que inicializa este
caso de uso y todos los dems actores que
participan para completar dicho caso se uso. [3]
En este campo se enuncian todos los datos de
entrada necesarios para el xito del caso de uso.
Cuando se trata de registro de usuarios (clientes,
administradores, otros sistemas etc.), por lo
general, se necesitan muchos datos as que se
recomienda realizar un anexo con dicha
informacin para no hacer tan extensa la presente
tabla. Una entrada tambin puede hacer
referencia a cualquier tipo de archivo (fotos,
archivos planos, archivos con extensiones
especiales) o entradas por sensores para el caso
de robots y maquinas automatizadas. [3]
Al igual que las entradas, las salidas, hacen
referencia a lo que el caso de uso debe arrojar si
este acaba con xito, por lo general, son mensajes
de xito hacia el usuario, pero tambin puede
incluir creacin de archivos como archivos de
registros entre otros. (Una actualizacin en la
base de datos NO es una salida). [3]

Creado por IronWorks Ingeniera de Sistemas PUJ

10

[Logo de la empresa]
Casos de uso: [Nombre del proyecto]
Documento de Casos de Uso[Nombre del proyecto]
En esta casilla se lista cualquier actividad que
tenga que realizarse antes de ejecutar el caso de
uso. Tambin se definen todas las condiciones que
Pre-Condiciones
tienen que estar en un estado verdadero antes de
iniciar el caso de uso. Cada una de las
precondiciones encontradas se debe enumerar ya
que en ocasiones una precede a la otra.[6]
Condicin
final de xito:

Post-Condiciones

N
o.

Actor

Condicin
final de fallo:

Describe el estado final del sistema


cuando el caso de uso termina su
flujo bsico de xito.
Ejemplo:
El precio del artculo ha sido
actualizado en la base de
datos con el nuevo valor. [6]
Describe el estado final del sistema
en caso de fallo en el flujo bsico
del caso de uso. Por lo general el
sistema debe retornar al estado
anterior del sistema antes de
iniciar el caso de uso, dicha accin
tambin se define en esta casilla.
[6]

Flujo bsico de xito


N
o

Sistema

El flujo bsico de xito consiste bsicamente en definir la interaccin entre


el actor relacionado con el caso de uso y el sistema como tal, es decir, una
accin del actor genera una accin del sistema.
A continuacin se muestra un ejemplo del flujo bsico para el caso de uso
registrar usuario.
1

El usuario elige la opcin de


registrar usuario.
2

El sistema despliega el formulario


para el registro de usuario.

El usuario diligencia sus


datos y enva el formulario.

Creado por IronWorks Ingeniera de Sistemas PUJ

11

[Logo de la empresa]
Casos de uso: [Nombre del proyecto]
Documento de Casos de Uso[Nombre del proyecto]
El sistema valida y almacena la
informacin del usuario en la base
4
de datos, arrojando un mensaje de
xito.
En este campo se especifica cualquier otro camino de
xito que pueda surgir durante la ejecucin del caso de
uso, el hecho que surja un nuevo posible camino no
significa que existe un error, por ejemplo, puede
suceder que un usuario no desee ingresar su
informacin por el formulario del sistema sino cargarlo
mediante un archivo plano.

Variaciones
(Caminos
Alternativos):

Para enumerar el camino alternativos se hace de forma


similar a los caminos de excepcin de la forma X.E.Y
donde:
1. X es el identificador del caso de uso.
2. E indica cual es el paso del flujo bsico de xito
que puede tener variaciones.
3. Y Indica que es un flujo alternativo as que su
valor debe ser mayor a 0 e incrementar para
cada camino alternativo que exista para un solo
paso del flujo bsico.
Por ejemplo el camino alternativo 1.3.1 hace referencia
al flujo alternativo que puede ocurrir en el paso 3 del
flujo bsico de xito en el caso de uso 1. [6]

Variaciones
(Caminos de
excepcin):

En esta casilla se especifica cualquier tipo de error que


pueda ocurrir en la ejecucin del caso de uso y se
define como el sistema responder a dichos errores
(despliegue del error por pantalla, almacenamiento
descriptivo del error en un log del sistema). Adems,
se debe especificar como el caso de uso va a
reaccionar encaso de que se presente un error no
previsto. Para las transacciones en bases de datos se
debe especificar sobre que consultas se realizara el
roolback (volver al estado anterior de la base de
datos). [6]
Cada caso de excepcin se nombra de la forma X.Y.E.Z
donde:
1. X es el identificador del caso de uso.
2. Y Indica el flujo normal (0) o flujo alternativo
(>0).
3. E indica que es la excepcin.
4. Z es una secuencia para el nmero de caminos
de excepcin.
Creado por IronWorks Ingeniera de Sistemas PUJ

12

[Logo de la empresa]
Casos de uso: [Nombre del proyecto]
Documento de Casos de Uso[Nombre del proyecto]
Por ejemplo la excepcin 1.0.E.1 indica la primera
excepcin del flujo normal para el caso de uso 5.
Ejemplo de cmo documentar una excepcin:
1.0.E.1 El usuario ha ingresado informacin invalida:
1. El sistema le informa al usuario cul ha sido la
informacin invalida.
2. Ir al paso 2 (El sistema despliega el formulario
para el registro de usuario.).
En esta casilla se asocian otros casos de uso que se
disparan en algn paso del flujo bsico de xito, o en
alguna de las variaciones, dichos casos de uso
disparados se documentan de forma similar a las
variaciones como se muestran a continuacin:
Para enumerar las extensiones se hace de forma similar
a los caminos de excepcin de la forma X.E.Y donde:
1. X es el identificador del caso de uso.
2. E indica cual es el paso del flujo bsico de xito
que puede tener variaciones.
3. Y por defecto queda como una letra indicando
que es una extension.

Extensiones

Ejemplo:
1.3.E Hace referencia a una extensin que sucede en el
paso 3 del flujo bsico de xito del caso de uso 1.

Requerimientos
Asociados

En esta casilla se colocan los identificadores nicos de


los requerimientos que el presenta caso de uso
satisface. [6]

Creado por IronWorks Ingeniera de Sistemas PUJ

13

[Logo de la empresa]
Casos de uso: [Nombre del proyecto]
Documento de Casos de Uso[Nombre del proyecto]

3. Referencias y Bibliografa
[1] Larman C. UML Y PATRONES. Una introduccin al anlisis y diseo
orientado a objetos y al proceso unificado. 2nd ed. Aragon DF. Madrid:
Pearson Educacin. S.A.; 2003.
[2] Addison Wesley Longman. Unified Modeling Language User Guide.
1era ed. Imprimido en estados unidos. Abril del 2000.
[3] Construx Software. Use Case Requierments Toolbox Tool. Versin 1.
Disponible en http://www.construx.com/Page.aspx?hid=1594,
consultado el 21 de Septiembre del 2007.
[4] Karl E. Wiegers. Use Case Template. Disponible en
http://www.processimpact.com/process_assets/use_case_template.doc,
consultado el 21 de Septiembre del 2007.
[5] Luis Carlos Diaz. Plantilla de casos de uso, Ingeniera de Sistemas,
Pontificia Universidad Javeriana.
[6] TechnoSolutions Corp. Use Case Template versin 1.2 2004.
Disponible en http://www.technosolutions.com/use_case_template.html,
consultado el consultado el 21 de Septiembre del 2007.

Creado por IronWorks Ingeniera de Sistemas PUJ

14