Santiago de Cali, Septiembre 11 de 2014 · Santiago de Cali, Septiembre 11 de 2014 Doctor JAIME...

Santiago de Cali, Septiembre 11 de 2014

DoctorJAIME ALBERTO AGUILAR ZAMBRANODecano de la Facultad de IngenieríaPonti�cia Universidad JaverianaCiudad

Certi�co que el presente trabajo de grado, titulado �MODELADO, PRUEBA Y VERIFICACIÓNDE SISTEMAS DISTRIBUIDOS USANDO RTDS E IFx� realizado por JUAN PABLO GIRÓNRUIZ, estudiante de Ingeniería Electrónica, se encuentra terminado y puede ser presentado parasustentación.

Atentamente,

Dr. EUGENIO TAMURA MORIMITSUDirector del Proyecto

Santiago de Cali, Septiembre 11 de 2014

DoctorJAIME ALBERTO AGUILAR ZAMBRANODecano de la Facultad de IngenieríaPonti�cia Universidad JaverianaCiudad

Por medio de ésta, presento a usted el trabajo de grado titulado �MODELADO, PRUEBA YVERIFICACIÓN DE SISTEMAS DISTRIBUIDOS USANDO RTDS E IFx� para optar el título deIngeniero Electrónico.

Espero que este trabajo reúna todos los requisitos académicos y cumpla el propósito para el cualfue creado, y sirva de apoyo para futuros proyectos en la Universidad Javeriana relacionados con lamateria.

Atentamente,

JUAN PABLO GIRÓN RUIZ

Modelado, prueba y verificación de sistemas distribuidosusando RTDS e IFx

Juan Pablo Girón Ruiz

Pontificia Universidad

JAV ERIANACali

Facultad de Ingeniería

Ingeniería Electrónica

Santiago de Cali

2014

Modelado, prueba y verificación de sistemas distribuidosusando RTDS e IFx

Juan Pablo Girón Ruiz

Proyecto de grado para optar al título de

Ingeniero Electrónico

Director : Dr. Eugenio Tamura

Pontificia Universidad Javeriana

Facultad de Ingeniería

Ingeniería Electrónica

Santiago de Cali

2014

ARTICULO 23 de la Resolución No. 13 del 6 de Julio de 1946

del Reglamento de la Pontificia Universidad Javeriana.

�La Universidad no se hace responsable por los conceptos emitidos

por sus alumnos en sus trabajos de Tesis. Sólo velará porque no se

publique nada contrario al dogma y a la moral católica y porque las

Tesis no contengan ataques o polémicas puramente personales;

antes bien, se vea en ellas el anhelo de buscar la Verdad y la Justicia�

Agradecimientos

Primero que todo, quiero dar gracias a Dios por la oportunidad que me ha dado de poder realizary culminar exitosamente éste trabajo de grado y por ende una etapa más de mi vida. Ademáspor permitirme trabajar al lado de mi director Eugenio Tamura quien día a día se esforzaba porenseñarme a hacer academia de forma autónoma. Estoy muy agradecido con él porque por mediode este trabajo de grado me brindó la oportunidad de crecer tanto académica como personalmente.

Quiero agradecer a mis padres, mis hermanos, mi abuela, mi novia Ana María Zúñiga y miamigo Diego Ceballos porque siempre me apoyaron en este proceso de mi carrera, que a pesar delos momentos de estrés siempre tuvieron paciencia y supieron como alentarme para no desfallecer.

Quiero agradecer a mi novia Ana María Zúñiga Velasco por todo su tiempo dedicado en leer ycorregir mi documento y por siempre tener la disposición de ayudarme y motivarme en ser mejorpersona y entregar lo mejor de mí día tras día.

Finalmente quiero agradecer al Sr. Eric Brunel Co-Creador y Director de tecnología de Pragma-dev y a su equipo, por brindarme soporte en la herramienta RTDS y a Marius Bozga creador dellenguaje IF por atender mis solicitudes y ayudarme en cada problema que tuve al usar la herramientaIFx.

Juan Pablo Girón R,

11 Sept. 2014

Resumen

Garantizar que los diseños de sistemas Hardware/Software no presenten problemas, se ha con-vertido en un reto cada vez mayor. El uso de técnicas formales como el Model Checking garantizade forma exhaustiva que los sistemas satisfagan una propiedad pero no la ausencia de errores. Porotro lado, el uso de pruebas funcionales de caja negra, permite tener una noción de qué tan bienestá construido el diseño del sistema, pero no es la mejor manera para valorar módulos críticos deun sistema distribuido.

El presente trabajo de grado está subdivido en tres grandes partes con el objetivo de explicar unametodología para la minimización de errores que combina una técnica formal y una no formal sobreun caso de estudio que corresponde al sistema de parqueo de la Ponti�cia Universidad Javeriana Cali,PUJC. Para el modelado del caso de estudio se hace uso de los diagramas de Secuencia de Mensajes,Message Sequence Message, MSC, y del lenguaje de Especi�cación y Descripción, conocido comoSpeci�cation and Description Language, SDL por sus siglas en inglés, sobre la herramienta Real-Time Developer Studio RTDS de PragmaDev, al igual que la simulación y pruebas funcionales decaja negra por medio del lenguaje Testing and Test Control Notation version 3 (TTCN-3). Porotra parte, se hace uso de la técnica de Model Checking sobre la herramienta IFx de Verimag paraveri�car formalmente propiedades expresadas por observadores, sobre un módulo crítico del sistemadel caso de estudio.

Palabras Clave: Modelado de sistemas distribuidos, pruebas funcionales, Model Checking, veri-�cación formal, SDL, MSC, TTCN-3, IF, RTDS, Herramienta IFx.

Abstract

One of the contemporary biggest challenges when designing Hardware/Software systems is gua-ranteeing that they are free of defects. The use of formal techniques like Model Checking allowsensuring that systems satisfy a given property because of exhaustive veri�cation; however, they donot guarantee that the system has no errors. On the other hand, the use of functional black boxtesting, provides a notion of how well designed the system is, but this approach is not the best wayto evaluate the critical modules of a distributed system.

This work is subdivided into three major parts in order to explain a methodology for minimizingerrors that combines two techniques, one is formal and the other one is semiformal on a casestudy corresponding to the parking system at the Ponti�cia Universidad Javeriana Cali, PUJC.Using PragmaDev's Real Time Developer Studio (RTDS), the model was described using MessageSequence Charts (MSC) and the Speci�cation and Description Language (SDL); its simulation tooland the Testing and Test Control Notation version 3 (TTCN-3) were used for black box functionaltesting. Finally, by using the Verimag's IF language and the IFx toolset, Model Checking techniqueswere applied to formally verify properties expressed by observers on a critical component of thesystem.

Keywords: Modeling of distributed systems, functional testing, Model Checking, formal veri�ca-tion, SDL, MSC, TTCN-3, IF, RTDS, IFx toolset.

Índice general

1. Introducción 11.1. Objetivos, Alcances y Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2. Objetivos Especí�cos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.3. Alcances y Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2. Metodología de Estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5. Estructura del Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Marco de Referencia 72.1. Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2. Marco Teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1. Lenguaje para la Especi�cación y Descripción de Sistemas Distribuidos . . . . 92.2.2. Software de Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.3. Veri�cación Formal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3. Caso de Estudio del Proyecto de Grado 213.1. Modelado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1.1. Especi�cación Usando MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.1.2. Diseño Usando SDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.2.1. Usando el Simulador de Modelos . . . . . . . . . . . . . . . . . . . . . . . . . 463.2.2. Usando una GUI para Probar Modelos . . . . . . . . . . . . . . . . . . . . . . 493.2.3. Usando TTCN-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.3. Veri�cación Formal usando IFx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.3.1. Consideraciones para Veri�car Sistemas Descritos en IF . . . . . . . . . . . . 663.3.2. De�nición de Propiedades Safety . . . . . . . . . . . . . . . . . . . . . . . . . 68

4. Análisis y Discusión 814.1. Uso de las Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.1.1. RTDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.1.2. IFx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.2. Mejoras al Modelo del Sistema de Parqueo . . . . . . . . . . . . . . . . . . . . . . . . 854.2.1. RTDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.2.2. IFx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.3. Metodología para la Construcción de Sistemas Distribuidos . . . . . . . . . . . . . . 86

xiv Índice general

5. Observaciones Finales 895.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.2. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A. Tipos de Datos y Señales usadas en el modelado del sistema de parqueo de laPUJC 91

B. Diagramas MSCs de la especi�cación del sistema 105

C. Diagramas MSCs en la fase de pruebas 119

Bibliografía 127

Capítulo 1

Introducción

La complejidad de los sistemas tanto en Hardware como en Software se ha venido incrementandosigni�cativamente y por ende la probabilidad que los sistemas presenten fallas aumenta [Sch04].Diversas áreas de las ciencias de la computación y matemáticas han propuesto diferentes técnicas quepermiten obtener sistemas Hardware/Software con un mínimo de errores; dichas técnicas estructuranla descripción del sistema a través de métodos formales o no formales, los cuales se pueden evaluarimplementando desde una prueba de caja negra1 hasta el uso de métodos formales.

Garantizar que un sistema no tenga errores se ha convertido en un reto cada vez más difícil parala ingeniería y las ciencias de la computación. Existen sistemas en los cuales no se admiten errores,por ejemplo en los sistemas de aviación, sistemas de control de plantas nucleares, etc. [Bow00]. Sinembargo, a pesar que existen métodos de veri�cación, validación y prueba de modelos, la complejidadde los sistemas se ha venido incrementando con gran rapidez y la forma de detectar errores conmétodos separados es insu�ciente [BBC+02].

Durante décadas se ha visto que los métodos formales (formal methods) y las pruebas (Testing)han sido rivales; en efecto, cientos de cientí�cos de�enden que veri�car los modelos por medio de es-tructuras de lógica matemática bien de�nidas está por encima de hacer simples pruebas funcionales,como lo son las de caja negra. No obstante, recientemente se ha visto que los métodos formales y laspruebas son complementarios, pero lastimosamente aplicar estas técnicas para garantizar sistemaslibres de errores está muy lejos de ser realidad [Hoa96, BBC+02, HKL+09].

Uno de los más famosos métodos formales usados en la industria es el Model Checking [MMT09],el cual es una técnica de veri�cación automática que dado un modelo y una propiedad formaldetermina si dicho modelo la satisface, y en caso que no pueda hacerlo es capaz de informarle alusuario dónde está el error para corregirlo [Ari12, MMT09].

Por otra parte, uno de los lenguajes más conocidos a nivel mundial para realizar pruebas funcio-nales de caja negra es Testing and Test Control Notation Version 3, TTCN-3, [WDT+11, ETS], elcual ha sido desarrollado y estandarizado por European Telecommunication Standards Institute, ET-SI. TTCN-3 provee diversas características en cuanto al manejo de mensajes, niveles de abstracción,módulos para codi�cación y decodi�cación de los mensajes, entre otras [WDT+11, ETS].

El esquema que se pretende llevar a cabo en este trabajo de grado es:

Mostrar la especi�cación y descripción de un sistema a partir de máquinas de estados �nitasusando el lenguaje Speci�cation and Description Language (SDL) y su interacción usando

1Prueba de caja negra: Es una prueba funcional que consiste en estimular el sistema a probar con las entradas

apropiadas que debe recibir la aplicación, y revisar si las salidas son las deseadas; lo anterior se lleva a cabo sin tener

conocimiento de la estructura/funcionamiento interno del sistema.

2 Capítulo 1. Introducción

Message Sequence Chart2(MSC).

Una vez obtenido el modelo del sistema, mostrar cómo a partir de pruebas funcionales de tipocaja negra se puede ejercitar el modelo en los niveles más �nos de abstracción.

Para comprobar que el sistema sea con�able, se veri�carán formalmente algunas de las pro-piedades del sistema, las cuales se consideren más críticas para su funcionamiento.

Para ejecutar los anteriores pasos, se tomará como caso de estudio el sistema de parqueaderosde automóviles de la Ponti�cia Universidad Javeriana Cali; éste caso será útil para mostrar queel trabajo en conjunto de pruebas y veri�caciones formales, posibilita implementar sistemasmás con�ables.

Para la descripción y especi�cación del sistema se hará uso de SDL y MSC, para las pruebasfuncionales de caja negra se utilizará TTCN-3, y �nalmente para la veri�cación formal se haráuso de IFx3, la cual es una herramienta desarrollada por VERIMAG4 que por medio del acceso alárbol abstracto desde una especi�cación de SDL la traslada a un lenguaje intermedio llamado IF,y a través de este último se puede veri�car usando un algoritmo de Model Checking5, que ya vieneintegrado en la herramienta. Un factor diferenciador que se le quiere dar al trabajo de grado es poderhacer uso de los tres lenguajes mencionados anteriormente con un único software que se llama Real

Time Developer Studio6, RTDS, software desarrollado por la compañía Francesa Pragmadev.

1.1. Objetivos, Alcances y Limitaciones

1.1.1. Objetivo General

Valorar el proceso de veri�cación del correcto funcionamiento de un modelo que representa unsistema distribuido, empleando un caso de estudio a partir de la unión de dos técnicas: métodosformales y pruebas funcionales de caja negra, en diferentes etapas del desarrollo de sistemas usandolas herramientas RTDS e IFx.

1.1.2. Objetivos Especí�cos

1. Implementar el caso de estudio usando un lenguaje que permita realizar pruebas funcionalesde caja negra al diseño y veri�cación formal por medio de herramientas automáticas.

2. Determinar en qué etapas del desarrollo de sistemas es pertinente usar métodos formales opruebas.

2Más información de MSC referirse a la recomendación Z.120 disponible en: https://www.itu.int/rec/T-REC-Z.

120-201102-I/en3Más Información de la herramienta disponible en: http://www-if.imag.fr4Para mas información acerca de VERIMAG consultar la siguiente página: http://www-verimag.imag.fr/?lang=

en5Model checking es una técnica de veri�cación que, dado el modelo del sistema bajo estudio y la propiedad

requerida, permite decidir automáticamente si la propiedad es satisfecha o no [CW96, Ham09]6Más Información del proveedor del software disponible en: http://www.pragmadev.com

https://www.itu.int/rec/T-REC-Z.120-201102-I/en

https://www.itu.int/rec/T-REC-Z.120-201102-I/en

http://www-if.imag.fr

http://www-verimag.imag.fr/?lang=en

http://www-verimag.imag.fr/?lang=en

http://www.pragmadev.com

1.2. Metodología de Estudio 3

3. Diseñar una batería de pruebas incrementales que sea apropiada con el modelo del caso deestudio y compatible con el lenguaje en el cual ha sido expresado.

4. Determinar las propiedades críticas del sistema que se desea veri�car.

1.1.3. Alcances y Limitaciones

El proceso de modelado del caso de estudio se hará por medio de un lenguaje que permitaser evaluado a través de pruebas y traducido a lenguajes con semántica formal para realizarveri�cación formal. Para soportar lo anterior se usará la herramienta Real Time DeveloperStudio y el lenguaje a usar será SDL.

El modelo del caso de estudio se limitará a especi�car de manera general los procesos in-volucrados; algunos de ellos se asumirán como subsistemas, los cuales proporcionando unaentrada retornan una salida, pero no se modelará su comportamiento dado que no es de inte-rés del presente trabajo de grado desarrollarlo. Ej.: modelar la base de datos de usuarios delparqueadero.

Las pruebas realizadas al modelo se harán en las primeras fases del desarrollo del mismo sinusar componentes paralelos de pruebas (PTCs) usando SDL, MSC y TTCN3.

La veri�cación formal no se hará en el nivel de sistema completo, sino sobre módulos especí-�cos.

Se hará uso de la herramienta SDL2IF para la transformación del modelo descrito en SDL aIF, con el �n de veri�carlo formalmente.

Los procesos de modelado y pruebas se harán usando la herramienta Real Time DeveloperStudio, y para la parte de veri�cación formal se usará la técnica Model Checking sobre laherramienta IFx.

1.2. Metodología de Estudio

El proyecto de grado busca aplicar una metodología que combina de manera conjunta dos téc-nicas, métodos formales y pruebas funcionales, para minimizar errores en el diseño de sistemasdistribuidos. Para ilustrar la aplicación de las dos técnicas se hará uso de un caso de estudio em-pleando dos herramientas que son: RTDS para el modelado y pruebas e IFx para la veri�caciónformal. Lo anterior implica realizar las siguientes tareas:

1. Comprender el correcto funcionamiento de la herramienta RTDS.

2. Implementar el caso de estudio usando un lenguaje que permita evaluar el diseño a través depruebas y métodos formales.

3. Determinar en qué etapas del desarrollo de sistemas es pertinente usar métodos formales opruebas.

4 Capítulo 1. Introducción

4. Diseñar una batería de pruebas incrementales que sea apropiada con el modelo del caso deestudio y compatible con el lenguaje en el cual ha sido expresado.

5. Implementar la batería de pruebas.

6. Entender el funcionamiento de IFx para veri�car formalmente el modelo del caso de estudio.

7. Determinar las propiedades críticas del sistema que se desea veri�car.

8. Seleccionar los tipos de observadores para la especi�cación de la propiedad a veri�car.

9. Seleccionar las propiedades a veri�car.

10. Implementar los observadores.

1.3. Motivación

El uso de sistemas Hardware/Software en la vida cotidiana es cada vez mayor; dichos sistemasdía tras día suelen ser más complejos, lo que representa un reto cada vez mayor para las ciencias decomputación y las matemáticas, el de garantizar que los sistemas no tenga errores. Con la tecnologíaactual el uso de métodos formales no permiten garantizar diseños a nivel de sistema libres de error,dado que la complejidad computacional de éstos es cada vez mayor y las herramientas actualesno pueden abordar dicha complejidad. Por otro lado, las pruebas funcionales de caja negra se hanconsiderado como una buena alternativa para valorar la correctitud de un sistema; sin embargo,no es posible estimular al sistema bajo prueba con todos los posibles escenarios, lo que hace quelas pruebas no sean la mejor técnica para valorar sistemas críticos como los sistemas de control deaviación.

El presente trabajo de grado, tiene como motivación ilustrar, a través de un caso de estudiola utilización de dos técnicas para valorar el diseño de un sistema distribuido, con el propósitode determinar que la utilización conjunta de los métodos formales y las pruebas permite entregarsistemas distribuidos más con�ables. En la literatura se pueden encontrar grupos de investigación,como FORTEST, que han intentado unir fuerzas para demostrar que se pueden minimizar erroresen el diseño de sistemas usando una metodología que consiste en combinar conjuntamente métodosformales y no formales. Lo anterior es empleado para la minimización de errores en los sistemas.Así pues, este trabajo de grado pretende explicar cuándo y dónde es conveniente hacer uso de laveri�cación formal y las pruebas para depurar errores en el diseño de sistemas y por ende conseguirsistemas distribuidos más con�ables.

1.4. Contribuciones

Con la realización de este trabajo de grado se contribuyó en lo siguiente:

Metodología. Se propone una metodología para diseñar sistemas distribuidos más con�ables,indicando cuándo y dónde se puede hacer uso de las veri�caciones formales y las pruebasfuncionales de caja negra para la minimización de errores.

1.5. Estructura del Documento 5

Retroalimentación para mejoras de la herramienta RTDS. En el desarrollo del presenteTrabajo de Grado, se hizo uso de la herramienta RTDS en su versión 4.4.1 para especi�car,diseñar y probar el sistema en SDL, e IFx en la versión 2.0, para veri�car formalmente partedel diseño del sistema de parqueo de la PUJC. Durante el desarrollo de este proyecto, sereportaron diferentes errores al equipo de soporte de la herramienta RTDS; la respuesta porparte de ellos es que dichos errores serían corregidos en la siguiente versión de la herramienta.

Académico. Contribuir al curso de sistemas digitales, mostrando la utilización de herramien-tas existentes en el mercado, que son poco exploradas en el país pero usadas por grandescompañías, como en el caso de la herramienta RTDS que ha sido usada por las compañías:ST-Ericsson, Airbus, Renault, entre otras. En el caso de la herramienta IFx ha sido usadapara diferentes casos de estudio entre los cuales se destacan: Ariane-5 y Medium Altitude Re-

connaissance System (MARS) desarrollado por la Real Fuerza Aérea Holandesa para el aviónF-16.

1.5. Estructura del Documento

La estructura del presente documento se encuentra dividido en los siguientes capítulos:Capítulo 2. [Marco de referencia]. En este capítulo se introducen los conceptos de los

lenguajes que se usaron en el desarrollo de este trabajo de grado. Se empieza describiendo losconceptos de la fase del modelado en SDL, posteriormente se detallan algunos conceptos del lenguajeTTCN-3 y se �naliza explicando los métodos formales para la veri�cación de sistemas usando laherramienta IFx.

Capítulo 3. [Desarrollo del caso de estudio]. Este capítulo se centra sobre el desarrollo delcaso de estudio, y se encuentra subdividido en tres grandes partes. La primera describe el modeladodel sistema de parqueo de la PUJC; posteriormente se describen las pruebas funcionales de cajanegra realizadas a dicho diseño haciendo uso del simulador de la herramienta RTDS y del lenguajeTTCN-3. Finalmente se veri�can formalmente algunas propiedades de un módulo del sistema deparqueo, usando la herramienta IFx.

Capítulo 4. [Análisis y discusión]. En este capítulo se analiza el desarrollo del caso deestudio y cómo el uso de dos técnicas para la minimización de errores en una sola metodología,puede entregar sistemas distribuidos más con�ables. Adicionalmente se explica cuándo y dónde esconveniente hacer uso de los lenguajes y las herramienta en el proceso de minimización de erroresen el diseño de sistemas.

Capítulo 5. [Conclusiones]. En este capítulo se presentan los resultados principales, dandocumplimiento a los objetivos propuestos.

Capítulo 2

Marco de Referencia

2.1. Estado del Arte

La técnica del Model Checking ha sido usada desde comienzos de los años 90 para la veri�-cación de propiedades en Hardware. Algunos de los casos más notables en este proceso han sidolos siguientes proyectos que se pueden encontrar en [CW96, WLBF09]. En [CW96] mencionan elproyecto IEEE Futurebus+ como caso de estudio para mostrar las ventajas de la técnica del ModelChecking, usando una herramienta de veri�cación automática por primera vez. Este proyecto consis-tía en veri�car la coherencia de la cache descrita en el estándar 896.1-1991 de la IEEE Futurebus+.Este proyecto fue realizado por Clarke y sus estudiantes de la Universidad de Carnegie Mellon.En [CW96] se pueden encontrar diferentes proyectos tanto en Hardware como en Software donde seusan los métodos formales para garantizar que el sistema cumpla con propiedades críticas; se puedeencontrar además que el proyecto llamado NewCore fue el primero en ser veri�cado formalmente ensu totalidad, éste se describía en 7.500 líneas de código en SDL, excluyendo comentarios, que fueronveri�cados, hallando 112 errores que fueron corregidos.

Compañías como Intel mencionan que el uso de los métodos formales para la veri�cación de hard-ware ha sido útil para garantizar sistemas con�ables y de alta calidad, además de permitir mejorarlos procesos de desarrollo en sus primeras etapas del sistema [Fix08]. Recientemente en [WLBF09]se puede encontrar un estado del arte actualizado de las experiencias que han obtenido las indus-trias en el uso de los métodos formales. La recolección de información se hizo por medio de uncuestionario enviado a las personas que han estado involucradas en el uso de los métodos formalesen la construcción de sistemas. La recopilación de información se dio entre Noviembre del 2007 aDiciembre del 2008; a través de esta encuesta se puede apreciar que la aplicabilidad de los métodosformales no sólo es en el campo de la ingeniería, sino también, en las �nanzas, salud, defensa, entreotros.

Los grupos de investigación de VERIMAG, que es un centro de investigación líder en sistemasembebidos, han propuesto un lenguaje intermedio para traducir modelos escritos en SDL y UMLpara veri�car los mismos usando la técnica de Model Checking. En la literatura encontramos dis-tintos trabajos de grado [BP06, PT06] que han probado la herramienta de IFx para veri�car quealgunas propiedades se mantienen en el modelo. En [BP06] usaron IFx sobre un sistema de telefoníamóvil, como caso de estudio, donde se veri�caron algunas propiedades como: la consistencia del tipode llamada que asigna el sistema con el tipo de llamada que obtiene el usuario. En [PT06] hacenuso de la herramienta IFx para veri�car un controlador de semáforos que está descrito en UML, lapropiedad que desean probar es: �Se busca sí en un momento dado dos semáforos están en verde óuno en verde y otro en ámbar�. Lo anterior representa un estado no deseado del sistema; lo que se

8 Capítulo 2. Marco de Referencia

concluye es que a través de la herramienta IFx se pudo determinar la falla del modelo.

En [VVBK05] hacen uso de los métodos formales para veri�car propiedades en un caso deestudio referente a redes de comunicación. El modelado del sistema se hizo por medio de SDL y laveri�cación formal fue a través de la técnica de Model Checking; se tradujo el modelo de SDL a IFpor medio de la herramienta SDL2IF, con el �n de obtener un sistema en un lenguaje al que se lepuede aplicar algún model checker.

En [GJ01] plantean y desarrollan un experimento para la veri�cación de la capa de controldinámica del protocolo MASCARA (Mobile Access Scheme based on Contention And Reservationfor ATM). Hacen uso de diferentes técnicas de reducción del sistema, con el objetivo de optimizarel modelo y por ende el tiempo de respuesta usando la técnica de Model Checking. La forma dediseñar las propiedades a veri�car fue de manera incremental, donde se empezaba con propiedadessencillas y se terminó veri�cando la capa de control dinámica del protocolo MASCARA.

En [Mar03] se escogió un bloque del Software de enrutamiento telefónico desarrollado en AlcatelNetwork Systems Romania, para veri�car algunas propiedades. Dicho bloque es el encargado derealizar el tipo de diálogo apropiado dependiendo de los parámetros de los mensajes de inicio ysubsecuentes. El bloque cuenta con dos interfaces: una upstream para el que llama y una downstreampara el servidor. En este caso de estudio hacen uso de IF como lenguaje intermedio para aplicar latécnica de Model Checking y veri�car básicamente cuatro propiedades las cuales son: DeadLocks,Progreso, Abortar y Cierre.

Con respecto a las pruebas funcionales de caja negra usando el lenguaje TTCN-3 encontramosestudios referente al diseño de casos de pruebas a partir de modelos expresados por medio de SDL yMSC. En [Ebn04] proponen una traducción de elementos de MSC a lenguaje de pruebas TTCN-3, eneste artículo de�nen una nueva semántica de MSC para permitir distintas especi�caciones de casosde prueba en TTCN-3 que pueden ser concurrentes o no. En [WDT+11] hay una breve descripciónde cómo el lenguaje TTCN-3 ha sido usado para diseñar pruebas al último estándar de sistemasde comunicaciones móviles conocido como LTE. Se destacan los campos de acción en los cuales ellenguaje TTCN-3 está siendo usado, entre estos encontramos [Sch10]: sector automovilístico, equiposmédicos, distribución y transmisión de potencia, Finanzas, Aviación, Ferrocarriles.

Este trabajo de grado pretende hacer uso de una metodología que combina dos técnicas, que sonel model checking y las pruebas, para la minimización de errores en el diseño de sistemas descritosen SDL y pretende veri�car algunas propiedades de algunos de sus módulos haciendo uso de latécnica de Model Checking. Adicionalmente, se desea hacer pruebas funcionales de caja negra pormedio del uso del lenguaje TTCN-3 en las primeras etapas del desarrollo del sistema.

2.2. Marco Teórico

En esta subsección se introducen conceptos pertinentes al desarrollo del trabajo de grado, ademásse ha subdividido en tres grandes partes: La primera corresponde a los conceptos del Modelado desistemas; en este caso se hace referencia a la estructura y características que posee el lenguajeSDL (Speci�cation and Description Language). En la segunda parte se de�nen algunos términosde las pruebas funcionales de caja negra, y se enfatiza en la estructura y característica que brinda

2.2. Marco Teórico 9

el lenguaje Testing and Test Control Notation version 3 conocido por sus siglas como TTCN-3 para dicha fase; por último, en la tercera parte se de�nen algunos conceptos referentes a laveri�cación formal de sistemas y se hace énfasis en la herramienta que se va a usar, IFx, de�niendosus características.

2.2.1. Lenguaje para la Especi�cación y Descripción de Sistemas Distribuidos

El uso de un modelo o especi�cación formal disminuyen los errores dentro del desarrollo delsistema [HKL+09]. Especi�car un sistema por medio de lenguajes formales tiene muchas ventajasentre las cuales encontramos:

Obtener un modelo que tenga una especi�cación y descripción clara y concisa del sistema.

Es posible automatizar la fase de pruebas, con el �n de hacerlas más dinámicas buscando elcorrecto funcionamiento del sistema.

Los sistemas son expresados bajo lenguajes basados en matemática, lo que ayuda a la cons-trucción de sistemas de alta calidad [HKL+09].

Es posible usar métodos de veri�cación formal para la detección y corrección de errores.

Permite ahorrar mucho tiempo/esfuerzo determinando dónde se originan los errores del siste-ma.

Dentro de los lenguajes que permiten expresar sistemas se encuentra SDL, el cual posee unascaracterísticas atractivas para representar sistemas reactivos1, entre las cuales se destaca representarsistemas con múltiples agentes a través de máquinas de estados �nitas extendidas.

A continuación se de�nirán algunas estructuras que posee dicho lenguaje, de�nidas por la reco-mendación Z.100 de la ITU-T [IT02]:

2.2.1.1. De�niciones en SDL

Agent (Agente): Es usado para denotar un sistema, bloque o proceso que contiene una o másmáquinas de estados �nitas extendidas.

Block (Bloque): Un bloque es un agente que puede contener uno o más bloques o procesosparalelos, y podría también contener una o varias máquinas de estados �nitos extendidas queposeen y manejan datos dentro del bloque.

Channel (Canal): Un canal es un camino de comunicación entre dos agentes.

Environment (Ambiente): El ambiente es el entorno en el que se desempeña el sistema.

1Sistemas reactivos: Son aquellos sistemas que generan una salida a partir de un estímulo externo que proviene

del ambiente.


El tipo PID es usado cuando los elementos de datos son referenciados a un agente. Existencuatro variables de tipo PID bien de�nidas en SDL las cuales son:

• SELF: Es el identi�cador de proceso de la instancia actual.

• SENDER: Es el identi�cador de proceso que envió la última señal.

• PARENT: Es el identi�cador de proceso que creó la última instancia.

• OFFSPRING: Es el identi�cador de proceso de la última instancia creada.

Procedure (Procedimiento): Un procedimiento es una encapsulación de una parte del com-portamiento de un agente, que puede ser usado en diferentes partes dentro del mismo. Otrosagentes puedan hacer llamados a un procedimiento remoto.

Signal (Señal): La principal manera de comunicación es por medio de señales que son salidasdel agente emisor y entradas al agente receptor.

State (Estado): Una máquina de estados �nita extendida de un agente está en un estado sieste está esperando por un estímulo.

Stimulus (Estímulo): Un estímulo es un evento que puede causar que un agente que está enun estado ejecute una transición.

System (Sistema): Un sistema es el agente más exterior que se comunica con el ambiente.

Timer (Temporizador): Un temporizador es un objeto de propiedad de un agente que causauna señal de estímulo cuando éste alcanza un determinado tiempo.

Transition (Transición): Una transición es una secuencia de acciones que un agente realizahasta que éste ingresa a un estado.

Type/Sort (Tipo): Un tipo es un conjunto de elementos que posee características en comúncuya de�nición puede ser usada para la creación de otras instancias; también se pueden formarotros tipos.

Value (Valor): El término valor es usado para la clase de datos que son accesados directamente.Los valores pueden ser pasados con libertad entre agentes.

2.2.1.2. Notación de SDL

En SDL existen dos notaciones las cuales son:

SDL/GR Representación grá�ca de SDL (En inglés: Graphic Representation form of SDL)

• Provee elementos grá�cos para los conceptos más importantes del lenguaje.

• Tiene una notación textual para aquellos elementos que no es apropiado representarlosgrá�camente.


SDL/PR Representación textual de SDL ( En inglés: Textual Phrase Representation form ofSDL)

• Usado principalmente para el desarrollo de compiladores.

La recomendación de la ITU-T Z.100 enfatiza en la representación grá�ca de SDL. Además elsoftware a usar en la fase de modelado del caso de estudio brinda la posibilidad de usar SDL/GR.

La Figura 2.1 es un ejemplo para mostrar la diferencia entre las notaciones SDL/GR y SDL/PR:

Figura 2.1: Ejemplo comparación representación grá�ca y textual en SDL. Fuente http://www.

sdl-forum.org/sdl2000present/sld006.htm

A partir de este momento los ejemplos relacionados con el modelado de sistemas se harán pormedio de componentes grá�cos.

2.2.1.3. Requerimientos de especi�cación usando Message Sequence Charts (MSC)

En el desarrollo de sistemas Hardware/Software encontramos diferentes etapas en las cuales esnecesario plantear un requerimiento de especi�cación clara y concisa, con el �n de elaborar el diseñodel mismo. Message Sequence Charts (MSC)2 es un lenguaje textual y grá�co que permite expresarrequerimientos de especi�caciones, simulación y validación, además de describir el comportamientode comunicación entre las entidades del sistema y el ambiente [Ebn04]. Actualmente existe unarelación directa entre la especi�cación realizada en un diagrama MSC y SDL, que facilita la partede diseño del modelo.

Las Figuras 2.2 y 2.3 muestran un ejemplo de la relación MSC-SDL.

2Información consultada el 20 de Mayo del 2014 en el siguiente sitio: http://www.sdl-forum.org/MSC/index.htm.

http://www.sdl-forum.org/sdl2000present/sld006.htm

http://www.sdl-forum.org/sdl2000present/sld006.htm

http://www.sdl-forum.org/MSC/index.htm.


Figura 2.2: Diagrama MSC interacción entre cuatro procesos. Fuente [Ren99]

Figura 2.3: Diseño en SDL de la especi�cación en MSC. Fuente [Ren99]

2.2.2. Software de Pruebas

2.2.2.1. Terminología de Pruebas

Una prueba es un conjunto de actividades que tiene como objetivo identi�car fallas en un sistemay evaluar su nivel de calidad, para obtener la satisfacción del usuario. Esto es un conjunto de tareascon metas claramente de�nidas [Hom13].

De acuerdo al estándar ANSI/IEEE 1059 una prueba se puede de�nir como: Un proceso deanálisis de un elemento de software para detectar las diferencias entre las condiciones existentesy requeridas (es decir defectos / errores / fallos) y para evaluar las características del elementosoftware [IEE94].

Las pruebas pueden ser estáticas o dinámicas. Las primeras, prueban el componente o el sistemaa nivel de especi�cación o de implementación sin tener que ejecutar éste [AO08, Hom13, ISO13].En las pruebas dinámicas, el componente o sistema está en ejecución y se estimula con entradasreales [AO08, Hom13].

La técnica de diseño de pruebas dinámicas permite identi�car las condiciones de la prueba; adi-cionalmente ésta se clasi�ca dentro de tres categorías, basadas en cómo son derivadas las entradasde las pruebas [ISO13]. Esas categorías son: Basada en la especi�cación, que consiste en proveer loscasos de prueba desde una base de prueba describiendo el comportamiento esperado del elementoa probar [ISO13]; la segunda categoría está basada en la estructura, que consiste en derivar loscasos de prueba desde una característica estructural, por ejemplo la estructura de un código fuen-te [ISO13]. Finalmente la tercera categoría corresponde a las pruebas basadas en la experiencia, que


se basa en un conocimiento previo, bien sea en un sistema en particular o en métricas de proyectosprevios [Hom13].

Mayoritariamente se emplean dos métodos de pruebas que son: Caja Negra (En inglés: Black-Box) y Caja blanca (En inglés: White-Box). El método de caja negra está basado en los reque-rimientos y especi�caciones para determinar si el modelo es correcto o no [Hom13, AO08]; unacaracterística importante de éste método es que no es necesario conocer el sistema interno. Por elcontrario, el método de caja blanca hace parte de la categoría basada en la estructura: el caso deprueba se deriva desde el código fuente interno del modelo [AO08]; la hipótesis fundamental consisteen que el modelo cumple con los requerimientos del cliente.

Los tipos de integración de pruebas son principalmente dos: De abajo hacia arriba (Bottom-up)y de arriba hacia abajo (Top-Down). La primera consiste en diseñar pruebas que empiecen desdelos niveles más �nos del sistema a los niveles más altos; la integración Top-Down consiste en diseñarpruebas desde los niveles más altos del sistema a los más �nos.

2.2.2.2. TTCN-3 (Testing and Test Control Notation Version 3)

Para minimizar errores en los sistemas es necesario usar diferentes técnicas que permitan cum-plir esta meta; por ejemplo, es útil realizar las pruebas funcionales de caja negra para probar elcorrecto funcionamiento en las primeras etapas del desarrollo del sistema. El presente trabajo degrado pretende usar las pruebas funcionales de caja negra en algunos módulos del caso de estudiohaciendo uso del lenguaje TTCN-3. Parte del modelo arquitectónico de TTCN-3 está soportado porla herramienta RTDS.

Testing and Test Control Notation Version 3, más conocido por sus siglas en inglés como TTCN-3 es un lenguaje de especi�cación e implementación de pruebas de tipo caja negra para sistemasdistribuidos y reactivos [GHR+03]. TTCN-3 se ha construido desde un núcleo de lenguaje textual queposibilita la interacción con otros lenguajes de descripción, por ejemplo SDL [GHR+03, WDT+11].Una de las características que presenta TTCN-3 es que su sintaxis textual es similar a lenguajestípicos de programación, por ejemplo: C, C++ o Java.

2.2.2.3. Conceptos Básicos de TTCN-3

System Under Test SUT (Sistema Bajo Prueba): Es el sistema el cual se va a someter apruebas.

Module (Módulo): Es donde está recopilado el código TTCN-3 y se encuentra conformadopor: Una parte de de�niciones y una parte de control [WDT+11].

Module de�nitions part (Parte de de�niciones): Especi�ca las de�niciones en el nivel superiordel módulo; éstas pueden ser usadas en cualquier parte incluso en la parte de control.

Module control part (Parte de control): Es la parte principal del programa de TTCN-3; enesta parte se describe la secuencia de la ejecución de los casos de prueba (Test cases).


Test Cases (Casos de Prueba): Los casos de prueba son especi�cados en la parte de las de�ni-ciones del módulo y son llamados en la parte de control. Un caso de prueba de�ne el compor-tamiento que es ejecutado con el �n de observar si el sistema pasa la prueba o no [GHR+03].

Test System (Sistema de Prueba): Ejecuta un caso de prueba y está conformado por unconjunto de componentes de prueba interconectados con unos puertos de comunicación biende�nidos y una explícita interfaz de sistema de prueba (en inglés: Test System Interface,TSI) [GHR+03].

Test Component (Componente de prueba): Ejecuta los casos de prueba (Test cases) [GHR+03].

Main Test Component MTC (Componente de prueba principal): La función principal es de-terminar a través de los resultados de los componentes de prueba si ésta pasa o no.

Verdict (Veredicto): Es una variable implícita que corresponde al resultado de la prueba.

Matching mechanism (Mecanismo de Coincidencia): TTCN-3 tiene integrado un mecanismode coincidencia que permite evaluar si el sistema satisface ciertas condiciones, de�nidas en loscasos de prueba. En TTCN-3 encontramos los siguientes valores para el veredicto:

• Pass: Signi�ca que el SUT se comportó de acuerdo al propósito de la prueba.

• Inconc: Signi�ca que no se puede determinar si el SUT pasó o falló la prueba.

• Fail: Indica que el SUT no cumplió con el propósito de la prueba.

• Error: Esta asignación la hace el ambiente de ejecución de TTCN-3 cuando hay fallas enel componente de pruebas o en el SUT.

• None: Es el valor inicial, cuando el veredicto no ha sido asignado.

Port (Puerto): Es el lugar donde los mensajes llegan o salen al componente de prueba. Unpuerto es modelado como una cola in�nita tipo FIFO.

Template (Plantilla): Son entidades en TTCN-3 usadas para describir el contenido de opera-ciones de comunicación. Poseen mecanismos de coincidencia para los mensajes de llegada y seomite en los mensajes de salida.

Alt-statement (Sentencia-Alt): Permite de�nir distintas operaciones de bloqueo, que permitenmanejar los mensajes entrantes y determinar si la prueba pasa o no.

Comunicación: Se re�ere al intercambio de señales entre componentes o con el SUT. La co-municación pueden ser basada en mensajes o basada en procedimientos.

Comunicación basada en mensajes: Se intercambian mensajes con el SUT a través de dosoperaciones: send y receive. La operación send transmite un mensaje al SUT a través de unpuerto especí�co. La operación receive es una operación de bloqueo que tiene como �nali-dad comparar el mensaje entrante y procede a determinar si coincide con el esperado,paradeterminar si la prueba pasa o no.


2.2.2.4. Modelo Arquitectónico del Sistema de Prueba en TTCN-3

La Figura 2.4 representa la arquitectura general del lenguaje de TTCN-3. De manera generallos adaptadores en TTCN-3 (TTCN-3 Adapters) están conformados por un adaptador de sistema yuno de plataforma que sirven para implementar funciones externas y adaptar los mensajes al SUT.Por otra parte en la capa del ejecutable de TTCN-3 (TTCN-3 Executable) se encuentran compo-nentes de manejo (Component Handling), codi�cación y decodi�cación (Codecs), y un ejecutablede TTCN-3. Todo esto sirve para: La distribución y comunicación entre componentes de prueba enparalelo, la transformación de mensajes a un formato entendible por TTCN-3, y la representacióndel comportamiento especí�co en el nivel de TTCN-3, respectivamente. Finalmente en el Controly Administración de pruebas (Test Management and Control) se encuentran un Administrador depruebas (Test Management) y una parte para el registro de eventos de prueba (Test Logging) quesirven para: proveer control sobre el orden de ejecución de los casos de pruebas, y para el manejode registro de sistema de prueba, respectivamente.

Figura 2.4: Modelo arquitectónico simpli�cado de TTCN-3. Fuente [AR11]

La herramienta RTDS soporta parcialmente la interfaz de control de TTCN-3 (TCI). Adicional-mente la interfaz TSI (Test System Interface) es proporcionada por la herramienta cuando la pruebase va hacer sobre un sistema descrito en SDL. El diseño de prueba del caso de estudio se hará deforma secuencial para los módulos más �nos del sistema, con el objetivo de garantizar su correctofuncionamiento; por lo tanto, no es de interés en este trabajo de grado implementar componentesparalelos de pruebas, lo que implica no hacer uso del componente de manejo (Component Handling).Adicionalmente, se aprovechará que la herramienta RTDS proporciona implícitamente una interfazpara la comunicación con un SUT descrito en SDL; por lo tanto, tampoco es de interés hacer usode adaptadores para la realización de pruebas al sistema.

2.2.3. Veri�cación Formal

2.2.3.1. Métodos Formales

Los métodos formales según [CW96] son lenguajes, técnicas y herramientas basados en estruc-turas matemáticas con el objetivo de especi�car y veri�car sistemas. El uso de formalismos en laveri�cación de sistemas no garantiza que estos estén libres de errores, pero brinda la posibilidad de


expresar modelos sin ambigüedades y con un mejor entendimiento.Dentro de los Métodos formales se encuentra la especi�cación formal de sistemas que consiste

en expresar por medio de estructuras de lógica matemática las propiedades deseadas, eliminandoambigüedades que inducen errores en el diseño [CW96]. La especi�cación formal es una descripciónclara y concisa del comportamiento de alto nivel y/o de las propiedades del sistema [Kro99]. Porotra parte los métodos formales también son usados para veri�car si el sistema modelado satisfaceciertas propiedades, que en muchos casos deben de cumplir los sistemas críticos [CW96].

2.2.3.2. Veri�cación Formal de Hardware

La veri�cación de hardware es la demostración que un circuito o un sistema (Nivel de implemen-tación) se comporta de acuerdo a un conjunto de requerimientos (Nivel de especi�cación) [Kro99].La veri�cación formal es contraria a la simulación, en el sentido que no es necesario crear un con-junto de estímulos al sistema para garantizar su comportamiento. La simulación es un método pocopráctico, debido a que es casi imposible lograr estimular el circuito o el sistema con todas las posiblesentradas que va a tener durante su funcionamiento.

Como se muestra en el �ujo de diseño usando veri�cación en la Figura 2.5, encontramos quepara la veri�cación de sistemas es necesario que el sistema sea especi�cado de manera rigurosa(System speci�cation). Una vez de�nido el sistema a través de lenguajes con una semántica formal,se de�nen las propiedades que se desea veri�car. Paralelo a la de�nición de las propiedades se puedeefectuar el proceso de diseño (Design Process) hasta obtener un producto o prototipo (product orprototype) del sistema deseado. Finalmente, se veri�ca a través de métodos formales que el prototiposatisface las propiedades de�nidas anteriormente, dando como resultado un éxito o fallas por mediode contraejemplos [VVBK05], como lo hace la técnica del Model Checking.

Figura 2.5: Vista general de un sistema de veri�cación. Fuente: [BK08, p. 3]

El �ujo de diseño usando veri�cación mostrado anteriormente no está diseñado estrictamentepara sistemas Hardware, sino que también puede ser usado en desarrollo de Hardware/Software.


2.2.3.3. Model Checking

Model Checking es una técnica automática [VVBK05] de veri�cación formal que depende de laconstrucción de un modelo �nito del sistema y veri�ca si una propiedad deseada se satisface en dichomodelo [CW96]. La exploración de todos los posibles estados del sistema se da de forma exhaustiva.Esta técnica permite mostrar a través de contraejemplos los errores del modelo, describiendo elcamino desde el estado inicial del sistema al estado que viola la propiedad que está siendo veri�cada,lo que facilita la depuración de fallas en el diseño del sistema [BK08, VVBK05].

A continuación se describe el proceso del Model Checking de una forma general [BK08]:

Fase de Modelado (Modelling Phase):

• Modelar el sistema por medio de un lenguaje que el Model Checker pueda manejar.

• Evaluar rápidamente el modelo a través de simulaciones para eliminar fallas básicas delmodelo.

• Especi�car la propiedad que se desea veri�car en el modelo por medio de un lenguaje deespeci�cación.

Fase de ejecución (Running phase): En esta fase se ejecuta el model checker para veri�car siel modelo satisface la propiedad.

Fase de análisis (Analysis phase):

• Si se cumplió la propiedad se continúa veri�cando las otras en caso de haber más.

• Si la propiedad no se cumplió:

1. Analizar el modelo con el contraejemplo generado por el model checker.

2. Re�nar el modelo, diseño o propiedad.

3. Repetir el procedimiento para veri�car nuevamente la propiedad.

• Si se quedó corto de memoria: Intentar reducir el modelo e intentar nuevamente.

2.2.3.4. Herramienta IFx

La herramienta IFx fue desarrollada por investigadores de Verimag en Francia. Esta herramientaes un ambiente para el modelado, validación y veri�cación de sistemas [BGI+04].

La herramienta IFx posee características que proveen grandes ventajas a los diseñadores desistemas tales como:

Soporta modelado de alto nivel con formalismos tales como SDL y UML.

Permite trasladar modelos de alto nivel a un formato intermedio expresado en IF.

El modelo semántico de IF posee una representación rica y su�cientemente expresiva parapermitir describir los conceptos básicos y estructura del lenguaje fuente.


IF es una representación intermedia basada en un Autómata temporizado extendido, convariables de datos discretas, comunicación primitiva y creación y destrucción dinámica deprocesos.

IF permite la simpli�cación de modelos, lo que permite optimizarlo para poder ser veri�cadopor medio de la técnica Model Checking.

La propiedad que se desea veri�car se puede expresar usando un observador (observer) que sepuede clasi�car como: pure (puro), cut (Poda) o intrusive (intrusivo).

La Figura 2.6 representa la arquitectura IFx3:

Figura 2.6: Arquitectura de la Herramienta IFx. Tomada de [BGI+04]

El propósito de este trabajo de grado es hacer uso de esta herramienta y no es de interés mostrarla interacción de cada componente de dicha herramienta. Para saber más respecto de su estructuray semántica referirse a [BGI+04].

2.2.3.5. Conceptos básicos de IFx

Process (Proceso): Un proceso describe el comportamiento secuencial incluyendo transforma-ción de datos, comunicación y creación de procesos. Un proceso se de�ne como un autómatatemporizado, que tiene un identi�cador único conocido como pid y una memoria local consis-tiendo de: variables, control de estados y una cola de mensajes que han llegado y no han sidoconsumidos. Para cada instancia de un proceso en SDL la herramienta IFx crea un procesoIF.

3Página o�cial de la herramienta IF: http://www-if.imag.fr/index.html

http://www-if.imag.fr/index.html


Variables (variables): Cada variable/timer que se declara en SDL es traducido al correspon-diente proceso IF.

States (Estados): Todos los estados del modelo en SDL, incluidos los de start y stop, sontraducidos dentro de un control de estados estable de IF (stable IF Control States). Cadadecisión en SDL se traduce en un estado inestable (non stable IF state).

Transitions (Transiciones): Las transiciones de�nen el camino entre dos estados de control deIF; pueden ser de tres tipos: eager (impaciente) aquí las transiciones tienen absoluta prioridadsobre el progreso del tiempo, delayable (retardable) pueden permitir el progreso de tiempomientras está habilitada esta transición, lazy (perezoso) no evita el progreso del tiempo.

Observers (Observadores): Los observadores permiten de�nir la propiedad deseada a veri�car.En IF podemos de�nir tres tipos de observadores los cuales son [BGI+04]:

• Pure (Puro): Expresan los requerimientos para ser veri�cados en el sistema.

• Cut (Poda): Adicionalmente al observador pure, este permite guiar la simulación hacia undeterminado camino de ejecución, ayudando a restringir el comportamiento del ambiente.

• Intrusive (Intrusivo): Este observador es el más completo de todos, dado que permitemanipular el sistema enviando señales y cambiando variables.

Capítulo 3

Caso de Estudio del Proyecto de Grado

El sistema de parqueo de la Ponti�ca Universidad Javeriana Cali (PUJC) ha sido seleccionadocomo el caso de estudio para realizar conjuntamente veri�caciones formales y pruebas, con el �n dedetectar y minimizar los errores en el diseño de un sistema distribuido.

La Figura 3.1 muestra el sistema de parqueo de vehículos de la PUJC, el cual cuenta con lassiguientes características:

a. Por lo menos con una entrada y una salida principal, que para este caso se encuentran ubicadassobre la Avenida Cañasgordas.

b. Cada entrada y salida principal cuenta con un sistema que permite identi�car las placas de loscarros, un lector de carnés y un sistema básico de sensores que permite detectar si un vehículoingresa o sale del sistema de parqueo.

c. Un conjunto de zonas1 que están bajo el mando de un controlador; en la Figura 3.1 se muestran5 controladores del sistema de parqueo de la PUJC que son: Principal, Las Palmas, El Lago,Docentes y Los Almendros.

d. Las bases de datos donde se encuentran registrados tanto los usuarios que tienen permitido elacceso al sistema de parqueo como las placas de los vehículos asociados a cada usuario.

1Una zona es un área donde se pueden aparcar vehículos y cuenta con un sistema de sensores para determinar la

entrada y salida de los mismos.

22 Capítulo 3. Caso de Estudio del Proyecto de Grado

Prin

cipa

l

Las Palmas

El L

ago

Los

Alm

endr

osS

S

S

S

S

S

Docentes

SS

S

S

SS

S

S

S

S

S

S

S

S

S

S

S

S

SS

S

S

Ent

rad

a P

rinci

pal

Sal

ida

Prin

cipa

l

Con

trol

ador

de

zon

a

Zon

a

SS

enso

res

para

det

ecta

r el

ingr

eso

o sa

lida

de

vehí

culo

Figura 3.1: Sistema de Parqueo de la PUJC

23

La Tabla 3.1 muestra básicamente 5 controladores de zonas que son:

Tabla 3.1: Controladores del sistema de parqueo de la PUJC.Controlador # Zonas de ParqueoPrincipal 6Docentes 1Las Palmas 3El Lago 2

Los Almendros 1

La Figura 3.2 ilustra esquemáticamente los componentes del sistema de parqueo de la PUJC.Básicamente un sistema de parqueo de vehículos cuenta con C controladores de zonas que a su vezpueden tener hasta Z zonas; éstas últimas poseen un sistema de sensores capaces de informar asu controlador si un vehículo ingresó o salió de dicha zona. Adicionalmente, el sistema puede tenerhasta E entradas y S salidas principales.

SistemaTdeTParqueaderosTPUJ-Cali

BasesTdeTDatos

SalidaTPrincipal(1,S) EntradaTPrincipal(1,E)

ControladorTdeTZonasT(1,C) ControladorTdeTZonasT(C,C)

SS Camara

LectorTTarjeta

SE Camara

LectorTTarjeta

S S...Zona(1,Z) Zona(Z,Z)

S S...Zona(1,Z) Zona(Z,Z)...

Figura 3.2: Componentes del Sistema de Parqueo de la PUJC.

Acceso de usuarios al sistema de parqueo. Para garantizar que al sistema sólo ingresenusuarios registrados (estudiantes, docentes, personal administrativo, colaboradores, etc.), es indis-pensable contar con elementos que permitan cumplir dicho objetivo. Por esto, el sistema está dise-ñado para que cada entrada y salida principal cuente con una cámara, cuyo propósito es capturar


la placa del vehículo que va a ingresar o salir del sistema. Igualmente, se considera tener un lectorde carnés que permita validar si el usuario efectivamente está registrado en el sistema; �nalmentese requiere un conjunto de sensores que identi�quen la entrada y salida de vehículos al sistema.En el momento que una persona desee ingresar al sistema de parqueo de la PUJC y ésta no estéregistrada en las bases de datos, el guarda de seguridad le hará entrega de un comprobante físicopara que por medio de éste pueda salir del sistema de parqueo; lo anterior podría servir para crearun registro de las placas de los vehículos que han ingresado.

El sistema de parqueo está diseñado de manera genérica de forma que pueda crecer acorde a lasnecesidades concretas. La Tabla 3.2 describe la funcionalidad que posee el sistema de parqueo y eltipo de usuario que está a cargo de realizar cada una de las funciones que la componen.

Tabla 3.2: Funcionalidad del sistema de parqueo.

Función Descripción de la función Agente

CrearControlador de

Zona

Permite crear en el sistema máscontroladores y a su vez una mayorcapacidad de zonas, lo que se traduce enpoder aparcar más vehículos.

ADMINISTRADOR

Crear una Zonaen un

ControladorEspecí�co

Permite anexar una zona en un controladorespecí�co ampliando la capacidad de ésteúltimo.

ADMINISTRADOR

Crear unaEntrada o Salida

principal

Permite crear en el sistema más entradas ysalidas para el acceso de vehículos al sistemade parqueo.

ADMINISTRADOR

Solicitarinformación a loscontroladores de

zona

Permite saber las plazas libres que poseecada uno de los controladores, lo queposibilita que el usuario sepa en quécontrolador y en qué zona hay espacio paraaparcar.

ADMINISTRA-DOR/AUTOGESTIÓNDEL SISTEMA

Inicializar elnúmero de plazastotales y libres deuna zona de uncontrolador en

especí�co

Permite inicializar el número de plazastotales y libres de una zona de uncontrolador en especí�co, posibilitando tenerzonas de diferentes capacidades.

ADMINISTRADOR

Reportar ingresoo salida de un

usuario al sistemade parqueo

Reporta si un usuario ha ingresado alsistema de parqueo sí y sólo sí: El código delusuario y la placa de su vehículo seencuentran registrados en la base de datosdel sistema de parqueo.

SISTEMA

Continúa en la página siguiente.

3.1. Modelado 25

Función Descripción de la función AgenteReportar el

ingreso o salidade un usuario en

una zona

Reporta si un vehículo ha ingresado o hadejado una zona cuando se detecte unasecuencia especí�ca en los sensores de lazona.

SISTEMA

3.1. Modelado

El modelado del comportamiento global del sistema se realizó usando MSCs y el modelo detalladode cada componente del sistema de parqueo se desarrolló usando el lenguaje SDL, ambos sobre laherramienta RTDS. Cabe aclarar que el modelo del sistema para el caso de estudio se desarrolló apartir de las funcionalidades genéricas descritas en la Tabla 3.2.

La arquitectura del sistema se divide en dos grandes bloques denominados ParkingLotSystem yUnmodeledProcesses, y estos a su vez se dividen en más bloques y procesos. La Figura 3.3, detallala arquitectura general del sistema de parqueo de la PUJC2.

System

ParkingLotSystem UnmodeledProcesses

pCreatorCardReaderNCamera(1,1)

pCamera(2,N)

pTesting(1,1)pMainSystemManager(1,1)

pCtrl(1,C) pZone(1,Z) pCreatorZoneManager(1,1)

BZone BEntryNOut_WayBCtrlZoneBMainSystemManager

pDataBase(1,1)

pCardReader(2,N)

pCreatorEntryNOut(1,1)

pEntryNOut_Way(2,N)

pZoneManager(1,C)

pCtrlManager(1,1)

Figura 3.3: Arquitectura del modelo del sistema de parqueo de la PUJC

Como se aprecia en la Figura 3.3, el primer bloque, ParkingLotSystem, está conformado por losprocesos y elementos que se han modelado con un mayor nivel de detalle; por el contrario, en elsegundo bloque se encuentran los elementos del sistema que no se han modelado sino que se hanconsiderado como procesos simples, los cuales reciben un valor y retornan otro pero sin realizar unprocesamiento especí�co de los datos, dado que no es de interés del proyecto modelarlos.

2El diseño del sistema en SDL se puede encontrar en el siguiente enlace: https://drive.google.com/file/d/

0BzIxvP1MSS74VEFVbmpCd0UyVE0/view

https://drive.google.com/file/d/0BzIxvP1MSS74VEFVbmpCd0UyVE0/view

https://drive.google.com/file/d/0BzIxvP1MSS74VEFVbmpCd0UyVE0/view


La Tabla 3.3 describen las funciones generales de cada bloque.

Tabla 3.3: Descripción de los bloques del sistema de parqueo

Bloques Sub-bloques Propósito/Función

UnmodeledPro-cesses

-En este bloque tiene lugar la validación deusuarios permitidos para ingresar o salir delsistema de parqueo.

ParkingLotSys-tem

BMainSystemMana-ger

Este bloque interactúa principalmente con elAdministrador, con el propósito de caracterizar elsistema de parqueo. Por ejemplo: Crearcontroladores de zonas, zonas, entradas y salidasprincipales, etc.

ParkingLotSys-tem

BCtrlZone

Interactúa básicamente con los bloquesBMainSystemManager y BZone. Captura lainformación del conjunto de zonas asociadas a uncontrolador y las reporta al bloqueBMainSystemManager cada vez que haya unrequerimiento de información.

ParkingLotSys-tem

BZone

Interactúa principalmente con el bloqueBCtrlZone y el usuario. Reporta el ingreso y salidade vehículos a partir de la información provenientede los sensores.

ParkingLotSys-tem

BEntryNOut_Way

Interactúa principalmente con los procesos delbloque UnmodeledProcesses y con el usuario. Enéste bloque se modela el ingreso y salida delusuario por las entradas y salidas principales,respectivamente.

Dentro de la arquitectura del sistema de parqueo presentada en la Figura 3.3, se observan algunosprocesos que tienen como función crear instancias de otros procesos, con el objetivo de hacer que elsistema de parqueo sea escalable de manera sencilla.

Creación de procesos en diferentes bloques. En términos del lenguaje, dado que la arqui-tectura del sistema de parqueo se compone de bloques, no es posible crear dinámicamente instanciasde procesos que se encuentren en otro bloque. Lo anterior implica tener procesos que sólo sirvanpara crear otros que se encuentren en su mismo bloque.

La Tabla 3.4 describe las funciones de los procesos del sistema de parqueo.

3.1. Modelado 27

Tabla 3.4: Descripción de los procesos del sistema de parqueo

Nombre delproceso

Funciones

pDataBaseRepresenta las bases de datos del sistema, además está encargado deevaluar si un usuario está habilitado para ingresar o salir del sistema deparqueo.

pCardReaderRepresenta al lector de carnés y se encarga de entregar el código delusuario que está por ingresar o salir del sistema de parqueo.

pCameraRepresenta la cámara que captura la placa del vehículo y la entrega alsistema con el �n de evaluar si el usuario está habilitado para ingresaro salir del sistema.

pCreatorCar-dReaderNCamera

Proceso encargado de crear los procesos pCardReader y pCamera, yasignarlos a su respectivo proceso pEntryNOut_Way.

pEntry-NOut_Way

Representa una entrada o salida principal, es el encargado de permitirel paso del usuario al sistema de parqueo. Adicionalmente es el únicoproceso que interactúa con los procesos pDataBase, pCardReader,pCamera y pCreatorCardReaderNCamera.

pCreatorEntry-NOut_Way

Encargado de crear el proceso pEntryNOut_Way.

pZoneRepresenta una zona del sistema e interactúa con el controlador dezonas reportando el ingreso o salida de un vehículo, dependiendo de lasecuencia de señales del conjunto de sensores que se reciba.

pZoneManagerEncargado de crear instancias del proceso pZone y a su vez asignarle surespectivo proceso pCtrl.

pCreatorZoneMa-nager

Encargado de crear los procesos pZoneManager y asignarle a éste surespectivo controlador de zonas.

pCtrlRepresenta un controlador de zonas y está encargado de controlar losprocesos pZone; adicionalmente reporta el estado de las plazas libres ytotales que posee cada zona.

pCtrlManager Encargado de crear los procesos pCtrl.

pMainSystemMa-nager

Representa la interfaz directa entre el administrador y el sistema. Através de este proceso se pueden crear entradas y salidas principales,controladores de zona, zonas, hacer requerimientos de información,inicializar tanto plazas libres como totales.

pTestingPermite acoplar el sistema para hacer pruebas funcionales de cajanegra. Este proceso no debe ser considerado en la fase deimplementación del sistema de parqueo.


3.1.1. Especi�cación Usando MSC

El modelado del sistema de parqueo inicia desde los requerimientos del sistema que se describenen la Tabla 3.2. La herramienta RTDS tiene la posibilidad de anexar al proyecto diagramas MSC;éstos son fundamentales para describir las especi�caciones del sistema.

Estrategias para la descripción de especi�caciones. Existen estrategias para la especi-�cación, diseño y desarrollo de modelos, entre las cuales encontramos Top-Down y Bottom-Up.Top-Down es una estrategia donde se inicia desarrollando el modelo desde un alto nivel con un altonivel de abstracción y termina en bloques o procesos con menores niveles de abstracción. Por elcontrario, Bottom-Up es una estrategia que consiste en empezar a diseñar los elementos del sistemadesde un nivel de abstracción bajo y a partir de éstos se construyen módulos más complejos.

En el presente trabajo, la estrategia Top-Down es usada para la especi�cación del sistema em-pleando diagramas MSC, y la metodología Botton-Up es usada para el diseño del sistema empleandoSDL.

3.1.1.1. MSCs de las Especi�caciones del Sistema

En el desarrollo de las especi�caciones del sistema de parqueo, se concluye que metodológica-mente es recomendable especi�car el sistema en alto nivel sin tener en cuenta los detalles de cadamódulo; para ello, se elaboró un MSC que tiene como �nalidad mostrar un escenario en el cual sedescriba la interacción de los dos bloques principales: ParkingLotSystem y UnmodeledProcesses. LaFigura 3.4 muestra dicha interacción, describiendo el escenario del acceso de un vehículo al sistemade parqueo.

Comportamiento entrada de vehículo al sistema de parqueo. En el MSC de la Figura3.4 encontramos tres agentes interactuando entre sí los cuales son: Env, ParkingLotSystem y Unmo-deledProcesses. El agente Env representa el ambiente por el cual el sistema intercambia mensajescon el usuario o con los sensores. El procedimiento que describe el acceso de un vehículo al sistemade parqueo de la PUJC representaba el comportamiento del sistema de parqueo de la PUJC. Elsistema dejó de funcionar correctamente cuando la compañía que diseñó e implementó dicho sistemano brindó más el soporte técnico. Dicho comportamiento está dado por la siguiente secuencia:

1. El proceso Env envía una señal al bloque ParkingLotSystem llamada sLoopInductive_Entranceque indica que un vehículo está ingresando por la entrada principal.

2. El bloque ParkingLotSystem veri�ca que el usuario que desea ingresar al sistema de parqueoestá autorizado. Para ello, necesita conocer su identi�cación y la placa del vehículo; con laseñal sEnableCarReader habilita el lector de carnés.

3. Una vez que el bloque ParkingLotSystem tiene el código del usuario, habilita la toma de la fotoa la placa, para ello intercambia el mensaje sRequestPlate con el bloque UnmodeledProcesses.

4. El bloque UnmodeledProcesses envía la placa como un charstring al bloque que hizo la con-sulta.

3.1. Modelado 29

Env ParkingLotSystem UnmodeledProcess

sPlate(plateRasRChastring)

sOkUser

sLoopInductive_Entrance

sRequestPlate

sCarPassedBarrier

sConfirmEntranceUser

sDownBarrier

sEnableCardReader

sDataUser(ID_UserRasRint)

sUpBarrier

Figura 3.4: MSC interacción entre los dos bloques ParkingLotSystem y UnmodeledProcesses

5. Una vez que se tenga la información del usuario es indispensable validarla y determinar si sele otorga el acceso al sistema. Para ello envía un requerimiento al bloque UnmodeledProcessesesperando la señal sOkUser que con�rma que el usuario está habilitado para usar el sistemade parqueo, o sNoRegis_User que indica que el usuario no tiene permitido usar el sistema deparqueo.

6. Si el usuario está habilitado para usar el sistema de parqueo entonces se efectúa una serie depasos para darle bienvenida al usuario: se envía una señal a la talanquera para que permitael paso del vehículo. Una vez que éste haya pasado, un sensor envía dicha señal indicandoque es seguro bajar la talanquera, y el bloque ParkingLotSystem culmina enviando la señalsDownBarrier, quedando así disponibles los dos bloques para interactuar nuevamente.

El escenario que representa la salida de un vehículo del sistema de parqueo de la PUJC es similaral comportamiento descrito en la Figura 3.4. La diferencia radica en que el agente Env o entornoenvía una señal sLoopInductive_Exit en lugar de sLoopInductive_Entrance cuando hay presenciade vehículo, y en el momento que el bloque ParkingLotSystem desea veri�car si el usuario estáautorizado para salir, envía una señal sCon�rmOutUser hacia el bloque UnmodeledProcesses.

De�nición de parámetros iniciales del sistema. En las Figuras 3.5 y 3.6 se describen losdiagramas MSCs de la inicialización del sistema cuando el administrador de�ne los parámetrosiniciales del sistema de parqueo.

La Figura 3.5 ilustra la interacción entre procesos del bloque ParkingLotSystem y del bloque


UnmodeledProcesses en la fase de inicialización; dicha relación es detallada a continuación:

El sistema debe tener por lo menos una entrada y una salida principal.

Cada entrada y salida principal debe tener una cámara la cual retorna el valor de la placa delvehículo a partir de una foto, un lector de carnés el cual retorna el identi�cador del usuario yun conjunto de sensores que garanticen que un vehículo puede ingresar o salir del sistema deparqueo.

El sistema tiene al menos una zona con su respectivo controlador. La zona cuenta con susrespectivos sensores para indicar si un vehículo ha ingresado o ha salido de dicha zona.

Cuenta con una base de datos donde se encuentran los códigos de los usuarios autorizados ysus placas asociadas para el acceso o salida del sistema de parqueo de la PUJC.

Inicialización de la entrada principal. El proceso pMainSystemManager se encarga de aso-ciar el proceso pEntryNOut_Way a su tabla de entradas principales; para ello envía una señalllamada sInitEntryWay_i al proceso pEntryNOut_Way. A partir de esta solicitud lo que va a pasares que éste proceso necesita que se le sea asignado un lector de carnés, que se representa como unproceso pCardReader, y una cámara, que se representa como un proceso pCamera. El proceso quetiene la facultad de crear estos procesos es pCreatorCardReaderNCamera; una vez éste haya creadoel lector de carnés y la cámara, enviará una señal al proceso pEntryNOut_Way con los identi�cado-res correspondientes. El proceso pMainSystemManager cuando reciba la señal sOkEntryWay1 porparte de pEntryNOut_Way anexará la nueva entrada principal a su lista de entradas principales.

3.1. Modelado 31

pCardReader

pCardReader

pMainSystemManager

pEntryWay

pEntryNOut_Way

pCreatorCardReaderNCamera

RTDS_start_process

pCreatorEntryNOut_Way

pCamera

pCamera

sOkCreateEntryNOut_Way(pid_E_OWay)

sOkInitEntryWay

sAssigned(pidCR,pidC)

sIamCamera(pidC)

sIamCamera(pidC)


sOkCreateOutWay(pid_OutWay)

sInitEntryWay_i

sIamCardReader(pidCR)

sCreateOutWay

sAssignCardReaderNCam



sOkEntryWay1

Idle

sWaitOkCreationOutWay

Idle

sOkEntryWay1

sWaitConfirmCamera

Idle

Idle

Idle

Idle

sOkCreation

Idle

sWaitAssigned_i

sWaitAssigned

Idle

Idle

Idle

Idle

Idle

sWaitConfirmCamera

Idle

sWaitConfirmCardReader

Idle

Idle


Figura 3.5: MSC de la inicialización entrada y salida principal del sistema


Para la creación de la salida principal, la interacción de los procesos es muy parecida a lainicialización de la primera entrada principal: sólo cambia que el proceso pMainSystemManagersolicita al agente pCreatorCardReaderNCamera crear un proceso pEntryNOut_Way y enviar laseñal correspondiente a este último para que se le sea asociado un lector de carnés y una cámara. Elproceso de inicialización termina cuando el proceso de creación de entradas y salidas principales envíaun mensaje al proceso pMainSystemManager llamado sOkCreateOutWay, asociando el identi�cadorde dicha salida principal para que sea anexado en su lista de salidas principales.

Inicialización procesos del bloque ParkingLotSystem. La Figura 3.6 describe la inicia-lización de los procesos del bloque ParkingLotSystem. El objetivo de esta interacción es asociar ala zona y al proceso pZoneManager su respectivo controlador. El sistema de parqueo cuenta concontroladores que tienen a su mando un conjunto de zonas y dado que el sistema es escalable di-námicamente, es posible que un controlador pueda tener más zonas. Sin embargo, debido a que elproceso pCtrl no se encuentra en el mismo bloque que pZone se necesita un proceso que sea capazde crear más zonas; para ello se requiere del proceso pZoneManager. Lo anterior implica que cadaproceso pCtrl tendrá asociado hasta Z zonas y un único proceso pZoneManager.

3.1. Modelado 33

pCreatorZoneManager

pCtrl

pTesting

pZone

pCtrlManager

pMainSystemManager

pZoneManager

RTDS_start_process

sIamZoneManager(pidZoneManager)

sOkInitPid

sOkCreationCtrl_i(infoCtrl)

sReqInfo

sInitialConnection

sConfirmZoneManager_i(pidCtrl)

sInfoZone(totalSpots,freeSpots)

sInitPidCtrl(pidCtrl)

Idle

Idle

Idle

sWaitConfirmInitPid

Idle

Idle

Idle

sWaitInfoZoneZero

sWaitConfirmZoneManager

Idle

Idle

Idle

Idle

Idle

Idle

Figura 3.6: MSC de la inicialización de procesos del bloque ParkingLotSystem


La función de cada una de las señales presentadas a partir de este momento se puede detallar enel Anexo de Tipos de Datos y Señales usadas en el modelado del sistema de parqueo de la PUJC.Los diagramas MSCs de la especi�cación del sistema de parqueo se pueden detallar en el anexoMSCs de la especi�cación.

Creación de una entrada principal. El administrador solicita la creación de una entradaprincipal al sistema de parqueo como se muestra en la Figura B.1. Inicialmente, se crea el procesoque representa una entrada principal y a éste se le asigna su respectiva cámara y lector de carné.Si se ha creado exitosamente la entrada principal, el sistema retorna una señal al administradorllamada sOkCreateE_W. Si en el sistema ya están creados el cupo máximo de entradas principales,retornará al administrador la señal sExcEntryWay en lugar de sOkCreateE_W y no se efectuará elintercambio de señales para la asignación de cámara y lector de carnés.

Creación de una salida principal. El administrador solicita la creación de una salida principalal sistema de parqueo como se muestra en la Figura B.2. Se crea el proceso que representa una salidaprincipal y a éste se le asigna su respectiva cámara y lector de carné. Si se ha creado exitosamentela salida principal, el sistema retorna una señal al administrador llamada sOkCreateE_O. Si en elsistema ya se han creado el cupo máximo de entradas principales, se retornará al administrador laseñal sExcOutWay en lugar de sOkCreateE_O y no se efectuará el intercambio de señales para laasignación de cámara y lector de carnés.

Creación de una zona cuando tiene asignado un pZoneManager. En la Figura B.3, eladministrador del sistema envía una señal al proceso pMainSystemManager para crear una zona enun controlador especí�co, con una inicialización de plazas libres y totales de la zona. Para la solicitudde la zona se usa la señal sAddZone donde su primer parámetro es el número del controlador dezona, el segundo y tercero son las plazas totales y libres de la zona, respectivamente. Si la creaciónde la zona es exitosa, el proceso pMainSystemManager lo hará saber al administrador a través dela señal sOkCreationZone; de lo contrario enviará la señal sExcLimitZones, la cual se da antes queel proceso pZoneManager haga una instancia del proceso pZone.

Creación de un controlador de zonas cuando no tiene pZoneManager. El administradordel sistema envía una señal al proceso pMainSystemManager para crear una zona en un controladorespecí�co como se muestra en la Figura B.4. Este escenario es muy parecido al de la Figura B.3; ladiferencia es que el controlador de zonas no tiene un proceso pZoneManager asociado, por lo cualsolicita su creación. Una vez creado el pZoneManager y asociado a su respectivo controlador dezonas, el intercambio de señales respecto a la Figura B.3 es el mismo.

Inicialización de los parámetros de una zona. En la Figura B.5 se representa el intercambiode señales para la inicialización de una zona de parqueo. En este diagrama se le asigna un controladora la zona y se ajusta su capacidad de aparcamiento de vehículos.

Creación de un controlador de zonas. En la Figura B.6, el administrador solicita al sistemade parqueo crear un controlador de zonas por medio de la señal sCreateCtrl que es recibida por elproceso pMainSystemManager. Si la creación es exitosa, el proceso pMainSystemManager retornaráuna señal sOkCreateCtrl al administrador; de lo contrario, hará saber al administrador que no esposible tener más controladores de zonas con la señal sExcLimitCtrl.

Ingreso de un vehículo al sistema de parqueo. En la Figura B.7, este escenario es simi-lar al de la Figura 3.4 presentada anteriormente pero a nivel de procesos. Dado que los procesos

3.1. Modelado 35

pCardReader, pCamera y pDataBase no han sido modelados, se ha colocado un temporizador en lavida del proceso pCamera llamado timerProcessOCR, el cual representa el tiempo de cómputo quetardaría el proceso pCamera para entregar a partir de una foto la placa de un vehículo en un tipode dato charstring.

Salida de un vehículo del sistema de parqueo. En la Figura B.8, este escenario es similar alde la Figura B.7. La diferencia radica en que en éste el vehículo está por salir del sistema de parqueo;básicamente el proceso de veri�cación de usuario habilitado para salir es el mismo que cuando estápor ingresar, con la diferencia que ésta validación se realiza a través de la señal sCon�rmOutUser.

Permiso denegado para ingresar al sistema de parqueo. En la Figura B.9, se describe elescenario en el que un usuario desea ingresar al sistema de parqueo de la PUJC pero éste no estáhabilitado para hacerlo. La dinámica de veri�cación del usuario es la misma que la Figura B.7, soloque la respuesta por parte del proceso pDataBase es negativa y no se le da acceso al usuario paraingresar.

Ingreso de un vehículo a una zona de parqueo. En la Figura 17, se describe el esce-nario en el cual un vehículo va a ingresar a una zona del sistema. Para saber que un usuario haingresado a dicha zona se tiene que cumplir la siguiente secuencia: Se interrumpe el primer sensorinfrarrojo (sIR1_Zone); posteriormente el vehículo interrumpe el sensor infrarrojo 2 (sIR2_Zone);y �nalmente se veri�ca que se trata de un vehículo por la señal capturada en el sensor inductivosLoopInductive_Zone. La zona reportará que ha ingresado un vehículo a su respectivo controladorcon la señal sEntered_Car. Otra posibilidad que es válida para el ingreso del vehículo a una zona,es cuando el vehículo ingresa en la dirección opuesta a la anterior: se interrumpe el sensor infrarrojo4, luego el sensor infrarrojo 3 y �nalmente se da la recepción de la señal del loop inductivo.

Salida de un vehículo de una zona de parqueo. En la Figura B.12, se describe el escenarioel cual un vehículo va a salir de una zona del sistema. Para saber que un usuario ha salido setiene que cumplir la siguiente secuencia: Se interrumpe primero el sensor infrarrojo 3, sIR3_Zone,posteriormente el vehículo interrumpe el sensor infrarrojo 4, sIR4_Zone y �nalmente se veri�caque es un vehículo por la señal capturada en el sensor inductivo sLoopInductive_Zone. La zonareportará que ha salido un vehículo de su zona a su respectivo controlador con la señal sOut_Car.Otra posibilidad que es válida para reconocer que un vehículo va a salir de la zona es cuando seinterrumpe primero el sensor infrarrojo 2, luego el sensor infrarrojo 1 y �nalmente se presenta larecepción de la señal del loop inductivo.

Simulando el ingreso y salida de un vehículo en una zona. Con el objetivo de tener controlsobre el ingreso y salida de un vehículo en una zona de un controlador especí�co, es necesario hacerun acople al diseño del sistema con procesos simples, como es el caso del proceso pTesting, quepermite establecer en qué controlador y qué zona ha ingresado o salido un vehículo sin conocerlos identi�cadores de las instancias de los procesos del sistema. La Figura B.13, describe en laimagen de los lados izquierdo y derecho, respectivamente la entrada y salida de vehículos en unazona del sistema. La diferencia de este escenario a los de las Figuras B.11 y B.12 radica en que lasseñales de los sensores son generadas desde el proceso pMainSystemManager. Cabe destacar que lasseñales de sensores generadas por el proceso pMainSystemManager no deben ser consideradas en laimplementación del sistema de parqueo.


3.1.2. Diseño Usando SDL

Bottom-Up fue la estrategia de diseño usada para el desarrollo del sistema. Se inicia implemen-tando el bloque BZone representado en la Figura 3.7, dado que contiene procesos que poseen unbajo nivel de abstracción.

Como se había planteado en las especi�caciones, el administrador puede crear una zona e ini-cializar sus parámetros los cuales son: plazas totales y libres. Ambos parámetros son subtipos deltipo de dato Integer; ver Anexo de Tipos de Datos y Señales usadas en el modelado del sistema deparqueo de la PUJC. La zona tiene la facultad de reportar a su respectivo controlador el ingreso osalida de vehículos, y de enviar su información como una estructura de datos InfoZone; cada quehaya un requerimiento por parte del controlador. En la fase de inicialización del sistema al procesopZone se le asigna estáticamente un valor de 300 para las plazas libres, freeSpots, y para las plazastotales, totalSpots.

3.1. Modelado 37

cMain_Zone

cEnv_Zone

cCreator_ZoneManager

cCtrl_ZoneManager

cCtrl_Zone

cZone_Manager

cCtrl_CreatorZoneManager

pZonedPycNUMMAXZONES_SYSTEMu

pZoneManagerdPycNUMMAXCTRLu

pCreatorZoneManager

[sOkCreateZoneManager]__

[sIRP_ZoneysIR2_Zoney

sIR3_ZoneysIR4_Zoney

sLoopInductive_Zone]

[sOkCreationy

sExcQuantityZonesy

sIamZoneManager]__

[sInitFreeSpoty

sInitTotalSpotsy

sReqInfoy

sInitPidCtrl]

[] __

[]__

[sIamZoneManager]

[sConfirmZoneManager]

[sIRP_ZoneTesty

sIR2_ZoneTesty

sIR3_ZoneTesty

sIR4_ZoneTesty

sLoopInductive_ZoneTest]

[sCreateZoneManager]

[sInitFreeSpoty

sInitTotalSpotsy

sReqInfoy

sInitPidCtrl]

[sCreateZoney

sConfirmZoneManager_i]

[sOkInity

sInfoZoney

sOkInitPid]

[sEntered_Cary

sOut_Cary

sOkInity

sInfoZoney

sOkInitPid]

__

Figura 3.7: Arquitectura del bloque BZone


Diseño para el ingreso o salida de un vehículo en una zona. Las Figuras 3.8, 3.9 y 3.10representan la máquina de estados que se diseñó para detectar si un vehículo está por ingresar osalir de una zona del sistema de parqueo. Como se aprecia en la Figura 3.9, cuando la zona notenga plazas libres, freeSpots, el proceso pZone reportará a su respectivo proceso pCtrl que tienecero plazas libres; de esta manera así ingresen más vehículos a la zona se evitará enviar valoresnegativos de plazas libres. Lo anterior es similar a la Figura 3.10 cuando la zona tenga disponiblestodas sus plazas libres e intente salir un vehículo de ésta, se reportará que las plazas libres soniguales a las máximas permitidas o ajustadas por el administrador evitando enviar valores mayoresa los permitidos por el sistema.

sIR’_Zone

VerifyIsaCarEntering

sIR’_ZoneTest

sIRc_Zone

WaitSensorIRk WaitSensorIR4

sIRc_Zone

RESET=tOut0

sIR4_ZoneTest

sIRk_Zone

TIMER,tEnter/tOut;

VerifyIsaCarOut

sIRc_ZoneTest

SET=NOWL’/,tEnter0

sIR4_Zone sIR4_ZoneTest

Idle

SET=NOWL’/,tOut0

sIRk_ZoneTest

IdleSET=NOWL’/tOut0

sIR4_Zone

SET=NOWL’/tEnter0

totalSpots,:=,’BB/freeSpots,:=,’BB

sIRk_ZoneTestsIRk_Zone

Idle

RESET=tEnter0RESET=tEnter0

sIR’_Zone

DCL

mD,Params,Signals,Dmp_freeSpots/p_totalSpots,i_spots/

mDBlock,Zone’s,Registers,DmfreeSpots/totalSpots,i_spots/pidCtrl/myCtrl,PID;

sIRc_ZoneTest

RESET=tOut0

tOutsIR’_ZoneTest tEnter

Figura 3.8: Máquina de estados del proceso pZone para el acceso o salida de un vehículo en unazona

truefalse

freeSpots:=freeSpots−1 sEntered_Car(freeSpots)ZTOZmyCtrl

sLoopInductive_ZoneTest tEnter

Idle

freeSpots=0

sEntered_Car(freeSpots)ZTOZmyCtrl

Idle

sLoopInductive_Zone

Idle


RESET(tEnter)RESET(tEnter)

Figura 3.9: Continuación máquina de estados para el ingreso de un vehículo en una zona de parqueo

3.1. Modelado 39

false true

Idle

sLoopInductive_Zone

Idle

tOut

VerifyIsaCarOut

Idle

freeSpots=totalSpots

RESET(tOut)RESET(tOut)

sOut_Car(freeSpots)mTOmmyCtrlfreeSpots:=freeSpots+1

sLoopInductive_ZoneTest

sOut_Car(freeSpots)mTOmmyCtrl

Figura 3.10: Continuación máquina de estados para la salida de un vehículo de una zona de parqueo

Las señales de entrada resaltadas que se encuentran en las Figuras 3.8, 3.9 y 3.10, son provenien-tes del proceso pMainSystemManager; nuevamente, éste tipo de señales son usadas para implementarpruebas funcionales de caja negra, cuya utilidad se explicará en la siguiente sección.

Utilización de temporizadores para evitar estados de bloqueo. La Figura 3.8 muestrala implementación de dos temporizadores que tienen como función regresar el proceso pZone a unestado válido y que éste no se quede en uno de bloqueo. Un ejemplo en el cual éstos temporizadoresserían útiles es cuando el proceso pZone reciba la señal del sensor sIR1_Zone y posteriormente laseñal sIR2_Zone. En este escenario, se consideraría que un vehículo está por ingresar a dicha zona,pero si el causante de la interrupción fue una persona nunca llegaría la señal sLoopInductive_Zone,por lo cual el proceso pZone quedaría en el estado VerifyIsaCarEntering; si ésta señal nunca llegadespués de cierto tiempo, el temporizador, tEnter, coloca al proceso nuevamente en el estado Idledonde puede efectuar otras funciones sin bloqueo alguno.

En la Figura 3.11 se muestran los estados y las transiciones que el proceso pZone efectúa parala inicialización de plazas totales, plazas libres, requerimientos de información y la asignación delidenti�cador de su controlador.

−

totalSpotsy:=yp_totalSpots

sReqInfo

sOkInitPidyTOySENDER

sInitTotalSpots(p_totalSpots) sInitPidCtrl(pidCtrl)

sOkInityToySENDER sOkInityToySENDER

myCtrl:=pidCtrl

−

Idle

−

−

freeSpotsy:=yp_freeSpots

sInitFreeSpot(p_freeSpots)

sInfoZone(totalSpots,freeSpots)yTOySENDER

Figura 3.11: Máquina de estados para la inicialización de parámetros de una zona y solicitud derequerimiento de información a ésta

Una vez implementada la máquina de estados del proceso pZone, se implementa el proceso


pZoneManager que está encargado de instanciar más procesos pZone y asignarle a éste su respectivocontrolador de zonas.

Diseño del proceso pZoneManager. En las Figuras 3.12 y 3.13 se puede apreciar la máquinade estados �nitos del proceso pZoneManager. Inicialmente, el sistema permanece en el estado Idle yestá habilitado para recibir las siguientes señales: sCreateZone, sCon�rmZoneManager y sCon�rm-ZoneManager_i. La primera señal tiene asociados dos parámetros de tipo i_spots que son subtiposdel tipo de dato Integer. Básicamente cuando el proceso pZoneManager recibe esta señal crea uninstancia de una zona. Si el sistema no tiene más capacidad para crear zonas, el agente pZoneMa-nager enviará una señal sExcQuantityZones a su respectivo controlador indicando que no es posibleanexar más zonas; de lo contrario, creará un proceso pZone y efectuará el intercambio de señalescon éste para inicializar sus parámetros.

false

true

myCtrl:=SENDER

sInitPidCtrlkmyCtrl1qTOqpidZone

quantityZones:=<

pZone

sConfirmZoneManager_isConfirmZoneManagerkpidCtrl1

sWaitAck_OkX

sIamZoneManagerqTOqmyCtrl

myCtrl:=SENDERFquantityZones:=quantityZones+X

Idle

Idle

sCreateZonekp_totalSpotsFp_freeSpots1

quantityZones:=quantityZones+XFpidZone:=OFFSPRING

sIamZoneManagerqTOqSENDER

Idle

sWaitInitPidCtrl_Zone

sInitFreeSpotkp_freeSpots1qTOqpidZone

myCtrl:=pidCtrl

DCL

quantityZonesqINTEGERFp_freeSpotsFp_totalSpotsqi_spotsFqmyCtrlFpidCtrlFpidZoneqPID;

quantityZonesq<qcMAX_ZONES

sExcQuantityZonesqTOqmyCtrl

Idle

sOkInitPid

Figura 3.12: Máquina de estados del proceso pZoneManager para la creación de zonas e inicializaciónde su respectivo controlador de zonas

3.1. Modelado 41

sWaitAck_Ok1

sWaitAck_Ok2

sOkInit

sOkInit

sInitTotalSpots(p_totalSpots) TO pidZone

sOkCreation(pidZone) TO myCtrl

Idle

Figura 3.13: Continuación máquina de estados para la creación de una zona de parqueo

La Figura 3.14 representa la máquina de estados �nitos del proceso pCreatorZoneManager. Laúnica función que tiene este proceso es la de instanciar procesos pZoneManager y asignarle a éstesu respectivo controlador de zonas.


Idle

sCreateZoneManager

pidZoneManager:=SENDER

sOkCreateZoneManager(pidZoneManager)TTOpidCtrl

pZoneManager

Idle

sConfirmZoneManager(pidCtrl)TTOTOFFSPRING

sIamZoneManager

pidCtrl:=SENDER

DCL

pidCtrl,pidZoneManagerTPID;

Figura 3.14: Máquina de estados �nitos del proceso pCreatorZoneManager


La Figura 3.15 muestra la arquitectura del bloque UnmodeledProcesses. En esta arquitecturase puede apreciar que los procesos pCardReader que representa el lector de carnés y pCamera querepresenta la cámara, solicitan al ambiente o entorno los datos que deberían de entregar al procesopEntryNOut_Way. De esa forma éstos procesos solo sirven para mostrar los canales y las conexionesa otros procesos que deberían de ser usados en el momento de ser modelados en detalle.

cEnv_CR cEntryWay_CamcEntryWay_CR

cCreator_CamerapCreator_CardReader

cCreatorCRNC

cEnv_Camera cEntryWay_DB

pDataBasepCardReaderI0ucNUMMAXENTRYNOUTWAYk pCameraI0ucNUMMAXENTRYNOUTWAYk


[sPlateFromEnv]

[sAssignCardReaderNCam]

[sPlate]

__

[sIDUserFromEnv]

[sIamCamera]

[]

__

[sOkUserusNoRegis_User]

__

[sIamCardReader]

[]

__

[sEnableCardReader] [sRequestPlate]

[]

[sDataUser]

__

[]

[sConfirmEntranceUserusConfirmOutUser]

[sAssigned]

__

Figura 3.15: Arquitectura del bloque Unmodeled Processes

Para el modelado de las bases de datos se ha construido un arreglo de datos que contiene unidenti�cador que tiene asociada una única placa; actualmente el sistema cuenta con 40 usuariosregistrados, pero el modelo no se ve afectado por esta simpli�cación (es decir, que si se modelara labase de datos de manera detallada, el modelo del sistema tal como se ha planteado permaneceríaigual) y la implementación tampoco se ve limitada a esta cantidad.

La Figura 3.16 representa la máquina de estados del proceso pDataBase que representa losrepositorios de información del sistema.

3.1. Modelado 43

true false

sNoRegis_User=TO=SENDER

sConfirmEntranceUser(data_User)

LoadDB

LoadDB(dataBase)

sConfirmOutUser(data_User)

statusUser:=CALL=getPass(dataBase,data_User)

DCLdataBase=tDATABASE,data_User=DataUser,statusUser=BOOLEAN;

Idle

sOkUser=TO=SENDER

statusUser

getPass

Idle

Figura 3.16: Máquina de estados del proceso pDataBase

La Figura 3.17 representa el procedimiento usado para cargar los datos al repositorio de datos.


LoadDB

FPARINVOUT’dataBase’tDATABASE;

dataBase1tplatesJWY:=’ABEMCQ’KdataBase1tIDJWY:=WKdataBase1tplatesJMY:=’AFG54M’KdataBase1tIDJMY:=MKdataBase1tplatesJCY:=’JUY589’KdataBase1tIDJCY:=CKdataBase1tplatesJQY:=’JKAMMM’KdataBase1tIDJQY:=QKdataBase1tplatesJ4Y:=’AAA555’KdataBase1tIDJ4Y:=4KdataBase1tplatesJ5Y:=’RKJWMC’KdataBase1tIDJ5Y:=5KdataBase1tplatesJ6Y:=’JPG5C8’KdataBase1tIDJ6Y:=6KdataBase1tplatesJ7Y:=’LAS84C’KdataBase1tIDJ7Y:=7KdataBase1tplatesJ8Y:=’AYS5QC’KdataBase1tIDJ8Y:=8KdataBase1tplatesJ9Y:=’VSDCM5’KdataBase1tIDJ9Y:=9KdataBase1tplatesJMWY:=’TAW5M4’KdataBase1tIDJMWY:=MWKdataBase1tplatesJMMY:=’OIU985’KdataBase1tIDJMMY:=MMKdataBase1tplatesJMCY:=’WUECM6’KdataBase1tIDJMCY:=MCKdataBase1tplatesJMQY:=’NMKQ85’KdataBase1tIDJMQY:=MQKdataBase1tplatesJM4Y:=’ASUQC5’KdataBase1tIDJM4Y:=M4KdataBase1tplatesJM5Y:=’VBC798’KdataBase1tIDJM5Y:=M5KdataBase1tplatesJM6Y:=’NAL64C’KdataBase1tIDJM6Y:=M6KdataBase1tplatesJM7Y:=’OQE56C’KdataBase1tIDJM7Y:=M7KdataBase1tplatesJM8Y:=’KIP7Q8’KdataBase1tIDJM8Y:=M8KdataBase1tplatesJM9Y:=’CFG8W7’KdataBase1tIDJM9Y:=M9KdataBase1tplatesJCWY:=’ABEMC4’KdataBase1tIDJCWY:=CWKdataBase1tplatesJCMY:=’AFG54C’KdataBase1tIDJCMY:=CMKdataBase1tplatesJCCY:=’JUY59W’KdataBase1tIDJCCY:=CCKdataBase1tplatesJCQY:=’JKAMMC’KdataBase1tIDJCQY:=CQKdataBase1tplatesJC4Y:=’AAA556’KdataBase1tIDJC4Y:=C4KdataBase1tplatesJC5Y:=’RKJWMQ’KdataBase1tIDJC5Y:=C5KdataBase1tplatesJC6Y:=’JPG5C9’KdataBase1tIDJC6Y:=C6KdataBase1tplatesJC7Y:=’LAS84Q’KdataBase1tIDJC7Y:=C7KdataBase1tplatesJC8Y:=’AYS5QQ’KdataBase1tIDJC8Y:=C8KdataBase1tplatesJC9Y:=’VSDCM6’KdataBase1tIDJC9Y:=C9KdataBase1tplatesJQWY:=’TAW5M5’KdataBase1tIDJQWY:=QWKdataBase1tplatesJQMY:=’OIU986’KdataBase1tIDJQMY:=QMKdataBase1tplatesJQCY:=’WUECM7’KdataBase1tIDJQCY:=QCKdataBase1tplatesJQQY:=’NMKQ86’KdataBase1tIDJQQY:=QQKdataBase1tplatesJQ4Y:=’ASUQC6’KdataBase1tIDJQ4Y:=Q4KdataBase1tplatesJQ5Y:=’VBC799’KdataBase1tIDJQ5Y:=Q5KdataBase1tplatesJQ6Y:=’NAL64Q’KdataBase1tIDJQ6Y:=Q6KdataBase1tplatesJQ7Y:=’OQE56Q’KdataBase1tIDJQ7Y:=Q7KdataBase1tplatesJQ8Y:=’KIP7Q9’KdataBase1tIDJQ8Y:=Q8KdataBase1tplatesJQ9Y:=’KIP74W’KdataBase1tIDJQ9Y:=Q9

Figura 3.17: Procedimiento para cargar los datos al repositorio del sistema de parqueo

La Figura 3.18 representa el procedimiento que valida si un usuario tiene acceso al sistemade parqueo, si su identi�cador obtenido del lector de carnés y la placa tomada por la cámara se

3.1. Modelado 45

encuentran en dicha base de datos.

truefalse

true

false

false

true

vIDTmpL=LvID

pass:=TRUE

FPARLdataBaseLtDATABASEMdata_UserLDataUser;RETURNSLBOOLEAN;

DCLLvPlateMvPlateTmpLcharstringMvIDMvIDTmpLINTEGERMIndexLINTEGERMLpassLBOOLEAN;

Index:=Index<)

getPass

pass

Index<cNUMMAXUSERS

pass:=TRUE

vPlateTmpL=LvPlate

FALSE

vPlate:=data_UserCplateMvID:=data_UserCIDMIndex:=(

vIDTmp:=dataBaseCtIDxIndex+MvPlateTmp:=dataBaseCtPlatesxIndex+

Figura 3.18: Procedimiento para validar si un usuario tiene acceso o salida del sistema de parqueo

Este tipo de búsquedas se podrían ampliar estableciendo algunas políticas de acceso, por ejemplo:

Que un usuario con su identi�cador pueda tener asociadas varias placas de vehículos.

Que el usuario tenga acceso al sistema sí y sólo sí en el repositorio aparece que sus vehículosno están dentro del sistema de parqueo.

Que un mismo usuario no pueda tener acceso al parqueo con otro vehículo registrado si ya haingresado otro.


Las opciones descritas anteriormente serían parte de las especi�caciones para el modelado ydiseño de la base de datos del sistema de parqueo. Este trabajo de grado no pretende enfocarse enlas políticas de validación de usuarios para ingresar o salir del sistema de parqueo. Lo anterior noafecta el propósito ni el objetivo del trabajo de grado; en el momento que se desee modelar la basede datos sólo es necesario reemplazar dicho proceso por el nuevo, conservando las señales que secomparten con otros procesos.

Para más información del diseño de las otras máquinas de estado véase el Anexo Digital.

3.2. Pruebas

Al igual que las estrategias de diseño mencionadas en la sección del modelado, éstas puedenser empleadas en la fase de pruebas de un modelo. En este caso se va a hacer uso de la estrategiaBottom-Up. La herramienta RTDS posee un módulo que permite hacer pruebas funcionales de cajanegra extendiendo éstas por medio de una interfaz grá�ca, donde se puede veri�car que el diseñocumplió con el escenario propuesto comparando el MSC que se genera al estimular el sistema frenteal MSC de la especi�cación del mismo escenario.

Una de las ventajas que tiene el módulo de pruebas de la herramienta RTDS es que permiteevaluar un modelo a través de un escenario especí�co de forma rápida y sencilla, pero carece deautomatización en cuanto a la inyección de estímulos al sistema bajo prueba. Por otro lado, ellenguaje TTCN-3 ha sido diseñado para hacer pruebas funcionales de caja negra y tiene la ventajade poder automatizarlas generando una mayor cantidad de estímulos, lo que se traduce en obtenersistemas más seguros al aumentar el grado de cubrimiento de pruebas sobre el modelo.

3.2.1. Usando el Simulador de Modelos

La Figura 3.19 muestra el simulador de modelos descritos en SDL que tiene la herramientaRTDS.

3.2. Pruebas 47

Figura 3.19: Interfaz grá�ca para el módulo de pruebas en la herramienta RTDS

Mediante el botón TO se pueden seleccionar las señales que se desean enviar a procesos especí-�cos, como se muestra en la Figura 3.20.

Figura 3.20: Interfaz envío de señales a procesos a través de la herramienta RTDS

Como se describió en la parte del modelado del sistema de parqueo, el bloque BZone tiene tresprocesos entre los cuales se encuentra el proceso pCreatorZoneManager que está encargado de crearprocesos de tipo pZoneManager.

Creación del proceso pZoneManager. La Figura C.6 muestra el resultado de un escenariode prueba de creación de un proceso pZoneManager. La manera de veri�car que el diseño de lasmáquinas de estados quedó conforme a los requerimientos es comparando el MSC resultante de


ejercitar el modelo creado con el MSC de la especi�cación.

Análisis de la prueba. Lo que muestra la Figura C.6 es básicamente que el proceso pCrea-torZoneManager inicialmente se encuentra en el estado Idle y está esperando por la señalsCreateZoneManager. Una vez reciba esta señal, crea el proceso pZoneManager asignándolesu proceso controlador y pasa al estado sWaitCon�rmZoneManager. Como el entorno solicitóla creación de un pZoneManager entonces su PID por defecto es cero, por eso el parámetro quecorresponde al identi�cador del controlador de zonas tiene el mismo valor. Una vez el procesopZoneManager haya asignado el identi�cador de su controlador, enviará una señal sIamZone-Manager a su proceso creador el cual se encuentra en un estado permitido para recibir dichaseñal y retorna al proceso que solicitó inicialmente la creación la señal sOkCreateZoneMana-ger enviando como parámetro de esa señal el identi�cador del nuevo proceso creado (4 en estecaso). Ambos procesos terminan su interacción y quedan en el estado Idle.

A partir de este momento se ha hecho uso del simulador de la herramienta RTDS para probaralgunas características del bloque BZone mediante el envío de mensajes manualmente. Por defectola condición inicial del bloque BZone, siempre contará con una instancia del proceso pZone, pZone-Manager y pCreatorZoneManager. Adicionalmente la zona de parqueo contará con 300 plazas libresy 300 totales. Los diagramas MSCs generados en cada prueba se puede encontrar en el Anexo deDiagramas MSCs en la fase de pruebas.

Respuesta del diseño al crear un proceso pZone. La Figura C.1, muestra el resultado deprobar que el proceso pZoneManager puede crear satisfactoriamente un proceso pZone.

Se espera que el sistema cuente con dos procesos pZone, y una instancia tanto del procesopZoneManager como de pCreatorZoneManager.

Resultado crear el número máximo de zonas. En la Figura C.2 se muestra el MSC cores-pondiente a la creación del número máximo de zonas. Se desa probar que el proceso pZoneManagerno podrá crear más zonas que las que tiene permitidas.

Se espera que el sistema cuenta con el número máximo de zonas, en este caso serían tres.Adicionalmente cuando se quiera crear otra adicional el proceso pZoneManager indicará queexcede su capacidad.

Resultado de inicializar las propiedades de una zona. En la Figura C.3 se muestra elresultado después de probar que se pueden inicializar las plazas libres y totales de una zona delsistema de parqueo.

Se espera que en el proceso de inicialización de las propiedades de la zona, ésta envíe siemprela señal sOkInit, lo que indica que los parámetros fueron ajustados satisfactoriamente.

Resultado ingreso de vehículos en una zona. En la Figura C.4, se muestra el resultado deprobar que la zona de parqueo es capaz de reportar una cifra correcta de plazas libres después dehaber entrado un vehículo a ésta. Inicialmente la zona cuenta con 300 plazas libres.

3.2. Pruebas 49

Se espera que la zona reporte 298 plazas libres después de ingresar dos vehículos a ésta.

Resultado salida de un vehículo en una zona. En la Figura C.5 se muestra el resultado deprobar que la zona reporta un número correcto de plazas libres después de ingresar y salir vehículosde dicha zona. Inicialmente la zona cuenta con 300 plazas libres.

Se espera que la zona reporte 299 plazas libres después de haber ingresado dos vehículos ysalido uno.

3.2.2. Usando una GUI para Probar Modelos

Aprovechando la característica que tiene la herramienta RTDS de crear una interfaz grá�ca comofuente de estímulos al sistema bajo pruebas, se diseña una como se muestra en la Figura 3.21.

A

B

C

Figura 3.21: Diseño de la interfaz grá�ca para la realización de pruebas

Utilización del proceso pTesting. Como se había comentado anteriormente en el diseño delsistema de parqueo de la PUJC se ha modelado un proceso llamado pTesting, como acople parahacer pruebas al modelo a través de una interfaz grá�ca. La limitación que tiene ésta es que nopermite ajustar todos los parámetros de una señal al mismo tiempo; por ejemplo, si se desearasimular el ingreso de un vehículo a la zona 0 del controlador 0 no sería posible hacer esto con unúnico objeto grá�co de tipo botón; por ende, es indispensable que el proceso pTesting capture losvalores del número de controlador y el número de zona donde se desea simular un ingreso de un


vehículo en dos diferentes estados. Similarmente, se trabaja el proceso de captación de datos parala simulación de la salida de un vehículo de una zona de parqueo.

Una vez el proceso pTesting tenga el número de controlador y la zona a hacer simulada, enviarála señal correspondiente al sistema para que simule en la zona y controlador especí�co la entrada osalida de vehículos.

Descripción de la interfaz grá�ca. Esta interfaz se ha diseñado para probar que el diseñodel sistema puede crear instancias de controladores de zonas y anexar a éstos nuevas zonas. Adicio-nalmente cuenta con la posibilidad de ingresar y sacar automóviles de una zona y un controladorespecí�co.

La parte A de la interfaz tiene la funcionalidad de ingresar un automóvil a una zona de uncontrolador especí�co. La manera de hacerlo es seleccionando un controlador ubicado debajode la etiqueta Entry Car in pCtrl desired . Una vez determinado el controlador por el cualun vehículo ingresó, se selecciona la zona que reportó el ingreso del vehículo ubicado bajo laetiqueta Entry Car in pZone desired . De forma análoga el proceso de sacar un vehículode una zona de parqueo es el mismo; únicamente se selecciona el controlador que está bajo laetiqueta Out Car in pCtrl desired y la zona que está abajo de la etiqueta Out Car inpZone desired .

La parte B de la interfaz corresponde a la funcionalidad de crear nuevos controladores y zonas.La forma de crear un controlador es seleccionando el botón Create Ctrl ; en ese momentose enviará una señal al sistema con el propósito de crear un nuevo proceso pCtrl. Para ane-xar una nueva zona a un controlador especí�co, se selecciona el botón Create pZone inpCtrl(n) donde n corresponde al controlador. Por razones prácticas, el sistema cuenta con 3controladores de zonas y cada uno puede tener a su mando hasta 3 zonas.

La parte C de la interfaz corresponde a la suma total de las plazas libres y totales que tiene cadacontrolador para veri�car que el sistema satisface las pruebas. Bajo la etiqueta free SpotsSystem se detallan las plazas libres totales de todos los controladores y bajo la etiquetatotal Spots System se muestra la suma de las plazas totales de todos los controladores. Lainformación anterior es indicada por medio de la interfaz grá�ca sí y sólo sí es presionado elbotón probe! después de haber corrido el sistema en el simulador de RTDS.

Limitaciones de la interfaz grá�ca. Indudablemente los entornos grá�cos como medio deacople para realizar pruebas a los sistemas muchas veces ayudan al desarrollador a obtener informa-ción del diseño de una forma más amigable. La herramienta RTDS ofrece éste tipo de módulos perocarece de más objetos grá�cos para ampliar el nivel de la prueba. Lo anterior implicó establecervalores constantes a algunos parámetros de las señales a ser enviadas al sistema bajo prueba a travésde la interfaz grá�ca; por ejemplo: Al momento de crear una zona en un controlador el adminis-trador establece el controlador de zonas que va a ser ampliado con una nueva zona, la cantidadde plazas totales y �nalmente se de�ne la cantidad de plazas libres. Dado que no existe un objetográ�co que permita inicializar una señal con más de dos parámetros, se de�nió que: todas las zonasdel controlador 0 tendrán 200 plazas libres y totales, todas las zonas del controlador 1 tendrán 100

3.2. Pruebas 51

plazas libres y totales y �nalmente todas las zonas del controlador 2 tendrán 50 plazas libres ytotales.

La Figura 3.22 detalla el número de plazas totales de los controladores del sistema cuando se hasometido al siguiente escenario:

El sistema cuenta con tres controladores y 9 zonas en total.

Inicialmente no han ingresado ni salido vehículos.

La cantidad de plazas libres y totales son las mismas, y corresponden a la sumatoria de lasplazas libres de todos los controladores, El controlador 1 cuenta tanto con 700 plazas librescomo totales, el controlador 2 cuenta con 300 plazas tanto libres como totales y �nalmente elcontrolador 3 cuenta con 150 plazas tanto libres como totales.

Ingresan 4 carros a la zona 0 del controlador 0.

Ingresa 1 carro tanto a la zona1 como a la zona 2 del controlador 0.

Ingresan 2 carros a la zona 0, 3 carros a la zona 1 y 1 carro a la zona 2; todas las zonaspertenecen al controlador 1.

El resultado esperado de plazas libres y totales que se desea ver en la interfaz grá�ca son: 1138y 1150 respectivamente.

Figura 3.22: Resultado de las plazas totales y libres inyectando datos al sistema bajo prueba desdela interfaz grá�ca


Tabla 3.5: Formato de Ingreso y salida de vehículos del sistema de parqueo de la PUJCHora Cantidad de vehículos06:35 3006:40 2606:45 3606:50 37

Como se puede apreciar en la Figura 3.22 sólo se muestran las plazas libres y totales del sistemacomo medio de observación para determinar si el diseño cumple con los escenarios propuestos; noobstante, es posible evaluar las plazas libres y totales de cada controlador si en el diseño del sistemase colocan procesos de acople que permitan consultar las plazas libres y totales de cada controladory retornen dichos valores como tipo de datos sencillos, es decir, sin estructuras dado que la interfazno soporta este tipo de datos.

3.2.3. Usando TTCN-3

Hasta el momento, el diseño del sistema de parqueo ha sido evaluado por medio de pruebasfuncionales de caja negra usando el simulador de la herramienta SDL. A pesar de que las pruebasprevias cumplen con el propósito de encontrar errores en el diseño del sistema, es indispensableinyectarle al sistema bajo prueba estímulos más dinámicos y de forma automática. En este momentola potencia del lenguaje TTCN-3 para hacer pruebas funcionales de caja negra se puede aprovecharal máximo.

Reporte de ingreso y salida de vehículos del sistema de parqueo. A partir de los mecanismosde registro de vehículos que posee el sistema de parqueo de la PUJC se obtuvieron datos reales deingreso y salida de dicho sistema. Un ejemplo de la forma de la estructura de los datos obtenidos semuestra en la Tabla 3.5.

Los procesos que serán evaluados pertenecen al bloque ParkingLotSystem. Debido a que laestructura de información mostrada en la Tabla 3.5 no muestra la zona ni el respectivo controladoren el cual un vehículo ha ingresado o salido de dicha zona, entonces se implementó una fórmula enel Software O�ce Calc del paquete LibreO�ce de Linux, con el objetivo de distribuir los vehículosde entrada y salida del sistema en las cuatro zonas totales del sistema.

Distribución de vehículos en diferentes zonas. Básicamente la fórmula para distribuir losvehículos entrantes y salientes en distintas zonas se establece a partir de las siguientes políticas:

En la zona que va a ingresar un vehículo a una hora especí�ca el número de plazas libres enese momento no puede ser menor que cero.

En la zona que va a salir un vehículo a una hora especí�ca el número de plazas libres en esemomento no puede ser mayor al número de plazas totales inicializadas en dicha zona.

Después de implementar una fórmula de asignación en O�ce Calc para la distribución de lacantidad de carros en distintas zonas, se obtiene un libro de cálculo en O�ce Calc con cuatro hojas,

3.2. Pruebas 53

ver Anexo Digital Tabla completa de datos. La primera hoja establece la condición del sistema aprobar como se muestra en la Figura 3.23.

CONDICIONES3DEL3SISTEMAPLAZAS3TOTALES3DEL3SISTEMA Cantidad3de3Zonas Plazas3libres3por3Zona

1200 4 300

Figura 3.23: Condiciones del sistema para realizar las pruebas en TTCN-3

A pesar de que el diseño del sistema considera tres controladores de zonas como máximo, lascuales pueden tener hasta 3 zonas con una capacidad máxima de 300 plazas libres y totales, en laspruebas usando TTCN-3 se tienen dos controladores y dos zonas especí�cas sobre dichos controla-dores. Lo anterior se hace por razones prácticas, pero no implica que las pruebas a realizar no sirvancomo técnica para la minimización de errores en el diseño.

Estructura del libro de cálculo. En la segunda y tercera hojas, llamadas ENTRADA ySALIDA, del libro de cálculo se encuentran la cantidad de vehículos que han ingresado o salido delsistema con su respectiva distribución a cada una de las zonas. La Figura 3.24 muestra una fracciónde los vehículos que ingresaron al sistema hasta las 7:25 a.m. y la Figura 3.25 muestra una fracciónde la distribución por zona de los vehículos que salieron al sistema hasta las 7:25 a.m.

Hour Quantity4of4Cars4IN Main4Entrance Zone404Ctrl0 Zone414Ctrl0 Zone404Ctrl1 Zone414Ctrl1 Total(05:15) 0 0 0 0 0 0 0(05:20) 0 1 0 0 0 0 0(05:25) 0 2 0 0 0 0 0(05:30) 1 0 1 0 0 0 1(05:35) 0 2 0 0 0 0 0(05:40) 0 2 0 0 0 0 0(05:45) 0 2 0 0 0 0 0(05:50) 0 0 0 0 0 0 0(05:55) 0 1 0 0 0 0 0(06:00) 0 2 0 0 0 0 0(06:05) 0 0 0 0 0 0 0(06:10) 4 2 4 0 0 0 4(06:15) 2 0 2 0 0 0 2(06:20) 4 0 4 0 0 0 4(06:25) 15 2 15 0 0 0 15(06:30) 12 2 12 0 0 0 12(06:35) 30 2 30 0 0 0 30(06:40) 26 0 26 0 0 0 26(06:45) 36 0 36 0 0 0 36(06:50) 37 0 37 0 0 0 37(06:55) 30 1 30 0 0 0 30(07:00) 32 0 32 0 0 0 32(07:05) 7 2 7 0 0 0 7(07:10) 54 1 54 0 0 0 54(07:15) 36 0 36 0 0 0 36(07:20) 26 1 13 13 0 0 26(07:25) 18 1 9 9 0 0 18

Figura 3.24: Distribución de carros ingresados al sistema y a cuatro diferentes zonas


Hour Quantity7of7Cars7OUT Main7Exit Zone707Ctrl0 Zone717Ctrl0 Zone707Ctrl1 Zone717Ctrl1 Total5:15 0 1 0 0 0 0 05:20 0 2 0 0 0 0 05:25 0 0 0 0 0 0 05:30 0 2 0 0 0 0 05:35 0 2 0 0 0 0 05:40 0 1 0 0 0 0 05:45 0 1 0 0 0 0 05:50 0 0 0 0 0 0 05:55 0 2 0 0 0 0 06:00 0 2 0 0 0 0 06:05 0 2 0 0 0 0 06:10 1 1 1 0 0 0 16:15 1 2 1 0 0 0 16:20 0 1 0 0 0 0 06:25 2 0 2 0 0 0 26:30 5 0 5 0 0 0 56:35 2 1 2 0 0 0 26:40 3 0 3 0 0 0 36:45 2 2 2 0 0 0 26:50 7 2 7 0 0 0 76:55 2 0 2 0 0 0 27:00 3 0 3 0 0 0 37:05 0 1 0 0 0 0 07:10 6 1 6 0 0 0 67:15 5 2 5 0 0 0 57:20 9 0 9 0 0 0 97:25 1 2 1 0 0 0 1

Figura 3.25: Distribución de carros que salieron del sistema y de cuatro zonas

Finalmente, el libro de cálculo en O�ce Calc posee una hoja donde se presenta el consolidadode plazas libres por zona y por hora. Como se muestra en la Figura 3.26, la última columna sirvepara identi�car una hora en especial, por ejemplo: Si queremos ver en número de plazas libres quehay en cada zona de parqueo a las 6:50 a.m., es equivalente a ver la �la cuyo índice tiene el valorde 19.

Hour In7Cars Out7Cars Zona707Ctrl0 Zona717Ctrl0 Zona707Ctrl1 Zona717Ctrl1 Free7Spots7System Index5:15 0 0 300 300 300 300 1200 05:20 0 0 300 300 300 300 1200 15:25 0 0 300 300 300 300 1200 25:30 1 0 299 300 300 300 1199 35:35 0 0 299 300 300 300 1199 45:40 0 0 299 300 300 300 1199 55:45 0 0 299 300 300 300 1199 65:50 0 0 299 300 300 300 1199 75:55 0 0 299 300 300 300 1199 86:00 0 0 299 300 300 300 1199 96:05 0 0 299 300 300 300 1199 106:10 4 1 296 300 300 300 1196 116:15 2 1 295 300 300 300 1195 126:20 4 0 291 300 300 300 1191 136:25 15 2 278 300 300 300 1178 146:30 12 5 271 300 300 300 1171 156:35 30 2 243 300 300 300 1143 166:40 26 3 220 300 300 300 1120 176:45 36 2 186 300 300 300 1086 186:50 37 7 156 300 300 300 1056 196:55 30 2 128 300 300 300 1028 207:00 32 3 99 300 300 300 999 217:05 7 0 92 300 300 300 992 227:10 54 6 44 300 300 300 944 237:15 36 5 13 300 300 300 913 247:20 26 9 9 287 300 300 896 257:25 18 1 1 278 300 300 879 26

Figura 3.26: Consolidado de plazas libres por zona y en el sistema en general de parqueo

Una vez distribuida la información de vehículos que han ingresado y salido del sistema y haber

3.2. Pruebas 55

estipulado el valor deseado de plazas libres por zonas y a nivel del sistema, se traduce la informaciónanterior en un tipo de dato que pueda ser leído por el lenguaje de TTCN-3.

Limitaciones del lenguaje TTCN-3 en RTDS. La herramienta RTDS hasta el momentono soporta todo el lenguaje TTCN-3; aspectos tales como pruebas a multicomponentes, creaciónde adaptadores, de�nición de vectores multidimensionales, etc., aún no están disponibles. Paramás información de las limitaciones del lenguaje TTCN-3 en RTDS véase el manual de referencia dePragmadev3. Por ende, se ha hecho uso de vectores unidimensionales que representan la informaciónde entrada y salida de vehículos y su respectivo valor esperado de plazas libres por zona.

Traductor de archivos en XLS a vectores unidimensionales de TTCN-3. Se implementóun algoritmo en el lenguaje de programación Python para la transformación de una tabla en formato*.xls a un vector en el lenguaje de TTCN-3. La Figura 3.27, muestra la función principal delalgoritmo.

Figura 3.27: Función principal del algoritmo para transformar datos de un archivo .xls a un vectorválido en TTCN-3

Básicamente la función principal solicita al usuario que ingrese el nombre del archivo de formato.xls. El formato que debe de tener dicho archivo se aprecia en las Figuras 3.24, 3.25 y 3.26; de locontrario, la información generada por el algoritmo no será coherente.

El nombre del archivo debe ser escrito sin especi�car la extensión. Adicionalmente, el usuario depruebas debe establecer el nombre que le dará a su archivo .ttcn3; lo anterior porque en el lenguajeTTCN-3, el nombre del módulo debe de coincidir con el nombre de dicho archivo.

Una vez que el usuario de pruebas haya ingresado los datos requeridos, el algoritmo hace llamadoa dos funciones que son: getData y conversion2TTCN3 . La primera función retorna una listaque contiene los datos del archivo .xls; posteriormente esta lista generada es un parámetro de lafunción conversion2TTCN3 . Dicha función se encarga de convertir cada término de la lista envectores unidimensionales válidos en TTCN-3. Para ver todo el código del algoritmo mencionadopreviamente, véase el Anexo Digital.

Estructura de pruebas con único componente en TTCN-3. Una vez obtenidos los datosque se van a inyectar al sistema bajo pruebas, se diseña la estructura de la prueba en TTCN-3 sobrela herramienta RTDS. Los siguientes pasos son recomendaciones que se proponen con base en el

3Para más informacióin del manual de referencia de la herramienta ingresar al siguiente enlace: http://www.

pragmadev.com/downloads/RefManual.pdf

http://www.pragmadev.com/downloads/RefManual.pdf

http://www.pragmadev.com/downloads/RefManual.pdf


desarrollo de este trabajo de grado, para diseñar una prueba en TTCN-3 de forma sencilla.

1. De�nir cuatro módulos de TTCN-3.

2. El primer módulo hará referencia a los tipos de datos que se usarán en las pruebas de�niendolas señales.

3. El segundo módulo corresponderá a los mensajes, templates, que se enviarán al sistema bajoprueba.

4. El tercer módulo de�nirá los puertos y componentes donde se compartirán los mensajes.

5. El cuarto módulo será el banco de pruebas. Aquí estarán los casos de prueba que se desearealizar además de la de�nición del control.

La Figura 3.28 ilustra el primer módulo que hace referencia a la de�nición de los tipos de datosa usar en las pruebas.

IU_Here_are_the_declarations_of_the_data_typeand_the_signals_that_will_be_used_in_thetestcases_ UI

IU_Code_written_by:_Juan_Pablo_Giron_Ruiz_UI

module declaration_Signals{

IU_Step_vq_Definition_of_data_Types_UI

type integer spots;type integer numCtrl;type integer numZone;

IU_Step_Oq_Declaration_of_the_Signals_UIIU_The_PURE_Signals_are_enumerated,_signalswith_parameters_are_type_record_UIIU_The_name_of_the_signals_must_be_the_same_that_inSDL_system_UI

IUSignals_with_parameters_UIIU_Channel_cDisplay_mainUI

type record sReqInfoCtrlZone{

numCtrl_num_Ctrl,numZone_num_Zone

}

type record sInfoCtrlZone{

spots_freeSpots}

IU_Channel_cEnv_pTesting_ UI

type record sEntryCarCtrl{

numCtrl_num_Ctrl}type record sOutCarCtrl{

numCtrl_num_Ctrl}type record sEntryCarZone{

numZone_num_Zone}type record sOutCarZone{

numZone_num_Zone}IUChannel_cEnv_MainUI

type enumerated sCreateCtrlZone_{e_sCreateCtrlZone}type enumerated sOkCreateCtrl_{e_sOkCreateCtrl}type enumerated sOkCreationZone_{e_sOkCreationZone}

type record sAddZone{

numCtrl_num_Ctrl,spots_totalSpots,spots_freeSpots

}

}

Continúa...

Continuación

Figura 3.28: Declaración de los tipos de datos y señales que se usarán en las pruebas de TTCN-3

3.2. Pruebas 57

La Figura 3.28, enmarca un tipo singular de de�nir las señales que van a ser usadas sobre elsistema bajo prueba, dado que el nombre de éstas corresponden tal cual a las de�nidas en el diseñodel sistema; lo anterior es una regla de la herramienta RTDS para la construcción de pruebas enTTCN-3. Adicionalmente se estipula que las señales que no tienen parámetros se pueden de�nircomo tipos de datos enumerated mientras que las señales que sí los tienen, éstos se deben de�nircomo tipos de datos record .

La forma de declaración de señales en TTCN-3 se asemeja a la declaración de variables de loslenguajes de programación C, C++ entre otros; donde primero se de�ne el tipo de dato de la variabley a continuación, el nombre de ésta.

En las Figuras 3.29 y 3.30 se de�nen las plantillas, templates, del diseño de la prueba.

E,{Here{is{the{delcarations{of{the{Templatesthat{will{be{used{in{the{TestCase{,E

E,{Templates{written{by{Juan{Pablo{Giron{Ruiz{,E

module declaration_templates{

import from declaration_Signals{all;

E,Channel{cDisplay_Main,Etemplate sReqInfoCtrlZone{a_sReqInfoCtrlZoneZnumCtrl{p_numCtrl:numZone{p_numZone

(:={

num_Ctrl:=p_numCtrl:num_Zone:=p_numZone

}

template sInfoCtrlZone{a_sInfoCtrlZoneZspots{p_freeSpots(:={

freeSpots:=p_freeSpots}

E,Channel{cEnv_pTesting,E

template sEntryCarCtrl{a_sEntryCarCtrlZnumCtrl{p_numCtrl(:={

num_Ctrl:=p_numCtrl}

Figura 3.29: De�nición de templates a ser usados en la prueba en TTCN-3


template sOutCarCtrl?a_sOutCarCtrl(numCtrl?p_numCtrl):={

num_Ctrl:=p_numCtrl}template sEntryCarZone?a_sEntryCarZone(numZone?p_numZone):={

num_Zone:=p_numZone}template sOutCarZone?a_sOutCarZone(numZone?p_numZone):={

num_Zone:=p_numZone}

/*Channel?cEnv_Main?*/

template sCreateCtrlZone?a_sCreateCtrlZone:=?template sOkCreationZone?a_sOkCreationZone:=?template sOkCreateCtrl?a_sOkCreateCtrl:=?

template sAddZone?a_sAddZone(numCtrl?p_numCtrl,spots?p_totalSpots,spots?p_freeSpots):=

{num_Ctrl:=p_numCtrl,totalSpots:=p_totalSpots,freeSpots:=p_freeSpots

}

Figura 3.30: Continuación de�nición de templates a ser usados en la prueba en TTCN-3

La razón por la cual se crean templates en TTCN-3 es porque estos se enviarán al sistema bajoprueba; además tienen la propiedad que los parámetros de la señal puedan ser de�nidos varias veces,lo que permite enviar al sistema bajo prueba una señal con distintos datos; en contraposición a lo quese hacía con la interfaz grá�ca donde sólo se podía modi�car un parámetro de una señal por botón.Nuevamente, existe una diferencia de declaración de templates si las señales tienen parámetros deaquellas que no los tienen. El símbolo ? en el lenguaje TTCN-3 quiere indicar que cuando se recibao se envíe una señal sin parámetros no interesa su contenido. Las señales del diseño en SDL quecontengan parámetros son de�nidas en los templates indicando el nombre de cada parámetro y surespectivo valor.

La Figura 3.31 de�ne los puertos y el componente sobre el cual se va a realizar la prueba. Elnombre que se de�ne para el puerto debe ser el mismo que el nombre de�nido en el canal del diseñoen SDL. El componente en TTCN-3 indica el sistema en SDL que va a ser probado.

3.2. Pruebas 59

/ODHereDisDtheDdeclarationDofDtheDportswhereDtheDmessagesDareDsentkDbesidesisDtheDdefinitionDofDtheDcomponentDO/

module declaration_portsNComponent{

import from declaration_templatesDall;import from declaration_SignalsDall;

type port cDisplay_Main_typeDmessage{

out sReqInfoCtrlZone;in sInfoCtrlZone

}

type port cEnv_pTesting_typeDmessage{

out sEntryCarCtrl;out sOutCarCtrl;out sEntryCarZone;out sOutCarZone;

}

type port cEnv_Main_typeDmessage{

out sCreateCtrlZone;out sAddZone;in sOkCreateCtrl;in sOkCreationZone;

}type component System{

port cDisplay_Main_typeDcDisplay_Mainport cEnv_pTesting_typeDcEnv_pTestingport cEnv_Main_typeDcEnv_Main

}}

Figura 3.31: De�nición de los puertos y componentes de la prueba en TTCN-3

Hasta el momento se han explicado las estructuras básicas para de�nir casos de prueba al diseñodel sistema en SDL usando TTCN-3. Las Figuras 3.32, 3.33 y 3.34 representan la de�nición de unbanco de pruebas para determinar si, a partir de un escenario de entrada y salida de vehículos,en una hora dada, la cantidad de plazas libres del sistema de parqueo y de cada una de las zonascorresponden al valor esperado.


.xvDescription:Herevisvdefinedvthevtc_EntryNoutCarSystemwhichvconsistvinvtestvifvthevsystemsatisfiesvwithvtheventryvandvoutvofcar(vthevobjetivevisvtovfeedvthevsystemwithvrealvdatasvandvdovavrequestvtovthevsystemaboutvonevzonevinvonevspecificvpCtrlvandobservervthevfreeSpotsvofvthisvzonevx.

module Testbench_EntryNOutCarSystem{import from declaration_Signalsvall;import from declaration_portsNComponentvall;import from declaration_templatesvall;

.xvImportvofvDatavofvEntrancevandvExitvofvCarsvx.

import from In_Out_Carsvall;

.xFunctionsx.

function f_EntryCar;numCtrlvnCtrl(numZonevnZoneI runs on System{

cEnv_pTesting)send;a_sEntryCarCtrl;nCtrlII;cEnv_pTesting)send;a_sEntryCarZone;nZoneII;

}

function f_OutCar;numCtrlvnCtrl(numZonevnZoneI runs on System{

cEnv_pTesting)send;a_sOutCarCtrl;nCtrlII;cEnv_pTesting)send;a_sOutCarZone;nZoneII;

}

function f_RequestInfoCtrl_Zone;numCtrlvnCtrl(numZonevnZoneI runs on System{

cDisplay_Main)send;a_sReqInfoCtrlZone;nCtrl(nZoneII;}

.xTestCasesx.testcase tc_EntryCar;numCtrlvp_numCtrl(numZonevp_numZoneI runs on System{

f_EntryCar;p_numCtrl(p_numZoneI;setverdict;passI;

}testcase tc_OutCar;numCtrlvp_numCtrl(numZonevp_numZoneI runs on System{

f_OutCar;p_numCtrl(p_numZoneI;setverdict;passI;

}

testcase tc_CreationCtrl;I runs on System{

cEnv_Main)send;a_sCreateCtrlZoneI;alt{[]

Figura 3.32: Construcción de un banco de pruebas en TTCN-3

3.2. Pruebas 61

cEnv_Main.receiveqa_sOkCreateCtrlI{

setverdictqpassI;}[else]{

setverdictqfailI;}

}stop;

}

testcase tc_CreationZoneqnumCtrl p_numCtrlWspots p_totalSpotsWspots p_freeSpotsI runs on System

{cEnv_Main.sendqa_sAddZoneqp_numCtrlWp_totalSpotsWp_freeSpotsII;alt{

[]cEnv_Main.receiveqa_sOkCreationZoneI{


setverdictqfailI;}

}stop;

}

testcase tc_VerifyFreeSpotsqnumCtrl nCtrl_ReqWnumZone nZone_ReqWspots freeSpotsI runs on System

{f_RequestInfoCtrl_ZoneqnCtrl_ReqWnZone_ReqI;alt{

[]cDisplay_Main.receiveqa_sInfoCtrlZoneqfreeSpotsII{


setverdictqfailI;}

}stop;

}testcase tc_initializationqI runs on System{

timer t_WaitInitializationSystem;t_WaitInitializationSystem.startq1I;t_WaitInitializationSystem.timeout;setverdictqpassI;

}

Figura 3.33: Continuación construcción de un banco de pruebas en TTCN-3


control{var integer indexkcount_numCars;var integer nCtrl_Entry;var integer nZone_Entry;var integer numCars;var integer indexHour; =OEachIHourIhasIaIindexIassignedIO=timer t_waitEntryCar;

=OTestCaseItoIInitilizationIofIwholeItheIsystemIO=

execute1tc_initialization1LL;

=OITestCaseItoIcreationIofIpCtrlIandIpZoneIO=

execute1tc_CreationCtrl1LL;execute1tc_CreationZone19k+99k+99LL;execute1tc_CreationZone1<k+99k+99LL;execute1tc_CreationZone1<k+99k+99LL;

=OLoopIforIInIandIOutIofICarsItoItheIParkingISystemO=

indexHourF=<V;

for 1indexF=9;index<[OindexHourP[;indexF=indexP<L{=OIInIcarsIO=

numCarsF=aEntryCar[index];nCtrl_EntryF=aCtrlEntryCar[index];nZone_EntryF=aZoneEntryCar[index];for 1count_numCarsF=9; count_numCars<numCars;count_numCarsF=count_numCarsP<L{

execute1tc_EntryCar1nCtrl_EntryknZone_EntryLL;t_waitEntryCar:start1}L;t_waitEntryCar:timeout;

}=OIOutICarsIO=numCarsF=aOutCar[index];nCtrl_EntryF=aCtrlOutCar[index];nZone_EntryF=aZoneOutCar[index];for 1count_numCarsF=9; count_numCars<numCars;count_numCarsF=count_numCarsP<L{

execute1tc_OutCar1nCtrl_EntryknZone_EntryLL;t_waitEntryCar:start1}L;t_waitEntryCar:timeout;

}

}numCarsF=aExpectedSpots[[OindexHour];nCtrl_EntryF=aCtrlExpected[[OindexHour];nZone_EntryF=aZoneExpected[[OindexHour];execute1tc VerifyFreeSpots1nCtrl EntryknZone EntryknumCarsLL;

Figura 3.34: Parte �nal de la construcción de un banco de pruebas en TTCN-3

Como se observa en la Figura 3.32, se han diseñado una serie de funciones y casos de pruebacon el objetivo de determinar el número de plazas libres de una zona de un controlador especí�co auna hora dada. Cuando se desea estimular el sistema con una señal se hace a través de la sentenciasend ; por el contrario si se espera un señal, se usa la sentencia receive que es de bloqueo, lo quesigni�ca que la prueba no avanza hasta que dicha señal haya llegado. El lenguaje TTCN-3 cuentacon mecanismos de coincidencia que permiten evaluar si el valor de la señal recibida corresponde conel valor esperado. De ser así, el caso de prueba, testcase , retorna un valor de pass; de lo contrario,

3.2. Pruebas 63

retornará fail si los valores no coinciden o error si existe alguna falla en el diseño de la prueba enTTCN-3.

En la parte de control del módulo del diseño de la prueba se especi�ca cuál testcase va a serejecutado; si es más de un caso de prueba, en la parte del control se da un veredicto total con baseen cada uno de los veredictos de las pruebas. Dicho veredicto �nal es pass sí y sólo sí cada uno delos resultados de los casos de prueba son del mismo valor; de lo contrario, el resultado total seráfail .

Las funciones que se de�nieron en la Figura 3.32 corresponden al ingreso o salida de un vehículode una zona en un controlador especí�co, además de una función encargada de enviar un requeri-miento de información de cuántas plazas tiene libre una zona de un controlador especí�co. Los casosde prueba que se de�nieron se muestran en la Tabla 3.6:

Tabla 3.6: De�nición de las funciones y casos de prueba cons-truidas en TTCN-3

Nombre del caso deprueba (test case)

Propósito/Resultado

tc_initializationEsperar que el sistema cumpla la primera etapa deinicialización antes de enviar los estímulos. El resultado deesta prueba se espera que sea pass.

tc_creationCtrlCrea un controlador en el sistema de parqueo. El resultadode esta prueba siempre será pass si se recibe la señala_sOkCreateCtrl.

tc_CreationZone

Crea una zona en un controlador especí�co, ajustando sucapacidad siempre a 300 plazas libres y totales. Elresultado de éste caso de prueba será pass cuando se recibala señal a_sOkCreationZone.

tc_EntryCarSimula, a través del proceso pTesting, que un carro haingresado a una zona de un controlador especí�co. Elresultado siempre será pass.

tc_OutCarSimula, a través del proceso pTesting, que un carro hasalido de una zona de un controlador especí�co. Elresultado siempre será pass.

tc_VerifyFreeSpots

Solicita al sistema la cantidad de plazas libres de una zonaen un controlador especí�co. Estipula cuál debería de ser elvalor esperado. El resultado de este caso de prueba serápass si la cantidad de plazas totales que tiene dicha zonacorresponde al esperado.

Nuevamente, en el banco de pruebas se declaró una variable llamada indexHour ; dicha variable


tiene como funcionalidad especi�car el índice correspondiente a la hora, como se explicó anterior-mente en la tabla de datos construida.

Las Figuras 3.35 y 3.36, muestran el resultado de la prueba al esperar que las plazas libres dela zona 0 del controlador 0 del sistema sea de 156.

Figura 3.35: Resultado de la prueba de veri�car las plazas libres de una zona en un controladorespecí�co a una determinada hora

Figura 3.36: Reporte de la última señal con el valor esperada de la cantidad de plazas libres en lazona 0 del controlador 0 en la herramienta RTDS

Después de la fase de creación de controladores con sus respectivas zonas a través de TTCN-3,las plazas libres y totales de todas las zonas de los controladores son 1200. Estimulando el sistemacon entrada y salidas de vehículos hasta las 6:50 a.m. (véase las Figuras 3.24 y 3.25), se espera quea esa hora, que corresponde al índice 19, la zona 0 del controlador 0 tenga 156 plazas libres comose muestra en la Figura 3.26. El resultado fue satisfactorio, lo que indica que para este escenario eldiseño funcionó como se esperaba.

La Figura 3.37 ilustra la con�guración del banco de pruebas diseñada para probar que las plazaslibres en cada momento después de ingresar o salir vehículo corresponden al valor deseado.

3.2. Pruebas 65

control{var integer indexkcount_numCars;var integer nCtrl_Entry;var integer nZone_Entry;var integer numCars;var integer indexHour; =OEachIHourIhasIaIindexIassignedIO=timer t_waitEntryCar;

=OTestCaseItoIInitilizationIofIwholeItheIsystemIO=

execute1tc_initialization1LL;

=OITestCaseItoIcreationIofIpCtrlIandIpZoneIO=

execute1tc_CreationCtrl1LL;execute1tc_CreationZone1<k]<<k]<<LL;execute1tc_CreationZone1+k]<<k]<<LL;execute1tc_CreationZone1+k]<<k]<<LL;

=OLoopIforIInIandIOutIofICarsItoItheIParkingISystemO=

for 1index:=<;index<length_array_data;index:=indexP+L{=OIInIcarsIO=numCars:=aEntryCar[index];nCtrl_Entry:=aCtrlEntryCar[index];nZone_Entry:=aZoneEntryCar[index];for 1count_numCars:=<; count_numCars<numCars;count_numCars:=count_numCarsP+L{

execute1tc_EntryCar1nCtrl_EntryknZone_EntryLL;t_waitEntryCar:start1DL;t_waitEntryCar:timeout;

}=OIOutICarsIO=numCars:=aOutCar[index];nCtrl_Entry:=aCtrlOutCar[index];nZone_Entry:=aZoneOutCar[index];for 1count_numCars:=<; count_numCars<numCars;count_numCars:=count_numCarsP+L{

execute1tc_OutCar1nCtrl_EntryknZone_EntryLL;t_waitEntryCar:start1DL;t_waitEntryCar:timeout;

}=OLoopIforIVerifyIExpectedIDatasIO=numCars:=aExpectedSpots[index];nCtrl_Entry:=aCtrlExpected[index];nZone_Entry:=aZoneExpected[index];execute1tc_VerifyFreeSpots1nCtrl_EntryknZone_EntryknumCarsLL;

}}

}

Figura 3.37: Con�guración módulo de control para probar que las plazas libres de cada zona corres-ponden a las deseadas cada vez que ingresen o salgan vehículos

Los tipos de datos, señales, declaración de puertos y del componente a ser probado son los mismosque se usaron para hacer las pruebas representadas en la Figura 3.32. De hecho, lo único que cambiaen la con�guración del control es que cada vez que ingresen y salgan vehículos de una zona en unahora especí�ca, se evalúa por medio del caso de prueba tc_VerifyFreeSpots la cantidad de plazaslibres de dicha zona en ese instante de tiempo.

El resultado de la prueba se muestra en la Figura 3.38.


Figura 3.38: Veredicto total de la prueba de evaluar las plazas libres de cada zona a cada hora

Los diagramas MSC correspondientes al resultado de las pruebas realizadas en TTCN-3 sepueden encontrar en el Anexo Digital.

3.3. Veri�cación Formal usando IFx

Los métodos formales tienen un papel muy importante en la construcción de sistemas críticos,veri�cando que el diseño del sistema cumpla con algunas propiedades deseadas, lo que provee sis-temas embebidos y software más con�ables. Model Checking es una técnica de veri�cación formalque hace una exploración exhaustiva a los estados del sistema al sistema veri�cando si la propiedaddeseada se satisface en el modelo. La técnica de Model Checking sirve para depurar el modelo di-señado a partir de contraejemplos generados si la propiedad deseada no se cumple; para hacer usode un Model Checker es necesario que el sistema esté expresado en un lenguaje con una semánticaformal. IF es un lenguaje construido por VERIMAG que posee una semántica formal; la construc-ción de sistemas descritos en IF se puede veri�car por medio de algún Model Checker. Actualmentees posible diseñar sistemas en SDL y traducir éstos a IF de forma automática.

3.3.1. Consideraciones para Veri�car Sistemas Descritos en IF

Soporte de IF en la herramienta RTDS. La herramienta RTDS permite traducir unsistema descrito en SDL al lenguaje IF de forma automática. La transformación de un lenguajea otro es hecha a través de un algoritmo construido por RTDS, ya que la herramienta SDL2IFque ofrecía ObjectGEODE no está disponible. A pesar de que la traducción de SDL a IF pormedio de la herramienta RTDS facilita la fase de traducción del sistema, existen problemascon dicha traducción. Durante el desarrollo de éste trabajo de grado se reportaron diferentesfallas de la herramienta a Pragmadev las cuales se describen a continuación.

• Consideraciones para el acceso a estructuras de datos. Algunos tipos de acceso a lasestructuras de datos soportados en el lenguaje SDL no son soportadas en la traducción

3.3. Veri�cación Formal usando IFx 67

a IF. A continuación se presenta un ejemplo de un tipo de acceso que no es traducidopor la herramienta, y al tratar de exportar el sistema a IF deja la herramienta RTDSbloqueada:

◦ PidZone := infoCtrlG!listZones(index)!ID

Lo que se pretendía hacer con el acceso a dicha estructura era obtener el identi�cadorde un proceso pZone, con dicha información se pueden ajustar los parámetros de di-cho proceso como lo son plazas totales y libres, además de solicitar requerimientos deinformación.

La Figura 3.39 representa la solución dada por el equipo de soporte de RTDS. Por elmomento es necesario crear variables temporales que permitan almacenar estructuras dedatos intermedias para sacar la información deseada a partir de éstas.

Figura 3.39: Solución para el acceso de estructuras de datos

• Consideraciones para la construcción del diseño en SDL. La herramienta RTDSpermite crear varias particiones en la interfaz del diseño de procesos en SDL. Debidoa que algunos estados poseen muchas señales de entrada, un estado se puede colocarnuevamente en otra partición y de�nir las señales que desea ver en dicha partición; si lasseñales del estado en dicha partición no son fáciles de leer se puede repetir cuantas vecessea necesario el proceso anterior.

Colocar un mismo estado en varias particiones tiene por objetivo ver mejor el diseño dela máquina de estados �nitos dando un mejor orden, pero ocasiona un problema en latraducción de SDL a IF, a pesar que en la fase de simulación y pruebas no ocasiona incon-venientes. Cuando el algoritmo está traduciendo el sistema de SDL a IF se de�nen todoslos estados que hay en las particiones, así en ésta se encuentre un estado previamentede�nido. En el momento de ejecutar la herramienta IFx se presenta un error relacionadocon la rede�nición de estados. Este es un problema que posee la herramienta RTDS, yactualmente no existe una solución automática; por ello, no se debería dividir un estadoen varias particiones desde la herramienta RTDS, o si ya se ha generado el archivo .IF,éste debe ser modi�cado manualmente. Si se desea modi�car el archivo .IF, la soluciónconsiste en encontrar, dentro de cada proceso identi�cado con la palabra process, los


estados que se encuentran repetidos, que se pueden identi�car por la sentencia state , ysolo dejar uno de�nido, con todas las señales que él recibe.

Limitaciones de la técnica Model Checking para las señales externas del modelo.Dado que la herramienta IFx veri�ca los sistemas por medio de la técnica Model Checking,es necesario limitar a rangos las señales de entrada que son externas al sistema; si no se hacelo anterior, entonces no se podrá veri�car el modelo ya que la herramienta arrojará un errordescribiendo que no se ha declarado el tipo de dato Integer, en el caso que la señal de entradasea un entero no limitado.

Una vez asumidas las consideraciones de las herramientas RTDS e IFx, se procede a diseñar losobservadores, los cuales nos permiten expresar las propiedades que deseamos veri�car en nuestrosistema.

3.3.2. De�nición de Propiedades Safety

Al igual que la construcción del sistema en SDL y las pruebas, se ha veri�cado una propiedaddel proceso pZone, el cual cuenta con un bajo nivel de abstracción y es una de las partes del sistemade parqueo más críticos, ya que si no funciona adecuadamente, entregará una información errada alusuario acerca de las plazas libres. La técnica de Model Checking posee un problema conocido comoexplosión de estados, y se da cuando a la representación del modelo se le derivan todos sus posiblesestados y transiciones y éstos no pueden ser computados dada su complejidad espacio-temporal.

Especi�caciones de la computadora que ejecutó la herramienta IFxLa computadora que fue utilizada para ejecutar la herramienta IFx cuenta con las siguientes

características:

Dell PowerEdge R815 Chassis 2U: Four AMD Opteron 6376 processors, 2.3GHz, 16Co-res/processor; Four 1.2TB 10K RPM SAS 6Gbps 2.5in Hot-plug Hard Drive; 64GB Me-mory,(8x8GB) 1600MT/s; Intel X520-T2 10GbE NIC, Dual Port.

Switch: Dell PowerConnect 8132, 24x 10GBase-T ports.

Dado que la técnica Model Checking hace una exploración exhaustiva a los estados del sistema,ésta exige muchos recursos computacionales como procesamiento y memoria; lo anterior se considerócon el �n de ejecutar la herramienta en dicha computadora.

De�nición de la propiedad para el proceso pZone. Los métodos formales en la etapa dedepuración del diseño son útiles para veri�car propiedades las cuales el modelo debería de satisfacery que por medio de pruebas funcionales de caja negra serían casi imposibles de obtener, como porejemplo: detectar que el sistema no presente deadlocks. Las propiedades a veri�car son descritas apartir de las especi�caciones del sistema.

La propiedad que se desea veri�car es la siguiente:

�Independiente de cuál sea la señal de entrada al proceso pZone, éste ejecutará las transiciones

correspondientes y evolucionará al estado Idle�


La anterior propiedad es equivalente a decir que el proceso pZone está libre de deadlocks4.

Las Figuras 3.40 y 3.41 describen la máquina de estados del proceso pZone con las consideracionesplanteadas previamente. La diferencia de este diseño al descrito en la parte de modelado del sistema,es que en una sola partición se encuentra el estado Idle con todas sus entradas, con el �n de evitarque en la fase de ejecución de la herramienta IFx salgan errores de rede�nición de estados.

sIRP_ZonesIRm_Zone

VerifyIsaCarOut

sIR/_Zone

totalSpots):=)BgfreeSpots):=)B

sInitFreeSpotqp_freeSpotsd

RESETqtEnterd

sOkInit)VIA)cCtrl_ZoneWaitSensorIR*

sReqInfo

freeSpots):=)p_freeSpots

sIRm_Zone

IdleSETqNOW+PgtOutd

tOut

SETqNOW+Pg)tOutd

Idle

totalSpots):=)p_totalSpots

−

sIR*_Zone

SETqNOW+Pg)tEnterd

sIRP_Zone

sIR*_Zone

sOkInit)VIA)cCtrl_Zone


TIMER)tEntergtOut;

Idle

tEnter

WaitSensorIRm

DCL

DN)Params)Signals)NDp_freeSpotsgp_totalSpots)i_spotsg

DNBlock)Zone’s)Registers)NDfreeSpotsgtotalSpots)i_spotsgpidCtrlgmyCtrl)PID;

RESETqtOutd

−

RESETqtOutd

sInfoZoneqtotalSpotsgfreeSpotsd)VIA)cCtrl_Zone

sInitTotalSpotsqp_totalSpotsd

SETqNOW+PgtEnterd

sIR/_Zone

−

RESETqtEnterd

Figura 3.40: Máquina de estados del proceso pZone adecuada para IF

false

true

true

false

IdleIdle

sLoopInductive_Zone

freeSpots=totalSpots

tEnter tOut

sOut_Car(freeSpots)yVIAycCtrl_Zone

RESET(tEnter)

RESET(tEnter) RESET(tOut)


freeSpots=0

freeSpots:=freeSpots−1

VerifyIsaCarOut

sEntered_Car(freeSpots)yVIAcCtrl_Zone

Idle

RESET(tOut)

Idle

freeSpots:=freeSpots+1

Idle

sLoopInductive_Zone

Idle

sOut_Car(freeSpots)yVIAycCtrl_Zone

sEntered_Car(freeSpots)yVIAycCtrl_Zone

Figura 3.41: Continuación máquina de estados del proceso pZone

4Deadlock: Un deadlock es una condición del sistema y ocurre cuando al menos algún componente del sistema no

se encuentra en un estado terminal y no puede salir de éste con las señales que le corresponde. Otra situación que

coloca al sistema en deadlock es cuando dos o más procesos esperan por un recurso del sistema, y el proceso que lo

tenga no lo libera [BK08, CDK05]


Las Figuras 3.42 y 3.43 representan la propiedad que se desea veri�car en el proceso pZone.Básicamente lo que muestra éste observador es que para todas las posibles entradas que tiene elproceso pZone las transiciones llegarán en algún momento al estado Idle.

truefalse

sError

input_sInitTotalSpots(pidSender,vSpot)_in_pidZone

cut

cut

input_sInitFreeSpot(pidSender,vSpot)_in_pidZone

true

Prove

cut

DEAD

sError_0error

true

END

DEAD

var_pidSender_pid;var_pidZone_pid;var_vSpot_i_spots;

({pZone}0)_instate_Idle

END

Figura 3.42: De�nición de la propiedad garantizando que el proceso pZone no tenga Deadlocks

truefalse

sErrorEND

outputPsOut_Car(pidSender,vSpot)PfromPpidZoneoutputPsEntered_Car(pidSender,vSpot)PfromPpidZone

({pZone}0)PinstatePIdle

Prove

inputPsReqInfo(pidSender)PinPpidZone

Figura 3.43: Continuación de�nición de la propiedad garantizando que el proceso pZone no tengaDeadlocks

El observador descrito en la Figura 3.42, se podría traducir en la siguiente secuencia:

1. El observador empieza con un símbolo de start y entra inmediatamente en un estado que se


llama Prove.

2. Una vez en el estado Prove se espera hacer coincidencia con algunas de las siguientes señales:

sInitFreeSpot

sInitTotalSpots

sReqInfo

sEntered_Car

sOut_Car

Nótese que no se han considerado las señales correspondientes a los sensores infrarrojos quedetectan si un vehículo ha pasado por éstos, lo anterior se podría reemplazar por las señalesde un nivel de abstracción mayor: sEntered_Car y sOut_Car, que solo son emitidas porel proceso pZone cuando un vehículo ha ingresado o salido de una zona, respectivamente.

3. El observador solo evalúa cada una de sus entradas, input , o salidas, output , cuando elsistema cambie de un estado a otro.

4. Con la sentencia instate se puede veri�car si un proceso se encuentra en dicho estado; el valorque retorna esta sentencia es true o false . Se espera que siempre el resultado sea true paraésta propiedad; de ésta forma se garantizará la ausencia de deadlocks en el dicho proceso.

5. Cada vez que se veri�que que el proceso pZone se encuentra en el estado Idle, se marcará comosatisfactorio el escenario propuesto por el model checker, y éste creará un nuevo escenario.De lo contrario, si el proceso pZone queda en otro estado diferente al Idle, entonces dichoescenario será un contraejemplo que el model checker mostrará.

Como se comentó previamente, la herramienta RTDS presenta algunos errores en la traducciónde SDL a IF. Esto también se ve re�ejado cuando se traduce el observador: como se puede observaren la Figura 3.42 todas las señales que se esperan se unen al mismo símbolo de condición dondese evalúa si el proceso pZone se encuentra en el estado Idle. En este punto, el algoritmo de laherramienta RTDS escribe 5 veces el mismo estado; dado que un condicional en SDL es equivalenteen IF a tener un estado temporal precedido de una señal continua. Para corregir este problema semodi�có el archivo .IF generado por la herramienta como se muestra en la Figura 3.44.


000000

stateYProveY;matchYinputYsInitTotalSpotsqpidSender{vSpotOYinYpidZone;nextstateYRTDS_decision_SYMB8;matchYoutputYsEntered_CarqpidSender{vSpotOYfromYpidZone;nextstateYRTDS_decision_SYMB8;matchYinputYsInitFreeSpotqpidSender{vSpotOYinYpidZone;nextstateYRTDS_decision_SYMB8;matchYinputYsReqInfoqpidSenderOYinYpidZone;nextstateYRTDS_decision_SYMB8;matchYoutputYsOut_CarqpidSender{vSpotOYfromYpidZone;nextstateYRTDS_decision_SYMB8;endstate;

stateYRTDS_decision_SYMB8Y8unstableY;

providedYnotYqq{pZone}/OYinstateYIdleO;nextstateYsError;

providedYq{pZone}/OYinstateYIdle;nextstateYEND;endstate;












providedYq{pZone}/OYinstateYIdle;nextstateYEND;endstate;000000

000000

stateYProveY;matchYinputYsInitTotalSpotsqpidSender{vSpotOYinYpidZone;nextstateYRTDS_decision_SYMB8;matchYoutputYsEntered_CarqpidSender{vSpotOYfromYpidZone;nextstateYRTDS_decision_SYMB8;matchYinputYsInitFreeSpotqpidSender{vSpotOYinYpidZone;nextstateYRTDS_decision_SYMB8;matchYinputYsReqInfoqpidSenderOYinYpidZone;nextstateYRTDS_decision_SYMB8;matchYoutputYsOut_CarqpidSender{vSpotOYfromYpidZone;nextstateYRTDS_decision_SYMB8;endstate;

N#stateYRTDS_decision_SYMB8Y8unstableY;











providedYq{pZone}/OYinstateYIdle;nextstateYEND;endstate;#NstateYRTDS_decision_SYMB8Y8unstableY;


providedYq{pZone}/OYinstateYIdle;nextstateYEND;endstate;000000

Commented

Figura 3.44: Modi�cación del observador para corregir el problema de rede�nición de estados


El diseño del proceso pZone satis�zo la propiedad propuesta; el resultado de la veri�caciónusando la herramienta IFx se aprecia en la Figura 3.45:

00:00:00uuuuuuuu339/suuuuuuuu371/tuuuulabelutableu:uuuuu686uitemsuuuuuuuuuu29/entryu16/minu44/maxuu23.66/avguuueventutableu:uuuuuu214uitemsuuuuuuuu13/entryu16/minu24/maxu16.46/avguuconfigutableu:uuuuu339uitemsuuuuuuuu13/entryuu24/minu36/maxu26.08/avguuuchunkutableu:uuuuu339uitemsuuuuuuuu13/entryuu20/minu36/maxu26.08/avginstanceutableu:u437uitemsuuuuuuuuu29/entryu12/minu24/maxu15.07/avguuuqueueutableu:uuuuuuuu0uitemsuuuuuuuuu13/entryuu0/minuu0/maxuuuu0.00/avgumessageutableu:uuuuu212uitemsuuu13/entryuu16/minu20/maxu16.31/avgnouerrorustate

Figura 3.45: Resultado de la herramienta IFx para la propiedad de ausencia de Deadlocks

La herramienta IFx a partir del diseño del proceso pZone determinó que todas sus posibilidadesde entrada y salida de mensajes se pueden dar en 339 estados y 371 transiciones con dicho observador,para garantizar que ésta propiedad se cumple. La otra información presentada por la herramientaes de depuración; para más información consulte [BGO+04].

Análisis de contraejemplos generados al veri�car una propiedad. El diseño de la má-quina de estados mostrada en la Figura 3.40, presenta un problema de diseño bastante común, y hasido puesto a propósito para mostrar que por medio de técnicas formales como el Model Checkingse puede encontrar este tipo de problemas y son mostrados a través de contraejemplos.

Una de las especi�caciones que tiene el proceso zona, pZone, es de reportar cuándo un vehículoha ingresado o salido de dicha zona; siempre y cuando se reciba una secuencia de señales de sensoresestablecida, que son las siguientes:

Para el ingreso de un vehículo. Se reciben en orden las señales: sIR1_Zone, sIR2_Zone y�nalmente sLoopInductive_Zone. Otra forma de saber si un vehículo ha ingresado es cuandose reciban las siguientes señales en su respectivo orden: sIR4_Zone, sIR3_Zone y �nalmentesLoopInductive_Zone.

Para la salida de un vehículo. Se reciben en orden las señales: sIR3_Zone, sIR4_Zoney �nalmente sLoopInductive_Zone. Otra forma de saber que un vehículo salió de la zona deparqueo es cuando se reciban las siguientes señales en el siguiente orden: sIR2_Zone, IR1_Zoney �nalmente sLoopInductive_Zone.

A partir de las especi�caciones para la detección de ingreso o salida de vehículos se diseña elobservador como se aprecia en las Figuras 3.46 y 3.47. La propiedad que describe dicho observadores:

�una zona siempre reportará si un vehículo ha ingresado enviando una señal llamada sEnte-red_Car; sí y sólo sí, se reciben las siguientes secuencias de sensores: sIR1_Zone, sIR2_Zone y

sLoopInductive o sIR4_Zone, sIR3_Zone y sLoopInductive.�


Figura 3.46: Propiedad Ingreso de vehículo en una zona a partir de un observador

Figura 3.47: Continuación propiedad Ingreso de vehículo en una zona a partir de un observador

Dado que la exploración de estados del modelo incrementa a medida que las plazas libres ytotales de una zona son mayores, se ha ajustado en el modelo que la cantidad máxima de plazases de 3; con lo anterior, limitamos que el Model Checking tenga explosión de estados. A pesar quelas plazas totales y libres son mucho menores que las usadas en la fase de pruebas, esto no altera elpropósito de la veri�cación.


La propiedad especi�cada previamente no la satis�zo el diseño del proceso pZone como se mues-tra en la �gura 3.48, por lo cual se han generado todos los posibles contraejemplos. Uno de ellos sedescribe en las Figuras 3.49 y 3.50, nuevamente la herramienta RTDS permite agregar automática-mente el contraejemplo como un MSC o permite crear un caso de prueba en TTCN-3 que conllevaa que el diseño planteado no satisfaga dicha propiedad. En este caso nos hemos concentrado en elanálisis del contraejemplo a través de diagramas MSCs.

Figura 3.48: Resultado del Model Checker después de veri�car la propiedad de ingreso de vehículo


Las Figuras 3.49 y 3.50 muestran algunos contraejemplos que el Model Checker construyó.

RTDS_start_process615

obsEnterCar625

pZone635

RTDS_Env605

sIR4_Zone

sIR2_Zone

sEntered_Car625

sLoopInductive_Zone

top:VerifyIsaCarEntering

120

120

120

80

120 top:Idle

130 top:sError

top:sSignals

top:RTDS_START

60

60

30

60

50

70

120

top:Idle

30 top:RTDS_START

top:RTDS_START

80

80 top:WaitSensorIR2

100

100

100

Figura 3.49: Contraejemplo 1, secuencia no permitida para el ingreso de un vehículo


obsEnterCary2g

pZoney3g

RTDS_Envy0g

RTDS_start_processy1g

sIR1_Zone

sLoopInductive_Zone

sIR3_Zone

sEntered_Cary2g

top:RTDS_START

60

30

120

60

50

top:RTDS_START

70

30

80

80

80 top:WaitSensorIR2

100

100

100 top:VerifyIsaCarEntering

120

top:sSignals

120

top:RTDS_START

120

60

120 top:Idle

130 top:sError

top:Idle

Figura 3.50: Contraejemplo 2, secuencia no permitida para el ingreso de un vehículo


Lo que nos indican los contraejemplos es que en el estado sWaitSensorIR2 se puede recibirla señal sIR3_Zone al igual que la señal sIR2_Zone; lo anterior indica que si se recibe la señalsIR1_Zone se espera que lleguen las señales de los sensores sIR2_Zone y sIR3_Zone, lo cual no esválido dado que si se recibe la señal sIR1_Zone se espera que llegue sólo la señal sIR2_Zone y nosIR3_Zone; en el caso de recibir la señal sIR4_Zone se espera que llegue la señal sIR3_Zone y nola señal sIR2_Zone. La solución para evitar este tipo problemas es dividir las señales que recibe elestado sWaitSensorIR2 en otro estado, como se muestra en la Figura 3.51.


Idle

SE

T=N

OW

Ly/

AtEnt

erq

sIni

tFre

eSpo

t=p_

free

Spo

tsq

RE

SE

T=t

Ent

erq

sIR

B_Z

one

sOkI

nitAV

IAAc

Ctr

l_Z

one

sIR

;_Z

one

Wai

tSen

sorI

R’

RE

SE

T=t

Out

q

SE

T=N

OW

Ly/

tOut

q

free

Spo

tsA:=

Ap_f

reeS

pots

Wai

tSen

sorI

RB

Idle

SE

T=N

OW

Ly/

tEnt

erq

Idle

tEnt

er

SE

T=N

OW

Ly/

tEnt

erq

RE

SE

T=t

Out

q

−

RE

SE

T=t

Out

q

sReq

Info

SE

T=N

OW

Ly/

tOut

q

DC

L

mDAP

aram

sAS

igna

lsAD

mp_

free

Spo

ts/p

_tot

alS

pots

Ai_sp

ots/

mDB

lock

AZon

e’sA

Reg

iste

rsAD

mfr

eeS

pots

/tota

lSpo

tsAi_

spot

s/pi

dCtr

l/myC

trlAP

ID;

RE

SE

T=t

Out

q

SE

T=N

OW

Ly/

AtOut

q

Wai

tSen

sorI

Ry

RE

SE

T=t

Ent

erq

sIR

y_Z

one

−

Idle

sIni

tTot

alS

pots

=p_t

otal

Spo

tsq

SE

T=N

OW

Ly/

AtEnt

erq

sIR

’_Z

one

Ver

ifyIs

aCar

Out

Ver

ifyIs

aCar

Ent

erin

gV

erify

IsaC

arO

ut

sOkI

nitAV

IAAc

Ctr

l_Z

one

TIM

ER

AtEnt

er/tO

ut;

sInf

oZon

e=to

talS

pots

/free

Spo

tsqA

VIA

AcC

trl_

Zon

e

RE

SE

T=t

Ent

erq

−

tEnt

ersI

Ry_

Zon

e

sIR

;_Z

one

sIR

’_Z

one

tota

lSpo

tsA:=

Ay/

free

Spo

tsA:=

Ay

Wai

tSen

sorI

R;

tOut

tota

lSpo

tsA:=

Ap_t

otal

Spo

tsS

ET

=NO

WL

y/AtO

utq

RE

SE

T=t

Ent

erq

Ver

ifyIs

aCar

Ent

erin

g

tOut

Idle

sIR

B_Z

one

Figura 3.51: Máquina de estados del proceso pZone corregido


En la Figura 3.52 se expresa la misma propiedad planteada previamente por medio de un ob-servador, con la diferencia que en el estado sWaitSensorIR2 sólo se recibirá la señal del sensorsIR2_Zone; y cuando un vehículo interrumpa el sensor sIR4_Zone al ingresar, existe un estadollamado sWaitSensorIR3 que espera la señal sIR3_Zone. De esta forma se garantiza que una zonareportará el ingreso de un vehículo según las especi�caciones dadas.

Figura 3.52: Propiedad del ingreso de un vehículo en una zona a través de un observador

Al ejecutar la veri�cación con la herramienta IFx, el resultado fue satisfactorio.

Capítulo 4

Análisis y Discusión

Hacer uso de herramientas como RTDS que permiten integrar lenguajes como TTCN-3 e IF parala especi�cación y veri�cación de errores en el diseño de sistemas, hace que sea posible mezclar deforma más sencilla dos técnicas tales como: métodos formales y pruebas, en una sola metodologíaque tiene como objetivo la minimización de errores en el diseño de sistemas distribuidos.

El sistema de parqueo de la PUJC como caso de estudio, posibilita que en un futuro el diseño ymodelado del mismo pueda ser expandido; además, diseñar diferentes pruebas y observadores quepermitan obtener un sistema más con�ables y que pueda ser implementado.

Como se explicó en el capítulo previo, se hizo uso de la herramienta RTDS para hacer el modeladodel sistema de parqueo de la PUJC en SDL; posteriormente, se hizo uso de los módulos de simulaciónque provee dicha herramienta para depurar los errores de diseño. Con el objetivo de probar el sistemaa partir de datos reales, se implementaron bancos de pruebas funcionales de caja negra sobre ellenguaje TTCN-3. Finalmente se utilizó el módulo de conversión de SDL a IF que posee RTDS paraobtener el sistema expresado en IF y usar éste para veri�car formalmente una propiedad usando laherramienta IFx.

4.1. Uso de las Herramientas

4.1.1. RTDS

Para el modelado. A pesar de que la herramienta RTDS en su versión 4.4.1 no soporta todoel lenguaje MSC y SDL, para la elaboración del modelado del caso de estudio fue su�ciente conlos soportes de dichos lenguajes. Para más información acerca del soporte del lenguaje SDL sobreRTDS, véase el manual de referencia.

Para la simulación. La herramienta cuenta con un módulo de simulación que permite probarel modelo de una forma sencilla, lo que permite evaluar funciones del sistema para la búsqueda ycorrección de errores en las primeras fases de depuración del diseño. A pesar de que la herramientade simulación que tiene RTDS facilita la rápida detección de errores, ésta se encuentra limitada encuanto a la automatización de estímulos a los módulos del sistema que se desean probar. Si bien,la herramienta RTDS cuenta con una función de grabar las señales en el mismo orden y valor conque fueron enviadas al sistema, éstas no pueden ser modi�cadas de forma sencilla para establecerun nuevo orden y otros valores de las señales; además, cabe destacar que a través del simulador noes posible indicar cuál es la respuesta esperada del sistema, sino que se da de forma visual a travésde un diagrama MSC generado por la herramienta o en su terminal de comandos.

Para el diseño de pruebas funcionales a través de una interfaz grá�ca. La herramientasoporta la creación de una interfaz grá�ca cuyo propósito es establecer, a través de objetos tipo

82 Capítulo 4. Análisis y Discusión

botón, señales que serán enviadas el sistema bajo prueba. Por otra parte, se pueden utilizar objetosde diseño de tipo indicador, que sirven para monitorear una salida del sistema; no es posible, sinembargo, ajustar el valor de la señal esperada para automatizar el resultado de la prueba.

Efectivamente, las interfaces grá�cas proporcionan un mejor esquema visual para efectuar unasecuencia de operaciones, pero en el caso de la herramienta RTDS dicha construcción mejora laforma en que los estímulos son generados pero disminuye su efectividad por varios factores. Unode ellos es que no es posible automatizar los estímulos que son enviados al sistema bajo prueba.Segundo los objetos de diseño que posee la interfaz carecen de funciones y atributos que permitenmodi�car más de un parámetro de una señal; por ejemplo, si se deseara modi�car cada parámetrode una señal por medio de un único objeto de tipo botón, no sería posible hacerlo. Si se deseaeste tipo de pruebas es necesario modi�car el diseño del sistema o diseñar procesos en SDL quepermitan ajustar una señal de n parámetros en n estados, lo que sería un proceso poco práctico sise consideran varias señales con las mismas características.

Para el diseño de pruebas usando TTCN-3. La herramienta en la versión 4.4.1 soportaparcialmente este lenguaje, pero sus limitantes no fueron impedimento para evaluar el diseño delsistema de parqueo a través de datos reales. RTDS proporciona un acople para las pruebas descritasen TTCN-3 a diseños en SDL de forma sencilla. Adicionalmente se pueden automatizar bancosde pruebas, y a partir de un mecanismo de coincidencia que posee el lenguaje TTCN-3, se puededeterminar automáticamente si la prueba fue satisfactoria cuando el sistema llega al valor deseado.

En el mercado podemos encontrar herramientas especializadas que soportan el lenguaje TTCN-3como se muestra en la Tabla 4.1.

4.1. Uso de las Herramientas 83

Tabla 4.1: Herramientas que soportan el lenguaje TTCN-3

ProveedorNombre de laherramienta

Descripción General Licencia

Pragma-dev1

Real TimeDeveloper Studio

Soporta parcialmente ellenguaje TTCN-3.Actualmente solo se puedenhacer pruebas funcionales aun único componente. No esposible manejar estructurasde datos complejas, lo cualimplica hacer acoples aldiseño con el �n de obtenerinformación del mismo.Permite acoplar un diseño enSDL a TTCN-3 de formasencilla.

Posee una licencia académicade carácter gratuito convigencia de un año.

OpenTTCNLtd2

OpenTTCN

Soporta el lenguaje TTCN-3de forma completa, vieneintegrado con adaptadoresgenéricos para hacer pruebasa sistemas descritos en otroslenguajes, como C, C++,entre otros. Soporta pruebasen paralelo. No posee unaintegración sencilla con ellenguaje SDL.

Es posible obtener unalicencia gratis por unosmeses, después de ese periodode prueba hay que comprar laherramienta. El valor de éstano está disponible en lapágina principal delproveedor.

Testing-Tech3

TTworkbench

Software especializado parahacer pruebas funcionalessobre TTCN-3. Soporta todala norma del lenguajeTTCN-3. No posee unaintegración sencilla con ellenguaje SDL.

Posee una licencia gratis parausar el programa con susfunciones básica. Lainformación del costo de éstaherramienta no estádisponible en la página web.

Sigue en la página siguiente.

1Para más información de la compañía consulte la página: http://www.pragmadev.com/index.html2Para más información de la compañía consulte la página: http://www.openttcn.com/3Para más información de TestingTech consulte la pgina: http://www.testingtech.com/company/about_us.php

http://www.pragmadev.com/index.html

http://www.openttcn.com/

http://www.testingtech.com/company/about_us.php


ProveedorNombre de laherramienta

Descripción General Licencia

Elvior4 TestCast

Soporta toda la norma dellenguaje TTCN-3.Permitiendo crearadaptadores al sistema bajoprueba, de�nir bancos depruebas a distintoscomponentesconcurrentemente. No poseeuna integración sencilla conel lenguaje SDL.

Posee una licencia paraprueba durante 15 días, lacual no tiene costo. Una vezterminada el periodo deprueba ésta herramienta tieneun valor desde 290 Euroshasta 8.730 Euros.

En la Tabla 4.2 se muestra un resumen de las características de cada una de las herramientas ylenguajes usados para probar el diseño del caso de estudio del presente Trabajo de Grado descritoen SDL.

Tabla 4.2: Comparación de las herramientas/lenguajes usados para probar el diseño del sistemaHerramien-ta/Lenguaje

Características

Simulador deRTDS

Permite crear pruebas funcionales de caja negra de forma rápidadepurando el diseño del sistema. Sólo se requiere conocer lafuncionalidad de la herramienta. No es posible automatizar losestímulos; aunque se pueden grabar las señales que se han usado en laprueba, los parámetros de estas y la secuencia con la cual fueronenviadas, siempre serán las mismas.

Interfaz grá�caRTDS

Permite enviar los estímulos por medio de un entorno grá�co y derecibir el valor deseado de forma sencilla. Se requiere conocer laherramienta RTDS. No permite automatizar los estímulos ingresados alsistema bajo prueba.

TTCN-3

Permite automatizar el envío de estímulos al sistema bajo prueba, semaneja el concepto de casos de prueba que incluyen un mecanismo devalidación de la respuesta esperada. Ajusta el veredicto global de laprueba dependiendo de los veredictos locales de cada caso de prueba.

Traducción de sistemas descritos en SDL a IF. RTDS proporciona una herramienta quepermite traducir sistemas descritos en SDL a IF. Para lograr traducciones exitosas es necesariotener presente varias consideraciones como, que no se debería de colocar un mismo estado en di-versas particiones; lo anterior evita errores de rede�nición de estados en el momento de ejecutar la

4Para más información de la compañía consulte la página web: http://www.elvior.com/en

http://www.elvior.com/en

4.2. Mejoras al Modelo del Sistema de Parqueo 85

herramienta IFx. La versión 4.4.1 de RTDS, no limita los tipos de accesos a estructuras de datos enel diseño en SDL, pero no es capaz de soportar algunos tipos de accesos en la fase de la traduccióna IF.

4.1.2. IFx

La herramienta IFx permite veri�car formalmente un modelo a partir de sus propiedades ha-ciendo uso de la técnica de Model Checking. Dichas propiedades se derivan de las especi�cacionesdel sistema y se expresan por medio de observadores. Lo interesante de veri�car sistemas a travésde la técnica de Model Checking, es que no se requiere ser un experto en la semántica formal ni enlos métodos formales para poder obtener resultados satisfactorios. A pesar de que la herramientaincorpora un analizador estático del sistema, no fue posible determinar a partir de éste si el sis-tema presentaba una condición de deadlock. Para forzar una respuesta del analizador estático dela herramienta IFx ante la veri�cación de deadlocks en un sistema, se diseñó un pequeño modeloen SDL, que posteriormente fue traducido a IF; dicho modelo contenía una condición de deadlockpuesta intencionalmente. Al ejecutar la herramienta IFx, ésta indicaba que el sistema no presentaproblemas y cumple con la propiedad de�nida. Al hacer un análisis profundo de qué estaba haciendoel analizador, se determinó que la herramienta depura ese tipo de errores mas no informa al usuariode ese proceso interno.

En la literatura se encuentra información acerca del lenguaje IF, pero existe poca documentaciónen cuanto a la utilización de la herramienta IFx. Lastimosamente, no fue posible obtener unarespuesta acerca del uso de dicha herramienta por parte de sus creadores.

4.2. Mejoras al Modelo del Sistema de Parqueo

4.2.1. RTDS

En el Modelado. La de�nición de parámetros de un proceso creado dinámicamente se podríamodi�car a través del uso de parámetros formales describiendo el sistema de manera más �na entérminos del lenguaje SDL. Cabe destacar que el diseño del sistema de parqueo no consideró losproblemas de transmisión de las señales; es decir, supongamos que el administrador quiera crear unazona de parqueo, entonces según las especi�caciones el proceso pMainSystemManager se quedaráen un estado de bloqueo esperando por la señal de con�rmación que indique que el proceso pZone,que representa una zona, ha sido creado exitosamente; si la señal de con�rmación por problemasde transmisión en la red no llega, el sistema permanecerá en bloqueo y será necesario reiniciarel sistema. La situación previa se podría controlar con la inclusión de temporizadores, los cualespermitan colocar los procesos en estados de no bloqueo si no reciben la señal esperada por un ciertoperiodo de tiempo.

Para el diseño de pruebas funcionales a través de una interfaz grá�ca. Para obtenerun comportamiento más real del sistema a probar, es necesario implementar pruebas funcionalessobre distintos componentes que interactúen entre ellos o con otros módulos del sistema de formaconcurrente; con el �n, de obtener una respuesta por parte del sistema que represente mejor el


comportamiento real que pueda tener el sistema. Por ejemplo, en el diseño de las pruebas se asumeque en una zona no puede ingresar y salir un vehículo al mismo tiempo; de hacerlo, la informaciónde plazas libres brindada por la zona no correspondería a la real. Una forma de solucionar dichoproblema es colocando símbolos de save en cada uno de los estados de la máquina de estados delproceso pZone.

Para el diseño de pruebas usando TTCN-3. Respecto a las pruebas funcionales realizadastanto en el simulador de la herramienta RTDS como en el lenguaje TTCN-3, se podría hacer unamejora que consistiría en probar el sistema de parqueo a nivel del sistema, lo que signi�ca evaluardesde el momento de ingreso de un vehículo al sistema de parqueo, su ubicación en una zona,posteriormente su salida de ésta y �nalmente su salida del sistema. Lo anterior se puede realizar sise implementan una serie de acoples a través de procesos intermedios en SDL; además, se podríanmodelar de forma más rigurosa los procesos que no fueron modelados, con el objetivo que éstospuedan re�ejar de manera más cercana el comportamiento real, entregando valores a partir deseñales automatizadas provenientes del entorno. Lo anterior se podría conseguir diseñando casos depruebas que entreguen valores aleatorios a dichos procesos.

4.2.2. IFx

La veri�cación formal del sistema se podría extender haciendo uso de otras opciones del anali-zador estático que posee la herramienta IFx, que consisten en la eliminación de variables y estadosque nunca serán alcanzados, búsqueda de DeadLocks en el sistema, depuración de variables quenunca son utilizadas, entre otras. Lo anterior permite obtener sistemas equivalentes en IF pero po-siblemente su espacio de exploración usando la técnica de Model Checking sería mucho menor queel del sistema original.

Durante el desarrollo de este trabajo de grado se trató de utilizar la herramienta de análisisestático que posee IFx, pero no fue posible conseguir la adecuada con�guración. Dado que noexisten guías o tutoriales para el uso de estas herramientas, se procedió a escribirles a los creadoresde dicha herramienta, entre ellos se encuentran el Dr. Marius Bozga y el Dr. Lulian Ober, ambosinvestigadores de VERIMAG pero no se recibió respuesta alguna del uso de dichas herramientas.

4.3. Metodología para la Construcción de Sistemas Distribuidos

Las fases de la construcción de un sistema distribuido involucran la descripción de la especi-�cación del sistema, su diseño en un lenguaje formal o semi-formal (como SDL) que no produzcaerrores por ambigüedades. Posterior al modelado es necesario garantizar la correcta operatividaddel diseño; para ello, se utilizan técnicas formales y no formales. Las técnicas formales correspondena expresar el sistema modelado en un lenguaje con una semántica formal y establecer las propie-dades que debería de satisfacer dicho sistema. Las técnicas no formales consisten en hacer pruebasfuncionales de caja negra o de caja blanca.

La especi�cación del sistema es una parte crucial en el desarrollo del modelo, ya que en esta fasese describe el comportamiento que el diseño debería de seguir; lo anterior, provee un camino sencillo

4.3. Metodología para la Construcción de Sistemas Distribuidos 87

para saber cuáles módulos se desean probar, además de de�nir los módulos críticos que posee elsistema para determinar las propiedades que se deberían satisfacer.

Depuración de errores. La herramienta SDL suple casi todas las fases que posee la cons-trucción de un sistema distribuido. Para la depuración de errores en el diseño del sistema, me-todológicamente es conveniente seguir los siguientes pasos una vez se tenga un diseño previo delsistema.

1. Para la depuración de los errores en los módulos con bajo nivel de abstracción es recomendablehacer uso de las herramientas de simulación y pruebas que tiene la herramienta RTDS.

2. Una vez encontrado algún error en el diseño, proceder a corregirlo y efectuar nuevamenteuna simulación que permite tener la noción que el sistema en ciertas funciones opera como seespera para algunos escenarios.

3. Para probar que la interacción de dos módulos del sistema funciona de manera deseada, seimplementan pruebas funcionales de caja negra sobre el lenguaje TTCN-3.

4. Nuevamente, los errores encontrados se depuran.

5. Una vez obtenida una noción del comportamiento general del sistema, se estipula con la ayudade las especi�caciones del sistema descrito en los diagramas MSC qué módulos contienenpropiedades críticas y sobre estos se veri�ca formalmente usando la herramienta IFx.

6. Si la propiedad especí�ca se satisface en el sistema construido, se procede a veri�car máspropiedades si las hay.

La metodología previa se determinó a través del desarrollo de este trabajo de grado y funcionóde manera apropiada para el modelado, depuración y entrega de un sistema más con�able.

Capítulo 5

Observaciones Finales

5.1. Conclusiones

La utilización de lenguajes formales y semi-formales para la especi�cación y diseño de modelos,permiten especi�car sistemas de manera más precisa que luego podrán ser veri�cados haciendouso de pruebas funcionales de�niendo la característica de la prueba a partir de las especi�cacionesde�nidas del sistema; además, se puede extender su veri�cación haciendo uso de técnicas formalescomo Model Checking para garantizar que el sistema cumpla con sus propiedades previamenteespeci�cadas.

Este trabajo de grado combina dos técnicas en una sola metodología para la minimización deerrores en el diseño de sistemas distribuidos; la utilización de dichas técnicas en el caso de estudioempleado, muestra que tanto las pruebas como las veri�caciones formales son complementarias yayudan a diseñar sistemas más con�ables.

Para utilizar la técnica de Model Checking como método formal de veri�cación sobre la herra-mienta IFx, el sistema se debe limitar a una porción del sistema con entradas delimitadas en unrango; lo que conlleva a concentrarse en veri�car formalmente sólo los módulos que se considerencríticos del sistema. Por otra parte, el uso de pruebas funcionales de caja negra brinda una nociónleve de la correctitud del diseño del sistema; las señales que son usadas para estimular el sistemabajo prueba, el usuario puede limitarlas de forma mas sencillo con datos reales, de�niendo los va-lores deseados de lo que se quiere probar; adicionalmente, permite analizar su comportamiento pormedio de diagramas MSCs.

Por otro lado, es importante destacar que las pruebas funcionales de caja negra y las veri�ca-ciones formales son complementarias; si bien es cierto que hacer uso de técnicas formales como es elcaso de Model Checking proporciona un análisis exhaustivo al diseño, lo que permite garantizar queel sistema cumple con cierta propiedad; pero su aplicabilidad a sistemas que posean un alto nivelde abstracción se ve afectado signi�cativamente por la complejidad del espacio de estados. Además,por medio de la herramienta IFx no es posible veri�car a través de la técnica de Model Checkingsistemas que poseen señales con tipos de datos no limitados; por ejemplo, si se deseara veri�car elsistema de parqueo a nivel sistema y que una de las propiedades fuera que si un usuario que haingresado con un vehículo desea salir con otro diferente, no pueda realizarlo. Se tendría que limitarel universo de placas que entrarían en dicho sistema, además el tipo de acoples que se necesitaríanpara que el lector de carnés y la cámara entreguen un resultado sería bastante tedioso de construir,dado que sus salidas deberían de corresponder a dicho universo de placas y de identi�cadores deusuarios. Lo anterior, seguramente ocasionaría una explosión de estados o el resultado se demoraríamucho tiempo en obtenerse. Por su parte, las pruebas funcionales de caja negra proporcionan una

90 Capítulo 5. Observaciones Finales

leve noción de qué tan bien está construido el sistema a partir de su modelo, si son pocos los estí-mulos enviados al sistema bajo prueba. Retomando el caso de evaluar el diseño a nivel de sistema,por medio de pruebas funcionales de caja negra sobre TTCN-3, se podría obtener una noción deldiseño estimulando el sistema a probar con datos reales; por ejemplo, se podría conseguir la basede datos de los códigos de usuarios con sus respectivas placas de vehículos asociadas, y con dichainformación se podría construir tablas de datos, como se hizo en la sección de pruebas, y representarésta en una estructura de datos que el lenguaje TTCN-3 soporte. Posteriormente se diseñarían losbancos de pruebas estipulando las condiciones deseadas que se espera que el sistema tenga.

A pesar que la herramienta RTDS presenta algunas falencias en la construcción de pruebasfuncionales sobre el lenguaje TTCN-3 y la traducción del lenguaje SDL a IF, no deja de ser unaalternativa atractiva para la construcción de sistemas distribuidos abarcando parcialmente todo elciclo de vida de la construcción de sistemas distribuidos.

5.2. Trabajos Futuros

A continuación se describen los posibles trabajos futuros que se derivan del desarrollo de estetrabajo de grado.

Modelado.

Considerar las condiciones de con�ictos en regiones críticas del sistema de parqueo; por ejem-plo, el diseño del sistema no soporta que en una zona ingrese y salga un vehículo al mismotiempo; de hacerlo, la información de plazas libres brindada por la zona no correspondería ala real.

Pruebas.

Realizar pruebas a distintos módulos del sistema de parqueo de manera concurrente, por mediodel lenguaje TTCN-3.

Veri�cación Formal

Hacer un mayor análisis al diseño del sistema usando la herramienta de análisis estático queposee la herramienta IFx; determinando si éste presenta condiciones de DeadLocks, Dead-Variables, alcanzabilidad, etc. Además de determinar más componentes críticos los cuales suveri�cación sea tratable.

Explorar el lenguaje IF en su semántica formal con el objetivo de tratar de veri�car el sistemacompleto con propiedades mas so�sticadas (Liveness, Safety).

Apéndice A

Tipos de Datos y Señales usadas en elmodelado del sistema de parqueo de la

PUJC

92Apéndice A. Tipos de Datos y Señales usadas en el modelado del sistema de parqueo

de la PUJC

93

m43Declarations3of3constants34m

SYNONYM3cNUMMAXCTRL3INTEGER3=31;SYNONYM3cMAX_ZONES3INTEGER3=31;SYNONYM3cNUMMAXZONES_SYSTEM3INTEGER3=3cNUMMAXCTRL4cMAX_ZONES;SYNONYM3cNUMMAXSPOTS3INTEGER3=3yxx;SYNONYM3cNUMMAXENTRYWAY3INTEGER3=3d;SYNONYM3cNUMMAXOUTWAY3INTEGER3=3d;SYNONYM3cNUMMAXENTRYNOUTWAY3INTEGER3=3cNUMMAXENTRYWAYFcNUMMAXOUTWAY;SYNONYM3cNUMMAXUSERS3INTEGER3=3bx;SYNONYM3cNUMMAXFREESPOTS3INTEGER3=3 cNUMMAXSPOTS4cNUMMAXZONES_SYSTEM;

SYNTYPE3i_spots3=3INTEGERDEFAULT3x;

CONSTANTS3xuucNUMMAXSPOTSENDSYNTYPE;

SYNTYPE3numMaxSpots3=3INTEGERCONSTANTS3xBcNUMMAXFREESPOTS

ENDSYNTYPE;

SYNTYPE3itIndex3=3INTEGERCONSTANTS3xBcMAX_ZONES−:

ENDSYNTYPE;

NEWTYPE3InfoZoneSTRUCT

totalSpots3INTEGER;freeSpots3INTEGER;ID3PID;

ENDNEWTYPE;

SYNTYPE3indexE_W3=3INTEGERCONSTANTS3xBcNUMMAXENTRYWAY

ENDSYNTYPE;

SYNTYPE3indexO_W3=3INTEGERCONSTANTS3xBcNUMMAXOUTWAY

ENDSYNTYPE;

NEWTYPE3table_EntryWaysARRAY2indexE_WpPID+

ENDNEWTYPE;

NEWTYPE3table_OutWaysARRAY2indexO_WpPID+

ENDNEWTYPE;

NEWTYPE3table_ZonesARRAY2itIndexp3InfoZone+

ENDNEWTYPE;

SYNTYPE3itIndext_Ctrl3=3INTEGERCONSTANTS3xBcNUMMAXCTRL−:

ENDSYNTYPE;

NEWTYPE3tableInfoGralCtrlARRAY2itIndext_Ctrlp3InfoCtrl+

ENDNEWTYPE;

NEWTYPE3tableMainInfoCtrlsARRAY2itIndext_CtrlpinfoMainCtrls+

ENDNEWTYPE;

NEWTYPE3tableVeriFyCon_ZoneARRAY2itIndext_CtrlpBOOLEAN+

ENDNEWTYPE;

NEWTYPE3tableVerifyCon_CtrlARRAY2itIndext_CtrlpBOOLEAN+

ENDNEWTYPE;

Figura A.1: Tipos de Datos usados en el modelado del sistema de parqueo de la PUJC


de la PUJCNEWTYPEOinfoMainCtrlsSTRUCT

totalSpotsZoneOINTEGER;freeSpotsZoneOINTEGER;

ENDNEWTYPE;

NEWTYPEOInfoCtrlSTRUCT

alltotalSpotsOINTEGER;allfreeSpotsOINTEGER;IDCtrlOPID;listZonesOtable_Zones;tableConnectionOkZonesOtableVeriFyCon_Zone;

ENDNEWTYPE;

NEWTYPEOInfoMainSystemSTRUCT

totalSpotsSystemOINTEGER;freeSpotsSystemOINTEGER;freeSpotsParkingOINTEGER;tableInfoCtrlOtableMainInfoCtrls;tableEntryWaysOtable_EntryWays;tableOutWaysOtable_OutWays;

ENDNEWTYPE;

SYNTYPEOIndexO=OINTEGERCONSTANTSOv:cNUMMAXUSERS−(

ENDSYNTYPE;

NEWTYPEOvec_PlatesARRAYdIndex0Ocharstringx;

ENDNEWTYPE;

NEWTYPEOvec_IDARRAYdIndex0OINTEGERx;

ENDNEWTYPE;

NEWTYPEODataUserSTRUCT

plateOcharstring;IDOINTEGER;

ENDNEWTYPE;

NEWTYPEOtDATABASESTRUCT

tplatesOvec_Plates;tIDO vec_ID;

ENDNEWTYPE;

Figura A.2: Continuación tipos de Datos usados en el modelado del sistema de parqueo de la PUJC

95

Las siguientes señales están ordenadas por proceso con sus respectivos canales.Proceso pZoneEste proceso tiene comunicación con tres canales en los cuales se transportan las siguientes

señales:Canal cEnv_Zone:

Señales provenientes del entorno al proceso pZone.

• sIR1_Zone: Representa la interrupción de un sensor infrarrojo para el ingreso de unvehiculo.

• sIR2_Zone: Representa la interrupción de un sensor infrarrojo para el ingreso de unvehículo.

• sIR3_Zone: Representa la interrupción de un sensor infrarrojo para la salida de unvehículo.

• sIR4_Zone: Representa la interrupción de un sensor infrarrojo para salida de un vehícu-lo.

• sLoopInductive_Zone: Representa la interrupción de un bucle inductivo, indicandosi está ingresando o saliendo un vehículo.

Canal cCtrl_Zone.

Señales provenientes del proceso pCtrl al proceso pZone

• sInitFreeSpot(i_spots): Asigna las plazas totales de una zona.

• sInitPidCtrl(PID): Establece a una zona su controlador correspondiente.

• sInitTotalSpots(i_spots): Asigna las plazas libres de una zona.

• sReqInfo: Solicita información a una zona.

Señales provenientes del proceso pZone al proceso pCtrl

• sEntered_Car(i_spots): Reporta que un vehículo ha ingresado en una zona, enviandola información de plazas libres que tiene dicha zona.

• sInfoZone(i_spots ): Reporta la información de la zona a través de un tipo de datoi_spots.

• sOkInit: Reporta que la inicialización de plazas libres o plazas totales fue exitosa.

• sOkInitPid: Reporta que la inicialización del PID de pCtrl en la zona fue éxitoso.

• sOut_Car(i_spots): Reporta que un vehículo ha salido de una zona, enviando lainformación de plazas libres que tiene dicha zona.

Canal cZone_Manager:

Proveniente del proceso pZoneManager al proceso pZone


de la PUJC• sInitFreeSpot(i_spots): Asigna las plazas totales de una zona.

• sInitPidCtrl: Establece a una zona su controlador correspondiente.

• sInitTotalSpots(i_spots): Asigna las plazas libres de una zona.

• sReqInfo: Solicita información a una zona.

Proveniente del proceso pZone al proceso pZoneManager

• sInfoZone(InfoZone): Reporta la información de la zona a tarves de un tipo de datoInfoZone.

• sOkInit(InfoZone): Reporta que la inicialización de plazas libres o plazas totales fueexitosa.

• sOkInitPid: Reporta que la inicialización del PID de pCtrl en la zona fue éxitoso.

Canal cMain_Zone.

Proveniente del proceso pTesting al proceso pZone

Las siguientes señales no son parte de la implementación del sistema, han sido estableceidascon el objetivo de facilitar las pruebas de entrada y salida de vehículos a cada uno de laszonas.

• sIR1_ZoneTest: Representa la interrupción de un sensor infrarrojo para el ingreso ysalida de un vehiculo.

• sIR2_ZoneTest: Representa la interrupción de un sensor infrarrojo para el ingreso ysalida de un vehículo.



• sLoopInductive_ZoneTest: Representa la interrupción de un bucle inductivo, indi-cando si está ingresando o saliendo un vehículo.

Proceso pZoneManager.canal cCtrl_ZoneManager.

Proveniente del proceso pCtrl al proceso pZoneManager

• sCon�rmZoneManager_i: Establece una union entre el proceso pCtrl y el procesopZoneManager, se comparte cuando el sistema empieza por primera vez.

• sCreateZone(i_spots,i_spots): Crea una zona nueva de�niendo sus plazas totales ylibres.

Proveniente del proceso pZoneManager al proceso pCtrl

97

• sExcQuantityZones: Noti�ca al proceso pCtrl que tiene el máximo de zonas permitidos.

• sIamZoneManager: Noti�ca que el PID de su controlador de zona, pCtrl, se asignóexitosamente.

• sOkCreation(PID): Con�rma que se creó y se conectó exitosamente una zona al pro-ceso pCtrl.

Canal cCreator_ZoneManager

Proveniente del proceso pCreatorZoneManager al proceso pZoneManager

• sCon�rmZoneManager(PID): Asocia el PID del controlador de zonas correspondien-te, al nuevo proceso pZoneManager.

Proceso pCreatorZoneManager.Canal cCtrl_CreatorZoneManager.

Proveniente del proceso pCtrl al proceso pCreatorZoneManager

• sCreateZoneManager: Solicita crear un proceso pZoneManager y asociarle a éste sucontrolador de zonas respectivo.

Proveniente del proceso pCreatorZoneManager al proceso pCtrl

• sExcZoneManager: Noti�ca al proceso pCtrl que ya tiene el máximo número de pZo-neManager.

• sOkCreateZoneManager(PID): Noti�ca que se ha creado y asociado exitosamenteun proceso pZoneManager al proceso pCtrl.

Proceso pCtrlManager.Canal cMain_CtrlManager.

Proveniente del proceso pMainSystemManager al proceso pCtrlManager

• sCreateCtrl: Solicita la creación de un controlador de zonas, pCtrl.

Proveniente del proceso pCtrlManager al proceso pMainSystemManager

• sExcQuantityCtrl: Noti�ca al proceso pMainSystemManager que no es posible crearmas procesos pCtrl debido que tiene el máximo número de éstos.

• sOkCreationCtrl(InfoCtrl): Noti�ca al proceso pMainSystemManager que un procesopCtrl ha sido creado exitosamente.

Canal cCtrl_CtrlManager.

Proveniente del proceso pCtrlManager al proceso pCtrl


de la PUJC• sCon�rmCtrl: Veri�ca que se haya creado un proceso pCtrl, enviando esta señal a esteúltimo como noti�cación.

Proveniente del proceso pCtrl al proceso pCtrlManager

• sIamCtrl(InfoCtrl): El proceso pCtrl con�rma su existencia enviando esta señal quetiene como parámetro su información de tipo de dato InfoCtrl.

Proceso pCtrl.Canal cMain_CtrlZone

Proveniente del proceso pMainSystemManager al proceso pCtrl

• sCreateZone_(i_spots,i_spots): Solicita crear una zona en el proceso pCtrl.

• sInitFreeSpotZone(zone,i_spots): Solicita asignar un nuevo valor de plazas librespara una zona contenida en un proceso pCtrl.

• sInitialConnection: Solicita al proceso pCtrl enlazar sus respectivos procesos: pZone,pZoneManager.

• sInitTotalSpotZone(zone,i_spots): Solicita asignar un nuevo valor de plazas totalespara una zona.

• sReqInfoCtrl: Solicita la información del proceso pCtrl que consiste a su vez la infor-mación de cada una de las zonas asociadas a dicho proceso.

Proveniente del proceso pCtrl al proceso pMainSystemManager

• sExcLimitZones: Noti�ca al proceso pMainSystemManager que no es posible anexarotra zona al proceso pCtrl, dado que execede su capacidad máxima.

• sInfoTotalCtrl(InfoCtrl): Envia la información de todas las zonas de parqueo al pro-ceso pMainSystemManager.

• sOkCreateZone(InfoCtrl): Noti�ca al proceso pMainSystemManager que se ha creadoexitosamente una zona de parqueo enviando como parámetro la información total delcontrolador de zonas, pCtrl.

• sOkCreationCtrl_i(InfoCtrl): Noti�ca al proceso pMainSystemManager que el pro-ceso pCtrl ya tiene asociado sus respectivos procesos pZoneManager y pZone.

• sOkSetUp: Noti�ca al proceso pMainSystemManager que la inicialización del valor deplazas totales y libres ha sido exitosa.

Proceso pMainSystemManager.Canal cEnv_Main.

Proveniente del ambiente al proceso pMainSystemManager

99

• sAddZone(numCtrl,totalSpots,freeSpots): Solicita al sistema agregar una zona deparqueo a un controlador de zona especí�co.

• sCreateCtrlZone: Solicita al sistema crear un controlador de zonas que se representaa través del proceso pCtrl.

• sCreateEntryWay: El usuario solicita crear una entrada principal al sistema de par-queo.

• sCreateOutWay: El usuario solicita crear una salida principal al sistema de parqueo.

• sReqInfoSystem: Solicita al sistema la información de sus controladores de zona.

• sSetUpFreeSpot(numCtrl,totalSpots,freeSpots): Asigna un nuevo valor de plazaslibres a un controlador y zona especí�cos.

• sSetUpTotalSpot(numCtrl,totalSpots,totalSpots): Asigna un nuevo valor de pla-zas totales a un controlador y zona especí�cos.

Proveniente del proceso pMainSystemManager al ambiente

• sExcLimitCtrl: Informa el sistema al usuario que no es posible crear mas procesospCtrl, dado que se excede el número máximo de estos.

• sFreeSpotsSystem: Entrega al usuario la cantidad de plazas libres que hay en el sistemade parqueo.

• sImpossibleGetInfoCtrls: Informa que no fue posible obtener toda la información delos procesos pCtrl del sistema.

• sInfoSystem(InfoMainSystem): Envía la información de todo el sistema.

• sOkCreateCtrl: Informa al usuario que se ha creado exitosamente un controlador dezona.

• sOkCreateE_O: Señal proveniente del proceso pMainSystemManager y noti�ca que hasido creado exitosamente una salida principal, que a su vez tiene asociado sus respectivoprocesos pCamera y pCardReader.

• sOkCreateE_W: Señal proveniente del proceso pMainSystemManager y noti�ca que hasido creado exitosamente una entrada principal, que a su vez tiene asociado sus respectivoprocesos pCamera y pCardReader.

• sOkCreationZone: Informa al usuario que el sistema ha creado un proceso pZone a unpCtrl especí�co.

Canal cpTesting_Main,

Proveniente del proceso pTesting al proceso pMainSystemManager

• sEntryCar(numCtrl,numZone): Especi�ca el proceso pCtrl y pZone en el cual ingresóun vehículo.


de la PUJC• sOutCar(numCtrl,numZone): Especi�ca el proceso pCtrl y pZone en el cual salió unvehículo.

Canal cDisplay_Main.

Proveniente del proceso pDisplay al proceso pMainSystemManager

• sReqInfoCtrlZone(indexCtrl,indexZone): Solicita la información de la plazas libresde una zona en un controlador especí�co.

Proveniente del proceso pMainSYstemManager al proceso pDisplay

• sInfoCtrlZone(i_spots): Entrega la información de plazas libres de una zona de uncontrolador especi�co.

Proceso pTesting.Canal cEnv_pTesting.

Proveniente del ambiente al proceso pTesting

• sCarPassedarrierTest(numEntryWay): Esta señal sirve para indicarle a un procesopEntryWay qué el carro a pasado la talanquera satisfactoriamente.

• sEntryCarCtrl(NroCtrl): Especi�ca el proceso pCtrl va a ingresar un vehículo.

• sEntryCarZone(NroZone): Especí�ca el proceso pZone en el cual va a ingresar unvehículo.

• sLoopInductive_EntranceTest(numEntryWay): Esta señal sirve para especi�carel proceso pEntryWay el cual está por ingresar un vehículo al sistema. Esta señal esparte del acople para realizar pruebas a cada proceso pEntryWay.

• sLoopInductive_ExitTest(numEntryWay): Esta señal sirve para especi�car el pro-ceso pEntryWay el cual está por salir un vehículo al sistema. Esta señal es parte delacople para realizar pruebas a cada proceso pEntryWay.

• sOutCarCtrl(NroCtrl): Especi�ca el proceso pCtrl va a salir un vehículo.

• sOutCarZone(NroZone): Especi�ca el proceso pZone en el cual va a salir un vehículo.

Proceso pEntryWay.Canal cEnv_EntryWay.

Proveniente del ambiente al proceso pEntryWay

• sCarPassedBarrier: Señal que indica que un carro pasó totalmente por la portería, yque es seguro bajar la talanquera.

• sLoopInductive_Entrance: Señal de un sensor inductivo que indica que un vehículoestá por entrar al sistema de parqueo.

101

• sLoopInductive_Exit: Señal de un sensor inductivo que indica que un vehículo estápor salir del sistema de parqueao.

Proveniente del proceso pEntryWay al ambiente

• sDownBarrier: Señal para bajar la talanquera de la portería para evitar el paso devehículos al sistema de parqueo.

• sUpBarrier: Señal para subir la talanquera de la portería y dar paso del vehículo alsistema de parqueo.

Canal cEntryWay_Main.

Proveniente del proceso pMainSystemManager al proceso pEntryWay

• sCarPassedBarrier_S: Señal que simula cuando un vehículo ha pasado la talanqueratanto en el ingreso como salida del sistema.

• sLoopInductive_Entrance_S: Señal que simula la presencia de un vehículo en unaentrada principal del sistema.

• sLoopInductive_Exit_S: Señal que simula la presencia de un vehículo en una salidaprincipal del sistema.

• sOkInitEntryWay: Señal enviada solo una vez al proceso pEntryWay, con el objetivode asignarle un lector de carné y cámara a la primera portería del sistema.

Proveniente del proceso pEntryWay al proceso pMainSystemManager

• sEnteredCarSystem: Indica al sistema que ha ingresado un vehículo al sistema deparqueaderos.

• sOkEntryWay1: Se da por una sola vez en la fase de inicialización, sirve para decir queel primer proceso pEntryWay ya le fue asignado sus procesos pCamera y pCardReader.

• sOutCarSystem: Indica al sistema que ha salido un vehículo al sistema de parqueaderos.

Canal cCreatorCRNC.

Proveniente del proceso pCreatorCardReaderNCamera al proceso pEntryWay

• sAssigned(pidCR,pidC): Noti�ca al proceso pEntryWay que procesos pCardReader ypCamera le corresponden.

Proveniente del proceso pEntryWay al proceso pCreatorCardReaderNCamera

• sAssignCardReaderNCam: Solicita que se le sea asignado un proceso pCardReadery un proceso pCamera al proceso pEntryWay.


de la PUJCCanal cInternalEntryWay.

Proveniente del proceso pEntryWay al proceso pCreatorEntryWay

• sOkCreateEntryWayN_OutWay(PID): Noti�ca al proceso pCreatorEntryWay quese ha creado correctamente el proceso pEntryWay.

Proveniente del proceso pCreatorEntryWay al proceso pEntryWay

• sOkInitEntryWay: Solicita al proceso pEntryWay que se asocie con sus respectivosprocesos pCardReader y pCamera.

Proceso pCreatorEntryWayCanal cCreatorEntryWay_Main.

Proveniente del proceso pCreatorEntryWay al proceso pMainSystemManager

• sExcEntryWay: Noti�ca al proceso pMainSystemManager que no es posible crear másentradas principales ya que excede su capacidad.

• sExcOutWay: Noti�ca al proceso pMainSystemManager que no es posible crear mássalidas principales ya que excede su capacidad.

• sOkCreateEntryWay(PID): Noti�ca al proceso pMainSystemManager que se ha crea-do exitosamente una entrada principal.

• sOkCreateOutWay(PID): Noti�ca al proceso pMainSystemManager que se ha creadoexitosamente una salida principal.

Proceso pDataBaseCanal cEntryWay_DB.

Proveniente del proceso pEntryWay al proceso pDataBase

• sCon�rmEntranceUser(DataUser): Solicita que se veri�que si el usuario que deseaingresar al sistema de parqueo está registrado en el sistema.

• sCon�rmOutUser(DataUser): Solicita que se veri�que si el usuario que desea salirdel sistema de parqueo está registrado en el sistema.

Proveniente del proceso pDataBase al proceso pEntryWay

• sNoRegis_User: Notifca al proceso pEntryWay que el usuario no está autorizado paraentrar ni salir del sistema de parqueo.

• sOkUser: Noti�ca al proceso pEntryWay que el usuario está autorizado para entrar ysalir del sistema de parqueo.

103

Proceso pCameraCanal cCreator_Camera.

Proveniente del proceso pCamera al proceso pCreatorCardReaderNCamera

• sIamCamera(pidC): El proceso pCamera noti�ca su existencia enviando su pid comoparámetro de la señal.

Canal cEntryWay_Cam.

Proveniente del proceso pEntryWay al proceso pCamera

• sRequestPlate: Solicita la placa del vehículo que esta por ingresar o salir del sistemade parqueo.

Proveniente del proceso pCamera al proceso pEntryWay

• sPlate(charstring): Retorna la placa del vehículo que esta por entrar o salir del sistemade parqueaderos como una cadena de caracteres.

Canal cEnv_Camera.

Proveniente del ambiente al proceso pCamera

• sPlateFromEnv(charstring): Envía una placa, simulando el proceso de obtención deuna placa a partir de una foto.

Proceso pCardReader.Canal cEntryWay_CR.

Proveniente del proceso pEntryWay al proceso pCardReader

• sEnableCardReader: Habilita el proceso pCardReader para el ID contenido en el carnédel usuario.

Proveniente del proceso pCardReader al proceso pEntryWay

• sDataUser(Integer): Retorna el valor del ID del usuario que está por ingresar o salirde la zona de parqueo.

Canal pCreator_CardReader

Proveniente del proceso pCardReader al proceso pCreatorCardReaderNCamera

• sIamCardReader(pidC): El proceso pCardReader noti�ca su existencia enviando di-cha señal y su PID como parámetro.


de la PUJCCanal cEnv_CR

Proveniente del entorno al proceso pCardReader

• sIDUserFromEnv(INTEGER): Envía un código de usuario, simulando el proceso deobtención del mismo.

Apéndice B

Diagramas MSCs de la especi�cación delsistema

106 Apéndice B. Diagramas MSCs de la especi�cación del sistema

pCreatorEntryWay

pEntryNOut_Way

pCamera

pCardReader


Env

pMainSystemManager



sOkCreateE_W

sOkInitEntryWay

sCreateEntryWay

sIamCamera(pidC)

sOkCreateEntryNOut_Way(pidEntryWay)


sOkCreateEntryWay(pidEntryWay)

sCreateEntryWay

Idle

Idle

Idle

Idle

Idle

Idle

Idle


Idle

sWaitConfirmCamera

sWaitAssigned

sOkCreation

sWaitOkCreationEntryWay

Idle

Idle

Figura B.1: MSC para la creación de una entrada principal al sistema de parqueo

107


Env

pCamera

pMainSystemManager

pCardReader

pCreatorEntryNOut_Way

pEntryNOut_Way


sOkCreateEntryNOut_Way(pidEntryWay)

sCreateOutWay

sOkCreateO_W

sOkCreateOutWay(pidOutWay)


sOkInitEntryWay

sCreateOutWay

sIamCamera(pidC)


Idle

Idle

Idle

sOkCreation

Idle

Idle


Idle

Idle

Idle

sWaitConfirmCamera

sWaitAssigned

Idle

Idle

sWaitOkCreationEntryWay

Figura B.2: MSC para la Creación de una salida principal al sistema de parqueo


pZoneManager

pCtrlP0)

pZone

pMainSystemManager

Env

sOkCreateZonePinfoCtrl)

sOkCreationZone

sCreateZone_PtotalSpots=20,freeSpots=15)

sAddZonePnumCtrl=0,totalSpots=20,freeSpots=15)

sCreateZonePtotalSpots=20,freeSpots=15,pidCtrl)

sOkCreationPpidZone)

Idle

Idle

Idle

sWaitAck_BZone

MSC_SetUpParametersZone

sWaitConfirmCreateZone

Idle

Idle

Idle

Idle

Idle

Figura B.3: MSC para la creación de una zona de parqueo cuando el controlador de zonas tieneasociado un pZoneManager

109

pZone

Env

pMainSystemManager

pCreatorZoneManager

pCtrlB0)

pZoneManager

sOkCreateZoneManagerBpidZoneManager)

sAddZoneBnumCtrl=0,totalSpots=20,freeSpots=15)

sOkCreationBpidZone)

sOkCreationZone

sCreateZoneManagerBpidCtrl)

sConfirmZoneManagerBpidCtrl)

sCreateZoneBtotalSpots=20,freeSpots=15,pidCtrl)

sIamZoneManagerBpidZoneManager)

sCreateZone_BtotalSpots,freeSpots)

sOkCreateZoneBinfoCtrl)

Idle

Idle

Idle

Idle

sWaitCreationZoneManager

Idle

Idle

Idle


MSC_SetUpParametersZone

Idle

sWaitAck_BZone

sWaitConfirmCreateZone

Idle

Figura B.4: MSC para la creación de una zona de parqueo cuando el controlador de zonas no tieneasociado un pZoneManager


pZoneManager pZone

sCreateZone(totalS,freeS,pidCtrl)

sInfoZone(totalSpots,freeSpots)

sReqInfo

sOkCreation(pidZone)

sOkInitPid

sOkInit

sInitTotalSpots(totalSpots)

sOkInit

sInitPidCtrl(pidCtrl)

sInitFreeSpot(freeSpots)

Idle

Idle

sWaitInfoZone

sWaitAck_Ok2

sWaitAck_Ok1

Idle

Idle

Idle

Idle


Idle

Figura B.5: MSC ajustes de parámetros a una zona de parqueo recién creada

111

Env pMainSystemManager pCtrlManager

pCtrl

sCreateCtrl

sOkCreateCtrl

sOkCreationCtrl(InfoCtrl)

sIamCtrl(InfoCtrl)

sConfirmCtrl

sCreateCtrl

Idle

Idle

Idle

sWaitAckCtrl

Idle

sWaitAckCtrlManager

Idle

Idle

Figura B.6: MSC para la creación de un controlador de zonas al sistema de parqueo


Env pCardReader

timerProcessOCR’10q

pCamera pMainSystemManagerpDataBase

timerWaitPassCar’1q

pEntryNOut_Way

sConfirmEntranceUser’DataUserq

sUpBarrier

sEnableCardReader

sCarPassedBarrier

sLoopInductive_Entrance

sDownBarrier

sPlate’’plate’q

sEnteredCarSystem

sRequestPlate

sDataUser’Id_userq

sOkUser

Idle

Idle

sWaitOCRPlate

Idle

IdleIdle

sWait4Sensor

sWaitCarPass

Idle

sWaitDataCardNPlate

Idle

sWait4Confirmation

sWaitPlate

Idle

Idle

Idle

Figura B.7: MSC para el ingreso de un vehículo al sistema de parqueo

113

Env

timerProcessOCRU10f

pCamerapCardReader pMainSystemManagerpDataBase

timerWaitPassCarU1f

pEntryWay

sPlateU’plate’f

sLoopInductive_Exit

sOutCarSystem

sRequestPlate

sDownBarrier

sCarPassedBarrier

sOkUser

sUpBarrier

sConfirmOutUserUDataUserf

sEnableReaderCard

sDataUserUId_userf

Idle IdleIdle

Idle

IdleIdle

sWait4Sensor

Idle

sWaitDataCardNPlate

sWait4Request

Idle

sWaitCarPass

Idle

sWaitOCRPlate

Idle

sWait4Confirmation

sWaitPlate

Figura B.8: MSC para la salida de un vehículo del sistema de parqueo

timerProcessOCRq104pCamerapMainSystemManagerpDataBasepEntryNOut_WaypCardReaderEnvsDataUserqId_user4sPlateq’plate’4sLoopInductive_EntrancesNoRegis_UsersConfirmEntranceUserqDataUser4sEnableCardReadersRequestPlatesWait4ConfirmationsWaitPlateIdleIdlesWaitDataCardNPlateIdlesWaitOCRPlateIdleIdleIdle

Figura B.9: MSC usuario no autorizado intentando ingresar al sistema de parqueo de la PUJC


Env

timerProcessOCRq10’

pCamera

pDataBase

pMainSystemManager

pEntryWay

pCardReader

sConfirmOutUserqDataUser’

sEnableReaderCard

sNoRegis_User

sLoopInductive_Exit

sRequestPlate

sDataUserqId_user’

sPlateq’plate’’

sWaitDataCardNPlate

Idle

Idle

Idle

Idle

sWait4Request

Idle

sWaitPlate

Idle

sWait4Confirmation

sWaitOCRPlate

Figura B.10: MSC usuario no autorizado intentando salir del sistema de parqueo de la PUJC

115

cEnvpCtrl

tEnter

tEnter

tEnter

tEnter

pZone(0)

sIR1_Zone

sIR2_Zone

sEntered_Car(freeSpots)

sLoopInductive_Zone

WaitSensorIR2

ScenarioFEntryFCar

Idle

sEvaluationFreeSpots

Idle

Idle


Idle

Figura B.11: MSC usuario ingresando a una zona del sistema de parqueo


pCtrlcEnv

tOut

tOut

tOut

tOut

pZone(0)

sIR3_Zone

sIR4_Zone

sLoopInductive_Zone

sOut_Car(freeSpots)

Idle

ScenarioTOutTCar

Idle

sEvaluatingTotalSpots

WaitSensorIR4


Idle Idle

Figura B.12: MSC usuario saliendo de una zona del sistema de parqueo

117

timer

Wai

tSig

nalIR

timer

Wai

tSig

nalIR

timer

Wai

tSig

nalIR

timer

Wai

tSig

nalIR

pMai

nSys

tem

Man

ager

Zon

e42V

pCtr

l41V

pTes

ting

Zon

e40V

pTes

ting

timer

Wai

tSig

nalIR

timer

Wai

tSig

nalIR

timer

Wai

tSig

nalIR

timer

Wai

tSig

nalIR

pMai

nSys

tem

Man

ager

pCtr

l40V

sIR

1_Z

oneT

est

sIR

3_Z

oneT

est

sIR

2_Z

oneT

est

sEnt

ered

_Car

4fre

eSpo

tsV

sLoo

pInd

uctiv

e_Z

oneT

est

sOut

Car

4Nro

Ctr

l=1,

Nro

Zon

e=2V

sIR

4_Z

oneT

est

sOut

_Car

4fre

eSpo

tsV

sEnt

ryC

ar4N

roC

trl=

0,N

roZ

one=

0V

sLoo

pInd

uctiv

e_Z

oneT

est

sWai

tTim

erIR

1

Idle

Idle

Idle

Idle

sWai

tTim

erIR

4V

erify

IsaC

arE

nter

ing

Wai

tSen

sorI

R2

Ver

ifyIs

aCar

Out

Wai

tSen

sorI

R4

Idle

Idle

Idle

Sce

nario

LOut

LCar

Idle

Sce

nario

LEnt

ryLC

ar

sWai

tTim

erIR

2

Idle

sWai

tTim

erIR

3

Idle

Figura B.13: MSC Ingreso y salida de un vehículo a través del proceso Testing

Apéndice C

Diagramas MSCs en la fase de pruebas

120 Apéndice C. Diagramas MSCs en la fase de pruebas

121

pCreatorZoneManager,1W

RTDS_Env,−1W

pZoneManager,3W

pZone,4W

pZone,2W

sOkInitPid,W

sOkInit,W

sOkInit,W

sInitPidCtrl,|{param1|=0|}W

sInitTotalSpots,|{param1|=200|}W

sInitFreeSpot,|{param1|=200|}W

sCreateZone,|{param1|=200|,param2|=200|}W

sOkCreation,|{param1|=4|}W

0

0

0

0

0

0

0

0

Idle

0

0

0

Idle

0

0

0

0

sWaitAck_Ok1

Idle

0

0

sWaitAck_Ok2

0

Idle

0

0

0

0

Idle

Idle

0

Idle

0

Idle

0


0

0

0

Figura C.1: MSC resultado de la prueba de creación de una zona de parqueo


pZoneP6d

pZoneP5d

pZoneP2d

pZoneManagerP3d

pCreatorZoneManagerPAd

RTDS_EnvP−Ad

pZoneP4d

sCreateZoneP|{paramA|=2WW|cparam2|=2WW|}d


sOkInitPd

sOkCreationP|{paramA|=6|}d

sInitFreeSpotP|{paramA|=2WW|}d

sOkInitPd

sOkInitPd


sOkInitPidPd

sOkInitPd

sInitPidCtrlP|{paramA|=W|}d

sOkInitPd

sExcQuantityZonesPd

sOkInitPidPd




sOkInitPd

sOkInitPidPd

sInitTotalSpotsP|{paramA|=2WW|}d







W

sWaitAck_Ok2

W


W

W

W

W

W

W

W

W

W

Idle

W

W

W

W

Idle

Idle

W

W

W

W

W

W

W

Idle

W

W

W

W

W

Idle

sWaitAck_OkA

Idle

W

W

W

W

W

Idle

W

W

W

sWaitAck_OkA

Idle

W

W

W

W

W

W

W

Idle

W

Idle

W

W

W

W

sWaitAck_Ok2

W

W

Idle


W

W

W

W

W

W

Idle

Idle

W

W

W

W


Idle

sWaitAck_Ok2

Idle

W

sWaitAck_OkA

W

W

Idle

W

W

W

W

Idle

W

W

W

Idle

W

W

W

W

W

W

W

W

W

W

W

W

W

W

Idle

Figura C.2: MSC resultado de la prueba de creación de número máximo de pruebas permitido porun proceso pZoneManager

123

RTDS_Env(−1)

pZone(2)

pCreatorZoneManager(1)

pZoneManager(3)

sInitPidCtrl(|{param1|=1|})

sOkInit()

sOkInitPid()

sInitTotalSpots(|{param1|=200|})

sInitFreeSpot(|{param1|=200|})

sInitPidCtrl(|{param1|=1|})

sOkInit()

sOkInitPid()

Idle

0

0

0

0

Idle

0

0

Idle

0

0

Idle

0

0

0

0

0

0

0

Idle

0

0

Idle

0

0 Idle

0

0

0

0

Figura C.3: MSC resultado de la prueba de inicializar las plazas totales y libres en una zona deparqueo


pZoneManagerW3l

pCreatorZoneManagerW1l

tEnterW3l

tEnter

tEnterW3l

tEnter

tEnterW3l

tEnter

tEnterW3l

tEnter

pZoneW2l

RTDS_EnvW−1l

sIR3_Zone

sIR2_Zone

sEntered_CarW|{param1|=299|}l

sIR1_Zone

sIR4_Zone

sLoopInductive_Zone

sEntered_CarW|{param1|=298|}l

sLoopInductive_Zone

0

0

0

WaitSensorIR2

0

0

0

0

0

0

0

0

0

0

Idle

Idle

0


WaitSensorIR2

0

0

0

Idle

Idle

0

0

0

0

0

0

0

0

0

0

0

0

0


0

Idle

0

0

Figura C.4: MSC resultado de la prueba del ingreso de un vehículo en una zona de parqueo

125

tEnterl3V

tEnter

tEnterl3V

tEnter

tEnterl3V

tEnter

tEnterl3V

tEnter

tOutl3V

tOut

tOutl3V

tOut

pZonel2V

pZoneManagerl3V

pCreatorZoneManagerl1V

RTDS_Envl−1V

sIR1_Zone

sIR2_Zone

sOut_Carl|{param1|=299|}V

sEntered_Carl|{param1|=298|}V

sIR2_Zone

sLoopInductive_Zone

sLoopInductive_Zone

sIR1_Zone

sLoopInductive_Zone

sIR2_Zone

sEntered_Carl|{param1|=299|}V

sIR1_Zone

0

0

0

0

0

Idle

0

VerifyIsaCarOut

0

0

0

0


0

WaitSensorIR20

0

Idle

0

0

Idle0

WaitSensorIR2

0

0

0

0

0

Idle

0

0

0

0

0

Idle

0


0

0

0

0

0

0

Idle

0

0

0

0

0

WaitSensorIR4

0

0

0

0

0

0

0

0

0

0

Figura C.5: MSC resultado de la prueba de la salida de un vehículo de la zona de parqueo


pCreatorZoneManager(1)

pZone(2)

RTDS_Env(−1)

pZoneManager(4)

pZoneManager(3)

sConfirmZoneManager(|{param1|=0|})

sCreateZoneManager

sIamZoneManager()

sOkCreateZoneManager(|{param1|=4|})

Idle

Idle

0

0

Idle

0

0

0


0

0

0

0

0

0

0

Idle

0

Idle

0

0

Idle

0

Figura C.6: Resultado de la prueba de crear una instancia de un proceso pZoneManager

Bibliografía

[AO08] Paul Ammann and Je� O�utt. Introduction to Software Testing. Cambridge UniversityPress, 1 edition, 2008.

[AR11] Lehtmets Andrus and Anna Rannaste. TTCN-3 Basic Introduction. pages 1�17, 2011.

[Ari12] Jaime Arias. Model Checking for tcc Calculus. Technical report, Programa de IngenieríaElectrónica, Ponti�cia Universidad Javeriana Cali, Cali, 2012.

[BBC+02] J.P. Bowen, K. Bogdanov, J.A. Clark, M. Harman, R.M. Hierons, and P. Krause. FOR-TEST: formal methods and testing. In Proceedings 26th Annual International Computer

Software and Applications, pages 91�101. IEEE Comput. Soc, 2002.

[BGI+04] Marius Bozga, Susanne Graf, Ober Ileana, Ober Iulian, and Sifakis Joseph. Formal Met-

hods for the Design of Real-Time Systems, volume 3185 of Lecture Notes in Computer

Science. Springer Berlin Heidelberg, Berlin, Heidelberg, 2004.

[BGO+04] Marius Bozga, Susanne Graf, Ileana Ober, Iulian Ober, and Joseph Sifakis. Tools andApplications II: The IF Toolset. In Bernardo, Marco; Corradini, Flavio, editor, Inter-national School on Formal Methods for the Design of Computer, Communication, and

Software Systems, volume 3185 of Lecture Notes in Computer SCience, pages 237�267,Bertinoro, Italy, September 2004. Springer.

[BK08] Christel Baier and Joost-Pieter Katoen. Principles of Model Checking. The MIT Press,2008.

[Bow00] Jonathan P. Bowen. The Ethics of Safety-Critical Systems. Communications of the

ACM, 43:91�-97, 2000.

[BP06] Adolfo Bravo and Jaime Parra. Veri�cación formal de Sistemas. Technical report,Programa Computación,Universidad Autonoma Metropolitana Unidad de Iztapalapa,Mexico, 2006.

[CDK05] Coulouris, Jean Dollimore, and Tim Kindberg. Distributed Systems: Concepts and De-

sign. Addison Wesley; 4 edition, 2005.

[CW96] Edmund M. Clarke and Jeannette M. Wing. Formal methods: state of the art and futuredirections. ACM Computing Surveys, 28(4):626�643, December 1996.

[Ebn04] Michael Ebner. TTCN-3 Test Case Generation from Message Sequence Charts. In In

Workshop on Integrated-reliability with Telecommunications and UML Languages (ISS-

RE04:WITUL), 2004.

128 Bibliografía

[ETS] ETSI's TTCN-3.org Editorial Team. Introduction TTCN-3. Disponible en: http://www.ttcn-3.org/index.php/about/introduction. Accesado el día 08/05/14.

[Fix08] Limor Fix. 25 Years of Model Checking, volume 5000 of Lecture Notes in Computer

Science. Springer Berlin Heidelberg, Berlin, Heidelberg, January 2008.

[GHR+03] Jens Grabowski, Dieter Hogrefe, György Réthy, Ina Schieferdecker, Anthony Wiles, andColin Willcock. An introduction to the testing and test control notation (TTCN-3).Computer Networks, 42(3):375�403, June 2003.

[GJ01] Susanne Graf and Guoping Jia. Veri�cation Experiments on the {Mascara} Protocol.In Model Checking Software, 8th International SPIN Workshop, Toronto, Canada, May

19-20, 2001, Proceedings, volume 2057 of LNCS. Springer Verlag, May 2001.

[Ham09] Edgardo Hames. Falluto : Un model checker para la veri�cación de sistemas tolerantesa fallas. Technical report, Facultad de matemática, Astronomía y Física,UniversidadNacional de Córdoba, Cordoba, Argentina, 2009.

[HKL+09] Robert M. Hierons, Paul Krause, Gerald Lüttgen, Anthony J. H. Simons, Sergiy Vilko-mir, Martin R. Woodward, Hussein Zedan, Kirill Bogdanov, Jonathan P. Bowen, RanceCleaveland, John Derrick, Jeremy Dick, Marian Gheorghe, Mark Harman, and Kal-pesh Kapoor. Using formal speci�cations to support testing. ACM Computing Surveys,41(2):1�76, February 2009.

[Hoa96] C.A.R Hoare. How Did Software Get So Reliable Without Proof?, volume 1051 of LectureNotes in Computer Science. Springer Berlin Heidelberg, Berlin, Heidelberg, 1996.

[Hom13] Bernard Homès. Fundamentals of Software Testing. John Wiley & Sons, Inc, 2013.

[IEE94] IEEE Guide for Software Veri�cation and Validation Plans. pages i�87, 1994.

[ISO13] Software and systems engineering Software testing Part 1:Concepts and de�nitions.pages 1�64, September 2013.

[IT02] ITU-T. ITU-T Rec. Z.100 � Formal description techniques (FDT) � Speci�cation and

Description Language (SDL), 2002.

[Kro99] Thomas Kropf. Introduction to Formal Hardware Veri�cation. Springer-Verlag NewYork, Inc., 1st edition, 1999.

[Mar03] C lin Jebelean Marius Minea. Experience with Formal Veri�cation of SDL Protocols.In Proceedings of the NATO Advanced Research Workshop on Concurrent Information

Processing and Computing, pages pp. 185�-192, Romania, 2003. Al. I. Cuza UniversityPress.

[MMT09] Iván Georgiev Mikovski, José Antonio González Martínez, and Nicolás Mon Trotti.FlexiMC Framework: framework �exible para model checking. 2009.

http://www.ttcn-3.org/index.php/about/introduction

http://www.ttcn-3.org/index.php/about/introduction

Bibliografía 129

[PT06] Sergio Pérez and Arturo Terceros. Validación de Modelos Uando IF Toolbox. Techni-cal report, Programa de Ingeniería Electrónica, Universidad Autónoma MetropolitanaUnidad Iztapalpa, Mexico, 2006.

[Ren99] Adriaan Michael Reniers. Message Sequence Charts Syntax and Semantics. PhD thesis,UnivesiteitsDrukkerij, Eindhoven, 1999.

[Sch04] Klaus Schneider. Veri�cation of Reactive Systems: Formal Methods and Algorithms.Springer, 2004.

[Sch10] Ina Schieferdecker. Test Automation with TTCN-3: State of the Art and a FuturePerspective. In ICTSS 2010, Test Automation with TTCN-3, Natal, Brazil, 2010.

[VVBK05] Bo�stjan Vlaovi�c, Aleksander Vre�ze, Zmago Brezoçnik, and Tatjana Kapus. Veri�cationof an SDL Speci�cation � a Case Study. Electrotechnical Review, 72:14�21, 2005.

[WDT+11] Colin Willcock, Thomas Deiÿ, Stephan Tobies, Stefan Keil, Federico Engler, and Step-han Schulz. An Introduction to TTCN-3. John Wiley & Sons, second edi edition, 2011.

[WLBF09] Jim Woodcock, Peter Gorm Larsen, Juan Bicarregui, and John Fitzgerald. Formalmethods: Practice and experience. ACM Computing Surveys, 41(4):1�36, October 2009.

Santiago de Cali, Septiembre 11 de 2014 · Santiago de Cali, Septiembre 11 de 2014 Doctor JAIME...

Documents

Transcript of Santiago de Cali, Septiembre 11 de 2014 · Santiago de Cali, Septiembre 11 de 2014 Doctor JAIME...