ISSN 0103-9741

Monografias em Cincia da Computao

n 24/08

Transformando o Diagrama de Atividade em uma

Rede de Petri

Luana Lachtermacher
Denis Silva da Silveira
Rodrigo de Barros Paes
Carlos Jos Pereira de Lucena

Departamento de Informtica

PONTIFCIA UNIVERSIDADE CATLICA DO RIO DE JANEIRO

RUA MARQUS DE SO VICENTE, 225 - CEP 22451-900

RIO DE JANEIRO - BRASIL

Monografias em Cincia da Computao, No. 24/08 ISSN: 0103-9741
Editor: Prof. Carlos Jos Pereira de Lucena Abril, 2008

Transformando o Diagrama de Atividades em uma

Rede de Petri atravs do QVT.
Luana Lachtermacher, Denis Silva da Silveira, Rodrigo de Barros Paes e Carlos
Jos Pereira de Lucena
lulachter@gmail.com, denis@inf.puc-rio.br rbp@les.inf.puc-rio.br, lucena@inf.puc-rio.br.

Abstract With the evolution of the Model Driven Architecture (MDA), there is a big
concern about model transformation. The OMG (Object Management Group ) recently
adopted a standard transformation language called Query View Transformation
(QVT). The main goal of this paper is to perform a transformation between models,
where the source model used was Activity Diagram shown in UML 2.0 and the target
model was Petri Net.

Keywords QVT, Transformation model to model, Activity Diagram and Petri Net.

Resumo. Com a evoluo do conceito de Arquitetura Dirigida a Modelo (MDA), existe

uma grande preocupao sobre a transformao entre modelos. A OMG (Object Mana-
gement Group) recentemente adotou um padro para linguagem de transformao
chamado Query View Transformation (QVT). Este artigo tem como objetivo fazer a
transformao entre modelos, o modelo fonte utilizado foi o Diagrama de Atividades,
apresentado na UML 2.0, e o modelo alvo foi a Rede de Petri.

Palavras-chave: QVT, Transformao modelo-modelo, Diagrama de Atividades, Rede

de Petri.

1
Responsvel por publicaes
Rosane Teles Lins Castilho
Assessoria de Biblioteca, Documentao e Informao
PUC-Rio Departamento de Informtica
Rua Marqus de So Vicente, 225 - Gvea
22451-900 Rio de Janeiro RJ Brasil
Tel. +55 21 3527-1516 Fax: +55 21 3527-1530
E-mail: bib-di@inf.puc-rio.br
Web site: http://bib-di.inf.puc-rio.br/techreports/
 Sumrio

1 Introduo 1
1.1 Objetivo 1

2 Diagrama de Atividade 2

3 Rede de Petri 2

4 Query View Transformation (QVT) 3

4.1 Arquitetura do QVT 4
4.2 Camada de Relao 4

5 Exemplo de Transformao 6
5.1 Consideraes Iniciais 6
5.2 Construindo o QVT 6
5.2.1 Mapeamentos dos elementos 7
5.2.2 Construo do script QVT 8
5.3 Transformao utilizando MediniQVT 20

6 Consideraes Finais 21

7 Referncias 22
1 Introduo
A expresso processo de negcio pode ser definida como um conjunto estruturado de ati-
vidades ordenadas, no tempo e no espao, que produzem um produto ou um servio,
com incio e fim, e entradas e sadas bem definidas (HAMMER e CHAMPY, 1994). Sua
implantao, no contexto de uma organizao, consome normalmente uma grande
quantidade de recursos (meios de produo: humanos, financeiros, matrias-primas, e
equipamentos). Logo, de grande utilidade para as organizaes o uso de alguma me-
todologia que possa identificar, o quanto antes, as inconsistncias nos processos de ne-
gcio. A execuo desses processos inconsistentes ir acarretar um custo muito maior
para as organizaes que o do desenvolvimento da metodologia.
A modelagem de um processo de negcio pode ser feita de muitas formas. O'NEILL e
SOHAL (1999) apresentam um conjunto variado de tcnicas (mtodos e ferramentas)
para essa funcionalidade. No contexto do desenvolvimento de Sistemas de Informao
orientados a objeto ou baseados em componentes, o Diagrama de Atividades tem ga-
nho bastante destaque.
Por outro lado, as redes de petri pelo seu formalismo com base matemtica e sua repre-
sentao grfica vem sendo amplamente utilizada para simulao, h mais de 30 anos,
em vrios domnios de aplicao, entre os quais se destacam os sistemas de manufatu-
ra, de transporte, logsticos e, de forma geral, todos os sistemas e eventos discretos
(MURATA, 1989). No entanto, ainda apresenta pouca familiaridade para os projetistas
de Sistemas de Informao quando comparada aos modelos da UML.
Sendo assim, a presente pesquisa desenvolver um processo de transformao entre o
Diagrama de Atividade, usado para modelagem de processos de negcio, para uma
Rede de Petri. A motivao para tal est no fato de ser mais fcil para os projetistas de
negcio, modelar o seu processo atravs do Diagrama de Atividade do que atravs das
Redes de Petri. Entretanto, esse processo de negcio, quando transformado em uma
Rede de Petri, em funo do seu formalismo matemtico, possibilitar a verificao de
propriedades, conforme apresentado em MURATA (1989). Entre essas propriedades
destacamos as de alcanabilidade, limitao, segurana, cobertura, limitao estrutural,
repetitividade e consistncia, que no so disponvel em um Diagrama de Atividade.
Para a realizao desta transformao, foi utilizado a linguagem de transformao de-
finida pelo OMG (Object Management Group): a Consulta/Viso/Transformao
(Query/Views/Transformation, QVT) (OMG, 2004).
1.1 Objetivo

O objetivo deste trabalho foi fornecer uma viso geral sobre o QVT, apresentando, um
exemplo na definio e execuo da transformao do Diagrama de Atividades em
uma Rede de Petri. Para alcanar esse objetivo, objetivos intermedirios foram alcana-
dos, como o estudo do QVT; do Diagrama de Atividades; da Rede de Petri e as ferra-
mentas utilizadas para realizar a transformao, como por exemplo: Eclipse Modeling
Framework, para fazer a gerao dos metamodelos e do exemplo que ser transformado
e o MediniQVT para fazer a transformao em si, utilizando como entrada os dois me-
tamodelos, o exemplo de Diagrama de Atividade e um script QVT desenvolvido.
Este trabalho ir primeiramente mostrar uma viso geral do Diagrama de Atividades,
Rede de Petri e QVT. Depois apresentado todos os passos para a transformao e uma
concluso do trabalho.

1
2 Diagrama de Atividade

A UML (BOOCH et al., 2005) um dos mais importantes padres mantidos pelo grupo
OMG. A UML vem sendo considerada como a linguagem de modelagem (grfica) pa-
dro no desenvolvimento orientado a objetos, oferecendo apoio criao de modelos
independentes da plataforma, nos quais os conceitos so separados da semntica exis-
tente nos modelos da implementao. As linguagens grficas de modelagem existem
h muito tempo na indstria de software, e o grande propulsor por trs de todas elas o
fato das linguagens de programao no possurem um nvel de abstrao suficiente-
mente alto que permita aos programadores raciocinar diretamente com os conceitos
envolvidos num projeto (FOWLER, 2004).
Modelagem, no sentido mais amplo, o uso econmico de algo (o modelo) no lugar de
alguma coisa real, tendo em vista algum objetivo cognitivo. Esta prtica permite o uso
de algo mais simples, seguro e barato do que o sistema real, para o estudo do objetivo
desejado(BOOCH,1994)(MEYER,1988). Um modelo , portanto, uma representao
simplificada de algum conceito ou situao, com os objetivos de sua observao, mani-
pulao e entendimento (MELLOR et al., 2004). No desenvolvimento de software, tal
como em outras aplicaes, os modelos so criados com o objetivo de diminuir a com-
plexidade inerente aos temas de suas aplicaes.
O Diagrama de Atividades utilizado para descrever lgica de programao, proces-
sos de negcio e workflows. Este diagrama determina as regras essenciais de seqncia
que se deve seguir para a execuo do processo. Neste trabalho, usamos uma verso
simplificada dos elementos do Diagrama de Atividades da UML 2.0 (OMG, 2005).

3 Rede de Petri

Rede de Petri uma ferramenta de modelagem aplicvel a uma srie de sistemas, espe-
cialmente aqueles com eventos concorrentes. Elas foram criadas por C. A. Petri, um
pesquisador alemo, que na sua tese de doutorado apresentou um tipo de grafo orien-
tado e bipartido com estados associados, com o objetivo de estudar a comunicao en-
tre autmatos (PETRI, 1961).
Um grafo G(P, E) consiste de um conjunto vrtices P = {p1,..., pn}, com n > 0, e de um
conjunto de arcos E = {e1,..., em}, tal que cada vrtice conectado com pelo menos outro
vrtice, e cada arco conecta dois vrtices de P. O grafo G dito orientado se todo arco
possui um sentido, bem como denominado finito se m e n so finitos. Um grafo, por
sua vez, considerado bipartido, quando o seu conjunto de vrtices P pode ser parti-
cionado em dois conjuntos X e Y. Tal que toda aresta E de G incidente a um elemento
de X e a um elemento de Y (BOAVENTURA NETTO, 2006).
Como ferramenta matemtica e grfica, as redes de petri oferecem um ambiente uni-
forme para a modelagem, anlise formal e simulao de sistemas e eventos discretos,
permitindo uma visualizao simultnea da sua estrutura e comportamento. No entan-

2
to, mais especificamente, as redes de petri modelam dois aspectos: eventos e condies.
Assim como, as relaes entre eles (HEUSER, 1990).
Os elementos dos dois conjuntos em que se podem dividir os vrtices que constituem
uma Rede de Petri denominam-se: lugares e transies. Os lugares so normalmente
representados por circunferncias ou elipses, e as transies por segmentos de reta, re-
tngulos ou barras. Os lugares encontram-se ligados s transies, e estas aos lugares,
atravs de arcos orientados, conforme ilustrado na.

Figura 1 Rede de Petri

Uma forma muito genrica e muito prxima as sua visualizao grfica, ser vista como
depsitos de recursos e as transies como aes que manipulam esses recursos. Os
recursos so representados graficamente por pequenos crculos pretos dentro dos luga-
res. Cada um desses crculos d-se o nome de marca. Os lugares surgem como repre-
sentantes do estado da rede e as transies como responsveis pela mudana de esta-
do. Desta forma, a Rede de Petri simultaneamente orientada para os estados e para as
aes. Ao estado da rede usual chamar-se marcao, dado ser definido pela marcao
de cada um dos seus lugares, ou seja, pela quantidade de marcas presentes em cada
lugar.
A funo das transies consiste em destruir e/ou criar marcas. Como as transies
esto obrigatoriamente entre lugares atravs da sua ao, denominada de disparo,
que um lugar altera a sua marcao. Os arcos indicam, para cada transio, os lugares
sobre os quais estas atuam. Este tipo de diagrama tem ajudado muito aos desenvolve-
dores para fazer a simulao de uma rotina e tambm vem sendo muito utilizado para
modelar comportamento em sistema distribudos.

4 Query View Transformation (QVT)

O QVT representa uma tentativa de se encontrar uma linguagem padro para expres-
sar transformaes entre modelos, de uma forma simples e tendo por fim a sua execu-
o automtica (TRATT, 2003). A sigla QVT representa trs conceitos:
Consulta (Query), pegam um modelo como entrada e selecionam elemen-
tos especficos deste modelo;
Viso (View), so modelos que so derivados de outros modelos, uma vi-
so uma projeo de um metamodelo que pode ser gerado a partir de
consultas em um modelo UML e respectivas transformaes;
Transformao (Transformation), tomam um modelo como entrada e atuali-
zam ou criam um novo modelo.
Apesar de o QVT estar dependente destes trs conceitos o da transformao o mais
importante para esse trabalho. A seguir ser mostrado todos os aspectos importantes
da transformao utilizando QVT.

3
4.1 Arquitetura do QVT

O QVT tem uma arquitetura hibrida, sendo uma parte declarativa e a outra imperativa.
As duas partes tm uma linguagem especifica.
A parte declarativa utilizada para fazer todo o processo de transformao. A lingua-
gem associada a esta parte, descreve os relacionamentos entre as variveis utilizando
funes ou regras de inferncia. Para a execuo desta linguagem necessrio um
compilador ou interpretador, que aplica um algoritmo sobre as relaes e produz um
resultado. Esta camada pode ter informaes suficientes para descrever uma transfor-
mao bidirecional ou unidirecional. (GARDNER et al., 2002) Existem duas camadas
declarativas. So elas:
A primeira camada a Relao (Relation) que tem como objetivo fazer uma especificao
do relacionamento entre modelos MOF. A linguagem utilizada nesta camada possibili-
ta a equivalncia entre de objetos complexos e cria classes de rastreamento para verifi-
car o que ocorreu durante a transformao. Alm da execuo propriamente dita, uma
relao pode ser utilizada apenas para garantir que a outra relao est correta.

A segunda camada chamada de Core. Essa camada responsvel por casar padres
de acordo com um conjunto de variveis e condies. O modelo Core pode ser direta-
mente implementado ou utilizado apenas como referencia da semntica da Relao. A
Relao facilmente transformada em Core utilizando a linguagem de transformao.
A parte imperativa composta pela camada de Mapeamento Operacional e pela Caixa
Preta. A camada Mapeamento Operacional uma extenso das duas camadas declarati-
vas e possui recursos normalmente encontrados em linguagens imperativas, como loops
e condies. A outra camada responsvel por juntar facilidades expressas em outras
linguagens como XSLT (Extensible Stylesheet Language Transformations) e integrar biblio-
teca que no so QVT (OMG 2004).
Neste trabalho, foi utilizada apenas a parte declarativa e, principalmente, a camada de
Relao.

Figura 1 Relacionamento entre os metamodelos do QVT. Fonte: OMG 2004

4.2 Camada de Relao

Nesta camada, uma transformao sempre especificada com um conjunto de relaes,

que devem ser verdadeiras para que a transformao seja efetuada corretamente. Para
a transformao, sempre existe um modelo de origem (fonte) e um modelo de destino
(alvo). Este modelo de destino pode conter um metamodelo que deve ser respeitado.
Uma relao composta de um ou mais domnios e um par de condies, expressas nas
clausula when e where.

4
Um domnio corresponde aos modelos utilizados para a transformao. Existem duas
constantes usadas antes da declarao do domnio: enforce e checkonly. Normalmente,
essa constante utilizada no domnio resultante. A constante enforce tem como objetivo
fazer com que o resultado da relao seja positivo, mesmo se para isso seja necessrio
inserir e alterar o modelo. A constante checkonly s ir verificar se a relao est vlida
ou no. Um exemplo de uma relao geral mostrado na Figura 2.
A clusula when especifica condies que a relao deve ter. J a clusula where especi-
fica uma condio que deve ser satisfeita por todos os elementos participantes da rela-
o.
Existem duas formas de relaes: nvel top e no nvel top. Uma relao com a constante
top determina que essa relao seja sempre executada, contrrio das relaes sem essa
constante. Normalmente, relaes sem essa constante so utilizadas apenas como con-
dio para outra relao.
A equivalncia dos padres pode estar associada com um domnio e isso chamado de
expresses de template de objeto (object template expressions) (OMG 2004).

Figura 2 Relao de explicao de object template expressions

No exemplo anterior, existe um expresso template associado com o domnio uml. A
correspondncia dos padres ir vincular todas as variveis da expresso, c, p e
cn, comeando pelo varivel principal do domnio, c. A varivel p j ser vincu-
lado atravs da condio when. A correspondncia continua agora procurando todos os
elementos do tipo Classe to domino que tenham o atributo tipo= Persistent. As prxi-
mas comparaes so com variveis que esto aninhadas, como o exemplo do na-
mespace. As funcionalidades de comparar variveis aninhadas e comparar variveis
que esto dentro das variveis aninhadas, aumentam ainda mais a complexidade das
relaes. A clusula where deve possuir ao menos uma linha correspondente do dom-
nio de rdbms que satisfaa a condio. Caso no exista essa condio, a Classe encon-
trada no transformada em uma Tabela (OMG 2004). Esse template permite a criao
de elementos no modelo de destino, j que ele est com a constante enforce. Todas as
caractersticas mostradas no segundo domnio, refletem como esse novo objeto criado
deve ser estruturado.
Uma transformao tambm tem um efeito sobre o rastreamento inverso (backtra-
king). Se parte das relaes falhar, a semntica fora backtraking a ocorrer. Isso acon-
tece porque em diversos pontos da transformao, escolhas podem decidir num cami-
nho que pode resultar em uma falha na transformao subseqente. Se ocorrer, o ras-
treamento inverso ir para o ltimo ponto de escolha, reiniciando o sistema para o estado
anterior, escolhendo um valor diferente do previamente escolhido, continuando assim

5
a execuo. O rastreamento inverso pode ocorrer em um nmero arbitrrio de nveis.
Essa tcnica permite ao programa encontra um caminho sem falhas sem que haja muita
interferncia do usurio.
Para aumentar a complexidade das relaes possvel utilizar OCL (Object Constraint
Language), que possibilita a construo de queries para a avaliao mais especifica de
uma determinada caracterstica.

5 Exemplo de Transformao
5.1 Consideraes Iniciais

Esta seo tem como objetivo mostrar um exemplo de transformao entre modelos. A
transformao ter como entrada, alm deste script QVT, os respectivos metamodelos
do Diagrama de Atividades e da Rede de Petri, alm do Diagrama de Atividades que
dever ser transformado. A sada ser o Diagrama de Atividades expresso em uma Re-
de de Petri.
Assim como os dois metamodelos, o Diagrama de Atividade utilizando como entrada
foi modelado utilizando o software Eclipse Modeling Framework. Aps essa etapa, foi rea-
lizado o mapeamento entre os elementos de cada metamodelo. Foi atravs desse ma-
peamento que descrevemos o script QVT, que detalharemos no decorrer desta seo. O
processo final, descrito na seo 5.3 , contm todos esses elementos, que foram coloca-
dos no programa MediniQVT (IKV++ Tecnologies) para fazer a gerao do modelo ex-
presso em uma Rede de Petri. Abaixo apresentamos o diagrama de atividade usado
como exemplo para a transformao.

Figura 3 Exemplo do Diagrama de Atividade

5.2 Construindo o QVT

Para o desenvolvimento do script QVT, necessrio primeiramente fazer a relao en-

tre os elementos dos dois metamodelos. Essa relao ser descrita na primeira parte
dessa seo. Com essas relaes desenvolvidas, possvel fazer o script QVT que ser
feito na segunda parte dessa seo.

6
5.2.1 Mapeamentos dos elementos

O elemento Ao no Diagrama de Atividades representa uma especificao de um

comportamento que tem diversos inputs que sero transformados em um conjunto de
outputs. Na Rede de Petri o elemento transio o componente que representa a ao e
que pode alterar o estado do sistema. Por possurem a mesma funcionalidade o ele-
mento Ao transformado no elemento transio (MAQBOOL,2005).
Como o elemento Atividade Inicial do Diagrama de Atividade apenas passa o
fluxo para o prximo elemento, ele ser representado como um elemento Lugar sem
nenhum marca, pois no demonstra nenhuma mudana de estado (MAQBOOL,2005).
O elemento Deciso direciona o fluxo em diversas direes que so determinadas de
acordo com uma Ao anterior. Esse elemento mapeado como um Lugar sem Marca
na Rede de Petri. O elemento Unio mapeado com um elemento Lugar, assim como
o elemento Deciso.
O elemento Separao tem como objetivo duplicar o fluxo e com isso representa uma
ao. Logo ele ser mapeado como uma Transio na Rede de Petri, que tem a mesma
funo de produzir uma ao. Como o elemento de Juno tem como objetivo unir o
elemento Separao, ele tambm representa uma ao que deve ser representado
com uma Transio.
Como j mencionado, os elementos Final de Fluxo e Final de Atividade fina-
lizam o fluxo de tokens. Logo, na Rede de Petri eles so mapeados para um lugar que
no tem sada, chamado de Sink. O conceito de finalizao de tokens no existe em uma
Rede de Petri e por isso ele no ser mapeado na transformao.
O ltimo elemento o Objeto, ele representa no diagrama de atividade inputs e out-
puts para as Aes. Na Rede de Petri isso mapeado como um Lugar com uma Marca
que representa a mudana de estado do Objeto em questo. Existe um tratamento
diferenciado para o elemento Pino,que filho do elemento Objeto.Os Pinos po-
dem ser transformados de trs diferentes formas: quando tem a relao entre um Pino
de Sada e um Pino de Entrada, quando tem apenas um Pino de Sada e
quando tem apenas um Pino de Entrada. Na primeira forma os dois elementos
so transformados em um elemento Lugar com duas Marcas, uma para cada Pino.
Na segunda e terceira forma, o Pino transformado em um Lugar com uma Marca e o
elemento Ao que possui o Pino ligado com o prximo elemento ou com o elemen-
to anterior do diagrama.
A transformao feita para cada elemento, mas como existe um seqenciamento entre
os elementos ocorrem alguns problemas. Esses problemas so unicamente causados
pela alta complexidade do Diagrama de Atividade e pela simplicidade da Rede de Pe-
tri. Na Rede de Petri existem apenas ligaes entre o elemento Transio e o elemento
Lugar,. Com isso, quando existe uma seqncia do mesmo elemento, como uma Deci-
so seguida de outra Deciso, no momento da transformao existe a ligao entre o
mesmo elemento na Rede de Petri. Por causa deste problema, necessrio a adio de
alguns elementos para o modelo resultante estar de acordo com o metamodelo da Rede
de Petri. Aps a correlao entre os elementos dos dois metamodelos e os casos que
necessitam adio de elementos ser desenvolvido um script QVT para traduzir essas
relaes.

7
5.2.2 Construo do script QVT

Como visto anteriormente, o QVT constitudo de relaes entre dois domnios, um de

cada metamodelo. Todas as relaes utilizam o domnio do Diagrama de Atividade
com a constante checkonly e o domnio da Rede de Petri com a constante enforce.
A primeira relao feita foi entre uma Atividade e uma Rede de Petri. Esses dois ele-
mentos so os ns iniciais dos modelos. Para esses elementos, foi feita uma relao que
consiste na criao de um elemento Rede na Rede de Petri para todos os elementos ativ
do Diagrama de Atividade, esta relao est descrita na Figura 4.
top relation AtividadeToRedePetri {
pn : String;
checkonly domain ativ a :Atividade::ativ{
ativNome= pn
};

enforce domain pet p : petri::RedePetri{

nome = pn
};
}
Figura 4 Relao Atividade to Rede de Petri

importante mencionar as mudanas que foram realizadas no metamodelo. A primei-

ra modificao feita, foi apenas para no ficar repetindo o atributo nome em todos os
elementos, logo foi criado um elemento chamado n bsico que tem um atributo nome e
um relacionamento com o n raiz. Todos os outros elementos do metamodelo herdam
desse elemento. Essa modificao foi feita nos dois metamodelos. O n raiz no Dia-
grama de Atividade a Atividade e na Rede de Petri o elemento Rede.
Outra modificao feita, foi com o intuito de unir os elementos do Diagrama de Ativi-
dade que se transformam no mesmo elemento da Rede de Petri. Os elementos modifi-
cados so os elementos que herdam Controle. Com a correlao feita anteriormente,
foi visto que alguns elementos que herdam Controle se transformam em uma Transi-
o e outros em um Lugar. Por isso foram criados dois elementos, Controlet e Controlel.
Foram feitas duas relaes para fazer a correspondncia de todos os elementos Con-
trole. Nas duas relaes foi utilizado o mesmo princpio. Para um elemento do do-
mnio do Diagrama de Atividade, criado um elemento na Rede de Petri, onde o nome
do elemento criado ser o mesmo do elemento no outro domnio. O elemento do Dia-
grama de Atividade tem relao com um elemento atividade. A clusula when garante
que o elemento inserido na Rede de Petri tenha a relao com um elemento rede que
seja equivalente ao elemento atividade que o outro elemento est relacionado. As duas
figuras, Figura 5 e Figura 6, mostram as duas relaes para os elementos Controle.

8
 top relation ControletoTransicao {

ju : String;

checkonly domain ativ d : Atividade::controlet{

atividade = a : Atividade::ativ{},
nome = ju
};

enforce domain pet t : petri::Transicao{

rede = p : petri::RedePetri{},
nome = ju
};
when
{
AtividadeToRedePetri(a,p);
}
}
Figura 5 Relao Controle to Transio

top relation ControleToLugar {

ju : String;

checkonly domain ativ d : Atividade::controlel{

atividade = a : Atividade::ativ{},
nome = ju
};

enforce domain pet t : petri::Lugar{

rede = p : petri::RedePetri{},
nome = ju
};
when
{
AtividadeToRedePetri(a,p);
}
}
Figura 6 Relao Controle to Lugar
Todas as relaes criadas utilizam o mesmo raciocnio dessas duas relaes. As rela-
es podem ter outras expresses inseridas que sero explicadas ao longo desta seo.
A prxima relao feita foi para o elemento Objeto. Para todos os Objetos encontra-
dos no domnio do Diagrama de Atividade, eles so transformados em um Lugar com
uma Marca na Rede de Petri. A complicao desta relao que o elemento Pino tam-
bm um tipo de Objeto. O elemento Pino deve ter um tratamento diferente do da-
do ao Objeto. Logo, para isso foi necessrio fazer uma relao que verifica que o Ob-
jeto no pode ser um Pino. A chamada desta relao feita na clausula when da rela-
o principal. As duas relaes que fazem a transformao esto na Figura 7 e na
Figura 8.

9
 top relation ObjetotoLugar {

pn : String;
checkonly domain ativ b:Atividade::objeto{
atividade = a : Atividade::ativ{},
nome = pn
};

enforce domain pet t : petri::Lugar{

marca = s: petri::Marca{},
rede = p : petri::RedePetri{},
nome = pn
};
when
{
AtividadeToRedePetri(a,p);
not PinoToLugar(b);
}
}
Figura 7 Relao Principal de Objeto to Lugar

top relation PinoToLugar{

pn : String;
checkonly domain ativ
b:Atividade::pino{
atividade = a : Atividade::ativ{},
nome = pn
};
}
Figura 8 Relao Secundria de Objeto to Lugar

Outro elemento que sofreu transformao foi a Ao. A relao similar com a relao
de Controle mostrado anteriormente, s mudando os elemento de origem e o ele-
mento de destino.
O ltimo elemento primrio que foi transformado foi o Pino. Como visto anteriormen-
te, o Pino tem trs formas separadas de transformao. Todas as transies entre os
elementos transformados foram feitas em uma relao s, que ser mostrada no final
desta seo. A primeira relao que iremos mostrar uma transio que liga um
Pino de sada em um Pino de Entrada. Para a transformao do Pino foi utili-
zada uma relao que transforma uma Transio que tem como origem um Pino
de sada e como destino um Pino de entrada em um lugar com duas marcas. A
transformao da ligao dos elementos ser mostrada a seguir. A Figura 9 est descri-
ta a relao de transformao.

10
Figura 9 Relao Pino Sada e Pino de Entrada com Lugar
A outra forma de transformao quando tem apenas o Pino de Sada. Para resol-
ver esse relacionamento foram necessrias quatro relaes: uma que transforma o Pino
de Sada em um lugar com uma marca, outra que garante que no tenha conflito com
a primeira forma de transformao e outras duas para criar as duas ligaes que a ao
que contem o Pino de Sada ter.
A primeira relao tem apenas diferena na clusula where. Nessa clusula utilizado
o operador lgico not com a segunda relao. A segunda relao garante que o Pino
de Sada no tem relao com nenhum Pino de Entrada, para que no sejam
sobrepostos as transformaes.
A Figura 10 tem a relao que transforma o Pino de Sada e a Figura 11 mostra re-
lao que evita conflitos com a primeira transformao de Pino.

Figura 10 Relao do Pino de Sada para Lugar

11
Figura 11 - Relao para evitar conflitos com a outra transformao
Para simplificar a explicao, o elemento Ao que possui o Pino ser denominado
portador e o elemento para qual o Pino aponta ser chamado de destinatrio. As ou-
tras duas relaes feitas para a transformao do elemento Pino so: uma para fazer a
ligao entre o portador e o destinatrio e outra para fazer ligao entre portador e o
elemento que o Pino se transformou. Na primeira relao descrita acima, a principal
inovao como feita a recuperao dos dois elementos participando da ligao, o
elemento portador e o destinatrio. Para identificar o elemento portador, foi necessrio
fazer o acesso atravs da transio de origem e nesse ltimo elemento acessar a origem.
O mesmo foi feito para identificar o elemento destinatrio. Na Figura 12 e Figura 13
mostra as duas relaes explicadas anteriormente.

Figura 12 Relao de ligao entre o elemento que possui o Pino e quem o pino aponta

12
Figura 13 Relao de ligao entre o Pino e o elemento que possui o Pino
A ltima forma de transformao quando tem apenas o Pino de Entrada. Para
resolver esse relacionamento foram necessrias quatro relaes, parecida com as rela-
es feitas para a ltima forma de transformao de Pino. A nica mudana que nas
duas primeiras relaes, as relaes de transformao do Pino e garantia de no ter
conflito com a primeira forma de transformao, foi o elemento do domnio do Dia-
grama de Atividades que foi utilizado, neste caso Pino de Entrada. Nas outras du-
as relaes, a diferena foi qual era o tipo de elemento que ser transformado, que nes-
te caso o Arco de Input..
A prxima relao feita foi para transformar a ligao entre os elementos, no caso do
Diagrama de Atividade o elemento Transio e na Rede de Petri os elementos Arco In-
put e o Arco Output. O Arco de Input, sempre tem origem em um Lugar e destino em
uma Transio. Com o Arco de Output, exatamente o contrrio, origem em uma
Transio e o destino em um Lugar. Por causa dessa caracterstica, foi feito duas rela-
es, uma para todas as Transies que iriam virar Arcos Input e outra para os que iri-
am virar Arcos de Output.
Na relao de Arcos de Input, foi feita uma relao genrica, que tem a origem e o des-
tino como um N Atividade, que pai de todos os elementos com exceo da Tran-
sio. No domnio da Rede de Petri dessa relao, sempre ser criado um elemento
Arco de Input e sempre sero referenciados um lugar e uma transio. Foram analisa-
dos todos os elementos que poderiam ser origem e todos que podiam ser destino e foi
utilizada a clusula where para garantir essa analise. Essa relao foi desenvolvida para
garantir que apenas essa relao resolvesse todas as transformaes para Arco de In-
put. A Figura 14 demonstra relao Arco de Input e tem como objetivo resolver todos os
problemas mencionados.

13
Figura 14 Relao dos Arcos Input
O mesmo foi feito para o Arco de Output. Foi feito uma relao genrica e na clusula
when adicionando os elementos que poderiam ser origem e os que poderiam ser desti-
no. A relao Arco de Output est descrita abaixo.

Figura 15 Relao de Arcos de Output

Como mostrado no inicio desta seo, existem algumas simplificaes necessrias. To-
das elas foram resolvidas dentro do QVT.

14
As simplificaes foram dividas em trs grandes grupos. Para os trs grupos, foi neces-
srio fazer trs relaes. A primeira relao responsvel por criar o elemento Dummy,
dependendo dos elementos da relao. As duas outras relaes so para fazer a ligao
entre os elementos inicias da relao e o elemento Dummy criado.
O primeiro grupo dos elementos do Diagrama de Atividade que se transformam no
elemento Lugar da Rede de Petri, com exceo ao elemento Pino. Como dito anterior-
mente, existem 4 conjuntos de elementos que sofreram simplificao nesse grupo. So
eles: Deciso com Deciso, Unio para Unio, Unio para Deciso, Deciso para Unio.
Cada um desses conjuntos ter a primeira relao, com a criao do elemento Dummy.
Todas as quatro primeiras relaes so parecidas, trocando apenas qual elemento do
domnio do Diagrama de Atividade ser utilizado como origem e qual ser utilizado
como destino. No exemplo abaixo, est descrita a relao entre Deciso e Unio.

Figura 16 - Relao de Simplificao de Deciso para Unio

J a segunda e a terceira relao so reutilizveis para esses quatro conjuntos. Essa reu-
tilizao feita atravs do domnio do Diagrama de Atividade com o atributo origem e
o destino do elemento Transio atravs da utilizao do elemento Controlel, que
pai de todos os elementos deste grupo. A restrio de quais elementos podem ser usa-
dos na relao inserido na clusula when. O destino dessa ligao sempre um lugar,
logo na clusula when a relao primria de transformao entre um elemento Con-
trole e um lugar. A origem da ligao sempre um elemento que se transforma em
uma Transio, logo foram utilizadas todas as primeiras relaes dos 4 conjuntos para
garantir a correlao entre os elementos. A diferena para as outras relaes o tipo de
elemento que criado, neste caso Arco de Input, e acontece exatamente o contrrio da
primeira relao. A origem tem um lugar associado e o destino uma Transio, gerada
a partir da primeira relao de simplificao. As duas relaes esto mostradas a se-
guir.

15
Figura 17 Primeira Relao de Simplificao do primeiro grupo

Figura 18 - Segunda Relao de Simplificao do primeiro grupo

16
O segundo grupo dos elementos do Diagrama de Atividade que se transformam no
elemento Transio da Rede de Petri. Como dito anteriormente, existem 8 conjuntos de
elementos que sofreram simplificaes nesse grupo, que so: Ao com Ao, Ao
com Juno, Ao com Separao, Juno com Juno, Juno com Ao, Jun-
o com Separao, Separao com Separao, Separao com Ao, Separa-
o com Juno. A forma de desenvolvimento das relaes igual ao grupo anterior.
A primeira relao existe para cada conjunto de elementos e a segunda e terceira rela-
o nica para todo o grupo. Os elementos Separao e Juno esto classificados
como Controlet, com visto anteriormente. Por causa dessa classificao, passaram a
existir apenas as 4 primeiras relaes. A diferena entre as relaes neste caso qual o
tipo de elemento do domnio do Diagrama de Atividades que igual origem e ao
destino. A relao de uma Ao para uma Ao est descrita a seguir.

Figura 19 Relao de Simplificao de Ao to Ao

A segunda e a terceira relao so parecidas com a do primeiro grupo, com a diferena
apenas em quais relaes so utilizadas na clausula where. Neste caso so as primeiras
relaes criadas para este grupo. Outra diferena que alm dessas relaes, utiliza-
da a relao primria AoToTransicao e ControletToTransicao para garantir que a trans-
formao para o elemento Transio. As duas relaes esto expressas a seguir.

17
Figura 20 Segunda relao de simplificao do segundo grupo

Figura 21 - Terceira relao de simplificao do segundo grupo

A ultima simplificao realizada foi para o elemento Pino. Essa simplificao teve que
ser separada j que o acesso aos tipos de elementos que participam das transformaes
feito dentro de uma varivel aninhada. Foram feitas duas simplificaes, uma quan-
do tem apenas o elemento Pino de Sada e outra quando tem apenas o elemento
Pino de Entrada. A estrutura das duas simplificaes est igual ao das simplifica-
es j explicadas.
Para simplificar a explicao, o elemento que possui o Pino ser denominado porta-
dor e o elemento para qual o elemento Pino aponta ser chamado de destinatrio. A

18
primeira relao a seguir descreve a transformao de um Pino de Sada que tem
como origem o portador, que um elemento Ao e como destino o elemento destina-
trio, que tambm um elemento Ao. A segunda relao mostra a ligao entre o
elemento portador e o elemento em qual o Pino se transformou, e a terceira relao a
ligao entre o elemento portador e o elemento destinatrio. A diferena dessa simpli-
ficao para todas as demonstradas anteriormente, a forma que o elemento origem e
o elemento destino so recuperados. Para isso, necessrio acessar atravs da transio
que o Pino possui o elemento que origem dessa transio. Esse mecanismo foi utili-
zado para todas as relaes descritas a seguir.

Figura 22 Simplificao Pino de sada I

Figura 239 Simplificao Pino de sada II

19
Figura 60 Simplificao Pino de sada II

A simplificao realizada para o elemento Pino de Entrada similar a simplifica-

o do elemento Pino de Sada. As nicas diferenas so o elemento do domnio
na primeira relao, que neste caso o Pino de Entrada e qual relao primria
ser utilizado para as outras duas relaes, neste caso utilizou-se a primeira relao de
simplificao do Pino de Entrada.
5.3 Transformao utilizando MediniQVT

Para a transformao de modelos foi utilizado o software MediniQVT, que foi o nico
software livre encontrado que faz a transformao da camada de Relao do QVT.
A ferramenta MediniQVT tambm baseada no Eclipse, mas um software fechado. No
entanto, ele foi o escolhido para este trabalho por utilizar QVT Relao e consegue fa-
zer a partir de qualquer metamodelo a transformao em qualquer outro metamodelo
dado com input. Esse software desenvolvido ikv++ Technologies ag e a verso utilizada
do software foi 1.0.0.
Para utilizar esse sistema necessrio criar um projeto que tenha uma pasta com os
dois metamodelos, dois arquivo .ecore, e o exemplo do modelo, um arquivo .xmi. Sendo
tambm necessrio ter pasta com o script QVT desenvolvido e uma pasta de rastrea-
mento.
Um problema encontrado no momento de fazer a transformao, foi que alguns atribu-
tos tiverem que ser modificados para que pudesse ser entendida pelo software. Os atri-
butos alterados foram: container, containment e EOpossite. Para o lado 1 da relao, os
atributos tm os seguintes valores: container = true, containment = false e o EOpossite ir
referenciar o relacionamento onde est a parte N do relacionamento. J para o lado N
do relacionamento, os atributos tm os seguintes valores: container = false, containment =
true e EOpossite ir referenciar o relacionamento onde est a parte N do relacionamen-
to.

20
Depois de configurar esses detalhes, possvel executar a transformao e o arquivo
Petri.xmi criado. A seguir est o modelo da Rede de Petri gerada.

Figura 5 Rede de Petri transformada.

6 Consideraes Finais
O objetivo desse trabalho foi realizar um estudo sobre QVT. Para tal, transformou um
Diagrama de Atividades da UML 2.0 para uma Rede de Petri, utilizando a linguagem
QVT padronizada pelo OMG, exemplificando com a transformao de dois modelos
que tem o mesmo nvel de abstrao.
A importncia deste estudo est no fato de que os desenvolvedores no precisem utili-
zar o Diagrama de Atividades para finalidades as quais, ele no foi estruturado para
realizar. Alm disso, importante verificar que possvel fazer a transformao entre
outros modelos, que podem proporcionar benefcios futuros ainda no estudados e/ou
explorados.
No decorrer desse trabalho ocorreram algumas dificuldades na sua execuo. Entre
elas podemos destacar a complexidade do Eclipse Modeling Framework (EMF) e na utili-
zao do software MediniQVT.
Com relao ao EMF, destacamos o fato de que quando os arquivos eram gerados, a
importao do arquivo de biblioteca e outros arquivos fontes eram feitos de forma in-
correta, provocando erros e sendo necessrios consertos manuais. Outra dificuldade
encontrada foi, ao reabrir um projeto, que j possui o .edit e o .editor criados, ocorriam
erros de incompatibilidade com a verso da biblioteca JRE (Java Runtime Enviroment) do
Java. Nesse caso o procedimento adotado foi o de excluir os dois arquivos e fazer a ge-
rao novamente, uma vez que assim supervamos o problema.
J no software MediniQVT utilizado, o problema acontecia quando se executava uma
alterao do arquivo .xmi que continha o exemplo a ser transformado. Quando havia a
alterao do modelo a transformao se perdia e provocando um erro de falta de refe-

21
rencia do elemento excludo. Uma das solues possveis para esse problema era a tro-
ca do nome do arquivo que continha o exemplo. Outro problema acontecia ao abrir o
arquivo .xmi do modelo transformado pela primeira vez, que provocava o erro Unable
to create this part due to an internal error. Reason for the failure: assertion failed:. A soluo
encontrada foi a de realizar uma segunda tentativa para que o erro no persistisse.
No decorrer dos estudos observamos que o potencial desta proposta foi significativa-
mente superior ao previsto no incio do mesmo.
Como sugesto para continuidade deste trabalho a extenso das Redes de Petri para
que se possa incorporar todos os elementos que fazem parte do Diagrama de Ativida-
des da UML 2.0. Outra melhoria que poderia ser includa a criao de uma ferramen-
ta que interprete o XML e gere o desenho do modelo tanto do Diagrama de Atividades
quanto da Rede de Petri.

7 Referncias
BOAVENTURA NETTO, P. O., Grafos: Teoria, Modelos, Algoritmos, 4a. Edio,
Editora Edgard Blcher Ltda., So Paulo, 2006.
BOOCH, G., Object Oriented Analysis and Design with Applications, 2a Edition,
Addison-Wesley, ISBN 0-8053-5340-2, 1994.
BOOCH, G., RUMBAUGH, J. e JACOBSON, I., The Unified Modeling Language
User Guide, Addison-Wesley, 2a Edition, ISBN: 0321267974, 2005.
HAMMER, M. e CHAMPY J., Reengenharia Revolucionaria a Empresa, Editora
Campus, 1994.
HEUSER, C. A., Modelagem Conceitual de Sistemas Redes de Petri, Edio Preli-
minar, Publicada para a V Escola Brasileiro-Argenina de Informtica, 1990.
FOWLER, M., UML Distilled: A Brief Guide to the Standard object Modeling Lan-
guage, 3a Edition, Pearson Education, ISBN: 0321193687, 2004.
GARDNER, T., GRIFFIN, C., KOEHLER, J., et al., 2002, A review of OMG MOF
2.0 Query / Views / Transformations Submissions and Recommendations towards
the final Standard, OMG Document: ad/03-08-02.
MAQBOOL, S. Tranformation of a Core Scenario and Activity Diagrams into Petri
Net, Master In Computer Science in University of Ottawa, September 2005
MELLOR, J. S., SCOTT, K., UHL A. e WEISE, D., MDA Distilled: Principles of
Model-Driven Architecture, Addison-Wesley, ISBN: 0-201-78891-8, 2004.
MEYER, B., Object-Oriented Software Construction, Prentice-Hall, 1988.
MURATA, T., Petri Nets: Properties, Analysis and Applications. Proceedings of the
IEEE, 77(4): 541-580. April 1989.
OMG, Object Management Group - QVT - Query/Views/Transformations, version
1.8, 2004. Disponivel em: www.omg.org, acessado em: 10/10/2006.
OMG, Object Management Group - Unified Modeling Language (UML) Superstruc-
ture Specification, version 2.0, 2005. Disponivel em: http://www.omg.org/cgi-bin/doc?
formal/05-07-04, Acessada em: 01/2007.

22
O'NEILL, P. e SOHAL, A., Business Process Reengineering: A Review of Recent
Literature, Technovation, vol. 19, no. 9, pp. 571-581, 1999.
PETERSON, J. L., Petri Nets. ACM Computing Surveys, 9(3): 223-252. September
1977.
PETRI, C. A., Kommunikation Mit Automaten. PhD Thesis, Technische Hochschule
Darmstadt, 1961.

23