Modelagem de Bancos de Dados em Tempo-real

Modelagem de Banco de Dados em Tempo-real Maria L.B. Perkusich, Maria de F.Q.V. Turnell e Angelo Perkusich Departamento de Engenharia Elétrica Universidade Federal da Paraíba, 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 método para a modelagem de Banco de Dados em Tempo-real (BDTR) utilizando uma notação de redes de Petri baseadas em objetos denominada EG-CPN. Esta notação é enriquecida de modo a promover a descrição eficiente de modelos integrando BDTR e Sistemas em Tempo-real (STR). O método disponibiliza para o projetista construções que permitem, por exemplo, declarar restrições lógicas e temporais e restrições de execução concorrente de métodos no contexto de uma aplicação de BDTR. Além disso, apresentamos um exemplo da aplicação do método introduzido para a modelagem e validação dos objetos de controle e de banco de dados para uma célula flexível 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 efficient 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 flexible manufacturing system cell.

1 Introdução Nos últimos anos as pesquisas na área de Sistemas de Gerenciamento de Banco de Dados em Tempo-real (SGBD-TR) tem se intensificado [1, 8]. Estas pesquisas são motivadas pelo fato de que determinadas aplicações precisam tratar com grandes volumes de dados, além de dados e transações com restrições temporais. Um possível encaminhamento visando solucionar tal problema seria buscar a integração 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 integração destas tecnologias (conceitos, mecanismos, ferramentas) não é suficiente para se desenvolver um SGBD-TR. Questões como modelagem conceitual, controle de concorrência, escalonamento, recuperação, entre outras, estão sendo consideradas e pesquisadas [1, 8, 10]. Dada a complexidade das aplicações em tempo-real, muitos pesquisadores acreditam que o paradigma da orientação a objetos é o mais apropriado para tratar com tais aplicações [1]. Também faz-se necessário o emprego de ferramentas eficazes com base formal para modelar tais aplicações. No contexto de sistemas de banco de dados, principalmente no caso de grandes sistemas, a integração é uma capacidade crítica e vital. Dados de diferentes aplicações devem ser integrados com o objetivo de possibilitar a coordenação de aplicações individuais em consonância com os objetivos corporativos.

Por outro lado, é desejável que o projeto de um STR se desenvolva de forma integrada ao seu BDTR, com base em um método unificado, de forma a dispensar o desenvolvimento de interfaces necessárias à adequação e integração dos diferentes projetos desenvolvidos com base em ferramentas diferentes. Desta forma, para satisfazer o requisito de integração no contexto de aplicações com grandes volumes de dados e restrições temporais, e a necessidade da utilização de ferramentas formais no desenvolvimento de sistemas complexos, introduzimos neste trabalho um método para a modelagem de STR e BDTR contemplando o requisito de integração e a necessidade de embasamento formal. A base formal deste trabalho é uma extensão de redes de Petri, incluindo principalmente o enriquecimento da notação de redes de Petri baseadas em objetos como definidas em [6, 13], de modo a promover a descrição eficiente de modelos integrados do BDTR e do STR. Além do modelo formal, o método é baseado também no modelo OMT (Object Modelling Technique) [15, 2], e no modelo RTSORAC (Real-Time Semantic Objects Relationships and Constraints) [3, 11]. Para exemplificar o método, apresentamos a modelagem de uma célula de um sistema flexível de manufatura. Esta escolha foi principalmente motivada pelo fato de que as soluções de controle para tais sistemas são baseadas em estruturas hierárquicas multi-nível, onde no nível mais baixo estão os controladores de chão de fábrica, e no nível mais alto estão os responsáveis por tomar decisões estratégicas e de planejamento. Em tais sistemas, a necessidade de integração entre os diferentes níveis de abstração torna-se vital, e a disponibilização de dados, tanto de planejamento de engenharia de produção, quanto de controle de processo, é condição necessária para satisfazer os requisitos de produção. Este artigo está organizado da seguinte forma: na Seção 2 são introduzidos os conceitos básicos de SGBD-TR. Na Seção 3 são introduzidos os conceitos básicos de um modelo estendido de redes de Petri baseado em objetos, denominado EG-CPN, que é utilizado como base formal no desenvolvimento do método apresentado neste artigo. O método para modelagem de STR e BDTR e sua exemplificação são apresentados nas Seções 4 e 5, respectivamente. Finalmente, na Seção 6 são apresentadas as conclusões deste trabalho.

2 Banco de Dados em Tempo-real Um SGBD-TR pode ser visto como a integração de um SGBD convencional com um STR [1]. Assim, um SGBD-TR além de processar transações e garantir a integridade dos dados, deve também operar em tempo-real, para satisfazer as restrições temporais impostas aos dados e transações. Destacam-se como características principais de um SGBD-TR a noção de dados temporalmente consistentes, e a habilidade para definir restrições temporais às transações. Deve-se observar que há casos em que as restrições temporais impostas às transações precisam ser satisfeitas com o objetivo de manter a consistência temporal dos dados. Em algumas situações estas restrições só podem ser satisfeitas se a consistência lógica dos dados for sacrificada. Em outras, para manter a consistência lógica dos dados, a consistência temporal deve ser sacrificada. Uma vez que estas situações são bastante freqüentes em SGBD-TR, os resultados produzidos por uma transação não precisam ser totalmente corretos, ou seja, podem ser imprecisos. Portanto as propriedades ACID [9] não precisam ser cumpridas totalmente, e foram redefinidas para SGBD-TR como será discutido na Seção 2.1. Por exemplo, em um sistema de controle de tráfego aéreo, a posição aproximada de um avião no tempo certo pode ser mais apropriada que o valor exato tarde demais. Geralmente a imprecisão permitida deve ser limitada. No exemplo anterior, a imprecisão na posição do avião deve ser de apenas alguns metros, considerada a posição verdadeira. Idealmente os dados gravados em um BDTR devem ser idênticos em valor ao seu correspondente no ambiente. No entanto, geralmente há um atraso de atualização no BDTR, o que pode levar a inconsistências entre estes valores. Portanto é necessário um mecanismo para verificar a consistência temporal do dado face à extensão do atraso na sua atualização [14]. Um tal mecanismo, pode ser baseado na defi-

nição de um rótulo 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 é válido. A consistência temporal dos dados pode ser medida de duas maneiras [14]: Consistência absoluta entre o valor real de um ítem de dado no ambiente de aplicação e o valor correspondente no banco de dados. Então, 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. Consistência relativa entre os itens de dados que são usados para calcular outros dados. Os itens de dados que serão usados na computação de outros dados devem ser gravados dentro de um intervalo de tempo relativo especificado. Esta medida surge da necessidade de assegurar que dados que serão usados na computação de outros dados representem aproximadamente o mesmo instante de tempo do ambiente. De modo geral as transações em um SGBD-TR podem ser classificadas como: transações de escrita (ou sensores), transações de atualização e transações de leitura [14]. As transações de escrita, tipicamente periódicas, obtém o estado do ambiente e escrevem os dados no banco de dados. As transações de atualização tanto podem ler quanto escrever no banco de dados periodicamente ou aperiodicamente. As transações de leitura, lêem dados do banco de dados e também podem ser periódicas ou aperiódicas. Uma transação em SGBD-TR também pode ser classificada com base no efeito de não cumprir sua restrição temporal, em estrita, suave ou firme1 . Estrita: uma transação é estrita quando qualquer resultado produzido após seu deadline é inútil para o sistema. Isso significa que qualquer transação estrita deve ser abortada quando não puder cumprir seu deadline, independentemente de sua conseqüência. Suave: uma transação é suave quando o resultado produzido após seu deadline sempre tem algum valor, que vai perdendo sua utilidade a medida que se distancia de seu deadline. Firme: uma transação é firme quando a perda do deadline não gera nenhum efeito ou valor para o sistema. Geralmente estas transações são recomeçadas quando perdem seu deadline. As restrições de tempo impostas às transações podem se originar de dois tipos de requisitos: requisitos de consistência temporal dos dados e requisitos impostos pelo sistema em relação ao tempo [14]. O primeiro assume a forma de requisito de periodicidade, por exemplo: a cada 20 segundos verifique a temperatura do ambiente. O segundo geralmente, assume a forma de deadlines impostos às transações aperiódicas, por exemplo: se temperatura > 1000 graus, adicione líquido refrigerador ao reator dentro de 5 segundos.

2.1 Propriedades ACID em BDTR As transações de um SGBD são estruturadas para cumprir as propriedades ACID [9]. Estas propriedades possibilitam a avaliação da consistência lógica dos dados e transações. No entanto, não consideram os requisitos de consistência temporal existentes nos BDTR. Portanto, para suportar aplicações em tempo-real, as propriedades ACID foram redefinidas, passando a permitir melhor suporte a consistência temporal enquanto mantém suporte a consistência lógica. Estas redefinições utilizam informação semântica para determinar em que grau as propriedades ACID podem ser relaxadas [3]. A conseqüência do 1

Tradução para os termos do inglês hard, soft e firm, respectivamente.

relaxamento destas propriedades é a introdução de imprecisão no banco de dados. As redefinições das propriedades ACID incluem atomicidade, consistência, isolamento, e durabilidade. A atomicidade garante que uma transação é totalmente executada ou nenhum passo dela é executado. Para transações em tempo-real, a execução atômica é seletivamente aplicada às subtransações que necessitam tratar com dados totalmente consistentes, ao invés de aplica-la à transação toda. Como um BDTR pode ser impreciso, algumas vezes não é necessário desfazer toda a transação. Assim uma transação pode terminar com um estado inconsistente, desde que a imprecisão seja limitada. Por exemplo, considere uma transação que está atualizando dados sobre o ambiente, perde seu deadline e deve parar de executar. Geralmente é desnecessário desfazer suas atualizações, uma vez que os valores anteriores também estão desatualizados. Além 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 consistência garante que a execução de uma transação sempre transforma o estado consistente de um banco de dados em um outro estado consistente. As transações em SGBD-TR devem suportar uma negociação entre manter consistência lógica ou temporal. Esta negociação pode introduzir imprecisão no banco de dados. Algumas aplicações em tempo-real podem suportar inconsistências no banco de dados. Por exemplo, dados que mudam freqüentemente não precisam ser atualizados a cada mudança, o que consumiria tempo de computação e recursos. Geralmente nessas aplicações as atualizações são realizadas apenas quando dados atualizados são necessários. A propriedade de isolamento garante que as ações de uma transação não são visíveis a nenhuma outra transação até que ela seja comprometida. Isto implica que não existem interdependências na execução das transações. Em SGBD-TR, as transações podem precisar se comunicar e sincronizar com outras transações de forma a executar funções de controle, portanto suas ações podem ser vistas por outras transações mesmo antes do comprometimento. Além disso, algumas transações podem ter restrições temporais e podem usar dados que precisam ser temporalmente consistentes. Assim, os dados gerados por uma transação não comprometida podem ser vistos por outras transações para evitar que tornem-se desatualizados, ou que não satisfaçam suas restrições temporais. A propriedade de durabilidade garante que as ações de uma transação no banco de dados são permanentes. Em BDTR, alguns dados tem validade temporal e não precisam ser gravados. Por outro lado, o banco de dados deve refletir o estado do ambiente, portanto é fácil recria-lo a partir da leitura dos sensores, ao invés de recria-lo no tempo em que ocorreu uma falha, pois esses dados provavelmente já serão inválidos.

2.2 Controle de Concorrência Semântico em SGBD-TR Alguns pesquisadores sugerem que o mecanismo de controle de concorrência de um SGBD-TR seja semântico [1, 3]. Isto é, informação semântica sobre o sistema pode ser utilizada para determinar quais as transações que podem ser executadas concorrentemente. Este mecanismo permite maior concorrência em BDTR, embora uma sobrecarga seja imposta ao sistema e ao projetista. O projetista deve conhecer bem cada transação para definir quais e em que condições as transações podem ser executadas concorrentemente. Então, é importante que o método de modelagem utilizado disponibilize mecanismos para descrever e verificar o controle de concorrência.

3 Introdução aos Sistemas EG-CPN A base formal para o método que introduziremos é um modelo de redes de Petri baseado em objetos denominado EG-CPN (Extended Generalized Coloured Petri Nets), que por sua vez é uma extensão do modelo G-CPN [6, 5, 13]. G-CPN é uma estrutura de redes de Petri baseada em objetos para a especificação e modelagem de sistemas distribuídos de software. Devido às limitações de espaço, neste artigo

não introduziremos a formalização dos modelos G-CPN e EG-CPN, o leitor interessado pode consultar [6]. As extensões incorporadas ao modelo objetivam enriquecer a notação de G-CPN, de modo que a descrição de especificações no domínio de aplicações envolvendo BDTR possam ser mais compactas, permitindo declarar restrições lógicas e temporais e compatibilidade entre execução concorrente de transações. No que segue, um objeto é uma quíntupla hN; AT; MT; R; FC i, onde: 1. 2.

3.

N é um identificador único para um objeto AT = ATa [ ATt é um conjunto de atributos, onde ATa e ATt são 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 imprecisão acumulada para o atributo. MT é um conjunto de métodos, e 8mti 2 MT , mti é definido pela dupla hArge; Argri, onde Arge e Argr são os conjuntos de argumentos de entrada e de retorno, respectivamente. 8argei 2 Arge, argei = h(N; V; TS; AV I; I ); LMIe i, onde N , V , T , AV I , e I são como definidos para ATt , e LMIe especifica o limite máximo de imprecisão que pode ser passado pelo método. 8argri 2 Argr , argri = h(N; V; TS; AV I; I ); LMIr i, onde N , V , T , AV I , e I são como definidos para ATt , e LMIr especifica o limite máximo de imprecisão permitido no valor retornado.

4.

R é um conjunto de restrições lógicas e temporais que definem o estado correto de uma instância de um objeto. Uma restrição é definida como um predicado que pode incluir os campos V , TS , AV I e I , de um atributo. Através destes predicados declaram-se as restrições lógicas e temporais, bem como os limites de imprecisão para os atributos. Por exemplo, na Figura 3, o predicado DB:i  2, indica que o limite máximo de imprecisão permitido para o atributo DB é 2. Observe que o limite máximo de imprecisão de um atributo pode ser declarado no conjunto de restrições do objeto e nos argumentos dos métodos, LMIe 2 argei e LMIr 2 argri . Isto permite maior flexibilidade para o projetista definir seus limites de acordo com as necessidades da aplicação.

5.

FC é uma função de compatibilidade que utiliza informação semântica sobre os objetos e o estado do sistema para determinar quando dois métodos de um objeto podem ser executados concorrentemente, e é definida por FC (mi ; mj ) =(expressão booleana)) IA, onde mi é o método que está executando, mj é o método que foi invocado e (expressão booleana) pode conter predicados envolvendo várias características do objeto ou do sistema, tais como: tempo atual e o intervalo de validade absoluto AV I do atributo, limite máximo de imprecisão LMI e a imprecisão acumulada I do atributo, entre outras. IA é definida por uma expressão que calcula a imprecisão acumulada nos atributos e nos argumentos dos métodos.

A expressão booleana pode ser avaliada para determinar se os dois métodos podem executar concorrentemente. Se ela for avaliada como verdadeira então os métodos podem executar concorrentemente e a imprecisão é calculada, caso contrário, o método invocado não pode ser executado. A FC pode ser utilizada para expressar uma negociação entre manter consistência lógica ou temporal de acordo com a semântica da aplicação. Ela permite a execução concorrente de métodos que podem introduzir imprecisão nos atributos e nos argumentos do método. Por isso, além de especificar compatibilidade entre a execução concorrente de métodos, a FC também expressa informação sobre a quantidade de imprecisão que pode ser introduzida pela execução concorrente dos métodos. Observe que um método invocado pode não ser executado se os dados que ele acessa são muito imprecisos para seus requisitos. Então deve existir alguma forma de recuperar a precisão dos dados de forma que o método

EG-CPNm

Métodos Atributos Restrições Função de compatibilidade

Invocação

Ativação

Controle de Contexto

EG-CPNn Métodos Atributos Restrições Função de compatibilidade lugar de ativação

Troca de Mensagens Lugar superior G-CPNn Lugar Inferior

ISP

Retorno

outros elementos do método

Terminação

lugar de terminação

Ambiente de Interação

Cliente

Servidor

Figura 1: Sistema EG-CPN e eventos na interação não fique bloqueado definitivamente. Uma forma é criar métodos, que podem ser ativados periodicamente, para escrever dados precisos no banco de dados. Assim os métodos bloqueados pela imprecisão dos dados podem ser executados.

3.1 Sistemas EG-CPN Sistemas EG-CPN são conjuntos de módulos EG-CPN, concorrentes, cooperantes e fracamente acoplados para modelagem/especificação formal e executável de aplicações envolvendo BDTR. Estruturalmente um sistema EG-CPN é a integração de um conjunto de módulos EG-CPN e um ambiente de interação. Cada módulo EG-CPN define um objeto instanciável do sistema. O ambiente de interação é o elemento responsável pela semântica de transferência de mensagens entre os módulos. O modelo de interação entre módulos EG-CPN é tipicamente cliente-servidor. Um módulo cliente requisita um serviço (execução de um método) em um módulo servidor. Quando a requisição é atendida pelo ambiente, diz-se que uma invocação ocorreu. A partir daí, o módulo cliente apenas espera que o ambiente faça efetivamente a ativação do serviço remoto, e passa a esperar a chegada da resposta. O ambiente avalia a função de compatibilidade. Caso ela seja avaliada como falsa, a invocação será enfileirada para uma posterior tentativa, quando algum método que estiver sendo executado terminar. Caso seja avaliada como verdadeira ele efetua uma ativação do método invocado no módulo servidor através da passagem dos dados necessários ao método. O módulo servidor, agora ativo, atende ao pedido. Quando for obtido um resultado, o ambiente detecta a disponibilidade desses resultados (fichas em um lugar de terminação do método) e os retoma a fim de retransmiti-los ao módulo cliente (terminação). Após a ocorrência da terminação no módulo servidor, o ambiente detecta o módulo cliente correspondente e devolve corretamente os dados, forçando a ocorrência do último evento associado à interação, denominado retorno.

3.2 Módulo EG-CPN Um módulo EG-CPN é estruturalmente representado por duas subestruturas: a primeira representa a interface do módulo e é denominada GSP (Generic Switching Place); a segunda é a estrutura interna do módulo - IS (Internal Structure). A interface determina a visão do módulo para o resto do sistema. Nela estão declarados os atributos, métodos encapsulados, restrições lógicas e temporais (referidas como Restrições na Figura 1), e as funções de compatibilidade. Os atributos representam os dados sobre os quais o módulo atua. Os métodos representam os serviços oferecidos pelo módulo. Para cada método declarado na interface existem dois lugares diferenciados na IS: lugar de ativação e lugar de terminação. O primeiro determina onde serão colocadas as fichas de ativação do método; e o segundo determina onde serão colocadas as fichas com o resultado. A estrutura interna é sintaticamente uma rede de Petri Colorida (CPN) [7]. A semântica é modificada devido a introdução de um lugar especial na IS, denominado ISP (Instantiating Switching Place) que é utilizado para representar invocações de métodos remotos. ISPs são

denotados por elipses e uma inscrição interna indicando qual método 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 invocação pode ocorrer, implicando no desaparecimento da ficha; em seguida, dependendo do funcionamento do método remoto, deverá ocorrer um retorno, e uma outra ficha com novos dados será depositada no ISP (lugar inferior), permitindo a habilitação das transições de saída, observe a Figura 1. Os lugares normais, bem como atributos e lugares que indicam ativação de métodos são representados graficamente por círculos. Os lugares de terminação são representados por círculos de borda dupla. Os demais elementos (transições e inscrições) seguem a mesma notação usada em G-CPN e CPN. Uma exceção deve ser notada: dois conjuntos de cores são associados a cada ISP, um para fichas de invocação (lugar superior) e outro para fichas de terminação (lugar inferior). Um único módulo EG-CPN pode atender a qualquer número de pedidos de serviços concorrentemente. Isso é possível, porque ao ocorrer uma ativação, uma nova instância do módulo, criada automaticamente, será encarregada de atender o pedido. Cada instância é tratada pelo que denomina-se de contexto. Um contexto pode ser visto como um novo objeto cuja estrutura funcional é uma cópia fiel da estrutura interna do módulo invocado. A única exceção é quanto aos lugares que representam atributos, que não serão copiados, mas compartilhados. O contexto é automaticamente destruído quando não restarem mais fichas relativas àquela invocação na rede. Os atributos em módulos EG-CPN são associados a lugares na estrutura interna. Como atributos são considerados parte do estado global do objeto, o seu estado (marcação) é único e portanto, compartilhado por todos os contextos do mesmo módulo EG-CPN. Consequentemente, os diversos contextos ativos concorrem pela utilização dos atributos (fichas nos lugares que os representam). Esta forma de definir o modelo EG-CPN permite que durante a modelagem, um módulo EG-CPN represente um objeto propriamente dito, com características intrinsecamente concorrentes, ou uma classe, que a cada invocação constrói objetos idênticos. Neste caso, os atributos declarados devem representar atributos de classe. Maiores detalhes relacionados à definição formal bem como à modelagem de transações e acesso aos dados podem ser encontrados em [6, 13].

4 Método para Modelagem de Banco de Dados em Tempo-real Nesta seção apresenta-se um método para modelagem de STR e BDTR. A aplicação do método resulta na obtenção de dois modelos: o modelo de objetos, usado para modelar as propriedades estáticas do sistema e, o modelo de processos, usado para modelar as propriedades dinâmicas do sistema.

4.1 Modelo de Objetos O modelo de objetos é baseado no modelo de objetos do método OMT e no modelo RTSORAC. O método OMT, usa três modelos complementares para modelar sistemas: Modelo de Objetos, Modelo Funcional e Modelo Dinâmico [2]. O Modelo de Objetos caracteriza as propriedades estáticas dos objetos, tais como, atributos, operações e restrições lógicas. O Modelo Funcional define as operações que os objetos executam. O Modelo Dinâmico descreve as interações temporais entre os objetos e suas respostas a eventos. Ele mostra sob quais condições as operações são executadas e por quanto tempo elas devem continuar executando. A notação do modelo de objetos OMT é simples e intuitiva, no entanto não permite a representação de algumas características de um BDTR. Portanto, baseado no modelo RTSORAC, que considera tais características, algumas extensões foram incorporadas ao modelo de objetos OMT, para permitir modelar um BDTR. A modelagem dos objetos começa com uma análise da declaração do problema e tem os seguintes passos:

1. Identificação dos objetos; 2. Identificação dos relacionamentos entre objetos; 3. Adição dos atributos dos objetos; 4. Uso de generalização para observar similaridades e diferenças; 5. Identificação das operações; 6. Identificação das operações compatíveis, ou seja, que podem ser executadas concorrentemente; 7. Identificação das restrições lógicas 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 método apresentado para definir restrições lógicas e temporais, assim como as operações compatíveis. No modelo de objetos, os objetos e seus relacionamentos são descritos através de um diagrama de classes, como na Figura 3. Uma classe é representada através de um retângulo 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 operações. Na quarta parte indica-se as operações compatíveis, definidas por meio de funções de compatibilidade. Na quinta parte descrevem-se as restrições lógicas e temporais.

4.2 Modelo de Processos (Funcional e Dinâmico) O modelo de processos, é baseado no modelo EG-CPN e é usado para modelar as propriedades funcionais e dinâmicas dos objetos, isto é, ele pode ser visto como a combinação do modelo funcional e do modelo dinâmico em um único modelo. O modelo de processos pode ser usado nas fases de análise, projeto e implementação do sistema. Estas fases podem ser tratadas simultaneamente, uma vez que as redes EGCPN podem ser simuladas e os requisitos analisados. Então, o projetista de uma aplicação pode usar as EG-CPNs para simular a aplicação e discutir os detalhes do comportamento dinâmico da aplicação com os usuários em todos os estágios da especificação. 4.2.1

Obtendo o Modelo de Processos

No modelo de processos os objetos são descritos através de módulos EG-CPN. Ele é definido a partir do modelo de objetos. Então, para cada objeto (contendo operações), identificado no modelo de objetos, é criado um módulo EG-CPN, no qual serão modelados as operações dos objetos correspondentes. A obtenção do modelo de processos envolve os seguintes passos: 1. Identificação dos objetos (EG-CPNs) – corresponde aos objetos do modelo de objeto; 2. Identificação das funcionalidades de cada objeto – corresponde às funcionalidades das operações dos objetos; 3. Definição da interface de cada objeto (GSP) - indica os atributos, as operações e seus argumentos de entrada e saída, as restrições lógicas e temporais, e as operações compatíveis, para o objeto; 4. Definição da estrutura interna de cada objeto (IS ) – modelagem das operações (métodos) do objeto. A aplicação dos passos é ilustrada na seção seguinte através de um exemplo.

peças não reconhecidas NR

M1

esteira PP

tipo 1 P1

MP1

esteira E1

E2 Robo R2

peças produzidas M2

Robo R1 RE peças rejeitadas

C P2

MP2 tipo 2

camera

Figura 2: Uma célula de manufatura

5 Exemplificando o Método Para exemplificar a utilização do método, considere a célula de manufatura mostrada na Figura 2. Ela é composta pelos robôs R1 e R2, quatro máquinas P1, P2, M1, M2 que produzem peças do tipo1 e tipo2, cinco depósitos MP1, MP2, NR, NE e PP, duas esteiras E1 e E2, e uma câmera C. As máquinas P1 e P2 realizam o pré-processamento da matéria-prima. As máquinas M1 e M2 realizam o processamento final da matéria-prima. As esteiras E1 e E2 transportam as peças dentro da célula. O robô R1 transporta a matéria-prima dos depósitos MP1 e MP2 para as máquinas P1 e P2, respectivamente, e deles para a esteira E1. A câmera C obtém as imagens das peças, e a partir destas imagens e de um banco de dados contendo tipos de peças, estas são reconhecidas e classificadas como tipo1 ou tipo2. O robô R2 remove as peças da esteira E1 e as coloca nos depósitos NR ou NE ou nas máquinas M1 ou M2. Peças não reconhecidas, por falta de tempo, são colocadas no depósito NR para inspeção futura. Peças não reconhecidas, por não constarem no banco de dados, são colocadas no depósito de rejeitados RE. Peças reconhecidas são colocadas nas máquinas M1 ou M2, de acordo com seu tipo, tipo1 ou tipo2, respectivamente. Após o processamento, as peças são depositadas na esteira E2, que as conduz para o depósito de peças produzidas PP.

5.1 Obtendo o Modelo de Objetos Inicialmente cria-se o modelo de objetos para a célula, de acordo com os passos indicados na Seção 4.1. Em seguida, esse modelo é utilizado como base para o projeto do modelo de processos. O modelo de objetos para a célula de manufatura da Figura 2 é apresentado na Figura 3.

5.2 Obtendo o Modelo de Processos De acordo com a Seção 4.2, os seguintes passos devem ser seguidos para se obter o modelo do processo em EG-CPN. Passo 1: Identificação dos Objetos Os objetos identificados são: equipamento, robô, peça, câmera e CELLDB. Neste artigo assume-se que as esteiras e depósitos têm capacidade suficiente para suportar o fluxo de materiais e, portanto não serão considerados na concepção do modelo. Para exemplificar o modelo de processos vamos considerar apenas os objetos peça, câmera e CELLDB, modelados pelas EG-CPNs PART, CÂMERA e CELLDB, respectivamente. Os demais objetos encontram-se detalhados em [13, 12].

CELLDB ATRIBUTOS

PEÇA ATRIBUTOS TIPO: cadeia de caracteres QUANTIDADE: inteiro

DB: TIPO*QUANTIDADE *AVI*TIMESTAMP*IMPRECISÃO

MÁQUINA ATRIBUTOS

TIPO: cadeia de caracteres QUANTIDADE: inteiro avi: inteiro TIMESTAMP=ts: time IMPRECISÃO=i: inteiro

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

...

MÉTODOS MÉTODOS RP( ) Ler quantidade de peças MP( ) Processa peça RESTRIÇÕES TIPO com SP1,SP2

RP( ) Ler quantidade de peças FUNÇÃO DE COMPATIBILIDADE FC(RP(pr),AT(pa))=((NOW-DB.ts >DB.avi) and (|DB.v-pa.v| pr.i=pr.i+pa.i+|DB.v-pa.v| RESTRIÇÕES TIPO com T1,T2,Trj,Tni NOW-DB.ts