Post on 06-Apr-2018
8/2/2019 Modelagem de Banco de Dados Em Tempo-Real
1/15
8/2/2019 Modelagem de Banco de Dados Em Tempo-Real
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-
8/2/2019 Modelagem de Banco de Dados Em Tempo-Real
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.
8/2/2019 Modelagem de Banco de Dados Em Tempo-Real
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
8/2/2019 Modelagem de Banco de Dados Em Tempo-Real
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
8/2/2019 Modelagem de Banco de Dados Em Tempo-Real
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
8/2/2019 Modelagem de Banco de Dados Em Tempo-Real
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/2/2019 Modelagem de Banco de Dados Em Tempo-Real
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.
8/2/2019 Modelagem de Banco de Dados Em Tempo-Real
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].
8/2/2019 Modelagem de Banco de Dados Em Tempo-Real
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
8/2/2019 Modelagem de Banco de Dados Em Tempo-Real
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.
8/2/2019 Modelagem de Banco de Dados Em Tempo-Real
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.
8/2/2019 Modelagem de Banco de Dados Em Tempo-Real
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
8/2/2019 Modelagem de Banco de Dados Em Tempo-Real
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
8/2/2019 Modelagem de Banco de Dados Em Tempo-Real
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.