Modelagem de Banco de Dados em Tempo-real

Maria L.B. Perkusich, Maria de F.Q.V. Turnell e Angelo Perkusich Departamento de Engenharia Eltrica Universidade Federal da Paraba, Caixa Postal 10105 58109-970 - Campina Grande - PB Fone: +55 83 310 1135 Fax: +55 83 310 1015 {ligia,turnellm,perkusic}@dee.ufpb.br
Resumo Neste trabalho introduzimos um mtodo para a modelagem de Banco de Dados em Tempo-real (BDTR) utilizando uma notao de redes de Petri baseadas em objetos denominada EG-CPN. Esta notao enriquecida de modo a promover a descrio eciente de modelos integrando BDTR e Sistemas em Tempo-real (STR). O mtodo disponibiliza para o projetista construes que permitem, por exemplo, declarar restries lgicas e temporais e restries de execuo concorrente de mtodos no contexto de uma aplicao de BDTR. Alm disso, apresentamos um exemplo da aplicao do mtodo introduzido para a modelagem e validao dos objetos de controle e de banco de dados para uma clula exvel de manufatura. Abstract This work introduces a method to model Real-time Databases (RTDB) based on an object based Petri net notation named EG-CPN. This notation is enriched in order to promote the efcient description of a model integrating the RTDB and the Real-time system. The method makes available to the designer contructs allowing, for example, the declaration of logic and timing restrictions as well as concurrent execution of methods in a RTDB application. Moreover, we present an example where the method is applied in the modeling and validation of database and control objects of a exible manufacturing system cell.

1 Introduo
Nos ltimos anos as pesquisas na rea de Sistemas de Gerenciamento de Banco de Dados em Tempo-real (SGBD-TR) tem se intensicado [1, 8]. Estas pesquisas so motivadas pelo fato de que determinadas aplicaes precisam tratar com grandes volumes de dados, alm de dados e transaes com restries temporais. Um possvel encaminhamento visando solucionar tal problema seria buscar a integrao entre as tecnologias de Sistemas de Gerenciamento de Banco de Dados (SGBD) e Sistemas em Tempo-real (STR). Entretanto, como discutido em [1, 10, 14], a simples integrao destas tecnologias (conceitos, mecanismos, ferramentas) no suciente para se desenvolver um SGBD-TR. Questes como modelagem conceitual, controle de concorrncia, escalonamento, recuperao, entre outras, esto sendo consideradas e pesquisadas [1, 8, 10]. Dada a complexidade das aplicaes em tempo-real, muitos pesquisadores acreditam que o paradigma da orientao a objetos o mais apropriado para tratar com tais aplicaes [1]. Tambm faz-se necessrio o emprego de ferramentas ecazes com base formal para modelar tais aplicaes. No contexto de sistemas de banco de dados, principalmente no caso de grandes sistemas, a integrao uma capacidade crtica e vital. Dados de diferentes aplicaes devem ser integrados com o objetivo de possibilitar a coordenao de aplicaes individuais em consonncia com os objetivos corporativos.

Por outro lado, desejvel que o projeto de um STR se desenvolva de forma integrada ao seu BDTR, com base em um mtodo unicado, de forma a dispensar o desenvolvimento de interfaces necessrias adequao e integrao dos diferentes projetos desenvolvidos com base em ferramentas diferentes. Desta forma, para satisfazer o requisito de integrao no contexto de aplicaes com grandes volumes de dados e restries temporais, e a necessidade da utilizao de ferramentas formais no desenvolvimento de sistemas complexos, introduzimos neste trabalho um mtodo para a modelagem de STR e BDTR contemplando o requisito de integrao e a necessidade de embasamento formal. A base formal deste trabalho uma extenso de redes de Petri, incluindo principalmente o enriquecimento da notao de redes de Petri baseadas em objetos como denidas em [6, 13], de modo a promover a descrio eciente de modelos integrados do BDTR e do STR. Alm do modelo formal, o mtodo baseado tambm no modelo OMT (Object Modelling Technique) [15, 2], e no modelo RTSORAC (Real-Time Semantic Objects Relationships and Constraints) [3, 11]. Para exemplicar o mtodo, apresentamos a modelagem de uma clula de um sistema exvel de manufatura. Esta escolha foi principalmente motivada pelo fato de que as solues de controle para tais sistemas so baseadas em estruturas hierrquicas multi-nvel, onde no nvel mais baixo esto os controladores de cho de fbrica, e no nvel mais alto esto os responsveis por tomar decises estratgicas e de planejamento. Em tais sistemas, a necessidade de integrao entre os diferentes nveis de abstrao torna-se vital, e a disponibilizao de dados, tanto de planejamento de engenharia de produo, quanto de controle de processo, condio necessria para satisfazer os requisitos de produo. Este artigo est organizado da seguinte forma: na Seo 2 so introduzidos os conceitos bsicos de SGBD-TR. Na Seo 3 so introduzidos os conceitos bsicos de um modelo estendido de redes de Petri baseado em objetos, denominado EG-CPN, que utilizado como base formal no desenvolvimento do mtodo apresentado neste artigo. O mtodo para modelagem de STR e BDTR e sua exemplicao so apresentados nas Sees 4 e 5, respectivamente. Finalmente, na Seo 6 so apresentadas as concluses deste trabalho.

2 Banco de Dados em Tempo-real

Um SGBD-TR pode ser visto como a integrao de um SGBD convencional com um STR [1]. Assim, um SGBD-TR alm de processar transaes e garantir a integridade dos dados, deve tambm operar em tempo-real, para satisfazer as restries temporais impostas aos dados e transaes. Destacam-se como caractersticas principais de um SGBD-TR a noo de dados temporalmente consistentes, e a habilidade para denir restries temporais s transaes. Deve-se observar que h casos em que as restries temporais impostas s transaes precisam ser satisfeitas com o objetivo de manter a consistncia temporal dos dados. Em algumas situaes estas restries s podem ser satisfeitas se a consistncia lgica dos dados for sacricada. Em outras, para manter a consistncia lgica dos dados, a consistncia temporal deve ser sacricada. Uma vez que estas situaes so bastante freqentes em SGBD-TR, os resultados produzidos por uma transao no precisam ser totalmente corretos, ou seja, podem ser imprecisos. Portanto as propriedades ACID [9] no precisam ser cumpridas totalmente, e foram redenidas para SGBD-TR como ser discutido na Seo 2.1. Por exemplo, em um sistema de controle de trfego areo, a posio aproximada de um avio no tempo certo pode ser mais apropriada que o valor exato tarde demais. Geralmente a impreciso permitida deve ser limitada. No exemplo anterior, a impreciso na posio do avio deve ser de apenas alguns metros, considerada a posio verdadeira. Idealmente os dados gravados em um BDTR devem ser idnticos em valor ao seu correspondente no ambiente. No entanto, geralmente h um atraso de atualizao no BDTR, o que pode levar a inconsistncias entre estes valores. Portanto necessrio um mecanismo para vericar a consistncia temporal do dado face extenso do atraso na sua atualizao [14]. Um tal mecanismo, pode ser baseado na de-

nio de um rtulo de tempo (timestamp) e de um intervalo de validade absoluta (avi) para cada dado ou conjunto de dados a serem gravados no banco de dados. Neste trabalho o timestamp indica o tempo quando o valor do dado foi gravado. O avi indica por quanto tempo o valor do dado vlido. A consistncia temporal dos dados pode ser medida de duas maneiras [14]: Consistncia absoluta entre o valor real de um tem de dado no ambiente de aplicao e o valor correspondente no banco de dados. Ento, a idade de um tem de dado deve estar dentro do intervalo de validade absoluta especicado. Esta medida surge da necessidade de manter o banco de dados consistente com o estado real do ambiente. Consistncia relativa entre os itens de dados que so usados para calcular outros dados. Os itens de dados que sero usados na computao de outros dados devem ser gravados dentro de um intervalo de tempo relativo especicado. Esta medida surge da necessidade de assegurar que dados que sero usados na computao de outros dados representem aproximadamente o mesmo instante de tempo do ambiente. De modo geral as transaes em um SGBD-TR podem ser classicadas como: transaes de escrita (ou sensores), transaes de atualizao e transaes de leitura [14]. As transaes de escrita, tipicamente peridicas, obtm o estado do ambiente e escrevem os dados no banco de dados. As transaes de atualizao tanto podem ler quanto escrever no banco de dados periodicamente ou aperiodicamente. As transaes de leitura, lem dados do banco de dados e tambm podem ser peridicas ou aperidicas. Uma transao em SGBD-TR tambm pode ser classicada com base no efeito de no cumprir sua restrio temporal, em estrita, suave ou rme1 . Estrita: uma transao estrita quando qualquer resultado produzido aps seu deadline intil para o sistema. Isso signica que qualquer transao estrita deve ser abortada quando no puder cumprir seu deadline, independentemente de sua conseqncia. Suave: uma transao suave quando o resultado produzido aps seu deadline sempre tem algum valor, que vai perdendo sua utilidade a medida que se distancia de seu deadline. Firme: uma transao rme quando a perda do deadline no gera nenhum efeito ou valor para o sistema. Geralmente estas transaes so recomeadas quando perdem seu deadline. As restries de tempo impostas s transaes podem se originar de dois tipos de requisitos: requisitos de consistncia temporal dos dados e requisitos impostos pelo sistema em relao ao tempo [14]. O primeiro assume a forma de requisito de periodicidade, por exemplo: a cada 20 segundos verique a temperatura do ambiente. O segundo geralmente, assume a forma de deadlines impostos s transaes aperidicas, por exemplo: se temperatura > 1000 graus, adicione lquido refrigerador ao reator dentro de 5 segundos.

2.1 Propriedades ACID em BDTR

As transaes de um SGBD so estruturadas para cumprir as propriedades ACID [9]. Estas propriedades possibilitam a avaliao da consistncia lgica dos dados e transaes. No entanto, no consideram os requisitos de consistncia temporal existentes nos BDTR. Portanto, para suportar aplicaes em tempo-real, as propriedades ACID foram redenidas, passando a permitir melhor suporte a consistncia temporal enquanto mantm suporte a consistncia lgica. Estas redenies utilizam informao semntica para determinar em que grau as propriedades ACID podem ser relaxadas [3]. A conseqncia do
1

Traduo para os termos do ingls hard, soft e rm, respectivamente.

relaxamento destas propriedades a introduo de impreciso no banco de dados. As redenies das propriedades ACID incluem atomicidade, consistncia, isolamento, e durabilidade. A atomicidade garante que uma transao totalmente executada ou nenhum passo dela executado. Para transaes em tempo-real, a execuo atmica seletivamente aplicada s subtransaes que necessitam tratar com dados totalmente consistentes, ao invs de aplica-la transao toda. Como um BDTR pode ser impreciso, algumas vezes no necessrio desfazer toda a transao. Assim uma transao pode terminar com um estado inconsistente, desde que a impreciso seja limitada. Por exemplo, considere uma transao que est atualizando dados sobre o ambiente, perde seu deadline e deve parar de executar. Geralmente desnecessrio desfazer suas atualizaes, uma vez que os valores anteriores tambm esto desatualizados. Alm do mais, pode ser mais interessante dispor de um banco de dados parcialmente atualizado do que de um banco de dados totalmente desatualizado. A propriedade de consistncia garante que a execuo de uma transao sempre transforma o estado consistente de um banco de dados em um outro estado consistente. As transaes em SGBD-TR devem suportar uma negociao entre manter consistncia lgica ou temporal. Esta negociao pode introduzir impreciso no banco de dados. Algumas aplicaes em tempo-real podem suportar inconsistncias no banco de dados. Por exemplo, dados que mudam freqentemente no precisam ser atualizados a cada mudana, o que consumiria tempo de computao e recursos. Geralmente nessas aplicaes as atualizaes so realizadas apenas quando dados atualizados so necessrios. A propriedade de isolamento garante que as aes de uma transao no so visveis a nenhuma outra transao at que ela seja comprometida. Isto implica que no existem interdependncias na execuo das transaes. Em SGBD-TR, as transaes podem precisar se comunicar e sincronizar com outras transaes de forma a executar funes de controle, portanto suas aes podem ser vistas por outras transaes mesmo antes do comprometimento. Alm disso, algumas transaes podem ter restries temporais e podem usar dados que precisam ser temporalmente consistentes. Assim, os dados gerados por uma transao no comprometida podem ser vistos por outras transaes para evitar que tornem-se desatualizados, ou que no satisfaam suas restries temporais. A propriedade de durabilidade garante que as aes de uma transao no banco de dados so permanentes. Em BDTR, alguns dados tem validade temporal e no precisam ser gravados. Por outro lado, o banco de dados deve reetir o estado do ambiente, portanto fcil recria-lo a partir da leitura dos sensores, ao invs de recria-lo no tempo em que ocorreu uma falha, pois esses dados provavelmente j sero invlidos.

2.2 Controle de Concorrncia Semntico em SGBD-TR

Alguns pesquisadores sugerem que o mecanismo de controle de concorrncia de um SGBD-TR seja semntico [1, 3]. Isto , informao semntica sobre o sistema pode ser utilizada para determinar quais as transaes que podem ser executadas concorrentemente. Este mecanismo permite maior concorrncia em BDTR, embora uma sobrecarga seja imposta ao sistema e ao projetista. O projetista deve conhecer bem cada transao para denir quais e em que condies as transaes podem ser executadas concorrentemente. Ento, importante que o mtodo de modelagem utilizado disponibilize mecanismos para descrever e vericar o controle de concorrncia.

3 Introduo aos Sistemas EG-CPN

A base formal para o mtodo que introduziremos um modelo de redes de Petri baseado em objetos denominado EG-CPN (Extended Generalized Coloured Petri Nets), que por sua vez uma extenso do modelo G-CPN [6, 5, 13]. G-CPN uma estrutura de redes de Petri baseada em objetos para a especicao e modelagem de sistemas distribudos de software. Devido s limitaes de espao, neste artigo

no introduziremos a formalizao dos modelos G-CPN e EG-CPN, o leitor interessado pode consultar [6]. As extenses incorporadas ao modelo objetivam enriquecer a notao de G-CPN, de modo que a descrio de especicaes no domnio de aplicaes envolvendo BDTR possam ser mais compactas, permitindo declarar restries lgicas e temporais e compatibilidade entre execuo concorrente de transaes. No que segue, um objeto uma quntupla hN; AT; MT; R; FC i, onde: 1. 2.

3.

N um identicador nico para um objeto AT = ATa ATt um conjunto de atributos, onde ATa e ATt so conjuntos de atributos atemporais e temporais, respectivamente. 8aa 2 ATa ; aa = hN; V i, onde: N o nome do atributo e V o valor do atributo. 8at 2 ATt ; at = hN; V; TS; AV I; I i, onde: TS o timestamp; AV I o intervalo de validade absoluta para o atributo, e; I a impreciso acumulada para o atributo. MT um conjunto de mtodos, e 8mti 2 MT , mti denido pela dupla hArge; Argri, onde Arge e Argr so os conjuntos de argumentos de entrada e de retorno, respectivamente. 8argei 2 Arge, argei = hN; V; TS; AV I; I ; LMIe i, onde N , V , T , AV I , e I so como denidos para ATt , e LMIe especica o limite mximo de impreciso que pode ser passado pelo mtodo. 8argri 2 Argr , argri = hN; V; TS; AV I; I ; LMIr i, onde N , V , T , AV I , e I so como denidos para ATt , e LMIr especica o limite mximo de impreciso permitido no valor
retornado.

4.

R um conjunto de restries lgicas e temporais que denem o estado correto de uma instncia de um objeto. Uma restrio denida como um predicado que pode incluir os campos V , TS , AV I e I , de um atributo. Atravs destes predicados declaram-se as restries lgicas e temporais,
bem como os limites de impreciso para os atributos. Por exemplo, na Figura 3, o predicado DB:i  2, indica que o limite mximo de impreciso permitido para o atributo DB 2. Observe que o limite mximo de impreciso de um atributo pode ser declarado no conjunto de restries do objeto e nos argumentos dos mtodos, LMIe 2 argei e LMIr 2 argri . Isto permite maior exibilidade para o projetista denir seus limites de acordo com as necessidades da aplicao.

5.

FC uma funo de compatibilidade que utiliza informao semntica sobre os objetos e o estado do sistema para determinar quando dois mtodos de um objeto podem ser executados concorrentemente, e denida por FC mi ; mj  =(expresso booleana) IA, onde mi o mtodo que est executando, mj o mtodo que foi invocado e (expresso booleana) pode conter predicados envolvendo vrias caractersticas do objeto ou do sistema, tais como: tempo atual e o intervalo de validade absoluto AV I do atributo, limite mximo de impreciso LMI e a impreciso acumulada I do atributo, entre outras. IA denida por uma expresso que calcula a impreciso acumulada nos atributos e nos argumentos dos mtodos.

A expresso booleana pode ser avaliada para determinar se os dois mtodos podem executar concorrentemente. Se ela for avaliada como verdadeira ento os mtodos podem executar concorrentemente e a impreciso calculada, caso contrrio, o mtodo invocado no pode ser executado. A FC pode ser utilizada para expressar uma negociao entre manter consistncia lgica ou temporal de acordo com a semntica da aplicao. Ela permite a execuo concorrente de mtodos que podem introduzir impreciso nos atributos e nos argumentos do mtodo. Por isso, alm de especicar compatibilidade entre a execuo concorrente de mtodos, a FC tambm expressa informao sobre a quantidade de impreciso que pode ser introduzida pela execuo concorrente dos mtodos. Observe que um mtodo invocado pode no ser executado se os dados que ele acessa so muito imprecisos para seus requisitos. Ento deve existir alguma forma de recuperar a preciso dos dados de forma que o mtodo

EG-CPNm

Mtodos Atributos Restries Funo de compatibilidade

Invocao

Ativao

EG-CPNn Mtodos Atributos Restries Funo de compatibilidade lugar de ativao outros elementos do mtodo lugar de terminao

Controle de Contexto Troca de Mensagens Lugar superior G-CPNn Lugar Inferior

ISP

Retorno

Terminao

Ambiente de Interao

Cliente

Servidor

Figura 1: Sistema EG-CPN e eventos na interao no que bloqueado denitivamente. Uma forma criar mtodos, que podem ser ativados periodicamente, para escrever dados precisos no banco de dados. Assim os mtodos bloqueados pela impreciso dos dados podem ser executados.

3.1 Sistemas EG-CPN

Sistemas EG-CPN so conjuntos de mdulos EG-CPN, concorrentes, cooperantes e fracamente acoplados para modelagem/especicao formal e executvel de aplicaes envolvendo BDTR. Estruturalmente um sistema EG-CPN a integrao de um conjunto de mdulos EG-CPN e um ambiente de interao. Cada mdulo EG-CPN dene um objeto instancivel do sistema. O ambiente de interao o elemento responsvel pela semntica de transferncia de mensagens entre os mdulos. O modelo de interao entre mdulos EG-CPN tipicamente cliente-servidor. Um mdulo cliente requisita um servio (execuo de um mtodo) em um mdulo servidor. Quando a requisio atendida pelo ambiente, diz-se que uma invocao ocorreu. A partir da, o mdulo cliente apenas espera que o ambiente faa efetivamente a ativao do servio remoto, e passa a esperar a chegada da resposta. O ambiente avalia a funo de compatibilidade. Caso ela seja avaliada como falsa, a invocao ser enleirada para uma posterior tentativa, quando algum mtodo que estiver sendo executado terminar. Caso seja avaliada como verdadeira ele efetua uma ativao do mtodo invocado no mdulo servidor atravs da passagem dos dados necessrios ao mtodo. O mdulo servidor, agora ativo, atende ao pedido. Quando for obtido um resultado, o ambiente detecta a disponibilidade desses resultados (chas em um lugar de terminao do mtodo) e os retoma a m de retransmiti-los ao mdulo cliente (terminao). Aps a ocorrncia da terminao no mdulo servidor, o ambiente detecta o mdulo cliente correspondente e devolve corretamente os dados, forando a ocorrncia do ltimo evento associado interao, denominado retorno.

3.2 Mdulo EG-CPN

Um mdulo EG-CPN estruturalmente representado por duas subestruturas: a primeira representa a interface do mdulo e denominada GSP (Generic Switching Place); a segunda a estrutura interna do mdulo - IS (Internal Structure). A interface determina a viso do mdulo para o resto do sistema. Nela esto declarados os atributos, mtodos encapsulados, restries lgicas e temporais (referidas como Restries na Figura 1), e as funes de compatibilidade. Os atributos representam os dados sobre os quais o mdulo atua. Os mtodos representam os servios oferecidos pelo mdulo. Para cada mtodo declarado na interface existem dois lugares diferenciados na IS: lugar de ativao e lugar de terminao. O primeiro determina onde sero colocadas as chas de ativao do mtodo; e o segundo determina onde sero colocadas as chas com o resultado. A estrutura interna sintaticamente uma rede de Petri Colorida (CPN) [7]. A semntica modicada devido a introduo de um lugar especial na IS, denominado ISP (Instantiating Switching Place) que utilizado para representar invocaes de mtodos remotos. ISPs so

denotados por elipses e uma inscrio interna indicando qual mtodo e EG-CPN invocar. Internamente, um ISP formado por dois lugares: lugar superior e lugar inferior. Seu funcionamento intuitivo, ou seja: quando uma cha depositada no ISP (lugar superior), uma invocao pode ocorrer, implicando no desaparecimento da cha; em seguida, dependendo do funcionamento do mtodo remoto, dever ocorrer um retorno, e uma outra cha com novos dados ser depositada no ISP (lugar inferior), permitindo a habilitao das transies de sada, observe a Figura 1. Os lugares normais, bem como atributos e lugares que indicam ativao de mtodos so representados gracamente por crculos. Os lugares de terminao so representados por crculos de borda dupla. Os demais elementos (transies e inscries) seguem a mesma notao usada em G-CPN e CPN. Uma exceo deve ser notada: dois conjuntos de cores so associados a cada ISP, um para chas de invocao (lugar superior) e outro para chas de terminao (lugar inferior). Um nico mdulo EG-CPN pode atender a qualquer nmero de pedidos de servios concorrentemente. Isso possvel, porque ao ocorrer uma ativao, uma nova instncia do mdulo, criada automaticamente, ser encarregada de atender o pedido. Cada instncia tratada pelo que denomina-se de contexto. Um contexto pode ser visto como um novo objeto cuja estrutura funcional uma cpia el da estrutura interna do mdulo invocado. A nica exceo quanto aos lugares que representam atributos, que no sero copiados, mas compartilhados. O contexto automaticamente destrudo quando no restarem mais chas relativas quela invocao na rede. Os atributos em mdulos EG-CPN so associados a lugares na estrutura interna. Como atributos so considerados parte do estado global do objeto, o seu estado (marcao) nico e portanto, compartilhado por todos os contextos do mesmo mdulo EG-CPN. Consequentemente, os diversos contextos ativos concorrem pela utilizao dos atributos (chas nos lugares que os representam). Esta forma de denir o modelo EG-CPN permite que durante a modelagem, um mdulo EG-CPN represente um objeto propriamente dito, com caractersticas intrinsecamente concorrentes, ou uma classe, que a cada invocao constri objetos idnticos. Neste caso, os atributos declarados devem representar atributos de classe. Maiores detalhes relacionados denio formal bem como modelagem de transaes e acesso aos dados podem ser encontrados em [6, 13].

4 Mtodo para Modelagem de Banco de Dados em Tempo-real

Nesta seo apresenta-se um mtodo para modelagem de STR e BDTR. A aplicao do mtodo resulta na obteno de dois modelos: o modelo de objetos, usado para modelar as propriedades estticas do sistema e, o modelo de processos, usado para modelar as propriedades dinmicas do sistema.

4.1 Modelo de Objetos

O modelo de objetos baseado no modelo de objetos do mtodo OMT e no modelo RTSORAC. O mtodo OMT, usa trs modelos complementares para modelar sistemas: Modelo de Objetos, Modelo Funcional e Modelo Dinmico [2]. O Modelo de Objetos caracteriza as propriedades estticas dos objetos, tais como, atributos, operaes e restries lgicas. O Modelo Funcional dene as operaes que os objetos executam. O Modelo Dinmico descreve as interaes temporais entre os objetos e suas respostas a eventos. Ele mostra sob quais condies as operaes so executadas e por quanto tempo elas devem continuar executando. A notao do modelo de objetos OMT simples e intuitiva, no entanto no permite a representao de algumas caractersticas de um BDTR. Portanto, baseado no modelo RTSORAC, que considera tais caractersticas, algumas extenses foram incorporadas ao modelo de objetos OMT, para permitir modelar um BDTR. A modelagem dos objetos comea com uma anlise da declarao do problema e tem os seguintes passos:

1. Identicao dos objetos; 2. Identicao dos relacionamentos entre objetos; 3. Adio dos atributos dos objetos; 4. Uso de generalizao para observar similaridades e diferenas; 5. Identicao das operaes; 6. Identicao das operaes compatveis, ou seja, que podem ser executadas concorrentemente; 7. Identicao das restries lgicas e temporais; 8. Renamento do modelo; Rumbaugh [15] detalha os passos 1-5 e 8. Os passos 6 e 7 foram introduzidos no modelo de objetos do mtodo apresentado para denir restries lgicas e temporais, assim como as operaes compatveis. No modelo de objetos, os objetos e seus relacionamentos so descritos atravs de um diagrama de classes, como na Figura 3. Uma classe representada atravs de um retngulo dividido em cinco partes. Na parte superior descreve-se o nome da classe. Na segunda parte descrevem-se os atributos. Na terceira parte listam-se as operaes. Na quarta parte indica-se as operaes compatveis, denidas por meio de funes de compatibilidade. Na quinta parte descrevem-se as restries lgicas e temporais.

4.2 Modelo de Processos (Funcional e Dinmico)

O modelo de processos, baseado no modelo EG-CPN e usado para modelar as propriedades funcionais e dinmicas dos objetos, isto , ele pode ser visto como a combinao do modelo funcional e do modelo dinmico em um nico modelo. O modelo de processos pode ser usado nas fases de anlise, projeto e implementao do sistema. Estas fases podem ser tratadas simultaneamente, uma vez que as redes EGCPN podem ser simuladas e os requisitos analisados. Ento, o projetista de uma aplicao pode usar as EG-CPNs para simular a aplicao e discutir os detalhes do comportamento dinmico da aplicao com os usurios em todos os estgios da especicao. 4.2.1 Obtendo o Modelo de Processos

No modelo de processos os objetos so descritos atravs de mdulos EG-CPN. Ele denido a partir do modelo de objetos. Ento, para cada objeto (contendo operaes), identicado no modelo de objetos, criado um mdulo EG-CPN, no qual sero modelados as operaes dos objetos correspondentes. A obteno do modelo de processos envolve os seguintes passos: 1. Identicao dos objetos (EG-CPNs) corresponde aos objetos do modelo de objeto; 2. Identicao das funcionalidades de cada objeto corresponde s funcionalidades das operaes dos objetos; 3. Denio da interface de cada objeto (GSP) - indica os atributos, as operaes e seus argumentos de entrada e sada, as restries lgicas e temporais, e as operaes compatveis, para o objeto; 4. Denio da estrutura interna de cada objeto (IS ) modelagem das operaes (mtodos) do objeto. A aplicao dos passos ilustrada na seo seguinte atravs de um exemplo.

peas no reconhecidas M1 NR P1

tipo 1 MP1

esteira PP peas produzidas M2 E2 Robo R2 RE peas rejeitadas

esteira E1 Robo R1 C P2 camera MP2 tipo 2

Figura 2: Uma clula de manufatura

5 Exemplicando o Mtodo
Para exemplicar a utilizao do mtodo, considere a clula de manufatura mostrada na Figura 2. Ela composta pelos robs R1 e R2, quatro mquinas P1, P2, M1, M2 que produzem peas do tipo1 e tipo2, cinco depsitos MP1, MP2, NR, NE e PP, duas esteiras E1 e E2, e uma cmera C. As mquinas P1 e P2 realizam o pr-processamento da matria-prima. As mquinas M1 e M2 realizam o processamento nal da matria-prima. As esteiras E1 e E2 transportam as peas dentro da clula. O rob R1 transporta a matria-prima dos depsitos MP1 e MP2 para as mquinas P1 e P2, respectivamente, e deles para a esteira E1. A cmera C obtm as imagens das peas, e a partir destas imagens e de um banco de dados contendo tipos de peas, estas so reconhecidas e classicadas como tipo1 ou tipo2. O rob R2 remove as peas da esteira E1 e as coloca nos depsitos NR ou NE ou nas mquinas M1 ou M2. Peas no reconhecidas, por falta de tempo, so colocadas no depsito NR para inspeo futura. Peas no reconhecidas, por no constarem no banco de dados, so colocadas no depsito de rejeitados RE. Peas reconhecidas so colocadas nas mquinas M1 ou M2, de acordo com seu tipo, tipo1 ou tipo2, respectivamente. Aps o processamento, as peas so depositadas na esteira E2, que as conduz para o depsito de peas produzidas PP.

5.1 Obtendo o Modelo de Objetos

Inicialmente cria-se o modelo de objetos para a clula, de acordo com os passos indicados na Seo 4.1. Em seguida, esse modelo utilizado como base para o projeto do modelo de processos. O modelo de objetos para a clula de manufatura da Figura 2 apresentado na Figura 3.

5.2 Obtendo o Modelo de Processos

De acordo com a Seo 4.2, os seguintes passos devem ser seguidos para se obter o modelo do processo em EG-CPN. Passo 1: Identicao dos Objetos Os objetos identicados so: equipamento, rob, pea, cmera e CELLDB. Neste artigo assume-se que as esteiras e depsitos tm capacidade suciente para suportar o uxo de materiais e, portanto no sero considerados na concepo do modelo. Para exemplicar o modelo de processos vamos considerar apenas os objetos pea, cmera e CELLDB, modelados pelas EG-CPNs PART, CMERA e CELLDB, respectivamente. Os demais objetos encontram-se detalhados em [13, 12].

CELLDB ATRIBUTOS
DB: TIPO*QUANTIDADE *AVI*TIMESTAMP*IMPRECISO TIPO: cadeia de caracteres QUANTIDADE: inteiro avi: inteiro TIMESTAMP=ts: time IMPRECISO=i: inteiro MTODOS MTODOS RP( ) Ler quantidade de peas MP( ) Processa pea RESTRIES TIPO com SP1,SP2 RP( ) Ler quantidade de peas FUNO DE COMPATIBILIDADE FC(RP(pr),AT(pa))=((NOW-DB.ts >DB.avi) and (|DB.v-pa.v| <= pr.lmir- (pr.i+pa.i)) ->pr.i=pr.i+pa.i+|DB.v-pa.v| RESTRIES TIPO com T1,T2,Trj,Tni NOW-DB.ts <= DB.avi; DB.i <=2

MQUINA
ATRIBUTOS ESTADO: inteiro NOME: cadeia de caracteres TIPO: cadeia de caracteres QUANTIDADE: inteiro

PEA
ATRIBUTOS TIPO: cadeia de caracteres QUANTIDADE: inteiro

. . .

PLANO DE PROCESSO
ATRIBUTOS #PLANODEPROCESSO: inteiro VERSO: cadeia de caracteres DESCRIO: cadeia de caracteres DATA: data

ROBO
MTODOS MM( ) Move rob DR( ) Desaloca rob RESTRIES TIPO com R1,R2

EQUIPAMENTO
MTODOS MA( ) Aloca mquina DA( ) Desaloca mquina RESTRIES TIPO com P1,P2,M1,M2

CAMERA
MTODOS RP( ) Ler pea IDP( ) Identifica pea

. . .

Figura 3: Modelo de dados para a clula de manufatura da Figura 2

Passo 2: Funcionalidades O objeto pea, modelado pela EG-CPN PART, apresentada na Figura 6, deve identicar o tipo da pea a ser pr-processada, alocar o equipamento para iniciar o pr-processamento da pea, e atualizar no buffer a quantidade de peas pr-processadas (mtodo mp). Tambm deve permitir a leitura da quantidade de peas pr-processadas (mtodo rp). O objeto cmera, modelado pela EG-CPN CMERA, apresentada na Figura 7, deve decidir a rota que uma pea deve seguir, de acordo com o seu tipo (tipo 1, tipo 2, no reconhecido, ou rejeitado). Peas identicadas devem ser enviadas para processamento nal, nas mquinas M1 ou M2. Peas no reconhecidas devem ser enviadas para o depsito de peas no reconhecidas NR ou depsito de rejeitados RE. Tambm deve atualizar no buffer a quantidade de peas nalizadas, no reconhecidas e rejeitadas (mtodo idp). Ele tambm deve permitir a leitura da quantidade de peas nalizadas, no reconhecidas e rejeitadas (mtodo rp). O objeto cellbd, modelado pela EG-CPN CELLDB, apresentada na Figura 8, tem o objetivo de ler (mtodo rp) e atualizar (mtodo at) no banco de dados a quantidade de peas pr-processadas, nalizadas, no reconhecidas e rejeitadas.

Passo 3: Interface dos Objetos Para a EG-CPN PART, a interface denida pelos mtodos mp e rp, e pelo atributo SPD que corresponde a um buffer, onde sero armazenadas as quantidades de peas pr-processadas. Para a EG-CPN CMERA, a interface denida pelos mtodos idp e rp, e pelo atributo PD que corresponde a um buffer, onde sero armazenadas as quantidades de peas nalizadas, no reconhecidas e rejeitadas. Para a EG-CPN CELLDB, a interface denida pelos mtodos rp e at, pelo atributo DB que corresponde ao banco de dados onde so armazenados os dados sobre peas, pelas restries e funo de compatibilidade.

color PART,NAME = with t1|t2|trj|tni; color SPART = with sp1|sp2; color PARTS = union PART + SPART; color AVI = int; color TIME = int; color INT,VALUE,I = int; color PARTN = product PART*INT; color SPARTN = product SPART*INT; color DBO = product NAME*VALUE*AVI*TIMEN*I; color ROBO = with r1|r2; color PART_ROBO = product PART*ROBO; color STAGES = with st1|st2|st3|st4; color MOVE_ROBO = product PART*ROBO*STAGES var n,m,i : INT; var nts,ts : TIME; var st : SPART; var avi : AVI; var p : PART; var pr,pa : DBO

Figura 4: Conjuntos de cores para as EG-CPNs

Control Objects Database Objects

Hierarchy#10

Parts#5

Pattern#8

CellDB#7

Recovery#9 Equipment#3

Camera#1

TimingCellDB#10 Robot#4

Environment#2

Declarations#6

Figura 5: Hierarquia para o modelo

Passo 4: Estrutura Interna Finalmente, no quarto passo, dene-se a estrutura interna de cada objeto. A estrutura interna uma rede EG-CPN que modela as operaes (mtodos) declaradas na interface do objeto.

5.3 Comportamento dos Objetos Modelados em EG-CPN

Para modelar a clula utilizou-se a ferramenta Design/CPN [7, 16]. O conjunto de cores para as EGCPNs so apresentadas na Figura 4. Na Figura 5 apresentamos a hierarquia para o modelo. As linhas cheias nesta gura indicam as relaes de conhecimento entre os objetos, ou congurao. Observe que o objeto TIMINGCELLDB, no apresentado neste artigo, temporiza a leitura do estado da clula, obtendo o nmero de peas pr-processadas, atravs do objeto PART, e o nmero de peas processadas do tipo1, tipo2, no reconhecidas ou rejeitadas, atravs do objeto CMERA, e atualizando o objeto CELLDB. Note que, o TIMINGCELLDB realiza a interface entre os objetos de banco de dados e os de controle. Observe ainda que o objeto ENVIRONMENT modela o comportamento do ambiente de interao, promovendo os eventos descritos na Seo 3. De fato, este objeto no seria necessrio, entretanto devido ao fato de utilizarmos a ferramenta Design/CPN, para a modelagem e validao, e por esta no tratar diretamente com EG-CPN existe a necessidade de transformar o sistema EG-CPN em uma CPN hierrquica. Pelo mesmo motivo, nos modelos para os objetos apresentados neste artigo, os isps so representados por dois lugares, um superior, de onde o ambiente retira chas referentes a invocaes e um inferior, onde o ambiente deposita chas de retorno. Os isps so representados por linhas tracejadas nas guras que seguem. Ainda, importante enfatizar, que tanto a funo de compatibilidade como as restries tambm devem ser mapeadas para CPN, no modelo apresentado. Esta transformao foi omitida, com o objetivo de simplicar a apresentao. Ento, observando o modelo de objetos apresentado na Figura 3 verica-se que alguns componentes foram acrescidos na hierarquia do modelo apresentado na Figura 5.

PART

MT = {mp(:PART):PART;rp(:SPART):SPARTN} AT = {SPD(:SPARTN)}
p rp

SPART

PART
mp p p t4 t3 p p sp

1t1 + 1t2 pr tp @timeout [tp = p] t1

PART

PART
(p,r1) RECOVERY.mf p

PART

PART_ROBOT
EQUIPMENT..ma

t5 (sp,0)

PART
(sp,n) p

(sp,n) SPD (sp,n) 1(st1,0) + 1(st2,0)

SPARTN

t2

p gprspd case sp = st1 andalso p = t1 then 1(st1,n+1) else 1(st2,n+1)

PART

SPARTN

gp2

Figura 6: EG-CPN para o objeto PART

5.3.1

Comportamento para o Objeto PART

Na Figura 6 apresenta-se a EG-CPN para o objeto pea, PART. Como visto anteriormente, dois mtodos so denidos para este objeto: mtodo mp e mtodo rp. Quando o objeto PART invocado para prprocessar uma pea, com o mtodo mp, uma cha depositada no lugar mp. De modo a iniciar o pr-processamento de uma pea, tanto o equipamento associado produo da pea como o rob devem estar disponveis. Caso a transio t1 dispare, o pr-processamento de uma pea (seja do tipo1 ou tipo2) iniciado. Aps o disparo da transio t1, o objeto EQUIPMENT invocado com o mtodo ma (aloca mquina), de modo a alocar o recurso P1 ou P2 para o pr-processamento de uma pea, e para alocar o rob para mover a pea para a esteira assim que o pr-processamento termine. Observe que o objeto EQUIPMENT invocado apenas se o sistema no estiver alocado para o processamento do tipo especco indicado na invocao. Quando o resultado do objeto EQUIPMENT retornado, a transio t2 pode ocorrer. No caso de ocorrer, a cha no lugar SPD atualizada e o objeto PART termina sua invocao. Observe que quando a transio t2 ocorre, uma cha removida do lugar SPD que mantm a informao relacionada com a pea pr-processada, a varivel n incrementada de uma unidade, e a cha com este novo valor depositada no lugar SPD. Uma cha no lugar gp2 indica o m da execuo do mtodo mp. De modo a considerar tolerncia a falhas e disponibilizar a correta reinicializao do objeto PART, utiliza-se um time-out, modelado pela transio temporizada t3. Quando esta transio ocorre, um objeto de recuperao invocado(RECOVERY.mf), e o objeto reinicializado. O objeto RECOVERY no apresentado neste trabalho. O mtodo rp realiza a leitura do nmero de peas pr-processadas. Quando ele invocado, uma cha depositada no lugar rp, indicando o tipo a ser lido. Quando a transio t5 ocorre, uma cha com o nmero de peas de um determinado tipo removida do lugar SPD e outra colocada para aquele tipo com o valor zero. O valor n e o tipo so retornados quando o lugar alvo gprspd alcanado.

CAMERA

MT = {idp(:PART):PART;rp(:PART):PARTN} AT = {PD(:PARTN)
idp p PART [p=t1 orelse p=t2]

rp [p=trj orelse p=tni] p t6

t7 (p,r2)

(p,r2,st3)

MOVE_ROBOT
Robot.mm tread (p,0)

PART_ROBOT

Equipment.ma

PART_ROBOT
(p,r2) (p,n) (p,n) (p,n) t8 p gp2

PART
p

t9

PARTN
PD

(p,n+1)

gp1

PARTN

1(trj,0)+ 1(T,0)+ 1(t1,0)+ 1(t2,0)

(p,n+1) (p,n)

p PART

Figura 7: EG-CPN para o objeto CMERA 5.3.2 Comportamento para o Objeto CMERA

O objeto CMERA modela a deciso a ser tomada, dependendo do tipo reconhecido pelo objeto PATTERN, que no apresentado neste trabalho. O objeto PATTERN identica a pea pr-processada e invoca o objeto CMERA com o mtodo idp, passando como argumento o tipo de pea que foi identicado. O objeto CMERA, baseado no tipo de pea, decide a rota para o objeto. A EG-CPN para este objeto apresentada na Figura 7. Dois mtodos so denidos para este objeto: o mtodo idp, que recebe o tipo da pea como argumento de entrada, e de acordo com o tipo, dispara a transio T6 ou T7. Se a pea for do tipo1 ou do tipo2 a transio T7 dispara e o objeto EQUIPMENT invocado com o mtodo ma para alocar os recursos necessrios ao processamento nal da pea. Se a pea for do tipo rejeitado ou no-reconhecida, a transio T6 dispara e o objeto ROBOT invocado com o mtodo mm (move pea) para movimentar a pea da esteira para os depsitos de peas rejeitadas ou no-identicadas. O disparo das transies T8 e T9 incrementam a quantidade de peas produzidas no lugar PD. O mtodo rp prov os meios pelos quais o nmero total de peas produzidas por tipo, peas no-identicadas ou rejeitadas possam ser acessados pelo objeto TIMINGCELLDB. Quando o mtodo rp invocado, uma cha depositada no lugar rp, a transio tread dispara removendo uma cha do lugar PD para o tipo p denido, e reinicializa o valor armazenado para o tipo com o valor 0. 5.3.3 Comportamento para o Objeto de Banco de Dados CELLDB

Na Figura 8 mostra-se o objeto de banco de dados CELLDB. O atributo denido pelo lugar DB e seu tipo associado. Este lugar armazena os dados obtidos dos objetos de controle PART e CAMERA, pelo objeto TIMINGCELLDB. Este objeto temporiza periodicamente a atualizao do BDTR. Inicialmente o atributo DB possui uma marcao inicial denindo uma cha para cada tipo de sub-produto (pea pr-processada) e produto (pea nalizada), ou seja, st1 e st2 para os sub-produtos do tipo1 ou tipo2, respectivamente, e t1 e t2 para produtos do tipo1 ou tipo2, respectivamente. Alm disso, so disponibilizadas chas para os itens rejeitados, trj, no identicados e T. Cada vez que o mtodo at invocado, as quantidades lidas pelo objeto TIMINGCELLDB so adicionadas aos valores prvios no campo correspondente para a

CELLDB

MT = {rp(:PARTS):DBO;at(:PARTS):} AT=(DB(:DBO) FC(rp(pr),at(pa))= ((now-DB.ts > DB.avi) and (|DB.v-pa.v| <= pr.lmir-(pr.i+pa.i)) -> pr.i=pri+pa.i+|DB.v-pa.v| R={(now-DB.ts <= DB.avi),DB.i<=2}
PARTS
at nts+1

PARTS
rp pr (p,o,avi,0) rdb @1

nts

rtc

TIME

now 1e

pa

DBO
(p,n,avi,ts) (p,n,avi,ts) 1(trj,0,0,0) + 1(T,0,0,0) + 1(t1,0,0,0) + 1(t2,0,0,0) + 1(st1,0,0,0)+ 1(st2,0,0,0) DB

nts (p,n+m,avi,nts) atdb 1e

rp

(p,n,avi,ts)

DBO

Figura 8: EG-CPN para o objeto CELLDB cha apropriada armazenada no lugar DB. Observe a soma das variveis n e m, no arco direcionado da transio atdb para o lugar DB. Quando o objeto CELLDB invocado com o mtodo rp, uma cha depositada no lugar rp. Quando a transio rdb ocorrer, uma cha para o tipo denido para o lugar rp removida do lugar DB, e chas com os valores (p,n,avi,ts,i) e (p,0,avi,0,i) so depositadas nos lugares rp e DB, respectivamente. Observe que a transio rtc representa o relgio local do objeto, de tal forma que o lugar now disponibiliza a data atual para o objeto. Cada vez que ela ocorre, a data incrementada de uma unidade de tempo. Para este objeto dene-se ainda a funo de compatibilidade como:

FC rppr; atpa = now , DB:ts DB:avi and jDB:v , pa:vj  pr:lmir , pr:i + pa:i  pr:i = pr:i + pa:i + jDB:v , pa:vj
Esta funo expressa uma negociao de consistncia lgica por consistncia temporal quando o mtodo rp (ler) est sendo executado e o mtodo at (atualiza) invocado. Se a consistncia temporal do item no banco de dados (lugar DB) foi violada, importante permitir que o mtodo at recupere a consistncia temporal do item. No entanto estes dois mtodos s podem ser executados concorrentemente se o valor que est sendo atualizado em DB pelo mtodo at (pa.v) prximo do valor atual em DB (DB.v). Esta determinao baseada no limite mximo de impreciso permitido para o argumento de retorno pr do mtodo rp (pr.lmir), na impreciso acumulada (pr.i), e na quantidade de impreciso que o mtodo at ir escrever em DB atravs de pa (pa.i). Ela tambm calcula a impreciso resultante da execuo concorrente dos mtodos. Neste caso, o argumento de retorno pr do mtodo rp pode ter um aumento na impreciso igual a diferena entre o valor de DB antes da atualizao (DB.v) e o valor de DB depois da atualizao (pa.v), mais a quantidade de impreciso que escrita em DB atravs de at (pa.i).

6 Concluso
Neste trabalho introduzimos um mtodo para a modelagem de STR e BDTR baseado em uma notao de rede de Petri baseada em objetos, denominado EG-CPN. Esta notao resultado do enriquecimento da notao G-CPN, com o objetivo de disponibilizar construes de natureza lingustica de modo a promover a descrio formal mais eciente de modelos integrados do STR e do BDTR. O modelo suporta

o tratamento de consistncia lgica e temporal, e controle de concorrncia semntico, com base em restries e funes de compatibilidade denidas pelo projetista e declaradas na interface dos modelos para os objetos. Tais funes podem ser vistas como restries de sincronizao para a execuo dos mtodos de um dado objeto. Para ilustrar a aplicao do mtodo, apresentamos a modelagem dos objetos de controle e de banco de dados para uma clula exvel de manufatura. O processo de validao possibilitou vericar os conceitos introduzidos neste trabalho bem como o modelo obtido para o problema particular abordado.

Referncias
[1] A. Bestravos, K.-J. Lin, and Son. S.H. Real-Time Database Systems: Issues and Applications. Kluwer Academic Publishers, 1997. [2] M. Blaha and W. Premerlani. Object-Oriented Modeling and Design for Database Applications. Prentice Hall, 1998. [3] L.C. DiPippo. Semantic Real-Time Object-based Concurrency Control. PhD thesis, Department of Computer Science and Statistics, University of Rhode Island, 1995. [4] K. Gordon. "diswg":database management systems requirements. Technical report, Alexandria, Virginia: NGCR SPAWAR 331 2B2, 1993. [5] D.D.S. Guerrero, J.C.A. de Figueiredo, and A. Perkusich. Object-based high-level petri nets as a formal approach to distributed information systems. In Proc. of IEEE Int. Conf. on Systems Man and Cybernetics, pages 33833388, Orlando, USA, October 1997. [6] D.D.S. Guerrero, A. Perkusich, and J.C.A. de Figueiredo. Modeling a cooperative environment based on an object-based modular petri net. In Proc. of The 9th International Conference on Software Engineering and Knowledge Engineering, pages 240247, Madrid, Spain, June 1997. [7] K. Jensen. Coloured Petri Nets: Basic Concepts, Analysis, Methods and Practical Use. EACTS Monographs on Theoretical Computer Science. Springer-Verlag, 1992. [8] C. Krishna and K. G. Shin. Real-Time Systems. MacGraw Hill Series in Computer Science, 1996. [9] S.B. Navathe and R.A. Elmasri. Fundamentals of Database Systems, 2nd Edition. AddisonWesley Pub. Co., New York, 1994. [10] G. Ozsoyoglu and R.T. Snodgrass. Temporal and real-time databases: A survey. IEEE Transactions on Data and Knowledge Engineering, 7(4):4756, August 1995. [11] J. Peckham, V.F. Wolfe, J.J. Prichard, and L.C. DiPippo. Design of a real-time object-oriented database system. Technical report, University of Rhode Island, TR94-231, 1996. [12] A. Perkusich, M.L.B. Perkusich, and S.K Chang. Object oriented design, modular analysis, and faulttolerance of real-time control software systems. International Journal of Software Engineering and Knowledge Engineering, 6(3):447476, 1996. [13] M.L.B. Perkusich, M.F.Q.V. Turnell, and A. Perkusich. Object-oriented real-time database design based on petri nets. In Proc. of IEEE Int. Conf. on Systems Man and Cybernetics, pages 202207, San Diego, USA, October 1998. [14] K. Ramamrithman. Real-time databases. International Journal of Distributed and Parallel Databases, 1993. [15] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-oriented modeling and design. Englewood Cliffs, N.J.: Prentice Hall, 1991. [16] University of Aarhus, Aarhus, Denmark. Design CPN - Overview of CPN ML Syntax, version 3.0, 1996.