UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

MATERIAL DE LECTURA SESIN N 4

Escuela Profesional: Ingeniera de Sistemas. Ciclo: Sexto Docente: Ing. Ivan Crispin Sanchez Asignatura: Ingeniera de Software. Semestre Acadmico: 2013 - II

Sesin 4: INGENIERIA DE REQUERIMIENTOS

ESQUEMA DE CONTENIDOS 1. 2. 3. 4. 5. DIAGRAMA DE CASOS DE USO DEL SISTEMA DOCUMENTACIN DE CASOS DE USO PRIORIZACIN DE CASOS DE USO CASOS DE USO DE PRUEBA SEGUIMIENTO DE REQUERIMIENTOS A TRAVS DE CASOS DE USO

1. DIAGRAMA DE CASOS DE USO DEL SISTEMA 1.1. INTRODUCCIN El modelo de caso de uso es un modelo de las funciones deseadas del sistema y su entorno, y hace las funciones de un contrato entre el cliente y los desarrolladores. Es utilizado como una introduccin esencial para las actividades de anlisis, diseo, y prueba del sistema. Un modelo de caso de uso muestra a los actores, casos de uso, paquetes de caso de uso, y sus relaciones. El modelo de caso de uso es un modelo que describe los requisitos de un sistema en trminos de casos de uso. Los casos de uso y los actores definen el alcance del sistema que usted construye. Los casos de uso incluyen cualquier cosa que est dentro del sistema; los actores incluyen cualquier cosa que es externa para el sistema. 1.2. OBJETIVOS Entre los principales objetivos de los diagramas de casos de uso se pueden mencionar los siguientes: Definir el comportamiento del sistema. Definir los casos de uso y sus respectivos actores. Entender como documentar los casos de uso. Utilizar un diagrama de casos de uso para mostrar los actores, casos de uso y sus interacciones. Definir escenarios para los casos de uso.

Sesin 04 Pag. 1

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

1.3. PROPSITO Cualquier diagrama de casos de uso busca tener los siguientes propsitos: El cliente le da la aprobacin al modelo de caso de uso. Cuando usted tiene esa aprobacin, sabe que el sistema es lo que el cliente quiere. Usted tambin puede usar el modelo para discutir sobre el sistema con el cliente durante el desarrollo. Los usuarios potenciales usan el modelo de caso de uso para entender mejor el sistema. El arquitecto del software usa el modelo de caso de uso para identificar funcionalidad arquitectnicamente significativa. Los diseadores usan el modelo de caso de uso para obtener una visin general de sistema. Cuando se refina el sistema, por ejemplo, se necesita documentar el modelo de caso de uso para ayudar a esta actividad. Los gerentes usan el modelo de caso de uso para planear y darle seguimiento al modelado de caso de uso y tambin al subsiguiente diseo. Las personas fuera del proyecto pero dentro de la organizacin (ejecutivos y comits de direccin), usan el modelo de caso de uso para hacerse una idea de lo que se ha hecho. Las personas revisan el modelo de caso de uso para proporcionarle la retroalimentacin apropiada a los desarrolladores de forma regular. Los diseadores destinan el modelo de caso de uso como una base para su actividad. Los evaluadores (testers) usan el modelo de caso de uso para planear actividades de ensayo lo ms pronto posible (casos de uso y test de integracin) . Esos que desarrollarn la siguiente versin del sistema usan el modelo de caso de uso para entender cmo opera la versin existente. Los escritores de la documentacin destinan los casos de uso como una base para escribir los manuales del usuario del sistema. El modelo de caso de uso en primer lugar establece los requisitos funcionales en el sistema, y es utilizado como una introduccin fundamental para el anlisis y diseo arquitectnico. Puede ser usado a principios de la fase de inicio para bosquejar el alcance del sistema, as como tambin durante la fase de elaboracin. El modelo de caso de uso es refinado por ms flujos detallados de eventos durante la fase de la construccin. El modelo de caso de uso es continuamente mantenido consistente con el modelo de diseo. Porque es un instrumento de planificacin muy poderoso, el modelo de caso de uso es generalmente usado en todas las fases del ciclo de desarrollo.

Sesin 04 Pag. 2

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

1.4. BENEFICIOS El uso de los diagramas de casos de uso tiene los siguientes beneficios dentro del anlisis y diseo orientado a objetos: COMUNICACIN CON LOS USUARIOS FINALES Y EXPERTOS DEL DOMINIO Proporciona una etapa previa al desarrollo del sistema. Asegura el entendimiento mutuo de los requerimientos. IDENTIFICACIN. Quin interacta con el sistema y debe hacer el sistema?. Qu interfaz debe tener el sistema? VERIFICACION Que se capturen todos los requerimientos Que los desarrolladores hayan entendido los requerimientos 1.5. ARTEFACTOS 1.5.1. ACTOR Un actor es alguien o algo que interacta con el sistema que ser construido. Como veremos en poco tiempo, los casos de uso describen algo que est dentro del alcance del sistema. Los actores son algo que es externo al alcance del sistema. All dentro es tres tipos primarios de actores: Los usuarios del sistema, otros sistemas que interactuarn con el sistema que ser construido, y el tiempo. El primer tipo de actor es una persona fsica, o un usuario. stos son los actores ms comunes, y estn presentes dentro justamente de cada sistema. Los actores son las personas que estarn directamente usando el sistema. Cundo denominando a los actores, recuerde usar el nombre del rol en vez de nombres de posicin. Un individuo determinado jugar muchos roles. Fulano dental puede ser un representante de servicio al cliente, pero si l est en lnea para comprarse un boleto de viaje, l desempea el rol de un cliente. Usar nombres de rol en vez de nombres de posicin le dar una descripcin ms estable de sus actores. Los nombres de posicin cambian con el paso del tiempo, como los roles y las responsabilidades son desplazadas de una posicin hacia otra. Usando roles, usted no necesitar actualizar su modelo cada vez que una posicin nueva se agrega o cambia. El segundo tipo de actor es otro sistema. Por ejemplo, un sistema de reservacin de una aerolnea puede necesitar interactuar con una aplicacin externa para validar tarjetas de crdito para las compras. En este ejemplo, la aplicacin de crdito externa es un actor. Es otro sistema que no cambiaremos en absoluto, que est fuera del
Sesin 04 Pag. 3

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

alcance del proyecto actual, pero que necesita interactuar con con nuestro nuevo sistema . Cualquiera sistema como ste, que tiene lugar simplemente fuera de los lmites de nuestra aplicacin, es actor. El tercer tipo de actor que es comnmente usado es el tiempo. El tiempo se convierte en un actor cuando la transicin transicin de una cierta cantidad de tiempo provoca algn evento en el sistema. Por ejemplo, en parte de las promociones de nuestra aerolnea puede ser la oportunidad para ganarse un boleto gratis. Todos los das a las 3:00 p.m. el sistema automticamente puede seleccionar seleccionar un cliente aleatorio a quien darle un boleto gratis. Porque el tiempo est fuera de nuestro control, es un actor.

Para entender por completo el propsito del sistema usted debe conocer para quin es el sistema, es decir, quien estar usando el sistema. Los tipos diferentes del usuario son representados como actores. Un actor es algo que intercambia datos con el sistema. Un actor puede ser un usuario, hardware externo, u otro sistema. CARACTERSTICAS El nombre y descripcin deben ser claros y entendibles. Un actor es quien inicializa un caso de uso. El ambiente fsico en el cual el actor estar usando el sistema. Las desviaciones del caso ideal (donde el usuario se sienta en una oficina silenciosa, sin distracciones), podran afectar el uso de cosas como por ejemplo el sonido, la eleccin de tipo de letra, y el uso apropiado de combinaciones del dispositivo de entrada. El nmero de usuarios representados por este actor. Este nmero es un factor pertinente ertinente al determinar el significado del actor, y el significado de las partes de la interfaz de usuario que el actor usa. La frecuencia con la cual el actor usar el sistema. Esta frecuencia determinar cunto (de la interfaz de usuario) el actor puede puede ser esperado para recordar entre sesiones.
Sesin 04 Pag. 4

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

En la mayora de los casos, una estimacin aproximada del nmero de usuarios y la frecuencia de uso ser satisfactoria. Una diferencia entre 30 y 40 no afectarn cmo es la interfaz de usuario modelada, pero una diferencia entre 3 y 30 lo pueden hacer. No puede haber actores que no interacten con al menos un caso de uso. Una persona o sistema puede utilizar puede jugar el papel de 2 o ms actores en el sistema. Los actores no interactan entre ellos. PAUTAS PARA IDENTIFICAR ACTORES Encontrar los actores es uno de los primeros pasos en la definicin del uso del sistema. Cada tipo de fenmeno externo con el que debe interactuar el sistema est representado por un actor. Para encontrar los actores, realice las siguientes preguntas: Qu grupos de usuarios requieren ayuda del sistema para ejecutar sus tareas? Qu grupos de usuarios son necesarios para ejecutar las funciones principales ms obvias del sistema? Qu grupos de usuarios son necesarios para ejecutar funciones secundarias como, por ejemplo, el mantenimiento y la administracin del sistema? Interactuar el sistema con algn sistema de hardware o software externo? Toda persona, grupo o fenmeno que coincida con una o varias de estas categoras es candidato para ser un actor. Para determinar si tienen los actores correctos (personas), puede intentar nombrar dos o tres personas que puedan ser actores y ver si el conjunto de actores es suficiente para sus necesidades. CHECKPOINST PARA ACTORES Ha encontrado usted todos los actores? Es decir, usted ha llevado las cuentas y ha modelado todos los roles en el entorno del sistema? Aunque usted debera comprobar esto, usted no puede estar seguro hasta usted haya encontrado y descrito todos los casos de uso. Est cada actor involucrado en un caso de uso como mnimo? Remueva a cualquier actor no mencionado en las descripciones del caso de uso, o cualquier actor sin relaciones de asociaciones con un caso de uso. Sin embargo, un actor mencionado en una descripcin de caso de uso es muy probable que tenga una relacin de asociacin con que un caso de uso particular. Puede nombrar usted al menos a dos personas que podran desempearse como un actor particular? En caso de que no, revise si el rol del actor modelado, es parte de otro actor. Si es as, usted debera juntar a los 2 actores. Juegan algunos actores roles similares en relacin al sistema? Si es as, usted los debera juntar en un solo actor. Las relaciones de asociaciones y las descripciones de los caso de uso muestran cmo se vinculan los actores y el sistema.

Sesin 04 Pag. 5

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Juegan dos o mas actores el mismo rol en relacin a un caso de uso? Si es as, usted debera usar generalizaciones para el actor, y as modelar su comportamiento compartido. Usar un actor particular el sistema en varias (completamente diferentes) formas o tiene l varios (completamente diferentes) propsitos para usar un caso de uso? Si es as, usted probablemente debera tener ms de un actor. Tienen los actores nombres intuitivos y descriptivos? Pueden entender tanto usuarios y clientes, los nombres del actor? Es importante que los nombres del actor correspondan a sus roles. En caso de que no, hay que cambiarlos. 1.5.2. CASO DE USO (Use Case) Es una secuencia de acciones realizadas por el sistema que producen un resultado observable y valioso para alguien en particular. Un caso de uso es justamente una forma de representar como alguien o algo usa nuestro sistema. El caso de uso al dar respuesta a un evento que inicia un agente externo (Actor) deben ser desarrollados en funcin a lo que los usuarios necesitan. Un caso de uso es pues en esencia una interaccin tpica entre el usuario y el sistema, aunque un caso de uso tambin puede ser invocado por otro caso de uso. La idea fundamental en los casos de uso es definir los requerimientos del sistema desde el punto de vista de quien usa el sistema y no de quien lo construye. De esta manera, nos aseguramos que estos permitan dar a conocer todos los requerimientos del sistema para poder construirlo. Un caso de uso define un conjunto de instancias de caso de uso, donde cada instancia es una secuencia de acciones un sistema realiza aquello produce un resultado observable de valor para un actor particular. Un caso de uso es una pieza de alto nivel de funcionalidad que el sistema proveer. En otras palabras, un caso de uso ilustra cmo alguien podra usar el sistema. CARACTERISTICAS Son iniciados por un nico agente externo (Actor). Estn expresados desde el punto de vista del actor. Describen tanto lo que haces el actor como lo que hace el sistema cuando ambos interactan. Se documentan con texto informal (Flujo de Eventos). Estn limitados al uso de una determinada funcionalidad claramente diferenciada, esto es en una sola tarea.

Sesin 04 Pag. 6

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

PAUTAS PARA IDENTIFICAR CASOS DE USO Qu tareas primarias el actor desea que el sistema desempee? Qu informacin tiene el actor que crear, consultar, actualizar, leer o borrar en el sistema y como lo har? Que necesitar el actor para informar al sistema acerca de repentinos, cambios externos? Qu informacin debe dar el sistema al actor? Cules son los eventos ante los cuales un actor debe reaccionar? Necesita el actor ser informado acerca de ciertas ocurrencias en el sistema? Qu casos de uso soportarn y mantendrn el sistema? Qu informacin debe ser modificada o creada en el sistema? Realizar el actor una puesta en marcha del sistema o un cese de operaciones? CHECKPOINST PARA CASOS DE USO Est cada caso de uso concreto involucrado en un actor como mnimo? En caso de que no, algo est mal; Un caso de uso que no interacta con un actor est de ms, y usted lo debera remover. Es cada caso de uso independiente de los dems? Si dos casos de uso estn todo el tiempo activados en la misma secuencia, usted probablemente los debera combinar en un solo caso de uso. Para un caso de uso incluido. Hace suposiciones acerca de los casos de uso que lo incluyen? Tales suposiciones deberan ser evitadas, a fin de que el caso de uso incluido no sea afectado por cambios en los casos de uso que incluye. Tiene cualquier casos de uso flujos o comportamientos muy similares de eventos? Si as es usted los debera combinar en un solo caso de uso (y si usted desea su comportamiento sea similar en el futuro). Esto da facilidades para introducir cambios futuros. Nota: Usted debe involucrar a los usuarios si usted decide combinar casos de uso, porque los usuarios, quines interacta con el nuevo caso de uso combinado probablemente sern afectados. Tiene parte del flujo de eventos ya modelada en otro caso de uso? Si es as, usted puede tener el nuevo caso de uso igual a otro anterior. Debera ser el flujo de eventos de un caso de uso introducido en el flujo de eventos de otro? Si es as, se est modelando esto como una relacin extendida para el otro caso de uso.

Sesin 04 Pag. 7

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Tiene los casos de uso nombres nicos, intuitivos, y explicativos a fin de que no pueden ser desordenados en una posterior etapa? En caso de que no, usted debera modificar sus nombres. Entienden los clientes y los usuarios del mismo modo los nombres y descripciones de los casos de uso? Cada nombre de caso de uso debe describir el comportamiento que el caso de uso soporta. Encuentra el caso de uso todos los requisitos que obviamente gobiernan su desempeo? Se conforma la secuencia de comunicacin entre actor y el caso de uso a las expectativas del usuario? Es claro esto de cmo y cundo el flujo de eventos del caso de uso inicia y acaba? El comportamiento podra existir, al ser activado slo cuando una cierta condicin no es encontrada. Hay una descripcin de qu ocurrir si una condicin dada no es encontrada? Es cualquier caso de uso excesivamente complicado? Si usted quiere que su modelo de caso de uso sea fcil de entender, tendra que dividir los casos de uso complicados. Contiene un caso de uso flujos disparejos de eventos? Si es as, es mejor dividirlo en dos o ms casos de uso separados. Un caso de uso que contiene flujos disparejos de eventos costar mucho entender y mantener. El subflujo est en un caso de uso modelado acertadamente? Es claro quin desea desempear un caso de uso? Es el propsito del caso de uso, claro tambin? Son claras las interacciones del actor e informacin intercambiada? Da una breve descripcin un retrato autntico y verdadero del caso de uso? FUENTES DE INFORMACIN PARA HALLAR CASOS DE USO Especificaciones del sistema Manifestaciones del problema Entrevistas Literatura relevante del sistema Entrevistas con expertos del sistema Conocimiento personal del sistema Sistemas heredados Manual de Funciones y Procedimientos
Sesin 04 Pag. 8

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Documentacin de Entrada y Salida 1.5.3. RELACIONES Las relaciones de los diagramas de casos de uso, son las mismas que han sido revisadas cuando se vio la sesin del Modelo de Casos de Uso del Negocio. 1.6. DEPENDENCIA DE LOS DEMS MODELOS DE LOS CASOS DE USO

2. DOCUMENTACIN DE CASOS DE USO 2.1. FLUJO DE EVENTOS Una diagrama de casos de uso describe lo que hace el sistema, pero no describe como lo hace, al construir los diagramas de casos de uso se debe tener bien en claro esta separacin. El comportamiento de un caso de uso, puede ser descrito de muchas maneras dependiendo de la conveniencia, a veces podemos usar pseudocdigo; sin embargo, comnmente un caso de uso se documenta de manera informal mediante un lista de pasos que sigue el Actor durante su interaccin con el sistema. A esta lista de pasos se le denomina FLUJO DE EVENTOS. El Flujo de Eventos de un caso de uso contiene la informacin ms importante derivada desde la actividad de modelado de caso de uso. Debera describir el flujo de eventos del caso de uso lo suficientemente claro para que una para persona ajena o externa lo entienda fcilmente. Recordar que el flujo de eventos debera presentar lo que el sistema hace, no cmo es que el sistema es diseado para desempear el comportamiento requerido.

Sesin 04 Pag. 9

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Un caso de uso se documenta generalmente con texto informal, por lo tanto si tenemos que especificar formalmente un algoritmo, los casos de uso no son los ms adecuados, en su lugar debemos usar los diagramas de actividad, secuencia o colaboracin. DIRECTIVAS Describir de qu modo el caso de uso comienza y finaliza. Describir qu datos son intercambiados entre el actor y el caso de uso. No describir los detalles de la interfaz de usuario, a menos que sea necesario entender el comportamiento del sistema. Por ejemplo, es a menudo bueno usar un conjunto limitado de terminologa especfica en la Web cuando se sabe que la aplicacin va ha ser basada en la Web. De lo contrario, se corre que el riesgo que el texto de caso de uso sea percibido como hacia lo abstracto. Las palabras a incluir en su terminologa podran ser "navegar", browse, hiperconexin a pgina", submit, y "navegador". Sin embargo, no se aconseja incluir referencias a "marcos" o "pginas web de tal manera que usted hace suposiciones acerca de los lmites entre ellas - sta es una decisin crtica del diseo. Describir el flujo de eventos, no slo la funcionalidad. Para implementar esto, inicie cada accin con "cuando el actor .... Describir slo los eventos que forman parte del caso de uso, y no lo que ocurre en otros casos de uso o fuera del sistema. Detallar el flujo de eventos todos los "QUES" deberan ser respondidos. Recordar que los diseadores de prueba deben usar este texto para identificar casos de prueba. Si usted ha usado ciertos trminos en otros casos de uso, asegrese de usar los trminos mismos exactos en este caso de uso, y que su significado deseado sea el mismo. Maneje trminos comunes, a travs de un glosario. ESTRUCTURA Las dos partes principales del flujo de eventos son: Flujo bsico de eventos. Flujos alternativos de eventos. El flujo bsico de eventos debera cubrir lo qu "normalmente" ocurre cuando el caso de uso es realizado. Los flujos alternativos de eventos informan acerca del comportamiento de carcter optativo o excepcional en relacin al comportamiento normal, y tambin en relacin a las variaciones del comportamiento normal. Usted puede pensar acerca de los flujos alternativos de eventos como "desvos" del flujo bsico de eventos, algunos de los cuales regresarn al flujo bsico de eventos y alguno que otro de los cuales acabar la ejecucin del caso de uso.

Sesin 04 Pag. 10

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Ambos el flujo bsico de eventos y los flujos de eventos alternativos deberan estar estructurados en pasos o subflujos. Al hacer esto, su meta principal debera ser la legibilidad del texto. Una regla general es que un subflujo debera ser un segmento de comportamiento dentro del caso de uso que tiene un propsito claro, y es "atmico" en el sentido que usted hace todas o ninguna de las acciones descritas. Usted puede necesitar tener varios niveles de subflujos, pero si lo puede hacer, lo debera evitar pues eso hace que el texto sea ms complicado y ms difcil para entender. Usted puede ilustrar la estructura del flujo de eventos mediante los diagramas de actividad. Este tipo de texto escrito, estructurado en subsecciones consecutivas, puede implicar por su naturaleza para el lector, que hay una secuencia entre los subflujos. Para evitar malentendidos, usted siempre debera apuntar fuera ya sea que la orden de los subflujos sea fija o no. Consideraciones para esta categora esta relacionadas a lo siguiente: Reglas del negocio. Por ejemplo, el usuario tiene que estar autorizado antes de que el sistema puede hacer disponible ciertos datos. Diseo de interfaz de usuario. Por ejemplo, el sistema no debera implementar una cierta secuencia de comportamiento que puede ser intuitivo para algunos pero no para otros usuarios. Para clarificar donde un flujo alternativo de eventos encaja en la estructura, usted necesita describir lo siguiente para cada "desvo" del flujo bsico de eventos: Donde en el flujo bsico de eventos, el comportamiento alternativo puede ser insertado. La condicin que necesita estar satisfecha para el comportamiento alternativo pueda iniciar. Cmo y dnde el flujo bsico de eventos es reasumido, o cmo finaliza el caso de uso. Podra ser tentador, si el flujo alternativo de eventos es muy simple, para justamente describirlo en la seccin del flujo bsico de eventos (usando alguna instruccin informal como "IF THEN ELSE"). Esto debera ser evitado. Demasiadas alternativas dificultarn el
Sesin 04 Pag. 11

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

comportamiento normal a ver. Tambin, incluir rutas alternativas en la seccin del flujo bsico de eventos crear ms pseudocdigo al texto y ser ms difcil de leer. En general, extraer partes del flujo de eventos y describir estas partes separadamente, pueden aumentar la legibilidad del flujo bsico de eventos y mejorar la estructura del caso de uso y el modelo de caso de uso. Usted puede modelar partes extradas como: Un flujo alternativo de eventos dentro del caso de uso base si fuera una variante simple, una opcin, o una excepcin para el flujo bsico de eventos. Como una inclusin explcita en el caso de uso base, si es que algo usted tiene el deseo de encapsular de manera que puede ser reusada por otros casos de uso. Como una inclusin implcita en el caso de uso base, si el flujo bsico de eventos del caso de uso base es completo, es decir, tiene un fin y comienzo definido. La naturaleza del flujo extensible debera ser tal que usted prefiere no exteriorizar ella la descripcin del caso de uso base para que sea menos compleja. Un subflujo en el flujo bsico de eventos, posiblemente como otra opcin, si ninguna de las alternativas citadas anteriormente aplican. Por ejemplo, en un caso de uso de Mantenimiento de Informacin del Empleado, pueden haber subflujos separados para agregar, suprimir y modificar informacin del empleado. ESTILOS Usted puede describir los casos de uso en muchos estilos. El estilo 01, demuestra que la descripcin del flujo de acontecimientos falla para clarificar el orden en la cual las cosas ocurrirn. Si usted escribe en este estilo, usted y los dems podran perder cosas importantes que le conciernen el sistema. En el estilo 02, que es el recomendado, es fcil de entender, y el orden en la cual las cosas ocurren es claramente evidente. El texto est dividido en subdivisiones numeradas y designadas. Los nmeros estn all para facilitar referirse a una subseccin. Los nombres de subsecciones dejarn al lector obtener una visin general rpida del flujo de eventos examinando a la ligera el texto, leyendo slo los encabezados. El estilo 03, sale a la vista como otro estilo, el cual puede ser til si usted encuentra difcil expresar la secuencia de eventos claramente. Este estilo de pseudocdigo es ms preciso, pero el texto es difcil de leer y absorber para una persona poco especializada, sobre todo si usted quiere captar el flujo de eventos rpidamente. PRE Y POSTCONDICIONES Puede ser til usar la nocin de precondicin y postcondicin para aclarar cmo inicia y finaliza el flujo de eventos. Sin embargo, slo selo si es percibido como valor agregado por la audiencia del caso de uso.

Sesin 04 Pag. 12

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

FORMATO DE DOCUMENTACIN NOMBRE. Cada caso de uso debe tener un nombre que indica qu es logrado por su interaccin con el actor. El nombre puede ser de varias palabras para ser comprendido. De ninguna manera dos casos de uso pueden tener el mismo nombre. DESCRIPCIN. La descripcin del caso de uso reflejar su propsito. Cada caso de uso debera incluir una descripcin breve que explica lo que el caso de uso har. La descripcin debera ser breve y sin rodeos, pero debe incluir los diferentes tipos de usuarios que ejecutarn el caso de uso y el resultado final que el usuario espera lograr a travs del caso de uso. Estas definiciones de caso de uso ayudarn al equipo entero a recordar por qu cada caso de uso es incluido en el proyecto y qu cosa el caso de uso est dirigido a realizar. Tambin ayudan a reducir confusin entre los miembros del equipo al documentar un propsito claro para el caso de uso. PRECONDICIONES. Las precondiciones de un caso de uso listan cualquier condicin que tienen para ser cumplidas antes de que el caso de uso puede comenzar. Por ejemplo, una precondicin podra ser que otro caso de uso ha sido ejecutado o que el usuario tiene los derechos de acceso necesarios para ejecutar el caso de uso actual. No todos los casos de uso tienen precondiciones. Los diagramas de Caso de uso no se definen para demostrar en cul ordena los casos de uso son ejecutados. Las precondiciones, sin embargo, pueden usarse para documentar una parte de este tipo de informacin. Por ejemplo, la precondicin para un caso de uso puede ser que otro caso de uso se ha ejecutado.

Sesin 04 Pag. 13

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

FLUJO BSICO DE EVENTOS. Los detalles especficos del caso de uso estn descritos en el flujo bsico y alternativo de eventos. El flujo de eventos describe, paso a paso, lo que ocurrir al ejecutar la funcionalidad en el caso de uso. El flujo de eventos se enfoca sobre lo que el sistema har, no cmo lo har, y est escrito desde la perspectiva del usuario. FLUJO ALTERNATIVO DE EVENTOS. Describe el flujo de eventos que se desarrollar cuando el ocurra una excepcin en el flujo bsico de eventos. POSTCONDICIONES. Las postcondiciones son condiciones que siempre deben ser ciertas despus de que el caso de uso haya terminado de ejecutarse. Como las precondiciones, las postcondiciones pueden usarse para agregar informacin acerca de la orden en la cual los casos de uso son ejecutados. Si, por ejemplo, un caso de uso siempre debe ser ejecutado despus de otro caso de uso, usted puede documentar esto en las postcondiciones. No todo caso de uso tendr postcondiciones. 3. PRIORIZACIN DE CASOS DE USO El equipo de desarrollo establece las prioridades para los casos de uso para determinar el contenido y el enfoque de cada iteracin en el proyecto. En esta actividad se describen los factores que contribuyen a tener en cuenta al establecer las prioridades. Una vez que el alcance del proyecto es conocido, la funcin del arquitecto de software que analiza los casos de uso para determinar cules son de gran importancia arquitectnica. Estos casos de de uso, en todo o parte, tienen alta prioridad y deben ser desarrolladas durante la fase de elaboracin. Otros casos de uso se completan durante la fase de construccin. Otros factores que contribuyen a priorizar casos de uso son: los riesgos, el esfuerzo, las dependencias, las prioridades o urgencia del negocio y tambin los recursos disponibles.

Sesin 04 Pag. 14

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Caso de Uso CU 01 CU 02 CU 03 CU 04 CU 05

Importancia 1 2 4 2 5

Riesgo 3 3 4 2 3

Esfuerzo 4 3 5 3 1

Dependencias CU 05 CU 01, CU 04 CU 02 CU 05

Urgencia 3 4 5 1 4

Recursos Disponible No Disponible Disponible No Disponible Disponible

1 - Muy Baja | 2 Baja | 3 Media | 4 Alta | 5 Muy Alta

4. CASOS DE USO DE PRUEBA Un cdigo sin fallos no tiene por qu derivar en un sistema sin fallos. Por ello, la fase de prueba de sistemas cobra una gran importancia en el desarrollo de sistemas software. El proceso de prueba a nivel de sistema engloba tantos tipos de prueba como tipos de requisitos se puedan definir y probar con la ejecucin del sistema o mediante la verificacin de sus distintos elementos. Los casos de prueba son un conjunto de condiciones o variables bajo las cules el analista determinar si el requisito de una aplicacin es parcial o completamente satisfactorio. Se pueden realizar muchos casos de prueba para determinar que un requisito es completamente satisfactorio. Con el propsito de comprobar que todos los requisitos de una aplicacin son revisados, debe haber al menos un caso de prueba para cada requisito a menos que un requisito tenga requisitos secundarios. En ese caso, cada requisito secundario deber tener por lo menos un caso de prueba. RUP recomiendan el crear por lo menos dos casos de prueba para cada requisito. Uno de ellos debe realizar la prueba positiva de los requisitos y el otro debe realizar la prueba negativa. Si la aplicacin es creada sin requisitos formales, entonces los casos de prueba se escriben basados en la operacin normal de programas de una clase similar. Lo que caracteriza un escrito formal de caso de prueba es que hay una entrada conocida y una salida esperada, los cuales son formulados antes de que se ejecute la prueba. La entrada conocida debe probar una precondicin y la salida esperada debe probar una postcondicin. Bajo circunstancias especiales, podra haber la necesidad de ejecutar la prueba, producir resultados, y luego un equipo de expertos evaluara si los resultados se pueden considerar como "correctos". Esto sucede a menudo en la determinacin del nmero del rendimiento de productos nuevos. La primera prueba se toma como lnea base para los subsecuentes ciclos de pruebas/lanzamiento del producto. Los casos de prueba escritos, incluyen una descripcin de la funcionalidad que se probar, la cul es tomada ya sea de los requisitos o de los casos de uso, y la preparacin requerida para asegurarse de que la prueba pueda ser dirigida.

Sesin 04 Pag. 15

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Los casos de prueba escritos se recogen generalmente en una suite de pruebas. Las variaciones de los casos de prueba son comnmente utilizados en pruebas de aceptacin. La prueba de aceptacin es realizada por un grupo de usuarios finales o los clientes del sistema, para asegurarse que el sistema desarrollado cumple sus requisitos. La prueba de aceptacin de usuario se distingue generalmente por la incorporacin de un trayecto feliz o casos de prueba positivos. Habitualmente los casos de prueba engloba requisitos funcionales, de seguridad, de rendimiento, de fiabilidad, de accesibilidad, etc. Al abordar la automatizacin de las pruebas de sistemas, se pueden identificar, a grandes rasgos, tres niveles claramente separados. El primero es la automatizacin del proceso de generacin de casos de prueba a partir de los requisitos, el segundo es la automatizacin de la ejecucin de los casos de prueba y el tercero es la comprobacin de sus resultados. El perfil de pruebas de UML define un objetivo de pruebas como un elemento con un nombre concreto que define qu debe ser probado. En el contexto de pruebas del sistema a partir de los casos de uso, un objetivo de prueba puede expresarse como un escenario del caso de uso. ESCENARIOS Los escenarios describen situaciones teniendo en cuenta aspectos de uso, permitiendo: conocer el problema, unificar criterios, ganar compromiso con clientes / usuarios, organizar los detalles involucrados y entrenar a nuevos participantes. El uso de escenarios como una tcnica para entender el problema a resolver usando un sistema de software ha sido recomendado por varios autores (Potts 1995; Booch 1991; Jacobson et al. 1992; Zorman 1995) y dichas propuestas se hicieron muy importantes para extender el uso de escenarios en la prctica real. Es una instancia descrita de caso de uso; un subconjunto de un caso de uso. Con un escenario representamos el conjunto de eventos que configura el comportamiento de un caso de uso. Un escenario describe una instancia del flujo de eventos de un caso de uso, con sus variaciones o extensiones posibles y las excepciones probables. Se pueden modelar mediante los diagramas de Interaccin: DIAGRAMA DE SECUENCIAS Y DIAGRAMA DE COLABORACION. Cada caso de uso tiene mltiples escenarios y pueden ser descritos como: Escenarios primarios. La forma en que debe trabajar el sistema. (Flujo Normal de Eventos). Escenarios secundarios. Excepciones al escenario normal (Flujos Alternativos de Eventos) Conforme el curso principal es justamente un camino posible a travs del caso de uso, si hay otras formas de alcanzar las metas del actor, necesita construir otros caminos para cada una de las rutas. Cada camino posible a travs de un caso de uso es denominado un escenario.

Sesin 04 Pag. 16

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Considere un escenario como una instancia de un caso de uso. Las instancias de caso de uso usan la misma notacin oval como los casos de uso, pero tienen su nombre de instancia, en el formato subrayado estndar, como sigue: La notacin de modelado mostrada es similar a eso de clases y sus instancias, los objetos. Nombre cada escenario a fin de que sean fcilmente distinguidos usando el formato para las instancias del objeto. Hay a menudo instancias potenciales infinitas de casos de uso, cada uno del cual es un camino ligeramente diferente a travs del caso de uso, con valores diferentes para la introduccin de datos del usuario, o el nmero diferente de errores ocurriendo en las rdenes distintas. Sin embargo, no se moleste aun intentando identificar todo estos caminos. Simplemente debera identificar los que producen cuantitativamente resultados diferentes. Por ejemplo, identifique formas diferentes de encontrar las metas o los mensajes diferentes de error. Construya escenarios que se extienden a lo largo de todos los errores, excepciones, o variaciones de flujo. Finalmente, el conjunto de escenarios que usted identifica debera agotar toda la lgica del caso de uso. Cada escenario que identifica tiene que ser un camino posible a travs de los casos de uso. As probablemente tendr que construir un flujo separado de eventos para cada escenario que ha encontrado. Cada uno de estos flujos adicionales son usualmente llamados un camino alterno. Documente los caminos alternos al modo del camino principal. El nmero de escenarios necesitados se basa en la comprensin que se tenga del sistema, es decir que si definimos un nmero X de escenarios, nos preguntamos Comprendo a cabalidad o enteramente el caso de uso?, si es as entonces el nmero de escenarios es el idneo, caso contrario debera buscar ms escenarios. Se sugiere lo siguiente: Escenarios Primarios (Dedicar aproximadamente el 80% del tiempo a estos escenarios). Escenarios Secundarios (Elaborar algunos de los escenarios secundarios interesantes y de alto riesgo). 5. SEGUIMIENTO DE REQUERIMIENTOS A TRAVS DE CASOS DE USO Para realizar un seguimiento de los requisitos a travs de nuestros casos de uso nosotros utilizamos el concepto de La trazabilidad de los requerimientos que se refiere a la documentacin de la vida de cada uno de ellos (requisitos), y debe permitir seguir el historial desde su formulacin original hasta el momento actual. Cada cambio realizado debe por tanto ser documentado para conseguir dicha trazabilidad. Incluso la implementacin de las caractersticas determinadas por los requerimientos debe poder ser trazada. Los requerimientos surgen de diversas fuentes: el cliente, el manager, el usuario final, etc. Todas y cada una de ellas tienen diferentes requerimientos para el producto. Utilizando la trazabilidad, puede seguirse el historial de una caracterstica implementada hasta las personas o grupos que la solicitaron durante la generacin de los requerimientos, permitiendo un rpido anlisis en cada fase del proyecto para: Determinar la visin original y permitir una discusin controlada de los cambios en el alcance.

Sesin 04 Pag. 17

UNFV FACULTAD DE INGENIERIA INDUSTRIAL Y DE SISTEMAS

Determinar qu elementos se vern afectados cuando consideramos agregar un nuevo requerimiento o modificar uno ya existente Verificar que el requerimiento contempla todos lo que el interesado solicit. Evitar el Gold Platting: Verificar que la aplicacin no implementa funcionalidades no demandadas por el cliente. MATRIZ DE TRAZABILIDAD Se utiliza para realizar seguimiento y control de los diversos artefactos e informacin que tenemos del sistema en estudio. Esta herramienta puede ser til para muchas formas de hacer seguimiento en cada fase del RUP. Para el caso de los requerimientos con los casos de uso, podemos tener la siguiente matriz de trazabilidad. Caso de Uso 1 Requisito del Sistema 1 Requisito del Sistema 2 Requisito del Sistema 3 Requisito del Sistema N X X X X Caso de Uso 2 Caso de Uso N X X

Sesin 04 Pag. 18