PDF de programación - Metodologías, procesos y entornos para sistemas de tiempo real - Master de Computación - Diseño de una aplicación basada en objetos de tiempo real

Análisis de requisitos

Metodologías, procesos y entornos para sistemas de tiempo real

Master de Computación

Diseño de una aplicación basada

en objetos de tiempo real

José M. Drake
Computadores y Tiempo Real

Santander, 2010

1

Metodos, procesos y entornos para sistemas de tiempo real

1

Análisis de requisitos

Modelo reactivo de una aplicación de tiempo real

Temp_Ev1

Actividad_a1

Actividad_b1

Actividad_c1

Entorno_Ev2

Actividad_a2

Mutex_H

Entorno_Ev3

Actividad_a3

Actividad_b3

Actividad_c3

Mutex_K

Mutex_J

Temp_Ev4

Actividad_a4

Actividad_b4

Actividad_c4

Actividad_d4

Procesador 1

Procesador 2

Red Comunicación

Procesador 3

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

2

Una aplicación de tiempo real se concibe como un conjunto de transacciones
(end_to_end_flow) que se ejecutan concurrentemente en la plataforma en que se
encuentra instalada:
•Cada transacción se inicia en respuesta a un determinado flujo de eventos al
que atiende la aplicación. Por cada ocurrencia de un evento se activa la
transacción y ejecuta el conjunto de actividades que constituye la respuesta al
evento que especifica su funcionalidad. Los eventos pueden proceder de los
dispositivos periféricos hardware (evento de entorno), o de un reloj de la
plataforma (evento temporizado) que ha sido programado por la propia
aplicación para que los genere con una determinada cadencia.

Metodos, procesos y entornos para sistemas de tiempo real

2

Análisis de requisitos

Flujo de control

Actividad a

Actividad b

secuencial

Actividad a

delay

retraso

Actividad b

Actividad a

Actividad b

Actividad c

concurrente

Actividad d

Actividad a

Actividad b

Actividad c

opcional

Actividad d

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

3

•Cada transacción está constituida por un conjunto de actividades que están
relacionadas entre sí por una determinada relación de precedencia o flujo de
control. Esto es, cada actividad se inicia o bien en respuesta al evento externo
que activa la transacción, o bien como consecuencia de que otra u otras
actividades de la misma transacción hayan finalizado. Como se muestra en la
figura, las relaciones de flujo de control entre las diferentes actividades de una
transacción pueden ser muy variadas, e incluyen entre otras, secuencialidad,
concurrencia, alternativas opcionales, sincronización, retrasos, etc.

Metodos, procesos y entornos para sistemas de tiempo real

3

Análisis de requisitos

Actividades, Threads, Mutexes y requisitos temporales

Thread_b

Thread_c

Temp_Ev1

Actividad_a1

HardGlobalDeadline

Actividad_b1

Actividad_c1

Mutex_x

Thread_a

CommChannel_e

Thread_d

Temp_Ev4

Actividad_a4

Actividad_b4

Actividad_c4

Actividad_d4

HardLocalDeadline

scheduler

Proc_1

scheduler

Net

scheduler

Proc_2

Thread_a

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

4

•Una actividad de una transacción consiste en la ejecución de un código en un
procesador o la transmisión de un mensaje por una red. Cada actividad requiere
para su ejecución un cierto tiempo de procesamiento o transmisión. Este tiempo
puede depender del estado de la aplicación cuando se ejecuta y no tiene que ser
el mismo en cada activación.
•Una actividad puede requerir, de acuerdo con su naturaleza, ser ejecutada en
régimen de exclusión mutua con la ejecución de otras actividades de la
aplicación. Esto se implementa en el código de las actividades requiriendo que
ambas accedan a un mismo mutex.
•Al tiempo en el que termina una actividad de una transacción, se le pueden
asignar requisitos de restricción temporal. Esta restricción temporal puede ser
relativa al instante en que se produjo el evento que activó la transacción
(requisito temporal global) o al instante en que se ha activado la propia
actividad (requisito temporal local). El requisto puede consistir en un plazo, en
una limitación de la variabilidad (jitter) o en una tasa de cumplimiento.

Metodos, procesos y entornos para sistemas de tiempo real

4

Análisis de requisitos

Conclusión

Una aplicación de tiempo real está constituida por un conjunto de actividades
organizadas por relaciones de flujo de control en respuesta a eventos temporizados o
procedentes del entorno.
La ejecución de las actividades que corresponden a la respuesta a diferentes eventos se realiza
concurrentemente y con flujos de control independientes. Entre la ejecución de dos actividades
que pertenecen a respuestas de eventos distintos no existen dependencia de flujo de control.

Pero si ambas requieren para su ejecución un mismo recurso, existirá entre ellas una relación

de exclusión mutua en su ejecución.

Los recursos son de dos tipos:

ejecutadas,

Los procesadores o redes de comunicación si las actividades los utilizan para ser

Los mutexes que establecen exclusión mutua por sincronización.

La aplicación puede requerir que ciertas actividades de las respuestas finalicen en

determinados plazos temporales.

El diseño de planificabilidad de una aplicación de tiempo real consiste en organizar
la ejecución de las actividades de las diferentes transacciones con el suficiente nivel
de concurrencia, y dotar a los threads en los que se planifican con la adecuada
prioridad para que en todos los casos la ejecución de las actividades se realice en el
orden adecuado, de forma que todas ellas finalicen antes de los plazos temporales que
tienen asignados.

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

5

Metodos, procesos y entornos para sistemas de tiempo real

5

Análisis de requisitos

Diseño de una aplicación orientada a objetos

Una aplicación diseñada utilizando el paradigma de orientación a objetos se diseña en base
a clases que se identifican con tipos de objetos que existen en su dominio de aplicación.

ScadaDemo

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

6

Metodos, procesos y entornos para sistemas de tiempo real

6

Análisis de requisitos

Cada clase se diseña desde el punto de vista funcional (1).

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

7

Metodos, procesos y entornos para sistemas de tiempo real

7

Análisis de requisitos

Cada clase se diseña desde el punto de vista funcional (2).

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

8

Metodos, procesos y entornos para sistemas de tiempo real

8

Análisis de requisitos

Cada clase se diseña desde el punto de vista funcional (3).

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

9

Metodos, procesos y entornos para sistemas de tiempo real

9

Análisis de requisitos

Verificación de la completitud del diseño funcional

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

10

Metodos, procesos y entornos para sistemas de tiempo real

10

Análisis de requisitos

Caso de uso “Ejecución”

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

11

Metodos, procesos y entornos para sistemas de tiempo real

11

Análisis de requisitos

Caso de uso “Muestrea”

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

12

Metodos, procesos y entornos para sistemas de tiempo real

12

Análisis de requisitos

Identificación de la clase que lanza una partición.

La instanciación de una aplicación resulta de invocar el método estático
main() de la clase principal estereotipada como <<main>>.
Hay una clase de este tipo por cada partición.

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

13

Metodos, procesos y entornos para sistemas de tiempo real

13

Análisis de requisitos

Clase activa que atiende eventos

Las clases que tienen capacidad de atender a
eventos del entorno se estereotipan como
<<active>>, y deben incluir entre sus métodos
privados el método que se invoca cuando el
evento ocurre. Estos métodos se estereotipan
como <<handler>> y se ejecutan en threads
internos propios de la clase y específicos para
cada tipo de evento.
Cuando la respuesta a un evento dura más que el
tiempo entre eventos, o bien se encolan los
eventos para su atención secuencial, o se dispone
de un grupo de threads (thread pool) para su
atención concurrente. En este último caso los
etiquetamos como <<concurrent_handler>>,
para indicar que cada ocurrencia del evento se
planifica en un thread independiente.

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

14

Metodos, procesos y entornos para sistemas de tiempo real

14

Análisis de requisitos

Clases <<active_timed>>

Las clases que tienen capacidad de programar el reloj, y atender los eventos
temporizados que proceden de él, se estereotipan como <<active_timed>>,
y deben incluir entre sus métodos privados el método que se invoca cuando
ocurre el evento temporizado. Estos métodos se ejecutan en threads
internos propios de la clase, y se estereotipan como <<timed>>.

Santander, 2010

Métodos, procesos y entornos para sistemas de tiempo real

J.M. Drake

15

Metodos, procesos y entornos para sistemas de tiempo real

15

Análisis de requisitos

Clases <<protected>>

Las clases que incluyen un mutex para garantizar que sea seguro el acceso a su estado
interno cuando threads externos invocan concurrentemente sus métodos, se estereotipan
como <<protected>>, y los métodos de su interfaz pública que requieren acceder al
mutex para ser ejecutados se estereotipan como <<synchronized>>.

Santander, 2010

Métodos, procesos y entornos para sist