Criar Modelo de Redes de Petr

Como destacado em Doll (2002), na UML, para cada objeto cujo comportamento seja relevante, deve ser construído um diagrama de estados que representa todos os estados desse objeto. O modelo dinâmico do sistema consiste, portanto, em vários diagramas de estados isolados, funcionando concorrentemente, não existindo uma visão dinâmica global. Na prática, percebe-se que poucos projetos conseguem construir modelos dinâmicos do sistema inteiro em razão da explosão no número de estados. Surge, então, a necessidade de representar a visão dinâmica do sistema utilizando uma outra abordagem que evite esta limitação. Uma solução para essa limitação é a utilização de redes de Petri na modelagem dinâmica de sistemas, como proposto no trabalho de Doll. Algumas das características de redes de Petri, ressaltadas por Doll, que as tornam propícias para capturar especificações comportamentais, orientadas a objetos e concorrentes são: as redes de Petri permitem a modelagem de concorrência, sincronização e compartilhamento de recursos em um sistema; além de que existem muitos resultados teóricos associados a redes de Petri para a análise comportamental, tais como detecção de bloqueio e análise de desempenho.

Adicionalmente, como apresentado no capítulo 2, pesquisas realizadas têm mostrado a adequabilidade do mapeamento entre regras e as redes de Petri. Dada a sua característica de fazer evoluir o estado a partir de regras representadas por transições, as redes de Petri pode ser igualmente consideradas como sistema de regras baseados em uma representação na forma: se condição então ação. Simão (2005) também destaca a viabilidade da utilização de redes de Petri na modelagem de SBRs, e apresentada a compatibilidade entre o metamodelo para controle discreto (que originou o PON) e as redes de Petri.

Dadas essas considerações, optou-se por propor as redes de Petri para realizar a modelagem dinâmica do sistema, o que é feito pela criação do Modelo de Redes de Petri do DON. Este modelo apresenta a interação dinâmica entre os objetos do sistema e permite fazer a validação do modelo por meio da sua simulação ou análise. O DON orienta a criação dos Modelos de Redes de Petri por caso de uso e, posteriormente, deve-se fazer a integração de todos esses modelos em um único Modelo de Rede de Petri.

Simão (2005) apresentada a compatibilidade entre o predecessor do PON e as redes de Petri, na qual cada regra é interpretada como uma transição, as condições e ações da regra são representados pelos arcos, e os estados dos atributos de um elemento são representados por lugares na rede. Aproveitando essa interpretação, e adaptando-a conforme a necessidade,

o Modelo de Rede de Petri do DON pode ser obtido a partir do Modelo de Componentes de acordo com o seguinte mapeamento para uma rede de Petri ordinária:

1. Os componentes estereotipados <<NOP_Condition>>, <<NOP_Rule>> e <<NOP_Action>> do Modelo de Componentes são substituídos por transições no Modelo de Rede de Petri.

2. As interfaces ou componentes <<NOP_Premise>> e <<NOP_Instigation>> são substituídos por lugares na rede. Além de premissas e instigações, essa representação expressa os estados dos atributos de um elemento, uma vez que uma premissa ou instigação testa ou altera o estado de um atributo.

3. Os relacionamentos de notificação também são substituídos por lugares.

A Figura 69 exibe a rede de Petri obtida a partir do Modelo de Componentes da Figura 63, adicionado de um temporizador para controlar o timer do portão. Para o SPE foi utilizada uma rede de Petri ordinária, porque esse tipo de rede satisfez as necessidades de modelagem do sistema. No entanto, para outros casos pode ser necessário utilizar outros tipos de redes. Essa rede foi modelada utilizando-se a ferramenta Visual Object Net++ (DRATH, 2011). Este tipo de rede explicita a estrutura das regras e a interação entre os objetos colaboradores do PON.

Uma vez criadas as redes de Petri de todos os casos de uso, elas devem ser integradas em uma única rede que pode possuir um maior nível de abstração. Neste caso, as transições de condição (ex: condition_rlOpening) e as transições de ação (ex: action_rlOpening) podem ser suprimidas, além dos lugares de notificação (Notifies), gerando assim uma rede de Petri resumida em relação à proposta anterior. Esta rede de Petri resumida segue o modelo proposto por Simão (2005), no qual as condições e ações da regra são representados pelos arcos, sendo que as regras continuam sendo interpretadas como transições e os estados dos atributos também continuam sendo representados por lugares na rede. Portanto, para um mapeamento direto do Modelo de Componentes para este tipo de rede de Petri resumida, seguem-se as seguintes etapas:

1. Os estereótipos <<NOP_Rule>> dos Modelos de Componentes são substituídos por transições na rede de Petri.

2. Os atributos e seus estados que pertencem aos <<NOP_Premise>> e aos <<NOP_Instigation>> são representados por lugares na rede.

3. Os estereótipos <<NOP_Premise>> ou interfaces requeridas são representados pelos arcos que chegam em uma transição que representa um <<NOP_Rule>>. 4. Os estereótipos <<NOP_Instigation>> ou interfaces fornecidas são substituídos

por arcos que saem de uma transição que representa um <<NOP_Rule>>.

A Figura 70 ilustra o modelo de rede de Petri resumido do caso de uso “Abrir Portão”.

Adicionalmente, podem ser adicionados quadrados que envolvam todos os estados de um mesmo FBE na rede de Petri a fim de melhor identificar os FBEs, assim como realizado por Simão (2005) na Figura 39 da fundamentação.