Hoja de Descripción de Casos de Uso

UNIVE
RSIDA
D
Curso:
NACIO
NAL
Ing. Sofware
orientado
a
DE
Objetos
TRUJI
Docente:
LLO
Juan Santos Fernndez
Hoja de descripcin de casos de uso
Ingeniera de Software
Alumnos:
Espino Rivera Marcia

Felipe Barba Peter
Rodriguez Costilla
Miluska
Florian Lozano
Patricia
Vsquez Guevara
DEDICATORIA
Diana
1
.
El presente informe se la dedico a
mi familia que a sus consejos y
palabras de aliento crec como
persona. Gracias por ayudarme a

cumplir
mis
objetivos
como
A mis padres por su amor,

ayuda
momento.
apoyo
en
todo
Gracias
por
esta
hermosa herencia.
A Dios Todopoderoso por darme las

fuerzas para seguir adelante a pesar de
las adversidades
Los alumnos.
AGRADECIMIENTOS
Primero y antes que nada, dar gracias a Dios, por estar con nosotros en cada
paso que damos, por fortalecer mi corazn e iluminar mi mente y por haber
puesto en mi camino a aquellas personas que han sido nuestro soporte y
compaa durante todo el periodo de estudio.
Agradecer hoy y siempre a nuestras familias por el esfuerzo realizado por

ellos. El apoyo en nuestros estudios, de ser as no hubiese sido posible. A
nuestros padres y dems familiares ya que me brindan el apoyo, la alegra y
me dan la fortaleza
NDICE
I.
CUANDO UTILIZAR LOS CASOS DE USO?......................................................5
II. PARA QU SIRVEN LOS CASOS DE USO?........................................................5

III.
QU ES UN MODELO DE CU Y QUE SON LOS CU?....................................6
IV.
QU SON LOS ACTORES Y CMO IDENTIFICARLOS?..............................6
V. CMO SE HACE EL DIAGRAMA DE CU?.........................................................7

VI.
CMO IDENTIFICAR LOS CASOS DE USO?.................................................8
VII.
CMO ESPECIFICAR CASOS DE USO?.........................................................8
1.
Caso de Uso............................................................................................................9
2.
Fuentes..................................................................................................................10
3.
Actores..................................................................................................................10
4.
Descripcin...........................................................................................................10
5.
Flujo bsico...........................................................................................................11
6.
Flujos alternos......................................................................................................12
7.
Pre-condiciones....................................................................................................13
8.
Post-condiciones...................................................................................................14
9.
Requerimientos trazados......................................................................................15
10.
Puntos de inclusin y extensin........................................................................15
11.
Notas.................................................................................................................16
12.
Consideraciones a la hora de escribir un Caso de Uso.....................................16
a)
Empleo del SI Condicional...............................................................................16
b)
Opciones de los actores.....................................................................................17
c)
Mostrando iteraciones.......................................................................................17
d)
Secuencias de eventos y eventos opcionales....................................................18
e)
Nivel de detalle esperado..................................................................................22
f)
Creatividad........................................................................................................23
VIII. CMO ESTRUCTURAR CASOS DE USO?...................................................24

1.
Generalizacin de actores.....................................................................................24
4
2.
Generalizacin de casos de uso............................................................................25
3.
Extensin de casos de uso....................................................................................26
4.
Inclusin de casos de uso.....................................................................................27
5.
Cmo interactan los CU.....................................................................................27
6.
Modelos de casos de uso no tienen niveles..........................................................28

a)
Casos de uso de negocio (CUN).......................................................................29
b)
Palabras reservadas...........................................................................................29
7.
RECOMENDACIONES GENERALES..............................................................30
a)
Empleo de estilos del procesador de palabras..................................................30
b)
Redacciones cortas, concisas y completas........................................................30
INTRODUCCIN
5
Los CU forman parte de las especificaciones de UML 2.0, as como de metodologas de

desarrollo, los mismos son empleados para la especificacin de requerimientos
funcionales.
Cada analista de requerimientos debe conocer profundamente el significado de escribir
CU y el empleo que a stos se les dar. Los casos de uso son una manera de capturar
requerimientos, para ser expresados a los equipos de anlisis, quienes encontrarn en
estos su principal fuente para identificar objetos y clases.
Pueden definirse varios estilos de CU dependiendo de las caractersticas del sistema a
ser descrito, as como los criterios que permiten identificar cundo cada criterio debe ser
utilizado y por qu.
HOJA DE DESCRIPCIN DE UN CASO DE USO

I.
CUANDO UTILIZAR LOS CASOS DE USO?
Los casos de uso son un tipo de requerimientos utilizados para especificar

funcionalidad, especialmente en sistemas con un alto grado de interaccin
hombre/mquina (y pueden ser utilizados hasta en sistemas de batch). En esencia los
casos de uso describen los intercambios entre el sistema que se est describiendo y las
personas o sistemas externos que interactan con el primero, por lo tanto son muy tiles
para describir funcionalidades a varios tipos de usuarios y con muchas interfaces.
II.
PARA QU SIRVEN LOS CASOS DE USO?
Los casos de uso son tiles para capturar requerimientos, ayudar a definir la
arquitectura, establecer las pautas para el diseo y las pruebas funcionales. Los CU son
una gua de los elementos que sern incluidos en los documentos de usuarios para las
aplicaciones, as como la forma en como stos deben ser empleados. Los CU tambin
establecen las bases para los protocolos de comunicacin entre aplicaciones y el diseo
de las interfaces grficas, entre otros.
La validez de los casos de uso viene dada cuando los usuarios e involucrados del
sistema aceptan el funcionamiento propuesto en los CU, siempre que la redaccin de los
mismo sea buena, no dejando cabida a ambigedades.
Entonces los casos de uso deben ser tiles y ofrecer valor tanto al equipo de usuarios e
involucrados como a los desarrolladores del proyecto.
III.
QU ES UN MODELO DE CU Y QUE SON LOS CU?
Los casos de uso describen secuencias de acciones que realiza un sistema y que lleva a
un resultado de valor a un actor especfico.
Un modelo de CU est compuesto por dos partes, un diagrama (grfico) y una parte
textual. El diagrama muestra las relaciones entre actores y casos de uso, as como las
relaciones entre los CU y entre actores en caso que existan . La parte textual muestra
la descripcin escrita en lenguaje natural que narra los pasos y dems caractersticas del
caso de uso.
IV.
QU SON LOS ACTORES Y CMO IDENTIFICARLOS?
Actor es algo o alguien fuera del Sistema que interacta con el Sistema.
Un actor especifica un rol que alguna entidad externa adopta cuando interacta con el
sistema directamente. Puede representar un rol de usuario o un rol jugado por otro
sistema o hardware que toca la frontera del sistema.
La siguiente es la lista de preguntas que permiten identificar a los actores que
interactuarn con el Sistema:
Quin o qu utiliza el Sistema?
Qu roles toman en la interaccin?
Quin toma informacin del Sistema?
Quin provee informacin al Sistema?
En qu parte de la compaa es utilizado el Sistema?
Quin instala, soporta y mantiene el Sistema?
Quin inicia y termina la ejecucin del sistema?
Qu otros sistemas utilizan el Sistema?
Ocurre algo en algn momento especfico?
La siguiente es la tabla que describe a los actores del sistema. El cdigo del actor
reseado como ACT.# se refiere al prefijo ACT. Seguido por el nmero de actor
8
asignado. La descripcin se refiere a una breve resea del rol del actor para el sistema y
las fuentes son los involucrados del negocio que ayudaron a definir y describir al actor.
Actor
Descripcin
Responsabilidades
ACT.# Nombre del Actor

<descripcin del actor>
<Responsabilidad 1>
<Responsabilidad 2>
Fuentes
<Stakeholders que identificaron y contribuyeron a definir al actor>
V.
CMO SE HACE EL DIAGRAMA DE CU?
El diagrama de CU ofrece la visin global que cuenta lo que hay afuera del sistema y lo
que hay adentro del sistema. Esto es, especifica las fronteras del sistema.
El aspecto de diagramas de casos de uso para sistemas batch vara con respecto a los
empleados para interfaces con usuarios.
El diagrama de CU no debe reflejar ni el flujo de control ni el flujo de datos, sino de
asociaciones que son canales de comunicacin.
Los casos de uso reflejan las relaciones entre los actores y los casos de uso.
Cuando la comunicacin es iniciada por el actor, la relacin de comunicacin contiene
una flecha hacia el lado del CU. Si no la contiene entonces el CU es quien solicita al
actor de la interaccin. Que un sistema invoque a un actor para alguna funcin solo
ocurre con el caso de actores no humanos (otros sistemas), y nunca ocurre que el CU
por s solo invoca al actor, siempre tiene que haber un actor que solicite su activacin,
considere que si esto no ocurre, probablemente lo que Ud. est tratando de modelar no
sea un CU. Arlow y Neustadt sugieren la incorporacin de un actor llamado tiempo para
cuando un CU es disparado no por la interaccin directa de un actor sino cada cierto
perodo de tiempo, ejemplo, CU.1 Recolectar informacin de campo: Breve
descripcin Cada 5 minutos el sistema dispara automticamente este CU que se
comunica con los dispositivos de campo para solicitar informacin.
VI.
CMO IDENTIFICAR LOS CASOS DE USO?
La siguiente es la lista de preguntas que permiten identificar los casos de uso dentro de
las fronteras de un sistema:
9
Qu funciones del sistema son requeridas por un actor especfico?
El sistema guarda o recupera informacin? Si es as Qu actores

disparan esta accin?
Qu ocurre cuando el sistema cambia de estado? Algn actor es

notificado?
Algn evento externo afecta al sistema? Qu notifica el sistema

respecto de estos eventos?
VII.
El sistema interacta con algn sistema externo?
El sistema genera algn reporte?
CMO ESPECIFICAR CASOS DE USO?
La especificacin de los casos de uso se refiere a la descripcin de cada una de las

partes definidas para lograr su descripcin completa. En la organizacin, la
especificacin de los Casos de Uso se har bajo el formato presentado a continuacin.
El siguiente cuadro muestra las partes y las indicaciones bsicas para iniciar su
redaccin.
Caso de Uso
Fuentes
Actor
Descripcin
Flujo bsico
CU.1 XX
<Stakeholders que proporcionaron informacin de esta funcionalidad>
Act.# <nombre de los actores> [(<Pseudnimos>)] [ secundario]
<Descripcin del caso de uso>
1. Ttulo del paso
Descripcin del paso.
2. Ttulo del paso
Flujos alternos
Descripcin del paso.

1. Ttulo del FA
Descripcin del FA
2. Ttulo del FA
Pre-
Descripcin del FA.

1. Ttulo del Precondicin
condiciones
Post-
Descripcin del PRC

1. Ttulo del Postcondiciones
10
condiciones
Requerimiento
Descripcin de la PTC
1. Ttulo del requerimiento
s trazados
Puntos de
Descripcin del requerimiento o porqu se enlaza a l desde este caso de uso

1. Ttulo del punto de inclusin
inclusin
Puntos de
Descripcin del punto de inclusin

1. Ttulo del punto de extensin
extensin
Notas
Descripcin del punto de extensin

1. Ttulo de la Nota
Descripcin de la nota
1. Caso de Uso
El nombre del CU debe comenzar por un verbo y ser lo ms corto posible,
pero que a su vez, describa lo que el CU hace. El nombre del CU debe
indicar el valor u objeto que genera para el actor. El nombre del CU
comienza por su identificacin CU. # Donde # es el nmero asignado a este
CU.
2. Fuentes
Son las personas que conocen del negocio, y las que proporcionan
informacin para la descripcin de la funcionalidad.
3. Actores
Los actores que interactan directamente con el sistema, tanto los primarios
quienes inician el CU, como los secundarios que interactan con el sistema
luego que este ha iniciado. Cuando se nombran los actores en la seccin de
actores del CU se coloca el cdigo asignado en la seccin de actores ejemplo
Act.1. En caso de haber actores segundarios, el CU debe indicar cuales son
secundarios, el resto se asumen primarios, de lo contrario se asume que todos
son primarios. Los actores secundarios se les coloca luego del pseudnimo
un guin y la palabra secundario en letra itlica.
El nombre del actor puede contener al lado una lista de pseudnimos, estos
son utilizados en el CU para describir su funcionamiento con el empleo del
pseudnimo en vez del nombre del actor (o rol) que puede ser muy largo. El
pseudnimo tambin puede ser empleado en forma de lista de actores, si un
pseudnimo est indicado en varios actores, entonces la referencia al
11
pseudnimo en el detalle del CU har indistinta la sustitucin por cualquiera

de los actores.
4. Descripcin
Es un prrafo que resume el objetivo del caso de uso. Sin dar detalles del
cmo, la descripcin del caso de uso resume todo lo que el caso de uso hace,
que es el valor que da al actor (o actores) primario, as como la necesidad de
la existencia de actores secundarios, para los casos que aplique.
Ejemplo. El caso de uso permite al Administrador crear, modificar y borrar
usuarios en el sistema El caso de uso permite al Cliente obtener la
informacin sobre su estado de cuenta del Sistema de Manejo de Clientes.
5. Flujo bsico
El flujo bsico (FB) describe los pasos que se sucederan en el escenario del
mundo perfecto o del da feliz. El flujo bsico es un camino simple, sin
ramificaciones y en l suelen hacerse una serie de asunciones, las
alternativas a estos presuntos son los flujos alternos.
Cada paso del flujo bsico contiene
1) un nmero de paso o flujo,
2) ttulo del paso
3) la descripcin del paso.
La numeracin del paso es un consecutivo que inicia con el nmero 1 en el
primer paso. El ttulo del paso representa un resumen de lo que el paso
realiza, suele ser una oracin que inicia con un verbo en estado activo Ej.
crear usuario, buscar datos de clientes mayores. La descripcin del paso
contiene el detalle de lo que se espera que ocurra en el paso. Dependiendo de
la complejidad del sistema o los datos manejados, los pasos pueden tener
varios intercambios, ejemplo:
3.
Crear cdigo de movimiento manual

12
El sistema solicita al Administrador de Tablas de O/S el valor del cdigo de

movimiento y una descripcin asociada a ese cdigo. El Administrador de Tablas de
O/S indica al sistema los valores para estos campos y le indica al sistema guardar la
informacin. El caso de uso termina.
Tabla 1. Listado del ltimo paso de un CU
Es obligatorio que cada paso contenga el nmero del paso y su ttulo, la
descripcin puede ser opcional en casos de uso cuyos pasos se limitan a la
oracin del ttulo.
Los pasos de los flujos bsicos no contienen, nunca, referencias a los flujos
alternos ni a flujos bsicos.
La descripcin del primer paso del FB indica que actor comienza el flujo y
cul es el disparador del mismo, ejemplo El caso de uso inicia cuando el
Administrador de Tablas de O/S indica al sistema la opcin de visualizar
rdenes de servicio.. El ltimo paso del flujo bsico cierra indicando que el
caso de uso termina, o finaliza, ejemplo ver Tabla 1.
6. Flujos alternos
Los flujos alternos (FA) se definen como flujos independientes, no como
subflujos, permitiendo hacer que un flujo alterno aplique de manera global a
todo el CU, o a varios flujos bsicos u alternativos. Mantener los FA de
forma plana facilita su lectura, su escritura y su comprensin. El formato
utilizado emplea una seccin separada para los flujos alternos. Los flujos
alternos pueden hacer referencia a flujos bsicos u otros flujos alternos.
Todos los FA deben indicar (en este orden):
Dnde comienzan? Desde donde parte este FA, puede ser un FB o

un FA.
Qu los dispara? Que hace que este FA inicie
Qu sucede? Lo que pasa cuando el FA es invocado, anlogo al FB.

13
A dnde regresa? Una vez que termina de ejecutarse el flujo

alterno, A dnde regresa la ejecucin del caso de uso?
El siguiente es un ejemplo de un FA.
1.
Excepcin: No se encontraron O/S para el criterio aplicado
En el paso 2 del flujo bsico el resultado de la bsqueda no arroja ningn

resultado. El sistema muestra al Usuario un mensaje alertando sobre tal situacin.
El usuario acepta el mensaje. El caso de uso retorna al paso 1 del flujo bsico con
los valores anteriormente empleados para la bsqueda.
2.
Mostrar la lista de mensajes asociados a una O/S
En el paso 2 o el paso 3 del flujo bsico el Usuario selecciona ver la lista de

mensajes asociados. El sistema muestra una tabla con todos los mensajes
contenidos por la O/S. El caso de uso retorna al paso en que fue llamado.
Tabla 2. Listado del ltimo paso de un CU
Al igual que los FB, los FA cuentan con un nmero de flujo, un ttulo y una
descripcin. El nmero de flujo es un secuencial que se inicia en 1 con el
primer FA del CU. El ttulo describe la accin que realiza FA y se escribe con
las mismas normas que en los FB, sin embargo, los FA que indican
excepciones se presentan de forma diferente, se indica que son excepciones y
el comportamiento que es errneo, no se escriben comenzando con verbo en
forma activa. La descripcin debe contener la respuesta a las cuatro
preguntas presentadas en el mismo orden en que se encuentran listadas.
7. Pre-condiciones
Las precondiciones son elementos opcionales de los CU. Cada precondicin
listada tiene: 1) nmero, 2) ttulo 3) descripcin (opcional). El nmero es un
consecutivo. El ttulo debe resumir muy brevemente la condicin. La
descripcin puede dar detalles de cmo la condicin es evaluada, o el rango
de valores que pueden ser aceptados para la condicin.
14
Bittner y Spence hacen nfasis en que las precondiciones no son eventos que
disparan o activan el CU en el sistema. Sin embargo son declaraciones en las
cuales el caso de uso puede comenzar. Las precondiciones son
necesariamente ciertas para que el CU pueda comenzar, pero no suficientes.
El CU slo puede ser comenzado por el actor cuando las precondiciones son
ciertas.
Las precondiciones no son evaluadas en los FB ni los FA pues se asumen
como ciertas. Si las precondiciones aplican para todos los CU del sistema
entonces es un requerimiento y no debe indicarse.
Para hallar precondiciones formlese las siguientes preguntas:
En qu estado debe encontrarse el sistema para que el CU se pueda

disparar?
Qu elementos deben estar presentes para que el CU pueda iniciar?
Cules son los supuestos asumidos?
Qu restricciones aplican al empleo del CU por los actores?
Note que las precondiciones son opcionales de no existir no agregue

precondiciones que no aporten a la explicacin del CU. Evite precondiciones
como El usuario debe estar vivo o La mquina debe estar encendida y el
sistema debe estar activado y funcionando, pues no agregan valor al diseo
y son obvias.
8. Post-condiciones
Las postcondiciones son elementos opcionales de los CU. Los elementos y
patrones para describir postcondiciones son iguales a los de las
precondiciones.
Bittner y Spence explican que las postcondiciones deben ser ciertas cuando
el CU termina, sin importar el curso de eventos que se sucedieron. Si algo
15
puede fallar Ud. debe cubrirlo en las postcondiciones para describir el estado
en el que el sistema se encontrar cuando el CU se completa.
Las postcondiciones son importantes puesto que dan las luces sobre las
condiciones que garantizan que siempre que termine el CU el sistema queda
en un estado vlido y los datos inherentes (en caso de existir) se encuentran
consistentes. Las postcondiciones son igualmente tiles para verificar que las
pruebas que se realicen sobre este CU aseguren que estas condiciones se
darn al salir, sea cual fuere el curso de acciones tomadas.
Para hallar postcondiciones formlese las siguientes preguntas:
En qu estado debe quedar el sistema luego que termina el CU?
Qu debe garantizarse cuando termine para que el sistema no quede

inconsistente o no utilizable?
Cules son las nicas condiciones vlidas en las que puede acabar
una ejecucin del CU?
Armour y Miller aclaran que tanto las precondiciones como

postcondiciones se refieren a estados del sistema, no del ambiente fuera
del mismo, ello debido a que las condiciones del ambiente no se modelan
dentro del sistema.
9. Requerimientos trazados
Los requerimientos son formas de enlazar los CU o especificaciones
funcionales con el resto de las especificaciones no funcionales. Estas
especificaciones o requerimientos deben encontrarse en el repositorio de
requerimientos con la informacin completa de los atributos definidos.
Aunque la trazabilidad con los requerimientos especiales se da por
demostrada en el mapa de trazabilidad de los requerimientos, el tenerlos
presentes en el CU hace ms fcil su lectura para el diseador e constructor.
Para los requerimientos se debe especificar el nmero, el ttulo y la
descripcin del requerimiento (opcional). El ttulo puede contener el cdigo
16
del requerimiento y el ttulo del mismo segn la definicin que se establezca

para las especificaciones no funcionales del sistema. La descripcin puede
omitirse puesto que se asume que la misma se encuentra en el repositorio de
requerimientos, sin embargo se pueden dar indicaciones adicionales de cmo
el CU debe cumplir con este requerimiento.
10.
Puntos de inclusin y extensin
Los puntos de inclusin son los enlaces para incluir un funcionamiento

especfico del CU que es empleado por ms de un CU.
Los puntos de extensin son los enlaces que permiten extender la
funcionalidad de un CU en un punto especfico de flujo bsico.
Para determinar cundo colocar y qu colocar en un punto de inclusin o un
punto de extensin ver la seccin de Cmo estructurar Casos de Uso?.
11.
Notas
Las notas son elementos opcionales muy importantes de los CU pues reflejan
el anlisis y la comprensin del funcionamiento del sistema, ms all de la
descripcin de las interacciones entre los usuarios. Las notas en los CU se
utilizan para plasmar explicaciones, detalles sobre la informacin, formatos
de archivos que ya se encontraban establecidos y otros acuerdos con los que
la aplicacin debe cumplir. Es importante que todas las notas se encuentren
referenciadas con algn elemento del Caso de Uso, ejemplo la descripcin, el
FB, el FA, las referencias justifican la existencia de la nota.
Las notas son caractersticas muy importantes de los CU puesto que permiten
capturar conocimientos propios del sistema que no se est describiendo, que
son tiles a la hora de hacer el diseo y la implementacin, sin embargo, no
representan una funcionalidad propia del CU que se est especificando.
Recuerde que en su rol de analista de requerimientos, su misin es plasmar la
mayor cantidad posible de detalle posible, ello debido a que es Ud. quin se
encuentra ms cercano a los funcionales que puedan estar revelando la
informacin.
17
12.
Consideraciones a la hora de escribir un Caso de Uso
La siguiente es una serie de consideraciones que deben ser tomadas a la hora

de escribir o especificar casos de uso.
a) Empleo del SI Condicional
Referido en ingls como using if-statement. Ni los flujos bsicos ni los
alternos deben contener SI condicionales, en esencia, los casos de uso no
son algoritmos, sino que describen la interaccin entre los actores y el
sistema. Para hacerlos no ambiguos, los casos de uso asumen un camino
ideal y el resto son caminos alternativos.
INCORRECTO
1.
Modificar el horario
Si el usuario ya tena un horario en su cuenta entonces

proceder a mostrar el detalle del horario. Si no, mostrar un
mensaje que indica que el usuario no tiene horario asignado.
CORRECTO
2.
Modificar el horario
El sistema muestra el detalle del horario.

NOTA: El sino representa un flujo alterno
Tabla 3. Empleo del si condicional
b) Opciones de los actores
Referido en ingls como actor choices o avoid CRUD use cases.
Tanto en flujos bsicos, principalmente, como en flujos alternos, un paso
puede contener varias alternativas. El paso debe presentar al lector todas
las alternativas posibles para el actor y tomar una de ellas, la que
corresponde al da feliz. El resto de las opciones correspondern a flujos
alternos del caso de uso. El listado de las opciones debe ser completo, no
debe utilizarse el etc. pues es un indicio de elementos que no han sido
especificados y dejarn al diseador la opcin para que los sustituya por
cualquier cosa. El siguiente ejemplo muestra el uso de opciones de los
actores.
18
3.
Crear cdigo de movimiento manual
El sistema permite al Administrador de Tablas de O/S crear, modificar o borrar

cdigos de movimiento manual. El Administrador de Tablas de O/S indica al
sistema crear cdigo de movimiento manual. El sistema solicita al Administrador
de Tablas de O/S la informacin de cdigo descripcin del cdigo. El
Administrador de Tablas de O/S suministra los valores para estos campos y le
indica al sistema guardar la informacin. El caso de uso termina.
Tabla 4. Opciones de los actores
c) Mostrando iteraciones
Las iteraciones son descritas en el caso de uso de manera plana, no se
debe escribir en forma de algoritmo con pasos, sino de forma descriptiva.
El siguiente es un ejemplo del uso de iteraciones.
1.
Seleccionar O/S
El sistema muestra la lista de las rdenes de servicio que aplican segn los
criterios de bsqueda seleccionados por el Usuario. Para cada elemento de la lista
el sistema muestra el Cdigo de movimiento, el estatus de la Orden, la fecha de la
orden, el tipo de error, el nmero de la orden de servicio, la interfaz que origin la
O/S, si la orden ha sido marcada para ser archivada, un indicador que especifica
si la O/S tiene Formato 2000 asociado y un indicador que especifica si la O/S tiene
mensajes asociados. El Usuario puede visualizar el F2K asociado a la O/S (en caso
de contenerlo) o la lista de mensajes asociados (en caso de contenerlos). El Usuario
selecciona visualizar el F2K asociado.
Tabla 5. Uso de iteraciones
d) Secuencias de eventos y eventos opcionales

A la hora de especificar secuencias de eventos, debe considerarse que no se
indiquen secuencias que no son requeridas. Cada paso en el flujo bsico
indica un orden, en el cual los eventos deben ocurrir, sin la posibilidad
19
(explicita) de hacerse en otro orden. En el caso en que esto ocurre, se deben

especificar los eventos como parte de un mismo flujo o, de forma explcita,
de que forma los eventos pueden ser ejecutados en otro orden. El siguiente
ejemplo muestra los pasos en un flujo bsico que indican secuencias que no
son requeridas y dos alternativas para resolverlas.
Secuencia no
requerida. N
o hay razn
para solicitar
informacin
de la tarjeta
de crdito en
este orden.
1.
Introducir informacin de compra
El CU inicia cuando el usuario indica crear una solicitud para la

venta de un tem. El sistema solicita al usuario la informacin del
cliente: nombre, apellido, CI, direccin y telfono; la cantidad de
productos a incluir en el pedido y la categora de precios en la que se
encuentra el cliente. El usuario indica al sistema la informacin
solicitada e indica validar la informacin.
2.
Validar informacin de compra
El sistema verifica que todos los datos solicitados tengan

informacin, y determina si el cliente ya se encuentra registrado en
el sistema. El sistema determina que todos los datos suministrados
son correctos y que el cliente no se encuentra registrado. El sistema
solicita al usuario la confirmacin del pedido.
3.
Confirmar la informacin de compra
El sistema presenta al usuario todos los datos suministrados en

referencia al cliente, el pedido y la lista de precios solo en forma de
lectura. El usuario puede confirmar la compra o indicar nuevos
valores para este campo. El usuario confirma los datos.
4.
Indicar informacin de tarjeta de crdito
El sistema solicita al usuario la informacin de la tarjeta de crdito

del cliente: banco, tipo, nmero, fecha de expiracin, cdigo de
20
seguridad y nombre en la tarjeta de crdito. El usuario indica todos

los datos y le indica al sistema realizar la compra.
5.
Crear solicitud de compra
El sistema crea la orden de compra con los datos suministrados y

realiza la transaccin con el banco. El banco autoriza la compra.
6.
Presentar resultado de la transaccin
El sistema muestra al usuario un mensaje indicando que la

transaccin ha sido realizada de forma exitosa, presenta los datos de
la compra y el detalle de los elementos vendidos. El sistema indica al
usuario que entregue el pedido.
Alternativa
1.
1. La
solicitud
de
informacin
de tarjeta de
crdito
no
requiere
validacin.
El CU inicia cuando el usuario indica crear una solicitud para la venta de

un tem. El sistema solicita al usuario la informacin del cliente: nombre,
apellido, CI, direccin y telfono; la cantidad de productos a incluir en el
pedido y la categora de precios en la que se encuentra el cliente; y la
informacin de tarjeta de crdito del cliente banco, tipo, nmero, fecha
hacerse luego
de
Introducir informacin de compra
la
de expiracin, cdigo de seguridad y nombre en la tarjeta de crdito. El

usuario indica al sistema la informacin solicitada e indica validar la
informacin.
2.
El sistema verifica que todos los datos solicitados tengan informacin, y

determina si el cliente ya se encuentra registrado en el sistema. El
sistema determina que todos los datos suministrados son correctos y que
el cliente no se encuentra registrado. El sistema solicita al usuario la
confirmacin del pedido.
3.
21
El sistema presenta la usuario todos los datos suministrados en

lectura. El usuario puede confirmar la compra o indicar nuevos valores
para este campo. El usuario confirma los datos.
4.
El sistema crea la orden de compra con los datos suministrados y realiza

la transaccin con el banco. El banco autoriza la compra.
5.
El sistema muestra al usuario un mensaje indicando que la transaccin

ha sido realizada de forma exitosa, presenta los datos de la compra y el
detalle de los elementos vendidos. El sistema indica al usuario que
entregue el pedido.
Alternativa
2. El sistema
solicita
al
usuario toda
1.
Iniciar compra
El CU inicia cuando el usuario indica crear una solicitud para la venta de

un tem.
la
informacin
pero
2.
Introducir informacin de usuario
no
indica
el
orden en que
debe
ser
presentada.
El sistema solicita al usuario la informacin del cliente: nombre,

apellido, CI, direccin y telfono.
3.
Introducir informacin de volumen de compra
Caso anlogo El sistema solicita al usuario la cantidad de productos a incluir en el

a
trabajar pedido y la categora de precios en la que se encuentra el cliente. Este
con tabs o paso puede ocurrir en cualquier momento luego de iniciar la compra.
pestaas.
4.
Introducir informacin de tarjeta de crdito
El sistema solicita al usuario la informacin de tarjeta de crdito del

cliente banco, tipo, nmero, fecha de expiracin, cdigo de seguridad y
22
nombre en la tarjeta de crdito. Este paso puede ocurrir en cualquier

momento luego de iniciar la compra.
5.
El usuario indica al sistema la informacin solicitada e indica validar la

informacin. El sistema verifica que todos los datos solicitados tengan
informacin, y determina si el cliente ya se encuentra registrado en el
sistema. El sistema determina que todos los datos suministrados son
correctos y que el cliente no se encuentra registrado. El sistema solicita
al usuario la confirmacin del pedido.
6.
El sistema presenta la usuario todos los datos suministrados en

lectura. El usuario puede confirmar la compra o indicar nuevos valores
para este campo. El usuario confirma los datos.
7.
El sistema crea la orden de compra con los datos suministrados y realiza

la transaccin con el banco. El banco autoriza la compra.
8.
El sistema muestra al usuario un mensaje indicando que la transaccin

ha sido realizada de forma exitosa, presenta los datos de la compra y el
detalle de los elementos vendidos. El sistema indica al usuario que
entregue el pedido.
Tabla 6. Manejo de secuencia de eventos
Si una secuencia de eventos se presenta, el diseador o desarrollador asumir que sta
es la forma correcta de realizar las actividades, sin dejar posibilidad a otras formas de
realizar la secuencia de pasos.
e) Nivel de detalle esperado
23
Se espera que el nivel de detalle del caso de uso no contemple detalles

sobre la interfaz, ni la arquitectura, ni el procesamiento interno de los
datos cuando estos no sean concernientes a los involucrados. Los casos
de uso presentan detalles de requerimientos, no de diseo, otras
herramientas son utilizadas para el diseo, como el prototipo. Esta
separacin se realiza para hacer ms fcil de entender los CU.
El caso de uso debe contener el detalle justo y necesario para explicar los
intereses (requerimientos funcionales) del involucrado y entregar el
sistema.
El nivel de detalle esperado para el caso de uso es el necesario para guiar
al diseador en la forma en que se desea presentar los datos y expresar
los resultados, en ningn momento se debe limitar al diseador en este
aspecto. En caso de existir restricciones o requerimientos de algn otro
tipo que limiten las opciones, los mismos deben ser referenciados en la
seccin de restricciones o requerimientos especiales segn el caso.
Las siguientes palabras, como regla general, indican un nivel de detalle
incorrecto: Base de Datos, archivo, etc., botn, HTML, http, SMTP, radio
button.
Dnde colocar informacin necesaria sobre requerimientos de interfaz o
arquitectura?
El documento que contiene los requerimientos debe contener esta
informacin. Es deber del analista de requerimientos tomar en
consideracin todos los requerimientos recolectados y presentarlos de
manera total y consistente para que el diseador y desarrollador los
puedan tener en cuenta a la hora de hacer su trabajo. Los requerimientos
pueden ser presentados en el listado de requerimientos especiales.
f) Creatividad
Debe recordar que Ud. Est escribiendo flujos que afectarn la
experiencia del usuario en la herramienta, y que eso que se defina ser
24
validado con el usuario. A la hora de escribir, el CU hgase la pregunta

Qu es lo que el sistema debera hacer mejor? Qu hay detrs de los
requerimientos? A qu estn acostumbrado los usuarios? Dnde el CU
genera valor? Las necesidades de los usuarios quedarn totalmente
satisfechas con la solucin propuesta? Qu otra cosa se podra hacer
para al sistema sea ms usable?
Recuerde que cuando escribe los CU, Ud. Est escribiendo como el
sistema va a trabajar y como la experiencia del usuario se ver afectada
por el uso del sistema.
Sin embargo, debe tomar en cuenta que si bien el CU debe agregar valor
a los procesos que el actor realizar con la herramienta, el mismo debe
poderse implementar en los tiempos solicitados, que el analista de
requerimientos no debe introducir requerimientos que no agreguen valor
a la cadena.
Especificaciones fciles pueden hacer sistemas fciles de utilizar.
Especificaciones complicadas, harn, con toda seguridad, sistemas
complejos, lo cual incrementa la oportunidad de rechazo del sistema por
los usuarios, agregando a todo el equipo la posibilidad de fracaso, pues
su xito est atado al xito de la experiencia que los usuarios con el uso
del sistema que se est analizando.
g) Nombre de los actores en todas las secciones del caso de uso
Cuando el CU especifica los pasos que el actor est realizando en el
sistema, el CU debe indicar claramente quin es el actor, no deben
emplearse expresiones como: El actor hace. en vez debe
especificarse el nombre completo del actor el pseudnimo. Ntese que el
pseudnimo puede ser el mismo en varios CU para hacer referencia a
actores diferentes, entonces se debe estar claro que el alcance del
pseudnimo se restringe, de manera estricta, al CU.
Los nombres de los actores siempre comienzan en mayscula y todas las
palabras que los componen comienzan en maysculas, como el formato
25
de cualquier nombre de persona (menos los artculos, ejemplo: de, la, el,
para, del, con, etc.
VIII.
CMO ESTRUCTURAR CASOS DE USO?
La estructuracin de los CU es un paso posterior a la construccin del modelo inicial del

modelo de CU. La primera construccin del modelo de CU nunca incluye la
estructuracin, ello ocurre producto de la especificacin cuando se comienza a ver que
los casos de uso tienen definiciones semejantes, compartidas o dependientes. La
estructuracin de CU busca simplificar la explicacin del funcionamiento del sistema y
es el primer acercamiento para contemplar la reutilizacin y la modularizacin en la
definicin del diagrama de clases. La estructuracin de CU consta de cuatro casos
posibles que se listan a continuacin, la explicacin contiene la repercusin el modelo
de clases resultantes.
1. Generalizacin de actores
La generalizacin de actores permite al analista identificar un rol que hace
factor comn de las funcionalidades de varios usuarios. Si el actor A1 puede
hacer {UC1, UC2 y UC3} y el actor A2 puede hacer {UC1, UC3 y UC4}
entonces se puede crear un actor A3 que puede hacer {UC1 y UC3}, que los
actores A1 y A2 extiendan de A3, que A1 pueda hacer {UC2} y que A2
pueda hacer {UC4}. Grficamente:
2. Generalizacin de casos de uso

La generalizacin de CU, al igual que en los actores, permite extraer factor
comn de dos o ms casos de uso que comparten caractersticas. En la
generalizacin de CU existe un CU padre (o base, o general) y un CU hijo
26
que es una especializacin del base. En estos casos el hijo hereda todas las
caractersticas del padre, puede agregar nuevas caractersticas, y puede
modificar (sobrescribir) caractersticas del padre excepto por las relaciones y
los puntos de extensin.
Cuando un CU es hijo de otro, en el nombre debe indicar cul es su padre,
indicando: CU.1.2 Crear libro child . No es lgico el empleo de
herencia mltiple en CU, por lo cual no est permitido. En la generalizacin
de CU la numeracin se modifica para indicar cul es el padre del caso de
uso, en el ejemplo anterior el CU.1.2 Crear libro es hijo del CU.1 Crear
producto, adicionalmente se agrega el indicador child para indicar que es
la especializacin de un caso de uso base. En la descripcin del CU se indica
cul es su CU base y que valor agrega sobre el mismo.
La especializacin permite establecer en el padre un comportamiento general
y el cada hijo una variacin del comportamiento general, variando mltiples
elementos del CU, ejemplo flujos bsicos, alternos, precondiciones, etc. para
lograr un resultado de valor. Un CU base puede ser especializado por
mltiples veces.
Grficamente, la generalizacin de CU se representa como a continuacin.
Note que CU.2 y CU.3 son los hijos y CU.1 es el padre.
3. Extensin de casos de uso

La extensin de CU se utiliza para agregar nuevas funcionalidades o
comportamientos a un CU. Cuando se extiende un CU, el CU base indica el
punto en los que se hace la extensin.
27
Los puntos de extensin en la especificacin del CU debe incluir, un ttulo que

es el nombre del CU que se extiende, y un texto de indica: 1) el paso del flujo
bsico que se extiende con esta funcionalidad o grupo de funcionalidades note
que los puntos de extensin nunca son sobre los flujos alternos 2)
opcionalmente la condicin que establece que esta funcionalidad est disponible
para el actor, y 3) la accin que realiza el actor para que el flujo de eventos se
curse hacia el CU extendido.
Las extensiones se utilizan para:
Describir caractersticas que son opcionales al comportamiento bsico

del sistema.
Describir errores o excepciones complejas de considerarlas en el CU

base complicara su comprensin.
Personalizacin de requerimientos para resolver necesidades especficas

del cliente.
Mejorar la gestin del alcance y la configuracin de las soluciones

entregadas.
4. Inclusin de casos de uso

La inclusin de CU se utiliza para extraer como factor comn una serie de
pasos que son repetidos en diferentes CU, permitiendo incluirlos mltiples
veces sin necesidad de volverlos a escribir.
Cuando hay inclusiones, el CU base no est completo sin sus inclusiones, sin
embargo, el CU inclusin puede o no ser completo por s solo.
Los puntos de inclusin se emplean en los CU base para indicar el punto
exacto donde se incluye su funcionamiento, la interpretacin es que una vez
que el punto de inclusin es alcanzado, el control pasa al CU de inclusin,
luego que este termina, la ejecucin retorna al CU base.
28
Grficamente, la inclusin de CU se representa como a continuacin. Note

que CU.1 y CU.4 incluyen la funcionalidad en CU.5
5. Cmo interactan los CU

Bittner explica que los CU no se comunican entre s de forma directa, recuerde
que los CU son solo descripciones. La nica forma de interactuar entre ellos es a
travs del estado del sistema que describen. Los CU pueden chequear el estado
del sistema en cualquier momento o esperar a que un estado cambie, as como
depender de un estado empleando precondiciones. No hay forma directa de
relacionar CU, y esto no es una debilidad. No hay nada en la definicin de CU
que permita la secuenciacin entre diferentes CU de forma directa. Cada CU se
espera que sea independiente de otros CU. Los CU son secuencias
independientes de comportamientos que producen un resultado de valor a un
usuario del sistema. La necesidad de hacer que un CU llame a otro es,
normalmente, una deficiencia de la definicin del alcance de los CU, en cuyo
caso se recomienda que revise si cada CU se mantiene independiendo y
produciendo un resultado de valor observable para el actor que lo invoca,
generalmente se resuelve agrupando CU en uno solo.
6. Modelos de casos de uso no tienen niveles
Bittner et al explica que los CU expresan lo que los involucrados quieren que el
sistema haga, no como el sistema lo va a implementar. Quienes quieren ver
niveles en CU quieren convertir los CU en instrumentos de anlisis, permitiendo
transparentar lo que se desea que sea la arquitectura del sistema en cuestin.
Los CU ayudan a capturar la descripcin de lo que el sistema debe hacer. Esto es
la expresin del comportamiento que se desea de un sistema. Por lo tanto, el
29
sistema se debe comportar de esta forma independientemente del diseo y la

implementacin que se haga. El valor de los CU se encuentra en hacer que el
comportamiento se exprese de forma simple y sin ambigedades. Mientras ms
se estructura la descripcin ms difcil se hace comprender el comportamiento
deseado.
a) Casos de uso de negocio (CUN)
Para Bittner et al. (2006) los casos de uso pueden ser utilizados para definir
procesos de negocio, en estos casos son llamados casos de uso de negocio
(CUN) o Business Use Cases (BUC), este trmino fue introducido por
Jaccobson. Los actores en el modelo de casos de uso de negocio son externos al
negocio, ellos son clientes, accionistas, proveedores y otras partes que participan
en el negocio en algn tipo de relacin.
Los casos de uso de negocio sirven para clarificar el ambiente en el que un
sistema ser utilizado, ellos pueden ser tiles para:
Clarificar el contexto del sistema y obtener el acuerdo de los

requerimientos
Cuando se estn modelando ms de un sistema para soportar uno o ms

procesos de negocio. En este sentido los CUN especifican el alcance y
las responsabilidades de cada uno de los sistemas.
En la construccin de aplicaciones que sern utilizados por varias

organizaciones. En este caso muestran la flexibilidad de los sistemas para
adaptarse a los procesos de dichas organizaciones.
Para definir sistemas que sern utilizados en nuevas lneas de negocio.
En proyectos complejos de reingeniera.
Los CUN muestran como los procesos son llevados a cabo por personas y los
activos de la organizacin.
30
Es importante aclarar que, as como los CU no explican como el sistema realiza

las operaciones ni la forma de las interfaces con el usuario, los BUC no revelan
detalles de cmo los procesos son implementados por los actores, ni los
artefactos de uso interno del proceso, mas s lo que hacen en el marco funcional.
b) Palabras reservadas
La siguiente es la lista de las palabras que son reservadas para la redaccin del
CU, y en ningn caso debern ser empleadas como parte de las palabras
relacionadas al contexto o negocio al que hace referencia el CU, a menos que se
trate del mismo significado.
UC, CU: Caso de uso
BUC, CUN: Caso de uso de negocio
Actor: Actor del caso de uso
FB: Flujo bsico
FA: Flujo alterno
Sistema: El sistema que se est analizando para este CU, en ningn caso
debe ser utilizado como pseudnimo de un sistema externo.
7. RECOMENDACIONES GENERALES
a) Empleo de estilos del procesador de palabras
Los procesadores de palabras cuentan en la actualidad con manejo de
estilos o formatos preconfigurados de texto. Estos estilos, al igual que
ocurre con los CSS (Cascade Style Sheets) en Web, hacen del documento
un documento mucho ms fcil de escribir y de modificar, puesto que con
modificar el estilo se modifica todo el documento sin tener que
identificar prrafo por prrafo donde se deben cambiar las fuentes,
tamaos, etc.
31
b) Redacciones cortas, concisas y completas

Lo que debes tener en mente es que alguien como t va a leer este
documento para hacer el anlisis, implementar un sistema, escribir la
documentacin, identificar las pruebas y vender el funcionamiento del
sistema, por lo que el documento debe ser:
1) lo suficientemente detallado para que el diseador, programador,
probador y documentalista no deba leer ningn documento no
referenciado desde ste para realizar su trabajo en relacin con el
sistema,
2) lo suficientemente preciso para no aburrir a un usuario a quin se le
explique cmo trabaja el sistema, sino que se obtenga de l el feedback
que permita identificar los cambios necesarios en la fase de redaccin de
CU en vez de cuando se entregue el sistema
32
IX.
CONCLUSIONES:
Los casos de uso describen los intercambios entre el sistema que se est
describiendo y las personas o sistemas externos que interactan con el
primero.
La especificacin de los casos de uso se refiere a la descripcin de cada
una de las partes definidas para lograr su descripcin completa.
La generalizacin de cu, al igual que en los actores, permite extraer
factor comn de dos o ms casos de uso que comparten caractersticas.
En la generalizacin de cu existe un cu padre (o base, o general) y un cu
hijo que es una especializacin del base.
La generalizacin de actores permite al analista identificar un rol que
hace factor comn de las funcionalidades de varios usuarios.
33
X.
BIBLIOGRAFA
1. http://documentos-ayudas-y-trabajos.blogspot.pe/2013/12/los-casos-de-usofichas-ejemplos-de.html
2. https://lsi.ugr.es/~mvega/docis/casos%20de%20uso.pdf
3. https://sites.google.com/site/alfonsoperezr/investigacion/estructuracin-yespecificacin-de-casos-de-uos
4. http://sedici.unlp.edu.ar/bitstream/handle/10915/18410/Documento_completo.pd
f%3Fsequence%3D1
5. http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/416
6. Curso de Anlisis de Requerimientos con Casos de Uso (ARCU) IBM-ISCA.
7. Recomendaciones en Writing good Use Cases de Jim Heumann, Evangelista de
Requerimientos (IBM)
8. J. Arlow, I. Neustatd, (2005). UML 2 and The Unified Proccess. Addison
Wesley. 2da Edicin, Massachusetts, USA
9. K. Bittner, I Spence (2006). Use case modelling. Addison Wesley.
Massachusetts, USA
34

Hoja de Descripción de Casos de Uso

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Hoja de Descripción de Casos de Uso

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVE

Espino Rivera Marcia

Hoja de descripcin de casos de uso

persona. Gracias por ayudarme a

A mis padres por su amor,

A Dios Todopoderoso por darme las

Hoja de descripcin de casos de uso

Agradecer hoy y siempre a nuestras familias por el esfuerzo realizado por

Hoja de descripcin de casos de uso

CUANDO UTILIZAR LOS CASOS DE USO?......................................................5

II. PARA QU SIRVEN LOS CASOS DE USO?........................................................5

QU ES UN MODELO DE CU Y QUE SON LOS CU?....................................6

QU SON LOS ACTORES Y CMO IDENTIFICARLOS?..............................6

V. CMO SE HACE EL DIAGRAMA DE CU?.........................................................7

CMO IDENTIFICAR LOS CASOS DE USO?.................................................8

CMO ESPECIFICAR CASOS DE USO?.........................................................8

Puntos de inclusin y extensin........................................................................15

Consideraciones a la hora de escribir un Caso de Uso.....................................16

Empleo del SI Condicional...............................................................................16

Opciones de los actores.....................................................................................17

Secuencias de eventos y eventos opcionales....................................................18

Nivel de detalle esperado..................................................................................22

VIII. CMO ESTRUCTURAR CASOS DE USO?...................................................24

Hoja de descripcin de casos de uso

Generalizacin de casos de uso............................................................................25

Extensin de casos de uso....................................................................................26

Inclusin de casos de uso.....................................................................................27

Cmo interactan los CU.....................................................................................27

Modelos de casos de uso no tienen niveles..........................................................28

Casos de uso de negocio (CUN).......................................................................29

Empleo de estilos del procesador de palabras..................................................30

Redacciones cortas, concisas y completas........................................................30

Hoja de descripcin de casos de uso

Los CU forman parte de las especificaciones de UML 2.0, as como de metodologas de

Hoja de descripcin de casos de uso

HOJA DE DESCRIPCIN DE UN CASO DE USO

CUANDO UTILIZAR LOS CASOS DE USO?

Los casos de uso son un tipo de requerimientos utilizados para especificar

PARA QU SIRVEN LOS CASOS DE USO?

QU ES UN MODELO DE CU Y QUE SON LOS CU?

Hoja de descripcin de casos de uso

QU SON LOS ACTORES Y CMO IDENTIFICARLOS?

Quin o qu utiliza el Sistema?

Qu roles toman en la interaccin?

Quin toma informacin del Sistema?

Quin provee informacin al Sistema?

En qu parte de la compaa es utilizado el Sistema?

Quin instala, soporta y mantiene el Sistema?

Quin inicia y termina la ejecucin del sistema?

Qu otros sistemas utilizan el Sistema?

Ocurre algo en algn momento especfico?

Hoja de descripcin de casos de uso

ACT.# Nombre del Actor

CMO IDENTIFICAR LOS CASOS DE USO?

Hoja de descripcin de casos de uso

Qu funciones del sistema son requeridas por un actor especfico?

El sistema guarda o recupera informacin? Si es as Qu actores

Qu ocurre cuando el sistema cambia de estado? Algn actor es

Algn evento externo afecta al sistema? Qu notifica el sistema

El sistema interacta con algn sistema externo?

El sistema genera algn reporte?

CMO ESPECIFICAR CASOS DE USO?

La especificacin de los casos de uso se refiere a la descripcin de cada una de las