Bloques de construcción de uml



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

Características Avanzadas


Utilizando solamente las características básicas de los estados y las transiciones se puede modelar la mayoría de los comportamientos de los objetos. Sin embargo, las máquinas de estados de UML tienen varias características avanzadas que pueden ayudar a modelar comportamientos complejos.
En UML los estados pueden incluir:


  • Acciones de entrada y salida: acciones atómicas que se ejecutan siempre que se entra o se sale del estado. Las acciones de entrada se etiquetan con el evento especial entry y las de salida con exit.




  • Transiciones internas: transiciones que se manejan sin cambiar de estado. Las transiciones internas son ligeramente diferentes de las autotransiciones. Una autotransición implica salir del estado y volver a entrar en él. Por lo tanto, primero se ejecuta la acción de salida del estado, después la acción de la transición y por último la acción de entrada al estado. En cambio, en una transición interna no se abandona el estado y sólo se ejecuta la acción asociada a la transición.




  • Actividades: conjunto de acciones que realiza el objeto mientras se encuentra en ese estado. Una acción no puede ser interrumpida por un evento, pero una actividad sí. A diferencia de las transiciones internas, las actividades no son disparadas por ningún evento externo. Se etiquetan con el evento especial do.




  • Eventos diferidos: lista de eventos que no se manejan en este estado, sino que se posponen y se añaden a una cola para ser manejados por el objeto en otro estado. Los eventos diferidos se etiquetan con la acción especial defer.





Además, en UML los estados de una máquina pueden contener subestados o estados anidados. A un estado que contiene subestados se le llama estado compuesto. Los estados compuestos se representan igual que los simples, pero contienen en su interior una máquina de estados que describe el flujo de control entre los subestados.


Las transiciones de entrada a un estado compuesto pueden activar el propio estado compuesto o uno de sus subestados. Para activar el estado compuesto es necesario que la máquina de subestados tenga definido un estado inicial. En tal caso, cuando se dispara una transición de entrada al estado compuesto, se ejecuta la acción de entrada y el flujo de control pasa al subestado inicial. Si no se define un subestado inicial, las transiciones de entrada deben dirigirse a los subestados y no al estado compuesto. Cuando se dispara una transición de entrada a un subestado, primero se ejecuta la acción de entrada del estado compuesto, a continuación el flujo de control pasa al subestado y se ejecuta su acción de entrada.
Las transiciones de salida pueden tener como origen el estado compuesto o un subestado. Si el origen es un subestado, cuando se dispara la transición se ejecuta primero la acción de salida del subestado, a continuación la acción del estado compuesto y por último la acción asociada a la transición. Si el origen de la transición de salida es el estado compuesto, cuando se dispara la transición se interrumpe la ejecución de la máquina anidada; ejecutándose primero la acción de salida del subestado que tuviese el control en ese momento, después la del estado compuesto y por último la acción asociada a la transición.



Cada vez que se dispara una transición de entrada a un estado compuesto, la máquina de estados anidada comienza de nuevo su ejecución en el estado inicial. Sin embargo, en algunas ocasiones puede resultar útil que la máquina recuerde el último estado en el que se encontraba y comience su ejecución desde ese estado. Para modelar este tipo de comportamiento UML introduce los estados de historia. Un estado de historia se representa con un círculo con el símbolo H.




El estado de historia debe tener una única transición de salida hacia otro subestado. La primera vez que se activa el estado compuesto, aún no hay historia, y se ejecuta esta transición. Si se dispara una transición de salida, el estado de historia recordará el último estado que estaba ejecutándose en la máquina antes de salir del estado compuesto. A partir de ese momento ya hay historia. Cuando se produzca una nueva transición de entrada el control pasará al último estado activo.


L
os estados compuestos pueden contener subestados concurrentes. Si todos los subestados son secuenciales, el estado compuesto contendrá sólo una máquina anidada. Si existen subestados concurrentes, el estado compuesto contendrá varias máquinas, una por cada tado concurrente.

Cuando se activa un estado compuesto que contiene subestados concurrentes, el flujo de control se divide en tantos flujos como máquinas anidadas haya. Las máquinas se ejecutarán en paralelo mientras el estado compuesto esté activo. Si una de las máquinas llega a su estado final, espera en ese estado a que todas las demás acaben de ejecutarse. Cuando todas las máquinas han alcanzado su estado final, el control vuelve a unirse en un único flujo.


Las máquinas de subestados concurrentes no pueden contener estados de historia.

Diagrama de actividades

Los diagramas de actividades de UML son similares a los diagramas de flujo tradicionales. Generalmente se utilizan para modelar flujos de trabajo o para describir detalladamente una operación.


En UML los diagramas de actividades son un caso particular de los diagramas de estado que muestran un flujo de control. En estos diagramas los estados representan actividades o acciones. Una acción es una operación atómica indivisible que no puede ser interrumpida durante su ejecución. Una actividad es una operación no atómica que puede descomponerse en otras actividades o acciones y que puede ser interrumpida durante su ejecución. Gráficamente no hay ninguna diferencia entre un estado de actividad y un estado de acción, ambos se representan con una caja de bordes redondeados.
Para indicar el estado inicial y final de la actividad global se utilizan los mismos símbolos que en los diagramas de estado: un círculo negro para el estado inicial y un círculo negro dentro de un círculo blanco para el estado final.
Cuando se completa la actividad o la acción de un estado, el flujo de control pasa inmediatamente al estado siguiente. La transición de un estado a otro se indica con una flecha continua.
Como en un cualquier diagrama de flujo se pueden especificar bifurcaciones dibujándolas con un rombo. Una bifurcación tiene una transición de entrada y dos o más transiciones de salida. En cada transición de salida se escribe una expresión entre corchetes, llamada guarda, que indica las condiciones bajo las que se sigue esa transición. Las guardas deben cubrir todas las condiciones posibles de salida para que el flujo de control no se interrumpa en ningún caso. Pero, para evitar ambigüedades en el flujo de control, las guardas no deben solaparse.


En un diagrama de actividades, es posible especificar flujos de control concurrentes. La unión y la división de estos flujos se indican mediante barras de sincronización. Una barra de sincronización se representa con una línea continua ancha que une varios flujos concurrentes en uno sólo, o divide un único flujo en varios hilos concurrentes.





Cuando se modelan flujos de trabajo de organizaciones, resulta muy útil dividir el diagrama de actividades en grupos que se correspondan con las distintas divisiones o unidades de la organización. Dentro de cada grupo se encontrarán las actividades de las que es responsable cada unidad. En UML, a estos grupos se les denomina calles porque el aspecto del diagrama recuerda a una pista de atletismo dividida en calles.


Aunque no es muy frecuente, se pueden incluir en el diagrama los objetos implicados en el flujo de control. Los objetos se unen con una dependencia a la actividad que los crea, modifica o destruye. A este uso de los objetos y las relaciones de dependencia se le denomina flujo de objetos. Debajo del nombre del objeto, se puede mostrar el estado del objeto con un nombre entre corchetes y el valor de sus atributos en un compartimento.




Diagrama de componentes

En UML los componentes representan elemento físicos del sistema, por ejemplo ejecutables, páginas HTML, librerías, tablas, ficheros, etc. Gráficamente, un componente se dibuja mediante una caja con pestañas.




Un diagrama de componentes muestra la organización y las dependencias entre un conjunto de componentes. Los diagramas de componentes pueden contener paquetes para organizar los elementos.


L
os componentes se comunican mediante interfaces. Es decir, un componente ofrece sus servicios a los demás exportando interfaces y los otros componentes acceden a sus servicios importando estas interfaces. La exportación de una interfaz se puede representar de dos formas. Si se utiliza la forma expandida de la interfaz para hacer explícitas sus operaciones, la exportación se representa como una relación de realización. Figura 1. Sin embargo, en los diagramas de componentes, lo más frecuente es utilizar la forma simplificada de la interfaz (la piruleta) y representar la exportación mediante una línea continua que une el componente a la interfaz.. Figura 2. La importación de una interfaz se representa mediante una relación de dependencia.
Figura 1.


Figura 2.

UML define cinco estereotipos estándar aplicables a los componentes:


  • executable: especifica un componente que se puede ejecutar en un nodo (archivos .EXE).

  • library: especifica una librería de objetos estática o dinámica (DLL).

  • table: especifica una tabla de una base de datos.

  • file: especifica un fichero que puede contener código fuente o datos.

  • document: especifica un documento.

Muchas herramientas de modelado proporcionan iconos específicos para representar estos estereotipos. Estos iconos no forman parte del estándar UML como tal, pero su uso está tan extendido entre la comunidad de usuarios que pueden considerarse un estándar “de facto”. Además, las herramientas también suelen incluir estereotipos para modelar aplicaciones Web que aún no forman parte de UML, pero posiblemente estarán incorporados en próximas versiones.


G
eneralmente, cuando se utilizan estos estereotipos, no se muestran las interfaces en el diagrama. En su lugar, se utiliza una notación simplificada, dibujando las dependencias directamente del componente que importa la interfaz hacia el componente que la exporta.

Diagrama de despliegue

Los diagramas de despliegue modelan la topología del hardware sobre el que se ejecuta el sistema software. Este tipo de diagramas suele utilizarse para modelar sistemas distribuidos o sistemas empotrados. En los sistemas monolíticos, generalmente, resultan innecesarios.


Un diagrama de despliegue muestra la configuración de los nodos del sistema. En UML, un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional que, generalmente, tiene alguna memoria y, a menudo, capacidad de procesamiento. Habitualmente los nodos representan procesadores y dispositivos hardware.
G
ráficamente, un nodo se dibuja como un cubo. Las conexiones físicas entre los nodos se representan mediante relaciones de asociación.

Figura 1
Los diagramas de despliegue pueden contener paquetes para organizar los nodos.


Cuando se modela la topología de los sistemas distribuidos y empotrados, es importante especificar la distribución física de los componentes software sobre los nodos. A menudo, resulta útil visualizar esta distribución en el diagrama de despliegue. Para ello, UML proporciona dos alternativas:


  • añadir a cada nodo un compartimento adicional con la lista de los componentes que se ejecutan sobre él. Figura 2.

  • incluir en el diagrama de despliegue los componentes y conectar, cada nodo con los componentes que se ejecutan sobre él, mediante una relación de dependencia. Figura 3.





Figura 2.

Figura 3.

Paquetes

Un paquete es un mecanismo de propósito general para organizar elementos en grupos. Gráficamente se representa como una carpeta.



Los paquetes se utilizan para organizar los elementos de los diagramas en grupos a los que se puede dar un nombre y manejar como un conjunto.


Si estamos desarrollando una aplicación trivial, probablemente podremos representar todo el sistema en un diagrama que contenga unos cuantos elementos y resulte fácil de entender e interpretar. Pero, en un sistema complejo, el número de elementos y de relaciones necesarias para modelar el sistema completo puede exceder la capacidad humana de comprensión. Por esta razón se agrupan los elementos en paquetes y el contenido de cada paquete se muestra en un diagrama distinto.
Los paquetes pueden tener relaciones de dependencia y generalización. La relación de dependencia indica que los elementos de un paquete utilizan o importan los elementos del paquete del que dependen. La generalización entre paquetes es similar a la generalización entre clases, los paquetes hijos heredan los elementos del paquete padre. La generalización entre paquetes suele utilizarse para especificar familias de paquetes.
Existen dos estereotipos de la relación de dependencia entre paquetes, <> y <>. Ambos especifican que el paquete origen tiene acceso a los elementos del paquete destino. La diferencia es que <> añade al espacio de nombres del origen el contenido del destino, evitando la calificación de nombres.


Figura 1. Relaciones entre paquetes


Los paquetes deben agrupar elementos cercanos semánticamente y que suelen cambiar juntos, tratando de minimizar las dependencias entre paquetes. De esta forma se facilita el mantenimiento y la evolución del sistema. Ante un cambio en el sistema, las modificaciones afectarán principalmente a los elementos de un paquete. Aunque habrá que revisar todos los paquetes que tengan alguna dependencia con el paquete que se ha modificado.
UML permite mostrar explícitamente el contenido de un paquete. En este caso, el nombre del paquete se coloca en la pestaña de la carpeta. (En la práctica no suele mostrarse el contenido de los paquetes de esta forma, sino que se accede al contenido de cada paquete mediante herramientas software).
Generalmente, los elementos de un paquete son públicos. Pero UML admite la posibilidad de controlar la visibilidad de los elementos de un paquete del mismo modo que se controla la visibilidad de los atributos y las operaciones dentro de una clase. Un elemento de un paquete puede ser:


  • Público: visibles en cualquier paquete que importe el paquete que lo contiene.

  • Protegido: sólo es visible dentro del paquete que lo contiene y de sus hijos.

  • Privado: sólo es visible dentro del paquete que lo contiene.

La notación para especificar la visibilidad de los elementos de un paquete es la misma que se usa para las clases: un elemento público va precedido del símbolo +, un elemento va precedido del símbolo # y un elemento privado va precedido del símbolo - . Por defecto los elementos de un paquete se consideran públicos.







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