Bloques de construcción de uml



Descargar 150.01 Kb.
Página4/7
Fecha de conversión28.10.2018
Tamaño150.01 Kb.
1   2   3   4   5   6   7

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.


Relaciones entre actores

Los actores sólo pueden tener entre ellos relaciones de generalización. Se pueden definir categorías generales de actores y especializarlos mediante relaciones de especialización.


La relación de generalización entre actores se representa igual que la generalización entre clases y entre casos de uso, con una línea continua con la punta de flecha vacía.



Diagrama de clases

Un diagrama de clases muestra las clases que componen el sistema y las relaciones que existen entre ellos. Este diagrama se utiliza para modelar la vista de diseño estructural de un sistema. Los diagramas de clases además, pueden contener paquetes.



Clases

Una clase es la definición de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica.


Las clases se representan gráficamente con una caja dividida en tres zonas: en la zona superior se escribe el nombre de la clase, en la zona central los atributos y en la inferior las operaciones. En algunas ocasiones, para simplificar el diagrama, las clases se representan con una caja que contiene sólo el nombre.



Para especificar que una clase es abstracta, es decir que contiene al menos una operación abstracta, se escribe el nombre de la clase en cursiva.
El número de instancias que pueden crearse de una clase es su multiplicidad. Generalmente la multiplicidad de una clase es ilimitada, en un sistema suele haber muchas instancias u objetos de una clase ejecutándose. Sin embargo, a veces es necesario restringir a un número determinado el número de instancias de una clase. En estos casos, la multiplicidad se escribe en la esquina superior derecha de la clase.
UML permite especificar dos características importantes de los elementos (atributos y operaciones) de una clase: la visibilidad y el alcance.


  • Visibilidad: los elementos de una clase pueden ser públicos, protegidos o privados.




  • Los elementos públicos son visibles para los objetos de todas las clases del sistema. Un elemento público va precedido del signo +.

  • Los elementos protegidos sólo son visibles dentro de la clase y de las clases hijas. Un elemento protegido va precedido del signo #.

  • Los elementos privados solamente son visibles dentro de la clase. Un elemento privado va precedido del signo -.




  • Alcance: se pueden especificar dos niveles de alcance:




  • Instancia: cada instancia de la clase tiene su propio valor del elemento.

  • Clase: sólo hay un valor del elemento para todas las instancias de la clase. (El alcance de clase es equivalente al uso de “static” en C++ y Java). Para indicar que un elemento tiene alcance de clase se subraya.



Atributos

La sintaxis de un atributo en UML es:


[visibilidad] nombre [multiplicidad] [:tipo] [= valor inicial] [{propiedades}]
La visibilidad, como se explicó anteriormente, indica si el atributo es público, protegido o privado.
La multiplicidad de un atributo es el número de instancias del atributo que se pueden crear. Se especifica mediante una expresión encerrada entre corchetes. Por ejemplo:
impresora [1..5]: Impresora
indica que pueden existir de 1 a 5 instancias del atributo impresora. La multiplicidad suele utilizarse para especificar vectores de atributos.
Las propiedades predefinidas para los atributos son:


  • changeable: no hay restricciones para cambiar el valor del atributo.

  • addOnly: esta propiedad sólo se aplica a los atributos de multiplicidad mayor que uno. Indica que, un valor asignado no se puede borrar ni modificar, sólo se permite añadir nuevos valores al atributo.

  • frozen: no se puede modificar el valor del atributo.



Operaciones

La sintaxis de una operación en UML es:


[visibilidad] nombre [(lista de parámetros)] [:tipo de retorno] [{propiedades}]
La visibilidad indica si la operación es pública, protegida o privada.
Para especificar que una operación es abstracta se escribe el nombre en cursiva. Una operación abstracta no tiene implementación, sólo tiene cabecera. La implementación la proporcionan las clases hijas redefiniendo la operación.
La sintaxis de un parámetro es:
[dirección] nombre [:tipo] [= valor por omisión]
La dirección de un parámetro puede tomar tres valores:


  • in: parámetro de entrada.

  • out: parámetro de salida.

  • in/out: parámetro de entrada y salida.

Las propiedades predefinidas para una operación son:




  • leaf: la operación no puede ser redefinida en las clases hijas.

  • isQuery: la ejecución de la operación no modifica el estado del sistema.

  • sequential: la semántica y la integridad del objeto no se pueden garantizar en presencia de múltiples flujos de control. Los objetos invocadores de la operación deben coordinarse para que en el objeto sólo haya un único flujo al mismo tiempo.

  • guarded: la operación tiene guardas. La semántica e integridad del objeto se garantizan en presencia de múltiples flujos de control, tratando secuencialmente todas las llamadas a las operaciones con guardas del objeto.

  • concurrent: la semántica y la integridad del objeto se garantizan en presencia de múltiples flujos tratando la operación como atómica.

Las propiedades sequential, guarded y concurrent sólo se emplean cuando existe concurrencia, en presencia de objetos activos, procesos o hilos.





Compartir con tus amigos:
1   2   3   4   5   6   7


La base de datos está protegida por derechos de autor ©composi.info 2017
enviar mensaje

    Página principal