Desarrollo de Sistemas en Tiempo Real

UNIVERSIDAD PRIVADA TELESUP
Prefacio:
La asignatura es de carcter terico-prctico. sta,

tiene como fin desarrollar en el estudiante habilidades
para el anlisis y la aplicacin de diferentes mtodos
usados en los sistemas de tiempo real, tales como los
mtodos de diseo e implementacin de sistemas. El
estudio de los sistemas de tiempo real es una rama
relativamente nueva de la ingeniera. Los primeros trabajos que mencionan estos
trminos tal cual se los utiliza en este captulo son del la dcada del 80. Se trata,
bsicamente, de la reunin de varias tcnicas preexistentes de anlisis y diseo, con
el propsito de organizar el desarrollo de sistemas compuestos por una combinacin
de hardware y software. El objetivo fundamental es que dicho desarrollo resulte en
sistemas robustos y confiables, con un ptimo aprovechamiento de los recursos.
Utiliza un enfoque diferente, con los mismos objetivos.
Comprende Cuatro Unidades de Aprendizaje:

Unidad I: Modelados de sistemas.
Unidad II: Metodologas de desarrollo de sistemas de tiempo real.
Unidad III: Modelado de tiempo real de las mquinas de estados.
Unidad IV: Metodologa de diseo de sistemas orientado a objetos.
Estructura de los Contenidos
Modelado de
Sistemas
Qu es el
modelado?
Metodologas
de desarrollo
de sistemas
de tiempo
real
Metodologas
estructuradas
orientada a
objetos.
Modelado formal
de Sistemas.
Tcnicas formales
de anlisis de
Metodologas
basadas en
SDL y en UML.
sistemas.
Lenguajes
grficos de
modelado.
Una semntica
de acciones
para MML.
Acciones
primitivas.
Modelado de
tiempo real de
las mquinas de
Estados
Metodologa de
diseo de
sistemas
orientado a
objetos
Semntica de las
mquinas de
estados.
Introduccin a la
metodologa de
diseo.
La mquina de
estados con
estados
concurrentes.
Propuesta de una
metodologa.
El tiempo real en
las mquinas de
estados.
Expresin del
tiempo en las
mquinas de
estados.
Diseo con
dispositivos
fsicos.
Un caso real: el
diseo de un
telfono
inalmbrico.
La competencia que el estudiante debe lograr al final de la asignatura es:
Comprender los elementos prcticos sobre las bases

tericas y aplicacin metodolgica que desarrolle,
fortalezca y perfeccione sus habilidades en las diferentes
metodologas usadas en el anlisis de sistemas en tiempo
real, a travs de actividades donde aplique diversas
tcnicas y estrategias que le permitan resolver problemas
en el campo laboral.
ndice del Contenido
I. PREFACIO
II. DESARROLLO DE LOS CONTENIDOS
UNIDAD DE APRENDIZAJE 1: MODELADO DE SISTEMAS
1.
Introduccin
a. Presentacin y contextualizacin
b. Competencia
c. Capacidades
d. Actitudes
e. Ideas bsicas y contenido
2.
Desarrollo de los temas
a. Tema 01: Qu es el modelado?
b. Tema 02: Modelado formal de sistemas.
c. Tema 03: Tcnicas formales de anlisis de sistemas.
d. Tema 04: Lenguajes grficos de modelado.
3.
Lecturas recomendadas
4.
Actividades
5.
Autoevaluacin
6.
Resumen
UNIDAD DE APRENDIZAJE 2: METODOLOGAS DE DESARROLLO DE SISTEMAS DE TIEMPO
REAL
1.
Introduccin
b. Competencia
c. Capacidades
d. Actitudes
2.
a. Tema 01: Metodologas estructuradas orientada a objetos.
b. Tema 02: Metodologas basadas en SDL y en UML.
c. Tema 03: Una semntica de acciones para MML.
d. Tema 04: Acciones primitivas.
3.
4.
Actividades
5.
Autoevaluacin
6.
Resumen
UNIDAD DE APRENDIZAJE 3: MODELADO DE TIEMPO REAL DE LAS MQUINAS DE ESTADOS
1.
Introduccin
b. Competencia
c. Capacidades
d. Actitudes
2.
a. Tema 01: Semntica de las mquinas de estados.
b. Tema 02: La mquina de estados con estados concurrentes.
c. Tema 03: El tiempo real en las mquinas de estados.
d. Tema 04: Expresin del tiempo en las mquinas de estados.
3.
4.
Actividades
5.
Autoevaluacin
6.
Resumen
UNIDAD DE APRENDIZAJE 4: METODOLOGA DE DISEO DE SISTEMAS ORIENTADO A OBJETOS
1.
Introduccin
b. Competencia
c. Capacidades
d. Actitudes
2.
a. Tema 01: Introduccin a la metodologa de diseo.
b. Tema 02: Propuesta de una metodologa.
c. Tema 03: Diseo con dispositivos fsicos.
d. Tema 04: Un caso real: el diseo de un telfono inalmbrico.
3.
4.
Actividades
5.
Autoevaluacin
6.
Resumen
III. GLOSARIO
IV. FUENTES DE INFORMACIN
V. SOLUCIONARIO
02
03 - 147
05-43
06
06
06
06
06
06
07-39
07
13
24
30
40
40
41
43
44-76
45
45
45
45
45
45
46-72
46
52
58
66
73
73
74
76
77-108
78
78
78
78
78
78
79-104
79
86
91
98
105
105
106
108
109-144
110
110
110
110
110
110
111-140
111
117
122
128
141
141
142
144
145
146
147
Introduccin
a) Presentacin y contextualizacin:
La creciente complejidad de los sistemas informticos ha llegado a tal nivel que
aquellos de mayor envergadura son comparables en dificultad y tamao con las
grandes obras de otras ramas de la ingeniera o la arquitectura. El modelamiento
es una actividad que ayuda a resolver situaciones problemticas antes de que
estas ocurran.
b) Competencia:
Conoce el modelamiento de sistemas en tiempo real utilizando las
herramientas adecuadas.
c) Capacidades:
1. Reconoce la importancia y necesidad del modelamiento de sistemas.
2. Describe los distintos modelos para modelar formalmente los sistemas.
3. Aplica las tcnicas y herramientas formales de anlisis de sistemas.
4. Emplea los lenguajes grficos de modelado para sistemas en tiempo real.
d) Actitudes:
Presente iniciativa de investigacin y prctica con respecto al modelado de
sistemas.
Perseverancia en el desarrollo de las actividades y/o trabajos del modelado de
sistemas.
e) Presentacin de Ideas bsicas y contenidos esenciales de la Unidad:

La Unidad de Aprendizaje 01: Modelado de Sistemas, comprende el desarrollo
de los siguientes temas:
TEMA 01: Qu es el Modelado?
TEMA 02: Modelado Formal de Sistemas.
TEMA 03: Tcnicas Formales de Anlisis de Sistemas.
TEMA 04: Lenguajes Grficos de Modelado.
Qu es el
Modelado?
TEMA 1
Competencia:
Reconocer la importancia y necesidad del
modelamiento de sistemas.
Desarrollo de los Temas
Tema 01: Qu es el Modelado?

La creciente complejidad de los sistemas informticos ha llegado a tal nivel que
aquellos de mayor envergadura son comparables en dificultad y tamao con las
grandes obras de otras ramas de la ingeniera o la arquitectura. Esta complejidad
comporta dos cuestiones fundamentales. Por un lado, es difcil llegar a construir un
sistema tan sofisticado, especialmente si no se tiene experiencia previa ni informacin
bsica sobre su composicin. Por otro lado, tambin es difcil establecer a priori si el
sistema funcionar correctamente una vez construido, lo que es especialmente grave
en aquellos sistemas cuyo coste es muy elevado, o son especialmente difciles de
modificar una vez construidos, o llevan a cabo tareas muy delicadas o peligrosas.
En estas otras ramas de las ciencias es tradicional el uso de

modelos que permitan un anlisis previo de las caractersticas y
el funcionamiento del sistema. El uso de modelos es una
herramienta bsica para tratar esta complejidad, ya que permite
hacer una rplica ms simple del sistema, de la que eliminan
detalles que no son fundamentales, obteniendo as un objeto de
estudio ms sencillo de entender, manejar y que permite hacer
predicciones sobre aspectos importantes del sistema real.
Un buen modelo debe tener varias caractersticas:
Debe permitir la abstraccin, para poder obviar detalles irrelevantes en un

momento dado para el anlisis de ciertas propiedades concretas del sistema.
Adems el grado de abstraccin debe ser variable y
as permitir que el anlisis sea a mayor o menor nivel
de detalle, segn sea necesario.
Debe usar notaciones que permitan a un lector

humano entender el sistema. Si la notacin usada es oscura o difcil de entender el
modelo ser de poca utilidad, incluso para sistemas con un mnimo de complejidad.
Debe mostrar las mismas caractersticas que el sistema final, al menos en aquellos
aspectos que quieran ser estudiados o analizados antes de la construccin del
sistema final.
Debe tener una base matemtica o formal que permita la demostracin de

propiedades, con el fin de poder predecir el funcionamiento del sistema una vez
construido.
Debe ser significativamente ms fcil y econmico de construir que el sistema final.
Necesidad del modelado

Aprovechando los avances en la construccin de las
computadoras cada vez mayor capacidad de procesamiento y
almacenamiento de informacin, los sistemas informticos
son cada vez ms grandes, se aplican a ms campos y se depositan en ellos
responsabilidades mayores. Esta situacin provoca una mayor exigencia sobre los
sistemas informticos. No slo han de ser sistemas que proporcionen un resultado
correcto, sino que tienen otra serie de requisitos entre los que se pueden citar la
obligacin de ser sistemas seguros o responder satisfactoriamente frente a situaciones
no esperadas o de error. Se puede ilustrar esta situacin usando ejemplos de la
aplicacin de la informtica a un campo concreto como la sanidad.
Las pruebas de radiodiagnstico ms avanzadas

hoy en da, como la tomografa axial computarizada
o la resonancia magntica estn controladas por
ordenador, de cuya correcta programacin depende
la exactitud de las pruebas. Ms delicado an es el
ejemplo de algunas terapias antitumorales en las
que un equipo informtico controla la exposicin de
un paciente a istopos radioactivos. En los aos ochenta, cuatro personas murieron
por haber sido sometidos a una dosis demasiado alta por culpa de un error
informtico. En los sistemas sanitarios tambin se han introducido complejos sistemas
informticos en el rea de la administracin y se usan grandes bases de datos para
almacenar, entre otros datos, los historiales clnicos de los pacientes.
Estas aplicaciones tienen grandes ventajas, ya que permiten a los mdicos un acceso
inmediato, desde distintos lugares y, posiblemente, simultaneo, a la informacin
histrica de pacientes a los que pueden no haber tratado antes. Sin embargo, los
requisitos de seguridad y de confidencialidad son una condicin bsica para evitar que
esos datos tan sensibles puedan usarse indebidamente. Por su parte, los sistemas de
apoyo vital a los enfermos que estn en las unidades de cuidados intensivos han de
ser capaces de seguir funcionando correctamente incluso
si, por ejemplo, se produce una prdida momentnea de
suministro elctrico. Es, por tanto, clara la necesidad de
construir sistemas informticos libres de errores y que
respondan a los requisitos con que se pensaron.
El desarrollo de sistemas informticos es una rama de la ingeniera reciente para la

que an no hay tcnicas de desarrollo que conciten la aprobacin generalizada de los
desarrolladores o que se puedan aplicar universalmente a las diferentes clases de
sistemas informticos. Sin embargo, en lo que s se est cada vez ms de acuerdo es
en la necesidad, y en los beneficios que conlleva, el usar modelos para guiar la
construccin de los sistemas reales, de forma que se puedan analizar las propiedades
del sistema final antes y durante su desarrollo. Diferentes autores han propuesto
mltiples modelos distintos, influenciados por el tipo de sistemas desarrollaban en ese
momento, por el campo de aplicacin para el que se proponan, etc. An hoy en da, la
diversidad es grande y se est lejos de la unanimidad, o de la universalidad de los
modelos, por lo que se sigue investigando ampliamente en el tema.
Los sistemas de tiempo real y su modelado

Los sistemas de tiempo real son una clase concreta de sistemas informticos que se
pueden definir de manera informal como aquellos sistemas en los que el tiempo de
respuesta es crucial para su funcionamiento correcto. Tambin se dice que en un
sistema de tiempo real, un dato obtenido fuera de plazo, aunque sea correcto, es un
dato invlido, que incluso puede provocar que el sistema falle en su conjunto. Uno de
los ejemplos ms habituales de los sistemas de tiempo real son los sistemas de
control, en los que un sistema computarizado se encarga de controlar el
funcionamiento de otro sistema, informtico o no. Por ejemplo, en los automviles
actuales se encuentran multitud de estos sistemas, como el sistema de antibloqueo de
los frenos.
10
Este sistema se encarga de vigilar el funcionamiento de las ruedas del vehculo

durante la frenada. Si se bloquean, se liberan momentneamente las ruedas para que
sigan girando y no se deslicen. En cuanto las ruedas han conseguido un giro mnimo,
se vuelve a actuar sobre el freno para volver a pararlas. En este ejemplo se muestran
algunas de las caractersticas habituales de estos sistemas: se monitorizan unos datos
que llegan del entorno, se procesan y, como resultado, se actan sobre dicho entorno.
Si la respuesta llega tarde y las ruedas han empezado a patinar, el desbloqueo de los
frenos puede ser intil o incluso contraproducente. Otro ejemplo de sistemas de
tiempo real, de una naturaleza distinta, es el de los servicios de videoconferencia,
donde se establece de forma remota una conexin entre dos o ms extremos y se
exige que los datos lleguen con una determinada velocidad y calidad a los otros
extremos, incluyendo la consideracin de posibles errores en el canal de
comunicacin.
Si se producen retrasos o prdidas de imagen o sonido

momentneas, es posible que se consiga mantener una
calidad suficiente en la conferencia, pero para eso es
necesario que la mayora de la informacin llegue correctamente y con un retraso
mnimo. Una de las clasificaciones de los sistemas de tiempo real distingue entre
sistemas duros (hard realtime systems), en los que ningn dato se puede producir
fuera de plazo, y blandos (soft realtime systems), en los que se puede permitir que
algunos de los resultados se produzcan con un retraso mayor del establecido. Los
sistemas de tiempo real tienen unas caractersticas propias que hace que su desarrollo
sea an ms difcil que el de la mayora del resto de los sistemas informticos.
Son sistemas inherentemente concurrentes en los que hay varios flujos de control
ejecutndose simultneamente e interaccionando, accediendo a recursos comunes
y comunicndose y sincronizndose entre ellos. El desarrollo de sistemas
concurrentes es ms complejo por la posibilidad de problemas adicionales como el
bloqueo, la inversin de prioridades, etc.
Interactan directamente con sistemas fsicos. Es muy

habitual encontrar sistemas que tienen una relacin a muy
bajo nivel con dispositivos fsicos para lectura de datos
para monitorizar los sistemas controlados y para escritura de datos para su control.
11
Su funcionamiento depende habitualmente de estmulos

procedentes del entorno (se suelen clasificar dentro de
los llamados sistemas reactivos, que actan dando
respuesta a un estmulo exterior). La frecuencia de los
estmulos exteriores es unas veces peridica, otras sigue
una distribucin de probabilidad y, en ocasiones, es desconocida.
Se desarrollan en arquitecturas fsicas muy variadas, no slo en computadoras

tradicionales, sino en otros dispositivos electrnicos autnomos, desde vehculos a
telfonos mviles, pasando por un amplio abanico. A este tipo de sistemas de
tiempo real se les llama empotrados (embedded realtime systems). Es habitual que
esos sistemas empotrados impongan fuertes restricciones en varios aspectos. Por
un lado, los recursos fsicos con los que se cuenta, como memoria y capacidad de
clculo, suelen estar muy ajustados, lo que incide en una mayor dificultad para
encontrar una solucin viable. Los recursos software, como bibliotecas de
funciones o sistemas operativos, pueden tambin estar limitados, ya que es
habitual la ausencia de versiones para estos entornos no estndares.
Tienen el requisito no funcional adicional de los plazos temporales de las respuestas.

Este requisito hace necesario el anlisis de la planificabilidad del sistema, que
establece si se pueden cumplir o no los plazos temporales y, si no se puede, cules
son los que fallan. Estas particularidades de los sistemas de tiempo real impiden, o
limitan, que los modelos y metodologas de desarrollo de sistemas informticos en
general se puedan aplicar a los sistemas de tiempo real o, al menos, que sean
suficientes. De aqu surge la necesidad de complementar modelos generales o
desarrollar otros nuevos para tener en cuenta las caractersticas adicionales que
presentan los sistemas de tiempo real.
12
Modelado
Formal de
Sistemas
TEMA 2
Competencia:
Describir los distintos modelos para modelar
formalmente los sistemas.
13
Tema 02: Modelado Formal de Sistemas
Son numerosos los distintos mtodos de modelar sistemas informticos que han
surgido desde los aos sesenta. Algunos de ellos son formales porque incorporan un
formalismo matemtico subyacente que permite derivar de manera fiable propiedades
de los sistemas modelados. Algunos de esos mtodos usan como base la lgica de
predicados de primer orden. Hay otros que se basan en la teora de conjuntos, para
describir los cambios de estados de los datos del sistema. Otros se basan en lgebras
de procesos.
Otro grupo es el formado por los mtodos basados en lgicas

modales, generalmente lgicas temporales, que permiten modelar
la evolucin del estado del programa en el tiempo en funcin de la
ocurrencia de eventos o de la ejecucin de las acciones. Por su
parte, otros mtodos, como las redes de Petri, SDL, los statecharts
o las mquinas de estados de UML estn basados en mquinas de
estados. Estos mtodos cuentan como ventaja con su expresin
grfica, que los hace ms asequibles a los desarrolladores y son especialmente
adecuados para modelar sistemas reactivos.
Cuando surgieron la mayora de estos mtodos algunas

tcnicas de programacin, como la orientacin a objetos,
no estaban tan extendidas por lo que las metodologas no
ofrecan apoyo para desarrollos basados en estos
paradigmas. Posteriormente han aparecido extensiones o
actualizaciones de algunos de estos mtodos que s tienen en cuenta la orientacin a
objetos. Igualmente ha ocurrido con la especificacin de requisitos no funcionales,
como los requisitos de tiempo, el rendimiento o aspectos de seguridad.
14
Como se pone de manifiesto a continuacin, la mayora de los mtodos descritos han

sido desarrolladas inicialmente para modelar sistemas en los que no se tenan en
cuenta requisitos relacionados con el tiempo, por lo que no ofrecan mecanismos
adecuados para expresar propiedades temporales ni realizar anlisis de estos
requisitos y que no eran vlidas para modelar y analizar sistemas de tiempo real.
Algunas
de
ellas,
adems,
presentaban
deficiencias
para
expresar
otras
caractersticas representativas de los sistemas de tiempo real, como la concurrencia, y

analizar propiedades relacionadas con ella, como la sincronizacin, envo de mensajes
o ausencia de interbloqueo.
Para la mayora de los mtodos que se incluyen han

surgido ampliaciones que incluyen herramientas para
especificar
propiedades
cumplimiento
de
ampliaciones
son
temporales
los requisitos
muy
variadas,
analizar
temporales.
en
el
Estas
funcin
del
formalismo sobre el que se han fundamentado y la

facilidad y potencia que se hayan conseguido para el
objetivo de cubrir los aspectos temporales del sistema.
Mtodos axiomticos
La axiomatizacin de los lenguajes de programacin ha sido
el primer paso en la formalizacin del diseo de los sistemas
informticos. Los primeros trabajos elaborados para el
desarrollo metdico de programas se usa la lgica de
predicados de primer orden. Las frmulas de estas lgicas de
programacin son las tripletas, que constan de una
precondicin, un programa y una postcondicin ({P} S {Q}). La precondicin y la
postcondicin son predicados lgicos sobre el estado del programa. El estado del
programa viene representado por el conjunto de valores de las variables. La tripleta es
verdad si cuando empieza la ejecucin del programa S, la precondicin P es cierta y,
si acaba el programa, la postcondicin Q tambin es cierta.
15
En la lgica se definen las reglas de derivacin adecuadas sobre los constructores

bsicos de la programacin secuencial secuencia, seleccin e iteracin que
permiten comprobar la validez de las tripletas. Las propiedades que se comprueban e
dividen en dos grupos, las de seguridad, que indican que un programa no llega nunca
a un estado indeseable, y las de viveza, que aseguran que un programa acaba
llegando a un estado valido. Por ejemplo, un bucle sin fin no cumple la propiedad de
viveza de acabar. La tcnica de Dijkstra va un paso ms all y propone mtodos para
la construccin de programas de manera que ste garantizado el cumplimiento de las
propiedades consideradas. En particular, define reglas para construir bucles y
sentencias de seleccin correctos.
La programacin concurrente, en la que varios procesos se ejecutan

simultneamente compitiendo por recursos comunes, presenta
nuevas instrucciones y situaciones, como la comunicacin y la
sincronizacin entre los procesos. Las lgicas de programas se han
ampliado para los lenguajes concurrentes incluyendo nuevas reglas
de inferencia para las nuevas instrucciones, como la de ejecucin en
paralelo o la de espera. Entre las propiedades especiales que se han de analizar para
los programas concurrentes estn la ausencia de bloqueo (deadlock), de esperas
indefinidas, (livelock) y de postergacin indefinida de procesos (starvation). Para ello
se han de hacer nuevas suposiciones sobre el entorno de ejecucin, como la
naturaleza del planificador, si es cclico o si soporta interrupciones, y sobre su
imparcialidad (weak fairness y strong fairness).
El gran problema de estas tcnicas es que la mayora de sus

usuarios potenciales las encuentra extremadamente difciles
de aplicar en la prctica, lo que se traduce en una
imposibilidad econmica de aplicarlas a desarrollos reales
en la industria. Esta dificultad se ha visto incrementada
por la falta de herramientas que permitieran aplicar las
tcnicas de forma automtica en sistemas del tamao y
complejidad habituales en las aplicaciones actuales.
16
Tcnicas basadas en teora de conjuntos

Las especificaciones basadas en la teora de conjuntos se caracterizan porque el
estado del programa se expresa de manera explcita mientras que el funcionamiento
del programa est implcito. El estado del programa se puede deducir del estado inicial
y de las operaciones que modelan los cambios de estados. En cambio, los mtodos
basados en algebras de procesos definen de manera explcita el funcionamiento del
sistema y es el estado el que est implcito.
Una de dichas tcnicas es la notacin Z, la cual est basada

en la teora de conjuntos y la lgica matemtica. Los objetos
matemticos
sus
propiedades
pueden reunirse
en
esquemas, patrones de declaraciones y restricciones. El

lenguaje de esquemas puede usarse para describir el estado
del sistema y las formas en que el estado puede cambiar.
Tambin puede usarse para describir propiedades del
sistema y para razonar sobre posibles refinamientos del diseo.
Una propiedad caracterstica de Z es el uso de tipos.

Cada objeto del lenguaje matemtico tiene un tipo
nico. Aunque Z es un lenguaje de especificacin formal,
las especificaciones tambin incluyen lenguaje natural. Los
modelos construidos en Z se pueden refinar, obteniendo otro
modelo coherente con el anterior, pero de mayor nivel de detalle. Z est pensada para
describir las caractersticas funcionales del sistema y las caractersticas no funcionales
como usabilidad, rendimiento o fiabilidad, quedan fuera de su mbito. Para ilustrar
algunas de las caractersticas bsicas de Z, se va a especificar un sistema muy simple
en el que se anotan y recuerdan fechas de cumpleaos.
[NOMBRE, FECHA]
LibroCumpleaos =
[conocidos: PNOMBRE; cumple:
NOMBRE FECHA| conocidos = dom cumple]
17
En este esquema se han definido los tipos que se van a usar NOMBRE y FECHA, el
conjunto de nombres cuyo cumpleaos se sabe (conocidos) y una funcin parcial que
asocia ciertos nombres con fechas (cumple). La restriccin final establece una forma
de calcular conocidos, como el dominio actual de la funcin cumple.
El siguiente esquema define una operacin que modifica el espacio de estados
definido en el anterior.
IncluirCumple =
[nombre? : NOMBRE; fecha? : FECHA|
nombre? conocidos; cumple = cumple nombre? fecha?]
En este esquema, indica que la operacin va a modificar el estado del sistema.

nombre? y fecha? son los nombres de los argumentos de la operacin. Como
precondicin el nombre de entrada no puede tener una fecha asociada. La otra
precondicin indica que, tras la ejecucin, el estado de la funcin parcial cumple
(denotado por cumple) vara como se indica en ese predicado.A partir de esta
especificacin se pueden demostrar propiedades del sistema. Por ejemplo, el nuevo
nombre pasa a formar parte de los conocidos: conocidos = conocidos nombre?
El uso de Z en la especificacin de sistemas reales puso de manifiesto que los

mecanismos de estructuracin disponibles hasta el momento (principalmente los
esquemas) no eran suficientes para estructurar de manera adecuada aplicaciones de
gran tamao. Para mejorar esta deficiencia, diversos grupos han propuesto
alternativas en las que se integra la filosofa de la orientacin a objetos en Z. En
algunas se propone el uso de Z con un estilo orientado a objetos, mientras que en
otras se aaden nuevos elementos a Z que permitan la descripcin de los elementos
habituales en la orientacin a objetos (clases, objetos, mtodos,...).
Tcnicas basadas en lgebra de procesos

Los mtodos basados en algebras de procesos modelan la interaccin concurrente
entre procesos secuenciales. Todas siguen unos mismos principios bsicos:
La interaccin entre procesos se hace a travs de la participacin de estos en

eventos. Los eventos se suelen considerar atmicos (acciones indivisibles). En el
modelo general, no est limitado el nmero de procesos que pueden interactuar en
un mismo evento.
18
Todo evento se considera una interaccin entre procesos, con lo que se consigue
un modelo homogneo. Por ejemplo, escribir un valor en un registro es un evento
en el que interaccionan el proceso que est escribiendo el valor y el registro o el
sistema.
El funcionamiento de los constructores de procesos debe depender exclusivamente

de los procesos que toman parte en l. Como ejemplos de estos constructores
estn: conjuncin, disyuncin, encapsulacin, secuenciacin y simultaneidad. La
diferencia entre ellos est los puntos de sincronizacin que fuerza en los procesos.
CSP
La
idea
bsica
del
lenguaje
CSP
(Communicating
Sequential Processes) es definir la concurrencia mediante la

comunicacin de procesos que tienen un funcionamiento
interno secuencial y se comunican y sincronizan a travs de
unos canales restringidos, de forma que cada proceso slo tiene acceso a sus datos
locales. El proceso es el elemento bsico de CSP y denota el patrn de
funcionamiento de una entidad. Cada proceso puede involucrarse en un conjunto
concreto de eventos. Un proceso se define recursivamente, P = (e Q), donde el
proceso P consta de la ejecucin del evento e y, posteriormente, la ejecucin del
proceso Q. Se pueden concatenar acciones que se van a ejecutar secuencialmente.
Por ejemplo, s: (e1 e2 e3 e4 P).
Hay operadores de seleccin () y de concurrencia ().

Cuando los procesos se ejecutan en paralelo estn
restringidos a la sincronizacin en eventos comunes.
Dos procesos se comunican datos sincronizndose a
travs
de los canales, que son mecanismos
de
comunicacin unidireccionales y punto a punto. Cuando

un proceso ejecuta un evento de comunicacin de salida mediante la operacin!,
escribe un dato en el canal de comunicacin y otro proceso debe sincronizarse con l
ejecutando simultneamente un evento de entrada sobre el mismo canal mediante la
operacin?, en la que se lee el dato presente en el canal.
19
Con esos elementos bsicos, se puede especificar un sumador que reciba dos
nmeros por diferentes canales y los descarte tras transmitir la suma por un tercer
canal:
ADD = (in1?x in2?y out!(x + y) ADD
| in2?y in1?x out!(x + y) ADD)
La semntica original de CSP es un caso concreto de algebras de procesos y su

modelo ms simple es el modelo de trazas. Cada posible patrn de funcionamiento
de un proceso de denota mediante una secuencia de eventos, llamada traza. En el
modelo de trazas slo se pueden especificar propiedades de seguridad, pero no de
viveza. El modelo de trazas es extendido con otros modelos para cubrir esas
propiedades, como el modelo de rechazos, las divergencias o el modelo de fallos.
Timed CSP es una extensin que aade nuevos

operadores a la sintaxis original de CSP para
estudiar
propiedades
no
funcionales
de
los
sistemas, concretamente los tiempos de respuestas

para garantizar sincronizaciones en las que el
instante en el que se llega a la sincronizacin es
fundamental. Entre los nuevos operadores se encuentran la espera, que modela un
lapso de tiempo en el que el proceso no hace nada, el prefijo con retraso, el timeout y
la interrupcin temporizada
LOTOS
LOTOS (Language Of Temporal Ordering Specification) fue desarrollado por la ISO
para la especificacin formal de sistemas distribuidos abiertos. La parte de
funcionamiento de LOTOS est basada en el concepto de accin atmica e
instantnea. Si se precisa modelar acciones que tarden tiempo, se modela una accin
de inicio y otra de fin. Un sistema en LOTOS est constituido por subsistemas que se
ejecutan concurrentemente e interaccionan entre s. Los subsistemas pueden, a su
vez, estar compuestos por otros subsistemas ms simples formando una jerarqua.La
composicin paralela de estos subsistemas se hace de una manera muy simple: dos
procesos interactan cuando ejecutan una accin sobre un mismo punto de
interaccin (gates). En esta sincronizacin pueden intercambiar informacin.
20
El funcionamiento de un sistema se define mediante expresiones de funcionamiento

como stop, exit, la composicin secuencial (;) y la eleccin ([ ]). Se puede hacer uso
de la recursin para definir el comportamiento de un subsistema. Hay varios
operadores para componer en paralelo los subsistemas definidos: composicin
concurrente sin sincronizacin (|||), sincronizacin total (||) y sincronizacin selectiva
(|[...]|). Un concepto fundamental en la composicin jerrquica de subsistemas es la
ocultacin. El operador hide permite ocultar acciones de manera que ninguna otra
accin de otro subsistema se puede sincronizar con ella.
E-LOTOS (Enhancement to LOTOS) es una extensin de LOTOS que incorpora

novedades como el concepto de tiempo cuantitativo,
definicin de datos con un mtodo parecido a la
programacin
funcional,
modularidad,
nuevos
operadores para aumentar la potencia expresiva del

lenguaje y algunas instrucciones habituales de los
lenguajes imperativos de programacin.
RT-LOTOS (Real Time LOTOS) es otra extensin de LOTOS proporciona tres
operadores temporales principales: el operador de retraso, delay, que retrasa de
manera determinista la ocurrencia de acciones observables e internas, el operador de
latencia, latency, que expresa una latencia no determinista, y el operador de
restriccin que limita el tiempo durante el cual una accin observable es accesible
desde el entorno.
Lgicas temporales
Las
lgicas
temporales
permiten
expresar
el
funcionamiento de sistemas software en trminos de

frmulas lgicas, que incluyen restricciones temporales,
eventos y relaciones entre ambos. La capacidad expresiva
de estas lgicas ha ido creciendo y muchas de ellas son
capaces de especificar adecuadamente sistemas reactivos aunque no todas sirven
para especificar sistemas de tiempo real. Las lgicas temporales son una clase
particular de lgicas modales en las que el conjunto de mundos posibles representa
los instantes de un dominio temporal. Las ms usadas en la especificacin de
sistemas software son extensiones de lgicas de predicados de primer orden.
21
Generalmente se aaden, al menos, cuatro nuevos operadores sobre los tradicionales:

siempre en el futuro, alguna vez en el futuro, siempre en el pasado y alguna vez en el
pasado. Algunos casos aaden dos nuevos operadores, desde y hasta. Para usar las
lgicas temporales en la especificacin de sistemas de tiempo real, stas han de ser
capaces de expresar las restricciones temporales, las cuales se pueden dividir en dos
grandes grupos: (i) eventos y ordenacin de eventos y (ii) restricciones temporales
cuantitativas. Para la especificacin y anlisis de sistemas de tiempo real, en los que
se necesita una cuantificacin de las propiedades temporales, hace falta una mtrica
del tiempo. Una forma tpica de hacerlo es definiendo operadores acotados en el
tiempo. Por ejemplo, se puede definir un operador que afirme que una frmula es
siempre cierta entre los instantes 4 y 7: [4,7] A
PTL (Propositional Temporal Logic) extiende la lgica proposicional introduciendo

los operadores temporales siempre en el futuro, alguna vez en el futuro, a continuacin
y hasta. Las proposiciones describen relaciones temporales entre estados. PTL es una
lgica basada en eventos y no proporciona mtrica para el tiempo. Es especialmente
adecuada para sistemas reactivos o basados en eventos como las mquinas de
estados, pero no tanto para sistemas de tiempo real.
BTTL (Branching Time Temporal Logic) es una extensin de PTL en la que el
modelo de tiempo pasa de ser lineal a ser ramificado en el futuro, con lo que se
pueden especificar sistemas no deterministas. Los operadores originales de PTL son
ampliados para manejar estas ramificaciones.
RTCTL (Real Time Computational Temporal Logic) es una extensin de CTL

(Computational Tree Logic) para sistemas de tiempo real que proporciona una
mtrica para el tiempo. Sin embargo, el problema de la satisfacibilidad es doblemente
exponencial y el problema de la comprobacin de modelos es de coste polinomial.
RTTL (Real-Time Temporal Logic) aade una mtrica para el tiempo usando un reloj
global del sistema cuyo valor se aumenta peridicamente y que puede usarse en las
frmulas para incluir caractersticas temporales. La ordenacin de los eventos es
parcial porque aquellos que han ocurrido entre dos instantes son indistinguibles. Sin
embargo, las frmulas son muy flexibles a la hora de referirse al tiempo, lo que
tambin provoca que sean ms difciles de entender y de manipular que las de otras
lgicas.
22
TPTL (Timed Propositional Temporal Logic) tambin incluye una mtrica para el
tiempo haciendo corresponder a cada instante un nmero natural y usando una
funcin montona que asocia un valor temporal con cada estado del sistema.
IL (Interval Logic) es un lgica proposicional basada en intervalos. Su modelo de
tiempo es lineal, acotado en el pasado y no acotado en el futuro. No presenta mtrica
del tiempo. Los intervalos estn acotados por eventos y cambios de estado del
sistema.
EIL (Extended Interval Logic) y RTIL (Real-Time Interval Logic) extienden IL para
permitir la especificacin de restricciones cuantitativas tpicas de sistemas de tiempo
real.
LTI (Logic of Time Intervals) es una lgica temporal de
intervalos de segundo orden. Los intervalos se pueden dividir en
subintervalos hasta llegar a momentos. La lgica tambin permite
cuantificacin de los intervalos. Permite especificar sin problemas
restricciones sobre la ordenacin de los eventos, pero no
restricciones cuantitativas, ya que carece de mtrica de tiempo.
RTL (Real-Time Logic) extiende la lgica de predicados de primer orden con

operadores para expresar restricciones tpicas de un sistema de tiempo real, pero no
es una lgica temporal en el sentido tradicional. Presenta un reloj absoluto para medir
el progreso del tiempo, que puede ser referenciado en las frmulas. El modelo de
tiempo es lineal, discreto, acotado en el pasado, no acotado en el futuro y totalmente
ordenado. El principal problema es la dificultad de las formulas por el hecho de que se
referencia un tiempo absoluto, adems a un nivel de abstraccin muy bajo.
TLA (Temporal Logic of Actions) es una lgica que se basa en definir la semntica
de acciones de un programa, a diferencia de otras lgicas temporales, en la que las
propiedades de los programas son definidas mediante frmulas de la lgica de
proposiciones o predicados con operadores temporales. En los autores defienden la
idea de que no es necesario describir una nueva semntica para especificar sistemas
de tiempo real, sino que es suficiente con los mtodos usados para especificar
sistemas concurrentes. Basta con aadir una nueva variable de programa que se
refiera al tiempo.
23
Tcnicas
Formales
de Anlisis
de Sistemas
TEMA 3
Competencia:
Aplicar las tcnicas y herramientas formales
de anlisis de sistemas.
24
Tema 03: Tcnicas Formales de Anlisis de

Sistemas
TAU DE TELELOGIC
El modelado formal de sistemas ofrece grandes ventajas. En
primer
lugar,
permite eliminar
la
ambigedad
en
la
especificacin de un sistema, reduciendo de esa forma la

posibilidad
de
malentendidos
entre
los
diferentes
componentes del grupo de desarrollo. Tambin posibilita la

aplicacin de tcnicas de anlisis formales que garanticen matemticamente la
correccin del sistema, frente a los mtodos tradicionales de prueba y error, que tiles
para son detectar la presencia de errores, pero no garantizan su ausencia.
La existencia de una semntica formal para el modelo en

el que se ha descrito el sistema permite hacer uso de
herramienta automticas o semiautomticas para realizar
la
simulacin
del
funcionamiento
del
sistema,
su
verificacin, la validacin de posibles escenarios y la

generacin automtica de cdigo.
En las siguientes secciones introducimos brevemente, a modo de ejemplo de esta
posibilidad, la herramienta automtica de diseo Tau de Telelogic que, a partir de la
descripcin del sistema usando MSC y SDL permite realizar los anlisis mencionados
anteriormente.
MSC es un lenguaje grfico orientado a objetos que se usa para describir
escenarios, es decir, ejecuciones concretas del sistema. SDL permite expresar
mediante mquinas de estados el funcionamiento de las clases del sistema.
Simulacin
El primer paso en la simulacin de un sistema es la generacin de cdigo a partir de
su descripcin en SDL. Tau permite escoger el compilador que se va usar y configurar
mltiples opciones en la creacin del cdigo. El cdigo generado incluye en el sistema
un proceso monitor que permite controlar e inspeccionar la ejecucin del sistema
generado.
25
El simulador permite realizar una ejecucin

controlada del sistema de manera similar a como
lo hacen los depuradores tradicionales de los
lenguajes de programacin. Se puede, por
ejemplo, ejecutar el sistema hasta la siguiente
transicin.
Como
los
activadores
de
las
transiciones son seales desde el entorno, el

simulador permite simular el envo de seales externas. Tambin se puede establecer
un punto de ruptura en un smbolo del sistema y ejecutar el sistema hasta que llegue a
dicho smbolo. Asimismo, se puede ejecutar hasta la expiracin de un temporizador.
Existe la posibilidad de inspeccionar el estado interno del sistema, viendo la lista de

procesos, las colas de seales y el valor de las variables de estados de las instancias
de procesos. Se puede modificar el estado del sistema creando nuevas instancias de
procesos, modificando su estado o el valor de sus variables y se pueden activar y
desactivar temporizadores. Durante la simulacin se pueden obtener diferentes trazas
de la ejecucin. Se puede obtener tambin un registro en modo texto, se puede ir
viendo segn avanza la simulacin cules son los estados SDL que se van activando
o se puede generar un MSC que represente la historia de la ejecucin simulada,
mostrando los estados de los diferentes objetos involucrados y los mensajes
intercambiados entre ellos. Por ltimo, es posible seleccionar la cantidad de
informacin que muestra el registro de la simulacin.
Generacin de cdigo
Tau ofrece la posibilidad de generar cdigo ejecutable de la aplicacin a partir de la
descripcin SDL. La generacin de cdigo se compone de dos elementos, el
generador de cdigo C a partir de la especificacin SDL y las bibliotecas predefinidas
que incluyen el runtime de SDL y los elementos de monitorizacin del sistema, por si
el cdigo generado se usa para simulacin o validacin. Las bibliotecas de runtime
incluyen los mecanismos de comunicacin del sistema con el entorno. En realidad, lo
que se genera es el cdigo correspondiente al funcionamiento de las mquinas de
estados. Dentro de cada accin de SDL se pueden incluir sentencias en C que se
integraran en el cdigo generado.
26
Tau ofrece tres versiones del generador de cdigo C a

partir de SDL, CBasic, solo para simulacin y
validacin,
CAdvanced,
para
cualquier
tipo
de
aplicacin, y CMicro, que genera versiones ms

pequeas y optimizadas, ms tiles cuando se trata de
sistemas empotrados con restricciones fuertes de
memoria y capacidad de procesamiento.
Cuando se genera cdigo se incluyen macros para

tratar la interaccin con el entorno, como las llamadas
al sistema y el envo y recepcin de seales. Las
macros dependen del nivel de integracin, que puede
ser
ligera,
light
integration,
ajustada
tight
integration. El cdigo generado con la integracin

ligera se ejecuta con una sola hebra del sistema operativo subyacente para toda la
aplicacin, por lo que la planificacin corre a cargo del runtime incluido en el cdigo
generado, lo que permite su ejecucin sin sistema operativo subyacente.
Por su lado, el cdigo que se genera con la

integracin ajustada contiene una hebra del
sistema
operativo
por
cada
proceso
de
la
aplicacin. En el modo de integracin ligera, los

procesos no son interrumpibles, pero en ajustado
s lo son, dependiendo de las posibilidades del
sistema operativo sobre el que se est trabajando.
Con CMicro existe un modo adicional de generacin de cdigo, bare integration, que
no incluye macros de manejo de dispositivos fsicos ni de seales. Este modo permite
personalizar el cdigo resultante mediante el uso de funciones de la biblioteca de
CMicro para definir esos manejadores.
27
Validacin y verificacin
Tau tambin ofrece una herramienta para validar sistemas. Una
vez especificado el sistema en SDL se puede compilar con la
ayuda de un compilador de C y generar un modelo ejecutable
que se puede validar para encontrar errores o inconsistencias o
verificar respecto a determinados requisitos. El sistema generado
incluye un monitor, al igual que el sistema generado para la simulacin, pero con un
abanico de rdenes distintas. El sistema SDL examinado con el validador se
representa mediante un rbol de funcionamiento, en el que cada nodo representa un
estado completo del sistema SDL. Es posible examinar el funcionamiento del sistema
recorriendo el rbol y examinando los estados.
El tamao del espacio de estados explorado se puede configurar y de l depende el

nmero de estados generados tras una transicin y el nmero de posibles sucesores
de un estado. El validador permite seguir la traza del sistema paso a paso de manera
similar a como se haca en la simulacin, pero ofreciendo informacin adicional, como
la lista de posibles transiciones a ejecutar en un estado. De este modo, el validador
puede informar sobre errores dinmicos, como el envo de una seal que no puede ser
recibida por ningn proceso.
El validador puede mostrar un MSC con la secuencia

de estados que lleva a un estado en el que se ha
producido un error. Para los sistemas cuyo espacio
de estados es demasiado grande para llevar a
cabo un recorrido exhaustivo se puede hacer un
recorrido aleatorio, escogiendo arbitrariamente un
camino de entre los posibles en cada transicin.
Otra funcionalidad proporcionada en Tau es la
verificacin de un posible escenario descrito mediante un MSC. En este caso, el
validador recibe el MSC y el sistema como entrada y simula aquellos caminos del rbol
de estados que pueden reproducir el MSC. La validacin acabara informando de si
ese MSC es posible en el sistema o de si hay caminos que lo violen.
28
Comprobacin de modelos
La comprobacin de modelos (model checking) es una tcnica de verificacin formal
en la que las propiedades de funcionamiento de un sistema se comprueban a travs
del recorrido exhaustivo, implcita o explcitamente, de todos los estados alcanzables
por el sistema y todos los funcionamientos que puede alcanzar durante ellos.
La comprobacin de modelos ofrece dos ventajas sustanciales respecto a otros
mtodos de verificacin: es completamente automtico y su aplicacin no requiere un
conocimiento profundo de disciplinas matemticas, y cuando el diseo no cumple una
propiedad el proceso siempre genera un contraejemplo.
Una variante muy interesante es la comprobacin de modelos simblica en la que se
puede hacer una enumeracin implcita exhaustiva de un nmero de estados
astronmicamente grande.
La comprobacin de modelos tiene dos limitaciones fundamentales: es aplicable solo a

sistemas de estados finitos y el nmero de estados crece exponencialmente cuando
hay varios procesos ejecutndose en paralelo.
La aplicacin de esta tcnica se divide en tres etapas: el modelado del sistema, la
especificacin de propiedades y la verificacin.
Aunque idealmente la verificacin de propiedades con la tcnica de comprobacin de
modelos es un proceso automtico, comnmente tiene que contar con la supervisin
humana, concretamente en el anlisis de los contraejemplos en aquellas situaciones
en que se ha detectado que el sistema no cumple la propiedad analizada.
La evolucin del sistema se modela mediante un grafo en el que cada nodo representa
un estado, o conjunto de estados, del sistema que se expresa como una frmula lgica
que se satisface en dicho estado o conjunto de estados. Las propiedades a verificar
se modelan como formulas lgicas y se comprueba si se cumplen o no en los nodos
del rbol. La existencia de una semntica formal para el modelo en el que se ha
descrito el sistema permite hacer uso de herramienta automticas o semiautomticas
para realizar la simulacin del funcionamiento del sistema, su verificacin, la validacin
de posibles escenarios y la generacin automtica de cdigo.
29
Lenguajes
Grficos de
Modelado
TEMA 4
Competencia:
Emplear los lenguajes grficos de modelado
para sistemas en tiempo real.
30
Tema 04: Lenguajes Grficos de Modelado
SDL
SDL, (Specification and Description Language) es un
lenguaje en el que se describen sistemas como un
conjunto de procesos concurrentes que se comunican
entre s y con el entorno. El funcionamiento de los procesos
est descrito en base a mquinas de estados comunicantes extendidas. SDL
especialmente recomendado para sistemas distribuidos y reactivos.
Uno de los principales objetivos al definir SDL fue su facilidad de uso, por lo que se
opt por un modelo grfico, ms intuitivo que uno textual. Las
versiones
iniciales
no
tenan
una
semntica
formal
subyacente, lo que provocaba problemas porque permita

diferentes
interpretaciones,
dificultaba
el
desarrollo
de
herramientas automticas que ayudaran a su uso y haca ms

complicada la descripcin precisa de sistemas complejos.
Estos inconvenientes llevaron a la definicin de una semntica
formal que se incluy por primera vez en la versin de 1988.
SDL describe la estructura del sistema de manera jerrquica mediante los

constructores sistema, bloque, proceso y procedimiento. Una descripcin en SDL se
compone de un sistema que muestra los lmites y la comunicacin entre el sistema
descrito y su entorno. El sistema se divide en bloques
que se comunican a travs de mensajes y estos bloques
se componen a su vez de procesos que son entidades
que se ejecutan concurrentemente. Los procedimientos
definen
secuencias
de
cdigo
que
se
ejecutan
secuencialmente en el mbito de un proceso.
31
A modo de ejemplo se va a especificar en SDL un sistema muy simple. Se trata de una

mquina expendedora que acepta fichas para vender un producto. El sistema se
compone de dos procesos, uno que inicia la venta y otro que realiza la cuenta del
importe ingresado. Si quedan existencias, se espera a que se introduzcan nuevas
fichas hasta que se complete el precio. El usuario tiene en cualquier momento la
posibilidad de anular la compra.
En la Figura 4.1 se muestra la descripcin del ejemplo a nivel de sistema en la
que hay un nico bloque que se comunica con el entorno a travs de dos
canales, para cada uno de los cuales se indican sus seales.
Figura 4.1. Descripcin a nivel de sistema.
En la Figura 4.2 se muestra la descripcin a nivel de bloques en la que se ven dos

procesos que se comunican entre s y con el entorno. Tambin se ve la
correspondencia entre los nombres de las rutas de seales y los canales. Adems de
los canales de comunicacin con el entorno, hay un canal interno, no visible desde
fuera del sistema, por el que se comunican los dos bloques.
32
Figura 4.2.Descripcin a nivel de bloques.
Figura 4.3. Descripcin del proceso controlador.
33
El proceso controlador, cuya mquina de estados se muestra en la Figura 4.3, se

encarga de iniciar y arrancar la venta. El proceso contador, Figura 4.4, lleva a
cabo la tarea de comprobar el pago. En ambos casos el funcionamiento viene
desarrollado mediante una mquina de estados muy simple.
Figura 4.3. Descripcin del proceso contador.
34
SDL para tiempo real

Aunque SDL tiene herramientas para especificar el paso del tiempo, como la
operacin now y los temporizadores, diversos trabajos de investigacin han sealado
que no son suficientes para especificar las restricciones habituales en los sistemas de
tiempo.
UML
UML, (Unified Modeling Language), surge a mitad de los
noventa como fusin fundamentalmente de tres mtodos de
desarrollo orientados a objetos, el mtodo de Booch, el
mtodo OOSE y el mtodo OMT. Cada uno de estos tres
mtodos era especialmente indicado en una de las fases
del desarrollo y se intent generar un nico mtodo que
fuera til durante todo el desarrollo y que eliminara los
problemas de contar con diferentes nomenclaturas.
Aunque UML no es una metodologa, sino un conjunto de lenguajes, su objetivo es

visualizar, especificar, construir y documentar los elementos de sistemas con gran
cantidad de software. Los lenguajes definidos en UML son fundamentalmente grficos,
para facilitar su estudio y comprensin. En UML se definen nueve tipos de diagramas,
algunos de los cuales modelan diferentes vistas estticas del sistema y otros modelas
vistas dinmicas:
Diagramas de clases, ste es un diagrama esttico en el que se muestran
cules son las clases involucradas en el sistema y las relaciones entre ellas.
Diagramas de objetos, ste es otro diagrama esttico est ntimamente
relacionado con el anterior. Muestra una vista de las instancias reales de las
clases que estn en ejecucin en el sistema en un momento determinado.
Diagramas de casos de uso, en estos diagramas se muestran conjuntos de
casos de usos y actores y sus relaciones.
35
Diagramas de secuencia, estos diagramas muestran parte de la vista dinmica,

concretamente una interaccin entre un subconjunto de objetos, bsicamente a
travs del envo de mensajes entre ellos. Estos diagramas priman la ordenacin
temporal de los mensajes.
Diagramas de colaboracin, estos diagramas son isomorfos a los diagramas de

secuencia, muestran la misma interaccin, pero resaltando la organizacin
estructural de los objetos.
Diagramas de estados, son mquinas de estados que especifican el

funcionamiento de los objetos de una clase. Se centran en el comportamiento de
sistemas reactivos dirigidos por eventos.
Diagramas de actividad, son un tipo especial de diagrama de estados que

resaltan el flujo de actividad entre los objetos.
Diagramas de componentes, son diagramas estticos que

muestran la organizacin y las dependencias entre los componentes.
Un componente suele corresponder a varias clases o interfaces.
Diagramas de despliegue, es una vista esttica estructural
en la que se relacionan los nodos de procesamiento con los

componentes que residen en ellos.
En UML se definen cuatro tipos fundamentales de elementos:
Estructurales. La mayora son elementos estticos e incluyen clases, interfaces,

colaboraciones, casos de uso, clases activas, componentes y nodos.
De comportamiento. Son las partes dinmicas del modelo e incluyen relaciones

y mquinas de estados. Estn asociados a uno o varios elementos estructurales.
De agrupacin. Son los elementos organizativos del modelo. Los nicos

elementos de agrupacin son los paquetes, que se pueden descomponer en
elementos ms simples.
De anotacin. Sirven para incluir explicaciones sobre los dems elementos del
modelo. Las notas son los elementos explicativos. Son simplemente smbolos
que introducen restricciones y comentarios.
36
Hay cuatro tipos de relaciones en UML:
Dependencia. Es una relacin semntica entre dos elementos en la que un

cambio en un elemento puede afectar a la semntica en el otro.
Asociacin. Es una relacin estructural que define un conjunto de conexiones

entre objetos. La agregacin es un tipo especial de asociacin.
Generalizacin. En
una relacin de generalizacin/especializacin los
elementos que especializan pueden sustituir al especializado. El caso ms usual

en la relacin de herencia entre clases.
Realizacin. Es una relacin semntica entre clasificadores en la que un

clasificador especifica un contrato que otro clasificador realizara. Esta relacin se
da entre interfaces y clases y entre casos de uso y diagramas de colaboracin.
Metamodelado
Cuando se define un lenguaje de modelado de sistemas, ste
suele poder aplicarse a un conjunto ms o menos amplio de
casos, dependiendo de la generalidad del lenguaje. Si el
lenguaje es muy especfico puede quedar reducido a
modelar sistemas de un tipo muy concreto como, por
ejemplo, sistemas elctricos, o cualquier otro. Si el lenguaje de modelado es
suficientemente genrico y puede modelar una gama amplia de sistemas, puede llegar
a modelar el propio lenguaje de modelado como un caso concreto de sistema
modelado. En este caso, los elementos del lenguaje no se usan para describir los
valores de los datos del sistema sino caractersticas de los datos del sistema.
Esta circunstancia del modelado del modelo en vez del modelado de valores se
conoce como metamodelado. Esta metarelacin no es exclusiva
del modelado de sistemas. Bien al contrario, se puede encontrar
en mltiples situaciones en el mbito de la informtica. Por
ejemplo, en las bases de datos, los metadatos son datos sobre
datos, los meta intrpretes son programas en cuya ejecucin, se
usan como datos ejecuciones de programas (por ejemplo los depuradores) o, en un
sistema de informacin, se puede tener el modelo E-R del modelo E-R del sistema.
37
El metamodelado suele definirse en niveles. El lenguaje de modelado puede definirse

mediante un metamodelo, donde los constructores presentes en el metamodelo se
denominan metaelementos y su relacin con los elementos del lenguaje de modelado
es que stos son instancias de aquellos, o sea, un elemento del lenguaje de modelado
es un caso concreto de un meta elemento del nivel de metamodelado.
Esta
definicin
puede
asimismo
aplicarse
al
metamodelo, que puede ser descrito en trminos de

otro nivel superior, el metametamodelo, y cada
metaelemento
es
una
instancia
de
un
metametaelemento. Esta jerarqua de definiciones se

podra extender tantos niveles como se quisiera, pero
en general, hay consenso sobre el uso de cuatro
niveles distintos de abstraccin:
Metametamodelo.
Describe
la
infraestructura
para
la
arquitectura
de
metamodelado, incluyendo el lenguaje de descripcin de metamodelos.

Metamodelo. Describe el lenguaje de especificacin de modelos.
Modelo. Describe el lenguaje para describir sistemas.
Elementos de usuario. Describe los valores concretos de un sistema particular.
Cuando un nivel es una instancia del nivel superior, se habla

de metamodelado dbil (loose metamodeling). Si se
consigue que cada elemento de un nivel sea instancia de un
solo elemento del nivel superior, se habla de metamodelado
fuerte (strict metamodeling). Uno de los casos ms
populares del uso de metamodelos en la definicin de
lenguajes de modelado es el que usa el OMG para describir
diferentes lenguajes de modelado y su conexin. El OMG usa dos especificaciones
distintas para modelar sistemas informticos distribuidos y sus interfaces en CORBA:
Lenguaje Unificado de Modelado (Unified Modeling Language, UML)
Servicios de Meta-Objetos (Meta-Object Facility, MOF)
38
La especificacin de UML define un conjunto de lenguajes grficos para visualizar,

especificar, construir y documentar los elementos de sistemas distribuidos orientados
a
objetos. La especificacin incluye un metamodelo, una notacin

grfica y un servicio de IDL en CORBA que permite el intercambio
de modelos entre las herramientas que manejan el metamodelo de
UML y repositorios de metadatos.
La especificacin de MOF define un conjunto de interfaces IDL en
CORBA que pueden usarse para definir y manipular un conjunto de
metamodelos
sus
correspondientes
modelos.
Entre
estos
metamodelos estn el metamodelo e UML, el metametamodelo de

MOF y, segn los planes actuales, estaran los metamodelos de las
nuevas propuestas del OMG que usen metamodelado.
UML y MOF estn basados en la arquitectura de metamodelado de cuatro niveles, por

lo que se ha intentado que estn lo ms alineado posible y que comparan la mayor
parte de los elementos semnticos centrales. Este alineamiento permite reutilizar los
elementos de UML en MOF para visualizar los elementos de los metamodelos. El
metamodelo de UML puede ser considerado una instancia del As a metametamodelo
de MOF. Como los objetivos de MOF y de UML son distintos, no se ha conseguido
seguir un metamodelo fuerte, sino que se ha optado por el metamodelado dbil. A
pesar de estas diferencias, la similitud entre la estructura de ambos modelos es muy
grande y la mayora de los conceptos pueden ser traducidos de un nivel a otro de
manera directa. Para aquellos elementos para los que no es posible esta aplicacin
inmediata, se definen reglas de transicin de un nivel a otro.
39
Lecturas Recomendadas
MODELAMIENTO: FUNDAMENTOS
http://galeon.com/mcoronado/ANALISIS_UNIDADES/01MODELAMIENTO.pdf
ANLISIS Y DISEO DE SISTEMAS INFORMTICOS

http://personales.upv.es/igil/Adsi.pdf
Actividades y Ejercicios
1. En un documento en Word realice un mapa conceptual sobre

el modelamiento de sistemas (S.) informticos (I.).
Envalo a travs de "Modelamiento de S. I.".
2. En un documento en Word seale 10 de los diferentes

manuales o tutoriales del lenguaje de programacin en UML.
Adems presente una aplicacin (A.) en sistema (S.) de
tiempo (T.) real (R.).
Envalo a travs de "UML & A. S. T. R.".
40
Autoevaluacin
1) Es una caracterstica de un buen modelo:

a. La abstraccin.
b. La rigurosidad.
c. La eficiencia.
d. La seguridad.
e. La educacin.
2) Una de la razones de la necesidad del modelados es:
a. Responder satisfactoriamente a eventos no esperados.
b. Predecir los resultados con exactitud.
c. Proporcionar resultado exactos.
d. Obtener pruebas de radio diagnsticos eficientes.
e. Evitar las muertes por dosis altas de medicina.
3) Los sistemas de tiempo real son:
a. Sistemas informticos que se trabajan sin mantenimiento.
b. Sistemas informticos donde el tiempo es relativo.
c. Una clase de sistemas informticos sin errores.
d. Una clase de sistemas informticos que se actualizan solos.
e. Sistemas en los que el tiempo de respuesta es crucial.
4) Algunos mtodos de modelado de sistema se basan en:
a. La teora algebra lineal.
b. La lgica de sujetos.
c. El lgebra de procesos.
d. Lgicas mtodos.
e. Lgicas de tiempo.
5) Es un mtodo con expresin grfica:
a. SPL.
b. Las mquinas de estados de UML.
c. Los stategraph.
d. Las redes de petronila.
e. Lgica de predicados.
41
6) El primer paso en la simulacin de un sistema es:

a. Es buscar un simulador.
b. La generacin de cdigo.
c. Conocer el problema a simular.
d. Inspeccionar el sistema internos del sistema.
e. Controlar el sistema.
7) La versin del generador de cdigo C a partir de SDL, CBasic, es solo para:
a. Simulacin y validacin.
b. Para cualquier tipo de versin.
c. Aplicaciones pequeas.
d. Sistema empotrados.
e. Para macros.
8) La comprobacin de modelos es una tcnica de:
a. Validacin de sistemas de tiempo real.
b. Generar cdigo c para la simulacin.
c. Verificacin formal de todos los estados alcanzables por el sistema.
d. Generar sistemas empotrados.
e. Crear macros para sistemas empotrados.
9) El SDL es un lenguaje en el que se describen sistemas como:

a. Un sistema de lenguaje de simulacin.
b. un conjunto de procesos divergentes con el entorno.
c. un conjunto de sistemas que interactan con el entorno.
d. un conjunto de procesos concurrentes que se comunican entre s.
e. un conjunto de procesos independientes.
10) UML es:
a. Una metodologa.
b. Un conjunto de mtodos.
c. Un documento del sistema.
d. Un conjunto de lenguajes de modelado.
e. Una gran cantidad de software.
42
Resumen
UNIDAD DE APRENDIZAJE I:
El uso de modelos es una herramienta bsica para tratar esta complejidad, ya que
permite hacer una rplica ms simple del sistema, de la que eliminan detalles que no
son fundamentales, obteniendo as un objeto de estudio ms sencillo de entender,
manejar y que permite hacer predicciones sobre aspectos importantes del sistema real.
La necesidad del modelado es de construir sistemas informticos libres de errores y que
respondan a los requisitos con que se pensaron.
Algunos de los mtodos de modelado usan como base la lgica de predicados de primer
orden. Hay otros que se basan en la teora de conjuntos, para describir los cambios de
estados de los datos del sistema. Otros se basan en lgebras de procesos. Otro grupo
es el formado por los mtodos basados en lgicas modales, generalmente lgicas
temporales, que permiten modelar la evolucin del estado del programa en el tiempo.
La semntica formal para el modelo permite hacer uso de herramientas automticas o

semiautomticas para realizar la simulacin del funcionamiento del sistema, su
verificacin, la validacin de posibles escenarios y la generacin automtica de cdigo.
Tales como la herramienta automtica de diseo Tau de Telelogic que, a partir de la
descripcin del sistema usando MSC y SDL permite realizar los anlisis mencionados
anteriormente.
SDL, es un lenguaje en el que se describen sistemas como un conjunto de procesos

concurrentes que se comunican entre s y con el entorno. SDL describe la estructura
del sistema de manera jerrquica mediante los constructores sistema, bloque, proceso
y procedimiento. UML no es una metodologa, sino un conjunto de lenguajes, su
objetivo es visualizar, especificar, construir y documentar los elementos de sistemas
con gran cantidad de software.
43
44
Introduccin
La metodologa de desarrollo de software de tiempo real se refiere a un framework
que es usado para estructurar, planear y controlar el proceso de desarrollo en
sistemas de informacin. A lo largo del tiempo, una gran cantidad de mtodos han
sido desarrollados diferencindose por su fortaleza y debilidad.
b) Competencia:
Reconoce las distintas metodologas de desarrollo de sistemas de tiempo
real, analizando el requerimiento de las situaciones.
c) Capacidades:
1. Reconoce las diversas metodologas estructuradas orientadas a los objetos.
2. Aplica las metodologas basadas en SDL y en UML de sistemas.
3. Explica la importancia de la semntica de acciones para MML.
4. Descompone acciones complejas en acciones primitivas o ms simples.
d) Actitudes:
Se interesa por el anlisis de las metodologas estructuradas orientada a
objetos.
Promueve la aplicacin de la semntica de acciones para MML.

La Unidad de Aprendizaje 02: Metodologas de Desarrollo de Sistemas de
Tiempo Real, comprende el desarrollo de los siguientes temas:
TEMA 01: Metodologas Estructuradas Orientada a Objetos.
TEMA 02: Metodologas Basadas en SDL y en UML.
TEMA 03: Una Semntica de Acciones para MML.
TEMA 04: Acciones Primitivas.
45
Metodologas
Estructuradas
Orientada a
Objetos
TEMA 1
Competencia:
Reconocer
las
diversas
metodologas
estructuradas orientadas a los objetos.
46
Tema 01: Metodologas Estructuradas

Orientada a Objetos
METODOLOGAS ESTRUCTURADAS
Los mtodos de diseos se pueden dividir en informales,
estructurados y formales. Los estructurados se diferencian de los
informales en que aquellos usan mtodos de representacin, que
pueden ser grficos, bien definidos, construidos a partir de un pequeo nmero de
componentes predefinidos interconectados de manera controlada. Sin embargo, a
diferencia de los mtodos formales, los lenguajes de los mtodos estructurados
carecen de la base matemtica que permita realizar anlisis formal de propiedades del
sistema. Las metodologas estructuradas no incorporan fundamentos formales debido
a la complejidad que presentan, que implica un coste muy alto en la formacin de
personal cualificado para su uso, especialmente en sistemas de gran complejidad.
HOOD, JSD y MASCOT son algunos ejemplos de metodologas estructuradas de

diseo.
Estas
metodologas
incorporan
mecanismos
para
especificar
las
caractersticas no funcionales de los sistemas de tiempo real, como la concurrencia,

los requisitos temporales, la tolerancia a fallos y la interaccin con los dispositivos
fsicos. Las metodologas estructuradas ms usadas son las denominadas
metodologas de diseo modular, que incorporan aspectos funcionales para la
especificacin de requisitos y abstracciones de datos en el resto del diseo.
A partir de los requisitos se obtienen diagramas de flujos de datos

que identifican procesos secuenciales de clculos y que pueden
ser refinados hasta obtener transformaciones de datos de bajo
nivel. En el siguiente paso se tiene en cuenta la concurrencia
inherente del sistema y se agrupan los flujos de control
secuenciales en hebras de accin concurrentes, en funcin de
diferentes heursticos. Por ejemplo, se pueden agrupar en funcin de los componentes
fsicos que usen, en base a consideraciones temporales o a su criticidad.
47
Seguidamente, se definen las tareas que van a componer el sistema a partir de las
hebras de accin concurrentes previas. La divisin en tareas dependera del estudio
de la concurrencia de la aplicacin, la conexin entre procesos y el acoplamiento y la
cohesin entre las tareas. En esta definicin se tiene en cuenta el modelo de tareas en
el que se van a implementar, para que dicha implementacin sea lo ms fcil posible.
Finalmente, a partir de las tareas, se crean las estructuras de datos que se van a usar
en el programa, bien basndose en tipos abstractos de datos o en objetos. La
caracterstica diferenciadora es que en estas metodologas se tiene en cuenta la
concurrencia antes que el modelo de datos.
Metodologas orientadas a objetos

La cualidad fundamental de las metodologas orientadas a
objetos es que construyen el sistema desde un primer
momento enfocando la atencin sobre los datos, creando
una red de entidades que se comunican, llamadas objetos.
Estas
metodologas se han mostrado especialmente adecuadas en la definicin de sistemas

interactivos, por lo que se adecan bien a los sistemas de tiempo real.
Hay dos modelos de concurrencia en los diseos

orientados a objetos, el implcito y el explcito. En el
implcito se supone en las primeras fases del diseo que
cada objeto es una unidad concurrente de ejecucin y
los anlisis se hacen en funcin de esa suposicin. En
las fases finales, el modelo de concurrencia se concreta
en funcin de las posibilidades que ofrezca el sistema
subyacente. En el modelo explcito los objetos se agrupan
desde un primer momento en procesos, que son los elementos concurrentes. De entre
estas metodologas destacamos HRT-HOOD, Octopus y ROOM que describimos
brevemente ms a continuacin.
48
HRT-HOOD
HRT-HOOD surge como una extensin de HOOD para
incorporar los aspectos no funcionales de los sistemas de
tiempo real. HRT-HOOD complementa las fases que
considera habituales en otras metodologas de desarrollo
de software definicin de requisitos, diseo estructural, diseo detallado,
codificacin y pruebas para evitar que los aspectos claves en los sistemas de
tiempo real se aborden demasiado tarde.
Para construir el sistema se describen compromisos, cada vez ms especficos, que
no se pueden modificar en niveles inferiores. Las obligaciones son los aspectos no
cubiertos por los compromisos, y que el nivel inferior debe resolver.
Este proceso de transformacin de obligaciones en compromisos para el siguiente

nivel est frecuentemente limitado por las restricciones que imponen los niveles
inferiores. Esos tres elementos influyen en gran medida en el diseo estructural. En el
diseo de la parte lgica de la arquitectura se suelen tratar aspectos funcionales y es,
en general, independiente de las restricciones del entorno fsico. La parte fsica de la
arquitectura tiene en cuenta los requisitos y otras restricciones y se encarga de los
aspectos no funcionales. La arquitectura fsica es la base de los anlisis de los
requisitos no funcionales una vez que se hayan llevado a cabo el diseo detallado y la
implementacin. La arquitectura fsica es un refinamiento de la lgica, aunque ambas
se van desarrollando en un proceso iterativo y concurrente.
Una vez terminado el diseo estructural se procede a realizar

el diseo detallado, sobre el que habr que hacer nuevas
estimaciones del tiempo de respuesta del cdigo conseguido,
para ver si se sigue cumpliendo el anlisis de planificabilidad
que se hizo en el diseo de la arquitectura fsica,
generalmente con tiempos estimados de manera menos precisa. En el diseo de la
arquitectura lgica solo se permite un conjunto concreto de objetos: activos, pasivos,
protegidos, cclicos y espordicos. Cada tipo est restringido en varios aspectos, como
el tipo de llamadas que puede hacer o la concurrencia interna, para facilitar el anlisis.
49
La fase de diseo fsico lleva a cabo la aplicacin de los elementos definidos en la

arquitectura lgica a los elementos fsicos sobre los que se construir el sistema. Para
realizar los anlisis necesarios sobre las caractersticas no funcionales hace falta que
el diseo se haya hecho de forma que permita el anlisis y que se puedan conocer las
caractersticas temporales de la plataforma sobre la que se ejecutar el sistema. En
esta fase se han de realizar tareas de ubicacin de objetos, planificacin de procesos
y redes y dependabilidad, incluyendo las cuestiones relativas al manejo de errores.
Los elementos del diseo se representan grficamente mediante objetos, similares a

los de HOOD. La nica diferencia es que incluye nueva informacin sobre el tipo de
objeto que es. Los objetos distinguen entre la interfaz y su implementacin interna y
pueden descomponerse a su vez en objetos ms simples. Los requisitos no
funcionales se expresan a travs de atributos de tiempo real que indican cuestiones
como el perodo, plazos temporales, etc.
En la Figura 1.1 se muestra el esquema de mayor nivel de una bomba de extraccin

de agua en una mina especificado en HRT-HOOD.
Figura 1.1. Parte del sistema de control de una mina especificado en HRT- HOOD.
50
Octopus
Octopus es una metodologa basada en otras dos previas, OMT y Fusin, que ha
intentado mantener las partes positivas de ambas y aadir los elementos necesarios
para el desarrollo de sistemas de tiempo real. Octopus tiene modelos estructural,
funcional y dinmico a nivel de sistema, subsistema, clases y objetos. Estos niveles de
abstraccin se reparten entre las diferentes fases: de requisitos, de arquitectura de
sistemas, de anlisis de subsistemas, de diseo de subsistemas y de implementacin
de subsistemas.
ROOM
ROOM
(Real-Time
Modeling)
es
otra
Object
Oriented
metodologa
de
desarrollo orientada a objetos y, segn sus

autores, cubre las deficiencias de otras
metodologas anteriores para el desarrollo de sistemas de tiempo real. Para ello se
centra en desarrollar sistemas de este tipo, incluyendo un conjunto bsico de
elementos de diseo suficiente para describir adecuadamente los sistemas de tiempo
real, pero sin querer ser una metodologa demasiado genrica para mantener su
utilidad y evitar que sea demasiado complicada.
ROOM puede usarse para crear un modelo ejecutable

orientado a objetos de un sistema de tiempo real y para
soportar estrategias comnmente usadas en la construccin
de modelos. El elemento bsico de los modelos de ROOM
son las clases de actores, que representan un conjunto de
objetos con caractersticas y funcionamiento comunes.
Estos objetos, u actores, son instancias de las clases de
actores y representan mquinas lgicas, independientes y
que funcionan concurrentemente.
51
Metodologas
TEMA
2
Basadas en
SDL y en
UML
Competencia:
Aplicar las metodologas basadas en SDL y
en UML de sistemas.
52
Tema 02: Metodologas Basadas en SDL y en

UML
Metodologas basadas en SDL: SOMT
La tecnologa SOMT integra anlisis orientado a objetos con
diseo en SDL y se centra fundamentalmente en sistemas
para
los
que
consideran
que
estos
modelos
son
especialmente apropiados, como los sistemas empotrados,

los de tiempo real y los que tienen una alta carga de
comunicacin. La metodologa SOMT se divide en las cinco fases habituales: anlisis
de requisitos, anlisis del sistema, diseo del sistema, diseo de objetos e
implementacin. Adems de estas fases, la metodologa aade como elemento
fundamental guas para pasar de los modelos de una fase a los de la siguiente.
En la fase de anlisis de requisitos se parte de un documento textual de requisitos y se

intenta conseguir una definicin formal de los mismos. Esta definicin se hace a
distintos niveles. Por un lado, se realizan diagramas de clases para obtener el modelo
de objetos de los requisitos y, por otro, se establecen los casos de uso mediante texto
estructurado o diagramas MSC. Tambin se crea un diccionario de datos. En el
anlisis de sistemas se describe la arquitectura del sistema y se identifican los objetos
necesarios para implementar la funcionalidad requerida. Los objetos se representan
mediante diagramas de clases y las relaciones entre ellos se especifican mediante
escenarios descritos en MSC.
En el diseo del sistema se define la estructura de

implementacin
se
identifican
las
estrategias
globales de diseo. En esta fase se definen la

estructura modular del diseo y la definicin de la
arquitectura mediante diagramas de sistemas y
bloques en SDL y definicin de interfaces basados en
seales
llamadas
remotas
procedimientos.
Tambin se establecen los casos de uso del diseo mediante MSC.
53
En la fase de diseo de objetos se crea una descripcin completa y formalmente

verificable del funcionamiento del sistema, bsicamente mediante diagramas de
procesos en SDL. Esta fase tambin incluye tareas de prueba y verificacin. En la fase
de implementacin y pruebas se produce el producto ejecutable final. Las actividades
de esta fase pueden incluir la generacin automtica de cdigo, la integracin en el
entorno fsico y la realizacin de pruebas.
Una de las herramientas que proporciona la metodologa SOMT para guiar el paso
entre los diferentes modelos de las sucesivas fases del desarrollo son los implinks,
los enlaces de implementacin, y la posibilidad de pegarlos en una fase posterior. Con
los implinks se pueden marcar los objetos de las fases iniciales de anlisis y diseo y
posteriormente integrarlos y relacionarlos con elementos de los diagramas SDL, de tal
manera que se facilita la navegacin entre los conceptos relacionados en los
diferentes diagramas y se puede comprobar mejor su coherencia, especialmente
cuando se producen cambios.
The Codesign Methodology

Mitschele
Thiel
Slomka
proponen
en
una
metodologa de diseo mixto de sistemas con

componentes
fsicos
lgicos
basada
en
extensiones de SDL y MSC, reutilizando procesos de desarrollo con estos formalismos

previos. Ambos son extendidos para incluir aspectos no funcionales y de
implementacin. MSC es extendido para incluir la expresin de restricciones
temporales. Esta extensin es denominada PMSC. SDL tambin es extendido en un
lenguaje denominado SDL*. En ambos casos las extensiones consisten en
anotaciones sobre diagramas en los lenguajes originales que incluyen informacin no
funcional, como restricciones de tiempo o de despliegue en componentes fsicos.
Con estas extensiones se pretenden abordar los aspectos no funcionales y de

implementacin de manera formal. La metodologa sigue un desarrollo iterativo en el
que cada ciclo corresponde a una fase del desarrollo: diseo inicial, formalizacin,
diseo de la implementacin e implementacin final. Durante el diseo se realiza un
refinamiento paralelo desde la especificacin en PMSC y SDL* hasta la
implementacin en VHDL y C.
54
La fase inicial de especificacin de requisitos produce la descripcin informal de los

requisitos del sistema, tanto los funcionales como los no funcionales. En la fase de
diseo inicial se modelan los casos de uso en PMSC, empleando las extensiones para
incluir los requisitos temporales. Con alguna informacin adicional, sobre este primer
diseo pueden llevarse a cabo anlisis de rendimiento y contrastar sus resultados con
las restricciones temporales especificadas. En esta fase se hace en SDL* la
descripcin estructural del sistema.
En la fase de formalizacin se hace un refinamiento paralelo de la estructura descrita

en SDL* y de los casos de uso en PMSC que reflejen el refinamiento de SDL*. En esta
fase se incluyen los aspectos no funcionales en el diseo SDL*, como los necesarios
para realizar la divisin entre componentes fsicos y lgicos. Los anlisis de
rendimiento de la fase anterior pueden servir ahora para centrarse en aquellas partes
del sistema que presentan mayores problemas en esta faceta. Los diseos refinados,
tanto en PMSC como SDL*, tambin son analizados desde el punto de vista del
rendimiento.
En la fase de implementacin se llevan a cabo los estudios de verificacin y simulacin

para, por ejemplo, estudiar la presencia de bloqueos o la planificabilidad. Para ellos se
genera el cdigo de manera automtica, en C para la parte lgica y en VHDL para los
componentes fsicos, pudiendo escoger entre una biblioteca de componentes
predefinidos o crear componentes especficos para la aplicacin. En la fase de
pruebas se pueden generar bancos de pruebas de manera automtica a partir de la
especificacin de los aspectos funcionales. Estas pruebas suelen estar descritas en
TTCN Los autores han desarrollado una extensin de TTCN para tener en cuenta
aspectos temporales especificados en PMSC.
La metodologa esta soportada por un conjunto de herramientas automticas que

tienen como datos de entrada la descripcin de la arquitectura del sistema y de su
funcionamiento dinmico en SDL* y PMSC, respectivamente, y que, en diferentes
pasos, y teniendo en cuenta informacin adicional de las bibliotecas de componentes
lgicos y fsicos, acaba haciendo una optimizacin del sistema, que es otra descripcin
SDL* del sistema que cumple las restricciones especificadas.
55
Metodologas basadas en UML: ROPES

La metodologa ROPES (Rapid Object Oriented Prototyping for Embedded
Systems) hace uso de UML para crear los modelos de las diferentes fases del
desarrollo en que se divide: anlisis, diseo, traduccin y pruebas. ROPES sigue un
ciclo de vida iterativo y fomenta la creacin temprana de prototipos para verificar la
calidad del sistema. La fase de anlisis se compone de tres subfases. La primera es
la fase de anlisis de requisitos, en la que se establecen los objetivos que ha de
cumplir el programa. En esta fase se han de identificar los casos de uso y los actores y
eventos externos, ya que el sistema se ve an como una caja negra. Si los casos de
uso son muy complejos, se descomponen y se relacionan entre s.
Tambin tienen que identificarse las restricciones, como las
interfaces o los parmetros de rendimiento, entre los que se
incluyen los requisitos de tiempo real de los eventos identificados. Para
representar los casos de uso se usan inicialmente diagramas de casos de uso, en los
que se incluyen los actores y las tareas que llevan a cabo. Si es necesario representar
la dinmica de estos casos de uso se emplean diagramas de secuencia y de estados.
La siguiente subfase en aquellos sistemas cuya dimensin lo justifique es el anlisis
de sistema, donde se establece qu partes del sistema sern implementadas mediante
dispositivos fsicos y cules sern programadas. En la fase del anlisis de objetos se
identifican los objetos del sistema y las clases que los contienen.
Se relacionan entre s, se identifican sus operaciones, se define el funcionamiento
dinmico y se traducen los requisitos temporales de los eventos externos en requisitos
temporales sobre los objetos que toman parte en la respuesta al evento. En esta fase
se usan fundamentalmente diagramas de clases y objetos. Para el anlisis del
funcionamiento dinmico de los objetos se usan diagramas de estados asociados a las
clases y se definen escenarios mediante diversos diagramas, como diagramas
temporales, de secuencias o de actividades. En la fase de diseo, se ha de escoger
una solucin que implemente de manera eficiente, y cumpliendo las restricciones
impuestas, el modelo que resulta de la fase de anlisis. En esta fase emerge de
manera explcita el modelo de concurrencia, ya que se distinguen los objetos activos y
los pasivos. Tambin se elige la poltica de planificacin y de asignacin de
prioridades. Se asignan las clases y objetos a los componentes, en especial cuando se
trata con sistemas distribuidos. Se implementan las relaciones y las mquinas de
estados.
56
En la metodologa se divide el diseo en tres fases: estructural, mecnico y detallado.

En cada una de ellas las actividades que se llevan a cabo son cada vez de mayor nivel
de detalle. Tras el diseo se efecta la traduccin del modelo UML a cdigo fuente. Y,
con ayuda de un compilador, ste se traduce a cdigo ejecutable. La traduccin de
UML a cdigo fuente puede ser llevada a cabo en parte por herramientas automticas,
pero el programador ha de incluir todava gran parte del cdigo manualmente. Se
incluyen pruebas de caja blanca, que pueden ser incrementales, en las que se van
incluyendo mdulos en el sistema, o de validacin del sistema completo.
Herramientas automticas de diseo

Diversas herramientas comerciales implementan estas
metodologas, o al menos dan soporte a parte de ellas.
Una de las primeras herramientas de modelado basado
en objetos es la posibilidad de generacin automtica
de cdigo fue ObjectTime Developer, de la empresa ObjectTime. ObjectTime
Developer se basa en la metodologa ROOM. Tras la aparicin y popularizacin de
UML, ObjectTime Developer y ROOM se han fundido con Rational Rose y UML, dando
lugar, respectivamente, a Rational Rose Real-Time y UML-RT, que usa los
mecanismos de extensin de UML para modelar los conceptos de ROOM. Como se
mencion al hablar de ROOM, el concepto fundamental es un tipo de objeto activo, las
capsulas, que se comunican mediante mecanismos concretos, los puertos, y cuyo
funcionamiento viene definido por mquinas de estados. Rational-Rose Real-Time
incorpora la generacin de cdigo de ObjectTime Developer, en la que cada objeto
activo tiene su propia hebra de ejecucin, que acta concurrentemente con las otras
hebras, y tiene su propia cola de eventos.
Rhapsody, de i-Logix, tambin ofrece todo el ciclo de vida de UML, del anlisis de
requisitos a la generacin parcial de cdigo pasando por la especificacin de objetos.
Sin embargo, no ofrecen herramientas de anlisis de propiedades de tiempo real
estricto, como planificacin, ni para la validacin de sistemas. Hay otras herramientas
basadas en UML y SDL. Por ejemplo, Tau, de Telelogic, usa UML en el diseo de
objetos y MSC para expresar el funcionamiento dinmico del sistema y SDL para la
fase de diseo. Incluye traduccin automtica entre las mquinas de estados de UML
y los diagramas de SDL. Ofrece generacin automtica de cdigo y herramientas de
simulacin y validacin. Todas estas herramientas carecen de mecanismos para el
anlisis de propiedades de tiempo real o de base formal para la verificacin.
57
Una
Semntica
TEMA 3
Acciones
para MML
de
Competencia:
Explicar la importancia de la semntica de
acciones para MML.
58
Tema 03: Una Semntica de Acciones para

MML
LOS FUNDAMENTOS DEL MODELO MML
MML es un lenguaje de metamodelado pensado para reconstruir el ncleo de UML de
tal manera que se pueda definir de una manera mucho ms simple y que pueda ser
extendido y especializado para diferentes tipos de sistemas. Entre otros conceptos
bsicos, MML establece dos distinciones ortogonales. La primera es una
correspondencia entre los conceptos del modelo (la sintaxis abstracta) y las instancias
(el dominio semntico). La segunda es la distincin entre los conceptos de modelado y
la sintaxis concreta, y se aplica tanto a conceptos del modelo como a las instancias.
La sintaxis es la forma en que estos elementos se concretan.
Los conceptos del modelo y las instancias estn relacionados a travs de un paquete
semntico que establece la relacin de satisfaccin entre los modelos y las instancias
vlidas. Entre los conceptos de modelado y la sintaxis concreta se establece una
relacin similar como se muestra en la Figura 3.1.
Figura 3.1. El mtodo MML.

Estas distinciones se describen en trminos de un patrn de definicin del lenguaje,
ver Figura 3.1. Cada componente del patrn es un paquete. Como en UML, un
paquete es un contenedor de clases u otros paquetes.
59
Adems, los paquetes en MML se pueden especializar. ste es el mecanismo clave

por el que se generan definiciones extensibles del lenguaje, y es similar al mecanismo
de extensin de paquetes definido en Catalysis. Aqu, la especializacin de paquetes
se indica colocando una flecha de especializacin de UML entre paquetes. El paquete
hijo especializa (y, por tanto, contiene) todo el contenido del paquete padre.
Otro componente importante de MML es su paquete core, que define los conceptos
de modelado bsicos usados en MML: paquetes, clases y atributos. El paquete actual
de conceptos del modelo de MML no proporciona un modelo dinmico del
funcionamiento. As, en las siguientes secciones se describe un propuesta para la
semntica de las acciones en MML, que se basa en una extensin del paquete core
de MML.
Principios arquitectnicos
Dos han sido los objetivos principales de la definicin de
la semntica de acciones. El primero, incluir la
semntica de acciones como el ncleo dinmico de
MML. MML se centr originariamente en el modelado
esttico, por lo que una extensin natural es aadir
caractersticas dinmicas. Esto implica la definicin de vistas de modelo y de
instancias y la separacin que puede capturar tanto la nocin de acciones como los
conceptos y funcionamiento en trminos de cambios en el estado de las instancias.
El segundo objetivo es hacer uso de la simplicidad de

MML y sus modelos de semnticas como base para
explorar la definicin de acciones en un lenguaje del
estilo de UML. Obviamente, esto es un primer hito para
trabajos posteriores para incorporar modelos similares en
UML (trabajo que actualmente se est haciendo como parte del proceso de envo de
propuestas para UML 2.0). Finalmente, para conseguir el objetivo de la simplicidad,
nos hemos centrado en la definicin de un subconjunto de las acciones que se van a
usar en la semntica de acciones. Estas acciones (WriteVariable, etc.) forman un
ncleo de acciones primitivas que todos los lenguajes de acciones deberan incluir.
60
Estas acciones son primitivas en el sentido de que la definicin

de acciones adicionales podra ser potencialmente descrita en
trminos de estas primitivas, facilitando as una estrategia de
definicin ms estructurada en niveles. Una ventaja adicional
de esto es que una herramienta que pueda ejecutar las
acciones primitivas puede actuar potencialmente como motor de ejecucin sobre el
que se pudieran traducir las definiciones de un lenguaje ms rico.
MML est pensado para ser extendido de manera consistente, por tanto la definicin
de las acciones se har en otro paquete en MML, siguiendo la estructura del resto de
paquetes, es decir, el paquete debera estar compuesto de paquetes para el modelo,
las instancias y la semntica, con los paquetes de modelo y de instancias subdivididos
a su vez en paquetes para los conceptos, la sintaxis concreta y la correspondencia
entre conceptos y sintaxis.
Ncleo dinmico
El ncleo dinmico (Dynamic Core) intenta modelar la evolucin de los valores de los
elementos del sistema a lo largo del tiempo, en contraste con la vista del modelo
esttico que considera las instancias unidas a un nico valor. La estrategia escogida
para definir el modelo dinmico considera que los elementos mutables, los objetos,
evolucionan a travs de diferentes estados a lo largo de la vida del sistema segn
cambian sus valores las acciones que se ejecutan sobre ellos. Estos estados
contienen todos los valores del elemento en un instante dado. El elemento asociado a
ese estado se identifica por medio de un atributo, la identidad (identity), que es nica
en el sistema para ese elemento. Es decir, dos estados se refieren al mismo elemento
si y solo si tienen la misma identidad.
Esta relacin entre los sucesivos estados de un

elemento tambin se muestra por medio de la
asociacin next, que significa que un estado dado es el siguiente estado de un
elemento sobre el que se ha ejecutado una accin. Los conceptos del modelo y la
semntica siguen siendo iguales que en el ncleo esttico y es el paquete de los
conceptos de instancias el que cambia. Cada instancia de la metaclase object
representa un estado de un elemento mutable.
61
El nuevo paquete para los conceptos de instancias del ncleo dinmico se muestra en
la Figura 3.2.
Figura
3.2.
Conceptos
de
instancias
del
ncleo
dinmico
(paquete
dynamiccore.instances.concepts).
Acciones
En la definicin de UML, OCL es un lenguaje formal para expresar restricciones sin
efectos laterales. La evaluacin de estas restricciones no cambia ningn valor del
sistema. MML tiene su propio lenguaje de restricciones basadas en OCL con unos
pocos cambios semnticos. Este lenguaje proporciona todas las expresiones bsicas
del lenguaje de OCL. El concepto actual e Expresin en MML cubre las expresiones
bsicas de OCL.
stas incluyen expresiones lgicas (and, not, equals, includes), referencias a slots,
variables e iteradores sobre tipos contenedores (sequences, sets y bags). Sin
embargo, no define otras expresiones, como las aritmticas. Los mtodos de MML se
usan para definir procedimientos computacionales. Los mtodos no tienen efectos
laterales y simplemente sirven para evaluar un conjunto de parmetros contra una
expresin OCL para obtener un resultado. Se puede definir un nuevo mtodo
simplemente cambiando la expresin.
62
Las acciones representarn los procedimientos computacionales que cambian el

estado de un elemento del sistema. Las acciones no tendrn una expresin que
especifique lo que hace la accin, sino que definirn las nuevas clases que
especialicen el concepto de accin bsica. Su funcionamiento particular se describir
por medio de reglas de correccin. Con esta estrategia, se tiene un conjunto de
acciones bsicas sobre las que se van a construir las nuevas acciones que sean
necesarias.
En este trabajo slo se va a definir un conjunto bsico de acciones que resulte

suficiente para permitir fcilmente la definicin de las otras acciones sobre ellas. Se
distinguirn las acciones primitivas de las compuestas. Las acciones primitivas son
suficientemente simples y no necesitan definirse en trminos de otros elementos ms
simples. Las acciones compuestas se definen como una composicin de acciones
ms simples, tanto primitivas como compuestas.
Conceptos de modelo
La Figura 3.3 muestra la definicin de la clase abstracta Action. La clase Action
especializa la clase Classifier. Cada accin tiene un conjunto de parmetros de
entrada. Como el orden de los parmetros es significativo, estas asociaciones estn
ordenadas. Los parmetros de entrada representan los valores que la accin necesita
para ejecutarse. Estos valores pueden incluir el objeto sobre el que se aplica la
accin. Todas las acciones son ejecutadas por un objeto, que puede ser llamado el
mbito (scope) de la accin. La asociacin entre las clases Action y Class muestra la
clase a la que pertenece el objeto mbito de la accin.
Figura
3.3.
Paquete
actions.model.concepts
63
Mtodos
El mtodo allActions() devuelve el conjunto de todas las acciones de una clase,
incluyendo la de sus progenitores. allActions() escoge solo una accin en el caso de
que haya mltiples padres con acciones con el mismo nombre. sta es tal vez las
estrategias simples para tratar el tema de las colisiones en la herencia mltiple,
aunque se podra mejorar definiendo una regla de mezcla si fuera necesario.
context uml.staticCore.model.concepts.Class
allActions() : Set(Action)
parents iterate(p; s = actions | s union (p.allActions( )
reject (c | actions exists(c | c.name = c.name)))
El mtodo allSubActions() devuelve todas las subacciones de una accin, anidadas a

cualquier profundidad.
context uml.actions.model.concepts.Action
allSubActions() : Set(Actiacotionns)
self.subactions union(self.subactions.allSubActions() asSet())
Conceptos de instancias
La clase Execution est definida en el paquete de conceptos de instancias mostrado
en la Figura 2.4. Una instancia de la clase Execution representa una ejecucin real de
una accin. Una instancia de Execution tiene una secuencia de valores de entrada
sobre los que ejecutarse. Una entrada distinguida es el estado del elemento que se
modifica en la ejecucin. Una ejecucin tambin tiene valores de salida. Entre ellos
est el nuevo estado del elemento modificado.
Una instancia de Execution tambin tiene una asociacin con la instancia de la clase
Object que la ejecuta, la asociacin self.
Figura
3.4.
Paquete
actions.instance.concepts
64
Aunque no hay nocin de tiempo ni, por tanto, de ordenacin temporal en el modelo
dinmico, hay una relacin causal entre las ejecuciones en el sistema. Para una
ejecucin puede haber una ejecucin previa (previous) y otra siguiente (next).
Tambin hay una relacin causal entre la ejecucin de la accin y los valores usados
en ella. Como una accin no puede ejecutarse hasta que todos los valores de entrada
hayan sido calculados, los valores producidos despus de la ejecucin de la accin no
pueden ser usados como parmetros de entrada.
La semntica de este paquete se muestra en la Figura 3.5.

Figura
3.5:
Paquete
actions.model.semantics.
Mtodos
1. El mtodo allSubExecutions() devuelve todas las subejecuciones de una ejecucin,
anidadas a cualquier profundidad.
context uml.actions.instance.concepts.Execution
allSubExecutions() : Set(Execution)
self.subexecution
union(self.subexections.allSubExecutions() asSet())
Reglas de correccin
2. Una salida de una ejecucin no puede ser usada como entrada de esa ejecucin.
context uml.actions.instance.concepts.Execution inv:
inputs forall (i| outputs forall(o| i <>o))
65
Acciones
Primitivas
TEMA 4
Competencia:
Descomponer acciones complejas en acciones
primitivas o ms simples.
66
Tema 04: Acciones Primitivas
Una accin primitiva es una accin que no se descompone en acciones ms simples.

La caracterstica comn de las acciones primitivas es que no tienen subacciones.
PrimitiveAction es una clase abstracta que se especializa en tres sub-clases
diferentes: la accin nula (NullAction), la creacin de un objeto (CreateObjectAction) y
la modificacin del valor del atributo de un objeto (WriteSlotAction). Las Figuras 4.1,
4.2 y 4.3 muestran, respectivamente, los paquetes de conceptos del modelo,
conceptos de instancias y semntica.
Mtodos
1. El mtodo subActions() devuelve el conjunto de subacciones inmediatas de una
accin. Para las acciones primitivas este conjunto es vaco.
context uml.actions.model.concepts.PrimitiveAction
subActions( ) : Set(Action) Set{ }
2. El mtodo subExecutions() devuelve el conjunto de subejecuciones inmediatas de

esa ejecucin. Para las ejecuciones de acciones simples se conjunto es vaco.
context uml.actions.instance.concepts.PrimitiveExecution
subExecutions( ) : Set(Execution) Set{ }
Figura 4.1: Paquete de conceptos del

modelo de las acciones primitivas
(primitiveactions.model.concepts).
67
Accin nula
La accin nula, como su nombre indica, no hace cambios en el sistema. Se incluye
porque las acciones compuestas se han definido para tener al menos una subaccin.
Reglas de correccin
1.
Una accin nula no tiene parmetros de entrada.

context uml.primitiveActions.model.concepts.NullAction inv:
self.inputs->size = 0
2.
Una instancia de NullExecution no tiene ni parmetros de entrada ni valores de

salida.
context uml.primitiveActions.instance.concepts.NullExecution inv:
self.inputssize = 0 and self.outputssize = 0
Figura 4.2: Paquete de los conceptos de instancia de las acciones primitivas

(primitiveactions.instance.concepts).
68
Figura
4.3:
Paquete
de
la
semntica
de
las
acciones
primitivas
(primitiveactions.semantics).
Accin de crear un objeto

Una accin de la clase CreateObjectAction
aade un nuevo objeto al sistema. En el lado
de
los
conceptos
de
modelo,
la
clase
CreateObjectAction tiene como entrada la

clase del objeto que se va a crear. Esta nica
entrada se ha renombrado, por claridad, como target. La ejecucin de una accin de
creacin de un objeto tiene un resultado, el objeto creado. Esta accin no hace nada
ms, ni siquiera inicializa los valores de los atributos del nuevo objeto. Para asegurar
que el objeto es nuevo, ste no puede tener un estado previo.
Reglas de correccin
1. Una instancia de CreateObjectAction tiene una nica entrada.
context uml.primitiveActions.model.concepts.CreateObjectAction inv:
2. La entrada de una instancia de CreateObjectAction es la clase del objeto creado.
context uml.primitiveActions.model.concepts.CreateObjectAction inv:
self.inputs.oclIsTypeOf(Class)
3. Una instancia de CreateObjectExecution no tiene parmetros de entrada y tiene un
valor de salida.
context uml.primitiveActions.instance.concepts.CreateObjectExecution
inv:
self.inputs size = 0 and self.outputs size = 1
69
4. La salida de una instancia de CreateObjectExecution es un objeto.

inv:
self.outputs at(1).IsTypeOf(Object)
5. La salida de una instancia de CreateObjectExecution es un objeto de la clase
correspondiente a la accin.
inv:
self.outputs at(1).of = self.of.inputs at(1)
6. La salida de una instancia de CreateObjectExecution es un objeto nuevo.
inv:
self.outputs at(1).previous size() = 0
Accin de escritura de un atributo

Una accin de la clase WriteSlotAction cambia el
valor de un atributo de un objeto. Los valores del
resto de atributos permanecen inalterados. Cada
accin tiene dos entradas distinguidas: target, que
muestra la clase del objeto a la que pertenece el
atributo y attribute, que representa el atributo que
se va a modificar. ste debe ser un atributo valido de esa clase.
La ejecucin de una accin de esta clase tambin tiene dos

entradas distinguidas: target y slot, que representan el
objeto y atributos concretos que se modifican. El atributo
debe ser un atributo valido de ese objeto. El nuevo valor del
atributo es la otra entrada de la ejecucin. Este valor debe
coincidir con el valor del atributo en el estado del objeto
despus de la ejecucin.
70
Reglas de correccin
1. Una instancia de la clase WriteSlotAction tiene tres parmetros de entrada.
context uml.primitiveActions.model.concepts.WriteSlotAction inv:
self.inputs->size = 3
2. target es una de las entradas de las instancias de WriteSlotAction.
self.inputs->includes(self.target)
3. attribute es una de las entradas de las instancias de

WriteSlotAction.
self.inputs->includes(self.attribute)
4. attribute debe ser un atributo vlido de la clase.
self.target.attributes->includes(self.attribute)
5. El tipo del atributo modificado debe ser compatible con el tipo del valor de entrada.
self.inputs->at(3).oclIsKindOf(self.attribute.type)
6. Una instancia de WriteSlotExecution tiene tres parmetros de entrada y un

parmetro de salida.
context uml.primitiveActions.instance.concepts.WriteSlotExecution inv:
self.inputs->size = 3 and self.outputs->size = 1
7. El objeto destino es una de las entradas de las instancias de WriteSlotExecution.
self.inputs->includes(self.target)
8. El atributo que se va a actualizar es una de las entradas de las instancias de
WriteSlotExecution.
context uml.primitiveActions.instance.concepts.WriteSlotExecution
inv:
self.inputs->includes(self.slot)
71
9. El objeto destino debe ser de la clase con la que est asociada la correspondiente
accin.
self.target.of = self.of.target
10. El atributo del objeto debe coincidir con el atributo de la clase asociada a la
correspondiente accin.
self.slot.of = self.of.attribute
11. El atributo debe ser un atributo vlido del objeto.

context uml.primitiveActions.instance.concepts.WriteSlotExecution
inv:
self.target->slots->includes(self.slot)
12. El tipo del valor de entrada debe ser compatible con el tipo del atributo.
self.inputs->at(3).oclIsKindOf(self.slot.type)
13. El objeto de salida es el siguiente estado del objeto de entrada.
context uml.actions.instance.concepts.WriteSlotExecution
inv:
self.inputs->at(1).next = self.outputs->at(1)
14. El
valor
del
atributo
actualizado
tras
una
WriteSlotExecution es el valor de entrada.

context primitiveActions.instance.concepts.WriteSlotExecution inv:
ouputs->at(1).slots->forall(s |
s = self.slot implies s.value = inputs->at(3))
15. El resto de los atributos del objeto destino permanecen inalterados.
context uml.actions.instance.concepts.WriteSlotExecution inv:
self.outputs->at(1)->forall(s |
s <>self.slot implies s.value = self.target.slot.value).
72
CONCEPTOS DE LA METODOLOGA ORIENTADA A OBJETOS

http://profesores.fi-b.unam.mx/carlos/aydoo/conceptos_oo.html
LENGUAJE DE MODELAMIENTO UNIFICADO (UML)

http://www.usmp.edu.pe/publicaciones/boletin/fia/info21/uml.htm
1. En un documento en Word realice un organigrama sobre las

principales acciones primitivas.
Envalo a travs de "Acciones Primitivas".
2. En un documento en Word describa y elabore un comentario

sobre las ventajas de las principales metodologas basadas
en SDL y en UML.
Envalo a travs de "SDL & UML".
73
Autoevaluacin
1) Los mtodos de diseos se pueden dividir en:

a.
b.
c.
d.
e.
Informales, estructurados y formales.

Informales, orientados y formales.
Informales, desorientados y orientados.
Enfocados, desenfocados y estructurados.
Reales, imaginarios y supuestos.
2) ROOM (Real-Time Object Oriented Modeling) es una metodologa:

a.
b.
c.
d.
e.
De desarrollo orientado a sistemas.

De desarrollo orientado a sujetos.
De desarrollo orientada a objetos
De desarrollo orientado a software.
De desarrollo orientado a telfonos mviles.
3) Los implinks son:

a.
b.
c.
d.
e.
Comando UML.
Sentencias SDL.
Recursos UML.
Enlaces UML.
Herramientas SOMT.
4) MML es un lenguaje de:

a. Metamodelado.
b. Metodologas.
c. Modificaciones.
d. Metaenlaces.
e. Muestras de estados.
5) El mtodo allActions() devuelve el conjunto de todas las acciones de:

a. Progenitores.
b. Una clase.
c. Alteraciones.
d. Subacciones
e. Metaelementos.
74
6) Una accin primitiva es una accin que:

a. No se compone con nuevas estrategias.
b. No se descompone en partculas pequeas.
c. No se descompone en acciones ms simples.
d. No comparte las metodologas y particularidades.
e. No se interpreta mediante codificaciones.
7) Una accin nula:

a. No tiene subacciones
b. No altera cdigos en el sistema.
c. No tiene funcionalidades en el sistema.
d. No hace cambios en el sistema.
e. No distingue los modelos de sistemas.
8) El
ncleo
dinmico
(Dynamic
Core)
intenta
_____________________________, en contraste con la vista del modelo
esttico que considera las instancias unidas a un nico valor.
a. Corregir la evolucin de los valores de los elementos del sistema a lo largo del
tiempo.
b. Verificar la evolucin de los valores de los elementos del sistema a lo largo del
tiempo.
c. Configurar la evolucin de los valores de los elementos del sistema a lo largo
del tiempo.
d. Restaurar la evolucin de los valores de los elementos del sistema a lo largo
del tiempo.
e. Modelar la evolucin de los valores de los elementos del sistema a lo largo del
tiempo.
9) Hay dos modelos de concurrencia en los diseos orientados a objetos:

a. El interno y el externo.
b. El implcito y el explcito.
c. El blando y el duro.
d. El informal y formal.
e. El SDL y UML.
10) La metodologa SOMT se divide habitualmente en:
a.
b.
c.
d.
e.
Seis fases.
Cuatro fases.
Tres fases.
Cinco fases.
Dos fases.
75
Resumen
UNIDAD DE APRENDIZAJE II:
Los mtodos de diseos se pueden dividir en informales, estructurados y formales.

Hay dos modelos de concurrencia en los diseos orientados a objetos, el implcito y
el explcito. ROOM una metodologa de desarrollo orientada a objetos. La
metodologa SOMT se divide en las cinco fases habituales. Una de las herramientas
que proporciona la metodologa SOMT para guiar el paso entre los diferentes
modelos de las sucesivas fases del desarrollo son los implinks.
La metodologa ROPES (Rapid Object Oriented Prototyping for Embedded Systems)

hace uso de UML para crear los modelos de las diferentes fases del desarrollo en
que se divide: anlisis, diseo, traduccin y pruebas. MML es un lenguaje de
metamodelado pensado para reconstruir el ncleo de UML. El ncleo dinmico
intenta modelar la evolucin de los valores de los elementos del sistema a lo largo del
tiempo.
MML es un lenguaje de metamodelado pensado para reconstruir el ncleo de UML

de tal manera que se pueda definir de una manera mucho ms simple y que pueda
ser extendido y especializado para diferentes tipos de sistemas. Entre otros
conceptos bsicos, MML establece dos distinciones ortogonales. La primera es una
correspondencia entre los conceptos del modelo (la sintaxis abstracta) y las
instancias (el dominio semntico).
La caracterstica comn de las acciones primitivas es que no tienen subacciones.

PrimitiveAction es una clase abstracta que se especializa en tres sub-clases
diferentes: la accin nula (NullAction), la creacin de un objeto (CreateObjectAction)
y la modificacin del valor del atributo de un objeto (WriteSlotAction). Las Figuras
4.1, 4.2 y 4.3 muestran, respectivamente, los paquetes de conceptos del modelo,
conceptos de instancias y semntica.
76
77
Introduccin
Las mquinas de estados se utilizan a menudo para resolver ciertos tipos de
problemas orientados al control, en los cuales el flujo de control pueda dibujarse
como un movimiento a travs de un conjunto de diferentes estados. Hay una serie
de definiciones diferentes y de descripciones de tipo prctico de una mquina de
estados; a un nivel terico es como un autmata que responde a un estmulo
concreto mediante un cambio de estado.
b) Competencia:
Comprende la importancia y aplicacin del modelado de tiempo real de las
mquinas de estados.
c) Capacidades:
1. Analiza las diversas teoras y aplicaciones de la semntica de las mquinas de
estados.
2. Explica la funcionalidad de las mquinas de estados con estados concurrentes
en los sistemas de tiempo real.
3. Reconoce el enfoque del tiempo real en las mquinas de estados y sus
particularidades.
4. Aplica los mecanismos de expresin del tiempo en las mquinas de estados de
UML.
d) Actitudes:
Muestra inters por el anlisis de los modelos de tiempo real de las mquinas.
Promueve la adecuada aplicacin de las distintas mquinas de estados.

La Unidad de Aprendizaje 03: Modelado de Tiempo Real de las Mquinas de
Estados, comprende el desarrollo de los siguientes temas:
TEMA 01: Semntica de las Mquinas de Estados.
TEMA 02: La Mquina de Estados con Estados Concurrentes.
TEMA 03: El Tiempo Real en las Mquinas de Estados.
TEMA 04: Expresin del Tiempo en las Mquinas de Estados.
78
Semntica
de las
TEMA 1
Mquinas
de Estados
Competencia:
Analizar las diversas teoras y aplicaciones
de la semntica de las mquinas de estados.
79
Tema 01: Semntica de las Mquinas de

Estados
Como se discuti anteriormente, la definicin oficial de UML no
diferencia claramente entre la sintaxis abstracta, o conceptos de
modelado, y el dominio semntico, o conceptos de instancia. Por
ejemplo, en la definicin de la semntica se dice: El trmino
evento se usa para referirse al tipo y no a la instancia del tipo. Sin
embargo, en alguna ocasin, donde el significado se pueda deducir claramente del
contexto, el trmino tambin se usar para referirse a una instancia del evento.
Esta falta de distincin tambin afecta al resto de los conceptos definidos en el

paquete de las mquinas de estados y hace que conceptos ms relacionados con la
vista esttica estn mezclados con otros ms cercanos a la vista dinmica. Por
ejemplo, aunque se habla ampliamente sobre el concepto de transicin de un estado a
otro, no hay ningn concepto que represente el procesamiento de una instancia de un
evento, ni hay reglas de correccin OCL relativas a las transiciones.
En este tema se propone una semntica para una versin simplificada de

las mquinas de estados de UML. Esto significa que hay
caractersticas, como las actividades, los estados de historia
o la lista de eventos postergados, que no son
contemplados. Finalmente, a partir de las tareas, se
crean las estructuras de datos que se van a usar en el
programa, bien basndose en tipos abstractos de datos
o en objetos. La caracterstica diferenciadora es que en
estas
metodologas se tiene en cuenta la concurrencia antes que el modelo de datos.
80
LA MQUINA DE ESTADOS PLANA

El modelo ms simple de una mquina de estados consta, por un lado, de un conjunto
de situaciones estables, denominadas estados, en uno de los cules la mquina
siempre permanece. En este modelo, los estados son indivisibles y no se pueden
desarrollar internamente. Debido a esta caracterstica, denominaremos a estas
mquinas como mquinas de estados planas. Por otro lado, la mquina de estados
comprende un conjunto de transiciones, que son enlaces entre los estados descritos
previamente. Cada transicin tiene un estado origen y un estado destino. La mquina
puede cambiar de estado a partir de su estado actual. No obstante, el cambio no
puede cambiar a cualquier otro estado, sino que para cambiar de un estado a otro
debe haber una transicin que tenga como estado origen al primer estado y como
estado final al segundo.
Esta definicin permite establecer varios paralelismos entre las instancias de las
mquinas de estados y los objetos. Este paralelismo se refleja principalmente en el
funcionamiento dinmico del sistema. Una instancia de una mquina de estados es
una entidad que, al igual que un objeto, pasa por diferentes estados segn se van
ejecutando acciones sobre el sistema. En el caso de las mquinas de estados, cada
uno de estos estados por los que va pasando se denomina el estado activo. Tambin
tiene sentido establecer, como se hace en la definicin de la infraestructura de UML
2.0 para los objetos, una identidad para cada instancia de una mquina de estados.
Esta identidad permanece fija durante la vida del sistema y acta como nexo entre los
sucesivos estados. Cada uno de estos estados debe pertenecer a un Snapshot, al
igual que lo hacen las instancias de la clase Object.
Este paralelismo, no obstante, no es completo. Un objeto tiene

caractersticas estructurales, los slots, que tienen asociados a su
vez valores. Cada objeto tiene que estar asociado con una instancia,
y slo una, de cada uno de sus slots. Por su lado, cada estado
activo de una instancia de una mquina de estados no tiene por qu
estar asociado con una instancia de los estados asociados a la
mquina de estados, sino slo con un subconjunto de ellos. En el caso de la mquina
de estados plana solo uno de los estados estar activo para cada estado de la
instancia de la mquina de estados.
81
Concepto de modelado
En la Figura 1.1 se muestra el diagrama de clases de los conceptos de modelado de
las mquinas de estados. En l vemos cmo una mquina de estados tiene asociados
un conjunto de estados y un conjunto de transiciones.
Figura 1.1: Conceptos de modelado de las mquinas de estados planas.
En esta primera aproximacin todos los estados son simples, por lo que no se
establece una relacin de contencin entre ellos.
Las transiciones, que definen los posibles cambios de estado

en la mquina de estados, parten de un estado origen,
source, y llegan a un estado destino, target. En las maquinas
hay dos estados distinguidos, el initial, que es el que se activa cuando empieza la vida
de la mquina, y el final, que es un estado tal que cuando se transita a l, se acaba la
actividad de la mquina. El estado final no puede, por tanto, tener ninguna transicin
de salida. En la definicin de las mquinas de estados de UML, el estado inicial tiene
una nica transicin de salida, que se ejecuta cuando empieza la vida de la mquina.
82
La mquina de estados con estados compuestos

David Harel argumenta que una mquina de estados es un modelo
cuya utilidad para el diseo puede mejorarse si el concepto de estado
se amplia de tal forma que cada estado puede, a su vez, dividirse en
otra mquina de manera jerrquica. Entre las ventajas estn un mejor
aprovechamiento del rea de dibujo y diseos ms cercanos al
sistema modelado. La desventaja de ese modelo es que su semntica se complica
porque aumentan las posibles relaciones entre los estados y las transiciones.
En
esta
considerar
seccin
un
vamos
modelo
a
ms
completo que el de la seccin

anterior en el que los estados
pueden
no
ser
simples,
sino
tambin compuestos. Los estados

compuestos
(CompositeState)
estn divididos jerrquicamente en subestados, lo que permite que el funcionamiento

de la mquina de estados pueda definirse en un nivel mayor de detalle. sta es una
relacin de composicin, por lo que un estado puede estar contenido a lo sumo en un
estado compuesto. Esta relacin tiene forma de rbol general donde el estado
principal es la raz. Dentro de los subestados hay uno distinguido, el estado inicial,
que es el que se activa cuando se entra en el superestado.
La clase de los estados simples (SimpleState) representa aquellos estados que no

tienen estructura interna, es decir, que no tienen subestados. Estos son los estados
que hemos considerado en la seccin anterior. Las transiciones pueden partir de un
estado anidado y llegar a otro estado anidado. Se considera que al ejecutar una
transicin de este tipo se sale de todos los estados que son ancestros del estado
origen hasta el estado ancestro comn con el estado destino ms profundo, y se entra
en todos los estados desde el mencionado ancestro comn hasta el estado destino.
83
Conceptos de modelado de mquinas de estado compuestos

En la Figura 1.2 se muestra el diagrama de clases de los conceptos de modelado para
las mquinas de estados con estados compuestos. Una mquina de estados se
compone de sus estados y sus transiciones. Los estados compuestos pueden
contener a su vez otros estados.
Figura 1.2: Conceptos de modelado de las mquinas de estados con estados

compuestos.
Dominio semntico
En la Figura 1.3 se muestra el diagrama de clases
correspondiente al dominio semntico de las
mquinas de estados con estados compuestos.
Se define una instancia de una mquina de
estados como una especializacin de la clase
SnapshotElementInstance. El dominio semntico se ampla con dos nuevas clases
para las instancias estados simples y compuestos, SimpleStateInstance y
CompositeStateInstance, respectivamente.
84
Figura 1.3. Dominio semntica de las mquinas de estados compuestos.
Aplicacin semntica
En la semntica de este modelo se incluyen respecto al de la seccin anterior los
diferentes tipos de estados, compuestos y simples (Figura 1.4).
Figura 1.4: Aplicacin semntica de las mquinas de estados compuestos.
85
La Mquina
TEMA 2
de Estados
con Estados
Concurrentes
Competencia:
Explicar la funcionalidad de las mquinas
de estados con estados concurrentes en los
sistemas de tiempo real.
86
Tema 02: La Mquina de Estados con

Estados Concurrentes
En este tema hacemos una segunda ampliacin del modelo de las mquinas de
estados incluyendo un nuevo tipo de estado compuesto, los estados concurrentes. Los
que hemos considerado en la seccin anterior son los que se denominan
secuenciales. La diferencia entre ambas categoras radica en la forma en que pueden
ejecutarse los subestados contenidos. Cuando un estado secuencial est activo, slo
uno de sus subestados est activo. En cambio, cuando un estado concurrente est
activo, todos sus subestados lo estn tambin.
Los estados compuestos concurrentes se

dividen en lo que se denominan regiones. Las
regiones trabajan de manera concurrente.
Debe haber al menos dos regiones en un
estado concurrente
y, cuando el estado
concurrente est activo, todas las regiones

tambin lo estn. Las regiones tambin tienen
que ser a su vez estados compuestos.
Conceptos de modelado
En la Figura 2.1 se muestra el diagrama de clases de los
conceptos de modelado para las mquinas de estados con
estados concurrentes. La principal diferencia en este paquete
es que aparecen dos nuevas clases, ConcurrentState y
SequentialState, que especializan CompositeState.
87
Dominio semntico
En la Figura 2.2 se muestra el diagrama de clases correspondiente al dominio
semntico de las mquinas de estados con estados concurrentes.
En este paquete tambin aparecen dos nuevas clases, ConcurrentStateInstance y
SequentialStateInstance, que especializan la clase CompositeStateInstance. Otra
diferencia es que en el modelo anterior, en el que slo se consideraban los estados
compuestos, la cardinalidad de la relacin entre las clases CompositeStateInstance y
StateMachineStateInstance era en el extremo substates porque slo poda estar
activo un subestado del estado activo.
Figura 2.1: Conceptos de modelado de las mquinas de estados con estados

concurrentes.
88
Figura 2.2 Dominio semntico de las mquinas de estados con estados concurrentes.
Ahora hay que aadir reglas de correccin para diferenciar cuantos subestados
pueden estar activos en funcin de si el estado activo es secuencial o concurrente. Si
es secuencial slo habr un subestado activo, y si es concurrente habra uno por cada
uno de sus subestados (regiones).
Aplicacin semntica
En la semntica de este modelo se incluyen nuevas clases para los nuevos tipos de
estados, los secuenciales y los concurrentes (Figura 2.3).
La recepcin de un evento
En las secciones anteriores hemos ofrecido una visin esttica de las mquinas de
estados en las que se muestra un estado activo en el que permanece la mquina
hasta que transita a otro estado. El aspecto verdaderamente dinmico de las
mquinas de estados reside en cmo se cambia de un estado a otro cuando se
produce la ocurrencia de un evento y qu acciones se ejecutan como respuesta.
89
Figura 2.3. Aplicacin semntica de las mquinas de estados concurrentes
Figura 2.4. Mquina de estados con estados concurrentes
90
El Tiempo
Real en las
Mquinas de
Estados
TEMA 3
Competencia:
Reconocer el enfoque del tiempo real en las
mquinas de estados y sus particularidades.
91
Tema 03: El Tiempo Real en las Mquinas de

Estados
Perfil de Planificabilidad, Rendimiento y Especificacin del Tiempo
El Perfil UML de Planificabilidad, Rendimiento y Especificacin del Tiempo (UML
Profile for Schedulability, Performance, and Time Specification) pretende extender
UML para que se pueda usar para la especificacin y diseo de sistemas de tiempo
real en toda su extensin y diversidad. El grupo de trabajo que ha realizado
este perfil afirma que las extensiones presentes en UML son suficientes
para llevar a cabo la tarea. Los autores de este perfil han intentado
hacer un marco lo suficientemente amplio como para que cubra todas
las distintas caractersticas de los sistemas de tiempo real pero que, a la
vez, sea lo bastante flexible como para permitir futuras especializaciones.
Como indican los autores, no han pretendido desarrollar nuevas

tcnicas de anlisis, sino anotar los modelos UML de forma que
las tcnicas de anlisis, tanto las actuales como las que se puedan
desarrollar, puedan aprovecharse de las ventajas del modelado en
UML. Entre los principios que han guiado la construccin de este perfil se cita la
posibilidad de construir herramientas que, de manera automtica, construyan modelos
para distintos tipos de anlisis concretos a partir de un modelo dado. Estas
herramientas deberan poder leer el modelo, procesarlo y realimentar con sus
resultados el modelo original.
A la hora de establecer cmo se ha de usar el perfil, los autores diferencian tres

actores:
El modelador, que construye modelos y est interesado en analizarlos para

saber si cumplen los requisitos requeridos.
El proveedor de mtodos de anlisis de modelos, que define mtodos de

anlisis y herramientas para llevarlos a cabo.
El proveedor de infraestructura, que proporciona tecnologas como sistemas

operativos de tiempo real o bibliotecas de componentes de tiempo real.
92
De entre los posibles usos que los autores esperan para el perfil, los que estn
pensados para los modeladores son:
Sintetizar el modelo, que incluir los estereotipos y valores etiquetados

necesarios para llevar a cabo los anlisis necesarios.
Analizar el modelo, posiblemente desde varios puntos de vista y a diferentes

niveles de detalle. Para el anlisis se usaran las anotaciones aadidos al
modelo UML.
Implementar el sistema, que consiste en construir la aplicacin que ejecute el

modelo creado anteriormente.
Estructura
Debido a la gran diversidad de posibles sistemas de
tiempo
real,
hard
soft,
distribuidos
monoprocesadores, etc., es muy difcil establecer un

conjunto cannico de conceptos de modelado y dise
que comprenda todos los sistemas. Esta situacin se
agrava cuando se tienen en cuenta, adems, las tcnicas de anlisis. A la hora de
analizar un modelo, el analizador suele trabajar con una versin simplificada del
sistema, del que se eliminan aquellas caractersticas que no son relevantes para el
anlisis. Una de las cuestiones que complica esta simplificacin es el hecho de que es
bastante usual el que las entidades del modelo no se correspondan una a una con las
entidades que es necesario conocer para poder llevar a cabo el anlisis.
Por ejemplo, las unidades de concurrencia en las que se base el modelo, procesos o
hebras, pueden estar definidas slo de forma implcita u oculta en el modelo del
sistema. Otra dificultad aadida viene dada por el hecho de que sobre un mismo
modelo de un sistema se pueden hacer diferentes anlisis, cada uno de los cuales se
puede centrar en un aspecto concreto del sistema como, por ejemplo, su
planificabilidad o el consumo de memoria. Aspectos relevantes para un determinado
anlisis pueden no ser interesantes para otro. Para superar ese problema los autores
del perfil proporcionan un marco nico que comprende los elementos comunes de los
distintos mtodos de anlisis de sistemas de tiempo real. El
ncleo de este marco lo constituye la definicin de recursos de
todo tipo y de sus calidades de servicio. Esta definicin se hace
en el paquete de Modelado de Recursos Generales.
93
A partir de estas definiciones bsicas, para cada

mtodo de anlisis hay que definir los conceptos
particulares que se necesiten. Estos conceptos se
definirn como especializacin de los ya definidos en
los mdulos de recursos generales. No todos los
conceptos de dominio tienen un estereotipo o un valor etiquetado correspondiente,
porque algunos de esos conceptos son demasiado abstractos y nunca se van a usar
directamente en ningn modelo de anlisis, sino que algunos modelos usaran una
especializacin de ese concepto, y ser para el concepto especializado para el que se
defina el estereotipo o valor etiquetado correspondiente en UML.
Como ya se ha comentado anteriormente, los autores del perfil argumentan que los
mecanismos de extensin ofrecidos por UML, estereotipos y valores etiquetados, son
suficientes para la tarea encomendada. Ellos ven los estereotipos como un mecanismo
de especializacin de clases que permite aadir nuevos atributos a la clase
especializada. Sin embargo, este mecanismo de estereotipado no permite agregar
nuevas asociaciones en el metamodelo respecto a las que ya tena la clase
especializada.
Las nuevas asociaciones que establezcan los elementos

de modelo se pueden traducir de tres formas distintas:
Algunas de estas asociaciones se corresponden

exactamente con otra asociacin ya existente en
el metamodelo de UML.
Otras
asociaciones
se
corresponden
con
etiquetas asociadas con el estereotipo.
En unos pocos casos, una asociacin de dominio se representa mediante una

relacin del tipo taggedValue de los mecanismos de perfiles de UML.
Otro de los objetivos del perfil ha sido permitir ms especializaciones de modelos de

dominio concreto cuando hagan falta. Como aplicacin ejemplo del perfil, los autores
han desarrollado el subperfil de CORBA de tiempo real como especializacin del perfil
de anlisis de planificabilidad.
94
Modelado de recursos
La parte fundamental del perfil es el paquete en el que se definen los recursos. Han
intentado definir recursos suficientemente generales como para ser una base comn
suficiente para poder definir los dems recursos y conceptos propios de cada modelo
particular que se defina posteriormente. La cuantificacin de las restricciones que
afectan a los sistemas de tiempo real es uno de los aspectos fundamentales que se
tratan en el perfil y, por tanto, las caractersticas de calidad de servicio son una parte
integral de los recursos.
Estas caractersticas de calidad de servicio tienen sentido en un contexto en el que se

pueda indicar, adems de la calidad de servicio ofrecida por un recurso, la calidad de
servicio requerida por los elementos del sistema que actan como clientes de dicho
recurso. El anlisis consistir, en ese caso, en comparar ambas capacidades. En el
perfil han trabajado con lo que denominan dos vistas respecto a los recursos y los
clientes. En la primera forma, los recursos y los clientes se encuentran en el mismo
nivel de abstraccin, por lo que la relacin es entre iguales y se puede indicar
mediante una asociacin. La otra forma de uso de recursos es una interpretacin
jerarquizada, en la que el cliente est en un nivel y el recurso est en otro,
generalmente para modelar una situacin en la que el recurso implementa un servicio
ofrecido por el cliente.
Modelado del tiempo

El modelado del tiempo se trata de varias formas en el perfil. Por un lado, se modela el
tiempo como magnitud, para medir las restricciones. Slo se define el tiempo mtrico,
ya que los autores argumentan que, habitualmente, los sistemas de tiempo real se
ocupan de la cardinalidad del tiempo, como en el caso del cumplimiento de los plazos
temporales. Encuentran til distinguir entre tiempo fsico y tiempo virtual, o de
simulacin, que puede incrementarse de manera no montona. Un segundo aspecto
que se modela sobre el tiempo son los mecanismos que se ofrecen al sistema, por
ejemplo por parte de un sistema operativo de tiempo real, para tratar con l, como los
temporizadores y los relojes. Finalmente, tambin se hace referencia a los diferentes
patrones que son esenciales en la planificabilidad o los distintos anlisis, como la
periodicidad, o la definicin de plazos e intervalos temporales.
95
Modelado de la planificabilidad
El perfil se centra en la especificacin de sistemas de tiempo real duros, es decir,
aquellos en los que se han de cumplir todos los plazos, para lo que suele ser
necesario poder establecer un lmite superior en el tiempo de respuesta del sistema a
los diferentes eventos. El objetivo principal del perfil en este aspecto ha sido cmo
anotar el modelo para permitir diferentes modelos de planificabilidad, para determinar
si se cumplen o no los plazos temporales. Para evitar conflictos debidos a la
nomenclatura, se han decidido por un marco comn a todos los posibles anlisis de
planificabilidad en los que, en un principio, han incluido los ms usados actualmente,
como Rate Monotonic Analysis (RMA), Deadline Monotonic Analysis (DMA) y Earliest
Deadline First (EDF). Sin embargo, los autores defienden que sus anotaciones son
suficientemente flexibles como para poder usar otros mtodos e, incluso, para poder
definir extensiones propias si son necesarias para otros mtodos de anlisis.
Modelado del rendimiento

Segn los autores del perfil, el anlisis del rendimiento tiene muchas caractersticas
comunes con el anlisis de planificabilidad, por lo que comparten como base comn el
Modelo de Recursos Generales. Consideran que el anlisis del rendimiento es ms
adecuado para sistemas de tiempo real no estrictos porque se basa en tcnicas
estadsticas, como teora de colas, que producen, asimismo, resultados estadsticas.
Por tanto, el modelo que proponen es mnimo, con la esperanza de que los
desarrolladores de herramientas especialicen nuevos subperfiles concretos para
anlisis particulares. Aun as, afirman que lo que ofrecen es suficiente para hacer un
anlisis bsico de rendimiento incluso de sistemas complejos.
Estructura del perfil

Al perfil se le ha dado una estructura modular para permitir que los
usuarios no tengan que considerar todo el perfil en su conjunto, sino
que puedan trabajar slo con una parte de l. Esta divisin tambin
est pensada para facilitar su especializacin. El perfil est dividido en una serie de
subperfiles (Figura 3.1), organizados en paquetes, dedicados a aspectos concretos y a
tcnicas de anlisis de modelos. El ncleo del perfil es el conjunto de paquetes que
representa el marco de modelado de recursos generales. A su vez, el modelo de
recursos generales est dividido en varias partes, con la idea de que las posteriores
especializaciones solo tengan que usar la parte concreta que necesiten.
96
El paquete principal, el del Marco de Modelado de Recursos Generales, General

Resource Modeling Framework, se divide en tres subpaquetes, de los que el principal
es el de modelado de recursos, que se ha hecho de tal manera que sea lo ms
independiente posible de los modelos de concurrencia y tiempo que se definan. Tanto
la concurrencia como el tiempo se definen en sus propios subpaquetes dentro del
paquete principal. El perfil define tambin un segundo paquete en el que se incluyen
tres tipos de anlisis, el anlisis de planificabilidad (SAProfile), el de rendimiento
(PAProfile) y uno adicional que es una especializacin del de planificabilidad,
(RSAProfile), para analizar la planificabilidad de sistemas CORBA de tiempo real.
Junto con esos paquetes se ha definido un modelo de biblioteca con la definicin de
un modelo de CORBA de tiempo real. Este modelo pretende ser un ejemplo que avale
el trabajo hecho en el perfil.
Figura 3.1. Estructura de

paquetes
del
perfil
de
Planificabilidad, Rendimiento y
Especificacin de Tiempo.
El paquete de modelado de recursos generales

El paquete de modelado de recursos generales, General Resource Modeling
Framework (GRM), es la parte fundamental del perfil, en la que se definen los
fundamentos necesarios para el anlisis cuantitativo de modelos UML. La nocin
bsica del modelo es la de calidad de servicio, que proporciona una base uniforme
para adjuntar informacin cuantitativa a los modelos UML. La informacin sobre
calidad de servicio representa, de manera directa o indirecta, las propiedades fsicas
de los entornos hardware y de la aplicacin representada en el modelo.
97
Expresin del
Tiempo en las
Mquinas de
Estados
TEMA 4
Competencia:
Aplicar los mecanismos de expresin del
tiempo en las mquinas de estados de UML
98
Tema 04: Expresin del Tiempo en las

Mquinas de Estados
Los nicos mecanismos relativos al manejo del tiempo en UML
son los eventos de tiempo, TimeEvent, y las expresiones de
tiempo, TimeExpression. Un evento de tiempo modela el
cumplimiento de un plazo temporal que se especifica mediante
una expresin de tiempo. Las expresiones de tiempo no tienen
un formato bien definido y se deja total libertad para su
especificacin. El tiempo expresado puede ser absoluto, una cantidad concreta de
tiempo, o relativo, una cantidad de tiempo desde un determinado evento, que
habitualmente es el instante de entrada a un estado.
Esta definicin del tiempo es tremendamente imprecisa. No se hace mencin a ningn

reloj de referencia, ni a la posibilidad de mltiples relojes, ni se especifica cules son
las unidades de tiempo, o si se puede modelar la precisin de los relojes, o algunas
otras de sus caractersticas. Burns y Diethers, modelan las mquinas de estados de
UML mediante autmatas con tiempo. En estas propuestas los autmatas con tiempo
disponen de un conjunto de relojes asociados; cada reloj se puede reiniciar a cero,
avanza montonamente y se puede consultar su valor para establecer condiciones
que se basen en ellos.
En ambos trabajos se aprovechan estas propiedades

para hacer anlisis de planificabilidad. Para modelar el
tiempo de ejecucin de las tareas llevadas a cabo en
un estado, se reinicia a cero un reloj cuando se entra
al estado, se establece como invariante del estado que
el valor del reloj es menor o igual que un tiempo y la
condicin de salida del estado se define como que el valor del reloj llegue al tiempo
referenciado en el invariante del estado.
99
Caractersticas del entorno de tiempo

Se puede describir el tiempo de ejecucin de una accin de SDL asociando una
etiqueta al icono de la accin, en vez de hacerlo de manera implcita. Con esa
etiqueta, se puede analizar la estructura del sistema especificado para construir una
red de tareas sobre la que hacer el anlisis de planificabilidad. En ese caso hay que
especificarlo como un comentario adicional porque no se tiene acceso al metamodelo
de SDL y no se pueden agregar nuevas caractersticas a los elementos de SDL.
Para incluir el manejo del tiempo necesario para

el anlisis de planificabilidad que queremos
hacer, nosotros vamos a seguir una estrategia
similar para SDL, aunque adaptndolo en
funcin de las diferencias entre SDL y las mquinas de estados de UML. Una primera
diferencia fundamental es que, en nuestro caso, en el que hemos definido un
metamodelo de las acciones y de las mquinas de estados, se puede aadir en ese
metamodelo la informacin sobre el tiempo de ejecucin y no hace falta hacer uso de
comentarios adicionales. Otra parte de la informacin necesaria para poder efectuar el
anlisis de planificabilidad es la relativa a las caractersticas temporales del entorno de
las mquinas de estados. En ese entorno se incluyen, entre otras cosas, los
mecanismos de manipulacin del tiempo. Como se ha indicado, SDL incluye una
definicin precisa de los mecanismos que proporciona para el manejo del tiempo.
En un sistema monoprocesador hay un reloj central que avanza montonamente y

cuyo valor puede ser consultado con la operacin now ( ), que devuelve un valor de un
tipo previamente definido, TIME, y los temporizadores, que son objetos que se pueden
definir en un proceso, arrancar con la operacin SET y reiniciar con la operacin
RESET. Los temporizadores generan un evento cuando llegan al final de su cuenta sin
haber sido reiniciados. Para incluir el entorno temporal necesario en las mquinas de
estados, vamos a usar mecanismos temporales similares a los definidos en el UML
Profile for Schedulability, Performance, and Time Specification. Por tanto, vamos a
definir los paquetes y los elementos necesarios usando el esquema que se ha seguido
para definir las acciones y las mquinas de estados: por cada paquete se definir un
subpaquete con la sintaxis abstracta, otro con el dominio semntico y otro con la
aplicacin semntica.
100
En el paquete de recursos temporales generales vamos a incluir los relojes y los

temporizadores. Los relojes ofrecen una operacin now() que permite consultar el
valor actual. Los temporizadores ofrecen operaciones para iniciarlos, set, y para
pararlos, reset.
Si un temporizador llega al final del tiempo establecido tras ser iniciado y sin haber
sido parado, genera una instancia de un evento temporal (Figuras 4.1, 4.2 y 4.3).
Figura 4.1: Sintaxis abstracta de los recursos temporales.
Figura 4.2. Dominio semntico de los recursos temporales.
101
Otro elemento que se debe introducir para tener la informacin necesaria para el
anlisis de planificabilidad es el tiempo de clculo de una accin, el conocido como
WCET (Wors Case Execution Time). Este dato se usa en mtodos de anlisis como el
del clculo del nivel de ocupacin del procesador o el del clculo del tiempo de
respuesta. Para aadir esa informacin a las acciones vamos a definir dos nuevas
clases a partir de las clases, TimedAction y TimedExecution. TimedAction tiene
asociado un valor de tiempo, el WCET, el tiempo de respuesta en el peor caso.
TimedExecution tiene asociado otro valor de tiempo, execTime, que corresponde al
tiempo que ha tardado dicha ejecucin concreta de la accin.
Figura 4.3. Sintaxis abstracta

de las acciones con tiempo.
Figura 4.4. Dominio semntico

de las acciones con tiempo.
Respecto al modelo de ejecucin, vamos a considerar que todos los objetos cuyo
funcionamiento viene definido por una mquina de estados se implementan con
objetos activos, y que cada uno cuenta con su hebra de ejecucin propia. Esta opcin
coincide con el concepto de concurrency unit que se define en el modelado de la
concurrencia del UML Profile for Schedulability, Performance, and Time Specification.
El modelo de paralelismo implicar que los objetos activos se ejecutaran
concurrentemente y que su ejecucin es interrumpible.
102
Un objeto podr ser interrumpido por otro objeto cuando se produzca un evento que
este otro objeto sea capaz de procesar y si el proceso que se activa tiene una
prioridad mayor que el proceso que va a ser interrumpido. En lo que concierne al
manejo y postergacin de los eventos recibidos por un objeto activo, se supondr que
cada objeto cuenta con una cola propia en la que se almacenan temporalmente las
instancias de los eventos que el objeto ha recibido pero no ha procesado an.
Problemas de tiempo real

Es necesario, considerar si los problemas detectados en SDL aparecen asimismo
cuando se usan las mquinas de estados de UML para disear un sistema de tiempo
real.
Expresin de restricciones temporales

Una funcin usual para la que se utilizan los temporizadores es la de marcar una
secuencia peridica, para, por ejemplo, activar una actividad peridicamente, como
puede ser un sensor. Otra funcin es la de
marcar un retraso, o la consumicin de un
periodo de tiempo, que, por ejemplo, indique
el final del plazo de ejecucin seguro
asignado a un proceso.
En ambos casos, cuando el plazo de activacin acaba, el

temporizador genera un evento temporal que se enva a la
mquina adecuada. Ilustremos esta idea con un ejemplo.
Supongamos una mquina de estados simple que cuenta
con un nico estado, Figura 4.5, en el que se admiten dos
seales, una corresponde a la expiracin de un temporizador, t,
que se activa con un determinado plazo temporal cada vez que se entra al estado, y la
otra corresponde a la recepcin de una instancia de un evento externo, e.
103
Con este diseo se pretende conseguir una activacin peridica del temporizador.
Figura 4.5: Maquina de estados con activacin peridica de un temporizador.
Como se ha mencionado anteriormente, los eventos que llegan a una mquina de

estados se almacenan en una cola, con una poltica del primero en entrar, primero en
salir. Si la mquina de estados est ocupada respondiendo a la recepcin de otro
evento cuando recibe una instancia del evento de expiracin del temporizador, el
procesamiento del evento de la expiracin del temporizador se ver retrasado. Cuando
la mquina de estados por fin atienda ese evento y llame a la funcin para consultar el
valor del tiempo actual con la operacin now( ) para volver a activar el temporizador, el
valor devuelto por la funcin ser el instante en el que se ha empezado a atender el
evento, no el instante en el que se ha recibido. Eso significa que el retraso con el que
el temporizador se activa la siguiente vez es mayor que el del perodo deseado.
Esa situacin tambin se puede dar en otras circunstancias. Si la cola de eventos no

est vaca, sino que contiene alguna instancia de la otra seal, en cuyo caso el tiempo
que transcurre entre que se recibe la seal y sta se procesa es an mayor. Ocurre
incluso que ese tiempo no est acotado porque no lo est el nmero de instancias de
eventos que puede haber en la cola.El otro motivo es que, con el modelo de
concurrencia considerado, la mquina de estados puede ser interrumpida por otra
mquina de estados de mayor prioridad y esta interrupcin puede ocurrir entre el
instante de la recepcin del evento y el inicio de su procesamiento, por lo que el valor
devuelto por la funcin now() no coincidir con el de la recepcin de la seal, aunque
la mquina atienda inmediatamente el evento.
104
MQUINAS DE ESTADO
http://200.69.103.48/comunidad/profesores/jruiz/jairocd/texto/cirdig/maquinasdee
sf.pdf
MQUINAS DE ESTADO FINITO

http://www-2.dc.uba.ar/materias/isoft1/is1-2007_1/recursos/Apuntes/FSM.pdf)
1. En un documento en Word elabore un cuadro comparativo

sobre las mquinas de estados concurrentes y mquinas de
estados sincrnicas.
Envalo a travs de "Maquinas de Estados".
2. En un documento en Word describa el proceso de utilizacin

adecuada de las herramientas de modelado en sistemas de
tiempo real.
Envalo a travs de "Sistema de Tiempo Real".
105
Autoevaluacin
1) En una mquina de estados comprende un conjunto de transiciones que:

a. Tienen un estado origen y un estado destino.
b. Tienen un estado negativo y otro positivo.
c. Tienen un origen negativo y positivo.
d. Tienen una configuracin abstracta y estricta.
e. Tienen una contextura ligera y positiva.
2) Las expresiones de tiempo pueden ser:
a. Inicio y final.
b. En minutos o das.
c. En unidades didcticas.
d. Absoluto o relativo.
e. Basado en reacciones.
3) Una instancia de una mquina de estados es una entidad que, al igual que un
objeto, pasa por:
a. Diferentes acciones.
b. Diferentes estados.
c. Diferentes direcciones.
d. Diferentes orificios.
e. Diferentes modos.
4) Los estados compuestos estn divididos jerrquicamente en:
a. Estados.
b. Enlaces.
c. Subestados.
d. Mtodos.
e. Atributos.
5) En los sistemas de tiempo real se modela el tiempo como magnitud, para
medir las:
a. Restricciones.
b. Secuencias.
c. Interacciones.
d. Configuraciones.
e. Medidas.
106
6) Un ejemplo donde se modela sobre el tiempo es:

a. En el uso de un reloj en el desarrollador.
b. En los uso de los temporizadores por el sistema operativo.
c. En el uso un cronmetro por el analista del sistema.
d. En el uso de calendarios y fechadores.
e. En el desarrollo de un mquina.
7) Los nicos mecanismos relativos al manejo del tiempo en UML son:
a. Timeclok y Timegold.
b. Timetype y Timestate.
c. TimeEvent y TimeExpression.
d. Timefution y Timewatch.
e. Timerun y Timestart.
8)
Se puede describir el tiempo de ejecucin de una accin de SDL asociando:

a. Una etiqueta al cono de configuracin.
b. Una etiqueta al cono de restriccin.
c. Una etiqueta al cono de programacin.
d. Una etiqueta al cono de modulacin.
e. Una etiqueta al icono de la accin.
9) Los estados compuestos concurrentes se dividen en:

a. Dominios.
b. Departamentos.
c. Sectores.
d. Regiones.
e. Estratos.
10) En la semntica del modelo se incluyen nuevas clases para los nuevos tipos
de estados:
a. Las regiones y dominios.
b. Los sectores y estratos.
c. Las clases y atributos.
d. Los enlaces y clases.
e. Las secuenciales y los concurrentes.
107
Resumen
UNIDAD DE APRENDIZAJE IIi:
El modelo ms simple de una mquina de estados consta de un conjunto de situaciones

estables, denominadas estados, en uno de los cules la mquina siempre permanece.
La mquina de estados tambin comprende un conjunto de transiciones. Cada
transicin tiene un estado origen y un estado destino. Los estados compuestos estn
divididos jerrquicamente en subestados, lo que permite que el funcionamiento de la
mquina de estados pueda definirse en un nivel mayor de detalle.
Los estados compuestos concurrentes se dividen en lo que se denominan regiones. Las

regiones trabajan de manera concurrente. Debe haber al menos dos regiones en un
estado concurrente. Las regiones tambin tienen que ser a su vez estados compuestos.
En las mquinas de estados con estados concurrentes aparecen dos nuevas clases,
ConcurrentState y SequentialState. En la semntica de este modelo se incluyen nuevas
clases para los nuevos tipos de estados, los secuenciales y los concurrentes.
Debido a la gran diversidad de posibles sistemas de tiempo real, duro y blando,

distribuidos y monoprocesadores, etc., es muy difcil establecer un conjunto cannico de
de conceptos de modelado y dise que comprenda todos los sistemas. El modelado
del tiempo modela el tiempo como magnitud, para medir las restricciones. Encuentran
til distinguir entre tiempo fsico y tiempo virtual, o de simulacin, que puede
incrementarse de manera no montona.
Los nicos mecanismos relativos al manejo del tiempo en UML son los eventos de
tiempo, TimeEvent, y las expresiones de tiempo, TimeExpression. Un evento de tiempo
modela el cumplimiento de un plazo temporal que se especifica mediante una expresin
de tiempo. SDL incluye una definicin precisa de los mecanismos que proporciona para
el manejo del tiempo. En un sistema monoprocesador hay un reloj central que avanza
montonamente y cuyo valor puede ser consultado con la operacin now( )
108
109
Introduccin
a) Presentacin y contextualizacin
Los sistemas informticos de tiempo real se utilizan en numerosos campos de
aplicacin, como el control de aviones, automviles y trenes, trfico,
comunicaciones, satlites, control de procesos, electrnica de consumo, etc. La
caracterstica ms importante de estos sistemas es que sus acciones se deben
ejecutar en intervalos de tiempo determinados por la dinmica de los sistemas
fsicos que supervisan o controlan. Adems, suelen tener requisitos estrictos de
fiabilidad y seguridad. Muchos de estos sistemas estn empotrados en otros
sistemas, lo que conlleva una limitacin de recursos (potencia de procesador,
memoria, etc.) con respecto a otros tipos de sistemas informticos.
b) Competencia
Analiza las distintas metodologas de diseo de sistemas de tiempo real
orientado a objetos.
c) Capacidades
1. Explica la metodologa de diseo de sistemas de tiempo real orientado a
objetos.
2. Elabora adecuadamente la estructura de una propuesta sobre la aplicacin de
una metodologa de diseo.
3. Aplica modelos de diseo e interaccin con dispositivos fsicos.
4. Analiza el proceso de diseo de un telfono inalmbrico y sus particularidades.
d) Actitudes
Promueve la adecuada aplicacin de los sistemas en los diversos dispositivos
fsicos de inters.
Muestra inters por el anlisis sobre las diversas metodologas de diseo de
sistemas basado en objetos.
e) Presentacin de Ideas bsicas y contenido esenciales de la Unidad:

La Unidad de Aprendizaje 04: Metodologa de diseo de sistemas orientado
a objetos comprende el desarrollo de los siguientes temas:
TEMA 01: Introduccin a la metodologa de diseo.
TEMA 02: Propuesta de una metodologa.
TEMA 03: Diseo con dispositivos fsicos.
TEMA 04: Un caso real: El diseo de un telfono inalmbrico.
110
Introduccin
a la
Metodologa
TEMA 1
de
Diseo
Competencia:
Explicar la metodologa de diseo de
sistemas de tiempo real orientado a objetos.
111
Tema 01: Introduccin a la Metodologa de Diseo

Aqu presentamos una metodologa de desarrollo de
sistemas empotrados de tiempo real para el diseo de
sistemas monoprocesadores.
presenta
una
metodologa
En muchos
cuyas
trabajos se
caractersticas
ms
sobresalientes son el uso sistemtico de lenguajes grficos

de modelado para la especificacin y diseo del sistema en
sus diferentes etapas, la integracin del anlisis de
planificabilidad en el entorno del uso de estos lenguajes
grficos y el modelo de interaccin con los dispositivos fsicos. La metodologa
incluye entre sus fases la simulacin y validacin del sistema. Para estas fases es
necesario que el lenguaje en el que describe el sistema tenga una semntica precisa
para generar una implementacin ejecutable del sistema.
Para el anlisis de planificabilidad se puede proponer Rate-Monotonic Analysis

(RMA), que proporciona una coleccin de mtodos cuantitativos para analizar y
predecir el funcionamiento temporal de los sistemas de tiempo real. Estos anlisis
pueden ayudar a organizar los procesos y los recursos en el diseo para hacer
posible predecir el funcionamiento del sistema final. En este sentido, RMA ayuda a
incorporar el anlisis de tiempo real y salvar el vaco entre el modelo de objetos y el
modelo de tareas.
Las tareas que se usan en el anlisis de planificabilidad se

obtienen a partir de la especificacin del funcionamiento dinmico
del sistema. Se puede usar UML en las primeras fases,
especificacin y diseo del sistema, y SDL en la parte final, para el
diseo
estructural
detallado,
el
disenso
de
procesos,
la
implementacin de cdigo y la simulacin y validacin del sistema.
112
Una de las razones principales de la eleccin de SDL es que, gracias a su semntica,

formal y claramente establecida, existen herramientas automticas como Tau de
Telelogic, que incluye entre sus funciones la simulacin y validacin del sistema
especificado y la generacin de cdigo. Por otro lado, se han desarrollado
herramientas que permiten aplicar RMA para realizar el anlisis de planificabilidad de
un sistema especificado en SDL, mediante su transformacin en grafos de tareas Es
posible modificar las metodologas propuestas en la que se sustituye SDL por UML
en las etapas finales del diseo. La razn de esta sustitucin es la tremenda
popularidad que ha alcanzado UML para la construccin de sistemas de todo tipo,
incluidos los sistemas reactivos y de tiempo real.
El uso de UML, no obstante, lleva acarreados inconvenientes que hay que solventar.
Como UML carece de una semntica formal, no es posible an llevar a cabo las
ltimas fases de la metodologa sobre diagramas UML: generacin de cdigo,
simulacin, validacin y anlisis de planificabilidad.
Por este motivo se ha desarrollado una semntica precisa para las acciones y para
las mquinas de estados de UML. Esta semntica es el primer paso para eliminar la
ambigedad
presente
en
UML
construir
herramientas
automticas
que
proporcionen las funciones mencionadas.
ANTECEDENTES
Se han llevado a cabo algunos trabajos para intentar integrar este tipo de anlisis en
un modelo SDL. Por ejemplo, ObjectGeode incluye un analizador de rendimiento en
su simulador que hace uso de algunas directivas para extender SDL para indicar
prioridades de procesos o retrasos temporales. En algunos trabajos se incluye una
semntica del plazo ms inmediato para SDL, de manera que permite una traduccin
desde una especificacin en SDL a una red de tareas analizable. Sin embargo, no
integran este anlisis en el resto del ciclo de desarrollo, ni tienen en cuenta la
interaccin con el hardware o anomalas de tiempo real como la inversin de
prioridades.
113
Otra lnea de trabajo en este contexto es la de

suplementar SDL con modelos de carga, en el que
se usa por ejemplo en la teora de colas para calcular
los tiempos en las colas de los trabajos y los
mensajes y las cargas de trabajo media y mximas
de los procesadores.
Otros trabajos presentan una estrategia nueva para la
prediccin temprana de rendimiento basada en sistemas especificados en MSC en el

contexto de SDL. Estos trabajos pueden ser complementarios y tiles en las primeras
fases del diseo, pero que para los sistemas de tiempo real es necesario hacer un
anlisis final de planificabilidad y, para conseguirlo, es necesario proporcionar un
modelo de ejecucin planificarle para UML.
Se puede aplicar la teora de planificabilidad en ROOM. Aunque es muy til, ROOM

no es una tcnica de descripcin formal y no puede usarse para incluir una fase de
validacin automtica directamente desde el diseo. La validacin es un tema
importante para el diseo de los sistemas de tiempo real. Una propuesta encaminada
a la sntesis automtica de implementaciones es a partir de los modelos de diseo
orientados a objetos de tiempo real, este incluye el tema del tiempo real y la
respuesta en un plazo de tiempo en el proceso de diseo.
Altisen y Sifakis proponen

una
metodologa
construir
para
sistemas
planificados restringiendo el
funcionamiento de los procesos para garantizar dos tipos de restricciones:
restricciones de planificabilidad y restricciones sobre los algoritmos de planificacin
tales como prioridades para procesos y posibilidad de interrupcin. Aunque la
metodologa se ilustra sobre procesos peridicos, puede aplicarse a sistemas
arbitrarios. Otra contribucin de este trabajo es la descomposicin de los requisitos
de planificacin en clases de requisitos que pueden ser expresados como
restricciones de seguridad.
114
UML-MAST es una metodologa y un conjunto de tcnicas de anlisis para

especificar, disear y estudiar sistemas de tiempo real haciendo uso de diversos
diagramas de UML en herramientas automticas, como diagramas de clases y
objetos, de secuencias y de actividad. La
metodologa incluye cinco vistas del
sistema, entre las que se encuentra la Mast RT View, que incluye informacin
sobre las caractersticas necesarias para realizar los anlisis de tiempo real, como el
funcionamiento temporal, las restricciones de rendimiento, etc. Esta informacin se
pasa como entrada a diversas herramientas que analizan diferentes aspectos
temporales del sistema, como anlisis de planificabilidad, simulaciones o anlisis de
utilizacin.
Los autores declaran que los nuevos componentes incluidos en UML para
especificar esta nueva vista disponen de un metamodelo formal. Este metamodelo se
define se una manera similar a como se definen las clases del UML Profile for
Schedulability, Performance, and Time Specification.
La semntica esttica se define mediante diagramas de clases, pero la semntica
dinmica se hace en lenguaje natural. Con respecto al trabajo relacionado con la
traduccin del modelo de objetos a modelo de procesos, UML/RT propone una vista
dinmica basada en mquinas de estados para cada objeto pasivo del modelo de
objetos. Octopus, propone el modelo de diseo como una extensin del modelo de
objetos, aunque puede necesitar una descomposicin ulterior en la fase de
implementacin. Con el objetivo de disear la concurrencia, Octopus propone el
concepto de hebra de interaccin entre objetos que representa el conjunto de objetos
que pueden tomar parte en un evento.
Octopus usa mquinas de estados para describir el funcionamiento en trminos de

cambios de estado causados por los eventos. Sin embargo, no los usan formalmente.
Usa class outlines para grabar los detalles del diseo. ste es el punto de arranque
de la fase de implementacin. Octopus combina dos conceptos, objetos y procesos
del sistema operativo, para disear la concurrencia. La traduccin directa de objetos
a procesos del sistema operativo no es fcil y pensamos que el paso intermedio que
proponemos la facilita
115
El paso del modelo de anlisis al modelo

de dis
eo en ROPES puede hacerse
usando
traductoras.
tcnicas
Las
elaborativas
tcnicas
traductoras
proponen definir traductores aplicados al

modelo de objetos para
producir un
sistema ejecutable. El traductor tiene dos partes: un marco de tiempo real y un

generador de cdigo. En este caso el modelo de objetos necesita estar ms detallado
que el que proponemos en nuestra metodologa. El modelo elaborativo es ms
tradicional. El modelo de anlisis es realizado con detalles de diseo y puede ser
mantenido como una entidad distinta del modelo de anlisis.
HRT-HOOD traduce el modelo de objetos a Ada. Para cada objeto se generan dos
paquetes: el primero simplemente contiene una coleccin de tipos de datos y
variables que definen los atributos de tiempo real del objeto; el segundo contiene el
cdigo del objeto. En este sentido esta metodologa propone un enfoque traductivo.
Estas formas diferentes de pasar del modelo de objetos al modelo de diseo son muy
interesantes, pero pensamos que es importante incluir en el modelo de diseo un
formalismo que incluya una fase de validacin para detectar situaciones indeseables
en los diseos concurrentes como la inanicin, bloqueos, etc.
116
Propuesta
TEMA 2
de una
Metodologa
Competencia:
Elaborar adecuadamente la estructura de
una propuesta sobre la aplicacin de una
metodologa de diseo.
117
Tema 02: Propuesta de una Metodologa

En esta seccin se propone soluciones parcia les
a algunos de los problemas presentes en las
metodologas de desarrollo orientadas a objetos.
Del salto existente entre el modelo de objetos y el
modelo de procesos, que presenta un inters
especial en el contexto de sistemas empotrados de
tiempo real. Se cubre este vaco mediante dos estrategias ortogonales. Se proporciona
una estrategia para pasar del modelo de objetos al modelo de procesos, de tal manera
que las restricciones de tiempo real pueden ser predecibles. Los criterios de diseo
que pueden aplicarse cuando una clase (u objeto) del modelo de objetos tiene que ser
traducida a uno o ms procesos (descritos mediante mquinas de estados).
Esta forma de traducir el modelo de objetos al modelo de procesos es un aspecto

importante de esta propuesta, y proporciona una estrategia clara para convertir objetos
en procesos, dando la posibilidad de analizar las propiedades de tiempo real. Sin
embargo, se ha aprendido de la experiencia en el desarrollo de sistemas empotrados
de tiempo real otras dos lecciones. En primer lugar, el modelo de objetos puede ser
refinado un poco ms de lo que recomiendan otras metodologas, y en algunas
ocasiones este diseo orientado a objetos ms detallado es altamente recomendable.
En segundo lugar, se puede conseguir un mejor

provecho de este modelo ms refinado si obtenemos
una buena correspondencia entre los elementos del
modelo de objetos y los elementos del modelo de
procesos. Esta traduccin detallada entre ambos
modelos presenta algunas novedades con respecto a las sugerencias hechas en otras
propuestas. El enfoque principal de esta metodologa es sobre el sistema de desarrollo
usando anlisis y diseo orientados a objetos, pero proporcionando anlisis de tiempo
real basado en las mquinas de estados de UML. La metodologa propuesta est
bsicamente dividida en cuatro fases Anlisis, Diseo, Validacin e Implementacin.
118
En cada fase se tienen en cuenta los aspectos funcionales y

no funcionales en dos vistas del sistema separadas, pero
complementarias. Esta distincin nos permite capturar las
caractersticas de tiempo real y las peculiaridades de los
dispositivos fsicos del sistema, con relativa independencia
de los requisitos funcionales (modelos de objetos y
dinmicos), pero recordando en qu nivel han surgido los
requisitos especficos.
La Figura 2.1 muestra las diferentes fases de esta metodologa. Como se ha

mencionado ya, esta figura muestra como cada fase se divide verticalmente en dos
vistas, dando las perspectivas funcionales y no funcionales. Obsrvese que las
expresiones usadas para denotar cada fase son diferentes dependiendo de sobre qu
aspecto se desea enfocar en cada vista. La primera fase se denomina Anlisis desde
una perspectiva funcional, mientras que usamos el trmino Especificacin de
requisitos de tiempo real para la vista no funcional. Cada una de estas dos vistas est
a su vez subdividida en otras dos vistas (llamadas modelos), distinguiendo as el
modelo de objetos del modelo dinmico en la perspectiva funcional y el modelo de
tiempo real de las restricciones fsicas en la perspectiva no funcional.
En la fase de anlisis se identifican y se analizan el dominio del problema y los

requisitos del usuario del sistema. Bsicamente, durante esta fase establecemos un
primer modelo de objetos y los casos de usos preliminares del sistema. Usaremos dos
notaciones grficas para apoyar ambas actividades: los diagramas de clases de UML
para capturar la descripcin orientada a objetos, y diagramas de secuencias para
describir el modelo dinmico.
Durante la fase de diseo los aspectos funcionales del sistema se estudian a dos
niveles: sistema y objetos. El diseo se realiza bsicamente mediante diagramas de
clases y objetos de UML. El diseo del sistema corresponde a un diseo de alto nivel,
que se refina cuanto sea necesario hasta llegar a un diseo de objetos detallado.
119
En la fase de simulacin, validacin y evaluacin del

rendimiento se contrastan los resultados de las fases de
anlisis y diseo. La simulacin y la validacin del sistema
se hacen usando la especificacin del sistema antes de su
implementacin. Estas tcnicas nos permiten detectar
posibles errores generales de diseo tales como bloqueos,
consumo implcito de seales, etc. Adems, se pueden
estudiar algunos escenarios particulares del sistema mediante la verificacin del
funcionamiento mediante diagramas de secuencia. Estos diagramas de secuencia
pueden describir situaciones requeridas, o prohibidas, que pueden verificarse
automticamente por las herramientas existentes. En este sentido, es posible usar los
diagramas de secuencia refinados en la fase previa para verificar parte de la
funcionalidad del sistema.
Finalmente, en la fase de implementacin obtenemos el cdigo correspondiente a la

parte del sistema especfica de la aplicacin. Este cdigo especfico de la aplicacin se
sostiene tpicamente sobre servicios genricos proporcionados por un nivel
subyacente (sistema operativo o el sistema de tiempo de ejecucin). Este nivel debe
proporcionar ciertas caractersticas para permitir nuestro modelo de ejecucin de
tiempo real analizable. Al menos, debe proporcionar planificacin de procesos
completamente interrumpible basada en prioridades fijas y alguna forma de herencia
de prioridad. Adems, el modelo de dispositivos fsicos debera adaptarse al
proporcionado (si lo hay).
ANLISIS Y ESPECIFICACIN DE REQUISITOS DE

TIEMPO REAL
La parte funcional del anlisis est dedicada a la obtencin
de los requisitos de usuario. En su parte funcional, se usan
los diagramas de casos de uso y los diagramas
de
actividad para identificar la dinmica de uso del sistema.

Con esta informacin, se crean los diagramas de clases que identifican los actores
involucrados en las acciones descritas anteriormente, desde el punto de vista del
usuario.
120
En esta fase tambin tiene una gran importancia la descripcin de los aspectos no
funcionales. En este nivel, el sistema se ve como una caja negra que responde a
estmulos del exterior, por lo que toda la informacin que se recopile ser relativa a
eventos producidos fuera de los lmites del entorno. Se tiene que tener en cuenta que
el sistema habr de responder simultneamente a eventos externos cuya frecuencia
puede ser distinta, o no estar definida y dar el resultado deseado dentro de los lmites
de tiempo impuestos. As, esta fase se centrar en la deteccin de los requisitos
temporales de los eventos externos (especficamente eventos de entrada) producidos
por la interaccin con el entorno, en el que incluyen los dispositivos fsicos y otros
subsistemas.
El resultado de esta actividad es una tabla con los eventos externos, donde por cada
evento se recopila la siguiente informacin: identificacin del evento, clases
involucradas en la respuesta del sistema y requisitos temporales (sobre periodo, plazo
de respuesta, jitter,).
Figura 2.1: Fases de la metodologa
121
Diseo
con
TEMA 3
Dispositivos
Fsicos
Competencia:
Aplicar modelos de diseo e interaccin con
dispositivos fsicos.
122
Tema 03: Diseo con Dispositivos Fsicos

En esta fase, una diferencia importante de esta propuest a con respecto a otras
metodologas (por ejemplo SOMT) es la posibilidad
de reducir el vaco existente entre el diseo
estructural (en diagramas de clases y objetos en
UML) y el de procesos (mquinas de estados en
UML). Esto es posible gracias a las actividades que
se llevan a cabo durante esta fase (interaccin con
los dispositivos fsicos y asignacin de prioridades) para capturar los aspectos no
funcionales.
NIVEL DE OBJETOS (SISTEMA)

En el aspecto funcional, en la fase de diseo se construye la estructura del sistema
partiendo de los diagramas obtenidos en la fase de anlisis. A partir de los diagramas
de clases del anlisis se generarn nuevos diagramas de clases que reflejen la
arquitectura lgica del sistema. Estos diagramas de clases se instanciaran en
diagramas de objetos para reflejar la estructura concreta del sistema.
NIVEL DE OBJETOS (DISEO)

Los diagramas de clases y objetos se usan
hasta en los ltimos pasos de esta fase. As,
durante este nivel del diseo, los diagramas de
clases y objetos se van detallando hasta llegar
a un diseo de objetos muy refinado.
Como en otras metodologas, los objetos se
traducen a procesos siguiendo criterios claros
tales como los siguientes: los objetos activos se
describirn con una mquina de estados propia, al menos, para que tenga su propia
capacidad de ejecucin. En algunas situaciones tiene que considerarse la posibilidad
de incluir en un objeto capacidad para procesamiento mltiple.
123
Una de estas situaciones se da cuando el objeto est

involucrado en el procesamiento de varios eventos
simultneos que no pueden cumplir sus requisitos
temporales. En este caso, puede ser necesario dividir el
objeto en varios para atender por separado a los
diferentes eventos . Otra posibilidad es la de usar
mquinas de estados con objetos concurrentes. Los objetos pasivos no compartidos
por varios objetos activos se modelan como un tipo de datos interno al proceso cliente.
Si el objeto pasivo es compartido consideramos un proceso con las limitaciones que
deben establecerse, tambin tratamos con las clases que modelan el funcionamiento
de la parte fsica, y proponemos la distincin entre procesos a ctivos (manejadores de
dispositivos fsicos) y procesos pasivos (que modelan directamente los dispositivos
fsicos).
A la vez que el diseo de los aspectos funcionales del sistema tambin se tienen en
cuenta las caractersticas no funcionales. En esta fase, Asignacin de prioridades e
interaccin con los dispositivos fsicos, an se mantienen en esta actividad dos
niveles: el nivel de sistema y el nivel de objetos.
INTERACCIN CON LOS DISPOSITIVOS FSICOS Y ASIGNACIN DE

PRIORIDADES
(NIVEL DE SISTEMA)
Respecto a los temas no funcionales, el
diseo tiene que capturar cmo los
dispositivos fsicos interaccionan con el
sistema.
En
este
sentido,
cada
componente fsico tiene que modelarse

como un objeto; por tanto, hay que definir
una clase para representar el componente fsico correspondiente. Las actividades que
se han de desarrollar en esta fase son similares a las propuestas en otras
metodologas como, por ejemplo, en Octopus.
124
Sin embargo, las guas para agrupar las clases que modelan los dispositivos fsicos
marcan una diferencia respecto a la estrategia propuesta por Octopus. De hecho, en
vez de agrupar todas estas clases en un nico subsistema, proponemos distribuir las
clases de dispositivos fsicos entre los diferentes subsistemas que han sido generados
durante la fase de anlisis. Esto promueve un diseo ms natural y razonable, porque
las clases que representan cada componente fsico estn definidos all donde se
necesitan. Bsicamente, la notacin que proponemos a este nivel son los diagramas
de clases y objetos de UML.
INTERACCIN CON LOS DISPOSITIVOS FSICOS Y ASIGNACIN DE

PRIORIDADES
(NIVEL DE OBJETOS)
El nivel de objetos de esta fase est dedicado a disear la interaccin con los
dispositivos fsicos, distinguiendo para cada componente fsico un objeto pasivo
y un objeto controlador. El primero modela el acceso al componente fsico y el
segundo implementa el protocolo demandado por los requisitos del sistema. Esta
forma de disear los componentes fsicos ayuda a decidir qu se va a disear como
software y qu como hardware, y a simular el sistema en la fase de diseo. Los
procesos fsicos desaparecen en la fase de implementacin.
Durante esta fase se llevan a cabo otras actividades. Por un lado, se completan las
cadenas de secuencias de los eventos, asociando objetos a eventos, o fijando las
prioridades de las transiciones. Por otro lado, se asignan los techos de prioridad de los
procesos pasivos usando mtodos como el de techo de prioridad inmediato.
Finalmente, se construye una
tabla, que muestra la correspondencia entre cada
evento y la correspondiente secuencia de transiciones. Adems, cada transicin tiene

asociada cierta informacin, como el tiempo de retraso debido a los bloqueos (si lo
hay), si es atmica o no, el tiempo de ejecucin en el peor caso y su prioridad relativa.
125
EVALUACIN DEL RENDIMIENTO

En esta fase se usan los modelos de simulacin para
analizar
cuantitativamente medidas tales como el
throughput y el tiempo de respuesta. Sera deseable

que este anlisis se llevara a cabo con herramientas
comerciales ya disponibles, aunque stas no ofrecen la
generacin del cdigo completo de un sistema a partir
de una especificacin UML.
En lo que respecta a la interaccin con los dispositivos fsicos, stos tienen que ser
simulados mediante elementos especificados en UML. Cuando el sistema est
implementado se acceder al dispositivo fsico mediante funciones C integradas en el
cdigo generado a partir del diseo. Sin embargo, durante esta fase tenemos que
completar la especificacin con clases y objetos UML que modelen el funcionamiento
de los dispositivos fsicos. Esto nos permitir la simulacin y validacin del sistema
completo, teniendo tambin en consideracin la interaccin con los dispositivos fsicos.
Otro aspecto relevante es el que corresponde a los requisitos de tiempo real.
Despus del diseo, es necesario un anlisis de tiempo real preliminar, usando este
anlisis es posible saber el funcionamiento temporal del sistema antes de la fase de
implementacin, y entonces hacer los cambios necesarios para mejorar el tiempo de
respuesta del sistema. En este sentido, la fase de evaluacin del rendimiento tambin
incluye un paso de rediseo para refinar el sistema especificado en UML. Basndonos
en la experiencia, este paso propone una serie de heursticos para cambiar el diseo y
mejorar los tiempos de respuesta de los eventos del sistema. Este paso ser
especialmente til cuando el sistema no cumpla los plazos de tiempo.
126
Los cambios en el diseo afectaran a los parmetros de la ecuacin del tiempo

de como el bloqueo y la interferencia. Proponemos un conjunto de heursticos
que nos permiten:
Redisear el sistema si no cumple los plazos de tiempo.

Tener en cuenta los requisitos de tiempo real desde los primeros pasos del
diseo.
Los heursticos se pueden resumir en los siguientes:
Transferencia de eventos, para reducir la interferencia con la respuesta a otros
eventos dentro del mismo objeto.
Creacin de procesos, para reducir el tiempo de bloqueo debido a eventos de
menor prioridad tratados por el mismo proceso.
Eliminacin de transiciones intermedias, eliminando transiciones entre objetos
que no aadan ninguna informacin, sino que slo sirvan como paso de
eventos.
127
Un Caso Real:
El Diseo
TEMA 4
de un
Telfono
Inalmbrico
Competencia:
Analizar el proceso de diseo de un telfono
inalmbrico y sus particularidades.
128
Tema 04: Un Caso Real: El Diseo de un

Telfono Inalmbrico
El Eole 400 es un telfono inalmbrico de la clase CT0 de
Alcatel,
que
admite
mltiples
auriculares,
con
un
contestador automtico de estado slido integrado en la

base. Est basado en otros dos productos anteriores CT0,
el France Telecom X1 (para el auricular y el circuito de radio
de la base) y el Eole 300 (para el resto de la base). El
sistema se compone de una parte fija (la base) y de uno o
ms auriculares. El software instalado en el telfono proporciona las siguientes
prestaciones principales:
Intercomunicacin entre la base y los auriculares.

Rellamada automtica al ltimo nmero marcado.
Activacin del altavoz durante la comunicacin.
Encriptacin de la comunicacin base-auricular.
Marcacin por pulsos o multifrecuencia.
Tres melodas programables en el auricular y opcin de desconectar el timbre.
Contestador automtico con modos de funcionamiento simple y de grabacin y
acceso remoto autentificado con cdigo de seguridad.
DESCRIPCIN DE LA PARTE FSICA
La base del EOLE 400 est compuesta de varios

circuitos electrnicos, algunos de ellos programables:
El microcontrolador NEC de 4 bits PD75116, con

8192x8 bits de memoria de programa (ROM), 512x4
bits de memoria de datos (RAM), 34 puertos de E/S,
un interfaz serie de 8 bits y un reloj a una frecuencia
de 4,19 MHz. El tiempo de ejecucin mnimo de una instruccin es 0,95s. Los
puertos de E/S conectan los diodos luminosos y el teclado al microcontrolador.
129
Una memoria EEPROM de chip nico, 24c01, con una capacidad de

almacenamiento de 1KByte.
Un circuito de radio, conocido como

COMBO, basado en el chip Motorola
MC13110.
Un circuito conversacional con altavoz

basado en el chip Motorola MC34216A.
Un mdulo contestador, conocido como

ATISAM, basado en el chip MSP58C80 de Texas Instruments.
Para iniciar una llamada, el usuario ha de pulsar la tecla line del auricular, con lo que
se enva una peticin de lnea a la base. El circuito de radio detecta el mensaje e
informa al sistema. Si la base est en disposicin de procesarlo, es decir, si no est ya
en el estado de comunicacin, se establece un enlace de radio entre la base y el
auricular y se activa el gancho de la lnea telefnica. Para volver al estado de
inactividad, el usuario puede pulsar otra vez la tecla line. Si, por ejemplo, se pulsa la
tecla intercom en la base, empiezan las acciones para comunicar una peticin a todos
los auriculares mediante la difusin de un mensaje a travs del circuito de la radio.
Si un auricular contesta la peticin, pulsando la tecla line, se establece una

intercomunicacin entre ese auricular y la base, gracias al micrfono integrado y al
altavoz. En caso contrario, si no hay respuesta en 15 segundos se supone que no hay
nadie interesado en la intercomunicacin y la base vuelve al estado inactivo.
Aunque ste es un sistema distribuido entre la base y los auriculares, slo se modelar
la parte fija del sistema, la de la base. Es decir, estamos tratando un sistema
monoprocesador.
130
APLICACIN DE LA METODOLOGA
La primera parte de la metodologa propuesta es la fase de anlisis. Los aspectos
funcionales de esta fase pueden dividirse en los niveles de requisitos y sistema. Los
documentos resultantes del nivel de requisitos son casos de uso desarrollados a partir
del manual de usuario, especificacin tcnica y entrevistas con los ingenieros
involucrados en el proyecto. A nivel de sistema se crea un primer diagrama de clases
para mostrar las relaciones entre los objetos identificados en el estudio de los
documentos de requisitos. Este diagrama se muestra en la Figura 4.1. Tras esto, se
hacen diagramas de secuencias para estudiar el funcionamiento dinmico de los
objetos en las posibles situaciones diferentes.
Figura 4.1: Arquitectura de objetos del sistema.
En la Figura 4.2 se muestra el diagrama de secuencia para la deteccin de una seal

de llamada entrante desde la lnea telefnica. Los aspectos no funcionales cubiertos
en esta fase son los relativos a los eventos externos del sistema. Los eventos externos
se muestran en el Cuadro 4.1 con sus nombres, requisitos temporales y los objetos a
los que involucran.
131
Figura 4.2: Diagrama secuencias del escenario de llamada entrante.
Cuadro 4.1: Tabla de eventos externos
132
La fase de diseo, interaccin con el hardware y asignacin de prioridades se divide

en los aspectos funcionales y los asuntos de tiempo real y dispositivos fsicos. A nivel
de sistema hacemos una estructura lgica de las clases para disear la arquitectura el
sistema que se refina para conseguir una definicin ms precisa del sistema.
Estos modelos se muestran en las Figuras 4.3 y 4.4. En el nivel de sistema de los
aspectos no funcionales hacemos un estudio ms preciso de los objetos fsicos.
Figura 4.3: Diseo de objetos.
133
Figura 4.4: Diseo refinado del sistema de radio.
Este estudio puede producir cambios en el diseo de objetos refinado, los dispositivos
fsicos se modelan mediante dos objetos: un objeto pasivo que modela el dispositivo
fsico y que permite a los dems procesos acceder a sus recursos a travs de
llamadas remotas a procedimientos, y otro objeto activo, correspondiente al
controlador, con un objeto controlador que es el que controla la comunicacin entre el
dispositivo fsico y el resto del sistema. En nuestro sistema, el objeto COMBO modela
el componente fsico del sistema de radio y el objeto DCombo para el controlador. En
la fase de anlisis de planificabilidad, y en funcin de los rboles de tareas y los
tiempos de respuesta de las acciones, se ve que hay eventos externos cuyo tiempo de
respuesta es superior a su plazo mximo de respuesta.
134
Concretamente, esta situacin se produce

porque el objeto DCombo maneja eventos
paralelos, ya que puede haber envo y
recepcin simultneos de mensajes entre la
base y los auriculares, y esta situacin
introduce un tiempo de bloqueo que impide que
el sistema sea panificable. Este
tiempo
de
bloqueo no se produce, por tanto, por un objeto externo que ejecute una accin de
menor
prioridad,
sino por la naturaleza del sistema
que impide que un objeto
responda a dos eventos a la vez. Hay dos formas de conseguir eliminar ese tiempo de
bloqueo en el procesamiento concurrente de los mensajes en ambos sentidos.
Una solucin es la divisin del proceso en dos, ocupndose cada uno de ellos de los
mensajes en un sentido. El inconveniente de esta solucin es que los recursos del
objeto original han de dividirse entre los dos nuevos objetos. Si cada uno de estos
nuevos objetos no necesita acceder a los recursos del otro no hay ningn problema,
pero si alguno de los recursos tiene que ser compartido por ambos objetos, hay que
definir un nuevo objeto pasivo que simplemente acte como contenedor de los
recursos a compartir.
Este objeto seguir las reglas comentadas anteriormente

para este tipo de procesos, solo ser accesible mediante
llamadas remotas a procedimientos y su prioridad vendr
dada por el techo de prioridad de los objetos que acceden
a l. En la Figura 4.5 se muestran los dos objetos nuevos,
DComboEnt
DComboSal,
el
objeto
pasivo,
CmbRecCmp, encargado de encapsular los recursos compartidos que formaban parte

del estado interno del objeto correspondiente al proceso controlador original. Estos
recursos compartidos son la tabla de canales y los canales de transmisin y recepcin.
En las Figuras 4.6 y 4.7 se muestran las respectivas mquinas de estados de los
objetos DComboEnt y DComboSal.
135
Figura 4.5: Especificacin detallada del protocolo de radio.
Figura 4.6: Mquinas de estados del objeto DComboEnt.
Figura 4.7: Mquinas de estados del objeto DComboSal.
136
Se podra pensar en una segunda alternativa, aprovechando las posibilidades de

concurrencia intraobjetos que proporcionan las mquinas de estado de UML con los
estados concurrentes. Los eventos que han provocado el tiempo de bloqueo excesivo
se podran procesar en diferentes regiones de un mismo estado concurrente. La
principal ventaja de esta solucin es que evita la complicacin del diseo, ya que no se
aaden nuevos objetos que no responden a necesidades de los requisitos funcionales,
sino a restricciones no funcionales. Uno de los inconvenientes de esta solucin es que,
si la respuesta a los eventos implica el acceso a los mismos recursos, hace falta
establecer un control de acceso a los recursos para que no se modifiquen
concurrentemente de forma descontrolada. El otro inconveniente radica en si
realmente las regiones de un estado concurrente pueden atender concurrentemente
distintos eventos.
Es posible definir la semntica de las mquinas de estados de tal manera que la

restriccin de ejecucin hasta la finalizacin se aplique concurrentemente a las
regiones ortogonales de un estado compuesto en vez de a la mquina de estados en
su totalidad. Esto permitira relajar las restricciones sobre la socializacin de eventos.
Sin embargo, dicha semntica es muy sutil y difcil de implementar. Por tanto, la
semntica dinmica definida en este documento se basa en la premisa de que un
paso de ejecucin hasta la finalizacin se aplica a toda la mquina de estados e
incluye los pasos concurrentes llevados a cabo por regiones concurrentes de la
configuracin de estados activos.
Una de las tareas ms importantes que hay que desarrollar en los aspectos no
funcionales de la fase de diseo es el estudio de los eventos internos y la realizacin
de la tabla de eventos/transiciones. Distinguimos diferentes modos de operacin y el
anlisis se lleva a cabo en el contexto de cada uno de los modos de operacin. En el
Cuadro 4.2 podemos ver la tabla de eventos/transiciones que contiene todos los
eventos de nuestra aplicacin simplificada. Los nmeros relacionados con el tiempo
son los especificados en los requisitos del sistema y dependen del microprocesador en
el que se instale el software. Estos tiempos fueron suministrados por la empresa
Alcatel.
137
Cuadro 4.2: Tabla de eventos/transiciones
138
Hemos considerado tres modos de trabajo: inactivo, llamada entrante y llamada

saliente. Los eventos concurrentes implicados en los modos funcionales se muestran
en la tabla 4.3
Cuadro 4.3: Tabla de transiciones.

El cuadro 4.4 contiene toda la informacin necesaria para aplicar las tcnicas de
tiempo. En los aspectos no funcionales, obtuvimos un anlisis de tiempo real
preliminar usando las tablas de eventos/transiciones con los diferentes modos
operativos de la fase de diseo. El cuadro 4.5 muestra el anlisis preliminar de tiempo
real para los modos operativos inactivo, llamada entrante y llamada saliente.
Cuadro 4.4: Eventos para los modos operativos inactivo, llamada entrante y
llamada saliente.
139
Cuadro 4.5: Tiempo de respuesta para las acciones de los modos operativos
140
ANLISIS Y DISEO ORIENTADO A OBJETOS

http://glbrtlmb.blogdiario.com/i2006-09/
DESARROLLO DE SOFTWARE PARA SISTEMAS DE TIEMPO REAL BASADO EN

UML, UN ENFOQUE FORMAL BASADO EN METAMODELADO
http://www.biblioteca.uma.es/bbldoc/tesisuma/17155538.pdf
1. En un documento en Word seale y describa el proceso de

diseo de sistemas de tiempo real aplicado a un robot para el
tratamiento de material peligroso.
Envalo a travs de "Diseo de Sistemas".
2. Presente un informe acadmico sobre la propuesta de Altisen

y Sifakis de una metodologa para construir sistemas
planificados restringiendo el funcionamiento de los procesos
para garantizar dos tipos de restricciones: restricciones de
planificabilidad y restricciones sobre los algoritmos.
Envalo a travs de "Altisen y Sifakis".
141
Autoevaluacin
1) Rate-Monotonic Analysis (RMA), proporciona una coleccin de mtodos

cuantitativos para analizar y predecir el funcionamiento:
a. Temporal de los sistemas de tiempo real.
b. Eficiente de los sistemas de tiempo real.
c. Predecible del sistema de tiempo real.
d. Organizado de un sistema de tiempo real.
e. Opcional disponibles en un sistema.
2) La metodologa propuesta en esta seccin est bsicamente dividida en:

a. Cinco fases.
b. Seis fases.
c. Siete fases.
d. Cuatro fases.
e. Tres fases.
3) Durante la fase de diseo los aspectos funcionales del sistema se estudian a

dos niveles:
a. Sistema y cdigos.
b. Cdigos y tecnologas.
c. Estructuras y mtodos.
d. Estados y cdigos.
e. Sistema y objetos.
4) En el aspecto funcional, en la fase de diseo se construye la estructura del

sistema partiendo de los diagramas obtenidos:
a. En la fase de anlisis.
b. En la fase de validacin.
c. En la fase de implementacin.
d. En la fase de configuracin.
e. En la fase de soporte.
5) Respecto a los temas no funcionales, el diseo tiene que capturar cmo los
dispositivos fsicos interaccionan con el sistema. En este sentido, cada
componente fsico tiene que modelarse como:
a. Un atributo.
b. Un objeto.
c. Una clase.
d. Un estado.
e. Software.
142
6) En la fase de evaluacin del rendimiento se usan los modelos de simulacin

para analizar cuantitativamente medidas tales como el:
a. Timeset y el tiempo de configuracin.
b. Timerest y el tiempo de saturacin.
c. Throughput y el tiempo de respuesta.
d. Timefast y el tiempo de simulacin.
e. Time restart y el tiempo de comulacin.
7) El Eole 400 es:

a. Un telfono personal.
b. Un telfono particular.
c. Un telfono cientfico.
d. un telfono inalmbrico.
e. Un telfono tradicional.
8) Es una de las caractersticas instaladas en el software instalado en el

telfono:
a. Responder al toque de la pantalla.
b. Enviar a la casilla de voz si no se contesta en 10 minutos.
c. Mostrar ocupado si no se contesta en 10 minutos,
d. Encriptar y grabar el nmero de telfono.
e. Rellamada automtica al ltimo nmero marcado.
9) Para los sistema de tiempo real se recomienda:

a. Usar claves en las primeras fases y cdigos en la parte final.
b. Usar UML en las primeras fases y SDL en la parte final.
c. Usar cdigos configurados sistemticamente en el software.
d. Aplicar metodologas comunes recomendados al tipo de software.
e. Configurar adecuadamente las funciones del software.
10) Una de las razones principales de la eleccin de SDL es que, gracias a su

semntica, formal y claramente establecida, existen herramientas
automticas como:
a. Tec software.
b. SCI de Tecnologics.
c. Tau de Telelogic.
d. Tau de servicios.
e. Timecode de telefona.
143
Resumen
UNIDAD DE APRENDIZAJE IV:
RMA, proporciona una coleccin de mtodos cuantitativos para analizar y predecir

el funcionamiento temporal de los sistemas de tiempo real. Estos anlisis pueden
ayudar a organizar los procesos y los recursos en el diseo para hacer posible
predecir el funcionamiento del sistema final. Se puede usar UML en las primeras
fases, especificacin y diseo del sistema, y SDL en la parte final, para el diseo
estructural detallado, el disenso de procesos, la implementacin de cdigo y la
simulacin y validacin del sistema.
La metodologa propuesta est bsicamente dividida en cuatro fases Anlisis,

Diseo, Validacin e Implementacin. En cada fase se tienen en cuenta los
aspectos funcionales y no funcionales en dos vistas del sistema separadas, pero
complementarias. Las expresiones usadas para denotar cada fase son diferentes
dependiendo de sobre qu aspecto se desea enfocar en cada vista. El diseo se
realiza bsicamente mediante diagramas de clases y objetos de UML. El diseo
del sistema corresponde a un diseo de alto nivel, que se refina cuanto sea
necesario hasta llegar a un diseo de objetos detallado.
Nivel de objetos (Sistema), se construye la estructura del sistema partiendo de los

diagramas obtenidos en la fase de anlisis. Nivel de objetos (Diseo) se usan los
diagramas de clases y objetos. En el nivel de sistemas el diseo tiene que
capturar cmo los dispositivos fsicos interaccionan con el sistema. En nivel de
objeto est dedicado a disear la interaccin con los dispositivos fsicos.
El Eole 400 es un telfono inalmbrico de la clase CT0 de Alcatel, que admite

mltiples auriculares, con un contestador automtico de estado slido integrado en
la base. Est basado en otros dos productos anteriores CT0, el France Telecom
X1 (para el auricular y el circuito de radio de la base). El software instalado en el
telfono proporciona las siguientes prestaciones principales: Intercomunicacin
entre la base y los auriculares, rellamada automtica al ltimo nmero marcado,
activacin del altavoz durante la comunicacin, encriptacin de la comunicacin
base-auricular y marcacin por pulsos o multifrecuencia.
144
Glosario
ARQUITECTURA: Consiste en la estructura organizacional de un sistema.

ATRIBUTO: Es una parte especfica de una clase. Una propiedad de un tipo
identificada mediante un nombre.
ESTADO: Es una condicin o situacin en la vida de un objeto, durante la cual

satisface una condicin, realiza una actividad o est esperando un evento.
ESTADO ACTIVO: Es un estado con una accin interna y una o ms transiciones

asociadas a la finalizacin de la accin interna.
ESTADO COMPUESTO: Es un estado compuesto por subestados.

EVENTO: En el contexto de un diagrama de estado, un evento es un
acontecimiento que puede disparar una transicin de estados.
EVENTO TEMPORAL: Es un evento que ocurre en un tiempo particular. Puede

ser especificado por medio de una expresin temporal.
MQUINA DE ESTADOS FINITOS (MEF): Es un modelo que describe los aspectos

de control en los sistemas de informacin.
META-METAMODELO: Es un modelo que define el lenguaje para expresar el

metamodelo. La relacin entre meta-metamodelo y metamodelo es anloga a la
relacin entre metamodelo y modelo.
METAMODELO: Es un modelo que define el lenguaje para poder expresar un

modelo.
MODELO: Es una abstraccin semnticamente consistente de un sistema.

REDES DE PETRI: Es un formalismo grfico que permite especificar sistemas
asincrnicos.
SUBESTADO: Es un estado que es parte de un estado compuesto. Un subestado
puede ser concurrente o disjunto.

SUBESTADO CONCURRENTE: Es un subestado que puede tener cabida
simultneamente a otros subestados concurrentes en el mismo estado
compuesto.
TIEMPO: Es un valor que representa un momento en el tiempo, absoluto o
relativo.
UML "UNIFIED MODELING LANGUAGE": Es un lenguaje que permite especificar,
construir, visualizar y documentar los elementos que componen un sistema de
software intensivo.
MSC: Es un lenguaje grfico orientado a objetos que se usa para describir
escenarios, es decir, ejecuciones concretas del sistema.
SDL : Permite expresar mediante mquinas de estados el funcionamiento de las
clases del sistema.
145
Fuentes de Informacin
BIBLIOGRFICAS:
PRESSMAN R., "Ingeniera del Software, un Enfoque Prctico" - Tercera Edicin

- Editorial Mc Graw-Hill - 2007
RUMBAUGH J. Modelado y Diseo Orientado a Objetos. Editorial Prentice
Hall.2010.
BOOCH G. Anlisis y Diseo Orientado a Objetos con Aplicaciones Editorial
Addison-Wesley/Diaz de Santos.2011
PFLEEGER S. Ingeniera de Software, Teora y Prctica, Editorial Prentice
Hall.2008
RUMBAUGH J. El Lenguaje Unificado de Modelado. Manual de Referencia.
Editorial Addison-Wesley.2009
ELECTRNICAS:
Introduccin al modelado de sistemas
http://www.isa.uma.es/C17/Presentaciones%20de%20Clase%20(ppt)/Document%20
Library/INTRODUCION%20AL%20MODELADO%20DE%20SISTEMAS.pdf
Metodologas de desarrollo de software

http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema04.pdf
Desarrollo de software para sistemas de tiempo real basado en UML

http://dialnet.unirioja.es/servlet/tesis?codigo=18353
Metodologa para el diseo de sistemas en tiempo real

http://isa.uniovi.es/docencia/TiempoReal/Recursos/temas/tema7.pdf
146
Solucionario
UNIDAD DE
1. A
UNIDAD DE
APRENDIZAJE 2:
1. A
2. A
2. C
3. E
3. E
4. C
4. A
5. B
5. B
6. B
6. C
7. A
7. D
8. C
8. E
9. D
9. B
10. D
10. D
APRENDIZAJE 1
UNIDAD DE
APRENDIZAJE 3:
UNIDAD DE
APRENDIZAJE 4:
1. A
1. A
2. D
2. D
3. B
3. E
4. C
4. A
5. A
5. B
6. B
6. C
7. C
7. D
8. E
8. E
9. D
9. B
10. E
10. C
147

Desarrollo de Sistemas en Tiempo Real

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Desarrollo de Sistemas en Tiempo Real

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

La asignatura es de carcter terico-prctico. sta,

Comprende Cuatro Unidades de Aprendizaje:

UNIVERSIDAD PRIVADA TELESUP

Estructura de los Contenidos

La competencia que el estudiante debe lograr al final de la asignatura es:

Comprender los elementos prcticos sobre las bases

UNIVERSIDAD PRIVADA TELESUP

ndice del Contenido

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

e) Presentacin de Ideas bsicas y contenidos esenciales de la Unidad:

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

Desarrollo de los Temas

Tema 01: Qu es el Modelado?

En estas otras ramas de las ciencias es tradicional el uso de

Un buen modelo debe tener varias caractersticas:

Debe permitir la abstraccin, para poder obviar detalles irrelevantes en un

Debe usar notaciones que permitan a un lector

UNIVERSIDAD PRIVADA TELESUP

Debe tener una base matemtica o formal que permita la demostracin de

Debe ser significativamente ms fcil y econmico de construir que el sistema final.

Necesidad del modelado

Las pruebas de radiodiagnstico ms avanzadas

UNIVERSIDAD PRIVADA TELESUP

El desarrollo de sistemas informticos es una rama de la ingeniera reciente para la

Los sistemas de tiempo real y su modelado

UNIVERSIDAD PRIVADA TELESUP

Este sistema se encarga de vigilar el funcionamiento de las ruedas del vehculo

Si se producen retrasos o prdidas de imagen o sonido

Interactan directamente con sistemas fsicos. Es muy

UNIVERSIDAD PRIVADA TELESUP

Su funcionamiento depende habitualmente de estmulos

Se desarrollan en arquitecturas fsicas muy variadas, no slo en computadoras

Tienen el requisito no funcional adicional de los plazos temporales de las respuestas.

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

Tema 02: Modelado Formal de Sistemas

Otro grupo es el formado por los mtodos basados en lgicas

Cuando surgieron la mayora de estos mtodos algunas

UNIVERSIDAD PRIVADA TELESUP

Como se pone de manifiesto a continuacin, la mayora de los mtodos descritos han

caractersticas representativas de los sistemas de tiempo real, como la concurrencia, y

Para la mayora de los mtodos que se incluyen han

formalismo sobre el que se han fundamentado y la

UNIVERSIDAD PRIVADA TELESUP

En la lgica se definen las reglas de derivacin adecuadas sobre los constructores

La programacin concurrente, en la que varios procesos se ejecutan

El gran problema de estas tcnicas es que la mayora de sus

UNIVERSIDAD PRIVADA TELESUP

Tcnicas basadas en teora de conjuntos

Una de dichas tcnicas es la notacin Z, la cual est basada

esquemas, patrones de declaraciones y restricciones. El

Una propiedad caracterstica de Z es el uso de tipos.

UNIVERSIDAD PRIVADA TELESUP

En este esquema, indica que la operacin va a modificar el estado del sistema.

El uso de Z en la especificacin de sistemas reales puso de manifiesto que los

Tcnicas basadas en lgebra de procesos

La interaccin entre procesos se hace a travs de la participacin de estos en

UNIVERSIDAD PRIVADA TELESUP

El funcionamiento de los constructores de procesos debe depender exclusivamente

Sequential Processes) es definir la concurrencia mediante la