UNIVERSIDAD DE COSTA RICA

SEDE DEL ATLNTICO. RECINTO DE TURRIALBA. BACHILLERATO EN INFORMTICA EMPRESARIAL. IF-6100, ANLISIS Y DISEO DE SISTEMAS. PROFESOR: LVARO MENA M.

RESUMEN LECTURA No.4

ANLISIS DE CASOS DE USO.
ESTUDIANTE: WILLIAM ULLOA ARAYA. CARN: A86450

II-2011

ANLISIS DE CASOS DE USO.

Escribir casos de uso para capturar los requisitos de software que son visibles para los actores del sistema ha sido una prctica comn. Sin embargo, una confusin comn ha acompaado a esta prctica. Una vez que tengo mis casos de uso, cmo los puedo usar para llegar a mi cdigo? En esta serie de artculos se presenta un caso de estudio que analiza los requerimientos capturados en los casos de uso y las transforma en representaciones que pueden ser aplicables codificando directamente. El objetivo es clarificar suficientemente esta transformacin de modo que usted puede aplicar inmediatamente estas ideas a su actual o prximo proyecto de software. El IBM Rational Unified Process (RUP) aboga por escrito los casos de uso para captar las necesidades de funcionamiento de un sistema de software. Los casos de uso son en realidad un componente de un paquete ms amplio de requisitos de los documentos conocidos como la especificacin de software (SRS), que contiene todos los requisitos para un proyecto de software. El SRS incluye los siguientes artefactos para los requisitos: Modelo de Casos de Uso, que consiste en: Diagrama de casos de uso: Una representacin visual de los usuarios del sistema (actores) y los servicios que solicite el sistema. Definiciones Actor: Una descripcin textual de los solicitantes de los servicios prestados por el sistema, y los servicios prestados a su sistema. Descripciones de casos: Las descripciones textuales de los principales servicios que ofrece el sistema en discusin. Especificaciones complementarias: Un documento que recoge las necesidades de todo el sistema, y los aspectos funcionales del sistema que no son visibles para los actores del sistema, ni local a un caso de uso especfico. Actividad del anlisis de Casos de uso. Esta narrativa se centrar en la actividad de utilizacin de anlisis de casos en el RUP. Como se puede ver en la Figura 1, esta actividad incluye artefactos que normalmente se producen en la actividad RUP anlisis de la arquitectura.

Figura 1: Flujo de trabajo para el anlisis arquitectnico (Elaboracin temprana)

El propsito de la actividad de anlisis de casos de uso es el siguiente: -Identificar las clases que realizan los diversos flujos de eventos en un caso de uso. -Distribuir el comportamiento de casos de uso a esas clases, el uso de casos de uso en las realizaciones. -Identificar las responsabilidades, atributos y asociaciones de las clases. -Tomar nota de la utilizacin de mecanismos arquitectnicos para proporcionar la funcionalidad necesaria para el caso de uso, y el sistema de software en general. Alternativamente se puede decir que el objetivo del anlisis de casos de uso es tomar nuestra comprensin de los requisitos en los casos de uso del sistema y de forma iterativa transformar los requisitos en las representaciones que apoyan los conceptos de negocio y cumplir con los objetivos de negocio de estos requisitos. El diagrama de la Figura 2 se ha tomado del anlisis de RUP y diseo de la actividad general, que ilustra en el caso de uso Anlisis de la actividad se produce en el contexto del anlisis de otras actividades de diseo. Figura 2: Anlisis de casos de uso en la actividad de RUP

El Anlisis de casos de uso se compone de varios pasos en el RUP [RUP2003]: Para cada caso de uso en una iteracin: -Crear una realizacin de casos de uso -Completar las denominaciones de casos de uso (si es necesario) -Encontrar clases de Anlisis de Comportamiento de Caso de Uso -Distribuir el comportamiento de las clases de anlisis Para cada clase de anlisis que resulta -Describir las responsabilidades de la clase -Describir los atributos de la clase y Asociaciones -Definir los atributos de clase -Establecer asociaciones entre las clases de anlisis -Describir las dependencias entre las clases de eventos de anlisis -Conciliar las realizaciones de casos de uso -Establecer la trazabilidad -Calificar los mecanismos de anlisis -Evaluar los resultados del anlisis de casos de uso

Como muestra la Figura 3, hay algunas actividades especficas que separan la redaccin de un caso de uso de su implementacin en el cdigo. Esta ilustracin tambin muestra los pasos recomendados por el RUP en el contexto del anlisis de casos de uso. Este diagrama se convertir en nuestro plan de trabajo visual que el resto de este documento se abordan las tareas especficas dentro de estas actividades.

Figura 3: Los pasos del anlisis de casos de uso

Ejemplo de caso de uso Considere este caso de uso muy breve de un sistema de software hipottico basado en navegador para una empresa de alquiler de automviles. Aqu est una descripcin de casos de uso para el caso de uso: reservar un vehculo. Caso de uso: reservar un vehculo. Este caso de uso comienza cuando un cliente indica que desea hacer una reservacin para un coche de alquiler. El sistema le pide el cliente para la recogida y la devolucin de los lugares de reserva, as como la recoleccin y las fechas de regreso y tiempos. El cliente indica los lugares deseados y las fechas. El sistema solicita el tipo de vehculo de los deseos del cliente. El cliente indica el tipo de vehculo. El sistema presenta todos los vehculos de juego disponibles en el lugar de recogida para la fecha y hora seleccionadas. Si el cliente solicita informacin detallada sobre un vehculo particular, el sistema presenta esta informacin para el cliente. Si el cliente selecciona un vehculo de alquiler, el sistema solicita informacin de identificacin del cliente (nombre completo, nmero de telfono, direccin de correo electrnico de confirmacin, etc.) El cliente proporciona la informacin necesaria. El sistema presenta informacin sobre los productos de proteccin (por ejemplo, exencin de daos, seguro de accidentes personales) y le pide al cliente de aceptar o rechazar cada producto. El cliente indica sus opciones.

Si el cliente indica "aceptar reserva", el sistema informa al cliente que la reserva ha sido completada, y presenta al cliente una confirmacin de la reserva. Este caso de uso termina cuando la confirmacin de la reserva se ha presentado al cliente. Si usted est pensando en implementar una interfaz basada en web, este caso de uso describe ese enfoque tambin, si usted reconoce que varios pasos en un caso de uso se pueden combinar en una sola pgina del navegador (por ejemplo, los pasos 2 y 3 sera sin duda estar en la misma pgina). En el entorno Web, la confirmacin de la reserva presentada al cliente en el paso 7 es el nmero de confirmacin asociados con la transaccin de alquiler que present al actor en la pgina Web de transaccin de resumen. Tambin tenga en cuenta el estilo de caso de uso. Debe estar escrito en voz activa y en tiempo presente. Utilice un vocabulario limitado y claro. No introduzca palabras innecesarias, y sea coherente. Ahora que tenemos este caso de uso como punto de partida, vamos a seguir los pasos del RUP de Anlisis de casos de uso. Anlisis de Casos de uso Paso 1: Crear una realizacin de casos de uso El primer paso en el RUP anlisis de casos de uso es crear lo que llama en RUP realizacin de casos de uso. Como muestra la Figura 4, una realizacin de casos de uso es realmente una coleccin de varios diagramas UML que juntos tenemos que validar las clases, responsabilidades, y las interacciones de objetos necesarios para proporcionar el comportamiento en nuestro proceso de casos de uso. Figura 4: Una RUP de casos de uso para la realizacin de un sistema de reserva de vuelos.

En concreto, una realizacin de caso de uso normalmente se representa con: Un diagrama de clases UML para las clases que participan en el caso de uso en el que nos estamos enfocando (a veces llamado una vista de diagrama de clase de las clases participantes.), Y Uno o ms diagramas UML para describir la interaccin de los objetos que interactan, y las interfaces que estos objetos invocan para llevar a cabo el trabajo del proceso de casos de uso. UML define dos tipos de diagramas de interaccin: un diagrama de secuencia (que se muestra en la Figura 4), y un diagrama de colaboracin. Cualquier diagrama puede ser eficaz. Anlisis de Caso de uso Paso 2: Descripciones Suplementarias de los casos de uso. Mientras que se piensa en el anlisis, y la descripcin de casos de uso general, slo se referir a la conducta del sistema que es visible desde el exterior a un actor con el sistema. Es bastante aceptable para describir en forma resumida algunos de los aspectos internos, comportamientos no visibles del sistema, pero no tratar de disear su sistema en la descripcin de casos de uso. Como ejemplo, considere el paso 4 en nuestro caso de uso: "El sistema presenta todos los vehculos disponibles en el lugar de recogida para la fecha y hora seleccionada. Si el cliente solicita informacin detallada sobre un vehculo particular, el sistema presenta esta informacin al cliente. Aqu se ha especificado que hay una fuente de datos externa de la informacin del vehculo, e hizo alto nivel de referencia a la presentacin a travs de pginas Web. Este era un ejemplo aislado de complementar, pero lector de nuestro caso de uso puede ahora conseguir una mejor comprensin de la geografa total de comportamientos implicados en el caso de uso. Anlisis de Caso de uso Paso 3: Encontrar las clases de anlisis del comportamiento de casos de uso De acuerdo con RUP, el propsito de este paso es identificar a un candidato conjunto de clases de anlisis que ser capaz de llevar a cabo el comportamiento descrito en los nuestros casos de uso. Pero esto plantea una pregunta muy interesante e importante: Qu es una clase de anlisis? Hay dos respuestas. En primer lugar, una clase de anlisis a nivel de negocio es algo que es esencial para el dominio del negocio, sin hacer referencia a la aplicacin o las limitaciones de la tecnologa. En segundo lugar, RUP extiende esta definicin mediante la definicin de las clases de anlisis en tres categoras disjuntos: como entidad, el controlador y las clases frontera. Clases RUP de la entidad son ms o menos equivalentes a las clases de anlisis a nivel empresarial por encima. Las Clases de controladores son los procesos conscientes, y conscientes de la secuencia: ellos controlan y dirigen el flujo de control de una secuencia de ejecucin.

Clases de lmites se encargan de mediar en la transferencia de informacin y eventos entre el software que se ejecuta y el mundo exterior. Las Clases de lmites manejan las funciones de entrada y salida requeridas por un sistema de software. Las Clases se puede descubrir de muchas formas diferentes y de diferentes fuentes: -En general el conocimiento del dominio -Los sistemas anteriores que son similares -Modelos de empresa / arquitecturas de referencia -CRC (Clase / Responsabilidad / Colaborador) sesiones -Glosario de trminos -La minera de datos Una tcnica sencilla para descubrir las clases que se conoce como diseccin gramatical En la diseccin gramatical se identifican los nombres de nuestras necesidades. De estos nombres (y el sustantivo adjetivo pares): -Algunos se convertirn en las clases. -Algunos se convierten en atributos de una clase. -Algunos no tienen ninguna importancia en absoluto para nuestras necesidades. Vamos a identificar y subrayar los nombres (omitiendo los pronombres como "l") en nuestro caso de uso complementado por reservar un vehculo, de la siguiente manera: Caso de uso: reservar un vehculo a un cliente. Hay que tener en cuenta que cada ocurrencia de cualquier sustantivo, o un par adjetivosustantivo, ha subrayado. Tenemos una gran cantidad de duplicados, por lo que se renen los nombres distintos / pares en una sola lista en la Tabla 1, por orden alfabtico: Tabla 1: nombres candidato / entidades

Cmo podemos identificar cules de estos nombres candidato realmente describen las clases en nuestro dominio del problema? Un mtodo muy til es desafiar a cada sustantivo candidato con algunas preguntas simples que se muestra en la Figura 5: Figura 5: Preguntas para el descubrimiento de las clases de anlisis 1-Est el candidato dentro de nuestra frontera del sistema? Si no, podra ser un actor de nuestro sistema. 2 Este candidato tiene un comportamiento de identificacin para nuestro dominio del problema? (es decir, puede que el nombre de los servicios / funciones que se necesitan en nuestro dominio del problema y que este candidato propio y proporcionar?) 3 Este candidato tiene una estructura identificable? (es decir, podemos identificar un conjunto de datos de este candidato que se debe poseer y administrar?) 4 Este candidato tiene relaciones con los otros candidatos? Si usted encuentra un "no", entonces el candidato no sea una clase, pasar a la siguiente candidato. Si la respuesta es "s", seguir haciendo las preguntas. Si usted recibe todas las respuestas "s", la conclusin de que el candidato es una clase, y obtener el prximo candidato a evaluar. Si se confronta a cada uno de nuestros candidatos con estas preguntas, debemos obtener resultados similares a la Tabla 2: Tabla 2: Resultados del desafo de Sustantivos

Ahora han completado los tres primeros pasos en la actividad de RUP de Anlisis de Casos de Uso: Para cada caso de uso en una iteracin: -Crear una realizacin de casos de uso -Complementar la descripcin de casos de uso (si es necesario) -Encontrar clases de Anlisis de Comportamiento de Caso de Uso Si seguimos rigurosamente RUP, el paso siguiente ser RUP: - Distribuir el comportamiento de las clases de anlisis Hay tres enfoques bsicos para "dar contenido a" las clases de anlisis: -Un enfoque basado en datos -Un enfoque impulsado por el comportamiento, o -Un enfoque de la responsabilidad de motor. Para cada clase de anlisis que resulta: -Describir las responsabilidades de la clase -Establecer asociaciones entre las clases de anlisis (diagrama de anlisis de clase) -Distribuir el comportamiento de las clases de anlisis (las operaciones a descubrir) -Describir los atributos de cada clase y Asociaciones -Definir los atributos de clase -Describir las dependencias entre las clases de eventos de anlisis Caso de uso Anlisis de paso 4: Describir las responsabilidades de la clase Este paso se realiza para cada clase de anlisis que hemos identificado. Una de las responsabilidades de una clase se describen los servicios que ofrecen esta clase en nuestro sistema, y que ninguna otra clase proveer. Responsabilidades en las diferentes clases no deben superponerse. Sobre la base de nuestra comprensin de nuestro dominio de alquiler de vehculos, y en consulta con las PYME de nuestro vehculo de alquiler y los analistas de negocio, podemos documentar las responsabilidades de cada clase de anlisis, como se muestra en la Tabla 3.

Tabla 3: Las responsabilidades de cada clase de anlisis

James Rumbaugh et al. 3 define un objeto o una clase, como "un concepto, abstraccin o cosa con lmites ntidos y significado para el problema en. Es principalmente a travs de la definicin de las responsabilidades que se puede dar una clase de "fronteras suaves", una definicin clara de lo que hace, y no hace. Anlisis anlisis de Caso de uso Paso 5: Establecer asociaciones entre las clases de

Ahora que hemos definido nuestras responsabilidades de clase, vamos a desarrollar un primer diagrama UML de clases para identificar las relaciones entre las clases de nuestro anlisis. Hay cuatro tareas simples que debe llevar a cabo para desarrollar un diagrama de clases: -Identificar las clases a modelar. -Identificar cul de estas clases de anlisis tienen algn tipo de relacin con los dems. -Para cualquiera de las dos clases que tienen alguna relacin, identificar la semntica de la relacin: es una asociacin, agregacin, composicin, o herencia? -De relaciones de no herencia, identificar la multiplicidad en la relacin. (La multiplicidad es una indicacin de "cuntos objetos de esa clase podra estar relacionado en un objeto de esta clase?" Es muy similar a la de cardinalidad en el mundo del modelaje de datos.) Mediante la aplicacin de estas medidas, junto con nuestras responsabilidades clase identificada, se llega al diagrama de clases UML que se muestra en la Figura 6. Figura 6: Anlisis de diagrama de clases para el sistema de alquiler de vehculos

Hay tres tipos de relaciones UML se muestra en este diagrama de clases, indicadas por diferentes estilos de lneas. La lnea simple indica una relacin de asociacin. Esto se utiliza para indicar que las dos clases estn conectados en una relacin de igual a igual y

que cada clase puede solicitar los servicios prestados por la otra clase a travs de sus operaciones. El diamante lleno en la lnea entre la Reserva y ProtectionProduct se llama composicin (o, no compartible agregacin). Esta relacin es un "todo / parte" o una relacin de "propiedad". En este diagrama de clases de composicin el smbolo significa que la Reserva posee y gestiona cero o ms (*) ProtectionProducts que se incluyen en la reserva. Adems, la composicin dicta que si la reserva se destruye, el ProtectionProducts propiedad de la reserva deber ser destruido, ya que no tienen ninguna importancia para la empresa si no es parte de una reserva. El diamante sin cubrir en la lnea entre VehicleInventory y de vehculos se llama agregacin (o, la agregacin puede compartir). Esta es tambin una "parte entera /" o la relacin de "propiedad", pero en la agregacin de no destruir las partes (de vehculos) cuando destruimos el todo (VehicleInventory). Esto tiene sentido: slo porque una RentalLocation en particular ya no va a alquilar coches (que se convertir en un lugar exclusivo para el servicio) los vehculos pueden ser temporalmente "hurfanos", pero no destruir los objetos que representan los vehculos, slo los reasigne a otro VehicleInventory. Los nmeros y smbolos * en los extremos de las lneas de relacin se llama especificadores de multiplicidad. Estos smbolos indica la cantidad de, por ejemplo, los vehculos asociados a un cliente. O, por el contrario, el nmero de clientes asociados a un vehculo. En este diagrama de clases que tienen multiplicidad que dice: "para cada cliente, tenemos cero o ms (*) Vehculos reservados (ya sea a la vez, o en el tiempo)." La lectura de este en la direccin opuesta, tenemos "para cada vehculo, que est reservado por ningn cliente o clientes, posiblemente, muchos (en el tiempo, obviamente)." Anlisis de Caso de uso Paso 6: Distribucin de comportamiento para las clases de anlisis De qu manera estas clases se comportan e interactan para llevar a cabo el trabajo de la Reserva de un caso de uso de vehculos? Se demuestra mediante la creacin de un diagrama de interaccin UML para capturar las interacciones entre los objetos de las clases de nuestro anlisis. Hay que recordar que los diagramas UML de secuencia y diagramas de colaboracin son cada tipo de diagramas de interaccin, y son parte de nuestra realizacin de caso de uso. En la figura 7, se muestra un diagrama de secuencia de anlisis a nivel de la reserva de un caso de uso de vehculos.

Figura 7: un anlisis de la Reserva de vehculos diagrama de secuencia

Tanto los diagramas de secuencia y diagramas de colaboracin contienen informacin casi idntica, slo lo presentan de manera diferente. Elegir qu esquema a utilizar es a menudo una cuestin de conveniencia y preferencia personal. En el diagrama de secuencia de los objetos se alinean en la parte superior del diagrama, y se han frustrado lneas de vida que se extienden hacia abajo. Las flechas horizontales con el texto numeradas se llaman mensajes. En un diagrama de secuencia, la secuencia de mensajes se muestra posicional: el tiempo avanza la pgina, por lo que un mensaje de baja en el diagrama se enva despus de un mensaje que est por encima de ella. Los mensajes de inicio de una lnea de vida del objeto, y siempre terminan en una lnea de vida, por lo general salvavidas de otro objeto, pero a veces en la lnea de vida propio del objeto emisor (ver Figura 7, el mensaje # 21). El diagrama de secuencia ofrece una ventaja significativa sobre el diagrama de colaboracin, que es el script en el lado izquierdo del diagrama. Este texto est tomado del caso de uso, o el escenario, que muestra el diagrama de secuencia. El guin de este diagrama es una representacin concisa del texto en la reserva de un caso de uso de vehculos. Colocar el script en el diagrama hace que el contexto de los mensajes sea muy claro, y los enlaces de los mensajes a los objetos de los casos de uso original. Siempre es el caso de que una declaracin hecha en el caso de uso se asignarn a uno o ms mensajes enviados entre los objetos en su sistema. El diagrama de secuencia lo hace explcito. Anlisis de casos de uso Paso 7: Describir los atributos y las asociaciones En el anlisis, usted descubrir algunos de los atributos (es decir, la clase de datos variables) que las clases necesitan para cumplir con sus responsabilidades. De nuestra lista de las responsabilidades de la clase se puede deducir ciertos atributos para las clases de nuestro anlisis. Atributos adicionales se puede determinar a partir del conocimiento de dominio general (por ejemplo, tiene sentido que cada objeto de vehculos deben tener un atributo identificador nico correspondiente a mandato federal del vehculo fsico del Nmero de Identificacin Vehicular). Nota UML: Clases en UML tiene tres subcompartimentos, como se muestra a continuacin, utilizando la cuenta como el ejemplo de la clase. El diagrama de clases de la figura 8 muestra los tipos de vehculos Alquiler de anlisis, las relaciones entre ellos y una puesta en marcha inicial de los atributos apropiados a ser de propiedad en cada clase. Estos son simplemente los atributos ms evidentes de las responsabilidades de clase. Tenga en cuenta que estos atributos no tienen ni siquiera los tipos de datos todava, porque los tipos de datos son un problema de diseo.

Figura 8: asignacin inicial de los atributos de clase

Anlisis

de caso de uso Paso 8: Calificar los mecanismos de anlisis

Un mecanismo de anlisis es un componente arquitectnico de alto nivel que proporciona un servicio requerido por el dominio del problema, no el dominio tcnico, la solucin. Este negocio se traduce en un mecanismo de exigencia de anlisis llamado Persistencia: el mantenimiento de la informacin y el Estado, incluso cuando la aplicacin no se est ejecutando. Un ejemplo de la relacin entre los mecanismos de anlisis, diseo e implementacin se muestra en la Tabla 4:

Algunos de los mecanismos de anlisis ms comunes son: persistencia, comunicacin (entre los procesos o aplicaciones), manejo de excepciones, mecanismos de notificacin de eventos, mensajera, seguridad, distribucin (es decir, los objetos distribuidos) e interfaz nativa.