17155538

Desarrollo de Software para Sistemas de Tiempo Real Basado en UML. Un Enfoque Formal Basado en MetamodeladoTesis 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

1

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 sistemasQu 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

2

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

3

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

4


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


5

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

6


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


7

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

8


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


9

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 sistemasSon 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: TauEl 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 aEn 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 expendedorsystem MaquinaExpendedorapeticion, ficha, anular

agotado

1(1)

1(1)

inf_errorinterfaz_usuario

ordenes_usuario interfaz_usuariopeticion, anular

controlador

expendedor

recibido, agotado

ventainicio, anular

agotado

interfaz_sal

intr_fichas contador_monedas interfaz_usuarioficha

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

iniciolisto

false existencias > 0 truepeticion anular

agotado recibir_fichasvendiendo

listo fichaanular agotado recibido

anular

insertadas := insertadas + 1;anular agotado dar

insertadas := 0;

false insertadas < precio truelisto

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 esta

17155538

Documents

Transcript of 17155538