CASOS DE US1

CASOS DE USO (USE CASE).
¿QUÉ ES UN CASO DE USO?
Un caso de uso es una descripción de los pasos o las actividades que deberán
realizarse para llevar a cabo algún proceso. Los personajes o entidades que
participarán en un caso de uso se denominan actores. En el contexto de ingeniería
del software, un caso de uso es una secuencia de interacciones que se
desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia
un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven
para especificar la comunicación y el comportamiento de un sistema mediante su
interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que
muestra la relación entre los actores y los casos de uso en un sistema. Una
relación es una conexión entre los elementos del modelo, por ejemplo la
especialización y la generalización son relaciones. Los diagramas de casos de uso
se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a
eventos que se producen en su ámbito o en él mismo.
Los más comunes para la captura de requisitos funcionales, especialmente con el
desarrollo del paradigma de la programación orientada a objetos, donde se
originaron, si bien puede utilizarse con resultados igualmente satisfactorios con
otros paradigmas de programación.
DIAGRAMA DE CASOS DE USO:
El diagrama de casos de uso representa la forma en cómo un Cliente (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).
Un diagrama de casos de uso consta de los siguientes elementos:

Actor.

Casos de Uso.

Relaciones de Uso, Herencia y Comunicación.
ELEMENTOS:
ACTOR:
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.
CASO DE USO:
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.
Relaciones:

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 flecha
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.
Ejemplo:
Como ejemplo esta el caso de una Máquina Recicladora:
Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El
sistema debe controlar y/o aceptar:

Registrar el número de ítemes ingresados.

Imprimir un recibo cuando el usuario lo solicita:
a. Describe lo depositado
b. El valor de cada item
c. Total

El usuario/cliente presiona el botón de comienzo

Existe un operador que desea saber lo siguiente:
a. Cuantos ítemes han sido retornados en el día.
b. Al final de cada día el operador solicita un resumen de todo lo depositado en el
día.

El operador debe además poder cambiar:
a. Información asociada a ítemes.
b. Dar una alarma en el caso de que:
i.
Item se atora.
ii.
No hay más papel.
Como una primera aproximación identificamos a los actores que interactúan con el
sistema:
Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede
cambiar la información de un Item o bien puede Imprimir un informe:
Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.
Otro aspecto es la impresión de comprobantes, que puede ser realizada después
de depositar algún item por un cliente o bien puede ser realizada a petición de un
operador.
Entonces, el diseño completo del diagrama de caso de uso es:
NORMAS DE APLICACIÓN:
Los casos del uso son a menudo elaborados en colaboración por los analistas de
requerimientos y los clientes.
Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea de
negocio. Desde una perspectiva tradicional de la ingeniería de software, un caso
de uso describe una característica del sistema. Para la mayoría de proyectos de
software, esto significa que quizás a veces es necesario especificar decenas o
centenares de casos de uso para definir completamente el nuevo sistema. El
grado de la formalidad de un proyecto particular del software y de la etapa del
proyecto influenciará el nivel del detalle requerido en cada caso de uso.
Los casos de uso pretenden ser herramientas simples para describir el
comportamiento del software o de los sistemas. Un caso de uso contiene una
descripción textual de todas las maneras que los actores previstos podrían trabajar
con el software o el sistema. Los casos de uso no describen ninguna funcionalidad
interna (oculta al exterior) del sistema, ni explican cómo se implementará.
Simplemente muestran los pasos que el actor sigue para realizar una operación.
Un caso de uso debe:

Describir una tarea del negocio que sirva a una meta de negocio

Tener un nivel apropiado del detalle

Ser bastante sencillo como que un desarrollador lo elabore en un único
lanzamiento
Situaciones que pueden darse:

Un actor se comunica con un caso de uso (si se trata de un actor primario la
comunicación la iniciará el actor, en cambio si es secundario, el sistema será el
que inicie la comunicación).

Un caso de uso extiende otro caso de uso.

Un caso de uso utiliza otro caso de uso.
Ventajas:
La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la
intención que tiene el actor (su usuario) al hacer uso del sistema.
Como técnica de extracción de requerimiento permite que el analista se centre en
las necesidades del usuario, qué espera éste lograr al utilizar el sistema, evitando
que la gente especializada en informática dirija la funcionalidad del nuevo sistema
basándose solamente en criterios tecnológicos.
A su vez, durante la extracción (elicitation en inglés), el analista se concentra en
las tareas centrales del usuario describiendo por lo tanto los casos de uso que
mayor valor aportan al negocio. Esto facilita luego la priorización del
requerimiento.
Aunque comúnmente se asocian a la la fase de Test de una aplicación, esta idea
es errónea, y su uso se extiende mayormente a las primeras fases de un
desarrollo.
Limitaciones:
Los casos de uso pueden ser útiles para establecer requisitos de comportamiento,
pero no establecen completamente los requisitos funcionales ni permiten
determinar los requisitos no funcionales. Los casos de uso deben complementarse
con información adicional como reglas de negocio, requisitos no funcionales,
diccionario de datos que complementen los requerimientos del sistema. Sin
embargo la ingeniería del funcionamiento especifica que cada caso crítico del uso
debe tener un requisito no funcional centrado en el funcionamiento asociado.
 http://es.wikipedia.org/wiki/Caso_de_uso
 http://users.dcc.uchile.cl/~psalinas/uml/casosuso.html