Programação Orientada A Objeto Com Grafos

Programao Orientada a Objeto com Grafos
Ana Paula Ldtke Ferreira

Leila Ribeiro
Abstract
This text aims to present a universal model of computation based on graphs and graph transformations.
It also shows how this formalism can be used to specify and to program object-oriented concurrent
systems.
Resumo
Este texto visa apresentar um modelo universal de computao baseado em grafos e transformaes
de grafos, e como este modelo pode ser usado para especificar e programar sistemas concorrentes
orientados a objetos.
8.1. Introduo
Programas de computador so parte integrante da vida moderna, fazendo
com que a maior parte das nossas atividades dirias dependam deles para que
possam ser realizadas. Aplicaes comuns so terminais bancrios, sistemas
de reservas de passagens, caixas de supermercado, clientes de correio eletr-
nico, processadores de texto, entre muitos outros. Servios mais sofisticados
so tambm controlados por programas, como sistemas de telecomunicaes,
controle de semforos, pilotos automticos de aeronaves e mesmo sistemas
de suporte vida utilizados em unidades de terapia intensiva em hospitais. Em
geral, tais sistemas necessitam controlar uma quantidade de componentes de
software que operam de forma simultnea. Para os usurios, de fundamen-
tal importncia que aqueles operem de forma absolutamente correta, visto que
falhas podem causar perdas tanto financeiras quanto humanas. Por exemplo,
um terminal para reservas de passagens areas necessita acessar uma base
de dados compartilhada para verificar se um assento est disponvel ou no;
pilotos automticos devem receber informaes de diversas partes da aero-
nave, bem como das condies climticas exteriores, para garantir que a rota
seja seguida apropriadamente; equipamentos de suporte vida devem moni-
torar constantemente os sinais vitais do paciente para que, em caso de algum
problema, medidas adequadas possam ser tomadas a tempo. Se uma falha
durante a execuo de um jogo ou de um editor de texto no traz problemas
387
Ferreira e Ribeiro
significativos, falhas na execuo de programas considerados crticos podem

ter conseqncias muito srias ou mesmo fatais. Mesmo com todas essas pre-
ocupaes com respeito necessidade de correo dos programas, existem
casos reportados em que falhas em dispositivos de software ou hardware cau-
saram de fato tais perdas. Um exemplo concreto e relativamente recente foi a
exploso do foguete Ariane 5 menos de quarenta segundos aps seu lana-
mento. A investigao do acidente concluiu que havia um erro no programa de
clculo da trajetria do foguete. O mesmo erro ocorreu no computador secun-
drio, e o foguete acabou sendo destrudo [Huth and Ryan 2000].
Novas tcnicas para o desenvolvimento de software surgiram nos ltimos
anos para atender s necessidades correntes de produo destes artefatos,
mas os paradigmas nos quais estas tcnicas so baseadas em especial
orientao a objeto, eventos e concorrncia apesar de fazerem com que o
processo de desenvolvimento em si seja facilitado, o teste e validao destes
sistemas tornaram-se muito mais complexos e, conseqentemente, mais sujei-
tos a erros. O cenrio atual requer tcnicas e metodologias que suportem as
necessidades do projeto e desenvolvimento de software moderno. Estas tcni-
cas devem garantir que o produto final seja consistente e completo em relao
sua especificao.
Apesar da crescente evidncia de que mtodos formais oferecem benef-
cios em termos da qualidade do produto final, esforos para a introduo des-
tes mtodos no processo de desenvolvimento inexistem na maior parte das
organizaes. A utilizao de mtodos formais na indstria freqentemente
esbarra na percepo que estes mtodos so difceis de entender e utilizar
[Arajo Jr. and Sawyer 1998]. Adicionalmente, os clientes devem participar no
processo de especificao, para garantir que as especificaes produzidas
atendem s suas necessidades. Portanto, um dos desafios mais importantes
criar mtodos formais que possam ser entendidos por todos os participantes
do processo de desenvolvimento de software. Acreditamos que gramticas de
grafos podem auxiliar na procura de uma soluo para este desafio.
Muitos dos mtodos de especificao usados na prtica so baseados em
algum tipo de diagrama, que so mais fceis de entender, mesmo por no
especialistas na rea de Computao. Visualmente simples, diagramas so
geralmente construdos a partir de regras sintticas bem definidas. Se essa
sintaxe tambm for equipada com uma semntica formal, tem-se uma lingua-
gem visual de especificao que pode ser integrada mais facilmente no pro-
cesso de desenvolvimento. Diagramas usados em processos de especificao
podem ser modelados por grafos.
Grafos so estruturas algbricas capazes de transmitir uma quantidade sig-
nificativa de informao de uma maneira compacta, visual e clara. Relaes
de qualquer ordem podem ser expressas na forma de grafos. A especificao
de sistemas computacionais com grafos oferece duas vantagens que so, em
geral, mutuamente exclusivas: (i) sendo estruturas matemticas, grafos apre-
sentam uma semntica bem definida e (ii) contando com uma apresentao
388
diagramtica, especificaes baseadas em grafos podem ser mais facilmente

entendidas e produzidas por no especialistas na rea de Computao. Assim,
tcnicas de especificao baseadas em grafos formam uma base slida para a
integrao de mtodos formais de especificao e verificao de sistemas no
processo de desenvolvimento de software [Baresi and Pezz 2000].
Sistemas baseados em regras descrevem computaes por meio de trans-
formaes locais. Transformaes aritmticas, sintticas e regras de infern-
cia so exemplos familiares. A maior vantagem dos sistemas baseados em
regras reside no fato de que a maior parte do conhecimento algortmico que
as pessoas trazem do ensino elementar e mdio baseado em regras: ns
conhecemos regras para transformar expresses matemticas em outras equi-
valentes, para calcular o valor de um elemento pertencente a uma equao,
para extrair a raiz quadrada de um nmero positivo, para achar o mnimo de
uma funo, e assim sucessivamente. Mas este conhecimento algortmico
baseado em regras no restrito Matemtica. Desde muito cedo na vida,
aprendemos a amarrar nossos sapatos, a trocar um pneu de bicicleta, a fritar
um ovo, a nos comportarmos adequadamente mesa e mesmo algumas t-
ticas para conseguir um namorado(a). Todo este conhecimento ns tambm
passamos adiante, e em geral o fazemos na forma de regras. Em Compu-
tao, reas como definio de linguagens [Hopcroft et al. 2001], programa-
o lgica e funcional [Clark and Taernlund 1982], [Sterling and Shapiro 1994],
[Reade 1995], especificao algbrica [Bergstra et al. 1989], reescrita de
termos [Gadducci 1996], [Kennaway 1995], prova automtica de teoremas
[Fitting 1996], processos concorrentes [Milner 1989] e sistemas especialistas
[Nikolopoulos 1997], [Russell and Norving 1995], [Kosko 1992] foram grande-
mente beneficiadas pela utilizao de regras.
Transformaes de grafos por meio de regras uma maneira natural
de combinar grafos, para a descrio de estruturas complexas, com re-
gras, para a manipulao destas estruturas. Sistemas de transformao
(ou reescrita) de grafos combinam as vantagens de grafos e regras em um
nico paradigma computacional [Ehrig et al. 1996b]. A teoria de sistemas de
transformaes de grafos estuda uma variedade de formalismos que expan-
dem a teoria das linguagens formais [Hopcroft 1969], [Hopcroft et al. 2001],
[Lewis and Papadimitriou 1998], [Martin 1996] para abarcar estruturas mais ge-
nricas especificadas como grafos. Todas as construes existentes na teoria
de linguagens tambm existem na abordagem baseada em grafos: regras, deri-
vaes e linguagens geradas podem ser definidas para grafos da mesma forma
que so definidas para seqncias de smbolos (strings). Uma gramtica de
grafos consiste de um grafo inicial e um conjunto de regras que transformam
grafos.
Normalmente, o objetivo de construir uma gramtica definida sobre seqn-
cias de smbolos produzir uma linguagem, a linguagem gerada pela aplica-
o das regras da gramtica a uma string inicial. Apesar de podermos fazer
o mesmo com grafos gerar linguagens onde as frases so grafos existe
389
Ferreira e Ribeiro
uma interpretao mais interessante para as gramticas de grafos: o grafo

inicial representa o estado inicial de um sistema, e as regras modelam os pos-
sveis comportamentos deste sistema. Assim, uma gramtica de grafos pode
ser vista como uma descrio formal ou modelo de um sistema. Neste caso,
os grafos gerados pela gramtica correspondem aos estados alcanados, e as
derivaes correspondem s computaes do sistema. Como os grafos so
estruturas que representam de maneira natural a distribuio de um estado, e
as regras atuam localmente (cada uma em uma poro do grafo), gramticas
de grafos podem ser usadas para modelar sistemas distribudos e concorren-
tes.
Para definir uma gramtica de grafos, precisa-se (i) escolher o tipo de grafo
adequado para representar os estados do sistema a ser modelado; (ii) definir
como podem ser as relaes entre esses grafos, que daro origem s regras;
(iii) definir como se d a aplicao de uma regra a um grafo. Neste trabalho,
apresenta-se a construo dessas definies de modo que a gramtica gerada
seja adequada para especificar sistemas que seguem o paradigma da orienta-
o a objeto.
Os princpios que regem o paradigma da orientao a objeto encapsula-
mento de dados e cdigo na mesma unidade sinttica, ocluso da informao,
herana e polimorfismo mostram-se adequados s necessidades de desen-
volvimento modular e distribudo, e de reutilizao de cdigo enfrentados por
projetistas e engenheiros de software, sendo talvez hoje o paradigma de de-
senvolvimento mais usado, tanto na indstria quanto na academia.
A herana um mecanismo central na programao orientada a obje-
tos, que suporta o projeto incremental de classes (na abordagem baseada
em classes [Cook 1990]) ou objetos (na abordagem baseada em objetos
[Ungar et al. 1991]). O mecanismo de herana permite que novas classes pos-
sam ser descritas usando a funcionalidade de classes j existentes. Este pro-
cesso gera uma hierarquia de classes onde uma classe derivada (herdeira ou
subclasse) uma verso refinada de sua classe primitiva (ancestral ou su-
perclasse) ou primitivas, dependendo se herana simples ou herana mltipla
est sendo utilizada. Uma classe derivada herda todos os dados e operaes
de suas classes primitivas, e pode adicionar novos dados e operaes, bem
como modificar operaes que j estejam definidas. A extensibilidade de clas-
ses neste paradigma suporta os requisitos de desenvolvimento incremental e
reutilizao de cdigo existentes para o desenvolvimento de grandes sistemas
de software [Breu 1991].
Juntamente com a herana, outro mecanismo fundamental da orientao
a objeto o polimorfismo. O polimorfismo pode ser descrito como a caracte-
rstica que permite que diferentes significados possam ser associados a algo
em diferentes contextos. Existem vrias formas de polimorfismo em linguagens
de programao, e a que estamos usando aqui o chamado polimorfismo de
subclasse [Cardelli and Wegner 1985]: um objeto pode pertencer a vrias clas-
ses distintas, simultaneamente. O polimorfismo de subclasse significa que uma
390
instncia de uma subclasse pode ser usada em lugares onde uma instncia da
superclasse seria esperada. Este conceito de polimorfismo pode ser exempli-
ficado pela seguinte situao: se duas classes c1 e c2 esto relacionadas via
herana, com c2 sendo uma subclasse de c1 , ento em qualquer ponto onde
um objeto da classe c1 esperado um objeto da classe c2 pode ser usado, j
objetos da classe c2 so tambm objetos da classe c1 , pois herdam todas as
caractersticas de c1 .
Polimorfismo de subclasse especialmente interessante em abordagens
orientadas a objeto que permitem que mtodos sejam sobrescritos (ou rede-
finidos). A sobrescrita de um mtodo herdado no mbito de uma classe de-
rivada permite que este mtodo possa ter uma implementao diferente do
mtodo herdado, embora ambos ainda possuam a mesma assinatura. Nes-
sas abordagens, pode ser implementada a chamada ligao dinmica, que
o mecanismo que seleciona o mtodo a ser executado baseado no tipo do ob-
jeto que executar de fato o mtodo. Como uma referncia a um objeto de
uma determinada classe pode conter objetos de classes diferentes nome-
adamente, de todas as subclasses da classe da referncia pode-se definir
um cdigo genrico que especializado em tempo de execuo pela ligao
dinmica de mtodos redefinidos. Desta forma, o cdigo a ser executado para
efetuar uma dada operao determinado em tempo de execuo, depen-
dendo do objeto que executar este cdigo. Isto d uma grande flexibilidade
ao sistema, pois uma mesma solicitao de execuo de mtodo pode ter v-
rias implementaes diferentes, dependendo do tipo do objeto que recebe esta
solicitao. A maioria das linguagens orientadas a objetos suporta a seleo do
mtodo apropriado a ser executado baseada na classe do objeto que recebe
a requisio de executar o mtodo [Campione et al. 2000], [Stroustup 2000],
[Thomas and Weedon 1997].
Existe na literatura um grande nmero de mtodos formais
[Fitzgerald et al. 2005], [CSK CORPORATION 2005], [Smith 1992],
[Smith 1999], [Goguen and Malcom 1996] e semi-formais [Booch et al. 1999]
para a especificao de sistemas orientados a objetos. Programas orientados
a objetos normalmente usam herana (que a maneira mais comum de reuso
de cdigo) e redefinio de mtodos para atingir seus objetivos. Portanto,
seria esperado que os formalismos para especificao de sistemas orientados
a objeto oferecessem construes correspondentes que refletissem esses
conceitos, caso contrrio, o formalismo iria negligenciar conceitos que tm
uma grande influncia na abordagem sendo descrita.
Mtodos para modelagem e programao de sistemas orientados a objetos
deveriam apresentar uma srie de caractersticas, entre as quais: (i) a existn-
cia de uma linguagem de especificao formal que possa ser facilmente enten-
dida tanto por desenvolvedores de software quanto por usurios finais; (ii) pos-
sibilidade de especificar aspectos estticos e dinmicos do sistema de forma
integrada, ou seja, no mesmo formalismo; (iii) a existncia de uma semntica
formal que seja compatvel com operadores de composio, para permitir o
391
Ferreira e Ribeiro
desenvolvimento modular de sistemas; (iv) a possibilidade de especificaes

mais abstratas serem refinadas em especificaes mais concretas, ou mesmo
em programas.
Uma maneira natural de modelar sistemas orientados a objetos usando
grafos representar objetos e classes como vrtices, e atributos e mensagens
como arcos. A Seo 8.3 mostra que pode-se definir grafos onde as classes
esto relacionadas por uma relao de ordem que representa a hierarquia de
herana. A relao de redefinio de mensagens (sobrescrita) determina a
relao de ordem entre mtodos em uma hierarquia de classes. Represen-
tar objetos, atributos e mtodos desta forma cria uma situao onde os grafos
no mais so definidos por conjuntos e funes, mas por conjuntos parcial-
mente ordenados e funes monotnicas, que preservam a relao de ordem
subjacente aos conjuntos. Este trabalho mostra como uma abordagem para
especificao de sistemas orientados a objetos usando grafos pode ser cons-
truda baseada nessas idias, apresentando tambm exemplos de uso dessa
abordagem.
O restante deste texto est estruturado da seguinte forma: as Sees 8.3
e 8.4 apresentam, respectivamente, os conceitos formais de grafos orientados
a objeto e de gramticas de grafos orientados a objeto, juntamente com exem-
plos que ilustram o significado e a utilizao destas estruturas. Na Seo 8.5
so apresentados exemplos de especificaes de sistemas orientados a ob-
jeto usando o formalismo apresentado na Seo 8.4. Esta parte do texto visa
mostrar que, embora a teoria por trs do formalismo seja matematicamente s-
lida, sua utilizao simples mesmo por pessoas que no tm formao em
programao (imperativa ou orientada a objeto) ou especificao formal. As
definies dos termos referentes teoria dos conjuntos e de relaes de or-
dem usadas nas definies formais das Sees 8.3 e 8.4 so apresentadas
formalmente na Seo 8.2. Se o interesse do leitor for meramente a utilizao
do formalismo, estes conceitos podem ser ignorados em uma primeira leitura
deste material; contudo, se o leitor tem interesse em trabalhar e entender con-
ceitos mais aprofundados sobre este mtodo de especificao, o material desta
seo de maior valia.
8.2. Fundamentos matemticos

Sendo um mtodo formal de especificao, natural que os conceitos de
gramticas de grafos orientados a objeto sejam explicados em termos de cons-
trues matemticas. Esse fato, contudo, no deve assustar o leitor. Mate-
mtica, no mbito da Cincia da Computao, alm de permitir demonstra-
es de propriedades e solues de problemas, tambm uma linguagem, e
como tal serve para expressar conceitos de forma clara e sem ambigidade.
Como toda linguagem, tambm, inicialmente pode se mostrar difcil de enten-
der, mas medida que vamos adquirindo fluncia, conseguimos ver suas van-
tagens de maneira mais clara. Assim, apesar de ser possvel entender uma
especificao escrita neste formalismo sem conhecer em detalhe toda a teoria
392
envolvida, interessante conhecer tambm as definies matemticas que a

sustentam. Qualquer desenvolvimento, terico ou aplicado, sobre essa teoria
depende disso.
Nesta seo so apresentados os fundamentos matemticos sobre os
quais a teoria de gramtica de grafos orientados a objeto se sustenta. A leitura
desta seo opcional para quem j possui os conhecimentos bsicos de te-
oria dos conjuntos, funes, relaes e teoria de ordem. Todas as definies
esto numeradas e so referenciadas no texto, sendo assim, quando houver
qualquer dvida o leitor pode facilmente consultar a definio pertinente ao
entendimento do texto.
8.2.1. Conjuntos, funes e relaes

A teoria de conjuntos vista desde o ensino fundamental, embora muitas
vezes suas construes no sejam descritas de maneira precisa. Um con-
junto, matematicamente falando, simplesmente uma coleo (finita ou infi-
nita) de elementos. Um conjunto pode ser representado como uma enumera-
o de seus elementos, entre chaves. Por exemplo, {a, b, c}, {gato, cachorro,
papagaio} e {0, 1, 01, 10, 11, 001, 010, . . .} so representaes vlidas de conjun-
tos. As reticncias no final de um conjunto indicam um conjunto infinito mas
cujos elementos obedecem a um certo padro: o conjuntos dos nmeros na-
turais, N, por exemplo, pode ser representado como {1, 2, 3, 4, . . .}. Quando
um conjunto infinito, mas quando o padro dos elementos no bvio as-
sim, pode-se representar o conjunto por propriedades de seus elementos. Por
exemplo, um nmero par tem a propriedade de ser divisvel por 2, onde o resto
da diviso zero. Desta forma, podemos representar o conjunto dos nmeros
pares por
Pares = {x N | x mod 2 = 0}
onde smbolo | lido como tal que. Ou seja, o conjunto dos nmeros pares
contm todos os elementos x (que pertencem ao conjunto N e portanto so
nmeros naturais) tal que o resultado da diviso inteira desse nmero x por
2 tem resto igual a zero. Ao longo deste texto sero apresentados diversos
conjuntos definidos por propriedades. A operao mais importante, do ponto de
vista do restante deste texto, sobre conjuntos o produto cartesiano, conforme
definido a seguir.
Definio 8.2.1 (Produto cartesiano) Sejam A e B dois conjuntos. O produto

cartesiano de A com B definido como o conjunto A B = {(a, b) | a A, b B}.
Definio 8.2.2 (Produto cartesiano generalizado) Sejam A1 , A2 , . . . , An , n >

1, conjuntos. O produto cartesiano generalizado destes conjuntos definido
como o conjunto A1 A2 . . . An = {(a1 , a2 , . . . , an ) | ai Ai , i = 1, . . . , n}.
Exemplo 8.2.1 (Produto cartesiano) A operao de produto cartesiano so-

bre conjuntos aparece com freqncia em muitas aplicaes utilizadas na Ci-
ncia da Computao. A seguir mostramos alguns exemplos:
393
Ferreira e Ribeiro
dados dois conjuntos A = {a, b, c} e B = {1, 2}, o produto cartesiano de A

com B dado pelo conjunto A B = {(a, 1), (a, 2), (b, 1), (b, 2), (c, 1), (c, 2)};
em geometria analtica, usamos o termo R2 para indicar o plano car-
tesiano; R2 , no entanto, significa R R, ou seja, o produto cartesi-
ano do conjunto dos nmeros reais, R, com ele prprio. Por definio,
R2 = R R = {(x, y) | x R, y R}, ou seja, o plano cartesiano na reali-
dade o conjunto de todos os pontos (x, y) que perfazem este plano;
se quisermos trabalhar com representao de elementos no espao, pre-
cisamos de uma coordenada adicional, ento o conjunto R3 o produto
cartesiano generalizado R R R = {(x, y, z) | x R, y R, z R};
quando se define uma estrutura de dados de tipo registro (record, em
Pascal, struct em C), estamos de fato definindo um produto cartesiano.
Imagine que temos o seguinte cdigo (em Pascal):
type data = record
dia: integer;
mes: integer;
ano: integer;
feriado: boolean;
end;
ento data o conjunto formado pelos elementos {(dia, mes, ano,
feriado) | dia, mes, ano Z, feriado {true, false}}, ou seja, data =
Z Z Z {true, false}.
As noes mais importantes das quais necessitamos para entender o res-

tante deste texto so as de relao e funo.
Definio 8.2.3 (Relao) Sejam A1 , A2 , . . . , An conjuntos. Uma relao n-ria

R sobre os conjuntos A1 , A2 , . . . , An qualquer subconjunto do produto cartesi-
ano A1 A2 . . . An .
Matematicamente, uma relao um subconjunto de um produto carte-

siano. Para relembrarmos, um produto cartesiano um construtor de tuplas
ordenadas, onde cada um dos elementos pertence a um dos conjuntos ope-
randos. Podemos relacionar diversas coisas ou pessoas. Por exemplo, toda
conta bancria tem um titular, todas as pessoas tm uma data de nascimento,
todas as casas tm um endereo, e assim sucessivamente. o Exemplo 8.2.2
apresenta mais exemplos de relaes, sob o ponto de vista de sua definio.
Exemplo 8.2.2 (Relao) Vejamos ento, como podemos expressar uma re-
lao matematicamente: imagine que queremos relacionar todas as pessoas
com seu respectivos pais, por meio de uma relao que vamos chamar de R.
Um pai ou me de algum tambm uma pessoa, ento podemos construir
todas as triplas ordenadas ( f , p, m), onde cada um desses elementos pertence
394
ao conjunto P das pessoas. No entanto, esta tripla s vai pertencer relao R

se o elemento f tiver como pai o elemento p e como me o elemento m. Sendo
assim, se construirmos todas as combinaes possveis (x, y, z) P P P, a
relao R (que contm as triplas onde o primeiro elemento filho do segundo
com o terceiro, ento claramente R P.
Outro exemplo, agora retirado do mbito da Cincia da Computao: as
possibilidades de valores em uma linha de uma tabela de um banco de da-
dos podem ser vistas como um produto cartesiano dos tipos dos elementos
relacionados. Por exemplo, uma tabela que mantm dados sobre funcionrios
de uma empresa, como por exemplo nome, cargo, salrio e tempo de servio,
pode ser vista como um subconjunto do produto cartesiano Nome Cargo
R N, onde Nome um conjunto de nomes de pessoas, Cargo o conjunto
dos cargos que a empresa tem, R o conjunto dos nmeros reais e N o con-
junto dos nmeros naturais. A tabela, contudo, no ter todas as possibilidade
de tuplas desse conjunto (at porque esse nmero infinito), mas ter exa-
tamente o nmero de linhas que o nmero de funcionrios da empresa, com
seus respectivos nomes, cargos, salrios e tempos de servio. Esses dados
so claramente um subconjunto de todos os dados possveis, o que caracteriza
matematicamente uma relao.
Algumas relaes tm propriedades especiais, e as relevantes para este

texto so listadas a seguir:
Definio 8.2.4 (Relaes binrias) Uma relao R dita binria se for uma
relao 2-ria. Uma relao binria R A A dita
reflexiva, se sempre que a A ento (a, a) R.
simtrica se sempre que (a, b) R ento (b, a) R.
antisimtrica se sempre que (a, b) R e (b, a) R ento a = b.
transitiva, se sempre que (a, b) R e (b, c) R ento (a, c) R.
Exemplo 8.2.3 (Relaes binrias) Um exemplo de relao reflexiva a re-

lao de igualdade = sobre os reais: para todo nmero real r R temos que
r = r. Um exemplo de relao simtrica a relao ser casado com: para
quaisquer duas pessoas x e y, se x casado com y, ento y casado com x.
Um exemplo de relao antisimtrica a relao de comparao entre reais 6:
se x 6 y e y 6 x, ento naturalmente temos que x = y. Um exemplo de relao
transitiva a relao binria ser antepassado de, sobre o conjunto das pes-
soas: se x antepassado de y e se y antepassado de z, ento x tambm
antepassado de z.
Definio 8.2.5 (Funo) Uma funo n-ria f uma relao (n + 1)-ria

R A1 A2 . . . An B, tal que para quaisquer tuplas (a1 , a2 , . . . , an , b) e
(a1 , a2 , . . . , an , b0 ) R, onde a1 A1 , a2 A2 , . . . , an An e b, b0 B, tem-se que
b = b0 . Neste caso escreve-se f : A1 A2 . . . An B, onde A1 A2 . . . An
chamado de domnio e B chamado de contradomnio da funo.
395
Ferreira e Ribeiro
Esta definio de funo pode parecer muito diferente daquilo que aprende-
se na escola a chamar de funo, mas de fato somente sua caracterizao
formal. Usualmente, uma funo matemtica representada pela sua lei de
formao, por exemplo, f (x) = x2 . Essa forma de representao contm infor-
mao sobre a funo, mas esta informao no completa. Para descrever
uma funo tambm fundamental informar o seu domnio de definio (quais
so os elementos aos quais a funo dever ser aplicada) e o seu contradom-
nio (em que conjunto esto as imagens dos elementos resultantes da aplicao
da funo). Naturalmente que o domnio e a lei de formao da funo definem
o seu contradomnio. No caso da funo f , seu domnio pode ser o conjunto
dos nmeros naturais, dos inteiros, dos reais, dos complexos ou qualquer sub-
conjunto finito ou infinito destes, embora usualmente as funes matemticas
tenham como domnio implcito o conjunto R, a no ser que algo seja dito em
contrrio. Uma funo, contudo, no precisa ter somente um argumento. A
funo que, dado um ponto (x, y)1 no p plano retorna a distncia deste ponto at
a origem (0, 0) dada por d(x, y) = x2 + y2 . A funo d : R R R neste
caso, recebe como argumentos dois valores reais x e y (ou um p par ordenado
de valores reais (x, y)) e retorna o valor real correspondente a x2 + y2 . Assim,
pode-se representar a funo d : R R R pcomo uma relao contida no con-
junto R R R, definida como d = {(x, y, x2 + y2 ) | x, y R}, e naturalmente
que d R R R. Ou seja, toda funo que recebe n argumentos pode ser
representada por uma relao n + 1-ria (uma relao em que suas tuplas tm
n+1 elementos) onde os primeiros n elementos so os argumentos da funo e
o ltimo elemento o resultado da aplicao da funo aos seus n argumentos.
Assim, a funo f (x) = x2 pode ser igualmente representada por uma relao
que contm os pares ordenados (1, 1), (1, 1), (3, 9), (5, 25) e assim sucessi-
vamente (para todos os valores possveis). Formalmente, a relao f pode ser
definida como f = {(x, x2 ) |px R}.
As relaes d = {(x, y, x2 + y2 ) | x, y R} e f = {(x, x2 ) | x R} definidas
acima so funes porque a lei de formao assegura que para quaisquer ar-
gumentos das funes, seu resultado, isto , o ltimo elemento da tupla,
nico. Existe somente uma distncia de um ponto origem, e existe somente
um quadrado de um nmero.
Definio 8.2.6 (Funo total, funo parcial) Sejam D e C dois conjuntos.

Uma funo f : D C dita total se, para todo elemento x D existe um ele-
mento f (x) C. Uma funo dita parcial se existe pelo menos um elemento
x D que no mapeado por f .
Toda funo parcial f : D C pode ser fatorizada em duas funes totais,
f ? : dom( f ) D e f ! : dom( f ) C, onde dom( f ) D contm exatamente os
elementos mapeados por f , f ? a funo de incluso desse subconjunto em
1Note que este um par ordenado pertencente ao conjunto resultante do produto carte-
siano R2 = R R.
396
D ( f ?(x) = x, para qualquer x dom( f )) e f ! a funo f restrita aos elementos

de seu domnio ( f !(x) = f (x), para qualquer x dom( f )). Quando uma funo
a restrio de outra a algum subconjunto de seu domnio usa-se o operador
| para denotar este fato. No caso anterior, escreve-se que f ! = f |dom( f ) .
Dadas duas funes f : A B e g : B C, define-se a composio de f
com g, denotada por g f : A C a funo que a cada elemento do domnio
x A faz corresponder o elemento g( f (x)) C.
Usualmente, em matemtica, trabalha-se com funes totais. Em Compu-

tao, no entanto, funes parciais aparecem em vrias situaes. Um pro-
grama, por exemplo, pode ser matematicamente descrito como uma funo,
que mapeia entradas em sadas. A prpria noo de funo nas linguagens
de programao implementa a noo matemtica de funo: o cabealho de
uma funo descreve seu nome, seu domnio e seu contradomnio enquanto
que o seu corpo descreve sua lei de formao. Por exemplo, o seguinte trecho
de cdigo em Pascal
function dist (x1,y1: real; x2,y2:real):real;

begin
dist := sqrt(sqr(x2-x1)+sqr(y2-y1));
end;
descreve a funo que calcula a distncia entre dois pontos que possuem co-
ordenadas (x1 , y1 ) e (x2 , y2 ). Note que o cabealho da funo descreve o seu
domnio (na forma do tipo de seus parmetros formais) e seu contradomnio
(no tipo de retorno da funo). Ou seja, o cabealho da funo Pascal dist
o equivalente da definio matemtica dist p : R R R R R, onde a sua lei
de formao dada por dist(x1 , y1 , x2 , y2 ) = (x2 x1 )2 + (y2 y1 )2 .
A diferena entre funes totais e funes parciais reside no fato de que
nestas ltimas nem todos os elementos do domnio so mapeados. Em um
programa, isso corresponde ao fato de que no existem sadas com significado
para todas as possibilidades de valores de entrada. O resultado da aplicao
de uma funo parcial a um elemento que no pertence ao seu domnio de
definio (ou seja, que no mapeado pela funo) indefinido, e usualmente
representado pelo smbolo .
Exemplo 8.2.4 (Funo parcial) Seja a funo f : N N definida como

x+1 x mod 2 = 0
f= (1)
x mod 2 6= 0

Na Figura 8.1 pode-se ver essa funo graficamente representada. Note que
somente os elementos pares do domnio so mapeados para os seus respec-
tivos sucessores no contradomnio da funo.
397
Ferreira e Ribeiro
Figura 8.1. Exemplo de uma funo parcial
Conforme a Definio 8.2.6, toda funo parcial f pode ser decomposta em

duas funes totais f ! e f ?, chamadas respectivamente funes de restrio
e incluso de f . Na sua definio, em (1), a funo f tem como domnio o
conjunto dos nmeros naturais N, mas somente os elementos pares so efeti-
vamente mapeados pela funo. Se formarmos um conjunto destes elementos
mapeados, que um subconjunto do domnio original da funo, ento qual-
quer funo que seja igual a f para estes elementos ser uma funo total. Da
mesma forma, uma funo de incluso do conjunto dos nmeros pares para o
conjunto dos nmeros naturais sempre pode ser construda.
Chama-se dom( f ) o conjunto que representa o domnio de definio da
funo f . Para o exemplo acima, dom( f ) = Pares N, e a funo de restrio
f ! : Pares N definida como f !(x) = x + 1 = f (x). A funo de incluso f ? :
Pares N dada por f ?(x) = x, ou seja, identifica os elementos do domnio
de definio com eles mesmos no domnio da funo f (note que o domnio
de f ! e f ? diferente do domnio de f ). A Figura 8.2 mostra graficamente a
decomposio da funo f definida acima nas funes f ! e f ?.
Funes podem apresentar propriedades em relao ao tipo de mapea-

mento que realizam. Em particular, diz-se que uma funo f : A B, total ou
parcial,
injetora se a cada dois elementos distintos do domnio correspondem
dois elementos distintos no contradomnio, ou seja, se para quaisquer
x, y dom( f ) ento x 6= y f (x) 6= f (y);
sobrejetora se todos os elementos do contradomnio encontram-se na
imagem da funo, ou seja, se para qualquer y B existe algum x A tal
que f (x) = y;
398
Figura 8.2. Decomposio de uma funo parcial em

duas funes totais
bijetora, se for simultaneamente injetora e sobrejetora.
8.2.2. Relaes de ordem parcial

Ordenaes de elementos aparecem em todas as reas do conhecimento
humano. Sempre que as palavras antes e depois aparecem em alguma frase
ou contexto, temos uma ordem estabelecida sobre as entidades das quais se
est a falar. A construo matemtica que representa uma ordenao uma
relao de ordem, que nada mais do que uma relao transitiva entre os
elementos que devem ser ordenados. Neste trabalho ser usada uma relao
de ordem parcial, que um caso especial de uma relao de ordem, e que
aparece com freqncia em muitos domnios da Cincia da Computao.
Definio 8.2.7 (Relao de ordem parcial) Uma relao binria R A A

uma relao de ordem parcial se e somente se for reflexiva, antisimtrica e
transitiva.
Exemplo 8.2.5 (Relaes de ordem parcial) Algumas relaes bem conhe-

cidas so de ordem parcial. A seguir, alguns exemplos familiares:
A relao 6 sobre o conjunto dos nmeros reais uma relao de or-

dem parcial: para qualquer nmero x R tem-se que x 6 x (reflexividade),
para quaisquer trs nmeros reais x, y, z R (no necessariamente dis-
tintos), se x 6 y e y 6 z ento x 6 z (transitividade) e para quaisquer dois
nmeros reais x, y R, sempre que x 6 y e y 6 x pode-se concluir que
x = y (antissimetria). Esta relao ainda uma relao de ordem total,
visto que para quaisquer dois nmeros reais x, y R, tem-se que ou x 6 y
ou y 6 x.
399
Ferreira e Ribeiro
A relao sobre conjuntos tambm uma relao de ordem parcial:

para qualquer conjunto A tem-se que A A (reflexividade), para quais-
quer trs conjuntos A, B e C, se A B e B C ento A C (transitividade)
e para quaisquer dois conjuntos A e B, sempre que A B e B A pode-se
concluir que A = B (antissimetria). Diferentemente, contudo, da relao
6, ela no uma ordem total.
A relao de subtipagem em linguagens de programao (no sentido
de possuir uma estrutura pertencente, totalmente ou em parte, a outro
tipo) tambm uma relao de ordem parcial: para qualquer tipo defi-
nido pelo usurio T tem-se que T T (reflexividade, visto que um tipo
estruturalmente idntico a si prprio), para quaisquer trs tipos T , T 0 e
T 00 , se T T 0 e T 0 T 00 ento T T 00 (transitividade) e para quaisquer
dois tipos T e T 0 , sempre que T T 0 e T 0 T pode-se concluir que T = T 0
(antissimetria). Esta relao tambm no uma ordem total.
Definio 8.2.8 (Conjunto parcialmente ordenado) Um conjunto parci-

almente ordenado (ou simplesmente poset) Pv = hP, vP i um conjunto P
juntamente com uma relao de ordem parcial vP sobre P.
Funes entre conjuntos parcialmente ordenados em geral exigem que a

ordem existente entre os elementos seja preservada. Isso quer dizer que se
dois elementos no domnio de definio da funo esto ordenados, suas ima-
gens devem estar ordenadas tambm. A definio formal desta construo,
bem como alguns exemplos, encontram-se a seguir.
Definio 8.2.9 (Funo monotnica) Sejam hP, vP i e hQ, vQ i dois conjun-

tos parcialmente ordenados. Uma funo f : P Q chamada funo monot-
nica se e somente se, para quaisquer p, p0 P, se pvP p0 ento f (p)vQ f (p0 ).
Exemplo 8.2.6 (Funo monotnica) Uma funo monotnica uma funo

que preserva a ordem dos elementos de seu domnio quando suas imagens
so comparadas usando a relao de ordem do seu contradomnio. A seguir
alguns exemplos de funo monotnicas e de funes no monotnicas, todas
definidas sobre o conjunto parcialmente ordenado hZ, 6i (os nmeros inteiros
e a relao usual menor ou igual entre eles).
Seja f : hZ, 6i hZ, 6i a funo cuja lei de formao dada por f (x) =
x + 1. Esta funo monotnica, visto que para quaisquer dois nmeros
inteiros m, n Z, temos que, se m 6 n (isto , se os elementos esto
relacionados na origem) ento f (m) 6 f (n). fcil provar que isso
verdade: se m 6 n, f (m) = m + 1 6 f (n) = n + 1 m + 1 6 n + 1 m + 1 6
n + 1 m 6 n (que a premissa da nossa suposio, e logo verdade).
A funo g(x) = |x| (mdulo) contudo, no uma funo monotnica.
fcil achar um contra-exemplo neste caso: sabe-se que 5 6 2, con-
tudo | 5| = 5 6/ 2 = | 2|.
400
As definies dadas a seguir so pertinentes teoria de ordem. A estrutura

grfica de uma relao de ordem parcial um grafo sem ciclos que passam por
dois elementos distintos, visto que para uma relao ser de ordem parcial ela
deve ser antissimtrica, o que exclui a existncia de caminhos circulares de
comprimento maior que 1 (um). Laos, contudo, so permitidos, visto que a
relao tambm deve ser reflexiva.
Se temos uma estrutura grfica desta forma, ento faz sentido falar nos
elementos que esto acima ou abaixo de outros na relao, apesar de estes
termos usualmente denotarem relaes espaciais. Assim, se dado um con-
junto parcialmente ordenado hP, vP i, se temos elementos relacionados x vP y e
y vP z, ento x est abaixo de y e z nesta relao, z est acima de x e de y e y
est entre x e z. As prximas definies do conta da definio dos conjuntos
dos elementos que esto acima ou abaixo de algum elemento (ou conjunto
de elementos) dado.
Definio 8.2.10 (Conjunto superior, conjunto inferior) Seja hP, vP i um

conjunto parcialmente ordenado. um subconjunto A P um conjunto superior
se sempre que x A, y P e x vP y tem-se que y A. O conjunto superior de
{x}, onde x P (tambm chamado o conjunto de todos os elementos acima de
x) denotado por x.
Dualmente, um subconjunto A P um conjunto inferior se x A implica
em y A para todo y v x. O conjunto de todos os elementos abaixo de um
elemento x A denotado por x.
Definio 8.2.11 (Limitante superior, limitante inferior) Seja hP, vP i um

conjunto parcialmente ordenado. Um elemento x P dito um limitante
superior de um subconjunto A P, escrito A v x, se e somente se a v x para
todo a A. O conjunto de todos os limitantes superiores de A denotado por
ub(A)
Dualmente, um elemento x P dito um limitante inferior de um subcon-
junto A P, escrito x v A, se e somente se x v a para todo a A. O conjunto de
todos os limitantes inferiores de A denotado por lb(A).
Definio 8.2.12 (Supremo (lub, join), nfimo (glb, meet)) Seja hP, vP i um
conjunto parcialmente ordenado. Se, para um subconjunto A P o seu con-
junto de limitantes superiores possuir um menor elemento x, ento x cha-
mado de menor limitante superior, ou supremo ou ainda join de A e escreve-se
x = lub(A) ou x = tA.
Dualmente, se, para um subconjunto A P o seu conjunto de limitantes
inferiores possuir um maior elemento x, ento x chamado de maior limitante
inferior, ou nfimo ou ainda meet de A e escreve-se x = glb(A) ou x = uA.
8.2.3. Grafos e morfismos de grafos

Os cursos da rea de Computao e Informtica usualmente possuem dis-
ciplinas de Estruturas de Dados ou de Teoria dos Grafos onde estas estruturas
401
Ferreira e Ribeiro
so vistas. Supe-se que o leitor j conhece estas estruturas, pelo menos de

maneira superficial. A seguir apresenta-se o que um grafo formalmente, e
como estas estruturas podem ser relacionadas algebricamente.
Definio 8.2.13 (Grafo) Um grafo uma tupla G = hV, Ei onde V o conjunto

de nodos (ou vrtices) do grafo e E V V uma relao binria sobre V . O
conjunto E denominado conjunto de arcos (ou arestas) de G.
Um grafo pode ento ser visto como um conjunto de elementos e uma rela-
o binria sobre estes elementos. Contudo, em alguns casos podemos querer
representar multigrafos, que so grafos que possuem mais do que uma aresta
entre os mesmos dois nodos. Estas situaes podem acontecer para mode-
lar, por exemplo, caminhos diretos distintos entre a mesma origem e o mesmo
destino, ou atributos diferentes de um mesmo objeto que tm o mesmo tipo.
Neste caso, a Definio 8.2.13 no adequada. A razo que, sendo uma
relao um conjunto, elementos iguais so identificados como sendo o mesmo
elemento. Desta forma, duas arestas distintas, mas como mesma origem v e
destino u, seriam representadas como o par ordenado (u, v). Como deixaria
de existir uma bijeo entre os arcos do grafo e o conjunto que os representa,
no se pode reconstruir o grafo a partir de sua definio matemtica. Logo,
precisamos de uma definio formal que contemple esta situao.
Definio 8.2.14 (Grafo) Um grafo uma tupla G = hVG , EG , srcG , tarG i onde
VG um conjunto de vrtices, EG um conjunto de arcos, srcG : EG VG a
funo que para cada arco retorna seu nodo de origem e tarG : EG VG a
funo que para cada arco retorna seu nodo de destino.
A Definio 8.2.14 permite que um grafo tenha tantas arestas paralelas

entre dois nodos quantas forem necessrias: note que o conjunto de arcos
no mais uma relao binria sobre o conjunto de vrtices, mas um conjunto
independente deste, que serve para nomear as arestas. As funes src e tar
relacionam, para cada aresta e E, os seus respectivos nodos de origem e
destino.
Relaes ou mapeamentos entre grafos podem ser expressos por morfis-
mos. O termo morfismo usado para expressar relacionamentos entre estru-
turas algbricas, e nada mais do que uma ou mais funes que preservam a
estrutura que est sendo mapeada. As Definies 8.2.15 e 8.2.16 apresentam,
respectivamente, o que se entende por um mapeamento total e um mapea-
mento parcial de grafos.
Definio 8.2.15 (Morfismo total de grafos) Sejam G1 = hVG1 , EG1 , srcG1 ,

tarG1 i e G2 = hVG2 , EG2 , srcG2 , tarG2 i dois grafos. Sejam hV : VG1 VG2 e
hE : EG1 EG2 duas funes totais. O par ordenado h = hhV , hE i : G1 G2 um
morfismo total de grafos entre G1 e G2 se e somente se hV srcG1 = srcG2 hE
e hV tarG1 = tarG2 hE . Um morfismo total de grafos dito injetor (sobrejetor,
bijetor) se as suas funes componentes so injetoras (sobrejetoras, bijetoras).
402
Figura 8.3. Circuito digital como um grafo rotulado
Definio 8.2.16 (Morfismo parcial de grafos) Seja G = hVG , EG , srcG , tarG i

um grafo. Um grafo S = hVS , ES , srcS , tarS i dito um subgrafo de G, escrevendo-
se S G ou S , G, se e somente se VS VG , ES EG , srcS = srcG |ES e
srcS = tarG |ES . Um morfismo parcial de grafos h entre dois grafos G1 e G2
um morfismo total de grafos de algum subgrafo dom(h) , G1 para G2 . dom(h)
chamdo de domnio de h.
Um morfismo total ou parcial de grafos preserva a estrutura no seguinte

sentido: para qualquer aresta mapeada pelo morfismo, se verificarmos qual
seu nodo de origem no grafo de origem do mapeamento e depois mapearmos
este nodo, temos que chegar exatamente no mesmo lugar que chegaramos
se primeiro mapessemos a aresta e da verificssemos qual o nodo de ori-
gem da aresta mapeada no grafo destino. Esta correspondncia deve existir
tambm em relao aos nodos destino dos arcos mapeados.
Grafos podem ainda ser equipados com informaes adicionais, que po-
dem ser usadas para diferenciar certos tipos de nodos ou de arcos. Considere,
por exemplo, o circuito apresentado na Figura 8.3. O desenho de um circuito
lembra muito a estrutura de um grafo: pode-se imaginar que as entradas, as
sadas e as portas lgicas so nodos e as ligaes entre estas entidades so
as arestas do grafo. No entanto, existe informao adicional sobre os nodos,
necessrios para diferenci-los. Afinal, uma porta or diferente de uma porta
and, tanto em termos de representao quanto em termos operacionais.
Existem duas maneiras de representar tipos de nodos e de arestas em um
grafo: a primeira utilizando um grafo rotulado, que contm informaes sobre
rtulos e funes de rotulao dos elementos do grafo; a segunda maneira
utiliza grafos tipados, que so grafos ordinrios mapeados para um grafo tipo
403
Ferreira e Ribeiro
via um morfismo total de grafos (Definio 8.2.15). A definio de grafo rotulado

dada a seguir. A definio de grafo tipado deixada para a Seo 8.3.2 onde
ser apresentado o conceito nos termos da orientao a objeto, que o foco
deste trabalho.
Definio 8.2.17 (Grafo rotulado) Um grafo rotulado G uma tupla ordenada

G = (V, E, LV , LE , src,tar, labV , labE ) onde V um conjunto de vrtices, E
um conjunto de arestas, LV e LE so, respectivamente, o conjunto de rtulos
de vrtices e de arestas, src,tar : E V so funes, denominadas origem e
destino, que associam a cada aresta do grafo G seus correspondentes nodos
de origem e destino, labV : V LV a funo de rotulao dos vrtices e
labE : E LE a funo de rotulao dos arcos.
Exemplo 8.2.7 (Grafo rotulado) A Figura 8.3 apresenta um esquema de cir-

cuito digital, contendo portas lgicas e conexes entre elas. Cada cone-
xo liga exatamente duas portas, uma entrada a uma porta ou uma porta
sada. Sendo assim, pode-se representar a estrutura de um circuito l-
gico como um grafo. Nesta representao, as portas lgicas, as entradas e
a sadas so os nodos enquanto que as conexes entre elas so as ares-
tas do grafo. Formalmente, este grafo pode ser representado pelos conjun-
tos V = {x1 , x2 , x3 , x4 , x5 , x6 , x7 , x8 , s, p1 , p2 , p3 , p4 , p5 , p6 , p7 , p8 } (vrtices) e E =
{a1 , a2 , a3 , a4 , a5 , a6 , a7 , a8 , a9 , a10 , a11 , a12 , a13 , a14 , a15 , a16 , a17 } (arestas) e pelas
funes src e tar descritas abaixo:
src(a1 ) = x1 src(a8 ) = x8 src(a15 ) = p6 tar(a4 ) = p2 tar(a11 ) = p6

src(a2 ) = x2 src(a9 ) = p1 src(a16 ) = p7 tar(a5 ) = p3 tar(a12 ) = p7
src(a3 ) = x3 src(a10 ) = p2 src(a17 ) = p8 tar(a6 ) = p3 tar(a13 ) = p7
src(a4 ) = x4 src(a11 ) = p3 tar(a7 ) = p4 tar(a14 ) = p8
src(a5 ) = x5 src(a12 ) = p3 tar(a1 ) = p1 tar(a8 ) = p4 tar(a15 ) = p8
src(a6 ) = x6 src(a13 ) = p4 tar(a2 ) = p1 tar(a9 ) = p5 tar(a16 ) = p8
src(a7 ) = x7 src(a14 ) = p5 tar(a3 ) = p2 tar(a10 ) = p5 tar(a17 ) = s
No entanto, uma porta NAND diferente de uma porta OR, por exemplo. A
sada de uma porta depende das suas entradas e de qual porta lgica estamos
falando. Assim, embora conexes entre portas, entradas e sadas sejam sem-
pre idnticas, os nodos do grafos pertencem a classes de elementos distintas.
Podemos inserir esta informao adicional em um grafo por meio de rtulos.
Tanto arestas quando vrtices podem ser rotulados, embora neste caso s faa
sentido rotular os nodos, que so os elementos que efetivamente devem conter
informao adicional. No caso deste circuito lgico, pode-se criar o conjunto
de rtulos Portas = {OR, AND, NAND, NOR, XOR, NOT, entrada, sada}, e uma
funo que, para cada nodo, devolva o seu rtulo correspondente. Para o grafo
da Figura 8.3, a funo de rotulao dos nodos labV : V Portas dada por
404
labV (x1 ) = entrada labV (x7 ) = entrada labV (p4 ) = NAND

labV (x2 ) = entrada labV (x8 ) = entrada labV (p5 ) = OR
labV (x3 ) = entrada labV (s) = sada labV (p6 ) = NOT
labV (x4 ) = entrada labV (p1 ) = NAND labV (p7 ) = AND
labV (x5 ) = entrada labV (p2 ) = AND labV (p8 ) = OR
labV (x6 ) = entrada labV (p3 ) = NOR
A rotulao dos arcos, visto que todos eles correspondem mesma entidade
lgica, dada por uma funo labE : E {} que tem como domnio o conjunto
de arcos do grafo e como contradomnio um conjunto unitrio. Para todo arco
e E, labE (e) = , o que significa que todos os arcos possuem o mesmo rtulo.
Desta forma, a informao relevante sobre o tipo de cada porta carregada
junto ao grafo, que pode ser reconstrudo a partir de sua definio matemtica.
Da mesma forma que relaes (Definio 8.2.3) no precisam necessa-

riamente ser binrias, tambm arcos de um grafo no necessitam conectar
somente dois nodos (um de origem e outro de destino). Um grafo cujos arcos
representam relacionamentos entre elementos de um conjunto (os nodos, no
caso) pode ser visto como uma relao binria sobre esse conjunto. Se quiser-
mos implementar visualmente uma relao de aridade maior, precisamos da
noo de hipergrafo. Um hipergrafo um grafo onde os arcos no se restrin-
gem a ter exatamente um nodo de origem e outro nodo de destino. Os arcos de
um hipergrafo, denominados hiperarcos, podem ter qualquer nmero de nodos
de origem e qualquer nmero de nodos de destino, inclusive zero.
Para definirmos formalmente um hipergrafo, precisamos de algumas de-
finies tiradas da teoria de linguagens formais. A noo de seqncia de
smbolos de um alfabeto uma delas.
Definio 8.2.18 (Alfabeto, string) Um alfabeto qualquer conjunto finito

de smbolos. Uma string ou palavra w sobre o alfabeto uma seqncia de
smbolos w1 . . . wn , n > 0, onde cada wi , i = 1, . . . , n. Uma seqncia de zero
elementos sobre chamada palavra vazia e denotada pelo smbolo . O
conjunto de todas as strings finitas sobre denotado por .
Definio 8.2.19 (Hipergrafo) Um hipergrafo H uma tupla hVH , EH , srcH ,

tarH i onde VH um conjunto de vrtices, EH um conjunto de (hiper)arcos
e srcH ,tarH : EH VH so, respectivamente, as funes de origem e destino
dos hiperarcos.
Os elementos de VH so strings sobre o conjunto VH , que considerado

um alfabeto como na Definio 8.2.18. Um hipergrafo uma generalizao de
um grafo para suportar relaes de aridade maior que 2 (binrias). Concre-
tamente, a diferena de um hipergrafo para um grafo definido da forma usual
(Definio 8.2.14) que os arcos do primeiro (denominados hiperarcos) podem
ter vrios (ou nenhum) nodo de origem e/ou destino.
405
Ferreira e Ribeiro
Figura 8.4. Exemplo de hipergrafo
Exemplo 8.2.8 (Hipergrafo) A Figura 8.4 mostra um exemplo de hipergrafo.

Aqui, os nodos so representados por retngulos vazados e os hiperarcos por
quadrados preenchidos e suas ligaes com seus nodos de origem e des-
tino. Os nodos origem ligam-se ao hiperarco com linhas cheias, enquanto que
o hiperarco conecta-se ao(s) seu(s) nodo(s) destino atravs de setas. Neste
exemplo, para o hiperarco H apresentado, o conjunto de nodos VH contm
sete elementos, a saber {n1, n2, n3, n4, n5, n6, n7}. O conjunto de hiperarcos
EH = {h1, h2, h3} contm trs elementos. As funes de origem (srcH : EH VH )
e destino (tarH : EH VH ) dos hiperarcos so definidas como se segue:
srcH (h1) = n1 tarH (h1) = n3

srcH (h2) = n1 n3 tarH (h2) = n2 n4 n4
srcH (h3) = n5 n7 tarH (h3) = n4 n6
Morfismos totais e parciais de hipergrafos podem ser definidos da mesma

forma que para grafos, a nica diferena que agora os mapeamentos de
arcos devem preservar uma seqncia de nodos, que verificada nodo a nodo,
conforme as Definies 8.2.20 e 8.2.21.
Definio 8.2.20 (Morfismo total de hipergrafos) Sejam H1 = hVH1 , EH1 ,

srcH1 , tarH1 i e H2 = hVH2 , EH2 , srcH2 , tarH2 i dois hipergrafos. Sejam hV : VH1 VH2
e hE : EH1 EH2 duas funes totais, onde hV : VH1 VH2 a extenso
da funo hV para strings, tal que, para qualquer string w = w1 . . . wn VH1 ,
hV (w) = hV (w1 )hV (w2 ) . . . hV (wn ), n > 0. O par h = hhV , hE i : H1 H2 um mor-
fismo total de hipergrafos entre H1 e H2 se e somente se hV srcH1 = srcH2 hE
406
e hV tarH1 = tarH2 hE . Um morfismo total de hipergrafos dito ser injetor (so-

brejetor, bijetor) se as suas funes componentes forem injetoras (sobrejetoras,
bijetoras).
Definio 8.2.21 (Morfismo parcial de hipergrafos) Seja H = hVH , EH , srcH ,

tarH i um hipergrafo. Um hipergrafo S = hVS , ES , srcS , tarS i dito um subgrafo
de H, escrito S H ou S , H, se e somente se VS VH , ES EH , srcS = srcH |ES
e srcS = tarH |ES . Um morfismo parcial de hipergrafos h entre dois hipergrafos
H1 e H2 um morfismo total de hipergrafos entre algum subgrafo dom(h) , H1
e H2 . dom(h) chamado de domnio de definio de h.
Hipergrafos rotulados e morfismos entre esses hipergrafos podem ser defi-

nidos nos mesmos moldes das definies destas estruturas para grafos. Este
trabalho deixado como exerccio para o leitor, mas deve ser uma aplicao
direta dos conceitos e definies j apresentados.
8.3. Grafos orientados a objeto

8.3.1. Grafos de classes
Linguagens de programao orientadas a objeto podem implementar di-
ferentes estruturas hierrquicas de classes (nas abordagens baseadas em
classes [Cook 1990]) ou objetos (nas abordagens baseadas em objetos
[Ungar et al. 1991]), dependendo do tipo de herana implementada e da exis-
tncia de uma classe da qual todas as outras derivam. A herana pode ser
simples ou mltipla, dependendo do nmero de classes das quais uma nova
classe pode derivar. Na herana simples, uma classe pode ser a extenso
de no mximo uma outra classe, enquanto que na herana mltipla uma nova
classe pode derivar de quantas classes quiser. Linguagens que implemen-
tam herana simples diferem no sentido de todas as classes possurem uma
classe primitiva comum (como a classe Object, em Java [Campione et al. 2000]
e Delphi [Lischner 2000]) ou no (como Ada95 [Barnes 1998], ou Glass
[Muhammad and Ferreira 2003]). O mesmo acontece com linguagens que per-
mitem herana mltipla, com uma classe primitiva comum (Eiffel [Meyer 1991])
ou sem ela (C++ [Stroustup 2000]).
Grafos acclicos representam fielmente a estrutura de classes em uma lin-
guagem orientada a objeto que permite herana mltipla, enquanto que lin-
guagens que permitem somente herana simples tm esta estrutura melhor
representada por um conjunto de rvores, que so casos particulares de gra-
fos acclicos. A ausncia de ciclos, isto , da existncia de um caminho de
comprimento maior que zero entre um nodo e ele mesmo, consistente tanto
com a criao de classes por herana quanto com a sobrescrita de mtodos
em linguagens orientadas a objeto: uma classe, para ser definida como uma
especializao (derivao) de outra, necessita que a classe primitiva j exista
antes que ela seja criada. De maneira similar, um mtodo s pode sobrescre-
ver (redefinir) outro mtodo se o segundo j existir em alguma classe primitiva
daquela que o sobrescreve. Assim, nem classes podem ser derivadas nem
407
Ferreira e Ribeiro
mtodos podem ser sobrescritos de forma circular. Da mesma forma, no faz

tambm sentido que uma classe seja uma especializao de si mesma ou que
um mtodo seja uma redefinio de si prprio.
A definio de uma relao estrita, apresentada a seguir na Definio 8.3.1,
formaliza o que deve ser a organizao hierrquica fundamental das classes
em linguagens orientadas a objeto de modelagem ou programao, quando
somente herana simples for permitida2 .
Definio 8.3.1 (Relao estrita) Uma relao binria R A A dita uma

relao estrita se e somente se apresentar as seguintes propriedades:
1. se (a, a0 ) R ento a 6= a0 (R irreflexiva);
2. se (a, a1 ), (a1 , a2 ), . . . , (an1 , an ), (an , a0 ) R, n > 0, ento (a0 , a)
/ R (R
acclica);
3. para quaisquer a, a0 , a00 A, se (a, a0 ), (a, a00 ) R ento a0 = a00 (R uma
funo);
4. para todo a A, ou (a, b) / R para todo b A ou ento existe n > 0 tal
que se (a, a1 ), (a1 , a2 ), . . . , (an1 , an ) R, ento (an , b)
/ R para todo b A
(todas as cadeias em R so finitas).
As duas primeiras condies expressam a ausncia de laos e ciclos na

estrutura, conforme discutido nos pargrafos anteriores. A terceira condio
assegura que a herana simples implementada, isto , uma classe uma es-
pecializao de, no mximo, alguma outra classe. A excluso dessa condio
suficiente para representar hierarquias de classes que implementam herana
mltipla. A quarta condio tem significado terico e quer dizer que no pode
existir uma cadeia infinita de classes das quais uma classe derivada. Es-
pecificaes orientadas a objeto so necessariamente finitas (como todas as
coisas reais so), ento essa condio no influi no processo de definio das
classes de um modelo. A Figura 8.5 apresenta um exemplo de uma relao
estrita. Os nomes constituem os elementos do conjunto base A e as setas
pontilhadas representam a relao R.
A relao que representa a hierarquia de herana em um programa ori-
entado a objeto constituda como uma relao estrita. Contudo, esta hie-
rarquia tambm tem caractersticas de transitividade, visto que se uma classe
x deriva de uma classe y e se esta classe y deriva de uma terceira classe z
ento x tambm deriva da classe z. Quando queremos construir uma rela-
o transitiva a partir de uma relao que no tem esta propriedade, constri-
se um fecho. Para os propsitos deste texto, ser construdo o fecho tran-
sitivo e reflexivo da relao. O fecho transitivo e reflexivo de uma relao
2
Muitos resultados deste trabalho so estendidos trivialmente para herana mltipla. A
herana simples, contudo, alm de mais familiar aos programadores, facilita o entendi-
mento das definies aqui apresentadas.
408
Figura 8.5. Exemplo de uma relao estrita
a relao adicionada dos pares que faltam para que ela se torne uma re-
lao transitiva e reflexiva. Especificamente, para uma relao vP , seu fe-
cho reflexivo vP {(x, x) | x P}, ou seja todos os pares que contm os
elementos relacionados com eles mesmos. O fecho transitivo construdo
como vP {(x, y) | z1 , . . . , zk P : (x, z1 ), (z1 , z2 ) . . . , (zk1 , zk ), (zk , y) vP }, isto
, completado pelos pares necessrios para tornar a relao transitiva. O
Exemplo 8.3.1 mostra a construo do fecho reflexivo e transitivo da relao
estrita apresentada na Figura 8.5.
Exemplo 8.3.1 (Fecho transitivo e reflexivo) A relao estrita vP apresen-

tada na Figura 8.5 possui um conjunto base P = {Natural, Integer, Real,
Complex, Figure, Color, shape, square, round, triangle, circle, ellipse} e a
relao estrita em si dada pelo conjunto de pares vP = {(Natural,Integer),
(Integer, Real), (Real, Complex), (square, shape), (round, shape), (triangle,
shape), (circle, round), (ellipse, round)}, conforme indicam as setas na figura
que representam essa relao. Para construirmos um conjunto estritamente
ordenado Pv = hP, vP i desta relao, precisamos construir o fecho transitivo e
reflexivo de vP .
O fecho reflexivo construdo adicionando todos os pares {(x, x) | x P}
relao original, ou seja, adicionando o conjunto {(Natural, Natural), (Integer,
Integer), (Real, Real), (Complex, Complex), (Figure, Figure), (Color, Color),
(shape, shape), (square, square), (round, round), (triangle, triangle), (circle,
circle), (ellipse, ellipse)} relao. Na Figura 8.5 isso seria equivalente a adi-
cionar laos em todos os elementos do conjunto.
O fecho transitivo construdo adicionando os pares que faltam para tor-
nar a relao transitiva. Lembrando a sua definio, uma relao transitiva
sempre que (x, y) e (y, z) forem pares da relao, tem-se que (x, z) tambm
precisa ser um par da relao. Assim, na Figura 8.5, como (Integer, Real)
um par da relao e como (Real, Complex) tambm , tem-se que o par (In-
teger, Complex) deve ser adicionado relao. Fazendo isso com todos os
pares (direta e indiretamente, conforme a definio), deve-se adicionar o con-
junto {(Natural, Real), (Integer, Complex), (Natural, Complex), (circle, shape),
409
Ferreira e Ribeiro
Figura 8.6. Fecho reflexivo e transitivo da relao da Figura 8.5
(ellipse, shape)} relao original.

O fecho transitivo da relao apresentada na Figura 8.5 o conjunto
{(Natural,Integer), (Integer, Real), (Real, Complex), (square, shape), (round,
shape), (triangle, shape), (circle, round), (ellipse, round), (Natural, Real), (In-
teger, Complex), (Natural, Complex), (circle, shape), (ellipse, shape), (Natural,
Natural), (Integer, Integer), (Real, Real), (Complex, Complex), (Figure, Figure),
(Color, Color), (shape, shape), (square, square), (round, round), (triangle, trian-
gle), (circle, circle), (ellipse, ellipse)}. A representao grfica do fecho transi-
tivo e reflexivo da relao vP apresentado na Figura 8.6.
Pode-se mostrar que o fecho transitivo e reflexivo de uma relao estrita

uma relao de ordem parcial (Definio 8.2.7). Este fato permite que todos os
resultados da teoria de ordens parciais sejam usados na investigao de pro-
priedades de especificaes orientadas a objeto. Embora este fato no seja
explorado em detalhe neste texto, podemos us-lo para definir formalmente
composies e extenses de sistemas orientados a objeto, o que importante
se quisermos descrever reutilizao e combinao de tais sistemas. Este re-
sultado tambm ser importante na construo de computaes de sistemas
orientados a objeto especificados com grafos. Maiores detalhes podem ser
encontrados em [Ferreira and Ribeiro 2005].
Relaes estritas sero ento usadas para representar duas estruturas hie-
rrquicas distintas: herana e sobrescrita. Como essas relaes so definidas
sobre conjuntos (de classes e de mtodos de classe, respectivamente), deve-
mos definir ento o que ser chamado de conjunto estritamente ordenado, que
nada mais do que um conjunto equipado com uma relao deste tipo.
Definio 8.3.2 (Conjunto estritamente ordenado) Um conjunto estrita-

mente ordenado Pv um par hP, vP i onde P um conjunto, vP uma relao
410
estrita e vP o fecho transitivo e reflexivo desta relao.

Conjuntos estritamente ordenados so um caso especial de conjuntos par-
cialmente ordenados, onde a relao de ordem parcial subjacente ao conjunto
gerada pelo fecho transitivo e reflexivo de uma relao estrita.
Talvez a maneira mais intuitiva de modelar sistemas orientados a objeto
com grafos representar as classes e os objetos como nodos e os atributos e
mensagens como arcos. Um sistema orientado a objeto consiste em um con-
junto de instncias objetos de classes definidas previamente. Cada objeto
possui uma estrutura interna definida pelos seus atributos e se comunica com
outros objetos usando troca de mensagens, que na maioria das linguagens
orientadas a objeto modernas implementada como invocao de mtodos.
Os grafos usados para modelar estes sistemas devem, ento, refletir essa
estrutura. A definio das classes ser feita na forma de um grafo, onde cada
nodo um identificador da classe, hiperarcos partindo dos nodos represen-
tam os atributos da classe e hiperarcos chegando na classe representam as
mensagens que se pode enviar a elas, isto , seus mtodos. A hierarquia de
herana construda por uma relao estrita entre os nodos do grafo. A indi-
cao de quais mtodos so redefinidos e que mtodos os redefinem tambm
indicada por uma relao deste mesmo tipo nos hiperarcos que represen-
tam mensagens. Estas relaes so necessrias na especificao, para que
o polimorfismo de subclasses e a ligao dinmica de mtodos possam ser
modelados adequadamente nos programas que usam grafos. O grafo resul-
tante denominado grafo de classes e sua definio formal apresentada na
Definio 8.3.3, a seguir.
Notao: No que se segue, um pequeno abuso de notao utilizado: para
qualquer conjunto S, S+ denota o seu fecho transitivo e S denota seu fecho
transitivo e reflexivo com respeito operao de concatenao (ou seja, to-
das as listas finitas formadas por elementos de S). Um elemento s S re-
presenta uma lista finita de elementos (que podem ser repetidos) de S, en-
quanto que s S significa ou um nico elemento de S ou uma lista que contm
um nico elemento de S. Este abuso tambm utilizado em diversos livros
de Linguagens Formais (como [Lewis and Papadimitriou 1998], [Martin 1996],
e [Hopcroft et al. 2001]).
Definio 8.3.3 (Grafo de classes) Um grafo de classes uma tupla hVv , E v ,

L, src, tar, labi onde Vv = hV, vV i um conjunto estritamente ordenado de
vrtices, Ev = hE, vE i um conjunto estritamente ordenado de hiperarcos,
L = {attr, msg} um conjunto de dois rtulos de arcos, src,tar : E V so
duas funes monotnicas, chamadas respectivamente de funes de origem
(source) e destino (target), lab : E L a funo de rotulao dos hiperarcos,
tal que as seguintes restries sejam atendidas:
Restries estruturais: para todo hiperarco e E, as seguintes propriedades
so verdadeiras:
411
Ferreira e Ribeiro
se lab(e) = attr ento src(e) V e tar(e) V (se e um arco de

atributo ento ele tem exatamente um nodo de origem) e
se lab(e) = msg ento src(e) V e tar(e) V (se e um arco de
mensagem ento ele tem exatamente um nodo de destino).
Os conjuntos {e E | lab(e) = attr} (conjunto de todos os atributos) e
{e E | lab(e) = msg} (conjunto de todas as mensagens) so denotados
por E|attr e E|msg , respectivamente.
Restries sobre as relaes de ordem: para todo hiperarco e E, as se-
guintes propriedades so verdadeiras:
1. se (e, e0 ) vE ento lab(e) = lab(e0 ) = msg,

2. se (e, e0 ) vE ento src(e) = src(e0 ),
3. se (e, e0 ) vE ento (tar(e),tar(e0 )) vV+ , e
4. se (e0 , e) vE e (e00 , e) vE , com e0 6= e00 , ento (tar(e0 ),tar(e00 ))
/
vV e (tar(e00 ),tar(e0 ))
/ vV .
Definies formais nem sempre so de fcil leitura, mas so necessrias

para descrever sem ambigidades o que se est tentando dizer. No caso
acima, estamos descrevendo, usando estruturas matemticas tambm defi-
nidas formalmente, o tipo de estrutura que vai representar as classes de um
sistema orientado a objeto. Sempre que se quer transmitir uma informao
sem ambigidade, o melhor usar algum domnio matemtico. Matemtica,
no mbito da Cincia da Computao tambm uma linguagem, e como tal
deve ser entendida. Como qualquer linguagem, requer algum estudo e pr-
tica para ser dominada, ento sempre louvvel tentar entender as definies
apresentadas neste texto. Aps algum tempo e algum esforo, estas definies
vo se tornando cada vez mais claras. No pargrafo a seguir, a Definio 8.3.3
explicada em detalhe.
Grafos de classes so os grafos usados para modelar a organizao das
classes em sistemas orientados a objeto. Cada nodo do grafo um identifi-
cador de uma classe, os hiperarcos que saem dos nodos so os atributos da
classe e os hiperarcos que chegam em um nodo so as mensagens que po-
dem ser endereadas classe. Cada hiperarco rotulado como um elemento
do conjunto de rtulos (attr ou msg), e este rtulo serve para diferenciar qual
o tipo do hiperarco, visto que tanto atributos como mensagens so elemen-
tos do conjunto de hiperarcos. As restries estruturais representam o fato
de que um atributo pertence a uma nica classe se o hiperarco rotulado
como atributo ento possui uma nica origem e que uma mensagem (m-
todo) tambm pertence a uma nica classe. Um atributo que contm mais do
que um vrtice de destino pode ser visto como um registro (record ou struct),
ou seja, um nico nome que representa de fato um agrupamento de valores
de um mesmo tipo ou de tipos diferentes; os nodos origem de um hiperarco
412
de tipo mensagem so os parmetros passados para aquela mensagem. Um

hiperarco de tipo mensagem define ento a assinatura de um mtodo.
As hierarquias de herana e sobrescrita so definidas pelas relaes estri-
tas (Definio 8.3.2) existentes, respectivamente, sobre os conjuntos de nodos
e de hiperarcos. Como estas relaes so funcionais, ento restringe-se
herana simples. A relao de sobrescrita existente sobre o conjunto de hi-
perarcos identifica quais so os mtodos que esto sendo redefinidos e por
quais mtodos eles so sobrescritos. As restries existentes sobre esta rela-
o de ordem asseguram que os mtodos so sobrescritos de acordo com o
permitido pelo paradigma, isto , somente hiperarcos que representam mensa-
gens (rotulados como msg) podem ser sobrescritos (1), seus parmetros so
idnticos (2), o mtodo que est sendo sobrescrito existe em uma classe pri-
mitiva estritamente acima (na relao de herana) daquela que o sobrescreve
(3) e somente a mensagem mais prxima na relao de sobrescrita pode ser
redefinida (4).
Notao:A partir deste ponto, todos os grafos apresentados em formato grfico
seguiro a seguinte notao:
Os vrtices de um grafo sero representados por retngulos vazados,
contendo o nome do nodo.
Os hiperarcos de tipo atributo sero representados por um quadrado pre-
enchido colado ao retngulo que representa o seu nodo de origem; os
nodos de destino do hiperarco so indicados por setas que partem do
quadrado que identifica o hiperarco.
Os hiperarcos de tipo mensagem so identificados pelo smbolo <A.
Os tentculos (setas que partem do quadrado que identifica o hiperarco)
dos hiperarcos so nomeados para facilitar a leitura e o entendimento
dos grafos apresentados.
A relao estrita de herana entre os nodos indicada pelas setas tra-
cejadas que ligam os nodos.
A relao estrita de redefinio de mensagens indicada pelas sejas
pontilhadas que ligam os hiperarcos deste tipo.
Exemplo 8.3.2 (Grafo de classes) A Figura 8.7 apresenta um grafo de clas-

ses muito simples para figuras e formas geomtricas. Os nodos do grafo re-
presentam as classes (Shape, Round, Circle, Ellipse, Figure, Drawing, Color e
Integer) enquanto que os atributos e mensagens so representados pelos hi-
perarcos. A relao de herana representada pelas setas tracejadas, embora
somente a relao estrita subjacente esteja desenhada, para facilitar o enten-
dimento e a visualizao. A relao completa de herana dada pelo fecho
transitivo e reflexivo desta relao, conforme explicado no Exemplo 8.3.1, e a
relao de sobrescrita de mtodos est representada pelas linhas pontilhadas.
413
Ferreira e Ribeiro
Figura 8.7. Grafo de classes para formas geomtricas
A classe Figure possui um atributo denominado consists, cujo destino o

nodo Shape. Isso significa que o tipo do atributo um elemento da classe
Shape. A classe Shape, por sua vez, possui um atributo que um hiperarco
com trs tentculos de destino, o que significa que este atributo agrupa trs ele-
mentos de dados. Um tentculo denominado color, que deve ser um elemento
da classe Color e dois atributos denominados pos-x e pos-y que so ambos
elementos da classe Integer. A classe Shape especializada via herana na
classe Round, que por sua vez especializada nas classes Circle e Ellipse.
Note como a redefinio do mtodo Draw da classe Shape pelas classes Cir-
cle e Ellipse compatvel com as restries impostas na relao de sobrescrita
existentes na Definio 8.3.3.
8.3.2. Grafos tipados

Classes so representadas como nodos de um grafo de classes e seus
mtodos e atributos como hiperarcos, conforme visto na Seo 8.3.1. Uma
coleo de objetos, juntamente com seus atributos e mensagens endereadas
a eles (isto , um programa orientado a objeto) pode ser caracterizado como
um grafo tipado sobre um grafo de classes. Tipar um grafo nada mais do
que identificar cada um de seus elementos (nodos e arcos) com algum nodo
e algum arco de um outro grafo. Neste caso, deve-se identificar os elemen-
tos de um grafo que representa uma instncia de um objeto em um programa
orientado a objeto com os elementos de um grafo de classes especfico, visto
que os objetos de um programa so de alguma classe definida neste mesmo
programa. Grafos tipados [Corradini et al. 1996] so uma ferramenta poderosa
para especificao de sistemas via grafos. A tipagem que apresentamos aqui
414
uma generalizao daquela, para que as construes da programao orien-

tada a objeto possam ser implementadas. O leitor interessado convidado a
comparar as duas abordagem para ver a diferena [Ferreira and Ribeiro 2003].
Notao: Para qualquer conjunto parcialmente ordenado hP, vP i, um conjunto

parcialmente ordenado induzido hP , vP i pode ser construdo, tal que para
quaisquer duas seqncias de smbolos u = u1 . . . un , v = v1 . . . vn P tem-se que
u vP v se e somente se |u| = |v| (ambas as seqncias tm o mesmo compri-
mento) e ui vP vi , i = 1, . . . , |u| (os elementos correspondentes das seqncias
esto relacionados via herana). Se Pv e Qv forem conjuntos parcialmente
ordenados, qualquer funo monotnica (isto , que preserva a ordem dos
elementos mapeados, Definio 8.2.9) f : P Q pode ser estendida funo
monotnica f : P Q , com f (p1 . . . pn ) = f (p1 ) f (p2 ) . . . f (pn ) = q1 . . . qn onde
p1 . . . pn P and q1 . . . qn Q (ou seja, a funo estendida f transforma cada
elemento da seqncia no elemento em que a funo f o transformaria).
A definio de morfismo de tipagem, apresentado a seguir na Defini-

o 8.3.4, nada mais do que a identificao dos elementos de um grafo qual-
quer com os elementos do grafo de classes que representa a hierarquia de
classes em uma especificao. Como cada objeto em um programa orientado
a objeto definido como tendo exatamente um tipo, ento matematicamente
esse mapeamento pode ser representado por uma funo. O nome morfismo
usado em matemtica para quando se estabelece relacionamentos entre es-
truturas matemticas, e no deve ser encarado como uma dificuldade, mas
como um outro nome (mais tcnico) para estes relacionamentos.
Definio 8.3.4 (Grafo C-tipado) Um grafo C-tipado GC uma tupla hG,t, Ci,
onde C = hVC v , EC v , L, srcC , tarC , labC i um grafo de classes, G = hVG , EG ,
srcG , tarG i um hipergrafo e t um par de funes totais htV : VG VC ,tE :
EG EC i tais que (tV srcG )vVC (srcC tE ) e (tV tarG )vVC (tarC tE ).
Segundo a definio Definio 8.3.4, tem-se ento um hipergrafo G que

consta de um conjunto de vrtices, um conjunto de hiperarcos e as funes
de origem e destino dos hiperarcos. Note que G no possui relaes sobre
seus nodos e hiperarcos, assim como estes ltimos tambm no so rotulados
como atributos ou mensagens. Toda essa informao ser inferida quando um
elemento de G for identificado com um dos elementos do grafo de classes C,
que contm essa informao. Da mesma forma, quando se define um objeto
em um programa orientado a objeto, a informao sobre a classe do objeto
dada pela declarao do seu tipo. O mapeamento de tipagem em si feito
por duas funes, que mapeiam separadamente os vrtices e arcos dos gra-
fos chamadas, respectivamente, de tV : VG VC e tE : EG EC . Note que a
primeira funo tem como domnio o conjunto de vrtices do grafo G e como
contradomnio o conjunto de vrtices do grafo de classes C, enquanto que a
415
Ferreira e Ribeiro
segunda funo tem como domnio o conjunto de hiperarcos do grafo G e como

contradomnio o conjunto de hiperarcos do grafo de classes C.
As restries impostas s funes tV (que mapeia os vrtices) e tE (que
mapeia os hiperarcos) visam estabelecer a herana de atributos e mtodos do
paradigma. Apesar das expresses parecerem complicadas primeira vista,
seu significado trivial: um arco e de um grafo C-tipado pode ter como origem
(respectivamente, destino) qualquer nodo v do mesmo grafo desde que seja
tipado sobre um arco do grafo de classes (via a funo tE , ou seja, o tipo do
arco tE (e)) que tenha como origem (respectivamente, destino) um nodo com
o qual v esteja relacionado via herana. Esta definio reflete o fato de que um
objeto pode fazer uso de qualquer atributo (ou mensagem) que pertena a uma
de suas classes primitivas, visto que tal elemento herdado quando a classe
especializada. O Exemplo 8.3.3 ilustra essa situao.
Exemplo 8.3.3 (Grafo C-tipado) A Figura 8.8 mostra o grafo C-tipado G =

h{F, Egg, 2, 5, White}, {1, 2}, src,tari sobre o grafo de classes C da Figura 8.7.
Os tentculos dos hiperarcos so nomeados para facilitar a visualizao sem
a necessidade de setas explcitas, para no poluir o diagrama. Os tentculos
do hiperarco 2 so chamados color, pos-x e pos-y; o nico tentculo do hipe-
rarco 1 denominado consists. Note que um objeto da classe Figure deve ter
um atributo (hiperarco 1) do tipo Shape. O atributo do objeto F, contudo, do
tipo Ellipse. Mas isso permitido pelo morfismo de tipagem, visto que a classe
Ellipse est relacionada por herana com a classe Shape. A classe Ellipse, por
outro lado, no possui nenhum atributo no grafo C-tipado da Figura 8.7. Mas,
como uma Ellipse uma classe Shape especializada, ela herda todos os seus
atributos, o que significa que o grafo est bem tipado.
A seguir mostrado como o grafo est bem tipado (de acordo com sua
definio):
(tV src)(1) = Figure vVC Figure = (srcC tE )(1)

(tV tar)(1) = Ellipse vVC Shape = (tarC tE )(1)
(tV src)(2) = Ellipse vVC Shape = (srcC tE )(1)

(tV tar)(2) = Color Integer Integer vVC Color Integer Integer = (tarC tE )(1)
Relaes entre grafos C-tipados podem ser definidas em termos de morfis-

mos entre estas estruturas. As relaes existentes devem preservar a origem
e o destino dos arcos, bem como as relaes de herana e sobrescrita do grafo
de classes subjacente.
Definio 8.3.5 (Morfismo de grafo C-tipado) Sejam GC C

1 = hG1 ,t1 , Ci e G2 =
hG2 ,t2 , Ci dois grafos C-tipados sobre o mesmo grafo de classes C = hVv , E v ,
L, src, tar, labi. Um morfismo de grafos C-tipados h : GC C
1 G2 entre os grafos
C C
G1 e G2 , um par de funes parciais h = hhV : VG1 VG2 , hE : EG1 EG2 i tal
que h um morfismo parcial de hipergrafos (Definio 8.2.21) e para todos os
416
Figura 8.8. Exemplo de um grafo C-tipado
elementos v dom(hV ), (t2V hV )(v) vVC t1V (v), e para todos os elementos e
dom(hE ), (t2E hE )(e) vEC t1E (e). Se (t2E hE )(e) = t1E (e) para todo e dom(hE )
ento o morfismo dito estrito.
Um morfismo de grafo C-tipado permite que sejam relacionados elemen-

tos desde que estes elementos estejam relacionados (direta ou indiretamente)
pelas relaes de herana (no caso do nodos) ou de sobrescrita (no caso do
hiperarcos). O significado da ligao de dois elementos x 99K y pela relao de
herana a usual em programa orientado a objeto: em qualquer lugar onde um
elemento de tipo3 y for esperado, um elemento de tipo x pode aparecer, visto
3A palavra tipo usada aqui em um sentido menos restrito do que aquele usado na
maioria dos textos de projeto de linguagens de programao. Apesar de existir de
fato uma diferena entre as hierarquias de herana e de subtipagem entre objetos
[Cook et al. 1989], tal distino no ser levada em considerao aqui, visto que es-
tamos trabalhando em um nvel mais alto de abstrao. Espera-se que isso no seja
417
Ferreira e Ribeiro
que um objeto de tipo x tambm um objeto de tipo y. Um morfismo de grafos

C-tipados reflete este conceito, uma vez que dois nodos podem ser identifica-
dos pelo morfismo desde que seus tipos, pertencentes ao grafo de classes,
estejam conectados via relao de herana. De forma similar, dois arcos po-
dem ser relacionados pelo morfismo se seus tipos estiverem relacionados via
relao de sobrescrita. Como um arco de atributo somente est relacionado no
fecho transitivo e reflexivo da relao de sobrescrita consigo mesmo (de acordo
com a Definio 8.3.3), ele somente pode ser identificado em um morfismo de
grafo C-tipado com outro arco de atributo que tenha o mesmo tipo no grafo de
classes subjacente. Uma mensagem, contudo, pode ser identificada com qual-
quer mensagem que a redefina. As razes para isso devero ficar claras na
Seo 8.4.
Morfismos de grafos C-tipados so mapeamentos que preservam as rela-
es de herana e sobrescrita entre os nodos e hiperarcos. Este fato vai ao
encontro das caractersticas do paradigma, visto que a existncia de um rela-
cionamento de herana entre duas classes faz com que as funcionalidades da
classe primitiva estejam disposio para todos os objetos de suas classes
derivadas. Desta forma, pode-se considerar que um objeto no tem um tipo
nico, mas sim um conjunto de tipos, formado por todas as classes com as
quais a classe de tipagem do objeto est relacionada via herana. Definir um
morfismo de grafos que leve em considerao a relao de herana garante
que o polimorfismo de subclasses possa ser aplicado de forma consistente.
Exemplo 8.3.4 (Morfismo de grafos C-tipados) A Figura 8.9 mostra um pos-

svel morfismo entre os grafos C-tipados G1 e G2 (o morfismo h representado
por linhas tracejadas), ambos tipados sobre o mesmo grafo de classes da Fi-
gura 8.7. Note que os nodos dos grafos G1 e G2 possuem os mesmos nomes
que os do grafo de classes. Na realidade, esses nomes indicam o morfismo de
tipagem, de maneira a tornar o morfismo em si mais claro e o visual do grafo
menos poludo. No entanto, essa clareza deve ser entendida pelo que de fato
ela : uma representao do morfismo de tipagem pelos nomes dos elementos
presentes nos grafos.
Como o objeto de tipo Drawing tambm um objeto de tipo Figure, e como
uma classe Circle tambm uma classe Round este morfismo permitido. De
fato, pela definio temos que, alm do mapeamento ter que ser um morfismo
de grafos (ou seja, origens e destinos dos arcos so preservados), para todo
v dom(hV ), (t2V hV )(v) vVC t1V (v), e para todos os elementos e dom(hE ),
(t2E hE )(e) vEC t1E (e). De fato, assumindo que os nodos so numerados de
motivo de confuso para o leitor.
418
Figura 8.9. Morfismo de grafos C-tipados
cima para baixo, temos que

(t2V hV )(v1 ) = Drawing vVC Figure = t1V (v1 )
(t2V hV )(v2 ) = Circle vVC Round = t1V (v2 )
(t2V hV )(v3 ) = Color vVC Color = t1V (v3 )
(t2V hV )(v4 ) = Integer vVC Integer = t1V (v4 )
(t2V hV )(v5 ) = Integer vVC Integer = t1V (v5 )
(t2E hE )(1) = 1 vEC 1 = t1E (1)
(t2E hE )(2) = 2 vEC 2 = t1E (2)
Como somente so representados arcos de atributos na figura, ento os
tipos devem ser estritamente preservados. No caso de haver mensagens, elas
teriam que obedecer relao de sobrescrita.
Para definirmos grafos orientados a objeto, contudo, precisamos prestar
ateno no tipo de mensagem que cada objeto pode receber e quais so (e
quantos so) os atributos permitidos. Quando se define um sistema orientado
a objeto, espera-se que cada objeto criado carregue consigo uma estrutura
interna que corresponda a todos os atributos de sua prpria classe somados
a todos os atributos herdados das classes primitivas; da mesma forma, todos
os mtodos da classe juntamente com os herdados (e no redefinidos) devem
estar disponveis. Um grafo C-tipado contm todos os mapeamento adequa-
dos para lidar com herana e sobrescrita de mtodos. Contudo, no possui
limitao na quantidade de atributos que cada objeto pode ter e sobre mensa-
gens que foram redefinidas estarem endereadas a objetos que as redefiniram.
Desta forma, para definirmos formalmente o que deve vir a ser um sistema ori-
entado a objeto, devemos restringir a definio de grafo C-tipado de maneira a
que nossos propsitos sejam alcanados.
419
Ferreira e Ribeiro
Um grafo orientado a objeto ser ento um caso particular de um grafo C-

tipado. Antes de apresentarmos a definio formal, contudo, algumas funes
auxiliares sero definidas, conforme a Definio 8.3.6 apresentada a seguir.
Definio 8.3.6 (Conjuntos gerados de atributos e mensagens) Seja

hG,t, Ci um grafo C-tipado onde G = hVG , EG , srcG , tarG i e C = hVv , E v , L, src,
tar, labi. Sejam ento definidas as seguintes funes:
a funo de conjunto de atributos attrG : VG P(EG ) retorna para cada
vrtice v VG o conjunto {e EG | srcG (e) = v lab(tE (e)) = attr}. Isto ,
para cada vrtice v de um grafo C-tipado esta funo devolve o conjunto
que contm todos os arcos de atributos que tm como origem o nodo v;
a funo de conjunto de mensagens msgG : VG P(EG ) retorna para
cada vrtice v VG o conjunto {e EG | tarG (e) = v lab(tE (e)) = msg}.
Isto , para cada vrtice v de um grafo C-tipado esta funo devolve o
conjunto que contm todas as mensagens endereadas ao nodo v;
a funo de conjunto de atributos estendida, attrC : V P(E), onde
attrC (v) = {e E | lab(e) = attr src(e) v}. Isto , para cada vrtice
v de um grafo de classes esta funo devolve o conjunto que contm
todos os arcos de atributos que tm como origem o nodo v mais aqueles
atributos que tm como origem as classes primitivas de v, ou seja, todos
os atributos de uma determinada classe representada pelo vrtice v;
a funo de conjunto de mensagens estendida, msgC : V P(E), onde
msgC (v) = {e E|msg | tar(e) v e0 E|msg : tar(e0 ) v e0 vE e}.
Isto , para cada vrtice v de um grafo de classes esta funo devolve o
conjunto que contm todas as mensagens (herdadas ou no) que podem
ser endereadas a v, com exceo daquelas que foram redefinidas por
alguma mensagem deste conjunto; ou seja, todas as mensagens que
podem ser enviadas classe representada pelo vrtice v.
Para qualquer grafo C-tipado hG,t, Ci existe uma funo total tE : P(EG )
P(EC ), que pode ser vista como uma extenso da funo de tipagem para
conjuntos de nodos ou de arcos. A funo tE , quando aplicada a um conjunto
E P(EG ), retorna o conjunto {tE (e) EC | e E} P(EC ). A notao tE |msg
e tE |attr ser usada para indicar a aplicao de tE a conjuntos contendo exclu-
sivamente arcos mensagens e atributos (respectivamente). Com as funes j
definidas, pode-se ento definir o tipo de grafo que vai representar sistemas
orientados a objeto.
Definio 8.3.7 (Grafo orientado a objeto) Seja C um grafo de classes. Um

grafo C-tipado hG,t, Ci um grafo orientado a objeto se e somente se para todo
v VG tem-se que
1. (tE |msg msgG )(v) = (msgC tV )(v) e
2. (tE |attr attrG )(v) = (attrC tV )(v).
420
Se, para todo v VG a funo tE |attr (attrG (v)) for injetora, GC dito um grafo
orientado a objeto estrito. Se tE |attr (attrG (v)) for tambm sobrejetora, GC
chamado um grafo orientado a objeto completo.
Grafos orientados a objeto diferem dos grafos C-tipados no seguinte sen-
tido: o nico tipo de mensagem que pode ser recebida por um objeto so as
menores possveis de acordo com a relao de sobrescrita. Isso porque, se-
gundo a primeira condio apresentada na Definio 8.3.7, uma mensagem
que tem como destino um objeto somente pode ser tipada por algum dos tipos
retornados pela funo de conjunto de mensagens estendida. Isso quer dizer
que no possvel termos uma mensagem tipada como algum mtodo que j
foi redefinido. Isso feito para garantir a implementao da ligao dinmica
de mtodos, visto que um objeto sempre responde ao mtodo mais prximo a
ele na hierarquia de herana e sobrescrita. A forma de garantir que isso sem-
pre acontece ser discutida na Seo 8.4, quando computaes de sistemas
orientados a objeto forem discutidas.
Grafos orientados a objeto podem ser estritos ou completos. Grafos orien-
tados a objeto estritos so aqueles onde cada nodo no pode possuir dois ou
mais atributos tipados como o mesmo arco no grafo de classes subjacente. A
injetividade de todas as funes tE |attr (attrG (v)), onde v VG , expressa que to-
dos os arcos de atributo de um mesmo vrtice so tipados de forma distinta (ou
seja, um objeto no possui atributos em excesso). Para que um grafo orientado
a objeto seja completo, no entanto, tambm necessrio que todos os atribu-
tos definidos em todos os nveis da relao de herana estejam presentes. A
definio de um grafo orientado a objeto completo coerente com a noo de
herana no paradigma da orientao a objeto: um objeto possui todos os atri-
butos definidos no mbito de sua prpria classe e herda todos os atributos, e
exatamente os atributos, que pertencem s suas classes primitivas.
Sistemas orientados a objeto so usualmente compostos por um nmero
grande de objetos, que podem receber mensagens de outros objetos (inclu-
sive de si prprio) e reagir a estas mensagens alterando seu estado interno
ou enviando mensagens a outros objetos. Grafos orientados a objeto podem
representar um sistema orientado a objeto de forma adequada: eles podem ter
quantos objetos se desejar, e mesmo que o nmero e tipo de atributos em cada
objeto seja limitado, o nmero de nodos no grafo que representa o sistema no
. Sendo assim, temos um formalismo capaz de expressar a estrutura esttica
das classes definidas em um programa orientado a objeto, juntamente com os
estados de um programa em execuo onde os nodos do grafo so os objetos
e os hiperarcos so todos os atributos e todas as mensagens a executar.
Para expressarmos a dinmica da execuo de um programa orientado a
objeto, contudo, precisamos de outro formalismo, capaz de expressar a ma-
neira como os estados de um programa evoluem com o tempo. Para isso, na
Seo 8.4 introduz-se formalmente o conceito de gramtica de grafos orien-
tados a objeto, que capaz de expressar finitamente todas as computaes
(finitas ou infinitas) de um sistema orientado a objeto.
421
Ferreira e Ribeiro
8.4. Gramticas de grafos orientados a objeto

8.4.1. Regras e grafos
Sistemas baseados em regras j provaram ser bastante teis para descre-
ver computaes por meio de transformaes locais: regras aritmticas, sint-
ticas e de deduo so exemplos familiares. Definio sinttica de linguagens,
semntica de linguagens de programao, programao funcional, programa-
o em lgica, especificao algbrica, reescrita de termos, prova automtica
de teoremas, sistemas especialistas, processos concorrentes e mveis so al-
guns exemplos de reas onde o papel das regras de fundamental importn-
cia.
Sistemas de transformao de grafos baseados em regras constituem uma
maneira bastante natural de combinar grafos, para a descrio de estruturas
complexas, com regras, para manipular estas estruturas. Transformao de
grafos, tambm conhecida como reescrita de grafos, combina os potenciais e
vantagens de ambos, grafos e regras, em um nico paradigma computacional.
A teoria de sistemas de transformao de grafos estuda uma va-
riedade de formalismos que expandem a teoria de linguagens for-
mais [Hopcroft 1969], [Hopcroft et al. 2001], [Lewis and Papadimitriou 1998],
[Martin 1996] para abarcar estruturas mais genricas especificadas como gra-
fos. Todas as construes conhecidas da teoria de linguagens formais baseada
em transformaes de strings tambm existem em sistemas de transformao
de grafos: regras, gramticas, derivaes e linguagens geradas por uma gra-
mtica podem ser definidas para grafos da mesma maneira que so definidas
para strings. Tambm da mesma forma, diferentes tipos de regras geram dife-
rentes classes de linguagens, com expressividade diferentes e tambm diferen-
as na decidibilidade dos problemas associados. J foi provado, contudo, que
todos os conjuntos enumerveis de grafos podem ser gerados usando regras
de transformao de grafos bastante restritas [Nagl 1986].
Da mesma forma que gramticas de strings, gramticas de grafos (siste-
mas de transformao de grafos equipados com um grafo inicial) tambm de-
terminam um modelo de computao. A estrutura dos grafos usada, o tipo de
produo de grafos e o resultado da aplicao das regras determinam o modelo
de computao especfico.
Um sistema de transformao de grafos permite que uma coleo (finita ou
infinita) de grafos seja descrita finitamente. Esta coleo constituda de todos
os grafos que podem ser obtidos a partir de um grafo inicial por meio da apli-
cao repetida de regras (ou produes) de grafos. Uma produo de grafos,
ou simplesmente uma regra, especifica como uma configurao de um sistema
pode ser alterada. Uma regra tem um lado esquerdo e um lado direito, que
so ambos grafos orientados a objeto estritos (Definio 8.3.7), e um morfismo
entre estes dois grafos, que determina o que deve ser alterado. Intuitivamente,
uma alterao descrita por uma regra ocorre da seguinte maneira: todos os
elementos que pertencem ao lado esquerdo da regra devem estar presentes
no grafo que representa o estado do sistema para que a regra possa ser apli-
422
cada; todos os itens mapeados do lado esquerdo da regra para o lado direito
da regra (via o morfismo entre os dois lados da regra) sero preservados pela
aplicao da regra; todos os elementos do lado esquerdo da regra que no
so mapeados so removidos; e, finalmente, todos os elementos que apare-
cem somente do lado direito da regra so adicionados ao estado corrente do
sistema.
Exemplo 8.4.1 (Aplicao de regra) A Figura 8.10 apresenta um exemplo de

aplicao de regra. A regra em questo representada pelos dois grafos na
parte superior da figura, onde r representa o morfismo entre eles. Os nodos e
arcos do grafo esto identificados pelos seus tipos, como de hbito, para que
o morfismo de tipagem no precise ser indicado explicitamente. Todos os gra-
fos so tipados sobre o grafo de classes apresentado na Figura 8.7. No lado
esquerdo da regra temos uma mensagem Draw enviada a um objeto de tipo
Figure, que possui um atributo consists de tipo Round. De acordo com o mor-
fismo r da regra, os objetos Figure e Round e o atributo consists devem ser
preservados, j que se encontram tanto no grafo do lado esquerdo quando no
do lado direito da regra (isto , so mapeados pelo morfismo r, embora este
mapeamento no aparea explicitamente na figura). A mensagem Draw que
aparece do lado esquerdo da regra deve ser removida na sua aplicao, visto
que no mapeada para o lado direito. A mensagem Draw endereada ao
objeto Round, que s aparece do lado direito, deve ser adicionada. Note que
a mensagem Draw que aparece do lado esquerdo da regra no pode ser do
mesmo tipo que a mensagem Draw que aparece do lado direito: se houvesse
este mapeamento, a regra no seria um morfismo de hipergrafos (no preser-
varia a origem e o destino dos elementos). A mensagem Draw que aparece
do lado direito , de acordo com o grafo de classes que tipa os elementos,
a mensagem Draw endereada classe Shape, que herdada pela classe
Round.
Na aplicao da regra, devemos achar uma ocorrncia do grafo do seu lado
esquerdo no grafo ao qual a regra ser aplicada (e que vai representar o estado
da execuo do programa orientado a objeto). Uma ocorrncia tambm um
morfismo de grafos C-tipados, s que deve ser total todos os elementos do
lado esquerdo devem estar no grafo do sistema. A ocorrncia mostrada expli-
citamente na figura, e o grafo resultante H construdo conforme a semntica
de aplicao de uma regra descrita: o elemento que a imagem da mensa-
gem Draw do lado esquerdo apagado do grafo, a nova mensagem Draw
adicionada na imagem de seu nodo de destino e todos os outros elementos
permanecem como esto: tanto os que foram preservados pela regra como os
que no foram mapeados pelo morfismo de ocorrncia.
O tipo de regra permitida pode variar, de acordo com aquilo que se quer
representar ou implementar. Regras sem qualquer tipo de restrio permitem
uma expressividade muito grande na especificao de sistemas. Contudo, elas
tambm podem levar a muitos problemas indecidveis. Restries em regras
423
Ferreira e Ribeiro
Figura 8.10. Exemplo de aplicao de regra
so importantes no s para tornar problemas interessantes decidveis (o que

por si s importante) mas tambm para refletir restries existentes nos sis-
temas que estamos tentando modelar. Todas as restries de regras apresen-
tadas na Seo 8.4.2 dizem respeito aos princpios da programao orientada
a objeto.
8.4.2. Regras orientadas a objeto

Para definir que tipo de regras de transformao de grafos sero permiti-
das para descrever as computaes de um sistema orientado a objeto, deve-
se levar em considerao as restries e particularidades do paradigma. De
acordo com os princpios da orientao a objeto, um sistema composto por
um conjunto de objetos que se comunicam trocando mensagens (que em mui-
tas linguagens so implementadas por invocaes de mtodos). Cada objeto
responde a uma mensagem recebida executando uma srie de aes. Adici-
onalmente, na execuo dessas aes, um objeto somente tem acesso sua
prpria estrutura interna (ocluso da informao). Caso um objeto queira al-
terar o estado interno de outro objeto, deve enviar uma mensagem (se esta
estiver disponvel) solicitando essa alterao.
Sendo assim, faz sentido que o lado esquerdo de uma regra (aquilo que
deve estar presente no sistema para que a regra possa ser aplicada) conte-
nha exatamente uma mensagem a ser tratada, juntamente com o objeto que
a recebe. Naturalmente que esta mensagem deve ser consumida pela apli-
cao da regra (ou seja, o arco da mensagem no poder ser mapeado pelo
morfismo da regra). A exigncia de somente existir uma mensagem do lado
esquerdo da regra no uma restrio muito forte s possveis computaes
do sistema, visto que muitas regras podem especificar reaes ao mesmo tipo
de mensagem (no determinismo) e vrias regras podem ser aplicadas em pa-
424
Figura 8.11. Mudana da classe de um objeto devido

aplicao de uma regra
ralelo (concorrncia), desde que no estejam em conflito [Ehrig et al. 1996a].

Alm disso, tambm devem estar presentes os atributos necessrios para que
as aes correspondentes regra possam ser executadas.
Alguns cuidados adicionais precisam ser tomados em relao ao morfismo
da regra. Em programas reais, um objeto nunca muda de tipo ao longo da
computao4 , mas as caractersticas de um morfismo entre grafos orientados
a objeto podem levar a que isso ocorra. O Exemplo 8.4.2 ilustra a situao
em que um objeto pode ter seu tipo (sua classe de definio) alterado por uma
aplicao de regra.
Exemplo 8.4.2 (Mudana de classe de objeto) Considere a derivao des-

crita na Figura 8.11. Os grafos deste exemplo tambm so tipados sobre o
grafo de classes apresentado na Figura 8.7, e o morfismo de tipagem impl-
cito pelo nome dos elementos.
O mapeamento da regra apresentado na Figura 8.11 um morfismo de gra-
fos C-tipados perfeitamente legal: uma classe Drawing tambm uma classe
Figure e um elemento da classe Circle tambm um elemento da classe
Shape. O morfismo de ocorrncia identifica os objetos do lado esquerdo da
regra com elementos do grafo G que tm exatamente os mesmos tipos. G o
grafo que representa o sistema orientado a objeto que est sendo transformado
e H o grafo resultante da transformao. Note, contudo, que o objeto tipado
4Linguagens de programao orientadas a objeto utilizam referncias na forma de apon-
tadores (s vezes chamados ponteiros) para objetos. Neste caso, mesmo que o tipo do
objeto referenciado possa mudar ao longo da computao, o tipo da referncia em si
no muda.
425
Ferreira e Ribeiro
como uma Figure em G mapeado (atravs do morfismo r0 , que o espelho do

morfismo r no grafo do sistema) para um objeto da classe Drawing; da mesma
forma, o objeto tipado como Shape mapeado para um objeto tipado como
Circle.
O morfismo r0 mantm o registro da evoluo dos objetos medida que
o tempo passa. Os objetos mapeados por este morfismo correspondem ao
mesmo objeto em qualquer ponto de uma computao, o que quer dizer que
se permitirmos regras onde um objeto troca sua classe, o mesmo pode ocorrer
de fato durante uma computao do sistema. A maneira de impedir que isso
acontea exigir que a funo que mapeia os objetos seja invertvel. Como a
funo de mapeamento dos nodos em um morfismo de grafos C-tipados exige
que, para que um nodo tipado como x seja mapeado para um nodo tipado como
y necessariamente y vV x (ou seja, y uma subclasse de x no grafo de classes
correspondente), ento a nica maneira da funo ser invertvel que y vV x e
que x vV y. Mas, como vV uma relao de ordem parcial (Definio 8.2.7), e
portanto antisimtrica, tem-se que necessariamente x = y, ou seja, ambos os
objetos precisam ter o mesmo tipo.
Outra questo importante que dois objetos no podem ser fundidos ao
longo da computao. Embora faa sentido criar e eliminar objetos durante a
execuo de um programa, no faz sentido fundi-los. Alis, como seria a fuso
de dois objetos? Teriam atributos duplicados? No caso da no duplicao
de atributos, como os novos valores dos atributos seriam computados? Pelo
menos esta no uma construo existente nas linguagens orientadas a objeto
mais conhecidas. A soluo deste problema consiste em exigir a injetividade do
morfismo da regra. Se a regra for injetora, dois objetos diferentes continuaro
sendo diferentes depois da aplicao da regra.
Como as regras devem corresponder s caractersticas do paradigma, a
ocluso de informao deve ser implementada. Isso significa que um objeto
no pode ter acesso estrutura interna de outro objeto quando computa. Para
caracterizar esta restrio de visibilidade, somente um objeto do lado esquerdo
da regra pode possuir atributos, e este deve ser precisamente o objeto que est
recebendo a mensagem que dever ser consumida. A existncia de arcos de
atributo em objetos que so, por exemplo, atributos do objeto que recebe a
mensagem, ou atributos de algum objeto passado como parmetro da mensa-
gem a ser tratada, significa que o mtodo que est sendo implementado pode
acessar (ler ou mesmo modificar) estes atributos. Impedindo a existncia des-
tes arcos de atributo do lado esquerdo da regra garante-se que as restries
de visibilidade so implementadas.
Por fim, embora no faa sentido a remoo de atributos de objetos, visto
que um atributo pertence estrutura interna de um objeto, que no modi-
ficada em tempo de execuo, permitido que atributos sejam apagados na
aplicao de uma regra. Esse aparente contra-senso exigido pelo fato de
que um morfismo de grafos exige que a origem e o destino dos arcos sejam
preservados. Sendo assim, a nica maneira de fazer um arco apontar para
426
outro objeto (o que significa na prtica alterar o valor do atributo em questo),

removendo-o e criando-o novamente com a mesma origem (o objeto ao qual
pertence) e com outro(s) destino(s), que correspondem ao(s) seu(s) novo(s)
valor(es). Os plurais da frase anterior dizem respeito ao fato de um atributo
tambm ser um hiperarco e, por esta razo, poder ter mais do que um objeto
de destino. Contudo, para evitar que um objeto perca ou ganhe atributos
ao longo da computao, para cada arco de atributo removido (ou seja, que
aparece no lado esquerdo da regra mas no no seu lado direito) deve ser cri-
ado um novo arco de atributo no lado direito da regra com exatamente o mesmo
tipo; da mesma forma, para cada arco de atributo no mapeado no lado direito
da regra deve existir um arco de atributo correspondente (do mesmo tipo) do
lado esquerdo da regra que removido na sua aplicao. Formalmente, deve
existir uma bijeo entre os arcos de atributo de ambos os lados da regra.
A definio formal de regra orientada a objeto dada pela Definio 8.4.1.
Definio 8.4.1 (Regra orientada a objeto) Uma regra orientada a objeto r

um morfismo de grafo C-tipado r = hrV , rE i : LC RC , onde LC = hL,tL , Ci e
RC = hR,tR , Ci so grafos orientados a objeto estritos tipados sobre o grafo de
classes C, e tal que as seguintes propriedades so verdadeiras:
rV injetora e invertvel, rE injetora,
{e EL | labC (tL (e)) = msg} um conjunto unitrio, cujo nico elemento
denominado mensagem do lado esquerdo da regra e cujo objeto de
destino chamado vrtice de atributos,
se {v VL | e EL , srcL (e) = v, labC (tL (e)) = attr} 6= 0/ ento um conjunto
unitrio, cujo nico elemento o vrtice de atributos,
cada regra implementa uma resposta a uma mensagem no mesmo nvel
(classe) em que a mensagem definida, i.e., se l a mensagem do lado
esquerdo da regra, ento (tV tarL )(l) = (tarC tE )(l),
a mensagem do lado esquerdo da regra no pertence ao domnio de r,
i.e., se l a mensagem do lado esquerdo da regra, ento l
/ dom(r) e
para todo vrtice v VL existe uma bijeo b : {e EL | labC (tL (e)) = attr
srcL (e) = v} {e ER | labC (tR (e)) = attr srcR (e) = rV (v)}, tal que tR b =
tL e tL b1 = tR .
A Definio 8.4.1 trata dos requisitos bsicos que respondem s caracte-

rsticas do paradigma. Contudo, outros tipos de regras podem ser construdas,
dependendo do tipo de sistema que se quer implementar. Em particular, pode-
se ter regras que no permitam nem a criao nem a eliminao de objetos,
regras que permitam somente a criao ou regras que permitam tanto a criao
quanto a eliminao de objetos ao longo da computao.
Estas regras podem parecer estranhas a quem est acostumado a progra-
mar com linguagens tradicionais, visto que em geral no h restries deste
tipo, podendo-se criar e eliminar objetos vontade. A questo aqui qual o
427
Ferreira e Ribeiro
objetivo da especificao: se quisermos modelar a estrutura e execuo de um

sistema orientado a objeto, no h razo para limitar a criao ou a eliminao
de objetos. Contudo, se o objetivo verificar propriedades de um sistema a
partir de sua especificao, ento a criao de objetos impede que mtodos
de verificao sobre estruturas finitas sejam utilizados, enquanto que a criao
e eliminao tornam a maior parte das propriedades no decidveis, e portanto
impossveis de verificar.
Para ilustrar como regras deste tipo podem ser especificadas, as Defini-
es 8.4.2 e 8.4.3 apresentam as suas definies formais.
Definio 8.4.2 (Regra orientada a objeto restrita) Uma regra orientada a

objeto restrita ou regra orientada a objeto sem criao ou eliminao de ob-
jetos r uma regra orientada a objeto r = hrV , rE i : LC RC onde rV uma
funo total e sobrejetora.
O fato de que o mapeamento entre os nodos do lado esquerdo e do lado

direito da regra precisar ser total e sobrejetor garante que no h possibilidade
nem de remoo nem de criao de novos nodos (objetos) no grafo do sistema
por causa da aplicao da regra. Se a funo total, significa que todos os
nodos do lado esquerdo so preservados pela aplicao, ou seja, no h eli-
minao. Se a funo for sobrejetora, significa que para todo vrtice do lado
direito da regra existe um vrtice do lado esquerdo que o mapeia atravs da
regra. Outra forma de ver esta questo que, como o morfismo da regra , por
definio, injetor, o fato da funo de mapeamento dos nodos ser sobrejetora
indica que existe uma bijeo (correspondncia um para um) entre os nodos
dos dois lados da regra, que so todos preservados na sua aplicao.
Definio 8.4.3 (Regra orientada a objeto irrestrita) Uma regra orientada a

objeto irrestrita uma regra orientada a objeto com criao de objetos
r = hrV , rE i : LC RC onde ou dom(rV ) = VL ou ento dom(rV ) = VL \{vrtice
de atributos}.
Regras orientadas a objeto irrestritas permitem que objetos possam ser

apagados, visto que o domnio da funo de mapeamento dos vrtices do grafo
diz que ou todos eles so mapeados, isto , todos sero preservados na apli-
cao da regra (dom(rV ) = VL ) ou ento o vrtice de atributos o nico nodo
removido (dom(rV ) = VL \{vrtice de atributos}). Note que este fato implica um
princpio da boa programao orientada a objeto, onde um objeto somente
pode eliminar a si mesmo.
Diferentes tipos de regras permitidas em uma gramtica do vazo a com-
putaes com diferentes caractersticas. As definies restantes, contudo, so
as mesmas independentemente do tipo de regra escolhida. Deste ponto em
diante, o termo regra orientada a objeto se refere a qualquer um dos tipos de
regras das Definies 8.4.2 e 8.4.3.
428
8.4.3. Derivaes
Uma derivao direta, ou passo de derivao, representa uma mudana no
estado de um programa em execuo, e obtida pela aplicao de uma regra
ao grafo que representa o estado do sistema.
Uma regra representa uma maneira possvel de evoluo de um sistema
orientado a objeto em qualquer ponto de sua execuo. Para que uma regra
possa ser aplicada, contudo, seus pr-requisitos devem estar presentes. O
pr-requisito de aplicao de uma regra dado pelo seu lado esquerdo. Sem-
pre que o lado esquerdo de uma regra existir em algum ponto do grafo que
representa o sistema, esta regra pode ser aplicada sobre aquele ponto. Essa
a noo de transformao local que os sistemas baseados em regras im-
plementam e que j foi discutida anteriormente. Note que uma mesma regra
pode potencialmente vir a ser aplicada em vrios pontos distintos do grafo do
sistema, bastando para isso que seu lado esquerdo aparea em mais que um
lugar do grafo ao mesmo tempo. Sendo assim, no h impedimentos para que
vrias aplicaes ocorram simultaneamente. Note como vrias aplicaes de
regra simultneas so equivalentes a vrios comandos sendo executados ao
mesmo tempo. Ou seja, aplicaes de regras so naturalmente atividades que
descrevem sistemas concorrentes.
Para que uma regra seja aplicada, ento, preciso encontrar uma ocorrn-
cia do lado esquerdo da regra no grafo que representa o sistema. Encontrar
uma ocorrncia significa achar um mapeamento total entre dois grafos, que
formalmente expresso por um morfismo de grafos.
Definio 8.4.4 (Ocorrncia orientada a objeto) Dado um grafo orientado a

objeto estrito GC e uma regra orientada a objeto r : LC RC , uma ocorrn-
cia orientada a objeto entre LC e GC um morfismo de grafos C-tipados
m = hmV , mE i : LC GC tal que mV uma funo total, mE uma funo to-
tal injetora, e para quaisquer dois elementos a, b L, se m(a) = m(b) ento ou
a, b dom(r) ou a, b
/ dom(r).
O papel de uma ocorrncia detectar uma situao em que uma re-

gra possa ser aplicada. Isso ocorre sempre que o lado esquerdo da re-
gra estiver presente em algum ponto do grafo que representa o estado da
execuo do programa. Esse match obtido pelo que denominado
isomorfismo de subgrafos, e que , em geral, um problema NP-completo
[Garey and Johnson 1999]. Contudo, pela prpria estrutura das regras usa-
das, basta inspecionar o grafo de sistema por arcos do tipo mensagem, j
que somente na presena deles que uma regra orientada a objeto pode ser
aplicada. Desta forma, podemos reduzir um problema que no caso geral tem
complexidade exponencial para (no pior caso) um procedimento que pode ser
realizado em tempo linear (proporcionalmente ao nmero de mensagens no
grafo). No o objetivo deste trabalho realizar anlises de complexidade dos
algoritmos associados implementao de gramticas de grafos orientados
429
Ferreira e Ribeiro
a objeto, mas interessante apontar que este um problema que pode ser
resolvido de forma eficiente.
Note-se que, pela definio de ocorrncia, dois vrtices distintos podem ser
identificados pelo morfismo. Essa identificao faz sentido, porque um objeto
pode ter uma referncia a si prprio ou enviar a si mesmo como parmetro
de uma mensagem para outro objeto. No entanto, no faz sentido identificar
dois atributos diferentes como sendo o mesmo atributo ou duas mensagens
distintas como sendo a mesma mensagem, ento a funo componente do
morfismo que mapeia arcos deve ser injetora.
O morfismo de ocorrncia tambm exige que elementos que so preser-
vados pela regra no possam ser identificados com elementos removidos por
ela. Esta restrio existe para impedir que efeitos colaterais indesejados ocor-
ram quando a regra for aplicada. Neste caso, o efeito colateral relevante a
remoo de um elemento que deveria ser preservado.
Depois de encontrada uma ocorrncia, a regra em questo pode ser apli-
cada. A idia por trs de uma aplicao de regra construir um novo grafo de
estado a partir do grafo atual. Quando existe uma ocorrncia do lado esquerdo
de uma regra para o grafo que representa o estado atual do sistema, pode-se
dividir este grafo da seguinte forma: os elementos que esto na imagem do
morfismo de ocorrncia e os que no esto. Estes ltimos so ditos pertence-
rem ao contexto da aplicao da regra (que todo o grafo tirando os elementos
que esto na imagem da ocorrncia). Os elementos que esto no contexto da
aplicao no so alterados pela aplicao da regra5 ; os elementos que per-
tencem imagem do morfismo so alterados da seguinte forma: todos os tens
mapeados tanto pela ocorrncia quanto pela regra so preservados e levados
para o novo grafo; todos os elementos que pertencem imagem da ocorrncia
mas cujas origens no pertencem ao domnio da regra (isto , no so ma-
peados pela regra) so apagados e no aparecem no novo grafo; finalmente,
todos os elementos que no pertencem imagem do morfismo da regra so
adicionados ao novo grafo, que representa ento o novo estado do sistema.
O Exemplo 8.4.1 mostrou um exemplo de aplicao de regra, antes que sua
definio formal fosse apresentada. interessante tentar mapear o exemplo
na definio formal de derivao direta, para verificar se tanto a prtica como
a teoria foram entendidas.
Definio 8.4.5 (Derivao direta orientada a objeto) Dados um grafo ori-

entado a objeto completo GC = hG,tG , Ci, uma regra orientada a objeto r : LC
RC e uma ocorrncia orientada a objeto m : LC GC , uma derivao direta ori-
entada a objeto, ou aplicao de regra orientada a objeto, pode ser computada
5
Existe uma possvel exceo se a regra permitir a remoo de nodos. Neste caso,
quando um nodo apagado todos os seus arcos incidentes so removidos tambm,
mesmo que eles faam parte do contexto de aplicao. Essa uma caracterstica da
abordagem single-pushout, e no ser explorada neste texto. Mais detalhes podem ser
encontrados em [Ehrig and Lwe 1993] e [Ehrig et al. 1996a].
430
em dois passos:
1. Construir a derivao resultante da aplicao da regra r ocorrncia
m conforme definido em [Ehrig et al. 1996a] e exemplificado no Exem-
plo 8.4.1, conseguindo um hipergrafo H e morfismos r0 : G H e m0 :
R H;
2. para obter o grafo resultante da derivao H C = hH,tH , Ci, equipar o re-
sultado do item anterior com o morfismo de tipagem para os seus nodos
e arcos dado abaixo:

para todo v VH , tH (v) = u tG (r0 1 (v)) tR (m0 1 (v)) ,

para todo e EH |attr , tH (e) = u tG (r0 1 (e)) tR (m0 1 (e)) ,
para todo e EH |msg , tH (e) = e0 , onde e0 msgC (tH (tarH (e))) e
e0 vE u [tG (r0 1 (e)) tR (m0 1 (e))].
A tupla hH C , r0 , m0 i o grafo orientado a objeto completo resultante da aplicao
da regra r ocorrncia m. Uma derivao direta do grafo GC para o grafo H C
r,m
sob a regra r e ocorrncia m denotado por GC H C .
Uma derivao de uma regra sobre uma ocorrncia provoca o colapso dos
elementos que so simultaneamente mapeados pela regra e pela ocorrncia,
enquanto copia o restante dos elementos provenientes do contexto e do lado
direito da regra. At aqui, esta definio idntica da abordagem algbrica
para gramticas de grafos. A diferena fundamental encontra-se na tipagem
dos elementos do grafo resultante.
Na abordagem tradicional, que usa morfismo de grafos tipados, os tipos
devem ser preservados pelo morfismo. Na abordagem aqui apresentada, as
relaes subjacentes que devem ser preservadas. Isso quer dizer que ele-
mentos de tipos diferentes podem ser mapeados pelo morfismo de ocorrncia
(o que, como j foi visto, implementa o polimorfismo de subclasses), ento
tem-se que decidir qual o tipo do elemento em questo no grafo resultante.
Note que no grafo resultante de uma aplicao de regra sob uma determi-
nada ocorrncia, cada elementos (nodo ou arco) pertence a uma das seguintes
trs situaes distintas: (i) o elemento pertence imagem da ocorrncia e
preservado pela aplicao da regra; (ii) o elementos no pertence imagem
da ocorrncia, e neste caso dito pertencer ao contexto da aplicao da regra;
(iii) o elemento foi criado pela aplicao da regra. Se o elemento vem do con-
texto ou do lado direito da regra, ento o seu tipo meramente copiado, visto
que o elemento em questo no est na imagem nem da ocorrncia nem da
regra. Para os elementos preservados pela regra, o tipo resultante o maior
limitante inferior (Definio 8.2.12) com respeito relao pertinente (herana
ou sobrescrita) entre os tipos dos elementos que esto na imagem do morfismo
e da regra sob o mesmo elemento no lado esquerdo desta e que so mape-
ados pelos morfismos m0 e r0 para o mesmo elementos do grafo resultante. A
431
Ferreira e Ribeiro
Figura 8.12. Exemplo de inexistncia de tipagem correta
necessidade de que a funo que mapeia os vrtices em uma regra orientada

a objeto seja invertvel assegura que o maior limitante inferior entre os tipos
das imagens dos elementos preservados pela regra sempre existe. Sem essa
restrio, seria impossvel assegurar a existncia de uma estrutura resultante,
como o Exemplo 8.4.3 ilustra.
Exemplo 8.4.3 (Inexistncia de tipagem correta) Considere os quatro gra-

fos orientados a objeto da Figura 8.12, tipados sobre o grafo de classes da
Figura 8.7. Todos eles possuem uma estrutura idntica, composta de dois no-
dos e um arco de atributo. Como tem sido feito, os elementos so nomeados
pelos seus tipos no grafo de classes subjacente, para facilitar a visualizao.
O grafo localizado no canto superior esquerdo da figura possui um nodo
tipado como Figure, que consiste ( consists) de um elemento de tipo Shape.
O elemento tipado como Figure mapeado para elementos de tipo Figure e
Drawing pelos dois morfismos que existem para os grafos orientados a objeto
localizados, respectivamente, no canto inferior esquerdo e no canto superior
direito. O elemento da classe Shape mapeado para um objeto da classe
Circle no grafo do canto inferior esquerda e para um objeto da classe Ellipse
no grafo do canto superior direito. Ambos os morfismos so perfeitamente
legais, visto que tanto Circle quanto Ellipse so classes derivadas de Shape.
Mas no existe nenhuma classe que seja subclasse, ao mesmo tempo, de
Circle e de Ellipse, o que significa que o maior limitante inferior destes dois
nodos com respeito relao de herana no existe. Isso faz todo sentido no
contexto da herana simples, onde duas classes que no esto relacionadas
por herana (como o caso) no podem possuir classes derivadas comuns.
Formalmente, essa noo expressa pela prpria definio de relao estrita
(Definio 8.3.1), que faz com que a interseco dos conjuntos inferiores de
432
dois elementos distintos no relacionados (direta ou indiretamente) seja vazio.

As mensagens, no entanto, necessitam de um cuidado especial. Como o
grafo do lado esquerdo da regra LC contm uma nica mensagem que deve
obrigatoriamente ser removida pela aplicao da regra (Definio 8.4.1), uma
mensagem no grafo resultante da derivao H C s pode ter vindo do grafo GC
ou do grafo RC . Se a mensagem vem de GC , que um grafo orientado a objeto,
no h necessidade de alterarmos o tipo da mensagem, visto que ela deve
estar corretamente tipada. Mas, se ela vem de RC , precisamos nos assegurar
que o seu tipo seja correto, de forma a que H C seja um grafo orientado a objeto
como requerido.
A situao potencialmente problemtica ilustrada na Figura 8.13. A regra
r, nesta figura, implementa uma situao comum: o resultado da execuo de
um mtodo a chamada a um outro mtodo que pertence a um dos atributos
do objeto em questo. Na implementao deste mtodo, um objeto da classe
Figure desenhado pelo envio de uma mensagem para a forma geomtrica
que a constitui (da classe Shape) para que ela se desenhe (e isso boa pro-
gramao orientada a objeto: a forma geomtrica que deve saber desenhar
a si prpria, a figura s deve ter conhecimento das formas que a compem).
Mas no grafo do sistema existe uma figura que tem uma elipse como forma
geomtrica constituinte, e sobre esta figura que a regra ser aplicada. Como
o mtodo Draw redefinido neste nvel (na classe Ellipse), a mensagem re-
sultante no pode ser a mensagem Draw da classe Shape, mas a mensagem
Draw da classe Ellipse. Para conseguir este resultado, no processo de tipa-
gem do grafo resultante tem-se que verificar qual a imagem da mensagem
que est no lado direito da regra, ver qual a classe do objeto para o qual a
mensagem aponta no grafo resultante e da encontrar o tipo certo, o que feito
pegando o tipo da nica mensagem do conjunto de mensagens que o objeto
no grafo resultante pode receber. Este processo realizado usando a fun-
o de conjunto de mensagens estendida sobre a classe do objeto que recebe
a mensagem no grafo resultante da derivao e que est relacionada com o
tipo de mensagem que aparece no lado direito da regra via relao de sobres-
crita. Esta mensagem necessariamente nica: ou ela prpria (se no foi
redefinida ou se no aplicado polimorfismo na ocorrncia) ou a mensagem
redefinida, j que o resultado da aplicao da funo funo de conjunto de
mensagens estendida (Definio 8.3.6) o conjunto dos tipos de mensagens
que um objeto pode receber, excluindo as mensagens que foram redefinidas.
Note que este processo o equivalente implementao de ligao di-
nmica de mtodos em programas orientados a objeto. A ligao dinmica
implementada em linguagens que suportam polimorfismo de subclasses e so-
brescrita de mtodos um mtodo que permite que em tempo de execuo
seja definida qual mtodo ser efetivamente chamado, dependendo do tipo de
objeto que uma referncia contm. Esse mecanismo prov grande flexibilidade
no desenvolvimento de sistemas orientados a objeto, e est embutido, por de-
finio, no formalismo aqui apresentado.
433
Ferreira e Ribeiro
Figura 8.13. Ligao dinmica como tipagem de mensagens
Resumindo, se a mensagem do grafo resultante da derivao vem do grafo

de contexto GC , no h necessidade de mudana de tipo da mensagem. Se,
no entanto, ela vem do lado direito da regra RC , ela deve ter seu tipo definido
no pelo objeto para o qual aponta em RC , mas de acordo com o objeto para o
qual a sua imagem aponta no grafo H C , visto que este elemento pode ter um
tipo diferente do indicado na regra, se polimorfismo de subclasses foi usado no
morfismo de ocorrncia e se a mensagem do lado direito da regra foi redefinida
para este objeto. Neste caso, a classe a que o objeto efetivamente pertence
pode ser qualquer elemento do conjunto inferior da classe indicada na regra.
Pode-se mostrar que uma derivao orientado a objeto direta est bem
definida, e que a estrutura proposta na Definio 8.4.5 sempre pode ser cons-
truda. Adicionalmente, o grafo H C = hH,tH , Ci resultante da derivao um
grafo orientado a objeto completo. Estes resultados tericos so importantes,
para mostrar que o que est sendo proposto reflete com fidelidade o que deve
acontecer. No faremos as demonstraes destes fatos neste texto, mas o lei-
tor interessado pode encontrar todos os resultados tericos referentes a este
formalismo em [Ferreira 2005].
Os grafos usados para representar sistemas orientados a objeto e os tipos
de regras que podem ser aplicados sobre eles determinam algumas proprie-
dades das computaes destes sistemas. Em particular, propriedades de fe-
chamento so interessantes, visto que podem fornecer informaes sobre os
resultados das computaes de sistemas. Pode-se mostrar que a classe dos
grafos orientados a objeto completos fechada para as derivaes com regras
orientadas a objeto que no permitem eliminao de objetos, embora no seja
para derivaes que usam regras irrestritas. Isso porque, de acordo com a de-
finio de derivao, se um nodo do grafo removido, todos os arcos (atributos
434
e mensagens) incidentes a ele so removidos tambm. Se existe um objeto

que mantm uma referncia para o objeto apagado, este arco de atributo vai
sumir, ou seja, existe a possibilidade de efeitos colaterais na estrutura interna
dos objetos causados pela aplicao de uma regra com eliminao. Esta situ-
ao conhecida como remoo em contextos indefinidos, e muito comum
em sistemas distribudos. Um exemplo muito familiar so os links de pginas
na Internet. Se uma pgina referencia outra, que removida ou muda de lugar,
tem-se o que se chama de link quebrado, ou referncia perdida. Na execuo
de um programa, qualquer computao com um objeto cuja referncia foi per-
dida vai causar um erro de execuo. Essa situao pode ser detectada no
modelo definido com gramtica de grafos orientados a objeto, caso as regras
permitam a eliminao de objetos.
A seguir, define-se formalmente o que uma gramtica de grafos orienta-
dos a objeto.
Definio 8.4.6 (Gramtica de grafos orientados a objeto) Uma gramtica

de grafos orientados a objeto uma tupla hI C , PC , Ci onde I C um grafo orien-
tado a objeto completo, PC um conjunto finito de regras orientadas a objeto e
C um grafo de classes.
O grafo inicial I C corresponde configurao inicial do sistema orientado a

objeto que estamos modelando/programando. Neste grafo temos todos os ob-
jetos presentes no sistema, com os valores de seus atributos (que so outros
objetos) j definidos e com as mensagens que os objetos recebem inicialmente.
Este grafo inicial vai evoluir ao longo do tempo por meio da aplicao das re-
gras da gramtica. O tipo de regra (se permite ou no criao e eliminao de
objetos) vai depender do problema que est sendo resolvido, conforme discus-
so realizada anteriormente. Todos os grafos nesta definio (o grafo inicial e
os lados esquerdo e direito de todas as regras) so tipados sobre o mesmo
grafo de classes C.
Uma questo importante, que deve ser levantada quando se pretende mo-
delar a soluo de qualquer problema em alguma linguagem formal, seja esta
linguagem mais abstrata como o caso de gramticas de grafos ou concreta
como uma linguagem de programao, a questo da sua semntica. Lingua-
gens de programao em geral vm equipadas com uma semntica formal que
explica o significado (funcionamento) de cada uma das construes sintticas
da linguagem. No caso das gramticas de grafos, diversas semnticas podem
ser construdas. Estas semnticas variam no aspectos que dizem respeito
concorrncia verdadeira (regras podem ser aplicadas ao mesmo tempo) ou in-
tercalao de eventos. A diferena entre as duas consiste na mesma diferena
entre sistemas multiprocessados e multiprogramados: no primeiros temos mais
do que um processador executando, de fato, ao mesmo tempo; nos segundos
temos um nico processador compartilhado pelos processos que nele execu-
tam. As semnticas podem ainda variar na quantidade de informao que
levam em considerao. Apesar da discusso sobre semnticas de gramticas
435
Ferreira e Ribeiro
de grafos encontrar-se alm do escopo deste trabalho, a programao ser

daqui para a frente realizada supondo uma semntica de intercalao. Esta
semntica assumida porque os verificadores de modelos [Clarke et al. 1999],
[Holzmann 1997], [Huth and Ryan 2000] que podem ser usados para verificar
propriedades especficas sobre os sistemas modelados usam esta semntica
na gerao do espao de estados do problema, ento faz mais sentido su-
por que as gramticas funcionem da mesma forma. Na prtica, continua-se
a manter os aspectos no determinsticos da execuo (no existe seqncia
pr-determinada na execuo de duas regras para as quais existe ocorrncia
no grafo) mas a aplicao das regras no pode ser realizada de forma simult-
nea.
Na Seo 8.5 sero apresentadas duas propostas de soluo para um pro-
blema clssico de concorrncia, que so modeladas usando gramticas de
grafos orientados a objeto.
8.5. Programao com grafos

8.5.1. O Jantar dos Filsofos (com bloqueio)
O problema do jantar dos filsofos foi originalmente apresentado por Eds-
ger Dijkstra em 1965 [Dijkstra 1965], como forma de ilustrar uma situao inde-
sejvel que pode ocorrer em programas concorrentes. O problema consiste na
seguinte situao: um nmero n de filsofos est sentado volta de uma mesa
circular com um prato de espaguete frente, um garfo do seu lado esquerdo e
outro garfo do seu lado direito (isto , existem n filsofos, n pratos e n garfos).
A vida de um filsofo consiste em comer e pensar, em intervalos alternados de
tempo. Quando um filsofo pra de pensar, ele deve pegar ambos os garfos ao
seu lado para que possa comear a comer. Como cada garfo compartilhado
entre dois filsofos, filsofos adjacentes no podem comer ao mesmo tempo.
A soluo do problema envolve um programa em que todos os filsofos de
fato alternem sua vida entre perodos nos quais pensam e perodos nos quais
comem. Para que isso ocorra, o programa deve apresentar a propriedade de
que sempre que um filsofo decide comear a comer, ele consegue comear a
comer em algum ponto do futuro. Se o programa apresenta esta propriedade,
ento no haver situaes indesejveis, como as que so exemplificadas a
seguir.
Uma abordagem intuitiva para resolver esse problema fazer com que cada
filsofo pegue o garfo que est sua esquerda, seguido do garfo que est
sua direita. Contudo, este algoritmo pode levar a uma situao de bloqueio
(deadlock ) uma vez que todas as quatro condies para a existncia de blo-
queios existem nessa situao: bloqueio de recursos compartilhados (garfos),
ausncia de preempo (nenhum filsofo pode pedir ao colega do lado para
ceder o seu garfo), manuteno de recursos enquanto novos recursos so ad-
quiridos (um filsofo fica segurando seu garfo esquerdo enquanto tenta pegar
o garfo sua direita) e espera circular (cada dois filsofos compartilham um
garfo) [Tanenbaum and Woodhull 1997].
436
A soluo deste problema consiste no desenvolvimento de um algoritmo

que evite, ao mesmo tempo, bloqueios e postergaes indefinidas (starvation).
Inicialmente apresentaremos uma modelagem mais simples, mas que permite
o aparecimento de bloqueios. Essa modelagem baseada na abordagem in-
tuitiva para a soluo apresentada anteriormente. A seguir apresentada uma
soluo que no permite bloqueios, mas que pode apresentar postergaes
indefinidas. A proposio de uma soluo usando semforos, que segue a
linha da soluo apresentada em [Tanenbaum and Woodhull 1997], ser dei-
xada como exerccio para o leitor.
Pode ocorrer uma situao de bloqueio se todos os n filsofos conseguirem
pegar um dos garfos. Nessa situao, nenhum filsofo ser capaz de pegar um
segundo garfo, visto que todos os n garfos estaro em poder de algum dos fi-
lsofos. Assim, o primeiro filsofo espera que o segundo filsofo libere o garfo,
que por sua vez espera que o terceiro filsofo libere o garfo, e assim suces-
sivamente at que o crculo se feche. Se nenhum filsofo desistir de esperar
e largar o garfo, temos uma situao de bloqueio estabelecida e nenhum dos
filsofos pode prosseguir sua execuo.
A falta de garfos disponveis uma analogia alocao de recursos com-
partilhados em uma situao de programao real. Alocar um recurso uma
tcnica comum de programao, para garantir que nenhum recurso (impresso-
ras, discos, arquivos, etc.) seja acessado por mais do que um programa ou
trecho de cdigo simultaneamente. Quando um recurso de interesse estiver
alocado, o programa deve esperar at que o recurso seja liberado. Quando
mltiplos programas esto alocando os mesmos recursos, situaes de blo-
queio e postergao indefinida podem ocorrer.
A primeira soluo apresentada a seguir visa introduzir a modelagem ori-
entada a objetos com gramticas de grafos. A seguir, faz-se uma modelagem
mais elaborada que efetivamente resolve o problema com respeito aos blo-
queios. A prova de que a modelagem est de fato correta (i.e., apresenta as
propriedades de ausncia de bloqueio e postergao indefinida) encontra-se
alm do escopo deste texto. Contudo, faz-se uma discusso sobre como uti-
lizar mtodos de verificao formal em especificaes usando gramtica de
grafos orientados a objeto. Inicialmente, deve-se construir o grafo de classes
para o sistema, apresentado na Figura 8.14. Os nodos do grafo representam os
objetos que podem estar presentes no sistema, e que so os seguintes: Philo-
sopher, que representam as entidades (programas) que alocam recursos; Fork,
que representa os recursos compartilhados pelos filsofos; Table, que modela
tanto o local onde os filsofos esto sentados como o local de onde os recur-
sos (garfos) sero alocados; e ForkHolder, que pode ser tanto um Philosopher
quanto um Table.
Os atributos existentes no grafo de classes contm a informao que os ele-
mentos necessitam para computar corretamente: um Philosopher est (arco
denominado isAt) sentado em uma mesa (Table), possui um garfo (Fork ) lo-
calizado sua esquerda e outro sua direita (atributos leftFork e rightFork,
437
Ferreira e Ribeiro
Figura 8.14. Grafo de classes para o problema do Jantar

dos Filsofos
respectivamente) que ele deve apanhar para poder comer. Note que um fil-
sofo no pode pegar qualquer garfo da mesa, somente os que esto prximos
a ele; um garfo (classe Fork ) tem um dono, que pertence classe ForkHolder
e, pela relao de herana, classe Table ou classe Philosopher. Como
todos os hiperarcos do grafo possuem somente um nodo de origem e um de
destino, eles sero representados como arcos comuns. O quadrado preto da
notao utilizada at agora ser descartado para facilitar a leitura.
As mensagens que aparecem na Figura 8.14 correspondem s aes que
os objetos podem receber durante a execuo do programa. Um Fork pode ser
adquirido por um Philosopher, e liberado por um Philosopher para uma Table
(mensagens acquire e release, respectivamente). Um Philosopher pode estar
pensando (thinking), comendo (eating), receber a mensagem eat, que faz com
que ele comece a tentar comer, pegando os garfos de que precisa pra isso, ou
receber a mensagem got, que o notifica que um Fork foi apreendido.
Notao: Os lados direito e esquerdo de regras orientadas a objeto so grafos

orientados a objeto, isto , grafos tipados sobre um grafo de classes (veja a
Seo 8.3.2). No entando, de maneira a fazer esta apresentao mais clara,
todos os arcos e nodos destes grafos so nomeados de acordo com o seu tipo
no grafo de classes, tornando o morfismo de tipagem explcito.
A Figura 8.15 apresenta as regras para a classe Fork. O lado esquerdo da

regra AcquireFork possui, como esperado, uma nica mensagem acquire
endereada a um nodo de tipo Fork e que tem um objeto da classe Philo-
sopher como parmetro. Note que esta regra somente poder ser aplicada
caso o dono do garfo (o destino do atributo owner ) seja um objeto de tipo Ta-
ble: neste caso, e somente neste caso, o dono do objeto da classe Fork passa
a ser o objeto da classe Philosopher passado como parmetro da mensagem,
438
Figura 8.15. Regras para a classe Fork
o qual notificado de que conseguiu apanhar o garfo em questo pela men-

sagem got (na qual o garfo apreendido passado como parmetro). Um garfo
liberado (pela mensagem release) pela aplicao da regra ReleaseFork:
um objeto de tipo Fork recebe uma mensagem de seu dono atual (um Philo-
sopher ), indicando o objeto de tipo Table ao qual o grafo ir agora pertencer,
ento o Fork simplesmente muda o valor do atributo owner do Philosopher
para a Table.
A Figura 8.16 apresenta as regras da classe Philosopher. As regras im-
plementadas para as mensagens eating e thinking existem para assegurar que
pode haver um intervalo de tempo no determinado para os perodos em que
o filsofo pensa e come. De acordo com a semntica usual das gramticas
de grafos, no existe ordem especfica de aplicaes de regras para as quais
existe uma ocorrncia. Tambm no existe restrio referente ao tempo decor-
rido entre o aparecimento de uma mensagem e seu consumo. Uma ocorrncia
previamente existente de uma regra para o grafo que representa o sistem pode
inclusive deixar de existir antes que a regra seja aplicada, fazendo com que
a aplicao em questo no seja mais possvel. Sendo assim, o tempo que
um filsofo passa comendo ou pensando depende somente do tempo passado
entre o recebimento da mensagem (eating ou thinking, respectivamente) e o
seu consumo.
A aplicao da regra StopEating interrompe a atividade de comer do fil-
sofo: um filsofo sentado mesa que possui dois garfos envia uma mensagem
para seus garfos direito e esquerdo, enviando a mesa na qual est sentado e
a si mesmo como parmetros. A aplicao da regra StopThinking consome
a mensagem existente thinking, e interrompe a atividade de pensar enviando
uma mensagem para o filsofo que estava pensando (e que possua a mensa-
439
Ferreira e Ribeiro
Figura 8.16. Regras para a classe Philosopher
gem) dizendo que hora de comer (mensagem eat).

Um Philosopher responde mensagem eat tentando apanhar o garfo que
est sua esquerda. Este processo modelado pelo envio da mensagem
acquire ao atributo tipado como leftFork. Uma vez que o filsofo receba a
mensagem got deste atributo, ele comea a tentar apanhar o garfo sua direita,
enviando a mensagem acquire ao garfo sua direita (o atributo tipado como
rightFork ). Quando uma mensagem got recebida deste atributo, o filsofo
pode comear ento a comer, o que indicado pelo envio da mensagem eating
a si mesmo, sinalizando que o perodo de comer teve incio.
A Figura 8.17 mostra o grafo inicial para o problema do Jantar dos Filsofos.
Conforme se pode ver, tem-se cinco filsofos Scrates, Plato, Nietzsche,
Hegel e Kant sentados em uma mesa, tendo um garfo entre cada dois deles.
Inicialmente, todos os filsofos esto pensando, conforme indicado pelas men-
sagens direcionadas a cada um deles. O processo de pensar de cada um pode
ser interrompido a qualquer momento, pela aplicao da regra StopThinking
(Figura 8.16), que somente requer a existncia de uma mensagem thinking en-
440
Figura 8.17. Grafo inicial para o problema do Jantar dos Filsofos
dereada a um filsofo para ser aplicada. Note que existem cinco ocorrncias
possveis desta regra no grafo inicial.
fcil construir uma computao que leve a uma situao de bloqueio:
basta que uma regra StopThinking (Figura 8.16) seja aplicada em cada um
dos cinco filsofos ao redor da mesa. Neste caso, todos eles estariam re-
cebendo a mensagem eat. Se a todos os filsofos for aplicada ento a regra
1stFork (Figura 8.16), ser enviada uma mensagem acquire a todos os garfos
da mesa (que correspondem exatamente aos garfos do lado esquerdo de cada
filsofo). Como todos os garfos esto inicialmente sobre a mesa, existe uma
ocorrncia para a aplicao da regra AcquireFork (Figura 8.15) em todas as
mensagens geradas. Todos os garfos tero agora um filsofo como dono, e to-
dos os filsofos sero notificados com a mensagem got, gerada pela aplicao
da regra anterior. Todos os filsofos tentaro conseguir um segundo garfo para
comear a comer, a regra 2ndFork pode ser aplicada a todos eles, enviando
agora uma mensagem acquire aos garfos do lado direito dos filsofos. A partir
da, nenhuma outra computao possvel. Todos os garfos esto alocados
para algum filsofo, que no devolve o garfo mesa enquanto no conseguir
comer. No h maneira das mensagens acquire poderem ser consumidas, e
uma situao de bloqueio est estabelecida.
Note que esta computao especfica leva a uma situao de bloqueio em-
bora muitas outras possam no levar. Sendo assim, esse modelo no correto,
pois a propriedade de que sempre que um filsofo desejar comer ele o conse-
guir no futuro no verdadeira.
441
Ferreira e Ribeiro
8.5.2. O Jantar dos Filsofos ( sem bloqueio)

A soluo proposta em [Tanenbaum 1992] para o problema do Jantar dos
Filsofos utiliza semforos para organizar o jantar de modo que todo filsofo
que decida comer atinja seu objetivo aps um intervalo finito de tempo. A abor-
dagem realizada aqui inspirada naquela, mas difere em alguns conceitos
fundamentais: em primeiro lugar, uma regra aplicada na sua totalidade, ou
seja, no existem estados intermedirios em sua aplicao. Por outro lado, no
so definidas primitivas de bloqueio ou de sincronizao de processos, ento
estas construes precisam ser definidas nas regras de gramtica. A soluo
apresentada aqui inspira-se na soluo proposta por Dijkstra no seguinte sen-
tido: um filsofo F somente consegue apanhar seu primeiro garfo (o esquerdo),
se o filsofo sua esquerda FE ainda no iniciou o seu processo de comear a
comer. No caso do filsofo esquerda FE j ter iniciado seu processo de incio
da refeio, ento ele j deve ser detentor do seu garfo esquerda. Se o garfo
que o primeiro filsofo F est tentando buscar for adquirido, o filsofo FE ficar
bloqueado. Se esse processo se repetir (como foi o caso no exemplo da seo
anterior), ento pode haver uma situao de bloqueio.
A alterao do algoritmo ser realizada nos seguintes termos: antes de
um filsofo conseguir adquirir um garfo, ser verificado se o primeiro garfo do
filsofo esquerda j foi adquirido; em caso negativo, o filsofo consegue ad-
quirir o garfo; em caso positivo, o filsofo no consegue adquirir o garfo e o
processo de aquisio recomea. Para conseguir realizar este processo, cada
garfo precisa saber qual o garfo que deve estar liberado para que o pro-
cesso de aquisio possa ser completado. Isso feito via uma modificao
no grafo de classes do sistema, onde a classe Fork ter um atributo a mais
(refFork ), que vai apontar para este elemento. Outras modificaes tambm
so necessrias no grafo de classes. Em particular, esta troca de informaes
entre garfos precisa ser feita por troca de mensagens. As novas mensagens
da classe Fork so as seguintes: acqFirst, free?, ok, nok. O novo grafo de
classes para esta soluo do problema do Jantar dos Filsofos apresentado
na Figura 8.18.
A mensagem acqFirst a mensagem enviada por um filsofo para o seu
garfo esquerda quando deseja comear a comer. necessrio agora dife-
renciar a mensagem de aquisio do primeiro garfo, porque os processos so
diferentes: necessrio verificar se o garfo esquerda do filsofo esquerda
de quem faz a requisio est ou no alocado, o que no feito na aquisio
do segundo garfo. Esta requisio feita pela mensagem free? que enviada
ao garfo pertinente. As mensagens ok e nok so enviadas pelo garfo que rece-
beu a requisio respondendo, respectivamente, que o garfo em questo est
livre ou alocado. As novas regras para a classe Fork esto representadas na
Figura 8.19.
As novas regras da classe Fork so denominadas Acquire1stFork,
ForkFree, ForkOwned, FirstForkAcq e FirstForkAgain. As regras
AcquireFork e ReleaseFork so idnticas quelas apresentadas para esta
442
Figura 8.18. Grafo de classes para o problema do Jantar

dos Filsofos (sem bloqueio)
classe na seo anterior. As modificaes dizem respeito basicamente s alte-

raes no algoritmo. A regra Acquire1stFork inicia os procedimentos para
que um garfo possa ser liberado para um filsofo, que passado como par-
metro da mensagem acqFirst, implementada nesta regra. Note que somente
existe uma ocorrncia para aplicao desta regra se o garfo em questo es-
tiver sobre a mesa (isto , no alocado a nenhum filsofo). Se a ocorrncia
existir, o objeto de tipo Fork que recebe a mensagem procede s seguintes
aes: em primeiro lugar, passa a pertencer ao filsofo que gerou a men-
sagem (passado como parmetro desta), para evitar que outro filsofo possa
se apossar deste garfo enquanto o procedimento realizado; depois, envia
uma mensagem free? ao garfo esquerdo do filsofo do lado esquerdo (que
est referenciado pelo atributo refFork de cada garfo), passando a si mesmo
e o objeto Table ao qual pertencia como parmetro. As regras ForkFree e
ForkOwned implementam a mesma mensagem free?. A aplicao destas re-
gras no mesmo objeto, contudo, excludente, visto que jamais pode haver uma
ocorrncia para as duas regras simultaneamente. A regra ForkFree pode ser
aplicada quando o objeto de tipo Fork ao qual ela se destina encontra-se so-
bre a mesa (no est alocado a nenhum filsofo); neste caso, o objeto Fork
continua pertencendo mesa (seu estado no alterado pela aplicao da
regra) e enviada uma mensagem ok ao garfo inquiridor, que veio como pa-
rmetro da mensagem. Caso o garfo inquirido pertencer a um filsofo, ento
existe uma ocorrncia para a regra ForkOwned. Neste caso, o objeto inquirido
tambm no tem seu estado alterado, mas envia uma mensagem nok para o
443
Ferreira e Ribeiro
Figura 8.19. Regras para a classe Fork (sem bloqueio)
444
Figura 8.20. Regra adicional para a classe Philosopher

(sem bloqueio)
objeto que fez a pergunta (passado como parmetro da mensagem free?), si-
nalizando que ele no est livre. Quando um garfo recebe a mensagem ok, a
regra FirstForkAcq sempre pode ser aplicada (note que a ocorrncia sem-
pre vai existir, visto que o garfo j foi alocado para um filsofo) e a nica ao
notificar o filsofo que pediu o garfo e que ainda no tinha sido notificado sobre
isso. Se a mensagem recebida for nok, contudo, tempos uma possvel situao
de bloqueio no horizonte. Neste caso, a regra FirstForkAgain aplicada, o
objeto Fork volta a pertencer mesa, e a mensagem que deu origem a todo
o processo, acqFirst enviada novamente ao garfo, com os parmetros ori-
ginais, reiniciando o processo. A nica alterao que necessria fazer nas
regras da classe Philosopher (apresentadas originalmente na Figura 8.16)
na regra PhilFirstFork, que ao invs de enviar a mensagem acquire agora
deve enviar a mensagem acqFirst, que d conta da verificao do estado do
garfo esquerdo do filsofo da esquerda do que est enviando a mensagem. A
regra alterada para a classe Philosopher est descrita na Figura 8.20.
O grafo inicial do problema tambm alterado, de maneira que cada garfo
conhea o garfo que deve ser investigado. O esquema inicial da gramtica
definida nesta seo apresentado na Figura 8.21.
Note que esta soluo no bloqueia o filsofo, que continua sempre ten-
tando pegar o garfo. Esta soluo apresentada, apesar de tornar impossvel
a existncia de bloqueios, permite postergaes indefinidas. Seja a seguinte
situao (de acordo com o grafo inicial apresentado na Figura 8.21): a men-
sagem thinking inicialmente enviada ao filsofo Hegel consumida pela apli-
cao da regra StopThinking, que envia uma mensagem eat para o mesmo
filsofo. Esta mensagem consumida ento pela nova regra Phil1stFork
(Figura 8.20), que produz a mensagem acqFirst que enviada ao garfo do
lado esquerdo de Hegel, Fork3. Como o atributo owner de Fork3 tem como
tipo Table, a regra Acquire1stFork pode ser aplicada. Com a aplicao
desta regra, o atributo owner de Fork3 passa a apontar para Hegel e en-
viada uma mensagem free? ao garfo Fork4. Como Fork4 tem seu o atri-
buto owner apontando para um objeto de tipo Table, existe uma ocorrncia
para a regra ForkFree e esta pode ento ser aplicada. A aplicao da regra
ForkFree sobre o garfo Fork4 envia uma mensagem ok para o garfo Fork3
que foi passado como parmetro da mensagem free?. Neste momento, a re-
445
Ferreira e Ribeiro
gra FirstForkAcq aplicada e o filsofo Hegel recebe a informao de que

adquiriu o garfo Fork3. Neste momento, imagine que o filsofo Nietzsche tem
sua mensagem thinking consumida pela regra StopThinking. A mensagem
eat enviada ao filsofo pela aplicao da regra tambm consumida pela apli-
cao da regra Phil1stFork, que envia uma mensagem acqFirst ao garfo
Fork2 que est esquerda de Nietzsche. Como Fork2 pertence a uma Ta-
ble a regra Acquire1stFork aplicada e a mensagem free? enviada ao
garfo Fork3. Como Fork3 pertence agora a um filsofo (Hegel, no caso) so-
mente existe uma ocorrncia para a regra ForkOwned e enviada ento uma
mensagem nok para o garfo Fork2, que por sua vez, pela aplicao da regra
FirstForkAgain reenvia a mensagem acqFirst tendo parmetro o filsofo
Nietzsche. Recebendo essa mensagem do garfo sua esquerda, existe uma
ocorrncia para a regra 2ndFork e uma mensagem acquire enviada agora
para o garfo direita de Hegel, Fork2. Como Fork2 pertence uma Table,
a regra AcquireFork aplicada, Hegel recebe uma mensagem got tendo
Fork2 como parmetro. A regra StartEating pode ento ser aplicada e He-
gel comea a comer. Neste momento, a mensagem eating enviada a Hegel
consumida pela aplicao da regra StopEating, que pede a liberao de
seus dois garfos para a mesa pelo envio da mensagem release para os garfos
Fork2 e Fork3 e da mensagem thinking para o prprio Hegel. Nesta situao,
a mensagem acqFirst enviada a Nietzsche j poderia ser consumida pela apli-
cao da regra AcquireFirstFork, que perguntaria ao garfo Fork3 se ele
estava livre, o que resultaria em sucesso visto que o filsofo Hegel j havia
parado de comer. Contudo, imagine que o filsofo Hegel inicia novamente o
seu processo de refeio antes que a seqncia de aplicao de mensagens
do garfo Fork2, requisitado por Nietzsche seja completada. Neste caso, Hegel
comearia a comer novamente e Nietzsche teria novamente que esperar. Uma
seqncia possvel de execuo repete este ciclo permanentemente, e o fil-
sofo Nietzsche jamais conseguir adquirir o objeto Fork2 e assim comear a
comer.
O desenvolvimento de uma soluo que no permita bloqueios nem pos-
tergaes indefinidas, no estilo dos semforos de Dijkstra, deixado como
exerccio para o leitor.
8.6. Concluses
Gramticas de grafos orientados a objeto representam um formalismo para
especificao de modelos de sistemas ou programas orientados a objeto. O for-
malismo em questo consiste em uma extenso da abordagem single-pushout
para gramticas de grafos com vistas a incorporar as principais caractersticas
do paradigma de orientao a objeto, nomeadamente: herana, polimorfismo,
encapsulamento e ocluso da informao.
Hipergrafos rotulados denominados grafos de classes so as estruturas
usadas para representar a hierarquia de classes em um sistema orientado a
objeto. Nodos representam classes, hiperarcos representam mensagens (m-
446
Figura 8.21. Grafo inicial para o problema do Jantar dos

Filsofos (sem bloqueio)
todos) ou atributos. Adicionalmente, existe uma relao de ordem parcial res-

trita sobre o nodos, que representa a herana entre classes, e sobre os arcos
de mensagens, que representa a sobrescrita de mtodos. Estas estruturas
servem para tipar os grafos que representaro sistemas e regras de grafos.
Grafos tipados so comumente usados para garantir que um sistema obe-
dece a uma certa estrutura permitida. Neste caso, o morfismo de tipagem
(feito sobre um grafo de classes) serve para identificar a que classe um objeto
pertence, e quais so os atributos e mensagens existentes. Em orientao a
objetos, contudo, o mecanismo de herana permite que um objeto use atributos
que suas classes primitivas tm, bem como execute mtodos que esto decla-
rados em outros nveis. O morfismo de tipagem aqui apresentado permite que
um objeto faa uso de elementos herdados, como em um sistema orientado a
objetos tradicionalmente implementado com linguagens de programao textu-
ais.
Morfismos de grafos orientados a objeto igualmente respeitam as relaes
de herana e sobrescrita ao grafo de classe subjacente. Um elemento de um
grafo (nodo ou arco) pode ser mapeado para um outro elemento desde que am-
bos os tipos estejam relacionados na relao pertinente. O encapsulamento de
dados e funes na mesma entidade sinttica obtido por restries estrutu-
rais no grafo de classes.
Grafos de classes e grafos orientados a objeto representam a especifica-
o esttica de um sistema. Para modelarmos o seu comportamento dinmico
(i.e., suas computaes) gramticas de grafos orientados a objeto so intro-
duzidas. O tipo de regra permitido nas gramticas utilizadas diz respeito s
restries impostas pelo paradigma. Um objeto somente age em funo do
447
Ferreira e Ribeiro
recebimento de uma mensagem, e a aplicao de um mtodo somente pode

fazer uso dos atributos (estado interno) do prprio objeto, garantindo que o
princpio de ocluso da informao seja respeitado. Sendo assim, cada re-
gra representa a aplicao de um nico mtodo, embora possam existir vrias
regras que implementem o mesmo mtodo.
Os morfismos de ocorrncia em gramticas de grafos orientados a objeto
so definidos da mesma forma que em gramticas de grafos usuais: como um
morfismo total do lado esquerdo de uma regra para o grafo que representa o
estado atual do sistema. Isso significa que o lado esquerdo de uma regra
um subgrafo do estado atual e a regra pode ser aplicada. Contudo, devido s
caractersticas dos morfismos de grafos orientados a objeto, uma ocorrncia
implementa tambm a noo de polimorfismo de subclasses, ou seja, todas as
regras definidas para uma determinada classe podem ser aplicadas em objetos
pertencentes a qualquer uma de suas subclasses.
Uma derivao representa um passo de avano na computao do sistema.
A construo resultante implementa ainda a ligao dinmica de mtodos, tor-
nando essa construo clssica da orientao a objeto uma caracterstica ine-
rente ao formalismo apresentado.
Gramticas de grafos orientados a objeto representam um passo impor-
tante na definio de linguagens visuais de especificao de sistemas orien-
tados a objeto. Todas as construes do paradigma esto presentes, e a fa-
cilidade do desenvolvimento visual patente na definio das especificaes.
Como importante que especificaes sejam produzidas a partir de um correto
entendimento dos requisitos de uma aplicao, necessrio que tanto desen-
volvedores quanto clientes participem do processo de especificao. Especi-
ficaes diagramticas so mais fceis de usar, produzir e entender por no
especialistas. Sendo ainda um mtodo de especificao formal, gramticas de
grafos orientados a objeto podem ser utilizadas para verificao formal de sis-
temas [Dotti et al. 2003], [Ferreira 2005] provando que uma especificao tem
as propriedades que dela se desejam.
Referncias
[Arajo Jr. and Sawyer 1998] Arajo Jr., J. and Sawyer, P. (1998). Integrating
object-oriented analysis and formal specification. Journal of the Brazilian
Computer Society, 5(1).
[Baresi and Pezz 2000] Baresi, L. and Pezz, M. (2000). Can graph gram-
mars make formal methods more human? In Workshop on Graph Transfor-
mation and Visual Modeling Techniques, pages 387394, Geneva (Switzer-
land).
[Barnes 1998] Barnes, J. (1998). Programming in Ada 95. Addison-Wesley
Professional, 2nd edition. 720p.
[Bergstra et al. 1989] Bergstra, J. A., Heering, J., and Klint, P. (1989). Algebraic
Specification. ACM Press, New York.
448
[Booch et al. 1999] Booch, G., Rumbaugh, J., and Jacobson, I. (1999). The
Unified Modeling Language User Guide. The Addison-Wesley Object Tech-
nology Series. Addison-Wesley, Reading.
[Breu 1991] Breu, R. (1991). Algebraic Specification Techniques in Object Ori-
ented Programming Environments, volume 562 of Lecture Notes in Computer
Science. Springer-Verlag, Berlin.
[Campione et al. 2000] Campione, M., Walrath, K., and Huml, A. (2000). The
Java(TM) Tutorial. Addison-Wesley, Upper Saddle River, 3rd edition.
[Cardelli and Wegner 1985] Cardelli, L. and Wegner, P. (1985). On understan-
ding types, data abstraction and polymorphism. ACM Computing Surveys,
17(4):471522.
[Clark and Taernlund 1982] Clark, K. L. and Taernlund, S.-A. (1982). Logic pro-
gramming. Academic Press, London. 366p.
[Clarke et al. 1999] Clarke, E. M., Grumberg, O., and Peled, D. A. (1999). Mo-
del Checking. MIT Press, Cambridge, MA. 387p.
[Cook 1990] Cook, W. R. (1990). Object-oriented programming versus abstract
data type. In de Bakker, J. W., de Roever, W. P., and Rozemberg, G., editors,
Foundations of Object-Oriented Languages, volume 489 of Lecture Notes in
Computer Science, pages 151178. Springer, Berlin.
[Cook et al. 1989] Cook, W. R., Hill, W. L., and Canning, P. S. (1989). Inhe-
ritance is not subtyping. In 17th Annual ACM Symposium on Principles of
Programming Languages, POPL, pages 125135. New York: ACM Press.
[Corradini et al. 1996] Corradini, A., Montanari, U., and Rossi, F. (1996). Graph
processes. Fundamentae Informatica, 26(3-4):241265.
[CSK CORPORATION 2005] CSK CORPORATION (2005). The
VDM++ Language. CSK Corporation. Available at
<http://www.vdmbook.com/langmanpp_a4_001.pdf>. Visited in May,
2005.
[Dijkstra 1965] Dijkstra, E. W. (1965). Solution to a problem in concurrent pro-
gramming control. Communications of the ACM, 8(9):569.
[Dotti et al. 2003] Dotti, F. L., Foss, L., Ribeiro, L., and Santos, O. M. (2003).
Verification of object-based distributed systems. In Najm, E., Nestmann, U.,
and Stevens, P., editors, International Conference on Formal Methods for
Open Object-Based Distributed Systems, FMOODS, volume 2884 of Lecture
Notes in Computer Science, pages 261275, Paris. Berlin: Springer-Verlag.
[Ehrig et al. 1996a] Ehrig, H., Heckel, R., Korff, M., Lwe, M., Ribeiro, L., Wag-
ner, A., and Corradini, A. (1996a). Algebraic approaches to graph transforma-
tion. Part II: single-pushout approach and comparison with double pushout
approach. In Ehrig, H., Kreowski, H.-J., Montanari, U., and Rozemberg, G.,
editors, Handbook of Graph Grammars and Computing by Graph Transfor-
mation, volume 1, chapter 4, pages 247312. World Scientific, Singapore.
449
Ferreira e Ribeiro
[Ehrig et al. 1996b] Ehrig, H., Kreowski, H.-J., Montanari, U., and Rozemberg,
G. (1996b). Handbook of Graph Grammars and Computing by Graph Trans-
formation, volume 1 (Foundations). World Scientific, Singapore.
[Ehrig and Lwe 1993] Ehrig, H. and Lwe, M. (1993). Parallel and distributed
derivations in the single-pushout approach. Theoretical Computer Science,
109:123143.
[Ferreira 2005] Ferreira, A. P. L. (2005). Object-Oriented Graph Grammars.
PhD thesis, Universidade Federal do Rio Grande do Sul, Porto Alegre.
[Ferreira and Ribeiro 2003] Ferreira, A. P. L. and Ribeiro, L. (2003). Towards
object-oriented graphs and grammars. In Najm, E., Nestmann, U., and
Stevens, P., editors, International Conference on Formal Methods for Open
Object-Based Distributed Systems, FMOODS, volume 2884 of Lecture Notes
in Computer Science, pages 1631, Paris. Berlin: Springer-Verlag.
[Ferreira and Ribeiro 2005] Ferreira, A. P. L. and Ribeiro, L. (2005). A graph-
based semantics for object-oriented programming constructs. Electronic No-
tes in Theoretical Computer Science, 122:89104.
[Fitting 1996] Fitting, M. (1996). First-order logic and automated theorem pro-
ving. Springer, New York, 2nd edition.
[Fitzgerald et al. 2005] Fitzgerald, J., Larsen, P. G., Mukherjee, P., Plat, N., and
Verhoef, M. (2005). Validated Designs for Object-oriented Systems. Springer,
New York.
[Gadducci 1996] Gadducci, F. (1996). On the Algebraic Approach to Concur-
rent Term Rewriting. PhD Thesis, Dipartimento di Informatica, Universit di
Pisa, Pisa, Italy.
[Garey and Johnson 1999] Garey, M. R. and Johnson, D. S. (1999). Computers
and intractability: a guide to the theory of NP-completeness. W. H. Freeman,
New York.
[Goguen and Malcom 1996] Goguen, J. A. and Malcom, G. (1996). Algebraic
semantics of imperative programs. MIT Press, London.
[Holzmann 1997] Holzmann, G. J. (1997). The model checker SPIN. IEEE
Transactions on Software Engineering, 23(5):117.
[Hopcroft 1969] Hopcroft, J. E. (1969). Formal languages and their relation to
automata. Addison-Wesley, Reading.
[Hopcroft et al. 2001] Hopcroft, J. E., Motwani, R., and Ullman, J. D. (2001). In-
troduction to automata theory, languages, and computation. Addison-Wesley,
Boston, 2nd edition.
[Huth and Ryan 2000] Huth, M. R. A. and Ryan, M. D. (2000). Logic in Compu-
ter Science: Modelling and reasoning about systems. Cambridge University
Press, Cambridge.
450
[Kennaway 1995] Kennaway, R. (1995). Infinitary rewriting and cyclic graphs.

Electronic Notes in Theoretical Computer Science, 2. 14p.
[Kosko 1992] Kosko, B. (1992). Neural networks and fuzzy systems: a dyna-
mical systems approach to machine intelligence. Prentice-Hall, Englewood
Cliffs.
[Lewis and Papadimitriou 1998] Lewis, H. R. and Papadimitriou, C. H. (1998).
Elements of the Theory of Computation. Prentice Hall, Upper Saddle River,
2nd edition.
[Lischner 2000] Lischner, R. (2000). Delphi in a Nutshell. OReilly.
[Martin 1996] Martin, J. C. (1996). Introduction to Languages and the Theory
of Computation. WCB/McGraw-Hill, 2nd edition.
[Meyer 1991] Meyer, B. (1991). Eiffel : The Language. Prentice Hall.
[Milner 1989] Milner, R. (1989). A Calculus of Communicating Systems.
Springer-Verlag, Berlin.
[Muhammad and Ferreira 2003] Muhammad, H. H. and Ferreira, A. P. L.
(2003). Explorao de reflexo computacional atravs de um modelo de
objetos sem classes. Revista Eletrnica de Iniciao Cientfica, 3(3):115.
[Nagl 1986] Nagl, M. (1986). Set theoretic approaches to graph grammars. In
Ehrig, H., Nagl, M., Rozenberg, G., and Rosenfeld, A., editors, 3rd Inter-
national Workshop on Graph Grammars and their Application to Computer
Science, volume 291 of Lecture Notes in Computer Science, pages 4154,
Warrenton, Virginia, USA. Berlin: Springer-Verlag.
[Nikolopoulos 1997] Nikolopoulos, C. (1997). Expert Systems. Marcel Dekker,
New York.
[Reade 1995] Reade, C. (1995). Elements of Functional Programming.
Addison-Wesley, Wokingham, 2nd edition.
[Russell and Norving 1995] Russell, S. J. and Norving, P. (1995). Artificial In-
telligence: a modern approach. Prentice-Hall, Upper Saddle River.
[Smith 1999] Smith, G. (1999). The Object Z Specification Language. Kluwer
Academic Publishers.
[Smith 1992] Smith, G. P. (1992). An Object-Oriented Approach to Formal Spe-
cification. PhD thesis, Department of Computer Science, University of Que-
ensland, Brisbane.
[Sterling and Shapiro 1994] Sterling, L. and Shapiro, E. Y. (1994). The Art of
Prolog : Advanced Programming Techniques. MIT Press, Cambridge, 2nd
edition.
[Stroustup 2000] Stroustup, B. (2000). The C++ Programming Language.
Addison-Wesley, Upper Saddle River, 3rd edition.
451
Ferreira e Ribeiro
[Tanenbaum 1992] Tanenbaum, A. S. (1992). Modern Operating Systems. Si-

mon & Schuster, Upper Saddle River, NJ.
[Tanenbaum and Woodhull 1997] Tanenbaum, A. S. and Woodhull, A. S.
(1997). Operating systems: design and implementation. Prentice Hall, Upper
Saddle River, 2nd edition.
[Thomas and Weedon 1997] Thomas, P. and Weedon, R. (1997). Object-
oriented programming in Eiffel. Addison-Wesley, Harlow.
[Ungar et al. 1991] Ungar, D., Chambers, C., Chang, B.-W., and Hlzle, U.
(1991). Organizing programs without classes. Lisp and Symbolic Compu-
tation, 3(4).
452

Programação Orientada A Objeto Com Grafos

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Programação Orientada A Objeto Com Grafos

Hochgeladen von

Copyright:

Verfügbare Formate

Programao Orientada a Objeto com Grafos

Ana Paula Ldtke Ferreira

significativos, falhas na execuo de programas considerados crticos podem

diagramtica, especificaes baseadas em grafos podem ser mais facilmente

uma interpretao mais interessante para as gramticas de grafos: o grafo

desenvolvimento modular de sistemas; (iv) a possibilidade de especificaes

8.2. Fundamentos matemticos

envolvida, interessante conhecer tambm as definies matemticas que a

8.2.1. Conjuntos, funes e relaes

Definio 8.2.1 (Produto cartesiano) Sejam A e B dois conjuntos. O produto

Definio 8.2.2 (Produto cartesiano generalizado) Sejam A1 , A2 , . . . , An , n >

Exemplo 8.2.1 (Produto cartesiano) A operao de produto cartesiano so-

dados dois conjuntos A = {a, b, c} e B = {1, 2}, o produto cartesiano de A

As noes mais importantes das quais necessitamos para entender o res-

Definio 8.2.3 (Relao) Sejam A1 , A2 , . . . , An conjuntos. Uma relao n-ria

Matematicamente, uma relao um subconjunto de um produto carte-

ao conjunto P das pessoas. No entanto, esta tripla s vai pertencer relao R

Algumas relaes tm propriedades especiais, e as relevantes para este

Exemplo 8.2.3 (Relaes binrias) Um exemplo de relao reflexiva a re-

Definio 8.2.5 (Funo) Uma funo n-ria f uma relao (n + 1)-ria

Definio 8.2.6 (Funo total, funo parcial) Sejam D e C dois conjuntos.

D ( f ?(x) = x, para qualquer x dom( f )) e f ! a funo f restrita aos elementos

Usualmente, em matemtica, trabalha-se com funes totais. Em Compu-

function dist (x1,y1: real; x2,y2:real):real;

Exemplo 8.2.4 (Funo parcial) Seja a funo f : N N definida como

Figura 8.1. Exemplo de uma funo parcial

Conforme a Definio 8.2.6, toda funo parcial f pode ser decomposta em

Funes podem apresentar propriedades em relao ao tipo de mapea-

Figura 8.2. Decomposio de uma funo parcial em

bijetora, se for simultaneamente injetora e sobrejetora.

8.2.2. Relaes de ordem parcial

Definio 8.2.7 (Relao de ordem parcial) Uma relao binria R A A

Exemplo 8.2.5 (Relaes de ordem parcial) Algumas relaes bem conhe-

A relao 6 sobre o conjunto dos nmeros reais uma relao de or-

A relao sobre conjuntos tambm uma relao de ordem parcial:

Definio 8.2.8 (Conjunto parcialmente ordenado) Um conjunto parci-

Funes entre conjuntos parcialmente ordenados em geral exigem que a

Definio 8.2.9 (Funo monotnica) Sejam hP, vP i e hQ, vQ i dois conjun-

Exemplo 8.2.6 (Funo monotnica) Uma funo monotnica uma funo

As definies dadas a seguir so pertinentes teoria de ordem. A estrutura

Definio 8.2.10 (Conjunto superior, conjunto inferior) Seja hP, vP i um

Definio 8.2.11 (Limitante superior, limitante inferior) Seja hP, vP i um

8.2.3. Grafos e morfismos de grafos

so vistas. Supe-se que o leitor j conhece estas estruturas, pelo menos de

Definio 8.2.13 (Grafo) Um grafo uma tupla G = hV, Ei onde V o conjunto

A Definio 8.2.14 permite que um grafo tenha tantas arestas paralelas

Definio 8.2.15 (Morfismo total de grafos) Sejam G1 = hVG1 , EG1 , srcG1 ,

Figura 8.3. Circuito digital como um grafo rotulado

Definio 8.2.16 (Morfismo parcial de grafos) Seja G = hVG , EG , srcG , tarG i

Um morfismo total ou parcial de grafos preserva a estrutura no seguinte

via um morfismo total de grafos (Definio 8.2.15). A definio de grafo rotulado

Definio 8.2.17 (Grafo rotulado) Um grafo rotulado G uma tupla ordenada

Exemplo 8.2.7 (Grafo rotulado) A Figura 8.3 apresenta um esquema de cir-

src(a1 ) = x1 src(a8 ) = x8 src(a15 ) = p6 tar(a4 ) = p2 tar(a11 ) = p6

labV (x1 ) = entrada labV (x7 ) = entrada labV (p4 ) = NAND

Da mesma forma que relaes (Definio 8.2.3) no precisam necessa-

Definio 8.2.18 (Alfabeto, string) Um alfabeto qualquer conjunto finito

Definio 8.2.19 (Hipergrafo) Um hipergrafo H uma tupla hVH , EH , srcH ,

Os elementos de VH so strings sobre o conjunto VH , que considerado

Figura 8.4. Exemplo de hipergrafo

Exemplo 8.2.8 (Hipergrafo) A Figura 8.4 mostra um exemplo de hipergrafo.

srcH (h1) = n1 tarH (h1) = n3

Morfismos totais e parciais de hipergrafos podem ser definidos da mesma