Universidade Federal de Santa Catarina
Curso de Pós-Graduação em Ciência da Computação
Um Simulador para Validação de Sistemas
Dependentes de Tempo Descritos em RT-LOTOS.
Dissertação submetida à Universidade Federal de Santa Catarina para a
obtenção do grau de
MESTRE EM CIÊNCIA DA COMPUTAÇÃO
Roberto Milton Scheffel
U m Simulador para Validação de Sistemas Dependentes de
Tempo Descritos em RT-LOTOS.
Roberto Milton Scheffel
Esta dissertação foi julgada adequada para a obtenção do título de Mestre em Ciência da Computação, Especialidade Sistemas de Computação, e aprovada em sua forma final pelo Curso de Pós-Graduação em Ciência da Computação da Universidade Federal.de Santa Catarina
Banca Examinadora:
S
U
,
A .
Prof. Murilo Silva de Camargo, Dr. Orientador, INE, UFSC
s
IA
aProf. Murilo Silva de Camargo, Dr. Coordenador do Curso, INE, UFSC
Prof. Murilo Silva de Camargo, Dr. Presidente, INE, UFSC
Prof. Dalpp JoseTsfnnés,®Dr. Instituto de Informática, UFRGS
%
' CUa-^
Prof. Jear/-Marie Farinés, Dr.
Agradecimentos
À todos aqueles que de um a form a ou de outra contribuíram para a elaboração deste trabalho.
A o prof. M urilo Silva de Camargo, pela oportunidade e pela dedicação na elaboração deste trabalho.
Às secretárias do C P G C C , V erinha e Valdete.
À todos os colegas e professores do C urso de Pós-Graduação em Ciência da C om putação da Universidade Federal de Santa Catarina.
Aos meus pais, A ldino e Adelyra, e aos meus irmãos, pelo apoio dado durante a realização deste trabalho. Em especial à m inha irm ã Roseli, p o r tudo que sempre fez p o r m im , e principalm ente pelas palavras de incentivo.
À diretoria (Celso, Iwens e Bráulio), pela amizade dem onstrada neste período, consolidada pela convivência, entre estudos, festas e dificuldades.
À m inha nam orada, Osnilde, p o r ter suportado a distância e pelo am or e com preensão que sempre dem onstrou.
Sumário
C apítulo 1 - In tro d u çã o ...1
C apítulo 2 - Sistemas Dependentes de Tem po - Especificação, Verificação e Validação... 3
2.1 Sistemas Dependentes de T e m p o ... 3
2.2 Técnicas de Descrição Form al de Sistemas Dependentes de T em p o... 5
2.2.1 Redes de Petri T em porizadas...6
2.2.2 Lógicas Tem porais Tem po R eal...6
2.2.3 Álgebras de Processos T em porizadas... 7
2.3 A Técnica de Descrição Form al R T -L O T O S ...8
2.3.1 Sintaxe da Linguagem...9
2.3.2 Semântica Operacional de R T -L O T O S ... 11
2.3.3 Com entários sobre a semântica de R T -L O T O S...11
2.4 Validação e Verificação de Sistemas Dependentes de T em p o ...13
2.5 Conclusões... 15
C apítulo 3 - Simulação de Especificações R T -L O T O S ...17
3.1 Modos de Sim ulação... 17
3.2 Funções do N úcleo de Sim ulação... ... 19
3.2.1 A Função A c tio n s... 21
3.2.2 A Função M e n u ... 23
3.2.3 A Função N e x t... ... 23
3.2.4 A Função M in T im e ... ...26
3.2.5 A Função M axT im e... 27
3.2.6 A Função D o T im e ...27
3.3.1 A rquitetura Básica do S im u lad o r...29
3.3.2 O N úcleo de Simulação...30
3.3.3 O M ódulo de Simulação In te ra tiv a ... 37
3.3.4 O M ódulo de Simulação A utom ática... 37
3.4 C onclusões... 41
C apítulo 4 - A Ferram enta R T L S ... 43
4.1 Simulação Interativa... 44
4.1.1 Ações e passagem do te m p o ...45
4.1.2 Marcação e visualização de estados...47
4.2 Simulação A utom ática...48
4.2.1 Geração de T raços... 49
4.2.2 A rvore de Execução... 51
4.3 C onclusões... 53
C apítulo 5...54
Exemplos de Aplicação da Ferram enta de Sim ulação...54
5.1 O Protocolo T ick-T ock...54
5.1.1 Descrição Inform al do P ro to co lo ...54
5.1.2 Especificação Form al do Protocolo Tick-Tock com C om portam ento F in i to ... 55
5.1.3 Simulação da Especificação... 57
5.1.3.1 Traços de Sim ulação... ... 57
5.1.3.2 Á rvore de Execução...60
5.1.4 Especificação Form al do Protocolo Tick-Tock com C om portam ento In fin ito ...63
5.1.5 Simulação da Especificação... 64
5.1.5.1 Traços de Sim ulação... 64
5.1.5.2 A rvore de Execução...66
5.2 Sistema Telefônico...69
5.2.1 Descrição Inform al dos Com ponentes da C entral Telefônica...71
5.2.3 Validação da Especificação Através da Sim ulação... 73
5.2.3.1 Traços de Sim ulação... 74
5.2.3.2 Á rvore de Execução... ...76
5.3 C ruzam ento R odovia-Ferrovia... 77
5.3.1 Descrição Inform al do P ro b le m a ...77
5.3.2 Especificação Form al do C ruzam ento R odovia-Ferrovia...78
5.3.3 Validação da Especificação Através da Sim ulação... 80
5.3.3.1 Traços de Sim ulação...81
5.3.3.2 Á rvore de Execução...82
5.4 A lgoritm o de Exclusão M ú tu a... 83
5.4.1 Descrição Inform al do A lg o ritm o ...83
5.4.2 Especificação form al do algoritm o em R T _ L O T O S ...84
5.4.3 Validação da Especificação Através da Sim ulação... 85
5.4.3.1 Traços de Sim ulação...86
5.4.3.2 Á rvore de Execução...87
5.5 Conclusões...88
C onclusões... ...89
Referências Bibliográficas... 92
A nexo A - A G ram ática da Linguagem R T -L O T O S ... 96
A nexo B - O Sistema S IN T A X ... 98
B .l In tro d u ção ... 98
B.2 O Processador da Gram ática - B N F ... 98
B.3 O C o n stru to r do Analisador Léxico - L E C L ...100
B.4 O s C onstrutores do Analisador Sintático - C SY N T e P R I O ... 101
B.5 O s C onstrutores do Analisador Semântico - SEM A CT e S E M A T ... 102
B.6 O Tratam ento de Erros - R E C O R ... 103
B.7 A Produção de Tabelas em Linguagem C - TABLES C ...104
Lista de Tabelas
Tabela 2.1 - Semântica Form al de R T -L O T O S ...12
Lista de Figuras
Figura 3.1 - Ferram enta de Simulação de Especificações R T -L O T O S ... 30
Figura 3.2 - A rvore A bstrata do Processo E xem plo...33
Figura 3.3 - Representação interna parcial do processo Exem plo... 34
Figura 3.4 - Representação interna parcial do processo Exem plo... 34
Figura 3.5 - Representação interna parcial do processo Exem plo... 35
Figura 3.6 - Representação interna completa do processo Exem plo...35
Figura 3.7 - Representação interna do Processo Exemplo depois da ação c... 36
Figura 4.1 - Especificação R T-LO TO S exem plo... 45
Figura 5 . 1 - 0 protocolo T ick -T o ck ... ... 55
Figura 5.2 - C entral T elefônica...70
Figura 5.3 - Com unicação C entral Telefônica - T erm in al... 70
Resumo
L O T O S é um a técnica de descrição form al padronizada pela ISO desde 1988, a qual perm ite expressar a ordenação tem poral de eventos, percebidas p o r um observador externo. C o m a combinação de ações elementares com os operadores da linguagem, é possível descrever com portam entos complexos. Sua m aior utilização ocorre na descrição de sistemas distribuídos. Existe atualm ente um grande núm ero de m étodos e técnicas de verificação e validação suportando a técnica de descrição form al LO TO S.
E ntretanto, um a grande limitação de L O T O S reside no fato da mesma não oferecer mecanismos de descrição de restrições tem porais. Assim, L O T O S não pode ser facilmente utilizada na descrição de sistemas onde o tem po intervém . Este fato levou ao desenvolvim ento de várias extensões da linguagem, perm itindo representar explicitam ente restrições de tem po na evolução do sistema.
N este trabalho, apresenta-se um a ferram enta de validação de especificações de sistemas tem po real escritas na linguagem de descrição form al R T-L O TO S. Esta linguagem é um a extensão tem porizada de LO T O S. A ferram enta perm ite a simulação do com portam ento dos m odelos descritos em R T-L O TO S, de m odo a validar requisitos de qualidade dos mesmos. A simulação pode ser interativa ou automática. A simulação autom ática oferece a alternativa de geração de um traço de execução ou a alternativa de explorar todos os traços possíveis, gerando um a árvore de execução. A o final do trabalho são apresentados estudos de caso, de m odo a ilustrar a utilização da ferram enta.
Abstract
L O T O S is a form al description technique standardized by ISO since 1988, w hich allows to express the tem poral ordering of events, as perceived by an external observer. The com bination of the elem entar actions and the language operators can be used to describe com plex behaviours. This form al description technique is m ostly used on th e distributed systems description. A ctually, there are a num ber of m ethods and techniques of verification and validation supporting the L O T O S formal description technique.
H ow ever, th e greatest lim itation of L O T O S is its lack of mechanisms for the description of tem poral restrictions. Thus, L O T O S cannot be easily used fo r the description of systems w here the tim e is crucial. This fact led to the developm ent of various extensions to the language, w hich have mechanisms to explicitly describe tem poral restrictions in the evolution of the system.
In this w o rk we present a tool for the validation of real tim e systems specifications, w ritten in th e form al description language R T-LO TO S. This language is a tem poral extension of LO T O S. The to ol allows the sim ulation of th e behaviour of models described w ith R T-L O T O S, w ith the objective of the quality requisites validation. The sim ulation can be interactive o r automatic. The autom atic sim ulation offers the alternative of generating an execution trace, or the alternative of exploring all possible traces, generating an execution tree. A t th e end of this w ork, some case studies are presented, to illustrate th e use of the tool.
Capítulo 1
Introdução
N o s últim os anos, as Técnicas de Descrição Form al (FD T - Formal Description Techniques) têm sido cada vez mais utilizadas e aceitas. Isto se deve ao fato de que cada vez mais procura-se verificar e validar os sistemas antes da sua implementação. Para sistemas de grande complexidade, é ainda mais im portante garantir o quanto antes sua correção. E pela facilidade de se m odelar paralelismo e com portam entos complexos, as FD T s encontram um vasto cam po de aplicação, destacando-se na especificação de sistemas distribuídos.
As FD T s padronizadas pelos organismos internacionais, tais com o L O T O S e Estelle (padronizadas pela ISO) e SDL (padronizada pelo UTI) encontraram , nos últim os anos, grande aceitação nos meios acadêmicos e industriais. Várias ferram entas de validação e verificação foram desenvolvidas, perm itindo um a análise com pleta das especificações. A té m esm o ferram entas de tradução autom ática de especificações para linguagens de program ação existem, elim inando o processo de codificação m anual de implementações das especificações. Esta tradução autom atizada evita a introdução de erros na programação.
U m a das FD T s de m aior aceitação tem sido L O T O S, devido ao seu grande poder de expressão, e pela sua boa fundam entação teórica, que perm ite a verificação form al de propriedades da especificação. L O T O S tem sua parte com portam ental baseada em CCS e CSP, e a parte de dados baseada na tipo abstrato de dados A C T O N E . Porém , L O T O S apresenta u m a limitação grave: não apresenta operadores ou mecanismos para a descrição de restrições de tem po nas especificações. Isto é, L O T O S fornece os mecanismos apropriados para se expressar a ordenação tem poral em que as ações devem ocorrer, mas não há com o representar o tem po quantitativam ente. Em outras palavras, não há com o expressar quando as ações devem acontecer ou as restrição de tem po que são impostas a um a ação.
Este trabalho apresenta um a extensão de LO T O S, denom inada de R T -L O T O S (Real-Time LO T O S), proposta em [Camargo95]. Esta extensão perm ite expressar restrições tem porais na ocorrência das ações das especificações. Estas restrições perm item expressar o intervalo de tem po no qual as ações pode ocorrer.
Porém , para um a com pleta verificação e validação de um sistema dependente de tem po, são necessárias ferramentas automatizadas. Estas ferram entas devem p erm itir a
verificação de propriedades sobre as especificações, bem com o acom panhar o desenvolvim ento do com portam ento das especificações, de m odo a garantir que o mesm o seja condizente com os requisitos de qualidade do sistema sendo especificado.
N este trabalho apresenta-se um a ferram enta de simulação para especificações de sistemas dependentes de tem po, escritas em R T-L O TO S. Esta ferram enta apresenta um a série de funcionalidades para a simulação interativa e autom ática de especificações R T -L O T O S. Perm ite o acom panham ento do desenvolvimento da especificação sendo simulada. Tam bém é possível gerar um a árvore de execução para um a especificação. Perm ite ainda a geração de diversos traços de execução da especificação, com diversas opções de disparo das ações nos intervalos de tem po a elas associadas. A o final do trabalho são feitos alguns estudos de caso.
Esta dissertação é organizada da seguinte forma:
N o capítulo 2 são apresentadas as características de sistemas dependentes de tem po, e as maneiras de representá-los. Em seguida é apresentada um a descrição da linguagem R T -L O T O S, utilizada para a especificação form al de sistemas dependentes de tem po, bem com o m étodos de validação e verificação das especificações.
N o capítulo 3 é discutida a simulação de sistemas dependentes de tem po descritos em R T -L O T O S, com ênfase nos aspectos utilizados no desenvolvimento da ferram enta apresentada neste trabalho. A inda neste capítulo é apresentada a arquitetura do sim ulador, com um a discussão dos algoritmos utilizados.
N o capítulo 4 as funcionalidades da ferram enta são apresentadas, descrevendo-as e m ostrando com o utilizá-las na validação de requisitos de qualidade dos sistemas especificados em R T-LO TO S.
N a continuidade, no capítulo 5, são apresentados alguns estudos de caso, visando testar e ilustrar a utilização da ferram enta como m étodo de validação.
P o r fim, são apresentadas as conclusões sobre este trabalho, m ostrando perspectivas futuras de desenvolvim ento desta e de outras ferramentas.
Capítulo 2
Sistemas Dependentes de Tempo - Especificação,
Verificação e Validação.
A complexidade dos sistemas computacionais m odernos é m uito grande. Esta complexidade de descrição de sistemas é ainda m aior quando o problem a envolve aspectos de tem po. Assim, a utilização de m étodos formais na especificação e verificação de sistemas dependentes de tem po é um a alternativa das mais promissoras.
N este capítulo serão abordadas as características dos sistemas dependentes de tem po, suas definições básicas e as principais classes de sistemas inform áticos tem po real. Tam bém serão apresentados os m étodos formais de especificações destes sistemas. U m destes m étodos, a álgebra de processos R T -L O T O S é m ostrada em detalhes, com um a discussão de sua sintaxe e semântica. Em seguida serão descritas algumas abordagens de verificação e validação das especificações dependentes de tem po, com ênfase na simulação.
2.1 Sistemas Dependentes de Tempo
Sistemas dependentes de tem po, ou sistemas tem po real, são sistemas nos quais o tem p o tem um a influência fundam ental sobre seu com portam ento [Camargo95]. O u seja, além de terem que oferecer certos serviços, para que sejam considerados corretos estes sistemas devem oferecer os serviços dentro de intervalos de tem po determ inados. Pode-se dizer assim que o tem po é um recurso a ser consumido pelo sistema.
O s sistemas dependentes de tem po incluem três grandes classes: sistemas tem po real, que reagem a estímulos do ambiente, protocolos de comunicação, que tratam da com unicação e sincronização de dispositivos, e aplicações m ultim ídia, que tratam da recuperação, transmissão, sincronização e apresentação de fluxos de diferentes mídias.
O s sistemas tempo real apresentam suas restrições tem porais na interação com seu am biente. D evem reagir a estímulos do ambiente, incluindo a pró p ria passagem do tem po. A presentam características que perm item diferenciá-los e classificá-los, segundo [Audsley90] et alli, tais como:
• C orreção Tem poral (Timeliness): os sistemas reagem a estímulos do am biente, dentro de intervalos de tem po especificados. P o r exemplo, um sistema de piloto
autom ático de aeronave, ao detectar um obstáculo a frente, não deve som ente alterar o curso para evitar a colisão, mas fazê-lo num tem po curto o suficiente.
• Relação de O rdem (Orderliness): a ordem de entrada dos dados deve ser respeitada nos dados de saída do sistema.
• A tualidade (Freshness): o sistema deve utilizar ou fornecer o dado mais atual possível, do pon to de vista tem poral. Assim, p o r exemplo, não basta u tilizar a últim a leitura de um sensor, mas sim garantir o tem po decorrente entre a leitura e a utilização do dado seja o m enor possível. Isto pode im plicar até mesm o no fato do sistema pedir um a nova leitura.
• Previsibilidade (Temporal Predictability): o com portam ento funcional e tem poral deve estar de acordo com sua especificação. O u seja, deve ser possível saber de antem ão qual será o com portam ento do sistema, e o m om ento em que o mesm o vai ocorrer.
• Coordenação (Coordination): as ações do sistema no seu ambiente devem ser coordenadas, de m odo que um a não prejudique a outra.
A lém disso, os sistemas tem po real podem ainda ser classificados em dois grandes grupos:
• Sistemas T em po Real N ão-Críticos (Soft Real-Time Systems)-, são sistemas tem po real que não apresentam falhas críticas. O u seja, caso um a ação não ocorra dentro do seu tem po pré-determinado, a falha resultante não é catastrófica. O custo da falha é da mesma ordem de grandeza que os benefícios da operação norm al.
• Sistemas T em po Real Críticos (Hard Real-Time Systems)-. São sistemas tem po real que apresentam conseqüências catastróficas em caso de falha. Os custos de um a falha podem exceder em várias ordens de magnitude os custos da operação norm al. P o r exemplo, o mal funcionam ento de um sistema de controle de um a usina nuclear pode causar acidentes cujas conseqüências são m uito m aiores que o benefício da operação norm al da usina. O s sistemas tem po real críticos apresentam duas situações assim caracterizadas:
• Seguro em caso de falha (Fail Safe): u m ou vários estados seguros para o com portam ento do sistema podem ser alcançados em caso de falha do sistema.
• O peracional em caso de falha (Fail Operational): quando não existe nenhum estado seguro identificável, mas o sistema computacional pode fornecer u m serviço m ínim o em caso de falha, evitando um a catástrofe.
O s Protocolos de Comunicação são norm as e regras estabelecidas para a padronização da com unicação entre dispositivos. As principais características gerais dos protocolos de com unicação são as seguintes [BBBC93]:
• Concorrência: protocolos de redes de com putadores são sistemas essencialmente paralelos, pois os nós de comunicação operam de m odo autônom o, em paralelo.
• Interação: os protocolos de comunicação expressam um a interação entre os nós da rede. Esta interação pode se dar de diversas formas, tais como: m em ória com partilhada, comunicação síncrona, comunicação assíncrona, comunicação p o r difusão e outras.
• Imprevisibilidade (unpredictability): a interação entre os nós não é previsível, ou seja, mensagens podem ser perdidas, bem como não se pode garantir o tem po de transmissão de um a mensagem entre dois nós distantes.
A lém destas características, outros mecanismos tem porais devem ser considerados na descrição de protocolos de comunicação. E ntre outros, pode-se citar erros p o r atraso (timeout), tem pos máximos e m ínim os de transmissão, duração de conexões, etc.
As aplicações m ultim ídia são aplicações que geram, processam, arm azenam , recuperam e apresentam informações de vários tipos, denom inadas mídia. Estas inform ações podem ser, p o r exemplo, textos e arquivos (mídia estática) ou áudio e vídeo (mídia contínua). U m a discussão mais detalhada dos aspectos tem porais de aplicações m ultim ídia podem ser encontradas em [Camargo95].
O s aspectos tem porais mais im portantes nos sistemas m ultim ídia, entre outros, são:
• O s atrasos de transmissão fim-a-fim de um fluxo de mídia. Variações nestes atrasos são denom inados jitter, sendo que o mesmo pode te r um intervalo de tolerância.
• Sincronização intra-fluxo, na qual se expressa o intervalos de tem pos m ínim o e máxim o entre a chegada de duas unidades de informação (pacotes) de u m mesmo fluxo de mídia.
• Sincronização inter-fluxos, na qual se expressa um a relação entre os tem pos de chegada de pacotes de dois ou mais fluxos de mídia relacionados. P o r exemplo, a sincronização de um fluxo de vídeo com o fluxo de som associado.
2.2 Técnicas de Descrição Formal de Sistemas Dependentes de
Tempo.
A necessidade de se expressar com exatidão as características dos sistemas dependentes de tem po levou ao desenvolvim ento de diversas abordagens de tratam ento. E n tre as principais, pode-se citar:
• Redes de Petri Temporizadas
• Lógicas Tem porais Tem po Real
• Algebras de Processos Temporizadas
2.2.
1 Redes de Petri Temporizadas
A teoria de Redes de Petri [Brams83] foi um dos prim eiros form alism os introduzidos para tra ta r concorrência, não-determ inism o e conexões causais entre eventos. E u m form alism o gráfico e m atemático que se adapta bem a um grande núm ero de aplicações, onde as noções de evento e evoluções simultâneas são im portantes.
As redes de Petri têm sua estrutura representada p o r lugares e transições, sendo que os lugares representam atividades do sistema, e as transições, ligadas a lugares de entrada e saída, representam a ocorrência de eventos. A evolução das redes de Petri é regida pelas fichas (tokens ou jettons) presentes nos lugares, que representam estados do sistema. A ocorrência de eventos no sistema se dá através do disparo das transições, com a retirada de fichas dos lugares de entrada e seu depósito nos lugares de saída.
As extensões tem porais das redes de P etri apresentam variações quanto os elem entos da rede aos quais o tem po é associado. N a literatura encontram os três formas básicas: Redes de P etri com tem po associado aos arcos (Timed A rc Petri Nets) [Walter83], Redes de P etri com tem po associado às transições (Timed Transition Petri Nets) [MeFa76] e, finalm ente, Redes de P etri com tem po associado aos lugares (Timed Place Petri Nets) [CoRo83].
Porém , a abordagem po r Redes de Petri apresenta restrições, tais com o não apresentar u m mecanismo de representação explícita de dados. Tam bém são criticadas p o r sua fraca modularização, não oferecendo um a mecanismo nativo de composição. R equerem ainda u m grande grau de abstração, para interpretar o que um a certa marcação representa no sistema p o r ela modelado.
2.2.2
Lógicas Temporais Tempo Real
Lógicas tem porais são um a classe de lógicas modais, na qual os operadores modais são interpretados de um a m aneira tem poral [AlHe92]. São compostas de operadores lógicos proposicionais que, com binados com um conjunto de operadores tem porais, p erm item que as seguintes propriedades sejam satisfeitas:
• Invariância: propriedades que são sempre verdadeiras em um programa.
• Eventualidade: propriedades que devem tornar-se verdadeiras em algum tem po futuro no sistema.
• Precedências: asserções que estabelecem que u m certo evento deve oco rrer antes de um outro.
Já as lógicas tem porais tem po real estendem as lógicas tem porais, incorporando possibilidades e tratam ento de propriedades quantitativas, tais com o periodicidade, esgotam ento de tem po (<deadlines) e atrasos (delays). Algumas das lógicas tem porais mais conhecidas na literatura são: Temporal Computation Tree Logic (TCTL) [AlHe92]; Real
Tim e Temporal Logic (RTTL) [Ostroff89]; e Metric Temporal Logic (MTL) [Koymans90].
2.2.3 Álgebras de Processos Temporizadas
As álgebras de processos têm sido desenvolvidas dentro do campo da teoria da concorrência. Seu início se deu com os trabalhos de H oare, com seu Com municating Sequential Processes - CSP [Hoare85], e de M ilner, com seu Calculus o f Com municating Systems - CCS [Milner80].
As álgebras de processos conseguem representar, com poucos operadores, to d a a complexidade de sistemas concorrentes ou de sistemas distribuídos. O s principais operadores existentes nas álgebras de processos são os de comunicação síncrona, escolha, não determ inism o, concorrência, restrição e renomeação. A m aioria das álgebras de processos im plem enta estes operadores, porém encontra-se diferenças na utilização e na semântica dos mesmos.
D entre as álgebras de processos existentes, a que mais se sobressai nos últim os tem pos é L O T O S, padronizada pela ISO (International Organization fo r Standardizatiori) desde 1988 [ISO88]. A parte com portam ental de L O T O S é baseada em CCS, com a comunicação síncrona com rendezvous m últiplo de CSP. Já a parte de descrição de dados é baseada na representação de dados algébricos A C T O N E .
Mas as álgebras de processos possuem limitações para a representação de tem po [BBBC93]. N ão é possível representar o tem po preciso em que u m evento deve ocorrer, nem é possível forçar a ocorrência de certos eventos. Para in tro d u zir o tratam ento de tem po nas álgebras de processos, duas são as alternativas: atribuir aos eventos um intervalo de tem p o no qual os mesmos podem ocorrer; ou incluir um operador que represente explicitam ente a passagem de um a ou mais unidades de tem po.
Várias são as extensões tem porais das álgebras de processos existentes. Para fins de referência, pode-se citar algumas extensões de CCS, tais com o [M oTo89] e [Regan90]. Já L O T O S foi alvo de um m aior núm ero de propostas para extensões tem porais, entre as quais cita-se [Azcorra90] [Regan93] [LeLé94] [CoOl95] [Camargo95]. A evolução destas propostas fez com que um novo padrão de L O T O S fosse estudado, agora com suporte a aspectos tem porais da especificação. Estes estudos deverão resultar num novo padrão denom inado E-LO TO S (Enhancem ent to LO TO S) [IS097], o qual já se encontra em estado de D raft Proposal pela ISO.
N a espera do novo padrão de LO T O S, neste trabalho será utilizada a extensão apresentada em [Camargo95], denom inada R T-L O TO S, que é apresentada na seção seguinte.
2.3 A Técnica de Descrição Formal RT-LOTOS
R T -L O T O S é um a extensão da T D F padrão L O T O S, e apresenta mecanismos para a representação de restrições de tem po na ocorrência das ações da especificação1. Assim, além do conjunto de ações, é definido um dom ínio de tem po para a especificação. Tal dom ínio pode ser denso ou esparso, a única restrição é que seja enumerável. Esta restrição é necessária para que o m odelo subjacente seja um sistema de transições rotulado.
Mais form alm ente, o dom ínio de tem po V deve ser um m onóide com utativo2
(p, + , 0) que satisfaz as seguintes condições: 1. d + d ’ - d o d’ - 0
2. a relação < çz V x V definida p o r d < d ’ <=> 3 d ” e V tal que d + d ” = d ’ é um a ordem parcial.
3. a relação < çr V x V definida p o r d < d ’ <=> 3 d ” e V tal que d + d ” = d ’, d ” ^ 0 é um a ordem parcial.
A lém disso, as seguintes propriedades são válidas para o dom ínio de tem po V\
• V r e Z>, 0 < r (0 é o m enor elemento de 2?)
• Vd, d ’ e V, se d < d ’ então o elem ento d ” e V tal que d + d ” = d ’ é único e é denotado p o r d ’ - d.
Denota-se p o r 7T o conjunto V u {oo}, onde co g V é um elem ento distinguido, tal que V d e Z ? , d < c o e o o + d = oo.
U m a discussão mais detalhada sobre o dom ínio de tem po em R T-L O TO S, tal com o a definição de dom ínios densos e esparsos, pode ser encontrada em [Camargo95].
1 Numa especificação, um sistema é visto como um processo, com a possibilidade deste ser constituído de vários sub-processos. Um processo é uma entidade capaz de realizar ações internas e não- observáveis, e de interagir com outros processos, através de ações externamente observáveis. Uma interação entre processos é denominada de evento, sendo que os eventos são atômicos, ou seja, ocorrem de forma instantânea, sem consumir tempo, num ponto de interação denominado porta. Neste trabalho comete-se um abuso de linguagem identificando com o termo ação tanto a porta quanto o evento associado a esta. Isto não traz maiores problemas, visto que os contextos são bem distintos, não havendo risco de confusão.
2 Monóide: conjunto munido de uma operação binária associativa e de um elemento neutro. Além disso, se (A, •, 1) é um monóide e a*b = b«a para qualquer a, b e A, então diz-se que (A, •, 1) é um monóide comutativo. Por exemplo, o conjunto dos números naturais munido da adição é um monóide comutativo.
As ações de R T -L O TO S podem ser agrupadas em dois grandes conjuntos:
• as ações clássicas de L O T O S, que incluem as ações observáveis pertencentes ao conjunto a ação interna i e a ação de térm ino com sucesso ô. A t f denota o
conjunto Act u {i}, e denota o conjunto
^ r f u {8}.
• as ações específicas de R T-L O TO S, que são as violações temporais a*,
pertencentes ao conjunto E suposto que existe um a bijeção entre / i a e /tet*.
O s intervalos de tem po associados às ações são da form a [ t mi n , t max ]. A semântica das ações tem porizadas faz com que um a ação com u m intervalo de tem po associado não seja oferecida antes do lim ite inferior deste intervalo. U m a vez alcançado o lim ite inferior, a ação é oferecida ao am biente para a sincronização. Caso esta não ocorra até o lim ite superior do intervalo, ocorre um a ação semântica de violação temporal. Esta violação tem poral pode ser tratada p o r u m novo operador, denom inado de preempção temporal.
U m a descrição detalhada da sintaxe e da semântica de R T-L O TO S, pode ser encontrada em [Camargo95]. O objetivo desta seção é dar som ente as noções básicas da linguagem para um m elhor entendim ento do restante do trabalho.
N este trabalho será utilizado som ente R T-LO TO S básico, ou seja, R T -L O T O S sem a parte de manipulação de dados. P ortanto, a discussão apresentada a seguir sobre a sintaxe e a semântica de R T -L O TO S om itirá os aspectos relativos aos dados.
2.3.1 Sintaxe da Linguagem
As expressões de com portam ento das especificações R T -L O T O S são gerados p o r um a sintaxe que é um a extensão direta da linguagem L O T O S e é apresentada a seguir:
E : : = s t o p => inação
e x i t => térm ino com sucesso [ t min i t max ] a ; E => prefixação - ação observável [ t min, t max ] i ; E => prefixação - ação interna E [ ] E => escolha
h i d e L i n E => ocultação
E | [ L ] | E => composição paralela E >> E => composição seqüencial E [ > E => preempção
E <L] { ax:Q i, . . . , a n :Qn} => preempção temporal P [ a i , a 2, . . - , a n] => instanciação de processo
A semântica dos operadores de R T-L O TO S pode ser descrita inform alm ente com o
s t o p : o operador de inação representa um processo que não realiza nenhum a ação, com pletam ente inativo, apenas deixa o tem po progredir.
e x i t : o operador de térm ino com sucesso representa um processo que no qual a ação semântica ô representa o fim bem sucedido do mesmo.
[ t min , t max] a ; E : representa o processo que pode evoluir pela ação a , den tro do intervalo de tem po [ t mi n, t max] • A ntes de t mi n a ação a não é oferecida ao am biente para a sincronização. Depois de t mi n e antes de t max o processo pode passar a te r o com portam ento de E pela ocorrência da ação a. N o instante t max, se a ação a não ocorrer, acontece o disparo de um a ação semântica a * , que representa a violação tem poral do intervalo da ação a. Esta ação de violação tem poral faz com que o processo evolua para s t o p . N o caso da ação interna i , não é definida a violação tem poral. Assim, no instante tmax) a ação i torna-se urgente e incontrolável, sendo a sua ocorrência obrigatória. Caso não seja especificado, o intervalo default para ações observáveis é [0,oo] e para a ação interna i é [0, 0].
E [ ] F: representa a escolha entre duas expressões de com portam ento. Esta escolha é decida pela ocorrência da prim eira ação em u m dos lados da escolha. Porém , a ocorrência de um a violação tem poral não decide a escolha para evitar o cham ado indeterm inism o tem poral.
h i d e L i n E : representa a ocultação do conjunto de ações L na expressão de com portam ento E. As ações pertencentes a L tornam -se invisíveis e urgentes. Porém , ao contrário da ação especial i , que deve ocorrer até o lim ite superior do seu intervalo, as ações que tornam -se invisíveis pelo operador de ocultação devem ocorrer no prim eiro instante em que são oferecidas. Esta propriedade é chamada de propriedade de progressão máxima.
E | [ L ] | F: representa o processo que é a composição paralela dos processos E e
F. O s processos podem evoluir independentem ente para as ações que não estão no conjunto de sincronização L. Para as ações pertencentes a L, as mesmas são oferecidas ao am biente no intervalo resultante da interseção dos intervalos locais em cada processo. Se esta interseção fo r vazia, a sincronização não será possível, ocorrendo a violação tem poral em ambos os lados da composição paralela. Se a interseção não for vazia, a ação é oferecida ao am biente. Porém , se não houver a sincronização, haverá tam bém a violação tem poral local nos processos em composição paralela. Esta violação tem poral ocorre isoladamente em cada lado do operador.
E >> F: representa a composição seqüencial dos processo E e F. A composição se com porta com o E até o seu térm ino com sucesso, passando a se com portar com o F.
E [> F : representa o processo que se com porta com o E, porém pode ser interrom pido p o r F, no m om ento da ocorrência de sua prim eira ação, e passa a se
com p o rtar com o F. Porém , a ocorrência de um a violação tem poral em F não in terro m pe E.
Se E term in ar com sucesso, todo o processo term ina.
E < L ] {a i : Q i, . . . , a n : Qn } : representa o processo que se com porta com o E, p o rém fazendo o tratam ento das violações tem porais que p o r acaso ocorram em E. Caso ocorra a violação tem poral de um a ação de L ( a i, . . . , a n), a expressão de com portam ento correspondente assume o lugar de E. Assim, se ocorrer a violação tem poral a i* em E, o processo passa a comportar-se como Qi.
P [ a i , . . - , a n] : representa a instanciação do processo P, com a troca das ações da definição do processo pelas ações que aparecem na instanciação.
2.3.2 Semântica Operacional de RT-LOTOS
A tabela 2.1 apresenta a semântica operacional de R T-L O T O S, no estilo SOS (,Structured Operational Semantics) de P lotkin, e inclui regras de inferência para as ações clássicas, para as violações tem porais e para a passagem do tem po.
2.3.3 Comentários sobre a semântica de RT-LOTOS
C om o dito anteriorm ente, existe um a diferença entre a urgência da ação interna i e
das ações ocultadas pelo operador hide. A ação interna i tem a garantia de ocorrer no seu intervalo, tornando-se urgente e incontrolável no limite superior do seu intervalo. Já as ações ocultadas, mesmo vistas pelo ambiente com o ações internas norm ais, têm a propriedade de progressão m áxim a, ou seja, devem ocorrer no prim eiro m om ento do seu
intervalo.
D esta form a, a expressão de com portam ento
[ 5,10]i ;P
e a expressão de com portam ento
hide [a] in [5,10]a;P
apresentam diferenças semânticas relevantes. Ambas são vistas, externam ente, com o um a
ação in tern a seguida do com portam ento de P. Porém , no aspecto tem poral, têm
com portam entos diferentes. N o prim eiro exemplo a ação i irá ocorrer no intervalo [5,10],
tornando-se urgente e incontrolável no instante 10. Já no segundo exemplo a ação a , pela propriedade da progressão máxima, irá ocorrer no instante 5, sendo vista externam ente com o a ação i. A diferença semântica está na passagem do tem po, e não na visão externa
Inação Término com Sucesso Prefixação stovexit --±stov stop [0 ,t]a\E--- >E exit - stop [0,0]a; E ---» stop -(a * i) \0j + s\a\E >r0, / t a ; £ Escolha E[]F--->E’ FUE--->E' E-Í-^E'
E[]F--- » E'\]F F[]E- ->F[]E'
£[]F---- >E'[\F
Ocultação ->E' (a e L)
hide L in E --- >hide Lin E' E—^— >E' (aeL)
hide L inE —-—>hide L inE' hide LinE- -» hide L in E'
j-, t
hide L in E —-—» hide LinE'
» £ ' (Va e L ^ ( E — —>))
hide LinE- -> hide L in E' Composição
Paralela
-+E' {aí LKj { S} )
E\[L]\F^-> E'\[L]\F F\[L\\E-?-+F\[L\\E' E\[L]\F- ->E'\[L]\F F\[L]\E- ^F\[L]\E'
->E' F ——»F1 ( a e L v { õ } ) F —‘—^F'
E\\E\\F — E'\[L\\F' E\\L\\F——±E'\\L\\F'
Composição Seqüencial E —^ E ' ( a * õ ) E » F — ^—> E ' » F «2+ E — — >E' F. •>•> F a*-->F . ' » F E-E » F — '-^>F F, » F ——> F ' » F Preempção E —^ E ' ( a * S ) E[ >F—^ E ’[>F E—^ E ' ->F' E[>F—^ E ' /i# F—-—>F' E \ > F —^ E \ > F E [> F -= -* F ' (1* E —— >£’ E[> F —^— >E'[> F E— F —^> F ' Preempção Temporal E - ^ E ' (a*S) E —?-+E'
E < L]{ar.Q\,...,ar,:Qn}— L]{ai\Q\,...,an.Qn} E < L]{ái:Qi,...,a„:Q,,}— E' E —^ > E ' ( a e L ) E...( aj e L)
E < L]{av.Qi,...,an\Qn}—-—>E'< L]{a\:Q\,...,ar,:Qn} E < L]{ai:Qi,...,a«:Qn}--->Qi
->E' E < L]{awQ\,...,an.Qn}——>E’< L\{av.Qi,...,an.Qn} Instanciação E [a \! gn\---> £ ' , P [g\,...,g„\.= E P[ai,...,ctn\— *-^>E' E[a\! gl,...,Ctnl gn\ —---->E', P[g\,...,gn\.= E P[ai,...,íJn]— E[at/g\,...,anlgn]— ‘—>E', P[g\,...,gn\:= E _______ P[a\,...,cb\ 1 >E ’_____________
T am bém o uso do operador de preempção tem poral necessita de alguns cuidados, mais especificamente na instanciação recursiva no lado direito do operador. As regras semânticas fazem com que a recursão “acumule” o operador de preem pção tem poral na expressão de com portam ento subseqüente. U m exemplo deste com portam ento é o seguinte processo:
p r o c e s s P[a,b] :=
[0,15]a; [20,30]b; P [ a , b ] < a , b ] {a :Q[a] , b:Q[b]} e n d p r o c
Após a prim eira recursão, o processo acima fica:
p r o c e s s P[a,b] :=
[0,15]a; [20, 30]b ; P[a,b] <a,b]{a:Q[a], b:Q[b]} < a , b ] {a :Q [ a ] , b : Q [ b ] }
e n d p r o c
O correndo agora a violação tem poral da ação a , o prim eiro operador de preem pção tem poral irá tratá-la, mas o segundo operador ficará ainda ativo. Desta forma, se houver a violação tem poral de a no processo Q, a mesma será tratada pelo segundo operador de preem pção tem poral. Este com portam ento se repetirá para quantas recursões houverem antes da prim eira violação tem poral.
Este com portam ento pode ser evitado, no exemplo acima, utilizando-se a seguinte construção: p r o c e s s P[a,b] := P l [ a , b ] < a , b ] { a : Q [ a ] , b :Q [ b ] } w h e r e p r o c e s s Pl[a,b] := [ 0 , 1 5 ] a ; [20, 3 0]b ; Pl[a,b] e n d p r o c e n d p r o c
N este novo processo não há mais o problem a da acumulação do operador de preem pção tem poral, e o com portam ento recursivo do lado esquerdo do operador de preem pção tem poral foi mantido.
2.4 Validação e Verificação de Sistemas Dependentes de Tempo
Q u an to se fala de verificação e validação de especificações formais, algumas divergências são encontradas na literatura, principalm ente quando os dois term os são confrontados.
Para [Ernb91] et alli, validação é um term o genérico que envolve todo o processo de detecção e correção de erros de um a dada especificação ou implementação. N este processo há três atividades principais: verificação, simulação e teste. A verificação visa provar form alm ente que um a especificação satisfaz certas propriedades desejáveis. A simulação é utilizada para gerar e observar um m odelo executável. Já a atividade de teste serve para
avaliar resultados gerados p o r um protótipo observado. O s resultados dos testes são usados na correção das especificações.
Já para [Kirkwood94], verificação é um a prova form al das propriedades da especificação, obtida pela manipulação de axiomas. P o r exemplo, utilizando a definição de relações de equivalência para provar a existência ou não de um a bissimulação entre duas especificações. A validação é um a demonstração convincente, geralmente obtida p o r experim entos, de que um a dada especificação está correta. Tais experim entos podem incluir simulação ou testes, p o r exemplo.
N a continuidade deste trabalho, o term o verificação será utilizado para designar um a prova form al das propriedades de um a especificação através de um m étodo (manipulação de axiomas). Já o term o validação denotará um a análise (possivelmente não exaustiva) do com portam ento de um a especificação p o r experim entos. Esta abordagem segue a linha de [Kirkwood94].
Para a verificação de sistemas dependentes de tem po, um m étodo que pode ser utilizado é o da verificação de modelos (Model Checking) [AlCo90], a p a rtir do qual procura-se verificar se o m odelo do com portam ento do sistema satisfaz um conjunto de propriedades estabelecidas. Para isto, o com portam ento do sistema é representado a p a rtir de u m form alism o de descrição de seus estados, com o grafos tem porizados, sistema de transições rotulado, entre outros. As propriedades são descritas a p artir de fórm ulas de um a lógica tem poral tem po real. Tal verificação pode se dar p o r um a abordagem num érica ou p o r um a abordagem simbólica. A abordagem num érica avalia a fórm ula, utilizando u m m odelo do grafo tem porizado, através da enumeração exaustiva de todos os estados do m odelo. Já a abordagem simbólica avalia a fórm ula diretam ente sobre o grafo tem porizado, sem a necessidade de construção de um modelo.
Para as especificações de sistemas utilizando R T-L O TO S, um a m etodologia de verificação foi desenvolvida e apresentada em [Martins96]. Esta m etodologia utiliza um a técnica baseada na verificação de modelos (model checking). Para verificação de propriedades de um a especificação em R T-L O TO S, são escritas fórmulas de um a Lógica T em poral T em po Real chamada T C T L [AlHe92] para representar essas propriedades. E m seguida é feita um a tradução das especificações R T-L O TO S para um form alism o denom inado Grafo Temporizado que é o m odelo a ser verificado. Este form alism o é um grafo estendido, com relógios e condições lógicas associados aos estados, que perm item um a redução da complexidade do m odelo. A tradução é feita pela ferram enta apresentada em [Martins96]. Em seguida, um a ferram enta auxiliar, denom inada K R O N O S [OlYo93], é utilizada sobre o grafo tem porizado, para verificar a satisfação ou não das fórmulas T C T L que representam as propriedades especificadas para o sistema.
Esta m etodologia restringe as expressões de com portam ento R T -L O T O S sobre as quais se pode realizar verificações. São proibidas duas classes de especificações R T -L O T O S:
• especificações que representem u m com portam ento infinito;
• especificações que contenham expressões não guardadas.
Diz-se que um a especificação representa um com portam ento infinito quando o com portam ento da mesma não pode ser traduzido num grafo tem porizado finito. U m exem plo de tal situação é o processo
P = Q III i; P
Este processo é um a expressão R T-L O TO S válida, porém não tem um a representação em grafo tem porizado finito.
Já as expressões guardadas dizem respeito às expressões de com portam ento nas quais a substituição recursiva das instanciações leva a um a expressão de com portam ento onde todas as instanciações são precedidas de no m ínim o um a ação. U m exemplo de expressão não guardada é o processo
P = P [] a; Q
N este processo, a instanciação recursiva de P nunca levará a um a expressão de com portam ento onde todas as instanciações são precedidas de um a ação.
A lém das técnicas da verificação form al de propriedades de um a especificação, é útil a simulação das especificações, para um acom panham ento da evolução do com portam ento da mesma. Este acom panham ento pode detectar evoluções não desejadas da especificação, nem sem pre detectadas na verificação através de predicados lógicos.
A simulação pode ainda, dependendo da técnica utilizada, p erm itir a validação de especificação que não podem ser verificadas pelas técnicas normais. U m exemplo é o caso de com portam entos infinitos, nos quais o form alism o subjacente à álgebra de processos (grafos tem porizados ou sistema de transições rotulado) não é finito.
Assim, pode-se dizer que a verificação de sistemas através da verificação de modelos, e a validação dos mesmos utilizando-se a simulação, são funções com plem entares. N a continuidade deste trabalho será abordada a simulação de especificações de sistemas dependentes de tem po, descritas em R T-L O TO S, através de um a m etodologia de simulação que utiliza a transform ação das especificações.
2.5 Conclusões
N este capítulo foram discutidas as principais características dos sistemas dependentes de tem po. Foram tam bém apresentadas diversas maneiras de se representá-los, tal como redes de P etri tem porizadas, lógicas tem porais tem po real e álgebras de processos tem porizadas.
U m a álgebra de processos tem porizada, denom inada R T-L O TO S, foi escolhida para especificar sistemas dependentes de tem po, e sua sintaxe e semântica apresentadas, com m aior ênfase sendo dada à semântica.
Foi m ostrada a necessidade da utilização de meios formais de verificação das especificações, e que um a m etodologia para tal já encontra-se disponível, definida em [Martins96]. Tam bém foi m ostrado que a simulação com plem enta a verificação através da
verificação de modelos. '
N o capítulo seguinte é feita um a abordagem de simulação de sistemas dependentes de tem po especificadas em R T-LO TO S. As características de um sim ulador são discutidas, e a arquitetura interna de um a ferram enta de simulação é descrita.
Capítulo 3
Simulação de Especificações RT-LOTOS
A simulação de especificações formais envolve alguns aspectos de avaliação e transform ação das mesmas, que podem determ inar características im portantes de um a ferram enta de simulação. E ntre estes aspectos, o mais im portante é a escolha entre a simulação diretam ente sobre a especificação ou sobre o m odelo semântico subjacente. Tam bém é necessária a definição das funções que determ inam as possibilidades de evolução da especificação, além das funções que representam a evolução propriam ente dita. O u tro aspecto im portante é a definição do mecanismo de exploração das diferentes alternativas de evolução do com portam ento da especificação.
Estes aspectos serão abordados neste capítulo, prim eiram ente com um a análise das alternativas disponíveis, seguida da descrição detalhada da alternativa escolhida para o desenvolvim ento deste trabalho.
3.1 Modos de Simulação
Para a simulação de especificações formais de sistemas através de álgebras de processo, existem duas alternativas básicas:
• A tradução da especificação para o formalismo subjacente, tal com o u m grafo tem porizado ou um sistema de transições rotulado. Após a tradução, é feita a simulação sobre o formalismo, sendo o processo de simulação basicamente o de disparo de ações e transições entre estados. O s estados já foram todos previam ente calculados, com as transições possíveis já determinadas para cada estado. Basicamente, a simulação resume-se a percorrer os arcos do form alism o subjacente, com o grafo tem porizado ou sistema de transições rotulado.
• O cálculo das ações possíveis diretam ente da especificação, com o disparo de um a ação implicando no cálculo do novo estado, através da transform ação da especificação. Para cada novo estado alcançado, é necessário calcular-se novam ente as ações possíveis. N o disparo das ações e na passagem do tem po, ao invés de um a simples m udança de estado num m odelo do form alism o subjacente, é necessário o ■ cálculo da expressão de com portam ento resultante.
As ferram entas de simulação para L O T O S, incorporadas nos maiores pacotes de verificação e simulação, utilizam a prim eira abordagem. Algumas ferramentas deste tipo são: a ferram enta Caesar.open, do pacote C aesar/A ldebaran [Garavel94] e a ferram enta SMILE, do pacote M iniLite [Eertink92]. Estas ferramentas utilizam o sistema de transições rotuladas que são gerados p o r compiladores de especificações escritas em L O T O S . A simulação consiste basicamente em percorrer as transições do sistema de transições rotuladas.
Para sistemas dependentes de tem po, a mesma abordagem é possível. Apenas o form alism o subjacente muda, devido ao problem a da explosão de estados quando da utilização de sistemas de transições rotulados para representar especificações de sistemas dependentes de tem po. U m a alternativa é utilizar u m form alism o diferente, os grafos tem porizados, que podem contornar este problem a. Para o caso particular de R T -L O T O S, é a solução adotada, conform e m ostrado em [Camargo95]. U m trad u to r de R T -L O T O S para grafos tem porizados já foi im plem entado em [Martins96]. Para a extensão tem poral de L O T O S apresentada em [CoOl95], hom ônim a à apresentada neste trabalho, foi im plem entada um a ferram enta de simulação, denom inada RTL. Esta ferram enta realiza a simulação sobre o grafo tem porizado utilizado com o m odelo semântico subjacente àquela linguagem.
Porém , como discutido em [CaFa95, Garavel89, Martins96], e já m ostrado na seção 2.4, esta abordagem apresenta a restrição de poder apenas tratar especificações que levem a um sistema de transições finito. U tilizando esta abordagem, u m sim ulador pode apenas lidar com especificações que tenham representação em u m sistema de transições finito.
Em [Eijk89] é apresentada um a m etodologia de construção de um sim ulador para especificações formais baseada na segunda alternativa, a da transform ação das especificações. Esta m etodologia foi utilizada no desenvolvimento da ferram enta de simulação H ip p o [Tretmans89], do projeto ESPR IT/SED O S. Esta abordagem contorna o problem a da representação de especificações cujo com portam ento não possa ser representado p o r u m sistema de transições finito.
Esta segunda abordagem será utilizada no presente trabalho, pelo fato de possibilitar a validação de um espectro m aior de especificações, com plem entando assim as funcionalidades da ferram enta já existente para R T-L O TO S, apresentada em [Martins96]. Porém , mesm o contornando a restrição dos com portam entos finitos, ainda é necessário que a especificação analisada pela simulação não apresente expressões não guardadas [Camargo95, Martins96], com o m ostrado na seção 2.4.
N a continuidade deste capítulo serão apresentadas as definições das funcionalidades do núcleo do simulador, bem como os algoritmos de simulação.
3.2 Funções do Núcleo de Simulação
Seguindo a m etodologia proposta em [Eijk89], o prim eiro passo para a construção de u m sim ulador é a definição das funções do núcleo do mesmo. Estas funções dizem respeito à avaliação dos eventos que podem ocorrer num determ inado estado da especificação, e como atualizar a especificação em decorrência de um evento.
A o contrário de LO T O S, onde um a especificação pode apenas evoluir pela ocorrência de ações, nas especificações R T -L O TO S existem outras maneiras da especificação evoluir. A lém das ações clássicas de LO T O S, existem as ações semânticas de violação tem poral. Tam bém a passagem do tem po deve ser administrada, havendo situações na especificação em que a mesma é perm itida ou não, dependendo da existência ou não de ações ditas urgentes.
Ações urgentes são ações que devem ocorrer no m om ento atual da especificação. Assim, um a ação interna i com o intervalo [0, 0] associado é urgente. Ela deve ocorrer im ediatam ente, não perm itindo a passagem do tem po antes de sua ocorrência. Ações observáveis com intervalo [0, 0] não são urgentes. Porém , neste instante, tam bém há a possibilidade da ocorrência da violação tem poral, e esta sim é urgente. Assim, neste instante não são perm itidas ações de passagem do tem po até que ocorra ou a ação observável ou sua violação tem poral.
Desta form a, foram identificados dois grupos de funções necessárias para o núcleo do sim ulador de especificações R T-LO TO S:
• funções que m anipulam a evolução da especificação pela ocorrência de ações e violações tem porais, e
• funções que m anipulam a evolução da especificação pela passagem do tem po.
Para a manipulação da ocorrência de ações e violações tem porais, foram identificadas as seguintes funções:
• A c t i o n s ( B ): dada um a expressão de com portam ento B, esta função reto rn a u m conjunto de triplas ( a , t : , t 2), onde a é um a ação (observável, interna, térm in o com sucesso ou violação tem poral), e t i e t 2 são os limites inferior e superior, respectivamente, do intervalo no qual a ação pode ocorrer. O conjunto de triplas denota as ações oferecidas p o r B, prontas para ocorrer ou não.
• M enu(M ): esta função, aplicada sobre um conjunto de ações, reto rn a o subconjunto de todas os ações que estão prontas para ocorrer. O u seja, pesquisa u m conjunto de ações, procurando as ações que tenham seu lim ite inferior igual a zero.
• N e x t ( a , B ): esta função deve calcular o novo estado da especificação, a p a rtir da ocorrência do evento a no estado atual B. Este evento a pode ser um a das ações
da especificação (pertencentes ao conjunto A c t) , a ação interna ( i) , as ações de violação tem poral (pertencente ao conjunto A c t* ) e a ação de térm in o com sucesso (ô). A lém da expressão de com portam ento que represente o novo estado da especificação, a função N e x t deve reto rn ar tam bém a ação que deve ser vista pelo am biente de B.
Para tratam ento da parte tem poral das especificações R T-LO TO S, três foram as funções identificadas com o necessárias no núcleo do sim ulador. Estas funções são descritas a seguir.
• M in T im e (M ): esta função pesquisa o conjunto de ações tem porizadas de um a expressão de com portam ento (calculada pela função A c t i o n s ) , e reto rn a o tem po m ínim o que este conjunto perm ite passar. Este tem po pode ser o m en o r lim ite inferior, ou o m enor lim ite superior, dependendo do que fo r m enor. Em outras palavras, é o tem po m ínim o para que um a nova ação seja habilitada, ou para que um a ação urgente ou violação tem poral impeça a ocorrência de ações de passagem do tem po.
• M axT im e (M): esta função tam bém pesquisa o conjunto de ações tem porizadas, retornando o m enor limite superior deste conjunto. Pode-se dizer que é o tem po m áxim o que pode passar, antes que um a ação torne-se urgente. As violações tem porais tam bém são consideradas urgentes. Isto porque no limite superior do intervalo de um a ação, é necessário determ inar se o que vai ocorrer é a ação ou sua violação tem poral.
• D oT im e ( t , B ): esta função calcula o novo estado da especificação, resultante da passagem de t unidades de tem po no estado atual B. Este tem po não deverá ser m aior que o tem po m áximo perm itido antes de um a ação urgente, obtido através da função M axT im e (M ).
N a seqüência, todas estas funções serão definidas form alm ente, de m odo a gerar um m odelo de avaliação e evolução de especificações R T -L O T O S a ser utilizado no núcleo de um simulador. Para a definição form al destas funções, são necessárias algumas definições prelim inares, feitas a seguir.
V é o dom ínio de tem po da especificação, /tct é o conjunto das ações clássicas de R T-L O T O S, e/íct* é o conjunto das violações temporais, conform e definido na seção 2.3.
'M é um conjunto das triplas na form a (a, t i , t 2), onde a e /íc£"h u /&£*, t x e T> e t2 e TT. Cada elem ento de M é um a tripla que denota um a ação a qualquer, com seu intervalo de tem po associado, onde t i e t2 são os limites superior e inferior, respectivamente. É o conjunto de todas as ações da especificação em qualquer intervalo possível no dom ínio de tem po especificado. É im portante ressaltar que o limite inferior não pode ser infinito.
Será denom inado % o conjunto de todas as expressões de com portam ento
com portam ento. Estas ações podem estar prontas para serem realizadas ou não. Mais form alm ente, a função A c t i o n s é definida da seguinte forma:
A c t i o n s : ^ —>2™
onde 2™ representa o conjunto das partes de ffl.
A p a rtir de um a expressão de com portam ento B e S, a função A c t i o n s calcula u m conjunto M a 7%, de ações com intervalos de tem po associados presentes em B. A seguir, a função A c t i o n s é definida recursivamente sobre os operadores de R T-L O TO S.
Actions(stop) = 0
O processo s t o p não oferece nenhum a ação.
Actions(exit) = {(ô , 0, co)}
O processo e x i t pode realizar a ação de térm ino com sucesso 8, sendo seu lim ite inferior 0 e o superior infinito.
N a prefixação, as ações observáveis podem ocorrer no seu intervalo. As violações R T -L O T O S válidas. O u seja, o conjunto de todas as especificações R T -L O T O S possíveis, que não possuam expressões não guardadas, conform e definido na seção 2.4.
Q uando não indicado o contrário, a e e a * e Act''. N os intervalos de tem po
[ t i , t 2] , t i e Z) e t 2 e .
3.2.1 A Função Actions
A função A c t i o n s calcula o conjunto de todas as ações de um a expressão de
{(a,ti,t2),(a * ,t2, t2)} se t2* o o A a ^ i A ctions([ti,t2]a; B) = i {(a,ti,t2)}
{ (U l,t2)}
se Í2 = oo a a * i se a = i
tem porais ocorrerem no lim ite superior do intervalo da ação observável, som ente se este lim ite não for infinito. Para a ação interna, não é definida a violação tem poral. Intervalos default são assumidos quando não definidos explicitamente.
Actions(Bi [] B2) = Actions(Bi) u Actions(B2)
N a escolha, o conjunto de ações é a simples união dos conjuntos de ações de cada lado do operador.
A ctions(Bi|[L]|B2) = {(a,ti,t2)|(a,ti,t2) eA ctio n s(B i)A a g L u { ô } } u
{ ( a , t i , t2) |( a ,t i ,t 2) e A c tio n s (B 2) a a í L u { ô } } u
{(a,ti,t2)|(a,t3,t4) e A c tio n s (B i) A(a,t5,t6) e A c t io n s ( B2) a a e L u {ô} a ti = max(t3, ts) a t2 = min(t4, tõ) a ti < t 2}
N a composição paralela, o conjunto de ações é a união das ações das expressões de com portam ento de cada lado do operador, que não pertençam ao conjunto de sincronização. Para as ações do conjunto de sincronização, é necessário que sejam oferecidas dos dois lados do operador e que haja um a interseção do intervalo de tem po associado de cada lado do operador. E o que denota a definição do terceiro conjunto na expressão acima. E im portante no tar que cada ação a sincronizar oferecida de u m lado do operador, poderá sincronizar-se com qualquer ocorrência da mesma ação do ou tro lado do operador. Assim, todas as possibilidades de sincronização são determinadas.
A ctions(Bi» B2) = {(a,ti,t2)|(a,ti,t2) e Actions(Bi) a a * ô} u
{(i,ti,ti)|(ô ,ti,t2 ) e Actions(Bi)}
N a composição seqüencial, a ação de térm ino com sucesso ô é ocultada. P o r este m otivo, é necessário substituir suas ocorrências pela ação interna i , no conjunto de ações possíveis para esta expressão de com portam ento. C om o passa a ser urgente, o lim ite superior do intervalo é atualizado, sendo igualado ao lim ite inferior (geralmente 0).
Actions(Bi [> B2) = Actions(Bi) u Actions(B2)
N a preem pção o conjunto de ações é a união dos conjuntos de ações que podem ocorrer dos dois lados do operador.
A ctions(hideLinB ) = {(a,ti,t2)|(a,ti,t2) e Actions(B) a a £ L } u {(i,ti,ti)|(a,ti,t2 ) e Actions(B) a a gL}
N o operador de ocultação, as ações a serem ocultadas são substituídas pela ação interna i . Pela propriedade de progressão máxima, devem ocorrer no prim eiro instante possível. Assim, o lim ite superior é igualado ao lim ite inferior.
Actions(B < L] {ai: Q i,..., an: Qn}) = {(a, ti, t2) | (a, ti, t2) e Actions(B) a a e Act1,8} u {(a*,t2,t2)|(a*,t2,t2) e Actions(B) a a g L } u {(i, t2, t2) | (a*, t2, t2) e Actions(B) a a e L }
O operador de preempção tem poral oculta a ocorrência das violações tem porais das ação de L. Assim, todas as violação tem porais a serem tratadas são substituídas pela ação interna i .
Actions(P[ai,a2,...,an]) = A ctions(B[ai/gi,a2/g2,...,an/gn]) seP [gi,g2,...,gn] = B
