Redes de Petri na Modelagem de Sistemas Orientados a Objetos.
Introdução
O presente artigo discute o uso de um tipo de rede de Petri de Alto Nível, as Redes Compactas, como uma técnica alternativa a Statecharts para modelar o comportamento dos objetos, no contexto da metodologia OMT.
A metodologia de desenvolvimento de sistemas orientada a objetos OMT (Object Modeling Technique) [RUM 91] propõe que a modelagem de um sistema contemple três visões: a estática, a funcional e a dinâmica. A visão estática é atendida pela modelagem de objetos através da representação das classes, dos relacionamentos entre as classes e dos atributos e operações internos às classes. A visão funcional é atendida pela modelagem das funções e fluxos de dados que descreve as transformações que os dados sofrem no interior do sistema. A visão dinâmica é atendida pela modelagem das transições de estados dos objetos.
A modelagem dinâmica, objeto de estudo deste trabalho, descreve os aspectos de controle do sistema, especificando em que momento e em que condições as transições de estado dos objetos podem ocorrer. A notação utilizada em OMT é baseada no formalismo statecharts concebido por David Harel [HAR87a, HAR87b] (ver Bate Byte n.36).
Na metodologia OMT para cada classe, cujo comportamento dinâmico seja relevante, deve ser modelado um diagrama de transição de estados, via statecharts, o qual representará todos os objetos da classe em questão. O modelo dinâmico do sistema consiste, portanto, em múltiplos diagramas statecharts isolados, funcionando concorrentemente. Não existe uma visão dinâmica global. A única forma de representar a interação entre duas ou mais máquinas de estado é através do compartilhamento de eventos. Uma das consequências de modelar o dinamismo de um sistema desta forma é a dificuldade de tratar simultaneamente conjuntos variáveis de objetos, pois cada diagrama modela tão somente um objeto individual.
Trabalho apresentado no XXII Seminário Integrado de Software e Hardware da SBC, Canela - RS.
O presente trabalho tem como objetivo propor a aplicação das redes de Petri de alto nível [JEN92, HEU93] (ver Bate Byte n. 39) na modelagem dinâmica da OMT, de forma a permitir a visualização global e integrada dos aspectos dinâmicos de um sistema e assim conseguir representar a interação de objetos e conjuntos de objetos de uma ou mais classes do universo da aplicação. Baseia-se em propostas anteriores que integram redes de Petri de alto nível com a abordagem entidade-relacionamento [HEU93, KAP91, KUN89]. Naqueles trabalhos, os lugares da rede de Petri são as classes de entidades e os relacionamentos do modelo ER. Neste, os lugares da rede de Petri representam estados de objetos.
Ao propor a integração de redes de Petri ao modelo de objetos da OMT, nos moldes definidos por este trabalho, introduz-se uma rígida disciplina na formação dos lugares da rede, qual seja, todo e qualquer lugar da rede de Petri deve corresponder a um dos possíveis estados de uma classe de objetos do modelo estático. Em outras propostas de utilização da rede de Petri, esta restrição não existe. Embora os lugares também refiram-se a estados de objetos, não existe um compromisso em manter a integração com um modelo de dados existente, portanto é possível que se introduzam lugares que tornem o modelo de difícil implementação. Disto pode se concluir que a modelagem da rede de Petri aqui proposta está bem mais próxima do projeto do sistema que a rede de Petri construída de forma independente.
Limitações de statecharts em sistemas de informação
Um statechart descreve as transições de estado de apenas um indivíduo. Quando a finalidade é modelar sistemas reativos que tratam de objetos físicos isolados, tais como um radar ou um relógio, o formalismo permite obter modelos fiéis. No entanto, quando se lida com sistemas de informação baseados em bancos de dados, que armazenam dados referentes a conjuntos de objetos de uma mesma classe, para utilizar statecharts ou mesmo a clássica máquina de estados, precisa-se fazer uma abstração, qual seja, modelar um objeto representante dos demais objetos da classe.
A limitação no tratamento de conjuntos de objetos de uma mesma classe pode ser ilustrada através do seguinte exemplo: Uma empresa de produção de software possui um setor de tratamento das reclamações oriundas dos seus clientes, onde trabalha um grupo de técnicos treinados para dar atendimento. Cada técnico, quando está disponível, recebe um lote de reclamações para dar encaminhamento e solução. Cada lote é composto de um número variável de reclamações. Um técnico só está liberado para atender um novo lote de reclamações, quando solucionar aquele que estiver atendendo. A figura 1 mostra o modelo de objetos, contendo as classes Técnico, Lote e Reclamação, e os conjuntos de associações Atendimento e Engloba. Logo abaixo, na mesma figura, são listados os possíveis estados que os objetos de cada classe podem apresentar.
A modelagem, através de statecharts, das transições de estado do sistema é mostrada na figura 2. Na figura 2, para cada classe identificada no modelo de objetos existe um diagrama independente. A interação entre eles se dá através da coincidência dos nomes de eventos (por exemplo, o evento alocarTécnico) ou através do disparo, a partir de algum objeto, de uma ação vinculada a um evento, a qual vai se configurar em evento para outro objeto (por exemplo a ação encerrarLote disparada pelo evento registrarSolução, na classe Reclamação, que vai ser considerada como evento nas classes Técnico e Lote).
Para formar um lote de reclamações, o usuário que opera o sistema, pode agrupar um número variável de reclamações (1 a n). Quando isto ocorre um lote passa do estado vazio para o estado formado, e uma ou mais reclamações passam do estado pendente para o estado selecionada. Estas duas transições de estado estão representadas, respectivamente, pelo evento associarConjRecl do diagrama da
Uma outra questão, também relativa à figura 2, diz respeito ao evento encerrarLote que para ser efetivado necessita que a condição associada seja verdadeira, isto é, que todas as reclamações referentes ao lote já tenham sido solucionadas. Esta condição está escrita de maneira informal, pois fica-se diante da impossibilidade de endereçar, ao nível do modelo, todas as reclamações que pertencem ao lote.
Os problemas acima mencionados não existiriam caso fosse definido que todos os lotes sempre teriam uma quantidade fixa de reclamações, por exemplo: três reclamações. Neste caso, como mostra a figura 3, a cada reclamação corresponderia um diagrama statechart, ou seja R1, R2 e R3. Agora seria possível associar explicitamente o evento associarConjRecl com os eventos selecionarRecl1, selecionarRecl2 e selecionarRecl3.
Também ficaria formalizada a condição associada ao evento encerrarLote, pois seria possível citar explicitamente o estado resolvida de cada uma das reclamações do lote. Entretanto a realidade tem mostrado que, na maior parte das vezes que um sistema de informações lida com conjuntos de objetos associados a outro objeto, a cardinalidade é variável.
Redes de Petri na modelagem dinâmica de OMT
As limitações existentes na modelagem dinâmica com statecharts, descritas na seção anterior, podem ser superadas através da utilização de redes de Petri de alto nível. Esta seção propõe utilizar como ferramenta de modelagem dos aspectos dinâmicos de um sistema uma classe das redes de Petri de alto nível: as redes compactas [HEU90, HEU93].
As redes de Petri compactas de alto nível (vide figura 4) contêm os seguintes elementos básicos: conexões (retângulos), lugares (círculos), ramos ligando conexões a lugares e uma linguagem formal de anotação (LA).
As conexões, ao estarem habilitadas, provocam uma modificação no conteúdo dos lugares a ela ligados.
Os ramos podem ser alteradores, pois modificam o conteúdo de um lugar, ou restauradores, quando apenas "consultam" o conteúdo de um lugar sem provocar qualquer alteração. Para que uma conexão esteja habilitada é necessário que: as entidades definidas nos ramos de entrada da conexão, sejam eles alteradores ou restauradores, estejam presentes nos respectivos lugares; que as entidades definidas nos ramos de saída da conexão, sejam eles alteradores ou restauradores, estejam ausentes dos respectivos lugares; e que a fórmula que porventura houver dentro do retângulo que representa a conexão resulte verdadeira, sob a valoração em questão. Após cumpridas todas estas regras a alteração modelada por uma conexão pode ocorrer, fazendo com que o conjunto de objetos especificado em cada ramo alterador de entrada desapareça do respectivo lugar e o conjunto de entidades especificado em cada ramo alterador de saída seja incluído no respectivo lugar.
A metodologia OMT propõe visualizar um sistema através de três pontos de vista: o estático, o dinâmico e o funcional. Cada um destes pontos de vista, ou abordagem, é influenciado e influencia os demais, como está representado na figura 4. Em relação à visão dinâmica, que é o foco deste artigo, os inputs para a construção da rede de Petri compacta, são: (i) o conjunto das transações obtidas da visão funcional, as quais originarão as conexões da rede, e (ii) as classes e associações obtidas da visão estática, cujos possíveis estados formarão os lugares da rede. À medida que se avance na modelagem da rede de Petri, é esperado o surgimento de feedbacks para as duas outras visões da OMT, a estática e a funcional.
Roteiro para a construção de uma rede de Petri compacta
Para auxiliar na modelagem da rede de Petri compacta de alto nível, sugere-se os seguintes passos:
a) Identificação dos estados dos objetos do sistema
Para cada classe existente no modelo de objetos, devem ser identificados os possíveis estados pelos quais cada objeto pode passar. O produto desta atividade será uma lista inicial de estados para cada classe de objetos, incluindo aqui as classes que surgirem de associações. O critério para identificar estados é informal e depende muito da interpretação que o analista dá ao problema. A princípio, qualquer modificação de valor dos atributos de um objeto representa uma mudança de estado. O analista deve selecionar, através de um processo de abstração, aquelas julgadas relevantes à aplicação.
b) Identificação das transações do sistema
Um sistema de informações além dos dados que estão armazenados em bancos de dados, possui um conjunto de transações que ao serem acionadas, ou provocam modificações nos dados armazenados, ou apenas os consultam.
A lista de transações para dar início à construção da rede de Petri compacta pode ser de caráter preliminar, não havendo necessidade de um aprofundamento na modelagem da visão funcional. É importante ressaltar que a própria modelagem da rede de Petri fornecerá importantes subsídios para o detalhamento e consolidação do modelo funcional, devido à visão global que fornece do sistema. Em sistemas simples a lista de transações é facilmente obtida a partir da descrição informal do problema. Em sistemas mais complexos, no entanto, pode ser necessário adotar alguma ferramenta de modelagem para identificar as transações, por exemplo o DFD.
c) Construção da rede de Petri
Conhecendo a lista das transações do sistema e os estados que os objetos manipulados por este sistema podem assumir, pode ser iniciada a construção da rede de Petri para modelar os aspectos dinâmicos.
Formalmente a rede de Petri que modela um sistema é um modelo único. Em sistemas maiores é recomendável dividir a rede em segmentos. Um critério possível para a segmentação é o de modelar em um mesmo diagrama transações afins. A conexão entre dois segmentos de rede de Petri se dá através da repetição dos lugares que lhes são comuns.
Adaptação das redes de Petri compactas para OMT
O presente trabalho propõe que a utilização da rede de Petri compacta de alto nível obedeça à seguinte regra que promove a sua integração com o modelo de objetos da visão estática:
Qualquer lugar da rede de Petri deve sempre corresponder a um determinado estado de uma classe ou associação do modelo de objetos e todos os estados possíveis de todas as classes e associações do modelo de objetos devem estar representados por lugares na rede de Petri.
A figura 5 apresenta uma rede de Petri compacta construída conforme a regra acima. Trata-se do mesmo sistema de atendimento a reclamações modelado via statecharts na figura 2 da sessão anterior.
A notação utilizada na rede de Petri é aquela utilizada em [HEU90,HEU93] com a introdução de uma regra de formação dos nomes dos lugares da rede. Propõe-se que seja atribuído a cada lugar o nome da classe de objetos seguida de um nome de estado entre colchetes, por exemplo, os lugares Técnico [ocupado] e Lote [formado], entre outros existentes na figura 5. Dentro de um lugar da rede podem haver vários objetos da classe especificada na notação, significando que todos eles estarão no estado descrito entre colchetes.
Tendo em vista a interpretação que lhes é dada neste trabalho, as conexões da rede de Petri (os retângulos do diagrama) serão chamadas de transações. Uma transação para ser efetivada necessita estar habilitada conforme as regras das redes de Petri. Por exemplo, a transação associarConjRecl estará habilitada toda vez que:
- o lote representado pela variável lote estiver presente no lugar Lote[vazio] e ausente do lugar Lote[formado];
- o subconjunto de reclamações representado pela variável cj_recl estiver presente no lugar Reclamação[pendente] e ausente do lugar Reclamação [selecionada];
- o par formado pela combinação do lote com o conjunto de reclamações, representados respectivamente pela variável lote e pela variável cj_recl, estiver ausente do lugar Engloba[X].
A efetivação da alteração especificada pela transação associarConjRecl produzirá os seguintes resultados na rede:
- o lote representado pela variável lote sairá do lugar Lote[vazio] e entrará no lugar Lote[formado];
- todas as reclamações do subconjunto representado pela variável cj_recl sairão do lugar Reclamação [pendente] e entrarão no lugar Reclamação [selecionada].
- surgirá no lugar Engloba[X] um objeto correspondente ao par composto pelo lote representado pela variável lote e pelo subconjunto de reclamações representado pela variável cj_recl.
A modelagem desta transação demonstra a capacidade da rede de Petri de tratar com precisão conjuntos variáveis de objetos, o que não ocorre com statecharts, conforme ficou evidenciado quando se tentou modelar a mesma transação na sessão anterior.
Situações especiais
Para integrar as redes de Petri compactas de alto nível à OMT, algumas situações específicas precisam ter a sua notação convencionada. Neste trabalho duas delas são apresentadas: objetos que não apresentam transição de estados e criação/destruição de objetos:
a) Objetos que não apresentam transição de estados
Certos objetos envolvidos em uma aplicação podem não apresentar transições de estados relevantes, com exceção da sua criação e da sua eliminação. Nestes casos, a identificação do lugar na rede de Petri leva o nome da classe seguido da constante 'X' entre colchetes.
Os objetos que venham a estar nestes lugares não poderão nunca ser transferidos para outro lugar na rede, pois isto configurar-se-ia em uma transição de estados. A única forma de promover alteração no conteúdo destes lugares é através da criação ou da destruição de objetos.
b) Criação e destruição de objetos
Toda a vez que um objeto é criado dentro do contexto de uma aplicação ele passa a ter uma identidade que o individualiza em relação aos demais objetos do universo de discurso da aplicação. Entre a criação e a destruição de um objeto não devem haver lapsos na sua existência, isto é, ele existe durante todos os momentos deste período de tempo.
A forma de modelar a criação de um objeto em rede de Petri é através de uma conexão que possua um ramo alterador de saída ligado a um lugar referente à classe do objeto em seu estado inicial. Por ser uma conexão criadora de objetos ela não deve possuir ramos alteradores de entrada referindo-se ao objeto que está sendo criado. Caso isto ocorresse tal objeto não estaria sendo criado, simplesmente estaria mudando de estado.
Modelar a destruição de objetos é exatamente o inverso da forma de modelar a sua criação.
Conclusão
O uso de redes de Petri de alto nível na modelagem dos aspectos dinâmicos de um sistema de informação, conforme é proposta neste artigo, mostra-se superior ao formalismo statecharts quando existe a necessidade de se referenciar conjuntos variávies de objetos de uma mesma classe. A rede de Petri permite que se especifique precisa e formalmente esta situação.
As redes de Petri são muito estudadas na literatura sendo sua semântica mais precisamente formalizada que a do statecharts.
A favor de statecharts conta, além da simplicidade de uso, a sua capacidade de permitir a elaboração de modelos estruturados, multiníveis.
A respeito da perspectiva que se tem de um sistema, existe uma diferença de paradigma entre statecharts e redes de Petri. Em statecharts focalizam-se as classes do modelo de objetos, construindo-se um diagrama independente para cada uma delas. Em redes de Petri, aborda-se o sistema como um todo, através de um diagrama unificado e integrado, tendo como foco principal as transações que afetam objetos de classes diferentes.
Para tratar a complexidade de uma rede de Petri, há a necessidade de se pesquisar e propor mecanismos que permitam o particionamento e estruturação de uma rede, sem que isto comprometa o seu formalismo.
Bibliografia
[HAR87a] HAREL, David. statecharts: a visual formalism for complex systems. Science of Computer Programmming, v. 8, 1987.
[HAR87b] HAREL, David. On visual formalisms. The Weizmann Inst.of Science, Rehovot, Israel, jun/1987.
[HEU90] HEUSER, Carlos A. Modelagem conceitual de sistemas: redes de Petri. V EBAI. Nova Friburgo, 1990.
[HEU91] HEUSER, C. A.; PERES, Eduardo M. ER-T diagrams: an approach to specifying database transactions. In: 10th Intern. Conf. on the E-R Approach, 1991, San Mateo, CA.
[HEU93] HEUSER, C. A.; PERES, E. M; RICHTER, G. Towards a complete conceptual model: Petri nets and E-R diagrams. Inf. Systems v.18,n.5, 1993
[JEN92] JENSEN, K. Colured Petri Nets: Basic concepts, Analysis Methods and Practical Use. Vol 1. Springer Verlag, Berlin 1992
[KAP91] KAPPEL, G.; SCHREFL, M. Object Behavior diagrams. Proc. Int. Conf. on Data Engineering. Kobe, pp 530-539, IEEE Computer Society Press 1991
[RUM91] RUMBAUGH, James et al. Objetct-oriented modeling and design. Prentice-Hall, New Jersey, 1991