04 detalles casos uso

Los Casos de Uso fueron introducidos por Jacobson en 1992 [Jacobson92]. Sin embargo, la idea de especificar un sistema a partir de su interacción con el entorno es original de Mc Menamin y Palmer, dos precursores del análisis estructurado, que escribieron en 1984 un excelente libro cuya lectura recomendamos . En ese libro, se define un concepto muy parecido al del caso de uso: el evento. Para Mc Menamin y Palmer, un evento es algo que ocurre fuera de los límites del sistema, ante lo cual el sistema debe responder. Siguiendo con nuestro ejemplo anterior, nuestro sistema de ventas tendrá un evento "Cliente hace Pedido". En este caso el sistema deberá responder al estimulo que recibe -el pedido-procesándolo.

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una forma de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado Unificado(UML), define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso. En los conceptos se debe detallar más de un caso de uso para poder identificar qué es lo que hace un caso de uso.

Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario. Por lo tanto los casos de uso determinan los requisitos funcionales del sistema, es decir, representan las funciones que un sistema puede ejecutar.

2009

El propósito de este proyecto es efectuar una recopilación, estudio y análisis de los usos existentes de los casos de uso, de autores reconocidos en el ambiente internacional de la Ingeniería de Software y del desarrollo orientado a objetos. Se analizarán los usos o extensiones de uso que se les dan a los modelos de casos de uso, para lograr una descripción completa y bien definida (formalización) de cada uno de ellos, permitiendo que los modelos de casos de uso sean un eje que acompañe y ayude a todo el proceso de desarrollo de software. Un modelo de caso de uso es una notación que permite especificar y documentar requisitos, planificar el proyecto de software, tales como fechas de entregas, tamaño del software, también ayudan al equipo de diseño, al diseño de interfaz de usuario y de pruebas del sistema. (No más de 200 palabras exponiendo sintéticamente los alcances de la línea de I/D) Palabras clave: casos de uso, análisis, modelos de casos de uso, requisitos, proceso de desarrollo de software.

Herramienta más utilizadas sobre la generación casos de uso.

Descripción Introducción En ingeniería del software, 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 cómo reacciona a eventos que se producen en su ámbito o en él mismo Características Características Los casos de uso evitan típicamente la jerga técnica, prefiriendo la lengua del usuario final o del experto del campo del saber al que se va a aplicar. 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 diez 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 tarea. 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.

Se propone y presenta un método de diseño riguroso de las pruebas de aceptación con cobertura funcional basado en la transformación de los casos de uso en grafos causa efecto que emplean lógica booleana.

¿Cómo describir Casos de uso? Profesores: Gustavo J. Sabio/ Fernando Pinciroli Página 2 de 8 cadena de condiciones atómicas encerradas entre corchetes unidas con operadores lógicos (expresados mediante las etiquetas AND, OR, XOR), debiendo comenzar cada renglón con el operador lógico. Se deberán utilizar también los corchetes para romper la precedencia de cálculo normal de estos operadores; por ejemplo: [[cond1] OR [cond2]] AND [cond3].