modelagem de banco de dados em tempo-real

8/2/2019 Modelagem de Banco de Dados Em Tempo-Real

1/15


2/15

Por outro lado, desejvel que o projeto de um STR se desenvolva de forma integrada ao seu BDTR,

com base em um mtodo unificado, 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 deredes de Petri baseadas em objetos como definidas em [6, 13], de modo a promover a descrio eficiente

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 exemplificar o mtodo, apresentamos a modelagem de uma clula de um sistema flexvel 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 contro-

ladores 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 exemplificao 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 definir restries temporais s transaes. Deve-se observar que h casos em que as restries tem-

porais 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 da-

dos for sacrificada. Em outras, para manter a consistncia lgica dos dados, a consistncia temporal deve

ser sacrificada. Uma vez que estas situaes so bastante freqentes em SGBD-TR, os resultados produ-

zidos 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 redefinidas para SGBD-TR

como ser discutido na Seo 2.1. Por exemplo, em um sistema de controle de trfego areo, a posioaproximada de um avio no tempo certo pode ser mais apropriada que o valor exato tarde demais. Geral-

mente 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 inconsistn-

cias entre estes valores. Portanto necessrio um mecanismo para verificar a consistncia temporal do

dado face extenso do atraso na sua atualizao [14]. Um tal mecanismo, pode ser baseado na defi-


3/15

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

respondente no banco de dados. Ento, a idade de um tem de dado deve estar dentro do intervalo

de validade absoluta especificado. 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 especificado. 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 classificadas 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. Astransaes de leitura, lem dados do banco de dados e tambm podem ser peridicas ou aperidicas.

Uma transao em SGBD-TR tambm pode ser classificada com base no efeito de no cumprir sua

restrio temporal, em estrita, suave ou firme1.

Estrita: uma transao estrita quando qualquer resultado produzido aps seu deadline intil para o

sistema. Isso significa 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 firme quando a perda do deadline no gera nenhum efeito ou valor para osistema. Geralmente estas transaes so recomeadas quando perdem seu deadline.

As restries de tempo impostas s transaes podem se originar de dois tipos de requisitos: requisi-

tos 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 verifique atemperatura do ambiente. O segundo geralmente, assume a forma de deadlines impostos s transaesaperidicas, por exemplo: se temperatura > 1000 graus, adicione lquido refrigerador ao reatordentro de 5 segundos.

2.1 Propriedades ACID em BDTR

As transaes de um SGBD so estruturadas para cumprir as propriedades ACID [9]. Estas proprieda-

des possibilitam a avaliao da consistncia lgica dos dados e transaes. No entanto, no conside-

ram os requisitos de consistncia temporal existentes nos BDTR. Portanto, para suportar aplicaes em

tempo-real, as propriedades ACID foram redefinidas, passando a permitir melhor suporte a consistncia

temporal enquanto mantm suporte a consistncia lgica. Estas redefinies utilizam informao semn-

tica para determinar em que grau as propriedades ACID podem ser relaxadas [3]. A conseqncia do

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


4/15

relaxamento destas propriedades a introduo de impreciso no banco de dados. As redefinies das

propriedades ACID incluem atomicidade, consistncia, isolamento, e durabilidade.

A atomicidade garante que uma transao totalmente executada ou nenhum passo dela executa-

do. 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 tran-

sao 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 pararde 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 introdu-

zir 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 outratransao 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 perma-

nentes. Em BDTR, alguns dados tem validade temporal e no precisam ser gravados. Por outro lado,

o banco de dados deve refletir 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 jsero 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 definir quais e em que condies as transaes podem ser executadas concor-

rentemente. Ento, importante que o mtodo de modelagem utilizado disponibilize mecanismos para

descrever e verificar 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 especi-

ficao e modelagem de sistemas distribudos de software. Devido s limitaes de espao, neste artigo


5/15

no introduziremos a formalizao dos modelos G-CPN e EG-CPN, o leitor interessado pode consul-

tar [6]. As extenses incorporadas ao modelo objetivam enriquecer a notao de G-CPN, de modo que

a descrio de especificaes no domnio de aplicaes envolvendo BDTR possam ser mais compac-

tas, permitindo declarar restries lgicas e temporais e compatibilidade entre execuo concorrente de

transaes.

No que segue, um objeto uma quntupla h N ; A T ; M T ; R ; F C i , onde:

1.N

um identificador nico para um objeto

2. A T = A Ta

A T

t

um conjunto de atributos, onde A Ta

e A Tt

so conjuntos de atributos atem-

porais e temporais, respectivamente.8 a

a

2 A T

a

; a

a

= h N ; V i

, onde:N

o nome do atributo eV

o valor do atributo. 8 at

2 A T

t

; a

t

= h N ; V ; T S ; A V I ; I i , onde: T S o t i m e s t a m p ; A V I o

intervalo de validade absoluta para o atributo, e; I a impreciso acumulada para o atributo.

3. M T um conjunto de mtodos, e 8 m ti

2 M T , m ti

definido pela dupla h A r g e ; A r g r i ,

onde A r g e e A r g r so os conjuntos de argumentos de entrada e de retorno, respectivamente.

8 a r g e

i

2 A r g e

,a r g e

i

= h N ; V ; T S ; A V I ; I ; L M I

e

i

, ondeN

,V

,T

,A V I

, eI

so como de-

finidos para A Tt

, e L M Ie

especifica o limite mximo de impreciso que pode ser passado pelo

mtodo.8 a r g r

i

2 A r g r

,a r g r

i

= h N ; V ; T S ; A V I ; I ; L M I

r

i

, ondeN

,V

,T

,A V I

, eI

so

como definidos paraA T

t

, eL M I

r

especifica o limite mximo de impreciso permitido no valorretornado.

4. R um conjunto de restries lgicas e temporais que definem o estado correto de uma instncia

de um objeto. Uma restrio definida como um predicado que pode incluir os campos V , T S ,

A V I

eI

, 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

D B : 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,L M I

e

2 a r g e

i

eL M I

r

2 a r g r

i

. Isto permite maior

flexibilidade para o projetista definir seus limites de acordo com as necessidades da aplicao.

5. F C uma funo de compatibilidade que utiliza informao semntica sobre os objetos e o estadodo sistema para determinar quando dois mtodos de um objeto podem ser executados concorren-

temente, e definida porF C m

i

; m

j

=

(expresso booleana) I A

, ondem

i

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 absolutoA V I

do atributo, limite mximo de imprecisoL M I

e a impreciso acumulada

I

do atributo, entre outras.I A

definida 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 concor-

rentemente. 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

F C

pode ser utilizada para expressar uma negociao entre manter consistncia lgica ou tem-

poral 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 especificar

compatibilidade entre a execuo concorrente de mtodos, aF C

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


6/15

Funo decompatibilidade

Funo decompatibilidade

Retorno

Ativao

Terminao

Ambiente de Interao

Troca de Mensagens

Controle de Contexto

Invocao

AtributosMtodos

Restries

G-CPNnLugar superior

Lugar Inferior

AtributosMtodos

Restries

ISP

lugar de ativao

outroselementosdo mtodo

lugar determinao

Cliente Servidor

EG-CPNmEG-CPNn

Figura 1: Sistema EG-CPN e eventos na interao

no fique bloqueado definitivamente. Uma forma criar mtodos, que podem ser ativados periodicamen-

te, 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 acopla-

dos para modelagem/especificao formal e executvel de aplicaes envolvendo BDTR. Estruturalmen-te um sistema EG-CPN a integrao de um conjunto de mdulos EG-CPN e um ambiente de interao.

Cada mdulo EG-CPN define 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 en-

tre 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 com-

patibilidade. Caso ela seja avaliada como falsa, a invocao ser enfileirada para uma posterior tentativa,

quando algum mtodo que estiver sendo executado terminar. Caso seja avaliada como verdadeira ele efe-

tua 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 ambientedetecta a disponibilidade desses resultados (fichas em um lugar de terminao do mtodo) e os retoma

a fim 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 comoRestries 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 fichas de ativao do mtodo; e o segundo determina onde

sero colocadas as fichas com o resultado. A estrutura interna sintaticamente uma rede de Petri Colorida

(CPN) [7]. A semntica modificada devido a introduo de um lugar especial na IS, denominado ISP

(Instantiating Switching Place) que utilizado para representar invocaes de mtodos remotos. ISPs so


7/15

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 ficha depositada no ISP (lugar superior), uma invocao pode ocorrer, implicando no

desaparecimento da ficha; em seguida, dependendo do funcionamento do mtodo remoto, dever ocorrer

um retorno, e uma outra ficha 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 graficamente 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 fichas de invocao (lugar superior) e outro para fichas de

terminao (lugar inferior).

Um nico mdulo EG-CPN pode atender a qualquer nmero de pedidos de servios concorrentemen-

te. Isso possvel, porque ao ocorrer uma ativao, uma nova instncia do mdulo, criada automatica-

mente, 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 fiel 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

fichas relativas quela invocao na rede.

Os atributos em mdulos EG-CPN so associados a lugares na estrutura interna. Como atributos soconsiderados parte do estado global do objeto, o seu estado (marcao) nico e portanto, compartilha-

do por todos os contextos do mesmo mdulo EG-CPN. Consequentemente, os diversos contextos ativos

concorrem pela utilizao dos atributos (fichas nos lugares que os representam). Esta forma de definir

o modelo EG-CPN permite que durante a modelagem, um mdulo EG-CPN represente um objeto pro-

priamente 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 definio 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, Mo-

delo 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 define as operaes

que os objetos executam. O Modelo Dinmico descreve as interaes temporais entre os objetos e suasrespostas 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:


8/15

1. Identificao dos objetos;

2. Identificao dos relacionamentos entre objetos;

3. Adio dos atributos dos objetos;

4. Uso de generalizao para observar similaridades e diferenas;

5. Identificao das operaes;

6. Identificao das operaes compatveis, ou seja, que podem ser executadas concorrentemente ;

7. Identificao das restries lgicas e temporais;

8. Refinamento 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 definir 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, definidas por meio defunes 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 EG-

CPN 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 especificao.

4.2.1 Obtendo o Modelo de Processos

No modelo de processos os objetos so descritos atravs de mdulos EG-CPN. Ele definido a partir

do modelo de objetos. Ento, para cada objeto (contendo operaes), identificado 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. Identificao dos objetos (EG-CPNs) corresponde aos objetos do modelo de objeto;

2. Identificao das funcionalidades de cada objeto corresponde s funcionalidades das operaes

dos objetos;

3. Definio 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. Definio da estrutura interna de cada objeto (I S

) modelagem das operaes (mtodos) do

objeto.

A aplicao dos passos ilustrada na seo seguinte atravs de um exemplo.


9/15

esteira

C

P1

P2

R1Robo

tipo 2

tipo 1

Robo

NRM1

M2

R2

esteira

rejeitadas

reconhecidaspeas no

RE

peas camera

peasproduzidas

PP E2 E1

MP1

MP2

Figura 2: Uma clula de manufatura

5 Exemplificando o Mtodo

Para exemplificar 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

final da matria-prima. As esteiras E1 e E2 transportam as peas dentro da clula. O rob R1 transportaa 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 classificadas 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: Identificao dos Objetos

Os objetos identificados so: equipamento, rob, pea, cmera e CELLDB. Neste artigo assume-seque as esteiras e depsitos tm capacidade suficiente para suportar o fluxo de materiais e, portanto no

sero considerados na concepo do modelo. Para exemplificar 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].


10/15

QUANTIDADE: inteiroTIPO: cadeia de caracteresNOME: cadeia de caracteresESTADO: inteiro

MA( ) Aloca mquinaDA( ) Desaloca mquina

TIPO com P1,P2,M1,M2

IDP( ) Identifica peaRP( ) Ler pea

TIPO: cadeia de caracteresQUANTIDADE: inteiro

#PLANODEPROCESSO: inteiroVERSO: cadeia de caracteresDESCRIO: cadeia de caracteresDATA: data

TIPO com SP1,SP2

MP( ) Processa peaRP( ) Ler quantidade de peas

QUANTIDADE: inteiro

TIPO: cadeia de caracteres

*AVI*TIMESTAMP*IMPRECISO

TIPO com R1,R2

DR( ) Desaloca rob

MM( ) Move rob

RP( ) Ler quantidade de peas

DB: TIPO*QUANTIDADE

FC(RP(pr),AT(pa))=((NOW-DB.ts >DB.avi) and

->pr.i=pr.i+pa.i+|DB.v-pa.v|

TIPO com T1,T2,Trj,TniNOW-DB.ts


11/15

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

Camera#1

Hierarchy#10

Declarations#6

Equipment#3

Parts#5

Robot#4

CellDB#7Pattern#8

Environment#2

Recovery#9 TimingCellDB#10

Database ObjectsControl Objects

Figura 5: Hierarquia para o modelo

Passo 4: Estrutura Interna

Finalmente, no quarto passo, define-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 EG-

CPNs so apresentadas na Figura 4. Na Figura 5 apresentamos a hierarquia para o modelo. As linhas

cheias nesta figura indicam as relaes de conhecimento entre os objetos, ou configurao. Observe que

o objeto TIMINGCELLDB, no apresentado neste artigo, temporiza a leitura do estado da clula, obtendoo 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. Noteque, o TIMINGCELLDB realiza a interface entre os objetos de banco de dados e os de controle. Observeainda que o objeto ENVIRONMENT modela o comportamento do ambiente de interao, promovendoos 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. Pelomesmo motivo, nos modelos para os objetos apresentados neste artigo, os isps so representados por

dois lugares, um superior, de onde o ambiente retira fichas referentes a invocaes e um inferior, onde

o ambiente deposita fichas de retorno. Os isps so representados por linhas tracejadas nas figuras 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 simplificar a apresentao. Ento, observando o modelo de objetos apresentado na Figura 3 verifica-se

que alguns componentes foram acrescidos na hierarquia do modelo apresentado na Figura 5.


12/15

SPART

rp

[tp = p] t1

PART

mpPART1t1 + 1t2

pr

PART_ROBOT

PART

EQUIPMENT..ma

t2SPARTN1(st1,0) +

1(st2,0)

SPD

PART

gp2

t3 @timeout

PART

PART

t4

RECOVERY.mf

t5

SPARTN

gprspd

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

(p,r1)

p

p

tp

p

p

p

p

p

p

(sp,n)

(sp,0)

(sp,n)

p

case sp = st1

andalso p = t1

then 1(st1,n+1)

else 1(st2,n+1)

sp

(sp,n)

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 mtodosso definidos para este objeto: mtodo mp e mtodo rp. Quando o objeto PART invocado para pr-processar uma pea, com o mtodo mp, uma ficha depositada no lugar mp. De modo a iniciar opr-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 (alocamquina), 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 especficoindicado na invocao. Quando o resultado do objeto EQUIPMENT retornado, a transio t2 podeocorrer. No caso de ocorrer, a ficha no lugar SPD atualizada e o objeto PART termina sua invocao.

Observe que quando a transio t2 ocorre, uma ficha removida do lugar SPD que mantm a infor-mao relacionada com a pea pr-processada, a varivel n incrementada de uma unidade, e a fichacom este novo valor depositada no lugar SPD. Uma ficha no lugar gp2 indica o fim da execuo domtodo 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 RECOVERYno apresentado neste trabalho.

O mtodo rp realiza a leitura do nmero de peas pr-processadas. Quando ele invocado, uma ficha depositada no lugar rp, indicando o tipo a ser lido. Quando a transio t5 ocorre, uma ficha com onmero de peas de um determinado tipo removida do lugar SPD e outra colocada para aquele tipocom o valor zero. O valor n e o tipo so retornados quando o lugar alvo gprspd alcanado.


13/15

PART

idp

[p=trj orelse

p=tni]t6

[p=t1 orelse

p=t2]t7

t8

PART

gp2

CAMERA MT = {idp(:PART):PART;rp(:PART):PARTN}AT = {PD(:PARTN)

MOVE_ROBOTPART_ROBOT

PART_ROBOT PART

Robot.mm Equipment.ma

t9

rp

gp1

PARTN

tread

PD

1(trj,0)+

1(T,0)+

1(t1,0)+

1(t2,0)

PARTN p

(p,n+1)

(p,n)

p p

(p,r2,st3) (p,r2)

(p,r2) p

p

p

(p,n)

(p,n+1)

(p,n)

(p,n)

(p,0)

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 PAT-TERN, que no apresentado neste trabalho. O objeto PATTERN identifica a pea pr-processada einvoca o objeto CMERA com o mtodo idp, passando como argumento o tipo de pea que foi identi-ficado. O objeto CMERA, baseado no tipo de pea, decide a rota para o objeto. A EG-CPN para esteobjeto apresentada na Figura 7. Dois mtodos so definidos para este objeto: o mtodo idp, que recebeo tipo da pea como argumento de entrada, e de acordo com o tipo, dispara a transio T6 ou T7. Se apea 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 final da pea. Se a pea for do tipo rejeitado ouno-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-identificadas. O disparo

das transies T8 e T9 incrementam a quantidade de peas produzidas no lugar PD. O mtodo rp provos meios pelos quais o nmero total de peas produzidas por tipo, peas no-identificadas ou rejeitadas

possam ser acessados pelo objeto TIMINGCELLDB. Quando o mtodo rp invocado, uma ficha depo-sitada no lugar rp, a transio tread dispara removendo uma ficha do lugar PD para o tipo p definido, ereinicializa o valor armazenado para o tipo com o valor 0.

5.3.3 Comportamento para o Objeto de Banco de DadosCELLDB

Na Figura 8 mostra-se o objeto de banco de dados CELLDB. O atributo definido pelo lugar DB e seu tipoassociado. Este lugar armazena os dados obtidos dos objetos de controle PART e CAMERA, pelo objetoTIMINGCELLDB. Este objeto temporiza periodicamente a atualizao do BDTR. Inicialmente o atributoDB possui uma marcao inicial definindo uma ficha para cada tipo de sub-produto (pea pr-processada)e produto (pea finalizada), 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 fichaspara os itens rejeitados, trj, no identificados e T. Cada vez que o mtodo at invocado, as quantidadeslidas pelo objeto TIMINGCELLDB so adicionadas aos valores prvios no campo correspondente para a


14/15

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

DBO

PARTS

rp

rdb

atdb

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.i=pri+pa.i+|DB.v-pa.v|

R={(now-DB.ts


15/15

o tratamento de consistncia lgica e temporal, e controle de concorrncia semntico, com base em res-

tries e funes de compatibilidade definidas 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 con-

trole e de banco de dados para uma clula flexvel de manufatura. O processo de validao possibilitou

verificar 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 Monogra-

phs 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 fault-

tolerance of real-time control software systems. International Journal of Software Engineering and Knowled-

ge 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.

modelagem de banco de dados em tempo-real

Documents