Está en la página 1de 12

REPBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD NACIONAL EXPERIMENTAL POLITCNICA DE LA FUERZA ARMADA NUCLEO CARABOBO - EXTENSIN GUACARA

DIAGRAMAS CASOS DE USOS

Autores: Anaya Lisseth V-17512749 Herrera Ernesto V-14431701

Tutor: Prof. Belkys Araujo Seccin: ING. SISTEMAS 003-N

Diagramas Casos de Usos Guacara, 16 de Junio del 2.010.

Diagramas Casos de Usos Un caso de uso es una tpica interaccin entre un usuario y un sistema de computador. La esencia de los casos de uso es capturar los requerimientos de un sistema, detallando todos los escenarios que el usuario construya. Se pueden organizar casos de uso especificando relaciones de

generalizacin, include y extend entre otros. Se aplican esas relaciones para factorizar un comportamiento comn (tomando tal comportamiento de otros casos de uso que lo incluyan) y variantes (asignando tal comportamiento en otros casos de uso que lo extiendan). Durante mucho tiempo en todos los desarrollos OO las personas usaban los escenarios para ayudarse a entender los requerimientos. Sin embargo los escenarios eran tratados muy informalmente. Jacobson es conocido por cambiar esto. Mejor la visibilidad del caso de uso (su nombre para el escenario) hacia el extends que lleg a ser un elemento fundamental en el desarrollo de proyectos y en la planificacin. 1. Qu es un caso de uso? Un caso de uso es una secuencia de acciones que ejecuta un actor dentro de un sistema para lograr un objetivo particular. El resultado de la modelizacin de un caso de uso debe ser que todos los requerimientos funcionales del sistema queden descritos. Un factor importante al crear casos de uso, es que se realizan sin detallar como se implementaron. Por ejemplo, se puede especificar como un sistema ATM se comportara estableciendo en los casos de uso la manera en la que los usuarios van a interactuar; no es necesario tener conocimiento sobre la parte

Diagramas Casos de Usos interna. Los casos de uso especifican el comportamiento deseado, no determinan como se llevar a cabo. Algo muy importante acerca de esto es que permiten (al usuario final y experto del dominio) comunicarse con los desarrolladores (quien construye los sistemas que satisfagan los requerimientos) sin caer en detalles; los casos de uso permiten enfocarse a los resultados. Un actor representa un papel que un usuario puede jugar dentro de un sistema o una entidad. El conjunto de actores dentro de un modelo de caso de uso refleja todo lo que se necesita para intercambiar informacin con el sistema. Por ejemplo en un hospital algunos actores podran ser: Mdicos, Administrativos... Un usuario puede ser ms de un tipo de actor. Por ejemplo, una enfermera puede hacer tambin el trabajo de un administrativo. Del mismo modo ms de un usuario puede aparecer como un actor. Dentro de un diagrama de casos de uso, los casos de uso aparecen como valos, generalmente en medio del diagrama; los actores aparecen como figuras a la derecha y a la izquierda. Durante la elaboracin, esto es todo lo que se necesita para empezar, no hay que tratar de capturar al principio todos los detalles correctamente, slo cuando se necesiten. Si se cree que el caso de uso dado tiene grandes ramificaciones arquitectnicas ser necesario dar ms detalles. Muchos casos de uso pueden ser detallados cuando se construyen. Ningn sistema se encuentra aislado. Cualquier sistema interacta con actores humanos o mecnicos que lo utilizan con algn objetivo. Un caso de uso especifica el comportamiento de un sistema o una parte del mismo, y es una descripcin de un conjunto de secuencias de acciones, donde cada secuencia representa la interaccin de los elementos externos del sistema (sus actores) con 4

Diagramas Casos de Usos el propio sistema. Un caso de uso representa un requerimiento funcional del sistema. Por ejemplo, un caso de uso fundamental en un banco, es el procesamiento de prstamos. Grficamente, los casos de uso se representan mediante elipses.

Los casos de uso se emplean para capturar el comportamiento deseado del sistema en desarrollo, sin tener que especificar cmo se implementa ese comportamiento. Proporcionan un medio para que los desarrolladores, los usuarios finales del sistema y los expertos del dominio lleguen a una comprensin comn del sistema. Adems ayudan a validar la arquitectura y a verificar el sistema mientras evoluciona a lo largo del desarrollo. Ejemplo: Un juego de dados Se tiene un juego de dados en que un jugador lanza dos dados. Si el total obtenido es siete, el jugador gana, de lo contrario pierde. Caso de uso: Juega un juego. Participantes (actores): Jugador. Descripcin: Este caso de uso comienza cuando el jugador recoge y tira los dados. Si los puntos suman siete, gana y pierde si suman cualquier otro nmero. El diagrama UML correspondiente a este caso de uso sera similar a este: 5

Diagramas Casos de Usos

Cada caso de uso debe tener un nombre que lo distinga de otros casos de uso. Los nombres pueden ser nombres simples o nombres de camino. Estos ltimos constan del nombre del caso de uso, precedido del nombre del paquete en el que se encuentra. Ejemplo:

Un actor representa un conjunto coherente de roles que juegan los usuarios de los casos de uso cuando interactan con stos. Los actores pueden ser personas o sistemas mecnicos. Se pueden definir categoras generales de actores (como cliente en el ejemplo de abajo) y especializarlos (como ClienteComercial) a travs de relaciones de generalizacin. Ejemplo:

Los casos de uso pueden ser versiones especializadas de otros casos de

Diagramas Casos de Usos uso, casos de uso incluidos como parte de otros casos de uso, y casos de uso que extienden el comportamiento de otros casos de uso bsicos. Organizacin de casos de uso Los casos de uso pueden organizarse agrupndolos en paquetes. Tambin se pueden especificar relaciones de generalizacin, inclusin y extensin. Generalizacin significa que el caso de uso hijo hereda el comportamiento y el significado del caso de uso padre, donde el hijo puede agregar o redefinir el comportamiento del padre. La generalizacin entre casos de uso se representa como una lnea continua con una punta de flecha vaca.

Una relacin de inclusin entre dos casos de uso significa que un caso de uso base incorpora explcitamente el comportamiento de otro caso de uso en el lugar especificado en el caso base. Aqu el caso de uso base toma el comportamiento del caso de uso proveedor. Esta relacin se usa para evitar describir el mismo flujo de eventos repetidas veces, poniendo el comportamiento comn en un caso de uso aparte (que ser incluido por un caso base). Una relacin de inclusin se representa como una dependencia, usando la palabra include. Para especificar la posicin en un flujo de eventos, se usa la palabra

Diagramas Casos de Usos include seguido del caso de uso que se quiere incluir. Por ejemplo, para describir el flujo de Seguir pedido: Flujo de eventos principal: Obtener y verificar el nmero de pedido. include (validar usuario). Examinar el estado de cada parte del pedido y preparar un informe para el usuario. Una relacin de extensin entre casos de uso significa que un caso de uso base incorpora implcitamente el comportamiento de otro caso de uso en el lugar especificado indirectamente por el caso de uso que extiende al base. Un caso de uso puede extenderse solamente en ciertos puntos, llamados puntos de extensin. La extensin se puede ver como que el caso de uso que extiende, incorpora su comportamiento en el caso de uso base. Se representa como una dependencia con la palabra extend. Los puntos de extensin slo son etiquetas que pueden aparecer en el flujo del caso de uso base. Por ejemplo, el flujo de Hacer pedido podra escribirse as: Flujo de eventos principal: include (Validar usuario). Recoger los tems del pedido del usuario. (Establecer prioridad). Enviar el pedido para ser procesado. Una relacin de extensin se usa para modelar la parte de un caso de uso que el usuario puede ver como comportamiento opcional del sistema. De esta forma se separa el comportamiento opcional del obligatorio. Es decir, un caso de uso base puede, bajo ciertas condiciones, incorporar el comportamiento de otro caso de uso en el lugar especificado. Modelando el comportamiento de un elemento Por lo general, los casos de uso se utilizan para modelar el comportamiento de un elemento, ya sea un sistema completo, un subsistema o una clase. Es 8

Diagramas Casos de Usos importante centrarse en lo que hace el elemento, no en cmo lo hace. Los casos de uso sirven de base para probar cada elemento segn evoluciona durante el desarrollo. Al probar continuamente cada elemento frente a sus casos de uso, se est validando su implementacin a lo largo del desarrollo. Para modelar el comportamiento de un elemento se debe: - Identificar los actores que interactan con el elemento. - Organizar los actores similares en jerarquas, identificando los roles. - Considerar las formas ms importantes que tiene cada actor de interactuar con el elemento. Tambin hay que considerar las formas excepcionales (puntos de extensin). - Organizar estos comportamientos como casos de uso, usando las reglas de inclusin (para factorizar el comportamiento comn) y de extensin (para distinguir el comportamiento excepcional). Ejemplo 1: Sistema de ventas. Un sistema de ventas debe interactuar con clientes, los cuales efectan pedidos. Adems los clientes pueden hacer un seguimiento de sus propios pedidos. El sistema enva los pedidos y las facturas a los clientes. En algunos casos, segn la urgencia de los clientes, se puede adelantar parte del pedido (pedidos parciales).

Diagramas Casos de Usos

Como se muestra en la figura anterior, el comportamiento de este sistema se puede modelar usando los casos de uso Hacer pedido, Seguir pedido, Enviar pedido, Facturar cliente. El comportamiento comn puede factorizarse (Validar cliente) y tambin pueden distinguirse sus variantes (Enviar pedido parcial). Cada caso de uso debe incluir una especificacin de su comportamiento.

Ejemplo 2: Validacin de tarjetas de crdito. La figura de abajo muestra el contexto de un sistema de validacin de tarjetas de crdito. Se puede ver que existen dos categoras de clientes: clientes individuales, clientes corporativos. Estos actores representan los roles que juegan las personas que interactan con el sistema. Tambin hay actores que representan otras instituciones, como Comercio, con el cual el cliente realiza una transaccin para comprar un artculo o servicio, y Entidad financiera, que por lo general es una entidad bancaria donde el usuario tiene la tarjeta de crdito.

10

Diagramas Casos de Usos

Modelado del contexto de un sistema Modelando los requerimientos de un sistema Un requisito es una caracterstica de diseo, una propiedad o un comportamiento de un sistema. Cuando se enuncian los requisitos de un sistema, se est estableciendo un contrato entre los elementos externos al sistema y el propio sistema, que establece lo que se espera que el sistema haga. De aqu la importancia de que antes de construir un sistema, exista un acuerdo sobre qu debera hacer el sistema. Sin embargo, es casi seguro que la comprensin de los requisitos va a evolucionar conforme se vaya implementando el sistema de manera iterativa e incremental. La mayora de los requerimientos funcionales de un sistema, si no todos, se pueden expresar con diagramas de casos de uso. Para expresar los requerimientos funcionales tambin puede usarse desde texto sin estructura, hasta expresiones en un lenguaje formal. La principal diferencia al modelar requerimientos funcionales, es que se introducen en los diagramas, casos de uso adicionales que pueden ser invisibles para los actores, pero que son comportamientos fundamentales del sistema. La siguiente figura extiende el diagrama de casos de uso anterior. 11

Diagramas Casos de Usos

Modelado de los requisitos de un sistema

12

También podría gustarte