Anexo 1 Breve descripción de uml anexo 1: Breve Descripción de uml



Descargar 0,63 Mb.
Página5/18
Fecha de conversión12.01.2017
Tamaño0,63 Mb.
1   2   3   4   5   6   7   8   9   ...   18

Actores

Los actores, como se mencionó, representan los distintos roles que los elementos del entorno desempeñan respecto al sistema. Un actor representa a todos los elementos que desempeñan el mismo rol. En el ejemplo del cajero automático, el actor Cliente representa a todos los clientes del banco que pueden utilizar el cajero.


Un mismo elemento puede desempeñar varios roles distintos, es decir, un elemento puede actuar como distintos actores en función del uso del sistema en cada momento. Es importante observar que los caso de uso están asociados con los actores, y no con los elementos concretos.
Supongamos por ejemplo, que los empleados del banco pueden utilizar el sistema software del cajero para consultar su estado y realizar estadísticas sobre su uso. Tendríamos entonces un nuevo actor del sistema, Empleado, relacionado con dos nuevos casos de uso, Consultar Estado y Realizar Estadísticas. Si los empleados del banco son además clientes del banco, podrían también utilizar el cajero como el resto de los clientes, para sacar o ingresar dinero y consultar sus cuentas. Esto quiere decir que los empleados del banco actuarán unas veces como el actor Empleado y otras como el actor Cliente. Pero, no implica que el actor Empleado esté relacionado con los casos de uso Extraer Dinero, Ingresar Dinero y Consultar Saldo.

Especificación de un caso de uso

El comportamiento de un caso de uso se especifica describiendo la secuencia de acciones que el sistema debe llevar a cabo para proporcionar un servicio. Esta secuencia de acciones, habitualmente denominada flujo de eventos, debe escribirse de forma que sea lo suficientemente clara como para que alguien ajeno al sistema pueda entenderlo fácilmente.


El estándar UML no se compromete con La especificación de un caso de uso. Los autores de UML solamente dan unas cuantas recomendaciones sobre el contenido de la especificación y la forma en qué debe escribirse. Para los autores de UML, la especificación de un caso de uso debería incluir al menos la siguiente información:


  • Cómo y cuándo empieza y acaba el caso de uso.

  • Cuándo el sistema interactúa con los actores y qué objetos intercambian.

  • Flujo de eventos básico y flujos alternativos de comportamiento.

Siguiendo estas recomendaciones proponemos la siguiente plantilla para escribir la especificación de un caso de uso. Esta plantilla además de las recomendaciones de UML incluye otras características recomendadas por A. Cockburn[], que consideramos muy útiles para la planificación y gestión del riesgo del proyecto.


Nombre o título.
Descripción: breve descripción textual del caso de uso. En esta descripción debería describirse cómo empieza el caso de uso y qué evento lo dispara.
Actores: enumeración de los actores que participan en el caso de uso.
Precondiciones: condiciones que debe tener el sistema antes de ejecutar el caso de uso.
Poscondiciones: condiciones que debe tener el sistema después de ejecutar el caso de uso. Es recomendable incluir las condiciones en caso de éxito y en caso de fallo del caso de uso.
Flujo de Eventos Principal: descripción de la interacción entre los actores y el sistema en condiciones normales, sin considerar ninguna excepción ni anomalía en la ejecución del caso de uso.
Flujos de Eventos Alternativos: descripción de la interacción entre los actores y el sistema en condiciones excepcionales.
Casos de Uso Relacionados.
Requisitos No Funcionales Relacionados.
Prioridad.

Frecuencia.



Riesgo asociado al caso de uso.
El siguiente ejemplo muestra la especificación del caso de uso Extraer Dinero.
Nombre o título: Extraer Dinero.
Descripción: El cliente solicita al cajero la cantidad que quiere retirar. El cajero comprueba si el cliente dispone de esa cantidad en su cuenta y si es así se la entrega. Antes de realizar la operación el cliente debe ser validado. Para ello, el cliente introduce en el cajero su tarjeta y su número de PIN. El cliente tiene tres intentos para introducir el PIN correcto.
Actores: Cliente.
Precondiciones: Ninguna
Postcondiciones:

En caso de éxito: el cliente obtiene la cantidad de dinero que ha solicitado, la operación queda registrada y su saldo actualizado.
En caso de fallo:

Si el cliente introduce un número de PIN erróneo tres veces, su tarjeta queda invalidada.


Si el cliente cancela la operación no hay ninguna postcondición.
Flujo de Eventos Principal:


  1. El cliente introduce la tarjeta en el cajero.

  2. El cajero solicita el número de PIN.

  3. El cliente introduce el número de PIN.

  4. El cajero comprueba el número de PIN

  5. Si el PIN es correcto, el cajero solicita la cantidad a retirar.

  6. El cliente introduce la cantidad a retirar.

  7. El cajero comprueba si el cliente dispone de esa cantidad en su cuenta y si hay suficiente dinero en el cajero.

  8. Si el cliente dispone de esa cantidad y el cajero tiene suficiente dinero, el cajero actualiza la cuenta del cliente, registra la operación, le entrega la tarjeta y el dinero al cliente y acaba el caso de uso.


Flujos de Eventos Alternativos:
3.a. El cliente puede cancelar la operación. El cajero le devuelve la tarjeta y el caso de uso acaba

5.a. Si el PIN introducido no es correcto y el cliente aún no ha consumido los tres intentos se vuelve al paso 2.

5.b. Si el PIN introducido no es correcto y el cliente ya ha consumido los tres intentos, el cajero invalida la tarjeta y el caso de uso acaba.

6.a. El cliente puede cancelar la operación. El cajero le devuelve la tarjeta y el caso de uso acaba.

8.a Si el cliente no tiene esa cantidad disponible en su cuenta o el cajero no tiene suficiente dinero, se informa al cliente y se vuelve al paso 5.
Casos de Uso Relacionados.
Requisitos No Funcionales Relacionados.
Prioridad: Alta.

Frecuencia: Alta.



Riesgo asociado al caso de uso: Medio.

Relaciones entre casos de uso

Los casos de uso pueden organizarse mediante las relaciones de uso (o inclusión), extensión y generalización entre ellos.


Uso

Esta relación significa que un caso de uso, llamado base, incorpora explícitamente el comportamiento de otro caso de uso. El caso de uso incorporado nunca se encuentra aislado. Es instanciado sólo como parte de algún caso de uso base que lo utiliza. La relación de uso se representa como una dependencia estereotipada con la etiqueta <>.


La relación de uso se utiliza para delegar un comportamiento, común a varios casos de uso (los casos de uso base), a un sólo caso de uso. En el ejemplo del cajero automático todos los casos de uso tienen un comportamiento común: el cliente debe validarse antes de retirar dinero, ingresar dinero o consultar el saldo de su cuenta. En lugar de incluir este comportamiento en cada caso de uso, como hicimos cuando escribíamos la especificación de Extraer Dinero, podemos agruparlo en un nuevo caso de uso Validar Cliente. Los casos de uso Extraer Dinero, Ingresar Dinero y Consultar Dinero utilizarán el caso de uso Validar Cliente. La figura? muestra el diagrama de casos de uso del cajero empleando las relaciones de uso.


La relación de uso debe indicarse explícitamente en el flujo de eventos de la especificación del caso base. Por ejemplo, el flujo de eventos principal de la especificación del caso de uso Extraer Dinero debería escribirse de esta forma:


Flujo de Eventos Principal:



  1. Usa Validar Cliente.

  2. El cajero solicita la cantidad a retirar.

  3. El cliente introduce la cantidad a retirar.

  4. El cajero comprueba si el cliente dispone de esa cantidad en su cuenta y si hay suficiente dinero en el cajero.

  5. Si el cliente dispone de esa cantidad y el cajero tiene suficiente dinero, el cajero actualiza la cuenta del cliente, registra la operación y le entrega el dinero al cliente.


Extensión
L
a relación de extensión se utiliza para modelar la parte de un caso de uso que puede considerarse como un comportamiento opcional. De esta forma se separa el comportamiento opcional del obligatorio. Esta relación se representa como una dependencia estereotipada como <>.

Los puntos de extensión pueden indicarse en el diagrama con una etiqueta en la relación de extensión, indicando en el flujo de eventos del caso base la localización del punto de extensión.


Generalización

La relación de generalización entre casos de uso es como la generalización entre clases. Significa que el caso de uso hijo hereda el comportamiento y el significado del caso de uso padre. El hijo puede añadir o redefinir el comportamiento del padre y puede ser colocado en cualquier lugar donde aparezca el padre.


Supongamos que el cajero automático pudiese validar al cliente de dos formas distintas: comprobando el PIN de la tarjeta o examinando la retina. El caso de uso padre Validar Usuario podría tener dos casos de uso hijos especializados Comprobar PIN y Examinar Retina.
L
a relación de generalización se representa igual que la generalización entre clases, con una línea continua con la punta de flecha vacía.


1   2   3   4   5   6   7   8   9   ...   18


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal