IVANOV TRIVEO H.

SEMINARIO DE TESIS I CAPTURA DE REQUISITOS COMO CASOS DE USO

7.1 Introduccin El esfuerzo principal en la fase e requisitos es desarrollar un modelo del sistema que se va a construir, y la utilizacin de los casos de uso es una forma adecuada de crear ese modelo. Esto es debido a que los requisitos funcionales se estructuran de forma natral mediante casos de uso, y a q la mayora de los otros requisitos no funcionales son especficos de un solo caso de uso, y pueden tratarse en contexto de ese caso de uso. Los requisitos no funcionales restantes aquella q son comunes para muchos o para todos los casos de uso, se mantienen en un documento aparte y se denominan requisitos adicionales. Los casos de uso proporcionan un medio intuitivo y sistemtico para capturar los requisitos funcionales con un nfasis espacial en el valor aadido para cada usuario individual o para cada sistema externo. Mediante la utilizacin de los casos de uso , los analistas se ven obligados a pensar en trminos de quienes son los usuarios y q necesidades u objetivos de la empresa pueden cumplir.

Analista de sistemas

Especificador de casos de uso

Diseador de internas Arquitecto de usuario

ssasssistemassistmes Responsable de ssasssistemassi stmes

ssasssist de Responsable ssasssistemassi Responsable de ssasssistemassi Responsable de emassis stmes stmes tmes ssasssistem ssasssistem ssasssistem assistmes assistmes assistmes

Actor

Glosario

Caso de Uso

Prototipo de interfaz De usuario

Descripcin de la arquitectura

ssasss istem assist mes

ssasssist emassis tmes

ssasssistem ssasssistemassi ssasssistemassi assistmes stmes stmes

Modelo de casos De uso

7.2 Artefactos Los artefactos fundamentales que se utilizan en la captura de requisitos son el modelo de casos de uso q incluye los casos de uso y los actores. Tambin puede haber otros tipos de artefactos como prototipos e interfaz de usuario. 7.2.1 Artefacto: modelo caso de uso El modelo de casos de uso permite a los desarrolladores de software y los clientes lleguen a un acuerdo sobre los requisitos, es decir sobre las condiciones y posibilidades q debe cumplir el sistema. El modelo de casos de uso pero sirve como acuerdo entre clientes y desarrolladores, proporciona la entrada fundamental para el anlisis, el diseo y las pruebas

Un modelo de casos de uso es un modelo del sistema q contiene actores, casos de uso y sus relaciones. El modelo de casos de uso puede hacerse bastante grande y difcil de digerir en un solo mordisco, la forma que es necesario algn medio de abordarlo en trozos mas pequeos. UML nos permite representar el modelo de diagramas que muestran actores u casos de uso desde

Modelo de casos de uso

Sistema casos de uso

Actor

Caso de uso

Diferentes puntos de vista y con diferentes propsitos. observe tambin que si el modelo de casos de uso es grande , es decir , si contiene un gran numero de casos de uso y/o actores ., Tambin puede ser til introducir paquetes en el modelo para tratar su tamao . Esto es una extensin ms o menos trivial del modelo de casos de uso. 7.2.2 Artefacto Actor

El modelo de casos de uso describe lo que hace el sistema para cada tipo de usuario. Cada uno de estos se presenta mediante uno o mas de los actores cada sistema externo con el q interacta el sistema incluyendo dispositivos externos como temporizadores, que se consideran externos al sistema. Una vez que hemos identificado todos los actores del sistema, tenemos identificado el entorno externo del sistema. Los actores suelen corresponderse con trabajadores (o actores del negocio) en un negocio. Recurdese que cada rol (De un trabajador) define lo que hace el trabajador en un proceso de negocio0 concreto. Los roles que desempea un trabajador pueden emplearse `para obtener (o para genera realmente si contamos con las herramientas apropiadas) los roles que cumple el actor del sistema correspondiente. Dotamos a cada trabajador con un caso de uso del sistema para cada uno de sus roles. Ese caso de uso proporciona un valor al actor cuando representa el papel de trabajador. Un actor juega un papel por cada caso de uso con el que colabora. Cada vez que el usuario en concreto (un humano u otro sistema) interacta con el sistema, la instancia correspondiente del actor esta desarrollando ese papel. Una instancia de un actor es por tanto un usuario concreto que interacta con el sistema. Cualquier entidad que se ajuste a un actor puede actuar como una instancia que se ajuste al actor. 7.2.3 Caso de uso Cada forma en que loas actores usan el sistema se representa con cada caso de uso. Los casos de uso son fragmentos de funcionalidad del sistema ofrece para aportar un resultado de valor para sus actores. De mas precisa, un caso de uso especifica una secuencia de acciones que el sistema puede llevar a cabo interactuando con sus actores, incluyendo alternativas dentro de la secuencia . Por tanto un caso de uso es una especificacin. Especifica el comportamiento de cosas dinmicas, en este caso, de instancias de los casos de uso. Ejemplo El caso de uso sacar dinero

Sacar dinero El caso de uso sacar dinero especifica las posibles instancias de ese caso de uso , es decir , las diferentes formas validas de llevar a cabo el caso de uso por parte del sistema y la interaccin requerida con las instancias de actores implicadas . Supongamos que una persona concreta, de nombre Jack, introducen en primer lugar su contrasea 1234, selecciona sacar 220 dlares, y tmale dinero. El sistema habr llevado a cabo una instancia de caso de uso. Si en cambio jack introduce su contrasea y elije sacar 240 dlares, y despus toma el dinero p, el sistema habr llevado a cabo otra instancia de caso de uso. Una tercera instancia de caso de uso podra ser lo que hara el sistema si Jack solicita 480 dlares, y el sistema no se lo permite debido a un saldo insuficiente o a una contrasea errnea y a casos similares.

Segn el vocabulario del UML, un caso de uso es el clasificador, lo cual quiere decir que tiene operaciones y atributos. Una descripcin de un caso de uso puede ser tanto incluir diagramas de estados, diagramas de actividad, colaboraciones, y diagramas de secuencia. Los diagramas de estado especifican el ciclo de viada de las instancias de los caso de uso en trminos de estados y transiciones entre los estados. Cada transicin es una secuencia de acciones. Los diagramas de actividad describen el ciclo de vida con mas detalles describiendo tambin la secuencia temporal de acciones que tiene lugar dentro de cada transicin. Los diagramas de colaboracin y los de secuencia se emplean para describir las interacciones entre, por ejemplo una instancia tpica de un actor y una instancia tpica de un caso de uso. En la prctica no siempre es necesario ser tan formal en la descripcin de casos de uso como trataremos en la seccin 7.4.3 detallar un caso de uso. Sin embargo, el tener en mente esta comprensin mas precisa de los casos de uso nos ayuda estructurar las descripciones de los mismos. Una instancia de caso de uso es la realizacin o ejecucin de un caso de uso. Otra forka de decirlo es que una instancia de un caso de uso es lo que el sistema lleva a cabo cuando obedece a un caso de uso .Cuando se lleva a cabo a cabo un instancia de caso de uso esta interacta con instancia de actores, y ejecuta una secuencia de acciones segn se especifica en el caso de uso. Esta secuencia se especifica en un diagrama de estados o un diagrama de actividad: es una camino a lo largo del caso de uso . puede haber muchos caminos y muchos de ellos pueden ser muy parecidos . Estas son alternativas de la secuencia de acciones para cada caso de uso. Un camino como ese a travs de un caso de uso puede ser algo parecido a lo siguiente: 1. La instancia del caso de uso se inicia y pasa a estado de comienzo. 2. El caso de uso es invocado por un mensaje externo de un actor. 3. transita a otro estado realizando una secuencia de acciones. Una secuencia de este tipo contiene clculos internos, seleccin del camino, y mensajes de salida (hacia algn actor). 4. Queda a la espera (en el nuevo estado) de otro mensaje externo de un actor. 5. es invocado (otra vez) por un nuevo mensaje, etc. Esto puede continuar sobre muchos estados asta que se termina la instancia de casos de uso. La mayora de las veces es una instancia de un actor la que invoca a la instancia del caso de uso, como se a descrito, pero tamben puede ser un evento interno al sistema al que invoque a la instancia, como cuando un temporizador programado se dispara (siempre que el temporizador se considere interno al sistema). Los casos de uso, como todos los clasificadores, tienen atributos. Estos atributos rep0resentan los valores de una instancia de un caso de uso, es decir, no pueden ser utilizados por otras instancias del caso de uso. Por ejemplo pueden considerarse que el caso de uso Sacar dinero posee atributos como la contrasea, la cuenta y la cantidad a retirar. Las instancias de los casos de uso no interactan con otras instancias de casos de uso .El nico tipo de interacciones en el modelo de casos de uso tiene lugar entre instancias de actores y entre instancias de casos de uso. El motivo es que queremos que el modelo de casos de uso sea simple e intuitivo para permitir discusiones fructferas con los usuarios finales y otros interesados, sin quedar atrapados en los detalles .No queremos tratar con

interfaces entre casos de uso, concurrencia y otros conflictos (como la comparicin de otros objetos) entre instancias de casos de uso distintas . Consideramos atmicas las instancias de casos de uso, es decir cada una de ellas se ejecuta por completo o no se ejecuta nada, sin interferencias por parte de otras instancias de casos de uso. Por tanto, el comportamiento de cada caso de uso puede interpretarse independientemente de los otros casos de uso. El considerar los casos de uso como atmicos no tiene nada que ver con que aya un gestor de transacciones subyacente que se encargue de los conflictos. Lo hacemos solamente para garantizar que podemos leer y comprender el modelo de casos de uso. Sin embargo, reconocemos que ciertamente existen temas de interferencia entre los diferentes usos de un sistema. Estos temas no se pueden resolver en el modelado de casos de uso si no que responden al anlisis y al diseo , podemos por ejemplo. Describir claramente como una clase puede puede participar en varias realizaciones de casos de uso y como puede resolverse cualquier tema de interferencia implcita entre casos de uso. Ejemplo Uno de los sistemas ms grandes del mundo El sistema mas grande jams construido por seres humanos podra ser un sistema con cerca de un billn de usuarios, a saber, la red de telecomunicaciones global. Cuando hacemos una llamada telefnica , por ejemplo , de san Francisco o Estocolmo , la llamada pasara probablemente a travs de unos 20 sistemas , incluyendo nodos de conmutacin locales , internacionales, sistemas por satlite , sistemas de transmisin y adems cada uno de estos sistemas tuvo un costo de desarrollo aproximadamente de 1000 personas al ao , y el esfuerzo de desarrollo de software constituyo en alto porcentaje de estos costo. Es sorprendente que cuando hacemos esas llamadas normalmente funcionen. Dada la complejidad y todas las diferentes personas, empresas y naciones implicadas, Por qu funciona? La razn fundamental es que cada interfaz de la red entera (es decir la arquitectura de la red) ha sido estandarizada por una misma organizacin, la UIT(La unin Internacional de Comunicaciones). La UIT ha especificado las interfaces entre todos los tipos de nodos en la red y la semntica precisa de todos ellos. La construccin de sistemas se basa en tcnicas similares alas utilizadas para construir la red global de telecomunicaciones. Primero se especifica el sistema entero como sus casos de uso, Se disea en trminos de subsistemas que colaboran. Los casos de uso del sistema en su globalidad se dividen en casos de uso. De los subsistemas que colaboran, y los subsistemas se interconectan mediante interfaces. Estas interfaces se definen de manera precisa, despus de lo cual cada subsistema por separado puede desarrollarse independientemente (como n sistema en si mismo) por una empresa diferente. UML soporta este tipo de arquitectura, y el proceso unificado puede ampliarse para desarrollar este tipo de sistema.

En realidad los casos de uso pede utilizarse no solo para especificar sistemas, si no tambin otras entidades mas pequeas, como subsistemas o clases. Por tanto un subsistema o una clase pueden tener 2 partes, cada una de las cuales describe una perspectiva: Una especificacin y una implementacin. La especificacin describe lo que el subsistema o la clase proporciona a su entorno en trminos de casos de uso. La parte de implementacin describe como se estructura internamente el subsistema o la clase para llevar a cabo su especificacin. Este entorno se compone normalmente de otros subsistemas o clases. Sin embargo, si queremos tratar el entorno de forma annima, podemos resaltarlo tambin mediante actores. Este enfoque se emplea cuando queremos tratar un subsistema como si fuese un sistema de pleno derecho como por ejemplo: Cuando queremos desarrollar el subsistema utilizando una tecnologa diferente de la que utilizamos para otros subsistemas. Podemos hacerlo siempre que proporcione los usos y casos e uso adecuados siempre que soporte las interfaces especificadas. Cuando queremos gestionar el sistema de forma separada de los otros quiz en ubicaciones geogrficas distintas. 7.2.3.1 Flujo de sucesos El flujo de sucesos para cada caso de uso puede plasmarse como una descripcin textual de secuencia de acciones del caso de uso. Por tanto, el flujo de sucesos especifica lo que el sistema hace cuando se lleva a cabo el caso e uso especificado. El flujo de sucesos tambin especifica como interacta el sistema con los actores cuando se lleva a cabo el caso de uso. Desde la perspectiva de la gestin, una descripcin de un flujo de sucesos incluyen un conjunto de secuencias de acciones que pueden ser modificadas , revisadas, diseadas, implementadas y probadas juntas, y que pueden ser descritas como una seccin o sub. Seccin del manual de usuario. Ofrecemos un ejemplo en la figura 7.4.3. 7.2.3.2 Requisitos especiales Llamndoos requisitos espaciales a una descripcin textual que agrupa todos los requisitos del tipo de los requisitos no funcionales sobre el caso de uso. Son fundamentalmente requisitos no funcionales relacionados con el caso de uso y que deben tratarse en flujos de trabajo posteriores como anlisis, diseo o implementacin. Ofrecemos un ejemplo en la figura 7.4.3. 7.2.4 Artefacto: Descripcin de la arquitectura (Vista del modelo de casos de uso) La descripcin de la arquitectura contiene una vista de la arquitectura del modelo de casos de uso, que representa los casos de uso significativos para la arquitectura (figura 7.5). La vista de la arquitectura del modelo de casos de uso debera incluir los casos de usos que describan alguna funcionalidad importante y crtica, o que impliquen algn requisito importante que deba desarrollarse pronto dentro del ciclo de vida del software. Esta vista de la arquitectura se utiliza como entrada cuando se prioriza los casos de uso para su desarrollo (Anlisis, diseo, implementacin) dentro de cada iteracin.

Figura 7.5 Descripcin de la arquitectura.

Descripcin de la arquitectura Vista de la arquitectura

Modelo de casos de uso

7.2.5 Artefacto : Glosario Podemos utilizar un glosario para definir trminos comunes importantes que los analistas utilizan al describir el sistema. Un glosario es muy til para alcanzar un consenso entre los desarrolladores relativo a la definicin de los diversos conceptos y nociones y para reducir en general el riesgo de confusiones. Habitualmente podemos obtener un glosario a partir de un modelo del negocio o de un modelo del dominio, pero debido a que es menos formal (no incluye clases o relaciones explicitas), es mas fcil de mantener y es mas intuitivo para utilizarlo con terceras personas externas como usuarios suplentes. Adems, un glosario tiende a estar mas centrado en el sistema que se va a construir en lugar de en su contexto, como es el caso de los modelos del negocio o del dominio. 7.2.6 Artefacto: Prototipo de interfaz de usuario Los prototipos de internas de usuario nos ayudan a comprender y especificar las iteraciones entre actores humanos y el sistema durante la captura de requisitos. No solo nos ayuda a desarrollar un interfaz grafica mejor, si no tambin a comprender los casos de uso. A la hora de especificar la interfaz de usuario tambin puede utilizarse otros artefactos, como los modelos de interfaz grafica y los esquemas de pantalla.

7.3 Trabajadores Al comienzo de este capitulo, explicamos los artefactos que se producen durante el modelado de casos de uso. El paso siguiente es examinar los trabajadores responsables de esos artefactos. Como dijimos en el capitulo 2 un trabajador es un puesto al cual se puede asignar una persona real. Con cada trabajador tenemos una descripcin de las responsabilidades y el comportamiento esperado del mismo. Un trabajador no es el lo mismo que un individuo: Una misma persona puede estar asignada a diferentes trabajadores durante un proyecto . Un trabajador tampoco se corresponde con un puesto o cargo concreto en una empresa ese es un tema diferente. En cambio, podemos decir que un trabajador representa una abstraccin de un ser humano con ciertas capacidades que se requieren en un caso de uso del negocio. En nuestro caso en el proceso unificado para el desarrollo de software cuando se asignan los recursos humanos a un proyecto, un trabajador representa el conocimiento y las habilidades blue alguien necesita para hacerse cargo del trabajo como trabajador del proyecto. Podemos identificar tres trabajadores que participan en el modelado de casos de uso. Cada uno con su propio conjunto de operaciones y con diferentes responsabilidades requeridas: Analista de sistemas, especificador de casos de uso y diseador de internas de usuario. 7.3.1 Trabajador: Analista de sistemas. El analista del sistema es el responsable del conjunto e requisitos que estn modelados en los casos de uso, lo que incluye todos los requisitos funcionales y no funcionales que son casos de uso especficos. El analista de sistemas es el responsable de delimitar el sistema. Encontrando los actores y los casos de uso y asegurando que el modelo e casos de uso es complejo y consistente. Para la consistencia el analista de sistemas puede utilizar un glosario para conseguir un acuerdo en los trminos comunes. Nociones y conceptos durante la captura de requisitos. Las Responsabilidades del analista de sistemas se muestran en la figura 7.6.

Analista de sistemas

ssasssistemassistmes Responsable de ssasssistemassi stmes

Actor Modelo de casos de uso

Glosario

ssasss istem assist mes

ssasssist emassis tmes

Aunque el analista de sistemas es responsable del modelo de casos de uso en particular y de los actores que contiene, No es responsable de cada caso en particular. Esto es una responsabilidad aparte que pertenece al trabajador especificador de casos de uso. El analista de sistemas es tambin el que dirige el modelado y el que coordina la captura de requisitos. Hay un analista de sistemas para cada sistema. No obstante en la practica este trabador esta respaldado por un equipo (en talleres o eventos similares) que incluye otras personas que tambin trabajan como analistas. Figura 7.6 La responsabilidades del analista del sistema durante la captura de requisitos en formas de casos de uso. 7.3.2 Trabajador: Especificador de casos de uso Habitualmente el trabajo de captura de requisitos puede no estar dirigido por un solo individuo. De hecho el analista de sistemas esta asistido por otros trabajadores que asumen la responsabilidades de las descripciones detalladas de uno a mas casos de uso. Estos trabajadores se denominan especificadotes de casos de uso. Cada especificador de casos de uso necesita trabajar estrechamente con los usuarios reales de sus casos de uso. Figura 7.7 Las responsabilidades de un especificador de casos de uso durante la captura de requisitos en forma de casos de uso

Especificador de casos de uso

Responsable de

Caso de uso

7.3.3 Diseador de internas de usuario Los diseadores de internas de usuario dan forma visual a las interfaces de usuario. Esto puede implicar el desarrollo de prototipos de interfaces de usuario para algunos casos de uso, habitualmente un prototipo para cada actor. Por tanto, es conveniente que cada diseador de interfaces de usuario de forma a las interfaces de usuario de uno a mas actores. Figura 7.8 Las responsabilidades de un diseador de interfaces de usuario durante la captura de requisitos en forma de casos de uso.

Diseador de interfaces de usuario Responsable de

Prototipo de interfaz

7.3.4 Trabajador: Arquitecto El arquitecto participa en el flujo de trabajo de los requisitos para describir la vista de la arquitectura del modelo de casos de uso. La vista de la arquitectura del modelo de casos de uso es una entrada importante para planificar las iteraciones como se describe en la seccin 7.4.2 Priorizar casos de uso Figura 7.9 Las responsabilidades de un arquitecto durante captura de requisitos en forma de casos de uso 7.4 Flujo de trabajo En la seccin anterior describimos la captura de requisitos en trminos estticos. Ahora vamos a utilizar un diagrama de actividad para describir el comportamiento dinmico. Figura 7.10 El flujo de trabajo para la captura de requisitos en forma de casos de uso, incluyendo trabajadores participantes y sus actividades. El diagrama utiliza calles para mostrar que trabajadores ejecutan que actividades; Cada actividad (Representada por ruedas dentadas) se sita en el mismo campo que el trabajador que la ejecuta. Cuando los trabajadores ejecutan las actividades, crean y modifican artefactos. Describimos los flujos de trabajo como una secuencia de actividades que estn ordenadas as que una actividad produce una salida que sirve de entrada a la siguiente actividad no obstante, el diagrama de actividad presenta solamente el flujo lgico. En el mundo real, no es necesario trabajar mediante actividades en secuencia de hecho, podemos trabajar por mltiples vas que producen un resultado final equivalente. Podemos por ejemplo, comenzar encontrando algunos casos de uso (La actividad de encontrar actores y casos de uso), solamente para darnos cuenta de que necesitamos aadir un nuevo caso de uso y as sucesivamente. Una actividad puede ser retomada muchas veces, cada una de estas puede acarrear la ejecucin de una sola fraccin de la actividad. Por ejemplo cuando retomamos la actividad de encontrar los actores y casos de uso, el nuevo resultado puede ser solamente una identificacin adicional de un caso de uso. Por tanto los caminos de una actividad a otra actividad ilustran tan solo la secuencia lgica de actividades utilizando los resultados de la ejecucin de una actividad como entrada para ejecutar otra. Primero el analista de sistemas (una persona respaldada por un equipo de analistas) ejecuta la actividad de encontrar actores y casos de uso para prepara una primera versin del modelo de casos de uso, con los actores y casos de uso identificados. El analista de

sistemas debe asegurar que el desarrollo del modelo de casos de uso captura todos los prerrequisitos que son entradas de `flujo de trabajo es decir, la lista de caractersticas y el modelo de dominio o de negocio. Entonces el arquitecto identificara los casos de uso relevantes arquitectnicamente ablando para proporcionan entradas a la priorizasin de los casos de uso (y posiblemente otros requisitos) que van a ser desarrollados en la iteracin actual de los casos de uso. Hecho esto, los especificadotes de casos de uso (Varios individuos) describen todos los casos de uso que se han priorizado. Ms o menos en paralelo con ellos, los diseadores de internas de usuario (varios individuos) sugieren las interfaces de usuario adecuadas para cada actor basndose en los casos de uso. Entonces el analista de sistemas reestructura el modelo de casos de uso definiendo generalizaciones entre los casos de uso para hacer lo mas comprensible posible. Los resultados de la primera iteracin atreves de los flujos de trabajo consiste en una primera versin del modelo de los casos de uso, los casos de uso y cualquier prototipo de internas de usuario asociado. Los resultados de cualquier iteracin subsiguiente consistirn entonces en nievas versiones de estos artefactos. Hay recordar que todos los artefactos se completan y mejoran incrementalmente a travs de las iteraciones. Los resultados de la primera iteracin a trabes de este flujo de trabajo consisten en una primera versin del modelo de casos de uso, los casos de uso y cualquier prototipo de interfaz de usuario asociado. Los resultados de cualquier iteracin subsiguiente consistirn entonces en nuevas versiones de estos artefactos. Hay que recordar que todos los artefactos se completan y mejoran incrementalmente a trabes de las iteraciones. Las distintas actividades en el modelado de casos de uso adoptan formas diferentes en diferentes fases del proyecto por ejemplo cuando un analista de sistemas ejecuta la actividad de encontrar actores y casos de uso durante la fase de inicio, identificado muchos actores y casos de uso nuevos. Pero cuando la actividad se realice durante la fase de construccin, el analista har sobre todo cambios secundarios en el conjunto de actores y casos de uso, tales como la creacin de un diagrama de casos de uso que describa mejor el modelado de casos de uso desde una perspectiva en particular. A continuacin amos a describir las actividades que tpicamente aparecen en la iteracin de elaboracin. 7.4.1 Actividad: identificamos los actores y casos de uso Identificamos los actores y los casos de uso: Delimitar el sistema en su entorno. Esbozar quien y que (Actores) interactan con el sistema, y que funcionalidad (Casos de uso) se espera del sistema. Capturar y definir un glosario de trminos comunes esenciales para la creacin de descripciones detalladas de las funcionalidades del sistema (Es decir, de los casos de uso). La identificacin de actores y casos de uso es la actividad mas decisiva para obtener adecuadamente los requisitos, y es responsabilidad del analista de sistemas. Pero el analista de sistemas no puede hacer ese trabajo solo. El analista requiere entradas de un equipo que incluye al cliente, los usuarios, y otros analistas que participan en talleres de modelado dirigido por el analista de sistemas. Algunas veces puede que tengamos un modelo del negocio el cual partir. Si es as, el equipo puede preparar un primer borrador del modelo de casos de uso ms o menos automticamente. Otras veces pueden partir del modelo del dominio o la entrada puede ser solamente una breve descripcin general o la especificacin de requisitos detallada

que incluye las caractersticas generales que se requiere. Tambin podemos tener como entrada los requisitos adicionales que no pueden ubicarse en casos de uso individale. Esta actividad consta de 4 pasos Figura 7.11 Las entradas y los resultados de identificar actores y casos de uso. Encontrar los actores. Encontrar los casos de uso. Describir brevemente cada caso de uso. Describir el modelo de casos de uso completo (Este paso tambin incluye la preparacin de un glosario de termino). Estos pasos no tiene por que ser ejecutados en ningn orden en particular y a menudo se hacen simultneamente. Por ejemplo, el diagramad de casos e uso puede actualizarse tan pronto como identifiquemos un nuevo actor o caso de uso. El resultado de esta actividad es una nueva versin del modelo de casos de uso con actores y casos de usos nuevos o cambiados. Podemos describir y dibujar superficialmente el artefacto modelo de casos de uso resultante, asta el punto de poder describir cada caso de uso en detalle que es lo que hace la siguiente actividad: Detallar un caso de uso. La figura 7.12 es una ilustracin de un diagrama de casos de uso de este tipo( madurado y reestructurado a travs de algunas iteraciones).Pronto lo describiremos con mas detalle. Figura 7.12 Casos de uso en el sistema de pagos y facturacin que soporta el caso de uso del negocio venta: Del pedido a la entrega. El papel iniciador, conectado a las asociaciones, indica que actor comienza el caso de uso. 7.4.1.1 Encontrar los actores La tarea de encontrar los actores depende de nuestro punto de partida. Cuando tenemos un modelo del negocio del cual partir, encontrar los actores resol sencillo. El analista de sistemas puede asignar un actor a cada trabajador del negocio y un actor del negocio y un actor a cada actor del negocio(es decir a cada cliente del negocio) que utilizara la informacin del sistema. En otro caso con o sin un modelo del dominio, el analista de sistemas, junto con el cliente, identifica los usuarios e intente organizarlos en categora representadas por actores. En ambos casos, debemos identificar los actores que representan sistemas externos y los actores para el mantenimiento y operacin del sistema. Hay dos criterios tiles a la hora de elegir los candidatos a actores: primero, debera ser posible identificar al menos a un usuario que pueda representar al actor candidato. Esto nos ayudaras a encontrar solamente a los actores relevantes y eliminara a los actores que solo sin fantasmas en nuestra imaginacin. Segundo debiera existir una coincidencia mnima entre los roles que desempea las instancias de los diferentes actores en relacin con el sistema. No queremos dos o mas actores que tengan en esencia los mismos roles. Si esto ocurre debemos intentar combinar los papeles en un conjunto de roles que asignaremos exclusivamente a un actor, o bien encontrar un actor generalizado que tenga asignado los roles comunes a los actores que se solapan. Este nuevo actor puede se especializado utilizando generalizaciones. Por ejemplo el comprador y el vendedor pueden ser especializados del actor cliente del banco. En primer momento es habitual

encontrar muchos actores que se solapan. Esto lleva a algunas discusiones antes de encontrar el conjunto de actores adecuado y de la definicin de las generalizaciones. El analista de sistemas da nombre a los actores y describe brevemente los papeles de cada actor y para que utilice el sistema el actor. Encontrar nombres relevantes para los actores es importante para comunicar la semntica deseada. La descripcin breve de cada actor debe esbozar sus necesidades y responsabilidades. Ejemplo Los actores comprador, vendedor y sistema de cuentas bancarias. Comprador Un comprador representa a una persona que es responsable de adquirir bienes o servicios como se describe en el caso de uso ventas: Del pedido a la entrega esta persona puede ser un individuo(es decir , no asociado a una compaa), o alguien dentro de una empresa. El comprador de bienes y servicios necesita el sistema de facturacin y pagos para enviar pedidos y pagar las facturas. Vendedor Un vendedor representa a una persona que vende y distribuye bienes o servicios. El vendedor utiliza el sistema para conseguir nuevos pedidos y entregar las confirmaciones de pedido, facturas y avisos de pago. Sistema de cuentas bancarias El sistema de facturacin y pagos se enva verificaciones de transacciones al sistema de cuentas bancarias. El resultado de este paso es una nueva versin del artefacto modelado del caso de uso con un conjunto de actores actualizado, cada uno con una breve descripcin. Estos actores brevemente descritos pueden utilizarse ahora como punto de partido para encontrar los casos de uso. 7.4.1.2 Encontrar los casos de uso Cuando el punto de partida es el modelo del negocio, encontramos los actores y casos de la forma descrita. Bsqueda de casos de uso a partir de un modelo del negocio. Se propone un caso de uso para cada rol e cada trabajador que participa en la realizacin de casos de uso del negocio y que utilizara informacin del sistema. En otros casos, el analista del sistema identificara los casos de uso a travs de los talleres con los clientes y los usuarios. El analista de sistemas va repasando los actores 1 por 1 y proponiendo los casos de uso para cada actor. Por ejemplo, pueden utilizarse las entrevistas y el storyboarding para comprender que casos de uso son necesarios: el actor necesitara normalmente casos de uso para soportar su trabajo de creacin, cambio, rastreo, eliminacin o estudio de los objetos del negocio, pedidos y cuentas, que se utilizan en los casos de uso del negocio. El actor tambin puede informar al sistema acerca de algunos sucesos externos u otras formas de representacin-el actor puede necesitar al sistema para informarle de algunos sucesos que han tenido lugar como cuando una factura ha vencido y no se ha pagado-. Puede haber tambin actores adicionales que ejecuten el inicio del sistema, su mantenimiento o su terminacin. Elegimos un nombre para cada caso de uso de forma que nos haga pensar en la secuencia de acciones concreta que aade valor a un actor. El nombre de un caso de uso a menudo

comienza con un verbo, y debe reflejar cual es el objetivo de la interaccin del actor y el sistema. En nuestro ejemplo tenemos casos de uso como pagar factura y solicitar bienes y servicios. Algunas veces es difcil decidir el mbito de un caso de uso. Una secuencia de interacciones usuario- sistema se puede especificar en un caso de uso o en varios, los cuales el actor invoca un tras otro. Como cuando decidimos si un caso de uso candidato debe ser un caso como tal, tenemos que considerar si es complejo por si mismo siempre se ejecuta como continuacin de otro caso de uso. Para ser mas es pacficos un caso de de uso entrega un resultado que se puede observar y que aade valor a un actor en concreto. esta norma practica para identificar un buen caso de uso puede ayudar a determinar el mbito apropiado de uno de ellos. Obsrvese que hay dos frases claves en estas directrices que constituyen criterios utiles para la identificacin de casos de uso, resultados de un valor y un actor en concreto: Resultado de valor: cada ejecucin satisfactoria de un caso de uso debe proporcionar algn valor al actor para alcanzar su objetivo. En algunos casos, el actor quiere pagar por el valor devuelto. Ntese que una instancia de caso de uso, como la de una llamada telefnica puede implicar a ms de un actor. En este caso, el criterio par un resultado de valor observable debe ser aplicado al actor iniciador. Este criterio resultados de valor nos ayuda a evitar encontrar casos de uso demasiado pequeos. Un actor en concreto: identificando casos de uso que proporcionen valores a los usuarios individuales reales, nos aseguramos de que los casos de uso no se harn demasiado grandes. Como pasa con los actores, los casos de uso que identificamos primero necesitan a menudo ser reestructurados u reevaluados un par de veces antes de que el modelo de casos de uso se estabilice. Los casos e uso y la arquitectura del sistema se desarrollan mediante iteraciones. Una vez que ya tenemos la arquitectura, los nuevos casos de uso que Capturemos deben ser adaptados a la arquitectura existente los casos de uso que ni se ajusten a la arquitectura elegida deben ser modificados para que encajen mejor con la arquitectura (podemos tambin mejorar la arquitectura para acomodar los nuevos casos de uso). Por ejemplo, podemos haber hecho el trabajo inicial de especificacin de un caso de uso con una interaccin particular del usuario en mente. Una vez que hemos elegido un determinado marco de trabajo de IGU puede que tengamos que modificar los casos de uso aunque estas adaptaciones sean, normalmente muy pequeas. No obstante se pueden requerir cambios mas drsticos el analista de sistemas puede proponer una forma de supervisin de la carga del sistema especificando un simulador que actu como un actor relevante que requiere casos de uso del sistema. De esta forma, se puede medir los tiempos de respuesta y otros requisitos e ejecucin. Tambin se puede medir el tiempo que un caso de uso permanece en colas internas del sistema. Estos dos enfoques pueden dar valores similares, pero el costo de su incrementacin puede ser muy diferente dependiendo de la arquitectura existente as que el analista de sistemas puede necesitar que se renegcienlos requisitos (casos de uso y dems) con el cliente para construir un sistema mejor. Ms fcil de incrementar y mantener para los desarrolladores, el cliente tambin gana con la renegociacin de los requisitos y consigue la funcionalidad del sistema antes, con una mayor calidad y un menor costo. 7.4.1.3 Describir brevemente cada caso de uso

A medida que los analistas van identificando a los casos de usos, algunas veces garabatean algunas pocas palabras explicando cada caso de uso, algunas veces solo describen los nombres. Despus, describen brevemente cada caso de uso, en primer lugar con algunas clases que resumen las acciones y mas tarde con una descripcin paso a paso de lo que el sistema necesita cuando interacta con sus actores. 7.4.1.4 Descripcin del modelo de casos de uso en su totalidad Preparamos diagramas descripciones para explicar el modelo de casos de uso en su totalidad, especialmente como se relacionan los casos de uso entre si y los actores. No hay una regla estricta sobre lo que se debe incluir en el diagrama. De hecho elegimos el conjunto de diagramas que describan ms claramente el sistema. Por ejemplo, podemos dibujar diagramas para mostrar los casos de uso que participan en un caso de uso de negocio o quizs para ilustrar los casos de uso que ejecuta un actor. Para asegurar la consistencia cuando se describe varios casos de uso concurrentemente, resulta prctico desarrollar un glosario de trminos. Estos trminos pueden derivar en las clases en un modelo del dominio o un modelo de negocio. El modelo de casos de uso requiere ser un modelo plano, como el que se describe aqu tambin puede organizarse en conjuntos de casos de uso llamados paquetes de casos de uso. Falta ejemplo Cuando la descripcin del modelo de casos de uso este preparada, dejamos que el visto bueno del modelo de casos de uso la gente que no forma parte del equipo de desarrollo (clientes y usuarios), convocando una revisin informal para determinar si: Se han capturado como casos de uso todos los requisitos funcionales necesarios. La secuencia de acciones es correcta, completa y comprensible para cada caso de uso. Se identifica algn caso de uso que no proporcione valor. Si es as, ese caso de uso debera reconsiderarse.

7.4.2 Actividad: priorizar casos de uso El propsito de esta actividad es proporcionar entradas a la priorizasin de los caos de uso para determinar cuales son necesarios para el desarrollo (es decir, anlisis, diseo, implementacin, etc.) en las primeras iteraciones, cuales pueden dejarse para mas tarde. Los resultados se recogen en la vista de la arquitectura del modelo de casos de uso. Despus. Esta vista se revisa con el jefe de proyecto, y se utiliza como entrada al hacer la planificacin de lo que debe desarrollarse en la iteracin. Hay que darse cuenta de que esta planificas con tambin necesita la consideracin de otros aspectos no tcnicos, como sus aspectos econmicos o del negocio del sistema que va hacer desarrollado. La vista de la arquitectura del modelo de casos de uso debe mostrar los casos de uso significativos desde el punto de vista de la arquitectura. Figura 7.13 las entradas y los resultados de priorizar los casos de uso. Figura 7.14 las entradas y los resultados de detallar cada casos de uso 7.4.3 Actividad: Detallar un caso de uso

El objetivo principal de detallar cada caso de uso es describir un flujo de sucesos en detalles incluyendo como comienza, termina e interactan con los actores. Con el modelo de casos de uso y los diagramas de casos de uso asociados como puntos de comienzo, el espicificador de un caso de uso individual puede ya describir cada caso de uso en detalle. El especificador de casos de uso detalla paso a paso la descripcin de cada casos de uso en una especificacin precisa de la secuencia de acciones. En esta sexy veremos: Como estructurar la descripcin para especificar todas las vas alternativas del caso de uso. Que incluir en una descripcin de casos de uso. Como formalizar la descripcin del casos de uso cuando sea necesario. Cada especificador de casos de uso debe trabajar estrechamente con los usuarios reales de los casos de uso. El especificador d los caos de uso necesita entrevistar con los usuarios quiz anotarse su compresin de los caos de uso y discutir propuestas con ellos y solicitarles que revisen la descripcin de los casos de uso. El resultado de esta actividad es la descripcin detallada de un caso de uso en particular en forma de texto y diagrama. 7.4.3.1 Estructuracin de la descripcin de los casos de uso Hemos mencionado que un caso de uso define los estados que las instancias de los casos de uso pueden tener y la posible transicin entre estos estados. Cada transicin es un secuencia de acciones que se ejecutan en un instancia del caso de uso cuando esta se dispara por efecto de un suceso, como podra ser un mensaje. El grafico de transicin de estados puede llegar a ser bastante intrincado. Por ello, debemos describir la posible transicin de estados de manera simple y precisa. Una tcnica probada es elegir un camino bsico completo desde el estado del inicio al estado final, y describir ese camino en una seccin de la descripcin. Entonces podemos describir en secciones separadas el resto de los caminos (Flechas curva) como caminos alternativos o desviaciones del camino bsico algunas veces no obstante las alternativas a desviaciones son lo suficiente pequea para explicarla en lnea como parte de la descripcin del camino bsico. Figura 7.15 Un caso de uso puede imaginarse como si tuviera un estado de comienzo (el rectngulo redondead de mas a la izquierda) , estados intermedios (Los subsiguientes rectngulos redondeados) , estados finales (el rectngulo redondeado dems a la derecha)y transiciones de un estado a otro El sentido comn determina si la descripcin debe ser en lnea o se debe crear un sesin separada para ella. Hay que recordar que el objetivo es hacer una descripcin precisa paro fcil de leer. Con cualquier tcnica que elijamos, tendremos que describir todas las alternativas sin habremos identificado cada caso de uso. Las alternativas, desviaciones, o excepciones del camino bsico pueden ocurrir por muchas razones: El actor puede elegir entre diferentes caminos en el caso de uso. Por ejemplo, durante el caso de uso pagar factura, el actor pagar puede decidir o rechazarla. Si esta implicado ms de un actor el caso de uso, las acciones de uno de ellos pueden influenciar el camino de las acciones del resto de actores. Un sistema puede detectar entradas errneas de los actores.

Algunos recursos del sistema pueden tener un mal funcionamiento, y as impedir que el sistema realice de forma adecuada su trabajo. El camino bsico elegido debe ser el camino normal, esto es, el que el usuario preexhibe como el que mas habitualmente va a seguir y aquel que proporciona el valor mas obvio al actor. Generalmente, cada camino bsico debe abarcar un par de excepciones y un par de peculiaridades que el sistema raramente necesita manejar. 7.4.3.1 Qu incluir en una descripcin de caso de uso? La descripcin de una caso de uso debe definir el estado inicial como precondicin. Como y cuando comienza el caso de uso (es decir, la primera accin a ejecutar). El orden requerido (si hay alguno) en el que las acciones se deben ejecutar. En este punto el orden se define por una secuencia enumerada. Como y cuando terminan los casos de uso. Una descripcin de caso de uso debe definir dos posibles estados finales como post condiciones. Los caminos de ejecucin que no estn permitidos. Las descripciones de caminos alternativos que estn incluidos junto con la descripcin del camino bsico. Las descripciones de los caminos alternativos que han sido extradas la descripcin del camino bsico. La interaccin del sistema con los actores y que cambios producen. Los atributos de los casos de uso pueden utilizarse como inspiracin para encontrar mas tarde clases y atributos en el anlisis y diseo por ejemplo podemos identificar una clase de diseo llamada factura, derivadas de un atributo facturado de un caso de uso. Durante el anlisis auque no es necesario configurarlo en le modelo de casos de uso. Mantenemos siempre el modelo de caos de uso prohibindolas interacciones entre las instancias de casos de uso y prohibiendo alas instancias acceder a los atributos de las otras. Hemos a menudo sobre los requisitos funcionales y como representarlos mediante casos de uso, pero tambin necesitamos certificar los requisitos no funcionales. Muchos de loes requisitos no funcionales estn resaltados con casos de uso especficos, como los requisitos para especificar la velocidad, disponibilidad, exactitud, tiempo de respuesta o utilizacin de memoria que el sistema necesita para ejecutar los casos de uso. Estos requisitos asocian como requisitos especiales, como el caso de uso en cuestin. Esto puede documentarse, por ejemplo, en una seccin separada dentro de la descripcin de casos de uso. As el sistema interacta con algunos otros sistemas, es necesario especificar esta interaccin. Estos se debe a ser en las primeras iteraciones, durante la FACE de elaboracin debido a que la realizacin de comunicaron del centro del sistema tiene habitualmente influencia en la arquitectura. Las descripciones de casos de uso se dan por finalizadas cuando se consideran comprensibles, correctas, completas y consistentes. Las descripciones son evaluadas por los analistas, los usuarios y los clientes en reuniones de realizacin que establecen al final de la captura de requisitos. Solamente los clientes y usuarios pueden verificar si los casos de uso son los correctos. 7.4.3.2 formalizacin de la descripcin de casos de uso. La figura 7.4 muestra como las transacciones hacen pasar a instancias de los casos de uso de un estado a otro. A menudo, como cuando el caso de uso tiene solamente unos pocos

restados, no necesitamos describir explcitamente los estados. Aun as, es buena idea tener una maquina de estados en nuestras mentes cuando describimos un caso de uso, para asegurarnos de que cubre todas las posibles situaciones. No obstante, en lagunas ocasiones, como cuando renuevan su sistemas en tiempo real complejo, los caos de uso pueden ser muy complejos, por eso pueden llegar a ser necesaria una tcnica de descripcin mas estructurada. La interaccin entre los actores y los casos de se puede transitar por ejemplo, por tantos estado y tantas transiciones alternativas que es casi imposible mantener consistente la descripcin textual de los casos de uso. Entonces puede ser til utilizar una tcnica de modelado visual para describir los casos de uso, estas tcnicas pueden ayudar al analista de sistemas o mejorar la comprensin de los casos de uso: pude utilizar los diagramas de estado de UML. para describir los estados de los casos de uso y las transiciones entre esos estados. Puede utilizarse los diagramas de actividad para describir las transiciones entre estados con ms detalle como consecuencia de las acciones. Los diagramas de actividad pueden describirse como una generalizacin de los diagramas de transicin de estado. Que son una tcnica bien probada que se utiliza en telecomunicaciones. Se puede usar los diagramas de interaccin para describir como interacta una instancia de casos de uso con la instancia de un actor. Los diagramas de interaccin, entonces, muestran el caso de uso y el actor participante. Figura 7.16 el diagrama de estado para el caso de uso pagar factura muestra como instancia de casos de uso pagar factura transita por los diferentes estados en una secuencia de transiciones de estados. Ntese que el uso de estos diagramas en el contexto de los casos de uso pueden llevarnos a algunas beses a largos y muy complejos diagramas que son difciles de leer y comprender. por ejemplo, un nico caso de uso puede implicar muchos estados que son difciles de nombrar de formar comprensible esto es especialmente delicado si los interesados que no son desarrollndose de software deben leer los diagramas. Tambin es muy costoso desarrollar diagramas detallado y mantenerlos consistentes con otros modelos del sistema. 7.4.4 Actividad: prototipar la interfaz de usuario El objetivo de esta actividad es construir un prototipo de interfaz de usuario. Hasta ahora, el analista de sistemas ha desarrollado un modelo de casos de uso que especifica que usuarios hay para que necesitan utilizar el sistema. Esto se ha presentado en los diagramas de casos de uso, en las descripciones generales del modelo de casos de uso y en las descripciones detalladas para cada caso de uso. Figura 7.17 las entradas y los resultados de prototipar la interfaz de usuario. Ahora necesitamos disear la interfaz de usuario que permita al usuario llevar a cabo los casos de usos de manera eficiente. Los hacemos en varios pasos. Comenzamos con los casos de uso de manera eficiente. Lo haremos en varios pasos. Comenzamos con los casos de uso e intentamos discernir que se necesita de las internes de usuario para habilitar los casos de uso para cada acto. Esto es, hacemos un diseo lgico de interfaz de usuario. Despus, creamos el diseo fsico de la interfaz de usuario y desarrollamos prototipos que ilustren como pueden utilizar el sistema los usuarios para ejecutar los

casos de uso. Mediante la especificacin de que se necesita antes de decidir como realizar la interfaz de usuario llegamos a comprender las necesidades antes intentar realizarlas. 7.4.4.1 crear diseo lgico de una interfaz de usuario. Cuando los actores interactan en el sistema como utilizaran y manipularan elementos de interfaz de usuario que representan atributos. A menudo de esto son trminos del glosario. Los actores pueden experimentar estos elementos de las interfaces de usuarios como iconos listas de elementos u objetos en un mapa de dos, y pueden manipularlos por seleccin, estos elementos actor por actor recorriendo todos los casos de uso a los que elector puede acceder, e identificando los elementos apropiados de la interfaz de usuario para cada caso de uso. Un nico elemento de interfaz de usuario puede intervenir en muchos casos de uso, desempeando un papel diferente en cada uno as, los elementos de la interfaz de usuario pueden disearse para jugar varios roles. Deberamos responder las preguntas para cada actor: Qu elementos de interfaz de usuario se necesita para posibilitar el caso de uso? Cmo deberan relacionarse unos con otros? Cmo se utilizaran en los diferentes casos de uso? Cul debera ser su apariencia? Cmo debera manipularse? Qu clase de dominio, entidades de negocio o unidades trabajo con adecuadas como elementos de la interfaz de usuario para cada caso de uso? con que elementos de la interfaz de usuario va atrabajar el actor? Qu acciones puede invocar el actor y que decisiones puede tomar? que guas de informacin va a necesitar elector antes de invocar cada accin de los casos de uso? Qu informacin debe proporcionar elector de sistema? Qu informacin debe proporciona el sistema al actor? Cules son loa valore medios de todos los parmetros de entrada salida? Figura 7.18 elementos de la interfaz de usuario para cuenta y factura con algunos de sus atributos indicados Una forma practica de trabajo es representar los elementos de interfaz de usuario mediante una nota adhesiva pegarlas en una pizarra y ordenarlas para ilustrar la apariencia de la interfaz de usuario. Seguidamente, los diseadores de interfaces de usuario describen como pueden utilizar los factores estos elementos cuando trabajen con los casos de uso. La ventaja de utilizar notas adhesivas es que pueden representar la cantidad necesaria de datos. Adems las notas adhesivas tampoco parecen permanentes-es fcil moverlas o simplemente eliminarlas-, los que hace que el usuario se sienta cmodo suponiendo cambios. 7.4.4.2 creacin de un prototipo fsicos de interfaz de una usuario Los diseadores de interfaz de usuario primero preparan unos esquemas aproximados de la configuracin de los elementos de las interfaces de usuario que constituyen interfaces de usuario tiles para los actores. Despus, bosquejan elementos adicionales necesarios para combinar varios elementos de internases de usuarios completas. Estos elementos adicionales pueden incluir contenedores de elementos de la interfaz de usuario, ventanas,

herramientas y controles; estos esquemas pueden prepararse despus del desarrollo de las notas adhesivas e identificar durante el diseo de la interfaz de usuario lgicas. Figura 7.19 una interfaz de usuario propuesta para los elementos, la interfaz relacionada cuenta y factura. Ahora estamos preparados para construir prototipos ejecutables de las configuraciones ms importantes de elementos de interfaz de usuarios. Estos prototipos pueden construirse con una herramienta d prototipazo rpido. Pueden haber varios prototipos, quiz uno para cada actor para verificar que cada actor puede verificar el caso de uso que se necesita. L esfuerzo del prototipado debe ser proporcional al valor de retorno esperado. Desarrollamos prototipos ejecutables cuando tenemos mucho que ganar en facilidad de uso por ejemplo un prototipo para los actores ms importantes, utilizamos bocetos en papel cuando no tengamos que ganar. La validacin de las interfaces de usuario a travs e revisiones de prototipos y esquemas en los primeros momento pueden prevenir muchos errores que sern mas caros de corregir despus. Los prototipos tambin pueden revisarse superficialmente a la descripcin de casos de uso, y permitir que se corrijan despus de que los casos de uso pasen a su diseador. Los revisores deben verificar cada interfaz de usuario. Permite que el actor navegue de forma adecuada. Proporciona una apariencia agradable y una forma consistente de trabajo0con una interfaz de usuario, por ejemplo, en cuanto al orden de tabulacin y teclas rpidas. Cumple con estndares relevantes como el color tamao de los botones y situacin de la barra de herramientas. Ntese que la implementacin de la interfaces de usuarios reales se construye en paralelo con el resto del sistema, esto es durante los flujos de trabajo de anlisis, diseo e implementacin. el prototipote interfaz de usuario que hemos desarrollado aqu deber entonces servir como especificacin de una interfaz de usuario. 7.4.5 estructurar el modelo de casos de uso Del modelo de casos de uso se estructura para: extraer descripciones de funcionalidad general y compartida que pueden ser utilizadas por descripciones mas especificas. Extraer descripciones u opcionales que pueden extender que pueden extender descripciones mas especificas. Antes que tengan lugar esta actividad, el analista de sistemas ha identificado los actores y los casos de uso, dibujndolos en diagramas, y explicando el modelo de casos de uso como un todo. Los especificadotes de casos de uso han desarrollado una descripcin de cada caso de uso en este punto el analista de sistemas el conjunto completo de casos de uso para ser que el modelo sea mas fcil de entender y trabajar con el. El analista debe buscar comportamientos compartidos y extensiones. 7.4.5.1 identificacin de descripciones de funcinabilidad compartida. A medida que identificamos y esbozamos las acciones de cada caso de uso, debemos tambin ir buscando acciones o parte de acciones comunes como partidas por varios casos de uso. Figura 7.20 las entradas y los resultados de encontrar generalizaciones en los casos de uso.

Con el fin de reducir la redundancia esta comparicin puede describirse una caso de uso separado que puede ser despus reutilizado por el caso de uso origina. Mostramos la relacin de reutilizacin mediante una generalizacin. la generalizacin entre casos de uso es una clase de herencia, las instancias de los casos de uso generalizados puede ejecutar todo el comportamiento descrito en el caso de uso generalizados. Dicho de otra forma, una generalizacin de un caso de uso A hacia un caso de uso B indica que una instancia del caso de uso A incluir tambin el comportamiento especificado en B. La generalizacin se emplea para simplificar la forma de trabajo y la comprensin del de modelo de casos de uso y para reutilizar casos de uso semifabricados cuando reunimos casos de uso terminados requeridos por el usuario. Cada caso de uso terminado se denomina caso de uso concreto. Los inicia un acto, y sus instancias constituyen una secuencia de acciones ejecutada por el sistema. El casos de uso semifabricado existe solamente para que otros casos de uso lo reutilicen y se les llama casos de uso abstractos. El caso de uso abstracto no puede instan ciarse por si mismo, pro una instancia de caso de uso concreto tambin exhibe el comportamiento especificado por un caso de uso abstracto que los utiliza. Para entendernos llamamos a esta instancia el caso de uso real que l actor percibe cuando interacta con el sistema. 7.4.5.2 identificacin de descripciones de funcionalidad adicionales y opcional la otra relacin entre casos de uso en la relacin de extensin (extend relationship).esta relacin modela la adicin de una secuencia de acciones de una caso de uso. Una extensin se comporta como si fuera algo que aade a la descripcin de un caso de uso. El comportamiento especificado por varias extensiones de un nico caso de uso destino puede darse dentro de una nica instancia de caso de uso. La relacin de extensin incluye tanto una condicin para la extensin para como una referencia o un punto de extensin en el caso de uso destino, es decir, una posicin en el caso de uso donde se puede hacer las adiciones una vez que llega al punto de extensin, al cual se refiere una relacin de extensin se evala la condicin de la relacin si la condicin se cumple la secuencia seguida por la instancia seguida del caso de uso incluye la secuencia de l caos de uso extendido. 7.4.5.3 identificaron de otras relaciones entre casos de uso. Tambin existen otras relaciones entre caos de uso, como las relaciones de inclusin. Podemos imaginar esta relacin, para simplificar, como una relacin inversa a la de extensin. Que proporciona la extensin explicita e incondicional a un caso de uso. Es mas cuando incluimos de caso de uso la se cuenca de comportamiento y los atributos del caso de uso incluido de capturan y no pueden modificarse y accederse- solamente pude utilizarse el resultado u funcin en un caso de uso-; esto es una diferencia en comparacin con la utilizacin de relaciones de generalizacin. La estructura de los casos de uso y de sus relaciones debe reflejar los casos de uso reales y tanto como sea pasible. Cuando ms deberan estas estructuras de los casos de uso reales, mas complicados ser comprender los casos de uso y sus propsitos. No solamente para terceras partes externas como usuarios y clientes sino tambin para los mismos desarrolladores Cada caso de uso individual necesita ser tratado como un artefacto separado. Alguien, es decir, un especificador de casos de uso, debe ser responsable de su descripcin; y en los flujos de trabajo subsiguientes- Anlisis y Diseo- debe representarse al caso de uso mediante casos de uso separados. Por este motivo los

casos de uso no deberan ser demasiadas o demasiados pequeos, conllevando as una sobrecarga de gestin significativa. Evite descomponer funcionalmente los casos de uso en el modelo de casos de uso. Esto se hace mucho mejor mediante el refinamiento de cada caso de uso en el modelo de anlisis.

7.5 Resumen del flujo de trabajo de los requisitos en este capitulo y en el anterior , hemos descrito como capturar los requisitos de un sistema en forma de: Un modelo de negocio o un modelo del dominio para establecer el contexto del sistema. Un modelo de casos de uso que capture los requisitos funcionales y los no funcionales que son especficos de casos de uso concretos. El modelo de casos de uso se realiza mediante una descripcin general un conjunto de diagramas y una descripcin detallada de cada caso de uso. Un conjunto de esbozos de interfaces de usuario y un de prototipos para cada actor que representan el diseo de las interfaces de usuario. Una especificacin de requisitos adicionales para los requisitos que son genricos y no especficos de un caso de uso en particular. Estos resultados son un muy buen punto de partida para los siguientes flujos de trabajo: anlisis diseo implementacin y prueba. Los casos de uso dirigirn el trabajo a lo largo de estos flujos de trabajo iteracin por iteracin. Para cada caso de uso del modelo de casos de uso identificaremos una realizacin de caso de uso correspondiente en la fase de anlisis y diseo de un conjunto de casos de prueba en la fase de prueba. Por tanto, los casos de uso enlazaran directamente los diferentes flujos de trabajo.