Adriano José Pinheiro Lemos
Dissertação submetida à Coordenação do Curso de Pós-Graduação
emInformáti adaUniversidade FederaldaParaíba-Campus II
o-mopartedos requisitosne essáriosparaobtenção dograude Mestre
emInformáti a.
Áreade Con entração: Ciên iada Computação
Linha de Pesquisa: Sistemas de Software
Angelo Perkusi h
(orientador)
Campina Grande,Paraíba,Brasil
Neste trabalhoinvestiga-seaapli açãodosprin ipais on eitosdereúsodesoftware
na modelagem formal de sistemas. Mais espe i amente, trata-se do reúso de
mode-los de sistemas de software utilizando Redes de Petri Coloridas. O prin ipal objetivo
é ontribuir para melhorar o pro esso de modelagem de sistemas de software
om-plexos, distribuídos e on orrentes. Como resultado, introduz-se atividades de reúso
no pro esso de modelagem,mais espe i amente armazenamentoe re uperação. Tais
atividadessão suportadaspela introduçãode um métodoe umaté ni a integrados de
Inthisworkthemain on eptsofsoftware reuseareappliedtotheformalmodelling
a tivitiesofasoftwaredevelopmentpro ess. Morespe i ally,wefo usthemodelreuse
of software systems des ribed in Coloured Petri Nets. The main goal of this work is
to improve the modelling pro ess of omplex, distributed, and on urrent software
systems. Asaresult,we omewiththeintrodu tionofreusea tivitiesonthemodeling
pro ess, namely the storage and retrieval of artifa ts. This a tivities are suported by
theintrodu tioof ate hnique, andamethod,whi hintegrated, provideawaytoreuse
Agradeço a todos os amigos, novos e antigos, que, inten ionalmente ou não, me
ajudaramounãomeatrapalharamduranteodesenvolvimentoeredaçãodestetrabalho.
Espero poder retribuir-lhes ofavornão osatrapalhando,quando for possível,em suas
fainasmais omplexas. Emparti ular,agradeçoatodos olegasquedividiramoespaço
dolaboratório de redes de Petri e asangústias dos dias ina abáveis.
Umagrade imentoespe ial aomeuorientadorAngeloPerkusi h pelapresteza,
sin- eridade e seriedade durante os pro essos, nem sempre agradáveis, de on epção,
im-plementação e do umentação deste trabalhode mestrado.
Finalmente, agradeço a minha mãe e meu pai(Salete e Ribamar)pelo exemplode
vidaepelaoportunidadede lhes dar alegriasmesmoquefugazes; eaminhanamorada
Sophia por salvar um ambiente distinto do a adêmi o, resguardando assim a minha
1 Introdução 1
1.1 Objetivosda Dissertação . . . 5
1.2 Es opo e Relevân ia . . . 5
1.3 Estrutura daDissertação . . . 6
2 Reúso de Software 7 2.1 Reúso de Software eSuas Abordagens. . . 7
2.2 Atividades de Reúso de Software . . . 10
2.3 Reúso de Modelos . . . 12
2.4 Atividades de Reúso na Modelagem Formalde Sistemasde Software . . 13
2.5 UmaSoluçãoPara Reúso Sistemáti o de Modelos . . . 16
2.5.1 Métodopara Armazenar Modelos Reusáveis . . . 17
2.5.2 Té ni a para Re uperar Modelos Reusáveis. . . 19
3 Con eitos Bási os 21 3.1 Redes de Petri . . . 21
3.1.1 Redes de Petri Coloridas . . . 25
3.1.2 ODesign/CPN . . . 28
3.1.3 Introdução Informala Redes de Petri Hierárqui as. . . 28
3.2 Veri ação Automáti ade Modelos . . . 30
3.2.1 Lógi a Temporal . . . 31
3.2.2 Lógi a TemporalRami ada -CTL . . . 33
4 Solução de Reúso de Modelos em Redes de Petri Coloridas 38
4.1 OCenário de Reúso de Modelos . . . 38
4.2 OMétodode Armazenamento . . . 42
4.3 Construindoo Repositórioe Armazenando Modelos . . . 45
4.4 A Té ni a de Re uperação . . . 50
4.5 Usando aTé ni a de Re uperação . . . 52
4.6 ObservaçõesAdi ionais . . . 55
4.7 Categorização doTrabalho de Reúso . . . 56
4.8 Sumário . . . 57
5 Con lusão 58 5.1 Trabalhosrela ionados . . . 58
1.1 Esquema doModelo Cas ata de Produção de Software. . . 2
3.1 Ilustraçãodo sistemado jantar dos lósofos. . . 22
3.2 Rede de Petri Lugar/Transição,modelo do jantardos lósofos. . . 23
3.3 Modelo em redes de Petri Coloridas dojantar dos lósofos. . . 27
3.4 Exemplode uma h pn om duas páginas. . . 29
3.5 Visãointuitivada semânti a dos operadores temporaisdas LTL. . . 32
3.6 Visãointuitivada semânti a dos operadores CTL. . . 34
3.7 Modelo CPN daversão venenosa dojantardos lósofos. . . 37
4.1 Junções dosistema de tro a de omposições de trens. . . 39
4.2 Modelo CPN de uma pilha de dados. . . 40
4.3 Modelo CPN de uma lade dados. . . 41
4.4 Sistema exível de manufatura om 4 élulas. . . 42
4.5 Esquema ilustrativo das etapas ne essárias a riação dorepositório. . . 45
4.6 Modelo CPN doíndi e dorepositório.. . . 46
4.7 Nóde de laraçõesglobal dorepositório.. . . 48
4.8 Modelo do domíniode estruturas de dados. . . 49
4.9 Modelo CPN dapilha armazenada norepositório. . . 51
4.10 Esquema ilustrativo de uma sessão de uso daté ni a de re uperação. . 53
2.1 Exemplode relaçãoentre fases domodelo as atae atividadesde reúso
Introdução
AEngenhariadeSoftware omodis iplinaquetratademétodos,ferramentaseté ni as
para tornar aprodução de sistemas de software nan eiramente e iente [
Cle95 ℄
, teve
seu berço na onferên ia daOTAN 1
que levou o seu nome em1968 ujo objetivo era
debater possíveissoluçõespara a hamada rise de software -termo também unhado
por o asião doevento.
Neste evento, entre as soluções propostas, surgiu a da riação de uma indústria
de software que tornasse o pro esso de desenvolvimento de software uma atividade
previsível e nan eiramente viável, através do uso de pro essos de desenvolvimento
similaresaos de outras dis iplinasde engenharia bem estabele idas.
O prin ípio que norteia a solução supra itada é o reúso de artefatos de software
espe ialmente onstruídos de forma a permitir que o desenvolvimento de novos
siste-mas de software não seja feito sempre do zero, mas sim através da omposição de
artefatos pré-fabri ados. Neste ontexto, o on eito de reúso de software foi de nido,
maisespe i amentenoartigodoM Illroy [
M I69 ℄
propondoa riaçãodessa indústria
de software apa itada a produzir, em massa, artefatos de software reusáveis, então
hamadosde omponentes de software.
Passadosmaisde30anos apósessa onferên ia,diversos esforçosdepesquisa
inves-tem noreúso de software omo objetivode melhoraros pro essosde desenvolvimento
de sistemasdesoftware
[Kru92;MMM95℄.
De fato,hojeper ebe-se quemétodos e
té -ni as de reúso de software en ontram-sedisseminados entre diversas fases dopro esso
1
de desenvolvimento de sistemas de software om o mesmo objetivo mas atuando em atividadesdiferentes.
Viabilidade
Análise de
Requisitos
e Especificação
Projeto e
Especificação
Codificação e
Teste de Módulo
Entrega
Manutenção
Estudo de
Teste de Sistema
Integração e
Figura1.1: Esquema doModelo Cas ata de Produçãode Software.
Considere por exemplo o modelo as ata lássi o de i lo de vida do pro esso de
desenvolvimento,ou pelomenos a variante deste dis riminadaem fases omo des rito
em [
GJM91 ℄
eilustrado na Figura1.1. Observe que em ada fase daprodução de um
sistemade software um artefatodiferente(espe i ação, modelos, des rição
arquitetu-ral,esquemasdeteste, ódigo-fonte)étrabalhado,eque adaumdestesartefatospode
ser objeto de reúso dependendo da atividade de desenvolvimento em questão
[Fre83℄.
Nãohárestrições,tudo queéresultadode esforçosde desenvolvimentoanteriorespode
ser reusado nointuito de melhoraropro esso de produçãode novos sistemas.
Entretanto, é omum observar-se na literatura e pelas práti as de mer ado que
o fo o prin ipal dos esforços de pesquisa e desenvolvimento em termos de té ni as e
métodos de reúso, está na fase de implementação, reusando ódigo fonte ou objeto.
Porém, outras fases do pro esso podem prever atividades de reúso dos artefatos de
pro esso de desenvolvimento de software é o uso, bastante divulgado tanto na
omu-nidade a adêmi a quanto na indústria de software, de padrões de projeto
[GHJV94℄.
Na fase de projeto e de nição daarquitetura de um sistema ujo pro esso segue uma
metodologia orientada a objetos, essa té ni a promove o reaproveitamento do
onhe- imento espe ialista a er a de soluções arquiteturais para problemas re orrentes de
projeto. Neste enário,oobjetode reúso são asdes riçõesde soluçõesorganizadas em
um sistema de padrões.
Enfatizando a fase de projeto, onde atividadesde modelagem de sistemas de
soft-waresãoapli adas,métodoseté ni asdereúsopodemserintroduzidos omosmesmos
propósitos da fase de implementação. Neste aso, o objeto de reúso são os modelos
do sistema. Nos asos em que linguagens formais são usadas na modelagem, o
ob-jeto de reúso são modelos sobre os quais propriedades desejadas no omportamento
do sistema podem ser veri adas através de métodos de análise e simulação [
Gar94;
GD90℄.
O uso de métodos formaisnopro esso de desenvolvimento dessessistemas de
soft-ware ajuda na dete ção de in onsistên ias e falhas no projeto de sistemas antes que
estas possam ausar grandes perdas nan eiras ou mesmo de vidas humanas. Tais
ferramentas e métodos embasados emmatemáti a são extremamente úteis quando se
bus agarantirummaiorgraude on ançanofun ionamentodeumsistemadesoftware
quando implementado.
Quando os sistemas de software são omplexos 2
, as de isões de projeto
tornam-se mais difí eis. E quanto mais difí eis são essas de isões, mais extensos e difí eis
de manipular os modelos matemáti os se tornam. Té ni as de abstração ajudam a
ompreender e tratar modelos extensos,mas nem sempreajudam a reduziro tempoe
oesforçode onstruçãodemodelosparanovossistemas. Paratanto,té ni asemétodos
de reúso são mais adequados para auxiliar na onstrução de novos modelos a partir
de partesde modelosexistentes quesintetizamesforços bemsu edidos emmodelagens
anteriores.
Com efeito,assim omoo reúsode ódigo promoveumamelhorianafasede
imple-mentaçãoatravés damudançade ênfase doengenheiro, da odi ação paraintegração
[
Cle95 ℄
,oreúsodemodelospodepromoveradiminuiçãodoesforçode modelagem, om
onseqüentemelhoriade desempenhonas tarefas realizadasnafasede projeto,através
doaproveitamentode esforços de modelagemanteriores.
No universo de problemas tratados pela engenharia de software, a lasse de
pro-blemas que éfo alizadaneste trabalhoé a modelagemde sistemas distribuídos e
on- orrentes. Devido à sua adequação à tarefa de modelagem de tais sistemas
[Mur89℄,
o método formal es olhido neste trabalho são as Redes de Petri Coloridas (Coloured
Petri Nets CPN)
[Jen92℄.
As Redes de Petri são uma ferramenta matemáti a, espe ialmente apropriadas à
des rição e ao estudo de sistemas de software on orrentes, assín ronos, distribuídos,
paralelos,não-determinísti os e/ou esto ásti os [
Mur89 ℄
. As Redes de Petri Coloridas
são redes de Alto Nível uja ara terísti a prin ipal é a in orporação da teoria de
tipos de dados. Tal ara terísti apermite arepresentação de informações omplexas,
desta forma, promovendo a des rição mais ompa ta de modelos. No Capítulo 3 são
apresentados os on eitos de Redes de Petri relevantes ao ontexto desta dissertação.
Otrabalhodemodelagemdesistemasdesoftware emRedesdePetri omauxíliode
omputadores é suportado por alguns ambientes, dentre esses vale itar o PEP
(Pro-grammingEnvironmentBasedonPetriNets)
[Gra95;Gra97℄
eoDesign/CPN
[CJK97℄.
Ambosauxiliamnaediçãográ aeanálisedemodelos,entretantonãodispõemde
me- anismosque suportemo reúso automáti o de modelos des ritos utilizandotais
ambi-entes. Atualmente,oprojetistaéforçadoareaproveitarosseus modelosexportando-os
de projetos anteriores e importando-os nos novos, práti a pou o adequada quando o
tempopara on lusão da modelageméum fator ríti o.
Dentre osdois ambientes itados,apenasum suportaotrabalho omaextensãode
Redes dePetri queseadequaaoes opodestetrabalho: o Design/CPN.Este ambiente
éformadoporum onjuntodeferramentaparaodesenvolvimentodemodelosdeRedes
de Petri Coloridas. Umafun ionalidade de parti ular importân iapara este trabalho
é apossibilidade de riar uma hierarquiade modelos,o que éuma fa ilidade sintáti a
1.1 Objetivos da Dissertação
Este trabalho tem omo objetivos prin ipais o estudo e apli ação dos prin ípios de
reúso de software na modelagem de sistemas de software omplexos, on orrentes e
distribuídos utilizandoRedes de Petri Coloridas.
Como onseqüên iadoestudotem-seumapropostade soluçãodereúsode modelos
CPN que serve omo prova de on eitos. Essa soluçãoé omposta por um métodode
armazenamento de modelos CPN em um repositório e uma té ni a para re uperação
destes, implementadas na ferramenta Design/CPN. O método e a té ni a têm omo
propósitoauxiliaroprojetistana onstruçãodenovosmodelosCPN,promovendomaior
e iên ia para a tarefa de modelagem formalde sistemas omplexos de software.
1.2 Es opo e Relevân ia
Neste trabalhorelata-seum estudosobre oreúsode software nafasede modelagemde
sistemas omplexosde software, de a ordo omoque foide laradonos objetivos. Este
estudosenorteou peloobjetivode ofere erme anismosde reúso de modelosemRedes
de Petri Coloridas.
A es olhade Redesde Petri omoformalismosedeu devidoasua boaadequação à
modelagemde sistemas omplexos e on orrentes, bem omo aexistên ia de uma boa
ferramenta de suporte a modelageme análisede taissistemas.
Paraaté ni adereúsoestabele ida,assume-sequeasbus aspormodelosresultam
emsu essoquandoo onjuntode propriedadesque osdes revemsão atendidas(algum
artefato é modelo das espe i ações de laradas). Esse ritério de bus a possibilita a
seleçãodemaisdeum andidatoaoreúso,emborahajasempreapossibilidadede haver
uma seleção exata, apenas um andidato seja sele ionado.
Éimportanteobservarqueéne essárioanotarosmodelosformalmente,porexemplo
visando parametrização, desta forma promovendo a integração automáti a desses em
projetos emdesenvolvimento.
A importân iadestetrabalhoestánaintroduçãodaapli açãode me anismos
siste-máti os de reúso de software na modelagemde sistemas emRedes de Petri Coloridas
ontexto de reúso de software, parti ularmentenafase de modelagem, omoatividade
prin ipale não omo suporte matemáti oao reúso automáti ode ódigo.
Destaforma,bus a-se ontribuirpara oestabele imentodemétodos eté ni as que
promovamum aumentode produtividade nopro esso de desenvolvimentode sistemas
desoftwareatravésdaintroduçãodeme anismosdereúsonafasedemodelagemformal
de tais sistemas.
1.3 Estrutura da Dissertação
Esta dissertação está organizada omo apresentado a seguir: no Capítulo 2 o tema
reúsodesoftwareédis utidoeotrabalhosituadonoes opomaisespe í odereúsode
modelosCPN. NoCapítulo3sãointroduzidosos on eitosne essáriosaoentendimento
dasolução de reúso de modelos CPN.
No Capítulo4, asoluçãode reúsoé detalhada om auxíliode umexemplo ealguns
aspe tos sobre a implementação do métodoe da té ni a que promovemreúso de
mo-delos CPN são levantados de forma mais elaborada. No Capítulo 5 são apresentadas
Reúso de Software
Neste apítulo, trata-se de reúso no ontexto dos pro essos de desenvolvimento de
sistemas de software. Os benefí ios da adoção de práti as de reúso são eviden iados,
bem omo as abordagens de reúso mais onhe idas e algumas de suas lassi ações.
Neste ontexto, aborda-se um es opo mais espe í o de estudo sobre à apli ação de
reúso,queserestringeafasedeprojeto,espe i amente omrelaçãoaousodemétodos
formaisna onstrução de modelosde sistemas de software.
2.1 Reúso de Software e Suas Abordagens
A onferên ia patro inadapelaOTAN 1
no ano de 1968 emGarmis h,
[NE68℄
onde se
dis utia omo tornara atividadede desenvolvimento de sistemas de software mais
e - ienteemtermosde ustosemaisprevisívelquantoaotempode on lusãodeprojetos,
é geralmentea eita omo oberço daengenharia de software [ Kru92 ℄ . Nesta onferên- ia, M Ilroy [M I69℄
sugeriu a riação de uma indústria de omponentes de software
reusáveis, primeiramençãoao reúso sistemáti o de software.
Entretanto, é interessante observar que, histori amente, a preo upação om reúso
desoftwaretemraízesanterioresaonas imentodaengenhariadesoftware. Jáem1950,
omo observa Wegner
[Weg89℄,
en ontram-se preo upações om o desenvolvimentode
bibliote as de sub-programas e, pou os anos mais tarde, observa-se o
desenvolvimen-to de linguagens de alto nível, a exemplo de Fortran, que permitiam a de nição de
1
abstraçõesde programaçãotais omofunções epro edimentos parametrizáveis.
Reusar esforços bem su edidos, não importa de que natureza, é e onomizar
tempo e trabalho om onseqüente aumento de produtividade [
Nei94; MMM95;
HM84℄.
Essa é uma máxima que tem guiado muitos esforços de pesquisa na bus a
por melhores práti as de desenvolvimento de sistemas omplexos 2
de software nestas
últimastrês dé adas
[Hem96; Kru92℄.
Emseguida apresentam-se, omo exemplo, dois
asos em queoreúsode software tem propor ionado larosbenefí iosaos pro essosde
desenvolvimentode sistemasde software omplexos.
Como primeiro aso, a generalização e reúso de boas soluções para problemas de
projeto quese repetem,reduz otempode on lusãoe o númerode possíveisfalhasno
sistema ausadas porde isõesarquiteturaiserradas [
GAO95 ℄
. Édisso quetrataa
apli- açãode padrõesde projeto
[GHJV94℄,
éoestado-da-arte emtermosde onhe imento
espe ialista sobre projeto arquitetural de sistemas de software planejados de a ordo
om metodologias orientadas a objetos. Observe que o ponto entral em padrões de
projeto éo reúso de onhe imentoespe ialista sobre projetosorientados aobjetos.
Um segundo aso é o reúso de ódigo fonteou objeto. Esta práti a pode diminuir
signi ativamente otempo de odi ação de um sistema de software, ou parte dele, e
torna menos provável que erros de programação sejam introduzidos na fase de
imple-mentação. Épou oprovávelqueum ódigodefeituososejapropagadoatravésdoreúso
aolongo dotempo (émais provável que este ódigo aia emdesuso).
Essa práti a de reúso é presen iada sob diversas formas, através de omponentes
de software, ondeo reúsoé feitode formaestanque, ouseja, ódigo éreusadosem que
se onheça os seus detalhes de fun ionamento interno, o seu ódigo fonte. Reúso de
ódigosob aformade frameworks,onde ódigofonteé reusadoatravésde me anismos
de herança emabordagens orientadas aobjetos neste aso, o reúsotambémimpli a
naaderên ia à arquitetura de sistemaimplí itaao framework.
Os enários de reúso des ritos a ima são apenas dois dos exemplos mais notórios
emque a práti a de reúso tem um históri ode bons resultados. Pode-se ainda reusar
espe i ações, requisitos oletados, arquiteturas de sistemas, pro essos, algoritmos e
tudo mais que façaparte dopro esso de desenvolvimento de sistemas de software. De
fato, não há restrições quanto ao artefato que se pode reusar, o que determina sua
es olhaé a ne essidade ea fase de desenvolvimentoem questão.
En ontra-seumaliteraturari anaáreadereúsodesoftwarenosentidode lassi ar,
de isolarpara ompreender asdiferentes abordagens dereúso. Algumas on entram-se
em identi ar que artefato é reusado e outras tentam onfrontar atividades de reúso
emum nívelmais abstrato.
Em um dos levantamentos sobre a literaturade pesquisa na área de reúso de
soft-ware,Krueger
[Kru92℄
parti ionaasdiferentesabordagens dereúsoemoito ategorias 3
edis ute adaumadelassob quatropontos deuma taxonomiaqueele onsideraserem
omuns a todas as ategorias: abstração, seleção, espe ialização eintegração.
Ainda de a ordo om Dusink [
Dus92 ℄
, reúso não é feito no vá uo mais sim em
algumlugarentreas in odimensõesdis riminadasemeixosortogonais: transformação
versus omposição, aixa-preta versus aixa-bran a,nívelde abstração, produto versus
pro esso e, nalmente, onstrução de artefatos reusáveis versus apli açãode artefatos
reusáveis.
Do pontodevistametodológi o,éfundamentalnotarqueospro essosde
desenvol-vimentode software baseadosemmodelosde i lode vida,impli itamente, onsideram
queo desenvolvimento de um novo sistemade software sempre omeçadaesta a zero.
Entretanto, é possível adaptar os modelos existentes para que suas fases in orporem
atividadesespe í asaodesenvolvimento de software om reúso. Assim, opro essode
desenvolvimento omo um todo pode se bene iar de té ni as, métodos, ferramentas
e ambientes opera ionais onde o reúso de artefatos é sistematizado e auxiliado por
omputador (automatizado).
Háalgunstrabalhos de pesquisaemquetodoummodelode i lo de vidade
desen-volvimento baseado em reúso foi elaborado [
DV94 ℄
. Nesses, em ada fase do i lo de
vida estão previstas atividades espe í as de reúso. Considere por exemplo, algumas
atividades de reúso asso iadas a fases do modelo as ata de pro esso de
desenvolvi-mentode software. O resultado éo enário apresentado naTabela 2.1.
3
Linguagensdealtonível,prospe çãode ódigoedesign, omponentesem ódigo-fonte,esquemas
de software, geradores de apli ações, linguagens de mais alto nível, sistemas de transformações e
Fases do Projeto Atividades de Reúso
Análise Reúso de requisitos
Projetoe Espe i ação Reúso de de isões de projetos (padrões de projetos) e
reúsode espe i açõesformais
Codi ação e Teste de
Módulo
Reúso de ódigo fonte e/ou de ódigo objeto
Tabela 2.1: Exemplo de relação entre fases do modelo as ata e atividades de reúso
asso iadas.
O enário exempli ado na Tabela 2.1 embora puramente ilustrativo, é útil para
identi ar algumas das possíveis atividades de reúso, em orrespondên ia direta om
as fases nas quais se inserem dentro do ontexto de um modelo de i lo de vida para
desenvolvimentode software om reúso. É óbvio que não ontempla todas as fasesdo
modelo as ata de i lo de vida. Para uma visão mais detalhada de um modelo no
qualatividadesde reúsoforamin orporadasemtodas asfasesvejaado umentaçãodo
projeto REBOOT [
DV94 ℄
.
Como visto, háum espe tro bastanteamplo para o estudo dainserção de práti as
de reúso de software nos pro essos de desenvolvimento de software. A próxima seção
trata da identi ação das atividades rela ionadas ao reúso de software e alguns dos
per alços quesurgem emfunção dessas atividades.
2.2 Atividades de Reúso de Software
Generi amente, pode-se identi artrês atividadesque, re orrentemente, estão
presen-tes em qualquer fase de um pro esso de desenvolvimento que in orpore reúso omo
práti a. São elas: armazenamento de artefatos reusáveis, re uperação de artefatos
reusáveis eintegração dos artefatos re uperados om ousem adaptação.
Considerando tais atividades, é omum en ontrar-se situações onde se pressupõe
a existên ia de artefatos onstruídos que possam ser reusados quando ne essário for
artefatosreusáveisequem desenvolvaapartirdeartefatosreusáveis. Emboranãohaja
desenvolvimento baseado em reúso sem desenvolvimento para reúso, neste trabalho
fo aliza-se a segunda atividade, ou seja, a onstrução de novos produtos de software
a partir de artefatos já onstruídos e bem usados sem, entretanto, negligen iar as
atividadesde armazenamentode artefatos.
Neste sentido, duasdas atividadesre orrentes itadasnoiní io destaseção
interes-sam mais parti ularmente: omo armazenar e omo re uperar artefatos reusáveis. A
integração pode ser deixadaem segundo plano neste primeiromomento.
Re uperar artefatos de software om e iên ia não é uma tarefa fá il, depende
do quão e ientemente pode-se de larar o que se quer re uperar e omo a bus a por
artefatos que orrespondamao quese de larou é levada a abo.
Num ontextoinformal,ondenãohá omode larar ompre isãooquesebus a,por
exemplo emum repositório FTPde programas, opro esso de bus a é feitoatravésda
identi ação dos andidatos através dos seus nomes que podem ser extremamente
inexpressivos tornando a bus a frustrante. Já no enário de bus a por uma função
em uma bibliote a de funções, dispõe-se das assinaturas das funções, dos seus tipos
de larados através dos parâmetros formais. Tais informações são de grande valia,
muito embora não seja garantia de queo quese deseja érealmente oque seobtevena
bus a.
Não há garantias mesmo om as de larações de tipos da assinatura, pelo simples
fato de que uma informaçãopuramente sintáti a sobre um artefato é insu iente
pa-ra de larar o que ele faz. Considere por exemplo uma bus a por um artefato que
implementeuma pilha de números inteiros emuma bibliote ade funções.
Ao de larar-se que oartefato alvoda bus a possui duas operações bási as,
respe -tivamentearmazenar e re uperar um número inteiro, espera-se ter des ritoo
ompor-tamentode umapilha de inteiros. Porém,ter-se-iatãosomentebus ado porquaisquer
artefatos que implementem um agregado de dados do tipo inteiro. Como resultado,
poderia-seobterum artefato queimplementeuma laenão uma pilha, queé um
des-fe ho perfeitamentea eitável emvistado quefoi de larado, porém sem utilidadepara
Váriaspesquisas rela ionadasaos problemas de re uperar ódigo para reúso,ou omo
queiram, omponentes desoftwareparareúso, apresentamesforçosnatentativaanotar
formalmente ódigo, ou seja, enrique er omponentes de software om des rições
ma-temáti as deseus omportamentosdeformaadisponibilizarmaioresgarantiassobreo
que re upera [ ZW93; ZW95b; FS97 ℄ . 2.3 Reúso de Modelos
Na fase de projeto de um sistema de software, a onstrução de um modelo formal
do sistema sendo desenvolvido pode ser on luído mais rapidamente aso o projetista
disponha de partes de modelos anteriores que possam ser reusados e ientemente no
projeto em andamento. Neste ontexto, a bus a por tais modelos reusáveis pode ser
muito mais e iente que uma simples prospe ção de pedaços de modelos dentro de
projetos inteiros já on luídos. Isso se deve ao fato do artefato objeto de reúso se
tratar de um modelo matemáti o que pode ter o seu omportamento investigado de
formaautomáti a, fatoeste quefa ilitabastanteo reúso.
Qualquer projetista que já tenha opiado e olado seus próprios modelos de um
projeto para o outro é um usuário em poten ial de uma té ni a ou método ou
fer-ramenta de reúso de modelos. É muito práti o guardar esforços de modelagem que
poderão fa ilmente ser reaproveitados num próximo projeto. Essa rença é reforçada
pela práti a de modelagem e ensino experimentada pelos pesquisadores e professores
integrantes doLaboratóriodePesquisaemRedesdePetri(Labpetri)doDepartamento
deSistemaseComputação,CampusIIdaUniversidadeFederaldaParaíba,eéapoiada
pelodesenvolvimentode uma té ni ae um métodoque serãodes ritos emdetalhes no
Capítulo4.
O reúso de modelos formais não é uma idéia inteiramente nova, sendo possível
en ontrar alguns trabalhos que, direta ou indiretamente, on orrem para adoção de
práti asde reúso nas atividades de modelagemformalde sistemasde software.
Trabalhos rela ionados a introdução de on eitos e me anismos de orientação a
objetos em Redes de Petri, são passos importantes em direção ao reúso de
LHCB98 ℄
, alguns deles desenvolvidos dentro do ambiente de pesquisa do Labpetri
[Gue97; SCP98℄.
Em outro trabalho, questões de reúso são abordadas através da
proposta de desenvolvimentode um sistema de padrões de modelos de Redes de Petri
[NJ99℄,
similar ao on eito de padrões de projeto, a idéia é generalizar soluções de
modelagememRedes de Petri para reúso sistemáti o posterior.
Contudo, ostrabalhos supra itadosembora diretamenterela ionados,promovemo
reúsodemodelosatravésde métodos quesedenominadereúso aixa-bran a 4
(usode
herança),em ontraposição àabordagemde reúsodeste trabalho,queévoltadaparao
reúso aixa-preta 5
,ondeomodelopodeserreusadodaforma omofoire uperado,sem
que o projetista ne essite fazer grandes alterações. Ainda sim, ambas as abordagens
perten em ao mesmogrupo de idéias epodem ser bemapli adas on omitantemente.
Otipode abordagemdereúso de modelos,ne essita queseidenti que quaisas
ati-vidadesde reúso asso iadasaopro essode modelagemformalde sistemasde software,
e omoestaspodemser desempenhadasdaformamaisautomáti apossível, omvistas
a fa ilitarotrabalhode modelagem. No quesegue, dis ute-se que atividadesde reúso
podem ser integradas ao pro esso de modelagemformale omo apli á-las.
2.4 Atividades de Reúso na Modelagem Formal de
Sistemas de Software
Nafasedeprojetodosistemadesoftware,oprojetistaéoespe ialistaquedetém
onhe- imentosobre oformalismoes olhidopara aquelafasedopro esso de desenvolvimento
e,provavelmente, daslinguagens de programaçãoutilizadas. Assim,é razoávelesperar
que opro esso de onstrução dos modelos dosistemasofra in uên ias dametodologia
de programação, ou do paradigma adotado (orientação a objetos ou estruturado, por
exemplo) bem omo do ambiente no qual o projeto será odi ado (UNIX, Windows,
et ). Estas in uên ias afetam o modo omo omodelo deste sistema é onstruído.
Em um ambiente em que o modelo de um sistema não será desenvolvido do zero,
massimapartirdemodelosreusáveis, omodo omoestemodeloé onstruídoétambém
4
traduçãodotermowhite-box.
in uen iadopelaabordagemde desenvolvimentobaseada emreúso. Logo,oprojetista
muda o fo o da atividade prin ipal que é onstruir o modelo, para a atividade de
montaro modeloa partir de pedaços já onstruídos.
Esta simples mudança de fo o, em si, já impli a em que o projetista deve então
se preo upar em omo bus ar as partes reusáveis de que ne essita para onstruir um
novo modelo. O projetista agora modela por diferença, primeiro ele deve pensar no
quevai onstruir, depoisfragmentarasolução,depoiseledeve seperguntarquepartes
da solução podem já ter sido modeladasanteriormente. Em seguida, elese on entra
em omo des rever os modelos que deseja re uperar para então, de posse de modelos
reusáveisre uperados, on luirseu modelo atravésdaintegração daspartesnovas om
as partesre uperadas.
É fá il per eber que, durante a modelagem de ada novo sistema, um projetista
pode identi ar um bom andidato a modelo reusável e armazena-lo no repositório.
Esta atividade deve ser extremamente en orajada e suportada na fase de projeto por
ser esta a forma pela qual o repositório de modelos reusáveis se torna mais ri o. Tal
atividadepode ser automatizada poruma té ni ade formaafa ilitare sistematizara
evolução do repositório de modelos.
Fi am assim elen adas as atividades de reúso que passam a fazer parte integral
da fase de projeto de sistemas de software, onsiderando a modelagem formal destes
sistemas omo pro esso prin ipal:
1. Identi açãode que onsta o modelo dosistema (identi açãodas partes)
2. Seleção de que partes devem ser onstruídas do zero e que partes podem ser
re uperadas para reúso
3. Des rição ebus a no repositório
4. Integração dos modelos re uperados aoprojetoem desenvolvimento
5. Identi açãodemodelos andidatosaoarmazenamentonorepositóriodemodelos
e in lusãodos mesmos norepositório
atividadeso orremna seqüên iadelineada a ima, entretanto, a atividadede
atualiza-ção dorepositóriopodeo orreraqualquer momentoduranteamodelagemdosistema,
não pres indindo de qualquer passo anterior.
A atividade de re uperação de modelos, mais espe i amente a des rição dos
mo-delos a serem re uperados, requer uma maior atenção para que este texto não pareça
leviano,apresentandoumaenumeraçãodasatividades omosefossemsimpleseóbvias.
Des rever o que se deseja de um modelo formal pode apresentar os mesmos
pro-blemas des ritos na Seção 2.2 om a situação exemplo da bus a por um artefato que
implementeo ontrole de uma pilha de inteiros numa bibliote ade funções. É
ne es-sário determinar-se om lareza o nível de pre isão om que a bus a por um modelo
vai o orrer.
Pode-seterumabus aemqualquerdosníveisextremosaseguir. Podesersu iente
apenas uma bus a feita om base em informações sintáti as sobre o modelo (uma
sentença de bus a que só avalie ritério sintáti os) ou, no outro extremo, pode ser
interessante re uperar apenas os modelos que atendam a restrições omportamentais
(semânti as) equivalentes à própria des rição total do modelo desejado, ou seja, o
própriomodelo des rito nasentença de bus a.
Ambosos extremos são indesejados, noprimeiro aso ( ritériospuramente
sintáti- os)não há omo garantirqueo quesere uperou éoquesedeseja reusar. Nosegundo
aso (bus a por equivalên ia omportamental, ou semânti a), pode-se ter a situação
emque alinguagem usada para es revera sentença de bus a seja amesma linguagem
usada para modelar o sistema, isso pode resultar na onstrução total de um modelo
para are uperação de outro idênti o dorepositório.
Tal situação omo des rita pelo segundo aso é pou o provável em virtude das
linguagens de espe i ação orientadas a modelos (Redes de Petri e grafos de estado,
por exemplo) não serem adequadas a des rição de propriedades, oque notadamenteé
oes opodas linguagens de espe i ação orientadas ade larações(Lógi as, Álgebrase
Expressões Quanti adas, por exemplo).
Assim, as bus as devem ser realizadas sob ritérios que estejam a meio aminho
bus a,maisoprojetistades reveráomodelodesejado. Aes olhadesteníveldepre isão
nare uperaçãode modelos pode impa tarnodesempenhodare uperação, onerandoa
apli açãode práti as de reúso no pro esso de modelagem.
Por outro lado, o relaxamento do ritério de bus a tem re exos diretos nas
ativi-dadesde integração dos modelosre uperados. Casoomodelo resultantesejaresultado
de uma bus a mais relaxada, om uma des rição par ial 6
, é bastante provável que o
modelo re uperado ne essite de um grande número de alterações manuais para ser
nalmenteintegrado om su esso aomodelo emdesenvolvimento.
Um aspe to interessante que não pode ser identi ado tão laramente, quanto as
atividades de reúso elen adas anteriormente, é o fator ultural. A apli ação de
prá-ti as de reúso em fases ini iais do i lo de desenvolvimento de sistemas de software
propor ionaobenefí io olateral de institu ionalizaroreúso desde muito edo nafase
on epção do sistema [
Tra95 ℄
. É a introdução de uma ultura de reúso que torna a
produçãode sistemasde software uma atividade om aráterde engenharianosentido
próprioda dis iplina.
Aseguir,tem-seumades riçãodospontosaserem onsideradosnodesenvolvimento
de uma soluçãode reúso de modelos formais. Asolução des ritasegue osprin ípiosjá
introduzidose é uma guia para a implementação des ritaem detalhes noCapítulo 4.
2.5 Uma Solução Para Reúso Sistemáti o de Modelos
Nesta seção dis ute-se omo os prin ípiosde reúso de software podem ser apli adosa
fase de projeto onde uma visão da arquitetura do sistema é traçada. De a ordo om
o que foi exposto nas seções anteriores, uma boa prova de que o reúso de modelos
pode ser apli ado om su esso seria a existên ia de pro edimentos sistemáti os para
armazenamentoe re uperação de modelos.
Assim, a seguir, apresenta-se uma solução de reúso suportada por um método de
armazenamentode modelosformaisdes ritos em Redes de Petri Coloridas, bem omo
de uma té ni a para re uperaçãode modelos de formaautomáti a baseada naté ni a
6
Porpar ialqueremosdizerqueasentençadebus a onstadeapenaspartenasrestriçõesdesejáveis
de Veri ação Automáti a de Modelos. Ambos, a té ni a de Veri ação Automáti a
de Modelos bem omo o formalismode Redes de Petri são des ritos Capítulo3.
2.5.1 Método para Armazenar Modelos Reusáveis
De modoa ilustraro método, onsidere asituação de uma riança brin ando om um
dosbrinquedos maispopularesdomundo: osblo osLego. Esta riançare onhe euma
oleção de ara terísti as que um objeto do mundo real tem, por exemplo uma asa,
e tenta imitar em es ala reduzida aquele objeto usando os blo os Lego. Se
prestar-mos bem atenção, o mesmo blo o que já foi parte de uma maquete anterior é usado
novamenteem um ontexto diferenteporém similar.
A situação supra itada guarda forte analogia om as práti as de projeto de
enge-nharias bem estabele idas omoa ivil e elétri a,onde os engenheiros trabalham om
esquemasmatemáti osquerepresentam as onstruçõesfundamentais. Apenas,por
se-rem do umentos matemáti os, estes esquemas podem ser estudados, analisados e/ou
simulados de formaa ofere er garantias sob o omportamento dos objetos reais antes
mesmo de sua onstrução.
No ontextodeusodeRedesdePetri omoumalinguagemadequadaparaa
onstru-ção de modelos matemáti osde sistemasde software, osblo os Lego são, na maioria
das vezes, as onstruçõesbási as dalinguagem,que serãoapresentados noCapítulo3.
Todavia, issonão é uma tautologia. Pode-se formar blo os fundamentaistão mais
omplexosquantosedesejare, omesses, onstruirmodelosbastantegrandesde forma
mais e iente. Para tanto, após identi ados esses blo os, deve-se ter uma forma
sistemáti adeguarda-losparausofuturo(reúso),umaformasistemáti adere uperaro
blo oadequadoaumane essidadeespe í aeumaformadeintegra-losaonovomodelo
que se deseja onstruir. Não é ne essário, ontudo, que estes blo os sejam de uma
granularidadepre xada,oumesmoquesejampadrão. Cadaprojetistapodere onhe er
os seus blo os reusáveis dentre os modelosque onstrói emdomíniosespe í os.
O estabele imento de regras para o armazenamento desses blo os, que doravante
serão hamadosde modelos reusáveis, deve preverasatividades posteriores de
Os modelos reusáveis devemser organizados emuma hierarquia que re ita uma
separaçãode domíniosde onhe imento(estruturasde dados, algoritmosde
oe-rên iade a he,proto olosde omuni ação,et ). Destaforma,oespaçodebus a
pode ser reduzido.
Umapadronização,baseada nodomínio,dos nomesusadosnosmodelosreusáveis
armazenados. Isso permite a parametrização da bus a, tornando-a passível de
automatização.
Asinformaçõesdos tiposde dados ontidasnomodelo devemserarmazenadade
formaa serem fa ilmentea essadas posteriormente. Isso fa ilita ospro essos de
integração dos modelosque eventualmente foremre uperados.
Omodelodeveserarmazenado ominformaçõesadi ionaissobre omoeste pode
ser utilizado,um aso de uso. Isso temduas nalidades, aprimeiraé auxiliarna
re uperaçãoatravésdainformaçãodoqueumambientedeveesperardo
ompor-tamentoexterno de um modelo. A segunda nalidadeé forne er um exemplode
usode formaaauxiliaroprojetistanomomentodeintegraromodelore uperado
noprojeto em onstrução.
Não se tem a pretensão que os prin ípios apontados a ima sejam de apli ação
ge-ral para o desenvolvimento de métodos ou té ni as de armazenamento de modelos
reusáveis. Essas são asguias queforamutilizadaspara onstruir um métodode
arma-zenamentode modelos emRedes de Petri ColoridasHierárqui as.
Seguramente, essas guias são in uen iadas enormemente pelas ara terísti as da
linguagem(tipos de dados omplexose o on eito de hierarquia), bem omopelas
res-triçõesfun ionaisdaferramentadeRedesdePetriadotada: oDesign/CPN,ferramenta
que será des ritano Capítulo3.
Os detalhes de implementaçãoque envolvemopro esso de armazenamento de
mo-delosCPNsão detalhadosnoCapítulo4,ondeum enáriode reúsode modelosé
apre-sentadoenele ométodode armazenamentoéilustrado. Aseguir, des reve-se de forma
2.5.2 Té ni a para Re uperar Modelos Reusáveis
Aatividadede bus aporummodelo,dea ordo om ertos ritériosentre uma oleção
demodelosarmazenados,apresentaalgumasdi uldades,porexemplo, omodes rever
as propriedades desejadas do modelo, ou omo pro eder a bus a por andidatos a
re uperação. No aso de Redes de Petri, a explosão dotamanho doespaço de estados
que representa o omportamento de um modelo é geralmenteo maiordos problemas.
Desta feita,enumera-se aquiasguias de uma té ni apara re uperar modelosCPN
Hierárqui osobservando ane essidade de eliminaroureduzirosproblemasintrínse os
aessa atividade, bem omose bene iandodaforma riteriosa om aqual osmodelos
foramarmazenados. Assim éimportante:
Usarumalinguagemadequadaades rição depropriedadesdos modelos(no aso
modelos CPN). Esta linguagem deve ser passível de integração om Redes de
Petri Coloridasde formaapermitir automatizaçãodopro esso de veri ação de
propriedades.
Permitirqueumprojetistainforme,interativamentedepreferên ia,aquedomínio
suabus airáserestringir. Énestemomentoqueaferramentade ediçãoeanálise
de CPNs hierárqui as omeça a in uen iar na usabilidade da té ni a, quanto
maioresforemasfa ilidade de interação om ousuário tantomais práti oefá il
será o uso daté ni a.
Veri aras propriedades des ritas ontraos modelos armazenados de forma
au-tomáti a. Nestemomento,osmodelosdevempoderser parametrizadosde forma
que a mesma fórmulapossa ser veri ada para os diversos modelos de nidos no
mesmo domínio. É nesta atividadeonde a padronização dos nomes exigida pelo
métodode armazenamentoé de maiorimportân ia.
Possibilitar que os modelos sejam exportados juntamente om os seus tipos de
dados asso iados em arquivos espe í os de forma que estes possam ser usados
emuma etapa posterior de integração.
apítuloédes reverde formabastantesu intaosmétodos, aslinguagens,asté ni as e
ferramentasne essárias a ompreensãodasoluçãode reúsode modelosproposta neste
Con eitos Bási os
Neste apítuloestão des ritos os on eitos bási os mais importantes ao entendimento
dorestantedestetrabalho. Primeiramente,serãointroduzidasasredesdePetri,
forma-lismobasedestapesquisa. Emseguida,des reve-se até ni adeVeri açãoAutomáti a
deModelos,usadanaimplementaçãodaté ni ade re uperaçãodemodelosCPN
deta-lhada noCapítulo 4. Finalmente, des reve-se a Lógi a TemporalRami ada (CTL) e
sua variante, o ASK-CTL,usada para des rever propriedadessobre o omportamento
dos modelos CPN.
3.1 Redes de Petri
Os on eitos que serão expostos nesta seção servem apenas a onstrução de uma
ba-se para o entendimento deste trabalho. Aqui, serão apresentadas as redes de Petri
Lugar/Transição e Coloridas, respe tivamente nos ontextos de redes de Baixo e Alto
Nível.
De a ordo om Murata [
Mur89 ℄
, redes de Petri são uma ferramenta matemáti a,
espe ialmente apropriadas à modelagem e ao estudo de sistemas de software
on or-rentes, assín ronos, distribuídos, paralelos, não-determinísti os e/ou esto ásti os. De
fato,asredes de Petri podemser apli adasàmodelagemde qualquer sistema om tais
ara terísti as.
Além de sua notação matemáti a, as redes de Petri possuem uma representação
onstrução de um sistema de software.
Uma rede de Petri é omposta de uma estrutura de rede, ins rições asso iadas a
essa estrutura e uma mar ação. A estrutura da rede e as ins rições de nem a sintaxe
deumaredede Petri. Aevoluçãode suasmar ações,segundo umaregrade o orrên ia,
estabele e a sua semânti a.
Uma estrutura de rede de Petri é uma tripla N =hP;T;Fi,naqual:
P é um onjunto nito de lugares;
T é um onjunto nitode transições;
F P T [T P é uma relaçãode uxo;
P \T =?.
Note que, de a ordo om a relação de uxo F, os ar os da estrutura sempre
o-ne tam nós de tipos diferentes. Gra amente, oslugares da estrutura de uma rede de
Petri orrespondem a ír ulos, as transições a retângulos e a relação de uxo a ar os
dire ionados.
Fil2
Fil3
Fil4
Pal4
Prato de
Arroz
Fil1
Pal3
Pal1
Pal2
Figura 3.1: Ilustraçãodo sistemado jantardos lósofos.
Na Figura 3.1, ilustra-se o lássi o sistema imaginado por Dijkstra onde lósofos
ada lósofo pode estar em um de dois estados possíveis: omendo ou pensando.
Ini- ialmente, todos os lósofos estão pensando e, para que qualquer um deles ome e a
omer, é ne essário que se pegue dois palitos ao mesmo tempo o da esquerda e o
da direita. Na Figura 3.2 ilustra-se o modelo em redes de Petri do jantar posto para
quatro lósofos.
f1Come
f1Pensa
f1SoltaPalitos
f1PegaPalitos
Palito4
f3PegaPalitos
f3Pensa
f3SoltaPalitos
f3Come
Palito3
f4Pensa
f4Come
f4PegaPalitos
f4SoltaPalitos
Palito1
f2Come
f2PegaPalitos
f2SoltaPalitos
f2Pensa
Palito2
Figura 3.2: Rede de Petri Lugar/Transição,modelo do jantardos lósofos.
Em uma rede de Petri, ospontos pretos, hamados has, dentrodos lugares
indi- am o estado em que se en ontra o sistema. Assim, nomodelo do jantardos lósofos
naFigura3.2, as has depositadasnos lugaresf(1)(2)(3)(4)PensaePalito(1)(2)(3)(4)
indi amquetodos os lósofos estão pensando eque todos ospalitos estão em imada
mesa. Esta asso iação de hasaos lugares de umarede hama-semar ação, e
estabe-le e o estadode uma rede de Petri. Embora o exemplode rede de Petri daFigura 3.2
não deixe laro, há dois tipos de ins rições para esta rede de Petri: o peso dos ar os
(que no aso foi suprimidopor ter valorunitário) e a ini ialização, que é a mar ação
ini ial darede.
des de Petri de Petri de Baixo Nível ( omo a Lugar/Transição) as has representam
informaçõesmeramente binárias,indi adas pelasua presença ouausên ia nos lugares.
O omportamento de uma rede de Petri é determinado pelo onjunto de estados
al ançáveisapartir de umamar ação ini ial,pelao orrên iaoudisparode transições.
Um onjunto de regras denominado regra de o orrên ia ou disparo determina
pre isa-mente emque ondições uma transição está habilitadaa o orrer e, quando o orrer, o
que pre isamentea onte e na rede.
Esta regra de o orrên ia pode de nir omo a rede ilustrada naFigura3.2 muda de
estado. Antes porém, de de nir o fun ionamento da regra de o orrên ia, é ne essário
que alguns on eitos bási ossejam estabele idos:
Lugaresdeentrada: lugaresdeondepartemosar osdire ionados(ar osdeentrada)
que hegam auma transição;
Lugares de saída: lugares para ondepartem osar os dire ionados(ar os de saída)
que saem de uma transição.
Veja então, a des rição da regra de o orrên ia para as redes de Petri
Lu-gar/Transição, tipodes rito até omomento:
Umatransição está habilitadaseos seus lugaresde entrada ontiverem has na
quantidade ne essária des ritapelos respe tivos pesos de seu ar os de entrada;
Umatransição pode o orrer aso esteja habilitada;
A o orrên ia ou disparo de uma transição resulta na retirada do número de
has, espe i ado nos ar osde entrada,dos respe tivos lugaresdeentradae,no
depósitode hasnaquantidadeespe i adapelosar osdesaída,nosrespe tivos
lugaresde saída.
Desta forma,observando o exemplo dosistema dos lósofos, nomodelo
apresenta-do pela Figura 3.2, as transições f(1)(2)(3)(4)PegaPalitos estão todas habilitadas no
momento ini ial. A o orrên ia, por exemplo, da transição f1PegaPalitos o asiona a
retirada das has dos lugares Palito1 e Palito4, e o depósito de uma ha no lugar
f1Come.
nórepresentaumamar açãoal ançávele adaar oindi aatransição quedeveo orrer
para al ançar um novo estado a partir de um ante essor. Logo, o grafo de o orrên ia
de uma rede de Petri é uma representação doseu espaço de estados, uma odi ação
doseu omportamento.
Assim, pode-se estudar o omportamento de um sistema modelado om redes de
Petri atravésdaexploraçãodoseu espaçode estados, investigandooseu grafode
o or-rên ia. Observequeeste grafopode ser gerado ompleta oupar ialmente, dependendo
do modelo sendo investigado. Isso se deve aofato de que uma rede de Petri pode ter
in nitosestadosnão interessando assima geração ompletade seu grafode o orrên ia
para propósitos práti os.
3.1.1 Redes de Petri Coloridas
As redes de Petri Lugar/Transição são úteis para a modelagem e estudo de sistemas
bastante simples. Quando a omplexidade dos sistemas a serem modelados aumenta,
surgem algumasrestrições aoseu uso. Entre asrestrições, pode-se itar a ne essidade
de dupli ação da estrutura de rede para modelar pro essos semelhantes ou idênti os.
Issoo orredevidoaofatode ser impossíveldiferen iarospro essospormeiode has.
Dessa forma, visando suprir tais limitações e fa ilitar a modelagem de sistemas
omplexos, extensões foram propostas para as redes da lasse de Baixo Nível. Dentre
elas, tem-sea lasse das redes de Petri Temporais ea lasse das redesde Petri de Alto
Nível. As redes de Petri de Alto Nível ara terizam-se sobretudo pela in orporação
da teoria de tipos de dados. As has para estas redes podem arregar informação
omplexa,que é manipuladapelo uso de umalinguagem.
Ofatodas has expressareminformações omplexasaumentaopoderde des rição
dessas redes e, onseqüentemente, modelos mais ompa tos podem ser obtidos. Essa
exibilidadenamanipulação dainformação permite aoprojetista distribuira
omple-xidade domodelo de um sistema entre as ins rições e a estrutura da rede. Dentre as
redes de Petri de Alto Nível,desta am-se asredes de Petri Coloridas
[Jen92℄.
Uma rede de Petri Colorida ompõe-se de três partes distintas: estrutura,
juntos de ores (domínios), variáveis e operações (funções) usadas nas ins rições. As
ins rições, porsua vez, podem ser de quatro tipos:
1. Cores dos Lugares: determinam a or asso iada ao lugar. Um lugar só pode
omportar has ujosvalores respeitem sua or;
2. Guardas: são expressões booleanasque restringem ao orrên ia das transições;
3. Expressões dos Ar os: servem para manipular ainformação ontida nas has;
4. Ini ializações: asso iadasaos lugares,estabele ema mar ação ini ial darede.
Veja na Figura 3.3, o modelo em redes de Petri Coloridas do sistema dos lósofos
des rito pela rede Lugar/Transição mostrada na Figura 3.2. Observe que as partes
do modelo om estruturas redundantes foram dobradas ompa tando o modelo. Os
lósofos e os palitos foramrepresentados por tiposde dados diferentes através do uso
de has om as ores FIL e PAL. Neste modelo, note que a ins rição que indi a a
mar ação ini ialdolugarPensaé daforma1` l(1) ++1` l(2) ++1` l(3) ++1` l(4),
onde o 1 antes de ada l(...) indi a que há apenas um lósofo deste tipo naquele
lugar. Issoporque omesmo lugarpode onter várias has de um mesmo valor, assim
essas expressões usam multi onjuntos para ins rever os lugares. Um multi onjunto
é um onjunto no qual pode haver repetição de elementos. O leitor interessado nas
de nições formaisde redes de Petri Coloridaspode en ontra-las em [
Jen92 ℄
.
Comopodeser onstatadonaFigura3.3,asins riçõeseasde laraçõesde ores
usa-das na rede são feitasusando-se uma linguagem,neste aso uma linguagemfun ional,
SML'97 [
Ull93 ℄
. Nas de larações abaixo do modelo CPN dos lósofos, en ontram-se
as de nições das ores (tipos) que representam os lósofos (FIL) e os palitos (PAL).
Ambas as ores podem ter elementos nomeados le pal indexadosporinteiros entre 1
en,queno aso é4. Assim, olugarPensapode onter, emum determinadomomento,
osegundo lósofo indi adopelains rição1` l(2) eo lugarPalitos Na Mesa, osegundo
palito indi ado pela ins rição 1`pal(2).A função Palitos riada realiza a retirada dos
palitossituados aesquerda eadireita de um determinado lósofo passado omo
Pensa
FIL
1‘fil(1)++1‘fil(2)
1‘fil(3)++1‘fil(4)
Come
FIL
Pega
Palitos
Solta
Palitos
Palitos
Na Mesa
PAL
1‘pal(1)++1‘pal(2)
1‘pal(3)++1‘pal(4)
val n =4;
color FIL = index fil with 1..n declare ms ;
color PAL = index pal with 1..n declare ms ;
var p : FIL ;
fun Palitos(fil(i)) = 1‘pal(i)++1‘pal(i mod n + 1) ;
p
p
p
p
Palitos(p)
Palitos(p)
Figura3.3: Modelo emredes de Petri Coloridasdo jantardos lósofos.
Assim, asoatransiçãoPegaPalitoso orra ompassumindoovalor l(1)indi ando
que uma ha om este valor esta sendo retida do lugar Pensa, a função Palitos irá
remover duas has da or PAL do lugar Palitos Na Mesa om os valores pal(1) e
pal(4). Em seguida, uma ha de valor l(1) é depositada no lugar Come on luindo
uma mudança de estado darede.
Éimportanteobservarquearegrade o orrên ia(oudisparo)paraasredesdePetri
Coloridasdepende de mais alguns on eitos: variáveisde transição, ligaçãoeelemento
de ligação. As variáveis de transição são aquelas en ontradas nos ar os dire ionados,
porexemplop, queévariáveldatransição PegaPalitos. Umaligaçãoé aasso iaçãode
uma variável de transição a um valorda sua or (ou tipo), omo exemplo de ligação,
pode-seter l
1
=< p=fil(1) >. Um elementode ligaçãoé um par (transição,ligação).
Por exemplo, onsiderando os exemplos supra itados, el
1
= (PegaPalitos;l
1
=< p =
fil(1) >) é um elemento de ligação. Mais uma vez, o detalhamento e formalização
destes on eitos é deixado omoreferên ia aoleitor interessado
3.1.2 O Design/CPN
ODesign/CPNéumpa otedeferramentasparaodesenvolvimentodemodelosderedes
de Petri Coloridas, e é onstituído de quatro ferramentas omputa ionais integradas
emum úni o pa ote:
1. Editor grá o para onstruir, modi ar e exe utar análise sintáti a de modelos
CPN;
2. Umsimuladorpodendooperarsimulaçãointerativaouautomáti a,possibilitando
ainda de nirdiferentes ritérios para paradae observação da evolução darede;
3. Umaferramenta para gerar e analisargrafosde o orrên ia de modelosCPN;
4. Umaferramentaparaanálisede desempenhoquepossibilitaasimulaçãoe
obser-vação de dadosde desempenho de modelos CPN.
ODesign/CPN é um dos pa otesde ferramentasmais elaboradospara onstrução,
modi ação, e análise de redes de Petri, e tem sido extensivamente utilizado om
su esso emdiferentes domíniosde apli ação. O leitorinteressado emmaioresdetalhes
pode onsultar
[CJK97℄.
3.1.3 Introdução Informal a Redes de Petri Hierárqui as
NestaseçãointroduzimosinformalmenteasredesdePetriColoridasHierárqui as
(Hie-rar hi alColouredPetri Nets HCPN)
[Jen92℄.
Oobjetivoéfamiliarizaroleitor om
anomen laturautilizadaemmodelosHCPN.Amotivaçãoparade nirasHCPNsé
dis-ponibilizarme anismospara onstruir modelosatravésda ombinaçãode um onjunto
de CPNs denominadaspáginas. Esta abordagempode ser omparada à onstruçãode
um programa a partirde um onjuntode módulos efunções.
Do ponto de vistateóri o umaHCPN possibilitades reveros mesmostiposde
sis-temas queuma CPNnão hierárqui a e,portanto,são modelos equivalentes. Ésempre
possível transformar uma HCPN em uma CPN não hierárqui a. Contudo, as HCPNs
for-sistemas omplexos, um dos grandes problemas enfrentados por desenvolvedores de
sistemas atualmente é lidar om muitos detalhes ao mesmo tempo, as HCPNs
dispo-nibilizam me anismos de abstração que permitemao projetista lidar e manter o fo o
emuma determinada parte de um modelo de adavez.
Modelos HCPN são implementados utilizando-se os on eitos de lugares de fusão
e transições de substituição. Lugares de fusãosão estruturas que permitemespe i ar
um onjunto de lugares omo fun ionalmente um úni o lugar, isto é, se uma ha
é removida ou adi ionada em um dos lugares, uma ha idênti a é adi ionada ou
removida dos outros lugares perten entes ao onjunto. Um onjunto de lugares de
fusãoé denominadode onjunto de fusão (fusion set).
Umatransiçãodesubstituiçãopodeser vista omoumatransiçãodemaisaltonível
que se rela ionaa uma CPN mais omplexa que des reve om mais detalhes as
ativi-dades modeladas pela transição de substituição. A página que ontém a transição de
substituiçãoédenominadadesuperpáginadaCPNmaisdetalhada orrespondente, que
porsua vez édenominadade subpágina. Cadatransição de substituiçãoédenominada
de supernó dasubpágina orrespondente.
Transição de
substituição
Superpágina
Subpágina
Sockets
Portas
Figura 3.4: Exemplo de uma h pn om duas páginas.
Uma transição de substituição se rela iona om sua subpágina através da
utiliza-ção de um tipo de onjunto de fusão de dois membros denominados portas e so kets.
Estas estruturasdes revem ainterfa eentre atransição de substituiçãoeasubpágina.
um onjunto de fusão. Dessa forma, quando uma ha é depositada num so ket, ela
apare e também na porta asso iada àquele so ket, permitindoassim a onexão entre
a superpágina e a subpágina. Cada so ket pode ser asso iado a uma ou mais portas,
e uma porta pode ser asso iada somente a um so ket. Na Figura 3.4 ilustra-se uma
hierarquiade duas páginas onforme des ritoaté omomento.
Comodito anteriormente, ésemprepossíveltraduzirumarede de Petri hierárqui a
para sua orrespondentenão hierárqui a. Para isso, bastasubstituir ada transiçãode
substituição ear os one tados,porsua respe tiva subpágina, olando adaso ketà
sua respe tivaporta. Detalhes teóri os rela ionadosa HCPNs podem ser en ontrados
em
[Jen92℄.
3.2 Veri ação Automáti a de Modelos
Veri ação de Modelos é uma té ni aautomáti a originalmentedesenvolvida para
ve-ri arsistemasreativosdeestados nitos,tais omoprojetosde ir uitosseqüen iaise
proto olosde omuni ação [
CGL96 ℄
. As espe i ações omportamentaisa serem
veri- adassão expressasemumalógi atemporalproposi ionaleosistemaémodeladopor
um grafode transição de estados. Nesta té ni a,ume ientepro edimentode bus aé
usado para determinar automati amente seas espe i ações são satisfeitas pelografo
de transição de estados, ou seja, seeste é um modelo para elas.
Aes olhadestaté ni aemdetrimento,porexemplo,daprovame âni ade teorema
[
CL73 ℄
para ompor a solução de re uperação de modelos neste trabalho, deveu-se
prin ipalmente pelo fato do pro edimento de Veri ação de Modelos ser automáti o.
O usuáriodesta té ni a sóne essita de uma representação de altonível domodelodo
sistemaeaespe i açãoaserveri ada. Oquea onte eéqueoveri adordemodelos
terminará sua exe ução om um resultado verdade, indi ando que o modelo satisfaz a
espe i ação, ou um resultado falso, seguido de um ontra-exemplo, mostrando uma
seqüên iade exe ução queexpli aoporquêdafórmulanão ser satisfeitapelomodelo.
Este ontra-exemplo é bastante útilpara en ontrar erros de modelagem.
omoexplosão do espaço de estados. Sistemas ujosmodelos apresentavamuma
quan-tidade de estados al ançáveis muito grande, e que res ia de forma não polinomial,
tornavamouso destaté ni aimprati ável. Issomudouporvoltade1980 oma
des o-berta deuma formade representaçãodas relaçõesde transição hamadadeDiagramas
deDe isãoBináriosOrdenados(DDBO) [
Bry86 ℄
,quepermitiuaveri açãodesistemas
realmente omplexos.
O algoritmooriginalde veri ação de modelos juntamente om a nova maneirade
representação das relaçõesde transições, ou onhe ida omo Veri ação de Modelos
Simbóli a [
JRBM92 ℄
. Esta ombinaçãopermiteaveri açãodesistemasreativosmuito
extensos, sistemas om mais de 10 120
estados porexemplo
[CGL94℄.
O fun ionamento detalhado do pro edimento de bus a foge aos interesses deste
trabalho. Entretanto, o leitor interessado pode re orrer os textos
[Ma 92;
CGL94;
WVF97; CGL96 ℄
para um estudo mais aprofundado sobre o tema. Para efeito de
en-tendimentodestetrabalho,ébastanteper eberqueaté ni adeVeri açãoAutomáti a
de Modelos realizauma bus a por exaustão noespaço de estados domodelo tentando
satisfazerfórmulas es ritasemlógi atemporal,para issore orrearepresentações mais
ompa tas doespaço de estados omo DDBOsporquestões de e iên ia.
Em se tratando do universo de modelagem em redes de Petri, a representação de
altoníveldomodeloéoprópriografode o orrên ia,entretantoéne essáriaumalógi a
temporal que possa expressar propriedades sobre o omportamento destes modelos.
Em seguida, des reve-se minimamente a lógi a temporal rami ada (Computational
Tree Logi - CTL) e a sua variante que será usada para des rever fórmulas sobre o
omportamentode modelos emredes de Petri Coloridas, o ASK-CTL.
3.2.1 Lógi a Temporal
Apesardas redesdePetri seremumaótimaes olhadelinguagemparaamodelagemde
sistemasdesoftware omplexos,asmesmasvantagensnão seapli amquando sedeseja
des rever propriedades sobre o omportamento dos mesmos. Neste aso, as lógi as e
álgebras são mais indi adas por serem linguagens de espe i ação de larativas e não
orientadasa modelos.
Lógi aModalonde,alémdosoperadoresdaLógi aProposi ional,operadorestemporais
oumodalidades são a res idosparaquesepossa des revereveri ar omoosvalores
verdadedas assertivasvariam om otempo [
Sti89 ℄
.
Aindasegundo propostoporPnueli,Lógi aTemporaléum sistemaformalbastante
útil à espe i ação e veri ação de orretude de programas de omputador de
natu-reza reativa e on orrente
[Pnu77℄.
Como exemplos de tais sistemas tem-se, sistemas
opera ionais e proto olos de omuni ação.
As lógi as temporais são lassi adas de a ordo om a natureza do tempo (linear
ou rami ado), a natureza de sua assertivas (proposi ional ou de primeira ordem), a
formadotempo(dis reto ou ontínuo) e sentido temporal(tempopassado oufuturo).
A estetrabalho, sóinteressa otipoproposi ional,rami ado, de tempo dis retoe om
a linha de tempo no sentido futuro. Entretanto, é importante dis utir, mesmo que
super ialmente, o omportamento dos operadores das lógi as de tempo linear, omo
a LTL, para que se possa melhor ompreender os operadores de uma lógi a de tempo
rami ado omo oCTL, dis utida napróximaseção.
Nos sistemas lógi os de tempo linear só há um futuro possível. Logo, os estados
estão todos des ritos ao longo de apenas uma linha de tempo. Nestes sistemas, os
operadorestemporaismais omunssãoG(sempre),F(emalgummomentofuturo),
X (no próximomomento) eU (atéque).
Gp - Sempre p
Xp - Próxima vez p
p U q - p até que q
Fp - em algum momento futuro p
linear utilizando diagramas de transição. Assim, na primeira ilustração, tem-se uma
omputação representada por uma seqüên ia de estados onde o último estado está
diferen iadopelo ír ulopreto,indi andoqueaproposiçãopéverdadenaqueleestado.
Isso signi ando que, Fp é verdade agora se em algum estado futuro a proposição p
é avaliada verdadeira. Da mesma forma,pode-se intuir o omportamento dos demais
operadores pelas ilustraçõesrestantes.
3.2.2 Lógi a Temporal Rami ada - CTL
Alógi atemporalCTLéumsub- onjuntodalógi amodaltemporalrami adade nida
por Clarke e Emerson
[MA81℄,
ujo a r nimo signi a Computation Tree Logi . Os
operadores de tempode CTL o orremempares daseguinte forma: quanti adores de
aminho, A (para todos os aminhos omputa ionais) ou E (para alguns aminhos
omputa ionais) pre edendo os operadores de tempo linear G (sempre), F (em
algum momentofuturo), X (próximo),U (até)e V (anão ser que).
AinterpretaçãodessesoperadoresestáilustradanaFigura3.6de maneiraintuitiva.
Nasilustrações,uma omputaçãoérepresentada porumaárvore deestadosM,emque
o primeiro ír ulo é o estado ini ial s
0
. Os ír ulos em preto representam os estados
emqueaproposiçãog éverdade. Assim, nailustraçãoqueindi ao omportamentodo
operador EF, o ír ulo em preto representa que para algum aminho, em um estado
futuro a proposição g é verdade, avaliando a fórmula EFg para verdade agora. As
ilustraçõesrestantes podem ser interpretadasde forma similar.
As fórmulasemCTLsão formadaspelos operadores temporais já omentados,
pro-posiçõesat mi as e one tores fun ionais (^,_, :, et .),da seguinte forma:
1. Cada proposição at mi aé uma fórmulaCTL;
2. Se f e g são fórmulas CTL, então :f, (f ^g)AXf,EXf, A(f U g),E(f U g)
tambémsão fórmulas.
Osdemais operadores podem ser derivados a partirdesses.
M, s
0
M, s
0
M, s
0
M, s
0
g
g
g
g
g
g
g
g
g
g
g
g
g
g
EF g
AF g
EG g
AG g
Figura3.6: Visão intuitivadasemânti a dos operadores CTL.
de veri ação das fórmulas, dade nição dos modelos de Kripke,bem omo da
semân-ti a de CTL podem ser en ontrados em
[CGL96℄.
3.2.3 ASK-CTL
Normalmente,aspropriedadesderedesdePetriColoridassãoespe i adasdiretamente
emtermosdeseusespaçosdeestados
[Jen92℄.
Ousodeumalógi atemporal onstruída
espe ialmentepara expressarpropriedadessobre oespaço de estadosde CPNs impli a
emter-se uma maneira,bem onhe ida e mais fá ilde usar, de expressar um espe tro
bemmaior de propriedades.
ASK-CTLéumalógi asimilaraCTL queéinterpretadasobreoespaçode estados
de CPNs [
CCM96 ℄
. Deformaapossibilitaraveri açãode propriedades
e ientemen-te, o algoritmo de veri ação é melhorado através do uso de grafos de omponentes
fortemente one tados (Strongly Cone ted Components -SCC's) [
Jen97 ℄
.
