Diagramas de implementación

El diagrama de implementación lo podemos dividir básicamente en:

• Diagrama de paquetes.
• Diagramas de componentes.
• Diagramas de despliegue.

Todos nos servirán para especificar de alguna manera como ha de ser llevada la implementación del resultado del analisis del dominio que estamos tratando.

El diagrama de componentes forma parte, junto al diagrama de paquetes, de la vista de implementación.

Los diagramas de componentes representan las dependencias entre varios componentes físicos del sistema. Muestra la organización (contención de unos dentro de otros) y las dependencias entre componentes de software.

Un componente representa un fichero fuente, una libreria o un ejecutable. Los componentes son artefactos (elementos fabricados) que forman parte de la implementación del sistema. Un componente se representa gráficamente como un rectangulo con una elipse pequeña y dos rectangulos pequeños que sobresalen del lado.

Normalmente se consideran componentes de software de tres niveles:

• Código fuente.
• Librerias.
• Ejecutables.

El nivel de código fuente muestra las dependencias de compilación entre ficheros.

En c++ serian las dependencias del include, por ejemplo.

En c# serian las dependencias del using.

En java serian las dependencias del import.

Cada clase del modelo lógico se puede realizar en el diagrama de componentes de código fuente en dos componentes: la especificación y el cuerpo. En C++, por ejemplo, una especificación corresponde a un archivo con un sufijo .hxx y un cuerpo corresponde a un archivo con sufijo .cxx.

El nivel de tiempo de ejecución muestra el mapeo de las clases a librerias en tiempo de ejecución.

La siguiente figura ilustra que la libreria Trade (Trade.dll) depende de la clase Slate (Slate.cls) y la clase Trade (Trade.cls).

El nivel de ejecutables muestra las interficies y las dependencias de las llamadas entre programas ejecutables.

Esta figura muestra que el ejecutable Trade se comunica con el ejecutable Contracts a través de la interficie TradeContract. También se comunica con la libreria Trade con la interficie TRade.

Los diagramas de despliegue (deployment) muestran la configuración del sistema en tiempo de ejecución a partir de ilustrar como los varios procesos se distribuyen en procesadores, ordenadores o otros dispositivos diferentes.
La vista de despliegue muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes, procesos y objetos que viven dentro.

El diagrama de despliegue contiene básicamente:

• Nodos: Un objeto en tiempo de ejecución que representa un recurso computacional (que generalmente tiene como mínimo memoria, y a menudo capacidad de procesar). Los esteriotipos permiten precisar la naturaleza del equipo, dispositivos, procesadores, memoria...
• Conexiones: Muestra el camino de comunicación entre varios nodos. La asociación puede tener un esteriotipo que indica la naturaleza de la comunicación (como por ejemplo, el tipo de canal o red).

1. El entorno de ejecución de una empresa que presta los servicios a internet se compone de tres servidores y dos clientes. El servidor lógico de negocio 1 contiene un componente llamado Jar1 que contiene la lógica del negocio de una aplicación web. El servidor lógica de negocio 2 contiene el mismo componente, y el tercer servidor, que se encarga de la capa web, se llama servidor aplicación web y contiene el componente War1. Este componente utiliza la interficie InterfícieJar1 implementada por Jar1 en los dos servidores que contienen el componente.

Los clientes web contienen un navegador y utiliza la interficie InterfícieWar1 del componente War1. El cliente "rich client" tiene un componente ClientJar1 que utiliza la interfície del módulo Jar1 del servidor lógico del negocio 1 mediante su interfaz.

a) ¿Para representar esta situación que tipo de daigrama UML utilizarias?

Diagrama de despliegue.
b) Dibujalo.

Diagramas de interacción

Introducción

Una interacción es la especificación del comportamiento de un caso de uso o de una operación en terminos de secuencia de mensajes entre objetos. Estos mensajes contienen estimulos que pueden ser peticiones de ejecución de operaciones o señales. Se llama hilo de ejecución a una secuencia de imagenes.

Colaboraciones

Una colaboración es un conjunto de papeles, de clasificadores o de instancias, y de papeles de asociaciones entre los objetos que intervienen en una interacción. Las colaboraciones se utilizan por coherencia entre las clases y asociaciones definidas en el modelo estático y las asociaciones y los objetos definidos en el caso de uso. Las colaboraciones se pueden definir a partir de clasificadores o de instancias.

A veces nos interesará representar multiobjetos, que representan un conjunto de objetos de un papel con multiplicidad más grande que 1 dentro de una asociación.

UML ofrece 3 diagramas para representar interacciones y colaboraciones:

• El diagrama de comunicación, pone énfasis en la descripción de la colaboración.
• El diagrama de secuencia, que pone énfasis en la sucesión temporal de mensajes en una interacción.
• El diagrama de actividades, que sirve para describir el estado de una actividad.

Diagrama de comunicación

El diagrama de colaboración es la representación de una interacción.

Parte del diagrama estático, sobre el cual se representan los mensajes de la interacción.

Cada mensaje tiene la siguiente especificación:

PREDECESORES GUARDA EXPRESIONES_SECUENCIA VALORES_RETORNO FIRMA

PREDECESORES: Lista mensajes predecesores '('NUM_SEQ, NUM_SEQ ')'

GUARDA: Condición que se tiene que cumplir para que se envíe el mensaje.

EXPRESIONES_SECUENCIA: Num_seq '['RECURRENCIA''],...,':'

RECURRENCIA: '*' '['CLAUSULA_ITERACIÓN']'

VALORES_RETORNO: Valores de retorno como consecuencia del proceso activado por el mensaje VALORES_RETORNO ',' VALORES_RETORNO ... ':='

FIRMA: Nombre estímulo y lista de argumentos.

Se puede indicar también la creación de objetos (new), destrucción (destroyed) y enlaces (transient).

Mensajes simples: corresponden a una simple ejecución dentro de un hilo de ejecución.

Mensajes asíncronos: estos mensajes se dan cuando el cliente envía un mensaje al subministrador y este acepta el mensaje. La clase que emite se espera a recibir el resultado de la operación asociada al mensaje.

Mensajes asíncronos: en este caso, la clase emisora envía un mensaje al subministrador y se continua ejecutando sin esperar que llegue el resultado de la clase receptora. En estos casos habitualmente la clase receptora pondrá en cola la ejecución de la petición recibida.
Mensaje de respuesta:
<- - - - - - - - - - - - -

Diagramas de secuencia

A diferencia de los diagramas de colaboración, los de secuencia no representan explicitamente el papel de las asociaciones. En cambio, si que representan el paso del tiempo y la durada de los mensajes.

El tiempo se representan hacia abajo, y no esta necesariamente a escala.

El horizontal, y en franges sucesivas, se representan los diferentes papeles de los clasificadores que participan en la interacción.

Los mensajes circulan de izquierda a derecha y las respuestas al revés.

Se llama línea de vida a un elemento que simboliza la existencia del papel en un cierto periodo de tiempo. Se representa por una línea vertical discontinua que va de la creación hasta la destrucción del objeto.

Para representar la destrucción de un objeto se pone una x al final de la línea de vida.

Durante la vida de un objeto pueden haber varios constructores según las condiciones que emite el mensaje.

Una activación es una parte de la línea de vida durante la cual un determinado papel ejecuta una acción o bien otros papeles ejecutan otras acciones como consecuencia de una acción ejecutada por el primero.

Las activaciones coinciden con el envío de un mensaje y la recepción de una respuesta.
Si haces llamadas reflexivas, estas se representan con otro recuadro ligeramente desplazado.
Los mensajes pueden ser del mismo tipo que los diagramas de colaboración, y las flechas se representan igual.
El orden de ejecución se representa de arriba a abajo en el tiempo.
No se identifican los números de secuencia porque están implícitos.
Pueden salir dos flechas de un mismo punto de activación si se envían dos mensajes a la vez.
Los mensajes de retorno se representan con una línea discontinua.

Concreciones y ejemplos:
Los diagramas de casos de uso, se presentan una vista externa del sistema. Los diagramas de interacción, que incluyen los de secuencia, describen como los casos de uso se realizan (se hacen realidad) como interacción entre conjuntos de objetos.

Los diagramas de secuencia muestran el flujo de mensajes (events) entre diversas instancias al largo del tiempo. De hecho, ofrecen una manera formal de especificar un escenario.
Se puede ver inmediatamente la orden en que se envían los mensajes porque el tiempo es una dimensión explícita del diagrama (eje vertical).
Cada instancia se representa mediante un recorrido vertical diferente.
Es una vista gráfica de un escenario (un camino concreto de un diagrama de casos de uso) que ilustra las interacciones entre objetos como secuencia temporal. De hecho, se puede crear a partir del caso de uso que se describe.

Actores y objetos: son los elementos que se comunican. Como tanto los objetos como los actores, son instancias, se hace uso de la nomenclatura del objeto con dos puntos y el nombre subrayado.
Lineas de vida:  son unas lineas que representan la vida de los objetos (o actores) a lo largo del tiempo. El tiempo va de arriba hacia abajo. La línea se hace gorda cuando este objeto esta ejecutando una operación. Decimos que el objeto es activo en ese momento. A menudo, los objetos dejan de existir. Para indicar el punto donde un objeto se destruye, se pone un aspa o cruz al final de la línea.

Mensajes: se representan con flechas que van de emisor a receptor y están etiquetadas con el mensaje que envían. La recepción de un mensaje hace que el objeto inicie su actividad. El retorno de la llamada se indica con una flecha a trozos. Sólo es necesario ponerlo si queremos hacer explicito lo que se devuelve. Si no, se puede suponer que devuelve cuando la zona activa del receptor acaba.

Los diagramas de secuencia permiten hacer uso de algunas estructuras de control, que van muy bien para simplificarlos.
Cuando hacemos uso de estructuras de control no estamos representando sólo un escenario concreto, sino que estamos generalizando.
Ejemplo de mensaje entre dos objetos:

Ejemplo de ejecución condicional del diagrama de secuencia.

El diagrama indica dos maneras de expresar alternativas. Una haciendo una parte de la vida condicional y otra condicionando el envío del mensaje con una guarda.

Si hiciese falta un mensaje a cada uno del conjunto de objetos, podemos simplificar el diagrama representando el conjunto de objetos con un objeto múltiple como se muestra en la figura superior.

A veces un objeto puede crear o eliminar otro objeto.
Esto se puede representar como mensajes especiales.
Un mensaje de creación no apunta a una zona activa de la línea de vida, sino que apunta al objeto mismo (Tiene que estar mas abajo que los otros).
El mensaje de destrucción apunta hacia un aspa al final de la línea de vida que representa el final de la vida del objeto.
Ejemplo de creación, destrucción y llamadas a métodos propios.

Diagramas de secuencia vs colaboración

El diagrama de colaboración es, como el diagrama de secuencia, otra realización de los casos de uso. Son una combinación de los diagramas de objetos y los de secuencia. Muestra el flujo de sucesos entre objetos.
Ejemplo de diagrama de colaboración:
Recordamos que el diagrama de colaboración muestra como los objetos trabajan los unos con los otros enviando mensajes y intercambiando datos. Los diagramas de colaboración y secuencia son dos vistas diferentes de las interacciones entre objetos. Las dos vistas representan exactamente la misma información.
El diagrama de secuencia refuerza la vista temporal, pero es necesario seguir el diagrama para saber quien relaciona con quien.
El diagrama de colaboración refuerza las relaciones que se establecen entre los objetos, pero hace falta seguir el diagrama para saber el orden de los mensajes.

Diagrama de actividades

El diagrama de actividades es una variante del diagrama de estado y del diagrama de interacción porque sirve para describir el estado de una actividad que es el conjunto de acciones secuenciales o concurrentes en la cual pueden intervenir varios clasificadores.
Estos diagramas tienen muchos elementos en común con los diagramas de colaboración y con los estados. Los conceptos de transición, estado, evento, señal, flujo de control y objetos son el mismo.
Los elementos específicos son:

• Estados de acción.
• Flujos de objetos.
• Estados de flujos de objetos.
• Estados de subactividades.
• Swimlanes
• Iconos de control.

Los diagramas de actividades se utilizan para capturar flujos de actividades y secuencias de decisiones. Son ideales para representar el comportamiento interno:

• de un método (la realización de una operación).
• de un caso de uso.
• de un proceso de negocio (workflow).

Se pueden entender como una extensión de los diagramas de estado, donde cada estado se caracteriza por estar ejecutando una actividad y, donde todas las transiciones son automáticas cuando se acaba la actividad. Ahora bien, se enriquece de otros elementos:

• Puntos de decisión: condiciones que cambian el flujo de las acciones.
• Caminos de ejecución concurrentes.
• Señales, con puntos de envío y recepción explícitos.
• Objetos afectados por las acciones.

En UML 2.0 es posible representar condiciones, sincronizaciones, señales, tokens...

Las actividades se enlazan mediante transiciones automáticas, y a través de estas pasarán de una actividad a otra.

Cuando una actividad acaba, se desencadena el paso a la siguiente actividad, automáticamente.

Las actividades no tienen transiciones internas ni transiciones desencadenadas por eventos. Podríamos decir que las transiciones se disparan de manera automática, cuando finaliza una actividad.

Es una variación de una máquina de estados en la cual los estados representan la ejecución de acciones o subactividades y las transiciones se disparan por la finalización de las accioens o subactividades.

El diagrama de actividades representa la máquina de estados de un procedimiento.

Ramificaciones y fusiones:
Una ramificación (branch) es una división del flujo de actividades en dos hilos alternativos. Cada vez que se ejecute el diagrama, se optará por uno o otro dependiendo de la condición.
La condición esta especificada como guarda a cada una de las conexiones que salen.
Una fusión (merge) es la unión de dos hilos alternativos en un solo hilo.
Las ramificaciones y las fusiones se representan con un rombo vacío.

Divisiones y uniones:
Las barras de sincronización permiten, igual que las ramificaciones y fusiones, dividir el flujo de actividades en varios hilos y después adjuntarlos de nuevo. La diferencia esta en que ahora no son hilos alternativos, sino hilos concurrentes. Eso quiere decir que siempre se ejecutaran los dos hilos y siempre se ejecutaran a la vez.
La barra que separa los hilos la llamamos barra de fork, y la barra que adjunta los hilos la llamamos barra de join. Hace falta decir que la barra de join tiene una consecuencia, si un hilo llega antes que el otro al punto de join, necesitará esperar a que el otro llegue, entonces es un punto de sincronización.

Carriles o swimlanes
Los carriles sirven para separar las actividades que realizan diferentes objetos o actores. Unas lineas gordas a modo de corchea, dividen en carriles el diagrama. A cada carril le pondremos solamente las actividades que hará el actor o objeto al cual pertenece el carril.
Flujo de objetos: Entradas y productos
A menudo, las actividades requieren de la existencia de objetos o generan objetos o cambian su estado. Estos objetos se pueden añadir al diagrama con las convenciones del diagrama de objetos. Podemos relacionar los objetos con las actividades haciendo uso de flechas que indican el flujo del objeto.

1. Partiendo del siguiente diagrama de secuencia, responde a las preguntas:

a) ¿Qué objetos (nombre y clasificador) intervienen en el diagrama?
Objeto: Q1:C1

• Nombre: Q1
• Clasificador: C1

Objeto: Q2:C2

• Nombre: Q2
• Clasificador: C2

Objeto: Q3:C3

• Nombre: Q3
• Clasificador: C3

Objeto: :C4

• Nombre: / Qualsevol
• Clasificador: C4

b) ¿Qué objetos son creados y destruidos durante la interacción?
Creados: Q2:C2
Destruidos: Q3:C3

c) Dibuja el diagrama de comunicación equivalente.

2. 

a) Que tipo de diagrama UML es?

Diagrama de actividades.

b) Segun lo que se representa en el diagrama, en el caso que se produzca un error en el procesamiento de una comanda, que puede hacer el usuario? Que le pasa al sistema?

El usuario no puede hacer nada.

c) Dibuja el diagrama de estados de una comanda a partir de la información representada en este.

Diagramas de casos de uso

Introducción

Los diagramas de casos de uso de UML sirven para mostrar las funciones de un sistema de software desde el punto de vista de sus interacciones con el exterior y sin entrar en la implementación detallada de las funciones en cuestión. Estos diagramas se utilizan en la recogida de documentación y en la fase de análisis.

Actores

La finalidad de un software es proporcionar información a personas, máquinas o dispositivos externos en general. Un actor es un conjunto de papeles de una entidad exterior en relación con el sistema de software considerado. Para ser actor, una entidad exterior tiene que cumplir dos condiciones:

• Ser autónomo respecto al software (Por ejemplo: un motor eléctrico, pero no una CPU).
• Tener una relación directa con el software o con entidades exteriores que esten subordinadas a este software.

Un actor es un clasificador pero no es un estereotipo. Si un conjunto de entidades exteriores hacen el mismo papel las representaremos con un mismo actor. Los actores pueden tener relaciones de especialización o generalización mediante herencia (un actor A es una especialización de un actor B si hace al menos todos los papeles de B).

Un caso de uso representa una interacción entre el software y un actor o más. La interacción tiene que ser una función autónoma dentro del software. Los casos de uso son un caso particular de clasificadores, pueden tener atributos y operaciones. Entre casos de uso y actores hay asociaciones que representan el papel del actor en relación del caso de uso, pero no representan ningún flujo de datos. El actor principal es el que pide la función del software. Hay tres tipos de relaciones:

• Relación de extensión: Se dice que el caso de uso A extiende a B si dentro de B se ejecuta A, cuando se cumple una condición determinada.
• Relación de inclusión: Un caso de uso A esta dentro de los casos de uso de B, C..., si es una parte del proceso común a todos estos. El caso de uso no es autónomo, es decir, no tiene actor primario, por lo tanto, siempre se enciende desde otro caso de uso. Permite la reutilización.
• Relación de generalización y especialización: Un caso de uso A es una especialización de B si A hace todo lo que hace B más algún proceso especifico.

Representación básica:

Representación de una especialización/generalización:

Normalmente no se utilizan los símbolos de clasificadores. Los esteriotipos extend y include se utilizan para las relacoines de extensión y de inclusión, respectivamente:

Podemos crear las asociaciones convenientes entre actores y casos de uso.

Si nos conviene, y en el caso que representemos todos los casos de uso de un sistema, los podemos enmarcar o bien con un cuadrado y un título, o bien con un óvalo, para el sistema contenedor de los casos de uso, como se muestra a continuación:

 Ejemplo de cajero automático:

1. Este diagrama de casos de uso representa la funcionalidad de una aplicación de alquiler de películas de un cajero automático.

 a) ¿Del diagrama se puede deducir que una persona sea responsable del cajero no puede alquilar películas?

No, puede actuar con el rol de cliente también.

 b) ¿Si se cambia el sistema de tal manera que la forma de añadir los materiales es diferente, esto afectaria a las personas con rol de cliente?

No.

 c) Mejora el diagrama teniendo en cuenta que los casos de uso de añadir DVD y añadir BR tienen partes en común. Explica tu decisión.

 d) Supongamos que se mejora el sistema para que los clientes puedan recomendar los DVDs que más les gusta. Esta tarea se puede llevar de manera autónoma, pero también cuando alquilan DVDs. Representa en el diagrama estos requerimientos nuevos.

 e) Se podria considerar el cajero automático como un actor?

Sí, es un sistema externo de la aplicación.

2. Teniendo en cuenta las respuestas a las siguientes preguntas del famoso juego del buscaminas, especifica el diagrama de casos de uso:

Recuerda que necesitaremos preguntarnos para realizar el diagrama...

En este caso podemos suponer que estos són todos los casos de uso del juego.

Preguntas habituales para especificar los casos de uso de un sistema serían:

¿Qué casos de uso identificamos?

• Iniciar una nueva partida.
• Descubrir una casilla.
• Marcar la casilla.

¿Quién realiza estos casos de uso?

• El jugador.

3. En la empresa donde trabajais han encargado un nuevo videojuego llamado Sokoban. Como analistas que sois, se pide que especifiqueis el diagrama de casos de uso del juego, teniendo en cuenta los siguientes requerimientos funcionales:

• Sokoban es un juego de varios niveles.
• Cada nivel esta compuesto por un jugador, cajeros, repisas i muros.
• El objetivo del juegador es empujar todas las cajas sobre las repisas.
• Cuando esto sucede el jugador pasa al siguiente nivel.
• Para mover una caja, el jugador tiene que situarse al lado y empujarla. Si la casilla hacia la que esta empujando esta libre, la caja se moverá.
• Si el jugador se queda bloqueado. Es decir, no puede acabar el nivel, puede reiniciar el nivel perdiendo una vida.
• Cuando el jugador pierde todas las vidas, la partida se acaba.

Diagramas de estado

Los diagramas de UML se classifican en:

• Modelo estático, define la estructura de clases y objetos.
• Modelo dinámico, define las interrelaciones entre objetos.
• Modelo de implementación, describe el programario en terminos de componentes y aplicación.

Cuando un objeto varia su comportamiento con el tiempo, se dice que tiene estados.
En las aplicaciones de tiempo real, el diagrama de estados es muy importante.
Podemos encontrar otros lenguajes como PetriNets y SDL (Specification and Description Language).

Conceptos

• Los objetos y sistemas en todo momento se encuentran en un estado.
• El estado actual de un objeto o sistema determina su futuro.
• Los cambios de estados son posibles, en UML les llamamos transiciones.
• La transición entre estados se debe a un evento.
• Los diagramas de estado serán para modelar el comportamiento (complejo) de objetos y sistemas.
• El diagrama de estados se documenta en la fase de analisis.
• Hace poco se han incorporado los diagramas de Harel en UML, con estos se permite que un objeto o un sistema pueda estar en dos estados a la vez.

Notación

Los estados se representan en rectangulos redondeados:

El nombre del estado no se puede repetir en ningun lugar del diagrama. Tiene que ser único, aunque un objeto puede llegar varias veces al largo de su vida a un determinado estado.
Pueden tener tres compartimientos:

• El primero es el nombre del estado.
• El segundo es para valores característicos del sistema o objeto del cuando se encuentra el estado.
• El tercero para las acciones que se ejecutan al entrar, mientras esta o al salir del estado.

El estado inicial se simboliza con un circulo negro y el estado final con un círculo negro/blanco.

Las transiciones se representan por flechas, que van de un estado a otro:

El nombre del evento que disparan las transacciones se escriben al lado de las flechas.

Puede que una transición comporte una acción que se indica con /acción.

Una acción puede ir precedida por una condición de guarda que se representa como [condición]. El texto que acompaña a una transición tiene la siguiente forma:
evento [condición] / acción.

De acciones podemos tener una, varias o ninguna, y el orden de estas es importante porque especifica el orden de ejecución.

El estado de un objeto esta determinado por los valores de los atributos. Los diagramas de estados nos sirven para especificar todos los estados por los que puede pasar un objeto al largo de su vida.
Por ejemplo, el proceso de los posibles estados del objeto correo electrónico.

La dinámica de un sistema esta determinada por:

• Todos los posibles estados que pueden tener sus objetos.
• Todas las secuencias de eventos posibles.
• Todas las transacciones posibles de un estado a otro, consecuencia de los eventos que afectan a los objetos.

Podemos hacer uso de un diagrama de estado para modelar la dinámica de un sistema. Por ejemplo:

Una máquina expendedora de billetes.

Otro ejemplo seria:

En el ejemplo se muestra un diagrama de estados que modela gran parte del "login" de un sistema de banca online. Para hacer el "logging" al sistema, hace falta introducir un número de seguridad (SSN) y un número de identificación personal (PIN), que después se tienen que validar. El proceso de "logging" se puede factorizar en cuatro estados del sistema:

• GettingSSN.
• GettingPIN.
• Validating.
• Rejecting.

De cada estado se obtiene un conjunto completo de transacciones que determina el estado siguiente.

Hay dos auto transacciones, GettingSSN i GettingPIN. Al estado Validating el objeto no espera que un evento dispare una transacción, pero ejecuta una actividad. El resultado de esta actividad la determina el propio estado.

Estado: es una situación determinada dentro de la vida de un objeto. También puede ser la duración de una interacción durante la cual se cumple alguna condición, se lleva a hacer a alguna acción o se espera algún evento. No necesariamente se corresponde a un instante en el tiempo (puede tener una duración).

Transición simple: una transición simple consiste en que un objeto o interacción pasa de un estado a otro, puede ser incluso el mismo. La transición se da cuando hay un evento más una condición de "guarda". Todo estado puede tener transiciones de llegada y transiciones de salida.

Transición interna: son pseudotransiciones en las cuales no hay cambio de estado. Sirven para especificar acciones que se tienen que ejecutar en respuesta a eventos que no provocan ningún cambio de estado en el objeto. 

Acción: una acción es la especificación de un proceso atómico (o se ejecuta totalmente o no se ejecuta). De una transición, se puede ejecutar una acción o más. Las acciones se pueden describir mediante procedimientos.

Señales: los objetos pueden recibir mediante mensajes peticiones de operaciones o señales. Las señales se diferencian de las operaciones en que no hacen ningún proceso y solo pueden producir eventos. A su vez, los eventos provocan transiciones que si que son capaces de llamar a acciones.

Señal → evento → transiciones → acciones

Eventos: hechos que cuando se producen provocan trasiciones de un estado a otro y también se pueden dar determinadas acciones. Los eventos no van ligados a ningún objeto en concreto, sino que forman parte del paquete. Cada evento tiene nombre y parámetros. Cuando se produce un evento tiene que ser tratado, sino se pierde, a no ser que se declare diferido. Los eventos pueden ser del tipo síncrono (el transmisor debe coordinarse con el receptor antes del envío de datos) o asíncrono.

Tipos de eventos:

• De llamada: se producen cuando se llama una operación de un objeto.
• De señal: se produce cuando se recibe una señal.
• De cambio: es una notificación que una determinada condición ha sucedido.
• De tiempo: representa que o bien ha pasado un determinado tiempo o bien es una determinada hora.

Hay unos eventos que se llaman internos y son pseudoeventos porque estan ligados a un estado en vez de una transición. Sirven para encender acciones que no estan vinculadas a ningún cambio de estado. Pueden ser de entrada, salida o de acción:

• El de entrada se produce cuando el objeto entra en el estado correspondiente. No tiene parámetros ni guarda, y se identifica con la palabra "entry".
• El de salida se producen en la salida del estado y se identifican con la palabra "exit".
• El de acción especifican acciones que se generan cuando se llega a un determinado estado, y desaparecen en el momento que sale. Se declaran con la palabra "do".

La firma de eventos entonces dependerá de su tipo:

• De llamada o señal:
  
  Nombre_evento(NombreParametro:exp_tipo,...)
• De tiempo:
  
  after(expresión_de_tiempo)After es la duración, por ejemplo, when(hora/fecha)
• De cambio:
  
  when(expresión_booleana)

Sintaxis

• La condición de guarda es una expresión que puede tomar el valor de cierto o falso, se escribe en pseudocódigo y determina cuando se cumple el evento.
• La acción es una especificación en pseudocódigo que indica que procedimientos se tendrán que ejecutar cuando se cumple el evento.
• Un envío toma la forma destinación '.' mensaje'(argumento','...')', donde destinación pueden ser uno o mas objetos y mensaje es una operación del objeto de destinación o una señal. 

Con UML, si hemos de definir una señal, lo podemos hacer como una clase, que no tiene operaciones ni relaciones, solo herencia, i que solamente tiene como atributo los parámetros de señal (con el esteriotipo <<signal>>). Al símbolo de clase se le puede añadir un comportamiento especial para indicar cuales son las señales a las cuales son sensibles.

Un ejemplo sería:

introducir_tarjeta[tarjeta=válida]/abrir_puerta^registrar_entrada

O

introducir_tarjeta[tarjeta=válida]/defer abrir_puerta^registrar_entrada. 

(este lo deja para después: diferido)

Ejemplos:

Transiciones complejas: Un objeto o interacción pueden estar en mas de un estado al mismo tiempo, y puede haber mas de una transición saliendo de un estado y mas de una transición llegando a un estado. Estas se llaman transiciones complejas. Se utiliza un pseduoestado intermedio que se llama sincronización o de bifurcación. Otro ejemplo de facturas:

Estados compuestos: Un estado compuesto es aquel en el cual hay varios subestados posibles, cada uno de los cuales también puede ser a la vez compuesto o simple. Todo estado compuesto tiene un diagrama de subestados, que pueden ser concurrentes (a la vez) o secuenciales (uno detrás de otro). Se representa como un estado simple pero con 2 compartimientos. Dentro de un estado compuesto pueden haber transiciones que van de subestado a subestado; Transiciones que entran o salen del estado compuesto o bien, transiciones que tienen como destinación un indicador de historia de estados, que es un pseudoestado que recuerda al estado del cual salió. Del indicador de historia puede salir una transición hacia un subestado y será la destinación en el caso de que la transición tenga lugar sin que se haya pasado ninguna vez al estado compuesto.

Finalmente hay unas transiciones que se llaman stubbed, que tienen como destinación o origen algún subestado de un estado compuesto que no se identifica en el diagrama.

Ejercicios

1. Diseña el diagrama de estados de un objeto trabajador teniendo en cuenta que éste puede estar en el paro, activo o jubilado. En el diagrama tienen que verse los posibles cambios de estado del trabajador cuando sea contratado, se jubile o finalice una relación laboral.
   
   
   
   
2. En una biblioteca se quiere llevar el control de los libros existentes, de los socios de la biblioteca y de los préstamos que se han hecho. De cada libro pueden existir uno o muchos ejemplares y cada ejemplar tendrá que encontrarse en un catálogo. Por eso se podrá dar entrada a un ejemplar del catálogo o darle de salida. Cada ejemplar se encuentra en un posbile estado:
• Disponible
• Prestado
• No disponible

A la hora de efectuar el préstamo, será necesario validar que existe un socio que lo pide y la disponibilidad del ejemplar. Las acciones a hacer podran ser la de prestar un libro y la de devolverlo. Cada elemento del sistema tendrá sus atributos propios, que se dejan a elección del alumno. Para este enunciado, se pide la realización de un diagrama de clases implicadas en el UML i el diagrama de estado de un ejemplar.

3.
a) Especifica un diagrama de estados del cambio de marchas de un coche automático.
b) Especifica un diagrama de estados del cambio de marchas de un coche manual.

4. Una universidad europea tiene el siguiente proceso de matriculación.
"Cuando un alumno aprueba el bachillerato se puede preinscribir a ocho opciones universitarias y se puede presentar a las pruebas de acceso para aprobarlas. Si no las aprueba puede presentarse el año siguiente, pero se conserva la preinscripción. Si aprueba las pruebas de acceso entra en el proceso de asignación de plaza y segun su nota se le asigna la primera opción o las demás. En el caso de asignar plaza en primera opción entra en el proceso de matricula de julio. Si se le asigna las plazas 2 a 8 entra en el proceso de matrícula de septiembre. Si no se le puede asignar plaza queda en situación de no admitido.
Los procesos de matrícula de julio y septiembre tienen dos etapas sucesivas: matricularse y pagar. Si un alumno se tiene que matricular y no lo hace (tiene de terminio hasta el 1 de agosto y el 1 de octubre, respectivamente) pasa a la situación de no admitido."
Realizad el diagrama de estados de alumno, utilizando un diagrama compuesto sin detallar para representar el proceso de matriculación y pago una vez se le asigna la plaza.
Mejorad el diagrama especificando detenidamente el diagrama de estados con los subestados incluidos el diagrama de estado compuesto.

5. Una empresa esta desarrollando un programario para la gestión de campañas publicitarias. Representa el diagrama de estados del objeto Campaña teniendo en cuenta:

Estamos considerando el funcionamiento de la clase campaña. Una campaña se inicia en el momento que se le asigna personal. En este momento se le asigna un director a la campaña y pasa a estar "comisionada". Cuando se da la autorización para parte de la empresa y el cliente firma el contrato, se activa la campaña. Si la campaña finaliza, queda marcada como completada y se realiza una declaración final. Sólo si el cliente paga toda la cantidad definida en el contrato de campaña pasa a estar pagada, y transcorridos 30 días se archiva y se desasigna el personal y el director asignados.