ANALISIS Y DISEO ORIENTADO A OBJETOS

Tema: Actor, Rol y Caso Practico

Jaime Albert Armas Rodrguez

Actor: Un Actor es un conjunto uniforme de personas, sistemas o mquinas externos al sistema que estamos modelando, que un rol determinado y que interactan con l.

El Actor, modela un tipo de objeto fuera del dominio del sistema pero que interacta directamente con l; lo que significa que, al definirlos empezamos a dar los lmites a nuestro sistema.

Un Actor es un rol que un usuario juega con respecto al sistema. El Rol es un concepto tomado del teatro y cine donde el artista puede interpretar varios personajes, cada personaje es justamente un rol. No debemos confundir el termino Rol con Usuario. Un usuario es aquel que accede al sistema pudiendo asumir diferentes roles (comprador, vendedor, cobrador, etc.); as, cada usuario puede acceder al sistema asumiendo el rol de diferentes actores. Un Actor tiene un nico rol para cada caso de Uso que se comunica con l.

Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino ms bien la labor que realiza frente al sistema.

Como ejemplo de la definicin anterior, tomemos el caso de un sistema de Ventas. Aqu, el caso de uso realizar una venta tiene un solo actor el Vendedor; sin embargo, el rol de vendedor puede ser realizador por un Vendedor, por el Supervisor o por el Jefe de Ventas. Si existiera un caso de uso especficamente para el Supervisor o el Jefe de Ventas entonces recin debern considerarse a stos como actores.

Los dispositivos de hardware y sistemas que interactan con el sistema que estamos modelando tambin pueden ser considerados Actores.

Representacin grfica de un actor

Los actores se representan mediante hombres de palo (stick man) tal como se muestra mas adelante. Usted puede utilizar os mecanismos de extensin previsto en el UML para estereotipar un Actor proveyendo un icono diferente que pueda ofrecer mejor visibilidad para su propsito. Por ejemplo puede representar un actor mediante un rectngulo con el estereotipo <<actor>>.

Recuerde que un actor es un tambin es un clasificador y por lo tanto puede representarse como una clase. Cada tipo de actor tiene un conjunto de especificaciones idnticas a la especificacin de una clase esto es un conjunto de compartimentos, pero con el campo adicional del estereotipo <<actor>>.

Cuando el Actor resulta ser un Sistema se suele representar mediante una computadora, para resaltar este hecho.

Posibles representaciones de un Actor. El hombre de palo es la ms utilizada. La ltima representacin es utilizada cuando se trata de sistemas

Nomenclatura de un Actor

Ya que para cada caso de uso, pueden existir diversos Actores a cada uno de ellos se le tiene que asignar un nombre. El nombre del actor se escribe debajo del icono que representa a dicho Actor.

Relaciones en los diagramas de casos de uso.

Un diagrama de caso de uso muestra las relaciones entre los actores y los casos de uso dentro de un sistema. Estas relaciones pueden ser de los siguientes tipos:

Relaciones de asociaciones entre actores y casos de uso. Relaciones de generalizacin entre actores. Relaciones de generalizacin entre casos de uso. Relaciones incluye (include) entre casos de uso. Relaciones extiende(extend) entre casos de uso

Estas relaciones son fuente de confusin as que preste especial atencin a su explicacin.

Relaciones de Asociacin En los Diagramas de Casos de Uso, una Relacin de Asociacin, representa la participacin de un Actor en un Caso de Uso. Es la ms general de las relaciones y la relacin semntica ms dbil, siempre parte de los actores y viajan en una sola direccin. A esta relacin tambin se le conoce como relacin de comunicacin, y suele estereotiparse como <<comunicates>>, aunque esto no es indispensable pues es la nica posible entre un actor y un caso de uso.

Representacin grfica de una asociacin

Se representa mediante una lnea slida. Como siempre parten de los Actores hacia los Casos de Uso no necesita colocarse una cabeza de flecha que indique la direccin.

_______________________
Representacin de una relacin de asociacin

Nomenclatura de una relacin de asociacin

Normalmente no se acostumbra a darle un nombre, pero cuando se desea detallar la asociacin puede drsele un nombre e incluso indicar su estereotipo para distinguir el propsito de la relacin. Lo ms comn es estereotipar a la relacin de asociacin como <<comunicates>>.

Relacin de generalizacin

Trata de representar la relacin entre dos objetos del mismo tipo en el cual uno de ellos se comporta igual que el otro pero que adems contiene caracteristicas adicionales que lo

diferencian. La generalizacin es una relacin de herencia y en los Diagramas de Casos de Uso puede ocurrir entre un actor y otro actor y, entre un caso de uso y otro caso de uso. El hijo hereda el comportamiento y significado del padre, y eventualmente el hijo puede sustituir al padre. Sin embargo, sin embargo el hijo puede redefinir algn comportamiento del padre, o definer algn otro comportamiento que el padre no presena.

Representacin grfica de la relacin de generalizacin

Se presenta mediante una lnea slida con cabeza de flecha hueca, apuntando desde el Caso de Uso Hijo hacia el Caso de Uso Padre, o desde Actor Hijo hacia Actor Padre.

La direccin de la flecha representa el mecansmo de herencia el hijo hereda del padre.

Representacin de una relacin de generalizacin

Nomenclatura de una Relacin de Generalizacin.

A esta relacin no es necesario colocarle un nombre pues representa en s misma un mecanismo de herencia.

Casos Tpicos

Una Relacin de Generalizacin desde un Actor A hacia un Actor B, indica que A es una especializacin de B, esto es A hereda el comportamiento de B, pero ademas posee otras caractersticas que lo diferencian de B, y que le permiten tener un comportamiento mas especializado. A puede eventualmente reemplazar a B.

Una Relacin de Generalizacin desde un Caso de Uso A hacia un Caso de Uso B, indica que A es una especializacin de B, esto es A hereda la funcionalidad de B, pero adems contiene otras funcionalidad de que lo diferencian. El caso de uso de A puede reemplazar a B.

Relacin <<include>> Al desarrollar un Diagrama de Casos de Uso a menudo nos encontramos con casos de uso que son incluidos como parte de otro u otros casos de uso, y es que algunos casos de uso pueden compartir un comportamiento comn. Este comportamiento comn es factorizado en versiones de casos de uso especializados. Una Relacin <<Include>> entre caso de usos significa que el caso de uso base incorpora explcitamente el comportamiento de otro caso de uso. El caso de uso base siempre utiliza el caso de uso incluido. El objetivo de la relacin <<include>> es permitir invocar el mismo comportamiento muchas veces, colocando el comportamiento comn en un caso de uso que puede ser invocado por otro u otros casos de uso. De manera general una relacin <<include>>, es una relacin de dependencia, puesto que su ejecucin depende siempre del caso de uso base, pues es este el que lo invoca. El caso de uso incluido no puede ejecutarse sin el caso de uso que lo incluye. Hasta antes de la versin 1.3 de UML este tipo de relacin fue llamada Relacin de Uso y se le estereotipaba como <<uses>>, pero la bibliografa oficial del UML 1.3 ya no consignaba este nombre, razn por la cual siempre nos referiremos a ella como la relacin <<include>>.

Observe que la utilizacin <<include>> est ms ligada al concepto de descomposicin funcional (muy comn en los modelos estructurados) que a los conceptos orientados a objetos. Esto es as, porque los casos de uso solamente nos sirven para averiguar lo que el usuario necesita del sistema y no cmo lo hace. Cuando necesitemos conocer ms detalle acerca del caso de uso recurrimos a otros tipos de diagramas ms estn ms relacionados con el enfoque orientado a objetos. Representacin grfica de una relacin <<include>> Se representa mediante una lnea discontinua con una cabeza de flecha abierta, desde el caso de uso base hacia el caso de uso incluido. La direccin de la flecha significa que el caso de uso base incluye al caso de uso incluido.

Nomenclatura de una relacin <<include>> La flecha es nombrada con la palabra clave <<include>> y no es necesario colocarle algn otro nombre. Casos Tpicos Una Relacin <<Include>> desde un Caso de Uso A hacia un Caso de Uso B, indica que una instancia de A debe tambin incluir el comprtamiento especificado por B. El comportamiento es incluido junto a la ubicacin en la cual est definida A. Esto significa que cada vez que utilice el caso de uso A, siempre se utilizar el caso de uso B.

Es posible que el caso de uso B, pueda ser invocado por varios casos de uso, tal como se muestra en el diagrama adjunto. Esto nos indica que B, es un comportamiento comn a A y C, que ha sido factorizado para evitar definirlo nuevamente, permitiendo su reutilizacin.

Relacin <<Extend>> Una Relacin <<Extend>> entre otros casos de uso significa que se ejecuta el caso de uso base pero, bajo ciertas condiciones, este caso de uso llama a otro caso de uso que extiende el comportamiento del primero. Esto significa que el caso de uso base implcitamente incorpora el comportamiento de otro caso de uso.

Se debe utilizar para modelar la parte del caso de uso que tiene un gran comportamiento opcional, as podemos separar el comportamiento que siempre ocurrir del comportamiento que ocurrir bajo ciertas condiciones.

Para encontrar las relaciones <<extend>> debemos observar los casos de uso similares, pero que contengan alguna diferencia en cmo realizan las operaciones y qu casos de uso redefinen la forma de realizar stas operaciones dentro de otro caso de uso. Se debe pensar en la conducta normal en un caso y la conducta inusual en otro caso, unidos por la relacin <<extend>>. De manera general una relacin <<extend>> es tambin una relacin de dependencia, puesto que el caso de uso extendido entra en accin dependiendo de las condiciones que se den al efectuarse el caso de uso base. Recuerde que el caso de uso extendido, slo se utilizar bajo ciertas condiciones.

Nomenclatura de una relacin <<extend>> La flecha es nombrada con el estereotipo <<extend>> La condicin de la extensin es opcional presentada despus de la palabra clave. Casos Tpicos Una Relacin <<extend>> desde un Caso de Uso A hacia un Caso de Uso B, indica que una instancia de B puede ser extendida al comportamiento especificado por A. El caso de uso A, ser ejecutado cuando al ser ejecutado B, se den las condiciones que activen A. Esta relacin se sujeta a las condiciones especificadas en la extensin. El comportamiento es insertado en la ubicacin definida en el punto de extensin de B, el cual es referenciado por la relacin <<extend>>

Cuando usar <<include>> y <<extend>> Ambos tipos de relacin implican la factorizacin de comportamientos comunes de varios casos de uso; sin embargo, en la relacin <<include>> se trata de factorizar comportamientos comunes para no repetir la definicin y los casos de uso factorizados pueden ser utilizados por otros casos de uso; mientras que en la relacin <<extend>> se tienen en cuenta los factores variantes, estos casos ocurren bajo ciertas circunstancias, poniendo este comportamiento en otro caso de uso el comportamiento comn mediante relaciones <<include>> y distinguiendo las variaciones mediante relaciones <<extend>> con el objetivo de crear un simple, balanceado y comprensible conjunto de casis de uso para su sistema. Relacin <<extend>> los Actores siguen conectados con los casos de uso extendidos. En la relacin <<include>> es el caso de uso base el que se conecta con el caso de uso incluido al invocarlo. Sugerencia:

Utilice <<extend>> cuando describa una variacin de la conducta normal. Utilice <<include>> cuando un caso de uso siempre es usado por otro u otros casos de uso y desee evitar repeticiones. Ejemplo: Se tiene una maquina lavadora de botellas, tarros y bidones. Muestre los siguientes requerimientos mediante un diagrama de casos de uso: El cliente deposita los tems y automticamente se le entrega un vale. El cliente puede imprimir en cualquier momento un recibo que indique el tem depositado y la cantidad. El operador presiona el botn de comienzo para iniciar el lavado. El operador desea saber cuntos tems han sido procesador en el da. Al final de cada da el operador solicita un resumen de todo lo depositado en el da. El operador debe adems poder cambiar la informacin asociada a los tems y dar una alarma en casi de eventualidad. La alarma debe tambin dispararse en el caso que el tem se atora o la impresora no tenga papel. Solucin: A continuacin se describe la construccin del diagrama de casos de uso paso a paso.

Paso 1: Los actores Como primera aproximacin identificamos a los actores que interactan con el sisyema: el Cliente y el Operador.

Paso 2: Relaciones de asociacin Luego, tenemos que un Cliente puede depositar Items e imprimir su vale y un Operador puede cambiar la informacin de un tem, iniciar el lavado, sonar la alarma, imprimir el vale para el cliente o generar un reporte diario.

Paso 3: Relaciones de generalizacin

La mquina lavadora debe saber lavar para los tres tipos de tems: lavar botellas, lavar tarros o lavar bidones.

Paso 4: Relaciones <<include>> Siempre que el cliente deposite tems se imprimir un vale. El Operador al final del da generara un reporte el cual siempre debe ser impreso.

Paso 5: Relaciones <<extend>> Cuando se est lavando el tem, y este atora se genera una alarma. Tambin se genera una alarma cuando estamos imprimiendo y falta papel.

Paso 6: Juntando las piezas. Entonces, el diagrama de casos de uso completo es: