CASOS DE USO

Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de los servicios de un sistema. Un caso de uso es una forma de expresar cmo alguien o algo lo usa (no slo personas, pueden ser otros sistemas). Los CU son independientes del mtodo de diseo y el modelo de programacin. Una funcin es un caso de uso si se debe indicar al sistema explcitamente que uno quiere acceder a esa funcin. Requerimientos formales con contexto y estructura que definen claramente el valor resultante. OBJETIVO: Transformar declaraciones deber de los requerimientos funcionales, en grupos que provean valores y contextos observables, organizados desde la perspectiva del usuario. Los CU describen lo que el sistema debe hacer, no cmo debe ser (rpido, confiable, seguro, etc.). Sirven para explicarle a clientes y desarrolladores los requerimientos funcionales con detalle suficiente para aprobar o utilizar los CU en el diseo.

Diferencias entre CU y Eventos

Eventos

Centrados en describir qu hace el sistema cuando el evento ocurre.Atmicos: 1 entrada proceso salidaAlta importancia datos E/S (esenciales)

Casos de uso

Centrados en describir dilogo entre usuario y sistemaPueden agrupar varios eventosDetalle de informacin que se intercambia es secundaria.

Caractersticas de CU

Expresado desde punto de vista del actor. Documentado con texto informal. Describen lo que hace el actor y el sistema cuando interactan. Iniciado por un nico actor. Lista numerada de pasos que sigue el actor en su interaccin. Acotado al uso de una determinada funcionalidad del sistema.

Actor

Agrupacin de personas o sistemas que interactan con el sistema en construccin. Externos al sistema, al identificar actores, se delimita el sistema y se define su alcance. Identificar a los actores es el primer paso en la tcnica de CU. El actor humano es el ms importante porque representa las interacciones ms interesantes y difciles. No puede ejecutar flujos alternativos, slo ejecuta escenarios. ESCENARIO: Caminos a travs de un CU, o serie de pasos y flujos que el actor puede tomar, para lograr un resultado.

Alternativas

Errores o excepciones durante la ejecucin del CU. EJ: Producto discontinuado. Sin sentido por s mismas, fuera del contexto del CU.

Relaciones de Extensin (A VECES)(CU opcional) < - - - - - (CU Principal)

Conjunto de pasos que slo ocurren en algunas oportunidades. EJ: En funcin Ingresando pedido, una opcin que permita presentar nuevos productos disponibles. La excepcin es cuando se interrumpe el CU y ejecuta el CU Presentando nuevos productos. En el ejemplo, el CU Presentando nuevos productos EXTIENDE al CU Ingresando pedido. El dibujo es (CU Ingresando) < - - - - - (CU Presentando) Representan parte de la funcionalidad del CU que no siempre ocurre. Son un CU en s mismas. No necesariamente provienen de un error o excepcin. EJ: Tomar un caf EXTIENE a Cenar. Regla general: Si algo opcional debe ser expresado con ms de un paso, es una extensin, no una alternativa.

Relaciones de Uso (SIEMPRE)(Caso que usa) - - - - - > (Caso que es usado)

Una funcionalidad del sistema es accedida por varios CU. EJ: Buscando producto puede ser accedida desde Ingresando pedido o desde Consultando productos. Concepto de subrutina. Funcionalidad comn. Los casos usados son CU en s mismos. El caso es usado SIEMPRE que el caso que lo usa es ejecutado. Es la diferencia con los opcionales.

Actores y Casos de Uso Abstractos

Un CU que nunca se ejecuta fuera del contexto de otro CU, es abstracto. EJ: Buscando producto del caso anterior. No implementable por s mismo, slo tiene sentido como parte de otros casos. Un actor que participa de este caso, que rene caractersticas comunes a todos los actores de los casos de uso que los usan, es un actor abstracto. Los actores abstractos, son necesarios para no dejar sin actores a los CU abstractos.

Los actores que ejecutan el caso Buscando Datos heredan al actor abstracto. La relacin de herencia puede ocurrir tambin si un actor ejecuta los mismos casos que otro actor, y algunos ms. EJ: Supervisor puede hacer lo mismo que el Vendedor, ms algunas cosas ms (Supervisor hereda Vendedor). Usar la herencia en el anlisis permite evitar redundancia y simplificar especificacin y grficos.

Tipos de Casos de Uso

Esenciales o de Trazo Grueso

Identificando los CU slo a nivel del nombre, ignorando detalles sobre la forma de interaccin. Incluyendo slo las alternativas ms relevantes, ignorando errores. Sin entrar en detalles sobre acciones de la interaccin. EJ: Si la empresa tiene descuentos, no especificar cmo son. Descripcin gruesa de los CU. Permite tomar decisiones sobre qu casos de uso implementar en cada fase, permite analizar los principales aspectos de todos los casos que afectan al diseo.

De Implementacin o De Trazo Fino

Completando todos los detalles que se pasaron por alto en los de trazo grueso.

Casos de Uso Temporales

Casos que se disparan con el paso del tiempo. EJ: Reporte mensual automtico. Se grafica haciendo el valo del caso con lnea punteada. Se debe especificar cul es el momento en el tiempo en que se inicia el caso.

Casos Primarios/Secundarios.

Si no son centrales del sistema, sino que son necesarios para que el sistema funcione sin problemas, son casos secundarios. EJ: Depuracin de pedidos de hace ms de 5 aos.

Proceso de Anlisis

1) Identificar los actores: Para quines es el sistema?2) Identificar los principales CU de cada actor: enunciar los nombres de los CU.3) Identificar nuevos casos a partir de los existentes: aplicar tcnicas de anlisis estructurado, segn 4 situaciones posibles: Variaciones significativas de CU existentesVariaciones en los casos de uso en funcin del actor o del tipo de objeto. EJ: En el caso del sistema que procesa pedidos, hacer las preguntas:1. Existen distintos tipos de cliente? EJ: Clientes locales y del exterior, procesamiento diferente para c/u.2. Existen distintos tipos de pedido, que lleven a acciones distintas? EJ: Distinto tipo de procesamiento segn el material del producto. CU opuestosBuscar la funcin opuesta a la descrita. EJ: De realizar pedido, cancelar pedido. Pensar en la negacin de la accin principal. EJ: Pagar pedido, NO pagar pedido. CU que preceden a casos existentesPreguntar qu debe ocurrir antes de cierto CU. EJ: El cliente, debe ser cliente. CU que suceden a casos existentesPreguntar qu ocurre despus de cierto CU. 4) Crear descripciones de CU de trazo grueso: Documentar los pasos principales, segn definicin de trazo grueso.5) Definir prioridades y seleccionar casos de la primera iteracin: Definir prioridades en 3 categoras: Imprescindibles: Si no se implementan el sistema no sirve. Importantes: Si no se implementan decepcionaran al usuario. Deseables: Se pueden implementar si hay tiempo disponible.6) Escribir los CU de trazo fino y crear prototipos: Profundizar definiciones, preparar prototipo para validar el estilo de interaccin (prototipos son descartables).

Organizacin de la especificacin

Grficos a utilizar

Un grfico de CU no debe mostrar ms de 15 casos.Se puede particionar grficos por actor. Separar casos principales de auxiliares.Graficar las relaciones de uso y extensiones si entran en el diagrama principal. dem para actores abstractos.Si no entran, mostrarlas en otros grficos con todos los CU que usan a otro en un mismo diagrama.Si un CU es utilizado por gran parte de otros casos, evitar mostrarlo en el grfico principal, por la cantidad de flechas.

Secciones (orden sugerido)

1) Propsito del sistema: Para qu se hace el sistema?2) Grficos de CU.3) Descripcin de los CU con sus alternativas.4) Prototipos principales.

Consejos para la redaccin de CU

Respetar el diagrama: representacin grfica + especificaciones textuales. Los actores humanos son los ms importantes. Mantener una tcnica estructural comn, con un nico flujo principal y mltiples flujos alternativos. Colocar referencias en los flujos alternativos: Sentencias simples que indiquen dnde se inicia, y cmo y dnde termina. Los escenarios deben contar la historia completa. Cuidado con sentencias IF: Romper IF en mltiples requerimientos. Especificar las elecciones (opciones) del actor. Alejar el CRUD: Centrarse en lo que el actor realmente quiere hacer, evitar relacionarlo con acciones de Crear, Leer, Actualizar y Borrar (CRUD, Create Read Update Delete). Secuencia de eventos puede ser opcional: Considerar si el orden de los pasos es realmente un requerimiento. Nivel correcto de detalle: No referenciar elementos de la interfaz, por ejemplo clickear en cierto botn. Escribir los CU de una forma que el sistema sea lo ms simple posible para el usuario.

Diagrama de Actividad

Muestra actividades, representando la realizacin de operaciones y las transiciones son disparadas por la finalizacin de estas operaciones. Enfocado en los flujos manejados por el procesamiento interno. Usar en situaciones donde la mayora de los eventos representan la finalizacin de acciones generadas internamente. No adecuado en situaciones de eventos asincrnicos. Caso de uso, centrado en interaccin entre actor y sistema. Diagrama de actividad, centrado en el procesamiento interno del sistema durante el CU. Un CU puede estar acompaado por cero, uno, o ms diagramas de actividad. Se puede construir diagramas de actividad jerrquicos, donde una actividad sea descompuesta en actividades menores.

Accin

Representacin de un estado con una accin interna y una o ms transiciones salientes (eventos de finalizacin).El uso normal de una accin es modelar un paso o un conjunto de pasos en la ejecucin.Puede ser escrita en lenguaje natural o pseudocdigo.

Decisin

Cuando una condicin es usada para indicar diferentes transiciones posibles que depende un valor booleano.

Andarivel

Usados para organizar las responsabilidades de las actividades.

Transicin simple

Una actividad sigue a otra, se las considera de duracin 0 y no tienen efectos laterales.

Transiciones concurrentes (fork y join)

Sincronizacin o bifurcacin en ejecuciones concurrentes.Un Join se habilita cuando todas las acciones origen han finalizado.Cuando un Fork se inicia todas las acciones son disparadas en simultneo.

Diagramas de Secuencia

Muestran objetos o clases y mensajes entre ellos. Lnea de vida: representa la existencia de un objeto a lo largo de un perodo de tiempo. Foco de control: representa el perodo de tiempo durante el cual el objeto ejecuta una accin. Mensajes a self: un mensaje que se enva de un objeto a l mismo se grafica mediante una caja de activacin anidada. Destruccin de objeto: cuando un objeto deja de existir, se marca su fin con una cruz donde termina su foco de control. Condicionales: se grafica con una flecha para cada opcin.

Trazabilidad: Matrices de Incidencia

Requerimientos / Casos de UsosDado que los casos de usos fueron determinados en relacin uno a uno con los requerimientos. Cada uno de estos ltimos queda cubierto por un caso de uso. Con esto corroboramos que todas las funcionalidades requeridas son tenidas en cuenta.

Requerimientos / ClasesEn este caso se determina que las clases con mayores incidencias en el sistema son Reserva, laboratorio y aquellas que derivan de Usuario (sobre todo docente). Cualquier cambio que se realice sobre ellas provocara un gran impacto en el proyecto, ya que adems estn en asociacin con muchas otras clases.

Casos de Usos / ClasesPor ltimo dado que como fue mencionado anteriormente, los casos de usos y los requerimientos estn en relacin 1 a 1, entonces la matriz de incidencia entre casos de usos/clases es idntica a la de requerimientos/clases. Por lo que en realidad no se aporta ningn dato nuevo.

Herramientas de gestin de requisitos

La gestin de requisitos es un componente vital, provee la direccin y el alcance del proyecto.Las herramientas CASE (Computer Arded Software Engineering) facilitan el trabajo de la especificacin, organizacin, almacenamiento y gestin de requisitos. A travs de la gestin de trazas, estas herramientas ayudan a evaluar el posible impacto de los cambios.

RequisitePro

Centrada en documentos, almacena los requisitos asocindolos a documentos.Auxilia especialmente en el control de cambio de requisitos con trazabilidad para especificaciones.Partner de MS.

IRqA

Diseada para soportar el proceso completo de ingeniera de requisitos.El ciclo de especificacin incluye captura de requisitos, anlisis, especificacin de sistema y validacin.

CaliberRM

Para sistemas grandes y complejos.Proporciona DB de requisitos con trazabilidad.Requisitos como parte del proceso de gestin de calidad.Basado en Internet.Maneja referencia de documentos, responsabilidad de usuario, trazabilidad, prioridad y estado entre otras.

Doors

Considera requisitos como objetos y documentos como mdulos.Orientacin a objetos.Para organizaciones grandes con complejos conjuntos de usuarios y requisitos.

UML (Lenguaje Unificado de Modelado)

Paquetes Mecanismo general para organizacin de modelos, agrupando elementos. Cada paquete corresponde a un subconjunto del modelo y contiene clases, objetos, relaciones, componentes, diagramas asociados. Un paquete puede contener otros paquetes. Una clase de un paquete puede aparecer en otro paquete por la importacin a travs de una relacin de dependencia entre paquetes. Un paquete encapsula a la vez que agrupa.

Diagramas de CU CU es una tcnica para capturar informacin de cmo trabaja un sistema. No pertenece estrictamente al enfoque orientado a objetos, es una tcnica de captura de requisitos.

Diagramas de Clases y Objetos Diagrama principal para el anlisis y diseo, presenta las clases y objetos del sistema con sus relaciones estructurales y de herencia. La definicin de clase y objeto incluye definiciones para atributos y operaciones. El modelo de CU aporta informacin para establecer las clases, objetos, atributos y operaciones.