Un caso de uso debe - diaAnalisis y Diseño Orientado a Objetos

UN CASO DE USO
Es una técnica para la captura de requisitos potenciales de un nuevo sistema o
una actualización de software. Cada caso de uso proporciona uno o más
escenarios que indican cómo debería interactuar el sistema con el usuario o
con otro sistema para conseguir un objetivo específico. Normalmente, en los
casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un
lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin
experiencia junto a los analistas para el desarrollo de casos de uso.
En otras palabras, 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
como reacciona una respuesta a eventos que se producen en el mismo.
Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué).
De forma que al ser parte del análisis nos ayudan a describir qué es lo que es
sistema debe hacer. Los Casos de Uso son qué hace el sistema desde el punto
de vista del usuario. Es decir, describen un uso del sistema y cómo este
interactúa con el usuario.
Notación de caso de uso
Se le llama Actor a toda entidad externa al sistema que guarda una relación
con este y que le demanda una funcionalidad. Esto incluye a los operadores
humanos pero también incluye a todos los sistemas externos así como a
entidades abstractas como el tiempo
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 usa otro caso de uso.
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 computación 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.
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.
MUÑECOS Y PELOTAS
Cuando empiezas a tener un número considerable de casos de uso como el
anterior, no resulta nada fácil situarlos y relacionarlos. Entonces empiezas a
tener la necesidad de una visión general del asunto, y ahora si, es cuando los
diagramas de casos de uso son de utilidad.
En los diagramas de casos de uso los muñecos son los actores y las pelotas
son los documentos de casos de uso. Así que dibujas un muñeco por actor y
una pelota por cada caso de uso (use case) y los enlazas con líneas cuando
haya una relación entre ellos.
Con esto consigues una visión general de cómo los diferentes actores
interactúan con los distintos casos de uno.
ALTO NIVEL
Los lenguajes de programación de alto nivel se caracterizan por expresar los
algoritmos de una manera adecuada a la capacidad cognitiva humana, en lugar
de a la capacidad ejecutora de las máquinas. En los primeros lenguajes de alto
nivel la limitación era que se orientaban a un área específica y sus
instrucciones requerían de una sintaxis predefinida. Se clasifican como
lenguajes procedimentales. Otra limitación de los es que se requiere de ciertos
conocimientos de programación para realizar las secuencias de instrucciones
lógicas. Los lenguajes de muy alto nivel se crearon para que el usuario común
pudiese solucionar tal problema de procesamiento de datos de una manera
más fácil y rápida.
Los casos de uso requieren tener al menos un conocimiento parcial de los
requerimientos del sistema. Un caso de uso es un documento narrativo que
describe la secuencia de eventos de un actor (agente externo) que utiliza un
sistema para completar un proceso. Para especificar los casos de uso en el
lenguaje UML, se utiliza un elipse que encierra el nombre del caso.
LOS CASOS PRIMARIOS: de uso representan los procesos comunes más
importantes. Los casos secundarios de uso representan procesos menores o
raros. Finalmente, los casos opcionales de uso representan procesos que
pueden no abordarse.
UN CASO DE USO EXPANDIDO: muestra más detalles que un caso de uso
de alto nivel. Los casos de uso expandidos son útiles para alcanzar un
conocimiento más profundo de los procesos y los requerimientos.
FLUJO DE EVENTOS PRINCIPAL: Obtener y verificar el número de pedido.
include (validar usuario). Examinar el estado de cada parte del pedido y
preparar un informe para el usuario.
LAS FRONTERAS DEL SISTEMA normalmente son: la frontera
software/hardware de un dispositivo o sistema de cómputo, el departamento de
una organización, la organización entera. Las fronteras son importantes para
definir lo que es interno y externo al sistema. El ambiente externo está
representado exclusivamente por los actores. Las dos siguientes figuras
muestran dos fronteras diferentes para el mismo sistema.
CASOS PRIMARIOS DE USO
Representan los procesos comunes más importantes, como comprar
productos.
CASOS SECUNDARIOS DE USO
Representan procesos menores o raros; por ejemplo, Solicitud de surtir el
nuevo pedido.
CASOS OPCIONALES DE USO
Representan procesos que pueden no abordarse.
Diagramas de Casos de uso