Desarrollo de Software para Sistemas de Tiempo Real Basado en UML. Un Enfoque Formal Basado en Metamodelado

Desarrollo de Software para Sistemas de Tiempo Real Basado en UML.
Un Enfoque Formal Basado en Metamodelado

Tesis Doctoral Departamento de Lenguajes y Ciencias de la Computacin o Universidad de Mlaga, Espaa a n Presentada por Jos Mar Alvarez Palomo e a
Director: Dr. Manuel D Rodr az guez
D. Manuel D Rodr az guez, Titular de Universidad del Departamento de Lenguajes y Ciencias de la Computacin de la Universidad de Mlaga, o a
Certica que D. Jos Mar Alvarez Palomo, Ingeniero en Informtica por la Unie a a versidad de Mlaga, ha realizado en el Departamento de Lenguajes y Ciencias a de la Computacin de la Universidad de Mlaga, bajo su direccin, el trabajo o a o de investigacin correspondiente a su Tesis Doctoral titulada o
Desarrollo de Software para Sistemas de Tiempo Real Basado en UML. Un Enfoque Formal Basado en Metamodelado
Revisado el presente trabajo, estimo que puede ser presentado al tribunal que ha de juzgarlo, y autorizo la presentacin de esta Tesis Doctoral en la o Universidad de Mlaga. a
En Mlaga, 9 de febrero de 2006 a
Firmado: Manuel D Rodr az guez Titular de Universidad Dpto. de Lenguajes y Ciencias de la Computacin o Universidad de Mlaga a
Muchos aos despus, frente al pelotn de fusilamiento, n e o el coronel Aureliano Buend hab de recordar aquella a a tarde remota en que su padre lo llev a conocer el hielo. o Cien aos de Soledad. Gabriel Garc Mrquez n a a
. . . , when the Queen jumped up and bawled out, Hes murdering the time! O with his head! Alice in Wonderland. Lewis Carroll
Una taza de caf y un t e tulo de doctor no se le niega a nadie, como decimos en la Universidad insiste el joven. La sonrisa etrusca. Javier Sampedro
Es ingenuo pensar que una obra que se desarrolla durante un per odo de varios aos, como es el caso de esta tesis, sea el resultado de un trabajo n individual. Son muchas las cosas que yo, como autor, he incorporado a este trabajo y que las he aprendido no slo de las personas con las que he convivido o en estos aos, sino durante toda mi vida. n Siempre resulta injusto mencionar a unas personas concretas cuando la memoria hace que olvides a otras, quiz tan importantes, as que espero que a aquellos quienes se consideren merecedores de estar en estas l neas y no se encuentren en ellas, no lo tomen como un desaire, sino que se unan a ellas con la seguridad de que estar encantado de que as lo hagan. e Quiero, por tanto, agradecer de manera concreta y dedicar esta obra a las siguientes personas. A mi familia antigua: mi padre, Jos, mi madre, Ra y e mi hermana Beln, por su amor y la educacin que he recibido. A mi familia e o nueva: mi mujer, Carmen, mi hijo, Hctor y mi hija, Carmen, tambin por e e el amor que me dan todos los d y por ensearme a ser una persona mejor. as n A mi director de tesis, Manolo, por la gu que me ha dado todos esa te tiempo y por su paciencia, ampliamente superior a la obligada. A mis compaeros de despacho, Luis y Jos, con los que he pasado tantos d de n e as trabajo agradables, todo un lujo. A mi querido amigo Paco, por su revisin del manuscrito, tan exhaustiva o y precisa. A Andy, Paul y Guiem, por darme la oportunidad de trabajar con ellos en York y hacerme sentir como en casa. Y a Miguel Angel, por sus consejos.
Indice general
1. Introduccin o 1. Modelado de sistemas . . . . . . . . . . . . . . . . . . 1.1. Qu es el modelado? . . . . . . . . . . . . . . e 1.2. Necesidad del modelado . . . . . . . . . . . . 1.3. Los sistemas de tiempo real y su modelado . . 1.4. Objetivos . . . . . . . . . . . . . . . . . . . . 1.5. Aportaciones . . . . . . . . . . . . . . . . . . 2. Modelado formal de sistemas . . . . . . . . . . . . . . 2.1. Mtodos axiomticos . . . . . . . . . . . . . . e a 2.2. Tcnicas basadas en teor de conjuntos . . . e a 2.3. Tcnicas basadas en lgebras de procesos . . . e a 2.4. Lgicas temporales . . . . . . . . . . . . . . . o 3. Tcnicas y herramientas formales de anlisis: Tau . . e a 3.1. Simulacin . . . . . . . . . . . . . . . . . . . . o 3.2. Generacin de cdigo . . . . . . . . . . . . . . o o 3.3. Validacin y vericacin . . . . . . . . . . . . o o 3.4. Comprobacin de modelos . . . . . . . . . . . o 4. Lenguajes grcos de modelado . . . . . . . . . . . . a 4.1. SDL . . . . . . . . . . . . . . . . . . . . . . . 4.2. UML . . . . . . . . . . . . . . . . . . . . . . 5. Metamodelado . . . . . . . . . . . . . . . . . . . . . . 6. Metodolog de desarrollo de sistemas de tiempo real as 6.1. Metodolog estructuradas . . . . . . . . . . as 6.2. Metodolog orientadas a objetos . . . . . . . as 6.3. Metodolog basadas en SDL . . . . . . . . . as 6.4. Metodolog basadas en UML . . . . . . . . . as 6.5. Herramientas automticas de diseo . . . . . . a n ix
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 1 3 4 7 9 14 15 17 19 23 26 26 27 29 30 31 31 39 51 54 54 55 63 66 75
2. Una semntica de acciones para MML a 1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . o 1.1. Los fundamentos del modelo MML . . . . . . . 2. Principios arquitectnicos . . . . . . . . . . . . . . . . o 3. Ncleo dinmico . . . . . . . . . . . . . . . . . . . . . u a 4. Acciones . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1. Conceptos de modelo . . . . . . . . . . . . . . . 4.2. Conceptos de instancias . . . . . . . . . . . . . 5. Acciones primitivas . . . . . . . . . . . . . . . . . . . . 5.1. Accin nula . . . . . . . . . . . . . . . . . . . . o 5.2. Accin de crear un objeto . . . . . . . . . . . . o 5.3. Accin de escritura de un atributo . . . . . . . o 6. Acciones compuestas . . . . . . . . . . . . . . . . . . . 6.1. Accin Secuencial . . . . . . . . . . . . . . . . . o 6.2. Accin Paralela . . . . . . . . . . . . . . . . . . o 7. Ejemplo de ejecucin . . . . . . . . . . . . . . . . . . . o 8. La semntica de acciones en el mbito de UML 2.0 . . a a 8.1. La propuesta adoptada nalmente para UML2.0 8.2. La propuesta enviada por 2U Consortium . . . 8.3. El paquete Behaviour . . . . . . . . . . . . . . 8.4. El paquete Actions . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
77 77 79 80 81 82 84 86 87 88 90 92 95 98 100 101 103 104 105 106 107
3. Modelado de tiempo real de las mquinas de estados de UML125 a 1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 o 1.1. Trabajos relacionados . . . . . . . . . . . . . . . . . . 127 2. Semntica de las mquinas de estados . . . . . . . . . . . . . 131 a a 2.1. La mquina de estados plana . . . . . . . . . . . . . . 132 a 2.2. La mquina de estados con estados compuestos . . . . 138 a 2.3. La mquina de estados con estados concurrentes . . . . 144 a 2.4. La recepcin de un evento . . . . . . . . . . . . . . . . 149 o 3. El tiempo real en las mquinas de estados . . . . . . . . . . . 175 a 3.1. Perl de Planicabilidad, Rendimiento y Especicacin del Tiempo . . . . . . . . . . . . . . . . . . . . . 175 o 3.2. Mecanismos de expresin del tiempo en las mquinas o a de estados de UML . . . . . . . . . . . . . . . . . . . . 196 3.3. Caracter sticas del entorno de tiempo . . . . . . . . . 197 3.4. Problemas de tiempo real . . . . . . . . . . . . . . . . 202 3.5. Extensin del entorno temporal de las mquinas de o a estados . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
4. Metodolog de dise o de sistemas de tiempo real orientada a n a objetos 213 1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 o 1.1. Trabajo relacionado . . . . . . . . . . . . . . . . . . . . 215 2. La metodolog . . . . . . . . . . . . . . . . . . . . . . . . . . 218 a 2.1. Anlisis y especicacin de requisitos de tiempo real . 222 a o 2.2. Diseo e interaccin con dispositivos f n o sicos y asignacin de prioridades . . . . . . . . . . . . . . . . . . . . 223 o 2.3. Evaluacin del rendimiento . . . . . . . . . . . . . . . . 226 o 3. Un caso real: el diseo de un telfono inalmbrico . . . . . . . 227 n e a 3.1. Descripcin de la parte f o sica . . . . . . . . . . . . . . . 228 3.2. Aplicacin de la metodolog . . . . . . . . . . . . . . . 229 o a 5. Conclusiones y trabajo futuro 243
CAP ITULO
Introduccin o
modelo. (Del it. modello). 4. m. Esquema terico, generalmente en forma matemtica, de un o a sistema o de una realidad compleja, como la evolucin econmio o ca de un pa que se elabora para facilitar su comprensin y el s, o estudio de su comportamiento. Diccionario de la lengua espaola. Vigsima segunda edicin. n e o Real Academia Espaola. n
1.
1.1.
Modelado de sistemas
Qu es el modelado? e
La creciente complejidad de los sistemas informticos ha llegado a tal a nivel que aquellos de mayor envergadura son comparables en dicultad y tamao con las grandes obras de otras ramas de la ingenier o la arquitectura. n a Esta complejidad comporta dos cuestiones fundamentales. Por un lado, es dif llegar a construir un sistema tan sosticado, especialmente si no se tiecil ne experiencia previa ni informacin bsica sobre su composicin. Por otro o a o lado, tambin es dif establecer a priori si el sistema funcionar correctae cil a 1
1. Modelado de sistemas
mente una vez construido, lo que es especialmente grave en aquellos sistemas cuyo coste es muy elevado, o son especialmente dif ciles de modicar 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 caracter a sticas y el funcionamiento del sistema. El uso de modelos es una herramienta bsica para tratar esta complejidad, a ya que permite hacer una rplica ms simple del sistema, de la que eliminan e a detalles que no son fundamentales, obteniendo as un objeto de estudio ms a sencillo de entender, manejar y que permite hacer predicciones sobre aspectos importantes del sistema real. Un buen modelo debe tener varias caracter sticas [109]: Debe permitir la abstraccin, para poder obviar detalles irrelevantes en o un momento dado para el anlisis de ciertas propiedades concretas del a sistema. Adems el grado de abstraccin debe ser variable y as permitir a o que el anlisis sea a mayor o menor nivel de detalle, segn sea necesario. a u Debe usar notaciones que permitan a un lector humano entender el sistema. Si la notacin usada es oscura o dif de entender el modelo o cil ser de poca utilidad, incluso para sistemas con un m a nimo de complejidad. Debe mostrar las mismas caracter sticas que el sistema nal, al menos en aquellos aspectos que quieran ser estudiados o analizados antes de la construccin del sistema nal. o Debe tener una base matemtica o formal que permita la demostraa cin de propiedades, con el n de poder predecir el funcionamiento del o sistema una vez construido.
Cap tulo 1. Introduccin o
Debe ser signicativamente ms fcil y econmico de construir que el a a o sistema nal.
1.2.
Necesidad del modelado
Aprovechando los avances en la construccin de ordenadores con cada o vez mayor capacidad de clculo y de almacenamiento de informacin, los a o sistemas informticos son cada vez ms grandes, se aplican a ms campos y a a a se depositan en ellos responsabilidades mayores. Esta situacin provoca una o mayor exigencia sobre los sistemas informticos. a No slo han de ser sistemas que proporcionen un resultado correcto, sino o que tienen otra serie de requisitos entre los que se pueden citar la obligacin o de ser sistemas seguros o responder satisfactoriamente frente a situaciones no esperadas o de error. Se puede ilustrar esta situacin usando ejemplos de la o aplicacin de la informtica a un campo concreto como la sanidad. Las prueo a bas de radiodiagnstico ms avanzadas hoy en d como la tomograf axial o a a, a computerizada o la resonancia magntica estn controladas por ordenador, e a de cuya correcta programacin depende la exactitud de las pruebas. Ms delio a cado an es el ejemplo de algunas terapias antitumorales en las que un equipo u informtico controla la exposicin de un paciente a istopos radioactivos. En a o o los aos ochenta, cuatro personas murieron por haber sido sometidos a una n dosis demasiado alta por culpa de un error informtico [76]. En los sistemas a sanitarios tambin se han introducido complejos sistemas informticos en el e a a rea de la administracin y se usan grandes bases de datos para almacenar, o entre otros datos, los historiales cl nicos de los pacientes. Estas aplicaciones tienen grandes ventajas, ya que permiten a los mdicos un acceso inmediato, e desde distintos lugares y, posiblemente, simultneo, a la informacin histria o o ca de pacientes a los que pueden no haber tratado antes. Sin embargo, los
requisitos de seguridad y de condencialidad son una condicin bsica para o a 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 a cuidados intensivos han de ser capaces de seguir funcionando correctamente incluso si, por ejemplo, se produce una prdida momentnea de suministro e a elctrico. e Es, por tanto, clara la necesidad de construir sistemas informticos libres a de errores y que respondan a los requisitos con que se pensaron. El desarrollo de sistemas informticos es una rama de la ingenier reciente para la que an a a u no hay tcnicas de desarrollo que conciten la aprobacin generalizada de los e o 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 a a a acuerdo es en la necesidad, y en los benecios que conlleva, el usar modelos para guiar la construccin de los sistemas reales, de forma que se puedan o analizar las propiedades del sistema nal antes y durante su desarrollo. Diferentes autores han propuesto mltiples modelos distintos, inuenciau dos por el tipo de sistemas desarrollaban en ese momento, por el campo de aplicacin para el que se propon o an, etc. An hoy en d la diversidad es u a, grande y se est lejos de la unanimidad, o de la universalidad de los modelos, a por lo que se sigue investigando ampliamente en el tema.
1.3.
Los sistemas de tiempo real y su modelado
Los sistemas de tiempo real son una clase concreta de sistemas informtia cos que se pueden denir 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 e plazo, aunque sea correcto, es un dato invlido, que incluso puede provocar a
que el sistema falle en su conjunto. Uno de los ejemplos ms habituales de los sistemas de tiempo real son a los sistemas de control, en los que un sistema computerizado se encarga de controlar el funcionamiento de otro sistema, informtico o no. Por ejemplo, a en los automviles actuales se encuentran multitud de estos sistemas, como o el sistema de antibloqueo de los frenos (ABS). Este sistema se encarga de vigilar el funcionamiento de las ruedas del veh culo durante la frenada. Si se bloquean, se liberan momentneamente las ruedas para que sigan girana do y no se deslicen. En cuanto las ruedas han conseguido un giro m nimo, se vuelve a actuar sobre el freno para volver a pararlas. En este ejemplo se muestran algunas de las caracter sticas habituales de estos sistemas: se monitorizan unos datos que llegan del entorno, se procesan y, como resultado, se acta sobre dicho entorno. Si la respuesta llega tarde y las ruedas han u empezado a patinar, el desbloqueo de los frenos puede ser intil o incluso u 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 o a con una determinada velocidad y calidad a los otros extremos, incluyendo la consideracin de posibles errores en el canal de comunicacin. Si se proo o ducen retrasos o prdidas de imagen o sonido momentneas, es posible que e a se consiga mantener una calidad suciente en la conferencia, pero para eso es necesario que la mayor de la informacin llegue correctamente y con un a o retraso m nimo. Una de las clasicaciones de los sistemas de tiempo real distingue entre sistemas duros (hard real-time systems), en los que ningn dato se puede u producir fuera de plazo, y blandos (soft real-time 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 caracter sticas propias que hace que su desarrollo sea an ms dif que el de la mayor del resto de los u a cil a sistemas informticos: a Son sistemas inherentemente concurrentes en los que hay varios ujos de control ejecutndose simultneamente e interaccionando, accediendo a a a recursos comunes y comunicndose y sincronizndose entre ellos. El a a desarrollo de sistemas concurrentes es ms complejo por la posibilidad a de problemas adicionales como el bloqueo, la inversin de prioridades, o etc. Interactan directamente con sistemas f u sicos. Es muy habitual encontrar sistemas que tienen una relacin a muy bajo nivel con dispositivos o f sicos para lectura de datos para monitorizar los sistemas controlados y para escritura de datos para su control. Su funcionamiento depende habitualmente de est mulos procedentes del entorno (se suelen clasicar dentro de los llamados sistemas reactivos, que actan dando respuesta a un est u mulo exterior). La frecuencia de los est mulos exteriores es unas veces peridica, otras sigue una distribucin o o de probabilidad y, en ocasiones, es desconocida. Se desarrollan en arquitecturas f sicas muy variadas, no slo en ordenao dores tradicionales, sino en otros dispositivos electrnicos autnomos, o o desde veh culos a telfonos mviles, pasando por un amplio abanico. A e o este tipo de sistemas de tiempo real se les llama empotrados (embedded real-time systems). Es habitual que esos sistemas empotrados impongan fuertes restricciones en varios aspectos. Por un lado, los recursos
f sicos con los que se cuenta, como memoria y capacidad de clculo, a suelen estar muy ajustados, lo que incide en una mayor dicultad para encontrar una solucin viable. Los recursos software, como bibliotecas o de funciones o sistemas operativos, pueden tambin estar limitados, ya e que es habitual la ausencia de versiones para estos entornos no estndaa res. Tienen el requisito no funcional adicional de los plazos temporales de las respuestas. Este requisito hace necesario el anlisis de la planicaa bilidad del sistema, que establece si se pueden cumplir o no los plazos temporales y, si no se puede, cules son los que fallan. a Estas particularidades de los sistemas de tiempo real impiden, o limitan, que los modelos y metodolog de desarrollo de sistemas informticos en as a general se puedan aplicar a los sistemas de tiempo real o, al menos, que sean sucientes. De aqu surge la necesidad de complementar modelos generales o desarrollar otros nuevos para tener en cuenta las caracter sticas adicionales que presentan los sistemas de tiempo real.
1.4.
Objetivos
El objetivo fundamental de esta tesis es el desarrollo de una metodolog a que integre modelos que permitan tener en cuenta las caracter sticas propias de los sistemas de tiempo real para llevar a cabo el anlisis de los requisitos a no funcionales y para construir sistemas correctos teniendo en cuenta las limitaciones expuestas en la seccin anterior. o Para ello no se ha partido de cero, sino que se han estudiado metodolog as y mtodos ya propuestos tanto para sistemas informticos en general como e a las espec cas para sistemas de tiempo real. En ambos casos se ha intentado
identicar, en primer lugar, cules son las virtudes y la utilidad de cada a una de ellas, cules son sus puntos fuertes y las ideas o herramientas que son a utiles en este contexto. Lo que se ha contrastado es que las metodolog para as sistemas generales son una buena base sobre la que partir y que incorporan conceptos ms nuevos, pero que adolecen, como es de esperar, de especicidad a para resolver problemas como el anlisis de planicabilidad, la interaccin con a o los dispositivos f sicos o la concurrencia del sistema. Por otro lado, las metodolog de desarrollo de sistemas de tiempo real as existentes ofrecen herramientas para el estudio de los requisitos propios de estos sistemas, pero son ms dif a ciles de aplicar o no incorporan el uso de los modelos ms en uso actualmente como los modelos grcos. a a Se ha intentado, por tanto, desarrollar una metodolog que integre claa ramente y como elementos de primer nivel los aspectos particulares de los sistemas de tiempo real junto con aquellos aspectos comunes a los sistemas generales. Con ese objetivo se ha hecho uso de experiencias concretas de desarrollo de sistemas de tiempo real industriales, se han identicado los principales puntos dbiles de las metodolog genricas y se han propuesto e as e las modicaciones necesarias para la integracin adecuada. o Tambin ha sido necesaria la modicacin de herramientas de modelado e o ya existentes, concretamente las mquinas de estados del Lenguaje Unicado a de Modelado (Unied Modeling Language, UML, [24]), que son apropiadas para el desarrollo de sistemas reactivos, como lo son los de tiempo real, pero que no incorporan en su denicin original el tratamiento del tiempo que es o necesario para el anlisis de la planicabilidad o el rendimiento del sistema. a Asimismo, se ha denido una nueva teor para proporcionar una base formal a a la semntica de algunas de las herramientas usadas. Concretamente, tanto a las mquinas de estados de UML como las acciones subyacentes no cuentan a
con una semntica formal en la norma de denicin. a o
1.5.
Aportaciones
Las aportaciones fundamentales de esta tesis se pueden dividir en tres, cada una expuesta en uno de los siguientes cap tulos: denicin de una semntio a ca formal para las acciones de UML, denicin de una semntica y adaptacin o a o para la denicin de sistemas de tiempo real de las mquinas de estados de o a UML y denicin de una metodolog de desarrollo de sistemas de tiempo o a real en la que se hace especial hincapi en la s e ntesis homognea de aspectos e funcionales y no funcionales del desarrollo en cada una de las fases. Semntica de acciones a UML, como se explica en secciones posteriores, es un conjunto de lenguajes de modelado, cada uno de los cuales se adecua a una fase o a un aspecto del desarrollo del sistema. Algunos de los lenguajes, o tipos de diagramas, se encargan de denir aspectos estticos del sistema, como los diagramas de a casos de uso, los de clases y objetos o los de despliegue. En estos diagramas se muestra la relacin estructural entre las diferentes partes en las que se dio vide el sistema. El resto de los diagramas especican aspectos dinmicos del a sistema, cmo va evolucionando ste a medida que pasa el tiempo y se van o e ejecutando las acciones que componen la respuesta del sistema a las entradas de datos. Estas acciones son el concepto fundamental de la semntica dinmica. a a Sin embargo, en la denicin de la norma de UML no son desarrolladas en o amplitud, sino que, posteriormente, se ha creado una extensin de la norma o espec ca para su denicin, la semntica de acciones de UML. o a Sin embargo, tanto ni la norma de UML [88] ni la semntica de acciones a [4] incluyen una semntica formal de los elementos ni de los diagramas. Los a
10
autores de la norma deenden esa posicin argumentando que no hay una o peticin amplia de la comunidad de usuarios de UML y slo ofrecen una o o semntica informal basada en lenguaje natural. No obstante, nosotros pena samos que, como se detall en secciones anteriores, una de las caracter o sticas bsicas de un buen modelo es la posibilidad que ofrece de analizar y vericar a el cumplimiento, o no, de ciertas propiedades. Para que esta vericacin se o pueda hacer matemticamente y ofrezca garant absolutas, el modelo del a as sistema debe tener una base matemtica que permita hacer ese anlisis. a a Otros autores han denido semnticas alternativas para las acciones basndoa a se en distintos modelos formales ya existentes, pero la comunidad de creadores de UML es muy reacia al uso de formalismos matemticos de dif a cil comprensin ya que, razonan, los ingenieros que deben usarlos para vericar o los sistemas no son expertos en matemticas y eso les produce un rechazo a que acaba por hacer impopular su uso. En esta tesis hemos intentado tener en cuenta dicha limitacin y hemos optado por un modelo matemtico que o a debe ser ms comprensible y cercano a los desarrolladores, un metamodelado a basado en los conceptos de clase y objeto como nociones bsicas sobre el que a se construye la semntica. a La semntica ocial de UML tambin est basada en este tipo de metaa e a modelado en el que los conceptos ms concretos estn relacionados con otros a a ms abstractos de un nivel superior. No obstante, esta semntica slo explica a a o de manera formal la parte estructural de las relaciones entre las diferentes clases, mediante diagramas de clases y haciendo uso del lenguaje funcional OCL para aadir restricciones no expresables en los anteriores diagramas. n La semntica que proponemos no se queda en la parte estructural, sino a que incluye la parte dinmica. La semntica se basa en una distincin funa a o damental entre los conceptos de la sintaxis abstracta y sus correspondientes
11
conceptos en el dominio semntico. La semntica se establece mediante las a a relaciones apropiadas entre elementos de ambos conjuntos. Una segunda distincin se hace entre los conceptos semnticos y su representacin grca. o a o a Basndonos en esta semntica de metamodelo hemos denido un conjunto a a de acciones m nimo que pueda servir de base a la denicin de conjuntos o ms amplios en funcin de las necesidades de cada tipo de sistema. Este a o conjunto de acciones incluye, por ejemplo, acciones simples, secuenciales y concurrentes. El resultado de este trabajo ha sido publicado en [16].
Semntica y adaptacin de las mquinas de estados de UML a o a Las mquinas de estados son un modelo adecuado para reejar la naturaa leza reactiva de los sistemas de tiempo real, que esperan la ocurrencia de un evento externo, reaccionan frente a l ejecutando una serie de acciones, que e posiblemente incluya la generacin de otros eventos, y vuelven a quedarse en o otro estado estable de espera. Las mquinas de estados de UML estn basadas en los statecharts de a a Harel [57] y tienen un conjunto muy rico de operaciones y recursos. Son mquinas que se pueden denir jerrquicamente, expandiendo un estado a a compuesto en otros estados ms simples. Permite la ejecucin concurrente a o de varias l neas de control, la ejecucin de actividades durante el tiempo que o la mquina permanece estable en un estado, o la ejecucin de transiciones a o que permitan salir o entrar de mltiples estados simultneamente. u a En primer lugar se ha especicado una semntica formal para un suba conjunto completamente funcional de las mquinas de estados siguiendo la a misma estrategia que con la semntica de acciones, el metamodelado separana do los conceptos de la sintaxis abstracta, el dominio semntico y la relacin a o entre ambos a travs de asociaciones semnticas. e a
12
En segundo lugar se ha analizado la capacidad y las limitaciones para expresar propiedades de tiempo real y se han propuesto las extensiones necesarias para poder expresar dichas propiedades y requisitos evitando las anomal frecuentemente relacionadas con estos sistemas como, por ejemplo, as la inversin de prioridades. o
Metodolog de desarrollo de sistemas de tiempo real a El uso de las metodolog orientadas a objetos junto con los mtodos de as e descripcin formal se han revelado como una forma prometedora de tratar o la complejidad de los sistemas de tiempo real actuales, altamente complejos. Estas metodolog estn actualmente bien soportadas por un conjunto de as a herramientas que permiten la especicacin, simulacin y validacin de los o o o aspectos funcionales de estos sistemas. No obstante, la mayor de estas metodolog no tienen en cuenta los a as aspectos no funcionales tales como la interaccin con los dispositivos f o sicos y las restricciones de tiempo real, que son especialmente importantes en el contexto de este tipo de sistemas. En esta tesis presentamos una metodolog que se basa en la combinacin de otras notaciones y metodolog a o as (UML, OCTOPUS, etc.), junto con la integracin de tcnicas de anlisis de o e a planicabilidad en el contexto de tcnicas de descripcin formal. e o La metodolog presta especial atencin a la transicin del modelo de a o o objetos al modelo de tareas, teniendo en cuenta aspectos de tiempo real y de integracin con los dispositivos f o sicos. En esta tesis se ha denido un conjunto reducido de acciones, pero que consideramos sucientemente ilustrativo de la viabilidad del mtodo de trae bajo propuesto. Igualmente, para las mquinas de estados slo se ha denido a o un subconjunto de todas las propiedades que incluyen las mquinas denidas a
13
en UML. Tambin en este caso pensamos que el trabajo desarrollado es lo e bastante amplio como para dejar clara su capacidad.
En ambos casos, por tanto, queda an por denir en nuestro modelo una u semntica formal para parte de la norma UML, tanto en el caso de las accioa nes, cuyo espectro es ms amplio en el perl de la semntica de acciones, como a a en el caso de las mquinas de estados, algunas de cuyas caracter a sticas, como las actividades o la ejecucin concurrente de acciones en las transiciones, no o han sido incluidas en este modelo.
Otro aspecto fundamental que falta por desarrollar es una mayor integracin de ambos conceptos con los dems diagramas especicados en UML, o a como puede ser la relacin entre las mquinas de estados y sus clases asociao a das o entre esas mismas mquinas de estados y diagramas dinmicos, como a a los diagramas de secuencia que deben representar escenarios de ejecuciones concretas en el entorno de sistemas compuestos por objetos cuyo funcionamiento viene denido por mquinas de estados. a
En el caso de la metodolog aunque ha sido usada para el desarrollo a, de sistemas reales, como el del un telfono inalmbrico, ser aconsejable un e a a uso ms amplio y variado para comprobar la adecuacin de las actividades a o planteadas para el desarrollo de estos sistemas y para ir modicando aquellos aspectos que sean completamente satisfactorios. Tambin es necesario e conseguir herramientas que permitan la ejecucin automtica de los anlio a a sis incluidos en la metodolog bien implementando herramientas nuevas o a, adaptando las ya existentes para incluir dichos anlisis. a
Los resultados de este cap tulo han sido publicados en [10] y [15].
14
2. Modelado formal de sistemas
Trabajo relacionado En [8], [9], [11], [12], [13], [117] y [14] se estudia en profundidad la adecuacin de SDL para el desarrollo de sistemas de tiempo real y se proponen o extensiones que permiten superar sus carencias y realizar anlisis de los rea quisitos temporales. SDL cuenta con ciertas ventajas frente a las mquinas a de estados de UML: fue pensado para sistemas de telecomunicacin y dispoo ne de una semntica formal subyacente que permite analizar propiedades del a sistema.
2.
Modelado formal de sistemas

Son numerosos los distintos mtodos de modelar sistemas informticos e a
que han surgido desde los aos sesenta. Algunos de ellos son formales porque n incorporan un formalismo matemtico subyacente que permite derivar de a manera able propiedades de los sistemas modelados. Algunos de esos mtodos usan como base la lgica de predicados de prie o mer orden, como los trabajos de C.A.R. Hoare [58] y E.W. Dijkstra [37, 38]. Hay otros que se basan en la teor de conjuntos, como Z [115], B [3] y VDM a [66], para describir los cambios de estados de los datos del sistema. Otros se basan en lgebras de procesos, como CSP [59], CCS [81] o LOTOS [60]. a Otro grupo es el formado por los mtodos basados en lgicas modales, genee o ralmente lgicas temporales, que permiten modelar la evolucin del estado o o del programa en el tiempo en funcin de la ocurrencia de eventos o de la ejeo cucin de las acciones. Por su parte, otros mtodos, como las redes de Petri o e [93], SDL [61], los statecharts [57] o las mquinas de estados de UML [102] a estn basados en mquinas de estados. Estos mtodos cuentan como ventaja a a e con su expresin grca, que los hace ms asequibles a los desarrolladores y o a a
15
son especialmente adecuados para modelar sistemas reactivos. Cuando surgieron la mayor de estos mtodos algunas tcnicas de proa e e gramacin, como la orientacin a objetos, no estaban tan extendidas por o o lo que las metodolog no ofrec apoyo para desarrollos basados en estos as an paradigmas. Posteriormente han aparecido extensiones o actualizaciones de algunos de estos mtodos que s tienen en cuenta la orientacin a objetos. e o Igualmente ha ocurrido con la especicacin de requisitos no funcionales, o como los requisitos de tiempo, el rendimiento o aspectos de seguridad. Como se pone de maniesto a continuacin, la mayor de los mtodos o a e descritos en las siguientes secciones han sido desarrolladas inicialmente para modelar sistemas en los que no se ten en cuenta requisitos relacionados an con el tiempo, por lo que no ofrec mecanismos adecuados para expresar an propiedades temporales ni realizar anlisis de estos requisitos y que no eran a vlidas para modelar y analizar sistemas de tiempo real. Algunas de ellas, a adems, presentaban deciencias para expresar otras caracter a sticas representativas de los sistemas de tiempo real, como la concurrencia, y analizar propiedades relacionadas con ella, como la sincronizacin, env de mensajes o o o ausencia de interbloqueo. Para la mayor de los mtodos que se incluyen a e han surgido ampliaciones que incluyen herramientas para especicar propiedades temporales y analizar el cumplimiento de los requisitos temporales. Estas ampliaciones son muy variadas, en funcin del formalismo sobre el que o se han fundamentado y la facilidad y potencia que se hayan conseguido para el objetivo de cubrir los aspectos temporales del sistema.
2.1.
Mtodos axiomticos e a
La axiomatizacin de los lenguajes de programacin ha sido el primer o o paso en la formalizacin del diseo de los sistemas informticos. Los primeo n a
16
ros trabajos elaborados para el desarrollo metdico de programas basndose o a en formalismos matemticos son los de C.A.R. Hoare [58] y E.W. Dijkstra a [38]. En ambos trabajos se usa la lgica de predicados de primer orden. Las o frmulas de estas lgicas de programacin son las tripletas, que constan de o o o una precondicin, un programa y una postcondicin ({P} S {Q}). La precono o dicin y la postcondicin son predicados lgicos sobre el estado del programa. o o o 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 o S, la precondicin P es cierta y, si acaba el programa, la postcondicin Q o o tambin es cierta. e En la lgica se denen las reglas de derivacin adecuadas sobre los conso o tructores bsicos de la programacin secuencial secuencia, seleccin e itea o o racin que permiten comprobar la validez de las tripletas. Las propiedades o que se comprueban se 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 vlido. Por ejemplo, a un bucle sin n no cumple la propiedad de viveza de acabar. La tcnica de e Dijkstra va un paso ms all y propone mtodos para la construccin de proa a e o gramas de manera que est garantizado el cumplimiento de las propiedades e consideradas. En particular, dene reglas para construir bucles y sentencias de seleccin correctos. o La programacin concurrente, en la que varios procesos se ejecutan sio multneamente compitiendo por recursos comunes, presenta nuevas instruca ciones y situaciones, como la comunicacin y la sincronizacin entre los proceo o sos. Las lgicas de programas se han ampliado para los lenguajes concurrentes o incluyendo nuevas reglas de inferencia para las nuevas instrucciones, como la de ejecucin en paralelo o la de espera. o
17
Entre las propiedades especiales que se han de analizar para los programas concurrentes estn la ausencia de bloqueo (deadlock ), de esperas indenidas, a (livelock ) y de postergacin indenida de procesos (starvation). Para ello o se han de hacer nuevas suposiciones sobre el entorno de ejecucin, como la o naturaleza del planicador, si es c clico o si soporta interrupciones, y sobre su imparcialidad (weak fairness y strong fairness). El gran problema de estas tcnicas es que la mayor de sus usuarios e a potenciales las encuentra extremadamente dif ciles de aplicar en la prctica, a lo que se traduce en una imposibilidad econmica de aplicarlas a desarrollos o reales en la industria. Esta dicultad se ha visto incrementada por la falta de herramientas que permitieran aplicar las tcnicas de forma automtica en e a sistemas del tamao y complejidad habituales en las aplicaciones actuales. n
2.2.
Tcnicas basadas en teor de conjuntos e a
La especicaciones basadas en la teor de conjuntos se caracterizan pora que el estado del programa se expresa de manera expl cita mientras que el funcionamiento del programa est impl a cito. 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 lgebras de procesos dee a nen de manera expl cita el funcionamiento del sistema y es el estado el que est impl a cito. Una de dichas tcnicas es la notacin Z ([115, 95, 120]), la cual est basada e o a en la teor de conjuntos y la lgica matemtica. Los objetos matemticos a o a a y 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 e usarse para describir propiedades del sistema y para razonar sobre posibles
18
renamientos del diseo. n Una propiedad caracter stica de Z es el uso de tipos. Cada objeto del lenguaje matemtico tiene un tipo unico. Aunque Z es un lenguaje de espea cicacin formal, las especicaciones tambin incluyen lenguaje natural. Los o e modelos construidos en Z se pueden renar, obteniendo otro modelo coherente con el anterior, pero de mayor nivel de detalle. Z est pensado para a describir las caracter sticas funcionales del sistema y las caracter sticas no funcionales como usabilidad, rendimiento o abilidad, quedan fuera de su ambito. Para ilustrar algunas de las caracter sticas bsicas de Z, se va a especicar a un sistema muy simple en el que se anotan y recuerdan fechas de cumpleaos. n [N OM BRE, F ECHA] LibroCumpleanyos = [conocidos : PN OM BRE; cumple : N OM BRE F ECHA| conocidos = dom cumple] En este esquema se han denido los tipos que se van a usar N OM BRE y F ECHA, el conjunto de nombres cuyo cumpleaos se sabe (conocidos) n y una funcin parcial que asocia ciertos nombres con fechas (cumple). La o restriccin nal establece una forma de calcular conocidos, como el dominio o actual de la funcin cumple. o El siguiente esquema dene una operacin que modica el espacio de o estados denido en el anterior. IncluirCumple = [nombre? : N OM BRE; f echa? : F ECHA| nombre? conocidos; cumple = cumple nombre? f echa?] / En este esquema, indica que la operacin va a modicar el estado del o sistema. nombre? y f echa? son los nombres de los argumentos de la operacin. Como precondicin el nombre de entrada no puede tener una fecha o o asociada. La otra precondicin indica que, tras la ejecucin, el estado de la o o
19
funcin parcial cumple (denotado por cumple ) var como se indica en ese o a predicado. A partir de esta especicacin se pueden demostrar propiedades del siso tema. Por ejemplo, el nuevo nombre pasa a formar parte de los conocidos: conocidos = conocidos nombre?. El uso de Z en la especicacin de sistemas reales puso de maniesto que o los mecanismos de estructuracin disponibles hasta el momento (principalo mente los esquemas) no eran sucientes para estructurar de manera adecuada aplicaciones de gran tamao. n Para mejorar esta deciencia, diversos grupos han propuesto alternativas en las que se integra la losof de la orientacin a objetos en Z [116]. En a o 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 n o los elementos habituales en la orientacin a objetos (clases, objetos, mtodos, o e . . . ).
2.3.
Tcnicas basadas en lgebras de procesos e a
Los mtodos basados en lgebras de procesos modelan la interaccin cone a o currente entre procesos secuenciales. Todas siguen unos mismos principios bsicos: a La interaccin entre procesos se hace a travs de la participacin de o e o stos en eventos. Los eventos se suelen considerar atmicos (acciones e o indivisibles). En el modelo general, no est limitado el nmero de proa u cesos que pueden interactuar en un mismo evento. Todo evento se considera una interaccin entre procesos, con lo que se o consigue un modelo homogneo. Por ejemplo, escribir un valor en un e
20
registro es un evento en el que interaccionan el proceso que est escria biendo 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 e estos constructores estn: conjuncin, disyuncin, encapsulacin, sea o o o cuenciacin y simultaneidad. La diferencia entre ellos est los puntos o a de sincronizacin que fuerza en los procesos. o CSP La idea bsica del lenguaje CSP (Communicating Sequential Processes) a [59] es denir la concurrencia mediante la comunicacin de procesos que o tienen un funcionamiento interno secuencial y se comunican y sincronizan a travs de unos canales restringidos, de forma que cada proceso slo tiene e o acceso a sus datos locales. El proceso es el elemento bsico de CSP y denota el a patrn de funcionamiento de una entidad. Cada proceso puede involucrarse o en un conjunto concreto de eventos. Un proceso se dene recursivamente, P = (e Q), donde el proceso P consta de la ejecucin del evento e y, posteriormente, la ejecucin del proceso o o Q. Se pueden concatenar acciones que se van a ejecutar secuencialmente. Por ejemplo, s:(e1 e2 e3 e4 P ). Hay operadores de seleccin (|) o y de concurrencia ( ). Cuando los procesos se ejecutan en paralelo estn a restringidos a la sincronizacin en eventos comunes. o Dos procesos se comunican datos sincronizndose a travs de los canaa e les, que son mecanismos de comunicacin unidireccionales y punto a punto. o Cuando un proceso ejecuta un evento de comunicacin de salida mediante la o operacin !, escribe un dato en el canal de comunicacin y otro proceso debe o o sincronizarse con l ejecutando simultneamente un evento de entrada sobre e a
21
el mismo canal mediante la operacin ?, en la que se lee el dato presente en o el canal. Con esos elementos bsicos, se puede especicar un sumador que a reciba dos nmeros por diferentes canales y los descarte tras transmitir la u 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 lgebras de procesos y a a su modelo ms simple es el modelo de trazas. Cada posible patrn de funa o cionamiento de un proceso de denota mediante una secuencia de eventos, llamada traza. En el modelo de trazas slo se pueden especicar propiedao des 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 o n 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. o Entre los nuevos operadores se encuentran la espera, que modela un lapso de tiempo en el que el proceso no hace nada, el prejo con retraso, el timeout y la interrupcin temporizada. o LOTOS LOTOS (Language Of Temporal Ordering Specication) [60] fue desarrollado por la ISO para la especicacin formal de sistemas distribuidos o abiertos. La parte de funcionamiento de LOTOS est basada en el concepto a de accin atmica e instantnea. Si se precisa modelar acciones que tarden o o a tiempo, se modela una accin de inicio y otra de n. o
22
Un sistema en LOTOS est constituido por subsistemas que se ejecutan a concurrentemente e interaccionan entre s Los subsistemas pueden, a su vez, . estar compuestos por otros subsistemas ms simples formando una jerarqu a a. La composicin paralela de estos subsistemas se hace de una manera muy o simple: dos procesos interactan cuando ejecutan una accin sobre un mismo u o punto de interaccin (gates). En esta sincronizacin pueden intercambiar o o informacin. o El funcionamiento de un sistema se dene mediante expresiones de funcionamiento como stop, exit, la composicin secuencial (;) y la eleccin ([]). o o Se puede hacer uso de la recursin para denir el comportamiento de un subo sistema. Hay varios operadores para componer en paralelo los subsistemas denidos: composicin concurrente sin sincronizacin (|||), sincronizacin o o o total (||) y sincronizacin selectiva (|[...]|). Un concepto fundamental o en la composicin jerrquica de subsistemas es el ocultacin. El operador o a o hide permite ocultar acciones de manera que ninguna otra accin de otro o subsistema se puede sincronizar con ella. E-LOTOS (Enhancement to LOTOS ) [43] es una extensin de LOTOS o que incorpora novedades como el concepto de tiempo cuantitativo, denicin o de datos con un mtodo parecido a la programacin funcional, modularidad, e o nuevos operadores para aumentar la potencia expresiva del lenguaje y algunas instrucciones habituales de los lenguajes imperativos de programacin. o RT-LOTOS (Real Time LOTOS ) [34] es otra extensin de LOTOS proo porciona 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 o accin observable es accesible desde el entorno. o
23
2.4.
Lgicas temporales o
Las lgicas temporales permiten expresar el funcionamiento de sistemas o software en trminos de frmulas lgicas, que incluyen restricciones temporae o o les, eventos y relaciones entre ambos. La capacidad expresiva de estas lgicas o ha ido creciendo y muchas de ellas son capaces de especicar adecuadamente sistemas reactivos aunque no todas sirven para especicar sistemas de tiempo real [21]. Las lgicas temporales son una clase particular de lgicas modales en las o o que el conjunto de mundos posibles representa los instantes de un dominio temporal. Las ms usadas en la especicacin de sistemas software son exa o tensiones de lgicas de predicados de primer orden. Generalmente se aaden, o n 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. n Para usar las lgicas temporales en la especicacin de sistemas de tiempo o o real, stas han de ser capaces de expresar las restricciones temporales, las e cuales se pueden dividir en dos grandes grupos: (i) eventos y ordenacin de o eventos y (ii) restricciones temporales cuantitativas. Para la especicacin y o anlisis de sistemas de tiempo real, en los que se necesita una cuanticacin a o de las propiedades temporales, hace falta una mtrica del tiempo. Una forma e t pica de hacerlo es deniendo operadores acotados en el tiempo. Por ejemplo, se puede denir un operador que arme que una frmula es siempre cierta o entre los instantes 4 y 7:
[4,7] A
PTL (Propositional Temporal Logic) [94] extiende la lgica proposicioo nal introduciendo los operadores temporales siempre en el futuro, alguna vez en el futuro, a continuacin y hasta. Las proposiciones describen relaciones o
24
temporales entre estados. PTL es una lgica basada en eventos y no proo porciona mtrica para el tiempo. Es especialmente adecuada para sistemas e reactivos o basados en eventos como las mquinas de estados, pero no tanto a para sistemas de tiempo real. BTTL (Branching Time Temporal Logic) [22] es una extensin de PTL o en la que el modelo de tiempo pasa de ser lineal a ser ramicado en el futuro, con lo que se pueden especicar sistemas no deterministas. Los operadores originales de PTL son ampliados para manejar estas ramicaciones. RTCTL (Real Time Computational Temporal Logic) ([45]) es una extensin de CTL (Computational Tree Logic) ([32]) para sistemas de tiempo real o que proporciona una mtrica para el tiempo. Sin embargo, el problema de la e satisfacibilidad es doblemente exponencial y el problema de la comprobacin o de modelos es de coste polinomial. RTTL (Real-Time Temporal Logic) [91] aade una mtrica para el tiempo n e usando un reloj global del sistema cuyo valor se aumenta peridicamente y o que puede usarse en las frmulas para incluir caracter o sticas temporales. La ordenacin de los eventos es parcial porque aquellos que han ocurrido entre o dos instantes son indistinguibles. Sin embargo, las frmulas son muy exibles o a la hora de referirse al tiempo, lo que tambin provoca que sean ms dif e a ciles de entender y de manipular que las de otras lgicas. o TPTL (Timed Propositional Temporal Logic) [7] tambin incluye una e mtrica para el tiempo haciendo corresponder a cada instante un nmero e u natural y usando una funcin montona que asocia un valor temporal con o o cada estado del sistema. IL (Interval Logic) [107] es un lgica proposicional basada en intervalos. o 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 e a
25
cambios de estado del sistema. EIL (Extended Interval Logic) ([80]) y RTIL (Real-Time Interval Logic) ([98]) extienden IL para permitir la especicacin de restricciones cuantitao tivas t picas de sistemas de tiempo real. LTI (Logic of Time Intervals) [5] es una lgica temporal de intervalos o de segundo orden. Los intervalos se pueden dividir en subintervalos hasta llegar a momentos. La lgica tambin permite cuanticacin de los intervao e o los. Permite especicar sin problemas restricciones sobre la ordenacin de o los eventos, pero no restricciones cuantitativas, ya que carece de mtrica de e tiempo. RTL (Real-Time Logic) [65] extiende la lgica de predicados de primer o orden con operadores para expresar restricciones t picas de un sistema de tiempo real, pero no es una lgica temporal en el sentido tradicional. Preo senta un reloj absoluto para medir el progreso del tiempo, que puede ser referenciado en las frmulas. El modelo de tiempo es lineal, discreto, acotado o en el pasado, no acotado en el futuro y totalmente ordenado. El principal problema es la dicultad de las frmulas por el hecho de que se referencia un o tiempo absoluto, adems a un nivel de abstraccin muy bajo. a o TLA (Temporal Logic of Actions) [73] es una lgica que se basa en denir o la semntica de acciones de un programa, a diferencia de otras lgicas tema o porales, en la que las propiedades de los programas son denidas mediante frmulas de la lgica de proposiciones o predicados con operadores temporao o les. En [2] los autores deenden la idea de que no es necesario describir una nueva semntica para especicar sistemas de tiempo real, sino que es sua ciente con los mtodos usados para especicar sistemas concurrentes. Basta e con aadir una nueva variable de programa que se reera al tiempo. n
26
3. Tcnicas y herramientas formales de anlisis: Tau e a
3.
Tcnicas y herramientas formales de anlie a sis: Tau

El modelado formal de sistemas ofrece grandes ventajas. En primer lugar,
permite eliminar la ambigedad en la especicacin de un sistema, reduciendo u o de esa forma la posibilidad de malentendidos entre los diferentes componentes del grupo de desarrollo. Tambin posibilita la aplicacin de tcnicas de e o e anlisis formales que garanticen matemticamente la correccin del sistema, a a o frente a los mtodos tradicionales de prueba y error, que son utiles para e detectar la presencia de errores, pero no garantizan su ausencia. La existencia de una semntica formal para el modelo en el que se ha a descrito el sistema permite hacer uso de herramienta automticas o semia automticas para realizar la simulacin del funcionamiento del sistema, su a o vericacin, la validacin de posibles escenarios y la generacin automtica o o o a de cdigo. o En las siguientes secciones introducimos brevemente, a modo de ejemplo de esta posibilidad, la herramienta automtica de diseo Tau de Telelogic a n que, a partir de la descripcin del sistema usando MSC [85] y SDL [108] o permite realizar los anlisis mencionados anteriormente. a MSC es un lenguaje grco orientado a objetos que se usa para describir a escenarios, es decir, ejecuciones concretas del sistema. SDL permite expresar mediante mquinas de estados el funcionamiento de las clases del sistema. a
3.1.
Simulacin o
El primer paso en la simulacin de un sistema es la generacin de cdigo o o o a partir de su descripcin en SDL. Tau permite escoger el compilador que se o va usar y congurar mltiples opciones en la creacin del cdigo. El cdigo u o o o generado incluye en el sistema un proceso monitor que permite controlar e
27
inspeccionar la ejecucin del sistema generado. o El simulador permite realizar una ejecucin controlada del sistema de mao nera similar a como lo hacen los depuradores tradicionales de los lenguajes de programacin. Se puede, por ejemplo, ejecutar el sistema hasta la siguiente o transicin. Como los activadores de las transiciones son seales desde el eno n torno, el simulador permite simular el env de seales externas. Tambin se o n e puede establecer un punto de ruptura en un s mbolo del sistema y ejecutar el sistema hasta que llegue a dicho s mbolo. Asimismo, se puede ejecutar hasta la expiracin de un temporizador. o 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 estan dos de las instancias de procesos. Se puede modicar el estado del sistema creando nuevas instancias de procesos, modicando 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. o o Se puede obtener tambin un registro en modo texto, se puede ir viendo segn e u avanza la simulacin cules son los estados SDL que se van activando o se o a puede generar un MSC que represente la historia de la ejecucin simulada, o mostrando los estados de los diferentes objetos involucrados y los mensajes intercambiados entre ellos. Por ultimo, es posible seleccionar la cantidad de informacin que muestra el registro de la simulacin. o o
3.2.
Generacin de cdigo o o
Tau ofrece la posibilidad de generar cdigo ejecutable de la aplicacin a o o partir de la descripcin SDL. La generacin de cdigo se compone de dos o o o elementos, el generador de cdigo C a partir de la especicacin SDL y las o o bibliotecas predenidas que incluyen el runtime de SDL y los elementos de
28
monitorizacin del sistema, por si el cdigo generado se usa para simulacin o o o o validacin. Las bibliotecas de runtime incluyen los mecanismos de comuo nicacin del sistema con el entorno. o En realidad, lo que se genera es el cdigo correspondiente al funcionao miento de las mquinas de estados. Dentro de cada accin de SDL se pueden a o incluir sentencias en C que se integrarn en el cdigo generado. a o Tau ofrece tres versiones del generador de cdigo C a partir de SDL, o CBasic, slo para simulacin y validacin, CAdvanced, para cualquier tipo o o o de aplicacin, y CMicro, que genera versiones ms pequeas y optimizadas, o a n ms utiles cuando se trata de sistemas empotrados con restricciones fuertes a de memoria y capacidad de procesamiento. Cuando se genera cdigo se incluyen macros para tratar la interaccin con o o el entorno, como las llamadas al sistema y el env y recepcin de seales. Las o o n macros dependen del nivel de integracin, que puede ser ligera, light integrao tion, o ajustada tight integration. El cdigo generado con la integracin ligera o o se ejecuta con una sola hebra del sistema operativo subyacente para toda la aplicacin, por lo que la planicacin corre a cargo del run-time incluido en o o el cdigo generado, lo que permite su ejecucin sin sistema operativo subo o yacente. Por su lado, el cdigo que se genera con la integracin ajustada o o contiene una hebra del sistema operativo por cada proceso de la aplicacin. o En el modo de integracin ligera, los procesos no son interrumpibles, pero o en ajustado s lo son, dependiendo de las posibilidades del sistema operativo sobre el que se est trabajando. e Con CMicro existe un modo adicional de generacin de cdigo, bare inteo o gration, que no incluye macros de manejo de dispositivos f sicos ni de seales. n Este modo permite personalizar el cdigo resultante mediante el uso de funo ciones de la biblioteca de CMicro para denir esos manejadores.
29
3.3.
Validacin y vericacin o o
Tau tambin ofrece una herramienta para validar sistemas. Una vez espee cicado 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 vericar 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. o o El sistema SDL examinado con el validador se representa mediante un a 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 a n explorado se puede congurar y de l depende el nmero de estados generados e u tras una transicin y el nmero de posibles sucesores de un estado. o u El validador permite seguir la traza del sistema paso a paso de manera similar a como se hac en la simulacin, pero ofreciendo informacin adicioa o o nal, como la lista de posibles transiciones a ejecutar en un estado. De este modo, el validador puede informar sobre errores dinmicos, como el env de a o una seal que no puede ser recibida por ningn proceso. n u 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. o Otra funcionalidad proporcionada en Tau es la vericacin de un posible o 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 a pueden reproducir el MSC. La validacin acabar informando de si ese MSC o a
30
es posible en el sistema o de si hay caminos que lo violen.
3.4.
Comprobacin de modelos o
La comprobacin de modelos (model checking) [68] es una tcnica de o e vericacin formal en la que las propiedades de funcionamiento de un sistema o se comprueban a travs del recorrido exhaustivo, impl e cita o expl citamente, 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 o otros mtodos de vericacin: es completamente automtico y su aplicacin e o a o no requiere un conocimiento profundo de disciplinas matemticas, y cuando el a diseo no cumple una propiedad el proceso siempre genera un contraejemplo. n Una variante muy interesante es la comprobacin de modelos simblica o o en la que se puede hacer una enumeracin impl o cita exhaustiva de un nmero u de estados astronmicamente grande. o La comprobacin de modelos tiene dos limitaciones fundamentales: es o aplicable slo a sistemas de estados nitos y el nmero de estados crece o u exponencialmente cuando hay varios procesos ejecutndose en paralelo. a La aplicacin de esta tcnica se divide en tres etapas: el modelado del o e sistema, la especicacin de propiedades y la vericacin. o o Aunque idealmente la vericacin de propiedades con la tcnica de como e probacin de modelos es un proceso automtico, comnmente tiene que cono a u tar con la supervisin humana, concretamente en el anlisis de los contrao a ejemplos 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 o representa un estado, o conjunto de estados, del sistema que se expresa como
31
una frmula lgica que se satisface en dicho estado o conjunto de estados. o o Las propiedades a vericar se modelan como frmulas lgicas y se comprueba o o si se cumplen o no en los nodos del rbol. a
4.
Lenguajes grcos de modelado a

En esta seccin se presentan lenguajes de especicacin y diseo basado o o n
en grcos. Sus elementos de descripcin son visuales, incrementando de esa a o manera la facilidad de aprendizaje y la comprensin por parte de un operador o humano.
4.1.
SDL
SDL, el Specication and Description Language [61] 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 a a est especialmente recomendado para sistemas distribuidos y reactivos. a Uno de los principales objetivos al denir SDL fue su facilidad de uso, por lo que se opt por un modelo grco, ms intuitivo que uno textual. o a a Las versiones iniciales no ten una semntica formal subyacente, lo que an a provocaba problemas porque permit diferentes interpretaciones, dicultaba a el desarrollo de herramientas automticas que ayudaran a su uso y hac ms a a a complicada la descripcin precisa de sistemas complejos. Estos inconvenientes o llevaron a la denicin de una semntica formal que se incluy por primera o a o vez en la versin de 1988. o SDL cuenta asimismo con una versin textual SDL/PR (la grca se o a denomina SLD/GR) que es semnticamente equivalente y que surgi por la a o necesidad de procesar los cheros de manera automtica. a
32
4. Lenguajes grcos de modelado a
SDL describe la estructura del sistema de manera jerrquica mediante a los constructores sistema, bloque, proceso y procedimiento. Una descripcin o en SDL se compone de un sistema que muestra los l mites y la comunicacin o 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 e procesos que son entidades que se ejecutan concurrentemente. Los procedimientos denen secuencias de cdigo que se ejecutan secuencialmente en el o ambito de un proceso. A nivel de sistema la descripcin est compuesta por los bloques de ms o a a alto nivel, los canales (y su lista de seales) de comunicacin entre ellos y n o los canales de comunicacin con el entorno. Esta descripcin se puede ir o o detallando para cada bloque que puede dividirse jerrquicamente en otros a bloques o en procesos. A este nivel la descripcin sigue siendo estructural o mostrando cules son los componentes y los canales de comunicacin entre a o ellos. Es ya a nivel de procesos donde se entra en la descripcin del funcionao miento del sistema. Los procesos son entidades que se ejecutan concurrentemente y su funcionamiento viene denido por mquinas de estados. a Los procedimientos representan partes del sistema que se pueden denir para aclarar la descripcin o agrupar acciones que se repiten a menudo. Los o procedimientos pueden denir sus propios valores, pueden ser recursivos e incluir estados, como los procesos, lo que les permite recibir seales externas. n Sin embargo, no pueden devolver el control a un estado del proceso que los llam, sino que debe acabar, llegando al nal o ejecutando una sentencia o return. Los procedimientos remotos son un tipo especial de procedimientos que proporcionan una v alternativa de comunicacin entre procesos, s a o ncrona
33
en este caso, y les permite acceder y modicar variables denidas en otros procesos. Estos procesos se declaran como remotos en el nivel adecuado (sistema o bloque) para que sea visible a todos los procesos que lo usan. El proceso que lo dene lo ha de exportar para que los dems puedan usarlo. Si a otro proceso quiere hacer uso de l, lo puede importar y lo tiene disponible e para llamarlo como cualquier otro procedimiento propio. El principal mecanismo de comunicacin entre los componentes de un o sistema descrito en SDL es de las seales. Las seales se pasan de un compon n nente a otro a travs de canales, para los que se especica la lista de seales e n que se puede enviar a travs de ellos. Las seales corresponden a un evene n to transitorio as ncrono, frente a las llamadas a procedimientos remotos que se hacen de manera s ncrona. Para poder usar las seales han de estar pren viamente declaradas y slo pueden usarse en su mbito. Las seales pueden o a n llevar parmetros asociados. a Para que una seal se pueda transmitir entre dos procesos ha de existir n entre ellos una ruta de comunicacin. Estas rutas se denominan canales y o son medios de comunicacin punto a punto y bidireccionales. Los canales se o describen en la descripcin estructural del sistema y pueden conectar el eno torno, bloques o procesos. Cada canal puede transmitir un conjunto concreto de seales que se especica con el canal. n Como ya se coment anteriormente, el funcionamiento del sistema se hace o a nivel de proceso mediante mquinas de estados. Estas mquinas de estados a a se llaman comunicantes porque intercambian seales con las dems mquinas n a a de estados del sistema y extendidas porque usan variables para reducir el nmero de estados. u Los componentes principales de una mquina de estados son los estados a y las transiciones. Una mquina permanece en un estado hasta que recibe a
34
una seal (la expiracin de un temporizador es un caso especial de recepcin n o o de una seal). Cuando recibe una seal la mquina efecta una transicin a n n a u o un estado nuevo. En la transicin el proceso puede realizar diferentes accioo nes, como enviar seales, llamar a procedimientos, operaciones condicionales, n operaciones con temporizadores, etc. Cada mquina de estados slo puede efectuar una transicin a la vez y a o o esta transicin se ejecuta (desde el punto de vista de la propia mquina) de o a manera atmica, es decir, que hasta que no llega al nuevo estado no acepta o nuevas seales. n Las seales que llegan a un proceso se guardan en una cola donde se n atienden en el mismo orden en el que llegaron. Cuando un proceso llega a un nuevo estado inspecciona la cola de seales que an no han sido procesadas. n u Si la seal que est en el frente de la cola es atendida en ese estado, el proceso n a la consume y evoluciona. Si, por el contrario, la seal no es atendida en ese n estado, sta se descarta. Para evitar la prdida de seales se puede especicar e e n en los estados qu seales son guardadas para ser procesadas en otro estado. e n Hay tipos especiales de transiciones, como las transiciones espontneas, a que no consumen ninguna seal y se usan principalmente para pruebas, las n seales continuas, que son transiciones que no se activan por la llegada de una n seal, sino porque una condicin lgica se haga verdadera, y transiciones con n o o prioridad si un proceso puede escoger entre una transicin normal y una o con prioridad porque ambas seales estn en la cola de seales del proceso, n a n el proceso siempre escoge la transicin con prioridad aunque su seal haya o n llegado despus. e Se pueden denir tipos de sistemas, bloques y procesos de los que se pueden tener mltiples instancias en el sistema. Entre los tipos se pueden u establecer relaciones de herencia en los que cada tipo modica el tipo padre
35
a travs de la especializacin. La especializacin en SDL est denida de e o o a una manera muy liberal y prcticamente no hay ninguna restriccin sobre a o qu elementos se pueden especializar y cmo. e o A modo de ejemplo se va a especicar en SDL un sistema muy simple. Se trata de una mquina expendedora que acepta chas para vender un a 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 chas hasta que se complete el precio. El usuario tiene en cualquier momento la posibilidad de anular la compra.
interfaz_sal block expendedor
system MaquinaExpendedora
peticion, ficha, anular
agotado
1(1)
1(1)
inf_error
interfaz_usuario
ordenes_usuario interfaz_usuario
peticion, anular
controlador
expendedor
recibido, agotado
venta
inicio, anular
agotado
interfaz_sal
intr_fichas contador_monedas interfaz_usuario

ficha
Figura 1.1: Descripcin a nivel de o sistema.
Figura 1.2: Descripcin a nivel de o bloques.
En la gura 1.1 se muestra la descripcin del ejemplo a nivel de sistema o en la que hay un unico bloque que se comunica con el entorno a travs de e dos canales, para cada uno de los cuales se indican sus seales. n En la gura 1.2 se muestra la descripcin a nivel de bloques en la que se o ven dos procesos que se comunican entre s y con el entorno. Tambin se ve e la correspondencia entre los nombres de las rutas de seales y los canales. n Adems de los canales de comunicacin con el entorno, hay un canal interno, a o
36
no visible desde fuera del sistema, por el que se comunican los dos bloques.
process controlador 1(1)
process contador_monedas
DCL precio Integer := 10, insertadas Integer := 0, existencias Integer := 10;
1(1)
listo
inicio
listo
false existencias > 0 true

peticion anular
agotado recibir_fichas
vendiendo
listo ficha
anular agotado recibido
anular
insertadas := insertadas + 1;
anular agotado dar
insertadas := 0;
false insertadas < precio true

listo
existencias := existencias 1;
recibido
listo
Figura 1.3: Descripcin del proceso o controlador.
Figura 1.4: Descripcin del proceso o contador.
El proceso controlador, cuya mquina de estados se muestra en la gura a 1.3, se encarga de iniciar y arrancar la venta. El proceso contador, gura 1.4, lleva a cabo la tarea de comprobar el pago. En ambos casos el funcionamiento viene desarrollado mediante una mquina de estados muy simple. a SDL para tiempo real Aunque SDL tiene herramientas para especicar el paso del tiempo, como la operacin now y los temporizadores, diversos trabajos de investigacin han o o sealado que no son sucientes para especicar las restricciones habituales n en los sistemas de tiempo. Entre ellos se pueden citar [114], en el que se dene SDL*, una extensin o
37
de SDL que describe restricciones de diseo no funcionales. Con este SDL n anotado y PMSC (una extensin de MSC con la misma losof se puede o a) partir el sistema en componentes f sicos y lgicos para optimizar costes y o cumplir los requisitos de tiempo. El proceso de diseo se puede automatizar n para derivar un sistema de tiempo real optimizado. Las anotaciones son similares a las de PMSC y se integran como comentarios en el diseo SDL. n Hay cinco tipos de directivas: de herramientas, que indican qu componentes se implementan y si hay e que incluir cheros con ms anotaciones, a de aplicacin, que especican sobre qu componentes f o e sicos se desplegarn los componentes lgicos, a o de recursos, que indican la capacidad mxima de los recursos con l a mites en el sistema, como nmero de instancias, ancho de banda, etc., u de tiempo, que aaden informacin sobre el retraso en el env de una n o o seal o el jitter, n de coste, que especican el coste mximo que pueden tener los compoa nentes del sistema. En [86], se presenta una estrategia general para la especicacin de sisteo mas de tiempo real usando SDL*. En primer lugar enumeran las deciencias que, en su opinin, presenta el modelo de tiempo de SDL: temporizadores sin o unidades, retrasos impredecibles en la recepcin de las seales de expiracin o n o de los temporizadores e imposibles de acotar y semntica insuciente de los a relojes del sistema y la operacin now. Clasican las restricciones temporales o en dos tipos: los requisitos temporales, que se han de validar durante las fases de diseo y prueba del sistema y condiciones temporales, que corresponden n
38
a segmentos de cdigo que se han de activar durante la ejecucin del sisteo o ma en funcin de determinadas condiciones de validez asociadas. Proponen o dos soluciones complementarias. Por un lado, la solucin funcional, en la que o desarrollan un patrn de diseo de sistemas de tiempo real que permite espeo n cicar reaccin s o ncrona a componentes de acceso al medio, funcionamiento de tiempo real determinista y funcionalidad de nivel 2 OSI como multiplexores de paquetes o planicadores. La otra estrategia, la temporal, dene relojes en base a una descripcin matemtica detallada, usando la notacin o a o descrita en esta propuesta. Cada sistema tiene al menos un reloj propio que puede ser asignado a cualquier elemento de la jerarqu del sistema y se dea ne un nuevo tipo abstracto para los relojes con operaciones para acceder al valor del reloj y a operaciones sobre temporizadores sobre ese reloj. En [26] Bozga et al. declaran que la semntica de tiempo de SDL y el que a las seales de los temporizadores se encolen con las dems seales impiden n a n especicar correctamente funcionamientos de tiempo real. SDL carece de una semntica de tiempo exible y de ms herramientas para expresar la parte a a no funcional del sistema o el entorno. Las caracter sticas sobre el entorno y los aspectos no funcionales deben incluir la duracin de las tareas internas, o la periodicidad de los eventos externos y el funcionamiento esperable de los canales de comunicacin. Para solucionarlo, se propone anotar el sistema con o dos tipos de anotaciones: las suposiciones, que es conocimiento a priori del entorno, usado tanto para vericacin como para generacin de cdigo, y las o o o armaciones, que representan restricciones en forma de propiedades esperadas de los componentes del sistema. Para hacer suposiciones sobre el paso del tiempo en el sistema se denen urgencias de transiciones que especican que una transicin habilitada ser ejecutada o inhabilitada antes de que pase una o a determinada cantidad de tiempo. En funcin de su urgencia las transiciones o
39
se clasican en eager, lazy y delayable. Tambin se puede anotar la durae cin del tiempo que tarda una seal en llegar del emisor al receptor o el que o n consume una accin al ejecutarse. Asimismo se puede anotar la periodicidad o esperada de los eventos externos. Respecto a los canales de comunicacin, o argumentan que en SDL siempre se consideran ables, sin prdida ni reordee nacin, consideracin que siempre es realista, y por tanto proponen anotar o o los canales con propiedades que permitan indicar si es posible la prdida o e la reordenacin de los mensajes enviados a travs de los canales. o e
4.2.
UML
UML, (Unied Modeling Language) [24], surge a mitad de los noventa como fusin fundamentalmente de tres mtodos de desarrollo orientados a o e objetos, el mtodo de Booch [23], el mtodo OOSE [64] y el mtodo OMT e e e [101]. Cada uno de estos tres mtodos era especialmente indicado en una e de las fases del desarrollo y se intent generar un unico mtodo que fuera o e util durante todo el desarrollo y que eliminara los problemas de contar con diferentes nomenclaturas. Aunque UML no es una metodolog sino un conjunto de lenguajes, su a, objetivo es visualizar, especicar, construir y documentar los elementos de sistemas con gran cantidad de software. Los lenguajes denidos en UML son fundamentalmente grcos, para facilitar su estudio y comprensin. En UML a o se denen nueve tipos de diagramas, algunos de los cuales modelan diferentes vistas estticas del sistema y otros modelas vistas dinmicas: a a Diagramas de clases. Este es un diagrama esttico en el que se muestran a cules son las clases involucradas en el sistema y las relaciones entre a ellas. Diagramas de objetos. Este otro diagrama esttico est a a ntimamente
40
relacionado con el anterior. Muestra una vista de las instancias reales de las clases que estn en ejecucin en el sistema en un momento dea o terminado. Diagramas de casos de uso. En estos diagramas se muestran conjuntos de casos de usos y actores y sus relaciones. Diagramas de secuencia. Estos diagramas muestran parte de la vista dinmica, concretamente una interaccin entre un subconjunto de oba o jetos, bsicamente a travs del env de mensajes entre ellos. Estos a e o diagramas priman la ordenacin temporal de los mensajes. o Diagramas de colaboracin. Estos diagramas son isomorfos a los diao gramas de secuencia, muestran la misma interaccin, pero resaltando o la organizacin estructural de los objetos. o Diagramas de estados. Son mquinas de estados que especican el funa cionamiento 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 ujo de actividad entre los objetos. Diagramas de componentes. Son diagramas estticos que muestran la a organizacin y las dependencias entre los componentes. Un componente o suele corresponder a varias clases o interfaces. Diagramas de despliegue. Es una vista esttica estructural en la que se a relacionan los nodos de procesamiento con los componentes que residen en ellos. En UML se denen cuatro tipos fundamentales de elementos:
41
Estructurales. La mayor son elemento estticos e incluyen clases, ina a terfaces, colaboraciones, casos de uso, clases activas, componentes y nodos. De comportamiento. Son las partes dinmicas del modelo e incluyen a relaciones y mquinas de estados. Estn asociados a uno o varios elea a mentos estructurales. De agrupacin. Son los elementos organizativos del modelo. Los unicos o elementos de agrupacin son los paquetes, que se pueden descomponer o en elementos ms simples. a De anotacin. Sirven para incluir explicaciones sobre los dems elemeno a tos del modelo. Las notas son los elementos explicativos. Son simplemente s mbolos que introducen restricciones y comentarios. Hay cuatro tipos de relaciones en UML: Dependencia. Es una relacin semntica entre dos elementos en la que o a un cambio en un elemento puede afectar a la semntica en el otro. a Asociacin. Es una relacin estructural que dene un conjunto de coo o nexiones entre objetos. La agregacin es un tipo especial de asociacin. o o Generalizacin. En una relacin de generalizacin/especializacin los o o o o elementos que especializan pueden sustituir al especializado. El caso ms usual en la relacin de herencia entre clases. a o Realizacin. Es una relacin semntica entre clasicadores en la que un o o a clasicador especica un contrato que otro clasicador realizar. Esta a relacin se da entre interfaces y clases y entre casos de uso y diagramas o de colaboracin. o
42
Las especicaciones en UML son la explicacin textual de la sintaxis y o la semntica de los elementos grcos de UML. La especicacin cubre los a a o detalles que no se pueden representar en la notacin grca, usualmente ms o a a simple y escueta. Las especicaciones se hacen en lenguaje natural habitualmente y, si se quiere una especicacin ms formal, se usa OCL (Object o a Constraint Language) [87]. Adems de la especicacin, la notacin grca a o o a se puede enriquecer con adornos, s mbolos grcos concretos para indicar a ciertos detalles del diagrama, como puede ser la visibilidad de los atributos. UML ofrece la posibilidad de denir nuevos elementos mediante diversos mecanismos de extensin: los estereotipos, los valores etiquetados y las reso tricciones. Con los estereotipos se construyen nuevos bloques de modelado, derivados de los ya existentes pero espec cos del dominio del problema. Los valores etiquetados extienden las propiedades de un bloque de construccin o aadiendo nueva informacin en la especicacin del elemento. La restricn o o cin extiende la semntica de un elemento de UML incluyendo nuevas reglas o a o modicando las existentes. En el resto de la seccin vamos a hacer un recorrido breve por los diagrao mas de UML que son ms utiles para la descripcin de los sistemas de tiempo a o real. En el aspecto esttico incluiremos los diagramas de casos de uso y los a de clases. En el aspecto dinmico incluiremos los diagramas de secuencia y a de estados.
Diagramas de clases Un diagrama de clases presenta un conjunto de clases, interfaces y colaboraciones, y las relaciones entre ellas. Estos diagramas son los ms comunes a en el modelado de sistemas orientados a objetos y se utilizan para describir la vista de diseo esttica de un sistema. Los que incluyen clases activas se n a
43
utilizan para cubrir la vista de procesos esttica de un sistema. a Los elementos de los diagramas de clases suelen ser: clases interfaces colaboraciones relaciones Como en los dems diagramas, podemos aadir notas y restricciones. Si el a n sistema modelado por el diagrama es muy grande, se puede dividir jerrquia camente incluyendo paquetes o subsistemas en el diagrama. Las clases se pueden utilizar para capturar el vocabulario del sistema que se est desarrollando, tanto para elementos software, hardware o puramena te conceptuales. Las clases representan conjuntos de valores con propiedades comunes. Estas propiedades incluyen atributos, operaciones, relaciones y semntica. a Un atributo es una abstraccin de un rango de valores (o estado) que o puede incluir una instancia de la clase. Una operacin es la implementacin o o de un servicio que puede ser requerido a cualquier instancia de la clase para que muestre un comportamiento. La representacin grca de una clase es un rectngulo con compartimeno a a tos separados para los atributos y las operaciones. Hay tres tipos fundamentales de relaciones: las dependencias, que representan relaciones de uso entre las clases, generalizaciones, que conectan clases generales con sus especializaciones, y asociaciones, que representan relaciones estructurales. Las asociaciones pueden conectar dos o ms clases y suelen a tener un nombre que identica su naturaleza. Las clases involucradas en la
44
asociacin tienen una funcin tambin identicada por su nombre. Cada clase o o e puede estar presente en la asociacin con un nmero diferente de instancias, o u posibilidad que se indica mediante la multiplicidad. Las asociaciones suelen representar relaciones de uso, aunque hay casos especiales, como las agregaciones y las composiciones, que representan una relacin de todo/parte. o Estas asociaciones indican aquellas situaciones en las que las instancias de una clase incluyen instancias de otras clases. Un diagrama de objetos es un tipo particular de diagrama de clases en el que se muestran las instancias que conforman realmente el sistema. Representa un conjunto de objetos y sus relaciones y se utilizan para describir estructuras de datos correspondientes a instancias de los elementos encontrados en los diagramas de clases. Los diagramas de objetos cubren la vista de diseo esttica o la vista de procesos esttica de un sistema al igual que los n a a diagramas de clases, pero desde la perspectiva de casos reales o protot picos.
Diagramas de casos de uso Los casos de uso se emplean para capturar el funcionamiento deseado del sistema en desarrollo, sin tener que especicar cmo se implementa ese o funcionamiento. Un caso de uso especica el funcionamiento del sistema o de parte del mismo, y es una descripcin de un conjunto de secuencias de accioo nes, incluyendo variantes, que ejecuta un sistema para producir un resultado observable de valor para un actor. Un actor representa un conjunto coherente de funciones que los usuarios de los casos de uso juegan al interactuar con el sistema. Un actor es, t picamente, una persona, un dispositivo f sico u otro sistema que interaccione con el modelado. Los actores se relacionan con los casos de uso a travs de e asociaciones que indican su funcin en el caso de uso. Un caso de uso describe o
45
qu hace el sistema sin especicar cmo lo hace. Es importante tener clara e o la separacin entre las vistas externa e interna. o Diagramas de interaccin o Un diagrama de interaccin muestra las acciones que se desarrollan entre o un conjunto de objetos relacionados, fundamentalmente representados por el env de mensajes entre los objetos. Hay dos tipos de diagramas de ino teraccin, que son isomorfos: los de secuencia y los de colaboracin. En los o o diagramas de secuencia se hace nfasis en mostrar la ordenacin temporal de e o la sucesin de mensajes y en los diagramas de colaboracin se incide ms en o o a la organizacin estructural de los objetos que realizan las acciones mostradas. o Diagramas de actividad Un diagrama de actividad es un diagrama de ujo que muestra el ujo de control entre actividades. Las actividades son ejecuciones no atmicas en o curso dentro de una mquina de estados. Las actividades producen acciones, a compuestas de clculos atmicos. a o Los diagramas de actividad contienen estados de accin y de actividad, o transiciones y objetos. Esots diagramas se pueden considerar como casos especiales de las mquinas de estados en los que los estados son estados de a actividad y las transiciones se disparan por la terminacin de la actividad o del estado origen. Las transiciones pueden incluir bifurcaciones dependientes de condiciones y divisiones y uniones para representar ujos de control concurrentes. Cuando se modelan ujos de trabajos de varios objetos a la vez, se pueden modelar mediante calles (swimlanes), donde se separan grcamente los ujos a de cada objeto.
46
Mquinas de estados a Las mquinas de estados se usan para modelar los aspectos dinmicos a a de un sistema. Una parte fundamental del funcionamiento de un sistema orientado a objetos se puede denir de manera reactiva, las instancias de las clases del sistema responden con determinadas acciones a est mulos externos a la clase. Estos est mulos pueden ser una llamada a uno de los mtodos de e la clase o el env de una seal. Si el objeto no realiza ninguna otra accin o n o entre el n de la respuesta a un est mulo externo y el inicio de la siguiente respuesta, se puede considerar que permanece en un determinado estado en ese intervalo de tiempo. Las mquinas de estados se adecan perfectamente a u para denir este tipo de funcionamiento. A diferencia de otros diagramas de UML, un diagrama de mquinas de a estados no representa el funcionamiento de varias clases dentro del sistema, sino que se limita a representar el funcionamiento interno de las instancias de una clase concreta. Una mquina de estados est compuesta por varios a a elementos fundamentales: estados, transiciones, eventos y acciones. Los estados representan las situaciones estables en la evolucin de un o objeto en la que se cumple alguna condicin y se espera algn evento. Hay o u estados especiales, como el estado inicial, en el que se encuentra el objeto cuando se crea y los estados nales, que representan el nal de la vida util de un objeto cuando alguna transicin hace que un estado nal sea el eso tado actual del objeto. Los estados pueden dividirse jerrquicamente para a representar un funcionamiento interno, bien secuencial, bien concurrente. El paso de un estado a otro se hace mediante la ejecucin de una trano sicin. Una transicin indica cules son las posibles evoluciones del estado o o a de una instancia. Cada estado tiene su propio conjunto de transiciones, y cada una de ellas lleva a un nuevo estado. Las transiciones tienen asocia-
47
das condiciones, acciones y eventos. La eleccin de la transicin que realiza o o una instancia como respuesta a un est mulo externo depende de cules estn a a activadas (en base a su condicin) y de los eventos asociados a las transicioo nes. Una transicin slo es elegible si su evento asociado coincide con el que o o ha recibido la mquina de estados. La ejecucin de la transicin implica la a o o ejecucin de las acciones asociadas. o Un evento es la especicacin de un suceso signicativo para el funcionao miento de la instancia que lo recibe. En las mquinas de estados de UML, los a eventos pueden incluir seales as n ncronas, llamadas a mtodos, cambios de e valores o el paso del tiempo. Cuando una instancia recibe un evento reacciona a l, t e picamente ejecutando una transicin, que suele involucrar un cambio o de estado. Las acciones especicadas en una mquina de estados representan los a clculos ejecutados por la instancia como respuesta al evento. Hay acciones a que se ejecutan al entrar a un estado, otras que se ejecutan al salir de un estado, otras que se ejecutan al ejecutar una transicin y otras que se ejecutan o mientras la mquina permanece en un estado. a
UML para tiempo real UML tiene dos conceptos relativos al tiempo, las clases TimeExpression y TimeEvent. Los valores de la clase TimeExpression sirven para expresar valores relativos al tiempo en aquellas circunstancias en las que se necesiten, como, por ejemplo, las condiciones de habilitacin de las transiciones de las o mquinas de estados para etiquetar propiedades de los mensajes en diagramas a de secuencia. Los elementos de la clase TimeEvent se usan para expresar la ocurrencia de un evento relacionado con el tiempo como la expiracin o de un temporizador. UML puede usar restricciones para establecer varias
48
propiedades de tiempo, como, por ejemplo, el tiempo de ejecucin o el tiempo o de bloqueo, o puede usar valores etiquetados para establecer la prioridad de una tarea o su plazo temporal de ejecucin. o Estos mecanismos no son sucientes para especicar todas las restricciones y funcionalidades asociadas a los sistemas de tiempo real. Por ejemplo, no se puede expresar la frecuencia de ocurrencia de un evento como una funcin de probabilidad. Tampoco hay mecanismos para referirse a relojes de o referencia o a los servicios temporales ofrecidos por capas inferiores de software, como el sistema operativo. La falta de una semntica formal de esos a mecanismos impide que una herramienta que haga anlisis de planicabilidad a pueda contar con la representacin de estos conceptos para su importacin. o o El UML Prole for Schedulability, Performance, and Time Specication (Perl de Planicabilidad, Rendimiento y Especicacin del Tiempo) [56] es o una respuesta a una iniciativa del Grupo de Manejo de Objetos (Object Management Group, OMG), un grupo de promotores de la orientacin a objetos o en el desarrollo de sistemas. La nalidad de esta iniciativa es extender UML para que se pueda usar para la especicacin y diseo de sistemas de tiempo o n real en toda su extensin y diversidad. El trabajo se ha realizado utilizando o los mecanismos de extensin presentes en UML, los estereotipos y los valores o etiquetados. En este perl se han introducido en el metamodelo de UML algunas clases nuevas, como TimeValue, Duration, Clock y Timer. De esta forma se denen nociones tan importantes como el periodo de una tarea, el jitter, o el tiempo de transmisin de una seal. La estructura del perl se o n divide en cuatro paquetes principales (gura 1.5), en los que se denen, respectivamente, los recursos generales, en los que se basan los dems paquetes, a los conceptos relacionados con la denicin del tiempo, los conceptos relatio vos al anlisis de planicabilidad y los relativos al anlisis del rendimiento. a a
49
Este perl se revisa en profundidad en el cap tulo 3, en el que se aaden a las n mquinas de estados de UML elementos para especicar sistemas de tiempo a real.
General Resource Modeling Framework
<<profile>> RTresource Modeling <<import>> <<import>>
<<profile>> RTconcurrency Modeling
<<profile>> RTtimeModeling
<<import>>
<<import>>
<<import>>
Analysis Models
<<profile>> SAProfile <<import>>
<<profile>> PAProfile Infrastructure Models
<<modelLibrary>> <<profile>> RSAProfile RealTimeCORBAModel
Figura 1.5: Estructura del perl de planicabilidad, rendimiento y especicacin de tiempo, tomada de [56]. o Shankar y Asa [112] y Lavazza et al. en [75] sugieren estrategias similares para aadir capacidad de especicacin de requisitos de tiempo real. En n o ambos casos optan por traducir el modelo UML a un modelo formal, concretamente lgicas temporales, sobre el que se pueden demostrar propiedades. o En [112] se centran en las mquinas de estados, a las que aaden construca n tores de tiempo real independientes de la semntica concreta de la mquina a a de estados. La base matemtica es una lgica temporal proposicional bidia o mensional, en la que se diferencia el microtiempo, o puntos, para referirse a las transiciones instantneas de estado de un objeto, del macrotiempo, para a
50
referirse a las comunicaciones entre objetos. La lgica ofrece los operadores o temporales usuales: siempre en el futuro, alguna vez en el futuro y hasta, con versiones acotadas. Las mquinas de estados que usan son planas y dea terministas respecto a las transiciones, y se traducen a la lgica temporal o siguiendo un determinado conjunto de reglas. Una vez que se tiene el modelo en la lgica se pueden vericar diferentes tipos de propiedades. Por un lado, o las habituales de seguridad y viveza; por otro, si un evento o accin ocurre o antes de t instantes de tiempo tras otro; y, nalmente, la validacin del moo delo en s incluyendo la comprobacin de la consistencia entre diagramas de , o secuencia y mquinas de estados. a En [75] traducen las mquinas de estados de UML a TRIO (Tempo Real a ImplicitO), una lgica de primer orden aumentada con operadores temporao les. En el caso concreto del ejemplo con el que ilustran su propuesta, usan una herramienta automtica de control de histricos. Para especicar el funcionaa o miento temporal, usan la sentencia After de UML y expresiones lgicas. La o traduccin a TRIO se hace identicando fragmentos del diagrama de estados o y deniendo los correspondientes axiomas TRIO. Aprville et al. proponen en [17] un nuevo perl de UML, llamado TURTLE, espec camente pensado para la validacin de restricciones de tiempo real. o Para ello, se basan en tres pilares, una semntica formal para las asociaciones a de clases, operadores temporales con retrasos no deterministas y la traduccin de las clases y la descripcin de su funcionamiento a RT-LOTOS. En o o TURTLE se usa un nuevo tipo de clase, TClass, que resulta de estereotipar el concepto usual de clase en UML. Las instancias de TClass se pueden comunicar a travs de canales de comunicacin llamados TGates, de los que e o hay de entrada y de salida. El funcionamiento dinmico de las clases se hace a mediante diagramas de secuencias. Para cada constructor de los diagramas
51
de secuencias se dene una traduccin a RT-LOTOS. Con esta traduccin se o o puede generar automticamente una descripcin del sistema en RT-LOTOS. a o La especicacin RT-LOTOS queda oculta al usuario y puede ser simulada o y validada mediante tcnicas de anlisis de alcanzabilidad. e a
5.
Metamodelado
Cuando se dene un lenguaje de modelado de sistemas, ste suele poe
der aplicarse a un conjunto ms o menos amplio de casos, dependiendo de a la generalidad del lenguaje. Si el lenguaje es muy espec co 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 sucientee mente genrico y puede modelar una gama amplia de sistemas, puede llegar e 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 caracter sticas de los datos del sistema. Esta circunstancia del modelado del modelo en vez del modelado de valores se conoce como metamodelado. Esta meta relacin no es exclusiva del o modelado de sistemas. Bien al contrario, se puede encontrar en mltiples siu tuaciones en el mbito de la informtica. Por ejemplo, en las bases de datos, a a los metadatos son datos sobre datos, los metaintrpretes son programas en e cuya ejecucin, se usan como datos ejecuciones de programas (por ejemplo o los depuradores) o, en un sistema de informacin, se puede tener el modelo o E-R del modelo E-R del sistema. El metamodelado suele denirse en niveles. El lenguaje de modelado puede denirse mediante un metamodelo, donde los constructores presentes en el metamodelo se denominan metaelementos y su relacin con los elemeno
52
5. Metamodelado
tos del lenguaje de modelado es que stos son instancias de aquellos, o sea, e un elemento del lenguaje de modelado es un caso concreto de un metaelemento del nivel de metamodelado. Esta denicin puede asimismo aplicarse o al metamodelo, que puede ser descrito en trminos de otro nivel superior, e el metametamodelo, y cada metaelemento es una instancia de un metametaelemento. Esta jerarqu de deniciones se podr extender tantos niveles a a como se quisiera, pero en general, hay consenso sobre el uso de cuatro niveles distintos de abstraccin: o Metametamodelo. Describe la infraestructura para la arquitectura de metamodelado, incluyendo el lenguaje de descripcin de metamodelos. o Metamodelo. Describe el lenguaje de especicacin de modelos. o 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 e 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 denicin a o de lenguajes de modelado es el que usa el OMG para describir diferentes lenguajes de modelado y su conexin. El OMG usa dos especicaciones distintas o para modelar sistemas informticos distribuidos y sus interfaces en CORBA: a Lenguaje Unicado de Modelado (Unied Modeling Language, UML) Servicios de Meta-Objetos (Meta-Object Facility, MOF)
53
La especicacin de UML dene un conjunto de lenguajes grcos para o a visualizar, especicar, construir y documentar los elementos de sistemas distribuidos orientados a objetos. La especicacin incluye un metamodelo, una o notacin grca y un servicio de IDL en CORBA que permite el intercambio o a de modelos entre las herramientas que manejan el metamodelo de UML y repositorios de metadatos.
La especicacin de MOF [90] dene un conjunto de interfaces IDL en o CORBA que pueden usarse para denir y manipular un conjunto de metamodelos y sus correspondientes modelos. Entre estos metamodelos estn el a metamodelo de UML, el metametamodelo de MOF y, segn los planes acu tuales, estarn los metamodelos de las nuevas propuestas del OMG que usen a metamodelado.
UML y MOF estn basados en la arquitectura de metamodelado de cuaa tro niveles, por lo que se ha intentado que estn lo ms alineado posible y e a que comparan la mayor parte de los elementos semnticos centrales. Este alia neamiento permite reutilizar los elemento 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 e diferencias, la similitud entre la estructura de ambos modelos es muy grande y la mayor de los conceptos pueden ser traducidos de un nivel a otro a de manera directa. Para aquellos elementos para los que no es posible esta aplicacin inmediata, se denen reglas de transicin de un nivel a otro. o o
54
6. Metodolog de desarrollo de sistemas de tiempo real as
6.
Metodolog de desarrollo de sistemas de as tiempo real

Metodolog estructuradas as
6.1.
McDermid [79] divide los mtodos de diseo en informales, estructurae n das y formales. Los estructurados se diferencian de los informales en que aqullos usan mtodos de representacin, que pueden ser grcos, bien dee e o a nidos, construidos a partir de un pequeo nmero de componentes predenin u dos interconectados de manera controlada. Sin embargo, a diferencia de los mtodos formales, los lenguajes de los mtodos estructurados carecen de la e e base matemtica que permita realizar anlisis formal de propiedades del sisa a tema. Las metodolog estructuradas no incorporan fundamentos formales as debido a la complejidad que presentan, que implica un coste muy alto en la formacin de personal cualicado para su uso, especialmente en sistemas de o gran complejidad. HOOD [49], JSD [62] y MASCOT [113] son algunos ejemplos de metodolog estructuradas de diseo. Estas metodolog incorporan mecanismos as n as para especicar las caracter sticas no funcionales de los sistemas de tiempo real, como la concurrencia, los requisitos temporales, la tolerancia a fallos y la interaccin con los dispositivos f o sicos. Las metodolog estructuradas ms usadas son las denominadas metoas a dolog de diseo modular, que incorporan aspectos funcionales para la esas n pecicacin de requisitos y abstracciones de datos en el resto del diseo. o n A partir de los requisitos se obtienen diagramas de ujos de datos que identican procesos secuenciales de clculos y que pueden ser renados hasta a obtener transformaciones de datos de bajo nivel. En el siguiente paso se tiene en cuenta la concurrencia inherente del siste-
55
ma y se agrupan los ujos de control secuenciales en hebras de accin concuo rrentes, en funcin de diferentes heur o sticos. Por ejemplo, se pueden agrupar en funcin de los componentes f o sicos que usen, en base a consideraciones temporales o a su criticidad. Seguidamente, se denen las tareas que van a componer el sistema a partir de las hebras de accin concurrentes previas. La divisin en tareas o o depender del estudio de la concurrencia de la aplicacin, la conexin entre a o o procesos y el acoplamiento y la cohesin entre las tareas. En esta denicin o o se tiene en cuenta el modelo de tareas en el que se se van a implementar, para que dicha implementacin sea lo ms fcil posible. o a a 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 a en objetos. La caracter stica diferenciadora es que en estas metodolog se as tiene en cuenta la concurrencia antes que el modelo de datos.
6.2.
Metodolog orientadas a objetos as
La cualidad fundamental de las metodolog orientadas a objetos es que as construyen el sistema desde un primer momento enfocando la atencin sobre o los datos, creando una red de entidades que se comunican, llamadas objetos. Estas metodolog se han mostrado especialmente adecuada en la denicin as o de sistemas interactivos, por lo que se adecan bien a los sistemas de tiempo u real. Hay dos modelos de concurrencia en los diseos orientados a objetos, n el impl cito y el expl cito. En el impl cito se supone en las primeras fases del diseo que cada objeto es una unidad concurrente de ejecucin y los n o anlisis se hacen en funcin de esa suposicin. En las fases nales, el modelo a o o de concurrencia se concreta en funcin de las posibilidades que ofrezca el o
56
sistema subyacente. En el modelo expl cito los objetos se agrupan desde un primer momento en procesos, que son los elementos concurrentes. De entre estas metodolog destacamos HRT-HOOD, Octopus y ROOM as que describimos brevemente en las siguientes secciones.
HRT-HOOD HRT-HOOD [29] surge como una extensin de HOOD para incorporar los o aspectos no funcionales de los sistemas de tiempo real. HRT-HOOD complementa las fases que considera habituales en otras metodolog de desarrollo as de software denicin de requisitos, diseo estructural, diseo detallado, o n n codicacin y pruebas para evitar que los aspectos claves en los sistemas o de tiempo real se aborden demasiado tarde. Para construir el sistema se describen compromisos, cada vez ms esa pec cos, que no se pueden modicar 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 o para el siguiente nivel est frecuentemente limitado por las restricciones que a imponen los niveles inferiores. Esos tres elementos inuyen en gran medida en el diseo estructural. n En el diseo de la parte lgica de la arquitectura se suelen tratar aspectos n o funcionales y es, en general, independiente de las restricciones del entorno f sico. La parte f sica de la arquitectura tiene en cuenta los requisitos y otras restricciones y se encarga de los aspectos no funcionales. La arquitectura f sica es la base de los anlisis de los requisitos no funcionales una vez que se a hayan llevado a cabo el diseo detallado y la implementacin. La arquitectura n o f sica es un renamiento de la lgica, aunque ambas se van desarrollando en o un proceso iterativo y concurrente.
57
Una vez terminado el diseo estructural se procede a realizar el diseo n n detallado, sobre el que habr que hacer nuevas estimaciones del tiempo de a respuesta del cdigo conseguido, para ver si se sigue cumpliendo el anlisis de o a planicabilidad que se hizo en el diseo de la arquitectura f n sica, generalmente con tiempos estimados de manera menos precisa. En el diseo de la arquitectura lgica slo se permite un conjunto concreto n o o de objetos: activos, pasivos, protegidos, c clicos y espordicos. Cada tipo a est restringido en varios aspectos, como el tipo de llamadas que puede hacer a o la concurrencia interna, para facilitar el anlisis. a La fase de diseo f n sico lleva a cabo la aplicacin de los elementos deo nidos en la arquitectura lgica a los elementos f o sicos sobre los que se construir el sistema. Para realizar los anlisis necesarios sobre las caracter a a sticas no funcionales hace falta que el diseo se haya hecho de forma que permita el n anlisis y que se puedan conocer las caracter a sticas temporales de la plataforma sobre la que se ejecutar el sistema. En esta fase se han de realizar tareas a de ubicacin de objetos, planicacin de procesos y redes y dependabilidad, o o incluyendo las cuestiones relativas al manejo de errores. Los elementos del diseo se representan grcamente mediante objetos, n a similares a los de HOOD. La unica diferencia es que incluye nueva informacin o 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 o a simples. Los requisitos no funcionales se expresan a travs de atributos de e tiempo real que indican cuestiones como el per odo, plazos temporales, etc. HRT-HOOD ofrece reglas sobre cmo traducir los objetos especicados o a cdigo en un lenguaje de programacin, preferiblemente Ada 95. Tambin o o e se ofrecen reglas sobre cmo habilitar los objetos en funcin de su tipo en o o los diferentes nodos de la red en un sistema distribuido para permitir la
58
planicabilidad. En la gura 1.6 se muestra el esquema de mayor nivel de una bomba de extraccin de agua en una mina especicado en HRT-HOOD. o
Sensor del nivel de agua
Pr Controlador AB LSER by IT sensor alto LSER by IT sensor bajo PSER sensor alto IH PSER sensor bajo IH
marca agua S ManejadorAB
ASER
start
estado bomba
lectura alarma
marca agua
motor
consola operador
registro datos
Figura 1.6: Parte del sistema de control de una mina especicado en HRTHOOD (extra de [29]. do
Octopus Octopus [63] es una metodolog basada en otras dos previas, OMT [101] a y Fusion [33], que ha intentado mantener las partes positivas de ambas y aadir los elementos necesarios para el desarrollo de sistemas de tiempo real. n
59
Octopus tiene modelos estructural, funcional y dinmico a nivel de sisa tema, subsistema, clases y objetos. Estos niveles de abstraccin se reparo ten entre las diferentes fases: de requisitos, de arquitectura de sistemas, de anlisis de subsistemas, de diseo de subsistemas y de implementacin de a n o subsistemas. En la fase de especicacin de requisitos se intentan identicar los requio sitos relevantes para el software describindolos mediante casos de uso [64]. e Los casos de uso se describen en lenguaje natural y se puede mostrar la relacin entre ellos a travs de diagramas de casos de uso. El paso nal de esta o e fase en la construccin del diagrama de contexto del sistema, en el que se o muestran las relaciones entre el entorno y el sistema. En la fase de arquitectura del sistema, ste es dividido en subsistemas para e poder abordar la complejidad del conjunto. La divisin en subsistemas facilita o el desarrollo en paralelo y la reusabilidad, aunque obliga a denir de manera cuidadosa los interfaces entre los diferentes subsistemas. Para conseguir que el desarrollo del software sea independiente del hardware subyacente, en los proyectos en Octopus siempre hay una capa que a el hardware. sla En la fase de anlisis se describen los subsistemas como una composia cin de objetos. Se usa el modelo impl o cito de concurrencia. Los objetos se describen desde tres puntos de vista, el modelo de objetos, que describe la estructura esttica en base a diagramas de clases, el modelo funcional, que a describe la interfaz funcional en base a impresos de operaciones, y el modelo dinmico, que describe las operaciones del subsistema y aborda los aspectos a reactivos y de tiempo real. Para los distintos pasos de esta fase se usan diferentes diagramas, entre los que podemos citar las mquinas de estados y a MSC para los escenarios. En la fase de diseo se pasa del modelo impl n cito de concurrencia a uno
60
expl cito, asignando objetos a procesos. El proceso consta de varios pasos. Primero se establecen las hebras de interaccin entre objetos y se depuran o hasta que se convierten en hebras de eventos. Despus se establece el tipo e de conexin entre los objetos, s o ncrona o as ncrona. Finalmente, los objetos se agrupan y se perlan los procesos asociados a los grupos de objetos. En esta fase se establecen qu objetos de los subsistemas responden a los eventos e externos y cules son las secuencias de acciones que componen la respuesta a total. La fase de implementacin depende del entorno nal y del lenguaje de o programacin. Parte de la traduccin al cdigo ejecutable puede ser automao o o tizada, como, por ejemplo, las cabeceras de las clases. Esta metodolog no incluye ningn mecanismo de anlisis de propiedades a u a temporales, como la planicabilidad. Octopus/UML [96] es una versin mejorada de Octopus que cumple la o terminolog y la notacin denida en UML. En algunos aspectos va ms a o a all de UML, especialmente en los aspectos propios de los sistemas de tiempo a real. Los elementos nuevos que no se adecuan a UML son denominados Special Octopus Features (SOF).
ROOM ROOM (Real-Time Object Oriented Modeling) [110] es otra metodolog a de desarrollo orientada a objetos y, segn sus autores, cubre las deciencias u de otras metodolog anteriores para el desarrollo de sistemas de tiempo real. as Para ello se centra en desarrollar sistemas de este tipo, incluyendo un conjunto bsico de elementos de diseo suciente para describir adecuadamente a n los sistemas de tiempo real, pero sin querer ser una metodolog demasiado a genrica para mantener su utilidad y evitar que sea demasiado complicada. e
61
Los modelos usados son grcos y se han intentando eliminar las discontia nuidades entre las diferentes etapas para reducir la posibilidad de errores. ROOM puede usarse para crear un modelo ejecutable orientado a objetos de un sistema de tiempo real y para soportar estrategias comnmente usadas u en la construccin de modelos. o El elemento bsico de los modelos de ROOM son las clases de actores, a que representan un conjunto de objetos con caracter sticas y funcionamiento comunes. Estos objetos, u actores, son instancias de las clases de actores y representan mquinas lgicas, independientes y que funcionan concurrentea o mente. Los actores del sistema se comunican a travs del env y recepcin de e o o mensajes. Los conjuntos de mensajes relacionados se agrupan en clases de protocolos. Estas clases de protocolos especican las seales asociadas a los n mensajes, la direccin de env y los datos que se intercambian. o o Los actores se relacionan entre s asociando uno de los elementos de sus interfaces, los puertos, a los protocolos previamente denidos. Los puertos son, por tanto, v de comunicacin claramente identicados por los que as o uye la informacin a travs de un conjunto de mensajes bien denidos por o e el protocolo. El funcionamiento de los actores de una clase se especica mediante mquinas de estados (llamadas aqu ROOMcharts). En estas mquinas las a a transiciones entre estados son disparadas por la llegada de un mensaje a travs de los puertos de la interfaz del objeto. Cuando una mquina de estae a dos cambia de un estado a otro como respuesta a la llegada de un mensaje, se ejecutan varias acciones asociadas, respectivamente, al estado de salida, la transicin y el estado de llegada. Tambin se pueden denir variables de o e estado extendidas en trminos de clases de datos. e
62
El mbito de complejidad de los actores puede ser tan grande como se nea cesite. Los actores complejos se pueden denir jerrquicamente en funcin de a o otros actores ms simples, as como las mquinas de estados pueden expandir a a sus estados para denir el funcionamiento a mayor nivel de detalle. Los diagramas de ROOM pueden incorporar instrucciones de otros lenguajes de programacin para representar detalles de bajo nivel como el paso o de mensajes o la manipulacin de datos. o ROOM usa secuencias de mensajes para especicar escenarios, que se pueden usar para denir los requisitos que se esperan del sistema y contrastarlo con ejecuciones reales del sistema para comprobar si se cumplen aqullos. e La mquina virtual de ROOM ofrece servicios de tiempo a travs de un a e protocolo que permite acceder al instante actual de un reloj global, activar y desactivar temporizadores y generar seales de timeout. n ROOM proporciona la mayor de las caracter a sticas de la orientacin o a objetos, como la herencia y la especializacin y la creacin dinmica de o o a actores y relaciones. Sin embargo, estas cuestiones no han sido bien resueltas a d de hoy en lo relacionado con sus consecuencias sobre el funcionamiento a de tiempo real del sistema. ROOM asume un modelo de prioridades de eventos, pero sin prioridad garantizada. Aunque la idea de asignar prioridades a los eventos en vez de a los procesos tambin la defendemos en la metodolog que proponemos, en e a ROOM no se garantiza la semntica de las prioridades para evitar tener que a resolver cuestiones que pueden surgir, como la inversin de prioridades. o La validacin se hace mediante ejecucin de escenarios, especialmente a o o alto nivel de abstraccin. La del cdigo de bajo nivel se hace con mtodos o o e tradicionales. ROOM tampoco incorpora mecanismos para realizar anlisis de plania
63
cabilidad del sistema.
6.3.
SOMT
Metodolog basadas en SDL as
La tecnolog SOMT [44] integra anlisis orientado a objetos con diseo en a a n 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. o La metodolog SOMT se divide en las cinco fases habituales: anlisis a a de requisitos, anlisis del sistema, diseo del sistema, diseo de objetos e a n n implementacin. Adems de estas fases, la metodolog aade como elemento o a a n fundamental gu para pasar de los modelos de una fase a los de la siguiente. as En la fase de anlisis de requisitos se parte de un documento textual de a requisitos y se intenta conseguir una denicin formal de los mismos. Esta o denicin se hace a distintos niveles. Por un lado, se realizan diagramas de o 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. e En el anlisis de sistemas se describe la arquitectura del sistema y se a identican los objetos necesarios para implementar la funcionalidad requerida. Los objetos se representan mediante diagramas de clases y las relaciones entre ellos se especican mediante escenarios descritos en MSC. En el diseo del sistema se dene la estructura de implementacin y n o se identican las estrategias globales de diseo. En esta fase se denen la n estructura modular del diseo y la denicin de la arquitectura mediante n o diagramas de sistemas y bloques en SDL y denicin de interfaces basados o en seales y llamadas remotas a procedimientos. Tambin se establecen los n e
64
casos de uso del diseo mediante MSC. n En la fase de diseo de objetos se crea una descripcin completa y forn o malmente vericable del funcionamiento del sistema, bsicamente mediante a diagramas de procesos en SDL. Esta fase tambin incluye tareas de prueba e y vericacin. o En la fase de implementacin y pruebas se produce el producto ejecutable o nal. Las actividades de esta fase pueden incluir la generacin automtica de o a cdigo, la integracin en el entorno f o o sico y la realizacin de pruebas. o Una de las herramientas que proporciona la metodolog SOMT para a 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 o 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 a n 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 o comprobar mejor su coherencia, especialmente cuando se producen cambios.
The Codesign Methodology Mitschele-Thiel y Slomka proponen en [83] una metodolog de diseo a n mixto de sistemas con componentes f sicos y lgicos basada en extensiones o de SDL y MSC, reutilizando procesos de desarrollo con estos formalismos previos. Ambos son extendidos para incluir aspectos no funcionales y de implementacin. o MSC es extendido para incluir la expresin de restricciones temporales. o Esta extensin es denominada PMSC. SDL tambin es extendido en un leno e guaje denominado SDL* (ver seccin 4.1). En ambos casos las extensiones o consisten en anotaciones sobre diagramas en los lenguajes originales que in-
65
cluyen informacin no funcional, como restricciones de tiempo o de desplieo gue en componentes f sicos. Con estas extensiones se pretenden abordar los aspectos no funcionales y de implementacin de manera formal. o La metodolog sigue un desarrollo iterativo en el que cada ciclo corresa ponde a una fase del desarrollo: diseo inicial, formalizacin, diseo de la n o n implementacin e implementacin nal. Durante el diseo se realiza un reo o n namiento paralelo desde la especicacin en PMSC y SDL* hasta la impleo mentacin en VHDL [19] y C. o La fase inicial de especicacin de requisitos produce la descripcin ino o formal 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, n empleando las extensiones para incluir los requisitos temporales. Con alguna informacin adicional, sobre este primer diseo pueden llevarse a cabo o n anlisis de rendimiento y contrastar sus resultados con las restricciones tema porales especicadas. En esta fase se hace en SDL* la descripcin estructural o del sistema. En la fase de formalizacin se hace un renamiento paralelo de la eso tructura descrita en SDL* y de los casos de uso en PMSC que reejen el renamiento de SDL*. En esta fase se incluyen los aspectos no funcionales en el diseo SDL*, como los necesarios para realizar la divisin entre compon o nentes f sicos y lgicos. Los anlisis de rendimiento de la fase anterior pueden o a servir ahora para centrarse en aquellas partes del sistemas que presentan mayores problemas en esta faceta. Los diseos renados, tanto en PMSC como n SDL*, tambin son analizados desde el punto de vista del rendimiento. e En la fase de implementacin se llevan a cabo los estudios de vericacin o o y simulacin para, por ejemplo, estudiar la presencia de bloqueos o la planio cabilidad. A continuacin se genera el cdigo de manera automtica, en C o o a
66
para la parte lgica y en VHDL para los componentes f o sicos, pudiendo escoger entre una biblioteca de componentes predenidos o crear componentes espec cos para la aplicacin. o En la fase de pruebas se pueden generar bancos de pruebas de manera automtica a partir de la especicacin de los aspectos funcionales. Estas a o pruebas suelen estar descritas en TTCN [48]. Los autores han desarrollado una extensin de TTCN para tener en cuenta aspectos temporales especio cados en PMSC. La metodolog est soportada por un conjunto de herramientas aua a tomticas que tienen como datos de entrada la descripcin de la arquitectura a o del sistema y de su funcionamiento dinmico en SDL* y PMSC, respectivaa mente, y que, en diferentes pasos, y teniendo en cuenta informacin adicional o de las bibliotecas de componentes lgicos y f o sicos, acaba haciendo una optimizacin del sistema, que es otra descripcin SDL* del sistema que cumple o o las restricciones especicadas.
6.4.
Metodolog basadas en UML as
ROPES La metodolog ROPES Rapid Object Oriented Prototyping for Embedded a Systems [39] hace uso de UML para crear los modelos de las diferentes fases del desarrollo en que se divide: anlisis, diseo, traduccin y pruebas. ROPES a n o sigue un ciclo de vida iterativo y fomenta la creacin temprana de prototipos o para vericar la calidad del sistema. La fase de anlisis se compone de tres subfases. La primera es la fase de a anlisis de requisitos, en la que se establecen los objetivos que ha de cumplir a el programa. En esta fase se han de identicar los casos de uso y los actores y eventos externos, ya que el sistema se ve an como una caja negra. Si los u
67
casos de uso son muy complejos, se descomponen y se relacionan entre s . Tambin tienen que identicarse las restricciones, como las interfaces o los e parmetros de rendimiento, entre los que se incluyen los requisitos de tiempo a real de los eventos identicados. 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 a casos de uso se emplean diagramas de secuencia y de estados. La siguiente subfase en aquellos sistemas cuya dimensin lo justique o es el anlisis de sistema, donde se establece qu partes del sistemas sern a e a implementadas mediante dispositivos f sicos y cules sern programadas. a a En la fase del anlisis de objetos se identican los objetos del sistema y las a clases que los contienen. Se relacionan entre s se identican sus operaciones, , se dene el funcionamiento dinmico y se traducen los requisitos temporales a 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 a a de los objetos se usan diagramas de estados asociados a las clases y se denen 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 n o manera eciente, y cumpliendo las restricciones impuestas, el modelo que resulta de la fase de anlisis. En esta fase emerge de manera expl a cita el modelo de concurrencia, ya que se distinguen los objetos activos y los pasivos. Tambin se elige la pol e tica de planicacin y de asignacin de prioridades. o o Se asignan las clases y objetos a los componentes, en especial cuando se trata con sistemas distribuidos. Se implementan las relaciones y las mquinas a de estados. En la metodolog se divide el diseo en tres fases: estructural, a n
68
mecnico y detallado. En cada una de ellas las actividades que se llevan a a cabo son cada vez de mayor nivel de detalle. Tras el diseo se efecta la traduccin del modelo UML a cdigo fuenn u o o te. Y, con ayuda de un compilador, ste se traduce a cdigo ejecutable. La e o traduccin de UML a cdigo fuente puede ser llevada a cabo en parte por o o herramientas automticas, pero el programador ha de incluir todav gran a a parte del cdigo manualmente. Se incluyen pruebas de caja blanca, que pueo den ser incrementales, en las que se van incluyendo mdulos en el sistema, o o de validacin del sistema completo. o Finalmente, se propone la realizacin de bancos de pruebas basados prino cipalmente en los escenarios identicados. En el libro en que detalla la metodolog el autor reserva la ultima parte a, a hablar de modelado orientado a objetos de tiempo real avanzado, en el que detalla cuestiones relativas al modelo de tareas y su planicacin, el o modelado dinmico y los marcos de tiempo real. a Aunque, en general, la presentacin de la metodolog es de muy alta o a calidad desde el punto de vista de la ingenier del software, por otro lado, a da la impresin de que el uso que hace de UML es demasiado genrico, o e sin extenderlo ni adaptarlo para las caracter sticas propias de los sistemas de tiempo real, an cuando muchos autores han hecho notar la falta de u adecuacin de UML para algunas cuestiones de dichos sistemas. o
UML para el modelado de sistemas complejos de tiempo real Selic y Rumbaugh deenden en [111] la utilidad de la metodolog ROOM a (ver seccin 6.2) en el desarrollo de sistemas de tiempo real, en especial los o dirigidos por eventos y distribuidos, debido en parte a la presencia de elementos especializados en la denicin de la arquitectura de este tipo de sistemas. o
69
En este trabajo, actualizan los elementos de la metodolog ROOM a los a conceptos en los que se basa UML sin tener que denir nuevos elementos ni modicar el metamodelo, sino haciendo uso de los mecanismos de extensin usuales de UML. Por ejemplo, el concepto bsico de actor de ROOM o a es capturado mediante una especializacin del concepto de clase usando el o estereotipo ((capsule)). Los constructores usados para representar los conceptos de tiempo real se dividen en dos grupos, los de modelado estructural y los de modelado de funcionamiento. La especicacin completa de las estructura se consigue a travs de una o e combinacin de diagramas de clases y diagramas de colaboracin. Los primeo o ros muestran las clases del sistema y las relaciones permanentes entre ellas, independiente del uso concreto. En los diagramas de colaboracin se explio citan las relaciones entre objetos de las clases determinadas por ciertos usos concretos del sistema. Los tres constructores principales del modelo estructural son las cpsulas, los puertos y los conectores. a Las cpsulas corresponden al concepto de actor de ROOM. Son entidaa des complejas, que interaccionan con el resto del sistema a travs de objetos e denominados puertos. Los puertos se encargan de procesar las seales de enn trada/salida con las que la cpsula se comunica con su entorno. Cada puerto a tiene un protocolo asociado que determina cules son las seales que puea n den comunicarse por l. Al restringir de esta manera la comunicacin de las e o cpsulas con su entorno se reduce el acoplamiento y se consiguen objetos a ms reutilizables. Los conectores, que corresponden al concepto ROOM de a ligaduras, son vistas abstractas de los canales de comunicacin que coneco tan dos o ms puertos. Los puertos ligados por una conexin deben jugar a o un papel complementario en el protocolo. Los conectores se representan en
70
los diagramas de colaboracin mediante papeles de asociacin y capturan las o o comunicaciones claves entre clases, mostrando cules afectan a otras directaa mente. Las cpsulas que corresponden a elementos complejos se pueden dividir a jerrquicamente en diagramas de subcpsulas unidas mediante conectores. a a Esta divisin se puede repetir hasta conseguir cpsulas sucientemente simo a ples. La relacin entre la subcpsulas se representa con diagramas de colao a boracin de UML. El funcionamiento dinmico de una cpsula se expresa o a a mediante mquinas de estados que se comunican con el exterior a travs de a e los puertos nales, de los que recibe las seales externas. Cada subcpsula n a puede tener su propia mquina de estados. Las mquinas de estados pueden a a crear y destruir dinmicamente subcpsulas. Se pueden denir papeles de coa a nexin, que son moldes genricos que se pueden concretar a posteriori con o e subcpsulas concretas. Las mquinas de estados se pueden especializar segn a a u los mecanismos denidos en UML. Los puertos de las cpsulas se dividen en dos categor cuando se ven a as desde el interior, los relay ports, que se conectan a las subcpsulas y los end a ports, que se conectan a la mquina de estados de la cpsula. a a El modelado dinmico se hace a travs de los protocolos, que especican a e el funcionamiento deseado de los conectores. Un protocolo se compone de un conjunto de participantes, cada uno de los cuales juega un papel en el protocolo. Cada papel en el protocolo tiene una lista de las seales que puen de enviar y otra de las que puede recibir. El funcionamiento dinmico del a protocolo se puede especicar mediante una mquina de estados y, adems, a a algunas interacciones concretas especialmente interesantes se pueden especicar mediante diagramas de secuencias, que han de ser compatibles con la mquina de estados. a
71
Los servicios de tiempo que necesitan las cpsulas para ejecutar acciones a relacionadas con el tiempo se adquieren a travs de puertos de acceso a e servicios concretos que proporcionan habilidades para disparar una transicin o en un instante absoluto o en uno relativo. Los puertos se modelan en UML mediante el estereotipo ((port)) aplicado a la clase Class. Los puertos tienen una relacin de realizacin respecto al o o papel de protocolo que implementan y una relacin de composicin respecto o o a la cpsula a la que pertenecen. a Los conectores se modelan mediante una asociacin y se declaran a travs o e de un papel de asociacin en un diagrama de colaboracin de cpsulas. o o a Las cpsulas se modelan mediante el estereotipo ((capsule)) aplicado a la a clase Class. Las cpsulas tienen relaciones de composicin con sus compoa o nentes, los puertos, las subcpsulas y los conectores internos. Los puertos de a una cpsula aparecen listados en un compartimento propio en el dibujo de la a cpsula. En los diagramas de colaboracin, los puertos de las instancias de a o las cpsulas se suelen mostrar como un cuadrado negro (el puerto conjugado a se muestra en blanco). Los protocolos se modelan mediante el estereotipo ((protocol)) aplicado a la clase Collaboration. Un protocolo est asociado con todos sus papeles a de protocolo. Los papeles de protocolo se modelan mediante el estereotipo ((protocolRole)) aplicado a la clase ClassifierRole. Cada papel de protocolo tiene asociaciones con la clase Signal para especicar las listas de seales de entrada y salida. n En las guras 1.7 y 1.8 se muestran, respectivamente, los diagramas de clases y colaboracin de un sistema simple en el que se ilustran algunos de o los elementos de UML usados para modelar los conceptos de ROOM. Aunque los autores de esta propuesta admiten la importancia de estable-
72

<<capsule>> CReceptor <<capsule>> CEmisor
<<capsule>> CClienteX
<<capsule>> CServidor
<<capsule>> CClienteY
<<port>> puertoCA
<<port>> puertoSA
<<port>> puertoSB
<<port>> puertoCB
<<protocolrole>> clienteA seal5 seal6 seal7 seal8 incoming
<<protocolrole>> servidorA seal1 seal2 seal3 seal4 incoming
<<protocolrole>> servidorB incoming seal9 seal10 outgoing seal11 seal12
<<protocolrole>> clienteB incoming seal13 seal14 outgoing seal15 seal16
outgoing
outgoing
<<protocol>> ProtA
<<protocol>> ProtB
Figura 1.7: Diagrama de clases del sistema. cer una semntica esttica y dinmica, dicen que su denicin est fuera del a a a o a a mbito de la publicacin. o COMET La metodolog COMET (Concurrent Object Oriented and architectural a design mEThod ) [54] es un mtodo de diseo para aplicaciones concurrentes. e n En particular, aplicaciones distribuidas y de tiempo real. El proceso de desarrollo del mtodo COMET es un proceso orientado a e objetos, compatible con el Unied Software Development Process y el modelo

<<capsule>> s:CServidor <<capsule>> r:CReceptor sext:ProtA
73
sA:ProtA::servidor
<<capsule>> cx:CClienteX
sint:ProtA
cA:ProtA::cliente
<<capsule>> e:CEmisor
sB:ProtB::servidor cB:ProtB::cliente
<<capsule>> cy:CClienteY
Figura 1.8: Diagrama de colaboracin del sistema. o en espiral. El modelo COMET de ciclo de vida del software es un proceso de desarrollo altamente iterativo basado alrededor del concepto de caso de uso. Los requisitos funcionales del sistema se determinan en base a actores y casos de uso. Los casos de uso se pueden ver a diferentes niveles de detalle. En el anlia sis de requisitos, los requisitos funcionales se denen en trminos de actores y e casos de uso. En el modelo de anlisis, se renan los casos de uso para descria bir los objetos que participan y cmo interaccionan. En el modelo de diseo, o n se desarrolla la arquitectura software, atendiendo las cuestiones relacionadas con la distribucin, concurrencia y ocultacin de informacin. o o o En la fase de requisitos se desarrolla el modelo de requisitos en base a casos de uso en los que participan los actores. Se incluye una descripcin textual o
74
de los casos de uso. Si los requisitos no estn claros, se puede desarrollar un a prototipo bsico para intentar entenderlos mejor. a En la fase de modelado de anlisis se desarrollan los modelos estticos y a a dinmicos del sistema. El modelo esttico se encarga de la relacin estructua a o ral entre las clases del dominio del problema. Las clases y las relaciones se representan en diagramas de clases. Una vez determinados los objetos que se van a incluir en el sistema, se desarrolla un modelo dinmico en el que se rea nan los casos de uso y se muestran qu objetos participan en cada uno y cmo e o se relacionan entre ellos. En esta fase se usan diagramas de colaboracin y de o secuencia para mostrar la dinmica de los casos de uso. Tambin se pueden a e usar mquinas de estados para aquellos casos en los que el funcionamiento a dependa del estado. En la fase de modelado del diseo, se disea la estructura software del n n sistema, en la que el modelo de anlisis se aplica sobre el entorno operacional. a Se pasa del dominio del problema, representado por el modelo de anlisis, al a dominio de la solucin, representado por el modelo del diseo. Se crean los o n diferentes subsistemas en funcin de los criterios aceptados y se establece la o comunicacin entre ellos, especialmente importante en los sistemas distribuio dos. En los sistemas concurrentes y los de tiempo real, adems de tener en a cuenta los aspectos normales en la orientacin a objetos, como la herencia, o la ocultacin de informacin, etc., hay que considerar adems los conceptos o o a no funcionales inherentes a la concurrencia y los requisitos de tiempo. Tras acabar el diseo de la estructura software, se sigue una estraten gia de construccin incremental de software, que se basa en seleccionar un o subconjunto del sistema a construir en cada incremento. El subconjunto se determina escogiendo los casos de uso que se van a construir y los objetos involucrados en ellos. Esta fase de construccin consta de diseo detallado, o n
75
codicacin y prueba de las clases incluidas en el subsistema. Las diferentes o unidades se van integrando hasta conseguir el sistema completo. Durante la integracin incremental de software se llevan a cabo las prueo bas de integracin de los subsistemas. Las pruebas se basan en los casos de o uso seleccionados para el subsistema. Estas son pruebas de caja blanca en las que se analizan las interfaces de los objetos. El resultado de estas pruebas incrementales son prototipos incrementales en los que se van incluyendo cada vez nuevas funcionalidades. Si se detectan errores graves, ser necesario a volver atrs a las fases anteriores. a Las pruebas del sistema incluyen la prueba de los requisitos funcionales. Estas pruebas ven el sistema como una caja negra y son obligatorias antes de entregar un prototipo o el sistema nal al usuario.
6.5.
Herramientas automticas de dise o a n
Diversas herramientas comerciales implementan estas metodolog o al as, menos dan soporte a parte de ellas. Una de las primeras herramientas de modelado basado en objetos que ofreci la posibilidad de generacin automtica de cdigo fue ObjectTime o o a o Developer, de la empresa ObjectTime. ObjectTime Developer se basa en la metodolog ROOM (ver seccin 6.2). Tras la aparicin y popularizacin de a o o o 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 o ROOM. Como se mencion al hablar de ROOM, el concepto fundamental es o un tipo de objeto activo, las cpsulas, que se comunican mediante mecanismos a concretos, los puertos, y cuyo funcionamiento viene denido por mquinas a de estados. Rational-Rose Real-Time incorpora la generacin de cdigo de o o
76
ObjectTime Developer, en la que cada objeto activo tiene su propia hebra de ejecucin, que acta concurrentemente con las otras hebras, y tiene su o u propia cola de eventos. Rhapsody, [97] de i-Logix, tambin ofrece todo el ciclo de vida de UML, e del anlisis de requisitos a la generacin parcial de cdigo pasando por la a o o especicacin de objetos. Sin embargo, no ofrecen herramientas de anlisis de o a propiedades de tiempo real estricto, como planicacin, ni para la validacin o o 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 funcion namiento dinmico del sistema y SDL para la fase de diseo. Incluye traduca n cin automtica entre las mquinas de estados de UML y los diagramas de o a a SDL. Ofrece generacin automtica de cdigo y herramientas de simulacin o a o o y validacin. La validacin permite vericar el funcionamiento dinmico eso o a pecicado mediante diagramas MSC, detectando posibles bloqueos, livelocks, etc. Las herramientas de simulacin permiten reproducir el funcionamiento o que lleva a esa situacin de manera fcil. o a Todas estas herramientas carecen de mecanismos para el anlisis de proa piedades de tiempo real o de base formal para la vericacin. o Igualmente, ninguna de estas herramientas ofrece la posibilidad de anotar caracter sticas temporales a los modelos, ni de analizar cuestiones temporales, como el rendimiento o la planicacin. Es ms, tampoco ofrecen la posibilidad o a de usar directamente herramientas externas de anlisis de planicabilidad. a
CAP ITULO
Una semntica de acciones para MML a
1.
Introduccin o
La semntica de acciones de UML ha sido adoptada recientemente por a
el Object Management Group (OMG) para extender UML con un mecanismo compatible para especicar la semntica de las acciones de una manera a independiente del software [4]. Esta semntica dene una extensin del mea o tamodelo de UML 1.5 que incluye una sintaxis abstracta para un lenguaje de acciones. Este lenguaje proporciona un conjunto de constructores simples para las acciones como, por ejemplo, acciones de escritura, condicionales y compuestas, que pueden usarse para describir el funcionamiento computacional de un modelo UML. Una parte clave de la propuesta es la descripcin o en ingls de la semntica del funcionamiento de los objetos, basada en un e a modelo de la historia de las ejecuciones de los objetos. Desafortunadamente, la propuesta de la semntica de acciones sufre de a un problema frecuente cuando se desarrollan metamodelos grandes en UML cmo estructurar el modelo de forma que queden claramente separados o sus diferentes componentes. Cuando no se consigue este objetivo, el me77
78
1. Introduccin o
tamodelo resultante es dif de entender y modicar, y en particular, de cil especializar y extender. Adems, los metamodelos basados en la semntica a a actual de UML sufren de la falta de un ncleo con una semntica denida u a de manera precisa sobre el que construir el metamodelo. Esto signica que a menudo es dif asegurar la correccin del modelo, y para superar esto, cil o debe invertirse una gran cantidad de trabajo en aclarar la semntica antes de a que se puedan hacer ms progresos. En el lado positivo, el modelo semntico a a bsico usado en la semntica de acciones, con sus nociones de snapshots, hisa a torias y cambios parece muy apropiado para denir los diferentes valores que van cambiando en el sistema. Adems, las acciones denidas en la propuesta a cubren de manera sistemtica el amplio rango de acciones necesarias para a un lenguaje de acciones util. As si se puede de alguna forma reestructurar , mejor lo que es un trabajo signicativo, entonces habr benecios claros para a los desarrolladores y usuarios del lenguaje.
En este cap tulo vamos a mostrar cmo la denicin de un ncleo con una o o u semntica precisa y el uso de un mecanismo de extensin de paquetes al estilo a o de Catalisis [41] puede generar una denicin mejor estructurada y adaptable o de la semntica de acciones. El trabajo est basado en una extensin del a a o Meta-Modelling Language (MML) [31], un lenguaje de metamodelado preciso desarrollado para conseguir que UML se pueda reconstruir como una familia de lenguajes de modelado. MML tiene muchas caracter sticas en comn con u el metamodelo de UML. Adems, es ms pequeo y ya tiene una semntica a a n a modelada, siendo as una base util para explorar la semntica de acciones a en general. Sin embargo, hay que dejar claro que ste no es un intento de e resolver el problema general de la ejecutabilidad de modelos, sino slo una o propuesta para describir la ejecutabilidad en el contexto de MML.
Cap tulo 2. Una semntica de acciones para MML a
79
1.1.
Los fundamentos del modelo MML
MML es un lenguaje de metamodelado pensado para reconstruir el ncleo u de UML de tal manera que se pueda denir de una manera mucho ms simple a y que pueda ser extendido y especializado para diferentes tipos de sistemas. Entre otros conceptos bsicos, MML establece dos distinciones ortogonales. a La primera es una correspondencia entre los conceptos del modelo (la sintaxis abstracta) y las instancias (el dominio semntico). La segunda es la distincin a o 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 a relacionados a travs de un paquete semntico que establece la relacin de e a o satisfaccin entre los modelos y las instancias vlidas. Entre los conceptos o a de modelado y la sintaxis concreta se establece una relacin similar como se o muestra en la gura 2.1). Estas distinciones se describen en trminos de un patrn de denicin e o o del lenguaje, ver gura 2.1. Cada componente del patrn es un paquete. o Como en UML, un paquete es un contenedor de clases u otros paquetes. Adems, los paquetes en MML se pueden especializar. Este es el mecanismo a clave por el que se generan deniciones extensibles del lenguaje, y es similar al mecanismo de extensin de paquetes denido en Catalysis [41]. Aqu la o , especializacin de paquetes se indica colocando una echa de especializacin o o 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 dene los conceptos de modelado bsicos usados en MML: paquetes, clases y atributos. a El paquete actual de conceptos del modelo de MML no proporciona un modelo dinmico del funcionamiento. As en las siguientes secciones se describe a ,
80
2. Principios arquitectnicos o
model
instances
concepts
concrete syntax
concepts
concrete syntax
conceptstosyntax
conceptstosyntax
semantics
Figura 2.1: El mtodo MMF. e un propuesta para la semntica de las acciones en MML, que se basa en una a extensin del paquete core de MML. o
2.
Principios arquitectnicos o
Dos han sido los objetivos principales de la denicin de la semntica de o a
acciones. El primero, incluir la semntica de acciones como el ncleo dinmia u a co de MML. MML se centr originariamente en el modelado esttico, por lo o a que una extensin natural es aadir caracter o n sticas dinmicas. Esto implica a la denicin de vistas de modelo y de instancias y la separacin que puede o o capturar tanto la nocin de acciones como los conceptos y funcionamiento o en trminos de cambios en el estado de las instancias. El segundo objetivo e es hacer uso de la simplicidad de MML y sus modelos de semnticas como a
81
base para explorar la denicin de acciones en un lenguaje del estilo de UML. o Obviamente, esto es un primer hito para trabajos posteriores para incorporar modelos similares en UML (trabajo que actualmente se est haciendo como a parte del proceso de env de propuestas para UML 2.0 [1]). Finalmente, para o conseguir el objetivo de la simplicidad, nos hemos centrado en la denicin o de un subconjunto de las acciones que se van a usar en la semntica de aca ciones. Estas acciones (WriteVariable, etc.) forman un ncleo de acciones u primitivas que todos los lenguajes de acciones deber incluir. Estas accioan nes son primitivas en el sentido de que la denicin de acciones adicionales o podr ser potencialmente descrita en trminos de estas primitivas, facilitana e do as una estrategia de denicin ms estructurada en niveles. Una ventaja o a adicional de esto es que una herramienta que pueda ejecutar las acciones primitivas puede actuar potencialmente como motor de ejecucin sobre el que o se pudieran traducir las deniciones de un lenguaje ms rico. a MML est pensado para ser extendido de manera consistente, por tanto a la denicin de las acciones se har en otro paquete en MML, siguiendo la o a estructura del resto de paquetes, es decir, el paquete deber estar compuesto a de paquetes para el modelo, las instancias y la semntica, con los paquetes de a modelo y de instancias subdivididos a su vez en paquetes para los conceptos, la sintaxis concreta y la correspondencia entre conceptos y sintaxis.
3.
N cleo dinmico u a
El ncleo dinmico (Dynamic Core) intenta modelar la evolucin de los u a o
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 unico a valor. La estrategia escogida para denir el modelo dinmico considera que los a
82
4. Acciones
elementos mutables, los objetos, evolucionan a travs de diferentes estados a e lo largo de la vida del sistema segn cambian sus valores las acciones que se u ejecutan sobre ellos. Estos estados contienen todos los valores del elemento en un instante dado. El elemento asociado a ese estado se identica por medio de un atributo, la identidad (identity), que es unica en el sistema para ese elemento. Es decir, dos estados se reeren al mismo elemento si y slo si o tienen la misma identidad. Esta relacin entre los sucesivos estados de un elemento tambin se mueso e tra por medio de la asociacin next, que signica que un estado dado es el o siguiente estado de un elemento sobre el que se ha ejecutado una accin. o Los conceptos del modelo y la semntica siguen siendo iguales que en el a ncleo esttico y es el paquete de los conceptos de instancias el que cambia. u a Cada instancia de la metaclase object representa un estado de un elemento mutable. El nuevo paquete para los conceptos de instancias del ncleo u dinmico se muestra en la gura 2.2. a
4.
Acciones
En la denicin de UML, OCL es un lenguaje formal para expresar reso
tricciones sin efectos laterales. La evaluacin de estas restricciones no cambia o ningn valor del sistema. u MML tiene su propio lenguaje de restricciones basadas en OCL con unos pocos cambios semnticos. Este lenguaje proporciona todas las expresiones a bsicas del lenguaje de OCL. El concepto actual de Expression en MML a cubre las expresiones bsicas de OCL. Estas incluyen expresiones lgicas a o (and, not, equals, includes), referencias a slots, variables e iteradores sobre tipos contenedores (sequences, sets y bags). Sin embargo, no dene otras expresiones, como las aritmticas. e
83
InstanceElement
+elements n Instance +value 1
+previous
0..1 Object identity : Integer 0..1 +next +slots n Slot
Figura 2.2: Conceptos de instancias del ncleo dinmico (paquete dynamicu a core.instances.concepts).
Los mtodos de MML se usan para denir procedimientos computacioe nales. Los mtodos no tienen efectos laterales y simplemente sirven para e evaluar un conjunto de parmetros contra una expresin OCL para obtener a o un resultado. Se puede denir un nuevo mtodo simplemente cambiando la e expresin. o
File: C:\doctorado\articulospropios\2002\sosym\actions.mdl dynamicCore.instances.concepts / Main Page 1 12:55:19 jueves, 07 de noviembre de 2002 Class Diagram:
Las acciones representarn los procedimientos computacionales que cama bian el estado de un elemento del sistema. Las acciones no tendrn una a expresin que especique lo que hace la accin, sino que denirn las nuevas o o a clases que especialicen el concepto de accin bsica. Su funcionamiento paro a ticular se describir por medio de reglas de correccin. Con esta estrategia, a o se tiene un conjunto de acciones bsicas sobre las que se van a construir las a nuevas acciones que sean necesarias. En este trabajo slo se va a denir un conjunto bsico de acciones que o a resulte suciente para permitir fcilmente la denicin de las otras acciones a o
84
4. Acciones
sobre ellas. Se distinguirn las acciones primitivas de las compuestas. Las acciones a primitivas son sucientemente simples y no necesitan denirse en trminos e de otros elementos ms simples. Las acciones compuestas se denen como una a composicin de acciones ms simples, tanto primitivas como compuestas. o a
4.1.
Conceptos de modelo
La gura 2.3 muestra la denicin de la clase abstracta Action. La clase o Action especializa la clase Classifier. Cada accin tiene un conjunto de o parmetros de entrada. Como el orden de los parmetros es signicativo, a a estas asociaciones estn ordenadas. a Los parmetros de entrada representan los valores que la accin necesita a o para ejecutarse. Estos valores pueden incluir el objeto sobre el que se aplica la accin. o 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 a o o muestra la clase a la que pertenece el objeto mbito de la accin. a o Mtodos e 1. El mtodo allActions() devuelve el conjunto de todas las acciones de e una clase, incluyendo la de sus progenitores. allActions() escoge slo o una accin en el caso de que haya mltiples padres con acciones con el o u mismo nombre. Esta es tal vez la estrategia ms simple para tratar el a tema de las colisiones en la herencia mltiple, aunque se podr mejorar u a deniendo una regla de mezcla si fuera necesario.
context uml.staticCore.model.concepts.Class
allActions() : Set(Action)
85
+inputs {ordered} n
Classifier (from staticCore.model.concepts)
{ordered} +inputs n
Instance
{ordered} +outputs n
Action
Execution +executions {ordered} n
+actions n
+scope
1
+scope Object
Class (from staticCore.model.concepts)
Figura 2.3: Paquete tions.model.concepts.
ac-
Figura 2.4: Paquete tions.instance.concepts.

1 +of n +instance Execution
ac-
Action
Figura 2.5: Paquete actions.model.semantics.
parents->iterate(p; s = actions | s ->union(p.allActions()-> reject(c | actions->exists(c | c.name = c.name)))
2. El mtodo allSubActions() devuelve todas las subacciones de una e accin, anidadas a cualquier profundidad. o
context uml.actions.model.concepts.Action
File: C:\doctorado\articulospropios\2002\sosym\actions.mdl actions.instance.concepts / Main Page 1 allSubActions() : Set(Action) 10:57:36 mircoles, 06 de noviembre de 2002 Class Diagram:
File: C:\doctorado\articulospropios\2002\sosym\actions.mdl actions.model.concepts / Main Page 1
10:51:41 mircoles, 06 de noviembre de 2002
Class Diagram:
self.subactions-> union(self.subactions.allSubActions()->asSet())
86
4. Acciones
4.2.
Conceptos de instancias
La clase Execution est denida en el paquete de conceptos de instancias a mostrado en la gura 2.4. Una instancia de la clase Execution representa una ejecucin real de una accin. o o 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 modica en la ejecucin. Una ejecucin tambin tiene valores de salida. o o e Entre ellos est el nuevo estado del elemento modicado. a Una instancia de Execution tambin tiene una asociacin con la instancia e o de la clase Object que la ejecuta, la asociacin self. o Aunque no hay nocin de tiempo ni, por tanto, de ordenacin temporal o o en el modelo dinmico, hay una relacin causal entre las ejecuciones en el a o sistema. Para una ejecucin puede haber una ejecucin previa (previous) y o o otra siguiente (next). Tambin hay una relacin causal entre la ejecucin de la accin y los e o o o valores usados en ella. Como una accin no puede ejecutarse hasta que todos o los valores de entrada hayan sido calculados, los valores producidos despus de e la ejecucin de la accin no pueden ser usados como parmetros de entrada. o o a La semntica de este paquete se muestra en la gura 2.5. a Mtodos e 1. El mtodo allSubExecutions() devuelve todas las subejecuciones de e una ejecucin, anidadas a cualquier profundidad. o
context uml.actions.instance.concepts.Execution
allSubExecutions() : Set(Execution) self.subexecution-> union(self.subexections.allSubExecutions()->asSet())
87
Reglas de correccin o 1. Una salida de una ejecucin no puede ser usada como entrada de esa o ejecucin. o
context uml.actions.instance.concepts.Execution inv:
inputs->forall(i| outputs->forall(o| i <>o))
5.
Acciones primitivas
Una accin primitiva es una accin que no se descompone en acciones o o
ms simples. La caracter a stica comn de las acciones primitivas es que no u tienen subacciones. PrimitiveAction es una clase abstracta que se especializa en tres subclases diferentes: la accin nula (NullAction), la creacin de un objeto o o (CreateObjectAction) y la modicacin del valor del atributo de un objeto o (WriteSlotAction). Las guras 2.6, 2.7 y 2.8 muestran, respectivamente, los paquetes de conceptos del modelo, conceptos de instancias y semntica. a Mtodos e 1. El mtodo subActions() devuelve el conjunto de subacciones inmediae tas de una accin. Para las acciones primitivas este conjunto es vac o o.
context uml.actions.model.concepts.PrimitiveAction
subActions() : Set(Action) Set{}
2. El mtodo subExecutions() devuelve el conjunto de subejecuciones e inmediatas de esa ejecucin. Para las ejecuciones de acciones simples o
88
5. Acciones primitivas
Action
PrimitiveAction
CreateObjectAction
NullAction
WriteSlotAction
+target
1 Class
1 +target
+attribute
1 Attribute
Figura 2.6: Paquete de conceptos del modelo de las acciones primitivas (primitiveactions.model.concepts).
ese conjunto es vac o.

context uml.actions.instance.concepts.PrimitiveExecution
subExecutions() : Set(Execution) Set{}
5.1.
Accin nula o
La accin nula, como su nombre indica, no hace cambios en el sistema. Se o

File: C:\doctorado\articulospropios\2002\sosym\actions.mdl primitiveActions.model.concepts / Main Page 1
incluye porque las acciones compuestas 06 dehan denido para tener al menos se noviembre de 2002 Class Diagram: 11:14:44 mircoles, una subaccin. o
89
Execution
PrimitiveExecution
CreateObjectExecution
NullExecution
WriteSlotExecution
+target
+target 1
+slot Slot (from staticCore.instance.concepts)
Object (from staticCore.instance.concepts)
Figura 2.7: Paquete de los conceptos de instancia de las acciones primitivas (primitiveactions.instance.concepts). Reglas de correccin o 1. Una accin nula no tiene parmetros de entrada. o a
context uml.primitiveActions.model.concepts.NullAction inv:
self.inputs->size = 0
2. Una instancia de NullExecution no tiene ni parmetros de entrada ni a valores de salida.

File: C:\doctorado\articulospropios\2002\sosym\actions.mdl primitiveActions.instance.concepts / Main Page 1
context uml.primitiveActions.instance.concepts.NullExecution inv: 11:18:40 mircoles, 06 de noviembre de 2002 Class Diagram:
self.inputs->size = 0 and self.outputs->size = 0
90
NullAction
+of 1 +of 1
+instances * +instances n
NullExecution
CreateObjectAction
CreateObjectExecution
WriteSlotAction +of 1
+instances n
WriteSlotExecution
Figura 2.8: Paquete de la semntica de las acciones primitivas (primitiveaca tions.semantics).
5.2.
Accin de crear un objeto o
Una accin de la clase CreateObjectAction aade un nuevo objeto al o n 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 unica entrada se ha renombrado, por claridad, como target. La ejecucin de una accin de creacin de un objeto tiene un resultado, el o o o objeto creado. Esta accin no hace nada ms, ni siquiera inicializa los valores o a de los atributos del nuevo objeto. Para asegurar que el objeto es nuevo, ste e no puede tener un estado previo. Reglas de correccin o 1. Una instancia de CreateObjectAction tiene una unica entrada.
context uml.primitiveActions.model.concepts.CreateObjectAction inv:
self.inputs->size = 1 File: C:\doctorado\articulospropios\2002\sosym\actions.mdl

primitiveActions.semantics / Main Page 1
11:23:31 mircoles, 06 de noviembre de 2002
Class Diagram:
91
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 ena trada y tiene un valor de salida.
context uml.primitiveActions.instance.concepts.CreateObjectExecution inv:
self.inputs->size = 0 and self.outputs->size = 1
4. La salida de una instancia de CreateObjectExecution es un objeto.

self.outputs->at(1).IsTypeOf(Object)
5. La salida de una instancia de CreateObjectExecution es un objeto de la clase correspondiente a la accin. o

self.outputs->at(1).of = self.of.inputs->at(1)
6. La salida de una instancia de CreateObjectExecution es un objeto nuevo.

context uml.primitiveActions.instance.concepts.CreateObjectExecution
92
inv:
self.outputs->at(1).previous->size() = 0
5.3.
Accin de escritura de un atributo o
Una accin de la clase WriteSlotAction cambia el valor de un atributo o de un objeto. Los valores del resto de atributos permanecen inalterados. Cada accin tiene dos entradas distinguidas: target, que muestra la clase o del objeto a la que pertenece el atributo y attribute, que representa el atributo que se va a modicar. Este debe ser un atributo vlido de esa clase. a La ejecucin de una accin de esta clase tambin tiene dos entradas diso o e tinguidas: target y slot, que representan el objeto y atributos concretos que se modican. El atributo debe ser un atributo vlido de ese objeto. a El nuevo valor del atributo es la otra entrada de la ejecucin. Este valor o debe coincidir con el valor del atributo en el estado del objeto despus de la e ejecucin. o Reglas de correccin o 1. Una instancia de la clase WriteSlotAction tiene tres parmetros de a entrada.
context uml.primitiveActions.model.concepts.WriteSlotAction inv:
2. target es una de las entradas de las instancias de WriteSlotAction.

self.inputs->includes(self.target)
93
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. a

self.target.attributes->includes(self.attribute)
5. El tipo del atributo modicado 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 entraa da y un parmetro de salida. a

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.
94
self.inputs->includes(self.slot) 9. El objeto destino debe ser de la clase con la que est asociada la coa rrespondiente accin. o
self.target.of = self.of.target 10. El atributo del objeto debe coincidir con el atributo de la clase asociada a la correspondiente accin. o
self.slot.of = self.of.attribute 11. El atributo debe ser un atributo vlido del objeto. a
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)
95
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)
6.
Acciones compuestas
A diferencia de las acciones primitivas, las dems acciones que vamos a a
denir son complejas y pueden dividirse en subacciones. Vamos a denir dos tipos de acciones compuestas, las secuenciales y las paralelas. Las guras 2.9, 2.10 y 2.11 muestran, respectivamente, los paquetes de conceptos del modelo, conceptos de instancias y semntica. Estas acciones no hacen directamente a ningn cambio en el sistema, sino que stos se hacen en las subacciones. u e El modelo de concurrencia que se modela es un modelo de intercalado de acciones, donde no se ejecutan varias acciones simultneamente, sino una a detrs de otra. a Reglas de correccin o 1. Una accin compuesta no tiene parmetros de entrada. o a
context uml.compositeActions.model.concepts.compositeAction inv:
96
6. Acciones compuestas
Action
CompositeAction
SequentialAction +seqaction
0..1
ParallelAction
0..1
+paraction
1..n Action 1..n +subaction {ordered} +subaction
Figura 2.9: Paquete de conceptos del modelo de las acciones compuestas (compositeactions.model.concepts). 2. La ejecucin de las subacciones de una ejecucin compuesta se ejecutan o o secuencialmente. Esto implica que una ejecucin no puede usar como o entrada la salida de una ejecucin posterior. o
context uml.compositeActions.instance.concepts.CompositeAction inv:
self.input->excludesAll(self.subsequents(). allSubExecutions().outputs)
Mtodos e 1. El mtodo subExecutions() devuelve las subejecuciones de una ejee cucin compuesta son sus subejecuciones. o
File: C:\doctorado\2002\sosym\ACTIONS.mdl 17:33:08 mircoles 13 de noviembre de 2002 Class Diagram: compositeActions.model.concepts / context uml.compositeActions.instance.concepts.compositeExecution Main Page 1
subExecutions(): Seq(Execution)
97
+subexecution {ordered} 1..n
Execution
+groupAction CompositeExecution 0..1
SequentialExecution
ParallelExecution
Figura 2.10: Paquete de conceptos de instancias de las acciones compuestas (compositeactions.instance.concepts).
SequentialAction
1 +of
n +instances n
SequentialExecution
ParallelAction
1 +of
ParallelExecution
+instances
Figura 2.11: Paquete de la semntica de las acciones compuestas (composia teactions.semantics).
self.subexecution()
2. El mtodo pos devuelve la posicin de una ejecucin en la secuencia e o o de subejecuciones de una accin compuesta. o
context uml.compositeActions.instance.concepts.compositeExecution
pos(): Integer self.posAux(self.groupExecution.subexecution,de 2002 1) File: C:\doctorado\articulospropios\2002\sosym\actions.mdl 13:12:39 mircoles, 13 de noviembre

compositeActions.instance.concepts / Main Page 1 Class Diagram:
98
3. Mtodo auxiliar para denir el mtodo pos. e e

posAux(sa : Seq(Executions), i : Integer): Integer ifi >sa->size() then 0 else ifsa->at(i) = self then i else self.posAux(sa, i + 1) + 1 endif endif
4. El mtodo subsequents() devuelve el conjunto de subejecuciones pose teriores a una subejecucin dada en una ejecucin compuesta, es decir, o o las subejecuciones que se ejecutan tras ella.
subsequents(): Seq(Execution) self.groupExecution.subexecution-> subSequence(self.pos(), self.subexecution->size())
6.1.
Accin Secuencial o
Una instancia de la clase Sequential Action es un envoltorio de una secuencia de subacciones. Estas subacciones tienen que ejecutarse en el orden en el que estn incluidas en la secuencia. Esto implica que una accin no a o puede usar como entrada una salida de una accin posterior. o Las ejecuciones de las subacciones tambin tienen que ejecutarse secuene cialmente, por tanto, una ejecucin, o un clculo de un valor para esa ejecuo a cin, no puede acceder a un valor modicado por una ejecucin previa. o o
99
Reglas de correccin o 1. Las ejecuciones de las subacciones de una ejecucin secuencial ocurren o en el mismo orden en el que estn denidas en la correspondiente aca cin secuencial. o
context uml.compositeActions.instance.concepts.sequentialAction inv:
self.subaction->forall(a | self.subaction->forall(a2 | a.pos() <a2.pos() implies a.of.pos() <a2.of.pos()))
Mtodos e 1. Este mtodo devuelve las subacciones de una accin secuencial son sus e o subacciones.
context uml.compositeActions.model.concepts.sequentialAction
subexecutions(): Seq(Action) self.subaction
2. Este mtodo devuelve la posicin de una accin en una accin secuene o o o cial.
pos(): Integer self.posAux(self.groupAction.subaction, 1)
3. Mtodo auxiliar para denir el mtodopos. e e

posAux(sa : Seq(Actions), i : Integer): Integer
100
ifi >sa->size() then 0 else ifsa->at(i) = self then i else self.posAux(sa, i + 1) + 1 endif endif
4. Este mtodo devuelve el conjunto de las subacciones posteriores a una e accin dada. o
subsequents(): Seq(Action) self.groupAction.subaction-> subSequence(self.pos(), self.subaction->size())
6.2.
Accin Paralela o
En la ejecucin de una accin paralela, las subejecuciones no tienen que o o seguir el orden en el que estn denidas las subacciones en la accin paralela. a o Las acciones pueden ejecutarse concurrentemente y un mismo valor puede ser accedido para calcular valores para diferentes ejecuciones paralelas, pero slo un valor dado puede ser modicado por una sola ejecucin. Este modelo o o corresponde a una ejecucin entrelazada de una accin paralela. o o Mtodos e 1. Las subacciones de una accin paralela son sus subacciones. o
context uml.compositeActions.model.concepts.parallelAction
subactions(): Set(Action)
101
self.subaction
7.
Ejemplo de ejecucin o
Esta seccin muestra la ejecucin, en un ejemplo simple, de varias acciones o o
sobre un objeto. Se dene el mtodo child para la clase Dog. Este mtodo e e crea un nuevo objeto de la clase, inicializa sus atributos y lo asigna como el nuevo hijo del objeto que lo ha creado. Perro::nacimiento() { Perro p;
p = nuevo Perro(); par{ p.edad = 0; p.pelo = corto; }; hijo = p; } Este mtodo consiste en un accin secuencial compuesta de tres subace o ciones: la creacin de un nuevo objeto, la actualizacin de sus slots, y la o o asignacin como nuevo hijo del padre. La actualizacin de los slots se hace o o en paralelo. Los objetos de la clase Perro tienen dos atributos, uno que indica su edad y otro que indica la longitud de su pelo. Cuando se crea el objeto, el valor asociado a sus slots no es un valor vlido, ya que la accin CreateObjectAction a o
102
7. Ejemplo de ejecucin o
no actualiza los valores de los slots del objeto creado. Para darles el valor adecuado hay que ejecutar sendas acciones de la clase WriteSlotActions. En las guras 2.12 y 2.13 se muestran la especicacin en trminos de la o e semntica de acciones propuesta anteriormente. Por claridad no se muestran a el resto de los slots del perro padre.
:Dog +scope +scope +scope +scope +actions +scope :CreateObjectAction
+target :Dog +target +slot +type +input@3 :Integer +slot :Slot
+subaction@1 +groupaction +seqaction :SequentialAction +actions :WriteSlotAction +sequentialaction +actions +subaction@1 +subaction@2 +parallelaction +actions ParallelAction +actions
+slot +subaction@2 +parallelaction :WriteSlotAction +slot :Slot
+subaction :WriteSlotAction +input@3
+target :Dog +input@3 +type +slot +target :Slot +type :Length
+scope
:Dog
Figura 2.12: Vista del modelo de la ejecucin del mtodo o e
103
Lassie: Object +value :CreateObjectExecution :Slot +subaction@1 +slot +slot +output@1 +seqexecution :SequentialExecution +actions +seqaction +seqexecution +scope Fido: Object Identity : 1 +target +parallelexecution +subexecution@2 :ParallelExecution +output Pluto: Object Identity : 2 +target +subexecution@3 +subexecution@2 :WriteSlotExecution :WriteSlotExecution +slot +next +output@3 Fido: Object Identity : 1 +slot :Slot +value +output +value +slot :Slot +value 0: IntegerValue Pluto: Object +value Identity : 2 +slot +slot :Slot +value long: LengthValkue +slot Pluto: Object Identity : 2 +target +slot :Slot +slot +value 7: IntegerValue +slot :Slot +value long: LengthValkue
:WriteSlotExecution +subexecution@1 :Slot +value 0: IntegerValue
+parallelexecution
:Slot
+value
short:LengthValue +value
Figura 2.13: Vista de las instancias de la ejecucin del mtodo o e
8.
File: C:\doctorado\articulospropios\2002\sosym\actions.mdl
La semntica de acciones en el mbito de a a UML 2.0

19:10:04 jueves, 19 de diciembre de 2002 Class Diagram: example / child_instance Page 1
La anterior semntica de acciones de propuso cuando la versin de trabajo a o de UML era la 1.4. Posteriormente, han aparecido las versiones 1.5 y 2.0. En la versin 1.4 no aparece incluida la semntica de acciones en el manual o a de referencia sino que es un documento aparte, ([4]). En la versin 1.5 la o semntica de las acciones ya aparece como un cap a tulo ms del manual de a referencia (cap tulo 2, Semntica, parte 5, acciones), aunque el contenido de a
104
8. La semntica de acciones en el mbito de UML 2.0 a a
este cap tulo era exactamente igual que el del apndice incluido en la versin e o anterior.
8.1.
La propuesta adoptada nalmente para UML2.0
La versin 2.0 de UML, ([118] y [119]), s supone un cambio cualitativo o importante respecto a las versiones 1.x, como se conocen habitualmente. En la peticin de propuestas se establece una larga lista de requisitos que o tienen que cumplir las propuestas para la nueva norma. Uno de los requisitos fundamentales establece la separacin en el metamodelo de UML entre los o elementos bsicos, el ncleo, y los elementos estructurales que dependen de a u este ncleo, por lo que las propuestas se han dividido en infraestructura y u superestructura, respectivamente. En la especicacin adoptada nalmente no se hace referencia a las aco ciones en la infraestructura, sino que son postergadas a la superestructura. En esta versin se reestructuran los conceptos de accin y actividad, que ya o o estaban presentes en la versin 1.5. En la versin 2.0, las actividades son o o grafos de funcionamiento en los que los nodos en los que realmente se lleva a cabo la ejecucin son las acciones. o La denicin de las acciones es muy parecida en lo fundamental a lo que ya o hab Aparecen dos acciones nuevas, AcceptEventAction y SendObjectAction a. y las acciones sobre atributos se generalizan a acciones sobre caracter sticas estructurales (AddStructuralFeatureValueAction, ClearStructuralFeatureAction, ReadStructuralFeatureAction y RemoveStructuralFeatureValueAction). Desaparecen las acciones ActionState, CallState y SubactivityState por la nueva reestructuracin en la que las acciones son parte de las actividades. o No obstante, la semntica de las acciones es similar al anterior con los a mismos problemas que se mencionaron al principio del cap tulo (1), lo que si-
105
gue haciendo vlido dicho anlisis y la justicacin para la semntica descrita a a o a en este cap tulo.
8.2.
La propuesta enviada por 2U Consortium
Como se coment al principio del cap o tulo (2), el grupo 2U Consortium ha enviado su propia propuesta de denicin de UML2.0 ([121], [122]). En o ella, las actividades y las acciones se denen en una jerarqu similar a la de a la propuesta aceptada, deniendo las actividades como un grafo de elementos de funcionamiento en el que las acciones los nodos que realmente ejecutan clculos y modicaciones del estado del sistema. a Hay diferencias fundamentales, no obstante, entre ambas propuestas. En sta, las acciones se denen como parte de la infraestructura y las actividades e como parte de la superestructura. Como en la propuesta para la denicin de o UML 1.5, [4], la actual propuesta se basa en el uso de MML (el Lenguaje de MetaModelado). Este lenguaje contiene elementos de metamodelado ya presentes en MOF ([84]): clases, atributos, operaciones de consulta, asociaciones, paquetes y un lenguaje de restricciones, OCL ([89]). Los otros dos elementos de MML son propios del lenguaje, la extensin de paquetes, que se usa en o lugar de la importacin y las plantillas de paquetes. Con estos dos elementos o se pretende conseguir una especicacin ms compacta y coherente mediante o a la reutilizacin sistemtica de patrones que se encuentran abundantemente o a repetidos en la denicin del lenguaje, como la relacin entre contenedor y o o elementos contenidos o entre un elemento generalizable y los elementos que lo especializan. Como tambin ocurr en la propuesta para UML 1.5, se mantienen las e a separaciones bsicas entre los elementos del lenguaje. La primera entre la a sintaxis abstracta de un paquete y su dominio semntico, con la semntica a a
106
denida como la relacin entre los elementos de ambos paquetes. La segunda o entre los elementos de modelado y su representacin, la sintaxis concreta. o Para el anlisis de la semntica de las acciones en esta nueva propuesta nos a a podemos centrar en los paquetes nales que resultan de la extensin e instano ciacin de los paquetes bsicos y las plantillas de paquetes. Estos paquetes o a nales tienen un aspecto muy similar al de los paquetes de la anterior propuesta.
8.3.
El paquete Behaviour
En el grafo de dependencias entre paquetes de la infraestructura, el paquete de las acciones, Actions, extiende directamente dos paquetes, Behaviour y Expressions. El paquete Behaviour representa la evolucin de los estados o del sistema a lo largo del tiempo. Su sintaxis abstracta es similar a la del paquete Packages: un paquete puede contener clases y subpaquetes. En el dominio semntico aparece el concepto de State, que representa el a estado, en un instante dado, de un elemento del sistema. Como subclases de State se denen Snapshot, Object y Slot, que corresponden con el estado de una instancia de un Paquete, una Class o un Attribute, respectivamente. Otro concepto nuevo es el de identidad. Cada elemento del sistema tiene asociada una identidad y sta permanece ja a lo largo de la evolucin del e o sistema en los diferentes cambios de estado. La identidad tiene una asociacin, en concreto, una secuencia ordenada de estados, llamada lmstrip, que o permite seguir la evolucin de ese elemento en el sistema. o Con estas clases y las operaciones denidas sobre ellas se puede saber, por ejemplo, si un estado de un elemento es posterior a otro o no.
107
8.4.
El paquete Actions
Las acciones son clculos que modican el estado del sistema. Se usan en a el cuerpo de las operaciones. El conjunto de acciones de esta propuesta es mucho ms reducido que el conjunto de la propuesta nalmente aceptada. a Slo se denen, por un lado, dos acciones primitivas, PrimitiveAction: una o que actualiza el valor de un atributo de un objeto, WriteAttributeAction y otra que crea una nuevo objeto de una clase CreateObjectAction. Por el otro lado, se denen dos acciones compuestas CompositeAction: una accin o secuencial, SequentialAction y otra paralela, ParallelAction. La clase Action cuenta con un atributo, isPreemptable, que indica si la evaluacin de la accin en cuestin puede ser interrumpida. Para interrumpir o o o una accin tiene que producirse la evaluacin de un ujo, de la clase Flow, o o que est asociado con las acciones compuestas. El mbito de una accin es a a o el conjunto de variables accesibles desde dicha accin. Como la clase Action o es una especializacin de la clase Expression, las acciones tienen un valor de o vuelta, que depende del tipo de accin que sea. Por ejemplo, la creacin de o o un objeto tiene como resultado de vuelta dicho objeto. Como en la semntica propuesta en la seccin 2, el dominio semntico de a o a las acciones son las evaluaciones de las mismas (Evaluation. Una evaluacin o tiene asociado un estado previo, sobre el que se aplica, y un estado posterior, que es al que se llega tras la ejecucin. o Ventajas e inconvenientes de la nueva semntica de acciones a La semntica de acciones presentada en 2 es, como se puede comprobar, a bastante similar a la que hemos ofrecido en este cap tulo. No obstante, ofrece un serie de ventajas y resuelve algunas de las lagunas de mi propuesta. En primer lugar, aunque se trata de una caracter stica que abarca a toda
108
la denicin de UML, podemos citar el uso de las extensiones y los patroo nes de paquetes, que hace la denicin global ms compacta y coherente. o a Tambin hay que apuntar la mejor denicin de los conceptos que involucra e o el funcionamiento dinmico del sistema. Se han denido nuevas clases, coa mo Behaviour y se ha redenido otras como Activity, consiguiendo una mejor integracin de los diferentes conceptos relacionados en la descripcin dinmio o a ca del sistema. La denicin del concepto de estado, que incluye Snapshot, o Object y Slot y su diferenciacin respecto a la identidad, que permanece o ja, tambin aclara el dominio semntico. Las operaciones denidas sobre la e a clase State permiten denir mejor las reglas de correccin que implican deo pendencias causales (o temporales, como las denen los autores) entre las evaluaciones de las acciones y las expresiones asociadas. En la nueva propuesta de la semntica de acciones se incluyen reglas de a correccin que limitan el orden de evaluacin entre una accin compuesta y o o o sus subacciones, indicando que el estado previo de la evaluacin de la accin o o compuesta debe coincidir con el estado previo de la evaluacin de alguna o subaccin e igualmente para el estado posterior. Asimismo, las evaluaciones o de las subacciones de una accin secuencial son ordenadas usando la relacin o o entre sus estados previos y posteriores. A pesar de todo, considero que an hay aspectos que no han sido satisfacu toriamente resueltos. Para ilustrar estas situaciones tomemos como ejemplo una accin compuesta, secuencial, por ejemplo, en la que todas sus subaccioo nes son acciones de escritura de atributos. Las evaluaciones de las acciones compuestas y la accin de crear un nuevo objeto tienen como estados previos o y posteriores una instancia de la clase Snapshot. La evaluacin de una accin o o de escritura del valor de un atributo tiene como estados previo y posterior una instancia de la clase Slot. Al ser los estados previos y posteriores distintas
109
subclases de la clase State no es posible comparar si son el mismo1 , o si van antes o despus. e
:SlotIdentity +identity +identity estado_1:Snapshot +pre 5:PrimitiveValue +value slot_1:Slot +pre :SnapshotIdentity
+identity +identity +post estado_2:Snapshot
cae:CompositeActionEvaluation
+subActionEval waae:WriteAttributeActionEvaluation +propertyCall :PropertyCallExpEval +source
+post slot_2:Slot ++ownedStructuralFeatureInstance
+ownedStructuralFeatureInstance +ownedSnapshotElementInstance o1:Object +writeValue :ConstantExpEval
o2:Object +ownedSnapshotElementInstance
+value
+value 10:PrimitiveValue
+value
:BoundVariableEval +referredVariable VariableValue
Figura 2.14: Evaluacin en la que no coinciden ni el estado previo ni el o posterior de una accin compuesta y una de sus subacciones o Otro cuestin muy relacionada que no queda clara es la relacin de ino o clusin entre las diferentes clases de estados. Un Snapshot puede contener o Snapshots u Objetos y stos, a su vez, pueden contener Slots. Adems, cada e a estado puede estar contenido directamente, a lo sumo, en un solo estado dentro de esta jerarqu Por tanto, si tenemos varias WriteAttributeActionEvaa. luation consecutivas, segn los diagramas de clases y las reglas de correccin u o no tenemos ni un nuevo Snapshot ni un nuevo Object como estado posterior para cada uno de los Slot intermedios que se van generando Otra inconsistencia que se puede presentar afecta a la causalidad entre la
En la propuesta hay varios errores. Uno de ellos es que se hace uso de la operacin o isSameTime sobre dos estados, que no ha sido denida previamente. En cambio, s se ha denido la operacin isSame, que simplemente comprueba si son el mismo objeto. El otro o es que la gura que muestra el ejemplo de una evaluacin de una WriteAttributeActionEo valuation el estado previo se dene de la clase Object, no de la clase Slot, como se dene en el diagrama de clases del dominio semntico. a
1
110
evaluacin de las expresiones asociadas a la evaluacin de una accin. Cuando o o o se evala una accin, los valores necesarios se calculan mediante la evaluacin u o o de expresiones. En esta semntica no se hace ninguna referencia a cmo deben a o estar relacionadas ambas evaluaciones. La restriccin fundamental es que un o valor usado en la evaluacin de una expresin no puede tomarse de un estado o o posterior a la evaluacin de la accin. o o Una posible solucin a estas discordancias es establecer que todas las o acciones tienen como estados previo y posterior un Snapshot y aadir las n reglas de correccin necesarias. En el caso de la escritura del valor de un o atributo, la clase y el atributo sobre los que se aplica la accin se accede o a travs de la expresin PropertyCallExpression a travs, respectivamente, e o e de sus asociaciones source y propertyCall. Habr que aadir una regla de a n correccin que indique que el estado posterior tiene que haber un objeto con o un slot cuyo valor coincida con el calculado en la expresin writeValue. o
111
UML::Core.Constructs.Actions.AbstractSyntax
VariableDeclaration 1..* scope
type
1..*
Classifier {Abstract} type * Expression {Abstract}
writeValue
propertyCall boundVariable PropertyCallExpression Action BoundVar * boolean isPreempted subAction endEval Flow * ownedFlow SequentialAction ParallelAction WriteAttributeAction * * startEval CompositeAction PrimitiveAction Class Object
CreateObjectAction
Figura 2.15: Sintaxis abstracta del paquete Actions donde los estados previos y posteriores de todas las acciones son de la clase Snapshot
112
UML::Core.Constructs.Actions.SemanticDomain VariableValue 1..* env * value Instance value 1..* * ExpressionEvaluation {Abstract} writeValue propertyCall boundVariable * subActionEval endEval startEval FlowEvaluation * ownedFlowEval ParallelActionEvaluation post pre Snapshot pre post post pre post CreateObjectActionEvaluation CompositeActionEvaluation PrimitiveActionEvaluation ActionEvaluation boolean isPreempted
SequentialActionEvaluation pre SnapshotIdentity identity *
WriteAttributeActionEvaluation
Figura 2.16: Dominio semntico del paquete Actions donde los estados prea vios y posteriores de todas las acciones son de la clase Snapshot
113
+identity :SlotIdentity 1 +identity 1 1 :SnapshotIdentity 1 1 +identity +identity +post cae:CompositeActionEvaluation 1 1 1 waae:WriteAttributeActionEvaluation 1 1 +propertyCall 1 :PropertyCallExpEval 1 +source 1 :BoundVariableEval 1 1 +referredVariable 1 VariableValue 1 1 +identity :SlotIdentity +identity +subActionEval estado_2:Snapshot 1 1 +post1 1 1 1 1 slot_2:Slot 1 ++ownedStructuralFeatureInstance 1 1 o2:Object +ownedSnapshotElementInstance 1
1 estado_1:Snapshot 1 1 5:PrimitiveValue +value 1 1 1 slot_1:Slot 1 +ownedStructuralFeatureInstance 1 +ownedSnapshotElementInstance 1 1 o1:Object 1 +value 1
+pre
+pre
+writeValue 1 :ConstantExpEval 1 +value +value 1 1 10:PrimitiveValue
Figura 2.17: Evaluacin en la que los estados previos y posterior de una o WriteAttributeActionEvaluation son de la clase Snapshot.
Reglas de correccin o Snapshot 1. Las instancias de la clase Object contenidas en una instancia de la clase Snapshot son estados de objetos diferentes
context Snaphot inv:
self.ownedSnapshotElementInstance->forall(oei, oei2 | oei <>oei2 implies <>oei.identity = oei2.identity Object 1. Las instancias de la clase Slot contenidas en una instancia de la clase Object son estados de slots diferentes
context Object inv:
self.ownedStructuralFeatureInstance->forall(osfi, osf2 | osfi <>osfi2 implies osfi.identity <>osfi2.identity
114
WriteAttributeActionEvaluation 1. En el estado posterior debe haber un objeto tal que uno de sus slots tiene el valor calculado en la evaluacin de la accin. o o
context WriteAttributeActionEvaluation inv:
post.ownedSnapshot.ElementInstance->exists(o | o.identity = self.propertyCall.source.referredVariable.value.identity and o.ownedStructuralFeatureInstance->exists(s | self.propertyCall.source.referredVariable.value. ownedStructuralFeatureInstance->exists(s2 | s2.identity = s.identity) and s.value = s.writeValue.value Respecto a la evaluacin de las expresiones se puede incluir una nueva o regla de correccin que establezca que el estado del que la evaluacin de la o o expresin obtiene sus valores coincide con el estado previo de la evaluacin o o de la accin a la que est asociada. o a Reglas de correccin o CompositeActionEvaluation 1. Para las evaluaciones de las subacciones directas de una accin como puesta, todos los valores de las expresiones asociadas pertenecen al estado previo de la accin. o
context CompositeActionEvaluation inv:
self.subActionEval.forall(sae | sae.ExpressionEvaluations()-> forall(ee | ee.allSubExpressionEvaluations()-> forall(see | see.ReferredInstances()-> forall(ri | ri.owningSnapshot = sae.pre))) Mtodos e AndExpEval
115
1. Esta operacin devuelve las evaluaciones de todas las subexpresiones o de la evaluacin de una expresin And anidadas a cualquier nivel. o o
context AndExpEval::
allSubExpressionEvaluations():Set(ExpressionEvaluation) self.left->union(self.right)-> union(self.left.allSubExpressionEvaluations())-> union(self.right.allSubExpressionEvaluations()) 2. Esta operacin devuelve todos los valores accedidos por la evaluacin o o de una expresin And. o
context AndExpEval::
ReferredInstances():Set(Instances) self.left.ReferredInstances()-> union(self.right.ReferredInstances())
BoundVariableEval 1. Esta operacin devuelve las evaluaciones de todas las subexpresiones o de la evaluacin de una expresin BoundVariable anidadas a cualquier o o nivel.
context BoundVariableEval::
allSubExpressionEvaluations():Set(ExpressionEvaluation) Set{}
2. Esta operacin devuelve todos los valores accedidos por la evaluacin o o de una expresin BoundVariableEval. o
context BoundVariableEval::
116
ReferredInstances():Set(Instances) self.referredVariable.value EqualsExpEval 1. Esta operacin devuelve las evaluaciones de todas las subexpresiones o de la evaluacin de una expresin Equals anidadas a cualquier nivel. o o
context EqualsExpEval::
allSubExpressionEvaluations():Set(ExpressionEvaluation) self.left->union(self.right)-> union(self.left.allSubExpressionEvaluations())-> union(self.right.allSubExpressionEvaluations()) 2. Esta operacin devuelve todos los valores accedidos por la evaluacin o o de una expresin Equals. o
context EqualsExpEval::
ReferredInstances():Set(Instances) self.left.ReferredInstances()-> union(self.right.ReferredInstances()) GreaterThanExpEval 1. Esta operacin devuelve las evaluaciones de todas las subexpresiones o de la evaluacin de una expresin GreaterThan anidadas a cualquier o o nivel.
context GreaterThanExpEval::
allSubExpressionEvaluations():Set(ExpressionEvaluation) self.left->union(self.right)-> union(self.left.allSubExpressionEvaluations())-> union(self.right.allSubExpressionEvaluations())
117
2. Esta operacin devuelve todos los valores accedidos por la evaluacin o o de una expresin GreaterThan. o
context GreaterThanExpEval::
ReferredInstances():Set(Instances) self.left.ReferredInstances()-> union(self.right.ReferredInstances()) IfExpEval 1. Esta operacin devuelve las evaluaciones de todas las subexpresiones o de la evaluacin de una expresin If anidadas a cualquier nivel. o o
context IfExpEval::
allSubExpressionEvaluations():Set(ExpressionEvaluation) self.condition->union(self.thenExpression)-> self.condition->union(self.elseExpression)-> union(self.condition.allSubExpressionEvaluations())-> union(self.thenExpression.allSubExpressionEvaluations())-> union(self.elseExpression.allSubExpressionEvaluations()) 2. Esta operacin devuelve todos los valores accedidos por la evaluacin o o de una expresin If. o
context IfExpEval::
ReferredInstances():Set(Instances) self.condition.ReferredInstances()-> self.thenExpression.ReferredInstances()-> self.elseExpression.ReferredInstances()-> IncludesExpEval 1. Esta operacin devuelve las evaluaciones de todas las subexpresiones o de la evaluacin de una expresin Includes anidadas a cualquier nivel. o o
118
context IncludesExpEval::
allSubExpressionEvaluations():Set(ExpressionEvaluation) self.source->union(self.condition)-> union(self.source.allSubExpressionEvaluations())-> union(self.condition.allSubExpressionEvaluations()) 2. Esta operacin devuelve todos los valores accedidos por la evaluacin o o de una expresin Includes. o
context IncludesExpEval::
ReferredInstances():Set(Instances) self.condition.ReferredInstances()-> union(self.source.ReferredInstances()) IterateExpEval 1. Esta operacin devuelve las evaluaciones de todas las subexpresiones o de la evaluacin de una expresin Iterate anidadas a cualquier nivel. o o
context IterateExpEval::
allSubExpressionEvaluations():Set(ExpressionEvaluation) self.source->union(self.body)-> union(self.source.allSubExpressionEvaluations())-> union(self.body.allSubExpressionEvaluations()) 2. Esta operacin devuelve todos los valores accedidos por la evaluacin o o de una expresin Iterate. o
context IterateExpEval::
ReferredInstances():Set(Instances) self.source.ReferredInstances()-> union(self.body.ReferredInstances())
119
NotExpEval 1. Esta operacin devuelve las evaluaciones de todas las subexpresiones o de la evaluacin de una expresin Not anidadas a cualquier nivel. o o
context NotExpEval::
allSubExpressionEvaluations():Set(ExpressionEvaluation) self.operand-> union(self.operand.allSubExpressionEvaluations()) 2. Esta operacin devuelve todos los valores accedidos por la evaluacin o o de una expresin Not. o
ReferredInstances():Set(Instances) self.operand.ReferredInstances()
PropertyCallExpEval 1. Esta operacin devuelve las evaluaciones de todas las subexpresiones o de la evaluacin de una expresin PropertyCall anidadas a cualquier o o nivel.
context PropertyCallEval::
allSubExpressionEvaluations():Set(ExpressionEvaluation) self.source->union(self.referredProperty)-> union(self.source.allSubExpressionEvaluations())-> union(self.referredProperty.allSubExpressionEvaluations()) 2. Esta operacin devuelve todos los valores accedidos por la evaluacin o o de una expresin PropertyCall. o
120
ReferredInstances():Set(Instances) self.referredProperty.value
CompositeActionEvaluation 1. Esta operacin devuelve las evaluaciones de expresiones asociadas a la o evaluacin de una CompositeActionEvaluation. o
context CompositeActionEvaluation::
ExpressionEvaluations():Set(ExpresionEvaluation) Set{}
CreateObjectActionEvaluation 1. Esta operacin devuelve las evaluaciones de expresiones asociadas a la o evaluacin de una CreateObjectActionEvaluation. o
context CreateObjectActionEvaluation::
ExpressionEvaluations(): Set(ExpresionEvaluation) self.boundVariable
WriteAttributeActionEvaluation 1. Esta operacin devuelve las evaluaciones de expresiones asociadas a la o evaluacin de una WriteAttributeActionEvaluation. o
context WriteAttributeActionEvaluation::
ExpressionEvaluations():Set(ExpresionEvaluation) self.propertyCall->union(self.callValue)
121
Esta regla de correccin implica que todas las acciones se evalan de mao u nera atmica, incluyendo la evaluacin de sus expresiones. Esto no es una o o idea demasiado realista porque el esp ritu de UML es precisamente la ejecucin concurrente de objetos e, incluso en la misma propuesta, las acciones o tienen un atributo que indican si son interrumpibles y las evaluaciones tienen otro que indican si han sido interrumpidas. Tampoco se estar teniendo en a cuenta la posibilidad de la intercalacin de la evaluacin de las expresiones o o de distintas acciones. Podemos permitir la ejecucin intercalada de acciones cambiando las reo glas de correccin. La regla anterior se puede restringir a la evaluacin de o o las acciones secuenciales (SequentialActionEvaluation), mientras que en las evaluaciones de las subacciones de una accin paralela (ParallelActionEvao luation), la evaluacin intercalada signica que el estado del que toman los o valores las expresiones asociadas a la evaluacin de la accin no tiene por o o qu ser necesariamente el estado previo de la accin, sino uno anterior. Ms e o a concretamente, puede ser cualquier estado entre el estado previo de la accin o paralela que contiene a la accin y el estado previo de la accin. o o Reglas de correccin o ParallelActionEvaluation
1. Para las evaluaciones de las subacciones directas de una accin paraleo la, todos los valores de las expresiones asociadas pertenecen a un estado que est entre el estado previo de la evaluacin de la accin paralela y a o o el estado previo de la evaluacin de la subaccin a la que est asociada o o a la evaluacin de la expresin. o o
context ParallelActionEvaluation inv:
122
self.subActionEval.forall(sae | sae.ExpressionEvaluations()-> forall(ee | ee.allSubExpressionEvaluations()->forall(see | forall(see | see.ReferredInstances()->forall(ri | (self.OuterParActionEval().pre.isEarlier(ri.owningSnapshot) or self.OuterParActionEval().pre.isSame(ri.owningSnapshot)) and (ri.owningSnapshot.isEarlier(sae.pre) or ri.owningSnapshot.isSame(sae.pre))))) 2. Para las evaluaciones de las subacciones directas de una accin secueno cial, todos los valores de las expresiones asociadas pertenecen al estado previo de la accin. o
context CompositeActionEvaluation inv:
self.subActionEval.forall(sae | sae.ExpressionEvaluations()-> forall(ee | ee.allSubExpressionEvaluations()-> forall(see | see.ReferredInstances()-> forall(ri | ri.owningSnapshot = sae.pre))) Mtodos e ActionEvaluation 1. Este mtodo devuelve la accin paralela ms exterior que contiene a e o a una accin dada. Si la accin est incluida en una accin secuencial, el o o a o valor devuelto es la propia accin o
context ActionEvaluation:
OuterParActionEval():ActionEvaluation if self.CompositeActionEvaluation->size() = 0 or self.CompositeActionEvaluation.of = SequentialAction then self else self.CompositeActionEvaluation.OuterParEvaluation() endif
123
Esta nueva de regla de correccin aumenta las posibilidades de ejecucin o o permitiendo la intercalacin en la evaluacin de las acciones. No obstante, o o sigue sin contemplar la ejecucin concurrente de dos acciones. Cada Snapshot o slo puede ser el estado previo de una evaluacin, lo que impide que varias o o acciones se evalen simultneamente sobre el mismo estado y desemboquen u a en un mismo estado posterior. En este caso, puede ocurrir que dos acciones modiquen concurrentemente el mismo valor y, por tanto, en el estado posterior el valor nal del elemento modicado no coincidir con el del valor a evaluado en la expresin asociada. o Por tanto, para permitir la ejecucin concurrente de varias acciones, o habr que cambiar la cardinalidad de la asociacin entre la clase State y a o las evaluaciones de las diferentes acciones para que cada estado pudiera ser el estado previo o el estado posterior de una accin o ms y cada accin o a o pudiera tener un solo estado previo y un solo estado posterior.
124
CAP ITULO
Modelado de tiempo real de las mquinas de a estados de UML
1.
Introduccin o
Entre las principales contribuciones de UML (Unied Modeling Lengua-
ge) [88] est la unicacin de varias notaciones previas que compart los a o an conceptos fundamentales, aunque difer ligeramente en el modo en que an las trataban. Tambin hay que hacer notar que UML ofrece un conjunto de e diagramas sucientemente amplio para permitir al desarrollador cubrir las diferentes partes o vistas de un sistema dado. Las mquinas de estados se encuentran entre los denominados elementos a de modelado dinmicos, que son los apropiados para describir el funcionaa miento dinmico de los sistemas. Estos diagramas especican el funcionaa miento de los diversos elementos mediante un conjunto de estados estables donde los elementos estn esperando la ocurrencia de un evento externo que a hace que el sistema reaccione y, posiblemente, cambie su estado interno. Consecuentemente, estos diagramas son muy apropiados para describir sistemas reactivos [57]. 125
126
1. Introduccin o
El documento de especicacin de UML 1.5 [88] dene en la seccin 2.12 la o o semntica de las mquinas de estados como una variante basada en objetos de a a los statecharts de Harel [57]. Su denicin se hace de una manera semiformal. o La sintaxis abstracta se dene mediante diagramas de clases y la semntica a esttica se dene usando reglas de correccin en OCL, que establecen ciertas a o propiedades que deben cumplir las instancias vlidas de los diagramas de a clases. Sin embargo, la semntica dinmica se describe en lenguaje natural, a a lo que impide la existencia de un modelo formal subyacente que permita a las herramientas de diseo hacer pruebas automticas del cumplimiento de n a las propiedades del modelo. Las mquinas de estados de UML tienen un gran nmero de diferentes a u elementos, lo que resulta en una semntica dinmica muy compleja. Por el a a contrario, algunos de estos elementos, como los estados stub y los estados submquina, no aaden nueva semntica de por s sino que son construccioa n a , nes sintcticas que pretenden facilitar el uso de las mquinas de estados. a a Una semntica precisa para las mquinas de estados permitir validar y a a a vericar sistemas descritos en UML como hacen otras herramientas, como Telelogic Tau con sistemas basados en SDL [61]. Si hay una semntica precisa y a correcta para las mquinas de estados, una herramienta podr representar el a a estado actual del sistema, por ejemplo como un diagrama de objetos, y podr a comprobar si es una instancia vlida del diagrama de clases que representa el a sistema. La validacin consistir en generar el rbol de posibles evoluciones o a a del sistema y analizar si los estados cumplen las restricciones establecidas. Estas restricciones se aplicar a los estados mismos y a las transiciones de an un estado a otro, como se comenta en el cap tulo de la semntica de acciones a (cap tulo 2). Estas restricciones podr expresarse en OCL. an Para la vericacin, las herramientas deber ser tambin capaces de o an e
Cap tulo 3. Modelado de tiempo real . . .
127
representar una traza de la ejecucin denida por un diagrama de colaborao cin o de secuencia. Esto implica otro trabajo a hacer, ya que estos diagramas o necesitan su propia semntica. a
1.1.
Trabajos relacionados
Son numerosos los trabajos que presentan semnticas formales alternatia vas para las mquinas de estados, demostrando de esa manera que es muy a generalizada la opinin de que una semntica formal y precisa conlleva grano a des benecios, como ya hemos comentado. En [35], Crane y Dingel hacen un estudio muy actual y sistemtico de diferentes propuestas de semnticas. a a Son tambin muy variados los formalismos usados para construir dichas e semnticas. Por un lado existen modelos que usan estructuras ms similares a a a las mquinas de estados, como sistemas de transiciones etiquetadas, estruca turas de Kripke, mquinas de estados abstractas, redes de Petri o grafos. La a ventaja de estas propuestas es que la similitud entre los formalismos usados y las mquinas de estados de UML hace que la traduccin de los conceptos a o entre ambos modelos sea ms fcil. a a Otro grupo de soluciones son las que se basan en lenguajes fuertemente matemticos, como teor de conjuntos y relaciones o lgicas temporales. a a o Aunque estas soluciones facilitan soluciones completas y con propiedades demostrables, son ms dif a ciles de entender por los usuarios de las mquinas de a estados. Otras propuestas se basan en la transformacin de las mquinas de o a estados en objetos de otros lenguajes apropiados para su anlisis automtia a cos, como la comprobacin de modelos. o Un tercer grupo de soluciones son aquellas que traducen las mquinas a de estados de UML a otros lenguajes, ya sean lenguajes de especicacin, o como Z o PVS [92], lenguajes de entrada a herramientas de comprobacin de o
128
1. Introduccin o
modelos, como PROMELA/SPIN, o lenguajes de programacin imperativa, o como Java. En [25] Brger y otros usan mquinas de estados abstractas para repreo a sentar la mquinas de estados de UML. Su trabajo incluye un estudio en a profundidad de los aspectos ms complicados del modelo, como el manejo de a los eventos o las actividades internas de los estados, ausentes en muchos otros modelos.Tambin hacen expl e citos algunos de puntos de variacin semntica o a de la norma UML. En [20] Baresi y Pezz` ilustran a travs de un ejemplo la traduccin e e o automtica de un modelo UML, en el que las mquinas de estados son un a a parte, a redes de Petri de alto nivel. La sintaxis y la semntica de UML a se hace sobre gramticas de grafos. Una vez traducidas las mquinas de a a estados a redes de Petri se pueden usar varias herramientas automticas ya a disponibles para realizar anlisis de exclusin mutua, ausencia de bloqueos, a o comprobacin de modelos, etc, que se pueden traducir a su vez a notacin o o UML para que el usuario las examine. En [53] Gogolla y Presicce estudian un mecanismo muy intuitivo de transformacin de mquinas de estados de UML a grafos aplanados mediante el o a uso de reglas de transformacin de grafos. En [72], Kuske contina el trabajo o u aplicando las tcnicas de transformacin de grafos para denir una semntica e o a formad de las mquinas de estados, en la que las distintas conguraciones a del sistema se representan como grafos y la ejecucin de una transicin coo o rresponde a la aplicacin de reglas de transformacin de grafos. o o En [18] Aredo proporciona un esquema general para traducir las mquia nas de estados de UML a PVS-SL, el lenguaje de especicacin del marco o PVS. La traduccin tiene en cuenta la sintaxis abstracta de las mquinas o a de estado y las reglas de correccin. Este mtodo cuenta con la ventaja de o e
129
disponer de las herramientas automticas de anlisis para PVS, que incluyen a a comprobacin de tipos y modelos y demostracin de teoremas. o o En [51] Gnesi y otros utilizan autmatas jerrquicos extendidos y estruco a turas de Kripke para darle un soporte formal a la semntica de las mquinas a a de estados y hacen uso de la herramienta JACK para hacer comprobacin de o modelos sobre ACTL, una lgica temporal de tiempo ramicado. o En [70] Knapp y Merz presentan HUGO, una herramienta que permite animar, comprobar modelos y generar cdigo Java a partir de mquinas de o a estados de UML. La comprobacin de modelos de las mquinas de estados o a se hace frente a diagramas de interaccin en vez de frmulas lgicas para o o o facilitar su uso. HUGO hace uso de PROMELA y SPIN. En [74] se estudia UML en su conjunto, representando los modelos de UML como teor de una teor de conjuntos extendida de primer orden. as a Las teor se expresan en Real-time Action Logic y las mquinas de estados as a se formalizan como extensiones de las teor para clases. as En [100] Rossi y otros usan LNint-e, una lgica temporal basada en puno tos, intervalos y fechas para formalizar los aspectos fundamentales de la semntica de las mquinas de estados de UML, haciendo especial nfasis a a e en los aspectos dinmicos. Algunas caracter a sticas como los eventos y las guardas no han sido modelados porque necesitan una lgica de primer orden. o Todas las propuestas anteriores se basan en formalismos matemticos de a los que la OMG, creadora de UML, preere no hacer uso por su dicultad de comprensin. Una limitacin fundamental en la utilidad de estas propuestas o o es la extensin de las mismas para la denicin de la semntica de los dems o o a a diagramas de UML, de manera que se pudiera usar toda la gama de diagramas de UML en el desarrollo de un mismo sistema. Si el formalismo no es adecuado para representar todos los diagramas, que son de muy distinta na-
130
1. Introduccin o
turaleza, al menos deber ofrecer mecanismos de traduccin a la semntica an o a de los otros diagramas para comprobar la coherencia las diferentes vistas de los modelos. Algunas propuesta, como [18] y [70] ofrecen herramientas para anlisis automtico de propiedades de las mquinas de estados que modelan, a a a lo que demuestra su utilidad prctica. a
En [46] Engels y otros usan el metamodelado para denir la semntica a formal. Parten del metamodelo esttico, basado en diagramas de clases) y lo a extienden al modelo dinmico con diagramas de colaboracin, que se usan a o para expresar la semntica dinmica de las mquinas de estados. Sin embara a a go, el conjunto de caracter sticas de las mquinas de estados cubierto es muy a reducido.
En [69], Kleppe y Warmer tambin usan el metamodelado para denir e la semntica formal de UML. Este trabajo es, con toda probabilidad, el ms a a similar al nuestro, pues tambin se basa en el trabajo desarrollado por el e grupo pUML [27]. El modelo de mquinas de estados que se representa es a muy simple, y slo incluye estados simples, transiciones y acciones. No dene o la semntica de la relacin entre los diferentes estados por los que pasa una a o mquina de estados a lo largo de su vida. a
Finalmente, queremos destacar el hecho de que ninguna de esas propuestas estudia el tema del tiempo en las mquinas de estados, ni su aplicacin a o a sistemas de tiempo real. Las que hacen mencin a prioridades se reeren a o las prioridades de las transiciones anidadas cuyo evento disparador coincide, pero no es ese el signicado de prioridad necesario en los sistemas de tiempo real.
131
2.
Semntica de las mquinas de estados a a

Como se discuti en el cap o tulo 2, la denicin ocial de UML no difeo
rencia claramente entre la sintaxis abstracta, o conceptos de modelado, y el dominio semntico, o conceptos de instancia. Por ejemplo, en la denicin de a o la semntica se dice: a El trmino evento se usa para referirse al tipo y no a la e instancia del tipo. Sin embargo, en alguna ocasin, donde el sigo nicado se pueda deducir claramente del contexto, el trmino e tambin se usar para referirse a una instancia del evento. e a Esta falta de distincin tambin afecta al resto de los conceptos denidos o e en el paquete de las mquinas de estados y hace que conceptos ms relaa a cionados con la vista esttica estn mezclados con otros ms cercanos a la a e a vista dinmica. Por ejemplo, aunque se habla ampliamente sobre el concepto a de transicin de un estado a otro, no hay ningn concepto que represente o u el procesamiento de una instancia de un evento, ni hay reglas de correccin o OCL relativas a las transiciones. En este cap tulo proponemos una semntica para una versin simplicada a o de las mquinas de estados de UML. Esto signica que hay caracter a sticas, como las actividades, los estados de historia o la lista de eventos postergados, que no son contemplados. Para ilustrar la losof de la aproximacin, a o se van a ofrecer diferentes modelos, cada vez con ms elementos. Pensamos a que el modelo nalmente considerado es sucientemente completo y lo bastante representativo de la validez del enfoque usado. El modelo de la seccin o 2.1 incluye estados simples y transiciones entre estados. El de la seccin 2.2 o introduce los estados compuestos, que se pueden describir en varios niveles de detalle. En la seccin 2.3 se ampl el concepto de estado compuesto o a
132
2. Semntica de las mquinas de estados a a
aadiendo los estados concurrentes, donde hay varios subestados activos sin multneamente. Finalmente, en la seccin 2.4 se aaden al modelo los eventos a o n que disparan las transiciones y las acciones que se ejecutan en el paso de un estado a otro. En cada seccin el desarrollo del modelo es similar. Se denen los tres o subpaquetes habituales en la denicin de un paquete en MML. Cada uno o de los subpaquetes incluye un diagrama de clases y las reglas de correccin o necesarias para detallar los aspectos semnticos que no se pueden denir a en el diagrama de clases. Asimismo se incluye un ejemplo para ilustrar los conceptos presentados. El ejemplo consta de una mquina de estados cona creta especicada en UML con los elementos incluidos en cada seccin y los o diagramas de objetos correspondientes a la sintaxis abstracta y el dominio semntico del ejemplo. a Muchos de los conceptos presentados a continuacin coinciden con otros o denidos en la semntica ocial de las mquinas de estados de UML. En a a la presente propuesta, el subpaquete de conceptos de modelado contiene los elementos relativos a la descripcin esttica de la mquina de estados, como o a a los posibles estados de la mquina o cules son las transiciones de salida de a a cada estado. Por otro lado, el subpaquete de conceptos de instancias dene los elementos relativos al aspecto dinmico. Entre otros, este paquete incluye a el procesamiento de una instancia de un evento y las ejecuciones involucradas en la transicin de un estado a otro. o
2.1.
La mquina de estados plana a
El modelo ms simple de una mquina de estados consta, por un lado, a a de un conjunto de situaciones estables, denominadas estados, en uno de los cuales la mquina siempre permanece. En este modelo, los estados son indivia
133
sibles y no se pueden desarrollar internamente. Debido a esta caracter stica, denominaremos a estas mquinas como mquinas de estados planas. a a Por otro lado, la mquina de estados comprende un conjunto de transicioa nes, que son enlaces entre los estados descritos previamente. Cada transicin o tiene un estado origen y un estado destino. La mquina puede cambiar de a 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 o estado nal al segundo. Esta denicin permite establecer varios paralelismos entre las instancias o de las mquinas de estados y los objetos. Este paralelismo se reeja princia palmente en el funcionamiento dinmico del sistema. a Una instancia de una mquina de estados es una entidad que, al igual que a un objeto, pasa por diferentes estados segn se van ejecutando acciones sobre u el sistema. En el caso de las mquinas de estados, cada uno de estos estados a por los que va pasando se denomina el estado activo. Tambin tiene sentido e establecer, como se hace en la denicin de la infraestructura de UML 2.0 o [121] para los objetos, una identidad para cada instancia de una mquina de a estados. Esta identidad permanece ja durante la vida del sistema y acta u 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, como se propone en [121]. Este paralelismo, no obstante, no es completo. Un objeto tiene caracter sticas 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 o sus slots. Por su lado, cada estado activo de una instancia de una mquina a de estados no tiene por qu estar asociado con una instancia de los estados e
134
asociados a la mquina de estados, sino slo con un subconjunto de ellos. En a o el caso de la mquina de estados plana slo uno de los estados estar activo a o a para cada estado de la instancia de la mquina de estados. Los estados de la a mquina de estados no tienen asociado ningn valor, como es el caso de los a u slots de los objetos, al menos en este primer modelo simple. Conceptos de modelado En la gura 3.1 se muestra el diagrama de clases de los conceptos de modelado de las mquinas de estados. En l vemos cmo una mquina de a e o a estados tiene asociados un conjunto de estados y un conjunto de transiciones.
StateMachine::AbstractSyntax
PackagedElement
+owningStateMachine 0..1 StateMachine
+owningStateMachine 0..1
+ownedStateMachineStates 0..* +source StateMachineState +inicial : Bool +target FinalState +outgoing 0..*
0..*
Transition 0..* +incoming
Figura 3.1: Conceptos de modelado de las mquinas de estados planas. a En esta primera aproximacin todos los estados son simples, por lo que o no se establece un relacin de contencin entre ellos. o o
135
Las transiciones, que denen los posibles cambios de estado en la mquina a de estados, parten de un estado origen, source, y llegan a un estado destino, target. En las mquinas hay dos estados distinguidos, el initial, que es el que se a activa cuando empieza la vida de la mquina, y el nal, que es un estado tal a que cuando se transita a l, se acaba la actividad de la mquina. El estado e a nal no puede, por tanto, tener ninguna transicin de salida. En la denio cin de las mquinas de estados de UML, el estado inicial tiene una unica o a transicin de salida, que se ejecuta cuando empieza la vida de la mquina de o a estados. Para no tener que denir una clase especial de estados, como se hace en la denicin de las mquinas de estados de UML con los pseudoestados, o a que incluyen estados iniciales, de historia, fork y join, entre otros, nosotros vamos a aadir un atributo de tipo Bool a los estados que indique si es el n estado inicial. Vamos a incluir una restriccin que indique que slo puede o o haber un estado inicial. Los estados nales los denimos como una especializacin de los estados simples. En el caso de los estados nales no es necesario o establecer ninguna restriccin sobre su nmero ya que, al no poderse efeco u tuar transiciones en ellos, no hay diferencia entre tener uno o varios estados nales. Reglas de correccin o 1. Slo hay un estado inicial. o
context StateMachine inv:
ownedStateMachineStates->select(osms | osms.initial = true)->size() = 1 2. Los estados nales no pueden ser iniciales.
136
context FinalState inv:
initial = false
3. Los estados nales no tienen transiciones de salida.

outgoing()->size() = 0
Dominio semntico a En la gura 3.2 se muestra el diagrama de clases correspondiente al dominio semntico de las mquinas de estados. En l se dene una insa a e tancia de una mquina de estados como una especializacin de la clase a o SnapshotElementInstance, como se describe en el cap tulo de Behaviour de [121]. All a su vez, SnapshotElementInstance se dene como una especia, lizacin de la clase State. La identidad de una instancia de una mquina o a de estados, representada por StateMachineInstanceIdentity, est asociaa da con los sucesivos estados por los que pasa la instancia. Cada valor de la instancia de la mquina de estados estar asociada con un estado activo, a a una instancia de la clase StateMachineStateInstance. Los estados activos, como los slots de un objeto, tienen una identidad constante que no cambia durante la ejecucin del sistema. o Aplicacin semntica o a La semntica de este primer modelo es muy simple, ya que en el dominio a semntico slo hay dos clases que se asocien con otras de la sintaxis abstracta a o (gura 3.3).
137
StateMachine::SemanticDomain
SnapshotElementInstance
State
+filmstrip StateMachineInstance 0..1 +owningStateMachineInstance +identity activeState StateMachineStateIdentity StateMachineStateInstance 0..*
FinalStateInstance
Figura 3.2: Dominio semntico de las mquinas de estados planas. a a

StateMachine::SemanticMapping 0..* StateMachine +of +instance 0..* StateMachineState +of StateMachineStateInstance +instance 0..* FinalState +of +instance FinalStateInstance StateMachineInstance
Figura 3.3: Aplicacin semntica de las mquinas de estados planas. o a a Ejemplo En la gura 3.4 se muestra una mquina con un estado inicial, uno nal, a tres estados normales y tres transiciones entre dicho estados. En la gura 3.5
138
se muestra el diagrama de objetos correspondiente a la sintaxis abstracta de dicha mquina. En la gura 3.5 aparecen algunos nombres que no aparecen a en la gura 3.4, como los de las transiciones (T 1, T 2, T 3 y T 3 ) y el del estado nal (Estado f ). Esta circunstancia se debe a que el modelo UML de la mquina de estados hay elementos que no necesitan nombre, como las a transiciones y los estados inicial y nales, entre otros, pero en el metamodelo, las clases que representan estos elementos son especializaciones de otras clases que cuentan entre sus atributos con un nombre, que es el que aparece en la gura 3.5. En la gura 3.6 se muestra el diagrama de objetos correspondiente al dominio semntico de la mquina de estados del ejemplo de la gura 3.4. a a El diagrama de objetos representa una posible situacin instantnea de la o a mquina de estados. Concretamente, la gura muestra una situacin en la a o que el estado activo es el estado Estado 1.
Estado_1 Estado_2
Estado_3
Figura 3.4: Ejemplo de mquina de estados plana. a
2.2.
La mquina de estados con estados compuestos a
David Harel argumenta en [57] que una mquina de estados es un moa delo cuya utilidad para el diseo puede mejorarse si el concepto de estado n
139
Estado_f:FinalState initial = false
target incoming
T_f: Transition outgoing ME: StateMachine
source Estado_1:StateMachineState initial = true source outgoing T_1: Transition incoming Estado_2:StateMachineState initial = false target source outgoing T_2: Transition incoming Estado_3:StateMachineState initial = false target source outgoing target incoming
T_3: Transition
Figura 3.5: Diagrama de objetos de la sintaxis abstracta de la mquina de a estados de la gura 3.4.
MEI:StateMachineInstance MEIid:StateMachineInstanceIdentity
filmstrip
identity
owningStateMachineInstance activeState Est1:StateMachineStateInstance
Figura 3.6: Diagrama de objetos del dominio semntico de la mquina de a a estados de la gura 3.4. se ampl de tal forma que cada estado puede, a su vez, dividirse en otra a mquina de manera jerrquica. Entre las ventajas estn un mejor aprovechaa a a miento del rea de dibujo y diseos ms cercanos al sistema modelado. La a n a desventaja de ese modelo es que su semntica se complica porque aumentan a las posibles relaciones entre los estados y las transiciones. En esta seccin vamos a considerar un modelo ms completo que el de o a la seccin anterior en el que los estados pueden no ser simples, sino tamo bin compuestos. Los estados compuestos (CompositeState) estn divididos e a
140
jerrquicamente en subestados, lo que permite que el funcionamiento de la a mquina de estados pueda denirse en un nivel mayor de detalle. Esta es una a relacin de composicin, por lo que un estado puede estar contenido a lo suo o mo en un estado compuesto. Esta relacin tiene forma de rbol general donde o a el estado principal es la ra Dentro de los subestados hay uno distinguido, z. 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. o 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 o 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 u a desde el mencionado ancestro comn hasta el estado destino. u Conceptos de modelado En la gura 3.7 se muestra el diagrama de clases de los conceptos de modelado para las mquinas de estados con estados compuestos. Una mquina a a de estados se compone de sus estados y sus transiciones. Los estados compuestos pueden contener a su vez otros estados. Reglas de correccin o 1. En el nivel ms externo de la mquina de estados slo hay un estado a a o inicial.
context StateMachine inv:
ownedStateMachineStates->select(osms | osms.initial = true)->size() = 1
141
StateMachine::AbstractSyntax PackagedElement
+owningStateMachine StateMachine 0..1 1..* +substates 1..* 0..1 +ownedStateMachineStates +source +target
+owningStateMachine 0..1 0..* Transition +incoming 0..*
+ownedTransitions +outgoing 0..*
StateMachineState +initial : bool
+superstate CompositeState SimpleState
FinalState
Figura 3.7: Conceptos de modelado de las mquinas de estados con estados a compuestos. 2. Un estado compuesto slo puede tener un subestado directo que sea o inicial.
context CompositeState inv:
subStates->select(ss | ss.initial = true)->size() = 1
3. Los estados nales no pueden ser iniciales.

initial = false
4. Los estados nales no tienen transiciones de salida.

142
outgoing()->size() = 0
Dominio semntico a En la gura 3.8 se muestra el diagrama de clases correspondiente al dominio semntico de las mquinas de estados con estados compuestos. Como ya a a hicimos en la seccin 2.1 se dene una instancia de una mquina de estados o a como una especializacin de la clase SnapshotElementInstance. El domio nio semntico se ampl con dos nuevas clases para las instancias estados a a simples y compuestos, SimpleStateInstance y CompositeStateInstance, respectivamente.
State
+owningStateMachineInstance StateMachineInstance
+filmstrip 0..*
+identity StateMachineInstanceIdentity
+activeState StateMachineStateInstance +substates +superstate 0..1 SimpleStateInstance
CompositeStateInstance FinalState
Figura 3.8: Dominio semntico de las mquinas de estados con estados coma a puestos.
Aplicacin semntica o a En la semntica de este modelo se incluyen respecto al de la seccin a o anterior los diferentes tipos de estados, compuestos y simples (gura 3.9).
143
StateMachine::SemanticMapping
0..* StateMachine +of StateMachineState +of +instance 0..* CompositeState +of +instance 0..* SimpleState +of +instance 0..* FinalState +of +instance FinalStateInstance SimpleStateInstance CompositeStateInstance +instance 0..* StateMachineStateInstance StateMachineInstance
Figura 3.9: Aplicacin semntica de las mquinas de estados compuestos. o a a
Ejemplo
En la gura 3.10 se muestra una mquina que se compone, adems del a a estado inicial y el nal, de dos estados compuestos, cada uno de los cuales se rena en otra mquina con estado inicial, nal y dos estados simples. En la a gura 3.11 se muestra el diagrama de objetos correspondiente a la sintaxis abstracta de dicha mquina. En esta gura se han obviado las relaciones de a composicin entre la mquina de estados y las transiciones, denidas en la o a sintaxis abstracta, para mejorar la legibilidad. En la gura 3.12 se muestra el diagrama de objetos correspondiente al dominio semntico, representando un posible estado activo de la mquina. a a
144
E1 E11
E2 E21
E12
E22
Figura 3.10: Mquina de estados con estados compuestos. a
2.3.
La mquina de estados con estados concurrentes a
En esta seccin hacemos una segunda ampliacin del modelo de las mquio o a nas de estados incluyendo un nuevo tipo de estado compuesto, los estados concurrentes. Los que hemos considerado en la seccin anterior son los que o se denominan secuenciales. La diferencia entre ambas categor radica en as la forma en que pueden ejecutarse los subestados contenidos. Cuando un estado secuencial est activo, slo uno de sus subestados est activo. En a o a cambio, cuando un estado concurrente est activo, todos sus subestados lo a estn tambin. a e 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 a e a e que ser a su vez estados compuestos.
EF:FinalState initial : false owningStateMachine ME: StateMachine owningStateMachine T2:Transition outgoing T1:Transition outgoing superState superState subState E22:SimpleState initial : false target incoming T21:Transition source outgoing subState E2F:FinalState initial : false target incoming T22:Transition subState E12:SimpleState initial : false target incoming T11:Transition T12:Transition outgoing incoming source target source outgoing initial : false initial : true E1F:FinalState E21:SimpleState superState subState Ev1 : Event initial : false +ownedStateMachineStates target E2:CompositeState incoming source superState +ownedStateMachineStates source owningStateMachine +ownedStateMachineStates
target incoming
E1:CompositeState
initial : true superState subState
superState
subState
E11:SimpleState
initial : true
source
outgoing
145
Figura 3.11: Diagrama de objetos de la sintaxis abstracta de la mquina de a la gura 3.10.
146
MEI: StateMachineInstance
filmstrip identity
MSId: StateMachineInstanceIdentity
owningStateMachineInstance activeState EI: CompositeStateInstance superState subState E1I:CompositeStateInstance superState subState E12I:CompositeStateInstance
Figura 3.12: Diagrama de objetos del dominio semntico de la mquina de a a la gura 3.10. Conceptos de modelado En la gura 3.13 se muestra el diagrama de clases de los conceptos de modelado para las mquinas de estados con estados concurrentes. La principal a diferencia en este paquete es que aparecen dos nuevas clases, ConcurrentState y SequentialState, que especializan CompositeState.
Reglas de correccin o 1. Todos los subestados de un estado concurrente son estados compuestos.
context ConcurrentState inv
substates->forall(sb | sb.oclIsKindOf(CompositeState)) 2. Un estado concurrente tiene al menos dos subestados.

context ConcurrentState inv:
substates->size >= 2
147
PackagedElement
+owningStateMachine ++owningStateMachine 1..* +ownedStateMachineStates 0..1 +outgoing 0..* StateMachine 0..1 +ownedTransitions 0..* Transition 0..* +incoming
1..* +substates 0..1
StateMachineState +source -initial : Bool +target
+superstate
CompositeState
SimpleState
SequentialState
ConcurrentState
FinalState
Figura 3.13: Conceptos de modelado de las mquinas de estados con estados a concurrentes. Dominio semntico a En la gura 3.14 se muestra el diagrama de clases correspondiente al dominio semntico de las mquinas de estados con estados concurrentes. a a En este paquete tambin aparecen dos nuevas clases, ConcurrentStateInstance e y SequentialStateInstance, que especializan la clase CompositeStateInstance. Otra diferencia es que en el modelo anterior, en el que slo se considerao ban los estados compuestos, la cardinalidad de la relacin entre las clases o CompositeStateInstance y StateMachineStateInstance era 1 en el extremo substates porque slo pod estar activo un subestado del estado activo. o a
148
State
StateMachineInstance ++owningStateMachineInstance +activeState
+filmstrip 0..* +identity StateMachineInstanceIdentity
StateMachineStateInstance +substates 1..* +superstate 0..1 SimpleStateInstance
CompositeStateInstance
ConcurrentStateInstance
SequentialStateInstance
FinalState
Figura 3.14: Dominio semntico de las mquinas de estados con estados cona a currentes. Ahora hay que aadir reglas de correccin para diferenciar cuntos subesn o a tados pueden estar activos en funcin de si el estado activo es secuencial o o concurrente. Si es secuencial slo habr un subestado activo, y si es concuo a rrente habr uno por cada uno de sus subestados (regiones). a Reglas de correccin o 1. Todos los subestados de un estado concurrente son estados compuestos.
context ConcurrentStateInstance inv:
substates->forall(sb | sb.oclIsKindOf(CompositeStateInstance)) 2. Si el estado activo es compuesto y secuencial slo hay un subestado o activo.
context SequentialStateInstance inv:
149
substates->size = 1 3. Si el estado activo es compuesto y concurrente hay un subestado activo por cada subestado denido en los conceptos de dominio.
context ConcurrentStateInstance inv:
substates->size = self.of.substates.size Aplicacin semntica o a En la semntica de este modelo se incluyen nuevas clases para los nuevos a tipos de estados, los secuenciales y los concurrentes (gura 3.15). Ejemplo Para ilustrar el modelo de mquinas de estados concurrentes consideraa mos una mquina con dos estados, uno de los cuales es concurrente. En la a gura 3.16 se muestra la mquina de estados. En la gura 3.17 se muestra el a diagrama de objetos correspondiente a la sintaxis abstracta de dicha mquia na. En la gura 3.18 se muestra el diagrama de objetos correspondiente a uno de los posibles estados. En este caso est activo el estado concurrente a EstCon. Al ser concurrente tambin estarn activos un estado por cada uno e a de sus subestados. Concretamente, en la gura estn activos los subestados a EC1-1 y EC2-2.
2.4.
La recepcin de un evento o
En las secciones anteriores hemos ofrecido una visin esttica de las o a mquinas de estados en las que se muestra un estado activo en el que pera manece la mquina hasta que transita a otro estado. Las reglas de correccin a o presentadas se pueden incluir en lo que se denomina semntica esttica en la a a denicin de UML [118]. o
150
StateMachine::SemanticMappping
+of StateMachine
+instance StateMachineInstance 0..*
+of StateMachineState
+instance StateMachineStateInstance 0..*
+of SimpleState +of CompositeState
+instance 0..* +instance 0..*
SimpleStateInstance
+of SequentialState +of ConcurrentState
+instance 0..* +instance 0..* +instance
FinalState
+of
0..*
FinalStateInstance
Figura 3.15: Aplicacin semntica de las mquinas de estados concurrentes. o a a
El aspecto verdaderamente dinmico de las mquinas de estados reside a a en cmo se cambia de un estado a otro cuando se produce la ocurrencia de o un evento y qu acciones se ejecutan como respuesta. e Adems de los que no se tienen en cuenta para simplicar el modelo, a hasta ahora se han dejado aparte intencionadamente varios elementos. Estos elementos son: el evento que dispara una transicin, la guarda que la habio lita, las acciones asociadas, tanto a los estados como a las transiciones, y la recepcin de un evento. o Una mquina de estados cambia de estado como respuesta a la llegada a
151
EstCon
EC1-1
EC1-2
EC2-1
EC2-1
E2
Figura 3.16: Mquina de estados con estados concurrentes. a de una instancia de un evento. Si en el estado actual de la mquina hay una a transicin cuyo origen es un estado activo, la mquina responde al evento diso a parando dicha transicin. La mquina evoluciona entonces al estado destino o a de la transicin. o Las transiciones responden a un solo evento, y para poder hacerlo han de estar habilitadas. Una transicin est habilitada si su guarda, una expresin o a o esttica que devuelve un valor lgico, se evala a verdadero en el momento a o u de la recepcin del evento. o En una mquina de estados, los estados llevan asociadas, como parte de a la respuesta de la mquina a la ocurrencia de un evento, varias acciones: la de a entrada, la de salida y la llamada actividad 1 . Tambin las transiciones pueden e tener asociada una accin. Estas acciones se ejecutan secuencialmente como o parte de la respuesta de la mquina a la ocurrencia de un evento. Primero a se ejecutan las acciones de salida del estado del que se parte, despus las e
Las actividades son una de las caracter sticas que no vamos a considerar en nuestro modelo de la mquinas de estados. a
1
152
E3: FinalState T2: Transition outgoing source E2: SimpleState ME: StateMachine initial = false +ownedStateMachineStates EstCon:ConcurrentState superState initial = true subState superState superState superState subState EC12: SimpleState initial = false target incoming outgoing source target incoming initial = false EC13: FinalState subState superState subState EC21: SimpleState initial = true source outgoing EC2: CompositeState superState subState EC22: SimpleState initial = false target incoming T21: Transition source subState +ownedStateMachineStates target incoming owningStateMachine source T1: Transition outgoing superState incoming initial = false +ownedStateMachineStates owningStateMachine owningStateMachine
target
subState
EC1: CompositeState
superState
subState
EC11: SimpleState
EC23: FinalState initial = false target outgoing incoming T22: Transition
initial = true source outgoing T11: Transition
Figura 3.17: Diagrama de objetos de la sintaxis abstracta de la mquina de a la gura 3.16.

T12: Transition

filmstrip identity
153
MEI: MachineStateInstance
MSId: MachineStateInstanceIdentity
owningStateMachineInstance activeState EstConI: ConcurrentStateInstance superState subState EC11I: SimpleStateInstance superState subState EC22I: SimpleStateInstance
Figura 3.18: Diagrama de objetos del dominio semntico de la mquina de a a la gura 3.16.
acciones asociadas a la transicin y, nalmente, las acciones de entrada del o estado al que se llega.
Si la instancia de un evento llega cuando la mquina est en un estado a a en el que no hay ninguna transicin para l, esa ocurrencia se consume sin o e respuesta. Cada estado puede, sin embargo, especicar lo que se denomina la lista de eventos postergados. Estos eventos no son tratados en el estado, pero tampoco se descartan, sino que se guardan para su tratamiento posterior cuando se cambie a un nuevo estado. La lista de eventos postergados tampoco la incluiremos en nuestro modelo.
En este modelo se incluyen los dos tipos de transiciones denidos en UML, las externas y las internas. La externas son las que se han tratado hasta ahora: reaccionan frente a la ocurrencia de un evento y pueden provocar el cambio de estado y la ejecucin de las acciones asociadas. Por su lado, las internas o no efectan cambio de estado, slo consumen la ocurrencia de un evento y u o slo se ejecuta la accin asociada a la transicin, no las de salida o entrada o o o del estado.
154
El cambio de estado Cuando se recibe un evento, si en el estado actual, o en alguno de sus subestados, hay alguna transicin que se dispare con una ocurrencia de ese o evento y dicha transicin est activa, es decir, su guarda se evala a verdao a u dero, se dispara esa transicin. o Como los estados pueden estar anidados, tanto el origen como el destino de la transicin que se ejecuta pueden ser subestados de otro u otros. Es o posible, por tanto, que la ejecucin de una transicin provoque que se salga o o de ms de un estado y se entre en ms de un estado. En el estado nal de la a a mquina de estados no puede aparecer ninguna instancia de los estados de a los que se ha salido. Para saber de qu estados se sale, se puede usar el concepto de LCA, e Least Common Ancestor, denido en [118]. El LCA de dos estados es el ancestro comn ms interior del estado origen y el destino. Es decir, es un u a ancestro comn tal que no hay ningn otro ancestro comn que sea a su vez u u u descendiente del LCA. Cuando se ejecuta una transicin, se sale de todos o aquellos estados activos que sean descendientes del LCA. Los estados en los que se entran son los que cumplen las siguientes condiciones: 1. es descendiente del LCA de los estados origen y destino de la transicin, o y 2. a) es el estado destino, o b) es un ancestro del estado destino, o c) su superestado se activa en el estado destino y 1) es el estado inicial de un superestado secuencial, o
155
2) el superestado es concurrente.
La ultima regla es la que hace referencia a aquellos estados que no son ascendientes directos del estado nal pero que acaban activos porque pertenecen a alguna regin de un estado concurrente que es tanto ascendiente del o estado destino como descendiente del LCA de los estados origen y destino. En la gura 3.19 se muestra una mquina de estados como ejemplo. En a esta mquina en la que en el estado principal estn el estado A, que es a a concurrente y se divide en dos regiones, y el estado B, que es simple. Estas regiones, a su vez, se dividen en otros estados compuestos, bien secuenciales o concurrentes. Por claridad, slo se muestran las transciones a los estados o iniciales y otras dos transiciones, una que parte del estado A112 y llega al estado B, disparada por el evento ev1 y otra que parte del estado B y llega al estado A211, disparada por el evento ev2. Supongamos que, en un momento dado, el estado en el que se encuentra esta mquina implica que estn activos los estados: A, A1, A2, A11, A12, a a A21, A112, A121, A211, A212, A2112 y A2121. Si hay una ocurrencia del ev1 y se ejecuta la transicin asociada, el LCA de los estados A112 y B es o EstadoPrincipal, por lo que se sale de todos los estados activos excepto el estado principal. Por otro lado, si se produce una instancia del evento ev2 siendo B el estado activo, se saldr del estado B y se entrar en los estados a a A, A1, A2, A11, A12, A21, A111, A121, A211, A212, A2111 y A2121. Los estados A212 y A2121 son ejemplos de estados que se activan por la ultima de las reglas enunciadas anteriormente. No son superestados del estado nal, A211, pero pertenecen, a distinto nivel, a una regin del estado concurrente o A21, que es superestado del estado destino y descendiente del origen y el destino de la transicin. o
156
A A1 A11 A111 A112 ev1
A12 A121 A122 B
A2 A21 A211 A2111 A2112 A22 A212 A2121 A2122 ev2
Figura 3.19: Mquina de estados con eventos. a La ejecucin de las acciones o Durante la ejecucin de una transicin se ejecutan tres acciones secueno o cialmente y en este orden: la accin de salida del estado actual, la accin de o o la transicin y la accin de entrada del estado destino de la transicin. o o o Si considerramos slo el modelo de la mquina de estados plana, es muy a o a fcil ver que el estado en el que est la mquina tiene que ser una instancia a a a del estado origen, source, de la transicin y que el estado en el que queda la o mquina tiene que ser una instancia del estado nal, target, de la transicin. a o Si pasamos a considerar estado compuestos, la cuestin se complica poro que, como ya hemos visto, el estado actual de una mquina puede involucrar a a ms de un estado. Como la transicin puede salir de varios estados anidaa o
157
dos, se ejecutan las acciones de salida de todos los estados de los que se sale. En la especicacin ocial de UML 2.0 [118], se dice que se ejecutan secueno cialmente empezando por la accin del estado ms interno. Eso es vlido para o a a cuando los estados involucrados son secuenciales, pero no se dice nada sobre en qu orden se ejecutan las acciones de salida si se salen de las diferentes e regiones de un estado concurrente. Una posibilidad es considerar que se sale de las regiones de manera concurrente, es decir, que las acciones de salida de los estados de los que se sale de dentro de una regin se ejecutan de manera concurrente con las acciones o de salida de los estados de las otras regiones del mismo estado concurrente. Dentro de una regin se ejecutar secuencialmente desde el estado ms o an a interno como se especica en [118]. Volvamos otra vez al ejemplo de la gura 3.19 y volvamos tambin a e suponer que el estado en el que se encuentra dicha mquina implica que a estn activos los estados: A, A1, A2, A11, A12, A21, A112, A121, A211, a A212, A2112 y A2121. Si llega una instancia del evento ev1 y se ejecuta la transicin asociada hasta el estado B, se sale de todos los estados activos. La o gura 3.20 muestra el diagrama de actividad que corresponde a la ejecucin o de las acciones segn el modelo comentado en el prrafo anterior. En la u a gura 3.21 se muestra el objeto de la clase Action a la que corresponde dicha ejecucin. o Lo mismo ocurre con las acciones de entrada: si una transicin entra o en ms de un estado anidado, se ejecutan secuencialmente las acciones de a entrada de todos los estados en los que se entra. En este caso, el orden es el inverso y se ejecuta primero la accin del estado ms exterior. Si se entra en o a un subestado de un estado concurrente, se activan todas las regiones de ese estado concurrente. La especicacin de UML no aclara cul es el orden en el o a
158
A2112
A2121
A111
A121
A211
A212
A11
A12
A21
A1
A2
Figura 3.20: Diagrama de actividad de la ejecucin de la transicin del evento o o ev1 en la gura 3.19 supuesto el estado indicado. que se ejecutan las acciones de entrada de los estados activos de las regiones. Podemos suponer que se ejecutan como acciones concurrentes independientes todas las acciones de entrada que pertenezcan a la misma regin. o En ese caso, si en el ejemplo de la gura 3.19 el estado B est activo a y se produce una instancia del evento ev2, se efectuarn como acciones de a
de la gura 3.23
:SequentialAction ConcurrentAction A: Action SequentialAction SequentialAction :ConcurrentAction A1:Action SequentialAction A2:Action :SequentialAction :ConcurrentAction :SequentialAction A21: Action A11: Action :SequentialAction :SequentialAction A12: Action :SequentialAction :SequentialAction A211:Action A212:Action :SequentialAction :A111: Action A121: Action :SequentialAction
A211:Action
A211:Action
159
Figura 3.21: Evaluacin de la accin compuesta correspondiente a la ejecucin o o o de la transicin del evento ev1 en la gura 3.19 en el estado considerado. o
entrada las que se muestran en el diagrama de actividad de la gura 3.22.
La accin compuesta correspondiente se muestra en el diagrama de objetos o
160

A
A1
A2
A21
A11
A12
A111
A121
A211
A212
A2111
A2121
Figura 3.22: Diagrama de actividad de las acciones de entrada en la ejecucin o de la transicin del evento ev2 en la gura 3.19 suponiendo el estado indicado. o Conceptos de modelado En la gura 3.24 se muestra el diagrama de clases de los conceptos de modelado para las mquinas de estados teniendo en cuenta las acciones. a En este paquete se aade a los estados las acciones que se ejecutan al n realizar un cambio de estado, la accin de salida y la accin de entrada, o o representadas por las relaciones exitAction y entryAction con la clase Action. Por su parte, las transiciones tambin se ampl con otra relacin con la e an o clase Action, transitionAction, que representa la accin asociada a la trano sicin. La otra relacin nueva de las transiciones es la guarda, representada o o por una instancia de la clase StaticExpression.
:SequentialAction
Reglas de correccin o
A: Action ConcurrentAction SequentialAction SequentialAction A2:Action
Figura 3.23: Diagrama de objetos correspondiente a la accin compuesta de o la ejecucin de la transicin del evento ev2 en la gura 3.19 en el estado o o considerado.
1. El valor de la guarda de la transicin es de tipo Boolean. o

A1:Action :ConcurrentAction :SequentialAction :SequentialAction :SequentialAction A21: Action :ConcurrentAction :A11: Action A12: Action :SequentialAction :SequentialAction :SequentialAction :SequentialAction :A211: Action A212: Action A111: Action A121: Action :SequentialAction :SequentialAction
context Transition inv:

A111: Action A2122: Action
161
162
PackagedElement
++owningStateMachine 0..1 +source +ownedStateMachineStates StateMachineState -initial : Bool +substates 1..* +superstate 0..1 SimpleState +exitAction 0..1 +target +entryAction 0..1 Action 0..1 +transitionAction CompositeState StateMachine
+owningStateMachine 0..1
+outgoing +incoming 0..* +ownedTransitions 0..* 0..* Transition
StaticExpression +guard
0..* +transition Event
+event
SequentialState
ConcurrentState
FinalState
ExternalTransition
InternalTransition
Figura 3.24: Conceptos de modelado de las mquinas de estados con acciones. a
self.guard->type.isKindOf(Boolean)
2. Una transicin no puede ir de una regin a otra dentro del mismo eso o tado concurrente.
context Transition inv:
self.source.superState.isKindof(ConcurrentState) implies self.source.superState <>self.target.superState
Mtodos e 1. ancestor(s1, s2) comprueba si s1 es un estado ancestro de s2.

context StateMachine:
ancestor (s1 : StateMachineState, s2 : StateMachineState) : Boolean
163
if (s2 = s1) then true else if (s1.superState->isEmpty) then true else if (s2.superState->isEmpty) then false else ancestor (s1, s2.superState) endif endif endif 2. LCA(s1,s2) devuelve el m nimo estado comn ancestro de s1 y s2. u Denida en [118] como:
context StateMachine:
LCA (s1 : StateMachineState, s2 : StateMachineState) : CompositeState if self.ancestor (s1, s2) then s1 else if self.ancestor (s2, s1) then s2 else self.LCA (s1.superstate, s2.superstate) endif endif
Dominio semntico a En la gura 3.25 se muestra el diagrama de clases correspondiente al dominio semntico de las mquinas de estados teniendo en cuenta las acciones. a a Una de las clases nuevas en este diagrama, EventReception, representa la
164
StateMachine::SemanticDomain +ownedSnapshotElementInstance 0..* SnapshotElementInstance StateMachineInstanceIdentity State +identity +filmstrip 0..* +owningStateMachineInstance +stateMachineInstance StateMachineInstance 0..1 State StaticExpEval +substates +superstate 0..1 +activeState 1..* +eventInstance StateMachineStateInstance EventInstance +guardEval EventReception Snapshot pre 0..1 +owningSnapshot +post
SequentialActionEvaluation
SimpleStateInstance
FinalStateInstance
Figura 3.25: Dominio semntico de las mquinas de estados con acciones. a a accin que se ejecuta en el mbito de una mquina de estados cuando se recibe o a a y procesa una ocurrencia de un evento. Como ocurre con las dems acciones a descritas en el cap tulo dedicado a las acciones de [121], una instancia de la clase EventReception est asociada con dos instancias de la clase Snapshot, a pre y post, que representan, respectivamente, el estado en el que se encontraba la mquina de estados cuando se produjo la ocurrencia del evento y el estado a en el que queda la mquina tras el procesamiento de dicho evento. a La recepcin de un evento tiene ms informacin relacionada. Por un lado, o a o la instancia de la mquina de estados que recibe el evento, que es parte del a snapshot de origen; por eso, la clase StateMachineInstance es una subclase de SnapshotElementInstance. Por otro lado, est asociada a la instancia a del evento que se procesa y, nalmente, a las acciones que se ejecutan como parte del procesamiento de ese evento.
165
Reglas de correccin o 1. La guarda de la transicin se evala a verdadero para que la transicin o u o est activa. e
context EventReception inv:
self.guardEval = true 2. La guarda de la transicin se evala en el estado activo inicial. o u

self.guardEval.subActionEval.forall(sae | sae.ExpressionEvaluations()->forall(ee | ee.allSubExpressionEvaluations()->forall(see | see.ReferredInstances()->forall(ri | ri.owningSnapshot = self.pre))) 3. La recepcin del evento implica la ejecucin de tres acciones. o o
exec.subExecution->size = 3 4. Las transiciones internas no cambian de estado.

context InternalTransition inv:
source = target
5. Si la transicin es interna, slo se ejecuta la accin de la transicin. o o o o

self.of.isKindOf(InternalTransition) implies (previous = next and previous.allSubtates() = next.allSubtates() and self.subExecution->at(1).oclIsTypeOf(NullExecution) and self.subExecution->at(2).oclIsKindOf(self.of.transitionAction) and self.subExecution->at(3).oclIsTypeOf(NullExecution))
166
6. Si la transicin es externa, la primera accin debe ser una accin como o o puesta que corresponda con las acciones de salida de los estados de los que se sale. El rbol de subestados activos de los que se sale depende a del LCA de los estados origen y destino y del estado activo actual.
self.of.oclIsKindOf(ExternalTransition) implies self.pre.activeSubStatesInstancesTree( self.of.owningStateMachine.LCA(self.of.source,self.of.target)) ->any(true).validExitEvaluation(self.subExecution->at(1))) 7. Si la transicin es externa, la segunda accin se corresponde con la aco o cin asociada a la transicin. o o
(self.of.oclIsKindOf(ExternalTransition) and self.of.transitionAction->size = 1 implies exec.subExecution->at(2).of = self.of.transitionAction) and (self.of.oclIsKindOf(ExternalTransition) and self.of.source.transitionAction->size = 0 implies exec.subExecution->at(2) = nullActionExecution) 8. Si la transicin es externa, la tercera accin debe ser una accin como o o puesta que corresponda con las acciones de entrada de los estados que acaban siendo activos al nal de la transicin. El rbol de subestados o a que se activan depende del LCA de los estados origen y destino de la transicin y del estado activo nal. o
self.of.oclIsKindOf(ExternalTransition) implies self.post.activeSubStatesInstancesTree( self.of.owningStateMachine.LCA(self.of.source,self.of.target)) ->any(true).validExitEvaluation(self.subExecution->at(3)))
167
9. El estado nal no puede contener ninguno de los estados de los que se ha salido.
self.post.allSubStatesInstances.excludesAll( self.pre.activeSubStatesInstancesTree( self.of.owningStateMachine.LCA(self.of.source,self.of.target)) ->any(true).allSubStatesInstances()) Mtodos e 1. El mtodo allSubstatesInstances() devuelve el conjunto de todas e las instancias de subestados de una instancia de un estado.
context StateMachineStateInstance:
allSubstatesInstances():Set(StateMachineStateInstance) {} 2. El mtodo allSubstatesInstances() devuelve el conjunto de todas e las instancias de subestados de una instancia de un estado compuesto.
context CompositeState:
allSubstatesInstances():Set(StateMachineStateInstance) substates->iterate(ss ac = substates | ac->union(ss.allSubStates())) 3. El mtodo allSubstatesInstances() devuelve el conjunto de todas e las instancias de subestados de una instancia de un estado simple.
context SimpleState:
allSubstatesInstances():Set(StateMachineStateInstance) {} 4. El mtodo postState() devuelve el estado de la mquina de estados e a en el siguiente snaphot, es decir, el estado tras la ejecucin de la recepo
168
cin del evento. o

context EventReception:
postState() : StateMachineInstance self.post.ownedSnapshotElementInstance.select(osei | osei.identity = self.stateMachineInstance.identity)
5. El mtodo activeSubStatesInstancesTree() devuelve el rbol de e a instancias de subestados cuya ra es una instancia del estado que se z pasa como parmetro. Si el estado sobre el que se aplica es una instancia a del parmetro, entonces se devuelve como ra del rbol el subestado a z a que es ancestro del destino de la transicin. En caso contrario, se busca o entre los subestados. Este mtodo se usa para calcular de qu estados e e se sale al ejecutar una transicin aplicndolo sobre el estado origen de o a la transicin y pasando como parmetro el LCA de los estados origen o a y destino de la transicin. o
activeSubStatesInstancesTree(sms : StateMachineState) : StateMachineStateInstance if self.of = sms then self.subStates()->select(ss | ss.of.ancestor(self.of.target)) else self.subStates()->iterate(ac = Set{}, ss |ac = Set{}, ac->union(ss.activeSubStatesInstancesTree(sms))) endif
6. El mtodo validExitEvaluation() devuelve true si un rbol de ejee a cuciones de acciones es una ejecucin vlida de un rbol de estados del o a a que se sale en la ejecucin de una transicin. o o
169
validExitEvaluation(acteval: ActionEvaluation): Bool if self.isKindOf(simpleState) then acteval.of = self.exitAction else if self.isKindOf(sequentialState) then acteval.subEvals()->size = 2 and acteval.subEvals()->at(2).of = self.exitAction and acteval.subEvals()->at(1). isKindOf(sequentialActionEvaluation) and self.substates.validExitEvaluation(acteval.subevals()->at(1)) else if self.isKindOf(concurrentState) then acteval.subEvals()->size = 2 and acteval.subEvals()->at(2).of = self.exitAction and acteval.subEvals()->at(1). isKindOf(concurrentActionEvaluation) and self.substates()->foreach(ss | actEval.subEvals()-> one(se | ss.validExitEvaluation(se))) endif endif
7. El mtodo validEntryEvaluation() devuelve true si un rbol de ejee a cuciones de acciones es una ejecucin vlida de un rbol de estados del o a a que se sale en la ejecucin de una transicin. o o
validEntryEvaluation(acteval: ActionEvaluation): Bool
170
if self.isKindOf(simpleState) then acteval.of = self.exitAction and acteval.subEvals()->size = 0 else if self.isKindOf(sequentialState) then acteval.isKindOf(seqAction) and acteval.subEvals()->size = 2 and acteval.subEvals()->at(1).of = self.entryAction and acteval.subStates()->at(1).validEntryEvaluation( acteval.subevals()->at(2)) else // self.isKindOf(concurrentState) then acteval.isKindOf(seqAction) and acteval.subEvals()->size = 2 and acteval.subEvals()->at(1).of = self.entryAction and acteval.subEvals()->at(2). isKindOf(concurrentActionEvaluation) and self.substates()->foreach(ss | actEval.subEvals()->at(2)-> subActionEvals()->one(se | ss.validEntryEvaluation(se))) endif endif
Aplicacin semntica o a En la semntica de este modelo se incluyen, adems de los previamente a a considerados, los conceptos relativos a los eventos y las transiciones (gura 3.26). Ejemplo En la gura 3.27 se muestra una mquina en la que slo se han marcado a o algunas transiciones y acciones. En la gura 3.28 se muestra el diagrama de objetos correspondiente a la sintaxis abstracta de dicha mquina. En la a gura 3.29 se muestra el diagrama de objetos correspondiente al dominio semntico. El diagrama corresponde a dos instantes en la vida del objeto, que a estaba en los estados E-1, E1-1, E13-1 y E14-1 y tras recibir una instancia
171
StateMachine::SemanticMapping +of StateMachine 0..* +of StateMachineState +of SimpleState +of CompositeState 0..* +of SequentialState 0..* ConcurrentState +of +instance 0..* 0..* FinalState +of Transition +of FinalStateInstance +instance +instance 0..* +instance 0..* EventReception ConcurrentMachineStateInstance +instance SequentialMachineStateInstance 0..* +instance CompositeMachineStateInstance 0..* +instance SimpleStateInstance +instance StateMachineStateInstance +instance StateMachineInstance
Event
+of
EventInstance
Figura 3.26: Aplicacin semntica de las mquinas de estados con acciones. o a a del evento et1, ha transitado a los estados E-2, E2-1, E21-1 y E211-1. En estas dos ultimas guras no se muestran los nombres de los extremos de las relaciones para evitar que la gura est demasiado cargada. Tampoco se han e incluido las relaciones composicin entre las transiciones y la mquina de o a estados en la gura 3.28.
172
E1 exit / ae1 E11 et1 / at1 t11 E12 exit / ae12 entry / ae21 entry / ae2
E2
E21 E211 entry / ae211
E13
E212
t13 E14 exit / ae14 E22
Figura 3.27: Mquina de estados con estados concurrentes y eventos. a
ME :StateMachine
ae1: Action initial : true et1: Event at1: Action initial : false
E1: ConcurrentStateMachineState
t1: Transition E2: SequentialStateMachineState
t2: Transition
EF: FinalState initial : false
ae21: Action
ae2: Action t21: Transition t22: Transition
E1R1 : SequentialStateMachineState initial : false initial : true
E1R2: SequentialStateMachineState
E21: SequentialStateMachineState
E22 : StateMachineState initial : false
E2F: FinalState initial : false
initial : false
E11: StateMachineState initial : false initial : true initial : false initial : false
E12StateMachineState
E1R1: FinalState E13: StateMachineState E14: StateMachineState
E1R2F: FinalState
E211: StateMachineState initial : true
E212: StateMachineState initial : false
E21F: FinalState initial : false
initial : true
initial : false
t12: Transition ae14: Action
ae12: Action
t12: Transition
t13: Transition
t14: Transition
ae211: Action
t211: Transition
t212: Transition
173
Figura 3.28: Diagrama de objetos de la sintaxis abstracta de la mquina de a estados de la gura 3.27.
174
smii: StateMachineInstanceIdentity
s1: Snapshot smi1: StateMachineInstance E1: SequentialStateInstance E11: ConcurrentStateInstance E141: SimpleStateInstance er: EventReception E1: SequentialActionEvaluation : SequentialActionEvaluation : ConcurrentActionEvaluation ae141: ActionEvaluation ae11: ActionEvaluation at11: ActionEvaluation : SequentialActionEvaluation ae21: ActionEvaluation smi2: StateMachineInstance E2: SequentialStateInstance E21: SequentialStateInstance E211: SequentialStateInstance E2111: SequentialStateInstance
s2: Snapshot
E131: SimpleStateInstance et11: EventInstance
: SequentialActionEvaluation ae211: ActionEvaluation : SequentialActionEvaluation ae2111: ActionEvaluation
Figura 3.29: Diagrama de objetos del dominio semntico de la mquina de a a estados de la gura 3.27.
ae121: ActionEvaluation
175
3.
3.1.
El tiempo real en las mquinas de estados a

Perl de Planicabilidad, Rendimiento y Especicacin del Tiempo o
El Perl UML de Planicabilidad, Rendimiento y Especicacin del Tiemo po (UML Prole for Schedulability, Performance, and Time Specication, [56]) pretende extender UML para que se pueda usar para la especicacin y o diseo de sistemas de tiempo real en toda su extensin y diversidad. El grupo n o de trabajo que ha realizado este perl arma que las extensiones presentes en UML son sucientes para llevar a cabo la tarea. Los autores de este perl han intentado hacer un marco lo sucientemente amplio como para que cubra todas las distintas caracter sticas de los sistemas de tiempo real pero que, a la vez, sea lo bastante exible como para permitir futuras especializaciones. Como indican los autores, no han pretendido desarrollar nuevas tcnicas e de anlisis, sino anotar los modelos UML de forma que las tcnicas de anlisis, a e a 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 perl se cita la o posibilidad de construir herramientas que, de manera automtica, construyan a modelos para distintos tipos de anlisis concretos a partir de un modelo dado. a Estas herramientas deber poder leer el modelo, procesarlo y realimentar an con sus resultados el modelo original. A la hora de establecer cmo se ha de usar el perl, los autores diferencian o tres actores: El modelador, que construye modelos y est interesado en analizarlos a para saber si cumplen los requisitos requeridos.
176
3. El tiempo real en las mquinas de estados a
El proveedor de mtodos de anlisis de modelos, que dene mtodos de e a e anlisis y herramientas para llevarlos a cabo. a El proveedor de infraestructura, que proporcionan tecnolog como as sistemas operativos de tiempo real o bibliotecas de componentes de tiempo real. De entre los posibles usos que los autores esperan para el perl, los que estn a pensados para los modeladores son: Sintetizar el modelo, que incluir los estereotipos y valores etiquetados a necesarios para llevar a cabo los anlisis necesarios. a Analizar el modelo, posiblemente desde varios puntos de vista y a diferentes niveles de detalle. Para el anlisis se usarn la anotaciones a a aadidas al modelo UML. n Implementar el sistema, que consiste en construir la aplicacin que o ejecute el modelo creado anteriormente. Estructura Debido a la gran diversidad de posibles sistemas de tiempo real, hard y soft, distribuidos y monoprocesadores, etc., es muy dif establecer un cil conjunto cannico de conceptos de modelado y diseo que comprenda todos o n los sistemas. Esta situacin se agrava cuando se tienen en cuenta, adems, las tcnicas o a e de anlisis. A la hora de analizar un modelo, el analizador suele trabajar con a una versin simplicada del sistema, del que se eliminan aquellas caracter o sticas que no son relevantes para el anlisis. Una de las cuestiones que complica a esta simplicacin es el hecho de que es bastante usual el que las entidades o
177
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 a concurrencia en las que se base el modelo, procesos o hebras, pueden estar denidas slo de forma impl o cita u ocultas en el modelo del sistema. Otra dicultad aadida viene dada por el hecho de que sobre un mismo n modelo de un sistema se pueden hacer diferentes anlisis, cada uno de los a cuales se puede centrar en un aspecto concreto del sistema como, por ejemplo, su planicabilidad o el consumo de memoria. Aspectos relevantes para un determinado anlisis pueden no ser interesantes para otro. a Para superar ese problema los autores del perl proporcionan un marco unico que comprende los elementos comunes de los distintos mtodos de e anlisis de sistemas de tiempo real. El ncleo de este marco lo constituye a u la denicin de recursos de todo tipo y de sus calidades de servicio. Esta o denicin se hace en el paquete de Modelado de Recursos Generales. A partir o de estas deniciones bsicas, para cada mtodo de anlisis hay que denir los a e a conceptos particulares que se necesiten. Estos conceptos se denirn como a especializacin de los ya denidos en los mdulos de recursos generales. o o Los modelos conceptuales se representan como paquetes y diagramas de clases UML en los que las clases representan conceptos del dominio, mientras que el perl UML consta de estereotipos UML, que se corresponden con los conceptos de dominio. En un hipottico modelo de anlisis, los conceptos proe a pios de ese modelo ser paquetes y clases que especializar los conceptos an an del Modelo de Recursos Generales. En el perl UML habr clases estereoa tipadas que corresponder a la especializacin de elementos ms generales an o a del perl. Entre los conceptos del modelo particular y las correspondientes clases del perl de UML se establecer la relacin adecuada. a o No todos los conceptos de dominio tienen un estereotipo o un valor eti-
178
quetado correspondiente, porque algunos de esos conceptos son demasiado abstractos y nunca se van a usar directamente en ningn modelo de anliu a sis, sino que algunos modelos usarn una especializacin de ese concepto, y a o ser para el concepto especializado para el que se dena el estereotipo o valor a etiquetado correspondiente en UML. Como ya se ha comentado anteriormente, los autores del perl argumentan que los mecanismos de extensin ofrecidos por UML, estereotipos y vao lores etiquetados, son sucientes para la tarea encomendada. Ellos ven los estereotipos como un mecanismo de especializacin de clases que permite o aadir nuevos atributos a la clase especializada. Sin embargo, este mecanismo n de estereotipado no permite agregar nuevas asociaciones en el metamodelo respecto a las que ya ten la clase especializada. Las nuevas asociaciones a 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. o Otras asociaciones se corresponden con etiquetas asociadas con el estereotipo. En unos pocos casos, una asociacin de dominio se representa mediante o una relacin del tipo o de UML. Otro de los objetivos del perl ha sido permitir ms especializaciones de a modelos de dominio concreto cuando hagan falta. Como aplicacin ejemplo o del perl, los autores han desarrollado el subperl de CORBA de tiempo real como especializacin del perl de anlisis de planicabilidad. o a taggedValue de los mecanismo de perles
179
Modelado de recursos La parte fundamental del perl es el paquete en el que se denen los recursos. Han intentado denir recursos sucientemente generales como para ser una base comn suciente para poder denir los dems recursos y conceptos u a propios de cada modelo particular que se dena posteriormente. La cuanticacin de las restricciones que afectan a los sistemas de tiempo o real es uno de los aspectos fundamentales que se tratan en el perl y, por tanto, las caracter sticas de calidad de servicio son una parte integral de los recursos. Estas caracter sticas de calidad de servicio tienen sentido en un contexto en el que se pueda indicar, adems de la calidad de servicio ofrecida a 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, u a a en comparar ambas capacidades. En el perl 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 o o iguales y se puede indicar mediante una asociacin. La otra forma de uso de o recursos es una interpretacin jerarquizada, en la que el cliente est en un o a nivel y el recurso est en otro, generalmente para modelar una situacin en a o 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 perl. Por un lado, se modela el tiempo como magnitud, para medir las restricciones. Slo se o dene el tiempo mtrico, ya que los autores argumentan que, habitualmente, e los sistemas de tiempo real se ocupan de la cardinalidad del tiempo, como en el caso del cumplimiento de los plazos temporales. Encuentran util distinguir
180
entre tiempo f sico y tiempo virtual, o de simulacin, que puede incrementarse o de manera no montona. o 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. e Finalmente, tambin se hace referencia a los diferentes patrones que son e esenciales en la planicabilidad o los distintos anlisis, como la periodicidad, a o la denicin de plazos e intervalos temporales. o Modelado de la planicabilidad El perl se centra en la especicacin de sistemas de tiempo real duros, es o decir, aquellos en los que se han de cumplir todos los plazos, para lo que suele ser necesario poder establecer un l mite superior en el tiempo de respuesta del sistema a los diferentes eventos. El objetivo principal del perl en este aspecto ha sido cmo anotar el modelo para permitir diferentes modelos de o planicabilidad, para determinar si se cumplen o no los plazos temporales. Para evitar conictos debidos a la nomenclatura, se han decidido por un marco comn a todos los posibles anlisis de planicabilidad en los que, en u a un principio, han incluido los ms usados actualmente, como Rate Monotonic a Analysis (RMA), Deadline Monotonic Analysis (DMA) y Earliest Deadline First (EDF). Sin embargo, los autores deenden que sus anotaciones son sucientemente exibles como para poder usar otros mtodos e, incluso, para e poder denir extensiones propias si son necesarias para otros mtodos de e anlisis. a Modelado del rendimiento Segn los autores del perl, el anlisis del rendimiento tiene muchas cau a racter sticas comunes con el anlisis de planicabilidad, por lo que comparten a
181
como base comn el Modelo de Recursos Generales. Consideran que el anliu a sis del rendimiento es ms adecuado para sistemas de tiempo real no estrictos a porque se basa en tcnicas estad e sticas, como teor de colas, que producen, a asimismo, resultados estad sticos. Por tanto, el modelo que proponen es m nimo, con la esperanza de que los desarrolladores de herramientas especialicen nuevos subperles concretos para anlisis particulares. An as arman que lo que ofrecen es suciente a u , para hacer un anlisis bsico de rendimiento incluso de sistemas complejos. a a
Estructura del perl Al perl se le ha dado una estructura modular para permitir que los usuarios no tengan que considerar todo el perl en su conjunto, sino que puedan trabajar slo con una parte de l. Esta divisin tambin est pensada o e o e a para facilitar su especializacin. o El perl est dividido en una serie de subperles (gura 3.30), organizaa dos en paquetes, dedicados a aspectos concretos y a tcnicas de anlisis de e a modelos. El ncleo del perl es el conjunto de paquetes que representa el u 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 a especializaciones slo tengan que usar la parte concreta que necesiten. o 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 a y tiempo que se denan. Tanto la concurrencia como el tiempo se denen en sus propios subpaquetes dentro del paquete principal. El perl dene tambin un segundo paquete en el que se incluyen tres e
182
General Resource Modeling Framework << profile>> RTresourceModeling

<<import>> <<import>>
<< profile>> RTconcurrencyModeling
<< profile>> RTtimeModeling
<<import>>
<<import>> <<import>>
Infrastructure Models
<< modelLibrary>> Analysis Models << profile>> SAProfile

<<import>>
RealTimeCORBAModel << profile>> PAProfile
<< profile>> RSAProfile
Figura 3.30: Estructura de paquetes del perl de Planicabilidad, Rendimiento y Especicacin de Tiempo. o tipos de anlisis, el anlisis de planicabilidad (SAProle), el de rendimiento a a (PAProle) y uno adicional que es una especializacin del de planicabilidad, o (RSAProle), para analizar la planicabilidad de sistemas CORBA de tiempo real. Junto con esos paquetes se ha denido un modelo de biblioteca con la denicin de un modelo de CORBA de tiempo real. Este modelo pretende o ser un ejemplo que avale el trabajo hecho en el perl. El paquete de modelado de recursos generales El paquete de modelado de recursos generales, General Resource Modeling Framework (GRM ), es la parte fundamental del perl, en la que se denen
183
los fundamentos necesarios para el anlisis cuantitativo de modelos UML. La a nocin bsica del modelo es la de calidad de servicio, que proporciona una o a base uniforme para adjuntar informacin cuantitativa a los modelos UML. o La informacin sobre calidad de servicio representa, de manera directa o o indirecta, las propiedades f sicas de los entornos hardware y software de la aplicacin representada en el modelo. o Los diferentes aspectos del GRM se agrupan en paquetes individuales. La estructura interna del paquete GRM se muestra en la gura 3.31.
Realization Model
ResourceUsageModel
DynamicUsageModel
StaticUsageModel
ResourceManagement
ResourceTypes CausalityModel
CoreResourceModel
Figura 3.31: Estructura de paquetes del Marco de Modelado de Recursos Generales. Los autores aclaran que para los propsitos de este perl es fundamental o distinguir entre elementos descriptores, como las clases y los tipos, y elementos instancias de tiempo de ejecucin, como los objetos y variables, que o se crean tomando como base los elementos descriptores. Esto es as porque prcticamente todos los anlisis que se hacen en los sistemas de tiempo real a a tienen sentido sobre instancias concretas y sus asociaciones. Por tanto, es ms a real hacer los anlisis sobre los diagramas de objetos que sobre los diagramas a
184
de clases. Sin embargo, a veces es util asociar caracter sticas de calidad de servicio a descriptores, como ocurre en aquellas situaciones en las que todas las instancias de un servidor tienen el mismo valor para ese parmetro de a calidad de servicio. El paquete Core Resource Model dene dos conjuntos de clases relacionados. Por un lado, las clases descriptoras y, por otro las clases de instancias. Por cada clase descriptora se dene una clase de instancia entre la que se establece una relacin de uno a muchos con los papeles tipo (type) e instancia o (instance). La clase principal en el grupo de los descriptores es la clase Descriptor, que representa un concepto muy general para cualquier elemento de diseo. n La clase Resource es una especializacin de Descriptor, y representa un o recurso de un sistema de tiempo real. La clase ResourceService representa un servicio de los varios que puede ofrecer un recurso. Entre ambas clases se establece una relacin de composicin que representa esta idea. o o La clase QoScharacteristic representa la caracterizacin cuantitativa de o un servicio ofrecido por un recurso. Entre las clases ResourceService y QoScharacteristic existe una asociacin de muchos a muchos. Hay una o asociacin adicional de muchos a muchos entre las clases ResourceService o y QoScharacteristic que, segn los autores, puede usarse para simplicar u el diseo del sistema cuando un recurso ofrezca claramente un unico servicio. n El paquete CausalityModel es la base del funcionamiento dinmico del a perl. Modela la relacin causa-efecto entre los eventos ocurridos en el sistema o y las acciones que se ejecutan como respuesta. Uno de los conceptos fundamentales en el modelo es el de ocurrencia de un evento, que corresponde a una instancia de la nocin de evento de UML. De o entre los diferentes tipos de eventos, los ms interesantes para el propsito del a o
185
perl son la generacin de estmulos y la recepcin de est o o mulos. Un est mulo es una instancia de una comunicacin entre dos objetos. Cuando un objeto, o el llamante, ejecuta una accin que involucra una comunicacin con otro o o objeto, se crea una instancia de generacin de est o mulos. Cuando el est mulo llega al objeto llamado se crea una instancia de recepcin de est o mulos. Esta secuencia de comunicacin genera, a su vez, la ejecucin de un escenario, en o o el que, posiblemente, se ejecuten una secuencia de acciones como respuesta al est mulo, que puede incluir otros est mulos. En el diagrama de clases del modelo, se incluye la clase Est mulo, (Stimulus), que tiene una asociacin con la clase StimulusGeneration y con la clase o StimulusReception. Tambin aparecen las clase Scenario, e Instance. Ese ta instancia tiene un papel doble. Por un lado es el objeto en el que se ejecuta el escenario, y por otro es el receptor del est mulo. El paquete Resource Usage Model representa el lado del cliente de la relacin con un recurso. El uso de un recurso es un patrn que describe o o cmo un conjunto de clientes usa un conjunto de recursos y sus servicios. o Este patrn se corresponde de una manera muy aproximada a la idea de o caso de uso. Dependiendo del caso concreto, se distinguen dos tipo de uso: el esttico, en el que slo interesa conocer la relacin esttica entre los clientes a o o a y los servicios que usan de los recursos, y el dinmico, en el que se tienen en a cuenta tambin aspectos temporales del uso, como el orden o la temporizacin e o de las acciones. En este modelo se separa el uso de un recurso del evento que lo ha producido. Esto permite denir patrones de uso independientemente de los factores externos que han llevado a l. Para ayudar a determinar qu parte del modelo e e se va a analizar, se introduce el concepto de contexto de anlisis, que consiste a en un conjunto de usos de recursos con sus correspondientes densidades y las
186
instancias de recursos usadas. El paquete StaticUsageModel se usa para representar una vista esttica a del uso de los recursos, aunque el uso en s no sea un proceso esttico. En ese a uso, se asocia al cliente un conjunto de valores deseados de calidad de servicio por cada uno de los servicios de los recursos usados. Estos valores deseados de calidad de servicio se pueden contrastar con los valores ofrecidos para los mismos servicios por los recursos usados para dilucidar si las peticiones pueden satisfacerse. El paquete DynamicUsageModel se usa para mostrar aquellas situaciones de uso de recursos en las que el orden y el instante del uso de los servicios de los recursos es relevante para el anlisis. En ese caso, se usan instancias a de escenarios, a los que hay asociados secuencias de ejecuciones de acciones, bien concurrentes, bien secuenciales. Las acciones se pueden representar a diferentes niveles de detalle y una accin compleja se puede dividir en acciones o ms simples. a El paquete ResourceTypes ofrece una coleccin de diferentes clases de o recursos que se pueden clasicar en base a diferentes categor En base a as. su propsito se distinguen: o recursos procesadores, que representan elementos f sicos o virtuales con capacidad de clculo y ejecucin de instrucciones, a o recursos de comunicacin, cuyo propsito principal es permitir la coo o municacin entre otros recursos y o dispositivos, que representan al resto de recursos. En base a su actividad, los recursos se clasican en: activos, que son capaces de crear est mulos sin necesidad de haber recibido un est mulo externo previo, y
187
pasivos, que slo ejecutan acciones como respuesta a la recepcin de un o o est mulo desde otro recurso. En base a su proteccin, los recursos pueden ser: o protegidos, que son los recursos que cuentan con una pol tica de control de acceso para garantizar un uso exclusivo y correcto, y no protegidos, que son los que no cuentan con ninguna proteccin frente o al uso simultneo por parte de varios clientes. a Para acceder a un recurso protegido, los clientes han de efectuar en primer lugar una operacin de adquisicin del recurso, que puede ser de naturaleo o za bloqueante o no bloqueante. Cuando el cliente acaba de trabajar con el recurso, debe ejecutar una accin de liberacin, de naturaleza no bloqueante. o o El paquete ResourceManagement dene dos funciones concernientes al manejo de los recursos, el resource manager, o habilitador de recursos, que se encarga de crear y destruir recursos en funcin de las peticiones de uso o de los clientes, y el resource broker, gestor de recursos, cuya funcin es la de o gestionar el acceso a los recursos por parte de los clientes. El ultimo subpaquete del paquete de modelado general de recursos es RealizationModel. En este paquete la realizacin es denida como la habilio dad de desarrollar un recurso de un nivel superior mediante recursos de un nivel inferior, ya sea describiendo un recurso en base a otros de mayor nivel de detalle o describiendo un recurso software en base a recursos hardware. La herramienta bsica para la aplicacin de la realizacin es la construccin a o o o de sistemas por niveles. Uno de los casos particulares de esta realizacin es el o renamiento, del que sealan como ejemplo la especicacin ISO RM-ODP, n o en la que en niveles superiores se encuentran elementos software completamente independientes de la tecnolog concreta usada, que se especica en a
188
los niveles inferiores. Para ilustrar la realizacin como la construccin de un o o recurso en base a otros de niveles inferiores se seala el modelo OSI de siete n capas para el desarrollo de sistemas de comunicacin. o Para los autores del perl, esta nocin de realizacin es similar al cono o cepto de deployment en UML: hay una aplicacin de elementos de un nivel o superior, usualmente software, a elementos de un nivel inferior, posiblemente un elemento del modelo del entorno. La relacin de realizacin es similar a o o la que se establece entre un cliente y un recurso en el modelo general de recursos, siendo el elemento de mayor nivel de abstraccin el que corresponde o al cliente, y el elemento del nivel de abstraccin inferior, que realiza al otro, o el que corresponde al recurso. El punto de vista UML del Paquete de Modelado General de Recursos La forma habitual en que se introduce un nuevo concepto de modelado en una extensin UML es mediante un estereotipo. Este estereotipo se aplica o a elementos del modelo UML, de tal manera que puedan ser reconocidos por herramientas automticas de anlisis o por personal especializado. Sin a a embargo, como en el paquete de modelado general de recursos la mayor de a los conceptos que se denen son abstractos y se especializarn con conceptos a ms concretos en diferentes subperles, no hay muchos estereotipos denidos a para los conceptos de este paquete. Uno de los conceptos para el que s se dene un estereotipo en UML es la realizacin, que se dene como un tipo especial de la relacin de abstraccin, o o o y para el que se dene el estereotipo ((realize)). En el perl se denen tres posibles especializaciones de esa relacin: o ((code)). Esta relacin se usa con un elemento que contiene f o sicamente el cdigo ejecutable de otro elemento. o
189
((deploys)). Una relacin ms general que indica que las instancias del o a proveedor estn contenidas en el cliente. a ((requires)). Una especializacin de la relacin anterior e indica que el o o cliente es una especicacin genrica del m o e nimo entorno de despliegue requerido por el proveedor. El modelado general del tiempo En el paquete General Time Modeling se denen los conceptos relacionados con la denicin del tiempo y los mecanismos para manejarlos, como o relojes y temporizadores. La denicin se restringe al llamado tiempo mtrico o e y no se incluyen modelos de tiempo lgico. o El diagrama de subpaquetes de este paquete consta de cuatro elementos en los que se denen, respectivamente, los conceptos para modelar el tiempo y los valores de tiempo, los conceptos para modelar eventos en el tiempo y est mulos relacionados con el tiempo, los conceptos para modelar mecanismos temporales (relojes y temporizadores) y los conceptos para modelar servicios temporales, como los que ofrecen los sistemas operativos de tiempo real. El modelo de tiempo que se incluye en el perl es un tiempo f sico que se compone de una progresin continua y no acotada de instantes de tiempo o f sico que componen un conjunto totalmente ordenado y denso. La primera de estas dos caracter sticas implica que los eventos estn parcialmente ordenados a y la segunda que el tiempo es denso. Como, habitualmente, los mecanismos de medicin del tiempo tienen una precisin limitada, tambin se incluye el o o e concepto de tiempo discreto. La medida del tiempo se hace a travs de la cuenta del nmero de ciclos e u expirados de un reloj de referencia, estrictamente peridico. Esta medida o conlleva la discretizacin del tiempo. La cuenta de un instante de tiempo o
190
particular, o su medida, se representa por un valor especial llamado valor de tiempo. El valor se podr implementar mediante un nmero natural, real o a u cualquier otra estructura ms compleja que sea necesaria. a Otros dos conceptos que aparecen en este subpaquete son el de duracin, o que es un valor temporal que representa el tiempo transcurrido entre dos instantes, y que tambin se representa con un valor temporal, y el de intervalo, e compuesto por dos valores temporales, que representa un espacio de tiempo entre dichos instantes temporales. Los mecanismos de manejo del tiempo que se denen en el perl son elementos que miden el paso del tiempo y generan como resultado algn u tipo de evento. Dichos mecanismos son una especializacin del concepto de o recurso denido en el paquete de modelado general de recursos. Dos son los mecanismos que se denen: los temporizadores y los relojes. Los temporizadores generan instancias del evento timeout bien cuando se alcanza un determinado instante de tiempo o bien cuando ha transcurrido un intervalo de tiempo desde el instante en el que se activ el temporizador. o Los relojes generan peridicamente instancias del evento clock tick. Tambin o e pueden generar instancias del evento interrupcin del reloj. o Todos los dispositivos de medida del tiempo tienen una serie de caracter sticas, como el valor actual, su valor de referencia, el origen temporal, el valor temporal mximo, la resolucin, etc. Por otro lado, ofrecen operaciones a o como establecer el tiempo, consultar el tiempo, reiniciar los servicios, y parar y reanudar el servicio. En el modelo denido en el perl, como en UML, las instancias de eventos son instantneas. Es decir, ocurren en un instante de tiempo dado y no tienen a duracin. Para poder hacer el anlisis temporal del sistema es necesario situar o a los eventos en el tiempo, por lo que se denen los eventos temporales. A cada
191
instancia de un evento temporal se le asocia un valor temporal relativo a un reloj, que denota el momento en el que ocurre dicha instancia. Como se dene en el paquete de modelado general de recursos, la ocurrencia de una instancia de un evento puede llevar aparejada la ocurrencia de una secuencia de est mulos. Para poder localizar estos est mulos en el tiempo, en el perl se dene el estmulo temporal, que lleva asociado dos valores temporales, el de inicio y, posiblemente, el de nalizacin. o Tambin se denen las acciones temporales, a las que se les asocian sus e propias marcas temporales, por un lado, un intervalo temporal, la duracin o de la accin, y, por otro, dos valores temporales, que corresponden a los o instantes de ocurrencia de los eventos de inicio y n, respectivamente, de la accin. o Finalmente, en este paquete se dene un servicio temporal que funciona como un generador de relojes y temporizadores, pensado para facilitar el modelado de los servicios temporales ofrecidos por los sistemas operativos de tiempo real.
Punto de vista UML del modelado general del tiempo En UML se denen los conceptos de TimeExpression y TimeEvent, para representar, respectivamente, valores de tiempo que se usan en tiempo de ejecucin y ocurrencia de eventos, tambin en tiempo de ejecucin. Los o e o autores del perl razonan que para expresar valores temporales en la fase de anlisis, a veces es necesario establecer una distribucin probabil a o stica de ocurrencia de esos eventos por lo que el concepto TimeExpression de UML no es suciente para modelar el concepto de valor de tiempo que pretende establecer el perl. El mismo razonamiento se puede dar para el concepto de TimeEvent.
192
El tiempo f sico no es denido en UML, sino slo la medicin de ste. o o e Para especicar valores de tiempo se proponen dos maneras: un estereotipo, ((RTtime)), aplicable a los valores que representen valores de tiempo, y, en segundo lugar, usar instancias del tipo RTtimeValue, denido tambin e en el perl. Este tipo se basa en etiquetas de UML (tags) y describe diferentes formas de expresar valores temporales en base a distintas unidades y categor Los intervalos de tiempo, al ser formas especiales de valores as. temporales, tambin pueden especicarse de manera similar. e Los mecanismos de manejo de tiempo se denen mediante diversos estereotipos, como ((RTtimingMechanism)), ((RTclock)) o ((RTtimer)). Sus diferentes caracter sticas se establecen mediante valores etiquetados, como RTstability, RTresolution, etc. Para las operaciones sobre esos mecanismos tambin e se denen los correspondientes estereotipos. Asimismo, para las acciones temporales tambin se aade otro estereotie n po, RTaction, cuyas caracter sticas temporales se especican mediante valores etiquetados, bien indicando su duracin, bien indicando los valores temporao les de los eventos de inicio y n. Para modelar los eventos temporales, se dene el estereotipo ((RTstimulus)), que se aplica a elementos UML que generen est mulos, como est mulos en s o ciertas acciones: llamadas a funciones, env de seales, etc. Dos est o n mulos concretos son los generados por los relojes y los temporizadores, caracterizados por los estereotipos ((RTclkInterrup)) y ((RTclktimeout)). Modelado general de concurrencia El paquete General Concurrency Modeling es una extensin del paquete o de causalidad del modelado general de recursos. Se amplia el concepto de escenario como secuencia de ejecucin de acciones como respuesta al env o o
193
y recepcin de est o mulos. Cada objeto del sistema susceptible de iniciar una secuencia de ejecuciones se denomina una unidad de concurrencia. Cuando se crea una unidad de concurrencia, sta inicia un escenario coe rrespondiente a su mtodo principal. Este escenario puede incluir generacin e o de est mulos, uso de servicios, etc. La ejecucin de los escenarios de las unio dades de concurrencia se ejecutan en paralelo. A las unidades de concurrencia se les asocia colas donde almacenar temporalmente los est mulos que les llegan cuando aqullas no estn disponibles e a por estar procesando un est mulo previo. Desde el punto de vista del servidor, las peticiones se pueden atender de manera inmediata o postergada. Desde el punto de vista del receptor, las peticiones pueden ser s ncronas o as ncronas. Punto de vista UML del modelado general de concurrencia Una entidad que se ejecute concurrentemente se describe con el estereotipo ((CRconcurrent)). Los estereotipos ((CRasynch)), ((CRsynch)), ((CRimmediate)) y ((CRdeferred)) sirven para indicar cmo se maneja un mensaje. o Modelado de planicabilidad En el paquete Schedulability Modeling se describe un conjunto m nimo de anotaciones sobre conceptos de planicabilidad, con el propsito de que o sea ampliable de manera sencilla para aquellos anlisis que requieran un a mayor grado de detalle o ms informacin para poder realizar el anlisis de a o a planicabilidad. Los autores hacen notar que el anlisis de planicabilidad es inherentea mente basado en instancias, por lo que no tiene sentido analizar diagramas con clases y asociaciones, sino diagramas de objetos con enlaces, en la que se sepa de manera concreta la cardinalidad de cada uno de los objetos.
194
El paquete consta de dos diagramas de clases en los que se denen, respectivamente, las clases correspondientes a los conceptos implicados en el modelado de sistemas que se quieran analizar y, por otro lado, elementos de la infraestructura necesaria para planicar procesos concurrentes, t picamente ofrecidos por el sistema operativo. Los nuevos elementos de modelado son especializaciones de conceptos denidos en otros paquetes del perl a los que se les han aadido atributos n para indicar las propiedades que son necesarias para realizar el algoritmo de planicabilidad. Por ejemplo, la clase SAction es una especializacin de la o clase TimedAction del paquete TimedEvents con una serie de atributos nuevos para especicar las propiedades que se necesitan saber sobre una accin o concreta en el anlisis de planicabilidad como, por ejemplo, la prioridad, el a tiempo de clculo en el peor caso, el tiempo de retraso, el tiempo de bloqueo, a etc. Otro ejemplo es la clase SResource, que es una especializacin de la clase o ProtectedReource del paquete ResourceTypes donde se aaden atributos para n especicar la capacidad, el tiempo de adquisicin y liberacin, etc. o o
Punto de vista UML del modelado de la planicabilidad La traduccin a UML de los conceptos denidos para este subperl tamo bin se hace deniendo nuevos estereotipos, ((SAaction)), ((SAengine)), ((SAowns)), e ((SAresource)), ((SAschedRes)) y ((SAscheduler)) entre otros. La mayor incora poran valores etiquetados para especicar los valores necesarios para llevar a cabo el anlisis de planicabilidad. a Los autores del perl incluyen gu y diagramas de ejemplo sobre cmo as o usar los conceptos denidos en este paquete. En los diagramas que se usan de ejemplo para modelar sistemas de tiempo real, los elementos se etiquetan con los estereotipos denidos anteriormente y los valores etiquetados necesarios
195
para indicar los factores involucrados en el anlisis de planicabilidad, como a la periodicidad, el plazo temporal o el tiempo de respuesta en el peor caso.
Modelado del rendimiento Como en el caso del modelado de la planicabilidad, el paquete Performance Modeling proporciona un conjunto m nimo de anotaciones que permitan realizar un anlisis de planicabilidad m a nimo, con el propsito de que o sea fcilmente extensible en aquellos casos en los que se necesite un anlia a sis ms detallado. Los conceptos incluidos en este paquete pretenden cubrir a los requisitos de rendimiento que se le exigen al sistema, las caracter sticas de calidad de servicio asociadas con los elementos del modelo, los parmea tros de ejecucin que permitan un anlisis automtico del rendimiento y la o a a presentacin de los resultados obtenidos a partir del anlisis. o a En el diagrama de clases denido en este paquete la clase central es Performance Context, que se reere a uno o varios escenarios que describan diferentes situaciones dinmicas de varios recursos. Esta clase es una espea cializacin de AnalysisContext. Los escenarios de este paquete se denen en o la clase PScenario, una especializacin de Scenario e incluyen nuevos atribuo tos para especicar los datos necesarios para el anlisis de rendimiento. Un a escenario, como en el caso general, se compone de varios pasos ms simples, a denidos en la clase PStep. Las actividades que se producen en el escenario se deben a las peticiones de uso por parte de los elementos del modelo, indicadas por instancias de la clase Workload, una especializacin de UsageDemand. Estas cargas de o trabajo pueden ser bien abiertas o cerradas, y cada una de ellas cuenta con sus propios atributos para especicar sus propiedades caracter sticas. Tambin se dene una nueva clase para los recursos, PResource, especialie
196
zacin de Resource, de cuyas instancias se puede especicar su utilizacin, su o o pol tica de planicacin y su caudal de salida. Se denen dos tipos concretos o de recursos, los activos, o que producen procesamiento, PProcessingResource, y los pasivos, PPassiveResource. Punto de vista UML del modelado del rendimiento Debido a su naturaleza netamente dinmica, los escenarios juegan un a papel central en el estudio del rendimiento. En UML, los escenarios se especican fundamentalmente mediante de diagramas de colaboracin o de o actividad. Tanto si se usan diagramas de colaboracin como de actividad, se deo nen diferentes estereotipos para los conceptos denidos en este paquete: ((PAcontext)), ((PAstep)), ((PAhost)) y ((PAresource)).
3.2.
Mecanismos de expresin del tiempo en las mquio a nas de estados de UML
Como se menciona en la seccin 4.2 del cap o tulo 1, los unicos 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 especica mediante una expresin de tiempo. Las expresiones de tiempo o no tienen un formato bien denido y se deja total libertad para su especicacin. El tiempo expresado puede ser absoluto, una cantidad concreta de o tiempo, o relativo, una cantidad de tiempo desde un determinado evento, que habitualmente es el instante de entrada a un estado. Esta denicin del tiempo es tremendamente imprecisa. No se hace meno cin a ningn reloj de referencia, ni a la posibilidad de mltiples relojes, o u u ni se especica cules son las unidades de tiempo, o si se puede modelar la a
197
precisin de los relojes, o algunas otras de sus caracter o sticas. Burns en [28] y Diethers et al en [36], modelan las mquinas de estados a de UML mediante autmatas con tiempo. En estas propuestas los autmatas o o con tiempo disponen de un conjunto de relojes asociados; cada reloj se puede reiniciar a 0, avanza montonamente y se puede consultar su valor para o establecer condiciones que se basen en ellos. En ambos trabajos se aprovechan estas propiedades para hacer anlisis de planicabilidad. Para modelar el a tiempo de ejecucin de las tareas llevadas a cabo en un estado, se reinicia a o 0 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 o del estado se dene como que el valor del reloj llegue al tiempo referenciado en el invariante del estado.
3.3.
Caracter sticas del entorno de tiempo
Alvarez et al en [14], describen el tiempo de ejecucin de una accin de o o SDL asociando una etiqueta al icono de la accin, en vez de hacerlo de manera o impl cita, como los autores mencionados en la seccin anterior. Con esa etio queta, se puede analizar la estructura del sistema especicado para construir una red de tareas sobre la que hacer el anlisis de planicabilidad. En ese a caso hay que especicarlo como un comentario adicional porque no se tiene acceso al metamodelo de SDL y no se pueden agregar nuevas caracter sticas a los elementos de SDL. Para incluir el manejo del tiempo necesario para el anlisis de planicabia lidad que queremos hacer, nosotros vamos a seguir una estrategia similar a la seguida en [14] para SDL, aunque adaptndolo en funcin de las diferencias a o entre SDL y las mquinas de estados de UML. Una primera diferencia funa damental es que, en nuestro caso, en el que hemos denido un metamodelo
198
de las acciones y de las mquinas de estados, se puede aadir en ese metaa n modelo la informacin sobre el tiempo de ejecucin y no hace falta hacer uso o o de comentarios adicionales. Otra parte de la informacin necesaria para poder efectuar el anlisis de o a planicabilidad es la relativa a las caracter sticas temporales del entorno de las mquinas de estados. En ese entorno se incluyen, entre otras cosas, los a mecanismos de manipulacin del tiempo. Como se ha explicado en la seccin o o 4.1 del cap tulo 1, SDL incluye una denicin precisa de los mecanismos que o proporciona para el manejo del tiempo. En un sistema monoprocesador hay un reloj central que avanza montonamente y cuyo valor puede ser consulo tado con la operacin now(), que devuelve un valor de un tipo previamente o denido, TIME, y los temporizadores, que son objetos que se pueden denir en un proceso, arrancar con la operacin SET y reiniciar con la operacin o o RESET. Los temporizadores generan un evento cuando llegan al nal de su cuenta sin haber sido reiniciados. Para incluir el entorno temporal necesario en las mquinas de estados, a vamos a usar mecanismos temporales similares a los denidos en el UML Prole for Schedulability, Performance, and Time Specication [56]. Por tanto, vamos a denir los paquetes y los elementos necesarios usando el esquema que se ha seguido para denir las acciones y las mquinas de a estados: por cada paquete se denir un subpaquete con la sintaxis abstracta, a otro con el dominio semntico y otro con la aplicacin semntica. a o a En el paquete de recursos temporales generales vamos a incluir los relojes y los temporizadores. Los relojes ofrecen una operacin now() que permite o consultar el valor actual. Los temporizadores ofrecen operaciones para iniciarlos, set, y para pararlos, reset. Si un temporizador llega al nal del tiempo establecido tras ser iniciado y sin haber sido parado, genera una instancia de
199
un evento temporal (guras 3.32, 3.33 y 3.34).

RecursosTemporales::AbstractSyntax
Watch
reference 1 *
Timer 1
generator
TimeEvent
Figura 3.32: Sintaxis abstracta de los recursos temporales.
RecursosTemporales::SemanticDomain
WatchInstance value: TimeValue 1 + now() : TimeValue referencia *
TimerInstance remaining : TimeValue + set(t : TimeValue) + reset() + isActive() : Bool + remaining() : TimeValue 1 generator TimeEventInstance + start: TimeValue + end : TimeValue received : TimeValue + consumed: TimeValue *
Figura 3.33: Dominio semntico de los recursos temporales. a Otro elemento que se debe introducir para tener la informacin necesaria o para el anlisis de planicabilidad es el tiempo de clculo de una accin, el a a o conocido como WCET (Worst Case Execution Time). Este dato se usa en mtodos de anlisis como el del clculo del nivel de ocupacin del procesador e a a o o el del clculo del tiempo de respuesta. Para aadir esa informacin a las a n o
200
RecursosTemporales::SemanticMapping
Watch
1 of instance
WatchInstance
Timer
1 of instance
TimerInstance
TimeEvent
1 of instance
TimeEventInstance
Figura 3.34: Aplicacin semntica de los recursos temporales. o a acciones vamos a denir dos nuevas clases a partir de las clases denidas en el cap tulo 2, 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. o o
timedActions.AbstractSyntax
Action
TimedAction * wcet Time
Figura 3.35: Sintaxis abstracta de las acciones con tiempo.
201
timedActions.AbstractSyntax
Execution
TimedExecution * wcet TimeValue
Figura 3.36: Dominio semntico de las acciones con tiempo. a
Respecto al modelo de ejecucin, vamos a considerar que todos los obo jetos cuyo funcionamiento viene denido por una mquina de estados se a implementan con objetos activos, y que cada uno cuenta con su hebra de ejecucin propia. Esta opcin coincide con el concepto de concurrency unit o o que se dene en el cap tulo del modelado de la concurrencia del UML Prole for Schedulability, Performance, and Time Specication, [56]. El modelo de paralelismo implicar que los objetos activos se ejecutarn a a concurrentemente y que su ejecucin es interrumpible. Un objeto podr ser o a 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. La cuestin de las prioridades o se tratar a continuacin. a o En lo que concierne al manejo y postergacin de los eventos recibidos por o un objeto activo, se supondr que cada objeto cuenta con una cola propia a en la que se almacenan temporalmente las instancias de los eventos que el
202
objeto ha recibido pero no ha procesado an. u
3.4.
Problemas de tiempo real
En [14] se estudian en profundidad los aspectos relacionados con el diseo n de sistemas de tiempo real cuando se emplea SDL y sus mecanismos estndar a de manejo de tiempo. En la seccin anterior se ha propuesto una ampliacin o o de las mquinas de estados de UML con la idea de reproducir el entorno de a SDL, con, por ejemplo, relojes y temporizadores, con sus respectivas operaciones. Es necesario, por tanto, considerar tambin en este caso si los problee mas detectados en SDL aparecen asimismo cuando se usan las mquinas de a estados de UML para disear un sistema de tiempo real. n Expresin de restricciones temporales o Una funcin usual para la que se utilizan los temporizadores es la de o marcar una secuencia peridica, para, por ejemplo, activar una actividad o peridicamente, como puede ser un sensor. Otra funcin es la de marcar un o o retraso, o la consumicin de un per o odo de tiempo, que, por ejemplo, indique el nal del plazo de ejecucin seguro asignado a un proceso. o En ambos casos, cuando el plazo de activacin acaba, el temporizador o genera un evento temporal que se env a la mquina adecuada. a a Ilustremos esta idea con un ejemplo. Supongamos una mquina de estados a simple que cuenta con un unico estado, gura 3.37, en el que se admiten dos seales, una corresponde a la expiracin de un temporizador, t, que se activa n o 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. Con este o diseo se pretende conseguir una activacin peridica del temporizador. n o o
203
/ t.set(PER) e
t.exp / t.set(PER)
Figura 3.37: Mquina de estados con activacin peridica de un temporizador. a o o Como se ha mencionado en la seccin 3.3, los eventos que llegan a una o mquina de estados se almacenan en una cola, con una pol a tica del primero en entrar, primero en salir. Si la mquina de estados est ocupada respondiendo a a a la recepcin de otro evento cuando recibe una instancia del evento de o expiracin del temporizador, el procesamiento del evento de la expiracin o o del temporizador se ver retrasado. Cuando la mquina de estados por n a a atienda ese evento y llame a la funcin para consultar el valor del tiempo o actual con la operacin now() para volver a activar el temporizador, el valor o devuelto por la funcin ser el instante en el que se ha empezado a atender el o a evento, no el instante en el que se ha recibido. Eso signica que el retraso con el que el temporizador se activa la siguiente vez es mayor que el del per odo deseado. Esa situacin tambin se puede dar en otras circunstancias. Si la cola de o e eventos no est vac sino que contiene alguna instancia de la otra seal, a a, n en cuyo caso el tiempo que transcurre entre que se recibe la seal y sta se n e procesa es an mayor. Ocurre incluso que ese tiempo no est acotado porque u a no lo est el nmero de instancias de eventos que puede haber en la cola. a u El otro motivo es que, con el modelo de concurrencia considerado, la mquina de estados puede ser interrumpida por otra mquina de estados a a
204
de mayor prioridad y esta interrupcin puede ocurrir entre el instante de o la recepcin del evento y el inicio de su procesamiento, por lo que el valor o devuelto por la funcin now() no coincidir con el de la recepcin de la seal, o a o n aunque la mquina atienda inmediatamente el evento. a
Recursos compartidos El uso de recursos compartidos es una situacin habitual, y a veces inevio table, en un diseo concurrente. Por la naturaleza de UML, las variables no n pueden ser directamente compartidas sino que tienen que estar encapsuladas en un objeto desde donde puede ser accesible a travs de diversos mecanise mos. En la gura 3.38 se muestra un sistema en el que hay tres mquinas a de estados. El objeto al que corresponde la mquina de estados de la parte a inferior de la gura contiene la variable x, a cuyo valor acceden los objetos a los que corresponden las mquinas de estados de la parte superior de la a gura. En este caso el acceso a dicha variable se hace de manera ordenada a travs de los dos eventos a los que responde la mquina de estados del objeto e a que contiene la variable. Aunque las variables globales sean el caso ms evidente de recurso coma partido, hay otras situaciones donde tambin se da esta situacin. Los dise o positivos f sicos son recursos compartidos a los que se accede desde distintos componentes del sistema. En los sistemas de tiempo real es muy habitual la interaccin con estos dispositivos, por lo que su modelado dentro del sistema o es fundamental. Adems, la denicin de un mecanismo de acceso a disposia o tivos f sicos tiene una serie de benecios: permite simular el sistema completo en la fase de diseo, lo que ayuda a tener una idea de la respuesta temporal n del sistema, posibilita la realizacin de anlisis de planicabilidad en la fase o a de diseo, incluyendo de esa manera los requisitos temporales de los disposin
205
e / sum(1)
e2 / mult(2)
sum(n)/ x=x+n
mult(n)/ x=x*n
Figura 3.38: Variable compartida por dos mquinas de estados. a
tivos f sicos y ofrece un mecanismo comn de interaccin con los dispositivos u o f sicos, lo que facilita la fase de implementacin porque permite denir un o esquema general de generacin de cdigo para acceso a los dispositivos f o o sicos. En la respuesta a un evento externo suelen estar involucrados varios objetos distintos. Entre estos objetos se crea una cadena de eventos, de tal manera que el objeto que recibe el evento externo inicial realiza una accin o y genera otro evento, que ser recibido por otro objeto. Sucesivamente, se a generarn ms eventos hasta que la respuesta al evento externo se complete. a a Puede ocurrir que un objeto est involucrado en la respuesta a ms de un e a evento externo. En ese caso podemos considerar ese objeto como un recurso compartido entre varias secuencias de eventos.
206
Inversin de prioridades o La inversin de prioridad es la situacin que se produce cuando, en un o o sistema concurrente, un proceso de una determinada prioridad tiene que esperar porque hay otro proceso de menor prioridad que se est ejecutando y no a puede interrumpirlo, aunque el modelo de concurrencia del sistema incluya la posibilidad de interrumpir los procesos en cualquier momento. Cuando los procesos no comparten recursos se puede evitar la inversin o de prioridad, pero si hay recursos compartidos no. Supongamos un sistema en el que varios objetos acceden a recursos proporcionados por un objeto servidor. El acceso a estos recursos implica el env de un evento para la o peticin del servicio y la espera de otro evento de respuesta. Durante el o tiempo entre ambos env el proceso cliente est esperando a que el servidor os, a acabe sus clculos. Si hay un cliente con una prioridad mayor que la del a servidor y est esperando la respuesta a un evento de peticin de un servicio, a o otro proceso que tenga una prioridad menor que la del cliente, pero mayor que la del servidor puede activarse por la llegada de otro evento distinto e interrumpir al proceso servidor. En ese caso, el proceso cliente, con una prioridad mayor que la del tercer proceso, sufre una inversin de prioridad o porque es postergado por un proceso de menor prioridad sin tener posibilidad de interrumpirlo. El mismo ejemplo sirve para ilustrar otra situacin de inversin de prioo o ridad. Si el proceso servidor es accedido por mltiples clientes con distintas u prioridades, es posible que, cuando un cliente con alta prioridad requiera un servicio por parte del servidor, se encuentre con que ste est atendiene a do la peticin de otro cliente con menor prioridad. Este es otro escenario de o inversin de prioridad. El tiempo que el proceso de mayor prioridad est poso a tergado puede ser mayor porque la cola de eventos pendientes del proceso
207
servidor puede no estar vac Si la cola de eventos sigue una pol a. tica de primero en entrar, primero en salir, se atendern primero las peticiones de los a procesos de menor prioridad. El principal inconveniente en ambos casos no es la presencia de la inversin o de prioridad, que es inevitable cuando se comparten recursos, sino que el tiempo en el que el proceso de mayor prioridad est bloqueado no es acotado. a Esta circunstancia no permite hacer los anlisis de planicabilidad habituales a en los sistemas de tiempo real.
3.5.
Extensin del entorno temporal de las mquinas o a de estados
Marcas temporales en los eventos En la seccin 3.4 se han presentado varias situaciones en la que una mquio a na de estados no puede saber el instante de tiempo en el que se ha recibido una instancia de un evento, provocando funcionamientos incorrectos desde el punto de vista temporal. Para posibilitar que una mquina de estados acceda a a informacin temporal correcta sobre los eventos que procesa hemos denido o la clase TimedEventInstance, mostrada en la gura 3.33, que representa las instancias de eventos con tiempo, en la que se incluyen cuatro atributos que representan instantes temporales de especial inters para dicha instancia del e evento: start. Instante temporal en el que se ha generado la instancia del evento. end. Instante temporal en el que se ha terminado el procesamiento del evento. Deniremos el n del procesamiento como el instante en el que la mquina de estados transita al estado destino de la transicin a o disparada por el evento y est preparada para responder a otro evento. a
208
received. Instante temporal en el que el evento es colocado en la cola de eventos de la mquina de estados. a consumed. Instante temporal en el que la mquina de estados empieza a el procesamiento del evento. Asignacin de prioridades o En la denicin de UML no se hace mencin a la asignacin de priorio o o dades a objetos, mquinas de estados o transiciones. La unica mencin a las a o prioridades se hace cuando, en un estado compuesto, varios estados anidados responden al mismo evento, la transicin correspondiente al estado ms o a interno es la que se ejecuta antes que las otras. En el UML Prole for Schedulability, Performance, and Time Specication [56], s se hace referencia a la asignacin de prioridades. En su cap o tulo 6, Schedulability Modeling, se trata el tema de la asignacin de prioridades. o Las acciones modeladas por la clase SAction tienen un atributo que indica la prioridad de la accin. o La asignacin de prioridades directamente a las acciones no reeja, desde o nuestro punto de vista, la losof que debe seguir la construccin de un a o sistema reactivo a eventos basado en mquinas de estados concurrentes. La a asignacin directa de prioridades a acciones tiene sentido cuando en el sistema o todas las acciones se estn ejecutando concurrentemente. Con la prioridad de a cada accin el planicador sabe a qu accin tiene que asignarle el procesador o e o y si una accin puede interrumpir a otra. o Sin embargo, cuando el sistema se basa en mquinas de estados, los oba jetos estn esperando a que ocurra un evento al que ellos respondan. Si se a produce un evento que activa una transicin de un objeto cuando el procesao dor est ocupado ejecutando las acciones de respuesta a otro evento en otra a
209
transicin de otra mquina de estados, el planicador no puede saber si se o a puede interrumpir a esa otra mquina de estados o no, porque la transicin a o no tiene una prioridad que comparar con la prioridad de la accin que se o est ejecutando. Se puede argumentar que la prioridad de la transicin es a o igual que la transicin de la accin que ejecuta, pero tampoco es una soluo o cin clara, porque en una transicin puede haber tres acciones involucradas: o o la accin de salida del estado, la asociada a la transicin y la de entrada al o o nuevo estado.
En vez de asignar las prioridades a las acciones, nosotros las asignamos a las transiciones, como se propone en [14]. Las prioridades de los objetos, que sern normalmente los elementos que se implementen sobre una entidad plaa nicable por el sistema, como un proceso, variarn en funcin de la transicin a o o que estn ejecutando. La planicacin de los objetos se har en funcin de e o a o la prioridad que tenga cada uno en ese instante. Esta posibilidad de cambiar de prioridad permite que un objeto que toma parte en la respuesta a varios eventos atienda cada uno a la prioridad adecuada.
Todas las transiciones involucradas en la respuesta a un evento deben compartir la misma prioridad para que el procesamiento del evento no se vea interrumpido por la llegada de otro evento de menor prioridad (en ese caso estar amos frente a una situacin de inversin de prioridades). Las transio o ciones compartidas, es decir, aqullas que son parte de la respuesta a varios e eventos externos tendrn como prioridad la mayor de entre las prioridades de a los eventos a los que responde. La actualizacin de la prioridad de los objetos o en base a la prioridad de la transicin que estn ejecutando est explicada o a a en profundidad en [14].
210
Modelado de recursos compartidos En esta seccin proponemos una estrategia de diseo para el acceso a reo n cursos compartidos. Los recursos estarn encapsulados en un tipo especial de a objetos, que eviten la inversin de prioridad y posibiliten una implementacin o o eciente. Estos objetos han de cumplir las siguientes propiedades: Son servidores pasivos, no empiezan ninguna secuencia de acciones por su propia iniciativa. El mtodo de comunicacin que ofrece es el de llamadas remotas a e o procedimientos. Su funcionamiento no implica estados, por lo que no tendrn asociados a mquinas de estados. a El tiempo de ejecucin de sus procedimientos debe estar acotado, para o que la inversin de prioridad sea limitada y, por tanto, aceptable para o el anlisis de planicabilidad. a En la seccin 3.1.6, The Resource Types Package, del UML Prole for o Schedulability, Performance, and Time Specication [56], donde se clasican los recursos en funcin de diferentes caracter o sticas, se proponen objetos activos, que inician secuencias de est mulos, y pasivos, que slo responden a o est mulos, y, por otro lado, respecto a la proteccin, se distinguen recursos o no protegidos, que no proporcionan mecanismos de proteccin frente a aco cesos simultneos, y protegidos, que ofrecen servicios exclusivos. El atributo a accessControlPolicy permite establecer el tipo de pol tica de control de acceso al objeto. En el cap tulo 6, Schedulability Modeling, del UML Prole for
211
Schedulability, Performance, and Time Specication [56], los recursos compartidos, modelados por la clase SResource, tienen un atributo que indica el techo de prioridad. Con esas propuestas, podemos concluir que los recursos compartidos deber modelarse con un objeto pasivo y protegido, para establecer la pol an tica de control de acceso y que ofreciera la posibilidad de asignar un techo de prioridad.
212
CAP ITULO
Metodolog de dise o de sistemas de tiempo a n real orientada a objetos
1.
Introduccin o
En este cap tulo presentamos una metodolog de desarrollo de sistemas a
empotrados de tiempo real para el diseo de sistemas monoprocesadores. n Esta metodolog es una adaptacin del trabajo presentado en [10] y a o [15]. En esos trabajos se presenta una metodolog cuyas caracter a sticas ms a sobresalientes son el uso sistemtico de lenguajes grcos de modelado para la a a especicacin y diseo del sistema en sus diferentes etapas, la integracin del o n o anlisis de planicabilidad en el entorno del uso de estos lenguajes grcos y a a el modelo de interaccin con los dispositivos f o sicos. La metodolog incluye a entre sus fases la simulacin y validacin del sistema. Para estas fases es o o necesario que el lenguaje en el que describe el sistema tenga una semntica a precisa para generar una implementacin ejecutable del sistema. o Para el anlisis de planicabilidad se propone Rate-Monotonic Analysis a (RMA) [47, 30, 77], que proporciona una coleccin de mtodos cuantitativos o e para analizar y predecir el funcionamiento temporal de los sistemas de tiempo 213
214
1. Introduccin o
real. Estos anlisis pueden ayudar a organizar los procesos y los recursos en a el diseo para hacer posible predecir el funcionamiento del sistema nal. En n este sentido, RMA ayuda a incorporar el anlisis de tiempo real [67, 55, 78] a y salvar el hueco entre el modelo de objetos y el modelo de tareas. Las tareas que se usan en el anlisis de planicabilidad se obtienen a partir de la a especicacin del funcionamiento dinmico del sistema. o a Tanto en [10] como en [15] se usa UML en las primeras fases, especicacin y diseo del sistema, y SDL en la parte nal, para el diseo estructural o n n detallado, el diseo de procesos, la implementacin de cdigo y la simulan o o cin y validacin del sistema. Una de las razones principales de la eleccin o o o de SDL en [10] y [15] es que, gracias a su semntica, formal y claramente a establecida, existen herramientas automticas como Tau, de Telelogic, que a incluye entre sus funciones la simulacin y validacin del sistema especicado o o y la generacin de cdigo. Por otro lado, hemos desarrollado herramientas o o que permiten aplicar RMA para realizar el anlisis de planicabilidad de un a sistema especicado en SDL, mediante su transformacin en grafos de tareas. o En este cap tulo se describe una modicacin de la metodolog propuesta o a en [10] y [15] en la que se sustituye SDL por UML en las etapas nales del diseo. La razn de esta sustitucin es la tremenda popularidad que ha n o o alcanzado UML para la construccin de sistemas de todo tipo, incluidos los o 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 a an llevar a cabo las ultimas fases de la metodolog sobre diagramas UML: u a generacin de cdigo, simulacin, validacin y anlisis de planicabilidad. o o o o a Por este motivo, en los cap tulos anteriores de este trabajo se ha desarrollado una semntica precisa para las acciones y para las mquinas de estados a a
Cap tulo 4. Metodolog de dise o de . . . a n
215
de UML. Esta semntica es el primer paso para eliminar la ambigedad a u presente en UML y y construir herramientas automticas que proporcionen a las funciones mencionadas en el prrafo anterior. En este trabajo no se ha a incluido el desarrollo de estas herramientas.
1.1.
Trabajo relacionado
Se han llevado a cabo algunos trabajos para intentar integrar este tipo de anlisis en un modelo SDL. Por ejemplo, ObjectGeode [50] incluye un analia zador de rendimiento en su simulador que hace uso de algunas directivas para extender SDL para indicar prioridades de procesos o retrasos temporales. En [71] se incluye una semntica del plazo ms inmediato para SDL, de manera a a que permite una traduccin desde una especicacin en SDL a una red de o o tareas analizable. Sin embargo, no integran este anlisis en el resto del ciclo a de desarrollo, ni tienen en cuenta la interaccin con el hardware o anomal o as de tiempo real como la inversin de prioridades. Otra l o nea de trabajo en este contexto es la de suplementar SDL con modelos de carga, como se describe en [82], que usa teor de colas para calcular los tiempos en las colas a de los trabajos y los mensajes y las cargas de trabajo media y mximas de a los procesadores. En [42] se presenta una estrategia nueva para la prediccin o temprana de rendimiento basada en sistemas especicados en MSC en el contexto de SDL. Pensamos que estos trabajos pueden ser complementarios y utiles en las primeras fases del diseo, pero que para los sistemas de tiempo n real es necesario hacer un anlisis nal de planicabilidad y, para conseguirlo, a es necesario proporcionar un modelo de ejecucin planicable para UML. En o [103] y [106] se puede ver cmo aplicar la teor de planicabilidad en ROOM. o a Aunque estos trabajos han sido muy utiles para la propuesta que ahora pre sentamos, ROOM no es una tcnica de descripcin formal y no puede usarse e o
216
1. Introduccin o
para incluir una fase de validacin automtica directamente desde el diseo. o a n Pensamos que la validacin es un tema importante para el diseo de los siso n temas de tiempo real. En [105] se presenta una propuesta encaminada a la s ntesis automtica de implementaciones a partir de los modelos de diseo a n orientados a objetos de tiempo real. Este es un trabajo muy interesante e incluye el tema del tiempo real y la respuesta en un plazo de tiempo en el proceso de diseo. [104] completa el trabajo previo y muestra cmo se puede n o integrar el anlisis de planicabilidad con el diseo orientado a objetos. a n En [6] se estudia una metodolog para construir sistemas planicados a restringiendo el funcionamiento de los procesos para garantizar dos tipos de restricciones: restricciones de planicabilidad y restricciones sobre los algoritmos de planicacin tales como prioridades para procesos y posibilidad o de interrupcin. Aunque la metodolog se ilustra sobre procesos peridicos, o a o puede aplicarse a sistemas arbitrarios. Otra contribucin de este trabajo es la o descomposicin de los requisitos de planicacin en clases de requisitos que o o pueden ser expresados como restricciones de seguridad. UML-MAST [40] es una metodolog y un conjunto de tcnicas de anlisis a e a para especicar, disear y estudiar sistemas de tiempo real haciendo uso de n diversos diagramas de UML en herramientas automticas, como diagramas a de classes y objetos, de secuencias y de actividad. La metodolog inclua ye cinco vistas del sistema, entre las que se encuentra la Mast RT View, que incluye informacin sobre las caracter o sticas necesarias para realizar los anlisis de tiempo real, como el funcionamiento temporal, las restricciones a de rendimiento, etc. Esta informacin se pasa como entrada a diversas heo rramientas que analizan diferentes aspectos temporales del sistema, como anlisis de planicabilidad, simulaciones o anlisis de utilizacin. Los autoa a o res declaran que los nuevos componentes incluidos en UML para especicar
217
esta nueva vista disponen de un metamodelo formal. Este metamodelo se dene se una manera similar a como se denen las clases del UML Prole for Schedulability, Performance, and Time Specication, discutido en la seccin o 3.1 del cap tulo 3. La semntica esttica se dene mediante diagramas de a a clases, pero la semntica dinmica se hace en lenguaje natural. a a Con respecto al trabajo relacionado con la traduccin del modelo de objeo tos a modelo de procesos, UML/RT [111] propone una vista dinmica basada a en mquinas de estados para cada objeto pasivo del modelo de objetos. Oca topus, [63], propone el modelo de diseo como una extensin del modelo de n o objetos, aunque puede necesitar una descomposicin ulterior en la fase de imo plementacin. Con el objetivo de disear la concurrencia, Octopus propone o n el concepto de hebra de interaccin entre objetos que representa el conjunto o de objetos que pueden tomar parte en un evento. Octopus usa mquinas de a estados para describir el funcionamiento en trminos de cambios de estado e causados por los eventos. Sin embargo, no los usan formalmente. Usa class outlines para grabar los detalles del diseo. Ese es el punto de arranque de la n fase de implementacin. Octopus combina dos conceptos, objetos y procesos o del sistema operativo, para disear la concurrencia. La traduccin directa de n o objetos a procesos del sistema operativo no es fcil y pensamos que el paso a intermedio que proponemos la facilita. El paso del modelo de anlisis al modelo de diseo en ROPES [39] puede a n hacerse usando tcnicas elaborativas o traductoras. Las tcnicas traductoras e e proponen denir 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 o ms detallado que el que proponemos en nuestra metodolog El modelo a a. elaborativo es ms tradicional. El modelo de anlisis es realizado con detalles a a
218
2. La metodolog a
de diseo y puede puede ser mantenido como una entidad distinta del modelo n de anlisis. Esta l a nea est ms cercana a nuestra propuesta. a a HRT-HOOD [29] traduce el modelo de objetos a Ada. Para cada objeto se generan dos paquetes: el primero simplemente contiene una coleccin de o tipos de datos y variables que denen los atributos de tiempo real del objeto; el segundo contiene el cdigo del objeto. En este sentido esta metodolog o a 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 n el modelo de diseo un formalismo que incluya una fase de validacin para n o detectar situaciones indeseables en los diseos concurrentes como la inanicin, n o bloqueos, etc.
2.
La metodolog a
Nuestra propuesta est conceptualmente basada en alternativas que apaa
recen en otras metodolog (en particular SOMT y Octopus). Sin embargo, as proporcionamos soluciones parciales a algunos de los problemas presentes en las metodolog mencionadas anteriormente, y tambin en otras metodoas e log de desarrollo orientadas a objetos. De hecho, nos ocupamos del salto as 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. e Cubrimos ese hueco mediante dos estrategias ortogonales. As proporciona, mos 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 n modelo de objetos tiene que ser traducida a uno o ms procesos (descritos a mediante mquinas de estados) se resumen en la seccin 2.2. Esta forma de a o
219
traducir el modelo de objetos al modelo de procesos es un aspecto importante de nuestra propuesta, y proporciona una estrategia clara para convertir objetos en procesos, dando la posibilidad de analizar las propiedades de tiempo real. Sin embargo, hemos aprendido de nuestra experiencia en el desarrollo de sistemas empotrados de tiempo real otras dos lecciones. En primer lugar, el modelo de objetos puede ser renado un poco ms de lo que recomiendan a otras metodolog y en algunas ocasiones este diseo orientado a objetos as, n ms detallado es altamente recomendable. En segundo lugar, se puede consea guir un mejor provecho de este modelo ms renado si obtenemos una buena a correspondencia entre los elementos del modelo de objetos y los elementos del modelo de procesos. As pensamos que esta traduccin detallada entre , o ambos modelos presenta algunas novedades con respecto a las sugerencias hechas en otras propuestas. El enfoque principal de esta metodolog es sobre el sistema de desarrollo a usando anlisis y diseo orientados a objetos, pero proporcionando anlisis de a n a tiempo real basado en las mquinas de estados de UML. La metodolog proa a puesta est bsicamente dividida en cuatro fases Anlisis, Diseo, Validacin a a a n o e Implementacin. En cada fase se tienen en cuenta los aspectos funcionales o y no funcionales en dos vistas del sistema separadas, pero complementarias. Esta distincin nos permite capturar las caracter o sticas de tiempo real y las peculiaridades de los dispositivos f sicos del sistema, con relativa independencia de los requisitos funcionales (modelos de objetos y dinmicos), pero a recordando en qu nivel han surgido los requisitos espec e cos. La gura 4.1 muestra las diferentes fases de la metodolog Como se ha a. mencionado ya, esta gura muestra cmo cada fase se divide verticalmente o en dos vistas, dando las perspectivas funcionales y no funcionales. Obsrvese e que las expresiones usadas para denotar cada fase son diferentes dependiendo
220
2. La metodolog a
ASPECTOS FUNCIONALES MODELO OBJETOS
DIAGRAMAS CLASES
ASPECTOS NO FUNCTIONALES MODELO TIEMPO REAL

REQUIS. REQUISITOS TEMPS. EVENTOS
MODELO DINMICO
Diagrama de secuencias
HARDWARE
ANLISIS Y ESPECIF. REQUISITOS TIEMPO REAL CABILIDAD PLANIFIRENDIM. EVAL. ASIGNACIN PRIORIDAD E INTERACCIN CON DISPOSITIVOS FSICOS
Anlisis req.
ANLISIS
Interf. Funcional
Lista eventos
Diag. secs.
SISTEMA
Anlisis Sistema
Escenarios Casos de uso
Tabla de eventos externos
DIAG. CLASES/OBJ UML
RMA y UML (TEMPS., PRIOR, ...)
DISEO
Arquitec. lgica Diseo de objetos UML Diseo de objetos refinado UML Modelos simulacin Modelos validacin
Interaccin objetos Refinam. escenarios Interaccin procesos
SISTEMA
Diagrama Objectos Hw
Cadena secs. event. Eventos internos Tabla eventos/accs Est. tiempo ejec. Anlisis prel. TR Rediseo
SIMUL. Y VALIDAC. FUNCIONAL
Diag. secs.
OBJETO
Especificacin de procesos de control Hw.
RMA
IMPLEMEN TACIN
UML
Generacin cdigo Prototipado Pruebas
Validacin y verificacin de restric. temporales
Figura 4.1: Fases de la metodolog a de sobre qu aspecto nos queremos centrar en cada vista. La primera fase e se denomina Anlisis desde una perspectiva funcional, mientras que usamos a el trmino Especicacin de requisitos de tiempo real para la vista no fune o cional. Cada una de estas dos vistas est a su vez subdividida en otras dos a vistas (llamadas modelos), distinguiendo as el modelo de objetos del mo delo dinmico en la perspectiva funcional y el modelo de tiempo real de las a restricciones f sicas en la perspectiva no funcional. En la fase de anlisis se identican y se analizan el dominio del problema a y los requisitos del usuario del sistema. Bsicamente, durante esta fase estaa blecemos un primer modelo de objetos y los casos de usos preliminares del sistema. Usaremos dos notaciones grcas para apoyar ambas actividades: a los diagramas de clases de UML para capturar la descripcin orientada a o objetos, y diagramas de secuencias para describir el modelo dinmico. a Durante la fase de diseo los aspectos funcionales del sistema se estudian n a dos niveles: sistema y objetos. El diseo se realiza bsicamente mediante n a
UML
Verif. casos uso Trazas simulacin
Simulacin Hw.
DIAG. CLASES/OBJ UML
HARDWARE
221
diagramas de clases y objetos de UML. El diseo del sistema corresponde a n un diseo de alto nivel, que se rena cuanto sea necesario hasta llegar a un n diseo de objetos detallado. n En la fase de simulacin, validacin y evaluacin del rendimiento se cono o o trastan los resultados de las fases de anlisis y diseo. La simulacin y la a n o validacin del sistema se hacen usando la especicacin del sistema antes o o de su implementacin. Estas tcnicas nos permiten detectar posibles erroo e res generales de diseo tales como bloqueos, consumo impl n cito de seales, n etc. Adems, se pueden estudiar algunos escenarios particulares del sistema a mediante la vericacin del funcionamiento mediante diagramas de secueno cia. Estos diagramas de secuencia pueden describir situaciones requeridas, o prohibidas, que pueden vericarse automticamente por las herramientas a existentes. En este sentido, es posible usar los diagramas de secuencia renados en la fase previa para vericar parte de la funcionalidad del sistema. Finalmente, en la fase de implementacin obtenemos el cdigo correspono o diente a la parte del sistema espec ca de la aplicacin. Este cdigo espec o o co de la aplicacin se sostiene t o picamente sobre servicios genricos proporcioe nados por un nivel subyacente (sistema operativo o el sistema de tiempo de ejecucin). Este nivel debe proporcionar ciertas caracter o sticas para permitir nuestro modelo de ejecucin de tiempo real analizable. Al menos, debe proo porcionar planicacin de procesos completamente interrumpible basada en o prioridades jas y alguna forma de herencia de prioridad. Adems, el modelo a de dispositivos f sicos deber adaptarse al proporcionado (si lo hay). a En las prximas secciones vamos a describir en detalle los nuevos aspeco tos de la metodolog que presentamos, resaltando las fases donde se hace a alguna contribucin relevante. Para mantener la relacin temporal entre aso o pectos funcionales y no funcionales, presentaremos cada fase dando las vistas
222
2. La metodolog a
funcionales y no funcionales al mismo tiempo.
2.1.
Anlisis y especicacin de requisitos de tiempo a o real
La parte funcional del anlisis est dedicada a la obtencin de los requisia a o tos de usuario. En su parte funcional, se usan los diagramas de casos de uso y los diagramas de actividad para identicar la dinmica de uso del sistema. a Con esta informacin, se crean los diagramas de clases que identican los o actores involucrados en las acciones descritas anteriormente, desde el punto de vista del usuario. En esta fase tambin tiene una gran importancia la descripcin de los e o aspectos no funcionales. En este nivel, el sistema se ve como una caja negra que responde a est mulos del exterior, por lo que toda la informacin que se o recopile ser relativa a eventos producidos fuera de los l a mites del entorno. Se tiene que tener en cuenta que el sistema habr de responder simultneamente a a a eventos externos cuya frecuencia puede ser distinta, o no estar denida y dar el resultado deseado dentro de los l mites de tiempo impuestos. As esta , fase se centrar en la deteccin de los requisitos temporales de los eventos a o externos (espec camente eventos de entrada) producidos por la interaccin o con el entorno, en el que incluyen los dispositivos f sicos y otros subsistemas. El resultado de esta actividad es una tabla con los eventos externos, donde por cada evento se recopila la siguiente informacin: identicacin del evento, o o clases involucradas en la respuesta del sistema y requisitos temporales (sobre per odo, plazo de respuesta, jitter, . . . ).
223
2.2.
Dise o e interaccin con dispositivos f n o sicos y asignacin de prioridades o
En esta fase, una diferencia importante de nuestra propuesta respecto a otras metodolog (por ejemplo SOMT) es la posibilidad de reducir el as hueco existente entre el diseo estructural (en diagramas de clases y objetos n en UML) y el de procesos (mquinas de estados en UML). Esto es posible a gracias a las actividades que se llevan a cabo durante esta fase (interaccin o con los dispositivos f sicos y asignacin de prioridades, vase seccin 2.2) o e o para capturar los aspectos no funcionales. Nivel de objetos (Sistema) En el aspecto funcional, en la fase de diseo se construye la estructura n del sistema partiendo de los diagramas obtenidos en la fase de anlisis. a A partir de los diagramas de clases del anlisis se generarn nuevos diagraa a mas de clases que reejen la arquitectura lgica del sistema. Estos diagramas o de clases se instanciarn en diagramas de objetos para reejar la estructura a concreta del sistema. Nivel de objetos (Dise o) n Los diagramas de clases y objetos se usan hasta en los ultimos pasos de esta fase. As durante este nivel del diseo, los diagramas de clases y objetos , n se van detallando hasta llegar a un diseo de objetos muy renado. n Como en otras metodolog los objetos se traducen a procesos siguiendo as, criterios claros tales como los siguientes: los objetos activos se describirn con a una mquina de estados propia, al menos, para que tenga su propia capacidad a de ejecucin. En algunas situaciones tiene que considerarse la posibilidad de o incluir en un objeto capacidad para procesamiento mltiple. Una de estas u
224
2. La metodolog a
situaciones se da cuando el objeto est involucrado en el procesamiento de a varios eventos simultneos que no pueden cumplir sus requisitos temporales. a 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 a 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 establecidas en [15, seccin 2.3.2]. Finalmente, tambin tratamos o e con las clases que modelan el funcionamiento de la parte f sica, y proponemos la distincin entre procesos activos (manejadores de dispositivos f o sicos) y procesos pasivos (que modelan directamente los dispositivos f sicos), como se estudi en [15, seccin 2.3.3]. o o A la vez que el diseo de los aspectos funcionales del sistema tambin se n e tienen en cuenta las caracter sticas no funcionales. En esta fase, Asignacin o de prioridades e interaccin con los dispositivos f o sicos, an se mantienen en u esta actividad dos niveles: el nivel de sistema y el nivel de objetos. Interaccin con los dispositivos f o sicos y asignacin de prioridades o (Nivel de sistema) Respecto a los temas no funcionales, el diseo tiene que capturar cmo n o los dispositivos f sicos interaccionan con el sistema. En este sentido, cada componente f sico tiene que modelarse como un objeto; por tanto, hay que denir una clase para representar el componente f sico correspondiente. Las actividades que se han de desarrollar en esta fase son similares a las propuestas en otras metodolog como, por ejemplo, en Octopus. Sin embargo, las as gu para agrupar las clases que modelan los dispositivos f as sicos marcan una diferencia respecto a la estrategia propuesta por Octopus. De hecho, como se mencion en [15, seccin 2.3.3], en vez de agrupar todas estas clases en o o
225
un unico subsistema, proponemos distribuir las clases de dispositivos f sicos entre los diferentes subsistemas que han sido generados durante la fase de anlisis. Esto promueve un diseo ms natural y razonable, porque las clases a n a que representan cada componente f sico estn denidos all donde se necesia tan. Bsicamente, la notacin que proponemos a este nivel son los diagramas a o de clases y objetos de UML.
Interaccin con los dispositivos f o sicos y asignacin de prioridades o (Nivel de objetos) El nivel de objetos de esta fase est dedicado a disear la interaccin con a n o los dispositivos f sicos, como se trat en [15, seccin 2.3.3], distinguiendo o o para cada componente f sico un objeto pasivo y un objeto controlador. El primero modela el acceso al componente f sico y el segundo implementa el protocolo demandado por los requisitos del sistema. Esta forma de disear n los componentes f sicos ayuda a decidir qu se va a disear como software y e n qu como hardware, y a simular el sistema en la fase de diseo. Los procesos e n f sicos desaparecen en la fase de implementacin. o 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 jando las prioridades de las transiciones (vase [15, seccin 2.3.1]). Por e o otro lado, se asignan los techos de prioridad de los procesos pasivos usando mtodos como el de techo de prioridad inmediato. Finalmente, se construye e una tabla, que muestra la correspondencia entre cada evento y la correspondiente secuencia de transiciones. Adems, cada transicin tiene asociada a o cierta informacin, como el tiempo de retraso debido a los bloqueos (si lo o hay), si es atmica o no, el tiempo de ejecucin en el peor caso y su prioridad o o relativa.
226
2. La metodolog a
2.3.
Evaluacin del rendimiento o
En esta fase se usan los modelos de simulacin para analizar cuantitatio vamente medidas tales como el throughput y el tiempo de respuesta. Ser a deseable que este anlisis se llevara a cabo con herramientas comerciales ya a disponibles, aunque stas no ofrecen la generacin del cdigo completo de un e o o sistema a partir de una especicacin UML. o En lo que respecta a la interaccin con los dispositivos f o sicos, stos tiee nen que ser simulados mediante elementos especicados en UML. Cuando el sistema est implementado se acceder al dispositivo f e a sico mediante funciones C integradas en el cdigo generado a partir del diseo. Sin embargo, o n durante esta fase tenemos que completar la especicacin con clases y obo jetos UML que modelen el funcionamiento de los dispositivos f sicos. Esto nos permitir la simulacin y validacin del sistema completo, teniendo tama o o bin en consideracin la interaccin con los dispositivos f e o o sicos. Otro aspecto relevante es el que corresponde a los requisitos de tiempo real. Despus del e diseo, es necesario un anlisis de tiempo real preliminar, que se basar en el n a a anlisis propuesto en [15, seccin 2.4]. Usando este anlisis es posible saber a o a el funcionamiento temporal del sistema antes de la fase de implementacin, o y entonces hacer los cambios necesarios para mejorar el tiempo de respuesta del sistema. En este sentido, la fase de evaluacin del rendimiento tambin o e incluye un paso de rediseo para renar el sistema especicado en UML. n Basndonos en nuestra experiencia, este paso propone una serie de heur a sticos para cambiar el diseo y mejorar los tiempos de respuesta de los eventos n del sistema. Este paso ser especialmente util cuando el sistema no cumpla a los plazos de tiempo. Los cambios en el diseo afectarn a los parmetros de n a a la ecuacin del tiempo de respuesta (vase [15, seccin 2.4]) como el bloqueo o e o y la interferencia. Proponemos un conjunto de heur sticos que nos permiten:
227
Redisear el sistema si no cumple los plazos de tiempo. n Tener en cuenta los requisitos de tiempo real desde los primeros pasos del diseo. n Los heur sticos 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 eveno tos de menor prioridad tratados por el mismo proceso. Eliminacin de transiciones intermedias, eliminando transiciones entre o objetos que no aadan ninguna informacin, sino que slo sirvan como n o o paso de eventos. En [15] y [117] se estudian en profundidad las tcnicas de rediseo aqu coe n mentadas.
3.
Un caso real: el diseo de un telfono inalmbrin e a co

El Eole 400 es un telfono inalmbrico de la clase CT0 de Alcatel, que e a
admite mltiples auriculares, con un contestador automtico de estado slido u a o integrado en la base. Est basado en otros dos productos anteriores CT0, el a 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 ja (la base) y de uno o ms auriculares. El software instalado en el telfono a e proporciona las siguientes prestaciones principales: Intercomunicacin entre la base y los auriculares. o
228
3. Un caso real: el dise o de un telfono inalmbrico n e a
Rellamada automtica al ultimo nmero marcado. a u Activacin del altavoz durante la comunicacin. o o Encriptacin de la comunicacin base-auricular. o o Marcacin por pulsos o multifrecuencia. o Tres melod programables en el auricular y opcin de desconectar el as o timbre. Contestador automtico con modos de funcionamiento simple y de graa bacin y acceso remoto autenticado con cdigo de seguridad. o o
3.1.
Descripcin de la parte f o sica
La base del EOLE 400 est compuesta de varios circuitos electrnicos, a o 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 m o nimo de una instruccin es 0,95 o s. Las puertos de E/S conectan los diodos luminosos y el teclado al microcontrolador. Una memoria EEPROM de chip unico, 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.
229
Un mdulo contestador, conocido como ATISAM, basado en el chip o MSP58C80 de Texas Instruments. Para iniciar una llamada, el usuario ha de pulsar la tecla line del auricular, con lo que se env una peticin de l a o nea a la base. El circuito de radio detecta el mensaje e informa al sistema. Si la base est en disposicin de a o procesarlo, es decir, si no est ya en el estado de comunicacin, se establece a o un enlace de radio entre la base y el auricular y se activa el gancho de la l nea telefnica. Para volver al estado de inactividad, el usuario puede pulsar o 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 o mediante la difusin de un mensaje a travs del circuito de la radio. Si un o e auricular contesta la peticin, pulsando la tecla line, se establece una ino tercomunicacin entre ese auricular y la base, gracias al micrfono integrado o o 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 o al estado inactivo. Aunque ste es un sistema distribuido entre la base y los e auriculares, slo vamos a modelar la parte ja del sistema, la de la base. Es o decir, estamos tratando un sistema monoprocesador.
3.2.
Aplicacin de la metodolog o a
En esta seccin trataremos los modelos principales de nuestra metodoo log aplicndolos al sistema telefnico desarrollado. a, a o La primera parte de nuestra metodolog es la fase de anlisis. Los asa a pectos 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, especicacin tcnica y entreo e vistas con los ingenieros involucrados en el proyecto. A nivel de sistema se
230
Teclado
Diodos
Linea Telefonica Sistema
COMBO
EEPROM
Circuito conversacional
Figura 4.2: Arquitectura de objetos del sistema. crea un primer diagrama de clases para mostrar las relaciones entre los objetos identicados en el estudio de los documentos de requisitos. Este diagrama se muestra en la gura 4.21 . Tras esto, se hacen diagramas de secuencias para estudiar el funcionamiento dinmico de los objetos en la posibles situacioa nes diferentes. En la gura 4.3 se muestra el diagrama de secuencia para la deteccin de una seal de llamada entrante desde la l o n nea telefnica. Los o aspectos no funcionales cubiertos en esta fase son los relativos a los eventos externos del sistema. Los eventos externos se muestran en la tabla 4.1 con sus nombres, requisitos temporales y los objetos a los que involucran, como se coment en la seccin 2.1. o o La fase de diseo, interaccin con el hardware y asignacin de prioridades n o o se divide en los aspectos funcionales y los asuntos de tiempo real y dispositivos f sicos. A nivel de sistema hacemos una estructura lgica de las clases para o disear la arquitectura del sistema que se rena para conseguir una denicin n o
La herramienta de modelado utilizada no permite el uso de caracteres acentuados, de ah la falta de tildes en sta y en otras guras. e
1
231
linea telefonica indicacion llamada entrante
sistema
circuito conversacional
COMBO
diodos
auricular
activacion timbre mensaje "llamada entrante" mensaje "llamada entrante" mensaje mensaje ACK encender diodo "line" ACK
Figura 4.3: Diagrama de secuencias del escenario de llamada entrante.
EstParametros Manejador configuracion ProgramarAltavoz
ParametrosMarcacion
Conf. externa
Clave configuracion Intefaz externa EnvTecla ProgramarMelodia
Melodia Llamada externa

Encender Manejador llamadas NuevaMelodia
Altavoz
Configuracion
Mensaje enviado
Tonos
Digitos Circuito conversacional
Mensajes
Mensaje recibido Codigo seguridad Sistema radio
Comunicacion
Marcaciones
Manejador marcacion
ProgramarModoMarcacion
Figura 4.4: Diseo de objetos. n
232
Evento externo Llamada entrante
Objetos involucrados Sistema, Diodos, COMBO, Circuito conversacional, L nea telefnica o Sistema, Diodos, COMBO, L nea telefnica o Sistema, Diodos, Teclado, COMBO
Llamada saliente
Intercomunicacin o
Cambio de volumen
Sistema, Teclado, EEPROM, Circuito conversational Sistema, Teclado, EEPROM, Circuito conversational
Change melody
Requisitos de tiempo Buscar l nea y seal no presenn te Periodo: 0.122 ms. Plazo:Detectar seal en la l n nea. Periodo: - Plazo:700 ms Buscar en canales y no hay portadora. Periodo: 0.122 ms. Plazo:Portadora detectada. Periodo: - . Plazo: 1100 ms Analizar teclado y no hay tecla pulsada. Periodo: 7.82 ms. Plazo:Tecla Intercom pulsada. Periodo: - . Plazo:1200 ms Analizar teclado y no hay tecla pulsada. Periodo: 7.82 ms. Plazo:Tecla Volumen pulsada. Periodo: - . Plazo:2000 ms Analizar teclado y no hay tecla pulsada. Periodo: 7.82 ms. Plazo:Tecla Intercom pulsada. Periodo: - . Plazo:2000 ms
Cuadro 4.1: Tabla de eventos externos.

EnviarMen
233
ManejCombo UltCanal:TCanInicCom FinComunicacion EnvMensaje(M:TMessBase) NoPortadora() LeerCabe() LeerDatos(m:TMensMovil) MenAMovil CMBCMBD MenDeMovil Canal Id:TCan COMBO EnvMenExt(c:TMensBase) EnvMenCmp(c:TMensBase) EnvReg0() EnvRegSCF() EnvRegMode() EnvRegGain() EnvRegRefPLL() LeerPortadora() LeerCabecera() LeerDatos(m:TMensBase) SubirSquelch() BajarSquelch() RestitutirSquelch()
Mensaje MenMovil:TMenMovil MevBase:TMenBase PrtCMB
Protocolo Mensaje : TMenMovil movilOr : IdMovil MendeCOMBO(M:TMenMovil) SenalPerdida() LIGBM() LlamEnt() SILEN() FIN_LIG() INTBM() FinLlamEnt() CODSEC() ENDINTB()
RecMen
Figura 4.5: Diseo renado del sistema de radio. n
ms precisa del sistema. Estos modelos se muestran en las guras 4.4 y 4.5. a En el nivel de sistema de los aspectos no funcionales hacemos un estudio ms preciso de los objetos f a sicos como se coment en la seccin 2.2. Este o o estudio puede producir cambios en el diseo de objetos renado. Como se n coment en [15, secciones 2.3.2 y 2.3.3] y en 2.2, los dispositivos f o sicos se modelan mediante dos objetos: un objeto pasivo que modela el dispositivo f sico y que permite a los dems procesos acceder a sus recursos a travs de a e llamadas remotas a procedimientos, y otro objeto activo, correspondiente al controlador, con un objeto controlador que es el que controla la comunicacin o entre el dispositivo f sico y el resto del sistema. En nuestro sistema, el objeto COMBO modela el componente f sico del sistema de radio y el objeto DCombo para el controlador. En la fase de anlisis de planicabilidad, y en funcin de a o los rboles de tareas y los tiempos de respuesta de las acciones, se ve que hay a eventos externos cuyo tiempo de respuesta es superior a su plazo mximo de a respuesta.
234
Concretamente, esta situacin se produce porque el objeto DCombo mao neja eventos paralelos, ya que puede haber env y recepcin simultneos de o o a mensajes entre la base y los auriculares, y esta situacin introduce un tiempo o de bloqueo que impide que el sistema sea planicable. Este tiempo de bloqueo no se produce, por tanto, por un objeto externo que ejecute una accin o 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 o o a ellos de los mensajes en un sentido. El inconveniente de esta solucin es que o 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 u compartido por ambos objetos, hay que denir un nuevo objeto pasivo que simplemente acte como contenedor de los recursos a compartir. Este objeto u seguir las reglas comentadas anteriormente para este tipo de procesos, slo a o ser accesible mediante llamadas remotas a procedimientos y su prioridad a vendr dada por el techo de prioridad de los objetos que acceden a l. En la a e gura 4.6 se muestran los dos objetos nuevos, DComboEnt y DComboSal, y 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 guras 4.7 y 4.8 se muestran las o o respectivas mquinas de estados de los objetos DComboEnt y DComboSal. a Se podr pensar en una segunda alternativa, aprovechando las posibilidaa des de concurrencia intraobjetos que proporcionan las mquinas de estado de a
235
DComboSal
Protocolo
CmbRecCmp tab_can : ArrCan can_tr : Canal CanRc : Canal
COMBO
DComboEnt
Figura 4.6: Especicacin detallada del protocolo de radio o

LeerCab EsperarDato ModoActivo
NoPort/CambiarCanal() LeerDato(regent)/VerifCodSeg(regent,codseg,ok)
ok = false ok = true/idmenok = VerifCan(regent.can) idmenok = false
idmenok = false/PrgChnTR;MendeCOMBO(regent)
Figura 4.7: Mquinas de estados del objeto DComboEnt. a UML con los estados concurrentes. Los eventos que han provocado el tiempo de bloqueo excesivo se podr procesar en diferentes regiones de un mismo an estado concurrente. La principal ventaja de esta solucin es que evita la como plicacin del diseo, ya que no se aaden nuevos objetos que no responden a o n n 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 o
236
ModoActivo
EnviarMensaje(M)/BuscarCanalLibre();EspCabe
mensajeExtendido = true/ CrearMenExt(M, regext);EnvMensExt(regext)
mensajeExtendido = false/ CrearMenCmp(M, regcmp);EnvMensCmp(regcmp)
Figura 4.8: Mquinas de estados del objetoDComboSal. a implica el acceso a los mismos recursos, hace falta establecer un control de acceso a los recursos para que no se modiquen concurrentemente de forma descontrolada. El otro inconveniente radica en si realmente las regiones de un estado concurrente pueden atender concurrentemente distintos eventos. En [88, seccin 2.12.4.7] se indica que: o es posible denir la semntica de las mquinas de estados de tal a a manera que la restriccin de ejecucin hasta la nalizacin se o o o aplique concurrentemente a las regiones ortogonales de un estado compuesto en vez de a la mquina de estados en su totalidad. a Esto permitir relajar las restricciones sobre la serializacin de a o eventos. Sin embargo, dicha semntica es muy sutil y dif de a cil implementar. Por tanto, la semntica dinmica denida en este a a documento se basa en la premisa de que un paso de ejecucin haso ta la nalizacin se aplica a toda la mquina de estados e incluye o a los pasos concurrentes llevados a cabo por regiones concurrentes de la conguracin de estados activos. o Tampoco la semntica denida en el cap a tulo 3 permite la respuesta con-
237
currente a eventos. Una de las tareas ms importantes que hay que desarrollar en los aspectos a no funcionales de la fase de diseo es el estudio de los eventos internos y la n realizacin de la tabla de eventos/transiciones explicada en la seccin 2.2. o o Distinguimos diferentes modos de operacin y el anlisis se lleva a cabo en o a el contexto de cada uno de los modos de operacin. En la tabla 4.2 podemos o ver la tabla de eventos/transiciones que contiene todos los eventos de nuestra aplicacin simplicada. Los nmeros relacionados con el tiempo son los o u especicados en los requisitos del sistema y dependen del microprocesador en el que se instale el software. Estos tiempos fueron suministrados por la empresa Alcatel. 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. La tabla 4.4 contiene toda la informacin necesaria para aplicar las tcnio e cas de tiempo explicadas en [15, seccin 2.4]. o Como se coment en la seccin 1, la fase de simulacin y validacin no o o o o est an disponible para UML. Este ejemplo se desarroll tambin con SDL a u o e y en esa versin s se realizaron las fases de simulacin y vericacin pao o o ra solventar los errores del sistema desarrollado. Los modelos de validacin o ayudaron a completar el sistema detectando los fallos de diseo tales con mo bloqueos y consumo impl cito de seales usando algoritmos de bit state. n Tambin vericamos nuestro sistema desarrollando casos de uso en MSC para e comparar con los resultados de la simulacin del sistema. Estas acciones se o han comentado en la seccin 2. En los aspectos no funcionales, obtuvimos un o anlisis de tiempo real preliminar usando las tablas de eventos/transiciones a con los diferentes modos operativos de la fase de diseo. La tabla 4.5 muesn
238
Nombre del Evento lectura de teclado interno interno interno interno interno externo peridico, 1000 ms o peridico, 0.122 ms o peridico, 700 ms o Hard, 500 ms Hard, 0.01 ms Soft, 700 ms peridico, 500 ms o peridico, 500 ms o peridico, 0.122 ms o Soft, 100 ms Soft, 150 ms Hard, 0.122 ms
Tipo interno
Patrn de Ocurrencia o peridico, 7.82 ms o
Requisitos de tiempo Hard, 7.82 ms
encender diodo apagar diodo escanear canales
enviar mensaje al auricular comprobar l nea llamada entrante
cambiar cdigo de seguridad o externo peridico, 1100 ms o Soft, 1100 ms
externo
peridico, 600 ms o
Soft, 400 ms
llamada saliente
Cuadro 4.2: Tabla de eventos/transiciones.

externo peridico, 1200 ms o Soft, 1200 ms
intercomunicacin o
Respuesta/transicin o leer tecla leer tecla leer tecla leer tecla vericar tecla esc on activar registro esc puerto esc o desabilitar registro esc puerto preparar escaneo establecer nivel de squelch cambiar canal buscar canal libre esc cabecera esc datos comprobar l nea comprobar l nea (buscar canal libre esc. cabe esc. datos leer cabe leer datos vericar canal vericar cdigo de seguridad) o (esc. on activar registro esc. puerto) programacin de registros del altavoz o nuevo cdigo (modicar valor (grabar o EEPROM (esc cabe esc datos))) leer cabe leer datos pedir l nea buscar canal libre esc. cabe esc. datos leer cabe leer datos (programar l nea (esc. on activar registro esc. puerto)) preparar intercomunicacin ((buscar canal o libre esc. cabe esc. datos leer cabe leer datos vericar canal vericar cdigo o seguridad) (esc. on activar registro esc. puerto))
239
Modo inactivo
Nombre del evento lectura de teclado encender diodo apagar diodo escanear canales comprobar l nea lectura de teclado encender diodo apagar diodo llamada entrante lectura de teclado encender diodo apagar diodo llamada saliente comprobar l nea
llamada entrante
llamada saliente
Cuadro 4.3: Eventos para los modos operativos inactivo, llamada entrante y llamada saliente.
240
Tiempo de bloqueo leer tecla n/d vericar tecla n/d esc. o 0.083 ms inhabilitar registro n/d esc. on n/d habilitar registro n/d esc. puerto n/d preparar escaneo n/d establecer nivel de squelch n/d cambiar canal n/d buscar canal libre 230 ms escribir cabecera n/d escribir datos n/d leer datos n/d escribir cabecera n/d vericar canal n/d vericar cdigo seguridad n/d o nuevo cdigo o n/d modicar valor n/d grabar EEPROM n/d comprobar l nea n/d programar registros altavoz n/d pedir l nea n/d programar l nea n/d preparar intercomunicacin n/d o
Id. Accin o
Atmica Tiempo Usado Prioridad o S S S S S S S S N N N N N S S N N N N S S N N N S 0.010 ms 0.008 ms 0.001 ms 0.017 ms 0.001 ms 0.017 ms 0.055 ms 0.001 ms 0.065 ms 0.050 ms 1.770 ms 0.018 ms 0.028 ms 230 ms 280 ms 0.133 ms 0.400 ms 0.004 ms 0.001 ms 120 ms 0.002 ms 0.040 ms 0.247 ms 0.040 ms 0.001 ms 50 50 40 40 39 39 39 55 55 55 38 38 38 37 37 37 37 33 33 33 60 32 30 30 29
Cuadro 4.4: Tabla de transiciones.
241
Modo inactivo
Nombre del evento Plazo Tiempo de respuesta lectura de teclado 7.82 ms 5.85 ms encender diodo 100 ms 76.37 ms apagar diodo 150 ms 77.59 ms escanear canales 0.122 ms 0.121 ms comprobar l nea 0.01ms 0.005 ms
Modo de llamada entrante

Nombre del evento Plazo lectura de teclado 7.82 ms encender diodo 100 ms apagar diodo 150 ms llamada entrante 700 ms Tiempo de respuesta 0.053 ms 0.19 ms 0.20 ms 515.92 ms
Modo de llamada saliente

Nombre del evento Plazo Tiempo de respuesta encender diodo 100 ms 0.156 ms apagar diodo 150 ms 0.166 ms comprobar l nea 0.01ms 0.005 ms llamada saliente 1100 ms 1067.37 ms Cuadro 4.5: Tiempo de respuesta para las acciones de los modos operativos. tra el anlisis preliminar de tiempo real para los modos operativos inactivo, a llamada entrante y llamada saliente.
242
CAP ITULO
Conclusiones y trabajo futuro
El contenido de este trabajo est incluido en el marco de las investigacioa nes realizadas por parte de los miembros del grupo de Ingenier del Software a del Departamento de Lenguajes y Ciencias de la Computacin, centrados en o el uso y adaptacin de tcnicas avanzadas de Ingenier del Software en el o e a desarrollo de sistemas empotrados de tiempo real. El objetivo fundamental de la metodolog denida en el cap a tulo 4 es proporcionar a los desarrolladores de sistemas empotrados de tiempo real herramientas de especicacin y diseo que incluyan las metodolog genricas o n as e ms modernas, como el empleo de la programacin orientada a objetos, el uso a o sistemtico de lenguajes grcos de especicacin y diseo y la utilizacin de a a o n o herramientas automticas para ayudar a establecer la correccin del sistema a o mediante la simulacin y vericacin del modelo y la generacin automtica o o o a de cdigo. o La metodolog presta especial atencin a aspectos de desarrollo caraca o ter sticos de los sistemas empotrados de tiempo real y que no se contemplan en otras metodolog as: El tratamiento de la parte f sica del sistema. En cada fase de la meto243
244 dolog se detallan las acciones que se han de llevar a cabo para tener a en cuenta sus caracter sticas. Los aspectos no funcionales, con un mayor nfasis en los requisitos teme porales. Los aspectos temporales se tienen en cuenta no slo permitieno do y facilitando su especicacin, sino tambin incluyendo herramientas o e para su anlisis. a Aspectos de concurrencia y prioridades, incluyendo el estudio de la asignacin de prioridades a los eventos y los mecanismos necesarios o para evitar situaciones incorrectas como la inversin de prioridades. o Concretamente, se ha integrado el anlisis de planicabilidad basado a en prioridades jas al ciclo de desarrollo. Como se explica en el cap tulo 4, respecto a la metodolog original, proa puesta en [10] y [15], se ha sustituido SDL por las mquinas de estados de a UML que, al carecer de una semntica formal, no permiten aprovechar las a ventajas derivadas del uso de herramientas automticas. Por este motivo, en a los cap tulos 2 y 3 se han denido semnticas formales para las acciones y a las mquinas de estados de UML. La estrategia seguida para la denicin de a o estas semnticas es la del metamodelado, un mtodo de modelado que, para a e denir los elementos del lenguaje de modelado, hace uso de los elementos del propio lenguaje (clases, objetos, asociaciones, etc.), pero a otro nivel de abstraccin. El metamodelado es la opcin escogida por la OMG para denir o o su semntica de UML. La diferencia fundamental entre nuestra semntica a a para las acciones y las mquinas de estados y la denida por la OMG es que a la nuestra incluye la semntica dinmica, o dominio semntico, como uno a a a de los tres aspectos bsicos de la semntica. Los otros dos aspectos son la a a sintaxis esttica, o sintaxis abstracta, y la aplicacin semntica entre la sina o a
Cap tulo 5. Conclusiones y trabajo futuro
245
taxis esttica y la dinmica. En la denicin de la semntica de la OMG, la a a o a semntica dinmica no est denida de manera rigurosa, sino que se expresa a a a en lenguaje natural el funcionamiento esperado de los elementos del lenguaje de modelado. Como el propsito fundamental de la denicin de la semntica para las o o a mquinas de estados y las acciones es su uso en una metodolog de desarrollo a a de sistemas de tiempo real, se han ampliado ambos conceptos, tanto las acciones como las mquinas de estados, deniendo clases especializadas, que a incluyen los conceptos y la informacin necesaria para que esos elementos o puedan ser usados en los anlisis de planicabilidad. a En el contexto de las mquinas de estados se han denido nuevas clases a para poder especicar y tratar correctamente las cuestiones relativas al tiempo. Tambin se han ampliado las clases relativas a los eventos con conceptos e temporales. Son muchos los puntos an abiertos en este trabajo. Respecto a la meu todolog propuesta en el cap a tulo 4. Aunque se ha revelado ecaz en su aplicacin industrial en un ejemplo real, como se explica en la seccin 3 de o o ese cap tulo, es necesario su uso en un conjunto amplio de sistemas, con caracter sticas variadas, que conrmen su adecuacin o que desvele aspectos que o no estn bien cubiertos o que sean mejorables en funcin de las propiedades e o del sistema a desarrollar. La semntica desarrollada en el cap a tulo 2 para las acciones tampoco se puede considerar un trabajo nalizado. Esta semntica puede ser un buen a punto de partida para la denicin de un conjunto de acciones ms como a pleto, cuya semntica detallada y nal se base en este enfoque. El conjunto a de acciones denido aqu puede tomarse como un conjunto bsico sobre el a que denir otras acciones, ms concretas o especializadas, de manera que la a
246 semntica del conjunto de acciones total del sistema se haga de una manea ra jerrquica. Tambin pueden denirse nuevos conjuntos de acciones cuya a e semntica se dena con un esquema anlogo al que presentamos aqu de a a , manera que cada conjunto de acciones se aplique a un determinado tipo de sistemas con caracter sticas particulares. La semntica desarrollada en el cap a tulo 3 para las mquinas de estados a tambin tiene elementos susceptibles de mejorar. Como se explica en la sece cin 2 de dicho cap o tulo, algunos elementos de las mquinas de estados, como a las actividades, los estados de historia o la lista de eventos postergados no han sido incluidos en el modelo de las mquinas de estados considerados para a evitar presentar un modelo demasiado complejo. Obviamente, si se pretende que esta semntica sea de utilidad en el tratamiento de sistemas reales coma plejos, ha de denirse la semntica para todos los elementos de las mquinas a a de estados. Otra cuestin pendiente, y de gran importancia, es el estudio de la relacin o o entre la semntica de los elementos que hemos denido en este trabajo y a la semntica de los dems diagramas denidos en UML. La cuestin de la a a o coherencia entre distintos diagramas UML que cubren diferentes aspectos de los mismos elementos de un sistema ha sido apuntada por numerosos autores. Nuestra semntica toma como base la semntica denida para MML [27], que a a incluye diagramas estticos como los diagramas de clases y los de objetos, a razn por la que la coherencia entre la semntica propuesta en este trabajo o a y la de esos diagramas est bien establecida. Sin embargo, no hay ni en a este trabajo, ni en [27] una semntica para, por ejemplo, los diagramas de a actividad, que deben usarse en la simulacin y validacin de escenarios. o o Hay otras facetas de sincronizacin que deben establecerse con ms clario a dad, como la relacin entre los aspectos estticos y los dinmicos del sistema. o a a
Cap tulo 5. Conclusiones y trabajo futuro
247
Uno de los elementos no considerados en nuestra propuesta de semntica para a las mquinas de estados son las actividades, acciones que se ejecutan durante a el tiempo en que una mquina de estados permanece en un estado. En el moa delo presentado, cada instancia de una mquina de estados estar ligada a a a un objeto. La posibilidad de modicar el objeto de un estado a travs de dos e mecanismos en principio autnomos, las llamadas a mtodos de la clase a la o e que pertenece el objeto el env de instancias de eventos que sern procesados o a por la mquina de estados ligada al objeto, hace que sea necesario planteara se cul es la forma en que una accin de un tipo repercute en el estado de a o ambos conceptos relacionados (objeto y mquina de estados). Por ejemplo, a cmo tener en cuenta la ejecucin de las acciones o de las actividades que o o modican los valores de los slots del objeto al que se asocia la mquina de a estados en la secuencia de snapshots del objeto en el dominio semntico. a Otro tema interesante a estudiar es el de la expresividad del metamodelado como mecanismo de modelado de la semntica de aspectos dinmicos a a (acciones y mquinas de estados) y compararla con otras tcnicas de modea e lado, como las semnticas para mquinas de estados con otros formalismos a a nombradas en la seccin 1.1 del cap o tulo 3. Entre las ventajas del metamodelado podemos citar, y de hecho es el principal motivo que cita la OMG para elegirlo en sus normas, la facilidad de comprensin, ya que no se basa o en formalismos con una notacin matemtica compleja, sino en conceptos o a familiares, como clases, objetos, asociaciones, etc. Entre los inconvenientes hay que resaltar que la base formal en la que se asienta el metamodelado no est tan desarrollada como la que usan otras a propuestas (lgicas temporales, redes de Petri, mquinas de estados exteno a didas, etc.), lo que provoca que se sigan discutiendo distintas posibilidades y alternativas en el metamodelado (como, por ejemplo, la conveniencia del
248 metamodelado estricto, como sugiere la OMG). Otro inconveniente destacable que hemos detectado durante la realizacin o de este trabajo es la capacidad de establecer propiedades de viveza con los diagramas de clases y las reglas de correccin expresadas en OCL. Ciertas o situaciones que se pueden expresar como cuando se cumpla una condicin, o lo siguiente que debe ocurrir es esta accin no son fcilmente expresables en o a OCL. Un ejemplo de estas situaciones se da en las transiciones espontneas en a las mquinas de estados. Cuando todas las regiones de un estado concurrente a acaban, porque llegan a un estado nal, el estado concurrente debe acabar ejecutando una transicin espontnea. Una situacin anloga se da cuando o a o a acaba la actividad que se ejecuta en un estado. El n de la actividad fuerza, segn la semntica de la OMG, la salida del estado a travs de la ejecucin u a e o de una transicin espontnea. Pensamos que los diagramas de clases y las o a reglas de correccin en OCL que hemos empleado para denir el dominio o semntico de los elementos dinmicos, y por tanto la semntica dinmica, a a a a han demostrado ser adecuados para especicar si un diagrama de objetos que representa una secuencia en el funcionamiento de un sistema es correcto o no desde el punto de vista de su denicin semntica, pero que estos mismos o a elementos de modelado adolecen de herramientas para forzar la ocurrencia de secuencias como las mencionadas de las transiciones espontneas. a
Bibliograf a
[1] pUML r submission with regard to UML 2.0, howpublished = http://www.cs.york.ac.uk/puml/papers/RFIResponse.PDF, key = 2Usubmission. [2] M. Abadi and L. Lamport. And old-fashioned recipe for real time. ACM Transactions of Programming Languages and Systems, 5(16):1543 1571, sept 1994. [3] J. R. Abrial. The B-Book: Assigning Programs to Meanings. Cambridge University Press, 1996. [4] Action semantics consortium: Response to omg rfp ad/98-11-01. action semantics for the UML. www.umlactionsemantics.org. [5] J. Allen and G. Ferguson. Actions and events in interval temporal logic. Technical Report TR-URCSD 521, University of Rochester, Rochester, NY, 1994. [6] K. Altisen, G. Goesler, and J. Sifakis. A methodology for the construction of scheduler systems. In Proceedings of Formal Techniques in RealTime and Fault-Tolerant Systems, Pune (India), sep 2000. SpringerVerlag. 249 Revised September 5, 2000 (2000)
250
Bibliograf a
[7] R. Alur and T. Henzinger. A really temporal logic. In Proceedings of the 30th IEEE Conference on Foundations of computer Science, Los Alamitos, CA, 1989. IEEE Computer Sociery Press. [8] J. Alvarez, M. D L. Llopis, E. Pimentel, and J. Troya. An analysable az, execution model for sdl for embedded real-time systems. In Workshop on Real-Time Programming (WRTP99). Elsevier, 1999. [9] J. Alvarez, M. D L. Llopis, E. Pimentel, and J. Troya. Embedded az, real-time development using sdl. In IEEE Real Time Systems Symposium (RTSS99). WIP sessions, 1999. [10] J. Alvarez, M. D L. Llopis, E. Pimentel, and J. Troya. Integrating az, schedulability analysis and sdl in an object-oriented methodology. In Proceedings of 9th SDL Forum, pages 241 259, Montreal, jun 1999. Elsevier. [11] J. Alvarez, M. D L. Llopis, E. Pimentel, and J. Troya. Schedulability az, analysis in real-time embedded systems specied in SDL. In Proceedings of 25th IFAC Workshop on Real-Time Programming, pages 117 123, Palma de Mallorca (Espaa), may 2000. Elsevier. n [12] J. Alvarez, M. D L. Llopis, E. Pimentel, and J. Troya. Sdl and hard az, real-time: New design and analysis techniques. In Workshop on SDL and MSC (SAM00), 2000. [13] J. Alvarez, M. D L. Llopis, E. Pimentel, and J. Troya. Deriving hard az, real time system implementations directly from SDL specications. In Proceedings of 9th International Symposium on Hardware/Software Codesign, pages 128 134, Copenague, apr 2001. ACM press.
Bibliograf a
251
[14] J. Alvarez, M. D L. Llopis, E. Pimentel, and J. Troya. Integrating az, schedulability analysis and design techniques in sdl. Real Time Systems Journal, 3(24):267 302, may 2003. [15] J. Alvarez, M. D L. Llopis, E. Pimentel, and J. Troya. An object az, oriented methodology for embedded real-time systems. The Computer Journal, 46(2):123 145, 2003. [16] J. M. Alvarez, T. Clark, A. Evans, and P. Sammut. An action semantics for the mml. In UML 2001, 2001. [17] L. Apvrille, P. de Saqui-Sannes, C. Lohr, P. Snac, and J.-P. Courtiat. e A new UML prole for real-time system formal design and validation. In Gogolla and Kobryn [52], pages 287301. [18] D. Aredo. Semantics of UML statecharts in PVS. Technical Report Research Report 299, Department of Informatics, University of Oslo, 2000. [19] P. J. Ashenden. The Designers Guide to VHDL. Morgan Kaufmann Publishers, San Francisco, 1995. [20] L. Baresi and M. Pezz`. On formalizing uml with high-level petri e nets. In G. Agha, F. de Cindio, and G. Rozenberg, editors, Concurrent Object-Oriented Programming and Petri Nets, volume 2001 of Lecture Notes in Computer Science, pages 276304. Springer, 2001. [21] P. Bellini, R. Mattolini, and P.Nesi. Temporal logics for real-time system specication. ACM Computing Surveys, 32(1):12 42, mar 2000. [22] M. Ben-Ari, A. Pnuelli, and Z. Manna. The temporal logic of branching time. Acta Informatica, 3(20):207 226, 1983.
252
Bibliograf a
[23] G. Booch. Object-oriented analysis and design with applications. Benjamin/Cummings Pub. Co., Redwood City, Calif., 1994. [24] G. Booch, J. Rumbaugh, and I. Jacobson. The Unied Modeling Language User Manual. Addision-Wesley, 1999. [25] E. Brger, A. Cavarra, and E. Riccobene. Modeling the dynamics o of uml state machines. In ASM 00: Proceedings of the International Workshop on Abstract State Machines, Theory and Applications, volume 1912, pages 223241, London, UK, 2000. Springer-Verlag. [26] M. Bozga, S. Graf, L. Mounier, I. Ober, J.-L. Roux, and D. Vincent. Timed extensions for sdl. In Reed and Reed [99], pages 223240. [27] S. Brodsky, A. Clark, S. Cook, A. Evans, and S. Kent. A feasibility study in rearchitecting UML as a family of languages using a precise oo meta-modeling approach. Technical report, pUML group, 2000. http://www.puml.org/mmt.zip. [28] A. Burns. How to verify a safe real-time system: The application of model checking and timed automata to the production cell case study. Real Time Systems, 24(2):135 151, mar 2003. [29] A. Burns and A. Wellings. Hrt-hood: A design method for hard realtime systems. Real Time Systems, (6):73 114, 1994. [30] A. Burns and A. Wellings. Real-Time Systems and Programming Languages. Addison-Wesley, 1997. [31] A. Clark, A. Evans, and S. Kent. Engineering modelling languages: A precise oo meta-modeling approach. Technical report, pUML group, 2000. http://www.puml.org/mml.
Bibliograf a
253
[32] E. M. Clarke, E. A. Emerson, and A. Sistla. Automatic verication of nite-state concurrent sistems using temporal logic specications. ACM Transactions on Programming Languages and Systems, 2(8):244 263, april 1986. [33] D. Coleman, P. Arnold, S. Bodo, C. Dollin, H. Gilchrist, F. Hayes, and P. Jeremaes. Object-Oriented Development - The Fusion Method. Prentice Hall, 1993. [34] J.-P. Courtiat, C. Santos, C. Lohr, and B. Outtaj. Experience with rtlotos, a temporal extension of the lotos formal description technique. Computer Communications, 23(12):1104 1123, jul 2000. [35] M. L. Crane and J. Dingel. On the semantics of uml state machines: Categorization and comparison. Technical Report 2005-501, School of Computing, Queens University, Kingston, Ontario, Canada, 2005. [36] K. Diethers, U. Goltz, and M. Huhn. Model checking UML statecharts with time. In J. Jrjens, M. V. Cengarle, E. B. Fernandez, B. Rumpe, u and R. Sandner, editors, Critical Systems Development with UML Proceedings of the UML02 workshop, pages 3552. Technische Universitt Mnchen, Institut fr Informatik, 2002. a u u [37] E. Dijkstra. Guarded commands, nondeterminacy and formal derivation of programs. Communications of the ACM, 18(8):453 457, aug 1975. [38] E. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976. [39] B. P. Douglass. Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns. Object Technology Series. Addison Wesley, 1999.
254
Bibliograf a
[40] J. Drake, M. G. Harbour, and J. L.Medina. Vista uml de tiempo real de sistemas diseados bajo una metodolog orientada a objetos. Techn a nical report, Group of Computers and Real-Time Systems. University of Cantabria (Internal Report), 2001. http://mast.unican.es/umlmast. [41] D. DSouza and A. C. Wills. Object Components and Frameworks with UML The Catalysis Approach. Addison-Wesley, 1998. [42] W. Dulz, S. Grughl, L. Kerber, and M. Sllner. Early performance o prediction of SDL/MSC specied systems by automatic synthetic code generation. In Proceedings of the 9th SDL Forum, pages 457 473, Montreal, Canada, jun 1999. Elsevier. [43] Enhancements to LOTOS (E-LOTOS), 2001. [44] A. Ek. The somt method. Technical report, Telelogic AB, 1995. [45] E. A. Emerson and J. Y. Halpner. sometimes and not never revisited: On branching versus linear time temporal logic. Journal of the ACM, 1(33):151 178, jan 1986. [46] G. Engels, J. H. Hausmann, R. Heckel, and S. Sauer. Dynamic meta modeling: A graphical approach to the operational semantics of behavioral diagrams in uml. In A. Evans, S. Kent, and B. Selic, editors, UML, volume 1939 of Lecture Notes in Computer Science, pages 323 337. Springer, 2000. [47] M. K. et al. A Practitioners Handbook for Real-time Analysis. Kluwer Academic Publishers, 1993.
Bibliograf a
255
[48] E. T. S. I. (ETSI). ETSI ES 201 873-1 V3.1.1 (2205-06) Methods for Testing and Specication(MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language. [49] European Space Agency. HRM/91-07/V3.1, sep 1991. [50] http://www.csverilog.com, 2001. [51] S. Gnesi, D. Latella, and M. Massink. Modular semantics for a uml statechart diagrams kernel and its extension to multicharts and branching time model-checking. J. Log. Algebr. Program., 51(1):4375, 2002. [52] M. Gogolla and C. Kobryn, editors. UML 2001 - The Unied Modeling Language, Modeling Languages, Concepts, and Tools, 4th International Conference, Toronto, Canada, October 1-5, 2001, Proceedings, volume 2185 of Lecture Notes in Computer Science. Springer, 2001. [53] M. Gogolla and F. P. Presicce. State diagrams in UML: A formal semantics using graph transformation. In Proceedings PSMT98 Workshop on Precise Semantics for Modeling Techniques, 1998. [54] H. Gomaa. Designing Concurrent, Distributed, and Real-Time Applications with UML. Addison-Wesley, 2000. [55] M. Gonzlez, M. Klein, and J. Lehoczky. Fixed priority scheduling of a periodic tasks with varying execution priorities. In Proceedings of the IEEE Real Time Systems Symposium, pages 116 128, San Antonio, dec 1991. IEEE Computer Society Press. HOOD Reference Manual Issue 3.1,
256
Bibliograf a
[56] O. M. Group. UML prole for schedulability, performance and time specication. version 1.1. formal/05-01-02. Technical report, Object Management Group, jan 2005. [57] D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8:231274, 1987. [58] C. Hoare. An axiomatic basis for computer programming. Communications of the ACM, 12(10):576 583, oct 1969. [59] C. Hoare. Communicating sequential processes. Communications of the ACM, 21(8):666 677, oct 1978. [60] ISO. Information processing systems open systems interconection lotos a formal description technique based on the temporal ordering of observational behaviour. Technical Report IS-8807, ISO., Geneva, sep 1989. [61] ITU. Specication and description language. Technical Report ITU-T Z.100, International Telecommunications Union, 1996. [62] M. Jackson. Principles of Program Design. Academic Press Inc, 1975. [63] M. Jackson. Object-Oriented Technology for Real-Time Systems: A Practical Approach Using OMT and Fusion. Prentice Hall, 1996. [64] I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard. ObjectOriented Software Engineering - A Use Case Driven Approach. Addison Wesley, 1992. [65] F. Jahanian and A. K. Mok. Safety analysis of timing properties in realtime systems. IEEE Transactions on Software Engineering, 9(12):890 904, sep 1986.
Bibliograf a
257
[66] C. B. Jones. Sistematic Software Development using VDM. Prentice Hall, 1989. [67] M. Joseph and P. Pandya. Finding response time in a real-time system. The Computer Journal, 29:390 395, 1986. [68] E. M. C. Jr., O. Grumberg, and D. A. Peled. Model Checking. The MIT Press, 1999. [69] A. Kleppe and J. Warmer. Unication of static and dynamic semantics of uml. a study in redening the semantics of the uml using the puml oo meta modelling approach. Technical report, Klasse Objecten, 2001. [70] A. Knapp and S. Merz. Model checking and code generation for uml state machines and collaborations. Technical Report Technical Report 2002-11, Institut fur Informatik, Universitat Augsburg, Reisensburg, Germany, 2002. [71] T. Kolloch and G. Frber. Mapping an embedded hard real time sysa tems SDL specication to an analysable task network - a case study. In Proceedings of ACM SIGPLAN Workshop on Languages, Compilers and Tools for Embedded Systems, pages 156 166, Montreal (Canada), jun 1998. Springer-Verlag. [72] S. Kuske. A formal semantics of uml state machines based on structured graph transformation. In Gogolla and Kobryn [52], pages 241256. [73] L. Lamport. The temporal logic of actions. ACM Transactions of Programming Languages and Systems, 3(16):872 923, may 1994.
258
Bibliograf a
[74] K. Lano, J. Bicarregui, and A. Evans. Structured axiomatic semantics for uml models. In Rigorous Object-Oriented Methods, Workshops in Computing. BCS, 2000. [75] L. Lavazza, G. Quaroni, and M. Venturelli. Combining UML and formal notations for modelling real-time systems. In ESEC / SIGSOFT FSE, pages 196206, 2001. [76] N. Leveson. Safeware. Addison-Wesley, 1995. [77] C. Liu and J. Layland. Scheduling algorithms for multiprogramming in a hard real-time environment. Journal of ACM, 20:46 71, 1973. [78] J. Mathai. Real-time Systems. Specication, Verication and Analysis. Prentice Hall International, 1996. [79] J. McDermid. Assurance in High Integrity Software, chapter 10. Pitman, 1989. [80] P. M. Melliar-Smith. Extending interval logic to real time systems. In Proceedings of the Conference on Temporal Logic Specication, pages 224 242, UK, 1987. Springer-Verlag. [81] R. Milner. Communications and Concurrency. Prentice-Hall, 1989. [82] A. Mitschele-Thiel and B. Mller-Clostermann. Performance engineeu ring of SDL/MSC systems. In Proceedinds of the 8th SDL Forum, pages 23 26, Evry, France, sep 1997. Elsevier. [83] A. Mitschele-Thiel and F. Slomka. Codesign with sdl/msc. In First International Workshop on Conjoint Systems Engineering, Tlz, Bad, o 1997.
Bibliograf a
259 2003.
[84] MetaObjectFacility(MOF)
Specication.
Version
1.4,
http://www.omg.org/docs/formal/02-04-03.pdf. [85] ITU recommendation Z.120. Message Sequence Chart (MSC). Geneva (Switzerland), 2000. [86] R. Mnzenberger, F. Slomka, M. Drfel, and R. Hofmann. A general u o approach for the specication of real-time systems with sdl. In Reed and Reed [99], pages 203222. [87] Object Management Group. formal/03-03-13 (UML 1.5 chapter 6 Object Constraint Language Specication), 2003. [88] Object Management Group. OMG Unied Modeling Language Specication, March 2003. Version 1.5. [89] UML 2.0 OCL Specication, 2003. http://www.omg.org/docs/ptc/0310-14.pdf. [90] OMG. Meta-object facility. Technical Report Document ad/97-08-14, DSTC, OMG, sep 1997. [91] J. S. Ostro and W. Wonham. Modeling and verifying real-time embedded computer systems. In Proceedings of the 8th IEEE Real-Time Systems Symposium, pages 124 132, Los Alamitos, CA, 1987. IEEE Computer Sociery Press. [92] S. Owre, N. Shankar, and J. Rushby. The PVS specication language. Technical report, Computer Science Laboratory, SRI International, feb 1993.
260
Bibliograf a
[93] C. A. Petri. Fundamentals of a theory of asynchronous information ow. In Proc. of IFIP Congress 62, pages 386390, Amsterdam, 1963. North Holland Publ. Comp. [94] A. Pnuelli. The temporal logic of programs. In Proceedings of the 18th Annual Symposium on Foundations of Computer Science, pages 46 57, Los Alamitos, CA, 1977. IEEE Computer Society Press. [95] B. Potter, J. Sinclair, and D. Till. An Introduction to Forma Specication and Z. International Series in Computer Science. Prentice Hall, 1991. [96] F. Rallis. Octopus/uml: Combining objects with real-time. pages 480 489, Washington, DC, USA, 1999. IEEE Computer Society. [97] http://www.ilogix.com, 2001. [98] R. Razouk and M. Gorlick. Real-time interval logic for reasoning about executions of real-time programs. SIGSOFT Software Engineering Notes, 8(14):10 19, dec 1989. [99] R. Reed and J. Reed, editors. SDL 2001: Meeting UML, 10th International SDL Forum Copenhagen, Denmark, June 27-29, 2001, Proceedings, volume 2078 of Lecture Notes in Computer Science. Springer, 2001. [100] C. Rossi, M. Enciso, and I. P. de Guzmn. Formalization of UML a state machines using temporal logic. Software and System Modeling, 3(1):3154, 2004. [101] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice Hall, 1991.
Bibliograf a
261
[102] J. Rumbaugh, G. Booch, and I. Jacobson. The Unied Modeling Language. User Guide. Addison-Wesley, 1999. [103] M. Saksena, P. Freedman, and P. Rodziewick. Guidelines for automated implementation of executable object oriented models for real-time embedded control systems. In Proceedings of the 18th IEEE Real-Time System Symposium, pages 240 251, San Francisco, EE.UU., dec 1997. IEEE Computer Society Press. [104] M. Saksena and P. Karvelas. Designing for schedulability: Integrating schedulability analysis with object-oriented design. In Proceedings of 12th IEEE Euromicro Conference on Real-Time Systems, pages 101 109, Estocolmo, Suecia, jun 2000. IEEE Computer Society Press. [105] M. Saksena, P. Karvelas, and Y. Wang. Automatic synthesis of multitasking implementations from real-time object oriented models. In Proceedings of International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC00), pages 360 368. IEEE Computer Society Press, mar 2000. [106] M. Saksena, A. Ptak, P. Freedman, and P. Rodziewick. Schedulability analysis for automated implementations of real-time object-oriented methods. In Proceedings of the 19th IEEE Real-Time System Symposium (RTSS98), pages 92 102, Madrid (Spain), dec 1998. IEEE Computer Society Press. [107] R. L. Schwartz, P. M. Melliar-Smith, and F. H. Vogt. An interval logic for higher-level temporal reasoning. In Proceedings of the Second ACM Symposium on Principles of Distributed Programming, pages 173 186, New York, NY, 1983. ACM Press.
262
Bibliograf a
[108] ITU recommendation Z.100. Specication and Description Language (SDL). Geneva (Switzerland), 2000. [109] B. Selic. Models, Software Models and UML, pages 1 15. Kluwer Academic Publishers, 2003. [110] B. Selic, G. Gullekson, and P. T. Ward. Real-Time Object-Oriented Modelling. John Wiley, 1994. [111] B. Selic and J. Rumbough. Using UML for modeling complex real-time systems. Technical report, OjbecTime Limited and Rational Software Corporation, mar 1998. [112] S. Shankar and S. Asa. Formal semantics of UML with real-time constructs. In P. Stevens, J. Whittle, and G. Booch, editors, UML 2003 - The Unied Modeling Language. Model Languages and Applications. 6th International Conference, San Francisco, CA, USA, October 2003, Proceedings, volume 2863 of LNCS, pages 6075. Springer, 2003. [113] H. Simpson. The mascot method. Software Engineering Journal,
1(3):103 120, may 1986. [114] S. Spitz, F. Slomka, and M. Drfel. SDL* - an annotated specication o language for engineering multimedia communication systems. In Sixth Open Workshop on High Speed Networks, Stuttgart, 1997. [115] J. M. Spivey. The Z Notation. A Reference Manual. International Series in Computer Science. Prentice Hall, second edition, 1992. [116] S. Stepney, R. Barden, and D. Cooper. Object Orientation in Z. Workshops in Computing. Springer-Verlag, 1992.
Bibliograf a
263
[117] L. M. L. Torres. Integracin de Anlisis de Tiempo Real en la Tcnica o a e de Descripcin Formal SDL. PhD thesis, Universidad de Mlaga, 2002. o a [118] UML 2.0 Infrastructure Specication, 2003.
http://www.omg.org/docs/ptc/03-09-15.pdf. [119] UML 2.0 Superstructure Specication, 2003.
http://www.omg.org/docs/ptc/03-08-02.pdf. [120] J. Woodcock and J. Davies. Using Z Specication, Renement, and Proof. International Series in Computer Science. Prentice Hall, 1996. [121] www.2uworks.org. Unambiguous UML (2u) 3rd revised submission to UML 2 infrastructure rfp, version 1.0. omg document ad/2003-01-08. http://www.2uworks.org/uml2submission/1.0/uml2InfraSubmission1.pdf, jan 2003. [122] www.2uworks.org. Unambiguous UML (2u) 3rd revised submission to UML 2 superstructure rfp, version 0.2. omg document ad/2002-12-23. http://www.2uworks.org/uml2submission/super0.2/uml2SuperSubmission02.pdf, jan 2003.

Desarrollo de Software para Sistemas de Tiempo Real Basado en UML. Un Enfoque Formal Basado en Metamodelado

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Desarrollo de Software para Sistemas de Tiempo Real Basado en UML. Un Enfoque Formal Basado en Metamodelado

Uploaded by

Copyright:

Available Formats

Desarrollo de Software para Sistemas de Tiempo Real Basado en UML.

Un Enfoque Formal Basado en Metamodelado

Director: Dr. Manuel D Rodr az guez

En Mlaga, 9 de febrero de 2006 a

77 77 79 80 81 82 84 86 87 88 90 92 95 98 100 101 103 104 105 106 107

Cap tulo 1. Introduccin o

Debe ser signicativamente ms fcil y econmico de construir que el a a o sistema nal.

Necesidad del modelado

Los sistemas de tiempo real y su modelado

Cap tulo 1. Introduccin o

Cap tulo 1. Introduccin o

Cap tulo 1. Introduccin o

con una semntica formal en la norma de denicin. a o

Cap tulo 1. Introduccin o

Cap tulo 1. Introduccin o

2. Modelado formal de sistemas

Modelado formal de sistemas

Cap tulo 1. Introduccin o

2. Modelado formal de sistemas

Cap tulo 1. Introduccin o

Tcnicas basadas en teor de conjuntos e a

2. Modelado formal de sistemas

Cap tulo 1. Introduccin o

Tcnicas basadas en lgebras de procesos e a

2. Modelado formal de sistemas

Cap tulo 1. Introduccin o

2. Modelado formal de sistemas

Cap tulo 1. Introduccin o

2. Modelado formal de sistemas

Cap tulo 1. Introduccin o

3. Tcnicas y herramientas formales de anlisis: Tau e a

Tcnicas y herramientas formales de anlie a sis: Tau

Cap tulo 1. Introduccin o

3. Tcnicas y herramientas formales de anlisis: Tau e a

Cap tulo 1. Introduccin o

3. Tcnicas y herramientas formales de anlisis: Tau e a

es posible en el sistema o de si hay caminos que lo violen.

Cap tulo 1. Introduccin o

Lenguajes grcos de modelado a

4. Lenguajes grcos de modelado a

Cap tulo 1. Introduccin o

4. Lenguajes grcos de modelado a

Cap tulo 1. Introduccin o

intr_fichas contador_monedas interfaz_usuario

Figura 1.1: Descripcin a nivel de o sistema.

Figura 1.2: Descripcin a nivel de o bloques.

4. Lenguajes grcos de modelado a

DCL precio Integer := 10, insertadas Integer := 0, existencias Integer := 10;

false existencias > 0 true

false insertadas < precio true

Figura 1.3: Descripcin del proceso o controlador.

Figura 1.4: Descripcin del proceso o contador.

Cap tulo 1. Introduccin o

4. Lenguajes grcos de modelado a

Cap tulo 1. Introduccin o

4. Lenguajes grcos de modelado a

Cap tulo 1. Introduccin o

4. Lenguajes grcos de modelado a

Cap tulo 1. Introduccin o

4. Lenguajes grcos de modelado a

Cap tulo 1. Introduccin o

4. Lenguajes grcos de modelado a

Cap tulo 1. Introduccin o