Verificação e Validação de Sistemas Orientados a Objetos
Usando Redes de Petri
Luciano Mathias Döll1, João Umberto Furquim de Souza1, Paulo Cesar Stadzisz2
1
Departamento de Informática – Universidade Estadual de Ponta Grossa (UEPG) 84.030-930 – Ponta Grossa – PR – Brazil
2
Centro Federal de Educação Tecnológica do Paraná – CEFET - PR 80230-901 - Curitiba – PR - Brazil
[email protected], [email protected], [email protected]
Abstract. This paper presents a new approach for dynamic modeling of the
object-oriented computational systems. Instead of employing state charts to describe the state models of each class, as in UML, this approach proposes to employ Predicate/Transition Petri nets. By analyzing the interaction among objects of the different classes, it is possible to integrate the Petri nets of each class in sense of obtaining a unique Predicate/Transition Petri net which describes the global states model of the system. The main benefit for using a formal notation to model the dynamic of a system is the possibility to apply formal analysis techniques aiming to validate the properties of the system.
Resumo. Este artigo apresenta uma nova abordagem para a modelagem da
dinâmica de sistemas computacionais orientados a objetos. Ao invés de empregar diagramas de transição de estados para descrever os modelos de estados de cada classe, como faz a UML, esta abordagem propõe o emprego de redes de Petri Predicado/Transição. Analisando a interação entre objetos de classes diferentes pode-se integrar as redes de Petri de cada classe a fim de obter-se uma única rede de Petri Predicado/Transição que descreve o modelo de estados global para o sistema. A principal vantagem de se utilizar uma notação formal para modelar a dinâmica de um sistema é a possibilidade de aplicar técnicas de análise formal com o intuito de validar propriedades do sistema.
1. Introdução
A modelagem de um sistema orientado a objetos contempla três visões: estática, funcional e dinâmica [Rumbaugh et al. 1991]. As visões estática e funcional estão relacionadas à modelagem estrutural, enquanto a visão dinâmica está relacionada ao fluxo de execução do sistema. A visão dinâmica é modelada sob dois níveis de abstração: um nível de colaboração entre os objetos, que trata da troca de mensagens entre eles, e um nível de comportamento do objeto, que trata dos estados, transições, eventos e ações de cada objeto. Na UML [Fowler and Scott 1997], o nível de colaboração entre os objetos é descrito pelos diagramas de seqüência e de colaboração, e o nível de comportamento do objeto é descrito pelos diagramas de atividades e de transição de estados.
Os modelos construídos utilizando a UML são semi-formais porque utilizam-se tanto modelos formais, como os diagramas de transição de estados, quanto modelos informais, como os diagramas de colaboração. Por conseqüência, não é possível realizar validações completas do sistema. Por exemplo, não é possível garantir a coerência do comportamento de um mesmo objeto no diagrama de transição de estados e no diagrama de seqüência.
Além disso, não existe, na UML, um diagrama que represente o modelo de estados global do sistema. Mesmo que se tentasse descrever todo o sistema através de um único diagrama de transição de estados, esta tarefa poderia se tornar impraticável em razão da explosão na combinação de estados. Este modelo global apresentaria um número total de estados igual ao produto das quantidades de estados apresentadas pelos diagramas de transição de estados de cada classe. Desta forma, o modelo global de um sistema com 10 objetos de classes distintas, sendo cada classe representada por um modelo de estados com 5 estados distintos, apresentaria 510 = 9.765.625 estados distintos.
O objetivo deste trabalho foi propor uma nova abordagem para a modelagem da dinâmica de sistemas orientados a objetos que permitisse a geração de um modelo de estados global para o sistema e, a partir deste modelo, aplicar métodos de verificação e validação da dinâmica do sistema. Esta nova abordagem é baseada em UML e Redes de Petri [Reisig 1985].
As redes de Petri são eficientes na modelagem, análise e simulação de sistemas dinâmicos com comportamento concorrente e não-determinístico. Como a notação é formal, pode-se aplicar algoritmos de análise sobre a rede com o intuito de verificar e validar propriedades do sistema. Além disso, para construir a rede, o projetista é obrigado a possuir uma noção completa e exata do funcionamento do sistema, o que diminui a incidência de erros e inconsistências nas fases posteriores de especificação e projeto do software.
Não obstante os benefícios de utilizar redes de Petri na modelagem de sistemas computacionais, elas são criticadas porque costumam gerar modelos extensos e complexos. Além disso, as redes de Petri são consideradas um método isolado pois não possuem integração com outras técnicas de modelagem existentes. A especificação de sistemas através de redes de Petri se torna inviável também em razão de não haver mecanismo ou notação que permita especificar a estrutura do sistema. Elas não consideram relações de associação, agregação e herança entre seus elementos.
A abordagem apresentada neste trabalho prevê o uso integrado de redes de Petri e UML na modelagem da dinâmica de sistemas orientados a objetos. Outras abordagens baseadas na integração entre UML e Redes de Petri para a modelagem da dinâmica de sistemas foram estudadas.
A metodologia proposta por [Cheung et al. 1998] transforma cenários de interação entre objetos (diagramas de seqüência) em redes de Petri ordinárias com o intuito de validar estes cenários. Nesta metodologia, não há a pretensão de se gerar uma única rede de Petri que represente o modelo de estados global para o sistema inteiro.
[Watanabe et al. 1997] propõem a utilização de redes de Petri coloridas [Jensen 1997] para modelagem da dinâmica de sistemas orientados a objetos. Uma rede de Petri
colorida representa o modelo de estados de uma classe e, portanto, de todos os objetos baseados na classe. Sempre que um objeto é criado durante a execução do sistema, uma nova marca colorida é criada na rede de Petri colorida.
A abordagem UML/PNO, proposta por [Paludetto and Delatour 1999], propõe o uso de redes de Petri objeto [Lakos 1997] em substituição aos diagramas de transição de estados. A abordagem UML/PNO é considerada adequada para a modelagem de sistemas de tempo real, que apresentam elevado grau de paralelismo, concorrência e relações de ordem. Por estas razões, a validação e verificação dos modelos tornam-se essenciais.
A metodologia CR (Customization Rules), proposta por [Baresi and Pezzè 2001] apresenta um conjunto de regras para traduzir uma especificação descrita através de uma notação semi-formal (UML) para uma especificação descrita através de uma notação formal (redes de Petri Predicado/Transição [Murata 1989]).
[Saldhana and Shatz 2000] descrevem um processo para gerar uma rede de Petri colorida a partir dos modelos dinâmicos de um sistema especificados na UML. Nesta abordagem, os diagramas de transição de estados da UML são primeiramente convertidos em máquinas de estados finitos. Estas máquinas de estados finitos são, então, convertidas para redes de Petri objeto. A seguir, os diagramas de colaboração da UML são usados para conectar as redes de Petri objeto com o objetivo de gerar uma única rede de Petri colorida que representa todo o sistema.
Neste artigo, é apresentada uma abordagem que utiliza UML e Redes de Petri Predicado/Transição para a modelagem da dinâmica de sistemas orientados a objetos. O principal conceito é a substituição dos diagramas de transição de estados por redes de Petri Predicado/Transição [Döll 2003]. Porém, os demais diagramas da UML não são ignorados. O projetista os utiliza do mesmo modo seguindo o processo unificado [Jacobson and Booch 2002] de análise e projeto de sistemas.
A abordagem proposta apresenta um modo sistemático de descrever os modelos de estados de cada classe através de redes de Petri, e integrá-las gerando uma única rede de Petri para fins de validação e verificação do comportamento do sistema. O fato de se considerar múltiplos fluxos de execução (threads) [Andrews 1991] na fase de projeto diminui o “gap” entre as fases de projeto e implementação, uma vez que threads são freqüentemente tratadas somente na fase de implementação. Além disso, foi desenvolvido um protótipo de uma ferramenta CASE, que gera o modelo de estados global do sistema de modo automático e interativo.
O restante deste artigo está organizado do seguinte modo. A próxima seção apresenta as técnicas inerentes à abordagem proposta neste trabalho. A seção 3 descreve o processo de verificação e validação de propriedades de sistemas orientados a objetos, tendo como base a abordagem proposta na seção 2. A seção 4 destaca as conclusões deste trabalho e a seção 5 indica perspectivas de trabalhos futuros.
2. UML e Redes de Petri
Conforme enunciado na seção anterior, ao utilizar a abordagem que está sendo apresentada, o projetista continua utilizando os diagramas da UML, com exceção dos diagramas de transição de estados, que são substituídos por redes de Petri. A visão
estática de um sistema é representada pelo diagrama de classes na UML. Através do diagrama de classes, o projetista descreve a estrutura das classes do sistema modelado, bem como o relacionamento entre estas classes. A figura 1 ilustra o diagrama de classes de um sistema bibliotecário, que foi utilizado como estudo de caso para aplicação da abordagem apresentada.
Figura 1. Diagrama de classes
Quanto à visão estática, a abordagem proposta não prevê alterações em relação a UML. Quanto à visão dinâmica, a proposta é a substituição dos diagramas de transição de estados por redes de Petri. Ao invés de descrever o modelo de estados de uma classe através de um diagrama de transição de estados, esta abordagem propõe que a descrição seja feita por meio de uma rede de Petri. Portanto, cada classe apresentaria uma rede de Petri relacionada.
Com o intuito de tornar a descrição do modelo de estados de uma classe mais sistemática para o projetista, algumas regras são aplicadas. Para cada método de uma classe, é criado um par de lugares de rede de Petri. Um dos lugares indica a requisição do método e o outro indica o retorno do método após sua execução. Estes pares de lugares correspondentes aos métodos da classe são posicionados à esquerda, sobre uma moldura que abrange toda a rede de Petri, e envoltos de uma pequena caixa retangular de cantos agudos. A classe CCtrlGeral, ilustrada na figura 2, apresenta dois métodos que, neste caso, são os métodos construtor e destrutor da classe.
Também são identificadas as chamadas externas que cada classe realiza. Para isso, são acrescentados pares de lugares correspondentes às chamadas efetuadas pela classe. Estes pares de lugares são posicionados à direita, sobre a moldura que abrange a rede de Petri, e envoltos por uma pequena caixa retangular com cantos arredondados. A classe CCtrlGeral, ilustrada pela figura 2, efetua chamadas a quatro diferentes métodos
de outras classes: solicitaOpção(), da classe CintUsuário, consultaAutor(), da classe
CctrlConsAut, inserirLivro(), da classe CctrlIns e consultaTitulo(), da classe CctrlConsTit. O motivo de representar as chamadas efetuadas pela classe é a facilidade
no processo de integração das redes de Petri. Este processo é detalhado na seção 2.2.
Figura 2. Rede de Petri
Depois que o projetista insere os pares de lugares correspondentes aos métodos da classe e às chamadas da classe, o próximo passo é descrever o modelo de estados da classe. Basicamente, os métodos da classe correspondem a eventos e as chamadas correspondem a ações no diagrama de transição de estados. Internamente, os estados representados nos diagramas de transição de estados são mapeados em lugares da rede de Petri e as transições são mapeadas em transições de redes de Petri. Estes esquemas de mapeamento são mostrados na figura 3.
2.1. Redes de Petri Predicado/Transição
Os objetos de uma mesma classe podem ser executados concorrentemente. Isto quer dizer que os estados dos objetos baseados em uma mesma classe são concorrentes e independentemente alterados, pois representam instâncias de uma mesma classe. A figura 4 ilustra três objetos baseados na mesma classe e que estão em estados distintos. Em geral, toda vez que um novo objeto de uma classe é instanciado, um novo fluxo de travessia do diagrama de transição de estados desta classe deveria ser criado. Este fluxo indicaria o estado corrente do novo objeto, independente dos fluxos de travessia dos demais objetos desta classe. Quando um objeto é desalocado, seu fluxo de travessia deixa de existir pois o diagrama de transição de estados teria alcançado o estado terminal.
A utilização de redes de Petri ordinárias para a modelagem de múltiplas instâncias de objetos de uma mesma classe tornaria o modelo complexo e extenso. Isto ocorre em razão da necessidade de se construírem estruturas que representem tanto a construção e destruição de objetos quanto a sua evolução de estados e seu endereçamento por objetos de outras classes. Na verdade, as redes de Petri ordinárias não possuem marcas identificáveis, o que impõe estruturas de controle adicionais.
Figura 4. Diagramas de transição de estados
Visando a obtenção de modelos mais concisos, utiliza-se neste trabalho uma categoria de redes de Petri de mais alto nível denominada rede de Petri Predicado/Transição. Redes de Petri Predicado/Transição incorporam o conceito de individualidade na marcação de uma rede de Petri. Os lugares da rede são chamados de Predicados e as marcas que neles se encontram representam as condições válidas do predicado. As marcas em um predicado definem sua extensão atual. Uma marca (tupla com um, dois,..., n elementos) é representada por <x1,x2,..., xn>; no caso limite no qual n = 0 (<>) perde-se a possibilidade de individualização e volta-se ao conceito clássico de “marca” indistinguível [Murata 1989].
Algumas abordagens empregam redes de Petri coloridas para descrever os modelos de estados das classes. Todavia, existe um inconveniente ao se adotar esta categoria de rede de Petri de alto nível para o propósito deste trabalho. Embora as redes de Petri coloridas considerem marcas distinguíveis, elas permitem um número restrito delas em função do número de cores limitado. Como uma classe pode servir de modelo para um número potencialmente infinito de instâncias, o emprego de redes de Petri coloridas se torna inviável. Esta é a razão pela qual a abordagem proposta neste artigo adota redes de Petri Predicado/Transição, ao invés de redes de Petri coloridas.
2.2. Integração
Depois que os modelos de estados de cada classe são representados através de redes de Petri, a próxima etapa é integrar as redes a fim de obter-se uma única rede de Petri Predicado/Transição. Esta rede de Petri representa o modelo de estados global do sistema e é através dela que os cenários de interações entre objetos são verificados e validados. A integração exige o conhecimento de quais classes se relacionam e como o fazem. Este conhecimento é obtido através do diagrama de colaboração, no qual são declaradas as trocas de mensagens entre os objetos de cada classe.
Para a integração, é criado um par de transições além do escopo de cada classe. As transições permitem a ligação entre a interface de invocação da classe que invoca um
determinado método com a interface comum da classe que recebe a invocação do mesmo método. A adoção de um par de transições para integrar as redes ocorre em razão de melhorar a compreensão e facilitar a leitura do modelo em um primeiro momento. No entanto, após a geração da rede de Petri Predicado/Transição que integra todas as classes, estes pares de transições são suprimidos devido à aplicação de técnicas de redução para redes de Petri e os lugares que os conectavam são fundidos. A integração das redes de Petri de cada classe permite a obtenção de uma única rede de Petri Pr/T que representa o comportamento global do sistema.
Embora a rede gerada seja extensa e seu grau de clareza diminua à medida que aumente o tamanho do sistema, o processo de geração da rede é automático e, portanto, não exige nenhum esforço adicional do projetista. Além disso, o número de elementos da rede é muitas vezes menor que o número de elementos do diagrama de transição de estados se houvesse a tentativa de construí-lo para descrever o modelo de estados global do sistema. Em relação ao modo tradicional de analisar e projetar sistemas, o esforço exigido pela abordagem é a habilidade para descrever os modelos de estados através de redes de Petri, ao invés de diagramas de transição de estados.
3. Verificação e Validação
A validação de um cenário de interação entre objetos é realizada através da elaboração do grafo de alcançabilidade [Murata 1989] para aquele cenário particular. Por exemplo, o diagrama de seqüência da figura 5 representa o cenário de interação para execução do caso de uso "Consultar Livro por Título" em um sistema bibliotecário. Este diagrama mostra a interação que ocorre entre os objetos CCtrlConsTit, CIntArq, CIntUsuário e
CLivro. Para efetuar a validação deste cenário, após a integração das redes de Petri,
isola-se a porção da rede integrada que envolve os modelos de estados das classes que servem de modelo para os objetos citados.
Figura 5. Diagrama de Seqüência
A figura 6 apresenta a porção da rede de Petri que envolve as classes
CCtrlConstTit, CIntArq, CIntUsuário e CLivro. Para facilitar a visualização, nesta figura
após o início do disparo das transições. A identificação destes elementos é feita de acordo com os métodos que são invocados pelos objetos neste cenário de interação. Estes métodos são: SolicitaTitulo() e MostraAutor(), da classe CIntUsuário,
ConsultaTitulo(titulo), da classe CIntArq, SetAutor(autor) e GetAutor(), da classe CLivro.
Figura 6. Rede de Petri Integrada
A marcação desta rede de Petri define que o objeto CctrlConsTit está no estado de Pronto e recebeu a invocação do método ConsultaTitulo(). Isto significa que se trata do início de execução do caso de uso "Consultar Livro por Título". Os demais objetos estão igualmente no estado de Pronto. A marcação inicial da rede é <p1, p3, p17, p24, p33>. O objetivo é testar a validade deste cenário de interação. Um cenário é válido se não há qualquer tipo de inconsistência na sua evolução, como por exemplo, um bloqueio. Não havendo inconsistências, após os disparos das transições, a marcação final deve ser <p2, p3, p17, p24, p33>.
Além disso, é necessário verificar os estados intermediários no grafo de alcançabilidade. Os estados intermediários representam os momentos que ocorrem as requisições de métodos no decorrer da evolução do cenário de interação. A ordem temporal destas trocas de mensagem deve ser respeitada de acordo com o diagrama de seqüência. A requisição do método SolicitaTitulo() corresponde ao nodo do grafo de alcançabilidade cuja marcação é <p4,p7,p17,p24,p33>. A requisição do método ConsultaTítulo(título) corresponde ao nodo do grafo de alcançabilidade cuja marcação é <p5,p9,p17,p24,p33>. A requisição do método SetAutor(autor) corresponde ao nodo do grafo de alcançabilidade cuja marcação é <p5,p17,p25,p26,p33>. A requisição do método MostraAutor() corresponde ao nodo do grafo de alcançabilidade cuja marcação
é <p6,p11,p17,p24,p33>. A requisição do método GetAutor() corresponde ao nodo do grafo de alcançabilidade cuja marcação é <p6,p19,p20,p24,p33>.
A figura 7 mostra o grafo de alcançabilidade elaborado para testar a validade deste cenário. Conforme se pode observar no grafo, a marcação final é <p2, p3, p17, p24, p33>. Além disso, ao percorrer o grafo de alcançabilidade do estado inicial ao final, os nodos cujas marcações correspondem às requisições dos métodos, são visitados na seqüência temporal estabelecida no diagrama de seqüência. Portanto, o cenário é válido.
Um cenário pode se tornar inválido por diversas razões. Uma delas é a presença de bloqueio, que consiste na existência de um estado impedindo qualquer outro método de ser invocado. Em termos de rede de Petri, isto significa que há uma marcação não final, onde nenhuma transição está habilitada.
4. Conclusões
Através da abordagem apresentada na seção anterior, todas as redes de Petri relacionadas a todas as classes do sistema são integradas. Sendo assim, uma única rede de Petri que representa o modelo de estados global do sistema é obtida. Em contrapartida, na UML, é permitido descrever apenas o modelo de estados de cada classe do sistema. É impraticável obter um diagrama de transição de estados para o sistema inteiro devido à explosão no número de estados.
São utilizadas, na abordagem proposta, redes de Petri Predicado/Transição, que permitem perceber as evoluções distintas de todos os objetos do sistema por trabalharem com o conceito de individualidade na marcação. Desta forma, um predicado da rede pode indicar em um dado momento da execução do software a existência de mais de um objeto compartilhando um mesmo estado. O diagrama de transição de estados, utilizado na UML, permite apenas criar um modelo de estados para cada classe do sistema. Porém, a evolução de estados prevista no diagrama é somente um modelo para cada objeto da classe, uma vez que, em tempo de execução, cada objeto apresenta sua própria evolução de estados.
Depois que uma única rede de Petri é gerada, através do processo de integração, para representar a dinâmica global do sistema, algoritmos podem ser aplicados para verificar e validar a semântica do projeto. Entre as possibilidades de verificação, estão a verificação de ausência de bloqueio e a validação de cenários de interação entre objetos.
Em relação às abordagens analisadas, a que mais se aproxima da abordagem proposta é a metodologia CR [Baresi and Pezzè 2001]. Porém, enquanto a CR emprega regras de mapeamento para traduzir os diagramas de transição de estados desenhados pelo projetista em redes de Petri, a abordagem proposta sugere que o comportamento de cada classe seja diretamente descrito pelo projetista por meio de uma rede de Petri.
Figura 7. Grafo de alcançabilidade
A figura 8 mostra uma tabela que compara as diferentes abordagens estudadas à abordagem proposta. A maioria delas defende a conversão de diagramas de transição de estados em redes de Petri. Todavia, [Cheung et. al. 1998] sugerem a conversão de cenários em redes de Petri e [Watanabe et. al. 1997] propõem a conversão de métodos em redes de Petri.
Com exceção da abordagem de [Cheung et. al 1998], as demais abordagens permitem a geração de uma única rede de Petri através da integração das redes de Petri de cada classe. Todas as abordagens permitem a especificação de qualquer tipo de sistema, exceto UML/PNO [Paludetto and Delatour 1999]. A única que permite descrever múltiplos fluxos de execução (threads) é a abordagem de [Watanabe et. al. 1997] A metodologia CR apresenta uma representação gráfica para descrever as interfaces externas (métodos) de cada classe. O mecanismo para descrever múltiplos fluxos de execução e a representação gráfica para descrever as interfaces externas foram adaptados e incorporados à abordagem proposta neste trabalho.
Embora a abordagem proposta apresente um grau de formalismo acentuado ao estabelecer o emprego de redes de Petri na modelagem da dinâmica de um sistema, o nível de dificuldade deste processo de modelagem é relativamente baixo uma vez que a abordagem utiliza notação gráfica e intuitiva, além de ser baseada na UML e no processo unificado.
5. Trabalhos futuros
A visão dinâmica apresenta dois níveis de abstração: o nível de colaboração entre os objetos e o nível de comportamento dos objetos. A abordagem apresentada neste trabalho propõe o uso de redes de Petri Predicado/Transição para descrever somente o nível de comportamento dos objetos. A evolução deste trabalho prevê o uso de redes de Petri para especificar os dois níveis de abstração. Isto significa que o projetista descartaria, além dos diagramas de estados, os diagramas de seqüência e de colaboração. Portanto, a visão dinâmica na UML seria integralmente formal, permitindo a validação dos requisitos do sistema previstos na visão funcional.
Conforme a abordagem proposta neste trabalho, a descrição do comportamento de cada classe considera somente seus métodos públicos. Como trabalho futuro, pode ser realizado o estudo de um mecanismo para representar os métodos privados. Além disso, na visão estrutural são descritas relações de herança, agregação e associação. Nas relações de herança, uma subclasse pode herdar o comportamento de uma superclasse. A evolução deste trabalho deve permitir que este comportamento seja herdado em termos de redes de Petri.
Ainda como perspectiva de trabalho futuro, pode ser feito um levantamento de outras propriedades que são passíveis de verificação e validação através da análise das redes de Petri. Neste trabalho, foram estudadas somente duas propriedades: validação de cenários e ausência de bloqueio. Entre as propriedades que podem ser avaliadas, estão a exclusão mútua dos estados através da análise de invariantes e limites dos estados através da análise da limitabilidade.
Referências
Andrews, G.R. (1991) “Concurrent Programming: Principles and Practice.” Benjamin/Cummings.
Baresi, L., Pezzè, M. (2001) “On Formalizing UML with High-Level Petri Nets”. In G. Agha and F. De Cindio (eds.) Concurrent Object-Oriented Programming and Petri Nets (a special volume in the Advances in Petri Nets series); pages 271-300. Number 2001 of Lecture Notes in Computer Science - Springer Verlag.
Cheung, K.S., Chow, K.O., Cheung, T.Y. (1998) “Deriving scenarios of object interaction through petri net”. In: Proceedings of the Technology of Object-Oriented Languages and Systems.
Döll, L. M. (2003) “Proposta de uma Metodologia para a Modelagem da Dinâmica de Sistemas Orientados a Objetos Usando Redes de Petri Predicado/Transição”. Dissertação de Mestrado apresentada ao CPGEI-CEFET-PR, Curitiba-PR.
Fowler, M., Scott, K. (1997) “UML Distilled”. Addison Wesley Longman, Reading, MA.
Jacobson, I., Booch, G. (2002) "The Unified Software Development Process". Addison Wesley Pub.
Jensen, K. (1997) “Coloured Petri Nets – Basic Concepts, Analysis Methods and Practical Use – Volume 3”. Springer-Verlag.
Lakos, C. (1997) "Object Oriented Modelling with Object Petri Nets". In: Advances in Petri Nets. LNCS, Springer, Berlin.
Murata, T. (1989) “Petri Nets: Properties, Analysis and Applications.” Proceedings of the IEEE, Vol. 77, No. 4, April.
Paludetto, M., Delatour, J. (1999) “UML et les réseaux de Petri : vers une sémantique des modèles dynamiques et une méthodologie de développement des systèmes temps réel”, In: L’Object.
Reisig, W. (1985) “Petri Nets – An Introduction”. Springer-Verlag.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W. (1991) “Object-Oriented Modelling and Design”. Prentice Hall, 1991.
Saldhana, J. A., Shatz, S. M. (2000) “UML Diagrams to Object Petri Net Models: An Approach for Modeling and Analysis”. In: Twelfth International Conference on Software Engineering and Knowledge Engineering. July 6-8. Chicago, IL, USA. Watanabe, H., Tokuoka, H., Wu, W., Saeki, M. (1997) “A Technique for Analysing and
Testing Object-oriented Software Using Coloured Petri Nets”, IPSJ SIGNotes Software Engineering No.117.