MODELADO DINAMICO

Es un sistema físico cuyo estado evoluciona con el tiempo. El comportamiento en dicho estado se puede caracterizar determinando los límites del sistema, los elementos y sus relaciones; de esta forma se puede elaborar modelos que buscan representar la estructura del mismo sistema.

Al definir los límites del sistema se hace, en primer lugar, una selección de aquellos componentes que contribuyan a generar los modos de comportamiento, y luego se determina el espacio donde se llevará a cabo el estudio, omitiendo toda clase de aspectos irrelevantes.

Diagrama de actividades

Un diagrama de actividades de UML ofrece una notación rica para representar una secuencia de actividades. Podría aplicarse a cualquier propósito, pero se considera especialmente útil para visualizar los flujos de trabajo y los procesos del negocio. Formalmente, un diagrama de actividades se considera un tipo especial de diagrama de estados de UML, en el que los estados son acciones y las transiciones de los eventos se disparan automáticamente al completarse la acción. Un grafo de actividades describe grupos secuenciales y concurrentes de actividades. Un diagrama de actividades tiene el propósito de modelar los procesos reales de una organización humana. El modelado de tales negocios es un propósito importante de los diagramas de actividades, pero también se pueden utilizar para modelar actividades software de alto nivel de ejecución de un sistema, sin profundizar en los detalles internos de los mensajes.

Figura 5. 4. Diagrama de actividades: ejemplo tomado de la documentación de UML v1.3

1.1.1. Estado de Actividad.

Una actividad es la especificación de una secuencia parametrizada de

comportamiento. Una actividad muestra un rectángulo con las puntas redondeadas

adjuntando todas las acciones, flujos de control y otros elementos que constituyen

la actividad.

1.1.2. Estado de Acción.

Una acción representa un solo paso dentro de una actividad. Las acciones

se denotan por rectángulos con las puntas redondeadas.

1.1.3. Transiciones

• Un diagrama de estados relaciona eventos y estados. Un cambio de estado causado por un evento se denomina una transición.

• Un estado se dibuja como un rectángulo de esquinas redondeadas con un nombre opcional.

• Una transición se dibuja como una flecha desde el estado origen al estado destino, etiquetada con el nombre del evento que causa la transición.

• Las transiciones que abandonan un estado deben corresponder a eventos diferentes.

Si un objeto está en un estado y ocurre un evento de los que etiquetan una de sus transiciones, el objeto entra en el estado destino de la transición y se dice que la transición se ha disparado.

– Si más de una transición abandona un estado, el primer evento que ocurra causa que se dispare la transición correspondiente. Si ocurre un evento que no corresponde a una transición que abandona el estado actual, se ignora el evento.

Una secuencia de eventos corresponde a un camino a través del grafo.

• Un estado está activo cuando se alcanza mediante una transición y se convierte en inactivo cuando se abandona a través de una transición.

Descripción de transición

• La etiqueta asociada a la transición (transition description) describe las circunstancias que provocan el cambio de estado. La sintaxis UML completa es trigger [guard] / behavior.

– Trigger es un evento que causa una transición.

– Guard es una condición booleana que se evalúa cuando se produce un evento, para determinar si la transición asociada a él puede ocurrir.

– Behavior es una actividad asociada al evento, que no se puede interrumpir y que se ejecuta mientras sucede la transición.

• La actividad (behavior) asociada al evento se describe usando operaciones, atributos y enlaces del clasificador al que pertenece, así como cualquier parámetro del evento de disparo. Esta actividad puede generar explícitamente eventos, como el envío de señales o la invocación de operaciones.

– boton_izdo_raton_pulsado(localizacion) / color := capta_color (localización); pluma.poner (color)

•La combinación de condiciones de guarda y eventos de disparo permite modelar distintos tipos de cambios de estado.

• Si se especifica un evento sin condición de guarda, la transición ocurre cuando se produce el evento asociado a la transición.

• Una transición con condición de guarda se dispara cuando ocurre su evento correspondiente, pero sólo si la condición es cierta.

• También se pueden usar condiciones de guarda para modelar una elección entre transiciones.

Si no se especifican evento ni condición, la transición ocurre inmediatamente después de que finalice el comportamiento interno (si existe) del estado origen de la transición.

– Si no hay actividad asociada al estado origen, la transición sin etiqueta se dispara tan pronto como se alcanza el estado.

• Si un estado tiene una o más transiciones sin evento asociado, pero ninguna de sus condiciones de guarda se satisfacen, el estado permanece activo hasta que se verifica alguna de las condiciones o hasta que un evento causa el disparo de otra transición.

– El cambio en el valor de una condición es un evento implícito.

1.1.4. Bifurcación y Unión

Las bifurcaciones y uniones tienen la misma notación: tanto una barra

horizontal como vertical (la orientación depende de si el flujo de control va de

derecha a izquierda o hacia abajo y arriba. Estos indican el comienzo y final de

hilos actuales de control. El siguiente diagrama muestra un ejemplo de su uso.

Una unión es diferente de una combinación ya que la unión sincroniza dos

flujos de entrada y produce un solo flujo de salida. El flujo de salida desde una

unión no se puede ejecutar hasta que todos los flujos se hayan recibido. Una

combinación pasa cualquier flujo de control directamente a través de esta. Si dos o

más flujos de entrada se reciben por un símbolo de combinación, la acción a la

que el flujo de salida apunta se ejecuta dos o más veces.

1.1.5. Calles (Particiones o carriles)

Una partición de una actividad se muestra como calles horizontales o verticales. En el siguiente diagrama, las particiones se usan para separar acciones dentro de una actividad en aquellas realizadas por el departamento de contabilidad y aquellas realizadas por el cliente.

2. MODELADO FISICO ORIENTADO A OBJETOS

En el contexto del desarrollo de sistemas de software con orientación a objetos, el MOO es la construcción de modelos de un sistema por medio de la identificación y especificación de un conjunto de objetos relacionados, que se comportan y colaboran entre sí de acuerdo a los requerimientos establecidos para el sistema de objetos.