Diagramas de casos de uso.

Un caso de uso representa una interaccin tpica entre un usuario y un sistema informtico.

Un caso de uso es un grafo con dos tipos de nodos:

Actor -que representa cualquier elemento que intercambia informacin con el sistema, por lo que est fuera de l Caso de uso -Es una secuencia de intercambios en dilogo con el sistema que se encuentran relacionadas por su comportamiento Los arcos entre los actores y los casos de uso se denominan arcos de comunicacin. El actor es un agente externo. Un actor representa un cierto papel que un usuario puede jugar. Una mquina tambin puede ser un actor. Cada caso de uso tiene una descripcin informal en lenguaje natural o en un lenguaje estructurado. Un diagrama de casos de uso es un grafo que incluye: los actores un conjunto de casos de uso encerrados en un recinto, la comunicacin entre los actores y los casos de uso las generalizaciones sobre los casos de uso. Los casos de uso se representan por una elipse conteniendo el nombre, que opcionalmente podra ir debajo de la elipse. Los actores se representan con un monigote y el nombre del actor al pie de la figura. Los nombres de los actores suelen empezar por mayscula.

Descripcin de los caso de uso.

Un caso de uso describe una funcionalidad ms una interaccin entre un actor y un sistema en forma de secuencia de acciones

La descripcin se centra en lo que debe hacerse, no en la manera de hacerlo

Deben evitarse expresiones imprecisas. Se busca sencillez y claridad Puede utilizarse un lenguaje estructurado para representar secuencia, repeticiones y situaciones opcionales La descripcin debe contener:

Inicio del caso de uso

Fin del caso de uso Interaccin entre el caso de uso y los actores Intercambios de datos Cronologa y origen de los datos Construccin de Casos de uso Es un proceso iterativo. Se van descubriendo los escenarios desde el punto de vista del usuario, es decir los ACTORES. Para detectar los casos de uso es conveniente hacer las siguientes preguntas: Cules son las principales tareas de cada actor? Escribe/lee/modifica el actor alguna informacin del sistema? Informa el actor al sistema de los cambios externos? Desea el actor ser informado de cambios no esperados?Es un proceso iterativo, en el que pueden utilizarse distintas tcnicas de observacin o de entrevista estructurada (para describir los escenarios potenciales desde el punto de vista del usuario). Los casos de uso no pueden ser demasiado pequeos, ya que deben aportar algn valor al actor. En el momento de identificar los actores es conveniente distinguir entre actores principales (que son los que emplean directamente el sistema llevando a cabo las tareas ms importantes) actores secundarios (existen para que los principales puedan utilizar el sistema).

La estructura del sistema debe decidirse teniendo en cuenta a los actores principales. Proceso de elaboracin de los casos de uso Identificar a grandes trazos los casos de uso Las principales etapas de cada caso de uso se describen en un par de frases Se distingue un caso principal y se identifican los casos alternativos y excepciones Se establece un proceso iterativo en el cual los casos de uso se amplan, profundizndose en su descripcin, buscndose etapas comunes y alternativas que representar en otros caso de uso relacionados por las relaciones incluye, generaliza y extiende. Se debe cuidar que: Exista una descripcin breve que represente una verdadera imagen del caso de uso Las condiciones de arranque y parada del caso de uso estn bien definidas Los usuarios estn satisfechos de la secuencia de interacciones entre el actor y el caso de uso El problema fundamental es encontrar el nivel de abstraccin adecuado. En general si un caso de uso se hace demasiado grande, a medida que se va detallando es conveniente dividirlo en varios. Se pueden hacer preguntas como: es posible ejecutar un paso de forma independiente a los otros o siempre va encadenado con ellos? Dos pasos que siempre se encadenan forman parte habitualmente del mismo caso de uso es lgico agrupar varios pasos para documentarlos, probarlos o modificarlos en conjunto? Si es as, deben formar parte del mismo caso de uso. Escenarios Un caso de uso tiene como instancias los escenarios: situaciones concretas que deben recorrer total o parcialmente el caso de uso. Se deben consideran en lo posible todos los escenarios de modo que se pueda validar el caso de uso. La ltima comprobacin consiste por tanto en asegurar que el caso de uso represente todos los escenarios. A veces se confunde el caso de uso con alguno de sus escenarios: Si aparecen muchos casos de uso puede que sea un sntoma de una mala descripcin del sistema.

Ejemplos de casos de uso.

Sacar dinero

Sistema del banco

Cliente

Transferencia

Depositar dinero

Operador

Cajero automatico

Comprobacion del estado Vendedor Realizacin de un pedido

Cliente

Completar un pedido

empledo

Establecer creditos

Supervisor

Mtodos sobrecargados. Java permite mtodos sobrecargados (overloaded), es decir mtodos distintos con el mismo nombre que se diferencian por el nmero y/o tipo de los argumentos. A la hora de llamar a un mtodo sobrecargado, Java sigue unas reglas para determinar el mtodo concreto que debe llamar: 1. Si existe el mtodo cuyos argumentos se ajustan exactamente al tipo de los argumentos de la llamada (argumentos actuales), se llama ese mtodo. 2. Si no existe un mtodo que se ajuste exactamente, se intenta promover los argumentos actuales al tipo inmediatamente superior (por ejemplo char a int, int a long, float a double, etc.) y se llama el mtodo correspondiente. 3. Si slo existen mtodos con argumentos de un tipo ms amplio (por ejemplo, long en vez de int), el programador debe hacer un cast explcito en la llamada, responsabilizndose de esta manera de lo que pueda ocurrir. 4. El valor de retorno no influye en la eleccin del mtodo sobrecargado. En realidad es imposible saber desde el propio mtodo lo que se va a hacer con l. No es posible crear dos mtodos sobrecargados, es decir con el mismo nombre, que slo difieran en el valor de retorno. Diferente de la sobrecarga de mtodos es la redefinicin. Una clase puede redefinir (override) un mtodo heredado de una superclase. Redefinir un mtodo es dar una nueva definicin. En este caso el mtodo debe tener exactamente los mismos argumentos en tipo y nmero que el mtodo redefinido. Mtodo sobre escrito. Cada vez que una clase hereda de un mtodo tenemos que la oportunidad de sobre escribirlo. Con esto logramos que su comportamiento sea especfico para esta clase. Cuando sobre escribimos un mtodo no podemos cambiarle el modificador de acceso por uno ms restrictivo. Tambin como regla de oro, un mtodo sobre escrito debe cumplir con el contrato (signature) de la sper clase. Las reglas generales de sobre escritura son las siguientes:
La lista de argumentos tiene que ser exactamente igual. El return type debe ser igual o de un subtipo del declarado en la super clase. El modificador de acceso no debe ser ms restrictivo. Los metodos puede ser sobre escritos solo si se heredaron de una super clase.

Los mtodos sobre escritos pueden tirar cualquier excepcin unchecked (runtime ex) sin importar lo que el mtodo de la sper clase haya declarado. EL mtodo no debe tirar nuevas exceptions checked que no hayan sido declaradas en el metodo de la super clase. No podemos sobre escribir metodos marcados con final, ni con static.

Constructores. Cuando se instancia un objeto es necesario inicializar sus variables con valores coherentes. La solucin en los lenguajes orientados a objetos es emplear los constructores. Un constructor es un mtodo perteneciente a la clase que posee unas caractersticas especiales: Se llama igual que la clase. - No devuelve nada, ni siquiera void. - Pueden existir varios, pero siguiendo las reglas de la sobrecarga de funciones. -De entre los que existan, tan slo uno se ejecutar al crear un objeto de la clase. - Dentro del cdigo de un constructor generalmente suele existir inicializaciones de variables y objetos, para conseguir que el objeto sea creado con dichos valores iniciales.